DomClick での Kubernetes: 1000 個のマイクロサービスのクラスターを安らかに管理しながら眠る方法

私の名前は Viktor Yagofarov です。DomClick で Ops (運用) チームの技術開発マネージャーとして Kubernetes プラットフォームを開発しています。 私たちの Dev <-> Ops プロセスの構造、ロシア最大の k8s クラスターの XNUMX つを運用する特徴、そして私たちのチームが適用している DevOps/SRE の実践についてお話したいと思います。

作戦チーム

運用チームには現在 15 人がいます。 そのうち XNUMX 人はオフィスを担当しており、XNUMX 人は別の時間帯で勤務しており、夜間も含めて勤務可能です。 したがって、運用部門の誰かが常に監視しており、あらゆる複雑なインシデントに対応する準備ができています。 私たちには夜勤がないので、精神が保たれ、誰もが十分な睡眠をとり、コンピューターに向かうだけでなく余暇を過ごす機会が与えられます。

ネットワーカー、DBA、ELK スタック スペシャリスト、Kubernetes 管理者/開発者、モニタリング、仮想化、ハードウェア スペシャリストなど、誰もが異なる能力を持っています。 8 つのことが全員を団結させます - 誰もがある程度私たちの誰かを置き換えることができます。たとえば、kXNUMXs クラスターに新しいノードを導入し、PostgreSQL を更新し、CI/CD + Ansible パイプラインを作成し、Python/Bash/Go で何かを自動化し、ハードウェアをデータセンター。 どの分野でも優れた能力を持っていても、活動の方向性を変えて他の分野で改善を始めることができます。 たとえば、私は PostgreSQL スペシャリストとして会社に入社し、現在は Kubernetes クラスターを主に担当しています。 チームではどんな身長でも歓迎され、影響力の感覚が非常に発達しています。

ちなみに私たちは狩りをしています。 候補者に対する要件は非常に標準的です。 私個人にとっては、その人がチームに適応し、対立がなく、自分の視点を守る方法を知っており、成長したいと考え、新しいことをすることを恐れず、アイデアを提供できることが重要です。 また、スクリプト言語のプログラミングスキル、Linux の基礎、英語の知識も必要です。 英語が必要なのは、単にファカップが発生したときに、Google で問題の解決策を 10 分ではなく 10 秒で検索できるようにするためです。 現在、Linux について深い知識を持つ専門家を見つけるのは非常に困難です。おかしな話ですが、候補者の XNUMX 人中 XNUMX 人が「負荷平均とは何ですか?」という質問に答えることができません。 それは何でできていますか?」、「C プログラムからコア ダンプをアセンブルする方法」という質問は、スーパーマンや恐竜の世界のものと考えられます。 通常、人々は他の能力を高度に発達させているため、これは我慢しなければなりませんが、私たちは Linux を教えます。 「現代のクラウドの世界において、なぜ DevOps エンジニアがこれらすべてを知る必要があるのか​​」という質問に対する答えは、この記事の範囲外に置く必要がありますが、XNUMX つの言葉で言えば、「これはすべて必要です」です。

チームツール

ツール チームは自動化において重要な役割を果たします。 彼らの主な任務は、開発者にとって便利なグラフィカル ツールや CLI ツールを作成することです。 たとえば、社内開発の Confer を使用すると、マウスを数回クリックするだけで文字通りアプリケーションを Kubernetes にロールアウトし、そのリソースやボールトからのキーなどを構成できます。 以前は Jenkins + Helm 2 がありましたが、コピー＆ペーストを排除してソフトウェア ライフサイクルに統一性をもたらすために独自のツールを開発する必要がありました。

Ops チームは開発者向けにパイプラインを作成しませんが、作成上の問題についてアドバイスすることはできます (まだ Helm 3 を使用している人もいます)。

DevOps

DevOps については、次のようになります。

開発チームはコードを作成し、開発 -> QA/ステージ -> 製品への会議を通じて展開します。 コードの速度が低下せず、エラーが含まれていないことを確認する責任は、開発チームと運用チームにあります。 日中は、運用チームの担当者がまずアプリケーションのインシデントに対応する必要があります。夕方と夜間には、当番の管理者 (Ops) が気づいた場合は勤務中の開発者を起こす必要があります。問題がインフラストラクチャにあるのではないことを確認してください。 モニタリングのすべてのメトリクスとアラートは、自動的または半自動的に表示されます。

運用部門の責任範囲は、アプリケーションが運用環境に展開された瞬間から始まりますが、開発者の責任はそこで終わりません。私たちは同じことを行い、同じ立場にあります。

開発者は、管理用マイクロサービス (Go バックエンド + HTML5 など) の作成にサポートが必要な場合に管理者にアドバイスし、管理者はインフラストラクチャの問題や k8s に関連する問題について開発者にアドバイスします。

ちなみに、私たちはモノリスをまったく持っておらず、マイクロサービスだけを持っています。 数で測定すると、これまでのところ、prod k900s クラスター内のその数は 1000 から 8 の間で変動しています。 配備。 ポッドの数は 1700 ～ 2000 の間で変動します。現在、本番クラスターには約 2000 のポッドがあります。

不要なマイクロサービスを監視し、半自動的に削除するため、正確な数字は言えません。 K8s は不要なエンティティを追跡するのに役立ちます 役に立たない演算子、多くのリソースとお金を節約します。

資源管理

監視

適切に構造化された有益な監視は、大規模クラスターの運用の基礎となります。 すべての監視ニーズを 100% カバーする普遍的なソリューションはまだ見つかっていないため、この環境ではさまざまなカスタム ソリューションを定期的に作成しています。

• ザビックス。 古き良き監視。主にインフラストラクチャの全体的な状態を追跡することを目的としています。 これは、処理、メモリ、ディスク、ネットワークなどの観点からノードがいつ停止したかを示します。 超自然的なことは何もありませんが、エージェントの個別の DaemonSet もあり、これを利用して、たとえばクラスター内の DNS の状態を監視します。愚かな coredns ポッドを探し、外部ホストの可用性をチェックします。 なぜわざわざこれを行う必要があるのか​​と思われるかもしれませんが、大量のトラフィックが発生すると、このコンポーネントは重大な障害点になります。 私はもう 説明された、クラスター内の DNS パフォーマンスにどのように苦労したか。
• プロメテウスオペレーター。 さまざまなエクスポーターのセットにより、クラスターのすべてのコンポーネントの概要がわかります。 次に、これらすべてを Grafana の大きなダッシュボードで視覚化し、アラートにアラートマネージャーを使用します。

私たちにとってもう XNUMX つの便利なツールは、 リスト入力。 あるチームが別のチームの Ingress パスと重複し、50 倍のエラーが発生する状況に何度か遭遇した後にこの記事を書きました。 現在、開発者は運用環境にデプロイする前に、誰も影響を受けないことを確認しています。私のチームにとって、これは Ingresses の問題の初期診断に適したツールです。 面白いことに、最初は管理者向けに書かれており、かなり「ぎこちない」ように見えましたが、開発チームがこのツールに夢中になった後は大きく変わり、「管理者が管理者のために Web の顔を作成した」ようには見えなくなりました。 」 間もなくこのツールは廃止され、そのような状況はパイプラインが展開される前であっても検証される予定です。

キューブ内のチーム リソース

例に入る前に、リソースをどのように割り当てるかを説明する価値があります。 マイクロサービス.

どのチームがどのくらいの量を使用しているかを理解するため ресурсы (プロセッサ、メモリ、ローカル SSD)、各コマンドを独自に割り当てます。 名前空間 チームのニーズを事前に議論した上で、「Cube」のプロセッサ、メモリ、ディスクの最大能力を制限します。 したがって、通常、XNUMX つのコマンドでクラスター全体の展開がブロックされず、数千のコアとテラバイトのメモリが割り当てられます。 名前空間へのアクセスは AD を通じて許可されます (RBAC を使用します)。 名前空間とその制限は、プル リクエストを通じて GIT リポジトリに追加され、すべてが Ansible パイプラインを通じて自動的にロールアウトされます。

チームにリソースを割り当てる例:

namespaces:

  chat-team:
    pods: 23
    limits:
      cpu: 11
      memory: 20Gi
    requests:
      cpu: 11
      memory: 20Gi

リクエストと制限

立方体」 リクエスト 保証されている予約リソースの数です。 ポッド クラスター内の (XNUMX つ以上の Docker コンテナー)。 制限値は保証されていない最大値です。 グラフを見ると、一部のチームがすべてのアプリケーションに対して多すぎるリクエストを設定しており、名前空間内のすべてのリクエストがすでに「使用されている」ため、アプリケーションを「キューブ」にデプロイできない様子がよくわかります。

この状況から抜け出す正しい方法は、実際のリソース消費量を確認し、それを要求された量 (リクエスト) と比較することです。

上のスクリーンショットでは、「要求された」CPU が実際のスレッド数と一致しており、制限が実際の CPU スレッド数を超える可能性があることがわかります =)

次に、いくつかの名前空間を詳細に見てみましょう (私は名前空間 kube-system を選択しました - 「Cube」自体のコンポーネントのシステム名前空間です)、要求されたものに対する実際に使用されたプロセッサ時間とメモリの比率を確認してみましょう。

実際に使用されるよりもはるかに多くのメモリと CPU がシステム サービス用に予約されていることは明らかです。 kube システムの場合、これは正当化されます。たまたま nginx イングレス コントローラーまたはノードローカル DNS がピーク時に CPU にアクセスし、大量の RAM を消費したため、ここではそのような予約が正当化されます。 さらに、過去 3 時間のチャートに依存することはできません。長期間にわたる履歴メトリクスを確認することが望ましいです。

「推薦制度」を創設しました。 たとえば、ここでは、「スロットル」が発生しないように「制限」（許容される上限）を上げたほうがよいリソースを確認できます。つまり、割り当てられたタイム スライスでリソースがすでに CPU またはメモリを消費した瞬間、および「凍結が解除される」まで待機しています。

そして、彼らの食欲を抑えるはずのサヤは次のとおりです。

オン スロットリング + リソース監視、複数の記事を書くことができるので、コメントで質問してください。 一言で言えば、このようなメトリクスを自動化するタスクは非常に難しく、多くの時間を必要とし、「ウィンドウ」機能と「CTE」Prometheus / VictoriaMetrics とのバランスをとる必要があると言えます (これらの用語は引用符で囲まれています。 PromQL ではこのようなことはなく、恐ろしいクエリをテキストのいくつかの画面に分割して最適化する必要があります)。

その結果、開発者は Cube の名前空間を監視するツールを利用できるようになり、いつ、どこでどのアプリケーションがリソースを「カット」できるか、どのサーバーに一晩中 CPU 全体を割り当ててもよいかを自分で選択できるようになりました。

方法論

今の会社では おしゃれ、私たちは DevOps に準拠しており、 SRE-実践者企業が 1000 のマイクロサービス、インフラストラクチャ全体に対して約 350 人の開発者、および 15 人の管理者を抱えている場合、「ファッショナブルである」必要があります。これらすべての「卑劣」の背後には、すべてを自動化する緊急の必要性があり、管理者がボトルネックになるべきではありません。プロセス中。

運用部門として、サービスの応答率とエラーに関連するさまざまなメトリクスとダッシュボードを開発者に提供します。

私たちは次のような方法論を使用します。 RED, USE и ゴールデンシグナルそれらを組み合わせることで。 現在どのサービスが低下しているのかが一目でわかるように、ダッシュボードの数を最小限に抑えるよう努めています (たとえば、99 秒あたりの応答コード、XNUMX パーセンタイル別の応答時間など)。 一般的なダッシュボードに新しいメトリクスが必要になると、すぐにそれらを描画して追加します。

もう一ヶ月もグラフを描いていない。 これはおそらく良い兆候です。これは、「願望」のほとんどがすでに実現されていることを意味します。 偶然にも、その週は少なくとも XNUMX 日に XNUMX 回は新しいグラフを描くようになりました。

現在、開発者が管理者に「ある種のメトリクスをどこで確認すればよいか」という質問をすることはほとんどないため、結果として得られる結果は貴重です。

実装 サービス メッシュ はもうすぐそこまで来ており、誰にとっても生活がはるかに楽になるはずです。Tools の同僚はすでに抽象的な「健康な人の Istio」の実装に近づいています。各 HTTP(s) リクエストのライフ サイクルはモニタリングで可視化され、サービス間 (だけではありません) の対話中に、「どの段階ですべてが壊れたのか」を常に理解できるようになります。 DomClick ハブからニュースを購読します。 =)

Kubernetes インフラストラクチャのサポート

これまで、パッチ適用済みのバージョンを使用していました キューブスプレー — Kubernetes のデプロイ、拡張、更新のための Ansible ロール。 ある時点で、kubeadm 以外のインストールのサポートがメイン ブランチから打ち切られ、kubeadm に切り替えるプロセスは提案されませんでした。 その結果、Southbridge 社は (kubeadm サポートと重大な問題の迅速な修正を備えた) 独自のフォークを作成しました。

すべての k8s クラスターを更新するプロセスは次のようになります。

• 取る キューブスプレー サウスブリッジからの場合は、スレッド Merjim で確認してください。
• アップデートをロールアウトしています ストレス- 「キューブ」。
• 一度に 1 ノードずつ更新をロールアウトします (Ansible では、これは「シリアル: XNUMX」です)。 デベロッパー- 「キューブ」。
• 更新します 突く 土曜日の夕方に一度に XNUMX つのノードずつ実行します。

将来的には置き換える予定です キューブスプレー もっと早く何かしたい場合は、次の場所に移動してください クビーズ.

合計で XNUMX つの「キューブ」があります: Stress、Dev、Prod。 他にも発売する予定です(ホットスタンバイ) XNUMX 番目のデータセンターの製品「Cube」。 ストレス и デベロッパー 「仮想マシン」（ストレスの場合は oVirt、開発の場合は VMWare クラウド）に存在します。 突く- 「Cube」は「ベア メタル」上に存在します。これらは 32 個の CPU スレッド、64 ～ 128 GB のメモリ、および 300 GB SSD RAID 10 を備えた同一のノードであり、合計で 50 個あります。 XNUMX つの「シン」ノードは「マスター」専用です 突く- 「キューバ」: 16 GB のメモリ、12 CPU スレッド。

販売に関しては、「ベアメタル」を使用することを好み、次のような不必要なレイヤーを避けます。 OpenStackは: 「うるさい隣人」と CPU は必要ありません 時間を盗む。 また、社内 OpenStack の場合、管理の複雑さは約 XNUMX 倍になります。

CI/CD「Cubic」およびその他のインフラストラクチャ コンポーネントには、別の GIT サーバーである Helm 3 を使用します (Helm 2 からの移行はかなり苦痛でしたが、オプションには非常に満足しています) アトミック)、ジェンキンス、Ansible、Docker。 私たちは機能ブランチと XNUMX つのリポジトリからさまざまな環境へのデプロイメントを好みます。

まとめ

これは、一般的に、DomClick における DevOps プロセスをオペレーション エンジニアの観点から見たものです。 この記事は、私が予想していたよりも技術的な内容ではありませんでした。したがって、Habré に関する DomClick ニュースをフォローしてください。Kubernetes などに関する「ハードコア」記事がさらに増える予定です。

出所： habr.com