Azure-Arc-支持的面向多云的-Kubernetes-指南-全-

news/2025/11/9 18:02:18/文章来源:https://www.cnblogs.com/apachecn/p/19204585

Azure Arc 支持的面向多云的 Kubernetes 指南（全）

原文：zh.annas-archive.org/md5/d59529b1ef4e2848b60fd4981536534c

译者：飞龙

协议：CC BY-NC-SA 4.0

前言

在科技和云计算领域，包括多云、容器、Kubernetes 和 DevOps 等多种技术正在高速发展。随着需要采用容器和 Kubernetes 来运行工作负载，以及在本地和多云环境中运行这些工作负载的能力，我们看到新的工具和技术模式的出现，旨在为技术团队提供便利。Azure Arc 启用的 Kubernetes 就是这些工具之一，而 GitOps 则是这些技术模式之一。类似云、容器和 Kubernetes 的增长，我们也将看到 Azure Arc 和 GitOps 的指数级增长。这只是时间问题。

在这份报告中，您将了解到驱动 Azure Arc 和 GitOps 创建的背景需求。您将了解 Azure Arc 的定义、如何使用以及如何使用它。您还将学习 GitOps 的含义及其在 Azure Arc 启用的 Kubernetes 提供中的作用。对于初次接触 Azure Arc 启用的 Kubernetes 和 GitOps 的旅程，这份报告将是一个很好的起点。

致谢

首先，感谢上帝继续祝福我，并给我机会参与这样的活动。感谢我的妻子 Aya 和我的儿子们对我有耐心，并为我追求这样的机会提供时间。

我还要感谢 O'Reilly 的团队，Michele Cronin 和 Jennifer Pollock，他们与我合作非常愉快。

感谢 Chris Sanders 和 Microsoft Arc 团队构建这一令人兴奋的技术。

特别感谢 Michael Levan 在本出版物的技术审查中提供的支持，确保我所创建的内容在技术上是完备的。

我要向 MVP 和广大技术社区致敬，感谢他们分享对技术的热情。能够成为如此庞大的技术社区的一部分，是我的荣幸。

第一章：Azure Arc 跨多云的一致性

在本章中，您将踏上一段多云之旅，并了解整个 Azure Arc 服务所提供的概述。

什么是 Azure Arc？

在当今的科技世界中，许多大大小小的组织都已经接受了云计算。组织通常选择混合和多云策略，他们经常有一些工作负载在本地运行，而其他工作负载则在多个云提供商之间运行。

组织采用混合和多云策略有很多原因：它帮助他们实现本地投资的好处，避免供应商锁定，并最小化来自单个云提供商的停机风险，同时使他们能够利用他们选择的任何云提供商的技术创新。

随之而来的是新的部署和管理挑战。其中一个首要挑战是处理每个云提供商之间的差异以及用于管理和治理的本地工具的差异。这可能会导致运行成本高昂且难以跟上。

另一个挑战是技能水平——让您的 IT 团队掌握单个云平台已经具有挑战性，但掌握两个或三个不同的云平台则更加困难。能够在单个工具集或云上进行培训降低了团队管理多云的门槛。有解决这一挑战的解决方案，Azure Arc 就是其中之一。

Azure Arc 是一种基于软件的云解决方案，直接响应本地和多云管理需求。微软在 2019 年的年度 Ignite 大会上宣布了 Azure Arc，这引起了人们的兴奋和关注，因为它改变了云计算的世界。

Azure Arc 通过将其扩展到多云，扩展了微软混合云产品。Azure Arc 旨在通过将 Azure 平面及其管理工具带到本地、边缘和多云环境中，简化复杂和分布式环境。Azure Arc 使 IT 团队能够部署工作负载和管理资源，无论它们存在于何处。

Azure Arc 将 Azure 资源管理（ARM）平台和 Azure 本地管理服务扩展到资源，无论这些资源是否存在于 Azure 中。这意味着资源可以从 Azure 中的任何环境中进行管理，无论它们是：

本地
非 Azure 云（例如，AWS，GCP 等）
微软混合云（例如，Azure Stack Hub，Azure Stack HCI，Azure Stack Edge）

图 1-1 展示了 Azure 控制平面、Azure 资源管理器和 Azure Arc 与 Azure Arc 管理下的外部资源之间的关系。

您还可以使用 Azure Arc 将工作负载部署到任何环境。例如，您可以将容器化工作负载部署到运行在 Azure 或非 Azure 环境中的 Kubernetes 集群，或者将 SQL 或 PostgreSQL 数据库部署到非 Azure 基础环境。通过 Azure Arc，您实质上是将资源从其他环境投影到 ARM 中。一旦将资源投影到 Azure Arc 中，您可以开始使用 Azure 原生工具进行治理、管理和部署。

图 1-1. Azure 通过 Azure Arc 连接外部资源的图示

此时此刻，Azure Arc 能够管理以下托管在 Azure 外部的资源类型：

服务器

支持 Linux 和 Windows，裸金属服务器，本地服务器，AWS EC2 虚拟机，GCP 计算引擎虚拟机，VMWare 虚拟机和 Hyper-V 虚拟机。

Kubernetes

支持本地 Kubernetes 集群，Rancher K3s，AWS EKS 集群和 GCP GKE 集群。

数据服务

支持 SQL 数据库和 PostgreSQL。

一些可以扩展的 Azure 服务包括：

基于角色的访问控制（RBAC）
订阅
管理组
资源组
标记
安全中心
Azure Defender
Azure Sentinel
Azure 策略
Azure 策略客户端配置
更新管理
变更跟踪
库存
Azure 自动化
Azure 监视器
GitOps

除了那些 Azure 服务之外，通过将非 Azure 资源纳入 Azure Arc 管理，您还可以启用以下 Azure 功能、服务和工具：

在 Azure 门户中查看和访问
Azure SDK
ARM 模板
Azure CLI
Azure PowerShell 模块
Azure Terraform 提供程序

让我们花点时间来解读此时此刻的 Azure Arc 定价。Azure Arc 启用的 Kubernetes 和 Azure Arc 启用的数据服务目前处于预览阶段，并且不需要额外费用。

Azure Arc 启用的服务器目前免费管理 Azure Arc 投影服务器。Azure VM 使用许多本地 Azure 管理服务，例如库存、变更跟踪、更新管理、Azure 策略和 Azure Arc 控制平面功能。请注意，对于每个额外的 Azure 管理服务（例如 Azure 监视器、Azure 策略客户端配置、安全中心、Azure Defender、Azure Sentinel 和 Azure 自动化），都会收取费用。您可以查看 Azure Arc 定价页面获取最新的定价更新。

Azure Arc 控制平面功能免费提供。被视为 Azure Arc 控制平面的服务包括：

通过 Azure 管理组和标记进行资源组织
通过资源图进行搜索和索引
通过 Azure RBAC 和 Azure 订阅进行访问和安全管理
环境和自动化通过 ARM 模板和 Azure 扩展

已经在使用 Azure Arc 的一些公司包括西门子、毕马威、Avanade 和 Ferguson。

Azure Arc 实现了“单一管理视图”的承诺。

长期以来，信息技术专业人员一直梦寐以求的“单一管理视图”：一个单一的仪表板或集中的位置，可用于管理资源和工作负载。许多产品承诺提供这种单一管理视图，但未能兑现承诺。

显然，市场正在需求多云；根据 Flexera's 2020 State Of The Cloud Report，93% 的企业采用了多云战略。多云推动了对单一管理视图的需求进一步增加，因为多云架构更为复杂和具有挑战性。有必要拥有工具，能够在多个云之间强化治理和安全管理资源和工作负载。微软已经响应了这一需求，与市场上的竞争对手以及 Azure Arc 的同类产品相比，它因其独特的设计和方法脱颖而出，允许您将工作负载留在希望的位置，并将 Azure 工具扩展到这些工作负载上。

当然，还有其他可用的技术。例如，Google 提供了 Anthos，这是一个托管的应用平台，将 GCP 服务扩展到任何环境。使用 Anthos，方法是将工作负载迁移到运行在 Google Kubernetes Engine（GKE）上的容器中。相比之下，Azure Arc 的方法是提供灵活性，允许用户选择将资源保留在本地、其他云中，或者在 Azure 中运行。与 Anthos 相比，Azure Arc 允许客户在虚拟机或容器上运行；Arc 将控制平面扩展到两者，并作为这些资源的总体管理层。Arc 可用于协助涵盖虚拟机、数据库实例和 Kubernetes 集群的资源生命周期，而其竞争对手则专注于容器。

通过 Arc，客户可以将应用程序部署到虚拟机或 Kubernetes 集群，无论它们位于何处，都可以投影到 Azure Arc 中，为 Azure 内的信息技术专业人员提供真正的单一管理视图的圣杯。

这使我们结束了对 Azure Arc 的概述。在本报告中，我们不会深入探讨 Azure Arc 启用的服务器或数据服务，因为重点是 Azure Arc 启用的 Kubernetes。接下来的章节将进一步探讨 Azure Arc 启用的 Kubernetes。

第二章：扩展 Azure 控制平面用于 Kubernetes

在本章中，我们将扩展讨论 Azure Arc，专注于如何在多个云环境中使用它来管理 Kubernetes。

什么是 Azure Kubernetes 服务？

容器和 Kubernetes 在技术上的爆炸已经不是秘密。随着公司内容器的增长继续增加，公司需要管理的容器数量也在增加。

许多公司到达一定阶段需要一种有效管理和编排容器的方式。Google 将 Kubernetes 作为容器的开源编排系统发布，公司以惊人的速度采纳，它已成为容器编排的首选。随着 Kubernetes 在企业中的普及，各大云提供商在其云平台上创建了托管的 Kubernetes 服务。Microsoft 在 Azure 云平台上创建了 Azure Kubernetes 服务（AKS）。

在我们讨论 Azure Arc 可启用的 Kubernetes 之前，谈论 AKS 和它的重要性是很重要的。当 Kubernetes 集群投影到 Azure Arc 中时，它们与 AKS 有一些类似的功能，例如监视、Azure 策略等。这意味着从 Kubernetes 获取信息和管理变得更加简单。

AKS 是 Microsoft 在 Azure 云平台上推出的托管 Kubernetes 服务，于 2018 年发布。它减少了管理自己的 Kubernetes 集群实例的管理开销。使用 AKS，您只需管理代理节点，Microsoft 为您管理控制平面。您可以与许多原生 Azure 服务集成，例如：

Azure 网络
Azure Active Directory 用于 RBAC
Azure 策略
Azure 监视器用于 Kubernetes 和容器监视
Azure 容器注册表
Azure 安全中心
Azure Defender
Azure 存储
Azure 容器实例

使用 AKS，Microsoft 已经并且持续以超快速度交付创新。Microsoft 添加到 AKS 中的一些功能，使 Kubernetes 的体验更加简单和增强，包括 Kubernetes 资源，可以在 Azure 门户中查看/管理 Kubernetes API 对象（例如 pods、services、namespaces 等），用于开发人员在 Kubernetes 集群上更轻松地与 Visual Studio 和 VS Code 进行客户端集成的 Dev Spaces，以及使用托管身份验证标识实现更安全、更无缝的服务账户方法。

Azure Arc 可启用的 Kubernetes

正如我们之前讨论过的，许多组织已经转向多云环境。我们还讨论了如何跨多个环境和云管理资源和工作负载是一个挑战。Kubernetes 经常被称为一种可以帮助公司避免供应商锁定并提供在云之间移动灵活性的技术。

尽管运行在 Kubernetes 上的容器工作负载是可移植的，从而更容易在本地或云端运行，但对于组织及其 IT 团队来说，跨多个云环境管理特定配置和工作负载仍然是一项艰巨的挑战。

通过 Azure Arc 启用的 Kubernetes，Microsoft 旨在简化管理多个 Kubernetes 集群的挑战——无论它们在何处运行——并简化流程。Azure Arc 不仅可以混合匹配云和虚拟机，还允许您混合匹配 Kubernetes 集群。截至撰写本文时，Azure Arc 启用的 Kubernetes 处于公共预览阶段，仅支持东部美国和西欧地区。发布一般可用时将支持更多地区。

简言之，Azure Arc 启用的 Kubernetes 允许客户将运行在本地或其他云提供商上的 Kubernetes 集群与 Azure 连接，实现在 Azure 云平台内的统一管理体验。它支持大多数开箱即用的 Cloud Native Computing Foundation (CNCF) 认证 Kubernetes 发行版。图 2-1 展示了可以使用 Azure Arc 启用的 Kubernetes 管理的各种托管 Kubernetes 云服务提供。

图 2-1. 使用 Azure Arc 启用的 Kubernetes 管理的多云 Kubernetes 集群

通过 Azure Arc 启用的 Kubernetes，我们可以实现以下功能：

利用 Azure Active Directory RBAC 访问 Kubernetes 集群。
对在 Azure 或非 Azure 环境和云中运行的 Kubernetes 集群进行清单编制、分组和标记。
利用 Azure Monitor 监控 Kubernetes 集群和容器。
利用 Azure Policies 通过应用 Azure Policies 对 Kubernetes 集群进行治理。
使用 Kubernetes 清单或 Helm Charts 部署应用程序，并通过 GitOps 进行配置。

图 2-2 展示了 Azure Arc 启用的 Kubernetes 和 GitOps 架构的示例，包括如何在 Azure Arc 中映射 Kubernetes 集群。

图 2-2. Azure Arc 扩展集群管理图示

第三章：GitOps：Git 作为事实的来源

在本章中，我们将专注于 GitOps，这是 Azure Arc 可用 Kubernetes 的重要组成部分。GitOps 可能是一个新概念，因此我们将花时间定义和解析它是什么，它是如何工作的，以及您如何在 Azure Arc 可用 Kubernetes 中使用它。

什么是 GitOps？

GitOps 是 Weaveworks 在 2017 年 8 月的一篇博客文章中首次提出的术语。它是云原生应用程序的操作模型模式，将应用程序和声明性基础设施代码存储在 Git 中作为事实的来源。它用于自动化持续交付。Weaveworks 在其 Kubernetes 环境中使用了 GitOps 操作模型模式。

在 Git 中，存在描述系统状态的代码，包括应用程序、配置、仪表板、监控等。在 GitOps 中，还有一种软件（运算符），它确保云原生生活环境的状态与 Git 中描述的所需状态相匹配。在撰写本文时，大多数运算符（如 Flux 和 ArgoCD）都设计用于与 Kubernetes 配合使用；但 GitOps 并不限于 Kubernetes。例如，有一个名为 Kubestack 的Terraform GitOps 框架。您计划使用 Flux 或 ArgoCD 运算符的 Git 存储库可以包含 YAML 格式的 Kubernetes 清单。这些清单应描述有效的 Kubernetes 对象，如命名空间、ConfigMaps、Secrets、Deployments、Pods、Services、Ingress、DaemonSets 等等。Git 存储库还可以包含应用程序的 Helm Charts。

GitOps 的原则包括：

声明性配置

系统状态以声明方式描述。

版本控制的、不可变的存储

Git 是事实的来源；所需的系统状态在 Git 中进行版本控制。

自动化交付

Git 是由自主代理执行的操作（创建，更改，删除）的单一位置。

自主代理

软件运算符强制执行所需状态并警示漂移。

闭环

自动化交付已批准的系统状态更改。

深入了解 GitOps，建议从 “GitOps：通过拉取请求进行操作” 博客文章开始。

Azure Arc 如何利用 GitOps

Azure Arc 使用 GitOps 来覆盖两个方面：首先是 Kubernetes 的配置，其次是应用程序的部署到 Kubernetes。配置可以包括诸如命名空间、ConfigMaps、Secrets、Ingress Controllers、Ingress 等对象。应用程序可以是诸如部署、Pods、服务和 Helm Charts 等内容。

Azure Arc 利用 Flux，一个开源的 GitOps 运算符。Flux 由 Weaveworks 构建，并且是 CNCF Sandbox 项目的一部分。

在 Azure Arc 启用的 Kubernetes 中，GitOps 是通过运行在 Kubernetes 集群上的 Flux 操作员（作为 Pod）来连接 Kubernetes 集群和 Git 仓库的一种方式。此 Flux 操作员用于同步 Kubernetes 集群配置和 Git 仓库中的期望状态配置，目标是通过 create、change 和 delete 操作使两者保持一致。

这种同步是通过 Flux 操作员的拉取方式实现的，Flux 将持续轮询 Git 仓库，查找任何新内容，并在 Kubernetes 集群中进行创建或更新。Flux 操作员还具有持续轮询容器注册表或 Helm 仓库的能力，以获取 Kubernetes 集群中所需的添加或更改。

Azure Arc 启用的 Kubernetes 集群和 Git 仓库连接存储在 ARM 中作为名为 Microsoft.KubernetesConfiguration/sourceControlConfigurations 的扩展资源。此内容存储在 Azure Cosmos DB 数据库中，静态加密。我们可以通过 Azure 门户或 Azure CLI 配置此设置。sourceControlConfiguration 属性包括：

配置名称
操作员实例名称
操作员命名空间
仓库 URL
操作员范围（命名空间/集群）
操作员类型
操作员参数
Helm（启用/禁用）

对于每个 Azure Arc 启用的 Kubernetes 集群，您可以拥有多个 sourceControlConfigurations，这些配置可以针对命名空间进行范围设置。这有助于处理多环境和多租户场景。

Azure Arc 启用的 Kubernetes 还可以使用 GitOps 管理大量 Kubernetes 集群的配置。通过使用 Azure 策略，在 Kubernetes 集群加入 Azure Arc 后立即应用所需的 sourceControlConfigurations 来实现这一目标。如果您希望跨多个 Kubernetes 集群应用相同的配置（如服务网格、监控代理、入口控制器等），则可以使用此功能。

第四章：使用 Azure Arc 启用的 Kubernetes

在这最后一章中，让我们开始探讨与 Azure Arc 启用的 Kubernetes 相关的架构及如何启动、监控和使用 RBAC 在 Azure Arc 预期 Kubernetes 集群中。我们还将深入了解如何使用 GitOps 将应用程序部署到 Azure Arc 预期 Kubernetes 集群。

Azure Arc 启用的 Kubernetes 架构和代理

Azure Arc 启用的 Kubernetes 本质上是在 Azure 中运行的 PaaS。服务本身的架构被抽象化了。 Azure Arc 启用的 Kubernetes 架构通常包括一些 Azure 服务、资源、工具和代理，以及在预期 Kubernetes 集群上运行的一些部署和 Pod。让我们详细解析一下架构和代理的内容。

首先，您需要在 Azure 或 Azure 之外运行的 Kubernetes 集群。这可以是 AKS；GKE；EKS；在 Azure、AWS、GCP、本地或边缘设备上运行的 VM 中的 Kubernetes；Rancher K3s；甚至是在边缘设备上运行的 Kubernetes。这将成为您在启用 Azure Arc 的 Kubernetes 中的预期 Kubernetes 集群。

您需要kubeconfig文件以访问集群，并在预期 Kubernetes 集群上具有 cluster-admin 角色。这将为部署 Arc 代理所需的访问权限。

您需要 Azure 命令行界面（Azure CLI）版本 2.3 或更高版本。这是安装 Azure Arc 启用的 Kubernetes 接口扩展和执行预期 Kubernetes 集群的注册任务所需的。

您需要在 Azure 中创建一个服务主体名称（SPN）。这个 SPN 必须具有对Microsoft.Kubernetes/connectedClusters资源类型的读写权限。此 SPN 还将与az login和az connectedk8s connect命令一起使用。

您需要在运行 Azure Arc 启用的 Kubernetes 的 Azure 订阅中启用以下 Azure Arc 提供程序：

Microsoft.Kubernetes
Microsoft.KubernetesConfiguration

您需要加载connectedk8s扩展和 Arc 启用的 Kubernetes CLI 扩展。此外，您需要 Helm 3，因为在使用az connectedk8s扩展将预期 Kubernetes 集群连接到 Arc 时会用到它。

您将在预期 Kubernetes 集群上运行 Azure Arc 启用的 Kubernetes 代理。为了使代理工作，以下网络协议/端口和出站 URL 需要在预期 Kubernetes 集群网络上允许：

协议/端口

TCP on port 443
TCP on port 9418

允许从预期 Kubernetes 集群出站的终点（DNS）

management.azure.com
eastus.dp.kubernetesconfiguration.azure.com
westeurope.dp.kubernetesconfiguration.azure.com
login.microsoftonline.com
mcr.microsoft.com
eus.his.arc.azure.com
weu.his.arc.azure.com

一旦代理加载并且预计的集群已经加入到 Arc 中，将在预计的 Kubernetes 集群上运行一个命名空间azure-arc。

在azure-arc命名空间中，还将作为 Deployments（即deployment.apps）运行在预计的 Kubernetes 集群上的运算符。它们是：

config-agent

当在预计的集群上应用sourceControlConfiguration资源时，监视预计的 Kubernetes 集群以更新合规状态。

controller-manager

协调 Azure Arc 组件之间的交互。它是一个用于操作其他运算符的运算符。

metrics-agent

收集其他 Arc 代理的指标以衡量性能并确保其优化。

cluster-metadata-operator

收集集群和 Azure Arc 代理的版本、集群元数据和节点计数。

resource-sync-agent

将集群-metadata-operator 收集的元数据与 Azure Arc 同步。

clusteridentityoperator

持有一个被其他运算符用来与 Azure 通信的托管服务身份（MSI）证书。

flux-logs-agent

作为sourceControlConfiguration的一部分，flux 运算符被部署到预计的 Kubernetes 集群(s)，并且该代理从它们那里收集日志。

在 azure-arc 命名空间中，将有一些运行在预计的 Kubernetes 集群上的 Pods：

cluster-metadata-operator-b88f6695d-rf998
clusteridentityoperator-6459fd778c-4wx66
config-agent-6cc967f5-kd8b8
controller-manager-557d758b9f-f69vw
flux-logs-agent-5db8bff9d4-gktl4
metrics-agent-997cf95d5-h96gd
resource-sync-agent-587b999567-4kz64

这总结了 Azure Arc 启用的 Kubernetes 涉及的组件，包括 Azure 服务、资源、工具、代理和涉及架构中的一些部署和 Pods。接下来，我们将探讨如何设置和使用 Azure Arc 启用的 Kubernetes。

创建一个服务主体名称

正如前面提到的，您将需要在 Azure 订阅中创建一个服务主体名称。此 SPN 将需要在订阅中的Microsoft.Kubernetes/connectedClusters资源类型上具有读写权限。

您还将使用此 SPN 执行az login命令以及az connectedk8s connect命令。您可以通过在 Azure Cloud Shell 中运行一行语法来创建此 SPN。您可以使用以下语法为 SPN 创建一个名称，并将其分配给特定的订阅：

az ad sp create-for-rbac --name <SPNNAMEHERE> --role contributor \--scope /subscriptions/<SUBSCRIPTIONIDHERE>

您将希望将输出复制到安全的地方，因为您将需要使用它。它将看起来类似于以下内容：

{"appId": "058t8611-j9k3-4f90-80d9-ag6524c823b7","displayName": " SPNNAME ","name": "http:// SPNNAME","password": "1a2c85hc-43qa-61f0-o4c6-rbg2c5av472r","tenant": "1qr3gg34-q032-4f6h-h19r-6o34b22v530l"
}

连接 Kubernetes 集群到 Azure Arc

现在让我们准备在 Azure 中配置 Azure Arc 启用 Kubernetes 所需的内容，并将其连接到现有的 Kubernetes 集群。这个现有的 Kubernetes 集群可以是 AKS、GKE、EKS 或您自己部署的集群。您可以在 Azure Cloud Shell 中执行这一节中的操作，或者在本地使用类似 VS Code 的工具。建议您从 Bash 中执行以下操作。

请注意，由于我们要连接现有的 Kubernetes 集群，我们需要确保我们的 KUBECONFIG 已配置，并且我们正在针对我们计划连接到 Azure Arc 的 Kubernetes 集群的正确上下文进行操作。

首先，我们需要通过运行以下命令安装 connectedk8s 扩展：

az extension add --name connectedk8s
az extension add --name k8sconfiguration

接下来，我们将使用以下命令注册 Azure Arc 启用 Kubernetes 所需的 Kubernetes 提供程序：

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

在这里，我们可以使用 SPN 登录订阅，以便使用 SPN 执行剩余的任务。以下是使用 az login 与 SPN 的语法：

az login --service-principal -u SPNID -p SPNPASSWORD \--tenant TENANTID

现在我们将创建用于我们预计的 Kubernetes 集群的资源组。您应为每个计划注册到 Azure Arc 的预计 Kubernetes 集群创建一个新的资源组。作为提醒，我们必须在支持 Azure Arc 启用 Kubernetes 的两个区域之一中创建此资源组。使用以下语法创建资源组：

az group create -l EastUS -n PROJECTEDK8SRESOURCEGROUP

接下来，让我们为我们的 SPN 设置 Bash 环境变量，如下所示：

export appId=SPNID
export password=SPNPASSWORD
export tenantId=TENANTID
export resourceGroup=PROJECTEDK8SRESOURCEGROUP
export arcClusterName= PROJECTEDK8SCLUSTERNAME

现在我们可以将我们的 Kubernetes 集群连接到 Azure Arc 启用 Kubernetes。此操作将部署 Azure Arc 启用 Kubernetes 代理和运算符：

az connectedk8s connect -n PROJECTEDK8SCLUSTERNAME \-g PROJECTEDK8SRESOURCEGROUP

完成后，我们的 Kubernetes 集群将连接到 Azure Arc，并将作为 Azure Arc 启用 Kubernetes 中的预计 Kubernetes 集群显示。Figure 4-1 显示了 Azure 门户中 Azure Arc 中预计的 Kubernetes 集群的外观。

图 4-1. Azure 门户中的 Azure Arc 启用 Kubernetes 集群视图

一旦我们的 Kubernetes 集群连接到 Azure Arc，我们可以单击预计的 Kubernetes 集群，并通过访问控制（IAM）为其分配 RBAC，分配标签，锁定集群，查看其属性，为其配置 GitOps 配置，并将 Azure 策略应用于其上。

使用 Azure Active Directory RBAC 与 Azure Arc 预计的 Kubernetes 集群

可以使用 Azure 门户中 Azure Arc 领域的预计集群资源的访问控制（IAM）刀片来为预计的 Kubernetes 集群分配角色分配，如图 Figure 4-2 所示。

图 4-2. Azure 门户中的 Azure Arc 启用 Kubernetes RBAC 角色

请注意，RBAC 仅适用于通过 Azure 访问预投影集群。这不适用于直接访问托管平台上的集群（例如 GCP、AWS、本地等）。

将应用程序部署到启用 GitOps 的 Azure Arc 预投影 Kubernetes 集群

现在我们将详细介绍如何利用 GitOps 将一个简单的应用程序和其他 API 对象部署到我们在 Azure Arc 启用 Kubernetes 中的预投影 Kubernetes 集群中。

你应该首先创建你自己的公共 GitHub 仓库。在仓库中创建一个名为 hello-kubernetes-arc-demo.yaml 的 YAML 文件，并包含以下内容：

apiVersion: v1
kind: Service
metadata:name: hello-kubernetes-custom
spec:type: LoadBalancerports:- port: 80targetPort: 8080selector:app: hello-kubernetes-custom
---
apiVersion: apps/v1
kind: Deployment
metadata:name: hello-kubernetes-custom
spec:replicas: 3selector:matchLabels:app: hello-kubernetes-customtemplate:metadata:labels:app: hello-kubernetes-customspec:containers:- name: hello-kubernetesimage: paulbouwer/hello-kubernetes:1.8ports:- containerPort: 8080env:- name: MESSAGEvalue: I just deployed this on Kubernetes!

这个 YAML 文件来自 Paul Bouwer 的一个仓库。通常用于演示在 Kubernetes 集群中部署小型工作负载。请注意，在启用 Azure Arc 的 Kubernetes 中使用 GitOps 可以与公共和私有 Git 仓库一起工作。为了使用 GitOps 和 Git 私有仓库，你需要使用 SSH，并提供 Flux 创建的或用户提供的密钥。

接下来，我们需要创建 GitOps 配置。这将在预投影的 Kubernetes 集群上部署 Flux 操作符和 Memcached。我们将使用 az k8sconfiguration 命令来执行此操作。以下是运行的语法：

az k8sconfiguration create --name gitops-config \--cluster-name PROJECTEDK8SCLUSTERNAME \--resource-group PROJECTEDK8SRESOURCEGROUP \--operator-instance-name gitops-config \--operator-namespace gitops-config \--repository-url URLOFYOURPUBLICREPOHERE \--scope cluster --cluster-type connectedClusters \--operator-params="--git-poll-interval 5s --git-readonly"

完成后，我们可以验证新的 GitOps 配置是否已在 “Azure 门户上的 Azure Arc” > “Azure Arc | Kubernetes 集群” > [预投影 Kubernetes 集群名称] > GitOps 中创建（参见图 4-3）。

图 4-3. 在 Azure 门户中显示的 GitOps

GitOps 已部署了运行示例应用程序所需的所有内容。它有效地部署了一个服务类型 LoadBalancer、一个具有三个副本的部署以及在预投影 Kubernetes 集群中运行 Web 应用程序的 Pod。你可以使用 kubectl 在你的预投影 Kubernetes 集群中查看新的 API 对象。

通过运行以下命令，你将能够在你的 Kubernetes 集群中看到正在运行的 Pod：

kubectl get pods

通过运行以下命令，你可以看到服务并获取负载均衡器的外部 IP：

kubectl get services

当你在网页浏览器中访问这个 IP 地址时，你应该能看到图 4-4 中显示的输出。

图 4-4. 通过 GitOps 在网页浏览器中部署的应用程序

现在，如果你想确保 GitOps 可以确保应用程序的期望状态，可以继续运行以下命令删除部署：

kubectl delete deployment hello-kubernetes-custom

大约五秒钟后，Flux 将会同步并重新应用 YAML 文件，将部署恢复到原来的状态。

使用 Azure Monitor 监控 Azure Arc 预投影 Kubernetes 集群

监控您的 Kubernetes 集群及其上运行的容器对于操作环境至关重要。您可以在 Azure Arc 启用的 Kubernetes 中使用 Azure Monitor for containers 来查看投影的 Kubernetes 集群的性能，并收集容器日志以监控工作负载。在撰写本文时，Azure Monitor for Containers 不支持 LiveData。在启用此监控之前，您需要满足以下先决条件。这些先决条件可以设置在您创建的 SPN 帐户上：

您需要配置一个带有 Azure Monitor for containers 的 Log Analytics 工作区。
至少，您需要成为 Azure 订阅中的 Azure Contributor 角色成员。
您需要成为配置了 Azure Monitor for containers 的 Log Analytics 工作区的 Log Analytics Contributor 角色成员。
您需要成为 Azure Arc 集群资源的 Contributor 角色成员。
您需要拥有 Log Analytics 读取者角色权限的成员身份。
您需要一个 HELM 客户端来为指定的 Kubernetes 集群启用 Azure Monitor for containers 图表。

让我们来设置一下。请注意，我们将要讲解的所有内容仍然在 Bash 中运行。

首先，让我们使用以下命令下载启用监视（也称为 OMS）脚本：

curl -o enable-monitoring.sh \-L https://aka.ms/enable-monitoring-bash-script

接下来，我们需要使用以下命令获取 Azure Arc 连接的集群 Azure 资源 ID：

export azureArcClusterResourceId=$(az resource show \--resource-group PROJECTEDK8SRESOURCEGROUP \--name PROJECTEDK8SCLUSTERNAME \--resource-type "Microsoft.Kubernetes/connectedClusters" \--query id -o tsv)

使用以下命令从当前的 KubeContext 检索预期的 Kubernetes 集群凭据：

export kubeContext="$(kubectl config current-context)"

使用以下语法运行 enable-monitoring.sh 脚本：

bash enable-monitoring.sh --resource-id $azureArcClusterResourceId \--client-id SPNID --client-secret SPNPASSWORD \--tenant-id TENANTID --kube-context $kubeContext

当 enable-monitoring.sh 完成后，您可以在 Azure 门户中进入“Azure Arc” > “Azure Arc | Kubernetes clusters” > [投影 Kubernetes 集群名称] > “监视 - 洞察”，查看您的投影 Kubernetes 集群的监视情况（见 Figure 4-5）。请注意，数据开始填充可能需要长达 15 分钟的时间。

图 4-5. 在 Azure Arc 启用的 Kubernetes 中查看监视的投影 Kubernetes 集群视图

总结

这就是我们一起的旅程的结束。让我们回顾一下我们所涵盖的内容。在本报告中，我们首先触及了多云市场需求及其如何推动在多个云上管理 Kubernetes 的需求。然后，我们简要介绍了 Azure Arc 的历史，并概述了整体服务。我们以 Azure Arc 如何实现“单一窗口”承诺来结束这一部分。

我们进入了 Azure Arc 启用的 Kubernetes 的另一条路线，首先概述了 Azure Kubernetes Service。然后，我们解释了 Azure Arc 启用的 Kubernetes 是什么以及其影响。我们深入了解了 GitOps 的定义、功能以及如何使用它，最后讨论了 Azure Arc 如何利用 GitOps。

我们随后深入探讨了 Azure Arc 的架构和组件，如何将 Kubernetes 集群连接到其中，以及如何使用 RBAC 和 Azure Monitor 来管理启用 Azure Arc 的 Kubernetes。我们还介绍了如何设置 GitOps 并将应用程序和配置部署到预期的 Kubernetes 集群。

希望您从本报告中对 Azure Arc 和 GitOps 有所收获。如果您的组织在不同环境中运行多个 Kubernetes 集群，我建议进一步了解 Azure Arc，作为简化多环境中 Kubernetes 管理需求的方法。

作者简介

Steve Buchanan（@buchatech）是一家大型咨询公司云转型团队的总监和中西部容器服务负责人。他是九次获得微软 MVP 奖项的获得者，Pluralsight 的作者，撰写了六本技术书籍。作为国际演讲者，他曾在包括中西部管理峰会（MMS）、Microsoft Ignite、BITCon、Experts Live Europe、OSCON、Inside Azure management 和用户组等技术活动上发表演讲。Steve 目前专注于通过 ITSM、DevOps 和 CloudOps 将 IT 的角色转变为业务的战略合作伙伴和数字转型的推动者。他活跃于技术社区，并喜欢在他的 IT 世界冒险博客www.buchatech.com上发布博文。