Migrasi dari ke dockershimcontainerd - Amazon EKS

Bantu tingkatkan halaman ini

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Ingin berkontribusi pada panduan pengguna ini? Pilih Edit halaman ini pada GitHub tautan yang terletak di panel kanan setiap halaman. Kontribusi Anda akan membantu membuat panduan pengguna kami lebih baik untuk semua orang.

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Migrasi dari ke dockershimcontainerd

Kubernetes tidak lagi mendukungdockershim. Bagian Kubernetes tim menghapus runtime di Kubernetes versi1.24. Untuk informasi selengkapnya, lihat Kubernetes Pindah Dari Dockershim: Komitmen dan Langkah Selanjutnya di Kubernetes Blog.

Amazon EKS juga mengakhiri dukungan untuk dockershim memulai dengan Kubernetes 1.24rilis versi. Amazon EKS AMIs yang diterbitkan secara resmi memiliki containerd satu-satunya runtime yang dimulai dengan versi1.24. Topik ini mencakup beberapa detail, tetapi informasi lebih lanjut tersedia di Semua yang perlu Anda ketahui tentang pindah ke containerd di Amazon EKS.

Ada kubectl plugin yang dapat Anda gunakan untuk melihat yang mana dari Anda Kubernetes beban kerja memasang Docker volume soket. Untuk informasi selengkapnya, lihat Detector for Docker Socket (DDS) di GitHub. Amazon EKS AMIs yang berjalan Kubernetes versi yang lebih awal dari 1.24 penggunaan Docker sebagai runtime default. Namun, Amazon EKS ini AMIs memiliki opsi flag bootstrap yang dapat Anda gunakan untuk menguji beban kerja Anda pada klaster yang didukung. containerd Untuk informasi selengkapnya, lihat Uji migrasi Amazon Linux 2 dari Docker untuk containerd.

Kami akan terus mempublikasikan AMIs untuk yang sudah ada Kubernetes versi hingga akhir tanggal dukungan mereka. Untuk informasi selengkapnya, lihat Amazon EKS Kubernetes rilis kalender. Jika Anda memerlukan lebih banyak waktu untuk menguji beban kerjacontainerd, gunakan versi yang didukung sebelumnya1.24. Namun, ketika Anda ingin memutakhirkan Amazon EKS resmi AMIs ke versi 1.24 atau yang lebih baru, pastikan untuk memvalidasi bahwa beban kerja Anda berjalan. containerd

containerdRuntime memberikan kinerja dan keamanan yang lebih andal. containerdadalah runtime yang sedang distandarisasi di seluruh Amazon EKS. Fargate dan Bottlerocket sudah digunakan containerd saja. containerdmembantu meminimalkan jumlah rilis Amazon EKS AMI yang diperlukan untuk mengatasi Kerentanan dockershim Umum dan Eksposur ()CVEs. Karena dockershim sudah menggunakan containerd secara internal, Anda mungkin tidak perlu melakukan perubahan apa pun. Namun, ada beberapa situasi di mana perubahan mungkin atau harus diperlukan:

  • Anda harus membuat perubahan pada aplikasi yang memasang Docker soket. Misalnya, gambar kontainer yang dibuat dengan wadah terpengaruh. Banyak alat pemantauan juga memasang Docker soket. Anda mungkin perlu menunggu pembaruan atau menerapkan kembali beban kerja untuk pemantauan runtime.

  • Anda mungkin perlu membuat perubahan untuk aplikasi yang bergantung pada spesifik Docker pengaturan. Misalnya, HTTPS_PROXY protokol tidak lagi didukung. Anda harus memperbarui aplikasi yang menggunakan protokol ini. Untuk informasi lebih lanjut, lihat dockerd di Docker Dokumentasi.

  • Jika Anda menggunakan pembantu kredensi Amazon ECR untuk menarik gambar, Anda harus beralih ke penyedia kredensi kubelet gambar. Untuk informasi selengkapnya, lihat Mengonfigurasi penyedia kredensi gambar kubelet di Kubernetes dokumentasi.

  • Karena Amazon EKS 1.24 tidak lagi mendukung Docker, beberapa flag yang sebelumnya didukung skrip bootstrap Amazon EKS tidak lagi didukung. Sebelum pindah ke Amazon EKS 1.24 atau yang lebih baru, Anda harus menghapus referensi apa pun ke bendera yang sekarang tidak didukung:

    • --container-runtime dockerd(containerdadalah satu-satunya nilai yang didukung)

    • --enable-docker-bridge

    • --docker-config-json

  • Jika Anda sudah memiliki Fluentd dikonfigurasi untuk Container Insights, maka Anda harus bermigrasi Fluentd kepada Fluent Bit sebelum beralih kecontainerd. Bagian Fluentd parser dikonfigurasi untuk hanya mengurai pesan log dalam format JSON. Tidak sepertidockerd, runtime containerd container memiliki pesan log yang tidak dalam format JSON. Jika Anda tidak bermigrasi ke Fluent Bit, beberapa yang dikonfigurasi Fluentd’s parser akan menghasilkan sejumlah besar kesalahan di dalam Fluentd wadah. Untuk informasi selengkapnya tentang migrasi, lihat Mengatur Bit Lancar sebagai a DaemonSet untuk mengirim log ke CloudWatch Log.

  • Jika Anda menggunakan AMI kustom dan Anda memutakhirkan ke Amazon EKS1.24, maka Anda harus memastikan bahwa penerusan IP diaktifkan untuk node pekerja Anda. Pengaturan ini tidak diperlukan dengan Docker tetapi diperlukan untukcontainerd. Diperlukan untuk memecahkan masalah Pod-untuk-Pod, Podke eksternal, atau Pod-untuk-apiserver konektivitas jaringan.

    Untuk memverifikasi pengaturan ini pada node pekerja, jalankan salah satu dari perintah berikut:

    • sysctl net.ipv4.ip_forward

    • cat /proc/sys/net/ipv4/ip_forward

    Jika outputnya0, maka jalankan salah satu perintah berikut untuk mengaktifkan variabel net.ipv4.ip_forward kernel:

    +

    • sysctl -w net.ipv4.ip_forward=1

    • echo 1 > /proc/sys/net/ipv4/ip_forward

Untuk aktivasi pengaturan di Amazon EKS AMIs untuk Amazon Linux 2 di containerd runtime, lihat install-worker.sh di GitHub.

Uji migrasi Amazon Linux 2 dari Docker untuk containerd

Untuk Kubernetes versi1.23, Anda dapat menggunakan flag bootstrap opsional untuk mengaktifkan containerd runtime untuk Amazon EKS yang dioptimalkan AL2 AMIs. Fitur ini memberi Anda jalur yang jelas untuk bermigrasi containerd saat memperbarui ke versi 1.24 atau yang lebih baru. Amazon EKS mengakhiri dukungan untuk Docker dimulai dengan Kubernetes 1.24peluncuran versi. containerdRuntime diadopsi secara luas di Kubernetes komunitas dan merupakan proyek lulusan dengan CNCF. Anda dapat mengujinya dengan menambahkan grup node ke cluster baru atau yang sudah ada.

Anda dapat mengaktifkan flag boostrap dengan membuat salah satu jenis grup node berikut.

Dikelola sendiri

Buat grup node menggunakan instruksi di Buat node Amazon Linux yang dikelola sendiri. Tentukan AMI Amazon EKS yang dioptimalkan dan teks berikut untuk BootstrapArguments parameter.

--container-runtime containerd
Dikelola

Jika Anda menggunakaneksctl, buat file bernama my-nodegroup.yaml dengan konten berikut. Ganti setiap example value dengan nilai-nilai Anda sendiri. Nama grup node tidak boleh lebih dari 63 karakter. Itu harus dimulai dengan huruf atau digit, tetapi juga dapat menyertakan tanda hubung dan garis bawah untuk karakter yang tersisa. Untuk mengambil ID AMI yang dioptimalkanami-1234567890abcdef0 , lihatAmbil AMI Amazon Linux yang direkomendasikan IDs.

apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: my-cluster region: region-code version: 1.23 managedNodeGroups: - name: my-nodegroup ami: ami-1234567890abcdef0 overrideBootstrapCommand: | #!/bin/bash /etc/eks/bootstrap.sh my-cluster --container-runtime containerd
catatan

Jika Anda meluncurkan banyak node secara bersamaan, Anda mungkin juga ingin menentukan nilai untuk argumen --apiserver-endpoint--b64-cluster-ca,, dan --dns-cluster-ip bootstrap untuk menghindari kesalahan. Untuk informasi selengkapnya, lihat Menentukan AMI.

Jalankan perintah berikut untuk membuat grup node.

eksctl create nodegroup -f my-nodegroup.yaml

Jika Anda lebih suka menggunakan alat yang berbeda untuk membuat grup node terkelola, Anda harus menerapkan grup node menggunakan template peluncuran. Di template peluncuran Anda, tentukan ID AMI Amazon EKS yang dioptimalkan, lalu terapkan grup node menggunakan template peluncuran dan berikan data pengguna berikut. Data pengguna ini meneruskan argumen ke dalam bootstrap.sh file. Untuk informasi lebih lanjut tentang file bootstrap, lihat bootstrap.sh di GitHub.

/etc/eks/bootstrap.sh my-cluster --container-runtime containerd