7장. 컨테이너 작업
7.1. 컨테이너 이해
AWS 애플리케이션의 Red Hat OpenShift Service의 기본 단위는 컨테이너 라고 합니다. Linux 컨테이너 기술은 실행 중인 프로세스를 격리하는 데 필요한 간단한 메커니즘으로, 이를 통해 실행 중인 프로세스는 지정된 리소스하고만 상호 작용하도록 제한됩니다.
많은 애플리케이션 인스턴스는 서로의 프로세스, 파일, 네트워크 등을 보지 않으며 단일 호스트의 컨테이너에서 실행될 수 있습니다. 컨테이너를 임의의 워크로드에 사용할 수는 있지만 일반적으로 각 컨테이너는 웹 서버나 데이터베이스 같은 단일 서비스(흔히 “마이크로 서비스”라고 함)를 제공합니다.
Linux 커널은 수년간 컨테이너 기술을 위한 기능을 통합해 왔습니다. AWS 및 Kubernetes의 Red Hat OpenShift Service는 다중 호스트 설치에서 컨테이너를 오케스트레이션하는 기능을 추가합니다.
7.1.1. 컨테이너 및 RHEL 커널 메모리 정보
RHEL(Red Hat Enterprise Linux) 동작으로 인해 CPU 사용량이 많은 노드의 컨테이너에서 예상보다 많은 메모리를 사용하는 것처럼 보일 수 있습니다. 메모리 사용량 증가는 RHEL 커널의 kmem_cache로 인한 것일 수 있습니다. RHEL 커널은 각 cgroup에 kmem_cache를 생성합니다. 성능 향상을 위해 kmem_cache에는 cpu_cache와 모든 NUMA 노드에 대한 노드 캐시가 포함됩니다. 이러한 캐시는 모두 커널 메모리를 사용합니다.
이러한 캐시에 저장된 메모리 양은 시스템에서 사용하는 CPU 수에 비례합니다. 결과적으로 CPU 수가 많을수록 이러한 캐시에 더 많은 양의 커널 메모리가 저장됩니다. 이러한 캐시에서 많은 양의 커널 메모리가 발생하면 AWS 컨테이너의 Red Hat OpenShift Service가 구성된 메모리 제한을 초과하여 컨테이너가 종료될 수 있습니다.
커널 메모리 문제로 인한 컨테이너 손실을 방지하려면 컨테이너에서 메모리를 충분히 요청해야 합니다. 다음 공식을 사용하여 kmem_cache 에서 사용하는 메모리 양을 추정할 수 있습니다. 여기서 nproc 은 nproc 명령에서 보고하는 처리 단위의 수입니다. 컨테이너 요청의 하한은 이 값에 컨테이너 메모리 요구 사항을 더한 값이어야 합니다.
$(nproc) X 1/2 MiB
7.1.2. 컨테이너 엔진 및 컨테이너 런타임 정보
컨테이너 엔진은 명령줄 옵션 및 이미지 가져오기를 포함하여 사용자 요청을 처리하는 소프트웨어입니다. 컨테이너 엔진에서는 하위 수준 컨테이너 런타임 이라고도 하는 컨테이너 런타임 을 사용하여 컨테이너 배포 및 운영에 필요한 구성 요소를 실행하고 관리합니다. 컨테이너 엔진 또는 컨테이너 런타임과 상호 작용할 필요가 없습니다.
Red Hat OpenShift Service on AWS 문서에서는 컨테이너 런타임 이라는 용어를 사용하여 하위 수준 컨테이너 런타임을 참조합니다. 기타 설명서에서는 컨테이너 엔진을 컨테이너 런타임으로 참조할 수 있습니다.
AWS의 Red Hat OpenShift Service는 CRI-O를 컨테이너 엔진으로 사용하고 C 또는 crun을 컨테이너 런타임으로 사용합니다. 기본 컨테이너 런타임은 runC입니다.
