云原生环境中的编排和管理层
Posted K8S技术社区
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了云原生环境中的编排和管理层相关的知识,希望对你有一定的参考价值。
编排和管理层是CNCF云原生环境中的第三层。在使用这类工具之前,工程师们可能已经按照安全性和合规性标准(配置层)自动化了基础设施配置,并为应用程序设置了运行时(运行时层)。现在,他们必须弄清楚如何将所有应用程序组件作为一个组进行编排和管理。组件必须相互识别以进行通信和编排,以实现共同的目标。天生具有可伸缩性的云原生应用依赖于这些工具所支持的自动化和弹性。
编排和调度
它是什么
编排和调度指的是运行和管理容器,这是跨集群打包和发布应用程序的一种新方法。集群是一组通过网络连接的物理或虚拟计算机。
容器编排器(和调度器)有点类似于笔记本电脑上的操作系统(OS),它管理你的所有应用程序。操作系统执行你想要使用的应用程序,并安排哪些应用程序可以使用你笔记本电脑的CPU和其他硬件资源。
虽然在一台机器上运行所有的东西很好,但现在大多数应用程序都比一台计算机所能处理的大得多。这些大型应用程序分布在多台机器上,形成了一个分布式应用程序。大多数现代应用程序是分布式的,这需要能够管理跨这些不同机器运行的所有组件的软件。简而言之,你需要一个“集群操作系统”,这就是编排工具的用武之地。
容器在许多不同环境下运行应用程序的能力是关键。容器编排器也是如此。容器和Kubernetes都是云原生架构的核心。
解决的问题
在云原生架构中,应用程序被分解为小组件或服务,每个组件或服务都放在一个容器中。现在,你不再拥有一个大型应用程序,而是拥有多个小型服务,每个服务都需要资源、监控和在出现问题时进行修复。虽然为单个服务手动执行这些操作是可行的,但当有数百个容器时,需要自动化流程。
如何起作用
容器编排器自动化容器管理。这在实践中意味着什么呢?
Kubernetes做了一种称为所需状态协调的工作:它将集群中容器的当前状态与所需状态相匹配。所需状态由工程师在一个文件中指定,并不断与实际状态进行比较。如果所需状态和实际状态不匹配,Kubernetes通过创建或销毁对象来协调它们。
简而言之,Kubernetes允许你将集群视为一台计算机。它只关注环境应该是什么样子,并处理实现细节。
基本技术
Kubernetes与Docker Swarm和Mesos等其他容器编排器一起属于编排和调度部分。它的基本目的是允许你将多台不同的计算机作为一个资源池来管理。除此之外,它允许你以一种声明性的方式来管理它们,也就是说,不用告诉Kubernetes如何做某件事,而是提供一个你想要做什么的定义。这允许你在一个或多个YAML文件中维护所需的状态,并将其或多或少地应用于任何Kubernetes集群。然后,编排器本身创建丢失的内容或删除不应存在的内容。
Buzzwords |
Popular Projects |
|
|
协作和服务发现
它是什么
正如我们所看到的,现代应用程序是由多个单独的服务组成的,这些服务需要协作来为最终用户提供价值。为了协作,它们通过网络进行通信。为了交流,它们必须首先找到彼此。服务发现是找出如何做到这一点的过程。
解决的问题
云原生架构是动态的和流动的,这意味着它们是不断变化的。当一个容器在一个节点上崩溃时,会在另一个节点上启动一个新容器来替换它。或者,当一个应用程序扩展时,副本会分散在整个网络中。没有一个地方有一个特定的服务,所有东西的位置都在不断变化。此类工具跟踪网络中的服务,以便在需要时服务可以相互查找。
如何起作用
请注意,“服务”在不同的上下文中可能有不同的含义,这可能会令人困惑。术语“服务”通常指放置在容器/pod内的服务。它是实际应用程序中具有特定功能的应用程序组件或微服务。
另一方面,Kubernetes服务是帮助pod找到并相互连接的抽象。它是一个服务(功能)的入口点,作为一个流程或pod的集合。在Kubernetes中,当你创建一个服务(抽象)时,你将创建一组pod,这些pod一起提供一个服务(功能),其中一个端点(条目)就是Kubernetes服务。
基本技术
随着分布式系统越来越普遍,传统的DNS进程和传统的负载均衡器往往无法跟上不断变化的端点信息。为了弥补这些缺点,人们创建了服务发现工具来处理单个应用程序实例快速注册和注销自己。一些选择(如etcd和CoreDNS)是Kubernetes原生的,一些则有定制的库或工具来允许服务有效地运行。CoreDNS和etcd是CNCF项目,构建在Kubernetes中。
Buzzwords |
Popular Projects |
|
|
远程过程调用
它是什么
远程过程调用(RPC)是一种特殊的技术,使应用程序能够相互通信。它代表了应用程序构建彼此通信的几种方法之一。
解决的问题
现代的应用程序是由许多单独的服务组成的,这些服务必须进行通信才能进行协作。RPC是处理应用程序之间通信的一种选择。
如何起作用
RPC提供了一种紧耦合和高度自定的方式来处理服务之间的通信。它支持带宽高效的通信,并且许多语言支持RPC接口实现。
基本技术
RPC为服务之间的通信提供了一个高度结构化和紧耦合的接口。RPC有很多潜在的好处:它使编码连接更容易,它允许极有效地使用网络层和服务之间结构良好的通信。不过,RPC因创建脆弱的连接点和强迫用户对多个服务进行协作升级而受到批评。gRPC是一种特别流行的RPC实现,已被CNCF采用。
Buzzwords |
Popular Projects |
|
|
服务代理
它是什么
服务代理是一种工具,它拦截进入/流出给定服务的流量,对其应用一些逻辑,然后将该流量转发给另一个服务。它本质上是一个“中间人”,收集有关网络流量的信息和/或对其应用规则。这可以简单到充当一个将流量转发到单个应用程序的负载均衡器,也可以复杂到一个互连的代理网格(与处理所有网络连接的单个容器化应用程序并排运行)。
服务代理本身很有用,特别是当将流量从更广泛的网络驱动到Kubernetes集群时。服务代理也是其他系统的构建块,例如API网关或服务网格。
解决的问题
应用程序应该以受控的方式发送和接收网络流量。为了跟踪流量并可能对其进行转换或重定向,我们需要收集数据。传统上,支持数据收集和网络流量管理的代码嵌入到每个应用程序中。
服务代理允许我们“外部化”这个功能。它不再需要存在于应用程序中。相反,它现在嵌入到平台层(应用程序运行的地方)。这很强大,因为它允许开发人员完全专注于编写应用程序逻辑、生成价值的代码,而处理流量的通用任务则由平台团队管理。通过集中分布和管理全局所需的服务功能(例如路由或TLS终端),服务之间的通信更加可靠、安全和高效。
如何起作用
代理充当用户和服务之间或不同服务之间的“看门人”。有了这种独特的定位,它们可以深入了解正在发生的通信类型。基于洞察,它们决定将特定请求发送到哪里,甚至完全拒绝它。
代理收集关键数据、管理路由(在服务之间均匀分布流量或在某些服务出现故障时重新路由)、加密连接和缓存内容(减少资源消耗)。
基本技术
服务代理的工作原理是截获服务之间的流量,对它们执行一些逻辑,然后潜在地允许流量继续移动。通过将一组集中控制的功能放入这个代理中,管理员可以完成几件事。它们可以收集有关服务间通信的详细指标,防止服务过载,并将其他通用标准应用于服务。服务代理是其他工具(如服务网格)的基础,因为它们提供了对所有网络流量强制执行更高级别策略的方法。
Buzzwords |
Popular Projects |
|
|
API网关
它是什么
计算机通过API(应用程序编程接口)进行交互,而API不应该与API网关混淆。
API网关允许组织将关键功能(如授权或限制应用程序之间的请求数)移动到可以集中管理的位置。它还可以作为API使用者(通常是外部)的公共接口。
通过API网关,组织可以集中控制(限制或启用)应用程序之间的交互并跟踪它们,从而实现诸如按存储容量使用计费、身份验证和防止服务被过度使用(即速率限制)。
解决的问题
虽然大多数容器和核心应用程序都有API,但API网关不仅仅是API。API网关简化了组织管理和将规则应用于所有交互的方式。
API网关允许开发人员编写和维护更少的自定义代码(系统功能被编码到API网关中)。它们还使团队能够看到并控制应用程序用户和应用程序本身之间的交互。
如何起作用
API网关位于用户和应用程序之间。它充当一个中间人,接收来自用户的消息(请求)并将它们转发给适当的服务。但是在发出请求之前,它会评估用户是否被允许做他们想做的事情,并记录关于谁发出了请求以及他们发出了多少请求的详细信息。
简单地说,API网关为应用程序用户提供了一个带有公共用户界面的单点入口。它还允许你将应用程序中其他实现的任务移交给网关,从而节省开发人员的时间和金钱。
基本技术
API网关从应用程序中取出自定义代码,并将其引入一个中央系统。API网关的工作原理是拦截对后端服务的调用,执行某种增值活动,如验证授权、收集指标或转换请求,然后执行它认为合适的任何操作。API网关充当一组下游应用程序的公共入口点,同时为团队提供了一个地方,在那里团队可以注入业务逻辑来处理授权、速率限制和按存储容量使用计费。它们允许应用程序开发人员从客户那里抽象出对其下游API的更改,并将诸如向网关引入新客户之类的任务卸载。
Buzzwords |
Popular Projects/Products |
|
|
服务网格
它是什么
服务网格最近很受关注。据TNS撰稿人janakirammsv称,“在Kubernetes之后,服务网格技术已经成为云原生堆栈中最关键的组件。”
服务网格管理服务之间的流量(即通信)。它们使平台团队能够在集群内运行的所有服务中统一地添加可靠性、可观测性和安全性,而不需要任何代码更改。
解决的问题
在云原生世界中,我们需要处理多个需要通信的服务。这意味着在一个本来就不可靠且通常速度较慢的网络上来回传输的流量要多得多。为了解决这一系列新的挑战,工程师必须实现额外的功能。在服务网格之前,必须将该功能编码到每个应用程序中。这种自定义代码常常成为技术债务的来源,并为失败或漏洞提供了新的途径。
如何起作用
服务网格为平台层上的所有服务统一添加了可靠性、可观测性和安全性,而不需要接触应用程序代码。它们与任何编程语言兼容,允许开发团队专注于编写业务逻辑。
基本技术
服务网格通过服务代理将集群上运行的所有服务绑定在一起,从而创建服务网格。它们通过服务网格控制平面进行管理和控制。服务网格允许平台所有者在应用程序上执行常见操作或收集数据,而无需开发人员编写自定义逻辑。
本质上,服务网格是一个基础结构层,它通过向服务代理的网络(或网格)提供命令和控制信号来管理服务间通信。它的强大之处在于它能够提供关键的系统功能,而不必修改应用程序。
有些服务网格使用通用服务代理作为其数据平面。另一些则使用专用代理;例如,Linkerd使用Linkerd2代理“微代理”,在性能和资源消耗方面获得优势。这些代理通过所谓的sidecar统一附加到每个服务上。其实在它自己的容器里运行的是同一个容器。
服务网格提供了许多有用的功能,包括显示详细的指标、加密所有流量、限制哪些操作被哪个服务授权、为其他工具提供附加插件等。
Buzzwords |
Popular Projects |
|
|
结论
如我们所见,这一层中的工具处理如何将所有这些独立的容器化服务作为一个组进行管理。编排和调度工具是一种集群操作系统,在集群中管理容器化的应用程序。协作和服务发现、服务代理和服务网格确保服务能够找到彼此并进行有效通信,以便作为一个具有凝聚力的应用程序进行协作。API网关是一个附加层,提供了对服务通信的更多控制,特别是在外部应用程序之间。
原文链接:
The Cloud Native Landscape: The Orchestration and Management Layer – The New Stack
以上是关于云原生环境中的编排和管理层的主要内容,如果未能解决你的问题,请参考以下文章