Pod的健康检查机制

原创

iginkgo18

修改于 2021-09-13 11:15:06

1.4K0

修改于 2021-09-13 11:15:06

1 探针简介

对线上业务来说，保证服务的正常稳定是重中之重，对故障服务的及时处理避免影响业务以及快速恢复一直是开发运维的难点。Kubernetes提供了健康检查服务，对于检测到故障服务会被及时自动下线，以及通过重启服务的方式使服务自动恢复。

2 使用Liveness及Readness探针

Liveness探针：主要用于判断Container是否处于运行状态，比如当服务crash或者死锁等情况发生时，kubelet会kill掉Container，然后根据其设置的restart policy进行相应操作（可能会在本机重新启动Container，或者因为设置Kubernetes QoS，本机没有资源情况下会被分发的其他机器上重新启动）

Readness探针：主要用于判断服务是否已经正常工作，如果服务没有加载完成或工作异常，服务所在的Pod的IP地址会从服务的Endpoints中被移除，也就是说，当服务没有ready时，会将其从服务的load balancer中移除，不会再接受或响应任何请求。

2.1 服务可用性和自动恢复

如果服务的健康检查（readiness）失败，故障的服务实例从service endpoint中下线，外部请求将不会再转发到该服务上，一定程度上保证正在提供的服务的正确性，如果服务自我恢复了（比如网络问题），会自动重新加入service endpoint对外提供服务。

另外，如果设置了Container（liveness）的探针，对故障服务的Container（liveness）的探针同样会失败，container会被kill掉，并根据原设置的container重启策略，系统倾向于在其原所在的机器上重启该container、或其他机器重新创建一个pod;

2.2 建议

1 . 对全部服务同时设置服务（readiness）和Container（liveness）的健康检查。

2 . 通过TCP对端口检查（TCPSocketAction），仅适用于端口已关闭或进程停止情况。因为即使服务异常，只要端口是打开状态，健康检查仍然是通过的。

3 . 基于第二点，一般建议用ExecAction自定义健康检查逻辑，或采用HTTP Get请求进行检（HTTPGetAction）

4 . 无论采用哪种类型的探针，一般建议设置检查服务（readiness）的时间短于检查Container（liveness）的时间，也可以将检查服务（readiness）的探针与Container（liveness）的探针设置为一致。目的是故障服务先下线，如果过一段时间还无法自动恢复，那么根据重启策略，重启该Container、或其他机器重新创建一个Pod恢复故障服务。

2.3 example liveness.yaml

容器会创建一个文件/tmp/healthy,30秒后删除；探针5秒会检查一次，检查方式为cat /tmp/healthy文件是否存在，检查到容易有问题，探测失败3次，则重建容器

[root@k8s-master-10 Liveness]# cat liveness.yaml 
apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec-changjian
spec:
  containers:
  - name: liveness
    image: busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5

3 存活探针

默认情况下：以镜像打包基于容器资源编排系统创建的pod对于用户和服务就相当于一个黑盒。想要探测容器中的用户部署的应用和服务是否正常，都被容器编排系统(k8s)所阻挡。正常情况下，任何一个为云原生开发的程序都会考虑到这个问题，为了监视容器中运行的“应用”正常各种指标应该向外输出，比如，健康状态，实现的方式，比如使用一个URL或者VirtualHost的单独容器对外输出健康状态指标。暴露给容器边界的外部。

Metrics:提供的指标数据，有业务级，系统级等 tracing: 分布式链路追踪可能会使用，可以认为埋点或者叫做探针探针就相当于一个接口，一个管道。后期直接使用即可，可以理解为URI或者端口探测 readiness: 就绪状态检测 liveness: 存活状态检测

Pod默认提供探针的接口: Liveness

下面非常重要:

判断一个pod中容器运行健康状态与否：有两种探针，而且周期性运行 liveness和 readiness；

liveness：如果容器没有正常运行，或者没有得到正确的值，kubelet会根据容器重启策略，重启或者杀死容器；

readiness: 判断容器内的应用程序从启动，到应用程序是否正常运行，能够提供用户正常访问和接受客户端请求，如果一个容器没有通过就绪检测，而容器可能会重启它，service会把对应的主机ip从后端移除，直到下次健康检测正常才把它加进来。

spec:
  containers:
  - name: …
    image: …
    livenessProbe:
      exec <Object>     # 命令式探针
      httpGet <Object>  # http GET类型的探针
      tcpSocket <Object>  # tcp Socket类型的探针
      initialDelaySeconds <integer>  # 发起初次探测请求的延后时长 建议设置长一点，有些服务启动很慢
      periodSeconds <integer>         # 请求周期
      timeoutSeconds <integer>        # 超时时长
      successThreshold <integer>     
      # 成功阈值 (表示探测n次成功，才表示容器是健康的，状态改变之后的确认次数)
      
      failureThreshold <integer>       # 失败阈值 状态改变之后，探测n此失败才确认失败

Pod默认提供的三种探针方式:

1 . LivenessProbe: 周期性探测, 检测未通过时，kubelet会根据restartPolicy的定义来决定是否会重启该容器；未定义时，Kubelet认为只容器未终止，即为健康;

以下是对存活探针方式的三种访问参数,ReadinessProbe访问方式一样:

命令查看readinessProbe有哪些参数

[root@k8s-master-10 Liveness]# kubectl explain pods.spec.containers.readinessProbe
KIND:     Pod
VERSION:  v1

RESOURCE: readinessProbe <Object>

DESCRIPTION:
     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

     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.

   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>
     How often (in seconds) to perform the probe. Default to 10 seconds. Minimum
     value is 1.

   successThreshold	<integer>
     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>
     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-lifecycle#container-probes

查看exec探测帮助:

[root@k8s-master-10 Liveness]# kubectl explain pods.spec.containers.readinessProbe.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.

查看http方式帮助:

[root@k8s-master-10 Liveness]# kubectl explain pods.spec.containers.readinessProbe.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>
     Host name to connect to, defaults to the pod IP. You probably want to set
     "Host" in httpHeaders instead.

   httpHeaders	<[]Object>
     Custom headers to set in the request. HTTP allows repeated headers.

   path	<string>
     Path to access on the HTTP server.

   port	<string> -required-
     Name or number of the port to access on the container. Number must be in
     the range 1 to 65535. Name must be an IANA_SVC_NAME.

   scheme	<string>
     Scheme to use for connecting to the host. Defaults to HTTP.

注意:

initialDelaySeconds 表示容器在启动之后，如果不设置时间，可能就是马上进行存活检测，因为此时有些大应用可能还没有启动，就检测失败了，检测失败之后又自动重启了，所以就处于重启的循环当中。所以此处应当设置一个延时等待时间。等容器中应用都启动好之后，再进行检测。

ReadinessProbe:

周期性探测,检测未通过时，与该Pod关联的Service,会将Pod从Service的后端可用端点列表中删除;直接再次就绪，重新添加回来。未定义时，只要容器未终止就是就绪;

StartProbe:

1.16版本之后支持，启动状态检测，检测容器刚刚启动是成功的，只有他通过之后，查看是否有LivenessProbe,然后生效LivenessProbe,一般用于大型服务启动时检测;

以上的三种探针都支持以下三种类似的检测方式:

下面三种检测方法:

1 . ExecAction: 直接执行命令，命令成功返回探测成功;制作容器时候预留一个探测接口ip/api;

2 . TCPSocketAaction: 端口能够正常打开，对于握手能够正常相应，发起三次握手。握手相应，表示成功;

3 . HTTPGetAction: 向指定的Path发起HTTP请求,2xx,3xx表示响应码成功;

3.1 基于存活探针使用命令测试

apiVersion: v1
kind: Pod
metadata:
  name: liveness-exec-demo
  namespace: default
spec:
  containers:
  - name: demo
    image: ikubernetes/demoapp:v1.0
    imagePullPolicy: IfNotPresent
    livenessProbe:
      exec:
        command: ['/bin/sh', '-c', '[ "$(curl -s 127.0.0.1/livez)" == "OK" ]']
      initialDelaySeconds: 5
      timeoutSeconds: 1
      periodSeconds: 5
 #执行上面的demo，判断执行的命令是否等于ok,如果等于ok，表示探测是成功的。
 
 kubectl apply -f .

提交post请求,容器会自动重启

[root@k8s-master1 ~]# curl  10.244.135.28/livez
OK[root@k8s-master1 ~] curl  -XPOST   -d "livez=Faile" 10.244.135.28/livez

3.3 使用tcp测试

example1

[root@k8s-master1 lianxi]# cat liveness-tcpsocket-demo.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: liveness-tcpsocket-demo
  namespace: default
spec:
  containers:
  - name: demo
    image: ikubernetes/demoapp:v1.0
    imagePullPolicy: IfNotPresent
    ports:
    - name: http
      containerPort: 80
    securityContext:
      capabilities:
        add:
        - NET_ADMIN   #方便后续添加iptables测试
    livenessProbe:
      tcpSocket:
        port: http
      periodSeconds: 5
      initialDelaySeconds: 5
      
[root@k8s-master-10 Liveness]# kubectl  exec  liveness-tcpsocket-demo -- iptables -A INPUT -p tcp --dport 80 -j REJECT

# 容器立马探测失败,5s之后就会重启
[root@k8s-master-10 ~]# kubectl get pods -w
NAME                      READY   STATUS    RESTARTS   AGE
liveness-tcpsocket-demo   1/1     Running   0          4h23m
liveness-tcpsocket-demo   1/1     Running   1          4h24m

example2

[root@k8s-master-10 Liveness]# cat nginx-tcp-liveness.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: nginx-tcp-liveness-probe
spec:
  containers:
  - name: nginx-tcp-liveness-probe
    image: nginx:latest
    ports:
    - name: http-80-port
      protocol: TCP
      containerPort: 80
    livenessProbe:
      tcpSocket:
        port: 80
      initialDelaySeconds: 3
      periodSeconds: 10
      timeoutSeconds: 3
      
[root@k8s-master-10 Liveness]# kubectl apply -f nginx-tcp-liveness.yaml
pod/nginx-tcp-liveness-probe created

[root@k8s-master-10 Liveness]# kubectl get pods  -o wide |grep nginx
nginx-tcp-liveness-probe   1/1     Running   0          2m5s   172.17.66.5   192.168.0.14   <none>           <none>

# 模拟故障,进入Pod安装htop
[root@k8s-master-10 Liveness]# kubectl exec -it nginx-tcp-liveness-probe bash
root@nginx-tcp-liveness-probe:/# apt-get update
root@nginx-tcp-liveness-probe:/# apt-get install htop
root@nginx-tcp-liveness-probe:/# htop

  CPU[||                           5.4%]   Tasks: 4, 0 thr; 1 running
  Mem[||||||||||||||         792M/5.61G]   Load average: 0.02 0.06 0.05 
  Swp[                            0K/0K]   Uptime: 2 days, 22:17:44

   PID USER      PRI  NI  VIRT   RES   SHR S CPU% MEM%   TIME+  Command               
     1 root       20   0 10652  3344  2532 S  0.0  0.1  0:00.00 nginx: master process 
    30 nginx      20   0 11056  1764   460 S  0.0  0.0  0:00.00 nginx: worker process
    31 root       20   0  3976  2072  1576 S  0.0  0.0  0:00.00 bash
   311 root       20   0  4780  1676  1240 R  0.0  0.0  0:00.00 htop
   
运行htop查看进程,容器进程通常为1;
root@nginx-tcp-liveness-probe:/# kill 1
root@nginx-tcp-liveness-probe:/# command terminated with exit code 137

[root@k8s-master-10 Liveness]# kubectl get pods -w |grep nginx
nginx-tcp-liveness-probe   1/1     Running   0          4m47s
nginx-tcp-liveness-probe   0/1     Completed   0          4m51s
nginx-tcp-liveness-probe   1/1     Running     1          5m7s


[root@k8s-master-10 Liveness]# kubectl describe pod nginx-tcp-liveness-probe  |tail
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type     Reason     Age                  From                   Message
  ----     ------     ----                 ----                   -------
  Normal   Scheduled  5m39s                default-scheduler      Successfully assigned default/nginx-tcp-liveness-probe to 192.168.0.14
  Normal   Pulling    48s (x2 over 5m39s)  kubelet, 192.168.0.14  Pulling image "nginx:latest"
  Warning  Unhealthy  48s                  kubelet, 192.168.0.14  Liveness probe failed: dial tcp 172.17.66.5:80: connect: connection refused
  Normal   Pulled     33s (x2 over 5m23s)  kubelet, 192.168.0.14  Successfully pulled image "nginx:latest"
  Normal   Created    33s (x2 over 5m23s)  kubelet, 192.168.0.14  Created container nginx-tcp-liveness-probe
  Normal   Started    33s (x2 over 5m23s)  kubelet, 192.168.0.14  Started container nginx-tcp-liveness-probe

3.4 通过http进行探测

只看响应码，如果是2xx,3xx表示正常，如果是4xx,5xx就是表示失败

[root@k8s-master1 lianxi]# cat liveness-httpget-demo.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: liveness-httpget-demo
  namespace: default
spec:
  containers:
  - name: demo
    image: ikubernetes/demoapp:v1.0
    imagePullPolicy: IfNotPresent
    livenessProbe:
      httpGet:
        path: '/livez'
        port: 80
        scheme: HTTP
      initialDelaySeconds: 5
      
[root@k8s-master-10 Liveness]# curl 172.17.66.2/livez
OK

4 就绪探针

就绪检查用于应用接入到service的场景，用于判断应用是否已经就绪完毕，即是否可以接受外部转发的流量，健康检查正常则将pod加入到service的endpoints中，健康检查异常则从service的endpoints中删除，避免影响业务的访问。

下面是容器启动之后通过15s之后进行就绪绪检测，在15s之前不会将访问容器的流量调度到后端的service ip，导致访问失败。通过检测之后才将service 添加到k8s后端的service ip中;

Example1

[root@k8s-master1 lianxi]# cat readiness-httpget-demo.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: readiness-httpget-demo
  namespace: default
spec:
  containers:
  - name: demo
    image: ikubernetes/demoapp:v1.0
    imagePullPolicy: IfNotPresent
    readinessProbe:
      httpGet:
        path: '/readyz'
        port: 80
        scheme: HTTP
      initialDelaySeconds: 15
      timeoutSeconds: 2
      periodSeconds: 5
      failureThreshold: 3
  restartPolicy: Always

Example2

创建一个Pod,使用httpGet的健康检查机制，定义readiness就绪检查探针检查路径/test.html

[root@k8s-master-10 Liveness]# cat httpget-liveness-readiness-probe.yaml
apiVersion: apps/v1
kind: Deployment 
metadata:
  name: nginx-tcp-liveness-probe
  labels: 
    app: nginx-server
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx-server
  template:
    metadata:
      labels:
        app: nginx-server
    spec:
      containers:
      - name: nginx-tcp-liveness-probe 
        image: nginx:latest
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
        
        livenessProbe:  #存活检查探针
          httpGet:
            port: 80
            path: /index.html
            scheme: HTTP
          initialDelaySeconds: 3  # 容器启动等待多少秒后存活和就绪探测器才会被初始化,默认0;
          periodSeconds: 10       # 执行探测的时间间隔,默认10，最小1
          successThreshold: 1     # 探测器失败后，被视为最小成功连续数,默认值为1,存活和启动探测这个值必须是1;
          timeoutSeconds: 3       # 探测超时等待多少秒,默认1;
          failureThreshold: 3 # 探测失败,k8s的重试次数，存活探测情况下的放弃意味着重启容器, 就绪探测情况>下放弃Pod会被打上未就绪标签,默认3;
          
        readinessProbe:  #就绪检查探针
          httpGet:
            port: 80
            path: /test.html
            scheme: HTTP
          initialDelaySeconds: 3
          periodSeconds: 10
          timeoutSeconds: 3
          
[root@k8s-master-10 Liveness]# cat nginx-service.yaml 
apiVersion: v1
kind: Service
metadata:
  labels:
    app: nginx
  name: nginx-service
spec:
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx-server
  type: ClusterIP
  
  
# 我们可以看到就绪探针检测不通过
[root@k8s-master-10 Liveness]# kubectl describe pod nginx-tcp-liveness-probe-57bb9c7668-qcssq |tail
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type     Reason     Age                From                   Message
  ----     ------     ----               ----                   -------
  Normal   Scheduled  101s               default-scheduler      Successfully assigned default/nginx-tcp-liveness-probe-57bb9c7668-qcssq to 192.168.0.14
  Normal   Pulled     101s               kubelet, 192.168.0.14  Container image "nginx:latest" already present on machine
  Normal   Created    101s               kubelet, 192.168.0.14  Created container nginx-tcp-liveness-probe
  Normal   Started    101s               kubelet, 192.168.0.14  Started container nginx-tcp-liveness-probe
  Warning  Unhealthy  6s (x10 over 96s)  kubelet, 192.168.0.14  Readiness probe failed: HTTP probe failed with statuscode: 404
  
  
# 查看service的endpoints，发现此时endpoints为空, 因为readiness就绪检测异常,kubelet认为此时pod并未就绪,因此并未将其加入到endpoints中
[root@k8s-master-10 Liveness]# kubectl get svc
NAME            TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes      ClusterIP   10.0.0.1     <none>        443/TCP   28d
nginx-service   ClusterIP   10.0.0.69    <none>        80/TCP    4m32s
[root@k8s-master-10 Liveness]# kubectl describe svc nginx-service
Name:              nginx-service
Namespace:         default
Labels:            app=nginx
Annotations:       kubectl.kubernetes.io/last-applied-configuration:
                     {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"labels":{"app":"nginx"},"name":"nginx-service","namespace":"default"},"s...
Selector:          app=nginx-server
Type:              ClusterIP
IP:                10.0.0.69
Port:              http  80/TCP
TargetPort:        80/TCP
Endpoints:         
Session Affinity:  None
Events:            <none>

# 进入到pod中手动创建网站文件，使readiness健康检查正常
[root@k8s-master-10 ~]# kubectl exec -it nginx-tcp-liveness-probe-57bb9c7668-qcssq bash
root@nginx-tcp-liveness-probe-57bb9c7668-qcssq:/# echo "readiness probe demo" > /usr/share/nginx/html/test.html

[root@k8s-master-10 Liveness]# kubectl describe svc nginx-service
Name:              nginx-service
Namespace:         default
Labels:            app=nginx
Annotations:       kubectl.kubernetes.io/last-applied-configuration:
                     {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"labels":{"app":"nginx"},"name":"nginx-service","namespace":"default"},"s...
Selector:          app=nginx-server
Type:              ClusterIP
IP:                10.0.0.69
Port:              http  80/TCP
TargetPort:        80/TCP
Endpoints:         172.17.66.2:80
Session Affinity:  None
Events:            <none>
[root@k8s-master-10 Liveness]# kubectl describe endpoints nginx-service
Name:         nginx-service
Namespace:    default
Labels:       app=nginx
Annotations:  endpoints.kubernetes.io/last-change-trigger-time: 2021-09-11T22:25:15+08:00
Subsets:
  Addresses:          172.17.66.2
  NotReadyAddresses:  <none>
  Ports:
    Name  Port  Protocol
    ----  ----  --------
    http  80    TCP

Events:  <none>

5 Pod中容器使用的两种钩子介绍

对容器主要做一些初始化的操作

post start hook: 容器启动初始化启动后的钩子 pre stop hook: 容器结束之前执行的操作

[root@k8s-master1 lianxi]# cat lifecycle-demo.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo
  namespace: default
spec:
  containers:
  - name: demo
    image: ikubernetes/demoapp:v1.0
    imagePullPolicy: IfNotPresent
    securityContext:
      capabilities:
        add:
        - NET_ADMIN
    livenessProbe:
      httpGet:
        path: '/livez'
        port: 80
        scheme: HTTP
      initialDelaySeconds: 5
    lifecycle:
      postStart:   #启动前执行的钩子
        exec:
          command: ['/bin/sh','-c','iptables -t nat -A PREROUTING -p tcp --dport 8080 -j REDIRECT --to-ports 80']
      preStop:     #容器结束前执行的钩子
        exec:
          command: ['/bin/sh','-c','while killall python3; do sleep 1; done']
  restartPolicy: Always

在容器启动的时候自动执行添加规则，容器结束的执行会执行上面的杀死python命令

[root@k8s-master-10 Liveness]# kubectl exec lifecycle-demo -- iptables -vnL -t nat
Chain PREROUTING (policy ACCEPT 6 packets, 360 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 REDIRECT   tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:8080 redir ports 80

Chain INPUT (policy ACCEPT 6 packets, 360 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

5.1 钩子三种实行方法

钩子也是支持三种实行的方法：对于postStart和preStart 都是一样的

[root@k8s-master-10 Liveness]# kubectl explain pods.spec.containers.lifecycle.postStart
KIND:     Pod
VERSION:  v1

RESOURCE: postStart <Object>

DESCRIPTION:
     PostStart is called immediately after a container is created. If the
     handler fails, the container is terminated and restarted according to its
     restart policy. Other management of the container blocks until the hook
     completes. More info:
     https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks

     Handler defines a specific action that should be taken

FIELDS:
   exec	<Object>
     One and only one of the following should be specified. Exec specifies the
     action to take.

   httpGet	<Object>
     HTTPGet specifies the http request to perform.

   tcpSocket	<Object>
     TCPSocket specifies an action involving a TCP port. TCP hooks not yet
     supported

6 Pod中多容器模式运行

Sidecar: 为了让外部的请求更好的接入Pod中容器而设计的(主要是代理);

Adapater: 主要是让容器请求更好的适配外部的请求而设计;

Ambassador: 主要为了让Pod中容器请求更好接入外部的环境设计;

(访问数据库，容器把数据给base容器，由base容器访问数据库)

加入定义两个初始化容器: Pod生命周期

容器初始化1 ---> 成功完成 ----> 第二个初始化容器2 ---> 成功完成 ---> 主容器(如果定义了sidecar可能和主容器一起启动)

说明:

一般在容器中使用初始化容器做特权操作，而不是直接定义特权字段，初始化容器执行完之后就会终止了, 比如添加iptables规则, 可以通过初始化容器来实现, 添加完iptables之后自动终止,然后运行主容器，而主容器没有net-admin权限;

Example

[root@k8s-master-10 Liveness]# cat sidecar-container-demo.yaml
apiVersion: v1
kind: Pod
metadata:
  name: sidecar-container-demo
  namespace: default
spec:
  containers:
  - name: proxy
    image: envoyproxy/envoy-alpine:v1.14.1
    command: ['/bin/sh','-c']
    args: ['sleep 5 && envoy -c /etc/envoy/envoy.yaml']
    lifecycle:
      postStart:
        exec:
          command: ['/bin/sh','-c','wget -O /etc/envoy/envoy.yaml http://ilinux.io/envoy.yaml']
  - name: demo
    image: ikubernetes/demoapp:v1.0
    imagePullPolicy: IfNotPresent
    env:
    - name: HOST
      value: "127.0.0.1"
    - name: PORT
      value: "8080"

通过envoys代理访问内部demo,demo只是监听在127.0.0.1的8080端口

[root@k8s-master-10 Liveness]# kubectl get pods -o wide
NAME                     READY   STATUS    RESTARTS   AGE    IP            NODE           NOMINATED NODE   READINESS GATES
lifecycle-demo           1/1     Running   0          21m    172.17.66.3   192.168.0.14   <none>           <none>
liveness-httpget-demo    1/1     Running   0          48m    172.17.66.2   192.168.0.14   <none>           <none>
sidecar-container-demo   2/2     Running   0          2m1s   172.17.66.4   192.168.0.14   <none>           <none>
[root@k8s-master-10 Liveness]# curl 172.17.66.4
iKubernetes demoapp v1.0 !! ClientIP: 127.0.0.1, ServerName: sidecar-container-demo, ServerIP: 172.17.66.4!

我们看看具体envoy的定义

[root@k8s-master-10 Liveness]# cat /etc/envoy/envoy.yaml 
admin:
  access_log_path: /tmp/admin_access.log
  address:
    socket_address: { address: 0.0.0.0, port_value: 9901 }

static_resources:
  listeners:
  - name: listener_0
    address:
      socket_address: { address: 0.0.0.0, port_value: 80 }
    filter_chains:
    - filters:
      - name: envoy.http_connection_manager
        config:
          stat_prefix: ingress_http
          codec_type: AUTO
          route_config:
            name: local_route
            virtual_hosts:
            - name: local_service
              domains: ["*"]
              routes:
              - match: { prefix: "/" }
                route: { cluster: local_service }
          http_filters:
          - name: envoy.router

  clusters:
  - name: local_service
    connect_timeout: 0.25s
    type: STATIC
    lb_policy: ROUND_ROBIN
    load_assignment:
      cluster_name: local_service
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: 127.0.0.1
                port_value: 8080

上面这张图也是服务网格的一种思想，将限流，容错，降级, 监控等调用sdk的服务放在一个应用中实现，把核心业务放在另一个应用程序中;

原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。

如有侵权，请联系 cloudcommunity@tencent.com 删除。

kubernetes

原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。

如有侵权，请联系 cloudcommunity@tencent.com 删除。

kubernetes

登录后参与评论

0 条评论

热度