Longhorn エンタープライズレベルのクラウドネイティブコンテナストレージソリューション - 展開

Longhorn エンタープライズレベルのクラウドネイティブコンテナストレージソリューション - 展開

[[418272]]

この記事はWeChatの公開アカウント「Hacker Afternoon Tea」から転載したもので、著者はShaoです。この記事を転載する場合は、Hacker Afternoon Tea公式アカウントまでご連絡ください。

シリーズ

  • Longhornとは何ですか?
  • Longhorn クラウドネイティブ分散ブロックストレージソリューションの設計アーキテクチャとコンセプト

インストール

Longhorn は、さまざまな方法で Kubernetes クラスターにインストールできます。

  • Rancher カタログ アプリ
  • kubectl
  • 舵

インストール要件

Longhorn がインストールされている Kubernetes クラスター内の各ノードは、次の要件を満たしている必要があります。

  • Kubernetes と互換性のあるコンテナ ランタイム (Docker v1.13+、containerd v1.3.7+ など)
  • Kubernetes v1.16+。
  • Kubernetes v1.17以降が推奨されます
  • open-iscsi がインストールされており、iscsid デーモンがすべてのノードで実行されています。これは、Longhorn が Kubernetes に永続ボリュームを提供するためにホスト上の iscsiadm に依存しているために必要です。
  • RWX をサポートするには、各ノードに NFSv4 クライアントがインストールされている必要があります。
  • ホスト ファイル システムは、データを保存するためのファイル エクステントをサポートします。現在サポートしているのは以下です:
    • 拡張子4
    • .XFS の
  • curl、findmnt、grep、awk、blkid、lsblk がインストールされている必要があります。
  • マウント伝播を有効にする必要があります。

Longhorn を適切に導入および操作するには、Longhorn ワークロードを root として実行できる必要があります。

OS/ディストリビューション固有の構成

  • Google Kubernetes Engine (GKE) Longhorn を適切に実行するには、追加の設定が必要です。
  • K3s クラスターには追加の設定が必要です。
  • CoreOS を搭載した RKE クラスターには csi-on-rke-and-coreos が必要です

環境チェックスクリプトの使用

これらの要因に関する十分な情報を収集するのに役立つスクリプトを作成しました。

env check スクリプトを実行する前に、jq をローカルにインストールする必要がある場合があることに注意してください。

スクリプトを実行します:

  1.  curl -sSfL https://raw.githubusercontent.com/longhorn/longhorn/v{{<現在のバージョン >}}/scripts/environment_check.sh |バッシュ

結果の例:

  1.  daemonset.apps/longhorn-environment-チェックが作成されました
  2. ポッドの準備が整うのを待っています(0/3)
  3. すべてのポッドが準備完了 (3/3) 
  4.  
  5.   MountPropagation が有効になりました! 
  6.  
  7. 掃除中…
  8.  daemonset.apps 「longhorn-environment-check」が削除されました
  9. クリーンアップ完了

ポッドセキュリティポリシー

v1.0.2 以降、Longhorn にはデフォルトの Pod セキュリティ ポリシーが付属しており、Longhorn が適切に機能するために必要な権限が提供されます。

Longhorn では、Pod セキュリティ ポリシーが有効になっているクラスターで適切に動作するために特別な構成は必要ありません。

ノートマウントの伝播

Kubernetes クラスターが Rancher v2.0.7+ 以降でプロビジョニングされている場合、MountPropagation 機能はデフォルトで有効になっています。

MountPropagation が無効になっている場合、ベース イメージ機能は無効になります。

open-iscsiをインストールする

open-iscsi をインストールするためのコマンドは、Linux ディストリビューションによって異なります。

GKE の場合、open-iscsi がすでに含まれているため、Ubuntu をゲスト OS イメージとして使用することをお勧めします。

SSH アクセスを許可するには、クラスター セキュリティ グループを編集する必要がある場合があります。

SUSE および openSUSE の場合は、次のコマンドを使用します。

  1.  zypper インストールopen -iscsi

Debian および Ubuntu の場合は、次のコマンドを使用します。

  1.  apt-get インストールopen -iscsi

AmazonLinux2 イメージを使用した EKS Kubernetes Worker AMI を使用する RHEL、CentOS、EKS の場合は、次のコマンドを使用します。

  1.  yum で iscsi-initiator-utils をインストールします

また、ユーザーが open-iscsi を自動的にインストールしやすくするために、iscsi インストーラーも提供しています。

  1.  kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/v{{<現在のバージョン >}}/deploy/prerequisite/longhorn-iscsi-installation.yaml

デプロイが完了したら、次のコマンドを実行してインストーラーのポッドのステータスを確認します。

  1. ポッドを取得します | grep longhorn-iscsi-インストール
  2. longhorn-iscsi-installation-49hd7 1/1 実行中 0 21m
  3.  longhorn-iscsi-installation-pzb7r 1/1 実行中 0 39m

次のコマンドを使用して、ログとインストール結果を表示することもできます。

  1.  kubectl ログ longhorn-iscsi-installation-pzb7r -c iscsi-installation
  2.  ...
  3. インストール済み:
  4.   iscsi-イニシエーター-utils.x86_64 0:6.2.0.874-7.amzn2 
  5.  
  6. 依存関係がインストールされました:
  7.   iscsi-イニシエーター-utils-iscsiuio.x86_64 0:6.2.0.874-7.amzn2 
  8.  
  9. 完了！
  10.  /etc/systemd/system/multi- user .target.wants/iscsid.serviceから/usr/lib/systemd/system/iscsid.serviceへのシンボリックリンクを作成しました。
  11.  iscsiが正常にインストールされました

NFSv4クライアントのインストール

NFSv4 クライアントをインストールするためのコマンドは、Linux ディストリビューションによって異なります。

Debian および Ubuntu の場合は、次のコマンドを使用します。

  1.  apt-get で nfs-common をインストールします

AmazonLinux2 イメージを使用した EKS Kubernetes Worker AMI を使用する RHEL、CentOS、EKS の場合は、次のコマンドを使用します。

  1.  yum で nfs-utils をインストールします

また、ユーザーが nfs-client を自動的にインストールしやすくするために、nfs インストーラーも提供しています。

  1.  kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/v{{<現在のバージョン >}}/deploy/prerequisite/longhorn-nfs-installation.yaml

デプロイが完了したら、次のコマンドを実行してインストーラーのポッドのステータスを確認します。

  1. ポッドを取得します | grep longhorn-nfs-インストール
  2. 名前準備完了 ステータス 再起動 年齢
  3. longhorn-nfs-installation-t2v9v 1/1 実行中 0 143分
  4. longhorn-nfs-installation-7nphm 1/1 実行中 0 143分

次のコマンドを使用して、ログとインストール結果を表示することもできます。

  1.  kubectl ログ longhorn-nfs-installation-t2v9v -c nfs-installation
  2.  ...
  3.  NFS のインストールに成功しました

Kubernetesのバージョンを確認する

次のコマンドを使用してKubernetesサーバーのバージョンを確認します。

  1.  kubectl バージョン

結果：

  1. クライアント バージョン: version.Info{メジャー: "1" 、マイナー: "19" 、GitVersion: "v1.19.3" 、GitCommit: "1e11e4a2108024935ecfcb2912226cedeafd99df" 、GitTreeState: "clean" 、BuildDate: "2020-10-14T12:50:19Z" 、GoVersion: "go1.15.2" 、コンパイラ: "gc" 、プラットフォーム: "linux/amd64" }
  2. サーバー バージョン: version.Info{メジャー: "1" 、マイナー: "17" 、GitVersion: "v1.17.4" 、GitCommit: "8d8aa39598534325ad77120c120a22b3a990b5ea" 、GitTreeState: "clean" 、BuildDate: "2020-03-12T20:55:23Z" 、GoVersion: "go1.13.8" 、コンパイラ: "gc" 、プラットフォーム: "linux/amd64" }

サーバーバージョンは v1.16 以上である必要があります。

Rancherカタログアプリとしてインストール

Rancher カタログを通じて Longhorn をインストールする利点の 1 つは、Rancher が Longhorn UI の認証を提供することです。

Longhorn の新しいバージョンが利用可能な場合は、カタログ アプリ画面に「アップグレード可能」というサインが表示されます。 [アップグレード] ボタンをクリックすると、Longhorn マネージャーをアップグレードできます。

インストール

オプション: Storage など、Longhorn 用の新しいプロジェクトを作成することをお勧めします。

Longhorn をインストールするクラスターとプロジェクトに移動します。

3. カタログ アプリ画面に移動します。

4. カタログで Longhorn 項目を見つけてクリックします。

5. オプション: デフォルト設定をカスタマイズします。 6. 「起動」をクリックします。 Longhorn は longhorn-system 名前空間にインストールされます。

これでLonghornがインストールされました。

7. index.html リンクをクリックして、Longhorn ダッシュボードに移動します。

Longhorn を正常にインストールしたら、カタログ アプリ画面に移動して Longhorn UI にアクセスできます。

Kubectlを使用してインストールする

Longhornのインストール

次のコマンドを使用して、任意の Kubernetes クラスターに Longhorn をインストールします。

  1.  kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/v{{<現在のバージョン >}}/deploy/longhorn.yaml

インストールの進行状況を監視する 1 つの方法は、longhorn-system 名前空間で作成されるポッドを監視することです。

  1.  kubectl ポッドを取得 \
  2.  --namespace longhorn-system \  
  3.  - 時計 

デプロイメントが成功したかどうかを確認します。

  1.  $ kubectl -n longhorn-system ポッドを取得します
  2. 名前準備完了 ステータス 再起動 年齢
  3. csi-attacher-6fdc77c485-8wlpg 1/1 実行中 0 9d
  4.  csi-attacher-6fdc77c485-psqlr 1/1 実行中 0 9d
  5.  csi-attacher-6fdc77c485-wkn69 1/1 実行中 0 9d
  6.  csi-provisioner-78f7db7d6d-rj9pr 1/1 実行中 0 9d
  7.  csi-provisioner-78f7db7d6d-sgm6w 1/1 実行中 0 9d
  8.  csi-provisioner-78f7db7d6d-vnjww 1/1 実行中 0 9d
  9.  engine-image-ei-6e2b0e32-2p9nk 1/1 実行中 0 9d
  10.  engine-image-ei-6e2b0e32-s8ggt 1/1 実行中 0 9d
  11.  engine-image-ei-6e2b0e32-wgkj5 1/1 実行中 0 9d
  12.  longhorn-csi-plugin-g8r4b 2/2 実行中 0 9d
  13.  longhorn-csi-plugin-kbxrl 2/2 実行中 0 9d
  14.  longhorn-csi-plugin-wv6sb 2/2 実行中 0 9d
  15.  longhorn-driver-deployer-788984b49c-zzk7b 1/1 実行中 0 9d
  16.  longhorn-manager-nr5rs 1/1 実行中 0 9d
  17.  longhorn-manager-rd4k5 1/1 実行中 0 9d
  18.  longhorn-manager-snb9t 1/1 実行中 0 9d
  19.  longhorn-ui-67b9b6887f-n7x9q 1/1 実行中 0

Longhorn UI へのアクセスを有効にするには、Ingress コントローラーを設定する必要があります。 Longhorn UI への認証はデフォルトでは有効になっていません。

展開されたリソースのリスト

次のプロジェクトが Kubernetes にデプロイされます。

  1. 名前空間: longhorn-system

すべての Longhorn ビットがこの名前空間に適用されます。

  1. サービスアカウント: longhorn サービス アカウント

サービス アカウントは longhorn-system 名前空間に作成されます。

  1. クラスターロール: longhorn ロール

この役割には次のアクセス権があります:

  • apiextension.k8s.io 内 (すべての動詞)
    • カスタムリソース定義
    • コア（すべての動詞）
    • /状態
    • /ログ
    • ポッド
    • イベント
    • 永続ボリューム
    • 永続ボリュームクレーム
    • ノード
    • プロキシ/ノード
    • 秘密
    • サービス
    • エンドポイント
    • configMaps
  • コア内
    • 名前空間 (取得、リスト)
  • アプリ内（すべての動詞）
    • デーモンセット
    • ステートフルセット
    • 展開
  • バッチで（すべての動詞）
    • 仕事
    • cronジョブ
  • storage.k8s.io 内 (すべての動詞)
    • ストレージクラス
    • ボリューム添付ファイル
    • シノデス
    • csiドライバー
  • coordination.k8s.io で
    • リース

ClusterRoleBinding: longhorn-bind

これにより、longhorn-role が longhorn-system 名前空間の longhorn-service-account に接続されます。

カスタムリソース定義

次のCustomResourceDefinitionsがインストールされます

  • longhorn.ioで
    • エンジン
    • レプリカ
    • 設定
    • ボリューム
    • エンジン画像
    • ノード
    • インスタンスマネージャー

Kubernetes API オブジェクト

  • デフォルト設定の構成マップ
  • longhorn-manager デーモンセット
  • longhorn-backendサービスはlonghorn-manager DaemonSetをKubernetesに内部的に公開します。
  • longhorn-ui デプロイメント
  • longhorn-frontendサービスはlonghorn-uiをKubernetesに内部的に公開します。
  • longhorn-driver-deployer は CSI ドライバーを展開します
  • longhorn ストレージクラス

Helmを使用してインストールする

Helmのインストールに関する注意事項

Helm のインストールに関するヘルプについては、公式ドキュメントを参照してください。

Helm 3.0 より前のバージョンを使用している場合は、ロールベースのアクセス制御 (RBAC) を使用して Kubernetes クラスターに Tiller をインストールする必要があります。

Longhornのインストール

Longhorn Helm リポジトリを追加します。

  1.  helm リポジトリに longhornを追加しますhttps://charts.longhorn.io

リポジトリから最新のチャートを取得します。

  1.  helm リポジトリの更新 

Longhorn を longhorn-system 名前空間にインストールします。 Helm 2 を使用して Longhorn をインストールするには、次のコマンドを使用します。

  1.  helm をインストール longhorn/longhorn --name longhorn --namespace longhorn-system  

Helm 3 を使用して Longhorn をインストールするには、次のコマンドを使用します。

  1.  kubectl で名前空間 longhorn-systemを作成します。
  2.  helm インストール longhorn longhorn/longhorn --namespace longhorn-system  

デプロイメントが成功したことを確認するには、次のコマンドを実行します。

  1.  kubectl -n longhorn-system ポッドを取得します

結果は次のようになります。

  1. 名前準備完了 ステータス 再起動 年齢
  2. 互換csi-attacher-d9fb48bcf-2rzmb 1/1 実行中 0 8分58秒
  3. csi-attacher-78bf9b9898-grn2c 1/1 実行中 0 32 秒
  4. csi-attacher-78bf9b9898-lfzvq 1/1 実行中 0 8 分 59 秒
  5. csi-attacher-78bf9b9898-r64sv 1/1 実行中 0 33秒
  6. csi-provisioner-8599d5bf97-c8r79 1/1 実行中 0 33秒
  7. csi-provisioner-8599d5bf97-fc5pz 1/1 実行中 0 33 秒
  8. csi-provisioner-8599d5bf97-p9psl 1/​​1 実行中 0 8 分 59 秒
  9. csi-resizer-586665f745-b7p6h 1/1 実行中 0 8分59秒
  10. csi-resizer-586665f745-kgdxs 1/1 実行中 0 33秒
  11. csi-resizer-586665f745-vsvvq 1/1 実行中 0 33秒
  12. engine-image-ei-e10d6bf5-pv2s6 1/1 実行中 0 9分30秒
  13. instance-manager-e-379373af 1/1 実行中 0 8分41秒
  14. instance-manager-r-101f13ba 1/1 実行中 0 8分40秒
  15. longhorn-csi-plugin-7v2dc 4/4 実行中 0 8分59秒
  16. longhorn-driver-deployer-775897bdf6-k4sfd 1/1 実行中 0 10m
  17.  longhorn-manager-79xgj 1/1 実行中 0 9分50秒
  18. longhorn-ui-9fbb5445-httqf 0/1 実行中

Longhorn UI へのアクセスを有効にするには、Ingress コントローラーを設定する必要があります。 Longhorn UI への認証はデフォルトでは有効になっていません。

UI へのアクセス

アクセスと認証の前提条件

これらの手順では、Longhorn がすでにインストールされていることを前提としています。

Longhorn YAML マニフェストをインストールした場合は、クラスターへの外部トラフィックを許可するように Ingress コントローラーを設定する必要があります。認証はデフォルトでは有効になっていません。これは、Helm と kubectl の両方のインストールに適用されます。

Longhorn が Rancher カタログ アプリとしてインストールされている場合、Rancher はアクセス制御 (rancher-proxy) を備えた Ingress コントローラーを自動的に作成します。

Longhorn UI へのアクセス

Kubernetes クラスターに Longhorn をインストールすると、UI ダッシュボードにアクセスできるようになります。

1. Longhorn の外部サービス IP を取得します。

  1.  kubectl -n longhorn-system でサービスを取得します

Longhorn v0.8.0 の場合、出力は次のようになり、longhorn UI には longhorn-frontend の CLUSTER-IP を使用してアクセスします。

  1. 名前タイプ クラスター IP 外部 IP ポート 年齢
  2. longhorn-backend ClusterIP 10.20.248.250 <なし> 9500/TCP 58m
  3.  longhorn-frontend ClusterIP 10.20.245.110 <なし> 80/TCP 58m

上記の例では、IP は 10.20.245.110 です。

Longhorn v0.8.0+ では、UI サービス タイプが LoadBalancer から ClusterIP に変更されました。

2. ブラウザで longhorn-frontend の IP に移動します。

Longhorn UI は次のようになります。

基本認証を使用した Ingress の作成 (nginx)

kubectl または Helm を使用して Kubernetes クラスターに Longhorn をインストールした場合は、外部トラフィックが Longhorn UI に到達できるように Ingress を作成する必要があります。

デフォルトでは、kubectl および Helm インストールでは認証が有効になっていません。これらの手順では、nginx Ingress コントローラーでアノテーションを使用して、基本認証を備えた Ingress を作成する方法を学習します。

基本認証ファイル auth を作成します。生成されたファイルの名前が auth であることが重要です (実際には、シークレットにはキー data.auth があります)。そうでない場合、Ingress は 503 を返します。

  1.  $ユーザー=;パスワード=; echo "${USER}:$(openssl passwd -stdin -apr1 <<< ${PASSWORD})" >> 認証

シークレットを作成します:

  1.  $ kubectl -n longhorn-systemシークレットを作成します。汎用基本認証--from-file=auth  

Ingress マニフェスト longhorn-ingress.yml を作成します。

  1.  APIバージョン: networking.k8s.io/v1
  2. 種類: イングレス
  3. メタデータ:
  4. 名前: longhorn-ingress
  5.   名前空間: longhorn-system
  6.   注釈:
  7.     #認証の種類
  8.     nginx.ingress.kubernetes.io/認証タイプ: 基本
  9.     # コントローラがHTTPSにリダイレクト（308）するのを防ぐ
  10.     nginx.ingress.kubernetes.io/ssl-redirect: 'false'  
  11.     ＃名前 ユーザー/パスワード定義を含むシークレット​
  12.     nginx.ingress.kubernetes.io/auth-secret: 基本認証
  13.     #認証が必要な理由を適切なコンテキストで表示するメッセージ
  14.     nginx.ingress.kubernetes.io/auth-realm: '認証が必要です'  
  15. 仕様:
  16.   ルール:
  17.   - http:
  18.       パス:
  19.       -pathType: プレフィックス
  20.         パス： "/"  
  21.         バックエンド:
  22.           サービス：
  23. 名前: longhorn-frontend
  24.             ポート：
  25.               番号: 80

Ingress を作成する:

  1.  $ kubectl -n longhorn-system を適用 -f longhorn-ingress.yml

例えば：

  1.  $ USER =foo;パスワード=bar; echo "${USER}:$(openssl passwd -stdin -apr1 <<< ${PASSWORD})" >> 認証
  2. $ 猫認証
  3. foo:$apr1$FnyKCYKb$6IP2C45fZxMcoLwkOwf7k0 
  4.  
  5.  $ kubectl -n longhorn-system シークレットを作成します。汎用基本認証--from-file=auth  
  6.  secret/basic-auth を作成しました
  7. $ kubectl -n longhorn-system シークレットを取得 basic-auth -o yaml
  8.  APIバージョン: v1
  9. データ：
  10.   作者: Zm9vOiRhcHIxJEZueUtDWUtiJDZJUDJDNDVmWnhNY29Md2tPd2Y3azAK
  11. 種類: 秘密
  12. メタデータ:
  13.   作成タイムスタンプ: "2020-05-29T10:10:16Z"  
  14. 名前: 基本認証
  15.   名前空間: longhorn-system
  16.   リソースバージョン: "2168509"  
  17.   セルフリンク: /api/v1/namespaces/longhorn-system/secrets/basic-auth
  18.   ユーザID: 9f66233f-b12f-4204-9c9d-5bcaca794bb7
  19. タイプ: 不透明
  20.  
  21.  $ エコー "
  22.  APIバージョン: networking.k8s.io/v1
  23. 種類: イングレス
  24. メタデータ:
  25. 名前: longhorn-ingress
  26.   名前空間: longhorn-system
  27.   注釈:
  28.     #認証の種類
  29.     nginx.ingress.kubernetes.io/認証タイプ: 基本
  30.     # コントローラがHTTPSにリダイレクト（308）するのを防ぐ
  31.     nginx.ingress.kubernetes.io/ssl-redirect: 'false'  
  32.     ＃名前 ユーザー/パスワード定義を含むシークレット​
  33.     nginx.ingress.kubernetes.io/auth-secret: 基本認証
  34.     #認証が必要な理由を適切なコンテキストで表示するメッセージ
  35.     nginx.ingress.kubernetes.io/auth-realm: '認証が必要です'  
  36. 仕様:
  37.   ルール:
  38.   - http:
  39.       パス:
  40.       -pathType: プレフィックス
  41.         パス： "/"  
  42.         バックエンド:
  43.           サービス：
  44. 名前: longhorn-frontend
  45.             ポート：
  46.               番号: 80
  47.  " | kubectl -n longhorn-systemを作成-f -
  48.  ingress.networking.k8s.io/longhorn-ingress が作成されました
  49.  
  50.  $ kubectl -n longhorn-system でイングレスを取得します
  51. 名前ホスト アドレス ポート 年齢
  52. ロングホーンイングレス * 45.79.165.114,66.228.45.37,97.107.142.125 80 2分7秒
  53.  
  54.  $ カール -v http://97.107.142.125/
  55.  * 97.107.142.125 を試行中...
  56.  * TCP_NODELAY設定 
  57.  * 97.107.142.125 (97.107.142.125) ポート80 (#0)に接続
  58. > GET / HTTP/1.1
  59.  > ホスト: 97.107.142.125
  60.  >ユーザーエージェント: curl/7.64.1
  61.  > 受け入れる: */*
  62.  >
  63.  < HTTP/1.1 401 権限がありません
  64. < サーバー: openresty/1.15.8.1
  65.  <日付: 2020年5月29日（金）11:47:33 GMT
  66.  < コンテンツタイプ: text/html
  67.  < コンテンツの長さ: 185
  68.  <接続: キープアライブ
  69. < WWW-Authenticate: 基本領域 = "認証が必要"  
  70.  <
  71.  <html>
  72.  <head><title>401認証が必要です</title></head>
  73.  <本文>
  74.  <center><h1>401認証が必要です</h1></center>
  75.  <hr><center>openresty/1.15.8.1</center>
  76.  </本文>
  77.  </html>
  78.  *ホスト 97.107.142.125への接続#0はそのまま残ります
  79. *接続0を閉じています
  80.  
  81.  $ カール -v http://97.107.142.125/ -u foo:bar
  82.  * 97.107.142.125 を試行中...
  83.  * TCP_NODELAY設定 
  84.  * 97.107.142.125 (97.107.142.125) ポート80 (#0)に接続
  85. * Basicを使用したサーバー認証 ユーザー  「フー」  
  86.  > GET / HTTP/1.1
  87.  > ホスト: 97.107.142.125
  88.  >認証: 基本 Zm9vOmJhcg==
  89.  >ユーザーエージェント: curl/7.64.1
  90.  > 受け入れる: */*
  91.  >
  92.  < HTTP/1.1 200 OK
  93.  <日付: 2020年5月29日（金）11:51:27 GMT
  94.  < コンテンツタイプ: text/html
  95.  < コンテンツの長さ: 1118
  96.  <最終更新日: 2020年5月28日(木) 00:39:41 GMT
  97.  < ETag: "5ecf084d-3fd"  
  98.  < キャッシュ制御:最大-age=0
  99.  <
  100.  <!DOCTYPE html>
  101.  <html lang= "ja" >
  102.  ......

AWS EKS Kubernetes クラスターの追加手順

nginx Ingress コントローラーをインターネットに公開するには、ELB (Elastic Load Balancer) を作成する必要があります。追加料金が発生する場合があります。

nginx ingress コントローラーのドキュメントに従って、必要なリソースを作成します。

ELB を作成するには、ingress-nginx/deploy/#aws の手順に従います。

参考文献

https://kubernetes.github.io/ingress-nginx/

アップグレード

ここでは、以前のすべてのバージョンから最新の Longhorn にアップグレードする方法について説明します。

Longhorn のアップグレード

アップグレード プロセスは通常、2 段階のプロセスです。最初に Longhorn マネージャーを最新バージョンにアップグレードし、次に最新の Longhorn マネージャーを使用して Longhorn エンジンを手動で最新バージョンにアップグレードします。

1. Longhornマネージャをアップグレードする

v1.1.x からアップグレードするには、longhorn-manager を参照してください。

2. Longhorn Engineを手動でアップグレードする

Longhorn Manager をアップグレードした後、Longhorn UI を使用して Longhorn Engine もアップグレードする必要があります。

3. Longhorn Engineを自動的にアップグレードする

Longhorn v1.1.1 以降では、エンジンを自動的にアップグレードするためのオプションが提供されます。

注意: Longhorn v1.1.0 および v1.1.1 で提供されるインスタンス マネージャー イメージ v1_20201216 には、数百のボリュームを持つ大規模なクラスターでデッドロックを引き起こす可能性があるバグが含まれています。詳細については、longhorn/issues/2697 を参照してください。 Longhorn v1.1.2 には、デッドロックを修正する新しいインスタンス マネージャー イメージ v1_20210621 が付属していますが、ボリュームのエンジン/レプリカ プロセスは、次にボリュームがデタッチ/アタッチされるまで、古いインスタンス マネージャーから新しいインスタンス マネージャーに移行されません。 Longhorn では、ボリュームのデータ プレーンを中断したくないためにこれを行います。

古いインスタンス マネージャーでデッドロックが発生した場合は、issues/2697#issuecomment-879374809 の回復手順に従ってください。

Longhorn Manager のアップグレード

v1.1.x からのアップグレード

v1.1.x から v1.1.2 へのアップグレードのみサポートされます。その他のバージョンの場合は、まず v1.1.x にアップグレードしてください。

Engine の v1.1.x から v1.1.2 へのライブ アップグレードをサポートします。

Longhorn が Rancher アプリとしてインストールされている場合のエアギャップ アップグレードでは、イメージ名を変更し、レジストリ URL 部分を削除する必要があります。

たとえば、Longhorn イメージ セクションのイメージ registry.example.com/longhorn/longhorn-manager:v1.1.2 は longhorn/longhorn-manager:v1.1.2 に変更されます。

アップグレードの準備

Longhorn が Helm Chart を使用してインストールされた場合、または Rancher カタログ アプリの一部としてインストールされた場合は、デフォルトの StorageClass のパラメーターが変更されていないことを確認してください。デフォルトの StorageClass パラメータを変更すると、チャートのアップグレードが失敗する可能性があります。 StorageClass のパラメータを再構成する場合は、デフォルトの StorageClass の構成をコピーして別の StorageClass を作成できます。

  1. 現在​ デフォルトのStorageClass には次のパラメータがあります。 
  2.  
  3.     パラメータ:
  4.       numberOfReplicas: <ユーザーが指定したレプリカ数、 3  デフォルト>
  5.       古いレプリカタイムアウト: "30"  
  6.       バックアップから: ""  
  7.       ベースイメージ: ""  

アップグレード

前提条件: アップグレードする前に必ずボリュームをバックアップしてください。何か問題が発生した場合は、バックアップを使用してボリュームを復元できます。

kubectl を使用してアップグレードするには、次のコマンドを実行します。

  1.  kubectl を適用 -f https://raw.githubusercontent.com/longhorn/longhorn/v1.1.2/deploy/longhorn.yaml

Helm を使用してアップグレードするには、次のコマンドを実行します。

  1.  helm アップグレード longhorn ./longhorn/chart

Rancher 2.1 以降で管理される Kubernetes クラスターでは、カタログ アプリ longhorn-system をアップグレードする手順はインストール手順と同様です。

次に、すべてのポッドが実行を開始し、Longhorn UI が動作するまで待ちます。例えば：

  1.  $ kubectl -n longhorn-system ポッドを取得します
  2. 名前準備完了 ステータス 再起動 年齢
  3. csi-attacher-78bf9b9898-mb7jt 1/1 実行中 1 3 分 11 秒
  4. csi-attacher-78bf9b9898-n2224 1/1 実行中 1 3 分 11 秒
  5. csi-attacher-78bf9b9898-rhv6m 1/1 実行中 1 3 分 11 秒
  6. csi-provisioner-8599d5bf97-dr5n4 1/1 実行中 1 2 分 58 秒
  7. csi-provisioner-8599d5bf97-drzn9 1/1 ランニング 1 2分58秒
  8. csi-provisioner-8599d5bf97-rz5fj 1/1 実行 1 2m58s
  9.  csi-resizer-586665f745-5bkcm 1/1 実行中 0 2分49秒
  10. csi-resizer-586665f745-vgqx8 1/1 実行中 0 2分49秒
  11. csi-resizer-586665f745-wdvdg 1/1 実行中 0 2分49秒
  12. engine-image-ei-62c02f63-bjfkp 1/1 実行中 0 14分
  13. engine-image-ei-62c02f63-nk2jr 1/1 実行中 0 14m
  14.  engine-image-ei-62c02f63-pjtgg 1/1 実行中 0 14分
  15. engine-image-ei-ac045a0d-9bbb8 1/1 実行中 0 3分46秒
  16. engine-image-ei-ac045a0d-cqvv2 1/1 実行中 0 3分46秒
  17. engine-image-ei-ac045a0d-wzmhv 1/1 実行中 0 3分46秒
  18. instance-manager-e-4deb2a16 1/1 実行中 0 3分23秒
  19. instance-manager-e-5526b121 1/1 実行中 0 3分28秒
  20. instance-manager-e-eff765b6 1/1 実行中 0 2分59秒
  21. instance-manager-r-3b70b0db 1/1 実行中 0 3分27秒
  22. instance-manager-r-4f7d629a 1/1 実行中 0 3分22秒
  23. instance-manager-r-bbcf4f17 1/1 実行中 0 2分58秒
  24. longhorn-csi-plugin-bkgjj 2/2 実行中 0 2分39秒
  25. longhorn-csi-plugin-tjhhq 2/2 実行中 0 2分39秒
  26. longhorn-csi-plugin-zslp6 2/2 実行中 0 2分39秒
  27. longhorn-driver-deployer-75b6bf4d6d-d4hcv 1/1 実行中 0 3分57秒
  28. longhorn-manager-4j77v 1/1 実行中 0 3分53秒
  29. longhorn-manager-cwm5z 1/1 実行中 0 3分50秒
  30. longhorn-manager-w7scb 1/1 実行中 0 3分50秒
  31. longhorn-ui-8fcd9fdd-qpknp 1/1 実行中 0 3

アップグレード後

既存のボリュームの破損を回避し、非推奨の設定である Guaranteed Engine CPU から新しいインスタンス マネージャーの CPU 予約メカニズムに切り替えるために、Longhorn はアップグレード中に非推奨の設定値に従って各ノードからの Engine Manager CPU Request と Replica Manager CPU Request を自動的に設定します。そうすると、新しいグローバル インスタンス マネージャーの CPU 設定である「保証されたエンジン マネージャー CPU」と「保証されたレプリカ マネージャー CPU」は有効になりません。新しいメカニズムとセットアップ手順をチェックして、調整が必要かどうかを確認することをお勧めします。

トラブルシューティング

エラー: 「longhorn」は無効です: プロビジョナー: 禁止: プロビジョナーへの更新は禁止されています。

これは、デフォルトの storageClass にいくつかの変更が加えられたことを意味し、アップグレードする前に古いものをクリーンアップする必要があります。

非推奨の StorageClass をクリーンアップするには、次のコマンドを実行します。

  1.  kubectl delete -f https://raw.githubusercontent.com/longhorn/longhorn/v1.1.2/examples/storageclass.yaml

Longhorn Engineを手動でアップグレードする

このセクションでは、Longhorn UI から Longhorn Engine を手動でアップグレードする方法を学習します。

前提条件

Longhorn エンジン イメージをアップグレードする前に、必ずバックアップしてください。

Longhorn エンジンをアップグレードする前に、Longhorn マネージャーをアップグレードしてください。

注意: Longhorn v1.1.0 および v1.1.1 で提供されるインスタンス マネージャー イメージ v1_20201216 には、数百のボリュームを持つ大規模なクラスターでデッドロックを引き起こす可能性があるバグが含まれています。詳細については、longhorn/issues/2697 を参照してください。 Longhorn v1.1.2 には、デッドロックを修正する新しいインスタンス マネージャー イメージ v1_20210621 が付属していますが、ボリュームのエンジン/レプリカ プロセスは、次にボリュームがデタッチ/アタッチされるまで、古いインスタンス マネージャーから新しいインスタンス マネージャーに移行されません。 Longhorn では、ボリュームのデータ プレーンを中断したくないためにこれを行います。

エンジン/レプリカ プロセスが古いインスタンス マネージャー上に残っている間にデッドロックが発生する可能性を減らすには、ボリュームのエンジンを小さなバッチ (一度に 2 つまたは 3 つのボリュームなど) でアップグレードする必要があります。

オフラインアップグレード

ライブ アップグレードが不可能な場合、またはボリュームが劣化状態にある場合は、次の手順を実行します。

  1. 関連するワークロードのデタッチ手順に従います。
  2. すべてのボリュームを選択するには一括選択を使用します。バッチ操作ボタン「エンジンのアップグレード」をクリックし、リストから使用可能なエンジン イメージを選択します。これは、このバージョン マネージャーに付属するデフォルトのエンジンです。
  3. すべてのワークロードを再開します。 Kubernetes ワークロードの一部ではないボリュームは、Longhorn UI から接続する必要があります。

ライブアップグレード

v1.1.x から v1.1.2 へのアップグレードではライブ アップグレードがサポートされます。

iSCSI フロントエンドは Live Upgrade をサポートしていません。

ライブ アップグレードは正常なボリュームに対してのみ実行する必要があります。

  1. アップグレードするボリュームを選択します。
  2. ドロップダウン メニューで [エンジンのアップグレード] をクリックします。
  3. アップグレードするエンジン イメージを選択します。
  4. UI によって現在のイメージがリストから除外されるため、通常はこれがリスト内の唯一のエンジン イメージになります。

[OK]をクリックします。

ライブ アップグレード中、ユーザーにはレプリカの数が一時的に 2 倍表示されます。アップグレードが完了すると、ユーザーには以前と同じ数のレプリカが表示され、ボリュームのエンジン イメージ フィールドが更新されます。

ライブ アップグレード後も、Rancher または Kubernetes では、エンジン イメージの古いバージョンとレプリカの新しいバージョンが引き続き表示されることに注意してください。これは予想通りです。ボリューム詳細ページにボリューム イメージとして新しいバージョンのイメージが表示されている場合は、アップグレードは成功しています。

古い画像をクリーンアップする

すべてのイメージがアップグレードされたら、Longhorn UI から [設定]/[エンジン イメージ] を選択します。これで、デフォルト以外のミラーを削除できるはずです。

Longhorn Engine を自動的にアップグレードする

Longhorn v1.1.1 以降では、Longhorn マネージャーをアップグレードした後、Longhorn ボリュームを新しいデフォルトのエンジン バージョンに自動的にアップグレードするオプションが提供されます。この機能により、Longhorn をアップグレードするときに必要な手作業の量が削減されます。この機能に関連する概念は次のとおりです。

1. ノードあたりの同時自動エンジンアップグレード制限設定

これは、Longhorn マネージャーをアップグレードした後、Longhorn がボリュームのエンジンを新しいデフォルトのエンジン イメージに自動的にアップグレードする方法を制御する設定です。この設定の値は、ノードごとに同時にデフォルトのエンジン イメージにアップグレードできるエンジンの最大数を指定します。値が 0 の場合、Longhorn はボリュームのエンジンをデフォルト バージョンに自動的にアップグレードしません。値が大きいほど、エンジンのアップグレード プロセスがより速く完了します。

ただし、この設定に大きな値を指定すると、エンジンのアップグレード プロセス中にノードの CPU とメモリがより多く消費されます。エラーに多少の余地を残しつつ、アップグレードの失敗が多すぎてシステムに負担がかからないように、この値を 3 に設定することをお勧めします。

2. さまざまなボリューム条件下での Longhorn の動作。

以下の場合、ノードあたりの同時自動エンジン アップグレード制限が 0 より大きく設定されていると想定されます。

  • 追加ボリューム

ボリュームが接続されていて正常な場合、Longhorn はボリュームのエンジンを新しいデフォルトのエンジン イメージに自動的にライブ アップグレードします。

  • 別冊

Longhorn は、分離されたボリューム上でオフライン アップグレードを自動的に実行します。

  • 災害復旧ボリューム

Longhorn は、災害復旧ボリュームの完全な復元をトリガーするため、災害復旧ボリュームを新しいデフォルトのエンジン イメージに自動的にアップグレードしません。完全な復元は、システム上で実行されている他の Longhorn ボリュームのパフォーマンスに影響を与える可能性があります。したがって、Longhorn では、災害復旧ボリューム エンジンを手動でアップグレードする適切なタイミング (たとえば、システムがアイドル状態のときやメンテナンス中など) をユーザーが決定できます。

ただし、DR ボリュームをアクティブ化すると、アクティブ化されてから切断されます。この時点で、Longhorn はボリュームを切断したときと同様に、ボリュームのオフライン アップグレードを自動的に実行します。

3. アップグレードが失敗した場合はどうなりますか?

ボリュームのアップグレードが失敗した場合、ボリューム仕様のエンジン イメージはボリューム状態のエンジン イメージとは異なるままになります。 Longhorn は、アップグレードが成功するまで再試行し続けます。

ノードごとにアップグレードできないボリュームが多すぎる場合 (つまり、ノードごとの同時自動エンジン アップグレード制限設定を超えた場合)、Longhorn はそのノード上のボリュームのアップグレードを停止します。

Longhorn のアンインストール

このセクションでは、Longhorn をアンインストールする方法について説明します。

  • 前提条件
  • Rancher UI から Longhorn をアンインストールする
  • Helm を使用して Longhorn をアンインストールする
  • kubectl を使用して Longhorn をアンインストールする
  • トラブルシューティング

前提条件

Kubernetes クラスターの損傷を防ぐために、Longhorn ボリューム (PersistentVolume、PersistentVolumeClaim、StorageClass、Deployment、StatefulSet、DaemonSet など) を使用するすべての Kubernetes ワークロードを削除することをお勧めします。

Rancher UI から Longhorn をアンインストールする

Rancher UI から、[カタログ アプリ] タブに移動し、Longhorn アプリを削除します。

Helm を使用して Longhorn をアンインストールする

次のコマンドを実行します:

  1.  helm アンインストール longhorn -n longhorn-system

kubectl を使用して Longhorn をアンインストールする

システムから CRD をクリーンアップするアンインストール ジョブを作成し、成功を待ちます。

  1.  kubectl create -f https://raw.githubusercontent.com/longhorn/longhorn/v1.1.2/uninstall/uninstall.yaml
  2.  kubectl get job/longhorn-uninstall -nデフォルト-w

サンプル出力:

  1.  $ kubectl create -f https://raw.githubusercontent.com/longhorn/longhorn/v1.1.2/uninstall/uninstall.yaml
  2.  serviceaccount/longhorn-uninstall-service-account が作成されました
  3. clusterrole.rbac。認証.k8s.io/longhorn-uninstall-role が作成されました
  4. クラスターロールバインディング.rbac。認証.k8s.io/longhorn-uninstall-bind が作成されました
  5. job.batch/longhorn-uninstall が作成されました
  6.  
  7.  $ kubectl get job/longhorn-uninstall -nデフォルト-w
  8. 名前完了 期間 年齢
  9. longhorn-アンインストール 0/1 3秒 3秒
  10. longhorn-アンインストール 1/1 20秒 20秒
  11. ^C

残りのコンポーネントを削除します。

  1.  kubectl delete -f https://raw.githubusercontent.com/longhorn/longhorn/v1.1.2/deploy/longhorn.yaml
  2.  kubectl delete -f https://raw.githubusercontent.com/longhorn/longhorn/v1.1.2/uninstall/uninstall.yaml

ヒント: 最初に kubectl delete -f https://raw.githubusercontent.com/longhorn/longhorn/v{{< current-version >}}/deploy/longhorn.yaml を試してそこで行き詰まった場合は、Ctrl + C を押してから kubectl create -f https://raw.githubusercontent.com/longhorn/longhorn/v{{< current-version >}}/uninstall/uninstall.yaml を実行してください。これも Longhorn の削除に役立ちます。最後に、残りのコンポーネントをクリーンアップすることを忘れないでください。

トラブルシューティング

アンインストール手順に従わずに、Rancher UIからLonghornアプリケーションを削除しました

(同じバージョンの) Longhorn アプリを再デプロイします。上記のアンインストール手順に従ってください。

CRD の問題点

何らかの理由で CRD インスタンスまたは CRD 自体を削除できない場合は、次のコマンドを実行してクリーンアップします。注意: これにより、Longhorn のすべての状態がクリアされます。

  1.  # CRDファイナライザ、インスタンス、定義を削除する
  2. $ (kubectl get crd -o jsonpath={.items[*].metadata. name } | tr ' ' のcrdの場合  '\n' | grep longhorn.rancher.io);する
  3.   kubectl -n ${NAMESPACE} を取得します $crd -o yaml | sed "s/\- longhorn.rancher.io//g" | kubectl を適用 -f -
  4.   kubectl -n ${NAMESPACE} で$crd --allを削除します 
  5.   kubectl crd/$crdを削除します
  6. 終わり

ボリュームはUIから接続/切断できますが、Kubernetes Pods/StatefulSetsなどでは使用できません。

ボリューム プラグイン ディレクトリが正しく設定されていることを確認します。ユーザーが明示的に設定しない限り、自動的に検出されます。注意: FlexVolume プラグインは Longhorn v0.8.0 以降では非推奨になっており、使用しないでください。

デフォルトでは、Kubernetes は公式ドキュメントに記載されているように /usr/libexec/kubernetes/kubelet-plugins/volume/exec/ を使用します。

ベンダーによっては、さまざまな理由からカタログを変更することを選択する場合があります。たとえば、GKE は代わりに /home/kubernetes/flexvolume を使用します。

ユーザーは、ホスト上で ps aux|grep kubelet を実行し、--volume-plugin-dir パラメータを確認することで、正しいディレクトリを見つけることができます。 None の場合は、デフォルトの /usr/libexec/kubernetes/kubelet-plugins/volume/exec/ が使用されます。

<<:  ハイブリッドクラウドエッジ戦略が IoT の成功に与える影響

>>:  オラクル、調達を強化して顧客のコスト削減と業務効率の向上を支援

推薦する

Shumai Technology: 香港の物理サーバー、最低350元、30M CMIまたは10M cn2、無制限のトラフィック

Shumai Technology は 5 月に、香港の自社データセンターにある香港サーバーを超低価...

なぜ Kafka を諦めて Pulsar を選んだのでしょうか?

最近、私は Pulsar と Kafka の比較を調べています。ちょっと検索してみると、これら 2 ...

mivocloud - 5 ユーロ/OpenStack/2G メモリ/40g SSD/無制限トラフィック/1T 高防御

モルドバのホスティング プロバイダーであり、RIPE NCC のメンバーでもある mivocloud...

360度検索と百度の違いの比較例

みなさんこんにちは。私は梁磊です。最近、クライアントからの相談を通じて、クライアントが 360 Se...

SalesEasy CRM: 次の段階で、中国の SaaS 企業はどのようにして繭から抜け出し、スケーラブルな成長を達成できるのでしょうか?

6月10日、国内のSaaS企業、投資機関、メディアからのゲスト5名（ Salesfunnel創業者...

個人ウェブマスターによる百度インデックスの最近の急増の理由の分析

最近、Baidu は登録に関していくつかの調整を行ったようです。私の個人的な経験では、3 月 12 ...

初めて投稿に成功した後の感想: 良い記事は宣伝を気にする必要はない

この記事は、自分の記事がどれだけ優れているかを自慢するために書いているわけではありません。ただ、提出...

新しいウェブサイトのインターネットマーケティングを行う方法

新しいサイトでは、このタイプの顧客に対応する過程で、顧客が常にお金を稼ぐ方法、お金を早く稼ぐ方法、そ...

一般的な環境のため: SEO実践者は平時における危険性を認識する必要がある

ある先輩は、SEO 実践者は 2 年以内に必ずさまざまなボトルネックに遭遇するだろう、とかつて言って...

ビッグモデルの時代において、Kingsoft Cloudはクラウドを基盤とし、差別化された戦略で未来を計画しています

生成型人工知能の波に後押しされ、あらゆる企業は時代の潮流に遅れずについていき、ビジネスモデルを革新す...

Java仮想マシン、これは進歩する価値のある方向です

時間が経つにつれて、誰もが徐々に中級プログラマーのレベルに入ります。同時に、学習しないことは立ち止ま...

WordPress の Google リッチ スニペット エラーを修正する

最近、 Google リッチ スニペット テスト ツールを使っていたところ、デフォルトの WordP...

従来のマーケティングモデルは終焉を迎えました。ブランドマーケティングは、新しいメディア時代にどうやって突破し、生まれ変わることができるのでしょうか?

1. 「 WeChatの運用方法」 WeChatの運営方法は、ビジネスの方法であり、インターネットの...

デジタル変革プロジェクト: 中小企業がクラウド コンピューティングを活用するための 4 つの重要なヒント

シリコンバレーでのテクノロジー業界の大規模なレイオフに関する最近のニュースは憂慮すべきものだが、問題...

分散アプリケーションランタイム Dapr: すべてを API にできる

​Dapr[1]はDistributed Application Runtimeの略語です。マルチラ...