个人拙见，仅供参考

公众号：yunops

某平台推行容器化各个人预分析

为了推行容器化，基于个人经验提出一些个人角度的分析说明，比较粗糙，后续应该会更新；

背景说明：

脑图图示（右键打开查看大图）：

k8s-apply

详细内容

  1. 【开发层面】研发配合内容：

    • 收集整理所有开发语言、框架；编译、进程启动方式/参数尽量统一；
    • 以语言+框架为维度进行标准化 Dockerfile 定制；
    • 容器化改造过程中一些固有方式的改造，如：根据日志收集方案修改；日志输出模式或控制日志大小；根据 services 特性进行调用改造（部分去注册中心）；
    • http 应用基于框架或自行开发实现标准的应用层健康检查接口，供 k8s 状态检测使用；
    • pod 规格（内存/cpu）的规划：容器化过程中需要评估统一生产级别 pod 规格的可行性，设置单 pod 的基准性能配置（CPU&内存），通过横向扩容（弹性伸缩节点）的方式提升系统承载量

  2. 【运维支撑层面】发布系统重构：

    • jenkins slave 是否进行容器化改造（1 期：实现功能：jenkins 分布式架构 + slave 编译环境规划；2 期：基于共享库的 pipeline 优化改造）
    • 发布流程重新设计：流水线定制、JAVA、node 的编译缓存方案设计（用于加速构建）；

  3. 【运维支撑层面】日志系统：

    • 建议避免日志文件落盘，输出到 stdout 或 stderr：可无缝对接阿里云日志服务或者流行开源容器化日志收集系统；
    • 如若保持现有模式日志文件落盘：需精简日志输出、对 pod 设置磁盘容量限制，否则会触发基于 QOS 的异常驱逐导致业务波动；

  4. 【运维支撑层面】监控系统：

    • 云原生支持 Prometheus，跟现有监控方案兼容性很高；改造成本较低

  5. 【运行环境层面】阿里云 k8s 产品调研，关键点：

    • 七层代理 ingress-controller 插件的可用性和扩展性（服务高可用/避免单点、应对业务增长方面考虑）；
      • 评估 AES 必要性（阿里云自研 nginx-ingress-controller 替代产品）
      • 内外网 ingress-controller 是否有规划需求
    • 存储方案设计：虽然 mars 应用均为无状态应用，后期必然有工具类有状态应用容器化，需要提前结合阿里云 paas 产品规划存储方案；（前瞻性考虑）
    • 标准化编排文件定制与版本管理（使用时基于固定模版自动生成或者使用 kustomize 结合 gitlab 进行托管）
    • k8s 版本选型：目前 AKE 未提供 1.20 以上 k8s 版本的 paas 产品，当前最新稳定版 k8s（1.20+）已经去 docker 话，需和阿里云确认后期改造成本（改造过程中的风险点和兼容性考虑）
    • 镜像仓库选型：自建或公有云 paas 产品

  6. 【运行环境层面】k8s 集群使用规划：

    • 各环境运行集群的规划：推荐环境拆分集群，强制网络隔离，降低耦合性；并且降低故障影响范围
    • 基于标准 CNI 接口的网络插件选型（结合阿里云当前支持情况进行 OverLay 与 UnderLay 方案选型评估：Terway 或 Flannel）
    • 全局环境变量或配置（环境级别）的提取与设置（如 apollo 连接地址、通用日志路径、环境标识等）
    • 集群使用的网段规划：在保证与现有的办公网段、公有云已经使用或者将来规划使用的 VPC 网段不重合的基础上，对集群节可用网段做好充足规划应对后期业务增长；
    • 按服务等级或类型进行硬件级别隔离降低故障影响面（基于节点亲和性调度进行规划）

  7. 【实际接入层面】业务切换规划：

    • 任务拆分、排期，按项目实施规范落实
    • 按计划根据关联性分批迁入（边缘性的业务首批迁入，其他业务依次按计划分批迁入）

部分已知难点：

部分已知风险点：