dbaplus社群 · 新书抢读-02期-

编者有言：互联网架构不断演化，经历了从集中式架构到分布式架构，再到云原生架构的过程。云原生因能解决传统应用升级缓慢、架构臃肿、无法快速迭代等问题而成了未来云端应用的目标。本期dbaplus社群将和大家一起探索云原生生态下Kubernetes的发展趋势。

 

 

 

本文将带你抢先阅读此书第七章——

云原生生态的基石Kubernetes

（PS：文末有惊喜哦~）

作者介绍

谈到Kubernetes就不得不谈到容器。几年前容器技术大热，现在基本归于平淡，之前大家提到的容器通常是指Docker容器，甚至很多人认为容器就等同于Docker，还有很多人像操作虚拟机一样使用容器。

Kubernetes是Google基于其内部使用的Borg改造而成的一个通用容器编排调度器，于2014年被发布到开源社区，并于2015年被捐赠给Linux基金会下属的云原生计算基金会（CNCF）。

Kubernetes也是GIFEE（Google Infrastructure For Everyone Else）中的一员，GIFEE中的其他成员还有HDFS、HBase、ZooKeeper等。

CNCF中托管的项目一般会遵循一套完善的成长流程，毕竟经过沙盒、孵化和毕业这三个阶段。

Kubernetes是CNCF托管的所有项目中第一个成功毕业的项目，整个CNCF技术栈都是围绕它而建立的。Kubernetes是云原生项目中最重要的组件，其目标不仅仅是成为一个编排系统，更是为用户提供一个规范，让用户可以描述集群的架构，定义服务的最终状态，并让系统自动维持在这个状态。

现如今，云服务已经可以为我们提供非常稳定的基础设施了，但是业务上云却成了一个难题。Kubernetes的出现与其说是为了提供最初的容器编排解决方案，倒不如说是为了解决应用上云（即实现云原生应用）这个难题。

CNCF中托管的一系列项目致力于对云原生应用的整个生命周期进行管理，通过开源软件为用户提供部署平台、日志收集、Service Mesh（服务网格）、服务发现、分布式追踪、监控、安全等各个领域的解决方案。

Kubernetes作为云上的操作系统，能够保证用户的应用在不同的云环境中使用相同的描述语言。

从理论上来讲，所有可以容器化、支持弹性伸缩的分布式应用都可以部署到 Kubernetes集群中。关于Kubernetes的详细配置，各位读者可以参考网络上的资源。

如果用户希望将大量的遗留应用迁移至Kubernetes集群中，应该如何操作呢？下面是简要的步骤，其中有些步骤可以通过CI/CD工具进行简化。

• 将原有的应用拆解为服务。

• 定义服务接口/API的通信方式。

• 编写启动脚本作为容器进程的入口。

• 准备应用的配置文件。

• 将应用容器化并制作容器镜像。

• 准备Kubernetes所使用的YAML文件。

• 如果有外置的配置文件，需要创建ConfigMap或Secret存储。

合理使用Kubernetes能够真正践行DevOps的理念。Kubernetes能够让开发工程师掌握自己的开发环境和测试环境，并且使所有的环境保持一致，进而提升开发效率，让监控更加精准。

以下是Kubernetes的简要应用指南：

• 根据环境（如开发环境、测试环境、生产环境）划分Namespace，也可以根据项目来划分。

• 为每个用户划分独立的Namespace，并且创建独立的Service Account和kubeconfig文件。隔离不同Namespace之间的资源，但不进行网络隔离，使不同Namespace间的服务可以互相访问。

• 创建YAML模板，降低编写Kubernetes YAML文件的难度。

• 在kubectl命令上再封装一层，增加用户身份设置和环境初始化操作，简化kubectl命令和常用功能。

• 管理员通过Dashboard查看不同Namespace的状态，也可以通过它简化相关的运维操作。

• 将所有的应用日志统一收集到Elasticsearch中，统一日志访问入口。

• 可以通过Grafana查看所有Namespace中的应用的状态和Kubernetes集群本身的状态。

• 需要持久化的数据要保存在分布式存储中，例如保存在GlusterFS和Ceph中。

Kubernetes乘着Docker和微服务的东风，一经推出便迅速受到关注，因为它的很多设计思想都契合了微服务和云原生应用的设计法则。

Kubernetes最大的作用是形成了事实上的“云操作系统”标准，以及定义了云应用的规范模型，所有的云原生应用必须遵循它的定义才能够部署和实施。

虽然Kubernetes已经足够强大，但仍然缺失一个重要能力——微服务治理能力。相比于单体式应用，微服务在带来更加轻量级且纯粹的应用系统的同时，也增加了部署和运维的成本，并且对微服务的可观察性也有更高的要求。

其中，如Istio这样的Service Mesh技术便成了解决云原生中的连接、保护、控制和观察服务的重要基础设施。

另外，Kubernetes本身并未提供CI/CD流程，而CI/CD的相关产品是操作系统上层不可或缺的实用工具和管理工具。因此，一大批新兴的云原生工具慢慢出现，并且正在逐渐完善用户体验。

Google通过将云应用进行抽象和简化而形成了Kubernetes，其中的各种概念对象（如Pod、Deployment、Job、StatefulSet等）已然成了云原生应用中的通用型可移植模型。

Kubernetes作为云应用的部署标准，直接面向业务应用，可极大提高云应用的可移植性，进而解决云供应商的问题。它让云应用具有跨云无缝迁移的能力，甚至可以用来管理混合云。目前来看，Kubernetes有很大希望成为下一代云计算的新标准。

如果Kubernetes被企业大量采用，将会重塑企业的IT价值，使IT成为影响业务速度和健壮性的中流砥柱。但是，对于Kubernetes来说，若想使它真正落地，目前还存在诸多问题，具体如下：

• 部署和运维复杂，运维人员往往需要经过专业培训才能够掌握Kubernetes的使用之道。

• 企业的组织架构需要向DevOps转型，很多问题并非技术复杂导致的，而是由管理手段不得当所致。

• 对于服务级别（尤其是微服务）的治理不足，暂时还没有一套切实可行且可落地的完整微服务治理方案。

• 对上层应用的支持不够完善，我们需要编写大量的YAML文件，这样一来管理成本较高。

• 当前很多传统应用可能不适合迁移至Kubernetes，或者迁移成本太高，这样一来，能够落地的项目不多，会影响Kubernetes的大规模推广。

以上是企业真正落地Kubernetes时将会遇到的棘手问题。针对这些问题，Kubernetes社区也在积极解决，社区已经成立了多个SIG（Special Interest Group，特殊兴趣小组），专门负责解决不同领域的问题。很多初创公司和云供应商们正虎视眈眈地觊觎着这巨大的市场份额。

在云原生生态圈的发展历程中，有以下几个关键点，我们一起来看一下：

• 引入服务网格（Service Mesh）：在Kubernetes上实现微服务架构以及进行服务治理时，Service Mesh是必需的组件。

• 落地无服务器架构（Serverless）：以FaaS为代表的无服务器架构将会逐渐流行。

• 加强数据服务承载能力：我们可以通过在Kubernetes上运行大数据应用来实现这一点。

• 简化应用部署与运维：包括简化云应用的监控、日志收集分析等。

上面提到的服务网格、无服务器架构、数据服务承载能力、部署与运维，这些概念目前在Kubernetes生态中已经存在，但是仍然有待加强。若能实现以上几点，我们就能够解决上文中提到的当前云生态中存在的问题。

目前，大部分容器云提供的服务大同小异，主要针对云平台管理、容器应用生命周期管理、DevOps、微服务架构等方面。这些大多是对原有应用的部署和资源申请流程的优化，并未成为“杀手级”的服务，它们依然是原有容器时代的产物。

而容器云进化到云原生这一高级阶段之后，容器技术将成为云平台的基础。虽然各大厂商都声称已经具有全面的功能，但是在推行容器技术时，依然需要结合企业的具体应用场景进行优化。

现今的IaaS（Infrastructure as a Service，基础设施即服务）运营商主要提供基础架构服务，如虚拟机、存储设备、数据库等，这些基础架构服务仍然会使用现有的工具（如Chef、Terraform、Ansible等）来进行管理。

Kubernetes则能够直接在裸机上运行，并结合CI/CD成为DevOps的得力工具，进而成为工程师部署应用的首选。Kubernetes也将成为PaaS（Platform as a Service，平台即服务）的重要组成部分，为开发者提供简单的应用程序部署方法。

但是，开发者可能不会直接与Kubernetes或PaaS交互，实际的应用部署流程将在自动化持续集成工具（如Jenkins）中完成。