完成容器化的普及之后，越来越多的业务部门参与到云原生的体系中。相比技术本身而言，研发人员的思维转变在整个体系化建设中更为重要。在实际落地过程中，我们接触到了很多开源的组件，也尝试了各种实现方式，最终挑选了一套更像是在旧流程上的升级，而不是颠覆的组件。

代码托管与编译

保留了很多年一直在使用的 Gitlab+Jenkins pipline 模式。我们是在新项目上试用过一段时间的 Gitlab CI 模式，但是新旧共存的方式对仓库管理员造成了一定程度的困扰。于是我们放弃了这个模式，直接在 Jenkins pipline 中增加了编译后代码打包推送到指定的中间仓库，编译后的文件夹以版本号命令，并添加了一些 md5 校验码。

容器仓库

Harbor (goharbor.io)

Harbor is an open source registry that secures artifacts with policies and role-based access control, ensures images are scanned and free from vulnerabilities, and signs images as trusted. 

Harbor 是一直使用的 Docker 仓库。我们选择 Harbor，一方面是刚好满足我们带 basic-auth 私有仓库建设的需要；另一方面其 UI 对容器不熟练的同事来说是比较友好的。我们根据实际的需要，也配置了 LDAP、镜像复制等服务。

Ingress

API Management Solution for Enterprise | Kong Inc. (konghq.com)

我们使用了差不多两年的 traefikhttps://doc.traefik.io/traefik/之后，逐步转向了 Kong Ingress Controller。早在使用 Kubernetes 之前，我们业务上就在使用 Kong 作为 web 和 api 服务的转发。得益于 Kong 社区的发展，我们后面可以以较小代价接入到 Kong Ingress。

在使用过程中，我们 Kong UI 和 API 混合使用。部署业务时，脚本自动向 Kong 注册应用相关信息；UI 可以让不是很熟练这块流程的同事快速掌握。另外，Kong 提供的的 Monitor、Logging、Trace 相对 traefik 来说是有优势的。

Helm

Helm

Helm is the best way to find, share, and use software built for Kubernetes.

Helm 已经逐渐成为容器应用中默认的打包工具。在实际业务中，Kubernetes yaml 文件或者 API 模式去部署一个应用对操作人的要求较高。我们需要一个工具，它在整个程序版本迭代中应该是快速、完整并且是简单的---于是我们选择了 Helm。

Helm 打包将一个应用依赖的 deployment、configmap、service、pvc 等资源打包在一起，推送到仓库后，管理起来比 yaml 模式方便很多。刚好 Harbor 也是支持 Helm Chart 包管理，和之前的 Docker 仓库刚好复用在一起。

KubeOperator

KubeOperator 是一个开源的轻量级 Kubernetes 发行版，专注于帮助企业规划、部署和运营生产级别的 Kubernetes 集群。

KubeOperator 是我们自建 IDC 机房用于快速构建 Kubernetes 集群的工具。虽然绝大部分业务都已经在公有云中，但是线上依然有一些没上云的服务。对于这些服务，我们使用 Kubernetes 的目的是希望更加统一、简单化的管理业务。我们自建过，也试用过 Rancher，只是最终选择了 KubeOperator。

结束语

我们不期望 Kubernetes 能替我们解决各种问题，我们的初衷是能更系统、简单化地管理我们的应用。