【AKS実践】ACRの自作イメージをNamespaceで整理してデプロイする

Azure

AKSでクラスターを作り、公式のNginxを動かすところまでは前回の記事でやりました。でも実際の開発では、「自分たちで作ったアプリのイメージ」をデプロイしたいはずです。

そのとき出てくるのが、次の2つの疑問です。

「自作イメージってどこに置くの？AKSはどうやって取ってくるの？」

「開発用と本番用、同じクラスターの中でどうやって分けるの？」

この記事では、この2つを解決するACR（Azure Container Registry）連携とNamespace（名前空間）を、手を動かしながら理解していきます。読み終わるころには、「自作イメージを、環境ごとに整理してAKSにデプロイする」流れが自分でできるようになります。

なお、AKSそのものの概念がまだあやふやな方は、先に 【図解】Azure Kubernetes Service（AKS）とは？ と クラスター構築→Nginx公開手順 を読んでおくとスムーズです。

この記事で作る全体像

いきなり手順に入る前に、これから作るものの地図を頭に入れておきましょう。登場人物は3つだけです。

  • ACR（Azure Container Registry）：自作したDockerイメージを保管しておく「倉庫」。Azure上のプライベートなDocker Hubのようなものです。
  • AKS：その倉庫からイメージを取り出して動かす「工場」。
  • Namespace：工場の中を「開発ライン」「本番ライン」のように仕切るための「間仕切り」。

つまりこの記事の流れは、「倉庫を用意する → 工場と倉庫をつなぐ → 工場の中を間仕切りする → 間仕切りごとにアプリを置く」という順番になります。

前提：この記事で使うもの

  • Azure CLI（az）がインストール・ログイン済みであること
  • AKSクラスターが1つ作成済みであること（作り方は前回記事を参照）
  • kubectl が使えること

この記事では、リソースグループを rg-aks-demo、AKS名を aks-demo として進めます。ご自身の環境に合わせて読み替えてください。

STEP1：ACR（コンテナの倉庫）を作る

まずは自作イメージの置き場所となるACRを作成します。ACR名はAzure全体で一意である必要があるので、かぶらない名前をつけてください（ここでは acrdemo0303 とします）。

az acr create \
  --resource-group rg-aks-demo \
  --name acrdemo0303 \
  --sku Basic

--sku Basic は一番安いプランです。学習用途ならこれで十分。本番で地理冗長（複数リージョンにレプリケート）が必要になったら Premium を検討します。

STEP2：イメージをビルドしてACRに置く

次に、動かすアプリのイメージを用意します。ここで嬉しいのが、手元にDockerが入っていなくても、ACRがクラウド上でビルドしてくれるという点です。az acr build を使います。

今回はサンプルとして、Azure公式が提供している小さなWebアプリ（azure-vote のようなイメージ）を使わず、ごく簡単な自作イメージを想定します。カレントディレクトリに Dockerfile がある状態で、次を実行します。

az acr build \
  --registry acrdemo0303 \
  --image myapp:v1 \
  .
  • --image myapp:v1：イメージ名とタグ。:v1 のようにバージョンを付けておくと、あとで更新（ローリングアップデート）するときに効いてきます。
  • 末尾の .：ビルドコンテキスト（Dockerfileのある場所）です。

完了したら、ちゃんと倉庫に入ったか確認しましょう。

az acr repository list --name acrdemo0303 --output table

myapp が表示されればOKです。

STEP3：AKSとACRをつなぐ（–attach-acr）

ここが今回の一番のポイントです。倉庫（ACR）を作っただけでは、工場（AKS）は勝手にイメージを取り出せません。「この倉庫から取っていいよ」という許可（認証）を渡す必要があります。

初心者がつまずきやすいのがこの認証まわりですが、AKSにはたった1コマンドで連携できる仕組みが用意されています。それが --attach-acr です。

az aks update \
  --resource-group rg-aks-demo \
  --name aks-demo \
  --attach-acr acrdemo0303

これだけです。裏側では、AKSが使っているマネージドID（Managed Identity）に対して、ACRからイメージをプルする権限（AcrPullロール）が自動で付与されます。ImagePullSecret を手作業で作る必要はありません。

クラスター作成時に az aks create の段階で --attach-acr を付けてしまう手もあります。あとから連携するなら az aks update、というだけの違いです。

STEP4：Namespace（間仕切り）で環境を分ける

いよいよNamespaceです。まずは「なぜ必要なのか」から。

Namespaceは「クラスターの中の仮想的な部屋」

1つのAKSクラスターに、開発用のアプリと本番用のアプリをそのまま入れると、名前がぶつかったり、間違って本番を触ってしまったりします。そこでクラスターの中を「部屋」で仕切るのがNamespaceです。

同じ myapp という名前のDeploymentでも、dev という部屋と prod という部屋にあれば、別物として共存できます。マンションで言えば、201号室の田中さんと301号室の田中さんが別人なのと同じイメージです。

Namespaceを作る

kubectl create namespace dev
kubectl create namespace prod

作られたか確認します。

kubectl get namespace

dev と prod のほかに、default や kube-system という部屋も見えるはずです。kube-system はKubernetes自身が使う大事な部屋なので、基本的に触りません。

STEP5：Namespaceを指定して自作イメージをデプロイ

準備が整いました。ACRの自作イメージを、dev という部屋にデプロイしてみましょう。次のマニフェスト（deployment.yaml）を用意します。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
  namespace: dev
spec:
  replicas: 2
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: acrdemo0303.azurecr.io/myapp:v1
        ports:
        - containerPort: 80

ポイントは2つです。

  • namespace: dev：このアプリを dev の部屋に置く、という指定。
  • image: acrdemo0303.azurecr.io/myapp:v1：イメージの場所。ACRのログインサーバー名（〜.azurecr.io）から書くのがポイントです。ここを間違えると Docker Hub を見に行ってしまいます。

適用します。

kubectl apply -f deployment.yaml

ちゃんと dev の部屋で動いているか、-n dev を付けて確認します。

kubectl get pods -n dev

2つのPodが Running になっていれば成功です。ここで -n dev を付け忘れると default の部屋を見てしまい「Podが無い！」と焦るので注意しましょう。

プルできない…となったときのチェックポイント

もしPodが ImagePullBackOff や ErrImagePull になったら、原因はほぼこの3つです。

  1. –attach-acr を忘れている（STEP3）。→ もう一度実行。
  2. イメージ名のスペルミス。特に .azurecr.io のログインサーバー名。
  3. タグ違い。:v1 で作ったのに :latest を指定している、など。

詳しい原因は kubectl describe pod <Pod名> -n dev の Events 欄に書いてあります。エラーが出たらまずここを見る、と覚えておくと運用でも役立ちます。

おまけ：毎回 -n を付けるのが面倒なとき

dev の部屋で作業し続けるなら、デフォルトの部屋を切り替えておくと -n dev を省略できます。

kubectl config set-context --current --namespace=dev

以降、kubectl get pods だけで dev の中身が見えます。本番を触るときは --namespace=prod に戻すのを忘れずに。この一手間が、事故防止につながります。

まとめ

この記事では、AKSで自作イメージを環境ごとに整理してデプロイする流れを見てきました。

  • ACR：自作イメージの倉庫。az acr build ならDocker不要でクラウドビルドできる。
  • –attach-acr：AKSとACRを1コマンドで連携。認証の面倒を肩代わりしてくれる。
  • Namespace：クラスターの中を部屋で仕切る仕組み。dev / prod で事故を防ぐ。
  • 操作時は -n <namespace> を意識する。忘れると「Podが無い」の落とし穴に。

これで「動かすアプリを用意して、整理して置く」ところまでできました。次はいよいよ運用の花形、アクセスが増えたときに自動でスケールさせる（HPA・Cluster Autoscaler）方法を見ていきます。

あわせて読みたい：

タイトルとURLをコピーしました