深入掌握Pod

让我们深入探索Pod的应用、配置、调度、升级及扩缩容，开始Kubernetes容器编排之旅。

Pod定义详解

YAML格式的Pod定义文件的完整内容如下：

apiVersion: v1
kind: Pod
metadate: 
  name: string
  namespace: string
  labels:
    - name: string
  annotations:
    - name: string
spec:
  containers:
  - name: string
    image: string
    imagePullPolicy: [Always | Never | IfNotPresent]
    command: [string]
    args: [string]
    workingDir: string
    volumeMounts:
    - name: string
      mountsPath: string
      readOnly: boolean
    ports:
    - name: string
      containerPort: int
      hostPort: int
      protocol: string
    env:
    - name: string
      value: string
    resource:
      limits:
        cpu: string
        memory: string
      requests:
        cpu: string
        memory: string
    livenessProbe:
      exec:
        command: [string]
      httpGet:
        path: string
        port: string
        host: string
        scheme: string
        httpHeaders:
        - name: string
          values: string
      tcpSocket:
        port: number
      initialDelaySeconds: 0
      timeoutSeconds: 0
      successThreshold: 0
      failureThreshold: 0
    securityContext:
      privileged: false
  restartPolicy: [Always | Never | OnFailure]
  nodeSelector: object
  imagePullSecrets:
  - name: string
  hostNetwork: false
  Volumes:
  - name: string
    emptyDir: {}
    hostPath:
      path: string
    secret:
      secretName: string
      items:
      - key: string
        path: string
    configMap:
      name: string
      items:
      - key: string
        path: string

对 Pod 定义文件模板中各属性的详细说明

 apiVersion: v1       #必选，版本号，例如v1
 kind: Pod       #必选，Pod
 metadata:       #必选，元数据
   name: string       #必选，Pod名称
   namespace: string    #必选，Pod所属的命名空间
   labels:      #自定义标签
     - name: string     #自定义标签名字
   annotations:       #自定义注释列表
     - name: string
 spec:         #必选，Pod中容器的详细定义
   containers:      #必选，Pod中容器列表
   - name: string     #必选，容器名称
     image: string    #必选，容器的镜像名称
     imagePullPolicy: [Always | Never | IfNotPresent] #获取镜像的策略 Alawys表示下载镜像 IfnotPresent表示优先使用本地镜像，否则下载镜像，Nerver表示仅使用本地镜像
     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     #内存清楚，容器启动的初始可用数量
     livenessProbe:     #对Pod内个容器健康检查的设置，当探测无响应几次后将自动重启该容器，检查方法有exec、httpGet和tcpSocket，对一个容器只需设置其中一种方法即可
       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的重启策略，Always表示一旦不管以何种方式终止运行，kubelet都将重启，OnFailure表示只有Pod以非0退出码退出才重启，Nerver表示不再重启该Pod
     nodeSelector: obeject  #设置NodeSelector表示将该Pod调度到包含这个label的node上，以key：value的格式指定
     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的存储卷，挂载集群与定义的secre对象到容器内部
         scretname: string  
         items:     
         - key: string
           path: string
       configMap:     #类型为configMap的存储卷，挂载预定义的configMap对象到容器内部
         name: string
         items:
         - key: string
           path: string   

如果上面的详细清单记不住，可以使用如下kubectl explain工具随时查看：

#   在这里，可通过一个命令来查看每种资源的可配置项
#   kubectl explain 资源类型         查看某种资源可以配置的一级属性
#   kubectl explain 资源类型.属性     查看属性的子属性
kubectl explain pod

Pod的基本用法

在对Pod的用法进行说明之前，有必要先对Docker容器中应用的运行要求进行说明。

在使用Docker时，可以使用docker run命令创建并启动一个容器。而在Kubernetes系统中对长时间运行容器的要求是：其主程序需要一直在前台执行。如果我们创建的Docker镜像的启动命令是后台执行程序，例如Linux脚本：

nohup start.sh &

则在kubelet创建包含这个容器的Pod之后运行完该命令，即认为Pod执行结束，将立刻销毁该Pod。如果为该Pod定义了ReplicationController，则系统会监控到该Pod已经终止，之后根据RC定义中Pod的replicas副本数量生成一个新的Pod。一旦创建新的Pod，就在执行完启动命令后陷入无限循环的过程中。这就是Kubernetes需要我们自己创建的Docker镜像并以一个前台命令作为启动命令的原因。对于无法改造为前台执行的应用，也可以使用开源工具Supervisor辅助进行前台运行的功能。Supervisor提供了一种可以同时启动多个后台应用，并保持Supervisor自身在前台执行的机制，可以满足Kubernetes对容器的启动要求。关于Supervisor的安装和使用，请参考官网http://supervisord.org的文档说明。接下来对Pod对容器的封装和应用进行说明。 Pod可以由1个或多个容器组合而成。

静态Pod

静态Pod是由kubelet进行管理的仅存在于特定Node上的Pod。它们不能通过API Server进行管理，无法与ReplicationController、Deployment或者DaemonSet进行关联，并且kubelet无法对它们进行健康检查。静态Pod总是由kubelet创建的，并且总在kubelet所在的Node上运行。

创建静态Pod有两种方式：配置文件方式和HTTP方式。

配置文件方式

首先，需要设置kubelet的启动参数“–config”，指定kubelet需要监控的配置文件所在的目录，kubelet会定期扫描该目录，并根据该目录下的.yaml或.json文件进行创建操作。

假设配置目录为/etc/kubelet.d/，配置启动参数为–config=/etc/kubelet.d/，然后重启kubelet服务。

由于静态Pod无法通过API Server直接管理，所以在Master上尝试删除这个Pod时，会使其变成Pending状态，且不会被删除。

删除该Pod的操作只能是到其所在Node上将其定义文件static-web.yaml从/etc/kubelet.d目录下删除。

HTTP方式

通过设置kubelet的启动参数“–manifest-url”，kubelet将会定期从该URL地址下载Pod的定义文件，并以.yaml或.json文件的格式进行解析，然后创建Pod。其实现方式与配置文件方式是一致的。

Pod容器共享Volume

同一个Pod中的多个容器能够共享Pod级别的存储卷Volume。Volume可以被定义为各种类型，多个容器各自进行挂载操作，将一个Volume挂载为容器内部需要的目录在下面的例子中，在Pod内包含两个容器：tomcat和busybox，在Pod级别设置Volume“app-logs”，用于tomcat向其中写日志文件，busybox读日志文件。

配置文件pod-volume-applogs.yaml的内容如下：

apiVersion:v1
kind: Pod
metadata:
   name: redis-php
   label:
     name: volume-pod
spec:
   containers:
   - name: tomcat
     image: tomcat
     ports:
     - containersPort: 8080
     volumeMounts:
     - name: app-logs
       mountPath: /usr/local/tomcat/logs
     - name: busybox
       image: busybox
       command: ["sh","-C","tail -f /logs/catalina*.log"]
   volumes:
   - name: app-logs
     emptyDir:{}

这里设置的Volume名为app-logs，类型为emptyDir（也可以设置为其他类型，详见第1章对Volume概念的说明），挂载到tomcat容器内的/usr/local/tomcat/logs目录，同时挂载到logreader容器内的/logs目录。tomcat容器在启动后会向/usr/local/tomcat/logs目录写文件，logreader容器就可以读取其中的文件了。

logreader容器的启动命令为tail -f /logs/catalina*.log，我们可以通过kubectl logs命令查看logreader容器的输出内容

Pod的配置管理

应用部署的一个最佳实践是将应用所需的配置信息与程序进行分离，这样可以使应用程序被更好地复用，通过不同的配置也能实现更灵活的功能。将应用打包为容器镜像后，可以通过环境变量或者外挂文件的方式在创建容器时进行配置注入，但在大规模容器集群的环境中，对多个容器进行不同的配置将变得非常复杂。从Kubernetes 1.2开始提供了一种统一的应用配置管理方案—ConfigMap。

ConfigMap概述

ConfigMap供容器使用的典型用法如下。

生成为容器内的环境变量。
设置容器启动命令的启动参数（需设置为环境变量）。
以Volume的形式挂载为容器内部的文件或目录。 ConfigMap以一个或多个key:value的形式保存在Kubernetes系统中供应用使用，既可以用于表示一个变量的值（例如apploglevel=info），也可以用于表示一个完整配置文件的内容（例如server.xml=<?xml…>…）可以通过YAML配置文件或者直接使用kubectl create configmap命令行的方式来创建ConfigMap。

创建ConfigMap资源对象

通过YAML配置文件方式创建

下面的例子cm-appvars.yaml描述了将几个应用所需的变量定义为ConfigMap的用法：

apiVersion: v1
kind: ConfigMap
metadata:
   name: cm-appvars
data:
   apploglevel: info
   appdatadir: /var/data

执行kubectl create命令创建该ConfigMap：

kubectl create -f cm-appvars.yaml

查看创建好的ConfigMap：

kubectl get configmap
kubectl describe configmap cm-appvars
kubectl get configmap cm-appvars -o yaml

下面的例子cm-appconfigfiles.yaml描述了将两个配置文件server.xml和logging.properties定义为ConfigMap的用法，设置key为配置文件的别名，value则是配置文件的全部文本内容：

apiVersion: v1
kind: ConfigMap
metadata:
    name: cm-appvars
data:
    key-serverxml:
        <?xml Version='1.0'encoding='utf-8'?>
        <Server port="8005"shutdown="SHUTDOWN">
        .....
        </service>
        </Server>
    key-loggingproperties:
         "handlers=lcatalina.org.apache.juli.FileHandler,
         ...."

通过kubectl命令行方式创建

不使用YAML文件，直接通过kubectl create configmap也可以创建ConfigMap，可以使用参数–from-file或–from-literal指定内容，并且可以在一行命令中指定多个参数。通过–from-file参数从文件中进行创建，可以指定key的名称，也可以在一个命令行中创建包含多个key的ConfigMap，语法为：

通过–from-file参数从目录中进行创建，该目录下的每个配置文件名都被设置为key，文件的内容被设置为value，语法为：

使用–from-literal时会从文本中进行创建，直接将指定的key#=value#创建为ConfigMap的内容，语法为：

在Pod中使用ConfigMap

通过环境变量方式使用ConfigMap

通过volumeMount使用ConfigMap

使用ConfigMap的限制条件

使用ConfigMap的限制条件如下。

ConfigMap必须在Pod之前创建。
ConfigMap受Namespace限制，只有处于相同Namespace中的Pod才可以引用它。
ConfigMap中的配额管理还未能实现。
kubelet只支持可以被API Server管理的Pod使用ConfigMap。kubelet在本Node上通过 –manifest-url或–config自动创建的静态Pod将无法引用ConfigMap。
在Pod对ConfigMap进行挂载（volumeMount）操作时，在容器内部只能挂载为“目录”，无法挂载为“文件”。在挂载到容器内部后，在目录下将包含ConfigMap定义的每个item，如果在该目录下原来还有其他文件，则容器内的该目录将被挂载的ConfigMap覆盖。如果应用程序需要保留原来的其他文件，则需要进行额外的处理。可以将ConfigMap挂载到容器内部的临时目录，再通过启动脚本将配置文件复制或者链接到（cp或link命令）应用所用的实际配置目录下。

在容器内获取Pod信息（Downward API）

我们知道，每个Pod在被成功创建出来之后，都会被系统分配唯一的名字、IP地址，并且处于某个Namespace中，那么我们如何在Pod的容器内获取Pod的这些重要信息呢？答案就是使用Downward API。 Downward API可以通过以下两种方式将Pod信息注入容器内部。

环境变量：用于单个变量，可以将Pod信息和Container信息注入容器内部。
Volume挂载：将数组类信息生成为文件并挂载到容器内部。

环境变量方式：将Pod信息注入为环境变量

下面的例子通过Downward API将Pod的IP、名称和所在Namespace注入容器的环境变量中，容器应用使用env命令将全部环境变量打印到标准输出中：

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: busybox
      command: ["/bin/sh","-c","env"]
      env:
        - name: MY_POD_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
        - name: MY_POD_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        - name: MY_POD_IP
          valueFrom:
            fieldRef:
              fieldPath: status.podIP
  restartPolicy: Never

注意到上面valueFrom这种特殊的语法是Downward API的写法。目前Downward API提供了以下变量。

metadata.name：Pod的名称，当Pod通过RC生成时，其名称是RC随机产生的唯一名称。
status.podIP：Pod的IP地址，之所以叫作status.podIP而非metadata.IP，是因为Pod的IP属于状态数据，而非元数据。
metadata.namespace：Pod所在的Namespace。运行kubectl create命令创建Pod：
```
kubectl create -f dapi-test-pod.yaml
```
查看dapi-test-pod的日志： ```yaml [root@bogon ~]# kubectl logs pod/dapi-test-pod KUBERNETES_PORT=tcp://169.169.0.1:443 KUBERNETES_SERVICE_PORT=443 HOSTNAME=dapi-test-pod SHLVL=1 HOME=/root MY_POD_NAMESPACE=default MY_POD_IP=172.17.0.2 MY_POD_NAME=dapi-test-pod

从日志中我们可以看到pod的ip name namespace 等信息被正确保存到了pod的环境变量中。

### 环境变量方式：将容器资源信息注入为环境变量
下面的例子通过Downward API将Container的资源请求和限制信息注入容器的环境变量中，容器应用使用printenv命令将设置的资源请求和资源限制环境变量打印到标准输出中：
```yaml
apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod-container-vars
spec:
  containers:
    - name: test-container
      image: busybox
      imagePullPolicy: Never
      command: ["sh","-c"]
      args:
        - while true; do
           echo -en '\n';
           printenv MY_CPU_REQUEST MY_CPU_LIMIT;
           printenv MY_MEM_REQUEST MY_MEM_LIMIT;
           sleep 3600;
           done;
      resources:
        requests:
          memory: "32Mi"
          cpu: "125m"
        limits:
          memory: "64Mi"
          cpu: "250m"
      env:
      - name: MY_CPU_REQUEST
        valueFrom:
          resourceFieldRef:
            containerName: test-container
            resource: requests.cpu
      - name: MY_CPU_LIMIT
        valueFrom:
          resourceFieldRef:
            containerName: test-container
            resource: limits.cpu
      - name: MY_MEM_REQUEST
        valueFrom:
          resourceFieldRef:
            containerName: test-container
            resource: requests.memory
      - name: MY_MEM_LIMIT
        valueFrom:
          resourceFieldRef:
            containerName: test-container
            resource: limits.memory
  restartPolicy: Never

注意valueFrom这种特殊的Downward API语法，目前resourceFieldRef可以将容器的资源请求和资源限制等配置设置为容器内部的环境变量。

requests.cpu：容器的CPU请求值。
limits.cpu：容器的CPU限制值。
requests.memory：容器的内存请求值。
limits.memory：容器的内存限制值。从日志中我们可以看到Container的requests.cpu、limits.cpu、requests.memory、limits.memory等信息都被正确保存到了Pod的环境变量中。

Volume挂载方式

下面的例子通过Downward API将Pod的Label、Annotation列表通过Volume挂载为容器中的一个文件，容器应用使用echo命令将文件的内容打印到标准输出中：

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod-volume
  labels:
    zone: us-est-coast
    cluster: test-cluster1
    rack: rack-22
  annotations:
    build: two
    builder: john-doe
spec:
  containers:
    - name: test-container
      image: busybox
      imagePullPolicy: Never
      command: ["sh","-c"]
      args:
        - while true; do
            if [[ -e /etc/podinfo/labels ]]; then
              echo -en '\n\n'; cat /etc/podinfo/labels;
            fi;
            if [[ -e /etc/podinfo/annotations ]]; then
              echo -en '\n\n'; cat /etc/podinfo/annotations;
            fi;
             sleep 3600;
          done
      volumeMounts:
         - name: podinfo
           mountPath: /etc/podinfo
           readOnly: false
  volumes:
    - name: podinfo
      downwardAPI:
        items:
        - path: "lables"
          fieldRef:
            fieldPath: metadata.labels
        - path: "annotations"
          fieldRef:
            fieldPath: metadata.annotations

这里要注意“volumes”字段中downwardAPI的特殊语法，通过items的设置，系统会根据path的名称生成文件。根据上例的设置，系统将在容器内生成/etc/labels和/etc/annotations两个文件。在/etc/labels文件中将包含metadata.labels的全部Label列表，在/etc/annotations文件中将包含metadata.annotations的全部Label列表。从日志中我们看到Pod的Label和Annotation信息都被保存到了容器内的/etc/labels和/etc/annotations文件中。

那么，Downward API有什么价值呢？

在某些集群中，集群中的每个节点都需要将自身的标识（ID）及进程绑定的IP地址等信息事先写入配置文件中，进程在启动时会读取这些信息，然后将这些信息发布到某个类似服务注册中心的地方，以实现集群节点的自动发现功能。此时Downward API就可以派上用场了，具体做法是先编写一个预启动脚本或Init Container，通过环境变量或文件方式获取Pod自身的名称、IP地址等信息，然后将这些信息写入主程序的配置文件中，最后启动主程序。

Pod生命周期和重启策略

Pod在整个生命周期中被系统定义为各种状态，熟悉Pod的各种状态对于理解如何设置Pod的调度策略、重启策略是很有必要的。 Pod的状态如下:

Pending :API Server已经创建了pod，但在pod内还有一个或多个容器的镜像没有创建，包括正在下载镜像的过程
Running :pod内所有容器均已创建，且至少有一个容器处于运行状态、正在启动状态或正在重启状态
Succeeded :pod内所有容器均成功执行后退出，且不会在重启
Failed :pod内所有容器均已退出，但至少有一个容器为退出失败状态
Unknown :由于某种原因无法获取该Pod的状态，可能由于网络通信不畅导致的 Pod的重启策略（RestartPolicy）应用于Pod内的所有容器，并且仅在Pod所处的Node上由kubelet进行判断和重启操作。当某个容器异常退出或者健康检查失败时，kubelet将根据RestartPolicy的设置来进行相应的操作。 Pod的重启策略包括Always、OnFailure和Never，默认值为Always。
Always：当容器失效时，由kubelet自动重启该容器。
OnFailure：当容器终止运行且退出码不为0时，由kubelet自动重启该容器。
Never：不论容器运行状态如何，kubelet都不会重启该容器。 kubelet重启失效容器的时间间隔以sync-frequency乘以2n来计算，例如1、2、4、8倍等，最长延时5min，并且在成功重启后的10min后重置该时间。

Pod的重启策略与控制方式息息相关，当前可用于管理Pod的控制器包括ReplicationController、Job、DaemonSet及直接通过kubelet管理（静态Pod）。每种控制器对Pod的重启策略要求如下。

RC和DaemonSet：必须设置为Always，需要保证该容器持续运行。
Job：OnFailure或Never，确保容器执行完成后不再重启。
kubelet：在Pod失效时自动重启它，不论将RestartPolicy设置为什么值，也不会对Pod进行健康检查。

Pod健康检查和服务可用性检查

Kubernetes 对 Pod 的健康状态可以通过两类探针来检查：LivenessProbe 和ReadinessProbe，kubelet定期执行这两类探针来诊断容器的健康状况。

LivenessProbe探针：用于判断容器是否存活（Running状态），如果LivenessProbe探针探测到容器不健康，则kubelet将杀掉该容器，并根据容器的重启策略做相应的处理。如果一个容器不包含LivenessProbe探针，那么kubelet认为该容器的LivenessProbe探针返回的值永远是Success。
ReadinessProbe探针：用于判断容器服务是否可用（Ready状态），达到Ready状态的Pod才可以接收请求。对于被Service管理的Pod，Service与Pod Endpoint的关联关系也将基于Pod是否Ready进行设置。如果在运行过程中Ready状态变为False，则系统自动将其从Service的后端Endpoint列表中隔离出去，后续再把恢复到Ready状态的Pod加回后端Endpoint列表。这样就能保证客户端在访问Service时不会被转发到服务不可用的Pod实例上。

LivenessProbe和ReadinessProbe均可配置以下三种实现方式。

ExecAction：在容器内部执行一个命令，如果该命令的返回码为0，则表明容器健康。

在下面的例子中，通过执行“cat /tmp/health”命令来判断一个容器运行是否正常。在该Pod运行后，将在创建/tmp/health文件10s后删除该文件，而LivenessProbe健康检查的初始探测时间（initialDelaySeconds）为15s，探测结果是Fail，将导致kubelet杀掉该容器并重启它：

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
  name: web
spec:
  containers:
  - image: nginx
    name: web
    imagePullPolicy: IfNotPresent
    ports:
    - containerPort: 80
    livenessProbe:                 # "健康检查"
      exec:
        command:
        - cat
        - /tmp/health
      initialDelaySeconds: 15        "初始探测时间"
      timeoutSeconds: 1              "超时时间"
  dnsPolicy: ClusterFirst
  restartPolicy: Always
status: {}

TCPSocketAction：通过容器的IP地址和端口号执行TCP检查，如果能够建立TCP连接，则表明容器健康。

在下面的例子中，通过与容器内的localhost:80建立TCP连接进行健康检查：

HTTPGetAction：通过容器的IP地址、端口号及路径调用HTTP Get方法，如果响应的状态码大于等于200且小于400，则认为容器健康。

在下面的例子中，kubelet定时发送HTTP请求到localhost:80/_status/healthz来进行容器应用的健康检查：

对于每种探测方式，都需要设置initialDelaySeconds和timeoutSeconds两个参数，它们的含义分别如下。

◎　initialDelaySeconds：启动容器后进行首次健康检查的等待时间，单位为s。

◎　timeoutSeconds：健康检查发送请求后等待响应的超时时间，单位为s。当超时发生时，kubelet会认为容器已经无法提供服务，将会重启该容器。

Kubernetes的ReadinessProbe机制可能无法满足某些复杂应用对容器内服务可用状态的判断，所以Kubernetes从1.11版本开始，引入Pod Ready++特性对Readiness探测机制进行扩展，在1.14版本时达到GA稳定版，称其为Pod Readiness Gates。

通过Pod Readiness Gates机制，用户可以将自定义的ReadinessProbe探测方式设置在Pod上，辅助Kubernetes设置Pod何时达到服务可用状态（Ready）。为了使自定义的ReadinessProbe生效，用户需要提供一个外部的控制器（Controller）来设置相应的Condition状态。

Pod的Readiness Gates在Pod定义中的ReadinessGate字段进行设置。下面的例子设置了一个类型为www.example.com/feature-1的新Readiness Gate：

新增的自定义Condition的状态（status）将由用户自定义的外部控制器设置，默认值为False。Kubernetes将在判断全部readinessGates条件都为True时，才设置Pod为服务可用状态（Ready为True）。

玩转Pod调度

在Kubernetes平台上，我们很少会直接创建一个Pod，在大多数情况下会通过RC、Deployment、DaemonSet、Job等控制器完成对一组Pod副本的创建、调度及全生命周期的自动控制任务。

在最早的Kubernetes版本里是没有这么多Pod副本控制器的，只有一个Pod副本控制器RC（Replication Controller），这个控制器是这样设计实现的：RC独立于所控制的Pod，并通过Label标签这个松耦合关联关系控制目标Pod实例的创建和销毁，随着Kubernetes的发展，RC也出现了新的继任者——Deployment，用于更加自动地完成Pod副本的部署、版本更新、回滚等功能。

严谨地说，RC的继任者其实并不是Deployment，而是ReplicaSet，因为 ReplicaSet进一步增强了 RC标签选择器的灵活性。之前RC的标签选择器只能选择一个标签，而ReplicaSet拥有集合式的标签选择器，可以选择多个Pod标签，如下所示：

selector: 
  matchLabels: 
    tier: frontend 
  matchExpressions: 
    - {key: tier, operator: In, values: [frontend]} 

与RC不同，ReplicaSet被设计成能控制多个不同标签的Pod副本。一种常见的应用场景是，应用MyApp目前发布了v1与v2两个版本，用户希望MyApp的Pod副本数保持为3个，可以同时包含v1和v2版本的Pod，就可以用ReplicaSet来实现这种控制，写法如下：

selector: 
  matchLabels: 
    version: v2 
  matchExpressions: 
    - {key: version, operator: In, values: [v1,v2]} 

其实，Kubernetes的滚动升级就是巧妙运用ReplicaSet的这个特性来实现的，同时，Deployment也是通过ReplicaSet来实现Pod副本自动控制功能的。我们不应该直接使用底层的ReplicaSet来控制Pod副本，而应该使用管理ReplicaSet的Deployment对象来控制副本，这是来自官方的建议。

在大多数情况下，我们希望Deployment创建的Pod副本被成功调度到集群中的任何一个可用节点，而不关心具体会调度到哪个节点。但是，在真实的生产环境中的确也存在一种需求：希望某种Pod的副本全部在指定的一个或者一些节点上运行，比如希望将MySQL数据库调度到一个具有SSD磁盘的目标节点上，此时Pod模板中的NodeSelector属性就开始发挥作用了，上述MySQL定向调度案例的实现方式可分为以下两步。

把具有SSD磁盘的Node都打上自定义标签“disk=ssd”。
在Pod模板中设定NodeSelector的值为“disk: ssd”。如此一来，Kubernetes在调度Pod副本的时候，就会先按照Node的标签过滤出合适的目标节点，然后选择一个最佳节点进行调度。上述逻辑看起来既简单又完美，但在真实的生产环境中可能面临以下令人尴尬的问题。
如果NodeSelector选择的Label不存在或者不符合条件，比如这些目标节点此时宕机或者资源不足，该怎么办？
如果要选择多种合适的目标节点，比如SSD磁盘的节点或者超高速硬盘的节点，该怎么办？Kubernates引入了NodeAffinity（节点亲和性设置）来解决该需求。在真实的生产环境中还存在如下所述的特殊需求。
不同Pod之间的亲和性（Affinity）。比如MySQL数据库与Redis中间件不能被调度到同一个目标节点上，或者两种不同的Pod必须被调度到同一个Node上，以实现本地文件共享或本地网络通信等特殊需求，这就是PodAffinity要解决的问题。
有状态集群的调度。对于ZooKeeper、Elasticsearch、MongoDB、Kafka等有状态集群，虽然集群中的每个Worker节点看起来都是相同的，但每个Worker节点都必须有明确的、不变的唯一ID（主机名或IP地址），这些节点的启动和停止次序通常有严格的顺序。此外，由于集群需要持久化保存状态数据，所以集群中的Worker节点对应的Pod不管在哪个Node上恢复，都需要挂载原来的Volume，因此这些Pod还需要捆绑具体的PV。针对这种复杂的需求，Kubernetes提供了StatefulSet这种特殊的副本控制器来解决问题，在Kubernetes 1.9版本发布后，StatefulSet才可用于正式生产环境中。
在每个Node上调度并且仅仅创建一个Pod副本。这种调度通常用于系统监控相关的Pod，比如主机上的日志采集、主机性能采集等进程需要被部署到集群中的每个节点，并且只能部署一个副本，这就是DaemonSet这种特殊Pod副本控制器所解决的问题。
对于批处理作业，需要创建多个Pod副本来协同工作，当这些Pod副本都完成自己的任务时，整个批处理作业就结束了。这种Pod运行且仅运行一次的特殊调度，用常规的RC或者Deployment都无法解决，所以Kubernates引入了新的Pod调度控制器Job来解决问题，并继续延伸了定时作业的调度控制器CronJob。

与单独的Pod实例不同，由RC、ReplicaSet、Deployment、DaemonSet等控制器创建的Pod副本实例都是归属于这些控制器的，这就产生了一个问题：控制器被删除后，归属于控制器的Pod副本该何去何从？在Kubernates 1.9之前，在RC等对象被删除后，它们所创建的Pod副本都不会被删除；在Kubernates 1.9以后，这些Pod副本会被一并删除。如果不希望这样做，则可以通过kubectl命令的–cascade=false参数来取消这一默认特性：

kubectl delete replicaset my-repset --cascade=false

接下来深入理解和实践这些Pod调度控制器的各种功能和特性。

Deployment或RC：全自动调度

Deployment或RC的主要功能之一就是自动部署一个容器应用的多份副本，以及持续监控副本的数量，在集群内始终维持用户指定的副本数量。

下面是一个Deployment配置的例子，使用这个配置文件可以创建一个ReplicaSet，这个ReplicaSet会创建3个Nginx应用的Pod：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

从调度策略上来说，这3个Nginx Pod由系统全自动完成调度。它们各自最终运行在哪个节点上，完全由Master的Scheduler经过一系列算法计算得出，用户无法干预调度过程和结果。

除了使用系统自动调度算法完成一组Pod的部署，Kubernetes也提供了多种丰富的调度策略，用户只需在Pod的定义中使用NodeSelector、NodeAffinity、PodAffinity、Pod驱逐等更加细粒度的调度策略设置，就能完成对Pod的精准调度。下面对这些策略进行说明。

yangjava

深入掌握pod