注意：以下文档只适用于TOP接口，请谨慎使用！
注意：以下文档只适用于TOP接口，请谨慎使用！
对于去年3月份刚完成扒了一层皮似的张北迁移的团队来说，接到又要来一次迁移通知的时候，内心是奔溃的。但在了解到是往 k8s 迁移的时候，我举双手赞成，毕竟连 F16 战斗机都用上了 K8S，甚至连日剧都出现了 k8s 的身影：
在我们完成迁移之后，也日益体会到容器化之后带来的各种福利。
相比传统的部署方式，上 k8s 之后系统无论从经济成本、时间成本、稳定性、安全性都带了大幅度的提升：
1）整体 ECS 费用节约成本约 13% (理论上可以更多，不过毕竟头回跑，买的资源偏高配些)，另外趁着迁移容器化，我们做了架构的调整，带宽及 RDS 费用也有不少的节省。
2）上线运维的便捷性也带来了时间成本的降低，各种批处理脚本可以干掉了。
3）k8s 基于 docker 容器化技术，各应用天然就是隔离的，加上各容器实例的资源规格约束，不需担心多个应用部署到一个服务器资源竞争造成的影响。
4）SLS 日志服务接入更加简单，只需部署管理配置即可接入。
5）pod 的调度由 k8s 集群自己管理，运维人员再也不需要翻阅 ecs 列表或者考虑购买新的服务器来发布新的应用了，只需评估应用所需资源，集群剩余资源是否可用即可。
6）大促期间只需要购买新的临时节点，扩缩容一键搞定，算上购买服务器的时间到扩容完成，也就十几分钟的时间，相比传统方式封网前半夜摸黑弹升资源重启，为了省点成本还得算计封网前一两天弹，简直不要太爽。
7）灰度发布更加的容易。
8）k8s 之前要保持各服务器环境完全一致几乎是不可能的，k8s 使用统一的镜像，能保证环境的一致性，而且在 k8s 中，镜像通过 dockerfile 构建，相当于把操作过程文档化，不易出错且容易追溯。
9）极端情况下如果容器异常退出，k8s 可以自动调度启动新的 pod 实例，极大提高了系统的健壮性，几乎可以做到用户无感知恢复。
10）操作系统需要更新或者某些配置必须更换的时候，只需修改镜像，调整部署配置重新拉取即可。
11）迁移后，ecs 只是跑实例的载体，开发、技术支持人员甚至都不需要明确感知他们的存在，再也不用头疼账号分配的问题，大部分时候开发、技术支持查日志直接通过 SLS 查即可，即使需要线上查问题，也只需登录 webssh 进入容器即可，无需登录服务器。
聚石塔的 k8s做了概念性的一些抽象和封装，相比原生 k8s 来说使用上更简单，刚上手可能有点不理解，完成一个应用真正上线后，就会理解其实这一套机制让大家少走了不少弯路，好比强制了代码规范：
1）上手快
不需要了解底层 deployment、controller、service、ingress 等概念就能完成应用的部署。
2）namespace 隔离
聚石塔 k8s 每个应用默认都是独立 namespace 隔离的，安全性更有保障。如果在原生 k8s 集群中，对于刚上手 k8s 的人来说很可能都部署到 default 下。
3）丰富的镜像
① 聚石塔 k8s 提供了常用官方镜像，这些镜像一方面减少了大家自己创建镜像的工作（掌握 docker 镜像的知识、镜像的选择、各种配置等），另一方面官方出品在安全性、完备性、质量上都有保障。
② 而且官方镜像界面（部署配置界面）默认的端口映射、环境变量、文件挂载、目录挂载配置清晰明了，即使是初上手的的运维人员也能轻松掌握
③ 健康检查和优雅上下线提供稳定性的保障。
4）环境隔离
环境与部署配置在原生 k8s 里并没有这个概念，但是考虑到日常运维中，如果出现高峰情况更多的只是变更实例的数量，进行扩缩，将 k8s 里 deployment 拆分为环境和部署配置还是很贴心的。
5）发布单
发布记录有据可查，回滚方便。
管理应用实例使用的镜像、资源限制（cpu、内存）、环境变量、配置文件、健康检查接口等。
主要管理集群环境关联、实例的数量、部署配置关联。需要注意的是，一次发布时基于环境的。
让应用服务能被外部(内网、外网)访问。
一次发布记录。
指的是当分几次完成容器中实例的替换。比如环境配置中配置实例数是4，批次2，表示每次替换两个实例，分两次完成。
注意：发布的时候，是先停止旧实例，再启动新实例的。这么做保障容器中有足够的资源能够部署新的实例，带来的问题是，如果实例数是1，会让服务暂时不可用，因此最好保障实例数 >=2。
总体上线流程如下，但在实际过程中，可以把 slb、eip准备好，在测试阶段，接入流量的过程做好后，后续正式部署也不需要修改。
注意 事项：
① 只能创建两个集群：测试集群、正式集群
② vpc 网段、服务网段、pod 网段，不能冲突。
注意加入集群的节点由于k8s组件自身会消耗一点资源，因此 8C16G 的节点，无法部署 8C16G 的应用，也无法部署两个 4C8G 的实例。理论上来说，规格越大，总体损耗越少。
接入流量的 slb、eip 等工作也可以提前做好。
这一步基本没啥问题，按提示选择类型，填写应用名称提交就可以了。
这一步就要根据自己的应用部署方式选择合适的镜像了，界面中环境变量、文件挂载、部署目录都很清晰。
注意事项：
① cpu 规格可以填小数；
② cpu 规格可以填 0 ，即共享；
③ 内存规格也可以共享，不过应用启动一般都要设定内存使用的，因此共享意义不大；
④ cpu、内存的规格设置一定要注意自己节点剩余的规格，另外牢记节点资源会有k8s组件的消耗，无法全部使用。
配置合适实例数量，数量的决策需要考虑的问题：
① 是否支持集群；
② 是否有需要做高可用；
③ 和部署配置中设定的规格权衡；
注意： 环境配置中数量的调整需要重新发布才生效（扩缩容是直接创建一个发布单做一次新的发布的）。
创建发布单、上传发布包，发布单记录可以看历史发布。创建发布单的时候有个批次的选择，前面已经说过，取决于部署配置中实例的数量，和自己期望控制的节奏。因为批次可以暂停，比如在发布可能产生风险的情况下，可以把批次拉大，每次暂停观察是否正常，再决定是否继续发布。
部署成功之后，还需要接入流量才可以被外部访问，推荐使用内网 SLB 接入，然后将 SLB 绑定一个 EIP，这样做的好处是负载均衡同时又内外网 IP，内外网都可以访问。当然如果只是内部服务，则不需要 EIP。
slb 接入的时候需要选择协议，以 http 和 https 为例，如果我们对外服务需要同时支持 http、https，则需要接入两个。接入时注意选择端口号，监听端口为 slb 对外的端口，http:80、https:443 默认端口即可。RS 端口是自己应用在容器内的端口。另外，https 接入需要先做好证书。
注意事项：
① 接入流量选择 slb 之后，会覆盖这个 slb 下的其他转发配置，这个很重要，建议选择新购的 slb
② 如果部署配置应用的实例数 >=2 ，k8s 集群将容器 pod 调度到哪个节点是未知的，如果多个实例调度到同一个节点，slb 的会话保持是无法保障到实例的，如下图：
i）调度到同一个节点，无法会话保持；
ii）调度到不同节点，会话保持正常工作。
以上步骤在正式迁移前相信大家都会跑几遍流程探探坑，在集群、应用配置、SLB、EIP、日志等接入完成后，迁移相对简单，因为集群毕竟是一个全新的环境，没有特殊情况下也不涉及数据库的变更，因此一般情况下先在容器部署好应用，内部测试通过，就剩下在业务低峰期切换域名就可以了。
api 发布有发布更方便、便于管理与内部运维系统的集成 的优势，我们采用的方式是 api 发布，聚石塔api文档写得很详细了，api 数量也不多，挨个测试一遍也不过半天时间，这里主要把遇到的问题和大家分享一下：
① 不支持的属性：k8s 的 deployment 概念基本和聚石塔里部署配置一致，部分属性可能不支持，比如 Deployment 的name属性，replicas 因为拆到了环境配置中，也不支持，其他具体要看使用情况；
② 还不支持 oss 授权（我打迁移的时候不支持）；
③ 如果不能走oss公开链接，则内部搭建好发布包的服务器，发布包内网能访问通就行；
④ 注意 api 调用限流；
⑤ k8s 名称规则限制：如果有出现类似的错误,检查下命名是否规范，比如 configMap key的名字，deployment name属性等。
rds 需要配置集群节点的白名单，老的方式是通过 ecs 和 rds 关联到一个应用实现互通的，现在必须配置白名单或者使用安全组设置。
