Seperti yang pernah kita dengar, Kubernetes menghentikan Docker sebagai runtime dari v1.20 untuk mendukung runtime yang menggunakan Container Runtime Interface (CRI), seperti containerd dan CRI-O.
Tapi itu bukan alasan untuk panik. Pertama-tama: ini adalah penghentian - yaitu, Anda akan mulai mendapatkan peringatan dari v1.20, jadi Anda tidak langsung terpengaruh. Anda masih memiliki satu tahun penuh untuk membuat rencana, karena Docker tidak akan didukung di v1.22, yang akan diluncurkan pada akhir 2021.
Meskipun Anda belum siap pada saat itu, Anda dapat memilih untuk tidak meningkatkan ke v1.22 sampai Anda merasa sudah siap. Kubernetes akan tetap menambal versi yang ada dengan pembaruan keamanan apa pun.
Namun sebelum kita membahas detail lebih lanjut tentang cara bermigrasi, mari kita pahami apa yang berubah dan siapa yang terkena dampaknya.
Apa yang Berubah
Jadi apa yang berubah? Ini hanya runtime Kubernetes. Jika Anda menggunakan Docker untuk membuat image dan mengujinya di CI / CD Pipeline selama pengembangan, Anda dapat terus menggunakannya. Docker menggunakan containerd secara internal untuk menjalankan container Docker.
Jika Docker menggunakan containerd dan, seperti yang kita semua tahu, containerd adalah runtime container lain, mengapa menggunakan Docker sama sekali? Nah, Docker bukan hanya runtime kontainer - runtime kontainer hanya membentuk intinya, dan Docker telah memindahkannya ke kontainer. Docker juga menyediakan banyak lapisan pengalaman pengguna di atasnya yang memungkinkan pengembang seperti Anda dan saya untuk berinteraksi dengannya dengan mudah.
Namun, lapisan itu tidak masuk akal untuk mesin. Selain itu, Kubernetes tidak dapat berinteraksi langsung dengan Docker, karena tidak kompatibel dengan Kubernetes CRI. Sebagai gantinya, ia perlu menggunakan lapisan lain di atas, yang disebut dockershim, yang menambahkan kompleksitas tambahan selama runtime container yang sudah kompleks, seperti gambar di bawah ini:
Sekarang itu menjadi berlebihan, dan oleh karena itu Kubernetes telah memutuskan untuk menghentikan dukungannya karena Docker pada akhirnya berinteraksi dengan containerd, yang dapat berinteraksi dengan Kubernetes secara langsung. Kubernetes juga tidak peduli dengan UI yang mewah, karena ini hanyalah sebuah mesin.
Siapa yang terkena dampak?
Jadi haruskah kita berhenti menggunakan Docker sama sekali? Tidak juga! Docker memiliki fungsi yang sangat berbeda. Selain sebagai runtime kontainer, ini juga merupakan mesin kontainer yang ramah pengembang. Jadi jika Anda menggunakan Docker untuk membuat image container dan dalam pipeline CI / CD, Anda dapat terus menggunakannya.
Docker membuat image container berstandar OCI. Itu berarti image Docker dapat berjalan dengan baik di runtime container apa pun yang sesuai dengan OCI - yang mencakup containerd dan CRI-O.
Sekarang mari kita lihat layer orkestrasi. Jika Anda menggunakan Docker sebagai runtime kontainer dalam cluster Kubernetes Anda, Anda akan terpengaruh. Anda harus menggantinya dengan runtime container yang didukung - containerd atau CRI-O. Container Docker bekerja dengan baik pada keduanya.
Jika Anda menggunakan layanan terkelola seperti GKE, EKS, atau AKS, Anda dapat memeriksa setelan cluster untuk mencari tahu runtime container yang digunakannya. Ketiga default untuk containerd, dan jika Anda belum membuat pilihan kustom, kemungkinan Anda menggunakan containerd dan tidak terpengaruh.
Jika Anda menggunakan Docker karena alasan tertentu, Anda perlu bekerja sama dengan penyedia cloud Anda untuk memastikan Anda mendapatkan upgrade yang tepat dan teruji ke runtime yang didukung. Penyedia cloud akan bekerja untuk tujuan ini dan segera menyediakan jalur migrasi dan saran.
Jika Anda telah membangun kluster atau memiliki penyiapan di lokasi, ini akan menjadi sedikit lebih banyak pekerjaan dan akan mengakibatkan waktu henti sementara Anda mengganti runtime penampung dan memulainya lagi dengan mengubah crictl.yaml file agar mengarah ke runtime penampung baru atau dengan mengizinkan kubeadm mendeteksi runtime baru secara otomatis dan menerapkan konfigurasi.
Nah, jika Anda tidak ingin downtime, Anda dapat menggunakan pendekatan canary, di mana Anda memutar cluster duplikat dengan runtime container yang didukung dan memigrasikan beban kerja Anda di sana - lalu memutar cluster yang sudah ada.
Apakah Beban Kerja Kontainer Terkena Dampak?
Akan lebih baik jika Anda membuat penilaian ini sebelum mencoba bermigrasi ke runtime baru. Jika Anda memiliki pipeline CI / CD yang berjalan di dalam Kubernetes dan menggunakan pendekatan Docker-in-Docker (DinD) dengan memasang /var/run/docker.sock file soket, Anda akan terpengaruh.
Karena Anda tidak akan menjalankan Docker di cluster Kubernetes, Anda perlu menggantinya dengan solusi yang sesuai - Kaniko adalah solusi yang sangat baik untuk ini, karena tidak bergantung pada daemon Docker untuk membangun image container. Anda dapat membaca “ Cara Membuat Kontainer di Cluster Kubernetes Dengan Kaniko ” untuk tampilan yang lebih detail tentang cara mendekati masalah ini.
Beban kerja lainnya tidak terpengaruh, dan Anda dapat menjalankannya dengan baik di waktu proses penampung lain yang didukung.
Ringkasan
Meskipun Kubernetes telah memutuskan untuk menghentikan Docker demi runtime container yang didukung CRI, tidak ada alasan untuk panik. Ini tidak menyiratkan kematian Docker, dan dampaknya hanya pada runtime container di cluster Kubernetes. Anda dapat terus menggunakan Docker untuk aktivitas pengembangan Anda seperti sebelumnya.
Untuk mempermudah, mari kita rangkum keseluruhan cerita dengan diagram alur yang membantu:
Terima kasih sudah membaca! Saya harap Anda menikmati artikelnya.