（二）k8s实战-深入Pod详解-Toy模板网

这篇具有很好参考价值的文章主要介绍了（二）k8s实战-深入Pod详解。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

一、配置文件详解

创建Pod nginx样例

apiVersion: v1 # api文档版本
kind: Pod # 资源对象类型，Pod, Deployment,StatefulSet
metadata: # Pod相关的元数据，用于描述Pod的数据
  name: nginx-demo # Pod的名称
  labels: # 定义Pod的标签
    type: app # 自定义lable标签，名称为tyoe，值为app
    test: 1.0.0 # 自定义lable标签，描述Pod版本号
  namespace: 'default' # 命名空间的配置
spec: # 期望Pod按照这里的描述进行创建
  containers: # Pod中的容器描述
  - name: nginx # 容器名称
    image: arm64v8/nginx:latest # 指定容器的镜像
    imagePullPolicy: IfNotPresent # 镜像拉取策略，Always, Never, IfNotPresent
    command: # 指定容器启动时执行的命令
    - nginx
    - -g
    - 'daemon off;' # nginx -g daemon off;
    workingDir: /usr/share/nginx/html # 定义容器启动后默认的目录
    ports:
    - name: http # 端口名称
      containerPort: 80 # 容器内需要暴露的端口
      protocol: TCP # 描述该端口是基于哪种协议通信的
    env: # 环境变量
    - name: JVM_OPTS # 环境变量名称
      value: '-Xms120m -Xmx128m' # 环境变量的值

    resources:
      requests: # 最少需要多少资源
        cpu: 100m # 限制cpu最多使用0.1个核心
        memory: 128Mi # 限制内存最少使用128兆
      limits: # 最多可以用多少资源
        cpu: 200m # 限制cpu最多使用0.2个核心
        memory: 256Mi # 限制最多使用256兆

  restartPolicy: OnFailure # pod重启策略，Always,OnFailure,Never,默认值为Always, OnFailure 只有pod非零推出码终止时，kubelet才会重启改容器，容器正常>结束的退出码为0

K8S 的资源清单

参数名	类型	字段说明
apiVersion	String	K8S APl 的版本，可以用 kubectl api versions 命令查询
kind	String	yam 文件定义的资源类型和角色
metadata	Object	元数据对象，下面是它的属性
metadata.name	String	元数据对象的名字，比如 pod 的名字
metadata.namespace	String	元数据对象的命名空间
Spec	Object	详细定义对象
spec.containers[]	list	定义 Spec 对象的容器列表
spec.containers[].name	String	为列表中的某个容器定义名称
spec.containers[].image	String	为列表中的某个容器定义需要的镜像名称
spec.containers[].imagePullPolicy	string	定义镜像拉取策略，有 Always、Never、IfNotPresent 三个值可选 - Always（默认）：意思是每次都尝试重新拉取镜像 - Never：表示仅适用本地镜像 - IfNotPresent：如果本地有镜像就使用本地镜像，没有就拉取在线镜像。
spec.containers[].command[]	list	指定容器启动命令，因为是数组可以指定多个，不指定则使用镜像打包时使用的启动命令。
spec.containers[].args[]	list	指定容器启动命令参数，因为是数组可以指定多个。
spec.containers[].workingDir	string	指定容器的工作目录
spec.containers[].volumeMounts[]	list	指定容器内部的存储卷配置
spec.containers[].volumeMounts[].name	string	指定可以被容器挂载的存储卷的名称
spec.containers[].volumeMounts[].mountPath	string	指定可以被容器挂载的存储卷的路径
spec.containers[].volumeMounts[].readOnly	string	设置存储卷路径的读写模式，ture 或者 false，默认是读写模式
spec.containers[].ports[]	list	指定容器需要用到的端口列表
spec.containers[].ports[].name	string	指定端口的名称
spec.containers[].ports[].containerPort	string	指定容器需要监听的端口号
spec.containers[].ports[].hostPort	string	指定容器所在主机需要监听的端口号，默认跟上面 containerPort 相同，注意设置了 hostPort 同一台主机无法启动该容器的相同副本（因为主机的端口号不能相同，这样会冲突）
spec.containers[].ports[].protocol	string	指定端口协议，支持 TCP 和 UDP，默认值为 TCP
spec.containers[].env[]	list	指定容器运行前需设置的环境变量列表
spec.containers[].env[].name	string	指定环境变量名称
spec.containers[].env[].value	string	指定环境变量值
spec.containers[].resources	Object	指定资源限制和资源请求的值（这里开始就是设置容器的资源上限）
spec.containers[].resources.limits	Object	指定设置容器运行时资源的运行上限
spec.containers[].resources.limits.cpu	string	指定 CPU 的限制，单位为 Core 数，将用于 docker run –cpu-shares 参数
spec.containers[].resources.limits.memory	string	指定 mem 内存的限制，单位为 MIB、GiB
spec.containers[].resources.requests	Object	指定容器启动和调度时的限制设置
spec.containers[].resources.requests.cpu	string	CPU请求，单位为core数，容器启动时初始化可用数量
spec.containers[].resources.requests.memory	string	内存请求，单位为MIB、GiB，容器启动的初始化可用数量
spec.restartPolicy	string	定义 pod 的重启策略，可选值为 Always、OnFailure、Never，默认值为 Always。 - Always：pod 一旦终止运行，则无论容器是如何终止的，kubelet 服务都将重启它。 - OnFailure：只有 pod 以非零退出码终止时，kubelet 才会重启该容器。如果容器正常结束（退出码为0），则 kubectl 将不会重启它。 - Never：Pod 终止后，kubelet 将退出码报告给 master，不会重启该 pod
spec.nodeSelector	Object	定义 Node 的 label 过滤标签，以 key：value 格式指定
spec.imagePullSecrets	Object	定义 pull 镜像时使用 secret 名称，以 name：secretkey 格式指定
spec.hostNetwork	Boolean	定义是否使用主机网络模式，默认值为 false。设置 true 表示使用宿主机网络，不使用 docker 网桥，同时设置了 true将无法在同一台宿主机上启动第二个副本

常用命令：
删除pod
kubectl delete po nginx-demo
创建pod
kubectl create -f nginx-demo.yaml
查看pod
kubectl get po
实时查看pod(动态)
kubectl get po -w
查看pod详细信息
kubectl get po -o wide
查看pod构建详细信息
kubectl describe po nginx-demo
查看路由
route -n

二、探针

为什么需要存活探针和就绪探针

上面的配置文件中，通过配置restartPolicy字段来对容器退出后执行3种不同的重启策略，但这并不能解决我们所有的问题，比如容器中的Java应用程序抛出OutOfMemoryErrors，但JVM进程会一致存在，容器并没有退出，再比如，Java停止响应或死锁，容器也没有终止等等，这时如果有一种机制来告诉kubernetes来重启容器那就最好了，在k8s中，提供了一种存活探针的机制来实现上诉的问题。

livenessProbe，叫做存活探针，是为了检测容器是否正在运行，是否活着；
readinessProbe，叫做就绪探针，是为了检测容器是否准备就绪，是否能接受客户端请求；
startupProbe，叫做启动探针，用于判断容器进程是否已经启动。

关于探针看这篇文章，写的太好了⬇️
pod健康检查之容器的存活探针、就绪探针

1、StartupProbe启动探针

k8s 1.16 版本新增的探针，用于判断应用程序是否已经启动了。
当配置了 startupProbe 后，会先禁用其他探针，直到 startupProbe 成功后，其他探针才会继续。

作用：由于有时候不能准确预估应用一定是多长时间启动成功，因此配置另外两种方式不方便配置初始化时长来检测，而配置了 statupProbe 后，只有在应用启动成功了，才会执行另外两种探针，可以更加方便的结合使用另外两种探针使用。

startupProbe:  #启动探针配置
  httpGet:  # 探测方式，基于http请求探测
    path: /api/startup # http请求路径
    port: 80 # 请求端口

2、LivenessProbe就绪探针

用于探测容器中的应用是否运行，如果探测失败，kubelet 会根据配置的重启策略进行重启，若没有配置，默认就认为容器启动成功，不会执行重启策略。

livenessProbe: #就绪探针配置
  httpGet: # 探测方式，基于http请求探测
    path: /health # http请求路径
    port: 8080 # 请求端口
    scheme: HTTP
  initialDelaySeconds: 60 # 初始延时，表示容器启动60秒后才开始探测
  failureThreshold: 5  # 失败多少次才算真正失败
  periodSeconds: 10 # 间隔时间
  successThreshold: 1 # 多少次检测成功才算成功
  timeoutSeconds: 5  # 请求的超时时间

3、ReadinessProbe存活探针

用于探测容器内的程序是否健康，它的返回值如果返回 success，那么就认为该容器已经完全启动，并且该容器是可以接收外部流量的。

readinessProbe: # 存活探针配置
  httpGet:
    path: /ready
    port: 8181
    scheme: HTTP
  failureThreshold: 3 # 错误次数
  periodSeconds: 10 # 间隔时间
  successThreshold: 1 # 多少次检测成功才算成功
  timeoutSeconds: 1 # 请求的超时时间

4、三种探测方式

# 1.ExecAction 
# 在容器内部执行一个命令，如果返回值为 0，则任务容器时健康的。
livenessProbe:
  exec:
    command:
      - cat
      - /health

# 2.TCPSocketAction
# 通过 tcp 连接监测容器内端口是否开放，如果开放则证明该容器健康
livenessProbe:
  tcpSocket:
    port: 80

# 3.HTTPGetAction
# 生产环境用的较多的方式，发送 HTTP 请求到容器内的应用程序，如果接口返回的状态码在 200~400 之间，则认为容器健康。
livenessProbe:
  failureThreshold: 5
  httpGet:
    path: /health
    port: 8080
    scheme: HTTP
    httpHeaders:
      - name: xxx
        value: xxx

5、探针的附加参数配置

initialDelaySeconds: 60 # 初始化时间
timeoutSeconds: 2 # 超时时间
periodSeconds: 5 # 监测间隔时间
successThreshold: 1 # 检查 1 次成功就表示成功
failureThreshold: 2 # 监测失败 2 次就表示失败

注意：定义存活探针时，一定要设置initialDelaySeconds属性，该属性为初始延时，如果不设置，默认容器启动时探针就开始探测了，这样可能会存在应用程序还未启动就绪，就会导致探针检测失败，k8s就会根据pod重启策略杀掉容器然后再重新创建容器的莫名其妙的问题。
在生产环境中，一定要定义一个存活探针。