Catatan perev. : Kami telah menulis lebih dari sekali tentang contenterd dan runtime lainnya untuk Kubernetes. Publikasi baru adalah terjemahan dari pengumuman baru-baru ini tentang tonggak penting dalam pengembangan contenterd, yang diterbitkan di blog resmi proyek Kubernetes. Teks ini ditulis oleh karyawan Google dan IBM, yang (tentu saja, bersama dengan Docker Inc) berkontribusi signifikan terhadap peningkatan konten.Sebelumnya di blog - dalam catatan
Containerd Membawa Lebih Banyak Opsi Runtime Kontainer untuk Kubernetes - kami memperkenalkan versi alpha dari integrasi contenterd dengan Kubernetes. 6 bulan ke depan pembangunan mengarah pada fakta bahwa integrasi telah tersedia untuk umum! Ini berarti bahwa sekarang Anda dapat menggunakan contenterd
1.1 sebagai runtime untuk kontainer di kluster Kubernet dalam produksi.
Containerd 1.1 bekerja dengan Kubernetes versi 1.10 dan lebih tinggi, mendukung semua fitur Kubernetes. Dalam infrastruktur pengujian Kubernetes, cakupan pengujian integrasi contenterd di Google Cloud Platform telah menjadi sama dengan integrasi dengan Docker (lihat
dasbor uji ).
“Kami senang melihat contenterd cepat mencapai tonggak penting ini. Di Alibaba Cloud, kami mulai menggunakan contenterd secara aktif sejak awal dan, berkat penekanannya pada kesederhanaan dan keandalan, menjadikan containerd sebagai mesin kontainer standar di produk Serverless Kubernet kami, yang menempatkan tuntutan tinggi pada kinerja dan stabilitas. Containerd tidak diragukan lagi akan menjadi mesin utama di era kontainer dan mengarah pada pengembangan inovasi. ” - Xinwei, seorang insinyur penuh waktu dari Alibaba Cloud
Perbaikan arsitektur
Arsitektur untuk mengintegrasikan contenterd dengan Kubernetes telah berubah dua kali. Setiap langkah evolusionernya menstabilkan dan meningkatkan efisiensi tumpukan.
Containerd 1.0 - CRI-Containerd (tidak ada)
Dalam
contenterd 1.0, daemon cri-
conteerd diperlukan untuk interaksi antara
Kubelet dan
conteerd (kami menulis tentang hal itu di akhir artikel ini - kira - kira Terjemahkan. ) . Daemon ini melayani permintaan ke
Container Runtime Interface (CRI) dari
Kubelet dan menggunakan
contenterd untuk mengelola kontainer dan gambar kontainer dengan benar. Pendekatan ini menghilangkan satu tautan tambahan di stack jika dibandingkan dengan implementasi Docker CRI (
dockershim ) -
lihat ilustrasi di atas .
Namun, cri-containerd dan containerd 1.0 adalah dua daemon terpisah yang berinteraksi melalui GRPC. Daemon tambahan dalam bundel ini membuat hidup lebih sulit bagi pengguna baik dalam memahami perangkat dan selama penyebaran, dan juga menghasilkan overhead yang tidak perlu untuk interaksi.
Containerd 1.1 - Plugin CRI (versi saat ini)
Di containerd 1.1, daemon cri-containerd diulang kembali ke plugin containerd CRI. Plugin ini dibangun ke dalam file 1.1 dan diaktifkan secara default. Tidak seperti cri-containerd, plugin berinteraksi dengan containerd dengan langsung memanggil fungsi yang diperlukan. Arsitektur baru telah membuat integrasi lebih stabil dan produktif, menghilangkan tautan lain (GRPC) dari tumpukan. Sekarang contenterd 1.1 dapat digunakan langsung di Kubernetes, dan daemon cri-containerd tidak lagi diperlukan.
Performa
Salah satu tujuan utama untuk contenterd 1.1 adalah untuk meningkatkan kinerja. Optimalisasi dilakukan di area waktu start-up dan sumber daya yang digunakan oleh iblis.
Hasil-hasil berikut adalah perbandingan dari contenterd 1.1 dan Docker 18.03 CE. Integration Conteerd 1.1 menggunakan plugin CRI built-in, dan integrasi untuk Docker 18.03 CE bekerja dengan dockershim. Hasilnya dihasilkan menggunakan benchmark kinerja simpul Kubernetes, yang merupakan bagian dari
tes e2e untuk node K8s . Sebagian besar data perbandingan tersedia untuk umum di
dasbor kinerja node .
Tunda perapian mulai
Hasil
benchmark startup 105 pod batch menunjukkan bahwa integrasi 1.1 1.1 integrasi memiliki penundaan lebih sedikit dalam memulai pod dari Docker 18.03 CE dengan dockershim (semakin kecil semakin baik).
CPU dan memori
Dalam kondisi siaga, integrasi 1.1 1.1 dengan 105 perapian mengkonsumsi lebih sedikit prosesor dan memori dibandingkan dengan integrasi Docker 18.03 CE dengan dockershim. Hasilnya dapat bervariasi tergantung pada jumlah perapian yang diluncurkan pada node - jumlah 105 perapian dipilih, karena default sekarang adalah nilai maksimum untuk custom hearths pada node.
Seperti yang dapat dilihat dari grafik di bawah ini, integrasi integrasi 1.1 dengan
Kubelet mengkonsumsi CPU 30,89% lebih sedikit dan memori RSS 11,30% lebih sedikit (resident set size), serta 12,78% lebih sedikit memori RSS yang dikonsumsi oleh runtime kontainer .
Tambahan dari penerjemah
Perlu diperhatikan bahwa solusi alternatif lain, CRI-O , terus berkembang. Secara khusus, pada KTT Open Source Jepang 2018 hari ini, seorang karyawan NTT menyajikan laporan dengan perbandingan luas dari lingkungan yang dapat dieksekusi yang ada untuk kontainer. Dan inilah salah satu slide yang membandingkan kinerja mereka:
crictl
Container Runtime Console Interface (CLI) adalah alat yang berguna untuk mengidentifikasi masalah dalam sistem dan aplikasi. Saat menggunakan Docker sebagai lingkungan wadah di Kubernetes, administrator sistem terkadang pergi ke situs Kubernetes untuk menjalankan perintah Docker dan mengumpulkan informasi tentang sistem dan / atau aplikasi. Misalnya, mereka dapat menggunakan
docker ps dan
docker inspect untuk memeriksa status proses,
docker images untuk mendapatkan daftar gambar pada node,
docker info untuk mendapatkan konfigurasi runtime untuk wadah, dll.
Untuk contenterd dan semua lingkungan yang kompatibel dengan CRI lainnya seperti dockershim, kami sarankan menggunakan
crictl sebagai alternatif CLI untuk perintah konsol Docker untuk menganalisis masalah pada pod, wadah, dan gambar kontainer yang di-host di node Kubernetes.
crictl adalah utilitas yang menawarkan fitur yang mirip dengan Docker CLI dan berfungsi sama baiknya untuk semua lingkungan runtime untuk wadah yang kompatibel dengan CRI. Itu dapat ditemukan di
repositori kubernetes-incubator / cri-tools ; versi saat ini adalah
cri-tools v1.11.0 (versi ini telah diperbaiki untuk rilis saat ini 3 hari lalu alih-alih v1.0.0-beta.1 , ditunjukkan dalam artikel asli, kira-kira terjemahan. ) . Meskipun utilitas
crictl dirancang agar mirip dengan Docker CLI, menawarkan transisi sederhana bagi pengguna, itu bukan salinan lengkapnya. Beberapa perbedaan penting dijelaskan di bawah ini.
Penggunaan terbatas: crictl adalah alat pemecahan masalah
crictl bukan pengganti
kubectl docker atau
kubectl - penggunaannya terbatas pada ruang lingkup identifikasi dan analisis masalah. Antarmuka Docker konsol menawarkan serangkaian perintah yang kaya, menjadikannya alat pengembangan yang sangat berguna. Namun, ini bukan opsi terbaik untuk pemecahan masalah pada node Kubernetes. Beberapa perintah Docker (mis.
docker network dan
docker build ) tidak berguna untuk Kubernetes, dan beberapa (mis. Nama
docker rename ) dapat merusak segalanya. Tujuan dari
crictl adalah untuk menyediakan perintah yang cukup untuk mengidentifikasi masalah pada node yang aman digunakan di lingkungan produksi.
Fokus Kubernetes
crictl menawarkan tampilan kontainer yang lebih dimengerti di dunia Kubernetes. Antarmuka konsol Docker tidak beroperasi dengan konsep Kubernet dasar, seperti di bawah (pod) dan namespace (
namespace ), yang mencegah representasi visual dari wadah dan perapian
(pentingnya masalah ini benar, sudah dalam konteks pemantauan, baru-baru ini kita bicarakan dalam laporan ini - catatan .perev. ) . Salah satu contohnya adalah
docker ps menunjukkan nama lama yang tidak jelas untuk wadah Docker dan daftar wadah jeda bersama dengan wadah aplikasi:
Namun,
wadah jeda adalah bagian dari implementasi perapian, di mana satu wadah tersebut digunakan untuk masing-masing perapian; mereka tidak boleh ditampilkan saat menampilkan wadah yang merupakan bagian dari perapian.
crictl , sebaliknya, diciptakan untuk Kubernetes. Utilitas ini menyediakan serangkaian perintah berbeda untuk perapian dan wadah. Misalnya,
crictl pods menampilkan informasi tentang
crictl pods , dan
crictl ps hanya menampilkan informasi tentang wadah aplikasi. Semua data diformat dalam tampilan tabel:
Contoh lain - di
crictl pods terdapat argumen
--namespace , yang memungkinkan pemfilteran pod berdasarkan namespaces yang didefinisikan dalam Kubernetes:
Untuk informasi lebih lanjut tentang cara menggunakan crictl dengan contenterd, lihat di sini:
Tapi bagaimana dengan Docker Engine?
Kita sering mendengar pertanyaan berikut: "Apakah beralih ke contenterd berarti bahwa saya tidak bisa lagi menggunakan Docker Engine?", Dan jawaban singkatnya adalah "TIDAK".
Docker Engine dibangun berdasarkan contenterd. Rilis Docker Community Edition (Docker CE) selanjutnya akan menggunakan contenterd versi 1.1. Dengan demikian, itu akan memiliki built-in dan diaktifkan oleh plugin CRI default. Ini berarti bahwa pengguna akan memiliki kesempatan untuk terus bekerja dengan Docker Engine untuk skenario tipikal lainnya, serta kemampuan untuk mengkonfigurasi Kubernetes untuk menggunakan contenterd yang mendasarinya yang datang dengan Docker Engine dan yang secara bersamaan digunakan oleh Docker Engine pada host yang sama. Lihatlah diagram arsitektur di bawah ini yang menunjukkan bagaimana konten yang sama digunakan oleh Docker Engine dan
Kubelet :
Karena
contenterd digunakan oleh
Kubelet dan Docker Engine, pengguna yang memilih untuk berintegrasi dengan contenterd tidak hanya akan mendapatkan semua fitur baru untuk Kubernetes, peningkatan kinerja dan stabilitas, tetapi juga opsi untuk menggunakan Docker Engine, seperti sebelumnya, untuk kebutuhan lainnya.
Mekanisme
namespace di
contenterd memastikan bahwa
Kubelet dan Docker Engine tidak akan memiliki akses ke kontainer dan gambar yang tidak dibuat oleh mereka. Ini berarti bahwa mereka tidak akan saling mengganggu, juga:
- Pengguna yang memasuki perintah
docker ps tidak akan melihat wadah yang dibuat di Kubernetes. Gunakan crictl ps untuk ini. Sebaliknya, pengguna tidak akan melihat wadah yang dibuat di Docker CLI di Kubernetes atau perintah crictl ps . Perintah crictl create dan crictl run hanya untuk pemecahan masalah. Tidak dianjurkan menjalankan perapian atau wadah secara manual menggunakan crictl pada simpul produksi. - Pengguna yang memasuki
docker images tidak akan melihat gambar dari Kubernetes. Untuk melakukan ini, gunakan perintah crictl images . Sebaliknya, Kubernetes tidak akan melihat gambar yang dibuat oleh docker pull , docker load dan docker build commands. Untuk melakukan ini, gunakan perintah crictl pull , serta ctr cri load , jika Anda ingin memuat gambar.
Ringkasan
- Containerd 1.1 memiliki dukungan CRI asli. Itu dapat digunakan langsung oleh Kubernetes.
- Containerd 1.1 siap diproduksi.
- Containerd 1.1 memiliki kinerja yang baik dalam hal waktu mulai pod dan pemanfaatan sumber daya sistem.
- crictl adalah utilitas konsol (CLI) untuk berkomunikasi dengan containerd 1.1 dan lingkungan runtime lainnya untuk kontainer yang mematuhi CRI untuk mengidentifikasi masalah pada node.
- Containerd 1.1 akan dimasukkan dalam rilis stabil berikutnya Docker CE. Pengguna akan dibiarkan dengan opsi untuk terus bekerja dengan Docker dalam kasus non-Kubernetes dan mengonfigurasi Kubernetes untuk menggunakan server konten yang mendasarinya yang merupakan bagian dari Docker.
Kami ingin mengucapkan terima kasih kepada semua orang dari Google, IBM, Docker, ZTE, ZJU dan pengembang individual yang telah berkontribusi dan membuat semua ini menjadi mungkin!
Untuk daftar terperinci dari perubahan dalam konten 1.1, lihat
Catatan Rilis .
Bagaimana cara mencoba
Petunjuk untuk menyiapkan kluster Kubernet untuk menggunakan contenterd sebagai runtime default:
- untuk sebuah cluster di GCE, dibesarkan menggunakan
kube-up.sh , - di sini ; - untuk menginstal sekelompok banyak node menggunakan Ansible dan kubeadm - di sini ;
- untuk membuat cluster dari awal di Google Cloud - lihat " Kubernetes the Hard Way ";
- untuk instalasi manual dari arsip tarball - di sini ;
- untuk instalasi menggunakan LinuxKit pada mesin virtual lokal - di sini .
Bagaimana cara berkontribusi
Plugin Containerd CRI - Proyek open source di GitHub, yang merupakan bagian dari containerd:
https://github.com/containerd/cri . Semua perubahan yang diajukan diterima dalam bentuk ide, tiket, koreksi.
Panduan memulai pengembang ini adalah titik awal yang baik untuk melakukan perubahan.
PS dari penerjemah
Baca juga di blog kami: