第八章 资源控制器

一、什么是控制器

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

spec:

containers:

- name: myapp

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

env:

- name: GET_HOSTS_FROM

value: dns

ports:

- containerPort: 80

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

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: nginx:1.7.9

ports:

- containerPort: 80

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

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

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

Waiting for rollout to finish: 2 out of 3 new replicas have been updated...deployment "nginx-deployment" successfully rolled out

6.4查看历史 RS

6.5 Deployment 更新策略

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

6.8清理 Policy

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

链接：https://www.bilibili.com/video/av66617940/?p=24

原文地址：https://www.cnblogs.com/LiuQizhong/p/11551381.html

时间： 2024-11-08 04:00:52

第八章 资源控制器的相关文章

laravel 创建资源控制器

php artisan make:controller PhotoController --resource 如果不添加 --resource只会创建普通的控制器,反之则创建资源控制器 资源控制器图例: 原文地址:https://www.cnblogs.com/ryanLee1/p/8470008.html

laravel6.0控制器-资源控制器

控制器: 控制器用来处理业务的,不应该处理逻辑,如果是小项目可以把逻辑写到控制器里,大点的项目应该抽离出来业务处理层如下: services业务处理层:比如:获取值,验证值,异常捕获 命名规则: 控制器名:用大驼峰命名 如:HelloController: 方法名:用小驼峰 如:helloWorld(); 成员变量:小驼峰 或者 _名称 创建控制器(可以自定义目录): php artisan make:controller UserController php artisan make:cont

kubernetes(三)--资源控制器

一.控制器简介 1.1.什么是控制器 Kubernetes 中内建了很多 controller(控制器),这些相当于一个状态机,用来控制 Pod 的具体状态和行为 1.2.控制器类型 1)ReplicationController 和 ReplicaSet 2)Deployment 3)DaemonSet 4)StateFulSet 5)Job/CronJob 6)Horizontal Pod Autoscaling 二.控制器详解 2.1.ReplicationController和Repli

[连载]《C#通讯（串口和网络）框架的设计与实现》- 8.总体控制器的设计

目       录 第八章           总体控制器的设计... 2 8.1           总控制器的职能... 2 8.2           组装和释放部件... 3 8.3           事件响应... 5 8.4           小结... 9 第八章     总体控制器的设计 有了IO部分.设备驱动部分.显示部分.数据导出部分和服务组件部分等,在这些已经存在的接口上构建一个集成各部分的总控制器,协调各部分有序工作.事件响应和控制数据流向. 另外,这个总控制器还负责

Laravel之控制器

一.简介 将所有的请求处理逻辑都放在单个routes.php 中肯定是不合理的,你也许还希望使用控制器类组织管理这些行为.控制器可以将相关的 HTTP 请求封装到一个类中进行处理.通常控制器存放在app/Http/Controllers 目录中. 二.基本控制器 1.简单示例下面是一个基本控制器类的例子.所有的 Laravel 控制器应该继承自 Laravel 自带的控制器基类Controller <?php namespace App\Http\Controllers; use App\Use

理解Docker（4）：Docker 容器使用 cgroups 限制资源使用

上一篇文章将到 Docker 容器使用 linux namespace 来隔离其运行环境,使得容器中的进程看起来就像爱一个独立环境中运行一样.但是,光有运行环境隔离还不够,因为这些进程还是可以不受限制地使用系统资源,比如网络.磁盘.CPU以及内存 等.为了让容器中的进程更加可控,Docker 使用 Linux cgroups 来限制容器中的进程允许使用的系统资源. 1. 基础知识:Linux control groups 1.1 概念 Linux Cgroup 可???让???您???为???系

易元平台常用控制器总结

表单组件 1.日期相关(显示日期) form.my97.DatePicker 相关约束 {dateFmt:'yyyy-MM-dd'} 2.下拉列表相关(根据值显示列表中的某一项) form.DOStaticList 相关配置 0,未发布;1,已发布;@0 @0表示默认显示未发布 3.下拉列表相关(显示外键的列表) form.DOResultListPopup 4.组合(用于TAPane组合,通常用于表格的操作列) form.TSuite 5.常用按钮(用于关联表之前传递父表id) form.TA

HTTP层 —— 控制器

1.简介 将所有的请求处理逻辑都放在单个 routes.php 中显然是不合理的,你也许还希望使用控制器类组织管理这些行为.控制器可以将相关的 HTTP 请求封装到一个类中进行处理.通常控制器存放在 app/Http/Controllers 目录中. 2.基本控制器 定义控制器 下面是一个基本控制器类的例子.所有的 Laravel 控制器应该继承自 Laravel 自带的控制器基类 Controller,控制器基类提供了一些很方便的方法如 middleware ,用于添加中间件到控制器动作: <

第十四章 系统资源控制器

一.资源控制器的组成系统 系统资源控制器(SRC)可以创建和管理许多子系统. 一个子系统可以是一个程序或进程,或者是一组程序或进程,这些程序或进程能够独立地运行或控制系统.一个子系统作为一个单元来提供特定的功能.子服务器(Subserver)是一个属于子系统的程序或进程. 许多子系统按照某一属性组成一个子系统组(SubSystem Group),使得子系统组可以再同一时刻控制许多子进程,例如:TCP/IP.SNA服务.NIS服务.网络文件系统(NFS)都是子系统组. 子系统的通信分为IPC消息和