一、灰度发布

　　灰度发布是一种发布方式，也叫金丝雀发布，起源是矿工在下井之前会先放一只金丝雀到井里，如果金丝雀不叫了，就代表瓦斯浓度高。原因是金丝雀对瓦斯气体很敏感。灰度发布的做法是：会在现存旧应用的基础上，启动一个新版应用，但是新版应用并不会直接让用户访问。而是先让测试同学去进行测试。如果没有问题，则可以将真正的用户流量慢慢导入到新版，在这中间，持续对新版本运行状态做观察，直到慢慢切换过去，这就是所谓的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.yaml

2）根据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/user

3）基于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/user

4）基于权重切分流量 

　　这种实现原理主要是根据用户请求，通过根据灰度百分比决定是否转发到灰度服务环境中

• 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 。在启动探针运行时，其他所有的探针检测都会失效。

检测方式

1、ExecAction

　　通过在 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-exec

2、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-probe

3、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")});

　　好了今天的内容就到这里了。