Masalah umum GKE pada Bare Metal

Halaman ini mencantumkan semua masalah umum Google Distributed Cloud Virtual untuk Bare Metal. Untuk memfilter masalah umum menurut versi atau kategori produk, pilih filter Anda dari menu drop-down berikut.

Pilih GDCV untuk versi Bare Metal Anda:

Pilih kategori masalah Anda:

Atau, telusuri masalah Anda:

Kategori Versi yang diidentifikasi Masalah dan solusi
Networking 1,15, 1,16

GKE Dataplane V2 tidak kompatibel dengan beberapa driver penyimpanan

GKE pada cluster Bare Metal menggunakan GKE Dataplane V2, yang tidak kompatibel dengan beberapa penyedia penyimpanan. Anda mungkin mengalami masalah dengan volume NFS atau Pod yang macet. Hal ini sangat mungkin terjadi jika Anda memiliki workload yang menggunakan volume ReadWriteMany yang didukung oleh driver penyimpanan yang rentan terhadap masalah ini:

  • Robin.io
  • Portworx (sharedv4 volume layanan)
  • csi-nfs

Ini bukan merupakan daftar lengkap.

Solusi

Perbaikan untuk masalah ini tersedia untuk versi Ubuntu berikut:

  • LTS 20.04: Gunakan image kernel 5.4.0 yang lebih baru dari linux-image-5.4.0-166-generic
  • LTS 22.04: 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 Pod kube-state-metrics atau gke-metrics-agent yang ada di node yang sama dengan kube-state-metrics kehabisan memori (OOM).

Hal ini dapat terjadi dalam cluster dengan lebih dari 50 node atau dengan banyak objek Kubernetes.

Solusi

Untuk mengatasi masalah ini, perbarui definisi resource kustom stackdriver untuk menggunakan gate fitur ksmNodePodMetricsOnly. Gate fitur ini memastikan bahwa hanya sejumlah kecil metrik penting yang terekspos.

Untuk menggunakan solusi ini, selesaikan langkah-langkah berikut:

  1. Periksa definisi resource kustom stackdriver untuk gerbang fitur yang tersedia: 
    
kubectl -n kube-system get crd stackdrivers.addons.gke.io -o yaml | grep ksmNodePodMetricsOnly
  2. Perbarui definisi resource kustom stackdriver untuk mengaktifkan ksmNodePodMetricsOnly: 
    
kind:stackdriver
spec:
  featureGates:
     ksmNodePodMetricsOnly: true
Penginstalan 1.28.0-1.28.200

Pemeriksaan preflight gagal pada RHEL 9.2 karena iptable tidak ada

Saat menginstal cluster di sistem operasi Red Hat Enterprise Linux (RHEL) 9.2, Anda mungkin mengalami kegagalan karena tidak adanya paket iptables. Kegagalan terjadi selama pemeriksaan preflight dan memicu pesan error yang mirip dengan yang berikut:


'check_package_availability_pass': "The following packages are not available: ['iptables']"

RHEL 9.2 berada dalam Pratinjau untuk GKE on Bare Metal versi 1.28.

Solusi

Abaikan error pemeriksaan preflight dengan menetapkan spec.bypassPreflightCheck ke true pada resource Cluster Anda.
Operasi 1,10, 1,11, 1,12, 1,13, 1,14, 1,15, 1,16

Failover MetalLB lambat dalam skala tinggi

Saat MetalLB menangani layanan dalam jumlah besar (lebih dari 10.000), failover dapat memerlukan waktu lebih dari satu jam. Hal ini terjadi karena MetalLB menggunakan antrean pembatasan kapasitas, yang jika berskala tinggi, dapat memerlukan waktu cukup lama untuk mengakses layanan yang perlu digagalkan.

Solusi

Upgrade cluster Anda ke versi 1.28 atau yang lebih baru. Jika Anda tidak dapat mengupgrade, mengedit layanan secara manual (misalnya, menambahkan anotasi) akan menyebabkan layanan failover lebih cepat.
Operasi 1.16.0-1.16.6, 1.28.0-1.28.200

Variabel lingkungan harus ditetapkan di workstation admin jika proxy diaktifkan

bmctl check cluster dapat gagal karena kegagalan proxy jika Anda tidak memiliki variabel lingkungan HTTPS_PROXY dan NO_PROXY yang ditentukan di workstation admin. Perintah bmctl melaporkan pesan error tentang kegagalan memanggil beberapa layanan Google, seperti contoh berikut:


[2024-01-29 23:49:03+0000] error validating cluster config: 2 errors occurred:
        * GKERegister check failed: 2 errors occurred:
        * Get "https://gkehub.googleapis.com/v1beta1/projects/baremetal-runqi/locations/global/memberships/ci-ec1a14a903eb1fc": oauth2: cannot fetch token: Post "https://oauth2.googleapis.com/token": dial tcp 108.177.98.95:443: i/o timeout
        * Post "https://cloudresourcemanager.googleapis.com/v1/projects/baremetal-runqi:testIamPermissions?alt=json&prettyPrint=false": oauth2: cannot fetch token: Post "https://oauth2.googleapis.com/token": dial tcp 74.125.199.95:443: i/o timeout

Solusi

Tetapkan HTTPS_PROXY dan NO_PROXY secara manual di workstation admin.
Upgrade dan update 1.28.0-gke.435

Upgrade ke versi 1.28.0-gke.435 mungkin gagal jika audit.log memiliki kepemilikan yang salah

Dalam beberapa kasus, file /var/log/apiserver/audit.log pada node bidang kontrol memiliki kepemilikan grup dan pengguna yang ditetapkan ke root. Setelan kepemilikan file ini menyebabkan kegagalan upgrade untuk node bidang kontrol saat mengupgrade cluster dari versi 1.16.x ke versi 1.28.0-gke.435. Masalah ini hanya berlaku untuk cluster yang dibuat sebelum versi 1.11 dan yang telah menonaktifkan Cloud Audit Logs. Cloud Audit Logs diaktifkan secara default untuk cluster pada 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 Anda ke versi 1.28.0-gke.435:

  • Jika Cloud Audit Logs diaktifkan, hapus file /var/log/apiserver/audit.log.
  • Jika Cloud Audit Logs dinonaktifkan, ubah kepemilikan /var/log/apiserver/audit.log agar sama dengan direktori induk, /var/log/apiserver.
Networking, Upgrade, dan update 1.28.0-gke.435

MetalLB tidak menetapkan alamat IP ke Layanan VIP

GKE di Bare Metal menggunakan MetalLB untuk load balancing yang dipaketkan. Pada GKE on Bare Metal rilis 1.28.0-gke.435, MetalLB yang dipaketkan diupgrade ke versi 0.13, yang memperkenalkan dukungan CRD untuk IPAddressPools. Namun, karena ConfigMaps mengizinkan nama untuk IPAddressPool, nama kumpulan tersebut harus dikonversi menjadi nama yang sesuai dengan Kubernetes dengan menambahkan hash ke akhir nama IPAddressPool. Misalnya, IPAddressPool dengan nama default akan dikonversi menjadi nama seperti default-qpvpd saat Anda mengupgrade cluster ke versi 1.28.0-gke.435.

Karena MetalLB memerlukan nama IPPool yang spesifik untuk dipilih, konversi nama ini mencegah MetalLB membuat pilihan 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 GKE pada Bare Metal 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:

  1. Dapatkan nama IPAddressPool yang dikonversi: 
    
kubectl get IPAddressPools -n kube-system
  2. Update Layanan yang terpengaruh untuk menetapkan anotasi metallb.universe.tf/address-pool ke nama yang dikonversi dengan hash.

    Misalnya, jika nama IPAddressPool dikonversi dari default menjadi nama seperti default-qpvpd, ubah anotasi metallb.universe.tf/address-pool: default di Layanan menjadi metallb.universe.tf/address-pool: default-qpvpd.

Hash yang digunakan dalam konversi nama bersifat deterministik, sehingga solusinya tetap ada.
Upgrade dan update 1,14

Pod orphan setelah diupgrade ke versi 1.14.x

Saat Anda mengupgrade GKE pada cluster Bare Metal ke versi 1.14.x, beberapa resource dari versi sebelumnya tidak akan dihapus. Secara khusus, Anda mungkin melihat kumpulan pod usang seperti berikut ini:


capi-webhook-system/capi-controller-manager-xxx
capi-webhook-system/capi-kubeadm-bootstrap-controller-manager-xxx

Objek usang ini tidak memengaruhi operasi cluster secara langsung, tetapi sebagai praktik terbaik, sebaiknya Anda menghapusnya.

  • Jalankan perintah berikut untuk menghapus objek usang: 
    
kubectl delete ns capi-webhook-system
kubectl delete validatingwebhookconfigurations capi-validating-webhook-configuration
kubectl delete mutatingwebhookconfigurations capi-mutating-webhook-configuration

Masalah ini telah diperbaiki di GKE pada Bare Metal versi 1.15.0 dan yang lebih baru.
Penginstalan 1,14

Pembuatan cluster macet pada tugas machine-init

Jika mencoba menginstal Google Distributed Cloud Virtual for Bare Metal versi 1.14.x, Anda mungkin akan mengalami kegagalan karena tugas machine-init, mirip dengan contoh output berikut:


"kubeadm join" task failed due to:
error execution phase control-plane-join/etcd: error creating local etcd static pod manifest file: etcdserver: re-configuration failed due to not enough started members

"kubeadm reset" task failed due to:
panic: runtime error: invalid memory address or nil pointer dereference

Solusi:

Hapus anggota etcd yang sudah tidak digunakan lagi dan menyebabkan tugas machine-init gagal. Selesaikan langkah-langkah berikut pada node bidang kontrol yang berfungsi:

  1. Cantumkan anggota etcd yang sudah ada: 
    
etcdctl --key=/etc/kubernetes/pki/etcd/peer.key \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/peer.crt \
  member list
    Cari anggota dengan status unstarted, seperti ditunjukkan dalam contoh output berikut: 
    
5feb7ac839625038, started, vm-72fed95a, https://203.0.113.11:2380, https://203.0.113.11:2379, false
99f09f145a74cb15, started, vm-8a5bc966, https://203.0.113.12:2380, https://203.0.113.12:2379, false
bd1949bcb70e2cb5, unstarted, , https://203.0.113.10:2380, , false
  2. Hapus anggota etcd yang gagal: 
    
etcdctl --key=/etc/kubernetes/pki/etcd/peer.key \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/peer.crt \
  member remove MEMBER_ID
    Ganti MEMBER_ID dengan ID anggota etcd yang gagal. Dalam contoh output sebelumnya, ID ini adalah bd1949bcb70e2cb5.

    Contoh output berikut menunjukkan bahwa anggota telah dihapus: 
    
Member bd1949bcb70e2cb5 removed from cluster  9d70e2a69debf2f
Networking 1.28.0

Cilium-operator tidak memiliki izin list dan watch Node

Di Cilium 1.13, izin ClusterRole cilium-operator salah. Izin list dan watch Node tidak ada. cilium-operator gagal memulai pembersih sampah memori, yang mengakibatkan masalah berikut:

  • Kebocoran resource Cilium.
  • Identitas usang tidak dihapus dari peta kebijakan BFP.
  • Peta kebijakan mungkin mencapai batas 16K.
    • Entri baru tidak dapat ditambahkan.
    • Penerapan NetworkPolicy salah.
  • Identitas mungkin mencapai batas 64K.
    • Pod baru tidak dapat dibuat.

Operator yang tidak memiliki izin Node melaporkan contoh pesan log berikut:


2024-01-02T20:41:37.742276761Z level=error msg=k8sError error="github.com/cilium/cilium/operator/watchers/node.go:83: Failed to watch *v1.Node: failed to list *v1.Node: nodes is forbidden: User \"system:serviceaccount:kube-system:cilium-operator\" cannot list resource \"nodes\" in API group \"\" at the cluster scope" subsys=k8s

Agen Cilium melaporkan pesan error jika tidak dapat memasukkan entri ke peta kebijakan, seperti contoh berikut:


level=error msg="Failed to add PolicyMap key" bpfMapKey="{6572100 0 0 0}" containerID= datapathPolicyRevision=0 desiredPolicyRevision=7 endpointID=1313 error="Unable to update element for Cilium_policy_01313 map with file descriptor 190: the map is full, please consider resizing it. argument list too long" identity=128 ipv4= ipv6= k8sPodName=/ port=0 subsys=endpoint

Solusi:

Hapus identitas Cilium, lalu tambahkan izin ClusterRole yang hilang ke operator:

  1. Hapus objek CiliumIdentity yang sudah ada: 
    
kubectl delete ciliumid –-all
  2. Edit objek ClusterRole cilium-operator: 
    
kubectl edit clusterrole cilium-operator
  3. Tambahkan bagian untuk nodes yang menyertakan izin yang tidak ada, seperti yang ditunjukkan dalam contoh berikut: 
    
- apiGroups:
  - ""
  resources:
  - nodes
  verbs:
  - get
  - list
  - watch
  4. Simpan dan tutup editor. Operator secara dinamis mendeteksi perubahan izin. Anda tidak perlu memulai ulang operator secara manual.
Upgrade dan update 1.15.0-1.15.7, 1.16.0-1.16.3

Masalah sementara yang terjadi selama pemeriksaan preflight

Salah satu tugas health check kubeadm yang berjalan selama pemeriksaan preflight upgrade mungkin gagal dengan pesan error berikut:


[ERROR CreateJob]: could not delete Job \"upgrade-health-check\" in the namespace \"kube-system\": jobs.batch \"upgrade-health-check\" not found

Error ini dapat diabaikan dengan aman. Jika Anda mengalami error ini yang memblokir upgrade, jalankan kembali perintah upgrade.

Jika Anda melihat error ini saat menjalankan preflight menggunakan perintah bmctl preflightcheck, tidak ada yang diblokir oleh kegagalan ini. Anda dapat menjalankan pemeriksaan preflight lagi untuk mendapatkan informasi preflight yang akurat.


Solusi:

Jalankan kembali perintah upgrade, atau jika ditemukan selama bmctl preflightcheck, jalankan kembali perintah preflightcheck.
Operasi 1.14, 1.15.0-1.15.7, 1.16.0-1.16.3, 1.28.0

Health check Jaringan berkala gagal saat node diganti atau dihapus

Masalah ini memengaruhi cluster yang melakukan health check jaringan secara berkala setelah node diganti atau dihapus. Jika cluster Anda menjalani health check berkala, health check jaringan berkala akan mengakibatkan kegagalan setelah penggantian atau penghapusan node, karena ConfigMap inventaris jaringan tidak diperbarui setelah dibuat.


Solusi:

Solusi yang direkomendasikan adalah menghapus inventaris ConfigMap dan health check jaringan berkala. Operator cluster akan otomatis membuatnya kembali dengan informasi terbaru.

Untuk cluster 1.14.x, jalankan perintah berikut:


kubectl delete configmap \
    $(kubectl get cronjob CLUSTER_NAME-network -o=jsonpath='{.spec.jobTemplate.spec.template.spec.volumes[?(@name=="inventory-config-volume")].configMap.name}' \
    -n CLUSTER_NAMESPACE) \
    -n CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG
kubectl delete healthchecks.baremetal.cluster.gke.io \
    CLUSTER_NAME-network -n CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG

Untuk cluster 1.15.0 dan yang lebih baru, jalankan perintah berikut:


kubectl delete configmap \
    $(kubectl get cronjob bm-system-network -o=jsonpath='{.spec.jobTemplate.spec.template.spec.volumes[?(@.name=="inventory-config-volume")]configMap.name}' \
    -n CLUSTER_NAMESPACE) \
    -n CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG
kubectl delete healthchecks.baremetal.cluster.gke.io \
    bm-system-network -n CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG
Networking 1.14, 1.15, 1.16.0-1.16.2

Gateway Jaringan untuk GDC tidak dapat menerapkan konfigurasi Anda jika nama perangkat berisi titik

Jika Anda memiliki perangkat jaringan yang menyertakan karakter titik (.) pada namanya, seperti bond0.2, Gateway Jaringan untuk GDC memperlakukan periode tersebut sebagai jalur dalam direktori ketika menjalankan sysctl untuk melakukan perubahan. Saat Gateway Jaringan untuk GDC memeriksa apakah deteksi alamat duplikat (DAD) diaktifkan, pemeriksaan mungkin akan gagal, sehingga tidak akan melakukan rekonsiliasi.

Perilaku ini berbeda di setiap versi cluster:

  • 1.14 dan 1.15: Error ini hanya ada jika Anda menggunakan alamat IP mengambang IPv6. Jika tidak menggunakan alamat IP mengambang IPv6, Anda tidak akan melihat masalah ini saat nama perangkat berisi titik.
  • 1.16.0 - 1.16.2: Error ini selalu ada jika nama perangkat berisi titik.

Solusi:

Upgrade cluster Anda ke versi 1.16.3 atau yang lebih baru.

Sebagai solusi hingga Anda dapat mengupgrade cluster, hapus titik (.) dari nama perangkat.
Upgrade dan update, Jaringan, Keamanan 1.16.0

Upgrade ke 1.16.0 gagal saat seccomp dinonaktifkan

Jika seccomp dinonaktifkan untuk cluster Anda (spec.clusterSecurity.enableSeccomp ditetapkan ke false), upgrade ke versi 1.16.0 akan gagal.

GKE pada Bare Metal versi 1.16 menggunakan Kubernetes versi 1.27. Pada Kubernetes versi 1.27.0 dan yang lebih baru, fitur untuk menetapkan profil seccomp bersifat GA dan tidak lagi menggunakan gate fitur. Perubahan Kubernetes ini menyebabkan upgrade ke versi 1.16.0 gagal saat seccomp dinonaktifkan dalam konfigurasi cluster. Masalah ini telah diperbaiki pada cluster versi 1.16.1 dan yang lebih tinggi. Jika Anda memiliki kolom cluster.spec.clusterSecurity.enableSeccomp yang ditetapkan ke false, Anda dapat mengupgrade ke versi 1.16.1 atau yang lebih tinggi.

Cluster dengan spec.clusterSecurity.enableSeccomp yang tidak disetel atau ditetapkan ke true tidak akan terpengaruh.
Penginstalan, Operasi 1.11, 1.12, 1.13, 1.14, 1.15.0-1.15.5, 1.16.0-1.16.1

metadata dalam container mungkin rusak setelah dimulai ulang saat /var/lib/containerd dipasang

Jika Anda telah memasang /var/lib/containerd secara opsional, metadata dalam container mungkin akan rusak setelah dimulai ulang. Metadata yang rusak dapat menyebabkan Pod gagal, termasuk Pod yang penting bagi sistem.

Untuk memeriksa apakah masalah ini memengaruhi Anda, lihat apakah pemasangan opsional ditentukan dalam /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

Membersihkan 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 membuat daftar Pod yang dapat dibersihkan:


kubectl get pods –A | grep TaintToleration

Contoh output berikut menunjukkan Pod dengan status TaintToleration:


kube-system    stackdriver-metadata-agent-[...]    0/1    TaintToleration    0

Solusi:

Untuk setiap Pod dengan gejala yang dijelaskan, periksa ReplicaSet tempat Pod tersebut berada. Jika ReplicaSet terpenuhi, Anda dapat menghapus Pod:

  1. Dapatkan ReplicaSet yang mengelola Pod dan temukan nilai ownerRef.Kind: 
    
kubectl get pod POD_NAME -n NAMESPACE -o yaml
  2. Dapatkan ReplicaSet dan verifikasi bahwa status.replicas sama dengan spec.replicas: 
    
kubectl get replicaset REPLICA_NAME -n NAMESPACE -o yaml
  3. Jika namanya cocok, hapus Pod tersebut: 
    
kubectl delete pod POD_NAME -n NAMESPACE.
Upgrade 1.16.0

etcd-events dapat berhenti saat meningkatkan ke versi 1.16.0

Saat Anda mengupgrade cluster yang ada ke versi 1.16.0, kegagalan Pod yang terkait dengan peristiwa etcd dapat menghentikan operasi. Secara khusus, tugas upgrade node gagal untuk langkah TASK [etcd_events_install : Run etcdevents].

Jika terpengaruh oleh masalah ini, Anda akan melihat kegagalan Pod seperti berikut:

  • Pod kube-apiserver gagal dimulai dengan error berikut: 
    
connection error: desc = "transport: Error while dialing dial tcp 127.0.0.1:2382: connect: connection refused"
  • Pod etcd-events gagal dimulai dengan error berikut: 
    
Error: error syncing endpoints with etcd: context deadline exceeded

Solusi:

Jika Anda tidak dapat mengupgrade cluster ke versi yang telah diperbaiki, gunakan solusi sementara berikut untuk mengatasi error tersebut:

  1. Gunakan SSH untuk mengakses node bidang kontrol dengan error yang dilaporkan.
  2. Edit file manifes etcd-events, /etc/kubernetes/manifests/etcd-events.yaml, dan hapus flag initial-cluster-state=existing.
  3. Terapkan manifes.
  4. Upgrade akan dilanjutkan.
Networking 1.15.0-1.15.2

CoreDNS orderPolicy tidak dikenali

OrderPolicy tidak dikenali sebagai parameter dan tidak digunakan. Sebagai gantinya, GKE di Bare Metal selalu menggunakan Random.

Masalah ini terjadi karena template CoreDNS tidak diupdate, yang menyebabkan orderPolicy diabaikan.


Solusi:

Update template CoreDNS dan terapkan perbaikan. Perbaikan ini berlanjut hingga upgrade dilakukan.

  1. Edit template yang ada: 
    
kubectl edit cm -n kube-system coredns-template
    Ganti konten template dengan kode berikut: 
    
coredns-template: |-
  .:53 {
    errors
    health {
      lameduck 5s
    }
    ready
    kubernetes cluster.local in-addr.arpa ip6.arpa {
      pods insecure
      fallthrough in-addr.arpa ip6.arpa
    }
{{- if .PrivateGoogleAccess }}
    import zones/private.Corefile
{{- end }}
{{- if .RestrictedGoogleAccess }}
    import zones/restricted.Corefile
{{- end }}
    prometheus :9153
    forward . {{ .UpstreamNameservers }} {
      max_concurrent 1000
      {{- if ne .OrderPolicy "" }}
      policy {{ .OrderPolicy }}
      {{- end }}
    }
    cache 30
{{- if .DefaultDomainQueryLogging }}
    log
{{- end }}
    loop
    reload
    loadbalance
}{{ range $i, $stubdomain := .StubDomains }}
{{ $stubdomain.Domain }}:53 {
  errors
{{- if $stubdomain.QueryLogging }}
  log
{{- end }}
  cache 30
  forward . {{ $stubdomain.Nameservers }} {
    max_concurrent 1000
    {{- if ne $.OrderPolicy "" }}
    policy {{ $.OrderPolicy }}
    {{- end }}
  }
}
{{- end }}
Jaringan, Operasi 1,10, 1,11, 1,12, 1,13, 1,14

Gateway Jaringan untuk komponen GDC dikeluarkan atau tertunda karena class prioritas tidak ada

Pod gateway jaringan di kube-system mungkin menampilkan status Pending atau Evicted, seperti ditunjukkan dalam contoh output ringkas berikut:


$ kubectl -n kube-system get pods | grep ang-node
ang-node-bjkkc     2/2     Running     0     5d2h
ang-node-mw8cq     0/2     Evicted     0     6m5s
ang-node-zsmq7     0/2     Pending     0     7h

Error ini menunjukkan peristiwa penggusuran atau ketidakmampuan untuk menjadwalkan Pod karena resource node. Karena Network Gateway untuk Pod GDC tidak memiliki PriorityClass, pod memiliki prioritas default yang sama dengan workload lainnya. Jika node memiliki resource yang terbatas, Pod gateway jaringan mungkin akan dikeluarkan. Perilaku ini sangat buruk untuk DaemonSet ang-node, karena Pod tersebut harus dijadwalkan pada node tertentu dan tidak dapat dimigrasikan.


Solusi:

Upgrade ke versi 1.15 atau yang lebih baru.

Sebagai perbaikan jangka pendek, Anda dapat menetapkan PriorityClass secara manual ke Gateway Jaringan untuk komponen GDC. Pengontrol GKE pada Bare Metal akan menimpa perubahan manual ini selama proses rekonsiliasi, seperti saat mengupgrade cluster.

  • Tetapkan PriorityClass system-cluster-critical ke Deployment pengontrol cluster ang-controller-manager dan autoscaler.
  • Tetapkan PriorityClass system-node-critical ke node ang-daemon DaemonSet.
Penginstalan, Upgrade, dan update 1.15.0, 1.15.1, 1.15.2

Pembuatan dan upgrade cluster gagal karena panjang nama cluster

Pembuatan cluster versi 1.15.0, 1.15.1, atau 1.15.2 atau mengupgrade cluster ke versi 1.15.0, 1.15.1, atau 1.15.2 akan gagal jika nama cluster lebih dari 48 karakter (versi 1.15.0) atau 45 karakter (versi 1.15.1 atau ). Selama proses pembuatan dan upgrade cluster, GKE di Bare Metal membuat resource health check dengan nama yang menggabungkan nama dan versi cluster:

  • Untuk cluster versi 1.15.0, nama resource health check adalah CLUSTER_NAME-add-ons-CLUSTER_VER.
  • Untuk cluster versi 1.15.1 atau 1.15.2, nama resource health check adalah CLUSTER_NAME-kubernetes-CLUSTER_VER.

Untuk nama cluster yang panjang, nama resource health check melebihi batasan panjang karakter Kubernetes 63 untuk nama label, yang mencegah pembuatan resource health check. Jika health check tidak berhasil, operasi cluster akan gagal.

Untuk melihat apakah Anda terpengaruh oleh masalah ini, gunakan kubectl describe untuk memeriksa resource yang gagal: 


kubectl describe healthchecks.baremetal.cluster.gke.io \
    HEALTHCHECK_CR_NAME -n CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG

Jika masalah ini memengaruhi Anda, respons akan berisi peringatan untuk ReconcileError seperti berikut: 


...
Events:
  Type     Reason          Age                   From                    Message
  ----     ------          ----                  ----                    -------
  Warning  ReconcileError  77s (x15 over 2m39s)  healthcheck-controller  Reconcile error, retrying: 1 error occurred:
           * failed to create job for health check
db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1: Job.batch
"bm-system-db-uat-mfd7-fic-hybrid-cloud-u24d5f180362cffa4a743" is invalid: [metadata.labels: Invalid
value: "db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1": must be no more than 63
characters, spec.template.labels: Invalid value:
"db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1": must be no more than 63 characters]

Solusi

Untuk berhenti memblokir upgrade atau pembuatan cluster, Anda dapat mengabaikan health check. Gunakan perintah berikut untuk membuat patch pada resource kustom healthcheck dengan status penerusan: (status: {pass: true})


kubectl patch healthchecks.baremetal.cluster.gke.io \
    HEALTHCHECK_CR_NAME -n CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG --type=merge \
    --subresource status --patch 'status: {pass: true}'
Upgrade dan Update 1,14, 1,15

Cluster versi 1.14.0 dan 1.14.1 dengan fitur pratinjau tidak dapat diupgrade ke versi 1.15.x

Jika cluster versi 1.14.0 dan 1.14.1 mengaktifkan fitur pratinjau, cluster akan diblokir agar tidak berhasil mengupgrade ke versi 1.15.x. Hal ini berlaku untuk melihat pratinjau fitur seperti kemampuan untuk membuat cluster tanpa kube-proxy, yang diaktifkan dengan anotasi berikut di file konfigurasi cluster:


preview.baremetal.cluster.gke.io/kube-proxy-free: "enable"

Jika terpengaruh oleh masalah ini, Anda akan mendapatkan error seperti berikut selama melakukan upgrade cluster:


[2023-06-20 23:37:47+0000] error judging if the cluster is managing itself:
error to parse the target cluster: error parsing cluster config: 1 error
occurred:

Cluster.baremetal.cluster.gke.io "$cluster-name" is invalid:
Annotations[preview.baremetal.cluster.gke.io/$preview-feature-name]:
Forbidden: preview.baremetal.cluster.gke.io/$preview-feature-name feature
isn't supported in 1.15.1 Anthos Bare Metal version

Masalah ini telah diperbaiki pada cluster versi 1.14.2 dan yang lebih tinggi.


Solusi:

Jika tidak dapat mengupgrade cluster ke versi 1.14.2 atau yang lebih tinggi sebelum mengupgrade ke versi 1.15.x, Anda dapat mengupgrade ke versi 1.15.x secara langsung menggunakan cluster bootstrap:


bmctl upgrade cluster --use-bootstrap=true
Operasi 1.15

Cluster versi 1.15 tidak menerima alamat IP mengambang duplikat

Gateway Jaringan untuk GDC tidak mengizinkan Anda membuat resource kustom NetworkGatewayGroup baru yang berisi alamat IP di spec.floatingIPs yang sudah digunakan dalam resource kustom NetworkGatewayGroup yang ada. Aturan ini diterapkan oleh webhook di GKE pada cluster Bare Metal versi 1.15.0 dan yang lebih tinggi. Alamat IP mengambang duplikat yang sudah ada tidak akan menyebabkan error. Webhook hanya mencegah pembuatan resource khusus NetworkGatewayGroups baru yang berisi alamat IP duplikat.

Pesan error webhook mengidentifikasi alamat IP yang bertentangan dan resource kustom yang ada yang sudah menggunakannya: 


IP address exists in other gateway with name default

Dokumentasi awal untuk fitur jaringan lanjutan, seperti gateway NAT keluar, tidak melarang alamat IP duplikat. Awalnya, hanya resource NetworkGatewayGroup bernama default yang dikenali oleh rekonsiler. Gateway Jaringan untuk GDC kini mengenali semua resource kustom NetworkGatewayGroup dalam namespace sistem. Resource kustom NetworkGatewayGroup yang ada akan diberlakukan, sebagaimana adanya.


Solusi:

Error terjadi hanya untuk pembuatan resource kustom NetworkGatewayGroup baru.

Untuk mengatasi error tersebut:

  1. Gunakan perintah berikut untuk menampilkan resource kustom NetworkGatewayGroups: 
    
kubectl get NetworkGatewayGroups --kubeconfig ADMIN_KUBECONFIG \
    -n kube-system -o yaml
  2. Buka resource kustom NetworkGatewayGroup yang ada dan hapus semua alamat IP floating yang bertentangan (spec.floatingIPs): 
    
kubectl edit NetworkGatewayGroups --kubeconfig ADMIN_KUBECONFIG \
    -n kube-system RESOURCE_NAME
  3. Untuk menerapkan perubahan, tutup dan simpan fasilitas kustom yang telah diedit.
Runtime VM di GDC 1.13.7

VM mungkin tidak dimulai pada cluster 1.13.7 yang menggunakan registry pribadi

Saat Anda mengaktifkan VM Runtime di GDC pada cluster versi 1.13.7 baru atau yang telah diupgrade 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 penarikan image. Misalnya, jika VM Anda menggunakan jaringan node, beberapa Pod mungkin melaporkan error pull image seperti berikut:


macvtap-4x9zp              0/1   Init:ImagePullBackOff  0     70m

Masalah ini telah diperbaiki pada GKE versi 1.14.0 dan yang lebih tinggi pada cluster Bare Metal.

Solusi

Jika tidak dapat segera mengupgrade cluster, Anda dapat menarik gambar secara manual. Perintah berikut mengambil image plugin macvtap CNI untuk VM Anda, lalu mengirimkannya ke registry pribadi: 


docker pull \
    gcr.io/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21
docker tag \
    gcr.io/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21 \
    REG_HOST/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21
docker push \
    REG_HOST/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21

Ganti REG_HOST dengan nama domain host yang Anda duplikasi secara lokal.

Penginstalan 1,11, 1,12

Selama pembuatan cluster di cluster jenis, pod gke-metric-agent gagal dimulai

Selama pembuatan cluster di cluster jenis, pod gke-metrics-agent gagal dimulai karena terjadi error pengambilan gambar sebagai berikut:


error="failed to pull and unpack image \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": failed to resolve reference \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": pulling from host gcr.io failed with status code [manifests 1.8.3-anthos.2]: 403 Forbidden"

Selain itu, dalam log container cluster bootstrap, Anda akan melihat entri berikut:


Sep 13 23:54:20 bmctl-control-plane containerd[198]: time="2022-09-13T23:54:20.378172743Z" level=info msg="PullImage \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\" " Sep 13 23:54:21 bmctl-control-plane containerd[198]: time="2022-09-13T23:54:21.057247258Z" level=error msg="PullImage \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\" failed" error="failed to pull and unpack image \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": failed to resolve reference \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": pulling from host gcr.io failed with status code [manifests 1.8.3-anthos.2]: 403 Forbidden"

Anda akan melihat error "gagal menarik" berikut dalam 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 dalam jenis cluster 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 dalam jenis cluster adalah untuk memfasilitasi tingkat keberhasilan pembuatan cluster serta untuk pelacakan dan pemantauan internal. Oleh karena itu, Anda dapat mengabaikan error ini.
Operasi, Jaringan 1,12, 1,13, 1,14, 1,15, 1,16, 1,28

Mengakses endpoint Layanan IPv6 akan membuat error LoadBalancer Node pada CentOS atau RHEL

Saat Anda mengakses Layanan dual-stack (Layanan yang memiliki endpoint IPv4 dan IPv6) dan menggunakan endpoint IPv6, LoadBalancer Node yang menyalurkan Layanan mungkin mengalami error. Masalah ini memengaruhi pelanggan yang menggunakan layanan dual stack dengan CentOS atau RHEL dan versi kernel lebih lama dari kernel-4.18.0-372.46.1.el8_6.

Jika Anda yakin masalah ini memengaruhi Anda, periksa versi kernel di LoadBalancer Node menggunakan perintah uname -a.


Solusi:

Update LoadBalancer Node ke versi kernel kernel-4.18.0-372.46.1.el8_6 atau yang lebih baru. Versi kernel ini tersedia secara default di CentOS serta RHEL versi 8.6 dan yang lebih baru.
Networking 1.11, 1.12, 1.13, 1.14.0

Masalah konektivitas sesekali setelah Node dimulai ulang

Setelah memulai ulang Node, Anda mungkin mengalami masalah konektivitas yang terputus-putus untuk Layanan NodePort atau LoadBalancer. Misalnya, Anda mungkin mengalami error handshake TLS atau reset koneksi sesekali. Masalah ini telah diperbaiki untuk cluster versi 1.14.1 dan yang lebih tinggi.

Untuk memeriksa apakah masalah ini memengaruhi Anda atau tidak, lihat aturan penerusan iptables di Node tempat Pod backend untuk Service yang terpengaruh dijalankan:


sudo iptables -L FORWARD

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 pada Node yang tidak dikonfigurasi dengan benar. Setelah Anda memulai ulang Pod yang di-anetd, aturan penerusan di iptables akan dikonfigurasi dengan benar.

Contoh output berikut menunjukkan bahwa aturan CILIUM_FORWARD sekarang dikonfigurasi dengan benar sebelum aturan KUBE-FORWARD:


Chain FORWARD (policy ACCEPT)
target                  prot opt source   destination
CILIUM_FORWARD          all  --  anywhere anywhere                /* cilium-feeder: CILIUM_FORWARD */
KUBE-FORWARD            all  --  anywhere anywhere                /* kubernetes forwarding rules */
KUBE-SERVICES           all  --  anywhere anywhere    ctstate NEW /* kubernetes service portals */
KUBE-EXTERNAL-SERVICES  all  --  anywhere anywhere    ctstate NEW /* kubernetes externally-visible service portals */
Upgrade dan update 1,9, 1,10

Fitur pratinjau tidak mempertahankan izin asli dan informasi pemilik

Fitur pratinjau cluster 1.9.x yang menggunakan bmctl 1.9.x tidak mempertahankan izin asli dan informasi pemilik. Untuk memverifikasi apakah Anda terpengaruh oleh fitur ini, ekstrak file yang dicadangkan menggunakan perintah berikut:


tar -xzvf BACKUP_FILE

Solusi

Verifikasi apakah metadata.json ada dan apakah bmctlVersion adalah 1.9.x. Jika metadata.json tidak ada, upgrade ke cluster 1.10.x dan gunakan bmctl 1.10.x untuk mencadangkan/memulihkan.
Upgrade dan pembuatan 1.14.2

clientconfig-operator terjebak dalam status tertunda dengan CreateContainerConfigError

Jika telah mengupgrade ke atau membuat cluster versi 1.14.2 dengan konfigurasi OIDC/LDAP, Anda mungkin melihat Pod clientconfig-operator macet dalam status tertunda. Dengan masalah ini, ada dua Pod clientconfig-operator, dengan satu dalam status berjalan dan yang lainnya 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 akan terpengaruh. Masalah ini telah diperbaiki dalam versi 1.14.3 dan semua rilis berikutnya, termasuk 1.15.0 dan yang lebih baru.


Solusi:

Sebagai solusinya, Anda dapat mem-patch deployment clientconfig-operator untuk menambahkan konteks keamanan tambahan dan memastikan bahwa deployment tersebut siap.

Gunakan perintah berikut untuk mem-patch clientconfig-operator di cluster target: 


kubectl patch deployment clientconfig-operator -n kube-system \
    -p '{"spec":{"template":{"spec":{"containers": [{"name":"oidcproxy","securityContext":{"runAsGroup":2038,"runAsUser":2038}}]}}}}' \
    --kubeconfig CLUSTER_KUBECONFIG

Ganti kode berikut:

  • CLUSTER_KUBECONFIG: jalur file kubeconfig untuk cluster target.
Operasi 1,11, 1,12, 1,13, 1,14, 1,15

Rotasi certificate authority gagal untuk cluster tanpa load balancing yang dipaketkan

Untuk cluster tanpa load balancing yang dipaketkan (spec.loadBalancer.mode ditetapkan 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 tidak responsif:


Signing CA completed in 3/0 control-plane nodes

Dalam hal ini, perintah pada akhirnya gagal. Log rotasi certificate-authority untuk cluster dengan tiga bidang kontrol dapat menyertakan entri seperti berikut: 


[2023-06-14 22:33:17+0000] waiting for all nodes to trust CA bundle OK
[2023-06-14 22:41:27+0000] waiting for first round of pod restart to complete OK
Signing CA completed in 0/0 control-plane nodes
Signing CA completed in 1/0 control-plane nodes
Signing CA completed in 2/0 control-plane nodes
Signing CA completed in 3/0 control-plane nodes
...
Unable to connect to the server: x509: certificate signed by unknown
authority (possibly because of "crypto/rsa: verification error" while
trying to verify candidate authority certificate "kubernetes")

Solusi

Jika Anda memerlukan bantuan tambahan, hubungi Dukungan Google.
Penginstalan, Jaringan 1.11, 1.12, 1.13, 1.14.0-1.14.1

ipam-controller-manager errorloop dalam cluster dual-stack

Saat Anda men-deploy cluster dual stack (cluster dengan alamat IPv4 dan IPv6), Pod ipam-controller-manager mungkin mengalami errorloop. Perilaku ini menyebabkan Node berputar di antara status Ready dan NotReady, serta dapat menyebabkan kegagalan penginstalan cluster. Masalah ini dapat terjadi saat server API kelebihan beban.

Untuk melihat apakah masalah ini memengaruhi Anda, periksa apakah Pod ipam-controller-manager gagal dengan error CrashLoopBackOff:


kubectl -n kube-system get pods | grep  ipam-controller-manager

Contoh output berikut menunjukkan Pod dalam status CrashLoopBackOff:


ipam-controller-manager-h7xb8   0/1  CrashLoopBackOff   3 (19s ago)   2m ipam-controller-manager-vzrrf   0/1  CrashLoopBackOff   3 (19s ago)   2m1s
ipam-controller-manager-z8bdw   0/1  CrashLoopBackOff   3 (31s ago)   2m2s

Dapatkan detail untuk Node yang memiliki status NotReady:


kubectl describe node <node-name> | grep PodCIDRs

Dalam cluster yang memiliki masalah ini, Node tidak memiliki PodCIDR yang ditetapkan padanya, seperti ditunjukkan dalam contoh output berikut:


PodCIDRs:

Dalam cluster yang responsif, semua Node harus memiliki PodCIDR dual-stack yang ditetapkan untuknya, seperti yang ditunjukkan dalam contoh output berikut:


PodCIDRs:    192.168.6.0/24,222:333:444:555:5:4:7:0/120

Solusi:

Mulai ulang Pod ipam-controller-manager:


kubectl -n kube-system rollout restart ds ipam-controller-manager
Operasi 1.6, 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13, dan 1.14

etcd melihat kelaparan

Cluster yang menjalankan etcd versi 3.4.13 atau sebelumnya mungkin mengalami kelaparan dan pengamatan resource non-operasional, yang dapat menyebabkan masalah berikut:

  • Penjadwalan pod terganggu
  • Node tidak dapat didaftarkan
  • kubelet tidak mengamati perubahan pod

Masalah ini dapat membuat cluster tidak berfungsi.

Masalah ini telah diperbaiki di GDCV untuk Bare Metal 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 GDCV sebelumnya untuk Bare Metal terpengaruh oleh masalah ini.

Solusi

Jika tidak dapat langsung melakukan upgrade, Anda dapat memitigasi risiko kegagalan cluster dengan mengurangi jumlah node dalam cluster Anda. Hapus node hingga metrik etcd_network_client_grpc_sent_bytes_total kurang dari 300 MBps.

Untuk melihat metrik ini di Metrics Explorer:

  1. Buka Metrics Explorer di Konsol Google Cloud:

    Buka Metrics Explorer

  2. Pilih tab Configuration
  3. Luaskan Select a metric, masukkan Kubernetes Container di panel filter, lalu gunakan submenu untuk memilih metrik:
    1. Di menu Active resources, pilih Kubernetes Container.
    2. Di menu Active metric category, pilih Anthos.
    3. Di menu Metrik aktif, pilih etcd_network_client_grpc_sent_bytes_total.
    4. Klik Terapkan.
Networking 1.11.6, 1.12.3

Status "Gagal" dalam mode vfio-pci operator SR-IOV

syncStatus objek SriovNetworkNodeState dapat melaporkan nilai "Gagal" untuk node yang dikonfigurasi. Untuk melihat status node dan menentukan apakah masalahnya memengaruhi Anda, jalankan perintah berikut:


kubectl -n gke-operators get \
    sriovnetworknodestates.sriovnetwork.k8s.cni.cncf.io NODE_NAME \
    -o jsonpath='{.status.syncStatus}'

Ganti NODE_NAME dengan nama node yang akan diperiksa.


Solusi:

Jika status objek SriovNetworkNodeState adalah "Gagal", upgrade cluster ke versi 1.11.7 atau yang lebih baru, atau versi 1.12.4 atau yang lebih baru.
Upgrade dan update 1.10, 1.11, 1.12, 1.13, 1.14.0, 1.14.1

Beberapa worker node tidak dalam status Siap setelah upgrade

Setelah upgrade selesai, beberapa worker node mungkin memiliki kondisi Siap yang ditetapkan ke false. Pada resource Node, Anda akan melihat error di samping kondisi Ready seperti 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:


sudo ls /etc/cni/net.d/

Solusi

Mulai ulang pod anetd node dengan menghapusnya.
Upgrade dan update, Keamanan 1.10

Beberapa rotasi sertifikat dari pengelola sertifikat menyebabkan inkonsistensi

Setelah beberapa rotasi sertifikat manual atau otomatis, pod webhook, seperti anthos-cluster-operator tidak diperbarui dengan sertifikat baru yang diterbitkan oleh cert-manager. Setiap update pada resource kustom cluster gagal dan menghasilkan error yang serupa sebagai berikut: 


Internal error occurred: failed calling
webhook "vcluster.kb.io": failed to call webhook: Post "https://webhook-service.kube-system.svc:443/validate-baremetal-cluster-gke-io-v1-cluster?timeout=10s": x509: certificate signed by unknown authority (possibly because of "x509:
invalid signature: parent certificate cannot sign this kind of certificate"
while trying to verify candidate authority certificate
"webhook-service.kube-system.svc")

Masalah ini dapat terjadi dalam keadaan berikut:

  • Jika Anda telah melakukan dua rotasi sertifikat yang diberikan oleh pengelola sertifikat manual pada cluster yang lebih lama dari 180 hari atau lebih dan tidak pernah memulai ulang anthos-cluster-operator.
  • Jika Anda telah melakukan cert-manager manual, lakukan rotasi sertifikat pada cluster yang lebih lama dari 90 hari atau lebih dan tidak pernah memulai ulang anthos-cluster-operator.

Solusi

Mulai ulang pod dengan menghentikan anthos-cluster-operator.
Upgrade dan update 1.14.0

Pod deployer pengontrol siklus proses yang sudah tidak berlaku lagi dibuat selama upgrade cluster pengguna

Dalam cluster admin versi 1.14.0, satu atau beberapa pod deployer pengontrol siklus proses yang sudah tidak berlaku mungkin akan dibuat selama upgrade cluster pengguna. Masalah ini berlaku untuk cluster pengguna yang awalnya dibuat pada versi di bawah 1.12. Pod yang dibuat secara tidak sengaja tidak akan menghambat operasi upgrade, tetapi dapat ditemukan dalam keadaan yang tidak terduga. Sebaiknya hapus 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:

  1. Mencantumkan resource pemeriksaan preflight: 
    
kubectl get preflightchecks --kubeconfig ADMIN_KUBECONFIG -A

    Outputnya akan terlihat seperti ini: 

    
NAMESPACE                    NAME                      PASS   AGE
cluster-ci-87a021b9dcbb31c   ci-87a021b9dcbb31c        true   20d
cluster-ci-87a021b9dcbb31c   ci-87a021b9dcbb31cd6jv6   false  20d

    di mana ci-87a021b9dcbb31c adalah nama cluster.

  2. Hapus resource yang nilainya di kolom PASS adalah true atau false.

    Misalnya, untuk menghapus resource dalam contoh output sebelumnya, gunakan perintah berikut:

    
kubectl delete preflightchecks ci-87a021b9dcbb31c \
    -n cluster-ci-87a021b9dcbb31c \
    --kubeconfig ADMIN_KUBECONFIG 
kubectl delete preflightchecks ci-87a021b9dcbb31cd6jv6 \
    -n cluster-ci-87a021b9dcbb31c \
    --kubeconfig ADMIN_KUBECONFIG
Networking 1,9, 1,10, 1,11, 1,12, 1,13, 1,14, 1,15, 1,16, 1,28

Status BGPSession terus berubah karena banyaknya rute masuk

GKE pada jaringan lanjutan Bare Metal gagal mengelola sesi BGP dengan benar jika peer eksternal mengiklankan rute dalam jumlah yang tinggi (sekitar 100 atau lebih). Dengan sejumlah besar rute masuk, pengontrol BGP lokal node membutuhkan waktu terlalu lama untuk merekonsiliasi sesi BGP dan gagal mengupdate status. Kurangnya update status, atau health check, menyebabkan sesi dihapus karena tidak berlaku lagi.

Perilaku yang tidak diinginkan pada sesi BGP yang mungkin Anda lihat dan menunjukkan adanya masalah meliputi hal-hal berikut:

  • Penghapusan dan pembuatan ulang bgpsession terus-menerus.
  • bgpsession.status.state tidak pernah menjadi Established
  • Rute yang gagal beriklan atau berulang kali diiklankan dan ditarik.

Masalah load balancing BGP mungkin akan muncul dengan masalah konektivitas ke layanan LoadBalancer.

Masalah FlatIP BGP mungkin terlihat karena masalah konektivitas ke Pod.

Untuk mengetahui apakah masalah BGP Anda disebabkan oleh peer jarak jauh yang mengiklankan terlalu banyak rute, gunakan perintah berikut untuk meninjau status dan output terkait:

  • Gunakan kubectl get bgpsessions di cluster yang terpengaruh. Output menunjukkan bgpsessions dengan status "Tidak Ditetapkan" dan waktu laporan terakhir terus-menerus dihitung hingga sekitar 10-12 detik sebelum tampak direset ke nol.
  • Output kubectl get bgpsessions menunjukkan bahwa sesi yang terpengaruh dibuat ulang berulang kali: 
    
kubectl get bgpsessions \
    -o jsonpath="{.items[*]['metadata.name', 'metadata.creationTimestamp']}"
  • Pesan log menunjukkan bahwa sesi BGP yang tidak berlaku sedang dihapus: 
    
kubectl logs ang-controller-manager-POD_NUMBER

    Ganti POD_NUMBER dengan pod pemimpin di cluster Anda.


Solusi:

Kurangi atau hilangkan jumlah rute yang diiklankan dari peer jarak jauh ke cluster dengan kebijakan ekspor.

Di GKE pada cluster Bare Metal versi 1.14.2 dan yang lebih baru, Anda juga dapat menonaktifkan fitur yang memproses rute yang diterima menggunakan AddOnConfiguration. Tambahkan argumen --disable-received-routes ke penampung bgpd daemonset ang-daemon.
Networking 1,14, 1,15, 1,16, 1,28

Waktu tunggu aplikasi yang disebabkan oleh kegagalan penyisipan tabel conntrack

Cluster yang berjalan di OS Ubuntu yang menggunakan kernel 5.15 atau yang lebih tinggi rentan terhadap kegagalan penyisipan tabel pelacakan koneksi netfilter (conntrack). Kegagalan penyisipan dapat terjadi meskipun tabel koneksi memiliki ruang untuk entri baru. Kegagalan disebabkan oleh perubahan pada kernel 5.15 dan versi yang lebih baru yang membatasi penyisipan tabel berdasarkan panjang rantai.

Untuk melihat apakah Anda terpengaruh oleh masalah ini, Anda dapat memeriksa statistik sistem pelacakan koneksi in-kernel dengan perintah berikut:


sudo conntrack -S

Responsnya akan terlihat seperti ini:


cpu=0       found=0 invalid=4 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=1       found=0 invalid=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=2       found=0 invalid=16 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=3       found=0 invalid=13 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=4       found=0 invalid=9 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=5       found=0 invalid=1 insert=0 insert_failed=0 drop=0 early_drop=0 error=519 search_restart=0 clash_resolve=126 chaintoolong=0
...

Jika nilai chaintoolong dalam respons bukan angka nol, berarti Anda akan terpengaruh oleh masalah ini.

Solusi

Mitigasi jangka pendek adalah meningkatkan ukuran tabel hash netfiler (nf_conntrack_buckets) dan tabel pelacakan koneksi netfilter (nf_conntrack_max). Gunakan perintah berikut pada setiap node cluster untuk meningkatkan ukuran tabel:


sysctl -w net.netfilter.nf_conntrack_buckets=TABLE_SIZE

sysctl -w net.netfilter.nf_conntrack_max=TABLE_SIZE

Ganti TABLE_SIZE dengan ukuran baru dalam byte. Nilai ukuran tabel default adalah 262144. Sebaiknya tetapkan nilai yang sama dengan 65.536 dikalikan dengan jumlah inti pada node. Misalnya, jika node Anda memiliki delapan core, tetapkan ukuran tabel ke 524288.
Upgrade dan update 1.11.3, 1.11.4, 1.11.5, 1.11.6, 1.11.7, 1.11.8, 1.12.4, 1.12.5, 1.12.6, 1.12.7, 1.12.8, 1.13.4, 1.13.4, 1.13.4

Tidak dapat memulihkan cadangan cluster dengan bmctl untuk beberapa versi

Sebaiknya cadangkan cluster sebelum mengupgrade sehingga Anda dapat memulihkan versi sebelumnya jika upgrade tidak berhasil. Masalah dengan perintah bmctl restore cluster menyebabkannya gagal memulihkan cadangan cluster dengan versi yang diidentifikasi. Masalah ini khusus untuk upgrade, yaitu saat Anda memulihkan cadangan versi sebelumnya.

Jika cluster Anda terpengaruh, log bmctl restore cluster akan berisi error berikut:


Error: failed to extract image paths from profile: anthos version VERSION not supported

Solusi:

Hingga masalah ini diperbaiki, sebaiknya gunakan petunjuk di Mencadangkan dan memulihkan cluster untuk mencadangkan cluster Anda secara manual dan memulihkannya secara manual, jika diperlukan.
Networking 1.10, 1.11, 1.12, 1.13, 1.14.0-1.14.2

NetworkGatewayGroup mengalami error jika tidak ada alamat IP pada antarmuka

NetworkGatewayGroup gagal membuat daemon untuk node yang tidak memiliki antarmuka IPv4 dan IPv6. Hal ini menyebabkan fitur seperti BGP LB dan OutboundNAT mengalami kegagalan. Jika Anda memeriksa log Pod ang-node yang gagal dalam namespace kube-system, error yang serupa 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\""}

Dalam contoh sebelumnya, tidak ada alamat IPv6 pada antarmuka ens192. Error ARP serupa ditampilkan jika node tidak memiliki alamat IPv4.

NetworkGatewayGroup mencoba membuat koneksi ARP dan koneksi NDP ke alamat IP lokal link. Jika alamat IP tidak ada (IPv4 untuk ARP, IPv6 untuk NDP), koneksi akan gagal dan daemon tidak dilanjutkan.

Masalah ini telah diperbaiki dalam rilis 1.14.3.


Solusi:

Hubungkan ke node menggunakan SSH dan tambahkan alamat IPv4 atau IPv6 ke link yang berisi IP node. Dalam contoh entri log sebelumnya, antarmuka ini adalah ens192:


ip address add dev INTERFACE scope link ADDRESS

Ganti kode berikut:

  • INTERFACE: Antarmuka untuk node Anda, seperti ens192.
  • ADDRESS: Alamat IP dan subnet mask yang akan diterapkan ke antarmuka.
Reset/Penghapusan 1.10, 1.11, 1.12, 1.13.0-1.13.2

Loop error anthos-cluster-operator saat menghapus node bidang kontrol

Saat Anda mencoba menghapus node bidang kontrol dengan menghapus alamat IP dari Cluster.Spec, anthos-cluster-operator akan memasuki status loop error yang memblokir operasi lainnya.


Solusi:

Masalah ini telah diperbaiki di 1.13.3 serta 1.14.0 dan yang lebih baru. Semua versi lainnya terpengaruh. Mengupgrade ke salah satu versi yang diperbaiki

Sebagai solusinya, jalankan perintah berikut:


kubectl label baremetalmachine IP_ADDRESS \
    -n CLUSTER_NAMESPACE baremetal.cluster.gke.io/upgrade-apply-

Ganti kode berikut:

  • IP_ADDRESS: Alamat IP node dalam status loop error.
  • CLUSTER_NAMESPACE: Namespace cluster.
Penginstalan 1.13.1, 1.13.2, dan 1.13.3

kubeadm join gagal dalam cluster besar karena ketidakcocokan token

Saat menginstal GKE pada cluster Bare Metal dengan node dalam jumlah besar, Anda mungkin melihat pesan error kubeadmin join yang mirip dengan contoh berikut:


TASK [kubeadm : kubeadm join --config /dev/stdin --ignore-preflight-errors=all] ***
fatal: [10.200.0.138]: FAILED! => {"changed": true, "cmd": "kubeadm join
--config /dev/stdin --ignore-preflight-errors=all", "delta": "0:05:00.140669", "end": "2022-11-01 21:53:15.195648", "msg": "non-zero return code", "rc": 1,
"start": "2022-11-01 21:48:15.054979", "stderr": "W1101 21:48:15.082440   99570 initconfiguration.go:119]
Usage of CRI endpoints without URL scheme is deprecated and can cause kubelet errors in the future.
Automatically prepending scheme \"unix\" to the \"criSocket\" with value \"/run/containerd/containerd.sock\". Please update your configuration!\nerror
execution phase preflight: couldn't validate the identity of the API Server: could not find a JWS signature in the cluster-info ConfigMap for token ID \"yjcik0\"\n
To see the stack trace of this error execute with --v=5 or higher", "stderr_lines":
["W1101 21:48:15.082440   99570 initconfiguration.go:119] Usage of CRI endpoints without URL scheme is deprecated and can cause kubelet errors in the future.
Automatically prepending scheme \"unix\" to the \"criSocket\" with value \"/run/containerd/containerd.sock\".
Please update your configuration!", "error execution phase preflight: couldn't validate the identity of the API Server:
could not find a JWS signature in the cluster-info ConfigMap for token ID \"yjcik0\"",
"To see the stack trace of this error execute with --v=5 or higher"], "stdout": "[preflight]
Running pre-flight checks", "stdout_lines": ["[preflight] Running pre-flight checks"]}

Solusi:

Masalah ini telah diatasi di GDCV untuk Bare Metal versi 1.13.4 dan yang lebih baru.

Jika Anda perlu menggunakan versi yang terpengaruh, pertama-tama buat cluster dengan kurang dari 20 node, lalu ubah ukuran cluster untuk menambahkan node lain setelah penginstalan selesai.
Logging dan pemantauan 1,10, 1,11, 1,12, 1,13,0

Batas CPU rendah untuk metrics-server di cluster Edge

Di GKE pada cluster Bare Metal Edge, batas CPU yang rendah untuk metrics-server dapat menyebabkan metrics-server sering dimulai ulang. Penskalaan Otomatis Pod Horizontal (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:

  • GKE pada cluster Bare Metal versi 1.x-1.12: 
    
kubectl get deployment metrics-server -n kube-system \
    -o yaml > metrics-server.yaml
  • GKE pada cluster Bare Metal versi 1.13 atau yang lebih baru: 
    
kubectl get deployment metrics-server -n gke-managed-metrics-server \
    -o yaml > metrics-server.yaml

Solusi:

Masalah ini telah diatasi di GKE pada cluster Bare Metal versi 1.13.1 atau yang lebih baru. Untuk memperbaiki masalah ini, upgrade cluster Anda.

Solusi jangka pendek hingga Anda dapat mengupgrade cluster adalah dengan meningkatkan batas CPU untuk metrics-server secara manual seperti berikut:

  1. Perkecil skala metrics-server-operator: 
    
kubectl scale deploy metrics-server-operator --replicas=0
  2. Update konfigurasi dan tingkatkan batas CPU:
    • GKE pada cluster Bare Metal versi 1.x-1.12: 
      
kubectl -n kube-system edit deployment metrics-server
    • GKE pada cluster Bare Metal versi 1.13: 
      
kubectl -n gke-managed-metrics-server edit deployment metrics-server

    Hapus baris --config-dir=/etc/config dan tingkatkan batas CPU, seperti ditunjukkan pada contoh berikut:

    
[...]
- command:
- /pod_nanny
# - --config-dir=/etc/config # <--- Remove this line
- --container=metrics-server
- --cpu=50m # <--- Increase CPU, such as to 50m
- --extra-cpu=0.5m
- --memory=35Mi
- --extra-memory=4Mi
- --threshold=5
- --deployment=metrics-server
- --poll-period=30000
- --estimator=exponential
- --scale-down-delay=24h
- --minClusterSize=5
- --use-metrics=true
[...]
  3. Simpan dan tutup metrics-server untuk menerapkan perubahan.
Networking 1,14, 1,15, 1,16

Koneksi NodePort langsung ke Pod hostNetwork tidak berfungsi

Koneksi ke Pod yang diaktifkan dengan hostNetwork menggunakan Layanan NodePort akan gagal jika Pod backend berada di node yang sama dengan NodePort yang ditargetkan. Masalah ini memengaruhi Layanan LoadBalancer saat digunakan dengan Pod yang di-hostNetwork. Dengan beberapa backend, kemungkinan akan ada 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 Service LoadBalancer, pastikan Pod yang di-hostNetwork-ed tidak berjalan pada 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 kumpulan node pekerja

Cluster admin versi 1.13.0 dan yang lebih tinggi tidak dapat berisi kumpulan node pekerja. Upgrade ke versi 1.13.0 atau yang lebih tinggi untuk cluster admin dengan kumpulan node pekerja akan diblokir. Jika upgrade cluster admin terhenti, Anda dapat mengonfirmasi apakah kumpulan node pekerja adalah penyebabnya dengan memeriksa error berikut di file upgrade-cluster.log di dalam folder bmctl-workspace:


Operation failed, retrying with backoff. Cause: error creating "baremetal.cluster.gke.io/v1, Kind=NodePool" cluster-test-cluster-2023-06-06-140654/np1: admission webhook "vnodepool.kb.io" denied the request: Adding worker nodepool to Admin cluster is disallowed.

Solusi:

Sebelum mengupgrade, pindahkan semua kumpulan node pekerja ke cluster pengguna. Untuk mengetahui petunjuk cara 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 resource kustom ClientConfig atau Stackdriver menggunakan kubectl apply, pengontrol mungkin akan 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 telah diupdate:

  1. Dapatkan definisi YAML yang ada: 
    
kubectl get stackdriver -n kube-system stackdriver \
    -o yaml > stackdriver.yaml
  2. Mengaktifkan fitur atau memperbarui konfigurasi di file YAML.
  3. Terapkan kembali file YAML yang telah diperbarui: 
    
kubectl apply -f stackdriver.yaml

Langkah terakhir untuk kubectl apply adalah tempat Anda mungkin mengalami masalah.


Solusi:

Jangan gunakan kubectl apply untuk mengubah resource yang ada. Sebagai gantinya, gunakan kubectl edit atau kubectl patch seperti yang ditunjukkan pada contoh berikut:

  1. Edit resource kustom Stackdriver: 
    
kubectl edit stackdriver -n kube-system stackdriver
  2. Mengaktifkan fitur atau memperbarui konfigurasi di file YAML.
  3. Simpan dan keluar dari editor

Pendekatan alternatif menggunakan kubectl patch:

  1. Dapatkan definisi YAML yang ada: 
    
kubectl get stackdriver -n kube-system stackdriver \
    -o yaml > stackdriver.yaml
  2. Mengaktifkan fitur atau memperbarui konfigurasi di file YAML.
  3. Terapkan kembali file YAML yang telah diperbarui: 
    
kubectl patch stackdriver stackdriver --type merge \
    -n kube-system --patch-file stackdriver.yaml
Logging dan pemantauan 1,12, 1,13, 1,14, 1,15, 1,16

Potongan backlog yang rusak menyebabkan stackdriver-log-forwarder crashloop

Errorloop stackdriver-log-forwarder akan terjadi jika mencoba memproses potongan backlog yang rusak. Contoh error berikut ditampilkan di 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 errorloop ini terjadi, Anda tidak dapat melihat log di Cloud Logging.


Solusi:

Untuk mengatasi error ini, selesaikan langkah-langkah berikut:

  1. Mengidentifikasi 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/ salah. Setiap file *.flb dengan pemeriksaan format yang gagal harus dihapus.
  2. Akhiri pod yang berjalan untuk stackdriver-log-forwarder: 
    
kubectl --kubeconfig KUBECONFIG -n kube-system \
    patch daemonset stackdriver-log-forwarder \
    -p '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'
    Ganti KUBECONFIG dengan jalur ke file kubeconfig cluster pengguna Anda.

    Pastikan Pod stackdriver-log-forwarder telah dihapus sebelum melanjutkan ke langkah berikutnya.
  3. Hubungkan ke node menggunakan SSH tempat stackdriver-log-forwarder berjalan.
  4. Pada node, hapus semua file *.flb yang rusak di var/log/fluent-bit-buffers/tail.1/.

    Jika ada terlalu banyak file yang rusak dan Anda ingin menerapkan skrip untuk membersihkan semua bagian backlog, gunakan skrip berikut:
    1. Deploy DaemonSet untuk membersihkan semua data kotor dalam buffer di fluent-bit: 
      
kubectl --kubeconfig KUBECONFIG -n kube-system apply -f - << EOF
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluent-bit-cleanup
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: fluent-bit-cleanup
  template:
    metadata:
      labels:
        app: fluent-bit-cleanup
    spec:
      containers:
      - name: fluent-bit-cleanup
        image: debian:10-slim
        command: ["bash", "-c"]
        args:
        - |
          rm -rf /var/log/fluent-bit-buffers/
          echo "Fluent Bit local buffer is cleaned up."
          sleep 3600
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        securityContext:
          privileged: true
      tolerations:
      - key: "CriticalAddonsOnly"
        operator: "Exists"
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      - key: node-role.gke.io/observability
        effect: NoSchedule
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
EOF
    2. Pastikan DaemonSet telah membersihkan semua node. Output dari dua perintah berikut harus sama dengan jumlah node dalam cluster: 
      
kubectl --kubeconfig KUBECONFIG logs \
    -n kube-system -l app=fluent-bit-cleanup | grep "cleaned up" | wc -l
kubectl --kubeconfig KUBECONFIG \
    -n kube-system get pods -l app=fluent-bit-cleanup --no-headers | wc -l
    3. Hapus pembersihan DaemonSet: 
      
kubectl --kubeconfig KUBECONFIG -n kube-system delete ds \
    fluent-bit-cleanup
    4. Mulai ulang Pod stackdriver-log-forwarder: 
      
kubectl --kubeconfig KUBECONFIG \
    -n kube-system patch daemonset stackdriver-log-forwarder --type json \
    -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'
Jaringan, Runtime VM di GDC 1.14.0

Memulai ulang Dataplane V2 (anetd) pada cluster dapat menyebabkan VM yang ada tidak dapat terhubung ke jaringan non-pod

Pada cluster multi-nic, memulai ulang Dataplane V2 (anetd) dapat menyebabkan virtual machine tidak dapat terhubung ke jaringan. Error yang mirip dengan berikut ini mungkin teramati dalam log pod anetd:


could not find an allocator to allocate the IP of the multi-nic endpoint

Solusi:

Anda dapat memulai ulang VM sebagai perbaikan cepat. Agar masalah ini tidak terulang, upgrade cluster Anda ke versi 1.14.1 atau yang lebih baru.
Operasi 1.13, 1.14.0, 1.14.1

gke-metrics-agent tidak memiliki batas memori di cluster profil Edge

Bergantung pada beban kerja cluster, gke-metrics-agent mungkin menggunakan memori lebih dari 4608 MiB. Masalah ini hanya memengaruhi GKE pada cluster profil Bare Metal Edge. Cluster profil default tidak terpengaruh.


Solusi:

Upgrade cluster Anda ke versi 1.14.2 atau yang lebih baru.
Penginstalan 1,12, 1,13

Pembuatan cluster mungkin gagal karena kondisi race

Jika Anda membuat cluster menggunakan kubectl, karena kondisi race, pemeriksaan preflight mungkin tidak pernah selesai. Akibatnya, pembuatan cluster mungkin gagal dalam kasus tertentu.

Rekonsiler pemeriksaan preflight membuat SecretForwarder untuk menyalin rahasia ssh-key default ke namespace target. Biasanya, pemeriksaan preflight memanfaatkan referensi pemilik dan merekonsiliasi setelah SecretForwarder selesai. Namun, dalam kasus yang jarang terjadi, referensi pemilik SecretForwarder dapat kehilangan referensi ke pemeriksaan preflight, sehingga menyebabkan pemeriksaan preflight macet. Akibatnya, pembuatan cluster gagal. Untuk melanjutkan rekonsiliasi pemeriksaan preflight berbasis pengontrol, hapus pod operator cluster atau hapus resource preflight-check. Jika Anda menghapus resource preflight-check, resource akan membuat yang lain dan melanjutkan rekonsiliasi. Atau, Anda dapat mengupgrade cluster yang ada (yang dibuat dengan versi sebelumnya) ke versi tetap.

Networking 1,9, 1,10, 1,11, 1,12, 1,13, 1,14, 1,15

Alamat IP yang dicadangkan tidak dirilis saat menggunakan plugin keberadaan dengan fitur multi-NIC

Di fitur multi-Nic, jika Anda menggunakan plugin keberadaan CNI dan menggunakan operasi CNI DEL untuk menghapus antarmuka jaringan untuk Pod, beberapa alamat IP yang dicadangkan mungkin tidak dirilis dengan benar. Hal ini terjadi saat operasi CNI DEL terganggu.

Anda dapat memverifikasi reservasi alamat IP Pod yang tidak digunakan dengan menjalankan perintah berikut:


kubectl get ippools -A --kubeconfig KUBECONFIG_PATH

Solusi:

Hapus secara manual alamat IP (ippool) yang tidak digunakan.
Penginstalan 1.10, 1.11.0, 1.11.1, 1.11.2

Node Problem Detector gagal di cluster pengguna 1.10.4

Node Problem Detector mungkin gagal dalam cluster pengguna versi 1.10.x, jika cluster admin versi 1.11.0, 1.11.1, atau 1.11.2 mengelola cluster pengguna 1.10.x. Jika Node Problem Detector gagal, log akan diperbarui dengan pesan error berikut:


Error - NPD not supported for anthos baremetal version 1.10.4:
anthos version 1.10.4 not supported.

Solusi

Upgrade cluster admin ke versi 1.11.3 untuk menyelesaikan masalah ini.
Operasi 1,14

Node cluster IPv4 mode pulau 1,14 memiliki mask CIDR pod berukuran 24

Pada rilis 1.14, setelan maxPodsPerNode tidak diperhitungkan untuk cluster mode pulau sehingga node akan diberi mask CIDR pod dengan ukuran 24 (256 alamat IP).nHal ini dapat menyebabkan cluster kehabisan alamat IP pod lebih awal dari yang diharapkan. Misalnya, jika cluster Anda memiliki mask CIDR pod 22, setiap node akan diberi mask CIDR pod 24, dan cluster hanya dapat mendukung hingga 4 node. Cluster Anda juga mungkin akan mengalami ketidakstabilan jaringan dalam periode churn pod tinggi jika maxPodsPerNode ditetapkan ke 129 atau lebih tinggi dan tidak ada overhead yang cukup di 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:

  1. Upgrade ke versi 1.14.1 atau yang lebih baru.
  2. Hapus worker node dan tambahkan kembali.
  3. 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 akan ditampilkan:


I0119 22:11:49.705596  107905 client.go:48] Operation failed, retrying with backoff.
Cause: error updating "baremetal.cluster.gke.io/v1, Kind=HealthCheck" cluster-user-ci-f3a04dc1b0d2ac8/user-ci-f3a04dc1b0d2ac8-network: admission webhook "vhealthcheck.kb.io"
denied the request: HealthCheck.baremetal.cluster.gke.io "user-ci-f3a04dc1b0d2ac8-network" is invalid:
Spec: Invalid value: v1.HealthCheckSpec{ClusterName:(*string)(0xc0003096e0), AnthosBareMetalVersion:(*string)(0xc000309690),
Type:(*v1.CheckType)(0xc000309710), NodePoolNames:[]string(nil), NodeAddresses:[]string(nil), ConfigYAML:(*string)(nil),
CheckImageVersion:(*string)(nil), IntervalInSeconds:(*int64)(0xc0015c29f8)}: Field is immutable

Solusi:

Hapus semua resource healthchecks.baremetal.cluster.gke.io di bagian namespace cluster, lalu jalankan kembali perintah bmctl restore cluster:

  1. Tampilkan daftar semua healthchecks.baremetal.cluster.gke.io resource: 
    
kubectl get healthchecks.baremetal.cluster.gke.io \
    --namespace=CLUSTER_NAMESPACE \
    --kubeconfig=ADMIN_KUBECONFIG

    Ganti kode berikut:

    • CLUSTER_NAMESPACE: namespace untuk cluster.
    • ADMIN_KUBECONFIG: jalur ke file kubeconfig cluster admin.
  2. Hapus semua healthchecks.baremetal.cluster.gke.io resource yang tercantum pada langkah sebelumnya: 
    
kubectl delete healthchecks.baremetal.cluster.gke.io \
    HEALTHCHECK_RESOURCE_NAME \
    --namespace=CLUSTER_NAMESPACE \
    --kubeconfig=ADMIN_KUBECONFIG
    Ganti HEALTHCHECK_RESOURCE_NAME dengan nama resource health check.
  3. Jalankan kembali perintah bmctl restore cluster.
Networking 1.12.0

Alamat IP eksternal layanan tidak berfungsi dalam mode datar

Dalam cluster yang memiliki flatIPv4 yang ditetapkan ke true, Layanan jenis LoadBalancer tidak dapat diakses oleh alamat IP eksternalnya.

Masalah ini telah diperbaiki 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 langsung dari 1.13.0 ke 1.14.x menggunakan bmctl 1.14.0 dan flag --use-bootstrap=false, upgrade tidak akan pernah selesai.

Error dengan operator preflight-check menyebabkan cluster tidak pernah menjadwalkan pemeriksaan yang diperlukan, yang berarti pemeriksaan preflight tidak pernah selesai.


Solusi:

Tingkatkan ke 1.13.1 terlebih dahulu sebelum Anda meningkatkan ke 1.14.x. Upgrade langsung dari 1.13.0 ke 1.13.1 akan berfungsi. Atau, upgrade dari 1.13.0 ke 1.14.x tanpa flag --use-bootstrap=false.
Upgrade dan update, Keamanan 1.13 dan 1.14

Cluster yang diupgrade ke 1.14.0 kehilangan taint master

Node bidang kontrol memerlukan salah satu dari dua taint tertentu untuk mencegah pod beban kerja dijadwalkan padanya. Saat Anda mengupgrade cluster GKE versi 1.13 ke versi 1.14.0, node bidang kontrol kehilangan taint yang diperlukan berikut:

  • node-role.kubernetes.io/master:NoSchedule
  • node-role.kubernetes.io/master:PreferNoSchedule

Masalah ini tidak menyebabkan kegagalan upgrade, tetapi pod yang tidak seharusnya berjalan pada node bidang kontrol dapat mulai melakukannya. Pod beban kerja ini dapat membebani node bidang kontrol dan menyebabkan ketidakstabilan cluster.

Menentukan apakah Anda terdampak

  1. Temukan node bidang kontrol, gunakan perintah berikut: 
    
kubectl get node -l 'node-role.kubernetes.io/control-plane' \
    -o name --kubeconfig KUBECONFIG_PATH
  2. Untuk memeriksa daftar taint pada node, gunakan perintah berikut: 
    
kubectl describe node NODE_NAME \
    --kubeconfig KUBECONFIG_PATH

    Jika tidak satu pun taint yang diperlukan tercantum, berarti Anda terpengaruh.

Solusi

Gunakan langkah-langkah berikut untuk setiap node bidang kontrol dari cluster versi 1.14.0 yang terpengaruh untuk memulihkan fungsi yang tepat. Langkah-langkah ini ditujukan untuk taint node-role.kubernetes.io/master:NoSchedule dan pod yang terkait. Jika Anda ingin agar node bidang kontrol menggunakan taint PreferNoSchedule, sesuaikan langkah-langkahnya.
Operasi, Runtime VM di GDC 1,11, 1,12, 1,13, 1,14, 1,15, 1,16, 1,28

Pembuatan VM sesekali gagal disertai error upload

Pembuatan Mesin Virtual (VM) baru dengan perintah kubectl virt create vm jarang gagal selama upload gambar. Masalah ini berlaku untuk VM Linux dan Windows. Error tersebut terlihat seperti contoh berikut: 


PVC default/heritage-linux-vm-boot-dv not found DataVolume default/heritage-linux-vm-boot-dv created
Waiting for PVC heritage-linux-vm-boot-dv upload pod to be ready... Pod now ready
Uploading data to https://10.200.0.51

 2.38 MiB / 570.75 MiB [>----------------------------------------------------------------------------------]   0.42% 0s

fail to upload image: unexpected return value 500,  ...

Solusi

Coba lagi perintah kubectl virt create vm untuk membuat VM Anda.
Upgrade dan update, Logging dan pemantauan 1,11

Komponen koleksi terkelola dalam cluster 1.11 tidak dipertahankan dalam upgrade ke 1.12

Komponen koleksi terkelola adalah bagian dari Google Cloud Managed Service for Prometheus. Jika Anda men-deploy komponen koleksi terkelola secara manual di namespace gmp-system cluster versi 1.11, resource terkait tidak akan dipertahankan saat Anda mengupgrade ke versi 1.12.

Mulai cluster versi 1.12.0, komponen Google Cloud Managed Service for Prometheus dalam namespace gmp-system dan definisi resource kustom terkait dikelola oleh stackdriver-operator dengan kolom enableGMPForApplications. Kolom enableGMPForApplications ditetapkan secara default ke true, jadi jika Anda men-deploy komponen Managed Service for Prometheus secara manual dalam namespace sebelum mengupgrade ke versi 1.12, resource akan dihapus oleh stackdriver-operator.

Solusi

Untuk mempertahankan resource koleksi yang dikelola secara manual:

  1. Mencadangkan semua resource kustom PodMonitoring yang ada.
  2. Upgrade cluster ke versi 1.12 dan aktifkan Managed Service for Prometheus.
  3. Deploy ulang resource kustom PodMonitoring pada cluster Anda yang telah diupgrade.
Upgrade dan update 1.13

Beberapa cluster versi 1.12 dengan runtime container Docker tidak dapat diupgrade ke versi 1.13

Jika cluster versi 1.12 yang menggunakan runtime container Docker tidak memiliki anotasi berikut, cluster tidak dapat mengupgrade ke versi 1.13:


baremetal.cluster.gke.io/allow-docker-container-runtime:  "true"

Jika Anda terpengaruh oleh masalah ini, bmctl akan menulis error berikut dalam file upgrade-cluster.log di dalam folder bmctl-workspace:


Operation failed, retrying with backoff. Cause: error creating "baremetal.cluster.gke.io/v1, Kind=Cluster": admission webhook
"vcluster.kb.io" denied the request: Spec.NodeConfig.ContainerRuntime: Forbidden: Starting with Anthos Bare Metal version 1.13 Docker container
runtime will not be supported. Before 1.13 please set the containerRuntime to containerd in your cluster resources.

Although highly discouraged, you can create a cluster with Docker node pools until 1.13 by passing the flag "--allow-docker-container-runtime" to bmctl
create cluster or add the annotation "baremetal.cluster.gke.io/allow-docker- container-runtime: true" to the cluster configuration file.

Hal ini kemungkinan besar terjadi pada cluster Docker versi 1.12 yang di-upgrade dari versi 1.11, karena upgrade tersebut tidak memerlukan anotasi untuk mempertahankan runtime container Docker. Dalam hal ini, cluster tidak memiliki anotasi saat mengupgrade ke 1.13. Perhatikan bahwa mulai dari versi 1.13, containerd adalah satu-satunya runtime container yang diizinkan.

Solusi:

Jika Anda terpengaruh oleh masalah ini, update resource cluster dengan anotasi yang hilang. Anda dapat menambahkan anotasi saat upgrade berjalan atau setelah pembatalan dan sebelum mencoba kembali upgrade.
Penginstalan 1,11

bmctl keluar sebelum pembuatan cluster selesai

Pembuatan cluster mungkin gagal untuk GDCV untuk Bare Metal versi 1.11.0 (masalah ini telah diperbaiki pada rilis GDCV untuk Bare Metal 1.11.1). Dalam beberapa kasus, perintah bmctl create cluster keluar lebih awal dan menulis error seperti berikut ke log:


Error creating cluster: error waiting for applied resources: provider cluster-api watching namespace USER_CLUSTER_NAME not found in the target cluster

Solusi

Operasi yang gagal menghasilkan artefak, tetapi cluster tidak beroperasi. Jika Anda mengalami masalah ini, gunakan langkah-langkah berikut untuk membersihkan artefak dan membuat cluster:
Penginstalan, Runtime VM di GDC 1,11, 1,12

Error rekonsiliasi runtime VM laporan penginstalan

Operasi pembuatan cluster dapat melaporkan error yang mirip dengan berikut ini:


I0423 01:17:20.895640 3935589 logs.go:82]  "msg"="Cluster reconciling:" "message"="Internal error occurred: failed calling webhook \"vvmruntime.kb.io\": failed to call webhook: Post \"https://vmruntime-webhook-service.kube-system.svc:443/validate-vm-cluster-gke-io-v1vmruntime?timeout=10s\": dial tcp 10.95.5.151:443: connect: connection refused" "name"="xxx" "reason"="ReconciliationError"

Solusi

Error ini tidak berbahaya dan Anda dapat mengabaikannya dengan aman.
Penginstalan 1,10, 1,11, 1,12

Pembuatan cluster gagal saat menggunakan multi-NIC, containerd, dan proxy HTTPS

Pembuatan cluster akan gagal jika Anda memiliki kombinasi kondisi berikut:

  • Cluster dikonfigurasi untuk menggunakan containerd sebagai runtime container (nodeConfig.containerRuntime ditetapkan ke containerd dalam file konfigurasi cluster, default untuk GDCV untuk Bare Metal versi 1.13 dan yang lebih baru).
  • Cluster dikonfigurasi untuk menyediakan beberapa antarmuka jaringan, multi-NIC, untuk pod (clusterNetwork.multipleNetworkInterfaces ditetapkan ke true dalam file konfigurasi cluster).
  • Cluster dikonfigurasi untuk menggunakan proxy (spec.proxy.url ditentukan dalam file konfigurasi cluster). Meskipun pembuatan cluster gagal, setelan ini akan disebarkan saat Anda mencoba membuat cluster. Anda mungkin melihat setelan proxy ini sebagai variabel lingkungan HTTPS_PROXY atau dalam konfigurasi containerd (/etc/systemd/system/containerd.service.d/09-proxy.conf).

Solusi

Tambahkan CIDR layanan (clusterNetwork.services.cidrBlocks) ke variabel lingkungan NO_PROXY di semua mesin node.
Penginstalan 1,10, 1,11, 1,12

Kegagalan pada sistem dengan setelan umask yang ketat

Rilis GDCV untuk Bare Metal 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 umask 0077 yang lebih ketat.


Solusi

Reset node bidang kontrol dan ubah setelan umask ke 0022 di semua mesin bidang kontrol. Setelah komputer diupdate, coba instal lagi.

Atau, Anda dapat mengubah izin direktori dan file /etc/kubernetes pada mesin bidang kontrol agar penginstalan atau upgrade dapat dilanjutkan.

  • Buat /etc/kubernetes dan semua subdirektorinya dapat dibaca: chmod o+rx.
  • Buat semua file milik pengguna root dalam direktori (rekursif) /etc/kubernetes dapat dibaca secara global (chmod o+r). Kecualikan file kunci pribadi (.key) dari perubahan ini karena telah dibuat dengan kepemilikan dan izin yang benar.
  • Buat /usr/local/etc/haproxy/haproxy.cfg dapat dibaca secara global.
  • Buat /usr/local/etc/bgpadvertiser/bgpadvertiser-cfg.yaml dapat dibaca oleh semua orang.
Penginstalan 1,10, 1,11, 1,12, 1,13

Inkompatibilitas grup kontrol v2

Grup kontrol v2 (cgroup v2) tidak didukung di GKE pada cluster Bare Metal versi 1.13 dan yang lebih lama dari GDCV untuk Bare Metal. 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 ke versi 1.14.
Penginstalan 1,10, 1,11, 1,12, 1,13, 1,14, 1,15, 1,16, 1,28

Pemeriksaan preflight dan kredensial akun layanan

Untuk penginstalan yang dipicu oleh cluster hybrid atau admin (dengan kata lain, cluster yang tidak dibuat dengan bmctl, seperti cluster pengguna), pemeriksaan preflight tidak memverifikasi kredensial akun layanan Google Cloud atau izin terkait.
Penginstalan 1,10, 1,11, 1,12, 1,13, 1,14, 1,15, 1,16, 1,28

Menginstal di vSphere

Saat menginstal GKE pada cluster Bare Metal pada VM vSphere, Anda harus menonaktifkan flag tx-udp_tnl-segmentation dan tx-udp_tnl-csum-segmentation. Flag ini berkaitan dengan pengurangan segmentasi hardware yang dilakukan oleh driver vSphere VMXNET3 dan tidak berfungsi dengan tunnel GENEVE GKE pada cluster Bare Metal.


Solusi

Jalankan perintah berikut pada setiap node untuk memeriksa nilai saat ini untuk tanda ini:


ethtool -k NET_INTFC | grep segm

Ganti NET_INTFC dengan antarmuka jaringan yang terkait dengan alamat IP node.

Respons harus memiliki entri seperti berikut:


...
tx-udp_tnl-segmentation: on
tx-udp_tnl-csum-segmentation: on
...
Terkadang di RHEL 8.4, ethtool menunjukkan tanda ini nonaktif, sedangkan tidak aktif. Untuk menonaktifkan tanda ini secara eksplisit, aktifkan dan nonaktifkan tanda dengan perintah berikut: 

ethtool -K ens192 tx-udp_tnl-segmentation on ethtool -K ens192 \
    tx-udp_tnl-csum-segmentation on
ethtool -K ens192 tx-udp_tnl-segmentation off ethtool -K ens192 \
    tx-udp_tnl-csum-segmentation off

Perubahan tanda ini tidak akan dipertahankan saat mulai ulang. Konfigurasi skrip startup untuk menetapkan flag ini secara eksplisit saat sistem melakukan booting.
Upgrade dan update 1.10

bmctl tidak dapat membuat, mengupdate, atau mereset cluster pengguna 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 terpengaruh oleh masalah ini, Anda akan melihat log seperti berikut saat menggunakan bmctl:


[2022-06-02 05:36:03-0500] error judging if the cluster is managing itself: error to parse the target cluster: error parsing cluster config: 1 error occurred:

*   cluster version 1.8.1 isn't supported in bmctl version 1.9.5, only cluster version 1.9.5 is supported

Solusi:

Gunakan kubectl untuk membuat, mengedit, atau menghapus resource kustom cluster pengguna di dalam cluster admin.

Kemampuan untuk mengupgrade cluster pengguna tidak terpengaruh.
Upgrade dan update 1.12

Upgrade cluster ke versi 1.12.1 mungkin akan terhenti

Mengupgrade cluster ke versi 1.12.1 terkadang terhenti karena server API tidak tersedia. Masalah ini memengaruhi semua jenis cluster dan semua sistem operasi yang didukung. Jika masalah ini terjadi, perintah bmctl upgrade cluster dapat gagal di beberapa titik, termasuk selama fase kedua pemeriksaan preflight.


Solusi

Anda dapat memeriksa log upgrade untuk mengetahui apakah Anda terpengaruh oleh masalah ini. Log upgrade terletak di /baremetal/bmctl-workspace/CLUSTER_NAME/log/upgrade-cluster-TIMESTAMP secara default.

upgrade-cluster.log mungkin berisi error seperti berikut:


Failed to upgrade cluster: preflight checks failed: preflight check failed
Log mesin mungkin berisi error seperti berikut (kegagalan berulang menunjukkan bahwa Anda terpengaruh oleh masalah ini): 

FAILED - RETRYING: Query CNI health endpoint (30 retries left). FAILED - RETRYING: Query CNI health endpoint (29 retries left).
FAILED - RETRYING: Query CNI health endpoint (28 retries left). ...

HAProxy dan Keepalive harus berjalan di setiap node bidang kontrol sebelum Anda mencoba kembali untuk mengupgrade cluster ke versi 1.12.1. Gunakan antarmuka command line crictl pada setiap node untuk memeriksa apakah container haproxy dan keepalived berjalan:


docker/crictl ps | grep haproxy docker/crictl ps | grep keepalived

Jika HAProxy atau Keepalive tidak berjalan di node, mulai ulang kubelet di node tersebut:


systemctl restart kubelet
Upgrade dan update, Runtime VM di GDC 1,11, 1,12

Upgrade cluster ke versi 1.12.0 atau yang lebih tinggi akan gagal jika Runtime VM di GDC diaktifkan

Pada GKE versi 1.12.0 di cluster Bare Metal, semua resource yang terkait dengan Runtime VM di GDC dimigrasikan ke namespace vm-system untuk lebih mendukung Runtime VM di rilis GA GDC. Jika Anda mengaktifkan VM Runtime di GDC dalam cluster versi 1.11.x atau yang lebih rendah, upgrade ke versi 1.12.0 atau yang lebih tinggi akan gagal, kecuali jika Anda menonaktifkan Runtime VM 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

Solusi

Untuk menonaktifkan Runtime VM di GDC:

  1. Edit resource kustom VMRuntime: 
    
kubectl edit vmruntime
  2. Tetapkan enabled ke false dalam spesifikasi: 
    
apiVersion: vm.cluster.gke.io/v1
kind: VMRuntime
metadata:
  name: vmruntime
spec:
  enabled: false
  ...
  3. Simpan resource kustom tersebut di editor Anda.
  4. Setelah upgrade cluster selesai, aktifkan kembali Runtime VM di GDC.

Untuk mengetahui informasi selengkapnya, lihat Bekerja dengan workload berbasis VM.

Upgrade dan update 1,10, 1,11, 1,12

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 tidak diperbarui dengan benar. Untuk mengetahui apakah Anda terpengaruh oleh masalah ini dan untuk memperbaikinya, periksa log anthos-cluster-operator dan cari error yang mirip dengan entri berikut:


controllers/Cluster "msg"="error during manifests operations" "error"="1 error occurred: ... {RESOURCE_NAME} is invalid: metadata.resourceVersion: Invalid value: 0x0: must be specified for an update

Entri ini adalah gejala dari resource yang salah diperbarui, dengan {RESOURCE_NAME} sebagai nama resource masalah.


Solusi

Jika Anda menemukan error ini di log Anda, selesaikan langkah-langkah berikut:

  1. Gunakan kubectl edit untuk menghapus anotasi kubectl.kubernetes.io/last-applied-configuration dari resource yang terdapat dalam pesan log.
  2. Simpan dan terapkan perubahan pada resource tersebut.
  3. Coba upgrade cluster lagi.
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 keluar atau load balancing paket dengan BGP. Fitur ini menggunakan {i>Network Gateway<i} untuk GDC. Upgrade cluster terhambat 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 berhenti memblokir upgrade, jalankan perintah berikut pada cluster yang sedang Anda upgrade:


kubectl -n kube-system delete deployment \
    ang-controller-manager-autoscaler
kubectl -n kube-system delete deployment \
    ang-controller-manager
kubectl -n kube-system delete ds ang-node
Upgrade dan update 1,10, 1,11, 1,12, 1,13, 1,14, 1,15

bmctl update tidak menghapus blok pemeliharaan

Perintah bmctl update tidak dapat menghapus atau mengubah bagian maintenanceBlocks dari konfigurasi resource cluster.


Solusi

Untuk informasi selengkapnya, termasuk petunjuk untuk menghapus node dari mode pemeliharaan, lihat Memasukkan node ke mode pemeliharaan.
Operasi 1,10, 1,11, 1,12

Node dilepas kordon jika Anda tidak menggunakan prosedur mode pemeliharaan

Jika Anda menjalankan cluster versi 1.12.0 (anthosBareMetalVersion: 1.12.0) atau yang lebih rendah dan menggunakan kubectl cordon secara manual pada sebuah node, GKE di Bare Metal mungkin akan melepaskan batasan node sebelum Anda siap dalam upaya merekonsiliasi status yang diharapkan.


Solusi

Untuk cluster versi 1.12.0 dan yang lebih rendah, gunakan mode pemeliharaan untuk menghubungkan dan menghabiskan node dengan aman.

Pada versi 1.12.1 (anthosBareMetalVersion: 1.12.1) atau yang lebih baru, GKE di Bare Metal tidak akan membuka kunci node secara tiba-tiba saat Anda menggunakan kubectl cordon.
Operasi 1,11

Cluster admin versi 11 yang menggunakan mirror registry tidak dapat mengelola cluster versi 1.10

Jika Anda menggunakan versi 1.11 dan menggunakan registry registry, cluster admin tidak dapat mengelola cluster pengguna yang menggunakan versi minor yang lebih rendah. Masalah ini memengaruhi operasi reset, update, dan upgrade di cluster pengguna.

Untuk menentukan apakah masalah ini memengaruhi Anda atau tidak, periksa log Anda untuk menemukan operasi cluster, seperti membuat, mengupgrade, atau mereset. 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

Rahasia kubeconfig ditimpa

Perintah bmctl check cluster, saat dijalankan di cluster pengguna, menimpa Secret cluster pengguna kubeconfig dengan cluster admin kubeconfig. Mengganti file menyebabkan operasi cluster standar, seperti mengupdate dan mengupgrade, gagal untuk cluster pengguna yang terpengaruh. Masalah ini berlaku untuk GKE pada cluster Bare Metal versi 1.11.1 dan yang lebih lama.

Untuk menentukan apakah masalah ini memengaruhi cluster pengguna, jalankan perintah berikut:


kubectl --kubeconfig ADMIN_KUBECONFIG \
    get secret -n USER_CLUSTER_NAMESPACE \
    USER_CLUSTER_NAME -kubeconfig \
    -o json  | jq -r '.data.value'  | base64 -d

Ganti kode berikut:

  • ADMIN_KUBECONFIG: jalur ke file kubeconfig cluster admin.
  • USER_CLUSTER_NAMESPACE: namespace untuk cluster. Secara default, namespace cluster untuk GKE pada cluster Bare Metal 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 pada contoh output berikut) adalah nama cluster admin, cluster pengguna yang ditentukan akan terpengaruh.


apiVersion: v1
clusters:
- cluster:
    certificate-authority-data:LS0tLS1CRU...UtLS0tLQo=
    server: https://10.200.0.6:443
  name: ci-aed78cdeca81874
contexts:
- context:
    cluster: ci-aed78cdeca81
    user: ci-aed78cdeca81-admin
  name: ci-aed78cdeca81-admin@ci-aed78cdeca81
current-context: ci-aed78cdeca81-admin@ci-aed78cdeca81
kind: Config
preferences: {}
users:
- name: ci-aed78cdeca81-admin
  user:
    client-certificate-data: LS0tLS1CRU...UtLS0tLQo=
    client-key-data: LS0tLS1CRU...0tLS0tCg==

Solusi

Langkah-langkah berikut akan memulihkan fungsi ke cluster pengguna yang terpengaruh (USER_CLUSTER_NAME):

  1. Temukan file kubeconfig cluster pengguna. GKE di Bare Metal menghasilkan file kubeconfig di workstation admin saat Anda membuat cluster. Secara default, file berada di direktori bmctl-workspace/USER_CLUSTER_NAME.
  2. Verifikasi bahwa cluster pengguna kubeconfig sudah benar: kubeconfig: 
    
kubectl get nodes \
    --kubeconfig PATH_TO_GENERATED_FILE
    Ganti PATH_TO_GENERATED_FILE dengan jalur ke file kubeconfig cluster pengguna. Responsnya menampilkan detail tentang node untuk cluster pengguna. Pastikan nama mesin sudah benar untuk cluster Anda.
  3. Jalankan perintah berikut untuk menghapus file kubeconfig yang rusak di cluster admin: 
    
kubectl delete secret \
    -n USER_CLUSTER_NAMESPACE \
    USER_CLUSTER_NAME-kubeconfig
  4. Jalankan perintah berikut untuk menyimpan kembali secret kubeconfig yang benar ke cluster admin: 
    
kubectl create secret generic \
    -n USER_CLUSTER_NAMESPACE \
    USER_CLUSTER_NAME-kubeconfig \
    --from-file=value=PATH_TO_GENERATED_FILE
Operasi 1,10, 1,11, 1,12, 1,13, 1,14, 1,15, 1,16, 1,28

Mengambil snapshot sebagai pengguna login non-root

Jika Anda menggunakan containerd sebagai runtime container, menjalankan snapshot sebagai pengguna non-root mengharuskan /usr/local/bin berada dalam PATH pengguna. Jika tidak, skrip akan gagal dengan error crictl: command not found.

Jika Anda tidak login sebagai pengguna root, sudo akan digunakan untuk menjalankan perintah snapshot. PATH sudo dapat berbeda dengan profil root dan mungkin tidak berisi /usr/local/bin.


Solusi

Update secure_path di /etc/sudoers untuk menyertakan /usr/local/bin. Atau, buat link simbolis untuk crictl di direktori /bin lain.
Logging dan pemantauan 1.10

stackdriver-log-forwarder memiliki [parser:cri] invalid time format log peringatan

Jika Parser antarmuka runtime container (CRI) menggunakan ekspresi reguler yang salah untuk mengurai waktu, log untuk Pod stackdriver-log-forwarder akan berisi error dan peringatan seperti berikut:


[2022/03/04 17:47:54] [error] [parser] time string length is too long [2022/03/04 20:16:43] [ warn] [parser:cri] invalid time format %Y-%m-%dT%H:%M:%S.%L%z for '2022-03-04T20:16:43.680484387Z'

Solusi:
Logging dan pemantauan 1,10, 1,11, 1,12, 1,13, 1,14, 1,15

Penagihan pemantauan yang tidak terduga

Untuk GKE pada cluster Bare Metal versi 1.10 hingga 1.15, beberapa pelanggan menemukan tagihan yang tinggi secara tidak terduga untuk Metrics volume di halaman Penagihan. Masalah ini hanya memengaruhi Anda jika semua keadaan berikut berlaku:

  • Pemantauan aplikasi diaktifkan (enableStackdriverForApplications=true)
  • Managed Service for Prometheus tidak diaktifkan (enableGMPForApplications)
  • Pod Aplikasi memiliki anotasi prometheus.io/scrap=true

Untuk mengonfirmasi apakah Anda terpengaruh oleh masalah ini, cantumkan metrik yang ditentukan pengguna. Jika Anda melihat penagihan untuk metrik yang tidak diinginkan, berarti masalah ini berlaku untuk Anda.


Solusi

Jika Anda terdampak oleh masalah ini, sebaiknya upgrade cluster Anda ke versi 1.12 dan beralihlah ke solusi pemantauan aplikasi baru managed-service-for-prometheus yang mengatasi masalah ini:

  • Pisahkan tanda untuk mengontrol pengumpulan log aplikasi versus metrik aplikasi
  • Google Cloud Managed Service for Prometheus Paket

    • Jika Anda tidak dapat mengupgrade ke versi 1.12, gunakan langkah-langkah berikut:

    1. Temukan Pod dan Service sumber yang memiliki penagihan yang tidak diinginkan: 
      
kubectl --kubeconfig KUBECONFIG \
    get pods -A -o yaml | grep 'prometheus.io/scrape: "true"'
kubectl --kubeconfig KUBECONFIG get \
    services -A -o yaml | grep 'prometheus.io/scrape: "true"'
    2. Hapus anotasi prometheus.io/scrap=true dari Pod atau Service.
    Logging dan pemantauan 1,11, 1,12, 1,13, 1,14, 1,15, 1,16, 1,28

    Pengeditan pada metrics-server-config tidak dipertahankan

    Dalam kasus yang ekstrem, kepadatan pod yang tinggi dapat membuat overhead logging dan pemantauan berlebihan, yang dapat menyebabkan Server Metrics berhenti dan dimulai ulang. Anda dapat mengedit ConfigMap metrics-server-config 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 update cluster atau operasi upgrade. Metrics Server tidak langsung terpengaruh, tetapi saat dimulai ulang, Server akan mengambil ConfigMap yang dikembalikan dan rentan terhadap overhead yang berlebihan, lagi.


    Solusi

    Untuk versi 1.11.x, Anda dapat membuat skrip edit ConfigMap dan menjalankannya bersama dengan update atau upgrade ke cluster. Untuk versi 1.12 dan yang lebih baru, hubungi dukungan.
    Logging dan pemantauan 1,11, 1,12

    Metrik yang tidak digunakan lagi memengaruhi dasbor Cloud Monitoring

    Beberapa metrik GKE pada Bare Metal tidak digunakan lagi dan, dimulai dengan rilis GDCV untuk Bare Metal 1.11, data tidak lagi dikumpulkan untuk metrik yang tidak digunakan lagi ini. Jika Anda menggunakan metrik ini dalam salah satu kebijakan pemberitahuan, tidak akan ada data untuk memicu kondisi pemberitahuan.

    Tabel berikut mencantumkan setiap metrik yang tidak digunakan lagi dan metrik yang menggantikannya.

    Metrik yang tidak digunakan lagi Metrik penggantian
    kube_daemonset_updated_number_scheduled kube_daemonset_status_updated_number_scheduled
    kube_node_status_allocatable_cpu_cores
    kube_node_status_allocatable_memory_bytes
    kube_node_status_allocatable_pods    		 kube_node_status_allocatable
    kube_node_status_capacity_cpu_cores
    kube_node_status_capacity_memory_bytes
    kube_node_status_capacity_pods    		 kube_node_status_capacity

    Pada GKE pada cluster Bare Metal versi 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 diupdate untuk rilis 1.11.0 dan yang lebih baru.


    Solusi

    Gunakan langkah-langkah berikut untuk bermigrasi ke metrik pengganti:

    1. Di konsol Google Cloud, pilih Monitoring atau klik tombol berikut:
      Buka Monitoring
    2. Di panel navigasi, pilih Dashboards, lalu hapus dasbor Anthos cluster node status.
    3. Klik tab Sample library dan instal ulang dasbor Anthos cluster node status.
    4. Ikuti petunjuk dalam artikel Membuat kebijakan pemberitahuan untuk membuat kebijakan menggunakan file definisi kebijakan node-cpu-usage-high.json yang telah diperbarui.
    Logging dan pemantauan 1,10, 1,11

    stackdriver-log-forwarder memiliki CrashloopBackOff error

    Dalam beberapa situasi, agen logging fluent-bit dapat kesulitan memproses potongan yang rusak. Jika agen logging tidak dapat mengabaikan bagian yang rusak, Anda mungkin mengamati bahwa stackdriver-log-forwarder terus mengalami error dengan error CrashloopBackOff. Jika Anda mengalami masalah ini, log Anda memiliki entri seperti berikut

    
[2022/03/09 02:18:44] [engine] caught signal (SIGSEGV) #0  0x5590aa24bdd5
in  validate_insert_id() at plugins/out_stackdriver/stackdriver.c:1232
#1  0x5590aa24c502      in  stackdriver_format() at plugins/out_stackdriver/stackdriver.c:1523
#2  0x5590aa24e509      in  cb_stackdriver_flush() at plugins/out_stackdriver/stackdriver.c:2105
#3  0x5590aa19c0de      in  output_pre_cb_flush() at include/fluent-bit/flb_output.h:490
#4  0x5590aa6889a6      in  co_init() at lib/monkey/deps/flb_libco/amd64.c:117 #5  0xffffffffffffffff  in  ???() at ???:0

    Solusi:

    Bersihkan bagian buffer untuk Stackdriver Log Forwarder.

    Catatan: Dalam perintah berikut, ganti KUBECONFIG dengan jalur ke file kubeconfig cluster admin.

    1. Hentikan semua pod stackdriver-log-forwarder: 
      
kubectl --kubeconfig KUBECONFIG -n kube-system patch daemonset \
    stackdriver-log-forwarder -p \
    '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'
      Pastikan bahwa stackdriver-log-forwarder pod telah dihapus sebelum melanjutkan ke langkah berikutnya.
    2. Deploy DaemonSet berikut untuk membersihkan data yang rusak di buffer fluent-bit: 
      
kubectl --kubeconfig KUBECONFIG -n kube-system apply -f - << EOF
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluent-bit-cleanup
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: fluent-bit-cleanup
  template:
    metadata:
      labels:
        app: fluent-bit-cleanup
    spec:
      containers:
      - name: fluent-bit-cleanup
        image: debian:10-slim
        command: ["bash", "-c"]
        args:
        - |
          rm -rf /var/log/fluent-bit-buffers/
          echo "Fluent Bit local buffer is cleaned up."
          sleep 3600
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        securityContext:
          privileged: true
      tolerations:
      - key: "CriticalAddonsOnly"
        operator: "Exists"
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      - key: node-role.gke.io/observability
        effect: NoSchedule
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
EOF
    3. Gunakan perintah berikut untuk memverifikasi bahwa DaemonSet telah membersihkan semua node: 
      
kubectl --kubeconfig KUBECONFIG logs \
    -n kube-system -l \
    app=fluent-bit-cleanup | grep "cleaned up" | wc -l
kubectl --kubeconfig KUBECONFIG -n \
    kube-system get pods -l \
    app=fluent-bit-cleanup --no-headers | wc -l
      Output kedua perintah tersebut harus sama dengan jumlah node di cluster Anda.
    4. Hapus pembersihan DaemonSet: 
      
kubectl --kubeconfig KUBECONFIG -n \
    kube-system delete ds fluent-bit-cleanup
    5. Mulai ulang pod penerus log: 
      
kubectl --kubeconfig KUBECONFIG \
    -n kube-system patch daemonset \
    stackdriver-log-forwarder --type json \
    -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'
    Logging dan pemantauan 1,10, 1,11, 1,12, 1,13, 1,14, 1,15, 1,16, 1,28

    Error metrik tidak dikenal di log gke-metrics-agent

    gke-metrics-agent adalah daemonset yang mengumpulkan metrik pada setiap node dan meneruskannya ke Cloud Monitoring. Alat ini dapat menghasilkan log seperti berikut:

    
Unknown metric: kubernetes.io/anthos/go_gc_duration_seconds_summary_percentile

    Error serupa dapat terjadi pada jenis metrik lain, termasuk (tetapi tidak terbatas pada):

    • apiserver_admission_step_admission_duration_seconds_summary
    • go_gc_duration_seconds
    • scheduler_scheduling_duration_seconds
    • gkeconnect_http_request_duration_seconds_summary
    • alertmanager_nflog_snapshot_duration_seconds_summary

    Log error ini dapat diabaikan dengan aman karena metrik yang dirujuknya tidak didukung dan tidak penting untuk tujuan pemantauan.
    Logging dan pemantauan 1,10, 1,11

    Gangguan ekspor metrik sesekali

    GKE pada cluster Bare Metal mungkin mengalami gangguan saat mengekspor metrik secara normal dan berkelanjutan, atau kehilangan metrik pada beberapa node. Jika masalah ini memengaruhi cluster Anda, Anda mungkin akan melihat kesenjangan dalam data untuk metrik berikut (setidaknya):

    • kubernetes.io/anthos/container_memory_working_set_bytes
    • kubernetes.io/anthos/container_cpu_usage_seconds_total
    • kubernetes.io/anthos/container_network_receive_bytes_total

    Solusi

    Upgrade cluster Anda ke versi 1.11.1 atau yang lebih baru.

    Jika Anda tidak dapat melakukan upgrade, lakukan langkah-langkah berikut sebagai solusi:

    1. Buka resource stackdriver untuk mengedit: 
      
kubectl -n kube-system edit stackdriver stackdriver
    2. Guna meningkatkan permintaan CPU untuk gke-metrics-agent dari 10m menjadi 50m, tambahkan bagian resourceAttrOverride berikut ke manifes stackdriver: 
      
spec:
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      limits:
        cpu: 100m
        memory: 4608Mi
      requests:
        cpu: 50m
        memory: 200Mi
      Resource yang diedit akan terlihat seperti berikut: 
      
spec:
  anthosDistribution: baremetal
  clusterLocation: us-west1-a
  clusterName: my-cluster
  enableStackdriverForApplications: true
  gcpServiceAccountSecretName: ...
  optimizedMetrics: true
  portable: true
  projectID: my-project-191923
  proxyConfigSecretName: ...
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      limits:
        cpu: 100m
        memory: 4608Mi
      requests:
        cpu: 50m
        memory: 200Mi
    3. Simpan perubahan Anda dan tutup editor teks.
    4. Untuk memastikan perubahan telah diterapkan, jalankan perintah berikut: 
      
kubectl -n kube-system get daemonset \
    gke-metrics-agent -o yaml | grep "cpu: 50m"
      Perintah ini akan menemukan cpu: 50m jika hasil edit Anda telah diterapkan.
    Networking 1.10

    Beberapa gateway default merusak konektivitas ke endpoint eksternal

    Memiliki beberapa gateway default di sebuah node dapat menyebabkan kerusakan konektivitas dari dalam Pod ke endpoint eksternal, seperti google.com.

    Untuk menentukan apakah Anda terpengaruh oleh masalah ini, jalankan perintah berikut pada node:

    
ip route show

    Beberapa instance default dalam respons menunjukkan bahwa Anda terpengaruh.
    Networking 1.12

    Pengeditan resource kustom jaringan pada cluster pengguna akan ditimpa

    GKE versi 1.12.x di cluster Bare Metal tidak mencegah Anda mengedit resource kustom jaringan secara manual di cluster pengguna. GKE on Bare Metal merekonsiliasi resource kustom di cluster pengguna dengan resource kustom di cluster admin Anda selama upgrade cluster. Rekonsiliasi ini akan menimpa semua pengeditan yang dilakukan secara langsung pada resource kustom jaringan di cluster pengguna. Resource kustom jaringan sebaiknya diubah hanya di cluster admin, tetapi cluster versi 1.12.x tidak menerapkan persyaratan ini.

    Fitur jaringan lanjutan, seperti load balancing paket dengan BGP, gateway NAT keluar, jaringan SR-IOV, mode datar dengan BGP, dan multi-NIC untuk Pod menggunakan resource kustom berikut:

    • BGPLoadBalancer
    • BGPPeer
    • NetworkGatewayGroup
    • NetworkAttachmentDefinition
    • ClusterCIDRConfig
    • FlatIPMode

    Anda dapat mengedit resource kustom ini di cluster admin dan langkah rekonsiliasi akan menerapkan perubahan pada cluster pengguna Anda.


    Solusi

    Jika Anda telah mengubah salah satu resource kustom yang disebutkan sebelumnya di cluster pengguna, ubah resource kustom yang terkait di cluster admin agar sesuai sebelum melakukan upgrade. Langkah ini memastikan bahwa perubahan konfigurasi Anda dipertahankan. GKE pada cluster Bare Metal versi 1.13.0 dan yang lebih tinggi mencegah Anda mengubah resource kustom jaringan pada cluster pengguna secara langsung.
    Networking 1,10, 1,11, 1,12, 1,13, 1,14, 1,15, 1,16, 1,28

    Kegagalan konektivitas pod dan pemfilteran jalur terbalik

    GKE di Bare Metal 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 dalam folder konfigurasi IPv4 (net/ipv4/conf/all). Nilai ini juga dapat diganti oleh sysctl, yang menyimpan setelan pemfilteran jalur balik dalam file konfigurasi keamanan jaringan, seperti /etc/sysctl.d/60-gce-network-security.conf.


    Solusi

    Konektivitas pod dapat dipulihkan dengan melakukan salah satu solusi berikut:

    Tetapkan nilai untuk net.ipv4.conf.all.rp_filter kembali ke 0 secara manual, lalu jalankan sudo sysctl -p untuk menerapkan perubahan.

    Atau

    Mulai ulang Pod anetd untuk menetapkan net.ipv4.conf.all.rp_filter kembali ke 0. Untuk memulai ulang Pod anetd, gunakan perintah berikut untuk menemukan dan menghapus Pod anetd, dan Pod anetd baru akan dimulai sebagai penggantinya:

    
kubectl get pods -n kube-system kubectl delete pods -n kube-system ANETD_XYZ

    Ganti ANETD_XYZ dengan nama Pod anetd.

    Setelah melakukan salah satu solusi, verifikasi bahwa nilai net.ipv4.conf.all.rp_filter ditetapkan ke 0 dengan menjalankan sysctl net.ipv4.conf.all.rp_filter pada setiap node.
    Networking 1,10, 1,11, 1,12, 1,13, 1,14, 1,15, 1,16, 1,28

    Alamat IP cluster (jenis) bootstrap dan alamat IP node cluster tumpang tindih

    192.168.122.0/24 dan 10.96.0.0/27 adalah pod dan CIDR layanan default yang digunakan oleh cluster (jenis) bootstrap. Pemeriksaan preflight akan gagal jika tumpang-tindih dengan alamat IP mesin node cluster.


    Solusi

    Untuk menghindari konflik, Anda dapat meneruskan flag --bootstrap-cluster-pod-cidr dan --bootstrap-cluster-service-cidr ke bmctl untuk menentukan nilai yang berbeda.
    Sistem operasi 1,10, 1,11, 1,12, 1,13, 1,14, 1,15, 1,16, 1,28

    Pembuatan atau upgrade cluster gagal di CentOS

    Pada Desember 2020, komunitas CentOS dan Red Hat mengumumkan penghentian CentOS. Pada 31 Januari 2022, CentOS 8 mencapai akhir siklus prosesnya (EOL). Akibat EOL, repositori yum berhenti berfungsi untuk CentOS, yang menyebabkan pembuatan cluster dan operasi upgrade cluster gagal. Hal ini berlaku untuk semua versi CentOS yang didukung dan memengaruhi semua versi GKE di cluster Bare Metal.


    Solusi
    Keamanan 1,10, 1,11, 1,12, 1,13, 1,14, 1,15, 1,16, 1,28

    Container tidak dapat menulis ke VOLUME yang ditentukan di Dockerfile dengan container dan SELinux

    Jika Anda menggunakan containerd sebagai runtime container dan sistem operasi Anda telah mengaktifkan SELinux, VOLUME yang ditetapkan dalam Dockerfile aplikasi mungkin tidak dapat ditulis. Misalnya, container yang dibangun dengan Dockerfile berikut tidak dapat menulis ke folder /tmp.

    
FROM ubuntu:20.04 RUN chmod -R 777 /tmp VOLUME /tmp

    Untuk memverifikasi apakah Anda terpengaruh oleh masalah ini, jalankan perintah berikut pada node yang menghosting container yang bermasalah:

    
ausearch -m avc

    Jika terpengaruh oleh masalah ini, Anda akan melihat error denied seperti berikut:

    
time->Mon Apr  4 21:01:32 2022 type=PROCTITLE msg=audit(1649106092.768:10979): proctitle="bash" type=SYSCALL msg=audit(1649106092.768:10979): arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=55eeba72b320 a2=241 a3=1b6 items=0 ppid=75712 pid=76042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=4294967295 comm="bash" exe="/usr/bin/bash" subj=system_u:system_r:container_t:s0:c701,c935 key=(null) type=AVC msg=audit(1649106092.768:10979): avc:  denied { write } for  pid=76042 comm="bash" name="aca03d7bb8de23c725a86cb9f50945664cb338dfe6ac19ed0036c" dev="sda2" ino=369501097 scontext=system_u:system_r: container_t:s0:c701,c935 tcontext=system_u:object_r: container_ro_file_t:s0 tclass=dir permissive=0

    Solusi

    Untuk mengatasi masalah ini, lakukan salah satu perubahan berikut:

    • Nonaktifkan SELinux.
    • Jangan gunakan fitur VOLUME di dalam Dockerfile.
    Upgrade dan update 1,10, 1,11, 1,12

    Node Problem Detector tidak diaktifkan secara default setelah upgrade cluster

    Saat Anda mengupgrade GKE pada cluster Bare Metal, 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 Detektor Masalah Node:

    1. Verifikasi apakah layanan node-problem-detector systemd berjalan pada node.
      1. Gunakan perintah SSH dan hubungkan ke node.
      2. Periksa apakah layanan node-problem-detector systemd berjalan pada node: 
        
systemctl is-active node-problem-detector
        Jika hasil perintah menampilkan inactive, berarti pendeteksi masalah node tidak berjalan pada node.
    2. Untuk mengaktifkan Node Problem Detector, gunakan perintah kubectl edit dan edit node-problem-detector-config ConfigMap. Untuk mengetahui informasi selengkapnya, lihat Pendeteksi Masalah Node.
    Operasi 1,9, 1,10

    Pencadangan cluster gagal saat menggunakan login non-root

    Perintah bmctl backup cluster akan gagal jika nodeAccess.loginUser ditetapkan ke nama pengguna non-root.]


    Solusi:

    Masalah ini berlaku untuk versi 1.9.x, 1.10.0, dan 1.10.1 serta telah diperbaiki dalam versi 1.10.2 dan yang lebih baru.
    Networking 1,10, 1,11, 1,12

    Layanan Load Balancer tidak berfungsi dengan container di jaringan host bidang kontrol

    Terdapat bug di anetd saat paket dihapus untuk LoadBalancer Services jika pod backend berjalan di node bidang kontrol dan menggunakan kolom hostNetwork: true di spesifikasi container.

    Bug tidak ada di versi 1.13 atau yang lebih baru.


    Solusi:

    Solusi berikut dapat membantu jika Anda menggunakan Layanan LoadBalancer yang didukung oleh Pod hostNetwork:

    1. Jalankan keduanya di node pekerja (bukan node bidang kontrol).
    2. Gunakan externalTrafficPolicy: local di spesifikasi Service dan pastikan workload Anda berjalan di node load balancer.
    Upgrade dan Update 1,12, 1,13

    Pod anthos-version-$version$ usang dan gagal mengambil gambar

    Upgrade cluster dari 1.12.x ke 1.13.x mungkin melihat adanya pod anthos-version-$version$ yang gagal dengan error ImagePullBackOff. Hal ini terjadi karena kondisi race anthos-cluster-operator yang diupgrade dan tidak akan memengaruhi kemampuan cluster reguler.

    Bug tidak ada setelah versi 1.13 atau yang lebih baru.


    Solusi:

    Hapus Tugas dynamic-version-installer dari 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 mengetahui apakah Anda terpengaruh, periksa log tugas upgrade yang berisi string upgrade-first-no* di cluster admin. Jika Anda melihat pesan error berikut, berarti Anda terkena dampaknya.

    
TASK [kubeadm_upgrade_apply : Run kubeadm upgrade apply] *******
...
[upgrade/config] FATAL: featureGates: Invalid value: map[string]bool{\"IPv6DualStack\":false}: IPv6DualStack isn't a valid feature name.
...

    Solusi:

    Untuk mengatasi masalah ini:

    1. Jalankan perintah berikut di workstation admin Anda: 
      
echo '[{ "op": "remove", "path": \
    "/spec/clusterConfiguration/featureGates" }]' \
    > remove-feature-gates.patch
export KUBECONFIG=$ADMIN_KUBECONFIG
kubectl get kubeadmconfig -A --no-headers | xargs -L1 bash -c \
    'kubectl patch kubeadmconfig $1 -n $0 --type json \
    --patch-file remove-feature-gates.patch'
    2. Coba upgrade cluster lagi.
    Logging dan Pemantauan 1.16.2, 1.16.3

    Penggunaan CPU yang tinggi untuk stackdriver-operator

    Ada masalah dalam stackdriver-operator yang menyebabkannya menggunakan waktu CPU yang lebih tinggi dari biasanya. Penggunaan CPU normal kurang dari 50 miliCPU (50m) untuk stackdriver-operator dalam status tidak ada aktivitas. Penyebabnya adalah ketidakcocokan resource Sertifikat yang diterapkan stackdriver-operator dengan ekspektasi dari cert-manager. Ketidakcocokan ini menyebabkan kondisi race antara cert-manager dan stackdriver-operator dalam memperbarui resource tersebut.

    Masalah ini dapat mengakibatkan penurunan performa pada cluster dengan ketersediaan CPU yang terbatas.


    Solusi:

    Gunakan solusi berikut hingga Anda dapat melakukan upgrade ke versi yang memperbaiki bug ini:

    1. Untuk menurunkan skala stackdriver-operator menjadi 0 replika untuk sementara, terapkan resource kustom AddonConfiguration: 
      
kubectl scale deploy stackdriver-operator --replicas=0
    2. Setelah Anda melakukan upgrade ke versi yang memperbaiki masalah ini, skalakan stackdriver-operator kembali: 
      
kubectl scale deploy stackdriver-operator --replicas=1
    Logging dan Pemantauan 1.16.0, 1.16.1

    Salinan metrik berbasis anotasi tidak berfungsi

    Dalam rilis minor GDCV untuk Bare Metal 1.16, kolom enableStackdriverForApplications dalam spesifikasi resource kustom stackdriver tidak digunakan lagi. Kolom ini diganti dengan dua kolom, enableCloudLoggingForApplications dan enableGMPForApplications, di resource kustom stackdriver.

    Sebaiknya gunakan Google Cloud Managed Service for Prometheus untuk memantau workload Anda. Gunakan kolom enableGMPForApplications untuk mengaktifkan fitur ini.

    Jika mengandalkan pengumpulan metrik yang dipicu oleh anotasi prometheus.io/scrape pada workload, Anda dapat menggunakan flag gate fitur annotationBasedApplicationMetrics untuk mempertahankan perilaku lama. Namun, ada masalah yang membuat annotationBasedApplicationMetrics tidak berfungsi dengan baik, sehingga mencegah pengumpulan metrik dari aplikasi Anda ke Cloud Monitoring.


    Solusi:

    Untuk mengatasi masalah ini, upgrade cluster ke versi 1.16.2 atau yang lebih baru.

    Pengumpulan metrik workload berbasis anotasi yang diaktifkan oleh gate fitur annotationBasedApplicationMetrics mengumpulkan metrik untuk objek yang memiliki anotasi prometheus.io/scrape. Banyak sistem software dengan origin open source dapat menggunakan anotasi ini. Jika Anda terus menggunakan metode pengumpulan metrik ini, pahami dependensi ini agar Anda tidak terkejut dengan biaya metrik di Cloud Monitoring.
    Jika Anda memerlukan bantuan lainnya, hubungi Cloud Customer Care.