Cluster Anthos on bare metal kini menjadi Google Distributed Cloud (khusus software) untuk bare metal. Untuk mengetahui informasi selengkapnya, lihat ringkasan produk.
Google Distributed Cloud untuk masalah umum bare metal
Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
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:
Pilih kategori masalah Anda:
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:
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:
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:
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:
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.
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:
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:
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:
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:
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:
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:
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:
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:
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.
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.
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:
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:
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:
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})
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:
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:
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:
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:
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")
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:
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:
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.
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:
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:
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:
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.
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
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:
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:
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:
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:
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.
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:
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
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:
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.
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.
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:
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:
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 umask0077 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.
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.
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):
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:
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
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
Untuk berhenti memblokir upgrade, jalankan perintah berikut terhadap cluster
yang sedang Anda upgrade:
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:
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.
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:
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:
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
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:
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.
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.
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.
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:
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):
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.
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:
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.
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-*
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:
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).
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.
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:
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.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2024-07-03 UTC."],[],[]]