Getting Started with Kubernetes Observability

Transcript

1. ç
   Kubernetes Observability入門
   Observability Conference 2022
   @yosshi_
   

   View Slide

2. ● 吉村 翔太
   ● ゼットラボ株式会社 ソフトウェアエンジニア
   ● 経歴
   SIer 6年、通信事業者のR&D 2年 etc
   ● Kurbernetes 、Prometheus　 etc
   ● 登壇 CNDT “Kubernetes Logging入門” etc
   ● コミュニティ活動“Cloud Native Developers JP”
   “Prometheus Meetup Tokyo”
   　　　　　　　　　
   @yosshi_
   自己紹介
   

   View Slide

3. 本日のゴール
   • Observabilityが何かわかる
   – Observabilityがあるとはどういう状態なのかイメージが持てるようになる
   • 5つのSignalの収集方法と使い方がわかる
   – KubernetesでMetricsやLogsを収集して使えるようになる
   – Traces、Profiles、Dumpsについてどういうものかイメージを持てるようになる
   

   View Slide

4. What is Observability?（1/2）
   参考 : glossary.cncf.io
   < https://glossary.cncf.io/observability/ >
   CNCFの用語集には上記のように記載されている
   

   View Slide

5. What is Observability?（2/2）
   参考 : glossary.cncf.io
   < https://glossary.cncf.io/observability/ >
   読みやすいようにGoogle翻訳にかけてみますが、このままでは抽象的で具体的に何をしていいか分からない
   

   View Slide

6. TAGとWhitepaper
   • CNCF Technical Advisory Groups (TAG)
   – 特定のテーマ毎に、実用的な情報や教育コンテンツを提供するグループ
   – 特定のベンダーやプラットフォームに依存しないアウトプットすることを定めている
   – Observabilityの他にも、Network、Security、Storage、Runtime などが存在する
   参考 : < https://github.com/cncf >
   

   View Slide

7. Observability Whitepaper とは
   参考 : Observability Whitepaper
   < https://github.com/cncf/tag-observability/blob/main/whitepaper.md >
   This paper aims to get you quickly started with different kinds of
   observability you might need to work within the cloud-native world.
   既に取り組んでいる企業で得た知見をもとに、
   各Signalsの収集方法と使い方がまとめられています
   • Observabilityに取り組めるようになるためのドキュメント
   

   View Slide

8. ● HARTMANN, Richard. Talk given at Fosdem (Brussels), Feb 2019.
   < https://archive.fosdem.org/2019/schedule/event/on_observability_2019/ >
   ● SRIDHARAN, Cindy. Distributed Systems Observability. Chapter 04, The Three Pillars of Observability. 2018
   < https://www.oreilly.com/library/view/distributed-systems-observability/9781492033431/ch04.html. >
   ● BEYER, Betsy; JONES, Chris; MURPHY, Niall; PETOFF, Jennifer. Site Reliability Engineering. O'Reilly
   Media, 2016.
   < https://sre.google/sre-book/table-of-contents/ >
   ● BEYER, Betsy; MURPHY, Niall; RENSIN, David; KAWAHARA, Kent; THORNE, Stephen. The Site Reliability
   Workbook. O'Reilly Media, 2018
   < https://sre.google/workbook/table-of-contents/ >
   ● SRIDHARAN, Cindy. Monitoring and Observability. Sep 5, 2017
   < https://copyconstruct.medium.com/monitoring-and-observability-8417d1952e1c >
   ● MCCARTHY, Kate; FONG-JONES, Liz; FISHER, Danyel; MAHON, Deirdre; PERKINS, Rachel. Observability
   Maturity: Community Research Findings Q1, 2020.
   < https://www.honeycomb.io/wp-content/uploads/2020/04/observability-maturity-report-4-3-2020-1-1.pdf >
   ● Kalman R. E., On the General Theory of Control Systems, London 1961.
   < https://www.sciencedirect.com/science/article/pii/S1474667017700948?via%3Dihub >
   60年前に書かれたこの論文に記載がある
   Observabilityとは 〜参考資料〜
   

   View Slide

9. 1960年に執筆された制御工学の論文
   Section 6 からObservability について記載されてます
   Observabilityはここ数年で
   できた考え方ではなく60年前からある
   

   View Slide

10. Controller Plant
    (制御対象)
    Command
    (目標値)
    Disturbance (外乱)
    in out
    Feedback
    Closed-loop diagram (閉ループ制御)
    開ループ制御と閉ループ制御の２つのモデル
    Controller Plant
    (制御対象)
    Command
    (目標値)
    Disturbance (外乱)
    in out
    Open-loop diagram (開ループ制御)
    20度の暖風を出してと命令したらエアコンが20度の暖風を出すモデル
    室温を20度にしてと命令したらエアコンが自動で室温を保ってくれるモデル
    

    View Slide

11. Observabilityを満たすとは？
    Controller Plant
    (制御対象)
    Command
    (目標値)
    Disturbance (外乱)
    in out
    Feedback
    Closed-loop diagram (閉ループ制御)
    • 閉ループ制御が実現できている
    Controllabilityがある(可制御)
    • 閉ループ制御を実施するのに必要な十分な in/out(測定対象) の情報を取得できている
    Observabilityがある(可観測)
    説明をわかりやすくするために
    ここはぼかしてます
    

    View Slide

12. KubernetesのHPAで例えてみると
    • CPU使用率を元にサービスに必要なPod数を制御できている状態 (閉ループ制御が成立)
    – Controllabilityがある
    – Observabilityがある
    「Observability」は「Controllability」を実現するための大事な概念という位置付け
    この説明を聞いても正直Observabilityで何をしていいかわからないし、Controllabilityのあるシステムを作
    るなんて夢のまた夢という人が大半だと思います
    • CPU使用率だけでサービスに必要なPod数を制御できていない状態 (閉ループ制御が不成立)
    – Controllabilityがない
    – Observabilityは不明
    – CPU使用率だけでは入力値が足りていない？ Controllerの処理が適切でない？
    

    View Slide

13. Observability Signals
    • Metrics
    • Logs
    • Traces
    – 分散トレーシングの話
    • Profiles
    – 主にApplication profilesの話
    • Dumps
    – core dumpの話
    Whitepaperでは以下の5つのSignals(測定対象)とその使い方が記載されています
    Whitepaperの内容だけでは
    Kubernetesの時にどうすればいいか分からないので
    以降のページで説明していきます
    現在、5種類ですが今後増えていく可能性があります
    

    View Slide

14. Three pillars(三本の柱) Primary Signals
    We like to think of them as the "primary signals" instead of "three pillars" for two reasons
    • 今はPrimary Signalsと呼びます
    – Three pillars は 2019年頃に
    KubeConのKeynoteなどで使われていました
    • 理由1
    – 柱だと3つ全て揃ってないとダメなイメージがあるが
    用途によっては1つだけで大丈夫なケースもある
    • 理由2
    – ProfilesやDumpsなどが対象から漏れることが多
    い
    

    View Slide

15. Kubernetes Metrics 入門
    

    View Slide

16. Vertical Pod
    Autoscaler
    (Autoscaling)
    Horizontal Pod
    Autoscaler
    (Autoscaling)
    Receiver
    (Slack, PagerDuty etc)
    Kubernetes API
    Prometheus adapter
    (Metrics APIs)
    Alertmanager
    (Alert)
    Grafana
    (Dashboard)
    Prometheusを使用した際のMetricsの全体図
    Prometheus
    (Collect,Store,Query)
    kube state metrics
    Control Plane
    Kubelet
    (cAdvisor)
    Node exporter
    Applications
    収集対象
    利用方法
    

    View Slide

17. OpenMetricsとは？
    # HELP http_requests_total The total number of HTTP requests.
    # TYPE http_requests_total counter
    http_requests_total{method="post",code="200"} 1027 1395066363000
    http_requests_total{method="post",code="400"} 3 1395066363000
    metrics name value
    label
    • OpenMetrics
    – 右図のような形式のデータを収集する
    参考 : Prometheus and OpenMetrics, with Richard Hartmann
    < https://kubernetespodcast.com/episode/037-prometheus-and-openmetrics/ >
    ADAM GLICK: Given all the work that you're doing with Prometheus, how did that lead you into
    creating the OpenMetrics Project?
    RICHARD HARTMANN: Politics. It's really hard for other projects, and especially for other
    companies, to support something with a different name on it. Even though Prometheus itself doesn't
    have a profit motive, so we don't have to have sales or anything, it was hard for others to accept stuff
    which is named after Prometheus in their own product. And this is basically why I decided to do that.
    

    View Slide

18. Kubernetesにおける収集対象のメトリクス一覧
    • Application metrics
    – ユーザが作成するアプリケーションや、ユーザがデプロイするOSSのメトリクス
    • kube-state-metrics
    – Kubernetesのリソースオブジェクトの状態に関するメトリクス
    • Control Plane
    – API-Server、Scheduler、Controller-manager等に関するメトリクス
    • Kubelet
    – Kubernetesのノードと、コンテナに関するメトリクス(cAdvisor)
    • Node Exporter
    – ノードのCPU使用率やメモリ使用率等のメトリクス
    

    View Slide

19. メトリクスのユースケース
    • ダッシュボード
    – メトリクスを元にグラフを作って、状態を見やすくする
    • アラート
    – 異常の状態を定義して、通知するようにする
    • Horizontal / Vertical Pod Autoscaler
    – メトリクスの値を入力値としてPodの状態を制御する
    • SLI/SLO
    – メトリクスを用いてサービスの理想の状態を定義する考え方の一つ
    

    View Slide

20. Kubernetes Logging 入門
    

    View Slide

21. promtail
    (Log agent)
    Alertmanager
    (Alert)
    Grafana Loki
    (Log Backend)
    Receiver
    (Slack, PagerDuty etc)
    Grafana
    (Dashboard)
    Grafana Lokiを使用した際のLogsの全体図
    Event
    (Container logs)
    Audit
    (Audit logs)
    Kubernetes
    Component
    (Container/Journal logs)
    Applications
    (Container logs)
    収集対象
    利用方法
    

    View Slide

22. Kubernetes のログ一覧
    • Application Logs
    – ユーザが作成するアプリケーションや、ユーザがデプロイするOSSのログ
    • Event Logs
    – Kubernetesのイベント(オブジェクトの状態が遷移)に関するログ
    • Audit Logs
    – Kubernetesの監査ログ
    • Kubernetes Component Logs
    – API-Server、Scheduler、Controller-manager、Kubelet等に関するログ
    

    View Slide

23. Application Logsと”kubectl logs”で見れるまで
    API Server
    kubectl logs Kubelet ログファイル
    コンテナ
    Container
    runtime
    Control plane Node Worker Node
    stdout/stderr
    “/var/logs/pods”配下に格納されている
    • Application Logs
    – stdout/stderrに出力したログがContainer runtimeから出力される(Container Logs)
    ノードがローリングアップデート等で消えた時に
    どうやってログファイルを参照するか考える必要があります
    

    View Slide

24. KubernetesのLoggingのArchitecture
    • 大きく分けて３種類のアーキテクチャがある
    Application forwarding
    参考< https://kubernetes.io/docs/concepts/cluster-administration/logging/>
    Sidecar processing
    Node agent forwarding
    

    View Slide

25. Application forwarding
    • 方法
    – アプリケーションが直接、ログバックエンドにログを送る
    • 特徴
    – Kubernetesに対する知識等は必要なく、アプリケーション単体で実現可能
    • 懸念点
    – アプリケーション毎に対応が必要
    コンテナを多数Deployする場合
    ログにホスト名が入ってないと追跡できない
    

    View Slide

26. Sidecar processing
    • 方法
    – Fluentdなどを使って、アプリケーションのログをログバックエンドに出力する
    • 特徴
    – Pod単位で実現可能
    – アプリケーションからログを送る部分の機能をSidecarに持たせられる
    • 懸念点
    – Pod単位で対応が必要
    

    View Slide

27. Node agent forwarding
    • 方法
    – 各ノードにDeamonSetでFluentdなどをDeployしてログを収集する
    • 特徴
    – Container Logsの実体がどこにあるか理解する必要がある
    – アプリケーション側で何もしていなくてもログが収集できる
    • 懸念点
    – コンテナがstdout/stderrにログを出力していないと
    収集できない
    

    View Slide

28. Event Logs (1/2)
    $ kubectl alpha events
    :
    110s Normal SuccessfulCreate ReplicaSet/kube-state-metrics-69fc8b7bb7 Created pod:
    kube-state-metrics-69fc8b7bb7-8n89q
    109s Normal Scheduled Pod/kube-state-metrics-69fc8b7bb7-8n89q Successfully assigned
    kube-system/kube-state-metrics-69fc8b7bb7-8n89q to demo-yosshi-123-w-default-a5f36c1c-ldssp
    109s Normal Started Pod/kube-state-metrics-69fc8b7bb7-8n89q Started container
    kube-state-metrics
    109s Normal Created Pod/kube-state-metrics-69fc8b7bb7-8n89q Created container
    kube-state-metrics
    109s Normal Pulled Pod/kube-state-metrics-69fc8b7bb7-8n89q Container image
    "k8s.gcr.io/kube-state-metrics-kube-state-metrics:v2.4.1" already present on machine
    • kubectl alpha events/ get events 等のコマンドで取得
    – eventが発生してから1時間以内(デフォルト値)のイベントが取得できる
    – デバック等の時に必要なログなのでeventrouterでContainer Logsに出力しておくケースが多い
    

    View Slide

29. API Server
    Control plane Node
    Event Logs (2/2)
    ログファイル
    eventrouter
    Container
    runtime
    Worker Node
    stdout/stderr
    eventrouterがeventを取得する
    • Event Logsの永続化
    – eventrouterがContainer Logsに出力してくれることで既存のログ収集の仕組みが活用できる
    参考 : eventrouter
    < https://github.com/heptiolabs/eventrouter >
    

    View Slide

30. Audit Logs
    apiVersion: audit.k8s.io/v1 # This is required.
    kind: Policy
    # Don't generate audit events for all requests in RequestReceived stage.
    omitStages:
    - "RequestReceived"
    rules:
    # Log pod changes at RequestResponse level
    - level: RequestResponse
    resources:
    - group: ""
    # Resource "pods" doesn't match requests to any subresource of pods,
    # which is consistent with the RBAC policy.
    resources: ["pods"]
    – 以下のようなaudit-policy.yamlを設定することで指定したKubernetesの操作ログを取得できる
    – LogはAPI-Serverのhostpath上に出力されるので、Logging agentで収集することで永続化可能
    

    View Slide

31. Kubernetes Component Logs
    – Control Planeが以下のような構成の場合
    Controller
    Manager
    Kubelet
    Container runtime
    API Server Scheduler
    Controle Plane Node
    Systemdで立ち上げている場合は
    Journal Logsとして出力されている
    “jounalctl -u kubelet”
    Containerで立ち上げている場合は
    Container Logsとして出力されている
    “kubectl logs”
    

    View Slide

32. Kubernetes のログ一覧
    • Application Logs
    – ユーザが作成するアプリケーションや、ユーザがデプロイするOSSのログ
    • Event Logs
    – Kubernetesのイベント(オブジェクトの状態が遷移)に関するログ
    • Audit Logs
    – Kubernetesの監査ログ
    • Kubernetes Component Logs
    – API-Server、Scheduler、Controller-manager、Kubelet等に関するログ
    

    View Slide

33. Docker と containerd のログの違い (1/4)
    • Dockerからcontainerdに変更するときは以下の3点が変わります
    – ログの出力先
    – ログフォーマット
    – ログローテーションの仕組み
    参考 : kubernetes.io
    < https://kubernetes.io/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/ >
    

    View Slide

34. Docker と containerd のログの違い (2/4)
    Kubelet ログファイル
    コンテナ
    Container
    runtime
    Worker Node
    stdout/stderr
    “/var/logs/pods”
    “/var/lib/docker/containers/”
    Kubelet ログファイル
    コンテナ
    Container
    runtime
    Worker Node
    stdout/stderr
    “/var/logs/pods”
    “/var/logs/pods”
    • ログの出力先の違い
    – Dockerは“/var/lib/docker/containers/”に出力したファイルをKubeletがシンボリックリンクで認識
    – containerdの場合は“/var/logs/pods”に出力するのでKubeletは直接参照
    

    View Slide

35. Docker と containerd のログの違い (3/4)
    • ログのフォーマットの違い
    – Docker : Dockerで設定。Kubernetesで利用する場合はjsonのケースがほとんど
    – containerd : containerdで設定。text形式。jsonではないので注意が必要
    $ tail 0.log
    {"log":"ts=2022-02-24T15:00:01.890Z caller=compact.go:518 level=info component=tsdb msg=\"write block\" mint=1645704000405
    maxt=1645711200000 ulid=01FWP3XZTPATM0DNB79VN6TZW0
    duration=1.419677358s\n","stream":"stderr","time":"2022-02-24T15:00:01.890727362Z"}
    {"log":"ts=2022-02-24T15:00:01.965Z caller=head.go:812 level=info component=tsdb msg=\"Head GC completed\"
    duration=72.466779ms\n","stream":"stderr","time":"2022-02-24T15:00:01.965877919Z"}
    $ tail 0.log
    2022-02-24T15:00:03.979528555Z stderr F ts=2022-02-24T15:00:03.979Z caller=compact.go:518 level=info component=tsdb msg="write block"
    mint=1645704000028 maxt=1645711200000 ulid=01FWP3Y1RKQEAQXM2FMTEM1AP2 duration=1.528035987s
    2022-02-24T15:00:04.057508629Z stderr F ts=2022-02-24T15:00:04.057Z caller=head.go:812 level=info component=tsdb msg="Head GC
    completed" duration=74.995023ms
    log-agentも合わせて変更しないとログが収集できなくなる
    

    View Slide

36. Docker と containerd のログの違い (4/4)
    Kubelet ログファイル
    コンテナ
    Container
    runtime
    Worker Node
    stdout/stderr
    {
    "log-driver": "json-file",
    "log-opts": {
    "max-size": "10m",
    "max-file": "3",
    }
    Kubelet ログファイル
    コンテナ
    Container
    runtime
    Worker Node
    stdout/stderr
    • ログのローテーションの違い
    – Docker : dockerで実施
    – containerd : Kubeletで実施
    apiVersion: kubelet.config.k8s.io/v1beta1
    kind: KubeletConfiguration
    :
    containerLogMaxSize: "10Mi"
    containerLogMaxFiles: "5"
    デフォルト値も異なるので切り替えの時は注意が必要
    

    View Slide

37. Kubernetes Tracing 入門
    

    View Slide

38. Applications
    OpenTelemetry
    Collector
    Jaeger
    (Trace Backend)
    Grafana Tempo
    (Trace Backend)
    Grafana
    (Dashboard)
    収集対象
    Applications
    Tracing Agent
    Library
    Grafana Tempoを使用した際のTracesの全体図
    利用方法
    ここからKubernetesのクラスタコンポーネント固有の情報がなくなってきます
    Grana Tempoだけだとわかりにくい人も
    多いと思うので、Jaegerも併記しています
    

    View Slide

39. 分散トレーシング
    参考 : jaegertracing.io
    < https://www.jaegertracing.io/docs/1.31/architecture/ >
    • Whitepaperの中のトレーシングは分散トレーシングのことになります
    – Kubernetesでは一つのリクエストが複数のpodを経由して完結するケース多くなります
    – そのため、ユニークなIDを付与してリクエストをトレースする技術になります
    

    View Slide

40. OpenTelemetryはトレーシングの技術？
    参考 : opentelemetry.io
    < https://opentelemetry.io/docs/reference/specification/logs/overview/#trace-context-in-legacy-formats >
    • TelemetryはTracesだけでなく、MetricsやLogsも含みます
    OpenTelemetryが目指す姿
    

    View Slide

41. Primary Signals の使い方
    

    View Slide

42. Primary Signals の利用イメージ
    参考 : < https://grafana.com/blog/2018/12/12/loki-prometheus-inspired-open-source-logging-for-cloud-natives/ >
    各Signals間は時刻を元に関連性を推測
    

    View Slide

43. 各Signals間を関連づける
    参考
    < https://github.com/cncf/tag-observability/blob/main/whitepaper.md >
    • ユニークなIDを付与することで関連づける機能についても議論されてます
    logとtraceに同じIDを付与する
    

    View Slide

44. Grafana Loki と Grafana Tempo での例
    参考
    < https://grafana.com/blog/2020/11/09/trace-discovery-in-grafana-tempo-using-prometheus-exemplars-loki-2.0-queries-and-more/ >
    2020-11-06T15:02:10.261121224Z stdout F level=info msg="HTTP client success" status=200 url=http://db duration=1.03636ms traceID=fb0fbe73200e474
    2020-11-06T15:02:10.014657751Z stdout F level=info msg="HTTP client success" status=200 url=http://db duration=2.116557ms traceID=2c963a78f1ee0c78
    2020-11-06T15:02:09.98055353Z stdout F level=info msg="HTTP client success" status=200 url=http://db duration=2.24091ms traceID=7efd169fbc41ff4a
    • ログにtraceIDを付与することでトレースと関連づける
    Grafana上でtraceIDを元に関連づけ
    

    View Slide

45. Kubernetes Profiles 入門
    

    View Slide

46. さまざまなProfiles
    • CPU Profilers
    • Heap Profilers
    • GPU Profilers
    • Mutex Profilers
    • IO Profilers
    • Language-specific Profilers
    ここから先はKubernetes特有の機能の紹介ではなく
    今まで使っていた技術をKubernetesの時にどう使えばいいかの話になります
    メモリリークの原因究明など、今までのやり方だけで分からない事象が起こります
    

    View Slide

47. Kubernetesにおけるコンテナの操作方法
    • コンテナを直接操作する
    – “kubectl exec”でコンテナを操作する
    – “kubectl debug”でエフェメラルコンテナを用意して操作する
    • コンテナに疎通できるようにして操作する
    – “kubectl port-forward”で接続する
    – “Service type Nodeport”等でコンテナに疎通できるようにする
    • ノードにsshして操作する
    – “kubectl get node -o wide”でノートを確認してsshする
    Kubernetes固有の部分はこの操作パターンを覚えること
    あとは今まで使ってきた技術をそのまま使っていきます
    

    View Slide

48. Kubernetes Dump 入門
    

    View Slide

49. Dump について
    • プログラムがクラッシュ時の原因を特定するためのCoredumpの話になります
    – “/proc/sys/kernerl/core_pattern”に書かれたpathにコアファイルを出力する
    – Kubernetes固有の操作方法等はない
    – コアファイルのpathをマウントしたlog-agentで収集することはできるが
    Kubernetesの情報と組合せて権限管理を行ったりすることが難しい
    Coredumpがノード単位での設定なので
    コンテナ単位で制御できず、ContainerIDが付与されてません
    ContainerでCoredumpを使いやすくするための機能提案はされて
    いますが、今のところ進展はありません
    参考 : github.com/moby
    < https://github.com/moby/moby/issues/19289 >
    

    View Slide

50. まとめ (振り返り)
    

    View Slide

51. Observability Signals
    • Metrics
    • Logs
    • Traces
    – 分散トレーシングの話
    • Profiles
    – 主にApplication profilesの話
    • Dumps
    – core dumpの話
    Whitepaperでは以下の5つのSignals(測定対象)とその使い方が記載されています
    Whitepaperの内容だけでは
    Kubernetesの時にどうすればいいか分からないので
    以降のページで説明していきます
    現在、5種類ですが今後増えていく可能性があります
    

    View Slide

52. Vertical Pod
    Autoscaler
    (Autoscaling)
    Horizontal Pod
    Autoscaler
    (Autoscaling)
    Receiver
    (Slack, PagerDuty etc)
    Kubernetes API
    Prometheus adapter
    (Metrics APIs)
    Alertmanager
    (Alert)
    Grafana
    (Dashboard)
    Prometheusを使用した際のMetricsの全体図
    Prometheus
    (Collect,Store,Query)
    kube state metrics
    Control Plane
    Kubelet
    (cAdvisor)
    Node exporter
    Applications
    収集対象
    利用方法
    

    View Slide

53. promtail
    (Log agent)
    Alertmanager
    (Alert)
    Grafana Loki
    (Log Backend)
    Receiver
    (Slack, PagerDuty etc)
    Grafana
    (Dashboard)
    Grafana Lokiを使用した際のLogsの全体図
    Event
    (Container logs)
    Audit
    (Audit logs)
    Kubernetes
    Component
    (Container/Journal logs)
    Applications
    (Container logs)
    収集対象
    利用方法
    

    View Slide

54. Applications
    OpenTelemetry
    Collector
    Jaeger
    (Trace Backend)
    Grafana Tempo
    (Trace Backend)
    Grafana
    (Dashboard)
    収集対象
    Applications
    Tracing Agent
    Library
    Grafana Tempoを使用した際のTracesの全体図
    利用方法
    ここからKubernetesのクラスタコンポーネント固有の情報がなくなってきます
    Grana Tempoだけだとわかりにくい人も
    多いと思うので、Jaegerも併記しています
    

    View Slide

55. Primary Signals の利用イメージ
    参考 : < https://grafana.com/blog/2018/12/12/loki-prometheus-inspired-open-source-logging-for-cloud-natives/ >
    

    View Slide

56. Kubernetesにおけるコンテナの操作方法
    • コンテナを直接操作する
    – “kubectl exec”でコンテナを操作する
    – “kubectl debug”でエフェメラルコンテナを用意して操作する
    • コンテナに疎通できるようにして操作する
    – “kubectl port-forward”で接続する
    – “Service type Nodeport”等でコンテナに疎通できるようにする
    • ノードにsshして操作する
    – “kubectl get node -o wide”でノートを確認してsshする
    Kubernetes固有の部分はこの操作パターンを覚えること
    あとは今まで使って生きた技術をそのまま使っていきます
    

    View Slide