Container runtime adalah perangkat lunak (software) yang bertanggung jawab untuk mengeksekusi dan mengelola siklus hidup container di dalam sistem operasi.
Tanpa adanya container runtime, sebuah container image (berkas cetakan aplikasi yang masih statis) tidak akan bisa berjalan atau diubah menjadi proses yang aktif di komputer.
Fungsi Utama Container Runtime
- Mengeksekusi Container: Mengambil image aplikasi, membongkarnya, lalu mengubahnya menjadi proses yang berjalan.
- Berinteraksi dengan Kernel OS: Menggunakan fitur sistem operasi seperti namespaces dan cgroups untuk mengisolasi proses agar tidak saling mengganggu dan mengatur pembagian sumber daya (CPU serta memori).
- Mengelola Siklus Hidup (Lifecycle):Menjalankan, memantau kesehatan, menghentikan, hingga membersihkan container saat tugasnya selesai.
Jenis-Jenis Container Runtime
Dunia teknologi membagi container runtime menjadi beberapa kategori berdasarkan fungsi dan kedekatannya dengan sistem operasi:
| Jenis Runtime | Karakteristik | Contoh Populer |
|---|---|---|
| Low-Level Runtime | Berkomunikasi langsung dengan kernel OS untuk membuat dan menjalankan container. | runc, crun |
| High-Level Runtime | Mengatur transfer image dari registry, pengelolaan API, dan berkomunikasi dengan low-level runtime. | containerd, CRI-O, Docker Engine |
| Sandboxed / Virtualized | Memberikan lapisan keamanan ekstra menggunakan mesin virtual mini demi isolasi maksimal. | gVisor, Kata Containers |
Hubungan dengan Alat Lain (Contoh: Docker dan Kubernetes)
- Docker sering dianggap sebagai “alat pengelola container” secara keseluruhan, tetapi di balik layarnya, Docker menggunakan containerd (sebuah high-level runtime) untuk benar-benar menjalankan container tersebut.
- Di dalam ekosistem Kubernetes, Kubernetes tidak menjalankan container sendirian, melainkan memanggil container runtime (seperti containerd atau CRI-O) melalui standar yang disebut Container Runtime Interface (CRI).
Dalam kubernetes, apa saja runtime containernya?
Dalam Kubernetes, container runtime yang didukung harus mematuhi standar CRI (Container Runtime Interface) versi v1. Kubernetes tidak lagi berkomunikasi langsung dengan semua jenis mesin container, melainkan lewat antarmuka standar tersebut.
Berikut adalah daftar container runtime yang umum dan resmi digunakan di Kubernetes:
1. Daftar Container Runtime Utama
- containerd: Runtime yang paling populer, stabil, dan menjadi standar de facto di sebagian besar ekosistem Kubernetes saat ini. Lahir dari proyek Docker yang kemudian didonasikan ke CNCF.
- CRI-O: Runtime yang dirancang khusus dan ringan (lightweight) untuk Kubernetes, dikembangkan oleh Red Hat dan komunitas open source. Sering digunakan pada Red Hat OpenShift.
- Docker Engine (via
cri-dockerd): Mesin Docker klasik masih bisa dipakai, tetapi tidak lagi didukung secara langsung oleh Kubernetes sejak dihapusnya komponen dockershim pada versi 1.24. Jika ingin menggunakan Docker Engine, Anda wajib memasang jembatan pihak ketiga bernamacri-dockerd. - Mirantis Container Runtime (MCR): Versi komersial dari Docker Enterprise yang juga menggunakan bantuan
cri-dockerduntuk terhubung ke Kubernetes.
2. Runtime Khusus / Berbasis Keamanan (Sandboxed)
Untuk kebutuhan beban kerja (workload) yang menuntut isolasi tingkat tinggi (misalnya keamanan multi-tenant atau menjalankan kode pihak ketiga yang tidak tepercaya), Kubernetes mendukung runtime khusus melalui fitur RuntimeClass:
- gVisor (oleh Google): Membungkus sistem panggilan (syscall) aplikasi dengan kernel pengguna tambahan untuk mencegah kernel panic atau eksploitasi langsung ke sistem operasi utama.
- Kata Containers: Menjalankan setiap container di dalam mesin virtual mini (VM) yang ringan, sehingga tiap container punya kernel Linux-nya sendiri demi keamanan isolasi fisik/virtual.
Untuk memperjelas lagi apa itu runtime, mari kita ikuti pemaparan berikut ini:
Mari kita kesampingkan dulu istilah-istilah teknis komputer yang rumit. Kita gunakan analogi dunia nyata yang jauh lebih mudah dibayangkan.
Bayangkan Anda ingin membangun sebuah Restoran Kontainer Makanan (seperti kafe-kafe modern yang memanfaatkan kontainer pengiriman barang jadi tempat makan).
Berikut adalah analoginya:
- Aplikasi Anda: Adalah resep makanan dan peralatan dapur yang ingin Anda jalankan.
- Container Image: Adalah cetak biru (blueprint) atau rencana arsitektur dari kafe kontainer tersebut. Bentuknya masih berupa kertas/berkas digital. Anda tidak bisa memasak di dalam selembar kertas, bukan?
- Container Runtime: Adalah kontainer fisik besi beserta tukang bangunan dan mesin dereknya.
Tugas si Container Runtime adalah mengambil cetak biru tersebut (Image), mengambil kontainer besi kosong, menyusun meja kursi di dalamnya sesuai cetak biru, lalu menyalakan listrik dan airnya. Begitu tukang selesai bekerja, kafe kontainer tersebut aktif dan siap menerima pelanggan (Inilah yang disebut Container yang sedang berjalan).
Jadi, tanpa adanya Container Runtime, aplikasi Anda akan selamanya menjadi file statis (image) di komputer dan tidak akan pernah menjadi proses yang hidup.
Secara Teknis, Apa yang Sebenarnya Dilakukan di Komputer?
Ketika Anda mengetik perintah untuk menjalankan container, Container Runtime bekerja di belakang layar melakukan 3 hal ini:
- Menyiapkan Ruangan Isolasi: Ia meminta izin ke Sistem Operasi (Windows/Linux) untuk membuat “ruangan terisolasi”. Kamar ini dibuat agar aplikasi di dalam kontainer tidak bisa mengintip atau merusak data aplikasi lain di komputer host.
- Membatasi Jatah Makanan (Resource): Ia mengatur batas tegas. Misalnya: “Kontainer A hanya boleh memakai maksimal 1 GB RAM dan 1 CPU.” Jika kontainer A serakah, runtime akan mengeremnya agar laptop Anda tidak hang.
- Menjaga Siklus Hidup: Ia bertindak seperti satpam. Jika aplikasi di dalam kontainer tiba-earth eror atau mati, runtime akan melaporkannya (atau menghidupkannya kembali jika diatur demikian), dan jika Anda menghapusnya, runtime akan membersihkan sisa-sisa filenya agar komputer bersih kembali.
Mengapa Ada Istilah Low-Level dan High-Level?
Di dunia Kubernetes, pekerjaan ini dibagi menjadi dua tugas agar lebih efisien:
- High-Level Runtime (Manajer): Tugasnya menerima perintah dari Anda (atau dari Kubernetes), mengunduh cetak biru (image) dari internet, dan mengurus manajemen tingkat atas. Contohnya:
containerd. - Low-Level Runtime (Kuli Bangunan): Si Manajer tidak turun tangan langsung ke sistem operasi. Ia akan menyuruh Low-Level Runtime untuk mengetuk pintu sistem operasi dan membuat kontainer fisiknya. Contohnya:
runc.
Jadi, ketika Anda menggunakan Kubernetes dan memilih containerd sebagai runtime-nya, artinya Anda menunjuk containerd sebagai manajer utama yang bertanggung jawab memastikan aplikasi-aplikasi Anda terbungkus dan berjalan dengan aman di server.
Melanjutkan analogi restoran kontainer sebelumnya, containerd dan runc adalah kombinasi utama yang bekerja sama di balik layar untuk menghidupkan kontainer Anda. Keduanya tidak saling bersaing, melainkan berbagi tugas dalam sebuah hierarki (tingkatan) kerja.
Secara singkat, containerd adalah sang Manajer (High-Level Runtime), sedangkan runc adalah Kuli Bangunannya (Low-Level Runtime).
1. runc: Sang Kuli Bangunan (Low-Level Runtime)
runc adalah perangkat lunak yang sangat ringan dan fokus pada satu tugas saja: membuat kontainer fisik di dalam sistem operasi. Ia bekerja di level paling bawah yang paling dekat dengan sistem operasi (Kernel Linux).
- Bagaimana cara kerjanya?
runcakan meminta Linux membuat ruangan terisolasi menggunakan fitur sistem operasi bernama namespaces dan cgroups. - Sifat Tugas:
runchanya bekerja dalam waktu singkat. Begitu kontainer berhasil dibuat dan aplikasi di dalamnya menyala, tugasruncselesai lalu ia langsung keluar (exit). Ia tidak bertugas memantau kontainer tersebut selama berhari-hari. - Kepatuhan Standar (OCI):
runcdibuat mengikuti standar industri universal yang disebut OCI (Open Container Initiative). Artinya, apa pun aplikasinya, selama cetak birunya memenuhi standar OCI,runcpasti bisa menjalankannya.
2. containerd: Sang Manajer (High-Level Runtime)
containerd berada satu tingkat di atas runc. containerd bertindak sebagai sistem manajemen lengkap yang mengurus segala urusan administrasi kontainer dari awal sampai akhir.
- Tugas Manajemen Tambahan:
containerdbertugas mengunduh cetak biru (image) dari internet (misal dari Docker Hub), menyimpannya ke dalam media penyimpanan server, mengatur konfigurasi jaringan, hingga memantau status kesehatan kontainer secara terus-menerus. - Cara Memerintah
runc: Ketika Kubernetes atau pengguna memerintahkan “Jalankan aplikasi ini!”,containerdakan menyiapkan semua file aplikasinya. Setelah siap,containerdmemanggilruncuntuk mengeksekusinya.
Tabel Perbandingan Tugas
Agar lebih mudah melihat perbedaan kontrasnya, berikut adalah pembagian kerja di antara keduanya:
| Fitur / Fungsi | containerd (High-Level) | runc (Low-Level) |
|---|---|---|
| Peran Utama | Manajer Siklus Hidup (Supervisor) | Eksekutor Pembuat Kontainer |
| Download Image | Ya, mengunduh dari internet | Tidak, hanya menerima file lokal |
| Durasi Kerja | Berjalan terus sebagai daemon di background | Hanya aktif saat awal membuat kontainer |
| Manajemen Jaringan | Ya, ikut mengelola network | Tidak, tidak tahu urusan network |
| Hubungan | Memanggil dan mengendalikan runc | Dipanggil dan diperintah oleh containerd |
Alur Kerja Nyata di Kubernetes / Docker
Ketika sistem ingin menjalankan sebuah aplikasi, rantai perintahnya akan berjalan seperti ini:
- Kubernetes (Kubelet) memberikan instruksi ke
containerdlewat jaringan internal. containerdmengunduh image aplikasi, membuka kemasannya, dan menyiapkan konfigurasinya.containerdmemanggilruncsambil menyerahkan file konfigurasi tersebut.runcberinteraksi dengan Kernel Linux untuk mengunci ruangan isolasi dan menyalakan aplikasi. Setelah aplikasi menyala,runcpamit undur diri.containerdtetap berdiri di sana untuk menjaga dan mengawasi aplikasi tersebut selama ia hidup.
