Kubernetes学习笔记之Pod篇(五)

什么是Pod？

认识与理解Pod

Pod是kubernetes中创建和管理的、最小的可部署的计算单元。
Pod就像一个豌豆荚，豌豆荚中的豆子就是我们常说的容器，里面可能是一组（一个或多个）容器；这些容器共享存储、网络、CPU以及内存等资源，可以把Pod理解为虚拟机，把Pod中的容器理解为运行在虚拟机中的应用。这些容器相对紧密地耦合在一起。这些应用可能是在同一个物理主机或虚拟机上。
kubernetes一般不会直接管理容器，而是通过Pod来管理。

Pod 的context可以理解成多个linux命名空间的联合

PID 命名空间（同一个Pod中的应用可以看到其它进程）
网络命名空间（同一个Pod中的应用对相同的IP地址和端口有权限）
IPC命名空间（同一个Pod中的应用可以通过VPC或者POSIX进行通信）
UTS 命名空间（同一个Pod中的应用共享一个主机名称）

Pod一般包含

一组(一个或多个)容器，一般是一个，除非是耦合性比较强需要共享资源的情况下才放在一个Pod中；
共享的存储资源(如数据卷vloume)，一个Pod中的容器时可以共享存储空间的；
每个pod都会被分配一个独立的IP地址，Pod中的容器共享同一个Pod IP及网络端口，Pod内的容器可以使用localhost相互通信；

Pod中的容器可分为两种类型：

工作容器：也就是我们的应用容器
初始化容器：负责完成一些初始化操作，初始化容器运行在工作容器之前，所以的初始化容器成功执行后，才会启动工作容器

管理和使用Pod

使用Pod

在实际使用kubernetes时，我们一般不会直接创建Pod，因为Pod的生命周期是最短暂的用后即销毁。
Pod不会自愈，如果Pod所在的Node节点资源不足或者Pod属于维护状态，Pod也会被驱逐。kubernetes使用更高级的控制器(controller)的抽象层，来管理Pod实例，虽然可以直接使用Pod，但是kubernetes中通常使用控制器(controller)来管理Pod。

kubernetes中Pod的控制器(controller)

Pod控制器又称为工作负载(workload)，控制器(controller)可以创建和管理多个Pod，提供副本管理、滚动升级和集群级别的自愈能力。例如某个Node故障，控制器(controller)会自动将该节点上的Pod调度到其他健康的Node上。
Pod常用控制器

Deployment：用于管理无状态Pod应用，是目前用的最广泛、最好用的控制器。支持滚动更新和回滚功能，还提供声明式配置。ReplicaSet和Deployment这两个资源对象逐步替换之前RC的作用；
StatefulSet ：管理有状态Pod应用；
DaemonSet ：用于管理守护进程类的Pod应用；
Job ：用于管理仅执行一次性任务的Pod应用，创建的Pod在执行完任务后就立即退出，不需要重启或重建；
Cronjob：用于管理周期性任务，不需要持续运行的Pod应用；
ReplicaSet：副本控制器，用于一直维持Pod数量在设定的期望值

创建Pod

通过资源清单方式创建Pod

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment # 工作负载名称
  labels:
    app: nginx 
spec:
  replicas: 3 # 期望pod数量
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx # 容器名称
        image: nginx:1.14.2 # 容器镜像
        ports:
        - containerPort: 80 # 容器端口

kubectl apply -f nginx-deployment.yaml

通过命令行创建Pod

kubectl run nginx-deploy --image=nginx:1.14.2 --port=80 --dry-run=true

Pod状态
Pod常见状态一般有以下几种：

Pending：Pod已经被创建，但是还没完成调度，一般集群工作节点不足会出现这个状态；
Running：Pod已经被创建并且已经分配到了某一个节点，Pod中所有的容器都已被创建，只是有一个容器正在运行或者在启动中；
Successded：Pod中所有的容器都已经成功终止，不能重新启动；
Failed：Pod中所有的容器均已经终止，且至少有一个容器已经在故障中或者终止；
Unkonwn：apiserver无法获取Pod当前状态，通常是master与Pod所在node主机失去连接导致；
ImagePullBackOff：镜像拉取失败，一般是由镜像名称配置有误、镜像拉取密钥配置有误导致；
CrashLoopBackOff：Pod中容器启动失败，可能是健康检测不通过，容器配置有误导致；
Terminating：Pod正在被删除；
Completed：容器内部主进程退出，一般是Job类应用执行完任务后会出现该状态；
ContainerCreating：Pod正在创建；
PodInitializing：Pod正在初始化中；

容器重启策略

Always：当容器失效时，由kubelet自动重启该容器；
OnFailure：当容器失效时，由kubelet自动重启该容器；
Never：不论容器运行状态如何，kubelet都不会重启该容器

容器镜像拉取策略
如不指定镜像拉取策略，则默认策略为Always
15. Always(总是拉取镜像)；
16. IfNotPresent (优先使用本地镜像，本地有则不拉取镜像)；
17. Never (只使用本地镜像，从不拉取，即使本地没有)
健康检查
健康检查(health check)用于检测应用实例是否正常工作，是保障业务可用性的一种手段。默认情况下，kubelet根据容器运行状态作为健康依据，不能监控容器中应用程序状态，假如程序假死，就会导致无法提供服务，丢失流量。引入kubernetes的健康检查机制可以确保容器健康存活。

健康检查类型主要有以下三种：

startupProbe(启动探测)：指示容器中的应用程序是否已启动。如果提供了启动探测，则会禁用所有其他探测器，直到成功为止。如果启动探测失败，kubelet 会杀死容器，容器会杀死受其重新启动策略的约束。如果容器没有提供启动探测，默认状态为。Success；
readinessProbe(就绪探测)：指示容器是否已准备好响应请求。如果就绪探测失败，端点控制器将删除 Pod 的 IP 来自与 Pod 匹配的所有服务的端点的地址。默认初始延迟之前的准备状态是。如果容器这样做不提供就绪探测，默认状态为。FailureSuccess；
livenessProbe(存货探测)：指示容器是否正在运行。如果活体探测失败，库贝莱特杀死容器，容器受其重新启动策略的约束。如果容器没有提供活动探测器，默认状态为。Success

健康检查机制
有四种不同的方法可以使用探针检查容器。每个探测器必须准确定义以下四种机制之一：

exec 在容器内执行指定的命令。诊断如果命令以状态代码 0 退出，则认为成功。
grpc 使用gRPC 执行远程过程调用。目标应实现gRPC 运行状况检查。如果响应成功，则认为诊断成功。 gRPC 探测器是一项 alpha 功能，仅在以下情况下可用：启用功能入口。statusSERVINGGRPCContainerProbe
httpGet 对 Pod 的 IP 执行 HTTP 请求指定端口和路径上的地址。诊断为如果响应具有状态代码，则视为成功大于或等于 200 且小于 400。
TcpSocket 对
Pod 的 IP 地址执行 TCP 检查指定的端口。如果出现以下情况，则认为诊断成功端口已打开。如果远程系统（容器）关闭连接在打开后立即，这算作正常。探查结果

健康检测结果分为以下三种

Success：表示容器通过了健康检查；
Failure：表示容器没有通过健康检查，此时会重新部署pod，或者是删除；
Unknown：表示当前执行机制没有进行完成，此时不会做任何操作，会等待下次的机制来检查。

常用Pod分析命令：

kubectl describe -n “namespace_name” pod “pod_name” # 查询pod详细信息；
kubectl logs -n “namespace_name” pod “pod_name” # 查询pod日志详情；
kubectl get pods -A -owide |grep “pod_name” # 查询pod运行状态及详细信息