超级会员免费看
利用 Azure Arc 实现 Kubernetes 集群的高级管理与部署
1. 配置 Azure Arc 和 Azure AD RBAC 进行 Kubernetes 集群的 RBAC 管理
Azure Arc 支持的 Kubernetes 一大优势在于能够利用 Azure Active Directory (AAD) 作为身份提供者，对 Kubernetes 集群进行授权和访问控制。借助 RBAC 和 Azure Arc 支持的 Kubernetes，可使用 Azure AD 和角色分配来控制对 Kubernetes 对象（如部署、Pod 和服务）的读写和删除操作。
1.1 集成前提条件
- 安装 Azure CLI。
- 安装 connectedk8s 扩展。
- 连接到现有的 Azure Arc 投影 Kubernetes 集群。
1.2 集成步骤
- 设置 Azure AD 应用程序 ：
- 创建服务器应用程序。
- 创建客户端应用程序。
- 为服务器应用程序创建角色分配。
-
在 K8s 集群上启用 Azure AD RBAC
：
在投影的 K8s 集群上运行以下命令以启用 Azure AD RBAC 功能：
az connectedk8s enable-features -n ARCK8sNAME -g RGNAME --features azure-rbac --app-id SPAPPID --app-secret SPPWD
1.3 角色分配
Azure AD RBAC 集成有以下角色分配，可通过 Azure 门户>Azure Arc 上投影集群资源的访问控制 (IAM) 刀片进行分配：
| 角色名称 | 描述 |
| — | — |
| Azure Arc Kubernetes Viewer | 允许对命名空间中的大多数对象进行只读访问，但不允许查看机密。 |
| Azure Arc Kubernetes Writer | 允许对命名空间中的大多数对象进行读写访问，但不允许查看或修改角色或角色绑定。 |
| Azure Arc Kubernetes Admin | 允许管理员访问，旨在通过 RoleBinding 在命名空间内授予。 |
| Azure Arc Kubernetes Cluster Admin | 允许超级用户对任何资源执行任何操作。 |
1.4 创建自定义角色定义
创建自定义角色定义分三步：
-
步骤 1
：创建 customrole.json 文件，示例如下：
{
"Name": "Arc Deployment Viewer",
"Description": "Lets you view all deployments in cluster/namespace.",
"Actions": [],
"NotActions": [],
"DataActions": [
"Microsoft.Kubernetes/connectedClusters/apps/deployments/read"
],
"NotDataActions": [],
"assignableScopes": [
"/subscriptions/<subscription-id>"
]
}
- 步骤 2 ：使用以下命令从 customrole.json 文件创建角色定义：
az role definition create --role-definition mycustomrole.json
- 步骤 3 ：使用步骤 1 中创建的自定义角色定义创建角色分配：
az role assignment create --role "Arc Deployment Viewer" --assignee <AZURE-AD-ENTITY-ID> --scope $ARM_ID/namespaces/<namespace-name>
1.5 连接到投影的 K8s 集群
有两种方式连接到投影的 K8s 集群：
-
使用 Cluster Connect 功能 (az connectedk8s proxy)
：
az connectedk8s proxy -n ARCK8sNAME -g RGNAME
运行上述命令后即可运行 kubectl 命令。
-
使用 kubeconfig 文件
：
- 设置用户凭据：
kubectl config set-credentials user@domain.com \
--auth-provider=azure \
--auth-provider-arg=environment=AzurePublicCloud \
--auth-provider-arg=client-id=SPCLIENTID \
--auth-provider-arg=tenant-id=TENANTID \
--auth-provider-arg=apiserver-id=SPAPPID
- 在 user > config 下添加 config-mode 设置：
name: user@domain.com
user:
auth-provider:
config:
apiserver-id: $SERVER_APP_ID
client-id: $CLIENT_APP_ID
environment: AzurePublicCloud
tenant-id: $TENANT_ID
config-mode: "1"
name: azure
此时即可运行 kubectl 命令。
2. 使用 Microsoft Defender for Cloud 和 Azure Arc 保护 Kubernetes 集群
Microsoft Defender for Cloud for Kubernetes 集群扩展能够保护运行在本地或其他云环境中的投影 Kubernetes 集群，提供与 Azure Kubernetes Service (AKS) 集群相同的威胁检测和防护能力。
2.1 接收和分析的项目
- API 服务器的审计日志。
- Log Analytics 代理的原始安全事件。
- 投影 Kubernetes 集群的集群配置信息。
- 通过 Azure Policy 加载项获取的工作负载配置。
2.2 前提条件
- 在订阅上启用 Microsoft Defender for Cloud for Kubernetes。
- 外部 Kubernetes 集群已连接到 Azure Arc。
- 满足通用集群扩展的前提条件（Azure CLI、connectedk8s 和 k8s-extension 扩展，投影 K8s 集群已连接到 Arc）。
2.3 部署扩展
在运行以下代码之前，需先运行 “az login” 和 “az account set”：
az k8s-extension create --name microsoft.azuredefender.kubernetes \
--cluster-type connectedClusters --cluster-name ARCK8sCLUSTERNAME \
--resource-group RGNAME --extension-type microsoft.azuredefender.kubernetes
3. 使用 Azure Policy、Azure Arc 和 GitOps 强制实施 Kubernetes 集群的合规性
Azure Policy 可用于对 Kubernetes 集群实施合规性控制，最初用于 Azure Kubernetes Service 集群，随着 Azure Arc 支持的 Kubernetes 的引入，其应用范围扩展到外部 Kubernetes 集群，还可与 GitOps 结合使用。
3.1 Azure Policy 的作用
- 以集中、一致的方式应用策略，保护投影的 Kubernetes 集群。
- 在 Azure Arc 投影的 Kubernetes 集群上大规模应用 GitOps 配置。
3.2 示例策略
- Kubernetes 集群容器应仅使用允许的镜像。
- 应启用 Azure Kubernetes Service 私有集群。
- Kubernetes 集群不应使用默认命名空间。
- 应在 Kubernetes 服务上定义授权 IP 范围。
3.3 前提条件
- 安装 Azure CLI 版本 2.12.0 或更高版本。
- 在订阅中注册 Azure Policy 提供程序：
az provider register --namespace 'Microsoft.PolicyInsights'
- Kubernetes 集群版本 1.14 或更高。
- Helm 3 或更高。
- 外部 Kubernetes 集群已连接到 Azure Arc。
- 需要 Azure Arc 支持的 Kubernetes 集群的 Azure 资源 ID。
- 为 Azure Arc 支持的 Kubernetes 集群分配 “Policy Insights Data Writer (Preview)” 角色分配。
3.4 工作原理
Azure Policy for K8s 基于 Open Policy Agent 实现的 Gatekeeper，由 Gatekeeper 组件和 Azure-policy 组件组成。添加 Azure Policy 扩展时，会创建 gatekeeper-system 命名空间并部署两个 Pod：gatekeeper-audit pods 和 gatekeeper-controller pods。
Azure Policy for Kubernetes 有审计和拒绝两种效果：
- 默认情况下，gatekeeper-audit pod 会检查集群是否存在违规。
- 当操作设置为拒绝时，gatekeeper-controller pods 会执行强制实施。
3.5 安装和分配策略
- 安装 Azure Policy 加载项 ：
- 添加 Azure Policy 加载项仓库到 Helm：
helm repo add azure-policy https://raw.githubusercontent.com/Azure/azure-policy/master/extensions/policy-addon-kubernetes/helm-charts
- 安装 Azure Policy 加载项 Helm 图表：
helm install azure-policy-addon azure-policy/azure-policy-addon-arc-clusters \
--set azurepolicy.env.resourceid=<AzureArcClusterResourceId> \
--set azurepolicy.env.clientid=<ServicePrincipalAppId> \
--set azurepolicy.env.clientsecret=<ServicePrincipalPassword> \
--set azurepolicy.env.tenantid=<ServicePrincipalTenantId>
-
分配 Azure Policy
：
1. 在 Azure 门户中，点击左窗格中的“所有服务”，然后搜索“Policy”。
2. 在左窗格的“创作”下，点击“定义”。
3. 在“类别”下拉列表框中，点击“全选”清除过滤器，然后在过滤器框中输入“Kubernetes”以筛选到 Kubernetes，点击“Kubernetes”。
4. 选择策略定义，然后选择“分配”按钮。
5. 确定策略应用的范围（如管理组、订阅、资源组）。
6. 为策略分配命名并提供描述。
7. 将策略强制实施设置为“已启用”或“已禁用”，然后点击“下一步”。
8. 设置参数（如有需要）。
9. 默认情况下，kube-system、gatekeeper-system 和 azure-arc 命名空间会被排除，建议保留此设置。
10. 点击“查看 + 创建”。
4. 理解 GitOps 和 Azure Arc 支持的 Kubernetes 架构与工作流程
GitOps 是一种云原生应用和 Kubernetes 的操作模式，将应用和声明式基础设施代码存储在 Git 中作为自动化持续交付的事实来源。Azure Arc 支持的 Kubernetes 利用 Flux 这个开源的 GitOps 操作符。
4.1 GitOps 的作用
- Kubernetes 配置 ：包括命名空间、配置映射、机密、入口控制器等对象的配置。
- 应用部署 ：如部署、Pod、服务、Helm 图表等应用的部署。
4.2 连接关系
Azure Arc 支持的 Kubernetes 集群和 Git 存储库的连接在 ARM 中作为名为 Microsoft.KubernetesConfiguration/sourceControlConfigurations 的扩展资源存在，存储在 Azure Cosmos DB 数据库中并进行静态加密。每个集群可以有多个 sourceControlConfigurations，可按命名空间进行范围限定。
4.3 sourceControlConfiguration 属性
- 配置名称
- 操作符实例名称
- 操作符命名空间
- 存储库 URL
- 操作符范围（命名空间/集群）
- 操作符类型
- 操作符参数
- Helm（启用/禁用）
5. 在 Azure Arc 中设置 GitOps 配置
设置 GitOps 配置有两种方式：
5.1 通过命令行设置
例如，在运行 GKE 时，可将以下代码保存到名为 “az_k8sconfig_gke.sh” 的文件中，并通过 Google Cloud Shell 运行：
az k8s-configuration create \
--name hello-arc \
--cluster-name $arcClusterName --resource-group $resourceGroup \
--operator-instance-name hello-arc --operator-namespace prod \
--enable-helm-operator \
--helm-operator-params='--set helm.versions=v3' \
--repository-url $appClonedRepo \
--scope namespace --cluster-type connectedClusters \
--operator-params="--git-poll-interval 3s --git-readonly --git-path=releases/prod"
5.2 通过 Azure 门户设置
- 转到 Azure Arc ➤ Kubernetes 集群 ➤ GitOps。
- 点击“添加配置”，完成所需属性和可选属性（如有需要）：
- 配置名称
- 操作符实例名称
- 操作符命名空间
- 存储库 URL
- 操作符范围（命名空间/集群）
- 操作符类型
- 操作符参数
- Helm（启用/禁用）
-
点击“添加”。
注意：GitOps 配置状态将显示为待处理，最多可能需要 10 分钟才能变为“已安装”状态。
6. 使用 GitOps 和 Azure Arc 将应用部署到投影的 Kubernetes 集群
在投影的 Kubernetes 集群上设置好 GitOps 后，可按以下步骤部署应用：
- 开发人员编写应用代码或 DevOps 工程师编写 Kubernetes 集群配置代码。
- 开发人员将代码推送到应用存储库的远程分支并打开拉取请求进行审查。
- 审查拉取请求以批准或拒绝合并。
- 按需验证更改。
- 负责人或团队批准拉取请求，更改合并到主 Git 存储库。
- 在短时间内（由您设置的间隔），Flux 会检测到与 Flux GitOps 操作符连接的 Git 存储库中的新更改。
- Flux GitOps 操作符将拉取更改并应用到投影的 Kubernetes 集群，实现应用和配置的部署。
7. 理解 Azure Arc 和 GitOps 与 Helm 的协同工作
通过 GitOps 和 Azure Arc 支持的 Kubernetes 部署基于 Helm 的应用与使用 Kubernetes 清单文件部署应用类似，但有一些区别：
- Helm 是 Kubernetes 的包管理器，用于管理 Kubernetes 上应用的生命周期。
- Azure Arc 支持的 Kubernetes 中的 Helm 操作符为 Flux 提供扩展，实现 Helm 图表发布的自动化。
- 在 Arc K8s GitOps 配置中，Helm 可设置为启用或禁用。
- 操作符使用 “HelmRelease” 自定义资源定义 (CRD)，可向 Helm 图表输入特定值，方便为不同环境（如开发、测试、生产）设置值。
8. 理解 Azure Arc 和 GitOps 与 IoT Edge 工作负载的协同工作
Azure IoT Edge 将云分析和自定义业务逻辑迁移到设备，将服务打包在边缘设备上运行的容器中。Azure Arc 支持的 Kubernetes 可管理 IoT Edge 上的 Kubernetes 集群，GitOps 可用于通过 Azure Arc 支持的 Kubernetes 将 IoT Edge 工作负载部署到 IoT Edge。
8.1 关键要点
- 使用 IoT Edge 时，需自带 K8s 集群并在其中注册 IoT Edge 自定义资源定义 (CRD) 控制器。
- Arc K8s 可用于操作运行 IoT Edge 的 K8s 集群，包括通过 GitOps 远程大规模部署/管理工作负载，并与云服务（如 IoT Hub）进行双向数据摄取。
- 所有 IoT Edge 组件都限定在特定的 Kubernetes 命名空间内，允许在单个集群中用于多个边缘设备。
利用 Azure Arc 实现 Kubernetes 集群的高级管理与部署
9. 总结
本文围绕 Azure Arc 支持的 Kubernetes 展开，深入探讨了其多方面的应用与管理方式，旨在帮助读者全面掌握如何利用 Azure Arc 提升 Kubernetes 集群的管理效率、安全性和合规性。
从安全防护角度来看，借助 Azure AD RBAC 可以对 Kubernetes 集群进行精细的权限控制，通过配置不同的角色和角色分配，明确不同用户或团队对集群资源的访问权限，确保数据安全和操作合规。同时，Microsoft Defender for Cloud 为集群提供了强大的威胁检测和防护能力，实时监控集群的安全状态，及时发现并处理潜在的安全风险。
在合规性管理方面，Azure Policy 发挥了重要作用。它能够以集中、一致的方式对 Kubernetes 集群实施策略，无论是针对容器镜像的使用限制，还是对集群配置的规范要求，都能通过策略的设置和执行来确保集群符合特定的合规标准。并且，结合 GitOps 可以实现策略的自动化部署和更新，提高管理效率。
GitOps 作为一种先进的操作模式，在 Azure Arc 支持的 Kubernetes 中展现出了巨大的优势。它将应用和基础设施代码存储在 Git 中，通过 Flux 操作符实现集群配置和应用部署的自动化，确保集群状态与 Git 中的代码保持一致。这不仅简化了部署流程，还提高了部署的可靠性和可重复性。
此外，在与 Helm 和 IoT Edge 的集成方面，Azure Arc 支持的 Kubernetes 也表现出色。Helm 作为 Kubernetes 的包管理器，与 GitOps 结合可以更方便地管理应用的生命周期；而与 IoT Edge 的协同工作，则使得 Kubernetes 集群能够更好地适应边缘计算场景，实现云边协同的高效运行。
综上所述，Azure Arc 支持的 Kubernetes 为企业提供了一个全面、高效、安全的 Kubernetes 管理解决方案。通过合理运用上述各项技术和工具，企业可以在不同的应用场景中更好地发挥 Kubernetes 的优势，提升业务的竞争力和灵活性。
为了更清晰地展示整个流程，以下是一个 mermaid 格式的流程图，概括了从配置到部署的主要步骤：
graph LR
classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px
A(开始):::process --> B(配置 Azure AD RBAC):::process
B --> C(保护集群 - Defender for Cloud):::process
C --> D(实施合规性 - Azure Policy):::process
D --> E(理解 GitOps 架构):::process
E --> F(设置 GitOps 配置):::process
F --> G(部署应用 - GitOps):::process
G --> H(与 Helm 协同):::process
H --> I(与 IoT Edge 协同):::process
I --> J(结束):::process
以下是一个表格，总结了各个部分的关键信息和操作步骤：
| 部分 | 关键信息 | 操作步骤 |
| — | — | — |
| 配置 Azure AD RBAC | 利用 Azure AD 进行授权和访问控制，支持多种角色分配 | 1. 满足前提条件；2. 设置 Azure AD 应用程序；3. 启用 Azure AD RBAC；4. 创建自定义角色定义；5. 连接到集群 |
| 保护集群 - Defender for Cloud | 提供威胁检测和防护能力，分析多种数据来源 | 1. 满足前提条件；2. 部署扩展 |
| 实施合规性 - Azure Policy | 集中、一致地应用策略，结合 GitOps 实现自动化 | 1. 满足前提条件；2. 安装 Azure Policy 加载项；3. 分配策略 |
| 理解 GitOps 架构 | 以 Git 为事实来源，利用 Flux 实现自动化 | 了解 GitOps 对配置和部署的作用，掌握连接关系和属性 |
| 设置 GitOps 配置 | 支持命令行和 Azure 门户两种方式 | 1. 命令行设置；2. 门户设置 |
| 部署应用 - GitOps | 基于已设置的 GitOps 进行应用部署 | 1. 编写代码；2. 推送代码；3. 审查合并；4. Flux 检测并应用更改 |
| 与 Helm 协同 | Helm 是包管理器，实现 Helm 图表发布自动化 | 了解 Helm 与 Flux 的协同方式，设置 Helm 状态 |
| 与 IoT Edge 协同 | 管理 IoT Edge 上的 Kubernetes 集群，实现云边协同 | 1. 注册 IoT Edge CRD 控制器；2. 操作 K8s 集群；3. 限定命名空间 |
希望通过本文的介绍，读者能够对 Azure Arc 支持的 Kubernetes 有更深入的理解，并在实际应用中充分发挥其优势，实现高效、安全、合规的 Kubernetes 集群管理和应用部署。
扫一扫
415
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
