本系列前三局部：

适宜 Kubernetes 初学者的一些实战练习 (一)
适宜 Kubernetes 初学者的一些实战练习 (二)
适宜 Kubernetes 初学者的一些实战练习 (三)

练习1 - Kubernetes pod 的主动 scale (程度主动伸缩）

kubectl scale 命令用于程序在负载减轻或放大时进行 pod 扩容或放大，本练习咱们通过一个理论例子来察看 scale命令到底能达到什么成果。

命令行创立一个 deployment：

kubectl run jerry-nginx --image=nginx:1.12.2

kubectl get deploy 查看刚刚创立的 deployment：

主动被 deployment 创立的 pod：
kubectl get pod:

应用下列命令查看生成的 deployment 明细：

kubectl get deployment jerry-nginx -o yaml

另一个有用的命令：

kubectl describe deployment jerry-nginx

当初咱们应用上面的命令对 deployment 进行程度扩大：

kubectl scale deployment jerry-nginx --replicas=3

kubectl get pods -l run=jerry-nginx

下图这个 Age 为 15 分钟之前的是第一次创立 deployment 时生成的，其余两个 Age 为 1 分钟之前的是执行了 scale 命令后主动创立的。

选中一个才创立的 pod，查看其事件记录：

kubectl describe pod jerry-nginx-69fd9f6c4-8dpvb

kubectl get replicaset

失去主动创立的 replication set：

desired = 3 意思就是咱们程度扩大时指定的参数 3.

即便手动删除一个 pod实例，replication set 又会很快主动创立一个新的：

主动创立的新 pod：

练习2 - Kubernetes 滚动降级(rolling update)个性体验

在 Kubernetes 上运行咱们的利用，有什么收益？Kubernetes 能够帮忙利用开发人员确保其开发出的应用程序以一种高可用的、可伸缩和容错的形式进行部署和运行。

换句话说，Kubernetes 环境的搭建，零碎的配置，能够全副交给 Kubernetes 的管理员，而利用开发人员作为 Kubernetes 的消费者，只须要记住几个简略的 kubectl 命令，就可能轻松实现应用程序到 Kubernetes 上的部署，简直不需付出额定的代价就能享受到 Kubernetes 作为一个平台给应用程序带来的上述非功能性的晋升。

在本系列第三篇文章适宜 Kubernetes 初学者的一些实战练习 (三) 咱们曾经接触了 Gardener, 一个开源的创立 Kubernetes 集群的解决方案：

我在 Gardener 上创立一个基于 Google Cloud Platform 的 Kubernetes 集群，取名jerry1204：

点击上图 Access 标签页里的 Dashboard(控制台)超链接，即可对这个 Kubernetes 集群进行操作。

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

应用命令行来运行 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

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

Scheduled 状态的 from: default-scheduler.

Scheduler 是 Kubernetes 的组件之一，负责调度 pod 到适合的节点上。具体什么样的节点算适合，取决于 Kubernetes Scheduler 调度算法的实现。如果把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 的数量和衰弱。

在 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
一旦 expose 命令执行后，get svc 命令这次就返回了一个和 deployment 同名的 service，裸露给外界拜访的 IP 地址为 35.205.230.209:

于是，应用 url 35.205.230.209/webapp 就能拜访运行在 Kubernetes pod 里的 SAP UI5 利用了：

到目前为止咱们的 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 版本。

上面的命令行推送一个标签为 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 的 deployment 基于的镜像从 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 曾经处于可用状态。
任意点开一个 pod 查看明细，发现其应用的 docker 镜像曾经是 v2.0版本了：

最初在浏览器里看到订单明细页面的题目，前面曾经呈现(v2.0), 再次确认了滚动降级曾经胜利完结了。

总结

Kubernetes Pod 程度主动伸缩和滚动降级，是理论我的项目中两个重要且罕用的操作，也是可能体现 Kubernetes 优越性的亮点所在。本文作为 Kubernetes 初学者实战练习系列的第四局部，通过两个理论的例子，具体介绍了 Kubernetes 程度主动伸缩和滚动降级的命令行操作步骤，以及这些命令行执行后背地的实现细节，心愿对初学者有所帮忙。