Kubernetes是什么?
在过去的几年中，Kubernetes一直是DevOps和Data Science社区中令人兴奋的话题。 它已经连续发展成为开发云原生应用程序的首选平台之一。 由Google作为开放源代码平台构建的Kubernetes可以处理将容器调度到计算集群上的工作，并管理工作负载以确保它们按预期运行。
但是，有一个陷阱：这意味着什么? 当然，有可能对Kubernetes进行其他研究，但是假设大多数读者已经对技术基础有所了解，那么Internet上的许多文章都是用专业术语和复杂术语充斥的高级概述。
在这篇文章中，我们试图提供对Kubernetes架构及其在大数据中的应用的易于理解的解释，同时澄清繁琐的术语。 但是，我们假设我们的读者已经对应用程序开发和编程领域有所了解。 我们希望到本文结尾时，您已经对该主题有了更深入的了解，并准备进行更深入的研究。
什么是微服务?
为了了解Kubernetes的工作原理以及我们为什么需要它，我们需要研究微服务。 对于微服务，尚无公认的定义，但简单地说，微服务是较小的，是执行特定任务的较大应用的分离组件。 这些组件通过REST API相互通信。 这种架构使应用程序可扩展和可维护。 这也使开发团队的工作效率更高，因为每个团队都可以专注于自己的组件，而不会干扰应用程序的其他部分。
由于每个组件或多或少地独立于应用程序的其他部分运行，因此有必要拥有可以管理和集成所有这些组件的基础架构。 该基础结构将需要保证在生产中部署时所有组件都能正常工作。
容器与虚拟机(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的主要元素了。 我们将首先解释下层的Kubernetes Worker节点，然后解释上层的Kubernetes Master。 工人节点是运行容器的奴才，而主节点是监督系统的总部。
Kubernetes工作节点组件
Kubernetes工作者节点(也称为Kubernetes奴才)包含与Kubernetes Master(主要是kube-apiserver)通信并运行容器化应用程序的所有必需组件。
Docker容器运行时Kubernetes需要一个容器运行时才能进行编排。 Docker是一个常见的选择，但也可以使用其他替代方案，例如CRI-O和Frakti。 Docker是一个用于构建，交付和运行容器化应用程序的平台。 Docker在每个工作程序节点上运行，并负责运行容器，下载容器映像和管理容器环境。
PodA pod包含一个或多个紧密耦合的容器(例如，一个用于后端服务器的容器，另一个用于辅助服务的容器，例如上载文件，生成分析报告，收集数据等)。 这些容器共享相同的网络IP地址，端口空间甚至卷(存储)。 此共享卷具有与容器相同的生命周期，这意味着如果除去容器，该卷将消失。 但是，Kubernetes用户可以设置持久卷以将其与Pod分离。 然后，卸下吊舱后，已安装的卷仍将存在。
kube-proxy kube-proxy负责路由每个节点上的传入或传出网络流量。 kube-proxy还是一个负载均衡器，可跨容器分布传入的网络流量。
kubelet kubelet从kube-apiserver获取一组pod配置，并确保定义的容器正常运行。
Kubernetes主组件
Kubernetes Master管理Kubernetes集群并协调工作节点。 这是大多数管理任务的主要切入点。
etcd etcd是Kubernetes集群的重要组成部分。 它是一个键值存储，用于共享和复制所有配置，状态和其他群集数据。
kube-apiserver几乎所有Kubernetes组件之间的通信以及控制集群的用户命令都是使用REST API调用完成的。 kube-apiserver负责处理所有这些API调用。
kube-scheduler kube-scheduler是Kubernetes中的默认调度程序，可为新创建的Pod查找最佳工作节点。 如果需要，您还可以创建自己的自定义计划组件。
kubectl kubectl是一个客户端命令行工具，用于通过kube-apiserver通信和控制Kubernetes集群。
kube-controller-manager kube-controller-manager是一个守护程序(后台进程)，它嵌入了一组Kubernetes核心功能控制器，例如端点，名称空间，复制，服务帐户等。
cloud-controller-managercloud-controller-manager运行与基础云服务提供商进行交互的控制器。 这使云提供商可以将Kubernetes集成到他们正在开发的云基础架构中。 诸如Google Cloud，AWS和Azure之类的云提供商已经提供了其Kubernetes服务版本。
Kubernetes大数据
开发大数据解决方案的主要挑战之一是定义正确的体系结构，以在生产系统中部署大数据软件。 顾名思义，大数据系统是处理在线和批处理数据的指数级增长的大规模应用程序。 因此，需要一个可靠，可扩展，安全且易于管理的平台来弥合要处理的大量数据，软件应用程序和底层基础结构(内部部署或基于云)之间的差距。
Kubernetes是在大型基础架构中部署应用程序的优秀选择之一。 使用Kubernetes，可以处理需要的所有在线和批处理工作负载，例如分析和机器学习应用程序。
在大数据世界中，Apache Hadoop一直是用于部署可扩展和分布式应用程序的主导框架。 但是，云计算和云原生应用程序的兴起削弱了Hadoop的普及程度(尽管像AWS和Cloudera这样的大多数云供应商仍提供Hadoop服务)。 Hadoop基本上提供了三个主要功能：资源管理器(YARN)，数据存储层(HDFS)和计算范例(MapReduce)。 所有这三个组件都已被更现代的技术所取代，例如用于资源管理的Kubernetes，用于存储的Amazon S3和用于分布式计算的Spark / Flink / Dask。 此外，大多数云供应商都提供自己的专有计算解决方案。
我们首先需要澄清的是，Hadoop或大多数其他大数据堆栈与Kubernetes之间没有"一对一"的关系。 实际上，人们可以在Kubernetes上部署Hadoop。 但是，Hadoop是在与当今时代截然不同的环境中构建和成熟的。 它是在网络延迟成为主要问题的时代构建的。 企业被迫拥有内部数据中心，以避免为了数据科学和分析目的而不得不移动大量数据。 话虽如此，希望拥有自己的数据中心的大型企业将继续使用Hadoop，但是由于更好的替代方案，采用率可能仍然很低。
如今，在云存储提供商和云原生解决方案的主导下，企业内部进行了大量的计算操作。 此外，许多公司选择在内部部署自己的私有云。 由于这些原因，Hadoop，HDFS和其他类似产品已经失去了对更新，更灵活，最终更优秀的技术(例如Kubernetes)的吸引力。
大数据应用程序是使用Kubernetes架构的良好候选者，因为Kubernetes集群具有可伸缩性和可扩展性。 最近发生了一些重大运动，将Kubernetes用于大数据。 例如，Apache Spark是处理大量数据的繁重运算的"海报子"，它正在努力添加本机Kubernetes调度程序以运行Spark作业。 谷歌最近宣布，他们将用Kubernetes替换YARN，以安排其Spark工作。 电子商务巨头eBay已部署了数千个Kubernetes集群来管理其Hadoop AI / ML管道。
那么Kubernetes为什么适合大数据应用呢? 以两个Apache Spark作业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的文章，并且读起来很有趣。
