4.2. Kubernetesクラスターの管理¶
セルフサービスユーザーは、コンテナ化されたアプリケーションを管理するために、永続ストレージ付きの準備済みKubernetesクラスターを配置できます。
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クラスター] 画面で、右側にある [作成] をクリックします。クラスターのパラメータを指定するウィンドウが開きます。
[クラスター] セクションで、Kubernetesバージョンを選択し、クラスター名を入力し、SSHキーを選択します。
[ネットワーク] セクションで、上記前提条件で述べた仮想ルーターを選択します。[フローティングIPアドレスを使用します] チェックボックスをオンにすることも推奨されています。この場合、KubernetesノードにはパブリックIPアドレスが割り当てられ、アクセスが簡単になります。
[マスターノード] セクションで、フレーバーを選択し、マスターノードで高可用性を有効化するかどうかを選択します。高可用性を有効化する場合、3個のマスターノードインスタンスが作成されます。それらのノードはアクティブ/アクティブモードで動作します。
[コンテナボリューム] セクションで、マスターノードとワーカーノード両方のボリュームについて、ストレージポリシーを選択し、サイズを入力します。
[ワーカー] セクションで、作成するワーカーの数を設定し、各ワーカーのフレーバーを選択します。
最後に、[作成] をクリックします。
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を動的にプロビジョニングできます。
ダッシュボードを介してKubernetesクラスターにアクセスします。手順については、「Kubernetesアクセス」を参照してください。
Kubernetesダッシュボードで、ストレージクラスの作成の説明に従ってストレージクラスを作成します。
永続ボリュームクレームを作成します。作成するには、[+ 作成] をクリックして、次のYAMLファイルを指定します。
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: mypvc spec: accessModes: - ReadWriteOnce resources: requests: storage: 10Gi storageClassName: mysc
このマニフェストは永続ボリュームクレーム
mypvc
も指定しています。このクレームにより単一のノードにより読み込み/書き込みレベルでマウントできる最低10GiBのボリュームがストレージクラスmysc
に要求されます。PVCを作成すると、クレームの要件を満たす永続ボリュームの動的プロビジョニングが開始されます。次にKubernetesは、これをクレームにバインドします。
ポッドを作成し、そのボリュームとして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. 永続ボリュームの静的プロビジョニング¶
永続ボリュームの静的プロビジョニングを使用して、既存の計算ボリュームをポッドにマウントできます。計算ボリュームをマウントするには、以下の手順を実行します。
セルフサービスパネルで、任意のボリュームのIDを取得します。
ダッシュボードを介してKubernetesクラスターにアクセスします。手順については、「Kubernetesアクセス」を参照してください。
Kubernetesダッシュボードで、ストレージクラスの作成の説明に従ってストレージクラスを作成します。
永続ボリュームを作成します。作成するには、[+ 作成] をクリックして、次の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
の計算ボリュームを使用します。永続ボリュームクレームを作成します。PVCを定義する前に、PVが作成済みでステータスが「利用可能」であることを確認してください。既存のPVは、ストレージのサイズ、アクセスモード、およびストレージクラスのクレーム要件を満たしていなければなりません。[+ 作成] をクリックして、次のYAMLファイルを指定します。
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: mypvc spec: accessModes: - ReadWriteOnce resources: requests: storage: 10Gi storageClassName: mysc
永続ボリュームクレーム
mypvc
が作成されると、ボリュームmypv
がクレームにバインドされます。ポッドを作成し、そのボリュームとしてPVCを指定します。永続ボリュームの動的プロビジョニングの手順3の例を使用します。
セルフサービスパネルで、計算ボリュームはKubernetesポッドを実行している仮想マシンにマウントされます。
4.2.2. Kubernetesでの外部ロードバランサの作成¶
Kubernetesでは、パブリックネットワークからのアクセスを提供する、外部ロードバランサを備えたサービスを作成できます。ロードバランサは、パブリックでアクセス可能なIPアドレスを受信し、受信したリクエストをKubernetesクラスターノード上の適切なポートにルーティングします。
外部ロードバランサを備えたサービスを作成するには、以下の手順を実行します。
ダッシュボードを介してKubernetesクラスターにアクセスします。手順については、「Kubernetesアクセス」を参照してください。
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アドレスが割り当てられ、この外部エンドポイントからアクセスできるようになります。
仮想ルーター経由で物理ネットワークにリンクされた仮想ネットワークにKubernetesクラスターを配置している場合は、
annotations
セクションを含まないYAMLファイルをload-balancer
サービスに使用できます。ロードバランサを作成すると、物理ネットワークからフローティングIPアドレスを受信します。この外部エンドポイントからアクセスできるようになります。
ロードバランサはセルフサービスパネルにも表示され、パフォーマンスと正常性を監視できます。例:
