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

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

Autopilot Standard

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

containerd 노드 이미지와 함께 GKE 1.32 이하를 실행하는 노드는 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 이미지와 Container Runtime Interface (CRI) v1alpha2 API가 모두 지원 중단되었습니다. 이전 버전에서 지원 중단된 다른 기능에 대한 자세한 내용은 지원 중단된 구성 속성을 참고하세요.
부 버전 1.33부터 GKE는 Docker 스키마 1 이미지 및 CRI v1alpha2 API에 대한 지원을 삭제하는 containerd 2.0을 사용합니다.
CRI 플러그인의 다음 containerd 구성 속성은 지원 중단되었으며 containerd 2.1에서 삭제될 예정입니다. GKE 버전은 아직 발표되지 않았습니다. registry.auths, registry.configs, registry.mirrors.

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

containerd 2로의 전환의 영향

containerd 2로의 전환이 미치는 영향을 알아보려면 다음 섹션을 참고하세요.

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

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

이러한 기능 사용에서 이전한 후 1.33이 클러스터 노드의 자동 업그레이드 타겟이고 자동 업그레이드를 차단하는 다른 요인이 없는 경우 GKE는 1.33으로의 자동 마이너 업그레이드를 재개합니다. 표준 클러스터 노드 풀의 경우 노드 풀을 수동으로 업그레이드할 수도 있습니다.

지원 종료 및 이전 준비 실패의 영향

GKE는 표준 지원 종료 시까지 자동 업그레이드를 일시중지합니다. 클러스터가 확장 채널에 등록된 경우 노드는 연장 지원 종료 시까지 버전을 유지할 수 있습니다. 지원 종료 시 자동 노드 업그레이드에 관한 자세한 내용은 지원 종료 시 자동 업그레이드를 참고하세요.

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

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

지원 중단된 기능에서 이전

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

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

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

이전할 이미지 찾기

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

Cloud Logging 사용

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를 사용하도록 이러한 애플리케이션을 업데이트해야 합니다.

워크로드 식별

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

kubectl 사용

다음 명령어를 사용하면 containerd 소켓에 액세스하는 워크로드를 찾을 수 있습니다. 이 명령어는 소켓이 포함된 hostPath 디렉터리를 마운트하는 워크로드를 반환합니다. 일부 워크로드는 이러한 디렉터리 또는 다른 하위 디렉터리를 마운트하지만 컨테이너드 소켓에 액세스하지 않으므로 이 쿼리로 인해 거짓양성이 발생할 수 있습니다.

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

kubectl get pods --all-namespaces -o json | jq -r '.items[] |
select(.spec.volumes[]? | select(.hostPath.path? and (.hostPath.path |
startswith("/run") or startswith("/var/run") or . == "/"))) |
.metadata.namespace + "/" + .metadata.name'

애플리케이션 코드 확인

애플리케이션 코드를 확인하여 CRI v1alpha2 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"