Windows Server 노드 풀을 사용하여 클러스터 만들기


이 페이지에서는 Microsoft Windows Server를 실행하는 노드 풀을 사용하여 Google Kubernetes Engine(GKE) 클러스터를 만드는 방법을 알아봅니다. 이 클러스터에서는 Windows Server 컨테이너를 사용할 수 있습니다. Microsoft Hyper-V 컨테이너는 현재 지원되지 않습니다. Linux 컨테이너와 마찬가지로 Windows Server 컨테이너는 프로세스 및 네임스페이스 격리를 제공합니다.

Windows Server 노드는 일반적인 Linux 노드보다 더 많은 리소스를 필요로 합니다. Windows OS 실행을 위해 또한 컨테이너에서 실행할 수 없는 Windows Server 구성요소를 위해 Windows Server 노드는 추가적인 리소스가 필요합니다. 이처럼 더 많은 리소스를 필요로 하므로 할당 가능한 리소스는 Linux 노드의 경우보다 적을 수 밖에 없습니다.

Windows Server 노드 풀을 사용하여 클러스터 만들기

이 섹션에서는 Windows Server 컨테이너를 사용하는 클러스터를 만듭니다.

이 클러스터를 만들려면 다음 작업을 완료해야 합니다.

  1. Windows Server 노드 이미지 선택
  2. 업데이트 및 구성 gcloud
  3. 클러스터 및 노드 풀 만들기
  4. kubectl 사용자 인증 정보 가져오기
  5. 클러스터 초기화 대기

Windows Server 노드 이미지 선택

GKE에서 실행하려면 Windows Server 버전 2019(LTSC), Windows Server 버전 20H2(SAC) 또는 Windows Server 버전 2022(LTSC)를 기반으로 Windows Server 컨테이너 노드 이미지를 빌드해야 합니다. 단일 클러스터는 여러 Windows Server 버전을 사용하는 여러 Windows Server 노드 풀을 가질 수 있지만, 각 개별 노드 풀은 하나의 Windows Server 버전만 사용할 수 있습니다.

노드 이미지 선택 시 다음 사항을 고려하세요.

  • 지원 시간:
    • Windows Server 노드 이미지의 지원 시점에는 OS 이미지의 지원 정책에 설명된 대로 Microsoft에서 제공하는 지원 시점이 적용됩니다. GKE 및 Windows 버전 매핑 섹션에 설명된 대로 gcloud container get-server-config 명령어를 사용하여 GKE Windows 노드 이미지의 지원 종료일을 찾을 수 있습니다.
    • SAC 버전은 최초 출시 후 18개월 동안 Microsoft에서만 지원됩니다. 노드 풀의 이미지 유형으로 SAC를 선택하지만 새 SAC 버전을 타겟팅하는 새 GKE 버전으로 노드 풀을 업그레이드하지 않는 경우, SAC 버전의 지원 수명 주기가 종료될 때 노드 풀에 새 노드를 만들 수 없습니다. Google의 Windows 서버 운영체제 지원에 대해 자세히 알아보세요. 수명 주기가 더 긴 LTSC를 사용하는 것이 좋습니다.
    • 공개 버전 출시 채널에 GKE 클러스터를 등록하는 경우 SAC를 선택하지 마세요. SAC 버전은 18개월 동안 Microsoft에서만 지원되므로 GKE 공개 버전을 계속 사용할 수 있지만 SAC 노드 풀 이미지가 지원되지 않을 수 있습니다.
  • 버전 호환성 및 복잡성:
    • 노드 풀을 업그레이드할 수 있고 컨테이너가 정기적으로 실행되는 경우에만 SAC를 선택합니다. GKE는 새 GKE 출시에서 Windows 노드 풀에 사용되는 SAC 버전을 주기적으로 업데이트하므로, 노드 풀 이미지 유형에 SAC를 선택하면 컨테이너를 더 자주 빌드해야 합니다.
    • 사용할 Windows Server 이미지 유형을 모르는 경우 Windows Server LTSC를 선택하여 노드 풀을 업그레이드할 때 발생할 수 있는 버전 비호환성 문제를 방지하는 것이 좋습니다. 자세한 내용은 Microsoft 문서의 Windows Server 서비스 채널: LTSC 및 SAC를 참조하세요.
    • Windows Server CoreNano Server 모두 컨테이너의 기본 이미지로 사용될 수 있습니다.
    • Windows Server 컨테이너에는 중요한 버전 호환성 요구사항이 있습니다.
      • LTSC용으로 빌드된 Windows Server 컨테이너는 SAC 노드에서 실행되지 않으며 반대의 경우도 마찬가지입니다.
      • 특정 LTSC 또는 SAC 버전용으로 빌드된 Windows Server 컨테이너는 다른 버전을 타겟팅하기 위해 다시 빌드되지 않고는 다른 LTSC 또는 SAC 버전에서 실행되지 않습니다.
    • Windows Server 컨테이너 이미지를 여러 Windows Server 버전을 타겟팅할 수 있는 멀티 아키텍처 이미지로 빌드하면 이 버전 관리 복잡성을 관리하는 데 도움이 됩니다.
  • 새로운 기능:
    • 새 Windows Server 기능은 일반적으로 SAC 버전에 먼저 도입됩니다. 이로 인해 새 GKE Windows 기능이 SAC 노드 풀에 먼저 도입될 수 있습니다.
    • 아직 LTSC 출시 버전에서 사용할 수 없는 기능이 필요한 경우 SAC를 고려하세요.
  • 컨테이너 런타임:

    • Windows Server LTSC 및 SAC 노드 이미지의 경우 컨테이너 런타임은 Docker 또는 containerd일 수 있습니다. GKE 노드 버전 1.21.1-gke.2200 이상에서는 containerd 런타임을 사용하는 것이 좋습니다. 자세한 내용은 노드 이미지를 참조하세요.

gcloud 업데이트 및 구성

시작하기 전에 다음 태스크를 수행했는지 확인합니다.

  • Google Kubernetes Engine API를 사용 설정합니다.
  • Google Kubernetes Engine API 사용 설정
  • 이 태스크에 Google Cloud CLI를 사용하려면 gcloud CLI를 설치한 후 초기화합니다. 이전에 gcloud CLI를 설치한 경우 gcloud components update를 실행하여 최신 버전을 가져옵니다.

클러스터 및 노드 풀 만들기

Windows Server 컨테이너를 실행하려면 클러스터에 Windows 노드 풀과 Linux 노드 풀이 각각 하나 이상 있어야 합니다. Windows Server 노드 풀만 사용해서는 클러스터를 만들 수 없습니다. Linux 노드 풀은 중요한 클러스터 부가기능을 실행하는 데 필요합니다.

Linux 노드 풀은 클러스터 부가기능을 실행할 수 있을 만큼 충분한 용량을 확보하는 것이 중요하므로 자동 확장을 사용하는 것이 좋습니다.

gcloud

다음 필드를 사용하여 클러스터를 만듭니다.

gcloud container clusters create CLUSTER_NAME \
    --enable-ip-alias \
    --num-nodes=NUMBER_OF_NODES \
    --cluster-version=VERSION_NUMBER \
    --release-channel CHANNEL

다음을 바꿉니다.

  • CLUSTER_NAME: 클러스터에 대해 선택한 이름입니다.
  • --enable-ip-alias별칭 IP를 사용 설정합니다. Windows Server 노드에는 별칭 IP가 필요합니다. 별칭 IP의 이점에 대한 자세한 내용은 별칭 IP를 사용한 기본 컨테이너 라우팅 이해를 참조하세요.
  • NUMBER_OF_NODES: 만드는 Linux 노드 수입니다. 클러스터 부가기능을 실행하려면 충분한 컴퓨팅 리소스를 제공해야 합니다. 이는 선택적 필드이며 생략하면 기본값 3을 사용합니다.
  • VERSION_NUMBER: 사용할 특정 클러스터 버전이며 1.16.8-gke.9 이상이어야 합니다. 출시 채널을 지정하지 않으면 GKE는 해당 버전이 제공되는 가장 성숙한 출시 채널에 클러스터를 등록합니다.
  • CHANNEL: 클러스터를 등록할 출시 채널입니다. rapid ,regular, stable 또는 None 중 하나일 수 있습니다. 기본적으로 클러스터는 --cluster-version, --release-channel, --no-enable-autoupgrade, --no-enable-autorepair 플래그 중 하나 이상이 지정되지 않는 경우 regular 출시 채널에 등록됩니다. 클러스터 버전을 선택하고 클러스터를 출시 채널에 등록하지 않으려면 None을 지정해야 합니다.

다음 필드를 사용하여 Windows Server 노드 풀을 만듭니다.

gcloud container node-pools create NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --image-type=IMAGE_NAME \
    --no-enable-autoupgrade \
    --machine-type=MACHINE_TYPE_NAME \
    --windows-os-version=WINDOWS_OS_VERSION

다음을 바꿉니다.

  • NODE_POOL_NAME: Windows Server 노드 풀에 대해 선택한 이름입니다.
  • CLUSTER_NAME: 위에서 만든 클러스터의 이름입니다.
  • IMAGE_NAME: 다음 값 중 하나를 지정할 수 있습니다.

    이러한 노드 이미지에 대한 자세한 내용은 Windows 노드 이미지 선택 섹션을 참조하세요.

  • --no-enable-autoupgrade노드 자동 업그레이드를 사용 중지합니다. 사용 설정하기 전에 Windows Server 노드 풀 업그레이드를 검토하세요.

  • MACHINE_TYPE_NAME: 머신 유형을 정의합니다. Windows Server 노드에 추가 리소스가 필요하므로 n1-standard-2가 권장되는 최소 머신 유형입니다. 머신 유형 f1-microg1-small은 지원되지 않습니다. 요금은 머신 유형마다 다르게 청구됩니다. 자세한 내용은 머신 유형 가격표를 참조하세요.

  • WINDOWS_OS_VERSION: 이미지 유형 WINDOWS_LTSC_CONTAINERD에 사용할 Windows OS 버전을 정의합니다. 이 플래그는 선택적 플래그입니다. 지정되지 않은 경우 사용되는 기본 OS 버전은 LTSC2019입니다. Windows Server 2022 노드 풀을 만들려면 값을 ltsc2022로 설정합니다. Windows Server 2019 노드 풀을 만들려면 값을 ltsc2019로 설정합니다.

다음 예시에서는 Windows Server 2022 노드 풀을 만드는 방법을 보여줍니다.

gcloud container node-pools create node_pool_name \
    --cluster=cluster_name \
    --image-type=WINDOWS_LTSC_CONTAINERD \
    --windows-os-version=ltsc2022

다음 예시에서는 Windows Server 2022 OS 이미지를 사용하도록 기존 Windows 노드 풀을 업데이트하는 방법을 보여줍니다.

gcloud container node-pools create node_pool_name \
    --cluster=cluster_name \
    --windows-os-version=ltsc2022

콘솔

  1. Google Cloud 콘솔에서 Google Kubernetes Engine 페이지로 이동합니다.

    Google Kubernetes Engine으로 이동

  2. 만들기를 클릭합니다.

  3. 클러스터 기본사항 섹션에서 다음을 완료합니다.

    1. 클러스터의 이름을 입력합니다.
    2. 위치 유형에서 클러스터에 사용할 리전 또는 영역을 선택합니다.
    3. 제어 영역 버전에서 출시 채널을 선택하거나 정적 버전을 지정합니다. 정적 버전은 1.16.8-gke.9 이상이어야 합니다.
  4. 탐색 창의 노드 풀에서 default-pool을 클릭하여 Linux 노드 풀을 만듭니다. 이 노드 풀을 구성할 때는 클러스터 부가기능을 실행하기에 충분한 컴퓨팅 리소스를 제공해야 합니다. 또한 노드 및 해당 리소스(예: 방화벽 경로)에 사용 가능한 리소스 할당량이 있어야 합니다.

  5. 페이지 상단에서 노드 풀 추가를 클릭하여 Windows Server 노드 풀을 만듭니다.

  6. 노드 풀 세부정보 섹션에서 다음을 완료합니다.

    1. 노드 풀이름을 입력합니다.
    2. 정적 버전 노드의 경우 노드 버전을 선택합니다.
    3. 노드 풀에서 만들 노드 수를 입력합니다.
  7. 탐색창의 노드 풀에서 노드를 클릭합니다.

    1. 이미지 유형 드롭다운 목록에서 다음 노드 이미지 중 하나를 선택합니다.

      • Docker를 포함한 Windows 장기 서비스 채널
      • containerd를 포함한 Windows 장기 서비스 채널
      • Docker를 포함한 Windows 반기 채널
      • containerd를 포함한 Windows 반기 채널

      자세한 내용은 Windows 노드 이미지 선택 섹션을 참조하세요.

    2. 인스턴스에 사용할 기본 머신 구성을 선택합니다. Windows Server 노드에 추가 리소스가 필요하므로 n1-standard-2가 권장되는 최소 크기입니다. 머신 유형 f1-microg1-small은 지원되지 않습니다. 요금은 머신 유형마다 다르게 청구됩니다. 자세한 내용은 머신 유형 가격표를 참조하세요.

  8. 탐색 창에서 Windows Server 노드 풀의 이름을 선택합니다. 이렇게 하면 노드 풀 세부정보 페이지로 돌아갑니다.

    1. 자동화에서 노드 자동 업그레이드 사용 설정 체크박스를 선택 취소합니다. 자동 업그레이드를 사용 설정하기 전에 Windows Server 노드 풀 업그레이드 섹션을 검토하세요.
  9. 탐색창의 클러스터에서 네트워킹을 선택합니다.

    1. 고급 네트워킹 옵션에서 VPC 기반 트래픽 라우팅 사용 설정(별칭 IP 사용)이 선택되어 있는지 확인합니다. Windows Server 노드에는 별칭 IP가 필요합니다. 별칭 IP의 이점에 대한 자세한 내용은 별칭 IP를 사용한 기본 컨테이너 라우팅 이해를 참조하세요.
  10. 만들기를 클릭합니다.

Terraform

Google Terraform 제공업체를 사용하여 Windows Server 노드 풀이 있는 GKE 클러스터를 만들 수 있습니다.

Terraform 구성에 다음 블록을 추가합니다.

resource "google_container_cluster" "cluster" {
  project  = "PROJECT_ID"
  name     = "CLUSTER_NAME"
  location = "LOCATION"

  min_master_version = "VERSION_NUMBER"

  # Enable Alias IPs to allow Windows Server networking.
  ip_allocation_policy {
    cluster_ipv4_cidr_block  = "/14"
    services_ipv4_cidr_block = "/20"
  }

  # Removes the implicit default node pool, recommended when using
  # google_container_node_pool.
  remove_default_node_pool = true
  initial_node_count       = 1
}

# Small Linux node pool to run some Linux-only Kubernetes Pods.
resource "google_container_node_pool" "linux_pool" {
  name       = "linux-pool"
  project    = google_container_cluster.cluster.project
  cluster    = google_container_cluster.cluster.name
  location   = google_container_cluster.cluster.location
  node_count = 1

  node_config {
    image_type = "COS_CONTAINERD"
  }
}

# Node pool of Windows Server machines.
resource "google_container_node_pool" "windows_pool" {
  name       = "NODE_POOL_NAME"
  project    = google_container_cluster.cluster.project
  cluster    = google_container_cluster.cluster.name
  location   = google_container_cluster.cluster.location
  node_count = 1

  node_config {
    image_type   = "IMAGE_NAME"
    machine_type = "MACHINE_TYPE_NAME"
  }

  # The Linux node pool must be created before the Windows Server node pool.
  depends_on = [google_container_node_pool.linux_pool]
}

다음을 바꿉니다.

  • PROJECT_ID: 클러스터가 생성되는 프로젝트 ID입니다.
  • CLUSTER_NAME: GKE 클러스터의 이름입니다.
  • LOCATION: 클러스터가 생성되는 위치(리전 또는 영역)입니다.
  • VERSION_NUMBER: 1.16.8-gke.9 이상이어야 합니다.
  • NODE_POOL_NAME: Windows Server 노드 풀에 대해 선택한 이름입니다.
  • IMAGE_NAME: 다음 값 중 하나를 지정할 수 있습니다.

    이러한 노드 이미지에 대한 자세한 내용은 Windows 노드 이미지 선택 섹션을 참조하세요.

  • MACHINE_TYPE_NAME: 머신 유형을 정의합니다. Windows Server 노드에 추가 리소스가 필요하므로 n1-standard-2가 권장되는 최소 머신 유형입니다. 머신 유형 f1-microg1-small은 지원되지 않습니다. 요금은 머신 유형마다 다르게 청구됩니다. 자세한 내용은 머신 유형 가격표를 참조하세요.

Windows Server 노드 풀을 만든 후 제어 영역이 업데이트되면 몇 분 동안 클러스터가 RECONCILE 상태가 됩니다.

kubectl 사용자 인증 정보 가져오기

만든 클러스터에 kubectl이 작동하도록 하려면 get-credentials 명령어를 사용하세요.

gcloud container clusters get-credentials CLUSTER_NAME

get-credentials 명령어에 대한 자세한 내용은 SDK get-credentials 문서를 참조하세요.

클러스터 초기화 대기

클러스터를 사용하기 전에 windows.config.common-webhooks.networking.gke.io가 생성될 때까지 몇 초 동안 기다립니다. 이 웹훅은 kubernetes.io/os: windows 노드 선택기로 만든 포드에 일정 내결함성을 추가하여 포드가 Windows Server 노드에서 실행되도록 합니다. 또한 포드를 검증하여 Windows에서 지원되는 기능만 사용하는지 확인합니다.

웹훅이 생성되었는지 확인하려면 다음 명령어를 실행합니다.

kubectl get mutatingwebhookconfigurations

다음을 실행하는 웹훅이 출력에 표시되어야 합니다.

NAME                                              CREATED AT
windows.config.common-webhooks.networking.gke.io  2019-12-12T16:55:47Z

이제 Windows 애플리케이션을 배포할 수 있는 2개의 노드 풀(Linux 1개와 Windows 1개)이 있는 클러스터가 생겼습니다.

GKE 및 Windows 버전 매핑

Microsoft는 새로운 SAC 버전을 약 6개월마다, 새로운 LTSC 버전을 2~3년마다 출시합니다. 이러한 새 버전은 일반적으로 새 GKE 부 버전에서 사용할 수 있습니다. GKE 부 버전 내에서는 LTSC 및 SAC 버전은 일반적으로 변경되지 않습니다.

GKE 버전과 Windows Server 버전 간의 버전 매핑을 보려면 gcloud beta container get-server-config 명령어를 사용합니다.

gcloud beta container get-server-config

응답의 windowsVersionMaps 필드에 버전 매핑이 반환됩니다. 응답을 필터링하여 클러스터의 특정 GKE 버전에 대한 버전 매핑을 보려면 Linux 셸 또는 Cloud Shell에서 다음 단계를 수행합니다.

  1. 다음 변수를 설정합니다.

    CLUSTER_NAME=CLUSTER_NAME
    NODE_POOL_NAME=NODE_POOL_NAME
    ZONE=COMPUTE_ZONE
    

    다음을 바꿉니다.

    • CLUSTER_NAME: 클러스터 이름입니다.
    • NODE_POOL_NAME: Windows Server 노드 풀의 이름입니다.
    • COMPUTE_ZONE: 클러스터의 컴퓨팅 영역입니다.
  2. 노드 풀 버전을 가져와서 NODE_POOL_VERSION 변수에 저장합니다.

    NODE_POOL_VERSION=`gcloud container node-pools describe $NODE_POOL_NAME \
    --cluster $CLUSTER_NAME --zone $ZONE --format="value(version)"`
    
  3. NODE_POOL_VERSION의 Windows Server 버전을 가져옵니다.

    gcloud beta container get-server-config \
        --format="yaml(windowsVersionMaps.\"$NODE_POOL_VERSION\")"
    

    출력은 다음과 비슷합니다.

    windowsVersionMaps:
      1.18.6-gke.6601:
        windowsVersions:
        - imageType: WINDOWS_SAC
          osVersion: 10.0.18363.1198
          supportEndDate:
            day: 10
            month: 5
            year: 2022
        - imageType: WINDOWS_LTSC
          osVersion: 10.0.17763.1577
          supportEndDate:
            day: 9
            month: 1
            year: 2024
    
  4. WINDOWS_SAC 이미지 유형의 Windows Server 버전을 가져옵니다.

    gcloud beta container get-server-config \
      --flatten=windowsVersionMaps.\"$NODE_POOL_VERSION\".windowsVersions \
      --filter="windowsVersionMaps.\"$NODE_POOL_VERSION\".windowsVersions.imageType=WINDOWS_SAC" \
      --format="value(windowsVersionMaps.\"$NODE_POOL_VERSION\".windowsVersions.osVersion)"
    

    출력은 다음과 비슷합니다.

    10.0.18363.1198
    

Windows Server 노드 풀 업그레이드

Windows Server 컨테이너 버전 호환성 요구사항은 노드 풀을 업그레이드하기 전에 새 GKE 버전의 Windows Server 버전과 일치하도록 컨테이너 이미지를 다시 빌드해야 할 수도 있음을 의미합니다.

컨테이너 이미지가 노드와 계속 호환되도록 하려면 버전 매핑을 확인하고, Windows Server 컨테이너 이미지를 여러 Windows Server 버전을 타겟팅할 수 있는 멀티 아키텍처 이미지로 빌드하는 것이 좋습니다. 그런 다음 컨테이너 배포를 업데이트하여 GKE 노드 풀 업그레이드를 수동으로 호출하기 전에 현재 및 다음 GKE 버전 모두에서 작동하는 멀티 아키텍처 이미지를 타겟팅할 수 있습니다. 노드의 버전이 제어 영역 버전에 비해 부 버전 3개 이상 뒤쳐지면 안되므로 수동 노드 풀 업그레이드를 정기적으로 수행해야 합니다.

Pub/Sub를 통해 업그레이드 알림을 구독하여 새로운 GKE 버전과 사용되는 Windows OS 버전에 대한 업데이트를 사전에 수신하는 것이 좋습니다.

최신 Windows Server 버전을 타겟팅하는 멀티 아키텍처 Windows Server 컨테이너 이미지를 지속적으로 빌드하는 경우에만(특히 Windows Server SAC를 노드 이미지 유형으로 사용하는 경우) 노드 자동 업그레이드를 사용 설정하는 것이 좋습니다. 노드 자동 업그레이드로 인해 Windows Server LTSC 노드 이미지 유형에 문제가 발생할 가능성은 낮지만 버전 비호환성 문제가 발생할 위험이 있습니다.

Windows 업데이트

Windows Server 노드에는 Windows 업데이트가 사용 중지됩니다. 자동 업데이트로 인해 예측할 수 없는 시간에 노드가 다시 시작될 수 있으며, 노드가 시작된 후에 설치된 Windows 업데이트는 GKE에서 노드를 다시 만들 때 손실됩니다. GKE는 새 GKE 출시에 사용되는 Windows Server 노드 이미지를 정기적으로 업데이트하여 Windows 업데이트를 설치할 수 있도록 합니다. Windows 업데이트가 Microsoft에서 출시되는 시점과 GKE에서 제공되는 시점 사이에 지연이 발생할 수 있습니다. 중요한 보안 업데이트가 출시되면 GKE는 Windows Server 노드 이미지를 최대한 신속하게 업데이트합니다.

Windows 포드 및 서비스 통신 방법 제어

네트워크 정책을 사용하여 Windows 포드 및 서비스의 통신 방법을 제어할 수 있습니다.

GKE 버전 1.22.2 이상에서 네트워크 정책이 사용 설정된 클러스터에서 Windows Server 컨테이너를 설정할 수 있습니다. 이 기능은 WINDOWS_LTSC 또는 WINDOWS_LTSC_CONTAINERD 노드 이미지 유형을 사용하는 클러스터에 사용할 수 있습니다.

제어 영역 또는 노드가 이전 버전을 실행 중이면 노드 풀 및 제어 영역을 GKE 버전 1.22.2 이상으로 업그레이드하여 네트워크 정책을 지원하는 버전으로 노드 풀을 마이그레이션할 수 있습니다. 이 옵션은 --enable-dataplane-v2 플래그로 클러스터를 만든 경우에만 사용할 수 있습니다.

네트워크 정책을 사용 설정하면 이 기능을 사용 설정하기 전에 Windows Server 컨테이너에서 작동하지 않는 정책을 포함하여 이전에 구성된 모든 정책이 활성화됩니다.

일부 클러스터는 네트워크 정책이 사용 설정된 클러스터의 Windows Server 컨테이너에서 사용될 수 없습니다. 자세한 내용은 제한사항 섹션을 참조하세요.

로그 보기 및 쿼리

로깅은 GKE 클러스터에서 자동으로 사용 설정됩니다. Kubernetes Engine 모니터링을 사용하여 Windows Server 노드에서 컨테이너 로그와 다른 서비스의 로그를 볼 수 있습니다.

다음은 컨테이너 로그를 가져오기 위한 필터의 예시입니다.

resource.type="k8s_container"
resource.labels.cluster_name="your_cluster_name"
resource.labels.namespace_name="your_namespace_id"
resource.labels.container_name="your_container_name"
resource.labels.Pod_name="your_Pod_name"

원격 데스크톱 프로토콜(RDP)을 사용하여 Windows Server 노드에 액세스

RDP를 사용하여 클러스터의 Windows Server 노드에 연결할 수 있습니다. 연결 방법에 대한 안내는 Compute Engine 문서의 Windows 인스턴스에 연결을 참조하세요.

멀티 아키텍처 이미지 빌드

멀티 아키텍처 이미지를 수동으로 빌드하거나 Cloud Build 빌더를 사용할 수 있습니다. 자세한 내용은 Windows 멀티 아키텍처 이미지 빌드를 참조하세요.

gMSA 사용

다음 단계는 Windows Server 노드 풀에서 그룹 관리형 서비스 계정(gMSA)을 사용하는 방법을 보여줍니다.

  1. AD 도메인에 자동으로 조인하도록 클러스터에서 Windows Server 노드를 구성합니다. 자세한 안내는 Active Directory 도메인에 자동으로 조인하도록 Windows Server 노드 구성을 참조하세요.

  2. 도메인 조인 서비스에서 자동으로 생성된 보안 그룹에 gMSA 액세스 권한을 생성하고 부여합니다. 이 단계는 AD 도메인에 대해 관리 액세스 권한이 있는 머신에서 수행되어야 합니다.

    $instanceGroupUri = gcloud container node-pools describe NODE_POOL_NAME --cluster CLUSTER_NAME --format="value(instanceGroupUrls)"
    $securityGroupName = ([System.Uri]$instanceGroupUri).Segments[-1]
    $securityGroup = dsquery group -name $securityGroupName
    $gmsaName = GMSA_NAME
    $dnsHostName = DNS_HOST_NAME
    
    New-ADServiceAccount -Name $gmsaName -DNSHostName $dnsHostName -PrincipalsAllowedToRetrieveManagedPassword $securityGroup
    
    Get-ADServiceAccount $gmsaName
    Test-ADServiceAccount $gmsaName
    

    다음을 바꿉니다.

    • NODE_POOL_NAME: Windows Server 노드 풀의 이름입니다. 자동으로 생성된 보안 그룹은 Windows Server 노드 풀과 이름이 같습니다.
    • CLUSTER_NAME: 클러스터 이름입니다.
    • GMSA_NAME: 새 gMSA에 대해 선택한 이름입니다.
    • DNS_HOST_NAME: 만든 서비스 계정의 정규화된 도메인 이름(FQDN)입니다. 예를 들어 GMSA_NAMEwebapp01이고 도메인이 example.com이면 DNS_HOST_NAMEwebapp01.example.com입니다.
  3. Windows 포드 및 컨테이너에 GMSA 구성 튜토리얼의 안내에 따라 gMSA를 구성합니다.

Windows Server 노드 풀 삭제

gcloud 또는 Google Cloud 콘솔을 사용하여 Windows Server 노드 풀을 삭제합니다.

gcloud

gcloud container node-pools delete NODE_POOL_NAME \
    --cluster=CLUSTER_NAME

콘솔

Google Cloud 콘솔을 사용하여 Windows Server 노드 풀을 삭제하려면 다음 단계를 수행하세요.

  1. Google Cloud 콘솔에서 Google Kubernetes Engine 페이지로 이동합니다.

    Google Kubernetes Engine으로 이동

  2. 수정할 클러스터 옆의 작업을 클릭한 다음 수정을 클릭합니다.

  3. 노드 탭을 선택합니다.

  4. 노드 풀 섹션에서 삭제할 노드 풀 옆에 있는 삭제를 클릭합니다.

  5. 확인 메시지가 나타나면 삭제를 다시 클릭합니다.

제한사항

일부 Kubernetes 기능은 아직 Windows Server 컨테이너에서 지원되지 않습니다. 또한 일부 기능은 Linux에만 해당되며 Windows에서는 작동하지 않습니다. 지원되는 Kubernetes 기능과 지원되지 않는 Kubernetes 기능의 전체 목록은 Kubernetes 문서를 참조하세요.

지원되지 않는 Kubernetes 기능 외에도 지원되지 않는 일부 GKE 기능이 있습니다.

GKE 클러스터의 경우 Windows Server 노드 풀에서 다음 기능이 지원되지 않습니다.

Windows 노드 풀의 로컬 외부 트래픽 정책은 GKE 버전 v1.23.4-gke.400 이상에서만 지원됩니다.

GKE 클러스터에 사용하려는 다른 Google Cloud 제품이 Windows Server 노드 풀을 지원하지 않을 수 있습니다. 구체적인 제한사항은 해당 제품의 문서를 참조하세요.

문제 해결

포드 디버깅서비스 디버깅에 대한 일반적인 안내는 Kubernetes 문서를 참조하세요.

Containerd 노드 문제

Containerd 노드 이미지 사용에 관련하여 알려진 문제는 알려진 문제를 참조하세요.

Windows 포드 시작 실패

Windows Server 컨테이너와 컨테이너를 실행하려는 Windows 노드 간의 버전 불일치로 인해 Windows 포드 시작이 실패할 수 있습니다.

Windows 노드 풀 버전이 1.16.8-gke.8 이상인 경우 2020년 2월 Windows Server 컨테이너 비호환성 문제에 대한 Microsoft 문서를 검토하고 2020년 3월의 Windows 업데이트가 포함된 기본 Windows 이미지로 컨테이너 이미지를 빌드합니다. 이전의 기본 Windows 이미지에 빌드된 컨테이너 이미지는 이러한 Windows 노드에서 실행되지 않을 수 있으며 노드가 NotReady 상태로 실패할 수도 있습니다.

이미지 가져오기 오류

Windows Server 컨테이너 이미지와 이 이미지를 구성하는 개별 레이어는 상당히 클 수 있습니다. 이러한 큰 크기로 인해 컨테이너 레이어를 다운로드하고 추출할 때 Kubelet이 시간 초과되어 실패할 수 있습니다.

포드에 '이미지 가져오기 실패' 또는 '이미지 가져오기 컨텍스트 취소됨' 오류 메시지 또는 ErrImagePull 상태가 표시되는 경우 이 문제가 발생할 수 있습니다.

가져오기 이미지가 자주 발생하는 경우 CPU 사양이 더 높은 노드 풀을 사용해야 합니다. 컨테이너 추출은 여러 코어에서 동시에 실행되므로 머신 유형에 코어가 많으면 전체 가져오기 시간이 단축됩니다.

Windows Server 컨테이너를 성공적으로 가져오려면 다음 옵션을 시도해 보세요.

  • Windows Server 컨테이너 이미지의 애플리케이션 레이어를 작은 레이어로 나누면 각각 더 빠르게 가져와서 추출할 수 있습니다. 이렇게 하면 Docker의 레이어 캐싱이 더 효과적이 되고 이미지 가져오기 재시도가 성공할 가능성이 높아집니다. 레이어에 대한 자세한 내용은 Docker 문서 이미지, 컨테이너, 스토리지 드라이버 정보를 참조하세요.

  • 포드를 만들기 전에 Windows Server 노드에 연결하고 컨테이너 이미지에서 수동으로 docker pull 명령어를 사용하세요.

  • 컨테이너 이미지 가져오기 시간 제한을 늘리려면 kubelet 서비스의 image-pull-progress-deadline 플래그를 설정합니다.

    Windows 노드에 연결하고 다음 PowerShell 명령어를 실행하여 플래그를 설정합니다.

    1. Windows 레지스트리에서 Kubelet 서비스의 기존 명령줄을 가져옵니다.

      PS C:\> $regkey = "HKLM\SYSTEM\CurrentControlSet\Services\kubelet"
      
      PS C:\> $name = "ImagePath"
      
      PS C:\> $(reg query ${regkey} /v ${name} | Out-String) -match `
      "(?s)${name}.*(C:.*kubelet\.exe.*)"
      
      PS C:\> $kubelet_cmd = $Matches[1] -replace `
      "--image-pull-progress-deadline=.* ","" -replace "\r\n"," "
      
    2. Kubelet 서비스를 위한 새로운 명령줄을 추가 플래그와 함께 설정하여 시간 제한을 늘립니다.

      PS C:\> reg add ${regkey} /f /v ${name} /t REG_EXPAND_SZ /d "${kubelet_cmd} `
      --image-pull-progress-deadline=40m "
      
    3. 변경이 완료되었는지 확인합니다.

      PS C:\> reg query ${regkey} /v ${name}
      
    4. 새 플래그가 적용되도록 kubelet 서비스를 다시 시작합니다.

      PS C:\> Restart-Service kubelet
      
    5. kubelet 서비스가 다시 시작되었는지 확인합니다.

      PS C:\> Get-Service kubelet # ensure state is Running
      

지원 종료된 이미지 계열

Windows 이미지로 노드 풀을 만들면 다음과 비슷한 오류가 발생합니다.

WINDOWS_SAC image family for 1.18.20-gke.501 has reached end of life, newer versions are still available.

이 오류를 해결하려면 사용 가능하고 지원되는 Windows 이미지를 선택합니다. GKE 및 Windows 버전 매핑 섹션에 설명된 대로 gcloud container get-server-config 명령어를 사용하여 GKE Windows 노드 이미지의 지원 종료일을 찾을 수 있습니다.

노드 풀 생성 중 시간 초과

많은 수의 노드(예: 500)를 만들며 Windows Server 이미지를 사용하는 클러스터의 첫 번째 노드 풀을 만드는 경우 노드 풀 생성 시간이 초과될 수 있습니다.

이 문제를 해결하려면 만들려는 노드 수를 줄이세요. 나중에 노드 수를 늘릴 수 있습니다.

'PLEG가 정상이 아님' 오류와 함께 NotReady 상태가 된 Windows 노드

이는 여러 포드가 단일 Windows 노드에서 매우 빠르게 시작될 때 발생하는 알려진 Kubernetes 문제입니다. 이 상황에서 복구하려면 Windows Server 노드를 다시 시작합니다. 이 문제를 방지하려면 Windows 포드가 생성되는 속도를 30초마다 하나의 포드로 제한하는 것이 좋습니다.

일관되지 않은 TerminationGracePeriod

컨테이너의 Windows 시스템 시간 제한은 구성한 유예 기간과 다를 수 있습니다. 이 차이로 인해 런타임에 전달된 유예 기간 종료 전에 Windows가 컨테이너를 강제 종료할 수 있습니다.

이미지 빌드 시 컨테이너-로컬 레지스트리 키를 수정하여 Windows 시간 제한을 수정할 수 있습니다. Windows 시간 제한을 수정하는 경우 TerminationGracePeriodSeconds 일치하도록 수정해야 할 수 있습니다.

네트워크 연결 문제

Windows Server 컨테이너에서 네트워크 연결 문제가 발생하는 경우 Windows Server 컨테이너 네트워킹에서 Google Cloud의 MTU인 1460과 호환되지 않는 1500의 네트워크 MTU를 가정하기 때문일 수 있습니다.

컨테이너의 네트워크 인터페이스 MTU와 Windows Server 노드 자체의 네트워크 인터페이스 MTU가 모두 동일한 값(즉, 1460 이하)으로 설정되었는지 확인합니다. MTU를 설정하는 방법은 Windows 컨테이너의 알려진 문제를 참조하세요.

노드 시작 문제

노드가 클러스터에서 시작되지 않거나 클러스터에 성공적으로 연결되지 못하면 노드의 직렬 포트 출력에 제공되는 진단 정보를 검토합니다.

다음 명령어를 실행하여 직렬 포트 출력을 확인합니다.

gcloud compute instances get-serial-port-output NODE_NAME --zone=COMPUTE_ZONE

다음을 바꿉니다.

1.24 이하 버전을 실행하는 클러스터가 있는 Windows 노드에서 간헐적으로 연결할 수 없는 서비스

호스트 네트워크 서비스 부하 분산기 규칙이 많은 Kubernetes 클러스터에서 Windows 노드를 시작할 때는 규칙 처리가 지연됩니다. 규칙당 30초 정도 지속되는 지연 시 서비스에 간헐적으로 연결할 수 없으므로 규칙이 많은 경우 총 지연 시간이 상당히 길어질 수 있습니다. 자세한 내용은 GitHub의 원래 문제를 참조하세요.

kube-proxy를 다시 시작하는 이벤트(예: 노드 시작, 노드 업그레이드, 수동 다시 시작)를 가진 Windows 노드가 있는 버전 1.24 이하를 실행하는 GKE 클러스터의 경우 해당 노드에서 실행 중인 포드에 연결된 모든 서비스는 해당 구성요소에 의해 모든 규칙이 동기화될 때까지 연결할 수 없습니다.

버전 1.25 이상을 실행하는 GKE 클러스터의 경우 이 동작이 크게 개선되었습니다. 이 개선사항에 대한 자세한 내용은 GitHub의 pull 요청을 참조하세요. 이 문제가 발생하는 경우 클러스터의 제어 영역을 1.25 이상으로 업그레이드하는 것이 좋습니다.

다음 단계