システム管理者と開発者の間の壁を取り払う
インフラ管理に携わっている方なら、運用チーム（Ops）と開発チーム（Dev）がまるで別の惑星の言葉で話しているような状況をよくご存じでしょう。私がDell R740上で動作する8台のESXiホストクラスターを管理していた頃、Ops側はvCenterを安定させ、各仮想マシン（VM）を監視することに専念したいと考えていました。一方でDev側は、コードのデプロイを高速化するために常にKubernetes（K8s）を要求していました。
Devがクラスターを必要とするたびに、私は手作業でVMを作成し、OSをインストールし、手動でK8sを構成しなければなりませんでした。この方法は非常に時間がかかり、リソースの制御も困難です。システム障害が発生した際、仮想化レイヤーとコンテナレイヤーの間で原因を追跡するのは悪夢でした。VMware Tanzu は、この状況を終わらせるために誕生しました。これにより、vSphereは単一の管理インターフェース上でVMとコンテナを並行して実行できるプラットフォームへと変貌します。
VMware Tanzu：ESXiがWorker Nodeになる時
実際、VMware Tanzuは単なる追加ソフトウェアではありません。これは、vSphereをネイティブなKubernetes対応インフラに変えるソリューションスイートです。従来の「入れ子」のようにVMの上でK8sを動かすのではなく、Tanzuは「Spherelet」と呼ばれるエージェントを通じてESXiのカーネルに直接統合されます。
Tanzuを有効にすると、vCenterにWorkload Managementメニューが表示されます。この時点から、K8sクラスターは通常のリソースオブジェクトとして扱われます。最大のメリットは、複雑な設定なしで、コンテナアプリケーションに対してもvMotion、DRS、High Availability（HA）を利用できる点にあります。
必要な条件：インフラを「息切れ」させないために
エンタープライズ環境でTanzuを展開するには、綿密な準備が必要です。約200台のVMを稼働させている8台のホストクラスターでの運用経験に基づき、最低限必要なスペックを以下にまとめました。
- vSphere License：vSphere 7.0 Update 1以降が必要です。ライセンスはvSphere with Tanzu（Basic、Standard、またはAdvanced）である必要があります。
- Network：ここが最も混乱しやすい部分です。NSX-Tの予算がない場合は、vSphere Distributed Switch（VDS）を使用します。コストを抑えるために、外部ロードバランサーとしてHAProxyを組み合わせるのが一般的です。
- Storage：ストレージポリシーが必須です。vSphere Container Storage Interface（CSI）の機能を最大限に活用するために、vSANの使用を推奨します。
- 予備リソース：各Supervisor Clusterは、制御用VMとして約16GBのRAMと4 vCPUを消費します。障害発生時に備え、ホストのリソースに少なくとも20%の空きがあることを確認してください。
4つの実践的な展開ステップ
ステップ1：Workload Managementの有効化
まず、vCenterにログインし、Workload Managementセクションに移動してGet Startedを選択します。システムが要件を満たす物理クラスターをスキャンします。
ネットワーク設定でVDSを選択する場合、3つの異なるIP範囲を準備する必要があります。管理用（約5つのIP）、ワークロード用（/23または/22を推奨）、そしてロードバランサー用のVIP範囲です。
ステップ2：HAProxy Applianceの構成
K8sには単一のアクセスポイント（API Server）が必要なため、HAProxyがゲートウェイの役割を果たします。HAProxyのOVAファイルをデプロイした後、Data Plane APIの構成に注意してください。これは、DevがK8sで新しいサービスを作成するたびに、vCenterがロードバランシング構成をHAProxyに自動的にプッシュするためのプロトコルです。
ステップ3：名前空間（Namespace）と制限の設定
Tanzuにおける名前空間は、リソースプールのように機能します。例えば、「Dev-01」チームに対して、最大64GBのRAMと2TBのストレージという制限を設けることができます。
# VMware専用のkubectlツールを使用してクラスターにログインする
kubectl vsphere login --server=10.10.20.50 --vsphere-username [email protected] --insecure-skip-verifyステップ4：Tanzu Kubernetes Grid (TKG) クラスターの初期化
ここで自動化の力が発揮されます。手動でインストールする代わりに、YAMLファイルをvCenterに送信するだけです。システムが自動的にVMテンプレートをクローンし、ネットワークを構成します。
本番環境用の構成ファイル例：
apiVersion: run.tanzu.vmware.com/v1alpha1
kind: TanzuKubernetesCluster
metadata:
name: tkg-prod-cluster
namespace: production-space
spec:
topology:
controlPlane:
count: 3 # コントロールプレーンの高可用性を確保
class: best-effort-medium
storageClass: vsan-default-policy
workers:
count: 5 # 後で簡単にスケールアップが可能
class: best-effort-large
storageClass: vsan-default-policy
distribution:
version: v1.21企業向けの本格的なK8sクラスターが構築されるまで、わずか10〜15分ほどです。
運用における「血の滲むような」実体験
実際のシステムでTanzuを1年以上運用してみて、いくつかのアドバイスがあります。
- Orphaned Volumes（孤立したボリューム）の監視：K8sは永続ボリューム（PV）を非常に素早く作成します。Devがクラスターを削除しても、ボリュームがvSAN上に残ってしまうことがあります。ディスクフルを避けるために、Cloud Native Storageセクションを定期的に確認してください。
- DNSエラーは最も一般的な問題：展開が失敗するケースの90%は、DNSがvCenterやESXiのドメイン名を解決できないことが原因です。開始前にAレコードとPTRレコードを完全に登録しておきましょう。
- ホストグループの分散：8台のホストがある場合、VM-Host Anti-Affinity機能を使用します。このルールにより、コントロールプレーンのVMが同じ物理ホストに配置されないようにし、1台のホストの障害がクラスター全体のダウンを招くのを防ぎます。
終わりに
KubernetesをvSphereに統合することは、単に新しい技術を追いかけることではありません。インフラ管理者が制御権を維持しながら、開発チームのスピード要求に応えるための真の解決策です。一度軌道に乗れば、数百のコンテナを管理することも、以前数台のVMを管理していたのと同じくらい簡単になります。
