目录

K8s 里多容器 Pod 的健康检查探针工作机制分析

1. 开篇

米娜桑,宝子们,ladies and 砖头们…… 总之,我回来了!

你看这标题,没错,K8s 的。兜转两载,我还是决定从“DevOps 工程师”变回“机器学习平台研发工程师”。直观一点讲,就是“云平台开发”那点事配上 GPU 那点料,是不是很好理解?

Anyway,以后又有机会玩 K8s 了,所以接下来我会继续更新和 K8s 或者“机器学习平台”相关的内容。总之总之,你们蹲了那么久的更新,来了!

2. 聊啥

今天有个同事问我:在1个 Pod 中跑多个 Container,如果其中一个挂了,另外一个会怎样?

嗯…… 我记得大概,不过没有确切的结论,这个取决于 probes 是怎么工作的,于是我实测了一下,发现和预期不是完全一致。

于是乎,今天和大伙分享下这个知识点。

3. 结论(TL;DR)

对,结论在开头。毕竟,我知道你们都很忙。


一番操作猛如虎,然后我发现:

当1个 Pod 中包含2个 Containers 的时候,如果2个 Containers 分别对外暴露不同的端口(http 服务为例),当其中有1个 Container 的:

  1. Liveness probe 失败,则该 Container 会被 Kubelet 干掉,然后该 Container 重启/重建(当然,你的重启策略得是 Always),另外一个 Container 不会重启(也就是不会发生 Pod 级别的重启/重建,因此 Pod IP 也不会变化);
  2. Readiness probe 失败,这时候 Pod 状态里的 Ready 列自然是1/2,关键是 Service 会怎样工作呢?
    1. 当使用1个 Service 负载流量到这个 Pod 的2个端口时,Service 对应的 Endpoint 会变成 NotReady,导致 Pod 中 ready 的那个 Container 也不能通过 Service 地址访问到;
    2. 当使用2个不同的 Service 分别负载流量到这个 Pod 的2个端口时,很遗憾,对应的2个 Endpoint 均会变成 NotReady,而不是1个 Ready,一个 NotReady。(这是和我最开始的猜测不相符的)

4. 测试过程

你居然看到了这里,宝子,你是个求知欲很强的孩子啊!

4.1 准备测试用镜像

我想用 NGINX 镜像来完成这次 probes 特性测试,但是要让2个 containers 在1个 Pod 里监听不同的端口,那就得重新打下镜像,包一层了。

1. 首先,准备一个配置文件

  • default.conf
1
2
3
4
5
6
7
8
server {
    listen 8080;

    location / {
        root   /usr/share/nginx/html;
        index  index.html index.htm;
    }
}

2. 然后准备一个 Dockerfile

  • Dockerfile
1
2
3
4
5
6
7
FROM nginx

RUN rm /etc/nginx/conf.d/default.conf

COPY default.conf /etc/nginx/conf.d/

EXPOSE 8080

注意到这里我们将端口号指定成了8080。

3. 接着 build 一下

1
docker build -t my-nginx-8080:1.0 .

很酷,第一个镜像有了。然后咱需要继续搞一个监听8081端口的新镜像。

4. 更新配置文件

  • default.conf
1
2
3
4
5
6
7
8
server {
    listen 8081;

    location / {
        root   /usr/share/nginx/html;
        index  index.html index.htm;
    }
}

5. 更新 Dockerfile

1
2
3
4
5
6
7
FROM nginx

RUN rm /etc/nginx/conf.d/default.conf

COPY default.conf /etc/nginx/conf.d/

EXPOSE 8081

6. build 第二个镜像

1
docker build -t my-nginx-8081:1.0 .

OK,到这里2个镜像就准备完成了。接着如何将镜像丢到 K8s worker 节点,大家就各显神通吧,通过镜像仓库也行,手动拷贝也罢。

4.2 准备 Deployment YAML

首先跑一个 probe 能过的版本,确保“1 Pod 2 Container”启起来。

  • deploy.yaml
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx-container1
        image: my-nginx-8080:1.0
        ports:
        - containerPort: 8080
        livenessProbe:
          httpGet:
            path: /
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 5
        readinessProbe:
          httpGet:
            path: /
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 5
      - name: nginx-container2
        image: my-nginx-8081:1.0
        ports:
        - containerPort: 8081
        livenessProbe:
          httpGet:
            path: /
            port: 8081
          initialDelaySeconds: 5
          periodSeconds: 5
        readinessProbe:
          httpGet:
            path: /
            port: 8081
          initialDelaySeconds: 5
          periodSeconds: 5

4.3 准备 Service YAML

然后准备一个 Service,用来测试 readinessProbe 相关行为。

  • svc.yaml
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
apiVersion: v1
kind: Service
metadata:
  name: my-nginx-service
spec:
  selector:
    app: nginx
  ports:
    - name: port1
      protocol: TCP
      port: 8080
      targetPort: 8080
    - name: port2
      protocol: TCP
      port: 8081
      targetPort: 8081

4.4 准备第二个 Service YAML

如果是分开的2个 Services 去转发流量到 Pod 内的2个 Containers 呢?也试一下:

  • svc-2.yaml
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
apiVersion: v1
kind: Service
metadata:
  name: my-nginx-service-1
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 8080
      targetPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: my-nginx-service-2
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 8081
      targetPort: 8081

4.5 测试过程

Apply YAML 后,依次将 Deployment 配置里的 livenessProbe.httpGet.pathreadinessProbe.httpGet.path 从正确的 / 改成会引发404的 /hehe,然后观察 Pod 的状态变化,Service/Endpoint 的状态变化,就可以啦。

(对,不放截图,显得冗长,不是懒,真的不是懒!)

5. 结论

前面贴过结论了,复制粘贴一波:

当1个 Pod 中包含2个 Containers 的时候,如果2个 Containers 分别对外暴露不同的端口(http 服务为例),当其中有1个 Container 的:

  1. Liveness probe 失败,则该 Container 会被 Kubelet 干掉,然后该 Container 重启/重建(当然,你的重启策略得是 Always),另外一个 Container 不会重启(也就是不会发生 Pod 级别的重启/重建,因此 Pod IP 也不会变化);
  2. Readiness probe 失败,这时候 Pod 状态里的 Ready 列自然是1/2,关键是 Service 会怎样工作呢?
    1. 当使用1个 Service 负载流量到这个 Pod 的2个端口时,Service 对应的 Endpoint 会变成 NotReady,导致 Pod 中 ready 的那个 Container 也不能通过 Service 地址访问到;
    2. 当使用2个不同的 Service 分别负载流量到这个 Pod 的2个端口时,很遗憾,对应的2个 Endpoint 均会变成 NotReady,而不是1个 Ready,一个 NotReady。(这是和我最开始的猜测不相符的)

6. 结尾

没看够?别急嘛,关注微信公众号“胡说云原生”,来日方长,see you tomorrow。