Service 作为 K8s 中的一等公民，其承载了核心容器网络的访问管理能力，包括： 暴露/访问一组 Pod 的能力 Pod 访问集群内、集群外服务 集群外客户端访问集群内 Pod 的服务 无论是作为应用的开发者还是使用者，一般都需要先经过 Service 才会访问到真正的目标 Pod。因此熟悉 Service 网络管理机制将会使我们更加深入理解 K8s 的容器编排原理，以期更好的服务各类业务。
多活建设：提高业务应用的可用性，避免单个集群或单个数据中心故障导致业务应用暂时不可用。 混合云建设：引入公有云弹性资源解决业务大促节假日资源洪峰 控制故障爆炸半径
几天前，K8s Network SIG 发布了 Gateway API（简称 gwapi）的 v1.1 版本[1]，这个版本的发布包含了多项重要功能的 GA（一般可用），以及一些实验功能的引入。这两部分分别通过标准渠道和实验渠道发布。
Kubernetes Gateway 或许，确切地应该称为 Kubernetes Gateway API[1] （下称 GWAPI）。GWAPI 是由 SIG-NETWORK[2] 社区管理的开源项目，是一种规范，不提供实现。Gateway API 被认为是 Kubernetes Ingress API[3] 的继任者，在 2019 年的 Ingress 革命[4] 中首次被提出，并在 2020 年 11 月发布了第一个版本。GWAPI 的发展非常快，截止本文发出已经演进到了 1.0.0 版本[5]，并且 1.1.0 也即将发布（已经发布了 1.1.0-rc2[6]）。
在容器化环境中，有效管理网络是至关重要的。容器网络接口（CNI）是一个标准，定义了容器应如何配置网络。本文将深入探讨 CNI 的基础知识，并带你了解 CNI 与 CRI 的关系。
这里的 kube on kube ， 是指建立 K8s 元集群，纳管其他业务 K8s 集群，通过声明式 API 管理集群的创建、增删节点等。
Cilium 是一种功能强大的网络、可观测性和安全解决方案。由于其灵活性和功能的多样性，它有着各种各样的使用场景。我查找了公开的文档和演讲，找到了我个人认为最重要的 20 个 Cilium 使用案例--其中也包括 Tetragon 和 Hubble。我认为以下的用例并不分先后顺序。
