Catatan perev. : Kami telah menulis lebih dari satu publikasi (lihat tautan di akhir artikel) tentang runtime kontainer (container runtimes) - sebagai aturan, mereka dibahas dalam konteks Kubernetes. Namun, sering kali bahan-bahan ini membangkitkan pertanyaan pembaca, menunjukkan kurangnya pemahaman di mana proyek berikutnya berasal, bagaimana hal itu terhubung dengan yang lain dan apa yang umumnya terjadi di seluruh wadah "kebun binatang" ini.
Sebuah artikel baru-baru ini oleh Phil Estes, direktur teknis wadah dan arsitektur IBM Watson & Cloud Platform untuk Linux, memberikan retrospektif yang sangat baik tentang bagaimana menavigasi dan mendapatkan pemahaman yang lebih luas tentang siapa yang telah kehilangan (atau tidak pernah menangkap) rangkaian peristiwa. Menjadi salah satu pemelihara proyek Moby dan proyek penahanan, anggota komite teknis Open Container Initiative (OCI) dan Moby, dan juga memiliki status Docker Captain, penulis menulis tentang masa lalu, masa kini, dan masa depan dunia runtime kontainer baru yang luar biasa. Dan untuk yang paling malas, materi dimulai dengan TL; DR pada subjek ... Temuan Kunci
- Seiring waktu, pilihan di antara runtime kontainer telah berkembang, memberikan lebih banyak opsi daripada mesin Docker yang populer.
- Open Container Initiative (OCI) telah berhasil menstandarkan konsep wadah dan gambar kontainer untuk menjamin interoperabilitas ("interoperabilitas" - sekitar. Terjemahan.) Di antara lingkungan runtime.
- Kubernetes menambahkan Container Runtime Interface (CRI), yang memungkinkan kontainer untuk terhubung ke lingkungan runtime dengan lapisan orkestrasi yang mendasarinya di K8s.
- Inovasi di bidang ini memungkinkan wadah untuk memanfaatkan virtualisasi ringan dan teknik isolasi unik lainnya untuk meningkatkan persyaratan keamanan.
- Dengan OCI dan CRI, interoperabilitas dan pilihan telah menjadi kenyataan dalam ekosistem wadah runtime dan lingkungan orkestrasi.
Teknologi Containerisasi telah ada selama beberapa waktu di dunia sistem operasi Linux - ide pertama tentang ruang nama terpisah untuk sistem file dan proses muncul lebih dari satu dekade yang lalu. Dan di masa lalu yang relatif baru, LXC muncul dan menjadi cara standar bagi pengguna Linux untuk berinteraksi dengan teknologi isolasi kuat yang tersembunyi di kernel Linux.
Namun, meskipun
LXC berupaya menyembunyikan kerumitan menggabungkan berbagai “bagian dalam” teknologi dari apa yang biasa kita sebut wadah hari ini, wadah tetap menjadi semacam sihir dan menjadi lebih kuat hanya di dunia orang-orang yang berpengetahuan luas, dan tidak mendapatkan distribusi luas di antara massa.
Semuanya berubah pada tahun 2014 dengan
Docker , ketika pembungkus baru yang ramah pengembang dari teknologi kernel Linux yang sama yang dimiliki LXC muncul - setelah semua, versi awal Docker "di belakang layar" menggunakan LXC, dan wadah menjadi - Fenomena massa nyata, karena pengembang dijiwai dengan kesederhanaan dan kemungkinan menggunakan kembali gambar kontainer Docker dan perintah sederhana untuk bekerja dengannya.
Tentu saja, Docker bukan satu-satunya yang ingin mendapatkan bagian di pasar kontainer ketika hype yang menyertai mereka tidak berpikir untuk mereda setelah bunga ledakan pertama di 2014. Selama bertahun-tahun, berbagai ide alternatif telah muncul untuk lingkungan wadah yang dapat dieksekusi dari
CoreOS (rkt) ,
Intel Clear Containers ,
hyper.sh (virtualisasi berbasis wadah ringan), dan
Singularity dan
shifter dalam dunia penelitian komputasi kinerja tinggi (HPC).
Pasar terus tumbuh dan matang, dan dengan
Open Container Initiative (OCI) muncul upaya untuk menstandarkan ide-ide awal yang dipromosikan oleh Docker. Saat ini, banyak lingkungan kontainer yang dapat dieksekusi sudah kompatibel dengan OCI, atau dalam perjalanannya, menawarkan kondisi yang sama bagi produsen untuk mempromosikan fitur dan kemampuan mereka yang berfokus pada aplikasi tertentu.
Popularitas Kubernetes
Tahap selanjutnya dalam evolusi wadah adalah menggabungkan wadah komputasi terdistribusi ala microservices dengan wadah - dan semua ini di dunia baru pengembangan dan penyebaran yang cepat (kita dapat mengatakan bahwa DevOps), yang secara aktif mendapatkan momentum seiring dengan popularitas Docker.
Meskipun
Apache Mesos dan platform orkestrasi perangkat lunak lain ada sebelum
Kubernetes mendominasi,
K8 lepas landas dengan cepat dari proyek Open Source kecil dari Google ke proyek utama
Cloud Native Computing Foundation (CNCF) .
Catatan perev. : Apakah Anda tahu bahwa CNCF muncul pada 2015 pada kesempatan rilis Kubernetes 1.0? Pada saat yang sama, proyek tersebut ditransfer oleh Google ke organisasi independen baru yang menjadi bagian dari The Linux Foundation.
Acara rilis K8s 1.0 disponsori oleh, antara lain, Mesosphere, CoreOS, Mirantis, OpenStack, Bitnami
Dari berita tentang rilis Kubernetes 1.0 di ZDNetBahkan setelah Docker merilis platform orkestrasi saingan,
Swarm , dibangun di Docker dan menampilkan kesederhanaan Docker dan fokus pada konfigurasi kluster aman default, ini tidak lagi cukup untuk membendung minat yang tumbuh di Kubernetes.
Namun, banyak pemangku kepentingan di luar komunitas asli cloud yang tumbuh dengan cepat menjadi bingung. Seorang pengamat biasa tidak dapat mengetahui apa yang terjadi: Kubernet bertarung dengan Docker atau kerja sama mereka? Karena Kubernetes hanyalah platform orkestrasi, diperlukan lingkungan wadah yang dapat dieksekusi yang akan secara langsung meluncurkan kontainer yang diatur dalam Kubernetes. Sejak awal, Kubernetes menggunakan mesin Docker dan, meskipun ada ketegangan kompetitif antara Swarm dan Kubernetes, Docker masih merupakan runtime default dan diperlukan agar kluster Kubernetes berfungsi.
Dengan sejumlah kecil runtimes kontainer selain Docker, tampak jelas bahwa memasangkan runtime dengan Kubernetes akan membutuhkan antarmuka yang ditulis khusus - shim - untuk setiap runtime. Kurangnya antarmuka yang jelas untuk mengimplementasikan runtimes kontainer membuatnya sangat sulit untuk menambahkan dukungan untuk runtimes baru di Kubernetes.
Container Runtime Interface (CRI)
Untuk mengatasi kompleksitas implementasi runtimes yang semakin bertambah di Kubernetes, komunitas tersebut mendefinisikan fungsi khusus antarmuka yang harus diimplementasikan oleh runtime container di dalam Kubernetes - menamainya
Container Runtime Interface (CRI) ( muncul di Kubernetes 1,5 - kira-kira Terjemahkan.) . Acara ini tidak hanya membantu masalah meningkatnya jumlah fragmen basis kode Kubernetes yang mempengaruhi penggunaan runtimes kontainer, tetapi juga membantu untuk memahami fungsi mana yang harus didukung oleh potensi runtimes jika mereka ingin mematuhi CRI.
Seperti yang Anda tebak, CRI mengharapkan hal-hal yang sangat sederhana dari runtime. Lingkungan seperti itu harus dapat memulai dan menghentikan pod, menangani semua operasi dengan kontainer dalam konteks pod (start, stop, pause, kill, delete), dan juga mendukung pengelolaan gambar kontainer menggunakan registri. Ada juga fungsi tambahan untuk mengumpulkan log, metrik, dll.
Ketika fitur baru muncul di Kubernetes, jika mereka bergantung pada lapisan runtime kontainer, perubahan tersebut dilakukan pada API CRI versi. Ini pada gilirannya menciptakan ketergantungan fungsional baru pada Kubernetes dan membutuhkan pelepasan runtime versi yang lebih baru yang mendukung fitur-fitur baru (satu contoh terakhir adalah ruang nama pengguna).
Lanskap CRI saat ini
Pada 2018, ada beberapa opsi untuk digunakan sebagai runtimes kontainer di Kubernetes. Seperti yang ditunjukkan pada ilustrasi di bawah ini, salah satu opsi nyata masih Docker dengan
dockershimnya yang mengimplementasikan API CRI. Dan faktanya, di sebagian besar instalasi Kubernetes hari ini, dialah Docker, yang tetap menjadi runtime default.
Salah satu konsekuensi menarik dari ketegangan antara strategi orkestrasi Docker dengan Swarm dan komunitas Kubernetes adalah proyek bersama, yang mengambil dasar runtime dari Docker dan mengumpulkan darinya sebuah proyek Open Source baru, yang dikembangkan bersama-sama -
mengandungerd . Seiring waktu, contenterd dipindahkan ke CNCF, organisasi yang sama yang mengelola dan memiliki proyek Kubernetes.
( Catatan terjemahan .: Kami menjelaskan penampilan kontenerd secara lebih rinci dalam artikel terpisah .)
Dari pengumuman konten di blog DockerContainerd, menjadi implementasi runtime yang sederhana, dasar, dan
tidak beralasan untuk Docker dan Kubernetes (via CRI), mulai mendapatkan popularitas sebagai pengganti potensial Docker di banyak instalasi Kubernetes. Sampai saat ini, IBM Cloud dan Google Cloud memiliki cluster berbasis konten dalam mode akses / beta awal. Microsoft Azure juga berjanji untuk beralih ke containerd di masa depan, dan Amazon masih mempertimbangkan berbagai runtime untuk solusi kontainernya (ECS dan EKS), sambil terus menggunakan Docker.
Red Hat telah memasuki ruang
runtime wadah dengan membuat implementasi CRI sederhana yang disebut
cri-o berdasarkan implementasi referensi OCI,
runc . Docker dan containerd juga berbasis runc, tetapi pencipta cri-o mengklaim bahwa runtime mereka “cukup” untuk Kubernetes dan mereka tidak membutuhkan lebih banyak - mereka hanya menambahkan fungsi yang paling diperlukan untuk mengimplementasikan Kubernetes CRI pada basis biner runc.
( Catatan terjemahan .: Kami menulis lebih banyak tentang proyek CRI-O dalam artikel ini , dan di sini tentang pengembangan lebih lanjut dalam bentuk podman.)Proyek virtualisasi ringan: Intel Clear Containers dan hyper.sh - muncul di alam liar OpenStack Foundation,
wadah Kata , dan menawarkan visi mereka tentang wadah virtual untuk isolasi tambahan menggunakan implementasi CRI yang disebut
frakti . Baik cri-o dan containerd juga berfungsi dengan wadah Kata, sehingga runtime yang kompatibel dengan OCI dapat dipilih sebagai opsi yang dapat dicolokkan.
Memprediksi masa depan
Mengatakan bahwa Anda tahu masa depan biasanya tidak terlalu bijaksana, tetapi setidaknya kita dapat memperbaiki beberapa tren yang muncul saat ekosistem wadah bergerak dari antusiasme dan sensasi ke tahap yang lebih matang dari keberadaan kita.
Ada kekhawatiran awal bahwa ekosistem wadah akan membentuk lingkungan yang terfragmentasi, peserta yang berbeda akan muncul dengan ide yang berbeda dan tidak sesuai tentang apa wadah itu. Berkat kerja OCI dan tindakan bertanggung jawab dari vendor dan peserta utama, kami melihat lingkungan yang sehat di industri di antara penawaran perangkat lunak yang lebih memilih kompatibilitas dengan OCI.
Bahkan di lingkungan yang lebih baru di mana standar penggunaan Docker menemui sedikit perlawanan karena pembatasan yang ada - misalnya, di HPC - semua upaya untuk menciptakan lingkungan wadah kontainer yang tidak berbasis Docker juga menarik perhatian OCI. Diskusi sedang berlangsung tentang apakah OCI dapat menjadi solusi yang layak untuk kebutuhan spesifik komunitas ilmuwan dan peneliti.
Menambah ini standarisasi runtime wadah plug-in di Kubernetes menggunakan CRI, kita bisa membayangkan dunia di mana pengembang dan administrator dapat memilih alat yang tepat dan tumpukan perangkat lunak untuk tugas-tugas mereka, menunggu dan mengamati interoperabilitas di seluruh ekosistem kontainer.
Pertimbangkan contoh spesifik untuk lebih memahami dunia ini:
- Pengembang dengan MacBook menggunakan Docker untuk Mac untuk mengembangkan aplikasinya dan bahkan menggunakan dukungan Kubernet bawaan (Docker di sini berfungsi seperti runtime CRI) untuk mencoba menggunakan aplikasi baru pada pod K8s.
- Aplikasi melewati CI / CD dalam perangkat lunak vendor, yang menggunakan kode runc dan khusus (ditulis oleh vendor) untuk mengemas gambar OCI dan memuatnya ke dalam daftar perusahaan wadah untuk pengujian.
- Instalasi kluster Kubernet di tempat, bekerja dengan contenterd sebagai runtime CRI, menjalankan serangkaian tes untuk aplikasi.
- Perusahaan ini, karena alasan tertentu, memilih wadah Kata untuk beban kerja tertentu dalam produksi, jadi ketika Anda menggunakan aplikasi, itu dimulai di pod dengan contenterd yang dikonfigurasi untuk menggunakan wadah Kata sebagai runtime alih-alih runc.
Seluruh skenario yang dijelaskan berfungsi dengan sangat baik karena kompatibilitas dengan spesifikasi OCI untuk lingkungan dan gambar runtime, dan fakta bahwa CRI memberikan fleksibilitas untuk memilih runtime.
Fleksibilitas dan pilihan yang memungkinkan ini membuat ekosistem kontainer benar-benar luar biasa dan juga merupakan kondisi yang sangat penting bagi kematangan industri, yang telah berkembang begitu pesat sejak 2014. Pada ambang batas 2019 dan tahun-tahun berikutnya, saya melihat masa depan yang cerah dengan inovasi dan fleksibilitas yang berkelanjutan bagi mereka yang menggunakan dan membuat platform berdasarkan wadah.
Informasi lebih lanjut tentang topik ini dapat ditemukan dalam pembicaraan Phil Estes baru-baru ini di QCon NY: “
CRI Runtimes Deep Dive: Siapa yang Menjalankan Pod Kubernetes Saya!? "
PS dari penerjemah
Baca juga di blog kami: