1. 쿠버네티스란?
쿠버네티스는 배포를 위해 사용하는 오픈소스이다.
원하는 배포를 정의하는 구성파일, 배포할 컨테이너, 인스턴스 수, 스케일을 확장해야 하는지, 교체해야하는지 등을 설정할 수 있다.
그 다음 특정 도구를 사용하여 클라우드 프로바이더 또는 실제로 올바르게 구성된 우리의 자체 머신에 전달한다.
그러면 그 구성에 지정된 리소스와 배포를 생성하기 위해 쿠버네티스 구성을 적용한다.
쿠버네티스는 도커를 대신하는것이 아니다.
도커 컨테이너와 함께 작동하여 컨테이너를 어디에나 배포할수 있게 하는 것이다.
여러 머신을 위한 docker-compose라고 생각할 수 있다.
2. 수동 배포의 문제점
컨테이너가 충돌하거나 다운될 경우 새 컨테이너로 교체해야 한다.
트래픽 급증시 더 많은 인스턴스가 필요하다.
들어오는 트래픽이 줄어들고나면 컨테이너를 다시 제거해줘야 한다.
http트래픽에 대해서도 실행중인 컨테이너 인스턴스에 균등하게 분산되도록 하고자 한다.
3. 개념
쿠버네티스 세계에서는 포드라는것에 의해 관리된다.
포드는 쿠버네티스 세계의 가장 작은 단위로 생각할 수 있으며 이를 쿠버네티스를 위한 구성파일에서 정의할 수 있다.
그리고 포드는 단순히 컨테이너를 보유한다.
실제로 포드는 항상 함께 작동해야 하는 여러 컨테이너를 보유할 수 있지만 가장 작은 단위는 단순히 하나의 포드이며
그런 다음 컨테이너를 실행할 책임이 있어 이 컨테이너를 실행한다.
이제 내부에 컨테이너가 있는 이 포드는 워커노드에서 자신을 실행한다.
즉 워커노드는 결국 컨테이너를 실행하는 쿠버네티스 세계 내의 것이다.
워커노드를 머신, 가상 인스턴스라고 생각할 수 있다.
즉 EC2 인스턴스는 워커 노드가 되는것이다.
워커노드는 특정양의 CPU와 메모리가 있는 어딘가의 머신, 즉 컴퓨터이며 그 머신에서 포드를 실행할 수 있다.
그리고 동일한 워커 노드중 하나에서 둘 이상의 포드를 실행할 수 있다.
이제 쿠버네티스에는 프록시가 필요하다.
이 프록시는 결국 쿠버네티스가 워커노드에서 워커노드의 포드 네트워크 트래픽의 제어를 설정하는 또다른 도구이다.
즉 프록시는 기본적으로 이러한 포드가 인터넷에 연결할 수 있는지의 여부와 이러한 포드 및 그 내부에서
실행되는 컨테이너를 외부 세계에서 어떻게 접근할 수 있는지를 제어한다.
예를 들어 이러한 포드의 컨테이너에서 웹 애플리케이션을 실행하는 경우
사용자의 외부 트래픽이 이 컨테이너에 도달할 수 있도록 프록시를 구성해야 한다.
쿠버네티스로 작업할 때 일반적으로 하나 이상의 워커노드가 필요하다.
더 큰 애플리케이션의 경우 일반적으로 다른 포드를 실행할 수 있는 둘이상의 워커 노드가 존재한다.
모든 컨테이너를 실행하는데 충분한 컴퓨팅 성능을 갖기 위해 둘 이상의 서버가 필요할 수 있으며 이는 컨테이너 스케일링을 포함한다.
쿠버네티스를 사용하여 컨테이너 및 포드를 동적으로 추가 및 제거하는 경우 트래픽이 들어오고 감소함에 따라
이러한 포드는 쿠버네티스에 의해 사용가능한 모든 워커노드로 자동으로 배포된다.
따라서 여러 워커 노드에서 서로 다르면서 동일한 컨테이너를 실행하여 워커로드를 고르게 분배할 수 있다.
이제 이러한 워커노드가 그 노드에서 실행되는 포드 및 컨테이너를 어떻게든 제어해야 한다.
누군가는 이러한 컨테이너와 포드를 만들고 시작해야 하며 실패하거나 더이상 필요하지 않은 경우 이를 교체하거나 종료해야 한다.
즉 이것은 기본적으로 워커 노드와 상호 작용하여 제어하는 컨트롤 센터이다.
따라서 쿠버네티스로 작업할때 일반적으로 워커노드 또는 포드와 직접 상호작용하지 않지만
쿠버네티스와 이 컨트롤 플레인이 그 무거운 짐을 지게 놔둔다.
그리고 우리는 개발자로서 원하는 종료상태를 정의하면 쿠버네티스가 그것을 고려한다.
따라서 이 마스터 노드는 단순히 다른서버, 다른 리모트 머신이다.
워커노드와 워커노드 상에서 실행중인 포드와 상호작용하는 책임을 가진다.
이론적으로 마스터 노드이자, 유일한 워커 도느 역할을 하는 하나의 머신을 가질수 있지만
더 큰 배포의 경우에는 고가용성을 보장하기 위해 자체적으로 여러 머신에 분할될 수 있는 마스터 노드가 있고
워커노드는 다른 인스턴스, 마스터노드와 독립적인 다른 머신이 된다.
따라서 하나의 워커노드가 다운되어도 마스터 노드가 함께 다운되지 않는다.
마스터 노드의 이 컨트롤 플레인은 실제로는 마스터 노드에서 실행되는 다양한 서비스의 다양한 도구 모음이다.
이 모든것이 클러스터를 형성한다.
이것은 마스터 및 워커 노드의 클러스터를 형성하고 이러한 모든 부분이 연결된 하나의 네트워크를 형성한다.
그런 다음 마스터 노드는 클라우드 프로바이더 API에 명령을 보내 그 클라우드 프로바이더에게
클라우드 프로바이더의 특정 리소스를 생성하고 원하는 큰그림, 이 최종상태를 복제하도록 지시한다.
4. 워커노드
워커노드는 어딘가에서 실행중인 EC2 인스턴스라고 생각하면된다.
워커노드는 마스터 노드가 관리하고 내부에 포드가 있다.
포드는 하나 이상의 애플리케이션 컨테이너와 이러한 컨테이너에 속한 모든 리소스를 호스팅한다.
예를 들어 컨테이너를 올바르게 실행하기 위한 구성뿐 아니라 볼륨과 같은것도 리소스에 들어가 있다.
포드 자체는 이 마스터 노드에 의해 즉 쿠버네티스에 의해 관리된다.
따라서 쿠버네티스는 포드를 생성하거나 삭제할 수 있다.
포드가 삭제되면 포드는 내부적으로 포드에 속한 컨테이너를 실행하고 관리할 수 있다.
보통 하나의 포드에 하나의 컨테이너가 있지만 밀접하게 작동해야 하는 여러 컨테이너가 있는 경우에는
포드 내부에 여러 컨테이너를 가질수도 있다. 또한 추가 리소스가 필요할 수도 있다.
예를들면 컨테이너가 통신할수 있는 하드 드라이브의 일부 공간이다.
주어진 워커노드에 둘이상의 포드가 실행되는게 일반적이다.
하나의 동일한 컨테이너에서 여러 인스턴스를 실행하여 들어오는 트래픽을 분산하려는 경우에 대비하는것이다.
그러나 완전히 다른 작업을 수행하기 위해 내부에 완전히 다른 컨테이너가 있는 포드일 수도 있다.
5. 마스터노드
마스터 노드에서는 API서버가 가장 중요하다.
이것은 워커 노드에서 실행되는 kubelet 서비스에 대한 카운터 포인트인 마스터 노드 머신에서 실행되는 간단한 서비스이다.
즉 이것은 워커와 마스터 노드간의 통신을 위한 카운터 파트이다.
이 API서버 외에도 마스터 노드 머신에 설치되어 실행되는 또다들 서비스는 기본적으로 포드를 관찰하고
새 포드가 생성되어야 하는 워커노드를 선택하는 일을 담당하는 스케줄러가 있다.
큐브 컨트롤 매니저라는 서비스를 가지고 있다.
이 서비스는 워커노드 전체를 감시하고 제어하며 적당한 수의 포드를 가동중에 있는지 확인하는 역할을 한다.
클라우드 컨트롤러 매니저는 큐브 컨트롤러 매니저와 동일한 작업을 수행하지만 클라우드 프로바이더에 따라 다르다.
그런 다음 AWS 또는 마이크로 소프트 Azure와 같은 클라우드 프로바이더에게 무엇을 해야하는지 알려준다.
즉 이 클라우드 컨트롤러 매니저는 AWS, Azure, 사용중인 프로바이더가 무엇이든 그에게 명령을 번역한다.
6. 중요 용어, 개념
(1) Cluster
클러스터는 노드머신, 마스터, 워커노드, 배포 혹은 원하는 최종상태를 구성하는 모든것의 컬랙션 세트이다.
(2) Nodes
하나 또는 여러개의 포드를 호스팅하는 특정 하드웨어 용량을 가지며
클러스터와 통신하거나 클러스터 내에서 통신하는 물리적인 머신 또는 가상머신이다.
(3) Master Node
모든 워커 노드를 걸쳐 포드를 관리하는 컨트롤 플레인을 가진 마스터 노드가 있다.
(4) Worker Node
포드를 호스팅하는 실제 머신이며 결국 앱컨테이너와 이러한 컨테이너에 필요한 리소스를 실행한다.
(5) Pods
애플리케이션 컨테이너와 요구 리소스가 포드라고 하는 유닛으로 결합됨을 의미한다.
포드는 컨테이너를 감싼 껍질이다.
결국 컨테이너를 시작하여 그 특정 컨테이너를 관리한다.
포드 자체는 마스터 노드에 의해 관리된다.
포드가 생성되는 것은 포드에서 컨테이너를 실행하는것과 같다.
(6) Containers
일반 도커 컨테이너이다.
(7) Services
고유한 포드 및 컨테이너에 독립적인 IP주소를 가진 포드 그룹이다.
서비스는 포드에 접근하는데 중요하며 그안에 있는 컨테이너도 중요하다.
서비스는 프록시와 관련이 있다.
서비스는 쿠버네티스 시계에서 특정 포드를 외부 세계에 노출하여 특정 IP주소 또는 도메인으로
특정 포드에 연결할수 있도록 하는 용어일 뿐이다.
'개발 > Docker' 카테고리의 다른 글
[Docker] docker context 이슈 (0) | 2024.09.30 |
---|---|
[Docker] `error storing credentials - err: exit status 1, out: `pass not initialized: exit status 1: Error: password store is empty. Try "pass init".`` (0) | 2023.05.15 |
[Docker] docker로 mariadb 개발환경 구축하기 (0) | 2023.02.05 |
[Docker] 도커 마운트 경로 오류 (0) | 2022.12.14 |
[Docker] DockerHub 사용하기 (0) | 2022.12.13 |