使用Kubernetes启动项目所需的一切
在微服务，云计算和无服务器架构时代，了解Kubernetes并学习如何使用它非常有用。 但是，特别是对于新手来说，Kubernetes的官方文档可能很难解读。 在以下系列文章中，我将尝试提供Kubernetes的简化视图，并提供示例，说明如何使用它通过不同的云提供商(例如Azure，Amazon，Google Cloud甚至IBM)来部署微服务。
在本系列的第一篇文章中，我们将讨论Kubernetes中使用的最重要的概念。 在以下文章中，我们将学习如何编写配置文件，如何将Helm用作程序包管理器，如何创建云基础架构以及如何使用Kubernetes轻松编排我们的服务。 在上一篇文章中，我们将创建一个CI / CD管道来自动化整个工作流程。 利用这些信息，您将能够启动任何类型的项目并创建可靠的基础架构/体系结构。
在开始之前，我想提一提，使用容器有很多好处，从提高部署速度到在更大的水平范围内交付的一致性。 即使这样，您也不应该对所有内容都使用容器，因为仅将应用程序的任何部分放入容器中都会带来诸如维护容器编排层的开销。 因此，不要一味得出结论，相反，在项目开始时，请创建成本/收益分析。
现在开始在Kubernetes的世界中开始我们的旅程!
硬件
节点 Node
节点是Kubernetes中最小的工作单元，可以是任何具有CPU和RAM内存的设备。 例如，节点可以是任何东西，从智能手表，智能手机，笔记本电脑甚至是RaspberryPi。 当我们与云提供商合作时，节点就是虚拟机。 因此，节点是单个设备上的抽象。
正如您将在下一篇文章中看到的那样，这种抽象的优点在于我们不需要了解底层的硬件结构，我们只需要使用节点，这样我们的基础架构将独立于平台。
> Node
集群 Cluster
集群是一组节点。 将程序部署到群集时，它会自动处理将工作分配到各个节点的情况。 如果需要更多资源(例如，我们需要更多内存)，则可以将新节点添加到群集中，并且工作将自动重新分配。
我们在集群上运行代码，而不必在意哪个节点上，工作的分配将自动进行。
> Cluster
持久卷 Persistent Volumn
由于我们的代码可以从一个节点重定位到另一个节点(例如，一个节点没有足够的内存，因此工作将重新安排在另一个具有足够内存的节点上)，因此保存在节点上的数据是易失的。 但是在某些情况下，我们想要永久保存数据。 在这种情况下，我们应该使用持久卷。 永久卷就像一个外部硬盘驱动器，您可以将其插入并在其中保存数据。
Kubernetes最初是作为无状态应用程序平台开发的，其中持久性数据存储在其他位置。 随着项目的成熟，许多组织也希望开始将其用于有状态应用程序，因此添加了持久的卷管理。 与虚拟化的早期阶段非常相似，数据库服务器通常不是迁移到这种新架构中的第一批服务器。 原因是数据库是许多应用程序的核心，并且可能包含有价值的信息，因此本地数据库系统仍主要在VM或物理服务器中运行。
所以问题是，什么时候应该使用持久卷? 要回答这个问题，首先我们应该了解不同类型的数据库应用程序。
我们可以将数据管理解决方案分为两类：
- 垂直可扩展—包括传统的RDMS解决方案，例如MySQL，PostgreSQL和SQL Server
- 水平可扩展—包括" NoSQL"解决方案，例如ElasticSearch或基于Hadoop的解决方案
垂直可伸缩解决方案(如MySQL，Postgres，Microsoft SQL等)不应放入容器中。 这些数据库平台需要高I / O，共享磁盘，块存储等，并且并未设计为优雅地处理群集中节点丢失的情况，这种情况通常发生在基于容器的生态系统中。
对于水平可伸缩应用程序(Elastic，Cassandra，Kafka等)，应使用容器，因为它们可以承受数据库集群中节点丢失的损失，并且数据库应用程序可以独立地重新平衡。
通常，您可以并且应该对使用冗余存储技术的分布式数据库进行容器化，并且可以承受数据库集群中节点的丢失(ElasticSearch是一个很好的例子)。
软件
容器 Container
现代软件开发的目标之一是使同一主机或群集上的应用程序彼此隔离。 虚拟机是解决此问题的一种方法。 但是虚拟机需要自己的操作系统，因此通常大小为千兆字节。
相比之下，容器将应用程序的执行环境彼此隔离，但共享底层操作系统内核。 因此，容器就像一个盒子，我们在其中存储运行应用程序所需的所有内容，例如代码，运行时，系统工具，系统库和设置等。它们通常以兆字节为单位进行度量，它们使用的资源比VM少得多， 并几乎立即启动。
吊舱 Pod
吊舱是一组容器。 在Kubernetes中，最小的工作单元是吊舱。 一个Pod可以包含多个容器，但是通常每个Pod使用一个容器，因为Kubernets中的复制单元是Pod。 因此，如果要独立缩放每个容器，则可以在容器中添加一个容器。
部署 Deployment
部署的主要作用是为Pod和副本集(同一Pod多次复制的集合)提供声明性更新。 使用部署，我们可以指定同一时间可以运行多少个相同pod的副本。 部署就像是Pod的管理器一样，它将自动增加请求的Pod的数量，它将监视Pod，并在出现故障的情况下重新创建Pod。 部署确实有帮助，因为您不必分别创建和管理每个Pod。
部署通常用于无状态应用程序。 但是，您可以通过将持久卷附加到部署卷并使其成为有状态来保存部署状态。
有状态集 StatefulSet
StatefulSet是Kubernetes中的一个新概念，它是用于管理有状态应用程序的资源。 它管理一组Pod的部署和扩展，并提供有关这些Pod的顺序和唯一性的保证。 它与Deployment类似，唯一的区别是Deployment会创建具有随机Pod名称的Pod集，并且Pod的顺序并不重要，而StatefulSet创建具有唯一命名约定和顺序的Pod。 因此，如果要创建名为example的Pod的三个副本，StatefulSet将创建具有以下名称的Pod：example-0，example-1，example-2。 在这种情况下，最重要的好处是您可以依靠窗格的名称。
守护程序集 DeamonSet
DaemonSet确保Pod在群集的所有节点上运行。 如果从集群添加/删除节点，DaemonSet会自动添加/删除容器。 这对于监视和日志记录很有用，因为这样可以确保您一直在监视每个节点，而不必手动管理群集的监视。
服务 Service
部署负责使一组Pod保持运行，而服务负责启用对一组Pod的网络访问。 服务提供了跨集群标准化的重要功能：负载平衡，应用程序之间的服务发现以及支持零停机应用程序部署的功能。 每个服务都有一个唯一的IP地址和一个DNS主机名。 可以将使用服务的应用程序手动配置为使用IP地址或主机名，并且流量将负载平衡到正确的Pod。 在"外部流量"部分，我们将详细了解服务类型以及如何使用它们在内部服务之间以及与外部世界进行通信。
ConfigMaps
如果您想部署到舞台，开发人员和产品等多个环境，由于环境差异，将配置烘焙到应用程序中是一个不好的做法。 理想情况下，您需要分离配置以匹配部署环境。 这就是ConfigMap发挥作用的地方。 ConfigMap允许您将配置工件与图像内容分离，以使容器化的应用程序具有可移植性。
外部流量
因此，您已经在集群中运行了所有服务，但是现在的问题是如何使外部流量进入集群? 共有三种不同的服务类型，可用于处理外部流量：ClusterIP，NodePort和LoadBalancer。 第四个解决方案是添加另一个抽象层，称为入口控制器。
集群IP
这是Kubernetes中的默认服务类型，它使您可以与集群内的其他服务进行通信。 这不是为了外部访问，而是通过使用代理的一点技巧，外部流量会影响我们的服务。 不要在生产中使用此解决方案，而只能用于调试。 声明为ClusterIP的服务不应在外部直接可见。
节点端口
正如我们在本文的第一部分中看到的那样，pod在节点上运行。 节点可以是不同的设备，例如笔记本电脑，也可以是虚拟机(在云中工作时)。 每个节点都有一个固定的IP地址。 通过将服务声明为NodePort，该服务将公开该节点的IP地址，因此您可以从外部访问它。 可以在生产中使用它，但是对于大型应用程序(其中有许多服务)，手动管理所有不同的IP地址可能很麻烦。
负载均衡器
声明类型为LoadBalancer的服务会使用云提供商的负载均衡器在外部公开它。 来自该外部负载平衡器的流量如何路由到服务窗格，取决于群集提供程序。 这是一个非常好的解决方案，您不必管理群集中每个节点的所有IP地址，但是每个服务只有一个负载均衡器。 缺点是，每个服务都将有一个单独的负载平衡器，并且将按每个负载平衡器实例向您收费。
该解决方案确实非常适合生产，但是可能会有点贵。 因此，让我们看一个更便宜的解决方案。
入口 Ingress
入口不是服务，而是管理群集中对服务的外部访问的API对象。 它充当集群的反向代理和单个入口点，该集群将请求路由到其他服务。 我通常使用NGINX Ingress Controller，该控制器承担反向代理的角色，同时还充当SSL。 要暴露入口，最好的生产就绪解决方案是使用负载平衡器。
使用此解决方案，您可以使用单个负载均衡器公开任何数量的服务，从而可以使您的账单尽可能低。
下一步
在本文中，我们了解了Kubernetes中使用的基本概念，了解了其硬件结构，了解了Pod，Deployments，StatefulSets，Services等不同的软件组件，并了解了如何在服务之间以及与外界进行通信。
在下一篇文章中，我们将在Azure上设置群集，并创建一个带有LoadBalancer，一个Ingress Controller，两个服务的基础结构，并使用两个Deployment来为每个服务启动三个Pod。
如果您需要更多"愚蠢简单"的解释，请在"中等"上关注我!
还有另一个正在进行的"愚蠢的简单AI"系列。 可以在此处找到前两篇文章：Python中的SVM和内核SVM和KNN。
感谢您阅读本文!
