View a markdown version of this page

Lihat persyaratan jaringan Amazon EKS untuk VPC dan subnet - Amazon EKS
Persyaratan dan pertimbangan VPCPersyaratan dan pertimbangan subnetPersyaratan dan pertimbangan subnet bersama

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.

Lihat persyaratan jaringan Amazon EKS untuk VPC dan subnet

Saat Anda membuat cluster, Anda menentukan VPC dan setidaknya dua subnet yang berada di Zona Ketersediaan yang berbeda. Topik ini memberikan gambaran umum tentang persyaratan dan pertimbangan khusus Amazon EKS untuk VPC dan subnet yang Anda gunakan dengan cluster Anda. Jika Anda tidak memiliki VPC untuk digunakan dengan Amazon EKS, lihatBuat VPC Amazon untuk kluster Amazon EKS Anda. Jika Anda membuat cluster lokal atau yang diperluas di AWS Outpost, lihat al Buat VPC dan subnet untuk kluster Amazon EKS AWS Outposts ih-alih topik ini. Konten dalam topik ini berlaku untuk cluster Amazon EKS dengan node hibrida. Untuk persyaratan jaringan tambahan untuk node hybrid, lihatMempersiapkan jaringan untuk node hybrid.

Persyaratan dan pertimbangan VPC

Saat Anda membuat cluster, VPC yang Anda tentukan harus memenuhi persyaratan dan pertimbangan berikut:

  • VPC harus memiliki jumlah alamat IP yang cukup tersedia untuk cluster, node apa pun, dan sumber daya Kubernetes lainnya yang ingin Anda buat. Jika VPC yang ingin Anda gunakan tidak memiliki jumlah alamat IP yang cukup, cobalah untuk menambah jumlah alamat IP yang tersedia.

    Anda dapat melakukan ini dengan memperbarui konfigurasi cluster untuk mengubah subnet dan grup keamanan yang digunakan cluster. Anda dapat memperbarui dari Konsol Manajemen AWS, versi terbaru AWS CLI, AWS CloudFormation, dan eksctl versi v0.164.0-rc.0 atau yang lebih baru. Anda mungkin perlu melakukan ini untuk menyediakan subnet dengan lebih banyak alamat IP yang tersedia agar berhasil memutakhirkan versi cluster.

    penting

    Semua subnet yang Anda tambahkan harus berada dalam kumpulan AZ yang sama seperti yang awalnya disediakan saat Anda membuat cluster. Subnet baru harus memenuhi semua persyaratan lainnya, misalnya mereka harus memiliki alamat IP yang cukup.

    Misalnya, asumsikan bahwa Anda membuat cluster dan menentukan empat subnet. Dalam urutan yang Anda tentukan, subnet pertama berada di Avail us-west-2a ability Zone, subnet kedua dan ketiga berada di Avail us-west-2b ability Zone, dan subnet keempat berada di us-west-2c Availability Zone. Jika Anda ingin mengubah subnet, Anda harus menyediakan setidaknya satu subnet di masing-masing dari tiga Zona Ketersediaan, dan subnet harus berada di VPC yang sama dengan subnet asli.

    Jika Anda memerlukan lebih banyak alamat IP daripada blok CIDR di VPC, Anda dapat menambahkan blok CIDR tambahan dengan mengaitkan blok Classless Inter-Domain Routing (CIDR) tambahan dengan VPC Anda. Anda dapat mengaitkan blok CIDR pribadi (RFC 1918) dan publik (non-RFC 1918) ke VPC Anda sebelum atau sesudah membuat cluster.

    Anda dapat menambahkan node yang menggunakan blok CIDR baru segera setelah Anda menambahkannya. Namun, karena bidang kontrol mengenali blok CIDR baru hanya setelah rekonsiliasi selesai, diperlukan waktu hingga satu jam agar blok CIDR yang Anda kaitkan dengan VPC dapat dikenali. Kemudian Anda dapat menjalankan perintah kubectl attachkubectl cp,kubectl exec,kubectl logs,, dan (kubectl port-forwardperintah ini menggunakankubelet API) untuk node dan pod di blok CIDR baru. Juga, jika Anda memiliki Pod yang beroperasi sebagai backend webhook, maka Anda harus menunggu rekonsiliasi bidang kontrol selesai.

  • Hindari tumpang tindih rentang alamat IP saat Anda menghubungkan cluster EKS Anda ke VPC lain melalui Transit Gateway, peering VPC, atau konfigurasi jaringan lainnya. Konflik CIDR terjadi ketika CIDR layanan cluster EKS Anda tumpang tindih dengan CIDR dari VPC yang terhubung. Dalam skenario ini, alamat IP Layanan diprioritaskan daripada sumber daya di VPC yang terhubung dengan alamat IP yang sama, meskipun perutean lalu lintas dapat menjadi tidak dapat diprediksi dan aplikasi mungkin gagal terhubung ke sumber daya yang dimaksud.

    Untuk menghindari konflik CIDR, pastikan CIDR layanan EKS Anda tidak tumpang tindih dengan CIDR VPC yang terhubung dan simpan catatan terpusat dari semua penugasan CIDR. Jika Anda menemukan tumpang tindih CIDR, Anda dapat menggunakan gateway transit dengan VPC layanan bersama. Untuk informasi selengkapnya, lihat VPC terisolasi dengan layanan bersama dan Pola konservasi alamat IP yang dapat dirutekan VPC Amazon EKS dalam jaringan hibrida. Juga, lihat bagian Komunikasi antar VPC pada halaman Pertimbangan VPC dan Subnet di Panduan Praktik Terbaik EKS.

  • Jika Anda ingin Kubernetes menetapkan IPv6 alamat ke Pod dan layanan, kaitkan blok IPv6 CIDR dengan VPC Anda. Untuk informasi selengkapnya, lihat Mengaitkan blok CIDR IPv6 dengan VPC Anda di Panduan Pengguna Amazon VPC. Anda tidak dapat menggunakan IPv6 alamat dengan Pod dan layanan yang berjalan pada node hibrida dan Anda tidak dapat menggunakan node hibrida dengan cluster yang dikonfigurasi dengan keluarga alamat IPv6 IP.

  • VPC harus memiliki DNS nama host dan dukungan DNS resolusi. Jika tidak, node tidak dapat mendaftar ke cluster Anda. Untuk informasi selengkapnya, lihat atribut DNS untuk VPC Anda di Panduan Pengguna Amazon VPC.

  • VPC mungkin memerlukan penggunaan titik akhir VPC. AWS PrivateLink Untuk informasi selengkapnya, lihat Persyaratan dan pertimbangan subnet.

  • Jika cluster menggunakan customer-routed control plane egress (controlPlaneEgressMode=CUSTOMER_ROUTED), subnet yang digunakan oleh cluster harus dapat merutekan ke setiap titik akhir yang dipanggil pesawat kontrol, seperti server webhook masuk dan penyedia OIDC. Ini membutuhkan jalur keluar (misalnya, gateway NAT, instance NAT, firewall, atau gateway transit ke VPC keluar terpusat) ditambah tabel rute, grup keamanan, dan aturan ACL jaringan yang memungkinkan lalu lintas. Untuk informasi selengkapnya, lihat Mengkonfigurasi perutean jalan keluar bidang kontrol.

Jika Anda membuat cluster dengan Kubernetes 1.14 atau versi sebelumnya, Amazon EKS menambahkan tag berikut ke VPC Anda:

Key Nilai

kubernetes.io/cluster/my-cluster

owned

Tag ini hanya digunakan oleh Amazon EKS. Anda dapat menghapus tag tanpa memengaruhi layanan Anda. Ini tidak digunakan dengan cluster yang versi 1.15 atau lebih baru.

Persyaratan dan pertimbangan subnet

Saat Anda membuat cluster, Amazon EKS membuat 2—4 antarmuka jaringan elastis di subnet yang Anda tentukan. Antarmuka jaringan ini memungkinkan komunikasi antara cluster Anda dan VPC Anda. Antarmuka jaringan ini juga mengaktifkan fitur Kubernetes yang menggunakan. kubelet API Koneksi ke kubelet API digunakan dalam kubectl port-forward perintahkubectl attach,kubectl cp,kubectl exec,kubectl logs, dan. Setiap antarmuka jaringan yang dibuat Amazon EKS memiliki teks Amazon EKS cluster-name dalam deskripsinya.

Antarmuka jaringan yang dikelola permintaan ini juga membawa lalu lintas bidang data antara bidang kontrol dan node pekerja Anda. Amazon EKS menyerap biaya transfer data di sisi bidang kontrol antarmuka jaringan ini. Anda dikenakan tarif transfer AWS data standar untuk lalu lintas di sisi pelanggan — khususnya, masuk ke node pekerja Anda dari bidang kontrol dan keluar dari node pekerja Anda ke bidang kontrol. Untuk informasi selengkapnya, lihat Harga Amazon EKS.

Amazon EKS dapat membuat antarmuka jaringannya di subnet apa pun yang Anda tentukan saat membuat cluster. Anda dapat mengubah subnet mana Amazon EKS membuat antarmuka jaringannya setelah cluster Anda dibuat. Saat Anda memperbarui klaster versi Kubernetes, Amazon EKS menghapus antarmuka jaringan asli yang dibuat, dan membuat antarmuka jaringan baru. Antarmuka jaringan ini dapat dibuat di subnet yang sama dengan antarmuka jaringan asli atau di subnet yang berbeda dari antarmuka jaringan asli. Untuk mengontrol antarmuka jaringan subnet mana yang dibuat, Anda dapat membatasi jumlah subnet yang Anda tentukan menjadi hanya dua saat Anda membuat cluster atau memperbarui subnet setelah membuat cluster.

Persyaratan subnet untuk cluster

Subnet yang Anda tentukan saat membuat atau memperbarui cluster harus memenuhi persyaratan berikut:

  • Subnet masing-masing harus memiliki setidaknya enam alamat IP untuk digunakan oleh Amazon EKS. Namun, kami merekomendasikan setidaknya 16 alamat IP.

  • Subnet harus berada di setidaknya dua Zona Ketersediaan yang berbeda.

  • Subnet tidak dapat berada di AWS Outposts atau AWS Wavelength. Namun, jika Anda memilikinya di VPC Anda, Anda dapat menerapkan node yang dikelola sendiri dan sumber daya Kubernetes ke jenis subnet ini. Untuk informasi selengkapnya tentang node yang dikelola sendiri, lihatPertahankan node sendiri dengan node yang dikelola sendiri.

  • Subnet dapat bersifat publik atau pribadi. Namun, kami sarankan Anda menentukan subnet pribadi, jika memungkinkan. Subnet publik adalah subnet dengan tabel rute yang mencakup rute ke gateway internet, sedangkan subnet pribadi adalah subnet dengan tabel rute yang tidak menyertakan rute ke gateway internet.

  • Subnet tidak dapat berada di Zona Ketersediaan berikut:

    AWS Wilayah Nama wilayah ID Zona Ketersediaan yang Tidak Diizinkan

    us-east-1

    AS Timur (Virginia Utara)

    use1-az3

    us-west-1

    AS Barat (California Utara)

    usw1-az2

    ca-central-1

    Kanada (Pusat)

    cac1-az3

Penggunaan kelompok alamat IP berdasarkan komponen

Tabel berikut berisi keluarga alamat IP yang digunakan oleh setiap komponen Amazon EKS. Anda dapat menggunakan terjemahan alamat jaringan (NAT) atau sistem kompatibilitas lainnya untuk menghubungkan ke komponen ini dari alamat IP sumber dalam keluarga dengan nilai “Tidak” untuk entri tabel.

Fungsionalitas dapat berbeda tergantung pada pengaturan keluarga IP (ipFamily) dari cluster. Pengaturan ini mengubah jenis alamat IP yang digunakan untuk blok CIDR yang ditetapkan Kubernetes ke Layanan. Cluster dengan nilai pengaturan IPv4 disebut sebagai cluster IPv4, dan cluster dengan nilai pengaturan IPv6 disebut sebagai cluster IPv6.

Komponen Alamat IPv4 Alamat IPv6 Alamat tumpukan ganda

Titik akhir publik API EKS

Ya 1,3

Ya 1,3

Ya 1,3

Titik akhir EKS API VPC

Ya

Tidak

Tidak

Titik akhir publik EKS Auth API (EKS Pod Identity)

Ya1

Ya1

Ya1

Titik akhir VPC API Auth EKS (Identitas Pod EKS)

Ya1

Ya1

Ya1

IPv4Titik akhir publik klaster Kubernetes 2

Ya

Tidak

Tidak

IPv4Titik akhir pribadi klaster Kubernetes 2

Ya

Tidak

Tidak

IPv6Titik akhir publik klaster Kubernetes 2

Ya 1,4

Ya 1,4

Ya 4

IPv6Titik akhir pribadi klaster Kubernetes 2

Ya 1,4

Ya 1,4

Ya 4

Subnet cluster Kubernetes

Ya 2

Tidak

Ya 2

Alamat IP Utama Node

Ya 2

Tidak

Ya 2

Rentang CIDR cluster untuk alamat IP Layanan

Ya 2

Ya 2

Tidak

Alamat IP pod dari VPC CNI

Ya 2

Ya 2

Tidak

URL Penerbit IRSA OIDC

Ya 1,3

Ya 1,3

Ya 1,3

catatan

1 Titik akhir adalah tumpukan ganda dengan keduanya IPv4 dan IPv6 alamat. Aplikasi Anda di luar AWS, node Anda untuk cluster, dan pod Anda di dalam cluster dapat mencapai titik akhir ini dengan salah satu IPv4 atauIPv6.

2 Anda memilih antara IPv4 cluster dan IPv6 cluster dalam pengaturan keluarga IP (ipFamily) cluster saat Anda membuat cluster dan ini tidak dapat diubah. Sebagai gantinya, Anda harus memilih pengaturan yang berbeda saat membuat cluster lain dan memigrasikan beban kerja Anda.

3 Titik akhir dual-stack diperkenalkan pada Agustus 2024. Untuk menggunakan titik akhir dual-stack dengan AWS CLI, lihat konfigurasi titik akhir Dual-stack dan FIPS di Panduan Referensi SDK dan Alat AWS . Berikut ini mencantumkan titik akhir baru:

Titik akhir publik API EKS

eks.region.api.aws

URL Penerbit IRSA OIDC

oidc-eks.region.api.aws

4 Titik akhir cluster dual-stack diperkenalkan pada Oktober 2024. EKS membuat titik akhir berikut untuk cluster baru yang dibuat setelah tanggal ini dan yang IPv6 dipilih dalam pengaturan keluarga IP (IPFamily) cluster:

Titik public/private akhir cluster EKS

eks-cluster.region.api.aws

Persyaratan subnet untuk node

Anda dapat menerapkan node dan sumber daya Kubernetes ke subnet yang sama dengan yang Anda tentukan saat membuat cluster. Namun, ini tidak perlu. Ini karena Anda juga dapat menerapkan node dan sumber daya Kubernetes ke subnet yang tidak Anda tentukan saat membuat cluster. Jika Anda menerapkan node ke subnet yang berbeda, Amazon EKS tidak membuat antarmuka jaringan cluster di subnet tersebut. Subnet apa pun yang Anda gunakan node dan sumber daya Kubernetes harus memenuhi persyaratan berikut:

  • Subnet harus memiliki alamat IP yang cukup tersedia untuk menyebarkan semua node dan sumber daya Kubernetes Anda.

  • Jika Anda ingin Kubernetes menetapkan IPv6 alamat ke Pod dan layanan, maka Anda harus memiliki satu blok CIDR dan IPv6 satu blok CIDR yang IPv4 terkait dengan subnet Anda. Untuk informasi selengkapnya, lihat Mengaitkan blok IPv6 CIDR dengan subnet Anda di Panduan Pengguna Amazon VPC. Tabel rute yang terkait dengan subnet harus menyertakan rute ke IPv4 dan IPv6 alamat. Untuk informasi selengkapnya, lihat R ute di Panduan Pengguna Amazon VPC. Pod hanya diberi IPv6 alamat. Namun antarmuka jaringan yang dibuat Amazon EKS untuk cluster Anda dan node Anda diberi IPv4 dan IPv6 alamat.

  • Jika Anda memerlukan akses masuk dari internet ke Pod Anda, pastikan untuk memiliki setidaknya satu subnet publik dengan alamat IP yang cukup tersedia untuk menyebarkan penyeimbang beban dan input. Anda dapat menerapkan penyeimbang beban ke subnet publik. Penyeimbang beban dapat menyeimbangkan beban ke Pod di subnet pribadi atau publik. Sebaiknya gunakan node Anda ke subnet pribadi, jika memungkinkan.

  • Jika Anda berencana untuk menyebarkan node ke subnet publik, subnet harus menetapkan alamat atau alamat IPv4 publik secara otomatis. IPv6 Jika Anda menyebarkan node ke subnet pribadi yang memiliki blok IPv6 CIDR terkait, subnet pribadi juga harus menetapkan alamat secara otomatis. IPv6 Jika Anda menggunakan AWS CloudFormation template yang disediakan oleh Amazon EKS untuk menerapkan VPC Anda setelah 26 Maret 2020, pengaturan ini diaktifkan. Jika Anda menggunakan templat untuk menerapkan VPC sebelum tanggal ini atau Anda menggunakan VPC Anda sendiri, Anda harus mengaktifkan pengaturan ini secara manual. Untuk template, lihatBuat VPC Amazon untuk kluster Amazon EKS Anda. Untuk informasi selengkapnya, lihat Memodifikasi atribut pengalamatan IPv4 publik untuk subnet Anda dan Memo difikasi atribut pengalamatan IPv6 untuk subnet Anda di Panduan Pengguna Amazon VPC.

  • Jika subnet tempat Anda menerapkan node adalah subnet pribadi dan tabel rutenya tidak menyertakan rute ke perangkat terjemahan alamat jaringan (NAT) () atau gateway khusus keluar (IPv4IPv6), tambahkan titik akhir VPC menggunakan ke VPC Anda. AWS PrivateLink Titik akhir VPC diperlukan untuk semua AWS layanan yang perlu berkomunikasi dengan node dan Pod Anda. Contohnya termasuk Amazon ECR, Elastic Load Bal CloudWatch ancing, Amazon, AWS Security Token Service, dan Amazon Simple Storage Service (Amazon S3). Jika Anda menggunakan peran IAM untuk akun layanan (IRSA), Anda juga dapat mencapai titik akhir OIDC cluster secara pribadi dengan discovery/JWKS titik akhir. com.amazonaws.region-code.oidc-eks Untuk informasi selengkapnya, lihat Akses titik akhir OIDC cluster menggunakan AWS PrivateLink. Titik akhir harus menyertakan subnet tempat node berada. Tidak semua AWS layanan mendukung titik akhir VPC. Untuk informasi lebih lanjut, lihat Apa itu AWS PrivateLink? dan AWS layanan yang terintegrasi dengan AWS PrivateLink. Untuk daftar persyaratan Amazon EKS lainnya, lihatMenyebarkan cluster pribadi dengan akses internet terbatas.

  • Jika Anda ingin menyebarkan penyeimbang beban ke subnet, subnet harus memiliki tag berikut:

    • Subnet privat

      Key Nilai

      kubernetes.io/role/internal-elb

      1

    • Subnet publik

      Key Nilai

      kubernetes.io/role/elb

      1

Ketika cluster Kubernetes versi 1.18 dan sebelumnya dibuat, Amazon EKS menambahkan tag berikut ke semua subnet yang ditentukan.

Key Nilai

kubernetes.io/cluster/my-cluster

shared

Saat Anda membuat cluster Kubernetes baru sekarang, Amazon EKS tidak menambahkan tag ke subnet Anda. Jika tag berada di subnet yang digunakan oleh cluster yang sebelumnya versi lebih awal dari1.19, tag tidak secara otomatis dihapus dari subnet saat cluster diperbarui ke versi yang lebih baru. Versi 2.1.1 atau versi sebelumnya dari AWS Load Balancer Controller memerlukan tag ini. Jika Anda menggunakan versi yang lebih baru dari Load Balancer Controller, Anda dapat menghapus tag tanpa mengganggu layanan Anda. Untuk informasi selengkapnya tentang pengontrol, lihatRute lalu lintas internet dengan AWS Pengontrol Load Balancer.

Jika Anda menerapkan VPC dengan menggunakan eksctl atau salah satu templat AWS CloudFormation VPC Amazon EKS, berikut ini berlaku:

  • Pada atau setelah 26 Maret 2020 — IPv4 Alamat publik secara otomatis ditetapkan oleh subnet publik ke node baru yang digunakan ke subnet publik.

  • Sebelum 26 Maret 2020 — IPv4 Alamat publik tidak secara otomatis ditetapkan oleh subnet publik ke node baru yang digunakan ke subnet publik.

Perubahan ini berdampak pada grup node baru yang digunakan ke subnet publik dengan cara berikut:

Persyaratan dan pertimbangan subnet bersama

Anda dapat menggunakan berbagi VPC untuk berbagi subnet dengan AWS akun lain dalam Organisasi yang sama AWS . Anda dapat membuat cluster Amazon EKS di subnet bersama, dengan pertimbangan berikut:

  • Pemilik subnet VPC harus berbagi subnet dengan akun peserta sebelum akun tersebut dapat membuat cluster Amazon EKS di dalamnya.

  • Anda tidak dapat meluncurkan sumber daya menggunakan grup keamanan default untuk VPC karena milik pemilik. Selain itu, peserta tidak dapat meluncurkan sumber daya menggunakan grup keamanan yang dimiliki oleh peserta lain atau pemilik.

  • Dalam subnet bersama, peserta dan pemilik secara terpisah mengontrol grup keamanan dalam setiap akun masing-masing. Pemilik subnet dapat melihat grup keamanan yang dibuat oleh peserta tetapi tidak dapat melakukan tindakan apa pun pada mereka. Jika pemilik subnet ingin menghapus atau memodifikasi grup keamanan ini, peserta yang membuat grup keamanan harus mengambil tindakan tersebut.

  • Jika cluster dibuat oleh peserta, pertimbangan berikut berlaku:

  • Pemilik VPC bersama tidak dapat melihat, memperbarui, atau menghapus cluster yang dibuat peserta di subnet bersama. Ini adalah tambahan untuk sumber daya VPC yang memiliki akses berbeda untuk setiap akun. Untuk informasi selengkapnya, lihat Tanggung jawab dan izin untuk pemilik dan peserta di Panduan Pengguna Amazon VPC.

  • Jika Anda menggunakan fitur jaringan ku stom plugin Amazon VPC CNI untuk Kubernetes, Anda perlu menggunakan pemetaan ID Zona Ketersediaan yang tercantum di akun pemilik untuk membuatnya. ENIConfig Untuk informasi selengkapnya, lihat Menerapkan Pod di subnet alternatif dengan jaringan khusus.

Untuk informasi selengkapnya tentang berbagi subnet VPC, lihat Mem bagikan VPC Anda dengan akun lain di Panduan Pengguna Amazon VPC.