- 1. 开篇
- 2. 聊啥
- 3. 结论(TL;DR)
-
4. 测试过程
- 4.1 准备测试用镜像
- 4.2 准备 Deployment YAML
- 4.3 准备 Service YAML
- 4.4 准备第二个 Service YAML
- 4.5 测试过程
- 5. 结论
- 6. 结尾
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 的:
- Liveness probe 失败,则该 Container 会被 Kubelet 干掉,然后该 Container 重启/重建(当然,你的重启策略得是 Always),另外一个 Container 不会重启(也就是不会发生 Pod 级别的重启/重建,因此 Pod IP 也不会变化);
- Readiness probe 失败,这时候 Pod 状态里的 Ready 列自然是1/2,关键是 Service 会怎样工作呢?
- 当使用1个 Service 负载流量到这个 Pod 的2个端口时,Service 对应的 Endpoint 会变成 NotReady,导致 Pod 中 ready 的那个 Container 也不能通过 Service 地址访问到;
- 当使用2个不同的 Service 分别负载流量到这个 Pod 的2个端口时,很遗憾,对应的2个 Endpoint 均会变成 NotReady,而不是1个 Ready,一个 NotReady。(这是和我最开始的猜测不相符的)
4. 测试过程
你居然看到了这里,宝子,你是个求知欲很强的孩子啊!
4.1 准备测试用镜像
我想用 NGINX 镜像来完成这次 probes 特性测试,但是要让2个 containers 在1个 Pod 里监听不同的端口,那就得重新打下镜像,包一层了。
1. 首先,准备一个配置文件
- default.conf
server {
listen 8080;
location / {
root /usr/share/nginx/html;
index index.html index.htm;
}
}
2. 然后准备一个 Dockerfile
- Dockerfile
FROM nginx
RUN rm /etc/nginx/conf.d/default.conf
COPY default.conf /etc/nginx/conf.d/
EXPOSE 8080
注意到这里我们将端口服务器托管网号指定成了8080。
3. 接着 build 一下
docker build -t my-nginx-8080:1.0 .
很酷,第一个镜像有了。然后咱需要继续搞一个监听8081端口的新镜像。
4. 更新配置文件
- default.conf
server {
listen 8081;
location / {
root /usr/share/nginx/html;
index index.html index.htm;
}
}
5. 更新 Dockerfile
FROM nginx
RUN rm /etc/nginx/conf.d/default.conf
COPY default.conf /etc/nginx/conf.d/
EXPOSE 8081
6. build 第二个镜像
docker build -t my-nginx-8081:1.0 .
OK,到这里2个镜像就准备完成了。接着如何将镜像丢到 K8s worker 节点,大家就各显神通吧,通过镜像仓库也行,手动拷贝也罢。
4.2 准备 Deployment YAML
首先跑一个 probe 能过的版本,确保“1 Pod 2 Container”启起来。
- deploy.yaml
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:
- container服务器托管网Port: 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
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
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.path
和 readinessProbe.httpGet.path
从正确的 /
改成会引发404的 /hehe
,然后观察 Pod 的状态变化,Service/Endpoint 的状态变化,就可以啦。
(对,不放截图,显得冗长,不是懒,真的不是懒!)
5. 结论
前面贴过结论了,复制粘贴一波:
当1个 Pod 中包含2个 Containers 的时候,如果2个 Containers 分别对外暴露不同的端口(http 服务为例),当其中有1个 Container 的:
- Liveness probe 失败,则该 Container 会被 Kubelet 干掉,然后该 Container 重启/重建(当然,你的重启策略得是 Always),另外一个 Container 不会重启(也就是不会发生 Pod 级别的重启/重建,因此 Pod IP 也不会变化);
- Readiness probe 失败,这时候 Pod 状态里的 Ready 列自然是1/2,关键是 Service 会怎样工作呢?
- 当使用1个 Service 负载流量到这个 Pod 的2个端口时,Service 对应的 Endpoint 会变成 NotReady,导致 Pod 中 ready 的那个 Container 也不能通过 Service 地址访问到;
- 当使用2个不同的 Service 分别负载流量到这个 Pod 的2个端口时,很遗憾,对应的2个 Endpoint 均会变成 NotReady,而不是1个 Ready,一个 NotReady。(这是和我最开始的猜测不相符的)
6. 结尾
没看够?别急嘛,关注微信公众号“胡说云原生”,来日方长,see you tomorrow。
服务器托管,北京服务器托管,服务器租用 http://www.fwqtg.net
机房租用,北京机房租用,IDC机房托管, http://www.fwqtg.net