Hari ini, kami sangat senang mempersembahkan Laporan Penggunaan Kontainer Sysdig untuk 2019 ( Sysdig 2019 Laporan Penggunaan Kontainer ). Kubernet terus mendapatkan momentum, arsitektur cloud semakin mengeksplorasi, dan semua ini berubah tidak hanya pola penggunaan, tetapi juga proses dan struktur organisasi. Anehnya, tahun ini jumlah kontainer berlipat ganda, umurnya tidak lebih dari 5 menit. Semakin layanan dinamis, tim cloud yang lebih baik mengenali kebutuhan untuk mengintegrasikan keamanan ke dalam proses DevOps. Sebagai bagian dari laporan penggunaan kami untuk 2019, kami sedang mengeksplorasi detail keamanan dan kepatuhan untuk pertama kalinya, di samping sejumlah detail tentang bagaimana pelanggan menggunakan kontainer, Kubernetes, dan banyak lagi.
Posisi Sysdig Unik
Sysdig Secure DevOps Platform memberikan perspektif nyata tentang infrastruktur, aplikasi, dan wadah. Laporan kami mencakup perusahaan di seluruh dunia dan di banyak daerah. Tahun ini kami menyertakan perincian tentang pengguna lokal SaaS dan Sysdig untuk memberi Anda gambaran penggunaan komersial dua juta kontainer yang digunakan sebagai contoh.
Lebih lanjut tentang hasilnya.
Dalam laporan 2018 kami, kami menggambarkan bagaimana Open Container Initiative (OCI) membantu memperkenalkan lingkungan peluncuran wadah alternatif. Pada tahun 2019, ini terjadi dalam skala besar: proyek containerd meraih bagian yang signifikan sebesar 18%. Dalam keadilan, perlu dicatat bahwa contenterd digunakan oleh Docker. Sebelumnya, mesinnya mengimplementasikan fungsi level tinggi dan level rendah dari lingkungan peluncuran. Sekarang mereka dibagi menjadi dua proyek terpisah: containerd dan runc.
CRI-O memulai debutnya tahun ini. Di antara hal-hal lain, kami dikejutkan oleh rendahnya tingkat perkembangan saat ini. CRI-O, runtime ringan Kubernetes, muncul di Red Hat pada 2016 dan diterima ke CNCF © pada 2019. Kami pikir tingkat pengembangan akan meningkat segera setelah pengguna Red Hat OpenShift bermigrasi dari v3 ke v4, di mana CRI-O menggantikan mesin Docker yang sebelumnya diadopsi.
Kepadatan kontainer di server fisik tumbuh 100%
Selama tahun lalu, jumlah rata-rata kontainer per server fisik telah meningkat menjadi 30, dua kali lipat dibandingkan dengan 15 pada tahun 2018 dan 10 pada tahun 2017.
Kami percaya bahwa angka ini akan meningkat berdasarkan beberapa faktor:
- Peningkatan jumlah aplikasi yang dimigrasi ke infrastruktur cloud;
- Memasukkan data dari klien Sysdig lokal yang menjalankan kelompok yang lebih besar dan lebih padat;
- Pertumbuhan komputasi "tenaga kuda", memungkinkan lebih banyak kontainer bekerja di setiap server.
Pada tahun 2019, kepadatan kontainer maksimum per node adalah 250, dan ini adalah peningkatan 38 persen dibandingkan dengan 2018.
Container Orchestra: Kubernetes Dominates
Tidak mengherankan bahwa sebagai instrumen de facto orkestrasi, Kubernetes mengambil sebanyak 77% bagian dari orkestrator bekas. Jumlah ini akan meningkat menjadi 89% jika Anda menambahkan Red Hat OpenShift dan Rancher - keduanya dibangun di atas Kubernetes. Dan inilah situasi saat ini dalam jumlah:
Jika Anda memisahkan data untuk perusahaan yang menggunakan platform Sysdig secara lokal, gambar orkestrasi berubah secara signifikan. Di segmen ini, Platform Red Hat OpenShift Container memimpin. Alasan utamanya adalah organisasi pengguna, biasanya besar dan berhati-hati, ingin memanfaatkan Kubernetes, tetapi lebih suka melakukan ini dengan solusi lokal yang didukung secara komersial seperti Platform as a Service (PaaS), seperti OpenShift.
Juga dalam laporan 2019, kami memeriksa statistik tentang penggunaan cloud publik. Unduh untuk detailnya .
Keamanan dan Kepatuhan
"Terapkan keamanan di muka" telah menjadi ungkapan obsesif. Ini menggambarkan suatu pendekatan di mana keamanan tertanam pada tahap awal siklus hidup pengembangan. Secara umum, organisasi wadah memahami bagaimana mengintegrasikan keamanan dan kepatuhan ke dalam alur kerja DevOps. Untuk mendapatkan wawasan tentang keamanan dan kepatuhan dalam wadah dan Kubernet, kami menganalisis data dari bidang pemindaian kerentanan, keamanan lingkungan startup, dan kepatuhan CIS.
Manajemen Kerentanan
Klien memindai gambar untuk mendeteksi, memblokir, dan menghilangkan kerentanan kontainer di jalur pipa CI / CD dan registrasi kontainer. Dalam laporan lengkap, kami melihat daftar yang digunakan, persentase gambar yang diambil dari repositori publik dan swasta. Kami juga memberikan rasio pemindaian gambar yang berhasil / tidak berhasil untuk kerentanan. Berikut ini beberapa kesimpulannya.
Ekstraksi Gambar: Repositori Publik vs Pribadi
Berapa banyak kontainer yang diambil dari repositori publik atau pribadi? Kami menemukan bahwa 40% gambar berasal dari sumber yang tersedia untuk umum.
Menggunakan gambar kontainer dari repositori terbuka sudah penuh - karena hanya sedikit dari mereka yang memenuhi standar atau diperiksa untuk kerentanan keamanan. Ambil, misalnya, Docker Hub : gambar berlabel "Bersertifikat," "Resmi," dan "Penerbit Terverifikasi" lebih dapat dipercaya. Namun, dari tiga juta gambar yang dihosting di server, kurang dari 1% memiliki sebutan tersebut. Untuk mengurangi risiko, tim cloud membuat kebijakan untuk menentukan registrasi kontainer mana yang dapat disetujui untuk digunakan dalam organisasi mereka.
Pemindaian gambar
Apa pun sumbernya, memindai gambar untuk mengetahui kerentanan sebelum menyebarkannya ke lingkungan produksi adalah praktik terbaik yang tidak dapat diabaikan. Untuk menilai tingkat risiko atau kerentanan, kami mengambil sampel gambar yang lulus dan gagal pemindaian, dipindai selama periode 5 hari. Lebih dari setengah gambar tidak lulus tes, yang berarti bahwa kerentanan yang diketahui dari tingkat bahaya yang tinggi dan sangat tinggi diidentifikasi di dalamnya.
Risiko Keamanan
Setelah pengembang mengatasi masalah yang diketahui, tim cloud harus menetapkan kebijakan yang menentukan perilaku abnormal dan memaksakan peringatan keamanan untuk dipicu dalam lingkungan produksi. Lingkungan startup keamanan untuk Kubernetes adalah sesuatu yang baru untuk perusahaan, tetapi mereka memahami apa itu, dengan cepat. Selama tahun lalu, Falco , proyek keamanan sumber terbuka CNCF untuk meluncurkan keamanan lingkungan, menyumbang Sysdig dari Docker Hub 6,7 juta kali. Ini adalah 252% lebih dari tahun sebelumnya.
Kami melihat pelanggaran kebijakan dalam konteks volume peringatan yang diterima klien dari Sysdig Secure, yang mengotomatiskan keamanan lingkungan peluncuran dengan kebijakan Falco. Ini mengidentifikasi jenis risiko keamanan yang paling umum ditemui oleh pengguna kontainer. Di antara mereka, yang paling umum adalah:
1 - Upaya untuk mengakses volume sensitif, direktori, atau file; 2 - Memulai dengan terlalu banyak izin atau upaya untuk memperluas hak istimewa; 3 - Meluncurkan shell perintah dari terminal yang terpasang
Dalam laporan lengkap tentang penggunaannya, kami memeriksa secara rinci 10 pelanggaran, memeringkatnya berdasarkan frekuensi, dan pada saat yang sama menggambarkan masing-masing, menjelaskan potensi ancaman.
Kepatuhan
Untuk mengurangi risiko dan memenuhi standar kepatuhan, termasuk PCI-DSS, HIPAA, dan GDPR, organisasi harus secara teratur meninjau server dan kontainer menggunakan praktik terbaik. Audit yang dilakukan menggunakan tolok ukur internal CIS untuk pemeriksaan Docker di Sysdig Secure menunjukkan bahwa masih ada ruang untuk perbaikan. Sebagai contoh, kami menemukan bahwa biasanya pada server kontainer ada:
10 Solusi Open Source Kontainer Terbaik
Open-source telah mengubah wajah pemrosesan data di seluruh perusahaan. Itu tidak hanya mendorong inovasi di seluruh infrastruktur, tetapi juga terutama dalam pengembangan aplikasi. Sysdig secara otomatis membuka proses di dalam wadah untuk melihat solusi yang membentuk layanan cloud yang dijalankan oleh pelanggan kami di lingkungan produksi. Dan inilah 10 teratas dari mereka:
Dari produk-produk baru tahun ini adalah Node.js dan Go (alias golang), yang berada di depan Jawa dalam hal penggunaan. Java memang dianggap sebagai salah satu bahasa pemrograman yang luar biasa. DevOps dan tim cloud tampaknya lebih suka opsi yang lebih baru, seperti Go, yang dibuat oleh insinyur Google, sebagian karena mereka lebih mudah digunakan. Misalnya, Node.js, kerangka kerja JavaScript, membuatnya mudah untuk menulis kode yang berfungsi sama baiknya di kedua server dan browser. Ini juga cocok untuk generasi baru dari basis data seperti CouchDB dan MongoDB yang mendukung permintaan yang ditulis JavaScript.
Kehidupan Kontainer
Parameter berapa lama (atau seberapa sedikit) wadah hidup, gambar dan layanan kontainer adalah salah satu topik paling populer dalam laporan kami untuk 2018. Ini mencerminkan bagaimana aplikasi modern lebih dinamis, baik dalam hal pengembangan maupun dalam hal runtime.
Kehidupan kontainer pendek
Membandingkan tahun demi tahun kehidupan kontainer, kami menemukan bahwa jumlah kontainer yang hidup kurang dari 10 detik menjadi dua kali lipat dan berjumlah 22%. Pada saat yang sama, jumlah kontainer yang hidup 5 menit atau kurang juga dua kali lipat.
Banyak wadah memerlukan umur pendek untuk hanya memenuhi fungsi dan segera merusak diri sendiri. Detik adalah, tampaknya, tidak cukup, tetapi untuk beberapa proses lebih banyak tidak diperlukan. Kami percaya bahwa peningkatan penggunaan Kubernetes Jobs, yang menjalankan tugas akhir seperti pekerjaan batch, berkontribusi terhadap pertumbuhan ini. Untuk mengatakan lebih banyak, kami mengharapkan peningkatan jumlah kontainer yang rendah, terutama pada platform tanpa server yang cocok untuk menjalankan tugas jangka pendek.
Sifat wadah yang sementara adalah salah satu keunggulan unik teknologi. Pada saat yang sama, itu sangat menyulitkan tugas-tugas seperti "lihat masalah dengan keamanan, kinerja dan kinerja." Alat pemantauan, keamanan, dan kepatuhan waktu-nyata yang memberikan daya pengamatan waktu nyata mengingat proses yang berlangsung singkat adalah kunci keberhasilan operasi.
Perkembangan dan umur gambar yang berkelanjutan
Wadah adalah teman yang sempurna untuk kelincahan. Mereka membantu mempercepat pengembangan dan pelepasan kode, seringkali dalam bentuk microseurise kemas. Kami menemukan bahwa lebih dari setengah gambar kontainer diganti - atau direvisi - dalam seminggu atau kurang. Ini merupakan indikasi seberapa singkat waktu antara rilis kode. Lebih lanjut, ini menunjukkan bahwa pipa CI / CD membantu tim pengembangan memberikan pembaruan perangkat lunak dengan kecepatan yang luar biasa cepat.
Metrik Kode Khusus
Metrik kode khusus memungkinkan pengembang dan tim DevOps menyesuaikan kode untuk mengumpulkan metrik unik. Dari tiga solusi mendasar: JMX, StatsD dan Prometheus, selama setahun terakhir, Prometheus telah muncul sebagai pemimpin dalam hal kegunaan. Bahkan, selama bertahun-tahun, penggunaan metrik Prometheus untuk pelanggan kami yang menggunakan metrik khusus telah tumbuh sebesar 130%. Metrik JMX (untuk aplikasi Java) dan StatsD semakin jarang digunakan (masing-masing 45% dan 17% tahun ini) karena penggunaan kerangka kerja pemrograman baru yang mendukung Prometheus sedang berkembang.
Untuk metrik dan eksportir teratas Prometheus yang digunakan oleh pelanggan Sysdig, lihat laporan lengkapnya.
Pengaturan darurat teratas
Pengaturan darurat klien Sysdig dengan jelas menunjukkan perintah cloud apa yang merupakan ancaman terbesar bagi operasi kontainer. Pengaturan darurat yang paling umum telah berubah dalam mendukung infrastruktur Kubernetes, sambil terus fokus pada pemanfaatan sumber daya dan waktu aktif. Berikut adalah Top 3 dari 800 pengaturan darurat unik yang didistribusikan ke klien Sysdig:
Plus, peringatan dapat dikonfigurasi untuk tag tertentu atau pintasan cloud / Kubernetes. Katakanlah, dengan menggunakan contoh dari peringatan di atas, Anda dapat mengikat peringatan cpu.used.percent ke namespace individu dengan tipe "istio-system", atau ke nama Pod spesifik dari tipe "utusan" di dalam namespace. Lihat binding lansiran teratas dalam laporan lengkap.
Pola Penggunaan Kubernetes
Berapa banyak cluster yang dikelola pengguna? Berapa banyak pod pada setiap node? Apakah ada yang menggunakan Pekerjaan Kubernetes? Laporan 2019 menjawab pertanyaan-pertanyaan ini dan lainnya. Ini adalah contoh dari apa yang klien gunakan dengan Kubernetes.
Beberapa klien hanya menginstal beberapa cluster - satu lebih besar dan sedikit lebih kecil - sementara yang lain memiliki armada banyak cluster dengan berbagai ukuran. Tabel di bawah ini menunjukkan distribusi jumlah cluster dan jumlah node per cluster untuk klien platform Sysdig:
Sejumlah besar klien yang mengelola satu kelompok atau sejumlah kecil dari mereka menunjukkan bahwa banyak perusahaan baru mulai mengembangkan Kubernet. Hasil pengamatan juga dipengaruhi oleh penggunaan layanan yang dikelola Kubernetes di cloud publik. Dengan layanan seperti Amazon Elastic Kubernetes Service (EKS), Google Kubernetes Engine (GKE), Azure Kubernetes Service (AKS), dan IBM Cloud Kubernetes Service (IKS), pengguna dapat memutar dan memecah cluster secepat yang mereka inginkan.
Jumlah polong per cluster
Pod adalah objek terkecil yang dapat diterapkan di Kubernet. Mereka terdiri dari satu atau lebih kontainer dengan penyimpanan dan jaringan yang sama, serta spesifikasi tentang cara memulai kontainer. Berikut ini adalah analisis pengguna platform Sysdig:
Penting! Tabel ini telah diperbarui untuk memperbaiki kesalahan pada gambar asli. Terima kasih banyak untuk Chris Collins - alias @ChrisInDurham - karena memperhatikan masalahnya!
Jumlah Pods per server fisik
Pod ada di server fisik hingga semua prosesnya selesai, tetapi dapat dihapus ketika pindah ke server lain jika sumber daya tidak mencukupi atau kegagalan server fisik. Berikut ini adalah snapshot distribusi Pods ke server untuk pengguna platform Sysdig:
Informasi tentang jumlah ruang nama Kubernetes, penyebaran, StatefulSets, dan tugas tersedia dalam laporan lengkap.
Kesimpulan
Sejak laporan penggunaan terakhir kami, kepadatan kontainer dua kali lipat, dan jelas bahwa kecepatan pengembangan meningkat saat Anda terbiasa. Temuan kunci dari laporan tahunan ketiga kami menekankan perlunya perusahaan untuk mengambil langkah-langkah untuk mempersiapkan pertumbuhan cepat yang diharapkan:
- Organisasi harus berinvestasi dalam alat Kubernetes untuk menyederhanakan operasi yang dapat diskalakan.
- Observabilitas waktu-nyata, memberikan audit terperinci dan catatan analitik untuk wadah yang hidup rendah, sangat penting untuk keamanan operasi.
- Untuk mengatasi risiko runtime, tim cloud harus bertindak sekarang - dan mengintegrasikan keamanan ke dalam DevOps.
- Karena Prometheus memperkuat posisinya sebagai pemimpin dalam standar pengumpulan metrik aplikasi cloud, pengguna harus belajar bagaimana menggunakannya sambil memberikan keandalan dan skalabilitas.
Untuk mengetahui semua detail, unduh Laporan Penggunaan Sysdig penuh untuk 2019 .