Bantu tingkatkan 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 Edit halaman ini pada GitHub tautan 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.

Pertimbangan Kemampuan EKS

Topik ini mencakup pertimbangan penting untuk menggunakan Kemampuan EKS, termasuk desain kontrol akses, pemilihan antara Kemampuan EKS dan solusi yang dikelola sendiri, pola arsitektur untuk penerapan multi-cluster, dan praktik terbaik operasional.

Kemampuan peran IAM dan Kubernetes RBAC

Setiap sumber daya kemampuan EKS memiliki peran IAM kemampuan yang dikonfigurasi. Peran kapabilitas digunakan untuk memberikan izin AWS layanan untuk kemampuan EKS untuk bertindak atas nama Anda. Misalnya, untuk menggunakan Kemampuan EKS untuk ACK untuk mengelola Bucket Amazon S3, Anda akan memberikan izin administratif Bucket S3 ke kemampuan tersebut, memungkinkannya membuat dan mengelola bucket.

Setelah kemampuan dikonfigurasi, sumber daya S3 di AWS dapat dibuat dan dikelola dengan sumber daya kustom Kubernetes di klaster Anda. Kubernetes RBAC adalah mekanisme kontrol akses in-cluster untuk menentukan pengguna dan grup mana yang dapat membuat dan mengelola sumber daya kustom tersebut. Misalnya, berikan izin pengguna dan grup Kubernetes RBAC tertentu untuk membuat dan mengelola Bucket sumber daya di ruang nama yang Anda pilih.

Dengan cara ini, IAM dan Kubernetes RBAC adalah dua bagian dari sistem kontrol end-to-end akses yang mengatur izin yang terkait dengan Kemampuan dan sumber daya EKS. Penting untuk merancang kombinasi izin IAM dan kebijakan akses RBAC yang tepat untuk kasus penggunaan Anda.

Untuk informasi tambahan tentang peran IAM kemampuan dan izin Kubernetes, lihat. Pertimbangan keamanan untuk Kemampuan EKS

Pola arsitektur multi-cluster

Saat menerapkan kemampuan di beberapa cluster, pertimbangkan pola arsitektur umum ini:

Hub dan Berbicara dengan manajemen terpusat

Jalankan ketiga kemampuan dalam klaster yang dikelola secara terpusat untuk mengatur beban kerja dan mengelola infrastruktur cloud di beberapa klaster beban kerja.

Pola ini memusatkan beban kerja dan manajemen infrastruktur cloud, dan dapat menyederhanakan operasi untuk organisasi yang mengelola banyak cluster.

Terdesentralisasi GitOps

Beban kerja dan infrastruktur cloud dikelola oleh kapabilitas pada klaster yang sama tempat beban kerja berjalan.

Pola ini mendesentralisasi operasi, dengan tim mengelola layanan platform khusus mereka sendiri dalam satu atau lebih cluster.

Hub dan Berbicara dengan Penyebaran ACK Hybrid

Menggabungkan model terpusat dan terdesentralisasi, dengan penerapan aplikasi terpusat dan manajemen sumber daya berdasarkan ruang lingkup dan kepemilikan.

Pola ini memisahkan keprihatinan—tim platform mengelola infrastruktur penting secara terpusat pada kluster manajemen, secara opsional termasuk klaster beban kerja, sementara tim aplikasi menentukan dan mengelola sumber daya cloud di samping beban kerja.

Memilih Pola

Pertimbangkan faktor-faktor ini ketika memilih arsitektur:

Membandingkan Kemampuan EKS dengan solusi yang dikelola sendiri

Kemampuan EKS memberikan pengalaman yang dikelola sepenuhnya untuk alat dan pengontrol Kubernetes populer yang berjalan di EKS. Ini berbeda dari solusi yang dikelola sendiri, yang Anda instal dan operasikan di cluster Anda.

Perbedaan Utama

Penerapan dan manajemen

AWS sepenuhnya mengelola Kemampuan EKS tanpa instalasi, konfigurasi, atau pemeliharaan perangkat lunak komponen yang diperlukan. AWS menginstal dan mengelola semua Kubernetes Custom Resource Definitions (CRDs) yang diperlukan di cluster secara otomatis.

Dengan solusi yang dikelola sendiri, Anda menginstal dan mengonfigurasi perangkat lunak klaster menggunakan bagan Helm, kubectl, atau operator lain. Anda memiliki kontrol penuh atas siklus hidup perangkat lunak dan konfigurasi runtime dari solusi yang dikelola sendiri, memberikan penyesuaian pada setiap lapisan solusi.

Operasi dan pemeliharaan

AWS mengelola patching dan operasi siklus hidup perangkat lunak lainnya untuk Kemampuan EKS, dengan pembaruan otomatis dan patch keamanan. Kemampuan EKS terintegrasi dengan AWS fitur untuk konfigurasi yang efisien, menyediakan ketersediaan tinggi bawaan dan toleransi kesalahan, dan menghilangkan pemecahan masalah beban kerja pengontrol dalam klaster.

Solusi yang dikelola sendiri mengharuskan Anda untuk memantau kesehatan komponen dan log, menerapkan patch keamanan dan pembaruan versi, mengonfigurasi ketersediaan tinggi dengan beberapa replika dan anggaran gangguan pod, memecahkan masalah dan memulihkan masalah beban kerja pengontrol, dan mengelola rilis dan versi. Anda memiliki kontrol penuh atas penerapan Anda, tetapi ini sering memerlukan solusi yang dipesan lebih dahulu untuk akses klaster pribadi dan integrasi lainnya yang harus selaras dengan standar organisasi dan persyaratan kepatuhan keamanan.

Konsumsi sumber daya

Kemampuan EKS berjalan di EKS dan di luar cluster Anda, membebaskan sumber daya node dan sumber daya cluster. Kemampuan tidak menggunakan sumber daya beban kerja klaster, tidak menggunakan CPU atau memori pada node pekerja Anda, menskalakan secara otomatis, dan berdampak minimal pada perencanaan kapasitas klaster.

Solusi yang dikelola sendiri menjalankan pengontrol dan komponen lain di node pekerja Anda, secara langsung mengkonsumsi sumber daya node pekerja, cluster IPs, dan sumber daya klaster lainnya. Mengelola layanan klaster memerlukan perencanaan kapasitas untuk beban kerja mereka, dan memerlukan perencanaan dan konfigurasi permintaan dan batasan sumber daya untuk mengelola persyaratan penskalaan dan ketersediaan tinggi.

Dukungan fitur

Sebagai fitur layanan yang dikelola sepenuhnya, Kemampuan EKS pada dasarnya berpendirian dibandingkan dengan solusi yang dikelola sendiri. Sementara kemampuan akan mendukung sebagian besar fitur dan kasus penggunaan, akan ada perbedaan dalam cakupan jika dibandingkan dengan solusi yang dikelola sendiri.

Dengan solusi yang dikelola sendiri, Anda sepenuhnya mengontrol konfigurasi, fitur opsional, dan aspek fungsionalitas lainnya untuk perangkat lunak Anda. Anda dapat memilih untuk menjalankan gambar kustom Anda sendiri, menyesuaikan semua aspek konfigurasi, dan sepenuhnya mengontrol fungsionalitas solusi yang dikelola sendiri.

Pertimbangan Biaya

Setiap sumber daya kemampuan EKS memiliki biaya per jam terkait, yang berbeda berdasarkan jenis kemampuan. Sumber daya cluster yang dikelola oleh kapabilitas juga memiliki biaya per jam terkait dengan harga mereka sendiri. Untuk informasi selengkapnya, lihat harga Amazon EKS.

Solusi yang dikelola sendiri tidak memiliki biaya langsung yang terkait dengan AWS biaya, tetapi Anda membayar sumber daya komputasi klaster yang digunakan oleh pengontrol dan beban kerja terkait. Di luar konsumsi sumber daya node dan cluster, biaya kepemilikan penuh dengan solusi yang dikelola sendiri mencakup overhead operasional dan biaya pemeliharaan, pemecahan masalah, dan dukungan.

Memilih antara Kemampuan EKS dan solusi yang dikelola sendiri

Kemampuan EKS Pertimbangkan pilihan ini ketika Anda ingin mengurangi overhead operasional dan fokus pada nilai yang berbeda dalam perangkat lunak dan sistem Anda, daripada operasi platform cluster untuk persyaratan dasar. Gunakan Kemampuan EKS saat Anda ingin meminimalkan beban operasional patch keamanan dan manajemen siklus hidup perangkat lunak, membebaskan sumber daya node dan cluster untuk beban kerja aplikasi, menyederhanakan konfigurasi dan manajemen keamanan, dan manfaatkan cakupan dukungan. AWS Kemampuan EKS ideal untuk sebagian besar kasus penggunaan produksi dan merupakan pendekatan yang direkomendasikan untuk penerapan baru.

Solusi yang dikelola sendiri Pertimbangkan pilihan ini ketika Anda memerlukan versi API sumber daya Kubernetes tertentu, build pengontrol khusus, memiliki otomatisasi dan perkakas yang ada di sekitar penerapan yang dikelola sendiri, atau memerlukan kustomisasi mendalam konfigurasi runtime pengontrol. Solusi yang dikelola sendiri memberikan fleksibilitas untuk kasus penggunaan khusus, dan Anda memiliki kendali penuh atas konfigurasi penerapan dan runtime Anda.

Perbandingan Khusus Kemampuan

Untuk perbandingan terperinci termasuk fitur khusus kemampuan, perbedaan hulu, dan jalur migrasi, lihat: