[CNDK2019]Production Ready Kubernetesに必要な15のこと / Production Ready Kubernetes 15 Rules

C174e1ef0c746f53d989b1902b4e674e?s=47 go_vargo
November 28, 2019

[CNDK2019]Production Ready Kubernetesに必要な15のこと / Production Ready Kubernetes 15 Rules

C174e1ef0c746f53d989b1902b4e674e?s=128

go_vargo

November 28, 2019
Tweet

Transcript

  1. 2.

    2 名前: 磯 賢大(@go_vargo) 所属: 株式会社コロプラ    インフラグループ 第2チーム 趣味:

    Kubernetesの裏側の仕組みを知ること / コントリビューション(minikube) 出版: 「実践Helm」インプレスR&D 自己紹介 外部発表: ・コロプラが実践しているSpinnakerを用いたデプロイ戦略 @ kubernetes Meetup #21 ・ゼロから始めるKubernetes Controller @ kubernetes Meetup #23 ・Docker Meetup, CloudNative Meetup, 他...
  2. 3.

    3 ・本番環境のKubernetesマニフェストに最低限必要な7のこと https://speakerdeck.com/masayaaoyama/jkd1812-prd-manifests ・Kubernetesを運用したことで学んだアンチパターン https://speakerdeck.com/goto_hidenobu/cloudnativedaystokyo-2019-slide ・The Twelve-Factor App https://12factor.net/ ・Cluster

    Ready Checklist for Kubernetes https://www.weave.works/blog/production-ready-checklist-kubernetes ・Application Checklist for Kubernetes https://www.weave.works/blog/application-checklist-kubernetes ・12 Kubernetes configuration best practices https://www.stackrox.com/post/2019/09/12-kubernetes-configuration-best-practices/ 参考にした資料
  3. 4.

    4 本講演で目指すこと - Kubernetesプラットフォームを構築する上で、押さえておきたい考慮点をまとめること ※ 特に分散システムならではの、本番環境を想定した、気をつけておきたい箇所 注意点 - 本講演で想定しているのは、Webアプリケーション基盤におけるKubernetesです -

    Kubernetesクラスタ自体をどうセキュアに構築すべきか、という点には触れていません ※クラスタが構築されている上で、気をつけるべきものをピックアップしています - 自社でのベストプラクティスの考え方も入れていますが、 全てが全てベストプラクティスとは考えてはいません(模索しているものもあります) - 自社で各テーマをどのように取り組んでいるかを随所で紹介していますが、 あくまで一例と捉えていただけると幸いです 目的
  4. 5.

    5 1. CI/CD 2. Manifest Management 3. Observability 4. Initial

    Processing 5. Graceful Shutdown 6. HealthCheck 7. Config Injection 8. Maintenance / Upgrade Agenda 9. Resource Management 10. Scheduling 11. Scaling 12. Security / Auth / Authz 13. External Traffic 14. Tuning 15. Stateful Application - Appendix
  5. 7.

    7 CI/CD CI/CDはOrchestrationの手前に あるものです。 Production Ready Kubernetes には必須と言えます。 = CI/CDはきちんと作りましょう

    CI/CDのツールは、非常に多くの 選択肢があります。 何を使うかはユースケースに合わ せて検討しましょう。 出典: CNCF TraipMap https://github.com/cncf/trailmap
  6. 8.

    8 CI/CD CNCF Product 出典: CNCF Landscape https://landscape.cncf.io 時代はCI/CD戦国時代です。 CI/CDを実現するためのツールの選択肢は

    非常に多くあります。 KubernetesがDeclarative APIであることを活 かして、マニフェストファイルを用いたCI/CD として、GitOpsモデルでデリバリすることを 想定したプロダクトも多くあります。 参考: Kubernetes anti-patterns: Let's do GitOps, not CIOps! https://www.weave.works/blog/kuberne tes-anti-patterns-let-s-do-gitops-not-ci ops
  7. 9.

    9 GitOps with Single Source of Truth 引用元: https://www.weave.works/technologies/gitops/ 参考:

    5 GitOps Best Practices https://blog.argoproj.io/5-gitops-best-practices-d95cb0cbe9ff
  8. 10.

    10 CI/CD @ Colopl CI: GitLab Runner CD: Spinnaker Spinnakerで、多様なデプロイ戦略を

    ステージという形で表現できるため 採用しました カナリアリリースの他に、 新規環境構築のPipelineなどを構築 事例詳細は下記資料に記載 コロプラが実践しているSpinnaker を用いたデプロイ戦略 https://speakerdeck.com/govargo/depl oy-strategy-with-spinnaker-at-colopl
  9. 12.

    12 マニフェスト管理 Kubernetesの管理には直結しない部分で 重要になるものの一つが マニフェスト管理です。 Infrastructure as Codeであるため、 マニフェストファイルを管理する 必要があります。

    マニフェスト管理にも代表的なツールや 管理方法に種類があります。 どちらが優れている、というものでは ないので、ユースケースに合わせて 選択しましょう。 出典: CNCF TraipMap https://github.com/cncf/trailmap
  10. 13.

    13 マニフェスト管理の考え方 Mono Repository Multi Repository or アプリケーション ソース インフラ

    マニフェスト アプリケーション ソース インフラ マニフェスト
  11. 14.

    14 Helm ・CNCF Incubating Projectのプロダクトで、Kubernetesのパッケージマネージャ ・Chartと呼ばれるマニフェストテンプレートをK8sクラスタにインストールする ・Releaseという単位で、インストールやアップデート、削除などを実施可能 ・values.yamlと呼ばれる設定値を記載したYAMLによって挙動を変更できる Kustomize ・kubectl(v1.14〜)に統合されているマニフェスト管理ツール

    ・overlayによって、環境ごとにマニフェストの設定値(variants)を変更できる ・YAMLを生成するGenerator機能や、YAMLの変更を行うTransform機能がある ・他SIGs(※) Project(Kubebuilder)でも活用されている よく使われるマニフェスト管理ツール ※SIGs https://github.com/kubernetes/community/blob/master/sig-list.md
  12. 15.

    15 マニフェスト管理にはHelm(v2)を利用しています(Helm3に移行検証中)。 プロジェクト横断で使える共通のHelm ChartをGit Submodule用に用意しており、 values.yaml(マニフェストファイルの設定値)のみProject固有のGitリポジトリで 管理しています。 マニフェスト管理 @ Colopl

    公式: https://helm.sh/ Project A / ┣ Chart A Directory / ┃ ┣ Common Chart A / ┃ ┣ values.dev.yaml ┃ ┣ values.stg.yaml ┃ ┗ values.prd.yaml Project B / ┣ Chart B Directory / ┃ ┣ Common Chart B / ...... マニフェスト管理の例 よく使うコマンド類はスクリプト化しています e.g. マニフェスト差分比較ツール
  13. 22.

    22 Monitoring: Prometheus + Grafanaを使ってMonitoring Prometheusだけで負荷分散できない時はVictoriaMetrics を使って水平スケーリングしています。 Logging: DaemonSetで配置したFluentdでログを収集し、 Stackdriver

    Loggingにてフィルターします。 Tracing: 以前はOpenCencusをアプリケーションコードに組み込 んで、Stackdriver Tracingで結果を確認していました。 現在はDatadog APMを活用しています Observability @ Colopl Monitoring Logging Stackdriver Logging + Tracing Stackdriver Tracing + Datadog APM
  14. 26.

    26 Kubernetesでの初期処理/前処理の設定方法として下記の方法があります。 1. initContainer ・Main Container起動前に、初期化用のコンテナを起動する 2. Entrypoint ・Container起動時のスクリプト内で、初期化処理を記載しておく 3.

    SideCar ・Main Containerと並行して、Containerを立ち上げてデータを更新する 4. postStart ・Container内のプロセスが起動した直後に、スクリプトを実行する Kubernetesにおける初期処理の実行方法
  15. 27.

    27 Initial Processing @ Colopl コンテナのEntrypointの処理の中で、コストのかかるWarmupを、プロセス起動前に行う Process Start #!/bin/bash artisan

    db:warmup artisan master-data:preload echo 1 > /app/.health startup.sh entrypoint.sh Warmup 前処理 HealthCheck ステータス更新 APP DB Warmup Preload
  16. 30.

    30 Kubernetesでの後処理の設定方法として下記の方法があります。 1. Entrypoint ・コードやスクリプト内でシグナルハンドリングする 2. preStop ・コンテナ停止時にHookで起動する Graceful Shutdownになるよう停止処理を書く

    Kubernetesにおける後処理の実行方法 preStop SIGTERM SIGKILL Delete Pod Running SIGTERM送信 SIGKILL送信 Pod削除 terminationGracePeriodSeconds(default: 30s) Terminatin g 任意のスクリプト やhttpGetなど Terminated Pod Terminating LifeCycle
  17. 31.

    31 Graceful Shutdown @ Colopl spec.containers[].lifecycle.preStopでGraceful Shutdown用のスクリプトを実行 Process End #!/bin/bash

    echo 0 > /app/.health sleep 28 PID=$(cat /run/nginx.pid) nginx -s quit while [ -d /proc/$PID ]; do sleep 0.1 done ... shutdown.sh プロセス停止確認 HealthCheck ステータス更新 リクエスト受付停止 (Endpoint削除 + LBサービスアウト) Nginxプロセス停止 APP Terminate APP Running APP Running リクエスト停止 サービスアウト
  18. 34.

    34 LivenessProbe & ReadinessProbe Fail APP Running APP Running APP

    Running LivenessProbe: Failed APP Running APP Terminate APP Running ReadinessProbe: Failed ReadinessProbe LivenessProbe
  19. 35.

    35 The Gotchas of Zero-Downtime Traffic /w Kubernetes - Leigh

    Capili, Weaveworks Zero-Downtimeでの(Web)サービスの更新を達成するために必要なことが 分かりやすくまとまっています。 セッション情報: https://kccncna19.sched.com/event/Uads/the-gotchas-of-zero-downtime-traffic-w-kubernetes-leigh-capili-weaveworks スライド: https://static.sched.com/hosted_files/kccncna19/f7/The%20Gotchas%20of%20Zero-Downtime%20Traffic.pdf Youtube: https://www.youtube.com/watch?v=0o5C12kzEDI Appendix)KubeConNA2019での参考セッション
  20. 36.

    36 HealthCheck @ Colopl livenessProbe: httpGet: path: /heartbeat.php port: 80

    initialDelaySeconds: 60 periodSeconds: 5 successThreshold: 1 failureThreshold: 5 timeoutSeconds: 20 readinessProbe: httpGet: path: /healthcheck.php port: 80 initialDelaySeconds: 60 periodSeconds: 3 successThreshold: 2 failureThreshold: 3 timeoutSeconds: 2 <?php // このファイルが時間内に実行されなかったら // サーバーが再起動される LivenessProbe: heartbeat.php ReadinessProbe: healthcheck.php <?php const HEALTHCHECK = '../app.health'; /** .health ファイルをチェックして状態を確認する * 1: 正常動作 */ 0: LBから外す if (intval(@file_get_contents(HEALTHCHECK)) === 0) { header('HTTP/1.1 404 Not Found'); return; }
  21. 38.

    38 アプリケーションの設定情報は、アプリケーションと分離して外部から注入できる ようにします。 参考: The TWELVE-FACTOR-APP Config https://12factor.net/config Kubernetes上でアプリケーションのConfigを設定する方法として、 ・ConfigMap

    ・Secret の二つの方法があります。 基本的な考えとして、 設定ファイルや環境変数 ⇨ ConfigMap 秘密情報、秘密情報を含んだ環境変数 ⇨ Secret に含めて、Podにマウントします。 設定ファイルや環境変数を外部から注入し、 CodeBaseを変更することなく、 アプリの挙動を変更できます。 Config Injection APP APP DB_URL: AAA DB_URL: BBB DEV PROD AAA BBB
  22. 39.

    39 Secret Management Infrastructure as Codeで設定方法を管理する際に特に重要になるのが、 Secretの管理です。 Secret Resourceは文字列を単純にBase64で エンコードします。よりセキュアに管理するには

    Kubernetes以外の仕組みが必要です。 ソリューション例 ・Sealed Secret ・kubesec ・Vault ・Berglas(GKEの場合) apiVersion: v1 kind: Secret metadata: name: database_secret data: PASS: cGFzc3dvcmQ= Secret.yaml $ echo cGFzc3dvcmQ= | base64 --decode password ⚡ すぐにデコードできてしまう ⚡
  23. 40.

    40 Secret Management @ Colopl GCPのSercret管理ツールであるBerglasとAdmission Webhook(Mutating, Validating) を利用した、透過的なSecret管理を導入中です。 apiVersion:

    v1 kind: Secret metadata: name: database_secret data: PASS: berglas://.../pass Mutating Webhook Server Validating Webhook Server Key Management Service Secret GCS Secret.yaml ① kubectl apply -f Secret.yaml ② Admission Webhook ③ Mutating ⑤ Validating (Error Check) ④ Decode マニフェスト上にはBerglasへの リファレンスだけ書くため、セキュア
  24. 43.

    43 Kubernetesでノードのメンテナンスを行う時は、 kubectl drain を使います。 kubectl drain を実行すると、そのノードはスケジュール対象外になります。 またノード上のPodを終了して、別のNodeにスケジューリングさせます。 その際、PodDisruptionBudget

    Resourceを設定することで、リクエスト受付可 能なPodが0にならないようにします。 Drain & PodDisruptionBudget Node Old Node New Node Old Node New kubectl drain Not Ready Ready Ready Not Ready Ready Ready kind: PodDisruptionBudget ... spec: maxUnavailable: 1 selector: matchLabels: ... 利用可能なPodの最小数 or 停止可能なPodの最大数 PodDisruptionBudgetで次のSpecを定義
  25. 44.

    44 Handling Risky Business: Cluster Upgrades - Puneet Pruthi, Lyft

    LyftでのKubernetesクラスタを自動更新する仕組みを構築した話です セッション情報: https://kccncna19.sched.com/event/UaYz/handling-risky-business-cluster-upgrades-puneet-pruthi-lyft スライド: https://static.sched.com/hosted_files/kccncna19/a0/Handling%20Cluster%20Upgrades%20-%20K8srotator.pdf Youtube: https://www.youtube.com/watch?v=Z_2KQP-BMUE Appendix)KubeConNA2019での参考セッション
  26. 48.

    48 Requests apiVersion: v1 kind: Pod … spec: … resources:

    requests: cpu: 100m memory: 1Gi limits: cpu: 1000m memory: 2Gi 2Gi 1Gi 1Gi 1Gi 2Gi 1Gi 2Gi 2Gi 3Gi 2Gi 1Gi 2Gi Requestsの値を元に、System Resourceが充分なNodeにPodはAssignされます。 実際のResource利用量に関係なく、Requestsの値でNodeにAssignされるため、使用量を 計測した上での適切な設定が必要です(Schedulingも考慮する)。 Assign 1Gi requests.memory
  27. 49.

    49 Limits & Eviction 2Gi 1Gi 4Gi 1.5Gi Node Capacity

    実際の使用量 (実行中Pod: 3) Capacity以上にResourceを消費 優先度が低く、Resource消費量の高いPod からEvictしていく = QoSが低く、Resource消費量の高いPod からEvictしていく LimitsはPodが使用できるResourceの上限ですが、スケジューリングの際に Limitsの値は考慮されません。 そのため、実際のPodの使用量がNodeが提供しているResource量を上回ることが あります。Node Capacityを超えてしまうと、KubernetesはPodを強制的にEvict (退避)します。 Evictionが発生するとResourceを増やす(Podを減らす・Nodeを増やす)しか 回避方法がありません。
  28. 50.

    50 QoS Class Evictionの際にどのPodから退避するかを決定する時に考慮されるのがQoS Classです。 重要なPodほどEvictionされないように、QoSを高く設定する必要があります。 apiVersion: v1 kind: Pod

    … spec: … resources: {} apiVersion: v1 kind: Pod … spec: ... requests: cpu: 100m memory: 1Gi limits: cpu: 1000m memory: 2Gi apiVersion: v1 kind: Pod … spec: ... requests: cpu: 1000m memory: 2Gi limits: cpu: 1000m memory: 2Gi Resources未設定 RequestsとLimits不一致 RequestsとLimits一致 QoS Class: QoS Class: QoS Class: BestEffort Burstable Guranteed 優先度 低 高
  29. 54.

    54 PriorityClassによる優先度付けの例 参考: Pod Priority and Preemption https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/ Node APP

    APP APP APP 同じ優先度 システム上重要なPodをAssignしようとしても、 Nodeが既に空いていない可能性がある Pending Node APP APP APP 優先度が高 高 低 低 低 優先度が高いPriorityClassをPodに指定すること で、Scheduleが優先される apiVersion: ... kind: PriorityClass metadata: name: high-priority value: 1000000 globalDefault: false description: "..." PriorityClass ※ PriorityClassの設定に伴うPreemptionには注意 https://grafana.com/blog/2019/07/24/how-a-production-outage-was-caused-using-kubernetes-pod-priorities/
  30. 56.

    56 GKEのNode PoolとTaints / Tolerationsを組み合わせて、WorkloadをNodePool単 位で分割しています。また、システムで重要なPodには優先度の高いPriorityClass を付けて、優先的にスケジューリングされるようにしています。 Scheduling @ Colopl

    Kubernetes cluster backend pool ZoneA ZoneB Instance Group label: back taint: back Instance Group label: back taint: back app pool ZoneA ZoneB Instance Group label: app taint: app Instance Group label: app taint: app prometheus pool ZoneA ZoneB Instance Group label: prom taint: prom Instance Group label: prom taint: prom system pool ZoneA ZoneB Instance Group label: system taint: system Instance Group label: system taint: system
  31. 62.

    62 Kubernetesは標準でSecurityやAuthentication(認証) / Authorization(認可)の 機能を持っています。言うまでもなく、これらを適切に設定することが重要です。 Kubernetesで設定可能な機能として、次のものがあります。 ・RBAC(Role-based access control) ・PodSecurityPolicy

    (Admission Control) ・Pod Security Context ・NetworkPolicy ・Audit Logging ※Clusterのセキュリティ担保 / 証明書の管理 / ContainerRuntimeなどもSecurityに関係してきますが時間の関係で割愛 Security 最低限どうセキュリティを担保するか、を考える時には、次の記事が参考になります 参考: 9 Kubernetes Security Best Practices Everyone Must Follow https://www.cncf.io/blog/2019/01/14/9-kubernetes-security-best-practices-everyone-must-follow/
  32. 63.

    63 Kubernetesはシステムユーザーを含めた全ての権限管理にRBACを利用しています Authorization by RBAC 参考: Introduction to Open Policy

    Agent https://speakerdeck.com/ken5scal/introduction-to-open-policy-agent DeveloperA ServiceAcount RoleBinding Role Developer Role × RBACサンプル DeveloperやAdminなどといったRoleを用意しておき、 ServiceAcountにRoleを紐付ける(RoleBinding) Role単位で権限を考えることになりますが、組織の実態にそぐわない場合もあります そうした場合はOpen Policy Agentなどの別の仕組みが必要になるかもしれません 参考: Open Policy Agent https://www.openpolicyagent.org/ CNCF Incubating Project
  33. 64.

    64 OPA Introduction & Community Update セッション情報: https://kccncna19.sched.com/event/Uahw/opa-introduction-community-update-rita-zhang-microsoft-patrick-east-styra OPA Deep

    Dive セッション情報: https://kccncna19.sched.com/event/Uafr/opa-deep-dive-tim-hinrichs-torin-sandall-styra Kubernetes Policy Enforcement Using OPA At Goldman Sachs セッション情報: https://kccncna19.sched.com/event/UaaX/kubernetes-policy-enforcement-using-opa-at-goldman-sachs-miguel-uzcategui-g oldman-sachs-tim-hinrichs-styra Appendix)KubeConNA2019での参考セッション
  34. 69.

    69 Evolving the Kubernetes Ingress APIs to GA and Beyond

    - Christopher M Luciano, IBM & Bowei Du, Google Ingress v1 GAに向けた更新の話と、Ingress v2のAPI Resource構想についての セッションとして必見です セッション情報: https://kccncna19.sched.com/event/UaYG/evolving-the-kubernetes-ingress-apis-to-ga-and-beyond-christopher-m-luciano-i bm-bowei-du-google スライド: https://static.sched.com/hosted_files/kccncna19/a5/Kubecon%20San%20Diego%202019%20-%20Evolving%20the%20Kuber netes%20Ingress%20APIs%20to%20GA%20and%20Beyond%20%5BPUBLIC%5D.pdf Youtube: https://www.youtube.com/watch?v=cduG0FrjdJA Appendix)KubeConNA2019での参考セッション
  35. 70.

    70 Player versus Player(PvP)要素のあるMultiPlayer Gameでは、PvP Clusterを用意しま す。そのため、Cluster間の疎通やCluster自体の疎通などを複合的に構築しています。 Multiple Player GameServer

    @ Colopl Internal LB APP APP APP APP Game Server Game Server Game Server APP Cluster PvP Cluster ①API Call ②Get GameServer Info (IP and Port) ③Connect to GameServer Client(Smart Phone)
  36. 73.

    73 Tuning / Garbage Collectionはなぜ必要? $ docker images REPOSITORY TAG

    <none> dev1-20191001 <none> dev1-20191001 …… log log log Nodeの性能アップ 溜まっていくログファイル... 溜まっていくコンテナイメージ... 溜まっていくイメージレイヤー... kernel Docker Registry
  37. 74.

    74 Tuning / Garbage Collection @ Colopl $ docker image

    prune -a -f deleted: sha256:d0bddce440f93 deleted: sha256:ec0659a3a34fa deleted: sha256:6fa14e84825ab ... log Nodeの性能アップ ログローテート レジストリの掃除 イメージレイヤーの掃除 kernel sysctl Alpine Cloud SDK Container Registry delete DaemonSetでNodeのTuning & Garbage Collection
  38. 77.

    77 Operatorは、Kubernetesの拡張機能を利用して、アプリケーションに必要な運用を コード化し、宣言的なAPIとして利用できるようにしたものです。 Stateful Application with Operator apiVersion: example.com/v1alpha1 kind:

    Cluster metadata: name: example-cluster spec: members: 5 apiVersion: example.com/v1alpha1 kind: Backup metadata: name: example-backup spec: schedule: '*/30 * * * *' ... Custom Resourceのイメージ
  39. 78.

    78 コロプラではKubernetes上のミドルウェアに、Stateful Applicationを利用しています。 ゲームの要件に合わせて、KVSやメッセージングキュー・RDBMS(MySQL)などの Stateful ApplicationをKubernetes上で管理しています。 Stateful Application @ Colopl

    ゲームのマスターデータ MySQL Operator Disk Provision Backup / Restore ※Coloplで自作したOperator Operatorでもそれ以外でも、なんらかの仕組みや工夫・考慮が必要になります。 Garbage Collection
  40. 79.
  41. 80.

    80 Production Readyに必要なこと まとめ(1/2) 1. CI/CDを整備する 2. マニフェスト管理の戦略を立てる 3. Observabilityを担保する

    4. 初期処理でコストの高い処理を事前に行う 5. シグナルハンドル/preStopを使ってGraceful Shutdown 6. HealthCheckで自己回復性を高める 7. Configは外部注入できる形にして、Secretはセキュアに管理 8. zero-downtimeを実現するメンテナンス戦略を立てる
  42. 81.

    81 Production Readyに必要なこと まとめ(2/2) 9. リソース管理をして、ノイジーネイバーを回避する 10. Podに優先度をつける・Workloadを分割する 11. HPAとCAでオートスケーリングのメリットを最大化する

    12. RBACの権限管理で足りない部分は、別の仕組みで補う 13. 外部通信(L7)にはIngressを使う 14. WorkerNodeをチューニング・ガベージコレクション 15. (ステートフルなものがある場合は)仕組みを考える
  43. 83.
  44. 85.

    85 Conntrack Table Podへのルーティングの実態はiptablesの書き換えです。その際、Kernelモジュール であるconntrack tableのエントリとしてトラッキングされます。 ノードあたりのWorkload(Pod)が多いと、conntrack tableが枯渇してパケットが Kernelによってドロップされることがあります。 nf_conntrack:

    table full, dropping packet conntrack枯渇の問題を回避するには、次の方法があります。 ・クラスタのサイズを大きくする(ことによってNodeあたりのWorkloadを減らす) ・WorkerNodeのカーネルパラメータを調整する 参考: https://cloud.google.com/kubernetes-engine/docs/troubleshooting#intermittent_failed_connections https://www.weave.works/blog/racy-conntrack-and-dns-lookup-timeouts
  45. 86.

    86 Node Local DNS Cache kube-dnsはkube-system namespaceに存在するSystem Componentの一つですが、 Kubernetes上の全ての名前解決がkube-dnsに殺到します。つまりスパイクする場合は 対策が必要です。その対策の一つとして、Node

    Local DNS Cacheがあります。 Pod Pod Pod kube-dns kube-system Node Local DNS Cache https://kubernetes.io/docs/tasks/administer-cluster/nodelocaldns/ https://aws.amazon.com/jp/blogs/containers/eks-dns-at-scale-and-spikeiness/ Pod Pod Pod kube-dns kube-system 参考: 通常のkube-dnsによる名前解決 CoreDNS
  46. 87.

    87 数百万DAU(Daily Active User)規模の負荷では、Prometheus単体では限界が来ます。 そのため、PrometheusのスケーリングとしてVictoriaMetricsを採用しています。 Monitoring Scale with Victoria Metrics

    … 通常タイトルにおける構成 一部タイトルにおける構成 Grafana Prometheus VictoriaMetrics Cluster Mode vmselect1 vminsertM vmstorage1 vmstorageN vminsert1 vmselectP 参考: https://victoriametrics.com/