当前位置：首页 > news >正文

k8s之Pod

news 来源：原创 2024/4/30 1:19:42

什么是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