Azure Fundamentals · レッスン

Azure 向け Kubernetes の概念

Pod、Deployment、Service、Namespace など Kubernetes の基本的な構成要素を確認し、AKS がコントロールプレーンを代わりに管理する仕組みを理解します。

「Azure 向け Kubernetes の概念」はCoddyKit上の無料Azure Fundamentalsレッスンです。これはレッスン3/4です。下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。これはAzure Fundamentals学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 Azure Fundamentalsコースには全4レッスンが含まれています。

Kubernetes とは

Kubernetes (K8s) は、Google が開発したオープンソースのコンテナーオーケストレーションプラットフォームです。コンテナー化されたアプリケーションのデプロイ、スケーリング、管理を自動化します。コンテナーを手動で実行するのではなく、YAML マニフェストでアプリケーションの望ましい状態を宣言すると、Kubernetes は実際の状態を望ましい状態に一致させる処理を継続的に行います。たとえば、失敗したコンテナーの再起動、正常なノードへのワークロードのスケジュール、レプリカのスケーリングなどです。

クラスターアーキテクチャ: コントロールプレーンとノード

Kubernetes クラスターは、コントロールプレーンとワーカーノードで構成されます。コントロールプレーンには、API サーバー (すべての kubectl コマンドの入り口)、etcd (分散状態ストア)、スケジューラー (Pod をノードに割り当てるコンポーネント)、コントローラーマネージャー (望ましい状態を維持するコンポーネント) が含まれます。ワーカーノードでは、kubelet (ノードエージェント)、kube-proxy (ネットワークルール)、コンテナーランタイム (containerd) が動作します。AKS では Microsoft がコントロールプレーンを管理するため、ユーザーが管理するのはワーカーノードだけです。

# Kubernetes control plane components
# kube-apiserver    - REST API for all cluster operations
# etcd              - Distributed key-value store (cluster state)
# kube-scheduler    - Assigns pending pods to nodes
# kube-controller-manager  - Runs reconciliation controllers

# Worker node components
# kubelet           - Node agent, ensures containers run
# kube-proxy        - Network routing for services
# containerd        - Container runtime (runs containers)

Pod: デプロイ可能な最小単位

Pod は、Kubernetes におけるデプロイ可能な最小単位です。Pod は、ネットワーク名前空間 (同じ IP アドレス)、ストレージボリューム、ライフサイクルを共有する 1 つ以上のコンテナーをまとめたものです。Pod 内のコンテナーは localhost 経由で通信します。Pod は一時的なものであり、障害が発生すると、異なる IP アドレスを持つ新しい Pod に置き換えられます。通常、Pod を直接作成することはなく、Pod を管理する上位レベルのリソースを作成します。

# Simple pod manifest
apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: myapp
    image: mycontainerregistry.azurecr.io/myapp:v1.0
    ports:
    - containerPort: 80
    resources:
      requests:
        cpu: '100m'
        memory: '128Mi'
      limits:
        cpu: '500m'
        memory: '512Mi'

Deployment: ReplicaSet の管理

Deployment は、Kubernetes でステートレスアプリケーションを実行する標準的な方法です。Deployment は、同一の Pod レプリカを指定された数だけ維持する ReplicaSet を作成・管理します。Deployment は、古い Pod を新しい Pod に段階的に置き換えるローリングアップデートと、以前のバージョンへのロールバックをサポートしています。望ましい Pod テンプレートとレプリカ数を記述すれば、残りの処理は Kubernetes が行います。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1       # Create 1 extra pod during update
      maxUnavailable: 0 # Never reduce below desired count
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: mycontainerregistry.azurecr.io/myapp:v1.0
        ports:
        - containerPort: 80

Service: 安定したネットワークエンドポイント

Pod は一時的なもので IP アドレスも変わるため、Service は一致する Pod 全体にトラフィックを負荷分散する、安定したネットワークエンドポイントを提供します。Service はラベルセレクターを使用して Pod を検索します。Service の種類には、ClusterIP (内部アクセスのみ、既定値)、NodePort (すべてのノードでポートを公開)、LoadBalancer (パブリック IP を持つ Azure Load Balancer をプロビジョニング)、ExternalName (外部サービスへの DNS エイリアス) があります。

# Service exposing myapp pods externally
apiVersion: v1
kind: Service
metadata:
  name: myapp-svc
spec:
  type: LoadBalancer  # Creates Azure Load Balancer
  selector:
    app: myapp        # Routes traffic to pods with this label
  ports:
  - port: 80          # Service port
    targetPort: 80    # Pod/container port

# After creation, check the EXTERNAL-IP (Azure LB public IP)
# kubectl get service myapp-svc

マルチテナント環境のための Namespace

Namespace は、1 つの Kubernetes クラスターを複数の仮想クラスターに分割します。異なる Namespace のリソースは名前によって分離されるため、development と production の両方の Namespace に myapp Deployment を同時に配置できます。Namespace は、チームや環境に RBAC、リソースクォータ、ネットワークポリシーを適用するための主要な単位です。既定の Namespace には、default、kube-system、kube-public があります。

# Create a namespace for the dev team
kubectl create namespace dev-team

# Deploy into a specific namespace
kubectl apply -f deployment.yaml --namespace dev-team

# List all resources in a namespace
kubectl get all --namespace dev-team

# Set default namespace for current context
kubectl config set-context --current --namespace dev-team

ConfigMap と Secret

ConfigMap は、機密性のない構成データをキーと値のペアまたはファイルとして保存し、環境変数またはボリュームマウントとして Pod に注入します。Secret は機密データ (パスワードやトークン) を Base64 エンコードして保存します (既定では暗号化されないため、保存時の真の暗号化には Azure Key Vault Provider for Secrets Store CSI Driver を使用してください)。どちらも Namespace のスコープに属し、Pod 仕様では名前で参照します。

# Create a ConfigMap from literal values
kubectl create configmap app-config \
  --from-literal=APP_ENV=production \
  --from-literal=LOG_LEVEL=info

# Create a Secret
kubectl create secret generic db-secret \
  --from-literal=DB_PASSWORD='super-secret'

# Reference in a pod spec
# env:
# - name: APP_ENV
#   valueFrom:
#     configMapKeyRef:
#       name: app-config
#       key: APP_ENV
# - name: DB_PASSWORD
#   valueFrom:
#     secretKeyRef:
#       name: db-secret
#       key: DB_PASSWORD

Azure の Persistent Volume

ステートフルアプリケーションには、個々の Pod より長く存続するストレージが必要です。Kubernetes は PersistentVolume (PV) と PersistentVolumeClaim (PVC) を使用して、ストレージと Pod のライフサイクルを分離します。AKS では、組み込みの Azure Disk および Azure Files ストレージクラスにより、PVC の作成時にマネージドディスクとファイル共有が自動的にプロビジョニングされます。Azure Disk は単一 Pod からのアクセス用で、Azure Files は複数の Pod による同時読み取り・書き込みをサポートします。

# PersistentVolumeClaim using Azure Disk
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-disk-pvc
spec:
  accessModes:
  - ReadWriteOnce   # Single-node read/write (Azure Disk)
  storageClassName: managed-csi
  resources:
    requests:
      storage: 10Gi

# Mount in a pod
# volumes:
# - name: data
#   persistentVolumeClaim:
#     claimName: my-disk-pvc
# volumeMounts:
# - name: data
#   mountPath: /data

Horizontal Pod Autoscaler

Horizontal Pod Autoscaler (HPA) は、観測された CPU やメモリの使用率、またはカスタムメトリックに基づいて、Deployment の Pod レプリカ数を自動的に調整します。HPA コントローラーは 15 秒ごとにメトリックサーバーへ問い合わせ、使用率を目標値付近に維持するようにレプリカをスケールアップまたはスケールダウンします。暴走したスケーリングを防ぐため、最小レプリカ数と最大レプリカ数を上限・下限として設定します。

# Create an HPA targeting 50% CPU utilisation
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: myapp-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp
  minReplicas: 2
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

正常性チェック: Liveness Probe と Readiness Probe

Kubernetes はプローブを使用してコンテナーの正常性を監視します。liveness probe はコンテナーが実行中かどうかを確認し、失敗すると Kubernetes がコンテナーを再起動します。readiness probe はコンテナーがトラフィックを処理できる状態かどうかを確認し、失敗すると、コンテナーを再起動せずに Pod を Service の負荷分散対象から除外します。startup probe はアプリケーションの初期化が完了するまで他のプローブを遅延させ、起動に時間がかかる場合の早すぎる再起動を防ぎます。

livenessProbe:
  httpGet:
    path: /health
    port: 80
  initialDelaySeconds: 15
  periodSeconds: 20
  failureThreshold: 3

readinessProbe:
  httpGet:
    path: /ready
    port: 80
  initialDelaySeconds: 5
  periodSeconds: 10
  failureThreshold: 3

startupProbe:
  httpGet:
    path: /startup
    port: 80
  failureThreshold: 30
  periodSeconds: 10  # Allow 300s for slow startup

リソース要求と制限

Kubernetes の各コンテナーでは、リソース要求 (スケジューラーが使用する、最低限保証された割り当て) と制限 (超過するとコンテナーがスロットリングまたは強制終了される最大値) を宣言する必要があります。CPU の要求値はミリコア (m) で指定し、1000m = 1 CPU コアです。要求値と制限値を正確に設定すると、ノイジーネイバー問題を防ぎ、リソースを過剰に割り当てることなく、スケジューラーが Pod をノード上に効率的に配置できるようになります。

resources:
  requests:
    cpu: '250m'      # 0.25 CPU core guaranteed
    memory: '256Mi'  # 256 MiB guaranteed
  limits:
    cpu: '1'         # Max 1 CPU core
    memory: '512Mi'  # Max 512 MiB (OOMKilled if exceeded)

理解度チェック

このレッスンで学んだ Microsoft Azure Fundamentals（AZ-900）の概念について、理解度を確認します。

レッスンのまとめ

このレッスンでは、ポッドがネットワークとストレージを共有する、デプロイ可能な最小単位であること、Deploymentsがローリングアップデートに対応したステートレスなレプリカセットを管理すること、そしてServicesが一時的なポッド間でトラフィックを負荷分散する安定したエンドポイントを提供することを学びました。次は、AKS でワークロードをデプロイする方法を学びます。

よくある質問