小阿轩yx-服务发布Ingress进阶
前言
Kubernetes 暴露服务的方式目前只有三种
- LoadBlancer Service
- NodePort Service
- Ingress
ingress 通俗来讲
- 和之前提到的 Service、Deployment，也是一个k8s 的资源类型。
- 用于实现用域名的方式访问 k8s 内部应用。（只能用域名访问，不能用 IP 地址访问）
Ingress
- 为 Kubernetes 集群中的服务提供了入口
- 可以提供负载均衡、SSL 终止和基于名称的虚拟主机
生产环境中常用的Ingress 有
- Treafik
- Nginx
- HAProxy
- lstio
基本概念
- service 的作用体现在两个方面
对集群内部
- 它不断跟踪 pod 的变化
- 更新 endpoint（端点）中对应 pod 的对象
- 提供了 ip 不断变化的 pod 的服务发现机制
对集群外部
- 它类似负载均衡器
- 可以在集群内外部对 pod 进行访问
在 Kubernetes 中
- Pod 的 IP 地址和 service 的 ClusterIP 仅可以在集群网络内部使用，对于集群外的应用是不可见的。
Kubernetes 目前提供了几种方案使外部的应用能够访问集群内的服务
- NodePort：将 service 暴露在节点网络上，NodePort 背后就是 Kube-Proxy，Kube-Proxy 是沟通service 网络、Pod 网络和节点网络的桥梁。
- 测试环境使用还行，当有几十上百的服务在集群中运行时，NodePort 的端口管理就是个灾难。因为每个端口只能是一种服务，端口范围只能是30000-32767。
- LoadBalancer：通过设置 LoadBalancer 映射到云服务商提供的 LoadBalancer 地址。
- 这种用法仅用于在公有云服务提供商的云平台上设置 Service 的场景。
- 受限于云平台，且通常在云平台部署LoadBalancer 还需要额外的费用。
- 在 service 提交后，Kubernetes 就会调用 cloudprovider 在公有云上为你创建一个负载均衡服务，并且把被代理的 Pod 的 IP 地址配置给负载均衡服务做后端。
- externalIPs：service 允许为其分配外部IP，如果外部IP路由到集群中一个或多个Node上，Service会被暴露给这些 externalIPs。
- 通过外部IP进入到集群的流量，将会被路由到Service的Endpoint上。
- Ingress：只需一个或少量的公网 IP 和 LB，即可同时将多个 HTTP 服务暴露到外网，七层反向代理。
- 可以简单理解为service的service，它其实就是一组基于域名和URL路径，把用户的请求转发到一个或多个service的规则。
目前比较流行的 IngressController 有
-
ingress-nginx（由Kubemetes官方维护）
-
nginx-ingress（由 Nginx 官方维护，注意和Ingress-nginx的区别）
-
Traefik
-
Istio
Ingress 组成
ingress
- 是一个 API 对象
- 对象的作用是定义请求如何转发到 service 的规则，可以理解为配置模版
- 通过 yaml 文件来配置
- 通过 http 或 https 暴露集群内部 service，给service提供外部URL、负载均衡、SSL/TLS能力以及基于域名的反向代理
- 要依靠 ingress-controller 来具体实现以上功能。
ingress-controller
- 是具体实现反向代理及负载均衡的程序，对ingress定义的规则进行解析，根据配置的规则来实现请求转发。
- 并不是k8s自带的组件，实际上ingress-controller只是一个统称，用户可以选择不同的ingress-controller实现
- 是负责具体转发的组件，通过各种方式将它暴露在集群入口，外部对集群的请求流量会先到 ingress-controller， 而ingress对象是用来告诉ingress-controller该如何转发请求
目前
由 k8s 维护的 ingress-controller 只有
- google云的GCE
- ingress-nginx
其它还有很多第三方维护的 ingress-controller
一般 ingress-controller 的形式都是一个 pod，里面跑着 daemon 程序和反向代理程序
- daemon 负责不断监控集群变化，根据 ingress 对象生成配置并应用新配置到反向代理
Ingress 工作过程
用户访问一个业务的流程
- 用户在浏览器中输入域名
- 域名解析至业务的入口IP（一般为外部负载均衡器，比如阿里的SLB或者DMZ的网关）。
- 外部负载均衡器反向代理至kubernetes的入口（一般为Ingress，或者通过NodePort暴露的服务等）。
- Ingress 根据自身的配置找到对应的Service，再代理到对应的Service上。
- 最后到达Service对应的某一个 Pod 上。
一般情况下
- Ingress 主要是一个用户 kubernetes 集群业务的入口。
是业务能够正常提供服务的核心
在生产环境中，推荐使用单独的服务器作为Ingress Controller。
Controller
- 可以使用Traefik、Istio、Nginx、HaProxy等作为Ingress Controller。
Ingress 工作原理
- ingress-controller 通过和 kubernetes APIServer 交互，动态的去感知集群中ingress规则变化
- 然后读取它，按照自定义的规则，规则就是写明了哪个域名对应哪个service，生成一段nginx配置
- 再写到 nginx-ingress-controller的pod里，这个ingress-controller的pod里运行着一个Nginx服务，控制器会把生成的 nginx配置写入 /etc/nginx.conf文件中
- 然后 reload 一下使配置生效。以此达到域名区分配置和动态更新的作用。
安装 Ingress Nginx Controller
- 由于 Ingress Controller 相当于kubernetes集群中服务的 “大门”
在生产环境中
- 一定要保障 Controller 的稳定性和可用性
- 为了提高Ingress Controller的可用性，一般采用单独的服务器作为Controller节点，以此保障Ingress Controller的Pod资源不会被其他服务的Pod影响。
Ingress Nginx
- 官方提供了多种部署方式，本此将采用 Helm 的方式进行安装，并且将Ingress Controller安装在k8s-node0l节点。
首先将 images 镜像文件通过 Xftp 上传至 master、node01、node02（101、102、103）
将 ingress-nginx 文件单独上传至 master（101）
最后再将资源清单文件单独上传至 master（101）
这一步开启会话同步
进入镜像文件三个节点同时导入镜像
主机一
[root@k8s-master ~]# cd images/
[root@k8s-master images]# bash imp_docker_img.sh主机二
[root@k8s-node01 ~]# cd images/
[root@k8s-node01 images]# bash imp_docker_img.sh主机三
[root@k8s-node02 ~]# cd images/
[root@k8s-node02 images]# bash imp_docker_img.sh取消会话同步
下载并安装 helm（已有 helm 环境可忽略此步骤）
https://get.helm.sh/helm-v3.9.4-linux-amd64.tar.gz
解压
[root@k8s-master ~]# tar zxvf helm-v3.9.4-linux-amd64.tar.gz移动到指定目录下
[root@k8s-master ~]# mv linux-amd64/helm /usr/local/bin/下载 Ingress Controller（已有离线包可忽略此步骤）
https://kubernetes.github.io/ingress-nginx
[root@k8s-master ~]# helm repo add ingress-nginx
"ingress-nginx" has been added to your repositories修改 Ingress Controller 参数
[root@k8s-master ~]# helm repo update
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "ingress-nginx" chart repository
Update Complete. ⎈Happy Helming!⎈拉取对应的镜像版本
[root@k8s-master ~]# helm pull ingress-nginx/ingress-nginx --version 4.7.1解压
[root@k8s-master ~]# tar xvf ingress-nginx-4.7.1.tgz修改配置文件
[root@k8s-master ~]# vim ingress-nginx/values.yaml
controller:
name: controller
image:
chroot: false
registry: registry.cn-hangzhou.aliyuncs.com
image: tanzu/controller
tag: "v1.6.4"
#digest: sha256:15be4666c53052484dd2992efacf2f50ea77a78ae8aa21ccd91af6baaa7ea22f
#digestChroot: sha256:0de01e2c316c3ca7847ca13b32d077af7910d07f21a4a82f81061839764f8f81# 将Controller的registry仓库地址修改为国内的
- registry: registry.cn-hangzhou.aliyuncs.com
- image: tanzu/controller
- tag: "v1.6.4"
- #digest: sha256:15be4666c53052484dd2992efacf2f50ea77a78ae8aa21ccd91af6baaa7ea22f
-
#digestChroot: sha256:0de01e2c316c3ca7847ca13b32d077af7910d07f21a4a82f81061839764f8f81
修改 opentelemetry 镜像地址
opentelemetry:
enabled: false
image: registry.cn-hangzhou.aliyuncs.com/tanzu/opentelemetry:v20230107
containerSecurityContext:
allowPrivilegeEscalation: false- image: registry.cn-hangzhou.aliyuncs.com/tanzu/opentelemetry:v20230107
将 admissionWebhook 的镜像地址修改为国内的
patchWebhookJob:
securityContext:
allowPrivilegeEscalation: false
resources: {}
patch:
enabled: true
image:
registry: registry.cn-hangzhou.aliyuncs.com
image: tanzu/kube-webhook-certgen
tag: v20220916-gd32f8c343
#digest: sha256:543c40fd093964bc9ab509d3e791f9989963021f1e9e4c9c7b6700b02bfb227b
pullPolicy: IfNotPresent- registry: registry.cn-hangzhou.aliyuncs.com
- image: tanzu/kube-webhook-certgen
- tag: v20220916-gd32f8c343
-
#digest: sha256:543c40fd093964bc9ab509d3e791f9989963021f1e9e4c9c7b6700b02bfb227b
修改 hostNetwork 的值为 true
- 设置为 true 时，该 Pod 将与其所在节点共享网络命名空间。
dnsPolicy设置为 ClusterFirstWithHostNet
- kubernetes 可以在 pod 级别通过 dnspolicy 字段设置DNS策略。
目前支持的 DNS 策略
- Default：继承 pod 所在宿主机的域名解析设置。
ClusterFirst：将优先使用kubernetes环境的dns服务（如coreDNS提供的域名解析服务），将无法解析的域名转发到系统配置的上游DNS服务器。
ClusterFirstWithHostNet：适用与以hostNetwork模式运行的pod。
None：忽略集群的 DNS 配置，需要手工通过dnsConfig自定义DNS配置。这个选项在1.9版本中开始引入，到1.10版本时升级为Beta，到1.14版本时达到稳定版本。
nodeSelector 添加 ingress: "true"
nodeSelector:
ingress: true
kubernetes.io/os: linux此配置能够将ingress安装在带有“ingress: true”标签的节点上。
- ingress: true
修改 kind 类型为 DaemonSet
kind: DeamonSet- 如果已经下载好了离线的 helm 和 ingress-nginx，可以直接解压并安装，不必下载。
部署 ingress
给需要部署 Ingress Controller 的节点打标签
[root@k8s-master ~]# kubectl label node k8s-node01 ingress=true创建 namespace
[root@k8s-master ~]# kubectl create ns ingress-nginx
namespace/ingress-nginx created进入目录
[root@k8s-master ~]# cd ingress-nginx安装 ingress-nginx
[root@k8s-master ingress-nginx]# helm install ingress-nginx -n ingress-nginx .- 注意最后有一个点
查看安装信息
[root@k8s-master ingress-nginx]# kubectl get po -n ingress-nginx -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
ingress-nginx-controller-2t6qh 1/1 Running 0 17s 192.168.10.102 k8s-node01 <none> <none>Ingress Nginx 入门
首先从最简单的配置开始
- 假如公司有一个web服务的容器，需要为其添加一个域名，此时可以使用 Ingerss 实现该功能
创建一个用于学习的 namespace
[root@k8s-master ingress-nginx]# kubectl create ns study-ingress创建一个 nginx 作为 web 服务
[root@k8s-master ingress-nginx]# kubectl create deployment nginx --image=nginx:1.7.9 \
-n study-ingress创建一个该 web 容器的 Service
[root@k8s-master ingress-nginx]# kubectl expose deployment nginx --port 80 -n study-ingress创建 ingress 指向上一步的 Service
[root@k8s-master ingress-nginx]# vim web-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: nginx-ingress
namespace: study-ingress
spec:
ingressClassName: nginx
rules:
- host: nginx.test.com
http:
paths:
- backend:
service:
name: nginx
port:
number: 80
path: /
pathType: ImplementationSpecific- service:
- name: nginx
- port:
- number: 80
路径类型
有3种支持 path 类型
- ImplementationSpecific：对于这种path类型，匹配取决于IngressClass。可以将其视为一个单独的pathType或者将其认为和Prefix或者Exact路径类型一样。
- Exact：精确匹配 URL 路径，并且区分大小写
- Prefix：根据 URL 中的，被 / 分割的前缀进行匹配。匹配区分大小写并且按照元素对路径进行匹配。path元素指的是路径中由/分隔符分隔的标签列表。
路径的最后一个元素是请求路径中最后一个元素的子字符串，那么这个是不匹配的。
举例：/foo/bar匹配/foo/bar/baz，但是不匹配 /foo/barbaz
创建该 ingress
[root@k8s-master ingress-nginx]# kubectl create -f web-ingress.yaml- 不删除此 ingress，否则后面的 ssl 无法访问
客户端访问测试
- 创建的 Ingress绑定的域名为nginx.test.com
- 由于本次的 IngressController 是以 hostNetwork 模式部署的，因此将域名解析至 IngressController 所在的节点即可。
- 如果 IngressController 上层还有一层网关，解析至网关IP即可。
- 接下来通过域名 nginx.test.com 即可访问 Web 服务器。
虚拟机打开一个带桌面的主机
找到 hosts 文件并用记事本打开
打开并添加地址
打开浏览器输入地址访问
- 可以看到通过上述简单的 Ingress 资源定义就可以实现以域名的方式访问服务，不需要再去维护复杂的Ngmx配置文件，大大降低了运维的复杂度和出错的频率。
Ingress Nginx 域名重定向 Redirect
- 一个服务要更换域名时并不能直接更改，要有一个过渡过程
- 这个过程中要将旧域名的访问跳转到新域名，可以使用 Redirect 功能
- 等旧域名无访问时，再停止旧域名
Nginx 作为代理服务器时，Redirect 可用于域名的重定向
比如
- 访问 old.com 被重定向到 new.com
- Ingress 可以更简单的实现 Redirect 功能
用 nginx.redirect.com 作为旧域名，baidu.com 作为新域名演示
编辑 Ingress 文件
[root@k8s-master ingress-nginx]# vim redirect.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/permanent-redirect: https://www.baidu.com
name: nginx-redirect
namespace: study-ingress
spec:
ingressClassName: nginx
rules:
- host: nginx.redirect.com
http:
paths:
- backend:
service:
name: nginx
port:
number: 80
path: /
pathType: ImplementationSpecific创建 Ingress
[root@k8s-master ingress-nginx]# kubectl create -f redirect.yaml测试
- 在客户端的 hosts文件添加域名 nginx.redirect.com
- 使用域名 nginx.redirect.com 访问网站，打开的是 baidu.com，说明跳转成功
Ingress Nginx 前后端分离 Rewrite
- 现在大部分应用都是前后端分离的架构，也就是前端用某个域名的根路径进行访问，后端接口采用／api进行访问，用来区分前端和后端。
- 或者同时具有很多个后端，需要使用／api-a到A服务,／api-b到B服务，但是由于A和B服务可能并没有／api-a和／api-b的路径，因此需要将／api-x重写为“／”，才可以正常到A或者B服务，否则将会出现404的报错。
此时可以通过 Rewrite 功能达到这种效果
创建一个应用模拟后端服务
[root@k8s-master ~]# kubectl create deployment backend-api --image=nginx:1.7.9 -n study-ingress创建 Service 暴露应用
[root@k8s-master ~]# kubectl expose deployment backend-api --port 80 -n study-ingress查看该 Service 的地址
[root@k8s-master ~]# kubectl get svc -n study-ingress
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
backend-api ClusterIP 10.108.159.54 <none> 80/TCP 49s
nginx ClusterIP 10.106.204.36 <none> 80/TCP 103m通过 /api-a 访问测试
- http://nginx.test.com/api-a
编辑 ingress 实现 rewrite
[root@k8s-master ~]# vim rewirte.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /$2
name: backend-api
namespace: study-ingress
spec:
ingressClassName: nginx
rules:
- host: nginx.test.com
http:
paths:
- backend:
service:
name: backend-api
port:
number: 80
path: /api-a(/|$)(.*)
pathType: ImplementationSpecific创建该 ingress
[root@k8s-master ~]# kubectl create -f rewirte.yaml访问测试
- http://nginx.test.com/api-a
Ingress Nginx SSL 配置
- 生产环境对外的服务一般需要配置HTTPS协议，使用Ingress也可以非常方便地添加HTTPS的证书。
- 由于是学习环境，并没有权威证书，因此需要使用OpenSSL生成一个测试证书（如果是生产环境，那么证书为在第三方公司购买的证书，无须自行生成）
生成证书
[root@k8s-master ~]# openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout tls.key -out tls.crt -subj "/CN=nginx.test.com"
Generating a 2048 bit RSA private key
.................+++
........................................+++
writing new private key to 'tls.key'创建证书的 secret
[root@k8s-master ~]# kubectl create secret tls ca-secret --cert=tls.crt --key=tls.key -n study-ingress编辑 ingress
[root@k8s-master ~]# vim ingress-ssl.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
creationTimestamp: null
name: nginx-ingress-ssl
spec:
ingressClassName: nginx-ssl
rules:
- host: nginx.test.com
http:
paths:
- backend:
service:
name: nginx
port:
number: 80
path: /
pathType: ImplementationSpecific
tls:
##证书授权的域名列表
- hosts:
- nginx.test.com
##证书的secret名字
secretName: ca-secret创建此 ingress
[root@k8s-master ~]# kubectl create -f ingress-ssl.yaml访问测试
- https://nginx.test.com
Ingress Nginx 基本认证
- 有些网站可能需要通过密码来访问，对于这类网站可以使用 nginx 的 basic-auth 设置密码访问
由于需要使用htpasswd工具，因此需要安装httpd
安装 httpd（在 master 主节点）101
[root@k8s-master ~]# yum -y install httpd使用 htpasswd 创建用户
[root@k8s-master ~]# htpasswd -c auth zhangsan
New password:
Re-type new password:
Adding password for user zhangsan基于之前创建的密码文件创建 secret
[root@k8s-master ~]# kubectl create secret generic basic-auth --from-file=auth -n study-ingress编辑 ingress 包含密码认证
[root@k8s-master ~]# vim ingress-with-auth.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/auth-realm: Please Input Your Username and Password
nginx.ingress.kubernetes.io/auth-secret: basic-auth
nginx.ingress.kubernetes.io/auth-type: basic
name: ingress-with-auth
namespace: study-ingress
spec:
ingressClassName: nginx
rules:
- host: auth.test.com
http:
paths:
- backend:
service:
name: nginx
port:
number: 80
path: /
pathType: ImplementationSpecific- nginx.ingress.kubernetes.io/auth-secret: basic-auth：密码文件的secret名称
- nginx.ingress.kubernetes.io/auth-type: basic：认证类型
- ingressClassName: nginx
- - host: auth.test.com
- host: auth.test.com 客户端要访问的域名，注意不要使用前面的域名，或者把前面的ingress都删掉
部署此 ingress
[root@k8s-master ~]# kubectl create -f ingress-with-auth.yaml访问测试
- 在客户端 hosts 文件新添加域名 auth.test.com 的解析
灰度/金丝雀发布
灰度与蓝绿发布
- 是为新版本服务创建一个与老版本服务完全一致的生产环境，在不影老版本服务的前提下，按照一定的规则把部分流量切换到新版本，当新版本试运行一段时间没有问题后，将用户的全量流量从老版本迁移至新版本。
灰度发布方式
- 通常用于AB测试，是指一部分用户继续使用老版本的服务，将一部分用户的流量切换到新版本，如果新版本运行稳定，则逐步将所有用户迁移到新版本。
金丝雀发布
- 指在生产环境中逐步推出新版本应用程序，只在一小部分用户或流量中使用该版本，并根据反馈逐步扩大规模，最终完全替换旧版本。
-
允许快速检测新版本与旧版本之间是否存在兼容性问题、性能问题或其他问题，并减轻了在实施全新发布时可能遭受的损失。
蓝绿部署
- 指同时运行两个版本的应用。
- 部署时并不停止掉老版本，而是直接部署一套新版本，等新版本运行起来后，再将流量切换到新版本上。
例如
- 发布前在蓝色的系统上进行测试，测试完成后切换为蓝色系统，同时观察蓝色系统的运行状态，如果运行出现问题可以及时切回绿色系统。
蓝绿部署的优点
- 可以减少发布影响的时间。
例如
- 某网站要进行后端升级，无需完全停掉服务更新，且出现问题后可以及时切回老版本。
蓝绿部署的缺点
- 需要两倍的硬件资源
- 需要额外进行付费
- 微服务架构很难这样进行迁移
- 要求蓝绿两套系统完全没有耦合
- 迁移后未完成的任务进行迁移需要一定的成本
创建 V1 版本
首先创建模拟生产（Production）环境的命名空间和服务
[root@k8s-master ~]# kubectl create ns production创建 v1 版本的应用
[root@k8s-master ~]# kubectl create deployment canary-v1 --image=registry.cn-beijing.aliyuncs.com/dotbalo/canary:v1 -n production创建 Service 暴露应用
[root@k8s-master ~]# kubectl expose deployment canary-v1 --port 8080 -n production创建 ingress 指定域名为 canary.com
[root@k8s-master ~]# cat v1-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: canary-v1
namespace: production
spec:
ingressClassName: nginx
rules:
- host: canary.com
http:
paths:
- backend:
service:
name: canary-v1
port:
number: 8080
path: /
pathType: ImplementationSpecific- - host: canary.com
- - backend:
- service:
- name: canary-v1
- port:
- number: 8080
路径类型 pathType
- ImplementationSpecific：系统默认，有IngressClass控制器提供具体实现
exact：精确匹配URL路径，区分大小写
- prefix：匹配URL路径的前缀
部署 ingress
[root@k8s-master ~]# kubectl create -f v1-ingress.yaml测试访问
- 在客户端添加 canary.com 的域名解析
创建 v2 版本
- 充当灰度环境
创建 v2 版本的命名空间
[root@k8s-master ~]# kubectl create ns canary创建 v2 版本的应用
[root@k8s-master ~]# kubectl create deployment canary-v2 --image=registry.cn-beijing.aliyuncs.com/dotbalo/canary:v2 -n canary创建 v2 版本的 service
[root@k8s-master ~]# kubectl expose deployment canary-v2 --port 8080 -n canary获取 svc 的信息
[root@k8s-master ~]# kubectl get svc -n canary
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
canary-v2 ClusterIP 10.110.139.239 <none> 8080/TCP 39s测试连通性
[root@k8s-master ~]# curl 10.110.139.239:8080
<h1>Canary v2</h1>通过 ingress 控制流量
[root@k8s-master ~]# vim canary-v2.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
##指定此为灰度环境
nginx.ingress.kubernetes.io/canary: "true"
##灰度环境的权重
nginx.ingress.kubernetes.io/canary-weight: "10"
##此ingress的名称
name: canary-v2
##所属的命名空间
namespace: canary
spec:
ingressClassName: nginx
rules:
##客户端访问的域名
- host: canary.com
http:
paths:
##后端设置，通常用来设置service
- backend:
service:
name: canary-v2
port:
number: 8080
path: /
pathType: ImplementationSpecific- nginx.ingrss.kubernetes.io/canary: "true"：表示此站点为灰度模式
-
nginx.ingress.kubernetes.io/canary-weight: "10"：表示为该站点分配10%的流量，原站点就可以得到90%的流量
weight：“10” 权重为10
测试灰度发布
进行测试
[root@k8s-master ~]# for i in $(seq 10);do curl -s canary.com;done
<h1>Canary v2</h1>
<h1>Canary v1</h1>
<h1>Canary v1</h1>
<h1>Canary v1</h1>
<h1>Canary v1</h1>
<h1>Canary v1</h1>
<h1>Canary v1</h1>
<h1>Canary v1</h1>
<h1>Canary v1</h1>
<h1>Canary v1</h1>- 从结果大致判断出，两个网站的访问比例大约为1:9
修改权重为50的测试结果
[root@k8s-master ~]# ku edit ingress canary-v2 -n canary
#修改权重值为50
nginx.ingress.kubernetes.io/canary-weight: "50"循环遍历10次输出查看结果
[root@k8s-master ~]# for i in $(seq 10);do curl -s canary.com;done
<h1>Canary v2</h1>
<h1>Canary v2</h1>
<h1>Canary v1</h1>
<h1>Canary v2</h1>
<h1>Canary v1</h1>
<h1>Canary v1</h1>
<h1>Canary v2</h1>
<h1>Canary v2</h1>
<h1>Canary v1</h1>
<h1>Canary v1</h1>小阿轩yx-服务发布Ingress进阶
282
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
