Azure Kubernetesにアプリをデプロイ~Kubernetesのチュートリアルをはじめから丁寧に②~
今回取り組むチュートリアルはこちら
前回はローカルでコンテナイメージを作成して、Azure Container Registoryへプッシュしました。
今回はAKSへデプロイして動かしてみたいと思います。
Azure Kubernetesクラスタの作成とアプリのデプロイ
チュートリアルでは例によってコマンドラインからデプロイをしていますが、個人的には勉強するときはポータル画面上からやった方が理解しやすいのではないかと思っています。なのでクラスタの作成とアプリのデプロイをまとめてポータル画面でやってしまいましょう。
早速取り掛かりたいところですが、まずは基本の用語を理解する必要があります。AKSは以下のような構成となっています。
コントロールプレーンはAzureの担当になっており、ユーザーで設定をいじることは出来ません。私たちはノード側をメインで操作していくことになります。意識したいのは、ノードの中にポッド(コンテナ)を作るという事です。これから行う設定が、どっちのサーバの設定をしているのかを意識しながら行いましょう。
まずはAKSクラスタを作成していきましょう。AKSクラスタはAKSを作るときの一番大きな箱です。基本タブは以下の通りです。特に注意することはなく、いずれも無料プランや推奨されるサービスを選択します。
つづいてノードプールタブです。これはAKS構成図でいうノードを格納するプールの設定になります。
agentpoolというのは既定で作成されるノードプールで、下図のような設定になっています。(agentpoolをクリックすると見られる+変更できます)。プライマリプールになるこのノードプールは、システム関連で必要になるシステムポッドを含む必要があり、それにはLinuxサーバーである必要があるみたいです。つまり、windowsサーバを使いたい時は新しくノードプールを作成しろという事でしょうね。また、ノードサイズはノードプール全体に割り当てるサーバサイズのようです。(ちなみに私は制限に引っかかったので2vCPU,4GBにしました)
続いてネットワークタブです。これもほぼ規定通りですが、ネットワーク構成だけはkubenetにしてみます。この設定はポッド(コンテナ)に割り当てるIPアドレスをどうするかという設定です。kubenetにすると、ノードサーバはAzureの仮想ネットワークからIPアドレスの払い出しが行われますが、ポッドは独自のアドレス空間(ローカルIPに近いイメージ)から払い出されます。外部通信の際はNATによってアドレス変換されて通信が行われます。CNIは対照的にポッドも同じ仮想ネットワークのアドレス空間から払い出されます。
統合タブでは作成済みのACRを選択します。
残りのタブは既定のままにしておきます。監視については色々設定を試してしてみたい部分はありますが、今回はやめておきましょう。
検証が終わったらデプロイします。
作成後のリソース画面ではノードプールの設定やネットワークなど色々確認出来ますが、ひとまずコンテナを動かすための作業を行いましょう。(意外とポータル画面のアイコンや項目を触るだけで勉強になったりします。コマンドでチュートリアルやらずにGUIでやるメリットはここにあると思います)
コンテナをアプリとしてデプロイするには「概要」→「作成」→「YAMLの適用」タブから行います。流石に一つひとつデプロイするのは厳しいので、ここは付属のymalファイル「aks-store-quickstart.yaml」を利用します(前回のチュートリアルでクローン済み)。このymalファイルはAKSにコンテナをデプロイするときの設定を書き込んだファイルです。非常に長いので詳細は割愛しますが、後ほど少しだけ内容を実際のデプロイ結果と合わせて確認します。
注意点としてyamlの中のfront,order,productのイメージ名をACRのレジストリ名に変更する事です。でないとイメージが正しくプルできません。
修正したyamlを張り付けて追加ボタンを押すと勝手にデプロイされます。確認するには「サービスとイングレス」タブの「store-front」にある外部IPを押すとローカルで見た画面が実際のweb画面として表示できます。
さて、予定していたチュートリアル3,4の内容は上記で終了ですが、肝心のyamlファイルの説明を省略してしまいました。ここではおまけとして、yamlファイルでデプロイした内容をざっくりポータル画面で確認します。長いので例としてstore-frontのポッドのみを表示して確認することとします。
まず、”conatiners”タグです。このタグには使用イメージや解放ポート、リソース(cpu,メモリ)、死活監視設定が記述されています。例えばstore-frontでは以下のように記述されています。
containers:
- name: store-front
image: tutorial2024.azurecr.io/aks-store-demo-store-front:1.0
ports:
- containerPort: 8080
name: store-front
env:
- name: VUE_APP_ORDER_SERVICE_URL
value: "http://order-service:3000/"
- name: VUE_APP_PRODUCT_SERVICE_URL
value: "http://product-service:3002/"
resources:
requests:
cpu: 1m
memory: 200Mi
limits:
cpu: 1000m
memory: 512Mi
startupProbe:
httpGet:
path: /health
port: 8080
failureThreshold: 3
initialDelaySeconds: 5
periodSeconds: 5
readinessProbe:
httpGet:
path: /health
port: 8080
failureThreshold: 3
initialDelaySeconds: 3
periodSeconds: 3
livenessProbe:
httpGet:
path: /health
port: 8080
failureThreshold: 5
initialDelaySeconds: 3
periodSeconds: 3
確認してみましょう。確認する場所はサービスとイングレスを辿っていった場所になります(下図のパンくずリストで参照)。各コンテナの設定は「ノードプール」→「ノード」→「ポッド」の中にいくつもポッド(コンテナ)の詳細があり、そこから確認する事が出来ます。(図中のパンくずリスト参照)
以下では使用したイメージ、環境変数を確認できます。ちゃんとyamlで指定した通り、ACRのstore-front:1.0を使用していますし、環境変数も”env”タグで示されている通りの値が表示されていますね。
「ライブログ」では、正常性チェックの設定を確認できます。LogAnalyticsで収集するようなメトリクスが確認できます。ちゃんと指定されたコマンドで正常性を確認していますね。
ネットワーク設定についても確認します。”container”タグの後に以下のような記述があります。これはstore-frontアプリに対してロードバランサーの80番ポートを内部コンテナの8080番につなぐ、という意味です。
apiVersion: v1
kind: Service
metadata:
name: store-front
spec:
ports:
- port: 80
targetPort: 8080
selector:
app: store-front
type: LoadBalancer
一方でproduct serviceの場合は
apiVersion: v1
kind: Service
metadata:
name: product-service
spec:
type: ClusterIP
ports:
- name: http
port: 3002
targetPort: 3002
selector:
app: product-service*
となっており、typeがロードバランサーではなくクラスターIPとなっていますね。つまり、外部IPではなくKubernetes内のIPを付与するという事になります。それぞれサービスから確認出来ます。
余談ですが、実はノードの中のポッドには、見知らぬポッドがいくつも立ち上がっています。
K8sを使う際にはビギナーの私が思うよりもはるかにたくさんのリソースで構成されて複雑なつくりをしている事が分かります。ただ、今回はチュートリアルなのでそれらの解説は専門家に譲るとして我々の関係ありそうなリソースの把握につとめました。
ともかくAKSは、クラスター→ノードプール→ノード→ポッド(コンテナ)という構成であることを理解できればと思います。
という事で、AKSでコンテナを立ち上げてみました。なんとなーくどんなリソースが中で動いているか体験してもらえたでしょうか。次回はマニュフェストファイルを用いてService busと連携するそうです。