컨테이너 해부학 101: 클러스터란 무엇인가요?

네트워킹 관점에서 컨테이너는 네트워크 전달 결정과 최종 목적지에 도달하는 패킷 사이의 경계인 네트워크 "에지(" )를 호스트 깊숙이 확장합니다. 엣지는 더 이상 호스트의 네트워크 인터페이스가 아니라 호스트 내부의 논리적 구조에 여러 계층 깊숙이 자리 잡고 있습니다. 또한 네트워크 토폴로지는 추상화되어 오버레이 네트워크 터널링, 가상 인터페이스, NAT 경계, 로드 밸런서, 네트워킹 플러그인 등의 형태로 호스트 내의 이러한 논리적 구조에 깊숙이 도달합니다. 네트워크 및 보안 설계자는 아키텍처를 설계할 때 더 이상 OS 내부를 무시할 수 없습니다. 컨테이너는 이러한 아키텍처가 패킷이 호스트의 NIC를 통과한 후 어디로 가는지 이해하도록 합니다. 

오케스트레이션 시스템

즉, 컨테이너 환경에 어떤 형태의 질서를 가져오려면 오케스트레이션 시스템이 필요합니다. 오케스트레이션 시스템은 컨테이너 구성, 확장 및 자동화와 관련된 세부 사항을 관리하고 컨테이너 동작과 관련된 다양한 구성 요소를 중심으로 논리적 구성을 생성합니다. 또한 컨테이너 런타임과 관련된 논리적 경계를 구성하고 IP 주소를 할당할 수 있는 논리적 구성을 생성하는 역할도 담당합니다. 즉, 이러한 시스템은 외부에 있으며 실제로 특정 컨테이너 런타임 인스턴스의 수명 주기를 배포하고 관리할 수 없으며, 이는 예를 들어 여전히 Docker에서 처리합니다.  

많은 컨테이너 오케스트레이션 시스템이 있지만, 오늘날 가장 일반적으로 사용되는 두 가지 시스템은 Kubernetes와 OpenShift입니다. 둘 다 동일한 기본 목표를 달성하지만, 하나는 프로젝트이고 다른 하나는 제품이라는 점이 가장 큰 차이점입니다: Kubernetes는 주로 Google에서 탄생한 프로젝트이며, OpenShift는 Red Hat에서 소유한 제품입니다. 일반적으로 Kubernetes는 퍼블릭 클라우드 환경에서 가장 많이 사용되고 OpenShift는 온프레미스 데이터 센터에서 가장 많이 사용되지만, 둘 사이에는 상당 부분 중복되는 부분이 있습니다. 요컨대, 쿠버네티스는 두 접근법의 기반이 되지만, 각 접근법 간에는 약간의 용어 차이가 있습니다. 

컨테이너의 간략한 역사

믿거나 말거나, 컨테이너는 Kubernetes보다 먼저 시작되었습니다. 예를 들어, Docker는 2013년에 컨테이너 플랫폼을 처음 출시한 반면, Kubernetes는 2014년에야 퍼블릭 클라우드에 초점을 맞춘 프로젝트를 출시했습니다. OpenShift는 온프레미스 데이터센터에 배포된 호스트에 중점을 두고 두 서비스보다 먼저 출시되었습니다.  

일반적으로 로컬 호스트에 컨테이너 런타임을 배포하는 것만으로도 개발자의 요구 사항을 충족할 수 있습니다. 런타임은 "localhost" 및 고유 포트를 통해 서로 통신할 수 있기 때문입니다. 컨테이너 런타임에는 특정 IP 주소가 할당되지 않습니다. 빠르고 효율적인 코드를 작성하고 관련 컨테이너 런타임 모음에 애플리케이션을 배포하는 데 집중하는 경우 이 접근 방식이 적합합니다. 그러나 해당 애플리케이션이 로컬 호스트 외부의 외부 리소스에 액세스하도록 하거나 외부 클라이언트가 해당 애플리케이션에 액세스하도록 하려면 네트워킹 세부 정보를 무시할 수 없습니다. 이것이 오케스트레이션 시스템이 필요한 이유 중 하나입니다.   

쿠버네티스는 컨테이너 런타임의 동작을 구성하기 위해 일련의 빌딩 블록과 API 중심 워크플로우를 중심으로 만들어졌습니다. 이 접근 방식에서, 쿠버네티스는 특정 컨테이너화된 환경과 관련된 호스트 내부 및 호스트 간에 일련의 논리적 구성을 생성하고 이러한 구성을 참조하기 위해 완전히 새로운 어휘 집합을 생성합니다. 쿠버네티스는 CPU 할당, 메모리 요구 사항 및 스토리지, 인증, 계량과 같은 기타 메트릭과 관련된 일련의 컴퓨팅 메트릭을 중심으로 이러한 빌딩 블록과 API 기반 워크플로우를 적용하지만, 대부분의 보안 및 네트워킹 전문가는 한 가지에 집중하고 있습니다:

IP 패킷은 IP 주소가 할당된 논리적 구조로 이동하는 도중에 어떤 경계를 통과할까요? 

네트워킹 관점에서 볼 때, Kubernetes와 OpenShift는 각 시스템 간에 약간의 어휘 차이만 있을 뿐 계층적 접근 방식으로 논리적이고 관련성 있는 구성을 생성합니다. 아래 그림이 이에 대한 설명입니다.

컨테이너 클러스터의 ABC

이 다이어그램은 쿠버네티스 환경의 기본 논리적 구성을 보여줍니다. 각 구성 요소가 무엇을 하는지는 설명하지 않고 서로 논리적으로 어떻게 연관되어 있는지만 설명합니다.

가장 광범위한 구조부터 가장 작은 구조까지 간략하게 설명합니다: 

• 클러스터:클러스터: 클러스터는 특정 컨테이너화된 배포와 관련된 호스트의 모음입니다. 
• 노드:클러스터 내부에는 노드가 있습니다. 노드는 컨테이너가 상주하는 호스트입니다. 호스트는 물리적 컴퓨터 또는 가상 머신이 될 수 있으며, 온프레미스 데이터 센터 또는 퍼블릭 클라우드에 상주할 수 있습니다. 일반적으로 클러스터에는 '마스터 노드'와 '작업자 노드'라는 두 가지 범주의 노드가 있습니다. 지나치게 단순화하자면, 마스터 노드는 클러스터의 중앙 데이터베이스와 API 서버를 제공하는 제어 영역입니다. 워커 노드는 실제 애플리케이션 파드를 실행하는 머신입니다. 
• 파드:각 노드 내부에서 Kubernetes와 OpenShift는 모두 파드를 생성합니다. 각 파드는 하나 이상의 컨테이너 런타임을 포함하며 오케스트레이션 시스템에 의해 관리됩니다. 파드는 쿠버네티스와 오픈시프트에 의해 IP 주소가 할당된다.
• 컨테이너:컨테이너 런타임이 상주하는 곳은 파드 내부입니다. 특정 파드 내의 컨테이너는 모두 해당 파드와 동일한 IP 주소를 공유하며, 고유 포트를 사용하여 로컬호스트를 통해 서로 통신합니다.
• 네임스페이스:특정 애플리케이션이 클러스터의 여러 노드에 걸쳐 "수평으로" 배포되며 리소스 및 권한을 할당하기 위한 논리적 경계를 정의합니다. 파드(따라서 컨테이너)와 서비스뿐만 아니라 역할, 시크릿 및 기타 많은 논리적 구성도 네임스페이스에 속한다. OpenShift에서는 이를 프로젝트라고 부르지만 동일한 개념입니다. 일반적으로 네임스페이스는 특정 애플리케이션에 매핑되며, 해당 애플리케이션 내의 모든 관련 컨테이너에 배포됩니다. 네임스페이스는 네트워크 및 보안 구성과 관련이 없습니다(Linux IP 네임스페이스와는 다름). 
• 서비스:파드는 갑자기 사라졌다가 나중에 동적으로 다시 배포될 수 있는 임시적일 수 있으므로, 서비스는 일련의 연결된 파드 앞에 배포되는 '프론트엔드'이며 파드가 사라져도 사라지지 않는 VIP가 있는 로드밸런서처럼 기능합니다. 서비스는 자체 IP 주소를 가진 비임시적 논리 구조입니다. Kubernetes와 OpenShift 내에서 몇 가지 예외를 제외하고, 외부 연결은 서비스의 IP 주소를 가리키고 "백엔드" 파드로 전달됩니다. 
• 쿠버네티스 API 서버: API 워크플로우가 중앙 집중화되는 곳으로, Kubernetes가 이러한 모든 논리적 구성의 생성 및 수명 주기를 관리합니다. 

컨테이너의 보안 문제 

워크로드 경계를 따라 보안 세그먼트를 생성하려면 Kubernetes에서 생성된 이러한 기본 논리 구조를 이해해야 합니다. 호스팅된 애플리케이션에서 들어오고 나가는 외부 네트워크 트래픽은 일반적으로 기본 호스트인 노드의 IP 주소를 가리키지 않습니다. 대신 네트워크 트래픽은 해당 호스트 내의 서비스 또는 파드를 가리키게 됩니다. 따라서 효과적인 세분화 보안 아키텍처를 만들려면 워크로드의 관련 서비스 및 파드를 충분히 이해해야 합니다. 

더 자세히 알고 싶으신가요? 컨테이너 세분화에 대한 네트워크 기반 접근 방식의 문제점과 호스트 기반 세분화를 사용하여 이를 극복하는 방법에 대한 백서를 확인해 보세요.