Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
VPCdan Pertimbangan Subnet
Mengoperasikan EKS klaster membutuhkan pengetahuan tentang AWS VPC jaringan, selain jaringan Kubernetes.
Kami menyarankan Anda memahami mekanisme komunikasi pesawat EKS kontrol sebelum Anda mulai merancang VPC atau menyebarkan cluster ke dalam yang sudah ada. VPCs
Lihat VPCpertimbangan Cluster dan pertimbangan grup EKS keamanan Amazon saat merancang VPC dan subnet yang akan digunakan. EKS
Gambaran Umum
EKSArsitektur Cluster
Sebuah EKS cluster terdiri dari duaVPCs:
-
Sebuah AWS -managed VPC yang menjadi tuan rumah pesawat kontrol Kubernetes. Ini VPC tidak muncul di akun pelanggan.
-
Dikelola pelanggan yang menghosting VPC node Kubernetes. Di sinilah kontainer berjalan, serta AWS infrastruktur yang dikelola pelanggan lainnya seperti penyeimbang beban yang digunakan oleh cluster. Ini VPC muncul di akun pelanggan. Anda perlu membuat yang dikelola pelanggan VPC sebelum membuat cluster. Eksctl menciptakan a VPC jika Anda tidak menyediakannya.
Node di pelanggan VPC membutuhkan kemampuan untuk terhubung ke endpoint API server yang dikelola di. AWS VPC Hal ini memungkinkan node untuk mendaftar dengan control plane Kubernetes dan menerima permintaan untuk menjalankan Pod aplikasi.
Node terhubung ke bidang EKS kontrol melalui (a) titik akhir EKS publik atau (b) antarmuka jaringan elastis Cross-Account (X-ENI) yang dikelola oleh. EKS Ketika sebuah cluster dibuat, Anda perlu menentukan setidaknya dua VPC subnet. EKSmenempatkan X- ENI di setiap subnet yang ditentukan selama pembuatan cluster (juga disebut subnet cluster). APIServer Kubernetes menggunakan Cross-Account ini ENIs untuk berkomunikasi dengan node yang digunakan pada subnet cluster yang dikelola pelanggan. VPC
Saat node dimulai, skrip EKS bootstrap 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 sebuah node, Kubelet menghubungi titik akhir klaster Kubernetes. Ini membangun koneksi dengan titik akhir publik di luar VPC atau titik akhir pribadi di dalam. VPC Kubelet menerima API instruksi dan memberikan pembaruan status dan detak jantung ke titik akhir secara teratur.
EKSKontrol Komunikasi Pesawat
EKSmemiliki dua cara untuk mengontrol akses ke titik akhir cluster. Kontrol akses endpoint memungkinkan Anda memilih apakah titik akhir dapat dijangkau dari internet publik atau hanya melalui Anda. VPC Anda dapat mengaktifkan titik akhir publik (yang merupakan default), titik akhir pribadi, atau keduanya sekaligus.
Konfigurasi API titik akhir cluster menentukan jalur yang diambil node untuk berkomunikasi dengan bidang kontrol. Perhatikan bahwa pengaturan titik akhir ini dapat diubah kapan saja melalui EKS konsol atauAPI.
Titik Akhir Publik
Ini adalah perilaku default untuk EKS cluster Amazon baru. Ketika hanya titik akhir publik untuk klaster yang diaktifkan, API permintaan Kubernetes yang berasal dari dalam klaster Anda VPC (seperti node pekerja untuk mengontrol komunikasi pesawat) meninggalkan jaringan AmazonVPC, tetapi bukan jaringan Amazon. Agar node dapat terhubung ke bidang kontrol, mereka harus memiliki alamat IP publik dan rute ke gateway internet atau rute ke NAT gateway di mana mereka dapat menggunakan alamat IP publik NAT gateway.
Titik Akhir Publik dan Swasta
Ketika titik akhir publik dan pribadi diaktifkan, Kubernetes API meminta dari dalam VPC komunikasi ke pesawat kontrol melalui X- di dalam Anda. ENIs VPC APIServer cluster Anda dapat diakses dari internet.
Titik Akhir Pribadi
Tidak ada akses publik ke API server Anda dari internet ketika hanya titik akhir pribadi yang diaktifkan. Semua lalu lintas ke API server cluster Anda harus berasal dari dalam kluster Anda VPC atau jaringan yang terhubung. Node berkomunikasi ke API server melalui X- ENIs di dalam AndaVPC. Perhatikan bahwa alat manajemen klaster harus memiliki akses ke titik akhir pribadi. Pelajari lebih lanjut cara menyambung ke titik akhir EKS klaster Amazon pribadi dari luar Amazon VPC
Perhatikan bahwa titik akhir API server cluster diselesaikan oleh DNS server publik ke alamat IP pribadi dariVPC. Di masa lalu, titik akhir hanya bisa diselesaikan dari dalam. VPC
VPCkonfigurasi
Amazon VPC mendukung IPv4 dan IPv6 menangani. Amazon EKS mendukung secara IPv4 default. A VPC harus memiliki IPv4 CIDR blok 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 yang baruVPC, Anda dapat melampirkan satu IPv6 CIDR blok, dan hingga lima saat mengubah yang sudah adaVPC. Panjang awalan ukuran IPv6 CIDR blok bisa antara /44 dan /60 dan untuk IPv6 subnet bisa antara/44/ dan /64. Anda dapat meminta IPv6 CIDR blok dari kumpulan IPv6 alamat yang dikelola oleh Amazon. Silakan merujuk ke bagian VPCCIDRblok dari Panduan VPC Pengguna untuk informasi lebih lanjut.
EKSCluster Amazon mendukung keduanya IPv4 danIPv6. Secara default, EKS cluster menggunakan IPv4 IP. Menentukan IPv6 pada waktu pembuatan cluster akan memungkinkan IPv6 cluster penggunaan. IPv6cluster membutuhkan dual-stack VPCs dan subnet.
Amazon EKS menyarankan Anda menggunakan setidaknya dua subnet yang berada di Availability Zone berbeda selama pembuatan klaster. Subnet yang Anda lewati selama pembuatan cluster dikenal sebagai subnet cluster. Saat Anda membuat klaster, Amazon EKS membuat hingga 4 akun silang (x-account atau x-ENIs) ENIs di subnet yang Anda tentukan. X- selalu ENIs digunakan dan digunakan untuk lalu lintas administrasi cluster seperti pengiriman log, exec, dan proxy. Silakan merujuk ke panduan EKS pengguna untuk detail persyaratan lengkap VPC dan subnet.
Node pekerja Kubernetes dapat berjalan di subnet cluster, tetapi tidak disarankan. Selama upgrade klaster Amazon EKS menyediakan tambahan ENIs dalam subnet cluster. Saat klaster Anda keluar, node dan pod pekerja dapat menggunakan yang tersedia IPs di subnet klaster. Oleh karena itu untuk memastikan ada cukup tersedia, IPs 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 dalam subnet dirutekan melalui gateway internet. 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 jalan keluar. Node dengan alamat IP publik atau elastis (EIPs) dalam subnet yang dikonfigurasi dengan gateway internet memungkinkan masuknya dari luar. VPC Subnet pribadi biasanya memiliki routing ke NATgateway, yang tidak memungkinkan masuknya lalu lintas ke node di subnet dari luar VPC sementara masih memungkinkan lalu lintas dari node untuk meninggalkan (jalan keluar). VPC
Di IPv6 dunia, setiap alamat dapat dirutekan melalui internet. IPv6Alamat yang terkait dengan node dan pod bersifat publik. Subnet pribadi didukung dengan menerapkan gateway internet egress-only (EIGW) di aVPC, memungkinkan lalu lintas keluar sambil memblokir semua lalu lintas masuk. Praktik terbaik untuk menerapkan IPv6 subnet dapat ditemukan di panduan VPC pengguna.
Anda dapat mengkonfigurasi VPC dan Subnet dalam tiga cara berbeda:
Hanya menggunakan subnet publik
Dalam subnet publik yang sama, node dan sumber daya ingress (seperti penyeimbang beban) dibuat. Tandai subnet publik kubernetes.io/role/elb
Menggunakan subnet pribadi dan publik
Node dibuat pada subnet pribadi, sedangkan sumber daya Ingress dipakai 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 NAT gateway atau. ENI
Hanya menggunakan subnet pribadi
Kedua node dan ingress dibuat dalam subnet pribadi. Menggunakan tag kubernetes.io/role/internal-elb
Komunikasi lintas VPCs
Ada banyak skenario ketika Anda memerlukan beberapa VPCs dan EKS kluster terpisah yang digunakan untuk ini. VPCs
Anda dapat menggunakan Amazon VPC Lattice
Amazon VPC Lattice beroperasi di ruang alamat link-lokal di IPv4 danIPv6, menyediakan konektivitas antar layanan yang mungkin memiliki alamat yang tumpang tindih. IPv4 Untuk efisiensi operasional, kami sangat menyarankan untuk menyebarkan EKS cluster dan node ke rentang IP yang tidak tumpang tindih. Jika infrastruktur Anda mencakup rentang IP VPCs 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 EKS untuk memecahkan CIDR tantangan yang tumpang tindih sambil mempertahankan alamat IP yang dapat dirutekan. RFC1918
Pertimbangkan untuk menggunakan AWS PrivateLink, juga dikenal sebagai layanan endpoint, jika Anda adalah penyedia layanan dan ingin berbagi layanan Kubernetes dan ingress Anda (baik ALB atauNLB) dengan pelanggan Anda di akun terpisah. VPC
Berbagi VPC di beberapa akun
Banyak perusahaan mengadopsi Amazon bersama VPCs sebagai sarana untuk merampingkan administrasi jaringan, mengurangi biaya, dan meningkatkan keamanan di beberapa AWS Akun dalam suatu AWS Organisasi. Mereka menggunakan AWS Resource Access Manager (RAM) untuk berbagi AWSsumber daya yang didukung secara aman dengan AWS Akun individu, unit organisasi (OUs) atau seluruh AWS Organisasi.
Anda dapat menerapkan EKS kluster Amazon, grup node terkelola, dan AWS sumber daya pendukung lainnya (seperti LoadBalancers, grup keamanan, titik akhir, dll.) di VPC Subnet bersama dari Akun lain AWS menggunakan. AWS RAM Gambar di bawah ini menggambarkan contoh arsitektur tingkat tinggi. Hal ini memungkinkan tim jaringan pusat mengontrol konstruksi jaringan sepertiVPCs, Subnet, dll., sambil memungkinkan tim aplikasi atau platform untuk menyebarkan kluster EKS Amazon di Akun masing-masing. AWS Panduan lengkap dari skenario ini tersedia di repositori github
Pertimbangan saat menggunakan Subnet Bersama
-
EKSCluster Amazon dan node pekerja dapat dibuat dalam subnet bersama yang semuanya merupakan bagian dari yang sama. VPC Amazon EKS tidak mendukung pembuatan cluster di beberapaVPCs.
-
Amazon EKS menggunakan AWS VPC Security Groups (SGs) untuk mengontrol lalu lintas antara bidang kontrol Kubernetes dan node pekerja klaster. Grup keamanan juga digunakan untuk mengontrol lalu lintas antara node pekerja, dan VPC sumber daya lainnya, dan alamat IP eksternal. Anda harus membuat grup keamanan ini di akun aplikasi/peserta. Pastikan bahwa grup keamanan yang ingin Anda gunakan untuk pod Anda juga berada di akun peserta. Anda dapat mengonfigurasi aturan masuk dan keluar dalam grup keamanan Anda untuk mengizinkan lalu lintas yang diperlukan ke dan dari grup keamanan yang terletak di akun PusatVPC.
-
Buat IAM peran dan kebijakan terkait dalam akun peserta tempat EKS klaster Amazon Anda berada. IAMPeran dan kebijakan ini sangat penting untuk memberikan izin yang diperlukan untuk klaster Kubernetes yang dikelola oleh AmazonEKS, serta node dan pod yang berjalan di Fargate. Izin memungkinkan Amazon EKS melakukan panggilan ke AWS layanan lain atas nama Anda.
-
Anda dapat mengikuti pendekatan berikut untuk mengizinkan akses lintas Akun ke AWS sumber daya seperti bucket Amazon S3, tabel Dynamodb, dll., Dari pod k8s:
-
Pendekatan kebijakan berbasis sumber daya: Jika AWS layanan mendukung kebijakan sumber daya, Anda dapat menambahkan kebijakan berbasis sumber daya yang sesuai untuk mengizinkan akses lintas akun ke IAM Peran yang ditetapkan ke pod kubernetes. Dalam skenario ini, OIDC penyedia, IAM Peran, dan kebijakan izin ada di akun aplikasi. Untuk menemukan AWS Layanan yang mendukung kebijakan berbasis Sumber Daya, rujuk AWSlayanan yang bekerja dengan IAM dan cari layanan yang memiliki Ya di kolom Berbasis Sumber Daya.
-
OIDCPendekatan penyedia: IAM sumber daya seperti kebijakan OIDC Penyedia, IAM Peran, Izin, dan Kepercayaan akan dibuat di AWS Akun peserta lain di mana sumber daya ada. Peran ini akan ditetapkan ke pod Kubernetes di akun aplikasi, sehingga mereka dapat mengakses sumber daya lintas akun. Lihat IAMperan Cross account untuk blog akun layanan Kubernetes
untuk panduan lengkap tentang pendekatan ini.
-
-
Anda dapat menerapkan resource Amazon Elastic Loadbalancer (ELB) (ALBatauNLB) untuk merutekan lalu lintas ke pod k8s baik di aplikasi maupun akun jaringan pusat. Lihat panduan Ekspos EKS Pod Amazon Melalui Load Balancer Lintas Akun
untuk petunjuk terperinci tentang penerapan ELB sumber daya di akun jaringan pusat. Opsi ini menawarkan fleksibilitas yang ditingkatkan, karena memberikan akun Central Networking kontrol penuh atas konfigurasi keamanan sumber daya Load Balancer. -
Saat menggunakan
custom networking featureAmazon VPCCNI, Anda perlu menggunakan pemetaan ID Availability Zone (AZ) yang tercantum di akun jaringan pusat untuk membuatnya.ENIConfigIni karena pemetaan acak fisik AZs ke nama AZ di setiap AWS akun.
Grup Keamanan
Grup keamanan mengontrol lalu lintas yang diizinkan untuk mencapai dan meninggalkan sumber daya yang terkait dengannya. Amazon EKS menggunakan grup keamanan untuk mengelola komunikasi antara bidang kontrol dan node. Saat Anda membuat klaster, Amazon EKS membuat grup keamanan yang diberi namaeks-cluster-sg-my-cluster-uniqueID. EKSmengaitkan kelompok keamanan ini ke yang dikelola ENIs dan node. Aturan default memungkinkan semua lalu lintas mengalir bebas antara cluster dan node Anda, dan memungkinkan semua lalu lintas keluar ke tujuan mana pun.
Saat membuat klaster, Anda dapat menentukan grup keamanan Anda sendiri. Silakan lihat rekomendasi untuk grup keamanan saat Anda menentukan grup keamanan sendiri.
Rekomendasi
Pertimbangkan Penerapan Multi-AZ
AWSWilayah menyediakan beberapa Availability Zone (AZ) yang terpisah secara fisik dan terisolasi, yang terhubung dengan latensi rendah, throughput tinggi, dan jaringan yang sangat redundan. Dengan Availability Zones, Anda dapat merancang dan mengoperasikan aplikasi yang secara otomatis gagal di antara Availability Zones tanpa gangguan. Amazon EKS sangat menyarankan untuk menerapkan EKS cluster ke beberapa zona ketersediaan. Harap pertimbangkan untuk menentukan subnet di setidaknya dua zona ketersediaan saat Anda membuat cluster.
Kubelet yang 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 Anda membuat node. Node ditempatkan di subnet cluster jika tidak ada subnet yang dikonfigurasi. EKSdukungan untuk grup node terkelola secara otomatis menyebarkan node di beberapa zona ketersediaan pada kapasitas yang tersedia. Karpenter
AWSElastic Load Balancer dikelola oleh Load AWS Balancer Controller untuk klaster Kubernetes. Ini menyediakan Application Load Balancer (ALB) untuk sumber daya ingress Kubernetes dan Network Load Balancer (NLB) untuk layanan Kubernetes tipe Loadbalancer. Pengontrol Elastic Load Balancer menggunakan tag
Menyebarkan Node ke Subnet Pribadi
VPCTermasuk subnet pribadi dan publik adalah metode ideal untuk menerapkan beban kerja Kubernetes. EKS Pertimbangkan untuk menetapkan minimal dua subnet publik dan dua subnet pribadi dalam dua zona ketersediaan yang berbeda. Tabel rute terkait subnet publik berisi rute ke gateway internet. Pod dapat berinteraksi dengan Internet melalui NAT gateway. Subnet pribadi didukung oleh gateway internet khusus egres di lingkungan (). IPv6 EIGW
Membuat instantiasi node dalam subnet pribadi menawarkan kontrol maksimal atas lalu lintas ke node dan efektif untuk sebagian besar aplikasi Kubernetes. Sumber daya masuk (seperti penyeimbang beban) dipakai di subnet publik dan mengarahkan 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 Availability Zone yang berbeda dalam AWS Region. VPC Sumber daya yang dikerahkan ke subnet tidak dapat mengakses internet, internet juga tidak dapat mengakses sumber daya dalam subnet. Agar aplikasi Kubernetes Anda dapat mengakses AWS layanan lain, Anda harus mengonfigurasi PrivateLink antarmuka dan/atau titik akhir gateway. Anda dapat mengatur load balancer internal untuk mengarahkan lalu lintas ke Pod menggunakan Load Balancer AWS Controller. Subnet pribadi harus diberi tag (kubernetes.io/role/internal-elb: 1
Pertimbangkan Mode Publik dan Pribadi untuk Titik Akhir Cluster
Amazon EKS menawarkan mode titik akhir klaster khusus publik public-and-private, dan pribadi. Mode default hanya publik, namun kami menyarankan untuk mengonfigurasi titik akhir cluster dalam mode publik dan pribadi. Opsi ini memungkinkan API panggilan Kubernetes di dalam klaster Anda VPC (seperti node-to-control-plane komunikasi) untuk memanfaatkan VPC titik akhir pribadi dan lalu lintas untuk tetap berada di dalam klaster Anda. VPC APIServer cluster Anda, di sisi lain, dapat dijangkau dari internet. Namun, kami sangat menyarankan untuk membatasi CIDR blok yang dapat menggunakan titik akhir publik. Pelajari cara mengonfigurasi akses titik akhir publik dan pribadi, termasuk membatasi CIDR blok.
Kami menyarankan titik akhir khusus pribadi ketika Anda memerlukan keamanan dan isolasi jaringan. Sebaiknya gunakan salah satu opsi yang tercantum dalam panduan EKS pengguna untuk terhubung ke API server secara pribadi.
Konfigurasikan Grup Keamanan dengan Hati-hati
Amazon EKS mendukung penggunaan grup keamanan khusus. Setiap grup keamanan khusus harus mengizinkan komunikasi antara node dan bidang kontrol Kubernetes. Silakan periksa persyaratan port dan konfigurasikan aturan secara manual ketika organisasi Anda tidak mengizinkan komunikasi terbuka.
EKSmenerapkan grup keamanan kustom yang Anda berikan selama pembuatan klaster 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 membuat grup keamanan untuk memungkinkan semua lalu lintas komunikasi antar simpul. 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.
Terapkan NAT Gateway di setiap Availability Zone
Jika Anda menerapkan node di subnet pribadi (IPv4danIPv6), pertimbangkan untuk membuat NAT Gateway di setiap Availability Zone (AZ) untuk memastikan arsitektur zona independen dan mengurangi pengeluaran lintas AZ. Setiap NAT gateway di AZ diimplementasikan dengan redundansi.
Gunakan Cloud9 untuk mengakses Private Clusters
AWSCloud9 adalah IDE berbasis web yang dapat berjalan dengan aman di Private Subnet tanpa akses masuk, menggunakan Systems Manager. AWS Jalan keluar juga dapat dinonaktifkan pada instance Cloud9. Pelajari lebih lanjut cara menggunakan Cloud9 untuk mengakses kluster dan subnet pribadi.
