在拥有了一个基础设施完善的Kubernetes集群之后，想必大家就想把以前的服务以及后续的服务一股脑儿的搬到k8s集群里面了，然后指望着k8s就能自由的调度服务没有后顾之忧了。实际上这才只是开始，还欠缺很多东西。
规划namespace
首先建议大家先规划一下如何分配namespace，这点非常的重要，否则你用着用着就会发现namespace会越来越多，并且越用越随意，最后完全无法管理。
目前我们公司namespace的规划是这样的。
1、每个项目都单独创建namespace，这个项目下的所有服务都放到这个namespace里面，这样不同项目之间资源就不会冲突，而且给研发人员分配权限的时候也好处理，当然也可以按照：项目名-dev、项目名-test、项目名-release，这种方式来把一个项目的不同环境区分出来。
2、所有的工具服务全部丢到tools这个namespace下面，包括gitlab、drone、harbor、metersphere等，所有的工具都由运维人员统一管理，当然也可以分的更新一些，比如test-tools表示测试用的工具等。
3、创建一个temp的命名空间，这个命名空间专门用来创建一些临时的测试用的容器，但是随时可能会被删除。
4、有一些chart包会限定namespace的就按照文档要求创建，一般这样的服务不会太多。
5、所有的演示用的项目都放到一个归档的namespace下面，这些服务一般不会改动了，仅作为演示使用。当一个项目完成之后，其服务也可以搬到归档用的namespace下面。
以上这些只是我们公司的一些规范，仅供参考，如果大家有其他的更好的规范也可以提出来一起学习一下。
规划CICD
kubernetes对程序员而言其实是不友好的，毕竟打包、打镜像、部署，这比直接java -jar可麻烦多了。所以我们要规划好CICD，减少程序员与Kubernetes的直接打交道。
CICD工具的话也比较多，传统的如jenkins，gitlab-ci等，都是可以的。之前有过一段时间使用jenkins，但总觉的太重了（至于JenkinsX那沉重的简直离了大谱），而且还要写大段的脚本。然后在一次意外的服务器崩溃，脚本数据丢失之后我就干脆抛弃了jenkins，选择了更轻量级的Drone CI作为CICD工具。
Drone CI分为两个部分，一个是Drone Server，它对接gitlab并且提供可视化界面。一个是Drone Runner，它从Server接收build请求，然后进行处理。对于中小型的团队来说Drone CI绝对是够用了。
只需要在项目里面定义一个.drone.yml就可以自动进行项目的构建与打包了，非常的方便，一开始连CD我也是通过Drone来做，直到有一天无意间看到GitOps这个概念，然后发现了ArgoCD这个神奇的玩意儿。
ArgoCD的作用主要是从git仓库中读取kubenetes使用的例如yaml文件，然后把git仓库里面的yaml文件的信息同步到Kubernetes集群中，并且还能做消息通知。这就带来了一个很大的好处，可以直接看到每次更新deployment的信息了，并且把服务迁移到其他集群里面的时候，这些yaml文件就可以直接使用了，避免了要重写yaml文件的尴尬。
后面我会详细描述一下我是如何通过Drone CI和ArgoCD来搭建公司的CICD流程的。
