9-1 健康检查---高可用的守护者
容器中pid为1的程序即为入口程序。
采用上一节的pod :web-demo
kubectl get pods -n dev
kubectl exec -it web-demo-f4564954d-4sl9v -n dev bash
即下面的这个服务
杀死这个java服务的进程
kill 14
发现只能访问到新的服务 说明service 在负载均衡的时候,如果后端的服务已经不存在了,那就只能访问到健康的服务,并不会继续轮询,会自动排除有错误的pod。
接着测试kill pid为1的进程
kill 1
发现1的进程无法被kill掉
杀死15 进程
容器自动退出了 说明kubernetes 在没有健康检查的时候,只有当我们的入口程序退出了,kubernetes才会重启容器,其他情况并不会care
重新使用exec 依旧可以进入容器 并且使用get pods可以发现pod的restart 为1
1创建基于cmd命令的健康检查配置。
web-dev-cmd.yaml
#deploy apiVersion: apps/v1 kind: Deployment metadata: name: web-demo namespace: dev spec: selector: matchLabels: app: web-demo replicas: 1 template: metadata: labels: app: web-demo spec: containers: - name: web-demo image: harbor.pdabc.com/kubernetes/web:v3 ports: - containerPort: 8080 # livenessProbe是用于检查健康状态的探针。和容器一个级别,用于检查应用是否存活 livenessProbe: exec: # 命令如果退出值为非0 判断为执行失败认为健康检查没有通过,会进行重启 command: - /bin/sh - -c - ps -ef|grep java|grep -v grep # initialDelaySeconds 等待容器启动10s之后 进行健康检查的命令 initialDelaySeconds: 10 # 健康检查的间隔 保证服务是一直可用的 重要的应用时间会短一点,但是消耗的性能会多一些 periodSeconds: 10 # 失败的容忍次数 失败几次 判断为彻底失败,放弃检查并重启 failureThreshold: 2 # 一旦检查到java 进程又存在了 只要一次就判断它是健康的 successThreshold: 1 # 最长等待时间 timeoutSeconds: 5
启动pod
kubectl apply -f web-dev-cmd.yaml
kubectl describe pod -n dev web-demo-666cc59f7b-9c9bl
看到其中有一条liveness的配置 则说明健康检查已经生效
Liveness: exec [/bin/sh -c ps -ef|grep java|grep -v grep] delay=10s timeout=5s period=10s #success=1 #failure=2
测试健康检查的流程 杀死进程14
容器检测到健康检查有问题杀死了容器 并 重启了一次
通过describe查看日志
kubectl describe pod -n dev web-demo-666cc59f7b-9c9bl
2基于http的健康检查
web-dev-http.yaml
#deploy apiVersion: apps/v1 kind: Deployment metadata: name: web-demo namespace: dev spec: selector: matchLabels: app: web-demo replicas: 1 template: metadata: labels: app: web-demo spec: containers: - name: web-demo image: harbor.pdabc.com/kubernetes/web:v3 ports: - containerPort: 8080 livenessProbe: # http 健康检查方式 如果返回是200判断是正常,302等则判断失败 httpGet: # 应用要访问的路径 path: /examples/index.html # 应用的容器的端口,本身真实的端口 port: 8080 scheme: HTTP initialDelaySeconds: 5 periodSeconds: 5 failureThreshold: 1 successThreshold: 1 timeoutSeconds: 5
创建web-dev-http.yaml
发现pod会重启 查看日志 发现请求超时 因为5秒内 pod并没有启动成功
可以通过增加initialDelaySeconds时长和failureThreshold 次数
pod在重启的时候 是不会漂移的,会一直在同一台机子上
3 tcp健康检查端口是否处于监听状态
web-dev-tcp.yaml
apiVersion: apps/v1 kind: Deployment metadata: name: web-demo namespace: dev spec: selector: matchLabels: app: web-demo replicas: 1 template: metadata: labels: app: web-demo spec: containers: - name: web-demo image: harbor.pdabc.com/kubernetes/web:v3 ports: - containerPort: 8080 livenessProbe: tcpSocket: port: 8080 initialDelaySeconds: 20 periodSeconds: 10 failureThreshold: 2 successThreshold: 1 timeoutSeconds: 5
启动并查看
修改web-dev-tcp.yaml
apiVersion: apps/v1 kind: Deployment metadata: name: web-demo namespace: dev spec: selector: matchLabels: app: web-demo replicas: 1 template: metadata: labels: app: web-demo spec: containers: - name: web-demo image: harbor.pdabc.com/kubernetes/web:v3 ports: - containerPort: 8080 livenessProbe: tcpSocket: port: 8080 initialDelaySeconds: 20 periodSeconds: 10 failureThreshold: 2 successThreshold: 1 timeoutSeconds: 5 # 用于负载均衡的检测 检测通过就放到负载均衡上 readinessProbe: httpGet: path: /examples/index.html port: 8080 scheme: HTTP initialDelaySeconds: 20 periodSeconds: 10 failureThreshold: 2 successThreshold: 1 timeoutSeconds: 5
修改并启动后 发现pod处于running但是并不是ready状态 说明ready状态没有通过检查
等过一会通过健康检查了之后 再访问界面就可以了,加入了负载均衡
kubectl get deploy -n dev
readinessProbe 影响的是deploy中available的值 如果没通过readinessProbe检查 那就是0
当工作中容器遇到restart的情况时,如果这个restart 发生频率非常低,可以把restart策略从always 改成never,以便保留现场.如果是稳定复现,类似于起不来的这种情况,可以把readinessProbe去掉或者配制成简单的检查命令,避免容器被重启,从而登陆到容器里进行调试.