注意：Kubernetes 是希腊语中的 “领航员”或“舵手 ”的意思。

将应用拆解为多个微服务

大型单体应用正被逐渐分解成小的、可独立运行的组件，我们称之为微服务。

微服务的扩容

面向单体系统，扩容针对的是整个系统，而面向微服务架构，扩容却只需要针对单个服务。

介绍容器技术

开发者不是使用虚拟机来隔离每个微服务环境（或者通常说的软件进程）， 而是正在转向 Linux 容器技术。在容器里的进程是和其他进程隔离的。
一个容器仅仅是运行在宿主机上被隔离的单个进程， 仅消耗应用容器消耗的资源， 不会有其他进程的开销。

比较虚拟机和容器

和虚拟机比较， 容器更加轻量级，低消耗。

在虚拟机技术中，运行在虚拟机里的应用程序会执行虚拟机内核的系统调用， 然后虚拟机内核会通过管理程序（hypervisor）在宿主机上的物理CPU执行x86指令。

容器则会完全执行宿主机上的内核的系统调用， 此内核是唯一一个在宿主机操作系统上执行x86指令的内核。

注意：存在两种类型的hypervisor。 第一种类型的管理程序不会使用宿主机OS, 而笫二种类型的会。

容器实现隔离机制介绍

有两个机制可用：
1）Linux Namespaces： 它使每个进程只看到它自己的系统视图（文件、进程、网络接口、主机名等）。隔离进程资源
2）Linux Control Groups (cgroups)：它限制了进程能使用的资源量 (CPU、 内存、 网络带宽等）。限制进程资源

1. 用 Linux 命名空间隔离进程

对于一个进程， 可以在其中一个命名空间中运行它。进程将只能看到同一个命名空间下的资源。

存在以下类型的命名空间：

• Mount (mnt)：文件系统
• Process ID (pid)
• Network (net)：网络接口
• Inter-process communication (ipc)
• UTS：主机名
• User ID (user)

2. 限制进程的可用资源

cgroups 是一个 Linux 内核功能， 它被用来限制一个进程或者一组进程的资源使用。一个进程的资源(CPU、 内存、 网络带宽等）使用量不能超出被分配的量。

注意：Docker本身并不提供进程隔离，实际上容器隔离是在Linux内核之上使用诸如Linux命名空间和cgroups之类的内核特性完成的， Docker仅简化了这些特性的使用。

Docker 的概念

Docker 是一个打包、 分发和运行应用程序的平台。

• 镜像（Image）： Docker镜像里包含了你打包的应用程序及其所依赖的环境。
• 镜像仓库（Registry）： Docker镜像仓库用于存放Docker镜像。
• 容器（Container）：Docker容器通常是一个Linux容器， 它基于Docker镜像被创建。一个运行中的容器是一个运行在Docker主机上的进程，且和其他进程都是隔离的。

构建、 分发和运行Docker镜像

镜像层

不同的镜像都能使用相同的父镜像作为它们的基础镜像。 这提升了镜像在网络上的分发效率， 当传输某个镜像时，因为相同的层已被之前的镜像传输， 那么这些层就不需要再被传输。

层不仅使分发更高效， 也有助于减少镜像的存储空间。每一层仅被存一 次， 当基于相同基础层的镜像被创建成两个容器时， 它们就能够读相同的文件。

容器镜像层是只读的，容器运行时， 一个新的可写层在镜像层之上被创建。 容器中进程写入位于底层的一个文件时， 此文件的一个拷贝在顶层被创建， 进程写的是此拷贝。

容器镜像可移植性的限制

1）内核版本的限制
如果一个容器化的应用需要一个特定的内核版本， 那它可能不能在每台机器上都工作。 如果一台机器上运行了 一个不匹配的Linux内核版本， 或者没有相同内核模块可用，那么此应用就不能在其上运行。

2）硬件架构的限制
一个在特定硬件架构之上编译的容器化应用， 只能在有相同硬件架构的机器上运行。 不能将一个x86架构编译的应用容器化后， 又期望它能运行在ARM架构的机器上。

注意：虚拟机没有这些局限性

rkt —— 一个Docker的替代方案

rkt (发音为”rock-it”)是另外一个Linux容器引擎。和Docker一样， rkt也是一个运行容器的平台。

Kubernetes 的核心功能

整个系统由 个主节点（master node）和若干个工作节点（worker node）组成，开发者把一个应用列表提交到主节点， Kubernetes 会将它们部署到集群的工作节点。

Kubernetes 来提供服务，包括服务发现、扩缩容、负载均衡、自恢复，甚至领导者的选举。

Kubernetes 集群架构

在硬件级别， Kubernetes 集群由很多节点组成，分两种类型：

• 主节点 （master node），它承载 Kubernetes 控制和管理整个集群系统的Control Plane 。
• 工作节点（worker node），它们运行用户实际部署的应用。

Control Plane (控制平面)

Control Plane用于控制集群并使它工作。它包含多个组件，组件可以运行在单个主节点上或者通过副本分别部署在多个主节点以确保高可用性 这些组件是：
• API Server，你和其他控制平面组件都要和它通信。
• Scheculer ，它调度你的应用（为每个可部署的应用组件分配一个工作节点）。
• Controller Manager，它执行集群级别的功能，如复制组件、持续跟踪工作节点、处理节点失败等。
• etcd ，一个可靠的分布式数据存储，它能持久化存储集群配置。

控制平面的组件持有并控制集群状态，但是它们不运行你的应用程序。这是由工作节点完成的。

Worker node

工作节点是运行容器化应用的机器。运行、监控和管理应用服务的任务是由以下组件完成的：
• Docker 、rtk 或其他 container runtime，它们运行你的容器。
• Kubelet ，它与 API Server通信，并管理它所在节点的容器。
• Kubernetes Service Proxy (kube-proxy） ，它负责在应用组件之间负载均衡网络流量。

在Kubernetes 中运行应用

为了在 Kubernetes 中运行应用，首先需要将应用打包进一个或多个容器镜像，再将那些镜像推送到镜像仓库，然后将应用的描述发布到 Kubemetes API Server。

该描述包括诸如容器镜像或者包含应用程序组件的容器镜像、这些组件如何相互关联，以及哪些组件需要同时运行在同一个节点上和哪些组件不需要同时运行等信息。此外，该描述还包括哪些组件为内部或外部客户提供服务且应该通过单个 IP地址暴露 ，并使其他组件可以发现。

描述信息（description）怎样成为一个运行的容器

当API Server 处理应用的描述时，Scheduler 调度指定容器组（pod）到可用的工作节点上，调度是基于每组所需的计算资源，以及调度时每个节点未分配的资源。然后，那些节点上的 Kubelet 指示Container Runtime 例如 Docker ）拉取所需的镜像并运行容器。

仔细看图 1.10 以更好地理解如何在 Kubernetes 中部署应用程序。应用描述符列出了四个容器，并将它们分为三组（这些集合被称为 pod ）。 前两个 pod 只包含一个容器，而最后一个包含两个。这意味着两个容器都需要协作运行 ，不应该相互隔离。在每 pod 旁边，还可以看到一个数字，表示需要并行运行的每个 pod 副本数量。在向 Kubernetes 提交描述符之后，它将把每个 pod 的指定副本数调度到可用的工作节点上。节点上的 Kubelet 将告知Docker 从镜像仓库中拉取容器镜像井运行容器

保持容器运行

一旦应用程序运行起来， Kubernetes 会不断地确认应用程序的部署状态始终与你提供的描述相匹配。

例如，如果你指出你需要运行五个 web 服务器实例，那么Kubernetes 总是保持正好运行五个实例。如果实例之一停止了正常工作，比如当进程崩溃或停止响应时， Kubernetes 将自动重启它。同理，如果整个工作节点死亡或无法访问， Kubernetes 将为在故障节点上运行的所有容器选择新节点，并在新选择的节点上运行它们。

扩展副本数量

当应用程序运行时，可以决定要增加或减少副本量 ，而 Kubernetes 将分别增加附加的或停止多余的副本。甚至可以把决定最佳副本数目的工作交给 Kubernetes。它可以根据实时指标（如 CPU 负载、内存消耗、每秒查询或应用程序公开的任何其他指标）自动调整副本数。

命中移动目标

为了让客户能够轻松地找到提供特定服务的容器，可以告诉 Kubernetes 哪些容器提供相同的服务，而 Kubernetes将通过一个静态 IP 地址暴露所有容器，并将该地址暴露给集群中运行的所有应用程序。这是通过环境变量完成的，但是客户端也可以通过良好的 DNS 查找服务 IP。kube-proxy 将确保到服务的连接可跨越提供服务的容器实现负载均衡。服务的 IP 地址保持不变，因此客户端始终可以连接到它的容器，即使它们在集群中移动。

使用 Kubernetes 的好处

• 简化应用程序部署
• 更好地利用硬件
• 健康检查和自我修复
• 自动伸缩（AUTOMATIC SCALING）：比如 HPA
• 简化应用程序开发