云原生 第十一章 应用健康

https://edu.aliyun.com/lesson_1651_18359?spm=5176.10731542.0.0.1eae20beEM00Ky#_18359

Liveness(存活探针)和Readness（就绪探针）

概念

• Liveness
  • Liveness用来判断pod是否就绪【PASS】，如果就绪接入层流量能打到相应的pod
  • Liveness状态为Fail，上层判断机制会判断该pod是否需要被重新拉起restart
  • 判断容器是否存活，如果不存活杀死pod
• Readness
  • 判断容器是否启动完成，pod的condition是ready。如果探测不成功pod会从endpoint移除；探测成功，将pod挂回到endpoint

状态获取方式

• http get，返回码200-399表示应用健康

spec
    containers:
        livenessProbe:
            httpGet:
                path:/healthz
                port:8080
                httpHeaders:
                - name: custom-Header
                  value: Awesome
            initialDelaySeconds: 3
            periodSeconds: 3

• exec 执行容器中的命令来判断当前服务是否正常，命令返回0，表示容器健康

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

• tcpSocket，通过连接容器的ip和port，如果tcp链接正常，则容器健康

spec
    containers:
        livenessProbe:
            tcpsocket:
                port: 8080
            initialDelaySeconds: 5
            periodSeconds: 5
        readinessProbe:
            tcpsocket:
                port: 8080
            initialDelaySeconds: 5
            periodSeconds: 5

yaml参数含义

• initialDelaySeconds：pod 启动延迟多久进行一次检查
• periodSeconds：检测的时间间隔，正常默认的这个值是 10 秒
• timeoutSeconds：当超时时间之内没有检测成功，那它会认为是失败的一个状态
• successThreshold：当这个 pod 从探测失败到再一次判断探测成功，所需要的阈值次数，默认情况下是 1 次，表示原本是失败的，那接下来探测这一次成功了，就会认为这个 pod 是处在一个探针状态正常的一个状态
• failureThreshold：探测失败的重试次数，默认值是 3，表示的是当从一个健康的状态连续探测 3 次失败，那此时会判断当前这个pod的状态处在一个失败的状态

pod健康探测结果

• success
• failure： container 没有通过健康检查，service层会将没有通过Readiness的pod摘除；Liveness将pod直接重新拉起或者删除
• unknown：超时或者一些脚本没及时返回

配置注意事项

• 根据实际情况，设置超时的阈值
• 调整判断次数
• exec：使用编译性的脚本（golang或c、c++编译出来的二进制）比shell脚本效率高30%
• tcpSocket存在TLS隐患

pod的声明周期

• pending
• running
• succeeded
• failed
• unknown

事件有两种

• normal
• warning

常见pod故障

• pod在pending
  • 调度器没有介入
  • kubectl describe pod
• pod在waiting
  • 镜像没拉取下来
• pod在不断拉取，但是backoff
  • pod已经被调度完成，但是启动失败
• pod在running但是不能正常服务
  • 配置错误
  • apply-validate-f pod.yaml 验证yaml
  • 验证端口
  • 查看Liveness和Readiness是否正确
• service异常
  • service后面是不是有真正的endpoint
  • endpoint是否可以正常提供服务

debug命令

• 进入一个正在运行的pod
  • kubectl exec -it pod-name /bin/bash
• 进入一个包含多容器的pod
  • kubectl exec -it pod-name -c container-name /bin/bash
• Service远程调试
  • telepresence工具：
    • telepresence-swap-deployment：将本地的应用代理到远程集群中的一个 service 上面
    • port-forward将远程应用调用到本地端口
• kubectl debug xx-pod
  • 当执行 debug 的时候，首先会先拉取一些镜像，这个镜像里面实际上会默认带一些诊断的工具。当这个镜像启用的时候，把这个 debug container 进行启动。与此同时会把这个 container 和相应的你要诊断的这个 container 的 namespace 进行挂靠，也就说此时这个 container 和你是同 namespace 的，类似像网络站，或者是类似像内核的一些参数，其实都可以在这个 debug container 里面实时地进行查看。

测试题目

https://gitchat.csdn.net/columnTopic/5d8b062b49b2b1063b5594b4

在 Kubernetes 目前支持的哪几种探针？（多选题）AB

• A. Liveness Probe
• B. Readiness Probe
• C. Port Probe
• D. Exec Probe

以下哪个关于 Liveness Probe 的描述是错误的？（多选题） AD

• A. Liveness Probe 是就绪探针
• B. Liveness Probe 是存活探针
• C. Livenss Probe 和 Readiness Probe 的探测方式是一致的
• D. Liveness Probe 主要面向有状态服务

Readiness Probe 在检测失败后会自动从 Endpoint 上摘掉 Pod。（单选题）A

• A. TRUE
• B. FALSE

一个应用可以组合两种探针同时使用。（单选题）A

• A. TRUE
• B. FALSE

当 Pod 处在 Pending的时候，可能是由于如下哪个问题造成的？（多选题）ABD

• A. 资源不足，造成无法调度
• B. Pod 尚未进入调度阶段
• C. Pod 调度失败
• D. Pod 正在拉取镜像

以下哪些方式是常见的应用调试手段？（多选题） ABCD

• A. Exec 进入到 Pod 并进行调试
• B. 使用 Port-Forward 调试远程的服务
• C. 使用 telepresense 将本地应用模拟远程应用进行调试
• D. 使用 kubectl-debug 调试 Pod

一个 service 无法对外提供服务的常见问题可能是？（多选题）ACD

• A. service 和 endpoint 之间的 label 不匹配
• B. service 名字与 Pod 不匹配
• C. service 的后端映射端口不匹配
• D. service 后端 Pod 状态异常

kubectl-debug 如何使用自定义的工具进行 Pod 调试？（单选题）A

• A. 使用自定义镜像
• B. 使用自定义命令
• C. 使用自定义工具
• D. 使用自定义配置

以下哪个方式不是调试 Pod 的方法？（单选题） D

• A. 使用 exec 进入 Pod 进行调试
• B. 查看 Pod 的事件
• C. 查看 Pod 的日志
• D. 查看 Pod 的标签

Readiness Probe 可以解决应用启动慢造成访问异常的问题（单选题） A

• A. TRUE
• B. FALSE