Pod控制器

kubelet是k8s集群节点代理程序，它在每个工作节点上都运行着一个实例。因而，集群中的某工作节点发生故障时，其kubelet也必将不再可用，于是，节点上的Pod资源的健康状态将无从得到保证，也无法再由kubelet重启。此种场景中的Pod存活性一般要由工作节点之外的Pod控制器来保证。事实上，遭到意外删除的Pod资源的恢复也依赖于其控制器。

Pod控制器由master的kube-controller-manager组件提供，常见的此类控制器由Replication、Controller、ReplicaSet、Deployment、、DaemonSet、StatefulSet、Job和CronJob等，它们分别以不同的方式管理Pod资源对象。

1.关于Pod控制器

我们可以把API Server类比成一个存储对象的数据库系统，它向客户端提供了API，并负责存储由用户创建的各种资源对象，至于各对象的当前状态如何才能符合用户期望的状态，则需要交由另一类称为控制器的组件来负责完成。创建完成后，每一个控制器对象都可以通过内部的和解循环(reconciliation loop),不间断地监控着由其负责的所有资源并确保其处于或不断地逼近用户定义的目标状态。

1.1 Pod控制器概述

Master的各组件中，API Server仅负责将资源存储于etcd中，并将其变动通知给各相关的客户端程序，如kubelet、kube-scheduler、kube-proxy和kube-controller-manager等，kube-scheduler监控到处于未绑定状态的Pod对象出现时遂启动调度器为其挑选适配的工作节点，然而，k8s的核心功能之一还在于要确保各资源对象的当前状态(status)以匹配用户期望的状态(spec)，使当前状态不断地向期望状态”和解”(reconciliation)来完成容器应用管理，而这些则是kube-controller-manager的任务。

List-Watch是k8s实现的核心机制之一，在资源对象的状态发生变动时，由API Server负责写入etcd并通过水平触发(level-triggered)机制主动通知给相关的客户端程序以确保其不会错过任何一个事件。控制器通过API Server的watch接口实时监控目标资源对象的变动并执行和解操作，但并不会与其他控制器进行任何交互，彼此之间根本就意识不到对方的存在。

1.2 控制器与Pod对象

Pod控制器资源通过持续性地监控集群中运行着的Pod资源对象来确保其管控的资源严格符合用户期望的状态，例如资源副本的数量要精确符合期望等。通常，一个Pod控制资源至少应该包含三个基本的组成部分：

• 标签选择器：匹配并关联Pod资源对象，并据此完成受其管控的Pod资源计数；
• 期望的副本数：期望在集群中精确运行着的Pod资源的对象数量；
• Pod模版：用于新建Pod资源对象的Pod模版资源；

1.3 Pod模版资源

PodTemplate是k8s API的常用资源类型，常用于为控制器指定自动创建Pod资源对象时所需的配置信息。因为要内嵌于控制器中使用，所以Pod模版的配置信息中不需要apiVersion和kind字段，但除此之外的其他内容与定义自主式Pod对象所支持的字段几乎完全相同，这包括metadata和spec及其内嵌的其他各个字段。Pod控制器类资源的spec字段通常都要内嵌replicas、selector和template字段，其中template即为Pod模版的定义。下面是一个定义在ReplicaSet资源中的模版资源示例：

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: rs-example
spec:
  replicas: 2
  selector:
    matchLabels:
      app: rs-demo
  template:
    metadata:
      labels:
        app: rs-demo
    spec:
      containers:
      - name: myapp
        image: ikubernetes/myapp:v1
        ports:
        - name: http
          containerPort: 80

如上示例中，spec.template字段在定义时仅给出了metadata和spec两个字段，它们的使用方法与自主式Pod资源完全相同。

2.ReplicationController和ReplicaSet

ReplicationController 用来确保容器应用的副本数始终保持在用户定义的副本数，即如果有容器异常退出，会自动创建新的 Pod 来替代；而如果异常多出来的容器也会自动回收。

在新版本的 Kubernetes 中建议使用 ReplicaSet 来取代 ReplicationController。ReplicaSet 跟 ReplicationController 没有本质的不同，只是名字不一样，并且 ReplicaSet 支持集合式的 selector。

虽然 ReplicaSet 可以独立使用，但一般还是建议使用 Deployment 来自动管理 ReplicaSet，这样就无需担心跟其他机制的不兼容问题（比如 ReplicaSet 不支持 rolling-update 但 Deployment 支持）。

ReplicaSet 示例：

apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
  name: frontend
  # these labels can be applied automatically
  # from the labels in the pod template if not set
  # labels:
    # app: guestbook
    # tier: frontend
spec:
  # this replicas value is default
  # modify it according to your case
  replicas: 3
  # selector can be applied automatically
  # from the labels in the pod template if not set,
  # but we are specifying the selector here to
  # demonstrate its usage.
  selector:
    matchLabels:
      tier: frontend
    matchExpressions:
      - {key: tier, operator: In, values: [frontend]}
  template:
    metadata:
      labels:
        app: guestbook
        tier: frontend
    spec:
      containers:
      - name: php-redis
        image: gcr.io/google_samples/gb-frontend:v3
        resources:
          requests:
            cpu: 100m
            memory: 100Mi
        env:
        - name: GET_HOSTS_FROM
          value: dns
          # If your cluster config does not include a dns service, then to
          # instead access environment variables to find service host
          # info, comment out the 'value: dns' line above, and uncomment the
          # line below.
          # value: env
        ports:
        - containerPort: 80

3.Deployment 控制器

Deploymen是K8s控制器的又一种实现，它构建于ReplicaSet控制器之上，可为Pod和ReplicaSet资源提供声明式更新。相比较而言，Pod和ReplicaSet是较低级别的资源，它们很少被直接使用。

相比较于手动创建和管理Pod资源来说，Deployment能够实现以下功能：

• 确保Pod资源对象的数量精确反映期望值：Deploy需要确保由其控制运行的Pod副本数量精确吻合配置中定义的期望值，否则就会自动补足所缺或终止所余；
• 确保Pod健康运行：探测到由其管控的Pod对象因其所在的工作节点故障而不可用时，自动请求由调度器于其他工作节点创建缺失的Pod副本；
• 弹性伸缩：业务规模可以在波峰或波谷期间，可以通过Deploy控制器动态调整相关Pod资源对象的数量。此外，在必要时还可以通过HPA(HroizontalPodAutoscaler)控制器实现Pod资源规模的自动伸缩；
• 事件和状态查看：必要时可以查看Deploy对象升级的详细进度和状态；
• 回滚：升级操作完成后发现问题时，支持使用回滚机制将应用返回到前一个或由用户指定的历史记录中的版本上；
• 版本记录：对Deploy对象的每一次操作都予以保存，以供后续可能执行的回滚操作使用；
• 暂停和启动：对于每一次升级，都能够随时暂停和启动；
• 多种自动更新方案：一是Recreate，即重建更新机制，全面停止、删除旧有的Pod后用新版本替代；另一个是RollingUpdata,即滚动升级机制，逐步替换旧有的Pod至新的版本；

3.1 创建Deployment

类似于Pod资源，创建Deployment控制对象同意可以使用YAML或JSON格式的清单文件定义其配置，它也由kind、apiVersion、metadata、spec和status这5个一级字段组成，其中status为只读字段，因此在清单文件中配置的仅为前4个字段。它的spec字段一般嵌套使用以下几个属性字段：

• replicas : 期望的Pod对象副本数；
• selector