Kubernetes 1.15：SIG Instrumentation 的变更内容

首先

在这里，我整理了SIG Instrumentation在Kubernetes 1.15的变更日志。

由于 SIG Instrumentation 的版本 v1.15 没有对以下主题进行任何更改，所以省略了详细说明。

• 主な変更点(1.15 What’s New)

• 既知の問題 (Known Issues)

• アップグレード時の注意点 (Urgent Upgrade Notes)

• 廃止及び削除される機能 (Deprecations and Removals)

• 注目機能 (Notable Features)

• API の変更 (API Changes)

依存関係 (Dependencies)

由于这次 SIG Instrumentation 的独立变更调查是首次，因此我们也会介绍与本次发布相关的 SIG Instrumentation 的 KEP。
根据以下 KEP 中提出的 Kubernetes Metrics Overhaul，已在 v1.14 中进行了指标修正。

• KEP Kubernetes Metrics Overhaul

• ゴール

Prometheusや他のエコシステムに合わせて一貫性のある名前と高品質のメトリクスを提供すること
メトリクスの直接的な結合を可能にするため、一貫したラベル名を提供すること

在v1.15版本中，仍然进行了单位修正等工作，并将根据SIG-Instrumentation和Prometheus的指南继续改进指标。

度量衡的改变

添加的度量

• [kube-proxy] kube-proxy がプロキシールールを適用した最後の時間を記録するメトリクスである kubeproxy_sync_proxy_rules_last_timestamp_seconds が追加されました (#74027, @squeed)

その他にも以下の kubeproxy_sync_proxy_rules_* メトリクスが追加されています
kubeproxy_sync_proxy_rules_endpoint_changes_pending
kubeproxy_sync_proxy_rules_endpoint_changes_total
kubeproxy_sync_proxy_rules_service_changes_pending
kubeproxy_sync_proxy_rules_service_changes_total

• [kubelet] process_start_time_seconds メトリクスが追加されました (#77975, @logicalhan)

これは名前の通り kubelet 自身のプロセスが起動した時間となります

• [scheduler] scheduler の queue ごとに Pending ステータスの Pod 数を記録する scheduler_pending_pods メトリクスが追加されました (#75501, @Huang-Wei)

クラスターの全体的な状態を知るために追加されました、ちなみにスケジュール済の Pod は scheduler_schedule_attempts_total{result=”scheduled”} のメトリクスで取得できます。

[kubelet] kubelet_volume_stats_* メトリクスに CSI ボリュームの情報が追加されました (#76188, @humblec)

• [kube-controller-manager, kubelet] ストレージ操作の成功と失敗のステータスを記録する storage_operation_status_count メトリクスが追加されました (#75750, @msau42)

合わせて storage_operation_duration_seconds メトリクス（Histogram）のバケット範囲が、最大50秒だったものから600秒まで拡張されています

弃用/修改的度量指标

• [kubelet] Probe メトリクスが Gauge タイプから Counter タイプに変更となったため、 メトリクス名も prober_probe_result から prober_probe_total に変更となりました (#76074, @danielqsj)

変更になったため prober_probe_result は利用できません

• [kube-apiserver] transformation_failures_total メトリクスが非推奨となり将来のリリースで削除されるため、transformation_operation_total の利用が推奨となりました。 (#70715, @immutableT)

KMS Provider の変換処理をモニタリングすることがモチベーションのようです

• [kubelet] storage_operation_duration_seconds メトリクスには潜在的な問題があったため、ボリュームのプロビジョニングと削除を含んだ volume_operation_total_seconds メトリクスが追加されました。storage_operation_duration_seconds メトリクスに変更はありませんが以下の問題を含んでいます。 (#78061, @yuxiangqian)

1. External Provisioner / Deleter によってプロビジョニング/削除されたボリュームの場合、 storage_operation_duration_seconds メトリクスに External Provisioner / Deleter の操作時間は含まれません（事実上0秒に近い数値となります）。これは volume_operation_total_seconds で修正されています。
2. プロビジョニングや削除の処理中に一時的なエラーが発生した場合、例えば deleteVolume が呼び出されている間にボリュームがまだ使用中だと storage_operation_duration_seconds メトリクスはボリュームが削除されるまで待ちません。これも volume_operation_total_seconds メトリクスで修正されています。
この変更の潜在的な影響としてアラートや SLO で使用しているメトリクスを storage_operation_duration_seconds から volume_operation_total_seconds に修正すると、以前より正確な数値で値も大きくなるため、閾値を超える可能性があります。

• [kube-apiserver] ミリ秒ではなく秒の単位になっていたため、*_admission_latencies_milliseconds_summary と *_admission_latencies_milliseconds メトリクスは、*_admission_duration_seconds と *_admission_duration_seconds_summary に変更となりました (#75279, @danielqsj)

これは命名ガイドライン違反の影響を受けました

これは SIG-Instrumentation のガイドラインではなく、Prometheus のガイドラインの must have a single unit です

• [kube-apiserver] Admission メトリクス *_admission_duration_seconds の Histogram バケットの範囲が 5ミリ秒 〜 2.5秒 の範囲に修正されました (#78608, @jpbetz)

ミリ秒から秒に修正した時、6桁ほどずれていたみたいです

[cloud-providers/azure] 不正確な Azure のメトリクスが修正されました (#77722, @andyzhangx)

其他值得注意的变化

• [metrics-server addon] 優先的に IP addresses を使ってノードへ接続するように戻しました (#76819, @serathius)

metrtics-server v0.3 で変更された機能により、IP アドレスより DNS が優先されるようになり一部のテストなどで DNS への依存が増えたので、引数の変更でもとの挙動に戻したようです。

• Pod に実行中のインスタンスがある場合、containerd や cri-o などの CRI ランタイムについては、 kubelet の Stats から以前に終了したインスタンスの Stats を表示しないように修正しました。

• この修正により Docker を利用した時の挙動と一貫性が保たれ、同じ Pod に複数インスタンスの Stats がある場合に一部のコンテナの Prometheus メトリクスが機能しなくなるという問題が修正されました (#77426, @Random-Liu)

ここで使われているインスタンスとは Pod の実体のことを指しています。またこの現象は短い期間で再作成されると同じ名前空間と名前をもつ Pod が作成され発生するようです。

So感

虽然不像v1.14那样，但v1.15中也有一些指标的添加和更改，所以最好对警报和SLO的指标进行盘点。
另外，目前来看，不仅针对Kubernetes，而且对于Prometheus的指标指南也是由审查来保护的，所以如果能在OpenMetrics等机制中讨论通过工具和规范来检测和修复问题，这将令人欣喜。