Linux----K8s的Pod资源管理限制与健康检查的两种规则

资源限制官方网站https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/为什么要对pod资源做限制？在 Kubernetes 体系中，资源默认是被多租户共享使用的，租户间不可避免地存在资源竞争问题。为了满足不同租户多样的服务质量需求，集群管理员需要为租户设置非常精细的资源配额以及资源限

稚与最初丶

530人浏览 · 2020-05-16 17:02:12

稚与最初丶 · 2020-05-16 17:02:12 发布

资源限制

官方网站

https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/

为什么要对pod资源做限制？

在 Kubernetes 体系中，资源默认是被多租户共享使用的，租户间不可避免地存在资源竞争问题。
为了满足不同租户多样的服务质量需求，集群管理员需要为租户设置非常精细的资源配额以及资源限制

在 Container 级别可以对两种计算资源进行管理：CPU 和内存。ResourceRequests 表示容器希望被分配到的可完全保证的资源量，Requests 的值会被提供给 Kubernetes 调度器，以便优化基于资源请求的容器调度；ResourceLimits 表示容器能用的资源上限，这个上限的值会影响在节点上发生资源竞争时的解决策略。

Pod和Container的资源请求和限制：

spec.containers[].resources.limits.cpu //cpu上限

spec.containers[].resources.limits.memory //内存上限

spec.containers[].resources.requests.cpu //创建时分配的基本CPU资源

spec.containers[].resources.requests.memory //创建时分配的基本内存资源

操作演示，对新创建pod的cpu和内存做限制

编辑yaml文件，创建pod资源
[root@localhost demo]# vim pod2.yaml
apiVersion: v1
kind: Pod
metadata:
  name: frontend            #pod名称
spec:
  containers:
  - name: db                #容器1名称
    image: mysql            #使用mysql镜像
    env:
    - name: MYSQL_ROOT_PASSWORD
      value: "password"
    resources:
      requests:
        memory: "64Mi"      #基本内存资源
        cpu: "250m"         #基本CPU资源
      limits:
        memory: "128Mi"     #内存最大限制
        cpu: "500m"         #CPU最大限制
  - name: wp                #容器2名称
    image: wordpress
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

查看创建信息

创建
[root@localhost demo]# kubectl apply -f pod2.yaml 
pod/frontend created

查看信息
[root@localhost demo]# kubectl get pods -w
NAME       READY   STATUS              RESTARTS   AGE
frontend   0/2     ContainerCreating   0          6s

[root@localhost demo]# kubectl get pods
NAME       READY   STATUS      RESTARTS   AGE
frontend   1/2     OOMKilled   2          11m

查看下载信息

查看创建的pod分配的节点信息
[root@localhost demo]# kubectl describe pod frontend
......
 Normal   Pulling    4m44s                kubelet, 192.168.179.152  pulling image "wordpress"
  Normal   Created    102s                 kubelet, 192.168.179.152  Created container
  Normal   Started    102s                 kubelet, 192.168.179.152  Started container
  Normal   Pulled     102s                 kubelet, 192.168.179.152  Successfully pulled image "wordpress"
  Normal   Pulling    24s (x4 over 12m)    kubelet, 192.168.179.152  pulling image "mysql"
  Normal   Created    21s (x4 over 4m45s)  kubelet, 192.168.179.152  Created container
  Normal   Started    21s (x4 over 4m44s)  kubelet, 192.168.179.152  Started container
  Normal   Pulled     21s (x4 over 4m45s)  kubelet, 192.168.179.152  Successfully pulled image "mysql"
  Warning  BackOff    13s (x4 over 86s)    kubelet, 192.168.179.152  Back-off restarting failed container

根据分配的节点查看限制信息

查看命名空间

[root@localhost demo]# kubectl get ns
NAME          STATUS   AGE
default       Active   16d
kube-public   Active   16d
kube-system   Active   16d

重启策略

Pod 的重启策略有 3 种，默认值为 Always。

Always ：容器失效时，kubelet 自动重启该容器；
OnFailure ：容器终止运行且退出码不为0时重启；
Never ：不论状态为何， kubelet 都不重启该容器。

失败的容器由 kubelet 以五分钟为上限的指数退避延迟（10秒，20秒，40秒…）重新启动，并在成功执行十分钟后重置。

查看创建的pod资源时，不知道重启策略

[root@localhost demo]# kubectl edit pod/foo

操作演示，OnFailure策略

创建新pod
[root@localhost demo]# vim pod3.yaml
apiVersion: v1
kind: Pod
metadata:
  name: foo
spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - /bin/sh
    - -c
    - sleep 30; exit 3    #进入容器，等待30秒，异常退出

[root@localhost demo]# kubectl apply -f pod3.yaml
pod/foo created


查看重启次数
[root@localhost demo]# kubectl get pods
NAME    READY   STATUS    RESTARTS   AGE
foo     1/1     Running   1          77s        #1次
mypod   1/1     Running   2          3d4h

[root@localhost demo]# kubectl get pods
NAME    READY   STATUS    RESTARTS   AGE
foo     1/1     Running   2          105s        #2次
[root@localhost demo]# kubectl get pods
NAME    READY   STATUS    RESTARTS   AGE
foo     0/1     Error     2          2m15s        #报错

操作演示，Never策略

vim pod3.yaml
apiVersion: v1
kind: Pod
metadata:
  name: foo
spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - /bin/sh
    - -c
    - sleep 10
  restartPolicy: Never

删除原有的资源
[root@localhost demo]# kubectl delete -f pod3.yaml 
pod "foo" deleted
[root@localhost demo]# kubectl get pods
NAME    READY   STATUS    RESTARTS   AGE
mypod   1/1     Running   2          3d4h
[root@localhost demo]# 

创建新的pod资源
[root@localhost demo]# kubectl apply -f pod3.yaml 
pod/foo created

查看状态
[root@localhost demo]# kubectl get pods
NAME    READY   STATUS      RESTARTS   AGE
foo     0/1     Completed   0          20s        #不会进行重启，直接关闭容器
mypod   1/1     Running     2          3d4h

健康检查，又称为探针（Probe）

两种规则，可以同时使用

livenessProbe：如果检查失败，将杀死容器，根据Pod的restartPolicy来操作。

ReadinessProbe：如果检查失败，kubernetes会把Pod从service endpoints中剔除。

Probe支持三种检查方法：

httpGet 发送http请求，返回200-400范围状态码为成功。
exec 执行Shell命令返回状态码是0为成功，非0值认定为不健康状态。
tcpSocket 发起TCP Socket建立成功。

操作演示

使用livenessProbe规则，通过exec的检查方法演示

[root@localhost demo]# vim pod4.yaml

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy    #通过这个方法检查
    livenessProbe:	    #使用的规则		
      exec:                 #检查方法为exec
        command:
        - cat               
        - /tmp/healthy
      initialDelaySeconds: 5        #容器创建完成5秒后，开始检查
      periodSeconds: 5              #检查的间隔频率

通过先创建一个文件，关联到exec检查方法，当30秒之后返回的状态码为非0时，通过livenessProbe规则，触发容器的重启策略，对容器进行重启操作

验证，该容器30秒后是否反复重启

创建该pod资源
[root@localhost demo]# kubectl apply -f pod4.yaml 
pod/liveness-exec created

[root@localhost demo]# kubectl get pods 
NAME            READY   STATUS      RESTARTS   AGE
foo             0/1     Completed   0          24m
liveness-exec   1/1     Running     0          19s        #正常运行状态

30秒后查看
[root@localhost demo]# kubectl get pods 
NAME            READY   STATUS             RESTARTS   AGE
foo             0/1     Completed          0          25m
liveness-exec   0/1     CrashLoopBackOff   1          74s    #重启

[root@localhost demo]# kubectl get pods 
NAME            READY   STATUS      RESTARTS   AGE
foo             0/1     Completed   0          26m
liveness-exec   1/1     Running     2          108s           #运行状态

[root@localhost demo]# kubectl get pods 
NAME            READY   STATUS             RESTARTS   AGE
foo             0/1     Completed          0          26m
liveness-exec   0/1     CrashLoopBackOff   2          2m16s    #重启

注意：观察重启次数

[root@localhost demo]# kubectl get pods 
NAME            READY   STATUS      RESTARTS   AGE
foo             0/1     Completed   0          28m
liveness-exec   1/1     Running     4          3m32s

反复进行健康检查，根据重启策略进行重启

K8S/Kubernetes

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐

【深度】阿里巴巴万级规模 K8s 集群全局高可用体系之美

作者 | 韩堂、柘远、沉醉来源 | 阿里巴巴云原生公众号前言台湾作家林清玄在接受记者采访的时候，如此评价自己 30 多年写作生涯：“第一个十年我才华横溢，‘贼光闪现’，令周边黯然失色；第二个十年，我终于‘宝光现形’，不再去抢风头，反而与身边的美丽相得益彰；进入第三个十年，繁华落尽见真醇，我进入了‘醇光初现’的阶段，真正体味到了境界之美”。长夜有穷，真水无香。领略过了 K8s“身在江

K8S/Kubernetes

如何基于 K8s 构建下一代 DevOps 平台？

作者 | 孙健波（天元）导读：当前云原生 DevOps 体系现状如何？面临哪些挑战？如何通过 OAM 解决云原生 DevOps 场景下的诸多问题？云原生开发应用模型 OAM(Open Application Model) 社区核心成员孙健波将为大家一一解答，并分享如何基于 OAM 和 Kubernetes 打造无限能力的下一代 DevOps 平台。什么是 DevOps？为什么基于 Kub