本番環境対応のKubernetesプラットフォームを構築するために必要なこと

第1章：
課題：本番環境対応プラットフォームとして、なぜKubernetesだけでは不十分なのか

DIYプラットフォームのライフサイクル

多くの組織は、最初から複雑な内部プラットフォームを構築しようとしているわけではありません。YAMLファイルを一つずつ追加していくうちに、知らず知らずのうちにそうなってしまうのです。「Day 0」のハネムーン期においては、オープンソースのコンポーネントを組み立てる作業は、まさに生産性そのもののように感じられ、開発の焦点は納品の実現に注がれます。新しい問題の一つひとつは、斬新な解決策を要する興味深いパズルですが、プラットフォームが拡大するにつれて、その計算式も変わってきます。

当初は単純なオーケストレーターとして始まったものが、ネットワーク、メッシュ、可観測性、認証のための、相互に依存し合うツール群からなる繊細なネットワークへと発展していきます。Kubernetes®のアップデートが行われるたびに、依存関係のドミノ効果が引き起こされます。2日目の運用は、互換性のテストが中心となり、全システムにわたる構成のずれを管理することが、チームの主な業務となります。

開発者から取り除かれた認知的負荷は消えたわけではなく、単にプラットフォームエンジニアに転嫁されたに過ぎません。ユーザーのために「ゴールデンパス」を構築する代わりに、チームはシステムの維持に追われる悪循環に陥っており、ロードマップに盛り込まれた革新的な取り組みを、メンテナンスという名目の下で絶えず犠牲にせざるを得ない状況にあります。この本番環境への移行準備におけるギャップは、Kubernetesのオーケストレーションそのものではなく、むしろそれを取り巻くあらゆる要素のライフサイクル管理にあるのです。

機能的なギャップ：オーケストレーションとライフサイクル管理を超えて

完全なエンタープライズグレードのコンテナプラットフォームを構築するには、KubernetesのCoreとなるオーケストレーション機能の枠をはるかに超える機能が必要となります。開発者に安定した環境を提供するためには、プラットフォームエンジニアが多様なコンポーネントのスタックを手作業で統合・管理する必要があります。

CNCFのエコシステムには1,200件以上のプロジェクトが存在するため、各組織はツールの選定やインテグレーションにおいて、非常に複雑な課題に直面しています。GitOps、オブザーバビリティ、セキュリティのいずれを目的とするにせよ、スタックに追加されるすべてのツールは、以下の要素を含む恒久的なメンテナンス要件となります：

• 高度なネットワーク：L4/L7 ロードバランシング、DNS、およびネットワークポリシーの適用
• Ingress ゲートウェイ：HTTP ルーティング、SSL/TLSの終端処理、および外部アクセス管理
• コンテナレジストリ：プライベート イメージのホスティングとライフサイクル管理
• データサービス：ステートフルストレージ、ストレージ移行、および事業継続性を確保するためのレプリケーション機能を備えたコンテナネイティブのバックアップ／リストア
• ポリシー管理： クラスタ全体で「ポリシー・アズ・コード」による適用を行う、一元化された RBAC
• セキュリティ：機密情報の 管理、サプライチェーンの管理、およびゼロトラスト・ネットワークのパターン
• オブザーバビリティ： クラスタ間のメトリクス 、ロギング、およびトレーシング 
• 自動化とデプロイ：GitOps ワークフロー（Argo CD／Flux）に加え、ビルド／テスト／デプロイのためのCI/CDパイプラインとの統合
• マルチクラスター管理：ハイブリッド／マルチクラウド環境全体におけるフリートのプロビジョニング、アップグレード、ポリシーの展開、および運用管理
• FinOps／コスト管理ツール：チームやクラスターを横断した利用状況の可視化とコスト最適化
• GPUへのアクセス： AI／MLワークロードにおけるGPUへのアクセスとスケジューリングの管理  
• サービスメッシュ：トラフィック 管理、サービス間セキュリティ（mTLS）、およびワークロードレベルの可観測性

これらのコンポーネントのライフサイクルを手動で管理するには、多大なリソースを要します。本番環境向けのプラットフォームを構築するには、20以上の異なるコンポーネントを手作業で統合する必要があります。各プロジェクトは年に3～4回リリースされるため、プラットフォームチームは年間100回以上のアップグレードという実証済みの負担に直面しており、その都度、独立した互換性テストや回帰テストが必要となります。スタック全体を検証済みの単一のユニットとしてアップグレードするプラットフォームがなければ、エンジニアはアーキテクチャ的な価値を提供することよりも、基盤となるインフラストラクチャーの管理に注力し続けることになります。

サポート期間とAPIの脆弱性

Kubernetesはマイナーリリースを短い間隔で提供しており、特定のマイナーバージョンに対するアップストリームからのパッチサポート期間はおよそ12か月（多くの場合、エンドツーエンドで約14か月と見なされます）であるため、プラットフォームチームは継続的なアップグレード作業を余儀なくされています。アップストリームのKubernetesは、あらかじめ統合されたエンタープライズ向けスタックとして提供されていないため、アップグレードのたびに完全な互換性確認作業が必要となります。これには、非推奨および削除されたAPIの監査、マニフェストやオペレーターのアップデート、および重要なアドオン（CNI、CSI、インジェストコントローラー、ポリシー、可観測性コンポーネント）が対象バージョンとの互換性を維持していることを確認することが含まれます。その結果、アップグレード・デットが生じることがよくあります。これは、ダウンタイムのリスクを冒せない、あるいはすべての相互依存関係を適切に検証するためのリソースがないため、チームが重要なセキュリティパッチの適用を先送りしてしまう状況です。

環境間の断片化

多くの組織は主にオンプレミス環境で運用されていますが、パブリッククラウドやエッジロケーションにもまたがるハイブリッド環境のサポートを求める声が高まっています。ベンダーに依存しない統一されたAPIがなければ、こうした環境は孤立した運用上のサイロとなってしまいます。このような分断により、通常、企業はハイブリッド運用をサポートするために、エンジニアリングチーム、オンプレミスチーム、パブリッククラウドチームなど、複数のチームを必要とせざるを得なくなります。これは、管理ワークフローや自動化スクリプトがプロバイダー間で移植できないためです。

こうした複数のチームを維持することによる主な影響は、運用上のオーバーヘッドと技術的な複雑さが大幅に増大することです。というのも、組織は異なるインフラストラクチャー間で同一のワークロードを管理するために、重複した作業を行わなければならないからです。こうした一貫性の欠如により、統一されたセキュリティ体制を徹底することが困難となり、クラスタ群が互いにばらばらな環境の寄せ集めとなってしまいます。各チームには、あらゆる環境においてクラスターの構築とセキュリティ対策の手法を標準化するソリューションが必要です。単一の運用モデルを採用することで、重複する専門チームの必要性を減らし、ワークロードの実行場所にかかわらず本番環境への移行準備が確実に整うようにします。

ステートフルなワークロードの回復力とデータ保護

Kubernetesは、ステートレスなサービスのために誕生したものであり、ステートや永続的なデータは外部インフラストラクチャーに転送されます。組織がミッションクリティカルなデータベースやキーバリューストア、その他の長期保存用ストレージをクラスターに移行するにつれ、ストレージが最大のボトルネックとなり、プラットフォームチームはKubernetesとレガシーストレージアレイの間のギャップを手作業で埋めることに追われることになります。エンタープライズグレードのデータサービスの実装は、クラウドネイティブアーキテクチャにおいて依然として大きな課題となっています。Kubernetesはステートレスなスケーリングを効果的に処理しますが、ステートフルなワークロードを保護するには、ブロックストレージ、ファイルストレージ、S3互換のオブジェクトストレージなど、マルチプロトコルにサポートするための複雑なインテグレーションが必要となります。メトロレプリケーションや非同期レプリケーションをサポートする、ネイティブでアプリケーションを意識したストレージ統合がなければ、ミッションクリティカルなワークロードに必要な復旧時間を達成することは、依然としてほとんどのプラットフォームチームにとって、「Day 2」における疲労感の主なソースとなっています。

コストの増加と営業債務

オープンソースのDIYプラットフォームが当初持つ魅力は、その維持管理にかかる負担や、維持管理に必要な手作業の労力によって、しばしば影を潜めてしまいます。プラットフォームを少しずつ構築していくと、開発者向けサービスの構築に充てられるエンジニアの工数が、断片化したスタックのパッチ適用、テスト、トラブルシューティングという終わりのないサイクルに割かれてしまいます。フリートが拡大するにつれて、運用上の負担は非線形に増大し、チームのキャパシティがライフサイクル管理や故障対応・修復作業に費やされてしまうという悪循環に陥ってしまいます。結局のところ、こうした運用上の負債はボトルネックとなり、優秀なエンジニアたちは、実際にビジネス成果やイノベーションを牽引する高付加価値のサービスを提供するのではなく、基盤部分の維持管理に注力せざるを得なくなってしまいます。

第2章：
戦略の転換：社内開発者向けプラットフォームと「ゴールデン・パス」

多くのエンタープライズ企業が、断片化したDIYスタックの維持管理に伴う継続的な負担を回避するため、管理・最適化されたプラットフォーム環境の導入を検討しています。その目的は、チームの注力を低レベルのコンポーネントインテグレーションから、内部開発者プラットフォーム（IDP）の提供へと移行させることにあります。プラットフォームエンジニアリングチームは、イノベーションを簡素化・標準化する最も容易な方法として、本番環境への「ゴールデンパス」を構築しています。

IDPが効果を発揮するためには、その基盤として以下の点が挙げられます：

• オープンかつ拡張性が高い：純粋なアップストリーム版Kubernetesを基盤としており、CNCFエコシステムとの完全な互換性を確保するとともに、プロプライエタリなロックインを回避します 
• 環境間の一貫性： Kubernetes導入の戦略的意図に沿い 、Kubernetesプラットフォームは、オンプレミス、パブリッククラウド、ハイブリッド、エッジなど、さまざまな環境にわたって統合された可視性を提供できるよう、一貫性と拡張性を備えている必要があります。
• AI対応インフラストラクチャー：単純なコンテナの枠を超え、GPUなどのリソースや動的リソース割り当て（DRA）を標準的なプラットフォームサービスとして扱うものです。
• 開発者重視： クラスタ群に対するパッチ適用、アップデート、アップグレード、およびテストのための自動化機能が組み込まれており 、一元的な可観測性を実現するとともに、開発者がアプリケーションコードのリリースやイノベーションに集中できるようにします
• データサービス： 画像やメディア用のオブジェクトストレージ、構造化されたユーザーデータ用のSQL/NoSQLデータベース、ログ用のファイルストレージなどを含む、データ サービスおよび管理スタックです。これにより、必要なデータの永続性とストレージリソースが、コンピューティングリソースと併せて確保されます

Nutanixは、プラットフォームエンジニアリングチームが、純粋なアップストリームKubernetesを基盤としたエンタープライズ対応のプラットフォームを導入できるよう支援し、開発者がインフラストラクチャーのプロビジョニングに伴う手作業による遅延なしに、コードのコミットから本番環境への移行を行えるセルフサービス環境を提供します。

第3章：
Nutanix Kubernetes Platform

Nutanix Kubernetes Platform（NKP）は、クラウドネイティブアプリケーションに耐障害性、セキュリティ、および運用段階（Day 2）の運用機能を提供する、包括的でオープンなエンタープライズグレードのプラットフォームです。NKPは、クラスターの構築、アップグレード、セキュリティ対策、監視の方法を標準化した独自のスタックにより、DIY型Kubernetesに伴う統合の負担を解消するよう設計されており、オンプレミス、エッジ、パブリッククラウド環境にわたるクラスター群を、単一の運用モデルで提供します。

以下の主な機能が含まれます:

• エンタープライズ対応プラットフォーム：このフルスタックプラットフォームは 、モニタリング、セキュリティ、外部からの通信の受け入れ、継続的デリバリー、ストレージなど、本番環境でコンテナ化されたアプリケーションを展開・実行するために必要なすべてのコンポーネントを提供します。
• オープン：CNCFの上流プロジェクトに完全に準拠しており、検証済みのCNCFプロジェクトの全カタログにアクセスできるほか、プラットフォームのニーズに応じて任意の代替ツールを自由に統合することができます。 
• 合理化されたライフサイクル管理（LCM）： 単一のプラットフォームをアップグレードするだけで 、クラスタの展開、アップグレード、OS、およびアドオンコンポーネントが自動的に行われます。これらすべてについて、アップグレードテストおよび互換性テストが実施済みです。
• 可観測性 と Insights: ロギング、モニタリング、アラート機能の統合 。NKP InsightsおよびAI Navigatorは、ルート原因分析を伴う異常検知機能、対話型のトラブルシューティングインターフェース、およびトラブルシューティングを迅速化するための推奨事項を提供します。
• 再現性のあるビルドのためのゴールデンテンプレート：NKPは 、標準化された"のゴールデンパス" および自動化機能を提供し、あらゆる環境において一貫性があり再現性のあるクラスタービルドを実現します。これにより、組織がコンテナの数を拡大する際に通常発生しがちな、手動設定のずれを回避することができます。
• ネイティブ統合によるデリバリーの迅速化：ネイティブなCI/CD パイプラインの統合とGitOpsベースの調整機能により、開発者は、DIYプラットフォーム特有のインフラストラクチャー上のボトルネックに悩まされることなく、コードのコミットから本番環境への展開までをスムーズに進めることができます。
• 環境間の移植性： 一貫した運用を維持し 、どこでもワークロードを実行できます。 
• 運用コストの最小化：NKPは、さまざまな環境（クラウド、オンプレミス、エッジ）にわたるクラスターの管理を一元化することで、異なるツールや重複するチームを管理する際の負担を軽減します。
• Nutanixのエンタープライズグレードのサポート： NPS（ネットプロモータースコア）90以上を誇る、信頼性の高い 継続的なサポートです。 

フリートマネージメント

• 宣言型フリートオーケストレーション：NKPは 、Cluster APIパターンを活用して、クラスタのライフサイクル管理のための統一された宣言型インターフェースを提供します。Kubernetesコントローラーを活用することで、on-premise、クラウド、エッジ環境を問わず、インフラストラクチャを望ましい状態に自動的に調整します。
• 一元化されたフリート管理： 単一の ペイン から、フリート全体にわたる クラスタ の作成、設定、アップグレード、および監視の方法を標準化します。
• 一貫性のある変更の展開： 手動による操作を必要とせずに、複数のクラスタにアプリケーションおよび設定のアップデートを適用します
• 統合プラットフォーム・ツールセット：NKPには 、CNCFプロジェクトや、ネットワーク、可観測性、ポリシー管理、セキュリティなどのプラットフォームコンポーネントに関する検証済みのカタログが含まれており、チームはツールを組み合わせたり、互換性を再テストしたりする時間を削減できます。
• AIを活用した診断と運用： 「NKP Insights」と「AI Navigator」は、自動化された信頼性エンジニアとしての役割を果たし、ベストプラクティスに照らしてクラスターを継続的にスキャンすることで、障害が発生する前に異常を検知します。また、自然言語によるトラブルシューティングが可能な対話型インターフェースを提供し、平均復旧時間（MTTR）の短縮を図ります。

1つのプラットフォームでどこでも実行可能

組織は、NKPを幅広い環境に導入することができます。NKPは、Nutanix独自の「Nutanix Cloud Infrastructure（NCI）」プラットフォームをはじめ、仮想マシン、ベアメタルサーバー、パブリッククラウド、エッジ拠点、さらにはエアギャップ環境に至るまで、オンプレミス環境でシームレスに動作します。Nutanixインフラストラクチャ上でNKPを実行することで、導入を効率化し、運用を加速させ、包括的なデータサービススイートへのアクセスを可能にする独自の統合機能が提供されます。さらに、Nutanixプラットフォームの分散型データベースアーキテクチャは、さらなる耐障害性を提供し、NKPのFoundationを強化しています。

セキュリティおよびエアギャップサポート

NKPは、セキュリティ機能が組み込まれており、お客様のコンプライアンスプログラムをサポートする機能を備えて設計されています。本ソリューションは、アイデンティティ、アクセス制御、ポリシーの適用、ネットワークのセグメンテーション、およびセキュアなアップグレード手法を標準化しており、制限された環境やエアギャップ環境へのサポートも含まれています。

• 一元化されたアクセス

  • 認証： SSOおよびフェデレーテッド認証のパターンをサポートし 、クラスタ間でIDとアクセス権限の一貫性を維持します。

  • RBACと暗号化：KubernetesネイティブのRBACと暗号化を活用し、企業のセキュリティ要件を満たすとともに、クラスターごとのアクセスモデルを削減します。

  • コンプライアンス支援： 必要に応じて、FIPS 140-2 などの要件への準拠を支援する機能を提供します 。

• ポリシーの適用とネットワーク制御

  • Policy as Code（OPA）： ポリシー適用機能（OPA Gatekeeper）を活用することで 、デリバリーの速度を低下させることなく、アクセス制御やベースラインのセキュリティルールといった基準を一貫して適用できます。

  • ネットワーク制御： ポッド／サービスレベルのトラフィック制御のために、クラウドネイティブのネットワークオプション（Cilium／Calico）およびKubernetesネットワークポリシーをサポートしています 。

  • mTLS 向けのサービスメッシュ： 必要に応じて、サービス間セキュリティのための mTLS を有効にするサービスメッシュ機能をサポートします 。

• 安全なライフサイクルと検証済みの運用

  • ライフサイクルの整合：コアプラットフォームのセキュリティコンポーネントを、検証済みかつバージョンが整合されたプラットフォームアプリケーションとして展開・維持管理し、バージョンの不整合やアップグレードに伴うリスクを低減します。

• エアギャップ環境／制限環境での運用
  • オフラインでのパッケージ化と配布：制限付きネットワークへの画像やチャートの移行にかかる手作業の負担を軽減するため、オフラインでのバンドル手法をサポートします。
  • ローカルレジストリオプション： ローカルレジストリ モデルを有効にし 、環境内でイメージを保存・管理できるようにします。
  • プロキシとオフライン環境での柔軟性： 既存のプロキシやローカルレジストリを活用できるため 、エアギャップ環境の構築においても、その場限りの特注設定が不要です。
  • 軍事グレードのDevSecOps：
    • 安全かつ検証済みの導入を実現するための、事前にスキャン済みのリリースおよびインストールバンドルです。
    • SSOおよび一元化されたRBACによる統合的なアクセス制御。
    • ワークロードの安全な分離を実現するマルチテナント機能。
    • VPC 統合とネットワークポリシーによるきめ細やかなトラフィック制御。
    • 転送中のデータを保護するための暗号化通信。
    • セキュリティ対策を積極的に推進し、お客様がコンプライアンス要件を満たせるよう支援するための、ポリシーの適用および異常検知。

第4章：
ステートフルワークロード向けのエンタープライズグレードのデータサービスと管理 

Nutanix Data Services for Kubernetes（NDK）は、ステートフルなKubernetesワークロード向けにアプリケーションを意識したレプリケーションとディザスタリカバリ機能を提供することで、エンタープライズストレージをKubernetes環境に拡張します。これにより、プラットフォームチームは、別途ストレージやデータサービスソリューションを統合することなく、データの保護やアプリケーションの復旧を行うことができます。開発者は、デプロイメントパイプラインの一環として、アプリケーションレベルのスナップショットおよびレプリケーションのスケジュールを定義できるようになりました。

これにより、プラットフォームチームには次のようなメリットがもたらされます：

• Kubernetes向けエンタープライズストレージ：Nutanix Unified Storage（NUS）は、ブロック、ファイル、オブジェクト、データベースを含むあらゆるデータにサポートした、統合型の永続ストレージを提供します。そのスケールアウト アーキテクチャーは、Kubernetes アプリケーションの構築および実行方法と整合しており、クラスタ間の拡張を簡素化します。
• Database-as-a-Service： SQL、NoSQL、およびベクトルデータベースの迅速かつ再現性の高い導入を実現するための、Database-as-a-Service（DBaaS）のサポートを提供します 。NDB Kubernetes Operator を使用することで、開発者は「インフラストラクチャ・アズ・コード」を活用し、NKP 内から直接、データベースのプロビジョニング、パッチ適用、バックアップを自動化できます。これにより、データセンターやエッジ環境においても、パブリッククラウドのデータベースサービスと同様の利便性を実現できます。
• NDKはNKPアプリカタログから利用可能： プラットフォームチームはNKPを通じてNDKを直接有効化できるため、アプリケーション認識型レプリケーションやDRをKubernetesプラットフォームの標準機能として容易に導入することが可能です。
• アプリケーションおよびネームスペースレベルの保護： ポリシーに基づくバックアップ、スナップショット、レプリケーション、および災害復旧（DR）のオーケストレーションにより、RPO(目標復旧時点)／RTO(目標復旧時間)のリスクを低減します
• マルチサイト・ガバナンスのサポート： クラスタ間で一貫したポリシーを適用することで、地理的に分散したデータ保護を実現し、コンプライアンスおよびガバナンスの要件に対応します。

第5章：
プラットフォームチームの運用成果 

効率化されたライフサイクル管理

NKPは、さまざまなインフラストラクチャープロバイダー向けに、Kubernetesのデプロイ、拡張、およびアップグレードを自動化します。Kubernetesのアップグレードをその都度、独自のインテグレーション作業として扱うのではなく、プラットフォームチームは、プラットフォームのCore機能全体にわたって互換性が確認されているプラットフォームを活用することができます。これにより、クラスター間のバージョン不一致を抑制し、ハードウェアの更新サイクル間の調整を簡素化し、アップグレードの遅れを最小限に抑えることができます。また、不必要な運用リスクを招くことなく、環境全体のパッチ適用状況を最新の状態に維持しやすくなります。

全フリートにわたる運用の一貫性

NKPは、Kubernetesのデプロイ、設定、ガバナンスの方法を標準化することで、クラスターや環境を問わず一貫した運用モデルを実現します。クラスターがオンプレミス、パブリッククラウド、あるいはエッジのいずれで稼働していても、プラットフォームチームは、すべてのクラスター群に対して、同一のライフサイクルワークフロー、セキュリティ制御、およびポリシーの境界を適用することができます。この一貫性により、クラスター間のずれを軽減し、本番環境への移行準備が、ワークロードの実行場所やクラスターの初期作成方法に左右されないようにすることができます。

ソフトウェアの迅速な提供

NKPは、ブループリント化されたクラスターとゴールデンイメージを活用することで、迅速な価値実現を実現するよう設計されており、反復可能なデプロイメントにおける導入時間を大幅に短縮します。チームは、数十もの独立したオープンソースコンポーネントを組み立て、継続的に再検証する代わりに、一貫したライフサイクルを備えた、完全かつ統合されたプラットフォームレイヤーを基盤として運用しています。NKPは、手動による依存関係の追跡、バージョンの互換性テスト、および環境固有のスクリプト作成の負担を軽減することで、プラットフォームのリソースを解放し、より付加価値の高い業務に注力できるようにします。NKPは、統合されたセルフサービス環境を提供することで、市場投入までの時間を短縮するのに役立ちます。これにより、開発者は重要なツールを活用し、データサービスを遅滞なく簡単に利用できるようになります。