【云原生系列之kubernetes】--探针的使用

kubernetes–探针

1、pod状态

1. 发出新建pod的请求
2. 调度资源
3. 将事件和node绑定并写入etcd中
4. node节点上的kubelet和kube-proxy进行pod创建、网络规则的维护
5. kubelet调用runc(docker/containerd)创建pod
6. pod回收

第一阶段

• pending：正在创建pod但是pod中的容器还没有全部被创建完成，主要是外部资源分配出问题了（检查pod的存储挂载，镜像下载，调度是否正常）
• Failed：pod中的容器启动失败导致pod工作异常
• Unknow：由于某种原因无法获得pod当前状态，通常是node节点通讯错误
• Succeed：pod中所有容器都没成功终止，即pod里所有的containers均被terminated,这个状态存在的时间非常短

第二阶段

• Unschedulabel：pod不能被调度，kube-scheduler没有匹配到合适的node节点
• podscheduled：pod正处于调度中，在kube-scheduler刚开始调度的时候，还没有将pod分配到指定的node，在筛选出合适的节点后会更新etcd数据，将pod分配到指定的node节点
• Initalized ：所有pod中的初始化容器已经完成
• ImagePullBackOff ：pod所在节点下载镜像失败
• Running：pod内部容器已经被创建启动
• Ready：表示pod中容器已经可以提供访问服务了

其他状态

Error: pod 启动过程中发生错误
NodeLost: pod 所在节点失联
Unknow: pod 所在节点失联或者其他未知异常
Waiting: pod 等待启动
Pending: pod 等待被调度,基本是外部资源获取有问题.
Terminating: Pod 等待被销毁,是否有其他服务占用.
CrashLoopBackOff: Pod启动失败,但kubelet正在将它重启
InvalidImageNmae: node节点无法解析镜像名称导致镜像无法下载
ImageInspectError: 无法校验镜像,镜像不完整导致
ErrorImageNeverPull: 策略禁止拉取镜像,镜像中心权限是私有等
ImagePullBackOff: 镜像拉取失败,尝试重新拉取
RegistryUnavailable: 镜像服务器不可用,网络原因或harbor宕机
ErrorIImagePull: 镜像拉取出错,超时或下载被强制终止
CreateContainerConfigErrror: 不能创建kubelet使用的容器配置
CreateContainerError: 创建容器失败
PreStartContainer: 执行preStart hook报错,Pod hook是由Kubernetes管理的kubelet发起的,当容器中的进程启动前或者容器中的进程终止之前运行,比如容器创建完成后里面的服务启动之前可以检查一下依赖的其他服务是否启动,或者容器退出之前可以把容器中的服务先通过命令停止爱
PostStartHookError: 执行 posstStart hook报错
RunContainerError: pod运行失败,容器中没有初始化pid为1的守护进程等.
ContainersNotInitialized: pod没有初始化完毕
ContainersNotReady: pod没有准备完毕
ContainerCreating: pod正在创建中
PodInitializing: pod正在初始化中
DockerDaemonNotReady: node节点docker服务没有启动
NetworkPluginNotReady: 网络插件还没有启动
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

2、探针

探针是由kubelet对容器执行的定时诊断，以保证Pod的状态始终处于运行状态，要执行诊断，kubelet调用由容器实现的handler（处理程序）

探测的方式

1. ExecAction:在容器内执行指定命令，如果命令退出时返回码为0，则认为诊断成功
2. TCPSocketAction:对指定端口上的容器IP地址进行TCP检查，如果端口打开在，则诊断被认为是成功的
3. HTTPGetAction：对指定的端口和路径上的容器的IP地址执行HTTPGet请求，如果响应码的值大于等于200且小于400，则诊断被认为成功的

每次探测都将获得以下三种结果之一：

• 成功：容器通过了诊断
• 失败：容器未能通过诊断
• 未知：诊断失败，因此不会采取任何行动

2.1 探针类型

• startupProbe：启动探针，检测容器是否启动成功，如果容器启动失败，kubelet将杀死容器，容器将服从其重启策略。如果启动了容器启动探针则其他的探针就无法使用，直达启动探针检测成功。（注意：如果启动探针检测成功后将会自动退出，不会再对容器进行检测）
• livenessProbe：存活探针， 检查容器是否正常运行,如果存活探针失败,则kubelet杀死容器,并且容器将收到器重启策略影响.如果容器不提供存活探针,则默认状态为success,livenessProbe用于控制是否重启pod （判断容器状态是否正常）
• readinessProbe：就绪探针，就绪探针,如果就绪探测失败,端点控制器将从与pod匹配的所有Service的端点中删除该pod的ip地址,初始延迟之前的就绪状态默认为Failure(失败)如果容器不提供就绪探针,则默认状态为success,readinessProbe用于控制pod是否添加至service（判断容器里的业务能否被正常访问）

注意： 存活探测情况下的失败就意味着重新启动容器，就绪探测情况下的失败就意味着pod就会被打上未就绪的标签。

2.2 探针的配置

initialDelaySeconds: 120  #初始化延迟时间，默认是0s，最小是0s
periodSeconds: 60  #探测周期间隔时间，指定了kebelet每隔多少秒执行一次存活探测，默认是10秒，最小是1s，类似haproxy中的inter
timeoutSeconds: 5  #单次探测超时时间，探测的超时后等待多少秒，默认1秒，最小1秒
successThreshold: 1 #从失败转为成功的重试次数，探测器失败后，被视为成功的最小连续成功数，默认是1，,存活探测的这个值必须是1,最小值是1.类似于haproxy的rise
failurThreshold: 3  #从成功转为失败的重试次数，当pod启动了并且探测失败，kubernetes的重试次数，存活探测情况下的放弃就意味着重启容器，就绪探测情况下放弃pod就会被打上未就绪的标签，默认值是3，最小值是1
1
2
3
4
5

http探测器可以在HTTPGetAction上配置字段

host:连接使用的主机名，默认是pod的IP,也可以使用HTTP头中设置的Host值代替
scheme：连接主机方式（http/https),默认是http
path:访问http服务的路径
httpHeaders:请求中定义的HTTP头
port:访问容器的端口号或者端口名
1
2
3
4
5

3、探针案例

3.1 Http探针

root@master1:~/yaml/pod# cat pod-http.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment-80
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx-deploy
  template:
    metadata:
      labels:
        app: nginx-deploy
    spec:
      containers:
      - name: nginx-deploy
        image: nginx
        ports:
        - containerPort: 80
        readinessProbe:
          httpGet:
            path: /index.html
            port: 80
          initialDelaySeconds: 5 #初始化延迟的时间5s（默认0秒）
          periodSeconds: 3 #每隔3s执行一次存活探测
          timeoutSeconds: 5 #单次探测超时时间为5s
          successThreshold: 1 # 成功的次数
          failureThreshold: 3 # 允许失败的次数
        livenessProbe:
          httpGet:
            path: /index.html
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 3
          timeoutSeconds: 5
          successThreshold: 1
          failureThreshold: 3
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  ports:
  - name: http
    port: 81
    targetPort: 80
    nodePort: 30020
  type: NodePort
  selector: 
    app: nginx-deploy

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

探测成功的结果：

删除了index.html文件后，探测失败的结果

watch -n 1 kubectl get ep
1

由于镜像本身就有，此时被删除的index.html探针检查一会又将恢复正常.在重建没有完成时,通过service继续访问该pod会有403的报错.

3.2 TCP探针

使用tcpSocket进行检测

root@master1:~/yaml/pod# cat pod-tcp.yaml 
apiVersion: apps/v1
kind: Deployment
metadata: 
  name: nginx-deploy
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx-deploy-tcp
  template:
    metadata:
      labels:
        app: nginx-deploy-tcp
    spec:
      containers:
      - name: deploy-nginx
        image: nginx
        ports:
        - containerPort: 80
        livenessProbe:
          tcpSocket:
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 3
          timeoutSeconds: 5
          successThreshold: 1
          failureThreshold: 3
        readinessProbe:
          tcpSocket:
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 3
          timeoutSeconds: 5
          successThreshold: 1
          failureThreshold: 3

---
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  ports:
  - name: http
    port: 81
    targetPort: 80
    nodePort: 30021
    protocol: TCP
  type: NodePort
  selector:
    app: nginx-deploy-tcp
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52

如果把探测的端口改为88就会出现以下情况：

3.3 ExecAction探针

某些情况下通过端口判断并不是很准确,同时服务又没法使用httpget的方式获取服务状态.这时就采用execaction方式,通过一条或多条命令的执行结果进行判断服务是否正常.

root@master1:~/yaml/pod# cat pod-execAction.yaml
apiVersion: apps/v1
kind: Deployment
metadata: 
  name: deploy-redis
spec:
  replicas: 1
  selector:
    matchLabels:
      app: deploy-redis
  template:
    metadata:
      labels:
        app: deploy-redis
    spec:
      containers:
      - name: redis-deploy
        image: redis
        ports:
        - containerPort: 6379
        livenessProbe:
          exec:
            command:
            - /usr/local/bin/redis-cli
            - quit
          initialDelaySeconds: 5
          periodSeconds: 3
          timeoutSeconds: 5
          successThreshold: 1
          failureThreshold: 3
  
        readinessProbe:
          exec:
            command:
            - /usr/local/bin/redis-cli
            - quit
          initialDelaySeconds: 5
          periodSeconds: 3
          timeoutSeconds: 5
          successThreshold: 1 
          failureThreshold: 3

---
apiVersion: v1
kind: Service
metadata:
  name: redis-service
spec:
  ports:
    - name: http
      port: 82
      targetPort: 6379
      nodePort: 30022
      protocol: TCP
  type: NodePort
  selector:
    app: deploy-redis
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57