Kubernetes学习笔记-Deployment：声明式的升级应用（1）20220603

回顾

之前学的几章内容让我们知道了如何将应用程序组件打包进容器，将他们分组到pod中，并为他们提供临时存储或持久化存储，将密钥或配置文件注入，并可以使pod之间相互通信

接下来讲如何升级在kubernetes集群中运行的应用程序，以及kubernetes如何帮助实现真正的零停机升级过程。

一、更新运行在pod内的应用程序
有两种方法更新pod：
第一种：直接删除所有现在的pod，然后创建新的pod
第二种：先创建新的pod，并等待他们成功
运行之后，再删除旧的pod
1）删除旧版本pos，使用新版本pos替换
使用ReplicationController管理pod，可以直接将pod的模版修改为需要替换的新版本的镜像，然后删除旧版本的pod实例
不足：删除旧版本pod到启动新版本pod之间短暂的服务不可用
2）先创建新版本pod再删除旧版本pod
如果短暂的服务不可以完全不能接受，且你的应用程序支持多个版本同时对外服务，可以先创建新的pod再删除原有的pod
不足：需要更多的硬件资源，因为你将在短时间内同时运行两倍数量的pod

2 使用ReplicationController实现自动的滚动升级
1）创建应用v1
使用单个yaml文件运行应用并通过service暴露
通过创建一个ReplicationController来运行应用程序，并创建LoadBalance服务将应用程序对外暴露
创建一个yaml文件，并使用kubectl create命令调用kubernetes api。yaml manifest可以使用包含三个横岗（- - -）的行来分隔多个对象
2）使用kubectl 来执行滚动升级
创建应用v2
运行kubectl rolling-update 命令来执行升级操作。指定需要替换的ReplicationController，以及为新的ReplicationController指定一个名称，并指定你想要替换的镜像
$kubectl rolling-update kubia-v1 kubia-v2 - -image=luksa/kubia：v2
不足：

（1）滚动升级过程中会直接修改创建的对象，直接更新pod和ReplicationController的标签并不符合之前创建的预期。

（2）还有更重要的一点是：kubectl 只是执行滚动升级过程中所有这些步骤的客户端，如果在升级失去网络连接，升级则会中断。pod和ReplicationController最终会处于中间状态

希望只需要在pod定义中更改所期望的镜像tag，并让kubernetes用运行新镜像替换旧的pod。

接下来一章就学习用Deployment声明式地升级应用