本文主要是介绍架构师系列-k8s（三）-k8s健康检查及探针，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
6. 健康检查
强大的自愈能力是Kubernetes这类容器编排引擎的一个重要特性，自愈的默认实现方式是自动重启发生故障的容器。
6.1 为什么需要健康检查
用户还可以利用Liveness和Readiness探测机制设置更精细的健康检查,进而实现如下需求:
- 零停机部署。
- 避免部署无效的镜像。
- 更加安全的滚动升级。
6.2 检查策略
在Pod部署到Kubernetes集群中以后，为了确保Pod处于健康正常的运行状态，Kubernetes提供了两种探针，用于检测容器的状态：
6.2.1 存活探测
Liveness是检查容器是否处于运行状态，如果检测失败，kubelet将会杀掉掉容器，并根据重启策略进行下一步的操作，如果容器没有提供Liveness Probe，则默认状态为Success；
Liveness探测器是让Kubernetes知道你的应用是否活着，如果你的应用还活着，那么Kubernetes就让它继续存在，如果你的应用程序已经死了，Kubernetes将移除Pod并重新启动一个来替换它。
让我们想象另一种情况，当我们的应用在成功启动以后因为一些原因“宕机”，或者遇到死锁情况，导致它无法响应用户请求。 在默认情况下，Kubernetes会继续向Pod发送请求，通过使用存活探针来检测，当发现服务不能在限定时间内处理请求（请求错误或者超时），就会重新启动有问题的pod。
6.2.2 就绪探测
Readiness 是检查容器是否已经处于可接受服务请求的状态，如果Readiness Probe失败，端点控制器将会从服务端点（与Pod匹配的）中移除容器的IP地址，Readiness的默认值为Failure，如果一个容器未提供Readiness，则默认是Success。
就绪探针旨在让Kubernetes知道你的应用是否准备好为请求提供服务，Kubernetes只有在就绪探针通过才会把流量转发到Pod，如果就绪探针检测失败，Kubernetes将停止向该容器发送流量，直到它通过。
一个应用往往需要一段时间来预热和启动，比如一个后端项目的启动需要连接数据库执行数据库迁移等等，一个Spring项目的启动也需要依赖Java虚拟机。即使该过程已启动，您的服务在启动并运行之前也无法运行。应用在完全就绪之前不应接收流量，但默认情况下，Kubernetes会在容器内的进程启动后立即开始发送流量。通过就绪探针探测，直到应用程序完全启动，然后才允许将流量发送到新副本。
6.2.3 两者对比
- Liveness探测和Readiness探测是两种Health Check机制,如果不特意配置,Kubernetes将对两种探测采取相同的默认行为,即通过判断容器启动进程的返回值是否为零来判断探测是否成功。
- 两种探测的配置方法完全一样,支持的配置参数也一样，不同之处在于探测失败后的行为:Liveness探测是重启容器;Readiness探测则是将容器设置为不可用,不接收Service转发的请求。
- Liveness探测和Readiness探测是独立执行的,二者之间没有依赖,所以可以单独使用,也可以同时使用，用Liveness探测判断容器是否需要重启以实现自愈;用Readiness探测判断容器是否已经准备好对外提供服务
6.2.4 如何配置
对于LivenessProbe和ReadinessProbe用法都一样，拥有相同的参数和相同的监测方式。
- initialDelaySeconds：用来表示初始化延迟的时间，也就是告诉监测从多久之后开始运行，单位是秒
- timeoutSeconds: 用来表示监测的超时时间，如果超过这个时长后，则认为监测失败
- periodSeconds：指定每多少秒执行一次探测，Kubernetes如果连续执行3次Liveness探测均失败,则会杀掉并重启容器
6.3 使用场景
- 如果容器中的进程能够在遇到问题或不健康的情况下自行崩溃，则不一定需要存活探针; kubelet 将根据 Pod 的
restartPolicy自动执行正确的操作。 - 如果希望容器在探测失败时被杀死并重新启动，那么请指定一个存活探针，并指定
restartPolicy为 Always 或 OnFailure。 - 如果要仅在探测成功时才开始向 Pod 发送流量，请指定就绪探针，在这种情况下，就绪探针可能与存活探针相同，但是 spec 中的就绪探针的存在意味着 Pod 将在没有接收到任何流量的情况下启动，并且只有在探针探测成功后才开始接收流量。
- 如果您希望容器能够自行维护，您可以指定一个就绪探针，该探针检查与存活探针不同的端点。
- 如果您只想在 Pod 被删除时能够排除请求，则不一定需要使用就绪探针；在删除 Pod 时，Pod 会自动将自身置于未完成状态，无论就绪探针是否存在，当等待 Pod 中的容器停止时，Pod 仍处于未完成状态。
6.4 默认的健康检查
我们首先学习Kubernetes默认的健康检查机制:每个容器启动时都会执行一个进程,此进程由Dockerfile的CMD或ENTRYPOINT指定。
如果进程退出时返回码非零,则认为容器发生故障,Kubernetes就会根据restartPolicy重启容器
6.4.1 创建资源清单
Pod的restartPolicy设置为OnFailure,默认为Always，sleep 10; exit 1模拟容器启动10秒后发生故障
vi pod-default-health.ymlapiVersion: v1
kind: Pod
metadata:name: pod-default-healthnamespace: defaultlabels:app: nginx
spec:containers:- name: nginximage: nginx:1.12ports: - containerPort: 80args: ["/bin/sh","-c"," sleep 10;exit 1"]6.4.2 创建容器
kubectl apply -f pod-default-health.yml
6.4.3 监控Pod变化
kubectl get pods -o wide -w
该命令可以不断显示容器的因为失败不断重启
在上面的例子中，容器进程返回值非零，Kubernetes则认为容器发生故障,需要重启。
有不少情况是发生了故障,但进程并不会退出，比如访问Web服务器时显示500内部错误,可能是系统超载,也可能是资源死锁,此时httpd进程并没有异常退出,在这种情况下重启容器可能是最直接、最有效的解决方案,那我们如何利用HealthCheck机制来处理这类场景呢?
6.5 探针类型
探针类型是指通过何种方式来进行健康检查，K8S有三种类型的探测：HTTP，Command和TCP。
6.5.1 exec存活探针
对于命令探测，是指Kubernetes在容器内运行命令，如果命令以退出代码0返回，则容器将标记为正常。否则，它被标记为不健康
下面的资源会在先创建一个nginx的任务，生存测试探针livenessProbe会执行test -e /tmp/healthy命令检查文件是否存在， 若文件存在则返回状态码 0，表示成功通过测试。
apiVersion: v1
kind: Pod
metadata:name: pod-nginx-demonamespace: defaultlabels:app: nginx
spec:containers:- name: nginximage: nginx:1.12ports: - containerPort: 80livenessProbe:initialDelaySeconds: 5periodSeconds: 3exec:command: ["test","-e","/tmp/healthy"]6.5.1.1 创建pod
创建pod
kubectl create -f pod-demo.yaml
kubectl get pod -w -o wide 启动后不断检测/tmp/healthy是否存在，不存在重启容器
6.5.1.2 创建文件
新开一个窗口写入登录pod容器，写入
healthy文件
# 登录pod容器
kubectl exec pod-nginx-demo -it /bin/bash
echo healthy > /tmp/healthy
# 在html目录写入healthy文件
echo healthy > /tmp/healthy查看原来的pod状态
kubectl get pods -o wide -w
我们发现pod不在不断地重启了
6.5.2 HTTP就绪探针
HTTP探测可能是最常见的探针类型，即使应用不是HTTP服务，也可以创建一个轻量级HTTP服务器来响应探测，比如让Kubernetes通过HTTP访问一个URL，如果返回码在200到300范围内，就将应用程序标记为健康状态，否则它被标记为不健康。
上面 清单 文件 中 定义 的 httpGet 测试 中， 请求的资源路径 为/healthy， 地址 默认 为 Pod IP， 端口使用了容器中定义的端口名称 HTTP， 这也是明确为容器指明要暴露的端口的用途之一。
apiVersion: v1
kind: Pod
metadata:name: pod-nginx-demonamespace: defaultlabels:app: nginx
spec:containers:- name: nginximage: nginx:1.12ports: - containerPort: 80readinessProbe:initialDelaySeconds: 5periodSeconds: 3httpGet:port: 80path: /healthyscheme: HTTP6.5.2.1 创建pod
kubectl create -f pod-demo.yaml #查看pod状态 kubectl get pods -o wide -w
我们发现nginx 一致处于未未就绪状态
6.5.2.2 查看pod详情
kubectl describe pod pod-nginx-demo
6.5.2.3 创建文件
新开一个窗口写入登录pod容器，写入
healthy文件
# 登录pod容器
kubectl exec pod-nginx-demo -it /bin/bash
# 在html目录写入healthy文件
echo healthy > /usr/share/nginx/html/healthy查看原来的pod状态
6.5.2.4 访问
curl 10.244.1.30/healthy
再次删除
healthy文件
rm -f /usr/share/nginx/html/healthy
再次查看pod状态，进入未就绪状态
kubectl get pods -o wide -w
6.5.3 TCP探针
TCP探测是指Kubernetes尝试在指定端口上建立TCP连接。
如果它可以建立连接，容器被认为是健康的; 如果它不能被认为是不健康的。
这常用于对gRPC或FTP服务的探测。
下面的资源清单文件，向Pod IP的80/tcp端口发起连接请求，并根据连接建立的状态判断Pod存活状态。
apiVersion: v1
kind: Pod
metadata:name: pod-nginx-demonamespace: defaultlabels:app: nginx
spec:containers:- name: nginximage: nginx:1.12ports: - containerPort: 80livenessProbe:tcpSocket:port: 806.5.3.1 探测结果
每次探测都将获得以下三种结果之一：
- 成功：容器通过了诊断。
- 失败：容器未通过诊断。
- 未知：诊断失败，因此不会采取任何行动。
6.5.3.2 创建pod
kubectl create -f pod-demo.yaml
#查看pod状态
kubectl get pods -o wide -w只要80端口正常一致就是正常状态
这篇关于架构师系列-k8s（三）-k8s健康检查及探针的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
