Dengan Google Distributed Cloud, 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, di cluster pengguna, kumpulan node yang memiliki node OS Windows Server, pastikan Anda memenuhi persyaratan berikut:
- Cluster admin harus sudah ada sebelum Anda dapat membuat node pool Windows, karena kumpulan node Windows hanya didukung di cluster pengguna.
- Cluster pengguna harus menjalankan setidaknya satu node pool Linux, karena kumpulan node Linux diperlukan untuk membuat node pool Windows.
- Cluster pengguna dengan kumpulan node Windows harus memiliki kolom
enabledataplanev2
yang disetel ketrue
di file konfigurasi cluster pengguna. Tindakan ini akan mengaktifkan Dataplane V2 pada node Linux di cluster tersebut. Secara default, Windows Dataplane V2 diaktifkan untuk kumpulan node Windows bagi 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.
Membuat kumpulan node Windows di cluster pengguna
Langkah 1: Buat Template VM Windows untuk Google Distributed Cloud
Sebelum memulai, pastikan Anda telah membuat cluster admin.
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 OS image 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.
Instal VMware Tools di template VM Windows dasar jika belum diinstal, menggunakan petunjuk VMWare.
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 Google Distributed Cloud
Sebagai bagian dari pembuatan template VM Windows dasar,
gkectl prepare windows
menjalankan Windowssysprep
. 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 kegagalansysprep
tertentu.Jika Anda ingin membuat template VM Windows dasar tanpa menjalankan Windows
sysprep
, sertakan--skip-sysprep
dalam perintahgkectl prepare windows
.Di baris terakhir output perintah, Anda dapat menemukan nama template VM Windows yang dihasilkan. Catat nama ini untuk digunakan di lain waktu. Nama tersebut memiliki format berikut:
Successfully created Anthos Windows VM template "gke-on-prem-windows-server-2019-VERSION"
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 diambil dari registry Microsoft saat menarik image. Untuk mengirim lapisan dasar, ikuti 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 tanda ini.
Opsi 2: Jika Anda perlu mengirim image lapisan dasar Windows secara manual ke registry pribadi:
- Sebelum mencoba langkah-langkah ini, gunakan komputer Windows dengan Docker yang terinstal, dan akses ke
gcr.io
. Anda hanya dapat menarik image container Windows ke komputer Windows. - Jalankan
docker login
untuk melakukan autentikasi ke registry pribadi Anda. Upload image Windows Container bersama lapisan dasarnya ke registry pribadi, 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 Docker
daemon.json
Anda guna memungkinkan pengiriman lapisan asing ke registry pribadi Anda:
{ "allow-nondistributable-artifacts": ["PRIVATE_REGISTRY_NAME"] }
- Download image Windows Container yang diperlukan ke komputer Windows lokal Anda, lalu beri tag dan kirim 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 daftar URL untuk membuat kumpulan node Windows
Jika cluster Anda berada di belakang server proxy, tambahkan URL ini ke daftar server proxy yang diizinkan selain alamat lain yang diperlukan oleh Google Distributed Cloud.
# 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
Langkah 4: Tambahkan kumpulan node Windows ke file konfigurasi cluster pengguna
Dataplane V2 harus diaktifkan di cluster pengguna untuk menggunakan kumpulan node Windows. Tambahkan baris berikut ke file konfigurasi cluster pengguna Anda untuk mengaktifkan Dataplane V2:
enableDataplaneV2: true
Tambahkan kumpulan node Windows ke bagian
nodePools
di file konfigurasi cluster pengguna. Setidaknya satu kumpulan node Linux diperlukan selain kumpulan node Windows Anda. Tetapkan kolomosImage
danosImageType
untuk membuat node pool 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 di file konfigurasi cluster pengguna.osImageType
: Menentukan jenis gambar OS menjadiwindows
.
# user-cluster.yaml nodePools: - name: windows-nodepool-1 cpus: 8 memoryMB: 16384 replicas: 3 bootDiskSizeGB: 100 osImage: WINDOWS_VM_TEMPLATE_NAME osImageType: windows
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, atau yang akan 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 di 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
. - Mengelola kumpulan node Windows sama seperti mengelola kumpulan node Linux. Lihat 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 sedang berjalan
Pastikan node Windows Anda telah dibuat dan
Ready
.kubectl --kubeconfig USER_KUBECONFIG get nodes
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 di-taint 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 pada node Windows Server, file manifes Anda harus menyertakan bagian nodeSelector
ini:
nodeSelector: kubernetes.io/os: windows
Setelah nodeSelector
dikonfigurasi, webhook akses masuk yang berjalan di cluster akan memeriksa beban kerja baru untuk mengetahui keberadaan pemilih node Windows ini dan, jika ditemukan, toleransi berikut akan diterapkan pada beban kerja yang memungkinkannya berjalan pada 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, lalu 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!
Mengupgrade cluster pengguna dengan node pool Windows
Proses upgrade untuk cluster pengguna dengan kumpulan node Windows serupa dengan proses upgrade cluster pengguna khusus Linux, kecuali bahwa Anda harus membuat template VM Windows dari template VM dasar sebelum melakukan upgrade.
Anda dapat memperbarui versi build patch 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
Perbarui kolom osImage
kumpulan node di file konfigurasi dengan nama template VM baru.
Jalankan perintah di bawah 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 itu adalah:
kubectl get secret windows-node-password -n [USER_CLUSTER_NAME] --kubeconfig admin-kubeconfig.yaml -o jsonpath={.data.*} | base64 -d
Anda juga bisa mendapatkan sandi melalui antarmuka pengguna vCenter. Buka VM tempat Anda ingin login, lalu Anda dapat menemukan sandi di properti vApp password
dari VM tersebut.
Setelah memiliki nama pengguna dan sandi, Anda dapat mengakses VM Windows menggunakan salah satu pendekatan berikut:
Menggunakan Protokol Desktop Jarak Jauh
Anda dapat mengakses VM Windows menggunakan klien RDP karena RDP telah diaktifkan selama template build.
Menggunakan SSH
Untuk menjalankan ssh ke VM Windows:
ssh Administrator@[VM_IP_ADDRESS]
Ikuti perintah untuk mengetikkan sandi agar terhubung ke VM Anda.
Mentransfer file dari dan ke VM Windows Anda
Anda dapat mentransfer file dari dan ke VM Windows dengan perintah scp
:
Upload file ke VM Windows:
scp [LOCAL_FILE_PATH] Administrator@[VM_IP_ADDRESS]:/[REMOTE_FILE_PATH]
Unduh file dari VM Windows:
scp Administrator@[VM_IP_ADDRESS]:/[REMOTE_FILE_PATH] [LOCAL_FILE_PATH]
Ketik sandi saat diminta.
Atau, Anda juga dapat mentransfer file menggunakan Cloud Storage atau RDP, seperti yang dijelaskan dalam Mentransfer file ke VM Windows.
Memperbarui konfigurasi Windows Server Anda
Containerd dan Windows Dataplane V2 sekarang tersedia secara umum mulai versi 1.11.
Docker dan Flannel untuk node 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 harus 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.
Memastikan layanan kubelet, kube-proxy, dan CNI berjalan di VM Windows
Hubungkan ke VM dengan mengikuti langkah-langkah di sini dan jalankan perintah berikut, bergantung pada penyiapan Anda:
Untuk semua konfigurasi, jalankan perintah berikut:
# Check that kubelet and kube-proxy services have status 'Running' Get-Service kubelet Get-Service kube-proxy
Jika cluster Anda dikonfigurasi dengan
windowsDataplaneV2
ditetapkan ketrue
, pastikan 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
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 di 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.
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 terletak di
C:\etc\startup\startup-script.ps1
- Jika kubelet tidak berjalan, periksa log kubelet pada bagian
C:\var\log
. - Jika kube-proxy tidak berjalan, periksa log kube-proxy di bagian
C:\var\log
.
- Jika flanneld tidak berjalan, coba jalankan kembali skrip startup yang terletak di
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 karena mengonversi kembali template VM yang dihasilkan oleh gkectl prepare windows
ke VM dan mengaktifkannya.
Untuk mengatasi hal ini, buat template VM baru dengan menjalankan gkectl prepare windows
lagi dan gunakan untuk membuat/mengupgrade/mengupdate kumpulan node Windows.
Logging dan Pemantauan
Google Distributed Cloud 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 sebagai komentar (item[Input]
pertama): Pastikan untuk menjadikan semua kolom sebagai komentar di item ini. Contoh: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?))_(? [^]+)(? .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.+)-(? [a-z0-9]{64}).log$ # Tag k8s_container. . . # Path C:\var\log\containers\ - Jalankan perintah
rollout restart
untuk memulai ulang daemonsetfluent-bit-windows
:kubectl --kubeconfig KUBECONFIG rollout restart daemonset fluent-bit-windows -n kube-system
- Edit configmap
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 dengan agen pemantauan Linux. Untuk memantau status node 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:
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
dari objek PersistentVolumeClaim
, karena StorageClass
default di cluster pengguna lokal menggunakan ext4
sebagai jenis sistem file, yang hanya berfungsi untuk container 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 Windows CSI pilihan Anda, seperti driver CSI SMB.
Pendeteksi Masalah Node pada node Windows
Daemon Pendeteksi Masalah Node tersedia di node Windows. Jika Anda telah mengupgrade ke versi 1.9, Node Problem Detector akan diaktifkan secara otomatis. Pendeteksi Masalah Node membantu deteksi masalah node umum dengan cepat. Node Problem Detector 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 Detektor Masalah Node:
- 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 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 Node Problem Detector, cari nama monitor di kolom reason
dari aturan yang ditentukan di bagian rules
.
Monitor Node Problem Detector juga menghasilkan kondisi berikut pada node. Masing-masing disetel ke true
jika Detektor Masalah Node mendeteksi skenario kegagalan yang sesuai pada node.
KubeletUnhealthy
KubeProxyUnhealthy
ContainerRuntimeUnhealthy
Setiap kali salah satu kondisi ditetapkan ke true
, kondisi Ready node akan menjadi false
, yang mencegah Pod baru dijadwalkan pada node.
Saat ditemukan kondisi yang tidak responsif, Node Problem Detector akan mencoba memperbaiki node secara otomatis dengan memulai ulang layanan sistem yang relevan.
Log Node Problem Detector berada di folder C:\var\log\node-problem-detector
node. Jika logging dan pemantauan diaktifkan, log akan diekspor ke Cloud Logging dan Anda dapat melihatnya di Logs Explorer.
Gunakan filter ini untuk mendapatkan log Node Problem Detector 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 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 mendapatkan 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 sisi 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 memerlukan panjang nama host VM <= 15 karakter. Untuk mode IPAM, karena nama host VM disetel 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.
Verifikasi bahwa server DNS Domain Aktif dapat dijangkau
Active Directory Domain Services (AD DS) menggunakan layanan resolusi nama Domain Name System (DNS) untuk memungkinkan klien menemukan pengontrol domain dan untuk pengontrol domain yang menghosting layanan direktori untuk berkomunikasi satu sama lain.
Server DNS dibuat saat peran AD DS menginstal forest root. Agar dapat bergabung dengan domain AD, VM Windows apa pun 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
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. Perlu diingat 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) Untuk menghindari penyimpanan sandi sebagai cleartext dalam skrip ini, tempatkan sandi di dalam file pada template VM, biarkan skrip membaca dari file sandi tersebut, lalu hapus file setelah domain bergabung.
$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
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
Di 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: Mengonfigurasikan GMSA untuk Pod dan container Windows. Anda dapat mengonfigurasi GMSA untuk pod dan container 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 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 penampung Windows
Beberapa perbedaan penting antara container Windows dan Linux adalah:
- Kompatibilitas versi image container Windows dan image OS host/node.
- Tuple versi OS Windows Server memiliki empat bagian: utama, minor, build, dan revisi.
- Image dasar penampung server Windows harus cocok dengan tiga bagian pertama dari tuple versi OS image host. Revisi tidak perlu 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 Google Distributed Cloud di Windows vSphere
Cluster pengguna harus berisi setidaknya satu node pool Linux.
- Anda tidak dapat membuat cluster yang hanya berisi satu node pool Windows
- Kumpulan node Linux diperlukan untuk menjalankan add-on penting.
Karena resource yang dicadangkan untuk node Windows 1,5 kali lebih banyak daripada node Linux, resource yang dapat dialokasikan untuk Windows akan lebih rendah.
Penggunaan node Windows mungkin memerlukan ukuran mesin minimum yang lebih besar daripada ukuran mesin minimum Google Distributed Cloud 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 Google Distributed Cloud, beserta solusi untuk menghindari atau pulih dari masalah ini.
Pod Windows tidak dapat berkomunikasi dengan alamat IP eksternal
Masalah ini dijelaskan dalam dokumentasi Microsoft, yang menyatakan "Anda perlu mengecualikan IP eksternal yang Anda coba kueri dari ExceptionList."
Hubungi Dukungan Google Cloud untuk mencari solusi sementara.
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 memiliki masalah, jalankan Restart-Service docker
, dan masalah tersebut akan dimitigasi. Dari Google Distributed Cloud 1.9, versi image container yang fluent-bit-win dan versi Docker telah diupdate untuk mengambil perbaikan upstream untuk masalah ini. 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 Anda mengalami hal ini selama pembuatan node pool Windows, Anda dapat memitigasinya dengan mengikuti langkah-langkah berikut:
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 perbaikan otomatis node mendeteksi masalah ini dan membuat ulang node Windows.
Jika Anda menggunakan mode DHCP, VM yang baru dibuat mungkin akan kembali memiliki IP duplikat karena server DHCP mengalami masalah untuk alokasi IP. Anda dapat menghapus kumpulan node Windows yang tertunda dengan menjalankan
gkectl update cluster
, lalu menambahkannya kembali ke user-cluster.yaml, menjalankangkectl 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 dinyalakan, sehingga jika Anda memulai ulang VM, skrip startup tidak akan berjalan lagi. Perintah ini akan menyebabkan beberapa layanan Windows berhenti berjalan, termasuk layanan kubelet, kube-proxy, dan sebagainya. Hal ini menyebabkan node memiliki status NotReady
. Jika Anda menggunakan Windows Dataplane V2, jaringan basi 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 ulang 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:
Ganti nama template VM yang sedang digunakan.
Langkah ini diperlukan agar dapat membuat template VM baru pada langkah berikutnya.
Konversikan template VM dasar Windows ke VM.
Ikuti langkah-langkah dalam Mengupgrade virtual machine ke versi hardware terbaru untuk mengupgrade versi hardware VM.
Konversikan kembali VM ke template VM.
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 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 nilaiosImage
agar cocok dengan nama template VM yang dihasilkan baru dan jalankan perintah berikut:gkectl update cluster
Buat ulang node Windows dengan menjalankan perintah berikut:
kubectl --kubeconfig USER_KUBECONFIG delete node NODE_NAME
Tunggu hingga pengontrol otomatis membuat ulang node.