devbox
很楠不爱3
这个屌丝很懒，什么也没留下！
关注作者
热门标签
热门文章
当前位置:   article > 正文

k8s之Pod_cpu是10m

作者：很楠不爱3 | 2024-03-24 21:29:14

赞

踩

cpu是10m

什么是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运行成功之前都是暂停的。

img探测方式

  • 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

欢迎关注，互相学习，共同进步~

我的个人博客

我的微信公众号：编程黑洞

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/很楠不爱3/article/detail/305018
推荐阅读
相关标签

Copyright © 2003-2013 www.wpsshop.cn 版权所有，并保留所有权利。

  

闽ICP备14008679号