Closed7
KubeCon + CloudNativeCon Europe 2023 視聴メモ
YouTubeで動画が公開された。
Hazardous Defaults: Managing Cardinality and Performance for Your Logging Stack
- Grafana Lokiのパフォーマンス改善に関する話
- Lokiで
Maximum active stream limit exceeded
が発生してログが閲覧できなくなった。この場合、ラベルやラベルの値を減らすか、管理者に上限を引き上げてもらう必要がある。 - まずはIndexes, Cardinality, Active Streams, Chunksについて理解しよう。
- Lokiはログのすべてのテキストをインデックス化してるわけじゃなく、ラベルでインデックス化している。パフォーマンスやメモリの効率のため。
- カーディナリティは、グループ内のユニークなエレメントの数
- Lokiに送信される同じインデックスのログをActive Streamsと呼ぶ
- Chunkはログをストレージに保存するブロックの単位
- 解決方法
- app, cluster, pod, filenameのラベルがある。カーディナリティの高いpodとfilenameをラベルに含めるのをやめた。
- PromtailではLokiにログを送信する前にtransformできる。replaceアクションを使って、ログのcontentにpodとfilenameを含めるようにした。
- その結果streams数は1/100になり、検索のパフォーマンスは40倍はやくなった。
Unlocking Argo CD’s Hidden Tools for Chaos Engineering - Featuring VCluster and More
- Argo CDの便利ツールの紹介
- Argo CDではクラスタ数やアプリケーション数が増えると、reconcileが遅くなったり、テンプレートのレンダリングが遅くなったり、Web UIのレスポンスが悪くなったりする。そのようなパフォーマンス問題を再現するのに便利なツールが用意されている。
- Gen Resources
- https://github.com/argoproj/argo-cd/tree/master/hack/gen-resources
- cluster, application, projectなどのリソースを大量に作ってくれるツール
- clusterをつくるためにvclusterをつかっている
On the Hunt for Etcd Data Inconsistencies
- etcdにおけるデータ不整合問題にたいする取り組みの話。
- etcdはKubernetesやその上で動くアプリケーションすべての礎となっている。なので、etcdでちょっとでもデータ不整合が起きると、nodeのステータスがready not readyでフラップしたり、apiserverのリクエストがたまに失敗したり、webhookがタイムアウトしたり、認証が失敗したりなど、重大な問題が起きてしまう。
- これまでは、failure injectionを使ってfunctional testをおこなっていたが、テストがflakyだし、テストの開発者がいなくなったのでメンテもできない。Jepsenは、Closureで書かれてるのでメンテが難しく、CIで動かすことも難しい。また、一度発生した問題を再現するテストを書くことが難しい。
- そこでモデルベーステストを導入した。OperationHistoryを与えるとetcdの理想の振る舞いを返してくれるモデルを作成した。
- 本物のetcdにFailure Injectionとトラフィックを与え、その結果得られた振る舞いと、モデルから得られた振る舞いを比較する。
Failure Injectionについては過去にブログに書いたのでこちらも参考に。
How to Develop a Robust Operator for Day-2 (Lesson Learned on KubeVirt/HCO)
- Hyperconverged Cluster Operator(HCO)の開発で得られたロバストなオペレーターを開発するための知見。
- HCOというのはオペレーターのためのオペレーター。HCOのカスタムリソースがシングルエントリーポイントとなる。つまり、最初にHCOのリソースを作成すれば、ノードをセットアップしたり、KubeVirtやネットワークなど様々なオペレーターを自動でデプロイしてくれる。
- Bad Practice
- Annotationの乱用を避けよう
- Best Practice
- Feature gatesを使おう
- DefaultingやValidatingを使いこなす
- 互換性について。互換性がない場合は、新しいAPI Versionを作成し、conversionやdepricationの機能を提供する。
- スケールさせるための注意点。イベントをフィルタリングしてreconcile回数を減らしたり、キャッシュを活用したり、statusはreconcile内で最後の1回だけ更新するなど。
- HCOにおけるアップグレード戦略
- ノードのOS、KubeVirtのコントロールプレーン、ワークロード、ゲストOSと順に更新していく
- PDBに引っかかったらアラートをあげてくれる
- テストとオブザーバビリティが大事
Using OpenTelemetry’s Exponential Histograms in Prometheus
- OpenTelemetryのExponential HistgramsとPrometheusのNative Histgramの話
- 通常のヒストグラムは、バケットの範囲を表す値とその範囲内のカウント数を保持している。通常のヒストグラムは事前にバケットのレイアウトを決めておく必要があり、実データがうまくバケットに当てはまらなかったときに、複数のバケットに同じ値が入ることになってしまう。そうすると分析の役に立たなかったりするし、保存するデータ量も無駄に大きくなってしまう。
- OpenTelemetryのExponential Histogram(PrometheusではNative Histgoramと呼ばれている)
- バケットの範囲はscaleファクターに応じて指数関数的な計算で決まる。
- このscaleを小さくすれば解像度が高くなり、大きくすれば表現できる範囲が広くなる。
- バケットを何分割するかをパラメータとして与えれば、実際に得られたデータから最適なscaleが決定される。
- ストレージに保存する際には、scaleの値と、隣り合うバケット同士の差分の値を保持するので、普通のヒストグラムと比べると保持するデータが少なくてすむ。
- OpenTelemetryとPrometheusでは、パラメータの名前、インデックス、エンコーディング方法が異なるので、そのマッピング方法について紹介している。
Updates and Best-Practices in Kubebuilder and Controller-Tools
- KubebuilderとController-Toolsの最新情報
- deploy-imageプラグイン
- ベストプラクティスに従ったカスタムコントローラーの実装のひな形を生成してくれるプラグイン
- 環境変数からイメージ名を持ってきたりfinalizerやstatusの処理など、コントローラーを実装するときに書きがちな処理が生成される。テストも生成してくれる。
- Grafanaプラグイン
- Grafana Dashboardを自動生成してくれるプラグイン
- コントローラーのCPUとメモリの使用量、reconcileの回数、エラー数、ワークキューの状況などを見ることのできるダッシュボード。
- さらにカスタムメトリクスのダッシュボードを生成することもできる。
- Phase2 Plugin
- KubebuilderではこれまでプラグインはGoで書く必要があり、Kubebuilderのバイナリと一緒にビルドしなければならなかった。Phase2プラグインで外部プラグインが使えるようになった。他の言語で書いても良い。
- Kubebuilderとplugin間はjsonでやりとりする。Kubebuilderが受け取ったjsonをもとにファイルシステムに書き出すという仕組み
- 特定のディレクトリから、名前とバージョンの一致するディレクトリを探し、その下にある実行可能ファイルをプラグインとして実行する
- controller-toolsのCustom Generator
- 任意のmarkerを追加して、そのジェネレーターを実装することができる。Goで書く。(詳しい説明はなし)
このスクラップは2ヶ月前にクローズされました