dockershim 제거가 자신에게 영향을 미치는지 확인하기

dockershim 제거가 자신에게 영향을 미치는지 확인하기 (Check whether dockershim removal affects you)

쿠버네티스의 dockershim 구성 요소는 Docker를 쿠버네티스의 컨테이너 런타임으로 사용할 수 있게 해줬어요. 쿠버네티스의 내장 dockershim 구성 요소는 v1.24 릴리스에서 제거됐어요.

이 페이지는 클러스터가 Docker를 컨테이너 런타임으로 어떻게 사용할 수 있는지 설명하고, 사용될 때 dockershim이 수행하는 역할에 대한 세부 사항을 제공하며, 어떤 워크로드가 dockershim 제거의 영향을 받을 수 있는지 확인할 수 있는 단계를 보여 줘요.

출처: 문서

본문

애플리케이션이 Docker에 의존하는지 확인하기

애플리케이션 컨테이너 빌드에 Docker를 사용한다면, 그 컨테이너들은 어떤 컨테이너 런타임에서도 계속 실행할 수 있어요. 이 Docker 사용은 컨테이너 런타임으로서의 Docker에 대한 의존으로 간주되지 않아요.

대체 컨테이너 런타임을 사용할 때, Docker 명령을 실행하는 것은 동작하지 않거나 예상치 못한 출력을 낼 수 있어요. Docker에 대한 의존성이 있는지 확인하는 방법은 다음과 같아요.

  • 권한 있는(privileged) 파드가 Docker 명령(예: docker ps)을 실행하거나, Docker 서비스를 재시작하거나(systemctl restart docker.service 같은 명령), /etc/docker/daemon.json 같은 Docker 특정 파일을 수정하지 않는지 확인하세요.
  • Docker 구성 파일(예: /etc/docker/daemon.json)에서 사설 레지스트리나 이미지 미러 설정을 확인하세요. 이런 것들은 보통 다른 컨테이너 런타임을 위해 재구성해야 해요.
  • 쿠버네티스 인프라 밖의 노드에서 실행되는 스크립트와 앱이 Docker 명령을 실행하지 않는지 확인하세요. 예를 들면:
    • 문제 해결을 위한 노드로의 SSH
    • 노드 시작 스크립트
    • 노드에 직접 설치된 모니터링·보안 에이전트
  • 위에서 언급한 권한 있는 작업을 수행하는 서드파티 도구. 자세한 내용은 'dockershim에서 텔레메트리·보안 에이전트 마이그레이션' 문서를 참고하세요.
  • dockershim 동작에 대한 간접적인 의존성이 없는지 확인하세요. 이는 엣지 케이스로 애플리케이션에 영향을 줄 가능성은 낮아요. 일부 도구는 Docker 특정 동작에 반응하도록 구성될 수 있어요. 예를 들어 특정 메트릭에 대해 알림을 높이거나, 문제 해결 지침의 일부로 특정 로그 메시지를 검색하는 것이죠. 그런 도구를 구성했다면 마이그레이션 전에 테스트 클러스터에서 동작을 테스트하세요.

Docker 의존성 설명 (Dependency on Docker explained)

컨테이너 런타임은 쿠버네티스 파드를 이루는 컨테이너를 실행할 수 있는 소프트웨어예요. 쿠버네티스는 파드의 오케스트레이션과 스케줄링을 담당해요. 각 노드에서 kubelet은 컨테이너 런타임 인터페이스(CRI)를 추상화로 사용하므로, 호환되는 어떤 컨테이너 런타임이든 사용할 수 있어요.

가장 이른 릴리스에서 쿠버네티스는 한 가지 컨테이너 런타임인 Docker와의 호환성을 제공했어요. 쿠버네티스 프로젝트 역사의 후반에, 클러스터 운영자들은 추가 컨테이너 런타임을 채택하고 싶어했어요. CRI는 이런 종류의 유연성을 허용하도록 설계됐고, kubelet은 CRI를 지원하기 시작했어요. 하지만 Docker는 CRI 사양이 발명되기 전에 이미 존재했기 때문에, 쿠버네티스 프로젝트는 어댑터 구성 요소인 dockershim을 만들었어요. dockershim 어댑터는 kubelet이 Docker를 마치 CRI 호환 런타임인 것처럼 상호작용할 수 있게 해줬어요.

이에 대한 자세한 내용은 'Kubernetes Containerd integration goes GA' 블로그 게시물에서 읽을 수 있어요.

Containerd를 컨테이너 런타임으로 전환하면 중간자(middleman)가 제거돼요. 같은 컨테이너들을 이전처럼 Containerd 같은 컨테이너 런타임으로 계속 실행할 수 있어요. 하지만 이제 컨테이너는 컨테이너 런타임과 직접 스케줄링되기 때문에 Docker에는 보이지 않아요. 그래서 이전에 이 컨테이너들을 확인하던 Docker 도구나 화려한 UI는 더 이상 사용할 수 없어요.

docker ps나 docker inspect 명령으로 컨테이너 정보를 얻을 수 없어요. 컨테이너를 나열할 수 없기 때문에, 로그를 얻거나, 컨테이너를 중지하거나, docker exec로 컨테이너 안에서 무엇인가 실행할 수도 없어요.

참고:

이미지를 pull하거나 docker build 명령으로 빌드하는 것은 여전히 가능해요. 하지만 Docker가 빌드하거나 pull한 이미지는 컨테이너 런타임과 쿠버네티스에 보이지 않아요. 쿠버네티스가 사용할 수 있게 하려면 어떤 레지스트리에 push해야 해요.

알려진 문제 (Known issues)

일부 파일시스템 메트릭이 누락되고 메트릭 형식이 다름

Kubelet의 /metrics/cadvisor 엔드포인트는 '쿠버네티스 시스템 구성 요소용 메트릭' 문서에 설명된 대로 Prometheus 메트릭을 제공해요. 그 엔드포인트에 의존하는 메트릭 수집기를 설치했다면 다음 문제를 볼 수 있어요.

  • Docker 노드의 메트릭 형식은 k8s_<container-name>_<pod-name>_<namespace>_<pod-uid>_<restart-count>인데, 다른 런타임의 형식은 달라요. 예를 들어 containerd 노드에서는 <container-id>예요.
  • 다음과 같이 일부 파일시스템 메트릭이 누락돼요:
container_fs_inodes_free
container_fs_inodes_total
container_fs_io_current
container_fs_io_time_seconds_total
container_fs_io_time_weighted_seconds_total
container_fs_limit_bytes
container_fs_read_seconds_total
container_fs_reads_merged_total
container_fs_sector_reads_total
container_fs_sector_writes_total
container_fs_usage_bytes
container_fs_write_seconds_total
container_fs_writes_merged_total

해결 방법

cAdvisor를 독립형 daemonset으로 사용해 이 문제를 완화할 수 있어요.

  • vX.Y.Z-containerd-cri 이름 패턴(예: v0.42.0-containerd-cri)의 최신 cAdvisor 릴리스를 찾으세요.
  • cAdvisor Kubernetes Daemonset 문서의 단계를 따라 daemonset을 만드세요.
  • 설치된 메트릭 수집기가 전체 Prometheus 컨테이너 메트릭 세트를 제공하는 cAdvisor /metrics 엔드포인트를 사용하도록 지정하세요.

대안:

  • 대체 서드파티 메트릭 수집 솔루션을 사용하세요.
  • /stats/summary에서 제공되는 Kubelet summary API에서 메트릭을 수집하세요.

더 알아보기 (Learn more)