文章目录

前言

首先在案例之前，先认识一下被业界广泛采用的服务发布有哪些，也是我们之后要实现的东西什么

发布策略

在现代软件开发和运维中，服务发布策略至关重要，以确保新版本能够顺利上线并最小化风险。以下是几种被业界广泛采用的服务发布策略：

  1. 蓝绿发布（Blue-Green Deployment）
    概念：
    蓝绿发布是一种减少停机时间和风险的部署策略。它通过维护两套几乎完全相同的生产环境——蓝色环境和绿色环境——来实现平滑的版本切换。
    流程：
    蓝色环境：当前活跃的生产环境，正在处理实际的用户流量。
    绿色环境：待更新的新版本被部署到绿色环境中。
    切换流量：一旦新版本在绿色环境中通过所有测试，流量从蓝色环境切换到绿色环境。
    回滚：如果新版本出现问题，可以迅速切换回蓝色环境。
    优点：
    无缝切换，最小化停机时间。
    容易回滚，风险较低。
    缺点：
    需要两套生产环境，成本较高。
    资源利用率可能不高。
  1. A/B 测试（A/B Testing）
    概念：
    A/B 测试是通过将用户流量分成两组或多组，分别体验不同版本的应用，从而比较其效果和性能差异的一种发布策略。
    流程：
    版本划分：创建版本A（现有版本）和版本B（新版本）。
    流量分配：随机将用户流量划分到A/B两个版本中。
    数据收集：收集用户在不同版本下的行为数据。
    分析结果：分析数据确定哪个版本表现更好。
    优点：
    可以在真实环境中验证新功能的效果。
    数据驱动决策，精确了解用户偏好。
    缺点：
    需要数据分析能力强，才能有效评估结果。
    对用户体验可能产生不一致的影响。
  1. 金丝雀发布（Canary Release）
    概念：
    金丝雀发布是一种逐步发布策略，通过向一小部分用户发布新版本，观察其表现并逐步扩大覆盖面，以确保新版本的稳定性和可靠性。
    流程：
    小规模发布：将新版本发布给少量用户（通常是内部用户或早期测试用户）。
    监控和评估：密切监控新版本的性能和用户反馈。
    扩大发布范围：如果新版本表现良好，逐步增加覆盖用户直到全量发布。
    优点：
    风险较小，可以早期发现问题。
    逐步发布，问题排查和修复较为容易。
    缺点：
    发布和监控过程较为复杂，需要持续观察。
    需要良好的监控和反馈机制。

应用

环境

虚拟机

Ip主机名cpu内存硬盘
192.168.10.11master012cpu双核4G100G
192.168.10.12worker012cpu双核4G100G
192.168.10.13worker022cpu双核4G100G

版本 centos7.9
已部署k8s-1.27

通过ingress-nginx实现灰度发布系统

一、负载均衡器metallb部署

1. 修改kube-proxy代理模式
kubectl edit configmap kube-proxy -n kube-syste

更改两处
strictARP 后的flase改为true
node 后添加ipvs
没看见往下翻

在这里插入图片描述

重启

kubectl rollout restart daemonset kube-proxy -n kube-system
2. metallb部署
kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.14.5/config/manifests/metallb-native.yaml

服务器连接不了时，可在vpn连接后，浏览器中访问https://raw.githubusercontent.com/metallb/metallb/v0.14.5/config/manifests/metallb-native.yaml
看到内容后复制创建文件

也可以使用离线下载后的文件部署

kubectl apply -f metallb-native.yaml

查看

kubectl -n metallb-system get pod

等待一会，可通过查看描述信息跟踪pod的运行状态，长时间无法完成下载时，各节点重启docker

kubectl -n metallb-system describe pod controller-6b9fd67ff4-rzvg2
3. IP地址池准备
vim ippool.yaml

addresses下是范围

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: ippool
  namespace: metallb-system
spec:
  addresses:
  - 192.168.10.240-192.168.10.250

yaml应用

kubectl apply -f ippool.yaml

若出现故障提示，等上面pod全部运行起来再部署
还不行，各节点重启docker

查看地址池信息

kubectl -n metallb-system describe ipaddresspools.metallb.io ippool

在这里插入图片描述

4.开启二层通告
vim L2.yaml

apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: example
  namespace: metallb-system

应用yaml

kubectl apply -f L2.yaml

二、 服务代理ingress nginx部署

（1）获取ingress nginx部署文件
创建目录

mkdir tsdir
cd tsdir

windows浏览器打开文件：

https://github.com/kubernetes/ingress-nginx/blob/main/deploy/static/provider/baremetal/deploy.yaml

复制文件内容到linux中deploy.yaml文件

vim deploy.yaml

（2）修改部署文件deploy.yaml

vim deploy.yaml

修改此行 type: NodePort
为 type: LoadBalancer

修改前
在这里插入图片描述
修改后
在这里插入图片描述

（3）部署ingress nginx

kubectl apply -f deploy.yaml

稍等几分钟后查看 需要vpn，没有的话查看信息时会显示连接不到镜像仓库

kubectl -n ingress-nginx get pod

可以看到已经成功运行了
在这里插入图片描述
修改configmap

kubectl get configmaps ingress-nginx-controller -n ingress-nginx

在这里插入图片描述

kubectl edit configmaps ingress-nginx-controller -n ingress-nginx

将false改为true
修改前
在这里插入图片描述
修改后
在这里插入图片描述

重启ingress-nginx应用：

kubectl rollout restart deployment ingress-nginx-controller -n ingress-nginx

在这里插入图片描述

三、应用服务部署

1.v1版本部署
vim 01-deploy-nginx-v1.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-v1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
      version: v1
  template:
    metadata:
      labels:
        app: nginx
        version: v1
    spec:
      containers:
      - name: nginx
        image: "openresty/openresty:centos"
        ports:
        - name: http
          protocol: TCP
          containerPort: 80
        volumeMounts:
        - mountPath: /usr/local/openresty/nginx/conf/nginx.conf
          name: config
          subPath: nginx.conf
      volumes:
      - name: config
        configMap:
          name: nginx-v1

---

apiVersion: v1
kind: ConfigMap
metadata:
  labels:
    app: nginx
    version: v1
  name: nginx-v1
data:
  nginx.conf: |-
    worker_processes  1;

    events {
        accept_mutex on;
        multi_accept on;
        use epoll;
        worker_connections  1024;
    }

    http {
        ignore_invalid_headers off;
        server {
            listen 80;
            location / {
                access_by_lua '
                    local header_str = ngx.say("nginx-v1")
                ';
            }
        }
    }

---

apiVersion: v1
kind: Service
metadata:
  name: nginx-v1
spec:
  type: ClusterIP
  ports:
  - port: 80
    protocol: TCP
    name: http
  selector:
    app: nginx
    version: v1

部署yaml并查看

kubectl apply -f 01-deploy-nginx-v1.yaml 
kubectl get pod

在这里插入图片描述
查看service

kubectl get svc

在这里插入图片描述
看看能不能访问到

curl 10.109.30.198

在这里插入图片描述

2.v2版本部署
vim 02-deploy-nginx-v2.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-v2
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
      version: v2
  template:
    metadata:
      labels:
        app: nginx
        version: v2
    spec:
      containers:
      - name: nginx
        image: "openresty/openresty:centos"
        ports:
        - name: http
          protocol: TCP
          containerPort: 80
        volumeMounts:
        - mountPath: /usr/local/openresty/nginx/conf/nginx.conf
          name: config
          subPath: nginx.conf
      volumes:
      - name: config
        configMap:
          name: nginx-v2
---

apiVersion: v1
kind: ConfigMap
metadata:
  labels:
    app: nginx
    version: v2
  name: nginx-v2
data:
  nginx.conf: |-
    worker_processes  1;

    events {
        accept_mutex on;
        multi_accept on;
        use epoll;
        worker_connections  1024;
    }

    http {
        ignore_invalid_headers off;
        server {
            listen 80;
            location / {
                access_by_lua '
                    local header_str = ngx.say("nginx-v2")
                ';
            }
        }
    }

---

apiVersion: v1
kind: Service
metadata:
  name: nginx-v2
spec:
  type: ClusterIP
  ports:
  - port: 80
    protocol: TCP
    name: http
  selector:
    app: nginx
    version: v2

应用yaml文件并查看

kubectl apply -f 02-deploy-nginx-v2.yaml 
kubectl get pods

在这里插入图片描述
查看service

kubectl get svc

在这里插入图片描述
测试

curl 10.105.171.163

在这里插入图片描述

3.创建stable版本ingress资源对象（对外发布）
vim 03-stable-ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-v1                    #自定义ingress名称
  namespace: default
spec:
  ingressClassName: nginx
  rules:
  - host: www.test.com                   # 自定义域名
    http:
      paths:
      - pathType: Prefix
        path: "/"
        backend:
          service:
            name: nginx-v1    # 对应上面创建的service名称
            port:
              number: 80

应用ingress.yaml文件并查看

kubectl apply -f 03-stable-ingress.yaml
kubectl -n ingress-nginx get svc

在这里插入图片描述
在hosts添加域名解析

vim /etc/hosts

添加
192.168.10.240 www.test.com
在这里插入图片描述
测试

curl www.test.com

在这里插入图片描述
创建目录并进入

mkdir nginx && cd nginx

四、流量切分

1.基于服务权重的流量切分

效果就是百分之九十的流量访问v1
百分之十的流量访问v2

创建yaml文件

vim 04-canary-ingress-weight.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-v2                    #自定义ingress名称
  namespace: default
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "10"
spec:
  ingressClassName: nginx
  rules:
  - host: www.test.com                   # 自定义域名
    http:
      paths:
      - pathType: Prefix
        path: "/"
        backend:
          service:
            name: nginx-v2    # 对应上面创建的service名称
            port:
              number: 80

应用yaml文件

kubectl apply -f 04-canary-ingress-weight.yaml
kubectl get ingress

注：虽然这里显示的是192.168.10.13但实际上还是通过域名访问到192.168.10.240的
在这里插入图片描述
测试
简单的shell脚本应用，测试10次

for i in {1..10};do curl http://www.test.com;done

虽然设置的是百分之十的流量，但实际应用不一定是10个里只有一个访问v2

在这里插入图片描述

2.基于用户请求头Header的流量切分

效果就是来自shenzhen的用户访问v2
其他访问v1

为了不影响，先删除上个yaml文件生成的应用，然后创建新的yaml文件

kubectl delete -f 04-canary-ingress-weight.yaml
vim 05-canary-ingress-header.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-v2                    #自定义ingress名称
  namespace: default
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-by-header: "Region"
    nginx.ingress.kubernetes.io/canary-by-header-pattern: "shenzhen"
spec:
  ingressClassName: nginx
  rules:
  - host: www.test.com                   # 自定义域名
    http:
      paths:
      - pathType: Prefix
        path: "/"
        backend:
          service:
            name: nginx-v2    # 对应上面创建的service名称
            port:
              number: 80

应用新的yaml文件并查看

kubectl apply -f 05-canary-ingress-header.yaml 
kubectl get ingress

在这里插入图片描述
测试
-H 大概意思就是模拟请求头内容

curl www.test.com
curl -H "Region:beijing" www.test.com
curl -H "Region:shanghai" www.test.com
curl -H "Region:shenzhen" www.test.com

可以看到效果
在这里插入图片描述

3.基于Cookie的流量切分

使用 Cookie 则无法自定义 value，以模拟灰度shenzhen地域用户为例，仅将带有名为 user_from_shenzhen的 Cookie 的请求转发给当前 Canary Ingress

照旧

kubectl delete -f 05-canary-ingress-header.yaml 
vim 06-canary-ingress-cookie.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-v2                    #自定义ingress名称
  namespace: default
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-by-cookie: "user_from_shenzhen"
spec:
  ingressClassName: nginx
  rules:
  - host: www.test.com                   # 自定义域名
    http:
      paths:
      - pathType: Prefix
        path: "/"
        backend:
          service:
            name: nginx-v2    # 对应上面创建的service名称
            port:
              number: 80

应用yaml文件并查看

kubectl apply -f 06-canary-ingress-cookie.yaml
kubectl get ingress

在这里插入图片描述
测试

curl --cookie "user_from_beijing" http://www.test.com
curl --cookie "user_from_shenzhen" http://www.test.com
curl --cookie "user_from_shenzhen=always" http://www.test.com

在这里插入图片描述

可查看当仅有 cookie user_from_shenzhen 为 always 的请求才由 v2 版本的服务响应。

至此 完成

总结

每种发布策略都有其特定的优缺点，选择合适的策略需要根据项目规模、团队能力和业务需求来综合考虑。蓝绿发布适合对稳定性要求极高的项目，A/B 测试适合需要数据驱动决策的功能优化，金丝雀发布则适合希望逐步发布、降低风险的场景。通过合理运用这些策略，可以有效提升发布过程的效率和质量。

# kubernetes # 学习 # nginx # 云原生 # 运维 # linux
Logo
K8S/Kubernetes

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐

【深度】阿里巴巴万级规模 K8s 集群全局高可用体系之美

作者 |  韩堂、柘远、沉醉来源 | 阿里巴巴云原生公众号​前言台湾作家林清玄在接受记者采访的时候，如此评价自己 30 多年写作生涯：“第一个十年我才华横溢，‘贼光闪现’，令周边黯然失色；第二个十年，我终于‘宝光现形’，不再去抢风头，反而与身边的美丽相得益彰；进入第三个十年，繁华落尽见真醇，我进入了‘醇光初现’的阶段，真正体味到了境界之美”。​长夜有穷，真水无香。领略过了 K8s“身在江

avatar K8S/Kubernetes

如何基于 K8s 构建下一代 DevOps 平台？

作者 | 孙健波（天元）导读：当前云原生 DevOps 体系现状如何？面临哪些挑战？如何通过 OAM 解决云原生 DevOps 场景下的诸多问题？云原生开发应用模型 OAM(Open Application Model) 社区核心成员孙健波将为大家一一解答，并分享如何基于 OAM 和 Kubernetes 打造无限能力的下一代 DevOps 平台。什么是 DevOps？为什么基于 Kub

avatar K8S/Kubernetes

k8s 火了！

2020，上云之年，产品云端化成为一种趋势。在一线城市，很多公司都已经构建了自己的私有云环境，比如阿里云、网易云、华为云等。而Kubernetes 作为基于容器编排领域的王者，具备扩展...

avatar K8S/Kubernetes