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 cluster Amazon EKS lokal di AWS Outposts
Topik ini mencakup beberapa kesalahan umum yang mungkin Anda lihat saat menggunakan cluster lokal dan cara memecahkan masalah mereka. Cluster lokal mirip dengan cluster Amazon EKS di cloud, tetapi ada beberapa perbedaan dalam cara pengelolaannya oleh Amazon EKS.
penting
Jangan pernah menghentikan instans Kubernetes kontrol cluster lokal EKS terkelola yang berjalan di Outpost kecuali secara eksplisit diinstruksikan oleh Dukungan. AWS Menghentikan instans ini menimbulkan risiko terhadap ketersediaan layanan cluster lokal, termasuk hilangnya cluster lokal jika beberapa instans dihentikan secara bersamaan. Instans bidang Kubernetes kontrol cluster lokal EKS diidentifikasi oleh tag eks-local:controlplane-name pada konsol instance EC2.
Cluster lokal dibuat melalui Amazon EKS API, tetapi dijalankan secara asinkron. Ini berarti bahwa permintaan ke API Amazon EKS segera kembali untuk cluster lokal. Namun, permintaan ini mungkin berhasil, gagal cepat karena kesalahan validasi input, atau gagal dan memiliki kesalahan validasi deskriptif. Perilaku ini mirip dengan API Kubernetes.
Cluster lokal tidak bertransisi ke FAILED status. Amazon EKS mencoba untuk merekonsiliasi status cluster dengan status yang diinginkan yang diminta pengguna secara terus menerus. Akibatnya, cluster lokal mungkin tetap berada di CREATING negara bagian untuk jangka waktu yang lama sampai masalah yang mendasarinya diselesaikan.
Masalah cluster lokal dapat ditemukan menggunakan perintah descripbe-cluster Amazon EKS AWS CLI. Masalah cluster lokal muncul oleh cluster.health bidang respons describe-cluster perintah. Pesan yang terkandung dalam bidang ini mencakup kode kesalahan, pesan deskriptif, dan ID sumber daya terkait. Informasi ini hanya tersedia melalui Amazon EKS API dan AWS CLI. Dalam contoh berikut, ganti my-cluster dengan nama cluster lokal Anda.
aws eks describe-cluster --name my-cluster --query 'cluster.health'
Contoh output adalah sebagai berikut.
{ "issues": [ { "code": "ConfigurationConflict", "message": "The instance type 'm5.large' is not supported in Outpost 'my-outpost-arn'.", "resourceIds": [ "my-cluster-arn" ] } ] }
Jika masalah tidak dapat diperbaiki, Anda mungkin perlu menghapus cluster lokal dan membuat yang baru. Misalnya, mencoba menyediakan cluster dengan jenis instance yang tidak tersedia di Outpost Anda. Tabel berikut mencakup kesalahan umum terkait kesehatan.
| Skenario kesalahan | Kode | Pesan | ResourceIds |
|---|---|---|---|
|
Subnet yang disediakan tidak dapat ditemukan. |
|
|
Semua ID subnet yang disediakan |
|
Subnet yang disediakan bukan milik VPC yang sama. |
|
|
Semua ID subnet yang disediakan |
|
Beberapa subnet yang disediakan bukan milik Pos Terdepan yang ditentukan. |
|
|
ID subnet yang bermasalah |
|
Beberapa subnet yang disediakan bukan milik Pos Terdepan mana pun. |
|
|
ID subnet yang bermasalah |
|
Beberapa subnet yang disediakan tidak memiliki alamat bebas yang cukup untuk membuat antarmuka jaringan elastis untuk instance bidang kontrol. |
|
|
ID subnet yang bermasalah |
|
Jenis instance pesawat kontrol yang ditentukan tidak didukung di Outpost Anda. |
|
|
ARN klaster |
|
Anda menghentikan instans Amazon EC2 bidang kontrol atau |
|
|
ARN klaster |
|
Anda memiliki kapasitas yang tidak mencukupi di pos terdepan Anda. Ini juga dapat terjadi ketika cluster sedang dibuat jika Pos Terdepan terputus dari Wil AWS ayah. |
|
|
ARN klaster |
|
Akun Anda melebihi kuota grup keamanan Anda. |
|
Pesan kesalahan dikembalikan oleh Amazon EC2 API |
Target VPC ID |
|
Akun Anda melebihi kuota antarmuka jaringan elastis Anda. |
|
Pesan kesalahan dikembalikan oleh Amazon EC2 API |
ID subnet target |
|
Instans pesawat kontrol tidak dapat dijangkau melalui Manajer AWS Sistem. Untuk resolusi, lihatInstans pesawat kontrol tidak dapat dijangkau melalui AWS Systems Manager. |
|
Instans pesawat kontrol Amazon EKS tidak dapat dijangkau melalui SSM. Harap verifikasi SSM dan konfigurasi jaringan Anda, dan rujuk dokumentasi pemecahan masalah EKS on Outposts. |
ID instans Amazon EC2 |
|
Terjadi kesalahan saat mendapatkan detail untuk grup keamanan terkelola atau antarmuka jaringan elastis. |
Berdasarkan kode kesalahan klien Amazon EC2. |
Pesan kesalahan dikembalikan oleh Amazon EC2 API |
Semua ID grup keamanan terkelola |
|
Terjadi kesalahan saat mengotorisasi atau mencabut aturan masuk grup keamanan. Ini berlaku untuk kelompok keamanan cluster dan pesawat kontrol. |
Berdasarkan kode kesalahan klien Amazon EC2. |
Pesan kesalahan dikembalikan oleh Amazon EC2 API |
ID grup keamanan yang bermasalah |
|
Terjadi kesalahan saat menghapus antarmuka jaringan elastis untuk instance bidang kontrol. |
Berdasarkan kode kesalahan klien Amazon EC2. |
Pesan kesalahan dikembalikan oleh Amazon EC2 API |
ID antarmuka jaringan elastis yang bermasalah |
Tabel berikut mencantumkan kesalahan dari AWS layanan lain yang disajikan di bidang kesehatan describe-cluster respons.
| Kode kesalahan Amazon EC2 | Kode masalah kesehatan cluster | Deskripsi |
|---|---|---|
|
|
|
Kesalahan ini dapat terjadi karena berbagai alasan. Alasan paling umum adalah Anda secara tidak sengaja menghapus tag yang digunakan layanan untuk menguraikan kebijakan peran terkait layanan dari bidang kontrol. Jika ini terjadi, Amazon EKS tidak dapat lagi mengelola dan memantau AWS sumber daya ini. |
|
|
|
Kesalahan ini dapat terjadi karena berbagai alasan. Alasan paling umum adalah Anda secara tidak sengaja menghapus tag yang digunakan layanan untuk menguraikan kebijakan peran terkait layanan dari bidang kontrol. Jika ini terjadi, Amazon EKS tidak dapat lagi mengelola dan memantau AWS sumber daya ini. |
|
|
|
Kesalahan ini terjadi ketika ID subnet untuk aturan masuk grup keamanan tidak dapat ditemukan. |
|
|
|
Kesalahan ini terjadi ketika izin untuk aturan masuk grup keamanan tidak benar. |
|
|
|
Kesalahan ini terjadi ketika grup aturan masuk dari grup keamanan tidak dapat ditemukan. |
|
|
|
Kesalahan ini terjadi ketika ID antarmuka jaringan untuk aturan masuk grup keamanan tidak dapat ditemukan. |
|
|
|
Kesalahan ini terjadi ketika kuota sumber daya subnet terlampaui. |
|
|
|
Kesalahan ini terjadi ketika kuota kapasitas pos terlampaui. |
|
|
|
Kesalahan ini terjadi ketika kuota antarmuka jaringan elastis terlampaui. |
|
|
|
Kesalahan ini terjadi ketika kuota grup keamanan terlampaui. |
|
|
|
Ini diamati saat membuat instans Amazon EC2 di akun baru. Kesalahannya mungkin mirip dengan yang berikut: " |
|
|
|
Amazon EC2 mengembalikan kode kesalahan ini jika jenis instans yang ditentukan tidak didukung di Outpost. |
|
Semua kegagalan lainnya |
|
Tidak ada |
Cluster lokal memerlukan izin dan kebijakan yang berbeda dari cluster Amazon EKS yang dihosting di cloud. Ketika cluster gagal membuat dan menghasilkan InvalidPermissions kesalahan, periksa kembali apakah peran cluster yang Anda gunakan memiliki kebijakan terkel AmazonEKSLocalOutpostClusterPolicy ola yang dilampirkan padanya. Semua panggilan API lainnya memerlukan kumpulan izin yang sama dengan cluster Amazon EKS di cloud.
Jumlah waktu yang dibutuhkan untuk membuat cluster lokal bervariasi tergantung pada beberapa faktor. Faktor-faktor ini termasuk konfigurasi jaringan Anda, konfigurasi Outpost, dan konfigurasi cluster. Secara umum, cluster lokal dibuat dan berubah ACTIVE status dalam 15-20 menit. Jika cluster lokal tetap berada di CREATING status, Anda dapat memang describe-cluster gil informasi tentang penyebabnya di bidang cluster.health keluaran.
Masalah yang paling umum adalah sebagai berikut:
-
Cluster Anda tidak dapat terhubung ke instance bidang kontrol dari Wil AWS ayah tempat Manajer Sistem berada. Anda dapat memverifikasi ini dengan menelepon
aws ssm start-session --targetdari host benteng di wilayah. Jika perintah itu tidak berfungsi, periksa apakah Manajer Sistem berjalan pada instance bidang kontrol. Atau, solusi lain adalah menghapus cluster dan kemudian membuatnya kembali.instance-id -
Instans bidang kontrol gagal dibuat karena izin kunci KMS untuk volume EBS. Dengan kunci KMS yang dikelola pengguna untuk volume EBS terenkripsi, instans bidang kontrol akan berakhir jika kunci tidak dapat diakses. Jika instans dihentikan, beralih ke kunci KMS terkel AWS ola atau pastikan kebijakan kunci yang dikelola pengguna Anda memberikan izin yang diperlukan untuk peran cluster.
-
Instans pesawat kontrol Manajer Sistem mungkin tidak memiliki akses internet. Periksa apakah subnet yang Anda berikan saat Anda membuat cluster memiliki gateway NAT dan VPC dengan gateway internet. Gunakan penganalisis jangkauan VPC untuk memverifikasi bahwa instance bidang kontrol dapat mencapai gateway internet. Untuk informasi selengkapnya, lihat Mem ulai dengan VPC Reachability Analyzer.
-
Peran ARN yang Anda berikan tidak memiliki kebijakan. Periksa apakah AWS kebijakan AmazonEKSLocalOutpostClusterPolicy terkelola: telah dihapus dari peran. Ini juga dapat terjadi jika AWS CloudFormation tumpukan salah dikonfigurasi.
-
Semua subnet yang disediakan harus dikaitkan dengan Pos Terdepan yang sama dan harus saling menjangkau. Ketika beberapa subnet ditentukan saat cluster dibuat, Amazon EKS mencoba menyebarkan instance bidang kontrol di beberapa subnet.
-
Grup keamanan terkelola Amazon EKS diterapkan pada antarmuka jaringan elastis. Namun, elemen konfigurasi lain seperti aturan firewall NACL mungkin bertentangan dengan aturan untuk antarmuka jaringan elastis.
-
Konfigurasi DNS VPC dan subnet salah dikonfigurasi atau hilang. Tinjau Buat VPC dan subnet untuk cluster Amazon EKS di AWS Outpost.
Amazon EKS secara otomatis memperbarui semua cluster lokal yang ada ke versi platform terbaru untuk versi minor Kubernetes yang sesuai. Untuk informasi lebih lanjut tentang versi platform, silakan merujuk kePelajari versi platform Kubernetes dan Amazon EKS untuk AWS Outposts.
Selama peluncuran versi platform otomatis, status cluster berubah menjadi. UPDATING Proses pembaruan terdiri dari penggantian semua instance bidang kontrol Kubernetes dengan yang baru yang berisi patch keamanan terbaru dan perbaikan bug yang dirilis untuk versi minor Kubernetes masing-masing. Secara umum, proses pembaruan platform cluster lokal selesai dalam waktu kurang dari 30 menit dan cluster berubah kembali ke ACTIVE status. Jika cluster lokal tetap dalam UPDATING status untuk jangka waktu yang lama, Anda dapat menelepon describe-cluster untuk memeriksa informasi tentang penyebabnya di bidang cluster.health keluaran.
Amazon EKS memastikan setidaknya 2 dari 3 instans bidang kontrol Kubernetes adalah node cluster yang sehat dan operasional untuk menjaga ketersediaan cluster lokal dan mencegah gangguan layanan. Jika klaster lokal terhenti dalam UPDATING keadaan, biasanya karena ada beberapa masalah infrastruktur atau konfigurasi yang mencegah ketersediaan minimum dua instans dijamin jika proses berlanjut. Jadi proses pembaruan berhenti berkembang untuk mencegah gangguan layanan cluster lokal.
Penting untuk memecahkan masalah cluster lokal yang terjebak dalam UPDATING status dan mengatasi akar penyebab sehingga proses pembaruan dapat menyelesaikan dan mengembalikan cluster lokal kembali ACTIVE dengan ketersediaan tinggi dari 3 instans bidang kontrol Kubernetes.
Jangan menghentikan Kubernetes instans cluster lokal EKS terkelola di Outpost kecuali diinstruksikan secara eksplisit oleh AWS Dukungan. Ini sangat penting untuk cluster lokal yang terjebak dalam UPDATING status karena ada kemungkinan tinggi bahwa node bidang kontrol lain tidak sepenuhnya sehat dan menghentikan instance yang salah dapat menyebabkan gangguan layanan dan risiko kehilangan data kluster lokal.
Masalah yang paling umum adalah sebagai berikut:
-
Satu atau lebih instance control-plane tidak dapat terhubung ke Manajer Sistem karena perubahan konfigurasi jaringan sejak cluster lokal pertama kali dibuat. Anda dapat memverifikasi ini dengan menelepon
aws ssm start-session --targetdari host benteng di wilayah. Jika perintah itu tidak berfungsi, periksa apakah Manajer Sistem berjalan pada instance bidang kontrol.instance-id -
Instans bidang kontrol baru gagal dibuat karena izin kunci KMS untuk volume EBS. Dengan kunci KMS yang dikelola pengguna untuk volume EBS terenkripsi, instans bidang kontrol akan berakhir jika kunci tidak dapat diakses. Jika instans dihentikan, beralih ke kunci KMS terkel AWS ola atau pastikan kebijakan kunci yang dikelola pengguna Anda memberikan izin yang diperlukan untuk peran cluster.
-
Instans pesawat kontrol Manajer Sistem mungkin kehilangan akses internet. Periksa apakah subnet yang disediakan saat Anda membuat cluster memiliki gateway NAT dan VPC dengan gateway internet. Gunakan penganalisis jangkauan VPC untuk memverifikasi bahwa instance bidang kontrol dapat mencapai gateway internet. Untuk informasi selengkapnya, lihat Mem ulai dengan VPC Reachability Analyzer. Jika jaringan pribadi Anda tidak memiliki koneksi internet keluar, pastikan bahwa semua titik akhir VPC dan titik akhir gateway yang diperlukan masih ada di subnet Regional dari cluster Anda (lihat). Akses subnet ke AWS layanan
-
Peran ARN yang Anda berikan tidak memiliki kebijakan. Periksa apakah AWS kebijakan AmazonEKSLocalOutpostClusterPolicy terkelola: telah dihapus dari peran.
-
Salah satu instance control-plane Kubernetes baru mungkin mengalami kegagalan bootstrap yang tidak terduga. Silakan ajukan tiket ke Pusat AWS Dukungan
untuk panduan lebih lanjut tentang pemecahan masalah dan pengumpulan log dalam kasus luar biasa ini.
-
Masalah AMI:
-
Anda menggunakan AMI yang tidak kompatibel. Hanya AMI Amazon Linux 2023 yang dioptimalkan Amazon EKS yang didukung. Untuk informasi selengkapnya, lihat Membuat node Amazon Linux di AWS Outpost.
-
Jika Anda menggunakan AWS CloudFormation template untuk membuat node, pastikan itu tidak menggunakan AMI yang tidak didukung.
-
-
Hilang AWS IAM Authenticator
ConfigMap- Jika hilang, Anda harus membuatnya. Untuk informasi selengkapnya, lihat Terapkan aws-auth ke cluster Anda ConfigMap. -
Grup keamanan yang salah digunakan — Pastikan
eks-cluster-sg-untuk menggunakan grup keamanan node pekerja Anda. Grup keamanan yang dipilih diubah oleh AWS CloudFormation untuk mengizinkan grup keamanan baru setiap kali tumpukan digunakan.cluster-name-uniqueid -
Mengikuti langkah-langkah VPC tautan pribadi yang tidak terduga — Data CA (
--b64-cluster-ca) atau API Endpoint (--apiserver-endpoint) yang salah diteruskan.
Ketika Pos Terdepan terputus dari Wil AWS ayah yang terkait dengannya, cluster Kubernetes kemungkinan akan terus bekerja secara normal. Namun, jika cluster tidak berfungsi dengan baik, ikuti langkah-langkah pemecahan masalah di Si apkan cluster Amazon EKS lokal di AWS Outpost untuk pemutusan jaringan. Jika Anda mengalami masalah lain, hubungi AWS Dukungan. AWS Dukungan dapat memandu Anda dalam mengunduh dan menjalankan alat pengumpulan log. Dengan begitu, Anda dapat mengumpulkan log dari instance pesawat kontrol cluster Kubernetes Anda dan mengirimkannya ke AWS Dukungan untuk penyelidikan lebih lanjut.
Ketika instans bidang kontrol Amazon EKS tidak dapat dijangkau melalui Manajer AWS Sistem (Manajer Sistem), Amazon EKS menampilkan kesalahan berikut untuk cluster Anda.
Amazon EKS control plane instances are not reachable through SSM. Please verify your SSM and network configuration, and reference the EKS on Outposts troubleshooting documentation.
Untuk mengatasi masalah ini, pastikan VPC dan subnet memenuhi persyaratan di Buat VPC dan subnet untuk cluster Amazon EKS di AWS Outposts dan Anda telah menyelesaikan langkah-langkah dalam Menyiapkan Manajer Sesi di Panduan Pengguna Manajer Sistem. AWS