Pod是Kubernetes进行管理的最小单元，程序要运行必须部署在容器中，而容器必须存在于Pod中

Pod可以认为是容器的封装，一个Pod中可以存在一个或者多个容器

在Kubernetes里面，Pod实际上正是Kubernetes抽象出来的一个可以类比为进程组的概念

由四个进程共同组成的一个应用Helloworld，在Kubernetes里面，实际上会被定义为一个拥有四个容器的Pod

就是说现在有四个职责不同、相互协作的进程，需要放在容器里去运行，在Kubernetes里面并不会把它们放到一个容器里，Kubernetes会把四个独立的进程分别用四个独立的容器启动起来，然后把它们定义在一个Pod里面

所以当Kubernetes把Helloworld给拉起来的时候，实际上会看到四个容器，它们共享了某些资源，这些资源都属于Pod，所以我们说Pod 在Kubernetes里面只有一个逻辑单位，没有一个真实的东西对应说这个就是Pod。真正起来在物理上存在的东西，就是四个容器。这四个容器，或者说是多个容器的组合就叫做Pod

Pod是Kubernetes分配资源的一个单位，因为里面的容器要共享某些资源，所以Pod也是Kubernetes的原子调度单位

假如现在有两个容器，它们是紧密协作的，所以它们应该被部署在一个Pod里面。具体来说，第一个容器叫做App，就是业务容器，它会写日志文件；第二个容器叫做LogCollector，它会把刚刚App容器写的日志文件转发到后端的ElasticSearch中

两个容器的资源需求是这样的：App容器需要1G内存，LogCollector需要0.5G内存，而当前集群环境的可用内存是这样一个情况：Node_A：1.25G内存、Node_B：2G内存

假如说现在没有Pod概念，就只有两个容器，这两个容器要紧密协作、运行在一台机器上。可是，如果调度器先把App调度到了Node_A上面，接下来会怎么样呢？这时会发现：LogCollector实际上是没办法调度到Node_A上的，因为资源不够。其实此时整个应用本身就已经出问题了，调度已经失败了，必须去重新调度

在Kubernetes里，就直接通过Pod这样一个概念去解决了。因为在Kubernetes里，这样的一个App容器和LogCollector容器一定是属于一个Pod的，它们在调度时必然是以一个Pod为单位进行调度，所以这个问题是根本不存在的

Pod里面的容器是超亲密关系，大概分为以下几类：

比如说两个进程之间会发生文件交换，比如一个写日志，一个读日志两个进程之间需要通过localhost或者说是本地的Socket去进行通信，这种本地通信也是超亲密关系这两个容器或者是微服务之间，需要发生非常频繁的RPC调用，出于性能的考虑，也希望它们是超亲密关系两个容器或者是应用，它们需要共享某些Linux Namespace。最简单常见的一个例子，就是我有一个容器需要加入另一个容器的Network Namespace。这样我就能看到另一个容器的网络设备，和它的网络信息 4）、Infra container（也叫Pause容器）

每个Pod中都可以包含一个或者多个容器，这些容器可以分为两类：

业务容器（用户程序所在的容器）：数量可多可少

Infra container：每个Pod都会有的一个根容器

1）共享网络

如上图所示，这个Pod里有两个用户容器A和B，还有一个Infra container。Infra container是一个非常小的镜像，大概100~200KB左右，是一个汇编语言写的、永远处于暂停状态的容器

整个Pod里Infra container第一个启动，在Infra containerHold住Network Namespace后，用户容器就可以加入到Infra container的Network Namespace当中了

所以说一个Pod里面的所有容器，它们看到的网络视图是完全一样的。即：它们看到的网络设备、IP地址、Mac地址等等，跟网络相关的信息，其实全是一份，这一份都来自于Pod第一次创建的这个Infra container。这就是Pod解决网络共享的一个解法

这也就意味着，对于Pod里的容器A和容器B来说：

它们可以直接使用localhost进行通信它们看到的网络设备跟Infra container看到的完全一样一个Pod只有一个IP地址，也就是这个Pod的Network Namespace对应的IP地址其他的所有网络资源，都是一个Pod一份，并且被该Pod中的所有容器共享Pod的生命周期只跟Infra container一致，而与容器A和B无关

而对于同一个Pod里面的所有用户容器来说，它们的进出流量，也可以认为都是通过Infra container完成的

2）共享存储

有了Infra container这个设计之后，共享Volume就简单多了：Kubernetes只要把所有Volume的定义都设计在Pod层级即可

这样，一个Volume对应的宿主机目录对于Pod来说就只有一个，Pod里的容器只要声明挂载这个Volume，就一定可以共享这个Volume对应的宿主机目录。比如下面这个例子：

apiVersion: v1
kind: Pod
metadata:
  name: two-containers
spec:
  restartPolicy: Never
  volumes:
  - name: shared-data
    hostPath:      
      path: /data
  containers:
  - name: nginx-container
    image: nginx
    volumeMounts:
    - name: shared-data
      mountPath: /usr/share/nginx/html
  - name: debian-container
    image: debian
    volumeMounts:
    - name: shared-data
      mountPath: /pod-data
    command: ["/bin/sh"]
    args: ["-c", "echo Hello from the debian container > /pod-data/index.html"]

在这个例子中，debian-container和nginx-container都声明挂载了shared-data这个Volume。而shared-data是hostPath类型。所以，它对应在宿主机上的目录就是：/data。而这个目录，其实就被同时绑定挂载进了上述两个容器当中

这就是nginx-container可以从它的/usr/share/nginx/html目录中，读取到debian-container生成的index.html文件的原因

3）Infra container的作用

整个Pod的生命周期就等同于Infra container的生命周期，可以以它为依据，评估整个Pod的健康状态Pod里的多个业务容器共享Infra container的IP，共享Infra container挂载的Volume，既简化了密切关联的业务容器之间的通讯问题，也很好地解决了它们之间的文件共享问题

下面是Pod的资源清单：

apiVersion: v1 # 必选，版本号，例如v1
kind: Pod # 必选，资源类型，例如Pod
metadata: # 必选，元数据
  name: string # 必选，Pod名称
  namespace: string # Pod所属的命名空间，默认为"default"
  labels: # 自定义标签列表
    - name: string      　          
spec: # 必选，Pod中容器的详细定义
  containers: # 必选，Pod中容器列表
  - name: string # 必选，容器名称
    image: string # 必选，容器的镜像名称
    imagePullPolicy: [ Always|Never|IfNotPresent ] # 镜像拉取策略
    command: [string] # 容器的启动命令列表，如不指定，使用打包时使用的启动命令
    args: [string] # 容器的启动命令参数列表
    workingDir: string # 容器的工作目录
    volumeMounts: # 挂载到容器内部的存储卷配置
    - name: string # 引用pod定义的共享存储卷的名称，需用volumes[]部分定义的的卷名
      mountPath: string # 存储卷在容器内mount的绝对路径，应少于512字符
      readOnly: boolean # 是否为只读模式
    ports: # 需要暴露的端口库号列表
    - name: string # 端口的名称
      containerPort: int # 容器需要监听的端口号
      hostPort: int # 容器所在主机需要监听的端口号，默认与Container相同
      protocol: string # 端口协议，支持TCP和UDP，默认TCP
    env: # 容器运行前需设置的环境变量列表
    - name: string # 环境变量名称
      value: string # 环境变量的值
    resources: # 资源限制和请求的设置
      limits: # 资源限制的设置
        cpu: string # Cpu的限制，单位为core数，将用于docker run --cpu-shares参数
        memory: string # 内存限制，单位可以为Mib/Gib，将用于docker run --memory参数
      requests: # 资源请求的设置
        cpu: string # Cpu请求，容器启动的初始可用数量
        memory: string # 内存请求，容器启动的初始可用数量
    lifecycle: # 生命周期钩子
        postStart: # 容器启动后立即执行此钩子，如果执行失败，会根据重启策略进行重启
        preStop: # 容器终止前执行此钩子，无论结果如何，容器都会终止
    livenessProbe: # 对Pod内各容器健康检查的设置，当探测无响应几次后将自动重启该容器
      exec: # 对Pod容器内检查方式设置为exec方式
        command: [string] # exec方式需要制定的命令或脚本
      httpGet: # 对Pod内个容器健康检查方法设置为HttpGet，需要制定Path、port
        path: string
        port: number
        host: string
        scheme: string
        HttpHeaders:
        - name: string
          value: string
      tcpSocket: # 对Pod内个容器健康检查方式设置为tcpSocket方式
         port: number
       initialDelaySeconds: 0 # 容器启动完成后首次探测的时间，单位为秒
       timeoutSeconds: 0 # 对容器健康检查探测等待响应的超时时间，单位秒，默认1秒
       periodSeconds: 0 # 对容器监控检查的定期探测时间设置，单位秒，默认10秒一次
       successThreshold: 0
       failureThreshold: 0
       securityContext:
         privileged: false
  restartPolicy: [Always | Never | OnFailure] # Pod的重启策略
  nodeName:  # 设置NodeName表示将该Pod调度到指定到名称的node节点上
  nodeSelector: obeject # 设置NodeSelector表示将该Pod调度到包含这个label的node上
  imagePullSecrets: # Pull镜像时使用的secret名称，以key：secretkey格式指定
  - name: string
  hostNetwork: false # 是否使用主机网络模式，默认为false，如果设置为true，表示使用宿主机网络
  volumes: # 在该pod上定义共享存储卷列表
  - name: string # 共享存储卷名称 （volumes类型有很多种）
    emptyDir: {} # 类型为emtyDir的存储卷，与Pod同生命周期的一个临时目录。为空值
    hostPath: string # 类型为hostPath的存储卷，表示挂载Pod所在宿主机的目录
      path: string # Pod所在宿主机的目录，将被用于同期中mount的目录
    secret: # 类型为secret的存储卷，挂载集群与定义的secret对象到容器内部
      scretname: string  
      items:     
      - key: string
        path: string
    configMap: # 类型为configMap的存储卷，挂载预定义的configMap对象到容器内部
      name: string
      items:
      - key: string
        path: string

可通过一个命令来查看每种资源的可配置项

kubectl explain 资源类型：查看某种资源可以配置的一级属性kubectl explain 资源类型.属性：查看属性的子属性

[root@k8s-master ~]# kubectl explain pod
KIND:     Pod
VERSION:  v1
FIELDS:
   apiVersion   
   kind 
   metadata