v2.14 to 3.0

v2.14 to 3.0

Argo CD v2.14 에서 3.0 으로 업그레이드할 때 알아야 할 내용입니다. 3.0 은 대체로 위험이 낮은 업그레이드지만 몇 가지 소수의 breaking change 가 있어요.

출처: 문서

본문

Argo CD 3.0 은 소수의 경미한 breaking change 만 포함하는 저위험 업그레이드로 설계되었습니다. 각 변경에 대해 다음 섹션은 영향받았는지 빠르게 판단하는 방법, breaking change 를 해결하는 방법, (해당된다면) Argo CD 2.x 기본 동작을 복원하는 방법을 설명합니다.

3.0 이 릴리스되면 더 이상 2.x 마이너 버전이 릴리스되지 않습니다. 가장 최근 두 마이너 버전에 대해서는 패치 릴리스를 계속 제공합니다(따라서 3.2 가 릴리스될 때까지 2.14, 3.1 이 릴리스될 때까지 2.13).

GitHub 에 릴리스 노트가 없는 이미지 (Images missing release notes on GitHub)

중요

3.0.7 - 3.0.10 이미지에는 GitHub 에 릴리스 노트가 없습니다. GoReleaser 와 darwin CLI 빌드에 문제가 있어 릴리스 노트 게시가 막혔습니다. 자세한 정보는 PR #23507 에서 확인할 수 있어요.

Breaking Changes

애플리케이션 update 와 delete 하위 리소스에 대한 세분화된 RBAC (Fine-Grained RBAC for application update and delete sub-resources)

세분화된 정책(fine-grained policies) 의 기본 동작이 변경되어 더 이상 하위 리소스에 적용되지 않습니다. v3 이전에는 애플리케이션에 update 또는 delete 를 부여하는 정책이 그 하위 리소스에도 적용되었습니다.

v3 부터 update 또는 delete 액션은 애플리케이션 자체에만 적용됩니다. Application 의 관리 리소스에 대해 update/* 또는 delete/* 액션을 허용하려면 새 정책을 정의해야 해요.

v2 동작을 유지하려면 Argo CD ConfigMap argocd-cm 에서 구성 값 server.rbac.disableApplicationFineGrainedRBACInheritance 를 false 로 설정하면 됩니다.

더 자세한 정보는 RBAC 문서 에서 확인하세요.

로그 RBAC 를 일급 RBAC 요소로 적용 (Logs RBAC enforcement as a first-class RBAC citizen)

2.4 에서 logs 를 새 RBAC 리소스로 도입했습니다. 2.3 이하에서는 applications, get 접근이 있는 사용자가 자동으로 로그 접근을 얻었습니다. 2.4 에서는 argocd-cm ConfigMap 의 플래그로 로그 RBAC 적용을 활성화할 수 있게 됐습니다:

server.rbac.log.enforce.enable: 'true'

3.0 부터 이 플래그는 제거되고 로그 RBAC 는 기본적으로 적용됩니다. 즉 logs 탭이 pod 뷰에서 보이려면 필요로 하는 사용자/그룹/역할에 명시적 logs, get 권한을 부여해야 합니다.

감지 (Detection)

argocd-cm ConfigMap 에 server.rbac.log.enforce.enable: "true" 가 있는 사용자는 이 변경의 영향을 받지 않습니다.

argocd-rbac-cm ConfigMap 에 policy.default: role:readonly 또는 policy.default: role:admin 이 있는 사용자는 영향받지 않습니다.

argocd-rbac-cm ConfigMap 에 policy.default 가 없고, argocd-cm ConfigMap 에 server.rbac.log.enforce.enable 을 false 로 설정했거나 아예 없는 사용자는 영향을 받으며 아래 해결 단계를 수행해야 합니다.

업그레이드 후에는 업그레이드 전에 있었다면 argocd-cm ConfigMap 에서 server.rbac.log.enforce.enable 설정을 제거하는 것을 권장합니다.

해결 (Remediation)

빠른 해결 (전역 변경)

커스텀 역할로 기존 기본 정책이 있는 사용자는 커스텀 역할에 대해 policy.csv 에 다음 정책을 추가하세요: p, role:<YOUR_DEFAULT_ROLE>, logs, get, */*, allow. 기본 정책이 없는 사용자는 policy.csv 에 다음 정책을 추가하세요: p, role:global-log-viewer, logs, get, */*, allow 그리고 이 역할에 대한 기본 정책을 추가합니다: policy.default: role:global-log-viewer

권장 해결 (정책별 변경)

applications, get 또는 applications, * 정책이 있는 모든 역할에 logs, get 정책을 명시적으로 추가하세요. 최소 권한 원칙을 유지하는 권장 방법입니다. Applications 접근을 관리하는 방식과 유사하게, 로그 접근도 Project 스코프 수준(Project 리소스) 또는 argocd-rbac-cm ConfigMap 수준에서 부여할 수 있어요. 자세한 내용은 이 예시 를 참고하세요.

기본 resource.exclusions 구성 (Default resource.exclusions configurations)

Argo CD 매니페스트는 이제 argocd-cm 에 resource.exclusions 기본 구성을 포함해, 컨트롤러가 생성하고 일반적으로 Git 에서 관리하지 않는 것으로 알려진 리소스를 제외합니다. 제외에는 볼륨이 많고 변경(churn) 이 잦은 오브젝트가 포함되며, 성능 이유로 제외해 관리 클러스터의 K8s API 서버로 가는 연결과 부하를 줄입니다.

제외된 Kinds:

• Kubernetes 리소스: Endpoints, EndpointSlice, Lease, SelfSubjectReview, TokenReview, LocalSubjectAccessReview, SelfSubjectAccessReview, SelfSubjectRulesReview, SubjectAccessReview, CertificateSigningRequest, PolicyReport 와 ClusterPolicyReport.

• Cert Manager: CertificateRequest.

• Kyverno: EphemeralReport, ClusterEphemeralReport, AdmissionReport, ClusterAdmissionReport, BackgroundScanReport, ClusterBackgroundScanReport 와 UpdateRequest.

• Cilium: CiliumIdentity, CiliumEndpoint 와 CiliumEndpointSlice.

기본 resource.exclusions 는 configMap 에서 오버라이드하거나 제거해 v2 동작을 유지할 수 있어요.

resource.exclusions 구성에 대한 자세한 내용은 Declarative Setup 을 참고하세요.

argocd_app_sync_status, argocd_app_health_status 와 argocd_app_created_time 메트릭 제거 (Removal of metrics)

argocd_app_sync_status, argocd_app_health_status, argocd_app_created_time 은 1.5.0 부터 기본적으로 deprecated 되고 비활성화되었으며, 이제 제거되었습니다. 이 메트릭들이 이전에 제공했던 정보는 이제 argocd_app_info 메트릭의 레이블로 제공됩니다.

감지 (Detection)

1.5.0 부터 이 메트릭들은 ARGOCD_LEGACY_CONTROLLER_METRICS 가 명시적으로 true 로 설정된 경우에만 사용할 수 있습니다. true 로 설정되지 않았다면 변경 없이 안전하게 업그레이드할 수 있습니다.

마이그레이션 (Migration)

이 메트릭들을 사용하고 있다면, 업그레이드 전에 모니터링 대시보드와 알림을 새 메트릭과 레이블을 사용하도록 업데이트해야 합니다.

Dex SSO 인증에서 RBAC 변경 (Changes to RBAC with Dex SSO Authentication)

Dex 를 사용할 때 인증에서 반환된 sub 클레임이 RBAC 의 subject 로 사용되었습니다. 그 값은 Dex 내부 구현에 의존하며 subject 를 나타내는 불변 값으로 간주해서는 안 됩니다.

새 동작은 Dex 에 federated:id 스코프를 요청하며, RBAC subject 로 사용되는 새 값은 sub 클레임 대신 federated_claims.user_id 클레임에 기반하게 됩니다.

RBAC 정책에서 Dex sub 클레임을 사용하고 있었다면, 동일한 접근을 유지하도록 업데이트해야 합니다.

정책에 정의된 현재 sub 클레임을 디코딩하면 사용할 올바른 user_id 를 알 수 있습니다. 일부 커넥터에서 user_id 로 사용되는 값을 구성할 수도 있어요.

$> echo "ChdleGFtcGxlQGFyZ29wcm9qLmlvEgJkZXhfY29ubl9pZA" | base64 -d

[email protected]_conn_i%

# Dex sub 클레임 기반 정책 (잘못됨)
- g, ChdleGFtcGxlQGFyZ29wcm9qLmlvEgJkZXhfY29ubl9pZA, role:example
- p, ChdleGFtcGxlQGFyZ29wcm9qLmlvEgJkZXhfY29ubl9pZA, applications, *, *, allow

# 이제 federated_claims.user_id 클레임 기반 정책 (올바름)
- g, [email protected], role:example
- p, [email protected], applications, *, *, allow

CLI 로 인증한다면 적절한 클레임이 있는 인증 토큰을 얻기 위해 새 버전도 사용해야 합니다.

argocd-cm 의 레거시 repo 구성 지원 제거 (Removed support for legacy repo config in argocd-cm)

리포지토리가 Secret 으로 관리되기 전에는 argocd-cm ConfigMap 에 구성되었습니다. argocd-cm 옵션은 한동안 deprecated 되어 있었고 Argo CD 3.0 에서 더 이상 사용할 수 없습니다.

감지 (Detection)

argocd-cm 에 구성된 리포지토리가 있는지 확인하려면 다음 명령어를 실행하세요:

kubectl get cm argocd-cm -n argocd -o=jsonpath="[{.data.repositories}, {.data['repository\.credentials']}, {.data['helm\.repositories']}]"

argocd-cm 에 구성된 리포지토리가 없다면 출력이 [, , ] 이며 이 변경의 영향을 받지 않습니다.

마이그레이션 (Migration)

리포지토리를 Secret 으로 변환하려면 리포지토리의 선언적 관리 문서를 따르세요.

ApplicationSet applyNestedSelectors 필드 무시 (Ignoring ApplicationSet applyNestedSelectors field)

ApplicationSet 에 spec.applyNestedSelectors 필드를 설정하는 것은 중첩 선택자(nested selectors) 의 필터가 적용되지 않는 직관에 반하는 동작을 해결했습니다. Argo CD 3.0 부터 이 필드는 무시되며 동작은 항상 applyNestedSelectors 가 true 로 설정된 것과 같습니다. 즉 중첩 선택자는 항상 적용됩니다.

감지 (Detection)

영향받는지 감지하려면 ApplicationSet 컨트롤러 로그에서 ignoring nested selector 문자열을 검색하세요. 이 문자열의 로그가 없다면 영향받지 않습니다.

영향 여부를 감지하는 또 다른 방법은 다음 명령어를 실행하는 것입니다:

kubectl get appsets -o=json | jq -r '.items[] | select(
    .spec.applyNestedSelectors != true and
    .spec.generators[][].generators[][].generators[].selector != null
  ) | .metadata.name'

이 명령어는 applyNestedSelectors 가 설정되지 않았거나 false 이고 중첩 선택자가 하나 이상 있는 ApplicationSet 의 이름을 출력합니다.

해결 (Remediation)

applyNestedSelectors 는 기본적으로 false 이므로, applyNestedSelectors 가 명시적으로 true 로 설정되지 않은 ApplicationSet 에서 중첩 선택자를 안전하게 제거할 수 있습니다. 선택자를 제거한 후에는 안전하게 업그레이드할 수 있어요.

예를 들어 이 ApplicationSet 에서 Argo CD 3.0 으로 업그레이드하기 전에 선택자를 제거해야 합니다.

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: guestbook
spec:
  goTemplate: true
  goTemplateOptions: ["missingkey=error"]
  generators:
  - matrix:
      mergeKeys: ['test-key']
      generators:
      - list:
          elements:
          - test-key: 'test-value'
            cluster: staging
          - test-key: 'test-value'
            cluster: production
      - merge:
          generators:
          - list:
              elements:
              - another-key: 'another-value'
          - cluster: {}
-           selector:
-             matchLabels:
-               app: guestbook

  template:
    metadata:
      name: '{{.cluster}}-guestbook'
    spec:
      project: my-project
      source:
        repoURL: https://github.com/infra-team/cluster-deployments.git
        targetRevision: HEAD
        path: guestbook/{{.cluster}}
      destination:
        server: '{{.url}}'
        namespace: guestbook

breaking change 와 함께 업그레이드된 Helm 버전 (Upgraded Helm version with breaking changes)

Helm 이 3.17.1 로 업그레이드되었습니다. values.yaml 에 null 오브젝트가 있는 섹션이 포함되어 있다면 서브차트에 대한 values.yaml 파일을 변경해야 할 수 있습니다. Helm GitHub 리포지토리의 관련 이슈 와 Helm 3.17.1 릴리스 노트 를 참고하세요. 그러한 문제와 해결의 예시 입니다.

설명:

• Helm 3.17.1 이전에는 values.yaml 의 null 오브젝트가 helm template 수행 시 cannot overwrite table with non table 경고를 발생시키고, 결과 K8s 오브젝트는 유효하지 않은 null 값으로 오버라이드되지 않았습니다.

• Helm 3.17.1 에서 이 동작이 변경되어 values.yaml 의 null 오브젝트가 여전히 helm template 수행 시 이 경고를 발생시키지만, 결과 K8s 오브젝트는 유효하지 않은 null 값으로 오버라이드됩니다.

• 문제를 해결하려면 null 오브젝트 값이 있는 values.yaml 을 식별하고 해당 null 값을 제거하세요.

기본적으로 annotation 기반 추적 사용 (Use Annotation-Based Tracking by Default)

리소스 추적 의 기본 동작이 label 기반 추적 대신 annotation 기반 추적을 사용하도록 변경되었습니다. Annotation 기반 추적은 더 신뢰할 수 있고 외부 코드가 추적 레이블을 한 리소스에서 다른 리소스로 복사하여 발생하는 오류에 덜 취약합니다.

감지 (Detection)

영향을 받는지 감지하려면 argocd-cm ConfigMap 에서 application.resourceTrackingMethod 필드를 확인하세요. 설정되지 않았거나 label 로 설정되어 있다면 label 기반 추적을 사용하는 것입니다. annotation 으로 설정되어 있다면 이미 annotation 기반 추적을 사용하는 것이므로 이 변경의 영향을 받지 않습니다.

kubectl get cm argocd-cm -n argocd -o jsonpath='{.data.application\.resourceTrackingMethod}'

label 기반 추적을 사용한다면 ApplyOutOfSyncOnly=true syncOptions 를 사용하는 Application 이 있는지 감지하는 것도 중요합니다. 그런 Application 은 annotation 추적 방식으로 전환한 뒤 고아(orphan) 리소스가 생길 가능성이 높아 업그레이드 직후 명시적으로 동기화해야 합니다.

그런 Application 이 있는지 감지하려면 다음을 실행하세요:

kubectl get applications.argoproj.io -A -o json | jq -r '.items[] | select(.spec.syncPolicy.syncOptions[]? == "ApplyOutOfSyncOnly=true") | .metadata.name'

해결 (Remediation)

ApplyOutOfSyncOnly=true syncOptions 와 label 기반 추적을 사용하는 사용자

label 기반 추적과 ApplyOutOfSyncOnly=true syncOptions 를 가진 Application 을 사용하는 사용자는 업그레이드 후 그 Application 에 대해 명시적 sync 를 실행해야 합니다. Argo CD API에 토큰을 얻은 뒤 실행할 수 있는 예시 명령어는 다음과 같습니다:

curl -X POST -H "Authorization: Bearer ***" -H "Content-Type: application/json" -d '{
    "name": "$YOUR_APP_NAME"
  }' "http://$YOUR_ARGOCD_URL/api/v1/applications/$YOUR_APP_NAME/sync"

UI 에서 ApplyOutOfSyncOnly 옵션을 체크 해제하고 그런 Application 을 동기화하는 것도 가능합니다. 그러나 현재 CLI 로는 ApplyOutOfSyncOnly 옵션 없이 sync 를 수행하는 것이 불가능합니다.

기타 사용자 (Other users)

대부분의 사용자는 Argo CD 3.0 으로 업그레이드하고 annotation 기반 추적을 사용하는 것이 안전합니다. 레이블은 다음 sync 에서 annotation 으로 교체됩니다. 리소스에 레이블이 없어도 Application 이 out-of-sync 로 표시되지는 않습니다.

경고

고아 리소스 가능성

label 기반 추적에서 annotation 기반 추적으로 전환할 때 리소스가 고아가 될 수 있는 알려진 엣지 케이스가 있습니다. annotation 기반 추적 전환 후 첫 sync 연산에 삭제되는 리소스가 포함되어 있으면, Argo CD 가 그 리소스가 Application 이 관리하는 것임을 인식하지 못해 삭제하지 않습니다. 이 엣지 케이스를 피하려면, out of sync 가 아니더라도 Application 에 sync 연산을 수행해 다음 sync 에서 고아 리소스 감지가 예상대로 동작하게 하는 것을 권장합니다.

3.0 버전으로 업그레이드한 후 Argo CD 추적 annotation 은 새 Git 커밋이 만들어지거나 Application 이 명시적으로 동기화될 때만 Application 의 리소스에 나타납니다.

Argo CD 가 관리하지 않는 리소스에 label 기반 추적을 사용하는 사용자

일부 사용자는 Argo CD 가 관리하지 않는 리소스를 추적하는 데 label 기반 추적에 의존합니다. Argo CD 가 리소스를 외부(extraneous)로 무시하거나 pruning 을 비활성화하도록 annotation 을 설정할 수 있어요. Argo CD 가 관리하지 않는 리소스를 추적하는 데 label 기반 추적을 사용한다면, 추적 label 대신 추적 annotation 을 구성해 관련 리소스에 적용해야 합니다. 추적 annotation 형식은:

argocd.argoproj.io/tracking-id: <app name>:<resource group>/<resource kind>:<resource namespace>/<resource name>

클러스터 스코프 리소스의 경우 네임스페이스는 Application 의 spec.destination.namespace 필드 값으로 설정됩니다.

경고

추적 label 과 annotation 을 수동으로 구성·적용하는 것은 공식 지원되는 기능이 아니며 Argo CD 의 동작은 향후 바뀔 수 있습니다. GitOps 로 Argo CD 로 리소스를 관리하는 것을 권장합니다.

옵트아웃 (Opting Out)

annotation 기반 추적을 사용할 준비가 되지 않았다면 argocd-cm ConfigMap 에서 application.resourceTrackingMethod 필드를 label 로 설정해 이 변경에서 옵트아웃할 수 있습니다. 현재 label 기반 추적을 제거할 계획은 없습니다.

기타 변경 (Other changes)

cluster.inClusterEnabled: "false" 사용

cluster.inClusterEnabled: "false" 가 명시적으로 구성되면, 현재 in-cluster 클러스터에서 동기화하도록 구성된 Application 은 리소스를 동기화할 가능성 없이 Unknown 상태가 됩니다.

in-cluster 클러스터를 사용해 새 Application 을 만드는 것은 불가능해집니다. 기존 Application 을 삭제해도 이전에 관리한 리소스는 삭제되지 않습니다.

in-cluster 가 비활성화된 경우 업그레이드 전에 기존 in-cluster Application 의 정리나 마이그레이션을 수행하는 것을 권장합니다. 마이그레이션 후 정리를 하려면 in-cluster 를 일시적으로 활성화해야 합니다.

모든 상태 업데이트와 높은 변경(churn) 변이 무시 (Ignoring all status updates and high churn mutations)

Argo CD 매니페스트는 이제 argocd-cm 에 resource.customizations.ignoreResourceUpdates 기본 구성을 포함해 Kubernetes 에서 자주 변이되는 공통 리소스를 제외합니다. 이런 변이는 Argo CD 에 불필요한 부하를 일으키는 것으로 알려져 있습니다. 감시 중인 리소스가 수정되면 Argo CD 는 항상 .status 변경을 무시합니다.

기본 resource.customizations.ignoreResourceUpdates 구성은 configMap 에서 오버라이드하거나 제거해 v2 동작을 유지할 수 있어요.

Application CR 의 Health 상태 (Health status in the Application CR)

각 오브젝트의 health 상태는 기본적으로 Application CR 의 /status 아래에 영속화되었습니다. Application 이 배포한 리소스의 health 변경(churn) 은 application 컨트롤러에 부하를 주었습니다. 이제 health 상태는 외부에 저장됩니다.

이 동작을 되돌리려면 Argo CD argocd-cmd-params-cm.yaml Config Map 에서 controller.resource.health.persist 를 true 로 설정하면 됩니다.

Application CR 에서 health 를 영속화하는 status 필드의 예:

status:
  health:
    status: Healthy
    lastTransitionTime: '2025-01-01T00:00:00Z'
  resources:
    - group: apps
      health:
        status: Healthy
      kind: Deployment
      name: my-app
      namespace: foo
      status: OutOfSync
      version: v1
  sync:
    status: OutOfSync

Application CR 에서 health 를 영속화하지 않는 status 필드의 예:

status:
  health:
    status: Healthy
    lastTransitionTime: '2025-01-01T00:00:00Z'
  resourceHealthSource: appTree
  resources:
    - group: apps
      kind: Deployment
      name: my-app
      namespace: foo
      status: OutOfSync
      version: v1
  sync:
    status: OutOfSync

감지 (Detection)

• argocd-cmd-params-cm.yaml ConfigMap 에서 controller.resource.health.persist 를 확인하세요.

값이 비어 있거나 true 이면 health 상태가 Application CR 에 영속화됩니다.

kubectl get cm argocd-cmd-params-cm -n argocd -o jsonpath='{.data.controller\.resource\.health\.persist}'

• Application CR 에서 resourceHealthSource 필드를 확인하세요. 빈 값이 보이면 health 상태가 Application CR 에 영속화되는 것입니다.

kubectl get applications.argoproj.io <my app> -n argocd -o jsonpath='{.status.resourceHealthSource}'

마이그레이션 (Migration)

.status.resources[].health 를 파싱하는 도구나 CLI 명령어는 health 상태를 얻기 위해 argocd cli/API 를 사용하도록 업데이트해야 합니다.

참고

Application 목록 API(argocd app list) 는 더 이상 리소스 개별 health 상태를 반환하지 않습니다.

argocd app get <my app> -o json

플러그인의 빈 환경 변수 (Empty Environment Variables in Plugins)

Argo CD 3.0 에서 빈 환경 변수는 이제 config management plugin 에 전달됩니다.

apiVersion: argoproj.io/v1alpha1
kind: Application
spec:
  source:
    plugin:
      name: example-plugin
      env:
        - name: VERSION
          value: '1.2.3'
        - name: DATA # Even though this is empty, it will be passed to the plugin as ARGOCD_ENV_DATA="".
          value: ''

기본적으로 ignoreDifferences 에 구성된 리소스 업데이트 무시 (Ignoring resource updates configured in ignoreDifferences by default)

기본적으로 기존 시스템 수준 ignoreDifferences 커스터마이제이션은 리소스 업데이트도 무시하도록 추가됩니다.

논리적으로, 필드에 대한 차이가 무시되도록 구성되어 있다면 그 필드가 변경될 때 애플리케이션에 대한 diff 를 생성할 이유가 없습니다.

이 동작을 비활성화하고 v2 기본값을 유지하려면 ignoreDifferencesOnResourceUpdates 를 false 로 설정하면 됩니다:

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-cm
data:
  resource.compareoptions: |
    ignoreDifferencesOnResourceUpdates: false

무시된 리소스 업데이트에 대한 자세한 내용은 Reconcile Optimization 문서 에서 확인하세요.

기본적으로 차이에서 status 필드 무시 (Ignoring status field from differences by default)

기본적으로 status 필드를 무시하는 compare 옵션은 crd 에서 all 리소스로 변경되었습니다.

이는 status 의 일부인 필드에 대해서는 더 이상 차이가 감지되지 않는다는 뜻입니다.

status 필드가 desired state 의 일부라는 점에 의존한다면 ignoreResourceStatusField 설정으로 v2 기본값을 유지할 수 있어요.

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-cm
data:
  resource.compareoptions: |
    ignoreResourceStatusField: crd

CRD 에 대한 preserveUnknownFields 기본 무시 제거 (Removing default ignores of preserveUnknownFields for CRD)

spec.preserveUnknownFields 는 CRD v1 에서 x-kubernetes-preserve-unknown-fields: true 를 선호하며 deprecated 되었습니다.

즉 spec.preserveUnknownFields: false 를 포함한 Argo CD 로 배포된 CRD 는 out of sync 가 됩니다. 이 문제를 해결하려면 CRD spec 에서 preserveUnknownFields 필드를 제거할 수 있습니다.

이 작업을 완료할 때까지 Application 이 out of sync 가 되지 않기를 원한다면 Application 매니페스트에 다음 구성을 추가할 수 있어요.

spec:
  ignoreDifferences:
    - group: apiextensions.k8s.io
      kind: CustomResourceDefinition
      jsonPointers:
        - /spec/preserveUnknownFields

argocd-cm ConfigMap 에서 전역으로 구성할 수도 있습니다.

resource.customizations.ignoreDifferences.apiextensions.k8s.io_CustomResourceDefinition: |
    jsonPointers:
    - /spec/preserveUnknownFields

무시된 리소스 업데이트에 대한 자세한 내용은 Diffing customization 문서 에서 확인하세요.

위생 처리된 프로젝트 API 응답 (Sanitized project API response)

보안상 이유로(GHSA-786q-9hcg-v9ff) 프로젝트 API 응답에서 민감한 정보를 제거하도록 위생 처리했습니다. 프로젝트 스코프 리포지토리와 클러스터의 자격 증명이 포함됩니다.

추가된 Healthcheck (Added Healthchecks)

• 추가된 새 health check 없음

더 알아보기 (Learn more)

• 직전 업그레이드: v2.13 to v2.14
• 다음 업그레이드: v3.0 to v3.1