2.k8s基础-基本概念Pod

1 Pod

1.1 创建一个 Pod

定义一个 Pod

# vim nginx.yaml
apiVersion: v1 # 必选，API 的版本号
kind: Pod # 必选，类型 Pod
metadata: # 必选，元数据
 name: nginx # 必选，符合 RFC 1035 规范的 Pod 名称
spec: # 必选，用于定义 Pod 的详细信息
 containers: # 必选，容器列表
 - name: nginx # 必选，符合 RFC 1035 规范的容器名称
   image: nginx:1.15.12 # 必选，容器所用的镜像的地址
   ports: # 可选，容器需要暴露的端口号列表
   - containerPort: 80 # 端口号

创建 Pod：

# kubectl create -f nginx.yaml
pod/nginx created

查看 Pod 状态：

# kubectl get po nginx
NAME READY STATUS RESTARTS AGE
nginx 0/1 ContainerCreating 0 20s

使用 kubectl run 创建一个 Pod：

# kubectl run nginx-run --image=nginx:1.15.12

1.2 更改 Pod 的启动命令和参数

1.3 Pod 状态及 Pod 故障排查命令

• Pending（挂起） ：

Pod 已被 Kubernetes 系统接收，但仍有一个或多个容器未被创建，可以通过 kubectl describe 查看处于 Pending 状态的原因

• Running（运行中）

Pod 已经被绑定到一个节点上，并且所有的容器都已经被创建，而且至少有一个 是运行状态，或者是正在启动或者重启，可以通过 kubectl logs 查看 Pod 的日志

• Succeeded（成功）

所有容器执行成功并终止，并且不会再次重启，可以通过 kubectl logs 查看 Pod 日志

• Failed（失败）

所有容器都已终止，并且至少有一个容器以失败的方式终止，也就是说这个容器 要么以非零状态退出，要么被系统终止，可以通过 logs 和 describe 查看 Pod 日 志和状态

• Unknown（未知）

通常是由于通信问题造成的无法获得 Pod 的状态

• ImagePullBackOff ErrImagePull

镜像拉取失败，一般是由于镜像不存在、网络不通或者需要登录认证引起的，可 以使用 describe 命令查看具体原因

• CrashLoopBackOff

容器启动失败，可以通过 logs 命令查看具体原因，一般为启动命令不正确，健 康检查不通过等

• OOMKilled

容器内存溢出，一般是容器的内存 Limit 设置的过小，或者程序本身有内存溢出， 可以通过 logs 查看程序启动日志

• Terminating

Pod 正在被删除，可以通过 describe 查看状态

• SysctlForbidden

Pod 自定义了内核配置，但 kubelet 没有添加内核配置或配置的内核参数不支持， 可以通过 describe 查看具体原因

• Completed

容器内部主进程退出，一般计划任务执行结束会显示该状态，此时可以通过 logs 查看容器日志

• ContainerCreating

Pod 正在创建，一般为正在下载镜像，或者有配置不当的地方，可以通过 describe 查具体原因

注意：Pod 的 Phase 字段只有 Pending、Running、Succeeded、Failed、Unknown，其余的为处 于上述状态的原因，可以通过 kubectl get po xxx –o yaml 查看。

1.4 Pod 镜像拉取策略

通过 spec.containers[].imagePullPolicy 参数可以指定镜像的拉取策略，目前支持的策略如下：

• Always

总是拉取，当镜像 tag 为 latest 时，且 imagePullPolicy 未配置，默认为 Always

• Never

不管是否存在都不会拉取

• IfNotPresent

镜像不存在时拉取镜像，如果 tag 为非 latest，且 imagePullPolicy 未配置，默认为 IfNotPresent

更改镜像拉取策略为 IfNotPresent：

1.5 Pod 重启策略

可以使用 spec.restartPolicy 指定容器的重启策略

• Always

默认策略。容器失效时，自动重启该容器

• OnFailure

容器以不为 0 的状态码终止，自动重启该容器

• Never

无论何种状态，都不会重启

指定重启策略为 Never：

1.6 Pod 的三种探针

• startupProbe

Kubernetes1.16 新加的探测方式，用于判断容器内的应用程序是否已经启动。如果 配置了 startupProbe，就会先禁用其他探测，直到它成功为止。如果探测失败，Kubelet 会杀死容器，之后根据重启策略进行处理，如果探测成功，或没有配置 startupProbe， 则状态为成功，之后就不再探测。

• livenessProbe

用于探测容器是否在运行，如果探测失败，kubelet 会“杀死”容器并根据重启策略 进行相应的处理。如果未指定该探针，将默认为 Success

• readinessProbe

一般用于探测容器内的程序是否健康，即判断容器是否为就绪（Ready）状态。如 果是，则可以处理请求，反之 Endpoints Controller 将从所有的 Service 的 Endpoints 中删除此容器所在 Pod 的 IP 地址。如果未指定，将默认为 Success

1.7 Pod 探针的实现方式

• ExecAction

在容器内执行一个指定的命令，如果命令返回值为 0，则认为容器健康

• TCPSocketAction

通过 TCP 连接检查容器指定的端口，如果端口开放，则认为容器健康

• HTTPGetAction

对指定的 URL 进行 Get 请求，如果状态码在 200~400 之间，则认为容器健康

1.8 livenessProbe 和 readinessProbe

为什么要配置健康检查？

Kubernetes 中 Pod 是最小的计算单元，而一个 Pod 又由多个容器组成，相当于每个容器就是一个应用，应用在运行期间，可能因为某些意外情况致使程序挂掉。那么如何监控这些容器状态稳定性，保证服务在运行期间不会发生问题，发生问题后进行重启等机制，就成为了重中之重的事情，考虑到这点 kubernetes 推出了活性探针机制。有了存活性探针能保证程序在运行中如果挂掉能够自动重启，但是还有个经常遇到的问题，比如说，在Kubernetes 中启动Pod，显示明明Pod已经启动成功，且能访问里面的端口，但是却返回错误信息。还有就是在执行滚动更新时候，总会出现一段时间，Pod对外提供网络访问，但是访问却发生404，这两个原因，都是因为Pod已经成功启动，但是Pod容器中应用程序还在启动中导致的，考虑到这点Kubernetes推出了就绪性探针机制。

首先 创建一个没有探针的 Pod：

配置健康检查：

1.9 配置 StartupProbe

1.10 preStop 和 postStart

1.11 gRPC 探测（1.24 默认开启）

1.12.探针实践

livenessProbe

exec

httpGet

tcpSocket

readinessProbe

exec

httpGet

tcpSocket

1.13 pod总结

pod生命周期

pod从开始创建到终止退出的时间范围称为Pod生命周期1

生命周期包含以下几个重要流程

初始化容器（initContainers）
创建主容器（containers）是必须的操作
容器启动后钩子

pod在整个生命周期的过程中总会处于以下几个状态：

Pending：创建了pod资源并存入etcd中，但尚未完成调度。
ContainerCreating：Pod 的调度完成，被分配到指定 Node 上。处于容器创建的过程中。通常是在拉取镜像的过程中。

pod生命周期的重要行为

容器的重启策略

定义是否重启Pod对象
Always：但凡Pod对象终止就重启，默认设置
OnFailure：仅在Pod出现错误时才重启
Never：从不
​
注：一旦Pod绑定到一个节点上，就不会被重新绑定到另一个节点上，要么重启，要么终止

pod的终止过程终止过程主要分为如下几个步骤

初始化容器（init）

spec字段下有个initContainers字段(初始化容器)，Init容器就是做初始化工作的容器。可以有一个或多个，如果多个按照定义的顺序依次执行，先执行初始化容器1，再执行初始化容器2等，等初始化容器执行完具体操作之后初始化容器就退出了，只有所有的初始化容器执行完后，主容器才启动。
由于一个Pod里容器存储卷是共享的，所以Init Container里产生的数据可以被主容器使用到，Init Container可以在多种K8S资源里被使用到，如Deployment、DaemonSet, StatefulSet、Job等，但都是在Pod启动时，在主容器启动前执行，做初始化工作。
https://link.zhihu.com/?target=https%3A//kubernetes.io/docs/concepts/workloads/pods/init-containers/%23init-containers-in-use

初始化容器与主容器区别是

1、初始化容器不支持 Readinessprobe,因为它们必须在Pod就绪之前运行完成
2、每个Init容器必须运行成功,下一个才能够运行

初始化容器应用

创建pod并查看pod

测试pod

主容器

1、容器钩子
初始化容器启动之后，开始启动主容器，在主容器启动之后有一个post start hook（容器启动后钩子）和pre stop hook（容器结束前钩子），无论启动后还是结束前所做的事我们可以把它放到这两个钩子，这个钩子就表示用户可以用它来钩住一些命令，非必须选项

• postStart：该钩子在容器被创建后立刻执行，如果该钩子对应的探测执行失败，则该容器会被杀死，并根据该容器的重启策略决定是否要重启该容器，这个钩子不需要传递任何参数。
• preStop：该钩子在容器被删除前执行，主要用于释放资源和优雅关闭程序

容器钩子：postStart和preStop

postStart：容器创建之后立刻执行，用于资源部署、环境准备等。 preStop：在容器被终止前执行，用于优雅关闭应用程序、通知其他系统等

postStart和preStop用法

测试启动和停止钩子

查看pod

优雅的删除资源对象

当用户请求删除含有pod的资源对象时（如RC、deployment等），K8S为了让应用程序优雅关闭（即让应用程序完成正在处理的请求后，再关闭软件），K8S提供两种信息通知：

总结：

pod在整个生命周期中有非常多的用户行为：

1、初始化容器完成初始化

2、主容器启动后可以做启动后钩子

3、主容器结束前可以做结束前钩子

4、在主容器运行中可以做一些健康检测，如startupprobe、livenessprobe，readnessprobe

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx
  name: nginx
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: docker.io/library/nginx:1.18.0-alpine
        ports

cat nginx.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx
  name: nginx
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: docker.io/library/nginx:1.18.0-alpine