Kubernetes中资源清单与Pod的生命周期(二)

一、资源清单

1,定义:

  在k8s中一般使用yaml格式的文件来创建符合我们预期的资源,这样的yaml被称为资源清单。

  使用资源清单创建Pod:

kubectl apply -f nginx.yaml

  定义nginx.yaml内容为:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod #自定义的名称只能用小写字母使用 - 连接,驼峰 或者 _ 连接会报错
  labels:
    app: nginx-app
    version: v1
spec:
  containers:
  - name: test-nginx
    image: nginx

2,资源清单常用字段

字段类型说明
apiVersion String k8s api 的版本,目前基本上是 v1。可以用 kubectl api-versions 命令查看
kind String 定义的资源类型。比如定义为一个 Pod 或者 Deployment等等。
metadata Object 声明元数据对象,固定值:metadata。
metadata.name String 元数据对象的名字。我们自己定义,比如该资源被 kind 定义为一个 Pod,那么 Pod 的名称就是在这里定义。
metadata.namespace String 元数据对象的命名空间。我们自己定义,不写默认为 default。这里定义的命名空间必须是已存在的。
metadata.labels Object 标签。
metadata.labels.app String 标签名称。
metadata.labels.version String 标签版本号。
Spec Object 详细定义对象。固定值:Spec。
spec.containers[] List 这里是Spec对象的容器列表。即这个资源可以声明多个容器。
spec.containers[].name String 容器的名字。建议不写,会自动创建。如果此处写了容器的名字,那么 k8s 对该容器进行扩容时会报错,因为不能存在相同名称的容器。
spec.containers[].image String 容器使用的镜像。
spec.containers[].imagePullPolicy String 镜像拉取策略。如果不设置,默认为 Always。Always:每次都拉取新的镜像;Never:仅使用本地镜像,如果本地镜像不存在则不使用该镜像;IfNotPresent:如果本地没有,就拉取新镜像。
spec.containers[].command[] List 指定容器启动命令,可以指定多个。不指定则默认为容器打包时使用的启动命令,若指定了则会覆盖原命令。
spec.containers[].args[] List 指定容器启动命令参数,可传入多个。
spec.containers[].workingDir String 指定容器的工作目录。
spec.containers[] 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.restartPolicy String Pod 重启策略。Always:Pod 一旦终止运行,不论是以什么方式终止的,kubelet 都会重启它;OnFailure:如果 Pod 的退出码是0,kubelet 不会重启,其它任何非0退出码终止的,都会重启;Never:Pod 终止后,kubelet 将退出码报告给 master 并不会重启该 Pod。
spec.nodeSelector Object 定义 Node 的 Label 过滤标签,言外之意就是选择在哪些 Node 上执行。以 key:value 格式指定。
spec.imagePullSecrets Object 定义 pull 镜像时使用的 secret 名称,格式为 name:secretkey 。
spec.hostNetwork Boolean 是否使用主机网络模式,默认值为 false。ture 表示使用宿主机网络,不使用 docker 网桥,并且将无法在同一台宿主机上启动第二个副本,否则端端口冲突。

3,排错思路

  如果我们使用资源清单进行资源的创建时发生错误(某个容器启动失败),可以通过以下思路排查(以 Pod 为例):

# 查看 Pod,-n 指定命名空间名称
kubectl get pod -n myspace -o wide

# 查看 Pod 的详细信息(假设 Pod 名称为 my-pod),查询结果包括 Pod 中所有容器的运行情况,如果某个容器正常运行,其 State 属性会是 Running
kubectl describe pod my-pod -n myspace

# 查看 Pod 中容器的运行日志,找出容器运行失败的原因。-c 表示要查看的容器,若 Pod 里只有一个容器,不加也可以。
kubectl log my-pod -c my-nginx -n myspace

二、Pod定义

  每个Pod都会存在一个Pause根容器,是每一个Pod都会去运行的,container即为应用程序,所以Pod就是根容器Pause和应用程序container所组成,在Pod当中可以运行多个小的容器的。

1,Pod组成的意义

  •   使用Pause根容器可以防止由于将多个容器组成一个单元,当其中某个容器挂掉就会导致整个单元无法使用的情况发生。
  •   Pod可以运行过个container,这些container是共享Pause根容器的IP地址,也共享Pause的volume挂债卷,这样既简化了关联业务容器之间的通信问题,也很好的解决了容器之间共享的问题
  •   在Kubernetes中的Pod之间是可以进行相互通信的,因为他们之间是一个二层交换的网络,所以不同主机之间Pod是可以进行相互访问的

2,Pod类型划分

  •   自主式Pod:直接创建一个 Pod 而不使用控制器,这种方式创建的 Pod 就称为 自主式 Pod。这种 Pod 一旦停止或被删除,就无法自动重启或重新创建。
  •   控制器管理的Pod:通过 ReplicaSet、DaemonSet 等控制器创建的 Pod,称为控制器管理的 Pod。通过控制器来管理的 Pod,会有一个期望的副本数量,一旦 Pod 超出或者达不到这个数量,那么控制器就会通过重启、创建或者删除 Pod 的方式维持 Pod 的数量达到期望值。

3,Pod、容器与Node之间的关系

  •   在Node当中运行着Pod,而在Pod当中是包含着容器。
  •   在K8s当中都是以Docker镜像发布的,每个Pod可以理解为上面运行着多个镜像,在默认情况下,比如在Pod当中某个容器停止了,K8s会自动检查这个问题并重启这个Pod(即将Pod当中的所有容器全部重启)
  •   如果Pod所在的Node宕机了,K8s会把Pod调度到其他的Node节点上
  •   Pod当中是可以运行多个应用的,即支持多容器运行,每一个Pod相当于一个资源池,Pod当中的容器可以共享IP和文件系统

三、Pod的生命周期

 1,生命周期描述

初始化 Pod 环境:每一个 Pod 在创建时都会先初始化 Pod 运行所必须的条件。然后才继续执行后面的容器初始化操作。比如会先创建 pause 这样的容器。
Init C:Init Containers,初始化容器。
  我们在 Pod 里面运行的容器,可能会依赖某些文件或者环境才能够正常启动或运行。Init C 就是来完成这些文件或者环境的创建的。
  Init C 可以有多个,也可以没有。按顺序执行,必须要等到前一个执行完成(必须是正常退出,否则会根据重启策略判断是否重新执行该 Init C),才会执行后一个。
  Init C 只存在容器初始化阶段,Init C 执行完成之后会消亡,不参与 Pod 的后续流程。
  所有的 Init C 都正常结束后,Main C 主容器才开始创建并启动。
Main C:主容器。即运行在 Pod 里提供服务的容器。主容器一旦停止运行,那么 Pod 也就停止了。需要注意的是一个 Pod 里面可以有很多个 Main C,且每个 Main C 都有自己的 Init C 等。
start:Main C 创建之前执行的操作,可以是一条命令或一个脚本。
stop:Main C 结束之后执行的操作,可以是一条命令或一个脚本。
readiness:容器就绪检测,可以指定在容器启动之后的某个时间点执行,比如 10 秒后。只有当 readiness 正常执行完成,该 Pod 才会显示为就绪状态。
liveness:容器是否正在运行。

2,InitC

  Init容器与普通的容器非常像,但是:1,Init容器总是运行到成功为止;2,每个Init容器必须都在下一个Init容器启动之前成功完成。

InitC简单实例init.yaml:(kubectl create -f init.yaml)

apiVersion: v1
kind: Pod #Pod类型
metadata:
  name: myapp-pod #Pod名称
  labels:
    app: myapp
spec:
  containers:
  - name: myapp-container #主容器
    image: busybox
    command: ['sh', '-c', 'echo The app is running! && sleep 3600']
  initContainers: #InitC
  - name: init-myservice #率先启动的Init容器
    image: busybox
    command: [ 'sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']  #监控myservice
  - name: init-mydb #在主容器之前启动,在init-myservice正常退出之后启动。
    image: busybox
    command: [ 'sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;'] #监控mydb

myservice.yaml :(kubectl create -f myservice.yaml)

apiVersion: v1
kind: Service
metadata:
  name: myservice
spec:
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

mydb.yaml :(kubectl create -f myservice.yaml)

apiVersion: v1
kind: Service
metadata:
  name: mydb
spec:
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9377

InitC特点:

  • 在 Pod 启动过程中,Init 容器会按顺序在网络和数据卷初始化之后启动(即在 pause 容器之后启动)。每个容器必须在下一个 容器启动之前成功退出。
  • 如果由于运行时或失败退出,将导致容器启动失败,它会根据 Pod 的 restartPolicy 指定的策略进行重试。
  • 在所有的 Init 容器没有成功之前,Pod 将不会变成 Ready 状态。Init 容器的端口将不会在 Service 中进行聚集。正在初始化中的 Pod 处于 Pending 状态,但应该会将 Initializing 状态设置为true。
  • 如果 Pod 重启,所有 Init 容器必须重新执行。
  • 对 Init 容器 spec 的修改被限制在容器 image 字段,修改其他字段都不会生效。更改 Init 容器的 image 字段,等价于重启该Pod。
  • Init 容器具有应用容器的所有字段。除了 readinessProbe,因为 Init 容器无法定义不同于完成 (conpletion)的就绪(readiness)之外的其他状态。
  • 在 Pod 中的每个 app 和 Init 容器的名称必须唯一;与任何其它容器共享同一个名称,会在验证时抛出错误。

3,探针

  探针是由 kubelet 对容器执行的定期诊断。要执行诊断,kubelet 调用由容器实现的 Handler。有三种类型的处理程序:

    •   ExecAction:在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。
    •   TCPSocketAction:对指定端口上的容器的 IP 地址进行 TCP 检查。如果端口打开,则诊断被认为是成功的。
    •   HTTPGetAction:对指定的端口和路径上的容器的 IP 地址执行 HTTPGet 请求。如果响应的状态码大于等于 200 且小于 400,则诊断被认为是成功的。

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

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

  探针有两种类型:

  • readinessProbe:探测容器是否准备好服务请求(即是否就绪 [READY])。如果就绪探测失败,端点控制器将从与 Pod 匹配的所有Service 的端点中删除该 Pod 的 IP 地址。初始延迟之前的就绪状态默认为 Failure 。如果容器不提供就绪探针,则默认状态为Success。
  • livenessProbe:探测容器是否正常运行。如果存活探测失败,则 kubelet 会杀死容器,并且容器将受到其重启策略的影响。如果容器不提供存活探针,则默认状态为 Success。

readinessProbe实例:采用HTTPGetAction(readness-httpget.yaml)

apiVersion: v1
kind: Pod
metadata:
  name: readness-httpget-pod
spec:
  containers:
  - name: readness-httpget-container
    image: hub.xcc.com/library/mynginx:v1
    imagePullPolicy: IfNotPresent #镜像拉取策略
    readinessProbe:
      httpGet: #探测方式
        port: 80
        path: /index1.html #检测路径
      initialDelaySeconds: 1 #容器启动后1s开始探测
      periodSeconds: 3 #如果检测失败,每3s继续探测,直到检测成功或者达到最大检测值

livenessProbe实例:采用ExecAction(liveness-exec.yaml)

apiVersion: v1
kind: Pod
metadata:
  name: liveness-exec-pod
  namespace: default
spec:
  containers:
  - name: lineness-exec-container
    image: busybox
    imagePullPolicy: IfNotPresent
    command: ['sh', '-c', 'touch /tmp/live; sleep 50; rm -rf /tmp/live; sleep 3600']
    livenessProbe:
      exec:
        command: ['test', '-e', '/tmp/live']
      initialDelaySeconds: 1
      periodSeconds: 3

4,Pod hook

  Pod hook(钩子)是由 Kubernetes 管理的 kubelet 发起的,当容器中的进程启动前或者容器中的进程终止之前运行,这是包含在容器的生命周期之中,也就是上面 Pod 生命周期 中提到的 start 和 stop。可以同时为 Pod 中的所有容器都配置 hook。

  Hook的类型包括两种:

    •   exec:执行一段命令。
    •   HTTP:发送HTTP请求。
apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo
spec:
  containers:
  - name: lifecycle-demo-container
    image: hub.xcc.com/library/mynginx:v1
    lifecycle:
      postStart:
        exec:
          command: [......]
      preStop:
        exec:
          command: [......]

5,Pod相位(phase )

  Pod 的 status 字段是一个 PodStatus 对象,PodStatus 中有一个 phase 字段。

  Pod 的相位(phase)是 Pod 在其生命周期中的简单宏观概述。该阶段并不是对容器或 Pod 的综合汇总,也不是为了做为综合状态机。

  Pod 相位的数量和含义是严格指定的,以下是当前 Pod 相位的所有值:

    •   挂起(Pending):Pod 已被 Kubernetes 系统接受,但有一个或者多个容器镜像尚未创建。等待时间包括调度 Pod 的时间和通过网络下载镜像的时间。
    •   运行中(Running):该 Pod 己经绑定到了一个节点上,Pod 中所有的容器都己被创建。至少有一个容器正在运行,或者正处于启动或重启状态。
    •   成功(Succeeded):Pod 中的所有容器都被成功终止,并且不会再重启。
    •   失畋(Failed):Pod 中的所有容器都己终止了,并且至少有一个容器是因为失败终止。也就是说,容器以非0状态退出或者被系统终止。
    •   未知(Unknown):因为某些原因无法取得 Pod 的状态,通常是因为与 Pod 所在主机通信失败。
posted @ 2020-09-10 09:30  MXC肖某某  阅读(415)  评论(0编辑  收藏  举报