今天就跟大家聊聊有关怎样体会Kubernetes内容器的高可用性和弹性伸缩,可能很多人都不太了解,为了让大家更加了解,小编给大家总结了以下内容,希望大家根据这篇文章可以有所收获。
小编将会介绍如何在Kubernetes里运行这个docker镜像。
在Kubernetes上运行我们的应用,有什么收益?根据Jerry这十多天有限的时间里对Kubernetes的学习,我的理解是,Kubernetes可以帮助应用开发人员确保其开发出的应用程序以一种高可用的、可伸缩和容错的方式进行部署和运行,应用开发人员无需花费大量时间和精力去学习Kubernetes底层细节。
换句话说,Kubernetes环境的搭建,系统的配置,可以全部交给Kubernetes的管理员,而应用开发人员作为Kubernetes的消费者,只需要记住几个简单的kubectl命令,就能够轻松完成应用程序到Kubernetes上的部署,几乎不需付出额外的代价就能享受到Kubernetes作为一个平台给应用程序带来的上述非功能性的提升。
我们继续用前一篇文章使用到的UI5应用进行讲解。
Jerry很穷,没有钱购买额外的服务器自己搭建Kubernetes集群环境。幸运的是,Kubernetes并没有抛弃我们这些贫穷的程序员,我们还可以选择Kubernetes Clusters as a Service这种解决方案。
我在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环境了。感谢阅读。
看完上述内容,你们对怎样体会Kubernetes内容器的高可用性和弹性伸缩有进一步的了解吗?如果还想了解更多知识或者相关内容,请关注亿速云行业资讯频道,感谢大家的支持。
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。