Kubernetes in Action 笔记 —— Kuber
Kubernetes 这个名字来自于希腊语，意思是舵手。还是很符合这个平台的作用的。Kubernetes 负责管理部署的应用并报告它们的情况，而用户就像是船长，只需要决定想要整个系统达到怎样的状态。
Kubernetes 是一个负责自动化部署和管理应用的软件系统，主要针对由容器构成的复杂的大型应用系统。
Kubernetes 的基本特性
抽象化基础设施
Infrastructure abstraction
Kubernetes 为用户和应用在底层的硬件之上提供了一个抽象层，底层的基础设施如计算机、网络及其他组件等对应用都是不可见的。用户通过这个抽象层部署和管理应用，不需要再面对每一台特定的机器。因此配置起来更加方便。
标准化部署
由于底层基础设施的具体细节不会再影响到应用的部署，本地数据中心和云环境都可以使用同样的部署方式。任何底层基础设施的差异都交给 Kubernetes 去处理，用户可以只关注产品及其内部逻辑。
声明式部署
Kubernetes 使用声明式的模型来定义具体的应用。用户只需要完成对应用中各组件的描述，Kubernetes 就会将这些描述转化成运行的应用。并在之后保证该应用的健康运行，在必要的时候重启或重新创建某个组件。
Declarative model
Changes in the description
当用户修改了某些描述，Kubernetes 会根据改动自动采取必要的步骤重新配置应用，令应用满足最新的描述。
接管应用的日常管理
一旦用户通过 Kubernetes 部署了某个应用，该应用的日常管理就会被 Kubernetes 接管。假如服务停止运行，Kubernetes 会自动重启该应用；或者由于硬件失效、基础设施架构调整导致该应用需要移动到其他机器上，Kubernetes 也会自行处理。
就像之前提到的，用户类似于船长负责更高层级的决策，而 Kubernetes 则类似于舵手负责执行具体的底层任务。
Kubernetes takes over the management of applications
Kubernetes 与微服务
之前的年头，绝大多数应用都是单体应用。应用里的各个组件是强耦合的，全部运行在同一个进程里。
当应用的容量需要提升时，水平扩展单体应用是非常困难的。只能不断升级服务器的硬件，即垂直扩展。
微服务范式是后来才出现的。单体应用被分割成数十甚至数百个独立的进程（微服务）。每一个微服务都拥有自己所独有的开发和部署周期，不同微服务的依赖会随着时间的推移差距越来越大。这使得在同一个操作系统内部运行两个微服务应用变得非常困难。
容器正好方便解决这个问题。但每个微服务都是一个独立的应用，需要单独进行管理。随着应用数量的上升这将会越来越困难。
整个应用系统的各个部分不需要部署到同一台机器上，这使得扩展起来更加方便。但同时也意味着各组件之间需要配置成能够相互通信的状态。同样增加了维护成本。
因此当微服务的规模变得很大时，自动化管理就显得尤为必要。Kubernetes 则正好提供了这种自动化功能。
Monolithic vs Microservices
Kubernetes 的架构
Kubernetes 可以看作是一个面向服务器集群的操作系统。
操作系统用来支撑计算机的基本功能比如 CPU 调度，作为应用和计算机硬件之间沟通的接口。类似的，Kubernetes 负责在服务器集群的各台机器上调度安排分布式应用的各个组件，作为应用和集群之间的接口。
OS vs Kubernetes
一个 Kubernetes 集群包含两组节点：
- 主节点：负责运行 Control Plane 组件，是系统的大脑，控制整个集群
- 工作节点：组成 Workload Plane，承接应用和负载
Kubernetes cluster
控制平台
Control Plane 负责控制整个集群。它运行在一台主节点上，或者以副本的方式运行在多个主节点上。包含 Scheduler、Controllers、Kubernetes API Server、etcd 等几个组件。
Components of Control Plane
- Kubernetes API Server 负责暴露 RESTful API 接口，用户可以通过此接口创建对象
- etcd 分布式数据仓库负责持久化通过 API 创建的对象，因为 API Server 本身是无状态的。Server 是唯一一个与 etcd 交互的组件
- Scheduler 负责决定每个应用实例具体运行在哪个工作节点上
- Controllers 负责具体化由 API 创建的对象。它们中的大部分实际上就是负责创建其他对象，有一些也会与外部系统进行交互（比如云提供商）
负载平台
工作节点就是实际上运行应用的节点，它们构成了 Workload Plane。负责运行、监控各个应用，并在各应用之间提供连通性。
Workload Plane
其中各组件的功能如下：
- Kubelet：一个与 API Server 进行交互的 agent，负责管理当前节点上运行的应用。会通过 API 向主节点报告应用的状态
- Container Runtime：可以是 Docker 或其他与 Kubernetes 兼容的容器运行时，受 kubelet 指挥，负责运行应用
- Kubernetes Service Proxy：在各应用的网络流量之间提供负载均衡
Kubernetes 的工作流程
Kubernetes 中的所有元素都由对象表示，可以通过 API 创建和获取这些对象。用户需要几种不同的对象来定义自己的应用，通常在 YAML 或 JSON 格式的清单文件中定义。
Deploying an application to Kubernetes
向 Kubernetes 部署应用的具体步骤为：
- 向 Kubernetes API 提交应用的 manifest 文件。API Server 将文件中定义的对象写入 etcd
- controller 接到已经创建了新对象的通知，继续创建几个新的对象，对应不同的应用实例
- Scheduler 为每一个应用实例分配工作节点
- 工作节点上的 Kubelet 接到通知，借助容器运行时运行应用实例
- 应用实例准备好接收客户端请求后，Kube Proxy 收到通知，为这些应用实例配置负载均衡
- 工作节点上的 Kubelets 和 Controllers 负责之后的监控工作，保证应用健康运行
