워크로드 배포 개요

Google Kubernetes Engine(GKE) 클러스터에서 컨테이너화된 애플리케이션과 기타 워크로드를 배포 및 관리하려면 Kubernetes 시스템을 사용하여 Kubernetes 컨트롤러 객체를 만들어야 합니다. 이러한 컨트롤러 객체는 클러스터에서 실행 중인 애플리케이션, 데몬, 일괄 작업을 나타냅니다.

Kubernetes API를 사용하거나 gcloud를 통해 설치한 Kubernetes의 명령줄 인터페이스인 kubectl을 사용하여 이러한 컨트롤러 객체를 만들 수 있습니다. 일반적으로 원하는 Kubernetes 컨트롤러 객체의 표현을 YAML 구성 파일로 빌드한 후 이 파일을 Kubernetes API 또는 kubectl 명령줄 인터페이스와 함께 사용합니다.

워크로드 유형

Kubernetes는 실행할 수 있는 다양한 워크로드에 상응하는 다양한 컨트롤러 객체를 제공합니다. 일부 컨트롤러 객체는 특정 유형의 워크로드를 나타내는 데 더 적합합니다. 다음 섹션에서는 다음을 비롯한 몇 가지 일반적인 워크로드 유형과 클러스터에서 워크로드를 실행하기 위해 만들 수 있는 Kubernetes 컨트롤러 객체를 설명합니다.

  • 스테이트리스(Stateless) 애플리케이션
  • 스테이트풀(Stateful) 애플리케이션
  • 일괄 작업
  • 데몬

스테이트리스(Stateless) 애플리케이션

스테이트리스(Stateless) 애플리케이션은 상태를 보존하지 않으며 영구 스토리지에 데이터를 저장하지 않습니다. 모든 사용자와 세션 데이터는 클라이언트에 있습니다.

스테이트리스(Stateless) 애플리케이션의 예시에는 Nginx와 같은 웹 프런트엔드, Apache Tomcat과 같은 웹 서버, 기타 웹 애플리케이션이 있습니다.

Kubernetes 배포를 만들어 클러스터에 스테이트리스(Stateless) 애플리케이션을 배포할 수 있습니다. 배포에서 만드는 포드는 고유하지 않고 상태를 보존하지 않으므로 상태 비추적 애플리케이션은 확장과 업데이트가 쉽습니다.

스테이트풀(Stateful) 애플리케이션

스테이트풀(Stateful) 애플리케이션은 상태가 저장되거나 영구적이어야 합니다. 스테이트풀(Stateful) 애플리케이션은 영구 볼륨과 같은 영구 스토리지를 사용하여 서버나 다른 사용자가 사용할 수 있도록 데이터를 저장합니다.

스테이트풀(Stateful) 애플리케이션의 예시에는 MongoDB와 같은 데이터베이스와 Apache ZooKeeper와 같은 메시지 큐가 있습니다.

Kubernetes StatefulSet를 만들어 상태 저장 애플리케이션을 배포할 수 있습니다. StatefulSet가 만드는 포드는 고유한 식별자가 있으며, 체계적이고 안전한 방식으로 업데이트할 수 있습니다.

일괄 작업

일괄 작업은 완료될 때까지 실행되는 유한하고 독립적인 작업을 나타내며 병렬 작업인 경우가 흔합니다. 일괄 작업의 몇 가지 예로는 이메일 전송, 비디오 렌더링, 리소스 소모량이 많은 연산 등 자동 또는 예약된 작업이 있습니다.

Kubernetes 작업을 만들어 클러스터에서 일괄 작업을 실행하고 관리할 수 있습니다. Kubernetes 작업이 완료되기 전에 작업을 완료해야 하는 포드의 수뿐 아니라 병렬로 실행되어야 하는 최대 포드 수를 지정할 수 있습니다.

데몬

데몬은 사용자가 개입할 필요 없이 할당된 노드에서 진행 중인 백그라운드 작업을 수행합니다. 데몬의 예시에는 Fluentd와 같은 로그 수집기와 모니터링 서비스가 있습니다.

Kubernetes DaemonSet를 만들어 클러스터에 데몬을 배포할 수 있습니다. DaemonSet는 노드당 하나의 포드를 만들며, DaemonSet가 배포해야 할 특정 노드를 지정할 수 있습니다.

GKE Autopilot의 DaemonSet

GKE는 Autopilot 작업 모드를 사용하여 만드는 클러스터의 노드를 관리합니다. 노드 또는 기본 Compute Engine 가상 머신(VM)을 수동으로 추가, 삭제, 수정할 수는 없습니다. 하지만 Kubernetes 노드 객체가 계속 표시되고 Autopilot에서 DaemonSet가 워크로드로 지원됩니다.

GKE Autopilot은 DaemonSet에서 관리하는 포드를 포함하여 모든 워크로드 포드에 영향을 미치는 일부 관리 기능을 제한합니다. privileged 보안 컨텍스트와 같은 승격된 권한을 사용하여 노드에서 관리 기능을 수행하는 DaemonSet는 GKE에서 명시적으로 허용하지 않는 한 Autopilot 클러스터에서 실행되지 않습니다.

Autopilot에서 적용한 한도에 대한 자세한 내용은 워크로드 제한 및 제약사항을 참조하세요. Autopilot에서 설정한 제약사항을 충족하는 워크로드에 DaemonSet를 사용할 수 있으며, 일부 Google Cloud 파트너의 DaemonSet도 사용할 수 있습니다.

Autopilot의 DaemonSet 권장사항

GKE는 배포된 워크로드의 총 크기를 사용해서 Autopilot이 클러스터에 대해 프로비저닝하는 노드 크기를 결정합니다. Autopilot이 노드를 프로비저닝한 후 DaemonSet를 추가하거나 크기를 조정할 경우 GKE는 새로운 총 워크로드 크기에 맞게 기존 노드의 크기를 조정하지 않습니다. 시스템 포드를 고려한 후 기존 노드의 할당 가능한 용량보다 큰 리소스 요청을 포함하는 DaemonSet는 이러한 노드에서 예약되지 않습니다.

GKE 버전 1.27.6-gke.1248000부터 Autopilot 모드의 클러스터는 모든 DaemonSet에 적합하지 않은 노드를 감지하고 시간 경과에 따라 모든 DaemonSet에 적합한 더 큰 노드로 워크로드를 마이그레이션합니다. 이 프로세스는 특히 핵심 클러스터 기능이 중단되지 않도록 정상적으로 종료하기 위해 추가 시간이 필요한 시스템 포드를 실행하는 경우에 다소 시간이 걸립니다.

GKE 버전 1.27.5-gke.200 이하에서는 DaemonSet 포드를 수용할 수 없는 노드를 차단하고 드레이닝하는 것이 좋습니다.

모든 GKE 버전의 경우 Autopilot에서 DaemonSet를 배포할 때 다음 권장사항을 따르는 것이 좋습니다.

  • 다른 워크로드보다 먼저 DaemonSet를 배포합니다.
  • DaemonSet에서 일반 포드보다 높은 PriorityClass를 설정합니다. 우선순위가 높은 PriorityClass를 사용하면 노드가 더 낮은 우선순위 포드를 수용할 수 있는 경우 GKE가 DaemonSet 포드를 수용하기 위해 해당 포드를 제거할 수 있습니다. 이렇게 하면 노드 재생성을 트리거하지 않고 각 노드에 DaemonSet가 있는지 확인하는 데 도움이 됩니다.

워크로드 객체 관리

명령형 메서드와 선언형 메서드를 사용하여 객체를 생성, 관리, 삭제할 수 있습니다. 다음 섹션에서는 이러한 메서드를 설명한 후 이러한 메서드를 채택하는 데 사용할 수 있는 다음 도구를 설명합니다.

명령형 명령어

명령형 명령어를 사용하면 kubectl로 객체를 빠르게 만들고, 보고, 업데이트하고, 삭제할 수 있습니다. 이러한 명령어는 일회성 태스크 또는 클러스터의 활성 객체 변경에 유용합니다. 명령형 명령어는 일반적으로 클러스터에 배포된 실시간 객체에서 작업하는 데 사용됩니다.

kubectl은 Kubernetes 객체를 만들고 수정할 수 있는 몇 가지 동사 기반 명령어를 제공합니다. 예를 들면 다음과 같습니다.

  • run: 클러스터에 새 객체를 생성합니다. 달리 지정하지 않으면 run은 배포 객체를 만듭니다.
  • expose: 새 서비스 객체를 만들어 라벨이 지정된 pod 집합에 트래픽 부하를 분산합니다.
  • autoscale: 새 자동 확장 처리 객체를 만들어 배포와 같은 컨트롤러 객체를 수평으로 자동 확장합니다.

명령형 명령어에서는 객체 스키마에 대한 지식이 필요 없으며 구성 파일도 필요 없습니다.

명령형 객체 구성

명령형 객체 구성은 완전히 정의된 객체 정의가 포함된 구성 파일을 사용하여 객체를 만들고, 업데이트하고, 삭제합니다. 명령형 명령어를 사용하는 경우보다 쉽게 소스 제어 시스템에 객체 구성 파일을 저장하고 변경사항을 감사할 수 있습니다.

구성 파일 또는 구성 파일이 포함된 디렉터리에서 kubectl apply , delete, replace 작업을 실행할 수 있습니다.

선언형 객체 구성

선언형 객체 구성은 로컬에 저장된 구성 파일에서 작동하지만 실행할 작업을 명시적으로 정의할 필요가 없습니다. 대신 kubectl이 객체별로 작업을 자동으로 감지합니다. 이는 작업이 많은 구성 파일 디렉터리에서 작업하는 경우에 유용합니다. 선언형 객체 관리에서는 객체 스키마와 구성 파일을 잘 알고 있어야 필요합니다.

kubectl apply를 실행하면 객체를 선언적으로 만들고 업데이트할 수 있습니다. apply는 전체 실시간 객체를 읽고 차이를 계산한 후 패치 요청을 API 서버로 전송하여 이러한 차이를 병합하여 객체를 업데이트합니다.

공개 Docker Hub 이미지

Docker Hub에서 공개 컨테이너 이미지를 배포할 때 GKE는 컨테이너 이미지의 캐시된 사본에 대해 캐싱 프록시 mirror.gcr.io를 자동으로 확인합니다. 캐시된 사본을 사용할 수 없는 경우 GKE는 Docker Hub에서 요청된 이미지를 가져오며 캐싱 프록시는 나중에 사용할 수 있도록 이미지를 캐시할 수 있습니다. 자세한 내용은 캐시된 이미지 가져오기를 참조하세요.

콘솔

kubectl 또는 API를 사용하여 워크로드를 배포한 후 Google Cloud 콘솔에서 GKE 워크로드 메뉴를 사용하여 클러스터에서 실행 중인 워크로드를 검사, 관리, 수정할 수 있습니다.

이 메뉴에서는 다음과 같은 기능을 제공합니다.

  • YAML 기반 텍스트 편집기를 사용하여 웹 브라우저에서 실시간 객체를 편집할 수 있습니다.
  • 업데이트 기록, 최근 이벤트 및 활동, 관리형 포드 등 객체에 대한 상세한 정보를 볼 수 있습니다.
  • 배포, 작업, StatefulSet를 쉽게 확장할 수 있습니다.
  • 작업 메뉴에서 배포를 자동 확장하고, 지속적 업데이트를 트리거하고, 수동으로 확장할 수 있습니다.
  • Cloud Shell을 사용하여 모든 객체를 검사, 편집, 삭제할 수 있습니다.

API

Google Cloud 클라이언트 라이브러리와 함께 GKE REST API와 Kubernetes API를 사용하여 워크로드를 프로그래매틱 방식으로 만들고 관리할 수 있습니다.

구성 파일

앞서 설명한 메서드를 사용하여 워크로드를 배포하면 GKE는 객체를 나타내는 구성 파일을 클러스터에 추가합니다.

객체의 라이브 구성은 로컬 파일과 다를 수 있습니다. YAML은 Kubernetes 객체를 만들고 표현하는 데 가장 많이 사용됩니다. JSON을 사용할 수도 있습니다.

Kubernetes 객체 사양, 상태, Kubernetes API에 대한 자세한 내용은 Kubernetes 객체 이해하기와 Kubernetes API 참조를 확인하세요.

라이브 구성 검사

콘솔

배포된 객체의 라이브 구성을 검사하려면 다음 단계를 따르세요.

  1. Google Cloud 콘솔에서 워크로드 페이지로 이동합니다.

    워크로드로 이동

  2. 원하는 워크로드를 선택합니다.

  3. YAML을 클릭합니다.

gcloud

배포된 객체의 라이브 구성을 검사하려면 다음 명령어를 실행하세요.

kubectl get [OBJECT_TYPE] [OBJECT_NAME] -o yaml

[OBJECT_TYPE]은 deployment, statefulset, job 또는 그 밖의 객체 유형일 수 있습니다. 예를 들면 다음과 같습니다.

kubectl get deployment my-stateless-app -o yaml

할당량을 사용하여 리소스 사용량 관리

많은 사용자나 팀이 클러스터의 리소스를 공유하는 경우 일부는 공정하게 공유된 것보다 더 많이 사용할 수 있다는 우려가 있습니다. Kubernetes ResourceQuota 객체를 사용하여 특정 네임스페이스 내의 리소스 소비를 제한할 수 있습니다.

또한 GKE는 불안정성을 방지하기 위해 노드가 100개 이하인 클러스터의 네임스페이스에 변경할 수 없는 기본 gke-resource-quotas 객체를 적용합니다.

GitLab을 사용하여 GKE에 배포

지속적 통합을 위해 GitLab을 사용하는 경우 GitLab GKE 구성요소를 사용하여 GKE 클러스터에 워크로드를 배포할 수 있습니다.

Google Cloud에서 GitLab을 사용하는 방법에 대한 엔드 투 엔드 튜토리얼을 사용해 볼 수도 있습니다.

자세한 내용은 Google Cloud의 GitLab 개요를 참조하세요.

다음 단계