本文已过时一年以上。较旧的文章可能包含过时的内容。请检查页面中的信息自发布以来是否已变得不正确。

Kubespray Ansible Playbooks 促进协同 Kubernetes 操作

为什么选择 Kubespray?

使 Kubernetes 在操作上强大是一个广泛认可的优先事项,我跟踪了围绕该项目的许多部署工作。 孵化的 Kubespray 项目对我来说特别有吸引力,因为它使用流行的 Ansible 工具集在云和物理目标上构建健壮、可升级的集群。我认为使用操作员熟悉的工具可以壮大我们的社区。

我们很高兴看到 Kubespray 支持的平台范围以及它如何处理各种选项,例如集成 Ceph 以实现 StatefulSet 持久性和 Helm 以便更容易地上传应用程序。这些添加使我们能够完全集成 OpenStack Helm charts演示视频)。

通过使用上游源代码而不是创建不同的安装脚本,我们可以获得更大社区的好处。这需要一些额外的开发工作;但是,我们相信帮助分享运营实践可以使整个社区更加强大。这也是 SIG-Cluster Ops 背后的动机。

借助 Kubespray 提供的强大安装,我们可以专注于更广泛的运营问题。

例如,我们现在可以驱动并行部署,因此可以同时为开发和测试充分利用 Kubespray 支持的选项。  

这有助于在自动化管道中,在 CentOS、Red Hat 和 Ubuntu 上构建、测试、销毁协调的 Kubernetes 安装。我们还可以使用 Digital Rebar 的提供商、租户和集群定义 JSON,通过单个命令设置完整的课堂环境。

让我们探讨一下课堂示例

首先,我们在 JSON 中定义一个 学生集群,如下面的代码段所示

| {

 "attribs": {

   "k8s-version": "v1.6.0",

   "k8s-kube_network_plugin": "calico",

   "k8s-docker_version": "1.12"

 },

 "name": "cluster01",

 "tenant": "cluster01",

 "public_keys": {

   "cluster01": "ssh-rsa AAAAB..... user@example.com"

 },

 "provider": {

   "name": "google-provider"

 },

 "nodes": [

   {

     "roles": ["etcd","k8s-addons", "k8s-master"],

     "count": 1

   },

   {

     "roles": ["k8s-worker"],

     "count": 3

   }

 ]

} |

然后,我们运行 Digital Rebar 工作负载 Multideploy.sh 参考脚本,该脚本会检查部署文件以提取关键信息。  基本上,它会自动执行以下步骤

| rebar provider create {“name”:“google-provider”, [秘密内容]}

rebar tenants create {“name”:“cluster01”}

rebar deployments create [cluster01 文件中的内容] |

部署创建命令将自动从提供商请求节点。由于我们正在使用租户和 SSH 密钥添加,因此每个学生只能访问自己的集群。完成后,添加 --destroy 标志将反转节点和部署的过程,但保留提供商和租户。

我们投入了像这种使用 Kubespray 和 Digital Rebar 的操作脚本,因为如果我们不能以一致的方式管理变化,那么我们注定要进行操作碎片化。  

我很高兴看到并成为社区在云端和本地实现企业级 Kubernetes 操作的进步的一部分。这意味着我看到合理的模式正在出现,并具有可共享/可重用的自动化。如果您正在部署 Kubernetes,即使是实验规模,我也强烈建议您关注(或更好地说,合作)这些工作。作为社区的一份子需要更多的前期工作,但您会获得共享经验和改进的好处,从而获得回报。

在规模化部署时,如何在不损害规模或安全性的情况下,建立一个既可重复又可多平台的系统?

以 Kubespray 和 Digital Rebar 为可重复的基础,扩展会变得更快、更容易。更好的是,直接使用上游允许将改进快速循环回上游。这意味着我们更接近于建立一个专注于 Kubernetes 操作方面的社区,并具有 SRE 思维

如果这很有趣,请在 Cluster Ops SIGKubespray 或 Digital Rebar 社区中与我们互动。