Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Pertimbangan VPC dan Subnet
Tip
Jelaj
Mengoperasikan cluster EKS membutuhkan pengetahuan tentang jaringan AWS VPC, selain jaringan Kubernetes.
Kami menyarankan Anda memahami mekanisme komunikasi bidang kontrol EKS sebelum Anda mulai merancang VPC Anda atau menyebarkan cluster ke VPC yang ada.
Lihat Pertimbangan VPC Cluster dan pertimbangan grup keamanan Amazon EKS saat merancang VPC dan subnet untuk digunakan dengan EKS.
Gambaran umum
Arsitektur Cluster EKS
Cluster EKS terdiri dari dua VPC:
-
AWS-managed VPC yang menjadi tuan rumah pesawat kontrol Kubernetes. VPC ini tidak muncul di akun pelanggan.
-
VPC yang dikelola pelanggan yang menghosting node Kubernetes. Di sinilah wadah berjalan, serta infrastruktur AWS yang dikelola pelanggan lainnya seperti penyeimbang beban yang digunakan oleh cluster. VPC ini muncul di akun pelanggan. Anda perlu membuat VPC yang dikelola pelanggan sebelum membuat cluster. Eksctl membuat VPC jika Anda tidak menyediakannya.
Node di VPC pelanggan memerlukan kemampuan untuk terhubung ke titik akhir server API terkelola di AWS VPC. Hal ini memungkinkan node untuk mendaftar dengan bidang kontrol Kubernetes dan menerima permintaan untuk menjalankan Pod aplikasi.
Node terhubung ke bidang kontrol EKS melalui (a) titik akhir publik EKS atau (b) antarmuka jaringan Cross-Account elastis (X-ENI) yang dikelola oleh EKS. Ketika cluster dibuat, Anda perlu menentukan setidaknya dua subnet VPC. EKS menempatkan a X-ENI di setiap subnet yang ditentukan selama pembuatan cluster (juga disebut subnet cluster). Server API Kubernetes menggunakan ENI ini untuk berkomunikasi dengan node Cross-Account yang digunakan pada subnet VPC cluster yang dikelola pelanggan.
Saat node dimulai, skrip bootstrap EKS dijalankan dan file konfigurasi node Kubernetes diinstal. Sebagai bagian dari proses boot pada setiap instance, agen runtime container, kubelet, dan agen node Kubernetes diluncurkan.
Untuk mendaftarkan node, Kubelet menghubungi titik akhir cluster Kubernetes. Ini membuat koneksi dengan titik akhir publik di luar VPC atau titik akhir pribadi dalam VPC. Kubelet menerima instruksi API dan menyediakan pembaruan status dan detak jantung ke titik akhir secara teratur.
Komunikasi Pesawat Kontrol EKS
EKS memiliki dua cara untuk mengontrol akses ke titik akhir cluster. Kontrol akses titik akhir memungkinkan Anda memilih apakah titik akhir dapat dijangkau dari internet publik atau hanya melalui VPC Anda. Anda dapat mengaktifkan titik akhir publik (yang merupakan default), titik akhir pribadi, atau keduanya sekaligus.
Konfigurasi titik akhir API cluster menentukan jalur yang diambil node untuk berkomunikasi ke bidang kontrol. Perhatikan bahwa pengaturan titik akhir ini dapat diubah kapan saja melalui konsol EKS atau API.
Titik Akhir Publik
Ini adalah perilaku default untuk klaster Amazon EKS yang baru. Jika hanya titik akhir publik untuk cluster yang diaktifkan, permintaan API Kubernetes yang berasal dari dalam VPC cluster Anda (seperti node pekerja untuk mengontrol komunikasi pesawat) meninggalkan VPC, tetapi tidak dari jaringan Amazon. Agar node dapat terhubung ke bidang kontrol, mereka harus memiliki alamat IP publik dan rute ke gateway internet atau rute ke gateway NAT di mana mereka dapat menggunakan alamat IP publik dari gateway NAT.
Titik Akhir Publik dan Pribadi
Ketika titik akhir publik dan pribadi diaktifkan, permintaan API Kubernetes dari dalam VPC berkomunikasi ke bidang kontrol melalui dalam VPC Anda. X-ENIs Server API klaster Anda dapat diakses dari internet.
Titik Akhir Pribadi
Tidak ada akses publik ke server API Anda dari internet ketika hanya titik akhir pribadi yang diaktifkan. Semua lalu lintas ke server API cluster Anda harus berasal dari dalam VPC cluster Anda atau jaringan yang terhubung. Node berkomunikasi ke server API melalui X-ENIs dalam VPC Anda. Perhatikan bahwa alat manajemen cluster harus memiliki akses ke titik akhir pribadi. Pelajari selengkap nya tentang cara menyambung ke titik akhir cluster Amazon EKS pribadi dari luar Amazon VPC.
Perhatikan bahwa titik akhir server API cluster diselesaikan oleh server DNS publik ke alamat IP pribadi dari VPC. Di masa lalu, titik akhir hanya dapat diselesaikan dari dalam VPC.
Konfigurasi VPC
Amazon VPC mendukung pengalamatan IPv4 dan IPv6. Amazon EKS mendukung IPv4 secara default. VPC harus memiliki blok IPv4 CIDR yang terkait dengannya. Anda dapat secara opsional mengaitkan beberapa blok IPv4 Classless Inter-Domain Routing /16 awalan (65.536 alamat IP) dan /28 awalan (16 alamat IP).
Saat membuat VPC baru, Anda dapat melampirkan satu blok CIDR IPv6, dan hingga lima saat mengubah VPC yang ada. Panjang awalan ukuran blok IPv6 CIDR dapat antara /44 dan /60 dan untuk subnet IPv6 dapat antara /44/ dan /64. Anda dapat meminta blok IPv6 CIDR dari kumpulan alamat IPv6 yang dikelola oleh Amazon. Silakan merujuk ke bagian blok VPC CIDR pada Panduan Pengguna VPC untuk informasi lebih lanjut.
Cluster Amazon EKS mendukung IPv4 dan IPv6. Secara default, cluster EKS menggunakan IP IPv4. Menentukan IPv6 pada waktu pembuatan cluster akan memungkinkan penggunaan cluster IPv6. Cluster IPv6 membutuhkan VPC dan subnet dual-stack.
Amazon EKS mengharuskan Anda menentukan setidaknya dua subnet di dua Zona Ketersediaan yang berbeda saat Anda membuat cluster. Subnet yang Anda tentukan dikenal sebagai subnet cluster. Amazon EKS menyediakan dua ENI lintas akun (X-ENI) di Zona Ketersediaan yang berbeda untuk mengaktifkan komunikasi dengan node pekerja Anda. Saat Anda membuat cluster, Amazon EKS membuat 2—4 X-ENI di subnet yang Anda tentukan. Amazon EKS selalu menerapkan X-enis dan menggunakannya untuk lalu lintas administrasi cluster seperti pengiriman log, exec, dan proxy. Untuk informasi selengkapnya tentang persyaratan VPC dan subnet, lihat persyaratan VPC dan subnet di Panduan Pengguna Amazon EKS.
Node pekerja Kubernetes dapat berjalan di subnet cluster, tetapi tidak disarankan. Selama peningkatan cluster, Amazon EKS menyediakan ENI tambahan di subnet cluster. Saat cluster Anda mengalami peningkatan skala, node dan pod pekerja dapat menggunakan IP yang tersedia di subnet cluster. Oleh karena itu untuk memastikan ada cukup IP yang tersedia, Anda mungkin ingin mempertimbangkan untuk menggunakan subnet cluster khusus dengan/28 netmask.
Node pekerja Kubernetes dapat berjalan baik di subnet publik atau pribadi. Apakah subnet bersifat publik atau pribadi mengacu pada apakah lalu lintas di dalam subnet dirutekan melalui gateway internet. https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html Subnet publik memiliki entri tabel rute ke internet melalui gateway internet, tetapi subnet pribadi tidak.
Lalu lintas yang berasal dari tempat lain dan mencapai node Anda disebut Ingress. Lalu lintas yang berasal dari node dan meninggalkan jaringan disebut keluar. Node dengan alamat IP publik atau elastis (EIP) dalam subnet yang dikonfigurasi dengan gateway internet memungkinkan masuknya dari luar VPC. Subnet pribadi biasanya memiliki routing ke gateway NAT, yang tidak mengizinkan lalu lintas masuk ke node di subnet dari luar VPC sementara masih mengizinkan lalu lintas dari node untuk meninggalkan VPC (egress).
Di dunia IPv6, setiap alamat dapat dirutekan internet. Alamat IPv6 yang terkait dengan node dan pod bersifat publik. Subnet pribadi didukung dengan menerapkan gateway internet khusus keluar (EIGW) di VPC, memungkinkan lalu lintas keluar sambil memblokir semua lalu lintas masuk. Praktik terbaik untuk mengimplementasikan subnet IPv6 dapat ditemukan di panduan pengguna VPC.
Anda dapat mengonfigurasi VPC dan Subnets dengan tiga cara berbeda:
Hanya menggunakan subnet publik
Di subnet publik yang sama, node dan sumber daya masuk (seperti penyeimbang beban) dibuat. Tandai subnet publik dengan kubernetes.io/role/elb untuk membangun penyeimbang beban yang menghadapi internet. Dalam konfigurasi ini, titik akhir cluster dapat dikonfigurasi menjadi publik, pribadi, atau keduanya (publik dan pribadi).
Menggunakan subnet pribadi dan publik
Node dibuat pada subnet pribadi, sedangkan sumber daya Ingress dibuat di subnet publik. Anda dapat mengaktifkan akses publik, pribadi, atau keduanya (publik dan pribadi) ke titik akhir cluster. Tergantung pada konfigurasi titik akhir cluster, lalu lintas node akan masuk melalui gateway NAT atau ENI.
Hanya menggunakan subnet pribadi
Baik node dan masuk dibuat di subnet pribadi. Menggunakan tag kubernetes.io/role/internal-elb subnet untuk membangun penyeimbang beban internal. Mengakses titik akhir cluster Anda akan memerlukan koneksi VPN. Anda harus mengaktifkan AWS PrivateLink untuk EC2 dan semua repositori Amazon ECR dan S3. Hanya titik akhir pribadi cluster yang harus diaktifkan. Kami menyarankan untuk memeriksa persyaratan klaster pribadi EKS sebelum menyediakan cluster pribadi.
Komunikasi di seluruh VPC
Ada banyak skenario ketika Anda memerlukan beberapa VPC dan cluster EKS terpisah yang digunakan ke VPC ini.
Anda dapat menggunakan Amazon VPC Lattice
Amazon VPC Lattice beroperasi di ruang alamat link-lokal di IPv4 dan IPv6, menyediakan konektivitas antara layanan yang mungkin memiliki alamat IPv4 yang tumpang tindih. Untuk efisiensi operasional, kami sangat menyarankan untuk menerapkan klaster dan node EKS ke rentang IP yang tidak tumpang tindih. Jika infrastruktur Anda mencakup VPC dengan rentang IP yang tumpang tindih, Anda perlu merancang jaringan Anda sesuai dengan itu. Kami menyarankan Private NAT Gateway, atau VPC CNI dalam mode jaringan khusus bersama dengan gateway transit untuk mengintegrasikan beban kerja di EKS untuk menyelesaikan tantangan CIDR yang tumpang tindih sambil mempertahankan alamat IP RFC1918 yang dapat dirutekan.
Pertimbangkan untuk menggunakan AWS PrivateLink, yang juga dikenal sebagai layanan titik akhir, jika Anda adalah penyedia layanan dan ingin berbagi layanan dan input Kubernetes Anda (baik ALB atau NLB) dengan VPC pelanggan Anda di akun terpisah.
Berbagi VPC di beberapa akun
Banyak perusahaan mengadopsi VPC Amazon bersama sebagai sarana untuk merampingkan administrasi jaringan, mengurangi biaya, dan meningkatkan keamanan di beberapa Akun AWS dalam Organisasi AWS. Mereka menggunakan AWS Resource Access Manager (RAM) untuk berbagi sumber daya AWS yang didukung dengan aman dengan Akun AWS individu, unit organisasi (OU), atau seluruh Organisasi AWS.
Anda dapat menerapkan cluster Amazon EKS, grup node terkelola, dan sumber daya AWS pendukung lainnya (seperti grup keamanan LoadBalancers, titik akhir, dll.) di Subnets VPC bersama dari Akun AWS lain menggunakan RAM AWS. Gambar di bawah ini menggambarkan contoh arsitektur tingkat tinggi. Hal ini memungkinkan tim jaringan pusat mengontrol konstruksi jaringan seperti VPC, Subnets, dll., sambil mengizinkan tim aplikasi atau platform untuk menerapkan cluster Amazon EKS di Akun AWS masing-masing. Panduan lengkap skenario ini tersedia di repositori https://github.com/aws-samples/eks-shared-subnets
Pertimbangan saat menggunakan Subnet Bersama
-
Cluster Amazon EKS dan node pekerja dapat dibuat dalam subnet bersama yang semuanya merupakan bagian dari VPC yang sama. Amazon EKS tidak mendukung pembuatan cluster di beberapa VPC.
-
Amazon EKS menggunakan AWS VPC Security Groups (SGs) untuk mengontrol lalu lintas antara bidang kontrol Kubernetes dan node pekerja cluster. Grup keamanan juga digunakan untuk mengontrol lalu lintas antara node pekerja, dan sumber daya VPC lainnya, dan alamat IP eksternal. Anda harus membuat grup keamanan ini di application/participant akun. Pastikan grup keamanan yang ingin Anda gunakan untuk pod Anda juga terletak di akun peserta. Anda dapat mengonfigurasi aturan masuk dan keluar dalam grup keamanan untuk mengizinkan lalu lintas yang diperlukan ke dan dari grup keamanan yang terletak di akun VPC Pusat.
-
Buat peran IAM dan kebijakan terkait dalam akun peserta tempat cluster Amazon EKS Anda berada. Peran dan kebijakan IAM ini sangat penting untuk memberikan izin yang diperlukan ke cluster Kubernetes yang dikelola oleh Amazon EKS, serta ke node dan pod yang berjalan di Fargate. Izin memungkinkan Amazon EKS untuk melakukan panggilan ke layanan AWS lain atas nama Anda.
-
Anda dapat mengikuti pendekatan berikut untuk mengizinkan akses lintas Akun ke sumber daya AWS seperti bucket Amazon S3, tabel Dynamodb, dll., dari pod k8s:
-
Pendekatan kebijakan berbasis sumber daya: Jika layanan AWS mendukung kebijakan sumber daya, Anda dapat menambahkan kebijakan berbasis sumber daya yang sesuai untuk mengizinkan akses lintas akun ke Peran IAM yang ditetapkan ke pod kubernetes. Dalam skenario ini, penyedia OIDC, Peran IAM, dan kebijakan izin ada di akun aplikasi. Untuk menemukan Layanan AWS yang mendukung kebijakan berbasis Sumber Daya, lihat layanan AWS yang bekerja dengan IAM dan cari layanan yang memiliki Ya di kolom Berbasis Sumber Daya.
-
Pendekatan Penyedia OIDC: Sumber daya IAM seperti Penyedia OIDC, Peran IAM, Izin, dan Kebijakan Kepercayaan akan dibuat di Akun AWS peserta lain di mana sumber daya tersebut ada. Peran-peran ini akan ditugaskan ke pod Kubernetes di akun aplikasi, sehingga mereka dapat mengakses sumber daya lintas akun. Lihat peran IAM lintas akun untuk
blog akun layanan Kubernetes untuk panduan lengkap tentang pendekatan ini.
-
-
Anda dapat menerapkan sumber daya Amazon Elastic Loadbalancer (ELB) (ALB atau NLB) untuk merutekan lalu lintas ke pod k8s baik di aplikasi maupun akun jaringan pusat. Lihat panduan Meng
ekspos Amazon EKS Pods Cross-Account Melalui Load Balancer untuk petunjuk terperinci tentang penerapan sumber daya ELB di akun jaringan pusat. Opsi ini menawarkan fleksibilitas yang ditingkatkan, karena memberikan kontrol penuh akun Jaringan Pusat atas konfigurasi keamanan sumber daya Load Balancer. -
Saat menggunakan
custom networking featureAmazon VPC CNI, Anda perlu menggunakan pemetaan ID Zona Ketersediaan (AZ) yang tercantum di akun jaringan pusat untuk membuatnya.ENIConfigHal ini disebabkan pemetaan acak AZ fisik ke nama AZ di setiap akun AWS.
Grup Keamanan
Grup keamanan mengontrol lalu lintas yang diizinkan untuk menjangkau dan meninggalkan sumber daya yang terkait dengannya. Amazon EKS menggunakan grup keamanan untuk mengelola komunikasi antara bidang kontrol dan node. Saat Anda membuat cluster, Amazon EKS membuat grup keamanan yang diberi namaeks-cluster-sg-my-cluster-uniqueID. EKS mengaitkan grup keamanan ini ke ENI terkelola dan node. Aturan default memungkinkan semua lalu lintas mengalir bebas antara cluster dan node Anda, dan memungkinkan semua lalu lintas keluar ke tujuan apa pun.
Saat Anda membuat cluster, Anda dapat menentukan grup keamanan Anda sendiri. Silakan lihat rekomendasi untuk grup keamanan saat Anda menentukan grup keamanan sendiri.
Rekomendasi
Pertimbangkan Pener Multi-AZ apan
Wilayah AWS menyediakan beberapa Availability Zone (AZ) yang terpisah secara fisik dan terisolasi, yang terhubung dengan jaringan latensi rendah, throughput tinggi, dan sangat redundan. Dengan Availability Zones, Anda dapat merancang dan mengoperasikan aplikasi yang secara otomatis gagal di antara Availability Zone tanpa gangguan. Amazon EKS sangat merekomendasikan penerapan cluster EKS ke beberapa zona ketersediaan. Harap pertimbangkan untuk menentukan subnet di setidaknya dua zona ketersediaan saat Anda membuat cluster.
Kubelet berjalan pada node secara otomatis menambahkan label ke objek node seperti. topology.kubernetes.io/region=us-west-2
Anda dapat menentukan subnet atau zona ketersediaan saat membuat node. Node ditempatkan di subnet cluster jika tidak ada subnet yang dikonfigurasi. Dukungan EKS untuk grup node terkelola secara otomatis menyebarkan node di beberapa zona ketersediaan pada kapasitas yang tersedia. Karpenter
AWS Elastic Load Balancers dikelola oleh AWS Load Balancer Controller untuk cluster Kubernetes. Ini menyediakan Application Load Balancer (ALB) untuk sumber daya masuk Kubernetes dan Network Load Balancer (NLB) untuk layanan Kubernetes tipe Loadbalancer. Pengontrol Elastic Load Balancer menggunakan tag
Menyebarkan Node ke Subnets Pribadi
VPC termasuk subnet pribadi dan publik adalah metode ideal untuk menerapkan beban kerja Kubernetes di EKS. Pertimbangkan untuk mengatur minimal dua subnet publik dan dua subnet pribadi di dua zona ketersediaan yang berbeda. Tabel rute terkait subnet publik berisi rute ke gateway internet. Pod dapat berinteraksi dengan Internet melalui gateway NAT. Subnet pribadi didukung oleh gateway internet khusus keluar di lingkungan IPv6 (EIG W).
Instantiating node di subnet pribadi menawarkan kontrol maksimal atas lalu lintas ke node dan efektif untuk sebagian besar aplikasi Kubernetes. Sumber daya masuk (seperti penyeimbang beban) dibuat instansiasi di subnet publik dan merutekan lalu lintas ke Pod yang beroperasi pada subnet pribadi.
Pertimbangkan mode pribadi saja jika Anda menuntut keamanan yang ketat dan isolasi jaringan. Dalam konfigurasi ini, tiga subnet pribadi digunakan di Zona Ketersediaan yang berbeda dalam VPC Wilayah AWS. Sumber daya yang digunakan ke subnet tidak dapat mengakses internet, internet juga tidak dapat mengakses sumber daya di subnet. Agar aplikasi Kubernetes Anda dapat mengakses layanan AWS lainnya, Anda harus mengonfigurasi titik akhir gateway PrivateLink antarmuka and/or . Anda dapat mengatur penyeimbang beban internal untuk mengarahkan lalu lintas ke Pod menggunakan AWS Load Balancer Controller. Subnet pribadi harus diberi tag (kubernetes.io/role/internal-elb: 1) agar pengontrol menyediakan penyeimbang beban. Agar node mendaftar dengan cluster, titik akhir cluster harus diatur ke mode pribadi. Silakan kunjungi panduan klaster pribadi untuk persyaratan dan pertimbangan lengkap.
Pertimbangkan Mode Publik dan Pribadi untuk Titik Akhir Cluster
Amazon EKS menawarkan mode titik akhir cluster khusus publik, publik dan swasta, dan khusus pribadi. Mode default hanya publik, namun kami sarankan mengonfigurasi titik akhir cluster dalam mode publik dan pribadi. Opsi ini memungkinkan panggilan API Kubernetes dalam VPC cluster Anda (seperti komunikasi node-to-control-plane) untuk memanfaatkan titik akhir VPC pribadi dan lalu lintas agar tetap berada di dalam VPC cluster Anda. Server API cluster Anda, di sisi lain, dapat dijangkau dari internet. Namun, kami sangat menyarankan untuk membatasi blok CIDR yang dapat menggunakan titik akhir publik. Pelajari cara mengonfigurasi akses titik akhir publik dan pribadi, termasuk membatasi blok CIDR.
Kami menyarankan titik akhir khusus pribadi ketika Anda membutuhkan keamanan dan isolasi jaringan. Sebaiknya gunakan salah satu opsi yang tercantum dalam panduan pengguna EKS untuk terhubung ke server API secara pribadi.
Konfigurasikan Grup Keamanan dengan Hati-hati
Amazon EKS mendukung penggunaan grup keamanan khusus. Setiap grup keamanan kustom harus mengizinkan komunikasi antara node dan bidang kontrol Kubernetes. Harap periksa persyaratan port dan konfigurasikan aturan secara manual ketika organisasi Anda tidak mengizinkan komunikasi terbuka.
EKS menerapkan grup keamanan kustom yang Anda berikan selama pembuatan cluster ke antarmuka terkelola (X-ENIs). Namun, itu tidak segera mengaitkannya dengan node. Saat membuat grup node, sangat disarankan untuk mengaitkan grup keamanan khusus
Kami sangat menyarankan untuk membuat grup keamanan untuk mengizinkan semua lalu lintas komunikasi antar node. Selama proses bootstrap, node memerlukan konektivitas Internet keluar untuk mengakses titik akhir cluster. Evaluasi persyaratan akses luar, seperti koneksi on-premise dan akses registri kontainer, dan tetapkan aturan dengan tepat. Sebelum memasukkan perubahan ke dalam produksi, kami sangat menyarankan agar Anda memeriksa koneksi dengan cermat di lingkungan pengembangan Anda.
Menyebarkan NAT Gateway di setiap Zona Ketersediaan
Jika Anda menerapkan node di subnet pribadi (IPv4 dan IPv6), pertimbangkan untuk membuat NAT Gateway di setiap Availability Zone (AZ) untuk memastikan arsitektur yang tidak bergantung pada zona dan mengurangi pengeluaran lintas AZ. Setiap gateway NAT di AZ diimplementasikan dengan redundansi.
