Oracle Cloud Hangout Cafe Season7 #1「Kubnernetes 超入門」(2023年6月7日開催)

Kubernetesクラスタ構築＆アプリケーションデプロイ

ここからは、これまで掴んだ内容を基にKubernetesクラスタを構築して、サンプルアプリケーションとしてWordPressを動かす流れを見ていきます。

クラスタ構築

Kubernetesのクラスタ構築は、以下にあるような全てを1から構築する方法やKubeadmのようなクラスタ構築ツールを利用する方法、マネージドサービスを利用する方法があります。

• Kubernetesクラスタ構築ツールを利用せずに、全てを1から構築する「Kubernetes the hard way」
• Kubernetesクラスタを構築するオープンソースソフトウェア「kubeadm」
• Kubernetesマネージドサービス
  • 「Oracle Container Engine for Kubernetes」
  • 「Amazon Elastic Kubernetes Service」
  • 「Google Kubernetes Engine」
  • 「Azure Kubernetes Service」

セッション時に実施したデモでは、Oracle Container Engine for Kubernetes(以降、OKEと略称)を利用しました。クイック作成によるクラスタ構築の手順についてはチュートリアルをご参照ください。

WordPressを動かしてみる

Kubernetesクラスタ上にWordPress環境を構築します。デモ環境構築で必要となるマニフェストは、こちらを参照してください。

デモ環境概要図
ブロックボリュームをストレージとするNFSサーバを構築し、WordPressとMySQLからのデータを保存できるようにします。そして、ブラウザから外部接続してWordPressを利用できるようにします。その際、これまで学んできたDeployment、Service、PersisitentVolume、PersistentVolumeClaim、Secretを利用して環境を構築します。

Secretの作成
MySQLのパスワードを格納するSecretを作成します。

$ 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の容量は設計時に考慮が必要です。

StorageClassによるDynamic Provisioning
PersistentVolumeClaimが発行されたタイミングで、動的にPersistentVolumeをプロビジョニングできるStorageClassという機能があります。デモ環境のPersistentVolumeとブロックボリュームの作成も、この機能を利用しています。

ここから、NFSサーバの構築を見ていきます。OKEではCSIボリューム・プラグインを利用して、ブロックボリュームのPersistentVolumeClaimを仕様に従って定義、適用することで PersistentVolumeとブロックボリュームをプロビジョニングできます。先ほど説明したStorageClassの仕組みを利用しています。

以下、マニフェストファイルです。oci-bvストレージ・クラスの定義(provisioner: blockvolume.CSI.oraclecloud.com)で指定されたCSIプラグインを使用して、ブロック・ボリュームを動的にプロビジョニングできます。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-pvc
spec:
  storageClassName: "oci-bv"
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 50Gi

マニフェストを適用します。

$ kubectl apply -f nfs-pvc.yaml

PersistentVolumeClaim確認すると、oci-bvストレージ・クラスの定義にvolumeBindingMode: WaitForFirstConsumerが含まれているため、PVCのステータスはPendingとなります。

$ kubectl get pvc

NAME      STATUS   VOLUME    CAPACITY   ACCESS MODES   STORAGECLASS   AGE
nfs-pvc   Pending                                      oci-bv         1m

この後、NFSサーバのDeploymentを適用することで、StatusがBoundに変わります。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nfs-server
spec:
  replicas: 1
  selector:
    matchLabels:
      role: nfs-server
  template:
    metadata:
      labels:
        role: nfs-server
    spec:
      containers:
      - name: nfs-server
        image: gcr.io/google_containers/volume-nfs:0.8
        ports:
          - name: nfs
            containerPort: 2049
          - name: mountd
            containerPort: 20048
          - name: rpcbind
            containerPort: 111
        securityContext:
          privileged: true
        volumeMounts:
          - mountPath: /exports
            name: nfs-local-storage
      volumes:
        - name: nfs-local-storage
          persistentVolumeClaim:
            claimName: nfs-pvc  #事前に作成した、PersistentVolumeClaim を指定

マニフェストを適用します。

$ kubectl apply -f nfs-server.yaml

NFSサーバのPodが作成されると、PersistentVolumeClaimのステータスがPendingからBoundに変わり、ブロックボリュームと紐づいているPersistentVolumeにバインドされたことになります。

$ kubectl get pvc

NAME      STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
nfs-pvc   Bound    csi-3ce3f735-04a8-4b22-a768-7ae794d200a7   50Gi       RWO            oci-bv         141m

WordPressとMySQLから接続するNFSサーバのServiceを作成します。

apiVersion: v1
kind: Service
metadata:
  name: nfs-service
spec:
  ports:
    - name: nfs
      port: 2049
    - name: mountd
      port: 20048
    - name: rpcbind
      port: 111
  selector:
    role: nfs-server

マニフェストを適用します。

$ kubectl apply -f nfs-service.yaml

確認します。

$ kubectl get services

NAME               TYPE          CLUSTER-IP      EXTERNAL-IP       PORT(S)                       AGE
kubernetes         ClusterIP     10.96.0.1                   443/TCP,12250/TCP             33d
nfs-service        ClusterIP     10.96.211.52                2049/TCP,20048/TCP,111/TCP    167m

PersistentVolume＆PersistentVolumeClaimの作成
WordPressとMySQLからNFS サーバのストレージにアクセスできるようにします。

WordPressとMySQLのPodから紐づけるPersistentVolumeとPersistentVolumeClaimを作成します。PersistentVolumeのマニフェストでは、NFSサーバのServiceオブジェクトのClusterIPを設定することでアクセスできるようになる仕組みです。

apiVersion: v1
kind: PersistentVolume
metadata:
  name: mysql-pv
  labels:
    type: local
spec:
  storageClassName: mysql
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteMany
  nfs:
    server: xx.xx.xx.xx #「nfs-service」のCLUSTER-IPを定義
    path: /

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pvc
  labels:
    app: wordpress
    tier: mysql
spec:
  storageClassName: mysql
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 5Gi

apiVersion: v1
kind: PersistentVolume
metadata:
  name: wordpress-pv
  labels:
    type: local
spec:
  storageClassName: wordpress
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteMany
  nfs:
    server: xx.xx.xx.xx #「nfs-service」のCLUSTER-IPを定義
    path: /

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: wordpress-pvc
  labels:
    app: wordpress
    tier: wordpress
spec:
  storageClassName: wordpress
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 5Gi

下表は、マニフェストの定義項目の概要です。

マニフェストを適用します。

$ kubectl apply -f mysql-pv.yaml
$ kubectl apply -f mysql-pvc.yaml
$ kubectl apply -f wordpress-pv.yaml
$ kubectl apply -f wordpress-pvc.yaml

Bound状況を確認します。

$ kubectl get pvc,pv

NAME                                   STATUS     VOLUME                                    CAPACITY   ACCESS  MODES   STORAGECLASS   AGE
persistentvolumeclaim/mysql-pvc        Bound      mysql-pv                                  10Gi       RWX             mysql          25h
persistentvolumeclaim/nfs-pvc          Bound      csi-3ce3f735-04a8-4b22-a768-7ae794d200a7  50Gi       RWO             oci-bv         26h
persistentvolumeclaim/wordpress-pvc    Bound      wordpress-pv                              10Gi       RWX             wordpress      25h

NAME                                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                  STORAGECLASS   REASON   AGE
persistentvolume/csi-3ce3f735-04a8-4b22-a768-7ae794d200a7  50Gi       RWO            Delete           Bound    default/nfs-pvc        oci-bv                  26h
persistentvolume/mysql-pv                                  10Gi       RWX            Retain           Bound    default/mysql-pvc      mysql                   25h
persistentvolume/wordpress-pv                              10Gi       RWX            Retain           Bound    default/wordpress-pvc  wordpress               25h