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

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

오케스트레이션 시스템

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

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

컨테이너의 간략한 역사

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

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

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

IP 주소가 할당된 논리적 구조로 가는 동안 IP 패킷은 어떤 경계를 통과합니까?

네트워킹 관점에서 보면 Kubernetes와 OpenShift는 모두 계층적 접근 방식으로 논리적이고 관련성이 높은 구조를 생성하지만 각 시스템 간의 어휘에는 약간의 차이가 있습니다.이에 대한 설명이 아래에 나와 있습니다.

컨테이너 클러스터의 ABC

이 다이어그램은 쿠버네티스 환경의 기본적인 논리적 구조를 보여줍니다.각 구조가 무엇을 하는지는 설명하지 않고, 논리적으로 서로 어떻게 관련되는지에 대해서만 설명합니다.

가장 넓은 구조부터 시작하여 가장 작은 구조까지 간단한 설명은 다음과 같습니다.

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

컨테이너의 보안 문제

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

더 많은 것에 관심이 있으세요? 체크아웃 컨테이너 세분화에 대한 네트워크 기반 접근 방식의 문제와 호스트 기반 세분화를 사용하여 이를 극복하는 방법에 대한 백서입니다.