GitOps


Red Hat Advanced Cluster Management for Kubernetes 2.12

GitOps

Red Hat Advanced Cluster Management for Kubernetes Team

摘要

了解如何使用集成的 GitOps 和 Argo CD。

第 1 章 GitOps 概述

Red Hat OpenShift Container Platform GitOps 和 Argo CD 与原始 Application Lifecycle ChannelSubscription 模型相比,与 Red Hat Advanced Cluster Management for Kubernetes 集成。

GitOps 与 Argo CD 开发集成处于活跃状态,以及为 Argo CD 提供功能增强和更新的大型社区。通过使用 OpenShift Container Platform GitOps Operator,您可以使用 Argo CD 开发中的最新改进,并从 GitOps Operator 订阅接收支持。

请参阅以下主题以了解更多有关与 OpenShift Container Platform GitOps 和 Argo CD 集成的 Red Hat Advanced Cluster Management for Kubernetes 的信息:

1.1. GitOps 控制台

了解有关集成的 OpenShift Container Platform GitOps 控制台功能的更多信息。创建并查看应用程序,如 ApplicationSetArgo CD 类型。ApplicationSet 代表从控制器生成的 Argo 应用程序。

  • 您可以点 Launch resource in Search 搜索相关资源。
  • 使用 Search 根据每个资源的组件 kind 查找应用程序资源。

重要:可用的操作基于您分配的角色。了解 基于角色的访问控制文档中的访问要求。

1.1.1. 先决条件

请参见以下先决条件和要求:

  • 要创建 ArgoCD ApplicationSet,您需要从 Sync 策略中启用 Automatically sync when cluster state changes
  • 对于带有 kustomization 控制器的 Flux,找到带有标签 kustomize.toolkit.fluxcd.io/name=<app_name> 的 Kubernetes 资源。
  • 对于带有 helm 控制器的 Flux,找到带有标签 helm.toolkit.fluxcd.io/name=<app_name> 的 Kubernetes 资源。
  • 您需要 GitOps 集群资源和 GitOps operator 来创建 ApplicationSet。如果没有满足这些先决条件,您将无法在控制台中看到 Argo 服务器选项来创建 ApplicationSet

1.1.2. 查询 Argo CD 应用程序

当您搜索 Argo CD 应用程序时,您会被定向到 Applications 页面。完成以下步骤,从 Search 页面访问 Argo CD 应用程序:

  1. 登录到您的 Red Hat Advanced Cluster Management hub 集群。
  2. 在控制台标头中选择搜索图标。
  3. 使用以下值过滤查询:kind:applicationapigroup:argoproj.io
  4. 选择要查看的应用程序。Application 页面中显示应用的信息的概览。

有关搜索的更多信息,请参阅 在控制台中搜索

1.2. 将受管集群注册到 Red Hat OpenShift GitOps operator

要使用 Push 模型配置 OpenShift GitOps,您可以将一个或多个 Red Hat Advanced Cluster Management for Kubernetes 受管集群的集合注册到 OpenShift GitOps operator 实例。注册后,您可以将应用程序部署到这些集群中。设置持续 OpenShift GitOps 环境,以便在开发、临时和生产环境中的集群间自动实现应用程序一致性。

1.2.1. 先决条件

  1. 您需要在 Red Hat Advanced Cluster Management for Kubernetes 上安装 Red Hat OpenShift GitOps Operator。
  2. 导入一个或多个受管集群。
  3. 要将受管集群注册到 OpenShift GitOps,请完成 创建 ManagedClusterSet 文档。

1.2.2. 将受管集群注册到 Red Hat OpenShift GitOps

完成以下步骤,将受管集群注册到 OpenShift GitOps:

  1. 创建受管集群集绑定到部署 OpenShift GitOps 的命名空间。有关将受管集群绑定到 openshift-gitops 命名空间的示例,请参阅 multicloud-integrations 受管集群设置绑定示例。Additional resources 部分,请参阅创建 ManagedClusterSetBinding 资源 以了解更多有关创建 ManagedClusterSetBinding 的信息。如需有关放置信息,请参阅从 ManagedClusterSets 中过滤 ManagedClusters
  2. 在受管集群集绑定中使用的命名空间中,创建一个 放置自定义资源 来选择要注册到 OpenShift GitOps operator 实例的一组受管集群。使用 multicloud-integration 放置示例作为模板。如需放置信息,请参阅使用 ManagedClusterSet with Placement

    备注:

    • 只有 OpenShift Container Platform 集群注册到 OpenShift GitOps operator 实例,而不是其他 Kubernetes 集群。
    • 在一些不稳定的网络场景中,受管集群可能会临时处于 unavailableunreachable 的状态。如需了解更多详细信息,请参阅为 Red Hat Advanced Cluster Management 和 OpenShift GitOps 配置放置容限
  3. 创建 GitOpsCluster 自定义资源,将一组受管集群从放置决定注册到指定的 OpenShift GitOps 实例。这可让 OpenShift GitOps 实例将应用程序部署到任何 Red Hat Advanced Cluster Management 受管集群。使用 multicloud-integrations OpenShift GitOps 集群示例。

    注:引用的放置资源必须与 GitOpsCluster 资源位于同一个命名空间中。请参见以下示例:

    apiVersion: apps.open-cluster-management.io/v1beta1
    kind: GitOpsCluster
    metadata:
      name: gitops-cluster-sample
      namespace: dev
    spec:
      argoServer:
        cluster: local-cluster
        argoNamespace: openshift-gitops
      placementRef:
        kind: Placement
        apiVersion: cluster.open-cluster-management.io/v1beta1
        name: all-openshift-clusters 1
    1
    placementRef.name 值是 all-openshift-clusters,指定为在 argoNamespace: openshift-gitops 中安装的 OpenShift GitOps 实例的目标集群。argoServer.cluster 规格需要 local-cluster 值。
  4. 保存您的更改。现在,您可以按照 OpenShift GitOps 工作流来管理应用程序。

1.2.3. 将非 OpenShift Container Platform 集群注册到 Red Hat OpenShift GitOps

现在,您可以使用 Red Hat Advanced Cluster Management GitOpsCluster 资源将非 OpenShift Container Platform 集群注册到 OpenShift GitOps 集群。借助此功能,您可以使用 OpenShift GitOps 控制台将应用程序资源部署到非 OpenShift Container Platform 集群中。要将非 OpenShift Container Platform 集群注册到 OpenShift GitOps 集群,请完成以下步骤:

  1. 进入非 OpenShift Container Platform ManagedCluster 资源 spec 中的 API 服务器 URL,并运行以下命令来验证它:

    oc get managedclusters eks-1
  2. 验证您的输出是否类似以下信息:

    NAME    HUB ACCEPTED   MANAGED CLUSTER URLS                                                      JOINED   AVAILABLE   AGE
    eks-1   true           https://5E336C922AB16684A332C10535B8D407.gr7.us-east-2.eks.amazonaws.com  True     True        37m
  3. 如果非 OpenShift Container Platform MangedCluster 资源 spec 中的 API 服务器 URL 为空,请完成以下步骤来手动更新它:

    1. 要完成 API 服务器 URL,请运行以下命令来编辑 MangedCluster 资源 spec

      oc edit managedclusters eks-1
    2. 验证您的 YAML 类似于以下文件:

      spec:
        managedClusterClientConfigs:
        - caBundle: ZW1wdHlDQWJ1bmRsZQo=
          url: https://5E336C922AB16684A332C10535B8D407.gr7.us-east-2.eks.amazonaws.com
    3. 保存更改,运行以下命令来验证 API 服务器是否已完成:

      oc get managedclusters eks-1
    4. 验证您的输出是否类似以下信息:
    NAME     HUB ACCEPTED  MANAGED CLUSTER URLS                                                      JOINED   AVAILABLE   AGE
    eks-1    true          https://5E336C922AB16684A332C10535B8D407.gr7.us-east-2.eks.amazonaws.com  True     True        37m
  4. 要验证是否生成了集群 secret,请转至 openshift-gitops 命名空间,并确认 GitOpsCluster 资源状态报告成功。

    备注:

    • 在 Red Hat Advanced Cluster Management 2.12 或更高版本中,如果您使用以下导入模式,所有类型的非 OpenShift Container Platform ManagedCluster 资源的 API 服务器 URL 会自动显示:

      • 为现有集群输入服务器 URL 和 API 令牌。
      • 为现有集群输入 kubeconfig 文件。
    • 以下情况可使其中一个 ManagedClusters 资源使 API 服务器 URL 为空:

      • 在版本 2.12 前,非 OpenShift Container Platform 集群会导入到 Red Hat Advanced Cluster Management hub 集群中。
      • 非 OpenShift Container Platform 集群通过导入模式手动导入到版本 2.12 中的 Red Hat Advanced Cluster Management hub 集群,运行导入命令

1.2.4. Red Hat OpenShift GitOps 令牌

当您与 OpenShift GitOps operator 集成时,对于通过放置和 ManagedClusterSetBinding 自定义资源绑定到 OpenShift GitOps 命名空间的每个受管集群,会在 OpenShift GitOps 实例服务器命名空间中创建一个令牌来访问 ManagedCluster

OpenShift GitOps 控制器需要此 secret 将资源同步到受管集群。默认情况下,服务帐户应用程序管理器与受管集群上的集群管理员权限一起工作,以在 OpenShift GitOps 实例服务器命名空间中生成 OpenShift GitOps 集群 secret。默认命名空间是 openshift-gitops

如果您不想此默认值,请在受管集群中创建一个带有自定义权限的服务帐户,以便在 OpenShift GitOps 实例服务器命名空间中生成 OpenShift GitOps 集群 secret。默认命名空间仍然是 openshift-gitops。如需更多信息,请参阅为 Argo CD push 模型创建自定义服务帐户

1.2.5. 其他资源

如需更多信息,请参阅以下资源和示例:

1.3. 为 GitOps 配置应用程序放置容限

Red Hat Advanced Cluster Management 为您提供了将应用程序部署到 Red Hat OpenShift GitOps 的受管集群。

在一些不稳定的网络场景中,受管集群可能会临时处于 Unavailable 状态。如果使用 Placement 资源来简化应用程序的部署,请为 Placement 资源添加以下容限,以继续包含不可用集群。以下示例显示了具有容限的 Placement 资源 :

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: placement
  namespace: ns1
spec:
  tolerations:
    - key: cluster.open-cluster-management.io/unreachable
      operator: Exists
    - key: cluster.open-cluster-management.io/unavailable
      operator: Exists

1.4. 使用 Push 和 Pull 模型部署 Argo CD

使用 Push 模型,hub 集群上的 Argo CD 服务器会在受管集群中部署应用程序资源。对于 Pull 模型,应用程序资源由 Propagation 控制器传播到受管集群,使用 manifestWork

对于这两种模型,相同的 ApplicationSet CRD 用于将应用程序部署到受管集群。

需要的访问权限:集群管理员

1.4.1. 先决条件

查看 Argo CD Pull 模型的以下先决条件:

重要:

  • 如果您的 openshift-gitops-ArgoCD-application-controller 服务帐户 没有分配 为集群管理员,则 GitOps 应用程序控制器可能无法部署资源。应用程序状态可能会发送类似以下错误的错误:
cannot create resource "services" in API group "" in the namespace
"mortgage",deployments.apps is forbidden: User
"system:serviceaccount:openshift-gitops:openshift-gitops-Argo CD-application-controller"
  • 在受管集群中安装 OpenShift Gitops Operator 后,您必须在同一受管集群中创建 ClusterRoleBinding 集群管理员特权。
  • 要将 ClusterRoleBinding 集群管理员特权添加到受管集群,请参阅以下 YAML 示例:

    kind: ClusterRoleBinding
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: argo-admin
    subjects:
      - kind: ServiceAccount
        name: openshift-gitops-argocd-application-controller
        namespace: openshift-gitops
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: ClusterRole
      name: cluster-admin
  • 如果您不是集群管理员,需要解决这个问题,请完成以下步骤:

    1. 在部署 Argo CD 应用程序的每个受管集群中创建所有命名空间。
    2. managed-by 标签添加到每个命名空间。如果 Argo CD 应用程序部署到多个命名空间,则每个命名空间都应该由 Argo CD 管理。

      请参见以下带有 managed-by 标签的示例:

    apiVersion: v1
    kind: Namespace
    metadata:
      name: mortgage2
      labels:
        argocd.argoproj.io/managed-by: openshift-gitops
    1. 您必须在存储库中声明应用程序的所有应用程序目的地命名空间,并在命名空间中包含 managed-by 标签。请参阅附加资源以了解如何声明命名空间。

请参阅以下要求来使用 Argo CD Pull 模型:

  • GitOps Operator 必须安装到 hub 集群和 openshift-gitops 命名空间中的目标受管集群。
  • 所需的 hub 集群 OpenShift Container Platform GitOps operator 必须是版本 1.9.0 或更高版本。
  • 所需的受管集群 OpenShift Container Platform GitOps Operator 必须与 hub 集群相同。
  • 您需要 ApplicationSet 控制器 为受管集群传播 Argo CD 应用程序模板。
  • 每个受管集群都必须在 hub 集群上的 Argo CD 服务器命名空间中有一个集群 secret,而 ArgoCD 应用程序设置控制器需要该 secret 来为受管集群传播 Argo CD 应用程序模板。

    要创建集群 secret,请创建一个 gitOpsCluster 资源,其中包含对 placement 资源的引用。placement 资源选择所有需要支持 Pull 模型的受管集群。当 GitOps 集群控制器协调时,它会在 Argo CD 服务器命名空间中为受管集群创建集群 secret。

1.4.2. 架构

对于 Push 和 Pull 模型,hub 集群上的 Argo CD ApplicationSet 控制器会协调为每个目标受管集群创建应用程序资源。有关这两种模型的架构,请查看以下信息:

1.4.2.1. 架构推送模型
  • 使用 Push 模型时,OpenShift Container Platform GitOps 将资源直接从集中 hub 集群应用到受管集群。
  • 在 hub 集群上运行的 Argo CD 应用程序与 GitHub 存储库通信,并将清单直接部署到受管集群。
  • 推送模型实现仅包含 hub 集群上的 Argo CD 应用程序,其中包含受管集群的凭证。hub 集群上的 Argo CD 应用程序可将应用程序部署到受管集群。
  • 重要: 对于需要资源应用程序的大量受管集群,请考虑 OpenShift GitOps GitOps 控制器内存和 CPU 用量的潜在压力。要优化资源管理,请参阅 Red Hat OpenShift GitOps 文档中的配置资源配额或请求
  • 默认情况下,Push 模型用于部署应用程序,除非您将 apps.open-cluster-management.io/ocm-managed-clusterapps.open-cluster-management.io/pull-to-ocm-managed-cluster 注解添加到 ApplicationSet 的 template 部分。
1.4.2.2. 架构 Pull 模型
  • 拉取模型可以通过减少 hub 集群中的控制器的压力与推送模型提供可扩展性,但需要更多请求和状态报告。
  • 使用 Pull 模型时,OpenShift Container Platform GitOps 不会将资源直接从集中 hub 集群应用到受管集群。Argo CD Application 从 hub 集群传播到受管集群。
  • 拉取模型实现应用 OpenShift Cluster Manager 注册、放置和 manifestWork API,以便 hub 集群和受管集群之间可以使用安全通信频道来部署资源。
  • 每个受管集群都单独与 GitHub 存储库通信,以便在本地部署资源清单,因此您必须在每个受管集群中安装和配置 GitOps operator。
  • Argo CD 服务器必须在每个目标受管集群中运行。Argo CD 应用程序资源在受管集群中复制,然后由本地 Argo CD 服务器部署。受管集群中的分布式 Argo CD 应用程序使用 hub 集群上的单个 Argo CD ApplicationSet 资源创建。
  • 受管集群由 ocm-managed-cluster 注解的值决定。
  • 要成功实现 Pull 模型,Argo CD 应用程序控制器必须在 ApplicationSet 的 template 部分中忽略带有 argocd.argoproj.io/skip-reconcile 注解的 Push 模型应用程序资源。
  • 对于 Pull 模型,受管集群中的 Argo CD Application 控制器会 协调以部署应用程序。
  • hub 集群上的 Pull model Resource sync 控制器 会定期查询 OpenShift Cluster Manager 在每个受管集群上搜索 V2 组件,以检索每个 Argo CD 应用程序的资源列表和错误消息。
  • hub 集群上的 聚合控制器 使用资源同步控制器的数据以及 manifestWork 的状态信息,从集群间创建和更新 MulticlusterApplicationSetReport
  • 部署的状态被收集回 hub 集群,但不会传输所有详细信息。定期提取其他状态更新以提供概述。状态反馈不是实时的,每个受管集群 GitOps operator 需要与 Git 存储库通信,这会导致多个请求。

1.4.3. 创建 ApplicationSet 自定义资源

Argo CD ApplicationSet 资源用于使用用于获取受管集群列表的 Push 或 Pull 模型在受管集群中部署应用程序。

  1. 对于 Pull 模型,将应用程序的目的地设置为默认本地 Kubernetes 服务器,如下例所示。应用程序由受管集群上的应用程序控制器在本地部署。
  2. 添加覆盖默认 Push 模型所需的注解,如下例所示 ApplicationSet YAML,该 YAML 使用带有模板注解的 Pull 模型:

    apiVersion: argoproj.io/v1alpha1
    kind: `ApplicationSet`
    metadata:
      name: guestbook-allclusters-app-set
      namespace: openshift-gitops
    spec:
      generators:
      - clusterDecisionResource:
          configMapRef: ocm-placement-generator
          labelSelector:
            matchLabels:
              cluster.open-cluster-management.io/placement: aws-app-placement
          requeueAfterSeconds: 30
      template:
        metadata:
          annotations:
            apps.open-cluster-management.io/ocm-managed-cluster: '{{name}}'1
            apps.open-cluster-management.io/ocm-managed-cluster-app-namespace: openshift-gitops
            argocd.argoproj.io/skip-reconcile: "true" 2
          labels:
            apps.open-cluster-management.io/pull-to-ocm-managed-cluster: "true" 3
          name: '{{name}}-guestbook-app'
        spec:
          destination:
            namespace: guestbook
            server: https://kubernetes.default.svc
          project: default
          sources: [
          {
            repoURL: https://github.com/argoproj/argocd-example-apps.git
            targetRevision: main
            path: guestbook
             }
          ]
          syncPolicy:
            automated: {}
            syncOptions:
            - CreateNamespace=true
    1
    Pull 模型需要 apps.open-cluster-management.io/ocm-managed-cluster
    2
    argocd.argoproj.io/skip-reconcile 需要忽略 Push 模型资源。
    3
    Pull 模型还需要 apps.open-cluster-management.io/pull-to-ocm-managed-cluster: "true "。

1.4.4. MulticlusterApplicationSetReport

  • 对于 Pull 模型,MulticlusterApplicationSetReport 聚合受管集群中的应用程序状态。
  • 该报告包括资源列表以及每个受管集群的应用程序的整体状态。
  • 为每个 Argo CD ApplicationSet 资源创建一个单独的报告资源。该报告与 ApplicationSet 在同一命名空间中创建。
  • 该报告包括以下项目:

    1. Argo CD 应用程序的资源列表
    2. 每个 Argo CD 应用程序的整体同步和健康状况
    3. 每个集群的出错信息,其中整个状态为 syncunhealthy
    4. 受管集群的所有状态概述状态
  • 资源同步控制器聚合控制器每 10 秒运行一次,以创建报告。
  • 两个控制器以及 Propagation 控制器,在同一 multicluster-integrations pod 中的独立容器中运行,如下例所示:

    NAMESPACE               NAME                                       READY   STATUS
    open-cluster-management multicluster-integrations-7c46498d9-fqbq4  3/3     Running

以下是 guestbook 应用程序的 MulticlusterApplicationSetReport YAML 文件示例:

apiVersion: apps.open-cluster-management.io/v1alpha1
kind: MulticlusterApplicationSetReport
metadata:
  labels:
    apps.open-cluster-management.io/hosting-applicationset: openshift-gitops.guestbook-allclusters-app-set
  name: guestbook-allclusters-app-set
  namespace: openshift-gitops
statuses:
  clusterConditions:
  - cluster: cluster1
    conditions:
    - message: 'Failed sync attempt: one or more objects failed to apply, reason: services is forbidden: User "system:serviceaccount:openshift-gitops:openshift-gitops-Argo CD-application-controller" cannot create resource "services" in API group "" in the namespace "guestbook",deployments.apps is forbidden: User <name> cannot create resource "deployments" in API group "apps" in the namespace "guestboo...'
      type: SyncError
    healthStatus: Missing
    syncStatus: OutOfSync
  - cluster: pcluster1
    healthStatus: Progressing
    syncStatus: Synced
  - cluster: pcluster2
    healthStatus: Progressing
    syncStatus: Synced
  summary:
    clusters: "3"
    healthy: "0"
    inProgress: "2"
    notHealthy: "3"
    notSynced: "1"
    synced: "2"

注:如果资源无法部署,则资源不会包含在资源列表中。如需更多信息,请参阅错误消息。

1.4.5. 其他资源

1.5. 使用 Red Hat OpenShift GitOps 管理策略定义

使用 ArgoCD 资源,您可以使用 Red Hat OpenShift GitOps 通过授予 OpenShift GitOps 访问权限在 Red Hat Advanced Cluster Management hub 集群上创建策略来管理策略定义。

1.5.1. 前提条件

您必须登录到您的 hub 集群。

需要的访问权限:集群管理员

已弃用: PlacementRule

1.5.2. 为 OpenShift GitOps 创建 ClusterRole 资源

要为 OpenShift GitOps 创建 ClusterRole 资源,可访问创建、读取、更新和删除策略和放置:

  1. 从控制台创建 ClusterRole。您的 ClusterRole 可能类似以下示例:

    kind: ClusterRole
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: openshift-gitops-policy-admin
    rules:
      - verbs:
          - get
          - list
          - watch
          - create
          - update
          - patch
          - delete
        apiGroups:
          - policy.open-cluster-management.io
        resources:
          - policies
          - configurationpolicies
          - certificatepolicies
          - operatorpolicies
          - policysets
          - placementbindings
      - verbs:
          - get
          - list
          - watch
          - create
          - update
          - patch
          - delete
        apiGroups:
          - apps.open-cluster-management.io
        resources:
          - placementrules
      - verbs:
          - get
          - list
          - watch
          - create
          - update
          - patch
          - delete
        apiGroups:
          - cluster.open-cluster-management.io
        resources:
          - placements
          - placements/status
          - placementdecisions
          - placementdecisions/status
  2. 另外,创建一个 ClusterRoleBinding 对象来授予 OpenShift GitOps 服务帐户对 openshift-gitops-policy-admin ClusterRole 对象的访问权限。ClusterRoleBinding 可能类似以下示例:

    kind: ClusterRoleBinding
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: openshift-gitops-policy-admin
    subjects:
      - kind: ServiceAccount
        name: openshift-gitops-argocd-application-controller
        namespace: openshift-gitops
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: ClusterRole
      name: openshift-gitops-policy-admin

    注: - 当使用 OpenShift GitOps 部署 Red Hat Advanced Cluster Management 策略定义时,会在每个受管集群命名空间中创建一个策略副本,以解决 hub 模板的不同。这些副本称为复制策略。- 为了防止 OpenShift GitOps 重复删除此复制策略,或者显示 Argo CD 应用程序 没有同步,argocd.argoproj.io/compare-options:IgnoreExtraneous 注解由 Red Hat Advanced Cluster Management 策略框架自动在每个复制策略上设置。

  3. Argo CD 有用于跟踪对象的标签和注解。对于没有在 Argo CD 中显示复制策略,请在 Red Hat Advanced Cluster Management 策略定义中将 spec.copyPolicyMetadata 设置为 false 来禁用 Argo CD 跟踪标签和注解。

1.5.3. 将策略生成器与 OpenShift GitOps 集成

您可以使用 OpenShift GitOps 通过 GitOps 使用 Policy Generator 生成策略。由于 OpenShift GitOps 容器镜像中没有预安装 Policy Generator,所以您必须完成自定义。

1.5.3.1. 先决条件
  • 您必须在 Red Hat Advanced Cluster Management hub 集群上安装 OpenShift GitOps。
  • 您必须登录到 hub 集群。
1.5.3.2. 从 OpenShift GitOps 访问策略生成器

要从 OpenShift GitOps 访问 Policy Generator,您必须配置 Init 容器,以便从 Red Hat Advanced Cluster Management Application Subscription 容器镜像复制 Policy Generator 二进制文件。您还必须通过在运行 Kustomize 时提供 --enable-alpha-plugins 标志来配置 OpenShift GitOps。

要使用 Policy Generator 创建、读取、更新和删除策略和放置,请授予对 OpenShift GitOps 的 Policy Generator 的访问权限。完成以下步骤:

  1. 使用以下命令编辑 OpenShift GitOps argocd 对象:

    oc -n openshift-gitops edit argocd openshift-gitops
  2. 要将 Policy Generator 更新至较新的版本,请将 Init 容器使用的 registry.redhat.io/rhacm2/multicluster-operators-subscription-rhel9 镜像添加到较新的标签。将 & lt;version > 参数替换为 ArgoCD 资源中的最新 Red Hat Advanced Cluster Management 版本。

    您的 ArgoCD 资源可能类似以下 YAML 文件:

    apiVersion: argoproj.io/v1beta1
    kind: ArgoCD
    metadata:
      name: openshift-gitops
      namespace: openshift-gitops
    spec:
      kustomizeBuildOptions: --enable-alpha-plugins
      repo:
        env:
        - name: KUSTOMIZE_PLUGIN_HOME
          value: /etc/kustomize/plugin
        initContainers:
        - args:
          - -c
          - cp /policy-generator/PolicyGenerator-not-fips-compliant /policy-generator-tmp/PolicyGenerator
          command:
          - /bin/bash
          image: registry.redhat.io/rhacm2/multicluster-operators-subscription-rhel9:v<version>
          name: policy-generator-install
          volumeMounts:
          - mountPath: /policy-generator-tmp
            name: policy-generator
        volumeMounts:
        - mountPath: /etc/kustomize/plugin/policy.open-cluster-management.io/v1/policygenerator
          name: policy-generator
        volumes:
        - emptyDir: {}
          name: policy-generator

    注: 另外,您可以创建一个 ConfigurationPolicy 资源,其中包含 ArgoCD 清单,并模板与 MulticlusterHub 中设置的版本匹配:

    image: '{{ (index (lookup "apps/v1" "Deployment" "open-cluster-management" "multicluster-operators-hub-subscription").spec.template.spec.containers 0).image }}'
  3. 如果要在生成策略前在 Kustomize 目录中启用 Helm chart 处理,请在 spec.repo.env 字段中将 POLICY_GEN_ENABLE_HELM 环境变量设置为 "true"

    env:
    - name: POLICY_GEN_ENABLE_HELM
      value: "true"
  4. 要创建、读取、更新和删除策略和放置,请创建一个 ClusterRoleBinding 对象来授予 OpenShift GitOps 服务帐户对 Red Hat Advanced Cluster Management hub 集群的访问权限。ClusterRoleBinding 可能类似以下资源:

    kind: ClusterRoleBinding
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: openshift-gitops-policy-admin
    subjects:
      - kind: ServiceAccount
        name: openshift-gitops-argocd-application-controller
        namespace: openshift-gitops
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: ClusterRole
      name: openshift-gitops-policy-admin

1.5.4. 在 OpenShift GitOps 中配置策略健康检查

通过 ArgoCD resoure,使用 OpenShift GitOps 为您定义自定义逻辑,根据资源状态决定特定资源的当前健康状况。定义自定义健康检查,以仅在策略合规时报告策略处于健康状态。当您为资源添加健康检查时,您必须在 resourceHealthChecks 字段中将它添加为

重要: 要验证您是否没有从互联网下载恶意的内容,请在应用前检查每个策略。

要为您的资源类型定义健康检查,请完成以下步骤:

  1. 要为您的 CertificatePolicy 资源配置健康检查,请使用以下命令编辑 ArgoCD 资源:

    oc -n openshift-gitops edit argocd openshift-gitops

    您的 ArgoCD 资源可能类似以下 YAML 文件:

    apiVersion: argoproj.io/v1beta1
    kind: ArgoCD
    metadata:
      name: openshift-gitops
      namespace: openshift-gitops
    spec:
      resourceHealthChecks:
        - group: policy.open-cluster-management.io
          kind: CertificatePolicy
          check: |
    	hs = {}
    	if obj.status == nil or obj.status.compliant == nil then
    	  hs.status = "Progressing"
    	  hs.message = "Waiting for the status to be reported"
    	  return hs
    	end
    	if obj.status.compliant == "Compliant" then
    	  hs.status = "Healthy" hs.message = "All certificates found comply with the policy"
    	  return hs
    	else hs.status = "Degraded"
              hs.message = "At least one certificate does not comply with the policy"
    	  return hs
            end
  2. 要在 CertificatePolicy,ConfigurationPolicy,OperatorPolicy, 和 Policy 资源中添加健康检查,请运行以下命令下载 argocd-policy-healthchecks.yaml

    wget https://raw.githubusercontent.com/open-cluster-management-io/policy-collection/main/stable/CM-Configuration-Management/argocd-policy-healthchecks.yaml
  3. 要应用 argocd-policy-healthchecks.yaml 策略,请运行以下命令:

    oc apply -f ./argocd-policy-healthchecks.yaml
  4. 通过查看 ArgoCD 资源的 Summary 选项卡来验证健康检查是否正常工作。从 Argo CD 控制台查看健康详情。

1.5.5. 其他资源

1.6. 生成用于安装 GitOps Operator 的策略

Red Hat Advanced Cluster Management 策略的一个常见用途是在一个或多个受管 Red Hat OpenShift Container Platform 集群上安装 Operator。继续阅读,了解如何使用 Policy Generator 生成策略,并使用生成的策略安装 OpenShift Container Platform GitOps Operator:

1.6.1. 生成安装 OpenShift Container Platform GitOps 的策略

您可以使用 Policy Generator 生成安装 OpenShift Container Platform GitOps 的策略。OpenShift Container Platform GitOps operator 提供了 all namespaces 安装模式,您可以在以下示例中查看。创建名为 openshift-gitops-subscription.yamlSubscription 清单文件,如下例所示:

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: openshift-gitops-operator
  namespace: openshift-operators
spec:
  channel: stable
  name: openshift-gitops-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace

要固定到 Operator 的特定版本,您可以添加以下参数和值: spec.startingCSV: openshift-gitops-operator.v<version>。将 <version> 替换为您的首选版本。

需要 PolicyGenerator 配置文件。使用名为 policy-generator-config.yaml 的配置文件来生成策略,以便在所有 OpenShift Container Platform 受管集群上安装 OpenShift Container Platform GitOps。请参见以下示例:

apiVersion: policy.open-cluster-management.io/v1
kind: PolicyGenerator
metadata:
  name: install-openshift-gitops
policyDefaults:
  namespace: policies
  placement:
    clusterSelectors:
      vendor: "OpenShift"
  remediationAction: enforce
policies:
  - name: install-openshift-gitops
    manifests:
      - path: openshift-gitops-subscription.yaml

最后所需的文件是 kustomization.yaml,它需要以下配置:

generators:
  - policy-generator-config.yaml

生成的策略可能类似以下带有 PlacementRule 的文件(已弃用):

apiVersion: apps.open-cluster-management.io/v1
kind: PlacementRule
metadata:
  name: placement-install-openshift-gitops
  namespace: policies
spec:
  clusterConditions:
    - status: "True"
      type: ManagedClusterConditionAvailable
  clusterSelector:
    matchExpressions:
      - key: vendor
        operator: In
        values:
          - OpenShift
---
apiVersion: policy.open-cluster-management.io/v1
kind: PlacementBinding
metadata:
  name: binding-install-openshift-gitops
  namespace: policies
placementRef:
  apiGroup: apps.open-cluster-management.io
  kind: PlacementRule
  name: placement-install-openshift-gitops
subjects:
  - apiGroup: policy.open-cluster-management.io
    kind: Policy
    name: install-openshift-gitops
---
apiVersion: policy.open-cluster-management.io/v1
kind: Policy
metadata:
  annotations:
    policy.open-cluster-management.io/categories: CM Configuration Management
    policy.open-cluster-management.io/controls: CM-2 Baseline Configuration
    policy.open-cluster-management.io/standards: NIST SP 800-53
    policy.open-cluster-management.io/description:
  name: install-openshift-gitops
  namespace: policies
spec:
  disabled: false
  policy-templates:
    - objectDefinition:
        apiVersion: policy.open-cluster-management.io/v1
        kind: ConfigurationPolicy
        metadata:
          name: install-openshift-gitops
        spec:
          object-templates:
            - complianceType: musthave
              objectDefinition:
                apiVersion: operators.coreos.com/v1alpha1
                kind: Subscription
                metadata:
                  name: openshift-gitops-operator
                  namespace: openshift-operators
                spec:
                  channel: stable
                  name: openshift-gitops-operator
                  source: redhat-operators
                  sourceNamespace: openshift-marketplace
          remediationAction: enforce
          severity: low

支持 OpenShift Container Platform 文档中的从清单生成的策略。OpenShift Container Platform 文档中的任何配置指南都可以使用 Policy Generator 应用。

1.6.2. 使用带有 OperatorGroup 的策略依赖项

当使用 OperatorGroup 清单安装 Operator 时,OperatorGroup 必须在创建 Subscription 前存在于集群中。使用策略依赖项功能以及 Policy Generator 来确保 OperatorGroup 策略在强制实施 订阅 策略前兼容。

通过按您想要的顺序列出清单来设置策略依赖项。例如,您可能想要首先创建命名空间策略,然后创建 OperatorGroup,最后再创建 Subscription

启用 policyDefaults.orderManifests 参数,并在 Policy Generator 配置清单中禁用 policyDefaults.consolidateManifests,以自动设置清单之间的依赖项。

1.7. 为 Argo CD push 模型创建自定义服务帐户

通过在 hub 集群中创建 managedserviceaccount 资源,在受管集群中创建服务帐户。使用 clusterpermission 资源为服务帐户授予特定权限。

创建用于 Argo CD push 模型的 customzied 服务帐户包括以下优点:

  • 应用程序管理器附加组件在每个受管集群上运行。默认情况下,Argo CD 控制器使用服务帐户 Application Manager 将这些资源推送到受管集群。
  • 应用程序管理器服务帐户具有大量权限,因为应用程序订阅附加组件使用应用程序管理器服务在受管集群中部署应用程序。如果您需要一组有限的权限,请不要使用 Application manager 服务帐户。
  • 您可以指定希望 Argo CD 推送模型使用的不同服务帐户。当 Argo CD 控制器将资源从集中式 hub 集群推送到受管集群时,您可以使用与默认应用程序管理器不同的服务帐户。通过使用不同的服务帐户,您可以控制授予此服务帐户的权限。
  • 服务帐户必须存在于受管集群上。要协助创建具有关联权限的服务帐户,请在集中式 hub 集群上使用 managedserviceaccount 资源和新的 clusterpermission 资源。

完成所有以下流程后,您可以为受管服务帐户授予集群权限。具有集群权限,您的受管服务帐户具有在受管集群中部署应用程序资源所需的权限。完成以下步骤:

1.7.1. 创建受管服务帐户

hub 上的 managedserviceaccount 自定义资源提供了一种便捷的方式,可以在受管集群中创建 serviceaccounts。当在 hub 集群上的 < managed_cluster > 命名空间中创建 managedserviceccount 自定义资源时,会在受管集群中创建一个 serviceccount

要创建受管服务帐户,请参阅启用受管服务帐户。

1.7.2. 创建集群权限

创建服务帐户后,它不会关联任何权限。要为新服务帐户授予权限,请使用 clusterpermission 资源。集群permission 资源在 hub 上的受管集群命名空间中创建。它提供在受管集群上创建角色、集群角色资源并通过 rolebindingclusterrolebinding 资源将其绑定到服务帐户的便捷方式。

  1. 要将 &lt ;managed-sa-sample > 服务帐户权限授予部署到 < managed cluster > 上 mortgage 命名空间的示例 mortgage 应用程序,请使用以下内容创建一个 YAML:

    apiVersion: rbac.open-cluster-management.io/v1alpha1
    kind: ClusterPermission
    metadata:
      name: <clusterpermission-msa-subject-sample>
      namespace: <managed cluster>
    spec:
      roles:
      - namespace: default
        rules:
        - apiGroups: ["apps"]
          resources: ["deployments"]
          verbs: ["get", "list", "create", "update", "delete", "patch"]
        - apiGroups: [""]
          resources: ["configmaps", "secrets", "pods", "podtemplates", "persistentvolumeclaims", "persistentvolumes"]
          verbs: ["get", "update", "list", "create", "delete", "patch"]
        - apiGroups: ["storage.k8s.io"]
          resources: ["*"]
          verbs: ["list"]
      - namespace: mortgage
        rules:
        - apiGroups: ["apps"]
          resources: ["deployments"]
          verbs: ["get", "list", "create", "update", "delete", "patch"]
        - apiGroups: [""]
          resources: ["configmaps", "secrets", "pods", "services", "namespace"]
          verbs: ["get", "update", "list", "create", "delete", "patch"]
      clusterRole:
        rules:
        - apiGroups: ["*"]
          resources: ["*"]
          verbs: ["get", "list"]
      roleBindings:
      - namespace: default
        roleRef:
          kind: Role
        subject:
          apiGroup: authentication.open-cluster-management.io
          kind: ManagedServiceAccount
          name: <managed-sa-sample>
      - namespace: mortgage
        roleRef:
          kind: Role
        subject:
          apiGroup: authentication.open-cluster-management.io
          kind: ManagedServiceAccount
          name: <managed-sa-sample>
      clusterRoleBinding:
        subject:
          apiGroup: authentication.open-cluster-management.io
          kind: ManagedServiceAccount
          name: <managed-sa-sample>
  2. 将 YAML 文件保存到名为 cluster-permission.yaml 的文件中。
  3. 运行 oc apply -f cluster-permission.yaml
  4. 示例 & lt;clusterpermission& gt; 在 mortgage 命名空间中创建一个名为 < clusterpermission-msa-subject-sample > 的角色。如果尚不存在,请创建一个命名空间 mortgage
  5. 查看在 < managed cluster&gt; 上创建的资源。

创建示例后,& lt;clusterpermission > 会在示例受管集群中创建以下资源:

  • 在 default 命名空间中,一个名为 < clusterpermission-msa-subject-sample > 的角色。
  • 在 default 命名空间中一个名为 <clusterpermission-msa-subject-sample > 的 roleBinding,用于将角色绑定到受管服务帐户。
  • 在 mortgage 命名空间中,一个名为 < clusterpermission-msa-subject-sample > 的角色。
  • 在 mortgage 命名空间中一个名为 <clusterpermission-msa-subject-sample > 的 roleBinding,用于将角色绑定到受管服务帐户。
  • 一个名为 < clusterpermission-msa-subject-sample > 的 clusterRole。
  • 一个名为 < clusterpermission-msa-subject-sample& gt; 的 clusterRoleBinding 将 clusterRole 绑定到受管服务帐户。

1.7.3. 在 GitOpsCluster 资源中使用受管服务帐户

GitOpsCluster 资源使用放置将所选受管集群导入到 Argo CD 中,包括创建 Argo CD 集群 secret,其中包含用于访问集群的信息。默认情况下,Argo CD 集群 secret 使用应用程序管理器服务帐户来访问受管集群。

  1. 要将 GitOpsCluster 资源更新为使用受管服务帐户,请将 managedServiceAccountRef 属性添加到受管服务帐户的名称。
  2. 将以下示例保存为 gitops.yaml 文件,以创建 GitOpsCluster 自定义资源:

    apiVersion: apps.open-cluster-management.io/v1beta1
    kind: GitOpsCluster
    metadata:
      name: argo-acm-importer
      namespace: openshift-gitops
    spec:
      managedServiceAccountRef: <managed-sa-sample>
      argoServer:
        cluster: notused
        argoNamespace: openshift-gitops
      placementRef:
        kind: Placement
        apiVersion: cluster.open-cluster-management.io/v1beta1
        name: all-openshift-clusters
        namespace: openshift-gitops
  3. 运行 oc apply -f gitops.yaml 以应用该文件。
  4. 进入 openshift-gitops 命名空间,并验证是否有新的 Argo CD 集群 secret,名称为 < managed cluster-managed-sa-sample-cluster-secret>。运行以下命令:

    oc get secrets -n openshift-gitops <managed cluster-managed-sa-sample-cluster-secret>
  5. 请查看以下输出来验证:

    NAME                                        TYPE     DATA   AGE
    <managed cluster-managed-sa-sample-cluster-secret>   Opaque   3      4m2s

1.7.4. 创建 Argo CD 应用程序

使用推送模型从 Argo CD 控制台部署 Argo CD 应用程序。Argo CD 应用程序使用受管服务帐户 < managed-sa-sample > 部署。

  1. 登录到 Argo CD 控制台。
  2. 单击 Create a new application
  3. 选择集群 URL。
  4. 进入 Argo CD 应用程序,验证它具有给定权限,如角色和集群角色,您要传播到 < managed cluster >。

1.7.5. 使用策略创建受管服务帐户和集群权限

When the GitOpsCluster resource is updated with the `managedServiceAccountRef`, each managed cluster in the placement of this GitOpsCluster needs to have the service account. If you have several managed clusters, it becomes tedious for you to create the managed service account and cluster permission for each managed cluster. You can simply this process by using a policy to create the managed service account and cluster permission for all your managed clusters

当您将 managedServiceAccountclusterPermission 资源应用到 hub 集群时,此策略的放置会绑定到本地集群。在 GitOpsCluster 资源放置中,将这些资源复制到所有受管集群的受管集群。

使用策略创建 managedServiceAccountclusterPermission 资源包含以下属性:

  • 在策略中更新 managedServiceAccountclusterPermission 对象模板会导致在所有受管集群中更新所有 managedServiceAccountclusterPermission 资源。
  • 直接更新到 managedServiceAccountclusterPermission 资源会恢复回原始状态,因为它由策略强制执行。
  • 如果 GitOpsCluster 放置更改的放置决定,策略会管理受管集群命名空间中资源的创建和删除。

    1. 要为 YAML 创建策略以创建受管服务帐户和集群权限,请使用以下内容创建一个 YAML:
    apiVersion: policy.open-cluster-management.io/v1
    kind: Policy
    metadata:
      name: policy-gitops
      namespace: openshift-gitops
      annotations:
        policy.open-cluster-management.io/standards: NIST-CSF
        policy.open-cluster-management.io/categories: PR.PT Protective Technology
        policy.open-cluster-management.io/controls: PR.PT-3 Least Functionality
    spec:
      remediationAction: enforce
      disabled: false
      policy-templates:
    
        - objectDefinition:
            apiVersion: policy.open-cluster-management.io/v1
            kind: ConfigurationPolicy
            metadata:
              name: policy-gitops-sub
            spec:
              pruneObjectBehavior: None
              remediationAction: enforce
              severity: low
              object-templates-raw: |
                {{ range $placedec := (lookup "cluster.open-cluster-management.io/v1beta1" "PlacementDecision" "openshift-gitops" "" "cluster.open-cluster-management.io/placement=aws-app-placement").items }}
                {{ range $clustdec := $placedec.status.decisions }}
                - complianceType: musthave
                  objectDefinition:
                    apiVersion: authentication.open-cluster-management.io/v1alpha1
                    kind: ManagedServiceAccount
                    metadata:
                      name: <managed-sa-sample>
                      namespace: {{ $clustdec.clusterName }}
                    spec:
                      rotation: {}
                - complianceType: musthave
                  objectDefinition:
                    apiVersion: rbac.open-cluster-management.io/v1alpha1
                    kind: ClusterPermission
                    metadata:
                      name: <clusterpermission-msa-subject-sample>
                      namespace: {{ $clustdec.clusterName }}
                    spec:
                      roles:
                      - namespace: default
                        rules:
                        - apiGroups: ["apps"]
                          resources: ["deployments"]
                          verbs: ["get", "list", "create", "update", "delete"]
                        - apiGroups: [""]
                          resources: ["configmaps", "secrets", "pods", "podtemplates", "persistentvolumeclaims", "persistentvolumes"]
                          verbs: ["get", "update", "list", "create", "delete"]
                        - apiGroups: ["storage.k8s.io"]
                          resources: ["*"]
                          verbs: ["list"]
                      - namespace: mortgage
                        rules:
                        - apiGroups: ["apps"]
                          resources: ["deployments"]
                          verbs: ["get", "list", "create", "update", "delete"]
                        - apiGroups: [""]
                          resources: ["configmaps", "secrets", "pods", "services", "namespace"]
                          verbs: ["get", "update", "list", "create", "delete"]
                      clusterRole:
                        rules:
                        - apiGroups: ["*"]
                          resources: ["*"]
                          verbs: ["get", "list"]
                      roleBindings:
                      - namespace: default
                        roleRef:
                          kind: Role
                        subject:
                          apiGroup: authentication.open-cluster-management.io
                          kind: ManagedServiceAccount
                          name: <managed-sa-sample>
                      - namespace: mortgage
                        roleRef:
                          kind: Role
                        subject:
                          apiGroup: authentication.open-cluster-management.io
                          kind: ManagedServiceAccount
                          name: <managed-sa-sample>
                      clusterRoleBinding:
                        subject:
                          apiGroup: authentication.open-cluster-management.io
                          kind: ManagedServiceAccount
                          name: <managed-sa-sample>
                {{ end }}
                {{ end }}
    ---
    apiVersion: policy.open-cluster-management.io/v1
    kind: PlacementBinding
    metadata:
      name: binding-policy-gitops
      namespace: openshift-gitops
    placementRef:
      name: lc-app-placement
      kind: Placement
      apiGroup: cluster.open-cluster-management.io
    subjects:
      - name: policy-gitops
        kind: Policy
        apiGroup: policy.open-cluster-management.io
    ---
    apiVersion: cluster.open-cluster-management.io/v1beta1
    kind: Placement
    metadata:
      name: lc-app-placement
      namespace: openshift-gitops
    spec:
      numberOfClusters: 1
      predicates:
      - requiredClusterSelector:
          labelSelector:
            matchLabels:
              name: local-cluster
    1. 将 YAML 文件保存到名为 policy.yaml 的文件中。
    2. 运行 oc apply -f policy.yaml
    3. 在策略的对象模板中,它会迭代 GitOpsCluster 关联的放置决策,并应用以下 managedServiceAccountclusterPermission 模板:

法律通告

Copyright © 2024 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.