认识k8s中资源申请和探针

最新推荐文章于 2024-04-27 17:04:16 发布

taoli-qiao

最新推荐文章于 2024-04-27 17:04:16 发布

阅读量448

点赞数

分类专栏：云原生文章标签： kubernetes

本文链接：https://blog.csdn.net/qiaotl/article/details/125737871

版权

云原生专栏收录该内容

34 篇文章 12 订阅

订阅专栏

在定义pod的部署文件时，还会对所需的资源量进行设置，保证pod的高可用。例如对于一些很重要的pod，不希望这个pod因为集群资源紧张而被驱逐，那么pod的资源设置最好设置成request和limit的值相同。如果按Pod的QoS(Quality of Service)进行分类，那么可以分为三类。
第一类：Guaranteed：pod的每个容器设置的资源需求(CPU/内存)的limits和request的值完全一样。
第二类：Burstable：只要一个容器指定了CPU或者内存的request，requests的limits的值不一样。
第三类：BestEffort：Pod中所有容器都未指定CPU或内存资源需求的requests。
当计算节点检测到内存压力时，Kubernetes会按BestEffort>Burstable>Guaranteed的顺序依次进行驱逐。在实际项目中对于重要的Pod，建议定义Guaranteed来保护重要的pod，对于大多数应用建议采用Burstable的类型，合理评估Pod所需资源后来设置Limit和request的值。下面是pod的yaml文件中定义requests和limits的例子。

对于启动后的pod也可以通过查看yaml文件获取Qos的类型，kubectl get pod podName -oyaml

在Pod部署定义的yaml文件中，除了对资源需求进行定义外，还会定义各种类型的探测器，例如存活探测器用来对启动的pod进行持续的健康检查，接下来就看看具体的探针类型和使用。探测器分为活跃（Liveness）、就绪（Readiness）和启动（Startup）探测器。kubelet使用存活探测器来确定什么时候要重启容器，例如，存活探测器可以探测到应用死锁（应用程序在运行，但是无法继续执行后面的步骤）情况。重启这种状态下的容器有助于提高应用的可用性。kubelet 使用就绪探测器可以知道容器何时准备好接受请求流量，当一个 Pod 内的所有容器都就绪时，才能认为该 Pod 就绪。这种信号的一个用途就是控制哪个 Pod 作为 Service 的后端。若 Pod 尚未就绪，会被从 Service 的负载均衡器中剔除。kubelet 使用启动探测器来了解应用容器何时启动。如果配置了这类探测器，你就可以控制容器在启动成功后再进行存活性和就绪态检查，确保这些存活、就绪探测器不会影响应用的启动。启动探测器可以用于对慢启动容器进行存活性检测，避免它们在启动运行之前就被杀掉。

接下来就定义一个存活探测器，具体yaml文件内容如下所示,可以看到pod启动一段时间后会重启，通过describe命令查看，可以看到是因为存活探测器失败，所以会启动kill pod的动作。

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: k8s.gcr.io/busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5

除了通过shell命令设置liveness prob外，还可以定义httpget的liveness prob，yaml文件内容如下所示，这个liveness prob是访问pod的8080/healthz接口来检测pod的健康状态。

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

除了HttpGet方式，还有TCP方式和gRPC方式，详细信息可以查看官网的文档。

除了定义livenessProbe外，对于有些启动比较耗时的pod，还可以定义startupProbe，防止pod在启动过程中被kill掉，具体yaml例子如下所示，在pod启动过程中，会通过startupProbe探测pod何时真正成功启动了，如果startupProbe成功一次，那么探测活动会被LivenessProbe接管，如果startupProbe一直不成功，那么会在30*10=300s=5minutes时间后kill掉pod里面的容器，然后根据restartPolicy来做下一步操作。

ports:
- name: liveness-port
  containerPort: 8080
  hostPort: 8080

livenessProbe:
  httpGet:
    path: /healthz
    port: liveness-port
  failureThreshold: 1
  periodSeconds: 10

startupProbe:
  httpGet:
    path: /healthz
    port: liveness-port
  failureThreshold: 30
  periodSeconds: 10

上面介绍了探测器，接下来再看看pod的优雅启动和优雅终止。你可能会遇到需要Kubernetes 仅在满足条件时启动 Pod 的情况，例如依赖项正在运行或sidecar 容器已准备就绪。同样，你可能希望在 Kubernetes 终止 pod 之前执行命令，以释放正在使用的资源并优雅地终止应用程序。kubernetes主要通过post-start和pre-stop两类hook来完成优雅启动和终止。下图是post-start和pre-stop两类hook的主要特性。

下面这个例子定义了post-start和pre-stop，创建该pod后，进入pod，查看/bin/sh目录，可以看到打印了具体的信息。

apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo
spec:
  containers:
  - name: lifecycle-demo-container
    image: nginx
    lifecycle:
      postStart:
        exec:
          command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"]
      preStop:
        exec:
          command: ["/bin/sh","-c","nginx -s quit; while killall -0 nginx; do sleep 1; done"]