在Kubernetes上运行SAP UI5应用(下): 一个例子体会Kubernetes内容器的高可用性和弹性伸缩-阿里云开发者社区

开发者社区> jerrywangsap> 正文

在Kubernetes上运行SAP UI5应用(下): 一个例子体会Kubernetes内容器的高可用性和弹性伸缩

简介: 上一篇文章 在Kubernetes上运行SAP UI5应用(上),我介绍了如何在Docker里运行一个简单的SAP UI5应用,并且已经成功地将一个包含了这个UI5应用的docker镜像上传到Docker hub上。 这篇文章作为这个主题的下半部分,将会介绍如何在Kubernetes里运行这个docker镜像。
+关注继续查看

上一篇文章 在Kubernetes上运行SAP UI5应用(上),我介绍了如何在Docker里运行一个简单的SAP UI5应用,并且已经成功地将一个包含了这个UI5应用的docker镜像上传到Docker hub上。


这篇文章作为这个主题的下半部分,将会介绍如何在Kubernetes里运行这个docker镜像。


文章目录


Kubernetes里的两个重要概念:pod和deployment


Kubernetes保证应用程序高可用性和伸缩性的一些体验


Kubernetes滚动升级(Rolling Update)特性体验


在Kubernetes上运行我们的应用,有什么收益?根据Jerry这十多天有限的时间里对Kubernetes的学习,我的理解是,Kubernetes可以帮助应用开发人员确保其开发出的应用程序以一种高可用的、可伸缩和容错的方式进行部署和运行,应用开发人员无需花费大量时间和精力去学习Kubernetes底层细节。


换句话说,Kubernetes环境的搭建,系统的配置,可以全部交给Kubernetes的管理员,而应用开发人员作为Kubernetes的消费者,只需要记住几个简单的kubectl命令,就能够轻松完成应用程序到Kubernetes上的部署,几乎不需付出额外的代价就能享受到Kubernetes作为一个平台给应用程序带来的上述非功能性的提升。


image.png


我们继续用前一篇文章使用到的UI5应用进行讲解。


Jerry很穷,没有钱购买额外的服务器自己搭建Kubernetes集群环境。幸运的是,Kubernetes并没有抛弃我们这些贫穷的程序员,我们还可以选择Kubernetes Clusters as a Service这种解决方案。


在我另一篇文章 站在巨人肩膀上的牛顿:Kubernetes和SAP Kyma 里我提到过Gardener, 一个开源的创建Kubernetes集群的解决方案:


https://github.com/gardener


image.png


我在SAP内部的Gardener上创建一个基于Google Cloud Platform的Kubernetes集群,取名jerry1204:


image.png


可以看到这个创建好的集群上的Kubernetes版本还是比较新的, 1.12.3仅仅低于12月3日刚刚发布的1.13版。


image.png


点击上图Access标签页里的Dashboard(控制台)超链接,即可对这个Kubernetes集群进行操作。当然像SAP上海研究院Kubernetes培训课程上讲课的那些老司机们更喜欢用命令行。


因为是免费的集群,只分配了一个工作节点:


image.png


控制台里看到的Kubernetes集群工作节点信息和命令行kubectl get node -o wide看到的一致:


image.png


Kubernetes里的两个重要概念:pod和deployment


下面我们使用命令行来消费我们前一篇文章上传到Docker Hub上的镜像i042416/ui5-nginx:


kubectl run jerry-ui5 --image=i042416/ui5-nginx


image.png


这个命令行背后发生了很多事情。


首先,运行在Kubernetes上的应用程序,其高可用性,可伸缩性和容错性到底是通过Kubernetes什么机制保证的?


image.png


答案是pod。请单击上面Kubernetes的架构图,然后放大,能看到node(节点)里包含了多个pod,每个pod里又包含了多个容器。像它的中文含义(豆荚,飞机,航天器或船只上可与主体分离的分离仓)暗示的一样,pod就是应用程序运行的载体,是Kubernetes的基本操作单元。整套Kubernetes系统的设计都是围绕着pod展开,例如pod的部署和运行,如何保证处于运行状态的pod总数量等于一个恒定值,如何将pod里应用提供的服务暴露给外部访问等等。


image.png


回到我们之前的命令行,我们试着执行另一个命令kubectl get pod,果然发现了一个pod被创建出来,诞生已经40秒了(Age = 40s)。


image.png


用describe命令查看这个pod的明细:


kubectl describe pod jerry-ui5-6ffd46bb95-6bgpg


下图Container ID后面的docker://说明这是一个docker容器,当然并不意味着Kubernetes只支持Docker这一种容器技术,比如Kubernetes还支持CoreOS的Rocket。


image.png


describe命名输出的Events区域揭示了一个pod从诞生到开始服役的生命周期状态跳转:


Scheduled->Pulling->Pulled->Created->Started



image.png

从每个状态的from字段也能看出很多信息。


Scheduled状态的from: default-scheduler。Scheduler是Kubernetes的组件之一,负责调度pod到合适的节点上。具体什么样的节点算合适,取决于Kubernetes Scheduler调度算法的实现,Jerry没有研究过。如果把Scheduler看成一个黑匣子,那么它的输入是pod和由多个节点组成的列表,输出是Pod和一个匹配节点的绑定。这个状态message显示的内容"Successfully assigned XXX to shoot–jerrytest-jerry1204-worker-yamer-z1-XXX"后面这个shoot–jerrytest开头的字符串就是pod被分配到的节点的名称。


后面几个状态的from字段都是kubelet,shoot–jerrytest-jerry1204-worker-yamer-z1-XXX,其中kubelet是Kubernetes节点上一个重要的模块,负责维护和管理运行于该节点上的所有容器,确保pod的运行状态与使用者期望一致。


在Kubernetes web控制台里也一样能看到这个处于运行状态的pod:


image.png


除了pod之外,Kubernetes第二个重要的概念就是deployment。


执行另一个命令kubectl get deploy,发现kubectl run命令除了生成一个pod外,还生成了一个deployment。从这个命令输出的Desired, Current和Up-to-Date, Available下面的数字,结合前面提到的Kubernetes里几乎所有的设计都是围绕着pod来展开这一指导思想,我们不难猜测出,这个生成的deployment也是为pod服务的。


image.png


实际上,Kubernetes的初学者可以把deployment的主要职责理解成是保证pod的数量和健康。


在前面的文章里,我们已经知道了怎样使用docker run启动一个docker镜像。然而在Kubernetes的世界里,我们不会直接和运行在pod里的docker容器打交道,而是通过Kubernetes service将pod里的应用提供的服务暴露给外界消费。


到目前为止,Kubernetes集群上还没有任何和应用程序相关的service生成。命令kubectl get svc只返回了一个Kubernetes的标准服务。


image.png


因此我们使用命令kubectl expose基于刚刚使用kubectl run生成的deployment创建一个service:


kubectl expose deployment jerry-ui5 --type=LoadBalancer --port=80 --target-port=80



一旦expose命令执行后,get svc命令这次就返回了一个和deployment同名的service,暴露给外界访问的IP地址为35.205.230.209:


image.png




于是,使用url 35.205.230.209/webapp就能访问运行在Kubernetes pod里的SAP UI5了:


image.png


Kubernetes保证应用程序高可用性和伸缩性的一些体验


到目前为止我们的SAP UI5应用仅仅运行在Kubernetes集群上的一个工作节点的单个pod里,还没有感受到这个应用运行时的表现和之前运行在Docker容器里有什么差异。


我们现在就来尝试下Kubernetes deployment的水平扩展功能。在Kubernetes操作台里选中deployment,从菜单里执行Scale命令,


image.png


设定新的pod的数量:下面截图的3,意思是告诉这个deployment,在命令执行完毕后,它必须要努力保证,在任何时候由它控制和监控的pod个数必须等于3。


image.png


当然这个控制台上的图形菜单在命令行里也存在对应的命令,我们后面会用到。


上图OK按钮点击后,再次执行kubectl get pod, 能观察到水平扩展执行之后,生成了两个新的deployment,所以这次get pod命令总共返回了3个pod,其中后两个pod从Age能看出是水平扩展执行之后刚刚创建的。


image.png


使用kubectl describe命令查看deployment的明细,在Replicas这个字段里看到这个deployment控制的pod的运行时明细:


3 desired | 3 updated | 3 total | 3 available | 0 unavailable


image.png


我们现在故意用kubectl delete删除一个pod,再次查看,发生一个新的pod瞬间就自动生成了,处于运行状态的pod总数仍然为3。


Kubernetes滚动升级(Rolling Update)特性体验


滚动升级是Kubernetes一大特色,顾名思义,这是一种平滑过渡的升级方式,通过逐个容器替代升级的方式,来实现无中断的服务升级。下图deployment的describe命令的输出,其中字段StrategyType字段表明kubectl run创建的deployment默认的升级方式就是滚动升级。


image.png


我设计了这样一个简单的升级场景:我的SAP UI5应用1.0版本同时运行在一个Kubernetes节点的10个pod上。在整个应用不中断的前提下,通过滚动升级的方式升级到2.0版本。


由于上一篇文章我上传到Docker Hub上的镜像的标签为默认的latest,所以我需要在Docker Hub上分别制造两个标签为v1.0和v2.0的镜像。


image.png


下面的命令行推送一个标签为v1.0的镜像到Docker Hub:


image.png



修改UI5应用明细页面的标题,在文字后加上一个**(v2.0)**, 用来表示这一版的应用为2.0版本:


image.png


同样将这个2.0版本的镜像推送到Docker Hub上:


image.png


Docker Hub上两个版本的镜像都就绪了:


image.png


首先使用1.0版本的镜像,启动单个pod去执行SAP UI5应用:


kubectl run jerry-ui5 --image=i042416/ui5-nginx:v1.0


使用scale命令将单个pod水平扩展到10个pod:


kubectl scale --replicas=10 deployment/jerry-ui5


image.png


上图看出kubectl get pod返回10个处于运行状态的pod。


使用下面的命令触发滚动升级,把名为jerry-ui5的deployent基于的镜像从v1.0升级到v2.0:


kubectl set image deployment/jerry-ui5 i042416/ui5-nginx=i042416/ui5-nginx:v2.0


image.png


使用kubectl rollout status deployment/jerry-ui5查看滚动升级的实时进展情况。上图显示的日志表明,在某个时间点,有多少个旧版本的pod正等待被终止,有多少个新版本的pod已经处于可用状态。


X old replicas are pending termination


X of Y updated replicas are available


任意点开一个pod查看明细,发现其使用的docker镜像已经是v2.0版本了:


image.png


最后在浏览器里看到订单明细页面的标题,后面已经出现(v2.0), 再次确认了滚动升级已经成功结束了。


image.png


本文介绍的只是Kubernetes特性的冰山一角,更多细节,有待我们去学习,毕竟SAP云平台即将支持Kubernetes环境了。感谢阅读。


image.png

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
阿里云服务器怎么设置密码?怎么停机?怎么重启服务器?
如果在创建实例时没有设置密码,或者密码丢失,您可以在控制台上重新设置实例的登录密码。本文仅描述如何在 ECS 管理控制台上修改实例登录密码。
10095 0
OpenKruise v0.10.0 版本发布:新增应用弹性拓扑管理、应用防护等能力
阿里云开源的云原生应用自动化管理套件、CNCF Sandbox 项目 -- OpenKruise,今天发布 v0.10.0 新版本,这也会是 OpenKruise v1.0 之前的最后一个 minor 版本。 本文将带你一览 v0.10.0 的新变化,其中新增的 WorkloadSpread、PodUnavailableBudget 等大颗粒特性后续还将有转文详细介绍其设计实现原理。
286 0
ECS弹性供应组使用步骤
关于阿里云ECS弹性供应组的详细使用情况,您可以通过控制台或者API这两种方式来创建、查询、修改以及删除一个弹性供应组,下面将为您介绍如何管理弹性供应组的详细步骤。
725 0
阿里云服务器如何登录?阿里云服务器的三种登录方法
购买阿里云ECS云服务器后如何登录?场景不同,阿里云优惠总结大概有三种登录方式: 登录到ECS云服务器控制台 在ECS云服务器控制台用户可以更改密码、更换系.
13893 0
SpringCloud 应用在 Kubernetes 上的最佳实践 — 高可用(熔断)
前几篇我们主要站在应用发布的场景,描述在发布过程中会遇到的灰度、监控、回滚、优雅上下线等保障发布能顺利进行的注意事项。作为一个程序员GG,可灰度的发布顺利上线往往意味着准点下班。而我们今天要分享的内容则关系到我们能否拥有一个高质量的休息时间,即线上的高可用保障。
3057 0
SpringCloud 应用在 Kubernetes 上的最佳实践 — 高可用(容量评估)
本篇是《SpringCloud 应用在 Kubernetes 上的最佳实践 》系列内容的第十一篇。
9699 0
+关注
2628
文章
0
问答
来源圈子
更多
+ 订阅
文章排行榜
最热
最新
相关电子书
更多
《2021云上架构与运维峰会演讲合集》
立即下载
《零基础CSS入门教程》
立即下载
《零基础HTML入门教程》
立即下载