Kubernetes 系列(五):deployment
k8s的控制器类型
- 控制器又被称为工作负载,pod通过控制器实现应用的运维,比如伸缩、升级等
- Kubernetes中内建了很多controller(控制器),这些相当于一个状态机,用来控制Pod的具体状态和行为
1、deployment:适合无状态的服务部署
2、StatefullSet:适合有状态的服务部署
3、DaemonSet:一次部署,所有的node节点都会部署,例如一些典型的应用场景:
- 运行集群存储 daemon,例如在每个Node上运行 glusterd、ceph
- 在每个Node上运行日志收集 daemon,例如 fluentd、 logstash
- 在每个Node上运行监控 daemon,例如 Prometheus Node Exporter
4、Job:一次性的执行任务
5、Cronjob:周期性的执行任务
Deployment控制器
Deployment实现了Pod 的“水平扩展 / 收缩”(horizontal scaling out/in),适合部署无状态的应用服务,用来管理pod和replicaset,具有上线部署、副本设定、滚动更新、回滚等功能,还可提供声明式更新,例如只更新一个新的Image。
Deployment如何控制pod
这些控制器被统一放在 kubernetes/pkg/controller 目录下,因为它们都遵循 Kubernetes 项目中的一个通用编排模式,即:控制循环(control loop)。
比如,现在有一种待编排的对象 X,它有一个对应的控制器。
那么,我就可以用一段 Go 语言风格的伪代码,为你描述这个控制循环:
for {
实际状态 := 获取集群中对象X的实际状态(Actual State)
期望状态 := 获取集群中对象X的期望状态(Desired State)
if 实际状态 == 期望状态{
什么都不做
} else {
执行编排动作,将实际状态调整为期望状态
}
}
在具体实现中,实际状态往往来自于 Kubernetes 集群本身。比如,kubelet 通过心跳汇报的容器状态和节点状态,或者监控系统中保存的应用监控数据,或者控制器主动收集的它自己感兴趣的信息,这些都是常见的实际状态的来源。
而期望状态,一般来自于用户提交的 YAML 文件。比如,Deployment 对象中 Replicas 字段的值。很明显,这些信息往往都保存在 Etcd 中。
接下来,以 Deployment 为例,我和你简单描述一下它对控制器模型的实现:
- Deployment 控制器从 Etcd 中获取到所有携带了“app: nginx”标签的 Pod,然后统计它们的数量,这就是实际状态;
- Deployment 对象的 Replicas 字段的值就是期望状态;Deployment 控制器将两个状态做比较,然后根据比较结果,确定是创建 Pod,还是删除已有的 Pod。
- 可以看到,一个 Kubernetes 对象的主要编排逻辑,实际上是在第三步的“对比”阶段完成的。这个操作,通常被叫作调谐(Reconcile)。这个调谐的过程,则被称作“Reconcile Loop”(调谐循环)或者“Sync Loop”(同步循环)。
Deployment依赖ReplicaSet控制pod
当你更新了yaml模板中关于容器的相关配置(比如,修改了容器的镜像),那么 Deployment 就需要遵循一种叫作“滚动更新”(rolling update)的方式,来升级现有的容器。
而这个能力的实现,依赖的是 Kubernetes 项目中的一个非常重要的概念(API 对象):ReplicaSet。
在你通过yaml创建(API 对象)ReplicaSet的 Metadata 里,都有一个字段叫作 ownerReference,用于保存当前这个 API 对象的拥有者(Owner)的信息。
这个ownerReference的go 结构体定义如下:
1 // OwnerReference contains enough information to let you identify an owning
2 // object. Currently, an owning object must be in the same namespace, so there
3 // is no namespace field.
4 type OwnerReference struct {
5 // API version of the referent.
6 APIVersion string `json:"apiVersion" protobuf:"bytes,5,opt,name=apiVersion"`
7 // Kind of the referent.
8 // More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#types-kinds
9 Kind string `json:"kind" protobuf:"bytes,1,opt,name=kind"`
10 // Name of the referent.
11 // More info: http://kubernetes.io/docs/user-guide/identifiers#names
12 Name string `json:"name" protobuf:"bytes,3,opt,name=name"`
13 // UID of the referent.
14 // More info: http://kubernetes.io/docs/user-guide/identifiers#uids
15 UID types.UID `json:"uid" protobuf:"bytes,4,opt,name=uid,casttype=k8s.io/apimachinery/pkg/types.UID"`
16 // If true, this reference points to the managing controller.
17 // +optional
18 Controller *bool `json:"controller,omitempty" protobuf:"varint,6,opt,name=controller"`
19 // If true, AND if the owner has the "foregroundDeletion" finalizer, then
20 // the owner cannot be deleted from the key-value store until this
21 // reference is removed.
22 // Defaults to false.
23 // To set this field, a user needs "delete" permission of the owner,
24 // otherwise 422 (Unprocessable Entity) will be returned.
25 // +optional
26 BlockOwnerDeletion *bool `json:"blockOwnerDeletion,omitempty" protobuf:"varint,7,opt,name=blockOwnerDeletion"`
27 }
如果有如下yaml文件:
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
apiVersion: apps/v1beta2 kind: Deployment metadata: name: nginx-deployment spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.10 ports: - containerPort: 80
我们可以用一张图把它描述出来:通过这张图,我们就很清楚地看到,一个定义了 replicas=3 的 Deployment,与它的 ReplicaSet,以及 Pod 的关系,实际上是一种“层层控制”的关系。
Deployment 控制器实际操纵的,是 ReplicaSet 对象,而不是 Pod 对象。
定义Deployment来创建Pod和ReplicaSet
创建一个yaml文件:nginx-deployment.yaml
apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment labels: app: nginx spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.7.9 ports: - containerPort: 80
创建deployment,–-record 参数。它的作用,是记录下你每次操作所执行的命令,以方便后面查看。
kubectl create -f nginx-deployment.yaml --record
通过标签查找Pod
kubectl get pod -l app=nginx
查看deployment,可以实时查看pod的创建状态
kubectl get deployments
在返回结果中,我们可以看到四个状态字段,它们的含义如下所示。
DESIRED:用户期望的 Pod 副本个数(spec.replicas 的值);
CURRENT:当前处于 Running 状态的 Pod 的个数;
UP-TO-DATE:当前处于最新版本的 Pod 的个数,所谓最新版本指的是 Pod 的 Spec 部分与 Deployment 里 Pod 模板里定义的完全一致;
AVAILABLE:当前已经可用的 Pod 的个数,即:既是 Running 状态,又是最新版本,并且已经处于 Ready(健康检查正确)状态的 Pod 的个数。
可以看到,只有这个 AVAILABLE 字段,描述的才是用户所期望的最终状态。
查看Deployment 所控制的 ReplicaSet
kubectl get rs
注意:Replica Set的名字总是<Deployment的名字>-<pod template的hash值>。
describe检查
kubectl describe deployment/nginx-deployment
实时查看 Deployment 对象的状态变化
kubectl rollout status deployment/nginx-deployment
创建一个Service对象,暴露Deployment端口,给外网访问
kubectl expose deployment/nginx --port=88 --type=NodePort --target-port=80 --name=example-nginx-service
# 备注 --port=88:Service服务的端口 --target-port=80: 容器暴露的端口 --type=NodePort:会随机开放一个宿主机端口(端口范围在apiserver中定义)
查看/描述 服务
kubectl get svc
kubectl describe svc example-nginx-service
快速访问测试: curl ip:port
查看Pod日志
kubectl logs pods/podname
注意:这个podname来自于通过标签查找的pod的name
扩容和缩容
kubectl scale deployment nginx-deployment --replicas=4
更新Deployment
kubectl edit deployment/nginx-deployment
注意:kubectl edit 指令,会帮你直接打开 nginx-deployment 的 API 对象。然后,你就可以修改这里的 Pod 模板部分了
kubectl edit 指令编辑完成后,保存退出,Kubernetes 就会立刻触发“滚动更新”的过程。你还可以通过 kubectl rollout status 指令查看 nginx-deployment 的状态变化:
kubectl rollout status deployment/nginx-deployment
继续查看 Deployment 的 Events,看到这个“滚动更新”的流程:
kubectl describe deployment nginx-deployment
整个更新是滚动更新的:将一个集群中正在运行的多个 Pod 版本,交替地逐一升级的过程,就是“滚动更新”。
Deployment Controller 会使用这个修改后的 Pod 模板,创建一个新的 ReplicaSet,这个新的 ReplicaSet 的初始 Pod 副本数是:0。
更新过程交替进行,新 ReplicaSet 管理的 Pod 副本数,从 0 个变成 1 个,再变成 2 个,最后变成 3 个。而旧的 ReplicaSet 管理的 Pod 副本数则从 3 个变成 2 个,再变成 1 个,最后变成 0 个。这样,就完成了这一组 Pod 的版本升级过程。
最后我们查看ReplicaSet
kubectl get rs
就会发现旧 ReplicaSet所管理的pod已经被“水平收缩”成了 0 个副本。
更新操作还有两种方式:一种是,手动修改yaml文件,然后执行kubectl apply -f nginx-deployment.yaml,另一种是通过 kubectl set image 命令。
另外补充:我们对 Deployment 进行的每一次更新操作,都会生成一个新的 ReplicaSet 对象,是不是有些多余,甚至浪费资源呢?
Kubernetes 项目还提供了一个指令,使得我们对 Deployment 的多次更新操作,最后 只生成一个 ReplicaSet。具体的做法是,在更新 Deployment 前,你要先执行一条 kubectl rollout pause 指令。
具体流程:
1.在更新这个Deployment时,执行kubectl rollout pause deployment/nginx-deployment
2.更新Deployment,使用kubectl edit 或者 kubectl set image 指令
3.等Deployment 上的更新完成以后,执行kubectl rollout resume deployment/nginx-deployment
回滚
回滚到上一个版本
kubectl rollout undo deployment/nginx-deployment
Deployment 的控制器,会让这个旧 ReplicaSe再次“扩展”成 3 个 Pod,而让新的 ReplicaSet重新“收缩”到 0 个 Pod。
回滚到更早之前的版本
查看此deployment每次变更对应的版本
kubectl rollout history deployment/nginx-deployment
查看对应版本的 Deployment 的 API 对象的细节
kubectl rollout history deployment/nginx-deployment --revision=2
确定以后我们就可以回滚到这个版本上
kubectl rollout undo deployment/nginx-deployment --to-revision=2
编写Deployment Spec指南
在所有的Kubernetes配置中,Deployment也需要apiVersion,kind和metadata这些配置项。配置文件的通用使用说明查看部署应用,配置容器,和使用kubeclt管理资源文档。
Deployment也需要 .spec section.
Pod Template
.spec.template
是 .spec中唯一要求的字段。
.spec.template 是 pod template. 它跟 Pod有一模一样的schema,除了它是嵌套的并且不需要apiVersion 和 kind字段。
另外为了划分Pod的范围,Deployment中的pod template必须指定适当的label(不要跟其他controller重复了)和适当的重启策略。
.spec.template.spec.restartPolicy
可以设置为 Always , 如果不指定的话这就是默认配置。
Replicas
.spec.replicas
是可以选字段,指定期望的pod数量,默认是1。
Selector
.spec.selector是可选字段,用来指定 label selector ,圈定Deployment管理的pod范围。
如果被指定, .spec.selector 必须匹配 .spec.template.metadata.labels,否则它将被API拒绝。如果 .spec.selector 没有被指定, .spec.selector.matchLabels 默认是 .spec.template.metadata.labels。
在Pod的template跟.spec.template不同或者数量超过了.spec.replicas规定的数量的情况下,Deployment会杀掉label跟selector不同的Pod。
注意: 你不应该再创建其他label跟这个selector匹配的pod,或者通过其他Deployment,或者通过其他Controller,例如ReplicaSet和ReplicationController。否则该Deployment会被把它们当成都是自己创建的。Kubernetes不会阻止你这么做。
如果你有多个controller使用了重复的selector,controller们就会互相冲突并导致不正确的行为。
策略
.spec.strategy 指定新的Pod替换旧的Pod的策略。 .spec.strategy.type 可以是”Recreate”或者是 “RollingUpdate”。”RollingUpdate”是默认值。
- Recreate Deployment
.spec.strategy.type==Recreate时,在创建出新的Pod之前会先杀掉所有已存在的Pod。
- Rolling Update Deployment
.spec.strategy.type==RollingUpdate
时,Deployment使用rolling update 的方式更新Pod 。你可以指定maxUnavailable 和maxSurge 来控制 rolling update 进程。
- Max Unavailable
.spec.strategy.rollingUpdate.maxUnavailable
是可选配置项,用来指定在升级过程中不可用Pod的最大数量。该值可以是一个绝对值(例如5),也可以是期望Pod数量的百分比(例如10%)。通过计算百分比的绝对值向下取整。如果.spec.strategy.rollingUpdate.maxSurge 为0时,这个值不可以为0。默认值是1。
例如,该值设置成30%,启动rolling update后旧的ReplicatSet将会立即缩容到期望的Pod数量的70%。新的Pod ready后,随着新的ReplicaSet的扩容,旧的ReplicaSet会进一步缩容,确保在升级的所有时刻可以用的Pod数量至少是期望Pod数量的70%。
- Max Surge
.spec.strategy.rollingUpdate.maxSurge
是可选配置项,用来指定可以超过期望的Pod数量的最大个数。该值可以是一个绝对值(例如5)或者是期望的Pod数量的百分比(例如10%)。当MaxUnavailable为0时该值不可以为0。通过百分比计算的绝对值向上取整。默认值是1。
例如,该值设置成30%,启动rolling update后新的ReplicatSet将会立即扩容,新老Pod的总数不能超过期望的Pod数量的130%。旧的Pod被杀掉后,新的ReplicaSet将继续扩容,旧的ReplicaSet会进一步缩容,确保在升级的所有时刻所有的Pod数量和不会超过期望Pod数量的130%。
- Progress Deadline Seconds
.spec.progressDeadlineSeconds
是可选配置项,用来指定在系统报告Deployment的failed progressing ——表现为resource的状态中type=Progressing、Status=False、 Reason=ProgressDeadlineExceeded前可以等待的Deployment进行的秒数。Deployment controller会继续重试该Deployment。未来,在实现了自动回滚后, deployment controller在观察到这种状态时就会自动回滚。
如果设置该参数,该值必须大于 .spec.minReadySeconds。
- Min Ready Seconds
.spec.minReadySeconds是一个可选配置项,用来指定没有任何容器crash的Pod并被认为是可用状态的最小秒数。默认是0(Pod在ready后就会被认为是可用状态)。进一步了解什么什么后Pod会被认为是ready状态,参阅 Container Probes。
- Rollback To
.spec.rollbackTo 是一个可以选配置项,用来配置Deployment回退的配置。设置该参数将触发回退操作,每次回退完成后,该值就会被清除。
- Revision
.spec.rollbackTo.revision是一个可选配置项,用来指定回退到的revision。默认是0,意味着回退到历史中最老的revision。
- Revision History Limit
Deployment revision history存储在它控制的ReplicaSets中。
.spec.revisionHistoryLimit 是一个可选配置项,用来指定可以保留的旧的ReplicaSet数量。该理想值取决于心Deployment的频率和稳定性。如果该值没有设置的话,默认所有旧的Replicaset都会被保留,将资源存储在etcd中,是用kubectl get rs查看输出。每个Deployment的该配置都保存在ReplicaSet中,然而,一旦你删除的旧的RepelicaSet,你的Deployment就无法再回退到那个revison了。
如果你将该值设置为0,所有具有0个replica的ReplicaSet都会被删除。在这种情况下,新的Deployment rollout无法撤销,因为revision history都被清理掉了。
- Paused
.spec.paused是可以可选配置项,boolean值。用来指定暂停和恢复Deployment。Paused和没有paused的Deployment之间的唯一区别就是,所有对paused deployment中的PodTemplateSpec的修改都不会触发新的rollout。Deployment被创建之后默认是非paused。