四、健康检查、调度约束

一、健康检查
Probe有以下两种类型：
livenessProbe
如果检查失败，将杀死容器，根据Pod的restartPolicy来操作。Liveness 探测可以告诉 Kubernetes 什么时候通过重启容器实现自愈
readinessProbe
如果检查失败，Kubernetes会把Pod从service endpoints中剔除。Readiness 探测则是告诉 Kubernetes 什么时候可以将容器加入到 Service 负载均衡池中，对外提供服务。

下面对 Liveness 探测和 Readiness 探测做个比较：
Liveness 探测和 Readiness 探测是两种 Health Check 机制，如果不特意配置，Kubernetes 将对两种探测采取相同的默认行为，即通过判断容器启动进程的返回值是否为零来判断探测是否成功。
两种探测的配置方法完全一样，支持的配置参数也一样。不同之处在于探测失败后的行为：Liveness 探测是重启容器；Readiness 探测则是将容器设置为不可用，不接收 Service 转发的请求。
Liveness 探测和 Readiness 探测是独立执行的，二者之间没有依赖，所以可以单独使用，也可以同时使用。用 Liveness 探测判断容器是否需要重启以实现自愈；用 Readiness 探测判断容器是否已经准备好对外提供服务。
1、Health Check 在 Scale Up 中的应用
　　对于多副本应用，当执行 Scale Up 操作时，新副本会作为 backend 被添加到 Service 的负责均衡中，与已有副本一起处理客户的请求。考虑到应用启动通常都需要一个准备阶段，比如加载缓存数据，连接数据库等，从容器启动到正真能够提供服务是需要一段时间的。我们可以通过 Readiness 探测判断容器是否就绪，避免将请求发送到还没有 ready 的 backend。
2、Health Check 另一个重要的应用场景是 Rolling Update
　　试想一下下面的情况，现有一个正常运行的多副本应用，接下来对应用进行更新（比如使用更高版本的 image），Kubernetes 会启动新副本，然后发生了如下事件：
正常情况下新副本需要 10 秒钟完成准备工作，在此之前无法响应业务请求。
但由于人为配置错误，副本始终无法完成准备工作（比如无法连接后端数据库）。
因为新副本本身没有异常退出，默认的 Health Check 机制会认为容器已经就绪，进而会逐步用新副本替换现有副本，其结果就是：当所有旧副本都被替换后，整个应用将无法处理请求，无法对外提供服务。如果这是发生在重要的生产系统上，后果会非常严重。
如果正确配置了 Health Check，新副本只有通过了 Readiness 探测，才会被添加到 Service；如果没有通过探测，现有副本不会被全部替换，业务仍然正常进行。

Probe支持以下三种检查方法：
httpGet，发送HTTP请求，返回200-400范围状态码为成功。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx1-deployment
  namespace: default
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx1
  template:
    metadata:
      labels:
        app: nginx1
    spec:
      nodeSelector:
        app: dev
      containers:
      - name: nginx1
        image: nginx:1.15
        livenessProbe: #健康检查
          httpGet:  #发送http请求,请求uri和端口
            path: /
            port: 8080
          initialDelaySeconds: 3 #容器启动后3秒开始检查
          periodSeconds: 3       #检查周期3秒
          timeOutSeconds: 3      #超时时间
        ports:
        - containerPort: 80

readinessProbe:
  httpGet:
    path: /
    port: 80
  initialDelaySeconds: 3
  periodSeconds: 3

exec，执行Shell命令返回状态码是0为成功

livenessProbe:
  exec:
    command:
    - cat
    - /tmp/healthy
  initialDelaySeconds: 5
  periodSeconds: 5
  
readinessProbe:
  exec:
    command:
    - cat
    - /tmp/healthy
  initialDelaySeconds: 5
  periodSeconds: 5 

tcpSocket，发起TCP Socket建立成功

readinessProbe:
  tcpSocket:
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 10
  timeOutSeconds: 3
  
livenessProbe:
  tcpSocket:
    port: 8080
  initialDelaySeconds: 15
  periodSeconds: 20
  timeOutSeconds: 3

二、调度约束

apiVersion: v1
kind: Pod
metadata:
  name: pod-example
  labels:
    app: nginx
spec:
  nodeName: 192.168.31.65
  containers:
  - name: nginx
    image: nginx:1.15

#给node设置标签
kubectl label nodes k8s-node03 app=dev

查看标签

[root@k8s-master01-etcd01 ~]# kubectl get node --show-labels     
NAME         STATUS   ROLES    AGE    VERSION   LABELS
k8s-node01   Ready    <none>   4d5h   v1.16.0   app=dev,beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-node01,kubernetes.io/os=linux
k8s-node02   Ready    <none>   4d5h   v1.16.0   app=dev,beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-node02,kubernetes.io/os=linux
k8s-node03   Ready    <none>   4d5h   v1.16.0   app=ingress-nginx,beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-node03,kubernetes.io/os=linux
k8s-node04   Ready    <none>   4d3h   v1.16.0   app=ingress-nginx,beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-node04,kubernetes.io/os=linux

配置调度

apiVersion: v1
kind: Pod
metadata:
  name: pod-example
spec:
  nodeSelector:
    env_role: dev
  containers:
  - name: nginx
    image: nginx:1.15