Kubernetes

はじめに Kubernetesを本番環境で運用する上で、適切なリソース管理とスケーリングは避けて通れない課題です。過剰なリソース割り当てはコストの無駄になり、不足していればパフォーマンス低下やサービス障害につながります。 本記事では、Kubernetesの自動スケーリング機能であるHorizontal Pod Autoscaler（HPA）とVertical Pod Autoscaler（VPA）について、基礎概念から本番環境での実践的な運用ノウハウまでを詳しく解説します。 HPAとVPAの違い Horizontal Pod Autoscaler（HPA） HPAは、Pod数を水平方向にスケールさせる機能です。負荷が増加するとPod数を増やし、負荷が減少するとPod数を減らします。 適用シーン： ステートレスなWebアプリケーション APIサーバー ワーカープロセス Vertical Pod Autoscaler（VPA） VPAは、個々のPodのリソース要求（CPU/メモリ）を垂直方向に調整する機能です。実際の使用状況に基づいて、より適切なリソース割り当てを推奨・適用します。 適用シーン： ステートフルなアプリケーション データベースやキャッシュサーバー バッチ処理ジョブ HPA実践ガイド 基本的なHPA設定 まずはシンプルなCPUベースのHPAから始めましょう。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 # deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: web-api namespace: production spec: replicas: 3 selector: matchLabels: app: web-api template: metadata: labels: app: web-api spec: containers: - name: web-api image: myregistry/web-api:v1.2.3 resources: requests: cpu: 200m memory: 256Mi limits: cpu: 1000m memory: 512Mi ports: - containerPort: 8080 readinessProbe: httpGet: path: /health port: 8080 initialDelaySeconds: 10 periodSeconds: 5 --- # hpa.yaml apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: web-api-hpa namespace: production spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: web-api minReplicas: 3 maxReplicas: 50 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70 - type: Resource resource: name: memory target: type: Utilization averageUtilization: 80 behavior: scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 10 periodSeconds: 60 scaleUp: stabilizationWindowSeconds: 0 policies: - type: Percent value: 100 periodSeconds: 15 - type: Pods value: 4 periodSeconds: 15 selectPolicy: Max カスタムメトリクスを使ったHPA CPUやメモリだけでなく、アプリケーション固有のメトリクスでスケーリングすることも可能です。 ...

Kyvernoで始めるKubernetes Admission Policy実践: 事故を減らすポリシー設計プレイブック Kubernetes運用で一番つらい事故は、クラスタが壊れるよりも「本来防げたはずのミスがそのまま本番へ入る」ことです。たとえば、latest タグのイメージが本番に入り再現不能になる、resources 未設定でノードが詰まる、privileged コンテナが混入する。これらは人の注意力だけに依存すると必ず再発します。 そこで有効なのが Admission Policy（入場制御）です。本記事では Kyverno を使って、現場で本当に運用できるポリシー群を段階導入する手順をまとめます。単なる「denyの例」ではなく、監査→警告→強制の移行、例外管理、CI連携まで含めて解説します。 1. なぜKyvernoなのか OPA Gatekeeper も強力ですが、Kyvernoは以下の特徴があり、初期導入が比較的スムーズです。 YAML中心で書ける（Rego学習コストを後回しにしやすい） validate / mutate / generate / verifyImages を一貫して扱える PolicyReportにより違反可視化がしやすい Pod SecurityやSupply Chain対策との相性が良い 「まずルールを回し始める」目的なら、Kyvernoは現実的な選択肢です。 2. 先に決めるべき設計原則 導入前に、以下だけは先に決めておきます。 導入フェーズ: Audit → Enforce を基本にする 責任分界: プラットフォームチームが共通ポリシー、各チームがアプリ固有例外 例外の期限: 永久例外は禁止。期限付きで必ず棚卸し 観測性: 違反数・対象Namespace・上位違反ルールをダッシュボード化 この原則なしにルールだけ増やすと、運用が破綻します。 3. 最小導入手順（30〜60分） 3.1 Kyvernoのインストール 1 2 3 4 5 6 7 8 9 helm repo add kyverno https://kyverno.github.io/kyverno/ helm repo update helm upgrade --install kyverno kyverno/kyverno \ -n kyverno --create-namespace \ --set admissionController.replicas=2 \ --set backgroundController.replicas=2 \ --set cleanupController.replicas=1 \ --set reportsController.replicas=1 本番では可用性のため、admission/backgroundは最低2レプリカ推奨です。 ...

Kubernetes環境でDBスキーマ変更を止めずに進める：ゼロダウンタイム移行の実践戦略 「カラムを追加するだけだから大丈夫」──この油断が、本番障害の入口になります。Kubernetes のように複数バージョンの Pod が同時に存在する環境では、DB スキーマ変更はアプリ変更よりも慎重に扱う必要があります。 本記事では、Expand-Contract パターンを中心に、ゼロダウンタイムを目指すための具体手順を解説します。実際の運用では、DDLの速さより「互換性のある期間をどう作るか」が勝負です。 1. なぜKubernetesでDB移行が難しいのか Kubernetesでは、ローリングアップデート中に新旧Podが混在します。つまり次の状態が同時に発生します。 新アプリは新スキーマを期待 旧アプリは旧スキーマしか知らない DBは1つしかない このとき破綻するのが「破壊的変更を先に適用する」ケースです。たとえば旧カラムを即削除すると、旧Podがエラーを連発します。 2. 基本戦略：Expand → Migrate → Contract ゼロダウンタイム移行の原則はこの3段階です。 Expand: 互換性を壊さない変更を先に入れる（新カラム追加など） Migrate: アプリを段階的に切替え、データを移行する Contract: 旧仕様を最終削除する（十分な監視後） この順序なら、どの時点でも旧新どちらのアプリも動作可能にできます。 3. 具体例：users.full_name を first_name / last_name へ分割 3.1 Expand フェーズ まず破壊的でないDDLを適用します。 1 2 ALTER TABLE users ADD COLUMN first_name text; ALTER TABLE users ADD COLUMN last_name text; この時点で旧アプリは full_name を使い続けられます。新アプリは新カラムに対応した実装を持っていても、まだ必須にしません。 3.2 アプリを「両対応」にする 書き込み時は両方へ保存（dual write）し、読み込み時は新カラム優先 + 旧カラムフォールバックにします。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 def save_user_name(user_id: str, full_name: str): first, last = split_name(full_name) db.execute( """ UPDATE users SET full_name = %s, first_name = %s, last_name = %s WHERE id = %s """, (full_name, first, last, user_id), ) def read_user_display_name(row): if row.first_name and row.last_name: return f"{row.first_name} {row.last_name}" return row.full_name この両対応期間を作るのが、ゼロダウンタイムの本質です。 ...

Kubernetesキャパシティ設計実践：HPA/VPA/Cluster Autoscalerを衝突させない運用術 Kubernetes は「自動でスケールするから安心」と思われがちですが、実運用では逆です。HPA、VPA、Cluster Autoscaler（CA）の設定が噛み合わないと、スケールアウトと再スケジューリングが衝突し、レイテンシ悪化やコスト増大を引き起こします。 本記事では、3つのオートスケーリング機構を同時運用する際の設計ポイントを、障害対応目線で整理します。 1. 役割分担を明確にする まず前提として、各コンポーネントの責務を固定します。 HPA: Pod 数を短期的に増減 VPA: Pod あたりの requests/limits を中長期で最適化 CA: ノード数を増減 この役割分担が曖昧だと、同じ問題を複数レイヤーで同時に解こうとして不安定化します。特に Web/API ワークロードでは、HPA を主軸、VPA は recommendation 中心で始めるのが安全です。 2. requests/limits が崩れていると全て失敗する HPA の CPU 指標は requests 基準で計算されます。requests が不正確だと、HPA の判断もズレます。最初にやるべきは次です。 過去 2 週間の実使用量を可視化 p95 使用量を requests の初期値に設定 limits は requests の 1.5〜2 倍で開始 極端に低い requests は「見かけの高負荷」を作り、不要スケールを誘発します。逆に高すぎる requests は CA の過剰増設を招きます。 3. HPA 指標選定の実践 CPU だけで運用すると、I/O 待ちや外部 API 待ちのボトルネックを見逃します。推奨は複合指標です。 CPU Utilization（基本） メモリ使用率（リーク監視） RPS あたりレイテンシ（SLO 接続） Queue 長（非同期処理） autoscaling/v2 では複数メトリクスを扱えるため、最初から設計しておくと後で楽です。 ...

Kubernetes障害対応ランブック実践編：15分で切り分け、60分で復旧するための現場手順 Kubernetes で障害が起きたとき、技術力より先に問われるのは「順序」です。順序が崩れると、正しいコマンドを打っていても復旧が遅れます。逆に、判断フレームが決まっていれば、難しい障害でも被害を最小化できます。 本記事では、実運用で使える障害対応ランブックを、初動 15 分・復旧 60 分を目安に具体化します。対象は EKS/GKE/AKS を含む一般的な Kubernetes 本番環境です。 1. 最初の5分：人と情報の交通整理 まずやるべきは技術調査ではなく、交通整理です。 インシデントの指揮者（IC）を1人決める ログ担当、メトリクス担当、アプリ担当を分ける Slack/Discord の専用チャンネルを作る 5分ごとの時系列ログ（タイムライン）を残す この段階で「誰が何を見ているか」が曖昧だと、同じ調査を3人で繰り返し、誰も復旧判断をしない状態になります。ICは手を動かさず、意思決定に集中するのが基本です。 2. 5〜15分：影響範囲の特定 次に「どのユーザーに、どの機能で、何%の影響があるか」を確定します。 2-1. まず全体の健康状態 1 2 3 kubectl get nodes kubectl get pods -A --field-selector=status.phase!=Running kubectl get events -A --sort-by=.lastTimestamp | tail -n 50 見るポイント: Node が NotReady になっていないか 特定 namespace だけで CrashLoopBackOff が増えていないか 直近イベントに FailedScheduling や Back-off restarting failed container がないか 2-2. SLO/SLIから影響を数値化 「遅い気がする」ではなく、以下を数値で押さえます。 ...

Kubernetesコスト最適化の実務：FinOps視点で無駄を可視化し、性能を落とさず削減する方法 Kubernetes を導入した直後は「自動で効率化される」と期待されがちですが、実際には逆です。適切な運用ルールがないと、クラウド請求は静かに膨らみ続けます。 典型例は次の通りです。 リクエスト/リミットが過大でノードが常時スカスカ 夜間トラフィック減少時も同じ台数を維持 開発環境が週末ずっと起動 HPA が CPU しか見ておらず、キュー滞留を無視 過剰なストレージクラス（IOPS課金）を全環境で使用 本記事では、FinOps の考え方を用いて、Kubernetesコストを「見える化→改善→定着」の順に進める方法を解説します。 コスト削減の前に定義すべき指標 削減施策が失敗する理由は、目標が「安くする」しかないからです。最低でも次の 4 指標を定義します。 Unit Cost: 1リクエストあたりコスト / 1ジョブあたりコスト Utilization: CPU・Memoryの実効使用率 Reliability: SLO 達成率（削減で品質を落とさない） Waste Ratio: 予約/実使用の差分率 この4つを同時に追うと、単なるコストカットでなく「健全な最適化」になります。 ステップ1：可視化基盤を整える 1-1. Kubecost または OpenCost の導入 EKS/GKE/AKS いずれでも、namespace / deployment / label 単位で費用を把握できる状態にします。重要なのは team, service, env ラベルを強制することです。 推奨ラベル: cost-center owner environment（prod/stg/dev） criticality ラベルがないと請求分析ができず、改善責任が曖昧になります。 1-2. 観測ダッシュボード 最初のダッシュボードは次を必須にします。 Namespace別コスト（当日/前日比） Pod別 request/usage ギャップ ノード空き率（CPU、Memory） 時間帯別トラフィックとレプリカ数 ここまでで「どこが高いか」は見えます。次は「なぜ高いか」を潰します。 ステップ2：最も効果が高い改善施策 2-1. Right Sizing（最優先） 多くの環境で最大効果が出るのは request/limit の見直しです。VPA recommendation を参考に、まずは read-only で 2 週間観測します。 ...

Kubernetesの最新トレンド：Wasm統合とサイドカーレス・メッシュ はじめに 先日閉幕した「KubeCon + CloudNativeCon Europe 2026」の熱気も冷めやらぬ中、この記事を執筆しています。今年のカンファレンスで最も注目を集め、キーノートから各セッションまで、あらゆる場所で議論の中心となっていたテーマは、間違いなくWebAssembly (Wasm) のKubernetesへのネイティブ統合と、それを支えるサイドカーレス・サービスメッシュの進化でした。 Kubernetesを運用する多くのエンジニアが、日々の業務で次のような課題に直面しているのではないでしょうか？ 肥大化するコンテナイメージ: アプリケーションの依存関係が増えるにつれ、コンテナイメージは数百MBから数GBに達し、CI/CDパイプラインの実行時間、ストレージコスト、そしてコンテナの起動時間に悪影響を与えている。 「サイドカー税」の深刻化: マイクロサービスの数が増加するにつれ、各Podにインジェクトされるサービスメッシュのサイドカープロキシ（Envoyなど）が消費するCPUやメモリが無視できないレベルになっている。この「サイドカー税」は、クラスター全体のコストを押し上げる大きな要因です。 複雑化するセキュリティ管理: コンテナはOSの一部を同梱するため、OSレイヤーの脆弱性（CVE）スキャンとパッチ適用に追われる日々。攻撃対象領域（Attack Surface）も広くなりがちです。 もし、これらの課題に一つでも心当たりがあるなら、本記事はあなたのためのものです。KubeCon 2026で示された未来は、これらの長年の課題を根本から解決する可能性を秘めています。この記事では、Wasmとサイドカーレス・メッシュがどのように連携し、次世代のKubernetesエコシステムを形作っていくのか、具体的なコード例やアーキテクチャ図を交えながら、徹底的に解説していきます。 なぜこの技術・話題が重要なのか：背景と2つの大きな課題 この新しいトレンドを理解するためには、まず私たちが現在立っている場所、つまりコンテナとサイドカーモデルがなぜ成功し、そして今どのような壁にぶつかっているのかを振り返る必要があります。 コンテナ技術の成熟と新たなオーバーヘッド DockerとKubernetesがクラウドネイティブの世界を切り拓いてから10年以上が経ち、コンテナはアプリケーションをパッケージングし、デプロイするためのデファクトスタンダードとなりました。しかし、その成功の裏で、いくつかの根深い課題が顕在化しています。 リソースオーバーヘッド: コンテナは軽量な仮想化技術ですが、ゼロオーバーヘッドではありません。各コンテナは、アプリケーションの実行に必要なライブラリやOSのユーザーランドの一部をイメージ内に含んでいます。これにより、同じライブラリがノード上の複数のコンテナで重複してメモリを消費し、イメージサイズも不必要に大きくなります。 遅いコールドスタート: コンテナイメージのダウンロード、展開、そしてコンテナプロセスの起動には、数百ミリ秒から数秒の時間がかかります。これは、常時稼働するサービスでは問題になりにくいですが、FaaS（Function as a Service）やサーバーレス環境のように、リクエストに応じてスケールアウト・スケールインを頻繁に行うユースケースでは致命的なボトルネックとなります。 広い攻撃対象領域: コンテナイメージに含まれるOSパッケージやライブラリは、それ自体が脆弱性の温床となり得ます。glibcやopensslといった基本的なライブラリにCVEが発見されれば、影響範囲の特定と修正に多大な労力を要します。 サービスメッシュの「サイドカー税」問題 マイクロサービスアーキテクチャの普及に伴い、サービス間の通信を制御・可視化するためのサービスメッシュ（IstioやLinkerdなど）が広く採用されるようになりました。その中心的なアーキテクチャが「サイドカーモデル」です。 サイドカーモデルは、アプリケーションコンテナの隣にプロキシコンテナ（Envoyなど）を配置し、全てのネットワーク通信をこのプロキシ経由で行わせることで、アプリケーションコードを変更することなく、mTLS、リトライ、サーキットブレーキング、詳細なテレメトリといった高度な機能を提供します。 このモデルは非常に強力ですが、大規模な環境では「サイドカー税 (Sidecar Tax)」と呼ばれる深刻な問題を引き起こします。 リソース消費: クラスター内に数千のPodがあれば、数千のサイドカープロキシが起動します。これらが消費するCPUとメモリの合計は、アプリケーション本体が消費するリソースに匹敵、あるいはそれを上回ることも珍しくありません。 レイテンシ増加: Pod内のアプリケーションとサイドカー間の通信は、localhostのネットワークスタックを経由します。これにより、マイクロ秒単位のわずかな遅延が積み重なり、サービス間通信全体のレイテンシを悪化させる可能性があります。 運用の複雑化: サイドカーのインジェクション、バージョンアップ、Podの起動・終了シーケンスの制御など、運用は複雑になりがちです。特に、サイドカーがアプリケーションより先に終了してしまうと、正常なトラフィックロスを引き起こすこともあります。 これらの課題に対する解決策として、クラウドネイティブコミュニティがたどり着いた答えが、WebAssemblyとサイドカーレス・アーキテクチャの融合なのです。 具体的な解決策：Wasm on Kubernetesとサイドカーレス・メッシュ それでは、KubeCon 2026で示された次世代アーキテクチャの具体的な中身を見ていきましょう。これは2つの主要な技術要素から構成されています。 1. KubernetesにおけるWasmワークロードの実行 WebAssembly（Wasm）は、もともとWebブラウザでネイティブコードに近いパフォーマンスを実現するための技術でしたが、その「軽量・高速・セキュア・ポータブル」という特性がサーバーサイドでも高く評価されるようになりました。 Wasm/WASIとは？（簡単なおさらい） Wasm: 特定のCPUアーキテクチャに依存しない、ポータブルなバイナリフォーマットです。Go, Rust, C++, Python, Javaなど、多くの言語からコンパイルできます。 WASI (WebAssembly System Interface): Wasmがサンドボックスの外側、つまりファイルシステムやソケット、環境変数といったシステムリソースと安全に対話するための標準インターフェースです。これにより、Wasmはブラウザの外でも安全に動作する汎用的な実行環境となりました。 KubernetesでのWasm実行の進化 数年前（2023-2024年頃）は、KubernetesでWasmを実行するにはKrustletのようなカスタムプロジェクトが必要で、実験的な取り組みでした。しかし2026年の現在、状況は大きく変わりました。containerdのrunwasi shimや、crunのようなOCIランタイムがWasmをネイティブサポートしたことで、Wasmはコンテナと並ぶ第一級のワークロードとして扱えるようになったのです。 これにより、私たちは使い慣れたPodリソースのruntimeClassNameフィールドを指定するだけで、Wasmワークロードをシームレスにデプロイできるようになりました。 コード例：WasmワークロードをデプロイするPodマニフェスト 以下は、Rustで書かれたシンプルなHTTPサーバーをWasmにコンパイルし、OCI準拠のコンテナレジストリにプッシュした後、Kubernetesにデプロイするためのマニフェストです。 ...