잠깐, k8s에서 docker가 deprecated 된다구?!

2021-08-25

잠깐, k8s에서 docker가 deprecated 된다구?!

들어가기 앞서

For Developers

도커 컨테이너는 여전히 존재하며, 모든게 변하는게 아니니 진정하고 천천히 글을 읽어 봐!

For admins

앞으로 도커에 대안을 신중히 고려하기 시작하는게 좋을거야

그래서 실화냐?

실화임

Docker support in the kubelet is now deprecated and will be removed in a future release. The kubelet uses a module called "dockershim" which implements CRI support for Docker and it has seen maintenance issues in the Kubernetes community. We encourage you to evaluate moving to a container runtime that is a full-fledged implementation of CRI (v1alpha1 or v1 compliant) as they become available.

https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#deprecation

짧게 말해 도커는 쿠버네티스 런타임 API인 CRI를 지원하지 않는다는 글이다.

그리고 쿠버네티스는 dockershim 라고하는 도커 API를 CRI로 변환해주는 브릿지 서비스를 사용해왔는데 이제 더이상 제공하지 않는다고 한다

도커는 로컬환경에서 개발환경을 세팅하는데 정말 강력한 도구임에 분명하지만, 이해하기 위해서 쿠버네티스 구조 안에 도커가 어떻게 동작하는지도 알아야 한다.

쿠버네티스는 가상/물리적 머신과 같은 다양한 컴퓨팅 리소스를 그룹화하며 또한 애플리케이션을 실행할 수 있다. 게다가 다른 사람과 공유할 수 있는 거대한 컴퓨팅 리소스처럼 보이게하는 인프라 오케스트레이션 도구이다.

이렇게 엄청 많은 기능을 담당하는 쿠버네티스에서 도커 또는 컨테이너 런타임은 쿠버네티스 내부에서는

단지호스트에 해당하는 애플리케이션을 사용하는데 사용되고 있다.

k8s-arc

근데 왜 도커가 더 이상 사용되지 않을까?

첫번째 이유는, 위에서 언급한것처럼 쿠버네티스는 CRI로 말하고 있는데, 도커와 대화 하려면 브리지 서비스가 필요하다. 이 브릿지 서비스를 유지보수하는게 점점 더 어려워 지고 있다.

k8s-in

두번째 이유는 위 이미지 빨간색 영역을 봐야한다

빨간색 영역은 쿠버네티스가 실제로 필요로 하는 부분인데, 쿠버네티스에 동일한 기능이 있기 때문에 도커의 기능 중 하나인 네트워크 및 볼륨은 쿠버네티스에서 사용되지 않는다.

사용하지 않는 많은 기능 자체가 보안에 위험할 수 있고, 기능이 적을수록 공격 표면적이 작아진다.

조금 더 자세히 말하자면,

도커는 클라이언트/서버 애플리케이션으로 클라이언트인 Docker CLI, 서버인 Docker daemon으로 구성된다.

그 중 서버는 컨테이너 이미지 빌드, 관리, 공유, 시행 및 컨테이너 인스턴스와 관리와 같이 너무 많은 기능을 담당하고, 데몬으로 모든 컨테이너 자식 프로세스로 소유하게 된다.

이로 인해 무거울 뿐 아니라 장애가 ㅂ라생하면 모든 자식프로세스에 영향을 끼쳐 Single point of failure 의 위험이 있다.

그리고 리눅스의 auido.log를 통해 관리자가 시스템의 보안 이벤트를 감시하고 기록된 정보를 볼 수 있는 audit 보안 기능 또한 사용할 수 없게 된다.

추가로 모든 도커 명령은 루트 권한을 가진 사용자에 의해서만 실행할 수 있어 보안에 문제가 생길 수 있다.

그래서 대안을 고려하기 시작했고 CRI 런타임이 나타났다.

CRI 런타임

두 가지 주요 CRI 런타임이 존재한다. containerd, CRI-O

containerd

위 빨간 박스가 있는 이미지에서 볼 수 있듯 런타임 작업을 수행하기 위해서 실제로 containerd가 도커 내부에서 사용되고 있다.

그렇기 때문에 만약 도커에서 새로운 환경으로 마이그레이션을 하려 한다면 가장 좋은 선택지가 될 수 있다.

따라서 CRI, 도커 모두 만족시킬 수 있는 대안중 하나다

containerd

CRI-O

Red Hat에서 개발한 CRI 런타임인데 현재 Red Hat OpenShift에서 사용되고 있으며, 더 이상 도커에 의존하지 않는다

재밌는점은 RHEL7은 도커를 공식적으로 지원하지 않고, 대신 컨테이너 환경을 위한 Podman, Builda 및 CRI-O를 제공하고 있다.

CRI-O의 강점은 CRI 런타임으로 만들어졌기 때문에 미니멀리즘에 있다. 반면에 containerd의 경우 도커의 일부로 시작되었다.

그래서 containerd에 비해 CRI-O는 순수하게 필요한 기능만 있다. 이런 특징 때문에 도커에서 마이그레이션을 하는게 어려울 수 있지만

쿠버네티스에서 필요한 기능들이 모두 제공되는 장점이 있다.

결론

  1. 자체구축 쿠버네티스 서비스 관리자
    • 도커는 확실히 더 이상 사용되지 않을거고, k8s 관리자라면 containerd 및 CRI-O와 같은 CRI 런타임을 고려해야 한다.
    • CRI와 OCI 런타임 책임 및 범위를 차이점을 알아야 한다.
  2. 클라우드 쿠버네티스 서비스 관리자(AWS EKS와 같은) -> 클라우드에서 관리해줄테니 업데이트하면 자동으로 바뀐다.
  3. 쿠버네티스를 사용하는 개발자 -> 평소처럼 YAML 만들어 배포하면 된다.

참고