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

举报
Jerry Wang 发表于 2021/12/31 21:56:01 2021/12/31
【摘要】 上一篇文章 在Kubernetes上运行SAP UI5应用(上),我介绍了如何在Docker里运行一个简单的SAP UI5应用,并且已经成功地将一个包含了这个UI5应用的docker镜像上传到Docker hub上。这篇文章作为这个主题的下半部分,将会介绍如何在Kubernetes里运行这个docker镜像。文章目录Kubernetes里的两个重要概念:pod和deploymentKuber...

上一篇文章 在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作为一个平台给应用程序带来的上述非功能性的提升。

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

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

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

https://github.com/gardener

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

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

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

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

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

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

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

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

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

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

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

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

在这里插入图片描述

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

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

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

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

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

image.gif

从每个状态的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:

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

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

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

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

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

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

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

image.gif

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

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

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

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

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

在这里插入图片描述

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

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

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

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

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

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

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

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

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

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

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

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

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

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

首先使用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

上图看出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

使用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版本了:

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

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

要获取更多Jerry的原创文章,请关注公众号"汪子熙"。

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

举报
请填写举报理由
0/200