什么是Kubernetes？在过去的几年里，Kubernetes一直是DevOps和数据科学社区中令人兴奋的话题。它不断发展成为开发云原生应用程序的首选平台之一。Kubernetes由Google作为一个开源平台构建，负责将容器调度到计算集群并管理工作负载以确保它们按预期运行。但是，有一个问题：这是什么意思？当然，可以对Kubernetes进行其他研究，但假设大多数读者已经对技术基础知识有所了解，互联网上的许多文章都充斥着行话和复杂的术语高级概述。在这篇文章中，我们试图对Kubernetes架构及其在大数据中的应用提供通俗易懂的解释，同时澄清繁琐的术语。但是，我们假设我们的读者已经对应用程序开发和编程领域有一定的了解。我们希望到本文结束时，您对该主题有更好的理解，并准备好进行更深入的研究。什么是微服务？为了理解Kubernetes是如何工作的以及我们为什么需要它，我们需要研究微服务。微服务没有普遍接受的定义，但简单地说，微服务是执行特定任务的大型应用程序的小型解耦组件。这些组件通过RESTAPI相互通信。这种架构使应用程序具有可扩展性和可维护性。它还使开发团队更有效率，因为每个团队都可以专注于自己的组件，而不会干扰应用程序的其他部分。由于每个组件或多或少地独立于应用程序的其余部分运行，因此有必要拥有一个可以管理和集成所有这些组件的基础架构。该基础架构将需要保证所有组件在生产中部署时都能正常工作。容器与虚拟机(VM)每个微服务都有其依赖性，需要自己的环境或虚拟机(VM)来托管它们。您可以将VM视为计算机中的一个“巨大”进程，其存储、处理和网络功能与计算机分离。换句话说，VM是物理硬件之上的软件加硬件抽象层，用于模拟完整的操作系统。可以想象，虚拟机是一个资源消耗过程，会耗尽计算机的CPU、内存和存储空间。如果您的组件很小（这很常见），您的VM中就会留下许多未充分利用的资源。这使得大多数托管在VM上的基于微服务的应用程序维护起来既费时又昂贵。容器，就像现实生活中的容器一样，里面装着东西。容器将运行微服务所需的代码、系统库和设置打包在一起，使开发人员更容易知道他们的应用程序无论部署在何处都能运行。大多数生产就绪应用程序由多个容器组成，每个容器运行应用程序的一个单独部分，同时共享操作系统(OS)内核。与VM不同，容器需要最少的资源才能在生产中可靠地运行。因此，与VM相比，容器被认为是轻量级的、独立的和可移植的。深入了解Kubernetes我们希望您还在路上！体验过容器和微服务之后，对Kubernetes的了解应该会更容易一些。在生产环境中，您必须管理容器化应用程序的生命周期，以确保不停机并有效利用系统资源。Kubernetes提供了一个框架来自动和弹性地管理分布式系统中的所有这些操作。简而言之，就是集群的操作系统。集群由在网络中连接在一起的多个虚拟机或真实机器组成。正式地，Kubernetes在官方网站上是这样定义的：“Kubernetes是一个可移植的、可扩展的、开源的平台，用于管理容器化的工作负载和服务，促进声明式配置和自动化。它有一个庞大且快速发展的生态系统。Kubernetes服务，支持，并且工具广泛可用。”Kubernetes是一个可扩展的系统。它通过利用模块化架构实现可扩展性。这意味着您的应用程序的每个服务都由定义的API和负载均衡器分隔。负载平衡器是一种机制，系统通过该机制确保每个组件（无论是服务器还是服务）都在利用最大可用容量来执行其操作。扩展应用程序只是更改配置文件中复制容器的数量的问题，或者您可以简单地启用自动缩放。这特别方便，因为系统扩展的复杂性委托给了Kubernetes。自动缩放是通过内存消耗、CPU负载等实时指标完成的。在用户端，Kubernetes自动在集群中的复制容器之间平均分配流量，保持部署稳定。Kubernetes可以提高硬件利用率。生产就绪的应用程序通常依赖于必须跨多个服务器部署、配置和管理的大量组件。如上所述，Kubernetes极大地简化了根据资源可用性标准（处理器、内存等）识别必须部署特定组件的服务器的任务。Kubernetes的另一个很酷的特性是它是自我修复的，这意味着它可以自动从故障中恢复，例如重新生成崩溃的容器。例如，如果某个容器由于某种原因出现故障，Kubernetes会自动将正在运行的容器数量与配置文件中定义的数量进行比较，并根据需要重启新容器以确保停机时间最短。现在我们已经解决了这个问题，是时候看看构成Kubernetes的主要元素了。我们先讲解下层的KubernetesWorker节点，再讲解上层的KubernetesMaster。工作节点是运行容器的小兵，而主节点是监督系统的总部。Kubernetes工作节点组件Kubernetes工作节点（也称为Kubernetesminion）包含与KubernetesMaster（主要是kube-apiserver）通信和运行容器化应用程序所需的所有组件。Docker容器运行时Kubernetes需要一个容器运行时来进行编排。Docker是一个常见的选择，但也可以使用其他替代方案，例如CRI-O和Frakti。Docker是一个用于构建、交付和运行容器化应用程序的平台。Docker运行在每个工作节点上，负责运行容器、下载容器镜像和管理容器环境。PodApod包含一个或多个紧密耦合的容器（例如，一个容器用于后端服务器，另一个容器用于辅助服务，如上传文件、生成分析报告、收集数据等）。这些容器共享相同的网络IP地址、端口空间甚至卷（存储）。此共享卷与容器具有相同的生命周期，这意味着如果容器被删除，该卷将消失。但是，Kubernetes用户可以设置持久卷以将它们与pod分离。然后，在pod被移除后，挂载的卷仍然存在。kube-proxykube-proxy负责路由每个节点上的传入或传出网络流量。kube-proxy也是一个负载均衡器，可以跨容器分配传入的网络流量。kubeletkubelet从kube-apiserver中获取一组pod配置，并确保定义的容器正常运行。Kubernetes主组件KubernetesMaster管理Kubernetes集群并协调工作节点。这是大多数管理任务的主要入口点。etcdetcd是Kubernetes集群的重要组成部分。它是一个键值存储，用于共享和复制所有配置、状态和其他集群数据。kube-apiserver几乎所有Kubernetes组件和控制集群的用户命令之间的通信都是使用RESTAPI调用完成的。kube-apiserver处理所有这些API调用。kube-schedulerkube-scheduler是Kubernetes中的默认调度程序，可以为新创建的pod找到最佳工作节点。如果需要，您还可以创建自己的自定义计划组件。kubectlkubectl是一个客户端命令行工具，用于通过kube-apiserver通信和控制Kubernetes集群。kube-controller-managerkube-controller-manager是一个守护进程（后台进程），内嵌了一组Kubernetes核心功能控制器，如端点、命名空间、复制、服务账户等。cloud-controller-managercloud-controller-manager运行与底层云服务提供商交互的控制器。这允许云提供商将Kubernetes集成到他们正在开发的云基础设施中。谷歌云、AWS和Azure等云提供商已经提供了他们的Kubernetes服务版本。Kubernetes大数据开发大数据解决方案的主要挑战之一是为在生产系统中部署大数据软件定义正确的架构。顾名思义，大数据系统是呈指数级增长的大规模应用程序，可以在线和批量处理数据。因此，需要一个可靠、可扩展、安全且易于管理的平台来弥合要处理的大量数据、软件应用程序和底层基础设施（内部部署或基于云）之间的差距。Kubernetes是在大型基础设施中部署应用程序的绝佳选择之一。借助Kubernetes，您可以处理所需的所有在线和批处理工作负载，例如分析和机器学习应用程序。在大数据世界中，ApacheHadoop一直是部署可扩展和分布式应用程序的主要框架。然而，云计算和云原生应用的兴起削弱了Hadoop的流行度（尽管大多数云提供商如AWS和Cloudera仍然提供Hadoop服务）。Hadoop基本上提供了三个主要功能：资源管理器（YARN）、数据存储层（HDFS）和计算范式（MapReduce）。所有这三个组件都已被更现代的技术所取代，例如用于资源管理的Kubernetes、用于存储的AmazonS3和用于分布式计算的Spark/Flink/Dask。此外，大多数云提供商都提供他们自己的专有计算解决方案。我们首先需要澄清的是，Hadoop或大多数其他大数据堆栈与Kubernetes之间不存在“一对一”的关系。事实上，可以在Kubernetes上部署Hadoop。然而，Hadoop是在与当今时代截然不同的环境中构建和成熟的。它是在网络延迟成为主要问题的时代构建的。企业被迫拥有内部数据中心，以避免为数据科学和分析目的移动大量数据。话虽如此，希望拥有自己的数据中心的大型企业将继续使用Hadoop，但由于有更好的替代方案，采用率可能仍然很低。如今，很多计算都是在内部完成的，主要由云存储提供商和云原生解决方案主导。此外，许多公司选择在本地部署自己的私有云。由于这些原因，Hadoop、HDFS和其他类似产品已经失去了对Kubernetes等更新、更灵活且最终更优越的技术的吸引力。由于Kubernetes集群的可伸缩性和可扩展性，大数据应用程序非常适合使用Kubernetes架构。最近出现了一些将Kubernetes用于大数据的重大动向。例如，ApacheSpark是处理大量数据的重型计算的“典范”，它正在努力添加一个本地Kubernetes调度程序来运行Spark作业。谷歌最近宣布他们正在用Kubernetes取代YARN来安排他们的Spark作业。电子商务巨头eBay已经部署了数千个Kubernetes集群来管理其HadoopAI/ML管道。那么Kubernetes为什么适合大数据应用呢？以两个ApacheSpark作业A和B在一台计算机上做一些数据聚合为例，假设共享依赖已从版本X更新到Y，但是作业A需要版本X，而作业B需要版本Y，作业A将无法运行。在Kubernetes集群中，每个节点将在其自己的驱动程序和执行程序容器上运行独立的Spark作业。此设置将防止依赖项相互干扰，同时仍保持并行性。Kubernetes在部署大数据堆栈时仍然存在一些主要痛点。例如，由于容器是为短期无状态应用程序设计的，缺乏可以在不同作业之间共享的持久存储是运行在Kubernetes上的大数据应用程序的主要问题。其他主要问题包括调度（上面的Spark实现仍处于试验阶段）、安全性和网络。考虑以下场景：节点A在集群中节点B上的数据节点上运行一个作业，需要读取存储在HDFS中的数据。这将大大增加网络延迟，因为现在与YARN不同，数据通过这个隔离系统的网络发送以进行计算。尽管试图解决这些数据局部性问题，但Kubernetes在真正成为部署大数据应用程序的可行和现实选择之前还有很长的路要走。尽管如此，开源社区仍在不懈地努力解决这些问题，以使Kubernetes成为部署大数据应用程序的实用选择。每年，Kubernetes凭借其弹性、可扩展性和资源利用率等固有优势，越来越接近于成为分布式大数据应用的事实平台。在本文中，我们只触及了Kubernetes的皮毛、它的功能和在大数据中的应用。作为一个不断发展的平台，Kubernetes将继续发展成为一个在众多技术领域都有应用的技术，尤其是在大数据和机器学习领域。如果您想了解有关Kubernetes的更多信息，请在“外部链接”部分下找到有关该主题的一些建议。我们希望您喜欢我们关于Kubernetes的文章，并且读起来很有趣。
