Panduan pengguna untuk kumpulan node Windows Server OS

Version 1.16 

• Versi terbaru
• Versi 1.16
• Versi sebelumnya (tidak didukung)

Dengan GKE di VMware, Anda dapat membuat kumpulan node node OS Windows Server. Cluster pengguna yang menjalankan kumpulan node OS Windows Server juga dapat menjalankan kumpulan node yang berisi node menggunakan Ubuntu atau Container-Optimized OS.

Persyaratan untuk kumpulan node OS Windows Server

Semua node dalam kumpulan node harus menggunakan sistem operasi yang sama, yang ditunjukkan oleh parameter osImageType.

Sebelum membuat node yang memiliki node OS Windows Server di cluster pengguna, pastikan Anda memenuhi persyaratan berikut:

• Cluster admin harus sudah ada sebelum Anda dapat membuat kumpulan node Windows, karena kumpulan node Windows hanya didukung di cluster pengguna.
• Cluster pengguna harus menjalankan setidaknya satu kumpulan node Linux, karena kumpulan node Linux diperlukan untuk membuat kumpulan node Windows.
• Cluster pengguna dengan kumpulan node Windows harus memiliki kolom enabledataplanev2 yang disetel ke true di file konfigurasi cluster pengguna. Tindakan ini mengaktifkan Dataplane V2 pada node Linux di cluster tersebut.

• Secara default, Windows Dataplane V2 diaktifkan untuk kumpulan node Windows untuk cluster pengguna baru.

• Anda telah mendownload ISO Windows Server 2019 dari Microsoft untuk membuat template VM khusus untuk kumpulan node Windows. Tag bahasa/wilayah untuk ISO harus en-US.

• Lingkungan vSphere Anda harus vSphere 6.7, Update 3 atau yang lebih baru.

Catatan: IPv6 tidak didukung.

Catatan: Kolom enableDataplaneV2 harus ditetapkan ke true.

Membuat kumpulan node Windows di cluster pengguna

Catatan: Image container Windows tidak tersedia sebagai paket dengan lapisan dasar, yang juga dikenal sebagai lapisan asing, yang berasal dari registry Microsoft. Hal ini karena image lapisan dasar dari registry Microsoft tidak dapat didistribusikan ulang. Dengan demikian, Anda harus mengambil image lapisan dasar dari Google Container Registry (GCR).

Langkah 1: Buat Template VM Windows untuk GKE di VMware

Sebelum memulai, pastikan Anda telah membuat cluster admin.

Catatan: Untuk workstation admin, Anda harus mengizinkan workstation admin dan host jump mengakses IP host ESXi tempat VM Windows dijalankan, sehingga Anda dapat menjalankan gkectl prepare windows.

1. Buat template VM Windows dasar dari ISO Windows Server 2019.

   • Jenis adaptor jaringan awal untuk VM Windows yang akan menginstal ISO Windows Server 2019 harus E1000E.
   • Ikuti langkah-langkah berikut: Membuat template VMware vSphere untuk Windows Server 2019.
   • Catat sandi awal yang ditetapkan saat Anda menjalankan Windows ISO penginstal, untuk menggunakannya di masa mendatang.
   • Pastikan Anda menggunakan versi patch terbaru yang memenuhi syarat untuk Windows Server 2019. Lihat catatan rilis kami untuk mengetahui versi image OS Windows terbaru yang memenuhi syarat untuk versi rilis Anthos tertentu. Lihat Proses patch keamanan.
   • Anda tidak dapat memasang perangkat apa pun yang menggunakan pengontrol IDE ke template VM dasar.

2. Instal VMware Tools pada template VM Windows dasar jika belum diinstal, menggunakan petunjuk VMWare.

3. Buat template VM Windows:

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

   Ganti kode berikut:

   • ADMIN_CLUSTER_KUBECONFIG: Jalur ke file kubeconfig cluster admin.

   • BASE_WINDOWS_VM_TEMPLATE: Jalur ke template VM Windows dasar

   • BUNDLE: Jalur ke file paket GKE pada VMware

   Sebagai bagian dari pembuatan template VM Windows dasar, gkectl prepare windows menjalankan Windows sysprep. Tindakan ini akan menggeneralisasi template VM dan membersihkan setelan jaringan untuk VM, sehingga membantu menghindari konflik alamat IP saat VM di-clone dari template yang sama. Namun, sysprep Windows berjalan sebagai kotak tertutup sehingga sulit untuk menangani kegagalan sysprep tertentu.

   Jika Anda ingin membuat template VM Windows dasar tanpa menjalankan Windows sysprep, sertakan --skip-sysprep dalam perintah gkectl prepare windows.

4. Di baris terakhir output perintah, Anda dapat menemukan nama template VM Windows yang dihasilkan. Catat nama untuk digunakan di lain waktu. Nama tersebut memiliki format berikut:

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

Catatan: Template VM yang dibuat akan digunakan sebagai OS image untuk kumpulan node Windows dan disiapkan untuk memicu skrip saat startup pertama, yang diperlukan agar node berfungsi dengan benar. Oleh karena itu, kami menyarankan agar Anda tidak melakukan manupulasi pada template VM ini (Misalnya, konversikan ke VM, lakukan beberapa tindakan dan konversi kembali ke template VM).

Langkah 2: Upload image container Windows ke registry pribadi

Abaikan langkah ini jika Anda tidak menggunakan registry pribadi.

Anda dapat mengotomatiskan upload image container Windows ke registry pribadi menggunakan container di workstation admin Linux. Namun, containerd tidak dapat mendorong lapisan dasar image container Windows, yang berarti lapisan dasar harus ditarik dari registry Microsoft saat menarik image. Untuk mendorong lapisan dasar, ikuti langkah-langkah Opsi 2.

Opsi 1: Jika Anda tidak perlu mengirim image lapisan dasar Windows secara manual ke registry pribadi:

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

Ganti ADMIN_CLUSTER_CONFIG dengan jalur ke file konfigurasi cluster admin.

Tanda --upload-windows-images menentukan bahwa image Container Windows akan dikirim. Hanya image container Linux yang akan dikirim ke registry pribadi tanpa menentukan flag ini.

Opsi 2: Jika Anda perlu menerapkan image lapisan dasar Windows secara manual ke registry pribadi:

• Gunakan komputer Windows dengan Docker terinstal, dan dengan akses ke gcr.io, sebelum mencoba langkah-langkah ini. Anda hanya dapat menarik image container Windows ke mesin Windows.
• Jalankan docker login untuk melakukan autentikasi ke registry pribadi Anda.

• Upload image Container Windows bersama lapisan dasarnya ke registry pribadi Anda, dengan mengikuti langkah-langkah berikut:

  • Buka file daemon.json Docker di komputer Windows Anda:

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

  • Tambahkan baris berikut untuk mengonfigurasi file daemon.json Docker Anda guna memungkinkan pengiriman lapisan asing ke registry pribadi Anda:

  {
    "allow-nondistributable-artifacts": ["PRIVATE_REGISTRY_NAME"]
  }
  

  • Download image Container Windows yang diperlukan ke komputer Windows lokal Anda, lalu beri tag dan kirim image tersebut ke registry pribadi Anda. Perubahan yang Anda buat pada file konfigurasi Docker daemon.json berarti bahwa lapisan dasar dapat dikirim ke registry pribadi. Untuk menyelesaikan tugas ini, jalankan perintah berikut:

# 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

Langkah 3: (Diperlukan jika menggunakan proxy) Mengizinkan URL untuk membuat kumpulan node Windows

Jika cluster Anda berada di belakang server proxy, tambahkan URL berikut ke daftar server proxy yang diizinkan selain alamat lain yang diperlukan GKE di VMware.

# 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

Catatan: Lihat daftar lengkap URL yang digunakan oleh Windows Server.

Langkah 4: Tambahkan kumpulan node Windows ke file konfigurasi cluster pengguna

1. Dataplane V2 harus diaktifkan di cluster pengguna Anda untuk menggunakan kumpulan node Windows. Tambahkan baris berikut ke file konfigurasi cluster pengguna Anda untuk mengaktifkan Dataplane V2:

   enableDataplaneV2: true
   

2. Tambahkan kumpulan node Windows ke bagian nodePools pada file konfigurasi cluster pengguna. Setidaknya satu kumpulan node Linux diperlukan selain kumpulan node Windows Anda. Tetapkan kolom osImage dan osImageType untuk membuat kumpulan node Windows:

• osImage: Ganti WINDOWS_VM_TEMPLATE_NAME dengan nama template VM Windows yang sudah disiapkan di langkah 1, yang harus berada di datastore vCenter yang sama dengan yang ditentukan dalam file konfigurasi cluster pengguna.
• osImageType: Menentukan jenis OS image menjadi windows.

# user-cluster.yaml

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

Catatan: Node Windows Server memerlukan lebih banyak resource daripada node Linux. Kami merekomendasikan nilai CPU dan memori yang ditunjukkan dalam contoh sebelumnya.

Langkah 5: Membuat node pool Windows

Sebelum membuat kumpulan node Windows, jalankan daftar validator preflight untuk Windows. Lewati langkah ini jika Anda sudah memiliki cluster pengguna. - (Opsional) Jalankan pemeriksaan preflight yang cepat dan lambat, yang membuat VM uji untuk Windows dan memvalidasi template VM Windows:

gkectl check-config --config USER_CLUSTER_CONFIG --kubeconfig ADMIN_CLUSTER_KUBECONFIG

• Perintah ini dimaksudkan untuk dijalankan sebelum membuat cluster pengguna. Jika Anda sudah memiliki cluster pengguna, pemeriksaan tertentu mungkin akan gagal. Misalnya, alamat IP dalam file hostconfig.yaml mungkin sudah digunakan oleh node yang ada di cluster pengguna Anda.
• Meskipun tidak direkomendasikan, Anda dapat melewati pemeriksaan preflight Windows dengan flag --skip-validation-windows.
• Pengelolaan kumpulan node Windows sama seperti pengelolaan kumpulan node Linux. Baca artikel Mengelola kumpulan node. Perintah untuk membuat, mengupdate, dan mengupgrade cluster serta node pool juga tetap sama dan tercantum di sini.

# 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

Langkah 6: Validasi node Windows yang sedang berjalan

1. Pastikan node Windows Anda telah dibuat dan Ready.

   kubectl --kubeconfig USER_KUBECONFIG get nodes
   

2. Lakukan diagnosis pada cluster pengguna untuk memeriksa apakah cluster tersebut responsif.

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

Men-deploy Pod Windows

Node Windows Server dirusak dengan key-value pair ini: node.kubernetes.io/os=windows:NoSchedule.

Taint ini memastikan bahwa penjadwal GKE tidak mencoba menjalankan container Linux pada node Windows Server. Untuk menjadwalkan penampung Windows Server di node Windows Server, file manifes Anda harus menyertakan bagian nodeSelector ini:

nodeSelector:
    kubernetes.io/os: windows

Dengan mengonfigurasi nodeSelector, webhook penerimaan yang berjalan di cluster akan memeriksa beban kerja baru untuk mengetahui keberadaan pemilih node Windows ini dan, jika ditemukan, akan menerapkan toleransi berikut pada beban kerja yang memungkinkannya berjalan di node Windows Server yang tertampung:

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

Langkah 1: Buat file deployment Internet Information Services (IIS)

Berikut ini contoh konfigurasi yang men-deploy image IIS resmi Microsoft ke satu Pod.

Buat file IIS bernama iis.yaml dengan konten berikut:

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]

Langkah 2: Buat deployment dan ekspos melalui layanan

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

Langkah 3: Memvalidasi Pod

Periksa status Pod menggunakan kubectl.

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pods

Tunggu hingga output yang ditampilkan menunjukkan bahwa Pod memiliki status "Running".

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

Dapatkan status layanan, dan tunggu hingga kolom IP eksternal terisi.

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG  get service iis

Output yang diharapkan:

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

Anda dapat menggunakan browser untuk membuka http://EXTERNAL_IP guna melihat halaman web IIS!

Catatan: Perlu diingat bahwa image container Windows harus di-build di Windows Server 2019 agar dapat berjalan di kumpulan node Windows. Lihat Mencocokkan versi host container dengan versi image container.

Mengupgrade cluster pengguna dengan kumpulan node Windows

Proses upgrade cluster pengguna dengan kumpulan node Windows mirip dengan proses upgrade cluster pengguna khusus Linux, bedanya Anda harus membuat template VM Windows dari template VM dasar sebelum mengupgrade.

Peringatan: Template VM dasar harus berupa template VM Windows Server 2019 kosong. Jangan gunakan kembali template VM Windows yang sudah ada yang digunakan oleh kumpulan node saat ini untuk membuat template VM baru.

Anda dapat memperbarui versi patch build dari template VM dasar selama upgrade dengan mendownload versi patch Windows Server 2019 yang lebih baru dari Microsoft sebagai patch keamanan. Lihat Proses patch keamanan.

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

Catatan: Perintah ini mencetak nama template VM yang baru disiapkan.

Perbarui kolom osImage kumpulan node di file konfigurasi dengan nama template VM baru. Jalankan perintah di bawah ini untuk mengupgrade cluster pengguna:

gkectl upgrade cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Ganti kode berikut:

• ADMIN_CLUSTER_KUBECONFIG dengan jalur file kubeconfig admin Anda
• ADMIN_CLUSTER_CONFIG dengan jalur file konfigurasi cluster admin Anda

Mengakses node Windows

Cara standar untuk mengakses node Windows adalah dengan nama pengguna dan sandi, yang berbeda dengan node Linux, yang biasanya diakses melalui pasangan kunci SSH untuk autentikasi.

Untuk node Windows di vSphere, nama penggunanya adalah Administrator. Sandi dibuat oleh clusterapi-controller dan disimpan dalam rahasia windows-node-password di namespace pengguna cluster admin. Perintah untuk mendapatkan {i>password<i} dari rahasia tersebut adalah:

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

Anda juga dapat menggunakan {i>password<i} menggunakan antarmuka pengguna vCenter. Buka VM tempat Anda ingin login, lalu temukan sandi di properti vApp password pada VM tersebut.

Setelah memiliki nama pengguna dan sandi, Anda dapat mengakses VM Windows menggunakan salah satu pendekatan berikut:

Menggunakan Protokol Desktop Jarak Jauh

Catatan: akses RDP (Remote Desktop Protocol) diaktifkan selama build template VM Windows di gkectl prepare windows. Anda juga harus memastikan aturan firewall mengizinkan akses RDP di port TCP 3389.

Anda dapat mengakses VM Windows menggunakan klien RDP karena RDP telah diaktifkan selama pembuatan template.

Menggunakan SSH

Catatan: server SSH diinstal selama build template VM Windows di gkectl prepare windows. Oleh karena itu, Anda dapat menggunakan ssh ke VM Windows menggunakan server SSH tersebut.

Untuk melakukan SSH ke VM Windows:

ssh Administrator@[VM_IP_ADDRESS]

Ikuti perintah untuk mengetik sandi agar terhubung ke VM.

Mentransfer file dari dan ke VM Windows Anda

Anda dapat mentransfer file dari dan ke VM Windows dengan perintah scp:

Unggah file ke VM Windows:

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

Download file dari VM Windows:

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

Ketik sandi jika diminta.

Atau, Anda juga dapat mentransfer file dengan menggunakan Cloud Storage atau RDP, seperti yang dijelaskan dalam Mentransfer file ke VM Windows.

Mengupdate konfigurasi Windows Server Anda

Containerd dan Windows Dataplane V2 sekarang tersedia secara umum mulai versi 1.11.

Node Docker dan Flannel untuk Windows tidak akan digunakan lagi dalam rilis berikutnya. Sebaiknya perbarui konfigurasi Anda sekarang, jika berlaku, untuk menggunakan containerd dan Windows Dataplane V2 sebagai gantinya. Lihat Mengupdate konfigurasi Windows Server.

Tidak dapat menjalankan SSH/RDP ke VM Windows

Periksa apakah VM memiliki koneksi jaringan dengan menjalankan Test-NetConnection di konsol web vCenter Anda.

Hasilnya akan berisi PingSucceeded: true jika ada koneksi jaringan. Jika VM tidak memiliki koneksi jaringan, periksa adaptor jaringan yang digunakan untuk VM ini. Pastikan jaringan mengizinkan koneksi masuk ke VM dari workstation tempat Anda ingin menjalankan SSH/RDP.

Pastikan layanan kubelet, kube-proxy, dan CNI berjalan di VM Windows

Hubungkan ke VM dengan mengikuti langkah-langkah di sini, lalu jalankan perintah berikut, bergantung pada penyiapan Anda:

1. Untuk semua konfigurasi, jalankan perintah berikut:

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

2. Jika cluster Anda dikonfigurasi dengan windowsDataplaneV2 yang disetel ke true, periksa apakah layanan antrea-agent, ovsdb-server, dan 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. Jika tidak, periksa apakah proses flanneld 'Berjalan':

   # Check that the flanneld process exists
   Get-Process flanneld
   

Menggunakan alat snapshot

Gunakan alat snapshot untuk mengambil tarball snapshot. Tarball ini berisi file log pada node serta output untuk perintah pemecahan masalah yang berjalan pada node.

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

Pembuatan VM Windows gagal

Periksa log dari container vsphere-controller-manager dalam Pod clusterapi-controllers di namespace pengguna cluster admin.

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

Pastikan template VM Anda berada di pusat data dan datastore yang sama seperti yang ditentukan dalam file konfigurasi cluster pengguna Anda.

VM Windows dibuat, tetapi node gagal dimulai dengan benar atau muncul

• Periksa log startup pada node yang terletak di C:\var\log\startup.log untuk melihat apakah ada yang gagal dimulai.

  • Jika flanneld tidak berjalan, coba jalankan kembali skrip startup yang berada di C:\etc\startup\startup-script.ps1
  • Jika kubelet tidak berjalan, periksa log kubelet pada C:\var\log.
  • Jika kube-proxy tidak berjalan, periksa log kube-proxy pada C:\var\log.

• Periksa apakah cloudbase-init telah menjalankan UserDataPlugin sebelum menjalankan skrip startup.

Untuk memeriksanya, dapatkan koneksi SSH ke VM Windows dan jalankan perintah berikut:

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

Jika Anda menemukan UserDataPlugin: 1 dalam output, artinya cloudbase-init telah menjalankan plugin tersebut, yang akan menyebabkan eksekusi skrip startup dilewati, dan node Windows tidak akan di-bootstrap sama sekali.

Hal ini biasanya disebabkan oleh konversi template VM yang dihasilkan oleh gkectl prepare windows kembali ke VM dan mengaktifkannya.

Untuk mengatasi masalah ini, buat template VM baru dengan menjalankan gkectl prepare windows lagi, lalu gunakan untuk membuat/mengupgrade/mengupdate kumpulan node Windows.

Logging dan Pemantauan

GKE di VMware mendukung logging dan pemantauan untuk node dan Pod Windows, seperti halnya untuk node dan Pod Linux.

Saat logging dan pemantauan dikonfigurasi, agen di-deploy pada node Windows. Agen ini mengumpulkan, memproses, dan mengekspor log dan metrik node.

Agen logging Windows

Agen logging Windows mengumpulkan log berikut:

• Jenis resource pod: beban kerja aplikasi pengguna dan sistem.

  Perhatikan bahwa log beban kerja aplikasi pengguna Windows dikumpulkan secara default. Untuk menonaktifkan log aplikasi:

  • Edit configmap fluent-bit-windows-config dan jadikan item [Input] yang mengumpulkan log aplikasi (item [Input] pertama) sebagai komentar:

    kubectl --kubeconfig KUBECONFIG edit configmap fluent-bit-windows-config -n kube-system
    

    Pastikan untuk menjadikan semua kolom pada item ini sebagai komentar. Contoh:

    #    [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
    

  • Jalankan perintah rollout restart untuk memulai ulang daemonset fluent-bit-windows:

    kubectl --kubeconfig KUBECONFIG rollout restart daemonset fluent-bit-windows -n kube-system
    

• Jenis resource node: kubelet, kube-proxy, dan log peristiwa Windows

Anda dapat mengakses log menggunakan Logs Explorer di konsol. Lihat Mengakses log untuk informasi selengkapnya.

Agen pemantauan Windows

Agen pemantauan Windows mengumpulkan kumpulan metrik penggunaan CPU dan memori yang berbeda dari agen pemantauan Linux. Untuk memantau status Pod dan Pod Windows, gunakan dasbor yang sudah disiapkan. Dari konsol, pilih Monitoring > Dashboards, lalu pilih "GKE on-prem Windows node status" dan "GKE on-prem Windows pod status" dari daftar All Dashboards.

Dasbor ini otomatis dibuat selama penginstalan cluster admin jika Cloud Monitoring diaktifkan. Jika Anda sudah menjalankan cluster admin, ikuti petunjuk ini untuk membuat dasbor ini, menggunakan file json berikut:

• windows_pod_status.json
• windows_node_status.json

Lihat daftar lengkap metrik yang dikumpulkan oleh agen Windows.

Penyimpanan persisten Windows

Saat menggunakan penampung Windows Server dengan penyimpanan persisten, Anda harus membuat objek StorageClass dan menentukan nama objek tersebut di kolom storageClassName untuk objek PersistentVolumeClaim, karena StorageClass default di cluster pengguna lokal menggunakan ext4 sebagai jenis sistem file, yang hanya berfungsi untuk penampung Linux. Untuk Windows, kita perlu menetapkan jenis sistem file ke ntfs.

Contoh kelas penyimpanan 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

Proxy CSI di-deploy secara otomatis ke node Windows. Anda dapat menginstal dan menggunakan driver CSI Windows pilihan Anda, seperti driver CSI SMB.

Pendeteksi Masalah Node pada node Windows

Daemon Node Problem Detector tersedia di node Windows. Jika Anda telah mengupgrade ke versi 1.9, Node Problem Detector akan diaktifkan secara otomatis. Pendeteksi Masalah Node membantu mendeteksi beberapa masalah node umum dengan cepat. Pendeteksi Masalah Node terus memeriksa kemungkinan masalah dan melaporkannya sebagai peristiwa dan kondisi pada node. Jika node mengalami gangguan, Anda dapat menggunakan perintah kubectl untuk menemukan peristiwa dan kondisi yang sesuai.

Konfigurasi monitor berikut diaktifkan untuk Node Problem Detector:

• windows-health-checker-kubelet
• windows-health-checker-kubeproxy
• windows-health-checker-docker
• windows-health-checker-containerd
• windows-defender-monitor

Untuk mendapatkan peristiwa dan kondisi pada sebuah node:

kubectl --kubeconfig KUBECONFIG describe nodes NODE_NAME

Ganti:

• KUBECONFIG dengan jalur file kubeconfig untuk cluster yang berisi node.
• NODE_NAME dengan nama node.

Untuk mengidentifikasi peristiwa yang dihasilkan oleh monitor Detektor Masalah Node, cari nama monitor di kolom reason dari aturan yang ditentukan di bagian rules.

Monitor Detektor Masalah Node juga menghasilkan kondisi berikut pada node. Masing-masing disetel ke true jika Pendeteksi Masalah Node mendeteksi skenario kegagalan yang sesuai pada node.

• KubeletUnhealthy
• KubeProxyUnhealthy
• ContainerRuntimeUnhealthy

Setiap kali salah satu kondisi ditetapkan ke true, kondisi Siap node akan menjadi false, yang mencegah Pod baru dijadwalkan pada node.

Saat kondisi yang tidak responsif ditemukan, Pendeteksi Masalah Node akan mencoba memperbaiki node tersebut secara otomatis dengan memulai ulang layanan sistem yang relevan.

Catatan: Untuk container, Pendeteksi Masalah Node hanya memunculkan masalah ke server API dan tidak mencoba memperbaiki node secara otomatis dengan memulai ulang layanan dalam container.

Log Pendeteksi Masalah Node berada di folder C:\var\log\node-problem-detector node. Jika logging dan pemantauan diaktifkan, log diekspor ke Cloud Logging dan Anda dapat melihatnya di Logs Explorer.

Gunakan filter ini untuk mendapatkan log Pendeteksi Masalah Node di Logs Explorer:

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

Ganti PROJECT_NAME dengan nama project.

Proses patch keamanan

Selain rilis patch reguler untuk versi Anthos yang didukung, tim Anthos juga terus memenuhi syarat update patch Windows yang lebih baru selama jangka waktu non-rilis, dan memublikasikan hasilnya sebagai referensi Anda. Jika update patch keamanan mendesak diperlukan di antara rilis patch Anthos, Anda dapat mem-build template VM baru menggunakan versi terbaru, lalu melakukan update berkelanjutan untuk kumpulan node Windows yang ada agar dapat menggunakan template baru.

Proses patch keamanan mencakup langkah-langkah berikut:

• Microsoft merilis patch keamanan baru untuk Windows Server 2019.
• Anthos memenuhi syarat untuk versi patch keamanan terbaru dan mengumumkan hasil kualifikasi.
• Jika memenuhi syarat, pengguna akan:
  • Download versi patch terbaru dari Microsoft
  • Buat template VM Windows baru menggunakan versi patch ini dengan mengikuti langkah-langkah di sini.
  • Update kumpulan node Windows untuk menggunakan template baru dengan menjalankan:

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

• Jika versi baru memerlukan perubahan dari sistem Anthos, Anda harus menunggu rilis patch Anthos bulanan berikutnya dan mengupgrade cluster.

• Jika versi Windows baru tidak kompatibel dengan Anthos sama sekali, tim Anthos akan melewati versi tersebut dan menunggu update keamanan berikutnya dari Microsoft.

Penggabungan domain Active Directory

Penggabungan domain Active Directory mengharuskan panjang nama host VM menjadi <= 15 karakter. Untuk mode IPAM, karena nama host VM ditetapkan di file konfigurasi cluster pengguna, Anda harus memastikan panjangnya <= 15 karakter. Petunjuk ini didasarkan pada petunjuk untuk membuat kumpulan node Windows, dengan langkah tambahan berupa penyediaan skrip yang disesuaikan selama build template VM Windows.

Memverifikasi bahwa server DNS Domain Aktif dapat dijangkau

Layanan Domain Direktori Aktif (AD DS) menggunakan layanan resolusi nama Domain Name System (DNS) agar klien dapat menemukan pengontrol domain dan pengontrol domain yang menghosting layanan direktori untuk berkomunikasi satu sama lain.

Server DNS dibuat saat peran AD DS menginstal hutan root. Agar semua VM Windows dapat bergabung dengan domain AD, VM harus dapat menjangkau server DNS. Konfigurasikan konfigurasi DNS dan firewall dengan mengikuti panduan penyedia layanan DNS yang Anda gunakan. Anda dapat memverifikasi apakah VM Windows di jaringan saat ini dapat menghubungi server DNS domain AD dengan menjalankan perintah ini:

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

Langkah 1: Buat template VM Windows dengan skrip yang disesuaikan

1. Jalankan skrip yang disesuaikan sebelum node Windows bergabung dengan cluster pengguna untuk penggabungan domain Active Directory. Simpan skrip ini ke jalur lokal di workstation admin Anda. Perhatikan bahwa:

   • Anda dapat mengganti skrip dengan skrip Anda sendiri untuk melakukan penggabungan domain Active Directory.
   • Sebaiknya gunakan akun pengguna dengan izin minimum yang diperlukan untuk penggabungan domain Active Directory, bukan menggunakan pengguna Administrator.
   • (Opsional) Agar sandi tidak disimpan sebagai cleartext dalam skrip ini, tempatkan sandi dalam file di template VM, biarkan skrip membaca dari file sandi tersebut, lalu hapus file setelah domain digabungkan.

   $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. Buat template VM Windows dengan skrip yang disesuaikan:

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

Ganti BUNDLE_PATH dengan jalur ke paket.

Langkah 2: Membuat node pool Windows

Lanjutkan dengan petunjuk standar di Langkah 2-6 untuk membuat kumpulan node Windows menggunakan template VM Windows yang disesuaikan.

Langkah 3: Verifikasi penggabungan Domain Aktif untuk node Windows

Pada VM pengontrol domain AD, jalankan perintah berikut:

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

Langkah 4: Konfigurasikan Akun Layanan yang Dikelola Grup (opsional)

Ikuti petunjuk berikut: Mengonfigurasi GMSA untuk Pod dan container Windows. Anda dapat mengonfigurasi GMSA untuk pod dan penampung Windows setelah node bergabung dengan domain.

Pemecahan masalah

Log untuk eksekusi skrip yang disesuaikan pada cloudbase-init terletak di C:\Program Files\Cloudbase Solutions\Cloudbase-Init\log\cloudbase-init.log. Cari LocalScriptPlugin di file log, dan periksa log yang terkait. - Membuat template VM Windows baru. - Update kumpulan node Windows untuk menggunakan template baru dengan menjalankan:

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Pertimbangan untuk container Windows

Beberapa perbedaan antara container Windows dan Linux adalah:

• Kompatibilitas versi image container Windows dan image OS host/node.
  • Tuple versi Windows Server OS memiliki empat bagian: besar, minor, build, dan revisi.
  • Image dasar penampung server Windows harus cocok dengan tiga bagian pertama tuple versi image OS host. Revisi tidak harus cocok, meskipun sebaiknya Anda memperbarui image dasar host dan container.
  • Pengguna harus membuat ulang image container mereka setiap kali versi OS image berubah
• Container dengan hak istimewa dan namespace host tidak didukung.
  • Pengguna tidak dapat mengonfigurasi/mengubah node dengan men-deploy container, seperti Daemonset.

Batasan untuk GKE di VMware pada Windows vSphere

• Cluster pengguna harus berisi setidaknya satu kumpulan node Linux.

  • Anda tidak dapat membuat cluster hanya dengan kumpulan node Windows
  • Kumpulan node Linux diperlukan untuk menjalankan add-on penting.

• Karena resource yang dicadangkan 1,5 kali lebih banyak untuk node Windows dibandingkan node Linux, resource yang dapat dialokasikan untuk Windows menjadi lebih rendah.

• Penggunaan node Windows mungkin memerlukan ukuran mesin minimum yang lebih besar daripada ukuran mesin minimum GKE di VMware Linux. Node Windows biasanya memerlukan lebih banyak resource karena overhead yang lebih tinggi dalam menjalankan komponen/layanan node.

Masalah Umum

Bagian ini mencantumkan masalah umum pada node Windows yang digunakan dengan GKE di VMware, beserta solusi untuk menghindari atau pulih dari masalah tersebut.

Pod Windows tidak dapat berkomunikasi dengan alamat IP eksternal

Catatan: Masalah ini hanya berlaku untuk Flannel (dengan WindowsDataplaneV2 dinonaktifkan). Masalah ini tidak terjadi saat WindowsDataplaneV2 diaktifkan.

Masalah ini dijelaskan dalam dokumentasi Microsoft, yang menyatakan "Anda perlu mengecualikan IP eksternal yang Anda coba kueri dari ExceptionList".

Hubungi Dukungan Google Cloud untuk mendapatkan solusi solusi.

Container Windows tidak dibersihkan setelah menghapus Pod Windows

Ini adalah masalah umum, saat Docker RemoveContainer juga mencoba memanggil CreateFile di Windows. Sebagai solusinya, login ke node Windows yang mengalami masalah, jalankan Restart-Service docker, dan masalah tersebut harus dimitigasi. Mulai GKE di VMware 1.9, versi image container dan versi docker yang lancar bit-win telah diupdate guna menerapkan perbaikan upstream untuk masalah ini. Seharusnya, versi ini tidak akan direproduksi lagi. Jika Anda mengalami masalah ini, hubungi Dukungan Google Cloud.

Node Windows yang memiliki konflik alamat IP

Ini adalah masalah umum yang sangat jarang terjadi. Jika mengalami hal ini selama pembuatan kumpulan node Windows, Anda dapat menguranginya dengan mengikuti langkah-langkah:

• Jika menggunakan mode IPAM, Anda dapat secara manual menghapus VM yang memiliki konflik IP dari vCenter. VM baru akan dibuat secara otomatis yang seharusnya memiliki alokasi IP yang benar. Atau, Anda dapat menunggu hingga node auto Repair mendeteksi masalah ini dan membuat ulang node Windows.

• Jika Anda menggunakan mode DHCP, VM yang baru dibuat kemungkinan memiliki IP duplikat lagi karena server DHCP mengalami masalah alokasi IP. Anda dapat menghapus kumpulan node Windows yang tertunda dengan menjalankan gkectl update cluster, lalu menambahkannya kembali ke user-cluster.yaml, menjalankan gkectl update cluster lagi untuk membuatnya. Kumpulan node yang baru dibuat harus memiliki alokasi IP yang benar.

Node Windows menjadi NotReady setelah memulai ulang VM

Saat ini, skrip startup node hanya berjalan saat VM pertama kali dihidupkan, sehingga jika Anda memulai ulang VM, skrip startup tidak akan berjalan lagi. Hal ini akan menyebabkan beberapa layanan Windows berhenti berjalan, termasuk layanan kubelet, kube-proxy, dan sebagainya. Hal ini menyebabkan node berada dalam status NotReady. Jika Anda menggunakan Windows Dataplane V2, jaringan lama juga perlu dibersihkan sebelum layanan Dataplane V2 dapat dimulai ulang, dan akan memerlukan menjalankan skrip untuk pembersihan, yang dapat menyebabkan kerumitan. Oleh karena itu, buat ulang node. Sebagai solusinya, Anda dapat menghapus node dengan menjalankan perintah di bawah dan menunggu pengontrol untuk membuatnya kembali secara otomatis.

kubectl --kubeconfig USER_KUBECONFIG delete node NODE_NAME

Perintah diagnosis gagal saat versi hardware VM Windows lebih rendah dari yang diharapkan

Jika template VM Windows menggunakan versi hardware lama, perintah gkectl diagnose cluster akan gagal dengan pesan berikut:

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",
    }

Untuk memperbaiki masalah ini, ikuti langkah berikut:

1. Ganti nama template VM yang saat ini digunakan.

   Langkah ini diperlukan agar dapat membuat template VM baru pada langkah selanjutnya.

2. Konversikan template VM dasar Windows menjadi VM.

3. Ikuti langkah-langkah di bagian Mengupgrade virtual machine ke versi hardware terbaru untuk mengupgrade versi hardware VM.

4. Konversikan kembali VM ke template VM.

5. Jalankan perintah berikut untuk menyiapkan template VM baru, menggunakan template VM yang telah diupgrade dari langkah sebelumnya sebagai template VM dasar.

   gkectl prepare windows
   

   Nama template VM yang dihasilkan yang baru harus cocok dengan nilai kolom osImage kumpulan node Windows di file konfigurasi cluster pengguna. Jika nilainya cocok, lanjutkan ke langkah berikutnya untuk membuat ulang node Windows.

   Jika nama template tidak cocok dengan nilai kolom osImage, perbarui nilai osImage agar cocok dengan nama template VM baru yang dihasilkan dan jalankan perintah berikut:

   gkectl update cluster
   

6. Buat ulang node Windows dengan menjalankan perintah berikut:

   kubectl --kubeconfig USER_KUBECONFIG delete node NODE_NAME
   

   Tunggu hingga pengontrol otomatis membuat ulang node.