试试将 Nutanix Karbon 作为 Azure Arc 兼容的 Kubernetes 进行连接

1 年 ago

新, 韵

3 minutes

请注意，本文所述内容基于截至当前日期的信息。因此，如果以后提供了新版本，可能会与所述信息发生矛盾，请留意。

首先

我是@hanakara_milk，最近几年来，我只在Advent Calendar期间在Qiita上发布文章。今天晚上我想分享的是关于Nutanix Karbon作为Azure Arc兼容的Kubernetes版本，并试着连接Azure Arc的文章。

原本是希望在Nutanix Community Edition（以下简称CE）上进行操作，但很遗憾，Nutanix Karbon最近才通过了Azure Arc认证，并作为支持Kubernetes的Certified产品。不过CE只有AOS 5.18版本的Karbon 2.0.x系列，由于时间原因，无法确保是否能够成功连接，因此我选择了商用版本的Nutanix进行验证。

Nutanix的配置如下所示。

Karbon：2.3.0

顺便提一下，微软文档中关于Azure Arc兼容的Kubernetes认证是指Karbon的2.2.1版本。

关于Azure Arc兼容的Kubernetes。

换一种方式来理解的话，就是说，可以像将Azure的特定定制用途区域之一的Kubernetes应用到本地一样，将在Azure Resource Manager（ARM）下管理的多种资源，包括本地环境在内，部署到任何地方。这是一种雄心勃勃的机制。

鑑於時間限制，本次我沒有完全測試的機會，但我將嘗試將部署在Nutanix Karbon上的Kubernetes集群連接到Azure Arc，並在Azure Portal上進行一些操作。

为连接到Azure Arc兼容的Kubernetes进行准备。

这篇文章的内容以将Linux作为操作终端（虚拟机）来使用为前提。

各種ツールのインストール（kubectl, Azure CLI, helm3）

需要操作终端设备或操作用虚拟机能够访问Karbon的Kubernetes集群。

需要将由Karbon部署的Kubernetes集群的kubeconfig作为环境变量注册到使用Azure CLI进行操作的终端等终端上，以便访问此终端。

连接到Azure Arc

使用Azure CLI添加connectedk8s扩展

添加用于将Kubernetes集群连接到Azure Arc的扩展命令集至Azure CLI。

az extension add --name connectedk8s

此操作需要假定已经安装了Azure CLI。

注册用于Azure Arc兼容Kubernetes的提供者。

在Azure CLI环境中，添加用于连接到Azure Arc所需的提供程序定义等内容。这可能需要一些时间来完成添加。

az provider register --namespace Microsoft.Kubernetes
az provider register --namespace Microsoft.KubernetesConfiguration
az provider register --namespace Microsoft.ExtendedLocation

创建适用于Azure Arc兼容Kubernetes的资源组。

在Azure Portal的用户界面上创建一个资源组，以便将Kubernetes集群与Azure Arc连接和管理（无需使用Azure CLI也可以执行）。如果使用现有的资源组，则无需进行此操作。

az group create --name {YOUR_RESOUCE_GROUP_NAME} --location {RG_ROCATION} --output table

引数：
{YOUR_RESOUCE_GROUP_NAME}代表要创建资源组的名称（例如：rg-karbon）
{RG_ROCATION}代表要部署资源组的位置（例如：japaneast）

az group create --name rg-karbon --location japaneast --output table

将Kubernetes集群连接到Azure Arc。

使用 Azure Portal 的用户界面将在 Karbon 中部署的 Kubernetes 集群连接到 Azure Arc（无需使用 Azure CLI）。在此操作中，需要指定的 “–name” 应为预先注册的 KUBECONFIG 中的 Kubernetes 集群名称。

az connectedk8s connect --name {KARBON_K8S_CLUSTER_NAME} --resource-group {YOUR_RESOUCE_GROUP_NAME}

参数：
{KARBON_K8S_CLUSTER_NAME}是使用Karbon部署的Kubernetes集群名称。
{YOUR_RESOUCE_GROUP_NAME}是之前创建的资源组名称。

az connectedk8s connect --name milk01 --resource-group rg-karbon

然而，在此阶段，通过Azure门户在Karbon中部署的Kubernetes集群只能看到，并且无法进行实际的工作负载操作等实际的管理操作，类似于有限制的只读状态。因此，现在需要通过Azure Arc将此已连接的Kubernetes集群转化为可以进行管理操作的状态。

激活Azure Arc上的Kubernetes管理功能。

启用集群连接功能

生成Service Account Bearer Token，并在Azure Portal中，使其具有可写权限以登录已在Karbon部署的Kubernetes集群（无需使用Azure CLI，可以通过Azure Portal的UI来执行）。首先是启用集群连接功能（cluster-connect）。

az connectedk8s enable-features --features cluster-connect -n {KARBON_K8S_CLUSTER_NAME} -g {YOUR_RESOUCE_GROUP_NAME}

az connectedk8s enable-features --features cluster-connect -n milk01 -g rg-karbon

集群连接功能（cluster-connect）的认证

接下来，我们将添加服务帐户并设置角色绑定，以便在Azure Arc中能够操作Kubernetes集群。
根据添加服务帐户和设置角色绑定的说明，这将是针对在Karbon上部署的Kubernetes集群的操作。在本示例中，我们将在已注册了milk01的KUBECONFIG文件，并且可以访问milk01集群的终端中进行操作。

kubectl create serviceaccount admin-user
kubectl create clusterrolebinding admin-user-binding --clusterrole cluster-admin --serviceaccount default:admin-user

完成添加服务账号并设置绑定角色后，获取服务账号的令牌。使用该令牌，在下一步中创建用于Azure Arc的Kubernetes管理操作的KUBECONFIG。

备忘录：
可以通过Azure AD集成来取代在服务账户上进行认证的工作。

SECRET_NAME=$(kubectl get serviceaccount admin-user -o jsonpath='{$.secrets[0].name}')
TOKEN=$(kubectl get secret ${SECRET_NAME} -o jsonpath='{$.data.token}' | base64 -d | sed $'s/$/\\\n/g')

使用先前创建的令牌，在Azure Arc中创建用于Kubernetes管理操作的KUBECONFIG。同时，暂时建立代理，以确认是否可以从Azure Portal的Azure Arc访问milk01集群。

az connectedk8s proxy -n $CLUSTER_NAME -g $RESOURCE_GROUP --token $TOKEN

az connectedk8s proxy -n milk01 -g rg-karbon --token $TOKEN

Setting up environment for first time use. This can take few minutes...
Proxy is listening on port 47011
Merged "milk01" as current context in /root/.kube/config
Start sending kubectl requests on 'milk01' context using kubeconfig at /root/.kube/config
Press Ctrl+C to close proxy.

使用Azure Arc管理在Karbon上部署的Kubernetes集群。

终于完成了Azure Arc管理操作的准备工作，立刻开始尝试操作。

在Azure门户上查看Kubernetes资源。

从左侧面板菜单中选择“Kubernetes集群资源（预览）”，以命名空间为筛选条件进行部署（deployment）的确认。

从 Azure 门户中添加 Kubernetes 资源

虽然没有必要特意放在代码中，但并不是没有意义的。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp-color
spec:
  selector:
    matchLabels:
      run: webapp-color
      #  strategy:
      #    rollingUpdate:
      #      maxSurge: 1
      #      maxUnavailable: 0
  replicas: 4
  template:
    metadata:
      labels:
        run: webapp-color
      annotations:
        kubernetes.io/change-cause: Initial release webapp-color version.1
    spec:
      containers:
      - name: webapp-color
        image: detteiu/karbon-training02:v1
        ports:
        - containerPort: 8080

从Azure门户中进行Kubernetes监控

下一步我们将在Azure门户中查看在Nutanix的Karbon上部署的本地Kubernetes集群的监控情况。可以通过配置Log Analytics和Azure Monitor for Container等来进行监控。

请注意：
在配置LogAnalytics或Azure Monitor时，将进行必要的数据获取以进行日志记录和监视，并根据数据量进行计费。

试用后的清洁工作

在使用云端服务时，如果不删除包括LogAnalytics和Azure Monitor配置以及使用的Workspace在内的资源组，会持续收取高额费用。如果为了Azure Arc兼容的Kubernetes创建了资源组，请务必彻底删除相关的Azure Arc相关资源组，还要记得删除在LogAnalytics和Azure Monitor中使用的Workspace和资源组。

总结

在2021年的Nutanix Advent Calendar上，我们尝试连接通过Nutanix Karbon在Azure Arc上部署的Kubernetes集群，这是内容的要点。

谷歌Anthos和Azure Arc一样，在连接时可能会稍微麻烦一些，但无论是在公有云上的Kubernetes还是在本地的Kubernetes，以及作为公有云提供的服务基础设施的一部分使用本地设备，并且希望将它们统一管理的情况下，它们可能是未来的选择之一。

然而，目前Kubernetes的运维通常是通过结合各种Kubernetes生态系统进行的，并通过它们的接口和仪表板进行管理。由于无法提供替代接口或生态系统的替代功能，以实现运维的统一化管理，要完全将Kubernetes的管理和运维一元化，似乎并不那么容易。

虽然只是简单地说可以从公共云管理任何支持混合云的Kubernetes，让本地基础设施成为公共云可用的基础设施之一的功能已经开始成为日本企业在应对云转型潮流时的常见系统要求。这项功能似乎已经成为有实际意义的讨论焦点之一。

当然，逆向模式指的是将公共云基础设施用作Nutanix的扩展资源，并可在本地使用的模式，如Nutanix在AWS或Azure上的”Nutanix Clusters”等模式。由于不需要太多的学习成本来进行Lift＆Shift，并且使用Prism进行本地操作时，可以简化操作流程，所以这也可以成为一种有效的方式。