-
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 ...- 1
在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- 1
- 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>- 1
- 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>- 1
- 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- 1
- 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) ....- 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
然后再通过docker inspect找到限制该容器的cgroup的路径
>>> docker inspect c60e37 | grep Cgroup "CgroupnsMode": "host", "Cgroup": "", "CgroupParent": "/kubepods/burstable/poda9ca2eed-ef7b-4564-b448-e35b06c7bdd0", "DeviceCgroupRules": null- 1
- 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- 1
- 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- 1
- 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- 1
- 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- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
欢迎关注，互相学习，共同进步~
我的个人博客
我的微信公众号：编程黑洞
-
相关阅读:
文件上传漏洞中常见文件解析
【定时同步系列10】16QAM基带调制+Gardener定时误差检测+解调误码率曲线之MATLAB仿真
数字IC手撕代码-XX公司笔试真题（脉冲密度调制）
supervisor--go版安装
MySql数据结构以及时间复杂度
MongoDB第一话 -- Docker安装MongoDB以及Springboot集成MongoDB
2022年第一季度保险服务数字化跟踪分析
【数据结构】跳表
2020年全国职业院校技能大赛改革试点赛样卷三
死灰复燃！QakBot 恶意软件仍在运行中
- 原文地址：https://blog.csdn.net/qq_22918243/article/details/126667622
