QiitaでAzure Kubernetes Service(以下、AKS)の記事を書きましょうキャンペーンのようなことを開催してるようなので参加してみます。
先月はAzure IoTでも同じようなキャンペーンを開催していたと思うのですが、10月10日はIPA主催の情報処理試験があり、その勉強のために泣く泣く参加できませんでした。
IoTも大したことないですが、Kubernetesはもう一つ何も知らないので生暖かい目で見てくだされば幸いです。

プライベートIPアドレスでオンプレミスからアクセスできるように構築してみる

公式ドキュメントをざっと読みつつ、仮想化、コンテナと一通り知ってるつもりではあるのですが昔仮想化技術の区分けにあった[完全仮想化]と[準仮想化]の違いと今の仮想化とコンテナの違いがいまいちわからず読み進めていました。
行きついた先は「とりあえずデモ環境を作ってみよう」という思いつきなのですが、進めていきます。
ただ普通に構築しては面白くないのと、公式ドキュメントにあったネットワークトポロジを読む限り、なんとなくネットワークに難しい点があるように見えたので、今回は全てプライベートネットワーク＋Hub Vnet無しでオンプレミスから直接AKSにアクセスできる環境を構築してみようと思います。

プライベート環境にAKSを閉じ込める理由

想定されるエンドユーザーからの要望

日本国内のお客様はVPN神話と揶揄されるように、「たとえ如何なる通信だろうとインターネットを経由することは言語道断。なので専用線もしくはVPNを必ず経由するようにしなさい。」という不文律のポリシー(？)が非常に強い傾向があるので、今後こういった案件が出てきた時もプライベート空間に閉じ込めた環境下でAKSを構築できるようになればそれなりに役に立つかな、という観点もあります。

公式ドキュメントのネットワークトポロジに逆らう理由

課金

また課金の観点からも、Hub Vnetを経由してのオンプレミスの通信が発生する公式のネットワークトポロジでは、AKSのあるVnetからオンプレミスにデータを返す際、Hub VnetとAKSのあるVnet間を接続するVnet Peeringを経由するのですが、このVnet Peeringは通信のIn/Out両方に課金がかかります。
Hub Vnetを見ると以前の記事で触れたAzure Firewallがあったり、Azure Bastionがあったり、Gateway Subnetがあったりしてネットワーク関連サービスがまとまっているだけです。
今回私が構築した方法であれば少なくともAzure Bastionは不要になり、Azure FirewallとGateway SubnetはAKSのあるVnetに構築できます。
Azure FirewallはAKSのOutBound方向の通信を制御するために必須のリソース、Gateway Subnet(というかVirtual Network Gateway)はオンプレミスとの接続に必須のリソースなのでこれらは省略できません。
Microsoftの公式ドキュメントに従って構築すると、私の感覚では「不要な通信コストが発生する」環境になってしまいます。
ご存知の通りAzureは通信量も従量課金で青天井(実際は31日×24時間×60分×60秒×最大通信速度(bps)ですので上限はある)となるので、これでは「課金が怖くて利用の促進が進まないのではないか？」と少々疑問を持ってしまいます。
非常に不遜な発言なのは重々承知の上なので、私の認識が間違えているのであればお手数ですがご指摘ください。

能書きはこれくらいにして、それではいってみましょう。

とりあえずいきなりデプロイする

既存環境にデプロイすることも考えましたが、ネットワーク調整が難しかったので新規でリソースグループを作成し、そこにAKSをデプロイします。

もういきなりAKSを新規で作りましょう。

初期設定ではこんな感じですが

こんな感じに設定変更しました。
MSDNのサブスクリプションを利用しているのでリージョンに縛りがあることと、CPUコア数に上限があること、当然課金に制限があることからこのような設計です。
[ノードプール]をクリックすると以下の画面になります。

実際のノードプールは赤枠の部分なので、ここもクリックしてみます。

ほとんど前項の設定値を引き継いでいるので問題ないと判断しました。
本格的に利用するなら[ノード当たりの最大ポッド数]は調整した方が良いかもしれません。
具体的な設定値は利用用途によりけりだと思います。

[ノードプール]の画面に戻ってきました。
画面中ほどの[仮想ノードを有効にする]にチェックを入れます。
この説明文、凄いことが書いてあります。

[仮想ノードでは、サーバレスのAzure Container Instanceを活用してバースト可能なスケーリングが可能になります。]
[仮想ノードでは、サーバレスのAzure Container Instanceを活用してバースト可能なスケーリングが可能になります。]
え？
[バースト可能なスケーリングが可能になります。]
非常にPublic Cloudっぽいですね。
心強い反面、課金が怖いです・・・
サーバレスなのでSpot InstanceやReserved Instanceの対象から外れると思うのですが、どうなんでしょうか。
この点は調べて後日追記します。
続いて[認証]へ進みます。

ここはいったんこのままいきます。

ネットワークレンジが広いのが気になりますが、コンテナたくさん立てるのに必要なのかと思うのでこのままにします。
セキュリティの項目も気になるので確認します。

[プライベートクラスターの有効化]の情報ボタンにホバーすると、大事な一文が出てきました。
[プライベートクラスタは、APIサーバとノードプール間のネットワークトラフィックがプライベートネットワークのみ保持されるようにするために、内部アドレスを使用します。]
もう全文赤字です。
ここは今回の想定構成だとチェックが必須ですね。

[承認されたIP範囲の設定]がグレーアウトしました。
[プライベートクラスタの有効化]と二者択一の構成なのでしょう。
恐らくパブリック環境からアクセス可能な状態でAKSを構成した際に、アクセス元IPアドレスを絞る設定だと思います。
今回の想定構成から外れるので今回は検証しません。
そして最後の[ネットワークポリシー]の[なし]が気になります。
情報ボタンにホバーしてみましょう。

記載内容を要約すると、ポッド間のInbound(イングレス)OutBound(エグレス)通信の制御を行うか行わないかの設定で、かつLinuxのノードプール(設定画面上で2つ前のタブ)に対してのみ制御を加えるものということです。
CalicoネットワークポリシーもAzureネットワークポリシーも存じ上げませんが、とりあえず[Azure]を選択します。

つづいてAKS内でデプロイされるコンテナーをどこのイメージから呼び出すのかの設定、コンテナレジストリの設定です。
新規作成で、どのようなパラメーターが選択できるのか確認しましょう。

コンテナレジストリのFQDNの指定とデプロイリージョンの指定、管理者ユーザとSKUの指定です。
ここはリソースグループとリージョンはデフォルト値でそのままとし、管理者ユーザもそのままにし、SKUはStandardから料金低減の観点でBasicに選択します。

今回検証ですので監視も無効にします。
タグは不要なのでこのままデプロイしましょう。

しばらく待つと無事デプロイが終りました。

AKSにアクセスできない

とりあえず何もわからないので[Kubernetesリソース]を確認します。

え！？

アクセスできないだと・・・！？
よく読んでみたらそりゃそうですね。
プライベート環境に通信を閉じ込めたので、Azure内のリソースからかプライベートIPアドレス同士でリーチする環境からでないと無理です。
更にネットワークトポロジにも記載のネットワーク関連のURLにある他の記述からもAKSのリソースへプライベートIPアドレスで名前解決できる環境を構築しないといけませんと書いてあります。
Azure Bastionがあればこの手間は削減できるのですが、Azure BastionはAzureポータルにログインしないと利用できないという弱点もあります。
これは何が弱点かというと、AKSの利用ユーザとAzure Portalを利用できるユーザとが必ずしも一致しないことが考えられるからです。
Azure Bastionは確かに情報システム部やSIerにすれば便利な機能ですが、一般ユーザに開放する機能ではないかなというのが個人の見解です。
現状のIAMだとAzure Portalにログインできてしまうと、他のリソースやサービスの有無まで見えてしまいます。
Azure Blueprintを使い[拒否]のIAMを構成すれば制御も可能なのですが、そこまで手間をかけて一般ユーザにAzure BastionのためだけにAzure Portalを開放するメリットが私には見出せません。
またAzure Bastionも存在するだけで課金のかかるサービスですしね。

何より手元のクライアントマシンから利用できれば、それに越したことはありません。

解決策

今回公式ドキュメントに則ってAzure上にDNSサーバを構築し、手元のマシンが参照するルーターでDNS Recursive機能を有効にして対応しました。
構成図としてはこうなります。

Azure DNS Private ZoneがAzure上のリソースからのDNSリクエストしか受け付けてくれないので、泣く泣くAzure上にServer(10.242.0.132)を構築し、DNS Recursive構成にしています。
名前解決の経路としては赤矢印のようになります。

このような多段式のDNS Request/Responceとなります。
この構成にするために、AKSのあるVnet(仮想ネットワーク)に冒頭に記載してある通りGateway Subnetを構築します。

解決策実装

さっそくAKSのあるVnetにGateway Subnetを構築しましょう。

Vnetの設定確認

AKSの[概要]画面にも[サービスCIDR]とあったので、恐らく[10.0.0.0/16]くらいで切られているのであろう、とタカを括っていたのですが・・・

先ほど新規で構築した実際のVnetは以下のようになっていました。

いやいや・・・
10.0.0.0/8って・・・
クラスA全部ですやん・・・
そんな大雑把な切り方あります？
・・・しかもデプロイ中にこのVnetに関する設定パラメータ無かったですやん・・・
何か色々おかしくないですかね？
我が家(弊社)はネットワーク機器がたくさんあるんで、それぞれのネットワーク機器のバックボーンネットワークとしてクラスAの一部を切り出して使っています。
まぁ重複してますよね。
結果ルーティングできないのでネットワーク切りなおします。
これは敢えてサクッと行くように、さもここで気付いたかのようにしてますが、実際はGateway Subnetを切って、仮想ネットワークゲートウェイも作成して、サーバ専用セグメント切って、DNSサーバも日本語化してDNS機能も追加して、VPNも結べてからから気付いたんで、ネットワークの再構築にめちゃめちゃ時間かかりました。
まぁ最初にVnet確認しとけよって話なんですけどね。
いや、まさかクラスA全部とか大きすぎでしょ？(2回目)
しかも設定途中でパラメータ指定出てきませんし。(2回目)
ご存知の方は多いと思いますが念のために記載しておくと、仮想ネットワークゲートウェイはデプロイするのに最大45分かかります。
最近早くなったとはいえ、それでも結構時間かかります。
しかも仮想ネットワークゲートウェイ構築中は対象のネットワークに変更は一切かけれなくなります。