Kubernetes:云原生管理的掌舵者


底层基础架构的每一次重大模式转变,都会让软件也随之发生重大模式转变,试着细想一下:大型机引起了任务批处理和过程式软件编程。客户端-服务器导致了面向对象的编程和早期分布式对象的尝试(如CORBA)。现在,云计算正在转变软件的架构、设计、分发和使用方式。导致这种情况的关键所在,是因为软件开发、软件交付和软件运行时都需要用到底层基础架构。

当下的时代,每个业务都是离不开业务软件,软件已经成为业务的关键,或者至少和其他核心基础服务一样关键。只有更快地为客户提供价值的企业才能成功。而且,软件开发和运营能力已经成为企业间业务的一个基础差别。采用云原生技术的企业正利用云计算的最佳实践来加速时间转变为价值的过程。

在本文中,我将描述IT领导者们是如何在企业中利用Kubernetes的潜力的。具体包括:
  • 定义云原生的意义是什么;
  • 帮助你理解Kubernetes适合于什么地方;
  • 讨论IT运营团队所需要环境的特征;
  • 剖析云原生的支撑技术;
  • 描述在企业中成功构建云原生项目所需要的架构。


1.png

云原生定义

简单地说,云原生系统就是利用云基础设施平台的各种特性的应用系统,这些特性包括按需使用、可伸缩和弹性等。但这并没有告诉我们如何去构建一个云原生系统。好在云原生计算基金会(CNCF)制定了一个更加详细的定义

“云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中,构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。

这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段,云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。”

接下来,让我们分析一下CNCF的云原生定义,以便了解它的关键属性以及用于构建云原生系统的技术。

云原生特征

  • 可伸缩:云基础服务是按需使用的,为云构建的应用程序,被设计为可利用云基础服务的这种“随需应变”的特性。云原生系统必须能够根据负载、性能或其他指标进行伸缩;
  • 弹性:正如Werner Vogels的名言所说,“失败是既定的,随着时间的推移,一切最终都会失败。”云原生系统的设计初衷就是能够容忍失败,通过将大的应用程序分解为较小的组件,来限制失败所带来的影响;
  • 可管理:软件系统的“可管理”意味着什么?可管理意味着软件系统易于管理,系统可配置、可轻松编辑、更新、且服务不中断,这样的系统可被认为是易于管理。而上述所提及属性中,部分高度相似的行为还被定义为著名的最佳实践,例如“12个因素应用程序”或“微服务架构”;
  • 可观察:在控制系统和交互设计模式中,可观察是指一个触发事件的对象,允许外部实体(观察者)轻松推断其内部状态和运行环境。类似地,云原生系统被设计为具有可观察能力,并能够提供关于系统状态变更和其本身运行环境的详细事件。


云原生技术

通过上文介绍,我们已了解云原生系统必须具备的属性,接下来,我们来看看构建云原生系统的一些关键技术和工具:
  • 声明性API:声明性API能够捕获用户的意图。例如:通过API调用,用户可以获得期望的系统状态,而不用关心系统如何达到这个期望状态。换句话说,云原生系统的接口必须提供抽象,允许用户指定他们想要什么,而不是系统应该如何运行。与之相左的命令式接口,则允许用户指定系统运行的指令。
  • 容器:容器已经快速地成为打包、分发和操作软件组件的最佳方式。云原生应用程序使用容器和Kubernetes(后文描述)作为基础构建模块,以及作为构建和管理应用程序组件的基本单元。
  • 微服务:微服务架构将系统解偶为独立的服务,且每个服务都具备可伸缩、弹性、可组合、最小化和完整的特性。微服务与云原生系统共享许多属性,因此,微服务架构成为了云计算和DevOps时代出现的首个主流软件架构范例。
  • 服务网格:微服务架构将应用智能聚焦到单个服务之上。消除了SOA系统架构中的独立中间件和集中式智能服务代理。但是带来的问题是,服务间通信的一些常见功能,如管理、可观察性和安全性,需要由一个单独的服务来处理。服务网格就是用于解决这个问题,而且,它还需提供分布式架构来管理服务间的通信。
  • 不可变基础设施:不可变基础设施的基本概念是“替换,而不是修复”。云计算支持这种模式。我们可以通过Randy Bias的《Pets vs
    Cattle
    》的描述,很好的了解这个概念。而云原生系统的重要之处就是将应用程序与基础设施进行解耦,将基础设施视为不可变的是实现这一点的绝佳方法。


Kubernetes适合什么地方?

既然我们已经提到了Kubernetes,那Kubernetes适合什么地方?它支持哪些云原生系统?

Kubernetes不仅支持上述所有的技术,而且还充当云原生系统的“控制平面”。为了理解这意味着什么,我们需要首先讨论一个关键的架构模式及其在可伸缩系统设计中的应用。

分层架构和三个平面

构建可伸缩系统的一个关键是将系统分解为多个部分,以便每个部分都打包相关联的行为和数据,并提供可让其他部分或外部系统重用的抽象。这个简单但功能强大的概念,通常称为分层体系结构。使用这种结构,系统的每一层都可以利用它下面的层,来实现定义良好的角色,并为它上面的层提供新的抽象。

在电信和网络领域,一些最大、最复杂和最可靠的系统均采用了分层系统结构。在这些系统中,分层系统结构通常定义三个层次或“平面”,每个平面都封装了不同的协议和行为,从而形成一个可伸缩和弹性的系统:
2.png

  1. 数据平面:数据平面(层)提供承载终端用户数据或流量的功能和协议。在电话系统中,这可以是一个呼叫信令包;在网络中,它是网络包和数据流;
  2. 控制平面:控制平面(层)提供功能和协议,协调处理数据平面中的进程。例如,在电话系统中,这可以是信号和呼叫处理,在网络中是路由和转发功能;
  3. 管理平面:管理平面(层)提供管理功能来配置和执行控制平面和数据平面中的所有功能和设备。在电话系统中,是系统操作所需的管理功能集合,简称FCAPS(故障、配置、计费、性能和安全性)。


了解了这三个平面后,我们将它应用到云原生系统中。下表总结了云原生系统中,每个系统平面及所对应功能:
3.png

云原生系统中的数据平面是容器运行时,它利用底层基础设施中的计算、网络和存储。控制平面是一个像Kubernetes软件的容器编排和管理系统,以及其他的应用程序控制功能,如服务网格等。管理平面和其他领域的做法类似,将所有管理类功能集成在一起,包括故障管理(警报)、配置管理(预制)、计费(账单和计量)、性能管理(指标和监视)和安全管理等功能。

虽然可以通过CLIs和本地接口单独管理交换机和路由器,但以这种方式管理任何大规模部署都是不现实的,也不划算。与任何新技术一样,早期采用者倾向于采用他们自己的管理软件。然而,随着技术的成熟,能够提供全面管理功能的集成工具和系统也会成熟起来。在下一节中,我们将研究云原生管理的关键属性和功能。

云原生管理

云原生管理是云原生系统的管理层。它提供了集成的解决方案,实现轻松管理整个云原生堆栈。让我们讨论一下云原生管理的关键属性和功能。

云原生管理的关键属性

  • 云原生:很显然,云原生管理解决方案需要使用云原生原则构建。这意味着云原生管理是可伸缩的、弹性的、可管理的和可观察的。并且使用如声明性API、容器和微服务架构等最佳技术所构建;
  • 可组合:2013年,Jonathan Murray引入了可组合企业的概念。Murray建议,对于成功的数字化转型企业,IT系统应该使用不影响整体,易于替换的部件构建。与之相似的,云原生管理也必须是可组合的。它应该在需要的地方提供内置功能,但允许根据需要去替换和定制所有的主要功能;
  • 与基础设施无关:为了实现弹性、效率和规模化,应用程序必须与基础设施解耦。云原生管理需要与基础设施和云平台不相关。单个管理平面应该能够管理跨公共云、私有云和数据中心以及边缘计算部署的集群。


云原生管理的关键功能

既然我们已经定义了什么是云原生管理,让我们来描述一下它必须做什么:
  • Kubernetes集群操作:云原生管理解决方案必须能够安装和操作Kubernetes集群,并为云提供商或其他来源的外部集群提供常规管理功能;
  • Kubernetes工作负载操作:云原生管理解决方案必须允许用户建模、部署和管理Kubernetes工作负载。工作负载可以是跨应用程序使用的集群服务,也可以是最终用户的Kubernetes应用程序;
  • 多层监控:云原生管理系统必须从云堆栈的每一层收集、关联和聚合指标。包括容器主机、集群和应用负载等。采用联和指标数据收集管道,可支持提供当前数据,向下采样和历史数据的长期存储;
  • 集成警报和通知:云原生管理解决方案必须支持可配置的告警,这些告警可以根据系统中的任何度量、状态或条件创建。一个重要的需求是能够将告警与应用程序、环境和最终用户SLA关联起来,以便分配适当的严重性;
  • 日志管理:云原生管理系统必须支持日志收集和聚合功能,并能够将日志数据发送到日志集中存储库。必须从源头丰富日志数据,且允许分段访问;
  • 审计跟踪:云原生管理系统必须记录对管理、控制和数据平面所做的任何变更,并标识执行更改的主体或角色。一个重要的特性是能够跟踪跨系统组件触发的一系列更改,包括系统操作,这样,任何变更都可以关联回用户操作;
  • 联合变更管理:云原生管理系统必须允许跨集群管理变更。这包括应用程序容器镜像的变更,以及资源清单配置的变更。云原生管理系统应该对变更管理采用推模型或拉模型保持立场,但是提供可构建的模块,让不同的团队决定最适合他们的模式;
  • 联合身份和访问管理:云原生管理必须支持跨集群的联合访问控制和授权。这意味着所有集群访问都必须关联到一套单独的标识管理系统,以便单个更新就可以终止角色或用户的访问;
  • 基于策略的管理:云原生管理必须提供策略来验证和转换配置。这些策略应该是基于所授权粒度的,可执行的。应该使用应用程序和运行时环境之类熟悉的实体。
  • 安全和控制层集成:云原生管理系统必须很好地与数据和控制层的安全和控制解决方案集成。对于容器化应用程序,集成包括图像扫描和来源系统、合规管理系统、密钥管理系统以及防火墙和网络策略实施系统等。除了安全性之外,云原生管理系统还必须具备通过服务网格管理服务间的通信的能力;
  • 操作洞察和最佳实践:云原生管理系统必须检查操作的最佳实践并提供可操作的建议。理想情况下,这些最佳实践是可配置和可扩展的,这样操作人员就可以根据需要定制它们。


您可以在Nirmata网站下载一个全面的评估人员指南和清单

结论

软件吞噬了整个世界!因此构建、部署和操作软件的能力对于所有企业的成功都至关重要。随着应用程序不断迁移到云端,新的云原生应用程序都将采用标准构建打包和容器化运行时。Kubernetes和服务网格等技术的出现,为应用打包和部署在容器中的微服务架构应用提供控制和管理功能。

电信和网络领域的核心系统所采用的分层体系结构,让系统由数据层、控制层和管理层组成。通过将这些规则应用于云原生系统,我们可以将容器运行时映射到数据层,将Kubernetes和服务网格映射到系统的控制层。但是,管理层是实施云原生系统所必需的一个关键组件。因此,我们在本文中,定义了云原生管理的关键属性和功能,以及云原生系统的管理层。云原生管理必须使用云原生原则构建,这些原则可组合且不依赖于基础设施。云原生管理还必须提供跨配置、故障、测量、警报和安全性的集成和多层管理功能。

值得庆幸的是,云原生管理的解决方案正在CNCF生态系统中迅速成熟。随着企业拥抱云原生管理,云原生系统和容器、Kubernetes等技术的全部潜力将会被主流所采用。对于应用软件构建来讲,那将是一个令人兴奋的时刻!

原文链接:Kubernetes: Steering the Ship with Cloud Native Management(翻译:易理林)

0 个评论

要回复文章请先登录注册