Upgrade |
1,16, 1,28, 1,29, 1,30 |
credential.yaml dibuat ulang dengan tidak benar selama admin
upgrade workstation
Saat mengupgrade workstation admin menggunakan perintah gkeadm upgrade
admin-workstation , file credential.yaml
tidak dibuat ulang dengan benar. Kolom nama pengguna dan sandi kosong.
Selain itu, kunci privateRegistry memiliki kesalahan ketik.
Kesalahan ejaan tombol privateRegistry yang sama juga ditemukan
file admin-cluster.yaml . Sejak
File credential.yaml dibuat ulang selama cluster admin
proses peningkatan versi, ada kesalahan ketik meskipun Anda sudah mengoreksi sebelumnya.
Solusi:
- Perbarui nama kunci registry pribadi di
credential.yaml menjadi
cocokkan privateRegistry.credentials.fileRef.entry pada
admin-cluster.yaml .
- Perbarui nama pengguna dan sandi registry pribadi di
credential.yaml .
|
Upgrade |
1,16, 1,28 |
Upgrade cluster pengguna gagal karena waktu tunggu rekonsiliasi pra-upgrade terjadi
Saat mengupgrade cluster pengguna, operasi rekonsiliasi pra-upgrade mungkin
memakan waktu lebih lama dari waktu tunggu yang ditentukan, sehingga mengakibatkan kegagalan upgrade.
Pesan error akan terlihat seperti berikut:
Failed to reconcile the user cluster before upgrade: the pre-upgrade reconcile failed, error message:
failed to wait for reconcile to complete: error: timed out waiting for the condition,
message: Cluster reconcile hasn't finished yet, please fix that before
rerun the upgrade.
Waktu tunggu untuk operasi rekonsiliasi pra-upgrade adalah 5 menit plus 1 menit per kumpulan node di cluster pengguna.
Solusi:
Pastikan bahwa
gkectl diagnose cluster
tanpa terjadi error. Lewati operasi rekonsiliasi pra-upgrade dengan menambahkan tanda --skip-reconcile-before-preflight ke perintah gkectl upgrade cluster . Contoh:
gkectl upgrade cluster --skip-reconcile-before-preflight --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--config USER_CLUSTER_CONFIG_FILE
|
Update |
1.16, 1.28.0-1.28.800, 1.29.0-1.29.400 |
Mengupdate DataplaneV2 ForwardMode tidak secara otomatis memicu mulai ulang DaemonSet anetd
Saat Anda memperbarui cluster pengguna
dataplaneV2.forwardMode
menggunakan gkectl update cluster , perubahan tersebut hanya diupdate
di ConfigMap, DaemonSet anetd tidak akan mengambil perubahan konfigurasi hingga dimulai ulang dan perubahan Anda tidak diterapkan.
Solusi:
Setelah perintah gkectl update cluster selesai, Anda akan melihat
output dari Done updating the user cluster . Setelah Anda melihat bahwa
pesan ini, jalankan perintah berikut untuk memulai ulang anetd
DaemonSet untuk mengambil perubahan konfigurasi:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG rollout restart daemonset anetd
Periksa kesiapan DaemonSet setelah mulai ulang:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get daemonset anetd
Pada output perintah sebelumnya, pastikan angka di kolom DESIRED cocok dengan angka di kolom READY .
|
Upgrade |
1.16 |
Perintah etcdctl tidak ditemukan selama upgrade cluster pada tahap pencadangan cluster admin
Selama upgrade cluster pengguna 1.16 ke 1.28, cluster admin didukung
ke atas. Proses pencadangan cluster admin menampilkan pesan error
"etcdctl: perintah tidak ditemukan". Upgrade cluster pengguna berhasil, dan
cluster admin tetap dalam status responsif. Satu-satunya masalah adalah
file metadata di cluster admin tidak dicadangkan.
Penyebab masalah ini adalah biner etcdctl
ditambahkan di 1.28, dan tidak tersedia pada 1.16 node.
Pencadangan cluster admin melibatkan beberapa langkah, termasuk mengambil dll.
lalu menulis file metadata untuk cluster admin.
Pencadangan dll. masih berhasil karena etcdctl masih dapat
dipicu setelah {i>exec<i} masuk ke dalam Pod {i>etcd<i}. Tetapi menulis file metadata
gagal karena masih mengandalkan biner etcdctl untuk
yang diinstal pada node. Namun, pencadangan file metadata bukanlah pemblokir
untuk membuat cadangan, sehingga proses
pencadangan masih berhasil, seperti halnya
upgrade cluster pengguna.
Solusi:
Jika Anda ingin mengambil cadangan
file {i>metadata<i}, ikuti
Kembali
dan memulihkan cluster admin dengan gkectl untuk memicu
pencadangan cluster admin menggunakan versi gkectl yang cocok
versi cluster admin Anda.
|
Penginstalan |
1,16-1,29 |
Kegagalan pembuatan cluster pengguna dengan load balancing manual
Saat membuat cluster pengguna yang dikonfigurasi untuk load balancing manual,
Kegagalan gkectl check-config terjadi yang menunjukkan bahwa
Nilai ingressHTTPNodePort minimal harus 30000, meskipun
traffic masuk yang dipaketkan dinonaktifkan.
Masalah ini terjadi terlepas dari apakah ingressHTTPNodePort
dan ingressHTTPSNodePort kolom ditetapkan atau dibiarkan kosong.
Solusi:
Untuk mengatasi masalah ini, abaikan hasil yang dikembalikan oleh
gkectl check-config . Untuk menonaktifkan paket masuk, lihat
Nonaktifkan traffic masuk yang dipaketkan.
|
Update |
1.29.0 |
Masalah dengan PodDisruptionBudget (PDB) terjadi saat
menggunakan cluster admin ketersediaan tinggi (HA), dan terdapat 0 atau 1 admin
node cluster tanpa peran setelah migrasi. Untuk memeriksa apakah ada node
objek tanpa peran, jalankan perintah berikut:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get nodes -o wide
Jika ada dua objek node atau lebih tanpa peran setelah
migrasi, maka PDB
tidak salah dikonfigurasi.
Gejala:
Output dari
diagnostik cluster admin mencakup informasi berikut
Checking all poddisruptionbudgets...FAILURE
Reason: 1 pod disruption budget error(s).
Unhealthy Resources:
PodDisruptionBudget metrics-server: gke-managed-metrics-server/metrics-server might be configured incorrectly: the total replicas(1) should be larger than spec.MinAvailable(1).
Solusi:
Jalankan perintah berikut untuk menghapus PDB:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG delete pdb metrics-server -n gke-managed-metrics-server
|
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 macet
jika objek mesin yang dicerminkan di cluster pengguna berisi
deletionTimestamp . Pesan error berikut 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 pengguna
node bidang kontrol dengan menjalankan gkectl delete machine terhadap
komputer yang dicerminkan
di cluster pengguna.
Solusi:
- Mendapatkan objek mesin yang dicerminkan dan menyimpannya ke file lokal untuk dicadangkan
tujuan.
- Jalankan perintah berikut untuk menghapus finaler dari jendela yang dicerminkan
komputer dan menunggu 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 simpul bidang kontrol, sehingga spesifikasi
komputer sumber yang benar akan
disinkronkan ulang ke dalam 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, bidang kontrol
VIP harus berada di subnet yang sama dengan node cluster lainnya. Jika tidak, kelompokkan
pembuatan gagal karena kubelet tidak dapat berkomunikasi dengan server API menggunakan
VIP bidang kontrol.
Solusi:
Sebelum pembuatan cluster, pastikan VIP bidang kontrol dikonfigurasi
di 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 di versi 1.10 atau
lebih cepat
Saat mengupgrade cluster admin dari 1.16 ke 1.28, bootstrap
komputer master admin baru mungkin gagal membuat bidang kontrol
CA {i>root<i}. Masalah ini disebabkan oleh perubahan pada cara sertifikat
yang dibuat untuk server Kubernetes API versi 1.28 dan yang lebih baru. Tujuan
direproduksi kembali untuk cluster yang dibuat pada versi 1.10 dan sebelumnya,
telah ditingkatkan hingga 1.16
dan sertifikat {i>leaf<i} tidak
dirotasi sebelum upgrade.
Untuk menentukan apakah kegagalan upgrade cluster admin disebabkan oleh
lakukan langkah-langkah berikut:
- Hubungkan ke mesin master admin yang gagal menggunakan SSH.
- Buka
/var/log/startup.log dan telusuri error seperti
berikut ini:
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 . Find (Menemukan)
authorityKeyIdentifier=keyidset dan ubah menjadi
authorityKeyIdentifier=keyid,issuer di bagian untuk
ekstensi berikut:
apiserver_ext , client_ext ,
etcd_server_ext , dan kubelet_server_ext . Sebagai
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 {i>startup<i} mesin.
- Jalankan
gkectl upgrade admin lagi untuk mengupgrade admin
.
- Setelah upgrade selesai, rotasikan leaf certificate untuk kedua admin
serta cluster pengguna, 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, dan jalankan
/opt/bin/master.sh .
|
Konfigurasi |
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 memiliki
Dataplane V2 diaktifkan:
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 {i>bug<i} di {i>gkectl<i} yang menyebabkannya
selalu menampilkan peringatan ini sebagai
selama dataplaneV2.forwardMode tidak digunakan, meskipun
Anda telah menetapkan enableDataplaneV2: true dalam cluster Anda
file konfigurasi Anda.
Solusi:
Anda dapat mengabaikan peringatan ini dengan aman.
|
Konfigurasi |
1.28.0-1.28.400, 1.29.0 |
Laporan pemeriksaan preflight penginstalan cluster admin HA salah jumlah
IP statis yang diperlukan
Saat Anda membuat cluster admin HA, pemeriksaan preflight akan menampilkan
pesan error yang salah berikut ini:
- 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 tidak benar
karena tidak lagi memiliki node add-on. Selain itu, karena 3
IP node bidang kontrol cluster admin ditentukan dalam
Bagian network.controlPlaneIPBlock di cluster admin
file konfigurasi, IP dalam file blok IP hanya diperlukan untuk
{i>node<i} bidang kontrol cluster pengguna kubeception.
Solusi:
Untuk melewati pemeriksaan preflight yang salah dalam rilis yang tidak tetap, tambahkan --skip-validation-net-config ke gkectl
perintah.
|
Operasi |
1.29.0-1.29.100 |
Menghubungkan Agen kehilangan koneksi ke Google Cloud setelah non-HA ke HA
migrasi cluster admin
Jika Anda memigrasikan
dari cluster admin non-HA ke cluster admin HA, Connect Agent
di cluster admin kehilangan koneksi ke
gkeconnect.googleapis.com dengan pesan error "Gagal memverifikasi JWT
tanda tangan". 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 opsi "rekonsiliasi paksa" anotasi 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 mendaftar ulang
cluster tersebut jika tidak menemukan deployment gke-connect yang ada
yang tersedia.
Setelah solusinya (mungkin perlu beberapa menit bagi pengontrol untuk
menyelesaikan rekonsiliasi), Anda dapat memverifikasi bahwa pesan "Gagal
verifikasi tanda tangan JWT Error 400 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 di
Konfigurasi Docker untuk mencegah pemesanan
Subnet 172.17.0.1/16 . Namun, dalam 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 dalam
gambar. 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 beban kerja 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 mengajukan permohonan 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 di
versi. Biner CNI ini tidak digunakan oleh bidang data v2, tetapi dapat digunakan
untuk antarmuka jaringan tambahan
dalam 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 admin
webhook cluster. Misalnya, jika kolom gkeConnect tidak
tetapkan di cluster admin yang ada, dengan menambahkannya dengan
Perintah gkectl update admin mungkin mendapatkan error berikut
pesan:
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
|
Konfigurasi |
1.15.0-1.15.10, 1.16.0-1.16.6, 1.28.0-1.28.200 |
Setelan default kolom controlPlaneNodePort adalah 30968 jika
Spesifikasi manualLB kosong
Jika Anda akan menggunakan load balancer manual
(loadBalancer.kind ditetapkan ke "ManualLB" ),
Anda tidak perlu mengonfigurasi loadBalancer.manualLB
di file konfigurasi untuk admin ketersediaan tinggi (HA)
cluster di versi 1.16 dan yang lebih baru. Tapi jika bagian ini kosong,
Google Distributed Cloud menetapkan nilai default ke semua NodePorts termasuk
manualLB.controlPlaneNodePort , yang menyebabkan cluster
pembuatan 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 untuk pelanggan yang menggunakan {i>driver<i}
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. Tapi bidang
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 petunjuknya.
|
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 pengumpul metadata gagal menjangkau API ini berdasarkan 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
Saat cluster admin dan cluster pengguna mana pun yang mengaktifkan ControlPlane V2, akan menggunakan
kredensial vSphere yang berbeda, misalnya, setelah memperbarui kredensial vSphere untuk
admin, clusterapi-controller mungkin gagal terhubung ke vCenter setelah dimulai ulang. Lihat log pengontrol clusterapi yang berjalan di konfigurasi cluster admin
namespace `kube-system`,
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 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. Di sini
misalnya, periksa label grpc_code untuk
Watch .
Anda dapat memeriksa metrik ini menggunakan Cloud Monitoring dengan
Kueri MQL:
fetch
k8s_container | metric 'kubernetes.io/anthos/grpc_server_handled_total' | align rate(1m) | every 1m
- Notifikasi pada semua kode selain
OK dapat dikirimkan dengan aman
diabaikan jika kode tidak termasuk salah satu dari yang berikut ini:
Unknown|FailedPrecondition|ResourceExhausted|Internal|Unavailable|DataLoss|DeadlineExceeded
Solusi:
Untuk mengonfigurasi Prometheus agar mengabaikan pemberitahuan positif palsu ini, tinjau
opsi berikut:
- Menyenyapkan notifikasi
dari UI Pengelola Pemberitahuan.
- Jika tidak dapat menampilkan notifikasi, tinjau langkah-langkah berikut
untuk menyembunyikan positif palsu:
- Menurunkan skala operator pemantauan menjadi
0 replika sehingga
agar modifikasi dapat dipertahankan.
- Ubah konfigurasi peta
prometheus-config , lalu tambahkan
grpc_method!="Watch" ke
etcdHighNumberOfFailedGRPCRequests konfigurasi pemberitahuan seperti yang ditampilkan
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 {i>etcd<i}
dan log
kube-apiserver untuk men-debug lebih lanjut.
|
Jaringan |
1.16.0-1.16.2, 1.28.0 |
Koneksi yang aktif dalam waktu lama NAT keluar akan terputus
Koneksi NAT keluar mungkin terputus setelah 5 hingga 10 menit
koneksi yang tersambung jika
tidak ada lalu lintas data.
Karena conntrack hanya penting untuk arah masuk (eksternal
koneksi ke cluster), masalah ini hanya terjadi jika koneksi
tidak mengirimkan informasi apa pun untuk sementara waktu, lalu sisi tujuan
mentransmisikan sesuatu. Jika Pod keluar NAT selalu membuat instance
maka masalah ini tidak akan terlihat.
Masalah ini terjadi karena pembersihan sampah memori yang tidak sengaja
menghapus entri {i>conntrack<i} yang dianggap
{i>daemon <i}tidak digunakan.
Perbaikan upstream
diintegrasikan ke dalam anetd untuk memperbaiki perilaku tersebut.
Solusi:
Tidak ada solusi yang mudah, dan kami belum melihat masalah di versi 1.16
dari perilaku ini. Jika Anda melihat sambungan jangka panjang
yang terputus karena
masalah ini, solusinya adalah menggunakan
beban kerja pada {i>node<i} yang sama dengan
alamat IP keluar, atau untuk mengirim pesan secara konsisten di TCP
koneksi jarak jauh.
|
Operasi |
1,14, 1,15, 1,16 |
Penanda tangan CSR mengabaikan spec.expirationSeconds saat menandatangani
sertifikat
Jika Anda membuat Certificate SigningRequest (CSR) dengan
expirationSeconds ditetapkan, expirationSeconds
akan diabaikan.
Solusi:
Jika Anda terpengaruh oleh masalah ini, Anda dapat memperbarui cluster pengguna dengan
menambahkan disableNodeIDVerificationCSRSigning: true pada pengguna
file konfigurasi cluster dan jalankan gkectl update cluster
untuk mengupdate 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
nonaktifkan traffic masuk yang dipaketkan untuk cluster yang ada, perintah gkectl update cluster gagal dengan error
mirip dengan contoh berikut:
[FAILURE] Config: ingress IP is required in user cluster spec
Error ini terjadi karena gkectl memeriksa beban
alamat IP traffic masuk balancer selama pemeriksaan preflight. Meskipun pemeriksaan ini
tidak diperlukan saat menonaktifkan traffic masuk yang dipaketkan, gkectl
pemeriksaan preflight gagal saat disableBundledIngress disetel 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 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 gagal.
Error yang ditampilkan mirip dengan yang berikut ini:
failed to get last CARotationStage: configmaps "ca-rotation-stage" not found
Solusi:
Jika Anda terpengaruh oleh masalah ini, Anda dapat memperbarui cluster admin dengan
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 {i>update<i} 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 menginstal
Pod di namespace default . Pod Workload CSI memvalidasi
bahwa {i>Driver<i} CSI vSphere sudah diinstal
dan dapat melakukan pengaturan volume
penyediaan resource. Jika Pod ini tidak dimulai, pemeriksaan validasi Workload CSI
gagal.
Ada beberapa masalah umum yang dapat mencegah Pod ini dimulai:
- Jika Pod belum menetapkan batas resource, yang akan terjadi
beberapa cluster dengan webhook penerimaan terinstal, Pod tidak dapat dimulai.
- Jika Cloud Service Mesh diinstal di cluster dengan
injeksi file bantuan Istio otomatis diaktifkan di
default
pada namespace, Pod Workload CSI tidak dapat dimulai.
Jika Pod Workload CSI tidak dimulai, Anda akan melihat error waktu tunggu seperti
berikut ini 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 resource Pod yang ditetapkan, jalankan
perintah berikut untuk memeriksa anthos-csi-workload-writer-<run-id>
status pekerjaan:
kubectl describe job anthos-csi-workload-writer-<run-id>
Jika batas resource tidak ditetapkan dengan benar untuk Pod Workload CSI,
status pekerjaan berisi pesan {i>error<i} 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 volume dinamis
penyediaan dengan kerja Driver vSphere CSI:
- 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 vSphere CSI berfungsi, jalankan
gkectl diagnose atau gkectl upgrade
dengan flag --skip-validation-csi-workload untuk melewati CSI
Pemeriksaan beban kerja.
|
Operasi |
1.16.0-1.16.2 |
Waktu tunggu update cluster pengguna habis saat versi cluster admin adalah 1.15
Saat Anda masuk ke
komputer admin yang dikelola pengguna, gkectl update cluster
mungkin habis waktu tunggunya dan gagal memperbarui cluster pengguna. Hal ini terjadi jika
versi cluster admin adalah 1.15 dan Anda menjalankan gkectl update admin
sebelum Anda 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 memperbarui cluster pengguna, pemeriksaan preflight akan berhenti
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 masuk ke
komputer admin yang dikelola pengguna, gkectl create cluster
mungkin habis waktu tunggunya 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 di 1.16, saat menggunakan
1.15 admin mengelompokkan validation-controller yang bertanggung jawab untuk memicu pemeriksaan preflight tidak ada. Oleh karena itu, saat mencoba membuat cluster pengguna, pemeriksaan preflight
hang sampai 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 |
Pembaruan atau upgrade cluster admin 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 connect , stackdriver ,
Konfigurasi cloudAuditLogging , atau gkeOnPremAPI
saat Anda mengupdate cluster admin, operasi mungkin ditolak oleh admin
webhook cluster. 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 admin
cluster yang sama. Saat status cluster admin dipulihkan di
jenis cluster, webhook cluster admin tidak dapat membedakan apakah
Objek OnPremAdminCluster ditujukan untuk pembuatan cluster admin,
atau melanjutkan operasi
pembaruan atau {i>upgrade<i}. Beberapa khusus buat
validasi dipanggil saat mengupdate dan mengupgrade secara tiba-tiba.
Solusi:
Tambahkan
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 yang berikut:
ADMIN_CLUSTER_NAME : nama
cluster admin.
ADMIN_CLUSTER_KUBECONFIG : jalur
pada file kubeconfig cluster admin.
- Tambahkan
onprem.cluster.gke.io/skip-project-location-sameness-validation: true
dan menyimpan resource kustom.
- Bergantung pada jenis cluster admin, selesaikan salah satu
langkah-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. Ini
parameter 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:
mengupdate atau mengupgrade cluster admin seperti biasa. Tidak ada parameter tambahan
diperlukan pada perintah
pembaruan atau {i>upgrade<i}.
|
Operasi |
1.16.0-1.16.2 |
Gagal menghapus cluster pengguna saat menggunakan workstation admin yang dikelola pengguna
Saat Anda masuk ke
komputer admin yang dikelola pengguna, gkectl delete cluster
mungkin habis waktu tunggunya dan gagal menghapus cluster pengguna. Hal ini terjadi jika
Anda pertama kali menjalankan gkectl di workstation yang dikelola pengguna untuk
membuat, memperbarui, atau mengupgrade cluster pengguna. Ketika 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. Tujuan
penghapusan objek Validasi (yang dibuat saat pembuatan,
{i>update<i}, atau upgrade) terhenti di fase penghapusan. Hal ini sering terjadi
karena finaler 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 Validation:
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 ini
dihapus dan operasi penghapusan cluster pengguna selesai
secara otomatis. Anda tidak perlu melakukan tindakan tambahan.
|
Jaringan |
1,15, 1,16 |
Traffic gateway NAT keluar ke server eksternal gagal
Jika Pod sumber dan Pod gateway NAT keluar berada di dua
node pekerja, traffic dari Pod sumber tidak dapat menjangkau
layanan IT perusahaan mereka. Jika Pod terletak di host yang sama, koneksi ke
layanan atau aplikasi eksternal berhasil.
Masalah ini disebabkan oleh {i>vSphere<i} menjatuhkan paket VXLAN saat {i>tunnel<i}
penggabungan diaktifkan. Ada masalah umum pada NSX dan VMware yang
hanya mengirimkan traffic gabungan pada port VXLAN yang dikenal (4789).
Solusi:
Ubah port VXLAN yang digunakan oleh Cilium menjadi 4789 :
- Edit ConfigMap
cilium-config :
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 setiap upgrade. VMware harus menyelesaikan masalahnya di vSphere
untuk perbaikan permanen.
|
Upgrade |
1.15.0-1.15.4 |
Upgrade cluster admin yang mengaktifkan enkripsi secret yang selalu aktif akan gagal
Cluster admin mengupgrade dari 1.14.x ke 1.15.x dengan
selalu aktif
enkripsi secret diaktifkan akan gagal karena ketidakcocokan antara
kunci enkripsi yang dibuat pengontrol dengan kunci yang tetap berada di
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 cluster admin
file konfigurasi, lalu mengupdate cluster menggunakan
perintah berikut:
gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig KUBECONFIG
-
Saat VM master admin yang baru dibuat, lakukan SSH ke VM master admin,
dan mengganti kunci baru pada {i>disk <i}
dengan yang lama dari
cadangan. Kuncinya ada di
/opt/data/gke-k8s-kms-plugin/generatedkeys
di master admin.
-
Update manifes Pod statis kms-plugin.yaml di
/etc/kubernetes/manifests
untuk memperbarui --kek-id agar sesuai dengan kid
di kunci enkripsi asli.
-
Mulai ulang Pod statis kms-plugin dengan memindahkan
/etc/kubernetes/manifests/kms-plugin.yaml ke lokasi lainnya
direktori lalu memindahkannya kembali.
-
Lanjutkan upgrade admin dengan menjalankan
gkectl upgrade admin lagi.
Mencegah kegagalan upgrade
Jika Anda 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 cluster admin
file konfigurasi, lalu mengupdate cluster menggunakan
perintah berikut:
gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig KUBECONFIG
- Upgrade cluster admin.
-
Mengaktifkan kembali enkripsi rahasia yang selalu aktif.
|
Penyimpanan |
1,11-1,16 |
Error disk dan kegagalan pemasangan saat menggunakan Pelacakan Pemblokiran yang Diubah
(CBT)
Google Distributed Cloud tidak mendukung Changes Block Tracking (CBT) di
{i>disk<i}. Beberapa perangkat lunak cadangan menggunakan
fitur CBT untuk melacak status {i>disk<i} dan
melakukan pencadangan, yang menyebabkan {i>
disk<i} tidak dapat terhubung ke VM
yang menjalankan Google Distributed Cloud. Untuk informasi selengkapnya, lihat
Pusat Informasi VMware
artikel ini.
Solusi:
Jangan mencadangkan VM Google Distributed Cloud, sebagai software pencadangan pihak ketiga
dapat menyebabkan CBT
diaktifkan pada {i>disk<i} mereka. Tidak perlu kembali
mengubah VM ini.
Jangan aktifkan CBT pada node, karena perubahan ini tidak akan dipertahankan di seluruh
atau upgrade aplikasi.
Jika Anda sudah memiliki disk dengan CBT yang diaktifkan, ikuti
Langkah-langkah Penyelesaian di
Pusat Informasi VMware
artikeluntuk menonaktifkan CBT di Disk First Class.
|
Penyimpanan |
1,14, 1,15, 1,16 |
Kerusakan data pada NFSv3 ketika paralel menambahkan ke file bersama
dilakukan dari beberapa {i>host<i}
Jika Anda menggunakan susunan penyimpanan Nutanix untuk
menyediakan pembagian NFSv3 ke
Anda mungkin akan mengalami kerusakan
data atau ketidakmampuan Pod untuk
berjalan dengan sukses. Masalah ini disebabkan oleh masalah kompatibilitas umum
antara versi VMware dan Nutanix tertentu. Untuk selengkapnya
lihat informasi terkait
Pusat Informasi VMware
artikel ini.
Solusi:
Artikel Pusat Informasi VMware sudah usang karena menunjukkan bahwa tidak ada
resolusi saat ini. Untuk mengatasi masalah ini, update ke versi terbaru
ESXi di host Anda dan ke versi Nutanix terbaru di 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 di
versi yang berbeda dari bidang kontrol Kubernetes. Terdapat
ketidakcocokan karena biner kubelet yang dimuat sebelumnya di OS image menggunakan
versi yang 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 ada antara patch Kubernetes
versi 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) yang lebih tinggi
dari 1, update atau upgrade akan gagal karena validasi versi CA di
webhook. Output dari
Upgrade/update gkectl berisi pesan error berikut:
CAVersion must start from 1
Solusi:
-
Menurunkan skala deployment
auto-resize-controller di
untuk menonaktifkan perubahan ukuran otomatis node. Ini diperlukan
karena kolom baru diperkenalkan ke
Resource Kustom cluster admin di
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 flag --disable-admin-cluster-webhook .Misalnya: 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
Ketika gugus Controlplane V2 non-HA dihapus, gugus tersebut akan tertahan di node
hingga kehabisan waktu.
Solusi:
Jika cluster berisi StatefulSet dengan data penting, hubungi
hubungi Cloud Customer Care untuk
mengatasi masalah ini.
Atau, lakukan langkah-langkah berikut:
- Hapus semua VM cluster dari vSphere. Anda dapat menghapus
VM melalui UI vSphere, atau jalankan perintah berikut:
govc vm.destroy .
- Hapus otomatis cluster lagi:
gkectl delete cluster --cluster USER_CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG --force
|
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 mungkin mengumpulkan
peringatan palsu terhadap klaim volume persisten (PVC) saat
memvalidasi setelan penyimpanan cluster. Pesan peringatan terlihat seperti
berikut ini
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 di
output berisi hal berikut, Anda dapat mengabaikan peringatan tersebut 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 komponen Anda
akses kunci akun layanan dan Pemantauan log (atau pendaftaran Connect)
masa berlaku kunci akun layanan
sudah habis, saat Anda
putar
kunci akun layanan, gkectl update credentials
gagal dengan error yang mirip dengan berikut ini:
Error: reconciliation failed: failed to update platform: ...
Solusi:
Pertama, rotasikan kunci akun layanan akses komponen. Meskipun
yang sama ditampilkan, Anda seharusnya dapat merotasi
setelah rotasi kunci akun layanan akses komponen.
Jika update masih belum berhasil, hubungi Cloud Customer Care
untuk mengatasi 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 IP
di file blok IP, pemeriksaan {i>preflight<i} 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 mulai 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 mungkin
menyebabkan pengelola pengontrol cloud vSphere menghapus
{i>node<i} bidang kontrol. Ini menyebabkan clusterapi-controller macet
menunggu node dibuat, dan bahkan upgrade/update
waktunya habis. Dalam hal ini, output dari gkectl
perintah upgrade/update mirip dengan yang berikut ini:
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 duplikat
nama {i>host<i} di pusat data yang sama. Kegagalan ini terjadi karena
Pengelola pengontrol cloud vSphere gagal menambahkan IP eksternal dan penyedia
ID pada 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,
sebagai 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 {i>host<i} diduplikasi,
dan lakukan solusinya jika diperlukan.
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 picu 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 ini adalah cluster admin non-HA, dan Anda menemukan vm master admin menggunakan nama host duplikat, Anda juga perlu:
Dapatkan nama mesin master admin
kubectl get machine --kubeconfig ADMIN_KUBECONFIG -owide -A
Perbarui objek mesin master admin
Catatan: NEW_ADMIN_MASTER_HOSTNAME harus sama dengan yang Anda tetapkan di admin-ip-block.yaml di 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 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 gagal saat 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
kredensial
file konfigurasi.
- 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
kredensial
file konfigurasi.
- 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 {i>node<i} dihapus dan kemudian
dibuat ulang dengan nama {i>node<i} yang sama,
ada sedikit kemungkinan bahwa PersistentVolumeKlaim (PVC) berikutnya
pembuatan gagal dengan 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 pada HA
cluster admin, 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 tersebut, lalu
menyediakan 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
Anda memperbaiki dan menggunakan
nama {i>template<i} 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
|
Jaringan |
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,
VM Seesaw tidak aktif atau terus gagal booting, Anda mungkin melihat pesan error berikut
di konsol vSphere:
GRUB_FORCE_PARTUUID set, initrdless boot failed. Attempting with initrd
Kesalahan ini menunjukkan bahwa kapasitas {i>disk<i} pada VM rendah karena
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 mengupdate
(gkectl update admin ) cluster admin yang tidak memiliki Ketersediaan Tinggi
dengan checkpoint diaktifkan, upgrade atau update mungkin akan gagal dengan pesan error seperti
berikut ini:
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 setelah 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, mengupgrade
cluster admin ke versi yang terpengaruh bisa 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
secara eksplisit mendaftarkan
cluster, 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
mengupgrade cluster admin. Anda mungkin melihat pesan status `gagal untuk
error register cluster` untuk sementara. Setelah beberapa waktu, data tersebut akan diupdate
secara otomatis.
|
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 didaftarkan di GKE On-Prem API, resource-nya
anotasi link diterapkan ke OnPremAdminCluster kustom
resource, yang tidak dipertahankan selama update cluster admin berikutnya karena
kunci anotasi yang digunakan salah. Hal ini dapat menyebabkan cluster admin
dan tidak sengaja terdaftar di GKE On-Prem API.
Cluster admin didaftarkan di API saat Anda
secara eksplisit mendaftarkan
cluster, 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
ke cluster admin lagi.
|
Jaringan |
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 diperbarui, yang
menyebabkan orderPolicy diabaikan.
Solusi:
Perbarui template CoreDNS dan terapkan perbaikan. Perbaikan ini berlanjut hingga
melakukan upgrade.
- Edit template yang ada:
kubectl edit cm -n kube-system coredns-template
Ganti konten template dengan 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, seperti selama upgrade cluster. Perilaku ini
meningkatkan kemungkinan mendapatkan sertifikat yang tidak valid untuk cluster admin Anda,
terutama untuk cluster versi 1.15.
Jika terpengaruh oleh masalah ini, Anda mungkin akan mengalami masalah seperti
berikut ini:
Solusi:
Upgrade ke versi Google Distributed Cloud setelah 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 tidak ada
kelas prioritas
Pod gateway jaringan di kube-system mungkin menampilkan status
Pending atau Evicted , seperti yang ditunjukkan dalam
contoh {i>output<i} yang ringkas:
$ 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
PriorityClass memiliki prioritas default yang sama dengan workload lainnya.
Jika node memiliki resource yang terbatas, Pod gateway jaringan mungkin
dikeluarkan. Perilaku ini sangat buruk untuk ang-node
DaemonSet, karena Pod harus dijadwalkan pada node tertentu dan tidak
melakukan migrasi.
Solusi:
Upgrade ke versi 1.15 atau yang lebih baru.
Sebagai perbaikan jangka pendek, Anda dapat menetapkan
PriorityClass
ke komponen Anthos Network Gateway. Pengontrol Google Distributed Cloud
menimpa perubahan manual ini selama proses rekonsiliasi, seperti
selama upgrade cluster.
- Menetapkan PriorityClass
system-cluster-critical ke
Cluster ang-controller-manager dan autoscaler
Deployment pengontrol.
- Menetapkan PriorityClass
system-node-critical ke
DaemonSet node ang-daemon .
|
Upgrade, Update |
1.12, 1.13, 1.14, 1.15.0-1.15.2 |
upgrade cluster admin gagal setelah mendaftarkan cluster ke gcloud
Setelah Anda menggunakan gcloud untuk mendaftarkan cluster admin dengan non-kosong
gkeConnect , 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
karena snapshot masih mencakup semua log yang dikumpulkan oleh
default dengan menjalankan journalctl pada 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 di
Google Distributed Cloud versi lebih awal dari 1.13 karena
MicrosoftDockerProvider
tidak digunakan lagi.
Solusi:
Ide umum untuk menyelesaikan masalah ini adalah dengan mengupgrade ke Google Distributed Cloud 1.13
dan menggunakan gkectl 1.13 untuk membuat template VM Windows, lalu membuat
Kumpulan node Windows. Ada dua opsi untuk masuk ke Google Distributed Cloud 1.13 dari
versi saat ini seperti yang ditunjukkan di bawah ini.
Catatan: Kami memiliki opsi untuk menyelesaikan masalah ini di versi Anda saat ini
tanpa harus meningkatkan sepenuhnya ke versi 1.13, tetapi akan membutuhkan lebih banyak panduan
langkah selanjutnya, hubungi tim dukungan kami jika Anda ingin mempertimbangkan
menggunakan 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 menghancurkan
. Sebaiknya gunakan Google Distributed Cloud versi minor terbaru.
Catatan: Anda akan memerlukan resource tambahan untuk menyediakan cluster baru, tetapi
lebih sedikit periode nonaktif dan gangguan
untuk workload yang ada.
Opsi 2: Menghapus kumpulan node Windows dan menambahkannya kembali saat
mengupgrade ke Google Distributed Cloud 1.13
Catatan: Untuk opsi ini, beban kerja Windows tidak akan dapat berjalan hingga
cluster diupgrade ke versi 1.13 dan kumpulan node Windows ditambahkan kembali.
- Menghapus kumpulan node Windows yang ada dengan menghapus node pool Windows
konfigurasi dari file user-cluster.yaml, lalu jalankan perintah:
gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
- Upgrade cluster admin+pengguna khusus Linux ke 1.12 setelah mengikuti
panduan pengguna upgrade untuk versi minor target 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 setelah mengikuti
upgrade panduan pengguna.
- 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.
- Mengupdate 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 adalah
digunakan pada {i>node<i}, bukan 20 detik
yang seharusnya sesuai dengan
konfigurasi Anda. Jika Anda memeriksa log startup {i>node<i}
dengan melakukan SSH ke VM,
yang terletak di `/var/log/startup.log`, Anda dapat menemukan hal berikut
{i>error<i}:
+ has_systemd_unit systemd-timesyncd
/opt/bin/master.sh: line 635: has_systemd_unit: command not found
Menggunakan RootDistanceMaxSec selama 5 detik dapat menyebabkan sistem
jam tidak sinkron dengan server NTP
ketika 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
Jika Anda menggunakan gkectl versi 1.13 untuk mengupdate versi 1.12
Anda, 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"
Jika Anda menggunakan gkectl update admin untuk 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 memeriksa log gkectl , Anda mungkin melihat bahwa beberapa
termasuk menyetel osImageType dari string kosong ke
ubuntu_containerd .
Kesalahan pembaruan ini disebabkan oleh pengisian ulang yang tidak tepat
Kolom osImageType di konfigurasi cluster admin karena
yang diperkenalkan dalam versi 1.9.
Solusi:
Upgrade ke versi Google Distributed Cloud setelah perbaikan. Jika mengupgrade
ini 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 untuk memberikan sertifikat penayangan tambahan untuk
Server Kubernetes API cluster pengguna dengan
authentication.sni tidak berfungsi saat 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
Bila Anda
update 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
mengupdate 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 ke '{"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
'
- Update 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
meng-upgrade ke versi yang telah diperbaiki.
|
Operasi |
1.13.1+, 1.14, 1., 1.16 |
Saat Anda menggunakan Terraform untuk menghapus cluster pengguna dengan beban F5 BIG-IP
load balancer, server virtual F5 BIG-IP tidak dihapus setelah cluster
penghapusan.
Solusi:
Untuk menghapus resource F5, ikuti langkah-langkah untuk
membersihkan partisi cluster pengguna F5
|
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
meng-upgrade cluster admin ke versi 1.13.8 atau 1.14.4, jenis cluster menarik
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 gagal memunculkan cluster jenis.
Menjalankan perintah berikut di workstation admin akan menunjukkan
penampung yang sesuai 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 container cluster jenis
gambar. Namun, v0.18.0 telah
masalah dengan image container yang dimuat sebelumnya,
sehingga mereka akan ditarik
dari internet secara tidak sengaja.
Solusi:
Jalankan perintah berikut di workstation admin, saat ada cluster admin
sedang menunggu dibuat atau diupgrade:
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 {i>switch<i} yang memfilter
permintaan GARP duplikat (ARP) duplikat,
pemilihan pemimpin keepalive mungkin mengalami kondisi race, yang menyebabkan beberapa {i>node<i} memiliki entri tabel ARP yang salah.
Node yang terpengaruh dapat melakukan ping VIP bidang kontrol, tetapi koneksi TCP ke VIP bidang kontrol
waktu tunggunya 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
Bahkan ketika
pendaftaran cluster gagal selama pembuatan cluster admin, perintah gkectl create admin tidak gagal saat terjadi error dan mungkin berhasil. Dengan kata lain, pembuatan cluster admin bisa "berhasil" tanpa terdaftar
ke suatu 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.
|
Konfigurasi |
1.15.0 |
Pesan error palsu tentang vCenter.dataDisk
Untuk cluster admin dengan ketersediaan tinggi, gkectl prepare menampilkan
pesan {i>error <i}yang keliru 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 mungkin 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. {i>Tcpdump<i} dapat berjalan kembali
dengan aman sampai 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 predikat NodeAffinity
gagal. 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 {i>registry<i} pribadi, tetapi Anda belum
mengonfigurasi kredensial yang disiapkan untuk
registry pribadi Anda, {i>OnPremUserCluster<i}
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
ke petunjuk di
Konfigurasi kredensial yang disiapkan.
|
Upgrade, Update |
1.15.0 |
Selama gkectl upgrade admin , pemeriksaan preflight penyimpanan untuk Migrasi CSI akan diverifikasi
bahwa StorageClasses tidak memiliki parameter yang diabaikan setelah Migrasi CSI.
Misalnya, jika ada StorageClass dengan parameter diskformat ,
gkectl upgrade admin 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
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
jalankan 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 Windows
node. Hal ini menyebabkan volume terkait bersifat hanya baca di dalam Pod.
Masalah ini kemungkinan besar terjadi jika sekumpulan node baru menggantikan node lama
yang sama (misalnya, upgrade cluster atau pembaruan kumpulan node). Stateful
yang sebelumnya bekerja dengan baik
mungkin tidak dapat menulis ke
pada 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"}'
-
Mendapatkan akses powershell ke node, baik melalui SSH atau vSphere
dan antarmuka web Anda.
-
Menetapkan variabel lingkungan:
PS C:\Users\administrator> pvname=PV_NAME
PS C:\Users\administrator> podid=POD_UID
- Identifikasi nomor {i>disk<i} 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
-
Pastikan disk 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, seandainya Pod mendapatkan
dijadwalkan ke {i>node<i} baru, Anda mungkin perlu mengulangi
langkah sebelumnya pada
{i>node<i} 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 yang mengikuti
memperbarui kredensial cluster,
Anda mungkin menemukan vsphere-csi-secret pada namespace kube-system di cluster admin yang 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 akan 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
pod audit-proxy / manifes container.
Solusi:
Untuk cluster pengguna bidang kontrol v2 dengan enableControlplaneV2: true , hubungkan ke mesin bidang kontrol pengguna menggunakan SSH,
dan perbarui /etc/kubernetes/manifests/audit-proxy.yaml dengan --cluster_name=USER_CLUSTER_NAME .
Untuk cluster pengguna bidang kontrol v1, edit penampung audit-proxy di
set stateful 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 dalam gkectl list clusters , atau
meng-upgrade ke versi dengan 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 tidak boleh
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 versi lama
gambar atau pod gke-connect-agent tidak dapat diambil karena
ke 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 register asli
kunci akun layanan (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 mengubah data rahasia pull image secara manual
regcred yang digunakan oleh gke-connect-agent
deployment:
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 Anda di
deployment gke-connect-agent dengan:
- Salin rahasia 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 sebelumnya mungkin mengalami menonton
kelaparan dan pengawasan sumber daya 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 versi {i>etcd<i}
3.4.21. Semua versi Google Distributed Cloud sebelumnya terpengaruh oleh
menyelesaikan masalah ini.
Solusi
Jika tidak dapat segera melakukan upgrade, Anda dapat mengurangi risiko
kegagalan cluster dengan mengurangi jumlah node dalam cluster Anda. Hapus
node hingga 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 Pilih metrik, masukkan
Kubernetes Container
di panel filter, lalu gunakan submenu untuk memilih metrik:
- Di menu Active resources, pilih Kubernetes Container.
- Di menu Active metric categories, pilih Anthos.
- Di menu Active metrics, pilih
etcd_network_client_grpc_sent_bytes_total .
- Klik Terapkan.
|
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 memperoleh
kewalahan dengan traffic yang terdiri dari token JWT kedaluwarsa yang diteruskan dari
kube-apiserver ke GKE Identity Service selama
webhook otentikasi. Meskipun GKE Identity Service tidak
{i>crashloop <i}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 VIP bidang kontrol dan port load balancer bidang kontrol untuk
(misalnya, 172.16.20.50:443 ).
Jika Anda terpengaruh oleh masalah ini, perintah tersebut akan menampilkan 400
kode status. Jika waktu permintaan habis, mulai ulang Pod ais lalu
jalankan kembali perintah curl untuk melihat apakah tindakan tersebut menyelesaikan masalah. Jika
Anda mendapatkan kode status 000 , masalah telah teratasi dan
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 akan 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 untuk mendapatkan perbaikan, Anda dapat
identifikasi dan mulai 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 mengetahui 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,
mengurai 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 dan 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 k8s.gcr.io -> Pengalihan 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.
|
Jaringan |
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 file
adalah seesaw-for-gke-admin.yaml untuk cluster admin, dan
seesaw-for-{CLUSTER_NAME}.yaml untuk cluster pengguna.
|
Jaringan |
1,14 |
Waktu tunggu aplikasi yang disebabkan oleh kegagalan penyisipan tabel conntrack
Google Distributed Cloud versi 1.14 rentan terhadap netfilter
kegagalan penyisipan tabel pelacakan koneksi (conntrack) saat menggunakan
{i>image<i} sistem operasi Ubuntu atau COS. Kegagalan penyisipan menyebabkan acak
aplikasi telah habis dan dapat terjadi bahkan
ketika tabel conntrack memiliki ruang
untuk entri baru. Kegagalan disebabkan oleh perubahan
{i>kernel<i} 5.15 dan yang lebih tinggi yang membatasi penyisipan tabel berdasarkan rantai
paruh.
Untuk melihat apakah Anda terpengaruh oleh masalah ini, Anda dapat memeriksa in-kernel
statistik sistem pelacakan koneksi di setiap node dengan
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 adalah bukan nol
nomor tersebut, Anda terpengaruh oleh masalah ini.
Solusi
Mitigasi jangka pendeknya adalah dengan
meningkatkan ukuran file netfiler
tabel hash (nf_conntrack_buckets ) dan netfilter
tabel pelacakan koneksi (nf_conntrack_max ). Gunakan
perintah berikut di setiap node cluster untuk meningkatkan ukuran
tabel:
sysctl -w net.netfilter.nf_conntrack_buckets=TABLE_SIZE
sysctl -w net.netfilter.nf_conntrack_max=TABLE_SIZE
Ganti TABLE_SIZE dengan ukuran baru dalam byte. Tujuan
nilai ukuran tabel default adalah 262144 . Sebaiknya Anda menetapkan
bernilai 65.536 kali
jumlah inti pada {i>node<i}. Misalnya,
jika node Anda memiliki delapan core, tetapkan ukuran tabel ke 524288 .
|
Jaringan |
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
|
Konfigurasi |
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:
- Jika Anda tidak ingin menentukan kolom ini atau ingin menggunakan kolom yang sama
pribadi sebagai cluster admin, Anda cukup menghapus atau
memberi komentar di bagian
privateRegistry di cluster pengguna Anda
file konfigurasi.
- Jika Anda ingin menggunakan kredensial registry pribadi tertentu untuk
cluster pengguna, Anda dapat menentukan
privateRegistry untuk sementara
seperti ini:
privateRegistry:
address: PRIVATE_REGISTRY_ADDRESS
credentials:
username: PRIVATE_REGISTRY_USERNAME
password: PRIVATE_REGISTRY_PASSWORD
caCertPath: PRIVATE_REGISTRY_CACERT_PATH
(CATATAN: Ini hanya perbaikan sementara dan bidang ini sudah
tidak digunakan lagi, pertimbangkan untuk menggunakan file kredensial saat mengupgrade ke 1.14.3+.)
|
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. Ini berarti bahwa 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 terjadi di semua versi Google Distributed Cloud 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
dengan kuat setelah 6 menit
kube-controller-manager mungkin kehabisan waktu saat melepaskan
PV/PVC setelah 6 menit, dan lepaskan PV/PVC dengan paksa. Log mendetail
dari kube-controller-manager tampilkan acara 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 CSI pihak ketiga
{i>driver<i}. 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 --skip-validation-all
sebelumnya.
|
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. Ketika masalah terjadi,
Anda akan melihat error dari gkectl diagnose cluster
laporan.
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, sebagaimana dijelaskan dalam 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 mungkin
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 pada
mematikan atau memulai ulang. Setelah perubahan ini, VM
mengirim pesan tersebut dan
mengembalikan IP ke server DHCP. Akibatnya, IP yang dirilis mungkin
dialokasikan ulang ke VM lain dan/atau IP yang berbeda mungkin ditetapkan ke
VM, yang mengakibatkan konflik IP (di level Kubernetes, bukan level vSphere)
dan/atau IP pada 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
systemd-networkd perubahan perilaku default. VM yang menjalankan
DaemonSet ini tidak akan melepaskan
IP ke server DHCP pada
mematikan/memulai ulang. IP akan dibebaskan secara otomatis
oleh server DHCP
kapan 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
1.12.
Setelah mengupgrade cluster 1.11.x ke 1.12.x,
Kolom component-access-sa-key di
Rahasia admin-cluster-creds akan dihapus menjadi kosong.
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 bahwa output-nya kosong, berarti kunci telah dihapus.
Setelah kunci akun layanan
akses komponen dihapus,
menginstal klaster pengguna baru atau
meningkatkan klaster pengguna yang ada
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."
- Persiapan oleh
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 Google Cloud
Konsol atau gcloud CLI, saat Anda menjalankan
gkectl update admin --enable-preview-user-cluster-central-upgrade
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:
Menambahkan 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 . mis. Jika memperbarui dari Ubuntu ke COS, kita harus menunggu sampai 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 token autentikasi akun layanan Calico CNI
atau
Masalah dengan Calico di Google Distributed Cloud 1.14.0
menyebabkan pembuatan dan penghapusan Pod gagal dengan pesan error berikut
output kubectl describe pods :
error getting ClusterInformation: connection is unauthorized: Unauthorized
Masalah ini hanya terjadi 24 jam setelah klaster
dibuat atau diupgrade ke versi 1.14 menggunakan Calico.
Cluster admin selalu menggunakan Calico, sedangkan untuk cluster pengguna
kolom konfigurasi `enableDataPlaneV2` di user-cluster.yaml, jika kolom itu
diatur ke `false`, atau tidak ditentukan, itu berarti Anda menggunakan Calico di bagian
.
Beberapa node Container install-cni membuat kubeconfig dengan
token yang berlaku selama 24 jam. Token ini harus dikirimkan secara berkala
diperpanjang oleh Pod calico-node . calico-node
Pod tidak dapat memperpanjang token karena tidak memiliki akses ke direktori
yang berisi file {i>
kubeconfig<i} pada {i>node<i}.
Solusi:
Masalah ini telah diperbaiki pada Google Distributed Cloud versi 1.14.1. Upgrade ke
versi ini atau yang lebih baru.
Jika kamu tidak bisa langsung mengupgrade, terapkan patch berikut pada
calico-node DaemonSet di cluster admin dan 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 yang berikut:
ADMIN_CLUSTER_KUBECONFIG : jalur
pada file kubeconfig cluster admin.
USER_CLUSTER_CONFIG_FILE : jalur
dari 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
|
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 gmp-system
untuk cluster Anda, komponen tidak dipertahankan saat Anda
upgrade ke versi 1.12.x.
Mulai versi 1.12, komponen GMP dalam namespace gmp-system dan CRD dikelola oleh stackdriver
, dengan flag enableGMPForApplications yang ditetapkan ke false oleh
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
dalam hal ini:
USER_CLUSTER_KUBECONFIG adalah cluster pengguna
{i>kubeconfig<i}.
|
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 .
|
Konfigurasi |
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:
cluster-autoscaler log
kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
cluster-autoscaler
dengan ADMIN_CLUSTER_KUBECONFIG adalah cluster admin
{i>kubeconfig<i}.
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
...
|
Konfigurasi |
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 cluster admin
{i>kubeconfig<i}.
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 cluster admin
{i>kubeconfig<i}.
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:
- "*"
|
Konfigurasi |
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 lebih titik. 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:
- Lihat log di cluster admin untuk
Penampung
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
berikut:
kubectl logs clusterapi-controllers-POD_NAME \
-c clusterapi-controller-manager -n USER_CLUSTER_NAME \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG
dalam hal ini:
- ADMIN_CLUSTER_KUBECONFIG adalah milik cluster admin
{i>kubeconfig<i}.
- USER_CLUSTER_NAME adalah nama cluster pengguna.
Berikut adalah 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 ruang isian
{i>host <i}dari file blok IP,
karakter apa pun setelah titik pertama akan diabaikan. Misalnya, jika
Anda menentukan nama host sebagai bob-vm-1.bank.plc , VM
nama host dan nama node akan
ditetapkan ke bob-vm-1 .
Bila verifikasi ID node diaktifkan, pemberi persetujuan CSR akan membandingkan
nama node dengan nama host di spesifikasi Perangkat, dan gagal merekonsiliasi
namanya. Pemberi persetujuan menolak CSR, dan node gagal
kerangka kerja internal.
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
berikut:
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--config USER_CLUSTER_CONFIG_FILE
Ganti yang berikut:
ADMIN_CLUSTER_KUBECONFIG : jalur
pada file kubeconfig cluster admin.
USER_CLUSTER_CONFIG_FILE : jalur
dari file konfigurasi cluster pengguna Anda.
Cluster Admin
- Buka resource kustom
OnPremAdminCluster untuk
pengeditan:
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
- Mengedit manifes
kube-controller-manager di admin
bidang kontrol cluster:
- SSH ke dalam
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 hingga
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 registry pribadi
paket sertifikat
Pembuatan/upgrade cluster admin terhenti di log berikut selamanya
dan akhirnya waktunya habis:
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 {i>node<i}. Hal ini dapat mengakibatkan
beban pada {i>node <i}lain atau kurangnya
redundansi untuk ketersediaan tinggi.
Aktivitas Dataplane tidak akan terpengaruh.
Pertentangan pada objek networkgatewaygroup menyebabkan beberapa
pembaruan status gagal karena
terjadi kesalahan dalam penanganan percobaan ulang. Jika terlalu banyak
update status 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 dan pembaruan atau
upgrade
Masalah umum yang dapat menyebabkan upgrade atau update cluster
macet saat menunggu objek
mesin lama untuk dihapus. Hal ini karena
finaler tidak dapat dihapus dari objek mesin. Hal ini memengaruhi semua
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.
Di clusterapi-controller log Pod, error-nya seperti
di bawah ini:
$ 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
{i>Error <i}terulang untuk komputer yang
sama selama beberapa menit untuk
berhasil bahkan tanpa masalah ini, hampir selalu dapat dilakukan
dengan cepat, tetapi untuk beberapa kasus yang jarang terjadi, error ini dapat terhenti di proses ini
selama beberapa jam.
Masalahnya adalah VM yang mendasarinya
sudah dihapus di vCenter, tetapi
objek mesin terkait tidak dapat dihapus, yang macet di
penghapusan finaler karena pembaruan
yang sangat sering dari {i>controller<i} lain.
Hal ini dapat menyebabkan waktu tunggu perintah gkectl habis, tetapi
pengontrol terus merekonsiliasi cluster sehingga proses upgrade atau update
pada akhirnya akan selesai.
Solusi:
Kami telah menyiapkan beberapa opsi mitigasi yang berbeda untuk masalah ini,
yang bergantung pada lingkungan dan persyaratan Anda.
- Opsi 1: Tunggu hingga upgrade selesai pada akhirnya
itu sendiri.
Berdasarkan analisis dan reproduksi di lingkungan Anda, upgrade
pada akhirnya dapat selesai dengan sendirinya
tanpa intervensi manual apa pun. Tujuan
peringatan dari opsi ini adalah bahwa tidak ada
pasti berapa lama waktu yang dibutuhkan
penghapusan finaler yang akan dilakukan
untuk setiap objek mesin. Bisa
Segera jika cukup beruntung, atau bisa berlangsung selama beberapa jam
jika rekonsiliasi pengontrol {i>
machineset<i} terlalu cepat dan komputer
{i>controller<i} tidak pernah mendapat kesempatan
untuk menghapus finaler di antara
rekonsiliasi.
Untungnya, opsi ini tidak memerlukan tindakan apa pun dari
tambahan, dan beban kerja tidak akan terganggu. Hanya perlu waktu yang lebih lama
untuk menyelesaikan upgrade.
- Opsi 2: Terapkan anotasi perbaikan otomatis ke semua perangkat lama
objek terstruktur dalam jumlah besar.
Pengontrol {i>machineset<i} akan
memfilter komputer yang memiliki
anotasi perbaikan otomatis dan stempel waktu penghapusan
bukan nol, dan tidak akan
terus mengeluarkan panggilan hapus pada
komputer tersebut, hal ini dapat membantu menghindari
kondisi race.
Kelemahannya adalah pod pada
komputer akan langsung dihapus
bukannya dikeluarkan, yang berarti ia tidak akan
menghormati konfigurasi PDB,
hal ini berpotensi menyebabkan periode nonaktif
untuk beban kerja Anda.
Perintah untuk mendapatkan semua nama mesin:
kubectl --kubeconfig CLUSTER_KUBECONFIG get machines
Perintah untuk menerapkan anotasi perbaikan otomatis untuk setiap mesin:
kubectl annotate --kubeconfig CLUSTER_KUBECONFIG \
machine MACHINE_NAME \
onprem.cluster.gke.io/repair-machine=true
Jika Anda mengalami masalah ini dan upgrade atau update masih tidak dapat
diselesaikan setelah sekian lama,
kontak
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
dukung "/" atau ":".
Solusi:
Hapus awalan https:// atau http:// dari
Kolom vCenter.Address di cluster admin atau cluster pengguna
konfigurasi yaml.
|
Penginstalan, Upgrade, Update |
1.10, 1.11, 1.12, 1.13 |
gkectl prepare panik di util.CheckFileExists
gkectl prepare dapat panik dengan hal berikut
stacktrace:
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 {i>registry<i}
dengan izin yang salah.
Solusi:
Untuk memperbaiki masalah ini, jalankan perintah berikut pada admin
workstation:
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 yang dapat dilanjutkan dan gkectl repair admin-master adalah
tidak bekerja sama
Setelah upaya upgrade cluster admin gagal, jangan jalankan gkectl
repair admin-master . Tindakan ini dapat menyebabkan upgrade admin berikutnya
upaya untuk gagal dengan masalah seperti daya master admin gagal 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 bidang kontrol admin tidak ada
Template VM
Jika mesin bidang kontrol admin tidak dibuat ulang setelah dilanjutkan
upaya upgrade cluster admin, template VM bidang kontrol admin
dihapus. Template VM bidang kontrol admin adalah template 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.
|
Sistem operasi |
1,12, 1,13 |
cgroup v2 dapat memengaruhi workload
Di versi 1.12.0, cgroup v2 (terpadu) diaktifkan secara {i>default<i} untuk
Node OS yang Dioptimalkan untuk Container (COS). Hal ini berpotensi menimbulkan
ketidakstabilan untuk beban kerja
Anda dalam klaster COS.
Solusi:
Kami beralih kembali ke cgroup v1 (hybrid) di versi 1.12.1. Jika Anda
menggunakan node COS, sebaiknya segera tingkatkan ke versi 1.12.1
saat dirilis.
|
Identitas |
1.10, 1.11, 1.12, 1.13 |
Resource kustom ClientConfig
gkectl update mengembalikan perubahan manual yang Anda miliki
yang dibuat ke resource kustom ClientConfig.
Solusi:
Kami sangat menyarankan agar Anda mencadangkan resource ClientConfig setelah
setiap perubahan manual.
|
Penginstalan |
1.10, 1.11, 1.12, 1.13 |
Validasi gkectl check-config gagal: tidak dapat menemukan F5
Partisi BIG-IP
Validasi gagal karena partisi F5 BIG-IP tidak dapat ditemukan, bahkan
meskipun mereka 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 perintah cert-manager/ca-injector
masalah pemilu pemimpin
Anda mungkin melihat kegagalan
instalasi karena
cert-manager-cainjector dalam crashloop, 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.
Pertama, perkecil monitoring-operator agar tidak
kembalikan perubahan ke 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 kita hanya punya satu replika yang berjalan. Tidak
yang 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 cert-manager-cainjector
deployment 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
...
Mempertahankan monitoring-operator replika pada 0 sebagai mitigasi
hingga penginstalan selesai. Jika tidak, perubahan akan dikembalikan.
Setelah instalasi selesai dan cluster aktif dan 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 hal yang sama
langkah lagi untuk memitigasi masalah hingga masalah ini diperbaiki di masa mendatang
data.
|
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
atau jika tidak, nama jaringan dalam
informasi vm dari vCenter adalah
salah, dan menyebabkan komputer menggunakan Unavailable
status. Hal ini pada akhirnya menyebabkan node otomatis diperbaiki
yang baru.
Govmomi terkait
bug.
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
Koneksi > Putuskan koneksi. Berikutnya, hubungkan kembali, yang memaksa update
dari 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, Ubuntu OS
gambar diperkuat dengan
Tolok Ukur Server CIS L1.
Untuk memenuhi aturan CIS "5.2.16 Pastikan SSH Idle Timeout Interval adalah
dikonfigurasi", /etc/ssh/sshd_config memiliki hal berikut
pengaturan:
ClientAliveInterval 300
ClientAliveCountMax 0
Tujuan setelan ini adalah untuk menghentikan sesi klien setelah 5
menit waktu tidak ada aktivitas. Namun, ClientAliveCountMax 0
nilai tersebut menyebabkan perilaku yang tidak diharapkan. Saat Anda menggunakan sesi ssh pada
atau node cluster, koneksi SSH mungkin
memutuskan hubungan bahkan klien ssh Anda tidak menganggur, seperti saat menjalankan
memakan waktu lama, dan perintah
Anda bisa dihentikan dengan
pesan berikut:
Connection to [IP] closed by remote host.
Connection to [IP] closed.
Solusi:
Anda dapat:
- Gunakan
nohup agar perintah Anda tidak dihentikan
pemutusan SSH,
nohup gkectl upgrade admin --config admin-cluster.yaml \
--kubeconfig kubeconfig
- Update
sshd_config untuk menggunakan bilangan bukan nol
Nilai ClientAliveCountMax . Aturan CIS menyarankan
untuk menggunakan
nilai kurang dari 3:
sudo sed -i 's/ClientAliveCountMax 0/ClientAliveCountMax 1/g' \
/etc/ssh/sshd_config
sudo systemctl restart sshd
Pastikan Anda menghubungkan kembali sesi SSH Anda.
|
Penginstalan |
1.10, 1.11, 1.12, 1.13 |
Penginstalan cert-manager bertentangan
Dalam rilis 1.13, monitoring-operator akan menginstal
cert-manager di namespace cert-manager . Jika untuk tertentu
alasan, Anda perlu menginstal pengelola sertifikat Anda sendiri,
petunjuk untuk menghindari konflik:
Anda hanya perlu menerapkan solusi ini sekali untuk setiap cluster, dan
perubahan akan dipertahankan di seluruh upgrade cluster.
Catatan: Satu gejala umum saat menginstal pengelola sertifikat Anda sendiri
adalah versi atau image cert-manager (misalnya
v1.7.2) dapat dikembalikan ke versi lamanya. Hal ini disebabkan oleh
monitoring-operator mencoba merekonsiliasi
cert-manager , dan mengembalikan versi dalam proses.
Solusi:
<pMenghindari konflik selama upgrade
- Uninstal versi
cert-manager Anda. Jika Anda menentukan
sumber daya Anda sendiri, Anda mungkin ingin
cadangan
mereka.
- Lakukan upgrade.
- Ikuti petunjuk berikut untuk memulihkan sandi Anda sendiri
cert-manager .
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 hingga 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 kustom jika ada.
- Anda dapat melewati langkah ini
jika menggunakan
penginstalan pengelola sertifikat default upstream, atau Anda yakin
cert-manager diinstal di namespace
cert-manager .
Jika tidak, salin cert-manager.io/v1 metrics-ca
Sertifikat dan Penerbit metrics-pki.cluster.local
resource dari cert-manager ke resource cluster
namespace dari pengelola sertifikat 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 admin
karena cluster admin hanya menjalankan kontrol Google Distributed Cloud
workload berbasis platform. Dalam kasus yang jarang terjadi, Anda juga perlu menginstal
cert-manager di cluster admin, ikuti petunjuk berikut
untuk menghindari konflik. Perlu diperhatikan, jika Anda adalah pelanggan Apigee dan Anda
hanya memerlukan cert-manager untuk Apigee, Anda tidak perlu menjalankan admin
menggunakan perintah cluster.
- 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 hingga 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 kustom jika ada.
- Anda dapat melewati langkah ini
jika menggunakan
penginstalan pengelola sertifikat default upstream, atau Anda yakin
cert-manager diinstal di namespace
cert-manager .
Jika tidak, salin cert-manager.io/v1 metrics-ca
Sertifikat dan Penerbit metrics-pki.cluster.local
resource dari cert-manager ke resource cluster
namespace dari pengelola sertifikat 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, {i>containerd<i}, dan runc di
{i>image<i} OS Ubuntu yang dikirimkan bersama
Google Distributed Cloud disematkan ke versi khusus menggunakan
PPA Ubuntu. Hal ini memastikan
bahwa setiap perubahan runtime container
akan memenuhi syarat oleh
Google Distributed Cloud sebelum setiap rilis.
Namun, versi khusus tidak dikenal oleh
CVE Ubuntu
Tracker, yang digunakan sebagai feed kerentanan oleh berbagai CVE
alat pemindaian. Oleh karena itu, Anda akan melihat
positif palsu (PP) di Docker,
hasil pemindaian kerentanan containerd dan runc.
Misalnya, Anda mungkin melihat positif palsu berikut dari CVE
hasil pemindaian. CVE ini sudah diperbaiki di patch terbaru
versi baru Google Distributed Cloud.
Lihat catatan rilis]
untuk perbaikan CVE.
Solusi:
Kanonis mengetahui masalah ini, dan perbaikan 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 Anda meningkatkan cluster non-HA dari 1,9 ke 1,10, Anda mungkin melihat
bahwa kubectl exec , kubectl log , dan webhook
terhadap klaster pengguna mungkin
tidak tersedia untuk waktu yang singkat. Periode nonaktif ini
dapat mencapai satu menit. Hal ini terjadi karena permintaan masuk
(kubectl exec, kubectl log, dan webhook) ditangani oleh kube-apiserver untuk
cluster pengguna. Pengguna kube-apiserver adalah
Statefulset. Dalam cluster non-HA, hanya ada satu replika untuk
Statefulset. Jadi selama peningkatan, ada kemungkinan bahwa versi
kube-apiserver tidak tersedia saat kube-apiserver baru belum tersedia
siap.
Solusi:
Periode nonaktif ini hanya terjadi selama proses upgrade. Jika Anda menginginkan
lebih singkat selama peningkatan versi, sebaiknya Anda beralih ke
HA
cluster.
|
Penginstalan, Upgrade, Update |
1.10, 1.11, 1.12, 1.13 |
Pemeriksaan kesiapan konektivitas gagal dalam diagnosis klaster HA setelah
pembuatan atau upgrade cluster
Jika Anda membuat atau mengupgrade klaster HA dan melihat konektivitas
pemeriksaan kesiapan gagal saat didiagnosis cluster. Dalam kebanyakan kasus, hal ini tidak akan
memengaruhi fungsi Google Distributed Cloud (kubectl exec, kubectl
log dan webhook). Hal ini terjadi karena terkadang
satu atau dua dari
replika konektivitas mungkin tidak siap untuk 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 menjalankan 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 Ubuntu
gambar telah melalui proses hardening dengan
Server CIS L1
Tolok ukur.
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. Tergantung jumlah
pada sistem file, Anda mungkin mengalami lonjakan penggunaan CPU dan memori
sekitar waktu tersebut yang disebabkan oleh proses aide ini.
Solusi:
Jika lonjakan memengaruhi beban kerja, Anda dapat menonaktifkan
{i>cron job <i}(tugas cron):
sudo chmod -x /etc/cron.daily/aide
|
Jaringan |
1.10, 1.11, 1.12, 1.13 |
Load balancer dan aturan firewall terdistribusi stateful NSX-T berinteraksi
tidak dapat diprediksi
Saat men-deploy Google Distributed Cloud versi 1.9 atau yang lebih baru, saat
deployment memiliki load balancer paket Seesaw
di lingkungan yang
menggunakan aturan {i>firewall<i} terdistribusi stateful NSX-T,
stackdriver-operator mungkin gagal dibuat
gke-metrics-agent-conf ConfigMap dan penyebabnya
gke-connect-agent Pod akan berada dalam loop error.
Masalah pokoknya adalah bahwa {i>firewall<i} stateful NSX-T
menghentikan koneksi dari klien ke API cluster pengguna
server melalui load balancer Seesaw
karena Seesaw menggunakan
alur koneksi. Masalah integrasi dengan firewall terdistribusi NSX-T
memengaruhi semua rilis Google
Distributed Cloud yang menggunakan Seesaw. Anda
mungkin melihat masalah koneksi serupa pada aplikasi Anda saat
membuat objek Kubernetes besar yang ukurannya lebih dari 32K.
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 Anda agar dapat menyetel ulang klien
koneksi saat mendeteksi kegagalan node backend. Tanpa label ini
klien server Kubernetes API mungkin berhenti merespons
selama beberapa menit
saat {i>instance<i} server mati.
|
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 memiliki
menemukan tagihan tinggi yang tidak terduga untuk Metrics volume pada
Halaman Penagihan. Masalah ini hanya mempengaruhi Anda ketika semua
keadaan berikut berlaku:
- Logging dan pemantauan aplikasi diaktifkan (
enableStackdriverForApplications=true )
- Pod Aplikasi memiliki
prometheus.io/scrap=true
anotasi. (Menginstal Cloud Service Mesh juga dapat menambahkan anotasi ini.)
Untuk mengonfirmasi apakah Anda terpengaruh oleh masalah ini atau tidak,
cantumkan
metrik buatan 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 , maka
masalah ini terjadi pada Anda.
Solusi
Jika Anda terpengaruh oleh masalah ini, sebaiknya Anda mengupgrade
cluster ke versi 1.12 atau yang lebih baru, hentikan penggunaan tanda enableStackdriverForApplications , dan beralihlah ke solusi pemantauan aplikasi baru managed-service-for-prometheus yang tidak lagi bergantung pada 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, gunakan langkah-langkah berikut:
- Temukan Pod dan Service 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
mengonfigurasi Cloud Service Mesh tanpa opsi Prometheus,
atau menonaktifkan fitur Penggabungan Metrik Istio.
|
Penginstalan |
1.11, 1.12, 1.13 |
Penginstal gagal saat membuat datadisk vSphere
Penginstal Google Distributed Cloud dapat gagal jika peran khusus terikat
di tingkat izin yang salah.
Ketika pengikatan peran salah, membuat datadisk vSphere dengan
govc mengalami hang dan disk dibuat dengan ukuran 0. Kepada
memperbaiki masalah ini, Anda harus mengikat peran khusus di vSphere vCenter
tingkat (root).
Solusi:
Jika Anda ingin mengikat peran khusus di tingkat DC (atau lebih rendah dari
{i>root<i}), Anda juga harus mengikat peran {i>read-only<i} ke pengguna di {i>root<i}
Tingkat vCenter.
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 yang tinggi ke monitoring.googleapis.com
Anda mungkin melihat
lalu lintas jaringan yang tinggi ke
monitoring.googleapis.com , bahkan dalam cluster baru yang belum memiliki
yang dioptimalkan untuk workload pengguna.
Masalah ini memengaruhi versi 1.10.0-1.10.1 dan versi 1.9.0-1.9.4. Ini
Masalah telah diperbaiki dalam 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:
- Perkecil skala `stackdriver-operator`:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system \
scale deployment stackdriver-operator --replicas=0
Ganti USER_CLUSTER_KUBECONFIG dengan jalur pengguna
file kubeconfig cluster.
- Buka ConfigMap
gke-metrics-agent-conf 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 menjadi
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` di `stackdriver`
.
Solusi:
Untuk mengurangi masalah ini, nonaktifkan pengumpulan metrik aplikasi dengan
menjalankan perintah berikut. Perintah ini tidak akan menonaktifkan
pengumpulan log aplikasi.
- Untuk mencegah perubahan berikut tidak dikembalikan, turunkan skala
stackdriver-operator :
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system scale deploy stackdriver-operator \
--replicas=0
Ganti USER_CLUSTER_KUBECONFIG dengan jalur pengguna
file kubeconfig cluster.
- Buka ConfigMap
gke-metrics-agent-conf untuk mengedit:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system edit configmap gke-metrics-agent-conf
- Di bagian
services.pipelines , jadikan seluruh komentar sebagai komentar
Bagian metrics/app-metrics :
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 Monitoring
dasbor, 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 yang tidak digunakan lagi berikut harus dimigrasikan ke
pengganti.
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
- Menghapus "status node lokal GKE" di Google Cloud Monitoring
dasbor. Instal ulang "status node lokal GKE" mengikuti
petunjuk ini.
- Menghapus "Penggunaan node lokal GKE" di Google Cloud Monitoring
dasbor. Instal ulang "Penggunaan node lokal GKE" mengikuti
petunjuk ini.
- Menghapus "kondisi vm vSphere lokal GKE" di lapisan
Dasbor pemantauan. Instal ulang "kondisi vm vSphere lokal GKE"
mengikuti
petunjuk ini.
Penghentian ini terjadi karena upgrade
agen kube-state-metrics dari v1.9 hingga v2.4, yang diperlukan untuk
Kubernetes 1.22. Anda dapat mengganti semua yang tidak digunakan lagi
kube-state-metrics metrik, 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 metrik ringkasan yang tidak relevan
entri seperti berikut:
Unknown metric: kubernetes.io/anthos/go_gc_duration_seconds_summary_percentile
Jenis metrik lain yang mungkin memiliki metrik ringkasan yang tidak relevan
sertakan :
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 ada dalam daftar metrik,
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, tetapi tidak
semua, node:
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. Sebagai
[versi 1.9.5+, 1.10.2+, 1.11.0]: tingkatkan cpu untuk gke-metrics-agent
dengan mengikuti langkah 1 - 4
- Buka referensi
stackdriver untuk mengedit:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system edit stackdriver stackdriver
- Untuk meningkatkan permintaan CPU
gke-metrics-agent dari
10m hingga 50m , batas CPU dari 100m
ke 200m tambahkan 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 Anda edit 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 telah diterapkan, jalankan perintah berikut:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system get daemonset gke-metrics-agent -o yaml \
| grep "cpu: 50m"
Perintah tersebut 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, penjadwal dan
Metrik pengontrol-pengelola tidak 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, penjadwal dan
Metrik pengontrol-pengelola tidak ada. Misalnya, kedua metrik ini
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 gkeConnect yang disediakan
selama pembuatannya, Anda akan mendapatkan pesan 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 masih dapat menggunakan cluster admin ini, tetapi Anda akan mendapatkan
error berikut jika nanti Anda 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 cluster
pendaftaran. Setelah melakukan perbaikan ini, Anda dapat mengupgrade 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 admin Anda
file kubeconfig cluster.
- Jalankan perintah ini untuk mengupdate
OnPremAdminCluster
resource kustom.
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
--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 admin Anda
file konfigurasi cluster Anda.
|
Identitas |
1.10, 1.11, 1.12, 1.13 |
Menggunakan GKE Identity Service dapat menyebabkan
Hubungkan Agen untuk memulai ulang secara tidak terduga
Jika Anda menggunakan
Layanan Identitas GKE
fitur untuk mengelola
GKE Identity Service ClientConfig,
Connect Agent mungkin dimulai ulang secara tiba-tiba.
Solusi:
Jika pernah mengalami masalah pada cluster yang ada, Anda dapat melakukannya
salah satu hal berikut:
- Nonaktifkan GKE Identity Service. Jika Anda menonaktifkan
GKE Identity Service, yang tidak akan menghapus layanan yang telah di-deploy
Biner GKE Identity Service atau hapus
ClientConfig. Untuk menonaktifkan
GKE Identity Service, jalankan perintah ini:
gcloud container fleet identity-service disable \
--project PROJECT_ID
Ganti PROJECT_ID dengan ID cluster
project host fleet.
- Update cluster ke versi 1.9.3 atau yang lebih baru, atau versi 1.10.1 atau
nanti, untuk mengupgrade versi Connect Agent.
|
Jaringan |
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 di Cisco ACI
karena pembelajaran IP data-plane.
Solusi:
Solusi yang mungkin dilakukan adalah menonaktifkan pembelajaran IP
dengan menambahkan IP Seesaw
sebagai IP Virtual L4-L7 dalam Kebijakan Aplikasi Cisco
Pengontrol Infrastruktur (APIC).
Anda dapat mengkonfigurasi opsi L4-L7 Virtual IP dengan membuka Tenant >
Profil Aplikasi > EPG aplikasi atau EPG uSeg. Gagal
menonaktifkan pemelajaran IP akan
mengakibatkan timbulnya titik akhir IP 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 terkait
Rilis vSphere 7.0 Pembaruan 3:
- 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
vCenter
Server 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
pada node COS
Untuk Pod yang berjalan pada node yang menggunakan image Container-Optimized OS (COS),
Anda tidak dapat memasang volume emptyDir sebagai exec . Ini dipasang sebagai
noexec dan Anda akan mendapatkan error berikut: exec user
process caused: permission denied . Misalnya, Anda akan melihat
jika Anda 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
telah dinonaktifkan pada kumpulan node
Replika kumpulan node tidak diupdate setelah penskalaan otomatis diaktifkan dan
dinonaktifkan pada kumpulan node.
Solusi:
Menghapus
cluster.x-k8s.io/cluster-api-autoscaler-node-group-max-size
dan cluster.x-k8s.io/cluster-api-autoscaler-node-group-min-size
anotasi dari deployment mesin untuk node pool yang sesuai.
|
Logging dan pemantauan |
1.11, 1.12, 1.13 |
Dasbor pemantauan Windows menampilkan data dari cluster Linux
Dari versi 1.11, pada dasbor pemantauan siap pakai,
Dasbor status Pod Windows dan dasbor status node Windows juga ditampilkan
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 memiliki CrashLoopBackOff error jika ada
dan kerusakan log
yang {i>buffer <i}pada {i>disk<i}.
Solusi:
Untuk mengurangi masalah ini, kita perlu membersihkan log {i>buffer<i} pada
{i>node<i}.
- Untuk mencegah perilaku yang tidak terduga, 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 pengguna
file kubeconfig cluster.
- 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 pembersihan DaemonSet telah membersihkan semua potongan,
Anda dapat menjalankan perintah berikut. Output dari kedua perintah
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 Anda
perhatikan error berikut di log Anda:
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 tingkat input log
melebihi batas agen {i>logging<i},
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 sumber daya di
agen logging.
- Buka referensi
stackdriver untuk mengedit:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system edit stackdriver stackdriver
- Untuk meningkatkan permintaan CPU
stackdriver-log-forwarder
, tambahkan 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 Anda edit 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 telah diterapkan, jalankan perintah berikut:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system get daemonset stackdriver-log-forwarder -o yaml \
| grep "cpu: 1200m"
Perintah tersebut menemukan cpu: 1200m jika hasil edit Anda telah diterapkan.
|
Keamanan |
1.13 |
Layanan Kubelet tidak akan tersedia untuk sementara setelah NodeReady
ada periode singkat ketika {i>node<i}
siap, tetapi server kubelet
sertifikat belum siap. kubectl exec dan
kubectl logs tidak tersedia selama puluhan detik ini.
Hal ini karena pemberi persetujuan sertifikat server baru memerlukan waktu
melihat IP valid node yang diupdate.
Masalah ini hanya memengaruhi sertifikat server kubelet, hal ini tidak akan berpengaruh
Penjadwalan pod.
|
Upgrade, Update |
1.12 |
Upgrade cluster admin sebagian tidak memblokir cluster pengguna baru
upgrade
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 tidak diupgrade sepenuhnya, dan versi statusnya adalah
tetap 1,10. Upgrade cluster pengguna ke 1.12 tidak akan diblokir oleh preflight apa pun
pemeriksaan, dan gagal akibat masalah
distorsi versi.
Solusi:
Selesaikan untuk mengupgrade cluster admin ke 1.11 terlebih dahulu, lalu upgrade
cluster pengguna menjadi 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 dari ruang kosong datastore tidak boleh digunakan untuk
kumpulan node cluster, dan telah ditambahkan di gkectl diagnose cluster
tanpa sengaja.
Solusi:
Anda dapat mengabaikan pesan {i>error<i} atau
melewatkan 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 adalah
dengan konfigurasi load balancer MetalLB.
Proses penghapusan cluster pengguna mungkin macet karena beberapa alasan yang
mengakibatkan pembatalan validasi MatalLB ConfigMap. Tidak mungkin
untuk menambahkan cluster pengguna baru dalam status ini.
Solusi:
Anda dapat
menghapus paksa cluster pengguna Anda.
|
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 admin
cluster, dan saat gkectl check-config dieksekusi setelah admin
pembuatan cluster 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 dibuat untuk cluster pengguna check-config oleh
default menggunakan osImageType yang sama dari cluster admin, dan
saat ini VM uji belum kompatibel dengan COS.
Solusi:
Untuk menghindari pemeriksaan preflight lambat yang membuat VM pengujian,
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 pushprox-client pada pengguna
ke cluster yang diizinkan di server pushprox di cluster admin.
Gejalanya adalah pushprox-client di cluster pengguna yang mencetak log error seperti
hal 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 cluster admin
kube-system.
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--namespace kube-system scale deploy monitoring-operator \
--replicas=0
- Mengedit ConfigMap
pushprox-server-rbac-proxy-config
di namespace admin cluster kube-system.
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--namespace kube-system edit cm pushprox-server-rbac-proxy-config
Temukan baris principals untuk
external-pushprox-server-auth-proxy pemroses dan benar
principal_name untuk semua cluster pengguna dengan menghapus
kube-system substring 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 admin
dan deployment pushprox-client pada cluster yang terpengaruh
cluster pengguna:
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 1.12.2 dan yang lebih baru di mana masalah telah diperbaiki, tingkatkan
admin cluster kube-system monitoring-operator 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 VM
{i>template<i} 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 VM
template yang akan digunakan untuk memperbaiki VM bidang kontrol admin jika
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 cluster
project ID dan akun layanan dengan cluster admin untuk
Cloud Audit Logs sehingga cluster admin harus memiliki
izin akses.
Namun, jika cluster admin menggunakan project ID atau
akun layanan yang berbeda dari cluster pengguna mana pun, log audit dari admin
akan gagal dimasukkan ke Google Cloud. Gejalanya adalah
rangkaian Permission Denied error dalam
audit-proxy Pod di cluster admin.
Solusi:
Lihat langkah-langkah solusi
Untuk mengatasi masalah ini, izin akses dapat disiapkan dengan berinteraksi dengan
fitur Hub cloudauditlogging :
- Pertama, periksa apakah akun layanan yang ada dan diizinkan
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 hal 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
cloudauditlogging Fitur Hub:
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 , ini berarti ada
akun layanan yang diizinkan untuk project ini, Anda dapat menggunakan
akun layanan dari daftar ini di cluster Anda, atau tambahkan 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" , artinya penyiapan izin tidak berhasil.
Coba selesaikan masalah di kolom description
respons, atau mencadangkan daftar yang diizinkan saat ini, hapus
fitur hub cloudauditlogging, dan aktifkan kembali setelah langkah 1
bagian ini lagi. Anda dapat menghapus cloudauditlogging
Fitur penghubung 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,
fungsi ini akan mengalami kegagalan
seperti 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, ia akan mengalami kegagalan berikut 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, untuk
contoh, gkectl diagnose snapshot berkontribusi pada kapasitas disk
tingkat penggunaan.
Sejak Google Distributed Cloud v1.8, image Ubuntu telah di-hardening dengan CIS Level 2
{i>Benchmark<i}. Dan salah satu aturan kepatuhan, "4.1.2.2 Memastikan log audit
tidak dihapus secara otomatis", memastikan setelan yang diaudit
max_log_file_action = keep_logs . Hal ini menghasilkan semua
audit yang disimpan pada {i>disk<i}.
Solusi:
Lihat langkah-langkah solusi
Stasiun kerja admin
Untuk workstation admin, Anda dapat secara manual mengubah status
untuk merotasi log secara otomatis, lalu memulai ulang proses audit
layanan:
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 dirotasi
setelah menghasilkan lebih dari 250 file (masing-masing berukuran 8 M).
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: /
Perlu diketahui bahwa perubahan konfigurasi yang diaudit ini akan melanggar CIS Level 2
aturan "4.1.2.2 Memastikan log audit tidak dihapus secara otomatis".
|
Jaringan |
1.10, 1.11.0-1.11.3, 1.12.0-1.12.2, 1.13.0 |
NetworkGatewayGroup IP mengambang bentrok dengan node
Anda
Pengguna tidak dapat membuat atau mengupdate 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"
Dalam versi yang terdampak, kubelet dapat keliru mengikat ke IP mengambang
yang ditetapkan ke node dan melaporkannya sebagai alamat node di
node.status.addresses . Webhook yang memvalidasi akan memeriksa
NetworkGatewayGroup alamat IP mengambang terhadap semua
node.status.addresses dalam cluster dan melihatnya sebagai
konflik.
Solusi:
Dalam cluster yang sama tempat pembuatan atau update
Objek NetworkGatewayGroup gagal, nonaktifkan untuk sementara
webhook yang memvalidasi ANG dan mengirimkan 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
dan hampir 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 masuk ke
antrean tak terbatas selama booting, dan Anda akan melihat
error loop tak terbatas di /var/log/cloud-init-output.log
file:
+ 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 saat Google Distributed Cloud mencoba mendapatkan node IP
di skrip startup, kode ini menggunakan grep -v
ADMIN_CONTROL_PLANE_VIP untuk melewati VIP bidang kontrol cluster admin
yang juga dapat
ditugaskan ke NIC. Namun, perintah itu juga melewati
alamat IP apa pun yang memiliki awalan VIP bidang kontrol, yang menyebabkan
skrip startup menjadi hang.
Misalnya, anggaplah VIP bidang kontrol admin cluster
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
terhambat selama pembuatan. Masalah ini juga dapat
terpicu jika
memiliki imbuhan yang sama dengan VIP bidang kontrol,
contoh, 192.168.1.255 .
Solusi:
- Jika alasan waktu tunggu pembuatan cluster admin telah habis
alamat IP siaran, jalankan perintah berikut di cluster admin
VM bidang kontrol:
ip addr add ${ADMIN_CONTROL_PLANE_NODE_IP}/32 dev ens192
Ini akan membuat baris tanpa alamat siaran, dan membatalkan pemblokiran
proses {i>booting<i}. Setelah skrip startup dibatalkan pemblokirannya, hapus ini
baris yang ditambahkan dengan menjalankan perintah berikut:
ip addr del ${ADMIN_CONTROL_PLANE_NODE_IP}/32 dev ens192
- Namun, jika alasan waktu tunggu pembuatan cluster admin telah habis
ke alamat IP VM bidang kontrol, Anda tidak dapat berhenti memblokir
skrip startup. Beralihlah ke alamat IP lain, dan buat ulang atau
upgrade ke versi 1.10.3 atau yang lebih baru.
|
Sistem operasi, Peningkatan Versi, Pembaruan |
1.10.0-1.10.2 |
Status cluster admin yang menggunakan image COS akan hilang pada
upgrade cluster admin atau perbaikan master admin
DataDisk tidak dapat dipasang dengan benar ke node master cluster admin saat
menggunakan gambar COS dan status cluster admin yang menggunakan gambar COS akan
tersesat saat upgrade cluster admin atau perbaikan master admin. (cluster admin
menggunakan gambar COS adalah fitur pratinjau)
Solusi:
Buat ulang cluster admin dengan osImageType yang disetel ke ubuntu_containerd
Setelah Anda 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
dirutekan ke pemrosesan lokal yang diselesaikan oleh sistem di 127.0.0.53
secara {i>default<i}. Alasannya adalah bahwa pada {i>image<i} Ubuntu 20.04
yang digunakan dalam versi
1.10.0, /etc/resolv.conf ditautkan secara symlink ke
/run/systemd/resolve/stub-resolv.conf , yang menunjukkan
127.0.0.53 stub DNS localhost.
Akibatnya, resolusi nama DNS {i>localhost<i}
menolak untuk memeriksa
server DNS upstream (ditentukan di
/run/systemd/resolve/resolv.conf ) untuk nama dengan
Akhiran .local , kecuali jika nama ditentukan sebagai penelusuran
domain.
Hal ini menyebabkan pencarian nama .local gagal. Sebagai
misalnya, saat startup node, kubelet gagal mengambil gambar
dari registry pribadi dengan akhiran .local . Menetapkan
Alamat vCenter dengan akhiran .local tidak akan berfungsi di
komputer admin.
Solusi:
Anda dapat menghindari masalah ini untuk node cluster jika Anda menentukan
Kolom searchDomainsForDNS di konfigurasi cluster admin Anda
dan file konfigurasi cluster pengguna untuk menyertakan domain.
Saat ini gkectl update tidak mendukung pembaruan
Kolom searchDomainsForDNS .
Oleh karena itu, jika Anda belum menyiapkan kolom ini sebelum pembuatan cluster,
Anda harus menjalankan SSH ke node dan
melewati stub yang diselesaikan oleh sistem lokal
mengubah symlink /etc/resolv.conf dari
/run/systemd/resolve/stub-resolv.conf (yang berisi
127.0.0.53 stub lokal) ke
/run/systemd/resolve/resolv.conf (yang menunjukkan
DNS upstream):
sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf
Sedangkan untuk workstation admin, gkeadm tidak mendukung
menentukan domain penelusuran, jadi Anda harus mengatasi masalah ini dengan panduan
langkah waktu ini.
Solusi ini tidak dapat diterapkan di seluruh pembuatan ulang VM. Anda harus
terapkan 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 Docker
jembatan alamat IP yang menggunakan --bip=169.254.123.1/24 , sehingga
ia tidak akan mencadangkan subnet 172.17.0.1/16 default. Namun,
di versi 1.10.0, ada {i>bug<i} di Ubuntu OS image yang menyebabkan
konfigurasi Docker yang disesuaikan agar diabaikan.
Hasilnya, Docker memilih 172.17.0.1/16 default sebagai
menghubungkan subnet alamat IP. Hal ini dapat menyebabkan
konflik alamat IP jika Anda
sudah memiliki beban kerja yang berjalan
dalam rentang alamat IP tersebut.
Solusi:
Untuk mengatasi masalah ini, Anda harus mengganti nama konfigurasi system berikut
untuk Docker, lalu mulai 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 mengajukan permohonan 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 bertentangan dengan 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 di
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}
- 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
|
Jaringan |
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 ditetapkan
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. Seharusnya
memulihkan lalu lintas.
|
Sistem operasi |
1.16, 1.28.0-1.28.200 |
Kubelet dibanjiri log yang menyatakan bahwa "/etc/kubernetes/manifess" tidak ada pada worker node
"staticPodPath" tidak sengaja ditetapkan untuk worker node
Solusi:
Buat folder "/etc/kubernetes/manifess" secara manual
|