首页 体育 教育 财经 社会 娱乐 军事 国内 科技 互联网 房产 国际 女人 汽车 游戏

(译)An introduction to Kubernetes

2019-12-19

原文:https://www.jeremyjordan.me/kubernetes/

这篇博客文章将对Kubernetes进行介绍,以便您了解该东西背面的动机,意义以及运用办法。在后续文章中,我将评论怎么运用更详细的示例来运用Kubernetes增强数据科学作业负载。可是,这有助于您首要了解根本原理-这是本文的要点。

先决条件:我将假定您了解Docker等容器技能。假如您没有构建和运转容器映像的经历,主张您先了解之后,在持续阅览本文

这是咱们将在本文中评论的内容。

Kubernetes一般被描绘为容器编列渠道。为了了解切当的意义,它有助于从头审视容器的用处,短少的内容以及Kubernetes怎么添补这一空白。

留意:您还将看到Kubernetes其简称numeronym,K8S。这意味着同一件事,仅仅更简略键入。

为什么咱们喜爱容器?容器供给了一种轻量级的机制来阻隔运用程序的环境。关于给定的运用程序,咱们能够指定要装置的体系装备和库,而不用忧虑与或许在同一台物理核算机上运转的其他运用程序发作抵触。咱们将每个运用程序封装为 容器映像 能够在任何机器上牢靠地履行*,然后为咱们供给了可移植性,以完结从开发到布置的平稳过渡。此外,因为每个运用程序都是独立的,无需忧虑环境抵触,因而将多个作业负载放置在同一台物理核算机上并完结更高的资源运用率愈加简略-终究降低了本钱。

短少的东西?可是,假如您的容器死了怎么办?乃至更糟的是,假如运转您的容器的核算机发作毛病,会发作什么?容器没有供给 容错 处理方案。或许,假如您有多个需求通讯的容器,该怎么在容器之间完结联网?当您旋转单个容器时,此改变怎么?容器 网络 很简略变成一团糟。最终,假定您的出产环境由多台机器组成-您怎么决议运用哪台机器来运转容器?

Kubernetes作为容器编列渠道。咱们能够运用容器编列渠道处理上述许多问题。

乐团的担任人具有音乐扮演的愿景,并与音乐家 交流 ,以 和谐 他们个人的乐器演奏,以完结整体愿景。作为体系的架构师,您的作业仅仅简略地 创造音乐 ,然后将操控权移交给乐团总监以完结该愿景。

容器编列渠道办理单个容器的整个生命周期,依据需求扩展和封闭资源。假如某个容器意外封闭,编列渠道将经过在其方位发动另一个容器来作出反响。

最重要的是,编列渠道为运用程序之间的通讯供给了一种机制,即便底层的单个容器被创立和毁掉也是如此。

最终,在给定一组要运转的容器作业负载和集群上的一组核算机的状况下,容器和谐器将检查每个容器并确认最佳的核算机来调度该作业负载。要了解为什么这很有价值,请观看Kelsey Hightower运用俄罗斯方块示例游戏来阐明自动化布置和容器编列之间的差异。

现在咱们大致了解了容器编列的动机,让咱们花一些时刻来评论Kubernetes背面的动机规划准则。它有助于了解这些原理,以便您能够 按预期 运用该东西。

或许Kubernetes中最重要的规划准则是,咱们仅界说体系的 希望状况 ,并让Kubernetes自动化作业以保证体系的 实践状况 反映这些希望。这使您免于在大多数事物损坏时进行修正的职责;你只需阐明你的体系是什么 应该 看起来像一个抱负的状况。Kubernetes将检测到体系的实践状况何时不契合这些希望,它将代表您进行干涉以处理问题。这使咱们的体系能够 自我修正 并对问题做出反响,而无需人工干涉。

体系的“状况”由一组 目标 界说。每个Kubernetes目标具有一个 标准 在其间供给所希望的状况和 的状况 反映了目标的当时状况。Kubernetes保护一切目标标准的列表,并不断轮询每个目标,以保证其状况与标准持平。假如目标无呼应,Kubernetes将发动一个新版原本替换它。假如目标的状况偏离了标准,Kubernetes将宣告必要的指令以将该目标驱动回到其所需状况。

关于必定的操作规划,有必要将您的运用程序规划为分布式体系。Kubernetes旨在为此类分布式体系供给根底设施层,发作洁净的笼统以在一组机器之上构建运用程序。更详细地说,Kubernetes供给了一个用于与该集群交互的 一致 界面,因而您不用忧虑与每台机器进行独自通讯。

容器开发一般主张 单一重视 。成果,开发容器化运用程序十分合适微服务架构规划形式,该形式主张“将软件运用程序规划为可独立布置的服务套件”。

Kubernetes中供给的笼统天然支撑别离服务的思维,该服务能够独立缩放和更新。这些服务在逻辑上是分隔的,并经过界说杰出的API进行通讯。这种逻辑上的别离使团队能够更快地将更改布置到出产中,因为每个服务都能够在独立的发布周期内运转。

为了从容器和容器编列中取得最大收益,您应该布置不可变的根底结构。这是不是应该登录到核算机上的容器以进行更改,而是应该构建新的容器映像,布置新版别并停止旧版别。在项目的生命周期中跨环境过渡时,您应该 运用相同的容器映像, 而且只能修正容器映像外部的装备。

这一点十分重要,因为容器被规划为时刻短的,随时能够被另一个容器实例替换。假如您的原始容器处于骤变状况,可是因为运转状况检查失利而被封闭,则在其方位旋转的新容器不会反映这些手动更改,并或许损坏您的运用程序。

当您保护不可变的根底结构时,将运用程序回滚到曾经的状况也变得愈加简略-您能够简略地更新装备以运用较旧的容器映像。

之前,我提到过,咱们经过Kubernetes 目标 的调集描绘了体系的 希望状况 。到目前为止,咱们对Kubernetes的评论还相对笼统和高层次。在本节中,咱们将经过掩盖Kubernetes中可用的根本目标,深化探讨有关怎么在Kubernetes上布置运用程序的更多细节。

能够运用 YAML 或 JSON 文件界说Kubernetes目标。这些界说目标的文件一般称为 清单 。将这些清单保留在版别操控的存储库中是一个好习惯,该存储库可作为有关集群上正在运转哪些目标的仅有现实来历。

pod目标是Kubernetes的根本构建块,由一个或多个的容器,一个同享的网络层,和同享文件体系的卷。与容器相似,Pods被规划为时刻短的-不会希望 特定的单个POD 会长时刻存在。

一般,您不会在清单中显式创立Pod目标,因为运用更高档的组件来为您办理Pod目标一般更简略。

一个布置目标包含由模板和副本数量界说的pods的调集。您能够为副本数设置特定的值,也能够运用独自的Kubernetes资源依据体系目标来操控副本数。

留意: Deployment 目标的操控器实践上在内部创立了另一个目标 ReplicaSet 。可是,这是作为用户从您那里笼统出来的。

虽然您不能依托任何一个 Pod 来无限期地运转,可是您能够依托集群将一直测验使n个Pod可用的现实。 假如咱们有一个布置的副本数为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 app= ml-model 。

以下YAML文件供给了一个示例,阐明晰咱们怎么环绕前期的Deployment示例包装Service。

虽然“服务”使咱们能够在安稳的终结点后边揭露运用程序,但该终结点仅可用于内部群集通讯。假如咱们想将运用程序露出给集群外部的流量,则需求界说一个Ingress目标。

这种办法的优点在于,您能够挑选揭露哪些服务。例如,假定除了咱们的机器学习模型服务外,咱们还有一个UI,该UI运用了模型的猜测作为大型运用程序的一部分。咱们或许挑选仅使UI可用于公共流量,然后阻挠用户直接查询服务模型服务。

以下 YAML 文件为上述示例界说了一个 Ingress 目标,使UI能够揭露拜访。

到目前为止,我现已描绘过的Kubernetes目标能够组成牢靠的,长时刻运转的服务。相反,当您要履行离散使命时, Job 目标很有用。例如,假定咱们想依据前一天搜集的信息每天从头练习模型。每天,咱们都希望发动一个容器来履行预界说的作业负载,然后在练习结束时封闭它。乔布斯为咱们供给了做到这一点的才能!假如因为某种原因咱们的容器在完结脚本之前溃散了,Kubernetes将经过在其方位发动一个新 Pod 来完结作业来做出反响。关于 Job 目标,目标的“所需状况”是作业的完结。

以下 YAML 界说了一个用于练习机器学习模型的示例Job。

留意:此作业标准将仅履行一次练习。假如咱们想每天履行此作业,则能够界说一个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服务器没有分配给核算机的目标。然后,调度程序将确认这些目标应分配给哪些机器,并将回复API服务器以反映此分配。

咱们将在本文中评论的主节点上的最终一个组件是 controller-manager ,它经过API服务器监督集群的状况,以检查集群的当时状况是否契合咱们的希望状况。假如实践状况与咱们的希望状况不同,则操控器办理器将经过API服务器进行更改,以测验将集群驱动到希望状况。操控器办理器由一组 操控器 controllers 界说,每个担任办理集群上特定资源类型的目标。在十分高的级别上,操控器将监督存储在etcd中的特定资源类型,并为应运转的Pod创立标准以完结目标的所需状况。然后,操控者有职责保证这些吊舱在运转时坚持健康,并在需求时封闭。

总结到目前为止咱们所包括的内容...

接下来,让咱们评论在作业程序节点上运转的操控平面组件。咱们的作业程序节点上可用的大多数资源都花在了运转咱们的实践运用程序上,可是咱们的节点的确需求知道他们应该运转哪些Pod,以及怎么与其他核算机上的Pod通讯。咱们将评论的操控平面的两个最终组成部分刚好包括了这两个方面。

该 kubelet 作为一个节点的“代理人”,其与 API 服务器进行通讯,以检查哪些容器作业量被分配到节点。然后,它担任旋转 Pod 以运转这些分配的作业负载。当节点初次参加集群时, kubelet 担任向 API 服务器宣告节点的存在,以便调度程序能够为其分配容器。

最终, kube-proxy 使容器能够跨集群上的各个节点彼此通讯。该组件处理一切网络问题,例如怎么将流量转发到恰当的Pod。

希望到这一点,您应该能够开端了解Kubernetes集群中事物的运转办法。一切组件都经过API服务器进行交互,咱们将群集的状况存储在etcd中。有多种组件写入etcd,以对集群进行更改,而且集群上的节点侦听etcd,以检查其应运转的Pod。

整个体系的规划使毛病对整个群集的影响最小。例如,假如咱们的主节点发作毛病,那么咱们的运用程序都不会当即受到影响;在新的主节点上线之前,咱们将无法对集群进行任何进一步的更改。

与每项新技能相同,你会花费一些时刻,您了解它是怎么作业的,以及它怎么运用于您正在构建的运用程序时。问“我真的需求Kubernetes吗?”是一个合理的问题。因而,我将测验供给一些答案或许为否的示例状况。

您能够在单台核算机上运转作业负载。

您的核算需求不多。

您不需求高可用性,而且能够忍受停机时刻。

您不会想到对已布置的服务进行很多更改。

您现已具有一个满足的有用东西栈。

您具有一个单体架构,不计划将其分红微服务。

您阅览了这篇文章,并以为“这很杂乱”而不是“这很有用”。

参阅:

热门文章

随机推荐

推荐文章