Penginstalan, Upgrade, dan update |
1.28.0-1.28.600,1.29.0-1.29.100 |
Webook Otorisasi Biner memblokir plugin CNI agar mulai menyebabkan salah satu nodepool gagal muncul
Dalam kondisi race yang jarang terjadi, urutan penginstalan webhook Otorisasi Biner dan pod gke-connect yang salah dapat menyebabkan pembuatan cluster pengguna terhenti karena node gagal mencapai status siap. Dalam skenario yang terpengaruh, pembuatan cluster pengguna dapat terhenti karena node gagal mencapai status siap. Jika ini terjadi, pesan berikut akan ditampilkan:
Node pool is not ready: ready condition is not true: CreateOrUpdateNodePool: 2/3 replicas are ready
Solusi:
- Hapus konfigurasi Otorisasi Biner dari file konfigurasi Anda. Untuk petunjuk penyiapan, lihat panduan penginstalan Otorisasi Biner hari ke-2 untuk GKE di VMware.
- Untuk berhenti memblokir node yang tidak responsif selama proses pembuatan cluster saat ini, hapus konfigurasi webhook Otorisasi Biner di cluster pengguna untuk sementara menggunakan perintah berikut.
kubectl --kubeconfig USER_KUBECONFIG delete ValidatingWebhookConfiguration binauthz-validating-webhook-configuration
Setelah proses bootstrap selesai, Anda dapat menambahkan kembali konfigurasi webhook berikut.
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
name: binauthz-validating-webhook-configuration
webhooks:
- name: "binaryauthorization.googleapis.com"
namespaceSelector:
matchExpressions:
- key: control-plane
operator: DoesNotExist
objectSelector:
matchExpressions:
- key: "image-policy.k8s.io/break-glass"
operator: NotIn
values: ["true"]
rules:
- apiGroups:
- ""
apiVersions:
- v1
operations:
- CREATE
- UPDATE
resources:
- pods
- pods/ephemeralcontainers
admissionReviewVersions:
- "v1beta1"
clientConfig:
service:
name: binauthz
namespace: binauthz-system
path: /binauthz
# CA Bundle will be updated by the cert rotator.
caBundle: Cg==
timeoutSeconds: 10
# Fail Open
failurePolicy: "Ignore"
sideEffects: None
|
Upgrade |
1,16, 1,28, 1,29 |
Upgrade cluster pengguna CPV2 terhenti karena mesin yang dicerminkan dengan deletionTimestamp
Selama upgrade cluster pengguna, operasi upgrade mungkin terhenti jika objek mesin yang dicerminkan di cluster pengguna berisi deletionTimestamp . Pesan error berikut akan ditampilkan jika upgrade terhenti:
machine is still in the process of being drained and subsequently removed
Masalah ini dapat terjadi jika sebelumnya Anda mencoba memperbaiki node bidang kontrol pengguna dengan menjalankan gkectl delete machine pada mesin yang dicerminkan di cluster pengguna.
Solusi:
- Dapatkan objek mesin yang dicerminkan dan simpan ke file lokal untuk tujuan pencadangan.
- Jalankan perintah berikut untuk menghapus finaler dari mesin yang dicerminkan dan tunggu hingga dihapus dari cluster pengguna.
kubectl --kubeconfig ADMIN_KUBECONFIG patch machine/MACHINE_OBJECT_NAME -n USER_CLUSTER_NAME-gke-onprem-mgmt -p '{"metadata":{"finalizers":[]}}' --type=merge
- Ikuti langkah-langkah di
node bidang kontrol cluster pengguna Controlplane V2 untuk memicu perbaikan node
pada node bidang kontrol, sehingga spesifikasi mesin sumber yang benar akan
disinkronkan ulang ke cluster pengguna.
- Jalankan kembali
gkectl upgrade cluster untuk melanjutkan upgrade
|
Konfigurasi, Penginstalan |
1,15, 1,16, 1,28, 1,29 |
Kegagalan pembuatan cluster karena VIP bidang kontrol di subnet yang berbeda
Untuk cluster admin HA atau cluster pengguna ControlPlane V2, VIP bidang kontrol harus berada di subnet yang sama dengan node cluster lainnya. Jika tidak, pembuatan cluster akan gagal karena kubelet tidak dapat berkomunikasi dengan server API menggunakan VIP bidang kontrol.
Solusi:
Sebelum pembuatan cluster, pastikan VIP bidang kontrol dikonfigurasi dalam subnet yang sama dengan node cluster lainnya.
|
Penginstalan, Upgrade, Update |
1.29.0 - 1.29.100 |
Kegagalan Pembuatan/Upgrade Cluster karena Nama Pengguna vCenter non-FQDN
Pembuatan/upgrade cluster gagal disertai error dalam pod CSI vsphere yang menunjukkan bahwa nama pengguna vCenter tidak valid. Hal ini terjadi karena nama pengguna yang digunakan bukan nama domain yang sepenuhnya memenuhi syarat. Pesan error pada pod vsphere-csi-controller seperti di bawah ini:
GetCnsconfig failed with err: username is invalid, make sure it is a fully qualified domain username
Masalah ini hanya terjadi di versi 1.29 dan yang lebih baru, karena validasi ditambahkan ke driver CSI vSphere untuk menerapkan penggunaan nama pengguna domain yang sepenuhnya memenuhi syarat.
Solusi:
Gunakan nama domain yang sepenuhnya memenuhi syarat untuk nama pengguna vCenter di file konfigurasi kredensial. Misalnya, gunakan "namapengguna1@example.com", bukan "namapengguna1".
|
Upgrade, Update |
1.28.0 - 1.28.500 |
Upgrade cluster admin gagal untuk cluster yang dibuat pada versi 1.10 atau yang lebih lama
Saat mengupgrade cluster admin dari 1.16 ke 1.28, bootstrap mesin master admin baru mungkin gagal membuat sertifikat bidang kontrol. Masalah ini disebabkan oleh perubahan cara pembuatan sertifikat untuk server Kubernetes API pada versi 1.28 dan yang lebih baru. Masalah ini
direproduksi untuk cluster yang dibuat pada versi 1.10 dan sebelumnya yang
telah diupgrade hingga 1.16, dan sertifikat leaf tidak
dirotasi sebelum upgrade.
Untuk mengetahui apakah kegagalan upgrade cluster admin disebabkan oleh masalah ini, lakukan langkah-langkah berikut:
- Hubungkan ke mesin master admin yang gagal menggunakan SSH.
- Buka
/var/log/startup.log dan telusuri error seperti berikut:
Error adding extensions from section apiserver_ext
801B3213B57F0000:error:1100007B:X509 V3 routines:v2i_AUTHORITY_KEYID:unable to get issuer keyid:../crypto/x509/v3_akid.c:177:
801B3213B57F0000:error:11000080:X509 V3 routines:X509V3_EXT_nconf_int:error in extension:../crypto/x509/v3_conf.c:48:section=apiserver_ext, name=authorityKeyIdentifier, value=keyid>
Solusi:
- Hubungkan ke mesin master admin menggunakan SSH. Untuk mengetahui detailnya, lihat
Menggunakan SSH untuk terhubung ke
node cluster admin.
- Edit
/etc/startup/pki-yaml.sh . Temukan authorityKeyIdentifier=keyidset dan ubah menjadi authorityKeyIdentifier=keyid,issuer di bagian untuk ekstensi berikut: apiserver_ext , client_ext , etcd_server_ext , dan kubelet_server_ext . Contoh:
[ apiserver_ext ]
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage=serverAuth
basicConstraints = critical,CA:false
authorityKeyIdentifier = keyid,issuer
subjectAltName = @apiserver_alt_names
- Simpan perubahan ke
/etc/startup/pki-yaml.sh .
- Jalankan
/opt/bin/master.sh untuk membuat sertifikat dan
menyelesaikan startup mesin.
- Jalankan kembali
gkectl upgrade admin untuk mengupgrade cluster
admin.
- Setelah upgrade selesai, putar leaf certificate untuk cluster pengguna dan admin, seperti yang dijelaskan dalam Memulai rotasi.
- Setelah rotasi sertifikat selesai, lakukan pengeditan yang sama pada
/etc/startup/pki-yaml.sh seperti yang Anda lakukan sebelumnya, lalu jalankan /opt/bin/master.sh .
|
Configuration |
1.29.0 |
Pesan peringatan yang salah untuk cluster dengan Dataplane V2 diaktifkan
Pesan peringatan yang salah berikut ditampilkan saat Anda menjalankan gkectl untuk membuat, mengupdate, atau mengupgrade cluster yang sudah mengaktifkan Dataplane V2:
WARNING: Your user cluster is currently running our original architecture with
[DataPlaneV1(calico)]. To enable new and advanced features we strongly recommend
to update it to the newer architecture with [DataPlaneV2] once our migration
tool is available.
Ada bug di gkectl yang menyebabkannya selalu menampilkan peringatan ini
selama dataplaneV2.forwardMode tidak digunakan meskipun
Anda telah menetapkan enableDataplaneV2: true dalam file konfigurasi
cluster.
Solusi:
Anda dapat mengabaikan peringatan ini dengan aman.
|
Configuration |
1.28.0-1.28.400, 1.29.0 |
Pemeriksaan preflight penginstalan cluster admin HA melaporkan jumlah IP statis yang salah
Saat Anda membuat cluster admin HA, pemeriksaan preflight akan menampilkan
pesan error yang salah berikut:
- Validation Category: Network Configuration
- [FAILURE] CIDR, VIP and static IP (availability and overlapping): needed
at least X+1 IP addresses for admin cluster with X nodes
Persyaratan untuk cluster admin dengan ketersediaan tinggi (HA) 1,28 dan yang lebih tinggi salah
karena tidak lagi memiliki node add-on. Selain itu, karena 3
IP node bidang kontrol cluster admin ditentukan di
bagian network.controlPlaneIPBlock pada file konfigurasi cluster
admin, IP dalam file blok IP hanya diperlukan untuk
node bidang kontrol cluster pengguna kubeception.
Solusi:
Untuk melewati pemeriksaan preflight yang salah dalam rilis yang tidak tetap, tambahkan --skip-validation-net-config ke perintah gkectl .
|
Operasi |
1.29.0-1.29.100 |
Connect Agent kehilangan koneksi ke Google Cloud setelah migrasi cluster admin non-HA ke HA
Jika Anda memigrasikan
dari cluster admin non-HA ke cluster admin HA, Connect Agent
di cluster admin akan kehilangan koneksi ke
gkeconnect.googleapis.com dan menampilkan error "Failed to verification JWT
signature". Hal ini karena selama migrasi, kunci penandatanganan KSA diubah, sehingga pendaftaran ulang diperlukan untuk memperbarui JWK OIDC.
Solusi:
Untuk menghubungkan kembali cluster admin ke Google Cloud, lakukan langkah-langkah berikut untuk memicu pendaftaran ulang:
Pertama-tama, dapatkan nama deployment gke-connect :
kubectl --kubeconfig KUBECONFIG get deployment -n gke-connect
Hapus deployment gke-connect :
kubectl --kubeconfig KUBECONFIG delete deployment GKE_CONNECT_DEPLOYMENT -n gke-connect
Picu rekonsiliasi paksa untuk onprem-admin-cluster-controller
dengan menambahkan anotasi "rekonsiliasi paksa" ke CR onpremadmincluster Anda:
kubectl --kubeconfig KUBECONFIG patch onpremadmincluster ADMIN_CLUSTER_NAME -n kube-system --type merge -p '
metadata:
annotations:
onprem.cluster.gke.io/force-reconcile: "true"
'
Idenya adalah onprem-admin-cluster-controller akan selalu men-deploy ulang deployment gke-connect dan mendaftarkan ulang cluster jika tidak menemukan deployment gke-connect yang tersedia.
Setelah solusinya (mungkin diperlukan waktu beberapa menit agar pengontrol
menyelesaikan rekonsiliasi), Anda dapat memverifikasi bahwa error 400 "Gagal
memverifikasi tanda tangan JWT" sudah hilang dari log gke-connect-agent :
kubectl --kubeconfig KUBECONFIG logs GKE_CONNECT_POD_NAME -n gke-connect
|
Penginstalan, Sistem operasi |
1.28.0-1.28.500, 1.29.0 |
IP jembatan Docker menggunakan 172.17.0.1/16 untuk node bidang kontrol cluster COS
Google Distributed Cloud menentukan subnet khusus,
--bip=169.254.123.1/24 , untuk IP jembatan Docker dalam
konfigurasi Docker guna mencegah reservasi subnet
172.17.0.1/16 default. Namun, pada versi 1.28.0-1.28.500 dan 1.29.0, layanan Docker tidak dimulai ulang setelah Google Distributed Cloud menyesuaikan konfigurasi Docker karena adanya regresi pada image COS OS. Hasilnya, Docker memilih 172.17.0.1/16 default sebagai subnet alamat IP jembatannya. Hal ini dapat menyebabkan konflik alamat IP jika Anda sudah memiliki workload yang berjalan dalam rentang alamat IP tersebut.
Solusi:
Untuk mengatasi masalah ini, Anda harus memulai ulang layanan Docker:
sudo systemctl restart docker
Verifikasi bahwa Docker memilih alamat IP jembatan yang benar:
ip a | grep docker0
Solusi ini tidak dapat dipertahankan di seluruh pembuatan ulang VM. Anda harus menerapkan kembali solusi ini setiap kali VM dibuat ulang.
|
update |
1.28.0-1.28.400, 1.29.0-1.29.100 |
Penggunaan beberapa antarmuka jaringan dengan CNI standar tidak berfungsi
Biner CNI standar bridge, ipvlan, vlan, macvlan, dhcp, tuning,
host-local, ptp, portmap tidak disertakan dalam OS image pada versi yang terpengaruh. Biner CNI ini tidak digunakan oleh bidang data v2, tetapi dapat digunakan untuk antarmuka jaringan tambahan pada fitur beberapa antarmuka jaringan.
Beberapa antarmuka jaringan dengan plugin CNI ini tidak akan berfungsi.
Solusi:
Upgrade ke versi dengan perbaikan jika Anda menggunakan fitur ini.
|
update |
1,15, 1,16, 1,28 |
Dependensi trident Netapp mengganggu driver CSI vSphere
Menginstal multipathd pada node cluster mengganggu driver CSI vSphere sehingga beban kerja pengguna tidak dapat dimulai.
Solusi:
|
Update |
1,15, 1,16 |
Webhook cluster admin mungkin memblokir pembaruan saat Anda menambahkan konfigurasi yang diperlukan
Jika beberapa konfigurasi yang diperlukan kosong di cluster admin
karena validasi dilewati, penambahannya dapat diblokir oleh webhook
cluster admin. Misalnya, jika kolom gkeConnect tidak
ditetapkan di cluster admin yang sudah ada, menambahkannya dengan
perintah gkectl update admin mungkin akan mendapatkan pesan
error berikut:
admission webhook "vonpremadmincluster.onprem.cluster.gke.io" denied the request: connect: Required value: GKE connect is required for user clusters
Solusi:
-
Untuk 1.15 cluster admin, jalankan perintah
gkectl update admin dengan flag --disable-admin-cluster-webhook . Contoh:
gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig ADMIN_CLUSTER_KUBECONFIG --disable-admin-cluster-webhook
-
Untuk 1.16 cluster admin, jalankan perintah
gkectl update admin dengan flag --force . Contoh:
gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig ADMIN_CLUSTER_KUBECONFIG --force
|
Configuration |
1.15.0-1.15.10, 1.16.0-1.16.6, 1.28.0-1.28.200 |
Kolom controlPlaneNodePort ditetapkan secara default ke 30968 saat spesifikasi manualLB kosong
Jika akan menggunakan load balancer manual (loadBalancer.kind ditetapkan ke "ManualLB" ), Anda tidak perlu mengonfigurasi bagian loadBalancer.manualLB dalam file konfigurasi untuk cluster admin ketersediaan tinggi (HA) pada versi 1.16 dan yang lebih baru. Namun, jika bagian ini kosong, Google Distributed Cloud akan menetapkan nilai default ke semua NodePorts termasuk manualLB.controlPlaneNodePort , yang menyebabkan pembuatan cluster gagal dengan pesan error berikut:
- Validation Category: Manual LB
- [FAILURE] NodePort configuration: manualLB.controlPlaneNodePort must
not be set when using HA admin cluster, got: 30968
Solusi:
Tentukan manualLB.controlPlaneNodePort: 0 di konfigurasi cluster admin Anda
untuk cluster admin HA:
loadBalancer:
...
kind: ManualLB
manualLB:
controlPlaneNodePort: 0
...
|
Penyimpanan |
1.28.0-1.28.100 |
nfs-common tidak ada di image OS Ubuntu
nfs-common tidak ada di OS image Ubuntu yang dapat menyebabkan masalah bagi pelanggan yang menggunakan driver yang bergantung pada NFS seperti NetApp.
Jika log berisi entri seperti berikut setelah mengupgrade ke 1.28, Anda akan terpengaruh oleh masalah ini:
Warning FailedMount 63s (x8 over 2m28s) kubelet MountVolume.SetUp failed for volume "pvc-xxx-yyy-zzz" : rpc error: code = Internal desc = error mounting NFS volume 10.0.0.2:/trident_pvc_xxx-yyy-zzz on mountpoint /var/lib/kubelet/pods/aaa-bbb-ccc/volumes/kubernetes.io~csi/pvc-xxx-yyy-zzz/mount: exit status 32".
Solusi:
Pastikan node Anda dapat mendownload paket dari Kanonis.
Selanjutnya, terapkan DaemonSet berikut ke cluster Anda untuk menginstal nfs-common :
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: install-nfs-common
labels:
name: install-nfs-common
namespace: kube-system
spec:
selector:
matchLabels:
name: install-nfs-common
minReadySeconds: 0
updateStrategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 100%
template:
metadata:
labels:
name: install-nfs-common
spec:
hostPID: true
hostIPC: true
hostNetwork: true
initContainers:
- name: install-nfs-common
image: ubuntu
imagePullPolicy: IfNotPresent
securityContext:
privileged: true
command:
- chroot
- /host
- bash
- -c
args:
- |
apt install -y nfs-common
volumeMounts:
- name: host
mountPath: /host
containers:
- name: pause
image: gcr.io/gke-on-prem-release/pause-amd64:3.1-gke.5
imagePullPolicy: IfNotPresent
volumes:
- name: host
hostPath:
path: /
|
Penyimpanan |
1.28.0-1.28.100 |
Kolom kebijakan penyimpanan tidak ada di template konfigurasi cluster admin
SPBM di cluster admin didukung pada versi 1.28.0 dan yang lebih baru. Namun, kolom vCenter.storagePolicyName tidak ada di template file konfigurasi.
Solusi:
Tambahkan kolom `vCenter.storagePolicyName` di file konfigurasi cluster admin jika Anda ingin mengonfigurasi kebijakan penyimpanan untuk cluster admin. Lihat instructions.
|
Logging dan pemantauan |
1.28.0-1.28.100 |
API kubernetesmetadata.googleapis.com yang baru-baru ini ditambahkan tidak mendukung VPC-SC. Hal ini akan menyebabkan agen pengumpulan metadata gagal menjangkau API ini pada VPC-SC. Selanjutnya, label metadata metrik akan hilang.
Solusi:
Di namespace `kube-system`, tetapkan kolom `featureGates.disableExperimentalMetadataAgent` di namespace CR `stackdriver` ke `true` dengan menjalankan perintah
`kubectl -n kube-system patch stackdriver stackdriver -p '{"spec":{"featureGates":{"disableExperimentalMetadataAgent":true}}}'`
lalu jalankan
`kubectl -n kube-system patch deployment stackdriver-operator -p '{"spec":{"template":{"spec":{"containers":[{"name":"stackdriver-operator","env":[{"name":"ENABLE_LEGACY_METADATA_AGENT","value":"true"}]}]}}}}'`
|
Upgrade, Update |
1.15.0-1.15.7, 1.16.0-1.16.4, 1.28.0 |
Pengontrol clusterapi dapat mengalami error jika cluster admin dan cluster pengguna apa pun yang mengaktifkan ControlPlane V2 menggunakan kredensial vSphere yang berbeda
Jika cluster admin dan cluster pengguna apa pun yang mengaktifkan ControlPlane V2 menggunakan kredensial vSphere yang berbeda, misalnya setelah memperbarui kredensial vSphere untuk cluster admin, clusterapi-controller mungkin gagal terhubung ke vCenter setelah dimulai ulang. Lihat log clusterapi-controller yang berjalan di namespace `kube-system` cluster admin,
kubectl logs -f -l component=clusterapi-controllers -c vsphere-controller-manager \
-n kube-system --kubeconfig KUBECONFIG
Jika log berisi entri seperti berikut, berarti Anda terpengaruh oleh masalah ini:
E1214 00:02:54.095668 1 machine_controller.go:165] Error checking existence of machine instance for machine object gke-admin-node-77f48c4f7f-s8wj2: Failed to check if machine gke-admin-node-77f48c4f7f-s8wj2 exists: failed to find datacenter "VSPHERE_DATACENTER": datacenter 'VSPHERE_DATACENTER' not found
Solusi:
Perbarui kredensial vSphere sehingga cluster admin dan semua cluster pengguna yang mengaktifkan Controlplane V2 menggunakan kredensial vSphere yang sama.
|
Logging dan pemantauan |
1,14 |
dll. tingginya jumlah permintaan GRPC yang gagal di Prometheus Alert Manager
Prometheus mungkin melaporkan peringatan yang mirip dengan contoh berikut:
Alert Name: cluster:gke-admin-test1: Etcd cluster kube-system/kube-etcd: 100% of requests for Watch failed on etcd instance etcd-test-xx-n001.
Untuk memeriksa apakah pemberitahuan ini merupakan positif palsu (PP) yang dapat diabaikan, selesaikan langkah-langkah berikut:
- Periksa metrik
grpc_server_handled_total mentah terhadap grpc_method yang diberikan dalam pesan pemberitahuan. Dalam contoh ini, periksa label grpc_code untuk Watch .
Anda dapat memeriksa metrik ini menggunakan Cloud Monitoring dengan kueri MQL berikut:
fetch
k8s_container | metric 'kubernetes.io/anthos/grpc_server_handled_total' | align rate(1m) | every 1m
- Pemberitahuan pada semua kode selain
OK dapat diabaikan
dengan aman jika kode bukan salah satu dari yang berikut:
Unknown|FailedPrecondition|ResourceExhausted|Internal|Unavailable|DataLoss|DeadlineExceeded
Solusi:
Untuk mengonfigurasi Prometheus agar mengabaikan pemberitahuan positif palsu ini, tinjau opsi berikut:
- Senyapkan pemberitahuan dari UI Alert Manager.
- Jika tidak dapat membisukan notifikasi, tinjau langkah-langkah berikut untuk menyembunyikan positif palsu (PP):
- Turunkan skala operator pemantauan menjadi replika
0 sehingga modifikasi dapat dipertahankan.
- Ubah konfigurasi peta
prometheus-config , dan tambahkan grpc_method!="Watch" ke konfigurasi pemberitahuan etcdHighNumberOfFailedGRPCRequests seperti yang ditunjukkan dalam contoh berikut:
- Asli:
rate(grpc_server_handled_total{cluster="CLUSTER_NAME",grpc_code!="OK",job=~".*etcd.*"}[5m])
- Diubah:
rate(grpc_server_handled_total{cluster="CLUSTER_NAME",grpc_code=~"Unknown|FailedPrecondition|ResourceExhausted|Internal|Unavailable|DataLoss|DeadlineExceeded",grpc_method!="Watch",job=~".*etcd.*"}[5m])
Ganti CLUSTER_NAME berikut dengan
nama cluster Anda.
- Mulai ulang Prometheus dan Alertmanager Statefulset untuk mengambil konfigurasi baru.
- Jika kode termasuk dalam salah satu kasus yang bermasalah, periksa log etcd dan log
kube-apiserver untuk melakukan debug lebih lanjut.
|
Networking |
1.16.0-1.16.2, 1.28.0 |
Koneksi yang aktif dalam waktu lama NAT keluar akan terputus
Koneksi NAT keluar dapat terputus setelah 5 hingga 10 menit koneksi dibuat jika tidak ada traffic.
Karena conntrack hanya penting dalam arah masuk (koneksi eksternal ke cluster), masalah ini hanya terjadi jika koneksi tidak mengirimkan informasi apa pun untuk sementara waktu, lalu sisi tujuan mengirimkan sesuatu. Jika Pod keluar dengan NAT selalu membuat instance pesan, masalah ini tidak akan terlihat.
Masalah ini terjadi karena pembersihan sampah memori anetd secara tidak sengaja menghapus entri conntrack yang menurut daemon tidak digunakan.
Perbaikan upstream baru-baru ini diintegrasikan ke anetd untuk memperbaiki perilaku.
Solusi:
Tidak ada solusi yang mudah, dan kami belum melihat masalah dalam versi 1.16
dari perilaku ini. Jika Anda melihat koneksi jangka panjang terputus karena masalah ini, solusinya adalah menggunakan workload pada node yang sama dengan alamat IP keluar, atau mengirim pesan secara konsisten di koneksi TCP.
|
Operasi |
1,14, 1,15, 1,16 |
Penanda tangan CSR mengabaikan spec.expirationSeconds saat menandatangani
sertifikat
Jika Anda membuat CertificatePenandatangananRequest (CSR) dengan
expirationSeconds disetel, expirationSeconds
akan diabaikan.
Solusi:
Jika terpengaruh oleh masalah ini, Anda dapat memperbarui cluster pengguna dengan
menambahkan disableNodeIDVerificationCSRSigning: true di file
konfigurasi cluster pengguna dan menjalankan perintah gkectl update cluster
untuk memperbarui cluster dengan konfigurasi ini.
|
Jaringan, Peningkatan Versi, Pembaruan |
1.16.0-1.16.3 |
Validasi load balancer cluster pengguna gagal untuk
disable_bundled_ingress
Jika Anda mencoba menonaktifkan traffic masuk yang dipaketkan untuk cluster yang ada, perintah gkectl update cluster akan gagal dengan error yang mirip dengan contoh berikut:
[FAILURE] Config: ingress IP is required in user cluster spec
Error ini terjadi karena gkectl memeriksa alamat IP masuk load balancer selama pemeriksaan preflight. Meskipun pemeriksaan ini
tidak diperlukan saat menonaktifkan traffic masuk yang dipaketkan, pemeriksaan preflight gkectl
akan gagal saat disableBundledIngress ditetapkan ke
true .
Solusi:
Gunakan parameter --skip-validation-load-balancer saat Anda mengupdate cluster, seperti yang ditunjukkan pada contoh berikut:
gkectl update cluster \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG \
--skip-validation-load-balancer
Untuk mengetahui informasi selengkapnya, lihat cara menonaktifkan traffic masuk yang dipaketkan untuk cluster yang ada.
|
Upgrade, Update |
1.13, 1.14, 1.15.0-1.15.6 |
Update cluster admin gagal setelah rotasi CA
Jika Anda mengganti sertifikat certificate authority (CA) cluster admin,
upaya berikutnya untuk menjalankan perintah gkectl update admin akan gagal.
Error yang ditampilkan mirip dengan yang berikut ini:
failed to get last CARotationStage: configmaps "ca-rotation-stage" not found
Solusi:
Jika terpengaruh oleh masalah ini, Anda dapat memperbarui cluster admin menggunakan flag --disable-update-from-checkpoint dengan perintah gkectl update admin :
gkectl update admin --config ADMIN_CONFIG_file \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--disable-update-from-checkpoint
Saat Anda menggunakan flag --disable-update-from-checkpoint , perintah update tidak menggunakan file checkpoint sebagai sumber kebenaran selama
update cluster. File checkpoint masih diperbarui untuk digunakan di masa mendatang.
|
Penyimpanan |
1.15.0-1.15.6, 1.16.0-1.16.2 |
Pemeriksaan preflight Workload CSI gagal karena kegagalan startup Pod
Selama pemeriksaan preflight, pemeriksaan validasi Beban Kerja CSI akan menginstal Pod di namespace default . CSI Workload Pod memvalidasi bahwa Driver CSI vSphere telah diinstal dan dapat melakukan penyediaan volume dinamis. Jika Pod ini tidak dimulai, pemeriksaan validasi Workload CSI akan gagal.
Ada beberapa masalah umum yang dapat mencegah Pod ini dimulai:
- Jika Pod tidak memiliki batas resource yang ditentukan, seperti yang terjadi pada beberapa cluster yang menginstal webhook penerimaan, Pod tidak akan dimulai.
- Jika Cloud Service Mesh diinstal di cluster dengan injeksi file bantuan Istio otomatis di namespace
default , Pod Workload CSI tidak akan dimulai.
Jika Pod Workload CSI tidak dimulai, Anda akan melihat error waktu tunggu seperti berikut selama validasi preflight:
- [FAILURE] CSI Workload: failure in CSIWorkload validation: failed to create writer Job to verify the write functionality using CSI: Job default/anthos-csi-workload-writer-<run-id> replicas are not in Succeeded phase: timed out waiting for the condition
Untuk melihat apakah kegagalan disebabkan oleh kurangnya set resource Pod, jalankan perintah berikut untuk memeriksa status tugas anthos-csi-workload-writer-<run-id> :
kubectl describe job anthos-csi-workload-writer-<run-id>
Jika batas resource tidak ditetapkan dengan benar untuk Pod Workload CSI,
status tugas akan berisi pesan error seperti berikut:
CPU and memory resource limits is invalid, as it are not defined for container: volume-tester
Jika Pod Workload CSI tidak dimulai karena injeksi file bantuan Istio,
Anda dapat menonaktifkan injeksi file bantuan Istio otomatis untuk sementara di
namespace default . Periksa label namespace dan gunakan
perintah berikut untuk menghapus label yang dimulai dengan istio.io/rev :
kubectl label namespace default istio.io/rev-
Jika Pod salah dikonfigurasi, verifikasi secara manual bahwa penyediaan volume dinamis dengan Driver CSI vSphere berfungsi:
- Buat PVC yang menggunakan StorageClass
standard-rwo .
- Buat Pod yang menggunakan PVC.
- Pastikan bahwa Pod dapat membaca/menulis data ke volume.
- Hapus Pod dan PVC setelah Anda memverifikasi operasi yang benar.
Jika penyediaan volume dinamis dengan Driver CSI vSphere berfungsi, jalankan gkectl diagnose atau gkectl upgrade dengan flag --skip-validation-csi-workload untuk melewati pemeriksaan Workload CSI.
|
Operasi |
1.16.0-1.16.2 |
Waktu tunggu update cluster pengguna habis saat versi cluster admin adalah 1.15
Saat Anda login ke
workstation admin yang dikelola pengguna, perintah gkectl update cluster mungkin kehabisan waktu dan gagal memperbarui cluster pengguna. Hal ini terjadi jika
versi cluster admin adalah 1.15 dan Anda menjalankan gkectl update admin
sebelum menjalankan gkectl update cluster .
Jika kegagalan ini terjadi, Anda akan melihat error berikut saat mencoba mengupdate cluster:
Preflight check failed with failed to run server-side preflight checks: server-side preflight checks failed: timed out waiting for the condition
Preflight check failed with failed to run server-side preflight checks: server-side preflight checks failed: timed out waiting for the condition
Selama update cluster admin 1.15, validation-controller yang memicu pemeriksaan preflight akan dihapus dari cluster. Jika Anda kemudian mencoba mengupdate cluster pengguna, pemeriksaan preflight akan berhenti berfungsi hingga waktu tunggu habis.
Solusi:
- Jalankan perintah berikut untuk men-deploy ulang
validation-controller :
gkectl prepare --kubeconfig ADMIN_KUBECONFIG --bundle-path BUNDLE_PATH --upgrade-platform
-
Setelah persiapan selesai, jalankan
gkectl update cluster lagi untuk memperbarui cluster pengguna
|
Operasi |
1.16.0-1.16.2 |
Waktu tunggu pembuatan cluster pengguna habis saat versi cluster admin adalah 1.15
Saat Anda login ke
workstation admin yang dikelola pengguna, perintah gkectl create cluster mungkin kehabisan waktu dan gagal membuat cluster pengguna. Hal ini terjadi jika
versi cluster admin adalah 1.15.
Jika kegagalan ini terjadi, Anda akan melihat error berikut saat mencoba membuat cluster:
Preflight check failed with failed to run server-side preflight checks: server-side preflight checks failed: timed out waiting for the condition
Preflight check failed with failed to run server-side preflight checks: server-side preflight checks failed: timed out waiting for the condition
Karena validation-controller ditambahkan pada 1.16, saat menggunakan
cluster admin 1.15, validation-controller yang bertanggung jawab untuk memicu pemeriksaan preflight tidak ada. Oleh karena itu, saat mencoba membuat cluster pengguna, pemeriksaan preflight akan hang hingga waktu tunggu habis.
Solusi:
- Jalankan perintah berikut untuk men-deploy
validation-controller :
gkectl prepare --kubeconfig ADMIN_KUBECONFIG --bundle-path BUNDLE_PATH --upgrade-platform
-
Setelah persiapan selesai, jalankan
gkectl create cluster lagi untuk membuat cluster pengguna
|
Upgrade, Update |
1.16.0-1.16.2 |
Update atau upgrade cluster admin akan gagal jika project atau lokasi layanan add-on tidak cocok satu sama lain
Saat Anda mengupgrade cluster admin dari versi 1.15.x ke 1.16.x, atau menambahkan konfigurasi connect , stackdriver , cloudAuditLogging , atau gkeOnPremAPI saat Anda mengupdate cluster admin, operasi tersebut mungkin ditolak oleh webhook cluster admin. Salah satu pesan error berikut mungkin ditampilkan:
"projects for connect, stackdriver and cloudAuditLogging must be the
same when specified during cluster creation."
"locations for connect, gkeOnPremAPI, stackdriver and
cloudAuditLogging must be in the same region when specified during
cluster creation."
"locations for stackdriver and cloudAuditLogging must be the same
when specified during cluster creation."
Update atau upgrade cluster admin memerlukan
onprem-admin-cluster-controller untuk merekonsiliasi cluster
admin dalam cluster jenis. Saat status cluster admin dipulihkan dalam
cluster jenis, webhook cluster admin tidak dapat membedakan apakah
objek OnPremAdminCluster tersebut digunakan untuk pembuatan cluster admin,
atau untuk melanjutkan operasi untuk update atau upgrade. Beberapa validasi khusus buat
dipanggil saat mengupdate dan mengupgrade secara tiba-tiba.
Solusi:
Tambahkan anotasi onprem.cluster.gke.io/skip-project-location-sameness-validation: true ke objek OnPremAdminCluster :
- Edit resource cluster
onpremadminclusters :
kubectl edit onpremadminclusters ADMIN_CLUSTER_NAME -n kube-system –kubeconfig ADMIN_CLUSTER_KUBECONFIG
Ganti resource berikut:
ADMIN_CLUSTER_NAME : nama
cluster admin.
ADMIN_CLUSTER_KUBECONFIG : jalur
file kubeconfig cluster admin.
- Tambahkan anotasi
onprem.cluster.gke.io/skip-project-location-sameness-validation: true
dan simpan resource kustom.
- Bergantung pada jenis cluster admin, selesaikan salah satu
langkah berikut:
- Untuk cluster admin non-HA yang memiliki file checkpoint: tambahkan parameter
disable-update-from-checkpoint dalam perintah update, atau tambahkan parameter `disable-upgrade-from-checkpoint` dalam perintah upgrade. Parameter
ini hanya diperlukan saat berikutnya Anda menjalankan
perintah update atau upgrade :
-
gkectl update admin --config ADMIN_CONFIG_file --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--disable-update-from-checkpoint
-
gkectl upgrade admin --config ADMIN_CONFIG_file --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--disable-upgrade-from-checkpoint
- Untuk cluster admin dengan ketersediaan tinggi (HA) atau file checkpoint dinonaktifkan: update atau upgrade cluster admin seperti biasa. Tidak ada parameter tambahan yang diperlukan pada perintah update atau upgrade.
|
Operasi |
1.16.0-1.16.2 |
Gagal menghapus cluster pengguna saat menggunakan workstation admin yang dikelola pengguna
Saat Anda login ke
workstation admin yang dikelola pengguna, perintah gkectl delete cluster mungkin kehabisan waktu dan gagal menghapus cluster pengguna. Hal ini terjadi jika Anda terlebih dahulu menjalankan gkectl di workstation yang dikelola pengguna untuk membuat, memperbarui, atau mengupgrade cluster pengguna. Jika kegagalan ini terjadi,
Anda akan melihat error berikut saat mencoba menghapus cluster:
failed to wait for user cluster management namespace "USER_CLUSTER_NAME-gke-onprem-mgmt"
to be deleted: timed out waiting for the condition
Selama penghapusan, cluster akan menghapus semua objeknya terlebih dahulu. Penghapusan objek Validasi (yang dibuat selama proses pembuatan, update, atau upgrade) terhenti pada fase penghapusan. Hal ini terjadi karena resolver memblokir penghapusan objek, yang menyebabkan penghapusan cluster gagal.
Solusi:
- Dapatkan nama semua objek Validasi:
kubectl --kubeconfig ADMIN_KUBECONFIG get validations \
-n USER_CLUSTER_NAME-gke-onprem-mgmt
-
Untuk setiap objek Validasi, jalankan perintah berikut untuk menghapus finaler dari objek Validasi:
kubectl --kubeconfig ADMIN_KUBECONFIG patch validation/VALIDATION_OBJECT_NAME \
-n USER_CLUSTER_NAME-gke-onprem-mgmt -p '{"metadata":{"finalizers":[]}}' --type=merge
Setelah menghapus finaler dari semua objek Validasi, objek akan dihapus dan operasi penghapusan cluster pengguna akan selesai secara otomatis. Anda tidak perlu melakukan tindakan tambahan.
|
Networking |
1,15, 1,16 |
Traffic gateway NAT keluar ke server eksternal gagal
Jika Pod sumber dan Pod gateway NAT keluar berada di dua worker node yang berbeda, traffic dari Pod sumber tidak dapat menjangkau layanan eksternal apa pun. Jika Pod berada di host yang sama, koneksi ke layanan atau aplikasi eksternal akan berhasil.
Masalah ini disebabkan oleh vSphere yang melepaskan paket VXLAN saat agregasi
tunnel diaktifkan. Ada masalah umum pada NSX dan VMware yang
hanya mengirim traffic gabungan pada port VXLAN yang dikenal (4789).
Solusi:
Ubah port VXLAN yang digunakan oleh Cilium menjadi 4789 :
- Mengedit
cilium-config ConfigMap:
kubectl edit cm -n kube-system cilium-config --kubeconfig USER_CLUSTER_KUBECONFIG
- Tambahkan kode berikut ke
cilium-config ConfigMap:
tunnel-port: 4789
- Mulai ulang DaemonSet anetd:
kubectl rollout restart ds anetd -n kube-system --kubeconfig USER_CLUSTER_KUBECONFIG
Solusi ini akan dikembalikan setiap kali cluster diupgrade. Anda harus mengonfigurasi ulang setelah melakukan setiap upgrade. VMware harus mengatasi masalah tersebut di vSphere
untuk mendapatkan perbaikan permanen.
|
Upgrade |
1.15.0-1.15.4 |
Upgrade cluster admin yang mengaktifkan enkripsi secret yang selalu aktif akan gagal
Upgrade cluster admin dari 1.14.x ke 1.15.x dengan enkripsi secret yang selalu aktif diaktifkan karena ketidakcocokan antara kunci enkripsi yang dihasilkan pengontrol dengan kunci yang dipertahankan pada disk data master admin. Output gkectl upgrade
admin berisi pesan error berikut:
E0926 14:42:21.796444 40110 console.go:93] Exit with error:
E0926 14:42:21.796491 40110 console.go:93] Failed to upgrade the admin cluster: failed to create admin cluster: failed to wait for OnPremAdminCluster "admin-cluster-name" to become ready: failed to wait for OnPremAdminCluster "admin-cluster-name" to be ready: error: timed out waiting for the condition, message: failed to wait for OnPremAdminCluster "admin-cluster-name" to stay in ready status for duration "2m0s": OnPremAdminCluster "non-prod-admin" is not ready: ready condition is not true: CreateOrUpdateControlPlane: Creating or updating credentials for cluster control plane
Menjalankan kubectl get secrets -A --kubeconfig KUBECONFIG` gagal dengan error berikut:
Internal error occurred: unable to transform key "/registry/secrets/anthos-identity-service/ais-secret": rpc error: code = Internal desc = failed to decrypt: unknown jwk
Solusi
Jika Anda memiliki cadangan cluster admin, lakukan langkah-langkah berikut untuk mengatasi kegagalan upgrade:
-
Nonaktifkan
secretsEncryption di file konfigurasi cluster admin, lalu perbarui cluster menggunakan perintah berikut:
gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig KUBECONFIG
-
Saat VM master admin baru dibuat, jalankan SSH ke VM master admin, ganti kunci baru pada disk data dengan kunci lama dari cadangan. Kunci ini terletak di
/opt/data/gke-k8s-kms-plugin/generatedkeys
pada master admin.
-
Update manifes Pod statis kms-plugin.yaml di
/etc/kubernetes/manifests untuk mengupdate --kek-id agar cocok dengan kolom kid dalam kunci enkripsi asli.
-
Mulai ulang Pod statis kms-plugin dengan memindahkan
/etc/kubernetes/manifests/kms-plugin.yaml ke direktori lain, lalu memindahkannya kembali.
-
Lanjutkan upgrade admin dengan menjalankan
gkectl upgrade admin lagi.
Mencegah kegagalan upgrade
Jika belum melakukan upgrade, sebaiknya Anda tidak mengupgrade ke 1.15.0-1.15.4. Jika Anda harus mengupgrade ke versi yang terpengaruh, lakukan
langkah-langkah berikut sebelum mengupgrade cluster admin:
-
Cadangkan cluster admin.
-
Nonaktifkan
secretsEncryption di file konfigurasi cluster admin, lalu perbarui cluster menggunakan perintah berikut:
gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig KUBECONFIG
- Upgrade cluster admin.
-
Mengaktifkan kembali enkripsi secret yang selalu aktif.
|
Penyimpanan |
1,11-1,16 |
Error disk dan kegagalan pemasangan saat menggunakan Changes Block Tracking (CBT)
Google Distributed Cloud tidak mendukung Changes Block Tracking (CBT) di
disk. Beberapa software pencadangan menggunakan fitur CBT untuk melacak status disk dan
melakukan pencadangan, yang menyebabkan disk tidak dapat terhubung ke VM
yang menjalankan Google Distributed Cloud. Untuk mengetahui informasi selengkapnya, lihat artikel Pusat Informasi VMware.
Solusi:
Jangan mencadangkan VM Google Distributed Cloud, karena software pencadangan pihak ketiga
dapat menyebabkan CBT diaktifkan di disk mereka. Anda tidak perlu mencadangkan VM ini.
Jangan aktifkan CBT pada node, karena perubahan ini tidak akan dipertahankan di seluruh
update atau upgrade.
Jika Anda sudah mengaktifkan disk dengan CBT, ikuti langkah-langkah Resolusi dalam artikel KB VMwareuntuk menonaktifkan CBT di Disk First Class.
|
Penyimpanan |
1,14, 1,15, 1,16 |
Kerusakan data di NFSv3 saat penambahan paralel ke file bersama dilakukan
dari beberapa host
Jika Anda menggunakan array penyimpanan Nutanix untuk menyediakan pembagian NFSv3 ke host, Anda mungkin akan mengalami kerusakan data atau tidak dapat menjalankan Pod dengan sukses. Masalah ini disebabkan oleh masalah kompatibilitas yang telah diketahui
antara versi VMware dan Nutanix tertentu. Untuk mengetahui informasi selengkapnya, lihat artikel Pusat Informasi VMware terkait.
Solusi:
Artikel Pusat Informasi VMware sudah tidak berlaku karena tidak ada
resolusi untuk saat ini. Untuk mengatasi masalah ini, update ESXi ke versi terbaru di host Anda dan ke versi Nutanix terbaru di array penyimpanan Anda.
|
Sistem operasi |
1.13.10, 1.14.6, 1.15.3 |
Ketidakcocokan versi antara kubelet dan bidang kontrol Kubernetes
Untuk rilis Google Distributed Cloud tertentu, kubelet yang berjalan pada node menggunakan versi yang berbeda dengan bidang kontrol Kubernetes. Ada ketidakcocokan karena biner kubelet yang dimuat sebelumnya di OS image menggunakan versi berbeda.
Tabel berikut mencantumkan ketidakcocokan versi yang teridentifikasi:
Versi Google Distributed Cloud |
versi kubelet |
Versi Kubernetes |
1.13.10 |
v1.24.11-gke.1200 |
v1.24.14-gke.2100 |
1.14.6 |
v1.25.8-gke.1500 |
v1.25.10-gke.1200 |
1.15.3 |
v1.26.2-gke.1001 |
v1.26.5-gke.2100 |
Solusi:
Anda tidak perlu melakukan apa pun. Inkonsistensi hanya terjadi antara versi patch Kubernetes dan tidak ada masalah yang disebabkan oleh kecondongan versi ini.
|
Upgrade, Update |
1.15.0-1.15.4 |
Upgrade atau update cluster admin dengan versi CA yang lebih tinggi dari 1 gagal
Jika cluster admin memiliki versi certificate authority (CA) di atas
1, update atau upgrade akan gagal karena validasi versi CA di
webhook. Output
upgrade/update gkectl berisi pesan error berikut:
CAVersion must start from 1
Solusi:
-
Turunkan skala deployment
auto-resize-controller di cluster admin untuk menonaktifkan perubahan ukuran otomatis node. Hal ini diperlukan karena kolom baru yang diperkenalkan ke Resource Kustom cluster admin pada 1.15 dapat menyebabkan error pointer nol di auto-resize-controller .
kubectl scale deployment auto-resize-controller -n kube-system --replicas=0 --kubeconfig KUBECONFIG
-
Jalankan perintah
gkectl dengan tanda --disable-admin-cluster-webhook .Contoh:
gkectl upgrade admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig KUBECONFIG --disable-admin-cluster-webhook
|
Operasi |
1.13, 1.14.0-1.14.8, 1.15.0-1.15.4, 1.16.0-1.16.1 |
Penghapusan cluster Controlplane V2 non-HA macet hingga waktu tunggu habis
Saat cluster Controlplane V2 non-HA dihapus, cluster tersebut akan terhenti pada penghapusan node hingga habis waktunya.
Solusi:
Jika cluster berisi StatefulSet dengan data penting, hubungi
hubungi Cloud Customer Care untuk
menyelesaikan masalah ini.
Atau, lakukan langkah-langkah berikut:
|
Penyimpanan |
1.15.0+, 1.16.0+ |
Tugas pemasangan volume CNS yang konstan muncul setiap menit untuk PVC/PV dalam hierarki setelah mengupgrade ke versi 1.15+
Saat cluster berisi volume persisten vSphere dalam hierarki (misalnya, PVC yang dibuat dengan StorageClass standard ), Anda akan mengamati tugas com.vmware.cns.tasks.attachvolume yang dipicu setiap menit dari vCenter.
Solusi:
Edit configMap fitur CSI vSphere dan setel list-volumes ke false:
kubectl edit configmap internal-feature-states.csi.vsphere.vmware.com -n kube-system --kubeconfig KUBECONFIG
Mulai ulang pod pengontrol vSphere CSI:
kubectl rollout restart deployment vsphere-csi-controller -n kube-system --kubeconfig KUBECONFIG
|
Penyimpanan |
1.16.0 |
Peringatan palsu yang dilihat oleh PVC
Jika sebuah cluster berisi volume persisten vSphere intree, perintah gkectl diagnose dan gkectl upgrade dapat menimbulkan peringatan palsu terhadap klaim volume persisten (PVC) saat memvalidasi setelan penyimpanan cluster. Pesan peringatan akan terlihat seperti
berikut
CSIPrerequisites pvc/pvc-name: PersistentVolumeClaim pvc-name bounds to an in-tree vSphere volume created before CSI migration enabled, but it doesn't have the annotation pv.kubernetes.io/migrated-to set to csi.vsphere.vmware.com after CSI migration is enabled
Solusi:
Jalankan perintah berikut untuk memeriksa anotasi PVC dengan peringatan di atas:
kubectl get pvc PVC_NAME -n PVC_NAMESPACE -oyaml --kubeconfig KUBECONFIG
Jika kolom annotations dalam
output berisi hal berikut, Anda dapat mengabaikan peringatan ini dengan aman:
pv.kubernetes.io/bind-completed: "yes"
pv.kubernetes.io/bound-by-controller: "yes"
volume.beta.kubernetes.io/storage-provisioner: csi.vsphere.vmware.com
|
Upgrade, Update |
1.15.0+, 1.16.0+ |
Rotasi kunci akun layanan gagal saat beberapa kunci sudah tidak berlaku
Jika cluster Anda tidak menggunakan registry pribadi, dan kunci akun layanan akses komponen Anda serta kunci akun layanan Logging-monitoring (atau Connect-register) sudah tidak berlaku, saat Anda merotasi kunci akun layanan, gkectl update credentials akan gagal dengan error yang mirip dengan berikut ini:
Error: reconciliation failed: failed to update platform: ...
Solusi:
Pertama, rotasikan kunci akun layanan akses komponen. Meskipun pesan error yang sama ditampilkan, Anda seharusnya dapat merotasi kunci lainnya setelah kunci akun layanan akses komponen dirotasi.
Jika update masih tidak berhasil, hubungi Cloud Customer Care untuk menyelesaikan masalah ini.
|
Upgrade |
1.16.0-1.16.5 |
1.15 Mesin master pengguna mengalami pembuatan ulang yang tidak terduga saat pengontrol cluster pengguna diupgrade ke 1.16
Selama upgrade cluster pengguna, setelah pengontrol cluster pengguna diupgrade ke 1.16, jika Anda memiliki cluster pengguna 1,15 lainnya yang dikelola oleh cluster admin yang sama, mesin master penggunanya mungkin akan dibuat ulang secara tidak terduga.
Ada bug di pengontrol cluster pengguna 1.16 yang dapat memicu pembuatan ulang mesin master pengguna 1.15.
Solusi yang Anda lakukan bergantung pada bagaimana Anda mengalami masalah ini.
Solusi saat mengupgrade cluster pengguna menggunakan Konsol Google Cloud:
Opsi 1: Gunakan GKE versi 1.16.6+ di VMware dengan perbaikan tersebut.
Opsi 2: Lakukan langkah-langkah berikut:
- Tambahkan anotasi jalankan ulang secara manual dengan perintah berikut:
kubectl edit onpremuserclusters USER_CLUSTER_NAME -n USER_CLUSTER_NAME-gke-onprem-mgmt --kubeconfig ADMIN_KUBECONFIG
Anotasi jalankan ulang adalah:
onprem.cluster.gke.io/server-side-preflight-rerun: true
- Pantau progres upgrade dengan memeriksa kolom
status di OnPremUserCluster.
Solusi saat mengupgrade cluster pengguna menggunakan workstation admin Anda sendiri:
Opsi 1: Gunakan GKE versi 1.16.6+ di VMware dengan perbaikan tersebut.
Opsi 2: Lakukan langkah-langkah berikut:
- Tambahkan file info build
/etc/cloud/build.info dengan konten berikut. Hal ini menyebabkan pemeriksaan preflight berjalan secara lokal di workstation admin, bukan di server.
gke_on_prem_version: GKE_ON_PREM_VERSION
Contoh:
gke_on_prem_version: 1.16.0-gke.669
- Jalankan kembali perintah upgrade.
- Setelah upgrade selesai, hapus file build.info.
|
Buat |
1.16.0-1.16.5, 1.28.0-1.28.100 |
Pemeriksaan preflight akan gagal jika nama host tidak ada dalam file blok IP.
Selama pembuatan cluster, jika Anda tidak menentukan nama host untuk setiap alamat IP
dalam file blok IP, pemeriksaan preflight akan gagal dengan
pesan error berikut:
multiple VMs found by DNS name in xxx datacenter. Anthos Onprem doesn't support duplicate hostname in the same vCenter and you may want to rename/delete the existing VM.`
Ada bug dalam pemeriksaan preflight yang menganggap nama host kosong sebagai duplikat.
Solusi:
Opsi 1: Gunakan versi yang memiliki perbaikan.
Opsi 2: Abaikan pemeriksaan preflight ini dengan menambahkan tanda --skip-validation-net-config .
Opsi 3: Tentukan nama host unik untuk setiap alamat IP dalam file blok IP.
|
Upgrade, Update |
1.16 |
Kegagalan pemasangan volume saat mengupgrade/mengupdate cluster admin jika menggunakan cluster pengguna non-HA dan bidang kontrol v1
Untuk cluster admin non-HA dan cluster pengguna bidang kontrol v1, saat Anda mengupgrade atau mengupdate cluster admin, pembuatan ulang mesin master cluster admin dapat terjadi bersamaan dengan mulai ulang mesin master cluster pengguna, yang dapat menampilkan kondisi race.
Hal ini menyebabkan Pod bidang kontrol cluster pengguna tidak dapat berkomunikasi ke bidang kontrol cluster admin, yang menyebabkan masalah pemasangan volume untuk kube-etcd dan kube-apiserver di bidang kontrol cluster pengguna.
Untuk memverifikasi masalah, jalankan perintah berikut untuk pod yang terpengaruh:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace USER_CLUSTER_NAME describe pod IMPACTED_POD_NAME
Dan Anda akan melihat peristiwa seperti:
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedMount 101s kubelet Unable to attach or mount volumes: unmounted volumes=[kube-audit], unattached volumes=[], failed to process volumes=[]: timed out waiting for the condition
Warning FailedMount 86s (x2 over 3m28s) kubelet MountVolume.SetUp failed for volume "pvc-77cd0635-57c2-4392-b191-463a45c503cb" : rpc error: code = FailedPrecondition desc = volume ID: "bd313c62-d29b-4ecd-aeda-216648b0f7dc" does not appear staged to "/var/lib/kubelet/plugins/kubernetes.io/csi/csi.vsphere.vmware.com/92435c96eca83817e70ceb8ab994707257059734826fedf0c0228db6a1929024/globalmount"
Solusi:
-
SSH ke node bidang kontrol pengguna, karena node tersebut adalah cluster pengguna bidang kontrol v1, node bidang kontrol pengguna berada di cluster admin.
-
Mulai ulang kubelet menggunakan perintah berikut:
sudo systemctl restart kubelet
Setelah dimulai ulang, kubelet dapat merekonstruksi stage global mount dengan benar.
|
Upgrade, Update |
1.16.0 |
Node bidang kontrol gagal dibuat
Selama upgrade atau update cluster admin, kondisi race dapat menyebabkan pengelola pengontrol cloud vSphere menghapus node bidang kontrol baru secara tidak terduga. Hal ini menyebabkan clusterapi-controller terhambat menunggu node dibuat, dan bahkan waktu upgrade/update habis. Dalam hal ini, output perintah upgrade/update gkectl mirip dengan yang berikut:
controlplane 'default/gke-admin-hfzdg' is not ready: condition "Ready": condition is not ready with reason "MachineInitializing", message "Wait for the control plane machine "gke-admin-hfzdg-6598459f9zb647c8-0\" to be rebooted"...
Untuk mengidentifikasi gejala, jalankan perintah di bawah untuk mendapatkan login pengelola pengontrol cloud vSphere di cluster admin:
kubectl get pods --kubeconfig ADMIN_KUBECONFIG -n kube-system | grep vsphere-cloud-controller-manager
kubectl logs -f vsphere-cloud-controller-manager-POD_NAME_SUFFIX --kubeconfig ADMIN_KUBECONFIG -n kube-system
Berikut adalah contoh pesan error dari perintah di atas:
node name: 81ff17e25ec6-qual-335-1500f723 has a different uuid. Skip deleting this node from cache.
Solusi:
-
Mulai ulang mesin yang gagal untuk membuat ulang objek node yang dihapus.
-
SSH ke setiap node bidang kontrol dan memulai ulang pod statis pengelola pengontrol cloud vSphere:
sudo crictl ps | grep vsphere-cloud-controller-manager | awk '{print $1}'
sudo crictl stop PREVIOUS_COMMAND_OUTPUT
-
Jalankan kembali perintah upgrade/update.
|
Operasi |
1.16 |
Nama host duplikat di pusat data yang sama menyebabkan kegagalan pembuatan atau upgrade cluster
Upgrade cluster 1.15 atau pembuatan cluster 1.16 dengan IP statis akan gagal jika ada nama host duplikat di pusat data yang sama. Kegagalan ini terjadi karena pengelola pengontrol cloud vSphere gagal menambahkan IP eksternal dan ID penyedia ke objek node. Hal ini menyebabkan waktu tunggu proses upgrade/pembuatan cluster habis.
Untuk mengidentifikasi masalah, dapatkan log pod pengelola pengontrol cloud vSphere untuk cluster tersebut. Perintah yang Anda gunakan bergantung pada jenis cluster, seperti berikut:
- Cluster admin:
kubectl get pods --kubeconfig ADMIN_KUBECONFIG -n kube-system | grep vsphere-cloud-controller-manager
kubectl logs -f vsphere-cloud-controller-manager-POD_NAME_SUFFIX --kubeconfig ADMIN_KUBECONFIG -n kube-system
- Cluster pengguna (kubeception):
kubectl get pods --kubeconfig ADMIN_KUBECONFIG -n USER_CLUSTER_NAME | grep vsphere-cloud-controller-manager
kubectl logs -f vsphere-cloud-controller-manager-POD_NAME_SUFFIX --kubeconfig ADMIN_KUBECONFIG -n USER_CLUSTER_NAME
- Cluster pengguna: (Controlplane V2):
kubectl get pods --kubeconfig USER_KUBECONFIG -n kube-system | grep vsphere-cloud-controller-manager
kubectl logs -f vsphere-cloud-controller-manager-POD_NAME_SUFFIX --kubeconfig USER_KUBECONFIG -n kube-system
Berikut adalah contoh pesan error:
I1003 17:17:46.769676 1 search.go:152] Finding node admin-vm-2 in vc=vcsa-53598.e5c235a1.asia-northeast1.gve.goog and datacenter=Datacenter
E1003 17:17:46.771717 1 datacenter.go:111] Multiple vms found VM by DNS Name. DNS Name: admin-vm-2
Periksa apakah nama host diduplikasi di pusat data:
Anda dapat menggunakan pendekatan berikut untuk memeriksa apakah nama host memiliki duplikat,
dan melakukan solusi jika perlu.
export GOVC_DATACENTER=GOVC_DATACENTER
export GOVC_URL=GOVC_URL
export GOVC_USERNAME=GOVC_USERNAME
export GOVC_PASSWORD=GOVC_PASSWORD
export GOVC_INSECURE=true
govc find . -type m -guest.hostName HOSTNAME
Contoh perintah dan output:
export GOVC_DATACENTER=mtv-lifecycle-vc01
export GOVC_URL=https://mtv-lifecycle-vc01.anthos/sdk
export GOVC_USERNAME=xxx
export GOVC_PASSWORD=yyy
export GOVC_INSECURE=true
govc find . -type m -guest.hostName f8c3cd333432-lifecycle-337-xxxxxxxz
./vm/gke-admin-node-6b7788cd76-wkt8g
./vm/gke-admin-node-6b7788cd76-99sg2
./vm/gke-admin-master-5m2jb
Solusi yang Anda lakukan bergantung pada operasi yang gagal.
Solusi untuk upgrade:
Lakukan solusi untuk jenis cluster yang berlaku.
- Cluster pengguna:
-
Perbarui nama host mesin yang terpengaruh di user-ip-block.yaml ke nama yang unik dan memicu update otomatis:
gkectl update cluster --kubeconfig ADMIN_KUBECONFIG --config NEW_USER_CLUSTER_CONFIG --force
-
Jalankan kembali
gkectl upgrade cluster
- Cluster Admin:
- Perbarui nama host mesin yang terpengaruh di admin-ip-block.yaml ke nama yang unik dan picu update otomatis:
gkectl update admin --kubeconfig ADMIN_KUBECONFIG --config NEW_ADMIN_CLUSTER_CONFIG --force --skip-cluster-ready-check
- Jika vm admin non-HA, dan Anda mendapati bahwa vm master admin menggunakan nama host duplikat, Anda juga perlu:
Mendapatkan nama mesin master admin
kubectl get machine --kubeconfig ADMIN_KUBECONFIG -owide -A
Memperbarui objek mesin master admin
Catatan: NEW_ADMIN_MASTER_HOSTNAME harus sama dengan yang Anda tetapkan di admin-ip-block.yaml pada langkah 1.
kubectl patch machine ADMIN_MASTER_MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG --type='json' -p '[{"op": "replace", "path": "/spec/providerSpec/value/networkSpec/address/hostname", "value":"NEW_ADMIN_MASTER_HOSTNAME"}]'
Pastikan bahwa nama host telah diperbarui di objek mesin master admin:
kubectl get machine ADMIN_MASTER_MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG -oyaml
kubectl get machine ADMIN_MASTER_MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG -o jsonpath='{.spec.providerSpec.value.networkSpec.address.hostname}'
- Jalankan kembali upgrade cluster admin dengan checkpoint dinonaktifkan:
gkectl upgrade admin --kubeconfig ADMIN_KUBECONFIG --config ADMIN_CLUSTER_CONFIG --disable-upgrade-from-checkpoint
Solusi untuk penginstalan:
Lakukan solusi untuk jenis cluster yang berlaku.
|
Operasi |
1.16.0, 1.16.1, 1.16.2, 1.16.3 |
$ dan ` tidak didukung di nama pengguna atau sandi vSphere
Operasi berikut akan gagal jika nama pengguna atau sandi vSphere berisi $ atau ` :
- Mengupgrade cluster pengguna 1.15 dengan Controlplane V2 yang diaktifkan ke versi 1.16
- Mengupgrade cluster admin dengan ketersediaan tinggi (HA) 1,15 ke versi 1.16
- Membuat cluster pengguna 1.16 dengan Controlplane V2 diaktifkan
- Membuat cluster admin dengan ketersediaan tinggi (HA) 1.16
Gunakan Google Distributed Cloud versi 1.16.4+ untuk perbaikan atau lakukan solusi di bawah ini. Solusi yang Anda lakukan bergantung pada operasi yang gagal.
Solusi untuk upgrade:
- Ubah nama pengguna atau sandi vCenter di sisi vCenter untuk menghapus
$ dan ` .
- Perbarui nama pengguna atau sandi vCenter di
file konfigurasi
kredensial Anda.
- Picu update cluster secara paksa.
- Cluster pengguna:
gkectl update cluster --kubeconfig ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG --force
- Cluster admin:
gkectl update admin --kubeconfig ADMIN_KUBECONFIG --config ADMIN_CLUSTER_CONFIG --force --skip-cluster-ready-check
Solusi untuk penginstalan:
- Ubah nama pengguna atau sandi vCenter di sisi vCenter untuk menghapus
$ dan ` .
- Perbarui nama pengguna atau sandi vCenter di
file konfigurasi
kredensial Anda.
- Lakukan solusi untuk jenis cluster yang berlaku.
|
Penyimpanan |
1.11+, 1.12+, 1.13+, 1.14+, 1.15+, 1.16 |
Kegagalan pembuatan PVC setelah node dibuat ulang dengan nama yang sama
Setelah node dihapus lalu dibuat ulang dengan nama node yang sama, ada sedikit kemungkinan bahwa pembuatan PersistentVolumeKlaim (PVC) berikutnya gagal dan disertai error seperti berikut:
The object 'vim.VirtualMachine:vm-988369' has already been deleted or has not been completely created
Hal ini disebabkan oleh kondisi race saat pengontrol CSI vSphere tidak menghapus mesin yang dihapus dari cache-nya.
Solusi:
Mulai ulang pod pengontrol vSphere CSI:
kubectl rollout restart deployment vsphere-csi-controller -n kube-system --kubeconfig KUBECONFIG
|
Operasi |
1.16.0 |
Perbaikan gkectl admin-master menampilkan error kubeconfig unmarshall
Saat Anda menjalankan perintah gkectl repair admin-master di cluster admin HA, gkectl akan menampilkan pesan error berikut:
Exit with error: Failed to repair: failed to select the template: failed to get cluster name from kubeconfig, please contact Google support. failed to decode kubeconfig data: yaml: unmarshal errors:
line 3: cannot unmarshal !!seq into map[string]*api.Cluster
line 8: cannot unmarshal !!seq into map[string]*api.Context
Solusi:
Tambahkan flag --admin-master-vm-template= ke perintah dan
sediakan template VM mesin yang akan diperbaiki:
gkectl repair admin-master --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
--config ADMIN_CLUSTER_CONFIG_FILE \
--admin-master-vm-template=/DATA_CENTER/vm/VM_TEMPLATE_NAME
Untuk menemukan template VM mesin:
- Buka halaman Hosts and Clusters di klien vSphere.
- Klik Template VM dan filter menurut nama cluster admin.
Anda akan melihat tiga template VM untuk cluster admin.
- Salin nama template VM yang cocok dengan nama mesin
yang Anda perbaiki dan gunakan nama template dalam perintah perbaikan.
gkectl repair admin-master \
--config=/home/ubuntu/admin-cluster.yaml \
--kubeconfig=/home/ubuntu/kubeconfig \
--admin-master-vm-template=/atl-qual-vc07/vm/gke-admin-98g94-zx...7vx-0-tmpl
|
Networking |
1.10.0+, 1.11.0+, 1.12.0+, 1.13.0+, 1.14.0-1.14.7, 1.15.0-1.15.3, 1.16.0 |
Melihat VM rusak karena kapasitas disk hampir penuh
Jika Anda menggunakan Seesaw sebagai jenis load balancer untuk cluster dan melihat bahwa VM Seesaw tidak aktif atau terus gagal melakukan booting, Anda mungkin melihat pesan error berikut di konsol vSphere:
GRUB_FORCE_PARTUUID set, initrdless boot failed. Attempting with initrd
Error ini menunjukkan bahwa kapasitas disk di VM rendah karena fasih-bit yang berjalan di Seesaw VM tidak dikonfigurasi dengan rotasi log yang benar.
Solusi:
Temukan file log yang menggunakan sebagian besar ruang disk menggunakan du -sh -- /var/lib/docker/containers/* | sort -rh . Bersihkan file log dengan ukuran terbesar, lalu mulai ulang VM.
Catatan: Jika VM benar-benar tidak dapat diakses, pasang disk ke VM yang berfungsi (misalnya workstation admin), hapus file dari disk yang terpasang, lalu pasang kembali disk ke VM Seesaw asli.
Untuk mencegah masalah ini terjadi lagi, hubungkan ke VM dan ubah file /etc/systemd/system/docker.fluent-bit.service . Tambahkan --log-opt max-size=10m --log-opt max-file=5 di perintah Docker, lalu jalankan systemctl restart docker.fluent-bit.service
|
Operasi |
1.13, 1.14.0-1.14.6, 1.15 |
Terjadi error pada kunci publik SSH admin setelah upgrade atau update cluster admin
Saat Anda mencoba mengupgrade (gkectl upgrade admin ) atau memperbarui (gkectl update admin ) cluster admin yang tidak memiliki ketersediaan Tinggi dengan checkpoint yang diaktifkan, upgrade atau update mungkin gagal dengan menampilkan error berikut:
Checking admin cluster certificates...FAILURE
Reason: 20 admin cluster certificates error(s).
Unhealthy Resources:
AdminMaster clusterCA bundle: failed to get clusterCA bundle on admin master, command [ssh -o IdentitiesOnly=yes -i admin-ssh-key -o StrictHostKeyChecking=no -o ConnectTimeout=30 ubuntu@AdminMasterIP -- sudo cat /etc/kubernetes/pki/ca-bundle.crt] failed with error: exit status 255, stderr: Authorized uses only. All activity may be monitored and reported.
ubuntu@AdminMasterIP: Permission denied (publickey).
failed to ssh AdminMasterIP, failed with error: exit status 255, stderr: Authorized uses only. All activity may be monitored and reported.
ubuntu@AdminMasterIP: Permission denied (publickey)
error dialing ubuntu@AdminMasterIP: failed to establish an authenticated SSH connection: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey]...
Solusi:
Jika Anda tidak dapat melakukan upgrade ke versi patch Google Distributed Cloud saat perbaikan ini,
hubungi Dukungan Google untuk mendapatkan bantuan.
|
Upgrade |
1.13.0-1.13.9, 1.14.0-1.14.6, 1.15.1-1.15.2 |
Upgrade cluster admin yang terdaftar di GKE On-Prem API dapat gagal
Saat cluster admin didaftarkan di GKE On-Prem API, upgrade cluster admin ke versi yang terpengaruh dapat gagal karena keanggotaan fleet tidak dapat diperbarui. Jika kegagalan ini terjadi, Anda akan melihat error berikut saat mencoba mengupgrade cluster:
failed to register cluster: failed to apply Hub Membership: Membership API request failed: rpc error: code = InvalidArgument desc = InvalidFieldError for field endpoint.on_prem_cluster.resource_link: field cannot be updated
Cluster admin didaftarkan di API saat Anda
mendaftarkan cluster secara eksplisit, atau saat Anda mengupgrade
cluster pengguna menggunakan klien GKE On-Prem API.
Solusi:
Batalkan pendaftaran cluster admin:
gcloud alpha container vmware admin-clusters unenroll ADMIN_CLUSTER_NAME --project CLUSTER_PROJECT --location=CLUSTER_LOCATION --allow-missing
dan lanjutkan
upgrade cluster admin. Anda mungkin melihat error `failed to register cluster` yang tidak berlaku untuk sementara. Setelah beberapa saat, halaman akan otomatis diupdate.
|
Upgrade, Update |
1.13.0-1.13.9, 1.14.0-1.14.4, 1.15.0 |
Anotasi link resource cluster admin yang terdaftar tidak dipertahankan
Saat cluster admin terdaftar di GKE On-Prem API, anotasi link resource-nya diterapkan ke resource kustom OnPremAdminCluster , yang tidak dipertahankan selama update cluster admin berikutnya karena kunci anotasi yang digunakan salah. Hal ini dapat menyebabkan cluster admin kembali didaftarkan di GKE On-Prem API secara tidak sengaja.
Cluster admin didaftarkan di API saat Anda
mendaftarkan cluster secara eksplisit, atau saat Anda mengupgrade
cluster pengguna menggunakan klien GKE On-Prem API.
Solusi:
Batalkan pendaftaran cluster admin:
gcloud alpha container vmware admin-clusters unenroll ADMIN_CLUSTER_NAME --project CLUSTER_PROJECT --location=CLUSTER_LOCATION --allow-missing
dan daftarkan ulang
cluster admin lagi.
|
Networking |
1.15.0-1.15.2 |
CoreDNS orderPolicy tidak dikenali
OrderPolicy tidak dikenali sebagai parameter dan
tidak digunakan. Sebagai gantinya, Google Distributed Cloud selalu menggunakan Random .
Masalah ini terjadi karena template CoreDNS tidak diupdate, yang
menyebabkan orderPolicy diabaikan.
Solusi:
Perbarui template CoreDNS dan terapkan perbaikan. Perbaikan ini tetap ada hingga upgrade.
- Edit template yang ada:
kubectl edit cm -n kube-system coredns-template
Ganti konten template dengan konten berikut ini:
coredns-template: |-
.:53 {
errors
health {
lameduck 5s
}
ready
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
fallthrough in-addr.arpa ip6.arpa
}
{{- if .PrivateGoogleAccess }}
import zones/private.Corefile
{{- end }}
{{- if .RestrictedGoogleAccess }}
import zones/restricted.Corefile
{{- end }}
prometheus :9153
forward . {{ .UpstreamNameservers }} {
max_concurrent 1000
{{- if ne .OrderPolicy "" }}
policy {{ .OrderPolicy }}
{{- end }}
}
cache 30
{{- if .DefaultDomainQueryLogging }}
log
{{- end }}
loop
reload
loadbalance
}{{ range $i, $stubdomain := .StubDomains }}
{{ $stubdomain.Domain }}:53 {
errors
{{- if $stubdomain.QueryLogging }}
log
{{- end }}
cache 30
forward . {{ $stubdomain.Nameservers }} {
max_concurrent 1000
{{- if ne $.OrderPolicy "" }}
policy {{ $.OrderPolicy }}
{{- end }}
}
}
{{- end }}
|
Upgrade, Update |
1.10, 1.11, 1.12, 1.13.0-1.13.7, 1.14.0-1.14.3 |
Status OnPremAdminCluster tidak konsisten antara checkpoint dan CR sebenarnya
Kondisi race tertentu dapat menyebabkan status OnPremAdminCluster menjadi tidak konsisten antara checkpoint dan CR sebenarnya. Jika masalah terjadi, Anda mungkin mengalami error berikut saat mengupdate cluster admin setelah mengupgradenya:
Exit with error:
E0321 10:20:53.515562 961695 console.go:93] Failed to update the admin cluster: OnPremAdminCluster "gke-admin-rj8jr" is in the middle of a create/upgrade ("" -> "1.15.0-gke.123"), which must be completed before it can be updated
Failed to update the admin cluster: OnPremAdminCluster "gke-admin-rj8jr" is in the middle of a create/upgrade ("" -> "1.15.0-gke.123"), which must be completed before it can be updated
Untuk mengatasi masalah ini, Anda harus mengedit checkpoint atau menonaktifkan checkpoint untuk upgrade/update. Hubungi tim dukungan kami untuk menggunakan solusi ini.
|
Operasi |
1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1 |
Proses rekonsiliasi mengubah sertifikat admin pada cluster admin
Google Distributed Cloud mengubah sertifikat admin di bidang kontrol cluster admin
pada setiap proses rekonsiliasi, misalnya selama upgrade cluster. Perilaku ini
meningkatkan kemungkinan mendapatkan sertifikat yang tidak valid untuk cluster admin,
terutama untuk cluster versi 1.15.
Jika masalah ini memengaruhi Anda, Anda mungkin akan mengalami masalah seperti
berikut ini:
- Sertifikat yang tidak valid dapat menyebabkan waktu tunggu perintah berikut habis dan menampilkan error:
gkectl create admin
gkectl upgrade amdin
gkectl update admin
Perintah ini dapat menampilkan error otorisasi seperti berikut:
Failed to reconcile admin cluster: unable to populate admin clients: failed to get admin controller runtime client: Unauthorized
- Log
kube-apiserver untuk cluster admin Anda mungkin berisi error seperti berikut:
Unable to authenticate the request" err="[x509: certificate has expired or is not yet valid...
Solusi:
Upgrade ke versi Google Distributed Cloud dengan perbaikan:
1.13.10+, 1.14.6+, 1.15.2+.
Jika upgrade tidak dapat dilakukan, hubungi Cloud Customer Care untuk menyelesaikan masalah ini.
|
Jaringan, Operasi |
1.10, 1.11, 1.12, 1.13, 1.14 |
Komponen Gateway Jaringan Anthos dihapus atau tertunda karena class prioritas tidak ada
Pod gateway jaringan di kube-system dapat menampilkan status Pending atau Evicted , seperti ditunjukkan dalam contoh output ringkas berikut:
$ kubectl -n kube-system get pods | grep ang-node
ang-node-bjkkc 2/2 Running 0 5d2h
ang-node-mw8cq 0/2 Evicted 0 6m5s
ang-node-zsmq7 0/2 Pending 0 7h
Error ini menunjukkan peristiwa penghapusan atau ketidakmampuan untuk menjadwalkan Pod karena resource node. Karena Pod Gateway Jaringan Anthos tidak memiliki PriorityClass, pod memiliki prioritas default yang sama dengan workload lainnya.
Jika node memiliki keterbatasan resource, Pod gateway jaringan mungkin akan dikeluarkan. Perilaku ini sangat buruk untuk ang-node
DaemonSet, karena Pod tersebut harus dijadwalkan pada node tertentu dan tidak dapat
dimigrasikan.
Solusi:
Upgrade ke versi 1.15 atau yang lebih baru.
Sebagai perbaikan jangka pendek, Anda dapat menetapkan PriorityClass ke komponen Gateway Jaringan Anthos secara manual. Pengontrol Google Distributed Cloud
menimpa perubahan manual ini selama proses rekonsiliasi, seperti
selama upgrade cluster.
- Tetapkan
system-cluster-critical PriorityClass ke Deployment pengontrol cluster ang-controller-manager dan autoscaler .
- Tetapkan PriorityClass
system-node-critical ke node ang-daemon DaemonSet.
|
Upgrade, Update |
1.12, 1.13, 1.14, 1.15.0-1.15.2 |
upgrade cluster admin gagal setelah mendaftarkan cluster ke gcloud
Setelah menggunakan gcloud untuk mendaftarkan cluster admin dengan bagian gkeConnect yang tidak kosong, Anda mungkin melihat error berikut saat mencoba mengupgrade cluster:
failed to register cluster: failed to apply Hub Mem\
bership: Membership API request failed: rpc error: code = InvalidArgument desc = InvalidFieldError for field endpoint.o\
n_prem_cluster.admin_cluster: field cannot be updated
Hapus namespace gke-connect :
kubectl delete ns gke-connect --kubeconfig=ADMIN_KUBECONFIG
Dapatkan nama cluster admin:
kubectl get onpremadmincluster -n kube-system --kubeconfig=ADMIN_KUBECONFIG
Hapus keanggotaan fleet:
gcloud container fleet memberships delete ADMIN_CLUSTER_NAME
dan lanjutkan upgrade cluster admin.
|
Operasi |
1.13.0-1.13.8, 1.14.0-1.14.5, 1.15.0-1.15.1 |
gkectl diagnose snapshot --log-since gagal membatasi jangka waktu untuk
perintah journalctl yang berjalan di node cluster
Hal ini tidak memengaruhi fungsi pengambilan snapshot cluster, karena snapshot masih menyertakan semua log yang dikumpulkan secara default dengan menjalankan journalctl di node cluster. Oleh karena itu,
tidak ada informasi proses debug yang terlewat.
|
Penginstalan, Upgrade, Update |
1,9+, 1,10+, 1,11+, 1,12+ |
gkectl prepare windows gagal
gkectl prepare windows gagal menginstal Docker pada versi Google Distributed Cloud yang lebih awal dari 1.13 karena MicrosoftDockerProvider sudah tidak digunakan lagi.
Solusi:
Ide umum untuk mengatasi masalah ini adalah dengan mengupgrade ke Google Distributed Cloud 1.13
dan menggunakan gkectl 1.13 untuk membuat template VM Windows, lalu
membuat node pool Windows. Ada dua opsi untuk membuka Google Distributed Cloud 1.13 dari versi Anda saat ini, seperti yang ditunjukkan di bawah ini.
Catatan: Kami memiliki opsi untuk menyelesaikan masalah ini pada versi Anda saat ini
tanpa harus mengupgrade hingga ke versi 1.13, tetapi akan memerlukan lebih banyak langkah
manual. Hubungi tim dukungan kami jika Anda ingin mempertimbangkan
opsi ini.
Opsi 1: Upgrade Biru/Hijau
Anda dapat membuat cluster baru menggunakan Google Distributed Cloud versi 1.13+ dengan node pool Windows, dan
memigrasikan workload Anda ke cluster baru, lalu membongkar cluster
saat ini. Sebaiknya gunakan Google Distributed Cloud versi minor terbaru.
Catatan: Anda akan memerlukan resource tambahan untuk menyediakan cluster baru, tetapi
mengurangi periode nonaktif dan gangguan untuk workload yang ada.
Opsi 2: Hapus node pool Windows dan tambahkan kembali saat mengupgrade ke Google Distributed Cloud 1.13
Catatan: Untuk opsi ini, workload Windows tidak akan dapat berjalan hingga cluster diupgrade ke 1.13 dan kumpulan node Windows ditambahkan kembali.
- Hapus kumpulan node Windows yang ada dengan menghapus konfigurasi node pool Windows dari file user-cluster.yaml, lalu jalankan perintah:
gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
- Upgrade cluster pengguna admin+khusus Linux ke versi 1.12 dengan mengikuti
panduan pengguna upgrade untuk target versi minor yang sesuai.
- (Pastikan untuk melakukan langkah ini sebelum mengupgrade ke 1.13) Pastikan
enableWindowsDataplaneV2: true dikonfigurasi di CR OnPremUserCluster . Jika tidak, cluster akan tetap menggunakan node pool Docker untuk Windows, yang tidak akan kompatibel dengan template VM Windows 1.13 yang baru dibuat dan belum menginstal Docker. Jika tidak dikonfigurasi atau disetel ke salah (false), perbarui cluster Anda untuk menyetelnya ke benar (true) di user-cluster.yaml, lalu jalankan:
gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
- Upgrade cluster admin+pengguna khusus Linux ke versi 1.13 dengan mengikuti
panduan pengguna upgrade.
- Siapkan template VM Windows menggunakan 1.13 gkectl:
gkectl prepare windows --base-vm-template BASE_WINDOWS_VM_TEMPLATE_NAME --bundle-path 1.13_BUNDLE_PATH --kubeconfig=ADMIN_KUBECONFIG
- Tambahkan kembali konfigurasi kumpulan node Windows ke user-cluster.yaml dengan kolom
OSImage yang ditetapkan ke template VM Windows yang baru dibuat.
- Update cluster untuk menambahkan kumpulan node Windows
gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
|
Penginstalan, Upgrade, Update |
1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1 |
Konfigurasi RootDistanceMaxSec tidak diterapkan untuk
ubuntu node
Nilai default 5 detik untuk RootDistanceMaxSec akan digunakan pada node, bukan 20 detik yang seharusnya merupakan konfigurasi yang diharapkan. Jika Anda memeriksa log startup node dengan melakukan SSH ke VM, yang terletak di `/var/log/startup.log`, Anda dapat menemukan error berikut:
+ has_systemd_unit systemd-timesyncd
/opt/bin/master.sh: line 635: has_systemd_unit: command not found
Penggunaan RootDistanceMaxSec selama 5 detik dapat menyebabkan jam
sistem tidak sinkron dengan server NTP saat penyimpangan jam lebih besar dari
5 detik.
Solusi:
Terapkan DaemonSet berikut ke cluster Anda untuk mengonfigurasi RootDistanceMaxSec :
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: change-root-distance
namespace: kube-system
spec:
selector:
matchLabels:
app: change-root-distance
template:
metadata:
labels:
app: change-root-distance
spec:
hostIPC: true
hostPID: true
tolerations:
# Make sure pods gets scheduled on all nodes.
- effect: NoSchedule
operator: Exists
- effect: NoExecute
operator: Exists
containers:
- name: change-root-distance
image: ubuntu
command: ["chroot", "/host", "bash", "-c"]
args:
- |
while true; do
conf_file="/etc/systemd/timesyncd.conf.d/90-gke.conf"
if [ -f $conf_file ] && $(grep -q "RootDistanceMaxSec=20" $conf_file); then
echo "timesyncd has the expected RootDistanceMaxSec, skip update"
else
echo "updating timesyncd config to RootDistanceMaxSec=20"
mkdir -p /etc/systemd/timesyncd.conf.d
cat > $conf_file << EOF
[Time]
RootDistanceMaxSec=20
EOF
systemctl restart systemd-timesyncd
fi
sleep 600
done
volumeMounts:
- name: host
mountPath: /host
securityContext:
privileged: true
volumes:
- name: host
hostPath:
path: /
|
Upgrade, Update |
1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2 |
gkectl update admin gagal karena kolom osImageType kosong
Saat menggunakan gkectl versi 1.13 untuk mengupdate cluster admin
versi 1.12, Anda mungkin melihat error berikut:
Failed to update the admin cluster: updating OS image type in admin cluster
is not supported in "1.12.x-gke.x"
Saat menggunakan gkectl update admin untuk cluster
versi 1.13 atau 1.14, Anda mungkin melihat pesan berikut dalam responsnya:
Exit with error:
Failed to update the cluster: the update contains multiple changes. Please
update only one feature at a time
Jika Anda memeriksa log gkectl , Anda mungkin melihat bahwa beberapa
perubahan menyertakan penetapan osImageType dari string kosong ke
ubuntu_containerd .
Error update ini disebabkan oleh pengisian ulang kolom osImageType yang tidak tepat di konfigurasi cluster admin sejak diperkenalkan di versi 1.9.
Solusi:
Upgrade ke versi Google Distributed Cloud setelah perbaikan. Jika upgrade
tidak memungkinkan bagi Anda, hubungi Cloud Customer Care untuk menyelesaikan masalah ini.
|
Pemasangan, Keamanan |
1.13, 1.14, 1.15, 1.16 |
SNI tidak berfungsi pada cluster pengguna dengan Controlplane V2
Kemampuan memberikan sertifikat penayangan tambahan untuk
server Kubernetes API cluster pengguna dengan
authentication.sni tidak akan berfungsi jika Controlplane V2
diaktifkan (
enableControlplaneV2: true ).
Solusi:
Hingga patch Google Distributed Cloud tersedia dengan perbaikan, jika Anda
perlu menggunakan SNI, nonaktifkan Controlplane V2 (enableControlplaneV2: false ).
|
Penginstalan |
1.0-1.11, 1.12, 1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1 |
$ di nama pengguna registry pribadi menyebabkan kegagalan startup mesin bidang kontrol admin
Mesin bidang kontrol admin gagal dimulai saat nama pengguna registry pribadi berisi $ .
Saat memeriksa /var/log/startup.log di mesin bidang kontrol admin, Anda akan melihat error berikut:
++ REGISTRY_CA_CERT=xxx
++ REGISTRY_SERVER=xxx
/etc/startup/startup.conf: line 7: anthos: unbound variable
Solusi:
Gunakan nama pengguna registry pribadi tanpa $ , atau gunakan versi Google Distributed Cloud dengan perbaikannya.
|
Upgrade, Update |
1.12.0-1.12.4 |
Peringatan positif palsu tentang perubahan yang tidak didukung selama update cluster admin
Saat
mengupdate cluster admin, Anda akan melihat peringatan positif palsu berikut di log, dan Anda dapat mengabaikannya.
console.go:47] detected unsupported changes: &v1alpha1.OnPremAdminCluster{
...
- CARotation: &v1alpha1.CARotationConfig{Generated: &v1alpha1.CARotationGenerated{CAVersion: 1}},
+ CARotation: nil,
...
}
|
Upgrade, Update |
1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1 |
Update cluster pengguna gagal setelah rotasi kunci penandatanganan KSA
Setelah Anda memutar
kunci penandatanganan KSA, lalu
memperbarui cluster pengguna, gkectl update mungkin gagal dengan
pesan error berikut:
Failed to apply OnPremUserCluster 'USER_CLUSTER_NAME-gke-onprem-mgmt/USER_CLUSTER_NAME':
admission webhook "vonpremusercluster.onprem.cluster.gke.io" denied the request:
requests must not decrement *v1alpha1.KSASigningKeyRotationConfig Version, old version: 2, new version: 1"
Solusi:
Ubah versi kunci penandatanganan KSA Anda kembali ke 1, tetapi pertahankan data kunci terbaru:
- Periksa rahasia di cluster admin pada namespace
USER_CLUSTER_NAME , dan dapatkan nama rahasia kunci penandatanganan ksa:
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME get secrets | grep ksa-signing-key
- Salin rahasia kunci penandatanganan ksa, dan beri nama rahasia yang disalin sebagai service-account-cert:
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME get secret KSA-KEY-SECRET-NAME -oyaml | \
sed 's/ name: .*/ name: service-account-cert/' | \
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME apply -f -
- Hapus rahasia kunci penandatanganan ksa sebelumnya:
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME delete secret KSA-KEY-SECRET-NAME
- Perbarui kolom
data.data di configmap ksa-signed-key-rotation-stage menjadi '{"tokenVersion":1,"privateKeyVersion":1,"publicKeyVersions":[1]}' :
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME \
edit configmap ksa-signing-key-rotation-stage
- Nonaktifkan webhook validasi untuk mengedit informasi versi di resource kustom OnPremUserCluster:
kubectl --kubeconfig=ADMIN_KUBECONFIG patch validatingwebhookconfiguration onprem-user-cluster-controller -p '
webhooks:
- name: vonpremnodepool.onprem.cluster.gke.io
rules:
- apiGroups:
- onprem.cluster.gke.io
apiVersions:
- v1alpha1
operations:
- CREATE
resources:
- onpremnodepools
- name: vonpremusercluster.onprem.cluster.gke.io
rules:
- apiGroups:
- onprem.cluster.gke.io
apiVersions:
- v1alpha1
operations:
- CREATE
resources:
- onpremuserclusters
'
- Perbarui kolom
spec.ksaSigningKeyRotation.generated.ksaSigningKeyRotation menjadi 1 di resource kustom OnPremUserCluster Anda:
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME-gke-onprem-mgmt \
edit onpremusercluster USER_CLUSTER_NAME
- Tunggu hingga cluster pengguna target siap, Anda dapat memeriksa statusnya dengan:
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME-gke-onprem-mgmt \
get onpremusercluster
- Pulihkan webhook validasi untuk cluster pengguna:
kubectl --kubeconfig=ADMIN_KUBECONFIG patch validatingwebhookconfiguration onprem-user-cluster-controller -p '
webhooks:
- name: vonpremnodepool.onprem.cluster.gke.io
rules:
- apiGroups:
- onprem.cluster.gke.io
apiVersions:
- v1alpha1
operations:
- CREATE
- UPDATE
resources:
- onpremnodepools
- name: vonpremusercluster.onprem.cluster.gke.io
rules:
- apiGroups:
- onprem.cluster.gke.io
apiVersions:
- v1alpha1
operations:
- CREATE
- UPDATE
resources:
- onpremuserclusters
'
- Hindari rotasi kunci penandatanganan KSA lainnya hingga cluster
diupgrade ke versi yang memiliki perbaikan.
|
Operasi |
1.13.1+, 1.14, 1., 1.16 |
Saat Anda menggunakan Terraform untuk menghapus cluster pengguna dengan load balancer F5 BIG-IP, server virtual F5 BIG-IP tidak akan dihapus setelah cluster dihapus.
Solusi:
Untuk menghapus resource F5, ikuti langkah-langkah untuk
membersihkan partisi cluster F5 pengguna
|
Penginstalan, Upgrade, Update |
1.13.8, 1.14.4 |
jenis cluster mengambil image container dari docker.io
Jika Anda membuat cluster admin versi 1.13.8 atau versi 1.14.4, atau
mengupgrade cluster admin ke versi 1.13.8 atau 1.14.4, cluster jenis akan mengambil
image container berikut dari docker.io :
docker.io/kindest/kindnetd
docker.io/kindest/local-path-provisioner
docker.io/kindest/local-path-helper
Jika docker.io tidak dapat diakses dari workstation admin Anda, pembuatan atau upgrade cluster admin akan gagal menampilkan cluster jenis tersebut.
Menjalankan perintah berikut di workstation admin akan menampilkan
container terkait yang tertunda dengan ErrImagePull :
docker exec gkectl-control-plane kubectl get pods -A
Respons berisi entri seperti berikut:
...
kube-system kindnet-xlhmr 0/1
ErrImagePull 0 3m12s
...
local-path-storage local-path-provisioner-86666ffff6-zzqtp 0/1
Pending 0 3m12s
...
Image container ini harus dipramuat di image container cluster jenis. Namun, jenis v0.18.0 memiliki
masalah dengan image container yang dimuat sebelumnya,
yang menyebabkan image tersebut ditarik dari internet secara tidak sengaja.
Solusi:
Jalankan perintah berikut di workstation admin, sementara cluster admin Anda masih dalam proses pembuatan atau upgrade:
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/kindnetd:v20230330-48f316cd@sha256:c19d6362a6a928139820761475a38c24c0cf84d507b9ddf414a078cf627497af docker.io/kindest/kindnetd:v20230330-48f316cd
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/kindnetd:v20230330-48f316cd@sha256:c19d6362a6a928139820761475a38c24c0cf84d507b9ddf414a078cf627497af docker.io/kindest/kindnetd@sha256:c19d6362a6a928139820761475a38c24c0cf84d507b9ddf414a078cf627497af
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-helper:v20230330-48f316cd@sha256:135203f2441f916fb13dad1561d27f60a6f11f50ec288b01a7d2ee9947c36270 docker.io/kindest/local-path-helper:v20230330-48f316cd
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-helper:v20230330-48f316cd@sha256:135203f2441f916fb13dad1561d27f60a6f11f50ec288b01a7d2ee9947c36270 docker.io/kindest/local-path-helper@sha256:135203f2441f916fb13dad1561d27f60a6f11f50ec288b01a7d2ee9947c36270
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-provisioner:v0.0.23-kind.0@sha256:f2d0a02831ff3a03cf51343226670d5060623b43a4cfc4808bd0875b2c4b9501 docker.io/kindest/local-path-provisioner:v0.0.23-kind.0
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-provisioner:v0.0.23-kind.0@sha256:f2d0a02831ff3a03cf51343226670d5060623b43a4cfc4808bd0875b2c4b9501 docker.io/kindest/local-path-provisioner@sha256:f2d0a02831ff3a03cf51343226670d5060623b43a4cfc4808bd0875b2c4b9501
|
Operasi |
1.13.0-1.13.7, 1.14.0-1.14.4, 1.15.0 |
Failover gagal pada cluster pengguna HA Controlplane V2 dan cluster admin saat jaringan memfilter permintaan GARP duplikat
Jika VM cluster Anda terhubung dengan switch yang memfilter permintaan GARP (ARP) duplikat, pemilihan pimpinan tetap mungkin mengalami kondisi race, yang menyebabkan beberapa node memiliki entri tabel ARP yang salah.
Node yang terpengaruh dapat melakukan ping VIP bidang kontrol, tetapi waktu tunggu koneksi TCP ke VIP bidang kontrol
akan habis.
Solusi:
Jalankan perintah berikut di setiap node bidang kontrol dari cluster yang terpengaruh:
iptables -I FORWARD -i ens192 --destination CONTROL_PLANE_VIP -j DROP
|
Upgrade, Update |
1.13.0-1.13.7, 1.14.0-1.14.4, 1.15.0 |
vsphere-csi-controller harus dimulai ulang setelah rotasi sertifikat vCenter
vsphere-csi-controller harus memuat ulang rahasia vCenter-nya setelah rotasi sertifikat vCenter. Namun, sistem saat ini tidak memulai ulang pod vsphere-csi-controller dengan benar, sehingga menyebabkan vsphere-csi-controller error setelah rotasi.
Solusi:
Untuk cluster yang dibuat di versi 1.13 dan yang lebih baru, ikuti petunjuk di bawah untuk memulai ulang vsphere-csi-controller
kubectl --kubeconfig=ADMIN_KUBECONFIG rollout restart deployment vsphere-csi-controller -n kube-system
|
Penginstalan |
1.10.3-1.10.7, 1.11, 1.12, 1.13.0-1.13.1 |
Pembuatan cluster admin tidak gagal saat terjadi error pendaftaran cluster
Meskipun
pendaftaran cluster gagal selama pembuatan cluster admin, perintah gkectl create admin tidak akan gagal saat terjadi error dan mungkin berhasil. Dengan kata lain, pembuatan cluster admin dapat "berhasil" tanpa didaftarkan ke fleet.
Untuk mengidentifikasi gejala, Anda dapat mencari pesan error berikut dalam log `gkectl create admin`,
Failed to register admin cluster
Anda juga dapat memeriksa apakah dapat menemukan cluster di antara cluster terdaftar di Cloud Console.
Solusi:
Untuk cluster yang dibuat pada versi 1.12 dan yang lebih baru, ikuti petunjuk untuk mencoba kembali pendaftaran cluster admin setelah pembuatan cluster. Untuk cluster yang dibuat pada versi sebelumnya,
-
Tambahkan pasangan nilai kunci palsu seperti "foo: bar" ke file kunci SA Connect Register Anda
-
Jalankan
gkectl update admin untuk mendaftarkan ulang cluster admin.
|
Upgrade, Update |
1.10, 1.11, 1.12, 1.13.0-1.13.1 |
Pendaftaran ulang cluster admin mungkin dilewati selama upgrade cluster admin
Selama upgrade cluster admin, jika waktu upgrade node bidang kontrol pengguna habis, cluster admin tidak akan didaftarkan ulang dengan versi agen koneksi yang telah diupdate.
Solusi:
Periksa apakah cluster ditampilkan di antara cluster yang terdaftar.
Sebagai langkah opsional, Login ke cluster setelah menyiapkan autentikasi. Jika cluster masih terdaftar, Anda dapat melewati petunjuk berikut untuk mencoba kembali pendaftaran.
Untuk cluster yang diupgrade ke versi 1.12 dan yang lebih baru, ikuti petunjuk untuk mencoba kembali pendaftaran cluster admin setelah pembuatan cluster. Untuk cluster yang diupgrade ke versi sebelumnya,
-
Tambahkan pasangan nilai kunci palsu seperti "foo: bar" ke file kunci SA Connect Register Anda
-
Jalankan
gkectl update admin untuk mendaftarkan ulang cluster admin.
|
Configuration |
1.15.0 |
Pesan error palsu tentang vCenter.dataDisk
Untuk cluster admin dengan ketersediaan tinggi, gkectl prepare menampilkan pesan error palsu ini:
vCenter.dataDisk must be present in the AdminCluster spec
Solusi:
Anda dapat mengabaikan pesan error ini dengan aman.
|
VMware |
1.15.0 |
Pembuatan kumpulan node gagal karena aturan afinitas Host VM yang redundan
Selama pembuatan kumpulan node yang menggunakan
afinitas Host VM,
kondisi race dapat mengakibatkan beberapa
aturan afinitas Host VM
dibuat dengan nama yang sama. Hal ini dapat menyebabkan pembuatan kumpulan node gagal.
Solusi:
Hapus aturan redundan lama agar pembuatan kumpulan node dapat dilanjutkan.
Aturan ini diberi nama [USER_CLUSTER_NAME]-[HASH].
|
Operasi |
1.15.0 |
gkectl repair admin-master mungkin gagal karena failed
to delete the admin master node object and reboot the admin master VM
Perintah gkectl repair admin-master dapat gagal karena kondisi race dengan error berikut.
Failed to repair: failed to delete the admin master node object and reboot the admin master VM
Solusi:
Perintah ini bersifat idempoten. API ini dapat dijalankan kembali dengan aman hingga perintah
berhasil.
|
Upgrade, Update |
1.15.0 |
Pod tetap dalam status Gagal setelah pembuatan ulang atau update node bidang kontrol
Setelah Anda membuat ulang atau mengupdate node bidang kontrol, Pod tertentu mungkin dibiarkan dalam status Failed karena kegagalan predikat NodeAffinity. Pod yang gagal ini tidak memengaruhi health atau operasi cluster normal.
Solusi:
Anda dapat mengabaikan Pod yang gagal dengan aman atau menghapusnya secara manual.
|
Keamanan, Konfigurasi |
1.15.0-1.15.1 |
OnPremUserCluster tidak siap karena kredensial registry pribadi
Jika Anda menggunakan kredensial yang disiapkan dan registry pribadi, tetapi belum mengonfigurasi kredensial yang disiapkan untuk registry pribadi Anda, OnPremUserCluster mungkin belum siap, dan Anda mungkin melihat pesan error berikut:
failed to check secret reference for private registry …
Solusi:
Siapkan kredensial registry pribadi untuk cluster pengguna sesuai dengan petunjuk dalam Mengonfigurasi kredensial yang disiapkan.
|
Upgrade, Update |
1.15.0 |
Selama gkectl upgrade admin , pemeriksaan preflight penyimpanan untuk Migrasi CSI memverifikasi bahwa StorageClasses tidak memiliki parameter yang diabaikan setelah Migrasi CSI.
Misalnya, jika ada StorageClass dengan parameter diskformat ,
gkectl upgrade admin akan menandai StorageClass dan melaporkan kegagalan dalam validasi preflight.
Cluster admin yang dibuat di Google Distributed Cloud 1.10 dan sebelumnya memiliki StorageClass dengan diskformat: thin
yang akan menggagalkan validasi ini, tetapi StorageClass ini masih berfungsi
dengan baik setelah Migrasi CSI. Kegagalan ini harus ditafsirkan sebagai peringatan.
Untuk informasi selengkapnya, periksa bagian parameter StorageClass di Memigrasikan Volume vSphere In-Tree ke Plugin Penyimpanan Container vSphere.
Solusi:
Setelah mengonfirmasi bahwa cluster Anda memiliki StorageClass dengan parameter yang diabaikan setelah Migrasi CSI
menjalankan gkectl upgrade admin dengan flag --skip-validation-cluster-health .
|
Penyimpanan |
1,15, 1,16 |
Volume vSphere dalam pohon yang dimigrasikan menggunakan sistem file Windows tidak dapat digunakan dengan driver CSI vSphere
Dalam kondisi tertentu, disk dapat dipasang sebagai hanya baca ke node Windows. Hal ini menyebabkan volume terkait bersifat hanya baca di dalam Pod.
Masalah ini kemungkinan besar terjadi saat kumpulan node baru menggantikan kumpulan node lama (misalnya, upgrade cluster atau pembaruan kumpulan node). Workload stateful yang sebelumnya berfungsi dengan baik mungkin tidak dapat menulis ke volumenya di kumpulan node baru.
Solusi:
-
Dapatkan UID Pod yang tidak dapat menulis ke volumenya:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pod \
POD_NAME --namespace POD_NAMESPACE \
-o=jsonpath='{.metadata.uid}{"\n"}'
-
Gunakan PersistentVolumeKlaim untuk mendapatkan nama PersistentVolume:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pvc \
PVC_NAME --namespace POD_NAMESPACE \
-o jsonpath='{.spec.volumeName}{"\n"}'
-
Tentukan nama node tempat Pod dijalankan:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIGget pods \
--namespace POD_NAMESPACE \
-o jsonpath='{.spec.nodeName}{"\n"}'
-
Dapatkan akses powershell ke node, baik melalui SSH maupun antarmuka web vSphere.
-
Menetapkan variabel lingkungan:
PS C:\Users\administrator> pvname=PV_NAME
PS C:\Users\administrator> podid=POD_UID
- Identifikasi nomor disk untuk disk yang terkait dengan PersistentVolume:
PS C:\Users\administrator> disknum=(Get-Partition -Volume (Get-Volume -UniqueId ("\\?\"+(Get-Item (Get-Item
"C:\var\lib\kubelet\pods\$podid\volumes\kubernetes.io~csi\$pvname\mount").Target).Target))).DiskNumber
-
Verifikasi bahwa disk tersebut adalah
readonly :
PS C:\Users\administrator> (Get-Disk -Number $disknum).IsReadonly
Hasilnya seharusnya True .
- Tetapkan
readonly ke false .
PS C:\Users\administrator> Set-Disk -Number $disknum -IsReadonly $false
PS C:\Users\administrator> (Get-Disk -Number $disknum).IsReadonly
-
Hapus Pod agar dapat dimulai ulang:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete pod POD_NAME \
--namespace POD_NAMESPACE
-
Pod akan dijadwalkan ke node yang sama. Namun, jika Pod dijadwalkan ke node baru, Anda mungkin perlu mengulangi langkah-langkah sebelumnya pada node baru.
|
Upgrade, Update |
1.12, 1.13.0-1.13.7, 1.14.0-1.14.4 |
vsphere-csi-secret tidak diupdate setelah gkectl update credentials vsphere --admin-cluster
Jika Anda memperbarui kredensial vSphere untuk cluster admin setelah
memperbarui kredensial cluster,
Anda mungkin melihat vsphere-csi-secret pada namespace kube-system di cluster admin masih menggunakan kredensial lama.
Solusi:
- Dapatkan nama rahasia
vsphere-csi-secret :
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system get secrets | grep vsphere-csi-secret
- Perbarui data rahasia
vsphere-csi-secret yang Anda dapatkan dari langkah di atas:
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system patch secret CSI_SECRET_NAME -p \
"{\"data\":{\"config\":\"$( \
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system get secrets CSI_SECRET_NAME -ojsonpath='{.data.config}' \
| base64 -d \
| sed -e '/user/c user = \"VSPHERE_USERNAME_TO_BE_UPDATED\"' \
| sed -e '/password/c password = \"VSPHERE_PASSWORD_TO_BE_UPDATED\"' \
| base64 -w 0 \
)\"}}"
- Mulai ulang
vsphere-csi-controller :
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system rollout restart deployment vsphere-csi-controller
- Anda dapat melacak status peluncuran dengan:
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system rollout status deployment vsphere-csi-controller
Setelah deployment berhasil diluncurkan, vsphere-csi-secret yang telah diupdate harus digunakan oleh pengontrol.
|
Upgrade, Update |
1.10, 1.11, 1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2 |
audit-proxy errorloop saat mengaktifkan Cloud Audit Logs dengan gkectl update cluster
audit-proxy mungkin errorloop karena --cluster-name kosong.
Perilaku ini disebabkan oleh bug dalam logika update, yang membuat nama cluster tidak disebarkan ke manifes pod / container audit-proxy.
Solusi:
Untuk cluster pengguna bidang kontrol v2 dengan enableControlplaneV2: true , hubungkan ke mesin bidang kontrol pengguna menggunakan SSH,
dan update /etc/kubernetes/manifests/audit-proxy.yaml dengan --cluster_name=USER_CLUSTER_NAME .
Untuk cluster pengguna bidang kontrol v1, edit penampung audit-proxy di
statefulset kube-apiserver untuk menambahkan --cluster_name=USER_CLUSTER_NAME :
kubectl edit statefulset kube-apiserver -n USER_CLUSTER_NAME --kubeconfig=ADMIN_CLUSTER_KUBECONFIG
|
Upgrade, Update |
1.11, 1.12, 1.13.0-1.13.5, 1.14.0-1.14.1 |
Deployment ulang bidang kontrol tambahan tepat setelah gkectl upgrade cluster
Tepat setelah gkectl upgrade cluster , pod bidang kontrol dapat di-deploy ulang lagi.
Status cluster dari gkectl list clusters berubah dari RUNNING menjadi RECONCILING .
Permintaan ke cluster pengguna mungkin kehabisan waktu.
Perilaku ini terjadi karena rotasi sertifikat bidang kontrol terjadi secara otomatis setelah
gkectl upgrade cluster .
Masalah ini hanya terjadi pada cluster pengguna yang TIDAK menggunakan bidang kontrol v2.
Solusi:
Tunggu hingga status cluster berubah kembali menjadi RUNNING di gkectl list clusters , atau
upgrade ke versi yang memiliki perbaikan: 1.13.6+, 1.14.2+, atau 1.15+.
|
Upgrade, Update |
1.12.7 |
Rilis buruk 1.12.7-gke.19 telah dihapus
Google Distributed Cloud 1.12.7-gke.19 adalah rilis yang buruk dan Anda sebaiknya tidak menggunakannya. Artefak telah dihapus dari bucket Cloud Storage.
Solusi:
Gunakan rilis 1.12.7-gke.20 sebagai gantinya.
|
Upgrade, Update |
1.12.0+, 1.13.0-1.13.7, 1.14.0-1.14.3 |
gke-connect-agent
terus menggunakan image lama setelah kredensial registry diperbarui
Jika Anda memperbarui kredensial registry menggunakan salah satu metode berikut:
gkectl update credentials componentaccess jika tidak menggunakan registry pribadi
gkectl update credentials privateregistry jika menggunakan registry pribadi
Anda mungkin mendapati gke-connect-agent terus menggunakan image lama
atau pod gke-connect-agent tidak dapat diambil karena
ImagePullBackOff .
Masalah ini akan diperbaiki dalam rilis Google Distributed Cloud 1.13.8, 1.14.4, dan rilis berikutnya.
Solusi:
Opsi 1: Deploy ulang gke-connect-agent secara manual:
- Hapus namespace
gke-connect :
kubectl --kubeconfig=KUBECONFIG delete namespace gke-connect
- Deploy ulang
gke-connect-agent dengan kunci akun layanan pendaftaran yang asli (tidak perlu memperbarui kunci):
Untuk cluster admin:
gkectl update credentials register --kubeconfig=ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG_FILE --admin-cluster
Untuk cluster pengguna:
gkectl update credentials register --kubeconfig=ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
Opsi 2: Anda dapat secara manual mengubah data image pull secret regcred yang digunakan oleh deployment gke-connect-agent :
kubectl --kubeconfig=KUBECONFIG -n=gke-connect patch secrets regcred -p "{\"data\":{\".dockerconfigjson\":\"$(kubectl --kubeconfig=KUBECONFIG -n=kube-system get secrets private-registry-creds -ojsonpath='{.data.\.dockerconfigjson}')\"}}"
Opsi 3: Anda dapat menambahkan rahasia pull image default untuk cluster dalam deployment gke-connect-agent dengan:
- Salin secret default ke namespace
gke-connect :
kubectl --kubeconfig=KUBECONFIG -n=kube-system get secret private-registry-creds -oyaml | sed 's/ namespace: .*/ namespace: gke-connect/' | kubectl --kubeconfig=KUBECONFIG -n=gke-connect apply -f -
- Dapatkan nama deployment
gke-connect-agent :
kubectl --kubeconfig=KUBECONFIG -n=gke-connect get deployment | grep gke-connect-agent
- Tambahkan rahasia default ke deployment
gke-connect-agent :
kubectl --kubeconfig=KUBECONFIG -n=gke-connect patch deployment DEPLOYMENT_NAME -p '{"spec":{"template":{"spec":{"imagePullSecrets": [{"name": "private-registry-creds"}, {"name": "regcred"}]}}}}'
|
Penginstalan |
1,13, 1,14 |
Kegagalan pemeriksaan konfigurasi LB manual
Jika Anda memvalidasi konfigurasi sebelum membuat cluster dengan Load balancer manual dengan menjalankan gkectl check-config , perintah akan gagal dengan pesan error berikut.
- Validation Category: Manual LB Running validation check for "Network
configuration"...panic: runtime error: invalid memory address or nil pointer
dereference
Solusi:
Opsi 1: Anda dapat menggunakan patch versi 1.13.7 dan 1.14.4 yang akan menyertakan perbaikan.
Opsi 2: Anda juga dapat menjalankan perintah yang sama untuk memvalidasi konfigurasi, tetapi melewati validasi load balancer.
gkectl check-config --skip-validation-load-balancer
|
Operasi |
1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13, dan 1.14 |
dll. kelaparan smartwatch
Cluster yang menjalankan dlld versi 3.4.13 atau yang lebih lama mungkin mengalami
kelaparan menonton dan pantauan resource non-operasional, yang dapat menyebabkan
masalah berikut:
- Penjadwalan pod terganggu
- Node tidak dapat didaftarkan
- kubelet tidak mengamati perubahan pod
Masalah ini dapat menyebabkan cluster tidak berfungsi.
Masalah ini telah diperbaiki dalam rilis Google Distributed Cloud 1.12.7, 1.13.6,
1.14.3, dan rilis berikutnya. Rilis yang lebih baru ini menggunakan etcd versi 3.4.21. Semua versi Google Distributed Cloud sebelumnya terpengaruh oleh
masalah ini.
Solusi
Jika tidak dapat segera melakukan upgrade, Anda dapat mengurangi risiko kegagalan cluster dengan mengurangi jumlah node dalam cluster. Hapus node hingga metrik etcd_network_client_grpc_sent_bytes_total kurang dari 300 MBps.
Untuk melihat metrik ini di Metrics Explorer:
- Buka Metrics Explorer di konsol Google Cloud:
Buka Metrics Explorer
- Pilih tab Configuration
- Luaskan Select a metric, masukkan
Kubernetes Container
di panel filter, lalu gunakan submenu untuk memilih metrik:
- Di menu Active resources, pilih Kubernetes Container.
- Di menu Active metric categories, pilih Anthos.
- Di menu Active metrics, pilih
etcd_network_client_grpc_sent_bytes_total .
- Klik Terapkan.
|
Upgrade, Update |
1.10, 1.11, 1.12, 1.13, dan 1.14 |
GKE Identity Service dapat menyebabkan latensi bidang kontrol
Saat cluster dimulai ulang atau diupgrade, GKE Identity Service dapat kewalahan dengan traffic yang terdiri dari token JWT yang sudah tidak berlaku dan diteruskan dari kube-apiserver ke GKE Identity Service melalui webhook autentikasi. Meskipun tidak menjalankan
crashloop, GKE Identity Service akan menjadi tidak responsif dan berhenti melayani permintaan lebih lanjut.
Masalah ini pada akhirnya menyebabkan latensi bidang kontrol yang lebih tinggi.
Masalah ini telah diperbaiki dalam rilis Google Distributed Cloud berikut:
Untuk mengetahui apakah Anda terpengaruh oleh masalah ini, lakukan langkah-langkah berikut:
- Periksa apakah endpoint GKE Identity Service dapat dijangkau secara eksternal:
curl -s -o /dev/null -w "%{http_code}" \
-X POST https://CLUSTER_ENDPOINT/api/v1/namespaces/anthos-identity-service/services/https:ais:https/proxy/authenticate -d '{}'
Ganti CLUSTER_ENDPOINT dengan port load balancer bidang kontrol dan VIP bidang kontrol untuk cluster Anda (misalnya, 172.16.20.50:443 ).
Jika Anda terpengaruh oleh masalah ini, perintah tersebut akan menampilkan kode status 400 . Jika waktu permintaan habis, mulai ulang Pod ais dan jalankan kembali perintah curl untuk melihat apakah tindakan tersebut menyelesaikan masalah. Jika Anda mendapatkan kode status 000 , masalah telah teratasi dan Anda sudah selesai. Jika Anda masih mendapatkan kode status 400 , server HTTP GKE Identity Service tidak dimulai. Jika demikian, lanjutkan.
- Periksa log kube-apiserver dan GKE Identity Service:
- Periksa log GKE Identity Service:
kubectl logs -f -l k8s-app=ais -n anthos-identity-service \
--kubeconfig KUBECONFIG
Jika log berisi entri seperti berikut, berarti Anda terpengaruh oleh masalah ini:
I0811 22:32:03.583448 32 authentication_plugin.cc:295] Stopping OIDC authentication for ???. Unable to verify the OIDC ID token: JWT verification failed: The JWT does not appear to be from this identity provider. To match this provider, the 'aud' claim must contain one of the following audiences:
- Periksa log
kube-apiserver untuk cluster Anda:
Dalam perintah berikut, KUBE_APISERVER_POD adalah nama Pod kube-apiserver di cluster yang diberikan.
Cluster Admin:
kubectl --kubeconfig ADMIN_KUBECONFIG logs \
-n kube-system KUBE_APISERVER_POD kube-apiserver
Cluster pengguna:
kubectl --kubeconfig ADMIN_KUBECONFIG logs \
-n USER_CLUSTER_NAME KUBE_APISERVER_POD kube-apiserver
Jika log kube-apiserver berisi entri seperti berikut, berarti Anda terpengaruh oleh masalah ini:
E0811 22:30:22.656085 1 webhook.go:127] Failed to make webhook authenticator request: error trying to reach service: net/http: TLS handshake timeout
E0811 22:30:22.656266 1 authentication.go:63] "Unable to authenticate the request" err="[invalid bearer token, error trying to reach service: net/http: TLS handshake timeout]"
Solusi
Jika tidak dapat segera mengupgrade cluster Anda untuk mendapatkan perbaikan, Anda dapat mengidentifikasi dan memulai ulang pod yang bermasalah sebagai solusi:
- Tingkatkan level verbositas GKE Identity Service ke 9:
kubectl patch deployment ais -n anthos-identity-service --type=json \
-p='[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", \
"value":"--vmodule=cloud/identity/hybrid/charon/*=9"}]' \
--kubeconfig KUBECONFIG
- Periksa log GKE Identity Service untuk konteks token yang tidak valid:
kubectl logs -f -l k8s-app=ais -n anthos-identity-service \
--kubeconfig KUBECONFIG
- Untuk mendapatkan payload token yang terkait dengan setiap konteks token yang tidak valid, urai setiap rahasia akun layanan terkait dengan perintah berikut:
kubectl -n kube-system get secret SA_SECRET \
--kubeconfig KUBECONFIG \
-o jsonpath='{.data.token}' | base64 --decode
- Untuk mendekode token serta melihat nama pod sumber dan namespace, salin token ke debugger di jwt.io.
- Mulai ulang pod yang diidentifikasi dari token.
|
Operasi |
1.8, 1.9, 1.10 |
Masalah peningkatan penggunaan memori pada pod pemeliharaan etcd
Pod pemeliharaan etcd yang menggunakan image etcddefrag:gke_master_etcddefrag_20210211.00_p0 akan terpengaruh. Container `etcddefrag` membuka koneksi baru ke server etcd selama setiap siklus defrag dan koneksi lama tidak dibersihkan.
Solusi:
Opsi 1: Upgrade ke versi patch terbaru dari 1.8 ke 1.11 yang berisi perbaikan.
Opsi 2: Jika Anda menggunakan versi patch yang lebih lama dari 1.9.6 dan 1.10.3, Anda perlu menurunkan skala pod pemeliharaan etcd untuk admin dan cluster pengguna:
kubectl scale --replicas 0 deployment/gke-master-etcd-maintenance -n USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG
kubectl scale --replicas 0 deployment/gke-master-etcd-maintenance -n kube-system --kubeconfig ADMIN_CLUSTER_KUBECONFIG
|
Operasi |
1.9, 1.10, 1.11, 1.12, 1.13 |
Melewatkan health check pod bidang kontrol cluster pengguna
Pengontrol kondisi cluster dan perintah gkectl diagnose cluster melakukan serangkaian health check, termasuk health check pod di seluruh namespace. Namun, pod mulai melewati pod bidang kontrol pengguna secara tidak sengaja. Mode bidang kontrol v2 tidak akan memengaruhi cluster Anda.
Solusi:
Hal ini tidak akan memengaruhi pengelolaan cluster atau workload apa pun. Jika ingin memeriksa kondisi pod bidang kontrol, Anda dapat menjalankan perintah berikut:
kubectl get pods -owide -n USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG
|
Upgrade, Update |
1,6+, 1,7+ |
Upgrade cluster admin 1.6 dan 1.7 mungkin terpengaruh oleh pengalihan k8s.gcr.io -> registry.k8s.io
Kubernetes mengalihkan traffic dari k8s.gcr.io ke registry.k8s.io pada 20/3/2023. Di Google Distributed Cloud 1.6.x dan 1.7.x, upgrade cluster admin menggunakan image container k8s.gcr.io/pause:3.2 . Jika Anda menggunakan proxy untuk workstation admin dan proxy tidak mengizinkan registry.k8s.io serta image container k8s.gcr.io/pause:3.2 tidak di-cache secara lokal, upgrade cluster admin akan gagal saat mengambil image container.
Solusi:
Tambahkan registry.k8s.io ke daftar proxy yang diizinkan untuk workstation admin Anda.
|
Networking |
1.10, 1.11, 1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2 |
Melihat kegagalan validasi pada pembuatan load balancer
gkectl create loadbalancer gagal dengan pesan error berikut:
- Validation Category: Seesaw LB - [FAILURE] Seesaw validation: xxx cluster lb health check failed: LB"xxx.xxx.xxx.xxx" is not healthy: Get "http://xxx.xxx.xxx.xxx:xxx/healthz": dial tcpxxx.xxx.xxx.xxx:xxx: connect: no route to host
Hal ini terjadi karena file grup jungkat-jungkit sudah ada. Dan pemeriksaan preflight mencoba memvalidasi load balancer jungkat-jungkit yang tidak ada.
Solusi:
Hapus file grup jungkat-jungkit yang ada untuk cluster ini. Nama filenya adalah seesaw-for-gke-admin.yaml untuk cluster admin, dan seesaw-for-{CLUSTER_NAME}.yaml untuk cluster pengguna.
|
Networking |
1,14 |
Waktu tunggu aplikasi yang disebabkan oleh kegagalan penyisipan tabel conntrack
Google Distributed Cloud versi 1.14 rentan terhadap kegagalan penyisipan tabel pelacakan koneksi netfilter (conntrack) saat menggunakan image sistem operasi Ubuntu atau COS. Kegagalan penyisipan menyebabkan waktu tunggu aplikasi acak habis dan dapat terjadi meskipun tabel conntrack memiliki ruang untuk entri baru. Kegagalan disebabkan oleh perubahan pada kernel 5.15 dan yang lebih baru yang membatasi penyisipan tabel berdasarkan panjang rantai.
Untuk melihat apakah Anda terpengaruh oleh masalah ini, periksa statistik sistem pelacakan koneksi dalam kernel di setiap node dengan perintah berikut:
sudo conntrack -S
Responsnya akan terlihat seperti ini:
cpu=0 found=0 invalid=4 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=1 found=0 invalid=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=2 found=0 invalid=16 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=3 found=0 invalid=13 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=4 found=0 invalid=9 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=5 found=0 invalid=1 insert=0 insert_failed=0 drop=0 early_drop=0 error=519 search_restart=0 clash_resolve=126 chaintoolong=0
...
Jika nilai chaintoolong dalam respons bukan angka
nol, Anda akan terpengaruh oleh masalah ini.
Solusi
Mitigasi jangka pendeknya adalah dengan menambah ukuran tabel hash netfiler (nf_conntrack_buckets ) dan tabel pelacakan koneksi netfilter (nf_conntrack_max ). Gunakan perintah berikut pada setiap node cluster untuk memperbesar ukuran tabel:
sysctl -w net.netfilter.nf_conntrack_buckets=TABLE_SIZE
sysctl -w net.netfilter.nf_conntrack_max=TABLE_SIZE
Ganti TABLE_SIZE dengan ukuran baru dalam byte. Nilai
ukuran tabel default adalah 262144 . Sebaiknya tetapkan nilai yang sama dengan 65.536 dikalikan dengan jumlah core pada node. Misalnya,
jika node Anda memiliki delapan core, tetapkan ukuran tabel ke 524288 .
|
Networking |
1.13.0-1.13.2 |
calico-typha atau loop error operator anetd pada node Windows dengan Controlplane v2
Dengan Controlplane v2 atau model penginstalan baru, calico-typha atau anetd-operator mungkin dijadwalkan ke node Windows dan mengalami error loop.
Alasannya adalah karena kedua deployment ini menoleransi semua taint, termasuk taint node Windows.
Solusi:
Upgrade ke versi 1.13.3+, atau jalankan perintah berikut untuk mengedit deployment `calico-typha` atau `anetd-operator`:
# If dataplane v2 is not used.
kubectl edit deployment -n kube-system calico-typha --kubeconfig USER_CLUSTER_KUBECONFIG
# If dataplane v2 is used.
kubectl edit deployment -n kube-system anetd-operator --kubeconfig USER_CLUSTER_KUBECONFIG
Hapus spec.template.spec.tolerations berikut:
- effect: NoSchedule
operator: Exists
- effect: NoExecute
operator: Exists
Dan tambahkan toleransi berikut:
- key: node-role.kubernetes.io/master
operator: Exists
|
Configuration |
1.14.0-1.14.2 |
File kredensial registry pribadi cluster pengguna tidak dapat dimuat
Anda mungkin tidak dapat membuat cluster pengguna jika menentukan bagian
privateRegistry dengan kredensial fileRef .
Preflight mungkin gagal dengan pesan berikut:
[FAILURE] Docker registry access: Failed to login.
Solusi:
|
Operasi |
1,10 dan yang lebih baru |
Cloud Service Mesh dan mesh layanan lainnya yang tidak kompatibel dengan Dataplane v2
Dataplane V2 mengambil alih load balancing dan membuat soket kernel, bukan DNAT berbasis paket. Artinya, Cloud Service Mesh tidak dapat melakukan pemeriksaan paket karena pod dilewati dan tidak pernah menggunakan IPTables.
Ini direpresentasikan dalam mode bebas kube-proxy karena hilangnya konektivitas atau pemilihan rute traffic yang salah untuk layanan dengan Cloud Service Mesh karena file bantuan tidak dapat melakukan pemeriksaan paket.
Masalah ini ada di semua versi GKE pada Bare Metal 1.10, tetapi beberapa versi baru 1.10 (1.10.2+) memiliki solusi.
Solusi:
Upgrade ke versi 1.11 untuk kompatibilitas penuh atau jika menjalankan versi 1.10.2 atau yang lebih baru, jalankan:
kubectl edit cm -n kube-system cilium-config --kubeconfig USER_CLUSTER_KUBECONFIG
Tambahkan bpf-lb-sock-hostns-only: true ke configmap, lalu mulai ulang daemonset anetd:
kubectl rollout restart ds anetd -n kube-system --kubeconfig USER_CLUSTER_KUBECONFIG
|
Penyimpanan |
1.12+, 1.13.3 |
kube-controller-manager mungkin melepaskan volume persisten secara paksa setelah 6 menit
kube-controller-manager mungkin habis waktu saat melepaskan PV/PVC setelah 6 menit, dan melepaskan PV/PVC secara paksa. Log mendetail dari kube-controller-manager menampilkan peristiwa yang mirip dengan berikut ini:
$ cat kubectl_logs_kube-controller-manager-xxxx | grep "DetachVolume started" | grep expired
kubectl_logs_kube-controller-manager-gke-admin-master-4mgvr_--container_kube-controller-manager_--kubeconfig_kubeconfig_--request-timeout_30s_--namespace_kube-system_--timestamps:2023-01-05T16:29:25.883577880Z W0105 16:29:25.883446 1 reconciler.go:224] attacherDetacher.DetachVolume started for volume "pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16" (UniqueName: "kubernetes.io/csi/csi.vsphere.vmware.com^126f913b-4029-4055-91f7-beee75d5d34a") on node "sandbox-corp-ant-antho-0223092-03-u-tm04-ml5m8-7d66645cf-t5q8f"
This volume is not safe to detach, but maxWaitForUnmountDuration 6m0s expired, force detaching
Untuk memastikan masalah ini terjadi, login ke node dan jalankan perintah berikut:
# See all the mounting points with disks
lsblk -f
# See some ext4 errors
sudo dmesg -T
Di log kubelet, pesan error seperti berikut akan ditampilkan:
Error: GetDeviceMountRefs check failed for volume "pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16" (UniqueName: "kubernetes.io/csi/csi.vsphere.vmware.com^126f913b-4029-4055-91f7-beee75d5d34a") on node "sandbox-corp-ant-antho-0223092-03-u-tm04-ml5m8-7d66645cf-t5q8f" :
the device mount path "/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16/globalmount" is still mounted by other references [/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16/globalmount
Solusi:
Hubungkan ke node yang terpengaruh menggunakan SSH, lalu mulai ulang node.
|
Upgrade, Update |
1,12+, 1,13+, 1,14+ |
Upgrade cluster terhenti jika driver CSI pihak ketiga digunakan
Anda mungkin tidak dapat mengupgrade cluster jika menggunakan driver CSI pihak ketiga. Perintah gkectl cluster diagnose mungkin menampilkan
error berikut:
"virtual disk "kubernetes.io/csi/csi.netapp.io^pvc-27a1625f-29e3-4e4f-9cd1-a45237cc472c" IS NOT attached to machine "cluster-pool-855f694cc-cjk5c" but IS listed in the Node.Status"
Solusi:
Lakukan upgrade menggunakan opsi --skip-validation-all .
|
Operasi |
1,10+, 1,11+, 1,12+, 1,13+, 1,14+ |
gkectl repair admin-master membuat VM master admin tanpa mengupgrade versi hardware vm-nya
Node master admin yang dibuat melalui gkectl repair admin-master mungkin menggunakan versi hardware VM yang lebih rendah dari yang diharapkan. Saat masalah terjadi,
Anda akan melihat error dari laporan
gkectl diagnose cluster .
CSIPrerequisites [VM Hardware]: The current VM hardware versions are lower than vmx-15 which is unexpected. Please contact Anthos support to resolve this issue.
Solusi:
Matikan node master admin, ikuti https://kb.vmware.com/s/article/1003746 untuk mengupgrade node ke versi yang diharapkan yang dijelaskan dalam pesan error, lalu memulai node.
|
Sistem operasi |
1.10+, 1.11+, 1.12+, 1.13+, 1.14+, 1.15+, 1.16+ |
VM merilis sewa DHCP saat dimatikan/dimulai ulang secara tiba-tiba, yang dapat
mengakibatkan perubahan IP
Dalam systemd v244, systemd-networkd memiliki perubahan perilaku default pada konfigurasi KeepConfiguration . Sebelum perubahan ini, VM tidak mengirim pesan rilis sewa DHCP ke server DHCP saat shutdown atau reboot. Setelah perubahan ini, VM akan mengirim pesan tersebut dan mengembalikan IP ke server DHCP. Akibatnya, IP yang dirilis dapat dialokasikan ulang ke VM yang berbeda dan/atau IP yang berbeda mungkin ditetapkan ke VM, yang mengakibatkan konflik IP (pada tingkat Kubernetes, bukan tingkat vSphere) dan/atau perubahan IP di VM, yang dapat merusak cluster dengan berbagai cara.
Misalnya, Anda mungkin melihat gejala berikut.
- UI vCenter menunjukkan bahwa tidak ada VM yang menggunakan IP yang sama, tetapi
kubectl get
nodes -o wide menampilkan node dengan IP duplikat.
NAME STATUS AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
node1 Ready 28h v1.22.8-gke.204 10.180.85.130 10.180.85.130 Ubuntu 20.04.4 LTS 5.4.0-1049-gkeop containerd://1.5.13
node2 NotReady 71d v1.22.8-gke.204 10.180.85.130 10.180.85.130 Ubuntu 20.04.4 LTS 5.4.0-1049-gkeop containerd://1.5.13
- Node baru gagal dimulai karena error
calico-node
2023-01-19T22:07:08.817410035Z 2023-01-19 22:07:08.817 [WARNING][9] startup/startup.go 1135: Calico node 'node1' is already using the IPv4 address 10.180.85.130.
2023-01-19T22:07:08.817514332Z 2023-01-19 22:07:08.817 [INFO][9] startup/startup.go 354: Clearing out-of-date IPv4 address from this node IP="10.180.85.130/24"
2023-01-19T22:07:08.825614667Z 2023-01-19 22:07:08.825 [WARNING][9] startup/startup.go 1347: Terminating
2023-01-19T22:07:08.828218856Z Calico node failed to start
Solusi:
Deploy DaemonSet berikut di cluster untuk mengembalikan
perubahan perilaku default systemd-networkd . VM yang menjalankan DaemonSet ini tidak akan melepaskan IP ke server DHCP saat shutdown/reboot. IP akan dibebaskan secara otomatis oleh server DHCP
setelah masa sewa berakhir.
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: set-dhcp-on-stop
spec:
selector:
matchLabels:
name: set-dhcp-on-stop
template:
metadata:
labels:
name: set-dhcp-on-stop
spec:
hostIPC: true
hostPID: true
hostNetwork: true
containers:
- name: set-dhcp-on-stop
image: ubuntu
tty: true
command:
- /bin/bash
- -c
- |
set -x
date
while true; do
export CONFIG=/host/run/systemd/network/10-netplan-ens192.network;
grep KeepConfiguration=dhcp-on-stop "${CONFIG}" > /dev/null
if (( $? != 0 )) ; then
echo "Setting KeepConfiguration=dhcp-on-stop"
sed -i '/\[Network\]/a KeepConfiguration=dhcp-on-stop' "${CONFIG}"
cat "${CONFIG}"
chroot /host systemctl restart systemd-networkd
else
echo "KeepConfiguration=dhcp-on-stop has already been set"
fi;
sleep 3600
done
volumeMounts:
- name: host
mountPath: /host
resources:
requests:
memory: "10Mi"
cpu: "5m"
securityContext:
privileged: true
volumes:
- name: host
hostPath:
path: /
tolerations:
- operator: Exists
effect: NoExecute
- operator: Exists
effect: NoSchedule
|
Operasi, Upgrade, Update |
1.12.0-1.12.5, 1.13.0-1.13.5, 1.14.0-1.14.1 |
Kunci akun layanan akses komponen dihapus total setelah cluster admin diupgrade dari 1.11.x
Masalah ini hanya akan memengaruhi cluster admin yang diupgrade
dari 1.11.x, dan tidak akan memengaruhi cluster admin yang baru dibuat setelah
versi 1.12.
Setelah mengupgrade cluster 1.11.x ke 1.12.x, kolom component-access-sa-key dalam rahasia admin-cluster-creds akan dihapus total.
Hal ini dapat diperiksa dengan menjalankan perintah berikut:
kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get secret admin-cluster-creds -o yaml | grep 'component-access-sa-key'
Jika Anda mendapati output kosong, berarti kunci telah dihapus.
Setelah kunci akun layanan akses komponen dihapus, penginstalan cluster pengguna baru atau upgrade cluster pengguna yang ada akan gagal. Berikut ini daftar beberapa pesan error yang mungkin Anda temui:
- Kegagalan preflight validasi lambat dengan pesan error:
"Failed
to create the test VMs: failed to get service account key: service
account is not configured."
- Penyiapan paling lambat
gkectl prepare gagal dengan pesan error:
"Failed to prepare OS images: dialing: unexpected end of JSON
input"
- Jika Anda mengupgrade cluster pengguna 1.13 menggunakan Konsol Google Cloud atau gcloud CLI, saat Anda menjalankan
gkectl update admin --enable-preview-user-cluster-central-upgrade untuk men-deploy pengontrol platform upgrade, perintah akan gagal dengan pesan: "failed to download bundle to disk: dialing:
unexpected end of JSON input" (Anda dapat melihat pesan ini di kolom status pada output kubectl --kubeconfig
ADMIN_KUBECONFIG -n kube-system get onprembundle -oyaml ).
Solusi:
Tambahkan kembali kunci akun layanan akses komponen ke rahasia secara manual dengan menjalankan perintah berikut:
kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get secret admin-cluster-creds -ojson | jq --arg casa "$(cat COMPONENT_ACESS_SERVICE_ACOOUNT_KEY_PATH | base64 -w 0)" '.data["component-access-sa-key"]=$casa' | kubectl --kubeconfig ADMIN_KUBECONFIG apply -f -
|
Operasi |
1.13.0+, 1.14.0+ |
Penskala otomatis cluster tidak berfungsi saat Controlplane V2 diaktifkan
Untuk cluster pengguna yang dibuat dengan Controlplane V2 atau model penginstalan baru, kumpulan node yang mengaktifkan penskalaan otomatis selalu menggunakan autoscaling.minReplicas di user-cluster.yaml. Log pod cluster-autoscaler juga menunjukkan bahwa pod tersebut tidak responsif.
> kubectl --kubeconfig $USER_CLUSTER_KUBECONFIG -n kube-system \
logs $CLUSTER_AUTOSCALER_POD --container_cluster-autoscaler
TIMESTAMP 1 gkeonprem_provider.go:73] error getting onpremusercluster ready status: Expected to get a onpremusercluster with id foo-user-cluster-gke-onprem-mgmt/foo-user-cluster
TIMESTAMP 1 static_autoscaler.go:298] Failed to get node infos for groups: Expected to get a onpremusercluster with id foo-user-cluster-gke-onprem-mgmt/foo-user-cluster
Pod autoscaler cluster dapat ditemukan dengan menjalankan perintah berikut.
> kubectl --kubeconfig $USER_CLUSTER_KUBECONFIG -n kube-system \
get pods | grep cluster-autoscaler
cluster-autoscaler-5857c74586-txx2c 4648017n 48076Ki 30s
Solusi:
Nonaktifkan penskalaan otomatis di semua kumpulan node dengan `gkectl update cluster` hingga diupgrade ke versi yang memiliki perbaikan
|
Penginstalan |
1.12.0-1.12.4, 1.13.0-1.13.3, 1.14.0 |
CIDR tidak diizinkan dalam file blok IP
Saat pengguna menggunakan CIDR dalam file blok IP, validasi konfigurasi akan gagal dengan error berikut:
- Validation Category: Config Check
- [FAILURE] Config: AddressBlock for admin cluster spec is invalid: invalid IP:
172.16.20.12/30
Solusi:
Sertakan IP individual dalam file blok IP hingga meningkatkan ke versi dengan perbaikan: 1.12.5, 1.13.4, 1.14.1+.
|
Upgrade, Update |
1.14.0-1.14.1 |
Pembaruan jenis image OS di admin-cluster.yaml tidak menunggu mesin bidang kontrol pengguna dibuat ulang
Saat Memperbarui jenis image OS bidang kontrol di admin-cluster.yaml, dan jika cluster pengguna yang sesuai dibuat melalui Controlplane V2, mesin bidang kontrol pengguna mungkin tidak menyelesaikan pembuatan ulang saat perintah gkectl selesai.
Solusi:
Setelah update selesai, tunggu hingga mesin bidang kontrol pengguna juga menyelesaikan pembuatan ulang dengan memantau jenis image OS node menggunakan kubectl --kubeconfig USER_KUBECONFIG get nodes -owide . Misalnya, jika memperbarui dari Ubuntu ke COS, kita harus menunggu semua mesin bidang kontrol berubah sepenuhnya dari Ubuntu ke COS bahkan setelah perintah pembaruan selesai.
|
Operasi |
1.10, 1.11, 1.12, 1.13, 1.14.0 |
Error pembuatan atau penghapusan pod karena masalah token autentikasi akun layanan Calico CNI
Masalah pada Calico di Google Distributed Cloud 1.14.0 menyebabkan pembuatan dan penghapusan Pod gagal dengan pesan error berikut dalam output kubectl describe pods :
error getting ClusterInformation: connection is unauthorized: Unauthorized
Masalah ini hanya terjadi 24 jam setelah cluster dibuat atau diupgrade ke versi 1.14 menggunakan Calico.
Cluster admin selalu menggunakan Calico, sedangkan untuk cluster pengguna ada
kolom konfigurasi `enableDataPlaneV2` di user-cluster.yaml. Jika kolom itu
disetel ke `false`, atau tidak ditentukan, artinya Anda menggunakan Calico di cluster
pengguna.
Penampung install-cni node membuat kubeconfig dengan token yang valid selama 24 jam. Token ini perlu diperpanjang secara berkala oleh Pod calico-node . Pod calico-node tidak dapat memperpanjang token karena tidak memiliki akses ke direktori yang berisi file kubeconfig pada node.
Solusi:
Masalah ini telah diperbaiki pada Google Distributed Cloud versi 1.14.1. Upgrade ke versi ini atau yang lebih baru.
Jika Anda tidak dapat langsung mengupgrade, terapkan patch berikut pada
calico-node DaemonSet di admin dan cluster pengguna Anda:
kubectl -n kube-system get daemonset calico-node \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG -o json \
| jq '.spec.template.spec.containers[0].volumeMounts += [{"name":"cni-net-dir","mountPath":"/host/etc/cni/net.d"}]' \
| kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f -
kubectl -n kube-system get daemonset calico-node \
--kubeconfig USER_CLUSTER_KUBECONFIG -o json \
| jq '.spec.template.spec.containers[0].volumeMounts += [{"name":"cni-net-dir","mountPath":"/host/etc/cni/net.d"}]' \
| kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f -
Ganti opsi berikut:
ADMIN_CLUSTER_KUBECONFIG : jalur
file kubeconfig cluster admin.
USER_CLUSTER_CONFIG_FILE : jalur
file konfigurasi cluster pengguna Anda.
|
Penginstalan |
1.12.0-1.12.4, 1.13.0-1.13.3, 1.14.0 |
Validasi blok IP gagal saat menggunakan CIDR
Pembuatan cluster gagal meskipun pengguna memiliki konfigurasi yang benar. Pengguna melihat pembuatan gagal karena cluster tidak memiliki cukup IP.
Solusi:
CIDR membagi menjadi beberapa blok CIDR yang lebih kecil, seperti 10.0.0.0/30 menjadi 10.0.0.0/31, 10.0.0.2/31 . Asalkan ada N+1 CIDR, dengan N adalah jumlah node dalam cluster, ini sudah cukup.
|
Operasi, Upgrade, Update |
1.11.0 - 1.11.1, 1.10.0 - 1.10.4, 1.9.0 - 1.9.6 |
Pencadangan cluster admin tidak menyertakan konfigurasi dan kunci enkripsi rahasia yang selalu aktif
Jika fitur enkripsi secret yang selalu aktif diaktifkan bersama dengan pencadangan cluster, pencadangan cluster admin akan gagal menyertakan kunci enkripsi dan konfigurasi yang diperlukan oleh fitur enkripsi secret yang selalu aktif. Oleh karena itu, memperbaiki master admin dengan cadangan ini menggunakan gkectl repair admin-master --restore-from-backup menyebabkan error berikut:
Validating admin master VM xxx ...
Waiting for kube-apiserver to be accessible via LB VIP (timeout "8m0s")... ERROR
Failed to access kube-apiserver via LB VIP. Trying to fix the problem by rebooting the admin master
Waiting for kube-apiserver to be accessible via LB VIP (timeout "13m0s")... ERROR
Failed to access kube-apiserver via LB VIP. Trying to fix the problem by rebooting the admin master
Waiting for kube-apiserver to be accessible via LB VIP (timeout "18m0s")... ERROR
Failed to access kube-apiserver via LB VIP. Trying to fix the problem by rebooting the admin master
Solusi:
- Gunakan biner gkectl dari versi patch terbaru yang tersedia untuk versi minor terkait untuk melakukan pencadangan cluster admin setelah operasi cluster penting. Misalnya, jika cluster menjalankan versi 1.10.2, gunakan biner 1.10.5 gkectl untuk melakukan pencadangan cluster admin secara manual seperti yang dijelaskan dalam Mencadangkan dan Memulihkan cluster admin dengan gkectl.
|
Operasi, Upgrade, Update |
1,10 dan yang lebih baru |
Membuat ulang VM master admin dengan boot disk baru (misalnya, gkectl repair admin-master ) akan gagal jika fitur enkripsi secret yang selalu aktif diaktifkan menggunakan perintah `gkectl update`.
Jika fitur enkripsi secret yang selalu aktif tidak diaktifkan saat pembuatan cluster, tetapi diaktifkan nanti menggunakan operasi gkectl update , gkectl repair admin-master akan gagal memperbaiki node bidang kontrol cluster admin. Sebaiknya fitur enkripsi secret yang selalu aktif diaktifkan saat pembuatan cluster. Tidak ada mitigasi saat ini.
|
Upgrade, Update |
1.10 |
Mengupgrade cluster pengguna pertama dari 1.9 ke 1.10 akan membuat ulang node di cluster pengguna lain
Mengupgrade cluster pengguna pertama dari 1.9 ke 1.10 dapat membuat ulang node di cluster pengguna lain pada cluster admin yang sama. Pembuatan ulang dilakukan secara bergelombang.
disk_label dihapus dari MachineTemplate.spec.template.spec.providerSpec.machineVariables , yang memicu update pada semua MachineDeployment secara tiba-tiba.
Solusi:
Lihat langkah-langkah solusi
- Perkecil skala replika
clusterapi-controllers menjadi 0 untuk semua cluster pengguna.
kubectl scale --replicas=0 -n=USER_CLUSTER_NAME deployment/clusterapi-controllers --kubeconfig ADMIN_CLUSTER_KUBECONFIG
Upgrade setiap cluster pengguna satu per satu.
|
Upgrade, Update |
1.10.0 |
Docker sering dimulai ulang setelah upgrade cluster
Mengupgrade cluster pengguna ke 1.10.0 dapat menyebabkan Docker sering dimulai ulang.
Anda dapat mendeteksi masalah ini dengan menjalankan kubectl describe node NODE_NAME --kubeconfig USER_CLUSTER_KUBECONFIG
Kondisi node akan menunjukkan apakah Docker sering dimulai ulang. Berikut adalah contoh output:
Normal FrequentDockerRestart 41m (x2 over 141m) systemd-monitor Node condition FrequentDockerRestart is now: True, reason: FrequentDockerRestart
Untuk memahami akar masalah, Anda perlu melakukan SSH ke node yang memiliki gejala dan menjalankan perintah seperti sudo journalctl --utc -u docker atau sudo journalctl -x
Solusi:
|
Upgrade, Update |
1.11, 1.12 |
Komponen GMP yang di-deploy sendiri tidak dipertahankan setelah diupgrade ke versi 1.12
Jika Anda menggunakan Google Distributed Cloud versi di bawah 1.12, dan telah menyiapkan komponen Prometheus yang dikelola Google (GMP) secara manual di namespace gmp-system
untuk cluster Anda, komponen tersebut tidak akan dipertahankan saat Anda
mengupgrade ke versi 1.12.x.
Mulai versi 1.12, komponen GMP dalam namespace gmp-system dan CRD dikelola oleh objek
stackdriver , dengan tanda enableGMPForApplications ditetapkan ke false secara
default. Jika Anda men-deploy komponen GMP secara manual di namespace sebelum mengupgrade ke versi 1.12, resource akan dihapus oleh stackdriver .
Solusi:
|
Operasi |
1.11, 1.12, 1.13.0 - 1.13.1 |
Objek ClusterAPI tidak ada dalam skenario system snapshot cluster
Dalam skenario system , snapshot cluster tidak menyertakan resource apa pun pada namespace default .
Namun, beberapa resource Kubernetes seperti objek Cluster API yang ada di bawah namespace ini berisi informasi proses debug yang berguna. Snapshot cluster harus menyertakannya.
Solusi:
Anda dapat menjalankan perintah berikut secara manual untuk mengumpulkan informasi proses debug.
export KUBECONFIG=USER_CLUSTER_KUBECONFIG
kubectl get clusters.cluster.k8s.io -o yaml
kubectl get controlplanes.cluster.k8s.io -o yaml
kubectl get machineclasses.cluster.k8s.io -o yaml
kubectl get machinedeployments.cluster.k8s.io -o yaml
kubectl get machines.cluster.k8s.io -o yaml
kubectl get machinesets.cluster.k8s.io -o yaml
kubectl get services -o yaml
kubectl describe clusters.cluster.k8s.io
kubectl describe controlplanes.cluster.k8s.io
kubectl describe machineclasses.cluster.k8s.io
kubectl describe machinedeployments.cluster.k8s.io
kubectl describe machines.cluster.k8s.io
kubectl describe machinesets.cluster.k8s.io
kubectl describe services
jika:
USER_CLUSTER_KUBECONFIG adalah file kubeconfig cluster pengguna.
|
Upgrade, Update |
1.11.0-1.11.4, 1.12.0-1.12.3, 1.13.0-1.13.1 |
Penghapusan cluster pengguna terhenti di pengurasan node untuk penyiapan vSAN
Saat menghapus, mengupdate, atau mengupgrade cluster pengguna, node pengosongan mungkin macet dalam skenario berikut:
- Cluster admin telah menggunakan driver vSphere CSI pada vSAN sejak versi 1.12.x, dan
- Tidak ada objek PVC/PV yang dibuat oleh plugin vSphere dalam hierarki di cluster admin dan pengguna.
Untuk mengidentifikasi gejala, jalankan perintah di bawah:
kubectl logs clusterapi-controllers-POD_NAME_SUFFIX --kubeconfig ADMIN_KUBECONFIG -n USER_CLUSTER_NAMESPACE
Berikut adalah contoh pesan error dari perintah di atas:
E0920 20:27:43.086567 1 machine_controller.go:250] Error deleting machine object [MACHINE]; Failed to delete machine [MACHINE]: failed to detach disks from VM "[MACHINE]": failed to convert disk path "kubevols" to UUID path: failed to convert full path "ds:///vmfs/volumes/vsan:[UUID]/kubevols": ServerFaultCode: A general system error occurred: Invalid fault
kubevols adalah direktori default untuk driver dalam hierarki vSphere. Jika tidak ada objek PVC/PV yang dibuat, Anda dapat mengalami bug yang menyebabkan node pengurasan akan terhenti dalam menemukan kubevols , karena implementasi saat ini mengasumsikan bahwa kubevols selalu ada.
Solusi:
Buat direktori kubevols di datastore tempat node dibuat. Ini ditentukan di kolom vCenter.datastore dalam file user-cluster.yaml atau admin-cluster.yaml .
|
Configuration |
1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13, 1.14 |
Cluster Autoscaler clusterrolebinding dan clusterrole dihapus setelah menghapus cluster pengguna.
Saat penghapusan cluster pengguna, clusterrole dan clusterrolebinding yang sesuai untuk autoscaler cluster juga akan dihapus. Hal ini memengaruhi semua cluster pengguna lainnya di cluster admin yang sama yang mengaktifkan autoscaler cluster. Hal ini karena clusterrole dan clusterrolebinding yang sama digunakan untuk semua pod autoscaler cluster dalam cluster admin yang sama.
Gejalanya adalah sebagai berikut:
kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
cluster-autoscaler
dengan ADMIN_CLUSTER_KUBECONFIG adalah file kubeconfig cluster
admin.
Berikut adalah contoh pesan error yang mungkin Anda lihat:
2023-03-26T10:45:44.866600973Z W0326 10:45:44.866463 1 reflector.go:424] k8s.io/client-go/dynamic/dynamicinformer/informer.go:91: failed to list *unstructured.Unstructured: onpremuserclusters.onprem.cluster.gke.io is forbidden: User "..." cannot list resource "onpremuserclusters" in API group "onprem.cluster.gke.io" at the cluster scope
2023-03-26T10:45:44.866646815Z E0326 10:45:44.866494 1 reflector.go:140] k8s.io/client-go/dynamic/dynamicinformer/informer.go:91: Failed to watch *unstructured.Unstructured: failed to list *unstructured.Unstructured: onpremuserclusters.onprem.cluster.gke.io is forbidden: User "..." cannot list resource "onpremuserclusters" in API group "onprem.cluster.gke.io" at the cluster scope
Solusi:
Lihat langkah-langkah solusi
Periksa apakah clusterrole dan clusterrolebinding hilang di cluster admin
-
kubectl get clusterrolebindings --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system | grep cluster-autoscaler
-
kubectl get clusterrole --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system | grep cluster-autoscaler
Terapkan clusterrole dan clusterrolebinding berikut ke cluster admin jika tidak ada. Tambahkan subjek akun layanan ke clusterrolebinding untuk setiap cluster pengguna.
-
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: cluster-autoscaler
rules:
- apiGroups: ["cluster.k8s.io"]
resources: ["clusters"]
verbs: ["get", "list", "watch"]
- apiGroups: ["cluster.k8s.io"]
resources: ["machinesets","machinedeployments", "machinedeployments/scale","machines"]
verbs: ["get", "list", "watch", "update", "patch"]
- apiGroups: ["onprem.cluster.gke.io"]
resources: ["onpremuserclusters"]
verbs: ["get", "list", "watch"]
- apiGroups:
- coordination.k8s.io
resources:
- leases
resourceNames: ["cluster-autoscaler"]
verbs:
- get
- list
- watch
- create
- update
- patch
- apiGroups:
- ""
resources:
- nodes
verbs: ["get", "list", "watch", "update", "patch"]
- apiGroups:
- ""
resources:
- pods
verbs: ["get", "list", "watch"]
- apiGroups:
- ""
resources:
- pods/eviction
verbs: ["create"]
# read-only access to cluster state
- apiGroups: [""]
resources: ["services", "replicationcontrollers", "persistentvolumes", "persistentvolumeclaims"]
verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
resources: ["daemonsets", "replicasets"]
verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
resources: ["statefulsets"]
verbs: ["get", "list", "watch"]
- apiGroups: ["batch"]
resources: ["jobs"]
verbs: ["get", "list", "watch"]
- apiGroups: ["policy"]
resources: ["poddisruptionbudgets"]
verbs: ["get", "list", "watch"]
- apiGroups: ["storage.k8s.io"]
resources: ["storageclasses", "csinodes"]
verbs: ["get", "list", "watch"]
# misc access
- apiGroups: [""]
resources: ["events"]
verbs: ["create", "update", "patch"]
- apiGroups: [""]
resources: ["configmaps"]
verbs: ["create"]
- apiGroups: [""]
resources: ["configmaps"]
resourceNames: ["cluster-autoscaler-status"]
verbs: ["get", "update", "patch", "delete"]
-
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
labels:
k8s-app: cluster-autoscaler
name: cluster-autoscaler
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-autoscaler
subjects:
- kind: ServiceAccount
name: cluster-autoscaler
namespace: NAMESPACE_OF_USER_CLUSTER_1
- kind: ServiceAccount
name: cluster-autoscaler
namespace: NAMESPACE_OF_USER_CLUSTER_2
...
|
Configuration |
1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13 |
cluster admin cluster-health-controller dan vsphere-metrics-exporter tidak berfungsi setelah menghapus cluster pengguna
Saat penghapusan cluster pengguna, clusterrole yang sesuai juga akan dihapus, yang mengakibatkan perbaikan otomatis dan pengekspor metrik vsphere tidak berfungsi
Gejalanya adalah sebagai berikut:
cluster-health-controller log
kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
cluster-health-controller
dengan ADMIN_CLUSTER_KUBECONFIG adalah file kubeconfig cluster
admin.
Berikut adalah contoh pesan error yang mungkin Anda lihat:
error retrieving resource lock default/onprem-cluster-health-leader-election: configmaps "onprem-cluster-health-leader-election" is forbidden: User "system:serviceaccount:kube-system:cluster-health-controller" cannot get resource "configmaps" in API group "" in the namespace "default": RBAC: clusterrole.rbac.authorization.k8s.io "cluster-health-controller-role" not found
vsphere-metrics-exporter log
kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
vsphere-metrics-exporter
dengan ADMIN_CLUSTER_KUBECONFIG adalah file kubeconfig cluster
admin.
Berikut adalah contoh pesan error yang mungkin Anda lihat:
vsphere-metrics-exporter/cmd/vsphere-metrics-exporter/main.go:68: Failed to watch *v1alpha1.Cluster: failed to list *v1alpha1.Cluster: clusters.cluster.k8s.io is forbidden: User "system:serviceaccount:kube-system:vsphere-metrics-exporter" cannot list resource "clusters" in API group "cluster.k8s.io" in the namespace "default"
Solusi:
Lihat langkah-langkah solusi
Terapkan yaml berikut ke cluster admin
- Untuk vsphere-metrics-exporter
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: vsphere-metrics-exporter
rules:
- apiGroups:
- cluster.k8s.io
resources:
- clusters
verbs: [get, list, watch]
- apiGroups:
- ""
resources:
- nodes
verbs: [get, list, watch]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
labels:
k8s-app: vsphere-metrics-exporter
name: vsphere-metrics-exporter
namespace: kube-system
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: vsphere-metrics-exporter
subjects:
- kind: ServiceAccount
name: vsphere-metrics-exporter
namespace: kube-system
Untuk cluster-health-controller
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: cluster-health-controller-role
rules:
- apiGroups:
- "*"
resources:
- "*"
verbs:
- "*"
|
Configuration |
1.12.1-1.12.3, 1.13.0-1.13.2 |
gkectl check-config gagal saat validasi image OS
Masalah umum yang dapat menggagalkan gkectl check-config tanpa menjalankan gkectl prepare . Hal ini membingungkan karena sebaiknya jalankan perintah sebelum menjalankan gkectl prepare
Gejalanya adalah perintah gkectl check-config akan gagal dengan pesan error berikut:
Validator result: {Status:FAILURE Reason:os images [OS_IMAGE_NAME] don't exist, please run `gkectl prepare` to upload os images. UnhealthyResources:[]}
Solusi:
Opsi 1: jalankan gkectl prepare untuk mengupload OS image yang tidak ada.
Opsi 2: gunakan gkectl check-config --skip-validation-os-images untuk melewati validasi image OS.
|
Upgrade, Update |
1.11, 1.12, 1.13 |
gkectl update admin/cluster gagal memperbarui grup anti
Masalah umum yang dapat menggagalkan gkectl update admin/cluster saat mengupdate anti affinity groups .
Gejalanya adalah perintah gkectl update akan gagal dengan pesan error berikut:
Waiting for machines to be re-deployed... ERROR
Exit with error:
Failed to update the cluster: timed out waiting for the condition
Solusi:
Lihat langkah-langkah solusi
Agar update dapat diterapkan, mesin harus dibuat ulang after update yang gagal.
Untuk update cluster admin, node add-on admin dan master pengguna harus dibuat ulang
Untuk update cluster pengguna, node pekerja pengguna harus dibuat ulang
Untuk membuat ulang node pekerja pengguna
Opsi 1 Ikuti cara memperbarui kumpulan node dan mengubah CPU atau memori untuk memicu pembuatan ulang node secara berkelanjutan.
Opsi 2 Gunakan kubectl delete untuk membuat ulang mesin satu per satu
kubectl delete machines MACHINE_NAME --kubeconfig USER_KUBECONFIG
Untuk membuat ulang node master pengguna
Opsi 1 Ikuti mengubah ukuran bidang kontrol dan ubah CPU atau memori untuk memicu pembuatan ulang node secara berkelanjutan.
Opsi 2 Gunakan kubectl delete untuk membuat ulang mesin satu per satu
kubectl delete machines MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG
Untuk membuat ulang node add-on admin
Menggunakan kubectl delete untuk membuat ulang mesin satu per satu
kubectl delete machines MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG
|
Penginstalan, Upgrade, Update |
1.13.0-1.13.8, 1.14.0-1.14.4, 1.15.0 |
Pendaftaran node gagal selama pembuatan, upgrade, update, dan
perbaikan otomatis node jika ipMode.type adalah static dan
nama host yang dikonfigurasi di
file blok IP berisi satu
atau beberapa periode. Dalam hal ini, Permintaan Penandatanganan Sertifikat (CSR) untuk node tidak disetujui secara otomatis.
Untuk melihat CSR yang tertunda untuk sebuah node, jalankan perintah berikut:
kubectl get csr -A -o wide
Periksa log berikut untuk pesan error:
- Melihat log di cluster admin untuk container
clusterapi-controller-manager di Pod clusterapi-controllers :
kubectl logs clusterapi-controllers-POD_NAME \
-c clusterapi-controller-manager -n kube-system \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG
- Untuk melihat log yang sama di cluster pengguna, jalankan perintah
berikut:
kubectl logs clusterapi-controllers-POD_NAME \
-c clusterapi-controller-manager -n USER_CLUSTER_NAME \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG
jika:
- ADMIN_CLUSTER_KUBECONFIG adalah file kubeconfig cluster admin.
- USER_CLUSTER_NAME adalah nama cluster pengguna.
Berikut ini contoh pesan error yang mungkin Anda lihat: "msg"="failed
to validate token id" "error"="failed to find machine for node
node-worker-vm-1" "validate"="csr-5jpx9"
- Lihat log
kubelet pada node yang bermasalah:
journalctl --u kubelet
Berikut adalah contoh pesan error yang mungkin Anda lihat: "Error getting
node" err="node \"node-worker-vm-1\" not found"
Jika Anda menentukan nama domain di kolom nama host file blok IP,
semua karakter setelah titik pertama akan diabaikan. Misalnya, jika Anda menentukan nama host sebagai bob-vm-1.bank.plc , nama host VM dan nama node akan ditetapkan ke bob-vm-1 .
Jika verifikasi ID node diaktifkan, pemberi persetujuan CSR akan membandingkan nama node dengan nama host di spesifikasi Mesin, dan gagal merekonsiliasi nama tersebut. Pemberi persetujuan akan menolak CSR, dan node gagal melakukan bootstrap.
Solusi:
Cluster pengguna
Nonaktifkan verifikasi ID node dengan menyelesaikan langkah-langkah berikut:
- Tambahkan kolom berikut di file konfigurasi cluster pengguna Anda:
disableNodeIDVerification: true
disableNodeIDVerificationCSRSigning: true
- Simpan file, dan perbarui cluster pengguna dengan menjalankan perintah
berikut:
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--config USER_CLUSTER_CONFIG_FILE
Ganti perintah berikut:
ADMIN_CLUSTER_KUBECONFIG : jalur
file kubeconfig cluster admin.
USER_CLUSTER_CONFIG_FILE : jalur
file konfigurasi cluster pengguna Anda.
Cluster Admin
- Buka resource kustom
OnPremAdminCluster untuk
mengedit:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
edit onpremadmincluster -n kube-system
- Tambahkan anotasi berikut ke resource kustom:
features.onprem.cluster.gke.io/disable-node-id-verification: enabled
- Edit manifes
kube-controller-manager di bidang kontrol
cluster admin:
- SSH ke
node bidang kontrol cluster admin.
- Buka manifes
kube-controller-manager untuk
pengeditan:
sudo vi /etc/kubernetes/manifests/kube-controller-manager.yaml
- Temukan daftar
controllers :
--controllers=*,bootstrapsigner,tokencleaner,-csrapproving,-csrsigning
- Perbarui bagian ini seperti yang ditunjukkan di bawah:
--controllers=*,bootstrapsigner,tokencleaner
- Buka pengontrol Deployment Cluster API untuk mengedit:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
edit deployment clusterapi-controllers -n kube-system
- Ubah nilai
node-id-verification-enabled dan
node-id-verification-csr-signing-enabled menjadi
false :
--node-id-verification-enabled=false
--node-id-verification-csr-signing-enabled=false
|
Penginstalan, Upgrade, Update |
1.11.0-1.11.4 |
Kegagalan startup mesin bidang kontrol admin yang disebabkan oleh paket sertifikat registry pribadi
Pembuatan/upgrade cluster admin terhenti di log berikut selamanya dan akhirnya habis waktunya:
Waiting for Machine gke-admin-master-xxxx to become ready...
Log pengontrol Cluster API di
snapshot cluster eksternal menyertakan log berikut:
Invalid value 'XXXX' specified for property startup-data
Berikut adalah contoh jalur file untuk log pengontrol Cluster API:
kubectlCommands/kubectl_logs_clusterapi-controllers-c4fbb45f-6q6g6_--container_vsphere-controller-manager_--kubeconfig_.home.ubuntu..kube.kind-config-gkectl_--request-timeout_30s_--namespace_kube-system_--timestamps
VMware has a 64k vApp property size limit. In the identified versions,
the data passed via vApp property is close to the limit. When the private
registry certificate contains a certificate bundle, it may cause the final
data to exceed the 64k limit.
Workaround:
Only include the required certificates in the private registry
certificate file configured in privateRegistry.caCertPath in
the admin cluster config file.
Or upgrade to a version with the fix when available.
|
Networking |
1.10, 1.11.0-1.11.3, 1.12.0-1.12.2, 1.13.0 |
NetworkGatewayNodes marked unhealthy from concurrent
status update conflict
In networkgatewaygroups.status.nodes , some nodes switch
between NotHealthy and Up .
Logs for the ang-daemon Pod running on that node reveal
repeated errors:
2022-09-16T21:50:59.696Z ERROR ANGd Failed to report status {"angNode": "kube-system/my-node", "error": "updating Node CR status: sending Node CR update: Operation cannot be fulfilled on networkgatewaynodes.networking.gke.io \"my-node\": the object has been modified; please apply your changes to the latest version and try again"}
Status NotHealthy mencegah pengontrol menetapkan IP mengambang tambahan ke node. Hal ini dapat mengakibatkan beban yang lebih tinggi pada node lain atau kurangnya redundansi untuk ketersediaan tinggi.
Aktivitas Dataplane tidak akan terpengaruh.
Pertentangan pada objek networkgatewaygroup menyebabkan beberapa update status gagal karena kesalahan dalam penanganan percobaan ulang. Jika terlalu banyak
update status yang gagal, ang-controller-manager akan melihat node sebagai
melewati batas waktu detak jantungnya dan menandai node NotHealthy .
Kesalahan dalam penanganan percobaan ulang telah diperbaiki di versi yang lebih baru.
Solusi:
Upgrade ke versi tetap, jika tersedia.
|
Upgrade, Update |
1.12.0-1.12.2, 1.13.0 |
Kondisi race memblokir penghapusan objek mesin selama, serta update atau upgrade
Masalah umum yang dapat menyebabkan upgrade atau update cluster terhenti saat menunggu objek mesin lama dihapus. Hal ini karena finaler tidak dapat dihapus dari objek mesin. Hal ini memengaruhi setiap operasi update berkelanjutan untuk kumpulan node.
Gejalanya adalah waktu perintah gkectl habis dengan pesan error berikut:
E0821 18:28:02.546121 61942 console.go:87] Exit with error:
E0821 18:28:02.546184 61942 console.go:87] error: timed out waiting for the condition, message: Node pool "pool-1" is not ready: ready condition is not true: CreateOrUpdateNodePool: 1/3 replicas are updated
Check the status of OnPremUserCluster 'cluster-1-gke-onprem-mgmt/cluster-1' and the logs of pod 'kube-system/onprem-user-cluster-controller' for more detailed debugging information.
Dalam log Pod clusterapi-controller , error-nya terlihat seperti berikut:
$ kubectl logs clusterapi-controllers-[POD_NAME_SUFFIX] -n cluster-1
-c vsphere-controller-manager --kubeconfig [ADMIN_KUBECONFIG]
| grep "Error removing finalizer from machine object"
[...]
E0821 23:19:45.114993 1 machine_controller.go:269] Error removing finalizer from machine object cluster-1-pool-7cbc496597-t5d5p; Operation cannot be fulfilled on machines.cluster.k8s.io "cluster-1-pool-7cbc496597-t5d5p": the object has been modified; please apply your changes to the latest version and try again
Error ini berulang untuk mesin yang sama selama beberapa menit untuk operasi yang berhasil meskipun tanpa masalah ini. Sering kali, error ini dapat diselesaikan dengan cepat, tetapi untuk beberapa kasus yang jarang terjadi, error ini dapat macet pada kondisi race ini selama beberapa jam.
Masalahnya adalah VM yang mendasarinya telah dihapus di vCenter, tetapi
objek mesin terkait tidak dapat dihapus, yang terhenti di
penghapusan finaler karena update yang sangat sering dari pengontrol lain.
Hal ini dapat menyebabkan waktu tunggu perintah gkectl habis, tetapi pengontrol terus merekonsiliasi cluster sehingga proses upgrade atau update pada akhirnya selesai.
Solusi:
Kami telah menyiapkan beberapa opsi mitigasi berbeda untuk masalah ini,
yang bergantung pada lingkungan dan persyaratan Anda.
Jika Anda mengalami masalah ini dan upgrade atau update masih tidak dapat
diselesaikan setelah sekian lama,
hubungi
tim dukungan kami untuk melakukan mitigasi.
|
Penginstalan, Upgrade, Update |
1.10.2, 1.11, 1.12, 1.13 |
gkectl menyiapkan kegagalan preflight validasi image OS
Perintah gkectl prepare gagal dengan:
- Validation Category: OS Images
- [FAILURE] Admin cluster OS images exist: os images [os_image_name] don't exist, please run `gkectl prepare` to upload os images.
Pemeriksaan preflight gkectl prepare mencakup validasi yang salah.
Solusi:
Jalankan perintah yang sama dengan flag tambahan --skip-validation-os-images .
|
Penginstalan |
1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13 |
URL vCenter dengan awalan https:// atau http://
dapat menyebabkan kegagalan startup cluster
Cluster admin gagal dibuat karena:
Exit with error:
Failed to create root cluster: unable to apply admin base bundle to external cluster: error: timed out waiting for the condition, message:
Failed to apply external bundle components: failed to apply bundle objects from admin-vsphere-credentials-secret 1.x.y-gke.z to cluster external: Secret "vsphere-dynamic-credentials" is invalid:
[data[https://xxx.xxx.xxx.username]: Invalid value: "https://xxx.xxx.xxx.username": a valid config key must consist of alphanumeric characters, '-', '_' or '.'
(e.g. 'key.name', or 'KEY_NAME', or 'key-name', regex used for validation is '[-._a-zA-Z0-9]+'), data[https://xxx.xxx.xxx.password]:
Invalid value: "https://xxx.xxx.xxx.password": a valid config key must consist of alphanumeric characters, '-', '_' or '.'
(e.g. 'key.name', or 'KEY_NAME', or 'key-name', regex used for validation is '[-._a-zA-Z0-9]+')]
URL digunakan sebagai bagian dari kunci Rahasia, yang tidak mendukung "/" atau ":".
Solusi:
Hapus awalan https:// atau http:// dari kolom vCenter.Address di cluster admin atau yaml konfigurasi cluster pengguna.
|
Penginstalan, Upgrade, Update |
1.10, 1.11, 1.12, 1.13 |
gkectl prepare panik di util.CheckFileExists
gkectl prepare dapat panik dengan stacktrace berikut:
panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0xde0dfa]
goroutine 1 [running]:
gke-internal.googlesource.com/syllogi/cluster-management/pkg/util.CheckFileExists(0xc001602210, 0x2b, 0xc001602210, 0x2b) pkg/util/util.go:226 +0x9a
gke-internal.googlesource.com/syllogi/cluster-management/gkectl/pkg/config/util.SetCertsForPrivateRegistry(0xc000053d70, 0x10, 0xc000f06f00, 0x4b4, 0x1, 0xc00015b400)gkectl/pkg/config/util/utils.go:75 +0x85
...
Masalahnya adalah gkectl prepare membuat direktori sertifikat registry pribadi dengan izin yang salah.
Solusi:
Untuk memperbaiki masalah ini, jalankan perintah berikut di workstation
admin:
sudo mkdir -p /etc/docker/certs.d/PRIVATE_REGISTRY_ADDRESS
sudo chmod 0755 /etc/docker/certs.d/PRIVATE_REGISTRY_ADDRESS
|
Upgrade, Update |
1.10, 1.11, 1.12, 1.13 |
Upgrade admin gkectl repair admin-master dan yang dapat dilanjutkan tidak berfungsi bersama
Setelah upaya upgrade cluster admin gagal, jangan jalankan gkectl
repair admin-master . Tindakan ini dapat menyebabkan upaya upgrade admin berikutnya gagal dengan masalah seperti kegagalan daya master admin atau VM tidak dapat diakses.
Solusi:
Jika Anda pernah mengalami skenario kegagalan ini, hubungi dukungan.
|
Upgrade, Update |
1.10, 1.11 |
Upgrade cluster admin yang dilanjutkan dapat menyebabkan template VM bidang kontrol admin tidak ada
Jika mesin bidang kontrol admin tidak dibuat ulang setelah upaya upgrade cluster admin dilanjutkan, template VM bidang kontrol admin akan dihapus. Template VM bidang kontrol admin adalah template master admin yang digunakan untuk memulihkan mesin bidang kontrol dengan gkectl
repair admin-master .
Solusi:
Template VM bidang kontrol admin akan dibuat ulang selama upgrade cluster admin berikutnya.
|
Sistem operasi |
1,12, 1,13 |
cgroup v2 dapat memengaruhi workload
Pada versi 1.12.0, cgroup v2 (unified) diaktifkan secara default untuk node Container Optimized OS (COS). Hal ini berpotensi menyebabkan ketidakstabilan untuk workload Anda di cluster COS.
Solusi:
Kami beralih kembali ke cgroup v1 (hybrid) di versi 1.12.1. Jika Anda menggunakan node COS, sebaiknya upgrade ke versi 1.12.1 segera setelah dirilis.
|
Identitas |
1.10, 1.11, 1.12, 1.13 |
Resource kustom ClientConfig
gkectl update mengembalikan perubahan manual yang telah Anda
buat pada resource kustom ClientConfig.
Solusi:
Kami sangat menyarankan Anda untuk mencadangkan resource ClientConfig setelah
setiap perubahan manual.
|
Penginstalan |
1.10, 1.11, 1.12, 1.13 |
Validasi gkectl check-config gagal: tidak dapat menemukan partisi BIG-IP F5
Validasi gagal karena partisi F5 BIG-IP tidak dapat ditemukan, meskipun
ada.
Masalah dengan F5 BIG-IP API dapat menyebabkan validasi gagal.
Solusi:
Coba jalankan gkectl check-config lagi.
|
Penginstalan |
1.12 |
Penginstalan cluster pengguna gagal karena masalah pemilu pemimpin cert-manager/ca-injector
Anda mungkin melihat kegagalan penginstalan karena
cert-manager-cainjector dalam errorloop, saat apiserver/etcd
lambat:
# These are logs from `cert-manager-cainjector`, from the command
# `kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system
cert-manager-cainjector-xxx`
I0923 16:19:27.911174 1 leaderelection.go:278] failed to renew lease kube-system/cert-manager-cainjector-leader-election: timed out waiting for the condition
E0923 16:19:27.911110 1 leaderelection.go:321] error retrieving resource lock kube-system/cert-manager-cainjector-leader-election-core:
Get "https://10.96.0.1:443/api/v1/namespaces/kube-system/configmaps/cert-manager-cainjector-leader-election-core": context deadline exceeded
I0923 16:19:27.911593 1 leaderelection.go:278] failed to renew lease kube-system/cert-manager-cainjector-leader-election-core: timed out waiting for the condition
E0923 16:19:27.911629 1 start.go:163] cert-manager/ca-injector "msg"="error running core-only manager" "error"="leader election lost"
Solusi:
Lihat langkah-langkah solusi
Jalankan perintah berikut untuk memitigasi masalah.
Turunkan skala monitoring-operator terlebih dahulu agar tidak mengembalikan perubahan pada Deployment cert-manager :
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system \
scale deployment monitoring-operator --replicas=0
Edit Deployment cert-manager-cainjector untuk menonaktifkan
pemilihan pemimpin, karena hanya ada satu replika yang berjalan. Ini tidak diperlukan untuk satu replika:
# Add a command line flag for cainjector: `--leader-elect=false`
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG edit \
-n kube-system deployment cert-manager-cainjector
Cuplikan YAML yang relevan untuk deployment cert-manager-cainjector akan terlihat seperti contoh berikut:
...
apiVersion: apps/v1
kind: Deployment
metadata:
name: cert-manager-cainjector
namespace: kube-system
...
spec:
...
template:
...
spec:
...
containers:
- name: cert-manager
image: "gcr.io/gke-on-prem-staging/cert-manager-cainjector:v1.0.3-gke.0"
args:
...
- --leader-elect=false
...
Biarkan replika monitoring-operator tetap di 0 sebagai mitigasi hingga penginstalan selesai. Jika tidak, perubahan akan dikembalikan.
Setelah penginstalan selesai dan cluster aktif serta berjalan,
aktifkan monitoring-operator untuk operasi hari ke-2:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system \
scale deployment monitoring-operator --replicas=1
Setelah setiap upgrade, perubahan akan dikembalikan. Lakukan kembali langkah yang sama untuk memitigasi masalah hingga masalah ini diperbaiki pada rilis mendatang.
|
VMware |
1.10, 1.11, 1.12, 1.13 |
Memulai ulang atau mengupgrade vCenter untuk versi yang lebih rendah dari 7.0U2
Jika vCenter, untuk versi yang lebih rendah dari 7.0U2, dimulai ulang, setelah
upgrade atau lainnya, nama jaringan dalam informasi vm dari vCenter
salah, dan menyebabkan mesin berada dalam status
Unavailable . Hal ini pada akhirnya menyebabkan node diperbaiki secara otomatis untuk membuat
node baru.
Bug govmomi
terkait.
Solusi:
Solusi ini disediakan oleh dukungan VMware:
- Masalah ini telah diperbaiki di vCenter versi 7.0U2 dan yang lebih baru.
- Untuk versi yang lebih rendah, klik kanan host, lalu pilih
Connection > Putuskan. Selanjutnya, hubungkan kembali, yang memaksa pembaruan grup port VM.
|
Sistem operasi |
1.10, 1.11, 1.12, 1.13 |
Koneksi SSH ditutup oleh host jarak jauh
Untuk Google Distributed Cloud versi 1.7.2 dan yang lebih baru, image OS Ubuntu
di-hardening dengan
CIS L1 Server Benchmark.
Untuk memenuhi aturan CIS "5.2.16 Memastikan SSH Idle Timeout Interval dikonfigurasi", /etc/ssh/sshd_config memiliki setelan berikut:
ClientAliveInterval 300
ClientAliveCountMax 0
Setelan ini ditujukan untuk menghentikan sesi klien setelah 5 menit waktu tidak ada aktivitas. Namun, nilai ClientAliveCountMax 0
menyebabkan perilaku yang tidak terduga. Saat Anda menggunakan sesi ssh di workstation admin, atau node cluster, koneksi SSH mungkin terputus meskipun klien ssh Anda tidak sedang tidak ada aktivitas, seperti saat menjalankan perintah yang memakan waktu lama, dan perintah Anda dapat dihentikan dengan pesan berikut:
Connection to [IP] closed by remote host.
Connection to [IP] closed.
Solusi:
Anda dapat:
Pastikan Anda menghubungkan kembali sesi SSH Anda.
|
Penginstalan |
1.10, 1.11, 1.12, 1.13 |
Penginstalan cert-manager bertentangan
Pada rilis 1.13, monitoring-operator akan menginstal
pengelola sertifikat di namespace cert-manager . Jika karena alasan tertentu, Anda perlu menginstal pengelola sertifikat Anda sendiri, ikuti petunjuk berikut untuk menghindari konflik:
Anda hanya perlu menerapkan langkah ini sekali untuk setiap cluster, dan perubahan tersebut akan dipertahankan di seluruh upgrade cluster.
Catatan: Salah satu gejala umum saat menginstal pengelola sertifikat Anda sendiri adalah bahwa versi atau image cert-manager (misalnya v1.7.2) dapat dikembalikan ke versi lamanya. Hal ini disebabkan oleh
monitoring-operator yang mencoba merekonsiliasi
cert-manager , dan mengembalikan versi dalam prosesnya.
Solusi:
<pMenghindari konflik selama upgrade
- Uninstal versi
cert-manager Anda. Jika menentukan resource Anda sendiri, sebaiknya Anda mencadangkan
resource tersebut.
- Lakukan upgrade.
- Ikuti petunjuk berikut untuk memulihkan
cert-manager Anda sendiri.
Memulihkan pengelola sertifikat Anda sendiri di cluster pengguna
- Skalakan Deployment
monitoring-operator ke 0:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
-n USER_CLUSTER_NAME \
scale deployment monitoring-operator --replicas=0
- Skalakan deployment
cert-manager yang dikelola oleh monitoring-operator ke 0:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
-n cert-manager scale deployment cert-manager --replicas=0
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
-n cert-manager scale deployment cert-manager-cainjector\
--replicas=0
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
-n cert-manager scale deployment cert-manager-webhook --replicas=0
- Instal ulang versi
cert-manager Anda.
Pulihkan
resource yang disesuaikan jika ada.
- Anda dapat melewati langkah ini jika menggunakan
penginstalan cert-manager default upstream, atau Anda yakin
cert-manager diinstal di namespace
cert-manager .
Jika tidak, salin Sertifikat metrics-ca cert-manager.io/v1 dan resource Penerbit metrics-pki.cluster.local dari cert-manager ke namespace resource cluster dari cert-manager yang terinstal.
relevant_fields='
{
apiVersion: .apiVersion,
kind: .kind,
metadata: {
name: .metadata.name,
namespace: "YOUR_INSTALLED_CERT_MANAGER_NAMESPACE"
},
spec: .spec
}
'
f1=$(mktemp)
f2=$(mktemp)
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
get issuer -n cert-manager metrics-pki.cluster.local -o json \
| jq "${relevant_fields}" > $f1
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
get certificate -n cert-manager metrics-ca -o json \
| jq "${relevant_fields}" > $f2
kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f $f1
kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f $f2
Memulihkan pengelola sertifikat Anda sendiri di cluster admin
Secara umum, Anda tidak perlu menginstal ulang cert-manager di cluster admin karena cluster admin hanya menjalankan workload bidang kontrol Google Distributed Cloud. Dalam kasus yang jarang terjadi, ketika Anda juga perlu menginstal pengelola sertifikat Anda sendiri di cluster admin, harap ikuti petunjuk berikut untuk menghindari konflik. Perlu diperhatikan, jika Anda adalah pelanggan Apigee dan
hanya memerlukan cert-manager untuk Apigee, Anda tidak perlu menjalankan
perintah cluster admin.
- Skalakan deployment
monitoring-operator ke 0.
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
-n kube-system scale deployment monitoring-operator --replicas=0
- Skalakan deployment
cert-manager yang dikelola oleh monitoring-operator ke 0.
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
-n cert-manager scale deployment cert-manager \
--replicas=0
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
-n cert-manager scale deployment cert-manager-cainjector \
--replicas=0
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
-n cert-manager scale deployment cert-manager-webhook \
--replicas=0
- Instal ulang versi
cert-manager Anda.
Pulihkan
resource yang disesuaikan jika ada.
- Anda dapat melewati langkah ini jika menggunakan
penginstalan cert-manager default upstream, atau Anda yakin
cert-manager diinstal di namespace
cert-manager .
Jika tidak, salin Sertifikat metrics-ca cert-manager.io/v1 dan resource Penerbit metrics-pki.cluster.local dari cert-manager ke namespace resource cluster dari cert-manager yang terinstal.
relevant_fields='
{
apiVersion: .apiVersion,
kind: .kind,
metadata: {
name: .metadata.name,
namespace: "YOUR_INSTALLED_CERT_MANAGER_NAMESPACE"
},
spec: .spec
}
'
f3=$(mktemp)
f4=$(mktemp)
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \n
get issuer -n cert-manager metrics-pki.cluster.local -o json \
| jq "${relevant_fields}" > $f3
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
get certificate -n cert-manager metrics-ca -o json \
| jq "${relevant_fields}" > $f4
kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f $f3
kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f $f4
</p |
Sistem operasi |
1.10, 1.11, 1.12, 1.13 |
Positif palsu dalam pemindaian kerentanan Docker, containerd, dan runc
Docker, containerd, dan runc di image OS Ubuntu yang dikirimkan bersama Google Distributed Cloud disematkan ke versi khusus menggunakan Ubuntu PPA. Langkah ini memastikan bahwa setiap perubahan runtime container akan memenuhi syarat oleh Google Distributed Cloud sebelum setiap rilis.
Namun, versi khusus ini tidak dikenal oleh Ubuntu CVE Tracker, yang digunakan sebagai feed kerentanan oleh berbagai alat pemindaian CVE. Oleh karena itu, Anda akan melihat positif palsu (PP) di hasil pemindaian kerentanan Docker, containerd, dan runc.
Misalnya, Anda mungkin melihat positif palsu berikut dari hasil pemindaian CVE. CVE ini telah diperbaiki dalam versi patch terbaru Google Distributed Cloud.
Lihat catatan rilis] untuk mengetahui perbaikan CVE.
Solusi:
Kanonis mengetahui masalah ini, dan perbaikannya dilacak di
https://github.com/canonical/sec-cvescan/issues/73.
|
Upgrade, Update |
1.10, 1.11, 1.12, 1.13 |
Koneksi jaringan antara admin dan cluster pengguna mungkin tidak tersedia dalam waktu singkat selama upgrade cluster non-HA
Jika mengupgrade cluster non-HA dari 1.9 ke 1.10, Anda mungkin memperhatikan
bahwa kubectl exec , kubectl log , dan webhook
terhadap cluster pengguna mungkin tidak tersedia untuk waktu yang singkat. Periode nonaktif ini dapat berlangsung hingga satu menit. Hal ini terjadi karena permintaan masuk (kubectl exec, kubectl log, dan webhook) ditangani oleh kube-apiserver untuk cluster pengguna. kube-apiserver pengguna adalah
Statefulset. Dalam cluster non-HA, hanya ada satu replika untuk Statefulset. Jadi, selama proses upgrade, ada kemungkinan kube-apiserver lama tidak tersedia sedangkan kube-apiserver baru belum siap.
Solusi:
Periode nonaktif ini hanya terjadi selama proses upgrade. Jika menginginkan periode nonaktif yang lebih singkat selama upgrade, sebaiknya Anda beralih ke cluster HA.
|
Penginstalan, Upgrade, Update |
1.10, 1.11, 1.12, 1.13 |
Pemeriksaan kesiapan konektivitas gagal dalam diagnosis cluster HA setelah
pembuatan atau upgrade cluster
Jika Anda membuat atau mengupgrade cluster HA dan melihat bahwa pemeriksaan kesiapan konektivitas gagal dalam mendiagnosis cluster, dalam sebagian besar kasus, hal ini tidak akan memengaruhi fungsi Google Distributed Cloud (kubectl exec, kubectl log, dan webhook). Hal ini terjadi karena terkadang satu atau dua
replika konektivitas mungkin tidak siap selama jangka waktu tertentu karena
jaringan yang tidak stabil atau masalah lainnya.
Solusi:
Konnektivitas akan pulih dengan sendirinya. Tunggu selama 30 menit hingga 1 jam
dan jalankan kembali diagnosis cluster.
|
Sistem operasi |
1.7, 1.8, 1.9, 1.10, 1.11 |
/etc/cron.daily/aide masalah lonjakan CPU dan memori
Mulai dari Google Distributed Cloud versi 1.7.2, OS image Ubuntu
di-hardening dengan
Benchmark Server
CIS L1.
Hasilnya, skrip cron /etc/cron.daily/aide telah diinstal sehingga pemeriksaan aide dijadwalkan untuk memastikan bahwa aturan Server CIS L1 "1.4.2 Memastikan integritas sistem file diperiksa secara rutin" diikuti.
cron job berjalan setiap hari pada pukul 06.25 UTC. Bergantung pada jumlah
file pada sistem file, Anda mungkin mengalami lonjakan penggunaan CPU dan memori
pada waktu tersebut yang disebabkan oleh proses aide ini.
Solusi:
Jika lonjakan memengaruhi beban kerja, Anda dapat menonaktifkan cron job harian:
sudo chmod -x /etc/cron.daily/aide
|
Networking |
1.10, 1.11, 1.12, 1.13 |
Load balancer dan aturan firewall terdistribusi stateful NSX-T berinteraksi secara tidak terduga
Saat men-deploy Google Distributed Cloud versi 1.9 atau yang lebih baru, jika deployment memiliki load balancer yang dipaketkan Seesaw di lingkungan yang menggunakan aturan firewall terdistribusi stateful NSX-T, stackdriver-operator mungkin gagal membuat gke-metrics-agent-conf ConfigMap dan menyebabkan Pod gke-connect-agent mengalami loop error.
Masalah pokoknya adalah aturan firewall terdistribusi NSX-T stateful menghentikan koneksi dari klien ke server API cluster pengguna melalui load balancer Seesaw karena Seesaw menggunakan alur koneksi asimetris. Masalah integrasi dengan aturan firewall terdistribusi NSX-T memengaruhi semua rilis Google Distributed Cloud yang menggunakan Seesaw. Anda
mungkin melihat masalah koneksi serupa di aplikasi Anda sendiri saat
membuat objek Kubernetes besar yang ukurannya lebih dari 32 ribu.
Solusi:
Ikuti
petunjuk ini untuk menonaktifkan aturan firewall terdistribusi NSX-T, atau menggunakan aturan firewall terdistribusi stateless untuk Seesaw VM.
Jika cluster Anda menggunakan load balancer manual, ikuti
petunjuk ini untuk mengonfigurasi load balancer agar dapat mereset koneksi klien saat cluster mendeteksi kegagalan node backend. Tanpa konfigurasi ini, klien server Kubernetes API dapat berhenti merespons selama beberapa menit saat instance server nonaktif.
|
Logging dan pemantauan |
1.10, 1.11, 1.12, 1.13, 1.14, 1.15 |
Penagihan pemantauan yang tidak terduga
Untuk Google Distributed Cloud versi 1.10 hingga 1.15, beberapa pelanggan
mendapati adanya penagihan tinggi yang tidak terduga untuk Metrics volume di
halaman Billing. Masalah ini hanya memengaruhi Anda jika semua
keadaan berikut terjadi:
- Logging dan pemantauan aplikasi diaktifkan (
enableStackdriverForApplications=true )
- Pod Aplikasi memiliki anotasi
prometheus.io/scrap=true . (Menginstal Cloud Service Mesh juga dapat menambahkan anotasi ini.)
Untuk mengonfirmasi apakah Anda terpengaruh oleh masalah ini, cantumkan metrik yang ditentukan pengguna. Jika Anda melihat penagihan untuk metrik yang tidak diinginkan dengan awalan nama external.googleapis.com/prometheus dan juga melihat enableStackdriverForApplications ditetapkan ke benar sebagai respons dari kubectl -n kube-system get stackdriver stackdriver -o yaml , berarti
masalah ini berlaku untuk Anda.
Solusi
Jika Anda terpengaruh oleh masalah ini, sebaiknya upgrade
cluster Anda ke versi 1.12 atau yang lebih baru, hentikan penggunaan tanda enableStackdriverForApplications , dan beralih ke solusi pemantauan aplikasi baru managed-service-for-prometheus yang tidak lagi mengandalkan anotasi prometheus.io/scrap=true . Dengan solusi baru ini, Anda juga dapat mengontrol pengumpulan log dan metrik secara terpisah untuk aplikasi Anda, dengan flag enableCloudLoggingForApplications dan enableGMPForApplications .
Untuk berhenti menggunakan tanda enableStackdriverForApplications , buka objek `stackdriver` untuk mengedit:
kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG --namespace kube-system edit stackdriver stackdriver
Hapus baris enableStackdriverForApplications: true , simpan dan tutup editor.
Jika Anda tidak dapat beralih dari pengumpulan metrik berbasis anotasi, ikuti langkah-langkah berikut:
- Temukan Pod dan Layanan sumber yang memiliki metrik penagihan yang tidak diinginkan.
kubectl --kubeconfig KUBECONFIG \
get pods -A -o yaml | grep 'prometheus.io/scrape: "true"'
kubectl --kubeconfig KUBECONFIG get \
services -A -o yaml | grep 'prometheus.io/scrape: "true"'
- Hapus anotasi
prometheus.io/scrap=true dari Pod atau Service. Jika anotasi ditambahkan oleh Cloud Service Mesh, pertimbangkan untuk mengonfigurasi Cloud Service Mesh tanpa opsi Prometheus, atau menonaktifkan fitur Istio Metrics Penggabungan.
|
Penginstalan |
1.11, 1.12, 1.13 |
Penginstal gagal saat membuat datadisk vSphere
Penginstal Google Distributed Cloud dapat gagal jika peran khusus terikat
pada tingkat izin yang salah.
Jika binding peran salah, pembuatan datadisk vSphere dengan govc hang dan disk akan dibuat dengan ukuran yang sama dengan 0. Untuk
memperbaiki masalah ini, Anda harus mengikat peran khusus di level
vSphere (root).
Solusi:
Jika ingin mengikat peran khusus di tingkat DC (atau lebih rendah dari
root), Anda juga harus mengikat peran hanya baca ke pengguna di tingkat
vCenter root.
Untuk informasi selengkapnya tentang pembuatan peran, lihat
hak istimewa akun pengguna vCenter.
|
Logging dan pemantauan |
1.9.0-1.9.4, 1.10.0-1.10.1 |
Traffic jaringan tinggi ke monitoring.googleapis.com
Anda mungkin melihat traffic jaringan yang tinggi ke
monitoring.googleapis.com , bahkan dalam cluster baru yang tidak memiliki
workload pengguna.
Masalah ini memengaruhi versi 1.10.0-1.10.1 dan versi 1.9.0-1.9.4. Masalah
ini telah diperbaiki pada versi 1.10.2 dan 1.9.5.
Solusi:
Lihat langkah-langkah solusi
Upgrade ke versi 1.10.2/1.9.5 atau yang lebih baru.
Untuk mengurangi masalah ini pada versi sebelumnya:
- Turunkan skala `stackdriver-operator`:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system \
scale deployment stackdriver-operator --replicas=0
Ganti USER_CLUSTER_KUBECONFIG dengan jalur file kubeconfig cluster
pengguna.
- Buka
gke-metrics-agent-conf ConfigMap untuk mengedit:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system \
edit configmap gke-metrics-agent-conf
- Tingkatkan interval pemeriksaan dari 0,1 detik menjadi 13 detik:
processors:
disk_buffer/metrics:
backend_endpoint: https://monitoring.googleapis.com:443
buffer_dir: /metrics-data/nsq-metrics-metrics
probe_interval: 13s
retention_size_mib: 6144
disk_buffer/self:
backend_endpoint: https://monitoring.googleapis.com:443
buffer_dir: /metrics-data/nsq-metrics-self
probe_interval: 13s
retention_size_mib: 200
disk_buffer/uptime:
backend_endpoint: https://monitoring.googleapis.com:443
buffer_dir: /metrics-data/nsq-metrics-uptime
probe_interval: 13s
retention_size_mib: 200
- Tutup sesi pengeditan.
- Ubah versi
gke-metrics-agent DaemonSet ke
1.1.0-anthos.8:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system set image daemonset/gke-metrics-agent \
gke-metrics-agent=gcr.io/gke-on-prem-release/gke-metrics-agent:1.1.0-anthos.8
|
Logging dan pemantauan |
1.10, 1.11 |
gke-metrics-agent sering mengalami error CrashLoopBackOff
Untuk Google Distributed Cloud versi 1.10 dan yang lebih baru, `gke-metrics-agent` DaemonSet sering mengalami error CrashLoopBackOff saat `enableStackdriverForApplications` ditetapkan ke `true` dalam objek `stackdriver`.
Solusi:
Untuk mengurangi masalah ini, nonaktifkan pengumpulan metrik aplikasi dengan menjalankan perintah berikut. Perintah ini tidak akan menonaktifkan pengumpulan log aplikasi.
- Agar perubahan berikut tidak dikembalikan, perkecil skala
stackdriver-operator :
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system scale deploy stackdriver-operator \
--replicas=0
Ganti USER_CLUSTER_KUBECONFIG dengan jalur file kubeconfig cluster
pengguna.
- Buka
gke-metrics-agent-conf ConfigMap untuk mengedit:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system edit configmap gke-metrics-agent-conf
- Di bagian
services.pipelines , jadikan seluruh bagian metrics/app-metrics sebagai komentar:
services:
pipelines:
#metrics/app-metrics:
# exporters:
# - googlecloud/app-metrics
# processors:
# - resource
# - metric_to_resource
# - infer_resource
# - disk_buffer/app-metrics
# receivers:
# - prometheus/app-metrics
metrics/metrics:
exporters:
- googlecloud/metrics
processors:
- resource
- metric_to_resource
- infer_resource
- disk_buffer/metrics
receivers:
- prometheus/metrics
- Tutup sesi pengeditan.
- Mulai ulang DaemonSet
gke-metrics-agent :
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system rollout restart daemonset gke-metrics-agent
|
Logging dan pemantauan |
1.11, 1.12, 1.13 |
Mengganti metrik yang tidak digunakan lagi di dasbor
Jika metrik yang tidak digunakan lagi digunakan di dasbor OOTB, Anda akan melihat beberapa diagram kosong. Untuk menemukan metrik yang tidak digunakan lagi di dasbor Monitoring, jalankan perintah berikut:
gcloud monitoring dashboards list > all-dashboard.json
# find deprecated metrics
cat all-dashboard.json | grep -E \
'kube_daemonset_updated_number_scheduled\
|kube_node_status_allocatable_cpu_cores\
|kube_node_status_allocatable_pods\
|kube_node_status_capacity_cpu_cores'
Metrik berikut yang sudah tidak digunakan lagi harus dimigrasikan ke penggantinya.
Tidak digunakan lagi | 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 |
kube_hpa_status_current_replicas |
kube_horizontalpodautoscaler_status_current_replicas |
Solusi:
Untuk mengganti metrik yang tidak digunakan lagi
- Hapus "Status node lokal GKE" di dasbor Google Cloud Monitoring. Instal ulang "status node lokal GKE" dengan mengikuti
petunjuk ini.
- Hapus "Penggunaan node lokal GKE" di dasbor Google Cloud Monitoring. Instal ulang "Pemanfaatan node lokal GKE" dengan mengikuti
petunjuk ini.
- Hapus "kondisi vm vSphere lokal GKE" di dasbor Google Cloud
Monitoring. Instal ulang "kondisi vm vSphere lokal GKE" dengan mengikuti
petunjuk ini.
Penghentian ini disebabkan oleh upgrade agen
kube-state-metrics dari v1.9 ke v2.4, yang diperlukan untuk Kubernetes 1.22. Anda dapat mengganti semua metrik kube-state-metrics yang tidak digunakan lagi, yang memiliki awalan kube_ , di dasbor kustom atau kebijakan pemberitahuan.
|
Logging dan pemantauan |
1.10, 1.11, 1.12, 1.13 |
Data metrik tidak diketahui di Cloud Monitoring
Untuk Google Distributed Cloud versi 1.10 dan yang lebih baru, data untuk cluster di Cloud Monitoring mungkin berisi entri metrik ringkasan yang tidak relevan seperti berikut:
Unknown metric: kubernetes.io/anthos/go_gc_duration_seconds_summary_percentile
Jenis metrik lain yang mungkin memiliki metrik ringkasan yang tidak relevan termasuk .
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
Meskipun metrik jenis ringkasan ini berada dalam daftar metrik, metrik tersebut tidak didukung oleh gke-metrics-agent saat ini.
|
Logging dan pemantauan |
1.10, 1.11, 1.12, 1.13 |
Metrik tidak ada di beberapa node
Anda mungkin mendapati bahwa metrik berikut tidak ada di beberapa node, tetapi tidak semuanya:
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:
Untuk memperbaiki masalah ini, lakukan langkah-langkah berikut sebagai solusinya. Untuk
[versi 1.9.5+, 1.10.2+, 1.11.0]: tingkatkan cpu untuk gke-metrics-agent
dengan mengikuti langkah 1 - 4
- Buka referensi
stackdriver Anda untuk mengedit:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system edit stackdriver stackdriver
- Guna meningkatkan permintaan CPU untuk
gke-metrics-agent dari
10m menjadi 50m , batas CPU dari 100m
menjadi 200m tambahkan bagian resourceAttrOverride
berikut ke manifes stackdriver :
spec:
resourceAttrOverride:
gke-metrics-agent/gke-metrics-agent:
limits:
cpu: 100m
memory: 4608Mi
requests:
cpu: 10m
memory: 200Mi
Resource yang diedit akan terlihat seperti berikut:
spec:
anthosDistribution: on-prem
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: 200m
memory: 4608Mi
requests:
cpu: 50m
memory: 200Mi
- Simpan perubahan Anda dan tutup editor teks.
- Untuk memastikan bahwa perubahan Anda telah diterapkan, jalankan perintah berikut:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system get daemonset gke-metrics-agent -o yaml \
| grep "cpu: 50m"
Perintah ini akan menemukan cpu: 50m jika hasil edit Anda telah diterapkan.
|
Logging dan pemantauan |
1.11.0-1.11.2, 1.12.0 |
Metrik penjadwal dan pengontrol-pengelola tidak ada di cluster admin
Jika cluster admin Anda terpengaruh oleh masalah ini, metrik penjadwal dan pengelola-pengelola tidak akan ada. Misalnya, kedua metrik ini tidak ada
# scheduler metric example
scheduler_pending_pods
# controller-manager metric example
replicaset_controller_rate_limiter_use
Solusi:
Upgrade ke v1.11.3+, v1.12.1+, atau v1.13+.
|
|
1.11.0-1.11.2, 1.12.0 |
Metrik penjadwal dan pengontrol-pengelola tidak ada di cluster pengguna
Jika cluster pengguna Anda terpengaruh oleh masalah ini, metrik penjadwal dan pengontrol-pengelola tidak akan ada. Misalnya, dua metrik berikut tidak ada:
# scheduler metric example
scheduler_pending_pods
# controller-manager metric example
replicaset_controller_rate_limiter_use
Solusi:
Masalah ini telah diperbaiki di Google Distributed Cloud versi 1.13.0 dan yang lebih baru.
Upgrade cluster Anda ke versi yang memiliki perbaikan.
|
Penginstalan, Upgrade, Update |
1.10, 1.11, 1.12, 1.13 |
Gagal mendaftarkan cluster admin selama pembuatan
Jika Anda membuat cluster admin untuk versi 1.9.x atau 1.10.0, dan jika
cluster admin gagal mendaftar dengan spesifikasi gkeConnect
yang disediakan selama pembuatannya, Anda akan mendapatkan error berikut.
Failed to create root cluster: failed to register admin cluster: failed to register cluster: failed to apply Hub Membership: Membership API request failed: rpc error: ode = PermissionDenied desc = Permission 'gkehub.memberships.get' denied on PROJECT_PATH
Anda tetap dapat menggunakan cluster admin ini, tetapi Anda akan mendapatkan error berikut jika nanti mencoba mengupgrade cluster admin ke versi 1.10.y.
failed to migrate to first admin trust chain: failed to parse current version "": invalid version: "" failed to migrate to first admin trust chain: failed to parse current version "": invalid version: ""
Solusi:
Lihat langkah-langkah solusi
Jika error ini terjadi, ikuti langkah-langkah berikut untuk memperbaiki masalah pendaftaran cluster. Setelah melakukan perbaikan ini, Anda dapat mengupgrade cluster admin.
- Jalankan
gkectl update admin untuk mendaftarkan cluster admin dengan kunci akun layanan yang benar.
- Buat akun layanan khusus untuk mem-patch
resource kustom
OnPremAdminCluster .
export KUBECONFIG=ADMIN_CLUSTER_KUBECONFIG
# Create Service Account modify-admin
kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
name: modify-admin
namespace: kube-system
EOF
# Create ClusterRole
kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
creationTimestamp: null
name: modify-admin-role
rules:
- apiGroups:
- "onprem.cluster.gke.io"
resources:
- "onpremadminclusters/status"
verbs:
- "patch"
EOF
# Create ClusterRoleBinding for binding the permissions to the modify-admin SA
kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
creationTimestamp: null
name: modify-admin-rolebinding
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: modify-admin-role
subjects:
- kind: ServiceAccount
name: modify-admin
namespace: kube-system
EOF
Ganti ADMIN_CLUSTER_KUBECONFIG dengan jalur file kubeconfig cluster
admin Anda.
- Jalankan perintah ini untuk memperbarui
resource kustom
OnPremAdminCluster .
export KUBECONFIG=ADMIN_CLUSTER_KUBECONFIG
SERVICE_ACCOUNT=modify-admin
SECRET=$(kubectl get serviceaccount ${SERVICE_ACCOUNT} \
-n kube-system -o json \
| jq -Mr '.secrets[].name | select(contains("token"))')
TOKEN=$(kubectl get secret ${SECRET} -n kube-system -o json \
| jq -Mr '.data.token' | base64 -d)
kubectl get secret ${SECRET} -n kube-system -o json \
| jq -Mr '.data["ca.crt"]' \
| base64 -d > /tmp/ca.crt
APISERVER=https://$(kubectl -n default get endpoints kubernetes \
--no-headers | awk '{ print $2 }')
# Find out the admin cluster name and gkeOnPremVersion from the OnPremAdminCluster CR
ADMIN_CLUSTER_NAME=$(kubectl get onpremadmincluster -n kube-system \
--no-headers | awk '{ print $1 }')
GKE_ON_PREM_VERSION=$(kubectl get onpremadmincluster \
-n kube-system $ADMIN_CLUSTER_NAME \
-o=jsonpath='{.spec.gkeOnPremVersion}')
# Create the Status field and set the gkeOnPremVersion in OnPremAdminCluster CR
curl -H "Accept: application/json" \
--header "Authorization: Bearer $TOKEN" -XPATCH \
-H "Content-Type: application/merge-patch+json" \
--cacert /tmp/ca.crt \
--data '{"status": {"gkeOnPremVersion": "'$GKE_ON_PREM_VERSION'"}}' \
$APISERVER/apis/onprem.cluster.gke.io/v1alpha1/namespaces/kube-system/onpremadminclusters/$ADMIN_CLUSTER_NAME/status
- Coba upgrade cluster admin lagi dengan
tanda
--disable-upgrade-from-checkpoint .
gkectl upgrade admin --config ADMIN_CLUSTER_CONFIG \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--disable-upgrade-from-checkpoint
Ganti ADMIN_CLUSTER_CONFIG dengan jalur file konfigurasi cluster
admin Anda.
|
Identitas |
1.10, 1.11, 1.12, 1.13 |
Penggunaan GKE Identity Service dapat menyebabkan
Agen Connect memulai ulang secara tak terduga
Jika Anda menggunakan fitur
GKE Identity Service
untuk mengelola
GKE Identity Service ClientConfig,
Connect Agent mungkin akan dimulai ulang secara tiba-tiba.
Solusi:
Jika pernah mengalami masalah ini pada cluster yang ada, Anda dapat melakukan salah satu tindakan berikut:
|
Networking |
1.10, 1.11, 1.12, 1.13 |
Cisco ACI tidak berfungsi dengan Direct Server Return (DSR)
Seesaw berjalan dalam mode DSR, dan secara default tidak berfungsi pada Cisco ACI karena pembelajaran IP bidang data.
Solusi:
Solusi yang dapat dilakukan adalah menonaktifkan pembelajaran IP dengan menambahkan alamat IP Seesaw sebagai IP Virtual L4-L7 di Cisco Application Policy Infrastructure Controller (APIC).
Anda dapat mengonfigurasi opsi L4-L7 Virtual IP dengan membuka Tenant > Application Profiles > Application EPGs atau uSeg EPGs. Kegagalan untuk menonaktifkan pembelajaran IP akan menyebabkan flapping endpoint IP di antara lokasi yang berbeda di fabric Cisco API.
|
VMware |
1.10, 1.11, 1.12, 1.13 |
vSphere 7.0 Memperbarui 3 masalah
VMWare baru-baru ini mengidentifikasi masalah kritis pada rilis vSphere 7.0 Update 3 berikut:
- vSphere ESXi 7.0 Pembaruan 3 (build 18644231)
- vSphere ESXi 7.0 Pembaruan 3a (build 18825058)
- vSphere ESXi 7.0 Pembaruan 3b (build 18905247)
- vSphere vCenter 7.0 Pembaruan 3b (build 18901211)
Solusi:
VMWare menghapus rilis ini. Anda harus mengupgrade
ESXi dan
Server
vCenter ke versi yang lebih baru.
|
Sistem operasi |
1.10, 1.11, 1.12, 1.13 |
Gagal memasang volume emptyDir sebagai exec ke dalam Pod yang berjalan
di node COS
Untuk Pod yang berjalan di node yang menggunakan image Container-Optimized OS (COS), Anda tidak dapat memasang volume emptyDir sebagai exec . Kode ini dipasang sebagai noexec dan Anda akan mendapatkan error berikut: exec user
process caused: permission denied . Misalnya, Anda akan melihat pesan error ini jika men-deploy Pod pengujian berikut:
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: test
name: test
spec:
containers:
- args:
- sleep
- "5000"
image: gcr.io/google-containers/busybox:latest
name: test
volumeMounts:
- name: test-volume
mountPath: /test-volume
resources:
limits:
cpu: 200m
memory: 512Mi
dnsPolicy: ClusterFirst
restartPolicy: Always
volumes:
- emptyDir: {}
name: test-volume
Di Pod pengujian, jika Anda menjalankan mount | grep test-volume , opsi noexec akan muncul:
/dev/sda1 on /test-volume type ext4 (rw,nosuid,nodev,noexec,relatime,commit=30)
Solusi:
Lihat langkah-langkah solusi
Terapkan resource DaemonSet, misalnya:
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: fix-cos-noexec
namespace: kube-system
spec:
selector:
matchLabels:
app: fix-cos-noexec
template:
metadata:
labels:
app: fix-cos-noexec
spec:
hostIPC: true
hostPID: true
containers:
- name: fix-cos-noexec
image: ubuntu
command: ["chroot", "/host", "bash", "-c"]
args:
- |
set -ex
while true; do
if ! $(nsenter -a -t 1 findmnt -l | grep -qe "^/var/lib/kubelet\s"); then
echo "remounting /var/lib/kubelet with exec"
nsenter -a -t 1 mount --bind /var/lib/kubelet /var/lib/kubelet
nsenter -a -t 1 mount -o remount,exec /var/lib/kubelet
fi
sleep 3600
done
volumeMounts:
- name: host
mountPath: /host
securityContext:
privileged: true
volumes:
- name: host
hostPath:
path: /
|
Upgrade, Update |
1.10, 1.11, 1.12, 1.13 |
Update replika kumpulan node cluster tidak berfungsi setelah penskalaan otomatis dinonaktifkan di kumpulan node
Replika kumpulan node tidak diupdate setelah penskalaan otomatis diaktifkan dan dinonaktifkan pada kumpulan node.
Solusi:
Menghapus anotasi cluster.x-k8s.io/cluster-api-autoscaler-node-group-max-size dan cluster.x-k8s.io/cluster-api-autoscaler-node-group-min-size dari deployment mesin untuk kumpulan node yang terkait.
|
Logging dan pemantauan |
1.11, 1.12, 1.13 |
Dasbor pemantauan Windows menampilkan data dari cluster Linux
Mulai versi 1.11, pada dasbor pemantauan siap pakai, dasbor status Pod Windows dan dasbor status node Windows juga menampilkan data dari cluster Linux. Hal ini karena node Windows dan metrik Pod juga diekspos di cluster Linux.
|
Logging dan pemantauan |
1.10, 1.11, 1.12 |
stackdriver-log-forwarder dalam CrashLoopBackOff yang konstan
Untuk Google Distributed Cloud versi 1.10, 1.11, dan 1.12, stackdriver-log-forwarder
DaemonSet mungkin mengalami error CrashLoopBackOff saat ada
log buffer yang rusak di disk.
Solusi:
Untuk mengurangi masalah ini, kita perlu membersihkan log yang di-buffer pada node.
- Untuk mencegah perilaku tidak terduga ini, turunkan skala
stackdriver-log-forwarder :
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
-n kube-system patch daemonset stackdriver-log-forwarder -p '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'
Ganti USER_CLUSTER_KUBECONFIG dengan jalur file
kubeconfig cluster pengguna.
- Deploy DaemonSet pembersihan untuk membersihkan potongan yang rusak:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
-n kube-system -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
- Untuk memastikan DaemonSet pembersihan telah membersihkan semua potongan, Anda dapat menjalankan perintah berikut. Output kedua perintah tersebut
harus sama dengan nomor node Anda dalam cluster:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
logs -n kube-system -l app=fluent-bit-cleanup | grep "cleaned up" | wc -l
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
-n kube-system get pods -l app=fluent-bit-cleanup --no-headers | wc -l
- Hapus DaemonSet pembersihan:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
-n kube-system delete ds fluent-bit-cleanup
- Lanjutkan
stackdriver-log-forwarder :
kubectl --kubeconfig USER_CLUSTER_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 |
stackdriver-log-forwarder tidak mengirim log ke Cloud Logging
Jika Anda tidak melihat log di Cloud Logging dari cluster, dan melihat error berikut di log:
2023-06-02T10:53:40.444017427Z [2023/06/02 10:53:40] [error] [input chunk] chunk 1-1685703077.747168499.flb would exceed total limit size in plugin stackdriver.0
2023-06-02T10:53:40.444028047Z [2023/06/02 10:53:40] [error] [input chunk] no available chunk
Sepertinya rasio input log melebihi batas agen logging,
yang menyebabkan stackdriver-log-forwarder tidak mengirim log.
Masalah ini terjadi di semua versi Google Distributed Cloud.
Solusi:
Untuk mengurangi masalah ini, Anda perlu meningkatkan batas resource pada
agen logging.
- Buka referensi
stackdriver Anda untuk mengedit:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system edit stackdriver stackdriver
- Guna meningkatkan permintaan CPU untuk
stackdriver-log-forwarder ,
tambahkan bagian resourceAttrOverride berikut
ke manifes stackdriver :
spec:
resourceAttrOverride:
stackdriver-log-forwarder/stackdriver-log-forwarder:
limits:
cpu: 1200m
memory: 600Mi
requests:
cpu: 600m
memory: 600Mi
Resource yang diedit akan terlihat seperti berikut:
spec:
anthosDistribution: on-prem
clusterLocation: us-west1-a
clusterName: my-cluster
enableStackdriverForApplications: true
gcpServiceAccountSecretName: ...
optimizedMetrics: true
portable: true
projectID: my-project-191923
proxyConfigSecretName: ...
resourceAttrOverride:
stackdriver-log-forwarder/stackdriver-log-forwarder:
limits:
cpu: 1200m
memory: 600Mi
requests:
cpu: 600m
memory: 600Mi
- Simpan perubahan Anda dan tutup editor teks.
- Untuk memastikan bahwa perubahan Anda telah diterapkan, jalankan perintah berikut:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system get daemonset stackdriver-log-forwarder -o yaml \
| grep "cpu: 1200m"
Perintah ini akan menemukan cpu: 1200m jika hasil edit Anda telah diterapkan.
|
Keamanan |
1.13 |
Layanan Kubelet tidak akan tersedia untuk sementara setelah NodeReady
ada kalanya node siap, tetapi sertifikat server kubelet belum siap. kubectl exec dan kubectl logs tidak tersedia selama puluhan detik ini.
Hal ini karena perlu waktu bagi pemberi persetujuan sertifikat server baru untuk
melihat IP valid node yang diupdate.
Masalah ini hanya memengaruhi sertifikat server kubelet dan tidak akan memengaruhi
penjadwalan Pod.
|
Upgrade, Update |
1.12 |
Upgrade cluster admin sebagian tidak memblokir upgrade cluster pengguna yang lebih baru
Upgrade cluster pengguna gagal dengan:
.LBKind in body is required (Check the status of OnPremUserCluster 'cl-stg-gdl-gke-onprem-mgmt/cl-stg-gdl' and the logs of pod 'kube-system/onprem-user-cluster-controller' for more detailed debugging information.
Cluster admin belum diupgrade sepenuhnya, dan versi statusnya masih 1.10. Upgrade cluster pengguna ke 1.12 tidak akan diblokir oleh pemeriksaan preflight, dan gagal dengan masalah kemiringan versi.
Solusi:
Selesaikan untuk mengupgrade cluster admin ke 1.11 terlebih dahulu, lalu upgrade
cluster pengguna ke 1.12.
|
Penyimpanan |
1.10.0-1.10.5, 1.11.0-1.11.2, 1.12.0 |
Datastore salah melaporkan ruang kosong yang tidak cukup
Perintah gkectl diagnose cluster gagal dengan:
Checking VSphere Datastore FreeSpace...FAILURE
Reason: vCenter datastore: [DATASTORE_NAME] insufficient FreeSpace, requires at least [NUMBER] GB
Validasi ruang kosong datastore tidak boleh digunakan untuk kumpulan node cluster yang ada, dan tidak sengaja ditambahkan di gkectl diagnose cluster .
Solusi:
Anda dapat mengabaikan pesan error atau melewati validasi menggunakan --skip-validation-infra .
|
Operasi, Jaringan |
1.11, 1.12.0-1.12.1 |
Anda mungkin tidak dapat menambahkan cluster pengguna baru jika cluster admin Anda disiapkan dengan konfigurasi load balancer MetalLB.
Proses penghapusan cluster pengguna mungkin terhenti karena alasan tertentu yang mengakibatkan pembatalan validasi MatalLB ConfigMap. Anda tidak dapat menambahkan cluster pengguna baru dalam status ini.
Solusi:
Anda dapat
menghapus paksa cluster pengguna.
|
Penginstalan, Sistem operasi |
1.10, 1.11, 1.12, 1.13 |
Gagal saat menggunakan Container-Optimized OS (COS) untuk cluster pengguna
Jika osImageType menggunakan cos untuk cluster admin, dan ketika gkectl check-config dijalankan setelah pembuatan cluster admin dan sebelum pembuatan cluster pengguna, cluster akan gagal pada:
Failed to create the test VMs: VM failed to get IP addresses on the network.
VM pengujian yang dibuat untuk cluster pengguna check-config secara default menggunakan osImageType yang sama dari cluster admin, dan saat ini VM pengujian belum kompatibel dengan COS.
Solusi:
Untuk menghindari pemeriksaan preflight lambat yang membuat VM pengujian, gunakan gkectl check-config --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config
USER_CLUSTER_CONFIG --fast .
|
Logging dan pemantauan |
1.12.0-1.12.1 |
Grafana di cluster admin tidak dapat menjangkau cluster pengguna
Masalah ini memengaruhi pelanggan yang menggunakan Grafana di cluster admin untuk memantau cluster pengguna di Google Distributed Cloud versi 1.12.0 dan 1.12.1. Error ini berasal dari ketidakcocokan sertifikat klien pushprox di cluster pengguna dan daftar yang diizinkan di server pushprox pada cluster admin.
Gejalanya adalah pushprox-client di cluster pengguna yang mencetak log error seperti berikut:
level=error ts=2022-08-02T13:34:49.41999813Z caller=client.go:166 msg="Error reading request:" err="invalid method \"RBAC:\""
Solusi:
Lihat langkah-langkah solusi
lakukan langkah-langkah berikut:
- Menurunkan skala deployment operator pemantauan di namespace sistem kube-system cluster admin.
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--namespace kube-system scale deploy monitoring-operator \
--replicas=0
- Edit ConfigMap
pushprox-server-rbac-proxy-config di namespace kube-system cluster admin.
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--namespace kube-system edit cm pushprox-server-rbac-proxy-config
Cari baris principals untuk pemroses external-pushprox-server-auth-proxy dan perbaiki principal_name untuk semua cluster pengguna dengan menghapus substring kube-system dari pushprox-client.metrics-consumers.kube-system.cluster. . Konfigurasi baru akan terlihat seperti berikut:
permissions:
- or_rules:
rules:
- header: { name: ":path", exact_match: "/poll" }
- header: { name: ":path", exact_match: "/push" }
principals: [{"authenticated":{"principal_name":{"exact":"pushprox-client.metrics-consumers.kube-system.cluster.local"}}},{"authenticated":{"principal_name":{"exact":"pushprox-client.metrics-consumers.kube-system.cluster."}}},{"authenticated":{"principal_name":{"exact":"pushprox-client.metrics-consumers.cluster."}}}]
- Mulai ulang deployment
pushprox-server di cluster admin dan deployment pushprox-client di cluster pengguna yang terpengaruh:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system rollout restart deploy pushprox-server
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system rollout restart deploy pushprox-client
- Langkah sebelumnya akan menyelesaikan masalah tersebut. Setelah cluster diupgrade ke versi 1.12.2 dan yang lebih baru setelah masalah diperbaiki, tingkatkan skala operator pemantauan sistem kube-system cluster admin agar dapat mengelola pipeline lagi.
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system scale deploy monitoring-operator --replicas=1
|
Lainnya |
1.11.3 |
gkectl repair admin-master tidak menyediakan template VM yang akan digunakan untuk pemulihan
Perintah gkectl repair admin-master gagal dengan:
Failed to repair: failed to select the template: no VM templates is available for repairing the admin master (check if the admin cluster version >= 1.4.0 or contact support
gkectl repair admin-master tidak dapat mengambil template VM yang akan digunakan untuk memperbaiki VM bidang kontrol admin jika nama VM bidang kontrol admin diakhiri dengan karakter t , m , p , atau l .
Solusi:
Jalankan kembali perintah dengan --skip-validation .
|
Logging dan pemantauan |
1.11, 1.12, 1.13, 1.14, 1.15, 1.16 |
Kegagalan logging audit cloud karena izin ditolak
Cloud Audit Logs memerlukan penyiapan izin khusus yang saat ini hanya dilakukan secara otomatis untuk cluster pengguna melalui GKE Hub.
Sebaiknya Anda memiliki minimal satu cluster pengguna yang menggunakan project ID dan akun layanan yang sama dengan cluster admin untuk Cloud Audit Logs, sehingga cluster admin akan memiliki izin yang diperlukan.
Namun, jika cluster admin menggunakan project ID yang berbeda atau akun layanan yang berbeda dengan cluster pengguna mana pun, log audit dari cluster admin akan gagal dimasukkan ke Google Cloud. Gejalanya adalah serangkaian error Permission Denied pada Pod audit-proxy di cluster admin.
Solusi:
Lihat langkah-langkah solusi
Untuk mengatasi masalah ini, izin dapat disiapkan dengan berinteraksi dengan
fitur Hub cloudauditlogging :
- Pertama-tama, periksa apakah akun layanan yang ada dan diizinkan untuk Cloud Audit Logs di project Anda:
curl -H "Authorization: Bearer $(gcloud auth print-access-token)" \
https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features/cloudauditlogging
- Bergantung pada responsnya, lakukan salah satu tindakan berikut:
- Jika Anda menerima error
404 Not_found , artinya tidak ada akun layanan yang diizinkan untuk project ID ini. Anda dapat mengizinkan akun layanan dengan mengaktifkan fitur Hub cloudauditlogging :
curl -X POST -H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features?feature_id=cloudauditlogging -d \
'{"spec":{"cloudauditlogging":{"allowlistedServiceAccounts":["SERVICE_ACCOUNT_EMAIL"]}}}'
- Jika Anda menerima spesifikasi fitur yang berisi
"lifecycleState": "ENABLED" dengan "code":
"OK" dan daftar akun layanan di allowlistedServiceAccounts , artinya ada akun layanan yang diizinkan untuk project ini, Anda dapat menggunakan akun layanan dari daftar ini di cluster, atau menambahkan akun layanan baru ke daftar yang diizinkan:
curl -X PATCH -H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features/cloudauditlogging?update_mask=spec.cloudauditlogging.allowlistedServiceAccounts -d \
'{"spec":{"cloudauditlogging":{"allowlistedServiceAccounts":["SERVICE_ACCOUNT_EMAIL"]}}}'
- Jika Anda menerima spesifikasi fitur yang berisi
"lifecycleState": "ENABLED" dengan "code":
"FAILED" , berarti penyiapan izin tidak berhasil.
Coba atasi masalah di kolom description pada respons, atau cadangkan daftar yang diizinkan saat ini, hapus fitur hub cloudauditlogging, dan aktifkan kembali setelah langkah 1 di bagian ini lagi. Anda dapat menghapus fitur Hub cloudauditlogging
dengan:
curl -X DELETE -H "Authorization: Bearer $(gcloud auth print-access-token)" \
https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features/cloudauditlogging
Dalam perintah di atas:
|
Operasi, Keamanan |
1,11 |
gkectl diagnose kegagalan pemeriksaan sertifikat
Jika stasiun kerja Anda tidak memiliki akses ke node pekerja cluster pengguna,
stasiun kerja tersebut akan mengalami kegagalan berikut saat menjalankan
gkectl diagnose :
Checking user cluster certificates...FAILURE
Reason: 3 user cluster certificates error(s).
Unhealthy Resources:
Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
Jika stasiun kerja Anda tidak memiliki akses ke node pekerja cluster admin atau node pekerja cluster admin, kegagalan berikut akan terjadi saat menjalankan gkectl diagnose :
Checking admin cluster certificates...FAILURE
Reason: 3 admin cluster certificates error(s).
Unhealthy Resources:
Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
Solusi:
Jika aman untuk mengabaikan pesan ini.
|
Sistem operasi |
1.8, 1.9, 1.10, 1.11, 1.12, 1.13 |
/var/log/audit/ mengisi ruang disk di VM
/var/log/audit/ diisi dengan log audit. Anda dapat memeriksa
penggunaan disk dengan menjalankan sudo du -h -d 1 /var/log/audit .
Perintah gkectl tertentu di workstation admin, misalnya, gkectl diagnose snapshot berkontribusi pada penggunaan
ruang disk.
Sejak Google Distributed Cloud v1.8, image Ubuntu di-hardening dengan Benchmark
CIS Level 2. Selain itu, salah satu aturan kepatuhan, "4.1.2.2 Memastikan log audit tidak otomatis dihapus", memastikan setelan max_log_file_action = keep_logs yang diaudit. Hasilnya, semua aturan audit disimpan di disk.
Solusi:
Lihat langkah-langkah solusi
Stasiun kerja admin
Untuk workstation admin, Anda dapat mengubah setelan yang diaudit secara manual untuk merotasi log secara otomatis, lalu memulai ulang layanan yang diaudit:
sed -i 's/max_log_file_action = keep_logs/max_log_file_action = rotate/g' /etc/audit/auditd.conf
sed -i 's/num_logs = .*/num_logs = 250/g' /etc/audit/auditd.conf
systemctl restart auditd
Setelan di atas akan membuat log yang diaudit secara otomatis merotasi setelah membuat lebih dari 250 file (masing-masing berukuran 8 juta).
Node cluster
Untuk node cluster, upgrade ke 1.11.5+, 1.12.4+, 1.13.2+, atau 1.14+. Jika
Anda belum dapat mengupgrade ke versi tersebut, terapkan DaemonSet berikut ke cluster Anda:
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: change-auditd-log-action
namespace: kube-system
spec:
selector:
matchLabels:
app: change-auditd-log-action
template:
metadata:
labels:
app: change-auditd-log-action
spec:
hostIPC: true
hostPID: true
containers:
- name: update-audit-rule
image: ubuntu
command: ["chroot", "/host", "bash", "-c"]
args:
- |
while true; do
if $(grep -q "max_log_file_action = keep_logs" /etc/audit/auditd.conf); then
echo "updating auditd max_log_file_action to rotate with a max of 250 files"
sed -i 's/max_log_file_action = keep_logs/max_log_file_action = rotate/g' /etc/audit/auditd.conf
sed -i 's/num_logs = .*/num_logs = 250/g' /etc/audit/auditd.conf
echo "restarting auditd"
systemctl restart auditd
else
echo "auditd setting is expected, skip update"
fi
sleep 600
done
volumeMounts:
- name: host
mountPath: /host
securityContext:
privileged: true
volumes:
- name: host
hostPath:
path: /
Perhatikan bahwa melakukan perubahan konfigurasi yang diaudit ini akan melanggar aturan CIS Level 2 "4.1.2.2 Memastikan log audit tidak dihapus secara otomatis".
|
Networking |
1.10, 1.11.0-1.11.3, 1.12.0-1.12.2, 1.13.0 |
NetworkGatewayGroup IP mengambang bertentangan dengan alamat node
Pengguna tidak dapat membuat atau memperbarui objek NetworkGatewayGroup karena error webhook validasi berikut:
[1] admission webhook "vnetworkgatewaygroup.kb.io" denied the request: NetworkGatewayGroup.networking.gke.io "default" is invalid: [Spec.FloatingIPs: Invalid value: "10.0.0.100": IP address conflicts with node address with name: "my-node-name"
Pada versi yang terdampak, kubelet dapat keliru mengikat ke alamat IP mengambang
yang ditetapkan ke node dan melaporkannya sebagai alamat node di
node.status.addresses . Webhook yang memvalidasi akan memeriksa
alamat IP mengambang NetworkGatewayGroup terhadap semua
node.status.addresses dalam cluster dan melihatnya sebagai
konflik.
Solusi:
Di cluster yang sama tempat pembuatan atau update objek NetworkGatewayGroup gagal, nonaktifkan sementara untuk validasi webhook ANG dan kirim perubahan Anda:
- Simpan konfigurasi webhook agar dapat dipulihkan di bagian akhir:
kubectl -n kube-system get validatingwebhookconfiguration \
ang-validating-webhook-configuration -o yaml > webhook-config.yaml
- Edit konfigurasi webhook:
kubectl -n kube-system edit validatingwebhookconfiguration \
ang-validating-webhook-configuration
- Hapus item
vnetworkgatewaygroup.kb.io dari daftar konfigurasi webhook dan tutup untuk menerapkan perubahan.
- Buat atau edit objek
NetworkGatewayGroup Anda.
- Terapkan ulang konfigurasi webhook asli:
kubectl -n kube-system apply -f webhook-config.yaml
|
Penginstalan, Upgrade, Update |
1.10.0-1.10.2 |
Waktu tunggu pembuatan atau upgrade cluster admin telah habis
Selama upaya upgrade cluster admin, VM bidang kontrol admin mungkin macet selama pembuatan. VM bidang kontrol admin mengalami
loop tunggu tanpa batas selama booting, dan Anda akan melihat
error loop tanpa batas berikut di file
/var/log/cloud-init-output.log :
+ echo 'waiting network configuration is applied'
waiting network configuration is applied
++ get-public-ip
+++ ip addr show dev ens192 scope global
+++ head -n 1
+++ grep -v 192.168.231.1
+++ grep -Eo 'inet ([0-9]{1,3}\.){3}[0-9]{1,3}'
+++ awk '{print $2}'
++ echo
+ '[' -n '' ']'
+ sleep 1
+ echo 'waiting network configuration is applied'
waiting network configuration is applied
++ get-public-ip
+++ ip addr show dev ens192 scope global
+++ grep -Eo 'inet ([0-9]{1,3}\.){3}[0-9]{1,3}'
+++ awk '{print $2}'
+++ grep -v 192.168.231.1
+++ head -n 1
++ echo
+ '[' -n '' ']'
+ sleep 1
Hal ini terjadi karena ketika Google Distributed Cloud mencoba mendapatkan alamat IP node
dalam skrip startup, Google Distributed Cloud akan menggunakan grep -v
ADMIN_CONTROL_PLANE_VIP untuk melewati VIP bidang kontrol cluster admin
yang dapat ditetapkan ke NIC juga. Namun, perintah ini juga akan melewati alamat IP apa pun yang memiliki awalan VIP bidang kontrol, yang menyebabkan skrip startup hang.
Misalnya, anggaplah VIP bidang kontrol cluster admin adalah 192.168.1.25. Jika alamat IP VM bidang kontrol cluster admin memiliki
awalan yang sama, misalnya 192.168.1.254, maka VM bidang kontrol
akan macet selama pembuatan. Masalah ini juga dapat dipicu jika alamat siaran memiliki awalan yang sama dengan VIP bidang kontrol, misalnya, 192.168.1.255 .
Solusi:
|
Sistem operasi, Peningkatan Versi, Pembaruan |
1.10.0-1.10.2 |
Status cluster admin yang menggunakan image COS akan hilang setelah upgrade cluster admin atau perbaikan master admin
DataDisk tidak dapat dipasang dengan benar ke node master cluster admin saat menggunakan image COS dan status cluster admin yang menggunakan image COS akan hilang setelah upgrade cluster admin atau perbaikan master admin. (cluster admin yang menggunakan gambar COS adalah fitur pratinjau)
Solusi:
Buat ulang cluster admin dengan osImageType yang disetel ke ubuntu_containerd
Setelah membuat cluster admin dengan osImageType yang disetel ke cos, ambil
kunci SSH cluster admin dan SSH ke node master admin.
Hasil df -h berisi /dev/sdb1 98G 209M 93G
1% /opt/data . Dan lsblk hasil berisi -sdb1
8:17 0 100G 0 part /opt/data
|
Sistem operasi |
1.10 |
pencarian DNS gagal yang diselesaikan oleh sistem pada .local domain
Di Google Distributed Cloud versi 1.10.0, resolusi nama di Ubuntu
akan dirutekan ke pemrosesan lokal yang di-resolve oleh sistem di 127.0.0.53
secara default. Alasannya adalah pada image Ubuntu 20.04 yang digunakan dalam versi
1.10.0, /etc/resolv.conf ditautkan secara symlink ke
/run/systemd/resolve/stub-resolv.conf , yang mengarah ke
stub DNS localhost 127.0.0.53 .
Akibatnya, resolusi nama DNS localhost menolak untuk memeriksa
server DNS upstream (ditentukan dalam
/run/systemd/resolve/resolv.conf ) untuk nama dengan
akhiran .local , kecuali jika nama tersebut ditetapkan sebagai domain
penelusuran.
Hal ini menyebabkan pencarian nama .local gagal. Misalnya, selama startup node, kubelet gagal mengambil image dari registry pribadi dengan akhiran .local . Menentukan alamat vCenter dengan akhiran .local tidak akan berfungsi di workstation admin.
Solusi:
Anda dapat menghindari masalah ini untuk node cluster jika menentukan
kolom searchDomainsForDNS di file konfigurasi cluster admin
dan file konfigurasi cluster pengguna untuk menyertakan domain.
Saat ini, gkectl update belum mendukung pembaruan kolom searchDomainsForDNS .
Oleh karena itu, jika Anda belum menyiapkan kolom ini sebelum pembuatan cluster,
Anda harus menjalankan SSH ke node dan mengabaikan stub lokal yang diselesaikan oleh sistem dengan
mengubah symlink /etc/resolv.conf dari
/run/systemd/resolve/stub-resolv.conf (yang berisi
stub lokal 127.0.0.53 ) menjadi
/run/systemd/resolve/resolv.conf (yang mengarah ke
DNS upstream sebenarnya):
sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf
Sedangkan untuk workstation admin, gkeadm tidak mendukung
penentuan domain penelusuran, sehingga Anda harus mengatasi masalah tersebut dengan langkah
manual ini.
Solusi ini tidak dapat diterapkan di seluruh pembuatan ulang VM. Anda harus menerapkan kembali solusi ini setiap kali VM dibuat ulang.
|
Penginstalan, Sistem operasi |
1.10 |
IP jembatan Docker menggunakan 172.17.0.1/16 , bukan
169.254.123.1/24
Google Distributed Cloud menentukan subnet khusus untuk alamat IP jembatan Docker yang menggunakan --bip=169.254.123.1/24 , sehingga tidak akan mencadangkan subnet 172.17.0.1/16 default. Namun, pada versi 1.10.0, ada bug pada OS image Ubuntu yang menyebabkan konfigurasi Docker yang disesuaikan diabaikan.
Hasilnya, Docker memilih 172.17.0.1/16 default sebagai subnet alamat IP jembatannya. Hal ini dapat menyebabkan konflik alamat IP jika Anda sudah memiliki workload yang berjalan dalam rentang alamat IP tersebut.
Solusi:
Untuk mengatasi masalah ini, Anda harus mengganti nama file konfigurasi systemd berikut untuk Docker, lalu memulai ulang layanan:
sudo mv /etc/systemd/system/docker.service.d/50-cloudimg-settings.cfg \
/etc/systemd/system/docker.service.d/50-cloudimg-settings.conf
sudo systemctl daemon-reload
sudo systemctl restart docker
Verifikasi bahwa Docker memilih alamat IP jembatan yang benar:
ip a | grep docker0
Solusi ini tidak dapat dipertahankan di seluruh pembuatan ulang VM. Anda harus menerapkan kembali solusi ini setiap kali VM dibuat ulang.
|
Upgrade, Update |
1,11 |
Upgrade ke 1.11 diblokir oleh kesiapan stackdriver
Di Google Distributed Cloud versi 1.11.0, ada perubahan definisi resource kustom yang terkait dengan logging dan pemantauan:
- Nama grup resource kustom
stackdriver diubah dari addons.sigs.k8s.io menjadi addons.gke.io ;
- Nama grup resource kustom
monitoring dan metricsserver diubah dari addons.k8s.io menjadi addons.gke.io ;
- Spesifikasi resource di atas mulai divalidasi berdasarkan skemanya. Secara khusus, spesifikasi resourceAttrOverride dan storageSizeOverride di resource kustom
stackdriver harus memiliki jenis string dalam nilai permintaan serta batas ukuran cpu, memori, dan penyimpanan.
Perubahan nama grup ini dibuat untuk mematuhi pembaruan CustomResourceDefinition di Kubernetes 1.22.
Anda tidak perlu melakukan tindakan apa pun jika tidak memiliki logika tambahan yang menerapkan atau mengedit resource kustom yang terpengaruh. Proses upgrade Google Distributed Cloud akan menangani migrasi resource yang terpengaruh dan mempertahankan spesifikasi yang sudah ada setelah nama grup diubah.
Namun, jika Anda menjalankan logika yang menerapkan atau mengedit resource yang terpengaruh, diperlukan perhatian khusus. Pertama, mereka perlu direferensikan dengan nama grup baru dalam file manifes Anda. Contoh:
apiVersion: addons.gke.io/v1alpha1 ## instead of `addons.sigs.k8s.io/v1alpha1`
kind: Stackdriver
Kedua, pastikan nilai spesifikasi resourceAttrOverride dan storageSizeOverride berjenis string. Contoh:
spec:
resourceAttrOverride:
stackdriver-log-forwarder/stackdriver-log-forwarder
limits:
cpu: 1000m # or "1"
# cpu: 1 # integer value like this would not work
memory: 3000Mi
Jika tidak, penerapan dan pengeditan tidak akan berpengaruh dan dapat menyebabkan status yang tidak terduga dalam komponen logging dan pemantauan. Gejala yang mungkin terjadi dapat meliputi:
- Log error rekonsiliasi dalam
onprem-user-cluster-controller , misalnya: potential reconciliation error: Apply bundle components failed, requeue after 10s, error: failed to apply addon components: failed to apply bundle objects from stackdriver-operator-addon 1.11.2-gke.53 to cluster my-cluster: failed to create typed live object: .spec.resourceAttrOverride.stackdriver-log-forwarder/stackdriver-log-forwarder.limits.cpu: expected string, got &value.valueUnstructured{Value:1}
- Terjadi kegagalan dalam
kubectl edit stackdriver stackdriver , misalnya: Error from server (NotFound): stackdrivers.addons.gke.io "stackdriver" not found
Jika Anda mengalami error di atas, artinya jenis yang tidak didukung berdasarkan spesifikasi CR stackdriver sudah ada sebelum upgrade. Sebagai solusinya, Anda dapat mengedit CR stackdriver secara manual dengan nama grup lama kubectl edit stackdrivers.addons.sigs.k8s.io stackdriver dan melakukan hal berikut:
- Mengubah permintaan dan batas resource ke jenis string;
- Hapus anotasi
addons.gke.io/migrated-and-deprecated: true jika ada.
Kemudian, lanjutkan atau mulai ulang proses upgrade.
|
Sistem operasi |
1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16 |
COS VM tidak menampilkan IP saat VM dipindahkan melalui penonaktifan host secara halus
Setiap kali ada kesalahan di server ESXi dan fungsi HA vCenter telah diaktifkan untuk server, semua VM di server ESXi yang rusak akan memicu mekanisme vMotion dan dipindahkan ke server ESXi normal lainnya. VM COS yang dimigrasikan akan kehilangan IP-nya.
Solusi:
Memulai ulang VM
|
Networking |
semua versi sebelum 1.14.7, 1.15.0-1.15.3, 1.16.0 |
Balasan GARP yang dikirim oleh Seesaw tidak menetapkan IP target
GARP berkala (Gratuitous ARP) yang dikirim oleh Seesaw setiap 20-an tidak menetapkan IP target di {i>header<i} ARP. Beberapa jaringan mungkin tidak menerima paket tersebut (seperti Cisco ACI). Hal ini dapat menyebabkan periode nonaktif layanan yang lebih lama setelah otak yang terpisah (karena paket drop VRRP) dipulihkan.
Solusi:
Picu failover Seeaw dengan menjalankan sudo seesaw -c failover pada salah satu VM Seesaw. Tindakan ini akan memulihkan traffic.
|
Sistem operasi |
1.16, 1.28.0-1.28.200 |
Kubelet dibanjiri log yang menyatakan bahwa "/etc/kubernetes/manifess" tidak ada di node pekerja
"staticPodPath" salah ditetapkan untuk node pekerja
Solusi:
Buat folder "/etc/kubernetes/manifests" secara manual
|