k8s教程（service篇）-ingress7层路由机制

k8s教程（service篇）-ingress 7层路由机制

作者：杨林伟

次浏览

次

2023-2-23

编辑推荐:

本文主要介绍了ingress概念、案例、ingress资源对象配置、 ingress策略配置及ingress的TLS安全设置相关内容。希望对你的学习有帮助。
本文来自于CSDN，由Linda编辑、推荐。

01 引言

在前面，我们知道Service的表现形式为IP地址和端口号（ClusterIP:Port），即工作在TCP/IP层。而对于基于HTTP的服务来说，不同的URL地址经常对应到不同的后端服务或者虚拟服务器（Virtual Host），这些应用层的转发机制仅通过Kubernetes的Service机制是无法实现的。

所以Kubernetes从1.1版本开始引入Ingress资源对象，用于将Kubernetes集群外的客户端请求路由到集群内部的服务上，同时提供7层（HTTP和HTTPS）路由功能。

02 ingress概念

Kubernetes 使用了一个Ingress策略定义和一个具体提供转发服务的Ingress Controller，两者结合，实现了基于灵活Ingress策略定义的服务路由功能。

如果是对Kubernetes集群外部的客户端提供服务，那么Ingress Controller实现的是类似于边缘路由器（Edge Router）的功能。需要注意的是，Ingress只能以HTTP和 HTTPS提供服务，对于使用其他网络协议的服务，可以通过设置Service的类型 type为NodePort或LoadBalancer对集群外部的客户端提供服务。

2.1 简单例子

使用Ingress进行服务路由时，Ingress Controller基于Ingress规则将客户端请求直接转发到Service对应的后端Endpoint（Pod）上，这样会跳过kube-proxy设置的路由转发规则，以提高网络转发效率，下图是一个典型的HTTP层路由的例子：

其中:

对http:/mywebsite.com/api的访问

将被路由到后端名为api的Service上；

对http:/mywebsite.com/web的访问

将被路由到后端名为web的Service上；

对http:/mywebsite.com/docs的访问

将被路由到后端名为docs的Service上。

03 完整案例

下面先通过一个完整的例子对Ingress Controller的部署、Ingress策略的配置，以及客户端如何通过Ingress Controller访问服务对Ingress的原理和应用进行说明。

3.1 部署ingress controller

Ingress Controller需要实现基于不同HTTP URL向后转发的负载分发规则，并可以灵活设置7层负载分发策略。目前Ingress Controller已经有许多实现方案，包括Nginx、HAProxy、Kong、Traefik、Skipper、Istio等开源软件的实现，以及公有云GCE、Azure、AWS等提供的Ingress应用网关，用户可以参考官方网站根据业务需求选择适合的Ingress Controller。

本例基于Nginx提供的Ingress Controller进行说明。

在Kubernetes中，Ingress Controller 会持续监控 API Server 的 /ingress 接口 (即用户定义的到后端服务的转发规则)的变化。当/ingress接口后端的服务信息发生变化时，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的定义如下：

# nginx-ingress-controller.yaml
apiVersion: v1
kind: Namespace
metadata:
name: nginx-ingress

ServiceAccount的定义如下：

apiVersion: v1
kind: ServiceAccount
metadata:
name: nginx-ingress
namespace: nginx-ingress

RBAC相关资源的定义如下：

kind: ClusterRole
apiVersion: rbac.
authorization.k8s.io/v1
metadata:
	name: nginx-ingress
rules:
- apiGroups:
  - ""
  resources:
    - services
	- endpoints
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - ""
  resources:
  - secrets
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - ""
  resources:
  - configmaps
  verbs:
  - get
  - list
  - watch
  - update
  - create
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - list
  - watch
- apiGroups:
  - ""
  resources:
  - events
  verbs:
  - create
  - patch
  - list
- apiGroups:
  - extensions
  resources:
  - ingresses
  verbs:
  - list
  - watch
  - get
- apiGroups:
  - "extensions"
  resources:
  - ingresses/status
  verbs:
  - update
- apiGroups:
  - k8s.nginx.org
  resources:
  - virtualservers
  - virtualserverroutes
  - globalconfigurations 
  - transportservers
  - policies
  verbs:
  - list
  - watch
  - get
- apiGroups:
  - k8s.nginx.org
  resources:
  - virtualservers/status
  - virtualserverroutes/status
  verbs:
  - update

---
kind: ClusterRoleBinding
apiversion: 
rbac.authorization.k8s.io/v1
metadata:
	name: nginx-ingress
subjects:
- kind: ServiceAccount
  name:nginx-ingress
  namespace: nginx-ingress 
  roleRef:
	kind: ClusterRole
	name: nginx-ingress
	apiGroup: rbac.authorization.k8s.io

Secret的定义如下：

apiVersion: v1
kind: Secret
metadata: 
	name: default-server-secret
	namespace: nginx-ingress 
type: Opaque
data:
	tls.secret:
		xxx...
	tls.key:
		xxxx...

ConfigMap的定义如下：

kind: ConfigMap
apiVersion: v1
metadata:
	name: nginx-config
	namespace: nginx-ingress 
data:

Deployment的定义如下：

apiVersion: apps/v1
kind: Deployment
metadata:
	name: nginx-ingress
	namespace: nginx-ingress 
spec:
	replicas: 1
	selector:
		matchLabels:
			app: nginx-ingress
	template:
		metadata:
			labels:
				app: nginx-ingress
	spec:
		nodeSelector:
		role: ingress-nginx-controller 
		serviceAccountName: nginx-ingress 
		containers:
		- image: nginx/nginx-ingress:1.7.2 
		  imagePullPolicy: IfNotPresent 
		  name: nginx-ingress
		  ports:
		  - name: http
		    containerPort: 80
		    hostPort: 80
		  - name: https
		    containerPort: 443
		    hostPort: 443
		  securityContext:
		    allowPrivilegeEscalation: true 
		    runAsUser: 101 #nginx 
		    capabilities:
		      drop:
			  - ALL
			  add:
			  - NET_BIND_SERVICE
		   env:
		   - name: POD_NAMESPACE 
		     valueFrom:
		       fieldRef:
		   fieldPath: metadata.namespace
		   - name: POD_NAME 
		     valueFrom:
			   fieldRef:
	fieldPath: metadata.name
		   args:
			 - -nginx-configmaps=$(POD
 NAMESPACE)/nginx-config
		     - -default-server-tls-secret=$
(POD NAMESPACE)/default-server-secret

通过kubectl create命令创建nginx-ingress-controller:

查看nginx-ingress-controller容器，确认其正常运行:

用curl访问Nginx Ingress Controller所在宿主机的80端口，验证其服务是否正常，在没有配置后端服务时Nginx会返回404应答：

3.2 创建ingress策略

本例对域名mywebsite.com的访问设置Ingress策略，定义对其/demo路径的访问转发到后端webapp Service的规则:

# mywebsite-ingress.yaml
apiversion: networking.k8s.io/v1 
kind: Ingress
metadata:
	name: mywebsite-ingress
spec:
	rules:
	- host: mywebsite.com
	http:
		paths:
		- path: /demo
		  pathType: ImplementationSpecific 
		  backend:
		  	service:
		    	name: webapp
				port:
		number: 8080

通过该Ingress定义设置的效果：客户端对目标地址 http://mywebsite.com/demo的访问将被转发到集群内的服务“webapp”上，完整的URL为“http://webapp:8080/demo”。

在Ingress策略生效之前，需要先确保webapp服务正确运行。同时注意Ingress中对路径的定义需要与后端webapp服务提供的访问路径一致，否则将被转发到一个不存在的路径上，引发错误。

创建：

一旦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的转发规则的正确配置:

3.3 客户端通过Ingress Controller访问后端webapp服务

由于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/的页面内容。

或

04 ingress资源对象配置

4.1 定义

一个ingress资源对象的定义如下：

apiversion: networking.k8s.io/v1 
kind: Ingress
metadata:
	name: mywebsite-ingress 
spec:
	rules:
	- host: mywebsite.com
	  http:
	    paths:
	    - path: /demo
	      pathType: ImplementationSpecific 
	      backend:
	        service:
	          name: webapp
	          port:
	            number: 8080

Ingress资源主要用于定义路由转发规则，可以包含多条转发规则的定义，通spec.rules进行设置。下面对其中的关键配置进行说明。

4.2 规则（rules）相关设置

规则 (rules）相关设置如下：

Ingress Controller将根据每条rule中path定义的URL路径将客户端请求转发到backend定义的后端服务上。

如果一个请求同时被在Ingress中设置的多个URL路径匹配，则系统将以最长的匹配路径为优先。如果有两条同等长度的匹配路径，则精确匹配类型(Exct) 优先于前缀匹配类型(Prefix)。

4.3 后端（Backend）设置

后端通常被设置为目标服务（Service），通常还应该为不匹配任何路由规则 (rule)的请求设置一个默认的后端，以返回HTTP 404响应码来表示没有匹配的规则。

默认的后端服务可以由Ingress Controller提供，也可以在Ingress资源对象中设置。

另外，如果后端不是以Kubernetes的Service提供的，则也可以设置为提供服务的资源对象，在这种情况下使用resource字段进行设置。例如，下例中的Ingress设置的后端地址为通过CRD“StorageBucket”定义的某个服务，同时设置为默认的后端：

apiversion: networking.k8s.io/v1 
kind: Ingress
metadata:
	name: ingress-resource-backend 
spec:
	defaultBackend:
		resource:
		apiGroup: k8s.example.com 
		kind: StorageBucket
		name: static-assets
rules:
- http:
    paths:
    - path: /icons
    pathType: ImplementationSpecific 
	  backend:
		resource:
		apiGroup: k8s.example.com 
		kind: StorageBucket
		name: icon-assets

通过这个Ingress的定义，客户端对路径/icons的访问将会被路由转发到后端名为“icon-assets”的StorageBucket服务上。不匹配任何规则的请求则侧被路由转发到默认的后端（defaultBackend）上。

4.4 路径类型（pathType）

对于每条规则（rule）中的路径（path），都必须设置一个相应的路径类型，目前支持以下3种类型。

ImplementationSpecific：系统默认，由IngressClass控制器提供具体实现；

Exact：精确匹配URL路径，区分大小写。

Prefix：匹配URL路径的前缀，区分大小写，路径由“/”符号分隔为一个个元素，匹配规则为逐个元素进行前缀匹配。如果路径中的最后一个元素是请求路径中最后一个元素的子字符串，则不会判断为匹配，例如/foo/bar是路径/foo/bar/baz的前缀，但不是路径/foo/barbaz的前缀。

如表所示是常见的路径类型匹配规则示例:

在某些情况下，Ingress中的多个路径都会匹配一个请求路径。在这种情况下，将优先考虑最长的匹配路径。如果两个匹配的路径仍然完全相同，则Exct类型的规则优先于Prefix类型的规则生效。

4.5 host通配符设置

在规则(rule)中设置的host用于匹配请求中的域名（虚拟主机名），设置为完整的字符串表示精确匹配，例如：“foo.bar.com”。

Kubernetes从1.18版本开始支持为host设置通配符“*”，例如“*.foo.com”。

精确匹配要求HTTP请求头中host参数的值必须与Ingress host设置的值完全一致 ;

通配符匹配要求HTTP请求头中host参数的值需要与Ingress host设置的值的后缀一致，并且仅支持一层DNS匹配。

下面是常见的一些host通配符匹配规则示例：

ingress host 配置请求头中的host值是否匹配

*.foo.com bar.foo.com 否

*.foo.com baz.bar.foo.com 否，不是一层DNS匹配

*.foo.com foo.com 否，不是一层DNS匹配

下例中的 Ingress包含精确匹配host"foo.bar.com" 和通配符匹配 host"*.foo.com"两条规则:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
	name: ingress-wildcard-host
spec:
	rules:
	  - host: "foo.bar.com"
		http:
			paths:
			- pathType: Prefix
			  path: "/bar"
			  backend:
			    service:
				name: service1
				port:
				number: 80
	  - host: "*foo.com"
	    http:
			paths:
			- pathType: Prefix
			  path: "/foo"
			  backend:
				 service:
				name: service2
				port:
				number: 80

4.6 ingressClassName和ingressClass资源对象

在一个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和一组参数：

apiversion: networking.k8s.io/v1 
kind: Ingressclass
metadata:
	name: external-lb
spec:
	controller:example.com
/ingress-controller 
	parameters:
		apiGroup: k8s.example.com 
		kind: IngressParameters 
		name: external-lb

然后在Ingress资源对象的定义中通过ingressClassName字段引用该IngressClass，标明使用其中指定的Ingress Controller和相应的参数:

apiversion: networking.
k8s.io/v1 
kind: Ingress
metadata: 
	name: example-ingress 
spec:
	ingressclassName: external-lb 
		rules:
		- host: "*example.com"
		  http:
		    paths:
		    - path: /example
		      pathType: Prefix
		      backend:
			  service:
			name: example-service 
			port:
			number: 80

05 ingress策略配置

为了实现灵活的路由转发策略，Ingress策略可以按多种方式进行配置，下面对几种常见的Ingress转发策略进行说明。

5.1 转发到单个后端服务

基于这种设置，客户端发送到Ingress Controller的访问请求都将被转发到后端的唯一服务，在这种情况下，Ingress无须定义任何rule，只需设置一个默认的后端服务(defaultBackend)。

通过如下所示的设置，对Ingress Controller的访问请求都将被转发到 “myweb：8080”这个服务：

# ingress-single
-backend-service.yaml 
apiversion: networking.
k8s.io/v1
kind: Ingress
metadata:
	name: test-ingress
spec:
	defaultBackend:
		service:
		name: webapp
		port:
		number: 8080

通过kubectl create命令创建后，查看ingress详情，可以看到系统为其设置了正确的后端目标地址：

5.2 将同一域名的不同URL路径转发到不同的服务(Simple Fanout)

这种配置常用于一个网站通过不同的路径提供不同的服务的场景，例如/web 表示访问Web页面，/api表示访问API接口，对应到后端的两个服务，只需在Ingress规则定义中设置将同一域名的不同URL路径转发到不同的后端服务，如图所示：

通过如下所示的设置，对"mywebsite.com/web"的访问请求将被转发到"web- service:80"服务,对"mywebsite.com/api"的访问请求将被转发到"api-service: 80"服务:

# ingress-simple-fanout.yaml 
apiversion: networking.k8s.io/v1 
kind: Ingress
metadata:
	name: simple-fanout-example
spec:
	rules:
	- host: mywebsite.com
	  http:
	    paths:
	    - path: /web
     	  pathType: ImplementationSpecific 
	      backend:
		    service:
				name: web-service
				port:
			number: 8080
		- path: /api
		  pathType: ImplementationSpecific
		  backend:
			service:
			name: api-service
			port:
		number: 8081

通过kubectl create创建之后，查看ingress详情，可以看到系统为不同的path设置了转发规则：

5.3 将不同的域名（虚拟主机名）转发到不同的服务

这里指基于host域名的Ingress规则将客户端发送到同一个IP地址的HTTP请求，根据不同的域名转发到后端不同的服务，例如foo.bar.com域名由service1提供服务，bar.foo.com域名由service2提供服务，如图所示：

通过如下所示的设置，请求头中host=foo.bar.com的访问请求将被转发到“service1:80”服务，请求头中host=bar.foo.com的访问请求将被转发到 “service2:80”服务：

apiVersion: networking.k8s.io/v1 
kind: Ingress
metadata:
	name: name-virtual-host-ingress
spec:
	rules:
	- host: foo.bar.com
	  http:
	    paths:
	    - pathType: Prefix
	      path: "/"
	      backend:
	 		service:
			  name: service1
			  port:
			    number: 80
	- host: bar.foo.com
	  http:
		paths:
		- pathType: Prefix
		  path:
		  backend:
		  service:
		  	name: service2
			port:
			  number: 80

5.4 不使用域名的转发规则

如果在Ingress中不定义任何host域名，Ingress Controller则将所有客户端请求都转发到后端服务。

例如下面的配置为将"<ingress-controller-ip>/demo"的访问请求转发到"webapp:8080/demo"服务:

apiversion: networking.k8s.io/v1 
kind: Ingress
metadata:
	name: test-ingress
spec:
	rules:
	- http:
	  paths:
	    path: /demo
	    pathType: Prefix
	    backend:
	      service:
	        name: webapp
	        port:
	          number: 8080

06 ingress的TLS安全设置

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的证书和私钥，例如：

apiVersion: v1
kind: Secret
metadata:
	name: testsecret-tls
	namespace: default
data:
	tls.crt: base64 encoded cert 
	tls.key: base64 encoded key 
type: kubernetes.io/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配置进行说明，步骤如下：

创建自签名的密钥和SSL证书文件；

将证书保存到Kubernetes的Secret资源对象中；

在Ingress资源中引用该Secret。

6.1 生成秘钥和证书

下面通过OpenSSL工具生成密钥和证书文件，将参数-subj中的/CN设置为host全限定域名(FQDN) “mywebsite.com”:

通过以上命令将生成tls.key和tls.crt两个文件。

6.2 创建secret资源对象

然后根据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命令进行创建

# mywebsite-ingress-secret.yaml 
apiVersion: v1
kind: Secret
metadata:
	name: mywebsite-ingress-secret 
type: kubernetes.io/tls 
data:
	tls.crt:
		MIIDAzCC.......
	tls.key:
		MIIEV......

然后使用kubectl create命令创建即可。

6.3 多个域名的配置

如果需要配置TLS的host域名有多个，例如前面第3种Ingress策略配置方式，则SSL证书需要使用额外的一个x509 v3配置文件辅助完成，在[alt_names]段中完成多个DNS域名的设置。

首先编写openssl.cnf文件，内容如下：

[req]
req_extensions = v3_req
distinguished_name = 
req_distinguished_name 
[req distinguished name]
[v3 req]
basicConstraints = CA:FALSE
keyusage = nonRepudiation,
digitalSignature,keyEncipherment 
subjectAltName = @alt_names 
[alt names]
DNS.1 = mywebsite.com 
DNS.2 = mywebsite2.com

接着使用OpenSSL工具完成密钥和证书的创建，生成自签名CA证书：

# openssl genrsa -out ca.key 2048
Generating RSA private key,2048
 bit long modulus (2 primes)
·······················++++++++++++
············++++++++++++
e  is  65537(0x10001)

# openssl req -x509 -new -nodes -key ca.
key -days 5000 -out ca.crt
 -subj "/CN=mywebsite.com"

基于openssl.cnf和CA证书生成Ingress TLS证书:

# openssl genrsa -out ingress.key 2048
Generating RSA private key,2048
 bit long modulus (2 primes)
·······················++++++++++++
············++++++++++++
e	is	65537(0x10001)

# openssl req -new -key ingress.
key -out ingress.csr -subj 
"/CN=mywebsite.com" -config openss1.cnf

# openssl x509 -req -in ingress.
csr -CA ca.crt -CAkey ca.key 
-CAcreateserial -out ingress.crt 
-days 5000 -extensions v3 req 
-extfile openssl.cnf
Signature ok
subject=/CN=mywebsite.com
Getting CA Private Key

然后根据ingress.key和ingress.crt文件创建secret资源对象，同样可以通过 kubectl create secret tls命令或YAML文件生成。这里通过命令行直接生成:

$ kubectl create secret tls mywebsite
-ingress-secret 
--key ingress.key --cert ingress.crt
secret "mywebsite-ingress-secret"created

至此，Ingress的TLS证书和密钥就成功创建到Secret对象中了, 下面创建Ingress对象，在tls段引用刚刚创建好的Secret对象：

# mywebsite-ingress-tls.yaml 
apiVersion: networking.k8s.io/v1 
kind: Ingress
metadata:
	name: mywebsite-ingress-tls 
spec:
	tls:
	- hosts:	
	  - mywebsite.com
	  secretName: mywebsite-ingress-secret 
	rules:
	- host:	mywebsite.com
	  http:
	    paths:
	    - path:	/demo
	      pathType: Prefix
	      backend:
			service:
				name: webapp
				port:
			number:	8080

成功创建该Ingress资源之后，就可以通过HTTPS安全访问Ingress了。

以使用curl命令行工具为例，访问Ingress Controller的URL"https:/192.168.18.3/demo/"：

次浏览

次

聊聊云原生和微服务架构

Serverless：微服务架构的终极模式

如何实现微服务架构下的分布式事务？

微服务下的数据架构设计