AKS Private Cluster Networkingを理解するための前提
AKS networkingは変化が速いため、旧方式とcurrent recommendationを区別して記載しています。実装直前には下記Microsoft Learnのcurrent constraints / region / version supportを再確認してください。
private AKS clusterではcontrol plane/API serverにinternal IPを使い、node poolとの通信をprivate network内に保つ。 Private Link方式のprivate clusterではAPI server VNet側Private Link Serviceとcluster subnet側private endpointを通じてcontrol planeへ接続する。
default構成ではprivate DNS zoneがcluster node VNetへlinkされ、API server private endpointのA record解決を支える。hub/custom DNSを使う場合はこのlink/forwardingを明示設計する。 public FQDNをdisableしても重要なのは名前ではなくmanagement clientからprivate endpointへのnetwork reachability。VPN、ExpressRoute、peering、Bastion/VM等の管理経路を用意する。
API Server VNet Integrationではcontrol planeをcluster VNet内private IPとして到達可能にするmodelがあり、別VNetから到達させる場合はPrivate Link Service/Private Endpoint等の追加patternが必要になる場合がある。 private control planeでもworkload/node egress要件は別。APIをprivateにしたことをinternet egress isolationと混同しない。
通信経路と責任境界
アドレスと識別情報の考え方
| Address / identity | Where it lives | 運用上の意味 |
|---|---|---|
| API FQDN | private DNSでAPI private IPへ解決 | public FQDN有無とpublic endpoint exposureは別概念。 |
| API private IP | private endpointまたはVNet-integrated control plane | management sourceからroute可能であることが必要。 |
| Management source | ops VNet/on-prem/runner | どこからkubectlするかを固定しDNS/link/routeを設計。 |
| Workload egress | node/pod outbound path | control planeをprivate化してもinternet egress設計は別途必要。 |
設計判断
| 判断軸 | 確認する問い | 設計として固定すること |
|---|---|---|
| Management source | 誰がどこからkubectl/CIするか | ops VNet/on-prem/runner subnetを固定。 |
| DNS ownership | AKS-managed private zoneかBYO private DNSか | hub resolver/conditional forwarder/RBACまで設計。 |
| Public FQDN | public DNS nameを残す必要があるか | public FQDN有無とpublic endpoint有無を混同しない。 |
| Cross-VNet | hub/ops VNetからAPIへどう到達するか | peering/private endpoint/VPN/ER patternを選択。 |
| Break glass | 通常management path障害時の復旧手段 | command invoke等を含めsecurity policyとrunbook化。 |
実装・移行の順序
- cluster方式（Private Link private cluster / API Server VNet Integration）を確認する。
- API FQDNとresolved private IP、private DNS zone/linkをinventoryする。
- management sourceからDNS query→route→TCP 443の順に検証する。
- custom DNS/hub resolver使用時はconditional forwardingとPrivate DNS link ownershipを確認する。
- CI/CD runnerから同じcontrol-plane pathを検証し、人手端末だけ成功する状態を避ける。
- stop/start/upgrade等でprivate endpoint/DNS behaviorが変わる可能性もrunbookへ記録する。
運用で残しておく情報
| 観点 | 残すべき運用証拠 |
|---|---|
| API endpoint | az aks showのprivateFQDN/fqdn/apiServerAccessProfileを記録。 |
| DNS | management sourceからAPI FQDNが期待private IPへ解決するか。 |
| Route | source VNet/on-premからAPI endpoint subnetまでのroute/NSG/firewall。 |
| CI/CD | self-hosted runner等のmanagement client pathも同じ基準で確認。 |
変更前に確認する
Control state
AKS networkProfile、Kubernetes object、Azure associationをread-onlyで採取し、desired configurationを固定する。
Data plane
同じ5-tupleで実通信し、forward path・return path・source translation・policy decisionを証明する。
Observability
DNS/TCP/flow/drop/backend health等、障害点に対応するsignalを同一時刻で収集する。
Negative test
allowだけでなく、禁止すべき通信が明示的に失敗することもsecurity acceptanceへ含める。
az aks show -g <rg> -n <cluster> --query "{privateFqdn:privateFqdn,fqdn:fqdn,api:apiServerAccessProfile,nodeRg:nodeResourceGroup}" -o jsonc
kubectl cluster-info
kubectl get nodes -o wideCommon failure modes
| 症状 | 疑うboundary | 確認・是正 |
|---|---|---|
| kubectl timeout | DNSは正しいがroute/NSG/VPNなし | name resolutionとTCP reachabilityを分けて確認。 |
| API名が解決しない | Private DNS link/custom DNS forwarding不足 | zone linkとresolver pathを確認。 |
| hub VMだけ失敗 | private zoneがspokeにしかlinkされていない | hub側resolver/link/forwarding designを修正。 |
| private clusterなのにpublic DNS名がある | public FQDNとendpoint exposureを混同 | public FQDNはname resolution要素。actual API pathを確認。 |