第一章 Kubernetes介绍

Kubernetes官方学习地址

一、Kubernetes是什么？

Kubernetes 是一个可移植、可扩展的开源平台，用于管理容器化的工作负载和服务，可促进声明式配置和自动化。 Kubernetes 拥有一个庞大且快速增长的生态，其服务、支持和工具的使用范围相当广泛。
Kubernetes 这个名字源于希腊语，意为“舵手”或“飞行员”。k8s 这个缩写是因为 k 和 s 之间有八个字符的关系。 Google 在 2014 年开源了 Kubernetes 项目。 Kubernetes 建立在Google 大规模运行生产工作负载十几年经验的基础上， 结合了社区中最优秀的想法和实践。
让我们回顾一下为何 Kubernetes 能够裨益四方。

传统部署时代：
早期，各机构是在物理服务器上运行应用程序。 由于无法限制在物理服务器中运行的应用程序资源使用，因此会导致资源分配问题。 例如，如果在物理服务器上运行多个应用程序， 则可能会出现一个应用程序占用大部分资源的情况，而导致其他应用程序的性能下降。 一种解决方案是将每个应用程序都运行在不同的物理服务器上， 但是当某个应用程式资源利用率不高时，剩余资源无法被分配给其他应用程式， 而且维护许多物理服务器的成本很高。

虚拟化部署时代：
因此，虚拟化技术被引入了。虚拟化技术允许你在单个物理服务器的 CPU 上运行多台虚拟机（VM）。 虚拟化能使应用程序在不同 VM 之间被彼此隔离，且能提供一定程度的安全性， 因为一个应用程序的信息不能被另一应用程序随意访问。
虚拟化技术能够更好地利用物理服务器的资源，并且因为可轻松地添加或更新应用程序， 而因此可以具有更高的可伸缩性，以及降低硬件成本等等的好处。
每个 VM 是一台完整的计算机，在虚拟化硬件之上运行所有组件，包括其自己的操作系统（OS）。

容器部署时代：
容器类似于 VM，但是更宽松的隔离特性，使容器之间可以共享操作系统（OS）。 因此，容器比起 VM 被认为是更轻量级的。且与 VM 类似，每个容器都具有自己的文件系统、CPU、内存、进程空间等。 由于它们与基础架构分离，因此可以跨云和 OS 发行版本进行移植。
容器因具有许多优势而变得流行起来。下面列出的是容器的一些好处：

• 敏捷应用程序的创建和部署：与使用 VM 镜像相比，提高了容器镜像创建的简便性和效率。
• 持续开发、集成和部署：通过快速简单的回滚（由于镜像不可变性）， 提供可靠且频繁的容器镜像构建和部署。
• 关注开发与运维的分离：在构建、发布时创建应用程序容器镜像，而不是在部署时， 从而将应用程序与基础架构分离。
• 可观察性：不仅可以显示 OS 级别的信息和指标，还可以显示应用程序的运行状况和其他指标信号。
• 跨开发、测试和生产的环境一致性：在笔记本计算机上也可以和在云中运行一样的应用程序。
• 跨云和操作系统发行版本的可移植性：可在 Ubuntu、RHEL、CoreOS、本地、 Google Kubernetes Engine 和其他任何地方运行。
• 以应用程序为中心的管理：提高抽象级别，从在虚拟硬件上运行 OS 到使用逻辑资源在 OS 上运行应用程序。
• 松散耦合、分布式、弹性、解放的微服务：应用程序被分解成较小的独立部分， 并且可以动态部署和管理 - 而不是在一台大型单机上整体运行。
• 资源隔离：可预测的应用程序性能。

• 资源利用：高效率和高密度。

  二、为什么需要 Kubernetes？

  传统的容器编排痛点

  容器技术虽然解决了应用和基础设施异构的问题，让应用可以做到一次构建，多次部署，但在复杂的微服务场景，单靠 Docker 技术还不够，它仍然有以下问题没有解决：

• 集成和编排微服务模块

• 提供按需自动扩容，缩容能力
• 故障自愈

• 集群内的通信

  Kubernetes 能解决的问题

• 按需的垂直扩容，新的服务器(node)能够轻易的增加或删除

• 按需的水平扩容，容器实例能够轻松扩容，缩容
• 副本控制器，你不用担心副本的状态
• 服务发现和负载均衡 Kubernetes 可以使用 DNS 名称或自己的 IP 地址来曝露容器。 如果进入容器的流量很大， Kubernetes 可以负载均衡并分配网络流量，从而使部署稳定。
• 存储编排 Kubernetes 允许你自动挂载你选择的存储系统，例如本地存储、公共云提供商等。
• 自动部署和回滚 你可以使用 Kubernetes 描述已部署容器的所需状态， 它可以以受控的速率将实际状态更改为期望状态。 例如，你可以自动化 Kubernetes 来为你的部署创建新容器， 删除现有容器并将它们的所有资源用于新容器。
• 自动完成装箱计算 Kubernetes 允许你指定每个容器所需 CPU 和内存（RAM）。 当容器指定了资源请求时，Kubernetes 可以做出更好的决策来为容器分配资源。
• 自我修复 Kubernetes 将重新启动失败的容器、替换容器、杀死不响应用户定义的运行状况检查的容器， 并且在准备好服务之前不将其通告给客户端。

• 密钥与配置管理 Kubernetes 允许你存储和管理敏感信息，例如密码、OAuth 令牌和 ssh 密钥。 你可以在不重建容器镜像的情况下部署和更新密钥和应用程序配置，也无需在堆栈配置中暴露密钥。

  什么时候使用 Kubernetes？

• 当你的应用是微服务架构

• 开发者需要快速部署自己的新功能到测试环境进行验证

• 降低硬件资源成本，提高使用率

  什么时候不适合使用 Kubernetes

• 应用是轻量级的单体应用，没有高并发的需求

• 团队文化不适应变革

  三、Kubernetes 的边界

  Kubernetes 不是传统的、包罗万象的 PaaS（平台即服务）系统。 由于 Kubernetes 是在容器级别运行，而非在硬件级别， 它提供了 PaaS 产品共有的一些普遍适用的功能， 例如部署、扩展、负载均衡、日志记录和监视。 但是，Kubernetes 不是单体式（monolithic）系统，那些默认解决方案都是可选、可插拔的。 Kubernetes 为构建开发人员平台提供了基础，但是在重要的地方保留了用户选择权，能有更高的灵活性。
  Kubernetes：

• 不限制支持的应用程序类型。 Kubernetes 旨在支持极其多种多样的工作负载，包括无状态、有状态和数据处理工作负载。 如果应用程序可以在容器中运行，那么它应该可以在 Kubernetes 上很好地运行。

• 不部署源代码，也不构建你的应用程序。 持续集成（CI）、交付和部署（CI/CD）工作流取决于组织的文化和偏好以及技术要求。
• 不提供应用程序级别的服务作为内置服务，例如中间件（例如消息中间件）、 数据处理框架（例如 Spark）、数据库（例如 MySQL）、缓存、集群存储系统 （例如 Ceph）。这样的组件可以在 Kubernetes 上运行，并且/或者可以由运行在 Kubernetes 上的应用程序通过可移植机制 （例如开放服务代理）来访问。
• 不是日志记录、监视或警报的解决方案。 它集成了一些功能作为概念证明，并提供了收集和导出指标的机制。
• 不提供也不要求配置用的语言、系统（例如 jsonnet），它提供了声明性 API， 该声明性 API 可以由任意形式的声明性规范所构成。
• 不提供也不采用任何全面的机器配置、维护、管理或自我修复系统。
• 此外，Kubernetes 不仅仅是一个编排系统，实际上它消除了编排的需要。 编排的技术定义是执行已定义的工作流程：首先执行 A，然后执行 B，再执行 C。 而 Kubernetes 包含了一组独立可组合的控制过程， 可以连续地将当前状态驱动到所提供的预期状态。 你不需要在乎如何从 A 移动到 C，也不需要集中控制，这使得系统更易于使用 且功能更强大、系统更健壮，更为弹性和可扩展。

四、与Docker的关系*

Docker以“Docker镜像”的方式一举解决了应用打包和发布这一困扰业界多年的技术难题，并且大大降低了普通开发人员运维部署应用的门槛。正是因为解决了应用打包这个根本性的问题，才使得Docker很快就被广大开发/运维人员所接受，迅速成为炙手可热的技术，并在一定时间内引领了容器化技术发展的浪潮。
那么Docker这么好用为什么还会出现Kubernetes呢？事实是Docker作为单一的容器技术工具并不能很好地定义容器的“组织方式”和“管理规范”，难以独立地支撑起生产级大规模容器化部署的要求。因此容器技术的发展就迅速走向了以Kubernetes为代表的“容器编排”的技术路线，而这也是为什么Docker容器没有直接在生产环境中大规模部署的关键原因。
上面我们提到了“容器编排”的概念，了解到相对于Docker单一容器技术而言，Kubernetes容器编排技术可以很好地实现大规模容器的组织和管理，从而使容器技术实现了从“容器”到“容器云”的飞跃！那么Kubernetes技术是从何而来？而又真正解决了什么问题呢？

• 从背景上说，Kubernetes是由Google与RedHat公司共同主导的开源“容器编排”项目，它起源于Google公司的Borg系统。所以它在超大规模集群管理方面的经验要明显优于其他容器编排技术，加上Kubernetes在社区管理方面的民主化，使得它很快打败了Docker公司推出的容器编排解决方案(Compose+Swarm)，从而成为了容器编排领域事实上的标准。
• 而在功能上Kubernetes是一种综合的基于容器构建分布式系统的基础架构环境，它不仅能够实现基本的拉取用户镜像、运行容器，还可以提供路由网关、水平扩展、监控、备份、灾难恢复等一系列运维能力，而更重要的是Kubernetes可以按照用户的意愿和整个系统的规则，高度自动化的处理好容器之间的各种关系实现“编排”能力。

• 此外Kubernetes的出现也重新定义了微服务架构的技术方向，通常所说的“云原生”及“Service Mesh(服务网格)”等概念，很大程度上也是依赖于Kubernetes所提供的基础能力。

  Kubernetes整体系统架构

  前面我们简单介绍了Kubernetes的起源和背景，接下来看看Kubernetes的整体系统架构，如下图所示：
  
  如上图所示，Kubernetes在架构上主要由Master和Node两种类型的节点组成，这两种节点分别对应着控制节点和计算节点。其中Master即控制节点，是整个Kubernetes集群的大脑，主要负责编排、管理和调度用户提交的作业，并能根据集群系统资源的整体使用情况将作业任务自动分发到可用Node计算节点。具体看Master节点主要由三个紧密协作的独立组件组合而成，它们分别是：

• kube-apiserver：是Kubernetes集群API服务的入口，主要提供资源访问操作、认证、授权、访问控制及API注册和发现等功能机制。

• kube-scheduler：负责Kubernetes的资源调度，能按照预定的调度策略将Pod调度到相应的机器上。
• kube-controller-manager：负责容器编排及Kubernetes集群状态的维护，例如故障检测、自动扩展、滚动更新等。

需要说明的是，上述组件在工作状态下还会产生许多需要进行持久化的数据，这些数据会通过kube-apiserver处理后统一保存到Etcd存储服务中。所以从这个角度看kube-apiserver不仅是外部访问Kubernetes集群的入口，也是维护整个Kubernetes集群状态的信息中枢。

而在Kubernetes计算节点中，除了上述3个系统组件外，其他基本与Master节点相同，而其中最核心的部分就是kubelet组件。它的核心功能具如下：

• 通过CRI（Container Runtime Interface）远程接口同容器运行时（如Docker）进行交互，对容器生命周期进行维护。其中CRI接口会定义了容器运行时的各项核心操作，例如启动容器所需的命令及参数等。
• 通过GRPC协议同Device Plugin插件交互，实现Kubernetes对宿主机物理设备的管理。
• 此外kubelet另一个重要的功能则是通过CNI（Container Networking Interface）来调用网络插件为容器配置网络，以及通过CSI（Container Storage Interface）和存储插件交互为容器配置持久化存储。

在Kubernetes中kubelet会通过CRI接口同容器运行时进行交互，而容器运行时则通过OCI容器运行时规范与底层Linux操作系统进行交互（涉及对Namespace、Cgroups等资源的操作）。需要强调的是，这里所说的容器运行时并不仅仅指Docker，而是所有实现了CRI接口规范的容器项目都可以作为Kubernetes的容器运行时存在。这是因为Kubernetes从设计之初就没有把Docker作为整个架构的核心，而只是将其作为最底层的一个容器运行时来实现。
但这并不是说Kubernetes就完全抛弃Docker了，要知道Docker最大的成功并不是它的容器运行时技术，而是它定义的“容器镜像”开创性地解决了困扰业界多年的应用打包难题，所以虽然Kubernetes并不完全依赖于Docker的容器运行时技术，但容器镜像的定义标准却是所有容器技术都绕不开的存在。
况且从Kubernetes架构设计上看，Kubernetes并没有打算重复造轮子而对已有的容器技术进行替代，它更关注的是对运行在大规模集群中的各种任务根据其关系进行作业编排及管理，所以任何实现了CRI、CNI、CSI等协议标准的容器技术都可以无缝地与Kubernetes集成。从这个角度看，Docker与Kubernetes的关系并不是替代的关系，而是平台与组件的关系，Kubernetes可以利用现有的Docker容器运行时技术，但却并不完全依赖Docker。而这也正是Kubernetes为什么被称作容器编排技术而不仅仅只是容器技术的原因。

Kubernetes容器编排概述

我们说处理任务之间的各种关系，实现容器编排是Kubernetes的核心技术能力，也是其大规模流行的关键原因。那么容器编排到底是个什么概念？在Kubernetes中是如何实现容器编排的呢？
其实所谓容器编排，通俗点举例就是如果两个应用调用关系比较紧密，那么我们希望运行时将它们部署在同一台机器上，从而提升服务之间的通信效率。而能够支持自动将具有此类关系的应用，以容器的方式部署在同一台机器上的技术就是容器编排。
当然，这里所说的紧密关系只是一种形象的说法，实际的技术场景中这种紧密关系可以被划分为很多类型，例如Web应用与数据库之间的访问关系、负载均衡和它后端服务之间的代理关系、门户应用与授权组件之间的调用关系等。
而对于Kubernetes来说，这样的关系描述显然还是过于具体，因为Kubernetes的设计目标不仅仅是能够处理前面提到的所有类型的关系，还要能够支持未来可能出现的更多种类的关系。这就要求Kubernetes要从更宏观地角度来定义任务之间的各种关系，并且能为将来支持更多种类的关系留有余地。
具体来说，Kubernetes是对容器间的访问进行了分类，如果这些应用之间需要非常频繁的交互和访问，或者它们之间存在直接通过本地文件进行信息交换的情况，那么在Kubernetes中可以将这些容器划分为一个“Pod”，而Pod中的容器将共享同一个Network Namespace、同一组数据卷，从而实现高效率通信。
Pod是Kubernetes中最基础的编排对象，是Kubernetes最小的调度单元，也是Kubernetes实现容器编排的载体，其本质上是一组共享了某些系统资源的容器集合。在Kubernetes中围绕Pod可以延伸出其他核心概念，具体如下图所示：

如上图所示，在Kubernetes中Pod解决了容器间紧密协作（即编排）的问题，而Pod要实现一次启动多个Pod副本就需要Deployment这个Pod多实例管理器；而有了这样一组Pod后，我们又需要通过一个固定网络地址以负载均衡的方式访问它，于是又有了Service。
而根据不同的编排场景Pod又衍生出描述一次性运行任务的Job编排对象、描述每个宿主机上必须且只能运行一个副本的守护进程服务DaemonSet、描述定时任务的CronJob编排对象、以及针对有状态应用的StatefulSet等多种编排对象。而这些编排对象正是Kubernetes定义容器间关系和形态的主要方法。