01 | 健康之路 kubernetes(k8s) 实践之路 : 开篇及概况

近几年容器相关的技术大行其道，容器、docker、k8s、mesos、service mesh、serverless等名词相信大家多少都有听过，国内互联网公司无一不接触和使用相关技术。

健康之路早在2016年就启动了容器化的评估。眼观现在容器化相关技术的稳定性和可行性也得到了很多的验证，在这样的前提下我们启动了容器化实践之路。

当然在实践的过程中我们也不乏遇到了一些问题，我们希望通过文字来记录和分享我们遇到的一些事情，也希望为大家的容器化之路带来帮助。

概要

目标读者

此系列文章不会涉及到很多的k8s技术，只涉及到我们最终定案和使用的方案。并且文章不会从头开始，会假设大家对k8s有一定了解有一些基础，最佳的目标读者是正在应用k8s初期和准备应用k8s的公司。

因为k8s的生态非常好，相关文章也特别多，入门及介绍文章、文档非常的多，大家可以自行的去补充相关的知识。

但有一个很重要的问题是没有完整的生产可用的系列文章，很多是针对k8s能力的技术文章和实现剖析。

就算有大厂的应用案例文章但谈及的粒度也比较粗只能提供一个大概的解决思路细的问题还要需要自己去摸索。

刚接触k8s该如何学习？

如果大家刚入门k8s推荐主看官方文档（英文）不要因为英文而怯步，通过翻译软件基本可以大致看懂。原因呢很简单：k8s发展的非常迅速，只有官方文档才是最可靠的，很多内容已经是过时的了。

辅助的话大家可以去搜寻一些系列文章（一样的零散的文章因为k8s的版本不一致而容易造成困扰），本人是通过XX时间上的k8s系列课程入门的，推荐刚入门的同学可以先从这个系列开始。对k8s有一定的掌握力后根据系列课程的内容再去k8s官方文档上加强学习一遍。

近期阿里云有推出了一个系列课程：《CNCF × Alibaba 云原生技术公开课》(XX时间上面系列的作者也在其中哦)目前还在更新中，内容也写得非常好可以在用来加强学习一下。

我们目前做了什么？

Fleet（自研，基于k8s打造的公司适用的容器运维和持续集成系统）

公司微服务框架的升级（兼容k8s引入后的原微服务调用）

生产线高可用k8s集群搭建

服务器资源（CPU、内存）紧张时频繁宕机的优化和避免

高可用BGP ClusterIP和PodIP及通过交换机打通现有网络与k8s集群内网络的互通

全局容器hosts

Java8（JVM）在容器中的调优和优化

PHP容器化

简单的监控和告警（Prometheus + Grafana）

技术选型

• 编排系统：kubernetes（当前版本1.14.1）
• CRI：Docker（当前版本18.09.4）
• CNI：Calico（当前版本3.7.2）
• Image Registry：Harbor（当前版本1.7.5，准备升级1.8.0）
• 负载均衡：LVS、HAProxy
• 集群引导：kubeadm（当前版本1.14.1）
• 监控告警：Prometheus + Grafana
• Fleet
• 后端：Java8 + Spring全家桶 + fabric8io kubernetes-client
• 前端：TypeScript + React + Ant Design Pro

k8s部署方式的选择

我们之前有考虑过两种方案进行k8s集群的部署。

1. 物理机+k8s
2. 虚拟机+k8s

最终我们选择了虚拟机+k8s。

因为我们觉得虚拟机带来的损耗是我们可以忍受的。一些性能的损耗换来较好的维护性这是我们想要的。

我们的现状

由于早期的技术正确选型，公司在以微服务的架构方式进行开发已经经历了很长的时间。

所以我们的大部分应用都是无状态的。这点为我们迁移k8s带来了非常多的帮助（总所周知有状态的应用程序是非常难迁移的，同样在k8s中也显得比较麻烦）。

所以如果大家现在大部分的应用还是有状态的，可以先考虑进行应用重构在考虑迁移至k8s。

开发线（整体迁移进行中）

在开发线我们基本上已经可以迁移到k8s上，也正在逐步回收资源，将回收后的资源逐步加入k8s中，目前运行了80天左右，最后一次故障在一个月前（开发线资源紧张，因为资源紧张触发了一个node频繁宕机的小坑，后面会有专门的篇幅跟大家详细分享），已稳定运行了30天左右。

目前我们的开发线k8s集群因为资源关系不是高可用的。

master一台（etcd堆叠）

node五台

harbor一台

总计7台虚拟机

应用情况

服务器资源情况

生产线（边缘应用迁移）

在生产线我们腾挪了一部分资源用来搭建高可用的k8s集群环境。

同时我们在生产线的动作也比较保守，目前迁移了小部分边缘应用（非核心业务）到生产线。同时公司RP微服务组件使用的是TCP长连接也踩了一个负载均衡的小坑目前还在优化兼容中。后面会有详细的篇幅来说明这个问题。

由于生产线资源比较充足至搭建完成没有发生过k8s故障（中间有因为网络策略配置失误导致了一小段服务不可访问）。

目前已稳定运行53天。

master三台

node四台

etcd三台

harbor两台

lvs两台

haproxy两台

总计17台虚拟机

应用情况

服务器资源情况

我们的不足和后续要做的事情

我们目前没有使用到CSI相关的内容，我们目前也不支持有状态的应用程序。后续我们会考虑建立Ceph集群来加入这块的能力。

我们目前也没有使用Ingress能力（我们目前采用Service的ClusterIP），后续根据急迫程度可能会考虑加入Ingress能力。

我们目前没有做日志收集（目前是依赖程序自己的日志传输逻辑自行查看或通过Fleet系统的控制台日志功能WebShell功能进行诊断）

我们目前的构建系统比较固定，没有那么灵活，后续可能会引入Drone等第三方构建系统进行构建。

.net core的容器化

有没有系列大纲？下一篇会分享什么？

抱歉，我实在没有那么强的全局观去梳理出全部的分享大纲。我会根据我们遇事的大致顺序进行分享。我会在每篇的结尾写出下一篇大概会分享什么内容。

下一篇应该会分享：高可用k8s集群搭建的内容，不会详细的说明搭建步骤（会分享我们目前的拓补图、高可用测试方案等内容），此系列的主要目标读者还是有一定基础的同学，会点到为止。

最后

首先是感谢。感谢领导CTO和经理的鼎立支持和协调。感谢k8s社区带来的优秀能力和文档。

ps：分享的所有内容不一定完全是我的成果，其中我们的小伙伴也一直在支持这个项目。

如果大家有疑问和需要交流的可以通过评论功能或私信我（推荐优先使用评论，评论的内容也是读者的一笔财富）。

关于Fleet

Fleet系统是我们公司自研的一套容器运维和持续构建系统。

系统的后续出现方式未定。

Fleet系统我们是有分期规划的。

目前处在2期进行中（1期是基本满足公司开发人员迁移到k8s的日常运维和使用）。

下面是部分系统截图