K8S容器编排最佳实践

K8S容器编排之POD健康检测(2)

2019-01-09  本文已影响8645人  云爬虫技术研究笔记

ReadinessProbe探针配置:

ReadinessProbe探针的使用场景livenessProbe稍有不同,有的时候应用程序可能暂时无法接受请求,比如Pod已经Running了,但是容器内应用程序尚未启动成功,在这种情况下,如果没有ReadinessProbe,则Kubernetes认为它可以处理请求了,然而此时,我们知道程序还没启动成功是不能接收用户请求的,所以不希望kubernetes把请求调度给它,则使用ReadinessProbe探针。
ReadinessProbelivenessProbe可以使用相同探测方式,只是对Pod的处置方式不同,ReadinessProbe是将Pod IP:Port从对应的EndPoint列表中删除,而livenessProbeKill容器并根据Pod重启策略来决定作出对应的措施。
ReadinessProbe探针探测容器是否已准备就绪,如果未准备就绪则kubernetes不会将流量转发给此Pod

ReadinessProbe探针与livenessProbe一样也支持exec、httpGet、TCP的探测方式,配置方式相同,只不过是将livenessProbe字段修改为ReadinessProbe

readinessProbe:
  exec:
    command:
    - cat
    - /tmp/healthy
  initialDelaySeconds: 5
  periodSeconds: 5

ReadinessProbe探针的HTTPTCP的探测方式也与livenessProbe的基本一致。

示例四: ReadinessProbe示例

现在来看一个加入ReadinessProbe探针和一个没有ReadinessProbe探针的示例:
该示例中,创建了一个deploy,名为JavaApp,启动的容器运行一个java应用程序,程序监听端口为8080

# 没有加入ReadinessProbe
cat JavaApp.yaml
---
kind: Deployment
apiVersion: apps/v1
metadata:
  name: JavaApp
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      test: JavaApp
  template: 
    metadata:
      labels:
         test: JavaApp
    spec:
      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 1
            preference:
              matchExpressions:
              - key: env
                operator: In
                values:
                - testing
      containers:
      - image: 192.168.1.183:8081/jar/JavaApp:29
        name: JavaApp
        ports:  
        - containerPort: 8080
      imagePullSecrets:
      - name: myregistrykey
---       
kind: Service
apiVersion: v1
metadata:
  name: JavaApp
  namespace: default
spec:
  selector:
      test: JavaApp
  ports:
    - protocol: TCP
      port: 8080# 没有加入ReadinessProbe
cat JavaApp.yaml
---
kind: Deployment
apiVersion: apps/v1
metadata:
  name: JavaApp
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      test: JavaApp
  template: 
    metadata:
      labels:
         test: JavaApp
    spec:
      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 1
            preference:
              matchExpressions:
              - key: env
                operator: In
                values:
                - testing
      containers:
      - image: 192.168.1.183:8081/jar/JavaApp:29
        name: JavaApp
        ports:  
        - containerPort: 8080
      imagePullSecrets:
      - name: myregistrykey
---       
kind: Service
apiVersion: v1
metadata:
  name: JavaApp
  namespace: default
spec:
  selector:
      test: JavaApp
  ports:
    - protocol: TCP
      port: 8080

创建:

kubectl create -f JavaApp.yaml

刚创建后,等几秒钟后,查看Pod状态

$  kubectl get pod
NAME                     READY     STATUS    RESTARTS   AGE
JavaApp-579b45567c-tdsrk    1/1      Running        0            6s

从上面可以看到,Pod刚启动6s,自身状态已Running,其READ字段,1/1表示1个容器状态已准备就绪了,此时,对于kubernetes而言,它已经可以接收请求了,而实际上服务还无法访问,因为JAVA程序还尚启动起来,本人实验中的JAVA程序启动时间大概需要50s,50s后方可正常访问,所以针对此类程序,必须配置ReadinessProbe

#加入readinessProbe
kind: Deployment
apiVersion: apps/v1
metadata:
  name: JavaApp
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      test: JavaApp
  template: 
    metadata:
      labels:
        test: JavaApp
    spec:
      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 1
            preference:
              matchExpressions:
              - key: env
                operator: In
                values:
                - testing
      containers:
      - image: 192.168.1.183:8081/jar/JavaApp:29
        name: JavaApp
        ports:  
        - containerPort: 8080
        readinessProbe:
          tcpSocket:
            port: 8080
          initialDelaySeconds: 60
          periodSeconds: 10
      imagePullSecrets:
      - name: myregistrykey
---
kind: Service
apiVersion: v1
metadata:
  name: JavaApp
  namespace: default
spec:
  selector:
    test: JavaApp
  ports:
    - protocol: TCP
      port: 8080

在该配置文件中,ReadinessProbe探针的探测方式为tcpSocket,因为程序监听在8080端口,所以这里探测为对8080建立连接。程序启动时间大概50多秒,所以这里第一次探测时间是在Pod Runing60秒后,间隔10秒后执行第二次探测
创建Pod:

kubectl create -f JavaApp.yaml

创建后等50秒查看状态:

$ kubectl get pod -o wide
NAME                         READY     STATUS    RESTARTS   AGE          IP             NODE
JavaApp-64b58cfd5c-kpc4s    0/1       Running   0           55s     172.26.91.109   192.168.1.180

Pod虽然已处于Runnig状态,但是由于第一次探测时间未到,所以READY字段为0/1,即容器的状态为未准备就绪,在未准备就绪的情况下,其Pod对应的Service下的Endpoint也为空,所以才不会有任何请求被调度进来。

$ kubectl get endpoints
   NAME           ENDPOINTS   
  JavaApp

当通过第一次探测的检查通过后,容器的状态自然会转为READ状态。

$ kubectl get pod
NAME                      READY     STATUS    RESTARTS   AGE
JavaApp-64b58cfd5c-qj886   1/     Running       0          1m

$ kubectl get endpoints 
NAME                ENDPOINTS                          AGE
JavaApp            172.26.91.113:8080                 1m

此后根据指定的间隔时间10s后再次探测,如果不通过,则kubernetes就会将Pod IPEndPoint列表中移除。

配置探针(Probe)相关属性

探针(Probe)有许多可选字段,可以用来更加精确的控制Liveness和Readiness两种探针的行为(Probe):

上一篇下一篇

猜你喜欢

热点阅读