kubesphere应用商店少应用 kubernetes 应用

转载

detailtoo 2024-05-11 21:08:26

文章标签 kubesphere应用商店少应用大数据 python java docker 文章分类 架构后端开发

kubernetes 应用

Kubernetes是用于容器编排的流行开源平台，即用于管理由多个基本上独立的运行时（称为容器）构建的应用程序。自2013年启动Docker容器化项目以来，容器已变得越来越受欢迎，但是大型，分布式容器化应用程序可能变得越来越难以协调。通过极大地简化容器化应用程序的规模管理，Kubernetes已成为容器革命的关键部分。

什么是容器编排？

容器支持类似VM的关注点分离，但开销却少得多，灵活性也更高。结果，容器改变了人们对开发，部署和维护软件的思考方式。在容器化的体系结构中，构成应用程序的不同服务被打包到单独的容器中，并跨物理或虚拟机集群部署。但这引起了对容器编排的需求，该工具可自动执行基于容器的应用程序的部署，管理，扩展，联网和可用性。

[ 单击此处注册免费的三个小时的Kubernetes入门课程，该课程由Pluralsight和InfoWorld提供。 ]

什么是Kubernetes？

Kubernetes是一个开源项目，已成为周围最受欢迎的容器编排工具之一。它允许您大规模部署和管理多容器应用程序。实际上，Kubernetes最常与最流行的容器化平台Docker一起使用，但它也可以与符合开放容器倡议（OCI）标准的任何容器系统一起使用，以用于容器映像格式和运行时。而且由于Kubernetes是开放源代码，对其使用方式的限制相对较少，因此任何想要运行容器的人都可以自由使用它，无论是在本地，在公共云中还是在两者中都可以运行它。

谷歌和Kubernetes

Kubernetes最初是Google的一个项目。它是Google Borg（虽然是Google内部使用的较早的容器管理工具）的继承人，尽管不是其直接后代。 Google 在2014年开源了Kubernetes ，部分原因是Kubernetes促进了分布式微服务架构，使其可以轻松地在云中运行应用程序。 Google认为采用容器，微服务和Kubernetes可能会推动客户使用其云服务（尽管Kubernetes当然也可以与Azure和AWS一起使用）。目前，Kubernetes由Cloud Native Computing Foundation维护，该基金会本身是Linux Foundation的组织。

Kubernetes与Docker和Kubernetes与Docker Swarm

Kubernetes不会代替Docker，而是会增强它。但是，Kubernetes 确实替代了围绕Docker出现的一些高级技术。

一种这样的技术是Docker Swarm ，它是与Docker捆绑在一起的协调器。仍然可以使用Docker Swarm代替Kubernetes，但是Docker Inc.已选择将Kubernetes纳入Docker Community和Docker Enterprise版本中。

并不是说Kubernetes是Docker Swarm的直接替代品。 Kubernetes比Swarm复杂得多，并且需要更多的工作来部署。但是，从长远来看，这项工作旨在为企业带来更大的回报-更易于管理，更具弹性的应用程序基础架构。对于开发工作和较小的容器集群，Docker Swarm提供了一个更简单的选择。

Kubernetes与Mesos

作为Kubernetes的竞争对手，您可能听说过的另一个项目是Mesos。 Mesos是一个Apache项目，最初来自Twitter的开发人员。它实际上被视为对Google Borg项目的答案。

Mesos实际上确实提供了容器编排服务，但其野心远不止于此：它旨在成为一种可以协调容器化和非容器化组件的云操作系统。为此，Mesos内可以运行许多不同的平台，包括Kubernetes本身。

Kubernetes体系结构：Kubernetes的工作方式

Kubernetes的架构利用了各种概念和抽象。其中一些是现有的熟悉概念的变体，而其他一些则是Kubernetes特有的。

Kubernetes集群

最高级的Kubernetes抽象，即cluster ，是指运行Kubernetes（本身是集群应用程序）的计算机及其所管理的容器的组。 Kubernetes集群必须具有master ，该系统可以命令和控制集群中的所有其他Kubernetes机器。高度可用的Kubernetes集群可在多台机器之间复制主设备的设施。但是一次只能有一个主服务器运行作业调度程序和控制器管理器。

Kubernetes节点和Pod

每个集群包含Kubernetes 节点。节点可能是物理机或VM。同样，这个想法是抽象的：无论运行什么应用程序，Kubernetes都可以处理该衬底上的部署。 Kubernetes甚至可以确保某些容器仅在VM或仅在裸机上运行。

节点运行pods ，这是可以创建或管理的最基本的Kubernetes对象。每个Pod代表Kubernetes中应用程序或正在运行的进程的单个实例，并且由一个或多个容器组成。 Kubernetes以一个组的形式启动，停止和复制Pod中的所有容器。容器将用户的注意力放在应用程序上，而不是容器本身上。从Pod的状态开始，有关如何配置Kubernetes的详细信息保存在Etcd （分布式键值存储）中。

可以根据需要在节点上创建和销毁Pod，以符合用户在Pod定义中指定的期望状态。 Kubernetes提供了一个称为控制器的抽象，用于处理豆荚如何上料，下料和下料的物流。根据要管理的应用程序的种类，控制器有几种不同的风格。例如，最近引入的“ StatefulSet”控制器用于处理需要持久状态的应用程序。另一种控制器Deployment用来放大或缩小应用程序，将应用程序更新到新版本，或者在出现问题时将应用程序回滚到已知良好的版本。

Kubernetes服务

由于Pod根据需要生存和死亡，因此我们需要不同的抽象来处理应用程序生命周期。即使运行组成该应用程序的容器的容器本身不是持久性的，应用程序也应该是持久性实体。为此，Kubernetes提供了一种称为服务的抽象。

Kubernetes中的服务描述了如何通过网络访问给定的Pod组（或其他Kubernetes对象）。正如Kubernetes文档所说，构成应用程序后端的pod可能会发生变化，但是前端不必知道或跟踪它。服务使这成为可能。

Kubernetes内部还有一些其他部分使图片更完整。调度程序将工作负载分配给节点，以便它们在资源之间达到平衡，从而使部署满足应用程序定义的要求。控制器管理器确保系统状态（应用程序，工作负荷等）与Etcd的配置设置中定义的所需状态匹配。

重要的是要记住，Kubernetes不会替换容器使用的任何低级机制，例如Docker本身。相反，Kubernetes为使用这些机制提供了更大的抽象集，以保持应用程序大规模运行。

Kubernetes入口

Kubernetes服务被认为在集群中运行。但是您将希望能够从外部访问这些服务。 Kubernetes包括NodePort和LoadBalancer在内的多个组件以不同程度的简单性和健壮性来促进这一工作，但是灵活性最高的组件是Ingress 。入口是一个API，通常通过HTTP管理对集群服务的外部访问。

Ingress确实需要进行一些配置才能正确设置-写了一本有关Kubernetes开发的书的马修·帕尔默（Matthew Palmer）引导您完成其网站上的过程。

Kubernetes仪表板

一个Kubernetes组件，它可以帮助你保持对所有这些其他组件的顶部是仪表板，基于Web的用户界面，使用它可以部署和故障排除的应用程序和管理群集资源。仪表板默认情况下未安装，但添加它并不会带来太大麻烦。

Kubernetes的优势

因为Kubernetes引入了新的抽象和概念，并且因为Kubernetes的学习曲线很高，所以询问使用Kubernetes的长期收益是正常的，这是正常的。以下是一些在Kubernetes内运行应用程序变得更容易的特定方式的摘要。

Kubernetes为您管理应用程序的运行状况，复制，负载平衡和硬件资源分配

Kubernetes的一项最基本职责就是保持应用程序的正常运行，运行并响应用户需求。变得“不健康”或不符合您为它们描述的健康定义的应用可以自动修复。

Kubernetes提供的另一个好处是最大限度地利用了硬件资源，包括内存，存储I / O和网络带宽。应用程序可以对资源使用情况设置软限制和硬限制。许多使用最少资源的应用程序可以打包在同一硬件上。需要扩展的应用程序可以放置在有增长空间的系统上。同样，可以自动在整个群集中推出更新，或者在更新中断时进行回退。

Kubernetes使用Helm图表简化了预配置应用程序的部署

软件包管理器（例如Debian Linux的APT和Python的Pip）为用户节省了手动安装和配置应用程序的麻烦。当应用程序具有多个外部依赖项时，这尤其方便。

Helm本质上是Kubernetes的软件包经理。许多流行的软件应用程序必须作为一组相互依赖的容器在Kubernetes中运行。 Helm提供了一种定义机制，即“图表”，它描述了如何将应用程序或服务作为Kubernetes内部的一组容器来运行。

您可以从头开始创建自己的Helm图表，如果要构建要在内部部署的自定义应用程序，则可能必须这样做。但是，如果您使用的是具有通用部署模式的流行应用程序，那么很有可能有人已经为其编写了Helm图表并将其发布在官方的Helm图表存储库中。查找官方Helm图表的另一个地方是Kubeapps.com目录。

Kubernetes简化了存储，机密和其他与应用程序相关的资源的管理

容器是不可变的。无论您放入其中的什么，都不应改变。但是应用程序需要状态，这意味着它们需要一种可靠的方式来处理外部存储卷。在应用程序的整个生命周期中，容器的生存，死亡和重生的方式使情况变得更加复杂。

Kubernetes提供抽象以允许容器和应用程序以与其他资源相同的解耦方式处理存储。可以通过Kubernetes存储驱动程序（称为卷）访问从Amazon EBS卷到普通的旧NFS共享的许多常见存储类型。通常，卷绑定到特定的Pod，但是称为“ Persistent Volume ”的卷子类型可以用于需要独立于任何Pod生存的数据。

容器通常需要使用“ 机密 ”，即您不希望将其硬编码到容器中或公开存放在磁盘卷上的API密钥或服务密码等凭据。尽管可以使用第三方解决方案（例如Docker机密和HashiCorp Vault），但Kubernetes具有自己的本地机密处理机制，尽管需要谨慎配置。例如，Etcd必须配置为在节点之间（而非纯文本）发送机密时使用SSL / TLS。

Kubernetes应用程序可以在混合和多云环境中运行

云计算的长期梦想之一是能够在任何云中，或在公共或私有云的任何混合中运行任何应用程序。这不仅是为了避免供应商锁定，而且还可以利用特定于各个云的功能。

Kubernetes提供了一组原语（统称为联邦），用于使多个集群在多个区域和云之间彼此同步。例如，一个给定的应用程序部署可以在多个群集之间保持一致，并且不同的群集可以共享服务发现，以便可以从任何群集访问后端资源。无论您是否跨越多个云环境，联合身份验证还可用于创建高可用性或容错的Kubernetes部署。

对于Kubernetes来说，联盟还相对较新。尚未在联合实例之间支持所有API资源，并且升级还没有自动测试基础结构。但是这些缺点将在将来的Kubernetes版本中解决。