标签：容器 kubernetes deploy nginx html 健康检查 pod 解析 port

参考：
https://zhuanlan.zhihu.com/p/542202680

一，健康检查种类

在kubernetes中，经常会看到健康检查相关的配置。一般有两种健康检查方式：存活性健康检查和可用性健康检查，也叫做存活探针（livenessProbe）或者就绪探针（readinessProbe）。
livenessProbe探测应用是否处于健康状态，如果不健康会杀掉容器并根据容器策略决定是否重启容器。
readinessProbe探测应用是否就绪并处于正常服务的状态，探测失败后隔离服务（不分配流量）。
startupProbe用于容器启动时判断容器是否启动完成，在这个探针探测成功前，即容器启动成功前，livenessProbe和readinessProbe探针都不会起作用，防止某些启动很慢的容器在启动过程中被检测。
在实际的使用中只需要配置livenessProbe和readinessProbe，通过一段工作中使用到的配置给大家作以说明。

livenessProbe:
  failureThreshold: 3
  httpGet:
    path: /sams/webapi/health
    port: 19201
    scheme: HTTP
  initialDelaySeconds: 120
  periodSeconds: 20
  successThreshold: 1
  timeoutSeconds: 30
readinessProbe:
  failureThreshold: 3
  httpGet:
    path: /sams/webapi/health
    port: 19201
    scheme: HTTP
  initialDelaySeconds: 120
  periodSeconds: 20
  successThreshold: 1
  timeoutSeconds: 30

二，字段含义

字段	含义
ailureThreshold	不正常阈值。检测失败次数超过此值表示容器不健康（默认3次）
httpGet	采用http健康检查的方式
path	服务器上的访问URI
port	容器上要访问端口号
scheme	用于连接host的协议（HTTP或HTTPS），默认为HTTP
initialDelaySeconds	等待时间。从容器启动开始算起到检查开始时间差
periodSeconds	每次探测时间间隔（默认10秒）
successThreshold	正常阈值，失败后检查成功的最小次数，即从错误到正确要多少次表示健康（默认1次）
timeoutSeconds	探测超时时间（默认1秒）
httpHeaders	自定义请求头

三、三种检查方式

kubernetes中每种健康检查有三种方式。上面示例中采用的是httpGet的方式，其他两种为TCP和EXEC。

区别：

http（httpGet）检查方式会向容器中运行的服务发送HTTP GET请求，返回任何大于等于200且小于400的值，均表示健康，反之为不健康。
TCP（tcpSocket）检查方式将连接到容器的某个端口（port），如果探测成功，返回值为0，则该容器是健康的，反之为不健康。
EXEC检查方式会在容器中执行特定的命令（command），如果命令执行成功，则返回0，那么就认为容器是健康的，反之为不健康。

检查结果：

对于两种健康检查方式，有三种检查结果。

结果	含义
Success	通过了检查
Failure	未通过检查
Unknown	未能进行检查，因此不采取任何措施
可以通过pod描述查看检查结果，如下

# kubectl describe pod nginx-deploy-db66ff67c-kt4dx
...
Events:
  Type     Reason     Age                From               Message
  ----     ------     ----               ----               -------
  Normal   Scheduled  68s                default-scheduler  Successfully assigned default/nginx-deploy-db66ff67c-kt4dx to k8s-worker2
  Normal   Pulled     23s (x3 over 67s)  kubelet            Container image "nginx" already present on machine
  Normal   Created    23s (x3 over 67s)  kubelet            Created container mynginx
  Normal   Started    23s (x3 over 67s)  kubelet            Started container mynginx
  Normal   Killing    23s (x2 over 43s)  kubelet            Container mynginx failed liveness probe, will be restarted
  Warning  Unhealthy  12s (x6 over 57s)  kubelet            Readiness probe failed: dial tcp 192.168.126.4:8000: connect: connection refused
  Warning  Unhealthy  8s (x8 over 53s)   kubelet            Liveness probe failed: dial tcp 192.168.126.4:8000: connect: connection refused

四、验证测试

livenessProbe探测应用是否处于健康状态，如果不健康会杀掉容器并根据容器策略决定是否重启容器。

# cat deployment.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx-deploy
  name: nginx-deploy
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx-deploy
  template:
    metadata:
      labels:
        app: nginx-deploy
    spec:
      restartPolicy: Always
      containers:
        - name: mynginx
          image: nginx
          imagePullPolicy: IfNotPresent
          ports:
          - containerPort: 80
          livenessProbe:
            failureThreshold: 3
            httpGet:
              path: /index.html
              port: 80
              scheme: HTTP
            initialDelaySeconds: 10
            periodSeconds: 5
            successThreshold: 1
            timeoutSeconds: 5

部署

# kubectl apply -f deployment.yaml

查看

# kubectl get pod|grep nginx
nginx-deploy-79f6f77ff6-b7rvr             1/1     Running   0          3m19s
nginx-deploy-79f6f77ff6-f4znp             1/1     Running   0          3m19s

创建service用于负载均衡

# kubectl expose deployment nginx-deploy --port=8000 --target-port=80

解析

# 创建service对应的deployment是nginx-deploy
kubectl expose deployment nginx-deploy 
# service的对应的端口是8000
--port=8000
# 对应的容器端口的80 nginx默认启动80端口
--target-port=80

查看service,需要使用下面显示的集群ip加端口访问，只能在node节点访问

# kubectl get svc|grep nginx-deploy
nginx-deploy                                             ClusterIP      10.0.0.52    <none>        8000/TCP          26m

进入pod分别修改两个pod的index.html

# kubectl exec -it nginx-deploy-79f6f77ff6-b7rvr bash
root@nginx-deploy-79f6f77ff6-b7rvr:/# cd /usr/share/nginx/html/
root@nginx-deploy-79f6f77ff6-b7rvr:/usr/share/nginx/html# echo 111 > index.html

另外一个pod修改成222
使用集群ip加端口访问测试,负载均衡第一次访问返回111第二次访问返回222

# curl 10.0.0.52:8000
111
# curl 10.0.0.52:8000
222

删除其中一个pod的index.html会触发pod重启

查看pod的描述可以看到健康检查失败

# kubectl describe pod nginx-deploy-79f6f77ff6-f4znp

访问测试一次返回111一次返回默认的index.html页面

dinessProbe探测应用是否就绪并处于正常服务的状态，探测失败后隔离服务。

# cat deployment2.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx-deploy
  name: nginx-deploy
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx-deploy
  template:
    metadata:
      labels:
        app: nginx-deploy
    spec:
      restartPolicy: Always
      containers:
        - name: mynginx
          image: nginx
          imagePullPolicy: IfNotPresent
          ports:
          - containerPort: 80
          readinessProbe:
            failureThreshold: 3
            httpGet:
              path: /index.html
              port: 80
              scheme: HTTP
            initialDelaySeconds: 10
            periodSeconds: 5
            successThreshold: 1
            timeoutSeconds: 5

部署

# kubectl apply -f deployment2.yaml

进入pod分别修改index.html为111和222
删除一个pod的index.html
容器不会重启，但是服务被隔离了，curl一直返回没有被删除的index.html内容

查看pod状态有一个容器没有重启但是一直处于未准备状态

# kubectl get pod|grep nginx
nginx-deploy-5d9989944-g66m8              1/1     Running   0          4m16s
nginx-deploy-5d9989944-mfc5h              0/1     Running   0          4m16s

查看pod描述

查看endpoint可以看到负载均衡服务被踢出了只剩一个pod提供服务了

六，梳理总结

存活性健康检查在检测失败后杀死容器，可用性健康检查失败后隔离服务（不分配流量）。容器是否重启由容器的重启策略restartPolicy决定的。
三种检查方式配置类似，区别在于方式的不同。HTTP为httpGet，TCP为tcpSocket，EXEC为exec（command）。
如果一个容器不包含存活探针，则Kubelet认为容器的存活探针的返回值永远成功，即永远不会重启。

标签：容器,kubernetes,deploy,nginx,html,健康检查,pod,解析,port
From： https://www.cnblogs.com/minseo/p/17996635

kubernetes健康检查配置解析