怎样体会Kubernetes内容器的高可用性和弹性伸缩-创新互联

今天就跟大家聊聊有关怎样体会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内容器的高可用性和弹性伸缩有进一步的了解吗？如果还想了解更多知识或者相关内容，请关注创新互联-成都网站建设公司行业资讯频道，感谢大家的支持。