容器探针

容器探测时pod对象生命周期中的一项重要的日常任务，它是kubelet对容器周期性执行的健康状态诊断，诊断操作由容器的处理器进行定义。k8s支持三种容器探针用于pod探测：

• ExecAction：在容器中执行一个命令，并根据其返回的状态码进行诊断的操作称为Exec探测，状 态码为0表示成功，否则即为不健康状态
• TCPSocketAction：通过与容器的某TCP端口尝试建立连接进行诊断，端口能够成功打开即为正 常，否则为不健康状。
• HTTPGetAction：通过向容器IP地址的某指定端口的指定path发起HTTP GET请求进行诊断，响应 码大于等于200且小于400时即为成功

任何一种探测方式都可能存在三种结果：

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

kubelet可在活动容器上执行两种类型的检测：

• (livenessProbe)存活性检测：用于判定容器是否处于运行状态，一旦此类检测未通过，kubelet将杀死容器并根据restartPolicy决定是否将其重启；未定义存活性检测的容器的默认状态未success
• (readinessProbe)就绪性检测：用于判断容器是否准备就绪并可对外提供服务；未通过检测的容器意味着尚未准备就绪，端点控制器会将其IP从所有匹配到此pod对象的service对象的端点列表中移除；检测通过之后，会再次将其IP添加至端点列表中。

案例

准备镜像

docker pull busybox:1.32.0
docker pull nginx:1.17.10-alpine
           

readinessProbe(就绪检测)

readinessprobe.yml

apiVersion: v1
kind: Pod
metadata:
  name: readinessprobe-test
  labels:
    app: readinessprobe-test
spec:
  containers:
    - name: readinessprobe-test
      image: nginx:1.17.10-alpine
      imagePullPolicy: IfNotPresent
      readinessProbe:
        httpGet:
          port: 80
          path: /index1.html
        initialDelaySeconds: 1
        periodSeconds: 3
  restartPolicy: Always
           

查看

创建pod
kubectl apply -f readinessprobepod.yml

检查pod状态，虽然pod状态显示running但是ready显示0/1，因为就绪检查未通过
kubectl get pods

查看pod详细信息，文件最后一行显示readiness probe failed。。。。
kubectl describe pod readinessprobe-pod

进入pod内部，因为是alpine系统，需要使用sh命令
kubectl exec -it readinessprobe-pod sh

进入容器内目录
cd /usr/share/nginx/html/

追加一个index1.html文件
echo "welcome lagou" >> index1.html

退出容器，再次查看pod状态，pod已经正常启动
exit
kubectl get pods
           

livenessProbe(存活检测)

案例一

livenessprobepod.yml

apiVersion: v1
kind: Pod
metadata:
  name: livenessprobe-test
  labels:
    app: livenessprobe-test
spec:
  containers:
    - name: livenessprobe-test
      image: busybox:1.32.0
      imagePullPolicy: IfNotPresent
      command: [ "/bin/sh","-c","touch /tmp/livenesspod ; sleep 30; rm -rf /tmp/livenesspod; sleep 3600"]
      livenessProbe:
        exec:
          command: ["test","-e","/tmp/livenesspod"]
        initialDelaySeconds: 1
        periodSeconds: 3
  restartPolicy: Always
           

执行

创建pod
kubectl apply -f livenessprobepod.yml

监控pod状态变化,容器正常启动
kubectl get pod -w

等待30秒后，发现pod的RESTARTS值从0变为1.说明pod已经重启一次
           

案例二

livenessprobenginxpod.yml

apiVersion: v1
kind: Pod
metadata:
name: livenessprobenginx-pod
labels:
 app: livenessprobenginx-pod
spec:
containers:
 - name: livenessprobenginx-pod
  image: nginx:1.17.10-alpine
  imagePullPolicy: IfNotPresent
  ports:
   - containerPort: 80
    name: nginxhttpget
  livenessProbe:
   httpGet:
    port: 80
    path: /index.html
   initialDelaySeconds: 1
   periodSeconds: 3
   timeoutSeconds: 10
restartPolicy: Always
           

创建pod
kubectl apply -f livenessprobenginxpod.yml

查看pod状态
kubectl get pod

查看容器IP，访问index.html页面。index.html页面可以正常访问。
kubectl get pod -o wide
curl 10.81.58.199

进入容器内部
kubectl exec -it livenessprobenginx-pod sh

删除index.html文件,退出容器
rm -rf //usr/share/nginx/html/index.html
exit

再次监控pod状态，等待一段时间后，发现pod的RESTARTS值从0变为1.说明pod已经重启一次。
kubectl get pod -w

进入容器删除文件一条命令执行rm -rf命令后退出容器。
kubectl exec -it livenessprobenginx-pod -- rm -rf
/usr/share/nginx/html/index.html

再次监控pod状态，等待一段时间后，发现pod的RESTARTS值从1变为2.说明pod已经重启一次。
kubectl get pod -w

因为liveness监控index.html页面已经被删除，所以pod需要重新启动，重启后又重新创建nginx
镜像。nginx镜像中默认有index.html页面。
           

案例三

livenessprobenginxpod2.yml

apiVersion: v1
kind: Pod
metadata:
name: livenessprobenginx-pod2
labels:
 app: livenessprobenginx-pod2
spec:
containers:
 - name: livenessprobenginx-pod2
  image: nginx:1.17.10-alpine
  imagePullPolicy: IfNotPresent
  livenessProbe:
   tcpSocket:
    #监测8080端口，如果8080端口没有反馈信息，重启pod
    port: 8080
   initialDelaySeconds: 10
   periodSeconds: 3
   timeoutSeconds: 5
restartPolicy: Always
           

创建pod
kubectl apply -f livenessprobenginxpod2.yml

查看pod状态
kubectl get pod -w

存活检测监听8080端口，8080端口没有反馈信息后重启pod，RESTARTS值从0变为1
           

每个人都有潜在的能量，只是很容易被习惯所掩盖，被时间所迷离，被惰性所消磨~