您的位置: 首页  >  文章  >  Kubernetes实战(第二版)----第1章 Kubernetes简介(续2)

Kubernetes实战(第二版)----第1章 Kubernetes简介(续2)

分类: 文章 • 2024-09-10 21:02:22

关注公众号:登峰大数据，阅读Kubernetes实战(第二版)(完整中文版)，系统学习Kubernetes！

Kubernetes实战(第二版)----第1章 Kubernetes简介(续2)

1.2.4  Kubernetes如何运行应用程序

通过对组成Kubernetes的组件的一般概述，我终于可以解释如何在Kubernetes中部署应用程序。

定义您的应用程序

Kubernetes中的一切都由一个对象表示。可以通过Kubernetes API创建和检索这些对象。应用程序由这些对象的几种类型组成--一种类型表示整个应用程序部署，另一种表示应用程序的运行实例，另一种表示一组这些实例提供的服务，并允许通过单个IP地址访问它们，还有许多其他类型。

所有这些类型在本书的第二部分都有详细的解释。目前，知道通过几种类型的对象定义应用程序就足够了。这些对象通常以YAML或JSON格式在一个或多个清单文件中定义。

定义：YAML最初被认为是“另一种标记语言”的意思，但后来它被改为递归缩略词“YAML Ain’t Markup Language”。这是将对象序列化为人类可读文本文件的方法之一。

定义：JSON是JavaScript对象表示法的缩写。这是序列化对象的另一种方式，但更适合在应用程序之间交换数据。

下图显示了通过创建一个清单(使用两个服务公开两个应用部署)来部署应用程序的示例。

Kubernetes实战(第二版)----第1章 Kubernetes简介(续2)

图1.14 将应用程序部署到Kubernetes

当部署应用程序时，会发生以下操作:

  • 将应用程序清单提交给Kubernetes API。API Server将清单中定义的对象写入etcd。

  • 控制器controller会注意到新创建的对象并创建几个新对象——每个应用程序实例一个。

  • 调度器Scheduler为每个实例分配一个节点。

  • Kubelet注意到一个实例被分配给Kubelet的节点。它通过容器运行时环境运行应用程序实例。

  • Kube Proxy注意到应用程序实例已经准备好接受来自客户端的连接，并为它们配置一个负载均衡器。

  • Kubelets和Controllers监视系统并保持应用程序运行。

这个过程在下面的章节中会有更详细的解释，但是完整的解释会在第14章中给出，在你熟悉了所有涉及到的对象和控制器之后。

向API提交应用程序

在创建YAML或JSON文件之后，通常通过Kubernetes命令行工具kubectl将文件提交给API。

注：Kubectl的发音是kube-control，但社区中较温和的人更喜欢称之为kube-cuddle。有些人称之为kube-C-T-L。

Kubectl将文件分割为单个对象，并通过向API发送HTTP PUT或POST请求来创建每个对象，这通常是使用RESTful API的情况。API Server验证对象并将其存储在etcd数据存储中。此外，它通知所有感兴趣的组件这些对象已经创建。下面将介绍控制器，它就是这些组件之一。

关于控制器controllers

大多数对象类型都有一个关联的控制器。控制器对特定的对象类型感兴趣。它等待API Server通知它:一个新对象已经创建，然后执行操作使该对象生效。通常，控制器只是通过相同的Kubernetes API创建其他对象。例如，负责应用程序部署的控制器创建一个或多个表示应用程序的单个实例的对象。控制器创建的对象数量取决于应用程序部署对象中指定的副本数量。

关于调度器Scheduler

调度器是一种特殊类型的控制器，它的唯一任务是将应用程序实例调度到工作节点上。它为每个新的应用程序实例对象选择最佳工作节点，并将其分配给实例--通过API修改对象的方式。

关于Kubelet和容器运行时环境

在每个工作节点上运行的Kubelet也是一种控制器。它的任务是等待应用程序实例被分配到它所在的节点，并运行应用程序。这是通过命令容器运行时环境启动应用程序的容器来实现的。

关于Kube代理

因为应用程序部署可能包含多个应用程序实例，所以负载均衡器需要在单个IP地址公开它们。Kube代理是与Kubelet一起运行的另一个控制器，它负责设置负载均衡器。

保持应用程序的健康运行

应用程序启动并运行后，Kubelet通过在应用程序终止时，重新启动应用程序的方式来保持其健康。它还通过更新表示应用程序实例的对象来报告应用程序的状态。其他控制器监视这些对象，并确保在其节点出现故障时将应用程序移动到正常的节点。

现在，您大致熟悉了Kubernetes的体系结构和功能。此时，您不需要理解或记住所有的细节，因为当您在本书的第二部分中了解到每个单独的对象类型和将它们引入生命周期的控制器时，再消化这些信息会更容易。

1.3 在您的组织/公司中引入Kubernetes

在结束本章之前，让我们看看如果您决定在自己的IT环境中引入Kubernetes，您可以使用哪些选项。

1.3.1在本地和云中运行Kubernetes

如果希望在Kubernetes上运行应用程序，那么必须决定是在本地、在组织自己的基础设施(本地)中运行它们，还是在一个主要的云提供商中运行它们，或者两者都运行——在一个混合云解决方案中

本地运行Kubernetes

如果项目规则要求您在现场运行应用程序，那么在自己的基础设施上运行Kubernetes可能是唯一选择。这通常意味着您将不得不自己管理Kubernetes，但我们将在稍后讨论这个问题。

Kubernetes可以直接在裸机上运行，也可以在数据中心运行的虚拟机中运行。在这两种情况下，您都不能像在云提供商提供的虚拟机中运行集群那样轻松地扩展集群。

在云中部署Kubernetes

如果没有本地基础设施，那么别无选择，只能在云中运行Kubernetes。这样做的好处是，如果需要，可以在短时间内扩展集群。如前所述，当集群的当前大小不再足以运行您想部署的所有应用程序时，Kubernetes本身可以要求云提供商提供额外的虚拟机。

当工作负载减少，一些工作节点没有运行工作负载时，Kubernetes可以要求云提供商销毁这些节点的虚拟机，以降低运营成本。集群的这种弹性当然是在云中运行Kubernetes的主要好处之一。

使用混合云解决方案

一个更复杂的选择是在本地运行Kubernetes，但也允许它溢出到云中。如果超出了自己数据中心的容量，可以配置Kubernetes以在云中提供额外的节点。通过这种方式，你可以两全其美。大多数时候，您的应用程序在本地运行，无需租用虚拟机，但在每年只有几次出现的短时间峰值负载，您的应用程序可以通过使用云中的额外资源来处理额外的负载。

如果您的用例需要它，您还可以跨多个云提供商运行Kubernetes集群，或者使用上述任何一种选项的组合。这可以通过使用单个控制平面或在每个位置使用一个控制平面来完成。

1.3.2 自己管理或不管理Kubernetes

如果您正在考虑在您的组织中引入Kubernetes，您需要回答的最重要的问题是，您是自己管理Kubernetes，还是使用Kubernetes即服务类型的产品，由其他人为您管理它。

自己管理Kubernetes

如果您已经在本地运行了应用程序，并且拥有足够的硬件来运行可用于生产的Kubernetes集群，那么您的第一反应可能是自己部署和管理它。如果你问Kubernetes社区的任何人这是否是一个好主意，你通常会得到一个非常明确的“不”。

图1.14是部署应用程序时Kubernetes集群中所发生的情况的简化表示。即使这个数字也会吓到你。Kubernetes带来了大量额外的复杂性。任何想要运行Kubernetes集群的人都必须非常熟悉它的内部工作方式。

可生产的Kubernetes集群的管理是一个数十亿美元的产业。在您决定自己管理一个项目之前，您必须咨询已经做过该项目的工程师，以了解大多数团队会遇到的问题。如果你不这样做，你可能会注定失败。另一方面，将Kubernetes用于非生产用例或使用托管Kubernetes集群的问题要少得多。

在云中使用托管的Kubernetes集群

使用Kubernetes比管理它容易十倍。大多数主要的云提供商现在都提供Kubernetes-as-a-Service。它们负责管理Kubernetes及其组件，而您只需像云提供商提供的任何其他API一样使用Kubernetes API。

*管理的Kubernetes产品包括以下内容:

  • 谷歌Kubernetes引擎(GKE)

  • Azure Kubernetes服务(AKS)

  • Amazon Elastic Kubernetes服务(EKS)

  • IBM Cloud Kubernetes服务

  • 红帽OpenShift在线和专用

  • VMware云战

  • 阿里巴巴Kubernetes云容器服务(ACK)

本书的前半部分只关注Kubernetes的使用。您将在一个本地开发集群和一个受管理的GKE集群上运行这些练习，因为我发现它是最容易使用的，并且提供了最好的用户体验。本书的第二部分为您管理Kubernetes提供了坚实的基础，但要真正掌握它，您还需要获得额外的经验。

1.3.3使用普通的或扩展的Kubernetes

最后一个问题是，是使用普通的开源版本的Kubernetes，还是使用扩展的、企业级质量的Kubernetes产品。

使用普通版本的Kubernetes

Kubernetes的开源版本由社区维护，代表了Kubernetes开发的前沿。这也意味着它可能不像其他选项那样稳定。它也可能缺乏良好的安全默认值。部署普通版本需要进行大量的微调，以设置用于生产的所有内容。

使用企业级的Kubernetes发行版

在生产中使用Kubernetes的一个更好的选择是使用企业质量的Kubernetes分发版，如OpenShift或Rancher。除了更好的默认值提供的更高的安全性和性能之外，它们还提供了除了前文Kubernetes API中提供的对象类型之外的其他对象类型。例如，普通的Kubernetes不包含表示集群用户的对象类型，而商业发行版包含。它们还提供了额外的软件工具，用于在Kubernetes上部署和管理知名的第三方应用程序。

当然，扩展和加强Kubernetes需要时间，因此这些商业Kubernetes发行版通常比开源Kubernetes版本落后一到两个版本。这并不像听起来那么糟糕。利通常大于弊。

1.3.4你应该使用Kubernetes吗?

我希望这一章已经让您对Kubernetes感到兴奋，并迫不及待地将它挤进您的it堆栈中。但是为了恰当地结束这一章，我们需要说一两句：何时使用Kubernetes不是一个好主意。

欢迎关注公众号，及时获得最新翻译内容：

Kubernetes实战(第二版)----第1章 Kubernetes简介(续2)

相关推荐