Pod概念简介
从逻辑上看K8S将多个物理机资源抽象成一个整体，用于运行各类K8S资源。

Pod是K8S的核心资源之一，属于一种逻辑单元，也是K8S中最小的操作单元。一个Pod单元封装一个应用容器（也可以有多个容器），存储资源、一个独立的网络IP以及管理容器运行的策略。这样在外部看来一个Pod相当于一个虚拟机。

Kubernetes中的Pod使用可分两种主要方式

1. Pod中运行一个容器。“one-container-per-Pod”模式是Kubernetes最常见的用法;在这种情况下，将Pod视为单个封装的容器，但Kubernetes是直接管理Pod而不是容器。
2. Pods中运行多个需要一起工作的容器。Pod可以封装紧密耦合的应用容器，它们之间能够共享资源，这些容器可以形成一个单一的内部service单位;

每一个Pod下的都有一个基础容器pause容器，主要为每个业务容器提供以下功能：

• PID命名空间：Pod中的不同应用程序可以看到其他应用程序的进程ID。
• 网络命名空间：Pod中的多个容器能够访问同一个IP和端口范围。
• IPC命名空间：Pod中的多个容器使用SystemV IPC或POSIX消息队列进行通信。
• UTS命名空间：Pod中的多个容器共享一个主机名；
• Volumes（共享存储卷）：Pod中的各个容器可以访问在Pod级别定义的Volumes。

Pod有元数据以供master进行管理，master主要通过Pod的label进行唯一标识。Pod资源Label格式：key=value是其中一项元数据，使用Label Selector组件根据Label选择Pod资源

Pod存在生命周期，一旦Pod出现问题，controller控制器能指挥Pod重启或者重建

Pod资源的生命周期
周期中的所有状态：pending，running，failed，successed，unknown
生命周期中的行为，如下图

在主容器启动前，所有的初始化操作是串行完成的。

容器启动之后，对容器有两类探测：

1. 存活性探测liveness prode，指示容器是否正在运行。如果存活探测失败，则 kubelet 会杀死容器，并且容器将受到其restartpolicy的影响。如果容器不提供存活探针，则默认状态为 Success。
2. 就绪性探测readinessprode，指示容器是否准备好服务请求。如果就绪探测失败，Endpoint控制器将从与 Pod 匹配的所有 Service 的Endpoint中删除该 Pod 的 IP 地址。初始延迟之前的就绪状态默认为 Failure。如果容器不提供就绪探针，则默认状态为 Success。

两类探测的三种实现方式：

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

pod的创建过程
Pod是Kubernetes的基础单元，了解其创建的过程，更有助于理解系统的运作。

①用户通过kubectl或其他API客户端提交Pod Spec给API Server。

②API Server尝试将Pod对象的相关信息存储到etcd中，等待写入操作完成，API Server返回确认信息到客户端。

③API Server开始反映etcd中的状态变化。

④所有的Kubernetes组件通过"watch"机制跟踪检查API Server上的相关信息变动。

⑤kube-scheduler（调度器）通过其"watcher"检测到API Server创建了新的Pod对象但是没有绑定到任何工作节点。

⑥kube-scheduler为Pod对象挑选一个工作节点并将结果信息更新到API Server。

⑦调度结果新消息由API Server更新到etcd，并且API Server也开始反馈该Pod对象的调度结果。

⑧Pod被调度到目标工作节点上的kubelet尝试在当前节点上调用docker engine进行启动容器，并将容器的状态结果返回到API Server。

⑨API Server将Pod信息存储到etcd系统中。

⑩在etcd确认写入操作完成，API Server将确认信息发送到相关的kubelet。

Pod资源的定义

可通过yaml文件具体定义一个Pod实例，然后以此文件创立该Pod实例
常用的一层定义
apiVersion：标记资源版本 格式group/version 使用命令kebectl api-version查看
kind：标记资源类别
metadata：元数据
spec：用户定义的期望状态(通过kubectl explain pod.spec 获取更详细)
常用的二层定义
nodeName：定义在指定的node节点上运行此Pod
nodeSelector：定义对node的选择策略，选择符合策略要求的node节点运行此Pod

restartPolicy：定义容器的重启策略

• Always ： 容器失效时，kubelet 自动重启该容器；
• OnFailure ： 容器终止运行且退出码不为0时重启；
• Never ：不论状态为何， kubelet 都不重启该容器。

常用的三层定义
spec.containers <[]object> 说明spec.container的值为队列类型对象

name 定义容器的名字
image 定义容器使用的镜像，若节点没有会从仓库拉取
imagePullPolicy

• 镜像拉取的策略，可用的值为Always，Never，IfNotPresent。
  Always表示总是从仓库中拉取镜像，不关本地有无镜像
  Never表示一直使用本地的镜像，本地没有镜像则等待本地导入
  IfNotPresent表示本地有镜像则使用，没有则去仓库中拉取
  只要容器标签为latest则默认使用Always，可以改使用IfNotPresent
  此字段一旦创建无法更新

ports 仅提供容器暴露的端口信息，并不能决定容器暴露什么端口，端口暴露由镜像决定。

command 提供的命令不会在shell中执行；如果需要执行shell命令 则使用/bin/bash ；
如果没有指定command，则使用容器镜像中的ENTRYPOINT。

args 提供命令参数，如果没有指定args，则使用容器镜像中的CMD

Pod实例操作
exec探测的测试
存活和就绪的探测方式基本接近
ngx-liveness-exec.yaml文件内容如下

apiVersion: v1
kind: Pod
metadata:
   name: liveness-exec-pod
   namespace: default
   labels:
     app: liveness-exec
     tier: frontend
spec:
   containers:
   - name: liveness-exec
     image: 192.168.80.146:5000/busybox:latest
     command: ["/bin/sh","-c","touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 60"]
     livenessProbe:
       exec: ##探测命令
          command: ["test","-e", "/tmp/healthy"] ##判断/tmp/healthy文件是否还存在
       initialDelaySeconds: 1 ##容器初始化完成后迟延1秒再开始存活探测
       periodSeconds: 3  ##每次探测间隔3秒

1、以此文件生成一个pod并观察pod状态

[root@k8s-master k8s-yaml]# kubectl create -f ngx-liveness-exec.yaml 
pod/liveness-exec-pod created
[root@k8s-master k8s-yaml]# kubectl get pods -w
NAME                READY     STATUS              RESTARTS   AGE
liveness-exec-pod   0/1       ContainerCreating   0          4s
liveness-exec-pod   1/1       Running   0         11s

2、running前30秒进入pod的容器进行，存在/tmp/healty文件

[root@k8s-node2 ~]# docker exec -it 94d25d20fc85 /bin/sh
/ # ls /tmp/
healthy

3、30秒后容器删除该文件，但不关闭容器，但liveness探测到该文件不存在，就依据restartPolicy完成重启，观察RESTARTS可以确定重启次数

[root@k8s-master k8s-yaml]# kubectl get pods -w                      
NAME                READY     STATUS    RESTARTS   AGE
liveness-exec-pod   1/1       Running   2          3m
liveness-exec-pod   1/1       Running   3         3m

httpget探测的测试
ngx-liveness-httpget.yaml文件内容如下

apiVersion: v1
kind: Pod
metadata:
   name: liveness-httpget-pod
   namespace: default
   labels:
     app: liveness-httpget
     tier: frontend
spec:
   nodeName: k8s-node2
   containers:
   - name: liveness-httpget
     image: 192.168.80.146:5000/my_ngx:v1
     ports:
     - name: http
       containerPort: 80
     livenessProbe:
       httpGet:
          port: http
          path: /index.html
       initialDelaySeconds: 1
       periodSeconds: 3

1、以此文件生成一个pod并观察pod状态

[root@k8s-master k8s-yaml]# kubectl create -f ngx-liveness-httpget.yaml 
pod/liveness-httpget-pod created
[root@k8s-master k8s-yaml]# kubectl get pods -w
NAME                READY     STATUS              RESTARTS   AGE
liveness-httpget-pod   0/1       ContainerCreating   0          4s
liveness-httpget-pod   1/1       Running   0         12s

2、进入pod的容器删除 /usr/share/nginx/html/index.html文件，即ngx的默认index文件

[root@k8s-node2 ~]# docker exec -it 34bf577f8920 /bin/sh
/ # rm -f /usr/share/nginx/html/index.html

3、liveness探测到httpget失败，就依据restartPolicy完成重启，观察RESTARTS可以确定重启次数

[root@k8s-master k8s-yaml]# kubectl get pods -w                      
NAME                READY     STATUS    RESTARTS   AGE
liveness-httpget-pod   1/1       Running   2          3m