根据前面对Service概念的说明，我们知道Service的表现形式为IP地址和端口号（ClusterIP：Port），即工作在TCP/IP层。而对于基于HTTP的服务来说，不同的URL地址经常对应到不同的后端服务或者虚拟服务器（Virtual Host），这些应用层的转发机制仅通过Kubernetes的Service机制是无法实现的。Kubernetes从1.1版本开始引入Ingress资源对象，用于将Kubernetes集群外的客户端请求路由到集群内部的服务上，同时提供7层（HTTP和HTTPS）路由功能。Ingress在Kubernetes 1.19版本时达到v1稳定版本。
Kubernetes使用了一个Ingress策略定义和一个具体提供转发服务的Ingress Controller，两者结合，实现了基于灵活Ingress策略定义的服务路由功能。如果是对Kubernetes集群外部的客户端提供服务，那么Ingress Controller实现的是类似于边缘路由器（Edge Router）的功能。需要注意的是，Ingress只能以HTTP和HTTPS提供服务，对于使用其他网络协议的服务，可以通过设置Service的类型（type）为NodePort或LoadBalancer对集群外部的客户端提供服务。
使用Ingress进行服务路由时，Ingress Controller基于Ingress规则将客户端请求直接转发到Service对应的后端Endpoint（Pod）上，这样会跳过kube-proxy设置的路由转发规则，以提高网络转发效率。
图4.7显示了一个典型的HTTP层路由的例子。
图4.7 一个典型的HTTP层路由的例子
其中：
◎ 对http：//mywebsite.com/api的访问将被路由到后端名为api的Service上；
◎ 对http：//mywebsite.com/web的访问将被路由到后端名为web的Service上；
◎ 对http：//mywebsite.com/docs的访问将被路由到后端名为docs的Service上。
下面先通过一个完整的例子对Ingress Controller的部署、Ingress策略的配置，以及客户端如何通过Ingress Controller访问服务对Ingress的原理和应用进行说明，然后对Ingress资源的概念、策略配置、TLS安全设置进行详细说明。
Ingress Controller需要实现基于不同HTTP URL向后转发的负载分发规则，并可以灵活设置7层负载分发策略。目前Ingress Controller已经有许多实现方案，包括Nginx、HAProxy、Kong、Traefik、Skipper、Istio等开源软件的实现，以及公有云GCE、Azure、AWS等提供的Ingress应用网关，用户可以参考官方网站根据业务需求选择适合的Ingress Controller。
在Kubernetes中，Ingress Controller会持续监控API Server的/ingress接口（即用户定义的到后端服务的转发规则）的变化。当/ingress接口后端的服务信息发生变化时，Ingress Controller会自动更新其转发规则。
本例基于Nginx提供的Ingress Controller进行说明。Nginx Ingress Controller可以以Daemonset或Deployment模式进行部署，通常可以考虑通过设置nodeSelector或亲和性调度策略将其调度到固定的几个Node上提供服务。
对于客户端应用如何通过网络访问Ingress Controller，本例中通过在容器级别设置hostPort，将80和443端口号映射到宿主机上，这样客户端应用可以通过URL地址“http：//<NodeIP>：80”或“https：//<NodeIP>：443”访问Ingress Controller。也可以配置Pod使用hostNetwork模式直接监听宿主机网卡的IP地址和端口号，或者使用Service的NodePort将端口号映射到宿主机上。
下面是Nginx Ingress Controller的YAML定义，其中将Pod创建在namespace“nginx-ingress”中，通过nodeSelector“role=ingress-nginx-controller”设置了调度的目标Node，并设置了hostPort将端口号映射到宿主机上供集群外部的客户端访问。该配置文件包含了Namespace、ServiceAccount、RBAC、Secret、ConfigMap和Deployment等资源对象的配置，示例如下。
Namespace的定义如下：
ServiceAccount的定义如下：
RBAC相关资源的定义如下：
Secret的定义如下：
对ConfigMap的定义如下：
对Deployment的定义如下：
通过kubectl create命令创建nginx-ingress-controller：
查看nginx-ingress-controller容器，确认其正常运行：
用curl访问Nginx Ingress Controller所在宿主机的80端口，验证其服务是否正常，在没有配置后端服务时Nginx会返回404应答：
本例对域名mywebsite.com的访问设置Ingress策略，定义对其/demo路径的访问转发到后端webapp Service的规则：
通过该Ingress定义设置的效果：客户端对目标地址http：//mywebsite.com/demo的访问将被转发到集群内的服务“webapp”上，完整的URL为“http：//webapp：8080/demo”。
在Ingress策略生效之前，需要先确保webapp服务正确运行。同时注意Ingress中对路径的定义需要与后端webapp服务提供的访问路径一致，否则将被转发到一个不存在的路径上，引发错误。这里以第1章的webapp服务（使用kubeguide/tomcat-app：v1镜像）为例，假设myweb服务已经部署完毕且正常运行，myweb提供的Web服务的路径也为/demo。
创建上述Ingress资源对象：
一旦Ingress资源成功创建，Ingress Controller就会监控到其配置的路由策略，并更新到Nginx的配置文件中生效。以本例中的Nginx Controller为例，它将更新其配置文件的内容为在Ingress中设定的路由策略。
登录一个nginx-ingress-controller Pod，在/etc/nginx/conf.d目录下可以看到Nginx Ingress Controller自动生成的配置文件default-mywebsite-ingress.conf，查看其内容，可以看到对mywebsite.com/demo的转发规则的正确配置：
由于Ingress Controller容器通过hostPort将服务端口号80映射到了宿主机上，所以客户端可以通过Ingress Controller所在的Node访问mywebsite.com提供的服务。
需要说明的是，客户端只能通过域名mywebsite.com访问服务，这时要求客户端或者DNS将mywebsite.com域名解析到Node的真实IP地址上。
通过curl访问mywebsite.com提供的服务（可以用--resolve参数模拟DNS解析，目标地址为域名；也可以用-H 'Host：mywebsite.com'参数设置在HTTP头中要访问的域名，目标地址为IP地址），可以正确访问到myweb服务/demo/的页面内容。
或
如果需要使用浏览器进行访问，那么需要先在本机上设置域名mywebsite.com对应的IP地址，再到浏览器上进行访问。以Windows为例，修改C：\Windows\System32\drivers\ etc\hosts文件，加入一行记录：
然后在浏览器的地址栏中输入“http：//mywebsite.com/demo/”，就能够访问Ingress提供的服务了，如图4.8所示。
图4.8 通过浏览器访问Ingress服务
一个Ingress资源对象的定义示例如下：
Ingress资源主要用于定义路由转发规则，可以包含多条转发规则的定义，通过spec.rules进行设置。下面对其中的关键配置进行说明。
◎ host（可选配置）：基于域名的访问，客户端请求将作用于指定域名的客户端请求。
◎ http.paths：一组根据路径进行转发的规则设置，每个路径都应配置相应的后端服务信息（服务名称和服务端口号）。只有客户端请求中的host和path都匹配之后，才会进行转发。
◎ backend：目标后端服务，包括服务的名称和端口号。
Ingress Controller将根据每条rule中path定义的URL路径将客户端请求转发到backend定义的后端服务上。
如果一个请求同时被在Ingress中设置的多个URL路径匹配，则系统将以最长的匹配路径为优先。如果有两条同等长度的匹配路径，则精确匹配类型（Exact）优先于前缀匹配类型（Prefix）。
后端通常被设置为目标服务（Service），通常还应该为不匹配任何路由规则（rule）的请求设置一个默认的后端，以返回HTTP 404响应码来表示没有匹配的规则。
默认的后端服务可以由Ingress Controller提供，也可以在Ingress资源对象中设置。
另外，如果后端不是以Kubernetes的Service提供的，则也可以设置为提供服务的资源对象，在这种情况下使用resource字段进行设置。
例如，下例中的Ingress设置的后端地址为通过CRD“StorageBucket”定义的某个服务，同时设置为默认的后端：
通过这个Ingress的定义，客户端对路径/icons的访问将会被路由转发到后端名为“icon-assets”的StorageBucket服务上。不匹配任何规则的请求则被路由转发到默认的后端（defaultBackend）上。
对于每条规则（rule）中的路径（path），都必须设置一个相应的路径类型，目前支持以下3种类型。
◎ ImplementationSpecific：系统默认，由IngressClass控制器提供具体实现。
◎ Exact：精确匹配URL路径，区分大小写。
◎ Prefix：匹配URL路径的前缀，区分大小写，路径由“/”符号分隔为一个个元素，匹配规则为逐个元素进行前缀匹配。如果路径中的最后一个元素是请求路径中最后一个元素的子字符串，则不会判断为匹配，例如/foo/bar是路径/foo/bar/baz的前缀，但不是路径/foo/barbaz的前缀。
如表4.2所示是常见的路径类型匹配规则示例。
表4.2 常见的路径类型匹配规则示例
▼续表
在某些情况下，Ingress中的多个路径都会匹配一个请求路径。在这种情况下，将优先考虑最长的匹配路径。如果两个匹配的路径仍然完全相同，则Exact类型的规则优先于Prefix类型的规则生效。
在规则（rule）中设置的host用于匹配请求中的域名（虚拟主机名），设置为完整的字符串表示精确匹配，例如“foo.bar.com”。Kubernetes从1.18版本开始支持为host设置通配符“*”，例如“*.foo.com”。
精确匹配要求HTTP请求头中host参数的值必须与Ingress host设置的值完全一致。
通配符匹配要求HTTP请求头中host参数的值需要与Ingress host设置的值的后缀一致，并且仅支持一层DNS匹配。
如表4.3所示是常见的一些host通配符匹配规则示例。
表4.3 常见的一些host通配符匹配规则示例
下例中的Ingress包含精确匹配host“foo.bar.com”和通配符匹配host“*.foo.com”两条规则：
在一个Kubernetes集群内，用户可以部署多个不同类型的Ingress Controller同时提供服务，此时需要在Ingress资源上注明该策略由哪个Controller管理。Kubernetes在1.18版本之前，可以在Ingress资源上设置一个名为“kubernetes.io/ingress.class”的annotation进行声明。但annotation的定义没有标准规范，Kubernetes从1.18版本开始引入一个新的资源对象IngressClass对其进行规范定义。在IngressClass中除了可以设置Ingress的管理Controller，还可以配置更加丰富的参数信息（通过parameters字段进行设置）。
例如下面的IngressClass定义了一个名为“example.com/ingress-controller”的Controller和一组参数：
然后在Ingress资源对象的定义中通过ingressClassName字段引用该IngressClass，标明使用其中指定的Ingress Controller和相应的参数：
如果在一个集群中有多个IngressClass资源，则还可以设置某个IngressClass为集群范围内默认的IngressClass，通过设置一个Annotation“ingressclass.kubernetes.io/is-default-class=true”进行标明。这样，如果某个Ingress资源没有通过ingressClassName字段指定需要使用的IngressClass，则系统将自动为其设置默认的IngressClass。
需要注意的是，如果在系统中存在多个默认的IngressClass，则在创建Ingress资源时必须指定ingressClassName，否则系统将无法判断使用哪个默认的IngressClass。管理员通常应确保在一个集群中只有一个默认的IngressClass。
随着IngressClass资源对象的逐步成熟，Annotation“kubernetes.io/ingress.class”将被逐渐弃用。而对IngressClass资源对象的支持需要各个Ingress Controller实现，用户需要持续关注Controller的支持进度，才能明确在新版本的Ingress Controller推出之后如何使用IngressClass。
为了实现灵活的路由转发策略，Ingress策略可以按多种方式进行配置，下面对几种常见的Ingress转发策略进行说明。
基于这种设置，客户端发送到Ingress Controller的访问请求都将被转发到后端的唯一服务，在这种情况下，Ingress无须定义任何rule，只需设置一个默认的后端服务（defaultBackend）。
通过如下所示的设置，对Ingress Controller的访问请求都将被转发到“myweb：8080”这个服务：
通过kubectl create命令创建该Ingress：
查看该Ingress的详细信息，可以看到系统为其设置了正确的后端目标地址：
这种配置常用于一个网站通过不同的路径提供不同的服务的场景，例如/web表示访问Web页面，/api表示访问API接口，对应到后端的两个服务，只需在Ingress规则定义中设置将同一域名的不同URL路径转发到不同的后端服务，如图4.9所示。
图4.9 将同一域名的不同URL路径转发到不同的后端服务
通过如下所示的设置，对“mywebsite.com/web”的访问请求将被转发到“web-service：80”服务；对“mywebsite.com/api”的访问请求将被转发到“api-service：80”服务：
通过kubectl create命令创建该Ingress：
查看该Ingress的详细信息，可以看到系统为不同path设置的转发规则：
这里指基于host域名的Ingress规则将客户端发送到同一个IP地址的HTTP请求，根据不同的域名转发到后端不同的服务，例如foo.bar.com域名由service1 提供服务，bar.foo.com域名由service2提供服务，如图4.10所示。
图4.10 将HTTP请求根据不同的域名（虚拟主机名）转发到后端不同的服务
通过如下所示的设置，请求头中host=foo.bar.com的访问请求将被转发到“service1：80”服务，请求头中host=bar.foo.com的访问请求将被转发到“service2：80”服务：
如果在Ingress中不定义任何host域名，Ingress Controller则将所有客户端请求都转发到后端服务。例如下面的配置为将“<ingress-controller-ip>/demo”的访问请求转发到“webapp：8080/demo”服务：
注意，是否支持不设置host的Ingress策略取决于Ingress Controll的实现。
Kubernetes支持为Ingress设置TLS安全访问机制，通过为Ingress的host（域名）配置包含TLS私钥和证书的Secret进行支持。
Ingress资源仅支持单个TLS端口号443，并且假设在Ingress访问点（Ingress Controller）结束TLS安全机制，向后端服务转发的流量将以明文形式发送。
如果Ingress中的TLS配置部分指定了不同的host，那么它们将根据通过SNI TLS扩展指定的虚拟主机名（这要求Ingress Controller支持SNI）在同一端口进行复用。
TLS Secret中的文件名必须为“tls.crt”和“tls.key”，它们分别包含用于TLS的证书和私钥，例如：
然后，需要在Ingress资源对象中引用该Secret，这将通知Ingress Controller使用TLS加密客户端到负载均衡器的网络通道。用户需要确保在TLS证书（tls.crt）中包含相应host的全限定域名（FQDN）被包含在其CN（Common Name）配置中。
TLS的功能特性依赖于Ingress Controller的具体实现，不同Ingress Controller的实现机制可能不同，用户需要参考各个Ingress Controller的文档。
下面以Nginx Ingress为例，对Ingress的TLS配置进行说明，步骤如下。
（1）创建自签名的密钥和SSL证书文件。
（2）将证书保存到Kubernetes的Secret资源对象中。
（3）在Ingress资源中引用该Secret。
下面通过OpenSSL工具生成密钥和证书文件，将参数-subj中的/CN设置为host全限定域名（FQDN）“mywebsite.com”：
通过以上命令将生成tls.key和tls.crt两个文件。
然后根据tls.key和tls.crt文件创建secret资源对象，有以下两种方法。
方法一：使用kubectl create secret tls命令直接通过tls.key和tls.crt文件创建secret对象。
方法二：编辑mywebsite-ingress-secret.yaml文件，将tls.key和tls.crt文件的内容经过BASE64编码的结果复制进去，使用kubectl create命令进行创建。
如果需要配置TLS的host域名有多个，例如前面第3种Ingress策略配置方式，则SSL证书需要使用额外的一个x509 v3配置文件辅助完成，在[alt_names]段中完成多个DNS域名的设置。
首先编写openssl.cnf文件，内容如下：
接着使用OpenSSL工具完成密钥和证书的创建。生成自签名CA证书：
基于openssl.cnf和CA证书生成Ingress TLS证书：
然后根据ingress.key和ingress.crt文件创建secret资源对象，同样可以通过kubectl create secret tls命令或YAML文件生成。这里通过命令行直接生成：
至此，Ingress的TLS证书和密钥就成功创建到Secret对象中了。
下面创建Ingress对象，在tls段引用刚刚创建好的Secret对象：
通过kubectl create命令创建该Ingress：
成功创建该Ingress资源之后，就可以通过HTTPS安全访问Ingress了。
以使用curl命令行工具为例，访问Ingress Controller的URL“https：//192.168.18.3/demo/”：
如果是通过浏览器访问的，则在浏览器的地址栏输入“https：//mywebsite.com/demo/”来访问Ingress HTTPS服务，浏览器会给出警告信息，如图4.11所示。
图4.11 通过浏览器访问Ingress HTTPS服务的警告信息
单击“继续前往mywebsite.com（不安全）”标签，访问后可看到Ingress HTTPS服务提供的页面，如图4.12所示。
图4.12 使用浏览器访问Ingress HTTPS服务