【容器架构】理解Kubernetes架构：综合指南

这本关于Kubernetes架构的全面指南旨在通过插图详细解释每个Kubernete组件。

因此，如果您希望：

1. 了解Kubernetes的体系结构
2. 掌握Kubernetes的基本概念
3. 了解Kubernetes架构组件
4. 探索连接这些组件的工作流

然后你会发现这个Kubernetes体系结构指南非常宝贵。

注意：为了更好地理解Kubernetes架构，有一些先决条件。请查看Kubernete学习指南中的先决条件以了解更多信息。

什么是Kubernetes架构？

下面的Kubernetes体系结构图显示了Kubernete集群的所有组件，以及外部系统如何连接到Kubernets集群。

Kubernetes架构图
关于Kubernetes，您首先应该了解的是，它是一个分布式系统。也就是说，它有多个组件，分布在网络上的不同服务器上。这些服务器可以是虚拟机或裸机服务器。我们称之为Kubernetes集群。

Kubernetes集群由控制平面节点和工作节点组成。

控制平面

控制平面负责容器编排并维护集群的所需状态。它包含以下组件。

• kube apiserver
• etcd
• kube调度器
• kube控制器经理
• 云控制器管理器

一个集群可以具有一个或多个控制平面节点。

Worker节点

Worker节点负责运行容器化的应用程序。工作节点具有以下组件。

• kubelet
• kube代理
• 容器运行时

Kubernetes控制平面组件

首先，让我们来看看每个控制平面组件以及每个组件背后的重要概念。

1.kube apiserver

kube-api服务器是Kubernetes集群的中心枢纽，它公开了Kubernetesneneneba api。它具有高度的可扩展性，可以处理大量并发请求。

最终用户和其他集群组件通过API服务器与集群通信。很少有监控系统和第三方服务可以与API服务器进行交互。

因此，当您使用kubectl来管理集群时，在后端，您实际上是通过HTTPRESTAPI与API服务器进行通信。但是，内部集群组件（如调度器、控制器等）使用gRPC与API服务器进行通信。

API服务器与群集中的其他组件之间的通信通过TLS进行，以防止对群集的未经授权的访问。

Kubernetes架构-kube apiserver解释
Kubernetes api服务器负责以下工作。

• API管理：公开集群API端点并处理所有API请求。API为版本，同时支持多个API版本。
• 身份验证（使用客户端证书、承载令牌和HTTP基本身份验证）和授权（ABAC和RBAC评估）
• 处理API请求并验证API对象（如pod、服务等）的数据（验证和突变允许控制器）
• 它是唯一与etcd通信的组件。
• api服务器协调控制平面和工作节点组件之间的所有进程。
• api服务器有一个内置的apiserver代理。它是API服务器进程的一部分。它主要用于允许从集群外部访问ClusterIP服务，即使这些服务通常只能在集群内部访问。
• API服务器还包含一个聚合层，允许您扩展Kubernetes API以创建自定义API资源和控制器。
• API服务器还支持监视资源以进行更改。例如，客户端可以对特定资源建立监视，并在创建、修改或删除这些资源时接收实时通知

安全注意：为了减少集群攻击面，保护API服务器的安全至关重要。Shadowserver基金会进行了一项实验，发现了38万台可公开访问的Kubernetes API服务器。

2.etcd

Kubernetes是一个分布式系统，它需要一个高效的分布式数据库，如etcd，以支持其分布式特性。它同时充当后端服务发现和数据库。你可以称之为Kubernetes集群的大脑。

etcd是一个开源的强一致性分布式密钥值存储。那么这意味着什么呢？

• 强一致性：如果对某个节点进行更新，则强一致性将确保该节点立即更新到群集中的所有其他节点。同样，如果你看看CAP定理，实现100%的可用性与强一致性和&分区容差是不可能的。
• 分布式：etcd被设计为在不牺牲一致性的情况下作为集群在多个节点上运行。
• 键值存储：将数据存储为键值的非关系数据库。它还公开了一个键值API。数据存储是在BboltDB之上构建的，BboltDB是BoltDB的一个分支。
   

etcd采用raft一致性算法，具有较强的一致性和可用性。它以领先成员的方式工作，以实现高可用性并承受节点故障。

那么etcd是如何与Kubernetes协同工作的呢？

简单地说，当你使用kubectl来获取kubernetes对象的详细信息时，你就是从etcd中获取的。此外，当您部署像pod这样的对象时，会在etcd中创建一个条目。

简而言之，以下是您需要了解的关于etcd的内容。

• etcd存储Kubernetes对象的所有配置、状态和元数据（pod、secret、daemonsets、deployment、configmap、statefulsets等）。
• etcd允许客户端使用Watch（）API订阅事件。Kubernetes api服务器使用etcd的监视功能来跟踪对象状态的变化。
  etcd使用gRPC公开密钥值API。此外，gRPC网关是一个RESTful代理，它将所有HTTP API调用转换为gRPC消息。这使它成为Kubernetes的理想数据库。
• etcd以键值格式将所有对象存储在/registry目录项下。例如，默认名称空间中名为Nginx的pod的信息可以在/register/pods/default/Nginx下找到
• kubernetes如何在etcd中存储数据

此外，etcd它是控制平面中唯一的Statefulset组件。

3.kube调度器

kube调度器负责在工作节点上调度Kubernetes pod。

部署pod时，您需要指定pod要求，如CPU、内存、相关性、污染或容忍度、优先级、持久卷（PV）等。调度器的主要任务是识别创建请求，并为满足要求的pod选择最佳节点。

下图显示了调度程序如何工作的高级概述。

高级kubernetes调度器工作流程图。
在Kubernetes集群中，将有多个工作节点。那么，调度器是如何从所有工作节点中选择节点的呢？

以下是调度程序的工作方式。

1. 为了选择最佳节点，Kube调度器使用过滤和评分操作。
2. 在过滤中，调度器会找到最适合pod调度的节点。例如，如果有五个工作节点具有运行pod的资源可用性，则它会选择所有五个节点。如果没有节点，则pod是不可调度的，并移动到调度队列中。如果它是一个大型集群，比如说100个工作节点，并且调度器不会迭代所有节点。有一个名为percentageOfNodesToScore的调度程序配置参数。默认值通常为50%。因此，它尝试以循环方式迭代50%的节点。如果工作节点分布在多个区域中，那么调度器会在不同区域中的节点上迭代。对于非常大的集群，NodesToScore的默认百分比为5%。
3. 在评分阶段，调度器通过为过滤后的工作节点分配分数来对节点进行排名。调度器通过调用多个调度插件来进行评分。最后，将选择具有最高级别的工作节点来调度pod。如果所有节点具有相同的秩，则将随机选择一个节点。
4. 一旦选择了节点，调度程序就会在API服务器中创建绑定事件。意味着绑定pod和节点的事件。
    

以下是您需要了解的关于调度器的信息。

 

1. 它是一个控制器，用于侦听API服务器中的pod创建事件。
    
2. 调度程序有两个阶段。调度周期和绑定周期。它一起被称为调度上下文。调度周期选择一个工作节点，绑定周期将该更改应用于集群。
3. 调度器总是将高优先级吊舱放置在低优先级吊舱之前进行调度。此外，在某些情况下，在pod开始在选定节点中运行后，pod可能会被逐出或移动到其他节点。如果你想了解更多，请阅读Kubernetes pod优先级指南
4. 您可以创建自定义调度程序，并在集群中与本机调度程序一起运行多个调度程序。部署pod时，可以在pod清单中指定自定义调度程序。因此，调度决策将基于自定义调度程序逻辑进行。
5. 调度器有一个可插入的调度框架。这意味着，您可以将自定义插件添加到调度工作流中。
    

4.Kube控制器经理

什么是控制器？控制器是运行无限控制循环的程序。这意味着它连续运行并观察物体的实际和期望状态。如果实际状态和所需状态存在差异，则可以确保kubernetes资源/对象处于所需状态。

根据官方文件，

在Kubernetes中，控制器是监视集群状态的控制循环，然后在需要的地方进行或请求更改。每个控制器都试图将当前集群状态移动到更接近所需状态的位置。

假设您想要创建一个部署，您可以在清单YAML文件中指定所需的状态（声明性方法）。例如，2个复制副本、一个卷装载、configmap等。内置的部署控制器确保部署始终处于所需状态。如果用户使用5个副本更新部署，则部署控制器会识别它并确保所需状态为5个副本。

Kube控制器管理器是一个管理所有Kubernetes控制器的组件。Kubernetes的资源/对象（如pod、命名空间、作业、复制集）由各自的控制器管理。此外，Kube调度器也是由Kube控制器管理器管理的控制器。

Kubernetes控制器管理器工作流

以下是重要的内置Kubernetes控制器列表。

1. 部署控制器
2. 副本集控制器
3. DaemonSet控制器
4. 作业控制器（Kubernetes作业）
5. CronJob控制器
6. 端点控制器
7. 命名空间控制器
8. 服务帐户控制器。
9. 节点控制器

以下是您应该了解的关于Kube控制器管理器的信息。

1. 它管理所有控制器，并且控制器试图将集群保持在所需状态。
2. 您可以使用与自定义资源定义相关联的自定义控制器来扩展kubernetes。
    

5.云控制器管理器（CCM）

当kubernetes部署在云环境中时，云控制器管理器充当云平台API和kubernetes集群之间的桥梁。

通过这种方式，核心kubernetes核心组件可以独立工作，并允许云提供商使用插件与Kubernete集成。（例如kubernetes集群与AWS云API之间的接口）

云控制器集成允许Kubernetes集群提供云资源，如实例（用于节点）、负载均衡器（用于服务）和存储卷（用于持久卷）。

云控制器管理器架构工作流
云控制器管理器包含一组特定于云平台的控制器，可确保特定于云的组件（节点、负载平衡器、存储等）的所需状态。以下是作为云控制器管理器一部分的三个主要控制器。

1. 节点控制器：该控制器通过与云提供商API对话来更新节点相关信息。例如，节点标记和注释、获取主机名、CPU和内存可用性、节点运行状况等。
2. 路由控制器：负责在云平台上配置网络路由。这样不同节点中的pod就可以相互通信。
3. 服务控制器：它负责为kubernetes服务部署负载均衡器、分配IP地址等。
    

以下是云控制器管理器的一些经典示例。

1. 正在部署负载平衡器类型的Kubernetes服务。在这里，Kubernetes提供了一个特定于云的负载均衡器，并与KubernetesService集成。
2. 为云存储解决方案支持的pod提供存储卷（PV）。
    

总体云控制器管理器管理kubernetes使用的特定于云的资源的生命周期。

Kubernetes工作节点组件

现在让我们来看一下每个工作节点组件。

1.Kubelet

Kubelet是一个在集群中的每个节点上运行的代理组件。t不作为容器运行，而是作为守护进程运行，由systemd管理。

它负责向API服务器注册工作节点，并主要从API服务器使用podSpec（Pod规范–YAML或JSON）。podSpec定义了应该在pod中运行的容器、它们的资源（例如CPU和内存限制）以及其他设置，如环境变量、卷和标签。

然后，它通过创建容器将podSpec带到所需的状态。

简单地说，库贝莱负责以下方面。

1. 为pod创建、修改和删除容器。
2. 负责处理活跃、准备和启动探针。
3. 负责通过读取pod配置来装载卷，并在主机上为卷装载创建相应的目录。
4. 使用cAdvisor和CRI等实现，通过对API服务器的调用收集和报告Node和pod状态。

Kubelet也是一个控制器，它监视pod的变化，并利用节点的容器运行时来提取图像、运行容器等。

除了来自API服务器的podSpec之外，kubelet可以接受来自文件、HTTP端点和HTTP服务器的podSpec。“文件中的podSpec”的一个很好的例子是Kubernetes静态pods。

静态pods由kubelet控制，而不是由API服务器控制。

这意味着您可以通过向Kubelet组件提供pod YAML位置来创建pod。但是，Kubelet创建的静态pods不受API服务器的管理。

下面是一个静态pod的真实例子。

在引导控制平面时，kubelet将api服务器、调度器和控制器管理器作为静态pod从位于/etc/kubernetes/manifests的podSpecs启动

以下是关于库贝莱的一些关键内容。

1. Kubelet使用CRI（容器运行时接口）gRPC接口与容器运行时进行通信。
2. 它还向流日志公开HTTP端点，并为客户端提供exec会话。
3. 使用CSI（容器存储接口）gRPC来配置块卷。
4. 它使用集群中配置的CNI插件来分配pod IP地址，并为pod设置任何必要的网络路由和防火墙规则。

Kubernetes组件kubelet解释
 

2.Kube代理

要理解Kube代理，您需要具备Kubernetes服务和端点对象的基本知识。

Kubernetes中的服务是一种在内部或向外部流量公开一组pod的方式。当你创建服务对象时，它会得到一个分配给它的虚拟IP。它被称为clusterIP。它只能在Kubernetes集群中访问。

Endpoint对象包含Service对象下pod组的所有IP地址和端口。端点控制器负责维护pod IP地址（端点）的列表。服务控制器负责为服务配置端点。

您无法ping ClusterIP，因为它只用于服务发现，而不是可ping的pod IP。

现在让我们来了解Kube Proxy。

Kube代理是一个守护进程，作为守护程序集在每个节点上运行。它是一个为pod实现Kubernetes服务概念的代理组件。（单个DNS用于一组具有负载平衡的pod）。它主要代理UDP、TCP和SCTP，不理解HTTP。

当您使用服务（ClusterIP）公开pod时，Kube代理会创建网络规则，将流量发送到分组在Service对象下的后端pod（端点）。也就是说，所有的负载平衡和服务发现都由Kube代理处理。

那么Kube代理是如何工作的呢？

Kube代理与API服务器进行对话，以获取有关服务（ClusterIP）和相应pod IP和端口（端点）的详细信息。它还监视服务和端点中的更改。

然后，Kube代理使用以下任何一种模式来创建/更新将流量路由到服务后面的pod的规则

1. IPTables：这是默认模式。在IPTables模式中，流量由IPtable规则处理。这意味着为每个服务创建IPtable规则。这些规则捕获到达ClusterIP的流量，然后将其转发到后端pod。此外，在这种模式下，kube代理随机选择后端pod进行负载平衡。一旦建立了连接，请求就会转到同一个pod，直到连接终止。
2. IPVS：对于服务超过1000的集群，IPVS可以提高性能。它支持以下后端负载平衡算法。
   1. rr:round-robin：这是默认模式。
   2. lc：最小连接数（最小打开连接数）
   3. dh：目的散列
   4. sh:源哈希
   5. sed：最短预期延迟
   6. nq：从不排队
3. 用户空间（旧版和不推荐）
4. 内核空间：此模式仅适用于Windows系统。

kube代理是如何工作的-工作流
如果您想了解kube代理IPtables和IPVS模式之间的性能差异，请阅读本文。

此外，您可以在没有kube代理的情况下运行Kubernetes集群，方法是将其替换为Cilium。

1.29阿尔法功能：Kubeproxy有一个新的𝗻𝗳𝘁𝗮𝗯𝗹𝗲𝘀 基于后端。nftables是IPtables的继任者，其设计更简单、更高效

3.容器运行时

您可能知道Java Runtime（JRE）。它是在主机上运行Java程序所需的软件。同样，容器运行时也是运行容器所需的软件组件。

容器运行时在Kubernetes集群中的所有节点上运行。它负责从容器注册表中提取映像，运行容器，为容器分配和隔离资源，以及管理主机上容器的整个生命周期。

为了更好地理解这一点，让我们来看看两个关键概念：

• 容器运行时接口（CRI）：它是一组API，允许Kubernetes与不同的容器运行时交互。它允许不同的容器运行时与Kubernetes互换使用。CRI定义了API，用于创建、启动、停止和删除容器，以及管理映像和容器网络。
• 开放容器倡议（OCI）：它是一套容器格式和运行时的标准

Kubernetes支持多个符合容器运行时接口（CRI）的容器运行时（CRI-O、Docker Engine、containerd等）。这意味着，所有这些容器运行时都实现了CRI接口，并公开了gRPC CRI API（运行时和映像服务端点）。

那么Kubernetes是如何利用容器运行时的呢？

正如我们在Kubelet部分所了解到的，Kubelet代理负责使用CRIAPI与容器运行时交互，以管理容器的生命周期。它还从容器运行时获取所有容器信息，并将其提供给控制平面。

让我们举一个CRI-O容器运行时接口的例子。以下是容器运行时如何使用kubernetes的高级概述。

Kubernetes容器运行时CRI-O概述
 

1. 当API服务器发出一个新的pod请求时，kubelet会与CRI-O守护进程对话，通过Kubernetes容器运行时接口启动所需的容器。
2. CRI-O使用容器/映像库从配置的容器注册表中检查并提取所需的容器映像。
3. CRI-O然后为容器生成OCI运行时规范（JSON）。
4. CRI-O然后启动OCI兼容运行时（runc），以根据运行时规范启动容器进程。
    

Kubernetes集群加载项组件

除了核心组件之外，kubernetes集群还需要插件组件才能完全运行。选择一个插件取决于项目需求和用例。

以下是集群中可能需要的一些流行插件组件。

• CNI插件（容器网络接口）
• CoreDNS（用于DNS服务器）：CoreDNS充当Kubernetes集群中的DNS服务器。通过启用此插件，您可以启用基于DNS的服务发现。
• 度量服务器（用于资源度量）：此插件可帮助您收集集群中节点和pod的性能数据和资源使用情况。
• Web UI（Kubernetes Dashboard）：此插件使Kubernete Dashboard能够通过Web UI管理对象。
   

1.CNI插件

首先，您需要了解容器网络接口（CNI）

它是一个基于插件的体系结构，具有与供应商无关的规范和库，用于为容器创建网络接口。

它并不是专门针对Kubernetes的。有了CNI，容器网络可以在Kubernetes、Mesos、CloudFoundry、Podman、Docker等容器编排工具之间实现标准化。

当涉及到容器网络时，公司可能有不同的要求，如网络隔离、安全、加密等。随着容器技术的进步，许多网络提供商为具有广泛网络功能的容器创建了基于CNI的解决方案。你可以称之为CNI插件

这允许用户从不同的供应商那里选择最适合他们需求的网络解决方案。

CNI插件如何与Kubernetes配合使用？

1. Kube控制器管理器负责为每个节点分配pod CIDR。每个pod都从pod CIDR获得一个唯一的IP地址。
2. Kubelet与容器运行时交互以启动计划的pod。CRI插件是Container运行时的一部分，它与CNI插件交互以配置pod网络
3. CNI插件允许使用覆盖网络在分布在相同或不同节点的吊舱之间进行联网。

Kubernetes CNI插件工作流
以下是CNI插件提供的高级功能。

1. Pod网络
2. Pod网络安全和隔离使用网络策略来控制Pod之间和命名空间之间的流量。

一些流行的CNI插件包括：

1. Calico
2. Flannel
3. Weave Net
4. Cilium (Uses eBPF)
5. Amazon VPC CNI (For AWS VPC)
6. Azure CNI (For Azure Virtual network)Kubernetes networking is a big topic and it differs based on the hosting platforms.
    

Kubernetes本机对象

到目前为止，我们已经了解了kubernetes的核心组件以及每个组件的工作原理。

所有这些组件都致力于管理以下关键的Kubernetes对象。

1. Pod
2. Namespaces
3. Replicaset
4. Deployment
5. Daemonset
6. Statefulset
7. Jobs & Cronjobs
8. ConfigMaps and Secrets

当谈到网络时，以下Kubernetes对象起着关键作用。

1. Services
2. Ingress
3. Network policies.

此外，Kubernetes可以使用CRD和自定义控制器进行扩展。因此，集群组件还管理使用自定义控制器和自定义资源定义创建的对象。

Kubernetes架构常见问题

Kubernetes控制平面的主要用途是什么？

控制平面负责维护集群及其上运行的应用程序的所需状态。它由API服务器等组件、调度程序和控制器管理器组成。

Kubernetes集群中工作节点的用途是什么？

工作节点是在群集中运行容器的服务器（裸机或虚拟服务器）。它们由控制平面管理，并从控制平面接收关于如何运行作为pod一部分的容器的指令。

如何在Kubernetes中确保控制平面和工作节点之间的通信安全？

控制平面和工作节点之间的通信使用PKI证书进行保护，不同组件之间的通信通过TLS进行。这样，只有受信任的组件才能相互通信。

Kubernetes中etcd键值存储的目的是什么？

Etcd主要存储集群的kubernetes对象、集群信息、节点信息和配置数据，例如集群上运行的应用程序的期望状态。

如果etcd坏了，Kubernetes应用程序会发生什么？

如果etcd出现故障，运行中的应用程序不会受到影响，但如果没有正常运行的etcd，则无法创建或更新任何对象

结论

了解Kubernetes体系结构有助于您进行日常的Kubernete实现和操作。

在实现生产级集群设置时，掌握Kubernetes组件的正确知识将帮助您运行和排除应用程序故障。