Kubernetes adalah alat yang hebat untuk menjalankan container Docker di lingkungan produksi yang terklaster. Namun, ada masalah yang tidak dapat diselesaikan oleh Kubernetes. Untuk penerapan produksi yang sering dilakukan, kami memerlukan penerapan Biru/Hijau yang sepenuhnya otomatis untuk menghindari waktu henti dalam proses, yang juga perlu menangani permintaan HTTP eksternal dan melakukan pembongkaran SSL. Hal ini memerlukan integrasi dengan penyeimbang beban seperti ha-proxy. Tantangan lainnya adalah penskalaan semi-otomatis dari cluster Kubernetes itu sendiri ketika dijalankan di lingkungan cloud, misalnya melakukan penskalaan sebagian cluster di malam hari.
Meskipun Kubernetes tidak memiliki fitur-fitur ini secara langsung, Kubernetes menyediakan API yang dapat Anda gunakan untuk memecahkan masalah serupa. Alat untuk penerapan Biru/Hijau otomatis dan penskalaan kluster Kubernetes dikembangkan sebagai bagian dari proyek Cloud RTI, yang dibuat berdasarkan sumber terbuka.
Artikel ini, berupa transkrip video, menunjukkan kepada Anda cara menyiapkan Kubernetes bersama dengan komponen open source lainnya untuk menciptakan lingkungan siap produksi yang menerima kode dari git commit tanpa downtime dalam produksi.
Jadi, setelah Anda memiliki akses ke aplikasi Anda dari dunia luar, Anda dapat mulai menyiapkan otomatisasi sepenuhnya, yaitu membawanya ke tahap di mana Anda dapat melakukan git commit dan memastikan bahwa git commit ini berakhir di produksi. Tentu saja, saat menerapkan langkah-langkah ini, saat menerapkan penerapan, kami tidak ingin mengalami waktu henti. Jadi, otomatisasi apa pun di Kubernetes dimulai dengan API.
Kubernetes bukanlah alat yang dapat digunakan secara produktif. Tentu saja Anda bisa melakukan itu, menggunakan kubectl dan sebagainya, namun tetap saja API adalah hal yang paling menarik dan berguna tentang platform ini. Dengan menggunakan API sebagai serangkaian fungsi, Anda dapat mengakses hampir semua hal yang ingin Anda lakukan di Kubernetes. kubectl sendiri juga menggunakan REST API.
Ini adalah REST, jadi Anda bisa menggunakan bahasa atau alat apa pun untuk bekerja dengan API ini, namun hidup Anda akan menjadi lebih mudah dengan perpustakaan khusus. Tim saya menulis 2 perpustakaan seperti itu: satu untuk Java/OSGi dan satu lagi untuk Go. Yang kedua tidak sering digunakan, tetapi bagaimanapun juga, Anda memiliki hal-hal berguna ini. Mereka adalah proyek sumber terbuka yang berlisensi sebagian. Ada banyak perpustakaan untuk berbagai bahasa, sehingga Anda dapat memilih salah satu yang paling sesuai untuk Anda.
Jadi, sebelum Anda mulai mengotomatiskan penerapan Anda, Anda perlu memastikan bahwa prosesnya tidak akan mengalami downtime. Misalnya, tim kami melakukan penerapan produksi pada tengah hari ketika orang-orang paling banyak menggunakan aplikasi, jadi penting untuk menghindari penundaan dalam proses ini. Untuk menghindari downtime, 2 metode digunakan: penerapan biru/hijau atau pembaruan berkelanjutan. Dalam kasus terakhir, jika Anda menjalankan 5 replika aplikasi, replika tersebut akan diperbarui secara berurutan satu demi satu. Metode ini berfungsi dengan baik, tetapi tidak cocok jika Anda menjalankan versi aplikasi berbeda secara bersamaan selama proses penerapan. Dalam hal ini, Anda dapat memperbarui antarmuka pengguna saat backend menjalankan versi lama, dan aplikasi akan berhenti bekerja. Oleh karena itu, dari sudut pandang pemrograman, bekerja dalam kondisi seperti itu cukup sulit.
Inilah salah satu alasan mengapa kami lebih memilih menggunakan penerapan biru/hijau untuk mengotomatiskan penerapan aplikasi kami. Dengan metode ini, Anda harus memastikan bahwa hanya satu versi aplikasi yang aktif dalam satu waktu.
Mekanisme penerapan biru/hijau terlihat seperti ini. Kami menerima lalu lintas untuk aplikasi kami melalui ha-proxy, yang meneruskannya ke replika aplikasi yang berjalan dengan versi yang sama.
Saat penerapan baru dilakukan, kami menggunakan Deployer, yang diberikan komponen baru dan menerapkan versi baru. Menerapkan versi baru suatu aplikasi berarti serangkaian replika baru “dibangkitkan”, setelah itu replika versi baru ini diluncurkan dalam pod baru yang terpisah. Namun, ha-proxy tidak mengetahui apa pun tentangnya dan belum merutekan beban kerja apa pun ke dalamnya.
Oleh karena itu, pertama-tama, perlu dilakukan pemeriksaan kinerja pemeriksaan kesehatan versi baru untuk memastikan bahwa replika siap melayani beban.
Semua komponen penerapan harus mendukung beberapa bentuk pemeriksaan kesehatan. Ini bisa berupa pemeriksaan panggilan HTTP yang sangat sederhana, ketika Anda menerima kode dengan status 200, atau pemeriksaan yang lebih mendalam, di mana Anda memeriksa koneksi replika dengan database dan layanan lain, stabilitas koneksi lingkungan dinamis , dan apakah semuanya dimulai dan berfungsi dengan benar. Proses ini bisa jadi sangat rumit.
Setelah sistem memverifikasi bahwa semua replika yang diperbarui berfungsi, Deployer akan memperbarui konfigurasi dan meneruskan confd yang benar, yang akan mengkonfigurasi ulang ha-proxy.
Hanya setelah ini lalu lintas akan diarahkan ke pod dengan replika versi baru, dan pod lama akan hilang.
Mekanisme ini bukan merupakan fitur Kubernetes. Konsep penerapan Biru/hijau sudah ada sejak lama dan selalu menggunakan penyeimbang beban. Pertama, Anda mengarahkan semua lalu lintas ke aplikasi versi lama, dan setelah pembaruan, Anda mentransfernya sepenuhnya ke versi baru. Prinsip ini tidak hanya digunakan di Kubernetes.
Sekarang saya akan memperkenalkan Anda pada komponen penerapan baru - Deployer, yang melakukan pemeriksaan kesehatan, mengkonfigurasi ulang proxy, dan sebagainya. Ini adalah konsep yang tidak berlaku di dunia luar dan ada di dalam Kubernetes. Saya akan menunjukkan cara membuat konsep Deployer Anda sendiri menggunakan alat sumber terbuka.
Jadi, hal pertama yang dilakukan Deployer adalah membuat pengontrol replikasi RC menggunakan API Kubernetes. API ini membuat pod dan layanan untuk penerapan lebih lanjut, yaitu membuat cluster yang benar-benar baru untuk aplikasi kita. Segera setelah RC yakin bahwa replika telah dimulai, RC akan melakukan pemeriksaan Kesehatan pada fungsinya. Untuk melakukan ini, Deployer menggunakan perintah GET /health. Ini menjalankan pemindaian komponen yang sesuai dan memeriksa semua elemen yang mendukung pengoperasian cluster.
Setelah semua pod melaporkan kesehatannya, Deployer membuat elemen konfigurasi baru - penyimpanan terdistribusi etcd, yang digunakan secara internal oleh Kubernetes, termasuk menyimpan konfigurasi penyeimbang beban. Kami menulis data ke dll, dan alat kecil bernama confd memonitor dll untuk data baru.
Jika mendeteksi adanya perubahan pada konfigurasi awal, ia akan membuat file pengaturan baru dan mentransfernya ke ha-proxy. Dalam hal ini, ha-proxy melakukan boot ulang tanpa kehilangan koneksi apa pun dan mengatasi beban pada layanan baru yang memungkinkan versi baru aplikasi kami berfungsi.
Seperti yang Anda lihat, meskipun komponennya melimpah, tidak ada yang rumit di sini. Anda hanya perlu lebih memperhatikan API dan lain-lain. Saya ingin memberi tahu Anda tentang penerapan sumber terbuka yang kami gunakan sendiri - Amdatu Kubernetes Deployer.
Ini adalah alat untuk mengatur penerapan Kubernetes dan memiliki beberapa fitur berikut:
- Penyebaran Biru/Hijau;
- menyiapkan penyeimbang beban eksternal;
- manajemen deskriptor penerapan;
- mengelola penerapan aktual;
- memeriksa fungsionalitas Pemeriksaan Kesehatan selama penerapan;
- implementasi variabel lingkungan ke dalam pod.
Deployer ini dibangun di atas API Kubernetes dan menyediakan REST API untuk mengelola penanganan dan penerapan, serta API Websocket untuk streaming log selama proses penerapan.
Ini menempatkan data konfigurasi penyeimbang beban ke dalam dll, sehingga Anda tidak perlu menggunakan ha-proxy dengan dukungan siap pakai, tetapi dengan mudah menggunakan file konfigurasi penyeimbang beban Anda sendiri. Amdatu Deployer ditulis dalam Go, seperti Kubernetes itu sendiri, dan dilisensikan oleh Apache.
Sebelum saya mulai menggunakan versi penerapan ini, saya menggunakan deskriptor penerapan berikut, yang menentukan parameter yang saya perlukan.
Salah satu parameter penting dari kode ini adalah mengaktifkan tanda “useHealthCheck”. Kita perlu menentukan bahwa pemeriksaan kewarasan harus dilakukan selama proses penerapan. Pengaturan ini dapat dinonaktifkan ketika penerapan menggunakan kontainer pihak ketiga yang tidak perlu diverifikasi. Deskriptor ini juga menunjukkan jumlah replika dan URL frontend yang dibutuhkan ha-proxy. Di bagian akhir terdapat tanda spesifikasi pod "podspec", yang memanggil Kubernetes untuk mendapatkan informasi tentang konfigurasi port, image, dll. Ini adalah deskriptor JSON yang cukup sederhana.
Alat lain yang merupakan bagian dari proyek sumber terbuka Amdatu adalah Deploymentctl. Ini memiliki UI untuk mengonfigurasi penerapan, menyimpan riwayat penerapan, dan berisi webhook untuk panggilan balik dari pengguna dan pengembang pihak ketiga. Anda tidak boleh menggunakan UI karena Amdatu Deployer sendiri adalah REST API, namun antarmuka ini dapat membuat penerapan lebih mudah bagi Anda tanpa melibatkan API apa pun. Deploymentctl ditulis dalam OSGi/Vertx menggunakan Angular 2.
Sekarang saya akan mendemonstrasikan hal di atas di layar menggunakan rekaman yang sudah direkam sebelumnya sehingga Anda tidak perlu menunggu. Kami akan menerapkan aplikasi Go sederhana. Jangan khawatir jika Anda belum pernah mencoba Go sebelumnya, ini adalah aplikasi yang sangat sederhana sehingga Anda pasti bisa mengetahuinya.
Di sini kita membuat server HTTP yang hanya merespons /kesehatan, jadi aplikasi ini hanya menguji pemeriksaan kesehatan dan tidak ada yang lain. Jika pemeriksaan berhasil, struktur JSON yang ditunjukkan di bawah ini akan digunakan. Ini berisi versi aplikasi yang akan diterapkan oleh deployer, pesan yang Anda lihat di bagian atas file, dan tipe data boolean - apakah aplikasi kita berfungsi atau tidak.
Saya sedikit curang dengan baris terakhir, karena saya menempatkan nilai boolean tetap di bagian atas file, yang di masa depan akan membantu saya menyebarkan bahkan aplikasi yang "tidak sehat". Kita akan membahasnya nanti.
Jadi mari kita mulai. Pertama, kami memeriksa keberadaan pod yang berjalan menggunakan perintah ~ kubectl get pods dan, berdasarkan tidak adanya respons dari URL frontend, kami memastikan bahwa tidak ada penerapan yang sedang dilakukan.
Selanjutnya di layar Anda melihat antarmuka Deploymentctl yang saya sebutkan, di mana parameter penerapan ditetapkan: namespace, nama aplikasi, versi penerapan, jumlah replika, URL front-end, nama kontainer, gambar, batas sumber daya, nomor port untuk pemeriksaan kesehatan, dll. . Batasan sumber daya sangat penting karena memungkinkan Anda menggunakan perangkat keras sebanyak mungkin. Di sini Anda juga dapat melihat log Deployment.
Jika sekarang Anda mengulangi perintah ~ kubectl get pods, Anda dapat melihat bahwa sistem “membeku” selama 20 detik, selama itu ha-proxy dikonfigurasi ulang. Setelah ini, pod dimulai, dan replika kami dapat dilihat di log penerapan.
Saya menghentikan waktu tunggu 20 detik dari video, dan sekarang Anda dapat melihat di layar bahwa versi pertama aplikasi telah diterapkan. Semua ini dilakukan hanya dengan menggunakan UI.
Sekarang mari kita coba versi kedua. Untuk melakukan ini, saya mengubah pesan aplikasi dari "Halo, Kubernetes!" pada "Halo, Deployer!", sistem membuat gambar ini dan menempatkannya di registri Docker, setelah itu kita cukup mengklik tombol "Deploy" lagi di jendela Deploymentctl. Dalam hal ini, log penerapan diluncurkan secara otomatis dengan cara yang sama seperti yang terjadi saat menerapkan versi pertama aplikasi.
Perintah ~ kubectl get pods menunjukkan bahwa saat ini ada 2 versi aplikasi yang berjalan, namun pada frontend terlihat kita masih menjalankan versi 1.
Penyeimbang beban menunggu hingga pemeriksaan kesehatan selesai sebelum mengalihkan lalu lintas ke versi baru. Setelah 20 detik, kami beralih ke curl dan melihat bahwa kami sekarang memiliki aplikasi versi 2 yang diterapkan, dan yang pertama telah dihapus.
Ini adalah penerapan aplikasi yang “sehat”. Mari kita lihat apa yang terjadi jika untuk aplikasi versi baru saya mengubah parameter Sehat dari benar menjadi salah, yaitu saya mencoba menerapkan aplikasi tidak sehat yang gagal dalam pemeriksaan kesehatan. Hal ini dapat terjadi jika beberapa kesalahan konfigurasi terjadi pada aplikasi pada tahap pengembangan, dan dikirim ke produksi dalam bentuk ini.
Seperti yang bisa kamu lihat, penerapannya melalui semua langkah di atas dan ~kubectl get pods menunjukkan bahwa kedua pod sedang berjalan. Namun tidak seperti penerapan sebelumnya, log menunjukkan status batas waktu. Artinya, karena pemeriksaan kesehatan gagal, versi baru aplikasi tidak dapat diterapkan. Akibatnya, Anda melihat bahwa sistem telah kembali menggunakan aplikasi versi lama, dan versi baru telah dihapus begitu saja.
Hal baiknya adalah meskipun Anda memiliki sejumlah besar permintaan simultan yang masuk ke aplikasi, mereka bahkan tidak akan menyadari waktu henti saat menerapkan prosedur penerapan. Jika Anda menguji aplikasi ini menggunakan kerangka Gatling, yang mengirimkan permintaan sebanyak mungkin, maka tidak satu pun permintaan ini akan dibatalkan. Ini berarti bahwa pengguna kami bahkan tidak akan melihat pembaruan versi secara real-time. Jika gagal, pekerjaan akan dilanjutkan pada versi lama; jika berhasil, pengguna akan beralih ke versi baru.
Hanya ada satu hal yang bisa gagal - jika pemeriksaan kesehatan berhasil, tetapi aplikasi gagal segera setelah beban kerja diterapkan padanya, yaitu keruntuhan hanya akan terjadi setelah penerapan selesai. Dalam hal ini, Anda harus memutar kembali ke versi lama secara manual. Jadi, kita melihat cara menggunakan Kubernetes dengan alat sumber terbuka yang dirancang untuk itu. Proses penerapan akan jauh lebih mudah jika Anda memasukkan alat ini ke dalam alur Build/Deploy Anda. Pada saat yang sama, untuk memulai penerapan, Anda dapat menggunakan antarmuka pengguna atau mengotomatiskan proses ini sepenuhnya dengan menggunakan, misalnya, komit ke master.
Build Server kami akan membuat image Docker, memasukkannya ke Docker Hub atau registri apa pun yang Anda gunakan. Docker Hub mendukung webhook, sehingga kita dapat memicu penerapan jarak jauh melalui Deployer seperti yang ditunjukkan di atas. Dengan cara ini Anda dapat sepenuhnya mengotomatiskan penerapan aplikasi Anda ke produksi potensial.
Mari beralih ke topik berikutnya - penskalaan cluster Kubernetes. Perhatikan bahwa perintah kubectl adalah perintah penskalaan. Dengan bantuan lebih lanjut, kami dapat dengan mudah meningkatkan jumlah replika di cluster yang ada. Namun, dalam praktiknya, kami biasanya ingin menambah jumlah node daripada pod.
Pada saat yang sama, selama jam kerja Anda mungkin perlu meningkatkannya, dan pada malam hari, untuk mengurangi biaya layanan Amazon, Anda mungkin perlu mengurangi jumlah instans aplikasi yang berjalan. Ini tidak berarti bahwa menskalakan jumlah pod saja sudah cukup, karena meskipun salah satu node menganggur, Anda masih harus membayar Amazon untuk itu. Artinya, seiring dengan penskalaan pod, Anda juga perlu menskalakan jumlah mesin yang digunakan.
Hal ini dapat menjadi tantangan karena baik kita menggunakan Amazon atau layanan cloud lainnya, Kubernetes tidak mengetahui apa pun tentang jumlah mesin yang digunakan. Ia tidak memiliki alat yang memungkinkan Anda menskalakan sistem pada tingkat node.
Jadi kita harus menjaga node dan podnya. Kita dapat dengan mudah menskalakan peluncuran node baru menggunakan API AWS dan mesin grup Scaling untuk mengonfigurasi jumlah node pekerja Kubernetes. Anda juga dapat menggunakan cloud-init atau skrip serupa untuk mendaftarkan node di cluster Kubernetes.
Mesin baru dimulai di grup Penskalaan, memulai dirinya sebagai sebuah node, mendaftar di registri master dan mulai bekerja. Setelah ini, Anda dapat menambah jumlah replika untuk digunakan pada node yang dihasilkan. Penurunan skala memerlukan lebih banyak upaya, karena Anda perlu memastikan bahwa langkah tersebut tidak menyebabkan kehancuran aplikasi yang sudah berjalan setelah mematikan mesin yang “tidak diperlukan”. Untuk mencegah skenario seperti itu, Anda perlu mengatur node ke status “tidak dapat dijadwalkan”. Artinya, penjadwal default akan mengabaikan node ini saat menjadwalkan pod DaemonSet. Penjadwal tidak akan menghapus apa pun dari server ini, tetapi juga tidak akan meluncurkan container baru di sana. Langkah selanjutnya adalah mengeluarkan node drain, yaitu mentransfer pod yang sedang berjalan dari node tersebut ke mesin lain, atau node lain yang memiliki kapasitas yang cukup untuk ini. Setelah Anda memastikan bahwa tidak ada lagi container di node tersebut, Anda dapat menghapusnya dari Kubernetes. Setelah ini, mereka tidak akan ada lagi untuk Kubernetes. Selanjutnya, Anda perlu menggunakan API AWS untuk menonaktifkan node atau mesin yang tidak diperlukan.
Anda dapat menggunakan Amdatu Scalerd, alat penskalaan sumber terbuka lainnya yang serupa dengan API AWS. Ini menyediakan CLI untuk menambah atau menghapus node dalam sebuah cluster. Fitur menariknya adalah kemampuan untuk mengkonfigurasi penjadwal menggunakan file json berikut.
Kode yang ditampilkan mengurangi kapasitas cluster hingga setengahnya pada periode malam hari. Ini mengonfigurasi jumlah replika yang tersedia dan kapasitas klaster Amazon yang diinginkan. Penggunaan penjadwal ini secara otomatis akan mengurangi jumlah node di malam hari dan menambahnya di pagi hari, sehingga menghemat biaya penggunaan node dari layanan cloud seperti Amazon. Fitur ini tidak ada di dalam Kubernetes, tetapi penggunaan Scalerd akan memungkinkan Anda menskalakan platform ini sesuai keinginan Anda.
Saya ingin menunjukkan bahwa banyak orang mengatakan kepada saya, "Itu semua baik-baik saja, tapi bagaimana dengan database saya, yang biasanya statis?" Bagaimana Anda bisa menjalankan sesuatu seperti ini di lingkungan dinamis seperti Kubernetes? Menurut pendapat saya, Anda tidak boleh melakukan ini, Anda tidak boleh mencoba menjalankan gudang data di Kubernetes. Secara teknis hal ini mungkin dilakukan, dan ada tutorial di Internet mengenai hal ini, tetapi ini akan sangat mempersulit hidup Anda.
Ya, ada konsep penyimpanan persisten di Kubernetes, dan Anda dapat mencoba menjalankan penyimpanan data seperti Mongo atau MySQL, tetapi ini merupakan tugas yang cukup memakan waktu. Hal ini disebabkan oleh fakta bahwa gudang data tidak sepenuhnya mendukung interaksi dengan lingkungan yang dinamis. Kebanyakan database memerlukan konfigurasi yang signifikan, termasuk konfigurasi cluster secara manual, tidak menyukai penskalaan otomatis dan hal serupa lainnya.
Oleh karena itu, Anda tidak perlu mempersulit hidup Anda dengan mencoba menjalankan data warehouse di Kubernetes. Atur pekerjaan mereka dengan cara tradisional menggunakan layanan yang sudah dikenal dan berikan Kubernetes kemampuan untuk menggunakannya.
Sebagai penutup topik, saya ingin memperkenalkan Anda pada platform Cloud RTI berbasis Kubernetes, yang sedang dikerjakan oleh tim saya. Ini menyediakan logging terpusat, pemantauan aplikasi dan cluster, dan banyak fitur berguna lainnya yang akan berguna. Ia menggunakan berbagai alat sumber terbuka seperti Grafana untuk menampilkan pemantauan.
Ada pertanyaan tentang mengapa menggunakan load balancer ha-proxy dengan Kubernetes. Pertanyaan bagus karena saat ini ada 2 level penyeimbangan beban. Layanan Kubernetes masih menggunakan alamat IP virtual. Anda tidak dapat menggunakannya untuk port pada mesin host eksternal karena jika Amazon membebani host cloud-nya secara berlebihan, alamatnya akan berubah. Inilah sebabnya kami menempatkan ha-proxy di depan layanan - untuk menciptakan struktur lalu lintas yang lebih statis agar dapat berkomunikasi secara lancar dengan Kubernetes.
Pertanyaan bagus lainnya adalah bagaimana Anda menangani perubahan skema database saat melakukan penerapan biru/hijau? Faktanya adalah, apapun penggunaan Kubernetes, mengubah skema database adalah tugas yang sulit. Anda perlu memastikan bahwa skema lama dan baru kompatibel, setelah itu Anda dapat memperbarui database dan memperbarui aplikasi itu sendiri. Anda dapat melakukan hot swap database dan kemudian memperbarui aplikasi. Saya mengenal orang-orang yang telah mem-boot cluster database yang benar-benar baru dengan skema baru, ini adalah opsi jika Anda memiliki database tanpa skema seperti Mongo, tapi itu bukan tugas yang mudah. Jika Anda tidak memiliki pertanyaan lebih lanjut, terima kasih atas perhatian Anda!
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