第 5 章 GitOps

在此次更新之前，在使用未由证书颁发机构签名的证书设置时，将无法验证 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 字段中。当使用提供给路由的优先级启用路由或 ingress 时，新 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 来更新内存。