趣店容器进化史

简介 > 趣店的容器化进程经历过三个里程碑：docker、单集群脚本化管理、多集群平台化管理。为了兼顾日常业务的需求开发，每一个里程均是由小部分人主导推动，由点及面地进行推广，并通过在小范围的试错中寻找最适合趣店业务场景的容器化方案。容器化为趣店的服务隔离及服务器统一化管理提供了基础条件，并且通过容器化迁移为趣店每月节省至少10万元服务器费用。（由于迁移工作以PHP服务作为试点，因此本文中的案例亦是以PHP为主） 趣店容器进化史快速预览图 Docker > 作为容器化推进的第一阶段，此阶段由开发主导，推广开发及测试环境容器化使用，并进行小部分服务线上容器化试用。 Docker入门 > 容器化推进初期，此时我们内部对于容器较为了解的人员并不多，开发不知道应 流量交易 该如何使用容器，运维对于如何维护容器下的服务也没有经验，因此在这个阶段我们着重对全体开发人员及运维人员进行初级容器入门分享，分享主要包括以下几个方面： Docker环境搭建 > 主要用于引导开发人员搭建本地Docker开发环境，进行初步的容器概念建模。 Docker命令解析 docker命令解析分享资料 > 该分享主要讲解Docker的常用指令、拆解容器的部署流程并简要介绍通过Swarm进行集群部署的方式。 Dockerfile最佳实践 > 分享如何以更优雅的方式编写Dockerfile。 Docker编排 > 我们的部分开发人员尝试更深层次地应用容器化，例如基于docker-compose推广docker在本地开发环境落地。这一推广对于微服务一类单个项目依托于多个服务的开发环境部署提供了极大的便利，同时也在开发环境的使用中进一步深化大家对容器的理解。在这一阶段开发了简易的K8s编排脚本，对新上线的小服务尝试使用K8s部署服务。 单集群脚本化管理 > 考虑到容器化仍处于尝试阶段且需要进行定制化脚本开发，因此第二阶段仍是以开发作为主导。本阶段开始对主要服务的小流量环境进行容器化迁移，通过开发更完善的K8s编排脚本以优化服务的持续集成与部署。 容器化服务迁移 > 随着全员对容器认知水平的提高，在这一阶段我们的小部分开发开始尝试进行线上小流量环境的迁移，迁移过程也曾遇到一些问题。 坑 CoreDNS负载异常导致部分请求错误 > 现象：在这一阶段的迁移过程中由于K8s的CoreDNS负载异常，我们已迁移服务曾出现短暂的不可用（因服务分区部署的关系我们及时将部署于K8s服务的服务流量摘除） > > 解决方案：容器化迁移是各方（运维、开发、K8s服务提供商）的磨合阶段，在这一阶段应提前准备及演练运行于K8s的服务异常情况下的流量切换方案。由于业务服务对K8s基础服务的强依赖关系，基础服务的监控、异常转移均需提前完善及演练。 镜像管理 > 镜像管理作为容器化迁移不可或缺的一部分，自建的镜像仓库能够更好的保障内部服务镜像的安全性（镜像可能包含服务源码），且部署于内网的镜像仓库能够极大提高部署速度。为简化镜像的管理与维护，我们在内网部署开源的Harbor服务管理内部镜像。 CI/CD > 在这一阶段我们通过自研的脚本（集成编排文件生成、镜像构建、部署）及Jenkins实现服务的CI/CD。由于这一阶段的CI/CD流程仍是试验阶段并无十分完善，这里暂时不展开叙述，较为完善的流程可参考下一阶段迁移的CI/CD。 日志收集 编排日志 > 编排日志目前我们没有特意收集，大部分情况下还是部署或者调度出现问题的时候由运维进入集群内通过Kubectl查看日志情况。 容器日志 > 由于大部分服务的日志都是往指定目录输出，目前并没有很好的利用容器的标准输出作为容器内部服务日志输出的统一出口，所以容器日志当前仍处于待挖掘阶段。 服务日志 - Nginx - PHP > 除去常规的Nginx access_log，我们在迁移过程中还需要重点关注Nginx error_log及PHP error_log，极少部分请求可能会因迁移过程中的操作不当而引发异常，此时可通过排查服务的错误日志及时发现并修复问题。 业务日志 > 由于我们的业务日志输出并无统一规范，因此无法通过常规的容器标准输出采集日志，而是通过Volume的方式将Pod的输出日志挂载至节点主机目录，再通过节点主机的Filebeat + Kafka将日志统一收集至日志服务器。 监控 宿主机资源监控（Master、Node） > 主机的资源监控包括：CPU、内存、磁盘、网卡流量等等，尽可能详细地收集主机监控信息对于异常情况下的问题排查有着极大的帮助。 基础组件监控（如：CoreDNS） > 围绕于集群服务的各种基础组件：kube-apiserver、kube-controller-manager、kube-scheduler、kubelet、kube-proxy、CoreDNS等等，也需要纳入监控范围，避免因为单个基础组件的异常影响整个集群内部业务服务的稳定性。 Pod - Nginx - PHP-FPM > Pod部署了可用于输出Nginx-FPM和PHP实时状态的Exporter，通过常规的Prometheus + Grafana方案实现K8s服务的监控。 网络拓扑   NodePort     Service     Pod   > 在这一阶段考虑到现有服务是逐步迁移，为保持原有线上灰度测试方案的可用性，并未使用常规的Ingress作为外部流量的入口。 多集群平台化管理 > 最终阶段我们基于开源平台进行二次定制化开发，由运维、开发共同主导。这一阶段的主要工作是通过定制化开发打通 开发-测试-审批-线上部署 的完整流程，并对现有的线上服务全量迁移至K8s集群。