合成モニタリングによるKubernetesクラスタ停電の回避

合成モニタリングとは何か

合成モニタリングは、あらかじめ定義されたチェックで構成され、インフラストラクチャの重要な要素を積極的に監視します.これらのチェックは、要素の機能をシミュレートします.また、エンドツーエンド接続を確実にするために要素間のコミュニケーションをシミュレートすることができます.これらのチェックの連続監視も、有効性と応答時間に関して総合的なパフォーマンスを測定するのを助けます.
Kubernetesクラスタの合成チェックの範囲を絞り込み、残りのポストは同じに基づいています.
合成チェックは、SREが問題を特定するのを助けることができて、それが実際のビジネスに影響を及ぼす前に、遅い反応とダウンタイムを決定することができます.アップグレード、主要なアーキテクチャ変更、または任意の機能リリース中にネットワークの障害、誤動作、エンドツーエンド接続の損失などを積極的に検出するのに役立ちます.

合成チェックはなぜKubernetesで重要か？

Kubernetesは同時に実行されている分散プロセスのコレクションです.このように、Kubernetesクラスタの失敗ドメインを識別することは、厄介な仕事でありえる.よく説明された合成チェックは、意図されたワークフローを複製して、そのパフォーマンスを測定することによって、これらの失敗ドメインのために可能なダウンタイムを減らすか、避けることができます.いくつかの不良ドメインは次のように記述できる.

ノードの問題(Dockerデーモン/Kubeletが失敗した状態では、CNIの失敗による未割り当てのIPアドレスなど).

PODの問題(失敗したヘルスチェック、実行状態にないPODなど)

名前空間の問題(名前空間でスケジュールできないPOD )

DNS解決問題( coredns lookup failure )

ネットワークの問題(ネットワークポリシーの変更など)

そして、より多く...

Kubernetes合成チェック／モニタリングに利用できるツール

があるmultiple tools available for synthetic monitoring, AppDynamicsなどの新しい遺物、dynatraceなど.このポストのために、Kubernetesネイティブ合成チェックに集中しましょう.
このポストを書く時に、2つのツールはKubernetes自然合成チェック(すなわちKuberhealthとGrafana雲)を持ちます.Kuberhealthy Grafana Cloudは、定期的に定義済みエンドポイントをチェックするプローブからデータを収集するためにエージェントを使用しています.Kuberhealth Grafanaクラウドに比べて、より多くの合成チェックを提供し、また、オープンソースのオプションです.このように、我々はKubernetesクラスタでKuberhealthの助けを借りて合成モニタリングを調査します.

何が健康ですか？

KuberHealthは、合成チェックを実行する演算子です.それぞれの合成チェックは、Khcheck/Khjob(KuberHealth Check/KuberHealth Job)と呼ばれるカスタムリソースによって作成されたテストコンテナーです.一旦チェックが作成されると、Kuberhealthは与えられた間隔で、そして、与えられたタイムアウトの範囲内のすべてのチェックをスケジュールします.合成チェックはKhcheckまたはKhjobの形で定義されます.両方のカスタムリソースは、Khcheckは定期的に実行されますが、Khjobは1回実行されることを除いて機能性でほとんど同じです.

展開チェック[礼儀正しい]
特定のKhCheckに対応するKuberhealthなプログレスポッド.目的が出されるとチェッカーポッドは破壊される.作成/削除サイクルは、期間の期間によって定期的に繰り返されるrunInterval/timeout KHCHECK構成でそれぞれ.結果はそれからKuberHealthに送られます.そして、順番にメトリクスと地位終点にそれを送ります.監視のために、我々はPrometheusと統合したり、JSONベースのステータスページでそれを表示することができます.このページはすべてのKhcheckの統合状態を与えます.

Kuberhealthで利用可能なチェック

コアKubernetes関数をチェックする前に定義されたチェックがあります.我々は、Kuberhealthによって直接提供されるチェックを使用することができます、あるいは、我々はユースケースに従って我々自身のカスタムチェックを書くこともできます.
ここでは、KHCHECKの1つの例です.データベース/ストレージ上のCRUD操作を実行する任意のアプリケーションでは、定数の接続が必要です.Kuberhealth HTTPチェックHTTP/HTTPSのエンドポイントの接続性をチェックするのに役立ちます.たとえば、以下のKHCHECKはMinioクラスタの到達可能性をチェックします.現実的なシナリオをシミュレートするために、minioはngrokを介して公開されます.接続が成功した場合、OK: true 接続が切断された場合、OK: false .

apiVersion: comcast.github.io/v1
kind: KuberhealthyCheck
metadata:
  name: a-minio-reachable
  namespace: kuberhealthy
spec:
  runInterval: 2m
  timeout: 2m
  podSpec:
    containers:
      - name: a-minio-reachable
        image: kuberhealthy/http-check:v1.5.0
        imagePullPolicy: IfNotPresent
        env:
          - name: CHECK_URL
            value: "http://ff333084d5a0.ngrok.io/login"
          - name: COUNT #### default: "0"
            value: "5"
          - name: SECONDS #### default: "0"
            value: "1"
          - name: PASSING_PERCENT #### default: "100"
            value: "100"
          - name: REQUEST_TYPE #### default: "GET"
            value: "GET"
          - name: EXPECTED_STATUS_CODE #### default: "200"
            value: "200"
        resources:
          requests:
            cpu: 15m
            memory: 15Mi
          limits:
            cpu: 25m
    restartPolicy: Always
    terminationGracePeriodSeconds: 5

重要な用途のいくつかについては、次のセクションで説明します.

Kubernetesクラスタにおける主要な停電をいかに避けたか

AWSで展開されたKubernetesクラスタが多数のマイクロサービスで成長し始めたので、IPアドレス不足に直面し始めました.問題はバーストスケーリングやアップグレード中に深刻になるでしょう.実現可能な解決策は、AWSが提供する二次CIDRソリューションを組み込むことであった.しかし、これは多くのネットワーク変更を必要としました.ちょっとした間違いが大きな停電をもたらすかもしれない.
私たちは解決策を望みました.そして、それは解決のローテーションの間、misconfigurationを特定する若干の時間を買います.すべてのマイクロサービスに依存するサービスの終点を特定した.我々はそれぞれのTCPとHTTP KHCHECKを作成し、KHCHECKマニフェストと一緒にKuberhealthインストールしました.次のイメージは、二次CIDRを展開する前にセットアップを示します.すべてのポッドは依存サービスに接続できます.
(この図はシナリオの最小バージョンです).

今すぐロールアウト中に、我々はすべての新しいpod IPアドレス(100.64 . x . x)でうまく動作することを確認したい.このように、我々は手動で二次CIDRを使用するクラスタに1つの新規なノードを加えた.KHCHECKは新しいノードの上でdaemauseを置き、すべての終点で連結性をチェックしました.我々は、エンドポイントのいくつかが接続できないことに気づいた.

我々は、セキュリティグループ、NACLS、およびWOWsで必要なホワイトライニングをチェックし、新しいCIDRがいくつかのWAWSで白くなっていないことを発見しました.WAFの設定を修正しました.その後、実際の二次CIDRのロールを続行し、すべてが示されたようにうまく働いた.

このように、我々はKuberhealthの助けを借りて、主要な停電から我々のKubernetesクラスタを保護しました.

Kuberhealth合成検査のユースケース

KuberHeatsは、Kubernetesクラスタを信頼性の高いものにするために、次のユースケースで役立つことができます.

ネットワーク変更

主要なネットワーク変更があるならば、あなたが実行しなければならないならば、HTTPまたはTCP Khcheckを使用して重要な終点の上でいくつかのチェックをすることはどんな誤った構成も見つけるのを助けて、積極的に主要な休止時間を避けるかもしれません.

IAM変更

KuberHealthはキムチェックを行い、適切なキーム機能を確認します.この概念は、ワークロードのIAMアクセスに厳格でなければならないどんな生産等級クラスタにもさらに拡張されることができます.アクセスを強化している間、セキュリティチームは必要なアクセスを妨害するかもしれません.適切なIAMチェックを行うことで、ダウンタイムを最小限に抑えることができます.
また、不要なアクセスをチェックすることもできます.私たちは、常にすべてのワークロードにこのアクセスを提供している場合は、フルアクセスまたはパワーユーザーアクセスと警告を常にチェックするKHCheckを変更することができます.

エンドポイント接続

我々は常に、データベースのようなクラスタの外の重要な要素は、キー値のストアは、それぞれの終点と接続性を監視KHCHECKと実行しているかどうかチェックすることができます.

アミ検証

Amazon Marketplaceには、クラスタで使用されるAMIを検証するための定義済みAMIチェックがあります.AMIチェックを変更して、NTP同期、ディレクトリ構造、ユーザアクセスなどのカスタム焼き組のAMIで重要な機能を確認できます.

コードンズチェック

不適切なcorednsの設定は、重い負荷でのDNS解決を妨げる可能性があります.したがって、DNSチェックはそのようなシナリオで内部と外部の両方のDNS解決の状態を提供することができます.この上の詳細を知るには、このガイドに従ってください.

リソースクォータチェック

リソースクォータチェックは、リソースクォータで有効になっている生産グレードクラスタで実行されるべき別の有用なチェックです.特定の名前空間のリソースクォータが最大負荷でのスケーリングによって使い尽くされたとする.追加の負荷を提供するために必要な新しいポッドは、その期間内にビジネスに影響を与える名前空間に配置できません.
これらのユースケースは、一般的に観察される多くの数である.あなたのインフラストラクチャに従ってあなたのユースケースを持って、あなたの小切手を同じように書くことができます.

結論

ここでは以下の点を取り上げた.

生産規模クラスタにおける総合モニタリングとその重要性は何か?

合成チェックはなぜKubernetesクラスタにとって重要か?

何が健康ですか?

どのように我々は主要な停電からKubernetesクラスタを保護したか?

どのようないくつかの重要なユースケースの合成チェックKuberhealthですか?

それを合計するために、このポストは、停電を避けて、基盤信頼性を増やすためにKubernetesクラスタの総合的なモニタリングのためにKuberhealthなツールにあなたを紹介しました.
この記事があなたにとって有益であり、あなたが更なる質問をする場合には、私との会話を始めるのを自由に感じてください.ハッピーコーディング

参考文献

https://kubernetes.io/blog/2020/05/29/k8s-kpis-with-kuberhealthy/

https://www.infoq.com/news/2019/05/kuberhealthy-synthetic-testing/

https://opensource.com/article/19/4/kuberhealthy

https://grepmymind.com/kuberhealthy-the-writing-the-ami-exists-check-c9e986298e4

https://medium.com/box-tech-blog/a-trip-down-the-dns-rabbit-hole-understanding-the-role-of-kubernetes-golang-libc-systemd-41fd80ffd679

https://geekflare.com/synthetic-monitoring-tools/