山东省建设工程信息网站,wordpress图片轮播插件,搅拌机东莞网站建设技术支持,横山桥网站原文#xff1a;https://www.jeremyjordan.me/kubernetes/#xff08;博客园团队推荐的#xff09;这篇博客文章将对Kubernetes进行介绍#xff0c;以便您了解该工具背后的动机#xff0c;含义以及使用方式。在后续文章中#xff0c;我将讨论如何使用更具体的#xff08… 原文https://www.jeremyjordan.me/kubernetes/博客园团队推荐的这篇博客文章将对Kubernetes进行介绍以便您了解该工具背后的动机含义以及使用方式。在后续文章中我将讨论如何使用更具体的数据科学示例来利用Kubernetes增强数据科学工作负载。但是这有助于您首先了解基本原理-这是本文的重点。先决条件我将假设您熟悉Docker等容器技术。如果您没有构建和运行容器映像的经验建议您先熟悉之后在继续阅读本文总览这是我们将在本文中讨论的内容。Kubernetes有什么意义Kubernetes通常被描述为容器编排平台。为了理解确切的含义它有助于重新审视容器的用途缺少的内容以及Kubernetes如何填补这一空白。注意您还将看到Kubernetes其简称numeronymK8S。这意味着同一件事只是更容易键入。为什么我们喜欢容器容器提供了一种轻量级的机制来隔离应用程序的环境。对于给定的应用程序我们可以指定要安装的系统配置和库而不必担心与可能在同一台物理计算机上运行的其他应用程序产生冲突。我们将每个应用程序封装为容器映像container image可以在任何机器上可靠地执行*只要它能够运行容器映像从而为我们提供了可移植性以实现从开发到部署的平稳过渡。此外由于每个应用程序都是独立的无需担心环境冲突因此将多个工作负载放置在同一台物理计算机上并实现更高的资源内存和CPU利用率更加容易-最终降低了成本。缺少的东西但是如果您的容器死了怎么办甚至更糟的是如果运行您的容器的计算机发生故障会发生什么容器没有提供容错fault tolerance解决方案。或者如果您有多个需要通信的容器该如何在容器之间实现联网当您旋转单个容器时此变化如何容器网络networking 很容易变成一团糟。最后假设您的生产环境由多台机器组成-您如何决定使用哪台机器来运行容器Kubernetes作为容器编排平台。我们可以使用容器编排平台解决上述许多问题。乐团的负责人拥有音乐表演的愿景并与音乐家沟通以协调他们个人的乐器演奏以实现总体愿景。作为系统的架构师您的工作只是简单地创作音乐指定要运行的容器然后将控制权移交给乐团总监容器编排平台以实现该愿景。容器编排平台管理单个容器的整个生命周期根据需要扩展和关闭资源。如果某个容器意外关闭编排平台将通过在其位置启动另一个容器来作出反应。最重要的是编排平台为应用程序之间的通信提供了一种机制即使底层的单个容器被创建和销毁也是如此。最后在给定1一组要运行的容器工作负载和2集群上的一组计算机的情况下容器协调器将检查每个容器并确定最佳的计算机来调度该工作负载。要了解为什么这很有价值请观看Kelsey Hightower1747-2055使用俄罗斯方块示例游戏来说明自动化部署和容器编排之间的区别。设计原则。现在我们大致了解了容器编排的动机让我们花一些时间来讨论Kubernetes背后的动机设计原则。它有助于理解这些原理以便您可以按预期使用该工具。陈述式也许Kubernetes中最重要的设计原则是我们仅定义系统的期望状态并让Kubernetes自动化工作以确保系统的实际状态反映这些期望。这使您免于在大多数事物损坏时进行修复的责任你只需说明你的系统是什么应该看起来像一个理想的状态。Kubernetes将检测到系统的实际状态何时不符合这些期望它将代表您进行干预以解决问题。这使我们的系统能够自我修复并对问题做出反应而无需人工干预。系统的“状态”由一组对象定义。每个Kubernetes对象具有1一个规范在其中提供所期望的状态和2的状态反映了对象的当前状态。Kubernetes维护所有对象规范的列表并不断轮询每个对象以确保其状态与规范相等。如果对象无响应Kubernetes将启动一个新版本来替换它。如果对象的状态偏离了规范Kubernetes将发出必要的命令以将该对象驱动回到其所需状态。分布式对于一定的操作规模有必要将您的应用程序设计为分布式系统。Kubernetes旨在为此类分布式系统提供基础设施层产生干净的抽象以在一组机器统称为集群之上构建应用程序。更具体地说Kubernetes提供了一个用于与该集群交互的统一界面因此您不必担心与每台机器进行单独通信。解耦容器开发通常建议单一关注。结果开发容器化应用程序非常适合微服务架构设计模式该模式建议“将软件应用程序设计为可独立部署的服务套件”。Kubernetes中提供的抽象自然支持分离服务的思想该服务可以独立缩放和更新。这些服务在逻辑上是分开的并通过定义良好的API进行通信。这种逻辑上的分离使团队可以更快地将更改部署到生产中因为每个服务都可以在独立的发布周期内运行前提是他们遵守现有的API合约。不变的基础设施为了从容器和容器编排中获得最大收益您应该部署不可变的基础结构。这是不是应该登录到计算机上的容器以进行更改例如更新库而是应该构建新的容器映像部署新版本并终止旧版本。在项目的生命周期开发-测试-生产中跨环境过渡时您应该使用相同的容器映像并且只能修改容器映像外部的配置例如通过安装配置文件。这一点非常重要因为容器被设计为短暂的随时可以被另一个容器实例替换。如果您的原始容器处于突变状态例如手动配置但是由于运行状况检查失败而被关闭则在其位置旋转的新容器不会反映这些手动更改并可能破坏您的应用程序。当您维护不可变的基础结构时将应用程序回滚到以前的状态例如如果发生错误也变得更加容易-您可以简单地更新配置以使用较旧的容器映像。Kubernetes中的基本对象。之前我提到过我们通过Kubernetes 对象的集合描述了系统的期望状态。到目前为止我们对Kubernetes的讨论还相对抽象和高层次。在本节中我们将通过覆盖Kubernetes中可用的基本对象深入探讨有关如何在Kubernetes上部署应用程序的更多细节。可以使用YAML或JSON文件定义Kubernetes对象。这些定义对象的文件通常称为清单manifests。将这些清单保留在版本控制的存储库中是一个好习惯该存储库可作为有关集群上正在运行哪些对象的唯一事实来源。Podpod对象是Kubernetes的基本构建块由一个或多个紧密相关的的容器一个共享的网络层和共享文件系统的卷。与容器类似Pods被设计为短暂的-不会期望特定的单个POD会长期存在。通常您不会在清单中显式创建Pod对象因为使用更高级的组件来为您管理Pod对象通常更简单。部署方式一个部署对象包括由模板和副本数量模板的多少副本我们要运行定义的pods的集合。您可以为副本数设置特定的值也可以使用单独的Kubernetes资源例如水平Pod自动缩放器根据系统指标例如CPU利用率来控制副本数。注意Deployment对象的控制器实际上在内部创建了另一个对象ReplicaSet。但是这是作为用户从您那里抽象出来的。虽然您不能依赖任何一个Pod来无限期地运行但是您可以依靠集群将始终尝试使n个Pod可用的事实其中n由您指定的副本数定义。 如果我们有一个部署的副本数为10的Deployment并且其中3个Pod因机器故障而崩溃那么将安排另外3个Pod在群集中的另一台计算机上运行。因此Deployment最适合无状态应用程序在这些应用程序中Pod可以随时更换而不会损坏。以下YAML文件提供了有关如何定义Deployment对象的带注释的示例。在此示例中我们要运行一个容器的10个实例该实例通过REST接口提供ML模型。注意为了让Kubernetes知道此工作负载可能有多计算密集型我们还应该在Pod模板规范中提供资源限制。部署还允许我们指定当我们有新版本的容器映像时我们希望如何推出更新这篇博客文章很好地概述了您的不同选择。如果我们想覆盖默认值我们将strategy在object下包含一个附加字段spec。Kubernetes将确保正常关闭运行旧容器映像的Pod并启动运行新容器映像的新Pod。服务Kubernetes中的每个Pod都分配有一个唯一的IP地址我们可以用来与之通信。但是由于Pod是短暂的因此很难将流量发送到所需的容器。例如让我们考虑上面的“部署”其中有10个Pod运行一个容器通过REST为机器学习模型提供服务。如果作为部署的一部分运行的Pod集合可以随时更改我们如何与服务器可靠地通信这是服务对象输入图片的地方。Kubernetes服务为您提供了一个稳定的端点即使由于更新扩展和故障导致确切的基础Pod发生变化它也可以用于将流量引导到所需的Pod。服务根据标签知道应将流量发送到哪个Pod 键值对我们在Pod元数据中定义。注意这篇博客文章很好地解释了如何实际路由流量。在此示例中我们的服务使用标签将流量发送到所有健康的Pod appml-model。以下YAML文件提供了一个示例说明了我们如何围绕早期的Deployment示例包装Service。Ingress尽管“服务”使我们可以在稳定的终结点后面公开应用程序但该终结点仅可用于内部群集通信。如果我们想将应用程序暴露给集群外部的流量则需要定义一个Ingress对象。这种方法的好处在于您可以选择公开哪些服务。例如假设除了我们的机器学习模型服务外我们还有一个UI该UI利用了模型的预测作为大型应用程序的一部分。我们可能选择仅使UI可用于公共流量从而阻止用户直接查询服务模型服务。以下YAML文件为上述示例定义了一个Ingress对象使UI可以公开访问。Job到目前为止我已经描述过的Kubernetes对象可以组成可靠的长期运行的服务。相反当您要执行离散任务时Job对象很有用。例如假设我们想根据前一天收集的信息每天重新训练模型。每天我们都希望启动一个容器来执行预定义的工作负载例如train.py脚本然后在培训结束时关闭它。乔布斯为我们提供了做到这一点的能力如果由于某种原因我们的容器在完成脚本之前崩溃了Kubernetes将通过在其位置启动一个新Pod来完成工作来做出反应。对于Job对象对象的“所需状态”是作业的完成。以下YAML定义了一个用于训练机器学习模型的示例Job假设在中定义了训练代码train.py。注意此作业规范将仅执行一次训练。如果我们想每天执行此作业则可以定义一个CronJob对象。...还有很多。上面讨论的对象当然不是Kubernetes中可用资源类型的详尽列表。在部署应用程序时您可能会发现有用的其他一些对象包括Volume用于管理安装在Pod上的目录Secret用于存储敏感凭证NameSpace用于分隔群集上的资源ConfigMap用于指定要作为文件挂载的应用程序配置值HorizontalPodAutoscaler用于基于现有Pod的当前资源利用率扩展部署StatefulSet与Deployment类似但适用于需要运行有状态应用程序的情况怎么样Kubernetes control plane(控制平面)。至此您可能想知道Kubernetes如何能够采用我们所有的对象规范并在集群上实际执行这些工作负载。在本节中我们将讨论组成Kubernetes 控制平面的组件这些组件控制如何在集群上执行监视和维护工作负载。在深入研究之前重要的是区分集群上的两类计算机一个master node主节点包含了大部分这使得我们的控制平面我们将在下面讨论的组件。在大多数中等大小的集群中您只有一个主节点尽管可以有多个主节点来实现高可用性。如果您使用云提供商的托管Kubernetes服务则它们通常会抽象化主节点而您不必进行管理或为此付费。一个worker node工作节点是实际运行我们的应用程序工作负载的机器。可以针对集群上的不同类型的工作负载量身定制多种不同的计算机类型。例如您可能具有一些GPU优化的节点以进行更快的模型训练然后使用CPU优化的节点进行服务。定义对象规格时可以指定有关将工作负载分配给哪种机器的首选项。现在让我们深入了解主节点上的主要组件。与Kubernetes通信以提供新的或更新的对象规范时您正在与API服务器进行通信。更具体地说API服务器验证更新对象的请求并充当有关集群当前状态的问题的统一接口。但是集群的状态存储在etcd分布式键值存储中。我们将使用etcd来保存有关以下信息集群配置对象规范对象状态集群上的节点以及分配对象在哪些节点上运行。注意etcd是我们控制平面中唯一的有状态组件所有其他组件都是无状态的。说到应该在哪里运行对象调度程序scheduler 负责确定这一点调度程序将询问API服务器然后将与etcd通信尚未分配给计算机的对象。然后调度程序将确定这些对象应分配给哪些机器并将回复API服务器以反映此分配该分配将传播到etcd。我们将在本文中讨论的主节点上的最后一个组件是controller-manager它通过API服务器监视集群的状态以查看集群的当前状态是否符合我们的期望状态。如果实际状态与我们的期望状态不同则控制器管理器将通过API服务器进行更改以尝试将集群驱动到期望状态。控制器管理器由一组控制器controllers定义每个负责管理集群上特定资源类型的对象。在非常高的级别上控制器将监视存储在etcd中的特定资源类型例如部署并为应运行的Pod创建规范以实现对象的所需状态。然后控制者有责任确保这些吊舱在运行时保持健康并在需要时关闭。总结到目前为止我们所涵盖的内容...接下来让我们讨论在工作程序节点上运行的控制平面组件。我们的工作程序节点上可用的大多数资源都花在了运行我们的实际应用程序上但是我们的节点确实需要知道他们应该运行哪些Pod以及如何与其他计算机上的Pod通信。我们将讨论的控制平面的两个最后组成部分恰好涵盖了这两个方面。该kubelet作为一个节点的“代理人”其与API服务器进行通信以查看哪些容器工作量被分配到节点。然后它负责旋转Pod以运行这些分配的工作负载。当节点首次加入集群时kubelet负责向API服务器宣布节点的存在以便调度程序可以为其分配容器。最后kube-proxy使容器能够跨集群上的各个节点相互通信。该组件处理所有网络问题例如如何将流量转发到适当的Pod。希望到这一点您应该能够开始了解Kubernetes集群中事物的运行方式。所有组件都通过API服务器进行交互我们将群集的状态存储在etcd中。有多种组件通过API服务器写入etcd以对集群进行更改并且集群上的节点通过API服务器侦听etcd以查看其应运行的Pod。整个系统的设计使故障对整个群集的影响最小。例如如果我们的主节点发生故障那么我们的应用程序都不会立即受到影响在新的主节点上线之前我们将无法对集群进行任何进一步的更改。什么时候不应该使用Kubernetes与每项新技术一样你会花费一些时间您了解它是如何工作的以及它如何应用于您正在构建的应用程序时。问“我真的需要Kubernetes吗”是一个合理的问题。因此我将尝试提供一些答案可能为否的示例情况。您可以在单台计算机上运行工作负载。Kubernetes可以看作是构建分布式系统的平台但是如果不需要则不应构建分布式系统您的计算需求不多。在本例中用于编排框架的计算相对较高您不需要高可用性并且可以容忍停机时间。您不会想到对已部署的服务进行大量更改。您已经拥有一个满意的有效工具栈。您拥有一个单体架构不打算将其分成微服务。这可以回到原本打算使用的工具的状态。您阅读了这篇文章并认为“这很复杂”而不是“这很有用”。参考朱莉娅·埃文斯Julia Evans-Kubernetes很酷的原因https://jvns.ca/blog/2017/10/05/reasons-kubernetes-is-cool/朱莉娅·埃文斯Julia Evans-我对Kubernetes的一些了解Julia的杂志对我的视觉解释Kubernetes控制平面有很大的启发https://jvns.ca/blog/2017/06/04/learning-about-kubernetes/
