小阿轩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进阶