Kubernetes实战(第二版)----第1章 Kubernetes简介(续1)
关注公众号:登峰大数据,阅读Kubernetes实战(第二版)(完整中文版),系统学习Kubernetes!
1.2.2 使用Kubernetes的好处
您已经了解了为什么世界各地的许多组织都欢迎Kubernetes进入它们的数据中心。现在,让我们仔细看看它给开发团队和IT运维团队带来的具体好处。
应用程序的自服务部署
因为Kubernetes将其所有工作节点表示为工作负载面,所以将应用程序部署到哪个节点不再重要。这意味着开发人员现在可以自己部署应用程序,即使他们不知道节点的数量或每个节点的特征。
在过去,系统管理员是决定每个应用程序应该放在何处的人。这个任务现在交给了Kubernetes。这允许开发人员部署应用程序,而不需要依赖其他人。当开发人员部署应用程序时,Kubernetes会根据应用程序的资源需求和每个节点上可用的资源来选择运行应用程序的最佳节点。
通过更好地利用基础设施降低成本
如果不关心应用程序落在哪个节点上,这还意味着它可以在任何时候移动到任何其他节点,而不必担心它。Kubernetes可能需要这样做,以便为希望部署的更大应用程序腾出空间。这种移动应用程序的能力允许将应用程序紧密地打包在一起,以便以最佳的方式利用节点的资源。
注:在第17章中,您将了解Kubernetes如何决定将每个应用程序放在何处,以及您如何影响决策。
寻找最佳组合可能是一项挑战和费时的工作,特别是当所有可能选项的数量非常大时,例如当有许多应用程序组件和可以部署它们的许多服务器节点时。计算机可以比人类更好更快地完成这项任务。Kubernetes做得很好。Kubernetes通过在同一台机器上组合不同的应用程序,提高了硬件基础设施的利用率,这样就可以在更少的服务器上运行更多的应用程序。
自动调整,以改变负载
使用Kubernetes管理已部署的应用程序还意味着,运维团队不必经常监视每个应用程序的负载,以响应突然的负载高峰。Kubernetes也处理了这个问题。它可以监视每个应用程序消耗的资源和其他指标,并调整每个应用程序运行实例的数量,以应对增加的负载或资源使用。
当在云基础设施上运行Kubernetes时,它甚至可以通过云提供商的API提供额外的节点来增加集群的规模。通过这种方式,您永远不会耗尽空间来运行应用程序的其他实例。
保持应用程序平稳运行
Kubernetes还会尽一切努力确保应用程序平稳运行。如果您的应用程序崩溃,Kubernetes将自动重启它。因此,即使您的应用程序在运行了几个小时之后就耗尽了内存,Kubernetes也会通过自动重启来确保您的应用程序继续为其用户提供服务。
Kubernetes是一个自愈系统,它处理软件错误,就像刚才描述的那样,但它也处理硬件故障。随着集群规模的增长,节点故障的频率也会增加。例如,在一个有100个节点、每个节点的平均故障间隔时间(MTBF)为100天的集群中,每天都有一个节点发生故障。
当一个节点失败时,Kubernetes自动将应用程序移动到剩余的健康节点。运维团队不再需要手动移动应用程序,而是可以专注于修复节点本身并将其返回到可用硬件资源池中。
如果基础设施有足够的空闲资源来允许系统在没有故障节点(去掉问题节点的情况下)的情况下正常运行,运维团队甚至不必立即对故障作出反应。如果它发生在午夜,运营团队中的任何人都不需要醒来。它们可以在正常工作时间处理故障节点。
简化应用程序开发
上一节中描述的改进主要与应用程序部署有关。但是应用程序开发的过程是怎样的呢?Kubernetes会给他们带来什么吗?它肯定如此。
如前所述,Kubernetes提供了与基础设施相关的服务,否则就必须在应用程序中实现这些服务。这包括分布式应用程序中的服务和/或对等点的发现、领袖选举、集中应用程序配置等。Kubernetes提供了这一点,同时保持应用程序与Kubernetes无关,但是在需要时,应用程序还可以查询Kubernetes API以获取关于其环境的详细信息。他们还可以使用API来改变环境。
1.2.3 Kubernetes集群的架构
正如你已经知道的,一个Kubernetes集群由两组节点组成:
-
承载控制平面组件的一组主节点,它们是系统的大脑,因为它们控制着整个集群。
-
组成工作负载平面的一组工作节点,这是运行工作负载(或应用程序)的地方。
下图显示了这两个平面以及它们所包含的不同节点。
图1.11 组成Kubernetes集群的两个平面
这两个平面以及这两种类型的节点运行不同的Kubernetes组件。书中接下来的两个部分介绍了它们,并对它们的功能进行了总结,但不涉及细节。本书的第三部分将深入介绍这些组件及其内部结构。
控制平面组件
控制平面是控制集群的。它由运行在单个主节点上或跨多个主节点复制的几个组件组成,以确保高可用性。控制平面的组件如下图所示。
图1.12 Kubernetes控制平面的组件
以下是组成部分及其功能:
-
Kubernetes API Server公开RESTful Kubernetes API。使用集群和其他Kubernetes组件的工程师通过这个API创建对象。
-
etcd分布式数据存储了通过API创建的对象,因为API Server本身是无状态的。Server是唯一与etcd通信的组件。
-
Scheduler 调度程序决定每个应用程序实例应该在哪个工作节点上运行。
-
Controllers 控制器赋予通过API创建的对象生命。它们中的大多数只是创建其他对象,但有些还与外部系统通信(例如,云提供商通过其API)。
控制平面的组件保持并控制集群的状态,但它们不运行应用程序。这是由(worker)节点完成的。
工作节点组件
工作节点是运行应用程序的计算机。它们构成集群的工作负载平面。除了应用程序之外,几个Kubernetes组件也在这些节点上运行。它们执行在应用程序之间运行、监视和提供连接的任务。如下图所示。
图1.13 运行在每个节点上的Kubernetes组件
每个节点运行以下组件集合:
-
Kubelet,一个与API Server对话并管理在其节点上运行的应用程序的代理。它通过API报告这些应用程序和节点的状态。
-
容器运行时环境(Container Runtime),它可以是Docker或与Kubernetes兼容的任何其他Container Runtime。它按照Kubelet的指示在容器中运行应用程序。
-
Kubernetes Service Proxy(Kube代理)在应用程序之间对网络流量进行负载平衡。它的名字暗示着通过它进行通信,但现在情况已经不一样了。你将在第14章中了解原因。
附加组件
大多数Kubernetes集群还包含几个其他组件。这包括一个DNS服务器,网络插件,日志代理和其他组件。它们通常在工作节点上运行,但也可以配置为在主节点上运行。
对架构有更深入的理解
现在,我只希望您对这些组件的名称和它们的功能有一些模糊的了解,因为我将在接下来的章节中多次提到它们。你将在这些章节中学习到关于它们的片段,但是我将在第14章中详细解释它们。
我不喜欢解释事物是如何工作的,除非我先解释事物是做什么的,并教你如何使用它。这就像学开车一样。你不会想知道内幕的。首先,你只想学习如何从A点到达B点。只有这样,你才会对汽车如何使这一切成为可能感兴趣。了解引擎盖下的东西,也许有一天当你的车坏了,被困在路边时,你能帮助你的车再次开动起来。我讨厌这么说,但是由于Kubernetes的复杂性,您在处理Kubernetes时会遇到很多这样的情况。
1.2.4 Kubernetes如何运行应用程序
通过对组成Kubernetes的组件的一般概述,我终于可以解释如何在Kubernetes中部署应用程序。
定义您的应用程序
(未完待续......) 欢迎关注公众号,及时获得最新翻译内容: