注意:以下文档只适用于TOP接口,请谨慎使用!

文档中心 > 聚石塔

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

更新时间:2020/05/29 访问次数:406

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

  • 上手快
    • 不需要了解底层 deployment、controller、service、ingress 等概念就能完成应用的部署
  • namespace 隔离
    • 聚石塔 k8s 每个应用默认都是独立 namespace 隔离的,安全性更有保障。如果在原生 k8s 集群中,对于刚上手 k8s 的人来说很可能都部署到 default 下
  • 丰富的镜像
    • 聚石塔 k8s 提供了常用官方镜像,这些镜像一方面减少了大家自己创建镜像的工作(掌握 docker 镜像的知识、镜像的选择、各种配置等),另一方面官方出品在安全性、完备性、质量上都有保障。
    • 而且官方镜像界面(部署配置界面)默认的端口映射、环境变量、文件挂载、目录挂载配置清晰明了,即使是初上手的的运维人员也能轻松掌握
    • 健康检查和优雅上下线提供稳定性的保障
  • 环境隔离
    • 环境与部署配置在原生 k8s 里并没有这个概念,但是考虑到日常运维中,如果出现高峰情况更多的只是变更实例的数量,进行扩缩,将 k8s 里 deployment 拆分为环境和部署配置还是很贴心的。
  • 发布单
    • 发布记录有据可查,回滚方便

聚石塔 k8s 的几个概念

  1. 部署配置

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

  1. 环境管理

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

  1. 流量接入

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

  1. 发布单

一次发布记录

  1. 发布批次:

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

 

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

 

总体上线流程

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

集群环境准备阶段

创建集群

注意事项

  • 只能创建两个集群:测试集群、正式集群
  • vpc 网段、服务网段、pod 网段,不能冲突。

加入节点

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

 

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

应用环境搭建阶段

创建应用

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

创建部署配置

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

注意事项:

  1. cpu 规格可以填小数
  2. cpu 规格可以填 0 ,即共享
  3. 内存规格也可以共享,不过应用启动一般都要设定内存使用的,因此共享意义不大
  4. cpu、内存的规格设置一定要注意自己节点剩余的规格,另外牢记节点资源会有k8s组件的消耗,无法全部使用

创建环境

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

  1. 是否支持集群
  2. 是否有需要做高可用
  3. 和部署配置中设定的规格权衡

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

部署上线

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

接入流量

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

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

 

注意事项:

  • 接入流量选择 slb 之后,会覆盖这个 slb 下的其他转发配置,这个很重要,建议选择新购的 slb
  • 如果部署配置应用的实例数 >=2 ,k8s 集群将容器 pod 调度到哪个节点是未知的,如果多个实例调度到同一个节点,slb 的会话保持是无法保障到实例的,如下图:
    • 调度到同一个节点,无法会话保持

 

  • 调度到不同节点,会话保持正常工作

正式迁移步骤

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

API 发布注意事项

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

注意事项

  1. 不支持的属性:k8s 的 deployment 概念基本和聚石塔里部署配置一致,部分属性可能不支持,比如 Deployment 的name属性,replicas 因为拆到了环境配置中,也不支持,其他具体要看使用情况
  2. 还不支持 oss 授权(我打迁移的时候不支持)
  3. 如果不能走oss公开链接,则内部搭建好发布包的服务器,发布包内网能访问通就行
  4. 注意 api 调用限流
  5. k8s 名称规则限制:如果有出现类似的错误,检查下命名是否规范,比如 configMap key的名字,deployment name属性等

 

补充

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

FAQ

关于此文档暂时还没有FAQ
返回
顶部