Google Distributed Cloud untuk masalah umum bare metal

Halaman ini mencantumkan semua masalah umum untuk Google Distributed Cloud (khusus software) untuk bare metal, yang sebelumnya dikenal sebagai Google Distributed Cloud Virtual. Untuk memfilter masalah umum menurut kategori atau versi produk, pilih filter Anda dari menu drop-down berikut.

Pilih versi Google Distributed Cloud Anda:

1,29 1,28 1.16 1.15 1,14 1.13 1.12 1,11 1.10

Pilih kategori masalah Anda:

Configuration Penginstalan Upgrade dan update Operasi Logging dan pemantauan Networking Keamanan Reset/Penghapusan Runtime VM di GDC

Atau, telusuri masalah Anda:

Kategori	Versi yang diidentifikasi	Masalah dan solusi
Penginstalan, Upgrade, dan update	1.28.0 hingga 1.28.600 dan 1.29.0 hingga 1.29.200	Kegagalan pemeriksaan preflight mesin untuk setelan check_inotify_max_user_instances dan check_inotify_max_user_watches Selama penginstalan atau upgrade cluster, pemeriksaan preflight mesin yang terkait dengan setelan kernel fs.inotify mungkin gagal. Jika Anda terpengaruh oleh masalah ini, log pemeriksaan preflight mesin berisi error seperti berikut: Minimum kernel setting required for fs.inotify.max_user_instances is 8192. Current fs.inotify.max_user_instances value is 128. Please run "echo "fs.inotify.max_user_instances=8192" | sudo tee --append /etc/sysctl.conf" to set the correct value. Masalah ini terjadi karena nilai fs.inotify max_user_instances dan max_user_watches salah dibaca dari bidang kontrol dan host bootstrap, bukan dari mesin node yang dimaksud. Solusi: Untuk mengatasi masalah ini, sesuaikan fs.inotify.max_user_instances dan fs.inotify.max_user_watches ke nilai yang direkomendasikan di semua bidang kontrol dan mesin bootstrap: echo fs.inotify.max_user_watches=524288 | sudo tee --append /etc/sysctl.conf echo fs.inotify.max_user_instances=8192 | sudo tee --append /etc/sysctl.conf sudo sysctl -p Setelah operasi penginstalan atau upgrade selesai, nilai ini dapat dikembalikan, jika perlu.
Konfigurasi, Penginstalan, Upgrade dan update, Jaringan, Keamanan	1,15, 1,16, 1,28, 1,29	Penginstalan dan upgrade cluster gagal saat ipam-controller-manager diperlukan Penginstalan dan upgrade cluster akan gagal jika ipam-controller-manager diperlukan dan cluster Anda berjalan di Red Hat Enterprise Linux (RHEL) 8.9 atau yang lebih tinggi (bergantung pada perubahan RHEL upstream) dengan SELinux berjalan dalam mode penerapan. Hal ini berlaku khususnya jika versi container-selinux lebih tinggi dari 2.225.0. Cluster Anda memerlukan ipam-controller-manager dalam salah satu situasi berikut: Cluster Anda dikonfigurasi untuk jaringan dual-stack IPv4/IPv6 Cluster Anda dikonfigurasi dengan clusterNetwork.flatIPv4 ditetapkan ke true Cluster Anda dikonfigurasi dengan anotasi preview.baremetal.cluster.gke.io/multi-networking: enable Penginstalan dan upgrade cluster tidak akan berhasil jika ipam-controller-manager diinstal. Solusi Tetapkan konteks default untuk direktori /etc/kubernetes pada setiap node bidang kontrol ke jenis etc_t: semanage fcontext /etc/kubernetes --add -t etc_t semanage fcontext /etc/kubernetes/controller-manager.conf --add -t etc_t restorecon -R /etc/kubernetes Perintah ini mengembalikan perubahan container-selinux pada direktori /etc/kubernetes. Setelah cluster diupgrade ke versi yang telah diperbaiki, urungkan perubahan konteks file sebelumnya di setiap node bidang kontrol: semanage fcontext /etc/kubernetes --delete -t etc_t semanage fcontext /etc/kubernetes/controller-manager.conf --delete -t etc_t restorecon -R /etc/kubernetes
Upgrade	1.28.0 - 1.28.500	Upgrade cluster gagal dengan error pemeriksaan keterjangkauan Google Cloud Jika Anda menggunakan bmctl untuk mengupgrade cluster, upgrade mungkin gagal dengan error GCP reachability check failed meskipun URL target dapat dijangkau dari workstation admin. Masalah ini disebabkan oleh bug pada bmctl versi 1.28.0 hingga 1.28.500. Solusi: Sebelum Anda menjalankan perintah bmctl upgrade, tetapkan variabel lingkungan GOOGLE_APPLICATION_CREDENTIALS agar mengarah ke file kunci akun layanan yang valid: export GOOGLE_APPLICATION_CREDENTIALS=JSON_KEY_PATH bmctl upgrade cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG Menetapkan Kredensial Default Aplikasi (ADC) dengan cara ini memastikan bahwa bmctl memiliki kredensial yang diperlukan untuk mengakses endpoint Google API.
Konfigurasi, Penginstalan, Upgrade dan update, Jaringan, Keamanan	1,15, 1,16, 1,28, 1,29	Penginstalan dan upgrade cluster gagal saat ipam-controller-manager diperlukan Penginstalan dan upgrade cluster akan gagal jika ipam-controller-manager diperlukan dan cluster Anda berjalan di Red Hat Enterprise Linux (RHEL) 8.9 atau yang lebih tinggi (bergantung pada perubahan RHEL upstream) dengan SELinux berjalan dalam mode penerapan. Hal ini berlaku khususnya jika versi container-selinux lebih tinggi dari 2.225.0. Cluster Anda memerlukan ipam-controller-manager dalam salah satu situasi berikut: Cluster Anda dikonfigurasi untuk jaringan dual-stack IPv4/IPv6 Cluster Anda dikonfigurasi dengan clusterNetwork.flatIPv4 ditetapkan ke true Cluster Anda dikonfigurasi dengan anotasi preview.baremetal.cluster.gke.io/multi-networking: enable Penginstalan dan upgrade cluster tidak akan berhasil jika ipam-controller-manager diinstal. Solusi Tetapkan konteks default untuk direktori /etc/kubernetes pada setiap node bidang kontrol ke jenis etc_t: semanage fcontext /etc/kubernetes --add -t etc_t semanage fcontext /etc/kubernetes/controller-manager.conf --add -t etc_t restorecon -R /etc/kubernetes Perintah ini mengembalikan perubahan container-selinux pada direktori /etc/kubernetes. Setelah cluster diupgrade ke versi yang telah diperbaiki, urungkan perubahan konteks file sebelumnya di setiap node bidang kontrol: semanage fcontext /etc/kubernetes --delete -t etc_t semanage fcontext /etc/kubernetes/controller-manager.conf --delete -t etc_t restorecon -R /etc/kubernetes
Upgrade	1.28.0 - 1.28.500	Upgrade cluster gagal dengan error pemeriksaan keterjangkauan Google Cloud Jika Anda menggunakan bmctl untuk mengupgrade cluster, upgrade mungkin gagal dengan error GCP reachability check failed meskipun URL target dapat dijangkau dari workstation admin. Masalah ini disebabkan oleh bug pada bmctl versi 1.28.0 hingga 1.28.500. Solusi: Sebelum Anda menjalankan perintah bmctl upgrade, tetapkan variabel lingkungan GOOGLE_APPLICATION_CREDENTIALS agar mengarah ke file kunci akun layanan yang valid: export GOOGLE_APPLICATION_CREDENTIALS=JSON_KEY_PATH bmctl upgrade cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG Menetapkan Kredensial Default Aplikasi (ADC) dengan cara ini memastikan bahwa bmctl memiliki kredensial yang diperlukan untuk mengakses endpoint Google API.
Penginstalan	1,29	Masalah Otorisasi Biner untuk cluster dengan kumpulan node load balancer terpisah Penginstalan cluster dengan kumpulan node load balancer terpisah mungkin akan gagal jika Anda mengaktifkan kebijakan Otorisasi Biner selama pembuatan cluster. Masalah ini terjadi karena pembuatan Pod GKE Identity Service dan Pod penting lainnya diblokir oleh webhook Otorisasi Biner. Untuk mengetahui apakah Anda terpengaruh oleh masalah ini, selesaikan langkah-langkah berikut: Identifikasi Pod mana yang gagal: kubectl get pods \ -n anthos-identity-service \ --kubeconfig CLUSTER_KUBECONFIG Menjelaskan Pod yang gagal. Cari pesan berikut di output: admission webhook "binaryauthorization.googleapis.com" denied the request: failed to post request to endpoint: Post "https://binaryauthorization.googleapis.com/internal/projects/PROJECT_NUMBER/policy/locations/LOCATION/clusters/CLUSTER_NAME:admissionReview": oauth2/google: status code 400: {"error":"invalid_target","error_description":"The target service indicated by the \"audience\" parameters is invalid. This might either be because the pool or provider is disabled or deleted or because it doesn't exist."} Jika Anda melihat pesan sebelumnya, artinya cluster Anda mengalami masalah. Solusi: Untuk mengatasi masalah ini, selesaikan langkah-langkah berikut: Batalkan operasi pembuatan cluster. Hapus blok spec.binaryAuthorization dari file konfigurasi cluster. Buat cluster dengan Otorisasi Biner dinonaktifkan. Setelah penginstalan selesai, aktifkan kebijakan Otorisasi Biner untuk cluster yang ada.
Konfigurasi, Penginstalan	1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28, 1.29	Memasang titik dengan SELinux diaktifkan menyebabkan masalah Jika telah mengaktifkan SELinux dan memasang sistem file ke direktori terkait Kubernetes, Anda mungkin mengalami masalah seperti kegagalan pembuatan cluster, file tidak dapat dibaca, atau masalah izin. Untuk mengetahui apakah Anda terpengaruh oleh masalah ini, jalankan perintah berikut: ls -Z /var/lib/containerd . Jika Anda melihat system_u:object_r:unlabeled_t:s0 di tempat label lain, seperti system_u:object_r:container_var_lib_t:s0, berarti Anda terpengaruh. Solusi: Jika Anda baru-baru ini memasang sistem file ke direktori, pastikan direktori tersebut sudah sesuai dengan konfigurasi SELinux Anda. Anda juga harus menjalankan perintah berikut pada setiap mesin sebelum menjalankan bmctl create cluster: restorecon -R -v /var restorecon -R -v /etc Perbaikan satu kali ini akan tetap ada setelah reboot, tetapi diperlukan setiap kali node baru dengan titik pemasangan yang sama ditambahkan. Untuk mempelajari lebih lanjut, lihat Memasang Sistem File dalam dokumentasi Red Hat.
Reset/Penghapusan	1.29.0	Reset cluster pengguna gagal menghapus namespace Saat menjalankan bmctl reset cluster -c ${USER_CLUSTER}, setelah semua tugas terkait selesai, perintah tersebut akan gagal menghapus namespace cluster pengguna. Namespace cluster pengguna terjebak dalam status Terminating. Pada akhirnya, waktu tunggu cluster habis dan menampilkan error. Solusi: Untuk menghapus namespace dan menyelesaikan reset cluster pengguna, gunakan langkah-langkah berikut: Hapus Pod metrics-server dari cluster admin: kubectl delete pods -l k8s-app=metrics-server \ -n gke-managed-metrics-server --kubeconfig ADMIN_KUBECONFIG_PATH Dalam situasi ini, Pod metrics-server akan mencegah penghapusan namespace cluster. Di cluster admin, hapus paksa resolver di namespace cluster pengguna: kubectl get ns ${USER_CLUSTER_NAMESPACE} -ojson | \ jq '.spec.finalizers = []' | \ kubectl replace --raw "/api/v1/namespaces/${USER_CLUSTER_NAMESPACE}/finalize" -f - Setelah finaler dihapus, namespace cluster akan dihapus dan reset cluster selesai.
Konfigurasi, Penginstalan, Keamanan	1.16.0 hingga 1.16.7 dan 1.28.0 hingga 1.28.400	Deployment Otorisasi Biner tidak memiliki nodeSelector Jika telah mengaktifkan Otorisasi Biner untuk GKE pada Bare Metal dan menggunakan versi 1.16.0 hingga 1.16.7 atau 1.28.0 hingga 1.28.400, Anda mungkin mengalami masalah saat menjadwalkan Pod untuk fitur tersebut. Dalam versi ini, Deployment Otorisasi Biner tidak memiliki nodeSelector, sehingga Pod untuk fitur tersebut dapat dijadwalkan pada node pekerja, bukan node bidang kontrol. Perilaku ini tidak menyebabkan kegagalan apa pun, tetapi tidak dimaksudkan. Solusi: Untuk semua cluster yang terpengaruh, selesaikan langkah-langkah berikut: Buka file Deployment Otorisasi Biner: kubectl edit -n binauthz-system deployment binauthz-module-deployment Tambahkan nodeSelector berikut di blok spec.template.spec: nodeSelector: node-role.kubernetes.io/control-plane: "" Simpan perubahan. Setelah perubahan disimpan, Pod hanya akan di-deploy ulang ke node bidang kontrol. Perbaikan ini harus diterapkan setelah setiap upgrade.
Upgrade dan update	1.28.0, 1.28.100, 1.28.200, 1.28.300	Terjadi error saat mengupgrade cluster ke 1.28.0-1.28.300 Mengupgrade cluster yang dibuat sebelum versi 1.11.0 ke versi 1.28.0-1.28.300 dapat menyebabkan Pod deployer pengontrol siklus proses memasuki status error selama upgrade. Jika ini terjadi, log Pod deployer pengontrol siklus proses akan mendapatkan pesan error yang mirip dengan berikut: "inventorymachines.baremetal.cluster.gke.io\" is invalid: status.storedVersions[0]: Invalid value: \"v1alpha1\": must appear in spec.versions Solusi: Masalah ini telah diperbaiki dalam versi 1.28.400. Upgrade ke versi 1.28.400 atau yang lebih baru untuk menyelesaikan masalah. Jika Anda tidak dapat melakukan upgrade, jalankan perintah berikut untuk menyelesaikan masalah ini: kubectl patch customresourcedefinitions/nodepoolclaims.baremetal.cluster.gke.io \ --subresource status --type json \ --patch='[{ "op": "replace", "path": "/status/storedVersions", "value": ["v1"]}]' kubectl patch customresourcedefinitions/machineclasses.baremetal.cluster.gke.io \ --subresource status --type json \ --patch='[{ "op": "replace", "path": "/status/storedVersions", "value": ["v1"]}]' kubectl patch customresourcedefinitions/inventorymachines.baremetal.cluster.gke.io \ --subresource status --type json \ --patch='[{ "op": "replace", "path": "/status/storedVersions", "value": ["v1"]}]'
Logging dan pemantauan	1.13.7, 1.14, 1.15, 1.16, 1.28	Project ID yang ditampilkan di Logs Explorer salah Terkadang log cluster atau container diberi tag dengan project ID yang berbeda di resource.labels.project_id pada Logs Explorer. Hal ini dapat terjadi jika cluster dikonfigurasi untuk menggunakan kemampuan observasi PROJECT_ONE, yang ditetapkan di kolom clusterOperations.projectID dalam konfigurasi cluster. Namun, cloudOperationsServiceAccountKeyPath dalam konfigurasi memiliki kunci akun layanan dari project PROJECT_TWO. Dalam kasus semacam itu, semua log dirutekan ke PROJECT_ONE, tetapi resource.labels.project_id diberi label sebagai PROJECT_TWO. Solusi: Gunakan salah satu opsi berikut untuk menyelesaikan masalah: Gunakan akun layanan dari project tujuan yang sama. Ubah project_id di file JSON kunci akun layanan ke project saat ini. Ubah project_id langsung di filter log dari Logs Explorer.
Networking	1.29.0	Penurunan performa untuk cluster yang menggunakan load balancing yang dipaketkan dengan BGP Untuk cluster versi 1.29.0 yang menggunakan load balancing paket dengan BGP, performa load balancing dapat menurun karena jumlah total Layanan berjenis LoadBalancer mendekati 2.000. Saat performa menurun, Layanan yang baru dibuat memerlukan waktu lama untuk terhubung atau tidak dapat dihubungkan oleh klien. Layanan yang ada akan terus berfungsi, tetapi tidak menangani mode kegagalan, seperti hilangnya node load balancer secara efektif. Masalah Service ini terjadi saat Deployment ang-controller-manager dihentikan karena memori habis. Jika cluster Anda terpengaruh oleh masalah ini, Layanan di cluster tidak dapat dijangkau dan tidak responsif, dan Deployment ang-controller-manager berada dalam CrashLoopBackOff. Respons saat mencantumkan Deployment ang-controller-manager serupa dengan berikut: ang-controller-manager-79cdd97b88-9b2rd 0/1 CrashLoopBackOff 639 (59s ago) 2d10h 10.250.210.152 vm-bgplb-centos4-n1-02 <none> <none> ang-controller-manager-79cdd97b88-r6tcl 0/1 CrashLoopBackOff 620 (4m6s ago) 2d10h 10.250.202.2 vm-bgplb-centos4-n1-11 <none> <none> Solusi Sebagai solusinya, Anda dapat meningkatkan batas resource memori Deployment ang-controller-manager sebesar 100 MiB dan menghapus batas CPU: kubectl edit deployment ang-controller-manager -n kube-system --kubeconfig ADMIN_KUBECONFIG Setelah berhasil melakukan perubahan dan menutup editor, Anda akan melihat output berikut: deployment.apps/ang-controller-manager edited Untuk memastikan bahwa perubahan telah diterapkan, periksa manifes ang-controller-manager di cluster: kubectl get deployment ang-controller-manager \ -n kube-system \ -o custom-columns=NAME:.metadata.name,CPU_LIMITS:.spec.template.spec.containers[*].resources.limits.cpu,MEMORY_LIMITS:.spec.template.spec.containers[*].resources.limits.memory \ --kubeconfig ADMIN_KUBECONFIG Responsnya akan terlihat seperti berikut: NAME CPU_LIMITS MEMORY_LIMITS ang-controller-manager <none> 400Mi
Penginstalan, Upgrade, Pencadangan, dan Pemulihan	1.28.0, 1.28.100	Masalah konektivitas gcr.io endpoint Container Registry dapat memblokir operasi cluster Beberapa operasi cluster untuk cluster admin membuat cluster bootstrap. Sebelum membuat cluster bootstrap, bmctl melakukan pemeriksaan keterjangkauan Google Cloud dari workstation admin. Pemeriksaan ini mungkin gagal karena masalah konektivitas dengan endpoint Container Registry, gcr.io, dan Anda mungkin melihat pesan error seperti berikut: system checks failed for bootstrap machine: GCP reachability check failed: failed to reach url https://gcr.io: Get "https://cloud.google.com/artifact-registry/": net/http: request canceled (Client.Timeout exceeded while awaiting headers) Solusi Untuk mengatasi masalah ini, coba lagi operasi tersebut dengan tanda --ignore-validation-errors.
Networking	1,15, 1,16	GKE Dataplane V2 tidak kompatibel dengan beberapa driver penyimpanan GKE pada cluster Bare Metal menggunakan GKE Dataplane V2, yang tidak kompatibel dengan beberapa penyedia penyimpanan. Anda mungkin mengalami masalah dengan Pod atau volume NFS yang macet. Hal ini sangat mungkin terjadi jika Anda memiliki workload yang menggunakan volume ReadWriteMany yang didukung oleh driver penyimpanan yang rentan terhadap masalah ini: Robin.io Portworx (sharedv4 volume layanan) csi-nfs Ini bukan merupakan daftar lengkap. Solusi Perbaikan untuk masalah ini tersedia untuk versi Ubuntu berikut: 20.04 LTS: Gunakan image kernel 5.4.0 yang lebih baru dari linux-image-5.4.0-166-generic 22.04 LTS: Gunakan image kernel 5.15.0 yang lebih baru dari linux-image-5.15.0-88-generic atau gunakan kernel HWE 6.5. Jika Anda tidak menggunakan salah satu versi ini, hubungi Dukungan Google.
Logging dan pemantauan	1,15, 1,16, 1,28	kube-state-metrics OOM dalam cluster besar Anda mungkin mendapati bahwa Pod kube-state-metrics atau gke-metrics-agent yang ada di node yang sama dengan kube-state-metrics kehabisan memori (OOM). Hal ini dapat terjadi dalam cluster yang memiliki lebih dari 50 node atau dengan banyak objek Kubernetes. Solusi Untuk mengatasi masalah ini, perbarui definisi resource kustom stackdriver untuk menggunakan gateway fitur ksmNodePodMetricsOnly. Fitur ini memastikan bahwa hanya sejumlah kecil metrik penting yang terekspos. Untuk menggunakan solusi ini, selesaikan langkah-langkah berikut: Periksa definisi resource kustom stackdriver untuk fitur yang tersedia: kubectl -n kube-system get crd stackdrivers.addons.gke.io -o yaml | grep ksmNodePodMetricsOnly Perbarui definisi resource kustom stackdriver untuk mengaktifkan ksmNodePodMetricsOnly: kind:stackdriver spec: featureGates: ksmNodePodMetricsOnly: true
Penginstalan	1.28.0-1.28.200	Pemeriksaan preflight gagal pada RHEL 9.2 karena iptables tidak ada Saat menginstal cluster pada sistem operasi Red Hat Enterprise Linux (RHEL) 9.2, Anda mungkin mengalami kegagalan karena paket iptables tidak ada. Kegagalan terjadi selama pemeriksaan preflight dan memicu pesan error yang mirip dengan berikut: 'check_package_availability_pass': "The following packages are not available: ['iptables']" RHEL 9.2 berada dalam Pratinjau untuk Google Distributed Cloud versi 1.28. Solusi Abaikan error pemeriksaan preflight dengan menetapkan spec.bypassPreflightCheck ke true pada resource Cluster Anda.
Operasi	1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16	Failover MetalLB lambat pada skala tinggi Saat MetalLB menangani layanan dalam jumlah besar (lebih dari 10.000), failover dapat memerlukan waktu lebih dari satu jam. Hal ini terjadi karena MetalLB menggunakan antrean dengan kapasitas terbatas yang, jika dalam skala tinggi, dapat memerlukan waktu beberapa saat untuk sampai ke layanan yang perlu di-gagalkan. Solusi Upgrade cluster Anda ke versi 1.28 atau yang lebih baru. Jika Anda tidak dapat melakukan upgrade, pengeditan layanan secara manual (misalnya, menambahkan anotasi) akan menyebabkan layanan failover lebih cepat.
Operasi	1.16.0-1.16.6, 1.28.0-1.28.200	Variabel lingkungan harus ditetapkan di workstation admin jika proxy diaktifkan bmctl check cluster dapat gagal karena kegagalan proxy jika Anda tidak memiliki variabel lingkungan HTTPS_PROXY dan NO_PROXY yang ditentukan di workstation admin. Perintah bmctl melaporkan pesan error tentang kegagalan memanggil beberapa layanan Google, seperti contoh berikut: [2024-01-29 23:49:03+0000] error validating cluster config: 2 errors occurred: * GKERegister check failed: 2 errors occurred: * Get "https://gkehub.googleapis.com/v1beta1/projects/baremetal-runqi/locations/global/memberships/ci-ec1a14a903eb1fc": oauth2: cannot fetch token: Post "https://oauth2.googleapis.com/token": dial tcp 108.177.98.95:443: i/o timeout * Post "https://cloudresourcemanager.googleapis.com/v1/projects/baremetal-runqi:testIamPermissions?alt=json&prettyPrint=false": oauth2: cannot fetch token: Post "https://oauth2.googleapis.com/token": dial tcp 74.125.199.95:443: i/o timeout Solusi Tetapkan HTTPS_PROXY dan NO_PROXY secara manual di workstation admin.
Upgrade dan update	1.28.0-gke.435	Upgrade ke versi 1.28.0-gke.435 mungkin gagal jika audit.log memiliki kepemilikan yang salah Dalam beberapa kasus, file /var/log/apiserver/audit.log pada node bidang kontrol memiliki kepemilikan grup dan pengguna yang ditetapkan ke root. Setelan kepemilikan file ini menyebabkan kegagalan upgrade untuk node bidang kontrol saat mengupgrade cluster dari versi 1.16.x ke versi 1.28.0-gke.435. Masalah ini hanya berlaku untuk cluster yang dibuat sebelum versi 1.11 dan yang memiliki Cloud Audit Logs dinonaktifkan. Cloud Audit Logs diaktifkan secara default untuk cluster pada versi 1.9 dan yang lebih baru. Solusi Jika Anda tidak dapat mengupgrade cluster ke versi 1.28.100-gke.146, gunakan langkah-langkah berikut sebagai solusi untuk menyelesaikan upgrade cluster Anda ke versi 1.28.0-gke.435: Jika Cloud Audit Logs diaktifkan, hapus file /var/log/apiserver/audit.log. Jika Cloud Audit Logs dinonaktifkan, ubah kepemilikan /var/log/apiserver/audit.log ke direktori induk yang sama dengan /var/log/apiserver.
Networking, Upgrade, dan update	1.28.0-gke.435	MetalLB tidak menetapkan alamat IP ke Layanan VIP Google Distributed Cloud menggunakan MetalLB untuk paket load balancing. Dalam rilis Google Distributed Cloud 1.28.0-gke.435, paket MetalLB diupgrade ke versi 0.13, yang memperkenalkan dukungan CRD untuk IPAddressPools. Namun, karena ConfigMaps mengizinkan nama apa pun untuk IPAddressPool, nama kumpulan tersebut harus dikonversi menjadi nama yang mematuhi Kubernetes dengan menambahkan hash ke akhir nama IPAddressPool. Misalnya, IPAddressPool dengan nama default dikonversi menjadi nama seperti default-qpvpd saat Anda mengupgrade cluster ke versi 1.28.0-gke.435. Karena MetalLB memerlukan nama IPPool tertentu untuk dipilih, konversi nama ini mencegah MetalLB membuat pemilihan kumpulan dan menetapkan alamat IP. Oleh karena itu, Layanan yang menggunakan metallb.universe.tf/address-pool sebagai anotasi guna memilih kumpulan alamat untuk alamat IP tidak akan lagi menerima alamat IP dari pengontrol MetalLB. Masalah ini telah diperbaiki di Google Distributed Cloud versi 1.28.100-gke.146. Solusi Jika tidak dapat mengupgrade cluster ke versi 1.28.100-gke.146, gunakan langkah-langkah berikut sebagai solusinya: Dapatkan nama IPAddressPool yang dikonversi: kubectl get IPAddressPools -n kube-system Update Layanan yang terpengaruh untuk menetapkan anotasi metallb.universe.tf/address-pool ke nama yang dikonversi dengan hash. Misalnya, jika nama IPAddressPool dikonversi dari default menjadi nama seperti default-qpvpd, ubah anotasi metallb.universe.tf/address-pool: default di Service menjadi metallb.universe.tf/address-pool: default-qpvpd. Hash yang digunakan dalam konversi nama bersifat determenistik, sehingga solusinya bersifat persisten.
Upgrade dan update	1.14, 1.15, 1.16, 1.28, 1.29	Pod orphan setelah diupgrade ke versi 1.14.x Saat Anda mengupgrade cluster Google Distributed Cloud ke versi 1.14.x, beberapa resource dari versi sebelumnya tidak akan dihapus. Secara khusus, Anda mungkin melihat kumpulan pod usang seperti berikut: capi-webhook-system/capi-controller-manager-xxx capi-webhook-system/capi-kubeadm-bootstrap-controller-manager-xxx Objek usang ini tidak memengaruhi operasi cluster secara langsung, tetapi sebagai praktik terbaik, sebaiknya Anda menghapusnya. Jalankan perintah berikut untuk menghapus objek usang: kubectl delete ns capi-webhook-system kubectl delete validatingwebhookconfigurations capi-validating-webhook-configuration kubectl delete mutatingwebhookconfigurations capi-mutating-webhook-configuration Masalah ini telah diperbaiki di Google Distributed Cloud versi 1.15.0 dan yang lebih baru.
Penginstalan	1,14	Pembuatan cluster macet pada tugas machine-init Jika mencoba menginstal Google Distributed Cloud versi 1.14.x, Anda mungkin akan mengalami kegagalan karena tugas machine-init, yang mirip dengan contoh output berikut: "kubeadm join" task failed due to: error execution phase control-plane-join/etcd: error creating local etcd static pod manifest file: etcdserver: re-configuration failed due to not enough started members "kubeadm reset" task failed due to: panic: runtime error: invalid memory address or nil pointer dereference Solusi: Hapus anggota etcd yang sudah tidak digunakan lagi yang menyebabkan tugas machine-init gagal. Selesaikan langkah-langkah berikut pada node bidang kontrol yang berfungsi: Cantumkan anggota dll. yang ada: etcdctl --key=/etc/kubernetes/pki/etcd/peer.key \ --cacert=/etc/kubernetes/pki/etcd/ca.crt \ --cert=/etc/kubernetes/pki/etcd/peer.crt \ member list Cari anggota dengan status unstarted, seperti yang ditunjukkan dalam contoh output berikut: 5feb7ac839625038, started, vm-72fed95a, https://203.0.113.11:2380, https://203.0.113.11:2379, false 99f09f145a74cb15, started, vm-8a5bc966, https://203.0.113.12:2380, https://203.0.113.12:2379, false bd1949bcb70e2cb5, unstarted, , https://203.0.113.10:2380, , false Hapus anggota etcd yang gagal: etcdctl --key=/etc/kubernetes/pki/etcd/peer.key \ --cacert=/etc/kubernetes/pki/etcd/ca.crt \ --cert=/etc/kubernetes/pki/etcd/peer.crt \ member remove MEMBER_ID Ganti MEMBER_ID dengan ID anggota etcd yang gagal. Pada contoh output sebelumnya, ID ini adalah bd1949bcb70e2cb5. Contoh output berikut menunjukkan bahwa anggota telah dihapus: Member bd1949bcb70e2cb5 removed from cluster 9d70e2a69debf2f
Networking	1.28.0	Cilium-operator tidak memiliki izin Node list dan watch Pada Cilium 1.13, izin ClusterRole cilium-operator salah. Izin Node list dan watch tidak ada. cilium-operator gagal memulai pembersih sampah memori, yang mengakibatkan masalah berikut: Kebocoran resource Cilium. Identitas usang tidak akan dihapus dari peta kebijakan BFP. Peta kebijakan mungkin mencapai batas 16 ribu tayangan iklan. Entri baru tidak dapat ditambahkan. Penerapan NetworkPolicy salah. Identitas mungkin mencapai batas 64K. Pod baru tidak dapat dibuat. Operator yang tidak memiliki izin Node akan melaporkan contoh pesan log berikut: 2024-01-02T20:41:37.742276761Z level=error msg=k8sError error="github.com/cilium/cilium/operator/watchers/node.go:83: Failed to watch *v1.Node: failed to list *v1.Node: nodes is forbidden: User \"system:serviceaccount:kube-system:cilium-operator\" cannot list resource \"nodes\" in API group \"\" at the cluster scope" subsys=k8s Agen Cilium melaporkan pesan error jika tidak dapat menyisipkan entri ke peta kebijakan, seperti contoh berikut: level=error msg="Failed to add PolicyMap key" bpfMapKey="{6572100 0 0 0}" containerID= datapathPolicyRevision=0 desiredPolicyRevision=7 endpointID=1313 error="Unable to update element for Cilium_policy_01313 map with file descriptor 190: the map is full, please consider resizing it. argument list too long" identity=128 ipv4= ipv6= k8sPodName=/ port=0 subsys=endpoint Solusi: Hapus identitas Cilium, lalu tambahkan izin ClusterRole yang tidak ada ke operator: Hapus objek CiliumIdentity yang ada: kubectl delete ciliumid –-all Edit objek ClusterRole cilium-operator: kubectl edit clusterrole cilium-operator Tambahkan bagian untuk nodes yang menyertakan izin yang tidak ada, seperti yang ditunjukkan dalam contoh berikut: - apiGroups: - "" resources: - nodes verbs: - get - list - watch Simpan dan tutup editor. Operator secara dinamis mendeteksi perubahan izin. Anda tidak perlu memulai ulang operator secara manual.
Upgrade dan update	1.15.0-1.15.7, 1.16.0-1.16.3	Masalah sementara yang ditemukan selama pemeriksaan preflight Salah satu tugas health check kubeadm yang dijalankan selama pemeriksaan preflight upgrade mungkin gagal dengan pesan error berikut: [ERROR CreateJob]: could not delete Job \"upgrade-health-check\" in the namespace \"kube-system\": jobs.batch \"upgrade-health-check\" not found Error ini dapat diabaikan dengan aman. Jika Anda mengalami error yang memblokir upgrade, jalankan kembali perintah upgrade. Jika Anda mengamati error ini saat menjalankan preflight menggunakan perintah bmctl preflightcheck, tidak ada yang diblokir oleh kegagalan ini. Anda dapat menjalankan pemeriksaan preflight lagi untuk mendapatkan informasi preflight yang akurat. Solusi: Jalankan kembali perintah upgrade, atau jika ditemukan selama bmctl preflightcheck, jalankan kembali perintah preflightcheck.
Operasi	1.14, 1.15.0-1.15.7, 1.16.0-1.16.3, 1.28.0	Health check Jaringan berkala gagal saat node diganti atau dihapus Masalah ini memengaruhi cluster yang melakukan health check jaringan secara berkala setelah node diganti atau dihapus. Jika cluster Anda menjalani health check secara berkala, health check jaringan berkala akan menyebabkan kegagalan setelah penggantian atau penghapusan node, karena inventaris jaringan ConfigMap tidak diperbarui setelah dibuat. Solusi: Solusi yang direkomendasikan adalah menghapus inventaris ConfigMap dan health check jaringan berkala. Operator cluster akan otomatis membuat ulang cluster dengan informasi terbaru. Untuk cluster 1.14.x, jalankan perintah berikut: kubectl delete configmap \ $(kubectl get cronjob CLUSTER_NAME-network -o=jsonpath='{.spec.jobTemplate.spec.template.spec.volumes[?(@name=="inventory-config-volume")].configMap.name}' \ -n CLUSTER_NAMESPACE) \ -n CLUSTER_NAMESPACE \ --kubeconfig ADMIN_KUBECONFIG kubectl delete healthchecks.baremetal.cluster.gke.io \ CLUSTER_NAME-network -n CLUSTER_NAMESPACE \ --kubeconfig ADMIN_KUBECONFIG Untuk cluster 1.15.0 dan yang lebih baru, jalankan perintah berikut: kubectl delete configmap \ $(kubectl get cronjob bm-system-network -o=jsonpath='{.spec.jobTemplate.spec.template.spec.volumes[?(@.name=="inventory-config-volume")]configMap.name}' \ -n CLUSTER_NAMESPACE) \ -n CLUSTER_NAMESPACE \ --kubeconfig ADMIN_KUBECONFIG kubectl delete healthchecks.baremetal.cluster.gke.io \ bm-system-network -n CLUSTER_NAMESPACE \ --kubeconfig ADMIN_KUBECONFIG
Networking	1.14, 1.15, 1.16.0-1.16.2	Gateway Jaringan untuk GDC tidak dapat menerapkan konfigurasi jika nama perangkat berisi titik Jika Anda memiliki perangkat jaringan yang menyertakan karakter titik (.) dalam namanya, seperti bond0.2, Gateway Jaringan untuk GDC akan memperlakukan periode tersebut sebagai jalur di direktori saat sysctl dijalankan untuk melakukan perubahan. Saat Network Gateway for GDC memeriksa apakah deteksi alamat duplikat (DAD) diaktifkan, pemeriksaan mungkin gagal, sehingga tidak akan direkonsiliasi. Perilaku di antara versi cluster berbeda-beda: 1.14 dan 1.15: Error ini hanya ada saat Anda menggunakan alamat IP mengambang IPv6. Jika tidak menggunakan alamat IP mengambang IPv6, Anda tidak akan melihat masalah ini saat nama perangkat berisi titik. 1.16.0 - 1.16.2: Error ini selalu ada jika nama perangkat Anda berisi titik. Solusi: Upgrade cluster Anda ke versi 1.16.3 atau yang lebih baru. Sebagai solusi hingga Anda dapat mengupgrade cluster, hapus titik (.) dari nama perangkat.
Upgrade dan update, Jaringan, Keamanan	1.16.0	Upgrade ke 1.16.0 akan gagal jika seccomp dinonaktifkan Jika seccomp dinonaktifkan untuk cluster Anda (spec.clusterSecurity.enableSeccomp ditetapkan ke false), upgrade ke versi 1.16.0 akan gagal. Google Distributed Cloud versi 1.16 menggunakan Kubernetes versi 1.27. Pada Kubernetes versi 1.27.0 dan yang lebih baru, fitur untuk menetapkan profil seccomp adalah GA dan tidak lagi menggunakan gate fitur. Perubahan Kubernetes ini menyebabkan upgrade ke versi 1.16.0 gagal saat seccomp dinonaktifkan dalam konfigurasi cluster. Masalah ini telah diperbaiki pada cluster versi 1.16.1 dan yang lebih tinggi. Jika kolom cluster.spec.clusterSecurity.enableSeccomp ditetapkan ke false, Anda dapat mengupgrade ke versi 1.16.1 atau yang lebih baru. Cluster dengan spec.clusterSecurity.enableSeccomp yang tidak disetel atau ditetapkan ke true tidak akan terpengaruh.
Penginstalan, Operasi	1.11, 1.12, 1.13, 1.14, 1.15.0-1.15.5, 1.16.0-1.16.1	Metadata dalam container dapat rusak setelah dimulai ulang saat /var/lib/containerd terpasang Jika Anda telah memasang /var/lib/containerd secara opsional, metadata dalam container mungkin akan rusak setelah dimulai ulang. Metadata yang rusak dapat menyebabkan Pod gagal, termasuk Pod yang penting bagi sistem. Untuk memeriksa apakah masalah ini memengaruhi Anda, lihat apakah pemasangan opsional ditentukan di /etc/fstab untuk /var/lib/containerd/ dan memiliki nofail dalam opsi pemasangan. Solusi: Hapus opsi pemasangan nofail di /etc/fstab, atau upgrade cluster Anda ke versi 1.15.6 atau yang lebih baru.
Operasi	1.13, 1.14, 1.15, 1.16, 1.28	Membersihkan Pod usang di cluster Anda mungkin melihat Pod yang dikelola oleh Deployment (ReplicaSet) dalam status Failed dan dengan status TaintToleration. Pod ini tidak menggunakan resource cluster, tetapi harus dihapus. Anda dapat menggunakan perintah kubectl berikut untuk menampilkan daftar Pod yang dapat dibersihkan: kubectl get pods –A | grep TaintToleration Contoh output berikut menunjukkan Pod dengan status TaintToleration: kube-system stackdriver-metadata-agent-[...] 0/1 TaintToleration 0 Solusi: Untuk setiap Pod dengan gejala yang dijelaskan, periksa ReplicaSet tempat Pod berada. Jika ReplicaSet ini terpenuhi, Anda dapat menghapus Pod: Dapatkan ReplicaSet yang mengelola Pod dan menemukan nilai ownerRef.Kind: kubectl get pod POD_NAME -n NAMESPACE -o yaml Dapatkan ReplicaSet dan verifikasi bahwa status.replicas sama dengan spec.replicas: kubectl get replicaset REPLICA_NAME -n NAMESPACE -o yaml Jika namanya cocok, hapus Pod: kubectl delete pod POD_NAME -n NAMESPACE.
Upgrade	1.16.0	peristiwa etcd dapat terhenti saat diupgrade ke versi 1.16.0 Saat Anda mengupgrade cluster yang sudah ada ke versi 1.16.0, kegagalan Pod yang terkait dengan peristiwa etcd dapat menghentikan operasi. Secara khusus, tugas node upgrade akan gagal untuk langkah TASK [etcd_events_install : Run etcdevents]. Jika terpengaruh oleh masalah ini, Anda akan melihat kegagalan Pod seperti berikut: Pod kube-apiserver gagal dimulai dengan error berikut: connection error: desc = "transport: Error while dialing dial tcp 127.0.0.1:2382: connect: connection refused" Pod etcd-events gagal dimulai dengan error berikut: Error: error syncing endpoints with etcd: context deadline exceeded Solusi: Jika Anda tidak dapat mengupgrade cluster ke versi yang telah diperbaiki, gunakan solusi sementara berikut untuk mengatasi error: Gunakan SSH untuk mengakses node bidang kontrol dengan error yang dilaporkan. Edit file manifes etcd-events, /etc/kubernetes/manifests/etcd-events.yaml, dan hapus flag initial-cluster-state=existing. Terapkan manifes. Upgrade akan dilanjutkan.
Networking	1.15.0-1.15.2	CoreDNS orderPolicy tidak dikenali OrderPolicy tidak dikenali sebagai parameter dan tidak digunakan. Sebagai gantinya, Google Distributed Cloud selalu menggunakan Random. Masalah ini terjadi karena template CoreDNS tidak diupdate, yang menyebabkan orderPolicy diabaikan. Solusi: Perbarui template CoreDNS dan terapkan perbaikan. Perbaikan ini tetap ada hingga upgrade. Edit template yang ada: kubectl edit cm -n kube-system coredns-template Ganti konten template dengan konten berikut ini: coredns-template: |- .:53 { errors health { lameduck 5s } ready kubernetes cluster.local in-addr.arpa ip6.arpa { pods insecure fallthrough in-addr.arpa ip6.arpa } {{- if .PrivateGoogleAccess }} import zones/private.Corefile {{- end }} {{- if .RestrictedGoogleAccess }} import zones/restricted.Corefile {{- end }} prometheus :9153 forward . {{ .UpstreamNameservers }} { max_concurrent 1000 {{- if ne .OrderPolicy "" }} policy {{ .OrderPolicy }} {{- end }} } cache 30 {{- if .DefaultDomainQueryLogging }} log {{- end }} loop reload loadbalance }{{ range $i, $stubdomain := .StubDomains }} {{ $stubdomain.Domain }}:53 { errors {{- if $stubdomain.QueryLogging }} log {{- end }} cache 30 forward . {{ $stubdomain.Nameservers }} { max_concurrent 1000 {{- if ne $.OrderPolicy "" }} policy {{ $.OrderPolicy }} {{- end }} } } {{- end }}
Jaringan, Operasi	1.10, 1.11, 1.12, 1.13, 1.14	Gateway Jaringan untuk komponen GDC dikeluarkan atau tertunda karena kelas prioritas tidak ada Pod gateway jaringan di kube-system dapat menampilkan status Pending atau Evicted, seperti ditunjukkan dalam contoh output ringkas berikut: $ kubectl -n kube-system get pods | grep ang-node ang-node-bjkkc 2/2 Running 0 5d2h ang-node-mw8cq 0/2 Evicted 0 6m5s ang-node-zsmq7 0/2 Pending 0 7h Error ini menunjukkan peristiwa penghapusan atau ketidakmampuan untuk menjadwalkan Pod karena resource node. Karena Gateway Jaringan untuk Pod GDC tidak memiliki PriorityClass, pod memiliki prioritas default yang sama dengan workload lainnya. Jika node memiliki keterbatasan resource, Pod gateway jaringan mungkin akan dikeluarkan. Perilaku ini sangat buruk untuk ang-node DaemonSet, karena Pod tersebut harus dijadwalkan pada node tertentu dan tidak dapat dimigrasikan. Solusi: Upgrade ke versi 1.15 atau yang lebih baru. Sebagai perbaikan jangka pendek, Anda dapat menetapkan PriorityClass ke komponen Gateway Jaringan untuk GDC secara manual. Pengontrol Google Distributed Cloud menimpa perubahan manual ini selama proses rekonsiliasi, seperti selama upgrade cluster. Tetapkan system-cluster-critical PriorityClass ke Deployment pengontrol cluster ang-controller-manager dan autoscaler. Tetapkan PriorityClass system-node-critical ke node ang-daemon DaemonSet.
Penginstalan, Upgrade, dan update	1.15.0, 1.15.1, 1.15.2	Pembuatan dan upgrade cluster gagal karena panjang nama cluster Pembuatan cluster versi 1.15.0, 1.15.1, atau 1.15.2 atau mengupgrade cluster ke versi 1.15.0, 1.15.1, atau 1.15.2 akan gagal jika nama cluster melebihi 48 karakter (versi 1.15.0) atau 45 karakter (versi 1.15.1 atau 1.15.2). Selama operasi pembuatan dan upgrade cluster, Google Distributed Cloud akan membuat resource health check dengan nama yang menggabungkan nama dan versi cluster: Untuk cluster versi 1.15.0, nama resource health check adalah CLUSTER_NAME-add-ons-CLUSTER_VER. Untuk cluster versi 1.15.1 atau 1.15.2, nama resource health check adalah CLUSTER_NAME-kubernetes-CLUSTER_VER. Untuk nama cluster yang panjang, nama resource health check melebihi batasan panjang karakter Kubernetes 63 untuk nama label, sehingga mencegah pembuatan resource health check. Jika health check tidak berhasil, operasi cluster akan gagal. Untuk mengetahui apakah Anda terpengaruh oleh masalah ini, gunakan kubectl describe untuk memeriksa resource yang gagal: kubectl describe healthchecks.baremetal.cluster.gke.io \ HEALTHCHECK_CR_NAME -n CLUSTER_NAMESPACE \ --kubeconfig ADMIN_KUBECONFIG Jika masalah ini memengaruhi Anda, responsnya akan berisi peringatan untuk ReconcileError seperti berikut: ... Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning ReconcileError 77s (x15 over 2m39s) healthcheck-controller Reconcile error, retrying: 1 error occurred: * failed to create job for health check db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1: Job.batch "bm-system-db-uat-mfd7-fic-hybrid-cloud-u24d5f180362cffa4a743" is invalid: [metadata.labels: Invalid value: "db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1": must be no more than 63 characters, spec.template.labels: Invalid value: "db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1": must be no more than 63 characters] Solusi Untuk berhenti memblokir upgrade atau pembuatan cluster, Anda dapat mengabaikan health check. Gunakan perintah berikut untuk membuat patch resource kustom health check dengan status lulus: (status: {pass: true}) kubectl patch healthchecks.baremetal.cluster.gke.io \ HEALTHCHECK_CR_NAME -n CLUSTER_NAMESPACE \ --kubeconfig ADMIN_KUBECONFIG --type=merge \ --subresource status --patch 'status: {pass: true}'
Upgrade dan Update	1,14, 1,15	Cluster versi 1.14.0 dan 1.14.1 dengan fitur pratinjau tidak dapat diupgrade ke versi 1.15.x Jika fitur pratinjau diaktifkan oleh cluster versi 1.14.0 dan 1.14.1, cluster tersebut akan diblokir sehingga tidak berhasil diupgrade ke versi 1.15.x. Ini berlaku untuk fitur pratinjau seperti kemampuan untuk membuat cluster tanpa kube-proxy, yang diaktifkan dengan anotasi berikut dalam file konfigurasi cluster: preview.baremetal.cluster.gke.io/kube-proxy-free: "enable" Jika terpengaruh oleh masalah ini, Anda akan mendapatkan error seperti berikut selama upgrade cluster: [2023-06-20 23:37:47+0000] error judging if the cluster is managing itself: error to parse the target cluster: error parsing cluster config: 1 error occurred: Cluster.baremetal.cluster.gke.io "$cluster-name" is invalid: Annotations[preview.baremetal.cluster.gke.io/$preview-feature-name]: Forbidden: preview.baremetal.cluster.gke.io/$preview-feature-name feature isn't supported in 1.15.1 Anthos Bare Metal version Masalah ini telah diperbaiki pada cluster versi 1.14.2 dan yang lebih tinggi. Solusi: Jika tidak dapat mengupgrade cluster ke versi 1.14.2 atau yang lebih tinggi sebelum mengupgrade ke versi 1.15.x, Anda dapat mengupgrade ke versi 1.15.x secara langsung menggunakan cluster bootstrap: bmctl upgrade cluster --use-bootstrap=true
Operasi	1.15	Cluster versi 1.15 tidak menerima alamat IP mengambang duplikat Gateway Jaringan untuk GDC tidak mengizinkan Anda membuat resource kustom NetworkGatewayGroup baru yang berisi alamat IP di spec.floatingIPs dan sudah digunakan di resource kustom NetworkGatewayGroup yang ada. Aturan ini diterapkan oleh webhook di cluster Google Distributed Cloud versi 1.15.0 dan yang lebih baru. Alamat IP mengambang duplikat yang sudah ada sebelumnya tidak menyebabkan error. Webhook hanya mencegah pembuatan resource kustom NetworkGatewayGroups baru yang berisi alamat IP duplikat. Pesan error webhook mengidentifikasi alamat IP yang bentrok dan resource kustom yang sudah ada dan sudah menggunakannya: IP address exists in other gateway with name default Dokumentasi awal untuk fitur jaringan lanjutan, seperti gateway NAT Keluar, tidak memperingatkan tentang alamat IP duplikat. Awalnya, hanya resource NetworkGatewayGroup bernama default yang dikenali oleh rekonsiliasi. Network Gateway for GDC kini mengenali semua resource kustom NetworkGatewayGroup dalam namespace sistem. Resource kustom NetworkGatewayGroup yang ada akan tetap berlaku, sebagaimana adanya. Solusi: Error hanya terjadi saat pembuatan resource kustom NetworkGatewayGroup baru. Untuk mengatasi error tersebut: Gunakan perintah berikut untuk menampilkan daftar resource kustom NetworkGatewayGroups: kubectl get NetworkGatewayGroups --kubeconfig ADMIN_KUBECONFIG \ -n kube-system -o yaml Buka resource kustom NetworkGatewayGroup yang sudah ada dan hapus alamat IP mengambang (spec.floatingIPs) yang bertentangan: kubectl edit NetworkGatewayGroups --kubeconfig ADMIN_KUBECONFIG \ -n kube-system RESOURCE_NAME Untuk menerapkan perubahan, tutup dan simpan resource kustom yang telah diedit.
Runtime VM di GDC	1.13.7	VM mungkin tidak dimulai pada cluster 1.13.7 yang menggunakan registry pribadi Saat Anda mengaktifkan VM Runtime di GDC pada cluster versi 1.13.7 baru atau yang telah diupgrade dan menggunakan registry pribadi, VM yang terhubung ke jaringan node atau menggunakan GPU mungkin tidak dapat dimulai dengan benar. Masalah ini disebabkan oleh beberapa Pod sistem di namespace vm-system yang mengalami error pengambilan image. Misalnya, jika VM Anda menggunakan jaringan node, beberapa Pod mungkin melaporkan error pengambilan image seperti berikut: macvtap-4x9zp 0/1 Init:ImagePullBackOff 0 70m Masalah ini telah diperbaiki pada cluster Google Distributed Cloud versi 1.14.0 dan yang lebih baru. Solusi Jika tidak dapat langsung mengupgrade cluster, Anda dapat mengambil image secara manual. Perintah berikut mengambil image plugin CNI macvtap untuk VM Anda dan mengirimnya ke registry pribadi: docker pull \ gcr.io/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21 docker tag \ gcr.io/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21 \ REG_HOST/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21 docker push \ REG_HOST/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21 Ganti REG_HOST dengan nama domain host yang Anda cerminkan secara lokal.
Penginstalan	1.11, 1.12	Selama pembuatan cluster di cluster jenis, pod gke-metric-agent gagal dimulai Selama pembuatan cluster di cluster jenis, pod gke-metrics-agent gagal dimulai karena terjadi error pengambilan gambar sebagai berikut: error="failed to pull and unpack image \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": failed to resolve reference \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": pulling from host gcr.io failed with status code [manifests 1.8.3-anthos.2]: 403 Forbidden" Selain itu, di log containerd cluster bootstrap, Anda akan melihat entri berikut: Sep 13 23:54:20 bmctl-control-plane containerd[198]: time="2022-09-13T23:54:20.378172743Z" level=info msg="PullImage \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\" " Sep 13 23:54:21 bmctl-control-plane containerd[198]: time="2022-09-13T23:54:21.057247258Z" level=error msg="PullImage \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\" failed" error="failed to pull and unpack image \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": failed to resolve reference \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": pulling from host gcr.io failed with status code [manifests 1.8.3-anthos.2]: 403 Forbidden" Anda akan melihat error "gagal menarik" berikut di pod: gcr.io/gke-on-prem-staging/gke-metrics-agent Solusi Terlepas dari error yang terjadi, proses pembuatan cluster tidak diblokir karena tujuan pod gke-metrics-agent dalam cluster jenis adalah untuk memfasilitasi tingkat keberhasilan pembuatan cluster serta untuk pelacakan dan pemantauan internal. Oleh karena itu, Anda dapat mengabaikan error ini. Solusi Terlepas dari error yang terjadi, proses pembuatan cluster tidak diblokir karena tujuan pod gke-metrics-agent dalam cluster jenis adalah untuk memfasilitasi tingkat keberhasilan pembuatan cluster serta untuk pelacakan dan pemantauan internal. Oleh karena itu, Anda dapat mengabaikan error ini.
Operasi, Jaringan	1.12, 1.13, 1.14, 1.15, 1.16, 1.28	Mengakses endpoint Layanan IPv6 membuat error pada LoadBalancer Node di CentOS atau RHEL Saat Anda mengakses Service dual-stack (Layanan yang memiliki endpoint IPv4 dan IPv6) dan menggunakan endpoint IPv6, LoadBalancer Node yang menyalurkan Layanan mungkin error. Masalah ini memengaruhi pelanggan yang menggunakan layanan dual-stack dengan versi CentOS atau RHEL dan kernel yang lebih lama dari kernel-4.18.0-372.46.1.el8_6. Jika merasa yakin bahwa masalah ini memengaruhi Anda, periksa versi kernel di LoadBalancer Node menggunakan perintah uname -a. Solusi: Update LoadBalancer Node ke kernel versi kernel-4.18.0-372.46.1.el8_6 atau yang lebih baru. Versi kernel ini tersedia secara default di CentOS serta RHEL versi 8.6 dan yang lebih baru.
Networking	1.11, 1.12, 1.13, 1.14.0	Masalah konektivitas yang terputus-putus setelah Node dimulai ulang Setelah memulai ulang Node, Anda mungkin mengalami masalah konektivitas yang terputus-putus untuk Layanan NodePort atau LoadBalancer. Misalnya, Anda mungkin mengalami TLS handshake atau error reset koneksi yang terputus-putus. Masalah ini telah diperbaiki untuk cluster versi 1.14.1 dan yang lebih baru. Untuk memeriksa apakah masalah ini memengaruhi Anda, lihat aturan penerusan iptables di Node tempat Pod backend untuk Layanan yang terpengaruh sedang berjalan: sudo iptables -L FORWARD Jika melihat aturan KUBE-FORWARD sebelum aturan CILIUM_FORWARD di iptables, Anda mungkin terpengaruh oleh masalah ini. Contoh output berikut menunjukkan Node yang memiliki masalah: Chain FORWARD (policy ACCEPT) target prot opt source destination KUBE-FORWARD all -- anywhere anywhere /* kubernetes forwarding rules */ KUBE-SERVICES all -- anywhere anywhere ctstate NEW /* kubernetes service portals */ KUBE-EXTERNAL-SERVICES all -- anywhere anywhere ctstate NEW /* kubernetes externally-visible service portals */ CILIUM_FORWARD all -- anywhere anywhere /* cilium-feeder: CILIUM_FORWARD */ Solusi: Mulai ulang Pod anetd pada Node yang salah dikonfigurasi. Setelah Anda memulai ulang Pod anet, aturan penerusan di iptables harus dikonfigurasi dengan benar. Contoh output berikut menunjukkan bahwa aturan CILIUM_FORWARD sekarang dikonfigurasi dengan benar sebelum aturan KUBE-FORWARD: Chain FORWARD (policy ACCEPT) target prot opt source destination CILIUM_FORWARD all -- anywhere anywhere /* cilium-feeder: CILIUM_FORWARD */ KUBE-FORWARD all -- anywhere anywhere /* kubernetes forwarding rules */ KUBE-SERVICES all -- anywhere anywhere ctstate NEW /* kubernetes service portals */ KUBE-EXTERNAL-SERVICES all -- anywhere anywhere ctstate NEW /* kubernetes externally-visible service portals */
Upgrade dan update	1,9, 1,10	Fitur pratinjau tidak menyimpan izin asli dan informasi pemilik Fitur pratinjau dari cluster 1.9.x yang menggunakan bmctl 1.9.x tidak menyimpan izin asli dan informasi pemilik. Untuk memastikan apakah Anda terpengaruh oleh fitur ini, ekstrak file yang dicadangkan menggunakan perintah berikut: tar -xzvf BACKUP_FILE Solusi Verifikasi apakah metadata.json ada dan apakah bmctlVersion adalah 1.9.x. Jika metadata.json tidak ada, upgrade ke cluster 1.10.x dan gunakan bmctl 1.10.x untuk mencadangkan/memulihkan.
Mengupgrade dan membuat	1.14.2	clientconfig-operator macet dalam status tertunda dengan CreateContainerConfigError Jika telah mengupgrade atau membuat cluster versi 1.14.2 dengan konfigurasi OIDC/LDAP, Anda mungkin akan melihat Pod clientconfig-operator macet dalam status tertunda. Dengan masalah ini, ada dua Pod clientconfig-operator, dengan satu Pod dalam status berjalan dan satu lagi dalam status tertunda. Masalah ini hanya berlaku untuk cluster versi 1.14.2. Versi cluster sebelumnya seperti 1.14.0 dan 1.14.1 tidak terpengaruh. Masalah ini telah diperbaiki dalam versi 1.14.3 dan semua rilis berikutnya, termasuk 1.15.0 dan yang lebih baru. Solusi: Sebagai solusinya, Anda dapat mem-patch deployment clientconfig-operator untuk menambahkan konteks keamanan tambahan dan memastikan bahwa deployment sudah siap. Gunakan perintah berikut untuk mem-patch clientconfig-operator di cluster target: kubectl patch deployment clientconfig-operator -n kube-system \ -p '{"spec":{"template":{"spec":{"containers": [{"name":"oidcproxy","securityContext":{"runAsGroup":2038,"runAsUser":2038}}]}}}}' \ --kubeconfig CLUSTER_KUBECONFIG Ganti kode berikut: CLUSTER_KUBECONFIG: jalur file kubeconfig untuk cluster target.
Operasi	1.11, 1.12, 1.13, 1.14, 1.15	Rotasi certificate authority gagal untuk cluster tanpa load balancing yang dipaketkan Untuk cluster tanpa load balancing yang dipaketkan (spec.loadBalancer.mode disetel ke manual), perintah bmctl update credentials certificate-authorities rotate dapat menjadi tidak responsif dan gagal dengan error berikut: x509: certificate signed by unknown authority. Jika Anda terpengaruh oleh masalah ini, perintah bmctl mungkin menampilkan pesan berikut sebelum menjadi tidak responsif: Signing CA completed in 3/0 control-plane nodes Dalam hal ini, perintah akhirnya gagal. Log otoritas sertifikat rotasi untuk cluster dengan tiga bidang kontrol dapat menyertakan entri seperti berikut: [2023-06-14 22:33:17+0000] waiting for all nodes to trust CA bundle OK [2023-06-14 22:41:27+0000] waiting for first round of pod restart to complete OK Signing CA completed in 0/0 control-plane nodes Signing CA completed in 1/0 control-plane nodes Signing CA completed in 2/0 control-plane nodes Signing CA completed in 3/0 control-plane nodes ... Unable to connect to the server: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "kubernetes") Solusi Jika memerlukan bantuan tambahan, hubungi Dukungan Google.
Pemasangan, Jaringan	1.11, 1.12, 1.13, 1.14.0-1.14.1	ipam-controller-manager crashloop di cluster dual-stack Ketika Anda men-deploy cluster dual-stack (cluster dengan alamat IPv4 dan IPv6), Pod ipam-controller-manager mungkin mengalami error loop. Perilaku ini menyebabkan Node mengalami siklus antara status Ready dan NotReady, dan dapat menyebabkan penginstalan cluster gagal. Masalah ini dapat terjadi saat server API memiliki beban tinggi. Untuk melihat apakah masalah ini memengaruhi Anda, periksa apakah Pod ipam-controller-manager gagal dengan error CrashLoopBackOff: kubectl -n kube-system get pods | grep ipam-controller-manager Contoh output berikut menunjukkan Pod dalam status CrashLoopBackOff: ipam-controller-manager-h7xb8 0/1 CrashLoopBackOff 3 (19s ago) 2m ipam-controller-manager-vzrrf 0/1 CrashLoopBackOff 3 (19s ago) 2m1s ipam-controller-manager-z8bdw 0/1 CrashLoopBackOff 3 (31s ago) 2m2s Dapatkan detail untuk Node yang memiliki status NotReady: kubectl describe node <node-name> | grep PodCIDRs Dalam cluster yang memiliki masalah ini, Node tidak memiliki PodCIDR yang ditetapkan untuknya, seperti ditunjukkan pada contoh output berikut: PodCIDRs: Dalam cluster yang sehat, semua Node harus memiliki PodCIDR dual-stack yang ditetapkan ke cluster tersebut, seperti ditunjukkan pada contoh output berikut: PodCIDRs: 192.168.6.0/24,222:333:444:555:5:4:7:0/120 Solusi: Mulai ulang Pod ipam-controller-manager: kubectl -n kube-system rollout restart ds ipam-controller-manager
Operasi	1.6, 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13, dan 1.14	dll. kelaparan smartwatch Cluster yang menjalankan dlld versi 3.4.13 atau yang lebih lama mungkin mengalami kelaparan menonton dan pantauan resource non-operasional, yang dapat menyebabkan masalah berikut: Penjadwalan pod terganggu Node tidak dapat didaftarkan kubelet tidak mengamati perubahan pod Masalah ini dapat menyebabkan cluster tidak berfungsi. Masalah ini telah diperbaiki di Google Distributed Cloud versi 1.12.9, 1.13.6, 1.14.3, dan rilis berikutnya. Rilis yang lebih baru ini menggunakan etcd versi 3.4.21. Semua versi Google Distributed Cloud sebelumnya terpengaruh oleh masalah ini. Solusi Jika tidak dapat segera melakukan upgrade, Anda dapat mengurangi risiko kegagalan cluster dengan mengurangi jumlah node dalam cluster. Hapus node hingga metrik etcd_network_client_grpc_sent_bytes_total kurang dari 300 MBps. Untuk melihat metrik ini di Metrics Explorer: Buka Metrics Explorer di konsol Google Cloud: Buka Metrics Explorer Pilih tab Configuration Luaskan Select a metric, masukkan Kubernetes Container di panel filter, lalu gunakan submenu untuk memilih metrik: Di menu Active resources, pilih Kubernetes Container. Di menu Active metric categories, pilih Anthos. Di menu Active metrics, pilih etcd_network_client_grpc_sent_bytes_total. Klik Terapkan.
Networking	1.11.6, 1.12.3	Status mode vfio-pci operator SR-IOV "Gagal" syncStatus objek SriovNetworkNodeState dapat melaporkan nilai "Failed" untuk node yang dikonfigurasi. Untuk melihat status node dan menentukan apakah masalahnya memengaruhi Anda, jalankan perintah berikut: kubectl -n gke-operators get \ sriovnetworknodestates.sriovnetwork.k8s.cni.cncf.io NODE_NAME \ -o jsonpath='{.status.syncStatus}' Ganti NODE_NAME dengan nama node yang akan diperiksa. Solusi: Jika status objek SriovNetworkNodeState "Gagal", upgrade cluster Anda ke versi 1.11.7 atau yang lebih baru, atau versi 1.12.4 atau yang lebih baru.
Upgrade dan update	1.10, 1.11, 1.12, 1.13, 1.14.0, 1.14.1	Beberapa worker node tidak dalam status Siap setelah upgrade Setelah upgrade selesai, kondisi Siap untuk beberapa node pekerja mungkin ditetapkan ke false. Pada resource Node, Anda akan melihat error di samping kondisi Ready yang mirip dengan contoh berikut: container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized Saat Anda login ke komputer yang terhenti, konfigurasi CNI pada perangkat tersebut akan kosong: sudo ls /etc/cni/net.d/ Solusi Mulai ulang pod anetd node dengan menghapusnya.
Upgrade dan update, Keamanan	1.10	Rotasi sertifikat beberapa kali dari cert-manager menyebabkan inkonsistensi Setelah beberapa rotasi sertifikat otomatis atau manual, pod webhook, seperti anthos-cluster-operator tidak diperbarui dengan sertifikat baru yang diterbitkan oleh cert-manager. Setiap update terhadap resource kustom cluster gagal dan akan menghasilkan error seperti berikut: Internal error occurred: failed calling webhook "vcluster.kb.io": failed to call webhook: Post "https://webhook-service.kube-system.svc:443/validate-baremetal-cluster-gke-io-v1-cluster?timeout=10s": x509: certificate signed by unknown authority (possibly because of "x509: invalid signature: parent certificate cannot sign this kind of certificate" while trying to verify candidate authority certificate "webhook-service.kube-system.svc") Masalah ini dapat terjadi dalam keadaan berikut: Jika Anda telah melakukan dua rotasi sertifikat manual yang dikeluarkan oleh pengelola sertifikat pada cluster yang lebih lama dari 180 hari atau lebih dan tidak pernah memulai ulang anthos-cluster-operator. Jika Anda telah melakukan rotasi sertifikat yang diterbitkan cert-manager secara manual pada cluster yang lebih lama dari 90 hari atau lebih dan tidak pernah memulai ulang anthos-cluster-operator. Solusi Mulai ulang pod dengan menghentikan anthos-cluster-operator.
Upgrade dan update	1.14.0	Pod deployer pengontrol siklus proses tidak berlaku lagi yang dibuat selama upgrade cluster pengguna Pada cluster admin versi 1.14.0, satu atau beberapa pod deployer pengontrol siklus proses yang sudah tidak berlaku mungkin dibuat selama upgrade cluster pengguna. Masalah ini berlaku untuk cluster pengguna yang awalnya dibuat pada versi yang lebih rendah dari 1.12. Pod yang dibuat secara tidak sengaja tidak menghalangi operasi upgrade, tetapi pod tersebut dapat ditemukan dalam status yang tidak terduga. Sebaiknya Anda menghapus pod yang sudah tidak berlaku. Masalah ini telah diperbaiki dalam rilis 1.14.1. Solusi: Untuk menghapus pod deployer pengontrol siklus proses yang sudah tidak berlaku: Mencantumkan resource pemeriksaan preflight: kubectl get preflightchecks --kubeconfig ADMIN_KUBECONFIG -A Outputnya akan terlihat seperti ini: NAMESPACE NAME PASS AGE cluster-ci-87a021b9dcbb31c ci-87a021b9dcbb31c true 20d cluster-ci-87a021b9dcbb31c ci-87a021b9dcbb31cd6jv6 false 20d di mana ci-87a021b9dcbb31c adalah nama cluster. Hapus resource yang nilainya di kolom PASS adalah true atau false. Misalnya, untuk menghapus resource dalam contoh output sebelumnya, gunakan perintah berikut: kubectl delete preflightchecks ci-87a021b9dcbb31c \ -n cluster-ci-87a021b9dcbb31c \ --kubeconfig ADMIN_KUBECONFIG kubectl delete preflightchecks ci-87a021b9dcbb31cd6jv6 \ -n cluster-ci-87a021b9dcbb31c \ --kubeconfig ADMIN_KUBECONFIG
Networking	1.9, 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28	Status BGPSession terus berubah karena banyaknya rute masuk Jaringan lanjutan Google Distributed Cloud gagal mengelola sesi BGP dengan benar saat peer eksternal mengiklankan rute dalam jumlah besar (sekitar 100 atau lebih). Dengan jumlah rute masuk yang besar, pengontrol BGP node-lokal membutuhkan waktu terlalu lama untuk merekonsiliasi sesi BGP dan gagal memperbarui statusnya. Kurangnya update status, atau health check, menyebabkan sesi dihapus karena tidak berlaku. Perilaku yang tidak diinginkan pada sesi BGP yang mungkin Anda temukan dan mengindikasikan adanya masalah meliputi hal berikut: Penghapusan dan pembuatan ulang bgpsession secara terus-menerus. bgpsession.status.state tidak pernah menjadi Established Rute yang gagal mengiklankan atau berulang kali diiklankan dan dibatalkan. Masalah load balancing BGP mungkin akan terlihat pada masalah konektivitas ke layanan LoadBalancer. Masalah FlatIP BGP mungkin terlihat dengan masalah konektivitas ke Pod. Untuk mengetahui apakah masalah BGP Anda disebabkan oleh peer jarak jauh yang mengiklankan terlalu banyak rute, gunakan perintah berikut untuk meninjau status dan output terkait: Gunakan kubectl get bgpsessions pada cluster yang terpengaruh. Output menunjukkan bgpsessions dengan status "Not Builted" dan waktu laporan terakhir terus dihitung hingga sekitar 10-12 detik sebelum terlihat direset ke nol. Output kubectl get bgpsessions menunjukkan bahwa sesi yang terpengaruh dibuat ulang berulang kali: kubectl get bgpsessions \ -o jsonpath="{.items[*]['metadata.name', 'metadata.creationTimestamp']}" Pesan log menunjukkan bahwa sesi BGP yang sudah tidak berlaku sedang dihapus: kubectl logs ang-controller-manager-POD_NUMBER Ganti POD_NUMBER dengan pod pemimpin di cluster Anda. Solusi: Kurangi atau hilangkan jumlah rute yang diberitahukan dari peer jarak jauh ke cluster dengan kebijakan ekspor. Di cluster Google Distributed Cloud versi 1.14.2 dan yang lebih baru, Anda juga dapat menonaktifkan fitur yang memproses rute yang diterima menggunakan AddOnConfiguration. Tambahkan argumen --disable-received-routes ke container bgpd daemonset ang-daemon.
Networking	1,14, 1,15, 1,16, 1,28	Waktu tunggu aplikasi yang disebabkan oleh kegagalan penyisipan tabel conntrack Cluster yang berjalan pada Ubuntu OS yang menggunakan kernel 5.15 atau lebih tinggi rentan terhadap kegagalan penyisipan tabel pelacakan koneksi netfilter (conntrack). Kegagalan penyisipan dapat terjadi bahkan jika tabel conntrack memiliki ruang untuk entri baru. Kegagalan disebabkan oleh perubahan pada kernel 5.15 dan yang lebih baru yang membatasi penyisipan tabel berdasarkan panjang rantai. Untuk melihat apakah Anda terpengaruh oleh masalah ini, periksa statistik sistem pelacakan koneksi dalam kernel dengan perintah berikut: sudo conntrack -S Responsnya akan terlihat seperti ini: cpu=0 found=0 invalid=4 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0 cpu=1 found=0 invalid=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0 cpu=2 found=0 invalid=16 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0 cpu=3 found=0 invalid=13 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0 cpu=4 found=0 invalid=9 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0 cpu=5 found=0 invalid=1 insert=0 insert_failed=0 drop=0 early_drop=0 error=519 search_restart=0 clash_resolve=126 chaintoolong=0 ... Jika nilai chaintoolong dalam respons bukan angka nol, Anda akan terpengaruh oleh masalah ini. Solusi Mitigasi jangka pendeknya adalah dengan menambah ukuran tabel hash netfiler (nf_conntrack_buckets) dan tabel pelacakan koneksi netfilter (nf_conntrack_max). Gunakan perintah berikut pada setiap node cluster untuk memperbesar ukuran tabel: sysctl -w net.netfilter.nf_conntrack_buckets=TABLE_SIZE sysctl -w net.netfilter.nf_conntrack_max=TABLE_SIZE Ganti TABLE_SIZE dengan ukuran baru dalam byte. Nilai ukuran tabel default adalah 262144. Sebaiknya tetapkan nilai yang sama dengan 65.536 dikalikan dengan jumlah core pada node. Misalnya, jika node Anda memiliki delapan core, tetapkan ukuran tabel ke 524288.
Upgrade dan update	1.11.3, 1.11.4, 1.11.5, 1.11.6, 1.11.7, 1.11.8, 1.12.4, 1.12.5, 1.12.6, 1.12.7, 1.12.8, 1.13.4, 1.13.4, 1.12.8, 1.13.4, 1.12.5	Tidak dapat memulihkan cadangan cluster dengan bmctl untuk beberapa versi Sebaiknya cadangkan cluster sebelum mengupgrade sehingga Anda dapat memulihkan versi sebelumnya jika upgrade tidak berhasil. Masalah pada perintah bmctl restore cluster menyebabkannya gagal memulihkan cadangan cluster dengan versi yang diidentifikasi. Masalah ini khusus untuk upgrade, yaitu ketika Anda memulihkan cadangan versi sebelumnya. Jika cluster Anda terpengaruh, log bmctl restore cluster akan berisi error berikut: Error: failed to extract image paths from profile: anthos version VERSION not supported Solusi: Hingga masalah ini diperbaiki, sebaiknya Anda menggunakan petunjuk di Mencadangkan dan memulihkan cluster untuk mencadangkan cluster secara manual dan memulihkannya secara manual, jika perlu.
Networking	1.10, 1.11, 1.12, 1.13, 1.14.0-1.14.2	NetworkGatewayGroup mengalami error jika tidak ada alamat IP di antarmuka NetworkGatewayGroup gagal membuat daemon untuk node yang tidak memiliki antarmuka IPv4 dan IPv6. Hal ini menyebabkan fitur seperti BGP LB dan EgressNAT gagal. Jika Anda memeriksa log Pod ang-node yang gagal di namespace kube-system, error yang mirip dengan contoh berikut akan ditampilkan jika alamat IPv6 tidak ada: ANGd.Setup Failed to create ANG daemon {"nodeName": "bm-node-1", "error": "creating NDP client failed: ndp: address \"linklocal\" not found on interface \"ens192\""} Pada contoh sebelumnya, tidak ada alamat IPv6 di antarmuka ens192. Error ARP serupa ditampilkan jika node tidak memiliki alamat IPv4. NetworkGatewayGroup mencoba membuat koneksi ARP dan koneksi NDP ke alamat IP lokal link. Jika alamat IP tidak ada (IPv4 untuk ARP, IPv6 untuk NDP), koneksi akan gagal dan daemon tidak dilanjutkan. Masalah ini telah diperbaiki dalam rilis 1.14.3. Solusi: Hubungkan ke node menggunakan SSH dan tambahkan alamat IPv4 atau IPv6 ke link yang berisi IP node. Pada contoh entri log sebelumnya, antarmuka ini adalah ens192: ip address add dev INTERFACE scope link ADDRESS Ganti kode berikut: INTERFACE: Antarmuka untuk node Anda, seperti ens192. ADDRESS: Alamat IP dan subnet mask yang akan diterapkan ke antarmuka.
Reset/Penghapusan	1.10, 1.11, 1.12, 1.13.0-1.13.2	loop error anthos-cluster-operator saat menghapus node bidang kontrol Saat Anda mencoba menghapus node bidang kontrol dengan menghapus alamat IP dari Cluster.Spec, anthos-cluster-operator akan memasuki status loop error yang memblokir operasi lainnya. Solusi: Masalah telah diperbaiki di 1.13.3 serta 1.14.0 dan yang lebih baru. Semua versi lain akan terpengaruh. Mengupgrade ke salah satu versi tetap Sebagai solusinya, jalankan perintah berikut: kubectl label baremetalmachine IP_ADDRESS \ -n CLUSTER_NAMESPACE baremetal.cluster.gke.io/upgrade-apply- Ganti kode berikut: IP_ADDRESS: Alamat IP node dalam status loop error. CLUSTER_NAMESPACE: Namespace cluster.
Penginstalan	1.13.1, 1.13.2, dan 1.13.3	kubeadm join gagal dalam cluster besar karena token tidak cocok Saat menginstal cluster Google Distributed Cloud dengan jumlah node yang besar, Anda mungkin melihat pesan error kubeadmin join yang mirip dengan contoh berikut: TASK [kubeadm : kubeadm join --config /dev/stdin --ignore-preflight-errors=all] *** fatal: [10.200.0.138]: FAILED! => {"changed": true, "cmd": "kubeadm join --config /dev/stdin --ignore-preflight-errors=all", "delta": "0:05:00.140669", "end": "2022-11-01 21:53:15.195648", "msg": "non-zero return code", "rc": 1, "start": "2022-11-01 21:48:15.054979", "stderr": "W1101 21:48:15.082440 99570 initconfiguration.go:119] Usage of CRI endpoints without URL scheme is deprecated and can cause kubelet errors in the future. Automatically prepending scheme \"unix\" to the \"criSocket\" with value \"/run/containerd/containerd.sock\". Please update your configuration!\nerror execution phase preflight: couldn't validate the identity of the API Server: could not find a JWS signature in the cluster-info ConfigMap for token ID \"yjcik0\"\n To see the stack trace of this error execute with --v=5 or higher", "stderr_lines": ["W1101 21:48:15.082440 99570 initconfiguration.go:119] Usage of CRI endpoints without URL scheme is deprecated and can cause kubelet errors in the future. Automatically prepending scheme \"unix\" to the \"criSocket\" with value \"/run/containerd/containerd.sock\". Please update your configuration!", "error execution phase preflight: couldn't validate the identity of the API Server: could not find a JWS signature in the cluster-info ConfigMap for token ID \"yjcik0\"", "To see the stack trace of this error execute with --v=5 or higher"], "stdout": "[preflight] Running pre-flight checks", "stdout_lines": ["[preflight] Running pre-flight checks"]} Solusi: Masalah ini telah diatasi di Google Distributed Cloud versi 1.13.4 dan yang lebih baru. Jika Anda perlu menggunakan versi yang terpengaruh, buat cluster dengan kurang dari 20 node terlebih dahulu, lalu ubah ukuran cluster untuk menambahkan node lain setelah penginstalan selesai.
Logging dan pemantauan	1.10, 1.11, 1.12, 1.13.0	Batas CPU rendah untuk metrics-server di cluster Edge Dalam cluster Google Distributed Cloud Edge, batas CPU yang rendah untuk metrics-server dapat menyebabkan metrics-server dimulai ulang sering. Penskalaan Otomatis Pod Horizontal (HPA) tidak berfungsi karena metrics-server tidak responsif. Jika batas CPU metrics-server kurang dari 40m, cluster Anda dapat terpengaruh. Untuk memeriksa batas CPU metrics-server, tinjau salah satu file berikut: Cluster Google Distributed Cloud versi 1.x-1.12: kubectl get deployment metrics-server -n kube-system \ -o yaml > metrics-server.yaml Cluster Google Distributed Cloud versi 1.13 atau yang lebih baru: kubectl get deployment metrics-server -n gke-managed-metrics-server \ -o yaml > metrics-server.yaml Solusi: Masalah ini telah diatasi di cluster Google Distributed Cloud versi 1.13.1 atau yang lebih baru. Untuk memperbaiki masalah ini, upgrade cluster Anda. Solusi jangka pendek hingga Anda dapat mengupgrade cluster adalah meningkatkan batas CPU untuk metrics-server secara manual sebagai berikut: Turunkan skala metrics-server-operator: kubectl scale deploy metrics-server-operator --replicas=0 Update konfigurasi dan tingkatkan batas CPU: Cluster Google Distributed Cloud versi 1.x-1.12: kubectl -n kube-system edit deployment metrics-server Cluster Google Distributed Cloud versi 1.13: kubectl -n gke-managed-metrics-server edit deployment metrics-server Hapus baris --config-dir=/etc/config dan tingkatkan batas CPU, seperti ditunjukkan pada contoh berikut: [...] - command: - /pod_nanny # - --config-dir=/etc/config # <--- Remove this line - --container=metrics-server - --cpu=50m # <--- Increase CPU, such as to 50m - --extra-cpu=0.5m - --memory=35Mi - --extra-memory=4Mi - --threshold=5 - --deployment=metrics-server - --poll-period=30000 - --estimator=exponential - --scale-down-delay=24h - --minClusterSize=5 - --use-metrics=true [...] Simpan dan tutup metrics-server untuk menerapkan perubahan.
Networking	1,14, 1,15, 1,16	Koneksi NodePort langsung ke Pod hostNetwork tidak berfungsi Koneksi ke Pod yang diaktifkan dengan hostNetwork menggunakan Layanan NodePort gagal saat Pod backend berada di node yang sama dengan NodePort yang ditargetkan. Masalah ini memengaruhi Layanan LoadBalancer saat digunakan dengan Pod Berjaringan host. Dengan beberapa backend, kegagalan koneksi sporadis mungkin dapat terjadi. Masalah ini disebabkan oleh bug dalam program eBPF. Solusi: Saat menggunakan Layanan Nodeport, jangan targetkan node tempat Pod backend berjalan. Saat menggunakan Layanan LoadBalancer, pastikan Pod yang Di-host Network tidak berjalan pada node LoadBalancer.
Upgrade dan update	1.12.3, 1.13.0	1.13.0 cluster admin tidak dapat mengelola 1.12.3 cluster pengguna Cluster admin yang menjalankan versi 1.13.0 tidak dapat mengelola cluster pengguna yang menjalankan versi 1.12.3. Operasi terhadap cluster pengguna versi 1.12.3 gagal. Solusi: Upgrade cluster admin Anda ke versi 1.13.1, atau upgrade cluster pengguna ke versi yang sama dengan cluster admin.
Upgrade dan update	1.12	Upgrade ke 1.13.x diblokir untuk cluster admin dengan kumpulan node pekerja Cluster admin versi 1.13.0 dan yang lebih tinggi tidak dapat berisi kumpulan node pekerja. Upgrade ke versi 1.13.0 atau yang lebih tinggi untuk cluster admin yang memiliki kumpulan node pekerja akan diblokir. Jika upgrade cluster admin Anda terhenti, Anda dapat mengonfirmasi apakah kumpulan node pekerja adalah penyebabnya dengan memeriksa error berikut pada file upgrade-cluster.log di dalam folder bmctl-workspace: Operation failed, retrying with backoff. Cause: error creating "baremetal.cluster.gke.io/v1, Kind=NodePool" cluster-test-cluster-2023-06-06-140654/np1: admission webhook "vnodepool.kb.io" denied the request: Adding worker nodepool to Admin cluster is disallowed. Solusi: Sebelum mengupgrade, pindahkan semua kumpulan node pekerja ke cluster pengguna. Untuk mengetahui petunjuk cara menambah dan menghapus kumpulan node, lihat Mengelola kumpulan node dalam cluster.
Upgrade dan update	1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28	Error saat memperbarui resource menggunakan kubectl apply Jika Anda mengupdate resource yang ada seperti resource kustom ClientConfig atau Stackdriver menggunakan kubectl apply, pengontrol mungkin akan menampilkan error atau mengembalikan input dan perubahan yang Anda rencanakan. Misalnya, Anda dapat mencoba mengedit resource kustom Stackdriver sebagai berikut dengan mendapatkan resource terlebih dahulu, lalu menerapkan versi yang diupdate: Dapatkan definisi YAML yang ada: kubectl get stackdriver -n kube-system stackdriver \ -o yaml > stackdriver.yaml Mengaktifkan fitur atau mengupdate konfigurasi dalam file YAML. Terapkan kembali file YAML yang telah diperbarui: kubectl apply -f stackdriver.yaml Langkah terakhir untuk kubectl apply adalah tempat Anda mungkin mengalami masalah. Solusi: Jangan gunakan kubectl apply untuk membuat perubahan pada resource yang ada. Sebagai gantinya, gunakan kubectl edit atau kubectl patch seperti yang ditunjukkan pada contoh berikut: Edit resource kustom Stackdriver: kubectl edit stackdriver -n kube-system stackdriver Mengaktifkan fitur atau mengupdate konfigurasi dalam file YAML. Simpan dan keluar dari editor Pendekatan alternatif menggunakan kubectl patch: Dapatkan definisi YAML yang ada: kubectl get stackdriver -n kube-system stackdriver \ -o yaml > stackdriver.yaml Mengaktifkan fitur atau mengupdate konfigurasi dalam file YAML. Terapkan kembali file YAML yang telah diperbarui: kubectl patch stackdriver stackdriver --type merge \ -n kube-system --patch-file stackdriver.yaml
Logging dan pemantauan	1.12, 1.13, 1.14, 1.15, 1.16	Potongan backlog yang rusak menyebabkan errorloop stackdriver-log-forwarder Error loop stackdriver-log-forwarder mencoba memproses potongan backlog yang rusak. Contoh error berikut ditampilkan dalam log container: [2022/09/16 02:05:01] [error] [storage] format check failed: tail.1/1-1659339894.252926599.flb [2022/09/16 02:05:01] [error] [engine] could not segregate backlog chunks Saat errorloop ini terjadi, Anda tidak dapat melihat log di Cloud Logging. Solusi: Untuk mengatasi error ini, selesaikan langkah-langkah berikut: Mengidentifikasi potongan backlog yang rusak. Tinjau contoh pesan error berikut: [2022/09/16 02:05:01] [error] [storage] format check failed: tail.1/1-1659339894.252926599.flb [2022/09/16 02:05:01] [error] [engine] could not segregate backlog chunks Dalam contoh ini, file tail.1/1-1659339894.252926599.flb yang disimpan di var/log/fluent-bit-buffers/tail.1/ mengalami kesalahan. Setiap file *.flb dengan pemeriksaan format yang gagal harus dihapus. Akhiri pod yang sedang berjalan untuk stackdriver-log-forwarder: kubectl --kubeconfig KUBECONFIG -n kube-system \ patch daemonset stackdriver-log-forwarder \ -p '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}' Ganti KUBECONFIG dengan jalur ke file kubeconfig cluster pengguna Anda. Pastikan bahwa Pod stackdriver-log-forwarder telah dihapus sebelum melanjutkan ke langkah berikutnya. Hubungkan ke node menggunakan SSH tempat stackdriver-log-forwarder dijalankan. Pada node, hapus semua file *.flb yang rusak di var/log/fluent-bit-buffers/tail.1/. Jika ada terlalu banyak file yang rusak dan Anda ingin menerapkan skrip untuk membersihkan semua potongan backlog, gunakan skrip berikut: Deploy DaemonSet untuk membersihkan semua data kotor dalam buffer di fluent-bit: kubectl --kubeconfig KUBECONFIG -n kube-system apply -f - << EOF apiVersion: apps/v1 kind: DaemonSet metadata: name: fluent-bit-cleanup namespace: kube-system spec: selector: matchLabels: app: fluent-bit-cleanup template: metadata: labels: app: fluent-bit-cleanup spec: containers: - name: fluent-bit-cleanup image: debian:10-slim command: ["bash", "-c"] args: - | rm -rf /var/log/fluent-bit-buffers/ echo "Fluent Bit local buffer is cleaned up." sleep 3600 volumeMounts: - name: varlog mountPath: /var/log securityContext: privileged: true tolerations: - key: "CriticalAddonsOnly" operator: "Exists" - key: node-role.kubernetes.io/master effect: NoSchedule - key: node-role.gke.io/observability effect: NoSchedule volumes: - name: varlog hostPath: path: /var/log EOF Pastikan DaemonSet telah membersihkan semua node. Output dari dua perintah berikut harus sama dengan jumlah node dalam cluster: kubectl --kubeconfig KUBECONFIG logs \ -n kube-system -l app=fluent-bit-cleanup | grep "cleaned up" | wc -l kubectl --kubeconfig KUBECONFIG \ -n kube-system get pods -l app=fluent-bit-cleanup --no-headers | wc -l Hapus DaemonSet pembersihan: kubectl --kubeconfig KUBECONFIG -n kube-system delete ds \ fluent-bit-cleanup Mulai ulang Pod stackdriver-log-forwarder: kubectl --kubeconfig KUBECONFIG \ -n kube-system patch daemonset stackdriver-log-forwarder --type json \ -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'
Jaringan, Runtime VM di GDC	1.14.0	Memulai ulang Dataplane V2 (anetd) pada cluster dapat menyebabkan VM yang ada tidak dapat terhubung ke jaringan non-pod Pada cluster multi-nic, memulai ulang Dataplane V2 (anetd) dapat menyebabkan virtual machine tidak dapat terhubung ke jaringan. Error yang serupa dengan berikut dapat diamati di log pod anetd: could not find an allocator to allocate the IP of the multi-nic endpoint Solusi: Anda dapat memulai ulang VM sebagai perbaikan cepat. Untuk menghindari terulangnya masalah ini, upgrade cluster Anda ke versi 1.14.1 atau yang lebih baru.
Operasi	1.13, 1.14.0, 1.14.1	gke-metrics-agent tidak memiliki batas memori di cluster profil Edge Bergantung pada beban kerja cluster, gke-metrics-agent mungkin menggunakan memori yang lebih besar dari 4608 MiB. Masalah ini hanya memengaruhi cluster profil Google Distributed Cloud Edge. Cluster profil default tidak terpengaruh. Solusi: Upgrade cluster Anda ke versi 1.14.2 atau yang lebih baru.
Penginstalan	1,12, 1,13	Pembuatan cluster mungkin gagal karena kondisi race Saat Anda membuat cluster menggunakan kubectl, karena kondisi race, pemeriksaan preflight mungkin tidak pernah selesai. Akibatnya, pembuatan cluster mungkin gagal dalam kasus tertentu. Rekonsiliasi pemeriksaan preflight membuat SecretForwarder untuk menyalin rahasia ssh-key default ke namespace target. Biasanya, pemeriksaan preflight memanfaatkan referensi pemilik dan melakukan rekonsiliasi setelah SecretForwarder selesai. Namun, dalam kasus yang jarang terjadi, referensi pemilik SecretForwarder dapat kehilangan referensi ke pemeriksaan preflight, yang menyebabkan pemeriksaan preflight macet. Akibatnya, pembuatan cluster gagal. Untuk melanjutkan rekonsiliasi untuk pemeriksaan preflight berbasis pengontrol, hapus pod operator cluster atau hapus resource preflight-check. Setelah Anda menghapus resource preflight-check, resource lain akan dibuat dan rekonsiliasi dilanjutkan. Atau, Anda dapat mengupgrade cluster yang sudah ada (yang dibuat dengan versi sebelumnya) ke versi tetap.
Networking	1.9, 1.10, 1.11, 1.12, 1.13, 1.14, 1.15	Alamat IP yang dicadangkan tidak dirilis saat menggunakan plugin Whereabouts dengan fitur multi-NIC Dalam fitur multi-Nic, jika Anda menggunakan plugin keberadaan CNI dan menggunakan operasi CNI DEL untuk menghapus antarmuka jaringan Pod, beberapa alamat IP yang dicadangkan mungkin tidak dirilis dengan benar. Hal ini terjadi saat operasi CNI DEL terganggu. Anda dapat memverifikasi reservasi alamat IP Pod yang tidak digunakan dengan menjalankan perintah berikut: kubectl get ippools -A --kubeconfig KUBECONFIG_PATH Solusi: Hapus secara manual alamat IP (ippool) yang tidak digunakan.
Penginstalan	1.10, 1.11.0, 1.11.1, 1.11.2	Pendeteksi Masalah Node gagal di cluster pengguna 1.10.4 Node Problem Detector mungkin gagal pada cluster pengguna versi 1.10.x, jika cluster admin versi 1.11.0, 1.11.1, atau 1.11.2 mengelola cluster pengguna 1.10.x. Saat Node Problem Detector gagal, log akan diperbarui dengan pesan error berikut: Error - NPD not supported for anthos baremetal version 1.10.4: anthos version 1.10.4 not supported. Solusi Upgrade cluster admin ke 1.11.3 untuk menyelesaikan masalah tersebut.
Operasi	1,14	Node cluster IPv4 mode pulau 1,14 memiliki ukuran mask CIDR pod sebesar 24 Pada rilis 1.14, setelan maxPodsPerNode tidak diperhitungkan untuk cluster mode pulau, sehingga node diberi ukuran mask CIDR pod 24 (256 alamat IP).Hal ini dapat menyebabkan cluster kehabisan alamat IP pod lebih awal dari yang diharapkan. Misalnya, jika cluster Anda memiliki ukuran mask CIDR pod 22; setiap node akan diberi mask CIDR pod 24 dan cluster hanya akan dapat mendukung hingga 4 node. Cluster Anda juga mungkin mengalami ketidakstabilan jaringan saat periode churn pod yang tinggi saat maxPodsPerNode ditetapkan ke 129 atau lebih tinggi dan tidak ada overhead yang cukup dalam CIDR pod untuk setiap node. Masalah ini hanya memengaruhi cluster IPv4 mode pulau yang menggunakan maxPodsPerNode di luar rentang 65 hingga 128. Jika cluster Anda terpengaruh, pod anetd akan melaporkan error berikut saat Anda menambahkan node baru ke cluster dan tidak ada podCIDR yang tersedia: error="required IPv4 PodCIDR not available" Solusi Gunakan langkah-langkah berikut untuk menyelesaikan masalah: Upgrade ke versi 1.14.1 atau yang lebih baru. Hapus worker node dan tambahkan kembali. Hapus node bidang kontrol dan tambahkan kembali, sebaiknya satu per satu untuk menghindari periode nonaktif cluster.
Upgrade dan update	1.14.0, 1.14.1	Kegagalan rollback upgrade cluster Rollback upgrade mungkin gagal untuk cluster versi 1.14.0 atau 1.14.1. Jika Anda mengupgrade cluster dari 1.14.0 ke 1.14.1, lalu mencoba melakukan rollback ke 1.14.0 menggunakan perintah bmctl restore cluster, error seperti contoh berikut mungkin ditampilkan: I0119 22:11:49.705596 107905 client.go:48] Operation failed, retrying with backoff. Cause: error updating "baremetal.cluster.gke.io/v1, Kind=HealthCheck" cluster-user-ci-f3a04dc1b0d2ac8/user-ci-f3a04dc1b0d2ac8-network: admission webhook "vhealthcheck.kb.io" denied the request: HealthCheck.baremetal.cluster.gke.io "user-ci-f3a04dc1b0d2ac8-network" is invalid: Spec: Invalid value: v1.HealthCheckSpec{ClusterName:(*string)(0xc0003096e0), AnthosBareMetalVersion:(*string)(0xc000309690), Type:(*v1.CheckType)(0xc000309710), NodePoolNames:[]string(nil), NodeAddresses:[]string(nil), ConfigYAML:(*string)(nil), CheckImageVersion:(*string)(nil), IntervalInSeconds:(*int64)(0xc0015c29f8)}: Field is immutable Solusi: Hapus semua resource healthchecks.baremetal.cluster.gke.io di namespace cluster, lalu jalankan kembali perintah bmctl restore cluster: Tampilkan daftar semua healthchecks.baremetal.cluster.gke.io referensi: kubectl get healthchecks.baremetal.cluster.gke.io \ --namespace=CLUSTER_NAMESPACE \ --kubeconfig=ADMIN_KUBECONFIG Ganti kode berikut: CLUSTER_NAMESPACE: namespace untuk cluster. ADMIN_KUBECONFIG: jalur ke file kubeconfig cluster admin. Hapus semua resource healthchecks.baremetal.cluster.gke.io yang tercantum di langkah sebelumnya: kubectl delete healthchecks.baremetal.cluster.gke.io \ HEALTHCHECK_RESOURCE_NAME \ --namespace=CLUSTER_NAMESPACE \ --kubeconfig=ADMIN_KUBECONFIG Ganti HEALTHCHECK_RESOURCE_NAME dengan nama resource health check. Jalankan kembali perintah bmctl restore cluster.
Networking	1.12.0	Alamat IP eksternal layanan tidak berfungsi dalam mode datar Dalam cluster yang memiliki flatIPv4 yang ditetapkan ke true, Layanan jenis LoadBalancer tidak dapat diakses oleh alamat IP eksternalnya. Masalah ini telah diperbaiki dalam versi 1.12.1. Solusi: Di cilium-config ConfigMap, tetapkan enable-415 ke "true", lalu mulai ulang Pod anetd.
Upgrade dan update	1.13.0, 1.14	Upgrade langsung dari 1.13.0 ke 1.14.x tidak pernah selesai Saat Anda mencoba melakukan upgrade langsung dari 1.13.0 ke 1.14.x menggunakan bmctl 1.14.0 dan tanda --use-bootstrap=false, upgrade tidak pernah selesai. Error pada operator preflight-check menyebabkan cluster tidak pernah menjadwalkan pemeriksaan yang diperlukan, yang berarti pemeriksaan preflight tidak pernah selesai. Solusi: Upgrade ke 1.13.1 terlebih dahulu sebelum Anda mengupgrade ke 1.14.x. Upgrade langsung dari 1.13.0 ke 1.13.1 seharusnya berfungsi. Atau, upgrade dari 1.13.0 ke 1.14.x tanpa flag --use-bootstrap=false.
Upgrade dan update, Keamanan	1.13 dan 1.14	Cluster yang diupgrade ke 1.14.0 kehilangan taint master Node bidang kontrol memerlukan salah satu dari dua taint tertentu untuk mencegah pod workload dijadwalkan pada node tersebut. Saat Anda mengupgrade cluster GKE versi 1.13 ke versi 1.14.0, node bidang kontrol akan kehilangan taint yang diperlukan berikut ini: node-role.kubernetes.io/master:NoSchedule node-role.kubernetes.io/master:PreferNoSchedule Catatan: Cluster yang dikelola sendiri, seperti cluster jenis mandiri, menggunakan taint PreferNoSchedule secara default. Masalah ini tidak menyebabkan kegagalan upgrade, tetapi pod yang tidak seharusnya berjalan pada node bidang kontrol dapat memulainya. Pod workload ini dapat membebani node bidang kontrol dan menyebabkan ketidakstabilan cluster. Mengetahui apakah Anda terpengaruh Temukan node bidang kontrol, gunakan perintah berikut: kubectl get node -l 'node-role.kubernetes.io/control-plane' \ -o name --kubeconfig KUBECONFIG_PATH Untuk memeriksa daftar taint pada node, gunakan perintah berikut: kubectl describe node NODE_NAME \ --kubeconfig KUBECONFIG_PATH Jika tidak satu pun taint yang diperlukan tercantum, Anda akan terpengaruh. Solusi Gunakan langkah-langkah berikut untuk setiap node bidang kontrol pada cluster versi 1.14.0 yang terpengaruh untuk memulihkan fungsi yang tepat. Langkah-langkah ini ditujukan untuk taint node-role.kubernetes.io/master:NoSchedule dan pod terkait. Jika Anda ingin node bidang kontrol menggunakan taint PreferNoSchedule, sesuaikan langkah-langkahnya. Lihat langkah-langkah solusi Terapkan taint yang tidak ada: kubectl taint nodes NODE_NAME \ node-role.kubernetes.io/master:NoSchedule \ -–kubeconfig KUBECONFIG_PATH Temukan pod tanpa toleransi node-role.kubernetes.io/master:NoSchedule: kubectl get pods -A --field-selector spec.nodeName="NODE_NAME" \ -o=custom-columns='Name:metadata.name,Toleration:spec.tolerations[*].key' \ --kubeconfig KUBECONFIG_PATH | \ grep -v "node-role.kubernetes.io/master" | uniq Hapus pod yang tidak memiliki toleransi node-role.kubernetes.io/master:NoSchedule: kubectl delete pod POD_NAME –-kubeconfig KUBECONFIG_PATH
Operasi, Runtime VM di GDC	1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28, 1.29	Pembuatan VM terkadang gagal disertai error upload Membuat Virtual Machine (VM) baru dengan perintah kubectl virt create vm jarang mengalami kegagalan selama upload image. Masalah ini berlaku untuk VM Linux dan Windows. Error tersebut terlihat seperti contoh berikut: PVC default/heritage-linux-vm-boot-dv not found DataVolume default/heritage-linux-vm-boot-dv created Waiting for PVC heritage-linux-vm-boot-dv upload pod to be ready... Pod now ready Uploading data to https://10.200.0.51 2.38 MiB / 570.75 MiB [>----------------------------------------------------------------------------------] 0.42% 0s fail to upload image: unexpected return value 500, ... Solusi Coba lagi perintah kubectl virt create vm untuk membuat VM Anda.
Upgrade dan update, Logging dan pemantauan	1,11	Komponen koleksi terkelola di cluster 1.11 tidak dipertahankan pada upgrade ke versi 1.12 Komponen koleksi terkelola adalah bagian dari Google Cloud Managed Service for Prometheus. Jika Anda men-deploy komponen koleksi terkelola secara manual di namespace gmp-system cluster versi 1.11, resource terkait tidak akan dipertahankan saat Anda mengupgrade ke versi 1.12. Mulai dari cluster versi 1.12.0, komponen Layanan Terkelola untuk Prometheus di namespace gmp-system dan definisi resource khusus terkait dikelola oleh stackdriver-operator dengan kolom enableGMPForApplications. Secara default, kolom enableGMPForApplications ditetapkan ke true, jadi jika Anda men-deploy komponen Managed Service for Prometheus secara manual di namespace sebelum mengupgrade ke versi 1.12, resource akan dihapus oleh stackdriver-operator. Solusi Untuk mempertahankan resource koleksi yang dikelola secara manual: Cadangkan semua resource kustom PodMonitoring yang ada. Upgrade cluster ke versi 1.12 dan aktifkan Managed Service for Prometheus. Deploy ulang resource kustom PodMonitoring di cluster Anda yang telah diupgrade.
Upgrade dan update	1.13	Beberapa cluster versi 1.12 dengan runtime container Docker tidak dapat diupgrade ke versi 1.13 Jika tidak memiliki anotasi berikut, cluster versi 1.12 yang menggunakan runtime container Docker tidak dapat diupgrade ke versi 1.13: baremetal.cluster.gke.io/allow-docker-container-runtime: "true" Jika Anda terpengaruh oleh masalah ini, bmctl akan menulis error berikut dalam file upgrade-cluster.log di dalam folder bmctl-workspace: Operation failed, retrying with backoff. Cause: error creating "baremetal.cluster.gke.io/v1, Kind=Cluster": admission webhook "vcluster.kb.io" denied the request: Spec.NodeConfig.ContainerRuntime: Forbidden: Starting with Anthos Bare Metal version 1.13 Docker container runtime will not be supported. Before 1.13 please set the containerRuntime to containerd in your cluster resources. Although highly discouraged, you can create a cluster with Docker node pools until 1.13 by passing the flag "--allow-docker-container-runtime" to bmctl create cluster or add the annotation "baremetal.cluster.gke.io/allow-docker- container-runtime: true" to the cluster configuration file. Hal ini kemungkinan besar terjadi pada cluster Docker versi 1.12 yang diupgrade dari versi 1.11, karena upgrade tersebut tidak memerlukan anotasi untuk mempertahankan runtime container Docker. Dalam hal ini, cluster tidak memiliki anotasi saat mengupgrade ke versi 1.13. Perlu diperhatikan bahwa mulai versi 1.13, containerd adalah satu-satunya runtime container yang diizinkan. Solusi: Jika Anda terpengaruh oleh masalah ini, update resource cluster dengan anotasi yang hilang. Anda dapat menambahkan anotasi saat upgrade sedang berjalan atau setelah membatalkan dan sebelum mencoba upgrade lagi.
Penginstalan	1,11	bmctl keluar sebelum pembuatan cluster selesai Pembuatan cluster untuk Google Distributed Cloud versi 1.11.0 mungkin gagal (masalah ini telah diperbaiki dalam rilis Google Distributed Cloud 1.11.1). Dalam beberapa kasus, perintah bmctl create cluster akan keluar lebih awal dan menulis error seperti berikut ke log: Error creating cluster: error waiting for applied resources: provider cluster-api watching namespace USER_CLUSTER_NAME not found in the target cluster Solusi Operasi yang gagal akan menghasilkan artefak, tetapi cluster tidak dapat beroperasi. Jika masalah ini memengaruhi Anda, gunakan langkah-langkah berikut untuk membersihkan artefak dan membuat cluster: Lihat langkah-langkah solusi Untuk menghapus artefak cluster dan mereset mesin node, jalankan perintah berikut: bmctl reset -c USER_CLUSTER_NAME Untuk memulai operasi pembuatan cluster, jalankan perintah berikut: bmctl create cluster -c USER_CLUSTER_NAME \ --keep-bootstrap-cluster Flag --keep-bootstrap-cluster penting jika perintah ini gagal. Jika perintah pembuatan cluster berhasil, Anda dapat melewati langkah selanjutnya. Jika tidak, lanjutkan. Jalankan perintah berikut untuk mendapatkan versi cluster bootstrap: kubectl get cluster USER_CLUSTER_NAME \ -n USER_CLUSTER_NAMESPACE \ --kubeconfig bmctl-workspace/.kindkubeconfig \ -o=jsonpath='{.status.anthosBareMetalVersion} Outputnya harus 1.11.0. Jika output bukan 1.11.0, tunggu satu atau dua menit dan coba lagi. Untuk memindahkan resource secara manual dari cluster bootstrap ke cluster target, jalankan perintah berikut: bmctl move --from-kubeconfig bmctl-workspace/.kindkubeconfig \ --to-kubeconfig \ bmctl-workspace/USER_CLUSTER_NAME/USER_CLUSTER_NAME-kubeconfig \ -n USER_CLUSTER_NAMESPACE Untuk menghapus cluster bootstrap, jalankan perintah berikut: bmctl reset bootstrap
Penginstalan, Runtime VM di GDC	1.11, 1.12	Laporan penginstalan error rekonsiliasi runtime VM Operasi pembuatan cluster mungkin melaporkan error yang mirip dengan berikut ini: I0423 01:17:20.895640 3935589 logs.go:82] "msg"="Cluster reconciling:" "message"="Internal error occurred: failed calling webhook \"vvmruntime.kb.io\": failed to call webhook: Post \"https://vmruntime-webhook-service.kube-system.svc:443/validate-vm-cluster-gke-io-v1vmruntime?timeout=10s\": dial tcp 10.95.5.151:443: connect: connection refused" "name"="xxx" "reason"="ReconciliationError" Solusi Error ini tidak berbahaya dan Anda dapat mengabaikannya dengan aman.
Penginstalan	1.10, 1.11, 1.12	Pembuatan cluster gagal saat menggunakan proxy multi-NIC, containerd, dan HTTPS Pembuatan cluster akan gagal jika Anda memiliki kombinasi kondisi berikut: Cluster dikonfigurasi untuk menggunakan containerd sebagai runtime container (nodeConfig.containerRuntime ditetapkan ke containerd dalam file konfigurasi cluster, default untuk Google Distributed Cloud versi 1.13 dan yang lebih baru). Cluster dikonfigurasi untuk menyediakan beberapa antarmuka jaringan, multi-NIC, untuk pod (clusterNetwork.multipleNetworkInterfaces ditetapkan ke true dalam file konfigurasi cluster). Cluster dikonfigurasi untuk menggunakan proxy (spec.proxy.url ditentukan dalam file konfigurasi cluster). Meskipun pembuatan cluster gagal, setelan ini diterapkan saat Anda mencoba membuat cluster. Anda mungkin melihat setelan proxy ini sebagai variabel lingkungan HTTPS_PROXY atau dalam konfigurasi containerd (/etc/systemd/system/containerd.service.d/09-proxy.conf). Solusi Tambahkan CIDR layanan (clusterNetwork.services.cidrBlocks) ke variabel lingkungan NO_PROXY di semua komputer node.
Penginstalan	1.10, 1.11, 1.12	Kegagalan pada sistem dengan setelan umask yang ketat Rilis Google Distributed Cloud 1.10.0 memperkenalkan fitur bidang kontrol rootless yang menjalankan semua komponen bidang kontrol sebagai pengguna non-root. Menjalankan semua komponen sebagai pengguna non-root dapat menyebabkan kegagalan penginstalan atau upgrade pada sistem dengan setelan umask 0077 yang lebih ketat. Solusi Reset node bidang kontrol dan ubah setelan umask menjadi 0022 di semua mesin bidang kontrol. Setelah komputer diupdate, coba lagi penginstalan. Atau, Anda dapat mengubah izin direktori dan file /etc/kubernetes pada mesin bidang kontrol untuk penginstalan atau upgrade untuk melanjutkan. Buat /etc/kubernetes dan semua subdirektorinya dapat dibaca: chmod o+rx. Jadikan semua file milik pengguna root di bawah direktori (rekursif) /etc/kubernetes yang dapat dibaca dunia (chmod o+r). Kecualikan file kunci pribadi (.key) dari perubahan ini karena file tersebut sudah dibuat dengan kepemilikan dan izin yang benar. Jadikan bahasa /usr/local/etc/haproxy/haproxy.cfg mudah dibaca. Jadikan /usr/local/etc/bgpadvertiser/bgpadvertiser-cfg.yaml dapat dibaca.
Penginstalan	1.10, 1.11, 1.12, 1.13	Inkompatibilitas grup kontrol v2 Grup kontrol v2 (cgroup v2) tidak didukung di cluster Google Distributed Cloud versi 1.13 dan Google Distributed Cloud yang lebih lama. Namun, versi 1.14 mendukung cgroup v2 sebagai fitur Pratinjau . Keberadaan /sys/fs/cgroup/cgroup.controllers menunjukkan bahwa sistem Anda menggunakan cgroup v2. Solusi Jika sistem Anda menggunakan cgroup v2, upgrade cluster Anda ke versi 1.14.
Penginstalan	1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28, 1.29	Pemeriksaan preflight dan kredensial akun layanan Untuk penginstalan yang dipicu oleh admin atau cluster hybrid (dengan kata lain, cluster yang tidak dibuat dengan bmctl, seperti cluster pengguna), pemeriksaan preflight tidak memverifikasi kredensial akun layanan Google Cloud atau izin yang terkait.
Penginstalan	1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28, 1.29	Menginstal di vSphere Saat menginstal cluster Google Distributed Cloud pada VM vSphere, Anda harus menonaktifkan flag tx-udp_tnl-segmentation dan tx-udp_tnl-csum-segmentation. Flag ini berkaitan dengan pengurangan beban segmentasi hardware yang dilakukan oleh driver vSphere VMXNET3 dan flag tersebut tidak berfungsi dengan tunnel GENEVE dari cluster Google Distributed Cloud. Solusi Jalankan perintah berikut pada setiap node guna memeriksa nilai saat ini untuk flag ini: ethtool -k NET_INTFC | grep segm Ganti NET_INTFC dengan antarmuka jaringan yang terkait dengan alamat IP node. Respons harus memiliki entri seperti berikut: ... tx-udp_tnl-segmentation: on tx-udp_tnl-csum-segmentation: on ... Terkadang dalam RHEL 8.4, ethtool menunjukkan tanda ini nonaktif, sedangkan tidak. Untuk menonaktifkan tanda ini secara eksplisit, aktifkan lalu nonaktifkan tanda dengan perintah berikut: ethtool -K ens192 tx-udp_tnl-segmentation on ethtool -K ens192 \ tx-udp_tnl-csum-segmentation on ethtool -K ens192 tx-udp_tnl-segmentation off ethtool -K ens192 \ tx-udp_tnl-csum-segmentation off Perubahan tanda ini tidak akan dipertahankan setiap kali dimulai ulang. Konfigurasikan skrip startup untuk menetapkan flag ini secara eksplisit saat sistem melakukan booting.
Upgrade dan update	1.10	bmctl tidak dapat membuat, mengupdate, atau mereset cluster pengguna dengan versi yang lebih rendah CLI bmctl tidak dapat membuat, mengupdate, atau mereset cluster pengguna dengan versi minor yang lebih rendah, terlepas dari versi cluster admin. Misalnya, Anda tidak dapat menggunakan bmctl dengan versi 1.N.X untuk mereset cluster pengguna versi 1.N-1.Y, meskipun cluster admin juga berada dalam versi 1.N.X. Jika terpengaruh oleh masalah ini, Anda akan melihat log yang serupa dengan berikut ini saat menggunakan bmctl: [2022-06-02 05:36:03-0500] error judging if the cluster is managing itself: error to parse the target cluster: error parsing cluster config: 1 error occurred: * cluster version 1.8.1 isn't supported in bmctl version 1.9.5, only cluster version 1.9.5 is supported Solusi: Gunakan kubectl untuk membuat, mengedit, atau menghapus resource kustom cluster pengguna di dalam cluster admin. Kemampuan untuk mengupgrade cluster pengguna tidak terpengaruh.
Upgrade dan update	1.12	Upgrade cluster ke versi 1.12.1 mungkin terhenti Upgrade cluster ke versi 1.12.1 terkadang terhenti karena server API tidak tersedia. Masalah ini memengaruhi semua jenis cluster dan semua sistem operasi yang didukung. Saat masalah ini terjadi, perintah bmctl upgrade cluster dapat gagal di beberapa titik, termasuk selama fase kedua pemeriksaan preflight. Solusi Anda dapat memeriksa log upgrade untuk mengetahui apakah Anda terpengaruh oleh masalah ini. Log upgrade berada di /baremetal/bmctl-workspace/CLUSTER_NAME/log/upgrade-cluster-TIMESTAMP secara default. upgrade-cluster.log mungkin berisi error seperti berikut: Failed to upgrade cluster: preflight checks failed: preflight check failed Log mesin mungkin berisi error seperti berikut (kegagalan berulang menunjukkan bahwa Anda terpengaruh oleh masalah ini): FAILED - RETRYING: Query CNI health endpoint (30 retries left). FAILED - RETRYING: Query CNI health endpoint (29 retries left). FAILED - RETRYING: Query CNI health endpoint (28 retries left). ... HAProxy dan Keepahidup harus berjalan pada setiap node bidang kontrol sebelum Anda mencoba mengupgrade cluster ke versi 1.12.1 lagi. Gunakan antarmuka command line crictl pada setiap node untuk memeriksa apakah container haproxy dan keepalived berjalan: docker/crictl ps | grep haproxy docker/crictl ps | grep keepalived Jika HAProxy atau Keepahidup tidak berjalan pada node, mulai ulang kubelet pada node: systemctl restart kubelet
Upgrade dan update, Runtime VM di GDC	1.11, 1.12	Upgrade cluster ke versi 1.12.0 atau yang lebih tinggi akan gagal saat VM Runtime di GDC diaktifkan Pada cluster Google Distributed Cloud versi 1.12.0, semua resource yang terkait dengan Runtime VM pada GDC dimigrasikan ke namespace vm-system untuk lebih mendukung Runtime VM pada rilis GA GDC. Jika Anda mengaktifkan VM Runtime di GDC dalam cluster versi 1.11.x atau yang lebih rendah, upgrade ke versi 1.12.0 atau yang lebih tinggi akan gagal, kecuali jika Anda terlebih dahulu menonaktifkan Runtime VM di GDC. Jika Anda terpengaruh oleh masalah ini, operasi upgrade akan melaporkan error berikut: Failed to upgrade cluster: cluster isn't upgradable with vmruntime enabled from version 1.11.x to version 1.12.0: please disable VMruntime before upgrade to 1.12.0 and higher version Solusi Untuk menonaktifkan Runtime VM di GDC: Edit resource kustom VMRuntime: kubectl edit vmruntime Tetapkan enabled ke false dalam spesifikasi: apiVersion: vm.cluster.gke.io/v1 kind: VMRuntime metadata: name: vmruntime spec: enabled: false ... Simpan resource kustom di editor Anda. Setelah upgrade cluster selesai, aktifkan kembali Runtime VM di GDC. Untuk mengetahui informasi selengkapnya, lihat Menangani workload berbasis VM.
Upgrade dan update	1.10, 1.11, 1.12	Upgrade macet di error during manifests operations Dalam beberapa situasi, upgrade cluster gagal diselesaikan dan CLI bmctl menjadi tidak responsif. Masalah ini dapat disebabkan oleh resource yang diperbarui dengan tidak benar. Untuk mengetahui apakah Anda terpengaruh oleh masalah ini dan untuk memperbaikinya, periksa log anthos-cluster-operator dan cari error yang mirip dengan entri berikut: controllers/Cluster "msg"="error during manifests operations" "error"="1 error occurred: ... {RESOURCE_NAME} is invalid: metadata.resourceVersion: Invalid value: 0x0: must be specified for an update Entri ini adalah gejala dari resource yang salah diperbarui, dengan {RESOURCE_NAME} adalah nama resource masalah. Solusi Jika Anda menemukan error ini di log, selesaikan langkah-langkah berikut: Gunakan kubectl edit untuk menghapus anotasi kubectl.kubernetes.io/last-applied-configuration dari resource yang dimuat dalam pesan log. Simpan dan terapkan perubahan pada resource. Coba upgrade cluster lagi.
Upgrade dan update	1.10, 1.11, 1.12	Upgrade diblokir untuk cluster dengan fitur yang menggunakan Gateway Jaringan untuk GDC Upgrade cluster dari 1.10.x ke 1.11.x akan gagal untuk cluster yang menggunakan gateway NAT keluar atau load balancing paket dengan BGP. Fitur ini menggunakan Gateway Jaringan untuk GDC. Upgrade cluster macet pada pesan command line Waiting for upgrade to complete... dan anthos-cluster-operator mencatat error seperti berikut: apply run failed ... MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable... Solusi Perhatian: Solusi berikut menghapus manifes dan menyebabkan periode nonaktif singkat selama 30–60 detik untuk paket load balancing dengan BGP. Sesi BGP dihentikan dan diaktifkan kembali, dan layanan LoadBalancer tidak tersedia selama periode ini. Fungsi dipulihkan saat anthos-cluster-operator menginstal ulang manifes. Untuk berhenti memblokir upgrade, jalankan perintah berikut terhadap cluster yang sedang Anda upgrade: kubectl -n kube-system delete deployment \ ang-controller-manager-autoscaler kubectl -n kube-system delete deployment \ ang-controller-manager kubectl -n kube-system delete ds ang-node
Upgrade dan update	1.10, 1.11, 1.12, 1.13, 1.14, 1.15	bmctl update tidak menghapus pemblokiran pemeliharaan Perintah bmctl update tidak dapat menghapus atau mengubah bagian maintenanceBlocks dari konfigurasi resource cluster. Solusi Untuk informasi selengkapnya, termasuk petunjuk untuk menghapus node dari mode pemeliharaan, lihat Memasukkan node ke mode pemeliharaan.
Operasi	1.10, 1.11, 1.12	Node dapat dilepas jika Anda tidak menggunakan prosedur mode pemeliharaan Jika Anda menjalankan cluster versi 1.12.0 (anthosBareMetalVersion: 1.12.0) atau yang lebih rendah dan menggunakan kubectl cordon secara manual pada node, Google Distributed Cloud mungkin akan berhenti memblokir node sebelum Anda siap untuk merekonsiliasi status yang diharapkan. Solusi Untuk cluster versi 1.12.0 dan yang lebih rendah, gunakan mode pemeliharaan untuk memblokir dan menguras node dengan aman. Pada versi 1.12.1 (anthosBareMetalVersion: 1.12.1) atau yang lebih tinggi, Google Distributed Cloud tidak akan melepaskan node Anda secara tidak terduga saat Anda menggunakan kubectl cordon.
Operasi	1,11	Cluster admin versi 11 yang menggunakan duplikasi registry tidak dapat mengelola cluster versi 1.10 Jika cluster admin Anda menggunakan versi 1.11 dan menggunakan registry duplikasi, cluster tersebut tidak dapat mengelola cluster pengguna yang menggunakan versi minor lebih rendah. Masalah ini memengaruhi operasi reset, update, dan upgrade di cluster pengguna. Untuk menentukan apakah masalah ini memengaruhi Anda, periksa operasi cluster di log, seperti buat, upgrade, atau reset. Log ini secara default terletak di folder bmctl-workspace/CLUSTER_NAME/. Jika Anda terpengaruh oleh masalah ini, log Anda akan berisi pesan error berikut: flag provided but not defined: -registry-mirror-host-to-endpoints
Operasi	1.10, 1.11	Rahasia kubeconfig ditimpa Saat dijalankan di cluster pengguna, perintah bmctl check cluster akan menimpa Secret kubeconfig cluster pengguna dengan kubeconfig cluster admin. Menimpa file akan menyebabkan operasi cluster standar, seperti update dan upgrade, gagal untuk cluster pengguna yang terpengaruh. Masalah ini berlaku untuk cluster Google Distributed Cloud versi 1.11.1 dan yang lebih lama. Untuk mengetahui apakah masalah ini memengaruhi cluster pengguna, jalankan perintah berikut: kubectl --kubeconfig ADMIN_KUBECONFIG \ get secret -n USER_CLUSTER_NAMESPACE \ USER_CLUSTER_NAME -kubeconfig \ -o json | jq -r '.data.value' | base64 -d Ganti kode berikut: ADMIN_KUBECONFIG: jalur ke file kubeconfig cluster admin. USER_CLUSTER_NAMESPACE: namespace untuk cluster. Secara default, namespace cluster untuk cluster Google Distributed Cloud adalah nama cluster yang diawali dengan cluster-. Misalnya, jika Anda memberi nama cluster test, namespace default-nya adalah cluster-test. USER_CLUSTER_NAME: nama cluster pengguna yang akan diperiksa. Jika nama cluster dalam output (lihat contexts.context.cluster dalam contoh output berikut) adalah nama cluster admin, cluster pengguna yang ditentukan akan terpengaruh. apiVersion: v1 clusters: - cluster: certificate-authority-data:LS0tLS1CRU...UtLS0tLQo= server: https://10.200.0.6:443 name: ci-aed78cdeca81874 contexts: - context: cluster: ci-aed78cdeca81 user: ci-aed78cdeca81-admin name: ci-aed78cdeca81-admin@ci-aed78cdeca81 current-context: ci-aed78cdeca81-admin@ci-aed78cdeca81 kind: Config preferences: {} users: - name: ci-aed78cdeca81-admin user: client-certificate-data: LS0tLS1CRU...UtLS0tLQo= client-key-data: LS0tLS1CRU...0tLS0tCg== Solusi Langkah-langkah berikut akan memulihkan fungsi ke cluster pengguna yang terpengaruh (USER_CLUSTER_NAME): Cari file kubeconfig cluster pengguna. Google Distributed Cloud menghasilkan file kubeconfig di workstation admin saat Anda membuat cluster. Secara default, file ini berada di direktori bmctl-workspace/USER_CLUSTER_NAME. Pastikan bahwa kubeconfig adalah kubeconfig cluster pengguna yang benar: kubectl get nodes \ --kubeconfig PATH_TO_GENERATED_FILE Ganti PATH_TO_GENERATED_FILE dengan jalur ke file kubeconfig cluster pengguna. Responsnya menampilkan detail tentang node untuk cluster pengguna. Pastikan nama mesin sudah benar untuk cluster Anda. Jalankan perintah berikut untuk menghapus file kubeconfig yang rusak di cluster admin: kubectl delete secret \ -n USER_CLUSTER_NAMESPACE \ USER_CLUSTER_NAME-kubeconfig Jalankan perintah berikut untuk menyimpan kembali rahasia kubeconfig yang benar ke cluster admin: kubectl create secret generic \ -n USER_CLUSTER_NAMESPACE \ USER_CLUSTER_NAME-kubeconfig \ --from-file=value=PATH_TO_GENERATED_FILE
Operasi	1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28, 1.29	Mengambil snapshot sebagai pengguna login non-root Jika Anda menggunakan containerd sebagai runtime container, menjalankan snapshot sebagai pengguna non-root akan mengharuskan /usr/local/bin berada dalam PATH pengguna. Jika tidak, sistem akan gagal dengan error crictl: command not found. Jika Anda tidak login sebagai pengguna root, sudo digunakan untuk menjalankan perintah snapshot. sudo PATH dapat berbeda dari profil root dan tidak boleh berisi /usr/local/bin. Solusi Update secure_path di /etc/sudoers untuk menyertakan /usr/local/bin. Atau, buat link simbolis untuk crictl di direktori /bin lain.
Logging dan pemantauan	1.10	stackdriver-log-forwarder memiliki [parser:cri] invalid time format log peringatan Jika Parser antarmuka runtime container (CRI) menggunakan ekspresi reguler yang salah untuk waktu penguraian, log untuk Pod stackdriver-log-forwarder akan berisi error dan peringatan seperti berikut: [2022/03/04 17:47:54] [error] [parser] time string length is too long [2022/03/04 20:16:43] [ warn] [parser:cri] invalid time format %Y-%m-%dT%H:%M:%S.%L%z for '2022-03-04T20:16:43.680484387Z' Solusi: Lihat langkah-langkah solusi Upgrade cluster Anda ke versi 1.11.0 atau yang lebih baru. Jika Anda tidak dapat langsung mengupgrade cluster, gunakan langkah-langkah berikut untuk memperbarui ekspresi reguler penguraian CRI: Untuk mencegah pengembalian perubahan berikut, perkecil skala stackdriver-operator: kubectl --kubeconfig KUBECONFIG \ -n kube-system scale deploy \ stackdriver-operator --replicas=0 Edit entri Regex di stackdriver-log-forwarder-config ConfigMap: kubectl --kubeconfig KUBECONFIG \ -n kube-system edit configmap \ stackdriver-log-forwarder-config Resource yang diedit akan terlihat seperti berikut: [PARSER] # https://rubular.com/r/Vn30bO78GlkvyB Name cri Format regex # The timestamp is described in https://www.rfc-editor.org/rfc/rfc3339#section-5.6 Regex ^(?<time>[0-9]{4}-[0-9]{2}-[0-9]{2}[Tt ][0-9] {2}:[0-9]{2}:[0-9]{2}(?:\.[0-9]+)?(?:[Zz]|[+-][0-9] {2}:[0-9]{2})) (?<stream>stdout|stderr) (?<logtag>[^ ]*) (?<log>.*)$ Time_Key time Time_Format %Y-%m-%dT%H:%M:%S.%L%z Time_Keep off Mulai ulang pod penerus log: kubectl --kubeconfig KUBECONFIG \ -n kube-system rollout restart daemonset \ stackdriver-log-forwarder
Logging dan pemantauan	1.10, 1.11, 1.12, 1.13, 1.14, 1.15	Penagihan pemantauan yang tidak terduga Untuk cluster Google Distributed Cloud versi 1.10 hingga 1.15, beberapa pelanggan mendapati adanya penagihan tinggi yang tidak terduga untuk Metrics volume di halaman Billing. Masalah ini hanya memengaruhi Anda jika semua keadaan berikut terjadi: Pemantauan aplikasi diaktifkan (enableStackdriverForApplications=true) Managed Service for Prometheus tidak diaktifkan (enableGMPForApplications) Pod Aplikasi memiliki anotasi prometheus.io/scrap=true Untuk mengonfirmasi apakah Anda terpengaruh oleh masalah ini, cantumkan metrik yang ditentukan pengguna. Jika Anda melihat penagihan untuk metrik yang tidak diinginkan, berarti masalah ini berlaku untuk Anda. Solusi Jika Anda mengalami masalah ini, sebaiknya upgrade cluster Anda ke versi 1.12 dan beralih ke solusi pemantauan aplikasi baru managed-service-for-prometheus yang mengatasi masalah ini: Flag terpisah untuk mengontrol pengumpulan log aplikasi versus metrik aplikasi Paket Google Cloud Managed Service for Prometheus Jika Anda tidak dapat mengupgrade ke versi 1.12, gunakan langkah-langkah berikut: Temukan Pod dan Layanan sumber yang memiliki penagihan yang tidak diinginkan: kubectl --kubeconfig KUBECONFIG \ get pods -A -o yaml | grep 'prometheus.io/scrape: "true"' kubectl --kubeconfig KUBECONFIG get \ services -A -o yaml | grep 'prometheus.io/scrape: "true"' Hapus anotasi prometheus.io/scrap=true dari Pod atau Service.
Logging dan pemantauan	1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28	Pengeditan pada metrics-server-config tidak dipertahankan Dalam kasus yang ekstrem, kepadatan pod yang tinggi dapat menimbulkan overhead logging dan pemantauan yang berlebihan, yang dapat menyebabkan Metrics Server berhenti dan dimulai ulang. Anda dapat mengedit metrics-server-config ConfigMap untuk mengalokasikan lebih banyak resource agar Metrics Server tetap berjalan. Namun, karena rekonsiliasi, edit yang dilakukan pada metrics-server-config dapat dikembalikan ke nilai default selama update cluster atau operasi upgrade. Metrics Server tidak langsung terpengaruh, tetapi saat dimulai ulang lagi, server akan mengambil ConfigMap yang dikembalikan dan rentan terhadap overhead yang berlebihan. Solusi Untuk 1.11.x, Anda dapat membuat skrip untuk mengedit ConfigMap dan melakukannya bersama dengan update atau upgrade pada cluster. Untuk 1.12 dan seterusnya, hubungi dukungan.
Logging dan pemantauan	1.11, 1.12	Metrik yang tidak digunakan lagi memengaruhi dasbor Cloud Monitoring Beberapa GKE pada metrik Bare Metal sudah tidak digunakan lagi dan, mulai dari rilis Google Distributed Cloud 1.11, data tidak lagi dikumpulkan untuk metrik yang tidak digunakan lagi ini. Jika Anda menggunakan metrik ini di salah satu kebijakan pemberitahuan, tidak akan ada data untuk memicu kondisi pemberitahuan. Tabel berikut mencantumkan setiap metrik yang tidak digunakan lagi dan metrik yang menggantikannya. Metrik yang tidak digunakan lagi Metrik penggantian kube_daemonset_updated_number_scheduled kube_daemonset_status_updated_number_scheduled kube_node_status_allocatable_cpu_cores kube_node_status_allocatable_memory_bytes kube_node_status_allocatable_pods kube_node_status_allocatable kube_node_status_capacity_cpu_cores kube_node_status_capacity_memory_bytes kube_node_status_capacity_pods kube_node_status_capacity Dalam versi cluster Google Distributed Cloud yang lebih rendah dari 1.11, file definisi kebijakan untuk pemberitahuan Anthos on baremetal node cpu usage exceeds 80 percent (critical) yang direkomendasikan menggunakan metrik yang tidak digunakan lagi. File definisi JSON node-cpu-usage-high.json diperbarui untuk rilis 1.11.0 dan yang lebih baru. Solusi Gunakan langkah-langkah berikut untuk bermigrasi ke metrik pengganti: Di konsol Google Cloud, pilih Monitoring atau klik tombol berikut: Buka Monitoring Di panel navigasi, pilih Dashboards, lalu hapus dasbor Anthos cluster node status. Klik tab Sample library dan instal ulang dasbor Anthos cluster node status. Ikuti petunjuk dalam Membuat kebijakan pemberitahuan untuk membuat kebijakan menggunakan file definisi kebijakan node-cpu-usage-high.json yang telah diperbarui.
Logging dan pemantauan	1.10, 1.11	stackdriver-log-forwarder memiliki CrashloopBackOff error Dalam beberapa situasi, agen logging fluent-bit dapat macet saat memproses potongan yang rusak. Jika agen logging tidak dapat mengabaikan potongan yang rusak, Anda mungkin mengamati bahwa stackdriver-log-forwarder terus mengalami error dengan error CrashloopBackOff. Jika Anda mengalami masalah ini, log Anda memiliki entri seperti berikut [2022/03/09 02:18:44] [engine] caught signal (SIGSEGV) #0 0x5590aa24bdd5 in validate_insert_id() at plugins/out_stackdriver/stackdriver.c:1232 #1 0x5590aa24c502 in stackdriver_format() at plugins/out_stackdriver/stackdriver.c:1523 #2 0x5590aa24e509 in cb_stackdriver_flush() at plugins/out_stackdriver/stackdriver.c:2105 #3 0x5590aa19c0de in output_pre_cb_flush() at include/fluent-bit/flb_output.h:490 #4 0x5590aa6889a6 in co_init() at lib/monkey/deps/flb_libco/amd64.c:117 #5 0xffffffffffffffff in ???() at ???:0 Solusi: Membersihkan potongan buffer untuk Stackdriver Log Forwarder. Catatan: Dalam perintah berikut, ganti KUBECONFIG dengan jalur ke file kubeconfig cluster admin. Hentikan semua pod stackdriver-log-forwarder: kubectl --kubeconfig KUBECONFIG -n kube-system patch daemonset \ stackdriver-log-forwarder -p \ '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}' Pastikan bahwa pod stackdriver-log-forwarder telah dihapus sebelum melanjutkan ke langkah berikutnya. Deploy DaemonSet berikut untuk membersihkan data yang rusak di buffer fluent-bit: kubectl --kubeconfig KUBECONFIG -n kube-system apply -f - << EOF apiVersion: apps/v1 kind: DaemonSet metadata: name: fluent-bit-cleanup namespace: kube-system spec: selector: matchLabels: app: fluent-bit-cleanup template: metadata: labels: app: fluent-bit-cleanup spec: containers: - name: fluent-bit-cleanup image: debian:10-slim command: ["bash", "-c"] args: - | rm -rf /var/log/fluent-bit-buffers/ echo "Fluent Bit local buffer is cleaned up." sleep 3600 volumeMounts: - name: varlog mountPath: /var/log securityContext: privileged: true tolerations: - key: "CriticalAddonsOnly" operator: "Exists" - key: node-role.kubernetes.io/master effect: NoSchedule - key: node-role.gke.io/observability effect: NoSchedule volumes: - name: varlog hostPath: path: /var/log EOF Gunakan perintah berikut untuk memverifikasi bahwa DaemonSet telah membersihkan semua node: kubectl --kubeconfig KUBECONFIG logs \ -n kube-system -l \ app=fluent-bit-cleanup | grep "cleaned up" | wc -l kubectl --kubeconfig KUBECONFIG -n \ kube-system get pods -l \ app=fluent-bit-cleanup --no-headers | wc -l Output dari kedua perintah tersebut harus sama dengan jumlah node di cluster Anda. Hapus DaemonSet pembersihan: kubectl --kubeconfig KUBECONFIG -n \ kube-system delete ds fluent-bit-cleanup Mulai ulang pod penerus log: kubectl --kubeconfig KUBECONFIG \ -n kube-system patch daemonset \ stackdriver-log-forwarder --type json \ -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'
Logging dan pemantauan	1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28	Error metrik tidak dikenal di log gke-metrics-agent gke-metrics-agent adalah daemonset yang mengumpulkan metrik pada setiap node dan meneruskannya ke Cloud Monitoring. Proses ini dapat menghasilkan log seperti berikut: Unknown metric: kubernetes.io/anthos/go_gc_duration_seconds_summary_percentile Error serupa dapat terjadi pada jenis metrik lainnya, termasuk (tetapi tidak terbatas pada): apiserver_admission_step_admission_duration_seconds_summary go_gc_duration_seconds scheduler_scheduling_duration_seconds gkeconnect_http_request_duration_seconds_summary alertmanager_nflog_snapshot_duration_seconds_summary Log error ini dapat diabaikan dengan aman karena metrik yang dirujuknya tidak didukung dan tidak penting untuk tujuan pemantauan.
Logging dan pemantauan	1.10, 1.11	Gangguan ekspor metrik yang terputus-putus Cluster Google Distributed Cloud mungkin mengalami gangguan pada ekspor metrik normal atau secara terus-menerus, atau metrik yang hilang di beberapa node. Jika masalah ini memengaruhi cluster, Anda mungkin akan melihat kesenjangan data untuk metrik berikut (minimal): kubernetes.io/anthos/container_memory_working_set_bytes kubernetes.io/anthos/container_cpu_usage_seconds_total kubernetes.io/anthos/container_network_receive_bytes_total Solusi Upgrade cluster Anda ke versi 1.11.1 atau yang lebih baru. Jika Anda tidak dapat melakukan upgrade, lakukan langkah-langkah berikut sebagai solusinya: Buka referensi stackdriver Anda untuk mengedit: kubectl -n kube-system edit stackdriver stackdriver Guna meningkatkan permintaan CPU untuk gke-metrics-agent dari 10m ke 50m, tambahkan bagian resourceAttrOverride berikut ke manifes stackdriver: spec: resourceAttrOverride: gke-metrics-agent/gke-metrics-agent: limits: cpu: 100m memory: 4608Mi requests: cpu: 50m memory: 200Mi Resource yang diedit akan terlihat seperti berikut: spec: anthosDistribution: baremetal clusterLocation: us-west1-a clusterName: my-cluster enableStackdriverForApplications: true gcpServiceAccountSecretName: ... optimizedMetrics: true portable: true projectID: my-project-191923 proxyConfigSecretName: ... resourceAttrOverride: gke-metrics-agent/gke-metrics-agent: limits: cpu: 100m memory: 4608Mi requests: cpu: 50m memory: 200Mi Simpan perubahan Anda dan tutup editor teks. Untuk memastikan bahwa perubahan Anda telah diterapkan, jalankan perintah berikut: kubectl -n kube-system get daemonset \ gke-metrics-agent -o yaml | grep "cpu: 50m" Perintah ini akan menemukan cpu: 50m jika hasil edit Anda telah diterapkan.
Networking	1.10	Beberapa gateway default memutus konektivitas ke endpoint eksternal Memiliki beberapa gateway default dalam node dapat menyebabkan gangguan konektivitas dari dalam Pod ke endpoint eksternal, seperti google.com. Untuk mengetahui apakah Anda terpengaruh oleh masalah ini, jalankan perintah berikut pada node: ip route show Beberapa instance default dalam respons menunjukkan bahwa Anda terpengaruh.
Networking	1.12	Pengeditan resource kustom jaringan pada cluster pengguna akan ditimpa Cluster Google Distributed Cloud versi 1.12.x tidak mencegah Anda mengedit resource kustom jaringan secara manual di cluster pengguna. Google Distributed Cloud merekonsiliasi resource kustom di cluster pengguna dengan resource kustom di cluster admin Anda selama upgrade cluster. Rekonsiliasi ini akan menimpa setiap edit yang dilakukan langsung pada resource kustom jaringan di cluster pengguna. Resource kustom jaringan hanya boleh diubah di cluster admin, tetapi cluster versi 1.12.x tidak menerapkan persyaratan ini. Fitur jaringan lanjutan, seperti load balancing paket dengan BGP, gateway NAT keluar, jaringan SR-IOV, mode datar dengan BGP, dan multi-NIC untuk Pod menggunakan resource kustom berikut: BGPLoadBalancer BGPPeer NetworkGatewayGroup NetworkAttachmentDefinition ClusterCIDRConfig FlatIPMode Edit resource kustom ini di cluster admin dan langkah rekonsiliasi akan menerapkan perubahan pada cluster pengguna Anda. Solusi Jika Anda telah mengubah salah satu resource kustom yang disebutkan sebelumnya pada cluster pengguna, ubah resource kustom terkait di cluster admin Anda agar sesuai sebelum melakukan upgrade. Langkah ini memastikan bahwa perubahan konfigurasi Anda dipertahankan. Cluster Google Distributed Cloud versi 1.13.0 dan yang lebih baru tidak mengizinkan Anda mengubah resource kustom jaringan di cluster pengguna secara langsung.
Networking	1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28	Kegagalan konektivitas pod dan pemfilteran jalur terbalik Google Distributed Cloud mengonfigurasi pemfilteran jalur terbalik pada node untuk menonaktifkan validasi sumber (net.ipv4.conf.all.rp_filter=0). Jika setelan rp_filter diubah ke 1 atau 2, pod akan gagal karena waktu tunggu komunikasi di luar node. Pemfilteran jalur terbalik ditetapkan dengan file rp_filter di folder konfigurasi IPv4 (net/ipv4/conf/all). Nilai ini juga dapat diganti oleh sysctl, yang menyimpan setelan pemfilteran jalur terbalik dalam file konfigurasi keamanan jaringan, seperti /etc/sysctl.d/60-gce-network-security.conf. Solusi Konektivitas pod dapat dipulihkan dengan melakukan salah satu solusi berikut: Tetapkan nilai untuk net.ipv4.conf.all.rp_filter kembali ke 0 secara manual, lalu jalankan sudo sysctl -p untuk menerapkan perubahan. Atau Mulai ulang Pod anetd untuk menetapkan net.ipv4.conf.all.rp_filter kembali ke 0. Untuk memulai ulang Pod anetd, gunakan perintah berikut untuk menemukan dan menghapus Pod anetd, lalu Pod anetd baru akan dimulai sebagai penggantinya: kubectl get pods -n kube-system kubectl delete pods -n kube-system ANETD_XYZ Ganti ANETD_XYZ dengan nama Pod anetd. Setelah melakukan salah satu solusi tersebut, verifikasi bahwa nilai net.ipv4.conf.all.rp_filter ditetapkan ke 0 dengan menjalankan sysctl net.ipv4.conf.all.rp_filter di setiap node.
Networking	1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28, 1.29	Alamat IP cluster bootstrap (jenis) dan alamat IP node cluster tumpang-tindih 192.168.122.0/24 dan 10.96.0.0/27 adalah pod dan CIDR layanan default yang digunakan oleh cluster bootstrap. Pemeriksaan preflight akan gagal jika tumpang-tindih dengan alamat IP mesin node cluster. Solusi Untuk menghindari konflik, Anda dapat meneruskan flag --bootstrap-cluster-pod-cidr dan --bootstrap-cluster-service-cidr ke bmctl untuk menentukan nilai yang berbeda.
Sistem operasi	1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28	Pembuatan atau upgrade cluster gagal di CentOS Pada Desember 2020, komunitas CentOS dan Red Hat mengumumkan penghentian CentOS. Pada 31 Januari 2022, CentOS 8 mencapai akhir siklus prosesnya (EOL). Akibat EOL, repositori yum berhenti berfungsi untuk CentOS, yang menyebabkan pembuatan cluster dan operasi upgrade cluster gagal. Hal ini berlaku untuk semua versi CentOS yang didukung dan memengaruhi semua versi cluster Google Distributed Cloud. Solusi Lihat langkah-langkah solusi Sebagai solusinya, jalankan perintah berikut agar CentOS Anda menggunakan feed arsip: sed -i 's/mirrorlist/#mirrorlist/g' /etc/yum.repos.d/CentOS-Linux-* sed -i 's|#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' \ /etc/yum.repos.d/CentOS-Linux-* Sebagai solusi jangka panjang, pertimbangkan untuk bermigrasi ke sistem operasi lain yang didukung.
Keamanan	1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28	Container tidak dapat menulis ke VOLUME yang ditentukan di Dockerfile dengan containerd dan SELinux Jika Anda menggunakan container sebagai runtime container dan sistem operasi Anda telah mengaktifkan SELinux, VOLUME yang ditetapkan dalam Dockerfile aplikasi mungkin tidak dapat ditulis. Misalnya, container yang dibangun dengan Dockerfile berikut tidak dapat menulis ke folder /tmp. FROM ubuntu:20.04 RUN chmod -R 777 /tmp VOLUME /tmp Untuk memastikan apakah Anda terpengaruh oleh masalah ini, jalankan perintah berikut pada node yang menghosting container bermasalah: ausearch -m avc Jika terpengaruh oleh masalah ini, Anda akan melihat error denied seperti berikut: time->Mon Apr 4 21:01:32 2022 type=PROCTITLE msg=audit(1649106092.768:10979): proctitle="bash" type=SYSCALL msg=audit(1649106092.768:10979): arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=55eeba72b320 a2=241 a3=1b6 items=0 ppid=75712 pid=76042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=4294967295 comm="bash" exe="/usr/bin/bash" subj=system_u:system_r:container_t:s0:c701,c935 key=(null) type=AVC msg=audit(1649106092.768:10979): avc: denied { write } for pid=76042 comm="bash" name="aca03d7bb8de23c725a86cb9f50945664cb338dfe6ac19ed0036c" dev="sda2" ino=369501097 scontext=system_u:system_r: container_t:s0:c701,c935 tcontext=system_u:object_r: container_ro_file_t:s0 tclass=dir permissive=0 Solusi Untuk mengatasi masalah ini, lakukan salah satu perubahan berikut: Nonaktifkan SELinux. Jangan gunakan fitur VOLUME di dalam Dockerfile.
Upgrade dan update	1.10, 1.11, 1.12	Pendeteksi Masalah Node tidak diaktifkan secara default setelah upgrade cluster Saat Anda mengupgrade cluster Google Distributed Cloud, Detektor Masalah Node tidak diaktifkan secara default. Masalah ini berlaku untuk upgrade dalam rilis 1.10 ke 1.12.1 dan telah diperbaiki dalam rilis 1.12.2. Solusi: Untuk mengaktifkan Detektor Masalah Node: Verifikasi apakah layanan node-problem-detector systemd berjalan di node. Gunakan perintah SSH, lalu hubungkan ke node. Periksa apakah layanan node-problem-detector systemd berjalan pada node: systemctl is-active node-problem-detector Jika hasil perintah menampilkan inactive, berarti node-problem-detector tidak berjalan pada node. Untuk mengaktifkan Node Problem Detector, gunakan perintah kubectl edit dan edit node-problem-detector-config ConfigMap. Untuk informasi selengkapnya, lihat Pendeteksi Masalah Node.
Operasi	1,9, 1,10	Pencadangan cluster gagal saat menggunakan login non-root Perintah bmctl backup cluster akan gagal jika nodeAccess.loginUser ditetapkan ke nama pengguna non-root.] Solusi: Masalah ini berlaku untuk versi 1.9.x, 1.10.0, serta 1.10.1 dan telah diperbaiki dalam versi 1.10.2 dan yang lebih baru.
Networking	1.10, 1.11, 1.12	Layanan Load Balancer tidak berfungsi dengan container di jaringan host bidang kontrol Terdapat bug di anetd saat paket dihapus untuk Layanan LoadBalancer jika pod backend berjalan di node bidang kontrol dan menggunakan kolom hostNetwork: true di spesifikasi container. Bug tidak ada di versi 1.13 atau yang lebih baru. Solusi: Solusi berikut dapat membantu jika Anda menggunakan Layanan LoadBalancer yang didukung oleh Pod hostNetwork: Jalankan pada node pekerja (bukan node bidang kontrol). Gunakan externalTrafficPolicy: local di spesifikasi Layanan dan pastikan workload Anda berjalan di node load balancer.
Upgrade dan Update	1,12, 1,13	Pod anthos-version-$version$ usang gagal mengambil gambar Upgrade cluster dari 1.12.x ke 1.13.x mungkin mengamati pod anthos-version-$version$ yang gagal dengan error ImagePullBackOff. Hal ini terjadi karena kondisi race anthos-cluster-operator diupgrade dan seharusnya tidak memengaruhi kemampuan cluster reguler apa pun. Bug tidak ada setelah versi 1.13 atau yang lebih baru. Solusi: Menghapus Tugas dynamic-version-installer dengan kubectl delete job anthos-version-$version$ -n kube-system
Upgrade dan update	1.13	1.12 cluster yang diupgrade dari 1.11 tidak dapat diupgrade ke 1.13.0 Cluster versi 1.12 yang diupgrade dari versi 1.11 tidak dapat diupgrade ke versi 1.13.0. Masalah upgrade ini tidak berlaku untuk cluster yang dibuat pada versi 1.12. Untuk mengetahui apakah Anda terpengaruh, periksa log tugas upgrade yang berisi string upgrade-first-no* di cluster admin. Jika melihat pesan error berikut, berarti Anda terpengaruh. TASK [kubeadm_upgrade_apply : Run kubeadm upgrade apply] ******* ... [upgrade/config] FATAL: featureGates: Invalid value: map[string]bool{\"IPv6DualStack\":false}: IPv6DualStack isn't a valid feature name. ... Solusi: Untuk mengatasi masalah ini: Jalankan perintah berikut di workstation admin Anda: echo '[{ "op": "remove", "path": \ "/spec/clusterConfiguration/featureGates" }]' \ > remove-feature-gates.patch export KUBECONFIG=$ADMIN_KUBECONFIG kubectl get kubeadmconfig -A --no-headers | xargs -L1 bash -c \ 'kubectl patch kubeadmconfig $1 -n $0 --type json \ --patch-file remove-feature-gates.patch' Coba lagi upgrade cluster.
Logging dan Pemantauan	1.16.2, 1.16.3	Penggunaan CPU yang tinggi untuk stackdriver-operator Ada masalah pada stackdriver-operator yang menyebabkannya mengonsumsi waktu CPU yang lebih tinggi dari biasanya. Penggunaan CPU normal kurang dari 50 milidetik (50m) untuk stackdriver-operator dalam status tidak ada aktivitas. Penyebabnya adalah ketidakcocokan resource Sertifikat yang diterapkan stackdriver-operator dengan ekspektasi dari cert-manager. Ketidakcocokan ini menyebabkan kondisi race antara cert-manager dan stackdriver-operator dalam mengupdate resource tersebut. Masalah ini dapat mengakibatkan penurunan performa pada cluster dengan ketersediaan CPU yang terbatas. Solusi: Sampai Anda dapat melakukan upgrade ke versi yang memperbaiki bug ini, gunakan solusi berikut: Untuk memperkecil skala stackdriver-operator sementara waktu menjadi 0 replika, terapkan resource kustom AddonConfiguration: kubectl scale deploy stackdriver-operator --replicas=0 Setelah Anda melakukan upgrade ke versi yang memperbaiki masalah ini, skalakan pencadangan stackdriver-operator lagi: kubectl scale deploy stackdriver-operator --replicas=1
Logging dan Pemantauan	1.16.0, 1.16.1	Scraper metrik berbasis anotasi tidak berfungsi Dalam rilis minor Google Distributed Cloud 1.16, kolom enableStackdriverForApplications dalam spesifikasi resource kustom stackdriver tidak digunakan lagi. Kolom ini diganti dengan dua kolom, enableCloudLoggingForApplications dan enableGMPForApplications, di resource kustom stackdriver. Sebaiknya gunakan Google Cloud Managed Service for Prometheus untuk memantau workload Anda. Gunakan kolom enableGMPForApplications untuk mengaktifkan fitur ini. Jika Anda mengandalkan pengumpulan metrik yang dipicu oleh anotasi prometheus.io/scrape pada workload Anda, Anda dapat menggunakan flag gate fitur annotationBasedApplicationMetrics untuk mempertahankan perilaku lama. Namun, ada masalah yang mencegah annotationBasedApplicationMetrics berfungsi dengan benar, sehingga mencegah pengumpulan metrik dari aplikasi Anda ke Cloud Monitoring. Solusi: Untuk mengatasi masalah ini, upgrade cluster Anda ke versi 1.16.2 atau yang lebih baru. Pengumpulan metrik workload berbasis anotasi yang diaktifkan oleh gate fitur annotationBasedApplicationMetrics mengumpulkan metrik untuk objek yang memiliki anotasi prometheus.io/scrape. Banyak sistem software dengan asal open source dapat menggunakan anotasi ini. Jika Anda terus menggunakan metode pengumpulan metrik ini, perhatikan dependensi ini agar Anda tidak terkejut dengan tagihan metrik di Cloud Monitoring.

Jika Anda memerlukan bantuan tambahan, hubungi Cloud Customer Care.