Catatan perev. : Dailymotion adalah salah satu layanan hosting video terbesar di dunia dan karenanya merupakan pengguna Kubernet yang terkenal. Dalam artikel ini, arsitek sistem David Donchez berbagi hasil menciptakan platform produksi untuk perusahaan berdasarkan K8, yang dimulai dengan instalasi cloud di GKE dan berakhir sebagai solusi hybrid, yang memungkinkan waktu reaksi yang lebih baik dan menghemat biaya infrastruktur.Ketika memutuskan untuk membangun kembali API
Dailymotion inti tiga tahun lalu, kami ingin mengembangkan cara yang lebih efisien untuk meng-host aplikasi dan mempermudah
pengembangan dan proses produksi . Untuk tujuan ini, kami memutuskan untuk menggunakan platform orkestrasi wadah dan secara alami memilih Kubernetes.
Mengapa layak membuat platform berbasis Kubernet Anda sendiri?
API tingkat produksi sesegera mungkin menggunakan Google Cloud
Musim panas 2016
Tiga tahun lalu, tepat setelah
Vivendi membeli Dailymotion, tim teknik kami fokus pada satu tujuan global: untuk menciptakan produk Dailymotion yang sama sekali baru.
Berdasarkan analisis wadah, solusi orkestrasi, dan pengalaman masa lalu kami, kami memastikan bahwa Kubernetes adalah pilihan yang tepat. Beberapa pengembang sudah memiliki gagasan tentang konsep dasar dan tahu bagaimana menggunakannya, yang merupakan keuntungan besar bagi transformasi infrastruktur.
Dari sudut pandang infrastruktur, diperlukan sistem yang kuat dan fleksibel untuk meng-host tipe baru aplikasi cloud-native. Kami memilih untuk tetap berada di awan di awal perjalanan kami untuk membangun platform lokal yang paling andal. Mereka memutuskan untuk menyebarkan aplikasi mereka menggunakan Google Kubernetes Engine, meskipun mereka tahu bahwa cepat atau lambat kami akan beralih ke pusat data kami sendiri dan menerapkan strategi hibrida.
Mengapa memilih GKE?
Kami membuat pilihan ini terutama karena alasan teknis. Selain itu, perlu segera menyediakan infrastruktur yang memenuhi kebutuhan bisnis perusahaan. Kami memiliki beberapa persyaratan aplikasi, seperti distribusi geografis, skalabilitas, dan toleransi kesalahan.
Cluster GKE di DailymotionKarena Dailymotion adalah platform video yang tersedia di seluruh dunia, kami benar-benar ingin meningkatkan kualitas layanan dengan mengurangi
latensi . Sebelumnya,
API kami hanya tersedia di Paris, yang tidak optimal. Saya ingin dapat meng-host aplikasi tidak hanya di Eropa, tetapi juga di Asia dan Amerika Serikat.
Sensitivitas terhadap penundaan ini berarti bahwa kami harus bekerja dengan serius pada arsitektur jaringan platform. Sementara sebagian besar layanan cloud memaksa mereka untuk membuat jaringan mereka sendiri di setiap wilayah dan kemudian menghubungkannya melalui VPN atau layanan terkelola tertentu, Google Cloud memungkinkan untuk membuat jaringan terpadu yang sepenuhnya dapat dirutekan yang mencakup semua wilayah Google. Ini merupakan nilai tambah besar dalam hal operasi dan efisiensi sistem.
Selain itu, layanan jaringan dan memuat penyeimbang dari Google Cloud melakukan pekerjaan yang sangat baik. Mereka hanya memungkinkan Anda untuk menggunakan alamat IP publik yang sewenang-wenang dari setiap wilayah, dan protokol BGP yang luar biasa menangani sisanya (mis., Mengarahkan ulang pengguna ke kluster terdekat). Jelas, jika terjadi kegagalan, lalu lintas akan secara otomatis pergi ke wilayah lain tanpa campur tangan manusia.
Pemantauan keseimbangan beban GooglePlatform kami juga aktif menggunakan prosesor grafis. Google Cloud membuatnya sangat efisien untuk menggunakannya secara langsung di kluster Kubernetes.
Pada saat itu, tim infrastruktur terutama berkonsentrasi pada tumpukan lama yang digunakan pada server fisik. Itulah sebabnya penggunaan layanan terkelola (termasuk komponen utama Kubernetes) memenuhi persyaratan kami dan memungkinkan kami untuk melatih tim untuk bekerja dengan kelompok lokal.
Akibatnya, kami dapat mulai menerima lalu lintas produksi di infrastruktur Google Cloud hanya 6 bulan setelah dimulainya pekerjaan.
Namun, terlepas dari sejumlah keuntungan, bekerja dengan penyedia cloud dikaitkan dengan biaya tertentu, yang dapat meningkat tergantung pada bebannya. Itulah sebabnya kami dengan cermat menganalisis setiap layanan terkelola yang digunakan, berharap untuk mengimplementasikannya di tempat di masa mendatang. Bahkan, pengenalan cluster lokal dimulai pada akhir 2016 dan pada saat yang sama sebuah strategi hibrida dimulai.
Meluncurkan Platform Orkestrasi Container Dailymotion Lokal
Musim Gugur 2016
Dalam kondisi ketika seluruh tumpukan siap untuk produksi, dan pekerjaan pada API
berlanjut , ada waktu untuk berkonsentrasi pada kelompok regional.
Saat itu, pengguna menonton lebih dari 3 miliar video setiap bulan. Tentu saja, kami telah menjalankan Jaringan Pengiriman Konten bercabang kami sendiri selama bertahun-tahun. Kami ingin mengambil keuntungan dari keadaan ini dan menggunakan kluster Kubernetes di pusat data yang ada.
Infrastruktur Dailymotion berjumlah lebih dari 2,5 ribu server di enam pusat data. Semua dikonfigurasi menggunakan Saltstack. Kami mulai menyiapkan semua resep yang diperlukan untuk membuat simpul master dan pekerja, serta kluster etcd.
Bagian jaringan
Jaringan kami sepenuhnya dapat dirutekan. Setiap server mengumumkan IP-nya di jaringan menggunakan Exabgp. Kami membandingkan beberapa plug-in jaringan dan
Calico adalah satu-satunya yang memenuhi semua kebutuhan (karena pendekatan yang digunakan pada level L3). Ini sangat cocok dengan model infrastruktur jaringan yang ada.
Karena saya ingin menggunakan semua elemen infrastruktur yang tersedia, pertama-tama, saya harus berurusan dengan utilitas jaringan buatan lokal kami (digunakan pada semua server): menggunakannya untuk mengumumkan rentang alamat IP pada jaringan dengan node Kubernetes. Kami mengizinkan Calico untuk menetapkan alamat IP ke pod, tetapi tidak menggunakannya dan masih tidak menggunakannya untuk sesi BGP pada peralatan jaringan. Bahkan, perutean ditangani oleh Exabgp, yang mengumumkan subnet yang digunakan oleh Calico. Ini memungkinkan kami menjangkau pod apa saja dari jaringan internal (dan khususnya dari penyeimbang beban).
Bagaimana kami mengelola lalu lintas masuknya
Untuk mengarahkan kembali permintaan yang masuk ke layanan yang diinginkan, diputuskan untuk menggunakan Ingress Controller karena integrasinya dengan sumber daya masuk Kubernetes.
Tiga tahun lalu, nginx-ingress-controller adalah pengendali yang paling matang: Nginx telah digunakan sejak lama dan telah dikenal karena stabilitas dan kinerjanya.
Dalam sistem kami, kami memutuskan untuk menempatkan pengontrol di server blade 10-gigabit khusus. Setiap pengontrol terhubung ke titik akhir kube-apiserver dari cluster yang sesuai. Exabgp juga digunakan pada server ini untuk mengumumkan alamat IP publik atau pribadi. Topologi jaringan kami memungkinkan kami untuk menggunakan BGP dari pengontrol ini untuk merutekan semua lalu lintas langsung ke pod tanpa menggunakan layanan seperti NodePort. Pendekatan ini membantu menghindari lalu lintas horizontal antara node dan meningkatkan efisiensi.
Pergerakan lalu lintas dari Internet ke podSekarang setelah Anda mengetahui platform hybrid kami, Anda dapat mempelajari proses migrasi lalu lintas.
Memigrasi lalu lintas dari Google Cloud ke infrastruktur Dailymotion
Musim Gugur 2018
Setelah hampir dua tahun membuat, menguji, dan mengonfigurasi, kami akhirnya mendapatkan tumpukan Kubernetes lengkap, siap menerima sebagian lalu lintas.
Strategi routing saat ini cukup sederhana, tetapi cukup memuaskan kebutuhan. Selain IP publik (di Google Cloud dan Dailymotion) AWS Route 53 digunakan untuk menetapkan kebijakan dan mengarahkan pengguna ke kluster pilihan kami.
Contoh Kebijakan Perutean Menggunakan Rute 53Dengan Google Cloud, itu mudah, karena kami menggunakan satu IP untuk semua cluster, dan pengguna diarahkan ke kluster GKE terdekat. Teknologi ini berbeda untuk cluster kami karena IP mereka berbeda.
Selama migrasi, kami berusaha untuk mengarahkan permintaan regional ke masing-masing cluster dan mengevaluasi keuntungan dari pendekatan ini.
Karena kluster GKE kami dikonfigurasikan untuk secara otomatis menggunakan Metrik Kustom, mereka menambah / mengurangi kapasitas tergantung pada lalu lintas masuk.
Dalam mode normal, semua lalu lintas regional diarahkan ke kluster lokal, dan GKE berfungsi sebagai cadangan jika terjadi masalah (pemeriksaan kesehatan dilakukan oleh Rute 53).
...
Di masa depan, kami ingin mengotomatisasi sepenuhnya kebijakan perutean untuk mendapatkan strategi hibrid yang otonom yang terus-menerus meningkatkan aksesibilitas pengguna. Adapun nilai tambahnya: biaya cloud berkurang secara signifikan dan bahkan berhasil mengurangi waktu respons API. Kami percaya platform cloud yang dihasilkan dan siap untuk mengarahkan lebih banyak lalu lintas ke sana jika perlu.
PS dari penerjemah
Anda mungkin juga tertarik dengan publikasi Dailymotion terbaru lainnya tentang Kubernetes. Ini didedikasikan untuk menyebarkan aplikasi Helm ke banyak kluster Kubernetes dan
diterbitkan sekitar sebulan yang lalu.
Baca juga di blog kami: