文档中心 > 聚石塔

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

更新时间:2023/06/25 访问次数:8841

对于去年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
返回
顶部