1 Pod 特点

Pod是kubernetes中你可以创建和部署的最小也是最简的单位，一个Pod代表着集群中运行的一个进程。

	Pod中封装着应用的容器（有的情况下是好几个容器），存储、独立的网络IP，管理容器如何运行的策略选项，Pod代表着部署的一个单位：kubernetes中应用的一个实例，可能由一个或者多个容器组合在一起共享资源。

Pod有两个必须知道的特点

1.1 网络

	每一个Pod都会被指派一个唯一的Ip地址，在Pod中的每一个容器共享网络命名空间，包括Ip地址和网络端口，在同一个Pod中的容器可以同locahost进行互相通信，当Pod中的容器需要与Pod外的实体进行通信时，则需要通过端口等共享的网络资源。

1.2 存储

	Pod能够配置共享存储卷，在Pod中所有的容器能够访问共享存储卷，允许这些容器共享数据，存储卷也允许在一个Pod持久化数据，以防止其中的容器需要被重启。

2 使用方式

2.1 自主式Pod

	这种Pod本身是不能自我修复的，当Pod被创建后（不论是由你直接创建还是被其他Controller），都会被Kuberentes调度到集群的Node上，直到Pod的进程终止、被删掉、因为缺少资源而被驱逐、或者Node故障之前这个Pod都会一直保持在那个Node上，Pod不会自愈。

	如果Pod运行的Node故障，或者是调度器本身故障，这个Pod就会被删除，同样的，如果Pod所在Node缺少资源或者Pod处于维护状态，Pod也会被驱逐。

2.2 控制器管理的Pod

	Kubernetes使用更高级的称为Controller的抽象层，来管理Pod实例，Controller可以创建和管理多个Pod，提供副本管理、滚动升级和集群级别的自愈能力。

	例如，如果一个Node故障，Controller就能自动将该节点上的Pod调度到其他健康的Node上。虽然可以直接使用Pod，但是在Kubernetes中通常是使用Controller来管理Pod的

3 自主运行Pod

3.1 创建资源清单

通过yaml文件或者json描述Pod和其内容器的运行环境和期望状态，例如一个最简单的运行nginx应用的pod，定义如下

vi nginx-pod.yml
apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.12
    ports:
    - containerPort: 80

3.1.1 参数描述

下面简要分析一下上面的Pod定义文件：

• apiVersion： 使用哪个版本的Kubernetes API来创建此对象
• kind：要创建的对象类型，例如Pod，Deployment等
• metadata：用于唯一区分对象的元数据，包括：name，UID和namespace
• labels：是一个个的key/value对，定义这样的label到Pod后，其他控制器对象可以通过这样的label来定位到此Pod，从而对Pod进行管理。（参见Deployment等控制器对象）
• spec： 其它描述信息，包含Pod中运行的容器，容器中运行的应用等等。不同类型的对象拥有不同的spec定义。详情参见API文档

3.2 创建Pod

使用kubectl创建pod

kubectl apply -f nginx-pod.yml

3.3 Pod操作

3.3.1 查看Pod列表

kubectl get pods

可以通过增加 -o wide查看详细信息

kubectl get pods -o wide

3.3.2 查看描述信息

可以通过describe查看pod的详细信息

kubectl describe pod nginx

3.3.3 访问pod

可以通过k8s创建的虚拟IP进行访问，可以在k8s的任何一个节点访问

 curl 10.244.1.10

3.3.4 删除Pod

可以使用delete删除Pod，删除后不能进行恢复

kubectl delete pod nginx

4 控制器运行Pod

Pod本身不具备容错性，这意味着如果Pod运行的Node宕机了，那么该Pod无法恢复，因此推荐使用Deployment等控制器来创建Pod并管理。

4.1 创建资源清单

通过yaml文件或者json描述Pod和其内容器的运行环境和期望状态，例如一个最简单的运行nginx应用的pod，定义如下

vi nginx-pod.yml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
        app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.12
        ports:
        - containerPort: 80

4.2 参数描述

下面简要分析一下上面的Pod定义文件：

4.2.1 Replicas

副本数量

	spec.replicas 是可以选字段，指定期望的pod数量，默认是1。

4.2.2 Selector

标签选择器

	.spec.selector是可选字段，用来指定 label selector ，圈定Deployment管理的pod范围。如果被指定， .spec.selector 必须匹配 .spec.template.metadata.labels，否则它将被API拒绝。如果 .spec.selector 没有被指定， .spec.selector.matchLabels 默认是.spec.template.metadata.labels。

	在Pod的template跟.spec.template不同或者数量超过了.spec.replicas规定的数量的情况下，Deployment会杀掉label跟selector不同的Pod。

4.2.3 Pod Template

Pod模板，.spec.template 是 .spec中唯一要求的字段。

	.spec.template 是 pod template，它跟 Pod有一模一样的schema，除了它是嵌套的并且不需要apiVersion 和 kind字段。

	另外为了划分Pod的范围，Deployment中的pod template必须指定适当的label（不要跟其他controller重复了，参考selector）和适当的重启策略。

	.spec.template.spec.restartPolicy 可以设置为 Always , 如果不指定的话这就是默认配置。

4.3 创建Pod

kubectl apply -f nginx-pod.yml

kubectl get pods -o wide

创建后发现，有两个nginx的pod在运行，符合我们的预期

4.4 Pod操作

4.4.1 删除Pod

这里可以尝试删除Pod

kubectl delete pod nginx-deployment-f77774fc5-cgs82
# 查看Pod详情
kubectl get pods -o wide

删除Pod后发现重新新建了一个Pod，这是因为有控制器发现少了一个Pod就会进行重新拉起来一个

5 镜像拉取策略

pod的镜像拉取策略分为三种：

• always（总是从官方下载镜像）
• never（从不下载镜像）
• ifnotpresent（如果本地没有镜像就从官方下载镜像）。

Kubernetes集群默认使用IfNotPresent策略

5.1 always

不管是否存在本地镜像，总是从远程仓库下载

5.1.1 修改资源清单

我们可以通过修改配置清单来配置不同的策略

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
        app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.12
        imagePullPolicy: Always
        ports:
        - containerPort: 80

5.1.2 生效配置

kubectl apply -f nginx-pod.yml

5.1.3 查看创建过程

kubectl describe pod nginx-deployment

可以清楚的看到重新下载而没有使用本地镜像

5.2 IfNotPresent

Kubernetes集群的默认策略，如果有本地镜像就使用，没有则从远程仓库下载

5.2.1 修改资源清单

我们可以通过修改配置清单来配置不同的策略

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
        app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.12
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80

5.2.2 生效配置

kubectl apply -f nginx-pod.yml

5.2.3 查看创建过程

kubectl describe pod nginx-deployment

可以清楚的看到没有重新下载镜像而是使用本地的镜像。

6 Pod生命周期

6.1 各个阶段

POD中明确规定了如下几个阶段

	实际上还有一中状态Terminating，在代码和文档中都没有说明，但却是存在。这种情况出现杂无法获取所在主机的资源情况，一直在尝试建立连接。

6.2 Pod重启策略

在Pod中的容器可能会由于异常等原因导致其终止退出，Kubernetes提供了重启策略以重启容器。

	Pod通过`restartPolicy`字段指定重启策略，重启策略类型为：Always、OnFailure 和 Never，默认为 Always。

	重启策略对同一个Pod的所有容器起作用，容器的重启由Node上的kubelet执行。Pod支持三种重启策略，在配置文件中通过`restartPolicy`字段设置重启策略：

注意：这里的重启是指在Pod的宿主Node上进行本地重启，而不是调度到其它Node上。

6.3 Pod状态转换

6.4 生命周期行为

6.4.1 初始化容器

初始化容器（init container）即应用程序的主容器启动之前要运行的容器，常用于为主容器执行一些预置操作，它们具有两种典型特征。

1. 初始化容器必须运行完成直至结束，若某初始化容器运行失败，那么kubernetes需要重启它直到成功完成。（注意：如果pod的spec.restartPolicy字段值为“Never”，那么运行失败的初始化容器不会被重启。）
2. 每个初始化容器都必须按定义的顺序串行运行。

6.4.2 容器探测

容器探测（container probe）是Pod对象生命周期中的一项重要的日常任务，它是kubelet对容器周期性执行的健康状态诊断，诊断操作由容器的处理器（handler）进行定义，Kubernetes支持三种处理器用于Pod探测：

• ExecAction：在容器内执行指定命令，并根据其返回的状态码进行诊断的操作称为Exec探测，状态码为0表示成功，否则即为不健康状态。
• TCPSocketAction：通过与容器的某TCP端口尝试建立连接进行诊断，端口能够成功打开即为正常，否则为不健康状态。
• HTTPGetAction：通过向容器IP地址的某指定端口的指定path发起HTTP GET请求进行诊断，响应码为2xx或3xx时即为成功，否则为失败。

任何一种探测方式都可能存在三种结果：“Success”（成功）、“Failure”（失败）、“Unknown”（未知），只有success表示成功通过检测。