本文首发于我的blog
从去年10月份第一次接触kubernetes，到年初系统学习，然后到上个月接手来运维kubernetes集群，也算是对kubernetes有一些了解了。在学习一个技术的时候，对技术的使用场景和发展趋势应该有自己的看法，这样才知道如何结合团队情况和公司的发展合理的采用一个技术。所以这里我宏观上谈一下我对kubernetes技术的一些思考。
kubernetes背景和诞生目的
kubernetes诞生的背景是因为Docker和Paas，对于稍微复杂的业务是不能直接用Docker的，因为Docker提供的能力实在有限，复杂的业务上云一般需要一些平台层面的能力，也就是Paas。kubernetes就是这个背景诞生的，击败了Mesos等竞争对手，成为容器编排领域事实上的标准。
所以按照技术的诞生背景来说，kubernetes的目的就是要做Paas，所以要玩好kubernetes必须对Paas有个大局观，下图是左耳朵耗子梳理的Paas结构图，我觉得挺全面了：
基于kubernetes构建Paas的原因在于：
- kubernetes本身提供了一些核心的能力比如服务发现，statefulset，负载均衡，服务状态检查并且自动重启等等；
- kubernetes提供了一些插件化的机制（CRD，动态准入控制等等）使得DIY，或者增强kubernetes的能力变得简单；
- kubernetes社区非常活跃，诞生了非常多的高质量项目，比如Prometheus，Rook等等；
因为这几个原因，基于kubernetes构建Paas变得更加简单。
入手难度
kubernetes入手确实有一些难度，尤其是运维kubernetes集群，不仅需要懂kubernetes的知识，还需要懂公有云的使用。基于此，很多公有云厂商推出了kubernetes托管服务，不仅降低了kubernetes运维成本，也更好的和已有的服务结合起来（比如阿里云的kubernetes托管服务，不再需要自己搭建ELK了，可以使用阿里云的日志系统）。
但是使用托管服务的时候不要觉得用了托管服务了自己的学习成本就降低了，对于kubernetes运维人员还是需要了解kubernetes的各个组件，了解云供应商各种产品使用。只有这样，才知道如何规划集群的网络，容量，存储等等，才知道业务如何改造才能上kubernetes。
业务如何上kubernetes
这里提三点。
- 服务需要设置合理的存活探针和就绪探针，这样kubernetes才知道什么时候杀掉Pod启动一个新的，什么时候把流量交给Pod。
- 设置合理的资源request和limit，一般request设置一个应用平均的资源利用值，limit设置一个稍高一些的值。
- 在线业务和离线业务混部需要额外注意，防止离线业务占用太多node资源导致node资源紧张从而杀掉在线业务。如果做不到这一点就不要做混部，利用nodeselector和toleraions来把在线和离线业务的pod分别部署到对应的node上去。
收益
这大半年用kubernetes的收益是：
- 资源高度弹性。离线业务来的时候申请spot实例，计算完毕之后就会自动回收spot实例，所以离线计算消耗的计算资源价格非常低；
- 更加敏捷。不用找运维申请物理机了，直接部署pod就好了，如果集群的资源不够，会自动扩容，完全不用担心计算资源不够的问题；
- 能力复用，尤其是监控的能力，把metric全部导入Prometheus，借助Prometheus+Grafana，整个监控体系非常简单；
- 提高资源利用率，尤其是可以做到业务混部；
近期评论