资源限制

• 当定义 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/

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

• 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 毫秒。
  • Kubernetes 不允许设置精度小于 1m 的 CPU 资源。
• 内存 资源单位
  • 内存的 request 和 limit 以字节为单位。
  • 可以以整数表示，或者以10为底数的指数的单位（E、P、T、G、M、K）来表示， 或者以2为底数的指数的单位（Ei、Pi、Ti、Gi、Mi、Ki）来表示。
  • 如：1KB=10^{3=1000，1MB=10}6=1000000=1000KB，1GB=10^9=1000000000=1000MB
  • 1KiB=2^{10=1024，1MiB=2}20=1048576=1024KiB

apiVersion: v1
kind: Pod
metadata:
  labels:
  name: test01
spec:
  containers:
  - name: test01
    image: nginx:1.14
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

  restartPolicy: Always

###查看创建的pods
kubectl get pods

##查看pod的详细信息
kubectl describe pod test01

##根据创建的pod所在的node节点，查看node 的详细信息
kubectl describe nodes node02

##实时监控pod的创建过程
kubectl get pods -o wide -w

探针（健康检查）

• 探针的三种规则：

  • livenessProbe ：判断容器是否正在运行。如果探测失败，则kubelet会杀死容器，并且容器将根据 restartPolicy 来设置 Pod 状态。 如果容器不提供存活探针，则默认状态为Success。
  • readinessProbe ：判断容器是否准备好接受请求。如果探测失败，端点控制器将从与 Pod 匹配的所有 service endpoints 中剔除删除该Pod的IP地址。 初始延迟之前的就绪状态默认为Failure。如果容器不提供就绪探针，则默认状态为Success。
  • startupProbe（这个1.17版本增加的）：判断容器内的应用程序是否已启动，主要针对于不能确定具体启动时间的应用。如果配置了 startupProbe 探测，则在 startupProbe 状态为 Success 之前，其他所有探针都处于无效状态，直到它成功后其他探针才起作用。 如果 startupProbe 失败，kubelet 将杀死容器，容器将根据 restartPolicy 来重启。如果容器没有配置 startupProbe， 则默认状态为 Success。

• Probe支持三种检查方法：

  • exec ：在容器内执行指定命令。如果命令退出时返回码为0则认为诊断成功。
  • tcpSocket ：对指定端口上的容器的IP地址进行TCP检查（三次握手）。如果端口打开，则诊断被认为是成功的。
  • httpGet ：对指定的端口和uri路径上的容器的IP地址执行HTTPGet请求。如果响应的状态码大于等于200且小于400，则诊断被认为是成功的

• 每次探测都将获得以下三种结果之一：

  • 成功（Success）：表示容器通过了检测。
  • 失败（Failure）：表示容器未通过检测。
  • 未知（Unknown）：表示检测没有正常进行。

• 官网示例：
  https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

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
      failureThreshold: 1
      initialDelaySeconds: 5
      periodSeconds: 5
  restartPolicy: Never

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

apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: test01
  name: test01
spec:
  replicas: 2
  selector:
    matchLabels:
      app: test01
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: test01
    spec:
      containers:
      - image: nginx
        name: nginx
        ports:
        - containerPort: 80
        readinessProbe:
          httpGet:
            port: 80
            path: /index.html
          initialDelaySeconds: 5
          periodSeconds: 5
          timeoutSeconds: 10

##创建pod容器和service资源
kubectl create deployment test01 --image=nginx --port=80 --replicas=2

kubectl expose deployment test01 --name=evc-test01 --port=8080 --target-port=80 --type=NodePort

apiVersion: v1
kind: Pod
metadata:
  name: http
  namespace: default
spec:
  containers:
  - name: http
    image: nginx
    imagePullPolicy: IfNotPresent
    ports:
    - name: http
      containerPort: 80
    readinessProbe:
      httpGet:
        port: 80
        path: /index.html
      initialDelaySeconds: 1
      periodSeconds: 3
    livenessProbe:
      httpGet:
        port: http
        path: /index1.html
      initialDelaySeconds: 1
      periodSeconds: 3
      timeoutSeconds: 10
    startupProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 1
      periodSeconds: 3

启动、退出动作

apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo
spec:
  containers:
  - name: lifecycle-demo-container
    image: nginx
    lifecycle:   
      postStart:
        exec:
          command: ["/bin/sh", "-c", "echo 123 >> /var/log/nginx/message"]      
      preStop:
        exec:
          command: ["/bin/sh", "-c", "echo 456 >> /var/log/nginx/message"]
    volumeMounts:
    - name: message-log
      mountPath: /var/log/nginx/
      readOnly: false
  initContainers:
  - name: init-myservice
    image: nginx
    command: ["/bin/sh", "-c", "echo '789'   >> /var/log/nginx/message"]
    volumeMounts:
    - name: message-log
      mountPath: /var/log/nginx/
      readOnly: false
  volumes:
  - name: message-log
    hostPath:
      path: /data/volumes/nginx/log/
      type: DirectoryOrCreate

总结

• Pod 容器的 3 种探针（健康检查）
  • 存活探针（livenessProbe）：探测是否正常运行。如果探测失败则kubelet杀掉容器（Pod容器会根据重启策略决定是否重启）
  • 就绪探针（readinessProbe）：探测Pod是否进入就绪状态（ready状态栏1/1），并做好接收service请求的准备。如果探测失败则Pod会变成未就绪状态（ready状态栏0/1），service资源会删除所关联的端点（endpoints），并不再转发请求给就绪探测失败的Pod
  • 启动探针（startupProbe）：探测容器内的应用是否启动成功。在启动探针探测成功之前，存活探针和就绪探针都会暂时处于禁用状态，直到启动探针探测成功
• 探针的 3 种探测方式：
  • exec：在command字段中指定在容器内执行的Linux命令来进行探测，如果命令返回码为0则认为探测成功，如果返回码为非0则认为探测失败
  • tcpSocket：向指定的Pod容器端口发送tcp连接请求，如果端口正确且tcp连接成功则认为探测成功，如果tcp连接失败则认为探测失败
  • httpGet：向指定的Pod容器端口和URL路径发送http get请求，如果http响应状态码为2XX 3XX则认为探测成功，如果响应状态码为4XX 5XX则认为探测失败
• 探针参数：
  • initialDelaySeconds：指定容器启动后延迟几秒开始探测
  • periodSeconds：每天探测的间隔时间（秒数）
  • failureThreshold：探测连续失败几次后判断探测失败
  • timeoutSeconds：指定探测超时等待时间（秒数）
• Pod 应用容器生命周期的启动动作和退出动作
  • spec.containers.lifecycle.postStart 配置子字段 exec.command 设置 Pod 容器启动时额外的命令操作
    请求，如果http响应状态码为2XX 3XX则认为探测成功，如果响应状态码为4XX 5XX则认为探测失败
• 探针参数：
  • initialDelaySeconds：指定容器启动后延迟几秒开始探测
  • periodSeconds：每天探测的间隔时间（秒数）
  • failureThreshold：探测连续失败几次后判断探测失败
  • timeoutSeconds：指定探测超时等待时间（秒数）
• Pod 应用容器生命周期的启动动作和退出动作
  • spec.containers.lifecycle.postStart 配置子字段 exec.command 设置 Pod 容器启动时额外的命令操作
  • spec.containers.lifecycle.preStop 配置子字段 exec.command 设置 Pod 容器运行中被kubelet杀掉退出时所执行的命令操作（不包含容器自行退出的情况）