k8s之Pod
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
再使用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>
我们可以使用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>
一般我们不直接创建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
我们再来看看是怎么使用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)
....
然后再通过docker inspect找到限制该容器的cgroup的路径
>>> docker inspect c60e37 | grep Cgroup
"CgroupnsMode": "host",
"Cgroup": "",
"CgroupParent": "/kubepods/burstable/poda9ca2eed-ef7b-4564-b448-e35b06c7bdd0",
"DeviceCgroupRules": null
我们再进入到/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
我们进入到nginx的容器ID目录下，查看tasks文件，发现有很多进程ID，为什么呢？
[root@k8s-worker1 c60e370dd413f240164aec3f98cb35a8d09f6a3833c414a6c7a767d51977b859]# cat tasks
2733304
2733402
2733403
2733404
2733405
2733406
2733407
2733408
2733409
容器就是一个隔离的进程，我们看下该容器的进程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
我通过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
欢迎关注，互相学习，共同进步~
我的个人博客
我的微信公众号：编程黑洞
K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容
更多推荐
0
0- 0
已为社区贡献10条内容
所有评论(0)