about me
20'S LIFE IN SYDNEY and BUSAN
쿠버네티스의 아키텍처
포드(Pod)
우리가 배포하고자 하는 컨테이너로 시작한다. 쿠버네티스 세계에서는 소위 포드(Pod)라는 것에 의해 관리되는데, 포드는 쿠버네티스 세계의 가장 작은 단위로 생각할 수 있으며, 이를 쿠버네티스를 위한 구성 파일에서 정의할 수 있다.
그리고 포드는 단순히 컨테이너를 보유한다.
실제로 포드는 항상 함께 작동해야 하는 여러 컨테이너를 보유할 수 있지만, 가장 작은 단위는 단순히 하나의 포드이며, 그런 다음 컨테이너를 실행할 책임이 있어 이 컨테이너를 실행한다.
워커(worker) 노드
내부에 컨테이너가 있는 포드는 소위 워커(worker) 노드에서 자신을 실행한다. 즉, 워커 노드는 결국 컨테이너를 실행하는 쿠버네티스 세계 내의 것이다. 그리고 워커 노드를 머신, 가상 인스턴스라고 생각할 수 있다.
예를 들어 AWS 세계에서 사용자가 완전히 소유하고, 관리하는 리모트 머신인 EC2 인스턴스는 워커 노드가 되는것이다.
워커 노드는 특정 양의 CPU와 메모리가 있는 어딘가의 머신, 즉, 컴퓨터이며 그 머신에서 포드를 실행할 수 있다.
그리고 동일한 워커 노드 중 하나에서 둘 이상의 포드을 실행할 수 있다.
프록시
이제 워커 노드의 이 워커 노드 포드 개념 외에도 쿠버네티스에는 프록시가 필요하다. 프록시는 쿠버네티스가 워커 노드에서
워커 노드의 포드 네트워크 트래픽의 제어를 설정하는 또다른 도구이다.
프록시는 기본적으로 이러한 포드가 인터넷에 연결할 수 있는지의 여부와 이러한 포드 및 그 내부에서 실행되는 컨테이너를 외부 세계에서 어떻게 접근할 수 있는지를 제어한다.
예를 들어, 이러한 포드의 컨테이너에서 웹 애플리케이션을 실행하는 경우 사용자의 외부 트래픽이 이 컨테이너에 도달할 수 있도록 프록시를 구성해야 한다.
컨트롤 플레인(plane)
포드와 컨테이너를 실행할 장소로써 쿠버네티스로 작업할 때 일반적으로 하나 이상의 워커 노드가 필요하다.
그러나 물론 더 큰 애플리케이션의 경우 일반적으로 다른 포드를 실행할 수 있는 둘 이상의 워커 노드가 존재한다.
모든 컨테이너를 실행하는데 충분한 컴퓨팅 성능을 갖기 위해 둘 이상의 서버가 필요할 수 있으며, 이는 컨테이너 스케일링을 포함한다.
쿠버네티스를 사용하여 컨테이너 및 포드를 동적으로 추가 및 제거하는 경우, 트래픽이 들어오고, 감소함에 따라 이러한 포드는 쿠버네티스에 의해, 사용 가능한 모든 워커 노드로 자동으로 배포된다.
따라서 여러 워커 노드에서 서로 다르면서 동일한 컨테이너를 실행하여 워크로드를 고르게 분배할 수 있다.
모든 워커 노드와 그 노드에서 실행되는 포드 및 컨테이너를 어떻게든 제어해야 한다. 누군가는 이러한 컨테이너와 포드를 만들고 시작해야 하며, 실패하거나 더 이상 필요하지 않은 경우, 이를 교체하거나 종료해야 한다.
그리고 그것은 마스터 노드에 의해 특별히 호출되는 컨트롤 플레인(plane)에 의해 수행된다.
즉, 이것은 기본적으로 워커 노드와 상호 작용하여 제어하는 컨트롤 센터이다.
따라서 쿠버네티스로 작업할 때, 일반적으로 워커 노드 또는 포드과 직접 상호작용하지 않지만, 쿠버네티스와 이 컨트롤 플레인이 그 무거운 짐을 지게 놔둔다.
개발자로서 원하는 종료 상태를 정의하면, 쿠버네티스가 그를 고려할 것이다.
따라서 마스터 노드는 단순히 다른 서버, 다른 리모트 머신이다.
마스터 노드는 마스터 노드에서 실행 중인 컨트롤 플레인을 갖고 있으며, 워커노드와 워커노드 상에서 실행중인 포드과 상호작용하는 책임을 가진다.
이론적으로 마스터 노드이자, 유일한 워커 노드 역할을 하는 하나의 머신을 가질 수 있지만, 더 큰 배포의 경우에는 고가용성을 보장하기 위해 자체적으로 여러 머신에 분할될 수 있는 마스터 노드가 있고 워커 노드는 다른 인스턴스, 마스터 노드와 독립적인 다른 머신이 된다.
따라서 하나의 워커 노드가 다운되어도 마스터 노드가 함께 다운되지는 않는다.
마스터 노드의 이 컨트롤 플레인은 실제로는 마스터 노드에서 실행되는 다양한 서비스의 다양한 도구 모음이다.
댓글