【云原生--Kubernetes】Pod资源管理与探针检测

一. 资源限制

1.1 概念

• 当定义 Pod 时可以选择性地为每个容器设定所需要的资源数量。最常见可设定资源是 CPU 和内存大小，以及其他类型的资源
• 当为 Pod 中的容器指定了 request资源时，调度器就使用该信息来决定将 Pod 调度到哪个节点上。当还为容器指定了limit资源时，kubelet 就会确保运行的容器不会使用超出所设的 limit 资源量。kubelet 还会为容器预留所设的 request 资源量，供该容器使用
• 如果 Pod 运行所在的节点具有足够的可用资源，容器可以使用超出所设置的 request 资源量。不过，容器不可以使用超出所设置的 limit 资源量
• 如果给容器设置了内存的 limit 值，但未设置内存的 request 值，Kubernetes 会自动为其设置与内存 limit 相匹配的 request值。类似的，如果给容器设置了 CPU 的 limit 值但未设置CPU 的 request 值，则 Kubernetes 自动为其设置 CPU 的 request 值 并使之与CPU 的 limit 值匹配
  官方示例
  https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/

1.2 Pod和容器的资源请求和限制

spec.containers[].resources. requests.cpu #定义创建容器时预分配的CPU资源
spec.containers[].resources.requests.memory #定义创建容器时预分配的内存资源
spec.containers[].resources.limits.cpu #定义 cpu 的资源上限
spec.containers[].resources.limits.memory #定义内存的资源上限

1.3 CPU资源单位

• CPU 资源的 request 和 limit 以 cpu 为单位。Kubernetes 中的一个 cpu 相当于1个 vCPU（1个超线程）
• Kubernetes 也支持带小数 CPU 的请求。spec.containers[].resources.requests.cpu 为0.5的容器能够获得一个 cpu 的一半 CPU资源（类似于Cgroup对CPU资源的时间分片）。表达式0.1等价于表达式 100m（毫核），表示每1000毫秒内容器可以使用的CPU时间总量为0.1*1000 毫秒

1.4 内存资源单位

• 内存的 request 和 limit 以字节为单位。 可以以整数表示，或者以10为底数的指数的单位（E、P、T、G、M、K）来表示，或者以2为底数的指数的单位（Ei、Pi、Ti、Gi、Mi、Ki）来表示。如1KB=103=1000，1MB=106=1000000=1000KB，1GB=10^9=1000000000=1000MB 1KiB=2^10=1024, 1MiB=2^20=1048576=1024KiB
• PS∶在买硬盘的时候，操作系统报的数量要比产品标出或商家号称的小一些，主要原因是标出的是以 MB、GB为单位的，1GB就是1,000,000,000Byte，而操作系统是以2进制为处理单位的，，因此检查硬盘容量时是以MiB、GiB为单位，1GB=2^30=1,073,741,824，相比较而言，1GiB要比1GB多出1,073,741,824-1,000,000,000=73,741,824Byte，所以检测实际结果要比标出的少—些

1.5 CPU和内存的Requests和Limits的特点

• Requests和Limits都是可选的。在Pod创建和更新时，如果未设置Requests和Limits，则使用系统提供的默认值，该默认值取决于集群配置。
• 如果Requests没有配置，默认被设置等于Limits。
• requests 是创建容器时需要预留的资源量。如果无法满足，则pod 无法调度。但是，这不是容器运行实际使用的资源，容器实际运行使用的资源可能比这个大，也可能比这个小。
• Limit 是限制pod容器可以使用资源的上限。容器使用的资源无法高于这个限制任何情况下Limits都应该设置为大于或等于Requests。

1.6 示例

vim demo1.yaml

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: web
    image: nginx
    env:
    - name: WEB_ROOT_PASSWORD
      value: "password"
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
  - name: db
    image: mysql
    env:
    - name: MYSQL_ROOT_PASSWORD
      value: "abc123"
    resources:
      requests:
        memory: "512Mi"
        cpu: "0.5"
      limits:
        memory: "1Gi"
        cpu: "1"

#发布
kubectl apply -f demo1.yaml 
#查看pod信息
kubectl get pod
kubectl describe pod frontend 

#查看pod详细信息，查询pod所在节点
kubectl  get pod -o wide 

#查看节点信息
kubectl  describe nodes k8s-node1

二. 探针Probe

健康检查，又名 探针（Probe）：探针是由kubelet对容器执行定期诊断。

2.1 探针规则

• StartupProbe（启动探针1.17版本新增）：判断容器内的应用程序是否已经启动，主要针对于不能确定具体启动时间应用。如果配置了startupProbe探测，则在startupProbe状态为success 之前，其他所有探针都处于无效状态，直到它成功后其他探针才起作用。如果startupProbe失败，kubelet将杀死容器，容器将根据restartPolicy来重启。如果容器没有配置startupProbe，则默认状态为Success。
• 存活性探测，判断pod是否需要重启。
  LivenessProbe（存活性探针）：判断容器是否正在运行。如果探测失败，则kubectl 会杀死容器，并且容器将根据 restartPolicy 来设置 Pod 状态。如果容器不提供存活探针，则默认状态为Success。
• 就绪性探测，判断pod是否能够提供正常服务
  ReadinessProbe（就绪性探针）：一般用于探测容器内的程序是否健康，它的返回值如果为success，那么就代表这个容器已经完成启动，并且程序已经是可以接受流量的状态。

注：以上规则可以同时定义。在readinessProbe检测成功之前，Pod的running状态是不会变成ready状态。

startupProbe、livenessProbe、ReadinessProbe之间的区别：
startupProbe: pod只检测一次，剩下的两种只要你的pod存在就会一直去检测
livenessProbe、ReadinessProbe：建议使用接口级的健康检查

2.2 Probe支持的三种检查方法

• Exec：在容器内执行一个命令，如果返回值为0，则认为容器健康。

• TCPSocket：通过TCP连接检查容器内的端口是否是通的，如果是通的就认为容器健康。

• HTTPGet：通过应用程序暴露的API地址来检查程序是否是正常的，如果状态码为200~400之间，则认为容器健康。

2.3 探测获得的三种结果

每次探测，都将会获得以下三种结果之一:

• 成功： 容器通过了诊断
• 失败： 容器未通过诊断
• 未知：诊断失败，因此不会采取任何行动

2.4 exec

vim exec.yaml
 
apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness				#为了健康检查定义的标签
  name: liveness-exec
spec:						#定义了Pod中containers的属性
  containers:
  - name: liveness
    image: busybox
    args:						#传入的命令
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy;sleep 600
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5			#表示pod中容器启动成功后，多少秒后进行健康检查 
      periodSeconds: 5				#在首次健康检查后，下一次健康检查的间隔时间 5s

探针可选的参数:

• initialDelaySeconds∶指定 kubelet 在执行第一次探测前应该等待5秒，即第一次探测是在容器启动后的第6秒才开始执行。默认是 0 秒，最小值是 0。
• periodSeconds∶指定了 kubelet 应该每 5 秒执行一次存活探测。默认是 10 秒。最小值是 1。
  -== failureThreshold==∶当探测失败时，Kubernetes 将在放弃之前重试的次数。存活探测情况下的放弃就意味着重新启动容器。就绪探测情况下的放弃 Pod 会被打上未就绪的标签。默认值是 3。最小值是 1。
• timeoutSeconds∶探测超时后等待多少秒。默认值是 1 秒。最小值是 1。（在 Kubernetes 1.20 版本之前，exec 探针会忽略timeoutSeconds 探针会无限期地持续运行，甚至可能超过所配置的限期，直到返回结果为止。）
  在这个配置文件中，可以看到 Pod 中只有一个容器。
• periodSeconds 字段指定了 kubelet 应该每 5 秒执行一次存活探测。
• initialDelaySeconds 字段告诉 kubelet 在执行第一次探测前应该等待 5 秒。

kubelet 在容器内执行命令 cat /tmp/healthy 来进行探测。 如果命令执行成功并且返回值为 0，kubelet 就会认为这个容器是健康存活的。 如果这个命令返回非 0 值，kubelet 会杀死这个容器并重新启动它。

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;sleep 60
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5

#创建pod
kubectl create  -f exec.yaml 
#跟踪查看pod 信息
kubectl get pod  -o wide -w
#查看pod 的消息信息
kubectl describe pod liveness-exec 

2.5 httpget

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - name: liveness
    image: k8s.gcr.io/liveness
    args:
    - /server
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
        httpHeaders:
        - name: Custom-Header
          value: Awesome
      initialDelaySeconds: 3
      periodSeconds: 3

在配置文件中，可以看到Pod具有单个Container。该periodSeconds字段指定kubectl应该每3秒执行一次活动性探测。该initiaDelaySeconds字段告诉kubelet在执行第一个探测之前应等待3秒。为了执行探测，kubectl将HTTP GET请求发送到Container中运行并在端口8080上侦听的服务器。如果服务器/healthz路径的处理程序返回成功代码，则kubectl会认为任何大于或等于400的代码均表示成功，其他代码都表示失败。

#加载yaml文件
kubectl create -f http.yaml                                      
#查看pod的详细参数
kubectl get pod -o wide -w
kubectl describe pod liveness-httpget       

2.6 tcpsocket

定义TCP活动度探针

第三种类型的活动性探针使用TCP套接字，使用此配置，kubelet将尝试在指定端口上打开容器的套接字。如果可以建立连接，则认为该让其运行状况良好，如果不能，则认为该容器是故障容器。

apiVersion: v1
kind: Pod
metadata:
  name: probe-tcp
spec:
  containers:
  - name: nginx
    image: soscscs/myapp:v1
    livenessProbe:
      initialDelaySeconds: 5
      timeoutSeconds: 1
      tcpSocket:
        port: 8080
      periodSeconds: 3

如你所见，TCP 检测的配置和 HTTP 检测非常相似。 下面这个例子同时使用就绪(readinessProbe)和存活(livenessProbe)探测器。

kubelet 会在容器启动 5 秒后发送第一个就绪探测。 这会尝试连接 goproxy 容器的 8080 端口。 如果探测成功，这个 Pod 会被标记为就绪状态，kubelet 将继续每隔 10 秒运行一次检测。

除了就绪探测，这个配置包括了一个存活探测。 kubelet 会在容器启动 15 秒后进行第一次存活探测。 与就绪探测类似，会尝试连接 goproxy 容器的 8080 端口。 如果存活探测失败，这个容器会被重新启动

编写yaml文件

kubectl  create  -f tcp.yaml
#查看pod的状态和详细信息
kubectl  get pods -o wide -w
kubectl describe pod liveness-httpget

如图所示，TCP检查的配置与HTTP检查非常相似，此示例同时使用就绪和活跃度探针，容器启动5秒后，kubelet将发送第一个就绪探测器。这些尝试连接到goproxy端口8080上的容器。如果探测成功，则容器将标记为就绪，kubelet将继续每10秒运行一次检查。

除了就绪探针之外，此配置还包括活动探针。容器启动后15秒钟，kubelet将运行第一个活动谈着，就像就绪探针一样，这些尝试goproxy在端口8080上连接到容器。如果活动探针失败，则容器将重新启动。

三. 总结

探针（3 种）
1.livenessProbe（存活探针）∶判断容器是否正常运行，如果失败则杀掉容器（不是pod），再根据重启策略是否重启容器
2.readinessProbe（就绪探针）∶判断容器是否能够进入ready状态，探针失败则进入noready状态，并从service的endpoints中剔除此容器
3.startupProbe∶判断容器内的应用是否启动成功，在success状态前，其它探针都处于无效状态

检查方式（3种）
1.exec∶使用 command 字段设置命令，在容器中执行此命令，如果命令返回状态码为0，则认为探测成功
2.httpget∶通过访问指定端口和url路径执行http get访问。如果返回的http状态码为大于等于200且小于400则认为成功
3.tcpsocket∶通过tcp连接pod（IP）和指定端口，如果端口无误且tcp连接成功，则认为探测成功

探针可选的参数
1.initialDelaySeconds∶ 容器启动多少秒后开始执行探测
2.periodSeconds∶探测的周期频率，每多少秒执行一次探测
3.failureThreshold∶探测失败后，允许再试几次
4.timeoutSeconds ∶ 探测等待超时的时间