Windows Server OS 노드 풀 사용자 가이드

VMware용 GKE를 사용하여 Windows Server OS 노드의 노드 풀을 만들 수 있습니다. 또한 Windows Server OS 노드 풀을 실행하는 사용자 클러스터는 Ubuntu 또는 Container-Optimized OS를 사용하여 노드의 노드 풀을 실행할 수 있습니다.

Windows Server OS 노드 풀 요구사항

노드 풀의 노드는 모두 osImageType 매개변수로 표시된 동일한 운영체제를 사용해야 합니다.

사용자 클러스터에서 Windows Server OS 노드가 있는 노드 풀을 만들기 전 다음 요구사항이 충족되었는지 확인해야 합니다.

  • Windows 노드 풀이 사용자 클러스터에서만 지원되기 때문에 Windows 노드 풀을 만들려면 먼저 관리자 클러스터를 배치해야 합니다.
  • Windows 노드 풀을 만들려면 Linux 노드 풀이 필요하기 때문에 사용자 클러스터가 Linux 노드 풀을 하나 이상 실행해야 합니다.
  • Windows 노드 풀을 포함하는 사용자 클러스터는 사용자 클러스터 구성 파일에서 enabledataplanev2 필드가 true로 설정되어 있어야 합니다. 이렇게 하면 해당 클러스터의 Linux 노드에서 Dataplane V2가 사용 설정됩니다.

  • 기본적으로 새 사용자 클러스터의 Windows 노드 풀에는 Windows Dataplane V2가 사용 설정됩니다.

  • Windows 노드 풀 관련 VM 템플릿을 만들기 위해 Microsoft에서 Windows Server 2019 ISO를 다운로드해야 합니다. ISO의 언어/리전 태그는 en-US여야 합니다.

  • vSphere 환경은 vSphere 6.7, 업데이트 3 이상이어야 합니다.

사용자 클러스터에서 Windows 노드 풀 만들기

1단계: VMware용 GKE의 Windows VM 템플릿 만들기

시작하기 전에 관리자 클러스터가 이미 생성되었는지 확인합니다.

  1. Windows Server 2019 ISO에서 기본 Windows VM 템플릿을 만듭니다.

    • Windows Server 2019 ISO를 설치할 Windows VM의 초기 네트워크 어댑터 유형은 E1000E여야 합니다.
    • 다음 단계 수행: Windows Server 2019용으로 VMware vSphere 템플릿을 만듭니다.
    • 나중에 사용할 수 있도록 Windows ISO 설치 프로그램을 실행할 때 설정된 초기 비밀번호를 기록해 둡니다.
    • Windows Server 2019의 최신 검증 패치 버전을 사용하고 있는지 확인하세요. 지정된 Anthos 출시 버전의 검정된 최신 Windows OS 이미지 버전은 출시 노트에서 확인할 수 있습니다. 보안 패치 프로세스를 참조하세요.
    • IDE 컨트롤러를 사용하는 기기는 기본 VM 템플릿에 연결할 수 없습니다.

  2. 아직 설치되지 않았으면 VMWare 안내에 따라 Windows VM 템플릿에 VMware 도구를 설치합니다.

  3. Windows VM 템플릿을 만듭니다.

    gkectl prepare windows \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --base-vm-template BASE_WINDOWS_VM_TEMPLATE \
    --bundle-path BUNDLE \
    [--skip-sysprep]

    다음을 바꿉니다.

    • ADMIN_CLUSTER_KUBECONFIG: 관리자 클러스터 kubeconfig 파일의 경로

    • BASE_WINDOWS_VM_TEMPLATE: 기본 Windows VM 템플릿의 경로

    • BUNDLE: VMware용 GKE 번들 파일 경로

    기본 Windows VM 템플릿을 빌드하는 과정에서 gkectl prepare windows는 Windows sysprep를 실행합니다. 이는 VM 템플릿을 일반화하고 VM의 네트워크 설정을 삭제하므로 동일한 템플릿에서 VM이 클론될 때 IP 주소 충돌을 방지하는 데 도움이 됩니다. 하지만 Windows sysprep는 닫힌 상자로 실행되므로 특정 sysprep 오류를 처리하기 어렵습니다.

    Windows sysprep를 실행하지 않고 기본 Windows VM 템플릿을 빌드하려면 gkectl prepare windows 명령어에 --skip-sysprep를 포함합니다.

  4. 명령어 결과의 마지막 줄에서 생성된 Windows VM 템플릿의 이름을 찾을 수 있습니다. 나중에 사용할 수 있도록 이름을 기록해 둡니다. 이 이름의 형식은 다음과 같습니다.

    Successfully created Anthos Windows VM template "gke-on-prem-windows-server-2019-VERSION"

2단계: 비공개 레지스트리에 Windows 컨테이너 이미지 업로드

비공개 레지스트리를 사용하지 않는 경우 이 단계를 생략합니다.

Linux 관리자 워크스테이션에서 containerd를 사용하여 비공개 레지스트리에 Windows 컨테이너 이미지 업로드를 자동화할 수 있습니다. 그러나 containerd는 Windows 컨테이너 이미지 기본 레이어를 푸시할 수 없습니다. 즉, 이미지를 가져올 때 기본 레이어를 Microsoft 레지스트리에서 가져와야 합니다. 기본 레이어를 푸시하려면 옵션 2 단계를 따르세요.

옵션 1: Windows 기본 레이어 이미지를 비공개 레지스트리에 수동으로 푸시할 필요가 없는 경우

gkectl prepare --config <var class="edit">ADMIN_CLUSTER_CONFIG</var> --upload-windows-images

ADMIN_CLUSTER_CONFIG를 관리자 클러스터 구성 파일의 경로로 바꿉니다.

--upload-windows-images 플래그는 Windows 컨테이너 이미지를 푸시하도록 지정합니다. 이 플래그를 지정하지 않으면 Linux 컨테이너 이미지만 비공개 레지스트리로 푸시됩니다.

옵션 2: Windows 기본 레이어 이미지를 비공개 레지스트리에 수동으로 푸시해야 하는 경우

  • 이 단계를 시도하려면 Docker가 설치되고 gcr.io에 액세스할 수 있는 Windows 머신을 사용합니다. Windows 컨테이너 이미지는 Windows 머신으로만 가져올 수 있습니다.
  • docker login을 실행하여 비공개 레지스트리에 인증을 수행합니다.

  • 다음 단계에 따라 기본 레이어와 함께 Windows 컨테이너 이미지를 비공개 레지스트리에 업로드합니다.

    • Windows 머신에서 Docker daemon.json 파일로 이동합니다. 

      PS C:> cat C:\ProgramData\docker\config\daemon.json

    • 다음 줄을 추가하여 비공개 레지스트리에 외부 레이어 푸시를 허용하도록 Docker daemon.json 파일을 구성합니다.

    {
  "allow-nondistributable-artifacts": ["PRIVATE_REGISTRY_NAME"]
}
    • 필요한 Windows 컨테이너 이미지를 로컬 Windows 머신에 다운로드한 후 태그를 지정하고 비공개 레지스트리에 푸시합니다. daemon.json Docker 구성 파일에 수행된 변경사항은 기본 레이어를 비공개 레지스트리에 푸시할 수 있음을 의미합니다. 이 작업을 완료하려면 다음 명령어를 실행합니다.
# Pull the Windows container images
docker pull gcr.io/gke-on-prem-release/pause-win:gke_windows_pause_20210302_RC00_2019
docker pull gcr.io/gke-on-prem-release/fluent-bit-win:v1.8.3-gke.1_ltsc2019
docker pull gcr.io/gke-on-prem-release/gke-metrics-agent-windows:0.3.10-gke.0_2019

# Tag the images to use private registry
docker tag gcr.io/gke-on-prem-release/pause-win:gke_windows_pause_20210302_RC00_2019 $PRIVATE_REGISTRY_URL/pause-win:gke_windows_pause_20210302_RC00_2019
docker tag gcr.io/gke-on-prem-release/fluent-bit-win:v1.8.3-gke.1_ltsc2019 $PRIVATE_REGISTRY_URL/fluent-bit-win:v1.8.3-gke.1_ltsc2019
docker tag gcr.io/gke-on-prem-release/gke-metrics-agent-windows:0.3.10-gke.0_2019 $PRIVATE_REGISTRY_URL/gke-metrics-agent-windows:0.3.10-gke.0_2019

# Push to private registry
docker push PRIVATE_REGISTRY_URL/pause-win:gke_windows_pause_20210302_RC00_2019
docker push PRIVATE_REGISTRY_URL/fluent-bit-win:v1.8.3-gke.1_ltsc2019
docker push PRIVATE_REGISTRY_URL/gke-metrics-agent-windows:0.3.10-gke.0_2019

3단계: (프록시 사용 시 필요) Windows 노드 풀 만들기를 위한 URL 허용 목록 지정

클러스터가 프록시 서버 뒤에 있으면 VMware용 GKE에 필요한 다른 주소 외에도 이 URL을 프록시 서버 허용 목록에 추가합니다.

# Microsoft registry URLs, needed by every Windows node if using GCR
mcr.microsoft.com
.data.mcr.microsoft.com
go.microsoft.com
winlayers.cdn.mscr.io

# Microsoft WSUS server URLs, needed by `gkectl prepare windows` on the Windows VM
windowsupdate.microsoft.com
.windowsupdate.microsoft.com
.windowsupdate.microsoft.com
.update.microsoft.com
.windowsupdate.com
download.windowsupdate.com
download.microsoft.com
.download.windowsupdate.com
wustat.windows.com
ntservicepack.microsoft.com
go.microsoft.com
dl.delivery.mp.microsoft.com

# Cloudbase-Init URL, needed by `gkectl prepare windows` on the Windows VM
https://cloudbase.it

# Powershell Gallery URLs, needed by `gkectl prepare windows` on the Windows VM
psg-prod-eastus.azureedge.net
az818661.vo.msecnd.net
devopsgallerystorage.blob.core.windows.net
.powershellgallery.com

# Windows Update Service, needed by `gkectl prepare windows` on the Windows VM
onegetcdn.azureedge.net
sws.update.microsoft.com
tsfe.trafficshaping.dsp.mp.microsoft.com
fe3.delivery.mp.microsoft.com
.prod.do.dsp.mp.microsoft.com
emdl.ws.microsoft.com
adl.windows.com
activation-v2.sls.microsoft.com
crl.microsoft.com
ocsp.digicert.com
ctldl.windowsupdate.com
login.live.com
licensing.mp.microsoft.com
www.msftconnecttest.com
settings-win.data.microsoft.com
wdcp.microsoft.com
smartscreen-prod.microsoft.com
checkappexec.microsoft.com
arc.msn.com
ris.api.iris.microsoft.com
.tlu.dl.delivery.mp.microsoft.com
.au.windowsupdate.com
www.microsoft.com
fe3.delivery.dsp.mp.microsoft.com.nsatc.net
cs9.wac.phicdn.net
geo-prod.do.dsp.mp.microsoft.com
slscr.update.microsoft.com
v10.events.data.microsoft.com

# Access for Installing docker, needed by `gkectl prepare windows` on the Windows VM
dockermsft.azureedge.net

4단계: 사용자 클러스터 구성 파일에 Windows 노드 풀 추가

  1. Windows 노드 풀을 사용하도록 사용자 클러스터에 Dataplane V2가 사용 설정되어 있어야 합니다. Dataplane V2를 사용 설정하도록 사용자 클러스터 구성 파일에 다음 줄을 추가합니다.

    enableDataplaneV2: true

  2. 사용자 클러스터 구성 파일의 nodePools 섹션에 Windows 노드 풀을 추가합니다. Windows 노드 풀 외에도 하나 이상의 Linux 노드 풀이 필요합니다. Windows 노드 풀을 만들도록 osImage 및 osImageType 필드를 설정합니다.

  • osImage: WINDOWS_VM_TEMPLATE_NAME을 1단계에서 준비한 Windows VM 템플릿의 이름으로 바꿉니다. 이 템플릿은 사용자 클러스터 구성 파일에 지정된 동일한 vCenter Datastore에 있어야 합니다.
  • osImageType: OS 이미지 유형을 windows로 지정합니다.
# user-cluster.yaml

nodePools:
- name: windows-nodepool-1
  cpus: 8
  memoryMB: 16384
  replicas: 3
  bootDiskSizeGB: 100
  osImage: WINDOWS_VM_TEMPLATE_NAME
  osImageType: windows

5단계: Windows 노드 풀 만들기

Windows 노드 풀을 만들기 전 Windows에 대해 프리플라이트 검사기 목록을 실행합니다. 이미 사용자 클러스터가 있다면 이 단계를 건너뛰세요. - (선택사항) Windows에 대해 테스트 VM을 만들고 Windows VM 템플릿을 검사하는 고속 및 저속 프리플라이트 검사를 둘 중 하나 또는 모두 실행합니다.

gkectl check-config --config USER_CLUSTER_CONFIG --kubeconfig ADMIN_CLUSTER_KUBECONFIG
  • 이 명령어는 사용자 클러스터를 만들기 전에 실행해야 합니다. 이미 사용자 클러스터가 있는 경우 특정 검사가 실패할 수 있습니다. 예를 들어 hostconfig.yaml 파일의 IP 주소를 사용자 클러스터의 기존 노드에서 이미 사용 중일 수 있습니다.
  • 권장되지는 않지만 --skip-validation-windows 플래그로 Windows 프리플라이트 검사를 건너뛸 수 있습니다.
  • Windows 노드 풀 관리는 Linux 노드 풀과 동일합니다. 노드 풀 관리를 참조하세요. 또한 클러스터 및 노드 풀 만들기, 업데이트, 업그레이드 명령어가 동일하게 유지되며 여기에 나열되어 있습니다.
# Create a new cluster
gkectl create cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

# Update an existing cluster with the new Windows node pool
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

# Upgrade an existing cluster with the new Windows node pool
gkectl upgrade cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

6단계: 실행 중인 Windows 노드 검사

  1. Windows 노드가 생성되었고 Ready인지 확인합니다.

    kubectl --kubeconfig USER_KUBECONFIG get nodes

  2. 사용자 클러스터를 진단하여 정상 상태인지 여부를 확인합니다.

    gkectl diagnose cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG  --cluster-name CLUSTER_NAME

Windows 포드 배포

Windows Server 노드는 node.kubernetes.io/os=windows:NoSchedule 키-값 쌍으로 taint됩니다.

이 taint는 GKE 스케줄러가 Windows Server 노드에서 Linux 컨테이너를 실행하지 않도록 합니다. Windows Server 노드에서 Windows Server 컨테이너를 예약하려면 매니페스트 파일에 nodeSelector 섹션이 포함되어야 합니다.

nodeSelector:
    kubernetes.io/os: windows

nodeSelector가 구성된 클러스터에서 실행되는 허용 웹훅은 새 워크로드에 이 Windows 노드 선택기가 있는지 확인하고 발견하면 다음 톨러레이션(toleration)을 워크로드에 적용하여 taint된 Windows Server 노드에서 실행되도록 합니다.

tolerations:
- key: "node.kubernetes.io/os"
  operator: "Equal"
  value: "windows"
  effect: "NoSchedule"

1단계: 인터넷 정보 서비스(IIS) 배포 파일 만들기

다음은 Microsoft의 공식 IIS 이미지를 단일 포드에 배포하는 샘플 구성입니다.

다음 콘텐츠로 iis.yaml이라는 IIS 파일을 만듭니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: iis
  labels:
    app: iis
spec:
  replicas: 1
  selector:
    matchLabels:
      app: iis
  template:
    metadata:
      labels:
        app: iis
    spec:
      nodeSelector:
        kubernetes.io/os: windows
      containers:
      - name: iis-server
        image: mcr.microsoft.com/windows/servercore/iis
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: iis
  name: iis
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: iis
  sessionAffinity: None
  type: LoadBalancer
  loadBalancerIP: [Fill in with an available IP address]

2단계: 배포를 만들고 서비스를 통해 노출

# Create the deployment
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG create -f iis.yaml

3단계: 포드 검사

kubectl을 사용하여 포드 상태를 확인합니다.

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pods

반환된 출력에 포드 상태가 'Running'으로 표시될 때까지 기다립니다.

NAME                   READY     STATUS    RESTARTS   AGE
iis-5c997657fb-w95dl   1/1       Running   0          28s

서비스 상태를 가져오고 외부 IP 필드가 채워질 때까지 기다립니다.

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG  get service iis

예상 출력:

NAME   TYPE           CLUSTER-IP    EXTERNAL-IP   PORT(S)        AGE
iis    LoadBalancer   10.44.2.112   35.x.x.x     80:32233/TCP   17s

IIS 웹페이지를 보기 위해 브라우저를 사용하여 http://EXTERNAL_IP를 열 수 있습니다.

사용자 클러스터를 Windows 노드 풀로 업그레이드

Windows 노드 풀을 사용한 사용자 클러스터의 업그레이드 프로세스는 Linux 전용 사용자 클러스터를 업그레이드하는 것과 비슷하지만, 업그레이드하기 전 기본 VM 템플릿에서 Windows VM 템플릿을 만들어야 한다는 것이 다릅니다.

Microsoft에서 새 버전의 Windows Server 2019 패치 버전을 보안 패치로 다운로드하여 업그레이드하는 동안 기본 VM 템플릿의 패치 빌드 버전을 업데이트할 수 있습니다. 보안 패치 프로세스를 참조하세요.

gkectl prepare windows --base-vm-template $BASE_WINDOWS_VM_TEMPLATE_NAME --bundle-path BUNDLE_PATH --kubeconfig ADMIN_CLUSTER_KUBECONFIG

구성 파일에서 노드 풀의 osImage 필드를 새 VM 템플릿 이름으로 업데이트합니다. 사용자 클러스터 업그레이드를 위해 아래 명령어를 실행합니다.

gkectl upgrade cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

다음을 바꿉니다.

  • ADMIN_CLUSTER_KUBECONFIG를 관리자 kubeconfig 파일 경로로 바꿉니다.
  • ADMIN_CLUSTER_CONFIG를 관리자 클러스터 구성 파일의 경로로 바꿉니다.

Windows 노드 액세스

Windows 노드에 액세스하는 표준 방법은 사용자 이름과 비밀번호를 사용하는 것이며, 이는 일반적으로 인증을 위해 SSH 키 쌍을 통해 액세스하는 Linux 노드와는 다릅니다.

vSphere 기반 Windows 노드의 경우 사용자 이름은 Administrator입니다. 비밀번호는 clusterapi-controller에 의해 생성되고 관리자 클러스터의 사용자 네임스페이스에 있는 windows-node-password 보안 비밀에 저장됩니다. 이 보안 비밀에서 비밀번호를 가져오는 명령어는 다음과 같습니다.

kubectl get secret windows-node-password -n [USER_CLUSTER_NAME] --kubeconfig admin-kubeconfig.yaml -o jsonpath={.data.*} | base64 -d

vCenter 사용자 인터페이스를 사용하여 비밀번호를 가져올 수도 있습니다. 로그인하려는 VM으로 이동한 후 해당 VM의 password vApp 속성에서 비밀번호를 찾을 수 있습니다.

사용자 이름과 비밀번호가 있으면 다음 방법을 사용하여 Windows VM에 액세스할 수 있습니다.

원격 데스크톱 프로토콜 사용

템플릿 빌드 중에 RDP가 사용 설정되었으므로 RDP 클라이언트를 사용하여 Windows VM에 액세스할 수 있습니다.

SSH 사용

SSH로 Windows VM에 연결하려면 다음을 수행합니다.

ssh Administrator@[VM_IP_ADDRESS]

프롬프트에 따라 비밀번호를 입력하여 VM에 연결합니다.

Windows VM 간 파일 전송

scp 명령어를 사용하여 Windows VM과 파일을 주고 받을 수 있습니다.

Windows VM에 파일을 업로드합니다.

scp [LOCAL_FILE_PATH] Administrator@[VM_IP_ADDRESS]:/[REMOTE_FILE_PATH]

Windows VM에서 파일을 다운로드합니다.

scp Administrator@[VM_IP_ADDRESS]:/[REMOTE_FILE_PATH] [LOCAL_FILE_PATH]

메시지가 표시되면 비밀번호를 입력합니다.

또는 Windows VM으로 파일 전송에 설명된 대로 Cloud Storage 또는 RDP를 사용하여 파일을 전송할 수도 있습니다.

Windows Server 구성 업데이트

containerd 및 Windows Dataplane V2는 이제 버전 1.11부터 정식 버전으로 제공됩니다.

Windows용 Docker 및 Flannel 노드는 이후 출시 버전에서 지원 중단됩니다. 해당하는 경우 지금 containerd 및 Windows Dataplane V2를 대신 사용하도록 구성을 업데이트하는 것이 좋습니다. Windows Server 구성 업데이트를 참조하세요.

Windows VM에 SSH/RDP로 연결할 수 없음

vCenter 웹 콘솔에서 Test-NetConnection을 실행하여 VM에 네트워크 연결이 있는지 확인합니다.

네트워크 연결이 있으면 결과에 PingSucceeded: true가 포함됩니다. VM에 네트워크 연결이 없으면 이 VM에 사용되는 네트워크 어댑터를 확인합니다. 네트워크에서 SSH/RDP를 실행하려는 워크스테이션에서 VM으로의 인바운드 연결이 허용되는지 확인합니다.

kubelet, kube-proxy, CNI 서비스가 Windows VM에서 실행 중인지 확인

다음 단계를 수행하여 VM에 연결하고 설정에 따라 다음 명령어를 실행합니다.

  1. 모든 구성에 다음 명령어를 실행합니다.

    # Check that kubelet and kube-proxy services have status 'Running'
Get-Service kubelet
Get-Service kube-proxy

  2. 클러스터가 true로 설정된 windowsDataplaneV2로 구성된 경우 antrea-agent, ovsdb-server 및 ovs-vswitchd 서비스가 'Running'인지 확인합니다.

    # Check that CNI services have the status of 'Running'
Get-Service antrea-agent
Get-Service ovsdb-server
Get-Service ovs-vswitchd

  3. 그렇지 않으면 flanneld 프로세스가 'Running'인지 확인합니다.

    # Check that the flanneld process exists
Get-Process flanneld

스냅샷 도구 사용

스냅샷 도구를 사용하여 스냅샷 tarball을 잡습니다. 이 tarball에는 노드에서 실행되는 문제 해결 명령어의 결과는 물론 노드의 로그 파일이 포함됩니다.

gkectl diagnose snapshot --scenario system-with-logs --cluster-name [USER_CLUSTER_NAME] --kubeconfig [PATH_TO_KUBECONFIG]

Windows VM 만들기 실패

관리자 클러스터의 사용자 네임스페이스에서 clusterapi-controllers 포드에 있는 vsphere-controller-manager 컨테이너의 로그를 확인합니다.

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME logs clusterapi-controllers-POD_NAME_SUFFIX vsphere-controller-manager

VM 템플릿이 사용자 클러스터 구성 파일에 지정된 것과 동일한 데이터 센터 및 Datastore에 있는지 확인합니다.

Windows VM이 생성되었지만 노드가 올바르게 시작하지 않거나 표시되지 않음

  • C:\var\log\startup.log에 있는 노드의 시작 로그를 확인하여 시작하지 못한 항목이 있는지 확인합니다.

    • flanneld가 실행 중이 아니면 C:\etc\startup\startup-script.ps1에 있는 시작 스크립트를 다시 실행합니다.
    • kubelet이 실행 중이 아니면 C:\var\log에서 kubelet 로그를 확인합니다.
    • kube-proxy가 실행 중이 아니면 C:\var\log에서 kube-proxy 로그를 확인합니다.

  • 시작 스크립트를 실행하기 전에 cloudbase-init이 이미 UserDataPlugin을 실행했는지 확인합니다.

이를 확인하려면 Windows VM에 대한 SSH 연결을 가져와서 다음 명령어를 실행합니다.

ls "HKLM:\\Software\Cloudbase Solutions\Cloudbase-Init\id-ovf\"

출력에 UserDataPlugin: 1이 표시되면 cloudbase-init이 이미 플러그인을 실행했다는 의미이며, 이로 인해 시작 스크립트 실행을 건너뛰게 되고 Windows 노드가 부트스트랩되지 않게 됩니다.

일반적으로 gkectl prepare windows로 생성된 VM 템플릿을 다시 VM으로 변환하고 전원을 켜면 이런 현상이 발생합니다.

이 문제를 해결하려면 gkectl prepare windows를 다시 실행하여 새 VM 템플릿을 만들고 이를 Windows 노드 풀 생성/업그레이드/업데이트에 사용합니다.

로깅 및 모니터링

VMware용 GKE는 Linux 노드 및 포드와 마찬가지로 Windows 노드 및 포드에 대해 로깅 및 모니터링을 지원합니다.

로깅 및 모니터링이 구성되었으면 에이전트가 Windows 노드에 배포됩니다. 이러한 에이전트는 노드의 로그 및 측정항목을 수집, 처리, 내보냅니다.

Windows 로깅 에이전트

Windows 로깅 에이전트는 다음 로그를 수집합니다.

  • 포드 리소스 유형: 시스템 및 사용자 애플리케이션 워크로드

    기본적으로 Windows 사용자 애플리케이션 워크로드 로그가 수집됩니다. 애플리케이션 로그를 사용 중지하려면 다음 안내를 따르세요.

    • fluent-bit-windows-config configmap을 수정하고 애플리케이션 로그를 수집하는 [Input] 항목(첫 번째 [Input] 항목)을 주석 처리합니다. 
      kubectl --kubeconfig KUBECONFIG edit configmap fluent-bit-windows-config -n kube-system
      이 항목 아래에 있는 모든 필드를 주석 처리해야 합니다. 예를 들면 다음과 같습니다. 
      #    [INPUT]
#      # https://docs.fluentbit.io/manual/input/tail
#      Name               tail
#      Tag_Regex          var.log.containers.(?a-z0-9?(?:.a-z0-9?))_(?[^]+)(?.+)-(?[a-z0-9]{64}).log$
#      Tag                k8s_container...
#      Path               C:\var\log\containers\.log
#      Exclude_Path       kube-system.log,gke-connect.log,knative-serving.log,gke-system.log,istio-system.log,monitoring-system.log,config-management-system.log,gatekeeper-system.log,cnrm-system.log
#      DB                 C:\var\log\fluent-bit-k8s-container-application.db
#      Mem_Buf_Limit      30MB
#      Skip_Long_Lines    On
#      Refresh_Interval   10
#      # storage.type       filesystem
#      Buffer_Chunk_Size  512KB
#      Buffer_Max_Size    5M
#      Rotate_Wait        30
#      Ignore_Older       4h
    • rollout restart 명령어를 실행하여 fluent-bit-windows daemonset을 다시 시작합니다. 
      kubectl --kubeconfig KUBECONFIG rollout restart daemonset fluent-bit-windows -n kube-system

  • 노드 리소스 유형: kubelet, kube-proxy, Windows 이벤트 로그

콘솔에서 로그 탐색기를 사용하여 로그에 액세스할 수 있습니다. 자세한 내용은 액세스 로그를 참조하세요.

Windows 모니터링 에이전트

Windows 모니터링 에이전트는 Linux 모니터링 에이전트와 다른 CPU 및 메모리 사용 측정항목 집합을 수집합니다. Windows 노드 및 포드 상태를 모니터링하려면 준비된 대시보드를 사용합니다. 콘솔에서 Monitoring > 대시보드를 선택한 후 모든 대시보드 목록에서 'GKE On-Prem Windows 노드 상태' 및 'GKE On-Prem Windows 포드 상태'를 선택합니다.

Cloud Monitoring이 사용 설정되어 있으면 관리자 클러스터 설치 중에 이러한 대시보드가 자동으로 생성됩니다. 관리자 클러스터가 이미 실행 중이면 이 안내에 따라 다음 json 파일을 사용하여 대시보드를 만듭니다.

Windows 에이전트로 수집된 측정항목 전체 목록을 참조하세요.

Windows 영구 스토리지

온프렘 사용자 클러스터의 기본 StorageClass는 Linux 컨테이너에서만 작동하는 ext4를 파일 시스템 유형으로 사용하므로 영구 스토리지에서 Windows Server 컨테이너로 작업할 때는 StorageClass 객체를 만들고 PersistentVolumeClaim 객체의 storageClassName 필드에 객체 이름을 지정해야 합니다. Windows의 경우 파일 시스템 유형을 ntfs로 설정해야 합니다.

Windows 스토리지 클래스 예시:

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: my-storage-class
provisioner: kubernetes.io/vsphere-volume
parameters:
  datastore: my-datastore
  diskformat: thin
  fstype: ntfs

CSI 프록시는 Windows 노드에 자동으로 배포됩니다. SMB CSI 드라이버와 같이 원하는 Windows CSI 드라이버를 설치 및 사용할 수 있습니다.

Windows 노드의 노드 문제 감지기

노드 문제 감지기 데몬은 Windows 노드에서 사용할 수 있습니다. 버전 1.9로 업그레이드한 경우 노드 문제 감지기가 자동으로 사용 설정됩니다. 노드 문제 감지기는 일반적인 노드 문제를 빠르게 감지하는 데 도움이 됩니다. 노드 문제 감지기는 발생 가능한 문제를 계속 확인하고 노드의 이벤트 및 조건으로 보고합니다. 노드가 오작동하면 kubectl 명령어를 사용하여 해당 이벤트 및 조건을 찾을 수 있습니다.

노드 문제 감지기에 다음 모니터링 구성이 사용 설정되었습니다.

노드의 이벤트 및 조건을 가져오려면 다음 안내를 따르세요.

kubectl --kubeconfig KUBECONFIG describe nodes NODE_NAME

다음과 같이 바꿉니다.

  • KUBECONFIG를 노드가 포함된 클러스터의 kubeconfig 파일 경로로 바꿉니다.
  • NODE_NAME을 노드 이름으로 바꿉니다.

노드 문제 감지기 모니터링에서 생성된 이벤트를 확인하려면 rules 섹션에 지정된 규칙의 reason 필드에서 모니터링 이름을 찾습니다.

노드 문제 감지기 모니터링은 노드에 다음 조건도 생성합니다. 노드 문제 감지기가 노드에서 해당 장애 시나리오를 감지하면 각각 true로 설정됩니다.

  • KubeletUnhealthy
  • KubeProxyUnhealthy
  • ContainerRuntimeUnhealthy

조건 중 하나가 true로 설정되면 노드의 준비 조건이 false가 되어 노드에 새 포드가 예약되지 않습니다.

비정상 조건이 발견되면 노드 문제 감지기는 관련 시스템 서비스를 다시 시작하여 노드를 자동 복구하려고 시도합니다.

노드 문제 감지기 로그는 노드의 C:\var\log\node-problem-detector 폴더에 있습니다. 로깅 및 모니터링을 사용 설정하면 로그가 Cloud Logging으로 내보내지고 로그 탐색기에서 확인할 수 있습니다.

이 필터를 사용하여 로그 탐색기에서 노드 문제 감지기 로그를 가져옵니다.

resource.type="k8s_node"
log_name="projects/PROJECT_NAME/logs/node-problem-detector"

PROJECT_NAME을 프로젝트 이름으로 바꿉니다.

보안 패치 프로세스

지원되는 Anthos 버전에 대한 정기적인 패치 출시 외에도 Anthos팀은 비출시 기간 중에도 지속적으로 더 새로운 Windows 패치 업데이트 대상을 확인하고 참조 결과를 게시합니다. Anthos 패치 출시 기간 사이에 긴급한 보안 패치 업데이트가 필요하면 최신 버전을 사용하여 새 VM 템플릿을 빌드한 후 기존 Windows 노드 풀이 새 템플릿을 사용하도록 순차적 업데이트를 수행할 수 있습니다.

보안 패치 프로세스에는 다음 단계가 포함됩니다.

  • Microsoft가 Windows Server 2019에 대해 새 보안 패치를 출시합니다.
  • Anthos가 최신 보안 패치 버전 대상을 확인하고 대상 확인 결과를 발표합니다.
  • 대상에 포함된 사용자는 다음을 수행합니다.
    • Microsoft에서 최신 패치 버전 다운로드.
    • 여기에 표시된 단계에 따라 이 패치 버전을 사용하여 새 Windows VM 템플릿을 빌드합니다.
    • 다음을 실행하여 새 템플릿을 사용하도록 Windows 노드 풀을 업데이트합니다.
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

  • 새 버전에 Anthos 측면의 변경사항이 필요하면 다음 월간 Anthos 패치 출시를 기다리고 클러스터를 업그레이드해야 합니다.

  • 새 Windows 버전이 Anthos와 전혀 호환되지 않으면 Anthos팀이 해당 버전을 건너뛰고 Microsoft에서 다음 보안 업데이트를 기다립니다.

Active Directory 도메인 조인

Active Directory 도메인에서는 VM 호스트 이름의 길이가 15자 이하여야 합니다. IPAM 모드에서는 VM 호스트 이름이 사용자 클러스터 구성 파일에 설정되기 때문에 길이가 15자 이하인지 확인해야 합니다. 이러한 안내는 Windows VM 템플릿 빌드 중 맞춤설정된 스크립트를 적용하는 추가 단계와 함께 Windows 노드 풀을 만들기 위한 안내를 기반으로 합니다.

Active Domain DNS 서버에 연결할 수 있는지 확인

Active Directory 도메인 서비스(AD DS)는 도메인 이름 시스템(DNS) 이름 확인 서비스를 사용하여 클라이언트가 도메인 컨트롤러를 찾고, 디렉터리 서비스를 호스팅하는 도메인 컨트롤러가 서로 통신할 수 있게 해줍니다.

DNS 서버는 AD DS 역할로 루트 포리스트가 설치되었을 때 생성되었습니다. 모든 Windows VM이 AD 도메인에 조인할 수 있게 하려면 DNS 서버에 연결할 수 있어야 합니다. 사용 중인 DNS 서비스 제공업체의 안내에 따라 DNS 및 방화벽 구성을 지정합니다. 다음 명령어를 실행하여 현재 네트워크의 Windows VM이 AD 도메인 DNS 서버에 연결할 수 있는지 확인할 수 있습니다.

PS C:\> nslookup DOMAIN_NAME DOMAIN_SERVER_IP
Server:  example-1-2-3-4.anthos
Address:  1.2.3.4
Name:    example.org
Address:  1.2.3.4

1단계: 맞춤설정된 스크립트로 Windows VM 템플릿 만들기

  1. Windows 노드가 Active Directory 도메인 조인을 위해 사용자 클러스터에 조인하기 전 맞춤설정된 스크립트를 실행합니다. 이 스크립트를 관리자 워크스테이션의 로컬 경로에 저장합니다. 다음 사항을 참고하세요.

    • Active Directory 도메인 조인을 수행하기 위해 스크립트를 사용자 고유 스크립트로 바꿀 수 있습니다.
    • 관리자 사용자를 사용하는 대신 Active Directory 도메인 조인에 필요한 최소 권한이 포함된 사용자 계정을 사용하는 것이 좋습니다.
    • (선택사항) 이 스크립트에서 비밀번호를 일반 텍스트로 저장하는 것을 방지하려면 VM 템플릿의 파일에 비밀번호를 저장하고, 스크립트가 이 비밀번호 파일에서 읽기를 수행하도록 허용하고, 도메인 조인 후 파일을 삭제합니다.
    $domain = "[DOMAIN_NAME]"
$password = "[PASSWORD]" | ConvertTo-SecureString -asPlainText -Force
$username = "$domain\[USERNAME]"
$credential = New-Object System.Management.Automation.PSCredential($username,$password)
Add-Computer -DomainName $domain -Credential $credential -restart –force

  2. 맞춤설정된 스크립트로 Windows VM 템플릿을 만듭니다.

    gkectl prepare windows --base-vm-template BASE_WINDOWS_VM_TEMPLATE_NAME --bundle-path BUNDLE_PATH --kubeconfig ADMIN_CLUSTER_KUBECONFIG --customized-script CUSTOMIZED_SCRIPT_PATH

BUNDLE_PATH를 번들 경로로 바꿉니다.

2단계: Windows 노드 풀 만들기

2-6단계의 표준 안내를 진행하여 맞춤설정된 Windows VM 템플릿을 사용하여 Windows 노드 풀을 만듭니다.

3단계: Windows 노드에 대한 Active Domain 조인 확인

AD 도메인 컨트롤러 VM에서 다음 명령어를 실행합니다.

PS C:\> Get-ADComputer -Filter 'Name -like "user-host-prefix*"'

DistinguishedName : CN=AD-VM-1,CN=Computers,DC=example,DC=org
DNSHostName       : ad-vm-1.example.org
Enabled           : True
Name              : AD-VM-1
ObjectClass       : computer
ObjectGUID        : b3609717-d24b-4df6-bccb-26ca8e8b9eb0
SamAccountName    : AD-VM-1$
SID               : S-1-5-21-3236879623-1561052741-2808297733-1103

4단계: 그룹 관리형 서비스 계정 구성(선택사항)

Windows 포드 및 컨테이너에 대해 GMSA 구성 안내를 따르세요. 노드가 도메인에 조인된 후 Windows 포드 및 컨테이너에 대해 GMSA를 구성할 수 있습니다.

문제 해결

cloudbase-init의 맞춤설정된 스크립트 실행 로그는 C:\Program Files\Cloudbase Solutions\Cloudbase-Init\log\cloudbase-init.log에 배치됩니다. 로그 파일에서 LocalScriptPlugin을 찾고 관련 로그를 확인합니다. - 새 Windows VM 템플릿을 빌드합니다. - 다음을 실행하여 새 템플릿을 사용하도록 Windows 노드 풀을 업데이트합니다.

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Windows 컨테이너 고려사항

Windows와 Linux 컨테이너 간에 구분되는 차이점은 다음과 같습니다.

  • Windows 컨테이너 이미지 및 호스트/노드 OS 이미지의 버전 호환성
    • Windows Server OS 버전 튜플에는 주, 부, 빌드, 버전의 4개 파트가 포함됩니다.
    • Windows Server 컨테이너 기본 이미지는 호스트 OS 이미지의 버전 튜플의 처음 3개 파트와 일치해야 합니다. 버전은 일치할 필요가 없지만 호스트 및 컨테이너 기본 이미지를 모두 업데이트하는 것이 좋습니다.
    • OS 이미지 버전이 변경될 때마다 사용자가 컨테이너 이미지를 다시 빌드해야 합니다.
  • 권한이 있는 컨테이너 및 호스트 네임스페이스는 지원되지 않습니다.
    • 사용자는 데몬 세트와 같은 컨테이너를 배포하여 노드를 구성/변경할 수 없습니다.

vSphere Windows에서 VMware용 GKE의 제한사항

  • 사용자 클러스터는 하나 이상의 Linux 노드 풀을 포함해야 합니다.

    • Windows 노드 풀만으로는 클러스터를 만들 수 없습니다.
    • Linux 노드 풀은 중요한 부가기능을 실행하기 위해 필요합니다.

  • Windows 노드에 대해서는 Linux 노드보다 1.5배 더 많은 리소스가 예약되기 때문에 Windows에 할당 가능한 리소스가 더 적습니다.

  • Windows 노드를 사용하려면 VMware용 GKE Linux 최소 머신 크기보다 더 큰 최소 머신 크기가 필요할 수 있습니다. 노드 구성요소/서비스 실행에 따른 오버헤드가 더 높기 때문에 Windows 노드는 일반적으로 더 많은 리소스가 필요합니다.

알려진 문제

이 섹션에서는 VMware용 GKE에 사용되는 Windows 노드와 관련된 알려진 문제와 이러한 문제를 방지하거나 복구하는 해결 방법을 설명합니다.

Windows 포드가 외부 IP 주소와 통신할 수 없음

이 문제는 'ExceptionList에서 쿼리하려고 시도 중인 외부 IP 주소를 제외해야 합니다.'라는 Microsoft 문서에 설명되어 있습니다.

문제 해결 방법을 진행하려면 Google Cloud 지원팀에 문의하세요.

Windows 포드를 삭제한 후 Windows 컨테이너가 삭제되지 않음

이 문제는 Docker RemoveContainer가 Windows에서 CreateFile도 호출하려고 시도하는 알려진 문제입니다. 이 문제를 해결하려면 문제가 발생한 Windows 노드에 로그인하고 Restart-Service docker를 실행합니다. 그러면 문제가 해결됩니다. VMware용 GKE 1.9부터 이 문제의 업스트림 수정을 적용하도록 fluent-bit-win 컨테이너 이미지 버전과 Docker 버전이 업데이트되었으므로 더 이상 문제가 발생하지 않습니다. 이 문제가 발생하면 Google Cloud 지원팀에 문의하세요.

IP 주소 충돌이 발생한 Windows 노드

이는 매우 드물게 발생하는 알려진 문제입니다. Windows 노드 풀을 만드는 동안 이 문제가 발생하면 다음 단계를 수행하여 문제를 완화할 수 있습니다.

  • IPAM 모드를 사용하는 경우 vCenter에서 IP 충돌이 발생한 VM을 수동으로 삭제할 수 있습니다. 그러면 IP가 올바르게 할당된 새 VM이 자동으로 생성됩니다. 또는 노드 자동 복구에서 이 문제를 감지할 때까지 기다렸다가 Windows 노드를 다시 만들 수도 있습니다.

  • DHCP 모드를 사용하는 경우 DHCP 서버에 IP 할당 문제가 발생하기 때문에 새로 생성된 VM에서 IP가 다시 중복될 가능성이 높습니다. gkectl update cluster를 실행하여 대기 중인 Windows 노드 풀을 삭제하고 user-cluster.yaml에 다시 추가한 후 gkectl update cluster를 다시 실행하여 노드 풀을 만들면 IP가 올바르게 할당된 새 노드 풀이 생성됩니다.

VM을 재부팅한 후 Windows 노드가 NotReady 상태가 됨

현재 노드 시작 스크립트는 VM이 처음 켜진 경우에만 실행됩니다. 따라서 VM을 재부팅하면 시작 스크립트가 다시 실행되지 않습니다. 이것은 kubelet, kube-proxy 서비스 등을 포함한 일부 Windows 서비스의 실행 중지를 야기할 것입니다. 그러면 노드가 NotReady 상태가 됩니다. Windows Dataplane V2를 사용하는 경우 Dataplane V2 서비스를 다시 시작하기 전에 비활성 네트워크도 정리해야 하며 정리를 위해 스크립트를 실행해야 하므로 문제가 발생할 수 있습니다. 따라서 노드를 다시 만들어야 합니다. 이 문제를 해결하려면 아래 명령어를 실행하여 노드를 삭제하고 컨트롤러에서 자동으로 다시 만들 때까지 기다릴 수 있습니다.

kubectl --kubeconfig USER_KUBECONFIG delete node NODE_NAME

Windows VM 하드웨어 버전이 예상한 버전보다 나을 때 진단 명령어 실패

Windows VM 템플릿에 이전 하드웨어 버전이 사용되는 경우 gkectl diagnose cluster 명령어가 다음 메시지와 함께 실패합니다.

Checking storage...FAILURE
    Reason: 1 storage error(s).
    Unhealthy Resources:
    CSIPrerequisites [VM Hardware]: The current VM hardware versions are lower than vmx-15 which is unexpected. Please contact Anthos support to resolve this issue. Use --detailed=true for the list of VMs.
    Debug Information:
    {
      "NODE_NAME": "vmx-XX",
    }

이 문제를 해결하려면 다음 단계를 수행하세요.

  1. 현재 사용 중인 VM 템플릿의 이름을 바꿉니다.

    다음 단계에서 새 VM 템플릿을 만들기 위해 필요합니다.

  2. Windows 기본 VM 템플릿을 VM으로 변환합니다.

  3. 가상 머신을 최신 하드웨어 버전으로 업그레이드의 단계에 따라 VM의 하드웨어 버전을 업그레이드합니다.

  4. VM을 다시 VM 템플릿으로 변환합니다.

  5. 이전 단계에서 업그레이드된 VM 템플릿을 기본 VM 템플릿으로 사용해서 다음 명령어를 실행하여 새 VM 템플릿을 준비합니다.

    gkectl prepare windows

    새로 생성된 VM 템플릿 이름은 사용자 클러스터 구성 파일의 Windows 노드 풀 osImage 필드 값과 일치해야 합니다. 값이 일치하면 다음 단계를 계속하여 Windows 노드를 다시 만듭니다.

    템플릿 이름이 osImage 필드 값과 일치하지 않으면 새로 생성된 VM 템플릿 이름과 일치하도록 osImage 값을 업데이트하고 다음 명령어를 실행합니다.

    gkectl update cluster

  6. 다음 명령어를 실행하여 Windows 노드를 다시 만듭니다.

    kubectl --kubeconfig USER_KUBECONFIG delete node NODE_NAME

    컨트롤러가 노드를 자동으로 다시 만들 때까지 기다립니다.