英国DEVOXX。Kubernetes投入生产：蓝/绿部署，自动扩展和部署自动化。第1部分

Kubernetes是在集群生产环境中运行Docker容器的绝佳工具。但是，有些任务是Kubernetes无法解决的。由于在生产环境中进行频繁的部署，我们需要一个全自动的Blue / Green部署来避免此过程中的停机时间，这也需要外部HTTP请求和SSL上传。这需要与负载平衡器（例如ha-proxy）集成。另一个任务是在云中工作时Kubernetes集群本身的半自动扩展，例如，在晚上部分减少集群的规模。

尽管Kubernetes没有开箱即用的功能，但它提供了可用于解决此类问题的API。 Kubernetes集群自动蓝/绿部署和扩展工具是Cloud RTI开放源项目的一部分。

该视频记录本介绍了如何配置Kubernetes以及其他开放源代码组件，以实现生产就绪的环境，该环境可以接受git commit change commit中的代码，而不会导致生产停机。



今天，我们将讨论Kubernetes，尤其是其自动化。我们将研究该系统的基础知识，然后继续介绍如何在开发阶段将Kubernetes集成到项目中。我的名字叫Paul，来自荷兰，在一家名为Luminis Technologies的公司工作，我是《用OSGi设计云应用程序》和《调制Java 9》一书的作者。我要说的与这些书的主题大不相同。
去年，我大部分时间都花在了基于Kubernetes的基础架构平台上并为其创建工具，主要是在Golang上。另外，我仍在继续编写Java 9书籍，我的爱好是举重。因此，让我们开始做生意。

为什么要照顾Kubernetes？首先，因为它允许您在集群中运行Docker。如果您不使用Docker，那么您将不在主题之列。如果您使用Docker，那么您会知道它主要是为了在自己的机器上运行容器而设计的。它改善了许多网络的工作，但是，所有这些仅限于一台机器，因此无法在集群中运行容器。



Docker的创建者正在不断扩展其功能，但是如果您确实需要在生产中运行容器，则将需要Kubernetes之类的东西，因为带有其命令行的Docker并没有帮助。

让我们谈谈Kubernetes的基础知识。在考虑将API用于自动化之前，我们需要了解该平台的工作原理。典型的群集包括以下元素。主节点管理和控制整个集群的操作，并决定将在何处计划容器以及如何启动容器。它会启动API服务器，这是平台工作中最重要的元素，稍后我们将详细考虑此问题。



有一大堆Node工作节点，其中包含带有Docker容器的Pods容器和分布式存储etcd。节点是容器运行的地方。 Kubernetes不能直接与Docker容器一起使用，但是为此使用了一个称为Pod的抽象。工作节点启动一堆容器，而主节点确保它们工作。此外，还有一个分布式键值类型etcd存储，用于存储有关集群的所有信息。 Etcd是容错的，因此至少包含3个独立的节点。这样可以确保向导正常运行而不会丢失状态。

使用上述所有组件启动Kubernetes之后，将部署调度容器。部署意味着容器开始在集群中工作。为此，首先，需要在主服务器上启动一个名为“复制控制器”的对象，该对象使您可以创建和监视多个炉床实例的状态。



若要将复制控制器配置为在五个不同的工作节点中创建5个容器副本，您需要具有许多节点。控制器除了启动这些容器的操作外，还监视它们的状态。如果由于内存不足而导致其中一个容器出现故障，则控制器将记录该数目从5减少到4，并在其中一个可用节点上启动一个新容器。这意味着当Kubernetes运行时，您无需在任何特定节点上启动容器，而是设置所需的状态-配置平台以部署5个容器并将控制权转移到复制控制器，这将维护该状态。因此，Replication Controller是一个非常重要的概念。

如我所说，Kubernetes不能直接与容器一起使用。他通过Pod（容器顶部的抽象）来做到这一点。重要的是，Kubernetes不仅可以与Docker容器一起运行，而且还可以与它的替代-rkt容器一起运行。这不是官方支持，因为如果您查看Kubernetes技术文档，则仅讨论Docker容器。但是，随着平台的发展，与其他格式容器的兼容性也随之增加。



每个容器可以包含许多具有相同生命周期的容器。这意味着我们将无法在同一吊舱中出于各种目的运行容器，因为所有容器只能在同一时间段内存在。他们同时开始并同时停止工作。因此，如果您使用微服务，则不能将它们全部放在同一个子目录中。炉膛内的容器在本地主机上彼此“看到”。

例如，如果您要部署Web服务，则此应用程序的容器将包含nginx容器，并且nginx不会被修改，而是直接可用。为了使此nginx能够正常工作，我们需要添加自己的HTML文件，并将它们放在用于Web文件的单独容器中。这两个容器都放在一个公共子容器中，并且开始一起工作，就像它们存在于同一物理计算机上一样，因此它们可以看到位于同一本地主机上的同一文件系统的文件。提供群集组件交互的服务使用env vars环境变量进行操作。

接下来提供的是网络。例如，如果您在同一台物理计算机（也可以位于云中）上运行多个容器，并且所有这些容器都使用端口，例如，我们使用3个与同一端口8080一起使用的Java应用程序，那么就会充满冲突。为了避免这种情况，您将需要端口映射端口映射，这将使部署应用程序的过程大大复杂化。



因此，如果每个启动的容器都具有自己的虚拟IP地址并且可以访问所有可用端口，而无需考虑它们可能的冲突，那就太好了。这正是Kubernetes提供的。

每次创建Pod时，都会为其创建自己的虚拟IP地址。其余Pod之间不共享端口，因此没有冲突。在此IP地址上唯一起作用的就是此容器的作用。这一切都简化了。
但是，这带来了一个新问题：如果每次重新启动容器时虚拟IP地址都发生更改（这种情况经常发生），那么如何使用这些容器？假设我们有2个相互通讯的Pod，但是它们的IP地址一直在变化。 Kubernetes使用称为服务的概念来解决此问题。这些服务在您的壁炉上方配置代理，并继续使用一定范围内的虚拟IP地址，但是这些是固定地址，不会一直更改。

因此，当Pod希望彼此通信时，它们不是直接而是通过服务使用这些固定IP地址进行通信。



这些服务组织在群集组件之间交换的所有副本的流量。因此，服务对于确保组件之间的通信非常重要。
当多个组件是大型应用程序（例如微服务架构）的一部分时，“服务”概念极大地促进了多组件部署过程，尽管我个人不喜欢处理微服务。



您拥有的每个组件都可以部署为具有其生命周期的单独子组件。它们彼此独立并且具有独立的名称空间，它们自己的IP地址和端口号范围可以独立更新和缩放。使用服务极大地促进了组件间的通信。以下幻灯片显示了几个组件的示例应用程序。



前端下的第一个是使用多个后端服务或后端服务副本的用户界面。您会看到捆绑了几个这样的Pod的捆绑包，它们的服务被用作代理。您不必在乎每个Pod的性能，因为如果其中一个Pod出现故障，Kubernetes将自动重启新Pod。后端服务使用位于不同Pod中的许多其他服务，并且所有这些都使用服务的概念进行交互。所有这些都很好用，因此，如果您使用这种架构，Kubernetes可以轻松地部署它。如果体系结构是基于不同的原理构建的，则可能会遇到问题。

下一个要介绍的重要概念是命名空间名称空间。



这些是Kubernetes中包含炉膛，复制控制器和服务的隔离空间。隔离意味着，例如，当开发环境在一个名称空间中而生产在另一名称空间中时，则使用具有相同名称的服务来防止不同名称空间之间的冲突。这样，您可以轻松地将不同的环境放置在同一物理Kubernetes集群中。

在生产环境中发布应用程序之前，部署应用程序是必要的步骤。 Kubernetes文档指出您必须使用kubectl命令行工具才能完成部署。该工具正在不断改进，非常适合部署任何东西。



您会看到使用kubectl命令为API创建的yaml配置文件。下一张幻灯片显示了典型的yaml文件的外观。



在此文件中，我们设置复制控制器。第一个重要部分是要复制的副本数量所在的行：3。该数目等于要使用的节点数。在这种情况下，数字3表示我们要在集群中的3台不同计算机上运行pod。复制控制器监视系统的状态，并在必要时自动重新启动容器，以确保给定数量的副本的连续操作。

代码底部是代表炉膛规格的行。它描述了端口，存储节点，Web服务器的名称和映像以及Docker容器所需的其他信息。

最后，这里有一堆元数据，例如标签。标签是键值对，并被添加到诸如Pod之类的对象中。它们用于分组和选择对象的子集。它们对于组织API交互，将控制器，吊舱和服务链接在一起非常重要。

Pod不知道是哪个复制控制器创建的，并且复制控制器也不知道它创建的Pod的列表。但是吊舱和控制器都具有标签，它们的重合指示特定的子属于特定的控制器。这是一个相当弱但灵活的连接，可确保API和自动化事物的稳定运行。

现在，您将看到一个简短的演示，展示了kubectl的工作，然后我们将更深入地研究负载平衡器并使用API​​。因此，我输入了kubectl get pods命令，但是系统没有显示任何炉膛，因为我们还没有运行任何东西。接下来，我输入ls命令以查看可用文件的列表。



现在，我从列表中输入第一个文件的名称，并显示配置yaml文件，类似于我们刚刚看过的文件。让我们使用此文件通过键入kubectl create –f nginx-controller.yaml来创建一个炉膛。结果，我们将在下创建。通过重复执行kubectl get pods命令，您可以看到这一方法有效。



但这只是一个缺点。让我们尝试通过创建多个副本来扩展控制器。为此，我输入命令kubectl scale rc nginx-副本= 5，其中rc是复制控制器，而5是所需的实例数或该控制器的副本。您会看到创建容器的进度，如果在几秒钟后重新输入kubectl get pods命令，则可以看到大多数创建的容器已经开始工作。



因此，我们将集群中运行的炉床或副本的数量增加到5个副本。另外，例如，您可以通过输入kubectl describe pod nginx-772ia命令查看为第一个副本创建的IP地址。这是附加到此特定容器的虚拟IP地址。



他的工作将由上述服务提供。让我们看看如果销毁一个工作副本会发生什么，因为在任何情况下，我们都必须确保一定数量的副本能够正常工作。我输入kubectl delete pod nginx-772ia命令，系统报告带有该标识符的下已被删除。使用kubectl get pods命令，我们看到5个控制器实例再次正常工作，并且出现了一个新的标识符为nginx-sunfn的远程副本，而不是远程副本nginx-772ia。



发生这种情况是因为Kubernetes注意到其中一个副本的故障。实际上，就我个人而言，这不是偶然的故障，而是故意的操作。但是，由于群集配置指定的副本数量保持不变，因此复制控制器注意到实例之一的消失，并通过创建并使用新ID启动新容器立即恢复了群集的所需状态。当然，当我自己删除副本并等待控制器还原副本时，这是一个愚蠢的示例，但是由于容器故障（例如由于内存不足），在现实生活中也会发生类似情况。在这种情况下，控制器也将重新启动。

如果我们有几种生产场景，其中Java应用程序的配置不正确，例如，安装的内存不足，则可能在程序启动后几个小时和一周内导致崩溃。在这种情况下，Kubernetes会确保工作流不会中断。

让我再次提醒您，当您不应该使用kubectl命令行和其他通过键盘输入的内容来确保产品运行时，上述所有内容都不适用于生产阶段。因此，在开始部署自动化之前，我们需要解决另一个大问题。假设我现在正在运行一个nginx容器，但是我无法从“外部世界”访问它。但是，如果它是一个Web应用程序，那么我可以通过Internet访问它。为了确保此过程的稳定性，使用了位于群集前面的负载平衡器。
我们需要能够从外部管理Kubernetes服务，并且开箱即用不会自动支持此功能。例如，为了确保HTTP平衡，您需要使用SSL卸载或SSL上载。这是从Web服务器接收的入站流量中删除基于SSL的加密的过程，以使服务器免于数据解密。为了平衡流量，您还可以使用网页的Gzip压缩。

Kubernetes的最新版本（例如1.02）具有称为Ingress的新功能。它用于配置负载均衡器。这是API中的一个新概念，您可以在其中编写一个插件，该插件将配置您使用的任何外部负载均衡器。



不幸的是，今天这个概念尚未最终确定，仅在alpha版本中提供。您可以演示它将来的工作方式，但与今天的工作方式不匹配。我使用的是Google Cloud Engine提供的平衡器，但是，如果您不使用此服务，则至少在目前，您需要自己做一些事情。在将来，大概一个月内，它将变得更加容易-您可以使用入口功能来平衡流量。

今天，通过创建自定义流量平衡器可以解决此问题。首先，您可以使用位于Kubernetes集群前面的ha-proxy。它在外部计算机或一组计算机上的群集外部运行。接下来，有必要提供ha-proxy的自动动态配置，以免在创建每个新炉床时手动进行配置。对于nginx，Apache和其他服务器，需要完成类似的工作，并且ha-proxy可以轻松集成。

下一张幻灯片显示了负载平衡器节点如何处理传入的HTTPS流量，并且ha-proxy位于Kubernetes群集之外的外部计算机或计算机群集上。 SSL上传也位于此处。代理检测到请求的地址，然后将流量传递给Kubernetes服务，而无需关注随时间变化的炉床的IP地址。接下来，服务将流量传递给具有动态IP地址的运行Pod。



如果使用AWS，则可以使用ELB负载平衡器概念。 Elastic Load Balancing将流量重定向到运行状况良好的Amazon实例，以确保应用程序的稳定性。如果您需要负载平衡器的可伸缩性，则此机制特别好。



在这种情况下，流量首先被发送到AWS服务，在此SSL被卸载，然后进入ha-proxy负载均衡器节点。

如果您的群集完全在专用虚拟VPN网络中，则可以执行相同的操作。在这种情况下，使用AWS ELB可以完全确保系统的安全性。您无需在集群外部的各个组件之间实现SSL。唯一与外界联系的是我们的ha-proxy。



从概念上讲，它看起来很简单，但实际上如何工作？如何设置ha-proxy，使其了解Kubernetes服务？如果以与考虑nginx相同的方式查看ha-proxy，您会注意到它仍然使用静态配置文件。因此，如果您想为其添加一个新的后端（在本例中是我们的Kubernetes服务），则需要更改配置文件，重新加载ha-proxy，直到此后一切都将按预期运行。当然，我们不想手动执行此操作。因此，您可以使用称为Confd的小型开源工具，该工具使用etcd数据管理本地应用程序配置文件。如果元数据存储etcd中发生更改，则Confd会自动生成一个配置模板，会根据新的工作条件重新配置ha-proxy。

看来这种方法需要付出更多的努力，但是，它是一种非常简单的工具，可以与模板一起使用，因此其使用是一项相当琐碎的任务。

26:00 min。

很快就会继续...

一点广告：）

感谢您与我们在一起。你喜欢我们的文章吗？想看更多有趣的资料吗？通过下订单或向您的朋友推荐给开发人员的基于云的VPS，最低价格为4.99美元，这是我们为您发明的入门级服务器 的独特类似物：关于VPS（KVM）E5-2697 v3（6核）的全部真相10GB DDR4 480GB SSD 1Gbps从$ 19还是如何划分服务器？（RAID1和RAID10提供选件，最多24个内核和最大40GB DDR4）。

阿姆斯特丹的Equinix Tier IV数据中心的戴尔R730xd便宜2倍吗？仅在荷兰有2台Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100电视！戴尔R420-2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB-$ 99起！阅读有关如何构建基础设施大厦的信息。使用Dell R730xd E5-2650 v4服务器花费一欧元9000欧元的c类？