7장. 컨테이너 작업

RHEL(Red Hat Enterprise Linux) 동작으로 인해 CPU 사용량이 많은 노드의 컨테이너에서 예상보다 많은 메모리를 사용하는 것처럼 보일 수 있습니다. 메모리 사용량 증가는 RHEL 커널의 kmem_cache로 인한 것일 수 있습니다. RHEL 커널은 각 cgroup에 kmem_cache를 생성합니다. 성능 향상을 위해 kmem_cache에는 cpu_cache와 모든 NUMA 노드에 대한 노드 캐시가 포함됩니다. 이러한 캐시는 모두 커널 메모리를 사용합니다.

이러한 캐시에 저장된 메모리 양은 시스템에서 사용하는 CPU 수에 비례합니다. 결과적으로 CPU 수가 많을수록 이러한 캐시에 더 많은 양의 커널 메모리가 저장됩니다. 이러한 캐시의 커널 메모리 양이 늘어나면 OpenShift Container Platform 컨테이너가 구성된 메모리 제한을 초과하여 컨테이너가 종료될 수 있습니다.

커널 메모리 문제로 인한 컨테이너 손실을 방지하려면 컨테이너에서 메모리를 충분히 요청해야 합니다. 다음 공식을 사용하면 kmem_cache 에서 사용되는 메모리 양을 추정할 수 있습니다. 여기서 nproc는 nproc 명령에서 보고하는 사용 가능한 처리 단위 수입니다. 컨테이너 요청의 하한은 이 값에 컨테이너 메모리 요구 사항을 더한 값이어야 합니다.

$(nproc) X 1/2 MiB

$(nproc) X 1/2 MiB

컨테이너 엔진은 명령줄 옵션과 이미지 풀을 포함하여 사용자 요청을 처리하는 소프트웨어입니다. 컨테이너 엔진은 컨테이너 런타임 ( 하위 수준 컨테이너 런타임 이라고도 함)을 사용하여 컨테이너를 배포하고 운영하는 데 필요한 구성 요소를 실행하고 관리합니다. 컨테이너 엔진이나 컨테이너 런타임과 상호 작용할 필요는 없을 것입니다.

OpenShift Container Platform은 컨테이너 엔진으로 CRI-O를 사용하고 컨테이너 런타임으로 runC 또는 crun을 사용합니다. 기본 컨테이너 런타임은 crun입니다. 두 컨테이너 런타임 모두 OCI(Open Container Initiative) 런타임 사양을 준수합니다.

CRI-O는 Kubernetes 네이티브 컨테이너 엔진 구현으로 운영 체제와 긴밀하게 통합되어 효율적이고 최적화된 Kubernetes 환경을 제공합니다. CRI-O 컨테이너 엔진은 각 OpenShift Container Platform 클러스터 노드에서 systemd 서비스로 실행됩니다.

Red Hat에서 개발한 crun은 C로 완전히 작성된 빠르고 메모리 사용량이 적은 컨테이너 런타임입니다. Docker에서 개발하고 Open Container Project에서 유지 관리하는 runC는 Go로 작성된 가볍고 이식성이 뛰어난 컨테이너 런타임입니다.

crun은 runC에 비해 다음을 포함하여 여러 가지 개선 사항이 있습니다.

runC는 crun에 비해 다음과 같은 몇 가지 장점이 있습니다.

필요에 따라 두 컨테이너 런타임 사이를 이동할 수 있습니다.

사용할 컨테이너 런타임을 설정하는 방법에 대한 자세한 내용은 CRI-O 매개변수를 편집하기 위한 ContainerRuntimeConfig CR 만들기를 참조하세요.