🚀 Wave Autoscale 3.2.2: SSO、Realtime Smart Sizing、Wave Diagnosis

著者: Hwansoo Kim (opens in a new tab)
日付: 2026年5月21日

TL;DR

• Realtime Smart Sizing. 推奨値が Kubernetes in-place pod resize (1.27+) または manifest patch で自動適用 — pod 再起動なし、rollout なし。VPA スタイルの hysteresis でプロダクション churn を防止。
• OIDC Single Sign-On. Web Console が Okta、Microsoft Entra ID、Google Workspace、Keycloak と連合。ローカル admin は break-glass として残り、共有パスワードを排除。
• Wave Insights を Wave Diagnosis に再構成. 同じデータ、インシデント時に SRE が実際に問う質問 — Failures / Waste / Capacity — 中心の構成。既存 URL は redirect されます。

🎯 Realtime Smart Sizing — 推奨から適用まで自動で

Kubernetes ネイティブの代替は VPA です。 VPA は従来 pod を evict して再起動することで推奨値を適用していましたが、新しい InPlaceOrRecreate update mode (K8s 1.33 beta、1.35 で in-place pod resize と共に graduate) は Wave と同じ /resize サブリソースを呼び出し、ノードが新リソースを収容できない場合は evict-and-recreate にフォールバックします。つまり最近のクラスタでは両方とも再起動を回避できる — 差別化は resize 呼び出しの上流に移動します: 推奨値がどのように選択され、いつ実際に適用され、運用者が何を見るか。Smart Sizing はすでに数リリースにわたって推奨側を駆動してきました; 3.2.2 が適用パスを周辺パイプライン (コンテナごとの buffer / min / max、VPA の priority-only 閾値が見逃す large-container drift を捕捉する 3 ガード hysteresis、Web Console の Apply History パネル) と接続します。

各ワークロード (Deployment、StatefulSet、DaemonSet、Argo Rollout、OpenShift DeploymentConfig) は 3 つの Apply Mode から 1 つを選択します:

• Off — 推奨のみ生成、ワークロードには触れない。
• In-Place Pod Resize — 実行中の pod に Kubernetes 1.27+ の /resize サブリソースを呼び出し。再起動なし、rollout なし、ダウンタイムなし。 (InPlacePodVerticalScaling feature gate; 1.33 から GA。)
• Manifest Patch — ワークロード spec を patch; 次回 rollout から新 pod が反映。どこでも安全。

自動適用は コンテナ単位の opt-in です — 明示的に有効化するまでクラスタには何も起きません。

運用ノイズを尊重する hysteresis

10 分周期で毎回微妙に異なる推奨値がそのまま適用されると churn が爆発します。Wave は次の 3 つのガードの いずれか を満たす場合のみ適用します:

10% の priority ガードは VPA Updater の --pod-update-threshold デフォルトと同じ — 業界標準のリファレンス値です。絶対値ガードは私たちの追加です — 大きなコンテナで比率は小さいが絶対変化が意味を持つケースを捕捉する安全網です。

自動適用を有効にする前に

• In-Place は pod ごとに fire-and-forget。 ノードのリソース不足で kubelet が拒否した場合、その pod はスキップされ次のサイクルで再試行します。確実な再スケジュールが必要なら Manifest モードを使用してください。
• Manifest モードは Argo CD auto-sync と競合。 Argo が patch を drift として戻します。Wave がリソース値の source of truth であるべきワークロードでは、Autopilot と同様に auto-sync を OFF にしてください。
• Deployment の自動適用は Autopilot 切り替え時に解除。 Autopilot が管理するワークロードのリソース決定は Autopilot のものであり、同じフィールドに 2 人の writer を置きません。

全運用ガイドは /docs/wave-sizing/realtime-smart-sizing にあります。

🔐 OIDC Single Sign-On

Kubernetes はダッシュボード認証を解決しません。 コンソール系ツールは認証なしで配布するか、kubectl proxy + kubeconfig に依存するか、単一の共有 admin アカウントを使用するかです。どれもチーム単位のコンプライアンスレビューを通りません。Wave Autoscale の Web Console には単一共有 admin の問題がありました; 3.2.2 がこれを解決します。

• 標準ベースの OIDC. Okta、Microsoft Entra ID (Azure AD)、Google Workspace、Keycloak などの OIDC プロバイダーと動作。Authorization Code with PKCE、設定可能な email claim、オプションの verified-email 強制。
• Stateless. OIDC の state、nonce、PKCE verifier は単一の AES-256-GCM 暗号化クッキーで運ばれます。外部セッションストアなし、Redis なし。
• 事前プロビジョニング. 管理者が auth_source = sso でユーザー行を作成し、既存のロール (Viewer / Operator / Manager / Admin) のいずれかを付与。最初の IdP ログイン時に email 一致で行にバインド。
• ローカル admin は break-glass として保持. ログイン画面のトグルで既存アカウントを使用可能 — IdP 障害がクラスタアクセスを遮断しません。

セットアップは /docs/administration/sso-setup に最後まで文書化されています — env var 表、claims mapping、IdP 別の落とし穴 (Entra ID 個人アカウント、Keycloak の preferred_username immutability)、トラブルシューティングまで。最初の IdP セットアップにおよそ 10 分を見込んでください。

🔍 Wave Insights → Wave Diagnosis

「このワークロードがなぜ今壊れたのか」に対する Kubernetes ネイティブの答えは kubectl describe、kubectl logs、そしてダッシュボードの連鎖です。 コンソールはその次に開く 3 つ目のタブで、運用者はすでに何を探しているか分かっています。Forecasting フレーム — 「何が壊れる可能性があるか」 — はそのワークフローの邪魔になります。

3.2.2 は領域を 3 つの bucket に再構成し、それぞれ 1 つの質問に答えるようにします:

各ページは質問で始まり、severity 別の色付き verdict が答えを先に示します。基盤テーブル、チャート、メトリクス収集はそのままです。

既存リンクは?

Diagnosis のドキュメントは /docs/wave-diagnosis/* 配下にあります。既存のドキュメント URL は 301 redirect で動作し続けます — ブックマーク、Slack スレッド、検索エンジンの以前の構造項目は壊れません。sub-grouping (Reliability / Performance / Cost Efficiency) もコンソールに合わせて Failures / Waste / Capacity に置き換えられます。API パスと query key はそのままです。