001.Kubernetes简介

一 Kubernetes概述

 名称 Kubernetes 源于希腊语，意为 “舵手” 或 “飞行员”。Google 在 2014 年开源了 Kubernetes 项目，Kubernetes 是一个可移植的、可扩展的开源平台，用于管理容器化的工作负载和服务，可促进声明式配置和自动化。Kubernetes 拥有一个庞大且快速增长的生态系统。Kubernetes 的服务、支持和工具广泛可用。

1.1 容器发展由来

传统部署时代： 早期，组织在物理服务器上运行应用程序。无法为物理服务器中的应用程序定义资源边界，这会导致资源分配问题。例如，如果在物理服务器上运行多个应用程序，则可能会出现一个应用程序占用大部分资源的情况，结果可能导致其他应用程序的性能下降。一种解决方案是在不同的物理服务器上运行每个应用程序，但是由于资源利用不足而无法扩展，并且组织维护许多物理服务器的成本很高。

虚拟化部署时代： 作为解决方案，引入了虚拟化功能，它允许您在单个物理服务器的 CPU 上运行多个虚拟机（VM）。虚拟化功能允许应用程序在 VM 之间隔离，并提供安全级别，因为一个应用程序的信息不能被另一应用程序自由地访问。

因为虚拟化可以轻松地添加或更新应用程序、降低硬件成本等等，所以虚拟化可以更好地利用物理服务器中的资源，并可以实现更好的可伸缩性。

每个 VM 是一台完整的计算机，在虚拟化硬件之上运行所有组件，包括其自己的操作系统。

容器部署时代： 容器类似于 VM，但是它们具有轻量级的隔离属性，可以在应用程序之间共享操作系统（OS）。因此，容器被认为是轻量级的。容器与 VM 类似，具有自己的文件系统、CPU、内存、进程空间等。由于它们与基础架构分离，因此可以跨云和 OS 分发进行移植。

1.2 容器上网优势

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

1.3 Kubernetes 功能

• 服务发现和负载均衡
  Kubernetes 可以使用 DNS 名称或自己的 IP 地址公开容器，如果到容器的流量很大，Kubernetes 可以负载均衡并分配网络流量，从而使部署稳定。

• 存储编排
  Kubernetes 允许您自动挂载您选择的存储系统，例如本地存储、公共云提供商等。

• 自动部署和回滚
  您可以使用 Kubernetes 描述已部署容器的所需状态，它可以以受控的速率将实际状态更改为所需状态。例如，您可以自动化 Kubernetes 来为您的部署创建新容器，删除现有容器并将它们的所有资源用于新容器。

• 自动二进制打包
  Kubernetes 允许您指定每个容器所需 CPU 和内存（RAM）。当容器指定了资源请求时，Kubernetes 可以做出更好的决策来管理容器的资源。

• 自我修复
  Kubernetes 重新启动失败的容器、替换容器、杀死不响应用户定义的运行状况检查的容器，并且在准备好服务之前不将其通告给客户端。

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

二 Kubernetes 组件

2.1 Master 组件

Master 组件提供集群的控制平面。Master 组件对集群进行全局决策（例如，调度），并检测和响应集群事件（例如，当不满足部署的 replicas 字段时，启动新的 pod）

• kube-apiserver：主节点上负责提供 Kubernetes API 服务的组件；它是 Kubernetes 控制面的前端。
• etcd：etcd 是兼具一致性和高可用性的键值数据库，可以作为保存 Kubernetes 所有集群数据的后台数据库
• kube-scheduler：主节点上的组件，该组件监视那些新创建的未指定运行节点的 Pod，并选择节点让 Pod 在上面运行。
• kube-controller-manager：在主节点上运行控制器的组件。
• cloud-controller-manager：运行与基础云提供商交互的控制器。cloud-controller-manager 二进制文件是 Kubernetes 1.6 版本中引入的 alpha 功能

从逻辑上讲，每个控制器都是一个单独的进程，但是为了降低复杂性，它们都被编译到同一个可执行文件，并在一个进程中运行。

这些控制器包括:

• 节点控制器（Node Controller）: 负责在节点出现故障时进行通知和响应。
• 副本控制器（Replication Controller）: 负责为系统中的每个副本控制器对象维护正确数量的 Pod。
• 端点控制器（Endpoints Controller）: 填充端点(Endpoints)对象(即加入 Service 与 Pod)。
• 服务帐户和令牌控制器（Service Account & Token Controllers）: 为新的命名空间创建默认帐户和 API 访问令牌.

2.2 Node 组件

节点组件在每个节点上运行，维护运行的 Pod 并提供 Kubernetes 运行环境。

• kubelet：一个在集群中每个节点上运行的代理。它保证容器都运行在 Pod 中。

　　　　　　kubelet 接收一组通过各类机制提供给它的 PodSpecs，确保这些 PodSpecs 中描述的容器处于运行状态且健康。kubelet 不会管理不是由 Kubernetes 创建的容器。

• kube-proxy 是集群中每个节点上运行的网络代理,实现 Kubernetes Service 概念的一部分。
• kube-proxy 维护节点上的网络规则。这些网络规则允许从集群内部或外部的网络会话与 Pod 进行网络通信。如果有 kube-proxy 可用，它将使用操作系统数据包过滤层。否则，kube-proxy 会转发流量本身。

• 容器运行环境(Container Runtime)，容器运行环境是负责运行容器的软件，Kubernetes 支持多个容器运行环境: Docker、 containerd、cri-o、 rktlet 以及任何实现 Kubernetes CRI (容器运行环境接口)。

2.3 插件(Addons)

• 插件使用 Kubernetes 资源 (DaemonSet, Deployment等) 实现集群功能。因为这些提供集群级别的功能，所以插件的命名空间资源属于 kube-system 命名空间。
• DNS：尽管并非严格要求其他附加组件，但所有示例都依赖集群 DNS，因此所有 Kubernetes 集群都应具有 DNS，除了环境中的其他 DNS 服务器之外，集群 DNS 还是一个 DNS 服务器，它为 Kubernetes 服务提供 DNS 记录，Cluster DNS 是一个 DNS 服务器，和您部署环境中的其他 DNS 服务器一起工作，为 Kubernetes 服务提供DNS记录，Kubernetes 启动的容器自动将 DNS 服务器包含在 DNS 搜索中。
• Dashboard 是 Kubernetes 集群的通用基于 Web 的 UI。它使用户可以管理集群中运行的应用程序以及集群本身并进行故障排除。
• 容器资源监控将关于容器的一些常见的时间序列度量值保存到一个集中的数据库中，并提供用于浏览这些数据的界面。
• 集群层面日志 机制负责将容器的日志数据保存到一个集中的日志存储中，该存储能够提供搜索和浏览接口。

三 Kubernetes优势、场景、特点

3.1 Kubernetes主要优势

• 容器编排
• 轻量级
• 开源
• 弹性伸缩
• 负载均衡

3.2 Kubernetes常见场景

• 快速部署应用
• 快速扩展应用
• 无缝对接新的应用功能
• 节省资源，优化硬件资源的使用

3.3 Kubernetes相关特点

• 可移植: 支持公有云，私有云，混合云，多重云（multi-cloud）
• 可扩展: 模块化, 插件化, 可挂载, 可组合
• 自动化: 自动部署，自动重启，自动复制，自动伸缩/扩展

四 Kubernetes 架构

4.1 节点

在 Kubernetes 中，节点（Node）是执行工作的机器，以前叫做 minion。根据你的集群环境，节点可以是一个虚拟机或者物理机器。每个节点都包含用于运行 pods 的必要服务，并由主控组件管理。节点上的服务包括 容器运行时、kubelet 和 kube-proxy

节点状态

地址

这些字段组合的用法取决于你的云服务商或者裸机配置。

• HostName：由节点的内核指定。可以通过 kubelet 的 --hostname-override 参数覆盖。
• ExternalIP：通常是可以外部路由的节点 IP 地址（从集群外可访问）。
• InternalIP：通常是仅可在集群内部路由的节点 IP 地址。

4.2 条件

conditions 字段描述了所有 Running 节点的状态。条件的示例包括

节点条件	描述
OutOfDisk	True 表示节点的空闲空间不足以用于添加新 pods, 否则为 False
Ready	表示节点是健康的并已经准备好接受 pods；False 表示节点不健康而且不能接受 pods；Unknown 表示节点控制器在最近 40 秒内没有收到节点的消息
MemoryPressure	True 表示节点存在内存压力 – 即节点内存用量低，否则为 False
PIDPressure	True 表示节点存在进程压力 – 即进程过多；否则为 False
DiskPressure	True 表示节点存在磁盘压力 – 即磁盘用量低，否则为 False
NetworkUnavailable	True 表示节点网络配置不正确；否则为 False

节点条件使用一个 JSON 对象表示。例如，下面的响应描述了一个健康的节点

"conditions": [
  {
    "type": "Ready",
    "status": "True",
    "reason": "KubeletReady",
    "message": "kubelet is posting ready status",
    "lastHeartbeatTime": "2019-06-05T18:38:35Z",
    "lastTransitionTime": "2019-06-05T11:41:27Z"
  }
]

如果 Ready 条件处于状态 Unknown 或者 False 的时间超过了 pod-eviction-timeout（一个传递给 kube-controller-manager 的参数），节点上的所有 Pods 都会被节点控制器计划删除。默认的删除超时时长为5 分钟。某些情况下，当节点不可访问时，apiserver 不能和其上的 kubelet 通信。删除 pods 的决定不能传达给 kubelet，直到它重新建立和 apiserver 的连接为止。与此同时，被计划删除的 pods 可能会继续在分区节点上运行。

在 1.5 版本之前的 Kubernetes 里，节点控制器会将不能访问的 pods 从 apiserver 中强制删除。但在 1.5 或更高的版本里，在节点控制器确认这些 pods 已经在集群停止运行前不会强制删除它们。你可以看到这些处于 Terminating 或者 Unknown 状态的 pods 可能在无法访问的节点上运行。为了防止 kubernetes 不能从底层基础设施中推断出一个节点是否已经永久的离开了集群，集群管理员可能需要手动删除这个节点对象。从 Kubernetes 删除节点对象将导致 apiserver 删除节点上所有运行的 Pod 对象并释放它们的名字。

节点生命周期控制器会自动创建代表条件的污点。 当调度器将 Pod 分配给节点时，调度器会考虑节点上的污点，但是 Pod 可以容忍的污点除外。

4.3 容量与可分配

描述节点上的可用资源：CPU、内存和可以调度到节点上的 pods 的最大数量。

capacity 块中的字段指示节点拥有的资源总量。allocatable 块指示节点上可供普通 Pod 消耗的资源量。

4.4 信息

关于节点的通用信息，例如内核版本、Kubernetes 版本（kubelet 和 kube-proxy 版本）、Docker 版本（如果使用了）和操作系统名称。这些信息由 kubelet 从节点上搜集而来。

4.5 管理

与 pods 和 services 不同，节点并不是在 Kubernetes 内部创建的：它是被外部的云服务商创建，例如 Google Compute Engine 或者你的集群中的物理或者虚拟机。这意味着当 Kubernetes 创建一个节点时，它其实仅仅创建了一个对象来代表这个节点。创建以后，Kubernetes 将检查这个节点是否可用。

4.6 节点控制器

节点控制器是一个 Kubernetes master 组件，管理节点的方方面面。

节点控制器在节点的生命周期中扮演了多个角色。第一个是当节点注册时为它分配一个 CIDR block（如果打开了 CIDR 分配）。

第二个是使用云服务商提供了可用节点列表保持节点控制器内部的节点列表更新。如果在云环境下运行，任何时候当一个节点不健康时节点控制器将询问云服务节点的虚拟机是否可用。如果不可用，节点控制器会将这个节点从它的节点列表删除。

第三个是监控节点的健康情况。节点控制器负责在节点不能访问时（也即是节点控制器因为某些原因没有收到心跳，例如节点宕机）将它的 NodeStatus 的 NodeReady 状态更新为 ConditionUnknown。后续如果节点持续不可访问，节点控制器将删除节点上的所有 pods（使用优雅终止）。（默认情况下 40s 开始报告 ConditionUnknown，在那之后 5m 开始删除 pods。）节点控制器每隔 --node-monitor-period 秒检查每个节点的状态。

4.7 容量与可分配

描述节点上的可用资源：CPU、内存和可以调度到节点上的 pods 的最大数量。

capacity 块中的字段指示节点拥有的资源总量。allocatable 块指示节点上可供普通 Pod 消耗的资源量。

可以在学习如何在节点上保留计算资源的同时阅读有关容量和可分配资源的更多信息。

4.8 信息

关于节点的通用信息，例如内核版本、Kubernetes 版本（kubelet 和 kube-proxy 版本）、Docker 版本（如果使用了）和操作系统名称。这些信息由 kubelet 从节点上搜集而来。

4.9 管理

与 pods 和 services 不同，节点并不是在 Kubernetes 内部创建的：它是被外部的云服务商创建，例如 Google Compute Engine 或者你的集群中的物理或者虚拟机。这意味着当 Kubernetes 创建一个节点时，它其实仅仅创建了一个对象来代表这个节点。创建以后，Kubernetes 将检查这个节点是否可用。例如，如果你尝试使用如下内容创建一个节点：

{
  "kind": "Node",
  "apiVersion": "v1",
  "metadata": {
    "name": "10.240.79.157",
    "labels": {
      "name": "my-first-k8s-node"
    }
  }
}

Kubernetes 会在内部创一个 Node 对象（用以表示节点），并基于 metadata.name 字段执行健康检查，对节点进行验证。如果节点可用，意即所有必要服务都已运行，它就符合了运行一个 pod 的条件；否则它将被所有的集群动作忽略直到变为可用。

注意： Kubernetes 保留无效节点的对象，并继续检查它是否有效。必须显式删除 Node 对象以停止此过程。

当前，有 3 个组件同 Kubernetes 节点接口交互：节点控制器、kubelet 和 kubectl。

4.10 节点控制器

节点控制器是一个 Kubernetes master 组件，管理节点的方方面面。

节点控制器在节点的生命周期中扮演了多个角色。第一个是当节点注册时为它分配一个 CIDR block（如果打开了 CIDR 分配）。

第二个是使用云服务商提供了可用节点列表保持节点控制器内部的节点列表更新。如果在云环境下运行，任何时候当一个节点不健康时节点控制器将询问云服务节点的虚拟机是否可用。如果不可用，节点控制器会将这个节点从它的节点列表删除。

第三个是监控节点的健康情况。节点控制器负责在节点不能访问时（也即是节点控制器因为某些原因没有收到心跳，例如节点宕机）将它的 NodeStatus 的 NodeReady 状态更新为 ConditionUnknown。后续如果节点持续不可访问，节点控制器将删除节点上的所有 pods（使用优雅终止）。（默认情况下 40s 开始报告 ConditionUnknown，在那之后 5m 开始删除 pods。）节点控制器每隔 --node-monitor-period 秒检查每个节点的状态

4.11 心跳机制

Kubernetes 节点发送的心跳有助于确定节点的可用性。 心跳有两种形式：NodeStatus 和 Lease 对象。 每个节点在 kube-node-lease命名空间 中都有一个关联的 Lease 对象。 Lease 是一种轻量级的资源，可在集群扩展时提高节点心跳机制的性能。

kubelet 负责创建和更新 NodeStatus 和 Lease 对象。

• 当状态发生变化时，或者在配置的时间间隔内没有更新时，kubelet 会更新 NodeStatus。 NodeStatus 更新的默认间隔为 5 分钟（比无法访问的节点的 40 秒默认超时时间长很多）。
• kubelet 会每 10 秒（默认更新间隔时间）创建并更新其 Lease 对象。Lease 更新独立于 NodeStatus 更新而发生

4.12 可靠性

在 Kubernetes 1.4 中我们更新了节点控制器逻辑以更好地处理大批量节点访问 master 出问题的情况（例如 master 的网络出了问题）。从 1.4 开始，节点控制器在决定删除 pod 之前会检查集群中所有节点的状态。

大部分情况下，节点控制器把驱逐频率限制在每秒 --node-eviction-rate 个（默认为 0.1）。这表示它每 10 秒钟内之多从一个节点驱逐 Pods。

当一个可用区域中的节点变为不健康时，它的驱逐行为将发生改变。节点控制器会同时检查可用区域中不健康（NodeReady 状态为 ConditionUnknown 或 ConditionFalse）的节点的百分比。如果不健康节点的部分超过 --unhealthy-zone-threshold （默认为 0.55），驱逐速率将会减小：如果集群较小（意即小于等于 --large-cluster-size-threshold 个 节点 - 默认为 50），驱逐操作将会停止，否则驱逐速率将降为每秒 --secondary-node-eviction-rate 个（默认为 0.01）。在单个可用区域实施这些策略的原因是当一个可用区域可能从 master 分区时其它的仍然保持连接。如果你的集群没有跨越云服务商的多个可用区域，那就只有一个可用区域整个集群）。

在多个可用区域分布你的节点的一个关键原因是当整个可用区域故障时，工作负载可以转移到健康的可用区域。因此，如果一个可用区域中的所有节点都不健康时，节点控制器会以正常的速率 --node-eviction-rate 进行驱逐操作。在所有的可用区域都不健康（也即集群中没有健康节点）的极端情况下，节点控制器将假设 master 的连接出了某些问题，它将停止所有驱逐动作直到一些连接恢复。

从 Kubernetes 1.6 开始，NodeController 还负责驱逐运行在拥有 NoExecute 污点的节点上的 pods，如果这些 pods 没有容忍这些污点。此外，作为一个默认禁用的 alpha 特性，NodeController 还负责根据节点故障（例如节点不可访问或没有 ready）添加污点。请查看这个文档了解关于 NoExecute 污点和这个 alpha 特性。

从版本 1.8 开始，可以使节点控制器负责创建代表节点条件的污点。

4.13 节点自注册

当 kubelet 标志 --register-node 为 true （默认）时，它会尝试向 API 服务注册自己。这是首选模式，被绝大多数发行版选用。

4.14 手动节点管理

集群管理员可以创建及修改节点对象。

如果管理员希望手动创建节点对象，请设置 kubelet 标记 --register-node=false。

管理员可以修改节点资源（忽略 --register-node 设置）。修改包括在节点上设置 labels 及标记它为不可调度。

节点上的 labels 可以和 pods 的节点 selectors 一起使用来控制调度，例如限制一个 pod 只能在一个符合要求的节点子集上运行。

4.15 节点容量

节点的容量（cpu 数量和内存容量）是节点对象的一部分。通常情况下，在创建节点对象时，它们会注册自己并报告自己的容量。如果你正在执行手动节点管理，那么你需要在添加节点时手动设置节点容量。

Kubernetes 调度器保证一个节点上有足够的资源供其上的所有 pods 使用。它会检查节点上所有容器要求的总和不会超过节点的容量。这包括由 kubelet 启动的所有容器，但不包括由 container runtime 直接启动的容器，也不包括在容器外部运行的任何进程。