Nama saya Viktor Yagofarov, dan saya sedang mengembangkan platform Kubernetes di DomClick sebagai manajer pengembangan teknis di tim Ops (operasi). Saya ingin berbicara tentang struktur proses Dev <-> Ops kami, fitur pengoperasian salah satu cluster k8s terbesar di Rusia, serta praktik DevOps/SRE yang diterapkan tim kami.
Tim Operasi
Tim Ops saat ini berjumlah 15 orang. Tiga di antaranya bertanggung jawab di kantor, dua bekerja di zona waktu berbeda dan tersedia, termasuk di malam hari. Oleh karena itu, seseorang dari Ops selalu memantau dan siap merespons insiden dengan kompleksitas apa pun. Kita tidak memiliki shift malam, yang menjaga jiwa kita dan memberikan setiap orang kesempatan untuk cukup tidur dan menghabiskan waktu luang tidak hanya di depan komputer.
Setiap orang memiliki kompetensi yang berbeda: penggiat jaringan, DBA, spesialis tumpukan ELK, admin/pengembang Kubernetes, pemantauan, virtualisasi, spesialis perangkat keras, dll. Satu hal yang menyatukan semua orang - setiap orang dapat menggantikan kita sampai batas tertentu: misalnya, memperkenalkan node baru ke cluster k8s, memperbarui PostgreSQL, menulis pipeline CI/CD + Ansible, mengotomatiskan sesuatu dengan Python/Bash/Go, menghubungkan perangkat keras ke Pusat Data. Kompetensi yang kuat di bidang apa pun tidak menghalangi Anda untuk mengubah arah aktivitas dan mulai meningkatkan diri di bidang lain. Misalnya, saya bergabung dengan sebuah perusahaan sebagai spesialis PostgreSQL, dan sekarang tanggung jawab utama saya adalah cluster Kubernetes. Di dalam tim, ketinggian apa pun diterima dan rasa leverage sangat berkembang.
Ngomong-ngomong, kami sedang berburu. Persyaratan calon cukup standar. Secara pribadi, penting bagi saya bahwa seseorang cocok dengan tim, non-konflik, tetapi juga tahu bagaimana mempertahankan sudut pandangnya, ingin berkembang dan tidak takut untuk melakukan sesuatu yang baru, serta menawarkan ide-idenya. Selain itu, keterampilan pemrograman dalam bahasa scripting, pengetahuan dasar-dasar Linux dan bahasa Inggris juga diperlukan. Bahasa Inggris diperlukan agar seseorang, jika terjadi fakap, dapat mencari solusi masalah di Google dalam 10 detik, bukan dalam 10 menit. Saat ini sangat sulit untuk menemukan spesialis dengan pengetahuan mendalam tentang Linux: ini lucu, tetapi dua dari tiga kandidat tidak dapat menjawab pertanyaan “Apa itu Load Average? Terbuat dari apa?”, dan pertanyaan “Bagaimana cara merakit core dump dari program C” dianggap sebagai sesuatu dari dunia manusia super... atau dinosaurus. Kita harus menerima hal ini, karena biasanya orang sudah sangat mengembangkan kompetensi lain, tapi kami akan mengajarkan Linux. Jawaban atas pertanyaan “mengapa seorang insinyur DevOps perlu mengetahui semua ini di dunia cloud modern” tidak akan dibahas dalam artikel ini, namun dalam tiga kata: semua ini diperlukan.
Alat Tim
Tim Alat memainkan peran penting dalam otomatisasi. Tugas utama mereka adalah membuat alat grafis dan CLI yang nyaman bagi pengembang. Misalnya, pengembangan internal kami, Confer, memungkinkan Anda meluncurkan aplikasi ke Kubernetes hanya dengan beberapa klik mouse, mengonfigurasi sumber dayanya, kunci dari vault, dll. Sebelumnya ada Jenkins + Helm 2, tetapi saya harus mengembangkan alat saya sendiri untuk menghilangkan copy-paste dan membawa keseragaman pada siklus hidup perangkat lunak.
Tim Ops tidak menulis saluran untuk pengembang, namun dapat memberikan saran mengenai masalah apa pun dalam tulisan mereka (beberapa orang masih memiliki Helm 3).
DevOps
Sedangkan untuk DevOps, kami melihatnya seperti ini:
Tim pengembang menulis kode, meluncurkannya melalui Confer to dev -> qa/stage -> prod. Tanggung jawab untuk memastikan bahwa kode tidak melambat dan tidak mengandung kesalahan terletak pada tim Pengembang dan Operasi. Pada siang hari, petugas jaga dari tim Ops pertama-tama harus menanggapi suatu kejadian dengan lamarannya, dan pada sore dan malam hari, administrator jaga (Ops) harus membangunkan pengembang jaga jika dia mengetahuinya. yakin bahwa masalahnya bukan pada infrastruktur. Semua metrik dan peringatan dalam pemantauan muncul secara otomatis atau semi-otomatis.
Area tanggung jawab Ops dimulai dari saat aplikasi diluncurkan ke dalam produksi, tetapi tanggung jawab Dev tidak berakhir di situ - kami melakukan hal yang sama dan berada di perahu yang sama.
Pengembang memberi saran kepada admin jika mereka memerlukan bantuan untuk menulis layanan mikro admin (misalnya, Go backend + HTML5), dan admin memberi saran kepada pengembang tentang masalah infrastruktur atau masalah terkait k8s.
Omong-omong, kami tidak memiliki monolit sama sekali, hanya layanan mikro. Jumlah mereka sejauh ini berfluktuasi antara 900 dan 1000 di cluster prod k8s, jika diukur dengan angka penyebaran. Jumlah pod berfluktuasi antara 1700 dan 2000. Saat ini terdapat sekitar 2000 pod di cluster prod.
Saya tidak dapat memberikan angka pastinya, karena kami memantau layanan mikro yang tidak diperlukan dan menghentikannya secara semi-otomatis. K8s membantu kita melacak entitas yang tidak diperlukan , yang menghemat banyak sumber daya dan uang.
Pengelolaan sumber daya
Pemantauan
Pemantauan yang terstruktur dengan baik dan informatif menjadi landasan dalam pengoperasian klaster besar. Kami belum menemukan solusi universal yang dapat mencakup 100% seluruh kebutuhan pemantauan, jadi kami secara berkala membuat solusi khusus yang berbeda di lingkungan ini.
- Zabbix. Pemantauan lama yang baik, yang dimaksudkan terutama untuk melacak kondisi infrastruktur secara keseluruhan. Ini memberitahu kita ketika sebuah node mati dalam hal pemrosesan, memori, disk, jaringan, dan sebagainya. Tidak ada yang supernatural, tetapi kami juga memiliki agen DaemonSet terpisah, yang dengannya, misalnya, kami memantau status DNS di cluster: kami mencari pod coredns yang bodoh, kami memeriksa ketersediaan host eksternal. Tampaknya mengapa repot-repot melakukan hal ini, tetapi dengan volume lalu lintas yang besar, komponen ini merupakan titik kegagalan yang serius. Aku sudah , bagaimana saya kesulitan dengan kinerja DNS di sebuah cluster.
- Operator Prometheus. Sekumpulan eksportir yang berbeda memberikan gambaran luas tentang seluruh komponen cluster. Selanjutnya, kami memvisualisasikan semua ini di dasbor besar di Grafana, dan menggunakan alertmanager untuk peringatan.
Alat lain yang berguna bagi kami adalah . Kami menulisnya setelah beberapa kali kami menghadapi situasi di mana satu tim tumpang tindih dengan jalur Ingress tim lain, sehingga menghasilkan kesalahan 50x. Sekarang sebelum diterapkan ke produksi, pengembang memeriksa bahwa tidak ada yang akan terpengaruh, dan bagi tim saya ini adalah alat yang bagus untuk diagnosis awal masalah dengan Ingresses. Lucu sekali bahwa pada awalnya alat ini ditulis untuk admin dan terlihat agak “kikuk”, tetapi setelah tim pengembang jatuh cinta dengan alat tersebut, alat ini banyak berubah dan mulai terlihat tidak seperti “seorang admin membuat wajah web untuk admin. ” Kami akan segera meninggalkan alat ini dan situasi seperti itu akan divalidasi bahkan sebelum pipeline diluncurkan.
Sumber daya tim di Cube
Sebelum kita membahas contohnya, ada baiknya menjelaskan bagaimana kita mengalokasikan sumber daya layanan mikro.
Untuk memahami tim mana dan dalam jumlah berapa yang menggunakannya ресурсы (prosesor, memori, SSD lokal), kami mengalokasikan setiap perintahnya sendiri namespace di “Cube” dan membatasi kemampuan maksimalnya dalam hal prosesor, memori dan disk, setelah sebelumnya membahas kebutuhan tim. Oleh karena itu, satu perintah, secara umum, tidak akan memblokir seluruh cluster untuk penerapan, mengalokasikan ribuan core dan terabyte memori. Akses ke namespace diberikan melalui AD (kami menggunakan RBAC). Namespace dan batasannya ditambahkan melalui permintaan tarik ke repositori GIT, dan kemudian semuanya secara otomatis diluncurkan melalui pipeline Ansible.
Contoh pengalokasian sumber daya ke tim:
namespaces:
chat-team:
pods: 23
limits:
cpu: 11
memory: 20Gi
requests:
cpu: 11
memory: 20Gi
Permintaan dan batasan
potong dadu" Meminta adalah jumlah sumber daya cadangan yang dijamin polong (satu atau lebih kontainer buruh pelabuhan) dalam sebuah cluster. Batasnya adalah maksimum yang tidak dijamin. Anda sering dapat melihat pada grafik bagaimana beberapa tim telah menetapkan terlalu banyak permintaan untuk semua aplikasinya dan tidak dapat menyebarkan aplikasi ke “Cube”, karena semua permintaan di bawah namespace mereka telah “dihabiskan”.
Jalan keluar yang benar dari situasi ini adalah dengan melihat konsumsi sumber daya aktual dan membandingkannya dengan jumlah yang diminta (Permintaan).
Pada tangkapan layar di atas Anda dapat melihat bahwa CPU yang “Diminta” cocok dengan jumlah thread sebenarnya, dan Batas dapat melebihi jumlah thread CPU sebenarnya =)
Sekarang mari kita lihat beberapa namespace secara detail (saya memilih namespace kube-system - namespace sistem untuk komponen "Cube" itu sendiri) dan lihat rasio waktu dan memori prosesor yang sebenarnya digunakan dengan yang diminta:
Jelas bahwa lebih banyak memori dan CPU yang dicadangkan untuk layanan sistem daripada yang sebenarnya digunakan. Dalam kasus sistem kube, hal ini dibenarkan: kebetulan pengontrol nginx ingress atau nodelocaldns pada puncaknya mengenai CPU dan menghabiskan banyak RAM, jadi di sini cadangan seperti itu dibenarkan. Selain itu, kami tidak dapat mengandalkan grafik selama 3 jam terakhir: sebaiknya kami melihat metrik historis dalam jangka waktu yang lama.
Sebuah sistem “rekomendasi” dikembangkan. Misalnya, di sini Anda dapat melihat sumber daya mana yang lebih baik jika menaikkan “batas” (bilah atas yang diizinkan) sehingga “pelambatan” tidak terjadi: momen ketika sumber daya telah menghabiskan CPU atau memori dalam jangka waktu yang ditentukan dan sedang menunggu sampai “dicairkan”:
Dan inilah buah-buahan yang dapat mengekang selera makan mereka:
Tentang pembatasan + pemantauan sumber daya, Anda dapat menulis lebih dari satu artikel, jadi ajukan pertanyaan di komentar. Singkatnya, saya dapat mengatakan bahwa tugas mengotomatisasi metrik seperti itu sangat sulit dan memerlukan banyak waktu dan menyeimbangkan tindakan dengan fungsi "jendela" dan "CTE" Prometheus / VictoriaMetrics (istilah ini ada dalam tanda kutip, karena hampir ada tidak ada yang seperti ini di PromQL, dan Anda harus membagi kueri menakutkan menjadi beberapa layar teks dan mengoptimalkannya).
Hasilnya, pengembang memiliki alat untuk memonitor namespace mereka di Cube, dan mereka dapat memilih sendiri di mana dan pada jam berapa aplikasi mana yang sumber dayanya dapat “dipotong”, dan server mana yang dapat diberikan seluruh CPU sepanjang malam.
Metodologi
Di perusahaan seperti sekarang modis, kami mematuhi DevOps- dan SRE-praktisi Ketika sebuah perusahaan memiliki 1000 layanan mikro, sekitar 350 pengembang, dan 15 admin untuk seluruh infrastruktur, Anda harus “menjadi modis”: di balik semua “baswords” ini ada kebutuhan mendesak untuk mengotomatisasi segalanya dan semua orang, dan admin tidak boleh menjadi penghambat dalam proses.
Sebagai Ops, kami menyediakan berbagai metrik dan dasbor untuk pengembang terkait dengan tingkat respons dan kesalahan layanan.
Kami menggunakan metodologi seperti: , и dengan menggabungkannya bersama-sama. Kami mencoba meminimalkan jumlah dasbor sehingga sekilas terlihat jelas layanan mana yang sedang mengalami penurunan (misalnya, kode respons per detik, waktu respons sebesar persentil ke-99), dan seterusnya. Segera setelah beberapa metrik baru diperlukan untuk dasbor umum, kami segera menggambar dan menambahkannya.
Saya belum menggambar grafik selama sebulan. Ini mungkin pertanda baik: ini berarti sebagian besar “keinginan” telah terwujud. Kebetulan selama seminggu saya menggambar beberapa grafik baru setidaknya sekali sehari.
Hasil yang dihasilkan sangat berharga karena sekarang pengembang jarang menemui admin dengan pertanyaan “di mana mencari semacam metrik.”
Implementasi Jaring Layanan sudah dekat dan akan membuat hidup lebih mudah bagi semua orang, kolega dari Tools sudah hampir menerapkan abstrak “Istio orang sehat”: siklus hidup setiap permintaan HTTP akan terlihat dalam pemantauan, dan itu akan selalu mungkin untuk memahami “pada tahap apa semuanya rusak” selama interaksi antar layanan (dan tidak hanya). Berlangganan berita dari hub DomClick. =)
Dukungan infrastruktur Kubernetes
Secara historis, kami menggunakan versi yang ditambal semprotan kube — Kemungkinan peran untuk menerapkan, memperluas, dan memperbarui Kubernetes. Pada titik tertentu, dukungan untuk instalasi non-kubeadm dihentikan dari cabang utama, dan proses peralihan ke kubeadm tidak diusulkan. Hasilnya, perusahaan Southbridge membuat forknya sendiri (dengan dukungan kubeadm dan perbaikan cepat untuk masalah kritis).
Proses update semua cluster k8s terlihat seperti ini:
- Ambil semprotan kube dari Southbridge, periksa thread kami, Merjim.
- Kami meluncurkan pembaruan ke Tekanan- "Kubus".
- Kami meluncurkan pembaruan satu node pada satu waktu (dalam Ansible ini adalah “serial: 1”) di dev- "Kubus".
- Kami memperbarui Pecutan pada Sabtu malam satu node pada satu waktu.
Ada rencana untuk menggantinya di masa depan semprotan kube untuk sesuatu yang lebih cepat dan pergi ke kubeadm.
Secara total kami memiliki tiga “Kubus”: Stres, Dev dan Prod. Kami berencana meluncurkan yang lain (siaga panas) Prod- “Cube” di pusat data kedua. Tekanan и dev hidup di “mesin virtual” (oVirt untuk Stres dan VMWare cloud untuk Dev). Pecutan- "Cube" hidup di "bare metal": ini adalah node identik dengan 32 thread CPU, memori 64-128 GB, dan 300 GB SSD RAID 10 - totalnya ada 50. Tiga node “tipis” didedikasikan untuk “master” Pecutan- “Kuba”: memori 16 GB, 12 thread CPU.
Untuk penjualan, kami lebih suka menggunakan “bare metal” dan menghindari lapisan yang tidak perlu OpenStack: kita tidak membutuhkan “tetangga yang berisik” dan CPU mencuri waktu. Dan kompleksitas administrasinya kira-kira dua kali lipat jika menggunakan OpenStack in-house.
Untuk CI/CD “Cubic” dan komponen infrastruktur lainnya kami menggunakan server GIT terpisah, Helm 3 (ini merupakan transisi yang agak sulit dari Helm 2, namun kami sangat senang dengan opsi yang ada atom), Jenkins, Ansible dan Docker. Kami menyukai cabang fitur dan penerapan ke lingkungan berbeda dari satu repositori.
Kesimpulan
Secara umum, seperti inilah proses DevOps di DomClick dari sudut pandang seorang insinyur operasi. Artikel tersebut ternyata kurang teknis dari yang saya harapkan: oleh karena itu, ikuti berita DomClick di Habré: akan ada lebih banyak artikel “hardcore” tentang Kubernetes dan banyak lagi.
Sumber: www.habr.com