本文已过时一年以上。较旧的文章可能包含过时的内容。请检查页面中的信息自发布以来是否已变得不正确。
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 SIG、Kubespray 或 Digital Rebar 社区中与我们互动。
- 在 GitHub 上参与 Kubernetes 项目
- 在 Stack Overflow 上发布问题(或回答问题)
- 在 Slack 上与社区联系
- 在 Twitter 上关注我们 @Kubernetesio 以获取最新更新