2021-07-02

配信URL

youtu.be

各タイトルを押していただくことで、実際の記事に飛びます。

Monitoring Kyverno with Prometheus

ついに、keyvernoがmonitoringされている例がでました。 keyvernoがに関しては、以下を参照ください。

cAdvisor and Kubernetes Monitoring Guide

Since cAdvisor is already integrated with the kubelet binary, ~~とあり、kubeletに統合されています。

この記事では、cpu, memory, diskなどの項目に関するmetric名やGrafanaから確認する方法についてが書かれているので、とても参考になる資料となっています。

Avoiding Kubernetes Cluster Outages with Synthetic Monitoring

Kuberhealthy
- khcheck / khjob（Kuberhealthy check / Kuberhealthy job）と呼ばれるカスタムリソースによって作成されたテストコンテナーを用いる
- khjobが1回実行されるのに対し、khcheckは定期的に実行されることを除いて、両方のカスタムリソースの機能はほぼ同じ
- Kuberhealthy合成チェックのユースケース
  - ネットワークの変更
    - 実行する必要のある主要なネットワーク変更がある場合は、HTTPまたはTCP khchecksを使用して重要なエンドポイントをチェック
  - IAMの変更
    - 適切なKIAM機能を検証するためのKIAMチェックがある。
  - エンドポイント接続
    - データベースやKey-Valueストアなど、クラスター外の重要な要素が稼働しているかどうかを常に確認できる。
  - AMI検証
    - AMIチェックを変更して、NTP同期、ディレクトリ構造、ユーザーアクセスなど、カスタムベイクされたAMIの重要な機能を確認できる。
  - CoreDNSチェック
  - リソースクォータチェック

demo

kuberhealthyをデプロイしていきます。

% kubectl create namespace kuberhealthy

% helm repo add kuberhealthy https://kuberhealthy.github.io/kuberhealthy/helm-repos
"kuberhealthy" has been added to your repositories

% helm install kuberhealthy kuberhealthy/kuberhealthy
NAME: kuberhealthy
LAST DEPLOYED: Fri Jul  2 22:06:02 2021
NAMESPACE: kuberhealthy
STATUS: deployed
REVISION: 1
TEST SUITE: None

デプロイされたか見ていきます。

% kubectl get pods -n kuberhealthy
NAME                            READY   STATUS    RESTARTS   AGE
kuberhealthy-8575448769-r8npz   1/1     Running   0          3d19h
kuberhealthy-8575448769-zslkx   1/1     Running   0          3d19h

なんかAgeがおかしい気もしますが、一旦進みます。

次に、サンプルのアプリを入れます。

% kubectl create deploy nginx --replicas 2 --image nginx:latest
deployment.apps/nginx created

% kubectl expose deployment nginx --type=NodePort --name=example-service --port 80                 
service/example-service exposed

では、アプリが見えるか確認していきます。

% curl 192.168.64.2:30795
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

今回、使うServiceは以下です。

% kubectl get svc
NAME              TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)        AGE
example-service   NodePort    10.105.7.80   <none>        80:30795/TCP   42m

では、以下のような2つのチェック用manifestを用意していきます。

今回、違いがわかるように、Service名ではなくIPで書いています。

URLが正しいもの

% cat kuberhealthy.yaml       
apiVersion: comcast.github.io/v1
kind: KuberhealthyCheck
metadata:
  name: nginx-reachable
  namespace: kuberhealthy
spec:
  runInterval: 2m
  timeout: 2m
  podSpec:
    containers:
      - name: nginx-reachable-check
        image: kuberhealthy/http-check:v1.5.0
        imagePullPolicy: IfNotPresent
        env:
          - name: CHECK_URL
            value: "http://10.105.7.80:80"
          - 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

URLがおかしいもの

apiVersion: comcast.github.io/v1
kind: KuberhealthyCheck
metadata:
  name: nginx-unreachable
  namespace: kuberhealthy
spec:
  runInterval: 2m
  timeout: 2m
  podSpec:
    containers:
      - name: nginx-unreachable-check
        image: kuberhealthy/http-check:v1.5.0
        imagePullPolicy: IfNotPresent
        env:
          - name: CHECK_URL
            value: "http://10.105.7.180:80"
          - 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

Applyすると以下のように確認ができます。

% kubectl get khcheck -n kuberhealthy     
NAME                AGE
nginx-reachable     20m
nginx-unreachable   18m

以下のような形でPodは作成されています。

% kubectl get pod -n kuberhealthy
NAME                            READY   STATUS      RESTARTS   AGE
kuberhealthy-8575448769-r8npz   1/1     Running     5          3d23h
kuberhealthy-8575448769-zslkx   1/1     Running     0          3d23h
nginx-reachable-1625242353      0/1     Completed   0          7m56s
nginx-reachable-1625242473      0/1     Completed   0          5m56s
nginx-reachable-1625242593      0/1     Completed   0          3m56s
nginx-reachable-1625242713      0/1     Completed   0          116s
nginx-unreachable-1625242725    1/1     Running     0          104s

では、実行結果を見ていきましょう。以下のServiceに対してport-forwardしていきます。

% kubectl get svc -n kuberhealthy
NAME           TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
kuberhealthy   ClusterIP   10.107.202.150   <none>        80/TCP    3d20h

% kubectl port-forward svc/kuberhealthy 8080:80 -n kuberhealthy

では、アクセスしてみます。

localhost:8080

以下のように、チェック結果を確認することができます。

{
  "OK": false,
  "Errors": [
    "Check execution error: kuberhealthy/nginx-unreachable: timed out waiting for checker pod to report in"
  ],
  "CheckDetails": {
    "kuberhealthy/nginx-reachable": {
      "OK": true,
      "Errors": [],
      "RunDuration": "17.206972822s",
      "Namespace": "kuberhealthy",
      "LastRun": "2021-07-02T14:23:13.09344293Z",
      "AuthoritativePod": "kuberhealthy-8575448769-r8npz",
      "uuid": "7401e1f7-330a-467d-9ad3-d0ea5e8a799f"
    },
    "kuberhealthy/nginx-unreachable": {
      "OK": false,
      "Errors": [
        "Check execution error: kuberhealthy/nginx-unreachable: timed out waiting for checker pod to report in"
      ],
      "RunDuration": "",
      "Namespace": "kuberhealthy",
      "LastRun": "2021-07-02T14:22:46.962592884Z",
      "AuthoritativePod": "kuberhealthy-8575448769-r8npz",
      "uuid": "9adf2caa-0a1d-42bb-9f45-a83ad94aedfa"
    }
  },
  "JobDetails": {},
  "CurrentMaster": "kuberhealthy-8575448769-r8npz"
}

What end-users want out of Prometheus remote storage: A comparison of M3 and Thanos

prometheusのリモートストレージソリューションとして、以下が人気
- Thanos
- M3
- Cortex
以下の観点でThanosとM3を比較
- 信頼性と可用性
  - Thanos
    - クエリアによって取得されたデータに加えてルール（アラートルールやPrometheusレコーディングルールなど）を適用できるネイティブクエリサービスがある。
    - Thanosの分散読み取りまたはクエリパスが原因で失敗率が高くなることがある。
  - M3
    - 集中ストレージを備えた最適化されたクエリエンジンを持つように構築および設計されている。
    - M3のクエリサービスは、クォーラム読み取りロジックを使用して、各データポイントの3つのコピーのうち少なくとも2つがM3DBからフェッチされ、クエリエージェント（Grafanaなど）に返される結果を一貫して計算する。
    - M3のクエリサービスはクエリ要求に優先順位を付けないため、要求（特に大規模な要求）の流入により、ボトルネックが発生し、クエリ処理全体の速度が低下する可能性がある。
- スケーラビリティとシンプルさ
  - Thanos
    - Thanosは、PrometheusのProxyの役割としてサイドカーで構成される。
    - ???
  - M3
    - 分散時系列データベース（M3DB）、取り込みおよびダウンサンプリング層（M3コーディネーター）、およびクエリエンジン（M3クエリ）の3つのコアコンポーネントで構成されている。
    - アーキテクチャ上、M3は簡単にスケールアップまたはスケールダウンできる。
    - M3DBは1つのユニットとして水平方向にスケールできるが、クラスター内のM3DBノードの数のサイズを変更する際、M3DBはステートフルであり、ノードメンバーシップの変更時にピアにデータをストリーミングするため、大規模な管理が困難になる可能性がある。
      - こちらは、Operatorによって自動的にスケールアップおよびスケールダウンできるようになっている。
- 効率とスピード
  - Thanos
    - Thanosサイドカーは、2時間のブロックでオブジェクトストレージにデータをアップロードする。
    - Thanosはコンパクターコンポーネントを使用してこれらのブロックを時間の経過とともにマージし、クエリ効率を向上させ、ストレージサイズを削減する。
    - Thanosコンパクターは一度に1つのインスタンスのリクエストのみを処理するように設定されているため、ユーザーはデータが完全に圧縮されるのを待ってから（つまり、2時間ごとに）集計データをクエリできる。
  - M3
    - すべてのダウンサンプリングおよびアグリゲーションはM3・コーディネーターによってローカルに行われる。
    - この設定では、集計はリアルタイムで行われ、各解決間隔の終わりに、集計されたメトリックがすぐにクエリに使用できます（つまり、5分の解像度でデータを集計する場合は5分ごと）。
    - M3コーディネーターサイドカーにダウンタイムがあると、集約されたデータが失われる可能性がある。
- アフォーダビリティ