Dimulai dengan v1.20, Kubernetes menghapus Docker sebagairuntime container.
Tapi jangan panik. Tidak semuanya seburuk yang terlihat pada pandangan pertama.
TL; DR. Kubernetes membuang Docker untuk mendukung runtime Container Runtime Interface (CRI) yang dirancang khusus untuk Kubernetes. Image Docker akan terus berfungsi seperti biasa di semua runtime.
Untuk pengguna akhir Kubernetes, sedikit yang akan berubah. Semua ini tidak berarti bahwa Docker akan "mati" atau harus / tidak boleh digunakan untuk pengembangan lagi. Docker akan terus menjadi alat yang hebat untuk membuat container, dan image yang dibuat dengannya
docker build
akan terus berjalan di cluster K8s.
Jika Anda menggunakan layanan Kubernetes terkelola seperti GKE atau EKS, Anda harus memastikan pekerja Anda menggunakan versi runtime yang didukung dan melakukannya sebelum dukungan Docker dihapus di rilis K8 mendatang. Jika node Anda memiliki penyesuaian khusus, kemungkinan besar Anda perlu mengupgrade untuk memenuhi persyaratan lingkungan dan runtime yang sesuai. Kami menganjurkan agar Anda menghubungi penyedia layanan Anda dan mendiskusikan semua masalah pengujian dan perencanaan peningkatan.
Jika Anda meluncurkan cluster sendiri, Anda juga perlu melakukan perubahan yang sesuai untuk menghindari masalah. Saat meningkatkan ke v1.20, Anda akan menerima peringatan penghentian Docker. Pengembang berencana untuk sepenuhnya meninggalkan Docker dalam versi 1.23, yang rilisnya dijadwalkan pada akhir 2021. Dengan rilisnya, Anda harus beralih ke salah satu lingkungan yang dapat dijalankan yang kompatibel - misalnya, containerd atau CRI-O. Pastikan saja lingkungan yang Anda pilih mendukung konfigurasi daemon Docker yang Anda gunakan (misalnya, logging).
Tentang apa semua kebingungan ini dan mengapa semua orang begitu khawatir?
Faktanya, kita berbicara tentang dua lingkungan yang sama sekali berbeda, dan ini menciptakan kebingungan. Di dalam cluster Kubernetes ada yang disebut runtime container , yang bertanggung jawab untuk memuat dan menjalankan gambar container. Dan Docker cukup populer sebagai alat untuk mengatur lingkungan ini (containerd dan CRI-O juga dikenal luas). Namun, Docker tidak didesain untuk disematkan di Kubernetes, dan ini menimbulkan sejumlah masalah.
"Docker" bukanlah alat yang terpisah, tetapi keseluruhan tumpukan teknologi, dan salah satu komponennya disebut "containerd" (kami menulis tentangnya secara lebih rinci di sini - kira-kira. Terjemahan)dan bertindak sebagai runtime tingkat tinggi untuk container. Docker populer dan nyaman karena banyaknya add-on untuk pengguna yang sangat menyederhanakan proses interaksi dengan alat ini selama pengembangan. Namun, semua peningkatan UX ini tidak diperlukan untuk Kubernetes, karena dia bukan manusia.
Tingkat abstraksi yang ramah pengguna ini memaksa cluster Kubernetes untuk menggunakan alat lain, Dockershim, untuk menjangkau apa yang sebenarnya dibutuhkannya: containerd. Dan ini buruk, karena lapisan tambahan seperti itu harus diservis dan juga bisa "rusak". Pada kenyataannya, ternyata sebagai berikut: di Kubernetes v1.23, Dockershim akan dihapus dari Kubelet - karenanya, Docker akan kehilangan dukungan sebagai runtime kontainer. Muncul pertanyaan: jika containerd sudah termasuk dalam stack Docker, mengapa Kubernetes membutuhkan Dockershim?
Intinya adalah Docker tidak kompatibel dengan Container Runtime Interface.(CRI). Jika itu kompatibel, kami tidak memerlukan lapisan tambahan dan semuanya akan bagus. Namun, ini bukanlah akhir dunia dan bukan alasan untuk panik. Cukup ganti runtime Docker dengan yang didukung.
Harap dicatat bahwa jika Anda menggunakan soket Docker (
/var/run/docker.sock
) sebagai bagian dari alur kerja normal, maka setelah beralih ke lingkungan lain Anda tidak lagi dapat bekerja dengannya. Pola ini sering disebut dengan “Docker in Docker”. Ada banyak alat berbeda untuk mengatasi masalah ini, termasuk kaniko , img, dan buildah .
? - Dockerfile'? Docker'?
Perubahan kontroversial ini adalah tentang lingkungan yang sama sekali berbeda dari yang digunakan kebanyakan orang untuk berinteraksi dengan Docker. Menginstal Docker untuk pengembangan tidak ada hubungannya dengan runtime di dalam cluster Kubernetes. Ya, ini membingungkan, saya tahu ...
Bahkan setelah inovasi, Docker akan tetap menjadi alat yang berguna bagi pengembang. Gambar yang dihasilkan Docker dapat bekerja dengan lebih dari sekedar Docker. Ini adalah gambar OCI lengkap. Gambar apa pun yang sesuai dengan OCI akan terlihat sama di Kubernetes apa pun alat yang digunakan untuk membuatnya. containerd dan CRI-O sangat bagus dalam mengambil gambar-gambar ini dan menjalankannya. Inilah mengapa standar penampung dibuat.
Jadi, perubahan akan datang. Beberapa orang tentu saja akan mengalami masalah tertentu. Tapi tidak ada yang perlu disesali atau dikhawatirkan, karena kemajuan adalah hal yang keren. Bergantung pada bagaimana Anda menggunakan Kubernetes, ini bisa berarti kelambanan total atau sedikit usaha untuk Anda. Dalam jangka panjang, inovasi seperti itu hanya akan membuat segalanya lebih mudah.
Jika perubahan mendatang masih membingungkan Anda, Anda baik-baik saja. Ada banyak bagian yang bergerak di Kubernetes, dan tidak ada yang 100% ahli dalam hal itu. Silakan mengajukan pertanyaan apa pun, terlepas dari tingkat pengalaman atau kesulitan! Tujuan kami adalah mempersiapkan semua orang sebanyak mungkin untuk perubahan yang akan datang. <3 Kami berharap posting ini telah menjawab sebagian besar pertanyaan Anda dan menghilangkan semua kekhawatiran dan kekhawatiran!
Butuh lebih banyak jawaban? Lihat FAQ penghentian Dockershim .
PS dari penerjemah
Anda juga dapat menemukan jawaban mendetail dari Tim Hockin , salah satu pengembang Kubernetes, dalam diskusi tentang topik ini di Reddit .
Baca juga di blog kami: