k8s之Pod
# 什么是pod?
Pod是一组共享了某些资源的容器。
容器的隔离是通过各种namespace来实现的,Pod 里的所有容器,可以通过Namespace来共享系统资源,像Network Namepsace。
# 为什么需要Pod?
众所周知所周知,容器是一个特殊的进程,但有些场景是,一个应用的运行,是需要多个进程结合使用,并有一定的依赖关系的。虽然我们也可以使用单独的容器来配置运行应用,但是都是独立的。而pod是k8s的原子调度,pod中的容器可以指定分配到同一个节点,统一按照资源调度。
使用docker也可以实现A、B容器共享网络和Volume,但是容器B必须比容器A先启动,是一个拓扑结构,而不是平等关系
$ docker run --net=B --volumes-from=B --name=A image-A ...
在Pod中,先创建启动的是Infra容器,该容器会处于一个禁止状态,而其他定义的容器,则通过Join Network Namespace与Infra容器连接在一起。
在Pod中的容器处于同一个Network Namespace中,所以可以通过localhost直接进行通信,看到的网络设备是一致的。而Pod的生命周期和Infra容器一致,和容器A、B无关。
Pod,实际上是在扮演传统基础设施里“虚拟机”的角色;而容器,则是这个虚拟机里运行的用户程序。
# 使用Pod
使用yaml来描述一个Pod。
apiVersion: v1
kind: Pod
metadata:
name: nginx-pod
spec:
containers:
- name: nginx
image: nginx:laster
2
3
4
5
6
7
8
9
10
再使用kubectl apply来创建pod
[root@k8s-worker1 zwf]# kubectl apply -f pod.yaml -n zwf
pod/nginx-pod created
[root@k8s-worker1 zwf]# kubectl get pods -n zwf -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-pod 1/1 Running 0 2m51s 10.222.126.60 k8s-worker2 <none> <none>
2
3
4
5
6
我们可以使用curl访问到pod中的nginx的服务了
[root@k8s-worker1 zwf]# curl 10.222.126.60:80
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>
<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>
<p><em>Thank you for using nginx.</em></p>
</body>
</html>
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
一般我们不直接创建Pod,而是通过各种控制器来管理创建
# 容器状态探针
- ReadinessProbe
就绪性探针,判断容器中的程序是否健康,不健康,则会将该pod从service可用端点列表移除。
- livenessProbe
存活性探针,判断容器是否健康,不健康,则会将容器重启。 注意:是将容器重启而不是pod
- startupProbe
在pod启动后按照配置执行一次,如果成功,则不再执行,如果失败,则会重启pod. 其他两个探针是在startupProbe运行成功之前都是暂停的。
探测方式
exec,执行一个Linux命令,看返回值
tcpSocket,使用tcp尝试连接某个端口,看是否连接成功
httpGet,尝试使用http请求,看是否请求成功
# 资源配置
在配置中使用resources字段来设置限制容器的资源。
requests,系统必须预留的可用资源
limits,容器可申请使用的最大可用资源,超过则会被kill的可能性
这里的cpu使用的是m(milli)的单位,1000m代表1个cpu,10m代表1%cpu
而内存使用Mi代表MB。
apiVersion: v1
kind: Pod
metadata:
name: ngx-pod-resources
spec:
containers:
- image: nginx:alpine
name: ngx
resources:
requests:
cpu: 10m
memory: 100Mi
limits:
cpu: 20m
memory: 200Mi
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
我们再来看看是怎么使用cgroup来限制pod中容器的资源
先找到pod中该容器的ID
>>> kubectl describe pod -n zwf ngx-pod-resources
Name: ngx-pod-resources
Namespace: zwf
Priority: 0
Node: k8s-worker1/10.64.2.141
Start Time: Tue, 30 Aug 2022 16:11:45 +0800
Labels: <none>
Annotations: cni.projectcalico.org/containerID: 4c8f23863e6589d44b96ded48a2abd857ca9e45637fb9dd6b106c3c217be0904
cni.projectcalico.org/podIP: 10.222.194.100/32
cni.projectcalico.org/podIPs: 10.222.194.100/32
Status: Running
IP: 10.222.194.100
IPs:
IP: 10.222.194.100
Containers:
ngx:
Container ID: docker://c60e370dd413f240164aec3f98cb35a8d09f6a3833c414a6c7a767d51977b859
Image: nginx:alpine
Image ID: docker-pullable://nginx@sha256:082f8c10bd47b6acc8ef15ae61ae45dd8fde0e9f389a8b5cb23c37408642bf5d
Port: <none>
Host Port: <none>
State: Running
Started: Tue, 30 Aug 2022 16:11:54 +0800
Ready: True
Restart Count: 0
Limits:
cpu: 20m
memory: 200Mi
Requests:
cpu: 10m
memory: 100Mi
Environment: <none>
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-jcccn (ro)
....
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
然后再通过docker inspect找到限制该容器的cgroup的路径
>>> docker inspect c60e37 | grep Cgroup
"CgroupnsMode": "host",
"Cgroup": "",
"CgroupParent": "/kubepods/burstable/poda9ca2eed-ef7b-4564-b448-e35b06c7bdd0",
"DeviceCgroupRules": null
2
3
4
5
我们再进入到/sys/fs/cgroup/cpu/kubepods/burstable/poda9ca2eed-ef7b-4564-b448-e35b06c7bdd0,可以看到有两个容器ID的目录,因为除了我们nginx容器之外,还有一个infra容器。
[root@k8s-worker1]# cd /sys/fs/cgroup/cpu/kubepods/burstable/poda9ca2eed-ef7b-4564-b448-e35b06c7bdd0
[root@k8s-worker1]# ls
4c8f23863e6589d44b96ded48a2abd857ca9e45637fb9dd6b106c3c217be0904 cpuacct.usage cpuacct.usage_sys cpu.rt_runtime_us
c60e370dd413f240164aec3f98cb35a8d09f6a3833c414a6c7a767d51977b859 cpuacct.usage_all cpuacct.usage_user cpu.shares
cgroup.clone_children cpuacct.usage_percpu cpu.cfs_period_us cpu.stat
cgroup.procs cpuacct.usage_percpu_sys cpu.cfs_quota_us notify_on_release
cpuacct.stat cpuacct.usage_percpu_user cpu.rt_period_us tasks
2
3
4
5
6
7
8
9
我们进入到nginx的容器ID目录下,查看tasks文件,发现有很多进程ID,为什么呢?
[root@k8s-worker1 c60e370dd413f240164aec3f98cb35a8d09f6a3833c414a6c7a767d51977b859]# cat tasks
2733304
2733402
2733403
2733404
2733405
2733406
2733407
2733408
2733409
2
3
4
5
6
7
8
9
10
容器就是一个隔离的进程,我们看下该容器的进程ID,再通过该ID找到该进程,确实是nginx没错,也在cgroup的tasks文件中,但是其他的进程ID是什么呢?
[root@k8s-worker1 c60e370dd413f240164aec3f98cb35a8d09f6a3833c414a6c7a767d51977b859]# docker inspect c60e | grep Pid
"Pid": 2733304,
"PidMode": "",
"PidsLimit": null,
[root@k8s-worker1 c60e370dd413f240164aec3f98cb35a8d09f6a3833c414a6c7a767d51977b859]# ps aux | grep 2733304
root 2733304 0.0 0.0 6304 4544 ? Ss 16:11 0:00 nginx: master process nginx -g daemon off;
root 2787238 0.0 0.0 12132 1156 pts/3 S+ 16:45 0:00 grep --color=auto 2733304
2
3
4
5
6
7
8
我通过ps aux来搜索一下nginx,容器ID为nginx master,而其他的进程ID都是nginx的worker进程。
[root@k8s-worker1 c60e370dd413f240164aec3f98cb35a8d09f6a3833c414a6c7a767d51977b859]# ps aux | grep nginx
root 2733304 0.0 0.0 6304 4544 ? Ss 16:11 0:00 nginx: master process nginx -g daemon off;
101 2733402 0.0 0.0 6760 1648 ? S 16:11 0:00 nginx: worker process
101 2733403 0.0 0.0 6760 1648 ? S 16:11 0:00 nginx: worker process
101 2733404 0.0 0.0 6760 1648 ? S 16:11 0:00 nginx: worker process
101 2733405 0.0 0.0 6760 1648 ? S 16:11 0:00 nginx: worker process
101 2733406 0.0 0.0 6760 1648 ? S 16:11 0:00 nginx: worker process
101 2733407 0.0 0.0 6760 1648 ? S 16:11 0:00 nginx: worker process
101 2733408 0.0 0.0 6760 1648 ? S 16:11 0:00 nginx: worker process
101 2733409 0.0 0.0 6760 1648 ? S 16:11 0:00 nginx: worker process
root 2781594 0.0 0.0 12132 1164 pts/3 S+ 16:41 0:00 grep --color=auto nginx
2
3
4
5
6
7
8
9
10
11