NKPって結局誰がやるのか
HCIの話をしている流れでKubernetesの話を出すと、これ自分たちの話じゃない感を感じていて。
でも今の流れ見てると、それで切り分けられる話でもないよなと思っていて、
Kubernetesって結局誰がやるのか、ちゃんと整理して考えてみたくなったので書いてみる。
Kubernetesがこんなに騒がれている背景から
理由はシンプルで、アプリの作り方が変わったから。
- アプリの数が増えた
- 更新頻度がめちゃくちゃ上がった
- マイクロサービス化が進んだ
一つのアプリが細かく分かれて、10〜100のコンテナで動くのが普通になってる。
しかもそれが毎日のように更新される。
これ、VM単位で管理してたやり方だと普通に破綻する。
実際、
- 企業のほとんどがKubernetesを検討または利用
- 新規アプリのほぼ全部がコンテナ前提
ここまで来ると「流行り」じゃなくて、前提条件に近い。
とはいえ、K8sはちょっと癖モノで難しい!?
なんとなくよく聞くようになったし重要なのは分かるけど、やりたくはない。
理由は単純で、運用が重すぎるから。
Kubernetes運用の現実
[構築]
- CLIでクラスタ作成
- ネットワーク（CNI）設計
- ストレージ（CSI）連携
- バージョン整合性チェック
[運用]
- アップグレード
- 脆弱性対応
- 障害対応
- ログ / 監視
つまり、作るより運用が本体。
現場で起きていること
この難しさの結果、役割分担が崩れる。
- アプリ側 → Kubernetes使いたい
- インフラ側 → 面倒見きれない
結果として、
- プロジェクトごとにクラスター乱立
- 設定バラバラ
- セキュリティ統一なし
いわゆるスプロール状態になる。
そしてトラブルが起きると、
- アプリの問題？
- インフラの問題？
- Kubernetesの設定？
誰も全体を説明できない状態になる。
誰がやるべきか
ここが一番重要。
- Kubernetesを使うのはアプリ側
- でも責任を持つのはインフラ側
このズレが問題。
そこで出てくるのがプラットフォームエンジニアリング。！！！
理想の構造
インフラ側
↓
標準化されたKubernetes基盤を提供
↓
アプリ側がセルフサービスで利用
ポイントは、最初からガバナンスが効いた状態で渡すこと。
NKPの立ち位置
Nutanix Kubernetes Platformは、この構造をそのまま実現している。
やっていることは大きく3つ。
1. 構築の標準化
- CNI / CSI / OSSの組み合わせを事前検証済み
- 設計の悩みをほぼ排除
2. Day0〜Day2の一元管理
- 構築だけでなく運用まで含めて管理
- アップデートやライフサイクルも統制
3. 周辺OSSの統合
- Service Mesh
- Observability
- CI/CD
これらをカタログから展開可能だとか...!
従来：
OSSを個別に選定・検証・統合
NKP：
最初からパッケージ化済み
コンテナの弱点も吸収している
コンテナの特徴として、
- データは基本持たない（ステートレス）
- 停止するとデータが消える
なので本来は、
- 永続ボリューム設計
- バックアップ設計
- 整合性管理
が必要になる。
ここもNKPでは、
データ保護をインフラ側にオフロード
- スナップショット
- レプリケーション
- バックアップ
→ コンテナに負荷をかけず実行
運用難易度が一段下がるポイント。
~One Platform~の価値
もう一つ大きいのがここ。
従来
VM基盤
K8s基盤
→ 別々に管理
NKP
VM + Kubernetes
同一インフラで運用
これによって、
- サーバーの二重化が不要
- 運用チームの分断を防げる
- 責任の所在が明確になる
地味だけどかなり効いてくるポイント。
結局、誰がやるのか
ここまで整理するとシンプルで、
- Kubernetesを使うのはアプリ側
- でも運用を成立させるのはインフラ側
NKPはその間のズレを埋めるためのもの。
Kubernetesを簡単にするというより、
Kubernetesを「ちゃんと管理できる状態に戻す」ためのプラットフォーム。
まとめ
- Kubernetesはもう選択肢ではなく前提
- ただしそのまま導入すると運用が崩れる
- 問題は技術ではなく「責任と統制」
- NKPはその構造を整えるためのもの
この視点で見ると、
誰に必要なものかが少しクリアになると思う。
...そろそろ家のサーバーにもNKPをデプロイするか、、、（多分やります）