Kubernetes 的 Ingress 资源只声明了「外部 HTTP/HTTPS 流量如何路由到集群内的 Service」,它本身不会产生任何转发行为。真正监听 Ingress 变化、把规则翻译成数据面配置、并对外接收流量的程序,就是 Ingress 控制器(Ingress Controller)。本文梳理它的工作原理与主流开源实现,并提供一个多维度对比与选型参考。

在 Kubernetes 集群中，Ingress 作为集群内服务对外暴露的访问接入点，几乎承载着集群内服务访问的所有流量。

Ingress 是 Kubernetes 中的一个资源对象，用来管理集群外部访问集群内部服务的方式。通过 Ingress 资源可以配置不同的转发规则，根据 Host、URL 路径等条件，将请求路由到不同 Service 所对应的后端 Pod。

暴露 Service 的三种方式

Kubernetes 中将 Service 暴露给集群外部访问，最常用的有三种类型：NodePort、LoadBalancer 和 Ingress。（ClusterIP 仅在集群内部可达，ExternalName 则通过 DNS CNAME 映射，二者不在本文讨论的对外暴露范围内。）

在学习和开发 Kubernetes(K8s)应用时，先在本地计算机上搭建一个集群用于验证，通常是最高效的方式。Kubernetes 官方文档专门将这类场景归为「学习环境（Learning Environment）」,与「生产环境（Production Environment）」相对。本文聚焦「安装」这一动作，给出四种主流本地安装方案的速查命令与关键点。

在学习和开发 Kubernetes(K8s)应用时,先在本地计算机上搭建一个集群用于测试和验证,是最高效的方式之一。官方文档将这些场景归为「学习环境(Learning Environment)」,与「生产环境(Production Environment)」相对。本文梳理四种主流的本地化部署工具,并对比其适用场景。

分析和理解 Kubernetes 的设计理念，可以使我们更深入地了解整个系统，更好地利用它管理分布式部署的云原生应用;另一方面，也能让我们借鉴其在分布式系统设计方面的经验。

1. 为什么需要 K8s 多集群

在讨论方案之前，先厘清概念。所谓 K8s 多集群（Multi-Cluster）,顾名思义就是多个 Kubernetes 集群协同工作。企业或组织可能根据自身需求，出于隔离性、可用性、合规性或使用成本等考虑，将应用运行在一个或多个集群中。在更成熟的形态下，应用实际运行的集群能够动态调度，不同集群间的应用也应支持相互访问。