Kubernetes 中的自动化配置

了解自动化 Broker 如何帮助简化 Kubernetes 应用程序和服务的管理。
380 位读者喜欢这篇文章。
Automated provisioning in Kubernetes

Opensource.com

在 Kubernetes 集群中部署应用程序时,通常需要某些类型的服务。许多应用程序需要数据库、存储服务、消息队列、身份管理等等。容器化您自己的应用程序已经够您忙的了。如果这些其他服务在集群内部随时可用,岂不是很方便?

服务目录

不要再自己部署和管理这些其他服务了;让服务目录为您效劳。Kubernetes 服务目录 README 中声明

“service-catalog 项目的最终目标是为 Kubernetes 用户提供一种从 Broker 消费服务的方式,并轻松配置他们的应用程序以使用这些服务,而无需详细了解这些服务是如何创建或管理的。”

任何人都可以通过实现 Open Service Broker API 来创建一个向服务目录发布一个或多个服务的 Broker。但今天我们关注的是 自动化 Broker,它可以让您轻松地从服务目录部署您的应用程序或服务。

服务包

在基本层面上,您只需要为自动化 Broker 提供一个经过特殊设计的容器,该容器知道如何配置和解除配置您的服务。我们称这个容器为服务包。在这个容器内部,您可以采用任何必要的方式来配置您的服务,但到目前为止,大多数示例都使用了 Ansible

如果您曾经直接从 YAML 创建过 Kubernetes 资源,那么编写 Ansible 角色来在集群中创建资源会感觉非常熟悉。使用像 Ansible 这样的通用自动化工具意味着您可以自由地与集群内部和外部的资源集成。例如,您的服务包可以在集群内部署一个 Web 应用程序,该应用程序使用集群外部的数据库。

最后,每个服务包都有一组最终用户将看到的标准属性,包括名称、描述以及用户在配置时可以指定的参数。这些元数据,与您使用 Ansible 或其他方式实现的逻辑相结合,构成了一个完整的应用程序定义。

有关创建 Ansible Playbook Bundle (APB) 的更多信息,包括查看使其变得容易的工具和基础镜像,请参阅 入门指南

整合在一起

Kubernetes 集群的最终用户可以查看服务目录,以了解有哪些服务可用。自动化 Broker 可能是目录中发布服务的多个 Broker 之一。当用户选择您的服务包时,他们有机会提供该包接受的任何参数。

用户体验因平台而异。在纯 Kubernetes 上,您可以使用 svcat 命令行工具。在 OpenShift 上,Web 控制台 提供了图形化体验。

在用户输入完成后,服务目录会告诉自动化 Broker 配置所选服务。Broker 在集群内设置一个安全命名空间,并将您的服务包作为正在运行的容器在其中启动。此时,就取决于您的服务包来完成任何需要完成的任务。例如,Postgresql 包 创建了三个 Kubernetes 资源:DeploymentConfig、Service 和 PersistentVolumeClaim。更高级的服务包可以部署一整套相关服务并将它们联系在一起。

服务配置完成后,您可以创建绑定,这是一种用于将其他应用程序连接到您的服务的标准化构造。请期待未来关于应用程序如何消费已配置服务的博客文章。

准备好看看它的实际效果了吗?“OpenShift Ansible Broker 启动和运行” 是一份简单、循序渐进的指南,用于启动 OpenShift 集群并与自动化 Broker 交互。(细心的读者会注意到,Openshift 的文档将自动化 Broker 称为“Openshift Ansible Broker”,这只是他们对自动化 Broker 的称呼。)

试一试,让我们知道您的想法。

Michael Hrivnak 将于今年 3 月 8 日至 11 日在加利福尼亚州帕萨迪纳举行的 SCaLE16x 大会上发表演讲。要参加并获得 50% 的门票折扣,请使用促销代码 OSDC 注册


想要掌握微服务吗? 了解如何 在自定进度的动手实验环境中运行 OpenShift 容器平台。

标签
User profile image.
Michael Hrivnak 是 Red Hat 的首席软件工程师。在领导容器镜像的早期注册和分发技术开发之后,他开始参与解决 Kubernetes 上的实际业务流程问题。

评论已关闭。

Creative Commons License本作品根据 Creative Commons Attribution-Share Alike 4.0 International License 获得许可。
© . All rights reserved.