Dalam artikel ini saya akan menjelaskan pengalaman kami bermigrasi Preply ke Kubernetes, bagaimana dan mengapa kami melakukannya, kesulitan apa yang kami temui dan keuntungan apa yang kami peroleh.
Kubernet untuk Kubernet? Tidak, persyaratan bisnis!
Sekitar Kubernetes ada banyak hype dan untuk alasan yang bagus. Banyak orang mengatakan bahwa itu akan menyelesaikan semua masalah, beberapa mengatakan bahwa kemungkinan besar Anda tidak memerlukan Kubernet . Kebenaran tentu saja ada di antara keduanya.
Namun, semua diskusi ini tentang di mana dan kapan Kubernetes dibutuhkan layak menjadi artikel terpisah. Sekarang saya akan berbicara sedikit tentang persyaratan bisnis kami dan bagaimana Preply bekerja sebelum migrasi ke Kubernetes:
- Ketika kami menggunakan aliran Skullcandy , kami memiliki banyak cabang, semuanya bergabung menjadi cabang umum yang disebut
stage-rc , dikerahkan ke panggung. Tim QA menguji lingkungan ini, setelah menguji cabang itu bergembira di master dan master dikerahkan ke prod. Seluruh prosedur memakan waktu sekitar 3-4 jam dan kami dapat menerapkan dari 0 hingga 2 kali sehari - Ketika kami menempatkan kode yang rusak ke prod, kami harus memutar kembali semua perubahan yang termasuk dalam rilis terbaru. Sulit juga untuk menemukan perubahan mana yang merusak produk kami
- Kami menggunakan AWS Elastic Beanstalk untuk menyimpan aplikasi kami. Setiap penyebaran Beanstalk dalam kasus kami membutuhkan waktu 45 menit (seluruh pipa bersama dengan tes berhasil dalam 90 menit ). Kembalikan ke versi aplikasi sebelumnya membutuhkan waktu 45 menit
Untuk meningkatkan produk dan proses kami di perusahaan, kami ingin:
- Pecahkan monolith menjadi microservices
- Sebarkan lebih cepat dan lebih sering
- Putar kembali dengan lebih cepat
- Ubah proses pengembangan kami karena kami pikir itu tidak lagi efektif
Kebutuhan kita
Kami mengubah proses pengembangan
Untuk mengimplementasikan inovasi kami dengan aliran Skullcandy, kami perlu menciptakan lingkungan yang dinamis untuk setiap cabang. Dalam pendekatan kami dengan konfigurasi aplikasi di Elastic Beanstalk, itu sulit dan mahal untuk dilakukan. Kami ingin menciptakan lingkungan yang akan:
- Digunakan dengan cepat dan mudah (lebih disukai wadah)
- Bekerja pada instance tempat
- Mereka mirip dengan prod
Kami memutuskan untuk pindah ke Pengembangan Berbasis Batang. Dengan bantuannya, setiap fitur memiliki cabang terpisah, yang, terlepas dari yang lain, dapat bergabung menjadi master. Cabang master dapat digunakan kapan saja.
git-flow dan Pembangunan Berbasis Batang
Sebarkan lebih cepat dan lebih sering
Proses Berbasis Batang yang baru memungkinkan kami untuk mengirimkan inovasi ke cabang master lebih cepat satu demi satu. Ini sangat membantu kami dalam proses menemukan kode yang rusak di prod dan memutar kembali. Namun, waktu penerapan masih 90 menit, dan waktu rollback adalah 45 menit, karena itu kami tidak dapat menggunakan lebih sering 4-5 kali sehari.
Kami juga mengalami kesulitan menggunakan arsitektur layanan di Elastic Beanstalk. Solusi yang paling jelas adalah menggunakan wadah dan instrumen untuk mengaturnya. Selain itu, kami sudah memiliki pengalaman menggunakan Docker dan docker-compose untuk pengembangan lokal.
Langkah kami selanjutnya adalah meneliti orkestra kontainer populer:
- AWS ECS
- Berkerumun
- Mesos Apache
- Pengembara
- Kubernetes
Kami memutuskan untuk menginap di Kubernetes, dan itulah sebabnya. Di antara para orkestra yang dipertanyakan, semua orang memiliki kelemahan penting: ECS adalah solusi yang bergantung pada vendor, Swarm telah kehilangan kemenangan Kubernet, Apache Mesos tampak seperti pesawat ruang angkasa untuk kita dengan para penjaga kebun binatangnya. Nomad tampak menarik, tetapi sepenuhnya mengungkapkan dirinya hanya dalam integrasi dengan produk Hashicorp lainnya, kami juga kecewa karena ruang nama dalam Nomad dibayar.
Meskipun memiliki ambang masuk yang tinggi, Kubernetes adalah standar de facto dalam orkestrasi wadah. Kubernetes sebagai Layanan tersedia di sebagian besar penyedia cloud utama. Orkestra sedang dalam pengembangan aktif, memiliki komunitas besar pengguna dan pengembang, dan dokumentasi yang baik.
Kami diharapkan untuk sepenuhnya memigrasi platform kami ke Kubernetes dalam 1 tahun. Dua insinyur platform tanpa pengalaman Kubernet terlibat dalam migrasi sebagian-boot.
Menggunakan Kubernetes
Kami mulai dengan bukti konsep, membuat gugus uji, dan mendokumentasikan semua yang kami lakukan secara terperinci. Kami memutuskan untuk menggunakan polisi , karena di wilayah kami pada saat itu EKS masih belum tersedia (di Irlandia diumumkan pada September 2018 ).
Saat bekerja dengan cluster, kami menguji cluster-autoscaler , cert-manager , Prometheus, integrasi dengan Hashicorp Vault, Jenkins dan banyak lagi. Kami "bermain" dengan strategi pembaruan, menghadapi beberapa masalah jaringan, khususnya dengan DNS , dan memperkuat pengetahuan kami dalam pengelompokan klaster.
Mereka menggunakan contoh lokasi untuk mengoptimalkan biaya infrastruktur. Untuk menerima pemberitahuan tentang masalah spot , mereka menggunakan kube-spot-termination-notice-handler , Spot Instance Advisor dapat membantu Anda memilih jenis instance spot.
Kami memulai migrasi dari aliran Skullcandy ke pengembangan berbasis-batang, tempat kami meluncurkan tahap dinamis untuk setiap permintaan tarik, ini memungkinkan kami untuk mengurangi waktu pengiriman untuk fitur baru dari 4-6 menjadi 1-2 jam .
Github hook meluncurkan penciptaan lingkungan dinamis untuk permintaan tarik
Kami menggunakan gugus uji untuk lingkungan dinamis ini, setiap lingkungan berada dalam namespace terpisah. Pengembang memiliki akses ke Kubernetes Dashboard untuk men-debug kode mereka.
Kami senang bahwa kami mulai mendapat manfaat dari Kubernet setelah hanya 1-2 bulan sejak awal penggunaannya.
Cluster panggung dan penjualan
Pengaturan kami untuk klaster panggung dan produk:
- kops dan Kubernetes 1.11 (versi terbaru pada saat pembuatan cluster)
- Tiga master node di zona akses berbeda
- Topologi jaringan pribadi dengan benteng khusus, Calico CNI
- Prometheus untuk mengumpulkan metrik digunakan dalam cluster yang sama dengan PVC (perlu dipertimbangkan bahwa kami tidak menyimpan metrik untuk waktu yang lama)
- Agen Datadog untuk APM
- Dex + dex-k8s-authenticator untuk menyediakan akses ke cluster kepada pengembang
- Node untuk cluster stage berfungsi pada instance spot
Saat bekerja dengan cluster, kami mengalami beberapa masalah. Sebagai contoh, versi Nginx Ingress dan Datadog agent berbeda pada cluster, sehubungan dengan ini beberapa hal bekerja pada cluster stage, tetapi tidak bekerja pada prod. Oleh karena itu, kami memutuskan untuk sepenuhnya mematuhi versi perangkat lunak pada kluster untuk menghindari kasus seperti itu.
Migrasikan Prod ke Kubernetes
Cluster panggung dan makanan siap, dan kami siap untuk memulai migrasi. Kami menggunakan monorepa dengan struktur berikut:
. ├── microservice1 │ ├── Dockerfile │ ├── Jenkinsfile │ └── ... ├── microservice2 │ ├── Dockerfile │ ├── Jenkinsfile │ └── ... ├── microserviceN │ ├── Dockerfile │ ├── Jenkinsfile │ └── ... ├── helm │ ├── microservice1 │ │ ├── Chart.yaml │ │ ├── ... │ │ ├── values.prod.yaml │ │ └── values.stage.yaml │ ├── microservice2 │ │ ├── Chart.yaml │ │ ├── ... │ │ ├── values.prod.yaml │ │ └── values.stage.yaml │ ├── microserviceN │ │ ├── Chart.yaml │ │ ├── ... │ │ ├── values.prod.yaml │ │ └── values.stage.yaml └── Jenkinsfile
Root Jenkinsfile berisi tabel korespondensi antara nama microservice dan direktori di mana kodenya berada. Ketika pengembang memegang permintaan tarik ke master, tag dibuat di GitHub, tag ini digunakan untuk prod menggunakan Jenkins sesuai dengan Jenkinsfile.
Direktori helm/ berisi bagan HELM dengan dua file nilai-terpisah untuk panggung dan penjualan. Kami menggunakan Skaffold untuk menyebarkan banyak bagan HELM ke panggung. Kami mencoba menggunakan bagan payung, tetapi dihadapkan pada kenyataan bahwa itu sulit untuk diukur.
Sesuai dengan aplikasi dua belas faktor, setiap layanan mikro baru di prod menulis log ke stdout, membaca rahasia dari Vault dan memiliki serangkaian peringatan dasar (memeriksa jumlah perapian yang berfungsi, lima ratus kesalahan dan laten pada masuknya).
Terlepas dari apakah kita mengimpor fitur baru ke layanan microser atau tidak, dalam kasus kami semua fungsi utama ada di monolit Django dan monolit ini masih berfungsi di Elastic Beanstalk.
Hancurkan monolit menjadi microservices // The Vigeland Park di Oslo
Kami menggunakan AWS Cloudfront sebagai CDN dan dengan itu kami menggunakan penyebaran kenari di seluruh migrasi kami. Kami mulai memigrasi monolit ke Kubernetes dan mengujinya pada beberapa versi bahasa dan pada halaman internal situs (seperti panel admin). Proses migrasi serupa memungkinkan kami menangkap bug pada prod dan memoles penyebaran kami hanya dalam beberapa iterasi. Selama beberapa minggu, kami memantau keadaan platform, memuat dan memantau, dan pada akhirnya, 100% lalu lintas penjualan dialihkan ke Kubernetes.
Setelah itu, kami benar-benar bisa meninggalkan penggunaan Elastic Beanstalk.
Ringkasan
Migrasi penuh memakan waktu 11 bulan, seperti yang saya sebutkan di atas, kami berencana untuk memenuhi batas waktu 1 tahun.
Sebenarnya, hasilnya jelas:
- Waktu penggunaan menurun dari 90 menit menjadi 40 menit
- Jumlah penyebaran meningkat dari 0-2 menjadi 10-15 per hari (dan masih terus bertambah!)
- Waktu rollback menurun dari 45 menjadi 1-2 menit
- Kami dapat dengan mudah memberikan layanan microser baru ke prod
- Kami merapikan pemantauan, penebangan, manajemen rahasia kami, memusatkan mereka dan menggambarkannya sebagai kode
Itu adalah pengalaman migrasi yang sangat keren dan kami masih bekerja pada banyak peningkatan platform. Pastikan untuk membaca artikel keren tentang pengalaman dengan Kubernetes dari Jura, dia adalah salah satu insinyur YAML yang terlibat dalam implementasi Kubernetes di Preply.