容器编排系统k8s之Pod生命周期、健康/就绪状态探测以及资源限制

  前文我们了解了在k8s上的资源标签、标签选择器以及资源注解相关话题,回顾请参考https://www.cnblogs.com/qiuhom-1874/p/14141080.html;今天我们来聊下k8s上的核心资源pod生命周期、健康/就绪状态探测以及pod资源限制相关话题;

  1、Pod生命周期

  pod生命周期是指在pod开始创建到pod退出所消耗的时间范围,我们把开始到结束的这段时间范围就叫做pod的生命周期;其大概过程如下图所示

  提示:上图主要描述了一个pod从创建到退出,中间这段时间经历的过程;从大的方向上看,pod生命周期分两个阶段,第一阶段是初始化容器,第二阶段是主容器的整个生命周期;其中对于主容器来来说,它的生命周期有分了三个阶段,第一阶段是运行post start hook,这个阶段是主容器运行之后立即需要做的事;第二阶段是主容器正常运行的阶段,在这个阶段中,我们可以定义对容器的健康状态检查和就绪状态检查;第三阶段是运行pre stop hook,这个阶段主要做容器即将退出前需要做的事;这里需要注意对于初始化容器来说,一个pod中可以定义多个初始化容器,他们必须是串行执行,只有当所有的初始化容器执行完后,对应的主容器才会启动;对于对容器的健康状态检查和就绪状态检查,我们也可以定义开始检查的延迟时长;因为有些容器存在容器显示running状态,但内部程序还没有初始化,如果立即做健康状态检查,可能存在健康状态为不健康,从而导致容器重启的状况;

  2、Pod创建过程

  提示:首先用户通过客户端工具将请求提交给apiserver,apiserver收到用户的请求以后,它会尝试将用户提交的请求内容存进etcd中,etcd存入完成后就反馈给apiserver写入数据完成,此时apiserver就返回客户端,说某某资源已经创建;随后apiserver要发送一个watch信号给scheduler,说要创建一个新pod,请你看看在那个节点上创建合适,scheduler收到信号以后,就开始做调度,并把调度后端结果反馈给apiserver,apiserver收到调度器的调度信息以后,它就把对应调度信息保存到etcd中,随后apiServer要发送一个watch信号给对应被调度的主机上的kubelet,对应主机上的kubelet收到消息后,立刻调用docker,并把对应容器跑起来;当容器运行起来以后,docker会向kubelet返回容器的状体;随后kubelet把容器的状态反馈给apiserver,由apiserver把容器的状态信息保存到etcd中;最后当etcd中的容器状态信息更新完成后,随后apiserver把容器状态信息更新完成的消息发送给对应主机的kubelet;

  3、在资源配置清单中定义初始化容器

[root@master01 ~]# cat pod-demo6.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod-demo6
  namespace: default
  labels:
    app: nginx
    env: testing
  annotations:
    descriptions: "this is test pod "
spec:
  containers:
  - image: nginx:1.14-alpine
    imagePullPolicy: IfNotPresent
    name: nginx
    ports:
      - containerPort: 80
        hostPort: 8080
        name: web
        protocol: TCP
  initContainers:
  - name: init-something
    image: busybox
    command:
    - /bin/sh
    - -c 
    - "sleep 60"
[root@master01 ~]# 

  提示:在资源配置清单中定义初始化容器需要在spec字段下,使用initContainers字段来定义,这个字段的值是一个列表对象;初始化容器的定义和主容器的定义方式很类似;上面初始化容器中主要干了一件事,就是sleep 60,意思是在启动主容器前,首先要让初始化容器中的操作执行完以后,对应的主容器才会开始运行;如果定义的初始化容器有多个,则要等待所有初始化容器中的操作执行完以后,对应主容器才会开始启动;

  4、Pod生命周期的两个函数钩子的使用

  postStart:这个函数钩子主要用来定义在主容器启动之后,立即需要做的事,比如执行一个命令,创建一个文件等等;这里需要注意的是,postStart这个函数钩子说定义的操作,都是针对主容器的,所以执行命令或其他操作的前提都是主容器上能够正常执行的操作;

  示例:定义运行一个nginx容器,在容器启动之后立即在对应html目录下创建一个文件,作为用户自定义测试页面

[root@master01 ~]# cat pod-demo7.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod-demo7
  namespace: default
  labels:
    app: nginx
    env: testing
  annotations:
    descriptions: "this is test pod "
spec:
  containers:
  - image: nginx:1.14-alpine
    imagePullPolicy: IfNotPresent
    name: nginx
    ports:
      - containerPort: 80
        hostPort: 8080
        name: web
        protocol: TCP
    lifecycle:
      postStart: 
        exec:
          command: 
          - /bin/sh
          - -c
          - "echo 'this is test page' > /usr/share/nginx/html/test.html"
[root@master01 ~]# 

  提示:在资源配置清单中定义主容器启动之后需要做的事,需要在对应主容器下用lifecycle字段来定义;其中postStart字段使用用来指定主容器启动之后要做到事,这个字段的值是一个对象;其中exec是用来定义使用exec来执行命令,command字段用来指定要执行的命令;除了可以用exec来定义执行命令,还可以使用httpGet来向当前容器中的url发起http请求,或者使用tcpSocket来向某个主机的某个端口套接字发起请求,默认不指定host表示向当前podip发起请求;

  执行配置清单

[root@master01 ~]# kubectl get pod
NAME                         READY   STATUS    RESTARTS   AGE
myapp-dep-5bc4d8cc74-cvkbc   1/1     Running   2          7d19h
myapp-dep-5bc4d8cc74-gmt7w   1/1     Running   3          7d19h
myapp-dep-5bc4d8cc74-gqhh5   1/1     Running   2          7d19h
ngx-dep-5c8d96d457-w6nss     1/1     Running   2          7d20h
[root@master01 ~]# kubectl apply -f pod-demo7.yaml
pod/nginx-pod-demo7 created
[root@master01 ~]# kubectl get pod -o wide
NAME                         READY   STATUS    RESTARTS   AGE     IP            NODE             NOMINATED NODE   READINESS GATES
myapp-dep-5bc4d8cc74-cvkbc   1/1     Running   2          7d19h   10.244.1.12   node01.k8s.org   <none>           <none>
myapp-dep-5bc4d8cc74-gmt7w   1/1     Running   3          7d19h   10.244.3.13   node03.k8s.org   <none>           <none>
myapp-dep-5bc4d8cc74-gqhh5   1/1     Running   2          7d19h   10.244.2.8    node02.k8s.org   <none>           <none>
nginx-pod-demo7              1/1     Running   0          6s      10.244.1.13   node01.k8s.org   <none>           <none>
ngx-dep-5c8d96d457-w6nss     1/1     Running   2          7d20h   10.244.2.9    node02.k8s.org   <none>           <none>
[root@master01 ~]# 

  验证:访问对应pod看看test.html是否能够访问到?

[root@master01 ~]# curl 10.244.1.13/test.html
this is test page
[root@master01 ~]# 

  提示:可以看到访问对应的pod的ip地址,能够访问到我们刚才定义容器启动之后创建的文件内容;

  preStop:这个函数钩子主要用来定义在容器结束之前需要做的事情,使用方式和postStart一样,都是在对应主容器里的lifesycle字段下定义;它也可以使用exec来执行命令或者httpGet来向容器的某个url发起请求,或者使用tcpSocket向某个套接字发起请求;

  示例:在容器结束前执行echo 命令

[root@master01 ~]# cat pod-demo8.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod-demo8
  namespace: default
  labels:
    app: nginx
    env: testing
  annotations:
    descriptions: "this is test pod "
spec:
  containers:
  - image: nginx:1.14-alpine
    imagePullPolicy: IfNotPresent
    name: nginx
    lifecycle:
      postStart: 
        exec:
          command: 
          - /bin/sh
          - -c
          - "echo 'this is test page' > /usr/share/nginx/html/test.html"
      preStop:
        exec:
          command: ["/bin/sh","-c","echo goodbye.."]
[root@master01 ~]# 

  5、pod终止过程

  提示:用户通过客户端工具想APIserver发送删除pod的指令,在APIserver收到用户发来的删除指令后,首先APIserver会把对应的操作写到etcd中,并设置其宽限期,然后etcd把对应数据写好以后,响应APIserver,随后APIserver响应客户端说对应容器已经标记为terminating状态;随后APIserver会发送一个把对应pod标记为terminating状态的消息给endpoint端点控制,让其删除与当前要删除pod相关的所有service,(其实在k8s上我们创建service关联pod不是直接关联pod,是现关联endpoint端点控制器,然后端点控制器再关联pod),随后APIserver会向对应要删除pod所在主机上的kubelet发送将pod标记为terminating状态的消息,当对应主机收到APIserver发送的标记pod为terminating状态消息后,对应主机上的kubelet会向对应pod里运行的容器发送TERM信号,随后再执行preStop中定义的操作;随后等待宽限期超时,如果对应的pod还没有被删除,此时APIserver就会向对应pod所在主机上的kubelet发送宽限期超时的消息,此时对应kubelet会向对应容器发送SIGKILL信号来强制删除对应的容器,随后docker把对应容器删除后,把删除完容器的消息响应给APIserver,此时APIserver会向etcd发送删除对应pod在etcd中的所有信息;

  6、pod健康状态探测

  所谓pod健康状态探测是指检查对应pod是否健康,如果不健康就把对应的pod重启;健康状态探测是一个周期性的工作;只要发现对应pod不健康,就重启对应pod;在k8s上对pod的健康状态探测的方式有三种,第一种上执行命令,只有对应命令执退出码为0就表示对应pod是处于健康状态,否则就不健康;第二种是用httpGet来探测对应pod里的容器的某个url是否可以访问,只有请求对应的url状态码为200才表示对应pod是健康的,否则就不健康;第三种是使用tcpSocket的方式来对某个套接字发送请求,只有套接字正常响应就表示对应pod是处于健康的,否则就是不健康;至于我们要使用那种方式来判断pod的健康与否,这取决与pod里的服务和业务逻辑;

  示例:使用exec执行命令的方式来探测pod的健康状态

[root@master01 ~]# cat pod-demo9.yaml
apiVersion: v1
kind: Pod
metadata:
  name: liveness-exec
  namespace: default
  labels:
    app: nginx
    env: testing
  annotations:
    descriptions: "this is test pod "
spec:
  containers:
  - image: nginx:1.14-alpine
    imagePullPolicy: IfNotPresent
    name: nginx
    lifecycle:
      postStart: 
        exec:
          command: 
          - /bin/sh
          - -c
          - "echo 'this is test page' > /usr/share/nginx/html/test.html"
      preStop:
        exec:
          command: ["/bin/sh","echo goodbay.."]
    livenessProbe:
      exec:
        command: ["/usr/bin/test","-e","/usr/share/nginx/html/test.html"]
[root@master01 ~]# 

  提示:使用配置清单定义pod的健康状态监测需要用到livenessProbe这个字段,这个字段的值是一个对象;以上配置表示判断/usr/share/nginx/html/test.html这个文件是否存在,存在就表示对应pod健康,否则就不健康;

  应用配置清单

[root@master01 ~]# kubectl apply -f pod-demo9.yaml
pod/liveness-exec created
[root@master01 ~]# kubectl get pod
NAME                         READY   STATUS    RESTARTS   AGE
liveness-exec                1/1     Running   0          4s
myapp-dep-5bc4d8cc74-cvkbc   1/1     Running   3          8d
myapp-dep-5bc4d8cc74-gmt7w   1/1     Running   4          8d
myapp-dep-5bc4d8cc74-gqhh5   1/1     Running   3          8d
nginx-pod-demo7              1/1     Running   1          4h45m
ngx-dep-5c8d96d457-w6nss     1/1     Running   3          8d
[root@master01 ~]# 

  提示:可以看到对应pod现在已经正常运行着,并且重启次数为0;

  测试:进入对应pod把test.html文件删除,看看对应pod还会正常处于健康状态吗?重启次数还是0吗?

[root@master01 ~]# kubectl exec liveness-exec -- rm -f /usr/share/nginx/html/test.html

  查看对应pod状态

[root@master01 ~]# kubectl get pod
NAME                         READY   STATUS    RESTARTS   AGE
liveness-exec                1/1     Running   1          2m45s
myapp-dep-5bc4d8cc74-cvkbc   1/1     Running   3          8d
myapp-dep-5bc4d8cc74-gmt7w   1/1     Running   4          8d
myapp-dep-5bc4d8cc74-gqhh5   1/1     Running   3          8d
nginx-pod-demo7              1/1     Running   1          4h48m
ngx-dep-5c8d96d457-w6nss     1/1     Running   3          8d
[root@master01 ~]# 

  提示:可以看到对应pod重启数已经变为1了,说明pod发生了重启;

  查看pod的详细信息

  提示:从上面的截图可以看到,pod健康状态检查不通过,就把容器给重启了;重启以后对应的文件又回重新创建,所以再次健康状态监测就通过了,所以pod处于健康状态;

  示例:使用httpGet探测对应pod是否健康

[root@master01 ~]# cat liveness-httpget.yaml
apiVersion: v1
kind: Pod
metadata:
  name: liveness-httpget
  namespace: default
  labels:
    app: nginx
    env: testing
  annotations:
    descriptions: "this is test pod "
spec:
  containers:
  - image: nginx:1.14-alpine
    imagePullPolicy: IfNotPresent
    name: nginx
    ports:
    - name: http
      containerPort: 80
    lifecycle:
      postStart: 
        exec:
          command: 
          - /bin/sh
          - -c
          - "echo 'this is test page' > /usr/share/nginx/html/test.html"
      preStop:
        exec:
          command: ["/bin/sh","echo goodbay.."]
    livenessProbe:
      httpGet:
        path: /test.html
        port: http
        scheme: HTTP
      failureThreshold: 2
      initialDelaySeconds: 2
      periodSeconds: 3
[root@master01 ~]# 

  提示:failureThreshold字段用于指定失败阈值,即多少次失败就把对应pod标记为不健康;默认是3次;initialDelaySeconds字段用于指定初始化后延迟多少时间再做健康状态监测;periodSeconds字段用于指定监测频率,默认是10秒一次;最小为1秒一次;以上配置清单表示对pod容器里的/test.html这个url发起请求,如果响应码为200就表示pod健康,否则就不健康;httpGet中必须指定端口,端口信息可以应用上面容器中定义的端口名称;

  应用配置清单

[root@master01 ~]# kubectl apply -f liveness-httpget.yaml
pod/liveness-httpget created
[root@master01 ~]# kubectl get pod
NAME                         READY   STATUS    RESTARTS   AGE
liveness-exec                1/1     Running   2          29m
liveness-httpget             1/1     Running   0          5s
myapp-dep-5bc4d8cc74-cvkbc   1/1     Running   3          8d
myapp-dep-5bc4d8cc74-gmt7w   1/1     Running   4          8d
myapp-dep-5bc4d8cc74-gqhh5   1/1     Running   3          8d
nginx-pod-demo7              1/1     Running   1          5h15m
ngx-dep-5c8d96d457-w6nss     1/1     Running   3          8d
[root@master01 ~]# 

  验证:进入对应pod,把test.html文件删除,看看对应pod是否会重启?

[root@master01 ~]# kubectl exec liveness-httpget -- rm -rf /usr/share/nginx/html/test.html
[root@master01 ~]# kubectl get pod
NAME                         READY   STATUS    RESTARTS   AGE
liveness-exec                1/1     Running   2          30m
liveness-httpget             1/1     Running   1          97s
myapp-dep-5bc4d8cc74-cvkbc   1/1     Running   3          8d
myapp-dep-5bc4d8cc74-gmt7w   1/1     Running   4          8d
myapp-dep-5bc4d8cc74-gqhh5   1/1     Running   3          8d
nginx-pod-demo7              1/1     Running   1          5h16m
ngx-dep-5c8d96d457-w6nss     1/1     Running   3          8d
[root@master01 ~]# 

  提示:可以看到对应pod已经发生了重启;

  查看pod详细信息

  提示:可以看到对应pod健康状态探测失败,并重启的事件;

  示例:使用tcpsocket方式来探测pod健康状态

[root@master01 ~]# cat liveness-tcpsocket.yaml
apiVersion: v1
kind: Pod
metadata:
  name: liveness-tcpsocket
  namespace: default
  labels:
    app: nginx
    env: testing
  annotations:
    descriptions: "this is test pod "
spec:
  containers:
  - image: nginx:1.14-alpine
    imagePullPolicy: IfNotPresent
    name: nginx
    ports:
    - name: http
      containerPort: 80
    livenessProbe:
      tcpSocket:
        port: http
      failureThreshold: 2
      initialDelaySeconds: 2
      periodSeconds: 3
[root@master01 ~]# 

  提示:使用tcpSocket方式来探测健康与否,默认不指定host字段表示探测对应podip;

  应用资源配置清单

[root@master01 ~]# kubectl apply -f liveness-tcpsocket.yaml 
pod/liveness-tcpsocket created
[root@master01 ~]# kubectl get pod
NAME                         READY   STATUS    RESTARTS   AGE
liveness-exec                1/1     Running   2          42m
liveness-httpget             1/1     Running   1          12m
liveness-tcpsocket           1/1     Running   0          5s
myapp-dep-5bc4d8cc74-cvkbc   1/1     Running   3          8d
myapp-dep-5bc4d8cc74-gmt7w   1/1     Running   4          8d
myapp-dep-5bc4d8cc74-gqhh5   1/1     Running   3          8d
nginx-pod-demo7              1/1     Running   1          5h27m
ngx-dep-5c8d96d457-w6nss     1/1     Running   3          8d
[root@master01 ~]# 

  测试:进入pod里的容器,修改nginx的端口为81,看看对应pod是否会重启?

[root@master01 ~]# kubectl exec liveness-tcpsocket -it -- /bin/sh
/ # netstat -tnl
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      
/ # grep "listen" /etc/nginx/conf.d/default.conf 
    listen       80;
    # proxy the PHP scripts to Apache listening on 127.0.0.1:80
    # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
/ # sed -i 's@    listen.*@    listen 81;@g' /etc/nginx/conf.d/default.conf 
/ # grep "listen" /etc/nginx/conf.d/default.conf 
    listen 81;
    # proxy the PHP scripts to Apache listening on 127.0.0.1:80
    # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
/ # nginx -s reload
2020/12/16 11:49:51 [notice] 35#35: signal process started
/ # command terminated with exit code 137
[root@master01 ~]# 

  提示:可以看到我们修改了配置文件让nginx监听81端口,没过几秒就退出了;

  查看对应pod是否发生了重启?

  提示:可以看到对应pod里的事件信息说健康状态监测10.244.3.22:80连接失败,容器重启了;

  7、pod就绪状态探测

  所谓pod就绪状态探测是指探测对应pod是否就绪,主要用在service关联后端pod的一个重要依据,如果对应pod未就绪,对应service就不应该关联pod,否则可能发生用户访问对应service,响应服务不可用;pod就绪状态检查和健康状态检查两者最主要的区别是,健康状态检查,一旦对应pod不健康了,就会执行重启对应pod的操作,而就绪状态检查是没有权限去重启pod,如果对应pod没有就绪,它不会做任何操作;同样的对就绪状态检查在k8s上也有三种方式和健康状态检查的方式一摸一样;

  示例:使用exec方式探测pod就绪状态

[root@master01 ~]# cat readiness-demo.yaml
apiVersion: v1
kind: Pod
metadata:
  name: readiness-demo
  namespace: default
  labels:
    app: nginx
    env: testing
  annotations:
    descriptions: "this is test pod "
spec:
  containers:
  - image: nginx:1.14-alpine
    imagePullPolicy: IfNotPresent
    name: nginx
    ports:
    - name: http
      containerPort: 80
    lifecycle:
      postStart:
        exec:
          command: ["/bin/sh","echo 'this is test page' > /usr/share/nginx/html/test.html"]
    readinessProbe:
      exec:
        command: ["/usr/bin/test","/usr/share/nginx/html/test.html"]
      failureThreshold: 2
      initialDelaySeconds: 2
      periodSeconds: 3
[root@master01 ~]# 

  提示:以上清单表示如果/usr/share/nginx/html/test.html文件存在,则表示对应pod就绪,否则就表示为就绪;

  应用配置清单

[root@master01 ~]# kubectl apply -f readiness-demo.yaml
pod/readiness-demo created
[root@master01 ~]# kubectl get pod
NAME                         READY   STATUS    RESTARTS   AGE
liveness-exec                1/1     Running   2          65m
liveness-httpget             1/1     Running   1          35m
liveness-tcpsocket           1/1     Running   1          23m
myapp-dep-5bc4d8cc74-cvkbc   1/1     Running   3          8d
myapp-dep-5bc4d8cc74-gmt7w   1/1     Running   4          8d
myapp-dep-5bc4d8cc74-gqhh5   1/1     Running   3          8d
nginx-pod-demo7              1/1     Running   1          5h50m
ngx-dep-5c8d96d457-w6nss     1/1     Running   3          8d
readiness-demo               0/1     Running   0          5s
[root@master01 ~]# kubectl get pod
NAME                         READY   STATUS    RESTARTS   AGE
liveness-exec                1/1     Running   2          65m
liveness-httpget             1/1     Running   1          36m
liveness-tcpsocket           1/1     Running   1          23m
myapp-dep-5bc4d8cc74-cvkbc   1/1     Running   3          8d
myapp-dep-5bc4d8cc74-gmt7w   1/1     Running   4          8d
myapp-dep-5bc4d8cc74-gqhh5   1/1     Running   3          8d
nginx-pod-demo7              1/1     Running   1          5h51m
ngx-dep-5c8d96d457-w6nss     1/1     Running   3          8d
readiness-demo               1/1     Running   0          25s
[root@master01 ~]# 

  提示:可以看到应用配置清单以后,对应的pod从未就绪到就绪状态了;

  测试:删除pod容器中的test.html文件,看看对应pod是否会从就绪状态到未就绪状态?

[root@master01 ~]# kubectl get pod
NAME                         READY   STATUS    RESTARTS   AGE
liveness-exec                1/1     Running   2          67m
liveness-httpget             1/1     Running   1          37m
liveness-tcpsocket           1/1     Running   1          25m
myapp-dep-5bc4d8cc74-cvkbc   1/1     Running   3          8d
myapp-dep-5bc4d8cc74-gmt7w   1/1     Running   4          8d
myapp-dep-5bc4d8cc74-gqhh5   1/1     Running   3          8d
nginx-pod-demo7              1/1     Running   1          5h52m
ngx-dep-5c8d96d457-w6nss     1/1     Running   3          8d
readiness-demo               1/1     Running   0          2m3s
[root@master01 ~]# kubectl exec readiness-demo -- rm -rf /usr/share/nginx/html/test.html
[root@master01 ~]# kubectl get pod
NAME                         READY   STATUS    RESTARTS   AGE
liveness-exec                1/1     Running   2          67m
liveness-httpget             1/1     Running   1          38m
liveness-tcpsocket           1/1     Running   1          25m
myapp-dep-5bc4d8cc74-cvkbc   1/1     Running   3          8d
myapp-dep-5bc4d8cc74-gmt7w   1/1     Running   4          8d
myapp-dep-5bc4d8cc74-gqhh5   1/1     Running   3          8d
nginx-pod-demo7              1/1     Running   1          5h53m
ngx-dep-5c8d96d457-w6nss     1/1     Running   3          8d
readiness-demo               0/1     Running   0          2m36s
[root@master01 ~]# 

  提示:可以看到对应pod已经处于未就绪状态了;

  查看对应pod的详细信息

  提示:在对应pod的详细信息中也能看到对应的事件,不同于健康状态探测,就绪状态探测,它这里不会重启pod;

  测试:创建test.html文件,看看对应pod是否会从未就绪状态到就绪状态?

[root@master01 ~]# kubectl exec readiness-demo -- touch /usr/share/nginx/html/test.htm
[root@master01 ~]# kubectl get pod
NAME                         READY   STATUS    RESTARTS   AGE
liveness-exec                1/1     Running   2          72m
liveness-httpget             1/1     Running   1          42m
liveness-tcpsocket           1/1     Running   1          30m
myapp-dep-5bc4d8cc74-cvkbc   1/1     Running   3          8d
myapp-dep-5bc4d8cc74-gmt7w   1/1     Running   4          8d
myapp-dep-5bc4d8cc74-gqhh5   1/1     Running   3          8d
nginx-pod-demo7              1/1     Running   1          5h57m
ngx-dep-5c8d96d457-w6nss     1/1     Running   3          8d
readiness-demo               1/1     Running   0          7m11s
[root@master01 ~]# 

  提示:可以看到对应pod已经处于就绪状态;

  8、pod资源限制

  所谓pod资源限制就是指限制对应pod里容器的cpu和内存使用量;我们知道如果一个容器不限制其资源的使用大小,很有可能发生一个容器将宿主机上的内存耗尽的情况,如果一旦发生内存耗尽,内核很有可能向容器进程发起oom(out of memory),这样一来运行在docker上的其他容器也会相继退出;所以为了不让类似的情况发生,我们有必要给pod里的容器做资源限定;

  资源计量方式

  对于cpu来讲,它是可压缩资源,所谓可以压缩资源就是表示cpu不够用时,它并不会报错,pod可以等待;对于内存来讲,它是不可压缩资源,不可压缩就是指如果内存不够用对应程序就会崩溃,从而导致容器退出;cpu的计量方式是m,即1核心=1000m,0.5个核心就等于500m;内存的计量方式默认单位是字节,我们在指定内存资源,直接加上单位即可;可以使用E、P、T、G、M、K为后缀单位,也可以使用Ei、Pi、Ti、Gi、Mi、Ki作为单位;

  示例:在资源清单中限制pod资源

[root@master01 ~]# cat resource.yaml
apiVersion: v1
kind: Pod
metadata:
  name: stress-pod
spec:
  containers:
  - name: stress
    image: ikubernetes/stress-ng
    command: ["/usr/bin/stress-ng","-c 1","-m 1","--metrics-brief"]
    resources:
      requests:
        memory: "128Mi"
        cpu: "200m"
      limits:
        memory: "512Mi"
        cpu: "400m"
[root@master01 ~]# 

  提示:定义pod的资源限制,需要用到resources这个字段,这个字段的值为一个对象;其中requests字段用于指定下限,limits指定资源的上限;

  应用资源清单

[root@master01 ~]# kubectl apply -f resource.yaml 
pod/stress-pod created
[root@master01 ~]# kubectl get pod -o wide
NAME                         READY   STATUS    RESTARTS   AGE     IP            NODE             NOMINATED NODE   READINESS GATES
liveness-exec                1/1     Running   2          147m    10.244.3.21   node03.k8s.org   <none>           <none>
liveness-httpget             1/1     Running   1          118m    10.244.2.14   node02.k8s.org   <none>           <none>
liveness-tcpsocket           1/1     Running   1          105m    10.244.3.22   node03.k8s.org   <none>           <none>
myapp-dep-5bc4d8cc74-cvkbc   1/1     Running   3          8d      10.244.1.16   node01.k8s.org   <none>           <none>
myapp-dep-5bc4d8cc74-gmt7w   1/1     Running   4          8d      10.244.3.17   node03.k8s.org   <none>           <none>
myapp-dep-5bc4d8cc74-gqhh5   1/1     Running   3          8d      10.244.2.11   node02.k8s.org   <none>           <none>
nginx-pod-demo7              1/1     Running   1          7h12m   10.244.1.14   node01.k8s.org   <none>           <none>
ngx-dep-5c8d96d457-w6nss     1/1     Running   3          8d      10.244.2.12   node02.k8s.org   <none>           <none>
readiness-demo               1/1     Running   0          82m     10.244.3.23   node03.k8s.org   <none>           <none>
stress-pod                   1/1     Running   0          13s     10.244.2.16   node02.k8s.org   <none>           <none>
[root@master01 ~]# 

  提示:可以看到stress-pod被调度到node02上运行了;

  测试:在node02上使用doucker stats命令查看对应stress-pod容器占用资源情况

  提示:可以看到在node02上跑的k8s_stress_stress-pod_default容器占有cpu和内存都是我们在资源清单中定义的量;

  示例:当pod里的容器资源不够用时,对应pod是否会发生oom呢?

[root@master01 ~]# cat memleak-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: memleak-pod
spec:
  containers:
  - name: simmemleak
    image: saadali/simmemleak
    resources:
      requests:
        memory: "64Mi"
        cpu: "1"
      limits:
        memory: "1Gi"
        cpu: "1"
[root@master01 ~]# 

  提示:以上配置清单主要限制了容器最大内存为1G,最小内存为64M,cpu上下限都为1核心;

  应用配置清单

[root@master01 ~]# kubectl apply -f memleak-pod.yaml
pod/memleak-pod created
[root@master01 ~]# kubectl get pod
NAME                         READY   STATUS              RESTARTS   AGE
liveness-exec                1/1     Running             2          155m
liveness-httpget             1/1     Running             1          126m
liveness-tcpsocket           1/1     Running             1          113m
memleak-pod                  0/1     ContainerCreating   0          2s
myapp-dep-5bc4d8cc74-cvkbc   1/1     Running             3          8d
myapp-dep-5bc4d8cc74-gmt7w   1/1     Running             4          8d
myapp-dep-5bc4d8cc74-gqhh5   1/1     Running             3          8d
nginx-pod-demo7              1/1     Running             1          7h21m
ngx-dep-5c8d96d457-w6nss     1/1     Running             3          8d
readiness-demo               1/1     Running             0          90m
stress-pod                   1/1     Running             0          8m46s
[root@master01 ~]# kubectl get pod
NAME                         READY   STATUS      RESTARTS   AGE
liveness-exec                1/1     Running     2          156m
liveness-httpget             1/1     Running     1          126m
liveness-tcpsocket           1/1     Running     1          114m
memleak-pod                  0/1     OOMKilled   0          21s
myapp-dep-5bc4d8cc74-cvkbc   1/1     Running     3          8d
myapp-dep-5bc4d8cc74-gmt7w   1/1     Running     4          8d
myapp-dep-5bc4d8cc74-gqhh5   1/1     Running     3          8d
nginx-pod-demo7              1/1     Running     1          7h21m
ngx-dep-5c8d96d457-w6nss     1/1     Running     3          8d
readiness-demo               1/1     Running     0          91m
stress-pod                   1/1     Running     0          9m5s
[root@master01 ~]# 

  提示:可以看到应用资源清单以后,对应的pod处于OOMKilled状态;原因是我们运行的镜像里面的程序一直申请内存,超出了最大限制;

  查看pod详细信息

  提示:可以看到当前pod状态为terminated状态,原因是OOMKilled;上一次状态为terminated,原因也是OOMKilled;

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐


文章浏览阅读942次。kube-controller-manager 和 kubelet 是异步工作的,这意味着延迟可能包括任何的网络延迟、apiserver 的延迟、etcd 延迟,一个节点上的负载引起的延迟等等。当 Kubernetes 中 Node 节点出现状态异常的情况下,节点上的 Pod 会被重新调度到其他节点上去,但是有的时候我们会发现节点 Down 掉以后,Pod 并不会立即触发重新调度,这实际上就是和 Kubelet 的状态更新机制密切相关的,Kubernetes 提供了一些参数配置来触发重新调度的时间。_node-monitor-period
文章浏览阅读3.8k次。上篇文章详细介绍了弹性云混部的落地历程,弹性云是滴滴内部提供给网约车等核心服务的容器平台,其基于 k8s 实现了对海量 node 的管理和 pod 的调度。本文重点介绍弹性云的调度能力,分为以下部分:调度链路图:介绍当前弹性云调度体系链路,对架构体系有一个初步的认知k8s 调度能力的运用:整体介绍弹性云现在用到的 k8s 调度能力和对其的增强k8s 版本的升级:介绍到从 k8s 1.12 到 1...._滴滴机房 腾讯
文章浏览阅读897次。对于cpu来说,这种分配方式并不会有太大问题,因为cpu可以灵活调度,numa调度时我们只计算绑定了numa cpu的pod是可以接受的,但是对于内存来说,numa node上申请了的内存无法做到随时迁移,这就会导致调度器视角numa node的mem资源足够,但是等到pod真正使用时,由于没有绑定numa node的pod申请的内存,导致numa node的mem资源不足,造成swap中断或者远端内存申请,这会对绑定mem的pod来带来性能损耗。忽略了没有绑定numa node的pod资源。_kubectl numa
文章浏览阅读796次,点赞17次,收藏15次。只要在Service定义中设置了ClusterIp:None,就定义了一个HeadLess Service, 它与普通的Service关键区别在于它没有ClusterIp地址,如果解析HeadLess Service的DNS域名,则会返回该Service对应的全部Pod的EndPoint列表,这就意味着客户端是直接与后端的pod建立了TCP/IP链接进行通信的。一个Label是一个键值对。注解:属于资源对象的元数据,可以被理解为一种特殊的标签,不过更多的是与程序挂钩,通常用于实现资源对象属性的自定义扩展。
文章浏览阅读763次。但是此时如果配置成 NONE, 租户创建成功了,但是无法创建资源文件,也就是无法上传文件,可能 dolphinscheduler 团队就想着将文件上传到 hdfs,暂不支持本地。需要将 resource.storage.type 置为 NONE, 因为我之前用的 1.3.6 版本的时候,即使资源文件存在本地文件也需要配置成 hdfs。_[error] 2023-10-24 18:10:43.762 +0800 org.apache.dolphinscheduler.api.servic
文章浏览阅读2.7k次,点赞2次,收藏13次。公司使用的是交老的k8s版本(1.16),由于老版本的K8s对于现在很多新特性不支持,所以需要升级到新版本。目前2023年7月11日最新版本的k8s是v1.27.3。通过参考官方文档进行k8s部署工作。其中涉及到操作系统配置、防火墙配置、私有镜像仓库等。_k8s最新版本
文章浏览阅读1.8w次,点赞14次,收藏27次。能节省你在kubeadm init 时遇到问题的排错时间⌚️。整合了网上大佬
文章浏览阅读1.1k次,点赞2次,收藏7次。具体操作步骤可以参考之前的教程,建议是先安装一台,然后克隆虚拟机,这样速度快。注意:在克隆时记得修改Mac地址、IP地址、UUID和主机名。(最后别忘了保存下快照~)_部署k8s集群
文章浏览阅读863次,点赞23次,收藏16次。当部署完 Kubernetes,便拥有了一个完整的集群。一组工作机器,称为节点, 会运行容器化应用程序。每个集群至少有一个工作节点。工作节点会 托管Pod ,而 Pod 就是作为应用负载的组件。控制平面管理集群中的工作节点和Pod。说人话版本:集群:cluster,多个几点被组织到一起共同为系统提供服务过程称之为集群。本质上是将承载同一个软件服务节点组织到一起,称之为该软件(服务)的集群,当然集群中的节点身份地位是不一样的。k8s集群也是如此,他也是多个节点组成。
文章浏览阅读943次。Rancher是一个开源的企业级多集群Kubernetes管理平台,实现了Kubernetes集群在混合云+本地数据中心的集中部署与管理,以确保集群的安全性,加速企业数字化转型。Rancher 1.0版本在2016年就已发布,时至今日,Rancher已经成长为企业在生产环境中运行容器和Kubernetes的首要选择。_rancher管理k8s
文章浏览阅读742次,点赞2次,收藏3次。本篇来讲解如何在centos下安装部署高可用k8s集群。_kubeadm ha keepalived + nginx
文章浏览阅读1.9k次,点赞21次,收藏25次。那么这个空间设置成内存的2倍大小。点击IPv4设置--手动--添加--设置ip--设置DNS服务器,最后点击--“保存”;首先选中--“本地标准磁盘”,存储配置--自定义分区,点击--“完成”;在--主机名--设置主机名:(例如k8s-master01),点击--点击+,设置--挂载点/boot--期望容量,点击--添加挂载点;点击--+--挂载点swap--期望容量,点击--“添加挂载点”;默认选择--亚洲--上海,并调整日期和时间,点击--“完成”;设备类型--确认--LVM,卷组--选择“修改”;_euler 服务器搭建
文章浏览阅读1k次。在1.25版本的k8s集群中部署gpu-manage时,虽然显示gpu节点上gpu-manage的pod实例都是running状态,但是给pod申领。既可以用源码的Makefile自动编译打包成新的镜像,但是源码的。说明gpu-manager和容器运行时接口通信失败了。编译后的镜像在1.25版本的k8s中可以正常使用。,但是在k8s1.23版本之后,接口路径已经改为。资源时,却始终找不到有资源的节点。,另外有一些依赖需要国际上的支持。可以看到这里用的运行时接口是。查看节点的详情时,返回的。_launch gpu manager 报错 can't create container runtime manager: context dead
文章浏览阅读1k次,点赞18次,收藏16次。SelfLink:API的资源对象之一,表示资源对象在集群当中自身的一个连结,self-Link是一个唯一的标识号,可以用于标识k8s集群当中的每个资源的对象。容器里使用的配置,在provisioner当中定义好环境变量,传给容器,storageclass的名称,NFS服务器的地址,NFS的目录。NFS的provisionner的客户端以pod的方式运行在集群当中,监听k8s集群当中PV的请求,然后动态的创建于NFS相关的PV。命名为 nfs-client-provisioner-clusterrole。
文章浏览阅读6.3k次,点赞2次,收藏20次。k8s证书过期解决方案之替换证书_k8s证书过期如何更换
文章浏览阅读1k次。KMS,Key Management Service,即密钥管理服务,在K8S集群中,以驱动和插件的形式启用对Secret,Configmap进行加密。以保护敏感数据
文章浏览阅读888次。exporter对于云服务的监控还是很不完美,毕竟每家都有自己的护城河。自动发现多实例这样的借助consul 阿波罗这样的会简单一些。aws可以借助cloudwatch这样的导入模板到grafana中。还是希望能将类似腾讯云云监控中的这些指标采集到prometheus中,但是这过程应该还很遥远grafana出图 prometheus查询语法这些东西有时间的好好研究一下。报警有必要进行分级别,收敛配置一下!_command: - "-redis.password-file=/redis_passwd.json
文章浏览阅读1k次。可以在此处(https://cloud.google.com/kubernetes-engine/docs/how-to/kube-dns)和此处(https://www.digitalocean.com/community/tutorials/an-introduction-to-the-kubernetes-dns-service)找到更多的详细信息。-or-ipvs/)和此处(https://arthurchiao.art/blog/cracking-k8s-node-proxy/)。_k8s默认命名空间
文章浏览阅读4.9k次,点赞11次,收藏32次。如果运行runc命令时提示:runc: error while loading shared libraries: libseccomp.so.2: cannot open shared object file: No such file or directory,则表明runc没有找到libseccomp,需要检查libseccomp是否安装,本次安装默认就可以查询到。所有主机均需要操作。所有主机均需要操作。所有主机均需要操作。所有主机均需要操作。所有主机均需要操作。所有主机均需要操作。_kubernetes 1.28
文章浏览阅读3.6w次,点赞118次,收藏144次。Canal 提供了网络功能,使得 Kubernetes 集群中的 Pod 可以相互通信,并与集群外部的服务进行通信。它通过网络插件的方式,为每个 Pod 分配唯一的 IP 地址,并管理网络流量的路由和转发。此外,Canal 还支持网络策略,用于定义 Pod 之间的通信规则和安全策略。Canal 基于 Calico 和 Flannel 项目,结合了二者的优点。它使用 Calico 的数据平面,提供高性能的网络转发和安全特性,同时使用 Flannel 的控制平面,实现 IP 地址管理和网络策略的配置。_k8s canal