dockershim에서 containerd로 마이그레이션 - Amazon EKS
Docker에서 containerd로 Amazon Linux 2 마이그레이션 테스트

dockershim에서 containerd로 마이그레이션

Kubernetes는 더 이상 dockershim을 지원하지 않습니다. Kubernetes 팀이 Kubernetes 버전 1.24에서 런타임을 제거했습니다. 자세한 내용은 Kubernetes 블로그의 Kubernetes, Dockershim에서 벗어나다: 커밋과 다음 단계를 참조하세요.

Amazon EKS에서는 Kubernetes 버전 1.24 릴리스부터 dockershim에 대한 지원을 종료합니다. 공식적으로 게시된 Amazon EKS AMI에는 버전 1.24부터 유일한 런타임으로 containerd가 있습니다. 이 항목에서는 몇 가지 세부 정보를 다루지만 자세한 내용은 Amazon EKS containerd로의 이동에 관해 알아야 할 모든 사항에서 확인할 수 있습니다.

어떤 Kubernetes 워크로드가 Docker 소켓 볼륨을 탑재하는지 확인하는 데 사용할 수 있는 kubectl 플러그인이 있습니다. 자세한 내용을 알아보려면 GitHub의 Detector for Docker Socket(DDS)을 참조하세요. 1.24 이전 버전의 Kubernetes를 실행하는 Amazon EKS AMI에서는 기본 런타임으로 Docker를 사용합니다. 그러나 이러한 Amazon EKS AMI에는 containerd을 사용하여 지원되는 클러스터의 워크로드를 테스트하는 데 사용할 수 있는 부트스트랩 플래그 옵션이 있습니다. 자세한 내용은 Docker에서 containerd로 Amazon Linux 2 마이그레이션 테스트 단원을 참조하십시오.

지원 날짜가 끝날 때까지 기존 Kubernetes 버전에 대한 AMI를 계속 게시할 예정입니다. 자세한 내용은 Amazon EKS Kubernetes 릴리스 일정 단원을 참조하십시오. containerd에서 워크로드를 테스트하는 시간이 더 필요하면 1.24 이전의 지원되는 버전을 사용하세요. 그러나 공식 Amazon EKS AMI를 1.24 또는 이후 버전으로 업그레이드하려면 워크로드가 containerd에서 실행되는지 검증하세요.

containerd 런타임에서는 신뢰성과 보안이 향상됩니다.containerd는 Amazon EKS 전체에서 표준화되고 있는 런타임입니다. Fargate와 Bottlerocket에서는 이미 containerd만 사용합니다. containerd는 dockershim CVE(일반적인 취약성 및 노출)를 해결하는 데 필요한 Amazon EKS AMI 릴리스 수 최소화에 도움이 됩니다. dockershim에서는 이미 내부적으로 containerd를 사용하고 있으므로 변경할 필요가 없을 수도 있습니다. 그러나 변경이 필요할 수 있거나 필요해야 하는 몇 가지 상황이 있습니다.

  • Docker 소켓을 탑재하는 애플리케이션을 변경해야 합니다. 예를 들어, 컨테이너로 빌드하는 컨테이너 이미지가 영향을 받습니다. 많은 모니터링 도구도 Docker 소켓을 탑재합니다. 업데이트를 기다리거나 런타임 모니터링을 위해 워크로드를 재배포해야 할 수도 있습니다.

  • 특정 Docker 설정에 의존하는 애플리케이션을 변경해야 할 수도 있습니다. 예를 들어, HTTPS_PROXY 프로토콜은 이제 지원되지 않습니다. 이 프로토콜을 사용하는 애플리케이션을 업데이트해야 합니다. 자세한 내용은 Docker 설명서의 dockerd 항목을 참조하세요.

  • Amazon ECR 자격 증명 헬퍼를 사용하여 이미지를 가져오는 경우 kubelet 이미지 보안 인증 제공업체로 전환해야 합니다. 자세한 내용을 알아보려면 Kubernetes 문서의 kubelet 이미지 보안 인증 제공업체 구성을 참조하세요.

  • Amazon EKS 1.24에서 더는 Docker를 지원하지 않으므로 Amazon EKS 부트스트랩 스크립트에서 이전에 지원되던 일부 플래그가 더는 지원되지 않습니다. Amazon EKS 1.24 또는 이후 버전으로 이동하기 전에 지금 지원되지 않는 플래그에 대한 참조를 모두 제거해야 합니다.

    • --container-runtime dockerd(containerd가 지원되는 유일한 값임)

    • --enable-docker-bridge

    • --docker-config-json

  • Container Insights에 대해 Fluentd를 이미 구성한 경우 containerd로 변경하기 전에 Fluentd를 Fluent Bit로 마이그레이션해야 합니다. Fluentd 구문 분석기는 JSON 형식의 로그 메시지만 구문 분석하도록 구성됩니다. dockerd와 달리 containerd 컨테이너 런타임에는 JSON 형식이 아닌 로그 메시지가 있습니다. Fluent Bit로 마이그레이션하지 않으면 구성된 Fluentd’s 구문 분석기 중 일부가 Fluentd 컨테이너 내에서 엄청난 양의 오류를 생성합니다. 마이그레이션에 대한 자세한 내용은 로그를 CloudWatch Logs로 전송하기 위해 Fluent Bit를 데몬 세트로 설정하기를 참조하세요.

  • 사용자 지정 AMI를 사용하고 Amazon EKS 1.24로 업그레이드하는 경우 워커 노드에 대해 IP 전달이 활성화되어 있는지 확인해야 합니다. 이 설정은 Docker에 필요하지 않았지만 containerd에 필요합니다. 이는 Pod와 Pod, Pod와 외부 또는 Pod와 apiserver 간 네트워크 연결 문제를 해결하는 데 필요합니다.

    워커 노드에서 이 설정을 확인하려면 다음 명령 중 하나를 실행합니다.

    • sysctl net.ipv4.ip_forward

    • cat /proc/sys/net/ipv4/ip_forward

    출력이 0이면 다음 명령 중 하나를 실행하여 net.ipv4.ip_forward 커널 변수를 활성화합니다.

    +

    • sysctl -w net.ipv4.ip_forward=1

    • echo 1 > /proc/sys/net/ipv4/ip_forward

containerd 런타임의 Amazon EKS AMI for Amazon Linux 2에 대한 설정 활성화는 GitHub의 install-worker.sh 섹션을 참조하세요.

Docker에서 containerd로 Amazon Linux 2 마이그레이션 테스트

Kubernetes 버전 1.23의 경우 선택적 부트스트랩 플래그를 사용하여 Amazon EKS 최적화 AL2 AMI에 대해 containerd 런타임을 활성화할 수 있습니다. 이 기능에서는 버전 1.24 또는 이후 버전으로 업데이트할 때 containerd로 마이그레이션하는 명확한 경로를 제공합니다. Amazon EKS에서는 Kubernetes 버전 1.24 출시부터 Docker에 대한 지원이 종료되었습니다. containerd 런타임은 Kubernetes 커뮤니티에서 널리 채택되었으며 CNCF의 마무리 단계를 통과한 프로젝트입니다. 노드 그룹을 새 클러스터나 기존 클러스터에 추가하여 테스트할 수 있습니다.

다음 노드 그룹 유형 중 하나를 생성하여 부트스트랩 플래그를 사용할 수 있습니다.

자체 관리형

자체 관리 Amazon Linux 노드 생성의 지침에 따라 노드 그룹을 생성합니다. Amazon EKS 최적화 AMI를 지정하고 BootstrapArguments 파라미터에 다음 텍스트를 지정합니다.

--container-runtime containerd
관리형

eksctl을 사용하는 경우 다음 내용이 포함된 my-nodegroup.yaml이라는 파일을 생성합니다. 모든 예제 값을 자신의 값으로 바꾸세요. 노드 그룹 이름은 63자를 초과할 수 없습니다. 문자나 숫자로 시작하되, 나머지 문자의 경우 하이픈과 밑줄을 포함할 수 있습니다. ami-1234567890abcdef0 에 대해 최적화된 AMI ID를 검색하려면 권장 Amazon Linux AMI ID 검색 섹션을 참조하세요.

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: my-cluster
  region: region-code
  version: 1.23
managedNodeGroups:
  - name: my-nodegroup
    ami: ami-1234567890abcdef0
    overrideBootstrapCommand: |
      #!/bin/bash
      /etc/eks/bootstrap.sh my-cluster --container-runtime containerd
참고

많은 노드를 동시에 시작하는 경우 --apiserver-endpoint, --b64-cluster-ca 및 --dns-cluster-ip 부트스트랩 인수에 대한 값을 지정하여 오류를 방지하려 할 수도 있습니다. 자세한 내용은 AMI 지정 단원을 참조하십시오.

다음 명령을 실행하여 노드 그룹을 생성합니다.

eksctl create nodegroup -f my-nodegroup.yaml

다른 도구를 사용하여 관리형 노드 그룹을 생성하려면 시작 템플릿을 사용하여 노드 그룹을 배포해야 합니다. 시작 템플릿에서 Amazon EKS 최적화 AMI ID를 지정한 다음 시작 템플릿을 사용하여 노드 그룹 배포하고 다음 사용자 데이터를 제공합니다. 이 사용자 데이터는 인수를 bootstrap.sh 파일에 전달합니다. 부트스트랩 파일에 대한 자세한 내용은 GitHub에서 bootstrap.sh 부분을 참조하세요.

/etc/eks/bootstrap.sh my-cluster --container-runtime containerd