K8s와 OCP
레드햇 오픈시프트 컨테이너 플랫폼(RHOCP)은 서버 클러스터에서 애플리케이션을 실행하기 위한 완전한 플랫폼입니다. 오픈시프트는 컨테이너와 쿠버네티스와 같은 기존 기술을 기반으로 합니다. 컨테이너는 컨테이너 런타임이 있는 모든 시스템에서 실행될 수 있는 애플리케이션과 그 의존성을 패키징하는 방법을 제공합니다.
쿠버네티스는 컨테이너화된 애플리케이션을 실행하는 서버 클러스터를 구축하기 위한 많은 기능을 제공합니다. 그러나 쿠버네티스는 완전한 솔루션을 제공하려는 것이 아니라, 시스템 관리자가 쿠버네티스를 완성할 수 있도록 확장 지점을 제공합니다. 오픈시프트는 쿠버네티스의 확장 지점을 기반으로 완전한 플랫폼을 제공합니다.
컨테이너 개요
컨테이너는 호스트의 다른 컨테이너와 독립적으로 애플리케이션을 실행하는 프로세스입니다. 컨테이너는 애플리케이션의 모든 런타임 의존성을 포함하는 컨테이너 이미지에서 생성됩니다. 그런 다음 컨테이너는 호스트에 어떤 의존성도 설치하지 않고, 다른 컨테이너의 의존성 간의 충돌 없이 어떤 호스트에서든 실행될 수 있습니다.
컨테이너는 네임스페이스와 제어 그룹(cgroups)과 같은 리눅스 커널 기능을 사용합니다. 예를 들어, 컨테이너는 CPU 시간 할당 및 시스템 메모리와 같은 자원 관리를 위해 cgroups를 사용합니다. 네임스페이스는 컨테이너의 프로세스와 자원을 다른 컨테이너 및 호스트 시스템으로부터 격리합니다.
오픈 컨테이너 이니셔티브(OCI)는 컨테이너, 컨테이너 이미지, 컨테이너 런타임에 대한 표준을 유지 관리합니다. 대부분의 컨테이너 엔진 구현이 OCI 사양에 맞춰 설계되었기 때문에, 사양에 따라 패키징된 애플리케이션은 어떤 준수 플랫폼에서든 실행될 수 있습니다.
K8s 개요
쿠버네티스는 컨테이너화된 애플리케이션의 배포, 관리 및 확장을 단순화하는 플랫폼입니다.
Podman과 같은 도구를 사용하여 리눅스 시스템에서 컨테이너를 실행할 수 있습니다. 예를 들어, 클러스터 전체에서 중복성을 위해 실행할 수 있는 컨테이너화된 서비스를 생성하기 위해서는 추가 작업이 필요합니다.
쿠버네티스는 여러 노드에서 애플리케이션을 실행하는 클러스터를 생성합니다. 노드가 실패하면 쿠버네티스는 다른 노드에서 애플리케이션을 다시 시작할 수 있습니다.
쿠버네티스는 선언적 구성 모델을 사용합니다. 쿠버네티스 관리자는 클러스터에서 실행할 워크로드의 정의를 작성하고, 쿠버네티스는 실행 중인 워크로드가 정의와 일치하는지 확인합니다. 예를 들어, 관리자는 여러 워크로드를 정의합니다. 각 워크로드는 필요한 메모리 양을 정의합니다. 그런 다음 쿠버네티스는 메모리 요구 사항을 충족시키기 위해 다른 노드에서 필요한 컨테이너를 생성합니다.
쿠버네티스는 워크로드를 포드의 관점에서 정의합니다. 포드는 동일한 클러스터 노드에서 실행되는 하나 또는 여러 컨테이너입니다. 여러 컨테이너가 있는 포드는 특정 상황에서 유용합니다. 예를 들어, 두 컨테이너가 어떤 자원을 공유하기 위해 동일한 클러스터 노드에서 실행되어야 할 때입니다. 예를 들어, 작업은 포드에서 완료될 때까지 작업을 실행하는 워크로드입니다.
서비스 발견 및 로드 밸런싱
여러 노드에 애플리케이션을 분산시키면 애플리케이션 간의 통신이 복잡해질 수 있습니다.
쿠버네티스는 네트워킹을 자동으로 구성하고 포드에 DNS 서비스를 제공합니다. 이러한 기능을 통해 포드는 IP 주소 대신 호스트 이름만을 사용하여 노드 간에 투명하게 다른 포드의 서비스와 통신할 수 있습니다. 여러 포드가 성능과 신뢰성을 위해 서비스를 지원할 수 있습니다. 예를 들어, 쿠버네티스는 NGINX 포드의 가용성을 고려하여 NGINX 웹 서버로 들어오는 요청을 균등하게 분배할 수 있습니다.
수평 확장
쿠버네티스는 서비스의 부하를 모니터링하고 부하에 맞춰 포드를 생성하거나 삭제할 수 있습니다. 일부 구성에서는 클러스터 부하를 수용하기 위해 동적으로 노드를 프로비저닝할 수도 있습니다.
자가 치유
애플리케이션이 건강 검사 절차를 선언하면, 쿠버네티스는 실패하거나 사용할 수 없는 애플리케이션을 모니터링, 재시작 및 재스케줄링할 수 있습니다. 자가 치유는 애플리케이션이 예기치 않게 중단되는 내부 실패와 애플리케이션을 실행하는 노드가 사용할 수 없게 되는 외부 실패로부터 애플리케이션을 보호합니다.
자동 롤아웃
쿠버네티스는 애플리케이션 컨테이너에 대한 업데이트를 점진적으로 롤아웃할 수 있습니다. 롤아웃 중에 문제가 발생하면, 쿠버네티스는 배포의 이전 버전으로 롤백할 수 있습니다. 쿠버네티스는 애플리케이션의 롤아웃된 버전으로 요청을 라우팅하고, 롤아웃이 완료되면 이전 버전의 포드를 삭제합니다.
비밀 및 구성 관리
컨테이너 변경 없이 애플리케이션의 구성 설정 및 비밀을 관리할 수 있습니다. 애플리케이션 비밀은 사용자 이름, 비밀번호, 서비스 엔드포인트 또는 비공개로 유지해야 하는 모든 구성 설정일 수 있습니다.
오퍼레이터
오퍼레이터는 쿠버네티스 워크로드를 선언적 방식으로 관리할 수 있는 패키지된 쿠버네티스 애플리케이션입니다. 예를 들어, 오퍼레이터는 데이터베이스 서버 리소스를 정의할 수 있습니다. 사용자가 데이터베이스 리소스를 생성하면, 오퍼레이터는 데이터베이스를 배포하고, 복제를 구성하며, 자동으로 백업을 생성하는 데 필요한 워크로드를 생성합니다.
쿠버네티스 아키텍처 개념 쿠버네티스는 여러 서버(노드라고도 함)를 사용하여 관리하는 애플리케이션의 복원력과 확장성을 보장합니다. 이러한 노드는 물리적 또는 가상 머신일 수 있습니다. 노드는 두 가지 유형이 있으며, 각각은 클러스터 작업의 다른 측면을 제공합니다.
Control plane nodes: 배포된 워크로드의 스케줄링을 위한 전역 클러스터 조정을 제공합니다. 이 노드들은 또한 클러스터 이벤트와 요청에 대응하여 클러스터 구성의 상태를 관리합니다.
Compute plane nodes : 사용자 워크로드를 실행합니다.
서버는 두 노드의 역할을 모두 수행할 수 있지만, 일반적으로 안정성, 보안 및 관리 용이성을 높이기 위해 두 역할을 분리합니다. 쿠버네티스 클러스터는 작은 단일 노드 클러스터부터 최대 5,000개 노드의 대규모 클러스터에 이르기까지 다양할 수 있습니다.
쿠버네티스 API 및 구성 모델
쿠버네티스는 클러스터에서 실행할 워크로드를 정의하는 모델을 제공합니다.
관리자는 리소스 측면에서 워크로드를 정의합니다.
모든 리소스 유형은 동일한 방식으로 작동하며, 통일된 API를 가집니다. `kubectl` 명령과 같은 도구는 모든 유형의 리소스, 심지어 사용자 정의 리소스 유형까지 관리할 수 있습니다.
쿠버네티스는 리소스를 텍스트 파일로 가져오거나 내보낼 수 있습니다. 텍스트 형식의 리소스 정의를 사용함으로써, 관리자는 워크로드를 생성하기 위한 올바른 작업 순서를 수행하는 대신에 워크로드를 설명할 수 있습니다. 이러한 접근 방식을 선언적 리소스 관리라고 합니다.
선언적 리소스 관리는 워크로드 생성 작업을 줄이고 유지 관리를 개선할 수 있습니다. 또한, 텍스트 파일을 사용하여 리소스를 설명할 때, 관리자는 버전 관리 시스템과 같은 일반적인 도구를 사용하여 변경 추적과 같은 추가적인 이점을 얻을 수 있습니다.
선언적 리소스 관리를 지원하기 위해 쿠버네티스는 클러스터의 상태를 지속적으로 추적하고 클러스터를 의도된 상태로 유지하기 위해 필요한 단계를 수행하는 컨트롤러를 사용합니다. 이 과정은 리소스에 대한 변경 사항이 효과가 나타나기까지 일정 시간이 걸릴 수 있음을 의미합니다. 그러나 쿠버네티스는 복잡한 변경 사항을 자동으로 적용할 수 있습니다. 예를 들어, 현재 노드에서 충족할 수 없는 애플리케이션의 RAM 요구 사항을 증가시키면, 쿠버네티스는 충분한 RAM을 가진 노드로 애플리케이션을 이동시킬 수 있습니다. 이동이 완료되면 쿠버네티스는 새 인스턴스로 트래픽을 리디렉션합니다.
쿠버네티스는 또한 네임스페이스를 지원합니다. 관리자는 네임스페이스를 생성할 수 있으며, 대부분의 리소스는 네임스페이스 내부에서 생성되어야 합니다. 대량의 리소스를 조직하는 데 도움을 주는 것 외에도, 네임스페이스는 리소스 접근과 같은 기능의 기초를 제공합니다. 관리자는 특정 사용자가 리소스를 보거나 수정할 수 있도록 네임스페이스에 대한 권한을 정의할 수 있습니다.