透过 API 自动化布署 Karbon 服务平台

让我们开始今天的主题 – 如何使用新的 Karbon API 部署 Kubernetes。

Karbon 的快速介绍

Nutanix 官网上对 Karbon 的描述如下：

使用企业 Kubernetes 管理解决方案 Karbon 快速建立生产云原生基础架构的方式。
大大简化了配置，操作和生命週期管理。
– https://www.nutanix.com/products/karbon

作为开发人员，这对我们意味着什么？ Kubernetes 本身本身就是一个巨大的话题，因此，有关 Kubernetes 的详细信息不在本文的讨论範围之内。 也就是说，Kubernetes（或K8s）对于新玩家来说可能是一个相当艰鉅的前景。 这可以包括诸如理解为什么首先要存在 K8s，要求是什么以及如何启动和运行 K8s 集群之类的事情。 Karbon 大大简化了可能相当複杂的过程，尤其是如果该过程是手动完成的。

就像决定将 Kubernetes 称为 K8s 的开发人员一样，我会很懒惰，并假设您具有脚本或第三方集成，需要以编程方式部署K8s 集群。 明确地说，我们正在部署 K8s 集群，但是我们将使用 Nutanix Karbon 来实现。 更轻鬆！

Karbon APIs

Nutanix Karbon API 是一个在2020年7月提供，相对较新的版本。对 Nutanix APIs 感兴趣的人会在 API 参考页上留意到一个新资源 – 这使您可以快速访问 Karbon API 文档。今天文章涵盖的所有内容都可以在那里以正式形式获得，包括此文未提到的其他 API。

GA vs alpha/beta

遍历Karbon API公开的各种端点时，您会看到各种端点前缀：

/karbon / v1/karbon/v1-alpha.1/karbon/v1-beta.1

就像先前所暗示的，一些可用的端点是通用（GA）并以/ karbon / v1开头，而其他端点仍被视为 alpha 或 beta 并以/karbon/v1-beta.1或/ karbon / v1-alpha.1。 在生产环境中使用 alpha 或 beta API 端点之前，应採取适当的谨慎措施。

值得注意的是，我们今天将使用的主要 API 端点以/ karbon / v1 为前缀，并被视为 GA。 唯一的例外是，但我会在适当的时候提及它。

测试环境

与所有 API 测试和开发一样，我使用的是 Postman 集合来整理我的请求。 如果您是 Postman 的新手，请参考“这么多变量！ 我如何使用Postman测试Nutanix API”。 它涵盖了我如何使用 Postman 来完成我们今天要做的事情。

版本

Here are the software versions I’m using on my development cluster:

OS 5.17.1Prism Central 5.17.0.3Karbon 2.1.0Nutanix Karbon OS image ntnx-0.6

假设条件

Karbon确实有先决条件，所以这是我正在做的一些高级假设。 这些适用于在自己的环境中关注本文的任何人。

您的环境满足要求并启用了Karbon。 有关更多信息，请参阅 Nutanix Karbon 指南中的需求部分，因为本文不会介绍如何在您的环境中运行Karbon。Nutanix Karbon OS 映像 ntnx-0.6 已经下载并可供部署。 请参阅《下载图像：Nutanix Karbon 指南》以获取更多信息。

列出现有存在的 Clusters

在创建新集群之前，让我们快速看一下我们的环境中可能已经在运行哪些集群。

为此的请求URI如下（这是今天文章中的单个请求，可以通过beta端点进行访问）：

https://[prism_central_ip_address]:9440/karbon/v1-beta.1/k8s/clusters

通过将此 GET 请求发送到 Prism Central，JSON 响应将包含有关由 Karbon 管理的现有 K8s 集群（如果有）的详细信息。 在我的测试环境中运行时，此请求表明 Karbon 正在管理三个现有的 K8s 集群。 整个响应很长–请注意，以下屏幕截图仅显示响应中的第一个群集。

包含由Karbon管理的所有3个Kubernetes集群的JSON数组

如您在上面的屏幕快照中所见，我们现在具有有关可见集群的 etcd 配置，API 服务器的 IP 地址，主部署类型（单个主服务器）以及有关 worker 和 Kubernetes 版本的信息的详细信息。

建立API Requests

由于我们将使用 Karbon 和 Karbon API 部署 Kubernetes 集群，因此我们现在可以开始构建请求。 首先，这是我们将使用 Karbon 部署 K8s 集群的请求 URI：

https://[prism_central_ip_address]:9440/karbon/v1/k8s/clusters

这是一个 POST 请求，因此需要一个相应的 JSON 净荷，该净荷告诉 Karbon API 我们实际上想要做什么。 作为一个小问题，让我们看一下如果根本没有任何 JSON 负载的情况下向该 URI 提交请求会发生什么情况：

{    "code": 602,    "message": "body in body is required"}

如您所见，我们很礼貌地告诉我们，缺少 JSON 正文，这是我们进一步进行之前所必需的。 在此过程中，如果您意外忽略了有效负载中的必填参数或字段，则会看到类似的消息。 不太相关，但是在谈论 HTTP POST 请求时，我经常互换“有效载荷”和“正文”两个词。 在这些文章的上下文中，它们是同一回事。

独立的主要 Kubernetes Cluster

如果您已经接触过 Kubernetes，您会知道主节点配置可以是单主机或多主机。 这是一个过分的简化，但是单主机基本上与 Nutanix Karbon 中的“开发”部署相匹配。 单主机开发集群将由以下组件组成：

1x大师
2x工人
1个etcd

请参阅 Kubernetes 组件以获取有关各种 Kubernetes 组件的信息。

对于此初始部署，重要的是要注意此配置不被认为是高度可用的。 虚拟机中的任何一个组件都可能发生故障，从而导致群集不可用。

首先，让我们看一下可用于部署由 Nutanix Karbon 管理的单主 Kubernetes 集群的 JSON 有效负载。

{    "cni_config": {        "flannel_config": {},        "pod_ipv4_cidr": "172.20.0.0/16",        "service_ipv4_cidr": "172.19.0.0/16"    },    "etcd_config": {        "node_pools": [            {                "ahv_config": {                    "cpu": 1,                    "disk_mib": 122880,                    "memory_mib": 8192,                    "network_uuid": "{{subnet_uuid}}",                    "prism_element_cluster_uuid": "{{cluster_uuid}}"                },                "name": "dev_etcd_node_pool",                "node_os_version": "ntnx-0.6",                "num_instances": 1            }        ]    },    "masters_config": {        "node_pools": [            {                "ahv_config": {                    "cpu": 1,                    "disk_mib": 122880,                    "memory_mib": 8192,                    "network_uuid": "{{subnet_uuid}}",                    "prism_element_cluster_uuid": "{{cluster_uuid}}"                },                "name": "dev_master_node_pool",                "node_os_version": "ntnx-0.6",                "num_instances": 1            }        ],        "single_master_config": {}    },    "metadata": {        "api_version": "v1.0.0"    },    "storage_class_config": {        "default_storage_class": true,        "name": "default-storageclass",        "reclaim_policy": "Delete",        "volumes_config": {            "file_system": "ext4",            "password": "{{pe_password}}",            "prism_element_cluster_uuid": "{{cluster_uuid}}",            "storage_container": "{{container_name}}",            "username": "{{username}}"        }    },    "workers_config": {        "node_pools": [            {                "ahv_config": {                    "cpu": 1,                    "disk_mib": 122880,                    "memory_mib": 8192,                    "network_uuid": "{{subnet_uuid}}",                    "prism_element_cluster_uuid": "{{cluster_uuid}}"                },                "name": "dev_worker_node_pool",                "node_os_version": "ntnx-0.6",                "num_instances": 2            }        ]    },    "name": "{{cluster_name}}",    "version": "1.16.10-0"}

JSON有效负载中包含很多信息，因此让我们检查一下它的主要功能。

由{{cluster_name}}指示的群集名称
组件（如前所述）
1x大师
2x工人
1个etcd
主节点，工作节点和etcd节点均配置如下：
1个vCPU
122880 MiB存储
8GiB虚拟RAM
已连接到同一虚拟机网络，以{{subnet_uuid}}表示
部署到由{{cluster_uuid}}指示的同一Prism Element群集
Kubernetes版本1.16.10-0
Nutanix主机操作系统版本ntnx-0.6
CIDR範围
服务：172.19.0.0/16
吊舱：172.20.0.0/16
名为default-storageclass的存储类
ext4文件系统
回收策略设置为“删除”
{{container_name}}指示的存储容器
Karbon API版本1.0.0
值得注意的是，每个节点类型的配置详细信息（例如，master / worker / etcd节点的ahv_config）当然可以有所不同。我对所有设备都使用相同的配置，因此有效负载要简单一些。

使用 Karbon UI 进行 Kubernetes 集群部署的用户会注意到，每个参数都与您在 Karbon UI 中看到的1：1匹配。换句话说，在使用 Karbon UI 时选择的选项也都已在 JSON 有效负载中指定。

传送 Requests

将请求发送到 Prism Central 会返回类似于以下所示的 JSON 响应–请注意，此响应显示在 require 变量已替换为实际集群名称等之后的值：

{    "cluster_name": "single01",    "cluster_uuid": "30efbfd8-5544-4a58-53c4-2545658cc981",    "task_uuid": "21da123c-8911-41e8-acef-7653cbdc2aaa"}

根据JSON有效负载的集群名称清晰可见，我们的新集群的UUID以及为处理该流程而创建的任务的UUID也清晰可见。 就本文而言，我们可以忽略task_uuid和cluster_uuid-Karbon API可用于获取有关当前情况的信息。 我们将尽快完成。

多主 Kubernetes Cluster

多主 Kubernetes 集群的 JSON 有效负载略有不同。 除了在单个主有效负载中指定的信息之外，我们还可以指定一些其他属性。 在生产环境中，您更可能会使用与此类似的东西，并调整各种参数以提供高度可用的配置。

主节点群集的外部 IPv4 地址（如果正在使用主动/被动配置）（此有效负载将对此进行演示）。
主节点实例数。 在单主机配置中将其设置为1，但在此处将其设置为2。
请注意，single_master_config 对像已从有效负载中删除-不适用于多主设备配置。
完整的 JSON 有效负载如下所示：

{    "cni_config": {        "flannel_config": {},        "pod_ipv4_cidr": "172.20.0.0/16",        "service_ipv4_cidr": "172.19.0.0/16"    },    "etcd_config": {        "node_pools": [            {                "ahv_config": {                    "cpu": 1,                    "disk_mib": 122880,                    "memory_mib": 8192,                    "network_uuid": "{{subnet_uuid}}",                    "prism_element_cluster_uuid": "{{cluster_uuid}}"                },                "name": "dev_etcd_node_pool",                "node_os_version": "ntnx-0.6",                "num_instances": 1            }        ]    },    "masters_config": {        "active_passive_config": {            "external_ipv4_address": "10.42.250.49"        },        "node_pools": [            {                "ahv_config": {                    "cpu": 1,                    "disk_mib": 122880,                    "memory_mib": 8192,                    "network_uuid": "{{subnet_uuid}}",                    "prism_element_cluster_uuid": "{{cluster_uuid}}"                },                "name": "dev_master_node_pool",                "node_os_version": "ntnx-0.6",                "num_instances": 1            }        ]    },    "metadata": {        "api_version": "v1.0.0"    },    "storage_class_config": {        "default_storage_class": true,        "name": "default-storageclass",        "reclaim_policy": "Delete",        "volumes_config": {            "file_system": "ext4",            "password": "{{pe_password}}",            "prism_element_cluster_uuid": "{{cluster_uuid}}",            "storage_container": "{{container_name}}",            "username": "{{username}}"        }    },    "workers_config": {        "node_pools": [            {                "ahv_config": {                    "cpu": 1,                    "disk_mib": 122880,                    "memory_mib": 8192,                    "network_uuid": "{{subnet_uuid}}",                    "prism_element_cluster_uuid": "{{cluster_uuid}}"                },                "name": "dev_worker_node_pool",                "node_os_version": "ntnx-0.6",                "num_instances": 2            }        ]    },    "name": "multi01",    "version": "1.16.10-0"}

传送 Requests

因为我们使用的是创建单主机集群时使用的相同 API 端点，所以响应的格式与上一个请求的响应格式相同：cluster_uuid，task_uuid和cluster_name。

取得 Clusters 资讯

在我们的一个或多个集群现在正在运行或仍在部署的情况下，能够查询它们将有所帮助。
Karbon API 还公开了一个端点，用于获取有关特定集群的信息。 这是一个 GET 请求，必须使用以下 URI：

https://[prism_central_ip_address]:9440/karbon/v1/k8s/clusters/[k8s_cluster_name]

在这一部分中，我们将使用多主群集的名称– multi01。 将上面的 [k8s_cluster_name] 替换为我们的集群名称将返回类似于以下所示的响应：

{    "etcd_config": {        "node_pools": []    },    "kubeapi_server_ipv4_address": "10.42.250.49",    "master_config": {        "deployment_type": "multi-master-active-passive",        "node_pools": []    },    "name": "multi01",    "status": "kDeploying",    "uuid": "90ac2d10-a83c-42d0-69d4-c0382531b247",    "version": "v1.16.10",    "worker_config": {        "node_pools": []    }}

这里显示了很多有用的信息：

我们的有效负载中指定的 Kubernetes API 服务器 IP 地址，即 10.42.250.49
部署类型，即多主-主动-被动
对于本部分，最重要的是状态为 kDeploying-该集群当前正在部署中，尚未準备好使用
部署完成后，两个都将在 Karbon UI 中显示为“健康”，就像使用 UI 本身创建它们一样。 在下面，我们可以看到本文中的两个演示集群都已部署并且运行良好，还有一个同事拥有的另一个集群。

已部署单主群集和多主群集，并且运行状况良好

下载 Kubeconfig

使用Karbon API 创建的 K8s 群集与使用 Karbon UI 创建的 K8s 群集完全没有区别。 因此，我们仍然可以下载由 Karbon 生成的“ kubeconfig”文件。 该文件用于对已部署的 K8s 集群运行 kubectl 命令。 请参阅《Nutanix Karbon指南》中的“下载Kubeconfig”以获取官方文档。

不过，对于我们今天所做的事情，还可以使用 Karbon API 下载 kubeconfig 文件。 GET 请求 URI 如下：

https://[prism_central_ip_address]:9440/karbon/v1/k8s/clusters/[cluster_name]/kubeconfig

将此请求发送到 Prism Central 并用有效的集群名称替换 [cluster_name] 将返回包含 kubeconfig 的 JSON 响应。 下面显示了一个示例–删除了证书颁发机构数据和令牌，使该示例更易于阅读：

{    "kube_config": "# -*- mode: yaml; -*-\n# vim: syntax=yaml\n#\napiVersion: v1\nkind: Config\nclusters:\n- name: single01\n  cluster:\n    server: https://10.42.250.85:443\n    certificate-authority-data: CERT_AUTHORITY_DATA_HERE\nusers:\n- name: default-user-single01\n  user:\n    token: TOKEN_HERE\ncontexts:\n- context:\n    cluster: single01\n    user: default-user-single01\n  name: single01-context\ncurrent-context: single01-context\n\n"}

本文详细介绍了 JSON 有效负载和 Karbon API 端点，这些端点可用于以编程方式部署 K8s 集群，并获取有关已经由 Karbon 管理的集群的信息。 儘管就 API 概念而言，这不是一个困难的过程，但有效载荷本身可能首先需要花费时间才能弄清楚。

希望以上示例演示了如何将 Karbon API 和 K8s 部署自动化集成到您自己的工作流程中。

感谢您的阅读，祝您有美好的一天！