抱歉,您的浏览器无法访问本站
本页面需要浏览器支持(启用)JavaScript
了解详情 >

Kubernetes 对外服务

image-20220525094307190

概述

Kubernetes 暴露服务的有三种方式:分别为 LoadBlancer Service、NodePort Service、Ingress。

​ 官网对 Ingress 的定义为管理对外服务到集群内服务之间规则的集合,通俗点讲就是它定义规则来允许进入集群的请求被转发到集群中对应服务上,从来实现服务暴露。

​ Ingress 能把集群内 Service 配置成外网能够访问的 URL,流量负载均衡,终止SSL,提供基于域名访问的虚拟主机等等。

LoadBlancer

LoadBlancer Service 是 Kubernetes 结合云平台的组件,如国外 GCE、AWS、国内阿里云等等,使用它向使用的底层云平台申请创建负载均衡器来实现,有局限性,对于使用云平台的集群比较方便。

NodePort

NodePort Service 是通过在节点上暴露端口,然后通过将端口映射到具体某个服务上来实现服务暴露

​ 对于集群来说,随着 Service 的不断增加,需要的端口越来越多,很容易出现端口冲突,而且不容易管理,当然对于小规模的集群服务,还是比较不错的。

Ingress

Ingress 使用开源的反向代理负载均衡器来实现对外暴漏服务,比如 Nginx、Apache、Haproxy等,用的最多的是使用nginx来做的,Nginx Ingress 一般有三个组件组成

ingress

ingress 是kubernetes的一个资源对象,用于编写定义规则。将nginx的配置抽象成一个Ingress对象,当用户每添加一个新的服务,只需要编写一个新的ingress的yaml文件即可

反向代理负载均衡器

​ 通常以Service的Port方式运行,接收并按照ingress定义的规则进行转发,通常为nginx,haproxy,traefik等,本文使用nginx

ingress-controller

​ 监听apiserver,获取服务新增,删除等变化,并结合ingress规则动态更新到反向代理负载均衡器上,并重载配置使其生效

整体结构

以上三者有机的协调配合起来,就可以完成 Kubernetes 集群服务的暴漏

img

Ingress-nginx介绍

Ingress-nginx组成
ingress-nginx-controller

​ 根据用户编写的ingress规则(创建的ingress的yaml文件),动态的去更改nginx服务的配置文件,并且reload重载使其生效(是自动化的,通过lua脚本来实现)

ingress资源对象

将Nginx的配置抽象成一个Ingress对象,每添加一个新的Service资源对象只需写一个新的Ingress规则的yaml文件即可(或修改已存在的ingress规则的yaml文件)

​ Ingress 资源对象是 Kubernetes 内置定义的一个对象,是从 Kuberenets 集群外部访问集群的一个入口,将外部的请求转发到集群内不同的 Service 上,其实就相当于 nginx、haproxy 等负载均衡代理服务器,可能你会觉得我们直接使用 nginx 就实现了,但是只使用 nginx 这种方式有很大缺陷,每次有新服务加入的时候怎么改 Nginx 配置?不可能让我们去手动更改或者滚动更新前端的 Nginx Pod 吧?那我们再加上一个服务发现的工具比如 consul 如何(然后利用consul-template去自动刷新我们的nginx配置)?貌似是可以,对吧?Ingress 实际上就是这样实现的,只是服务发现的功能自己实现了,不需要使用第三方的服务了,然后再加上一个域名规则定义,路由信息的刷新依靠 Ingress Controller 来提供。

ingress flow

注意:这里写的是ingress,但其实是ingress-controller在起作用,这里的路由规则可能是一个域名,或者是一个Path路径,都是可以去做一个路由的匹配

组件说明

  • externalLB : 外部的4层负载均衡器
  • ingress-nginx : nodePort 类型的 service 为 ingress-nginx 的 pod 接入外部流量
  • ingress-nginx : ingress-nginx pod, 负责创建负载均衡
  • Ingress 根据后端 Service 实时识别分类及 IP 把结果生成配置文件注入到 ingress-nginx pod 中
  • site1 : Service 对后端的pod 进行分类(只起分类作用)

Ingress工作原理

Ingress 的实现分为两个部分 Ingress Controller 和 Ingress

​ 截至目前,nginx-ingress 已经能够完成 7/4 层的代理功能(4 层代理基于 ConfigMap,感觉还有改进的空间);Nginx 的 7 层反向代理模式,可以简单用下图表示:

img

  1. Nginx 对后端运行的服务(Service1、Service2)提供反向代理,在配置文件中配置了域名与后端服务 Endpoints 的对应关系。
  2. 客户端通过使用 DNS 服务或者直接配置本地的 hosts 文件,将域名都映射到 Nginx 代理服务器。
  3. 当客户端访问 service1.com 时,浏览器会把包含域名的请求发送给 nginx 服务器,nginx 服务器根据传来的域名,选择对应的 Service,这里就是选择 Service 1 后端服务,然后根据一定的负载均衡策略,选择 Service1 中的某个容器接收来自客户端的请求并作出响应。

过程很简单,nginx 在整个过程中仿佛是一台根据域名进行请求转发的“路由器”,这也就是7层代理的整体工作流程了!

工作原理

对于 Nginx 反向代理做了什么,我们已经大概了解了

​ 在 k8s 系统中,后端服务的变化是十分频繁的,单纯依靠人工来更新nginx 的配置文件几乎不可能,nginx-ingress 由此应运而生,Nginx-ingress 通过监视 k8s 的资源状态变化实现对 nginx 配置文件的自动更新

img

  1. nginx-ingress 模块在运行时主要包括三个主体:NginxController、Store、SyncQueue。
  2. Store 主要负责从 kubernetes APIServer 收集运行时信息,感知各类资源(如 ingress、service等)的变化,并及时将更新事件消息(event)写入一个环形管道。
  3. SyncQueue 协程定期扫描 syncQueue 队列,发现有任务就执行更新操作,即借助 Store 完成最新运行数据的拉取,然后根据一定的规则产生新的 nginx 配置,(有些更新必须 reload,就本地写入新配置,执行 reload),然后执行动态更新操作,即构造 POST 数据,向本地 Nginx Lua 服务模块发送 post 请求,实现配置更新。
  4. NginxController 作为中间的联系者,监听 updateChannel,一旦收到配置更新事件,就向同步队列 syncQueue 里写入一个更新请求。

Ingress解决痛点

动态配置服务

​ 如果按照传统方式,当新增加一个服务时,我们可能需要在流量入口加一个反向代理指向我们新的服务,而使用ingress,只需要配置好ingress,当服务启动时,会自动注册到ingress当中,不需要额外的操作。

减少不必要的Port暴露

​ 我们知道部署k8s时,是需要关闭防火墙的,主要原因是k8s的很多服务会以nodeport方式映射出去,这样对于宿主机来说是非常的不安全的,而ingress可以避免这个问题,只需要将ingress自身服务映射出去,就可代理后端所有的服务,则后端服务不需要映射出去。

安装Ingress-nginx

可以将上面的Ingress理解为在集群的前端加了一个Nginx,用来提供Nginx所能提供的一切功能,例如基于url的反向代理,https认证,用户鉴权,域名重定向等等

img

注意事项

需要注意以下几点

  • Nginx是基于url的,如果没有DNS解析url到集群中任意ip可以考虑hosts文件劫持
  • Nginx的本质也是NodePort的方式暴露给集群外的一个特殊Service
  • Nginx的配置文件根据Ingress的规则自动添加和修改

拉取配置

从GitHub上下载yaml文件:官方地址,注意对应k8s版本

1
wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/main/deploy/static/provider/cloud/deploy.yaml

如果上面地址下载失败,可以使用最后完整的配置文件,如果使用官网的,可能需要换镜像地址,因为官网下载的镜像很大可能会失败

修改镜像资源地址

由于官网镜像国内网络无法下载,所以我们需要修改yaml规约文件中的镜像资源地址。主要修改两个镜像资源如下:

  • registry.k8s.io/ingress-nginx/controller
  • registry.k8s.io/ingress-nginx/kube-webhook-certgen

我们使用阿里云的镜像资源地址阿里云镜像仓库,注意实现需要登录才能进入查找镜像

image-20220712174642666

点进去查看奖项详情

image-20220712174920283

使用阿里云的镜像地址替换掉k8s官网的镜像地址

image-20220712175025973

对于kube-webhook-certgen操作时一样的,只是搜索替换的换成kube-webhook-certgen

image-20220712175140889

编辑配置

注意注释掉 externalTrafficPolicy: Local的配置

image-20220712175351441

完整配置

完整的配置如下,可以直接使用

1
vi deploy.yaml

对照如下deploy.yaml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
apiVersion: v1
kind: Namespace
metadata:
labels:
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
name: ingress-nginx
---
apiVersion: v1
automountServiceAccountToken: true
kind: ServiceAccount
metadata:
labels:
app.kubernetes.io/component: controller
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.2.1
name: ingress-nginx
namespace: ingress-nginx
---
apiVersion: v1
kind: ServiceAccount
metadata:
labels:
app.kubernetes.io/component: admission-webhook
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.2.1
name: ingress-nginx-admission
namespace: ingress-nginx
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
labels:
app.kubernetes.io/component: controller
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.2.1
name: ingress-nginx
namespace: ingress-nginx
rules:
- apiGroups:
- ""
resources:
- namespaces
verbs:
- get
- apiGroups:
- ""
resources:
- configmaps
- pods
- secrets
- endpoints
verbs:
- get
- list
- watch
- apiGroups:
- ""
resources:
- services
verbs:
- get
- list
- watch
- apiGroups:
- networking.k8s.io
resources:
- ingresses
verbs:
- get
- list
- watch
- apiGroups:
- networking.k8s.io
resources:
- ingresses/status
verbs:
- update
- apiGroups:
- networking.k8s.io
resources:
- ingressclasses
verbs:
- get
- list
- watch
- apiGroups:
- ""
resourceNames:
- ingress-controller-leader
resources:
- configmaps
verbs:
- get
- update
- apiGroups:
- ""
resources:
- configmaps
verbs:
- create
- apiGroups:
- ""
resources:
- events
verbs:
- create
- patch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
labels:
app.kubernetes.io/component: admission-webhook
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.2.1
name: ingress-nginx-admission
namespace: ingress-nginx
rules:
- apiGroups:
- ""
resources:
- secrets
verbs:
- get
- create
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
labels:
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.2.1
name: ingress-nginx
rules:
- apiGroups:
- ""
resources:
- configmaps
- endpoints
- nodes
- pods
- secrets
- namespaces
verbs:
- list
- watch
- apiGroups:
- ""
resources:
- nodes
verbs:
- get
- apiGroups:
- ""
resources:
- services
verbs:
- get
- list
- watch
- apiGroups:
- networking.k8s.io
resources:
- ingresses
verbs:
- get
- list
- watch
- apiGroups:
- ""
resources:
- events
verbs:
- create
- patch
- apiGroups:
- networking.k8s.io
resources:
- ingresses/status
verbs:
- update
- apiGroups:
- networking.k8s.io
resources:
- ingressclasses
verbs:
- get
- list
- watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
labels:
app.kubernetes.io/component: admission-webhook
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.2.1
name: ingress-nginx-admission
rules:
- apiGroups:
- admissionregistration.k8s.io
resources:
- validatingwebhookconfigurations
verbs:
- get
- update
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
labels:
app.kubernetes.io/component: controller
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.2.1
name: ingress-nginx
namespace: ingress-nginx
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: ingress-nginx
subjects:
- kind: ServiceAccount
name: ingress-nginx
namespace: ingress-nginx
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
labels:
app.kubernetes.io/component: admission-webhook
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.2.1
name: ingress-nginx-admission
namespace: ingress-nginx
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: ingress-nginx-admission
subjects:
- kind: ServiceAccount
name: ingress-nginx-admission
namespace: ingress-nginx
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
labels:
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.2.1
name: ingress-nginx
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: ingress-nginx
subjects:
- kind: ServiceAccount
name: ingress-nginx
namespace: ingress-nginx
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
labels:
app.kubernetes.io/component: admission-webhook
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.2.1
name: ingress-nginx-admission
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: ingress-nginx-admission
subjects:
- kind: ServiceAccount
name: ingress-nginx-admission
namespace: ingress-nginx
---
apiVersion: v1
data:
allow-snippet-annotations: "true"
kind: ConfigMap
metadata:
labels:
app.kubernetes.io/component: controller
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.2.1
name: ingress-nginx-controller
namespace: ingress-nginx
---
apiVersion: v1
kind: Service
metadata:
labels:
app.kubernetes.io/component: controller
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.2.1
name: ingress-nginx-controller
namespace: ingress-nginx
spec:
#externalTrafficPolicy: Local
ipFamilies:
- IPv4
ipFamilyPolicy: SingleStack
ports:
- appProtocol: http
name: http
port: 80
protocol: TCP
targetPort: http
- appProtocol: https
name: https
port: 443
protocol: TCP
targetPort: https
selector:
app.kubernetes.io/component: controller
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
type: LoadBalancer
---
apiVersion: v1
kind: Service
metadata:
labels:
app.kubernetes.io/component: controller
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.2.1
name: ingress-nginx-controller-admission
namespace: ingress-nginx
spec:
ports:
- appProtocol: https
name: https-webhook
port: 443
targetPort: webhook
selector:
app.kubernetes.io/component: controller
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
type: ClusterIP
---
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app.kubernetes.io/component: controller
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.2.1
name: ingress-nginx-controller
namespace: ingress-nginx
spec:
minReadySeconds: 0
revisionHistoryLimit: 10
selector:
matchLabels:
app.kubernetes.io/component: controller
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
template:
metadata:
labels:
app.kubernetes.io/component: controller
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
spec:
containers:
- args:
- /nginx-ingress-controller
- --publish-service=$(POD_NAMESPACE)/ingress-nginx-controller
- --election-id=ingress-controller-leader
- --controller-class=k8s.io/ingress-nginx
- --ingress-class=nginx
- --configmap=$(POD_NAMESPACE)/ingress-nginx-controller
- --validating-webhook=:8443
- --validating-webhook-certificate=/usr/local/certificates/cert
- --validating-webhook-key=/usr/local/certificates/key
env:
- name: POD_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: POD_NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
- name: LD_PRELOAD
value: /usr/local/lib/libmimalloc.so
image: registry.cn-hangzhou.aliyuncs.com/google_containers/nginx-ingress-controller:v1.2.1
imagePullPolicy: IfNotPresent
lifecycle:
preStop:
exec:
command:
- /wait-shutdown
livenessProbe:
failureThreshold: 5
httpGet:
path: /healthz
port: 10254
scheme: HTTP
initialDelaySeconds: 10
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 1
name: controller
ports:
- containerPort: 80
name: http
protocol: TCP
- containerPort: 443
name: https
protocol: TCP
- containerPort: 8443
name: webhook
protocol: TCP
readinessProbe:
failureThreshold: 3
httpGet:
path: /healthz
port: 10254
scheme: HTTP
initialDelaySeconds: 10
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 1
resources:
requests:
cpu: 100m
memory: 90Mi
securityContext:
allowPrivilegeEscalation: true
capabilities:
add:
- NET_BIND_SERVICE
drop:
- ALL
runAsUser: 101
volumeMounts:
- mountPath: /usr/local/certificates/
name: webhook-cert
readOnly: true
dnsPolicy: ClusterFirst
nodeSelector:
kubernetes.io/os: linux
serviceAccountName: ingress-nginx
terminationGracePeriodSeconds: 300
volumes:
- name: webhook-cert
secret:
secretName: ingress-nginx-admission
---
apiVersion: batch/v1
kind: Job
metadata:
labels:
app.kubernetes.io/component: admission-webhook
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.2.1
name: ingress-nginx-admission-create
namespace: ingress-nginx
spec:
template:
metadata:
labels:
app.kubernetes.io/component: admission-webhook
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.2.1
name: ingress-nginx-admission-create
spec:
containers:
- args:
- create
- --host=ingress-nginx-controller-admission,ingress-nginx-controller-admission.$(POD_NAMESPACE).svc
- --namespace=$(POD_NAMESPACE)
- --secret-name=ingress-nginx-admission
env:
- name: POD_NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
image: registry.cn-hangzhou.aliyuncs.com/google_containers/kube-webhook-certgen:v1.1.1
imagePullPolicy: IfNotPresent
name: create
securityContext:
allowPrivilegeEscalation: false
nodeSelector:
kubernetes.io/os: linux
restartPolicy: OnFailure
securityContext:
fsGroup: 2000
runAsNonRoot: true
runAsUser: 2000
serviceAccountName: ingress-nginx-admission
---
apiVersion: batch/v1
kind: Job
metadata:
labels:
app.kubernetes.io/component: admission-webhook
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.2.1
name: ingress-nginx-admission-patch
namespace: ingress-nginx
spec:
template:
metadata:
labels:
app.kubernetes.io/component: admission-webhook
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.2.1
name: ingress-nginx-admission-patch
spec:
containers:
- args:
- patch
- --webhook-name=ingress-nginx-admission
- --namespace=$(POD_NAMESPACE)
- --patch-mutating=false
- --secret-name=ingress-nginx-admission
- --patch-failure-policy=Fail
env:
- name: POD_NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
image: registry.cn-hangzhou.aliyuncs.com/google_containers/kube-webhook-certgen:v1.1.1
imagePullPolicy: IfNotPresent
name: patch
securityContext:
allowPrivilegeEscalation: false
nodeSelector:
kubernetes.io/os: linux
restartPolicy: OnFailure
securityContext:
fsGroup: 2000
runAsNonRoot: true
runAsUser: 2000
serviceAccountName: ingress-nginx-admission
---
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
labels:
app.kubernetes.io/component: controller
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.2.1
name: nginx
spec:
controller: k8s.io/ingress-nginx
---
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
labels:
app.kubernetes.io/component: admission-webhook
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
app.kubernetes.io/version: 1.2.1
name: ingress-nginx-admission
webhooks:
- admissionReviewVersions:
- v1
clientConfig:
service:
name: ingress-nginx-controller-admission
namespace: ingress-nginx
path: /networking/v1/ingresses
failurePolicy: Fail
matchPolicy: Equivalent
name: validate.nginx.ingress.kubernetes.io
rules:
- apiGroups:
- networking.k8s.io
apiVersions:
- v1
operations:
- CREATE
- UPDATE
resources:
- ingresses
sideEffects: None

应用配置

1
kubectl apply -f deploy.yaml

image-20220711173740297

查看详情

我们可以通过如下命令查看部署详情

1
kubectl get pod -ningress-nginx

出现如下状状态表示已经部署成功

image-20220712175523328

解决LoadBalancer问题

查看service详情

下面我们看下Service的详情

1
kubectl get service -n ingress-nginx

image-20220713145441131

我们发现ingress-nginx-controllerEXTERNAL-IP处于pending状态,这是因为service类型是LoadBalancer,需要有外部负载均衡器来分配IP,如果没有事先安装负载均衡器,就会一直处于pending状态

安装MetalLB

我们可以事先安装MetalLB负载均衡器来解决这个办法,具体安装可以参考《MetalLB 安装》

查看service详情

安装完成MetalLB 后再次查看service详情

1
kubectl get service -n ingress-nginx

我们发现这个时候EXTERNAL-IP已经有值了

image-20220713153243458

查看Controller日志
1
kubectl logs -f ingress-nginx-controller-97bf8bdc7-q8pg7 -n ingress-nginx

当看到下面的信息证明 ingress-nginx 部署成功了,这里我们安装的是最新版本的控制器

image-20220713183538715

查看ingressclass

安装完成后会自动创建一个 名为 nginxIngressClass 对象

1
kubectl get ingressclass

image-20220713183637640

创建Ingress-nginx

下面就来创建我们自己的Ingress-nginx

创建资源清单

创建Nginx服务
1
vi nginx_nodeport.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
volumes:
- name: html
emptyDir: {}
containers:
- name: nginx
image: docker.io/library/nginx:1.20
ports:
- containerPort: 80
volumeMounts:
- name: html
mountPath: /usr/share/nginx/html
- name: sidecar
image: docker.io/library/alpine
volumeMounts:
- name: html
mountPath: /html
command: ["/bin/sh", "-c"]
args:
- while true; do
echo $(hostname) $(date) >> /html/index.html;
sleep 6000;
done
---
apiVersion: v1
kind: Service
metadata:
name: nginx-svc
spec:
type: NodePort
selector:
app: nginx
ports:
- protocol: TCP
port: 80
targetPort: 80
nodePort: 32134
创建Tomcat服务
1
vi tomcat_nodeport.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
apiVersion: apps/v1
kind: Deployment
metadata:
name: tomcat-deployment
spec:
replicas: 2
selector:
matchLabels:
app: tomcat
template:
metadata:
labels:
app: tomcat
spec:
containers:
- name: tomcat-pod
image: docker.io/library/tomcat:9.0
---
apiVersion: v1
kind: Service
metadata:
name: tomcat-svc
spec:
type: NodePort
selector:
app: tomcat
ports:
- protocol: TCP
port: 8080
targetPort: 8080
nodePort: 32135
创建资源清单
1
2
kubectl apply -f nginx_nodeport.yaml
kubectl apply -f tomcat_nodeport.yaml

image-20220711165446441

查看部署
1
2
kubectl get pod -o wide
kubectl get service -o wide

image-20220711170317229

​ 可以看到通过nodeport暴露的方式是没有问题的,但是到该种方式在大规模的集群服务中,有很大的缺陷,所以接下来通过ingress-nginx进行实现。

创建ingress规则

创建该规则就是用于分别代理后端的tomcat和nginx服务

​ 在下面的 Ingress 资源对象中我们使用配置 ingressClassName: nginx 指定让我们安装的 ingress-nginx 这个控制器来处理我们的 Ingress 资源,配置的匹配路径类型为前缀的方式去匹配 /,将来自域名ingress.test.com 的所有请求转发到 my-nginx 服务的后端 Endpoints 中去

1
vi ingress-rule.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: test-ingress
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
ingressClassName: nginx #使用 nginx 的 IngressClass(关联的 ingress-nginx 控制器)
rules:
- host: ingress.test.com #后端应用通过该域名进行访问
http:
paths:
- path: / #nginx的网页根目录:/
pathType: Prefix
backend:
service: #将所有请求发送到 my-nginx 服务的 80 端口
name: nginx-svc
port:
number: 80
- path: /tomcat #tomcat的网页更目录:/tomcat
pathType: Prefix
backend:
service:
name: tomcat-svc
port:
number: 8080

注意:不过需要注意大部分Ingress控制器都不是直接转发到Service,而是只是通过Service来获取后端的Endpoints列表(因此这里的svc只起到了一个服务发现的作用),直接转发到Pod,这样可以减少网络跳转,提高性能!!!

应用配置
1
2
3
kubectl apply -f ingress-rule.yaml
# 查看绑定信息
kubectl get ingresses -o wide

我们发现地址地址栏已经显示虚拟IP了,代表我们已经部署成功

image-20220713160708100

查看配置详情
1
2
# 查看describe查看详细信息
kubectl describe ingress test-ingress

image-20220713160639562

查看配置规则

test-ingress 启动后会自动创建nginx转换规则,我们可以看下配置规则

1
2
3
kubectl get pods -n ingress-nginx
kubectl exec -it ingress-nginx-controller-97bf8bdc7-q8pg7 -n ingress-nginx -- bash
# cat nginx.conf

image-20220713162834240

通过查看nginx配置文件,我们可以清楚的知道之前所说的ingress-controller会根据我们编写的ingress规则(代理后端应用),动态的去更改nginx的配置文件

image-20220713162954839

请求访问

下面我们演示下如何使用域名进行请求访问集群内的服务

配置Host文件

因为基于nginx的请求,并且配置了虚拟主机,我们第一步是配置一下host文件,将我们的虚拟IP配置上去

1
vi /etc/hosts

在windows主机上将node02的ip地址添加到hosts文件中,做域名解析:#修改路径:C:\Windows\System32\drivers\etc\hosts(需要给予修改权限)

1
192.168.245.100 ingress.test.com
请求Nginx

我们可以通过浏览器请求nginx,并且多长访问发现可以负载均衡

1
http://ingress.test.com/

image-20220713165627607

请求Tomcat
1
http://ingress.test.com/tomcat

我们发现出现了经典的404页面

image-20220713170202758

请求流程

下图显示了客户端是如何通过 Ingress 控制器连接到其中一个 Pod 的流程

​ 客户端首先对ingress.test.com执行 DNS 解析,得到 Ingress 控制器所在节点的 IP,然后客户端向 Ingress 控制器发送 HTTP 请求,然后根据 Ingress 对象里面的描述匹配域名,找到对应的 Service 对象,并获取关联的 Endpoints 列表,将客户端的请求转发给其中一个 Pod

ingress controller workflow

Ingress-Nginx高级使用

下面是一些常用的配置,如果我们还想进行一些自定义配置,则有几种方式可以实现:使用 Configmap 在 Nginx 中设置全局配置、通过 Ingress 的 Annotations 设置特定 Ingress 的规则、自定义模板

配置TLS

通过部署ingress后,我们现在使用的是http的方式,为后端应用的安全考虑为所有的pod都颁发一个证书,我们只需为ingress代理的域名颁发证书就能够实现

TLS概述

​ Ingress 资源对象还可以用来配置 Https 的服务,可以通过设定包含 TLS 私钥和证书的 Secret 来保护 Ingress。 Ingress 只支持单个 TLS 端口 443,如果 Ingress 中的 TLS 配置部分指定了不同的主机,那么它们将根据通过 SNI TLS 扩展指定的主机名 (如果 Ingress 控制器支持 SNI)在同一端口上进行复用,需要注意 TLS Secret 必须包含名为 tls.crt 和 tls.key 的键名

创建CA证书

我们先创建一个证书

1
2
3
mkdir ssl&&cd ssl
openssl genrsa -out nginx.key 2048
openssl req -new -x509 -key nginx.key -out nginx.crt -subj /C=CN/ST=Beijing/L=Beijing/O=ssltest/CN=ingress.test.com

其中CN=ingress.test.com为想要访问的域名

image-20220713171037044

创建secret

我们创建一个保存nginx私钥的secret

1
kubectl create secret tls nginx-secret --cert=nginx.crt --key=nginx.key

image-20220713171215533

编辑ingress配置
1
vi ingress-rule.yaml

在 Ingress 中引用此 Secret 将会告诉 Ingress 控制器使用 TLS 加密从客户端到负载均衡器的通道,我们需要确保创建的 TLS Secret 创建自包含 ingress.test.com 的公用名称的证书

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: test-ingress
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
ingressClassName: nginx
tls:
- hosts:
- ingress.test.com
secretName: nginx-secret
rules:
- host: ingress.test.com #后端应用通过该域名进行访问
http:
paths:
- path: / #nginx的网页根目录:/
pathType: Prefix
backend:
service:
name: nginx-svc
port:
number: 80
- path: /tomcat #tomcat的网页更目录:/tomcat
pathType: Prefix
backend:
service:
name: tomcat-svc
port:
number: 8080
应用配置
1
kubectl apply -f ingress-rule.yaml
验证访问

直接在浏览器中访问http://ingress.test.com/,我们发现已经可以进行https访问

image-20220713171709811

内部认证

在 Ingress 对象上配置一些基本的 Auth 认证,比如 Basic Auth

创建密码文件

我们可以在 Ingress 对象上配置一些基本的 Auth 认证,比如 Basic Auth,可以用 htpasswd 生成一个密码文件来验证身份验证

1
2
3
4
5
6
#记得安装下httpd-tools软件包,htpasswd命令依赖于这个软件包
yum install -y httpd-tools
mkdir basic-auth&&cd basic-auth
#htpasswd创建一个auth的密码文件,用户名是root
htpasswd -c auth root
cat auth

输入的用户名和密码都是root

image-20220713185107578

创建secret

下面需要创建一个secret的对象保存密码

1
2
kubectl create secret generic basic-auth --from-file=auth 
kubectl describe secrets basic-auth

然后根据上面的 auth 文件创建一个 secret 对象

image-20220713185348276

编辑Ingress文件
1
vi ingress-rule.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: test-ingress
annotations:
nginx.ingress.kubernetes.io/auth-type: basic # 认证类型
nginx.ingress.kubernetes.io/auth-secret: basic-auth # 包含 user/password 定义的 secret 对象名
nginx.ingress.kubernetes.io/auth-realm: 'Authentication Required - root' # 要显示的带有适当上下文的消息,说明需要身份验证的原因
spec:
ingressClassName: nginx
tls:
- hosts:
- ingress.test.com
secretName: nginx-secret
rules:
- host: ingress.test.com #后端应用通过该域名进行访问
http:
paths:
- path: / #nginx的网页根目录:/
pathType: Prefix
backend:
service:
name: nginx-svc
port:
number: 80
- path: /tomcat #tomcat的网页更目录:/tomcat
pathType: Prefix
backend:
service:
name: tomcat-svc
port:
number: 8080
应用配置

然后对上面的 my-nginx 应用创建一个具有 Basic Auth 的 Ingress 对象

1
kubectl apply -f ingress-rule.yaml

image-20220713185809176

验证访问

直接在浏览器中访问http://ingress.test.com/,然后通过下面的命令或者在浏览器中直接打开配置的域名进行测试,我们发现已经需要输入用户名密码了

image-20220713185848697

输入用户名密码后就可以正常访问了

外部认证

除了可以使用我们自己在本地集群创建的 Auth 信息之外,还可以使用外部的 Basic Auth 认证信息

查看外部认证

比如我们使用 https://httpbin.org (国外网站,打开贼慢😓)的外部 Basic Auth 认证,创建如下所示的 Ingress 资源对象:

image-20220713190239826

编辑Ingress文件
1
vi ingress-rule.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: test-ingress
annotations:
# 配置外部认证服务地址,最后路径是用户名密码 user/passwd
nginx.ingress.kubernetes.io/auth-url: https://httpbin.org/basic-auth/user/passwd
spec:
ingressClassName: nginx
tls:
- hosts:
- ingress.test.com
secretName: nginx-secret
rules:
- host: ingress.test.com #后端应用通过该域名进行访问
http:
paths:
- path: / #nginx的网页根目录:/
pathType: Prefix
backend:
service:
name: nginx-svc
port:
number: 80
- path: /tomcat #tomcat的网页更目录:/tomcat
pathType: Prefix
backend:
service:
name: tomcat-svc
port:
number: 8080
应用配置
1
kubectl apply -f ingress-rule.yaml
验证访问

上面的资源对象创建完成后,直接在浏览器中访问http://ingress.test.com/,再进行简单的测试

image-20220713190858383

输入用户名密码user/passwd 就可以访问了

URL重写

URL重写概述

​ ingress-nginx 很多高级的用法可以通过 Ingress 对象的 annotation 进行配置,比如常用的 URL Rewrite 功能。很多时候我们会将 ingress-nginx 当成网关使用,比如对访问的服务加上 /app 这样的前缀,在 nginx 的配置里面我们知道有一个 proxy_pass 指令可以实现:

1
2
3
location /app/ {
proxy_pass http://127.0.0.1/remote/;
}

可能要加上/app,或者/gateway,/api,特别是在我们微服务里,我们很多时候要把我们的微服务提供的一些接口给它聚合在某一个子路径下面去,比如果/api.或者/api/v1下面,当然这些功能我们可以直接在网关层ingress这里实现这样的功能。

​ proxy_pass 后面加了 /remote 这个路径,此时会将匹配到该规则路径中的 /app 用 /remote 替换掉,相当于截掉路径中的 /app。同样的在 Kubernetes 中使用 ingress-nginx 又该如何来实现呢?我们可以使用 rewrite-target 的注解来实现这个需求。比如现在我们想要通过 rewrite.qikqiak.com/gateway/ 来访问到 Nginx 服务,则我们需要对访问的 URL 路径做一个 Rewrite,在 PATH 中添加一个 gateway 的前缀,关于 Rewrite 的操作在 ingress-nginx 官方文档中也给出对应的说明:

ingress nginx rewrite

rewrite-target

按照要求我们需要在 path 中匹配前缀 nginx,然后通过 rewrite-target 指定目标

效果说明

我们当前访问https://ingress.test.com/nginx显示如下界面

image-20220714094711932

我们的效果是访问https://ingress.test.com/nginx相当于访问https://ingress.test.com/

编辑资源清单
1
vi ingress-rule.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: test-ingress
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
ingressClassName: nginx
tls:
- hosts:
- ingress.test.com
secretName: nginx-secret
rules:
- host: ingress.test.com #后端应用通过该域名进行访问
http:
paths:
- path: /nginx(/|$)(.*) #(/|$)代表可能/nginx 或者/nginx/
pathType: Prefix
backend:
service:
name: nginx-svc
port:
number: 80
- path: /tomcat #tomcat的网页更目录:/tomcat
pathType: Prefix
backend:
service:
name: tomcat-svc
port:
number: 8080
应用配置
1
kubectl apply -f ingress-rule.yaml
验证访问

更新后,我们可以预见到直接访问域名肯定是不行了,因为我们没有匹配 / 的 path 路径

image-20220714094953695

但是我们带上 nginx 的前缀再去访问:

image-20220714095035566

​ 我们可以看到已经可以访问到了,这是因为我们在 path 中通过正则表达式/nginx(/|$)(.*) 将匹配的路径设置成了 rewrite-target 的目标路径了,所以我们访问https://ingress.test.com/nginx 的时候实际上相当于访问的就是后端/了

app-root

要解决我们访问主域名出现 404 的问题,我们可以给应用设置一个 app-root 的注解,这样当我们访问主域名的时候会自动跳转到我们指定的 app-root 目录下面

编辑资源清单
1
vi ingress-rule.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: test-ingress
annotations:
nginx.ingress.kubernetes.io/app-root: /nginx/ #修改点1:添加app-root注解
nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
ingressClassName: nginx
tls:
- hosts:
- ingress.test.com
secretName: nginx-secret
rules:
- host: ingress.test.com #后端应用通过该域名进行访问
http:
paths:
- path: /nginx(/|$)(.*) #(/|$)代表可能/nginx 或者/nginx/
pathType: Prefix
backend:
service:
name: nginx-svc
port:
number: 80
- path: /tomcat #tomcat的网页更目录:/tomcat
pathType: Prefix
backend:
service:
name: tomcat-svc
port:
number: 8080
应用配置
1
kubectl apply -f ingress-rule.yaml
验证访问

这个时候我们更新应用后访问主域名 ingress.test.com 就会自动跳转到 ingress.test.com/nginx/ 路径下面去了

image-20220714095035566

configuration-snippet

但是还有一个问题是我们的 path 路径其实也匹配了 /app 这样的路径,可能我们更加希望我们的应用在最后添加一个 / 这样的 slash

编辑资源清单
1
vi ingress-rule.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: test-ingress
annotations:
nginx.ingress.kubernetes.io/app-root: /nginx/
nginx.ingress.kubernetes.io/rewrite-target: /$2
nginx.ingress.kubernetes.io/configuration-snippet: | #修改点1:
rewrite ^(/gateway)$ $1/ redirect;
spec:
ingressClassName: nginx
tls:
- hosts:
- ingress.test.com
secretName: nginx-secret
rules:
- host: ingress.test.com #后端应用通过该域名进行访问
http:
paths:
- path: /nginx(/|$)(.*) #(/|$)代表可能/nginx 或者/nginx/
pathType: Prefix
backend:
service:
name: nginx-svc
port:
number: 80
- path: /tomcat #tomcat的网页更目录:/tomcat
pathType: Prefix
backend:
service:
name: tomcat-svc
port:
number: 8080
应用配置
1
kubectl apply -f ingress-rule.yaml
验证访问

更新后我们的应用就都会以 / 这样的 slash 结尾了,这样就完成了我们的需求,如果你原本对 nginx 的配置就非常熟悉的话应该可以很快就能理解这种配置方式了

image-20220714100111063

灰度发布

在日常工作中我们经常需要对服务进行版本更新升级,所以我们经常会使用到滚动升级、蓝绿发布、灰度发布等不同的发布操作。

​ 而 ingress-nginx 支持通过 Annotations 配置来实现不同场景下的灰度发布和测试,可以满足金丝雀发布、蓝绿部署与 A/B 测试等业务场景

发布规则

ngress-nginx可以通过annotations实现不同的发布规则

注意:金丝雀规则按优先顺序进行排序:canary-by-header > canary-by-cookie > canary-weight

nginx.ingress.kubernetes.io/canary-by-header

​ 基于 Request Header 的流量切分,适用于灰度发布以及 A/B 测试。当 Request Header 设置为 always 时,请求将会被一直发送到 Canary 版本;当 Request Header 设置为 never 时,请求不会被发送到 Canary 入口;对于任何其他 Header 值,将忽略 Header,并通过优先级将请求与其他金丝雀规则进行优先级的比较

nginx.ingress.kubernetes.io/canary-by-header-value

​ 要匹配的 Request Header 的值,用于通知 Ingress 将请求路由到 Canary Ingress 中指定的服务。当 Request Header 设置为此值时,它将被路由到 Canary 入口。该规则允许用户自定义 Request Header 的值,必须与上一个 annotation (canary-by-header) 一起使用。

nginx.ingress.kubernetes.io/canary-weight

​ 基于服务权重的流量切分,适用于蓝绿部署,权重范围 0 - 100 按百分比将请求路由到 Canary Ingress 中指定的服务。权重为 0 意味着该金丝雀规则不会向 Canary 入口的服务发送任何请求,权重为 100 意味着所有请求都将被发送到 Canary 入口。

​ 基于 cookie 的流量切分,适用于灰度发布与 A/B 测试。用于通知 Ingress 将请求路由到 Canary Ingress 中指定的服务的cookie。当 cookie 值设置为 always 时,它将被路由到 Canary 入口;当 cookie 值设置为 never 时,请求不会被发送到 Canary 入口;对于任何其他值,将忽略 cookie 并将请求与其他金丝雀规则进行优先级的比较。

规则分类

总的来说可以把以上的四个 annotation 规则划分为以下两类:

基于权重的 Canary 规则

基于权重的 Canary 规则

基于用户请求的 Canary 规则

基于用户请求的 Canary 规则

环境准备
创建Production资源清单

首先创建一个 production 环境的应用资源清单

1
vi production.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-production
spec:
replicas: 2
selector:
matchLabels:
app: production
template:
metadata:
labels:
app: production
spec:
volumes:
- name: html
emptyDir: {}
containers:
- name: nginx
image: docker.io/library/nginx:1.20
ports:
- containerPort: 80
volumeMounts:
- name: html
mountPath: /usr/share/nginx/html
- name: sidecar
image: docker.io/library/alpine
volumeMounts:
- name: html
mountPath: /html
command: ["/bin/sh", "-c"]
args:
- while true; do
echo 'production' >> /html/index.html;
sleep 6000;
done
---
apiVersion: v1
kind: Service
metadata:
name: nginx-svc-production
spec:
selector:
app: production
ports:
- protocol: TCP
port: 80
targetPort: 80
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: production
spec:
ingressClassName: nginx
rules:
- host: ingress.test.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: nginx-svc-production
port:
number: 80
创建Canary资源清单

参考将上述 Production 版本的 production.yaml 文件,再创建一个 Canary 版本的应用

1
vi canary.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-canary
spec:
replicas: 2
selector:
matchLabels:
app: canary
template:
metadata:
labels:
app: canary
spec:
volumes:
- name: html
emptyDir: {}
containers:
- name: nginx
image: docker.io/library/nginx:1.20
ports:
- containerPort: 80
volumeMounts:
- name: html
mountPath: /usr/share/nginx/html
- name: sidecar
image: docker.io/library/alpine
volumeMounts:
- name: html
mountPath: /html
command: ["/bin/sh", "-c"]
args:
- while true; do
echo 'canary' >> /html/index.html;
sleep 6000;
done
---
apiVersion: v1
kind: Service
metadata:
name: nginx-svc-canary
spec:
selector:
app: canary
ports:
- protocol: TCP
port: 80
targetPort: 80
创建应用
1
2
kubectl apply -f production.yaml
kubectl apply -f canary.yaml

image-20220714104717067

接下来就可以通过配置 Annotation 规则进行流量切分了

基于权重

基于权重的流量切分的典型应用场景就是蓝绿部署,可通过将权重设置为 0 或 100 来实现。

​ 例如,可将 Green 版本设置为主要部分,并将 Blue 版本的入口配置为 Canary,最初,将权重设置为 0,因此不会将流量代理到 Blue 版本,一旦新版本测试和验证都成功后,即可将 Blue 版本的权重设置为 100,即所有流量从 Green 版本转向 Blue

创建Ingress

创建一个基于权重的 Canary 版本的应用路由 Ingress 对象

1
vi canary-ingress.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: canary
annotations:
nginx.ingress.kubernetes.io/canary: "true" # 要开启灰度发布机制,首先需要启用 Canary
nginx.ingress.kubernetes.io/canary-weight: "30" # 分配30%流量到当前Canary版本
spec:
ingressClassName: nginx
rules:
- host: ingress.test.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: nginx-svc-canary
port:
number: 80
应用配置
1
kubectl apply -f canary-ingress.yaml

image-20220714105110606

验证测试

Canary 版本应用创建成功后,接下来我们在命令行终端中来不断访问这个应用,观察返回内容的变化

1
for i in $(seq 1 10); do curl -s ingress.test.com ;done;

由于我们给 Canary 版本应用分配了 30% 左右权重的流量,所以上面我们访问10次有3次访问到了 Canary 版本的应用,符合我们的预期

image-20220714105717242

基于Request Header

基于Request Header 进行流量切分的典型应用场景即灰度发布或 A/B 测试场景

​ 在上面的 Canary 版本的 Ingress 对象中新增一条 annotation 配置 nginx.ingress.kubernetes.io/canary-by-header: canary(这里的 value 可以是任意值),使当前的 Ingress 实现基于 Request Header 进行流量切分,由于 canary-by-header 的优先级大于canary-weight,所以会忽略原有的 canary-weight 的规则

编辑资源清单
1
vi canary-ingress.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: canary
annotations:
nginx.ingress.kubernetes.io/canary: "true" # 要开启灰度发布机制,首先需要启用 Canary
nginx.ingress.kubernetes.io/canary-by-header: canary # 基于header的流量切分
nginx.ingress.kubernetes.io/canary-weight: "30" # 分配30%流量到当前Canary版本
spec:
ingressClassName: nginx
rules:
- host: ingress.test.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: nginx-svc-canary
port:
number: 80
应用配置
1
kubectl apply -f canary-ingress.yaml

image-20220714105110606

请求访问

更新上面的 Ingress 资源对象后,我们在请求中加入不同的 Header 值,再次访问应用的域名。

​ 注意:当 Request Header 设置为 never 或 always 时,请求将不会或一直被发送到 Canary 版本,对于任何其他 Header 值,将忽略 Header,并通过优先级将请求与其他 Canary 规则进行优先级的比较。

1
for i in $(seq 1 10); do curl -s -H "canary:never" ingress.test.com ;done;

image-20220714110245431

这里我们在请求的时候设置了 canary: never 这个 Header 值,所以请求没有发送到 Canary 应用中去,如果设置为其他值呢:

1
for i in $(seq 1 10); do curl -s -H "canary:other-value" ingress.test.com ;done;

image-20220714110401126

由于我们请求设置的 Header 值为 canary: other-value,所以 ingress-nginx 会通过优先级将请求与其他 Canary 规则进行优先级的比较,我们这里也就会进入 canary-weight: "30" 这个规则去

修改规则

这个时候我们可以在上一个 annotation (即 canary-by-header)的基础上添加一条 nginx.ingress.kubernetes.io/canary-by-header-value: user-value 这样的规则,就可以将请求路由到 Canary Ingress 中指定的服务了

1
vi canary-ingress.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: canary
annotations:
nginx.ingress.kubernetes.io/canary: "true" # 要开启灰度发布机制,首先需要启用 Canary
nginx.ingress.kubernetes.io/canary-by-header-value: user-value
nginx.ingress.kubernetes.io/canary-by-header: canary # 基于header的流量切分
nginx.ingress.kubernetes.io/canary-weight: "30" # 分配30%流量到当前Canary版本
spec:
ingressClassName: nginx
rules:
- host: ingress.test.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: nginx-svc-canary
port:
number: 80

同样更新 Ingress 对象后,重新访问应用,当 Request Header 满足 canary: user-value时,所有请求就会被路由到 Canary 版本:

1
for i in $(seq 1 10); do curl -s -H "canary:user-value" ingress.test.com ;done;

image-20220714111045199

与基于 Request Header 的 annotation 用法规则类似

​ 例如在 A/B 测试场景下,需要让地域为北京的用户访问 Canary 版本,那么当 cookie 的 annotation 设置为 nginx.ingress.kubernetes.io/canary-by-cookie: "users_from_Beijing",此时后台可对登录的用户请求进行检查,如果该用户访问源来自北京则设置 cookie users_from_Beijing 的值为 always,这样就可以确保北京的用户仅访问 Canary 版本。

编辑资源清单

同样我们更新 Canary 版本的 Ingress 资源对象,采用基于 Cookie 来进行流量切分

1
vi canary-ingress.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: canary
annotations:
nginx.ingress.kubernetes.io/canary: "true" # 要开启灰度发布机制,首先需要启用 Canary
nginx.ingress.kubernetes.io/canary-by-cookie: "users_from_Beijing" # 基于 cookie
nginx.ingress.kubernetes.io/canary-weight: "30" # 分配30%流量到当前Canary版本
spec:
ingressClassName: nginx
rules:
- host: ingress.test.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: nginx-svc-canary
port:
number: 80
应用配置
1
kubectl apply -f canary-ingress.yaml

image-20220714105110606

请求访问

更新上面的 Ingress 资源对象后,我们在请求中设置一个 users_from_Beijing=always 的 Cookie 值,再次访问应用的域名

1
for i in $(seq 1 10); do curl -s -b "users_from_Beijing=always" ingress.test.com ;done;

我们可以看到应用都被路由到了 Canary 版本的应用中去了,如果我们将这个 Cookie 值设置为 never,则不会路由到 Canary 应用中

image-20220714111447882

评论