View a markdown version of this page

Membandingkan Kemampuan EKS untuk ACK dengan ACK yang dikelola sendiri - Amazon EKS
Perbedaan dari hulu ACKJalur migrasiPratinjau pengontrol dan promosi otomatisLangkah selanjutnya

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.

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 keuntungan operasional yang signifikan. Untuk perbandingan umum Kemampuan EKS vs solusi yang dikelola sendiri, lihatPertimbangan Kemampuan EKS. Topik ini berfokus pada ACK-specific perbedaan.

Perbedaan dari hulu ACK

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 mengizinkan 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.

Tag sesi: Kemampuan terkelola secara otomatis menetapkan tag sesi pada semua permintaan AWS API, memungkinkan kontrol akses dan audit yang halus. Tag termasukeks:eks-capability-arn,eks:kubernetes-namespace, daneks:kubernetes-api-group. Ini berbeda dari ACK yang dikelola sendiri, yang tidak mengatur tag ini secara default. Lihat Konfigurasikan izin ACK untuk detail tentang penggunaan tag sesi dalam kebijakan IAM.

Tag sumber daya: Kemampuan menerapkan tag default yang berbeda ke AWS sumber daya daripada ACK yang dikelola sendiri. Kemampuan menggunakan tag eks: awalan (sepertieks:kubernetes-namespace,eks:eks-capability-arn) alih-alih services.k8s.aws/ tag yang digunakan oleh ACK yang dikelola sendiri. Lihat Pertimbangan ACK untuk EKS daftar lengkap tag sumber daya default.

Kompatibilitas sumber daya: Sumber daya khusus ACK bekerja identik dengan ACK hulu tanpa perubahan pada file YAML sumber daya ACK Anda. Kemampuan menggunakan API dan CRD Kubernetes yang sama, sehingga alat seperti kubectl bekerja dengan cara yang sama. Kemampuan ini hanya mendukung pengontrol dan sumber daya yang umumnya tersedia (GA) di hulu ACK. Kemampuan tidak termasuk pengontrol yang ada di pratinjau hulu. Status pengontrol dapat berubah dari pratinjau ke GA hulu dari waktu ke waktu, dan kemampuan kemudian dapat mulai mengelolanya secara otomatis. Jika Anda menjalankan pengontrol pratinjau yang dikelola sendiri di samping kemampuan, tinjau Pratinjau pengontrol dan promosi otomatis sebelum Anda bermigrasi.

Untuk dokumentasi ACK lengkap dan panduan khusus layanan, lihat dokumentasi ACK di situs web ACK.

Jalur migrasi

Anda dapat bermigrasi dari ACK yang dikelola sendiri ke kemampuan terkelola dengan gangguan minimal pada AWS sumber daya Anda. Migrasi bergantung pada pemilihan pemimpin Kubernetes: pengontrol yang dikelola sendiri dan kemampuan bersaing untuk sewa yang sama, sehingga hanya satu dari mereka yang mendamaikan sumber daya tertentu setiap saat. Agar ini berfungsi, keduanya harus berbagi sewa di namespace yang sama. Kemampuan ini tidak secara paksa mengambil sewa dari pengontrol yang dikelola sendiri yang sedang berjalan, sehingga Anda mengontrol kapan serah terima terjadi dengan mengurangi pengontrol yang dikelola sendiri.

penting

Sebelum memulai, berikan izin Peran Kemampuan IAM yang setara dengan izin yang digunakan pengontrol yang dikelola sendiri saat ini. Kemampuan diautentikasi dengan Peran Kemampuan khusus melalui prinsip capabilities.eks.amazonaws.com layanan, bukan melalui mekanisme yang digunakan pengontrol mandiri Anda saat ini, seperti IRSA atau EKS Pod Identity (lihat). Konfigurasikan izin ACK Jika Peran Kemampuan tidak memiliki izin, kemampuan mengadopsi sumber daya Anda. Kemudian gagal untuk merekonsiliasi mereka dan mencatat AccessDenied kesalahan.

Selesaikan langkah-langkah berikut untuk bermigrasi. Langkah-langkah menggunakan pengontrol S3 (ack-s3-controller) sebagai contoh. Ulangi untuk setiap pengontrol ACK yang dikelola sendiri yang ingin Anda migrasikan ke kemampuan, ganti nama pengontrol yang sesuai dan bagan Helm.

catatan

Menjalankan pengontrol yang dikelola sendiri di samping kemampuan dimaksudkan sebagai status sementara selama migrasi, bukan sebagai konfigurasi jangka panjang. Sementara keduanya berjalan, gangguan di kedua sisi (seperti penyebaran kemampuan atau peningkatan pengontrol yang dikelola sendiri) dapat melepaskan sewa dan membiarkan pihak lain mendapatkannya, menyebabkan rekonsiliasi beralih secara tak terduga di antara mereka. Selesaikan migrasi untuk setiap pengontrol alih-alih menjalankannya dikelola sendiri bersama kemampuan tanpa batas waktu.

  1. Aktifkan pemilihan pemimpin pada pengontrol ACK yang dikelola sendiri dan pindahkan sewa ke: kube-system

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

    Anda harus menetapkan kedua nilai tersebut. Di grafik ACK Helm, --leader-election-namespace bendera hanya diterapkan ketika leaderElection.enabled adatrue, dan pemilihan pemimpin dinonaktifkan secara default. Pengaturan leaderElection.namespace saja tidak berpengaruh. Pengontrol terus berjalan tanpa sewa, dan kedua pengontrol merekonsiliasi sumber daya yang sama pada saat yang sama setelah kemampuan dibuat. Ini berlaku untuk setiap bagan pengontrol layanan ACK, tidak hanya S3.

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

  2. Buat kemampuan ACK pada cluster Anda (lihatBuat kemampuan ACK). Kemampuan dimulai dan bersaing untuk sewa, tetapi pengontrol yang dikelola sendiri masih menahannya. Pengontrol mandiri Anda terus merekonsiliasi sumber daya Anda, dan kemampuan menunggu kepemimpinan daripada memaksa pengambilalihan.

  3. Saat Anda siap untuk memulai migrasi, skala pengontrol yang dikelola sendiri hingga nol replika. Ini melepaskan sewa sehingga kemampuan dapat memperoleh kepemimpinan dan mengambil alih rekonsiliasi:

    kubectl scale deployment ack-s3-controller \
  --namespace ack-system --replicas=0

    Setelah Anda menurunkan skala pengontrol yang dikelola sendiri, kemampuan memperoleh sewa dan memulai rekonsiliasi, biasanya dalam waktu singkat. Menskalakan kembali pengontrol yang dikelola sendiri tidak mengembalikan sewa ke sana, karena kemampuan terus menahan dan memperbarui sewa. Untuk mengembalikan rekonsiliasi ke pengontrol yang dikelola sendiri, skalakan kembali ke setidaknya satu replika dan kemudian hapus kemampuan ACK. Setelah Anda menghapus kemampuan, pengontrol yang dikelola sendiri memperoleh kembali sewa dan melanjutkan rekonsiliasi.

    Pada adopsi, kemampuan menerapkan tag sumber daya defaultnya sendiri (aw eks: alan) sebagai pengganti services.k8s.aws/ tag yang digunakan oleh ACK yang dikelola sendiri (lihatPertimbangan ACK untuk EKS). Harapkan serangkaian panggilan API penandaan satu kali terhadap sumber daya yang Anda adopsi, dan perbarui alokasi biaya atau alat kebijakan apa pun yang dikunci pada awalan tag. services.k8s.aws/

  4. Pastikan kemampuan itu sehat dan telah mengambil alih rekonsiliasi sumber daya Anda. Konfirmasikan bahwa sumber daya melaporkan Synced kondisi True dan bahwa kemampuan tidak mencatat AccessDenied kesalahan.

  5. Setelah Anda mengonfirmasi kemampuan mengelola sumber daya Anda dengan benar, hapus pengontrol yang dikelola sendiri:

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

Pendekatan ini memungkinkan kedua pengontrol untuk hidup berdampingan dengan aman selama migrasi. Kemampuan terkelola mengadopsi sumber daya yang sebelumnya dikelola oleh pengontrol yang dikelola sendiri setelah Anda melepaskan sewa, memastikan rekonsiliasi berkelanjutan tanpa konflik.

Pratinjau pengontrol dan promosi otomatis

Kemampuan ini hanya mendukung pengontrol yang GA di hulu ACK. Pengontrol yang ada di pratinjau hari ini dapat dipromosikan ke GA hulu nanti. Ketika itu terjadi, kemampuan mulai mengelola pengontrol itu secara otomatis, tanpa tindakan apa pun dari pihak Anda.

Ini menciptakan risiko jika Anda menjalankan pengontrol pratinjau yang dikelola sendiri pada cluster yang juga menggunakan kemampuan untuk pengontrol lain. Anda dapat menjalankan pengontrol pratinjau sebagai replika tunggal dengan pemilihan pemimpin dinonaktifkan, karena tidak ada pengontrol lain untuk berkoordinasi. Ketika pengontrol itu dipromosikan ke GA, kemampuan mulai mengelolanya. Pada saat itu, dua rekonsilier bertindak pada sumber daya yang sama tanpa sewa bersama untuk mengoordinasikannya. Hasilnya adalah konflik rekonsiliasi ganda yang sama yang dirancang untuk dicegah oleh langkah-langkah migrasi. Kedua rekonsilier mengeluarkan panggilan AWS API yang bersaing dan menulis pembaruan yang bertentangan ke status sumber daya khusus.

Untuk menghindari hal ini, sebelum Anda menjalankan pengontrol pratinjau yang dikelola sendiri di samping kemampuan:

  • Aktifkan pemilihan pemimpin pada pengontrol pratinjau yang dikelola sendiri dan arahkan leasannya kekube-system, menggunakan leaderElection.namespace=kube-system pengaturan yang sama leaderElection.enabled=true dan yang ditunjukkan pada langkah migrasi. Ini memastikan bahwa jika pengontrol dipromosikan dan kemampuan mengambil alih, keduanya berkoordinasi melalui sewa bersama daripada rekonsiliasi secara paralel.

  • Lacak status GA hulu dari setiap pengontrol pratinjau yang Anda andalkan, dan rencanakan untuk memigrasinya mengikuti jalur migrasi saat dipromosikan. Anda dapat memeriksa status saat ini dari setiap pengontrol di halaman layanan ACK di situs web ACK.

Langkah selanjutnya