Halaman ini menunjukkan cara menyelesaikan masalah yang terkait dengan penginstalan atau upgrade cluster Google Distributed Cloud.
Jika Anda memerlukan bantuan tambahan, hubungi Cloud Customer Care.Masalah penginstalan
Bagian berikut dapat membantu Anda memecahkan masalah terkait penginstalan Google Distributed Cloud.
Pesan error sementara
Proses penginstalan untuk Google Distributed Cloud adalah proses berkelanjutan rekonsiliasi. Akibatnya, Anda mungkin melihat pesan error sementara di selama instalasi.
Selama instalasi berhasil diselesaikan, kesalahan ini dapat akan diabaikan dengan aman. Berikut adalah daftar pesan log error sementara yang umum:
Internal error occurred: failed calling webhook "webhook.cert-manager.io": Post
https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s:
dial tcp IP_ADDRESS:443: connect: connection refused
Internal error occurred: failed calling webhook "vcluster.kb.io": Post
https://webhook-service.kube-system.svc:443/validate-baremetal-cluster-gke-io-v1-cluster?timeout=30s:
dial tcp IP_ADDRESS:443: connect: connection refused
Failed to register cluster with GKE Hub; gcloud output: error running command
'gcloud container fleet memberships register CLUSTER_NAME --verbosity=error --quiet':
error: exit status 1, stderr: 'ERROR: (gcloud.container.hub.memberships.register)
Failed to check if the user is a cluster-admin: Unable to connect to the server: EOF
Get
https://127.0.0.1:34483/apis/infrastructure.baremetal.cluster.gke.io/v1/namespaces/cluster-
cluster1/baremetalmachines: dial tcp 127.0.0.1:34483: connect: connection refused"
Create Kind Cluster "msg"="apply run failed" "error"="unable to recognize \"/tmp/kout088683152\": no matches for kind \"NetworkLogging\" in version \"networking.gke.io/v1alpha1\""
Create Kind Cluster "msg"="apply run failed" "error"="unable to recognize \"/tmp/kout869681888\": no matches for kind \"Provider\" in version \"clusterctl.cluster.x-k8s.io/v1alpha3\""
Jika kunci akun layanan Google Cloud Anda telah habis masa berlakunya, Anda akan melihat pesan berikut
pesan error dari bmctl
:
Error validating cluster config: 3 errors occurred:
* GKEConnect check failed: Get https://gkehub.googleapis.com/v1beta1/projects/project/locations/global/memberships/admin: oauth2: cannot fetch token: 400 Bad Request
Response: {"error":"invalid_grant","error_description":"Invalid JWT Signature."}
* ClusterOperations check failed: Post https://cloudresourcemanager.googleapis.com/v1/projects/project:testIamPermissions?alt=json&prettyPrint=false: oauth2: cannot fetch token: 400 Bad Request
Response: {"error":"invalid_grant","error_description":"Invalid JWT Signature."}
* GCR pull permission for bucket: artifacts.anthos-baremetal-release.appspot.com failed: Get https://storage.googleapis.com/storage/v1/b/artifacts.anthos-baremetal-release.appspot.com/iam/testPermissions?alt=json&permissions=storage.objects.get&permissions=storage.objects.list&prettyPrint=false: oauth2: cannot fetch token: 400 Bad Request
Response: {"error":"invalid_grant","error_description":"Invalid JWT Signature."}
Anda harus membuat kunci akun layanan baru.
Menggunakan cluster bootstrap untuk men-debug masalah
Saat Google Distributed Cloud mengelola pengelolaan sendiri (admin, hybrid, atau mandiri) cluster, LLM men-deploy Kubernetes dalam Docker (jenis) cluster untuk sementara menghosting pengontrol Kubernetes yang diperlukan untuk membuat cluster. Fitur sementara ini cluster yang disebut sebagai cluster bootstrap. Cluster pengguna dibuat dan diupgrade oleh admin yang mengelola atau cluster hibridanya tanpa menggunakan cluster bootstrap.
Jika cluster jenis sudah ada di deployment Anda saat mencoba menginstal,
Google Distributed Cloud menghapus cluster jenis yang ada. Hanya penghapusan
yang terjadi setelah instalasi
atau peningkatan versi berhasil.
Untuk mempertahankan cluster jenis yang ada bahkan setelah berhasil, gunakan metode
Tanda --keep-bootstrap-cluster
dari bmctl
.
Google Distributed Cloud membuat file konfigurasi untuk cluster bootstrap
di bawah WORKSPACE_DIR/.kindkubeconfig
. Anda dapat terhubung ke
cluster bootstrap hanya selama pembuatan dan upgrade cluster.
Cluster bootstrap perlu mengakses repositori Docker untuk mengambil image. Tujuan
secara default disetel ke Container Registry, kecuali jika Anda menggunakan
registry pribadi. Selama pembuatan cluster,bmctl
akan membuat file berikut:
bmctl-workspace/config.json
: Berisi akun layanan Google Cloud kredensial untuk akses {i>registry<i}. Kredensial diperoleh dari KolomgcrKeyPath
di file konfigurasi cluster.bmctl-workspace/config.toml
: Berisi konfigurasi dalam container di klaster yang baik.
Memeriksa log cluster bootstrap
Untuk men-debug cluster bootstrap, Anda dapat melakukan langkah-langkah berikut:
- Menghubungkan ke cluster bootstrap selama pembuatan dan upgrade cluster.
- Mendapatkan log cluster bootstrap.
Anda dapat menemukan log di mesin yang Anda gunakan untuk menjalankan bmctl
di bawah
folder:
bmctl-workspace/CLUSTER_NAME/log/create-cluster-TIMESTAMP/bootstrap-cluster/
bmctl-workspace/CLUSTER_NAME/log/upgrade-cluster-TIMESTAMP/bootstrap-cluster/
Ganti CLUSTER_NAME
dan TIMESTAMP
dengan
nama cluster Anda dan waktu sistem yang sesuai.
Untuk mendapatkan log dari cluster bootstrap secara langsung, Anda dapat menjalankan perintah selama pembuatan dan upgrade cluster:
docker exec -it bmctl-control-plane bash
Perintah membuka terminal di dalam kontainer bidang kontrol {i>bmctl<i} yang berjalan di cluster bootstrap.
Untuk memeriksa log kubelet
dan containerd
, gunakan perintah berikut dan
cari error atau peringatan dalam output:
journalctl -u kubelet
journalctl -u containerd
Masalah upgrade cluster
Saat mengupgrade cluster Google Distributed Cloud, Anda dapat memantau progres dan memeriksa status cluster dan node Anda.
- Jika Anda mengalami masalah selama upgrade, coba tentukan pada tahap mana terjadi kegagalan. Untuk mempelajari lebih lanjut apa yang terjadi pada cluster selama proses upgrade, lihat Siklus proses dan tahapan upgrade cluster.
- Untuk mempelajari lebih lanjut dampak masalah selama upgrade cluster, lihat Memahami dampak kegagalan di Google Distributed Cloud.
Panduan berikut dapat membantu menentukan apakah upgrade dapat dilanjutkan seperti biasa atau jika ada masalah.
Memantau progres upgrade
Menggunakan perintah kubectl describe cluster
untuk melihat status cluster
selama proses upgrade:
kubectl describe cluster CLUSTER_NAME \
--namespace CLUSTER_NAMESPACE \
--kubeconfig ADMIN_KUBECONFIG
Ganti nilai berikut:
CLUSTER_NAME
: nama .CLUSTER_NAMESPACE
: namespace.ADMIN_KUBECONFIG
: admin {i>kubeconfig<i}.- Secara default, cluster admin, hybrid, dan mandiri menggunakan upgrade yang diterapkan.
Jika Anda menggunakan flag
--use-bootstrap=true
dengan perintahbmctl upgrade
, operasi upgrade menggunakan cluster bootstrap. Untuk memantau progres upgrade saat cluster bootstrap digunakan, tentukan jalur ke cluster bootstrap file kubeconfig,.kindkubeconfig
. File ini ada di ruang kerja saat ini.
- Secara default, cluster admin, hybrid, dan mandiri menggunakan upgrade yang diterapkan.
Jika Anda menggunakan flag
Lihat bagian Status
dari output, yang menunjukkan agregasi
status upgrade cluster. Jika cluster melaporkan error, gunakan
bagian untuk memecahkan masalah tersebut.
Periksa apakah node sudah siap
Menggunakan perintah kubectl get nodes
untuk melihat status node dalam cluster
selama proses upgrade:
kubectl get nodes --kubeconfig KUBECONFIG
Untuk memeriksa apakah node berhasil menyelesaikan proses upgrade, lihat
Kolom VERSION
dan AGE
dalam respons perintah. VERSION
adalah
Versi Kubernetes untuk cluster. Untuk melihat versi Kubernetes pada
Versi Google Distributed Cloud, lihat Pembuatan Versi.
Jika node menampilkan NOT READY
, coba hubungkan node dan periksa kubelet
status:
systemctl status kubelet
Anda juga dapat meninjau log kubelet:
journalctl -u kubelet
Meninjau output status kubelet dan log ke pesan yang menunjukkan alasannya {i>node <i}memiliki masalah.
Memeriksa node mana yang diupgrade
Untuk memeriksa node mana di cluster yang sedang dalam proses upgrade, gunakan
Perintah kubectl get baremetalmachines
:
kubectl get baremetalmachines --namespace CLUSTER_NAMESPACE \
--kubeconfig ADMIN_KUBECONFIG
Ganti nilai berikut:
CLUSTER_NAMESPACE
: namespace.ADMIN_KUBECONFIG
: admin {i>kubeconfig<i}.- Jika cluster bootstrap digunakan untuk
peningkatan versi admin, hybrid, atau mandiri,
menentukan file kubeconfig cluster bootstrap
(
bmctl-workspace/.kindkubeconfig
).
- Jika cluster bootstrap digunakan untuk
peningkatan versi admin, hybrid, atau mandiri,
menentukan file kubeconfig cluster bootstrap
(
Contoh {i>output<i} berikut menunjukkan bahwa {i>node<i} yang
sedang diupgrade memiliki
ABM VERSION
berbeda dengan DESIRED ABM VERSION
:
NAME CLUSTER READY INSTANCEID MACHINE ABM VERSION DESIRED ABM VERSION
10.200.0.2 cluster1 true baremetal://10.200.0.2 10.200.0.2 1.13.0 1.14.0
10.200.0.3 cluster1 true baremetal://10.200.0.3 10.200.0.3 1.13.0 1.13.0
Periksa node apa yang sedang dalam proses pengosongan
Selama proses upgrade, Pod akan terkuras dari node, dan penjadwalan akan
dinonaktifkan hingga node berhasil diupgrade. Untuk melihat node mana yang
pengosongan, gunakan perintah kubectl get nodes
:
kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG | grep "SchedulingDisabled"
Ganti USER_CLUSTER_KUBECONFIG
dengan jalur ke file {i>
cluster kubeconfig<i} pengguna.
Kolom STATUS
difilter menggunakan grep
agar hanya menampilkan node yang melaporkan
SchedulingDisabled
. Status ini menunjukkan bahwa node sedang dikosongkan.
Anda juga dapat memeriksa status node dari cluster admin:
kubectl get baremetalmachines -n CLUSTER_NAMESPACE \
--kubeconfig ADMIN_KUBECONFIG
Ganti nilai berikut:
CLUSTER_NAMESPACE
: namespace.ADMIN_KUBECONFIG
: admin {i>kubeconfig<i}.- Jika cluster bootstrap digunakan untuk
peningkatan versi admin, hybrid, atau mandiri,
menentukan file kubeconfig cluster bootstrap
(
bmctl-workspace/.kindkubeconfig
).
- Jika cluster bootstrap digunakan untuk
peningkatan versi admin, hybrid, atau mandiri,
menentukan file kubeconfig cluster bootstrap
(
Node yang kehabisan daya menampilkan status di bawah kolom MAINTENANCE
.
Memeriksa alasan node telah berada dalam status tidak aktif untuk waktu yang lama
Gunakan salah satu metode di bagian sebelumnya untuk
mengidentifikasi node yang mendapatkan
dihabiskan menggunakan perintah kubectl get nodes
. Gunakan perintah kubectl get
pods
dan filter nama node ini untuk melihat detail tambahan:
kubectl get pods --all-namespaces -o wide --field-selector spec.nodeName=NODE_NAME
Ganti NODE_NAME
dengan nama
dan node sedang dikosongkan. Output menampilkan daftar Pod yang macet atau lambat untuk
akan habis. Upgrade akan dilanjutkan, bahkan dengan Pod yang macet, saat proses pengosongan berjalan
sebuah {i>node<i} memerlukan
waktu lebih dari 20 menit.
Mulai rilis 1.29, pengurasan node
menggunakan fitur Penghapusan
API, yang mematuhi PodDisruptionBudgets
(PDB).
Setelan PDB berikut dapat menyebabkan masalah pengosongan node:
Pod yang dikelola oleh beberapa PDB
Konfigurasi statis PDB seperti berikut:
maxUnavailable
==0
minUnavailable
>= total replika
Jumlah total replika sulit ditentukan dari sumber daya PDB, karena sudah ditentukan dalam resource level lebih tinggi, seperti
Deployment
,ReplicaSet
, atauStatefulSet
. PDB cocok dengan pod berdasarkan pemilih hanya di konfigurasi mereka. Pendekatan yang baik untuk mendiagnosis apakah PDB statis menyebabkan masalah adalah melihat apakahpdb.Status.ExpectPods
<=pdb.Status.DesiredHealthy
pertama dan melihat apakah salah satu konfigurasi statis yang disebutkan memungkinkan hal ini terjadi.
Pelanggaran runtime, seperti nilai DisruptionsAllowed
yang dihitung untuk PDB
resource yang menjadi 0
, juga dapat memblokir pengosongan node. Jika Anda memiliki
Objek PodDisruptionBudget
dikonfigurasi
yang tidak dapat menyebabkan gangguan tambahan, upgrade node mungkin gagal
meng-upgrade ke versi bidang kontrol
setelah percobaan berulang kali. Untuk mencegah hal ini
gagal, sebaiknya tingkatkan Deployment
atau
HorizontalPodAutoscaler
agar node dapat menghabiskan waktu sambil tetap mematuhi
Konfigurasi PodDisruptionBudget
.
Untuk melihat semua objek PodDisruptionBudget
yang tidak mengizinkan gangguan apa pun, gunakan
perintah berikut:
kubectl get poddisruptionbudget --all-namespaces \
-o jsonpath='{range .items[?(@.status.disruptionsAllowed==0)]}{.metadata.name}/{.metadata.namespace}{"\n"}{end}'
Memeriksa alasan Pod tidak responsif
Upgrade dapat gagal jika Pod berisi upgrade-first-node
atau upgrade-node
alamat IP bidang kontrol. Perilaku ini biasanya terjadi karena Pod statis
tidak sehat.
Periksa Pod statis dengan perintah
crictl ps -a
dan cari apakah membuat error Kubernetes atau Podetcd
. Jika terdapat Pod yang gagal, tinjau log untuk Pod untuk melihat mengapa Pod tersebut mengalami error.Beberapa kemungkinan untuk perilaku crashloop mencakup hal berikut:
- Izin atau pemilik file yang dipasang ke Pod statis tidak benar.
- Konektivitas ke alamat IP virtual tidak berfungsi.
- Masalah terkait
etcd
.
Jika perintah
crictl ps
tidak berfungsi atau tidak menampilkan apa pun, periksa Statuskubelet
dancontainerd
. Gunakan perintahsystemctl status SERVICE
danjournalctl -u SERVICE
untuk melihat log.
Langkah selanjutnya
- Jika Anda memerlukan bantuan tambahan, hubungi Cloud Customer Care.