kubernetes Pod高级用法-探针

POD-2高级用法

容器探测详解
所谓容器探测就是我们在里面设置了一些探针，或者传感器来获取相应的数据用来判断容器存活与否或者就绪与否的标准；

目前k8s支持的存活性探测方式和就绪性探测方式都是一样的，探针类型有三种：
ExecAction：
TCPSocketAction：
HTTPGetAction：
如果探针是针对容器存活性检测的，就是容器存活性探针
如果探针是针对容器就绪状态检测的，就是融容器就绪性探针
kubectl explain pods.spec.containers
可以看到如下：
livenessProbe（容器存活性探针）：
readinessProbe （容器就绪性探针）
lifecycle（容器生命周期探针）：主要是用来定义容器启动后和结束前的钩子的

#查看livenessprobe和readinessprobe用法：
kubectl explain pods.spec.containers.livenessProbe
kubectl explain pods.spec.containers.readinessProbe
livenessProbe <Object>
     Periodic probe of container liveness. Container will be restarted if the
     probe fails. Cannot be updated. More info:
     https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes
readinessProbe     <Object>
     Periodic probe of container service readiness. Container will be removed
     from service endpoints if the probe fails. Cannot be updated. More info:
     https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes
lifecycle <Object>
Actions that the management system should take in response to container lifecycle events. Cannot be updated.

（1）livenessProbe定义详解：
#livenessProbe是一个对象，内部的对象形式有三种，及探针类型有三个，exec，httpGet，tcpSock，我们平时定义的时候只需要定义三种探针中的任意一个即可
kubectl explain pods.spec.containers.livenessProbe
KIND:     Pod
VERSION:  v1
RESOURCE: livenessProbe <Object>
DESCRIPTION:
     Periodic probe of container liveness. Container will be restarted if the
     probe fails. Cannot be updated. More info:
     https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes
     Probe describes a health check to be performed against a container to
     determine whether it is alive or ready to receive traffic.
FIELDS:
   exec  <Object>
     One and only one of the following should be specified. Exec specifies the
     action to take.
   failureThreshold     <integer>
     Minimum consecutive failures for the probe to be considered failed after
     having succeeded. Defaults to 3. Minimum value is 1.
#我们探测几次都失败了，才认为是失败的，我们不能够一锤定音，这样会导致误伤的，因此需要探测多次，默认是3次都探测失败，才认为是失败的
   httpGet    <Object>
     HTTPGet specifies the http request to perform.
   initialDelaySeconds <integer> 
#我们在容器启动的时候不能立即做探测，因为容器里的应用可能还没启动，我们需要在等一会在做探测，为的是容器里的应用可以起来，所以叫做初始化时的延迟等待时间，
     Number of seconds after the container has started before liveness probes
     are initiated. More info:
     https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes
periodSeconds <integer>#探测周期#周期间隔时长，默认是10s中探测一次
     How often (in seconds) to perform the probe. Default to 10 seconds. Minimum
     value is 1.
successThreshold    <integer>
认为探测成功的最小连续成功次数
失败之后。默认值为1。必须为1才能保持活力。最小值
为1。
     Minimum consecutive successes for the probe to be considered successful
     after having failed. Defaults to 1. Must be 1 for liveness. Minimum value
     is 1.
 tcpSocket <Object>
     TCPSocket specifies an action involving a TCP port. TCP hooks not yet
     supported
timeoutSeconds     <integer> #超时检测时长#每一次探测超时时间多长，探测请求之后始终没有响应，那么我们能等待的时间是多少，默认是1s
     Number of seconds after which the probe times out. Defaults to 1 second.
     Minimum value is 1. More info:
     https://kubernetes.io/docs/concepts/workloads/pods/pod-


（2）readnessProbe定义详解：
kubectl explain pods.spec.containers.readinessProbe
KIND: Pod
VERSION: v1
RESOURCE: readinessProbe <Object>
DESCRIPTION:
FIELDS:
exec <Object>

failureThreshold <integer>
我们探测几次都失败了，才认为是失败的，我们不能够一锤定音，这样会导致误伤的，因此需要探测多次，默认是3次都探测失败，才认为是失败的
httpGet <Object>

initialDelaySeconds <integer>
初始化时的延迟等待时间，
periodSeconds <integer>
探测周期#周期间隔时长，默认是10s中探测一次
successThreshold <integer>
认为探测成功的最小连续成功次数
失败之后。默认值为1。必须为1才能保持活力。最小值
为1。
tcpSocket <Object>

timeoutSeconds <integer>
每一次探测超时时间多长，
（3）查看livenessProbe下的exec用法
kubectl explain pods.spec.containers.livenessProbe.exec
KIND:     Pod
VERSION:  v1
RESOURCE: exec <Object>
DESCRIPTION:
     One and only one of the following should be specified. Exec specifies the
     action to take.
     ExecAction describes a "run in container" action.
FIELDS:
   command <[]string>
     Command is the command line to execute inside the container, the working
     directory for the command is root ('/') in the container's filesystem. The
     command is simply exec'd, it is not run inside a shell, so traditional
     shell instructions ('|', etc) won't work. To use a shell, you need to
     explicitly call out to that shell. Exit status of 0 is treated as
     live/healthy and non-zero is unhealthy.

例一：写一个简单的pod实例
健康探测使用的探针是exec
[root@master k8s-pod]# cat pod-liveness-exec.yaml

apiVersion: v1
kind: Pod
metadata:
  name: liveness-exec-pod
  namespace: default
  labels:
    test: liveness-exec-pod-busybox
spec:
  containers:
  - name: liveness-exec-containers
    image: docker.io/library/busybox:latest
    imagePullPolicy: IfNotPresent
    command: ["/bin/sh","-c","touch /tmp/test;sleep 30;rm -rf /tmp/test;sleep 3600"]
    livenessProbe:
      exec:
        command: ["test","-e","/tmp/test"] #test命令-e 该“文件名”是否存在
      initialDelaySeconds: 5 #延迟5秒开始探针/初始化容器
      periodSeconds: 10 #探测周期10秒一次

[root@master k8s-pod]# kubectl describe pod liveness-exec-pod
探测失败会重启

##Warning  Unhealthy  53s (x3 over 73s)   kubelet            Liveness probe failed:

apiVersion: v1
kind: Pod
metadata:
name: liveness-exec-pod #pod的名字
namespace: default #liveness-exec-pod这个pod的命名空间
spec:
containers:
- name: liveness-exec-container #容器的名字
image: busybox:latest #启动容器时使用的镜像
imagePullPolicy: IfNotPresent #镜像拉取策略
command: ["/bin/sh","-c","touch /tmp/healthy;sleep 30;rm -rf /tmp/healthy;sleep 3600"]
#启动容器时在容器内使用的命令，创建一个文件，sleep 30s,然后删除，在sleep 3600s，那么也就是这个文件存在的时间是30s，超过30s健康检测显示就是失败状态
livenessProbe: #探测容器的存活性
exec:
command: ["test","-e","/tmp/healthy"]
#检测文件是否存在，如果存在返回成功，不存在返回失败，我们可以定义容器重启策略，如果失败就重启，或者从不重启，这里不定义，默认失败就重启
initialDelaySeconds: 1 #启动容器之后1s开始探测
periodSeconds: 3 #探测的时间间隔是3s
kubectl apply -f liveness-exec.yaml
kubectl get pods 可以看到liveness-exec-pod出入running状态了

例二：写一个简单的pod实例
健康探测使用的探针是httpGet
#查看httpGet这个探针的用法

kubectl explain pods.spec.containers.livenessProbe.httpGet
KIND:     Pod
VERSION:  v1
RESOURCE: httpGet <Object>
DESCRIPTION:
     HTTPGet specifies the http request to perform.
     HTTPGetAction describes an action based on HTTP Get requests.
FIELDS:
   host  <string>
#连接到哪个主机
   httpHeaders    <[]Object>
#发送给什么样的请求头部
   path  <string>
#向哪个url发送请求
   port  <string> -required-
#请求的端口
   scheme    <string>

[root@master k8s-pod]# cat pod-liveness-httpGet.yaml

apiVersion: v1
kind: Pod
metadata:
  name: liveness-httpget-pod
  namespace: default
  labels:
    test: liveness-httpget-pod
spec:
  containers:
  - name: liveness-httpget-container
    image: docker.io/library/nginx:latest
    imagePullPolicy: IfNotPresent
    ports:
    - name: http
      containerPort: 80
    livenessProbe:
      httpGet:
        port: http #检测的端口，这个用上面的定义的port名字http
        path: /index.html #检测的url，默认是index.html
      initialDelaySeconds: 1 #容器启动之后1s开始探测
      periodSeconds: 3 #探测的时间间隔是3s

[root@master k8s-pod]# kubectl describe pod liveness-httpget-pod
上面可以看到容器运行正常
连入到容器内部
kubectl exec -it liveness-httpget-pod – /bin/sh
手动删除这个容器里的index.html文件
rm -rf /usr/share/nginx/html/index.html
然后再次查看容器的详细信息

目前是检测到了异常
过30s，再查看容器信息
kubectl describe pods liveness-httpget-pod 发现正常了，因为容器探测的时间间隔是30s，过了30s探测失败，那么就会重启，重启之后配置文件重新加载，那么容器重新恢复正常

重新连接可以进入到容器了
kubectl exec -it liveness-httpget-pod – /bin/sh
kubectl get pods 显示如下：
ready下面对应值通过/连接，/右面表示pod内部有几个容器，/左侧表示有几个容器就绪了，这里的就绪表示容器一启动就是就绪的，但是实际容器启动的时候里面的程序不一定起来，比方说里面运行tomcat，tomcat启动可能需要一定时间。

2.readnessProbe（容器就绪性探测）
service给pod提供一个入口地址，service和pod关联是通过标签选择器，我们后端只要创建一个pod，那么就会根据标签选择器被service关联到，但是新创建的pod里面的应用程序可能没有启动，我们在通过service访问的时候，可能会访问到刚创建的pod，但是访问时失败的，这个在生产环境是不被允许的，所以需要做容器做就绪性探测（readlinessProbe）和容器存活性探测（livenessProbe），尤其是readnessProbe
[root@master k8s-pod]# cat pod-readinessProbe-httpGet.yaml

apiVersion: v1
kind: Pod
metadata:
  name: rediness-httpdget-pod
  namespace: default
spec:
  containers:
  - name: rediness-httpget-container
    image: docker.io/library/nginx:latest
    imagePullPolicy: IfNotPresent
    ports:
    - name: http
      containerPort: 80
    readinessProbe:
      httpGet:
        port: http
        path: /index.html
      initialDelaySeconds: 1
      periodSeconds: 3

删除index文件能进但是没有READY
kubectl describe pod rediness-httpdget-pod
Readiness probe failed: HTTP probe failed with statuscode: 404
kubectl exec -it rediness-httpdget-pod – /bin/bash
/usr/share/nginx/html# echo hello >> index.html
即可恢复
容器不会终止，显示会显示没有READY

3.lifecycle讲解
启动后的钩子和终止前的钩子，叫做lifecycle
创建资源对象时，可以使用lifecycle来管理容器在运行前和关闭前的一些动作。lifecycle有两种回调函数：
PostStart：容器创建成功后，运行前的任务，用于资源部署、环境准备等。PreStop：在容器被终止前的任务，用于优雅关闭应用程序、通知其他系统等等。

查看lifecycle用法
kubectl explain pods.spec.containers.lifecycle
container
FIELDS:
   postStart  <Object>
   preStop    <Object>

查看lifecycle的postStart用法
kubectl explain pods.spec.containers.lifecycle.postStart
#poststart是在容器启动之后被立即执行的钩子，如果操作失败，容器根据重启策略决定是否重启，
FIELDS:
   exec  <Object>
   httpGet    <Object>
   tcpSocket <Object>
上面可以看到容器启动后钩子，也是有三种探针，exec，httpGet，tcpSocket
kubectl explain pods.spec.containers.lifecycle.preStop 查看lifecycle的preStop用法
#prestop是容器终止前被立即执行的钩子
FIELDS:
   exec  <Object>
   httpGet    <Object>
   tcpSocket <Object>
上面可以看到容器终止前钩子，也是有三种探针，exec，httpGet，tcpSocket

[root@master k8s-pod]# cat pod-lifecycle-poststart.yaml

apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-poststart-nginx
  namespace: default
  labels:
    test: lifecycle
spec:
  containers:
  - name: poststart-nginx-container
    image: docker.io/library/nginx:latest
    imagePullPolicy: IfNotPresent
    ports:
    - name: http
      containerPort: 80
    lifecycle:
      postStart:
        exec:
          command: ["/bin/bash","-c","echo this is postStart-nginx > /usr/share/nginx/html/index.html"]

[root@master k8s-pod]# kubectl exec -it lifecycle-poststart-nginx – curl localhost
this is postStart-nginx

*prestop例子：
PreStop在整个生命周期中比较有用，实用场景也比较多。 比如：
1.关闭前等待某一个状态完成；
2.关闭前同步一些状态（数据）到其他的地方；
3.关闭前通知某一个系统或者更新一个状态；

cat preStop-nginx.yaml

apiVersion: v1
kind: Pod
metadata:
  name: prestop-nginx
  namespace: default
spec:
  containers:
  - name: prestop-nginx
    image: nginx
    imagePullPolicy: IfNotPresent
    lifecycle:
       preStop:
         exec:
           command: ["/usr/local/nginx/sbin/nginx","-s","quit"]
    ports:
    - name: http
      containerPort: 80

通过kubectl apply更新yaml
kubectl apply -f poststart-nginx.yaml
停掉pod的时候，会先把pod里的nginx先停掉
#通过pod部署应用的时候，访问应用时需要经过的数据走向
pod ip:port–>container ip:port–>container容器里具体的服务(服务暴漏的端口跟我们请求pod ip:port保持一致)