第 5 章 GitOps

目前，Red Hat OpenShift GitOps 1.8.4 不适用于 OpenShift Container Platform 4.10 和 4.11 的 latest 频道。latest 频道由 GitOps 1.9.z 获取，它只在 OpenShift Container Platform 4.12 及更新的版本中发布。

作为临时解决方案，切换到 gitops-1.8 频道来获取新的更新。GITOPS-3158

在此次更新之前，当使用 .spec.dex 参数配置 Dex 时，并尝试使用 LOG IN VIA OPENSHIFT 选项登录到 Argo CD UI，您将无法登录。在这个版本中解决了这个问题。

在这个版本中，您可以添加 ApplicationSet Progressive Rollout 策略功能的支持。使用此功能，您可以在修改 ApplicationSet spec 或 Application 模板后，增强 ArgoCD ApplicationSet 资源，以便为进度应用程序资源更新嵌入推出部署策略。当您启用此功能时，应用程序会以声明性顺序更新，而不是同时更新。GITOPS-956

在这个版本中，Red Hat OpenShift GitOps Operator 和 kam CLI 可用于 OpenShift Container Platform 上的 ARM 架构。GITOPS-1688

在这个版本中，您可以使用 Argo CD CR 将命令参数传递给存储库服务器部署。GITOPS-2445

例如：

apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
spec:
  repo:
    extraRepoCommandArgs:
      - --max.combined.directory.manifests.size
      - 10M

在此次更新之前，您只能在 openshift-gitops-repo-server pod 中设置 ARGOCD_GIT_MODULES_ENABLED 环境变量，而不是在 ApplicationSet Controller pod 中设置。因此，在使用 Git 生成器时，Git 子模块会在生成子应用程序时克隆，因为 ApplicationSet Controller 环境中缺少变量。另外，如果在 ArgoCD 中没有配置克隆这些子模块所需的凭证，应用程序生成会失败。在这个版本中解决了这个问题，您可以使用 Argo CD CR 将任何环境变量（如 ArgoCD_GIT_MODULES_ENABLED ）添加到 ApplicationSet Controller pod 中。然后 ApplicationSet Controller pod 从克隆的存储库中成功生成子应用程序，且进程中没有克隆子模块。GITOPS-2399

例如：

apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
  labels:
    example: basic
spec:
  applicationSet:
    env:
     - name: ARGOCD_GIT_MODULES_ENABLED
       value: "true"

在这个版本中，您可以使用以下附加子键自定义资源行为：

GITOPS-1561

在这个版本中，您可以在同一集群中的任何命名空间中创建由同一 control plane Argo CD 实例管理的应用程序。作为管理员，执行以下操作以启用此更新：

在这个版本中，Argo CD 支持 Server-Side Apply 功能，这有助于用户执行以下任务：

在此次更新之前，当使用不受证书颁发机构签名的证书设置时，将无法验证 RHSSO 证书。在这个版本中解决了这个问题，您可以提供一个自定义证书，它会在与它通信时验证 Keycloak 的 TLS 证书。您可以将 rootCA 添加到 Argo CD 自定义资源 .spec.keycloak.rootCA 字段中。Operator 使用 PEM 编码的 root 证书协调此更改并更新 argocd-cm ConfigMap 中的 oidc.config 字段。GITOPS-2214

例如：

apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
  labels:
    example: basic
spec:
  sso:
    provider: keycloak
    keycloak:
     rootCA: |
       ---- BEGIN CERTIFICATE ----
       This is a dummy certificate
       Please place this section with appropriate rootCA
       ---- END CERTIFICATE ----
  server:
    route:
      enabled: true

Red Hat OpenShift GitOps Operator 可以在 Dex 之外通过 OIDC 使用 RHSSO (KeyCloak)。但是，在应用了最新的安全修复程序时，在某些情况下无法验证 RHSSO 证书。GITOPS-2214

作为临时解决方案，请在 ArgoCD 规格中禁用 OIDC (Keycloak/RHSSO) 端点的 TLS 验证。

在此次更新之前，当使用不受证书颁发机构签名的证书设置时，将无法验证 RHSSO 证书。在这个版本中解决了这个问题，您可以提供一个自定义证书，它会在与它通信时验证 Keycloak 的 TLS 证书。您可以将 rootCA 添加到 Argo CD 自定义资源 .spec.keycloak.rootCA 字段中。Operator 使用 PEM 编码的 root 证书协调此更改并更新 argocd-cm ConfigMap 中的 oidc.config 字段。GITOPS-2214

例如：

apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
  labels:
    example: basic
spec:
  sso:
    provider: keycloak
    keycloak:
     rootCA: |
       ---- BEGIN CERTIFICATE ----
       This is a dummy certificate
       Please place this section with appropriate rootCA
       ---- END CERTIFICATE ----
  server:
    route:
      enabled: true

Red Hat OpenShift GitOps Operator 可以使用带有 OIDC 和 Dex 的 RHSSO (KeyCloak)。但是，在应用了最新的安全修复程序时，Operator 无法验证 RHSSO 证书。GITOPS-2214

作为临时解决方案，请在 ArgoCD 规格中禁用 OIDC (Keycloak/RHSSO) 端点的 TLS 验证。

apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
spec:
  extraConfig:
    "admin.enabled": "true"
...

在这个版本中，Operator 将 Red Hat Single Sign-On(RH-SSO)更新至 v7.5.1 版本，包括以下改进：

在这个版本中，一个新的 .host URL 字段添加到 Argo CD 操作对象的 .status 字段中。当为路由启用了路由或入口时，新的 URL 字段会显示路由。如果没有从路由或入口提供 URL，则不会显示 .host 字段。

当配置了路由或入口时，但对应的控制器没有正确设置，且不是 Ready 状态，也不会传播其 URL，操作对象中的 .status.host 字段的值表示为 Pending 而不是显示 URL。这会影响操作对象的整体状态，方法是将其设置为 Pending 而不是 Available。GITOPS-654

在此次更新之前，当使用不受证书颁发机构签名的证书设置时，将无法验证 RHSSO 证书。在这个版本中解决了这个问题，您可以提供一个自定义证书，它会在与它通信时验证 Keycloak 的 TLS 证书。您可以将 rootCA 添加到 Argo CD 自定义资源 .spec.keycloak.rootCA 字段中。Operator 使用 PEM 编码的 root 证书协调此更改并更新 argocd-cm ConfigMap 中的 oidc.config 字段。GITOPS-2214

例如：

apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
  labels:
    example: basic
spec:
  sso:
    provider: keycloak
    keycloak:
     rootCA: |
       ---- BEGIN CERTIFICATE ----
       This is a dummy certificate
       Please place this section with appropriate rootCA
       ---- END CERTIFICATE ----
  server:
    route:
      enabled: true

Red Hat OpenShift GitOps Operator 可以使用带有 OIDC 和 Dex 的 RHSSO (KeyCloak)。但是，在应用了最新的安全修复程序时，Operator 无法验证 RHSSO 证书。GITOPS-2214

作为临时解决方案，请在 ArgoCD 规格中禁用 OIDC (Keycloak/RHSSO) 端点的 TLS 验证。

apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
spec:
  extraConfig:
    "admin.enabled": "true"
...

Red Hat OpenShift GitOps Operator v1.4.0 引入了一个回归问题，它从以下 CRD 的 spec 中删除描述字段：

以管理用户身份，当使用 argocd.argoproj.io/managed-by 标签为命名空间提供 Argo CD 访问权限时，它会假定 namespace-admin 权限。这些特权是管理员向非管理员用户提供命名空间（如开发团队）的问题，因为特权使非管理员用户能够修改网络策略等对象。

在这个版本中，管理员可以为所有受管命名空间配置通用集群角色。在 Argo CD 应用程序控制器的角色绑定中，Operator 指的是 CONTROLLER_CLUSTER_ROLE 环境变量。在 Argo CD 服务器的角色绑定中，Operator 指的是 SERVER_CLUSTER_ROLE 环境变量。如果这些环境变量包含自定义角色，Operator 不会创建默认的 admin 角色。相反，它将现有自定义角色用于所有受管命名空间。GITOPS-1290

如果从 Dex 验证供应商迁移到 Keycloak 供应商，您可能会遇到 Keycloak 的登录问题。

要防止这个问题，在迁移时，从 Argo CD 自定义资源中删除 .spec.dex 部分来卸载 Dex。等待几分钟，让 Dex 完全卸载。然后，通过将 .spec.sso.provider: keycloak 添加到 Argo CD 自定义资源来安装 Keycloak。

作为临时解决方案，通过删除 .spec.sso.provider: keycloak 来卸载 Keycloak。然后重新安装它。GITOPS-1450,GITOPS-1331

当使用 Namespace-scoped Argo CD 实例时，例如：一个没有限定到集群中的所有命名空间的 Argo CD 实例，Red Hat OpenShift GitOps 会动态维护一个受管命名空间列表。这些命名空间包括 argocd.argoproj.io/managed-by 标签。此命名空间列表存储在 Argo CD Settings Clusters "in-cluster" NAMESPACES 的缓存中。在此次更新之前，如果您删除了其中一个命名空间，Operator 会忽略该命名空间，命名空间会保留在列表中。这个行为会破坏集群配置中的 CONNECTION STATE，所有同步尝试都会导致错误。例如：

Argo service account does not have <random_verb> on <random_resource_type> in namespace <the_namespace_you_deleted>.

这个程序错误已被解决。GITOPS-1521

GitOps Operator 现在符合最新 Operator-SDK 推荐的命名约定：

从 Dex 身份验证供应商迁移到 Keycloak 提供程序时，您可能会遇到 Keycloak 登录问题。GITOPS-1450

为防止上述问题，在迁移时，通过删除 Argo CD 自定义资源中找到的 .spec.dex 部分来卸载 Dex。等待几分钟以便 Dex 完全卸载，然后通过将 .spec.sso.provider: keycloak 添加到 Argo CD 自定义资源来继续安装 Keycloak。

作为临时解决方案，通过删除 .spec.sso.provider: keycloak 来卸载 Keycloak，然后重新安装。

Argo CD 身份验证现已与红帽 SSO 集成，并在集群中自动配置 OpenShift 4 身份提供商。此功能默认为禁用。要启用红帽 SSO，请在 ArgoCD CR 中添加 SSO 配置，如下所示。目前，keycloak 是唯一受支持的提供程序。

apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
  labels:
    example: basic
spec:
  sso:
    provider: keycloak
  server:
    route:
     enabled: true

现在，您可以使用路由标签定义主机名来支持路由器分片。现在，支持在 server (argocd server)、grafana 和 prometheus 路由上设置标签。要在路由上设置标签，请在 ArgoCD CR 中的服务器的路由配置下添加标签。

apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
  labels:
    example: basic
spec:
  server:
    route:
     enabled: true
     labels:
       key1: value1
       key2: value2

Red Hat OpenShift GitOps 1.2 中的 openshift-gitops 命名空间中启用了资源配额。这会影响手动部署的带外工作负载，以及 openshift-gitops 命名空间中默认 Argo CD 实例部署的工作负载。当您从 Red Hat OpenShift GitOps v1.1.2 升级到 v1.2 时，此类工作负载必须使用资源请求和限制来配置。如果存在额外的工作负载，则必须增加 openshift-gitops 命名空间中的资源配额。

openshift-gitops 命名空间的当前资源配额。

您可以使用以下命令来更新 CPU 限值。

$ oc patch resourcequota openshift-gitops-compute-resources -n openshift-gitops --type='json' -p='[{"op": "replace", "path": "/spec/hard/limits.cpu", "value":"9000m"}]'

您可以使用以下命令来更新 CPU 请求。

$ oc patch resourcequota openshift-gitops-compute-resources -n openshift-gitops --type='json' -p='[{"op": "replace", "path": "/spec/hard/cpu", "value":"7000m"}]

您可以替换以上命令中的路径从 cpu 到 memory 来更新内存。