淘宝开放平台

登录
文档中心 > 商家经营工具-开发指引

商家经营工具-开发指引

【我打】聚石塔K8S 容器化迁移分享

更新时间：2023/06/25 访问次数：8818

对于去年3月份刚完成扒了一层皮似的张北迁移的团队来说，接到又要来一次迁移通知的时候，内心是奔溃的。但在了解到是往 k8s 迁移的时候，我举双手赞成，毕竟连 F16 战斗机都用上了 K8S，甚至连日剧都出现了 k8s 的身影：


image.png


在我们完成迁移之后，也日益体会到容器化之后带来的各种福利。


一、容器化后的好处


相比传统的部署方式，上 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做了概念性的一些抽象和封装，相比原生 k8s 来说使用上更简单，刚上手可能有点不理解，完成一个应用真正上线后，就会理解其实这一套机制让大家少走了不少弯路，好比强制了代码规范：

1）上手快

不需要了解底层 deployment、controller、service、ingress 等概念就能完成应用的部署。


2）namespace 隔离

聚石塔 k8s 每个应用默认都是独立 namespace 隔离的，安全性更有保障。如果在原生 k8s 集群中，对于刚上手 k8s 的人来说很可能都部署到 default 下。


3）丰富的镜像

① 聚石塔 k8s 提供了常用官方镜像，这些镜像一方面减少了大家自己创建镜像的工作（掌握 docker 镜像的知识、镜像的选择、各种配置等），另一方面官方出品在安全性、完备性、质量上都有保障。

② 而且官方镜像界面（部署配置界面）默认的端口映射、环境变量、文件挂载、目录挂载配置清晰明了，即使是初上手的的运维人员也能轻松掌握

③ 健康检查和优雅上下线提供稳定性的保障。


4）环境隔离

环境与部署配置在原生 k8s 里并没有这个概念，但是考虑到日常运维中，如果出现高峰情况更多的只是变更实例的数量，进行扩缩，将 k8s 里 deployment 拆分为环境和部署配置还是很贴心的。


5）发布单

发布记录有据可查，回滚方便。


三、聚石塔 k8s 的几个概念


1. 部署配置

管理应用实例使用的镜像、资源限制（cpu、内存）、环境变量、配置文件、健康检查接口等。


2. 环境管理

主要管理集群环境关联、实例的数量、部署配置关联。需要注意的是，一次发布时基于环境的。


3. 流量接入

让应用服务能被外部(内网、外网)访问。


4. 发布单

一次发布记录。

5. 发布批次

指的是当分几次完成容器中实例的替换。比如环境配置中配置实例数是4，批次2，表示每次替换两个实例，分两次完成。

 

注意：发布的时候，是先停止旧实例，再启动新实例的。这么做保障容器中有足够的资源能够部署新的实例，带来的问题是，如果实例数是1，会让服务暂时不可用，因此最好保障实例数 >=2。

 

四、总体上线流程


总体上线流程如下，但在实际过程中，可以把 slb、eip准备好，在测试阶段，接入流量的过程做好后，后续正式部署也不需要修改。


1. 集群环境准备阶段


创建集群

注意 事项：

① 只能创建两个集群：测试集群、正式集群

② vpc 网段、服务网段、pod 网段，不能冲突。


加入节点

注意加入集群的节点由于k8s组件自身会消耗一点资源，因此 8C16G 的节点，无法部署 8C16G 的应用，也无法部署两个 4C8G 的实例。理论上来说，规格越大，总体损耗越少。

 

接入流量的 slb、eip 等工作也可以提前做好。


2. 应用环境搭建阶段


1）创建应用

这一步基本没啥问题，按提示选择类型，填写应用名称提交就可以了。


2）创建部署配置

这一步就要根据自己的应用部署方式选择合适的镜像了，界面中环境变量、文件挂载、部署目录都很清晰。

注意事项：

① cpu 规格可以填小数；

② cpu 规格可以填 0 ，即共享；

③ 内存规格也可以共享，不过应用启动一般都要设定内存使用的，因此共享意义不大；

④ cpu、内存的规格设置一定要注意自己节点剩余的规格，另外牢记节点资源会有k8s组件的消耗，无法全部使用。


3）创建环境

配置合适实例数量，数量的决策需要考虑的问题：

① 是否支持集群；

② 是否有需要做高可用；

③ 和部署配置中设定的规格权衡；

注意： 环境配置中数量的调整需要重新发布才生效（扩缩容是直接创建一个发布单做一次新的发布的）。


4）部署上线

创建发布单、上传发布包，发布单记录可以看历史发布。创建发布单的时候有个批次的选择，前面已经说过，取决于部署配置中实例的数量，和自己期望控制的节奏。因为批次可以暂停，比如在发布可能产生风险的情况下，可以把批次拉大，每次暂停观察是否正常，再决定是否继续发布。


5）接入流量

部署成功之后，还需要接入流量才可以被外部访问，推荐使用内网 SLB 接入，然后将 SLB 绑定一个 EIP，这样做的好处是负载均衡同时又内外网 IP，内外网都可以访问。当然如果只是内部服务，则不需要 EIP。

slb 接入的时候需要选择协议，以 http 和 https 为例，如果我们对外服务需要同时支持 http、https，则需要接入两个。接入时注意选择端口号，监听端口为 slb 对外的端口，http:80、https:443 默认端口即可。RS 端口是自己应用在容器内的端口。另外，https 接入需要先做好证书。


image.png


注意事项：

① 接入流量选择 slb 之后，会覆盖这个 slb 下的其他转发配置，这个很重要，建议选择新购的 slb

② 如果部署配置应用的实例数 >=2 ，k8s 集群将容器 pod 调度到哪个节点是未知的，如果多个实例调度到同一个节点，slb 的会话保持是无法保障到实例的，如下图：

i）调度到同一个节点，无法会话保持；


image.png


ii）调度到不同节点，会话保持正常工作。


image.png


五、正式迁移步骤


以上步骤在正式迁移前相信大家都会跑几遍流程探探坑，在集群、应用配置、SLB、EIP、日志等接入完成后，迁移相对简单，因为集群毕竟是一个全新的环境，没有特殊情况下也不涉及数据库的变更，因此一般情况下先在容器部署好应用，内部测试通过，就剩下在业务低峰期切换域名就可以了。


API 发布注意事项


api 发布有发布更方便、便于管理与内部运维系统的集成 的优势，我们采用的方式是 api 发布，聚石塔api文档写得很详细了，api 数量也不多，挨个测试一遍也不过半天时间，这里主要把遇到的问题和大家分享一下：


注意事项

① 不支持的属性：k8s 的 deployment 概念基本和聚石塔里部署配置一致，部分属性可能不支持，比如 Deployment 的name属性，replicas 因为拆到了环境配置中，也不支持，其他具体要看使用情况；

② 还不支持 oss 授权（我打迁移的时候不支持）；

③ 如果不能走oss公开链接，则内部搭建好发布包的服务器，发布包内网能访问通就行；

④ 注意 api 调用限流；

⑤ k8s 名称规则限制：如果有出现类似的错误,检查下命名是否规范，比如 configMap key的名字，deployment name属性等。


image.png


补充

rds 需要配置集群节点的白名单，老的方式是通过 ecs 和 rds 关联到一个应用实现互通的，现在必须配置白名单或者使用安全组设置。

FAQ

关于此文档暂时还没有FAQ
有用(0) 我要提问
返回
顶部