k8s

​

K8s简介

Kubernetes是容器集群管理系统，是一个开源的平台，可以实现容器集群的自动化部署、自动扩缩容、维护等功能。

通过Kubernetes你可以：

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

Kubernetes的特点

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

K8s的历史

众所周知，Kubernetes 是 Google 于 2014 年 6 月基于其内部使用的 Borg 系统开源出来的容器编排调度引擎。其实从 2000 年开始，Google 就开始基于容器研发三个容器管理系统，分别是 Borg、Omega 和 Kubernetes。这篇由 Google 工程师 Brendan Burns、Brian Grant、David Oppenheimer、Eric Brewer 和 John Wilkes 几人在 2016 年发表的《Borg, Omega, and Kubernetes》论文里，阐述了 Google 从 Borg 到 Kubernetes 这个旅程中所获得知识和经验教训。

Google 从 2000 年初就开始使用容器（Linux 容器）系统，Google 开发出来的第一个统一的容器管理系统在内部称之为 “Borg”，用来管理长时间运行的生产服务和批处理服务。由于 Borg 的规模、功能的广泛性和超高的稳定性，一直到现在 Borg 在 Google 内部依然是主要的容器管理系统。

Google 的第二套容器管理系统叫做 Omega，作为 Borg 的延伸，它的出现是出于提升 Borg 生态系统软件工程的愿望。Omega 应用到了很多在 Borg 内已经被认证的成功的模式，但是是从头开始来搭建以期更为一致的构架。由于越来越多的应用被开发并运行在 Borg 上，Google 开发了一个广泛的工具和服务的生态系统。它被应用到了很多在 Borg 内已经被认证的成功的模式，但是是从头开始来搭建以期更为一致的构架。这些系统提供了配置和更新 job 的机制，能够预测资源需求，动态地对在运行中的程序推送配置文件、服务发现、负载均衡、自动扩容、机器生命周期管理、额度管理等。许多 Omega 的创新（包括多个调度器）都被收录进了 Borg。

Google 的第三套容器管理系统就是我们所熟知的 Kubernetes，它是针对在 Google 外部的对 Linux 容器感兴趣的开发者以及 Google 在公有云底层商业增长的考虑而研发的。和 Borg、Omega 完全是谷歌内部系统相比，Kubernetes 是开源的。像 Omega 一样，Kubernetes 在其核心有一个被分享的持久存储，有组件来检测相关 object 的变化。跟 Omega 不同的是，Omega 把存储直接暴露给信任的控制平面的组件，而在 Kubernete 中，提供了完全由特定领域更高层面的版本控制、认证、语义、策略的 REST API 接口，以服务更多的用户。更重要的是，Kubernetes 是由一群底层开发能力更强的开发者开发的，他们主要的设计目标是用更容易的方法去部署和管理复杂的分布式系统，同时仍能从容器提升的效率中受益。

2014 年 Kubernetes 正式开源，2015 年被作为初创项目贡献给了云原生计算基金会（CNCF），从此开启了 Kubernetes 及云原生化的大潮。

2015年左右，Google在美国波特兰的OSCON 2015大会上宣布并正式发布Kubernetes 1.0。Google与Linux基金会合作组建了云原生计算基金会（CNCF）。CNCF旨在为云原生软件构建可持续发展的生态系统，并围绕一系列高质量开源项目建立社区，整合这些开源技术来让编排容器成为微服务架构的一部分。CNCF自创立以来已经拥有非常多的高质量项目，其中包括Kubernetes、Prometheus、gRPC、CoreDNS等。

2016年左右，Kubernetes成为主流。在CloudNativeCon 2016大会上，来自世界各地的约1000名贡献者和开发者齐聚一堂，交流有关Fluentd、Kubernetes、Prometheus、OpenTracing和其他云原生技术的内容。

2017年左右，互联网巨头纷纷表示支持Kubernetes。在这一年，Google和IBM发布微服务框架Istio，其提供了一种无缝连接、管理和保护不同微服务网格的方法。Amazon宣布为Kubernetes提供弹性容器服务，用户可以在AWS上使用Kubernetes部署、管理和扩展容器化应用程序。同年年底，Kubernetes 1.9发布。

2018年左右，无人不知Kubernetes。在KubeCon+CloudNativeCon Europe 2018峰会上，有超过4300名开发者聚集在一起讨论Kubernetes生态技术。同年，Kubernetes 1.10发布。KubeCon第一次在中国举办。

Kubernetes是Google公司开源的一个容器（Container）编排与调度管理框架，该项目最初是Google内部面向容器的集群管理系统，而现在是由Cloud Native Computing Foundation（CNCF，云原生计算基金会）托管的开源平台，由Google、AWS、Microsoft、IBM、Intel、Cisco和Red Hat等主要参与者支持，其目标是通过创建一组新的通用容器技术来推进云原生技术和服务的开发。作为领先的容器编排引擎，Kubernetes提供了一个抽象层，使其可以在物理或虚拟环境中部署容器应用程序，提供以容器为中心的基础架构。

Kubernetes系统拥有一个庞大而活跃的开发人员社区，这使其成为历史上增长最快的开源项目之一。它是GitHub上排名前10的项目，也是Go语言最大的开源项目之一，Kubernetes也被称为K8s，是通过将8个字母ubernete替换为8而形成的缩写。Kubernetes系统具有如下特点。

● 可移植：支持公有云、私有云、混合云、多重云（Multi-cloud）。

● 可扩展：模块化、插件化、可挂载、可组合。

● 自动化：自动部署、自动重启、自动复制、自动伸缩/扩展。

架构

Kubernetes系统用于管理分布式节点集群中的微服务或容器化应用程序，并且其提供了零停机时间部署、自动回滚、缩放和容器的自愈（其中包括自动配置、自动重启、自动复制的高弹性基础设施，以及容器的自动缩放等）等功能。

Kubernetes系统最重要的设计因素之一是能够横向扩展，即调整应用程序的副本数以提高可用性。设计一套大型系统，且保证其运行时健壮、可扩展、可移植和非常具有挑战性，尤其是在系统复杂度增加时，系统的体系结构会直接影响其运行方式、对环境的依赖程度及相关组件的耦合程度。

微服务是一种软件设计模式，适用于集群上的可扩展部署。开发人员使用这一模式能够创建小型、可组合的应用程序，通过定义良好的HTTP REST API接口进行通信。Kubernetes也是遵循微服务架构模式的程序，具有弹性、可观察性和管理功能，可以适应云平台的需求。

Kubernetes的系统架构设计与Borg的系统架构设计理念非常相似，如Scheduler调度器、Pod资源对象管理等。

Kubernetes系统架构遵循客户端/服务端（C/S）架构，系统架构分为Master和Node两部分，Master作为服务端，Node作为客户端。Kubernetes系统具有多个Master服务端，可以实现高可用。在默认的情况下，一个Master服务端即可完成所有工作。

Master服务端也被称为主控节点，它在集群中主要负责如下任务。

（1）集群的“大脑”，负责管理所有节点（Node）。

（2）负责调度Pod在哪些节点上运行。

（3）负责控制集群运行过程中的所有状态。

Node客户端也被称为工作节点，它在集群中主要负责如下任务。

（1）负责管理所有容器（Container）。

（2）负责监控/上报所有Pod的运行状态。

Master服务端（主控节点）主要负责管理和控制整个Kubernetes集群，对集群做出全局性决策，相当于整个集群的“大脑”。集群所执行的所有控制命令都由Master服务端接收并处理。Master服务端主要包含如下组件。

● kube-apiserver组件：集群的HTTP REST API接口，是集群控制的入口。

● kube-controller-manager组件：集群中所有资源对象的自动化控制中心。

● kube-scheduler组件：集群中Pod资源对象的调度服务。

Node客户端（工作节点）是Kubernetes集群中的工作节点，Node节点上的工作由Master服务端进行分配，比如当某个Node节点宕机时，Master节点会将其上面的工作转移到其他Node节点上。Node节点主要包含如下组件。

● kubelet组件：负责管理节点上容器的创建、删除、启停等任务，与Master节点进行通信。

● kube-proxy组件：负责Kubernetes服务的通信及负载均衡服务。

● container组件：负责容器的基础管理服务，接收kubelet组件的指令。

另外，作为开发者，还需要深入了解client-go库。不同组件之间是松耦合架构，各组件之间各司其职，保证整个集群的稳定运行。

Client-go

Kubernetes还提供了通过编程的方式与Kubernetes API Server进行通信。client-go是从Kubernetes的代码中单独抽离出来的包，并作为官方提供的Go语言的客户端发挥作用。client-go简单、易用，Kubernetes系统的其他组件与Kubernetes API Server通信的方式也基于client-go实现

在大部分基于Kubernetes做二次开发的程序中，建议通过client-go来实现与Kubernetes API Server的交互过程。这是因为client-go在Kubernetes系统上做了大量的优化，Kubernetes核心组件（如kube-scheduler、kube-controller-manager等）都通过client-go与Kubernetes API Server进行交互

熟练使用并掌握client-go是每个Kubernetes开发者必备的技能。

Kube-apiserver

kube-apiserver组件，也被称为Kubernetes API Server。它负责将Kubernetes“资源组/资源版本/资源”以RESTful风格的形式对外暴露并提供服务。Kubernetes集群中的所有组件都通过kube-apiserver组件操作资源对象。kube-apiserver组件也是集群中唯一与Etcd集群进行交互的核心组件。例如，开发者通过kubectl创建了一个Pod资源对象，请求通过kube-apiserver的HTTP接口将Pod资源对象存储至Etcd集群中。

Etcd集群是分布式键值存储集群，其提供了可靠的强一致性服务发现。Etcd集群存储Kubernetes系统集群的状态和元数据，其中包括所有Kubernetes资源对象信息、集群节点信息等。Kubernetes将所有数据存储至Etcd集群中前缀为/registry的目录下。

kube-apiserver属于核心组件，对于整个集群至关重要，它具有以下重要特性。

● 将Kubernetes系统中的所有资源对象都封装成RESTful风格的API接口进行管理。

● 可进行集群状态管理和数据管理，是唯一与Etcd集群交互的组件。

● 拥有丰富的集群安全访问机制，以及认证、授权及准入控制器。

● 提供了集群各组件的通信和交互功能。

Kube-controller-manager

kube-controller-manager组件，也被称为Controller Manager（管理控制器），它负责管理Kubernetes集群中的节点（Node）、Pod副本、服务、端点（Endpoint）、命名空间（Namespace）、服务账户（ServiceAccount）、资源定额（ResourceQuota）等。例如，当某个节点意外宕机时，Controller Manager会及时发现并执行自动化修复流程，确保集群始终处于预期的工作状态。

Controller Manager负责确保Kubernetes系统的实际状态收敛到所需状态，其默认提供了一些控制器（Controller），例如DeploymentControllers控制器、StatefulSet控制器、Namespace控制器及PersistentVolume控制器等，每个控制器通过kube-apiserver组件提供的接口实时监控整个集群每个资源对象的当前状态，当因发生各种故障而导致系统状态出现变化时，会尝试将系统状态修复到“期望状态”。

Controller Manager具备高可用性（即多实例同时运行），即基于Etcd集群上的分布式锁实现领导者选举机制，多实例同时运行，通过kube-apiserver提供的资源锁进行选举竞争。抢先获取锁的实例被称为Leader节点（即领导者节点），并运行kube-controller-manager组件的主逻辑；而未获取锁的实例被称为Candidate节点（即候选节点），运行时处于阻塞状态。在Leader节点因某些原因退出后，Candidate节点则通过领导者选举机制参与竞选，成为Leader节点后接替kube-controller-manager的工作。

Kube-scheduler

kube-scheduler组件，也被称为调度器，目前是Kubernetes集群的默认调度器。它负责在Kubernetes集群中为一个Pod资源对象找到合适的节点并在该节点上运行。调度器每次只调度一个Pod资源对象，为每一个Pod资源对象寻找合适节点的过程是一个调度周期。

kube-scheduler组件监控整个集群的Pod资源对象和Node资源对象，当监控到新的Pod资源对象时，会通过调度算法为其选择最优节点。调度算法分为两种，分别为预选调度算法和优选调度算法。除调度策略外，Kubernetes还支持优先级调度、抢占机制及亲和性调度等功能。

kube-scheduler组件支持高可用性（即多实例同时运行），即基于Etcd集群上的分布式锁实现领导者选举机制，多实例同时运行，通过kube-apiserver提供的资源锁进行选举竞争。抢先获取锁的实例被称为Leader节点（即领导者节点），并运行kube-scheduler组件的主逻辑；而未获取锁的实例被称为Candidate节点（即候选节点），运行时处于阻塞状态。在Leader节点因某些原因退出后，Candidate节点则通过领导者选举机制参与竞选，成为Leader节点后接替kube-scheduler的工作。

kubelet

kubelet组件，用于管理节点，运行在每个Kubernetes节点上。kubelet组件用来接收、处理、上报kube-apiserver组件下发的任务。kubelet进程启动时会向kube-apiserver注册节点自身信息。它主要负责所在节点（Node）上的Pod资源对象的管理，例如Pod资源对象的创建、修改、监控、删除、驱逐及Pod生命周期管理等。

kubelet组件会定期监控所在节点的资源使用状态并上报给kube-apiserver组件，这些资源数据可以帮助kube-scheduler调度器为Pod资源对象预选节点。kubelet也会对所在节点的镜像和容器做清理工作，保证节点上的镜像不会占满磁盘空间、删除的容器释放相关资源。

kubelet组件实现了3种开放接口:

• Container Runtime Interface：简称CRI（容器运行时接口），提供容器运行时通用插件接口服务。CRI定义了容器和镜像服务的接口。CRI将kubelet组件与容器运行时进行解耦，将原来完全面向Pod级别的内部接口拆分成面向Sandbox和Container的gRPC接口，并将镜像管理和容器管理分离给不同的服务。
• Container Network Interface：简称CNI（容器网络接口），提供网络通用插件接口服务。CNI定义了Kubernetes网络插件的基础，容器创建时通过CNI插件配置网络。
• Container Storage Interface：简称CSI（容器存储接口），提供存储通用插件接口服务。CSI定义了容器存储卷标准规范，容器创建时通过CSI插件配置存储卷。

Kube-proxy

kube-proxy组件，作为节点上的网络代理，运行在每个Kubernetes节点上。它监控kube-apiserver的服务和端点资源变化，并通过iptables/ipvs等配置负载均衡器，为一组Pod提供统一的TCP/UDP流量转发和负载均衡功能。

kube-proxy组件是参与管理Pod-to-Service和External-to-Service网络的最重要的节点组件之一。kube-proxy组件相当于代理模型，对于某个IP：Port的请求，负责将其转发给专用网络上的相应服务或应用程序。但是，kube-proxy组件与其他负载均衡服务的区别在于，kube-proxy代理只向Kubernetes服务及其后端Pod发出请求。

基本概念

组件

控制平面组件

Master组件提供集群的管理控制中心。

Master组件可以在集群中任何节点上运行。但是为了简单起见，通常在一台VM/机器上启动所有Master组件，并且不会在此VM/机器上运行用户容器。

kube-apiserver

API 服务器是 Kubernetes 控制平面的组件， 该组件负责公开了 Kubernetes API，负责处理接受请求的工作。 API 服务器是 Kubernetes 控制平面的前端

Kubernetes API 服务器的主要实现是 kube-apiserver。 kube-apiserver 设计上考虑了水平扩缩，也就是说，它可通过部署多个实例来进行扩缩。 你可以运行 kube-apiserver 的多个实例，并在这些实例之间平衡流量

Kube-scheduler

kube-scheduler 是控制平面的组件， 负责监视新创建的、未指定运行节点（node）的 Pods， 并选择节点来让 Pod 在上面运行。

调度决策考虑的因素包括单个 Pod 及 Pods 集合的资源需求、软硬件及策略约束、 亲和性及反亲和性规范、数据位置、工作负载间的干扰及最后时限。

Kube-controller-manager

kube-controller-manager 是控制平面的组件， 负责运行控制器进程。

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

这些控制器包括：

• 节点控制器（Node Controller）：负责在节点出现故障时进行通知和响应
• 任务控制器（Job Controller）：监测代表一次性任务的 Job 对象，然后创建 Pods 来运行这些任务直至完成
• 端点分片控制器（EndpointSlice controller）：填充端点分片（EndpointSlice）对象（以提供 Service 和 Pod 之间的链接）。
• 服务账号控制器（ServiceAccount controller）：为新的命名空间创建默认的服务账号（ServiceAccount）。

cloud-controller-manager

一个 Kubernetes 控制平面组件， 嵌入了特定于云平台的控制逻辑。 云控制器管理器（Cloud Controller Manager）允许你将你的集群连接到云提供商的 API 之上， 并将与该云平台交互的组件同与你的集群交互的组件分离开来。

cloud-controller-manager 仅运行特定于云平台的控制器。 因此如果你在自己的环境中运行 Kubernetes，或者在本地计算机中运行学习环境， 所部署的集群不需要有云控制器管理器。

与 kube-controller-manager 类似，cloud-controller-manager 将若干逻辑上独立的控制回路组合到同一个可执行文件中， 供你以同一进程的方式运行。 你可以对其执行水平扩容（运行不止一个副本）以提升性能或者增强容错能力。

下面的控制器都包含对云平台驱动的依赖：

• 节点控制器（Node Controller）：用于在节点终止响应后检查云提供商以确定节点是否已被删除
• 路由控制器（Route Controller）：用于在底层云基础架构中设置路由
• 服务控制器（Service Controller）：用于创建、更新和删除云提供商负载均衡器

Node组件

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

kubelet

kubelet 会在集群中每个节点（node）上运行。 它保证容器（containers）都运行在 Pod 中。

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

kube-proxy

kube-proxy 是集群中每个节点（node）上所运行的网络代理， 实现 Kubernetes 服务（Service） 概念的一部分。

kube-proxy 维护节点上的一些网络规则， 这些网络规则会允许从集群内部或外部的网络会话与 Pod 进行网络通信。

如果操作系统提供了可用的数据包过滤层，则 kube-proxy 会通过它来实现网络规则。 否则，kube-proxy 仅做流量转发。

运行时(Runtime)

容器运行环境是负责运行容器的软件。

Kubernetes 支持许多容器运行环境，例如 containerd、 CRI-O 以及 Kubernetes CRI (容器运行环境接口) 的其他任何实现。

插件

插件使用 Kubernetes 资源（DaemonSet、 Deployment 等）实现集群功能。 因为这些插件提供集群级别的功能，插件中命名空间域的资源属于 kube-system 命名空间。

有几种标配的插件

DNS

尽管其他插件都并非严格意义上的必需组件，但几乎所有 Kubernetes 集群都应该有集群 DNS， 因为很多示例都需要 DNS 服务。

集群 DNS 是一个 DNS 服务器，和环境中的其他 DNS 服务器一起工作，它为 Kubernetes 服务提供 DNS 记录。

Kubernetes 启动的容器自动将此 DNS 服务器包含在其 DNS 搜索列表中。

Web界面

Dashboard 是 Kubernetes 集群的通用的、基于 Web 的用户界面。 它使用户可以管理集群中运行的应用程序以及集群本身， 并进行故障排除

容器资源监控

容器资源监控 将关于容器的一些常见的时间序列度量值保存到一个集中的数据库中， 并提供浏览这些数据的界面。

集群层面日志

集群层面日志机制负责将容器的日志数据保存到一个集中的日志存储中， 这种集中日志存储提供搜索和浏览接口。