k8s中如何对某个pod进行故障隔离?
1、背景说明
问你个问题: 对于一个deployment创建出来的多个副本的pod,想要对其中一个进行“故障隔离”,该怎么办?
本篇文档,在接下去的部分会为你进行揭秘······
2、示例演示
为了能够让你,准确的理解,究竟“故障隔离”干了什么事情,我们用一个鲜活的例子进行演示。
2.1 环境准备
首先,模拟创建2个副本的deployment和对应service
[root@nccztsjb-node-23 ~]# cat nginx-deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment spec: selector: matchLabels: app: nginx replicas: 2 template: metadata: labels: app: nginx #注意这里的标签! spec: containers: - name: nginx image: 172.20.58.152/middleware/nginx:1.21.4 ports: - containerPort: 80 [root@nccztsjb-node-23 ~]# cat nginx-svc.yaml apiVersion: v1 kind: Service metadata: labels: app: nginx-svc name: nginx-svc spec: ports: - name: 80-80 port: 80 protocol: TCP targetPort: 80 selector: app: nginx #注意这里的标签! type: ClusterIP [root@nccztsjb-node-23 ~]# kubectl apply -f nginx-deployment.yaml -f nginx-svc.yaml deployment.apps/nginx-deployment created service/nginx-svc created
这里,用到了很重要的一点就是——标签(label)
查看已经创建好的pod,以及对应的标签:
[root@nccztsjb-node-23 ~]# kubectl get pod -o wide --show-labels NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES LABELS nginx-deployment-5d84d847f4-6j928 1/1 Running 0 8s 172.39.157.234 nccztsjb-node-24 <none> <none> app=nginx,pod-template-hash=5d84d847f4 nginx-deployment-5d84d847f4-jwdqp 1/1 Running 0 8s 172.39.21.102 nccztsjb-node-25 <none> <none> app=nginx,pod-template-hash=5d84d847f4
查看对应的endpoints(创建service自动生成)
[root@nccztsjb-node-23 ~]# kubectl get endpoints nginx-svc NAME ENDPOINTS AGE nginx-svc 172.39.157.234:80,172.39.21.102:80 27s
我们从以上的查询结果中,可以清晰的看到endpoints已经正确的关联了2个pod的IP和端口号
2.2、修改pod标签
ok,关键的地方来了,为了达到对某个pod进行故障隔离的方式,并且不让前端的流量打入进去,我们该怎么办?
我们知道,endpoints(service)和pod的关联通过标签。
deployment创建pod副本的关联方式也是标签。
那么,知道这个原理就很简单了。
对的,修改某个需要进行故障隔离的标签。
通过以下的命令,修改某个pod的标签:
kubectl edit pod nginx-deployment-5d84d847f4-jwdqp
修改后,查看pod:
[root@nccztsjb-node-23 ~]# kubectl get pod -o wide --show-labels NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES LABELS nginx-deployment-5d84d847f4-6j928 1/1 Running 0 2m31s 172.39.157.234 nccztsjb-node-24 <none> <none> app=nginx,pod-template-hash=5d84d847f4 nginx-deployment-5d84d847f4-gb9zm 1/1 Running 0 5s 172.39.21.104 nccztsjb-node-25 <none> <none> app=nginx,pod-template-hash=5d84d847f4 nginx-deployment-5d84d847f4-jwdqp 1/1 Running 0 2m31s 172.39.21.102 nccztsjb-node-25 <none> <none> app=nginxtest,pod-template-hash=5d84d847f4
发现:pod标签已经被修改了,并且原来的又创建出来一个pod。说明:修改标签后的pod已经不输出原来deployment管理的范畴了。
查看endpoints
[root@nccztsjb-node-23 ~]# kubectl get endpoints nginx-svc NAME ENDPOINTS AGE nginx-svc 172.39.157.234:80,172.39.21.104:80 38m [root@nccztsjb-node-23 ~]#
再看endpoints,那个pod的IP已经不在了,取而代之的是,新启动的pod的IP和端口。
所以,到这里我们明白了,针对deployment创建出来的pod,也是可以进行故障隔离的,最简单的方法就是修改pod的标签。
不过,带来的问题是,这个pod不受这个deployment管理了。
怎么理解这个呢,我们删除这个deployment······
[root@nccztsjb-node-23 ~]# kubectl delete -f nginx-deployment.yaml deployment.apps "nginx-deployment" deleted [root@nccztsjb-node-23 ~]#
再来看看pod
[root@nccztsjb-node-23 ~]# kubectl get pod -o wide --show-labels NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES LABELS nginx-deployment-5d84d847f4-jwdqp 1/1 Running 0 52m 172.39.21.102 nccztsjb-node-25 <none> <none> app=nginxtest,pod-template-hash=5d84d847f4 [root@nccztsjb-node-23 ~]#
惊奇的发现,deployment删除了,对应的pod删除,但是这个改过标签的pod成为了孤立的pod了,没人管了。
要删除这个pod,需要单独的使用kubelet delete pod来删除。
所以,通过上面的一个完整的例子,你可以看出来。
对deployment创建出来的pod,进行故障隔离的方法很简单:
修改pod的标签。