kubernetes(四)---pod的生命周期&探针

kubernetes(四)—pod的生命周期&探针

1.pod的生命周期

Pod 是 kubernetes 系统的基础单元，是由用户创建或部署的最小组件，也是 kubernetes 系统上运行容器化应用的资源对象

pod可以包含多个容器，应用运行在这些容器里面，同时pod也可以有一个或多个先于应用容器启动的init容器。

2.init容器实验

我们先写一个简单的资源清单，不定义init容器：

vim pod.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: myapp
spec:
  containers: 
    - name: myapp
      image: myapp:v1
      imagePullPolicy: IfNotPresent
      ports:
        - containerPort: 80
          hostPort: 80
      resources:
        limits:
          memory: 100M
        requests:
          memory: 50M
  nodeSelector:
    kubernetes.io/hostname: server3
  hostNetwork: true

运行，查看到这个资源清单里只运行了一个容器
把pod信息的输出转化为一个yaml文件：

kubectl get pod -o yaml

当我们创建测试pod的资源清单时发现格式混乱，是因为里面含有缩进

所以我们使用纯vi不缩进的形式来编写：

\vi init.yaml
apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: myapp-container
    image: busybox:1.28
    command: ['sh', '-c', 'echo The app is running! && sleep 3600']
  initContainers:
  - name: init-myservice
    image: busybox:1.28
command: ['sh', '-c', "until nslookup myservice.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for myservice; sleep 2; done"]

创建pod并查看状态：

kubectl create -f init.yaml 
kubectl get pod

我们可以看到它处于init容器初始化状态

创建service：
为了暴露pod，让集群外部节点可以访问

\vi service.yaml 
kind: Service
apiVersion: v1
metadata:
  name: myservice
spec:
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

kubectl create -f service.yaml	#服务创建完毕，此时解析可通过

init容器初始化成功：

kubectl get pod

可以看到init初始化成功，退出；myapp-pod正常运行

访问myapp-pod容器：

get pod -o wide
curl 10.244.2.18

进入容器查看dns解析：

kubectl run test -it --image=busyboxplus
nslookup myservice.default.svc.cluster.local

可以看到myservice的ip被解析出来了

3.探针

什么是探针？

探针是由 kubelet 对容器执行的定期诊断。要执行诊断，kubelet 调用由容器实现的 Handler。

有三种类型的处理程序：

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

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

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

Kubelet 可以选择是否执行在容器上运行的三种探针执行和做出反应：

• livenessProbe：指示容器是否正在运行。如果存活探测失败，则 kubelet 会杀死容器，并且容器将受到其 重启策略 的影响。如果容器不提供存活探针，则默认状态为 Success。
• readinessProbe：指示容器是否准备好服务请求。如果就绪探测失败，端点控制器将从与 Pod 匹配的所有 Service 的端点中删除该 Pod 的 IP 地址。初始延迟之前的就绪状态默认为 Failure。如果容器不提供就绪探针，则默认状态为 Success。
• startupProbe: 指示容器中的应用是否已经启动。如果提供了启动探测(startup probe)，则禁用所有其他探测，直到它成功为止。如果启动探测失败，kubelet 将杀死容器，容器服从其重启策略进行重启。如果容器没有提供启动探测，则默认状态为成功Success

存活检测-liveness

首先删除之前实验时创建的myservice服务：

kubectl get all
kubectl delete -f init.yaml 
kubectl delete pod test
kubectl delete service myservice 

cat pod.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: myapp
spec:
  containers: 
    - name: myapp
      image: myapp:v1
      imagePullPolicy: IfNotPresent
      livenessProbe:
        tcpSocket:
          port: 80
        initialDelaySeconds: 1 
        periodSeconds: 2 
        timeoutSeconds: 2 

kubectl create -f pod.yaml 

说明：
initialDelaySeconds: 1 - - -pod起动后1秒开始检测
periodSeconds: 2 - - -每隔两秒检测
timeoutSeconds: 2 - - -监测的超时时间（如果超过这个时长，则认为监测失败）

kubectl get pod
kubectl get pod -o wide

这里我们看到它一直在restart，这是因为它默认开启的是80端口，但文件中指定访问的端口是8080，它会一直检测
解决：我们只需要将端口改为80即可

检测就绪-readiness

就绪探针用法被检测容器是否能真正被访问

vim pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: myapp
spec:
containers:
- name: myapp
image: nginx
imagePullPolicy: IfNotPresent
      readinessProbe:
        httpGet:
          path: /test.html
          port: 80
        initialDelaySeconds: 1
        periodSeconds: 3
        timeoutSeconds: 1

kubectl create -f pod.yaml 
kubectl get pod

我们可以看到此时服务状态是running，但它并没有就绪，检测未通过

查看日志：

kubuctl logs myapp

可以看到原因是：在nginx的默认发布目录里找不到test.html文件

查看pod的详细信息，发现404报错：

describe pod myapp

此时我们创建test.html

kubectl exec -it myapp -- sh
cd /uar/share/nginx/html
echo hello nigar > test.html

再次检测：

kubectl get pod

满足就绪条件，pod处于ready状态
如果此时我们删除test.html，就又会检测到没有就绪。这就说明就绪探针会在进程运行过程中一直做检测