이 페이지에서는 컨테이너화된 워크로드를 실행하는 Google Kubernetes Engine(GKE) 클러스터의 아키텍처를 설명합니다. 이 페이지에서 컨트롤 플레인과 노드, 그리고 다양한 GKE 클러스터 구성요소가 서로 어떻게 상호작용하는지 알아보세요.
이 페이지는 IT 솔루션과 시스템 아키텍처를 정의하는 관리자, 설계자, 운영자를 대상으로 합니다. Google Cloud 콘텐츠에서 참조하는 일반적인 역할 및 예시 태스크에 대해 자세히 알아보려면 일반 GKE 사용자 역할 및 태스크를 참조하세요.
이 페이지를 읽기 전에 Kubernetes 클러스터 아키텍처에 대해 숙지해야 합니다.
GKE 클러스터는 컨트롤 플레인과 노드라는 작업자 머신으로 구성됩니다. 컨트롤 플레인과 노드는 Kubernetes 클러스터 조정 시스템을 구성합니다. GKE Autopilot은 컨트롤 플레인, 노드, 모든 시스템 구성요소를 포함하여 클러스터의 전체 기본 인프라를 관리합니다.
GKE Standard 모드를 사용하는 경우 GKE는 컨트롤 플레인 및 시스템 구성요소를 관리하고, 사용자는 노드를 관리합니다.
다음 다이어그램은 GKE 클러스터의 아키텍처를 보여줍니다.
이 다이어그램은 다음 구성요소를 보여줍니다.
- 컨트롤 플레인: GKE에서 관리합니다. Kubernetes API 서버, 워크로드 컨트롤러, Kubernetes 스케줄러, 클러스터 상태 스토리지를 실행합니다.
- 노드: Autopilot 모드에서는 GKE가 관리하고 Standard 모드에서는 고객이 관리합니다. 모든 포드는 노드에서 실행됩니다.
- 기타 Google Cloud 서비스: GKE와 통합하여 사용할 수 있습니다.
컨트롤 플레인 정보
컨트롤 플레인은 Kubernetes API 서버, 스케줄러, 핵심 리소스 컨트롤러와 같은 프로세스를 실행합니다. GKE는 클러스터 생성부터 삭제까지 컨트롤 플레인 수명 주기를 관리합니다. 여기에는 컨트롤 플레인에서 실행되는 Kubernetes 버전으로의 업그레이드가 포함됩니다. 업그레이드는 GKE가 자동으로 또는 자동 일정보다 빨리 업그레이드하기 위해 사용자 요청에 따라 수동으로 실시합니다.
컨트롤 플레인 및 Kubernetes API
컨트롤 플레인은 클러스터의 통합 엔드포인트입니다. Kubernetes API 호출을 통해 컨트롤 플레인과 상호작용합니다. 컨트롤 플레인은 Kubernetes API 서버 프로세스(kube-apiserver)를 실행하여 API 요청을 처리합니다. 다음 방법으로 Kubernetes API 호출을 수행할 수 있습니다.
- 직접 호출: HTTP/gRPC
- 간접 호출:
kubectl같은 Kubernetes 명령줄 클라이언트 또는Google Cloud 콘솔
API 서버 프로세스는 클러스터의 모든 통신을 위한 허브입니다. 노드, 시스템 프로세스, 애플리케이션 컨트롤러와 같은 모든 내부 클러스터 구성요소는 API 서버의 클라이언트로 작동합니다.
API 요청은 클러스터에 있는 객체의 원하는 상태를 Kubernetes에 알려줍니다. Kubernetes는 계속해서 해당 상태를 유지하려고 시도합니다. Kubernetes를 사용하면 API에서 명령적으로 또는 선언적으로 객체를 구성할 수 있습니다.
Kubernetes에서 객체 관리에 대해 자세히 알아보려면 다음 페이지를 참조하세요.
컨트롤 플레인 및 클러스터 상태 데이터베이스
오픈소스 Kubernetes 프로젝트는 기본적으로 클러스터의 모든 데이터를 저장하는 데이터베이스로 etcd를 사용합니다. 클러스터 상태는 클러스터 내 모든 Kubernetes API 객체의 상태 정보를 담고 있는 키-값 저장소에 보관됩니다. 예를 들어 클러스터 상태 데이터베이스에는 모든 보안 비밀, ConfigMap, 배포가 저장됩니다.
GKE 클러스터는 클러스터 상태를 다음 키-값 저장소 중 하나에 저장합니다.
- etcd: GKE는 클러스터 상태를 각 컨트롤 플레인 가상 머신(VM)에서 실행되는 etcd 인스턴스에 저장합니다.
- Spanner: GKE는 클러스터 상태를 Spanner에 저장합니다. Spanner 데이터베이스는 클러스터 컨트롤 플레인에서 실행되지 않습니다.
데이터베이스 유형과 관계없이, 모든 GKE 클러스터는 컨트롤 플레인에서 etcd API를 제공합니다. Kubernetes API 서버는 etcd API를 사용해 백엔드 클러스터 상태 데이터베이스와 통신합니다.
컨트롤 플레인 및 노드 상호작용
컨트롤 플레인은 모든 클러스터 노드에서 실행되는 대상을 관리합니다. 컨트롤 플레인은 워크로드를 예약하고 워크로드 수명 주기, 확장, 업그레이드를 관리합니다. 컨트롤 플레인은 또한 이러한 워크로드의 네트워크 및 스토리지 리소스를 관리합니다. 컨트롤 플레인 및 노드는 Kubernetes API를 사용하여 서로 통신합니다.
컨트롤 플레인과 Artifact Registry 상호작용
클러스터를 만들거나 업데이트할 때 GKE는 컨트롤 플레인과 노드에서 실행되는 Kubernetes 시스템 소프트웨어용 컨테이너 이미지를 pkg.dev 또는 gcr.io 도메인의 Artifact Registry 저장소에서 가져옵니다. 이러한 레지스트리에 중단이 발생하면 다음 작업이 실패할 수 있습니다.
- 새 클러스터 생성
- 클러스터 버전 업그레이드
서비스 중단의 특정 성격과 기간에 따라 사용자 간섭이 없어도 워크로드 문제가 발생할 수 있습니다.
Artifact Registry 저장소 중단이 리전 단위로 발생한 경우 중단의 영향을 받지 않는 다른 영역이나 리전으로 요청이 리디렉션될 수 있습니다.
Google Cloud 서비스 상태를 확인하려면 Google Cloud 상태 대시보드로 이동하세요.
리전 중단이 발생하더라도 애플리케이션 가용성을 유지할 수 있도록 여러 리전에 걸쳐 배포하세요.
노드 정보
노드는 컨테이너화된 애플리케이션과 기타 워크로드를 실행하는 작업자 머신입니다. 개별 머신은 GKE가 생성하는 Compute Engine 가상 머신(VM)입니다. 컨트롤 플레인은 각 노드의 자체 보고 상태를 관리하고 업데이트를 수신합니다.
노드는 클러스터의 워크로드를 구성하는 컨테이너를 지원하는 데 필요한 서비스를 실행합니다. 여기에는 런타임 및 Kubernetes 노드 에이전트(kubelet)가 포함됩니다. 이 에이전트는 컨트롤 플레인과 통신하고, 해당 노드에 예약된 컨테이너를 시작하고 실행합니다.
GKE는 또한 로그 수집 및 클러스터 내 네트워크 연결과 같은 기능을 제공하는 DaemonSet라고 하는 노드별 에이전트로 실행되는 여러 시스템 컨테이너를 실행합니다.
컨테이너화된 애플리케이션에서는 stdout를 사용하세요. stdout를 사용하면 플랫폼이 애플리케이션 로그를 처리할 수 있기 때문입니다.
노드 관리는 클러스터 작업 모드에 따라 다음과 같이 달라집니다.
| 노드 구성요소 | Autopilot 모드 | 표준 모드 |
|---|---|---|
| 수명 주기 | 다음을 포함하는 GKE의 완전 관리형: |
GKE는 다음을 관리합니다.
다음을 관리할 수 있습니다.
|
| 가시성 | kubectl을 사용하여 노드를 볼 수 있습니다. 기본 Compute Engine 가상 머신은 gcloud CLI 또는 Google Cloud 콘솔에서 표시하거나 액세스할 수 없습니다. |
kubectl, gcloud CLI, Google Cloud 콘솔에서 노드를 볼 수 있습니다. 기본 Compute Engine VM을 보고 액세스합니다. |
| 연결 | 기본 VM에 직접 연결하지 않습니다. | SSH를 사용해서 기본 VM에 연결합니다. |
| 노드 운영체제(OS) | GKE에서 관리합니다. 모든 노드는 containerd를 사용하는 Container-Optimized OS(cos_containerd)를 사용합니다. |
노드 운영 체제를 선택합니다. |
| 머신 하드웨어 선택 | 사용 사례에 따라 포드에서 컴퓨팅 클래스를 요청합니다. GKE는 머신 구성, 예약, 수량, 수명 주기를 관리합니다. |
노드 풀을 만들 때 Compute Engine 머신 유형을 선택하고 구성합니다. 필요에 따라 크기 조정, 확장, 수량, 일정 예약, 위치 설정을 구성합니다. |