Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
s
<0x0
Masalah umum Google Distributed Cloud untuk bare metal
Halaman ini mencantumkan semua masalah umum untuk Google Distributed Cloud (khusus software) untuk bare metal (sebelumnya dikenal sebagai Google Distributed Cloud Virtual, sebelumnya dikenal sebagai cluster Anthos di bare metal).
Halaman ini ditujukan untuk Admin, arsitek, dan Operator yang mengelola siklus proses infrastruktur teknologi yang mendasarinya, serta menanggapi pemberitahuan dan halaman saat tujuan tingkat layanan (SLO) tidak terpenuhi atau aplikasi gagal. Untuk mempelajari lebih lanjut peran umum dan contoh tugas yang kami referensikan dalam konten, lihat Peran dan tugas pengguna GKE umum. Google Cloud
Jika Anda adalah bagian dari Program Developer Google, simpan halaman ini untuk menerima
notifikasi saat catatan rilis yang terkait dengan halaman ini dipublikasikan. Untuk
mempelajari lebih lanjut, lihat
Halaman Tersimpan.
Untuk memfilter masalah umum menurut versi atau kategori 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
Jaringan, Upgrade, dan update
1.30 dan yang lebih baru
Pod Istiod gagal mencapai status siap selama upgrade
Fitur Ingress yang dibundel di Google Distributed Cloud menggunakan
istiod. Fitur ini tidak menggunakan definisi resource kustom
yang ditentukan oleh Istio. Namun, karena kode yang digunakan bersifat open source, pod
sensitif terhadap penginstalan Istio yang mungkin Anda miliki untuk kasus penggunaan Anda sendiri.
Jika tidak ada definisi resource kustom Istio di cluster,
Istiod menyatakan dirinya siap tanpa menunggu definisi resource kustom. Namun, jika ada definisi resource kustom v1beta di cluster, Istiod akan menunggu definisi resource kustom v1 sebelum menyatakan kesiapan. Akibatnya, pod Istiod
mungkin gagal mencapai status siap, sehingga menyebabkan upgrade cluster gagal.
Verifikasi:
Untuk mengonfirmasi apakah cluster Anda terpengaruh, periksa status pod Istiod di namespace gke-system:
kubectlgetpods-ngke-system-lapp=istiod
Jika status pod adalah Running, tetapi pemeriksaan kesiapan gagal
(misalnya, 0/1 siap), cluster Anda kemungkinan terpengaruh.
Solusi:
Untuk mengatasi masalah ini, gunakan salah satu solusi sementara berikut:
Deploy definisi resource kustom v1 Istio secara manual
ke cluster Anda.
Nonaktifkan fitur bundled-ingress jika Anda tidak menggunakannya.
Penginstalan, upgrade, dan update
1.30.400 dan yang lebih lama
lifecycle-controllers-manager mengalami error saat memeriksa resource kustom PreflightCheck
Cluster pada versi 1.30.400 atau yang lebih lama dapat mengalami lifecycle-controllers-managererror pod saat memvalidasi PreflightCheck resource kustom. Error ini menghentikan penyediaan dan upgrade cluster.
Masalah ini terjadi karena dereferensi pointer nol selama validasi resource PreflightCheck.
Solusi:
Untuk mengizinkan penyediaan atau upgrade cluster dilanjutkan, lewati pemeriksaan pra-penerbangan. Tetapkan kolom bypassPreflightCheck ke true di file konfigurasi cluster Anda:
Node Problem Detector tidak dimulai setelah pemulihan cluster
Saat Anda memulihkan cluster menggunakan bmctl restore cluster,
layanan systemd Node Problem Detector (NPD) tidak dimulai di node
setelah operasi pemulihan selesai.
Untuk memeriksa apakah Anda terpengaruh, jalankan
systemctl is-active node-problem-detector di node cluster
setelah operasi pemulihan. Jika perintah menampilkan inactive,
Anda terpengaruh oleh masalah ini.
1.28 dan yang lebih lama, 1.29.0-1.29.700, 1.30.0-1.30.300
Pod Load Balancer Control Plane dimulai ulang setiap 7 hari
Di cluster yang menggunakan load balancer Layer 2 gabungan, Anda mungkin melihat error "Connection Refused" atau ketidaktersediaan server API singkat (sekitar 1 menit) yang terjadi setiap 7 hari.
Perilaku ini terjadi karena pod haproxy dan keepalived di node bidang kontrol dimulai ulang karena setelan waktu aktif tugas. Masalah ini memengaruhi cluster pada versi 1.29.0 hingga 1.29.700, 1.30.0 hingga 1.30.300, serta 1.28 dan yang lebih lama.
Verifikasi:
Untuk mengonfirmasi bahwa cluster Anda terpengaruh oleh masalah khusus ini, periksa konfigurasi tugas update load balancer dengan menyelesaikan langkah-langkah berikut:
Ganti JOB_NAME dengan nama yang ditampilkan di langkah sebelumnya.
Jika outputnya adalah 604800 (yaitu 7 hari dalam detik), berarti cluster Anda terpengaruh oleh masalah ini.
Solusi:
Untuk mencegah mulai ulang mingguan, tambal kolom ttlSecondsAfterFinished secara manual pada tugas update load balancer yang ada ke nilai yang lebih besar, dengan menyelesaikan langkah-langkah berikut:
Edit tugas update load balancer:
kubectleditjobJOB_NAME-nkube-system
Di editor, temukan kolom ttlSecondsAfterFinished dan ubah nilainya menjadi 7776000 (sekitar 90 hari).
Simpan dan keluar dari editor untuk menerapkan perubahan.
Operasi
1.32.0-1.32.700, 1.33.0-1.33.300, 1.34.0
cluster-operator pod mengalami error dengan dereferensi pointer nol
Pod cluster-operator mungkin mengalami error atau masuk ke
crashloop karena panik: assignment to entry in nil map di pengontrol.
Hal ini dapat terjadi saat pengontrol mencoba memperbarui anotasi pada
resource kustom, seperti NodePool, yang tidak memiliki anotasi
(peta nol).
Solusi:
Untuk mencegah panik, pastikan resource kustom (misalnya,
NodePool) memiliki setidaknya satu anotasi. Anda dapat menambahkan
anotasi dummy menggunakan perintah berikut:
ADMIN_KUBECONFIG: Jalur ke file kubeconfig
cluster admin.
Upgrade dan update
1.34.0
Upgrade node pekerja gagal karena ketidakcocokan nama host
Upgrade node pekerja gagal karena regresi
(kubernetes/kubeadm#3244)
di kubeadm. Regresi terjadi saat nama host Linux tidak cocok dengan nilai label kubernetes.io/hostname pada node Kubernetes yang sesuai.
Untuk mengonfirmasi bahwa node yang terpengaruh gagal, gunakan journalctl
yang mirip dengan berikut ini:
Dec 09 20:09:50 vm-lb-0--40b1a328a3448f5-112eaaafe1beedad kubeadm[3684235]: error: error execution phase kubelet-config: could not remove the CRI socket annotation from Node "vm-lb-0--40b1a328a3448f5-112eaaafe1beedad": nodes "vm-lb-0--40b1a328a3448f5-112eaaafe1beedad" not found
Dalam contoh ini, nama host Linux yang dilaporkan dalam respons
journalctl tidak cocok dengan label
kubernetes.io/hostname untuk node,
yang mengonfirmasi bahwa upgrade terpengaruh oleh masalah ini:
kubectl get nodes lb-0--40b1a328a3448f5-112eaaafe1beedad.lab.anthos \
-ojsonpath='{.metadata.labels.kubernetes\.io\/hostname}'
Respons:
lb-0--40b1a328a3448f5-112eaaafe1beedad.lab.anthos
Solusi:
Agar node yang terpengaruh dapat menyelesaikan upgrade, coba ubah nama host untuk sementara agar cocok dengan nilai label kubernetes.io/hostname pada node Kubernetes yang sesuai, seperti berikut:
Migrasi yang tepat akan menghentikan koneksi yang ada pada cordon node
Saat Anda mengaktifkan failover cepat NAT keluar, mengisolasi node gateway dengan
kubectl cordon <NODE_NAME> akan memulai migrasi yang lancar
yang mempertahankan koneksi keluar yang ada. Namun, di
Google Distributed Cloud software-only release 1.34.0, fitur migrasi yang lancar
tidak berfungsi sebagaimana mestinya.
Jika administrator mengisolasi node gateway keluar aktif dalam cluster versi 1.34.0 yang menggunakan failover cepat, pengisolasian akan berperilaku seperti kegagalan node yang tidak direncanakan dan segera menghentikan semua koneksi stateful yang ada di node tersebut.
Solusi:
Tidak ada solusi untuk masalah ini.
Jaringan
1.32.0
Kegagalan komunikasi Layanan ClusterIP
Layanan ClusterIP mungkin mengalami koneksi yang terputus-putus atau gagal
saat traffic dirutekan ke Pod backend di node yang berbeda. Kegagalan komunikasi ini disebabkan oleh regresi di Cilium v1.15 yang mengakibatkan penghapusan aturan CILIUM_POST_nat dari iptables. Aturan
CILIUM_POST_nat diperlukan untuk penafsiran alamat jaringan
sumber (SNAT) dan penghapusannya menyebabkan penyamaran yang tidak andal oleh
kube-proxy, yang mengakibatkan kegagalan komunikasi Layanan ClusterIP.
Misalnya, jika Anda mengupgrade cluster dan operasi terhenti,
Anda mungkin melihat pesan log seperti berikut, yang menunjukkan bahwa handshake TLS
waktunya habis saat layanan ClusterIP mencoba terhubung ke server API
di node pool np1:
I0527 15:42:39.261368 372146 upgrade.go:994] Error trying to connect to api server: Get "https://10.200.0.108:443/apis/baremetal.cluster.gke.io/v1/namespaces/cluster-baremetal-test/nodepools/np1": net/http: TLS handshake timeout
E0527 15:42:39.264789 372146 exec.go:207] command "/root/bmctl-upgrade upgrade cluster --kubeconfig /root/bmctl-workspace/baremetal-test/baremetal-test-kubeconfig --quiet --cluster baremetal-test --manifest-profile-env staging" times out
Masalah ini telah diperbaiki di versi 1.32.100 dan yang lebih baru.
Solusi:
Jika Anda tidak dapat mengupgrade ke versi dengan perbaikan, sebaiknya Anda
mengupgrade image Cilium secara manual ke versi
v1.15.6-anthos1.32.50 atau yang lebih baru. Update ini mengatasi masalah ini dengan memperkenalkan kembali aturan CILIUM_POST_nat yang diperlukan.
Untuk mengupgrade image Cilium, ikuti langkah-langkah berikut:
Error ((retry 1) error adding iam policy bindings: failed to add project binding: failed to set project "<>" iam policy: googleapi: Error 400: Identity Pool does not exist (projectID.). Please check that you specified a valid resource name as returned in the `name` attribute in the configuration API., badRequest) ensuring iam policy binding: project-Id
Kegagalan ini terjadi karena workload identity pool default yang diperlukan
bernama projectID.
tidak otomatis disediakan di project baru.
Solusi:
Gunakan langkah-langkah berikut untuk mengonfigurasi Workload Identity Federation untuk
project Anda:
Buat workload identity pool default yang tidak ada secara manual:
Secara default, token akses memiliki masa aktif 3.600 detik (1 jam).
Saat Anda menggunakan Autentikasi Cluster Workload Identity, bmctl memeriksa waktu habis masa berlaku token. Jika masa berlaku token berada dalam waktu 1.800 detik (30 menit),
bmctl akan melaporkan error dan keluar.
Jalankan bmctl configure projects lagi.
Upgrade dan update, Logging dan pemantauan
1.29, 1.30, 1.31, 1.32
Playbook Ansible cal-update gagal saat mengubah tanda logging audit
Playbook Ansible cal-update berisi error logis yang
menyebabkan kegagalan saat mencoba mengubah tanda disableCloudAuditLogging. Hal ini mencegah pengaktifan atau penonaktifan log audit yang tepat.
Jika disableCloudAuditLogging diubah dari true
menjadi false, log audit tidak dapat diaktifkan karena skrip gagal
sebelum menerapkan perubahan konfigurasi ke kube-apiserver. Jika
disableCloudAuditLogging diubah dari false menjadi
true, log audit dapat dinonaktifkan, tetapi tugas cal-update
terus gagal, sehingga mencegah playbook mencapai pemeriksaan kondisi.
Pesan error yang diamati adalah:
The task includes an option with an undefined variable. The error was: 'dict object' has no attribute 'stdout_lines'
Solusi:
Tidak ada solusi untuk masalah ini, Anda harus mengupgrade cluster ke versi yang memiliki perbaikan. Saat mengupgrade, ikuti langkah-langkah berikut:
Nonaktifkan logging audit dengan menyetel disableCloudAuditLogging
ke true.
Saat patch tersedia, upgrade cluster Anda ke salah satu versi patch rilis minor berikut (atau yang lebih baru), yang memiliki perbaikan:
1.30.1200
1.31.800
1.32.400
Untuk mengaktifkan kembali log audit cloud, tetapkan disableCloudAuditLogging
kembali ke false.
Upgrade dan update
1.32+
Upgrade untuk cluster admin ketersediaan tinggi (HA) gagal setelah operasi perbaikan
Pada cluster admin HA, perintah gkectl upgrade admin akan gagal
dan macet saat Anda menjalankannya setelah menjalankan perintah gkectl repair
admin-master.
Perintah gkectl repair admin-master menambahkan
anotasi machine.onprem.gke.io/managed=false ke Mesin yang diperbaiki.
Anotasi ini menyebabkan pengontrol cluster-api macet
dalam status rekonsiliasi saat Anda menjalankan perintah gkectl upgrade admin. Upgrade untuk cluster non-HA mencakup logika pivot yang menghapus anotasi ini, tetapi logika pivot tidak ada dalam upgrade untuk cluster HA.
Solusi:
Hapus anotasi machine.onprem.gke.io/managed secara manual
dari resource Machine di cluster admin sebelum memulai upgrade.
Upgrade, Konfigurasi
1.32.0 - 1.32.200
Mirror registri menyebabkan kegagalan pemeriksaan pra-upgrade
Cluster yang dikonfigurasi dengan mirror registri gagal dalam pemeriksaan awal check_gcr_pass selama upgrade ke 1.32.0+. Kegagalan ini disebabkan oleh perubahan cara pembuatan resource kustom PreflightCheck, yang menghilangkan konfigurasi mirror registri dari spesifikasi cluster yang digunakan dalam pemeriksaan.
Masalah ini ditemukan selama pengujian internal pada cluster dengan konfigurasi proxy dan mirror registry.
Solusi:
Anda dapat menggunakan salah satu opsi berikut sebagai solusi untuk masalah ini:
Gunakan flag --force saat memicu upgrade.
Dapatkan konfigurasi cluster saat ini menggunakan bmctl get config
dan gunakan file konfigurasi yang baru dibuat ini untuk memicu upgrade.
Konfigurasi, Update
1.15 hingga 1.30, 1.31.0 hingga 1.31.800, 1.32.0 hingga 1.32.300
Health check berkala CronJob Gagal diupdate setelah spesifikasi Cluster berubah
Pada versi cluster tertentu, CronJob health check berkala mungkin tidak memperbarui spesifikasinya saat ada perubahan pada konfigurasi resource Cluster. Kegagalan update ini menyebabkan health check menjadi tidak berlaku dan berpotensi menyebabkan kegagalan tugas.
Masalah ini telah diperbaiki di Google Distributed Cloud versi 1.31.900,
1.32.400, dan 1.33.0 serta yang lebih baru.
Solusi:
Untuk versi 1.30 dan yang lebih lama, Anda dapat menggunakan langkah-langkah berikut sebagai solusi:
Keepalived digunakan untuk memindahkan VIP bidang kontrol dari satu mesin ke mesin lain untuk mencapai ketersediaan tinggi. Jika VIP bidang kontrol ditangani
oleh load balancer Layer 2 yang dibundel, failover instance
Keepalived dapat menyebabkan interval singkat (di bawah satu detik) saat
ARP yang tidak beralasan dengan alamat MAC yang berbeda diselingi. Infrastruktur
jaringan switching dapat menafsirkan penyisipan ini sebagai tidak normal dan menolak
pesan ARP lebih lanjut selama jangka waktu hingga 30 menit. Pesan ARP yang diblokir pada gilirannya dapat menyebabkan VIP bidang kontrol tidak tersedia selama periode ini.
Penyisipan ARP yang tidak perlu disebabkan oleh setelan Keepalived
yang digunakan dalam versi 1.31 dan yang lebih lama. Secara khusus, semua node dikonfigurasi
untuk menggunakan prioritas yang sama. Perubahan konfigurasi Keepalived dalam versi 1.32 mengatasi masalah ini dengan mengonfigurasi
prioritas yang berbeda untuk setiap instance Keepalived dan juga menyediakan
setelan cluster,
controlPlane.loadBalancer.keepalivedVRRPGARPMasterRepeat, untuk
mengurangi jumlah ARP yang tidak perlu.
Solusi:
Untuk versi 1.31 dan yang lebih lama, Anda dapat mengurangi interleaving ARP gratis dengan mengedit langsung file konfigurasi Keepalived, /usr/local/etc/keepalived/keepalived.conf. Untuk setiap
node yang menjalankan load balancer bidang kontrol, edit file konfigurasi
untuk mengubah setelan berikut:
priority: tetapkan nilai priority yang berbeda untuk
setiap node (nilai yang valid adalah antara 1 dan 254)
weight: mengubah nilai weight dari
-2 menjadi -253 untuk memastikan bahwa failover
Keepalived dipicu saat health check gagal.
Logging dan pemantauan
1.30, 1.31, 1.32, 1.33
Perbedaan dalam metrik kubernetes.io/anthos/custom_resurce_watchers
Karena error definisi internal, metrik kubernetes.io/anthos/custom_resurce_watchers mungkin menampilkan data yang tidak akurat. Jika terpengaruh oleh masalah ini, Anda mungkin melihat
error dalam log yang mirip dengan berikut:
Anda dapat mengabaikan error ini dengan aman. Metrik ini tidak digunakan untuk
peringatan sistem penting dan error tidak memengaruhi fungsi project atau cluster
Anda.
Operasi
1.30, 1.31, 1.32, 1.33
Pengambilan snapshot gagal mengurai file konfigurasi cluster
Jika direktori .manifests tidak ada di workstation admin saat Anda menjalankan bmctl check cluster --snapshot,
perintah akan gagal dengan error yang mirip dengan berikut:
Kegagalan ini terjadi karena perintah bmctl check cluster
--snapshot memerlukan file definisi resource kustom di
direktori .manifests untuk memvalidasi konfigurasi
cluster. Direktori ini biasanya dibuat selama penyiapan cluster.
Jika Anda secara tidak sengaja menghapus direktori atau menjalankan bmctl dari
lokasi yang berbeda, perintah tidak dapat melanjutkan operasi snapshot.
Solusi Sementara:
Anda dapat mengatasi masalah ini dengan membuat ulang direktori
.manifests secara manual menggunakan salah satu metode berikut:
Sebagai bagian dari pemeriksaan awalnya, perintah ini akan otomatis membuat
direktori .manifests di direktori kerja Anda saat ini,
terlepas dari apakah perintah berhasil diselesaikan atau tidak.
Di direktori yang berisi file konfigurasi cluster saat ini,
jalankan perintah bmctl create cluster:
bmctlcreatecluster--clusterTEST_CLUSTER
Meskipun perintah ini kemungkinan akan menghasilkan error, seperti
Unable to Parse Cluster Configuration File,
direktori .manifests tetap dibuat di direktori kerja
Anda saat ini.
Direktori sementara bmctl-workspace/TEST_CLUSTER
yang dihasilkan dapat dihapus dengan aman setelahnya.
Setelah melakukan salah satu solusi sebelumnya, coba lagi perintah
bmctl check cluster --snapshot.
Penginstalan, Upgrade, dan update
1.32.0, 1.32.100
VIP bidang kontrol tidak dipindahkan saat HAProxy tidak tersedia
Jika instance HAProxy tidak tersedia di node yang menghosting
VIP bidang kontrol, setelan nopreempt pada instance Keepalived
mencegah VIP bidang kontrol berpindah ke node dengan
HAProxy yang responsif. Masalah ini terkait dengan fitur yang secara otomatis
mengonfigurasi prioritas protokol redundansi router virtual Keepalived (VRRP)
yang tidak kompatibel dengan setelan nopreempt.
Solusi:
Sebagai solusinya, gunakan langkah-langkah berikut untuk menonaktifkan fitur
Keepalived:
Tambahkan anotasi preview.baremetal.cluster.gke.io/keepalived-different-priorities: "disable"
ke cluster:
Hapus nopreempt dari /usr/local/etc/keepalived/keepalived.conf
di node yang menjalankan load balancer bidang kontrol.
Bergantung pada konfigurasi load balancer, node ini adalah node bidang kontrol atau node di kumpulan node load balancer.
Setelah nopreempt dihapus, pod statis keepalived
harus dimulai ulang untuk mengambil perubahan dari file
konfigurasi. Untuk melakukannya, di setiap node, gunakan perintah berikut untuk memulai ulang
pod keepalived:
Tugas pra-penerbangan dan health check yang gagal dapat meninggalkan artefak dalam
folder abm-tools-* yang diberi stempel waktu di bagian /usr/local/bin. Jika Anda terpengaruh
oleh masalah ini, Anda mungkin melihat banyak folder seperti berikut:
/usr/local/bin/abm-tools-preflight-20250410T114317.
Kegagalan berulang dapat menyebabkan peningkatan penggunaan disk.
Solusi
Hapus folder ini secara manual jika Anda mengalami masalah ini:
rm-rf/usr/local/bin/abm-tools-*
Jaringan
1.28.0-1.28.200
Traffic load balancer dihentikan saat menggunakan gateway NAT keluar
Pada cluster yang mengaktifkan gateway NAT keluar, jika load balancer memilih backend yang cocok dengan aturan pemilihan traffic yang ditentukan oleh resource kustom EgressNATPolicy yang tidak berlaku, traffic load balancer akan dihentikan.
Masalah ini terjadi saat pembuatan dan penghapusan pod yang cocok dengan
kebijakan egress. Kebijakan keluar tidak dibersihkan sebagaimana mestinya
saat pod dihapus dan kebijakan keluar yang tidak berlaku menyebabkan pod LoadBalancer
mencoba mengirim traffic ke koneksi yang tidak ada lagi.
Masalah ini telah diperbaiki di Google Distributed Cloud versi 1.28.300 dan yang lebih baru.
Solusi
Untuk membersihkan resource kebijakan NAT keluar, mulai ulang setiap node yang menghosting
backend yang gagal.
Upgrade dan update, Reset/Penghapusan
1,28
kegagalan machine-init - node bidang kontrol baru macet
selama penggantian
Saat mengganti (menghapus, menambahkan) node bidang kontrol di
Google Distributed Cloud 1.28, node baru mungkin gagal bergabung dengan cluster.
Hal ini karena proses yang bertanggung jawab untuk menyiapkan node baru
(bm-system-machine-init) mengalami error berikut:
Failed to add etcd member: etcdserver: unhealthy cluster
Error ini terjadi saat node panel kontrol lama dihapus dan keanggotaannya di etcd-events tidak dibersihkan dengan benar, sehingga meninggalkan anggota yang sudah tidak berlaku. Anggota yang sudah tidak berlaku mencegah node baru bergabung ke cluster etcd-events, sehingga menyebabkan proses machine-init gagal dan node baru terus dibuat ulang.
Konsekuensi masalah ini meliputi:
Node bidang kontrol baru tidak dapat dimulai dengan benar.
Cluster dapat macet dalam status RECONCILING.
Node bidang kontrol terus dihapus dan dibuat ulang karena
kegagalan machine-init.
Masalah ini telah diperbaiki di versi 1.29 dan yang lebih baru.
Solusi:
Jika Anda tidak dapat mengupgrade ke versi 1.29, Anda dapat menghapus anggota etcd-events yang rusak dari cluster secara manual, menggunakan petunjuk berikut:
Gunakan SSH untuk mengakses node panel kontrol yang berfungsi.
Kegagalan upgrade bidang kontrol karena file super-admin.conf
tidak ada
Selama upgrade cluster, proses upgrade mungkin gagal di node control plane
pertama dengan pesan error di dalam tugas ansible yang menunjukkan bahwa file
super-admin.conf tidak ada.
Masalah ini terjadi karena node bidang kontrol pertama yang diupgrade
mungkin bukan node pertama yang disediakan selama pembuatan cluster.
Proses upgrade mengasumsikan bahwa node pertama yang diupgrade adalah node
yang berisi file super-admin.conf.
Masalah ini diperbaiki dalam update patch berikut: 1.30.500-gke.127, 1.30.600-gke.69, dan 1.31.200-gke.59
Solusi:
Untuk mengurangi masalah ini, lakukan langkah berikut pada node yang gagal:
Salin file /etc/kubernetes/admin.conf ke
/etc/kubernetes/super-admin.conf:
Proses upgrade akan otomatis dicoba lagi dan akan berhasil.
Upgrade dan update
1.29.0 - 1.29.1100, 1.30.0 - 1.30.400
Pengurasan node terhenti jika
Pod menoleransi taint NoSchedule
Pod dengan toleransi NoSchedule dipertimbangkan untuk
penghentian selama upgrade. Namun, karena toleransi NoSchedule, pengontrol Deployment atau DaemonSet dapat menjadwalkan Pod lagi di node yang sedang menjalani pemeliharaan, sehingga berpotensi menunda upgrade.
Untuk melihat apakah Anda terpengaruh oleh masalah ini, ikuti langkah-langkah berikut:
Periksa log pod anthos-cluster-operator untuk mengidentifikasi
pod yang memblokir pengurasan node.
Dalam cuplikan log contoh berikut,
Pod node-problem-detector-mgmt-ydhc2 belum dikuras:
nodepool_controller.go:720] controllers/NodePool "msg"="Pods yet to drain for 10.0.0.3 machine are 1 : [node-problem-detector-mgmt-ydhc2]" "nodepool"={"Namespace":"test-cluster","Name":"test-cluster"}
Untuk setiap pod yang memblokir pengurasan node, jalankan
perintah berikut untuk memeriksa toleransi:
Ganti POD_NAME dengan nama
Pod yang memblokir pengosongan node.
Anda akan melihat salah satu kombinasi berikut:
Toleransi dengan efek NoSchedule dan operator Exists
Toleransi dengan efek NoSchedule dan kunci "baremetal.cluster.gke.io/maintenance"
Toleransi dengan efek kosong dan kunci "baremetal.cluster.gke.io/maintenance"
Misalnya, responsnya mungkin terlihat seperti berikut:
{
"effect": "NoSchedule",
"operator": "Exists"
},
Solusi:
Anda dapat membatalkan pengurasan node dengan melakukan salah satu tindakan berikut:
Tambahkan toleransi baremetal.cluster.gke.io/maintenance:NoExecute
ke pod yang memiliki
toleransi baremetal.cluster.gke.io/maintenance:Schedule
dan tidak memerlukan penghentian yang benar.
Hapus kombinasi toleransi yang diidentifikasi dari pod yang harus
dikeluarkan selama pengurasan node.
Jaringan
1.28, 1.29, dan 1.30
Panggilan jaringan ke Pod dengan hostPort yang diaktifkan akan gagal untuk permintaan yang berasal dari dalam node yang sama
Panggilan jaringan ke Pod yang mengaktifkan hostPort akan gagal dan
menjatuhkan paket jika permintaan berasal dari dalam node yang sama tempat
Pod berjalan. Hal ini berlaku untuk semua jenis cluster dan node.
Cluster yang dibuat tanpa kube-proxy,
tidak terpengaruh.
Periksa apakah Anda terpengaruh oleh masalah ini:
Dapatkan nama Pod anetd:
Pod anetd bertanggung jawab untuk mengontrol traffic
jaringan.
Teridentifikasi di 1.29.100, Kemungkinan terjadi di versi lain juga
I/O disk tinggi karena hilangnya konektivitas jaringan atau Akun Layanan yang tidak valid
Pod stackdriver-log-forwarder mungkin mengalami kehilangan konektivitas atau akun layanan yang sudah tidak berlaku, yang akan menyebabkan kegagalan pengiriman log tersebut ke logging.googleapis.com, sehingga menyebabkan penumpukan log dalam buffer, yang mengakibatkan I/O disk yang tinggi. Agen logging Cloud (Fluent Bit), daemonset yang diberi nama stackdriver-log-forwarder, menggunakan buffer berbasis sistem file dengan batas 4 GB. Saat penuh, agen akan mencoba memutar atau mengosongkan buffer, yang dapat menyebabkan I/O tinggi.
Hal-hal yang perlu diperiksa:
Pastikan kunci akun layanan (SA) telah habis masa berlakunya. Jika ya, putar untuk mengatasi masalah.
Anda dapat mengonfirmasi akun layanan yang saat ini digunakan menggunakan perintah berikut dan memvalidasinya di IAM:
Peringatan: Menghapus buffer akan mengakibatkan hilangnya semua log yang saat ini disimpan dalam buffer secara permanen (termasuk log node, pod, dan container Kubernetes). Jika akumulasi buffer disebabkan oleh hilangnya konektivitas jaringan ke layanan logging Google Cloud, log ini akan hilang secara permanen saat buffer dihapus atau jika buffer penuh dan agen tidak dapat mengirim log.
Hapus pod daemonset stackdriver-log-forwarder dari cluster dengan menambahkan pemilih node (Tindakan ini akan mempertahankan DaemonSet stackdriver-log-forwarder, tetapi membatalkan penjadwalannya dari node):
Ganti KUBECONFIG dengan jalur ke file kubeconfig cluster pengguna Anda.
Pastikan Pod stackdriver-log-forwarder telah dihapus sebelum melanjutkan ke langkah berikutnya.
Jika hal ini hanya terjadi pada satu atau beberapa node:
Hubungkan ke node menggunakan SSH tempat stackdriver-log-forwarder berjalan (verifikasi bahwa stackdriver-log-forwarder tidak lagi berjalan di node tersebut).
Di node, hapus semua file buffer menggunakan rm -rf /var/log/fluent-bit-buffers/, lalu ikuti langkah 6.
Jika ada terlalu banyak node dengan file tersebut dan Anda ingin menerapkan skrip untuk membersihkan semua node yang memiliki backlog chunk ini, gunakan skrip berikut:
Deploy DaemonSet untuk membersihkan semua data dalam buffer di fluent-bit:
Upgrade diblokir oleh pod yang macet karena masalah containerd
Pod dapat macet saat dihentikan jika node sedang dikuras. Pod yang macet dapat
memblokir operasi, seperti upgrade, yang menguras node. Pod dapat macet
saat container ditampilkan sebagai berjalan meskipun proses utama yang mendasarinya
dari container telah berhasil keluar. Dalam hal ini, perintah
crictl stop juga tidak menghentikan container.
Untuk mengonfirmasi apakah Anda terpengaruh oleh masalah ini, ikuti langkah-langkah berikut:
Periksa apakah cluster Anda memiliki pod yang macet dengan status
Terminating:
Jika Anda melihat peringatan seperti berikut dengan Unhealthy
dan FailedKillPod sebagai alasannya, Anda terpengaruh oleh masalah ini:
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedKillPod 19m (x592 over 46h) kubelet error killing pod: [failed to "KillContainer" for "dnsmasq" with KillContainerError: "rpc error: code = DeadlineExceeded desc = context deadline exceeded", failed to "KillPodSandbox" for "0843f660-461e-458e-8f07-efe052deae23" with KillPodSandboxError: "rpc error: code = DeadlineExceeded desc = context deadline exceeded"]
Warning Unhealthy 4m37s (x16870 over 46h) kubelet (combined from similar events): Readiness probe errored: rpc error: code = Unknown desc = failed to exec in container: failed to start exec "c1ea4ffe7e4f1bacaab4f312bcc45c879785f6e22e7dc2d94abc3a019e20e1a9": OCI runtime exec failed: exec failed: cannot exec in a stopped container: unknown
Masalah ini disebabkan oleh masalah containerd upstream, yang telah
diperbaiki di Google Distributed Cloud versi 1.28.1000, 1.29.600, 1.30.200, 1.31, dan yang lebih baru.
Solusi
Untuk membatalkan pemblokiran operasi cluster:
Hapus paksa pod yang macet:
kubectldeletepodPOD_NAME-nPOD_NAMESPACE--force
Jika pod berhasil dimulai ulang, coba lagi operasi cluster.
Upgrade dan update, Operasi
1.28, 1.29, dan 1.30.0-1.30.100
Upgrade diblokir oleh pod yang macet karena gagal menghapus cgroups
Pod dapat macet saat dihentikan jika node sedang dikuras. Pod yang macet dapat
memblokir operasi cluster, seperti upgrade, yang mengosongkan node. Pod dapat
macet saat proses runc init dibekukan, yang mencegah
containerd menghapus runc init yang terkait dengan Pod tersebut.cgroups
Untuk mengonfirmasi apakah Anda terpengaruh oleh masalah ini, ikuti langkah-langkah berikut:
Periksa apakah cluster Anda memiliki pod yang macet dengan status
Terminating:
Setelah cgroupsTHAWED,
proses runc init yang sesuai akan otomatis keluar
dan cgroups akan otomatis dihapus. Hal ini mencegah
peringatan Failed to remove cgroup tambahan muncul
di log kubelet. Pod yang macet dalam status Terminating
juga akan otomatis dihapus tidak lama setelah pembersihan.
Setelah cgroups yang dibekukan dibersihkan dan pod yang macet dihapus, coba lagi operasi cluster.
Konfigurasi, Jaringan
1.28.0 hingga 1.28.1000, 1.29.0 hingga 1.29.500, dan 1.30.0 hingga 1.30.200
Peristiwa NodeNotReady karena pembaruan sewa gagal
Di Google Distributed Cloud versi yang diidentifikasi, kubelet mungkin gagal
memperbarui lease node selama lebih dari 40 detik, sehingga menghasilkan peristiwa NodeNotReady.
Masalah ini terjadi sesekali dan terjadi kira-kira setiap 7 hari. Failover VIP bidang kontrol mungkin terjadi sekitar waktu peristiwa NodeNotReady.
Masalah ini telah diperbaiki di versi 1.28.1100, 1.29.600, 1.30.300, dan yang lebih baru.
Solusi:
Untuk mengurangi masalah ini, Anda dapat mengonfigurasi kubelet dengan langkah-langkah berikut:
Buat /etc/default/kubelet dan tambahkan variabel lingkungan berikut ke dalamnya:
Ganti KUBELET_PID dengan output dari perintah
di langkah sebelumnya.
Output perintah cat akan mencantumkan dua variabel lingkungan yang ditambahkan pada beberapa baris terakhir.
Update
1,30
Error kolom tidak dapat diubah saat memperbarui cluster pengguna dengan versi 1.30.x bmctl
Saat Anda membuat cluster pengguna menggunakan perintah bmctl create cluster
dan meneruskan kolom cloudOperationsServiceAccountKeyPath
di header, kolom spec.clusterOperations.serviceAccountSecret
akan ditambahkan ke resource Cluster yang dibuat. Kolom ini tidak ada dalam
file konfigurasi cluster dan tidak dapat diubah. Perintah bmctl update cluster
tidak mengisi kolom ini dari header, sehingga upaya untuk mengupdate
cluster dengan perintah bmctl update cluster dan file konfigurasi
cluster asli gagal dengan error berikut:
Resource kustom yang diambil ditulis ke file YAML bernama:
bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-TIMESTAMP.yaml.
File konfigurasi baru ini mencakup spec.clusterOperations.serviceAccountSecret,
yang diperlukan agar perintah update berfungsi.
TIMESTAMP dalam nama file menunjukkan tanggal
dan waktu file dibuat.
Ganti file konfigurasi cluster yang ada dengan file yang diambil.
Simpan cadangan file yang ada.
Edit file konfigurasi cluster baru dan gunakan bmctl update
untuk mengupdate cluster pengguna Anda:
Jika rotasi sertifikat berhasil, hapus direktori cadangan:
rm-rf~/kubelet-backup/
Penginstalan, Upgrade, dan update
1.31
Error saat membuat resource kustom
Di Google Distributed Cloud versi 1.31, Anda mungkin mendapatkan error saat
mencoba membuat resource kustom, seperti cluster (semua jenis) dan
beban kerja. Masalah ini disebabkan oleh perubahan yang tidak kompatibel yang diperkenalkan di
Kubernetes 1.31 yang mencegah kolom caBundle dalam definisi
resource kustom bertransisi dari status valid ke status tidak valid.
Untuk mengetahui informasi selengkapnya tentang perubahan ini, lihat
log perubahan Kubernetes 1.31.
Sebelum Kubernetes 1.31, kolom caBundle sering kali ditetapkan ke nilai sementara \n, karena di versi Kubernetes sebelumnya, server API tidak mengizinkan konten paket CA kosong. Penggunaan
\n adalah solusi yang wajar untuk menghindari kebingungan, karena
cert-manager biasanya memperbarui caBundle
nanti.
Jika caBundle telah di-patch sekali dari status tidak valid ke status
valid, tidak akan ada masalah. Namun, jika definisi resource kustom
disesuaikan kembali ke \n (atau nilai
lain yang tidak valid), Anda mungkin mengalami error berikut:
...Invalid value: []byte{0x5c, 0x6e}: unable to load root certificates: unable to parse bytes as PEM block]
Solusi
Jika Anda memiliki definisi resource kustom yang caBundle
ditetapkan ke nilai yang tidak valid, Anda dapat menghapus kolom caBundle
seluruhnya dengan aman. Tindakan ini akan menyelesaikan masalah.
Penginstalan, Upgrade, dan update
1.28, 1.29, dan 1.30
Upgrade cluster membutuhkan waktu terlalu lama
Dalam upgrade cluster, setiap node cluster akan dikuras dan diupgrade. Pada rilis 1.28 dan yang lebih baru, Google Distributed Cloud beralih dari pengurasan node berbasis taint ke pengurasan berbasis penghapusan.
Selain itu, untuk mengatasi interdependensi pod, pengurasan berbasis penghapusan
mengikuti urutan pengurasan multi-tahap.
Pada setiap tahap pengurasan, pod memiliki masa tenggang 20 menit untuk dihentikan,
sedangkan pengurasan berbasis taint sebelumnya memiliki satu waktu tunggu 20 menit.
Jika setiap tahap memerlukan waktu 20 menit penuh untuk mengeluarkan semua pod, waktu untuk
menguras node dapat jauh lebih lama daripada pengurasan berbasis taint
sebelumnya. Selanjutnya, peningkatan waktu pengosongan node dapat meningkatkan waktu yang diperlukan untuk menyelesaikan upgrade cluster atau mengalihkan cluster ke mode pemeliharaan secara signifikan.
Ada juga
masalah Kubernetes upstream
yang memengaruhi logika waktu tunggu untuk pengurasan berbasis pengusiran. Masalah ini
juga dapat memperpanjang waktu pengurasan node.
Solusi:
Sebagai solusi, Anda dapat
menonaktifkan pengurasan node berbasis pengusiran.
Tindakan ini akan kembali ke pengurasan berbasis taint. Namun, kami tidak merekomendasikan pengurasan berbasis taint, karena tidak mematuhi PodDisruptionBudgets (PDB), yang dapat
menyebabkan gangguan layanan.
Penginstalan, Upgrade, dan update
1.16, 1.28, dan 1.29
Pemeriksaan preflight yang gagal dan sudah tidak berlaku dapat memblokir operasi cluster
Penyelesaian cluster adalah fase standar untuk sebagian besar operasi cluster,
termasuk pembuatan cluster dan upgrade cluster. Selama rekonsiliasi
cluster, pengontrol cluster Google Distributed Cloud memicu pemeriksaan
persiapan. Jika pemeriksaan preflight ini gagal, rekonsiliasi cluster lebih lanjut akan diblokir. Akibatnya, operasi cluster yang mencakup
rekonsiliasi cluster juga diblokir.
Pemeriksaan pra-penerbangan ini tidak berjalan secara berkala, tetapi berjalan sebagai bagian dari
rekonsiliasi cluster saja. Oleh karena itu, meskipun Anda memperbaiki masalah yang
menyebabkan kegagalan pra-peluncuran awal dan pemeriksaan pra-peluncuran sesuai permintaan berhasil dijalankan, rekonsiliasi cluster tetap diblokir karena pemeriksaan pra-peluncuran yang gagal dan sudah tidak berlaku ini.
Jika Anda mengalami penginstalan atau upgrade cluster yang macet, Anda dapat
memeriksa apakah Anda terpengaruh oleh masalah ini dengan langkah-langkah berikut:
Periksa log Pod anthos-cluster-operator untuk menemukan entri seperti berikut:
"msg"="Preflight check not ready. Won't reconcile"
Periksa apakah pemeriksaan pra-penerbangan yang dipicu oleh pengontrol
cluster berada dalam status gagal:
Setelah pemeriksaan preflight yang gagal dan tidak berlaku dihapus, pengontrol
cluster dapat membuat pemeriksaan preflight baru.
Penginstalan, Upgrade, dan update
1.30.100, 1.30.200, dan 1.30.300
Operasi pembuatan atau upgrade cluster pengguna mungkin tidak berhasil
Membuat cluster pengguna di, atau mengupgrade cluster pengguna yang ada ke,
versi 1.30.100, 1.30.200, atau 1.30.300 mungkin tidak berhasil. Masalah ini hanya berlaku saat kubectl atau klien GKE On-Prem API (konsol Google Cloud , gcloud CLI, atau Terraform) digunakan untuk operasi pembuatan dan upgrade cluster pengguna.
Dalam situasi ini, operasi pembuatan cluster pengguna akan macet dalam
status Provisioning dan upgrade cluster pengguna akan macet
dalam status Reconciling.
Untuk memeriksa apakah cluster terpengaruh, ikuti langkah-langkah berikut:
CLUSTER_NAME: nama cluster
pengguna yang mengalami masalah.
USER_CLUSTER_NAMESPACE: nama namespace cluster
pengguna.
ADMIN_KUBECONFIG: jalur file kubeconfig cluster pengelola.
Jika nilai CLUSTER STATE adalah Provisioning
atau Reconciling, Anda mungkin terpengaruh oleh masalah ini. Contoh respons berikut adalah indikator bahwa upgrade macet:
NAME ABM VERSION DESIRED ABM VERSION CLUSTER STATE
some-cluster 1.30.0-gke.1930 1.30.100-gke.96 Reconciling
Versi yang tidak cocok juga merupakan indikasi bahwa upgrade cluster belum selesai.
Streaming log Pod anthos-cluster-operator untuk pesan yang berulang, yang menunjukkan bahwa cluster mengalami masalah saat penyediaan atau rekonsiliasi:
kubectllogsPOD_NAME-nkube-system-f--since=15s\--kubeconfigADMIN_KUBECONFIG|\grep"Waiting for configMapForwarder to forward kube-system/metadata-image-digests to the cluster namespace, requeuing"
Ganti POD_NAME dengan nama lengkap
Pod anthos-cluster-operator dari langkah sebelumnya.
Saat perintah berjalan, perhatikan aliran berkelanjutan dari baris log yang cocok, yang menunjukkan bahwa operasi cluster macet. Output
contoh berikut mirip dengan yang Anda lihat saat cluster
macet saat menyelaraskan:
...
I1107 17:06:32.528471 1 reconciler.go:1475] "msg"="Waiting for configMapForwarder to forward kube-system/metadata-image-digests to the cluster namespace, requeuing" "Cluster"={"name":"user-t05db3f0761d4061-cluster","namespace":"cluster-user-t05db3f0761d4061-cluster"} "controller"="cluster" "controllerGroup"="baremetal.cluster.gke.io" "controllerKind"="Cluster" "name"="user-t05db3f0761d4061-cluster" "namespace"="cluster-user-t05db3f0761d4061-cluster" "reconcileID"="a09c70a6-059f-4e81-b6b2-aaf19fd5f926"
I1107 17:06:37.575174 1 reconciler.go:1475] "msg"="Waiting for configMapForwarder to forward kube-system/metadata-image-digests to the cluster namespace, requeuing" "Cluster"={"name":"user-t05db3f0761d4061-cluster","namespace":"cluster-user-t05db3f0761d4061-cluster"} "controller"="cluster" "controllerGroup"="baremetal.cluster.gke.io" "controllerKind"="Cluster" "name"="user-t05db3f0761d4061-cluster" "namespace"="cluster-user-t05db3f0761d4061-cluster" "reconcileID"="e1906c8a-cee0-43fd-ad78-88d106d4d30a""Name":"user-test-v2"} "err"="1 error occurred:\n\t* failed to construct the job: ConfigMap \"metadata-image-digests\" not found\n\n"
...
Pengguna non-root tidak dapat menjalankan bmctl restore untuk memulihkan kuorum
Saat menjalankan bmctl restore --control-plane-node sebagai pengguna
non-root, masalah chown terjadi saat menyalin file dari node
control plane ke mesin workstation.
Solusi:
Jalankan perintah bmctl restore --control-plane-node dengan
sudo untuk pengguna non-root.
Upgrade
1.30.0-gke.1930
Tugas upgrade-health-check tetap dalam status aktif karena tidak ada image pause:3.9
Selama upgrade, tugas upgrade-health-check mungkin tetap dalam status aktif
karena image pause:3.9 tidak ada.
Masalah ini tidak memengaruhi keberhasilan upgrade.
Solusi:
Hapus tugas upgrade-health-check secara manual dengan perintah
berikut:
Download artefak dengan ukuran yang melebihi batas memory.max
cgroup mungkin sangat lambat. Masalah ini disebabkan oleh bug di kernel Linux untuk Red Hat Enterprise Linux (RHEL) 9.2. Kernel dengan cgroup v2 yang diaktifkan terpengaruh. Masalah ini diperbaiki di kernel versi 5.14.0-284.40.1.el_9.2 dan yang lebih baru.
Solusi:
Untuk pod yang terpengaruh, tingkatkan setelan batas memori untuk containernya
(spec.containers[].resources.limits.memory) sehingga batasnya
lebih besar daripada ukuran artefak yang didownload.
Upgrade
1.28 hingga 1.29.200
Upgrade cluster gagal karena konflik dalam definisi resource kustom networks.networking.gke.io
Selama upgrade cluster bare metal, upgrade mungkin gagal dengan
pesan error yang menunjukkan bahwa ada konflik dalam
definisi resource kustom networks.networking.gke.io.
Secara khusus, error ini menunjukkan bahwa v1alpha1 tidak ada
di spec.versions.
Masalah ini terjadi karena definisi resource kustom versi v1alpha1 tidak dimigrasikan ke v1 selama proses upgrade.
Solusi:
Patch cluster yang terpengaruh dengan perintah berikut:
Kegagalan pemeriksaan awal 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 awal komputer 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 dibaca secara salah 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:
Setelah operasi penginstalan atau upgrade selesai, nilai ini dapat dikembalikan jika perlu.
Upgrade
1.28.0 - 1.28.500
Upgrade cluster gagal karena error pemeriksaan jangkauan Google Cloud
Saat 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 di versi bmctl 1.28.0 hingga 1.28.500.
Solusi:
Sebelum 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 gagal jika
ipam-controller-manager diperlukan dan cluster Anda
berjalan di Red Hat Enterprise Linux (RHEL) 8.9 atau yang lebih baru (bergantung pada
perubahan RHEL upstream) dengan SELinux yang berjalan dalam mode penerapan. Hal
ini berlaku khusus saat 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 stack ganda IPv4/IPv6
Cluster Anda dikonfigurasi dengan clusterNetwork.flatIPv4
disetel ke true
Cluster Anda dikonfigurasi dengan
anotasi preview.baremetal.cluster.gke.io/multi-networking: enable
Penginstalan dan upgrade cluster tidak berhasil saat
ipam-controller-manager diinstal.
Solusi
Tetapkan konteks default untuk direktori /etc/kubernetes
di setiap node bidang kontrol ke jenis etc_t:
Upgrade cluster gagal karena error pemeriksaan jangkauan Google Cloud
Saat 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 di versi bmctl 1.28.0 hingga 1.28.500.
Solusi:
Sebelum 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 node pool load balancer terpisah
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 di atas, berarti cluster Anda mengalami masalah ini.
Solusi:
Untuk mengatasi masalah ini, selesaikan langkah-langkah berikut:
Membatalkan operasi pembuatan cluster.
Hapus blok spec.binaryAuthorization dari
file konfigurasi cluster.
Buat cluster dengan Otorisasi Biner dinonaktifkan.
Direktori pemasangan dengan SELinux yang diaktifkan menyebabkan masalah
Jika Anda mengaktifkan SELinux dan memasang sistem file ke direktori terkait Kubernetes, Anda mungkin mengalami masalah seperti kegagalan pembuatan cluster, file yang tidak dapat dibaca, atau masalah izin.
Untuk menentukan 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 yang seharusnya
menampilkan label lain, seperti
system_u:object_r:container_var_lib_t:s0, Anda terpengaruh.
Solusi:
Jika Anda baru saja memasang sistem file ke direktori, pastikan direktori tersebut sudah diupdate dengan konfigurasi SELinux Anda.
Anda juga harus menjalankan perintah berikut di setiap mesin sebelum
menjalankan bmctl create cluster:
restorecon-R-v/var
restorecon-R-v/etc
Perbaikan satu kali ini akan tetap ada setelah mulai ulang, tetapi diperlukan setiap kali node baru dengan titik pemasangan yang sama ditambahkan. Untuk mempelajari lebih lanjut, lihat
Mounting File Systems dalam dokumentasi Red Hat.
Reset/Penghapusan
1.29.0
Reset cluster pengguna gagal saat mencoba menghapus namespace
Saat menjalankan bmctl reset cluster -c ${USER_CLUSTER},
setelah semua tugas terkait selesai, perintah gagal menghapus
namespace cluster pengguna. Namespace cluster pengguna macet dalam status
Terminating. Pada akhirnya, reset cluster akan mencapai batas waktu
dan menampilkan error.
Solusi:
Untuk menghapus namespace dan menyelesaikan reset cluster pengguna, ikuti
langkah-langkah berikut:
Setelah finalizer 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 Anda telah mengaktifkan
Otorisasi Biner
untuk Google Distributed Cloud dan menggunakan versi 1.16.0 hingga
1.16.7 atau 1.28.0 hingga 1.28.400, Anda mungkin mengalami masalah terkait
penjadwalan Pod untuk fitur tersebut. Dalam versi ini, Deployment Otorisasi Biner tidak memiliki nodeSelector, sehingga Pod untuk fitur tersebut dapat dijadwalkan di node pekerja, bukan di 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 akan di-deploy ulang hanya ke node
panel kontrol. Perbaikan ini harus diterapkan setelah setiap upgrade.
Upgrade dan update
1.28.0, 1.28.100, 1.28.200, 1.28.300
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 hal ini terjadi, log Pod deployer
pengontrol siklus proses akan memiliki pesan error yang mirip dengan berikut ini:
"inventorymachines.baremetal.cluster.gke.io\" is invalid: status.storedVersions[0]: Invalid value: \"v1alpha1\": must appear in spec.versions
Solusi:
Masalah ini telah diperbaiki di versi 1.28.400. Upgrade ke versi 1.28.400 atau yang lebih baru untuk mengatasi masalah ini.
Jika Anda tidak dapat melakukan upgrade, jalankan perintah berikut untuk menyelesaikan masalah:
ID project yang salah ditampilkan di Logs Explorer
Terkadang log cluster atau container diberi tag dengan project ID yang berbeda
di resource.labels.project_id di Logs Explorer.
Hal ini dapat terjadi saat cluster dikonfigurasi untuk menggunakan PROJECT_ONE observabilitas, yang ditetapkan di kolom clusterOperations.projectID dalam konfigurasi cluster.
Namun, cloudOperationsServiceAccountKeyPath dalam
konfigurasi memiliki kunci akun layanan dari project
PROJECT_TWO.
Dalam kasus tersebut, 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 dalam file JSON kunci akun layanan ke project saat ini.
Ubah project_id secara langsung di filter log dari Logs Explorer.
Jaringan
1.29, 1.30
Penurunan performa untuk cluster yang menggunakan load balancing gabungan dengan BGP
Untuk cluster versi 1.29.0 yang menggunakan load balancing gabungan dengan BGP,
performa load balancing dapat menurun saat 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 Layanan ini terjadi saat Deployment ang-controller-manager dihentikan karena kehabisan memori.
Jika cluster Anda terpengaruh oleh masalah ini, Layanan di cluster tidak dapat dijangkau dan tidak sehat, serta ang-controller-manager
Deployment berada dalam CrashLoopBackOff. Respons saat
mencantumkan ang-controller-manager Deployments akan mirip dengan
berikut ini:
Masalah konektivitas endpoint gcr.io Artifact Registry dapat memblokir operasi cluster
Beberapa operasi cluster untuk cluster admin membuat cluster bootstrap. Sebelum membuat cluster bootstrap, bmctl
melakukan pemeriksaan Google Cloud keterjangkauan dari workstation admin.
Pemeriksaan ini mungkin gagal karena masalah konektivitas dengan
endpoint Artifact Registry, gcr.io, dan Anda mungkin melihat
pesan error seperti berikut:
Untuk mengatasi masalah ini, coba lagi operasi dengan tanda
--ignore-validation-errors.
Jaringan
1.15, 1.16
GKE Dataplane V2 tidak kompatibel dengan beberapa driver penyimpanan
Cluster bare metal menggunakan GKE Dataplane V2, yang tidak kompatibel dengan beberapa penyedia penyimpanan. Anda mungkin mengalami
masalah dengan volume atau Pod 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 (volume layanan sharedv4)
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 di cluster besar
Anda mungkin melihat bahwa kube-state-metrics atau
Pod gke-metrics-agent yang ada di node yang sama dengan
kube-state-metrics kehabisan memori (OOM).
Hal ini dapat terjadi di cluster dengan lebih dari 50 node atau dengan banyak
objek Kubernetes.
Solusi
Untuk mengatasi masalah ini, perbarui definisi
resource kustom stackdriver agar menggunakan gerbang
fitur ksmNodePodMetricsOnly. Gerbang fitur ini memastikan bahwa hanya sejumlah kecil metrik penting yang ditampilkan.
Untuk menggunakan solusi ini, selesaikan langkah-langkah berikut:
Periksa definisi resource kustom stackdriver untuk
gerbang fitur yang tersedia:
Pemeriksaan pra-penerbangan gagal di RHEL 9.2 karena iptables tidak ada
Saat menginstal cluster di sistem operasi Red Hat Enterprise Linux (RHEL) 9.2, Anda mungkin mengalami kegagalan karena paket iptables tidak ada. Kegagalan terjadi selama pemeriksaan
pra-penerbangan dan memicu pesan error yang mirip dengan berikut ini:
'check_package_availability_pass':"The following packages are not available: ['iptables']"
RHEL 9.2 dalam Pratinjau
untuk Google Distributed Cloud versi 1.28.
Solusi
Lewati error pemeriksaan preflight dengan menyetel
spec.bypassPreflightCheck ke true di
Resource cluster Anda.
Operasi
1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16
Failover MetalLB yang lambat dalam skala besar
Jika MetalLB menangani sejumlah besar layanan (lebih dari 10.000),
pengalihan dapat memakan waktu lebih dari satu jam. Hal ini terjadi karena MetalLB menggunakan antrean yang dibatasi laju yang, saat berada di bawah skala tinggi, dapat memerlukan waktu beberapa saat untuk mencapai layanan yang perlu melakukan failover.
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 melakukan 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 menentukan variabel lingkungan HTTPS_PROXY dan NO_PROXY 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 di
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 menonaktifkan Cloud Audit Logs. Cloud Audit Logs diaktifkan secara default untuk cluster di versi 1.9 dan yang lebih tinggi.
Solusi
Jika Anda tidak dapat mengupgrade cluster ke versi 1.28.100-gke.146,
gunakan langkah-langkah berikut sebagai solusi untuk menyelesaikan upgrade cluster
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 agar sama dengan direktori induk, /var/log/apiserver.
Jaringan, Upgrade, dan update
1.28.0-gke.435
MetalLB tidak menetapkan alamat IP ke Layanan VIP
Google Distributed Cloud menggunakan MetalLB untuk
load balancing yang dibundel. Di Google Distributed Cloud
rilis 1.28.0-gke.435, MetalLB yang dibundel diupgrade ke versi 0.13,
yang memperkenalkan dukungan CRD untuk IPAddressPools. Namun,
karena ConfigMaps memungkinkan nama apa pun untuk IPAddressPool,
nama kumpulan harus dikonversi menjadi nama yang kompatibel dengan Kubernetes dengan
menambahkan hash di 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
pemilihan, konversi nama mencegah MetalLB melakukan pemilihan
kumpulan dan menetapkan alamat IP. Oleh karena itu, Layanan yang menggunakan
metallb.universe.tf/address-pool sebagai anotasi untuk memilih
kumpulan alamat untuk alamat IP tidak lagi menerima alamat IP dari
pengontrol MetalLB.
Masalah ini telah diperbaiki di Google Distributed Cloud versi 1.28.100-gke.146.
Solusi
Jika Anda tidak dapat mengupgrade cluster ke versi 1.28.100-gke.146, gunakan
langkah-langkah berikut sebagai solusi sementara:
Mendapatkan nama IPAddressPool yang dikonversi:
kubectlgetIPAddressPools-nkube-system
Perbarui 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 Layanan menjadi metallb.universe.tf/address-pool: default-qpvpd.
Hash yang digunakan dalam konversi nama bersifat deterministik, sehingga
solusinya bersifat persisten.
Upgrade dan update
1.14, 1.15, 1.16, 1.28, 1.29
Pod yatim setelah mengupgrade ke versi 1.14.x
Saat Anda mengupgrade cluster ke versi 1.14.x, beberapa
resource dari versi sebelumnya tidak akan dihapus. Secara khusus, Anda
mungkin melihat sekumpulan pod yang tidak terkait seperti berikut:
Masalah ini telah diperbaiki di Google Distributed Cloud versi 1.15.0 dan yang lebih tinggi.
Penginstalan
1,14
Pembuatan cluster terhenti pada tugas machine-init
Jika Anda mencoba menginstal Google Distributed Cloud versi 1.14.x, Anda mungkin mengalami kegagalan karena tugas machine-init, mirip dengan contoh output berikut:
Hapus anggota etcd yang sudah tidak digunakan dan menyebabkan tugas
machine-init gagal. Selesaikan langkah-langkah berikut di node bidang kontrol yang berfungsi:
Cilium-operator tidak ada Node list dan
izin watch
Di Cilium 1.13, izin cilium-operator ClusterRole
salah. Izin Node list dan
watch tidak ada. cilium-operator gagal memulai pengumpul sampah, yang menyebabkan masalah berikut:
Kebocoran resource Cilium.
Identitas yang tidak aktif tidak dihapus dari peta kebijakan BFP.
Peta kebijakan dapat mencapai batas 16 ribu.
Entri baru tidak dapat ditambahkan.
Penerapan NetworkPolicy yang salah.
Identitas dapat 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.742276761Zlevel=errormsg=k8sErrorerror="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 saat tidak dapat menyisipkan entri ke dalam peta kebijakan, seperti contoh berikut:
level=errormsg="Failed to add PolicyMap key"bpfMapKey="{6572100 0 0 0}"containerID=datapathPolicyRevision=0desiredPolicyRevision=7endpointID=1313error="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=128ipv4=ipv6=k8sPodName=/port=0subsys=endpoint
Solusi:
Hapus identitas Cilium, lalu tambahkan izin ClusterRole yang tidak ada ke operator:
Hapus objek CiliumIdentity yang ada:
kubectldeleteciliumid–-all
Edit objek ClusterRole cilium-operator:
kubectleditclusterrolecilium-operator
Tambahkan bagian untuk nodes yang mencakup izin yang tidak ada, seperti yang ditunjukkan dalam contoh berikut:
Error ini dapat diabaikan dengan aman. Jika Anda mengalami error ini yang
memblokir upgrade, jalankan kembali perintah upgrade.
Jika Anda melihat error ini saat menjalankan pra-penerbangan menggunakan
perintah bmctl preflightcheck, tidak ada yang diblokir oleh
kegagalan ini. Anda dapat menjalankan pemeriksaan pra-cetak lagi untuk mendapatkan informasi pra-cetak yang akurat.
Solusi:
Jalankan kembali perintah upgrade, atau jika terjadi 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 berkala
setelah node diganti atau dihapus. Jika cluster Anda menjalani health check berkala, hasil health check jaringan berkala akan gagal setelah penggantian atau penghapusan node, karena ConfigMap inventaris jaringan tidak diperbarui setelah dibuat.
Solusi:
Solusi yang direkomendasikan adalah menghapus ConfigMap inventaris dan
health check jaringan berkala. Operator cluster secara otomatis
membuat ulang dengan informasi terbaru.
Network Gateway untuk GDC tidak dapat menerapkan konfigurasi Anda jika nama perangkat berisi titik
Jika Anda memiliki perangkat jaringan yang menyertakan karakter titik
(.) dalam nama, seperti bond0.2,
Network Gateway for GDC memperlakukan titik sebagai jalur dalam
direktori saat menjalankan sysctl untuk melakukan perubahan. Saat
Network Gateway for GDC memeriksa apakah deteksi alamat duplikat
(DAD) diaktifkan, pemeriksaan mungkin gagal dan tidak akan merekonsiliasi.
Perilakunya berbeda di antara versi cluster:
1.14 dan 1.15: Error ini hanya ada saat Anda menggunakan alamat IP mengambang IPv6. Jika Anda tidak menggunakan alamat IP mengambang IPv6, Anda tidak akan melihat masalah ini saat nama perangkat Anda berisi titik.
1.16.0 - 1.16.2: Error ini selalu ada saat nama perangkat Anda berisi titik.
Solusi:
Upgrade cluster Anda ke versi 1.16.3 atau yang lebih baru.
Sebagai solusi sementara hingga Anda dapat mengupgrade cluster, hapus titik
(.) dari nama perangkat.
Upgrade dan update, Jaringan, Keamanan
1.16.0
Upgrade ke 1.16.0 gagal saat seccomp dinonaktifkan
Jika seccomp dinonaktifkan untuk cluster Anda
(spec.clusterSecurity.enableSeccomp disetel ke false),
maka upgrade ke versi 1.16.0 akan gagal.
Google Distributed Cloud versi 1.16 menggunakan Kubernetes versi 1.27.
Di Kubernetes versi 1.27.0 dan yang lebih tinggi, fitur untuk menyetel
profil seccomp sudah tersedia secara umum dan tidak lagi menggunakan
gerbang fitur.
Perubahan Kubernetes ini menyebabkan upgrade ke versi 1.16.0 gagal saat
seccomp dinonaktifkan dalam konfigurasi cluster. Masalah ini
telah diperbaiki di cluster versi 1.16.1 dan yang lebih tinggi. Jika Anda
telah menetapkan kolom cluster.spec.clusterSecurity.enableSeccomp
ke false, Anda dapat mengupgrade ke versi 1.16.1 atau yang lebih tinggi.
Kluster dengan spec.clusterSecurity.enableSeccomp yang tidak ditetapkan atau
ditetapkan ke true tidak terpengaruh.
Metadata containerd dapat rusak setelah dimulai ulang saat
/var/lib/containerd di-mount
Jika Anda telah memasang /var/lib/containerd secara opsional, metadata
containerd mungkin 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 dudukan opsional ditentukan
di /etc/fstab untuk /var/lib/containerd/ dan memiliki
nofail di 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
Menghapus Pod yang sudah tidak berlaku 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 mencantumkan
Pod yang dapat Anda bersihkan:
kubectlgetpods–A|grepTaintToleration
Contoh output berikut menampilkan Pod dengan status
TaintToleration:
Untuk setiap Pod dengan gejala yang dijelaskan, periksa ReplicaSet tempat
Pod berada. Jika ReplicaSet sudah puas, Anda dapat menghapus Pod:
Dapatkan ReplicaSet yang mengelola Pod dan temukan nilai
ownerRef.Kind:
kubectlgetpodPOD_NAME-nNAMESPACE-oyaml
Dapatkan ReplicaSet dan verifikasi bahwa status.replicas
sama dengan spec.replicas:
kubectlgetreplicasetREPLICA_NAME-nNAMESPACE-oyaml
Jika nama cocok, hapus Pod:
kubectldeletepodPOD_NAME-nNAMESPACE.
Upgrade
1.16.0
etcd-events dapat terhenti saat upgrade ke versi 1.16.0
Saat Anda mengupgrade cluster yang ada ke versi 1.16.0, kegagalan Pod
yang terkait dengan etcd-events dapat menghentikan operasi. Secara khusus,
tugas upgrade-node gagal pada
langkah TASK [etcd_events_install : Run etcdevents].
Jika Anda terpengaruh oleh masalah ini, Anda akan melihat kegagalan Pod seperti berikut:
Pod kube-apiserver gagal dimulai dengan
error berikut:
connectionerror:desc="transport: Error while dialing dial tcp 127.0.0.1:2382: connect: connection refused"
Pod etcd-events gagal dimulai dengan error berikut:
Error ini menunjukkan peristiwa pengusiran atau ketidakmampuan untuk menjadwalkan Pod
karena resource node. Karena tidak memiliki PriorityClass, Network Gateway untuk Pod GDC memiliki prioritas default yang sama dengan workload lainnya.
Jika node kekurangan resource, Pod gateway jaringan mungkin
dikeluarkan. Perilaku ini sangat buruk untuk DaemonSet ang-node, karena Pod tersebut harus dijadwalkan di node tertentu dan tidak dapat bermigrasi.
Solusi:
Upgrade ke 1.15 atau yang lebih baru.
Sebagai solusi jangka pendek, Anda dapat menetapkan
PriorityClass
secara manual ke komponen Network Gateway for GDC. Pengontrol Google Distributed Cloud
akan menimpa perubahan manual ini selama proses rekonsiliasi, seperti
selama upgrade cluster.
Tetapkan PriorityClass system-cluster-critical ke
Deployment pengontrol
cluster ang-controller-manager dan autoscaler.
Tetapkan PriorityClass system-node-critical ke DaemonSet node ang-daemon.
Penginstalan, Upgrade, dan update
1.15.0, 1.15.1, 1.15.2
Pembuatan dan upgrade cluster gagal karena panjang nama cluster
Membuat 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
lebih panjang dari 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 membuat resource pemeriksaan kondisi 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 63 karakter Kubernetes untuk nama
label, yang mencegah pembuatan resource health check.
Tanpa health check yang berhasil, operasi cluster akan gagal.
Untuk melihat apakah Anda terpengaruh oleh masalah ini, gunakan kubectl describe
untuk memeriksa resource yang gagal:
Untuk membatalkan pemblokiran upgrade atau pembuatan cluster, Anda dapat melewati pemeriksaan kondisi. Gunakan perintah berikut untuk mem-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 cluster versi 1.14.0 dan 1.14.1 mengaktifkan fitur pratinjau,
cluster tersebut tidak dapat diupgrade ke versi 1.15.x. Hal ini berlaku untuk fitur pratinjau seperti kemampuan untuk membuat cluster tanpa kube-proxy, yang diaktifkan dengan anotasi berikut dalam file konfigurasi cluster:
Masalah ini telah diperbaiki di cluster versi 1.14.2 dan yang lebih tinggi.
Solusi:
Jika Anda 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:
bmctlupgradecluster--use-bootstrap=true
Operasi
1,15
Cluster versi 1.15 tidak menerima alamat IP mengambang duplikat
Network Gateway for GDC tidak memungkinkan Anda membuat NetworkGatewayGroup
resource kustom baru yang berisi alamat IP di spec.floatingIPs
yang sudah digunakan dalam resource kustom NetworkGatewayGroup yang ada. Aturan ini diterapkan oleh webhook di cluster bare metal versi 1.15.0 dan yang lebih tinggi. Alamat IP mengambang duplikat yang sudah ada tidak menyebabkan error. Webhook hanya mencegah pembuatan
resource kustom NetworkGatewayGroups baru yang berisi alamat
IP duplikat.
Pesan error webhook mengidentifikasi alamat IP yang bertentangan dan
resource kustom yang ada yang sudah menggunakannya:
IPaddressexistsinothergatewaywithnamedefault
Dokumentasi awal untuk fitur jaringan tingkat lanjut, seperti
gateway NAT Egress, tidak memperingatkan terhadap alamat IP duplikat.
Awalnya, hanya resource NetworkGatewayGroup bernama
default yang dikenali oleh rekonsiliasi. Network Gateway untuk GDC
kini mengenali semua resource kustom NetworkGatewayGroup
dalam namespace sistem. Resource kustom NetworkGatewayGroup
yang ada akan dipertahankan seperti apa adanya.
Solusi:
Error terjadi saat pembuatan resource kustom NetworkGatewayGroup
baru saja.
Untuk mengatasi error:
Gunakan perintah berikut untuk mencantumkan resource kustom NetworkGatewayGroups:
Untuk menerapkan perubahan, tutup dan simpan resource kustom yang 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 diupgrade yang menggunakan registry pribadi, VM yang terhubung ke jaringan node atau menggunakan GPU mungkin tidak dimulai dengan benar. Masalah ini disebabkan oleh beberapa
Pod sistem di namespace vm-system yang mengalami error
saat menarik image. Misalnya, jika VM Anda menggunakan jaringan node, beberapa Pod mungkin melaporkan error penarikan image seperti berikut:
macvtap-4x9zp0/1Init:ImagePullBackOff070m
Masalah ini telah diperbaiki di cluster versi 1.14.0 dan yang lebih tinggi.
Solusi
Jika tidak dapat mengupgrade cluster Anda dengan segera, Anda dapat menarik
image secara manual. Perintah berikut menarik image plugin CNI macvtap
untuk VM Anda dan mengirimkannya ke registry pribadi Anda:
Ganti REG_HOST dengan nama domain host yang Anda mirror secara lokal.
Penginstalan
1.11, 1.12
Selama pembuatan cluster di cluster jenis, pod gke-metric-agent gagal dimulai
Selama pembuatan cluster di cluster kind, pod gke-metrics-agent
gagal dimulai karena error penarikan image 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 kluster bootstrap, Anda akan melihat entri berikut:
Sep1323:54:20bmctl-control-planecontainerd[198]:time="2022-09-13T23:54:20.378172743Z"level=infomsg="PullImage \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\" "Sep1323:54:21bmctl-control-planecontainerd[198]:time="2022-09-13T23:54:21.057247258Z"level=errormsg="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
Meskipun terjadi error, proses pembuatan cluster tidak diblokir karena
tujuan pod gke-metrics-agent di cluster kind adalah untuk memfasilitasi
tingkat keberhasilan pembuatan cluster serta untuk pelacakan dan pemantauan internal.
Oleh karena itu, Anda dapat mengabaikan error ini.
Solusi
Meskipun terjadi error, proses pembuatan cluster tidak diblokir karena
tujuan pod gke-metrics-agent di cluster kind 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 Service IPv6 menyebabkan Node LoadBalancer error di
CentOS atau RHEL
Saat Anda mengakses Layanan stack ganda (Layanan yang memiliki endpoint IPv4 dan
IPv6) dan menggunakan endpoint IPv6, Node LoadBalancer yang
menayangkan Layanan mungkin mengalami error. Masalah ini memengaruhi pelanggan yang menggunakan
layanan dual-stack dengan CentOS atau RHEL dan versi kernel yang lebih lama dari
kernel-4.18.0-372.46.1.el8_6.
Jika Anda yakin bahwa masalah ini memengaruhi Anda, periksa versi kernel di
Node LoadBalancer menggunakan perintah uname -a.
Solusi:
Update Node LoadBalancer ke kernel versi
kernel-4.18.0-372.46.1.el8_6 atau yang lebih baru. Versi kernel ini tersedia secara default di CentOS dan RHEL versi 8.6 dan yang lebih baru.
Jaringan
1.11, 1.12, 1.13, 1.14.0
Masalah konektivitas terputus-putus setelah Node di-reboot
Setelah memulai ulang Node, Anda mungkin melihat masalah konektivitas
intermiten untuk Layanan NodePort atau LoadBalancer. Misalnya, Anda mungkin mengalami
error handshake TLS atau reset koneksi yang terjadi sesekali. Masalah ini telah
diperbaiki untuk versi cluster 1.14.1 dan yang lebih tinggi.
Untuk memeriksa apakah masalah ini memengaruhi Anda, lihat aturan penerusan iptables
di Node tempat Pod backend untuk Layanan yang terpengaruh berjalan:
sudoiptables-LFORWARD
Jika Anda melihat aturan KUBE-FORWARD sebelum aturan
CILIUM_FORWARD di iptables, Anda mungkin
terpengaruh oleh masalah ini. Contoh output berikut menunjukkan Node tempat
masalah terjadi:
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 di Node yang salah dikonfigurasi. Setelah Anda
memulai ulang Pod anetd, aturan penerusan di iptables harus
dikonfigurasi dengan benar.
Contoh output berikut menunjukkan bahwa aturan CILIUM_FORWARD
kini 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 mempertahankan informasi izin dan pemilik asli
Fitur pratinjau cluster 1.9.x menggunakan bmctl 1.9.x tidak mempertahankan
informasi pemilik dan izin asli. Untuk memverifikasi apakah Anda terpengaruh oleh fitur ini, ekstrak file yang dicadangkan menggunakan perintah berikut:
tar-xzvfBACKUP_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 Anda telah mengupgrade ke atau membuat cluster versi 1.14.2 dengan konfigurasi OIDC/LDAP, Anda mungkin melihat Pod clientconfig-operatormacet dalam status tertunda. Dengan masalah ini, ada dua
Pod clientconfig-operator, dengan satu 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 di
versi 1.14.3 dan semua rilis berikutnya, termasuk 1.15.0 dan yang lebih baru.
Solusi:
Sebagai solusinya, Anda dapat menerapkan patch pada deployment clientconfig-operator
untuk menambahkan konteks keamanan tambahan dan memastikan bahwa deployment
siap.
Gunakan perintah berikut untuk menerapkan 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 gabungan
Untuk cluster tanpa load balancing gabungan (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 berhenti merespons:
SigningCAcompletedin3/0control-planenodes
Dalam hal ini, perintah akan gagal. Log rotate certificate-authority
untuk cluster dengan tiga bidang kontrol dapat mencakup entri seperti
berikut:
Jika Anda memerlukan bantuan tambahan, hubungi
Dukungan Google.
Instalasi, Jaringan
1.11, 1.12, 1.13, 1.14.0-1.14.1
ipam-controller-manager crashloop di cluster
dual-stack
Saat Anda men-deploy cluster stack ganda (cluster dengan alamat IPv4 dan IPv6), Pod ipam-controller-manager mungkin mengalami crashloop. Perilaku ini menyebabkan Node berganti-ganti antara status
Ready dan NotReady, dan dapat menyebabkan
penginstalan cluster gagal. Masalah ini dapat terjadi saat server API
mengalami beban tinggi.
Untuk melihat apakah masalah ini memengaruhi Anda, periksa apakah Pod ipam-controller-manager gagal dengan error CrashLoopBackOff:
Dapatkan detail untuk Node yang dalam status NotReady:
kubectldescribenode<node-name>|grepPodCIDRs
Di cluster yang mengalami masalah ini, Node tidak memiliki PodCIDR yang ditetapkan,
seperti yang ditunjukkan dalam contoh output berikut:
PodCIDRs:
Dalam cluster yang sehat, semua Node harus memiliki PodCIDR dual-stack yang ditetapkan ke Node tersebut, seperti yang ditunjukkan dalam contoh output berikut:
1.6, 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13, dan 1.14
Kekurangan sumber daya etcd watch
Cluster yang menjalankan etcd versi 3.4.13 atau yang lebih lama dapat mengalami kekurangan watch dan watch resource yang tidak beroperasi, yang dapat menyebabkan masalah berikut:
Penjadwalan Pod terganggu
Node tidak dapat mendaftar
kubelet tidak mengamati perubahan pod
Masalah ini dapat membuat 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 mengupgrade segera, 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 Pilih metrik, 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.
Jaringan
1.11.6, 1.12.3
Status mode vfio-pci operator SR-IOV "Gagal"
syncStatus objek SriovNetworkNodeState
dapat melaporkan nilai "Gagal" untuk node yang dikonfigurasi. Untuk melihat status
node dan menentukan apakah masalah tersebut memengaruhi Anda, jalankan
perintah berikut:
Ganti NODE_NAME dengan nama node yang akan
diperiksa.
Solusi:
Jika status objek SriovNetworkNodeState adalah "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 node pekerja tidak dalam status Siap setelah upgrade
Setelah upgrade selesai, beberapa node pekerja mungkin memiliki kondisi Siap yang ditetapkan ke false. Pada resource Node, Anda akan melihat error di samping kondisi Siap 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 di komputer tersebut kosong:
sudols/etc/cni/net.d/
Solusi
Mulai ulang pod anetd node dengan menghapusnya.
Upgrade dan update, Keamanan
1.10
Beberapa rotasi sertifikat dari cert-manager menyebabkan inkonsistensi
Setelah beberapa rotasi sertifikat manual atau otomatis, pod webhook,
seperti anthos-cluster-operator tidak diperbarui dengan sertifikat baru
yang dikeluarkan oleh cert-manager. Setiap update pada resource kustom
cluster gagal dan menghasilkan error serupa 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 mungkin terjadi dalam situasi berikut:
Jika Anda telah melakukan dua rotasi sertifikat yang dikeluarkan cert-manager secara manual
pada cluster yang berusia 180 hari atau lebih dan tidak pernah memulai ulang anthos-cluster-operator.
Jika Anda telah melakukan rotasi sertifikat yang dikeluarkan secara manual cert-manager pada cluster yang berusia 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 yang sudah tidak berlaku yang dibuat selama upgrade cluster pengguna
Di 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 di
versi yang lebih rendah dari 1.12. Pod yang dibuat secara tidak sengaja tidak menghalangi
operasi upgrade, tetapi mungkin ditemukan dalam status yang tidak terduga. Kami
merekomendasikan agar 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:
Status BGPSession terus berubah karena banyaknya rute masuk
Jaringan canggih Google Distributed Cloud gagal mengelola sesi BGP dengan benar saat peer eksternal mengiklankan sejumlah besar rute (sekitar 100 atau lebih). Dengan sejumlah besar rute masuk, pengontrol BGP lokal node membutuhkan waktu terlalu lama untuk menyelaraskan sesi BGP dan gagal memperbarui status. Tidak adanya update status, atau health check, menyebabkan sesi
dihapus karena tidak aktif.
Perilaku yang tidak diinginkan pada sesi BGP yang mungkin Anda perhatikan dan menunjukkan
adanya masalah meliputi hal berikut:
Penghapusan dan pembuatan ulang bgpsession secara berkelanjutan.
bgpsession.status.state tidak pernah menjadi
Established
Rute gagal diiklankan atau diiklankan berulang kali dan
dibatalkan.
Masalah load balancing BGP mungkin terlihat dengan masalah konektivitas ke layanan LoadBalancer.
Masalah BGP FlatIP mungkin terlihat dengan masalah konektivitas ke Pod.
Untuk menentukan apakah masalah BGP 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 menampilkan bgpsessions dengan status "Not Established"
dan waktu pelaporan terakhir terus bertambah hingga sekitar 10-12 detik
sebelum direset ke nol.
Output kubectl get bgpsessions menunjukkan bahwa sesi yang terpengaruh dibuat ulang berulang kali:
Pesan log menunjukkan bahwa sesi BGP yang tidak aktif sedang dihapus:
kubectllogsang-controller-manager-POD_NUMBER
Ganti POD_NUMBER dengan pod
leader di cluster Anda.
Solusi:
Kurangi atau hilangkan jumlah rute yang diiklankan dari peer
jarak jauh ke cluster dengan kebijakan ekspor.
Pada versi cluster 1.14.2 dan yang lebih baru, Anda juga dapat menonaktifkan
fitur yang memproses rute yang diterima dengan menggunakan
AddOnConfiguration. Tambahkan
argumen --disable-received-routes ke ang-daemon
container bgpd daemonset.
Jaringan
1.14, 1.15, 1.16, 1.28
Waktu tunggu aplikasi habis karena kegagalan penyisipan tabel conntrack
Cluster yang berjalan di OS Ubuntu yang menggunakan kernel 5.15 atau yang lebih tinggi rentan terhadap kegagalan penyisipan tabel pelacakan koneksi (conntrack) netfilter. Kegagalan penyisipan dapat terjadi meskipun tabel conntrack memiliki ruang untuk entri baru. Kegagalan disebabkan oleh perubahan pada
kernel 5.15 dan yang lebih tinggi yang membatasi penyisipan tabel berdasarkan panjang
rantai.
Untuk melihat apakah Anda terpengaruh oleh masalah ini, Anda dapat memeriksa statistik sistem pelacakan koneksi dalam kernel dengan perintah berikut:
Jika nilai chaintoolong dalam respons adalah angka
bukan nol, Anda terpengaruh oleh masalah ini.
Solusi
Mitigasi jangka pendek adalah dengan meningkatkan ukuran tabel hash netfilter (nf_conntrack_buckets) dan tabel pelacakan koneksi netfilter (nf_conntrack_max). Gunakan perintah berikut di setiap node cluster untuk meningkatkan ukuran tabel:
Ganti TABLE_SIZE dengan ukuran baru dalam byte. Nilai
ukuran tabel default adalah 262144. Sebaiknya tetapkan
nilai yang sama dengan 65.536 kali jumlah core di 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 Anda sebelum melakukan upgrade agar Anda dapat memulihkan versi sebelumnya jika upgrade tidak berhasil.
Masalah pada perintah bmctl restore cluster menyebabkan perintah tersebut gagal memulihkan cadangan cluster dengan versi yang diidentifikasi. Masalah
ini khusus untuk upgrade, saat Anda memulihkan cadangan versi
sebelumnya.
Jika cluster Anda terpengaruh, log bmctl restore cluster
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.
Jaringan
1.10, 1.11, 1.12, 1.13, 1.14.0-1.14.2
NetworkGatewayGroup akan 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 kegagalan fitur seperti
BGP LB dan EgressNAT. Jika Anda memeriksa log Pod
ang-node yang gagal di namespace kube-system, error
yang mirip dengan contoh berikut akan ditampilkan saat 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 akan ditampilkan jika
node tidak memiliki alamat IPv4.
NetworkGatewayGroup mencoba membuat koneksi ARP dan
koneksi NDP ke alamat IP link-local. Jika alamat IP tidak ada (IPv4 untuk ARP, IPv6 untuk NDP), koneksi akan gagal dan daemon tidak akan berlanjut.
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. Dalam entri log contoh sebelumnya, antarmuka
ini adalah ens192:
ipaddressadddevINTERFACEscopelinkADDRESS
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
anthos-cluster-operator crash loop 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 ini telah diperbaiki di 1.13.3 dan 1.14.0 serta versi yang lebih baru. Semua versi lainnya terpengaruh. Upgrade ke salah satu versi yang telah diperbaiki
Sebagai solusi sementara, jalankan perintah berikut:
IP_ADDRESS: Alamat IP
node dalam status loop error.
CLUSTER_NAMESPACE: Namespace cluster.
Penginstalan
1.13.1, 1.13.2, dan 1.13.3
kubeadm join gagal di cluster besar karena ketidakcocokan token
Saat menginstal cluster dengan sejumlah besar node, 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 diselesaikan 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 tambahan
setelah penginstalan selesai.
Logging dan pemantauan
1.10, 1.11, 1.12, 1.13.0
Batas CPU rendah untuk metrics-server di cluster Edge
Di cluster Google Distributed Cloud Edge, batas CPU yang rendah untuk
metrics-server dapat menyebabkan seringnya mulai ulang
metrics-server. Horizontal Pod Autoscaling (HPA) tidak berfungsi
karena metrics-server tidak sehat.
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 yang ditunjukkan dalam 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.
Jaringan
1.14, 1.15, 1.16
Koneksi NodePort langsung ke Pod hostNetwork tidak berfungsi
Koneksi ke Pod yang diaktifkan dengan hostNetwork menggunakan Service
NodePort gagal saat Pod backend berada di node yang sama dengan
NodePort target. Masalah ini memengaruhi Layanan LoadBalancer saat digunakan dengan
Pod hostNetwork. Dengan beberapa backend, dapat terjadi kegagalan koneksi sporadis.
Masalah ini disebabkan oleh bug dalam program eBPF.
Solusi:
Saat menggunakan Layanan NodePort, jangan menargetkan node tempat Pod backend berjalan. Saat menggunakan Layanan LoadBalancer, pastikan Pod dengan
hostNetwork tidak berjalan di node LoadBalancer.
Upgrade dan update
1.12.3, 1.13.0
Cluster admin 1.13.0 tidak dapat mengelola cluster pengguna 1.12.3
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 node pool 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 dengan kumpulan node pekerja diblokir. Jika upgrade cluster admin Anda terhenti, Anda dapat mengonfirmasi
apakah penyebabnya adalah kumpulan node pekerja dengan memeriksa 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=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
petunjuk cara menambahkan dan menghapus node pool, lihat
Mengelola node pool dalam cluster.
Upgrade dan update
1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28
Error saat mengupdate resource menggunakan kubectl apply
Jika Anda memperbarui resource yang ada seperti ClientConfig atau
resource kustom Stackdriver menggunakan kubectl apply,
pengontrol dapat menampilkan error atau mengembalikan input dan perubahan yang direncanakan.
Misalnya, Anda dapat mencoba mengedit resource kustom Stackdriver
sebagai berikut dengan terlebih dahulu mendapatkan resource, lalu menerapkan versi yang diperbarui:
Aktifkan fitur atau perbarui konfigurasi di file YAML.
Terapkan kembali file YAML yang diperbarui:
kubectlapply-fstackdriver.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 dalam contoh berikut:
Edit resource kustom Stackdriver:
kubectleditstackdriver-nkube-systemstackdriver
Aktifkan fitur atau perbarui konfigurasi di file YAML.
Chunk backlog yang rusak menyebabkan loop error stackdriver-log-forwarder
stackdriver-log-forwarder mengalami loop error jika mencoba
memproses potongan backlog yang rusak. Contoh error berikut ditampilkan dalam
log penampung:
[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 crashloop ini terjadi, Anda tidak dapat melihat log di Cloud Logging.
Solusi:
Untuk mengatasi error ini, selesaikan langkah-langkah berikut:
Identifikasi bagian 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 yang gagal pemeriksaan format harus dihapus.
Akhiri pod yang berjalan untuk stackdriver-log-forwarder:
Memulai ulang Dataplane V2 (anetd) di cluster dapat menyebabkan
VM yang ada tidak dapat terhubung ke non-pod-network
Di cluster multi-NIC, memulai ulang Dataplane V2 (anetd) dapat
menyebabkan mesin virtual tidak dapat terhubung ke jaringan. Error
yang serupa dengan berikut mungkin terlihat 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 solusi 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 pada cluster profil Edge
Bergantung pada workload cluster, gke-metrics-agent
mungkin menggunakan memori lebih dari 4.608 MiB. Masalah ini hanya memengaruhi
cluster profil Edge Google Distributed Cloud untuk bare metal. Kluster 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 persaingan
Saat Anda membuat cluster menggunakan kubectl, karena kondisi
persaingan, pemeriksaan pra-penerbangan mungkin tidak akan pernah selesai. Akibatnya, pembuatan cluster
dapat gagal dalam kasus tertentu.
Penyelarasan pemeriksaan pra-penerbangan membuat SecretForwarder
untuk menyalin rahasia ssh-key default ke namespace target.
Biasanya, pemeriksaan awal memanfaatkan referensi pemilik dan
melakukan rekonsiliasi setelah SecretForwarder selesai. Namun, dalam
kasus yang jarang terjadi, referensi pemilik SecretForwarder dapat
kehilangan referensi ke pemeriksaan pra-penerbangan, sehingga menyebabkan pemeriksaan pra-penerbangan
macet. Akibatnya, pembuatan cluster gagal. Untuk melanjutkan
rekonsiliasi untuk pemeriksaan pra-peluncuran yang dikontrol pengontrol, hapus pod
cluster-operator atau hapus resource preflight-check. Saat Anda
menghapus resource pemeriksaan awal, resource tersebut akan membuat resource lain dan melanjutkan
rekonsiliasi. Atau, Anda dapat mengupgrade cluster yang ada
(yang dibuat dengan versi sebelumnya) ke versi tetap.
Jaringan
1.9, 1.10, 1.11, 1.12, 1.13, 1.14, 1.15
Alamat IP yang dicadangkan tidak dilepaskan saat menggunakan plugin lokasi dengan fitur multi-NIC
Pada fitur multi-Nic, jika Anda menggunakan plugin CNI whereabouts
dan Anda menggunakan operasi CNI DEL untuk menghapus antarmuka jaringan untuk Pod,
beberapa alamat IP yang dicadangkan mungkin tidak dilepaskan dengan benar. Hal ini terjadi
saat operasi DEL CNI terganggu.
Anda dapat memverifikasi reservasi alamat IP Pod yang tidak digunakan dengan menjalankan perintah berikut:
kubectlgetippools-A--kubeconfigKUBECONFIG_PATH
Solusi:
Hapus alamat IP (ippools) yang tidak digunakan secara manual.
Penginstalan
1.10, 1.11.0, 1.11.1, 1.11.2
Node Problem Detector gagal di cluster pengguna 1.10.4
Node Problem Detector mungkin gagal di cluster pengguna versi 1.10.x,
saat cluster admin versi 1.11.0, 1.11.1, atau 1.11.2
mengelola cluster pengguna 1.10.x. Jika Node Problem Detector gagal, log akan diperbarui dengan pesan error berikut:
Upgrade cluster admin ke 1.11.3 untuk menyelesaikan masalah ini.
Operasi
1,14
Node cluster IPv4 mode pulau 1.14 memiliki ukuran mask CIDR pod 24
Pada rilis 1.14, setelan maxPodsPerNode tidak diperhitungkan untuk cluster mode terisolasi, sehingga node diberi ukuran mask CIDR pod 24 (256 alamat IP).Hal ini dapat menyebabkan cluster kehabisan alamat IP pod lebih cepat dari yang diharapkan. Misalnya, jika cluster Anda memiliki ukuran mask CIDR pod 22; setiap node akan diberi mask CIDR pod 24 dan cluster hanya dapat mendukung hingga 4 node. Cluster Anda juga dapat mengalami ketidakstabilan jaringan dalam periode churn pod yang tinggi jika maxPodsPerNode disetel ke 129 atau yang 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 1.14.1 atau versi yang lebih baru.
Hapus node pekerja 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:
Ganti HEALTHCHECK_RESOURCE_NAME dengan
nama resource pemeriksaan kesehatan.
Jalankan kembali perintah bmctl restore cluster.
Jaringan
1.12.0
Alamat IP eksternal layanan tidak berfungsi dalam mode datar
Di cluster yang memiliki flatIPv4 yang ditetapkan ke true,
Layanan jenis LoadBalancer tidak dapat diakses oleh alamat IP eksternalnya.
Masalah ini telah diperbaiki di versi 1.12.1.
Solusi:
Di ConfigMap cilium-config, 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 di tempat dari 1.13.0 ke
1.14.x menggunakan bmctl 1.14.0 dan
flag --use-bootstrap=false, upgrade tidak akan pernah selesai.
Error pada operator preflight-check menyebabkan
cluster tidak pernah menjadwalkan pemeriksaan yang diperlukan, yang berarti pemeriksaan
penerbangan tidak pernah selesai.
Solusi:
Lakukan upgrade ke 1.13.1 terlebih dahulu sebelum melakukan upgrade ke 1.14.x. Upgrade di tempat
dari 1.13.0 ke 1.13.1 akan berfungsi. Atau, upgrade dari 1.13.0 ke
1.14.x tanpa tanda --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 di node tersebut. Saat Anda mengupgrade cluster versi 1.13 ke versi 1.14.0, node bidang kontrol akan kehilangan taint wajib berikut:
node-role.kubernetes.io/master:NoSchedule
node-role.kubernetes.io/master:PreferNoSchedule
Masalah ini tidak menyebabkan kegagalan upgrade, tetapi pod yang seharusnya tidak berjalan di node bidang kontrol dapat mulai melakukannya. Pod workload ini dapat membebani node bidang kontrol dan menyebabkan ketidakstabilan cluster.
Menentukan apakah Anda terpengaruh
Untuk menemukan node bidang kontrol, gunakan perintah berikut:
Jika kedua taint yang diperlukan tidak tercantum, berarti Anda terpengaruh.
Solusi
Gunakan langkah-langkah berikut untuk setiap node panel kontrol cluster versi 1.14.0 yang terpengaruh untuk memulihkan fungsi yang tepat. Langkah-langkah ini ditujukan untuk
pengotoran node-role.kubernetes.io/master:NoSchedule dan pod
terkait. Jika Anda ingin node bidang kontrol menggunakan taint PreferNoSchedule, sesuaikan langkah-langkahnya.
Pembuatan VM gagal secara berkala dengan error upload
Membuat Virtual Machine (VM) baru dengan perintah kubectl virt create vm
sesekali gagal selama upload image. Masalah ini berlaku untuk
VM Linux dan Windows. Error tersebut terlihat seperti contoh berikut:
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 dalam upgrade ke 1.12
Komponen pengumpulan terkelola adalah bagian dari Managed Service for Prometheus.
Jika Anda men-deploy
komponen koleksi terkelola
secara manual di namespace gmp-system pada
cluster versi 1.11, resource terkait tidak
dipertahankan saat Anda mengupgrade ke versi 1.12.
Mulai dari cluster versi 1.12.0, komponen Managed Service for Prometheus di namespace gmp-system dan definisi resource kustom terkait dikelola oleh stackdriver-operator dengan kolom enableGMPForApplications. Kolom enableGMPForApplications secara default adalah
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:
Mencadangkan semua resource kustom PodMonitoring yang ada.
Deploy ulang resource kustom PodMonitoring di cluster yang diupgrade.
Upgrade dan update
1.13
Beberapa cluster versi 1.12 dengan runtime container Docker tidak dapat
diupgrade ke versi 1.13
Jika cluster versi 1.12 yang menggunakan runtime container Docker
tidak memiliki anotasi berikut, cluster tersebut tidak dapat diupgrade ke versi 1.13:
Hal ini kemungkinan besar terjadi pada cluster Docker versi 1.12 yang
diupgrade dari 1.11, karena upgrade tersebut tidak memerlukan anotasi
untuk mempertahankan runtime container Docker. Dalam hal ini, cluster tidak memiliki
anotasi saat diupgrade ke 1.13. Perhatikan bahwa mulai
versi 1.13, containerd adalah satu-satunya runtime container yang diizinkan.
Solusi:
Jika Anda terpengaruh oleh masalah ini, perbarui resource cluster dengan
anotasi yang tidak ada. Anda dapat menambahkan anotasi saat
upgrade sedang berjalan atau setelah membatalkan dan sebelum mencoba lagi upgrade.
Penginstalan
1,11
bmctl keluar sebelum pembuatan cluster selesai
Pembuatan cluster mungkin gagal untuk Google Distributed Cloud versi 1.11.0
(masalah ini telah diperbaiki di rilis Google Distributed Cloud 1.11.1). Dalam beberapa
kasus, perintah bmctl create cluster keluar lebih awal dan
menulis error seperti berikut ke log:
Operasi yang gagal menghasilkan artefak, tetapi cluster tidak
dapat dioperasikan. Jika masalah ini memengaruhi Anda, gunakan langkah-langkah berikut untuk membersihkan artefak dan membuat cluster:
Melihat langkah-langkah solusi
Untuk menghapus artefak cluster dan mereset mesin node, jalankan
perintah berikut:
bmctlreset-cUSER_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-langkah
selanjutnya. Jika tidak, lanjutkan.
Jalankan perintah berikut untuk mendapatkan versi cluster bootstrap:
Untuk menghapus cluster bootstrap, jalankan perintah berikut:
bmctlresetbootstrap
Penginstalan, Runtime VM di GDC
1.11, 1.12
Penginstalan melaporkan error rekonsiliasi runtime VM
Operasi pembuatan cluster dapat melaporkan error yang mirip dengan
berikut ini:
I042301:17:20.8956403935589logs.go:82]"msg"="Cluster reconciling:""message"="Internal error occurred: failed calling webhook \"vvmruntime.kb.io\": failed to call webhook: Post \"https://vmruntime-webhook-service.kube-system.svc:443/validate-vm-cluster-gke-io-v1vmruntime?timeout=10s\": dial tcp 10.95.5.151:443: connect: connection refused""name"="xxx""reason"="ReconciliationError"
Solusi
Error ini tidak berbahaya dan Anda dapat mengabaikannya dengan aman.
Penginstalan
1.10, 1.11, 1.12
Pembuatan cluster gagal saat menggunakan multi-NIC, containerd,
dan proxy HTTPS
Pembuatan cluster 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 tinggi).
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 dapat 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 mesin node.
Penginstalan
1.10, 1.11, 1.12
Kegagalan pada sistem dengan setelan umask
yang ketat
Google Distributed Cloud versi 1.10.0 memperkenalkan fitur bidang kontrol tanpa root 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 di mesin control plane agar
penginstalan atau upgrade dapat dilanjutkan.
Jadikan /etc/kubernetes dan semua subdirektorinya dapat dibaca
oleh semua orang: chmod o+rx.
Buat semua file yang dimiliki oleh pengguna root di bawah
direktori (secara rekursif) dapat dibaca oleh semua orang /etc/kubernetes (chmod o+r). Kecualikan file kunci pribadi (.key) dari perubahan ini karena file tersebut sudah dibuat dengan kepemilikan dan izin yang benar.
Jadikan /usr/local/etc/haproxy/haproxy.cfg world
dapat dibaca.
Jadikan /usr/local/etc/bgpadvertiser/bgpadvertiser-cfg.yaml
dapat dibaca oleh dunia.
Penginstalan
1.10, 1.11, 1.12, 1.13
Ketidakcocokan grup kontrol v2
Grup kontrol v2 (cgroup v2) tidak didukung di Google Distributed Cloud versi 1.13 dan 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 cluster admin atau hybrid (dengan kata lain, cluster yang tidak dibuat dengan bmctl, seperti cluster pengguna), pemeriksaan awal tidak memverifikasi kredensial akun layanan atau izin terkaitnya. Google Cloud
Saat menginstal cluster bare metal di VM vSphere, Anda harus menonaktifkan
flag tx-udp_tnl-segmentation dan
tx-udp_tnl-csum-segmentation. Flag ini terkait dengan offload segmentasi hardware yang dilakukan oleh driver vSphere VMXNET3 dan tidak berfungsi dengan tunnel GENEVE cluster bare metal.
Solusi
Jalankan perintah berikut di setiap node untuk memeriksa nilai saat ini dari
flag ini:
ethtool-kNET_INTFC|grepsegm
Ganti NET_INTFC dengan antarmuka
jaringan yang terkait dengan alamat IP node.
Terkadang di RHEL 8.4, ethtool menunjukkan bahwa tanda ini nonaktif
padahal tidak. Untuk secara eksplisit menonaktifkan flag ini, aktifkan lalu nonaktifkan flag dengan perintah berikut:
Perubahan flag ini tidak akan tetap ada setelah mulai ulang. Konfigurasi skrip startup untuk menetapkan flag ini secara eksplisit saat sistem melakukan booting.
Upgrade dan update
1.10
bmctl tidak dapat membuat, memperbarui, atau mereset cluster pengguna versi 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 menggunakan versi
1.N.X.
Jika Anda terpengaruh oleh masalah ini, Anda akan melihat log yang mirip dengan
berikut saat menggunakan bmctl:
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 dapat terhenti
Mengupgrade cluster ke versi 1.12.1 terkadang terhenti karena server API menjadi tidak tersedia. Masalah ini memengaruhi semua jenis cluster dan semua sistem operasi yang didukung. Jika masalah ini terjadi, perintah bmctl
upgrade clusterdapat gagal di beberapa titik, termasuk selama
fase kedua pemeriksaan awal.
Solusi
Anda dapat memeriksa log upgrade untuk menentukan 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:
HAProxy dan Keepalived harus berjalan di setiap node bidang kontrol sebelum Anda
mencoba lagi mengupgrade cluster ke versi 1.12.1. Gunakan
crictl command-line interface
di setiap node untuk memeriksa apakah container haproxy dan
keepalived sedang berjalan:
Jika HAProxy atau Keepalived tidak berjalan di node, mulai ulang
kubelet di node:
systemctlrestartkubelet
Upgrade dan update, VM Runtime di GDC
1.11, 1.12
Mengupgrade cluster ke versi 1.12.0 atau yang lebih tinggi akan gagal jika
VM Runtime di GDC diaktifkan
Di cluster versi 1.12.0, semua resource yang terkait dengan
VM Runtime di GDC dimigrasikan ke namespace vm-system
untuk mendukung rilis GA VM Runtime di GDC dengan lebih baik. Jika
Anda mengaktifkan VM Runtime di GDC pada cluster versi 1.11.x atau yang lebih rendah, upgrade ke versi 1.12.0 atau yang lebih tinggi akan gagal kecuali jika Anda menonaktifkan VM Runtime di GDC terlebih dahulu. 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 terhenti 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 secara tidak benar. Untuk menentukan apakah Anda terpengaruh oleh masalah ini dan cara 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 resource yang diperbarui secara tidak benar, dengan
{RESOURCE_NAME} adalah nama resource yang bermasalah.
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 ada dalam pesan log.
Simpan dan terapkan perubahan pada resource.
Coba lagi upgrade cluster.
Upgrade dan update
1.10, 1.11, 1.12
Upgrade diblokir untuk cluster dengan fitur yang menggunakan Network Gateway untuk GDC
Upgrade cluster dari 1.10.x ke 1.11.x gagal untuk cluster yang menggunakan
gateway NAT egress atau
load balancing yang disertakan dengan
BGP. Kedua fitur ini menggunakan Network Gateway untuk GDC. Upgrade cluster
macet di pesan command line Waiting for upgrade to complete...
dan error log anthos-cluster-operator
seperti berikut:
apply run failed ... MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field
is immutable...
Solusi
Untuk menghentikan pemblokiran upgrade, jalankan perintah berikut pada cluster yang Anda upgrade:
bmctl update tidak menghapus pemblokiran pemeliharaan
Perintah bmctl update tidak dapat menghapus atau mengubah
bagian maintenanceBlocks dari konfigurasi
resource cluster.
Solusi
Untuk mengetahui informasi selengkapnya, termasuk petunjuk untuk menghapus node dari
mode pemeliharaan, lihat
Mengaktifkan mode pemeliharaan
node.
Operasi
1.10, 1.11, 1.12
Node tidak dibatasi 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 di node, Google Distributed Cloud untuk bare metal mungkin akan membatalkan cordon
node sebelum Anda siap dalam upaya untuk menyelaraskan status yang diharapkan.
Solusi
Untuk cluster versi 1.12.0 dan yang lebih rendah, gunakan
mode pemeliharaan untuk
menghalangi dan mengosongkan node dengan aman.
Di versi 1.12.1 (anthosBareMetalVersion: 1.12.1) atau
yang lebih tinggi, Google Distributed Cloud untuk bare metal tidak akan membatalkan cordon node Anda secara tiba-tiba saat
Anda menggunakan kubectl cordon.
Operasi
1,11
Cluster admin versi 11 yang menggunakan mirror registri tidak dapat mengelola cluster versi 1.10
Jika cluster admin Anda menggunakan versi 1.11 dan menggunakan mirror registri, cluster tersebut tidak dapat mengelola cluster pengguna yang menggunakan versi minor yang lebih rendah. Masalah ini
memengaruhi operasi reset, update, dan upgrade pada cluster pengguna.
Untuk menentukan apakah masalah ini memengaruhi Anda, periksa log Anda untuk
operasi cluster, seperti pembuatan, upgrade, atau reset. Log ini
berada di folder bmctl-workspace/CLUSTER_NAME/
secara default. 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
Secret kubeconfig ditimpa
Perintah bmctl check cluster, saat dijalankan di cluster pengguna, akan menggantikan Secret kubeconfig cluster pengguna dengan kubeconfig cluster admin. Menimpa file menyebabkan operasi cluster standar, seperti memperbarui dan mengupgrade, gagal untuk cluster pengguna yang terpengaruh. Masalah ini berlaku untuk versi cluster 1.11.1
dan yang lebih lama.
Untuk menentukan 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, nama namespace cluster
adalah nama cluster yang diawali dengan
cluster-. Misalnya, jika Anda memberi nama cluster
test, namespace defaultnya 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, maka cluster pengguna yang ditentukan terpengaruh.
Langkah-langkah berikut akan memulihkan fungsi ke cluster pengguna yang terpengaruh
(USER_CLUSTER_NAME):
Cari file kubeconfig cluster pengguna. Google Distributed Cloud untuk bare metal
membuat file kubeconfig di workstation admin saat Anda membuat
cluster. Secara default, file berada di
direktori bmctl-workspace/USER_CLUSTER_NAME.
Verifikasi bahwa kubeconfig adalah kubeconfig cluster pengguna yang benar:
Ganti PATH_TO_GENERATED_FILE dengan
jalur ke file kubeconfig cluster pengguna. Respons 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 memerlukan /usr/local/bin agar berada di PATH pengguna.
Jika tidak, operasi akan gagal dengan error crictl: command not found.
Jika Anda tidak login sebagai pengguna root, sudo digunakan
untuk menjalankan perintah snapshot. PATH sudo dapat berbeda dari
profil root dan mungkin tidak berisi /usr/local/bin.
Solusi
Perbarui 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 penampung (CRI)
menggunakan ekspresi reguler yang salah untuk mengurai waktu, log untuk Pod
stackdriver-log-forwarder akan berisi error dan peringatan
seperti berikut:
Resource yang Anda edit akan terlihat seperti berikut:
[PARSER]# https://rubular.com/r/Vn30bO78GlkvyBNamecri
Formatregex
# The timestamp is described inhttps://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_KeytimeTime_Format%Y-%m-%dT%H:%M:%S.%L%z
Time_Keepoff
Untuk versi cluster 1.10 hingga 1.15, beberapa pelanggan telah
menemukan penagihan yang sangat tinggi untuk Metrics volume di halaman
Penagihan. Masalah ini hanya memengaruhi Anda jika semua
keadaan berikut berlaku:
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 terpengaruh oleh 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:
Memisahkan tanda untuk mengontrol pengumpulan log aplikasi versus
metrik aplikasi
Google Cloud Managed Service for Prometheus yang dibundel
Jika Anda tidak dapat mengupgrade ke versi 1.12, ikuti langkah-langkah berikut:
Temukan Pod dan Layanan sumber yang memiliki penagihan yang tidak diinginkan:
Hapus anotasi prometheus.io/scrap=true dari
Pod atau Layanan.
Logging dan pemantauan
1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28
Pengeditan pada metrics-server-config tidak dipertahankan
Kepadatan pod yang tinggi dapat, dalam kasus ekstrem, membuat overhead pemantauan dan logging yang berlebihan, yang dapat menyebabkan Server Metrik berhenti dan dimulai ulang. Anda
dapat mengedit metrics-server-config ConfigMap untuk mengalokasikan
lebih banyak resource agar Metrics Server tetap berjalan. Namun, karena rekonsiliasi, pengeditan yang dilakukan pada metrics-server-config dapat dikembalikan ke nilai default selama operasi update atau upgrade cluster.
Metrics Server tidak langsung terpengaruh, tetapi saat dimulai ulang berikutnya, Metrics Server akan mengambil ConfigMap yang dikembalikan dan rentan terhadap overhead yang berlebihan.
Solusi
Untuk 1.11.x, Anda dapat membuat skrip pengeditan ConfigMap dan melakukannya bersama
dengan update atau upgrade ke 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 metrik khusus software Google Distributed Cloud telah dihentikan dan, mulai
rilis Google Distributed Cloud 1.11, data tidak lagi dikumpulkan untuk metrik yang
dihentikan ini. Jika Anda menggunakan metrik ini dalam kebijakan pemberitahuan, tidak akan ada data yang memicu kondisi pemberitahuan.
Tabel berikut mencantumkan masing-masing metrik yang telah
tidak digunakan lagi dan metrik yang menggantikannya.
Pada versi cluster 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: Go to Monitoring
Di panel navigasi, pilih
Dasbor, lalu hapus dasbor Status node cluster Anthos.
Klik tab Sample library, lalu instal ulang dasbor Anthos
cluster node status.
stackdriver-log-forwarder memiliki CrashloopBackOff
error
Dalam beberapa situasi, agen logging fluent-bit dapat
macet saat memproses chunk yang rusak. Jika agen logging tidak dapat melewati
chunk yang rusak, Anda mungkin melihat 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:
Bersihkan potongan buffer untuk Penerusan Log Stackdriver.
Catatan: Dalam perintah berikut, ganti
KUBECONFIG dengan jalur ke file kubeconfig
cluster admin.
Error metrik tidak diketahui di log gke-metrics-agent
gke-metrics-agent adalah daemonset yang mengumpulkan metrik di setiap node dan meneruskannya ke Cloud Monitoring. Hal 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 tidak rutin
Cluster mungkin mengalami gangguan dalam ekspor metrik yang normal dan berkelanjutan, atau kehilangan metrik di beberapa node. Jika masalah ini memengaruhi cluster Anda, Anda mungkin melihat kesenjangan data untuk metrik berikut (setidaknya):
Perintah ini akan menemukan cpu: 50m jika hasil edit Anda telah diterapkan.
Jaringan
1.10
Beberapa gateway default merusak konektivitas ke endpoint eksternal
Memiliki beberapa gateway default di node dapat menyebabkan konektivitas terganggu dari dalam Pod ke endpoint eksternal, seperti google.com.
Untuk menentukan apakah Anda terpengaruh oleh masalah ini, jalankan perintah
berikut pada node:
iprouteshow
Beberapa instance default dalam respons menunjukkan
bahwa Anda terpengaruh.
Jaringan
1.12
Pengeditan resource kustom jaringan di cluster pengguna akan ditimpa
Cluster 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 menggantikan pengeditan apa pun 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.
Anda mengedit resource kustom ini di cluster admin dan
langkah rekonsiliasi menerapkan perubahan pada cluster pengguna Anda.
Solusi
Jika Anda telah mengubah salah satu resource kustom yang disebutkan sebelumnya di
cluster pengguna, ubah resource kustom yang sesuai di cluster admin agar
cocok sebelum mengupgrade. Langkah ini memastikan bahwa perubahan konfigurasi Anda dipertahankan. Versi cluster 1.13.0 dan yang lebih tinggi mencegah Anda mengubah resource kustom jaringan di cluster pengguna secara langsung.
Jaringan
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 menjadi 1 atau
2, pod akan gagal karena waktu tunggu komunikasi di luar node
habis.
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 sementara 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 menyetel
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 di tempatnya:
Setelah melakukan salah satu solusi sementara, 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 (kind) dan alamat IP node cluster yang tumpang-tindih
192.168.122.0/24 dan 10.96.0.0/27 adalah
CIDR pod dan layanan default yang digunakan oleh cluster bootstrap (kind).
Pemeriksaan pra-penerbangan 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 proses
(EOL). Sebagai akibat dari EOL, repositori yum berhenti berfungsi untuk CentOS, yang menyebabkan operasi pembuatan cluster dan upgrade cluster gagal. Hal ini berlaku untuk semua versi CentOS yang didukung dan memengaruhi semua versi cluster.
Solusi
Melihat langkah-langkah solusi
Sebagai solusi sementara, jalankan perintah berikut agar CentOS Anda menggunakan feed arsip:
Container tidak dapat menulis ke VOLUME yang ditentukan dalam Dockerfile
dengan containerd dan SELinux
Jika Anda menggunakan containerd sebagai runtime container dan sistem
operasi Anda mengaktifkan SELinux, VOLUME yang ditentukan dalam
Dockerfile aplikasi mungkin tidak dapat ditulis. Misalnya, container
yang dibuat dengan Dockerfile berikut tidak dapat menulis ke folder
/tmp.
FROM ubuntu:20.04 RUN chmod -R 777 /tmp VOLUME /tmp
Untuk memverifikasi apakah Anda terpengaruh oleh masalah ini, jalankan perintah berikut
di node yang menghosting container bermasalah:
ausearch-mavc
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
Node Problem Detector tidak diaktifkan secara default setelah upgrade cluster
Saat Anda mengupgrade cluster, Node Problem Detector 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 Pendeteksi Masalah Node:
Verifikasi apakah layanan node-problem-detector systemd sedang berjalan di node.
Gunakan perintah SSH dan hubungkan ke node.
Periksa apakah layanan node-problem-detector systemd
berjalan di node:
systemctlis-activenode-problem-detector
Jika hasil perintah menampilkan inactive, berarti node-problem-detector tidak berjalan di node.
Untuk mengaktifkan Node Problem Detector, gunakan perintah
kubectl edit dan edit ConfigMap
node-problem-detector-config. Untuk mengetahui informasi selengkapnya, lihat Node Problem Detector.
Operasi
1.9, 1.10
Pencadangan cluster gagal saat menggunakan login non-root
Perintah bmctl backup cluster akan gagal jika
nodeAccess.loginUser disetel ke nama pengguna non-root.]
Solusi:
Masalah ini berlaku untuk versi 1.9.x, 1.10.0, dan 1.10.1
dan telah diperbaiki di versi 1.10.2 dan yang lebih baru.
Jaringan
1.10, 1.11, 1.12
Layanan Load Balancer tidak berfungsi dengan container di jaringan host
bidang kontrol
Ada bug di anetd yang menyebabkan paket dihentikan untuk
Layanan LoadBalancer jika pod backend berjalan di node bidang
kontrol dan menggunakan kolom hostNetwork: true dalam spesifikasi
penampung.
Bug ini 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 di worker node (bukan node bidang kontrol).
Pod anthos-version-$version$ yang tidak memiliki induk gagal menarik image
Upgrade cluster dari 1.12.x ke 1.13.x mungkin mengalami kegagalan
pod anthos-version-$version$ dengan error ImagePullBackOff.
Hal ini terjadi karena kondisi persaingan anthos-cluster-operator ditingkatkan
dan tidak akan memengaruhi kemampuan cluster reguler.
Bug tidak ada setelah versi 1.13 atau yang lebih baru.
Solusi:
Hapus Job dynamic-version-installer dengan
kubectl delete job anthos-version-$version$ -n kube-system
Upgrade dan update
1.13
Cluster 1.12 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 menentukan apakah Anda terpengaruh, periksa log tugas upgrade yang
berisi string upgrade-first-no* di cluster admin.
Jika Anda melihat pesan error berikut, Anda terpengaruh.
Penggunaan CPU yang tinggi untuk stackdriver-operator
Ada masalah di stackdriver-operator yang menyebabkan stackdriver-operator
menggunakan waktu CPU yang lebih tinggi dari biasanya. Penggunaan CPU normal kurang dari 50
miliCPU (50m) untuk stackdriver-operator dalam keadaan
idle. Penyebabnya adalah ketidakcocokan resource Sertifikat yang
stackdriver-operator terapkan dengan ekspektasi dari
cert-manager. Ketidakcocokan ini menyebabkan kondisi persaingan antara
cert-manager dan stackdriver-operator dalam
memperbarui resource tersebut.
Masalah ini dapat menyebabkan penurunan performa pada cluster dengan ketersediaan CPU yang terbatas.
Solusi:
Hingga Anda dapat mengupgrade ke versi yang memperbaiki bug ini, gunakan
solusi berikut:
Untuk menurunkan skala stackdriver-operator ke 0 replika untuk sementara, terapkan resource kustom AddonConfiguration:
Pengambilan metrik berbasis anotasi tidak berfungsi
Pada rilis minor Google Distributed Cloud 1.16, kolom
enableStackdriverForApplications dalam spesifikasi resource kustom
stackdriver tidak digunakan lagi. Kolom ini digantikan oleh 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 dapat menggunakan flag gerbang 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 tinggi.
Pengumpulan metrik workload berbasis anotasi yang diaktifkan oleh
gerbang 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 biaya metrik di Cloud Monitoring.
Cloud Audit Logs memerlukan penyiapan izin khusus yang
dilakukan secara otomatis oleh cluster-operator melalui GKE Hub.
Namun, dalam kasus ketika satu cluster admin mengelola beberapa cluster dengan
ID project yang berbeda, bug di cluster-operator akan menyebabkan akun layanan
yang sama ditambahkan ke daftar yang diizinkan berulang kali dan gagal dalam
permintaan daftar yang diizinkan karena batasan ukuran. Hal ini akan menyebabkan log audit dari beberapa atau semua cluster ini gagal dimasukkan ke Google Cloud.
Gejalanya adalah serangkaian error Permission Denied di Pod
audit-proxy di cluster yang terpengaruh.
Gejala lainnya adalah status error dan daftar panjang akun layanan yang diduplikasi saat Anda memeriksa daftar yang diizinkan untuk logging audit cloud melalui GKE Hub:
Untuk mengatasi masalah ini, Anda dapat mengupgrade cluster ke setidaknya 1.28.1000,
1.29.500, atau 1.30.200 tempat masalah ini diperbaiki; Atau Anda dapat menerapkan
Solusi: berikut
Melihat langkah-langkah solusi
Hapus dan buat ulang fitur logging audit cloud GKE Hub untuk memicu
otomatisasi daftar yang diizinkan lagi.
Semua versi patch di 1.29 dan yang lebih lama, 1.30.400 dan yang lebih lama, serta 1.31.0
Konfigurasi mirror registry di node tidak diupdate jika hanya kolom
hosts yang diubah
Saat Anda memperbarui kolom containerRuntime.registryMirrors.hosts untuk endpoint mirror registri dalam spesifikasi Cluster, perubahan tidak akan otomatis diterapkan ke node cluster. Masalah ini terjadi karena logika rekonsiliasi tidak mendeteksi perubahan yang dilakukan secara eksklusif pada kolom hosts, dan akibatnya, tugas update mesin yang bertanggung jawab untuk mengupdate konfigurasi containerd pada node tidak dipicu.
Verifikasi:
Anda dapat memverifikasi masalah ini dengan mengubah hanya kolom hosts untuk mirror registri, lalu memeriksa file konfigurasi containerd (jalurnya mungkin /etc/containerd/config.toml atau jalur lain seperti /etc/containerd/config.d/01-containerd.conf, bergantung pada versi dan penyiapan) di node pekerja. File tidak menampilkan daftar hosts yang diperbarui untuk endpoint mirror.
Solusi:
Pilih salah satu opsi berikut:
Upgrade ke versi dengan perbaikan: upgrade cluster Anda ke 1.30.500-gke.126 atau yang lebih baru, 1.31.100-gke.136 atau yang lebih baru, atau 1.32.0.
Memicu update melalui perubahan NodePool: lakukan perubahan kecil pada spesifikasi NodePool untuk node yang terpengaruh. Misalnya, tambahkan label atau anotasi sementara. Tindakan ini akan memicu proses update mesin, yang
mengambil perubahan mirror registri. Anda dapat menghapus perubahan sepele tersebut setelahnya.
Langkah berikutnya
Jika Anda memerlukan bantuan tambahan, hubungi
Cloud Customer Care.
Anda juga dapat melihat bagian
Mendapatkan dukungan untuk mengetahui informasi selengkapnya tentang sumber dukungan, termasuk yang berikut:
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2026-02-25 UTC."],[],[]]
