Kubernetes 中的控制器

时间 2020-03-18

标签 kubernetes 控制器繁體版

原文原文链接

Kubernetes 中的控制器

标签（空格分隔）： kubernetes系列vue

一：kubernetes 中控制器

二：kubernetes 类型

一：kubernetes 中控制器

1.1 什么是控制器

Kubernetes 中内建了不少 controller（控制器），这些至关于一个状态机，用来控制 Pod 的具体状态和行为

1.2 控制器类型

ReplicationController 和 ReplicaSet

Deployment

DaemonSet

StateFulSet

Job/CronJob

Horizontal Pod Autoscaling

1.2.1 ReplicationController 和 ReplicaSet

ReplicationController（RC）用来确保容器应用的副本数始终保持在用户定义的副本数，即若是有容器异常退
出，会自动建立新的 Pod 来替代；而若是异常多出来的容器也会自动回收；
在新版本的 Kubernetes 中建议使用 ReplicaSet 来取代 ReplicationController 。ReplicaSet 跟
ReplicationController 没有本质的不一样，只是名字不同，而且 ReplicaSet 支持集合式的 selector  标签

1.2.2 Deployment

Deployment 为 Pod 和 ReplicaSet 提供了一个声明式定义 (declarative) 方法，用来替代之前的
ReplicationController 来方便的管理应用。典型的应用场景包括；

定义 Deployment 来建立 Pod 和 ReplicaSet
滚动升级和回滚应用
扩容和缩容
暂停和继续 Deployment

编程：

命令式编程：它侧重于如何实现程序，就像咱们刚接触编程的时候那样，咱们须要把程序的实现过程按照逻辑结果一步步写下来

声明式编程：它侧重于定义想要什么，而后告诉计算机／引擎，让他帮你去实现
            结构化的查询语句（T-sql）

申明式编程 （Deployment）  apply（优）    create
命令式 （rs）               create（优）   apply

RS 与 RC 与 Deployment 关联:

RC （ReplicationController ）主要的做用就是用来确保容器应用的副本数始终保持在用户定义的副本数 。即如
果有容器异常退出，会自动建立新的Pod来替代；而若是异常多出来的容器也会自动回收
Kubernetes 官方建议使用 RS（ReplicaSet ） 替代 RC （ReplicationController ） 进行部署，RS 跟 RC 没有
本质的不一样，只是名字不同，而且 RS 支持集合式的 selector

vim rs-deploy.yaml
---
apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
  name: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      tier: frontend
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - name: myapp
        image: wangyanglinux/myapp:v1
        env:
        - name: GET_HOSTS_FROM
          value: dns
        ports:
        - containerPort: 80
---
kubectl apply -f rs-deploy.yaml

kubectl get pods

总结： 不少的rs 是标签来控制的 一旦 rs 被删除 pod 所对应的 定义标签 pod都会被删除

RS 与 Deployment 的关联

部署一个nginx：

vim nginx-deploy.yaml
----
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: wangyanglinux/myapp:v1
        ports:
        - containerPort: 80
---
kubectl apply -f nginx-deploy.yaml --recond 

## --record参数能够记录命令，咱们能够很方便的查看每次 revision 的变化

kubectl get pod 

kubectl get deploy

扩容方案：

kubectl scale deployment nginx-deployment --replicas 5

若是集群支持 horizontal pod autoscaling 的话，还能够为Deployment设置自动扩展

kubectl autoscale deployment nginx-deployment --min=10 --max=15 --cpu-percent=80

更新镜像也比较简单
kubectl set image deployment/nginx-deployment nginx=wangyanglinux/myapp:v2

回滚：

kubectl rollout undo deployment/nginx-deployment

详细的回滚更新操做：

kubectl set image deployment/nginx-deployment nginx=wangyanglinux:v2
kubectl rollout status deployments nginx-deployment
kubectl get pods
kubectl rollout history deployment/nginx-deployment
kubectl rollout undo deployment/nginx-deployment
kubectl rollout undo deployment/nginx-deployment --to-revision=2 ## 可使用 --revision参数指定
某个历史版本
kubectl rollout pause deployment/nginx-deployment ## 暂停 deployment 的更新

能够用 kubectl rollout status 命令查看 Deployment 是否完成。若是 rollout 成功完成， kubectl rollout
status 将返回一个0值的 Exit Code

$ kubectl rollout status deployment/nginx-deployment
Waiting for rollout to finish: 2 of 3 updated replicas are available...
deployment "nginx" successfully rolled out
$ echo $?
0

上面的 返回码，这个通常用于写脚本

清理 Policy
您能够经过设置 .spec.revisonHistoryLimit 项来指定 deployment 最多保留多少 revision 历史记录。默认的会
保留全部的 revision；若是将该项设置为0，Deployment 就不容许回退了

1.2.3 DaemonSet

DaemonSet 确保所有（或者一些）Node 上运行一个 Pod 的副本。当有 Node 加入集群时，也会为他们新增一个
Pod 。当有 Node 从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它建立的全部 Pod
使用 DaemonSet 的一些典型用法：
运行集群存储 daemon，例如在每一个 Node 上运行  glusterd 、 ceph
在每一个 Node 上运行日志收集 daemon，例如 fluentd 、 logstash
在每一个 Node 上运行监控 daemon，例如 Prometheus Node Exporter、 collectd 、Datadog 代理、
New Relic 代理，或 Ganglia  gmond

守护进程 方案

vim daemonset.yaml
----
apiVersion: apps/v1
kind: DaemonSet
metadata:
 name: deamonset-example
 labels:
   app: daemonset
spec:
  selector:
    matchLabels:
      name: deamonset-example
  template:
    metadata:
      labels:
        name: deamonset-example
    spec:
      containers:
      - name: daemonset-example
        image: wangyanglinux/myapp:v1
----
kubectl apply -f daemonset.yaml

kubectl get daemonset

kubectl delete daemonset --all

1.2.4 Job

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

特殊说明:

spec.template格式同Pod

RestartPolicy仅支持Never或OnFailure

单个Pod时，默认Pod成功运行后Job即结束

.spec.completions 标志Job结束须要成功运行的Pod个数，默认为1

.spec.parallelism 标志并行运行的Pod的个数，默认为1

spec.activeDeadlineSeconds 

标志失败Pod的重试最大时间，超过这个时间不会继续重试

上传 镜像 Perl.tar.gz 到所有节点 

tar -zxvf Perl.tar.gz
docker load -i perl.tar 

docker tag perl:latest perl:v1

--------------------

vim job.yaml
----
apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    metadata:
      name: pi
    spec:
      containers:
      - name: pi
        image: perl:v1
        command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never
---
查看日志 表示 运行计算pi 的2000

kubectl apply -f job.yaml

1.2.5 CronJob

Cron Job 管理基于时间的 Job，即：
在给定时间点只运行一次
周期性地在给定时间点运行

使用前提条件：

**当前使用的 Kubernetes 集群，版本 >= 1.8（对 CronJob）。对于先前版本的集群，版本 <1.8，启动 API Server时，经过传递选项  --runtime-config=batch/v2alpha1=true  能够开启 batch/v2alpha1
API**

典型的用法以下所示：
在给定的时间点调度 Job 运行
建立周期性运行的 Job，例如：数据库备份、发送邮件

CronJob Spec:
spec.template格式同Pod
RestartPolicy仅支持Never或OnFailure
单个Pod时，默认Pod成功运行后Job即结束
.spec.completions 标志Job结束须要成功运行的Pod个数，默认为1
.spec.parallelism 标志并行运行的Pod的个数，默认为1
spec.activeDeadlineSeconds 标志失败Pod的重试最大时间，超过这个时间不会继续重试

.spec.schedule ：调度，必需字段，指定任务运行周期，格式同 Cron

.spec.jobTemplate ：Job 模板，必需字段，指定须要运行的任务，格式同 Job

.spec.startingDeadlineSeconds ：启动 Job 的期限（秒级别），该字段是可选的。若是由于任何缘由而错
过了被调度的时间，那么错过执行时间的 Job 将被认为是失败的。若是没有指定，则没有期限

.spec.concurrencyPolicy ：并发策略，该字段也是可选的。它指定了如何处理被 Cron Job 建立的 Job 的
并发执行。只容许指定下面策略中的一种：
   Allow （默认）：容许并发运行 Job
   Forbid ：禁止并发运行，若是前一个尚未完成，则直接跳过下一个
   Replace ：取消当前正在运行的 Job，用一个新的来替换
注意，当前策略只能应用于同一个 Cron Job 建立的 Job。若是存在多个 Cron Job，它们建立的 Job 之间总
是容许并发运行。

.spec.suspend ：挂起，该字段也是可选的。若是设置为  true ，后续全部执行都会被挂起。它对已经开始
执行的 Job 不起做用。默认值为  false 。

.spec.successfulJobsHistoryLimit 和  .spec.failedJobsHistoryLimit ：历史限制，是可选的字段。它
们指定了能够保留多少完成和失败的 Job。默认状况下，它们分别设置为  3 和  1 。设置限制的值为  0 ，相
关类型的 Job 完成后将不会被保留。

vim 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 Kubernetes cluster
          restartPolicy: OnFailure

----
kubectl apply -f cronjob.yaml

kubectl get cronjob

kubectl get job

1.2.6 StatefulSet

StatefulSet 做为 Controller 为 Pod 提供惟一的标识。它能够保证部署和 scale 的顺序

StatefulSet是为了解决有状态服务的问题（对应Deployments和ReplicaSets是为无状态服务而设计），其应用场景包括：

 1.稳定的持久化存储，即Pod从新调度后仍是能访问到相同的持久化数据，基于PVC来实现

2. 稳定的网络标志，即Pod从新调度后其PodName和HostName不变，基于Headless 
Service（即没有Cluster IP的Service）来实现

3. 有序部署，有序扩展，即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次依次进行（即从0到N-1，在下一个Pod运行以前全部以前的Pod必须都是Running和Ready状态），基于init containers来实现

4. 有序收缩，有序删除（即从N-1到0）

1.2.7 Horizontal Pod Autoscaling

应用的资源使用率一般都有高峰和低谷的时候，如何削峰填谷，提升集群的总体资源利用率，让service中的Pod
个数自动调整呢？这就有赖于Horizontal Pod Autoscaling了，顾名思义，使Pod水平自动缩放