rolling update,可以使得服务近乎无缝地平滑升级,即在不停止对外服务的前提下完成应用的更新。
replication controller与deployment的区别
replication controller
Replication Controller为Kubernetes的一个核心内容,应用托管到Kubernetes之后,需要保证应用能够持续的运行,Replication Controller就是这个保证的key,主要的功能如下:
-
确保pod数量:它会确保Kubernetes中有指定数量的Pod在运行。如果少于指定数量的pod,Replication Controller会创建新的,反之则会删除掉多余的以保证Pod数量不变。
-
确保pod健康:当pod不健康,运行出错或者无法提供服务时,Replication Controller也会杀死不健康的pod,重新创建新的。
-
弹性伸缩 :在业务高峰或者低峰期的时候,可以通过Replication Controller动态的调整pod的数量来提高资源的利用率。同时,配置相应的监控功能(Hroizontal Pod Autoscaler),会定时自动从监控平台获取Replication Controller关联pod的整体资源使用情况,做到自动伸缩。
-
滚动升级:滚动升级为一种平滑的升级方式,通过逐步替换的策略,保证整体系统的稳定,在初始化升级的时候就可以及时发现和解决问题,避免问题不断扩大。
Deployment
Deployment同样为Kubernetes的一个核心内容,主要职责同样是为了保证pod的数量和健康,90%的功能与Replication Controller完全一样,可以看做新一代的Replication Controller。但是,它又具备了Replication Controller之外的新特性:
-
Replication Controller全部功能:Deployment继承了上面描述的Replication Controller全部功能。
-
事件和状态查看:可以查看Deployment的升级详细进度和状态。
-
回滚:当升级pod镜像或者相关参数的时候发现问题,可以使用回滚操作回滚到上一个稳定的版本或者指定的版本。
-
版本记录: 每一次对Deployment的操作,都能保存下来,给予后续可能的回滚使用。
-
暂停和启动:对于每一次升级,都能够随时暂停和启动。
-
多种升级方案:Recreate:删除所有已存在的pod,重新创建新的; RollingUpdate:滚动升级,逐步替换的策略,同时滚动升级时,支持更多的附加参数,例如设置最大不可用pod数量,最小升级间隔时间等等。
deployment的常用命令
查看部署状态
kubectl rollout status deployment/review-demo --namespace=scm
kubectl describe deployment/review-demo --namespace=scm
或者这种写法
kubectl rollout status deployments review-demo --namespace=scm
kubectl describe deployments review-demo --namespace=scm
升级
kubectl set image deployment/review-demo review-demo=library/review-demo:0.0.1 --namespace=scm
或者
kubectl edit deployment/review-demo --namespace=scm
编辑.spec.template.spec.containers[0].image的值
终止升级
kubectl rollout pause deployment/review-demo --namespace=scm
继续升级
kubectl rollout resume deployment/review-demo --namespace=scm
回滚
kubectl rollout undo deployment/review-demo --namespace=scm
查看deployments版本
kubectl rollout history deployments --namespace=scm
回滚到指定版本
kubectl rollout undo deployment/review-demo --to-revision=2 --namespace=scm
升级历史
kubectl describe deployment/review-demo --namespace=scm
Name: review-demo
Namespace: scm
CreationTimestamp: Tue, 31 Jan 2017 16:42:01 +0800
Labels: app=review-demo
Selector: app=review-demo
Replicas: 3 updated | 3 total | 3 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 1 max unavailable, 1 max surge
OldReplicaSets: <none>
NewReplicaSet: review-demo-2741031620 (3/3 replicas created)
Events:
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
1m 1m 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set review-demo-2741031620 to 1
1m 1m 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set review-demo-1914295649 to 2
1m 1m 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set review-demo-2741031620 to 2
1m 1m 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set review-demo-1914295649 to 1
1m 1m 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set review-demo-2741031620 to 3
1m 1m 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set review-demo-1914295649 to 0
deployment文件
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: review-demo
namespace: scm
labels:
app: review-demo
spec:
replicas: 3
# minReadySeconds: 60 #滚动升级时60s后认为该pod就绪
strategy:
rollingUpdate: ##由于replicas为3,则整个升级,pod个数在2-4个之间
maxSurge: 1 #滚动升级时会先启动1个pod
maxUnavailable: 1 #滚动升级时允许的最大Unavailable的pod个数
template:
metadata:
labels:
app: review-demo
spec:
terminationGracePeriodSeconds: 60 ##k8s将会给应用发送SIGTERM信号,可以用来正确、优雅地关闭应用,默认为30秒
containers:
- name: review-demo
image: library/review-demo:0.0.1-SNAPSHOT
imagePullPolicy: IfNotPresent
livenessProbe: #kubernetes认为该pod是存活的,不存活则需要重启
httpGet:
path: /health
port: 8080
scheme: HTTP
initialDelaySeconds: 60 ## equals to the maximum startup time of the application + couple of seconds
timeoutSeconds: 5
successThreshold: 1
failureThreshold: 5
readinessProbe: #kubernetes认为该pod是启动成功的
httpGet:
path: /health
port: 8080
scheme: HTTP
initialDelaySeconds: 30 ## equals to minimum startup time of the application
timeoutSeconds: 5
successThreshold: 1
failureThreshold: 5
resources:
# keep request = limit to keep this container in guaranteed class
requests:
cpu: 50m
memory: 200Mi
limits:
cpu: 500m
memory: 500Mi
env:
- name: PROFILE
value: "test"
ports:
- name: http
containerPort: 8080
几个重要参数说明
maxSurge与maxUnavailable
maxSurge: 1 表示滚动升级时会先启动1个pod
maxUnavailable: 1 表示滚动升级时允许的最大Unavailable的pod个数
由于replicas为3,则整个升级,pod个数在2-4个之间
terminationGracePeriodSeconds
k8s将会给应用发送SIGTERM信号,可以用来正确、优雅地关闭应用,默认为30秒。
如果需要更优雅地关闭,则可以使用k8s提供的pre-stop lifecycle hook 的配置声明,将会在发送SIGTERM之前执行。
livenessProbe与readinessProbe
livenessProbe是kubernetes认为该pod是存活的,不存在则需要kill掉,然后再新启动一个,以达到replicas指定的个数。
readinessProbe是kubernetes认为该pod是启动成功的,这里根据每个应用的特性,自己去判断,可以执行command,也可以进行httpGet。比如对于使用java web服务的应用来说,并不是简单地说tomcat启动成功就可以对外提供服务的,还需要等待spring容器初始化,数据库连接连接上等等。对于spring boot应用,默认的actuator带有/health接口,可以用来进行启动成功的判断。
其中readinessProbe.initialDelaySeconds可以设置为系统完全启动起来所需的最少时间,livenessProbe.initialDelaySeconds可以设置为系统完全启动起来所需的最大时间+若干秒。
这几个参数配置好了之后,基本就可以实现近乎无缝地平滑升级了。对于使用服务发现的应用来说,readinessProbe可以去执行命令,去查看是否在服务发现里头应该注册成功了,才算成功。
doc
- 【分享】几种常见的不停机发布方式
- Deployment vs ReplicationController in Kubernetes
- kubernetes-user-guide-deployments
- Kubernetes用户指南(三)--在生产环境中使用Pod来工作、管理部署
- Kubernetes livenessProbe shutdown during application startup
- Kubernetes技术研究容器监控监测
- Graceful shutdown of pods with Kubernetes
- http://www.cnblogs.com/ilinuxer/p/6637214.html
相关推荐
在实际应用中,滚动升级可以使用 kubectl 命令来实现,例如: * 如果修改了 yaml 文件:kubectl apply -f .yml * 如果没有更改 yaml 文件却想要平滑重启:$ kubectl rollout restart deployment * 查看滚动升级的...
基于容器的应用部署、维护和滚动升级 负载均衡和服务发现 跨机器和跨地区的集群调度 自动伸缩 无状态服务和有状态服务 广泛的Volume支持 插件机制保证扩展性 Kubernetes发展非常迅速,已经成为容器编排领域的领导者...
本文将详细介绍如何在您的Kubernetes环境中升级节点,主要聚焦于使用system-upgrade-controller这一工具。 首先,我们需要理解Kubernetes节点升级的基本流程。通常,这包括以下步骤: 1. **准备升级**: 在升级之前...
Kubernetes具有完备的集群管理能力,包括多层次的安全防护和准入机制/多租户应用支撑能力、透明的服务注册和服务发现机制、内建智能负载均衡器、强大的故障发现和自我修复功能、服务滚动升级和在线扩容能力、可扩展...
3. **容器化应用部署**:学习使用YAML文件来定义和部署应用,包括如何创建自定义工作负载、设置服务发现、进行滚动更新和蓝绿部署等。 4. **存储与网络**:理解Kubernetes中的持久化存储,如Persistent Volumes和...
Kubernetes 1.4 改进了滚动更新和回滚机制,允许用户在不中断服务的情况下平滑地升级或回滚应用版本,确保服务的稳定性和高可用性。 总结起来,Kubernetes 1.4.0 源代码包含了大量关于容器编排、服务发现、资源...
2. **Helm**:应用包管理工具,简化Kubernetes应用的打包、分发和升级。 综上所述,《Programming Kubernetes》全面涵盖了Kubernetes的核心概念、工作原理、实践技巧以及与其他技术的整合,对于想要深入了解和使用...
- **日志和监控**:使用Kubernetes的logging和metrics API,配合Prometheus和Grafana等工具进行集群监控。 4. **Kubernetes网络模型** - **Network Policy**:控制Pod间通信的策略,实现微隔离。 - **CNI插件**...
基于容器的应用部署、维护和滚动升级 负载均衡和服务发现 跨机器和跨地区的集群调度 自动伸缩 无状态服务和有状态服务 广泛的Volume支持 插件机制保证扩展性 Kubernetes发展非常迅速,已经成为容器编排领域的领导者...
5. **部署和升级**:使用这个离线包,用户可以在没有互联网连接的环境中部署Kubernetes集群,或者将现有集群升级到1.15.4版本。这涉及到解压文件、配置必要的组件,如etcd、kubelet、apiserver等,并通过kubectl工具...
1. **kubeadm**: Kubernetes的官方部署工具,简化集群初始化和升级过程。 2. **kops**: AWS上的Kubernetes集群管理工具。 3. **Kubespray**: 多云和混合云环境下的Kubernetes集群自动化部署工具。 **附加组件** ...
3. **下载新版本**:从官方渠道获取最新版的kubernetes客户端,例如通过访问Kubernetes官方网站或使用curl命令。 4. **安装新版本**:根据操作系统和平台的指示进行安装,可能涉及解压、移动文件到正确目录,并更新...
- **集群升级**: 介绍如何安全地升级 Kubernetes 集群的版本,包括滚动更新和蓝绿部署等策略。 - **高可用性**: 探讨如何构建高可用性的 Kubernetes 集群,确保关键业务系统的持续运行。 ### 核心原理 #### 2.1 ...
Kubernetes中Autoscaling组的可靠,可扩展的滚动升级 RollingUpgrade提供了Kubernetes本机机制,用于使用CRD和控制器对AutoScaling组中的实例进行滚动更新。 它有什么作用? RollingUpgrade受到kops进行滚动更新的...
在缩短软件交付周期方面,作者分享了如何利用Kubernetes的滚动更新功能实现无缝升级,避免服务中断。同时,书中也涉及了故障排查、监控和日志收集的最佳实践,如使用Prometheus和Grafana进行性能监控,以及使用...
为了适应 Kubernetes 环境,应用需要进行改造,包括保证良好的持久性和可用性、支持同时运行多个应用实例、不停机的滚动升级等。 高可用性 高可用性是新的标准配置,需要保证良好的持久性和可用性、支持同时运行多...
Kubernetes的出现使得系统设计者可以更专注于业务逻辑,因为它自动处理负载均衡、服务发现、高可用性、滚动升级和自动伸缩等任务,降低了开发和运维成本。Kubernetes的简写K8s源于其名称中的8个字母。 云原生应用...
除了基础概念和操作,代码示例还可能涵盖了如何编写合适的 YAML 文件、如何优雅地升级应用、如何进行滚动更新等最佳实践。 10. **监控与日志** Kubernetes 提供了多种工具来监控集群的健康状况和收集应用日志。...