喧嚣之后，关于Kubernetes的一点思考
喧嚣之后，关于Kubernetes的一点思考
1、为什么要用 Kubernetes - 发自灵魂的拷问 ？
理由有很多种，我们可以说 docker 无法解决多进程调度问题，也可以说 Kubernetes 是云时代的操作系统，消除了在设计中考虑底层网络和服务器基础设施的需要，使我们更专注于自己的业务，但无论怎么解释，并没有从正面回答用 Kubernetes 真正原因，比如，公司有一套自动化脚手架工具，拖拖拽拽就可以完成服务的开发和线上部署，这难道不是降低工作量吗？公司有一套虚拟机克隆系统或者第三方云平台，从某种程度上来说，也可以完成服务的扩容，有什么问题吗？
但有一点你要清楚，IT 从来都是一个由新技术驱动的行业；如何理解呢？4G 带来了短视频业务蓬勃发展，5G + AICDE 可以运用到人工智能、IOT、云计算、大数据等行业，4G 难道不能完成这个工作吗？当然是可以的，只不过耗费资源更多、速度更慢、体验更差；就像一个垂垂暮年的老者和活力四射的少年同时过来面试，即便他们具有差不多的能力，让你选，你选谁？当然这些话听起来有点冠冕堂皇，貌似有点道理，但是用了 Kubernetes 能给我们带来哪些实实在在的好处呢？
首先、我最直观的感受，Kubernetes 助力我们搭建了一套 PaaS 平台，就是常说的 平台即服务 。在过去，公司会经常会碰到一些这样的问题，各个产品/项目孤立建设，越建越多，看似没有什么关系，但是也会存在复杂的接口调用和数据传递，时间一久，导致整个 IT 系统和环境日趋复杂，出现问题后大多数修修补补，无法从系统性，全局的角度去解决分析问题。
第二点、资源问题，大多数企业在没有创建 PaaS 平台之前，大多数存在多个中心机房、可能是开发一套、测试一套、甚至各种演示环境..... 开发人员需要给客户演示某个服务，申请一台硬件资源，演示完成之后，这台机器就这样一直躺在那里睡觉了..... 各个团队或者项目申请的资源都是固定的，无论业务忙闲，都无法动态调用底层资源，无法实现物理硬件资源最大化利用。而通过 Kubernetes 能够把所有分离的资源形成资源池，需要的时候动态分配和调用，从而实现 峰谷互补，这样一来解决了资源的闲置问题，当突发访问来临时我们有相应的应对方案。
第三点、部署和扩容问题，面对互联网高速发展的今天，用户群体逐渐庞大，面对海量用户的挑战，传统 IT 架构应对速度和系统运行风险的抵御能力捉襟见肘，传统情况下，部署一个服务去除硬件资源不说，软件资源大多需要运维人员手动部署。速度慢、效率低、而且更容易出错，而通过 Kubernetes 能够解决服务迅速部署和扩容问题，特别是部署，囿于 docker 打包技术，常常能够快速完成从一个环境到另外一个环境服务部署；对于扩容、更是 Kubernetes 的长项、它能在数分钟内完成从一个节点到上百个节点快速扩容。当然这也需要运维人员从传统运维到新型运维的角色转变。
第四点、人力成本问题（领导比较关心的问题）、这一点我先做保留，还没有从直观上感受到使用 Kubernetes 带来了大量人力成本的降低，而且投入了一部分人去研究和学习，业务系统迁移过程中也碰到很多问题。没有对整体的人力成本做量化。IT 系统本身符合 复杂性交换定律 怎么理解呢？ 一个系统中复杂的部分只会做转移，就像我们平时说的系统是无状态，其实并不是系统无状态，只是我们把系统中的状态转移到数据库或等第三方组件中，用第三方组件去解决系统状态问题。但在同时，我们需要维护这些第三方组件。同样的道理，Kubernetes 帮助我们完成了系统的部署、管理、弹性。那么我们就需要对 Kubernetes 这个包含 50w 行代码的庞然大物付出代价。
Kubernetes 确实有很多神奇功能，使得大规模的容器编排更容易管理，重中之重更是解决复杂系统的利器，具体复杂的程度，需要专业人员去评估，特别对于规模比较小的团队，会因为维护它并且因为它的学习曲线陡峭而耗费大量的时间，最后导致维护这一套环境耗费的成本更高，导致我们用轮船拉了摩托车都可以拉完的货物。
2、Kubernetes 能给开发人员带来的挑战和机遇
多数开发人员都会有一个误区，会把 Kubernetes 看作 docker 的上层架构，就好像 Java 和 J2EE 关系一样，J2EE 是以 Java 为基础的企业级架构，Kubernetes 是以 docker 为基础的容器编排平台；甚至认为 Kubernetes 是乱拳打死老司机（docker）。但实际上 Kubernetes 和 docker 存在着更复杂的关系，表面上看 Kubernetes 离不开 docker，实际上 docker 只是 Kubernetes 底层容器技术之一，另外支持 rkt。Kubernetes 之所以能够在和 docker 的这场竞争中一骑绝尘，更大的原因是，Kubernetes 的前身来自于 google 内部的 borg 系统，并不是几个工程师随便研究一段时间得出成果，而是 Google 公司在基础设施领域多年来经验积累的沉淀和升华，这也是 Kubernetes 发布之后，很多人 抱怨 其设计思想超前的原因。
随着 Kubernetes 成为当今 IT 界符合标准且为数不多的热门技术之一，它的影响力会长达数十年，这就导致传统运维终将被历史淘汰，所以我们每个 IT 人员都有理由掌握这门新技术。这门技术的出现最直接的受益人员就是运维，那么对于开发人员，掌握这门技术，有哪些好处呢？
首先在开发系统的过程中我们不用过于关注底层业务无关的代码和功能模块了，我们不必考虑负载均衡器和注册中心的技术选型，更不用考虑选用何种服务治理框架、监控框架，总之通过使用 Kubernetes 提供的解决方案，我们用更多的精力专注于业务代码编写，而且由于 Kubernetes 提供了强大的自动化机制，前期的运维成本和后期的维护成本都将大大降低。
而对于企业来说最关心的是能不能带来收益，学习和使用成本有多高？现在来看 Kubernetes 已经是一门非常成熟的编排技术，各大一线互联网公司已经付出实践，在同时他们也付出了巨大的精力去研究这门技术，我们也要考虑自身有没有足够人力、物力、甚至时间去支持我们研究这门技术，像 Kubernetes 各个功能模块通过插件式管理，不能满足需求时，是否有能力去编写插件，还有像 Kubernetes 部分功能还处在 alpha 阶段（准入控制 PodPreset）.... 这些都应该在使用之前列入到计划范围内。
3、Kubernetes 微服务架构设计带给我们什么帮助？
首先Kubernetes 微服务架构更多体现在它的 Service 设计上，这个微服务其实和平时我们所理解的微服务并不冲突；微服务的本质是把一个大的单体架构拆分为多个微服务，目的是更好的管理和运行，即使你使用了 Kubernetes 这个过程还是要有，所以说 Kubernetes 本身只能说是更好的拥抱微服务架构。如何理解呢？咱们可以从 Kubernetes 提供资源对象能力上来说明。
Kubernetes 里面 Service Cluster IP 非常准确的把握了微服务的本质，从本质上来说，每一个微服务都会包含一个 Socket (IP + Port) 通过这个地址，即可发起连接和访问。Kubernetes 正是为每个 Service 定义了一个固定不变的 IP 地址，这就是 Cluster IP，并引入了 DNS 机制，将每个服务名和 IP 做捆绑，这样使得 Kubernetes Service 对集群其它服务可以通过域名访问，对内（Pod）可以实现服务的路由和负载均衡。
第二点 Kubernetes 自动化功能，其主要实现对象是 Deployment，当我们集群中的某个节点宕机导致 Pod 的副本数量少于期望数量时，节点控制器能够发现该故障并通知 API Server、触发调度、重新计算并选择新的 Node 创建 Pod，而且这个过程是完全自动化的。如果我们想实现服务的扩容，只需要修改 Deployment 对象的 yaml 文件 replics 数量既可，这样扩容完全成了一个数字游戏。另外我们也可以使用 Kubernetes 的 HPA 功能，当服务的 CPU 和内存超过某个指标自动扩容，低于某个指标缩容，这些复杂功能 Kubernetes 都可以自动完成，可见 Kubernetes 自动化能力有多强。
第三点 Kubernetes 的配置中心，在分布式系统下，配置中心一般会选用数据库，配置中心一般会提供相应 http 接口供外部调用，如果需要配置在运行时动态修改并立即生效，则需要引入 zookeeper 等组件来实现配置中心，但这种配置中心属于侵入式设计。它要求每个业务都需要调用特定接口，这样虽然可以完成配置的动态修改，但是却破坏了业务的完整性。而 Kubernetes 的 ConfigMap 利用 volume 数据卷挂载的功能，即映射到容器特定目录上，容器里程序就可以读取此配置文件，在应用看来，好像把配置打包在了容器里。整个过程对应用没有任何侵入。但在使用过程中，要注意两点：
- 环境变量和 subpath 形式不会动态更新配置文件。
- ConfigMap 在Kubernetes 中不存在版本的概念，需要自身维护。
第四点 Kubernetes 的存活和就绪探针，个人认为，这两个设计都是非常实用的功能。在分布式系统中，由于服务数量众多，存在一定程度上的 僵尸服务。通常做法是在接口中添加 ping 命令，属于侵入式设计，检测服务是否存活，如果发现问题，则交由人工处理。而 Kubernetes 探针功能，不仅能够毫无侵入的探测服务是否存在假死现象，当发现服务不正常后，能够自动化删除不正常 Pod 并重新创建。
上述主要是介绍 Kubernetes 微服务框架中比较经典的设计，当然像 StatefulSet 有状态资源类型、持久化存储方案、以 Pormethous 为主的监控方案，更是解决了复杂有状态服务（MySql、redis）的编排和监控。其实我们见过服务类型，Kubernetes 都对其进行资源抽象。回到问题开头，虽然 Kubernetes 更好的拥抱了微服务架构，其实并不能从根本上解决微服务架构一些问题，举个例子微服务架构的一大难题就是分布式事务问题，我们为了提升服务的响应速度，那么会采用缓存或者 MQ 加快数据访问速度，保证数据的最终一致性，这个最终一致性如何保证，其实还要看我们业务自身的设计。
4、总结
本文主要结合 Kubernetes 特点和使用经验，分析 Kubernetes 的优缺点，以及对是否使用 Kubernetes 做出取舍。
推荐