CH02_资源_03_Pod控制器_20190919

Pod类型：

1. 自主式 Pod：无管理者，Pod退出了，此类型的Pod不会被创建
2. 控制器管理的 Pod：在控制器的生命周期里，始终要维持 Pod的副本数目

控制器：

         Kubernetes中内建了许多contoller(控制器)，这些相当于一个状态机，用来控制Pod的具体状态和行为

控制器类型:

1. ReplicaSet和ReplicationController（废除）
2. Deployment
3. DaemonSet
4. StateFulSet
5. Job/CronJob
6. Horizontal Pod Autoscaling

1.ReplicaSet

rs支持应用容器的副本数目始终保持在用户定义的副本数。创建新的Pod来替代异常退出的Pod。异常多出来的容器自动回收。
rs和rc没有本质的不同，rs支持集合式的selector；rs通过标签Labels（matchLabels）选择与控制

RS与Deployments的关联：deployment通过修改rs的创建来管理对应的Pod，以及通过rs版本的的交替来完成滚动更新

示例：Example006：
/root/yaml/001_pod_rs_deployment_svc/006_rs.yaml

apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata: 
  name: frontend1
spec:
  replicas: 3
  selector:
    matchLabels:
      tier: frontend
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        imagePullPolicy: IfNotPresent
        env:
        - name: GET_HOSTS_FROM
          value: dns
        ports:
        - containerPort: 80

2.Deployment

为Pod和ReplicaSet提供一个声明式定义（declarative）方法，用来替代以前的ReplicationCotroller来方便的管理应用。典型的应用场景包括：

1. 定义Deployment来创建Pod和ReplicaSet
2. 滚动升级和回滚应用
3. 扩容和缩容
4. 暂停和继续更新 Deployment

命令式编程：它侧重于如何实现 create rs
声明式编程：它侧重于结果 apply Deployment

示例：Example007：
/root/yaml/001_pod_rs_deployment_svc/007_deployment.yaml

apiVersion: extensions/v1beta1
kind: Deployment
metadata: 
  name: nginx-deployment
spec:
  replicas: 3
  template: 
    metadata: 
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80

1. --record可以记录命令，方便查看每次revision的变化，用于回滚
   # kubectl apply -f deployment.yaml --record
2. 扩容：
   kubectl scale deployment nginx-deployment --replicas 10
3. 如果集群支持HPA的话，还可以为Deployment设置自动扩展
4. 更新镜像  策略：默认1-1，未来25%-25% ，可以在yaml模版中定义新策略
   # kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
   # kubectl set image deployment/nginx-deployment nginx=httpd:latest
   Deployment更新策略 # kubectl describe deployments
   rollover（多个rollout并行）
   v1版本创建了一半，开始升级至v2版，直接杀死v1版的所有pod，并创建v2版本的Pod
5. 回滚
   # kubectl rollout history deployment/nginx-deployment                       //查看历史版本
   # kubectl rollout undo deployment/nginx-deployment                         //回滚至上一个版本
   # kubectl rollout undo deployment/nginx-deployment --to-revision=2 //回滚到指定版本
   # kubectl rollout status deployment/nginx-deployment                       //查看回滚/更新状态，是否更新完成。
   # echo $?                                                                                           //Exit Code 退出码为0 ，更新成功
   # kubectl rollout pause deployment/nginx-deployment                        //暂停deployment的更新Deployment.spec.revisionHistoryLimit 可以指定revision历史记录的条数， 默认全保留， 0则不保留历史版本。这同rs版本的数量一致

3.DaemonSet

DaemonSet确定全部Node（注意：污点和容忍）上运行一个Pod的副本。新node加入集群，也会为其创建一个Pod。当有Node从集群移除时，这些Pod也会被回收。
删除DaemonSet将会删除它创建的所有Pod
典型用法：

1. 运行集群存储daemon，例如在每个Node上运行 glusterd、ceph
2. 在每个Node上运行日志收集daemon，例如fluentd、logstash
3. 在每个Node上运行监控daemon，例如 Prometheus Node Exporter、collectd、Datadog代理、New Relic代理，或Ganglia gmond

示例：Example008：
/root/yaml/001_pod_rs_deployment_svc/008_DaemonSet.yaml

apiVersion: apps/v1
kind: DaemonSet
metadata: 
  name: daemonset-example
  labels:
    app: daemonset
spec:
  selector:
    matchLabels:
      name: daemonset-example
  template:
    metadata:
      labels:
        name: daemonset-example
    spec:
      containers:
      - name: daemonset-example
        image: httpd:latest

4.Job（执行脚本）

job负责批处理任务，即仅执行一次的任务，它保证批处理任务的一个或多个Pod成功结束

Job Spec 特殊说明

1. RestartPolicy仅支持Never或OnFailure
2. 单个Pod时，默认Pod成功运行后Job即结束
3. .spec.completions 标志Job结束需要成功运行的Pod个数，默认为1
4. .spec.parallelism 标志并行运行的Pod的个数，默认为1
5. .spec.activeDeadlineSeconds 标志失败Pod的重试最大时间，超过这个时间不会继续重试

示例：Example009：
/root/yaml/001_pod_rs_deployment_svc/009_job.yaml

apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    metadata:
      name: pi
    spec:
      containers:
      - name: pi
        image: perl
        command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never

5.CronJob（版本>=1.8）

CronJob管理基于时间的Job（分 时 日 月 周 ，同crontab）

典型用法：

1. 指定时间点调度Job运行
2. 周期性的运行Job，例如：数据库备份、发邮件

CronJob Spec 特殊说明：（同Job Spec）

1. RestartPolicy仅支持Nerver或者OnFailure
2. 单个Pod时，默认Pod成功运行后Job即结束
3. .spec.completions 标志Job结束需要成功运行的Pod个数，默认为1
4. .spec.parallelism 标志并行运行的Pod的个数，默认为1
5. .spec.activeDeadlineSeconds 标志失败Pod的重试最大时间，超过这个时间不会继续重试

重点字段：

1. .spec.schedule: 调度，必需字段，指定任务运行周期，格式同cron
2. .spec.jobTemplate: Job模版，必需字段，指定需要运行的任务，格式同Job
3. .spec.startingDeadlineSeconds: 启动Job的期限（秒级别），该字段是可选的。如果因为任何原因错过了被调度的时间，那么错过执行时间的Job将被认为是失败的。如果没有指定，则没有期限
4. .spec.concurrencyPolicy: 并发策略，可选字段。它指定了如何处理被Cron Job创建的Job的并发执行。只允许指定下面策略中的一种：                                                                                                                                                                                        Allow（默认）：允许并发运行Job
           Forbid：禁止并发执行，如果前一个还没有完成，则直接跳过下一个
           Replace：取消当前正在运行的Job，用一个新的来替换。
           注意：当前策略只能用于同一个CronJob创建的Job。如果存在多个CronJob，它们创建的Job之间总是允许并发。
5. spec.suspend: 挂起，可选字段。如果设置为true，后续所有执行都会被挂起。它对已经开始执行的Job不起作用。默认值为false
6. spec.successfulJobHistoryLimit和.spec.failedJobsHistoryLimit:历史限制，可选字段。他们指定了可以保留多少完成和失败的Job。默认情况下，他们分别设置为3和1。设置限制的值为 0，相关类型的Job完成后将不会被保留。

CronJob限制:

1. cronJob创建Job操作应该是 幂等的
2. cronJob定期运行Job。Job的运行结果运行状态 并不返回给cronJob

示例：Example010：
注意：删除cronjob的时候不会自动删除job。需要独立删除 # kubectl delete job
/root/yaml/001_pod_rs_deployment_svc/010_cronJob.yaml

apiVersion: batch/v1beta1
kind: CronJob
metadata: 
  name: hello
spec: 
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox
            args:
            - /bin/sh
            - -c
            - date; echo Hello from the Kubernnetes cluster
          restartPolicy: OnFailure

 

6.StatefulSet

• 与Deployments和ReplicaSets是无状态服务的设计不同，StatefulSet是为了解决有状态服务的问题
• 需要借助到存储 PV-PVC
• StatefulSet为Pod提供唯一的标识。它可以保证部署和scale的顺序，保证存储的稳定连接

应用场景：

1. 稳定的持久化存储，即Pod重新调度后还是能访问到相同的持久化数据，基于PVC来实现。 稳定的mongodb，mysql不稳定
2. 稳定的网络标志，即Pod重新调度后其PodName和HostName不变，基于Headless Service（即没有Cluster IP的Service）来实现
3. 有序部署，有序扩展，即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次进行（即如 mysql->tomcat -> nginx, 在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态），基于init containers来实现
4. 有序收缩，有序删除（即 nginx->tomcat->mysql）

示例在 pv-pvc 处介绍

7.Horizontal Pod Autoscaling

hpa管理deployment，实现Pod的水平自动扩容和缩容，提高集群的整体资源利用率。需要借助到资源收集模块metrics-server。示例在资源收集模块处介绍