Docker Swarm, Kubernetes, dan Mesos adalah framework orkestrasi container yang paling populer. Dalam ceramahnya, Arun Gupta membandingkan aspek Docker, Swarm, dan Kubernetes berikut ini:
- Pembangunan lokal.
- Fungsi penerapan.
- Aplikasi multi-kontainer.
- Penemuan layanan.
- Menskalakan layanan.
- Tugas dijalankan sekali.
- Integrasi dengan Maven.
- Pembaruan "bergulir".
- Membuat klaster database Couchbase.
Hasilnya, Anda akan memperoleh pemahaman yang jelas tentang apa yang ditawarkan setiap alat orkestrasi dan mempelajari cara menggunakan platform ini secara efektif.
Arun Gupta adalah kepala teknolog untuk produk sumber terbuka di Amazon Web Services, yang telah mengembangkan komunitas pengembang Sun, Oracle, Red Hat, dan Couchbase selama lebih dari 10 tahun. Memiliki pengalaman luas bekerja dalam memimpin tim lintas fungsi yang mengembangkan dan menerapkan strategi untuk kampanye dan program pemasaran. Dia memimpin tim insinyur Sun, merupakan salah satu pendiri tim Java EE dan pencipta Devoxx4Kids cabang AS. Arun Gupta adalah penulis lebih dari 2 ribu postingan di blog IT dan telah memberikan ceramah di lebih dari 40 negara.
Baris 55 berisi COUCHBASE_URI yang menunjuk ke layanan database ini, yang juga dibuat menggunakan file konfigurasi Kubernetes. Jika Anda melihat baris 2, Anda dapat melihat jenis: Layanan adalah layanan yang saya buat bernama couchbase-service, dan nama yang sama tercantum pada baris 4. Di bawah ini adalah beberapa port.
Baris kuncinya adalah 6 dan 7. Dalam pelayanan saya berkata, "Hei, ini label yang saya cari!", dan label ini tidak lebih dari nama pasangan variabel, dan baris 7 menunjuk ke couchbase-rs-pod saya aplikasi. Berikut ini adalah port yang menyediakan akses ke label yang sama.
Pada baris 19 saya membuat ReplicaSet tipe baru, baris 31 berisi nama gambar, dan baris 24-27 menunjuk ke metadata yang terkait dengan pod saya. Inilah tepatnya yang dicari oleh layanan dan koneksi apa yang harus dibuat. Di akhir file ada semacam koneksi antara baris 55-56 dan 4, mengatakan: βgunakan layanan ini!β
Jadi, saya memulai layanan saya ketika ada kumpulan replika, dan karena setiap kumpulan replika memiliki portnya sendiri dengan label yang sesuai, maka itu disertakan dalam layanan. Dari sudut pandang pengembang, Anda cukup memanggil layanan tersebut, yang kemudian menggunakan kumpulan replika yang Anda perlukan.
Hasilnya, saya memiliki pod WildFly yang berkomunikasi dengan backend database melalui Layanan Couchbase. Saya dapat menggunakan frontend dengan beberapa pod WildFly, yang juga berkomunikasi dengan backend couchbase melalui layanan couchbase.
Nanti kita akan melihat bagaimana layanan yang terletak di luar cluster berkomunikasi melalui alamat IP-nya dengan elemen yang terletak di dalam cluster dan memiliki alamat IP internal.
Jadi, container stateless memang bagus, tapi seberapa baguskah menggunakan container stateful? Mari kita lihat pengaturan sistem untuk container stateful atau persisten. Di Docker, ada 4 pendekatan berbeda pada tata letak penyimpanan data yang harus Anda perhatikan. Yang pertama adalah Implisit Per-Container, yang berarti ketika menggunakan couchbase, MySQL atau MyDB satateful container, semuanya dimulai dengan Sandbox default. Artinya, segala sesuatu yang disimpan dalam database disimpan dalam wadah itu sendiri. Jika wadahnya hilang, datanya juga ikut hilang.
Yang kedua adalah Explicit Per-Container, ketika Anda membuat penyimpanan tertentu dengan perintah docker volume create dan menyimpan data di dalamnya. Pendekatan Per-Host ketiga dikaitkan dengan pemetaan penyimpanan, ketika semua yang disimpan dalam wadah diduplikasi secara bersamaan di host. Jika penampung gagal, data akan tetap ada di host. Yang terakhir adalah penggunaan beberapa host Multi-Host, yang disarankan pada tahap produksi berbagai solusi. Katakanlah wadah Anda dengan aplikasi Anda berjalan di host, tetapi Anda ingin menyimpan data Anda di suatu tempat di Internet, dan untuk ini Anda menggunakan pemetaan otomatis untuk sistem terdistribusi.
Masing-masing metode ini menggunakan lokasi penyimpanan tertentu. Data penyimpanan Per-Kontainer Implisit dan Eksplisit pada host di /var/lib/docker/volumes. Saat menggunakan metode Per-Host, penyimpanan dipasang di dalam container, dan container itu sendiri dipasang di host. Untuk multihost, solusi seperti Ceph, ClusterFS, NFS, dll dapat digunakan.
Jika kontainer persisten gagal, direktori penyimpanan menjadi tidak dapat diakses dalam dua kasus pertama, namun dalam dua kasus terakhir akses tetap dipertahankan. Namun, dalam kasus pertama, Anda dapat mengakses repositori melalui host Docker yang berjalan di mesin virtual. Dalam kasus kedua, data juga tidak akan hilang, karena Anda telah membuat penyimpanan Eksplisit.
Jika host gagal, direktori penyimpanan tidak tersedia dalam tiga kasus pertama; dalam kasus terakhir, koneksi dengan penyimpanan tidak terputus. Terakhir, fungsi bersama sepenuhnya dikecualikan untuk penyimpanan dalam kasus pertama dan dimungkinkan dalam kasus lainnya. Dalam kasus kedua, Anda dapat berbagi penyimpanan bergantung pada apakah database Anda mendukung penyimpanan terdistribusi atau tidak. Dalam kasus Per-Host, distribusi data hanya dimungkinkan pada host tertentu, dan untuk multihost disediakan melalui perluasan cluster.
Ini harus diperhitungkan saat membuat container stateful. Alat Docker lain yang berguna adalah plugin Volume, yang bekerja berdasarkan prinsip βbaterai ada, tetapi harus diganti.β Saat Anda memulai container Docker, dikatakan, βHei, setelah Anda memulai container dengan database, Anda dapat menyimpan data Anda di container ini!β Ini adalah fitur default, tetapi Anda dapat mengubahnya. Plugin ini memungkinkan Anda untuk menggunakan drive jaringan atau yang serupa daripada database kontainer. Ini mencakup driver default untuk penyimpanan berbasis host dan memungkinkan integrasi kontainer dengan sistem penyimpanan eksternal seperti Amazon EBS, Azure Storage, dan disk Persisten GCE.
Slide berikutnya menunjukkan arsitektur plugin Docker Volume.
Warna biru mewakili klien Docker yang terkait dengan host Docker biru, yang memiliki mesin penyimpanan lokal yang memberi Anda wadah untuk menyimpan data. Hijau menunjukkan Klien Plugin dan Daemon Plugin, yang juga terhubung ke host. Mereka memberikan kesempatan untuk menyimpan data dalam penyimpanan jaringan dari jenis Storage Backend yang Anda butuhkan.
Plugin Docker Volume dapat digunakan dengan penyimpanan Portworx. Modul PX-Dev sebenarnya adalah sebuah kontainer yang Anda jalankan yang terhubung ke host Docker Anda dan memungkinkan Anda menyimpan data dengan mudah di Amazon EBS.
Klien Portworx memungkinkan Anda memantau status berbagai kontainer penyimpanan yang terhubung ke host Anda. Jika Anda mengunjungi blog saya, Anda dapat membaca cara memanfaatkan Portworx dengan Docker secara maksimal.
Konsep penyimpanan di Kubernetes mirip dengan Docker dan diwakili oleh direktori yang dapat diakses oleh container Anda di dalam pod. Mereka tidak bergantung pada masa pakai wadah apa pun. Jenis penyimpanan paling umum yang tersedia adalah hostPath, nfs, awsElasticBlockStore, dan gsePersistentDisk. Mari kita lihat cara kerja toko-toko ini di Kubernetes. Biasanya proses penyambungannya terdiri dari 3 langkah.
Yang pertama adalah seseorang di sisi jaringan, biasanya administrator, memberi Anda penyimpanan persisten. Ada file konfigurasi PersistentVolume yang sesuai untuk ini. Selanjutnya, pengembang aplikasi menulis file konfigurasi bernama PersistentVolumeClaim, atau permintaan penyimpanan PVC, yang berbunyi: βSaya memiliki penyimpanan terdistribusi sebesar 50 GB yang disediakan, tetapi agar orang lain juga dapat menggunakan kapasitasnya, saya memberi tahu PVC ini bahwa saya saat ini hanya perlu 10 GB". Terakhir, langkah ketiga adalah permintaan Anda dipasang sebagai penyimpanan, dan aplikasi yang memiliki pod, atau kumpulan replika, atau yang serupa, mulai menggunakannya. Penting untuk diingat bahwa proses ini terdiri dari 3 langkah yang disebutkan dan dapat diskalakan.
Slide berikutnya menunjukkan Kubernetes Persistence Container dari arsitektur AWS.
Di dalam persegi panjang berwarna coklat yang mewakili cluster Kubernetes, terdapat satu node master dan dua node pekerja, ditandai dengan warna kuning. Salah satu node pekerja berisi pod oranye, penyimpanan, pengontrol replika, dan kontainer Docker Couchbase hijau. Di dalam cluster, di atas node, persegi panjang ungu menunjukkan Layanan dapat diakses dari luar. Arsitektur ini direkomendasikan untuk menyimpan data pada perangkat itu sendiri. Jika perlu, saya bisa menyimpan data saya di EBS di luar cluster, seperti yang ditunjukkan pada slide berikutnya. Ini adalah model penskalaan yang umum, namun ada aspek finansial yang perlu dipertimbangkan saat menggunakannya - menyimpan data di suatu tempat di jaringan bisa lebih mahal daripada di host. Saat memilih solusi containerisasi, ini adalah salah satu argumen yang penting.
Sama seperti Docker, Anda dapat menggunakan container Kubernetes persisten dengan Portworx.
Inilah yang dalam terminologi Kubernetes 1.6 saat ini disebut sebagai βStatefulSetβ - sebuah cara bekerja dengan aplikasi Stateful yang memproses event tentang penghentian Pod dan melakukan Graceful Shutdown. Dalam kasus kami, aplikasi tersebut adalah database. Di blog saya, Anda dapat membaca cara membuat StatefulSet di Kubernetes menggunakan Portworx.
Mari kita bicara tentang aspek pengembangan. Seperti yang saya katakan, Docker memiliki 2 versi - CE dan EE, dalam kasus pertama kita berbicara tentang versi stabil dari Edisi Komunitas, yang diperbarui setiap 3 bulan sekali, berbeda dengan versi EE yang diperbarui setiap bulan. Anda dapat mengunduh Docker untuk Mac, Linux atau Windows. Setelah diinstal, Docker akan diperbarui secara otomatis dan sangat mudah untuk memulainya.
Untuk Kubernetes, saya lebih suka versi Minikube - ini adalah cara yang baik untuk memulai platform dengan membuat cluster pada satu node. Untuk membuat cluster dari beberapa node, pilihan versinya lebih luas: ini adalah kops, kube-aws (CoreOS+AWS), kube-up (ketinggalan jaman). Jika Anda ingin menggunakan Kubernetes berbasis AWS, saya sarankan untuk bergabung dengan AWS SIG, yang mengadakan pertemuan online setiap hari Jumat dan menerbitkan berbagai materi menarik tentang bekerja dengan AWS Kubernetes.
Mari kita lihat bagaimana Rolling Update dilakukan pada platform ini. Jika ada cluster yang terdiri dari beberapa node, maka ia menggunakan versi gambar tertentu, misalnya WildFly:1. Pembaruan berkelanjutan berarti versi gambar diganti secara berurutan dengan yang baru di setiap node, satu demi satu.
Untuk melakukan ini, saya menggunakan perintah pembaruan layanan buruh pelabuhan (nama layanan), di mana saya menentukan versi baru dari gambar WildFly:2 dan metode pembaruan pembaruan-paralelisme 2. Angka 2 berarti sistem akan memperbarui 2 gambar aplikasi secara bersamaan, kemudian pembaruan 10 detik menunda 10 detik, setelah itu 2 gambar berikutnya akan diperbarui pada 2 node lagi, dll. Mekanisme pembaruan bergulir sederhana ini disediakan untuk Anda sebagai bagian dari Docker.
Di Kubernetes, pembaruan berkelanjutan berfungsi seperti ini. Pengontrol replikasi rc membuat satu set replika dari versi yang sama, dan setiap pod di webapp-rc ini dilengkapi dengan label yang terletak di etcd. Ketika saya membutuhkan sebuah pod, saya menggunakan Layanan Aplikasi untuk mengakses repositori etcd, yang memberi saya pod tersebut menggunakan label yang ditentukan.
Dalam hal ini, kami memiliki 3 pod di pengontrol Replikasi yang menjalankan aplikasi WildFly versi 1. Saat memperbarui di latar belakang, pengontrol replikasi lain dibuat dengan nama dan indeks yang sama di akhir - - xxxxx, di mana x adalah angka acak, dan dengan label yang sama. Sekarang Layanan Aplikasi memiliki tiga pod dengan aplikasi versi lama dan tiga pod dengan versi baru di pengontrol Replikasi baru. Setelah itu, pod lama akan dihapus, pengontrol replikasi dengan pod baru diganti namanya dan dioperasikan.
Mari beralih ke pemantauan. Docker memiliki banyak perintah pemantauan bawaan. Misalnya, antarmuka baris perintah statistik kontainer buruh pelabuhan memungkinkan Anda menampilkan informasi tentang status kontainer ke konsol setiap detik - penggunaan prosesor, penggunaan disk, beban jaringan. Alat Docker Remote API menyediakan data tentang cara klien berkomunikasi dengan server. Ini menggunakan perintah sederhana, tetapi didasarkan pada Docker REST API. Dalam hal ini kata REST, Flash, Remote memiliki arti yang sama. Saat Anda berkomunikasi dengan host, itu adalah REST API. Docker Remote API memungkinkan Anda mendapatkan informasi lebih lanjut tentang menjalankan container. Blog saya menguraikan rincian penggunaan pemantauan ini dengan Windows Server.
Memantau kejadian sistem buruh pelabuhan saat menjalankan cluster multi-host memungkinkan untuk memperoleh data tentang kerusakan host atau kerusakan kontainer pada host tertentu, layanan penskalaan, dan sejenisnya. Dimulai dengan Docker 1.20, ini menyertakan Prometheus, yang menyematkan titik akhir ke dalam aplikasi yang sudah ada. Ini memungkinkan Anda menerima metrik melalui HTTP dan menampilkannya di dasbor.
Fitur pemantauan lainnya adalah cAdvisor (kependekan dari container Advisor). Ini menganalisis dan menyediakan data penggunaan sumber daya dan kinerja dari container yang sedang berjalan, menyediakan metrik Prometheus langsung dari kotaknya. Keistimewaan alat ini adalah hanya menyediakan data selama 60 detik terakhir. Oleh karena itu, Anda harus bisa mengumpulkan data tersebut dan memasukkannya ke dalam database agar Anda bisa memantau prosesnya dalam jangka panjang. Itu juga dapat digunakan untuk menampilkan metrik dasbor secara grafis menggunakan Grafana atau Kibana. Blog saya memiliki penjelasan rinci tentang cara menggunakan cAdvisor untuk memantau kontainer menggunakan dashboard Kibana.
Slide berikutnya menunjukkan seperti apa keluaran titik akhir Prometheus dan metrik yang tersedia untuk ditampilkan.
Di kiri bawah Anda melihat metrik untuk permintaan HTTP, tanggapan, dll., di sebelah kanan adalah tampilan grafisnya.
Kubernetes juga menyertakan alat pemantauan bawaan. Slide ini menunjukkan cluster tipikal yang berisi satu node master dan tiga node pekerja.
Setiap node yang berfungsi berisi cAdvisor yang diluncurkan secara otomatis. Selain itu, terdapat Heapster, sistem pemantauan kinerja dan pengumpulan metrik yang kompatibel dengan Kubernetes versi 1.0.6 dan lebih tinggi. Heapster memungkinkan Anda mengumpulkan tidak hanya metrik kinerja beban kerja, pod, dan kontainer, tetapi juga peristiwa dan sinyal lain yang dihasilkan oleh seluruh cluster. Untuk mengumpulkan data, ia berkomunikasi dengan Kubelet masing-masing pod, secara otomatis menyimpan informasi dalam database InfluxDB, dan mengeluarkannya sebagai metrik ke dasbor Grafana. Namun perlu diingat bahwa jika Anda menggunakan miniKube, fitur ini tidak tersedia secara default, jadi Anda harus menggunakan add-on untuk pemantauan. Jadi semuanya tergantung di mana Anda menjalankan container dan alat pemantauan mana yang dapat Anda gunakan secara default dan mana yang perlu Anda instal sebagai add-on terpisah.
Slide berikutnya menampilkan dasbor Grafana yang menunjukkan status berjalannya container saya. Ada cukup banyak data menarik di sini. Tentu saja, ada banyak alat pemantauan proses Docker dan Kubernetes komersial, seperti SysDig, DataDog, NewRelic. Beberapa di antaranya memiliki masa uji coba gratis selama 30 tahun, jadi Anda dapat mencoba dan menemukan salah satu yang paling cocok untuk Anda. Secara pribadi, saya lebih suka menggunakan SysDig dan NewRelic, yang terintegrasi dengan baik dengan Kubernetes. Ada alat yang terintegrasi dengan baik ke dalam platform Docker dan Kubernetes.
Beberapa iklan π
Terima kasih untuk tetap bersama kami. Apakah Anda menyukai artikel kami? Ingin melihat konten yang lebih menarik? Dukung kami dengan melakukan pemesanan atau merekomendasikan kepada teman, , analog unik dari server level awal, yang kami temukan untuk Anda: (tersedia dengan RAID1 dan RAID10, hingga 24 core dan hingga 40GB DDR4).
Dell R730xd 2x lebih murah di pusat data Equinix Tier IV di Amsterdam? Hanya disini di Belanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - mulai $99! Membaca tentang
Sumber: www.habr.com