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. 노드 이미지 선택
  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 영역을 선택합니다.

gcloud config 사용

  • 기본 프로젝트 ID를 설정합니다.
    gcloud config set project project-id
  • 영역 클러스터를 사용하는 경우 기본 컴퓨팅 영역을 설정합니다.
    gcloud config set compute/zone compute-zone
  • 리전 클러스터를 사용하는 경우 기본 컴퓨팅 리전을 설정합니다.
    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 버전만 사용할 수 있습니다.

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

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

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

  • 새 Windows Server 기능은 일반적으로 SAC 버전에 먼저 도입됩니다. 이로 인해 새 GKE Windows 기능이 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 버전에 매핑되는 방식을 보여줍니다.

GKE 버전 SAC 버전 LTSC 버전
1.14.x(사전 체험판만 해당) 10.0.17763(Windows Server 버전 1809 Core) 없음
1.15.x(사전 체험판만 해당) 10.0.17763(Windows Server 버전 1809 Core) 없음
1.16.4-gke.25~1.16.7.x(베타만 해당) 10.0.18363.592(Windows Server 버전 1909 Core) 10.0.17763.973(Windows Server 2019 Core)
1.16.8-gke.8+ 10.0.18363.720(Windows Server 버전 1909 Core) 10.0.17763.1098(Windows Server 2019 Core)
1.17.x 10.0.18363.720(Windows Server 버전 1909 Core) 10.0.17763.1098(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

각 항목의 의미는 다음과 같습니다.

  • 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 플래그를 사용하여 기본 버전 1.16.8-gke.9 이상의 출시 채널을 선택할 수 있습니다.

다음 필드를 사용하여 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-nameWINDOWS_SAC 또는 WINDOWS_LTSC입니다. 이러한 노드 이미지에 대한 자세한 내용은 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 이상의 정적 버전을 선택합니다.
      또는
      마스터 버전에서 기본 버전 1.16.8-gke.9 이상의 출시 채널을 선택합니다.
  4. 탐색 창의 노드 풀에서 default-pool을 클릭하여 Linux 노드 풀을 만듭니다. 이 노드 풀을 구성할 때는 클러스터 부가기능을 실행하기에 충분한 컴퓨팅 리소스를 제공해야 합니다. 또한 노드 및 해당 리소스(예: 방화벽 경로)에 사용 가능한 리소스 할당량이 있어야 합니다.

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

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

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

    1. 이미지 유형 드롭다운 목록에서 Windows Server 반기 채널 또는 Windows Server 장기 서비스 채널을 선택합니다. 이러한 노드 이미지에 대한 자세한 내용은 Windows 노드 이미지 선택 섹션을 참조하세요.
    2. 인스턴스에 사용할 기본 머신 구성을 선택합니다. Windows Server 노드에 추가 리소스가 필요하므로 n1-standard-2가 권장되는 최소 크기입니다. 머신 유형 f1-microg1-small은 지원되지 않습니다. 요금은 머신 유형마다 다르게 청구됩니다. 자세한 내용은 머신 유형 가격표를 참조하세요.
  8. 탐색 창에서 Windows Server 노드 풀의 이름을 선택합니다. 이렇게 하면 노드 풀 세부정보 페이지로 돌아갑니다.

    1. Automation에서 노드 자동 업그레이드 사용 설정을 선택 해제합니다. 사용 설정하기 전에 Windows Server 노드 풀 업그레이드 섹션을 검토하세요.
  9. 탐색 창에서 네트워킹을 선택합니다.

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

Windows Server 노드 풀을 만들고 나면 클러스터는 마스터가 업데이트되는 몇 분 동안 RECONCILE 상태가 됩니다.

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

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

gcloud container clusters get-credentials 

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 버전 모두에서 작동하는 멀티 아키텍처 이미지를 타겟팅할 수 있습니다. 노드의 버전이 마스터 버전에 비해 부 버전 두 개 이상 뒤쳐지면 안되므로 수동 노드 풀 업그레이드를 정기적으로 수행해야 합니다.

최신 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 인스턴스에 연결을 참조하세요.

멀티 아키텍처 이미지 빌드

Docker는 멀티 아키텍처(또는 다중 플랫폼) 이미지를 지원합니다. 멀티 아키텍처 이미지를 사용하면 노드의 컨테이너 런타임이 호환되는 플랫폼 이미지를 가져올 수 있습니다. 멀티 아키텍처 이미지 매니페스트를 빌드하려면 각 플랫폼의 이미지를 빌드한 다음 각 플랫폼의 해당 이미지를 참조하는 매니페스트를 빌드해야 합니다.

멀티 아키텍처 이미지 매니페스트를 빌드하려면 다음 안내를 따르세요.

  1. LTSC 2019 Docker 이미지를 만듭니다. 예를 들면 gcr.io/my-project/foo:1.0-2019입니다.
  2. SAC 1909 Docker 이미지를 만듭니다. 예: gcr.io/my-project/foo:1.0-1909
  3. Windows Server 버전 1909 VM을 만듭니다.
  4. RDP를 사용하여 VM에 연결합니다.
  5. PowerShell을 실행합니다.
  6. docker manifest 실험용 기능을 사용 설정합니다.
    PS C:> $env:DOCKER_CLI_EXPERIMENTAL = 'enabled'
    
  7. 멀티 아키텍처 매니페스트를 만듭니다.
    docker manifest create gcr.io/my-project/foo:1.0 gcr.io/my-project/foo:1.0-2019 gcr.io/my-project/foo:1.0-1909
    
  8. 새로 만든 매니페스트를 푸시합니다.
    docker manifest push gcr.io/my-project/foo:1.0 gcr.io/my-project/foo:1.0-2019 gcr.io/my-project/foo:1.0-1909
    

Windows Server 노드 풀 삭제

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

gcloud

gcloud container node-pools delete --cluster=cluster-name node-pool-name

Console

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

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

    Google Kubernetes Engine 메뉴로 이동

  2. 삭제하려는 노드 풀이 있는 클러스터 옆의 수정 아이콘(연필 모양)을 클릭합니다.

  3. 노드 풀 섹션에서 삭제하려는 노드 풀 옆에 있는 삭제 아이콘(휴지통 모양)을 클릭합니다.

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

제한사항

일부 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 이미지를 사용하는 클러스터의 첫 번째 노드 풀을 만드는 경우 노드 풀 생성 시간이 초과될 수 있습니다.

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

gMSA 사용

그룹 관리형 서비스 계정(gMSA)을 사용하는 데 문제가 있는 경우 Active Directory의 컴퓨터 이름 제한 때문일 수 있습니다. Active Directory는 컴퓨터 이름을 15자(영문 기준)로 제한합니다. GKE를 사용하는 경우 이 이름은 GKE 노드 이름에서 파생됩니다. 노드 이름은 노드 풀 이름과 그 뒤의 고유한 문자열로 구성됩니다. 노드 이름이 15자를 넘으면 다시 15자로 잘립니다.

예를 들어 노드의 이름이 gke-cluster-windows--node-pool-window-3d3afc34- wnnn이면 GKE-CLUSTER-WIN으로 잘립니다.

다른 노드의 이름이 gke-cluster-windows--node-pool-window-123gtj12-aabb이면 이 이름도 GKE-CLUSTER-WIN로 잘립니다.

Active Directory에서는 컴퓨터와 이름에 일대일 관계가 있으므로 두 컴퓨터가 이름을 공유하면 오류가 발생합니다.

이 문제를 방지하려면 Active Directory에 가입할 때 컴퓨터 이름을 변경하세요. 컴퓨터 이름을 바꾼 후 노드의 kubelet 및 kube-proxy 구성도 업데이트하여 노드의 클러스터 연결이 중지되는 문제를 방지합니다. kubelet 및 kube-proxy 서비스 경로에 --hostname-override 플래그를 추가하면 됩니다. 플래그를 노드의 인스턴스 이름으로 설정하고 서비스를 다시 시작합니다.

구성을 업데이트하려면 다음 명령어를 실행합니다.

sc.exe config service-name binPath="existing-service-binpath --hostname-override=node-instance-name"

각 항목의 의미는 다음과 같습니다.

  • service-namekubelet 또는 kube-proxy입니다. 이 스크립트를 서비스당 한 번 실행합니다.
  • existing-service-binpath는 서비스의 binPath입니다. sc.exe qc service-name을 사용하여 검색할 수 있습니다.
  • node-instance-name은 노드 VM의 인스턴스 이름입니다.

이렇게 하면 문제가 해결되고 노드 및 호스트 Pod가 표시됩니다. 또한 Active Directory에서 이름 충돌을 피할 수 있습니다.

Microsoft Active Directory용 관리형 서비스에 대한 참고사항

Microsoft Active Directory용 관리형 서비스에서 gMSA를 설정하려면 몇 가지 추가 단계가 필요합니다. 이 프로세스는 Managed Microsoft AD의 기본 객체 및 권한과 표준 AD 간의 차이로 인해 약간 다릅니다. 관리형 Microsoft AD에서 gMSA를 만드는 방법에 대해 알아보세요.

'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 컨테이너의 알려진 문제를 참조하세요.

다음 단계