容器化和微服务技术的飞速发展对于满足日益增长的应用需求至关重要，但要正确实施，就意味着需要克服一些关键的网络编排挑战。在云原生应用开发者面临的复杂性中，策略性地使用 Kubernetes Ingress Controllers 是最难理解的组件之一，也是最重要的组件之一。
在深入探讨 Ingress Controllers 之前，你需要了解为什么网络对于开发者工作流程如此重要。
开发团队通常会创建后端 API 服务，以便为外部应用和用户实现连接。在早期开发阶段，团队通常在本地开发机器上使用容器环境的实现，这些环境更简单地依赖于通过 Docker Compose 或类似的本地编排器进行直接容器调用来实现访问。
然而，当需要转移到共享开发或预发布环境并匹配将在生产环境中使用的配置时，这些直接访问的权宜之计就不再足够了。访问模式通常假定受信任的访问，这在生产环境中是不能假定的，或者它们依赖于静态值，而这些静态值很可能在云基础设施中发生变化。
上述权宜之计通常通过端口映射来处理——字面上是通过任意分配的端口将应用程序暴露给本地机器。但是端口映射根本无法转化为在 Kubernetes 环境中运行的应用程序，因为通常有多个副本在运行，而且有时会有集群运行软件的多个版本。虽然可以使用 Kubernetes Pod 和 Deployment 资源在进行这种转换时将自动化引入到容器生命周期管理中，但这些解决方案无法实现应用程序访问。
幸运的是，Kubernetes 提供了一个专门的资源抽象来出色地满足这一需求。
以 Kubernetes 服务的方式访问应用程序
部署在 Kubernetes Pod 中的容器会收到指定的互联网协议 (IP) 地址，但各种生命周期操作可能会更改这些地址。这使得确保其他组件可以定位（并连接到）容器变得特别具有挑战性。为了解决这个问题——这里没有双关语的意思——Kubernetes 提供了一个定义的服务资源，可以自动管理这种连接。
开发人员可以定义与 Pod 关联的 Kubernetes 服务，并指定可以访问它们的服务名称。根据配置这些服务时使用的服务类型，可以以多种方式建立和实施连接。常用的 Kubernetes 服务 类型包括 ClusterIP、NodePort 和 LoadBalancer。
ClusterIP
如果服务资源定义没有定义服务类型，则默认选择 ClusterIP。此服务类型会提示 Kubernetes 创建一个虚拟集群 IP 地址，用于 Pod 连接。但是，虚拟集群 IP 地址只能在集群内部路由。因此，ClusterIP 服务最适合用于需要相互暴露仅限内部应用程序端点的用例。
NodePort
启用对服务的外部访问的最简单方法是使用 NodePort 服务类型。NodePort 在集群中的每个节点上打开一个指定的端口。底层 ClusterIP 用于路由连接到暴露的节点端口的客户端。
NodePort 服务类型有优点和缺点。从积极的方面来看，NodePort 有效地为集群外部的应用程序提供了通信。从消极的方面来看，服务必须使用有限的端口范围（默认情况下，在 30000 到 32767 范围内），并且只能将单个端口映射到单个服务。还需要注意的是：如果客户端连接所通过的节点的主机 IP 地址或虚拟机发生更改，则必须更新该信息。
LoadBalancer
LoadBalancer 服务类型通常在云环境中使用，它可以自动配置 Kubernetes 集群外部的负载均衡器。使用 LoadBalancer 可以干净利落地避开临时 IP 地址的问题，同时完全支持外部应用程序的网络访问。但用户请注意：这种服务类型可能会因在基于云的负载均衡器和 Ingress Controller 之间增加额外的跃点而增加云提供商的成本。
使用 Ingress Controllers 克服限制
ClusterIP、NodePort 和 LoadBalancer 提供了在某些情况下适用于建立对服务的外部访问的有用方法。话虽如此，这些 Kubernetes 网络选项中的每一个的局限性都理所当然地让许多应用程序开发人员寻找替代方案。
Ingress 资源抽象
Kubernetes 原生的 Ingress 资源抽象暴露了 HTTP 和 HTTPS 端点，并允许定义控制流量路由的规则。这种技术非常适合应用程序开发人员和 DevOps 团队，因为 Ingress 资源使得可以使用单个外部端点、负载均衡器或两者同时暴露多个服务。采用这种方法，团队可以制定主机、前缀和其他规则，以根据自己的偏好将流量路由到定义的服务资源。
Ingress 资源抽象增强了服务资源功能，以更灵活地实现外部访问。但工作尚未完成：仅定义 Ingress 资源只会发送网络配置请求。还需要另一个组件来完成允许从 Kubernetes 外部访问服务的工作。
Ingress Controllers
当需要处理 Ingress 资源请求时，Ingress Controllers 会处理入站请求，并根据手头的具体技术生成必要的路由规范。在常见用例中，各种 Ingress Controllers 都安装在 Kubernetes 集群中，可以在其中选择和部署它们，以根据需要处理每个请求。
一些流行的 Ingress Controllers 示例包括：
- Traefik: 它被认为是一个简单且可靠的开源 Kubernetes Ingress Controller，专为将 Kubernetes 与外部应用程序连接而设计。
- AWS ALB: 这个常用的 Ingress Controller 利用 AWS Application Load Balancers 来处理 Ingress 资源请求。
- Nginx: 此控制器使用开源 Nginx 来实现 Ingress 资源。
选择 Ingress Controller
开发人员在选择 Ingress Controllers 时不会有错失良机的风险：可以将多个选项部署到 Kubernetes，并使用最适合每个任务的选项。话虽如此，团队在选择 Ingress Controllers 时需要考虑一些关键因素。支持基于客户权重定义进行流量拆分的工具为开发人员提供了更广泛的选择。利用灵活的路由定义、基于名称和路径的路由、优先级路由和自定义资源定义 (CRD) 的能力也值得关注。从安全角度来看，最好支持 Let's Encrypt 和自动化证书管理。
但最重要的是，开发团队应识别并实施最适合其用例的 Ingress Controllers。制定计划并正确部署 Ingress Controllers 将使在应用程序开发中发挥 Kubernetes 的全部潜力变得更加简单，并且无需在网络方面投入不必要的时间和资源。
评论已关闭。