灰度发布是一种发布方式，也叫金丝雀发布，起源是矿工在下井之前会先放一只金丝雀到井里，如果金丝雀不叫了，就代表瓦斯浓度高。原因是金丝雀对瓦斯气体很敏感。灰度发布的做法是：会在现存旧应用的基础上，启动一个新版应用，但是新版应用并不会直接让用户访问。而是先让测试同学去进行测试。如果没有问题，则可以将真正的用户流量慢慢导入到新版，在这中间，持续对新版本运行状态做观察，直到慢慢切换过去，这就是所谓的A/B测试。当然，你也可以招募一些灰度用户，给他们设置独有的灰度标示（Cookie，Header），来让他们可以访问到新版应用，当然，如果中间切换出现问题，也应该将流量迅速地切换到老应用上。
1）准备新版本的service拷贝一份deployment文件：
cp deployment-user-v1.yaml deployment-user-v2.yaml
修改之前写过的内容：
apiVersion: apps/v1 #API 配置版本 kind: Deployment #资源类型 metadata: + name: user-v2 #资源名称 spec: selector: matchLabels: + app: user-v2 #告诉deployment根据规则匹配相应的Pod进行控制和管理，matchLabels字段匹配Pod的label值 replicas: 3 #声明一个 Pod,副本的数量 template: metadata: labels: + app: user-v2 #Pod的名称 spec: #组内创建的 Pod 信息 containers: - name: nginx #容器的名称 + image: registry.cn-beijing.aliyuncs.com/zhangrenyang/nginx:user-v2 ports: - containerPort: 80 #容器内映射的端口
然后service的文件内容是这样的：
apiVersion: v1 kind: Service metadata: + name: service-user-v2 spec: selector: + app: user-v2 ports: - protocol: TCP port: 80 targetPort: 80 type: NodePort
启动：
kubectl apply -f deployment-user-v2.yaml service-user-v2.yaml2）根据cookie切分流量
基于 Cookie 切分流量。这种实现原理主要根据用户请求中的 Cookie 是否存在灰度标示 Cookie去判断是否为灰度用户，再决定是否返回灰度版本服务
nginx.ingress.kubernetes.io/canary：可选值为 true / false 。代表是否开启灰度功能nginx.ingress.kubernetes.io/canary-by-cookie：灰度发布 cookie 的 key。当 key 值等于 always 时，灰度触发生效。等于其他值时，则不会走灰度环境 ingress-gray.yaml
我们创建一个ingress-gray.yaml文件：
apiVersion: extensions/v1beta1 kind: Ingress metadata: name: user-canary annotations: kubernetes.io/ingress.class: nginx nginx.ingress.kubernetes.io/rewrite-target: / nginx.ingress.kubernetes.io/canary: "true" nginx.ingress.kubernetes.io/canary-by-cookie: "vip_user" spec: rules: - http: paths: - backend: serviceName: service-user-v2 servicePort: 80 backend: serviceName: service-user-v2 servicePort: 80
使文件生效：
kubectl apply -f ./ingress-gray.yaml
获取外部接口：
kubectl -n ingress-nginx get svc
测试：
curl http://172.31.178.169:31234/user curl http://118.190.156.138:31234/user curl --cookie "vip_user=always" http://172.31.178.169:31234/user3）基于header切分流量
基于 Header 切分流量，这种实现原理主要根据用户请求中的 header 是否存在灰度标示 header去判断是否为灰度用户，再决定是否返回灰度版本服务。
修改下上面的ingress-gray.yml文件即可：
apiVersion: extensions/v1beta1 kind: Ingress metadata: name: user-canary annotations: kubernetes.io/ingress.class: nginx nginx.ingress.kubernetes.io/rewrite-target: / nginx.ingress.kubernetes.io/canary: "true" + nginx.ingress.kubernetes.io/canary-by-header: "name" + nginx.ingress.kubernetes.io/canary-by-header-value: "vip" spec: rules: - http: paths: - backend: serviceName: service-user-v2 servicePort: 80 backend: serviceName: service-user-v2 servicePort: 80
同样的：
kubectl apply -f ingress-gray.yaml curl --header "name:vip" http://172.31.178.169:31234/user4）基于权重切分流量
这种实现原理主要是根据用户请求，通过根据灰度百分比决定是否转发到灰度服务环境中
nginx.ingress.kubernetes.io/canary-weight：值是字符串，为 0-100 的数字，代表灰度环境命中概率。如果值为 0，则表示不会走灰度。值越大命中概率越大。当值 = 100 时，代表全走灰度。
一样一样的，修改下配置参数罢了：
apiVersion: extensions/v1beta1 kind: Ingress metadata: name: user-canary annotations: kubernetes.io/ingress.class: nginx nginx.ingress.kubernetes.io/rewrite-target: / nginx.ingress.kubernetes.io/canary: "true" + nginx.ingress.kubernetes.io/canary-weight: "50" spec: rules: - http: paths: - backend: serviceName: service-user-v2 servicePort: 80 backend: serviceName: service-user-v2 servicePort: 80
测试下：
kubectl apply -f ingress-gray.yaml for ((i=1; i<=10; i++)); do curl http://172.31.178.169:31234/user; done
k8s 会优先去匹配 header ，如果未匹配则去匹配 cookie ，最后是 weight。
二、滚动发布滚动发布，则是我们一般所说的无宕机发布。其发布方式如同名称一样，一次取出一台/多台服务器（看策略配置）进行新版本更新。当取出的服务器新版确保无问题后，接着采用同等方式更新后面的服务器。k8s创建副本应用程序的最佳方法就是部署(Deployment)，部署自动创建副本集(ReplicaSet)，副本集可以精确地控制每次替换的Pod数量，从而可以很好的实现滚动更新。k8s每次使用一个新的副本控制器(replication controller)来替换已存在的副本控制器，从而始终使用一个新的Pod模板来替换旧的pod模板
- 创建一个新的replication controller
- 增加或减少pod副本数量，直到满足当前批次期望的数量
- 删除旧的replication controller
滚动发布的优缺点如下：
- 优点
- 不需要停机更新，无感知平滑更新。
- 版本更新成本小,不需要新旧版本共存
- 缺点
- 更新时间长：每次只更新一个/多个镜像，需要频繁连续等待服务启动缓冲
- 旧版本环境无法得到备份：始终只有一个环境存在
- 回滚版本异常痛苦：如果滚动发布到一半出了问题，回滚时需要使用同样的滚动策略回滚旧版本
我们下面来尝试下，先扩容为10个副本：
kubectl get deploy kubectl scale deployment user-v1 --replicas=10
修改deployment-user-v1.yaml文件：
apiVersion: apps/v1 #API 配置版本 kind: Deployment #资源类型 metadata: name: user-v1 #资源名称 spec: minReadySeconds: 1 + strategy: + type: RollingUpdate + rollingUpdate: + maxSurge: 1 + maxUnavailable: 0 + selector: + matchLabels: + app: user-v1 #告诉deployment根据规则匹配相应的Pod进行控制和管理，matchLabels字段匹配Pod的label值 replicas: 10 #声明一个 Pod,副本的数量 template: metadata: labels: app: user-v1 #Pod的名称 spec: #组内创建的 Pod 信息 containers: - name: nginx #容器的名称 + image: registry.cn-beijing.aliyuncs.com/zhangrenyang/nginx:user-v3 #使用哪个镜像 ports: - containerPort: 80 #容器内映射的端口
启动：
kubectl apply -f ./deployment-user-v1.yaml
deployment.apps/user-v1 configured
然后查看状态：
kubectl rollout status deployment/user-v1三、服务可用性探针
当 Pod 的状态为 Running 时，该 Pod 就可以被分配流量(可以访问到)了。一个后端容器启动成功，不一定不代表服务启动成功。
3.2.1 存活探针 LivenessProbe第一种是存活探针。存活探针是对运行中的容器检测的。如果想检测你的服务在运行中有没有发生崩溃，服务有没有中途退出或无响应，可以使用这个探针。如果探针探测到错误， Kubernetes 就会杀掉这个 Pod；否则就不会进行处理。如果默认没有配置这个探针， Pod 不会被杀死。
3.2.2 可用探针 ReadinessProbe第二种是可用探针。作用是用来检测 Pod 是否允许被访问到（是否准备好接受流量）。如果你的服务加载很多数据，或者有其他需求要求在特定情况下不被分配到流量，那么可以用这个探针。如果探针检测失败，流量就不会分配给该 Pod。在没有配置该探针的情况下，会一直将流量分配给 Pod。当然，探针检测失败，Pod 不会被杀死。
3.2.3 启动探针 StartupProbe第三种是启动探针。作用是用来检测 Pod 是否已经启动成功。如果你的服务启动需要一些加载时长（例如初始化日志，等待其他调用的服务启动成功）才代表服务启动成功，则可以用这个探针。如果探针检测失败，该 Pod 就会被杀死重启。在没有配置该探针的情况下，默认不会杀死 Pod 。在启动探针运行时，其他所有的探针检测都会失效。
通过在 Pod 的容器内执行预定的 Shell 脚本命令。如果执行的命令没有报错退出（返回值为0），代表容器状态健康。否则就是有问题的
我们来新建一个文件,vi shell-probe.yaml，内容如下：
apiVersion: v1 kind: Pod metadata: labels: test: shell-probe name: shell-probe spec: containers: - name: shell-probe image: registry.aliyuncs.com/google_containers/busybox args: - /bin/sh - -c - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600 livenessProbe: exec: command: - cat - /tmp/healthy initialDelaySeconds: 5 periodSeconds: 5
然后执行下面的命令，查看情况：
kubectl apply -f liveness.yaml kubectl get pods | grep liveness-exec kubectl describe pods liveness-exec2、TCPSocketAction
这种方式是使用 TCP 套接字检测。 Kubernetes 会尝试在 Pod 内与指定的端口进行连接。如果能建立连接（Pod的端口打开了），这个容器就代表是健康的，如果不能，则代表这个 Pod 就是有问题的。
创建文件如下，tcp-probe.yaml：
apiVersion: v1 kind: Pod metadata: name: tcp-probe labels: app: tcp-probe spec: containers: - name: tcp-probe image: nginx ports: - containerPort: 80 readinessProbe: tcpSocket: port: 80 initialDelaySeconds: 5 periodSeconds: 10
类似的：
kubectl apply -f tcp-probe.yaml kubectl get pods | grep tcp-probe kubectl describe pods tcp-probe
进入到容器内部：
kubectl exec -it tcp-probe -- /bin/sh
更新apt-get并安装vim：
apt-get update apt-get install vim -y vi /etc/nginx/conf.d/default.conf
修改nginx文件配置，把80端口修改为8080，然后重载一下nginx：
nginx -s reload
看一下状态：
kubectl describe pod tcp-probe3、HTTPGetAction
这种方式是使用 HTTP GET 请求。Kubernetes 会尝试访问 Pod 内指定的API路径。如果返回200，代表容器就是健康的。如果不能，代表这个 Pod 是有问题的。
添加http-probe.yaml文件：
apiVersion: v1 kind: Pod metadata: labels: test: http-probe name: http-probe spec: containers: - name: http-probe image: registry.cn-beijing.aliyuncs.com/zhangrenyang/http-probe:1.0.0 livenessProbe: httpGet: path: /liveness port: 80 httpHeaders: - name: source value: probe initialDelaySeconds: 3 periodSeconds: 3
然后，运行并查看状态：
kubectl apply -f ./http-probe.yaml kubectl describe pods http-probe kubectl replace --force -f http-probe.yaml
Dockerfile内容如下：
FROM node COPY ./app /app WORKDIR /app EXPOSE 3000 CMD node index.js
node服务文件如下：
let http = require('http'); let start = Date.now(); http.createServer(function(req,res){ if(req.url === '/liveness'){ let value = req.headers['source']; if(value === 'probe'){ let duration = Date.now()-start; if(duration>10*1000){ res.statusCode=500; res.end('error'); }else{ res.statusCode=200; res.end('success'); } }else{ res.statusCode=200; res.end('liveness'); } }else{ res.statusCode=200; res.end('liveness'); } }).listen(3000,function(){console.log("http server started on 3000")});
好了今天的内容就到这里了。
站在巨人的肩膀上，希望我可以看的更远。