我叫 Viktor Yagofarov，作為 Ops（運營）團隊的技術開發經理，正在 DomClick 開發 Kubernetes 平台。 我想向您介紹我們的 Dev <-> Ops 流程的結構、運行俄羅斯最大的 k8s 集群之一的功能，以及我們團隊使用的 DevOps / SRE 實踐。
團隊行動
Ops 團隊目前有 15 人。 其中三人負責辦公室，兩人在不同時區工作，並且可以在晚上工作。 因此，運營部門的人員始終處於監控狀態，隨時準備對任何復雜的事件做出響應。 我們沒有夜班，這樣既保護了我們的心態，也讓大家有機會得到充足的睡眠，度過閒暇時光，而不僅僅是在電腦前。
每個人都有不同的能力：網絡人員、DBA、ELK 堆棧專家、Kubernetes 管理員/開發人員、監控、虛擬化、硬件專家等。 有一件事將所有人團結在一起- 每個人都可以在某種程度上取代我們中的任何人：例如，將新節點引入k8s 集群、更新PostgreSQL、編寫CI / CD + Ansible 管道、在Python / Bash / Go 中自動化某些操作、連接一個片段硬件到 DPC。 在任何領域的強大能力都不會妨礙改變活動方向並開始在其他領域發揮作用。 例如，我在一家公司找到了一份 PostgreSQL 專家的工作，現在我的主要職責領域是 Kubernetes 集群。 在團隊中，任何成長都是受歡迎的，肩負感非常發達。
順便說一句，我們打獵。 對候選人的要求非常標準。 對我個人來說，重要的是一個人融入團隊，不具對抗性，但也知道如何捍衛自己的觀點，想要發展，並且不害怕做新的事情，提出自己的想法。 此外，還需要腳本語言的編程技能、Linux 基礎知識和英語知識。 需要英語只是為了讓遇到 fakap 的人可以在 10 秒內而不是 10 分鐘內通過谷歌搜索到問題的解決方案。 對於對 Linux 有深入了解的專家來說，現在變得非常困難：有趣，但三分之二的候選人無法回答“什麼是平均負載？”這個問題。 它由什麼組成？”，而“如何從 sish 程序收集核心轉儲”這個問題被認為是來自超人……或恐龍世界的東西。 我們必須忍受這一點，因為通常人們都具有高度發展的其他能力，而我們將教授 Linux。 “為什麼 DevOps 工程師需要了解現代云世界中的所有這些”這個問題的答案必須超出本文的範圍，但用三個詞來說：所有這些都是必要的。
工具命令
工具團隊在自動化方面發揮著重要作用。 他們的主要任務是為開發人員創建方便的圖形和 CLI 工具。 例如，我們內部開發的 Confer 允許您只需點擊幾下鼠標即可將應用程序部署到 Kubernetes，配置其資源、保管庫中的密鑰等。 曾經有 Jenkins + Helm 2，但我必須開發自己的工具來消除複製粘貼並為軟件生命週期帶來統一性。
Ops 團隊不為開發人員編寫管道，但可以就編寫管道時出現的任何問題提供建議（有些仍然使用 Helm 3）。
DevOps的
對於 DevOps，我們是這樣看待的：
開發團隊編寫代碼，通過 Confer to dev -> qa/stage -> prod 將其推出。 開發和運營團隊有責任確保代碼不會變慢並且不會引發錯誤。 白天，運維團隊的值班人員應通過其應用程序對事件做出響應，而在傍晚和晚上，如果值班管理員（運維）確定問題不存在，則應叫醒值班開發人員。在基礎設施方面。 監控中的所有指標和警報都會自動或半自動出現。
Ops 的職責範圍從應用程序推出到生產的那一刻開始，但 Dev 的職責並沒有就此結束——我們做一件事，同舟共濟。
如果開發人員需要幫助編寫管理微服務（例如，Go 後端 + HTML5），他們會向管理員提供建議，管理員會就任何基礎設施或 k8s 相關問題向開發人員提供建議。
順便說一句，我們根本沒有單體應用，只有微服務。 如果按照數量來衡量，到目前為止，它們的數量在 prod k900s 集群中波動在 1000 到 8 之間 部署。 Pod 數量在 1700 到 2000 之間波動。現在 prod 集群中的 Pod 數量在 2000 個左右。
我無法給出確切的數字，因為我們會監控不必要的微服務並以半自動模式將其刪除。 跟踪 k8s 中不必要的實體可以幫助我們 從而節省資源和金錢。
資源管理
監控
精心構建且信息豐富的監控成為大型集群運行的基石。 我們尚未找到能夠 100% 滿足所有監控需求的通用解決方案，因此我們定期在此環境中鉚接不同的定制解決方案。
- ZABBIX。 良好的舊式監控，主要設計用於監控基礎設施的整體狀態。 它通過處理器、內存、磁盤、網絡等告訴我們節點何時死亡。 沒什麼超自然的，但我們還有一個單獨的 DaemonSet 代理，例如，借助它，我們可以監控集群中的 DNS 狀態：我們尋找愚蠢的 coredns pod，我們檢查外部主機的可用性。 看起來為什麼要為此煩惱，但在大量流量下，這個組件是一個嚴重的故障點。 以前我有 集群中的 DNS 性能如何掙扎。
- 普羅米修斯操作員。 一組不同的導出器可以很好地概述所有集群組件。 接下來，我們在 Grafana 的大型儀表板上可視化所有這些，並使用 Alertmanager 進行通知。
對我們來說另一個有用的工具是 。 我們多次遇到這樣的情況，即一個團隊的 Ingress 與其路徑重疊，導致 50 倍的錯誤，所以我們編寫了它。 現在，在部署到生產之前，開發人員會檢查它們是否不會傷害任何人，對於我的團隊來說，這是初步診斷 Ingress 問題的一個很好的工具。 有趣的是，一開始它是為管理員編寫的，看起來相當“笨拙”，但是當開發團隊愛上這個工具後，它發生了很大的變化，開始看起來不像“管理員為管理員製作了一個網頁界面” 。 很快我們將放棄這個工具，甚至在管道推出之前，這種情況就會得到驗證。
“魔方”中的團隊資源
在繼續舉例之前，有必要解釋一下我們如何進行資源分配 微服務.
了解哪些團隊以及使用的數量 ресурсы （處理器、內存、本地SSD），我們自己分配 命名空間 在“立方體”中，並限制其在處理器、內存和磁盤方面的最大能力，之前已經討論過團隊的需求。 因此，在一般情況下，一個命令不會阻塞整個集群的部署，為其自身分配數千個核心和 TB 的內存。 對命名空間的訪問是通過 AD 發出的（我們使用 RBAC）。 命名空間及其限制通過拉取請求添加到 GIT 存儲庫，然後所有內容都通過 Ansible 管道自動推出。
每個團隊的資源分配示例：
namespaces:
chat-team:
pods: 23
limits:
cpu: 11
memory: 20Gi
requests:
cpu: 11
memory: 20Gi
要求和限制
立方” 要求 是保證保留資源的數量 莢 （一個或多個 docker 容器）在一個集群中。 限制是無保證的最大值。 您經常可以在圖表上看到一些團隊如何為其所有應用程序設置太多請求，並且無法將應用程序部署到“多維數據集”，因為在他們的命名空間下，所有請求都已被“用完”。
解決這種情況的正確方法是查看實際的資源消耗並將其與請求量（Request）進行比較。
上面的截圖顯示，“請求”（Requested）的CPU被選擇為真實的線程數，並且Limits可以超過真實的CPU線程數=）
現在讓我們仔細看看一些命名空間（我選擇了命名空間 kube-system - “Cube”本身組件的系統命名空間）並查看實際使用的處理器時間和內存與請求的比率：
很明顯，為系統服務保留的內存和CPU比實際使用的要多得多。 在 kube-system 的情況下，這是合理的：峰值時的 nginx 入口控制器或 nodelocaldns 恰好依賴於 CPU 並消耗了大量 RAM，所以這裡這樣的餘量是合理的。 此外，我們不能依賴過去 3 小時的圖表：希望看到很長一段時間內的歷史指標。
開發了“建議”系統。 例如，在這裡您可以看到哪些資源最好提高“限制”（允許的上限），這樣就不會發生“限制”：Pod 已經在分配的時間量內使用 CPU 或內存的那一刻並等待它被“解凍”：
以下是可以調節他們食慾的豆莢：
Про 節流 + 監控資源，你可以寫多篇文章，所以在評論中提出問題。 簡而言之，我可以說自動化此類指標的任務非常困難，需要大量時間並平衡“窗口”函數和“CTE”Prometheus / VictoriaMetrics（這些術語用引號引起來，因為有PromQL 中幾乎沒有類似的情況，您必須在多個文本屏幕上屏蔽可怕的查詢並優化它們）。
因此，開發人員可以使用工具來監控“Cube”中的命名空間，並且可以選擇哪些應用程序可以在何時何地“削減”資源，以及可以為哪些 pod 提供整夜的整個 CPU。
方法論
像現在這樣的公司 時髦，我們堅持 DevOps-並且 SRE-從業者當一家公司擁有1000 個微服務、大約350 名開發人員和15 名管理員負責整個基礎設施時，你必須“變得時尚”：在所有這些“流行語”的背後，迫切需要自動化一切，而管理員不應該成為瓶頸在流程中。
作為運維人員，我們為開發人員提供與服務響應時間及其錯誤相關的各種指標和儀表板。
我們使用的方法例如： , и 將它們組合在一起。 我們嘗試盡量減少儀表板的數量，以便一目了然地了解當前正在降級的服務（例如，每秒的響應代碼、第 99 個百分位數的響應時間）等等。 一旦需要通用儀表板的一些新指標，我們就會立即繪製並添加它們。
我已經一個月沒有畫圖了。 這可能是一個好兆頭：這意味著大部分“願望”已經實現。 碰巧有一個星期我每天至少畫一次新圖表。
由此產生的結果很有價值，因為現在開發人員很少向管理員詢問“在哪裡可以看到某種指標”的問題。
Внедрение 服務網格 即將到來，應該會讓每個人的生活變得更加輕鬆，Tools 的同事已經接近實現抽象的“健康人的 Istio”：每個 HTTP(s) 請求的生命週期將在監控中可見，並且在服務間（而不僅僅是）交互中，始終可以了解“一切在哪個階段發生故障”。 訂閱來自 DomClick 中心的新聞。 =)
Kubernetes 基礎設施支持
歷史上，我們使用修補版本 庫貝噴霧 - 用於部署、擴展和更新 Kubernetes 的 Ansible 角色。 在某些時候，主分支切斷了對非 kubeadm 安裝的支持，並且沒有提出向 kubeadm 的過渡過程。 因此，南橋做了自己的分叉（支持 kubeadm 并快速修復關鍵問題）。
所有 k8s 集群的升級過程如下所示：
- 拿 庫貝噴霧 從南橋出發，請諮詢我們的分行 merjim。
- 推出更新 應力- “立方體”。
- 我們一次推出一個節點的更新（在 Ansible 中這是“serial: 1”） 開發- “立方體”。
- 更新中 刺 週六晚上，一次一個節點。
未來有計劃更換 庫貝噴霧 更快地去某事並去 庫貝德姆.
總的來說，我們有三個“立方體”：壓力、開發和生產。 我們計劃推出另一個雙機熱備）產品-第二個數據中心的“立方體”。 應力 и 開發 存在於虛擬機中（用於壓力的 oVirt 和用於開發的 VMWare 雲）。 刺- “Cube”依賴於“裸機”（裸機）：這些是相同的節點，具有 32 個 CPU 線程、64-128 GB 內存和 300 GB SSD RAID 10 - 總共有 50 個。 三個“瘦”節點專屬於“大師” 刺- “古巴”：16 GB 內存，12 個 CPU 線程。
對於銷售，我們更喜歡使用“裸機”並避免不必要的層，例如 OpenStack的：我們不需要“吵鬧的鄰居”和CPU 偷時間。 對於內部 OpenStack，管理的複雜性增加了大約一半。
對於 CI/CD Cubic 和其他基礎設施組件，我們使用單獨的 GIT 服務器 Helm 3 原子）、Jenkins、Ansible 和 Docker。 我們喜歡功能分支並從同一存儲庫部署到不同的環境。
結論
一般來說，從運維工程師的角度來看，DomClick 的 DevOps 流程就是這樣的。 這篇文章的技術含量比我預期的要低：因此，請關注 Habré 上的 DomClick 新聞：將會有更多關於 Kubernetes 等的“硬核”文章。
來源： www.habr.com