4.2. Kubernetesクラスターの管理

セルフサービスユーザーは、コンテナ化されたアプリケーションを管理するために、永続ストレージ付きの準備済みKubernetesクラスターを配置できます。

Kubernetesクラスターには次のコンポーネントが含まれます。

表 4.2.1 Kubernetesのコンポーネント
コンポーネント 名前とバージョン
基盤となるOS Fedora 29 Atomic Host
コンテナランタイム Docker 1.13.1
ネットワークプラグイン VXLANを用いたFlannel

Kubernetesクラスター作成の前提条件は以下のとおりです。

  • Kubernetes-as-a-serviceコンポーネント。計算クラスターと同時に配置することも、後ほど配置することもできます(Creating the Compute ClusterまたはManaging Add-On Servicesを参照)。
  • Kubernetesのマスターノードとワーカーノードを相互接続するネットワーク。このネットワークは、仮想ルーターを介して物理ネットワークに接続された共有物理ネットワークまたは仮想ネットワークのいずれかになります。仮想ネットワークには、ゲートウェイとDNSサーバーが指定されている必要があります。
  • マスターノードとワーカーノードの両方にインストールされるSSHキー。
  • Kubernetesノードすべてに十分なリソース。フレーバーを考慮に入れます。

重要

また、Kubernetesクラスターを作成するネットワークがこれらのデフォルトネットワークと重複しないようにする必要があります。

  • 10.100.0.0/24---ポッドレベルのネットワークに使用される
  • 10.254.0.0/16---KubernetesクラスターIPアドレスの割り当てに使用される

Kubernetesクラスターを作成するには、[Kubernetesクラスター] 画面で、右側にある [作成] をクリックします。クラスターのパラメータを指定するウィンドウが開きます。

  1. [クラスター] セクションで、Kubernetesバージョンを選択し、クラスター名を入力し、SSHキーを選択します。

    ../_images/ss_kubernetes1_ac.png
  2. [ネットワーク] セクションで、上記前提条件で述べた仮想ルーターを選択します。[フローティングIPアドレスを使用します] チェックボックスをオンにすることも推奨されています。この場合、KubernetesノードにはパブリックIPアドレスが割り当てられ、アクセスが簡単になります。

    ../_images/ss_kubernetes2_ac.png
  3. [マスターノード] セクションで、フレーバーを選択し、マスターノードで高可用性を有効化するかどうかを選択します。高可用性を有効化する場合、3個のマスターノードインスタンスが作成されます。それらのノードはアクティブ/アクティブモードで動作します。

    ../_images/ss_kubernetes3_ac.png
  4. [コンテナボリューム] セクションで、マスターノードとワーカーノード両方のボリュームについて、ストレージポリシーを選択し、サイズを入力します。

    ../_images/ss_kubernetes4_ac.png
  5. [ワーカー] セクションで、作成するワーカーの数を設定し、各ワーカーのフレーバーを選択します。

    ../_images/ss_kubernetes5_ac.png
  6. 最後に、[作成] をクリックします。

Kubernetesクラスターの作成が始まります。[仮想マシン] 画面にマスターノードとワーカーノードが表示され、[ボリューム] 画面にはそれらのボリュームが表示されます。

クラスターの準備ができた後、[Kubernetesアクセス] をクリックすると、ダッシュボードにアクセスする手順が表示されます。

Kubernetesクラスターを削除するには、[Kubernetesクラスター] 画面でそのクラスターをクリックしてから、[削除] をクリックします。マスターVMとワーカーVMが、ボリュームと一緒に削除されます。

4.2.1. Kubernetesポッドの永続ボリュームの使用

Kubernetesでは、ポッドの永続ストレージとして、計算ボリュームを使用できます。永続ボリューム(PV)はポッドとは独立して存在しており、このボリュームは、マウントされたポッドが削除された後も存続します。このPVを他のポッドにマウントして、保存されているデータにアクセスすることができます。計算クラスター内に存在するボリュームを使用して、PVを手動で作成したり、静的に作成することなく、動的にプロビジョニングすることができます。

4.2.1.1. ストレージクラスの作成

Acronis Cyber Infrastructureで、ストレージクラスを管理者パネルで定義された計算ストレージポリシーにマップします。ストレージクラスの作成は、Kubernetesクラスターでのすべてのストレージ操作に必要です。

ストレージクラスを作成するには、Kubernetesダッシュボードで [+ 作成] をクリックして、このオブジェクトを定義するYAMLファイルを指定します。例:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: mysc
provisioner: csi-cinderplugin
parameters:
  type: default

このマニフェストは、ストレージポリシーdefaultを使用する、ストレージクラスmyscについて記述します。ストレージポリシーは計算クラスター内に存在していなければならず、現在のプロジェクトに対するストレージのクォータで指定されます。

4.2.1.2. 永続ボリュームの動的プロビジョニング

永続ボリュームは、永続ボリュームクレーム(PVC)を介して動的にプロビジョニングできます。特定のストレージクラス、アクセスモード、サイズのPVに対応するPVCリクエスト。クラスターに適切なPVが存在する場合、クレームにバインドされます。適切なPVが存在しないにもかかわらず、プロビジョニングされる場合は、新しいボリュームが作成され、クレームにバインドされます。KubernetesはPVCを使用してPVのバックアップを取得し、それをポッドにマウントします。

重要

ポッドと、ポッドが使用する永続ボリュームクレームは、同じ名前領域に存在していなければなりません。

次の手順を実行して、ポッドにPVを動的にプロビジョニングできます。

  1. ダッシュボードを介してKubernetesクラスターにアクセスします。手順については、「Kubernetesアクセス」を参照してください。

  2. Kubernetesダッシュボードで、ストレージクラスの作成の説明に従ってストレージクラスを作成します。

  3. 永続ボリュームクレームを作成します。作成するには、[+ 作成] をクリックして、次のYAMLファイルを指定します。

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: mypvc
    spec:
      accessModes:
      - ReadWriteOnce
      resources:
        requests:
          storage: 10Gi
      storageClassName: mysc
    

    このマニフェストは永続ボリュームクレームmypvcも指定しています。このクレームにより単一のノードにより読み込み/書き込みレベルでマウントできる最低10GiBのボリュームがストレージクラスmyscに要求されます。

    PVCを作成すると、クレームの要件を満たす永続ボリュームの動的プロビジョニングが開始されます。次にKubernetesは、これをクレームにバインドします。

    ../_images/ss_kubernetes6.png
  4. ポッドを作成し、そのボリュームとしてPVCを指定します。これを実行するには、[+ 作成] をクリックして、次のYAMLファイルを指定します。

    apiVersion: v1
    kind: Pod
    metadata:
      name: nginx
    spec:
      containers:
      - image: nginx
        imagePullPolicy: IfNotPresent
        name: nginx
        ports:
        - containerPort: 80
          protocol: TCP
        volumeMounts:
          - mountPath: /var/lib/www/html
            name: mydisk
      volumes:
      - name: mydisk
        persistentVolumeClaim:
          claimName: mypvc
          readOnly: false
    

    この設定ファイルは、永続ボリュームクレームmypvcを使用するポッドnginxを記述しています。クレームにバインドされた永続ボリュームは、nginxコンテナ内の/var/lib/www/htmlからアクセスできます。

4.2.1.3. 永続ボリュームの静的プロビジョニング

永続ボリュームの静的プロビジョニングを使用して、既存の計算ボリュームをポッドにマウントできます。計算ボリュームをマウントするには、以下の手順を実行します。

  1. セルフサービスパネルで、任意のボリュームのIDを取得します。

    ../_images/ss_kubernetes7_ac.png
  2. ダッシュボードを介してKubernetesクラスターにアクセスします。手順については、「Kubernetesアクセス」を参照してください。

  3. Kubernetesダッシュボードで、ストレージクラスの作成の説明に従ってストレージクラスを作成します。

  4. 永続ボリュームを作成します。作成するには、[+ 作成] をクリックして、次のYAMLファイルを指定します。

    apiVersion: v1
    kind: PersistentVolume
    metadata:
      annotations:
        pv.kubernetes.io/provisioned-by: csi-cinderplugin
      name: mypv
    spec:
      accessModes:
      - ReadWriteOnce
      capacity:
        storage: 10Gi
      csi:
        driver: cinder.csi.openstack.org
        fsType: ext4
        volumeHandle: c5850e42-4f9d-42b5-9bee-8809dedae424
      persistentVolumeReclaimPolicy: Delete
      storageClassName: mysc
    

    このマニフェストは、ストレージクラスmyscから永続ボリュームクレームmypvcも指定しています。このストレージクラスは10GiBのストレージを持ち、単一のノードによる読み込み/書き込みレベルでマウントできるアクセスモードを備えています。PV、mypvは、 バックストレージとして、IDc5850e42-4f9d-42b5-9bee-8809dedae424の計算ボリュームを使用します。

  5. 永続ボリュームクレームを作成します。PVCを定義する前に、PVが作成済みでステータスが「利用可能」であることを確認してください。既存のPVは、ストレージのサイズ、アクセスモード、およびストレージクラスのクレーム要件を満たしていなければなりません。[+ 作成] をクリックして、次のYAMLファイルを指定します。

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: mypvc
    spec:
      accessModes:
      - ReadWriteOnce
      resources:
        requests:
          storage: 10Gi
      storageClassName: mysc
    

    永続ボリュームクレームmypvcが作成されると、ボリュームmypvがクレームにバインドされます。

    ../_images/ss_kubernetes8.png
  6. ポッドを作成し、そのボリュームとしてPVCを指定します。永続ボリュームの動的プロビジョニングの手順3の例を使用します。

    セルフサービスパネルで、計算ボリュームはKubernetesポッドを実行している仮想マシンにマウントされます。

    ../_images/ss_kubernetes9_ac.png

4.2.2. Kubernetesでの外部ロードバランサの作成

Kubernetesでは、パブリックネットワークからのアクセスを提供する、外部ロードバランサを備えたサービスを作成できます。ロードバランサは、パブリックでアクセス可能なIPアドレスを受信し、受信したリクエストをKubernetesクラスターノード上の適切なポートにルーティングします。

外部ロードバランサを備えたサービスを作成するには、以下の手順を実行します。

  1. ダッシュボードを介してKubernetesクラスターにアクセスします。手順については、「Kubernetesアクセス」を参照してください。

  2. Kubernetesダッシュボードで、ロードバランサの配置とサービスを作成します。これを実行するには、[+ 作成] をクリックして、それらのオブジェクトを定義するYAMLファイルを指定します。例:

    • 共有物理ネットワークにKubernetesクラスターを配置した場合、次のマニフェストを指定します。

      apiVersion: apps/v1beta1
      kind: Deployment
      metadata:
        name: nginx
      spec:
        replicas: 2
        template:
          metadata:
            labels:
              app: nginx
          spec:
            containers:
            - name: nginx
              image: nginx
              ports:
              - containerPort: 80
      ---
      kind: Service
      apiVersion: v1
      metadata:
        name: load-balancer
        annotations:
          service.beta.kubernetes.io/openstack-internal-load-balancer: "true"
      spec:
        selector:
          app: nginx
        type: LoadBalancer
        ports:
        - port: 80
          targetPort: 80
          protocol: TCP
      

      上のマニフェストでは、2つのポッドのレプリカセットを備える配置nginxと、ロードバランサタイプを使用するサービスload-balancerが記述されています。サービスで使用される注釈は、ロードバランサが内部にあることを示しています。

      ロードバランサが作成されると、共有物理ネットワークからIPアドレスが割り当てられ、この外部エンドポイントからアクセスできるようになります。

      ../_images/ss_kubernetes11.png
    • 仮想ルーター経由で物理ネットワークにリンクされた仮想ネットワークにKubernetesクラスターを配置している場合は、annotationsセクションを含まないYAMLファイルをload-balancerサービスに使用できます。ロードバランサを作成すると、物理ネットワークからフローティングIPアドレスを受信します。この外部エンドポイントからアクセスできるようになります。

ロードバランサはセルフサービスパネルにも表示され、パフォーマンスと正常性を監視できます。例:

../_images/ss_kubernetes12_ac.png