

 **Bantu meningkatkan 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 GitHub ** tautan ** Edit halaman ini di 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 hibrida
<a name="hybrid-nodes-troubleshooting"></a>

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 cluster 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 Dukungan.

**Diperlukan versi nodeadm untuk penyedia kredenSIAL SSM**  
Jika Anda menggunakan AWS System Manager (SSM) sebagai penyedia kredensia untuk node hibrida, Anda harus menggunakan `nodeadm` versi `1.0.19` atau yang lebih baru untuk instalasi dan peningkatan baru. Versi sebelumnya `nodeadm` berisi kunci penandatanganan SSM yang sudah ketinggalan zaman dan gagal selama `nodeadm install` dan `nodeadm upgrade` dengan kesalahan verifikasi tanda tangan berikut:  

```
"msg":"Command failed","error":"failed to install ssm installer: validating ssm-setup-cli signature: Signature Verification Error: No matching signature"
```
Untuk mengatasi kesalahan ini, [ unduh versi ](hybrid-nodes-nodeadm.md#hybrid-nodes-nodeadm-download) terbaru `nodeadm` sebelum menjalankan `nodeadm install` atau`nodeadm upgrade`.

 **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[Referensi `nodead` m node hibrida](hybrid-nodes-nodeadm.md).

 **Mendeteksi masalah dengan node hibrida Anda dengan wawasan cluster Wawasan klaster ** Amazon EKS mencakup pemeriksaan * wawasan * yang mendeteksi masalah umum dengan konfigurasi Node Hibrid EKS di cluster Anda. Anda dapat melihat hasil dari semua pemeriksaan wawasan dari Konsol Manajemen AWS, AWS CLI, dan AWS SDK. Untuk informasi selengkapnya tentang wawasan cluster, lihat[Mempersiapkan peningkatan versi Kubernetes dan memecahkan masalah kesalahan konfigurasi dengan wawasan klaster](cluster-insights.md).

## Memasang pemecahan masalah node hibrida
<a name="hybrid-nodes-troubleshooting-install"></a>

Topik pemecahan masalah berikut terkait dengan menginstal dependensi node hybrid pada host dengan `nodeadm install` perintah.

 **`nodeadm`perintah gagal `must run as root` ** 

Per `nodeadm install` intah 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 ** 

Per `nodeadm install` intah menginstal dependensi yang diperlukan untuk node hybrid. Dependensi node hibrida termasuk`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 berikut ini di `nodeadm install` output.

```
"msg":"Command failed","error":"failed reading file from url: ...: max retries achieved for http request"
```

 **Gagal memperbarui manajer paket ** 

Per `nodeadm install` intah 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 memperbaiki, Anda dapat menjalankan `apt update` atau `yum update` atau `dnf update` sebelum menjalankan `nodeadm install` atau Anda dapat mencoba menjalankan kembali`nodeadm install`.

```
failed to run update using package manager
```

 **Batas waktu 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 pemasangan dependensi node hibrida sebelum batas waktu terpenuhi. Untuk mengatasi masalah ini, Anda dapat mencoba menggunakan `--timeout` flag in `nodeadm` untuk memperpanjang durasi batas waktu untuk mengunduh dependensi.

```
nodeadm install K8S_VERSION --credential-provider CREDS_PROVIDER --timeout {{20m0s}}
```

## Menghubungkan pemecahan masalah node hibrida
<a name="hybrid-nodes-troubleshooting-connect"></a>

Topik pemecahan masalah di bagian ini terkait dengan proses menghubungkan node hybrid ke cluster EKS dengan `nodeadm init` perintah.

 **Kesalahan operasi atau skema yang tidak didukung ** 

Saat menjalankan`nodeadm init`, jika Anda melihat kesalahan yang terkait dengan `operation error` atau`unsupported scheme`, periksa `nodeConfig.yaml` untuk memastikannya diformat dengan benar dan diteruskan ke`nodeadm`. Untuk informasi selengkapnya tentang format dan opsi untuk`nodeConfig.yaml`, lihat[Referensi `nodead` m node hibrida](hybrid-nodes-nodeadm.md).

```
"msg":"Command failed","error":"operation error ec2imds: GetRegion, request canceled, context deadline exceeded"
```

 **Peran Hybrid Nodes IAM kehilangan izin untuk tindakan `eks:DescribeCluster` ** 

Saat menjalankan`nodeadm init`, `nodeadm` cobalah untuk mengumpulkan informasi tentang cluster EKS Anda dengan memanggil `DescribeCluster` tindakan EKS. Jika peran IAM Node Hibrid Anda tidak memiliki izin untuk `eks:DescribeCluster` tindakan tersebut, maka Anda harus meneruskan titik akhir API Kubernetes, bundel CA cluster, dan layanan IPv4 CIDR dalam konfigurasi node yang Anda lewati saat menjalankan. `nodeadm` `nodeadm init` Untuk informasi selengkapnya tentang izin yang diperlukan untuk peran IAM Node Hibrid, lihat[Siapkan kredenSIAL untuk node hibrida](hybrid-nodes-creds.md).

```
"msg":"Command failed","error":"operation error EKS: DescribeCluster, https response error StatusCode: 403 ... AccessDeniedException"
```

 **Peran Hybrid Nodes IAM kehilangan izin untuk tindakan `eks:ListAccessEntries` ** 

Saat menjalankan`nodeadm init`, mencoba `nodeadm` untuk memvalidasi apakah cluster EKS Anda memiliki entri akses tipe yang `HYBRID_LINUX` terkait dengan peran IAM Node Hibrid dengan memanggil `ListAccessEntries` tindakan EKS. Jika peran IAM Node Hibrid Anda tidak memiliki izin untuk `eks:ListAccessEntries` tindakan tersebut, maka Anda harus mener `--skip cluster-access-validation` uskan tanda saat menjalankan `nodeadm init` perintah. Untuk informasi selengkapnya tentang izin yang diperlukan untuk peran IAM Node Hibrid, lihat[Siapkan kredenSIAL untuk node hibrida](hybrid-nodes-creds.md).

```
"msg":"Command failed","error":"operation error EKS: ListAccessEntries, https response error StatusCode: 403 ... AccessDeniedException"
```

 **Node IP tidak di jaringan node jarak jauh CIDR ** 

Saat menjalankan`nodeadm init`, Anda mungkin mengalami kesalahan jika alamat IP node tidak berada dalam CIDR jaringan node jarak jauh yang ditentukan. 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 CIDRs 10.0.0. 0/16 dan 192.168.0. 0/16. Kesalahan terjadi karena 10.18.0.1 tidak berada dalam salah satu rentang.

Konfirmasikan bahwa Anda telah mengkonfigurasi 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 cluster 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 cluster dan wilayah yang `nodeConfig.yaml` cocok dengan cluster yang Anda inginkan.

```
aws eks describe-cluster --name {{CLUSTER_NAME}} --region REGION_NAME --query cluster.remoteNetworkConfig.remoteNodeNetworks
```
+ Pastikan Anda bekerja dengan node yang dimaksud:
  + Konfirmasikan Anda berada di node yang benar dengan memeriksa nama host dan alamat IP-nya cocok dengan yang ingin Anda daftarkan dengan cluster.
  + Konfirmasikan node ini berada di jaringan lokal yang benar (yang rentang 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 IP dalam CIDR jaringan node jarak jauh Anda.
+ Jika node Anda memiliki beberapa antarmuka jaringan, `kubelet` mungkin pilih antarmuka dengan alamat IP di luar CIDR jaringan node jarak jauh Anda sebagai default. Untuk menggunakan antarmuka yang berbeda, tentukan alamat IP-nya menggunakan `--node-ip` `kubelet` bendera di Anda`nodeConfig.yaml`. Untuk informasi selengkapnya, lihat [Referensi `nodead` m 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 cluster EKS ** 

Jika Anda menjalankan `nodeadm init` dan selesai tetapi node hibrida Anda tidak muncul di cluster Anda, mungkin ada masalah dengan koneksi jaringan antara node hybrid dan bidang kontrol EKS, Anda mungkin tidak memiliki izin grup keamanan yang diperlukan dikonfigurasi, atau Anda mungkin tidak memiliki pemetaan yang diperlukan dari peran IAM Node Hibrid ke Kontrol Role-Based Akses Kubernetes (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 <ip address>: i/o timeout
```

Jika Anda melihat pesan ini, periksa hal berikut untuk memastikannya memenuhi persyaratan node hibrida yang dirinci di[Mempersiapkan jaringan untuk node hybrid](hybrid-nodes-networking.md).
+ Konfirmasikan bahwa VPC yang diteruskan ke klaster EKS memiliki rute ke Transit Gateway (TGW) atau Virtual Private Gateway (VGW) untuk node lokal dan CIDR pod secara opsional.
+ Konfirmasikan bahwa Anda memiliki grup keamanan tambahan untuk cluster EKS Anda memiliki aturan masuk untuk CIDR node lokal Anda dan CIDR pod opsional.
+ Konfirmasikan router lokal Anda dikonfigurasi untuk mengizinkan lalu lintas ke dan dari bidang kontrol EKS.

 **Tidak sah ** 

Jika node hybrid 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` kesalahan. 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 ini, periksa hal berikut untuk memastikannya memenuhi detail persyaratan node hibrida di [Siapkan kredenSIAL untuk node hibrida](hybrid-nodes-creds.md) dan[Mempersiapkan akses cluster untuk node hybrid](hybrid-nodes-cluster-prep.md).
+ Konfirmasikan identitas node hibrida cocok dengan peran IAM Node Hibrid yang diharapkan. Ini dapat dilakukan dengan menjalankan `sudo aws sts get-caller-identity` dari node hybrid Anda.
+ Konfirmasikan peran IAM Node Hibrid Anda memiliki izin yang diperlukan.
+ Konfirmasikan bahwa di cluster Anda, Anda memiliki entri akses EKS untuk peran IAM Node Hibrid Anda atau konfirmasikan bahwa Anda `aws-auth` ConfigMap memiliki entri untuk peran IAM Node Hibrid Anda. Jika Anda menggunakan entri akses EKS, konfirmasikan entri akses Anda untuk peran IAM Node Hibrid Anda memiliki jenis `HYBRID_LINUX` akses. Jika Anda menggunakan `aws-auth` ConfigMap, konfirmasikan entri Anda untuk peran Hybrid Nodes IAM memenuhi persyaratan dan pemformatan yang dirinci di[Mempersiapkan akses cluster untuk node hybrid](hybrid-nodes-cluster-prep.md).

### Node hibrida terdaftar dengan cluster EKS tetapi menunjukkan status `Tidak Siap`
<a name="hybrid-nodes-troubleshooting-not-ready"></a>

Jika node hybrid Anda berhasil terdaftar dengan cluster EKS Anda, tetapi node hybrid 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 (CSR) macet Tertunda ** 

Setelah menghubungkan node hybrid ke cluster EKS Anda, jika Anda melihat bahwa ada CSR yang tertunda untuk node hibrida Anda, node hibrida Anda tidak memenuhi persyaratan untuk persetujuan otomatis. CSR untuk node hibrida secara otomatis disetujui dan dikeluarkan jika CSR untuk node hibrida dibuat oleh node dengan `eks.amazonaws.com/compute-type: hybrid` label, dan CSR memiliki Subjek Alternative Names (SAN) berikut: setidaknya satu DNS SAN sama dengan nama node dan SAN IP milik CIDR jaringan node jarak jauh.

 **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 menjalankan`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 EKS Kubernetes API di jaringan lokal Anda atau di tingkat host. Lihat M [ eneruskan kueri DNS masuk ke VPC Anda ](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-forwarding-inbound-queries.html) di dokumentasi * AWS Route53. *

```
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 Anda tetapi tidak dapat melihatnya di konsol EKS, periksa izin prinsipal IAM yang Anda gunakan untuk melihat konsol. Prinsip 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 hibrida
<a name="_running_hybrid_nodes_troubleshooting"></a>

Jika node hybrid Anda terdaftar dengan cluster EKS Anda, memiliki status`Ready`, dan kemudian beralih ke status`Not Ready`, ada berbagai masalah yang mungkin berkontribusi pada status tidak sehat seperti simpul 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 AWS Dukungan.

Jalan `nodeadm debug` kan dari node hybrid Anda untuk memvalidasi jaringan dan persyaratan kredensi terpenuhi. Untuk informasi lebih lanjut tentang `nodeadm debug` perintah, lihat[Referensi `nodead` m node hibrida](hybrid-nodes-nodeadm.md).

 **Dapatkan status simpul ** 

```
kubectl get nodes -o wide
```

 **Periksa kondisi simpul dan peristiwa ** 

```
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 `kubelet` log ** 

```
systemctl status kubelet
```

```
journalctl -u kubelet -f
```

 **Probe keaktifan pod gagal atau webhook tidak berfungsi ** 

Jika aplikasi, add-on, atau webhook yang berjalan di node hybrid Anda tidak dimulai dengan benar, Anda mungkin memiliki masalah jaringan yang memblokir komunikasi ke pod. Agar bidang kontrol EKS dapat menghubungi webhook yang berjalan pada node hybrid, Anda harus mengonfigurasi cluster EKS Anda dengan jaringan pod jarak jauh dan memiliki rute untuk CIDR pod lokal Anda di tabel routing VPC Anda dengan target sebagai Transit Gateway (TGW), gateway pribadi virtual (VGW), atau gateway lain yang Anda gunakan untuk menghubungkan VPC dengan jaringan lokal Anda. Untuk informasi selengkapnya tentang persyaratan jaringan untuk node hibrida, 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 hibrida](hybrid-nodes-webhooks.md) untuk informasi selengkapnya tentang persyaratan untuk menjalankan webhook pada node hybrid.

Pesan log pod umum untuk skenario ini ditunjukkan di bawah ini di mana ip-alamat adalah IP Cluster untuk layanan Kubernetes.

```
dial tcp <ip-address>: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 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 IP node dan IP pod Anda termasuk dalam jaringan node jarak jauh dan CIDR jaringan pod jarak jauh yang dikonfigurasi untuk cluster Anda. Gunakan perintah di bawah ini untuk memeriksa penugasan IP.

```
kubectl get nodes -o wide
```

```
kubectl get pods -A -o wide
```

Bandingkan IP ini dengan CIDR jaringan jarak jauh yang dikonfigurasi untuk memastikan routing yang tepat. Untuk persyaratan konfigurasi jaringan, lihat[Mempersiapkan jaringan untuk node hybrid](hybrid-nodes-networking.md).

## Pemecahan masalah CNI node hibrida
<a name="hybrid-nodes-troubleshooting-cni"></a>

Jika Anda mengalami masalah dengan awalnya memulai Cilium atau Calico dengan node hibrida, itu paling sering disebabkan oleh masalah jaringan antara node hybrid atau pod CNI yang berjalan pada node hybrid, dan bidang kontrol EKS. Pastikan lingkungan Anda memenuhi persyaratan dalam Mempersiapkan jaringan untuk node hibrida. Ini berguna untuk memecah masalah menjadi beberapa bagian.

Konfigurasi cluster EKS  
Apakah RemotePodNetwork konfigurasi RemoteNodeNetwork dan benar?

Konfigurasi VPC  
Apakah ada rute untuk RemoteNodeNetwork dan RemotePodNetwork di tabel routing VPC dengan target Transit Gateway atau Virtual Private Gateway?

Konfigurasi grup keamanan  
Apakah ada aturan masuk dan keluar untuk dan? RemoteNodeNetwork RemotePodNetwork 

On-premises jaringan  
Apakah ada rute dan akses ke dan dari bidang kontrol EKS dan ke dan dari node hibrida dan pod yang berjalan pada node hibrida?

Konfigurasi CNI  
Jika menggunakan jaringan overlay, apakah konfigurasi kumpulan IP untuk CNI cocok dengan yang RemotePodNetwork dikonfigurasi untuk cluster EKS jika menggunakan webhook?

 **Node hibrida memiliki status `Ready` tanpa CNI diinstal ** 

Jika node hybrid Anda menampilkan status`Ready`, tetapi Anda belum menginstal CNI di cluster Anda, ada kemungkinan bahwa ada artefak CNI lama pada node hybrid Anda. Secara default, saat 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 (CRD) untuk CNI ini mungkin masih ada di cluster Anda dari instalasi lama. Untuk informasi lebih lanjut, lihat bagian Hapus Cilium dan Hapus Calico dari. [Konfigurasikan CNI untuk node hybrid](hybrid-nodes-cni.md)

 **Pemecahan masalah cilium ** 

Jika Anda mengalami masalah menjalankan Cilium pada node hybrid, lihat langkah-langkah pemec [ ahan 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 kesalahan. Agen Cilium memerlukan konektivitas ke titik akhir EKS Kubernetes API 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 di log pod agen Cilium.

```
msg="Unable to contact k8s api-server"
level=fatal msg="failed to start: Get \"https://<k8s-cluster-ip>:443/api/v1/namespaces/kube-system\": dial tcp <k8s-cluster-ip>:443: i/o timeout"
```

Agen Cilium berjalan di jaringan host. Cluster EKS Anda harus dikonfigurasi `RemoteNodeNetwork` untuk konektivitas Cilium. Konfirmasikan bahwa Anda memiliki grup keamanan tambahan untuk cluster EKS dengan aturan masuk untuk Anda`RemoteNodeNetwork`, bahwa Anda memiliki rute di VPC untuk Anda`RemoteNodeNetwork`, 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 IP pod yang tersedia untuk dialokasikan untuk semua node di cluster Anda. Anda mengonfigurasi ukuran CIDR Pod yang dapat dialokasikan saat menggunakan IPAM kumpulan cluster 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) dalam dokumentasi Cilium untuk informasi selengkapnya.

 **Cilium BGP tidak bekerja ** 

Jika Anda menggunakan Cilium BGP Control Plane untuk mengiklankan alamat pod atau layanan Anda ke jaringan lokal Anda, Anda dapat menggunakan perintah Cilium CLI berikut untuk memeriksa apakah BGP mengiklankan rute ke sumber daya Anda. Untuk langkah-langkah untuk menginstal CLI Cilium, lihat [ Menginstal Cilium CLI ](https://docs.cilium.io/en/stable/gettingstarted/k8s-install-default/#install-the-cilium-cli) dalam dokumentasi Cilium.

Jika BGP bekerja dengan benar, Anda akan melihat node hybrid Anda dengan Status Sesi `established` di output. Anda mungkin perlu bekerja dengan tim jaringan Anda untuk mengidentifikasi nilai yang benar untuk AS Lokal, Peer AS, dan Alamat Peer lingkungan Anda.

```
cilium bgp peers
```

```
cilium bgp routes
```

Jika Anda menggunakan Cilium BGP untuk mengiklankan IP Layanan dengan jenis`LoadBalancer`, Anda harus memiliki label yang sama pada Anda `CiliumLoadBalancerIPPool` dan Layanan, yang harus digunakan di pemilih Anda. `CiliumBGPAdvertisement` Contoh ditunjukkan di bawah ini. Perhatikan, jika Anda menggunakan Cilium BGP untuk mengiklankan IP Layanan dengan tipe LoadBalancer, rute BGP mungkin terganggu selama restart agen Cilium. Untuk informasi selengkapnya, lihat Sken [ ario Kegag ](https://docs.cilium.io/en/latest/network/bgp-control-plane/bgp-control-plane-operation/#failure-scenarios) alan 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: <CIDR to advertise>
  serviceSelector:
    matchExpressions:
      - { key: app, operator: In, values: [ guestbook ] }
```

 **CiliumbGPADiklan ** 

```
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 menjalankan Calico pada node hybrid, lihat langkah-langkah pemec [ ahan 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 jaringan node atau 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 Anda dan tabel perutean VPC Anda harus dikonfigurasi dengan rute untuk CIDR node lokal dengan gateway transit (TGW) atau gateway pribadi virtual (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 routing VPC Anda harus dikonfigurasi dengan rute untuk pod lokal CIDR dengan gateway transit (TGW) atau gateway pribadi virtual (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 tertutup ** 

Sumber daya Calico yang tidak berjalan sebagai a DaemonSet memiliki toleransi fleksibel secara default yang memungkinkannya dijadwalkan pada node tertutup yang tidak siap untuk penjadwalan atau menjalankan pod. Anda dapat memperketat toleransi untuk sumber daya non- DaemonSet 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 kredensi
<a name="hybrid-nodes-troubleshooting-creds"></a>

Untuk aktivasi hibrida AWS SSM dan Peran AWS IAM Anywhere, Anda dapat memvalidasi bahwa kredenSIAL untuk peran IAM Node Hibrid dikonfigurasi dengan benar pada node hibrida Anda dengan menjalankan perintah berikut dari node hibrida Anda. Konfirmasikan nama node dan nama Peran IAM Node Hybrid adalah apa yang Anda harapkan.

```
sudo aws sts get-caller-identity
```

```
{
    "UserId": "ABCDEFGHIJKLM12345678910:<node-name>",
    "Account": "<aws-account-id>",
    "Arn": "arn:aws: sts::<aws-account-id>:assumed-role/<hybrid-nodes-iam-role/<node-name>"
}
```

 ** AWS Pemecahan masalah Manajer Sistem (SSM) ** 

Jika Anda menggunakan aktivasi hibrida AWS SSM untuk kredensional node hibrida Anda, perhatikan direktori dan artefak SSM berikut yang diinstal pada node hibrida Anda oleh. `nodeadm` Untuk informasi selengkapnya tentang agen SSM, lihat Bek [ erja dengan agen SSM ](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent.html) di Panduan Pengguna Manajer * AWS Sistem. *


| Deskripsi | Lokasi | 
| --- | --- | 
| Agen SSM | Ubuntu - `/snap/amazon-ssm-agent/current/amazon-ssm-agent` RHEL & AL2023 - `/usr/bin/amazon-ssm-agent`  | 
| Log SSM Agent |  `/var/log/amazon/ssm`  | 
|  AWS kredensibilitas |  `/root/.aws/credentials`  | 
| CLI Pengaturan SSM |  `/opt/ssm/ssm-setup-cli`  | 

 **Memulai ulang agen SSM ** 

Beberapa masalah dapat diselesaikan dengan memulai ulang 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 Anda dapat terhubung ke titik akhir SSM dari node hybrid Anda. Untuk daftar titik akhir SSM, lihat titik akhir dan kuota Manajer [AWS Sistem. ](https://docs.aws.amazon.com/general/latest/gr/ssm.html) Ganti perintah `us-west-2` di bawah ini dengan Wil AWS ayah untuk aktivasi hibrida AWS SSM Anda.

```
ping ssm.us-west-2.amazonaws.com
```

 **Melihat status koneksi instans SSM terdaftar ** 

Anda dapat memeriksa status koneksi instans yang terdaftar dengan aktivasi hibrida SSM dengan perintah AWS CLI berikut. Ganti ID mesin dengan ID mesin instans 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 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 instance Anda dengan AWS SSM, konfirmas `region` ikan`activationCode`,, dan `activationId` di `nodeConfig.yaml` Anda benar. Wil AWS ayah untuk cluster 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 telah kedaluwarsa ** 

Jika agen SSM tidak dapat menyegarkan kredenSIAL, Anda mungkin melihat. `ExpiredTokenException` Dalam skenario ini, jika Anda dapat terhubung ke titik akhir SSM dari node hibrida, Anda mungkin perlu memulai ulang agen SSM untuk memaksa penyegaran kredensia.

```
"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 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 instance dengan SSM karena aktivasi kedaluwarsa, Anda perlu membuat aktivasi hibrida SSM baru, memperbarui `nodeConfig.yaml` dengan `activationCode` dan `activationId` aktivasi hibrida SSM baru Anda, dan jalankan 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 kredenSIAL yang di-cache ** 

Jika Anda melihat kegagalan untuk menyegarkan kredenSIAL yang di-cache, `/root/.aws/credentials` file tersebut mungkin telah dihapus di host Anda. Pertama periksa aktivasi hibrida SSM Anda dan pastikan aktif dan node hybrid 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 Pemecahan masalah IAM Roles Anywhere ** 

Jika Anda menggunakan AWS IAM Roles Anywhere untuk kredenSIAL node hibrida Anda, perhatikan direktori dan artefak berikut yang diinstal pada node hybrid Anda oleh`nodeadm`. Untuk informasi selengkapnya tentang pemecahan masalah IAM Roles Anywhere, lihat Mem [ ecahkan AWS Masalah identitas dan akses IAM Roles Anywhere ](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/security_iam_troubleshoot.html) di Panduan Pengguna * AWS IAM Roles Anywhere. *


| Deskripsi | Lokasi | 
| --- | --- | 
| Peran IAM Anywhere 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`  | 

 **IAM Roles Anywhere gagal menyegarkan kredenSIAL yang di-cache ** 

Jika Anda melihat kegagalan untuk menyegarkan kredenSIAL yang di-cache, tinjau konten `/etc/aws/hybrid/config` dan konfirmasikan bahwa IAM Roles Anywhere telah dikonfigurasi dengan benar dalam konfigurasi Anda`nodeadm`. Konfirmasikan `/etc/iam/pki` itu ada. Setiap node harus memiliki sertifikat dan kunci yang unik. Secara default, saat menggunakan IAM Roles Anywhere sebagai penyedia kredensia, `nodeadm` `/etc/iam/pki/server.pem` digunakan 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 Anywhere tidak berwenang untuk melakukan `sts:AssumeRole` ** 

Di `kubelet` log, jika Anda melihat masalah akses ditolak untuk `sts:AssumeRole` operasi saat menggunakan Peran IAM Anywhere, periksa kebijakan kepercayaan peran IAM Node Hibrid Anda untuk mengonfirmasi bahwa prinsip layanan IAM Roles Anywhere diizinkan untuk mengambil Peran IAM Node Hibrid. Selain itu, konfirmasikan bahwa jangkar kepercayaan ARN dikonfigurasi dengan benar dalam kebijakan kepercayaan peran IAM Node Hibrid Anda dan bahwa peran IAM Node Hibrid ditambahkan ke profil IAM Roles Anywhere Anda.

```
could not get token: AccessDenied: User: ... is not authorized to perform: sts:AssumeRole on resource: ...
```

 **Peran IAM Anywhere tidak diberi wewenang untuk mengatur `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
<a name="hybrid-nodes-troubleshooting-os"></a>

### RHEL
<a name="_rhel"></a>

 **Kegagalan pendaftaran manajer hak atau langganan ** 

Jika Anda menjalankan `nodeadm install` dan mengalami kegagalan untuk menginstal dependensi node hybrid karena masalah pendaftaran hak, pastikan Anda telah menetapkan nama pengguna dan kata sandi Red Hat dengan benar di host Anda.

```
This system is not registered with an entitlement server
```

### Ubuntu
<a name="_ubuntu"></a>

 **GLIBC tidak ditemukan ** 

Jika Anda menggunakan Ubuntu untuk sistem operasi Anda dan IAM Roles Anywhere untuk penyedia kredensia Anda dengan node hybrid dan melihat masalah dengan GLIBC tidak ditemukan, Anda dapat menginstal dependensi 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
<a name="_bottlerocket"></a>

Jika Anda mengaktifkan wadah admin Bottlerocket, Anda dapat mengaksesnya dengan SSH untuk debugging lanjutan dan pemecahan masalah dengan hak istimewa yang ditingkatkan. 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 wadah admin dengan mengawali setiap perintah dengan`sudo chroot /.bottlerocket/rootfs`.

```
sudo chroot /.bottlerocket/rootfs <command>
```

 **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 kontainer host, Anda dapat menjalankan:

```
journalctl _COMM=host-ctr -f
```