ネットワークアクセス¶
オペレーターが Kubernetes API にどう届くかで、kubectl / helm の実行場所が決まります。AKS 設計に合うパターンを選んでください。
パターン A — プライベート AKS API¶
API サーバーにパブリックエンドポイントがありません。接続手段の例:
- コーポレート VPN または ExpressRoute
- VNet 内のジャンプ / バスチョン VM
- その他承認されたプライベート経路
影響
- プライベート API に届くマシン上で Helm を実行する
- CI ランナーも同じ到達性が必要、またはジャンプホストからデプロイ
- ユーザー向け Application Gateway はパブリックのままでもよい
詳細は プライベート AKS 向け Helm。
パターン B — パブリック AKS API¶
API がインターネットから到達可能（多くの場合は承認済み IP で制限）。
影響
- ノート PC や CI から直接
az aks get-credentialsと Helm が可能（ファイアウォール次第） - 承認ネットワークを厳しくし、全世界公開にしない
パターン C — ジャンプ VM を標準化¶
API がパブリックでも、操作を VNet 内 VM に寄せる組織があります（ACR プライベート DNS、Key Vault ファイアウォールなど）。
影響
- VM 上に kubeconfig またはマネージド ID
- ポリシー上、シークレットを開発者 PC に置かない運用が可能
ユーザー通信と操作通信¶
| 通信 | 典型経路 |
|---|---|
| エンドユーザー → AMS UI | DNS → Application Gateway → Ingress → Pod |
| オペレーター → クラスタ API | VPN / ジャンプ / パブリック API → kubectl / helm |
| Pod → Azure PaaS | 設計に応じた PE / サービスエンドポイント |
「プライベート AKS」と「非公開 Web サイト」は別物です。コントロールプレーンをプライベートにしつつ、AMS をパブリックホストで公開できます。
初回 Helm 前の確認¶
- [ ] 操作ホストで
kubectl get nodesが成功する - [ ] チャート取得 / リポジトリ clone ができる
- [ ] AMS ホストの DNS が Gateway を向いている（または本番前に向く）
- [ ] TLS Secret 方針が決まっている
- [ ] テスト Pod で ACR プルができる