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

gcloud 업데이트 및 구성

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

다음 방법 중 하나를 사용하여 기본 gcloud 설정을 진행합니다.

  • gcloud init를 사용하여 기본값 설정 과정을 진행합니다.
  • gcloud config를 사용하여 프로젝트 ID, 영역, 리전을 개별적으로 설정합니다.

gcloud init 사용

One of [--zone, --region] must be supplied: Please specify location 오류가 표시되면 이 섹션을 완료합니다.

  1. gcloud init를 실행하고 다음 안내를 따르세요.

    gcloud init

    원격 서버에서 SSH를 사용하는 경우 --console-only 플래그를 사용하여 다음 명령어로 브라우저를 실행하지 못하게 할 수 있습니다.

    gcloud init --console-only
  2. 안내를 따라 gcloud에서 Google Cloud 계정을 사용하도록 승인합니다.
  3. 새 구성을 만들거나 기존 구성을 선택합니다.
  4. Google Cloud 프로젝트를 선택합니다.
  5. 영역 클러스터의 기본 Compute Engine 영역이나 리전 또는 Autopilot 클러스터의 리전을 선택합니다.

gcloud config 사용

  • 기본 프로젝트 ID를 설정합니다.
    gcloud config set project PROJECT_ID
  • 영역 클러스터를 사용하는 경우 기본 컴퓨팅 영역을 설정합니다.
    gcloud config set compute/zone COMPUTE_ZONE
  • Autopilot 또는 리전 클러스터를 사용하는 경우 기본 컴퓨팅 리전을 설정합니다.
    gcloud config set compute/region COMPUTE_REGION
  • gcloud를 최신 버전으로 업데이트합니다.
    gcloud components update

Windows Server 노드 이미지 선택

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

이미지 유형을 선택할 때 다음 사항을 고려하세요.

  • Windows Server 노드 이미지의 지원 시점은 운영체제 수명 주기 및 지원 정책에 설명된 대로 Microsoft에서 제공하는 지원 시점입니다. 수명 주기가 더 긴 LTSC를 사용하는 것이 좋습니다. 아직 LTSC 출시 버전에서 사용할 수 없는 기능이 필요한 경우 SAC를 고려하세요.

  • SAC 버전은 최초 출시 후 18개월 동안 Microsoft에서만 지원됩니다. 노드 풀의 이미지 유형으로 SAC를 선택하지만 새 SAC 버전을 타겟팅하는 새 GKE 버전으로 노드 풀을 업그레이드하지 않는 경우, SAC 버전의 지원 수명 주기가 종료될 때 노드 풀에 새 노드를 만들 수 없습니다. Google의 Windows Server 운영체제 지원에 대해 자세히 알아보세요.

  • 노드 풀을 업그레이드할 수 있고 컨테이너가 정기적으로 실행되는 경우에만 SAC를 선택합니다. GKE는 새 GKE 출시에서 Windows 노드 풀에 사용되는 SAC 버전을 주기적으로 업데이트하므로, 노드 풀 이미지 유형에 SAC를 선택하면 컨테이너를 더 자주 빌드해야 합니다.

  • 새 Windows Server 기능은 일반적으로 SAC 버전에 먼저 도입됩니다. 이로 인해 새 GKE Windows 기능이 SAC 노드 풀에 먼저 도입될 수 있습니다.

  • 공개 버전 출시 채널에 GKE 클러스터를 등록하는 경우 SAC를 선택하지 마세요. SAC 버전은 18개월 동안 Microsoft에서만 지원되므로 GKE 공개 버전을 계속 사용할 수 있지만 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 버전을 타겟팅할 수 있는 멀티 아키텍처 이미지로 빌드하면 이 버전 관리 복잡성을 관리하는 데 도움이 됩니다.

버전 매핑

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

GKE 버전과 Windows Server 버전 간의 버전 매핑을 보려면 gcloud 명령줄 도구를 사용하거나 이 문서의 버전 매핑 표를 참조하세요.

gcloud 도구를 사용하여 버전 매핑 가져오기

사용 가능한 모든 GKE 버전에 대한 GKE 버전과 Windows Server Core 버전 간의 버전 매핑을 보려면 다음을 실행합니다.

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
    

버전 매핑 표

다음 표는 GKE 버전이 Windows Server 버전에 매핑되는 방식을 보여줍니다.

1.16

GKE 버전 SAC 버전 LTSC 버전
1.16.8-gke.8 - 1.16.13-gke.401 10.0.18363.720(Windows Server 버전 1909 Core) 10.0.17763.1098(Windows Server 2019 Core)
1.16.13-gke.402 - 1.16.13-gke.404 10.0.18363.1082(Windows Server 버전 1909 Core) 10.0.17763.1457(Windows Server 2019 Core)
1.16.15-gke.500 10.0.18363.720(Windows Server 버전 1909 Core) 10.0.17763.1098(Windows Server 2019 Core)
1.16.15-gke.1600 - 1.16.15-gke.3500 10.0.18363.1082(Windows Server 버전 1909 Core) 10.0.17763.1457(Windows Server 2019 Core)
1.16.15-gke.4300 - 1.16.15-gke.7400 10.0.18363.1016(Windows Server 버전 1909 Core) 10.0.17763.1397(Windows Server 2019 Core)
1.16.15-gke.7800 - 1.16.15-gke.11800(1.16.15-gke.7801 제외) 10.0.18363.1198(Windows Server 버전 1909 Core) 10.0.17763.1577(Windows Server 2019 Core)
1.16.15-gke.7801+(1.16.15-gke.10600 and 1.16.15-gke.11800 제외) 10.0.18363.1379(Windows Server 버전 1909 Core) 10.0.17763.1757(Windows Server 2019 Core)

1.17

GKE 버전 SAC 버전 LTSC 버전
1.17.9-gke.1504 - 1.17.12-gke.500 10.0.18363.900(Windows Server 버전 1909 Core) 10.0.17763.1282(Windows Server 2019 Core)
1.17.12-gke.1501 10.0.18363.1082(Windows Server 버전 1909 Core) 10.0.17763.1457(Windows Server 2019 Core)
1.17.12-gke.1504 - 1.17.13-gke.600 10.0.18363.900(Windows Server 버전 1909 Core) 10.0.17763.1282(Windows Server 2019 Core)
1.17.13-gke.1400 - 1.17.14-gke.1600 10.0.18363.1016(Windows Server 버전 1909 Core) 10.0.17763.1397(Windows Server 2019 Core)
1.17.15-gke.300 - 1.17.17-gke.1500(1.17.17-gke.1101 제외) 10.0.18363.1198(Windows Server 버전 1909 Core) 10.0.17763.1577(Windows Server 2019 Core)
1.17.17-gke.1101+(1.17.17-gke.1500 제외) 10.0.18363.1379(Windows Server 버전 1909 Core) 10.0.17763.1757(Windows Server 2019 Core)

1.18

GKE 버전 SAC 버전 LTSC 버전
1.18.6-gke.3503 - 1.18.9-gke.801 10.0.18363.900(Windows Server 버전 1909 Core) 10.0.17763.1282(Windows Server 2019 Core)
1.18.9-gke.1501 10.0.18363.1082(Windows Server 버전 1909 Core) 10.0.17763.1457(Windows Server 2019 Core)
1.18.9-gke.2501 - 1.18.10-gke.601 10.0.18363.900(Windows Server 버전 1909 Core) 10.0.17763.1282(Windows Server 2019 Core)
1.18.10-gke.1500 - 1.18.12-gke.1700(1.18.12-gke.1201 제외) 10.0.18363.1016(Windows Server 버전 1909 Core) 10.0.17763.1397(Windows Server 2019 Core)
1.18.12-gke.1201 10.0.18363.1198(Windows Server 버전 1909 Core) 10.0.17763.1577(Windows Server 2019 Core)
1.18.14-gke.1200 - 1.18.15-gke.1500(1.18.15-gke.1102 제외) 10.0.18363.1198(Windows Server 버전 1909 Core) 10.0.17763.1577(Windows Server 2019 Core)
1.18.15-gke.1102+(1.18.15-gke.1500 제외) 10.0.18363.1379(Windows Server 버전 1909 Core) 10.0.17763.1757(Windows Server 2019 Core)

1.19

GKE 버전 SAC 버전 LTSC 버전
1.19.6-gke.600 - 1.19.7-gke.1500 10.0.18363.658(Windows Server 버전 1909 Core) 10.0.17763.1577 (Windows Server 2019 Core)
1.19.8-gke.1600+ 10.0.19042.804(Windows Server 버전 20H2 Core) 10.0.17763.1757(Windows Server 2019 Core)

1.20

GKE 버전 SAC 버전 LTSC 버전
1.20.2-gke.1500 10.0.18363.658(Windows Server 버전 1909 Core) 10.0.17763.1757(Windows Server 2019 Core)
1.20.4-gke.500+ 10.0.19042.804(Windows Server 버전 20H2 Core) 10.0.17763.1757(Windows Server 2019 Core)

클러스터 및 노드 풀 만들기

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

Linux 노드 풀은 중요하므로 크기를 0으로 조절하지 말고 클러스터 부가기능을 실행할 용량이 충분한지 확인하세요.

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 이상이어야 합니다. --release-channel 플래그를 사용하여 출시 채널을 선택할 수도 있습니다.
  • CHANNEL: 클러스터를 등록할 출시 채널입니다. rapid ,regular, stable 또는 None 중 하나일 수 있습니다. 기본적으로 클러스터는 --cluster-version, --release-channel, --no-enable-autoupgrade, --no-enable-autorepair 플래그가 지정되지 않은 경우 regular 출시 채널에 등록됩니다.

다음 필드를 사용하여 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

다음을 바꿉니다.

  • NODE_POOL_NAME: Windows Server 노드 풀에 대해 선택한 이름입니다.
  • CLUSTER_NAME: 위에서 만든 클러스터의 이름입니다.
  • IMAGE_NAME: WINDOWS_LTSC 또는 WINDOWS_SAC입니다. 이러한 노드 이미지에 대한 자세한 내용은 Windows 노드 이미지 선택 섹션을 참조하세요.
  • --no-enable-autoupgrade노드 자동 업그레이드를 사용 중지합니다. 사용 설정하기 전에 Windows Server 노드 풀 업그레이드를 검토하세요.
  • MACHINE_TYPE_NAME: 머신 유형을 정의합니다. Windows Server 노드에 추가 리소스가 필요하므로 n1-standard-2가 권장되는 최소 머신 유형입니다. 머신 유형 f1-microg1-small은 지원되지 않습니다. 요금은 머신 유형마다 다르게 청구됩니다. 자세한 내용은 머신 유형 가격표를 참조하세요.

Console

  1. Cloud Console에서 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. 이미지 유형 드롭다운 목록에서 Windows 반기 채널 또는 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_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_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_LTSC 또는 WINDOWS_SAC입니다. 이러한 노드 이미지에 대한 자세한 내용은 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 노드 선택기로 만든 Pod에 일정 내결함성을 추가하여 Pod가 Windows Server 노드에서 실행되도록 합니다. 또한 Pod를 검증하여 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개)이 있는 클러스터가 생겼습니다.

Windows Server 노드 풀 업그레이드

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

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

최신 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 노드 이미지를 최대한 신속하게 업데이트합니다.

로그 보기 및 쿼리

로깅은 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 노드를 구성합니다. 자세한 내용은 AD 도메인에 자동으로 조인하도록 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 Pod 및 컨테이너에 GMSA 구성 가이드의 안내에 따라 gMSA를 구성합니다.

Windows Server 노드 풀 삭제

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

gcloud

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

Console

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

  1. Cloud Console에서 Google Kubernetes Engine 메뉴로 이동합니다.

    Google Kubernetes Engine 메뉴로 이동

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

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

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

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

제한사항

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

또한 일부 GKE 기능은 지원되지 않습니다.

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

Windows Server 노드 풀의 경우 다음 기능이 지원되지 않습니다.

문제 해결

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

Windows Pod 시작 실패

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

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

이미지 가져오기 오류

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

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

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

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

  • pod를 만들기 전에 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 `
      "${name}.*(C:.*kubelet\.exe.*)\r"
      
      PS C:\> $kubelet_cmd = $Matches[1]
      
    2. Kubelet 서비스를 위한 새로운 명령줄을 추가 플래그와 함께 설정하여 시간 제한을 늘립니다.

      PS C:\> reg add ${regkey} /f /v ${name} /t REG_EXPAND_SZ /d "${kubelet_cmd} `
      --image-pull-progress-deadline=15m
      
    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
      

노드 풀 생성 중 시간 초과

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

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

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

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

일관되지 않은 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

다음을 바꿉니다.

  • NODE_NAME: 노드 이름입니다.
  • COMPUTE_ZONE: 특정 노드의 컴퓨팅 영역입니다.

다음 단계