K8S-pod进阶

标签：容器进阶 request Pod limit pod K8S CPU name

一.资源限制

当定义 Pod 时可以选择性地为每个容器设定所需要的资源数量。
最常见的可设定资源是 CPU 和内存大小，以及其他类型的资源。

当为 Pod 中的容器指定了 request 资源时，调度器就使用该信息来决定将 Pod 调度到哪个节点上。
当还为容器指定了 limit 资源时，kubelet 就会确保运行的容器不会使用超出所设的 limit 资源量。
kubelet 还会为容器预留所设的 request 资源量，供该容器使用。

小结：pod根据指定的request，通过预选和优选策略选择合适节点来进行pod的调度

如果 Pod 运行所在的节点具有足够的可用资源，容器可以使用超出所设置的 request 资源量。
不过，容器不可以使用超出所设置的 limit 资源量。

小结：request是预分配的资源，limit是上限资源；当节点的资源足够可以超出request设置的资源，但不能超过limit上限资源

如果给容器设置了内存的 limit 值，但未设置内存的 request 值，
Kubernetes 会自动为其设置与内存 limit 相匹配的 request 值。
类似的，如果给容器设置了 CPU 的 limit 值但未设置 CPU 的 request 值，
则 Kubernetes 自动为其设置 CPU 的 request 值并使之与 CPU 的 limit 值匹配。

小结：限制资源时只设置了request的值，没有设置limit值，那limit值将于设置的request值相匹配

1.1资源单位

①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

PS：在买硬盘的时候，操作系统报的数量要比产品标出或商家号称的小一些，主要原因是标出的是以 MB、GB为单位的，1GB 就是1,000,000,000Byte，而操作系统是以2进制为处理单位的，因此检查硬盘容量时是以MiB、GiB为单位，1GiB=2^30=1,073,741,824，相比较而言，1GiB要比1GB多出1,073,741,824-1,000,000,000=73,741,824Byte，所以检测实际结果要比标出的少一些。

1.2资源限制示例

二.健康检查【探针 Probe】

探针是由kubelet对容器执行的定期诊断。

2.1探针的三种规则

①livenessProbe

判断容器是否正在运行。
如果探测失败，则kubelet会杀死容器，并且容器将根据 restartPolicy 来设置 Pod 状态。
如果容器不提供存活探针，则默认状态为Success。

②readinessProbe

判断容器是否准备好接受请求。
如果探测失败，端点控制器将从与 Pod 匹配的所有 service endpoints 中剔除删除该Pod的IP地址。初始延迟之前的就绪状态默认为Failure。
如果容器不提供就绪探针，则默认状态为Success。

③startupProbe（这个1.17版本增加的）

判断容器内的应用程序是否已启动，主要针对于不能确定具体启动时间的应用。
如果配置了 startupProbe 探测，在则在 startupProbe 状态为 Success 之前，其他所有探针都处于无效状态，直到它成功后其他探针才起作用。
如果 startupProbe 失败，kubelet 将杀死容器，容器将根据 restartPolicy 来重启。如果容器没有配置 startupProbe，则默认状态为 Success。

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

2.2探针的三种检查方式

①exec

在容器内执行指定命令。
如果命令退出时返回码为0则认为诊断成功。

②tcpSocket

对指定端口上的容器的IP地址进行TCP检查（三次握手）。
如果端口打开，则诊断被认为是成功的。

③httpGet

对指定的端口和路径上的容器的IP地址执行HTTPGet请求。
如果响应的状态码大于等于200且小于400，则诊断被认为是成功的。

2.3探测获得的结果【三种】

①成功

容器通过了诊断。

②失败

容器未通过诊断。

③未知

诊断失败，因此不会采取任何行动

2.4检查方法示例

①exec方式

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
  - name: liveness
    images: k8s.gcr.io/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

②tcpSocket方式

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

③httpGet方式

apiVersion: v1
kind: Pod
metadata:
  name: goproxy
  labels:
    app: goproxy
spec:
  containers:
  - name: goproxy
    images: k8s.gcr.io/goproxy:0.1
    ports:
    - containerPort: 8080
    readinessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10
    livenessProbe:
      tcpSocket:
        port: 8080
      initalDelaySeconds: 15
      periodSeconds: 20

2.5启动和退出动作

①启动

spec.containers.lifecycle.postStart：配置exec.command字段设置Linux命令，实现当应用容器启动时，会执行的额外操作

②退出

spec.containers.lifecycle.preStop：配置exec.command字段设置 Linux命令，实现当应用容器退出时，会执行的最后一个操作

apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo
spec:
  containers:
  - name: lifecycle-demo-container
    image: soscscs/myapp:v1
    lifecycle:  #此为关键字段
      postStart:
        exec:
          command: ["/bin/sh", "-c", "echo hello from the postStart handler >> /var/log/nginx/message"]
      preStop:
        exec:
          command: ["/bin/sh", "-c", "echo hello from the preStop handler >> /var/log/nginx/message"]
    volumeMounts:
    - name: message-log
      mountPath: /var/log/nginx/
      readOnly: false
  initContainers:
  - name: init-myservice
    image: soscscs/myapp:v1
    command: [ "/bin/sh","-c" , "echo 'Hello initContainers' >>/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容器镜像拉取策略【imagepullpolicy】三种容器

① ifNotpresent：优先使用本地已存在的镜像，如本地没有则从仓库拉取镜像

② Always：总是从仓库拉取镜像，无论本地是否一存在镜像

③ Never：总是补充仓库拉取镜像，仅使用本地镜像

镜像重启策略

① always：当容器终止退出后，总是重启容器，默认策略

② ONFailure：当容器异常退出时【退出状态码非0】时，重启容器：正常退出不重启容器

③ Never：当容器终止退出，从不重启容器

pod容器探针三种

① 存活探针：判断容器是否运行正常，如果探测失败则杀掉容器【不是pod】，容器会根据重启策略是否重启

② 就绪探针：判断pod是否能进入ready状态，做好接受请求的准备；探测失败会进入notready状态并从service资源的endpoint中剔除，service将不会把请求转发给这个pod

③ 启动探针：判断容器内的应用是否启动成功，在探测成功状态为success之前，其他探针都会处于失效状态

三种探测方式

① exec：通过command设置执行在容器内执行的命令来进行探测，如果返回码为0，则认为探测成功

② httpget：通过http get 请求访问指定的容器端口和url路径，如果假设返回状态码为大于等于200且小于400，则认为探测成功

③ tcpsocket：通过指定的端口发送tcp连接，如果端口无误且三次握手过程（tcp连接成功），测认为探测成功

标签：容器,进阶,request,Pod,limit,pod,K8S,CPU,name
From： https://www.cnblogs.com/suoluo212/p/17141010.html