标签：网络   日志收集   runtime   ado   监控   select   exporter   exp   lov   

四 资源控制器

一、什么是控制器

Kubernetes 中内建了很多 controller（控制器），这些相当于一个状态机，用来控制 Pod 的具体状态和行为

二、控制器类型

①　ReplicationController 和 ReplicaSet

②　Deployment

③　DaemonSet

④　StateFulSet

⑤　Job/CronJob

⑥　Horizontal Pod Autoscaling

1、ReplicationController 和 ReplicaSet

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

2、Deployment（首选）

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

①　定义 Deployment 来创建 Pod 和 ReplicaSet

②　滚动升级和回滚应用

③　扩容和缩容

④　暂停和继续 Deployment

滚动更新：会创建一个新副本的rs1，旧的rs的pod减少一个时，rs1会新加一个，直到全部增减完成

 回滚：同理，需要恢复旧的rs时，会启动rs，再进行增减操作

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

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

4、CronJobCron Job

管理基于时间的 Job，即：

• 在给定时间点只运行一次
• 周期性地在给定时间点运行

使用前提条件：**当前使用的 Kubernetes 集群，版本 >= 1.8（对 CronJob）。对于先前版本的集群，版本 <1.8，启动 API Server时，通过传递选项--runtime-config=batch/v2alpha1=true可以开启 batch/v2alpha1API**

典型的用法如下所示：

在给定的时间点调度 Job 运行

创建周期性运行的 Job，例如：数据库备份、发送邮件

5、StatefulSet

StatefulSet 作为 Controller 为 Pod 提供唯一的标识。它可以保证部署和 scale 的顺序

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

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

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

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

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

6、Horizontal Pod Autoscaling(HPA )

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

二、控制器实例

1、RS 与 RC 与 Deployment 关联RC （ReplicationController ）

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

Kubernetes 官方建议使用 RS（ReplicaSet ）替代 RC （ReplicationController ）进行部署，RS 跟 RC 没有本质的不同，只是名字不一样，并且 RS 支持集合式的 selector

查看RS完整模板信息：kubectl explain rs

RS创建模板

apiVersion: extensions/v1beta1

kind: ReplicaSet

metadata:

  name: frontend

spec:

  replicas: 3

  selector:

    matchLabels:

      tier: frontend

  template:

    metadata:

      labels:

        tier: frontend  #RS通过labels来获知哪些POD是属于其自己的副本数，即如果POD的lebels发生改变就会增加一个原标签的POD

    spec:

      containers:

      - name: myapp

        image: hub.lqz.com/library/nginx:latest

        env:

        - name: GET_HOSTS_FROM

          value: dns

        ports:

        - containerPort: 80

资源控制器所创建的pod，删除后会被新建

kubectl label pod frontend-8lhvb tier=frontend1 --overwrite=True  修改标签

kubectl get pod --show-labels  查看标签

2、RS 与 Deployment 的关联

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

①　定义Deployment来创建Pod和ReplicaSet

②　滚动升级和回滚

③　应用扩容和缩容

④　暂停和继续Deployment

三、部署一个简单的 Nginx 应用

1、创建

kubectl apply -f deployment.yaml --record

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 create -f https://kubernetes.io/docs/user-guide/nginx-deployment.yaml --record

## --record参数可以记录命令，我们可以很方便的查看每次 revision 的变化

创建Deployment会创建一个rs，其中rs的名称会作为POD的标签存储在POD的LABELS中如下图，其中nginx是Deployment中写入的POD标签

2、扩容

kubectl scale deployment nginx-deployment --replicas 10

3、如果集群支持 horizontal pod autoscaling 的话，还可以为Deployment设置自动扩展

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

4、更新镜像也比较简单

kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1

其中nginx是Deployment中的容器名称，后面是镜像与版本

镜像的更新会导致rs的创建，POD的IP会变化

5、回滚

kubectl rollout undo deployment/nginx-deployment

注意是回滚到上一个版本

6、更新 Deployment

6.1假如我们现在想要让 nginx pod 使用nginx:1.9.1的镜像来代替原来的nginx:1.7.9的镜像

kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1deployment "nginx-deployment" image updated

6.2可以使用edit命令来编辑 Deployment

kubectl edit deployment/nginx-deploymentdeployment "nginx-deployment" edited

6.3查看 rollout 的状态

kubectl rollout status deployment/nginx-deployment

6.4查看历史 RS

6.5 Deployment 更新策略

• Deployment 可以保证在升级时只有一定数量的 Pod 是 down 的。默认的，它会确保至少有比期望的Pod数量少一个是up状态（最多一个不可用）
• Deployment 同时也可以确保只创建出超过期望数量的一定数量的 Pod。默认的，它会确保最多比期望的Pod数量多一个的 Pod 是 up 的（最多1个 surge ）
• 未来的 Kuberentes 版本中，将从1-1变成25%

6.6Rollover（多个rollout并行）

假如您创建了一个有5个niginx:1.7.9 replica的 Deployment，但是当还只有3个nginx:1.7.9的 replica 创建出来的时候您就开始更新含有5个nginx:1.9.1 replica 的 Deployment。在这种情况下，Deployment 会立即杀掉已创建的3个nginx:1.7.9的 Pod，并开始创建nginx:1.9.1的 Pod。它不会等到所有的5个nginx:1.7.9的Pod 都创建完成后才开始改变航道

6.7回退 Deployment

kubectl set image deployment/nginx-deployment nginx=nginx:1.91
kubectl rollout status deployments nginx-deployment
kubectl get pods
kubectl rollout undo deployment/nginx-deployment

kubectl rollout history deployment/nginx-deployment

kubectl rollout undo deployment/nginx-deployment --to-revision=2 ## 可以使用 --revision参数指定某个历史版本,revision参数在上面命令可以查看到 kubectl rollout pause deployment/nginx-deployment ## 暂停 deployment 的更新

6.8清理 Policy

您可以通过设置.spec.revisonHistoryLimit项来指定 deployment 最多保留多少 revision 历史记录。默认的会保留所有的 revision；如果将该项设置为0，Deployment 就不允许回退了

kubectl create -f https://kubernetes.io/docs/user-guide/nginx-deployment.yaml --record## --record参数可以记录命令，我们可以很方便的查看每次 revision 的变化

Kubernetes学习（四）

标签：网络   日志收集   runtime   ado   监控   select   exporter   exp   lov   

原文地址：https://www.cnblogs.com/lovedairan/p/12274187.html