Membandingkan Kemampuan EKS untuk ACK dengan ACK yang dikelola sendiri - Amazon EKS
Perbedaan dari ACK huluJalur migrasiLangkah selanjutnya

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.

Membandingkan Kemampuan EKS untuk ACK dengan ACK yang dikelola sendiri

Kemampuan EKS untuk ACK menyediakan fungsionalitas yang sama dengan pengontrol ACK yang dikelola sendiri, tetapi dengan keunggulan operasional yang signifikan. Untuk perbandingan umum Kemampuan EKS vs solusi yang dikelola sendiri, lihatPertimbangan Kemampuan EKS. Topik ini berfokus pada perbedaan spesifik ACK.

Perbedaan dari ACK hulu

Kemampuan EKS untuk ACK didasarkan pada pengontrol ACK hulu tetapi berbeda dalam integrasi IAM.

Peran Kemampuan IAM: Kemampuan menggunakan peran IAM khusus dengan kebijakan kepercayaan yang memungkinkan prinsipal capabilities.eks.amazonaws.com layanan, bukan IRSA (Peran IAM untuk Akun Layanan). Anda dapat melampirkan kebijakan IAM langsung ke Peran Kemampuan tanpa perlu membuat atau membuat anotasi akun layanan Kubernetes atau mengonfigurasi penyedia OIDC. Praktik terbaik untuk kasus penggunaan produksi adalah mengonfigurasi izin layanan menggunakanIAMRoleSelector. Lihat Konfigurasikan izin ACK untuk detail selengkapnya.

Kompatibilitas sumber daya: Sumber daya kustom ACK bekerja secara identik dengan ACK upstream tanpa perubahan pada file YAMAL sumber daya ACK Anda. Kemampuannya menggunakan Kubernetes yang sama APIs dan CRDs, jadi alat seperti kubectl bekerja dengan cara yang sama. Semua pengontrol GA dan sumber daya dari ACK hulu didukung.

Untuk dokumentasi ACK lengkap dan panduan khusus layanan, lihat dokumentasi ACK.

Jalur migrasi

Anda dapat bermigrasi dari ACK yang dikelola sendiri ke kemampuan terkelola tanpa waktu henti:

  1. Perbarui pengontrol ACK yang dikelola sendiri kube-system untuk digunakan untuk sewa pemilihan pemimpin, misalnya:

    helm upgrade --install ack-s3-controller \
  oci://public.ecr.aws/aws-controllers-k8s/s3-chart \
  --namespace ack-system \
  --set leaderElection.namespace=kube-system

    Ini memindahkan sewa pengontrolkube-system, memungkinkan kemampuan terkelola untuk berkoordinasi dengannya.

  2. Buat kemampuan ACK di cluster Anda (lihatBuat kemampuan ACK)

  3. Kemampuan terkelola mengenali AWS sumber daya yang dikelola ACK yang ada dan mengambil alih rekonsiliasi

  4. Secara bertahap turunkan atau hapus penerapan pengontrol yang dikelola sendiri:

    helm uninstall ack-s3-controller --namespace ack-system

Pendekatan ini memungkinkan kedua pengendali untuk hidup berdampingan dengan aman selama migrasi. Kemampuan yang dikelola secara otomatis mengadopsi sumber daya yang sebelumnya dikelola oleh pengendali yang dikelola sendiri, memastikan rekonsiliasi berkelanjutan tanpa konflik.

Langkah selanjutnya