이전

다음

Kubernetes 배포 작동 방식

완료됨

드론 추적 앱에는 서로 별도로 배포되는 여러 구성 요소가 있습니다. 클러스터에 해당 구성 요소의 배포를 구성하는 작업입니다. 여기서는 해당 구성 요소를 배포하는 데 사용할 수 있는 배포 옵션 중 일부를 살펴봅니다.

Pod 배포 옵션

kubectl을 사용하는 경우 Kubernetes 클러스터에서 Pod 배포를 관리하는 몇 가지 옵션이 있습니다. 옵션은 다음과 같습니다.

• Pod 템플릿
• 복제 컨트롤러
• 복제본 세트
• 배포

이러한 네 가지 Kubernetes 개체 유형 정의 중 하나를 사용하여 포드를 배포할 수 있습니다. 이러한 파일은 YAML을 사용하여 배포할 포드의 의도된 상태를 설명합니다.

Pod 템플릿이란?

Pod 템플릿을 사용하여 배포하려는 Pod의 구성을 정의할 수 있습니다. 템플릿에는 컨테이너 이미지의 이름 및 이미지를 가져오는 데 사용할 컨테이너 레지스트리와 같은 정보가 포함되어 있습니다. 템플릿에는 사용할 포트와 같은 런타임 구성 정보도 포함되어 있습니다. 템플릿은 Docker 파일을 만들 때와 같은 방법으로 YAML을 사용하여 정의됩니다.

템플릿을 사용하여 Pod를 수동으로 배포할 수 있습니다. 그러나 수동으로 배포된 Pod는 실패, 삭제 또는 종료 후에 다시 시작되지 않습니다. Pod의 수명 주기를 관리하려면 상위 수준 Kubernetes 개체를 만들어야 합니다.

복제 컨트롤러란?

복제 컨트롤러는 Pod 템플릿을 사용하며 실행해야 하는 지정된 수의 Pod를 정의합니다. 컨트롤러를 사용하면 같은 Pod의 여러 인스턴스를 실행할 수 있으며 Pod가 하나 이상의 클러스터 노드에서 항상 실행됩니다. Pod가 실패하거나 삭제 또는 종료된 경우 컨트롤러는 해당 방식으로 실행되는 Pod를 새 Pod로 바꿉니다.

예를 들어 드론 추적 프런트 엔드 웹 사이트를 배포하고 사용자가 웹 사이트 액세스를 시작한다고 가정합니다. 특정 이유로 모든 Pod가 실패하는 경우 새 Pod를 시작해야 사용자가 웹 사이트를 사용할 수 있습니다. 복제 컨트롤러를 통해 웹 사이트를 항상 사용하도록 관리할 수 있습니다.

복제본 세트란?

복제본 세트는 복제본을 배포하는 기본 방식으로 복제 컨트롤러를 대체합니다. 복제본 세트에는 복제 컨트롤러와 동일한 기능이 포함되어 있지만 선택기 값을 포함하는 추가 구성 옵션이 있습니다.

선택기를 사용하면 복제본 세트가 그 아래에서 실행 중인 모든 Pod를 식별할 수 있습니다. 이 기능을 통해 선택기 값과 같은 값으로 레이블이 지정되어 있지만 복제본 세트를 사용하여 만들어지지 않은 Pod를 관리할 수 있습니다.

배포란?

배포는 복제 세트보다 한 수준 높은 관리 개체를 생성하고 클러스터의 포드에 대한 업데이트를 배포하고 관리할 수 있도록 합니다.

클러스터에 배포된 앱의 인스턴스가 5개 있다고 가정합니다. 앱 버전 1.0.0을 실행하는 5개의 Pod가 있습니다.

앱을 수동으로 업데이트하기로 결정한 경우 모든 팟(Pod)을 제거한 다음 앱 버전 2.0.0을 실행하는 새 팟(Pod)을 실행할 수 있습니다. 이 전략을 사용하면 앱에 가동 중지 시간이 발생합니다.

대신 이전 앱 버전 팟(Pod)을 제거하기 전에 앱의 새 버전으로 팟(Pod)을 실행하는 롤링 업데이트를 실행하려고 합니다. 롤링 업데이트는 이전 Pod를 한 번에 모두 종료하지 않고 한 번에 하나의 Pod를 실행합니다. 배포는 복제본 세트 관련 정보를 설명하는 섹션에 구성된 복제본 개수를 적용합니다. 기존 Pod를 새 Pod로 바꾸므로 복제본 세트에 지정된 Pod 수를 유지합니다.

배포는 기본적으로 Pod 업데이트를 위한 롤링 업데이트 전략을 제공합니다. 다시 만들기 전략을 사용할 수도 있습니다. 이 전략은 새 Pod를 시작하기 전에 Pod를 종료합니다.

또한 배포에서는 kubectl을 사용하여 실행할 수 있는 롤백 전략도 제공합니다.

배포는 YAML 기반 정의 파일을 활용하여 배포를 쉽게 관리할 수 있습니다. 배포를 사용하면 클러스터에 변경 내용을 적용할 수 있습니다. 예를 들어 새 버전의 앱을 배포하고, 레이블을 업데이트하고, Pod의 다른 복제본을 실행할 수 있습니다.

kubectl에는 kubectl run 명령을 사용하여 Pod를 배포할 때 자동으로 배포를 만드는 편리한 구문이 있습니다. 이 명령은 필수 복제본 세트와 Pod를 사용하여 배포를 만듭니다. 그러나 이 명령은 정의 파일을 만들지 않습니다. 배포 정의 파일을 사용하여 모든 배포를 관리하고 버전 제어 시스템을 사용하여 변경 사항을 추적하는 것이 가장 좋습니다.

배포 고려 사항

Kubernetes에는 클러스터의 네트워킹 및 스토리지를 구성하는 방법에 대한 특정 요구 사항이 있습니다. 이 두 가지 측면을 구성하는 방법은 클러스터 네트워크에 앱을 공개하고 데이터를 저장하는 방법에 영향을 미칩니다.

예를 들어 드론 추적 앱의 각 서비스에는 사용자 액세스, 프로세스 간 네트워크 액세스 및 데이터 스토리지에 대한 특정 요구 사항이 있습니다. 이제 Kubernetes 클러스터의 이러한 측면과 앱 배포에 미치는 영향을 살펴보세요.

Kubernetes 네트워킹

클러스터에 하나의 컨트롤 플레인과 두 개의 노드가 있다고 가정해 봅니다. Kubernetes에 노드를 추가하면 내부 프라이빗 네트워크 범위에서 각 노드에 IP 주소가 자동으로 할당됩니다. 예를 들어 로컬 네트워크 범위가 192.168.1.0/24라고 가정합니다.

배포하는 각 Pod에는 IP 주소 풀의 IP가 할당됩니다. 예를 들어 다음 이미지와 같이 구성에서 10.32.0.0/12 네트워크 범위를 사용한다고 가정합니다.

기본적으로 Pod 및 노드는 서로 다른 IP 주소 범위를 사용하여 서로 통신할 수 없습니다.

향후 복잡한 문제가 발생하면 Pod가 일시적이라는 것을 기억하세요. Pod의 IP 주소는 일시적이며 새로 만든 Pod에 다시 연결하는 데 사용할 수 없습니다. 이 구성은 앱이 내부 구성 요소에 통신하는 방식 및 사용자와 서비스가 앱과 외부에서 상호 작용하는 방식에 영향을 미칩니다.

통신을 간소화하기 위해 Kubernetes는 사용자가 다음 방법으로 네트워킹을 구성하는 것을 권장합니다.

• Pod는 NAT(Network Address Translation)를 사용하지 않고 여러 노드를 통해 서로 통신할 수 있습니다.
• 노드는 NAT 없이 모든 Pod와 통신할 수 있으며 그 반대의 경우도 가능합니다.
• 노드의 에이전트는 모든 노드 및 Pod를 통해 통신할 수 있습니다.

Kubernetes는 네트워킹을 구성하기 위해 설치할 수 있는 몇 가지 네트워킹 옵션을 제공합니다. 예를 들어 Antrea, Cisco ACI(Application Centric Infrastructure), Cilium, Flannel, Kubenet, VMware NSX-T 및 Weave Net이 있습니다.

클라우드 공급자는 자체 네트워킹 솔루션도 제공합니다. 예를 들어 AKS(Azure Kubernetes Service)는 Azure Virtual Network CNI(컨테이너 네트워크 인터페이스), Kubenet, Flannel, Cilium 및 Antrea를 지원합니다.

Kubernetes 서비스

Kubernetes 서비스는 Pod에 안정적인 네트워킹을 제공하는 Kubernetes 개체입니다. Kubernetes 서비스를 사용하여 노드, Pod 및 클러스터에 대한 내부와 외부 모두의 앱 사용자 간에 통신하도록 설정할 수 있습니다.

Kubernetes는 노드 또는 Pod와 마찬가지로 만들 때 서비스에 IP 주소를 할당합니다. 이러한 주소는 서비스 클러스터의 IP 범위에서 할당됩니다. 예: 10.96.0.0/12. 서비스는 또한 서비스 이름 및 IP 포트를 기반으로 DNS 이름을 할당합니다.

드론 추적 앱에서 네트워크 통신은 다음과 같습니다.

• 웹 사이트 및 RESTful API에는 클러스터 외부의 사용자가 액세스할 수 있습니다.

• 메모리 내 캐시와 메시지 큐 서비스에는 각각 프런트 엔드 및 RESTful API에서 액세스할 수 있지만 외부 사용자가 액세스할 수는 없습니다.

• 메시지 큐는 데이터 처리 서비스에 대한 액세스 권한이 필요하지만 외부 사용자에게는 필요하지 않습니다.

• NoSQL 데이터베이스에는 메모리 내 캐시 및 데이터 처리 서비스에서 액세스할 수 있지만 외부 사용자가 액세스할 수는 없습니다.

이 시나리오를 지원하기 위해 세 가지 유형의 서비스를 구성하여 앱의 구성 요소를 표시할 수 있습니다.

서비스	설명
ClusterIP	클러스터 내의 서비스 세트에서 서비스를 사용할 수 있도록 서비스에 할당된 주소입니다. 예를 들어 앱의 프런트 엔드 및 백 엔드 구성 요소 간 통신이 있습니다.
NodePort	Kubernetes 컨트롤 플레인이 서비스에 할당하는 30000~32767 사이의 노드 포트입니다(예: clusters01의 192.169.1.11). 그런 다음, 공개하려는 Pod의 대상 포트를 사용하여 서비스를 구성합니다. 예를 들어 프런트 엔드 중 하나를 실행하는 Pod에서 포트 80을 구성합니다. 이제 노드 IP 및 포트 주소를 통해 프런트 엔드에 액세스할 수 있습니다.
LoadBalancer	앱을 실행하는 노드와 공용 네트워크 액세스에 Pod를 공개하는 노드 간에 부하를 분산할 수 있는 부하 분산 장치입니다. 일반적으로 클라우드 공급자를 사용할 때 부하 분산 장치를 구성합니다. 이 경우 외부 부하 분산 장치의 트래픽은 앱을 실행하는 Pod로 전송됩니다.

드론 추적 앱에서 LoadBalancer를 사용하여 추적 웹 사이트와 RESTful API를 노출하고 ClusterIP를 사용하여 데이터 처리 서비스를 노출하도록 결정할 수 있습니다.

Pod 그룹화 방법

IP 주소로 Pod를 관리하는 것은 실용적이지 않습니다. Pod IP 주소는 컨트롤러에서 다시 만들 때 변경되며 원하는 수의 Pod를 실행할 수 있습니다.

서비스 개체를 사용하면 선택기 레이블을 사용하여 클러스터의 특정 Pod를 대상으로 지정하고 관리할 수 있습니다. 서비스 정의의 선택기 레이블을 Pod 정의 파일에 정의된 Pod 레이블과 일치하도록 설정합니다.

예를 들어 많은 Pod를 실행하고 있다고 가정합니다. 해당 Pod 중 일부만 프런트 엔드에 있으며 프런트 엔드 Pod만 대상으로 지정하는 LoadBalancer 서비스를 설정하려고 합니다. 서비스 정의 파일에서 Pod 레이블을 선택기 값으로 참조하여 해당 Pod를 공개하도록 서비스를 적용할 수 있습니다. 서비스는 레이블과 일치하는 Pod만 그룹화합니다. Pod를 제거하고 다시 만들면 새 Pod가 일치하는 레이블을 통해 서비스 그룹에 자동으로 추가됩니다.

Kubernetes 스토리지

Kubernetes는 Docker를 사용할 때 확인할 수 있는 동일한 스토리지 볼륨 개념을 사용합니다. Docker 볼륨 수명이 관리되지 않기 때문에 Docker 볼륨은 Kubernetes 볼륨보다 덜 관리됩니다. Kubernetes 볼륨의 수명은 Pod의 수명과 일치하는 명시적 수명입니다. 이 수명이 일치하는 것은 Pod에서 실행되는 컨테이너보다 볼륨이 오래 지속됨을 의미합니다. 그러나 Pod가 제거되면 볼륨도 제거됩니다.

Kubernetes는 PersistentVolumes를 활용하는 영구적 스토리지를 프로비저닝하는 옵션을 제공합니다. 또한 PersistentVolumeClaims를 사용하여 Pod용 특정 스토리지를 요청할 수 있습니다.

메시지 큐 및 데이터베이스와 같은 영구적 스토리지가 필요한 앱 구성 요소를 배포할 때 이 두 가지 옵션을 모두 고려하세요.

클라우드 통합 고려 사항

Kubernetes는 클라우드 네이티브 앱에서 사용하는 기술 스택을 명시하지 않습니다. Azure와 같은 클라우드 환경에서는 Kubernetes 클러스터 외부에서 여러 서비스를 사용할 수 있습니다.

앞에서 설명한 대로 Kubernetes는 다음 서비스를 제공하지 않습니다.

• 미들웨어
• 데이터 처리 프레임워크
• 데이터베이스
• 캐시
• 클러스터 스토리지 시스템

이 드론 추적 솔루션에는 미들웨어 기능을 제공하는 세 가지 서비스인 NoSQL 데이터베이스, 메모리 내 캐시 서비스 및 메시지 큐가 있습니다. NoSQL 솔루션으로는 MongoDB Atlas를, 메모리 내 캐시를 관리하려면 Redis를, 메시지 큐 요구 사항에 따라 RabbitMQ 또는 Kafka를 선택할 수 있습니다.

Azure와 같은 클라우드 환경을 사용하는 경우 Kubernetes 클러스터 외부 서비스를 사용하는 것이 좋습니다. 그렇게 하면 클러스터의 구성과 관리를 간소화할 수 있습니다. 예를 들어 메모리 내 캐싱 서비스에는 Azure Cache for Redis, 메시지 큐에는 Azure Service Bus 메시징, NoSQL 데이터베이스에는 Azure Cosmos DB를 사용할 수 있습니다.

계속