Halaman ini menyajikan informasi tentang runtime container containerd, dukungan untuk Docker di Google Kubernetes Engine (GKE), dan ringkasan mengapa Anda harus bermigrasi ke image node yang menggunakan containerd. Untuk mendapatkan petunjuk tentang cara melakukan migrasi ke image node containerd, lihat Bermigrasi dari Docker ke image node containerd.
Ringkasan
Node Kubernetes menggunakan runtime container untuk meluncurkan, mengelola, dan menghentikan container yang berjalan di Pod. Project Kubernetes menghapus dukungan bawaan untuk runtime Docker di Kubernetes versi 1.24 dan yang lebih baru. Untuk mencapai hal tersebut, Kubernetes menghapus komponen yang disebut dockershim, agar Docker dapat berkomunikasi dengan komponen Kubernetes seperti kubelet.
Containerd, runtime default baru, adalah runtime container standar industri yang didukung oleh Kubernetes, dan digunakan oleh banyak project lainnya. Runtime containerd menyediakan abstraksi lapisan yang memungkinkan implementasi serangkaian fitur seperti gVisor dan Streaming image untuk memperluas fungsi GKE. Runtime ini juga dianggap lebih efisien dalam pengelolaan resource dan lebih aman daripada runtime Docker.
Akibat perubahan ini, GKE tidak mendukung image node yang menggunakan Docker sebagai runtime di GKE versi 1.24 dan yang lebih baru. Sebuah cluster akan terpengaruh jika salah satu node pool-nya menggunakan image node berbasis Docker atau menggunakan penyediaan otomatis node dengan jenis image node default berbasis Docker.
Sebelum 31 Juli 2023, yang merupakan tanggal akhir siklus proses (EOL) untuk GKE versi 1.23, GKE menjeda upgrade otomatis dan mencegah adanya upgrade manual ke versi 1.24. Untuk mengupgrade bidang kontrol cluster ke GKE versi 1.24 dan yang lebih baru sebelum tanggal ini, Anda harus mengupdate konfigurasi penyediaan otomatis node dan semua node ke runtime containerd. Untuk mengupgrade node pool, Anda harus bermigrasi ke image node yang menggunakan runtime containerd.
Setelah versi 1.23 mencapai akhir siklus proses (EOL), GKE berhenti memblokir upgrade control plane manual ke versi 1.24 untuk cluster yang belum menyelesaikan migrasi, dan mulai secara bertahap mengupgrade cluster demi keamanan dan kompatibilitas. Untuk mempelajari lebih lanjut cara GKE mengupgrade cluster Anda ke versi 1.24, dan tindakan yang sebaiknya Anda lakukan untuk memigrasikan cluster dari image node Docker, lihat Migrasi otomatis saat versi 1.23 mencapai akhir siklus proses (EOL).
Image Docker dan node containerd
Containerd telah menjadi runtime default untuk semua node GKE baru sejak versi 1.19 di Linux dan 1.21 di Windows. Akan tetapi, cluster GKE Standard juga terus mendukung image node yang menggunakan Docker sebagai runtime. Tabel berikut menjelaskan image node berbasis Docker yang tidak akan didukung di GKE versi 1.24 dan yang lebih baru, serta image containerd yang setara:
| Runtime Docker | runtime containerd |
|---|---|
Container-Optimized OS dengan Docker (cos) |
Container-Optimized OS dengan containerd (cos_containerd) |
Ubuntu dengan Docker (ubuntu) |
Ubuntu dengan containerd (ubuntu_containerd) |
Windows Server LTSC dengan Docker (windows_ltsc) |
Windows Server LTSC dengan containerd (windows_ltsc_containerd) |
Windows Server SAC dengan Docker ( |
Windows Server SAC dengan containerd ( |
Linimasa dan tonggak pencapaian
Di GKE versi 1.23, Anda tidak lagi dapat melakukan hal berikut:
- Membuat cluster baru yang menggunakan image node berbasis Docker.
- Menambahkan node pool baru dengan image node berbasis Docker ke cluster yang ada.
- Mengaktifkan penyediaan otomatis node dengan flag
--autoprovisioning-image-typeyang ditetapkan ke image node berbasis Docker.
Jika mengupgrade ke GKE versi 1.23, Anda dapat melanjutkannya dengan menggunakan cara berikut:
- Node pool yang sudah ada dengan image node berbasis Docker yang dibuat sebelum upgrade.
- Autoscaler cluster di node pool dengan image node Docker.
- Penyediaan otomatis node dengan flag
--autoprovisioning-image-typeditetapkan ke image node berbasis Docker, jika diaktifkan sebelum upgrade.
Di GKE versi 1.24, Anda tidak lagi dapat melakukan hal berikut:
- Jika bidang kontrol menjalankan versi 1.24, Anda tidak dapat menggunakan penyediaan otomatis node dengan flag
--autoprovisioning-image-typeyang ditetapkan ke image node berbasis Docker. - Jika node pool menjalankan versi 1.24, node tidak dapat menggunakan image node berbasis Docker.
Tabel berikut memberikan ringkasan perubahan yang akan terjadi saat Anda berinteraksi dengan versi GKE mendatang:
| Tindakan | GKE versi 1.23 | GKE versi 1.24 |
|---|---|---|
| Membuat cluster baru dengan Docker | Tidak | Tidak |
| Membuat node pool baru dengan Docker | Tidak | Tidak |
| Mengaktifkan penyediaan otomatis node dengan Docker | Tidak | Tidak |
| Mengupgrade dari versi sebelumnya dengan konfigurasi penyediaan otomatis node Docker yang ada | Ya | Tidak |
| Menggunakan image node berbasis Docker | Ya | Tidak |
Memigrasikan otomatis saat versi 1.23 mencapai akhir siklus proses (EOL)
Jika Anda tidak mengupgrade ke versi 1.24 dan bermigrasi ke image node containerd sebelum versi 1.23 mencapai akhir siklus proses (EOL) pada 31 Juli 2023, GKE akan melakukan hal berikut dari waktu ke waktu:
Jika cluster Anda memiliki penyediaan otomatis node dengan jenis image node default berbasis Docker, GKE akan memperbarui konfigurasi untuk menggunakan image node setara yang menggunakan runtime containerd. Anda tidak dapat memblokir operasi ini dengan pengecualian pemeliharaan. Untuk memastikan bahwa tidak ada efek buruk pada workload Anda, sebaiknya perbarui jenis image default penyediaan otomatis node secara manual ke image berbasis containerd sebelum GKE memperbarui konfigurasi secara otomatis.
GKE mengupgrade bidang kontrol cluster Anda ke versi 1.24.
GKE memigrasikan node pool apa pun yang masih menggunakan Docker ke image node containerd mulai 1 September 2023. Sebaiknya migrasikan image node secara manual sebelum tanggal ini. Atau, Anda dapat meminta agar GKE memulai operasi untuk memigrasikan cluster Anda agar dapat menggunakan image containerd. Untuk membuat permintaan ini, hubungi Cloud Customer Care.
Agar dapat memblokir migrasi otomatis untuk sementara, upgrade cluster Anda ke versi 1.24 atau yang lebih baru, lalu konfigurasi pengecualian pemeliharaan. Untuk informasi selengkapnya tentang pengecualian pemeliharaan ini, lihat Menunda migrasi otomatis ke image node containerd untuk sementara.
GKE mengupgrade node pool pada versi 1.23 menjadi 1.24, seperti yang dilakukan dengan versi yang tidak didukung untuk memastikan keselarasan kondisi cluster dengan kebijakan skew versi open source. Untuk mempelajari lebih lanjut, lihat siklus proses versi minor GKE. Anda dapat memblokir upgrade ini untuk sementara dengan pengecualian pemeliharaan.
Tunda migrasi otomatis ke image node dalam containerd untuk sementara
Setelah bidang kontrol cluster diupgrade ke versi 1.24 atau yang lebih baru, Anda dapat
mengonfigurasi pengecualian pemeliharaan
guna mencegah node dimigrasikan untuk sementara waktu hingga 29 Februari 2024,
saat versi 1.25 mencapai
akhir dukungan.
Agar memenuhi syarat untuk pengecualian pemeliharaan ini, cluster Anda harus didaftarkan di saluran rilis.
Konfigurasikan pengecualian pemeliharaan dengan cakupan"Tidak ada upgrade minor atau node",
dan tetapkan flag --add-maintenance-exclusion-end ke 2024-02-29T00:00:00Z atau
sebelumnya. Sebaiknya berhenti memblokir migrasi sesegera mungkin dan izinkan node diupgrade ke versi 1.24. Versi minor yang telah mencapai akhir dukungan tidak akan lagi menerima patch keamanan dan perbaikan bug.
Bermigrasi dari Docker ke image node containerd
Lihat Bermigrasi dari Docker ke image node containerd untuk mengidentifikasi cluster dan node pool menggunakan image node berbasis Docker, serta memigrasikan node pool tersebut ke image node containerd.
Berdasarkan model tanggung jawab bersama GKE, tanggung jawab pelanggan adalah menjaga kondisi workload, dan tanggung jawab Google adalah memastikan bahwa cluster tetap berfungsi, termasuk menjalankan versi yang didukung. Sebaiknya uji workload Anda dan migrasikan cluster sebelum GKE melakukannya secara otomatis.
Sebelum versi 1.23 mencapai akhir dukungan, GKE mencegah upgrade otomatis atau manual ke versi 1.24 untuk cluster yang memiliki node pool yang menggunakan image node Docker. Setelah Anda memigrasikan cluster agar hanya menggunakan image containerd, upgrade otomatis dapat dilanjutkan dalam waktu satu hari—sesuai dengan jadwal rilis GKE—atau Anda dapat mengupgrade cluster secara manual.
Setelah versi 1.23 mencapai akhir dukungan, GKE berhenti memblokir upgrade otomatis atau manual ke versi 1.24 dan mengikuti proses migrasi otomatis.
Dampak migrasi
Perubahan utama saat Anda bermigrasi ke image node containerd adalah bahwa Docker tidak lagi mengelola siklus proses container Anda (seperti memulai dan menghentikannya). Oleh karena itu, Anda tidak dapat menggunakan perintah Docker atau Docker API untuk melihat atau berinteraksi dengan container GKE yang berjalan pada node yang menggunakan image containerd.
Sebagian besar workload pengguna tidak memiliki dependensi pada runtime container. Runtime Docker juga mengimplementasikan containerd, sehingga workload Anda berperilaku serupa pada image node containerd.
Anda mungkin terpengaruh jika situasi berikut berlaku:
- Anda menjalankan Pod dengan hak istimewa yang menjalankan perintah Docker.
- Anda menjalankan skrip di node dari luar infrastruktur Kubernetes (misalnya, untuk menggunakan ssh guna memecahkan masalah).
- Anda menjalankan alat pihak ketiga yang melakukan operasi dengan hak istimewa serupa.
- Beberapa alat Anda merespons log khusus Docker dalam sistem pemantauan.
- Anda men-deploy alat logging, pemantauan, keamanan, atau continuous integration yang disediakan oleh vendor luar ke dalam cluster GKE. Hubungi vendor ini untuk mengonfirmasi dampak.
Anda tidak terpengaruh dalam situasi berikut:
- Anda memiliki pipeline build di luar cluster GKE yang menggunakan Docker untuk membangun dan mengirim image container.
- Anda menggunakan perintah
docker builddandocker pushdi cluster GKE. Image node Linux dengan containerd menyertakan biner Docker dan mendukung perintah ini.
Menggunakan Pod dengan hak istimewa untuk mengakses Docker
Jika pengguna mengakses Docker Engine pada node menggunakan Pod dengan hak istimewa, Anda harus memperbarui workload tersebut agar tidak terlalu bergantung pada Docker. Sebagai contoh, pertimbangkan untuk memigrasikan proses ekstraksi logging dan pemantauan dari Docker Engine ke add-on sistem GKE.
Membangun image container dengan containerd
Anda tidak dapat menggunakan containerd untuk membangun image container. Image Linux dengan containerd menyertakan biner Docker sehingga Anda dapat menggunakan Docker untuk membangun dan mengirim image. Namun, sebaiknya jangan gunakan container individual dan node lokal untuk menjalankan perintah guna membangun image.
Kubernetes tidak mengetahui resource sistem yang digunakan oleh proses lokal di luar cakupan Kubernetes, dan bidang kontrol Kubernetes tidak dapat memperhitungkan proses tersebut saat mengalokasikan resource. Hal ini dapat membuat resource pada workload GKE menjadi tidak memadai atau menyebabkan ketidakstabilan pada node.
Pertimbangkan untuk menyelesaikan tugas ini menggunakan service lain di luar cakupan container individual, seperti Cloud Build, atau menggunakan alat seperti kaniko untuk membuat image sebagai workload Kubernetes.
Jika tidak ada satu pun dari saran ini yang berhasil dan Anda memahami risikonya, Anda dapat terus menggunakan Docker di node lokal untuk membangun image. Anda harus mengirim image ke registry sebelum dapat menggunakannya di cluster GKE. Kubernetes dengan containerd tidak mengetahui image yang dibangun secara lokal menggunakan Docker.
Melakukan proses debug container pada node containerd
Untuk proses debug atau pemecahan masalah pada node Linux, Anda dapat berinteraksi dengan containerd menggunakan alat command line portabel yang dibangun untuk runtime container Kubernetes: crictl. crictl mendukung fungsi umum untuk melihat container
dan image, membaca log, dan menjalankan perintah container. Lihat panduan pengguna crictl untuk mengetahui rangkaian lengkap fitur yang didukung dan informasi penggunaan.
Untuk node Windows Server, daemon containerd berjalan sebagai layanan Windows bernama containerd.
Log tersedia sebagai berikut:
- Windows:
C:\etc\kubernetes\logs\containerd.log - Linux: jalankan
journalctl -u containerd
Anda juga dapat melihat log untuk node Windows dan Linux di Logs Explorer
pada LOG NAME: "container-runtime".
Pemecahan masalah
Untuk pemecahan masalah, buka Memecahkan masalah terkait runtime containerd.
Langkah berikutnya
- Baca tentang penghentian penggunaan Dockerhim.
- Periksa apakah penghentian penggunaan tersebut memengaruhi Anda.
- Bermigrasi dari Docker ke image node containerd.