Nama saya Viktor Yagofarov, dan saya sedang membangunkan platform Kubernetes di DomClick sebagai pengurus pembangunan teknikal dalam pasukan Ops (operasi). Saya ingin bercakap tentang struktur proses Dev <-> Ops kami, ciri pengendalian salah satu kluster k8s terbesar di Rusia, serta amalan DevOps/SRE yang digunakan oleh pasukan kami.
Pasukan Ops
Pasukan Ops kini mempunyai 15 orang. Tiga daripada mereka bertanggungjawab untuk pejabat, dua bekerja dalam zon waktu berbeza dan tersedia, termasuk pada waktu malam. Oleh itu, seseorang daripada Ops sentiasa berada di monitor dan bersedia untuk bertindak balas terhadap sebarang insiden kerumitan. Kami tidak mempunyai syif malam, yang memelihara jiwa kami dan memberi semua orang peluang untuk mendapatkan tidur yang cukup dan menghabiskan masa lapang bukan sahaja di komputer.
Setiap orang mempunyai kecekapan yang berbeza: perangkaian, DBA, pakar tindanan ELK, pentadbir/pembangun Kubernetes, pemantauan, virtualisasi, pakar perkakasan, dsb. Satu perkara menyatukan semua orang - semua orang boleh menggantikan mana-mana daripada kita sedikit sebanyak: contohnya, perkenalkan nod baharu ke dalam kelompok k8s, kemas kini PostgreSQL, tulis saluran paip CI/CD + Ansible, automasi sesuatu dalam Python/Bash/Go, sambungkan perkakasan ke Pusat data. Kecekapan yang kukuh dalam mana-mana bidang tidak menghalang anda daripada mengubah hala tuju aktiviti anda dan mula bertambah baik dalam beberapa bidang lain. Sebagai contoh, saya menyertai syarikat sebagai pakar PostgreSQL, dan kini bidang tanggungjawab utama saya ialah kelompok Kubernetes. Dalam pasukan, sebarang ketinggian adalah dialu-alukan dan rasa leverage sangat berkembang.
By the way, kami sedang memburu. Keperluan untuk calon agak standard. Secara peribadi, adalah penting bagi saya bahawa seseorang itu sesuai dengan pasukan, tidak berkonflik, tetapi juga tahu cara mempertahankan pandangannya, mahu membangun dan tidak takut melakukan sesuatu yang baru, dan menawarkan ideanya. Selain itu, kemahiran pengaturcaraan dalam bahasa skrip, pengetahuan tentang asas Linux dan Bahasa Inggeris diperlukan. Bahasa Inggeris diperlukan semata-mata supaya seseorang sekiranya berlaku fakap boleh google penyelesaian masalah dalam 10 saat, dan bukan dalam 10 minit. Kini amat sukar untuk mencari pakar yang mempunyai pengetahuan mendalam tentang Linux: ia lucu, tetapi dua daripada tiga calon tidak dapat menjawab soalan "Apakah Purata Beban? Ia diperbuat daripada apa?", dan soalan "Bagaimana untuk memasang longgokan teras daripada program C" dianggap sesuatu dari dunia supermen... atau dinosaur. Kami perlu bersabar dengan ini, kerana biasanya orang mempunyai kecekapan lain yang sangat maju, tetapi kami akan mengajar Linux. Jawapan kepada soalan "mengapa seorang jurutera DevOps perlu mengetahui semua ini dalam dunia awan moden" perlu ditinggalkan di luar skop artikel, tetapi dalam tiga perkataan: semua ini diperlukan.
Alat Pasukan
Pasukan Alat memainkan peranan penting dalam automasi. Tugas utama mereka adalah untuk mencipta alat grafik dan CLI yang mudah untuk pembangun. Contohnya, Konferensi pembangunan dalaman kami membolehkan anda melancarkan aplikasi secara literal kepada Kubernetes dengan hanya beberapa klik tetikus, mengkonfigurasi sumbernya, kunci dari peti besi, dsb. Sebelum ini, terdapat Jenkins + Helm 2, tetapi saya terpaksa membangunkan alat saya sendiri untuk menghapuskan salin-tampal dan membawa keseragaman kepada kitaran hayat perisian.
Pasukan Ops tidak menulis saluran paip untuk pembangun, tetapi boleh menasihati sebarang isu dalam penulisan mereka (sesetengah orang masih mempunyai Helm 3).
DevOps
Bagi DevOps, kami melihatnya seperti ini:
Pasukan pembangun menulis kod, melancarkannya melalui Confer to dev -> qa/stage -> prod. Tanggungjawab untuk memastikan bahawa kod tidak perlahan dan tidak mengandungi ralat terletak pada pasukan Dev dan Ops. Pada waktu siang, orang yang bertugas daripada pasukan Ops hendaklah terlebih dahulu memberi respons kepada insiden dengan permohonannya, dan pada waktu petang dan malam, pentadbir yang bertugas (Ops) harus membangunkan pemaju yang bertugas jika dia tahu untuk pasti masalahnya bukan pada infrastruktur. Semua metrik dan makluman dalam pemantauan muncul secara automatik atau separa automatik.
Bidang tanggungjawab Ops bermula dari saat aplikasi dilancarkan ke dalam pengeluaran, tetapi tanggungjawab Dev tidak berakhir di situ - kami melakukan perkara yang sama dan berada dalam bot yang sama.
Pembangun menasihati pentadbir jika mereka memerlukan bantuan menulis perkhidmatan mikro pentadbir (contohnya, Go backend + HTML5), dan pentadbir menasihati pembangun tentang sebarang isu atau isu infrastruktur yang berkaitan dengan k8.
Ngomong-ngomong, kami tidak mempunyai monolit sama sekali, hanya perkhidmatan mikro. Bilangan mereka setakat ini turun naik antara 900 dan 1000 dalam kelompok prod k8s, jika diukur dengan nombor penyebaran. Bilangan pod berubah-ubah antara 1700 dan 2000. Pada masa ini terdapat kira-kira 2000 pod dalam kelompok prod.
Saya tidak dapat memberikan nombor yang tepat, kerana kami memantau perkhidmatan mikro yang tidak diperlukan dan memotongnya secara separa automatik. K8s membantu kami menjejaki entiti yang tidak diperlukan , yang menjimatkan banyak sumber dan wang.
Pengurusan sumber
Pemantauan
Pemantauan yang tersusun dan bermaklumat menjadi asas dalam operasi kluster besar. Kami belum lagi menemui penyelesaian universal yang akan meliputi 100% daripada semua keperluan pemantauan, jadi kami mencipta penyelesaian tersuai yang berbeza secara berkala dalam persekitaran ini.
- Zabbix. Pemantauan lama yang baik, yang bertujuan terutamanya untuk mengesan keadaan keseluruhan infrastruktur. Ia memberitahu kita apabila nod mati dari segi pemprosesan, memori, cakera, rangkaian dan sebagainya. Tiada apa-apa yang ghaib, tetapi kami juga mempunyai ejen DaemonSet yang berasingan, dengan bantuannya, sebagai contoh, kami memantau keadaan DNS dalam kelompok: kami mencari pod coredns bodoh, kami menyemak ketersediaan hos luaran. Nampaknya mengapa perlu bersusah payah dengan ini, tetapi dengan jumlah lalu lintas yang besar, komponen ini merupakan titik kegagalan yang serius. Saya sudah , bagaimana saya bergelut dengan prestasi DNS dalam kelompok.
- Operator Prometheus. Satu set pengeksport yang berbeza memberikan gambaran keseluruhan yang besar tentang semua komponen kluster. Seterusnya, kami memvisualisasikan semua ini pada papan pemuka besar di Grafana dan menggunakan alertmanager untuk makluman.
Satu lagi alat yang berguna untuk kami ialah . Kami menulisnya selepas beberapa kali kami menghadapi situasi di mana satu pasukan bertindih dengan laluan Ingress pasukan lain, mengakibatkan 50x ralat. Sekarang sebelum digunakan untuk pengeluaran, pembangun menyemak bahawa tiada siapa yang akan terjejas, dan untuk pasukan saya ini adalah alat yang baik untuk diagnosis awal masalah dengan Ingresses. Sungguh melucukan bahawa pada mulanya ia ditulis untuk pentadbir dan ia kelihatan agak "kekok", tetapi selepas pasukan pembangun jatuh cinta dengan alat itu, ia banyak berubah dan mula kelihatan tidak seperti "pentadbir membuat muka web untuk pentadbir. β Tidak lama lagi kami akan meninggalkan alat ini dan situasi sedemikian akan disahkan walaupun sebelum saluran paip dilancarkan.
Sumber pasukan dalam Cube
Sebelum kita masuk ke dalam contoh, kita patut menerangkan cara kita memperuntukkan sumber perkhidmatan mikro.
Untuk memahami pasukan mana dan dalam kuantiti yang digunakan mereka sumber (pemproses, memori, SSD tempatan), kami memperuntukkan setiap arahannya sendiri ruang nama dalam "Cube" dan hadkan keupayaan maksimumnya dari segi pemproses, memori dan cakera, setelah membincangkan keperluan pasukan sebelum ini. Oleh itu, satu arahan, secara amnya, tidak akan menyekat keseluruhan kluster untuk penggunaan, memperuntukkan beribu-ribu teras dan terabait memori. Akses kepada ruang nama diberikan melalui AD (kami menggunakan RBAC). Ruang nama dan hadnya ditambah melalui permintaan tarik ke repositori GIT, dan kemudian semuanya dilancarkan secara automatik melalui saluran paip Ansible.
Contoh memperuntukkan sumber kepada pasukan:
namespaces:
chat-team:
pods: 23
limits:
cpu: 11
memory: 20Gi
requests:
cpu: 11
memory: 20Gi
Permintaan dan had
kiub" Meminta ialah bilangan sumber simpanan yang dijamin untuk buah (satu atau lebih bekas docker) dalam kelompok. Had adalah maksimum yang tidak dijamin. Anda selalunya boleh melihat pada graf bagaimana sesetengah pasukan telah menetapkan sendiri terlalu banyak permintaan untuk semua aplikasinya dan tidak boleh menggunakan aplikasi itu ke "Cube", kerana semua permintaan di bawah ruang nama mereka telah "dibelanjakan".
Jalan keluar yang betul dari situasi ini adalah dengan melihat penggunaan sumber sebenar dan membandingkannya dengan jumlah yang diminta (Permintaan).
Dalam tangkapan skrin di atas, anda boleh melihat bahawa CPU "Diminta" dipadankan dengan bilangan sebenar rangkaian dan Had boleh melebihi bilangan sebenar rangkaian CPU =)
Sekarang mari kita lihat beberapa ruang nama secara terperinci (saya memilih ruang nama kube-system - ruang nama sistem untuk komponen "Cube" itu sendiri) dan lihat nisbah masa dan memori pemproses yang sebenarnya digunakan kepada yang diminta:
Adalah jelas bahawa lebih banyak memori dan CPU dikhaskan untuk perkhidmatan sistem daripada yang sebenarnya digunakan. Dalam kes sistem kube, ini adalah wajar: ia berlaku bahawa pengawal kemasukan nginx atau nodelocaldns pada puncaknya memukul CPU dan menggunakan banyak RAM, jadi di sini rizab sedemikian adalah wajar. Selain itu, kami tidak boleh bergantung pada carta untuk 3 jam yang lalu: adalah wajar untuk melihat metrik sejarah dalam tempoh masa yang panjang.
Sistem "cadangan" telah dibangunkan. Sebagai contoh, di sini anda boleh melihat sumber mana yang lebih baik untuk menaikkan "had" (bar atas dibenarkan) supaya "pendikit" tidak berlaku: saat sumber telah menghabiskan CPU atau memori dalam kepingan masa yang diperuntukkan dan sedang menunggu sehingga ia akan "tidak dibekukan":
Dan berikut adalah buah yang harus mengekang selera mereka:
pada pendikit + pemantauan sumber, anda boleh menulis lebih daripada satu artikel, jadi tanya soalan dalam komen. Dalam beberapa perkataan, saya boleh mengatakan bahawa tugas mengautomasikan metrik sedemikian adalah sangat sukar dan memerlukan banyak masa dan tindakan mengimbangi dengan fungsi "tetingkap" dan "CTE" Prometheus / VictoriaMetrics (istilah ini terdapat dalam petikan, kerana terdapat hampir tiada seperti ini dalam PromQL, dan anda perlu membahagikan pertanyaan yang menakutkan kepada beberapa skrin teks dan mengoptimumkannya).
Akibatnya, pembangun mempunyai alat untuk memantau ruang nama mereka dalam Cube, dan mereka boleh memilih sendiri di mana dan pada masa apa aplikasi boleh "dipotong" sumber mereka, dan pelayan mana yang boleh diberikan keseluruhan CPU sepanjang malam.
metodologi
Dalam syarikat seperti sekarang bergaya, kami mematuhi DevOps- dan SRE-pengamal Apabila sebuah syarikat mempunyai 1000 perkhidmatan mikro, kira-kira 350 pembangun dan 15 pentadbir untuk keseluruhan infrastruktur, anda perlu "bergaya": di sebalik semua "kata-kata kasar" ini terdapat keperluan mendesak untuk mengautomasikan segala-galanya dan semua orang, dan pentadbir tidak seharusnya menjadi penghalang. dalam proses.
Sebagai Ops, kami menyediakan pelbagai metrik dan papan pemuka untuk pembangun yang berkaitan dengan kadar tindak balas perkhidmatan dan ralat.
Kami menggunakan metodologi seperti: , ΠΈ dengan menggabungkan mereka bersama-sama. Kami cuba meminimumkan bilangan papan pemuka supaya sekali imbas jelas perkhidmatan yang sedang merendahkan (contohnya, kod tindak balas sesaat, masa tindak balas sebanyak persentil ke-99), dan sebagainya. Sebaik sahaja beberapa metrik baharu menjadi perlu untuk papan pemuka umum, kami segera melukis dan menambahkannya.
Saya tidak melukis graf selama sebulan. Ini mungkin satu petanda yang baik: ini bermakna kebanyakan "keinginan" telah direalisasikan. Ia berlaku bahawa pada minggu itu saya akan melukis beberapa graf baharu sekurang-kurangnya sekali sehari.
Hasilnya adalah berharga kerana kini pembangun agak jarang pergi ke pentadbir dengan soalan "di mana untuk melihat beberapa jenis metrik."
Perlaksanaan Mesh Perkhidmatan semakin hampir dan sepatutnya menjadikan hidup lebih mudah untuk semua orang, rakan sekerja dari Tools sudah hampir melaksanakan "Istio orang yang sihat" abstrak: kitaran hayat setiap permintaan HTTP akan kelihatan dalam pemantauan, dan ia akan sentiasa mungkin untuk memahami "pada peringkat mana semuanya rosak" semasa interaksi antara perkhidmatan (dan bukan sahaja). Langgan berita daripada hab DomClick. =)
Sokongan infrastruktur Kubernetes
Dari segi sejarah, kami menggunakan versi yang ditampal Kubespray β Peranan yang boleh dipertanggungjawabkan untuk menggunakan, melanjutkan dan mengemas kini Kubernetes. Pada satu ketika, sokongan untuk pemasangan bukan kubeadm telah dipotong daripada cawangan utama, dan proses penukaran kepada kubeadm tidak dicadangkan. Akibatnya, syarikat Southbridge membuat garpu sendiri (dengan sokongan kubeadm dan penyelesaian pantas untuk masalah kritikal).
Proses untuk mengemas kini semua k8s kluster kelihatan seperti ini:
- Ambil Kubespray dari Southbridge, semak dengan benang kami, Merjim.
- Kami sedang melancarkan kemas kini kepada tekanan- "Kiub".
- Kami melancarkan kemas kini satu nod pada satu masa (dalam Ansible ini adalah "siri: 1") dalam dev- "Kiub".
- Kami kemas kini Prod pada petang Sabtu satu nod pada satu masa.
Terdapat rancangan untuk menggantikannya pada masa akan datang Kubespray untuk sesuatu yang lebih cepat dan pergi ke kubeadm.
Secara keseluruhan kami mempunyai tiga "Kiub": Tekanan, Dev dan Prod. Kami merancang untuk melancarkan satu lagi (siap sedia panas) Prod-βCubeβ di pusat data kedua. tekanan ΠΈ dev hidup dalam "mesin maya" (oVirt untuk Tekanan dan awan VMWare untuk Dev). Prod- "Cube" hidup pada "logam kosong": ini adalah nod yang sama dengan 32 utas CPU, memori 64-128 GB dan 300 GB SSD RAID 10 - terdapat 50 daripadanya secara keseluruhan. Tiga nod "nipis" didedikasikan untuk "tuan" Prod- "Cuba": 16 GB memori, 12 utas CPU.
Untuk jualan, kami lebih suka menggunakan "logam kosong" dan mengelakkan lapisan yang tidak perlu seperti OpenStack: kami tidak memerlukan "jiran bising" dan CPU curi masa. Dan kerumitan pentadbiran kira-kira dua kali ganda dalam kes OpenStack dalaman.
Untuk CI/CD βCubicβ dan komponen infrastruktur lain kami menggunakan pelayan GIT yang berasingan, Helm 3 (ia adalah peralihan yang agak menyakitkan daripada Helm 2, tetapi kami sangat gembira dengan pilihan atom), Jenkins, Ansible dan Docker. Kami menyukai cawangan ciri dan penggunaan ke persekitaran yang berbeza daripada satu repositori.
Kesimpulan
Ini, secara umum, rupa proses DevOps di DomClick dari perspektif jurutera operasi. Artikel itu ternyata kurang teknikal daripada yang saya jangkakan: oleh itu, ikuti berita DomClick di HabrΓ©: akan ada lebih banyak artikel "tegar" tentang Kubernetes dan banyak lagi.
Sumber: www.habr.com