RKE1からRKE2への移行方法

本ドキュメントでは、RKEクラスターからRKE2クラスターへの移行方法について説明します。

はじめに

本ドキュメントでは、移行の対象となるRKEで構築されたクラスターを「RKE1クラスター」と表記しています。

お客様は、移行先となるRKE2クラスターを新たに作成し、現在ご利用中のRKE1クラスターからアプリケーションの移行を行っていただく必要があります。

本ドキュメントでは、作成したRKE2クラスターへのお客様のアプリケーションの状態に合わせた各種移行パターンについて説明します。お客様のアプリケーションの状態に合わせて、最適な移行方法をご選定ください。

注意事項

本ドキュメントで説明するアプリケーションの移行手順は一例であり、お客様がご利用されているすべてのアプリケーションに適用できるわけではありません。また、アプリケーションによっては、記載の手順通りに移行できない可能性があることをご了承ください。

アプリケーションに特化した移行が必要な場合は、アプリケーションベンダーへお問い合わせください。OSSをご利用の場合は、各OSSが提供するドキュメント等をご確認ください。

アプリケーションの移行方法

移行方法は、以下のパターンに分けて説明します。

永続ボリュームを利用していないアプリケーション
永続ボリュームを利用しているアプリケーション

お客様のアプリケーションが永続ボリューム(PersistentVolume)を利用している場合、各種マニフェスト(YAML)に加えて、永続ボリュームのデータ移行も合わせて必要となります。

どちらの手順も Kind: PersistentVolumeClaim、Kind: PersistentVolume 以外の各種マニフェストの移行方法は同じです。「永続ボリュームを利用していないアプリケーション」の移行手順をご参照ください。
「永続ボリュームを利用しているアプリケーション」では、永続ボリュームのデータ移行方法について記載します。

また、Veeam Softwareが提供するKubernetesネイティブなバックアップソリューション「Veeam Kasten」を利用した移行手順もご紹介します。

移行対象のアプリケーションおよびマニフェストの管理状況に合わせて、最適な移行方法をご検討ください。

永続ボリュームを利用していないアプリケーション

マニフェストのコード管理がされている場合

お客様のアプリケーションのマニフェスト(YAML)がGitHub等でコード管理されている場合、基本的にそれらのマニフェストファイルをRKE2クラスターに適用(Apply)することで、同じ内容のアプリケーションを稼働させることが可能です。

必要なマニフェストをRKE2クラスターに適用し、問題なく動作することをご確認ください。

マニフェストのコード管理がされていない場合

お客様のアプリケーションのマニフェスト(YAML)がGitHub等でコード管理されておらず、RKE1クラスターにのみ存在する場合は、RKE1クラスターから必要なマニフェストファイルを取り出し、RKE2クラスターに適用(Apply)することで移行を行います。

RKE1クラスターからマニフェストを取り出すには、以下の方法があります。

kubectl を使用してリソースをYAML形式で保存する
IDCFクラウドコンテナコンソールにアクセスしてWebUIからYAMLをダウンロードする

これらの方法で取得したYAMLファイルから不要な部分を削除し、GitHub等でコード管理することをご検討ください。

kubectlを使用して移行する

kubectl では -o yaml オプションを用いて出力形式を指定できます。このオプションを使用し、RKE1クラスターからマニフェストをYAML形式で出力し、RKE2クラスターへ適用してください。

RKE1クラスターからマニフェスト(YAML)を取得する

kubectl を使用してYAML形式で出力し、ファイルに保存します。

kubectl --kubeconfig "kubeconfig_file_name" -n "Namespace" get "Resource種別" "Resource名" -o yaml > "出力ファイル名"

取得したマニフェスト(YAML)をRKE2クラスターに適用する

kubectl を使用して保存したマニフェストをクラスターに適用します。ファイル名の代わりにディレクトリを指定すると、そのディレクトリにある全てのYAMLファイルが適用されます。

kubectl --kubeconfig "kubeconfig_file_name" apply -f "ファイル名"

以下の例のように、必要な全てのリソースを取得し、RKE2クラスターに適用します。

Kind: Deployment / ConfigMap リソースの移行例

例では、kubectl のコンフィグを以下のファイル名で保存している場合を想定します。

RKE1クラスター: old-kubeconfig.yaml
RKE2クラスター: new-kubeconfig.yaml

## Kind: Deployment / Kind: ConfigMap の一覧を出力し、移行対象を確認する。
$ kubectl --kubeconfig old-kubeconfig.yaml -n example-namespace get deployments.apps
NAME           READY   UP-TO-DATE   AVAILABLE   AGE
example-app    1/1     1            1           4h7m
example-app2   1/1     1            1           3s

$ kubectl --kubeconfig old-kubeconfig.yaml -n example-namespace get configmaps
NAME               DATA   AGE
data1              1      4h19m
data2              1      4h15m

## Kind: Deployment をRKE1クラスターからYAMLで出力する。
$ kubectl --kubeconfig old-kubeconfig.yaml -n example-namespace get deployments.apps example-app -o yaml > example-namespace_deployment_example-app.yaml

## Kind: ConfigMap をRKE1クラスターからYAMLで出力する。
$ kubectl --kubeconfig old-kubeconfig.yaml -n example-namespace get configmaps example-data -o yaml > example-namespace_configmap_example-data.yaml

### RKE2クラスターへの適用する。
$ kubectl --kubeconfig new-kubeconfig.yaml apply -f example-namespace_deployment_example-app.yaml
$ kubectl --kubeconfig new-kubeconfig.yaml apply -f example-namespace_configmap_example-data.yaml

## Kind: Deployment の一覧を出力し、移行を確認する。
$ kubectl --kubeconfig new-kubeconfig.yaml -n example-namespace get deployments.apps
NAME           READY   UP-TO-DATE   AVAILABLE   AGE
example-app    1/1     1            1           1m

$ kubectl --kubeconfig new-kubeconfig.yaml -n example-namespace get configmaps
NAME               DATA   AGE
example-data       1      6h53m
kube-root-ca.crt   1      2d23h

Tips

RKE1クラスターからの出力とRKE2クラスターへの入力を同時に行うことも可能です。 tee コマンドを使用すると、同時にファイルにも出力されるため、コード管理にご活用ください。

kubectl --kubeconfig old-kubeconfig.yaml -n example-namespace get deployments.apps example-app -o yaml | tee example-namespace_deployment_example-app.yaml | kubectl --kubeconfig new-kubeconfig.yaml apply -f -

IDCFクラウドコンテナコンソールを使用して移行する

IDCFクラウドコンテナコンソールを使用し、Web UIから移行を行います。

RKE1クラスターからマニフェスト(YAML)を取得する

コンテナコンソールからRKE1クラスターのExploreにアクセスし、移行元となるリソースを確認します。

リソース右端のメニューから「YAMLをダウンロード」を選択すると、マニフェストをダウンロードできます。また、「YAMLを編集」を選択するとYAML編集画面が開くため、ここから内容をコピーすることも可能です。

「関連リソース」では、このリソースが参照している別のリソースを確認できます。

「関連リソース」に表示される全てのリソースが、必ずしも保存対象とは限りません。

例えば、Kind: Deployment の「関連リソース」には Kind: ReplicaSet なども関連リソースとして表示されます。しかし、Kind: ReplicaSet は Kind: Deployment が自動的に生成するリソースであるため、個別に保存・管理する必要はありません。

取得したマニフェスト(YAML)をRKE2クラスターに適用する

コンテナコンソールからRKE2クラスターのExploreにアクセスし、RKE1クラスターから取得したマニフェストを適用します。

コンテナコンソール右上のメニューから「YAMLをインポート」を選択し、「ファイルから読み込む」を選択して取得したマニフェストを読み込み、「インポート」で適用します。

「ファイルから読み込む」以外にも、直接YAMLを貼り付けて適用することも可能です。

必要な全てのリソースを取得し、RKE2クラスターに適用します。

永続ボリュームを利用しているアプリケーション

永続ボリューム(PersistentVolume)を利用してデータを保持しているアプリケーションの場合は、RKE1クラスターからRKE2クラスターへデータを移行します。

Kind: PersistentVolume および Kind: PersistentVolumeClaim 以外のリソースに関する各種マニフェスト(YAML)は、前述の「永続ボリュームを利用していないアプリケーション」と同様の手順で移行します。

以下の方法で永続ボリュームのデータを移行できます。各手順のメリット・デメリットをご確認のうえ、最適なデータ移行手順をご検討ください。

kubectl cp を使用してデータを移行する
IDCFクラウドのボリュームをそのまま移行する

PersistentVolumeを使用するOperator(例:RDBのOperator)をご利用の場合は、Operatorが実装しているバックアップ・リストアの手順をご確認いただき、利用可能な場合はそちらの手順をご利用ください。

Kubectl cp を使用してデータを移行する

kubectl cp を使用してRKE1クラスターのPod内にあるデータをローカルにコピーし、保存します。その後、保存したデータをRKE2クラスターで稼働しているPodのボリュームに移行します。

メリット
- kubectl コマンドのみでデータ移行可能
デメリット
- ファイル単位でのデータ移行となる
- 各ボリュームについて個別に対応が必要
- コンテナ内部に tar コマンドがインストールされている必要がある
  - インストールされていない場合 kubectl cp が失敗します

RKE2クラスターにデータ移行先ワークロードを準備する

kubectl cp を使用したデータ移行では、RKE1クラスターとRKE2クラスターの両方で、ボリュームを持つPodが稼働している必要があります。

「永続ボリュームを利用していないアプリケーション」のいずれかの手順で、RKE2クラスターへワークロードを移行し、稼働させます。この際、Kind: PersistentVolumeClaim も同様の手順で移行してください。

個別に Kind: PersistentVolumeClaim を作成している場合のみ、移行が必要です。

Kind: StatefulSet で volumeClaimTemplates を利用している場合、StatefulSetが動的に Kind: PersistentVolumeClaim を作成します。したがって、Kind: PersistentVolumeClaim 自体の移行は必要ありません。

kubectl cp を使用してPodからデータをコピーしローカルに保存する

kubectl cp を使用してRKE1クラスターのPodからデータをコピーし、ローカルに保存します。

kubectl --kubeconfig "kubeconfig_file_name" -n "Namespace" cp "Pod名":"コピー元ファイルパス" "保存先ファイル名" -c "コンテナ名"

Tips

コピー元ファイルパス にディレクトリを指定した場合、そのディレクトリ配下のファイルが全て保存対象となります。このとき、保存先ファイル名 には保存先のディレクトリ名を指定します。
Pod上で1つのコンテナのみが動作している場合、-c "コンテナ名" オプションは省略可能です。

kubectl cp を使用してローカルのデータをPodへデータ移行する

kubectl cp を使用して、ローカルにあるデータをRKE2クラスターのPodへ移行します。

kubectl --kubeconfig "kubeconfig_file_name" -n "Namespace" cp "保存元ファイル名" "Pod名":"コピー先ファイルパス" -c "コンテナ名"

Tips

保存元ファイルパス にディレクトリを指定した場合、指定したディレクトリとその配下のファイル全てを対象に移行できます。このとき、コピー先ファイル名 には保存先のディレクトリ名を指定します。

保存元ファイル名 にディレクトリを指定した場合、コピー先ファイル名 に指定したディレクトリの中に、保存元ファイル名 と同じ名前のディレクトリが作成され、その配下にファイルがコピーされます。

コンテナ内部の `/data` 配下をRKE2クラスターへ移行する例

例では、kubectl のコンフィグを以下のファイル名で保存している場合を想定します。

RKE1クラスター: old-kubeconfig.yaml
RKE2クラスター: new-kubeconfig.yaml

## RKE1クラスターの移行元データの確認
$ kubectl --kubeconfig old-kubeconfig.yaml -n example-namespace exec -it example-app-0 -- ls -la /data
total 4
drwxr-xr-x    3 root     root            38 Mar  3 09:28 .
drwxr-xr-x    1 root     root            41 Mar  3 08:21 ..
-rw-r--r--    1 root     root           702 Mar  3 09:28 example.txt
drwxr-xr-x    2 root     root            24 Mar  3 09:28 index

## kubectl cp 利用して、RKE1クラスターの Pod: example-app-0、Container: alpine の /data ディレクトリ配下を、ローカルの ./data/ ディレクトリ配下に取得します。
$ kubectl --kubeconfig old-kubeconfig.yaml -n example-namespace cp example-app-0:/data/ ./data/ -c alpine
#tar: removing leading '/' from member names と出力されますが、無視して構いません。

## ローカルに取得したデータの確認
$ ls -la ./data/
合計 8
drwxr-xr-x. 3 root root   38  3月  3 18:10 .
drwxr-xr-x. 8 root root 4096  3月  3 18:28 ..
-rw-r--r--. 1 root root  702  3月  3 18:10 example.txt
drwxr-xr-x. 2 root root   24  3月  3 18:10 index

## kubectl cp 利用して、ローカルの ./data/ ディレクトリ配下のデータを、RKE2クラスターの Pod: example-app-0、Container: alpine の /data ディレクトリ配下へデータを移行します。
$ kubectl --kubeconfig new-kubeconfig.yaml -n example-namespace cp ./data/ example-app-0:/ -c alpine
#コンテナ内部の / からコピーされるため、/data/FileName と配置されます。

## RKE2クラスターへ移行したデータの確認
$ kubectl --kubeconfig new-kubeconfig.yaml -n example-namespace exec -it example-app-0 -- ls -la /data
total 4
drwxr-xr-x    3 root     root            38 Mar  3 09:44 .
drwxr-xr-x    1 root     root            41 Mar  3 08:21 ..
-rw-r--r--    1 root     root           702 Mar  3 09:44 example.txt
drwxr-xr-x    2 root     root            24 Mar  3 09:44 index

RKE1クラスターの各ボリュームから必要な全てのファイルを取得し、RKE2クラスターの対応するボリュームにデータを移行します。

IDCFクラウドのボリュームをそのまま移行する

IDCFクラウドコンピューティングのボリュームを利用して、データの移行を行います。

前提条件

クラスター種別が「IDCFクラウド」
Container Storage Interfaceとして「IDCFクラウド」を利用
StorageClassとして cloudstack-xfs、cloudstack-ext4 を利用

以下の手順でIDCFクラウドコンピューティングのボリュームデータをRKE1クラスターからRKE2クラスターに移行します。

RKE1クラスターで利用中のボリュームのスナップショットを取得し、そのスナップショットから複製したボリュームをRKE2クラスターで利用する。
RKE1クラスターで利用中のボリュームをRKE2クラスターに移行し、そのまま利用する。

RKE1クラスターで利用しているボリュームをそのままRKE2クラスターに移行する場合、移行が容易であるというメリットがある一方で、移行時にデータ異常が発生した場合に元の状態に戻すことが困難になる可能性があります。そのため、データの安全性を考慮し、スナップショットを利用した移行を推奨します。

メリット
- RKE1クラスターで使用中のIDCFクラウドコンピューティングボリュームをそのままRKE2クラスターへ移行可能
デメリット
- RKE1クラスターで移行対象のボリュームを使用しているPodを停止する必要がある

スナップショットを取得し、ボリュームを複製する

移行元ボリュームのスナップショットを取得し、そのスナップショットからボリュームを複製してRKE2クラスターで利用します。RKE1クラスターのボリュームをそのまま移行する場合は、この手順は不要です。

スナップショット取得時の注意事項

ボリュームのスナップショットはPodが停止していない状態でも取得できますが、アタッチ/マウントされたままの状態での取得となるため、ファイルシステムが破損する可能性があります。
安全にスナップショットを取得するため、Podを停止しアタッチ/マウントが解除されたことを確認してからスナップショットを取得してください。
「スナップショット取得の際の注意点」をご確認いただき、注意点を理解したうえで実施してください。

IDCFクラウドコンテナコンソールの ストレージ > PersistentVolume 画面で、複製元のIDCFクラウドコンピュートのボリューム名を確認します。

ボリュームと紐づくPodを事前に停止し、IDCFクラウドコンソールから該当ボリュームの詳細を確認します。「アタッチ先」が空欄になっていることを確認してください。これにより、Podからアタッチ/マウントが解除されていることが確認できます。

上記確認後、「実践活用ガイド - スナップショットの作成方法」を参照し、コンテナコンソールから確認した移行対象ボリュームのスナップショットを取得します。

次に、「データディスクのスナップショットからの複製手順を教えてください。」を参照し、取得したスナップショットから任意のボリューム名でボリュームを複製します。ここではボリュームの複製のみを行い、手動での仮想マシンへのアタッチは不要です。

Kind: PersistentVolumeClaim / PersistentVolume のマニフェスト(YAML)を準備する

RKE1クラスターから、移行元ボリュームの Kind: PersistentVolumeClaim および Kind: PersistentVolume のマニフェストを取得し、不要な項目を削除してマニフェストを準備します。

マニフェストの準備例について説明します。以下のYAMLでは、説明に必要な部分のみを抜粋しています。

例として、以下のリソースの移行準備を行います。

PersistentVolumeClaim: example-app-data-example-app-0
PersistentVolume: pvc-de7222d5-be9f-44e3-8e2c-12fae86e684e

Podが利用する Kind: PersistentVolumeClaim / PersistentVolume を確認する

PodのYAMLを見ることで、そのPodが利用しているPersistentVolumeClaim名を確認できます。spec.volumes.persistentVolumeClaim.claimName がPodが利用しているPersistentVolumeClaim名となります。

apiVersion: v1
kind: Pod
spec:
  volumes:
    - name: example-app-data
      persistentVolumeClaim:
        claimName: example-app-data-example-app-0

PersistentVolumeClaim: example-app-data-example-app-0 から紐づくPersistentVolume名を確認することで、紐づくPersistentVolume名を確認できます。spec.volumeName がPodが利用しているPersistentVolume名となります。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: example-app-data-example-app-0
spec:
  volumeName: pvc-de7222d5-be9f-44e3-8e2c-12fae86e684e

マニフェスト(YAML)を取得し、加工する

確認した移行元ボリュームの Kind: PersistentVolumeClaim および Kind: PersistentVolume のマニフェストを取得し、不要な項目を削除した後、利用するボリュームを指定するようにマニフェストを準備します。

修正対象のマニフェスト取得手順については、「kubectlを使用して移行する - RKE1クラスターからマニフェスト(YAML)を取得する」をご確認ください。

取得した Kind: PersistentVolumeClaim および Kind: PersistentVolume のマニフェストから、不要な項目を削除します。

kind: PersistentVolumeClaim以下の部分を削除
- metadata.annotations
- metadata.creationTimestamp
- metadata.managedFields
- metadata.resourceVersion
- metadata.uid
- status
kind: PersistentVolume以下の部分を削除
- metadata.annotations
- metadata.creationTimestamp
- metadata.managedFields
- metadata.resourceVersion
- metadata.uid
- spec.claimRef
- spec.csi.volumeAttributes
- status

上記の項目を削除すると、以下のようになります。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  finalizers:
  - kubernetes.io/pvc-protection
  name: example-app-data-example-app-0
  namespace: default
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: cloudstack-xfs
  volumeMode: Filesystem
  volumeName: pvc-de7222d5-be9f-44e3-8e2c-12fae86e684e

---

apiVersion: v1
kind: PersistentVolume
metadata:
  finalizers:
  - external-provisioner.volume.kubernetes.io/finalizer
  - kubernetes.io/pv-protection
  - external-attacher/volume-cloudstack-idcfcloud-com
  name: pvc-de7222d5-be9f-44e3-8e2c-12fae86e684e
spec:
  accessModes:
  - ReadWriteOnce
  capacity:
    storage: 10Gi
  csi:
    driver: volume.cloudstack.idcfcloud.com
    fsType: xfs
    volumeHandle: 204af794-d2a3-49e9-a95d-22af5a3d98b0
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: topology.volume.cloudstack.idcfcloud.com/zone
          operator: In
          values:
          - ampere
  persistentVolumeReclaimPolicy: Delete
  storageClassName: cloudstack-xfs
  volumeMode: Filesystem

作成したマニフェストの ボリュームID を、複製したボリュームの ボリュームID に書き換えます。

IDCFクラウドコンピュートのUIから複製したボリュームの ボリュームID を確認し、Kind: PersistentVolume のマニフェストにある spec.csi.volumeHandle の値を、確認した ボリュームID に書き換えます。

上記で、Kind: PersistentVolumeClaim および Kind: PersistentVolume のマニフェストの準備は完了です。

マニフェスト(YAML)を適用(Apply)する

準備した Kind: PersistentVolumeClaim および Kind: PersistentVolume のマニフェストをRKE2クラスターに適用します。この際、ボリュームがノードからデタッチされている必要があります。確実にデタッチされていることを確認してから適用してください。

複製ボリュームを利用する場合は、スナップショットからボリューム作成を行った時点ではデタッチされていますが、念のため確実にデタッチされていることをご確認ください。
ボリュームを複製せずにそのまま移行する場合は、RKE1クラスターで該当ボリュームがアタッチされた状態では移行できません。RKE1クラスターでボリュームを使用しているワークロードのPodを停止(Kind: Deployment、Kind:StatefulSet では spec.replicas を0にする)させてください。ボリュームを利用する全てのPodが停止すると、ボリュームがノードからデタッチされます。Pod停止後、確実にデタッチされていることをご確認ください。
デタッチ処理にはしばらく時間がかかる場合があります。

ボリュームのデタッチを確認した後、以下の順番でRKE2クラスターへマニフェストを適用してください。

加工した Kind: PersistentVolume のマニフェストを適用
加工した Kind: PersistentVolumeClaim のマニフェストを適用
Kind: Deployment、Kind: StatefulSet などのボリュームを利用するワークロードのマニフェストを適用

Veeam Kasten を利用した移行

Veeam Softwareが提供するKubernetesネイティブなバックアップソリューション「Veeam Kasten」を利用した移行手順を次のページでご紹介します。

RKE2への移行 Veeam Kastenを利用する

http(s)でインターネットからコンテナに接続する

ロードバランサーを作成する

永続ボリュームを利用する

クラスターを利用できるメンバーを管理する方法

プロジェクトの管理方法

モニタリングの設定方法について

アラート・通知設定方法

ロギングの設定方法について

Custom形式でKubernetesクラスターを構築する

その他パブリッククラウドのKubernetesサービスを利用する

IDCFプライベートクラウドでKubernetesを利用する

RKE2への移行

1. CacheDBに接続するコンピュートとIPアドレスを準備する

2. CacheDBの設定を入力する

3. CacheDBを作成する

4. CacheDBを利用する

5. CacheDBの利用を終了する

RKE1からRKE2への移行方法

はじめに

注意事項

アプリケーションの移行方法

永続ボリュームを利用していないアプリケーション

マニフェストのコード管理がされている場合

マニフェストのコード管理がされていない場合

kubectlを使用して移行する

RKE1クラスターからマニフェスト(YAML)を取得する

取得したマニフェスト(YAML)をRKE2クラスターに適用する

Kind: Deployment / ConfigMap リソースの移行例

Tips

IDCFクラウドコンテナコンソールを使用して移行する

RKE1クラスターからマニフェスト(YAML)を取得する

取得したマニフェスト(YAML)をRKE2クラスターに適用する

永続ボリュームを利用しているアプリケーション

Kubectl cp を使用してデータを移行する

RKE2クラスターにデータ移行先ワークロードを準備する

kubectl cp を使用してPodからデータをコピーしローカルに保存する

Tips

kubectl cp を使用してローカルのデータをPodへデータ移行する

Tips

コンテナ内部の /data 配下をRKE2クラスターへ移行する例

IDCFクラウドのボリュームをそのまま移行する

前提条件

スナップショットを取得し、ボリュームを複製する

スナップショット取得時の注意事項

Kind: PersistentVolumeClaim / PersistentVolume のマニフェスト(YAML)を準備する

Podが利用する Kind: PersistentVolumeClaim / PersistentVolume を確認する

マニフェスト(YAML)を取得し、加工する

マニフェスト(YAML)を適用(Apply)する

Veeam Kasten を利用した移行

コンテナ内部の `/data` 配下をRKE2クラスターへ移行する例