이 페이지는 Cloud Translation API를 통해 번역되었습니다.

노드를 containerd 2로 마이그레이션

Autopilot Standard

Google Kubernetes Engine(GKE) 클러스터는 버전 1.24 이상을 실행하는 모든 워커 노드와 함께 containerd 노드 이미지를 사용합니다. 워커 노드는 GKE 버전에 따라 특정 버전의 containerd를 사용합니다.

GKE 1.32 이하를 실행하는 노드 중 containerd 노드 이미지를 사용하는 노드는 containerd 1.7 이하 버전을 사용합니다.
GKE 1.33을 실행하는 노드는 containerd 2.0을 사용합니다.

GKE 노드가 1.32에서 1.33으로 업그레이드되면 노드가 containerd 1.7을 사용하는 버전에서 새로운 메이저 버전인 containerd 2.0으로 마이그레이션됩니다. GKE 버전에서 사용하는 containerd 버전은 변경할 수 없습니다.

containerd 2에서 워크로드가 예상한 대로 실행되고 있음을 알고 있으면 이 페이지를 건너뛰어도 됩니다.

GKE가 containerd 2로 전환하는 방법

다음 타임라인을 검토하여 GKE에서 containerd 2를 사용하도록 기존 클러스터를 전환하는 방법을 확인합니다.

마이너 버전 1.32에서 GKE는 containerd 1.7을 사용합니다. containerd 1.7에서는 Docker 스키마 1 이미지와 CRI(Container Runtime Interface) v1alpha2 API의 지원이 모두 중단되었습니다. 이전 버전에서 지원 중단된 다른 기능에 대해 알아보려면 지원 중단된 구성 속성을 참조하세요.
마이너 버전 1.33에서 GKE는 Docker 스키마 1 이미지와 CRI v1alpha2 API가 더 이상 지원되지 않는 containerd 2.0을 사용합니다.
CRI 플러그인의 containerd 구성 속성인 registry.auths, registry.configs, registry.mirrors는 지원 중단되었으며 containerd 2.2에서 삭제될 예정입니다. GKE 버전은 아직 발표되지 않았습니다. 하지만 registry.configs.tls는 containerd 2.0에서 이미 삭제되었습니다.

1.33과 같은 이후 마이너 버전으로 자동 업그레이드되는 대략적인 시점은 출시 채널의 예상 일정을 참조하세요.

containerd 2로의 전환이 미치는 영향

다음 섹션에서 containerd 2로의 전환이 미치는 영향을 알아보세요.

자동 업그레이드 일시중지됨

GKE는 클러스터에서 지원 중단된 기능을 사용하는 것이 감지되면 1.33으로의 자동 업그레이드를 일시중지합니다. 하지만 클러스터 노드에서 이러한 기능을 사용하면 노드 업그레이드를 방지하기 위해 유지보수 제외를 만드는 것이 좋습니다. 유지보수 제외를 사용하면 GKE에서 사용량을 감지하지 않는 경우 노드가 업그레이드되지 않습니다.

이러한 기능 사용을 중단한 후, 다음 조건이 충족되면 GKE는 자동 마이너 업그레이드를 1.33으로 재개합니다.

GKE에서 14일 동안 지원 중단된 기능의 사용을 감지하지 못했습니다(지원 중단된 CRI registry.configs 속성의 경우 3일).
1.33은 클러스터 노드의 자동 업그레이드 대상입니다.
다른 차단 요소는 없습니다. 자세한 내용은 자동 업그레이드 시점을 참조하세요.

Standard 클러스터 노드 풀의 경우 노드 풀을 수동으로 업그레이드할 수도 있습니다.

지원 종료 및 마이그레이션 준비 실패의 영향

GKE는 스탠더드 지원 종료 시점에 도달할 때까지 자동 업그레이드를 일시중지합니다. 클러스터가 확장 채널에 등록되면 노드는 연장 지원 종료 시점에 도달할 때까지 버전을 유지할 수 있습니다. 지원 종료 시 자동 노드 업그레이드에 대한 자세한 내용은 지원 종료 시 자동 업그레이드를 참조하세요.

이러한 기능에서 마이그레이션하지 않으면 1.32의 지원이 종료되고 클러스터 노드가 자동으로 1.33으로 업그레이드될 때 클러스터에서 다음과 같은 문제가 발생할 수 있습니다.

Docker 스키마 1 이미지를 사용하는 워크로드가 실패합니다.
CRI v1alpha2 API를 호출하는 애플리케이션에서 API 호출 시 오류가 발생합니다.

영향을 받는 클러스터 식별

GKE는 클러스터를 모니터링하고 추천자 서비스를 사용하여 지원 중단된 기능을 사용하는 클러스터 노드를 식별하는 데 도움이 되는 통계와 추천을 통해 지침을 제공합니다.

버전 요구사항

다음 버전 이상을 실행하는 클러스터는 이러한 통계와 추천을 받습니다.

1.28.15-gke.1159000
1.29.9-gke.1541000
1.30.5-gke.1355000
1.31.1-gke.1621000

통계 및 추천 받기

안내에 따라 통계와 추천을 확인합니다. Google Cloud 콘솔을 사용하여 통계를 확인할 수 있습니다. 다음 하위 유형으로 필터링하여 Google Cloud CLI 또는 Recommender API를 사용할 수도 있습니다.

DEPRECATION_CONTAINERD_V1_SCHEMA_IMAGES: Docker 스키마 1 이미지
DEPRECATION_CONTAINERD_V1ALPHA2_CRI_API: CRI v1alpha2 API
DEPRECATION_CONTAINERD_V2_CONFIG_REGISTRY_CONFIGS: registry.configs.auth 및 registry.configs.tls를 포함한 지원 중단된 CRI registry.configs 속성

지원 중단된 기능에서 마이그레이션

다음 콘텐츠를 검토하여 containerd 2에서 지원 중단된 기능에서 마이그레이션하는 방법을 알아보세요.

Docker 스키마 1 이미지에서 마이그레이션

마이그레이션해야 하는 이미지를 사용하여 워크로드를 식별한 다음 해당 워크로드를 마이그레이션합니다.

마이그레이션할 이미지 찾기

다양한 도구를 사용하여 마이그레이션해야 하는 이미지를 찾을 수 있습니다.

통계 및 추천 또는 Cloud Logging 사용

영향을 받는 클러스터 식별 섹션의 설명대로 클러스터가 최소 버전 이상을 실행하는 경우 통계 및 추천을 사용하여 Docker 스키마 1 이미지를 사용하는 클러스터를 찾을 수 있습니다. 또한 Cloud Logging에서 다음 쿼리를 사용하여 containerd 로그를 확인하고 클러스터에서 Docker 스키마 1 이미지를 찾을 수 있습니다.

jsonPayload.SYSLOG_IDENTIFIER="containerd"
"conversion from schema 1 images is deprecated"

이미지를 가져온 후 30일이 지났다면 이미지 로그가 표시되지 않을 수 있습니다.

노드에서 직접 `ctr` 명령어 사용

특정 노드를 쿼리하여 스키마 1로 가져온 삭제되지 않은 모든 이미지를 반환하려면 노드에서 다음 명령어를 실행합니다.

  ctr --namespace k8s.io images list 'labels."io.containerd.image/converted-docker-schema1"'

이 명령어는 예를 들어 특정 노드의 문제를 해결 중이고 이미지를 가져온 후 30일이 넘게 경과했기 때문에 Cloud Logging에 로그 항목이 보이지 않는 경우 유용할 수 있습니다.

`crane` 오픈소스 도구 사용

crane과 같은 오픈소스 도구를 사용하여 이미지를 확인할 수도 있습니다.

다음 crane 명령어를 실행하여 이미지의 스키마 버전을 확인합니다.

crane manifest $tagged_image | jq .schemaVersion

워크로드 준비

Docker 스키마 1 이미지를 실행하는 워크로드를 준비하려면 해당 워크로드를 스키마 2 Docker 이미지 또는 Open Container Initiative(OCI) 이미지로 마이그레이션해야 합니다. 마이그레이션할 때는 다음과 같은 옵션을 고려하세요.

대체 이미지 찾기: 공개적으로 제공되는 오픈소스 또는 공급업체에서 제공한 이미지를 찾을 수 있습니다.
기존 이미지 변환: 대체 이미지를 찾을 수 없으면 다음 단계에 따라 기존 Docker 스키마 1 이미지를 OCI 이미지로 변환할 수 있습니다.
1. Docker 이미지를 containerd로 가져옵니다. 그러면 이미지가 자동으로 OCI 이미지로 변환됩니다.
2. 새로운 OCI 이미지를 레지스트리에 푸시합니다.

CRI v1alpha2 API에서 마이그레이션

CRI v1alpha2 API는 Kubernetes 1.26에서 삭제되었습니다. containerd 소켓에 액세스하는 워크로드를 식별하고 v1 API를 사용하도록 이러한 애플리케이션을 업데이트해야 합니다.

영향을 받을 수 있는 워크로드 식별

다양한 기법을 사용하여 마이그레이션해야 할 수 있는 워크로드를 식별할 수 있습니다. 이러한 기법은 거짓양성을 생성할 수 있으며, 추가 조사를 통해 별도의 조치가 필요하지 않음을 확인해야 합니다.

통계 및 추천 사용

클러스터가 최소 버전 이상을 실행하는 경우 통계 및 추천을 사용하여 v1alpha2 API를 사용하는 클러스터를 찾을 수 있습니다. 자세한 내용은 영향을 받는 클러스터 식별을 참조하세요.

Google Cloud 콘솔에서 통계를 볼 때 지원 중단된 CRI v1alpha2 API에서 워크로드 마이그레이션 사이드바 패널을 참조하세요. 이 패널의 확인할 워크로드 테이블에는 영향을 받을 수 있는 워크로드가 표시됩니다. 이 목록에는 containerd 소켓 경로(예: /var/run/containerd/containerd.sock 또는 /run/containerd/containerd.sock)가 포함된 hostPath 볼륨이 있고 GKE에서 관리하지 않는 워크로드가 포함됩니다.

다음 사항을 이해하는 것이 중요합니다.

이 목록에는 거짓양성이 있을 수 있습니다. 이 목록에 표시되는 워크로드는 해당 워크로드가 반드시 지원 중단된 API를 사용하고 있다는 의미는 아닙니다. 이는 워크로드가 containerd 소켓을 포함하는 hostPath 볼륨을 참조한다는 것만 나타냅니다. 예를 들어 모니터링 에이전트는 측정항목을 수집하기 위해 노드의 루트 파일 시스템(/)을 포함할 수 있습니다. 노드의 루트 파일 시스템을 포함하면 기술적으로 소켓의 경로가 포함되지만 측정항목 에이전트가 실제로 CRI v1alpha2 API를 호출하지 않을 수 있습니다.
이 목록은 비어 있거나 불완전할 수 있습니다. GKE가 주기적 검사를 수행할 때 지원 중단된 API를 사용하는 워크로드가 단기간 동안 실행되지 않은 경우 목록이 비어 있거나 불완전할 수 있습니다. 권장사항이 있다는 것은 클러스터에 있는 최소 하나 이상의 노드에서 CRI v1alpha2 API 사용이 감지되었음을 의미합니다.

따라서 실제 API 사용량을 확인하기 위해 다음과 같은 방법을 사용하여 추가 조사를 수행하는 것이 좋습니다.

영향을 받는 서드 파티 워크로드 확인

클러스터에 배포된 서드 파티 소프트웨어의 경우 이러한 워크로드가 CRI v1alpha2 API를 사용하지 않는지 확인합니다. 해당 공급업체에 문의하여 호환되는 소프트웨어 버전을 확인해야 할 수도 있습니다.

kubectl 사용

다음 명령어를 사용하면 containerd 소켓에 액세스하는 워크로드를 찾아 잠재적으로 영향을 받는 워크로드를 찾을 수 있습니다. 이 명령어는 Google Cloud 콘솔 권장사항의 확인할 워크로드 테이블에 사용된 것과 유사한 로직을 사용합니다. 소켓 경로가 포함된 hostPath 볼륨이 있고 GKE에서 관리하지 않는 워크로드를 반환합니다. 권장사항과 마찬가지로 이 쿼리는 거짓양성을 반환하거나 단기 워크로드를 누락할 수 있습니다.

다음 명령어를 실행합니다.

kubectl get pods --all-namespaces -o json | \
jq -r '
  [
    "/", "/var", "/var/","/var/run", "/var/run/",
    "/var/run/containerd", "/var/run/containerd/", "/var/run/containerd/containerd.sock",
    "/run", "/run/", "/run/containerd", "/run/containerd/",
    "/run/containerd/containerd.sock"
  ] as $socket_paths |
  [
    "kube-system", "kube-node-lease", "istio-system", "asm-system",
    "gatekeeper-system", "config-management-system", "config-management-monitoring",
    "cnrm-system", "hnc-system", "gke-managed-system", "gke-gmp-system",
    "gmp-system", "gke-managed-cim"
  ] as $excluded_namespaces |
  .items[] |
  select(
    (.spec.volumes[]?.hostPath.path as $p | $socket_paths | index($p))
    and
    ([.metadata.namespace] | inside($excluded_namespaces) | not)
  ) |
  .metadata.namespace + "/" + .metadata.name
'

eBPF 추적을 사용하여 API 호출자 식별

CRI v1alpha2 API를 호출하는 워크로드를 더 확실하게 식별하려면 다음과 같은 두 가지 특수 DaemonSet를 배포하면 됩니다.

containerd-socket-tracer는 containerd 소켓에 대한 연결을 설정하는 모든 프로세스를 포드 및 컨테이너 세부정보와 함께 로깅합니다.
cri-v1alpha2-api-deprecation-reporter는 CRI v1alpha2 API가 마지막으로 호출된 시간을 로깅합니다.

이러한 도구는 확장된 버클리 패킷 필터(eBPF)를 사용하여 containerd 소켓에 대한 연결을 추적하고 이 연결과 실제 지원 중단된 API 호출과의 상관관계를 파악합니다.

이 두 도구의 타임스탬프를 연계시키면 지원 중단된 API 호출을 수행하는 정확한 워크로드를 파악할 수 있습니다. 이 방법은 실제 소켓 연결과 API 사용을 관찰하므로 hostPath 볼륨만 확인하는 것보다 더 높은 수준의 신뢰도를 제공합니다.

이러한 도구를 배포하고 사용하는 방법과 로그를 해석하는 방법에 대한 자세한 내용은 containerd 소켓 연결 추적을 참조하세요.

이 도구를 사용한 후에도 지원 중단된 API 호출의 소스를 식별할 수 없지만 권장사항이 활성 상태로 유지되면 지원 받기를 참조하세요

앞의 방법을 사용하거나 코드베이스를 검사하여 CRI v1alpha2 API를 사용하는 워크로드를 식별한 후에는 v1 API를 사용하도록 코드를 업데이트해야 합니다.

애플리케이션 코드 업데이트

애플리케이션을 업데이트하려면 애플리케이션이 k8s.io/cri-api/pkg/apis/runtime/v1alpha2 클라이언트 라이브러리를 가져오는 위치를 삭제하고 API의 v1 버전을 사용하도록 코드를 수정합니다. 이 단계에서는 가져오기 경로를 변경하고 코드가 API를 호출하는 방식을 업데이트합니다.

예를 들어 지원 중단된 라이브러리를 사용하는 다음 golang 코드를 참조하세요.

  package main

  import (
    ...

    runtimeapi "k8s.io/cri-api/pkg/apis/runtime/v1alpha2"
  )

  func foo() {
    ...

    client := runtimeapi.NewRuntimeServiceClient(conn)
    version, err := client.Version(ctx, &runtimeapi.VersionRequest{})

    ...
  }

여기서 애플리케이션은 v1alpha2 라이브러리를 가져와 RPC를 발급하는 데 사용합니다. RPC가 containerd 소켓에 대한 연결을 사용하는 경우 이 애플리케이션으로 인해 GKE가 클러스터의 자동 업그레이드를 일시중지하게 됩니다.

애플리케이션 코드를 검색하고 업데이트하려면 다음 단계를 따르세요.

다음 명령어를 실행해 v1alpha2 가져오기 경로를 검색하여 문제가 있는 golang 애플리케이션을 식별합니다.
```
  grep -r "k8s.io/cri-api/pkg/apis/runtime/v1alpha2"
```
이 명령어의 출력에 v1alpha2 라이브러리가 파일에 사용된 것으로 표시되면 파일을 업데이트해야 합니다.

예를 들어 다음 애플리케이션 코드를 바꿉니다.
```
  runtimeapi "k8s.io/cri-api/pkg/apis/runtime/v1alpha2"
```

v1을 사용하도록 코드를 업데이트합니다.

  runtimeapi "k8s.io/cri-api/pkg/apis/runtime/v1"

지원 중단된 containerd 구성 속성에서 마이그레이션

CRI 플러그인의 containerd 구성 속성인 registry.auths, registry.configs, registry.mirrors는 지원 중단되었으며 containerd 2.2에서 삭제될 예정입니다. GKE 버전은 아직 발표되지 않았습니다. 하지만 registry.configs.tls는 containerd 2.0에서 이미 삭제되었습니다.

워크로드 식별

다양한 기법을 사용하여 마이그레이션해야 하는 워크로드를 식별할 수 있습니다.

통계 및 추천 사용

초기 접근 방식으로 통계 및 추천을 사용하여 지원 중단된 containerd 구성 속성을 사용하는 클러스터를 찾을 수 있습니다. 이를 위해서는 최소 GKE 버전이 필요합니다. 이 접근 방식에 대한 자세한 내용은 영향을 받는 클러스터 식별을 참조하세요.

Google Cloud 콘솔에서 통계를 볼 때 지원 중단된 CRI 레지스트리 인증 필드에서 containerd 구성 마이그레이션 또는 지원 중단된 CRI 레지스트리 미러 필드에서 containerd 구성 마이그레이션을 참조하세요. containerd 구성에 액세스할 수 있는 워크로드를 찾으려면 확인할 워크로드 섹션을 확인하세요.

kubectl 사용

또는 kubectl을 사용하여 워크로드를 식별할 수 있습니다.

다음 속성이 있는 워크로드를 확인하여 containerd 구성을 수정하는 워크로드를 찾습니다.

containerd 구성을 포함하는 hostPath 볼륨이 있는 워크로드
권한 액세스(spec.containers.securityContext.privileged: true)가 포함된 컨테이너가 있고 호스트 프로세스 ID(PID) 네임스페이스(spec.hostPID: true)를 사용하는 워크로드

이 명령어는 워크로드가 containerd 구성이 아닌 이러한 디렉터리의 다른 파일에 액세스할 수 있으므로 거짓양성을 반환할 수 있습니다. 또는 이 명령어는 containerd 구성 파일을 아직 일반적이지 않은 다른 방법으로 액세스하는 워크로드를 반환하지 않을 수 있습니다.

다음 명령어를 실행하여 DaemonSet을 확인합니다.

kubectl get daemonsets --all-namespaces -o json | \
jq -r '
  [
    "/", "/etc", "/etc/",
    "/etc/containerd", "/etc/containerd/",
    "/etc/containerd/config.toml"
  ] as $host_paths |
  [
    "kube-system", "kube-node-lease", "istio-system", "asm-system",
    "gatekeeper-system", "config-management-system", "config-management-monitoring",
    "cnrm-system", "hnc-system", "gke-managed-system", "gke-gmp-system",
    "gmp-system", "gke-managed-cim"
  ] as $excluded_namespaces |
  .items[] |
  select(
    ([.metadata.namespace] | inside($excluded_namespaces) | not)
    and
    (
      (any(.spec.template.spec.volumes[]?.hostPath.path; IN($host_paths[])))
      or
      (
        .spec.template.spec.hostPID == true and
        any(.spec.template.spec.containers[]; .securityContext?.privileged == true)
      )
    )
  ) |
  .metadata.namespace + "/" + .metadata.name
'

CRI 레지스트리 `auths` 또는 `configs.auth` 속성에서 마이그레이션

워크로드가 containerd 구성에서 auths 또는 configs.auth 속성을 사용하여 비공개 레지스트리에서 컨테이너 이미지를 가져오기 위해 인증하는 경우 해당 이미지를 사용하는 워크로드를 imagePullSecrets 필드로 마이그레이션해야 합니다. 자세한 내용은 비공개 레지스트리에서 이미지 사용을 참조하세요.

지원 중단된 auths 또는 configs.auth 속성을 사용하는 워크로드를 식별하고 마이그레이션하려면 다음 안내를 검토하세요.

레지스트리의 인증 세부정보 찾기

다음 방법 중 하나로 레지스트리의 인증 세부정보를 찾을 수 있습니다.

GKE 노드에 연결하여 /etc/containerd/config.toml 파일의 CRI 레지스트리 auths 및 configs.auth 섹션을 검토합니다.
containerd 구성 파일을 수정하는 워크로드를 찾고 앞에서 설명한 워크로드 식별 방법을 사용하여 포함된 인증 세부정보를 확인합니다. GKE는 시스템 워크로드에 이러한 설정을 사용하지 않습니다.

registry.configs.auth 속성을 사용하는 경우 인증 세부정보는 다음과 같이 표시될 수 있습니다.

  [plugins."io.containerd.grpc.v1.cri".registry.configs."$REGISTRY_DOMAIN".auth]
    username = "example-user"
    password = "example-password"

구성에서 지정된 각 레지스트리 도메인에 대해 이러한 인증 세부정보를 수집합니다.

`imagePullSecrets` 필드를 사용하도록 워크로드 업데이트

비공개 레지스트리에서 이미지 가져오기의 안내에 따라 이전 섹션의 인증 세부정보로 보안 비밀을 만듭니다.
다음 명령어를 실행하여 imagePullSecrets 필드로 마이그레이션해야 하는 워크로드를 식별합니다.
```
kubectl get pods -A -o json |
jq -r ".items[] |
  select(.spec.containers[] |
        .image | startswith(\"$REGISTRY_DOMAIN\")) |
  .metadata.namespace + \"/\" + .metadata.name"
```
이 레지스트리 도메인의 이미지가 있는 워크로드에서 사용되는 각 네임스페이스의 보안 비밀을 만들어야 합니다.
imagePullSecrets 필드에 이전 단계에서 만든 보안 비밀을 사용하도록 워크로드를 업데이트합니다.

또는 많은 수의 워크로드를 마이그레이션하려면 MutatingAdmissionWebhook을 구현하여 imagePullSecrets 필드를 추가할 수 있습니다.

레지스트리 인증 설정을 중지하도록 containerd 구성 업데이트

imagePullSecrets 필드를 사용하도록 워크로드를 마이그레이션한 후에는 레지스트리 인증을 설정하지 않도록 containerd 구성을 수정하는 워크로드를 업데이트해야 합니다. 구성을 수정하는 것으로 확인된 워크로드의 경우 레지스트리 인증 설정을 중지하도록 워크로드를 수정합니다.

새 노드 풀로 테스트하고 새 노드 풀로 워크로드 마이그레이션

워크로드에 문제가 발생할 위험을 완화하려면 다음 단계를 따르세요.

새 노드 풀을 만듭니다.
containerd 구성을 수정하는 업데이트된 워크로드를 새 노드 풀의 노드에 예약합니다.
노드 풀 간 워크로드 마이그레이션의 안내에 따라 나머지 워크로드를 새 노드 풀로 마이그레이션합니다.

CRI 레지스트리 `configs.tls` 속성에서 마이그레이션

워크로드에서 registry.configs.tls 속성을 사용하는 경우 비공개 CA 인증서로 비공개 레지스트리에 액세스하도록 워크로드를 마이그레이션해야 합니다.

안내에 따라 구성 DaemonSet에서 마이그레이션합니다. 이 프로세스는 다음 단계를 따릅니다.

TLS 세부정보 설정을 중지하도록 containerd 구성을 수정하는 워크로드를 업데이트합니다.
Secret Manager에 인증서를 저장합니다.
인증서를 가리키는 런타임 구성 파일을 만듭니다.
새 노드 풀을 만들고 비공개 레지스트리에서 호스팅되는 이미지를 사용하는 워크로드가 예상대로 작동하는지 테스트합니다.
새 클러스터에 구성을 적용하고 해당 클러스터에서 워크로드를 실행하거나 기존 클러스터에 구성을 적용합니다. 기존 클러스터에 구성을 적용하면 다른 기존 워크로드가 중단될 수 있습니다. 이 두 가지 방법에 대한 자세한 내용은 런타임 구성 파일 만들기를 참조하세요.

마이그레이션 후에는 registry.configs 필드에 변경사항을 적용하지 않아야 containerd에 문제가 발생하지 않습니다.

지원 받기

지원 중단된 API 호출의 소스를 여전히 확인할 수 없고 추천이 활성 상태로 유지되는 경우 다음 단계를 고려하세요.

문서에서 문제 해결 방법을 찾을 수 없으면 지원 받기를 참조하여 다음 주제에 대한 조언을 포함한 추가 도움을 요청하세요.
- Cloud Customer Care에 문의하여 지원 케이스를 엽니다.
- StackOverflow에서 질문하고 google-kubernetes-engine 태그를 사용하여 유사한 문제를 검색해 커뮤니티의 지원을 받습니다. #kubernetes-engine Slack 채널에 가입하여 더 많은 커뮤니티 지원을 받을 수도 있습니다.
- 공개 Issue Tracker를 사용하여 버그나 기능 요청을 엽니다.

노드를 containerd 2로 마이그레이션 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.

GKE가 containerd 2로 전환하는 방법

containerd 2로의 전환이 미치는 영향

자동 업그레이드 일시중지됨

지원 종료 및 마이그레이션 준비 실패의 영향

영향을 받는 클러스터 식별

버전 요구사항

통계 및 추천 받기

지원 중단된 기능에서 마이그레이션

Docker 스키마 1 이미지에서 마이그레이션

마이그레이션할 이미지 찾기

통계 및 추천 또는 Cloud Logging 사용

노드에서 직접 ctr 명령어 사용

crane 오픈소스 도구 사용

워크로드 준비

CRI v1alpha2 API에서 마이그레이션

영향을 받을 수 있는 워크로드 식별

통계 및 추천 사용

영향을 받는 서드 파티 워크로드 확인

kubectl 사용

eBPF 추적을 사용하여 API 호출자 식별

애플리케이션 코드 업데이트

지원 중단된 containerd 구성 속성에서 마이그레이션

워크로드 식별

통계 및 추천 사용

kubectl 사용

CRI 레지스트리 auths 또는 configs.auth 속성에서 마이그레이션

레지스트리의 인증 세부정보 찾기

imagePullSecrets 필드를 사용하도록 워크로드 업데이트

레지스트리 인증 설정을 중지하도록 containerd 구성 업데이트

새 노드 풀로 테스트하고 새 노드 풀로 워크로드 마이그레이션

CRI 레지스트리 configs.tls 속성에서 마이그레이션

지원 받기

노드를 containerd 2로 마이그레이션

노드에서 직접 `ctr` 명령어 사용

`crane` 오픈소스 도구 사용

CRI 레지스트리 `auths` 또는 `configs.auth` 속성에서 마이그레이션

`imagePullSecrets` 필드를 사용하도록 워크로드 업데이트

CRI 레지스트리 `configs.tls` 속성에서 마이그레이션