Kubernetesクラスタ構築＆アプリケーションデプロイ
ここからは、これまで掴んだ内容を基にKubernetesクラスタを構築して、サンプルアプリケーションとしてWordPressを動かす流れを見ていきます。
クラスタ構築
Kubernetesのクラスタ構築は、以下にあるような全てを1から構築する方法やKubeadmのようなクラスタ構築ツールを利用する方法、マネージドサービスを利用する方法があります。
セッション時に実施したデモでは、Oracle Container Engine for Kubernetes(以降、OKEと略称)を利用しました。クイック作成によるクラスタ構築の手順についてはチュートリアルをご参照ください。
WordPressを動かしてみる
Kubernetesクラスタ上にWordPress環境を構築します。デモ環境構築で必要となるマニフェストは、こちらを参照してください。
デモ環境概要図
ブロックボリュームをストレージとするNFSサーバを構築し、WordPressとMySQLからのデータを保存できるようにします。そして、ブラウザから外部接続してWordPressを利用できるようにします。その際、これまで学んできたDeployment、Service、PersisitentVolume、PersistentVolumeClaim、Secretを利用して環境を構築します。
デモ環境概要図
Secretの作成
MySQLのパスワードを格納するSecretを作成します。
Secretの作成
1 | $ kubectl create secret generic mysql --from-literal=password=mysql-p@ssw0d |
NFSサーバの作成
NFSサーバの作成に入る前に、以下を見ていきます。
- Kubernetesクラスタ上におけるデータの一時性と永続性
- PersistentVolumeとPersistentVolumeClaimの仕組み
- StorageClassによるDynamic Provisioning
Kubernetesクラスタ上におけるデータの一時性と永続性
ここでは、データの一時性(Temporary)をPodが削除または再デプロイされると同時にデータが消える意味とします。コンテナ内の書き込みレイヤーのボリュームにデータを保存したり、Pod内のボリューム(emptyDir)にデータを保存するとPodが削除、再デプロイされると同時にデータも削除されるため、データを永続できません。
データの一時性
ここでは、永続性(Persistent)をPodが削除または再デプロイされてもデータは消えない意味とします。hostPathをマニフェストに定義してノードにあるローカルディスクにデータを保存、またはPersistentVolume / PersistentVolumeClaimを利用してローカルディスクや外部のストレージにデータを保存できます。Podが削除、再デプロイされてもデータはローカルディスク及び外部のストレージにあるため、データの永続を担保できます。
データの永続性
PersistentVolumeとPersistentVolumeClaimの仕組み
事前にストレージを準備して、そのストレージをPersistentVolumeに紐づけます。そして、そのPersistentVolumeをPersistentVolumeClaim を利用して要求します。下図では5GiBを要求しています。実際、払い出されるボリュームは要求されている5GiBに近い20GiBのボリュームとなります。要求容量よりも15GiB多いボリュームとなるので PersistentVolumeの容量は設計時に考慮が必要です。
PersistentVolumeとPersistentVolumeClaimの仕組み
StorageClassによるDynamic Provisioning
PersistentVolumeClaimが発行されたタイミングで、動的にPersistentVolumeをプロビジョニングできるStorageClassという機能があります。デモ環境のPersistentVolumeとブロックボリュームの作成も、この機能を利用しています。
StorageClassによるDynamic Provisioning
ここから、NFSサーバの構築を見ていきます。OKEではCSIボリューム・プラグインを利用して、ブロックボリュームのPersistentVolumeClaimを仕様に従って定義、適用することで PersistentVolumeとブロックボリュームをプロビジョニングできます。先ほど説明したStorageClassの仕組みを利用しています。
NFSサーバの作成
以下、マニフェストファイルです。oci-bvストレージ・クラスの定義(provisioner: blockvolume.CSI.oraclecloud.com)で指定されたCSIプラグインを使用して、ブロック・ボリュームを動的にプロビジョニングできます。
02 | kind: PersistentVolumeClaim |
06 | storageClassName: "oci-bv" |
マニフェストを適用します。
1 | $ kubectl apply -f nfs-pvc.yaml |
PersistentVolumeClaim確認すると、oci-bvストレージ・クラスの定義にvolumeBindingMode: WaitForFirstConsumerが含まれているため、PVCのステータスはPendingとなります。
3 | NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE |
4 | nfs-pvc Pending oci-bv 1m |
この後、NFSサーバのDeploymentを適用することで、StatusがBoundに変わります。
17 | image: gcr.io/google_containers/volume-nfs:0.8 |
29 | name: nfs-local-storage |
31 | - name: nfs-local-storage |
32 | persistentVolumeClaim: |
33 | claimName: nfs-pvc #事前に作成した、PersistentVolumeClaim を指定 |
マニフェストを適用します。
1 | $ kubectl apply -f nfs-server.yaml |
NFSサーバのPodが作成されると、PersistentVolumeClaimのステータスがPendingからBoundに変わり、ブロックボリュームと紐づいているPersistentVolumeにバインドされたことになります。
3 | NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE |
4 | nfs-pvc Bound csi-3ce3f735-04a8-4b22-a768-7ae794d200a7 50Gi RWO oci-bv 141m |
WordPressとMySQLから接続するNFSサーバのServiceを作成します。
マニフェストを適用します。
1 | $ kubectl apply -f nfs-service.yaml |
確認します。
3 | NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE |
4 | kubernetes ClusterIP 10.96.0.1 <none> 443/TCP,12250/TCP 33d |
5 | nfs-service ClusterIP 10.96.211.52 <none> 2049/TCP,20048/TCP,111/TCP 167m |
PersistentVolume＆PersistentVolumeClaimの作成
WordPressとMySQLからNFS サーバのストレージにアクセスできるようにします。
PersistentVolumeとPersistentVolumeClaimの作成
WordPressとMySQLのPodから紐づけるPersistentVolumeとPersistentVolumeClaimを作成します。PersistentVolumeのマニフェストでは、NFSサーバのServiceオブジェクトのClusterIPを設定することでアクセスできるようになる仕組みです。
08 | storageClassName: mysql |
14 | server: xx.xx.xx.xx #「nfs-service」のCLUSTER-IPを定義 |
02 | kind: PersistentVolumeClaim |
09 | storageClassName: mysql |
08 | storageClassName: wordpress |
14 | server: xx.xx.xx.xx #「nfs-service」のCLUSTER-IPを定義 |
02 | kind: PersistentVolumeClaim |
09 | storageClassName: wordpress |
下表は、マニフェストの定義項目の概要です。
| 定義 |
説明 |
| name,labels |
多数のPersistentVolumeがある場合に識別しやすくなるため、設定を推奨 |
| storageClassName |
PersistentVolumeのStorageClassを指定
PersistentVolumeClaimは紐づけるPersistentVolumeの storageClassNameを指定
※このstorageClassはDynamicProvisioningではなく、単純に設定した値のPersistentVolumeと PersistentVolumeClaimを紐づける |
| storage |
クラウドプロバイダーの機能と連携して、ロードバランサやディスクボリュームなどのリソースを管理する |
| accessModes |
・ReadWriteOnce(RWO)：
単一ノードからRead/Write
・ReadOnlyMany(ROX)：
複数ノードからRead
・ReadWriteMany(RWX)：
複数ノードからRead/Write |
| persistentVolumeReclaimPolicy |
・Delete：
PersistentVolumeの実体が削除される
・Retain：
指定しない場合はRetain、PersistentVolumeの実体は削除せずに保持、他のPersistentVolumeClaimにより、このPersistentVolumeは再マウントされない
・Recycle：
PersistentVolumeのデータを削除(rm –rf ./*) し再利用可能にする
他のPersistentVolumeClaimにより再マウントされる |
| nfs |
nfs-serviceのIP アドレスを入力してNFS サーバを指定 |
マニフェストを適用します。
1 | $ kubectl apply -f mysql-pv.yaml |
2 | $ kubectl apply -f mysql-pvc.yaml |
3 | $ kubectl apply -f wordpress-pv.yaml |
4 | $ kubectl apply -f wordpress-pvc.yaml |
Bound状況を確認します。
03 | NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE |
04 | persistentvolumeclaim/mysql-pvc Bound mysql-pv 10Gi RWX mysql 25h |
05 | persistentvolumeclaim/nfs-pvc Bound csi-3ce3f735-04a8-4b22-a768-7ae794d200a7 50Gi RWO oci-bv 26h |
06 | persistentvolumeclaim/wordpress-pvc Bound wordpress-pv 10Gi RWX wordpress 25h |
08 | NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE |
09 | persistentvolume/csi-3ce3f735-04a8-4b22-a768-7ae794d200a7 50Gi RWO Delete Bound default/nfs-pvc oci-bv 26h |
10 | persistentvolume/mysql-pv 10Gi RWX Retain Bound default/mysql-pvc mysql 25h |
11 | persistentvolume/wordpress-pv 10Gi RWX Retain Bound default/wordpress-pvc wordpress 25h |
