AKSクラスタとデモアプリケーションがAzureにどのように展開されたのかをKubernetes内部も含めて確認

この記事の内容

  • AKSのネットワーク構成（kubenet）において、PodネットワークとサービスネットワークがAzure VNetとどのように分離されているかを解説します
  • デプロイメント・レプリカセット・サービスといったKubernetesリソースの役割と相互関係を確認します
  • YAMLファイルの定義内容とAKSポータル画面の表示がどのように対応しているかを照らし合わせます
  • フロントエンドとバックエンドの2コンポーネント構成アプリケーションが、内部でどのように通信しているかを追います
  • kubectl get all コマンドで全リソースをまとめて確認する方法を紹介します

AKSのネットワーク構成（kubenet）

今回は規定の設定でAKSクラスタを作成したため、ネットワーク構成のタイプは kubenet になっています。kubenetにはほかにもタイプがあり、選択によって構成が変わりますが、今回は最もシンプルな構成です。

kubenetでは、KubernetesクラスタはNAT（ネットワークアドレス変換）を介してAzureの仮想ネットワーク（VNet）側と通信します。つまり、AzureのVNetとKubernetes内部のネットワークは完全に切り離されており、NATによって相互通信が実現されています。

Kubernetes内部には、大きく2つのネットワークが存在します。

ネットワークCIDRブロック
サービス用ネットワーク10.0.0.0/16
Pod用ネットワーク10.244.0.0/16

この設定はAKSのネットワークプロファイルから確認できます。

種PS類oedrvCiIcDeRCID:Rk::ub11e00n..e20t4.40..00./01/616

Pod用ネットワークの中にPodが配置され、そのPodの中で1つ以上のコンテナが動作します。概念的には、Podは1つの仮想マシンに近いイメージで捉えると理解しやすいです。PodはIPアドレスと名前を持ちます。

Serviceリソースの役割

Kubernetesの Service は、特定の役割を持つPodへのアクセスを安定的に提供するための仕組みです。

Podはスケールアウト・スケールインや障害によって頻繁に生成・削除され、IPアドレスも変化し続けます。Serviceは、こうした変化するPodへのアクセスを固定的なエンドポイントとして提供し、ロードバランサーとして目的のPodにトラフィックを転送します。

デモアプリケーションの構成

今回展開したアプリケーションは、以下の2つのコンポーネントで構成されています。

  • azure-vote-front（フロントエンド）
  • azure-vote-back（バックエンド）

それぞれのコンポーネントに対してDeploymentとServiceが定義されており、合計4つのKubernetesリソースによってアプリケーションが動作しています。

YAMLファイルとAKSリソースの対応確認

azure-vote-back の Deployment

YAMLファイルの最初のセクションには、azure-vote-back のDeploymentが定義されています。

kind: Deployment
metadata:
  name: azure-vote-back
spec:
  replicas: 1
  selector:
    matchLabels:
      app: azure-vote-back
  template:
    spec:
      containers:
      - name: azure-vote-back
        image: <redis image>
        resources:
          ...
        ports:
        - containerPort: 6379

AKSポータルの「ワークロード → デプロイ」画面では、azure-vote-back が表示されており、セレクターとして app=azure-vote-back が設定されています。レプリカ数は1で、Podは 10.244.1.7 というIPアドレスを持ち、該当ノード上で稼働しています。

レプリカセットは、指定した数のPodのレプリカが常に稼働していることを保証するリソースです。Podが落ちた場合でも自動的に再起動し、指定した数を維持し続けます。

azure-vote-back の Service（ClusterIP）

YAMLファイルの次のセクションには、azure-vote-back 向けのServiceが定義されています。

kind: Service
metadata:
  name: azure-vote-back
spec:
  type: ClusterIP
  ports:
  - port: 6379
    targetPort: 6379
  selector:
    app: azure-vote-back

このServiceのタイプは ClusterIP です。ClusterIPはクラスター内部からのみアクセス可能で、外部からはアクセスできません。自動的にIPアドレス（例：10.0.33.21）が割り当てられ、このIPの6379番ポートへのアクセスが 10.244.1.7:6379 のPodに転送されます。

azure-vote-front の Deployment

kind: Deployment
metadata:
  name: azure-vote-front
spec:
  replicas: 1
  selector:
    matchLabels:
      app: azure-vote-front
  template:
    spec:
      containers:
      - name: azure-vote-front
        image: <azure-vote-front:v1>
        ports:
        - containerPort: 80
        env:
        - name: REDIS
          value: "azure-vote-back"

フロントエンドのコンテナには、バックエンドのホスト名として azure-vote-back を環境変数 REDIS で渡しています。これにより、フロントエンドPodはバックエンドの名前解決を内部DNS経由で行えます。

AKSポータルでも azure-vote-front のDeploymentが確認でき、セレクターとして app=azure-vote-front が設定されています。Podは1つ稼働中で、IPアドレスとノード情報が表示されています。

azure-vote-front の Service（LoadBalancer）

kind: Service
metadata:
  name: azure-vote-front
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: azure-vote-front

フロントエンドはインターネット越しにアクセスさせたいため、Serviceのタイプは LoadBalancer です。これによりAzureのロードバランサーが作成され、パブリックIPアドレスが割り当てられます。80番ポートへのアクセスが app=azure-vote-front というセレクターを持つPodに転送されます。

なお、正常性プローブの設定などはYAMLファイルに記述しなくても、Azureが自動的に構成してくれます。

アプリケーションのアクセスフロー

ブラウザからアプリケーションにアクセスする際のフローは以下のとおりです。

ブLaCaaラ↓o↓z↓l↓z↓zウauuuuザイdセrバsセr処rンBレeッtレe理eタaク-クeク-結-ーlタvエrタv果vネaーoンIーoをoッntドPt返tトcaeへ（aeすe経ep-のap--由rpf名zpbf（（=r前u=ar外aao解raco部zzn決ezknIuut（-utPrravrPアeePzoeoPド--out-doレvvdrev（dスoo（e-o6:tt8-bt3→8ee0vae70--番oc-9ブ）ffポtkb番ラrrーeaポウooト-Scーザnnでbekトへtt待arでレ受cvで待スSで）kiル受ポeルcー）ンrー→eテスvテ）ィiィ1ンcン0グeグ.）0.33.21）

フロントエンドPodが環境変数で受け取った azure-vote-back という名前は、Kubernetes内部のDNSによってClusterIPのIPアドレス（10.0.33.21）に名前解決されます。そこからServiceを通じてバックエンドPodに到達し、処理結果が返されます。

kubectl get all で全リソースを確認

全体の構成を理解したうえで、Azure Cloud ShellからKubernetes内の全リソースをまとめて確認してみましょう。

kubectl get all

実行結果には以下のリソースが表示されます。

  • Pod：azure-vote-front と azure-vote-back の2つ
  • Service：ClusterIPの azure-vote-back と、外部IPを持つLoadBalancerの azure-vote-front の2つ
  • Deployment：azure-vote-front と azure-vote-back の2つ
  • ReplicaSet：上記Deploymentに対応する2つ

ポータル画面であちこちクリックして確認するよりも、このコマンド1つで全体像をすっきり把握できます。構成を理解してから見ると、各リソースが端的に表現されており、非常に見通しよく確認できます。

まとめ

この記事では、AKSクラスタ上で動作するデモアプリケーションの内部構造をYAMLファイルとポータル画面を照らし合わせながら確認しました。

  • AKSのkubenet構成では、Kubernetes内部ネットワーク（PodとService）はAzure VNetとNATで切り離されています
  • Deployment はPodの展開を定義し、ReplicaSet が指定数のPodを常に維持します
  • Service（ClusterIP） はクラスター内部専用のエンドポイントを提供し、Service（LoadBalancer） はインターネット経由のアクセスを可能にします
  • フロントエンドとバックエンドの通信は、環境変数で渡したService名をKubernetes内部DNSで名前解決することで実現されています
  • kubectl get all を使うことで、稼働中の全リソースをコマンド一発で確認できます

YAMLファイルの定義とKubernetesリソースの対応関係を把握することで、AKSの動作原理をより深く理解できるようになります。