1.14. Red Hat OpenShift GitOps 1.9.0 发行注记


Red Hat OpenShift GitOps 1.9.0 现在包括在 OpenShift Container Platform 4.12 和 4.13 中。

1.14.1. 勘误更新

发布日期:2023 年 6 月 9 日

此发行版本中包括的安全修复列表包括在以下公告中:

如果安装了 Red Hat OpenShift GitOps Operator,请运行以下命令来查看此发行版本中的容器镜像:

$ oc describe deployment gitops-operator-controller-manager -n openshift-operators
Copy to Clipboard Toggle word wrap

1.14.2. 新功能

当前发行版本包括以下改进:

  • 在这个版本中,您可以使用自定义 must-gather 工具来收集有关项目级别资源、集群级别资源和 Red Hat OpenShift GitOps 组件的诊断信息。此工具提供有关与 Red Hat OpenShift GitOps 关联的集群的调试信息,您可以与红帽支持团队共享以进行分析。GITOPS-2797

    重要

    自定义 must-gather 工具是一个技术预览功能。

  • 在这个版本中,您可以使用 Argo Rollouts 为进度交付添加支持。目前,支持的流量管理器只是 Red Hat OpenShift Service Mesh。GITOPS-959

    重要

    Argo Rollouts 是一个技术预览功能。

1.14.3. 弃用和删除的功能

  • 在 Red Hat OpenShift GitOps 1.7.0 中,.spec.resourceCustomizations 参数已弃用。弃用的 .spec.resourceCustomizations 参数计划在以后的 Red Hat OpenShift GitOps GA v1.10.0 发行版本中删除。您可以使用新格式 spec.ResourceHealthChecksspec.ResourceIgnoreDifferencesspec.ResourceActionsGITOPS-2890
  • 在这个版本中,对以下已弃用的 ssodex 字段的支持会扩展,直到即将发布的 Red Hat OpenShift GitOps GA v1.10.0 版本为止:

    • .spec.sso.image.spec.sso.version.spec.sso.resources.spec.sso.verifyTLS 字段。
    • .spec.dex 参数以及 DISABLE_DEX

      在之前的计划中,弃用的 ssodex 字段将在 Red Hat OpenShift GitOps v1.9.0 发行版本中删除,现在计划在以后的 Red Hat OpenShift GitOps GA v1.10.0 发行版本中删除。GITOPS-2904

1.14.4. 修复的问题

在当前发行版本中解决了以下问题:

  • 在此次更新之前,当使用新证书 Argo CD 更新 argocd-server-tls secret 时,并不总是获取这个 secret。因此,会显示旧的过期证书。在这个版本中,新的 GetCertificate 功能解决了这个问题,并确保使用最新版本的证书。现在,当添加新证书时,Argo CD 会自动选择它们,而无需重启 argocd-server pod。GITOPS-2375
  • 在此次更新之前,当针对指向签名 Git 标签的 targetRevision 整数强制 GPG 签名验证时,用户会得到一个 Target revision in Git is not signed 错误。在这个版本中解决了这个问题,用户可以对签名的 Git 标签强制进行 GPG 签名验证。GITOPS-2418
  • 在此次更新之前,用户无法通过 Operator 部署的 Argo CD 连接到 Microsoft Team Foundation Server (TFS) 类型 Git 存储库。在这个版本中,通过将 Git 版本更新至 Operator 中的 2.39.3 解决了这个问题。GITOPS-2768
  • 在此次更新之前,当 Operator 部署并在启用了 High Availability (HA) 功能的情况下运行时,在 .spec.ha.resources 字段下设置资源限值不会影响 Redis HA pod。在这个版本中,通过在 Redis 协调代码中添加检查来解决协调的问题。这些检查可确保 Argo CD 自定义资源 (CR) 中的 spec.ha.resources 字段是否已更新。当使用新的 CPU 和内存请求或限制值 HA 更新 Argo CD CR 时,这些更改会应用到 Redis HA pod。GITOPS-2404
  • 在此次更新之前,如果命名空间范围的 Argo CD 实例使用 managed-by 标签管理多个命名空间,并且其中一个受管命名空间处于 Terminating 状态,Argo CD 实例将无法将资源部署到所有其他受管命名空间中。在这个版本中,启用 Operator 从之前管理的任何受管标签中删除 managed-by 标签,现在会终止命名空间。现在,由命名空间范围的 Argo CD 实例管理的终止命名空间不会阻止资源部署到其他受管命名空间中。GITOPS-2627

1.14.5. 已知问题

  • 目前,Argo CD 不会从 argocd-tls-certs-cm 配置映射中指定的路径中读取传输层安全 (TLS) 证书,从而导致 x509: certificate signed by unknown authority 错误。

    临时解决方案:执行以下步骤:

    1. 添加 SSL_CERT_DIR 环境变量:

      Argo CD 自定义资源示例

      apiVersion: argoproj.io/v1alpha1
      kind: ArgoCD
      metadata:
        name: example-argocd
        labels:
          example: repo
      spec:
        # ...
        repo:
          env:
            - name: SSL_CERT_DIR
              value: /tmp/sslcertdir
          volumeMounts:
            - name: ssl
              mountPath: /tmp/sslcertdir
          volumes:
            - name: ssl
              configMap:
                name: user-ca-bundle
        # ...
      Copy to Clipboard Toggle word wrap

    2. 在存在 Operator 订阅的命名空间中创建一个空配置映射,并包括以下标签:

      配置映射示例

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: user-ca-bundle 
      1
      
        labels:
          config.openshift.io/inject-trusted-cabundle: "true" 
      2
      Copy to Clipboard Toggle word wrap

      1
      配置映射的名称。
      2
      请求 Cluster Network Operator 注入合并的捆绑包。

      创建此配置映射后,openshift-config 命名空间中的 user-ca-bundle 内容会自动注入到此配置映射中,即使与系统 ca-bundle 合并也是如此。GITOPS-1482

返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

Theme

© 2025 Red Hat