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 이미지와 CRI (Container Runtime Interface) 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 호출 실패가 발생합니다.
영향을 받는 클러스터 식별
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
지원 중단된 기능에서 이전
다음 콘텐츠를 검토하여 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 이미지로 변환할 수 있습니다.
- Docker 이미지를 containerd로 가져와 자동으로 OCI 이미지로 변환합니다.
- 새 OCI 이미지를 레지스트리에 푸시합니다.
CRI v1alpha2 API에서 마이그레이션
CRI v1alpha2 API는 Kubernetes 1.26에서 삭제되었습니다. containerd 소켓에 액세스하는 워크로드를 식별하고 이러한 애플리케이션이 v1 API를 사용하도록 업데이트해야 합니다.
워크로드 식별
다양한 기법을 사용하여 마이그레이션해야 하는 워크로드를 식별할 수 있습니다.
통계 및 추천 사용하기
클러스터가 최소 버전 이상을 실행하는 경우 통계 및 추천을 사용하여 v1alpha2 API를 사용하는 클러스터를 찾을 수 있습니다. 자세한 내용은 영향을 받는 클러스터 식별을 참고하세요.
Google Cloud 콘솔에서 통계를 볼 때 사이드바 패널 지원 중단된 CRI v1alpha2 API에서 워크로드 이전을 참고하세요. containerd 소켓에 액세스하는 워크로드를 찾으려면 확인할 워크로드 섹션을 선택합니다.
kubectl 사용
다음 명령어를 사용하면 containerd 소켓에 액세스하는 워크로드를 찾을 수 있습니다. 이 명령어는 소켓이 포함된 hostPath 디렉터리를 마운트하는 워크로드를 반환합니다. 일부 워크로드는 이러한 디렉터리 또는 다른 하위 디렉터리를 마운트하지만 컨테이너드 소켓에 액세스하지 않으므로 이 쿼리로 인해 거짓양성이 발생할 수 있습니다.
다음 명령어를 실행합니다.
kubectl get pods --all-namespaces -o json |
jq -r '.items[] |
select(.spec.volumes[]?.hostPath.path as $p |
["/", "/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"] | index($p)) |
.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"