应用管理要点
- 工作负载型控制器 编排 应用
- 应用时长划分
- 守护进程任务
- DaemonSet
- 作业类、周期类任务
- job
- 守护进程任务
- 状态划分
- 有状态任务
- statefulset
- 第三方专用的Operator
- 无状态任务
- ReplicaSet
- Deployment
- 有状态任务
- 系统类的应用
- DaemonSet
- 集群中的每个节点 只运行一个应用 例如node exporter
- 应用时长划分
- 卷存储
- pv pvc持久化存储
- storageclass 动态关联卷
- configmap secret提供配置管理
- pv pvc持久化存储
- service 提供访问入口
声明式API介绍
API设计方法
命令式API介绍
- 也称为指令式API,用户需要一步步地告诉机器该如何做(How),机器自身不具有任何“智能”,只被动接受指令
- 高度依赖用户自身理解和达成目标的能力和处理各类异常问题的经验,实现的是“命令式编程(Imperative Programming)”
声明式API介绍
- 声明终态 中间屏蔽掉过程 交由标准化的程序去完成
- 也称为申明式API,用户只需要告诉机器想要的结果(What),机器自身需要确定如何达成该目标
- 机器需要一定的“智能”,但通常只能支持事先预设和可被其理解的特定任务
- 实现的是“声明式编程(Declarative Programming)”
声明式API
相较于命令式编程,声明式编程是一个更高的层次上的编程
-
声明式API允许用户以给出最终期望目标的方式编写代码,但具体的执行过程(即机器智能的那部分代码),最终仍然需要以命令式编程实现,只不过,它们可由不同的人群完成
-
类比来说,声明式编程的用户类似于企业的高管,只用关心和交待最终目标;而命令式编程的用户类似于企业部门经理,他需要理解目标的达成路径,并组织人力完成目标
Kubernetes的声明式API
- 用户能够以声明式定义资源对象的目标状态(spec)
- 由控制器代码(机器智能组件)负责确保实际状态(status)与期望状态一致
- 控制器即“部门经理”,负责确保部门内的各项具体任务得以落地
- 控制器通常由API的提供者负责编写
- 用户需要做的是根据资源类型及其控制器提供的DSL进行声明式编程
控制器
Kubernetes的控制器类型
ks8内置
打包于Controller Manager中内置提供的控制器,例如Service Controller、Deployment Controller等
- 基础型、核心型控制器
- 打包运行于kube-controller-manager中
工作负载型控制器
- 无状态应用编排:ReplicaSet、Deployment
- 有状态应用编排:StatefulSet、第三方专用的Operator
- 系统级应用:DaemonSet
- 作业类应用:Job和CronJob
插件或第三方应用的专用控制器,例如Ingress插件ingress-nginx的Controller,网络插件Project Calico的Controller等
- 高级控制器,通常需要借助于基础型控制器完成其功能
- 以Pod形式托管运行于Kubernetes之上,而且这些Pod很可能会由内置的控制器所控制
控制器模型(控制回路)介绍
-
初始阶段
- Controller负责根据用户定义的 Input(目标状态)控制System
- 并生成Output(结果状态)
-
Feedback阶段
- 根据Output生成Feedback Signal(回路信号)
- 而后由Error Detector基于 Feedback Signal和 Input来判定是否存在错误
- 并在有错误时生成Error Signal 并且基于错误信号再去做动作
-
如果有Error Signal
- 将驱动Controller生成Actuating Signal
- 并控制System的行为与Input要求相同
Kubernetes Controller的控制回路介绍
-
Controller根据spec(用户期望状态),控制System生成Status
- 保存期望状态
- Status 保存的是实际的状态
-
Controller借助于Sensor持续监视System的Spec和Status
- 在每一次控制回路中 都会对二者进行比较 然后增量修正
- 并确保System的Status不断逼近或完全等同Status
Kubernetes的应用编排
定义工作负载型控制器资源对象以编排应用
- 内置的各工作负载型控制器都有对应的资源类型,控制器专用于管控其对应类型的资源对象
- 例如,Deployment控制器对应有Deployment资源类型
- 这些资源类型都是Kubernetes上标准的API资源,并遵循资源规范的通用格式
- 用户需要编排某应用时,需要事先确认好应用的运行目标模式,例如实例数据及结束条件等,并根据模式选出对应的工作负载控制器类型
- 而后根据相应控制器的资源类型的规范,编写资源配置,并提交给API Server即可
- 相应控制器监视到API Server上新建的资源后,即会运行代码确保对象实例的实际状态(Status)与期望状态(Spec)一致
注意:控制器对象仅负责确保API Server上有相应数量的符合标签选择器的Pod对象的定义,至于Pod对象的Status如何与Spec保持 一致,则要由相应节点上的kubelet负责保证 极客