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

Kubespray Ansible Playbook 促进协作式 Kubernetes 运维

作者：Rob Hirschfeld (RackN) |

为什么选择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”, [secret stuff]}

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

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

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

我们投入到像这个使用Kubespray和Digital Rebar的示例这样的操作脚本中，因为如果我们不能以一致的方式管理变体，那么我们将注定陷入操作碎片化。

我很高兴看到并参与社区在云和本地环境中实现企业级Kubernetes运营的进展。这意味着我看到了可共享/可重用自动化与合理模式的出现。如果您正在部署Kubernetes，即使是实验规模，我也强烈建议您关注（或更好地，参与协作）这些工作。成为社区的一部分需要更多前期投入，但随着您获得共享经验和改进的好处，回报会非常丰厚。

大规模部署时，您如何设置一个既可重复又多平台的系统，而又不影响规模或安全性？

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

如果这让您感兴趣，请与我们联系，加入Cluster Ops SIG、Kubespray或Digital Rebar社区。