Kubernetes Engine を使用して、リージョン永続ディスクにアプリをデプロイする

このチュートリアルでは、Google Kubernetes Engine のリージョン永続ディスクを使用して WordPress をデプロイすることで、高可用性アプリをデプロイする方法を説明します。リージョン永続ディスクでは、2 つのゾーンの間で同期レプリケーションが行われます。

リージョン永続ディスクでは、2 つのゾーンの間で同期レプリケーションが行われます。

目標

  • GKE のリージョン クラスタを作成します。
  • 複製されたゾーン用に構成された Kubernetes StorageClass リソースを作成します。
  • StorageClass を使用するリージョン ディスクで WordPress をデプロイします。
  • ノードを削除してゾーンの障害をシミュレーションします。
  • WordPress アプリケーションとデータが別の複製ゾーンへ正常に移行されたことを確認します。

料金

このチュートリアルでは、課金対象である次の Google Cloud コンポーネントを使用します。

料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。新しい Google Cloud ユーザーは無料トライアルをご利用いただけます。

始める前に

  1. Google アカウントにログインします。

    Google アカウントをまだお持ちでない場合は、新しいアカウントを登録します。

  2. Google Cloud Console の [プロジェクト セレクタ] ページで、Google Cloud プロジェクトを選択または作成します。

    [プロジェクトの選択] ページに移動

  3. Cloud プロジェクトに対して課金が有効になっていることを確認します。プロジェクトに対して課金が有効になっていることを確認する方法を学習する

  4. Compute Engine and GKE API を有効にします。

    API を有効にする

GKE クラスタの作成

  1. Cloud Shell を開きます。

    Cloud Shell を開く

    このチュートリアルの以降の部分は Cloud Shell から実行します。

  2. us-west1 リージョンの 2 つのゾーンにまたがるリージョン GKE クラスタを作成します。

    CLUSTER_VERSION=$(gcloud beta container get-server-config --region us-west1 --format='value(validMasterVersions[0])')
    
    export CLOUDSDK_CONTAINER_USE_V1_API_CLIENT=false
    gcloud beta container clusters create repd \
      --cluster-version=${CLUSTER_VERSION} \
      --machine-type=n1-standard-4 \
      --region=us-west1 \
      --num-nodes=1 \
      --node-locations=us-west1-b,us-west1-c
    

これで、各ゾーンに 1 つのノードを持つリージョン クラスタが作成されました。また、gcloud コマンドにより、クラスタに接続するように kubectl コマンドが自動的に構成されました。

リージョン ディスクを使用したアプリのデプロイ

このセクションでは、Helm をインストールし、リージョン永続ディスクによって使用される Kubernetes StorageClass を作成して、WordPress をデプロイします。

Helm をインストールして初期化し、グラフ パッケージをインストールする

Helm とともにインストールされるグラフ パッケージには、WordPress を実行するために必要なすべてのものが含まれています。

  1. Cloud Shell インスタンスでローカル側に Helm をインストールします。

    curl https://raw.githubusercontent.com/kubernetes/helm/master/scripts/get > get_helm.sh
    chmod 700 get_helm.sh
    ./get_helm.sh
    
  2. Helm を初期化します。

    kubectl create serviceaccount tiller --namespace kube-system
    kubectl create clusterrolebinding tiller-cluster-rule \
      --clusterrole=cluster-admin \
      --serviceaccount=kube-system:tiller
    helm init --service-account=tiller
    until (helm version --tiller-connection-timeout=1 >/dev/null 2>&1); do echo "Waiting for tiller install..."; sleep 2; done && echo "Helm install complete"
    

これで、Helm がクラスタにインストールされました。

StorageClass を作成する

このセクションでは、グラフで使用される StorageClass を作成し、リージョン ディスクのゾーンを定義します。StorageClass にリストされるゾーンは、GKE クラスタのゾーンと一致します。

  1. リージョン ディスク用の StorageClass を作成します。

    kubectl apply -f - <<EOF
    kind: StorageClass
    apiVersion: storage.k8s.io/v1
    metadata:
      name: repd-west1-b-c
    provisioner: kubernetes.io/gce-pd
    parameters:
      type: pd-standard
      replication-type: regional-pd
    volumeBindingMode: WaitForFirstConsumer
    allowedTopologies:
    - matchLabelExpressions:
      - key: failure-domain.beta.kubernetes.io/zone
        values:
        - europe-west1-b
        - europe-west1-c
    EOF
    

これで、us-west1-b ゾーンと us-west1-c ゾーンに複製される PersistentVolumes をプロビジョニングできる StorageClass が作成されました。

WordPress をデプロイする

このセクションでは、Kubernetes によって、一方の可用性ゾーンにある適切なノードに永続ディスクが自動接続されます。

  1. 前の手順で作成した StorageClass を使用するように構成されている WordPress グラフをデプロイします。

    helm install --name wp-repd \
      --set persistence.storageClass=repd-west1-b-c \
      stable/wordpress \
      --set mariadb.persistence.storageClass=repd-west1-b-c
    
  2. 次のコマンドを実行します。これは、サービス ロードバランサの外部 IP アドレスが作成されるまで待ってから実行されます。

    while [[ -z $SERVICE_IP ]]; do SERVICE_IP=$(kubectl get svc wp-repd-wordpress -o jsonpath='{.status.loadBalancer.ingress[].ip}'); echo "Waiting for service external IP..."; sleep 2; done; echo http://$SERVICE_IP/admin
    
  3. 永続ディスクが作成されたことを確認します。

    while [[ -z $PV ]]; do PV=$(kubectl get pvc wp-repd-wordpress -o jsonpath='{.spec.volumeName}'); echo "Waiting for PV..."; sleep 2; done
    
    kubectl describe pv $PV
    
  4. コマンド出力に表示されたリンクから、ブラウザで WordPress 管理者ページを開きます。

    echo http://$SERVICE_IP/admin
  5. コマンド出力に表示されたユーザー名とパスワードでログインします。

    cat - <<EOF
    Username: user
    Password: $(kubectl get secret --namespace default wp-repd-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode)
    EOF
    

これで、WordPress の有効なデプロイが行われ、2 つのゾーンにあるリージョン永続ディスクでバックアップされるようになりました。

ゾーン障害をシミュレーションする

このセクションでは、ゾーン障害をシミュレーションして、Kubernetes によってワークロードが他のゾーンに移動され、リージョン ディスクが新しいノードに接続されることを確認します。

  1. WordPress ポッドの現在のノードを取得します。

    NODE=$(kubectl get pods -l app=wp-repd-wordpress -o jsonpath='{.items..spec.nodeName}')
    
    ZONE=$(kubectl get node $NODE -o jsonpath="{.metadata.labels['failure-domain\.beta\.kubernetes\.io/zone']}")
    
    IG=$(gcloud compute instance-groups list --filter="name~gke-repd-default-pool zone:(${ZONE})" --format='value(name)')
    
    echo "Pod is currently on node ${NODE}"
    
    echo "Instance group to delete: ${IG} for zone: ${ZONE}"
    
  2. WordPress ポッドが実行されているノードのインスタンス グループを削除して、ゾーン障害をシミュレーションします。

    gcloud compute instance-groups managed delete ${IG} --zone ${ZONE}
  3. WordPress ポッドと永続ボリュームの両方が、別のゾーンにあるノードに移行されたことを確認します。

    kubectl get pods -l app=wp-repd-wordpress -o wide

    表示されているノードが、前の手順のノードと異なっていることを確認します。

  4. コマンド出力に表示されたリンクから、ブラウザで WordPress 管理者ページを開きます。

    echo http://$SERVICE_IP/admin

    異なるゾーンにあるノードにリージョン永続ディスクが接続されました。

クリーンアップ

このチュートリアルで使用するリソースについて、Google Cloud Platform アカウントに課金されないようにする手順は次のとおりです。

  1. WordPress アプリと永続ディスクを削除します。

    helm delete --purge wp-repd
  2. すべての永続ボリュームが削除されるまで待ちます。

    while [[ $(kubectl get pv  | wc -l) -gt 0 ]]; do echo "Waiting for PV deletion..."; sleep 2; done
  3. GKE クラスタを削除します。

    export CLOUDSDK_CONTAINER_USE_V1_API_CLIENT=false
    gcloud beta container clusters delete repd --region=us-west1

次のステップ