Kubernetes 架构图

每日分享最新，最流行的软件开发知识与最新行业趋势，希望大家能够一键三连，多多支持，跪求关注，点赞，留言。

你知道 Kubernetes 架构图是什么吗？Kubectl、微服务、无服务器计算、Kubernetes、AWS、容器、Fluentd、pod、节点或扩展怎么样？

如今，您可能在生活中的某个阶段听说过很多计算术语，但您可能还无法完全了解 IT。

即使您熟悉所有这些术语，您是否了解它们的上下文？

如果您了解我到目前为止提到的所有内容，那么您可能会考虑进一步阅读，因为您将要了解更多。但是，如果你不熟悉上面提到的术语，请坐下来听我说的话。

当我将 Kubernetes 主题分解为原子并逐步构建它时，您将遇到坎坷，因此您将了解 Kubernetes 架构图，每个 Kubernetes 架构示例，整个结构，什么它的用途，以及如何使用它。

因此，让我们点击进入 IT！

什么是 Kubernetes？

Kubernetes 集群架构由一个主（控制）平面和一个或多个节点（工作机器）组成。或者，如果您使用 kubeadmn、kops 等 Kubernetes 自我管理的服务，它可能会更多。

这两个实例都可以在云中，以虚拟机的形式，甚至是物理设备。但是，当涉及到 Azure AKS、GCP GKE 和 AWS EKS 等托管 Kubernetes 架构环境时，控制平面的管理由指定的云提供商完成。

现在，当大型企业希望执行关键任务时，他们会使用 Kubernetes，因为它是一个用于容器管理的开源系统，是满足他们需求的完美解决方案。为什么 Kubernetes 如此出色？这是它可以做的：

除了其基本的框架功能外，Kubernetes 在其他方面也很有帮助。它允许用户从各种选项中进行选择，例如语言、日志记录和监控工具、应用程序框架的类型，以及用户可能需要的许多其他有价值的工具。

Kubernetes 本身不是平台即服务 (PaaS)，但您可以将其用作完整的 PaaS 起始基础。

自从 Kubernetes 出现在市场上以来，它已经成为一种非常流行的工具，也是当今最成功的开源平台之一。

为什么我们需要 Kubernetes？

Kubernetes 的唯一目的是以自动化方式和容器形式托管您的应用程序。这允许您根据需要部署尽可能多的应用程序实例，但这还不是全部。您还可以在应用程序中找到的所有服务之间启用可访问的通信。

听起来不可思议；你可能会想，“Kubernetes 有什么不能做的吗？” 你这样想也没错。

我们需要 Kubernetes 仅仅是因为它允许我们在所有可用资源上有效地分配我们的工作负载，但它也允许我们优化基础设施成本。此外，Kubernetes 具有可扩展性、高可用性、可移植性和安全性等几个王牌。

可扩展性

Kubernetes 中部署的所有应用程序都称为微服务，它们由许多容器组成，这些容器进一步分组为 Pod。从这里开始，每个容器在逻辑上都被设计为执行一个单一的任务。

高可用性

几乎所有容器编排引擎都可以提供应用程序可用性。然而，Kubernetes 的高可用架构的存在是为了实现基础设施和应用程序的可用性。它还通过利用复制控制器、宠物集和副本集来确保应用程序前端的高可用性。

Kubernetes 在应用程序前端使用复制控制器、副本集和宠物集来确保高可用性。此外，用户可以随时设置最小运行 Pod 数。

此外，Kubernetes（高可用性）支持基础设施可用性，包括广泛的存储后端。其中包括块存储设备，如 Amazon Elastic Block Store (EBS)、Google Compute Engine 永久磁盘等。

此外，它还支持 NFS、GlusterFSand 等分布式文件系统和 Flocker 等专用容器存储插件。

可移植性

Kubernetes 的设计在操作系统、容器运行时、云平台、PaaS 和处理器架构方面提供了多种选择。此外，您可以在不同的 Linux 发行版上配置 Kubernetes 集群，例如 CentOs、Debian、Fedora、CoreOS、Ubuntu 和 Red Hat Linux。

您可以将其部署为在基于 KVM、libvirt 和 vSphere 的本地或虚拟环境中运行。

Kubernetes 的无服务器架构能够在 Google Cloud、Azure 和 AWS 等云平台上运行。尽管如此，如果您跨云提供商或本地混合和匹配集群，您也可以创建混合云。

安全

谈到 Kubernetes 安全性，应用程序架构在多个级别上进行了安全配置。

Kubernetes 优势

Kubernetes 的主要优势是巨大的，这就是 Kubernetes 必须提供的：

自动装箱

Kubernetes 将自动打包您的应用程序并根据所有可用资源和要求创建容器调度，而不会牺牲可用性。因此，Kubernetes 将在尽力而为和关键工作负载之间取得平衡，以节省未使用的资源并确保完全利用。

负载平衡和服务发现

由于 Kubernetes 会自动为容器分配 IP 地址，因此可以让您在网络和通信方面放心。此外，对于一组容器，它提供了一个单一的 DNS 名称，用于对集群内的流量进行负载平衡。

存储编排

Kubernetes 允许您选择要挂载的系统存储。您可以选择 AWS、GCP 甚至本地存储等公共云提供商。此外，您可以使用 iSCSI、NFS 等共享网络存储系统。

自我修复

Kubernetes 能够自动重启所有在执行期间失败的容器。此外，它将杀死所有不响应用户先前定义的健康检查的容器。最后，如果节点死亡，它将重新调度并替换所有其他可用节点中的所有失败容器。

秘密和配置管理

Kubernetes 可以帮助您更新和部署机密和应用程序配置，而无需重建映像并在堆栈配置中公开机密。

批量执行

除了管理服务之外，Kubernetes 还可以处理您的批处理和 CI 工作负载，如果需要，它们将替换失败的容器

水平缩放

Kubernetes 需要一个命令来扩展容器，但它也可以使用 CLI 缩小容器。您可以通过 Kubernetes UI 中的仪表板执行扩展。

自动回滚和转出

Kubernetes 可以逐步推出对您的应用程序或其配置的更新和更改。如果出现问题，Kubernetes 可以并且将会回滚更改。

这些是 Kubernetes 架构图的一些最关键的优势，但这并不是 Kubernetes 提供的全部。因此，让我们更深入地了解 Kubernetes 更有吸引力的方面及其实际用例。

Kubernetes 和在企业和公司中的采用

您会惊讶地发现超过 25,000 家公司使用 Kubernetes 集群架构。大多数使用 Kubernetes 的公司都来自美国，从事 CS（计算机软件）行业。

据 Enlyft 称，过去五年Kubernetes 数据使用情况和有关 Kubernetes 使用统计的数据更加透明。

使用 Kubernetes 的企业拥有 100 万至 1000 万美元的收入和 10-50 名员工。这些公司是小型企业，占使用 Kubernetes 的企业的 38%。

此外，使用 Kubernetes 的公司中有 43% 是拥有 50-1000 名员工的中型公司。最后，使用 Kubernetes 架构的企业中有 19% 是拥有超过 1000 名员工的大公司。

一些在其工作流程中使用 Kubernetes 的著名公司包括 Shopify、Google、Udemy、Slack 等。

为什么这些公司使用 Kubernetes？这就是为什么。

在本地运行 Kubernetes 背后的原因

当企业在其数据中心中实施 Kubernetes 架构图而不是替代方案（公共云提供商）时，这变成了一件大事。很自然，这几个基本因素对于公司决定 Kubernetes 本地战略实施至关重要：

经营方针

每个企业都有特定的业务策略要求，例如需要在准确指定的地理位置运行工作负载。如果您考虑特定的策略需求集，您就会理解为什么企业可能难以利用公共云。

此外，如果提及的业务对其竞争有严格的业务政策，一些公司可能不会接受来自各种公共云提供商的报价。

避免锁定

许多企业希望避免使用来自一个云提供商的服务，因为他们可能希望在多个云中部署他们的应用程序。这包括本地（私有）云。因此，企业将降低由于某些云提供商的问题而造成的永久性影响的风险。

此外，这使公司有机会与云提供商协商更好的价格。

成本

在规模上，在公共云中运行应用程序的成本可能很高，而成本效益可能是在本地使用 Kubernetes 的最重要原因。

此外，如果您的应用程序依赖于处理和摄取大量数据，您可以期望支付高昂的费用在公共云环境中运行它们。

另一方面，由于现有数据中心，利用“内部”Kubernetes 将显着降低运营成本。

数据隐私和合规

一些组织针对数据隐私和合规问题制定了规定。例如，如果公司的服务嵌套在特定的公共云中，这些规则可能会阻止公司为世界各地的客户提供服务。

您将使用自己的数据中心有效地将您的应用程序现代化为云原生格式。如果您选择退出 Kubernetes 本地部署，您将显着改变您的业务。像这样的有效策略将帮助您节省大量资金，同时无疑会改善基础设施的使用。

为什么需要容器来使用 Kubernetes？

想要将其应用程序容器化的公司必须大规模使用容器，因为他们不使用一两个容器，而是使用数十个甚至上百个容器，以确保高可用性和负载平衡流量。

接下来发生的事情是他们必须扩大集装箱数量。当流量每秒都在增加时，需要“扩展”过程来服务“n”个请求。或者，在需求低的情况下，您应该缩减容器数量。

老实说，即使这是可能的，您也只能在涉及管理这些容器的大量手动工作之后才能做到这一点。因此，在我脑海中徘徊的问题是，这一切是否值得麻烦。自动化干预会让您的生活更轻松并节省您数小时的体力劳动吗？毫无疑问会的！

因此，容器管理工具至关重要。有许多著名的容器编排和管理工具可用，但 Kubernetes 是市场的领导者。它受欢迎的原因是它无与伦比的功能以及它是谷歌产品的事实。

因此，选择 Kubernetes 的一个很好的理由是基于流量需求的容器自动扩展。

Kubernetes 架构及其组件

Kubernetes 架构图的组件是节点（一组机器）和控制平面。现在，让我们更深入地了解这些组件。

Kubernetes 中的主节点是什么？

Master Node 是所有管理任务的起点，它的职责是管理 Kubernetes 集群架构。

集群中可能有多个主节点，并且随着更多主节点检查容错性所需的操作将使系统处于称为“高可用性”的模式。

但是，一个主节点具有执行所有任务的主节点的角色。

主节点组件

Kubernetes API 服务器

1. 主节点内的 API 服务器是执行所有管理任务的地方。
2. REST 命令然后转到将处理和验证请求的 API 服务器。
3. 根据请求，集群的结果状态将基于分布式键值进行存储。

调度器

1. 该组件将任务调度到指定的从节点。此外，每个从节点都会存储资源使用信息。
2. Scheduler 会以 Services 和 Pod 的形式调度所有的工作。
3. 在任务调度之前，调度器会考虑服务需求质量、亲和性、反亲和性、数据局部性等。

控制管理器

1. 控制管理器被称为控制器，它是一个调整 Kubernetes 集群的守护进程。Kubernetes 集群用于管理各种非终止控制循环。
2. 这个组件还有其他一些事情，比如节点垃圾收集、事件垃圾收集、级联删除垃圾收集。此外，它还具有创建命名空间等生命周期功能。
3. 本质上，控制器查看托管对象的所需状态，但它也使用 API 服务器来忽略和管理其当前状态。如果未满足对象的期望状态，则控制回路将通过采取特定步骤来确保平衡当前和期望状态以实现该目标。

ETCD

1. 该组件分发一个键值存储，最终使用集群状态进行存储。
2. 您可以在外部配置 ETCD，甚至可以将其作为 Kubernetes Master 的一部分。
3. “Go”编程语言是人们用来编写 ETCD 的一种语言。在 Kubernetes 中，您可以存储 Secrets、ConfigMaps、子网等配置详细信息，并存储集群状态。

高层次的 Kubernetes 架构

当谈到高层时，Kubernetes 架构由几个部分组成，如控制平面（主节点）、几个 Kubelet（集群节点）和 ETCD（有助于保持集群状态一致的分布式存储系统）。

控制平面在这一切中去哪里？

控制平面是一个特定的系统，它永久地管理对象状态，帮助匹配系统对象的实际和期望状态，并响应集群内的任何变化。

控制平面由三个基本组件组成——kKubescheduler、kKubeapiserver 和 kKubecontroller-manager。这些组件将通过单个主节点运行，甚至可以在多个主节点中复制（高可用性）。

Kube 调度器

1. 组件会忽略没有分配节点的新创建的 Pod，并选择它们将运行的节点。
2. 调度决策基于几个因素，包括数据局部性、工作负载间的干扰、软件/硬件/策略限制、资源需求（个人和集体）、亲和性和反亲和性规范以及截止日期。

这是 Apiserver

1. kKubeapiserver 组件作为 API 服务器的主要实现组件。此外，它通过部署额外的实例进行扩展（水平扩展）。可以运行多个实例并平衡它们之间的流量。
2. API 服务器公开了 Kubernetes API，它是 Kubernetes 控制平面的前端组件。

Kube-Controller-Manager

即使每个控制器都是一个独立的进程，您也可以将多个控制器合并为一个二进制文件，但为了降低复杂性，它将作为单个进程运行。

这些是一些控制器类型：

1. 节点控制器——在节点关闭时通知和响应。
2. 作业控制器——监视作业对象（一次性任务）并创建完成任务的 Pod。
3. Endpoints 控制器——填充 Endpoints 对象（合并 Pod 和服务）。
4. 令牌控制器和服务帐户——创建新命名空间所需的默认帐户和 API 访问令牌。

工作节点架构

工作节点通过 Pod 运行应用程序，主节点控制 Pod。Pod 调度在物理服务器（从节点）上。因此，当您想从外部环境访问应用程序时，您必须连接到这些节点。

工作节点组件

1. 容器运行时

1. Worker Node 需要一个容器运行时来管理和运行容器的生命周期。
2. Docker 经常被混淆为容器运行时，但它是一个以这种方式利用容器的平台。

2. 库贝莱特

1. Kubelet 与主节点通信并在工作节点上执行。它通过 API 服务器获取 Pod 规格。此外，它执行健康且积极运行的 Pod 中描述的相关容器。

3. cAdvisor

1. cAdvisor 用于分析在指定节点上运行的每个容器的网络使用情况、文件、CPU 和内存的所有指标。您应该找到一个好的监控工具，因为 cAdvisor 没有提供长期存储解决方案。
2. 您无需采取特定步骤来安装 cAdvisor，因为它集成了 kubelet 二进制文件。

4. 快速 Kubelet 工作流程图

一个更实用的解决方案是向您展示 Kubelet 工作流程的图解图表，以便您更好地了解它是如何工作的。您将在下面看到 Kubelet 工作流程的详细而快速的介绍。

5. 代理

1. Kube-proxy 在每个节点上运行，它与每个主机子网分开工作，以确保外部各方可以访问所有服务。
2. 它还充当位于工作节点上的任何服务的负载平衡器和网络代理的角色。此外，Kubee-proxy 将管理 UDP 和 TCP 数据包的网络路由。
3. 网络代理在每个工作节点上运行，并遵循每个服务端点的 API 服务器（删除/创建）。
4. 为了让 Kube-proxy 到达服务端点，它创建了不同的路由。

Kubernetes 概念、工具、部署和其他重要元素

ETCD

深入了解 Kubernetes 架构图的表面总是很有趣，而 ETCD 是一个伟大的 Kubernetes 架构示例的关键元素。Kubernetes 将所有集群状态信息存储在 ETCD 中，被称为控制平面的唯一有状态元素。

ETCD 高度一致，使其成为锚协调点。此外，得益于 Raft 共识算法，ETCD 具有高可用性。

ETCD 的另一个出色功能是它能够将更改流式传输到客户端。这有助于所有 Kubernetes 集群组件保持同步。

Kubectl

这是 Kubernetes 的命令行工具，它可以帮助您运行命令。此外，Kubectl 有利于管理和检查集群资源、查看日志和应用程序部署。

Kubectl 使用户能够控制访问以执行任何 Kubernetes 操作。从更技术的角度来看，kubectl 是 Kubernetes API 的客户端。

Kubernetes 网络

“IP-per-pod”模型是 Kubernetes 的运作方式。这意味着每个 pod 都被分配了一个 IP 地址。此外，位于单个 pod 中的容器将共享相同的 IP 地址和网络命名空间。

网络 Kubernetes 有一个独特的网络模型，适用于 pod 到 pod 和集群范围的网络。

通常，CNI（容器网络接口）会使用覆盖网络，通过 VXLAN（流量封装）来隐藏 Pod 的底层网络。此外，它可以利用完全路由的其他解决方案。无论它使用哪种解决方案，集群范围的 pod 网络都是 pod 进行通信的地方，而 CNI 提供者管理这种通信。

Pod 内没有任何限制，因此容器之间可以相互通信，因为在 Pod 中，容器共享相同的 IP 地址和网络命名空间。

这是什么意思呢？首先，这意味着容器的通信是通过 localhost 完成的。其次，Pod 之间的通信是可能的，这要归功于 Pod IP 地址。

Kubernetes 中的存储

Kubernetes 基于卷的概念，本质上，卷是一个目录，其中可能包含一些 pod 可以访问的数据。但是，特定卷类型的使用决定了它的内容，选择了备份这个目录的介质，以及这个目录最初是如何形成的。

一个 pod 中的任何容器都能够消耗同一个 pod 中的存储。最初，当 Pod 重新启动时，存储将继续存在，但在删除 Pod 后会发生什么取决于存储类型。

各种可用选项将允许您将块存储和文件存储挂载到 pod，最流行的是云存储服务，如 gcePersistentDisk 和 AWS EBS。或者，iSCSI、Flocker、NFS、CephFS 和 glusterFS 等物理存储也是可以考虑的选项。

此外，管理员可以为您提供 PersistentVolumes (PV) 存储解决方案。PV 是集群范围的对象，它们进一步链接到后备存储提供程序，允许您使用这些资源。所以 PV 所做的就是绑定到已经存在的存储资源。

PersistentVolumeClaim 将为同一命名空间下的每个 pod 创建一个存储消耗请求。但是，根据使用情况，它可以具有不同的状态或阶段。这些状态被称为可用、绑定、释放和失败。

最后，StorageClasses 是一个抽象层，可以让您看到底层存储的质量差异。此外，运营商使用 StorageClasses 来描述不同的存储类型，它根据来自每个 pod 的所有传入声明为存储提供动态配置。

Kubernetes 概念

要使 Kubernetes 架构图实用，您必须了解该架构用来表示 Kubernetes 系统内状态的各种抽象。

1. Pod – 由一个或多个容器控制的单个应用程序。一个 pod 包含一个唯一的网络 ID、应用程序容器和存储资源，以确定它将如何运行容器。
2. 服务——Pod 很容易发生变化。因此，Kubernetes 无法保证物理 pod 将保持活动状态（如果复制控制器结束并以新 pod 开始）。

相反，该服务将显示一组逻辑 pod，但它也将扮演网关的角色。这意味着您不必跟踪组成服务的 pod，因为 pod 将能够向服务发送请求。

1. NameSpace – 是一个虚拟集群，可在多个项目的多个用户的环境中工作。值得一提的是，一个物理集群可以同时运行多个虚拟集群。

命名空间中的资源必须是唯一的，并且它们不会被授予访问另一个命名空间的权限。此外，可以为命名空间分配资源配额，这样您就可以避免过度消耗物理集群中的整体资源。

1. Volume——在 Kubernetes 中，卷将应用于整个 pod。因此，它将安装在位于指定 pod 中的所有容器上。即使容器重启，Kubernetes 也可以保证所有数据都会被保存。但是，如果 pod 被杀死，volume 也会消失。一个 pod 可以有许多不同类型的卷。
2. 部署——这个概念描述了 pod 的期望状态或其副本集，通常在 yaml 文件中。在部署文件中指定的当前和预期状态匹配之前，部署控制器将缓慢更新环境。此环境更新包括删除或创建副本。

yaml 文件的作用是为每个 pod 定义两个副本。但是，当只有其中一个在运行时，yaml 文件定义也会创建另一个。因此，重要的是要知道在部署管理副本时不应直接操作它们。请改用新的部署。

Kubernetes Supervisord

管理和创建流程是主管的主要工作。但是，这些过程的起点是其配置文件中的数据。如果您想知道主管是如何做到这一点的，答案很简单——它会创建子流程。

只要子进程处于活动状态，Supervisord 就会管理它创建的每个子进程。这就是为什么监督者被称为子进程的“后代”的父进程。

Fluentd

Fluentd 是一个流行的开源数据收集器，您可以在 Kubernetes 节点上进行设置。您将快速转换和过滤日志数据，并在设置后跟进容器日志文件。您将能够将它们传送到 Elasticsearch 集群，以便索引和存储数据。

1. JSON 统一日志记录——Fluentd 将尽可能尝试将数据结构化为 JSON。这对于处理日志数据很重要，因为 Fluentd 会统一它们。处理日志数据包括过滤、收集跨多个目的地和源的日志输出以及缓冲。
2. 可插拔架构——社区能够扩展功能，这要归功于 Fluentd 拥有的灵活的插件系统。此外，这些插件将连接多个数据输出和数据源。Fluentd 插件是有益的，因为它们允许更好、更直接的日志使用。
3. 内置可靠性——由于此数据收集器使用基于文件的缓冲并支持内存，它可以防止您在节点间丢失有价值的数据。此外，您可以将其设置为高可用性，但请记住，它在应对艰难的故障转移方面也表现出色。
4. 所需资源最少——这个开源收集器占用的系统资源最少，因为它是用 Ruby 和 C 语言组合编写的。

Kubernetes Deployment

Deployment 为 Kubernetes 提供了修改或创建承载容器化应用程序的 pod 实例的说明。部署可以实现许多目标，例如在受控环境中启用更新代码、扩展副本 pod 数量以及将代码回滚到以前的部署版本以防您需要回滚。

Deployment优势

Kubernetes 部署给我们带来的最有意义的好处是关于各种重复功能（扩展、更新生产应用程序、部署）的自动化系统。

此外，自动 pod 实例启动机制让您放心，因为现在您可以放心，您的实例将按预期运行并跨集群内的所有节点运行。从本质上讲，自动化程度越高越好。即使您的部署速度更快，您也会遇到更少的错误。

由于对节点和 Pod 的持续健康和性能监控，Kubernetes 部署可以绕过出现故障的节点，甚至替换失败的 Pod。通过这样做，部署控制器可以轻松替换 pod，最终目标是确保所有重要应用程序的无缝工作。

结论

Kubernetes 架构图一开始并不是一个容易理解的系统，但是当你这样做时，你的生活和工作时间会变得容易得多。

我们了解到，Kubernetes 被证明是一种出色的扩展解决方案，支持多样化和解耦的有状态和无状态工作负载，并提供自动回滚和部署。尽管如此，它还是一个很棒的平台，允许您编排您的应用程序（基于容器）。

今天我们一起经历了很多信息。我只是希望您对 Kubernetes 以及它是什么以及它是如何工作的有更好的了解。如果有任何问题，您可能想知道我们还没有讨论过，请联系我们，我们团队的专业人员将帮助您解决任何问题。