Kubernetes 작동 방식
Kubernetes 설치를 성공적으로 구성하려면 Kubernetes 시스템 아키텍처에 대해 잘 알고 있어야 합니다. 여기서는 Kubernetes 설치를 구성하는 모든 구성 요소를 살펴봅니다.
컴퓨터 클러스터란?
클러스터는 함께 작동하고 단일 시스템으로 볼 수 있도록 구성하는 컴퓨터 세트입니다. 클러스터에 구성된 컴퓨터는 동일한 종류의 작업을 처리합니다. 예를 들어 모두 웹 사이트, API를 호스트하거나 컴퓨팅 집약적 작업을 실행합니다.
클러스터는 해당 작업을 예약하고 제어하는 중앙 집중형 소프트웨어를 사용합니다. 작업을 실행하는 클러스터의 컴퓨터를 ‘노드’라고 하며, 소프트웨어 예약을 실행하는 컴퓨터를 컨트롤 ‘플레인’이라고 합니다.
Kubernetes 아키텍처
앞서 언급한 대로 오케스트레이터는 앱을 배포하고 관리하는 시스템입니다. 또한 클러스터는 함께 작동하고 단일 시스템으로 표시되는 컴퓨터 집합이라는 것도 배웠습니다. Kubernetes를 오케스트레이션 및 클러스터 소프트웨어로 사용하여 앱을 배포하고 컴퓨팅 리소스 요구 사항의 변화에 대응합니다.
Kubernetes 클러스터에는 하나 이상의 기본 플레인과 하나 이상의 노드가 포함되어 있습니다. 컨트롤 플레인 및 노드 인스턴스는 둘 다 클라우드의 물리적 디바이스, 가상 머신 또는 인스턴스가 될 수 있습니다. Kubernetes의 기본 호스트 OS는 Linux이며 Linux 기반 워크로드를 기본적으로 지원합니다.
클러스터 노드에서 Windows Server 2019 이상을 사용하여 Microsoft 워크로드를 실행할 수도 있습니다. 예를 들어 드론 추적 앱의 데이터 처리 서비스가 특정 Windows OS API 호출을 사용하는 .NET 4.5 앱으로 작성되었다고 가정합니다. 이 서비스는 Windows Server OS를 실행하는 노드에서만 실행할 수 있습니다.
이제 컨트롤 플레인과 작업자 노드, 각각에서 실행되는 소프트웨어를 자세히 살펴봅니다. 각 구성 요소의 역할과 클러스터에서 각 구성 요소를 실행하는 위치를 이해하면 Kubernetes를 설치할 때 도움이 됩니다.
Kubernetes 컨트롤 플레인
Kubernetes 클러스터의 Kubernetes 컨트롤 플레인은 Kubernetes의 오케스트레이션 기능을 관리하는 서비스 컬렉션을 실행합니다.
학습 관점에서 보면 Kubernetes 기능을 탐색하면서 테스트 환경에서 단일 컨트롤 플레인을 사용하는 것이 좋습니다. 그러나 AKS(Azure Kubernetes Service)와 같은 프로덕션 및 클라우드 배포에서 기본 구성은 복제된 컨트롤 플레인이 3~5개인 고가용성 배포임을 알 수 있습니다.
참고 항목
컨트롤 플레인은 클러스터 상태를 유지하기 위해 특정 소프트웨어를 실행하는데, 이때 다른 컴퓨팅 워크로드도 실행합니다. 그러나 일반적으로 중요하지 않은 워크로드와 사용자 앱 워크로드를 실행할 때 컨트롤 플레인을 제외하는 것이 좋습니다.
Kubernetes 노드
Kubernetes 클러스터의 노드는 컴퓨팅 워크로드가 실행되는 위치입니다. 각 노드는 API 서버를 통해 컨트롤 플레인과 통신하여 노드의 상태 변경 내용을 알립니다.
컨트롤 플레인에서 실행되는 서비스
Kubernetes는 컨트롤 플레인에서 실행되는 여러 관리 서비스를 사용합니다. 이러한 서비스는 클러스터 구성 요소 통신, 워크로드 일정 및 클러스터 상태 지속성과 같은 측면을 관리합니다.
다음 서비스는 Kubernetes 클러스터의 컨트롤 플레인을 구성합니다.
- API 서버
- 백업 저장소
- 스케줄러
- 컨트롤러 관리자
- 클라우드 컨트롤러 관리자
API 서버란?
API 서버를 Kubernetes 클러스터의 컨트롤 플레인에 대한 프런트 엔드로 생각할 수 있습니다. Kubernetes의 구성 요소 사이에서 수행되는 모든 통신은 이 API를 통해 수행됩니다.
예를 들어 사용자는 Kubernetes 클러스터의 API 서버에 대해 명령을 실행할 수 있는 kubectl이라는 명령줄 앱을 사용합니다. 이 API를 제공하는 구성 요소를 kube-apiserver라고 하며, 이 구성 요소의 여러 인스턴스를 배포하여 클러스터의 스케일링을 지원할 수 있습니다.
이 API는 명령 또는 YAML 기반 구성 파일을 게시하는 데 사용할 수 있는 RESTful API를 공개합니다. YAML은 사람이 읽을 수 있는 프로그래밍 언어의 데이터 serialization 표준입니다. YAML 파일을 사용하여 Kubernetes 클러스터 내 모든 개체의 의도한 상태를 정의합니다.
예를 들어 클러스터에서 앱의 인스턴스 수를 늘려야 한다고 가정합니다. YAML 기반 파일을 사용하여 새 상태를 정의하고 이 파일을 API 서버에 제출합니다. API 서버는 구성의 유효성을 검사하고 구성을 클러스터에 저장한 후에 앱 배포에서 구성된 증가 수를 적용합니다.
백업 저장소란?
백업 저장소는 Kubernetes 클러스터가 완료된 구성을 저장하는 영구 스토리지입니다. Kubernetes는 etcd라는 고가용성의 안정적인 분산 키-값 저장소를 사용합니다. 이 키-값 저장소는 클러스터 내 모든 개체의 현재 상태 및 원하는 상태를 저장합니다.
프로덕션 Kubernetes 클러스터에서 공식 Kubernetes 지침은 고가용성을 위해 etcd 데이터베이스의 복제된 인스턴스 3~5개를 포함하는 것입니다.
참고
etcd는 데이터 백업을 담당하지 않습니다. etcd 데이터를 백업하기 위한 유효한 백업 계획이 적용되었는지 사용자가 확인해야 합니다.
스케줄러란?
스케줄러는 모든 노드에서 워크로드의 할당 작업을 담당하는 구성 요소입니다. 스케줄러는 클러스터에서 새로 만든 컨테이너를 모니터링하고 해당 컨테이너를 노드에 할당합니다.
컨트롤러 관리자란?
컨트롤러 관리자는 API 서버를 통해 클러스터에 대해 구성된 컨트롤러를 시작하고 모니터링합니다.
Kubernetes는 컨트롤러를 사용하여 클러스터의 개체 상태를 추적합니다. 각 컨트롤러는 클러스터의 이벤트를 보고 응답하는 동안 종료되지 않는 루프에서 실행됩니다. 예를 들어 노드, 컨테이너 및 엔드포인트를 모니터링하는 컨트롤러가 있습니다.
컨트롤러는 API 서버와 통신하여 개체의 상태를 확인합니다. 현재 상태가 개체에 대해 원하는 상태와 다르면 컨트롤러는 원하는 상태를 확인하기 위한 작업을 수행합니다.
클러스터에서 실행 중인 세 개의 컨테이너 중 하나가 응답을 중지하고 실패했다고 가정합니다. 이 경우 컨트롤러는 앱을 항상 사용하도록 새 컨테이너를 시작해야 하는지 여부를 결정합니다. 원하는 상태가 시간에 상관없이 세 개의 컨테이너를 실행하면 새 컨테이너가 실행되도록 예약됩니다.
클라우드 컨트롤러 관리자란?
클라우드 컨트롤러 관리자는 클러스터가 클라우드 환경에서 실행되는 경우 클러스터의 기본 클라우드 기술과 통합됩니다. 해당 서비스는 부하 분산 장치, 큐 및 스토리지 등이 될 수 있습니다.
노드에서 실행되는 서비스
워크로드 실행 방법을 제어하기 위해 Kubernetes 노드에서 실행되는 여러 서비스가 있습니다.
다음 서비스는 Kubernetes 노드에서 실행됩니다.
- Kubelet
- Kube-proxy
- 컨테이너 런타임
Kubelet이란?
Kubelet는 클러스터의 각 노드에서 실행되고 API 서버의 작업 요청을 모니터링하는 에이전트입니다. 이 에이전트는 요청된 작업 단위가 실행 중이고 정상 상태인지 확인합니다.
Kubelet는 노드를 모니터링하고 각 노드에서 예약된 컨테이너가 예상대로 실행되는지 확인합니다. kubelet은 Kubernetes가 생성하는 컨테이너만 관리합니다. 현재 노드에서 작업을 실행할 수 없는 경우 다른 노드에서 실행되도록 작업을 다시 예약하지는 않습니다.
Kube-proxy란?
kube-proxy 구성 요소는 로컬 클러스터 네트워킹을 담당하며 각 노드에서 실행됩니다. 이 구성 요소는 각 노드에 고유한 IP 주소가 있는지 확인합니다. 또한 iptables 및 IPVS를 사용하여 트래픽의 라우팅과 부하 분산을 처리하는 규칙을 구현합니다.
이 프록시는 DNS 서비스를 자체적으로 제공하지 않습니다. CoreDNS를 기반으로 하는 DNS 클러스터 추가 기능이 권장되며 기본적으로 설치됩니다.
컨테이너 런타임이란?
컨테이너 런타임은 Kubernetes 클러스터에서 컨테이너를 실행하는 기본 소프트웨어입니다. 런타임은 컨테이너 이미지를 가져오고, 시작하고, 중지하는 일을 담당합니다. Kubernetes는 Docker, containerd, rkt, CRI-O 및 frakti를 비롯한 여러 컨테이너 런타임을 지원합니다. 많은 컨테이너 런타임 유형에 대한 지원은 CRI(컨테이너 런타임 인터페이스)를 기반으로 합니다. CRI는 kubelet가 사용 가능한 컨테이너 런타임과 통신할 수 있도록 하는 플러그 인 디자인입니다.
AKS의 기본 컨테이너 런타임은 업계 표준 컨테이너 런타임인 containerd입니다.
Kubernetes 클러스터와 상호 작용
Kubernetes는 클러스터를 관리하는 데 사용하는 kubectl이라는 명령줄 도구를 제공합니다. kubectl을 사용하여 클러스터의 컨트롤 플레인에 명령을 전송하거나 API 서버를 통해 모든 Kubernetes 개체에 대한 정보를 가져올 수 있습니다.
kubectl은 다음의 구성 정보를 포함하는 구성 파일을 사용합니다.
- 클러스터 구성은 클러스터 이름, 인증서 정보 및 클러스터와 연결된 서비스 API 엔드포인트를 지정합니다. 이 정의를 사용하면 단일 워크스테이션에서 여러 클러스터에 연결할 수 있습니다.
- 사용자 구성은 구성된 클러스터에 액세스할 때 사용자와 해당 권한 수준을 지정합니다.
- 컨텍스트 구성은 식별 이름을 통해 클러스터와 사용자를 그룹화합니다. 예를 들어 개발 및 프로덕션 클러스터를 식별하는 'dev-cluster' 및 'prod-cluster'가 있을 수 있습니다.
명령줄 구문의 일부로 올바른 컨텍스트를 제공하여 여러 클러스터에 연결하도록 kubectl을 구성할 수 있습니다.
Kubernetes Pod
Pod는 Kubernetes에서 실행되는 앱의 단일 인스턴스를 나타냅니다. Kubernetes에서 실행하는 워크로드는 컨테이너화된 앱입니다. Docker 환경과 달리 Kubernetes에서 직접 컨테이너를 실행할 수는 없습니다. 컨테이너를 Pod라는 Kubernetes 개체로 패키지할 수 있습니다. Pod는 Kubernetes에서 만들 수 있는 가장 작은 개체입니다.
단일 Pod는 하나 이상의 컨테이너 그룹을 포함할 수 있습니다. 그러나 Pod에는 일반적으로 동일한 앱의 배수가 포함되지 않습니다.
팟(Pod)에는 공유 스토리지 및 네트워크 구성에 대한 정보와 패키징된 컨테이너를 실행하는 방법에 대한 사양이 포함됩니다. Pod 템플릿을 사용하여 클러스터에서 실행하는 Pod에 대한 정보를 정의합니다. Pod 템플릿은 다시 사용하고 다른 개체에 포함하여 Pod 배포를 관리하는 YAML 코딩된 파일입니다.
예를 들어 Kubernetes 클러스터에 웹 사이트를 배포하려고 한다고 가정해 보겠습니다. 앱 컨테이너 이미지 및 구성을 지정하는 Pod 정의 파일을 만듭니다. 그런 다음, Pod 정의 파일을 Kubernetes에 배포합니다.
솔루션의 유일한 구성 요소로 웹 사이트를 사용하는 웹앱은 거의 없습니다. 웹앱에는 일반적으로 몇 가지 종류의 데이터 저장소와 기타 지원 요소가 있습니다. Kubernetes Pod에는 둘 이상의 컨테이너가 포함될 수도 있습니다.
사이트에서 데이터베이스를 사용한다고 가정합니다. 웹 사이트는 주 컨테이너에서 패키지되고 데이터베이스는 지원 컨테이너에서 패키지됩니다. 여러 컨테이너가 환경을 통해 서로 통신합니다. 컨테이너에는 호스트 OS, 네트워크 스택, 커널 네임스페이스, 공유 메모리 및 스토리지 볼륨에 대한 서비스가 포함됩니다. Pod는 앱에 해당하는 모든 서비스를 제공하는 샌드박스 환경입니다. Pod를 사용하여 컨테이너에서 할당된 IP 주소를 공유할 수도 있습니다.
많은 노드에서 실행되는 많은 Pod를 잠재적으로 만들 수 있으므로 식별하기 어려울 수 있습니다. 팟(Pod)을 정의할 때 지정하는 문자열 레이블을 사용하여 팟(Pod)을 인식하고 그룹화할 수 있습니다.
Kubernetes Pod의 수명 주기
Kubernetes Pod에는 Pod를 배포, 실행 및 업데이트하는 방법에 영향을 주는 특정 수명 주기가 있습니다. 먼저 Pod YAML 매니페스트를 클러스터에 제출합니다. 클러스터에 제출되고 유지된 후 매니페스트 파일은 Pod의 원하는 상태를 정의합니다. 스케줄러는 Pod를 실행하는 데 충분한 리소스가 있는 정상 노드에 Pod를 예약합니다.
Pod의 수명 주기에서 단계는 다음과 같습니다.
| 단계 | 설명 |
|---|---|
| 보류 중 | Pod는 클러스터를 수락하지만 클러스터의 모든 컨테이너가 설정되거나 실행 준비가 되어 있지는 않습니다. 보류 중 상태는 Pod가 예약되기를 기다리는 시간과 컨테이너 이미지를 다운로드하는 데 소요된 시간을 나타냅니다. |
| 실행 중 | Pod 내의 모든 리소스가 준비된 후 Pod는 실행 중 상태로 전환됩니다. |
| 성공 | Pod가 의도한 작업을 완료하고 성공적으로 실행되면 Pod는 성공 상태로 전환됩니다. |
| 실패 | Pod는 다양한 이유로 실패할 수 있습니다. 포드의 컨테이너가 실패하여 다른 모든 컨테이너가 종료되었거나 포드 컨테이너를 준비하는 동안 이미지를 찾지 못했을 수 있습니다. 이러한 유형의 경우 포드가 실패 상태가 될 수 있습니다. Pod는 Pending 상태 또는 Running 상태에서 실패 상태로 전환될 수 있습니다. 특정 실패로 인해 Pod가 보류 중 상태로 돌아갈 수도 있습니다. |
| Unknown | Pod의 상태를 확인할 수 없는 경우 Pod는 Unknown 상태입니다. |
Pod는 컨트롤러, 컨트롤 플레인 또는 사용자가 명시적으로 제거할 때까지 클러스터에 유지됩니다. Pod가 삭제되면 이후 즉시 새 Pod가 만들어집니다. 새 Pod는 Pod 매니페스트가 정확한 복사본이 아니므로 삭제된 Pod와 다르기 때문에 완전히 새로운 인스턴스로 간주됩니다.
클러스터는 Pod의 상태 또는 동적으로 할당된 구성을 저장하지 않습니다. 예를 덜어 Pod ID 또는 IP 주소를 저장하지 않습니다. 이 측면은 Pod를 배포하는 방법 및 앱을 디자인하는 방법에 영향을 줍니다. 예를 들어 Pod에 대해 미리 할당한 IP 주소를 사용할 수 없습니다.
컨테이너 상태
단계는 Pod의 수명 주기 위치를 요약한 것입니다. Pod를 검사할 때 클러스터가 Pod 내에서 컨테이너를 추적하는 데 사용하는 세 가지 상태가 있습니다.
| 시스템 상태 | Description |
|---|---|
| 대기 중 | 컨테이너의 기본 상태이며 컨테이너가 실행 또는 종료되지 않은 상태입니다. |
| 실행 중 | 컨테이너가 문제없이 예상대로 실행되고 있습니다. |
| 종료됨 | 컨테이너가 더 이상 실행되지 않습니다. 모든 작업이 완료되거나 어떤 이유로 컨테이너가 실패했기 때문입니다. 두 사례를 모두 디버그할 때 이유와 종료 코드를 사용할 수 있습니다. |