Kubernetes Ingress简单入门

做者：Nick Ramirez

原文连接：https://thenewstack.io/kubernetes-ingress-for-beginners/

本文转载自Rancher Labs

不知道你是否注意到一个奇怪的现象，尽管Kubernetes Ingress API仍然处于beta状态，可是已经有许多公司使用它来暴露Kubernetes服务。从事相关项目的工程师表示，Kubernetes Ingress API愈来愈有可能摘下其beta标签。实际上，Kubernetes Ingress API处于beta状态已经持续了几年的时间，准确来讲，是在2015年秋季开始进入该阶段的。可是，漫长的beta阶段可让Kubernetes贡献者有时间来完善规范并使其与已经搭建好的实施软件（HAProxy、NGINX、Traefik等）保持一致，从而使API标准化以反映最多见而且有需求的功能。

随着该功能GA的临近，那么如今应该是一个合适的时机能够帮助新手快速了解Ingress的工做方式。简而言之，Ingress是一个规则，能够绘制出在集群内部的服务如何弥合鸿沟，暴露到客户可使用它的外部世界。同时，称为Ingress controller的代理在集群网络的边缘进行侦听（监视要添加的规则），并将每一个服务映射到特定的URL路径或域名以供公众使用。在Kubernetes维护者开发API的同时，其余开源项目也实现了Ingress Controller并为其代理添加了本身的独特功能。

在本文中，我将介绍这些概念，并帮助你了解Ingress模式背后的驱动力。

路由问题

在Kubernetes中建立Pod时，须要为其分配selector标签，如Deployment manifest的如下片断所示：

该Deployment建立了运行Docker镜像my-app的三个副本，并为其分配app=foo标签。除了直接访问Pod，一般将它们分组在Service下，这使它们能够在单个集群IP地址上使用（可是只能在同一集群中使用）。Service充当抽象层，隐藏了pod的周期短暂特性，能够随时增长或减小或替换它们。它还能够执行基本的循环负载均衡。

例如，如下Service定义收集全部带有selector标签app = foo的Pod，并在其中平均路由流量。

可是，只能从集群内部以及运行在附近的其余Pod访问此服务。Kubernetes Operator正在努力解决如何为集群外部的客户端提供访问权限。该问题在早期就已经出现，而且将两种机制直接集成到Service规范中进行处理。编写service manifest时，包括一个名为type的字段，该字段的值为NodePort或LoadBalancer。这是一个将类型设置为NodePort的示例：

NodePort类型的服务使用起来很简单。本质上，这些服务但愿Kubernetes API为他们分配一个随机的TCP端口，并将其暴露到集群以外。这样作的方便之处在于，客户端可使用该端口将集群中的任何节点做为目标，而且他们的消息将被中转到正确的位置。这就相似于你能够拨打美国境内的任何电话，而接听电话的人都会确保为你转接到合适的人。

缺点在于，该端口的值必须介于30000到32767之间，虽然这个范围安全地避开了经常使用端口地范围，可是与常见的HTTP端口80和HTTPS 443相比，该端口显然不是很标准。此外，随机性自己也是一个障碍，由于它意味着你事先不知道值是什么，这使得配置NAT、防火墙规则更具挑战性——尤为是须要为每项服务设置不一样的随机端口。

另外一个选项是将类型设置为LoadBalancer。可是，这有一些前提条件——仅当你在GKE或EKS之类的云托管环境中运行而且可使用该云供应商的负载均衡器技术时，它才有效，由于它是自动选择并配置的。其缺点是比较昂贵，由于使用这种类型的服务会为每一个服务启动一个托管的负载均衡器以及一个新的公共IP地址，这会产生额外的费用。

Ingress路由

分配一个随机端口或外部负载均衡器是很容易操做的，但也带来了独特的挑战。定义许多NodePort服务会形成随机端口混乱，而定义许多负载均衡器服务会致使须要支付比实际所需更多的云资源费用。这些状况不可能彻底避免，但也许能够减小它的使用范围，甚至你只须要分配1个随机端口或1个负载均衡器就可以暴露许多内部服务。所以，这一平台须要一个新的抽象层，该层能够在入口点（entrypoint）后面整合许多服务。

那时，Kubernetes API引入了一种称为Ingress的新型manifest，它为路由问题提供了新的思路。它的工做方式是这样的：你编写一个Ingress manifest，声明你但愿客户端如何路由到服务。manifest实际上并不自行执行任何操做，你必须将Ingress Controller部署到你的集群中，以监视这些声明并对其执行操做。

与其余任何应用程序同样，Ingress controller是Pod，所以它们是集群的一部分而且能够看到其余Pod。它们是使用在市场上已经发展了多年的反向代理搭建的，所以，你能够选择HAProxy Ingress Controller、NGINX Ingress Controller等。底层代理为其提供了第7层路由和负载均衡功能。不一样的代理将本身的功能集放到表中。例如，HAProxy Ingress Controller不须要像NGINX Ingress Controller那样频繁地从新加载，由于它为服务器分配了slot，并使用Runtime API在运行时填充slot。这使得该Ingress Controller拥有更好的性能。

Ingress Controller自己位于集群内部，与其余Kubernetes Pod同样，也容易受到同一“监狱”的“监禁”。你须要经过NodePort或LoadBalancer类型的服务将它们暴露到外部。可是，如今你只有一个入口点，全部流量都将经过此处：一个服务链接到一个Ingress Controller，Ingress Controller依次链接到许多内部Pod。Controller具备检查HTTP请求的功能，能够根据其发现的特征（例如URL路径或域名）将客户端定向到正确的Pod。

参考这个Ingress的示例，该示例定义了URL路径/foo应该如何链接到名为foo-service的后端服务，而URL路径/bar被定向到名称为bar-service的服务。

如上文所示，你依旧须要为你的Pod设置服务，可是你不须要在Pod上设置类型字段，由于路由和负载均衡将由Ingress层处理。服务的做用被简化为以通用名称对Pod进行分组。最终，两个路径，/foo和/bar，将由一个公共IP地址和域名提供服务，例如example.com/foo 和 example.com/bar 。本质上，这是API网关模式，在API网关中，单个地址将请求路由到多个后端应用程序。

添加Ingress Controller

Ingress manifest的声明式方法是你能够指定所需的内容，而无需知道如何实现。Ingress Controller的工做之一是执行，它须要监控新的ingress规则并配置其底层代理以制定相应的路由。

你可使用Kubernetes包管理工具Helm安装HAProxy Ingress Controller。首先，经过下载Helm二进制文件并将其复制到PATH环境变量中包含的文件夹（例如/usr/local/bin/）中来安装Helm。接下来，添加HAProxy Technologies Helm库，并使用helm install命令部署Ingress Controller。

经过运行命令kubectl get service列出全部正在运行的服务来验证是否已建立Ingress Controller。

HAProxy Ingress Controller在集群的pod中运行，并使用NodePort类型的Service资源发布对外部客户端的访问。在上面显示的输出中，你能够看到为HTTP选择了端口31704，为HTTPS选择了端口32255。你还能够在端口30347上查看HAProxy信息统计页面。HAProxy Ingress Controller会提供有关流经它的流量的详细指标，所以你能够更好地观察到进入集群的流量。

在controller建立类型为NodePort的服务时，这意味着须要分配一个随机的端口而且端口编号每每很高，可是如今你只需管理几个此类端口，也就是只需管理链接到Ingress Controller的端口，无需再为每一个服务建立一个端口。你也能够将其配置为使用LoadBalancer类型，只要在云端进行操做便可。它看起来以下：

整体而言，不须要管理太多Ingress Controller。安装后，它基本上会在后台执行其工做。你只须要定义Ingress manifest，controller就会当即将它们链接起来。Ingress manifest的定义与引用的服务有所区别，所以你能够控制什么时候暴露服务。

结 论

Ingress资源经过容许API网关样式的流量路由，整合了外部客户端如何访问Kubernetes集群中的服务。代理服务经过公共入口点（entrypoint）进行中转，你可使用intent-driven、YAML声明来控制什么时候以及如何公开服务。

当Ingress API这一功能GA以后，你必定会看到这种模式变得愈来愈流行。固然，可能产生一些细微的变化，主要是为了使API与现有controller中已经实现的功能保持一致。其余改进可能会指导controller如何继续发展以符合Kubernetes维护者的愿景。总而言之，如今是开始使用此功能的好时机！