**Bantu tingkatkan halaman ini**
Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Untuk berkontribusi pada panduan pengguna ini, pilih **Edit halaman ini pada GitHub** tautan yang terletak di panel kanan setiap halaman.
Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Memecahkan masalah node hybrid
Topik ini mencakup beberapa kesalahan umum yang mungkin Anda lihat saat menggunakan Amazon EKS Hybrid Nodes dan cara memperbaikinya. *Untuk informasi pemecahan masalah lainnya, lihat [Memecahkan masalah dengan kluster dan node Amazon EKS](troubleshooting.md) dan [tag Pusat Pengetahuan untuk Amazon EKS](https://repost.aws/tags/knowledge-center/TA4IvCeWI1TE66q4jEj4Z9zg/amazon-elastic-kubernetes-service) di AWS re:Post.* Jika Anda tidak dapat menyelesaikan masalah, hubungi AWS Support.
**Pemecahan masalah node dengan `nodeadm debug`** Anda dapat menjalankan `nodeadm debug` perintah dari node hybrid Anda untuk memvalidasi jaringan dan persyaratan kredensi terpenuhi. Untuk informasi lebih lanjut tentang `nodeadm debug` perintah, lihat[`nodeadm`Referensi node hibrida](hybrid-nodes-nodeadm.md).
**Mendeteksi masalah dengan node hibrid Anda dengan wawasan klaster** Amazon EKS cluster insights mencakup *pemeriksaan wawasan* yang mendeteksi masalah umum dengan konfigurasi EKS Hybrid Nodes di klaster Anda. Anda dapat melihat hasil semua pemeriksaan wawasan dari Konsol Manajemen AWS, AWS CLI, dan. AWS SDKs Untuk informasi selengkapnya tentang wawasan cluster, lihat[Bersiaplah untuk upgrade versi Kubernetes dan pecahkan masalah kesalahan konfigurasi dengan wawasan klaster](cluster-insights.md).
## Menginstal pemecahan masalah node hybrid
Topik pemecahan masalah berikut terkait dengan menginstal dependensi node hybrid pada host dengan perintah. `nodeadm install`
**`nodeadm`perintah gagal `must run as root`**
`nodeadm install`Perintah harus dijalankan dengan pengguna yang memiliki root atau `sudo` hak istimewa pada host Anda. Jika Anda menjalankan `nodeadm install` dengan pengguna yang tidak memiliki root atau `sudo` hak istimewa, Anda akan melihat kesalahan berikut dalam `nodeadm` output.
```
"msg":"Command failed","error":"must run as root"
```
**Tidak dapat terhubung ke dependensi**
`nodeadm install`Perintah menginstal dependensi yang diperlukan untuk node hybrid. Dependensi node hybrid mencakup`containerd`,, `kubelet``kubectl`, dan komponen AWS SSM atau AWS IAM Roles Anywhere. Anda harus memiliki akses dari tempat Anda menjalankan `nodeadm install` untuk mengunduh dependensi ini. Untuk informasi lebih lanjut tentang daftar lokasi yang harus dapat Anda akses, lihat[Mempersiapkan jaringan untuk node hybrid](hybrid-nodes-networking.md). Jika Anda tidak memiliki akses, Anda akan melihat kesalahan yang mirip dengan yang berikut dalam `nodeadm install` output.
```
"msg":"Command failed","error":"failed reading file from url: ...: max retries achieved for http request"
```
**Gagal memperbarui pengelola paket**
`nodeadm install`Perintah berjalan `apt update` atau `yum update` atau `dnf update` sebelum menginstal dependensi node hybrid. Jika langkah ini tidak berhasil, Anda mungkin melihat kesalahan yang mirip dengan berikut ini. Untuk memulihkan, Anda dapat menjalankan `apt update` atau `yum update` atau `dnf update` sebelum berlari `nodeadm install` atau Anda dapat mencoba menjalankan kembali`nodeadm install`.
```
failed to run update using package manager
```
**Batas waktu tunggu atau batas waktu konteks terlampaui**
Saat menjalankan`nodeadm install`, jika Anda melihat masalah pada berbagai tahap proses penginstalan dengan kesalahan yang menunjukkan ada batas waktu atau batas waktu konteks terlampaui, Anda mungkin memiliki koneksi lambat yang mencegah penginstalan dependensi node hibrida sebelum batas waktu terpenuhi. Untuk mengatasi masalah ini, Anda dapat mencoba menggunakan `--timeout` tanda `nodeadm` untuk memperpanjang durasi batas waktu untuk mengunduh dependensi.
```
nodeadm install K8S_VERSION --credential-provider CREDS_PROVIDER --timeout 20m0s
```
## Menghubungkan pemecahan masalah node hybrid
Topik pemecahan masalah di bagian ini terkait dengan proses menghubungkan node hybrid ke cluster EKS dengan perintah. `nodeadm init`
**Kesalahan operasi atau skema yang tidak didukung**
Saat menjalankan`nodeadm init`, jika Anda melihat kesalahan yang terkait dengan `operation error` atau`unsupported scheme`, periksa kesalahan Anda `nodeConfig.yaml` untuk memastikannya diformat dengan benar dan diteruskan ke`nodeadm`. Untuk informasi selengkapnya tentang format dan opsi untuk`nodeConfig.yaml`, lihat[`nodeadm`Referensi node hibrida](hybrid-nodes-nodeadm.md).
```
"msg":"Command failed","error":"operation error ec2imds: GetRegion, request canceled, context deadline exceeded"
```
**Peran IAM Node Hybrid tidak memiliki izin untuk tindakan `eks:DescribeCluster`**
Saat menjalankan`nodeadm init`, `nodeadm` cobalah mengumpulkan informasi tentang cluster EKS Anda dengan memanggil `DescribeCluster` tindakan EKS. Jika peran IAM Hybrid Nodes Anda tidak memiliki izin untuk `eks:DescribeCluster` tindakan tersebut, maka Anda harus meneruskan endpoint Kubernetes API, cluster CA bundle, dan service IPv4 CIDR dalam konfigurasi node yang Anda berikan saat Anda menjalankan. `nodeadm` `nodeadm init` Untuk informasi selengkapnya tentang izin yang diperlukan untuk peran IAM Hybrid Nodes, lihat. [Siapkan kredensil untuk node hybrid](hybrid-nodes-creds.md)
```
"msg":"Command failed","error":"operation error EKS: DescribeCluster, https response error StatusCode: 403 ... AccessDeniedException"
```
**Peran IAM Node Hybrid tidak memiliki izin untuk tindakan `eks:ListAccessEntries`**
Saat menjalankan`nodeadm init`, `nodeadm` mencoba untuk memvalidasi apakah klaster EKS Anda memiliki entri akses tipe yang `HYBRID_LINUX` terkait dengan peran IAM Hybrid Nodes dengan memanggil tindakan EKS`ListAccessEntries`. Jika peran IAM Hybrid Nodes Anda tidak memiliki izin untuk `eks:ListAccessEntries` tindakan tersebut, maka Anda harus meneruskan `--skip cluster-access-validation` flag saat menjalankan `nodeadm init` perintah. Untuk informasi selengkapnya tentang izin yang diperlukan untuk peran IAM Hybrid Nodes, lihat. [Siapkan kredensil untuk node hybrid](hybrid-nodes-creds.md)
```
"msg":"Command failed","error":"operation error EKS: ListAccessEntries, https response error StatusCode: 403 ... AccessDeniedException"
```
**IP node tidak dalam jaringan node jarak jauh CIDR**
Saat menjalankan`nodeadm init`, Anda mungkin mengalami kesalahan jika alamat IP node tidak berada dalam jaringan node jarak jauh yang ditentukan CIDRs. Kesalahan akan terlihat mirip dengan contoh berikut:
```
node IP 10.18.0.1 is not in any of the remote network CIDR blocks [10.0.0.0/16 192.168.0.0/16]
```
Contoh ini menunjukkan node dengan IP 10.18.0.1 mencoba bergabung dengan cluster dengan jaringan jarak jauh 10.0.0.0/16 dan CIDRs 192.168.0.0/16. Kesalahan terjadi karena 10.18.0.1 tidak berada dalam salah satu rentang.
Konfirmasikan bahwa Anda telah mengonfigurasi dengan benar `RemoteNodeNetworks` untuk menyertakan semua alamat IP node. Untuk informasi selengkapnya tentang konfigurasi jaringan, lihat[Mempersiapkan jaringan untuk node hybrid](hybrid-nodes-networking.md).
+ Jalankan perintah berikut di wilayah klaster Anda berada untuk memeriksa `RemoteNodeNetwork` konfigurasi Anda. Verifikasi bahwa blok CIDR yang tercantum dalam output menyertakan rentang IP node Anda dan sama dengan blok CIDR yang tercantum dalam pesan kesalahan. Jika tidak cocok, konfirmasikan nama klaster dan wilayah yang `nodeConfig.yaml` sesuai dengan klaster yang Anda inginkan.
```
aws eks describe-cluster --name CLUSTER_NAME --region REGION_NAME --query cluster.remoteNetworkConfig.remoteNodeNetworks
```
+ Verifikasi bahwa Anda bekerja dengan node yang dimaksud:
+ Konfirmasikan bahwa Anda berada di node yang benar dengan memeriksa nama host dan alamat IPnya cocok dengan yang ingin Anda daftarkan ke cluster.
+ Konfirmasikan bahwa node ini berada di jaringan lokal yang benar (yang jangkauan CIDR-nya terdaftar `RemoteNodeNetwork` selama penyiapan cluster).
Jika IP node Anda masih tidak seperti yang Anda harapkan, periksa hal berikut:
+ Jika Anda menggunakan IAM Roles Anywhere, `kubelet` lakukan pencarian DNS pada IAM Roles Anywhere `nodeName` dan menggunakan IP yang terkait dengan nama node jika tersedia. Jika Anda mempertahankan entri DNS untuk node Anda, konfirmasikan bahwa entri ini mengarah ke IPs dalam jaringan node jarak jauh Anda. CIDRs
+ Jika node Anda memiliki beberapa antarmuka jaringan, `kubelet` mungkin pilih antarmuka dengan alamat IP di luar jaringan node jarak jauh Anda CIDRs sebagai default. Untuk menggunakan antarmuka yang berbeda, tentukan alamat IP-nya menggunakan `--node-ip` `kubelet` bendera di`nodeConfig.yaml`. Untuk informasi selengkapnya, lihat [`nodeadm`Referensi node hibrida](hybrid-nodes-nodeadm.md). Anda dapat melihat antarmuka jaringan node Anda dan alamat IP-nya dengan menjalankan perintah berikut pada node Anda:
```
ip addr show
```
**Node hibrida tidak muncul di kluster EKS**
Jika Anda menjalankan `nodeadm init` dan itu selesai tetapi node hibrida Anda tidak muncul di klaster Anda, mungkin ada masalah dengan koneksi jaringan antara node hybrid Anda dan bidang kontrol EKS, Anda mungkin tidak memiliki izin grup keamanan yang diperlukan yang dikonfigurasi, atau Anda mungkin tidak memiliki pemetaan yang diperlukan dari peran IAM Hybrid Nodes Anda ke Kubernetes Role-Based Access Control (RBAC). Anda dapat memulai proses debugging dengan memeriksa status `kubelet` dan `kubelet` log dengan perintah berikut. Jalankan perintah berikut dari node hybrid yang gagal bergabung dengan cluster Anda.
```
systemctl status kubelet
```
```
journalctl -u kubelet -f
```
**Tidak dapat berkomunikasi dengan cluster**
Jika node hybrid Anda tidak dapat berkomunikasi dengan bidang kontrol cluster, Anda mungkin melihat log yang mirip dengan berikut ini.
```
"Failed to ensure lease exists, will retry" err="Get ..."
```
```
"Unable to register node with API server" err="Post ..."
```
```
Failed to contact API server when waiting for CSINode publishing ... dial tcp : i/o timeout
```
Jika Anda melihat pesan ini, periksa hal berikut untuk memastikannya memenuhi persyaratan node hibrida yang dirinci[Mempersiapkan jaringan untuk node hybrid](hybrid-nodes-networking.md).
+ Konfirmasikan bahwa VPC yang diteruskan ke kluster EKS memiliki rute ke Transit Gateway (TGW) atau Virtual Private Gateway (VGW) untuk node lokal dan pod opsional Anda. CIDRs
+ Konfirmasikan bahwa Anda memiliki grup keamanan tambahan untuk klaster EKS Anda yang memiliki aturan masuk untuk node lokal CIDRs dan pod opsional. CIDRs
+ Konfirmasikan router lokal Anda dikonfigurasi untuk mengizinkan lalu lintas ke dan dari bidang kontrol EKS.
**Tidak sah**
Jika node hibrida Anda dapat berkomunikasi dengan bidang kontrol EKS tetapi tidak dapat mendaftar, Anda mungkin melihat log yang mirip dengan berikut ini. Perhatikan perbedaan utama dalam pesan log di bawah ini adalah `Unauthorized` kesalahannya. Ini menandakan bahwa node tidak dapat melakukan tugasnya karena tidak memiliki izin yang diperlukan.
```
"Failed to ensure lease exists, will retry" err="Unauthorized"
```
```
"Unable to register node with API server" err="Unauthorized"
```
```
Failed to contact API server when waiting for CSINode publishing: Unauthorized
```
Jika Anda melihat pesan-pesan ini, periksa hal berikut untuk memastikannya memenuhi rincian persyaratan node hibrida di [Siapkan kredensil untuk node hybrid](hybrid-nodes-creds.md) dan[Mempersiapkan akses cluster untuk node hybrid](hybrid-nodes-cluster-prep.md).
+ Konfirmasikan identitas node hybrid sesuai dengan peran IAM Hybrid Nodes yang Anda harapkan. Ini dapat dilakukan dengan menjalankan `sudo aws sts get-caller-identity` dari node hybrid Anda.
+ Konfirmasikan peran IAM Hybrid Nodes Anda memiliki izin yang diperlukan.
+ Konfirmasikan bahwa di klaster Anda, Anda memiliki entri akses EKS untuk peran IAM Hybrid Nodes Anda atau konfirmasikan bahwa Anda `aws-auth` ConfigMap memiliki entri untuk peran IAM Hybrid Nodes Anda. Jika Anda menggunakan entri akses EKS, konfirmasikan entri akses Anda untuk peran IAM Node Hybrid Anda memiliki jenis `HYBRID_LINUX` akses. Jika Anda menggunakan `aws-auth` ConfigMap, konfirmasikan entri Anda untuk peran IAM Hybrid Nodes memenuhi persyaratan dan pemformatan yang dirinci. [Mempersiapkan akses cluster untuk node hybrid](hybrid-nodes-cluster-prep.md)
### Node hibrida terdaftar dengan kluster EKS tetapi menunjukkan status `Not Ready`
Jika node hibrida Anda berhasil terdaftar dengan kluster EKS Anda, tetapi node hibrida menunjukkan status`Not Ready`, hal pertama yang harus diperiksa adalah status Container Networking Interface (CNI) Anda. Jika Anda belum menginstal CNI, maka diharapkan node hybrid Anda memiliki status`Not Ready`. Setelah CNI diinstal dan berjalan dengan sukses, node diperbarui ke status`Ready`. Jika Anda mencoba menginstal CNI tetapi tidak berhasil berjalan, lihat [Pemecahan masalah CNI node hibrida](#hybrid-nodes-troubleshooting-cni) di halaman ini.
**Permintaan Penandatanganan Sertifikat (CSRs) macet Tertunda**
Setelah menghubungkan node hybrid ke kluster EKS Anda, jika Anda melihat ada node hybrid yang CSRs tertunda, node hybrid Anda tidak memenuhi persyaratan untuk persetujuan otomatis. CSRs untuk node hybrid secara otomatis disetujui dan dikeluarkan jika node CSRs for hybrid dibuat oleh node dengan `eks.amazonaws.com/compute-type: hybrid` label, dan CSR memiliki Nama Alternatif Subjek berikut (SANs): setidaknya satu DNS SAN sama dengan nama node dan IP SANs milik jaringan node jarak jauh. CIDRs
**Profil hybrid sudah ada**
Jika Anda mengubah `nodeadm` konfigurasi dan mencoba mendaftarkan ulang node dengan konfigurasi baru, Anda mungkin melihat kesalahan yang menyatakan bahwa profil hibrida sudah ada tetapi isinya telah berubah. Alih-alih berjalan `nodeadm init` di antara perubahan konfigurasi, jalankan `nodeadm uninstall` diikuti oleh a `nodeadm install` dan`nodeadm init`. Ini memastikan pembersihan yang tepat dengan perubahan konfigurasi.
```
"msg":"Command failed","error":"hybrid profile already exists at /etc/aws/hybrid/config but its contents do not align with the expected configuration"
```
**Node hibrida gagal menyelesaikan API Pribadi**
Setelah berjalan`nodeadm init`, jika Anda melihat kesalahan pada `kubelet` log yang menunjukkan kegagalan untuk menghubungi server API EKS Kubernetes karena ada`no such host`, Anda mungkin harus mengubah entri DNS untuk titik akhir API EKS Kubernetes di jaringan lokal atau di tingkat host. *Lihat [Meneruskan kueri DNS masuk ke VPC Anda](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-forwarding-inbound-queries.html) di dokumentasi Route53. AWS *
```
Failed to contact API server when waiting for CSINode publishing: Get ... no such host
```
**Tidak dapat melihat node hybrid di konsol EKS**
Jika Anda telah mendaftarkan node hybrid tetapi tidak dapat melihatnya di konsol EKS, periksa izin utama IAM yang Anda gunakan untuk melihat konsol. Prinsipal IAM yang Anda gunakan harus memiliki izin IAM dan Kubernetes minimum tertentu untuk melihat sumber daya di konsol. Untuk informasi selengkapnya, lihat [Lihat sumber daya Kubernetes di Konsol Manajemen AWS](view-kubernetes-resources.md).
## Menjalankan pemecahan masalah node hybrid
Jika node hibrida Anda terdaftar dengan kluster EKS Anda`Ready`, memiliki status, dan kemudian beralih ke status`Not Ready`, ada berbagai masalah yang mungkin berkontribusi pada status tidak sehat seperti node yang kekurangan sumber daya yang cukup untuk CPU, memori, atau ruang disk yang tersedia, atau node terputus dari bidang kontrol EKS. Anda dapat menggunakan langkah-langkah di bawah ini untuk memecahkan masalah node Anda, dan jika Anda tidak dapat menyelesaikan masalah, hubungi Support AWS .
Jalankan `nodeadm debug` dari node hybrid Anda untuk memvalidasi jaringan dan persyaratan kredensi terpenuhi. Untuk informasi lebih lanjut tentang `nodeadm debug` perintah, lihat[`nodeadm`Referensi node hibrida](hybrid-nodes-nodeadm.md).
**Dapatkan status node**
```
kubectl get nodes -o wide
```
**Periksa kondisi dan peristiwa node**
```
kubectl describe node NODE_NAME
```
**Dapatkan status pod**
```
kubectl get pods -A -o wide
```
**Periksa kondisi dan acara pod**
```
kubectl describe pod POD_NAME
```
**Periksa log pod**
```
kubectl logs POD_NAME
```
**Periksa `kubectl` log**
```
systemctl status kubelet
```
```
journalctl -u kubelet -f
```
**Probe keaktifan pod gagal atau webhook tidak berfungsi**
Jika aplikasi, add-on, atau webhook yang berjalan pada node hybrid Anda tidak dimulai dengan benar, Anda mungkin memiliki masalah jaringan yang memblokir komunikasi ke pod. Agar control plane EKS dapat menghubungi webhook yang berjalan pada node hybrid, Anda harus mengonfigurasi klaster EKS Anda dengan jaringan pod jarak jauh dan memiliki rute untuk pod CIDR lokal di tabel perutean VPC dengan target sebagai Transit Gateway (TGW), virtual private gateway (VPW), atau gateway lain yang Anda gunakan untuk menghubungkan VPC dengan jaringan lokal Anda. Untuk informasi lebih lanjut tentang persyaratan jaringan untuk node hybrid, lihat[Mempersiapkan jaringan untuk node hybrid](hybrid-nodes-networking.md). Anda juga harus mengizinkan lalu lintas ini di firewall lokal Anda dan memastikan router Anda dapat merutekan dengan benar ke pod Anda. Lihat [Konfigurasikan webhook untuk node hybrid](hybrid-nodes-webhooks.md) untuk informasi selengkapnya tentang persyaratan untuk menjalankan webhook pada node hybrid.
Pesan log pod umum untuk skenario ini ditampilkan di bawah ini dimana ip-address adalah IP Cluster untuk layanan Kubernetes.
```
dial tcp :443: connect: no route to host
```
**`kubectl logs`atau `kubectl exec` perintah tidak berfungsi (perintah `kubelet` API)**
Jika`kubectl attach`,`kubectl cp`,`kubectl exec`,`kubectl logs`, dan `kubectl port-forward` perintah habis sementara `kubectl` perintah lain berhasil, masalahnya kemungkinan terkait dengan konfigurasi jaringan jarak jauh. Perintah-perintah ini terhubung melalui cluster ke `kubelet` titik akhir pada node. Untuk mengetahui informasi selengkapnya, lihat [Titik akhir `kubelet`](hybrid-nodes-concepts-kubernetes.md#hybrid-nodes-concepts-k8s-kubelet-api).
Verifikasi bahwa node IPs dan pod Anda IPs termasuk dalam jaringan node jarak jauh dan jaringan pod jarak jauh yang CIDRs dikonfigurasi untuk klaster Anda. Gunakan perintah di bawah ini untuk memeriksa tugas IP.
```
kubectl get nodes -o wide
```
```
kubectl get pods -A -o wide
```
Bandingkan ini IPs dengan jaringan jarak jauh yang dikonfigurasi CIDRs untuk memastikan perutean yang tepat. Untuk persyaratan konfigurasi jaringan, lihat[Mempersiapkan jaringan untuk node hybrid](hybrid-nodes-networking.md).
## Pemecahan masalah CNI node hibrida
Jika Anda mengalami masalah dengan awalnya memulai Cilium atau Calico dengan node hibrida, ini paling sering disebabkan oleh masalah jaringan antara node hibrida atau pod CNI yang berjalan pada node hibrida, dan bidang kontrol EKS. Pastikan lingkungan Anda memenuhi persyaratan dalam Mempersiapkan jaringan untuk node hybrid. Ini berguna untuk memecah masalah menjadi beberapa bagian.
Konfigurasi kluster EKS
Apakah konfigurasi RemoteNodeNetwork dan RemotePodNetwork konfigurasi benar?
Konfigurasi VPC
Apakah ada rute untuk RemoteNodeNetwork dan RemotePodNetwork di tabel perutean VPC dengan target Transit Gateway atau Virtual Private Gateway?
Konfigurasi grup keamanan
Apakah ada aturan masuk dan keluar untuk dan? RemoteNodeNetwork RemotePodNetwork
Jaringan lokal
Apakah ada rute dan akses ke dan dari bidang kontrol EKS dan ke dan dari node hibrida dan pod yang berjalan pada node hybrid?
Konfigurasi CNI
Jika menggunakan jaringan overlay, apakah konfigurasi kumpulan IP untuk CNI cocok dengan yang RemotePodNetwork dikonfigurasi untuk kluster EKS jika menggunakan webhook?
**Hybrid node memiliki status `Ready` tanpa CNI diinstal**
Jika node hybrid Anda menunjukkan status`Ready`, tetapi Anda belum menginstal CNI di cluster Anda, ada kemungkinan bahwa ada artefak CNI lama pada node hybrid Anda. Secara default, ketika Anda menghapus Cilium dan Calico dengan alat seperti Helm, sumber daya pada disk tidak dihapus dari mesin fisik atau virtual Anda. Selain itu, Definisi Sumber Daya Kustom (CRDs) untuk ini CNIs mungkin masih ada di cluster Anda dari instalasi lama. Untuk informasi selengkapnya, lihat bagian Hapus Cilium dan Hapus Calico dari. [Konfigurasikan CNI untuk node hybrid](hybrid-nodes-cni.md)
**Pemecahan masalah Cilium**
Jika Anda mengalami masalah saat menjalankan Cilium pada node hybrid, lihat [langkah pemecahan masalah](https://docs.cilium.io/en/stable/operations/troubleshooting/) dalam dokumentasi Cilium. Bagian di bawah ini mencakup masalah yang mungkin unik untuk menerapkan Cilium pada node hibrida.
**Cilium tidak dimulai**
Jika agen Cilium yang berjalan pada setiap node hibrida tidak dimulai, periksa log pod agen Cilium untuk mengetahui kesalahan. Agen Cilium memerlukan konektivitas ke titik akhir API EKS Kubernetes untuk memulai. Startup agen cilium akan gagal jika konektivitas ini tidak dikonfigurasi dengan benar. Dalam hal ini, Anda akan melihat pesan log yang mirip dengan yang berikut ini di log pod agen Cilium.
```
msg="Unable to contact k8s api-server"
level=fatal msg="failed to start: Get \"https://:443/api/v1/namespaces/kube-system\": dial tcp :443: i/o timeout"
```
Agen Cilium berjalan di jaringan host. Kluster EKS Anda harus dikonfigurasi `RemoteNodeNetwork` untuk konektivitas Cilium. Konfirmasikan bahwa Anda memiliki grup keamanan tambahan untuk kluster EKS Anda dengan aturan masuk untuk Anda`RemoteNodeNetwork`, bahwa Anda memiliki rute di VPC untuk `RemoteNodeNetwork` Anda, dan bahwa jaringan lokal Anda dikonfigurasi dengan benar untuk memungkinkan konektivitas ke bidang kontrol EKS.
Jika operator Cilium sedang berjalan dan beberapa agen Cilium Anda berjalan tetapi tidak semuanya, konfirmasikan bahwa Anda memiliki pod yang tersedia IPs untuk dialokasikan untuk semua node di klaster Anda. Anda mengonfigurasi ukuran Pod yang dapat dialokasikan CIDRs saat menggunakan kumpulan klaster IPAM dengan `clusterPoolIPv4PodCIDRList` konfigurasi Cilium Anda. Ukuran CIDR per-node dikonfigurasi dengan `clusterPoolIPv4MaskSize` pengaturan dalam konfigurasi Cilium Anda. Lihat [Memperluas kumpulan cluster](https://docs.cilium.io/en/stable/network/concepts/ipam/cluster-pool/#expanding-the-cluster-pool) di dokumentasi Cilium untuk informasi selengkapnya.
**Cilium BGP tidak berfungsi**
Jika Anda menggunakan Cilium BGP Control Plane untuk mengiklankan pod atau alamat layanan Anda ke jaringan lokal, Anda dapat menggunakan perintah Cilium CLI berikut untuk memeriksa apakah BGP mengiklankan rute ke sumber daya Anda. Untuk langkah-langkah menginstal CLI Cilium, lihat Menginstal CLI Cilium [di dokumentasi Cilium](https://docs.cilium.io/en/stable/gettingstarted/k8s-install-default/#install-the-cilium-cli).
Jika BGP bekerja dengan benar, Anda harus node hybrid Anda dengan Session State `established` di output. Anda mungkin perlu bekerja dengan tim jaringan Anda untuk mengidentifikasi nilai yang benar untuk Local AS, Peer AS, dan Peer Address lingkungan Anda.
```
cilium bgp peers
```
```
cilium bgp routes
```
Jika Anda menggunakan Cilium BGP untuk mengiklankan Layanan dengan tipe`LoadBalancer`, Anda harus memiliki label yang sama pada Layanan Anda `CiliumLoadBalancerIPPool` dan Layanan, yang harus digunakan dalam pemilih Anda. IPs `CiliumBGPAdvertisement` Contoh ditunjukkan di bawah ini. Catatan, jika Anda menggunakan Cilium BGP untuk mengiklankan Layanan dengan tipe LoadBalancer, rute BGP mungkin terganggu selama agen Cilium memulai kembali. IPs Untuk informasi selengkapnya, lihat [Skenario Kegagalan](https://docs.cilium.io/en/latest/network/bgp-control-plane/bgp-control-plane-operation/#failure-scenarios) dalam dokumentasi Cilium.
**Layanan**
```
kind: Service
apiVersion: v1
metadata:
name: guestbook
labels:
app: guestbook
spec:
ports:
- port: 3000
targetPort: http-server
selector:
app: guestbook
type: LoadBalancer
```
**CiliumLoadBalancerIPPool**
```
apiVersion: cilium.io/v2alpha1
kind: CiliumLoadBalancerIPPool
metadata:
name: guestbook-pool
labels:
app: guestbook
spec:
blocks:
- cidr:
serviceSelector:
matchExpressions:
- { key: app, operator: In, values: [ guestbook ] }
```
**silia BGPAdvertisement**
```
apiVersion: cilium.io/v2alpha1
kind: CiliumBGPAdvertisement
metadata:
name: bgp-advertisements-guestbook
labels:
advertise: bgp
spec:
advertisements:
- advertisementType: "Service"
service:
addresses:
- ExternalIP
- LoadBalancerIP
selector:
matchExpressions:
- { key: app, operator: In, values: [ guestbook ] }
```
**Pemecahan masalah Calico**
Jika Anda mengalami masalah saat menjalankan Calico pada node hybrid, lihat [langkah pemecahan masalah](https://docs.tigera.io/calico/latest/operations/troubleshoot/) dalam dokumentasi Calico. Bagian di bawah ini mencakup masalah yang mungkin unik untuk menerapkan Calico pada node hybrid.
Tabel di bawah ini merangkum komponen Calico dan apakah mereka berjalan pada node atau jaringan pod secara default. Jika Anda mengonfigurasi Calico untuk menggunakan NAT untuk lalu lintas pod keluar, jaringan lokal Anda harus dikonfigurasi untuk merutekan lalu lintas ke CIDR node lokal dan tabel perutean VPC Anda harus dikonfigurasi dengan rute untuk CIDR node lokal dengan gateway transit (TGW) atau virtual private gateway (VGW) sebagai target. Jika Anda tidak mengonfigurasi Calico untuk menggunakan NAT untuk lalu lintas pod keluar, jaringan lokal Anda harus dikonfigurasi untuk merutekan lalu lintas ke CIDR pod lokal dan tabel perutean VPC Anda harus dikonfigurasi dengan rute untuk CIDR pod lokal dengan gateway transit (TGW) atau virtual private gateway (VGW) sebagai target.
| Komponen | Jaringan |
| --- | --- |
| Server API Calico | Simpul |
| Pengontrol Calico untuk Kubernetes | Pod |
| Agen simpul Calico | Simpul |
| Calico `typha` | Simpul |
| Driver simpul Calico CSI | Pod |
| Operator Calico | Simpul |
**Sumber daya Calico dijadwalkan atau berjalan pada node yang ditutup**
Sumber daya Calico yang tidak berjalan sebagai a DaemonSet memiliki toleransi fleksibel secara default yang memungkinkannya dijadwalkan pada node yang dikepung yang tidak siap untuk penjadwalan atau menjalankan pod. Anda dapat memperketat toleransi untuk sumber daya DaemonSet non-Calico dengan mengubah instalasi operator Anda untuk menyertakan yang berikut ini.
```
installation:
...
controlPlaneTolerations:
- effect: NoExecute
key: node.kubernetes.io/unreachable
operator: Exists
tolerationSeconds: 300
- effect: NoExecute
key: node.kubernetes.io/not-ready
operator: Exists
tolerationSeconds: 300
calicoKubeControllersDeployment:
spec:
template:
spec:
tolerations:
- effect: NoExecute
key: node.kubernetes.io/unreachable
operator: Exists
tolerationSeconds: 300
- effect: NoExecute
key: node.kubernetes.io/not-ready
operator: Exists
tolerationSeconds: 300
typhaDeployment:
spec:
template:
spec:
tolerations:
- effect: NoExecute
key: node.kubernetes.io/unreachable
operator: Exists
tolerationSeconds: 300
- effect: NoExecute
key: node.kubernetes.io/not-ready
operator: Exists
tolerationSeconds: 300
```
## Pemecahan masalah kredensil
Untuk aktivasi hybrid AWS SSM dan Peran AWS IAM Anywhere, Anda dapat memvalidasi bahwa kredensil untuk peran IAM Hybrid Nodes dikonfigurasi dengan benar pada node hybrid Anda dengan menjalankan perintah berikut dari node hybrid Anda. Konfirmasikan nama node dan nama Peran IAM Node Hybrid adalah apa yang Anda harapkan.
```
sudo aws sts get-caller-identity
```
```
{
"UserId": "ABCDEFGHIJKLM12345678910:",
"Account": "",
"Arn": "arn:aws: sts:::assumed-role/"
}
```
** AWS Pemecahan masalah Systems Manager (SSM)**
Jika Anda menggunakan aktivasi hibrida AWS SSM untuk kredensil node hybrid Anda, perhatikan direktori dan artefak SSM berikut yang diinstal pada node hybrid Anda oleh. `nodeadm` Untuk informasi selengkapnya tentang agen SSM, lihat [Bekerja dengan agen SSM](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent.html) di *Panduan Pengguna AWS Systems Manager*.
| Deskripsi | Lokasi |
| --- | --- |
| Agen SSM | Ubuntu - `/snap/amazon-ssm-agent/current/amazon-ssm-agent` RHEL & AL2 023 - `/usr/bin/amazon-ssm-agent` |
| Log SSM Agent | `/var/log/amazon/ssm` |
| AWS kredensialnya | `/root/.aws/credentials` |
| CLI Pengaturan SSM | `/opt/ssm/ssm-setup-cli` |
**Memulai ulang agen SSM**
Beberapa masalah dapat diselesaikan dengan memulai kembali agen SSM. Anda dapat menggunakan perintah di bawah ini untuk memulai ulang.
**AL2023 dan sistem operasi lainnya**
```
systemctl restart amazon-ssm-agent
```
**Ubuntu**
```
systemctl restart snap.amazon-ssm-agent.amazon-ssm-agent
```
**Periksa konektivitas ke titik akhir SSM**
Konfirmasikan bahwa Anda dapat terhubung ke titik akhir SSM dari node hybrid Anda. Untuk daftar titik akhir SSM, lihat titik akhir dan kuota [AWS Systems Manager](https://docs.aws.amazon.com/general/latest/gr/ssm.html). Ganti perintah `us-west-2` di bawah ini dengan AWS Region untuk aktivasi hybrid AWS SSM Anda.
```
ping ssm.us-west-2.amazonaws.com
```
**Lihat status koneksi instans SSM terdaftar**
Anda dapat memeriksa status koneksi dari instance yang terdaftar dengan aktivasi hibrida SSM dengan perintah CLI AWS berikut. Ganti ID mesin dengan ID mesin instance Anda.
```
aws ssm get-connection-status --target mi-012345678abcdefgh
```
**Ketidakcocokan checksum CLI Pengaturan SSM**
Saat menjalankan `nodeadm install` jika Anda melihat masalah dengan ketidakcocokan `ssm-setup-cli` checksum, Anda harus mengonfirmasi bahwa tidak ada instalasi SSM yang lebih lama di host Anda. Jika ada instalasi SSM yang lebih lama di host Anda, hapus dan jalankan kembali `nodeadm install` untuk menyelesaikan masalah.
```
Failed to perform agent-installation/on-prem registration: error while verifying installed ssm-setup-cli checksum: checksum mismatch with latest ssm-setup-cli.
```
**SSM `InvalidActivation`**
Jika Anda melihat kesalahan saat mendaftarkan instans Anda dengan AWS SSM, konfirmasikan `region``activationCode`, dan `activationId` di dalamnya benar. `nodeConfig.yaml` AWS Wilayah untuk kluster EKS Anda harus sesuai dengan wilayah aktivasi hibrida SSM Anda. Jika nilai-nilai ini salah dikonfigurasi, Anda mungkin melihat kesalahan yang mirip dengan berikut ini.
```
ERROR Registration failed due to error registering the instance with AWS SSM. InvalidActivation
```
**SSM`ExpiredTokenException`: Token keamanan yang termasuk dalam permintaan sudah kedaluwarsa**
Jika agen SSM tidak dapat menyegarkan kredensil, Anda mungkin melihat file. `ExpiredTokenException` Dalam skenario ini, jika Anda dapat terhubung ke titik akhir SSM dari node hybrid Anda, Anda mungkin perlu me-restart agen SSM untuk memaksa penyegaran kredenal.
```
"msg":"Command failed","error":"operation error SSM: DescribeInstanceInformation, https response error StatusCode: 400, RequestID: eee03a9e-f7cc-470a-9647-73d47e4cf0be, api error ExpiredTokenException: The security token included in the request is expired"
```
**Kesalahan SSM dalam menjalankan perintah mesin register**
Jika Anda melihat kesalahan saat mendaftarkan mesin dengan SSM, Anda mungkin perlu menjalankan ulang `nodeadm install` untuk memastikan semua dependensi SSM diinstal dengan benar.
```
"error":"running register machine command: , error: fork/exec /opt/aws/ssm-setup-cli: no such file or directory"
```
**SSM `ActivationExpired`**
Saat menjalankan`nodeadm init`, jika Anda melihat kesalahan saat mendaftarkan instans dengan SSM karena aktivasi yang kedaluwarsa, Anda perlu membuat aktivasi hibrida SSM baru, memperbarui `nodeConfig.yaml` dengan `activationCode` dan `activationId` aktivasi hibrida SSM baru Anda, dan menjalankan kembali. `nodeadm init`
```
"msg":"Command failed","error":"SSM activation expired. Please use a valid activation"
```
```
ERROR Registration failed due to error registering the instance with AWS SSM. ActivationExpired
```
**SSM gagal menyegarkan kredensil yang di-cache**
Jika Anda melihat kegagalan untuk me-refresh kredenal cache, `/root/.aws/credentials` file tersebut mungkin telah dihapus di host Anda. Pertama periksa aktivasi hibrida SSM Anda dan pastikan aktif dan node hibrida Anda dikonfigurasi dengan benar untuk menggunakan aktivasi. Periksa log agen SSM di `/var/log/amazon/ssm` dan jalankan kembali `nodeadm init` perintah setelah Anda menyelesaikan masalah di sisi SSM.
```
"Command failed","error":"operation error SSM: DescribeInstanceInformation, get identity: get credentials: failed to refresh cached credentials"
```
**Bersihkan SSM**
Untuk menghapus agen SSM dari host Anda, Anda dapat menjalankan perintah berikut.
```
dnf remove -y amazon-ssm-agent
sudo apt remove --purge amazon-ssm-agent
snap remove amazon-ssm-agent
rm -rf /var/lib/amazon/ssm/Vault/Store/RegistrationKey
```
** AWS Peran IAM Di Mana Saja Pemecahan masalah**
Jika Anda menggunakan AWS IAM Roles Anywhere untuk kredenal node hybrid Anda, perhatikan direktori dan artefak berikut yang diinstal pada node hybrid Anda oleh. `nodeadm` *Untuk informasi selengkapnya tentang pemecahan masalah Peran IAM Di Mana Saja, lihat [Memecahkan Masalah identitas dan akses Peran AWS IAM Di Mana Saja di mana saja di Panduan Pengguna IAM Roles AWS Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/security_iam_troubleshoot.html).*
| Deskripsi | Lokasi |
| --- | --- |
| Peran IAM Di Mana Saja CLI | `/usr/local/bin/aws_signing_helper` |
| Lokasi dan nama sertifikat default | `/etc/iam/pki/server.pem` |
| Lokasi dan nama kunci default | `/etc/iam/pki/server.key` |
**Peran IAM Di Mana Saja gagal menyegarkan kredensil yang di-cache**
Jika Anda melihat kegagalan untuk me-refresh kredenal cache, tinjau konten `/etc/aws/hybrid/config` dan konfirmasikan bahwa IAM Roles Anywhere telah dikonfigurasi dengan benar dalam konfigurasi Anda. `nodeadm` Konfirmasikan bahwa `/etc/iam/pki` ada. Setiap node harus memiliki sertifikat dan kunci yang unik. Secara default, saat menggunakan IAM Roles Anywhere sebagai penyedia kredensi, `nodeadm` gunakan `/etc/iam/pki/server.pem` untuk lokasi dan nama sertifikat, dan `/etc/iam/pki/server.key` untuk kunci pribadi. Anda mungkin perlu membuat direktori sebelum menempatkan sertifikat dan kunci di direktori dengan. `sudo mkdir -p /etc/iam/pki` Anda dapat memverifikasi konten sertifikat Anda dengan perintah di bawah ini.
```
openssl x509 -text -noout -in server.pem
```
```
open /etc/iam/pki/server.pem: no such file or directory
could not parse PEM data
Command failed {"error": "... get identity: get credentials: failed to refresh cached credentials, process provider error: error in credential_process: exit status 1"}
```
**Peran IAM Di Mana Saja tidak diizinkan untuk melakukan `sts:AssumeRole`**
Di `kubelet` log, jika Anda melihat masalah akses ditolak untuk `sts:AssumeRole` operasi saat menggunakan Peran IAM Di Mana Saja, periksa kebijakan kepercayaan peran IAM Node Hybrid Anda untuk mengonfirmasi bahwa prinsip layanan IAM Roles Anywhere diizinkan untuk mengasumsikan Peran IAM Node Hybrid. Selain itu, konfirmasikan bahwa ARN jangkar kepercayaan dikonfigurasi dengan benar dalam kebijakan kepercayaan peran IAM Hybrid Nodes Anda dan bahwa peran IAM Hybrid Nodes Anda ditambahkan ke profil IAM Roles Anywhere Anda.
```
could not get token: AccessDenied: User: ... is not authorized to perform: sts:AssumeRole on resource: ...
```
**Peran IAM Di Mana Saja tidak diizinkan untuk disetel `roleSessionName`**
Di `kubelet` log, jika Anda melihat masalah akses ditolak untuk menyetel`roleSessionName`, konfirmasikan bahwa Anda telah menyetel `acceptRoleSessionName` ke true untuk profil IAM Roles Anywhere Anda.
```
AccessDeniedException: Not authorized to set roleSessionName
```
## Pemecahan masalah sistem operasi
### RHEL
**Kegagalan pendaftaran pengelola hak atau langganan**
Jika Anda menjalankan `nodeadm install` dan mengalami kegagalan untuk menginstal dependensi node hibrida karena masalah pendaftaran hak, pastikan Anda telah mengatur nama pengguna dan kata sandi Red Hat dengan benar di host Anda.
```
This system is not registered with an entitlement server
```
### Ubuntu
**GLIBC tidak ditemukan**
Jika Anda menggunakan Ubuntu untuk sistem operasi Anda dan IAM Roles Anywhere untuk penyedia kredensi Anda dengan node hybrid dan melihat masalah dengan GLIBC tidak ditemukan, Anda dapat menginstal ketergantungan itu secara manual untuk menyelesaikan masalah.
```
GLIBC_2.32 not found (required by /usr/local/bin/aws_signing_helper)
```
Jalankan perintah berikut untuk menginstal dependensi:
```
ldd --version
sudo apt update && apt install libc6
sudo apt install glibc-source
```
### Bottlerocket
Jika Anda mengaktifkan penampung admin Bottlerocket, Anda dapat mengaksesnya dengan SSH untuk debugging lanjutan dan pemecahan masalah dengan hak istimewa yang lebih tinggi. Bagian berikut berisi perintah yang perlu dijalankan pada konteks host Bottlerocket. Setelah Anda berada di wadah admin, Anda dapat menjalankan `sheltie` untuk mendapatkan shell root penuh di host Bottlerocket.
```
sheltie
```
Anda juga dapat menjalankan perintah di bagian berikut dari shell kontainer admin dengan awalan setiap perintah dengan`sudo chroot /.bottlerocket/rootfs`.
```
sudo chroot /.bottlerocket/rootfs
```
**Menggunakan logdog untuk pengumpulan log**
Bottlerocket menyediakan `logdog` utilitas untuk mengumpulkan log dan informasi sistem secara efisien untuk tujuan pemecahan masalah.
```
logdog
```
`logdog`Utilitas mengumpulkan log dari berbagai lokasi pada host Bottlerocket dan menggabungkannya menjadi tarball. Secara default, tarball akan dibuat di`/var/log/support/bottlerocket-logs.tar.gz`, dan dapat diakses dari wadah host di`/.bottlerocket/support/bottlerocket-logs.tar.gz`.
**Mengakses log sistem dengan journalctl**
Anda dapat memeriksa status berbagai layanan sistem seperti`kubelet`,`containerd`, dll dan melihat log mereka dengan perintah berikut. `-f`Bendera akan mengikuti log secara real time.
Untuk memeriksa status `kubelet` layanan dan mengambil `kubelet` log, Anda dapat menjalankan:
```
systemctl status kubelet
journalctl -u kubelet -f
```
Untuk memeriksa status `containerd` layanan dan mengambil log untuk `containerd` instance yang diatur, Anda dapat menjalankan:
```
systemctl status containerd
journalctl -u containerd -f
```
Untuk memeriksa status `host-containerd` layanan dan mengambil log untuk `containerd` instance host, Anda dapat menjalankan:
```
systemctl status host-containerd
journalctl -u host-containerd -f
```
Untuk mengambil log untuk wadah bootstrap dan wadah host, Anda dapat menjalankan:
```
journalctl _COMM=host-ctr -f
```