使用kubernetes一年以后的思考

本文首发于个人blog

从去年10月份第一次接触kubernetes，到年初系统学习，而后到上个月接手来运维kubernetes集群，也算是对kubernetes有一些了解了。在学习一个技术的时候，对技术的使用场景和发展趋势应该有本身的见解，这样才知道如何结合团队状况和公司的发展合理的采用一个技术。因此这里我宏观上谈一下我对kubernetes技术的一些思考。

kubernetes背景和诞生目的

kubernetes诞生的背景是由于Docker和Paas，对于稍微复杂的业务是不能直接用Docker的，由于Docker提供的能力实在有限，复杂的业务上云通常须要一些平台层面的能力，也就是Paas。kubernetes就是这个背景诞生的，击败了Mesos等竞争对手，成为容器编排领域事实上的标准。

因此按照技术的诞生背景来讲，kubernetes的目的就是要作Paas，因此要玩好kubernetes必须对Paas有个大局观，下图是左耳朵耗子梳理的Paas结构图，我以为挺全面了：

基于kubernetes构建Paas的缘由在于：

1. kubernetes自己提供了一些核心的能力好比服务发现，statefulset，负载均衡，服务状态检查而且自动重启等等；
2. kubernetes提供了一些插件化的机制（CRD，动态准入控制等等）使得DIY，或者加强kubernetes的能力变得简单；
3. kubernetes社区很是活跃，诞生了很是多的高质量项目，好比Prometheus，Rook等等；

由于这几个缘由，基于kubernetes构建Paas变得更加简单。

入手难度

kubernetes入手确实有一些难度，尤为是运维kubernetes集群，不只须要懂kubernetes的知识，还须要懂公有云的使用。基于此，不少公有云厂商推出了kubernetes托管服务，不只下降了kubernetes运维成本，也更好的和已有的服务结合起来（好比阿里云的kubernetes托管服务，再也不须要本身搭建ELK了，可使用阿里云的日志系统）。

可是使用托管服务的时候不要以为用了托管服务了本身的学习成本就下降了，对于kubernetes运维人员仍是须要了解kubernetes的各个组件，了解云供应商各类产品使用。只有这样，才知道如何规划集群的网络，容量，存储等等，才知道业务如何改造才能上kubernetes。

业务如何上kubernetes

这里提三点。

1. 服务须要设置合理的存活探针和就绪探针，这样kubernetes才知道何时杀掉Pod启动一个新的，何时把流量交给Pod。
2. 设置合理的资源request和limit，通常request设置一个应用平均的资源利用值，limit设置一个稍高一些的值。
3. 在线业务和离线业务混部须要额外注意，防止离线业务占用太多node资源致使node资源紧张从而杀掉在线业务。若是作不到这一点就不要作混部，利用nodeselector和toleraions来把在线和离线业务的pod分别部署到对应的node上去。

收益

这大半年用kubernetes的收益是：

• 资源高度弹性。离线业务来的时候申请spot实例，计算完毕以后就会自动回收spot实例，因此离线计算消耗的计算资源价格很是低；
• 更加敏捷。不用找运维申请物理机了，直接部署pod就行了，若是集群的资源不够，会自动扩容，彻底不用担忧计算资源不够的问题；
• 能力复用，尤为是监控的能力，把metric所有导入Prometheus，借助Prometheus+Grafana，整个监控体系很是简单；
• 提升资源利用率，尤为是能够作到业务混部；