en to ja translation catalogue (311 entries)

note: type: Title ==
en: LINSTOR Volumes in Kubernetes
ja: Kubernetes で LINSTOR ボリューム

note: type: Plain text
en: indexterm:[Kubernetes]This chapter describes the usage of LINSTOR in Kubernetes as managed by the operator and with volumes provisioned using the https://github.com/LINBIT/linstor-csi[LINSTOR CSI plugin].
ja: indexterm:[Kubernetes] この章では、オペレーターによって管理され、 https://github.com/LINBIT/linstor-csi[LINSTOR CSI plugin] を使用してプロビジョニングされた KubernetesのLINSTORボリュームについて説明します。

note: type: Plain text
en: This Chapter goes into great detail regarding all the install time options and various configurations possible with LINSTOR and Kubernetes. For those more interested in a "quick-start" for testing, or those looking for some examples for reference. We have some complete <<Helm Install Examples>> of a few common uses near the end of the chapter.
ja: この章では、LINSTOR と Kubernetes で可能なすべてのインストールオプションとさまざまな構成について詳しく説明します。テスト目的で「クイックスタート」に興味がある方、または参照用の例を探している方は、この章の終わり近くに <Helm インストール例>> を参照ください。

note: type: Title ===
en: Kubernetes Overview
ja: Kubernetesの概要

note: type: Plain text
en: _Kubernetes_ is a container orchestrator. Kubernetes defines the behavior of containers and related services via declarative specifications. In this guide, we'll focus on using `kubectl` to manipulate `.yaml` files that define the specifications of Kubernetes objects.
ja: _Kubernetes_ はコンテナーオーケストレーターです。 Kubernetes は、宣言した仕様に基づいてコンテナと関連サービスの動作を定義します。このガイドでは、Kubernetes オブジェクトの仕様を定義する `.yaml` ファイルを介して `kubectl` を使用することに焦点を当てます。

note: type: Title ===
en: Deploying LINSTOR on Kubernetes
ja: Kubernetes への LINSTOR のデプロイ

note: type: Title ====
en: Deploying with the LINSTOR Operator
ja: LINSTORオペレーターを使用したデプロイ

note: type: Plain text
en: LINBIT provides a LINSTOR operator to commercial support customers.  The operator eases deployment of LINSTOR on Kubernetes by installing DRBD, managing Satellite and Controller pods, and other related functions.
ja: LINBIT は LINSTOR オペレーターを商用サポート顧客に提供します。オペレーターは、DRBD のインストール、サテライトポッドとコントローラポッドの管理、およびその他の関連機能により、LINSTOR を Kubernetes に簡単にデプロイできます。

note: type: Plain text
en: The operator itself is installed using a Helm v3 chart as follows:
ja: オペレーター自体は、次のように Helm v3 チャートを使用してインストールされます。

note: type: Plain text
en: Create a kubernetes secret containing your my.linbit.com credentials:
ja: my.linbit.com 認証情報を含む kubernetes シークレットを作成します。

note: type: Plain text
en: The name of this secret must match the one specified in the Helm values, by default `drbdiocred`.
ja: このシークレットの名前は、Helm で指定されたものと一致する必要があります。デフォルトは `drbdiocred` です。

note: type: Plain text
en: Configure the LINSTOR database backend. By default, the chart configures Etcd as database backend. Starting with 1.7.0, the operator can also configure LINSTOR to use <<s-kubernetes-linstor-k8s-backend,Kubernetes as datastore>> directly. If you go the Etcd route, you should configure persistent storage for it:
ja: LINSTOR データベースバックエンドを構成します。デフォルトでチャートは Etcd をデータベースバックエンドとして構成します。1.7.0 以降、オペレーターは直接 <<s-kubernetes-linstor-k8s-backend,Kubernetes as datastore>> を使用するように LINSTOR を構成することもできます。Etcd ルートを使用する場合は、永続ストレージを構成する必要があります。

note: type: Plain text
en: Use an existing storage provisioner with a default `StorageClass`.
ja: デフォルトの `StorageClass` で既存のストレージプロビジョナーを使用する。

note: type: Plain text
en: <<s-kubernetes-etcd-hostpath-persistence,Use `hostPath` volumes>>.
ja: <<s-kubernetes-etcd-hostpath-persistence, `hostPath` ボリューム>> を使用する。

note: type: Plain text
en: Disable persistence, **for basic testing only**. This can be done by adding `--set etcd.persistentVolume.enabled=false` to the `helm install` command below.
ja: 基本的なテストのみで永続化を無効にします。これは以下の `helm install` コマンドに `--set etcd.persistentVolume.enabled=false` を追加することで実行できます。

note: type: Plain text
en: Read <<s-kubernetes-storage, the storage guide>> and configure a basic storage setup for LINSTOR
ja: <<s-kubernetes-storage, ストレージの構成>> を確認し、LINSTOR の基本的なストレージを構成してください。

note: type: Plain text
en: Read the <<s-kubernetes-securing-deployment,section on securing the deployment>> and configure as needed.
ja: <<s-kubernetes-securing-deployment,デプロイメントの保護に関するセクション>> を参照して、必要に応じて設定します。

note: type: Plain text
en: Select the appropriate kernel module injector using `--set` with the `helm install` command in the final step.
ja: 最後のステップとして `helm install` コマンドで `--set` を使用して、適切なカーネルモジュールインジェクタを選択します。

note: type: Plain text
en: Choose the injector according to the distribution you are using.  Select the latest version from one of `drbd9-rhel7`, `drbd9-rhel8`,...  from http://drbd.io/ as appropriate.  The drbd9-rhel8 image should also be used for RHCOS (OpenShift). For the SUSE CaaS Platform use the SLES injector that matches the base system of the CaaS Platform you are using (e.g., `drbd9-sles15sp1`). For example:
ja: 使用しているディストリビューションに応じてインジェクターを選択してください。 http://drbd.io/ から、 `drbd9-rhel7`, `drbd9-rhel8`, ... 等の最新バージョンを適宜選択します。drbd9-rhel8 イメージは、RHCOS(OpenShift) でも使用します。SUSE CaaS プラットフォームの場合、使用している CaaS プラットフォームのシステムと一致する SLES インジェクターを使用します（ `drbd9-sles15sp1` など）。例えば以下のようにします。

note: type: Plain text
en: Only inject modules that are already present on the host machine. If a module is not found, it will be skipped.
ja: ホストマシンに既に存在するモジュールのみを挿入します。モジュールが見つからない場合は、スキップされます。

note: type: Plain text
en: Disable kernel module injection if you are installing DRBD by other means. Deprecated by `DepsOnly`
ja: 他の方法で DRBD をインストールする場合は、カーネルモジュールインジェクションを無効にします。 `DepsOnly` により非推奨になりました。

note: type: Plain text
en: Finally create a Helm deployment named `linstor-op` that will set up everything.
ja: 最後にすべてをセットアップする `linstor-op` という名前の Helm デプロイメントを作成します。

note: type: Plain text
en: Further deployment customization is discussed in the <<s-kubernetes-advanced-deployments,advanced deployment section>>
ja: 詳細なデプロイメントのカスタマイズについては、<<s-kubernetes-advanced-deployments,advanced deployment section>> を参照ください。

note: type: Title =====
en: LINSTOR k8s backend
ja: LINSTOR k8s バックエンド

note: type: Plain text
en: The Kubernetes backend for LINSTOR is still new, you might encounter issues, especially on LINSTOR version upgrade. Please read <<s-kubernetes-upgrade-k8s-backend, the upgrade guide>> for more information.
ja: LINSTOR の Kubernetes バックエンドはまだ新しいため、特に LINSTOR バージョンのアップグレードで問題が発生する可能性があります。詳細は <<s-kubernetes-upgrade-k8s-backend, こちら>> を参照ください。

note: type: Plain text
en: Starting with LINSTOR 1.16.0, the Controller can use the Kubernetes API directly to persist its cluster state. To enable this backend, use the following override file during the chart installation:
ja: LINSTOR 1.16.0 以降、コントローラーは Kubernetes API を直接使用してクラスター状態を永続化できます。このバックエンドを有効にするには、チャートのインストール中に次のオーバーライドファイルを使用します。

note: type: Plain text
en: It is currently **NOT** possible to migrate from an existing cluster with Etcd backend to the Kubernetes backend.
ja: 現在、Etcd バックエンドを備えた既存のクラスターから Kubernetes バックエンドに移行することはできません。

note: type: Title =====
en: LINSTOR etcd `hostPath` persistence
ja: LINSTOR etcd `hostPath` 永続化

note: type: Plain text
en: You can use the `pv-hostpath` Helm templates to create `hostPath` persistent volumes. Create as many PVs as needed to satisfy your configured etcd `replicas` (default 1).
ja: `pv-hostpath` Helm テンプレートを使用して、 `hostPath` 永続ボリュームを作成できます。構成された etcd の `replicas` を満たすために必要な数の PV を作成します（デフォルト1）。

note: type: Plain text
en: Create the `hostPath` persistent volumes, substituting cluster node names accordingly in the `nodes=` option:
ja: `nodePath =` オプションでクラスターノード名を指定して `hostPath` 永続ボリュームを作成します。

note: type: Plain text
en: By default, a PV is created on every `control-plane` node. You can manually select the storage nodes by passing `--set "nodes={<NODE0>,<NODE1>,<NODE2>}"` to the install command.
ja: デフォルトで PV はすべての `control-plane` ノードに作成されます。インストールコマンドに `--set "nodes={<NODE0>,<NODE1>,NODE2>}"` を渡すことにより、ストレージノードを手動で選択できます。

note: type: Title =====
en: Using an existing database
ja: 既存のデータベースの使用

note: type: Plain text
en: LINSTOR can connect to an existing PostgreSQL, MariaDB or etcd database. For instance, for a PostgreSQL instance with the following configuration:
ja: LINSTOR は既存の PostgreSQL、MariaDB、etcd データベースに接続できます。たとえば、次の構成は PostgresSQL インスタンスの場合です。

note: type: Plain text
en: The Helm chart can be configured to use this database instead of deploying an etcd cluster by adding the following to the Helm install command:
ja: Helm のインストールコマンドに以下を追加することにより、etcd クラスターをデプロイする代わりにこのデータベースを使用するように Helm チャートを構成できます。

note: type: Title ====
en: Configuring storage
ja: ストレージの構成

note: type: Plain text
en: The LINSTOR operator can automate some basic storage set up for LINSTOR.
ja: LINSTORオペレーターは、いくつかの基本的なストレージセットアップを自動化できます。

note: type: Title =====
en: Configuring storage pool creation
ja: ストレージプール作成の構成

note: type: Plain text
en: The LINSTOR operator can be used to create LINSTOR storage pools. Creation is under control of the LinstorSatelliteSet resource:
ja: LINSTOR オペレーターを使用して、LINSTOR ストレージプールを作成できます。作成は LinstorSatelliteSet リソースの制御下にあります。

note: type: Plain text
en: ====== At install time
ja: ====== インストール時

note: type: Plain text
en: At install time, by setting the value of `operator.satelliteSet.storagePools` when running helm install.
ja: インストール時の helm install を実行するときに `operator.satelliteSet.storagePools` の値を設定します。

note: type: Plain text
en: First create a file with the storage configuration like:
ja: まず、次のようなストレージ構成でファイルを作成します。

note: type: Plain text
en: This file can be passed to the helm installation like this:
ja: このファイルは、次のように helm インストールに渡すことができます。

note: type: Plain text
en: ====== After install
ja: ====== インストール後

note: type: Plain text
en: On a cluster with the operator already configured (i.e. after `helm install`), you can edit the LinstorSatelliteSet configuration like this:
ja: オペレーターがすでに構成されているクラスター（つまり、 `helm install` の後）では、次のようにして LinstorSatelliteSet 構成を編集できます。

note: type: Plain text
en: The storage pool configuration can be updated like in the example above.
ja: ストレージプールの構成は、上記の例のように更新できます。

note: type: Title =====
en: Preparing physical devices
ja: 物理デバイスの準備

note: type: Plain text
en: By default, LINSTOR expects the referenced VolumeGroups, ThinPools and so on to be present. You can use the `devicePaths: []` option to let LINSTOR automatically prepare devices for the pool. Eligible for automatic configuration are block devices that:
ja: デフォルトでは、LINSTOR は、参照される VolumeGroups, ThinPools などが存在することを想定しています。 `devicePaths：[]` オプションを使用して、LINSTOR がプール用にデバイスを自動的に準備できるようにすることができます。自動構成の対象となるのは、次のようなブロックデバイスです。

note: type: Plain text
en: Are a root device (no partition)
ja: ルートデバイス（パーティションなし）

note: type: Plain text
en: do not contain partition information
ja: パーティション情報を含まない。

note: type: Plain text
en: have more than 1 GiB
ja: 1 GiB 以上である。

note: type: Plain text
en: To enable automatic configuration of devices, set the `devicePaths` key on `storagePools` entries:
ja: デバイスの自動構成を有効にするには `storagePools` エントリに `devicePaths` キーを設定します。

note: type: Plain text
en: Currently, this method supports creation of LVM and LVMTHIN storage pools.
ja: 現在、このメソッドは LVM および LVMTHIN ストレージプールの作成をサポートしています。

note: type: Title =====
en: `lvmPools` configuration
ja: `lvmPools` 構成

note: type: Plain text
en: `name` name of the LINSTOR storage pool.Required
ja: `name` LINSTOR ストレージプールの名前。必須

note: type: Plain text
en: `volumeGroup` name of the VG to create.Required
ja: `volumeGroup` 作成する VG の名前。必須

note: type: Plain text
en: `devicePaths` devices to configure for this pool.Must be empty and >= 1GiB to be recognized.Optional
ja: `devicePaths` このプール用に構成するデバイス。空で、認識されるには 1GiB 以上必要である。オプション

note: type: Plain text
en: `raidLevel` LVM raid level.Optional
ja: `raidLevel` LVM RAID レベル。オプション

note: type: Plain text
en: `vdo` Enable [VDO] (requires VDO tools in the satellite).Optional
ja: `vdo` [VDO]を有効にする（サテライトに VDO ツールが必要）。オプション

note: type: Plain text
en: `vdoLogicalSizeKib` Size of the created VG (expected to be bigger than the backing devices by using VDO).Optional
ja: `vdoLogicalSizeKib` 作成された VG のサイズ（VDO を使用することで下位デバイスよりも大きくなることが予想される）。オプション

note: type: Plain text
en: `vdoSlabSizeKib` Slab size for VDO. Optional
ja: `vdoSlabSizeKib` VDO のスラブサイズ。オプション

note: type: Title =====
en: `lvmThinPools` configuration
ja: `lvmThinPools` 構成

note: type: Plain text
en: `name` name of the LINSTOR storage pool. Required
ja: `name` LINSTOR ストレージプールの名前。必須

note: type: Plain text
en: `volumeGroup` VG to use for the thin pool. If you want to use `devicePaths`, you must set this to `""`.  This is required because LINSTOR does not allow configuration of the VG name when preparing devices.
ja: `volumeGroup` シンプールに使用する VG。 `devicePaths` を使用する場合は、これを `""` に設定する必要があります。LINSTOR ではデバイスの準備時に VG 名を構成できないため、これが必要です。

note: type: Plain text
en: `thinVolume` name of the thinpool. Required
ja: `thinVolume` シンプールの名前。必須

note: type: Plain text
en: `devicePaths` devices to configure for this pool. Must be empty and >= 1GiB to be recognized. Optional
ja: `devicePaths` このプール用に構成するデバイス。認識されるには、空で 1GiB 以上ある。オプション

note: type: Plain text
en: `raidLevel` LVM raid level. Optional
ja: `raidLevel` LVM RAID レベル。オプション

note: type: Plain text
en: The volume group created by LINSTOR for LVMTHIN pools will always follow the scheme "linstor_$THINPOOL".
ja: LVMTHIN プール用に LINSTOR によって作成されたボリュームグループは、常にスキーム "linstor_$THINPOOL" に従います。

note: type: Title =====
en: `zfsPools` configuration
ja: `zfsPools` 構成

note: type: Plain text
en: `zPool` name of the zpool to use. Must already be present on all machines. Required
ja: `zPool` 使用する zpool の名前。すべてのマシンにすでに存在している必要があります。必須

note: type: Plain text
en: `thin` `true` to use thin provisioning, `false` otherwise. Required
ja: `thin` シンプロビジョニングを使用するには `true`, 使用しないなら `false` を設定する。必須

note: type: Title =====
en: Using `automaticStorageType` (DEPRECATED)
ja: `automaticStorageType` の使用（非推奨）

note: type: Plain text
en: _ALL_ eligible devices will be prepared according to the value of `operator.satelliteSet.automaticStorageType`, unless they are already prepared using the `storagePools` section. Devices are added to a storage pool based on the device name (i.e. all `/dev/nvme1` devices will be part of the pool `autopool-nvme1`)
ja: すべての適切なデバイスは、すでに `storagePools` セクションを使用して準備している場合を除き `operator.satelliteSet.automaticStorageType` の値に従って準備されます。デバイスは、デバイス名に基づいてストレージプールに追加さ>れます（つまり、すべての `/dev/nvme1` デバイスはプール `autopool-nvme1` 一部>になります）。

note: type: Plain text
en: The possible values for `operator.satelliteSet.automaticStorageType`:
ja: `operator.satelliteSet.automaticStorageType` の可能な値は次のとおりです。

note: type: Plain text
en: `None` no automatic set up (default)
ja: `None` 自動セットアップなし（デフォルト）

note: type: Plain text
en: `LVM` create a LVM (thick) storage pool
ja: `LVM` LVM（シック）ストレージプールを作成

note: type: Plain text
en: `LVMTHIN` create a LVM thin storage pool
ja: `LVMTHIN` LVM thin ストレージプールを作成

note: type: Plain text
en: `ZFS` create a ZFS based storage pool (**UNTESTED**)
ja: `ZFS` ZFS ベースストレージプールを作成 (** 未テスト **)

note: type: Title ====
en: Securing deployment
ja: 安全なデプロイメント

note: type: Plain text
en: This section describes the different options for enabling security features available when using this operator. The following guides assume the operator is installed <<s-kubernetes-deploy-linstor-operator,using Helm>>
ja: このセクションでは、オペレーターを使用するときに使用できるセキュリティ機能を有効にするためのさまざまなオプションについて説明します。以下のガイドは <<s-kubernetes-deploy-linstor-operator,Helm>> を使ってオペレーターがインストールされていることを前提とします。

note: type: Title =====
en: Secure communication with an existing etcd instance
ja: 既存の etcd インスタンスとの安全な通信

note: type: Plain text
en: Secure communication to an `etcd` instance can be enabled by providing a CA certificate to the operator in form of a kubernetes secret. The secret has to contain the key `ca.pem` with the PEM encoded CA certificate as value.
ja: `etcd` インスタンスへの安全な通信は、kubernetes シークレットの形式で CA 証明書をオペレーターに提供することで有効にできます。シークレットには、PEM エンコードされた CA 証明書を値として持つキー `ca.pem` を含める必要があります。

note: type: Plain text
en: The secret can then be passed to the controller by passing the following argument to `helm install`
ja: 次の引数を `helm install` に渡すことで、シークレットをコントローラーに渡すことができます。

note: type: Plain text
en: ====== Authentication with `etcd` using certificates
ja: ====== 証明書を使用した `etcd` での認証

note: type: Plain text
en: If you want to use TLS certificates to authenticate with an `etcd` database, you need to set the following option on helm install:
ja: TLS 証明書を使用して `etcd` データベースで認証する場合は、helm インストールで次のオプションを設定する必要があります。

note: type: Plain text
en: If this option is active, the secret specified in the above section must contain two additional keys:
ja: このオプションが有効な場合、上記のセクションで指定されたシークレットには、2つの追加キーが含まれている必要があります。

note: type: Plain text
en: `client.cert` PEM formatted certificate presented to `etcd` for authentication
ja:  `client.cert` 認証のために `etcd` に提示される PEM 形式の証明書

note: type: Plain text
en: `client.key` private key **in PKCS8 format**, matching the above client certificate.
ja: `client.key` 上記のクライアント証明書と一致する PKCS8 形式の秘密鍵

note: type: Plain text
en: Keys can be converted into PKCS8 format using `openssl`:
ja: 鍵は `openssl` を使用して PKCS8 形式に変換できます。

note: type: Title =====
en: Configuring secure communication between LINSTOR components
ja: LINSTOR コンポーネント間の安全な通信の設定

note: type: Plain text
en: The default communication between LINSTOR components is not secured by TLS. If this is needed for your setup, follow these steps:
ja: LINSTOR コンポーネント間のデフォルトの通信は TLS によって保護されていません。必要な場合は、次の手順に従い設定します。

note: type: Plain text
en: Create private keys in the java keystore format, one for the controller, one for all satellites:
ja: 1 つはコントローラー用、もう 1 つはすべてのサテライト用に、Java キーストア形式で秘密鍵を作成します。

note: type: Plain text
en: Create a trust store with the public keys that each component needs to trust:
ja: 各コンポーネントが信頼できるよう公開鍵を伴うトラストストアを作成します。

note: type: Plain text
en: Controller needs to trust the satellites
ja: コントローラはサテライトを信頼する必要があります。

note: type: Plain text
en: Nodes need to trust the controller
ja: ノードはコントローラーを信頼する必要があります。

note: type: Plain text
en: Create kubernetes secrets that can be passed to the controller and satellite pods
ja: コントローラとサテライトポッドに渡す kubernetes シークレットを作成します。

note: type: Plain text
en: Pass the names of the created secrets to `helm install`
ja: 作成したシークレットの名前を `helm install` に渡します。

note: type: Plain text
en: It is currently **NOT** possible to change the keystore password. LINSTOR expects the passwords to be `linstor`. This is a current limitation of LINSTOR.
ja: 現在、キーストアのパスワードを変更することはできません。LINSTOR はパスワードが `linstor` であると想定しています。これは LINSTOR の現在の制限です。

note: type: Title =====
en: Configuring secure communications for the LINSTOR API
ja: LINSTOR API の安全な通信の構成

note: type: Plain text
en: Various components need to talk to the LINSTOR controller via its REST interface. This interface can be secured via HTTPS, which automatically includes authentication. For HTTPS+authentication to work, each component needs access to:
ja: さまざまなコンポーネントが REST インターフェースを介して LINSTOR コントローラーと通信する必要があります。このインターフェースは、自動的に認証を含む HTTPS を介して保護できます。HTTPS 認証が機能するためには、各コンポーネントが以下にアクセスする必要があります。

note: type: Plain text
en: A private key
ja: 秘密鍵

note: type: Plain text
en: A certificate based on the key
ja: キーに基づく証明書

note: type: Plain text
en: A trusted certificate, used to verify that other components are trustworthy
ja: 他のコンポーネントが信頼できることを確認するために使用される信頼できる証明書

note: type: Plain text
en: The next sections will guide you through creating all required components.
ja: 次のセクションでは、必要なすべてのコンポーネントの作成について説明します。

note: type: Plain text
en: ====== Creating the private keys
ja: ====== 秘密鍵の作成

note: type: Plain text
en: Private keys can be created using java's keytool
ja: 秘密鍵は Java の keytool を使用して作成できます。

note: type: Plain text
en: The clients need private keys and certificate in a different format, so we need to convert it
ja: クライアントは異なる形式の秘密鍵と証明書を必要とするため、変換する必要があります。

note: type: Plain text
en: The alias specified for the controller key (i.e. `-ext san=dns:linstor-op-cs.default.svc`) has to exactly match the service name created by the operator. When using `helm`, this is always of the form `<release-name>-cs.<release-namespace>.svc`.
ja: コントローラキーで指定されたエイリアス（つまり `-ext san=dns:linstor-op-cs.default.svc` ）は、オペレーターが作成したサービス名と完全に一致する必要があります。 `helm` を使用する場合は、これは常に `<release-name>-cs.<release-namespace>.svc` の形式になります。

note: type: Plain text
en: It is currently NOT possible to change the keystore password. LINSTOR expects the passwords to be linstor. This is a current limitation of LINSTOR
ja: 現在、キーストアのパスワードを変更することはできません。LINSTOR は、パスワードが linstor であると想定しています。これは LINSTOR の現在の制限です。

note: type: Plain text
en: ====== Create the trusted certificates
ja: ====== 信頼できる証明書の作成

note: type: Plain text
en: For the controller to trust the clients, we can use the following command to create a truststore, importing the client certificate
ja: コントローラがクライアントを信頼するには、次のコマンドを使用してトラストストアを作成し、クライアント証明書をインポートします。

note: type: Plain text
en: For the client, we have to convert the controller certificate into a different format
ja: クライアントの場合、コントローラ証明書を別の形式に変換する必要があります。

note: type: Plain text
en: ====== Create Kubernetes secrets
ja: ====== Kubernetes シークレットの作成

note: type: Plain text
en: Now you can create secrets for the controller and for clients:
ja: これで、コントローラとクライアントのシークレットを作成できます。

note: type: Plain text
en: The names of the secrets can be passed to `helm install` to configure all clients to use https.
ja: シークレットの名前を `helm install` に渡して、すべてのクライアントが https を使用するように設定できます。

note: type: Title =====
en: Automatically set the passphrase for LINSTOR
ja: LINSTOR のパスフレーズを自動設定

note: type: Plain text
en: LINSTOR needs to store confidential data to support encrypted information. This data is protected by a master passphrase. A passphrase is automatically generated on the first chart install.
ja: LINSTOR は、暗号化された情報をサポートするために機密データを保存する必要があります。このデータはマスターパスフレーズによって保護されています。パスフレーズは、最初のチャートインストール時に自動的に生成されます。

note: type: Plain text
en: If you want to use a custom passphrase, store it in a secret:
ja: カスタムパスフレーズを使用する場合は、シークレットに保存します。

note: type: Plain text
en: On install, add the following arguments to the helm command:
ja: インストール時に、次の引数を helm コマンドに追加します。

note: type: Title =====
en: Helm Install Examples
ja: Helm インストール例

note: type: Plain text
en: All the below examples use the following `sp-values.yaml` file. Feel free to adjust this for your uses and environment. See <<Configuring storage pool creation>> for further details.
ja: 以下のすべての例では、次の `sp-values.yaml` ファイルを使用しています。用途や環境に合わせて調整してください。詳細は <ストレージプール作成の構成> を参照ください。

note: type: Plain text
en: Default install. Please note this does not setup any persistence for the backing etcd key-value store.
ja: デフォルトのインストールです。これにより etcd KeyValue ストアの設定はされないことに注意してください。

note: type: Plain text
en: This is not suggested for any use outside of testing.
ja: 警告：これは、テスト以外での使用は推奨されていません。

note: type: Plain text
en: Install with LINSTOR storage-pools defined at install via `sp-values.yaml`, persistent hostPath volumes, 3 etcd replicas, and by compiling the DRBD kernel modules for the host kernels.
ja: `sp-values.yaml` で定義された LINSTOR storage-pools, 永続的な hostPath ボリューム, 3 つの etcd レプリカ, ホストカーネル用にコンパイルされた DRBD カーネルモジュールを使用してインストールします。

note: type: Plain text
en: This should be adequate for most basic deployments. Please note that this deployment is not using the pre-compiled DRBD kernel modules just to make this command more portable. Using the pre-compiled binaries will make for a much faster install and deployment. Using the `Compile` option would not be suggested for use in a large Kubernetes clusters.
ja: これは、ほとんどの基本的なデプロイメントに適しています。このデプロイメントでは、コマンドの移植性を高めるために、コンパイル済みの DRBD カーネルモジュールを使用していないことに注意してください。コンパイル済みのバイナリを使用すると、インストールとデプロイメントは速くなります。大規模な Kubernetes クラスターでの使用には、 `Compile`  オプションの使用は推奨されません。

note: type: Plain text
en: Install with LINSTOR storage-pools defined at install via `sp-values.yaml`, use an already created PostgreSQL DB (preferably clustered), instead of etcd, and use already compiled kernel modules for DRBD. Additionally, we'll disable the Stork scheduler in this example.
ja: `sp-values.yaml` で定義された LINSTOR storage-pools, etcd の代わりに作成済みの Postgres DB（できればクラスター化）, DRBD 用にコンパイル済みのカーネルモジュールを使用してインストールします。さらに、この例では Stork スケジューラーを無効にします。

note: type: Plain text
en: The PostgreSQL database in this particular example is reachable via a service endpoint named `postgres`. PostgreSQL itself is configured with `POSTGRES_DB=postgresdb`, `POSTGRES_USER=postgresadmin`, and `POSTGRES_PASSWORD=admin123`
ja: この例の Postgres データベースは `postgres` という名前のサービスエンドポイントでアクセスできます。Postgres 自体は `POSTGRES_DB = postgresdb`, `POSTGRES_USER = postgresadmin`, および `POSTGRES_PASSWORD = admin123` で構成されます。

note: type: Title =====
en: Terminating Helm deployment
ja: Helm デプロイメントの終了

note: type: Plain text
en: To protect the storage infrastructure of the cluster from accidentally deleting vital components, it is necessary to perform some manual steps before deleting a Helm deployment.
ja: 重要なコンポーネントを誤って削除しないようにクラスターのストレージインフラストラクチャを保護するには、Helm デプロイメントを削除する前にいくつかの手動手順を実行する必要があります。

note: type: Plain text
en: Delete all volume claims managed by LINSTOR components. You can use the following command to get a list of volume claims managed by LINSTOR. After checking that none of the listed volumes still hold needed data, you can delete them using the generated kubectl delete command.
ja: LINSTOR コンポーネントによって管理されているすべてのボリューム要求を削除します。次のコマンドを使用して、LINSTOR が管理するボリューム要求のリストを取得できます。リストされたどのボリュームにも必要なデータが残っていないことを確認した後、生成された kubectl delete コマンドを使用してそれらを削除できます。

note: type: Plain text
en: These volumes, once deleted, cannot be recovered.
ja: これらのボリュームは、いったん削除されると復元できません。

note: type: Plain text
en: Delete the LINSTOR controller and satellite resources.
ja: LINSTOR コントローラーとサテライトリソースを削除します。

note: type: Plain text
en: Deployment of LINSTOR satellite and controller is controlled by the LinstorSatelliteSet and LinstorController resources. You can delete the resources associated with your deployment using kubectl
ja: LINSTOR サテライトとコントローラーのデプロイメントは、LinstorSatelliteSet リソースと LinstorController リソースによって制御されます。kubectl を使用して、デプロイメントに関連付けられているリソースを削除できます。

note: type: Plain text
en: After a short wait, the controller and satellite pods should terminate. If they continue to run, you can check the above resources for errors (they are only removed after all associated pods terminate)
ja: しばらくすると、コントローラーとサテライトポッドが終了します。終了しない場合は、上記のリソースのエラーを確認します（関連付けられているすべてのポッドが終了した後でのみ削除されます）

note: type: Plain text
en: Delete the Helm deployment.
ja: Helm デプロイメントの終了

note: type: Plain text
en: If you removed all PVCs and all LINSTOR pods have terminated, you can uninstall the helm deployment
ja: すべての PVC を削除し、すべての LINSTOR ポッドが終了した場合、helm デプロイメントをアンインストールできます。

note: type: Plain text
en: Due to the Helm's current policy, the Custom Resource Definitions named LinstorController and LinstorSatelliteSet will not be deleted by the command.
          More information regarding Helm's current position on CRDs can be found
          https://helm.sh/docs/chart_best_practices/custom_resource_definitions/#method-1-let-helm-do-it-for-you[here].
ja: Helm の現在のポリシーにより、LinstorController および LinstorSatelliteSet という名前のカスタムリソース定義はコマンドによって削除されません。
    CRD の Helm の現状に関しては https://helm.sh/docs/chart_best_practices/custom_resource_definitions/#method-1-let-helm-do-it-for-you[こちら] を参照ください。

note: type: Title ====
en: Advanced deployment options
ja: 高度なデプロイメントオプション

note: type: Plain text
en: The helm charts provide a set of further customization options for advanced use cases.
ja: helm チャートは、より高度な使用のための追加オプションを提供します。

note: type: Plain text
en: Sets the pull policy for all images.
ja: すべてのイメージのプルポリシーを設定します。

note: type: Plain text
en: Controls the number of replicas for each component.
ja: 各コンポーネントのレプリカ数を制御します。

note: type: Plain text
en: Set container resource requests and limits. See https://kubernetes.io/docs/tasks/configure-pod-container/assign-cpu-resource/[the kubernetes docs].  Most containers need a minimal amount of resources, except for:
ja: コンテナリソースのリクエストと制限を設定します。詳細は https://kubernetes.io/docs/tasks/configure-pod-container/assign-cpu-resource/[kubernetes ドキュメント] を参照ください。以下を除いて、ほとんどのコンテナには最小限のリソースが必要です。

note: type: Plain text
en: `etcd.resources` See the https://etcd.io/docs/v3.4.0/op-guide/hardware/[etcd docs]
ja: `etcd.resources` https://etcd.io/docs/v3.4.0/op-guide/hardware/[etcd docs] を参照

note: type: Plain text
en: `operator.controller.resources` Around `700MiB` memory is required
ja: `operator.controller.resources` 約 `700MiB` のメモリが必要

note: type: Plain text
en: `operater.satelliteSet.resources` Around `700MiB` memory is required
ja: `operater.satelliteSet.resources` 約 `700MiB` のメモリが必要

note: type: Plain text
en: `operator.satelliteSet.kernelModuleInjectionResources` If kernel modules are compiled, 1GiB of memory is required.
ja: `operator.satelliteSet.kernelModuleInjectionResources` カーネルモジュールをコンパイルする場合、1GiBのメモリが必要

note: type: Plain text
en: Affinity and toleration determine where pods are scheduled on the cluster. See the https://kubernetes.io/docs/concepts/scheduling-eviction/[kubernetes docs on affinity and toleration].  This may be especially important for the `operator.satelliteSet` and `csi.node*` values. To schedule a pod using a LINSTOR persistent volume, the node requires a running LINSTOR satellite and LINSTOR CSI pod.
ja: Affinity と Toleration によって、ポッドがクラスター上でスケジュールされる場所が決まります。詳細は https://kubernetes.io/docs/concepts/scheduling-eviction/[Affinity と Toleration に関する Kubernetes のドキュメント] を参照ください。これは `operator.satelliteSet` および `csi.node*` の値にとって特に重要です。LINSTOR 永続ボリュームを使用してポッドをスケジュールするには、実行中の LINSTOR サテライトと LINSTOR CSI ポッドがノードに必要です。

note: type: Plain text
en: Sets additional environments variables to pass to the Linstor Controller and Satellites. Uses the same format as https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/[the `env` value of a container]
ja: Linstor コントローラーとサテライトに渡す追加の環境変数を設定します。 https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/[コンテナ環境変数] と同じフォーマットを使用します。

note: type: Plain text
en: Sets additional properties on the Linstor Controller. Expects a simple mapping of `<property-key>: <value>`.
ja: Linstor コントローラーに追加のプロパティを設定します。単純な `<property-key>: <value>` マッピングを使用します。

note: type: Plain text
en: Kubelet expects every CSI plugin to mount volumes under a specific subdirectory of it's own state directory. By default, this state directory is `/var/lib/kubelet`. Some Kubernetes distributions use a different directory:
ja: Kubelet は、すべての CSI プラグインが独自の状態ディレクトリの特定のサブディレクトリにボリュームをマウントすることを想定しています。デフォルトでは、この状態ディレクトリは `/var/lib/kubelet` です。一部の Kubernetes ディストリビューションは異なるディレクトリを使用します。

note: type: Title =====
en: High Availability Deployment
ja: 高可用性デプロイメント

note: type: Plain text
en: To create a High Availability deployment of all components, take a look at the https://github.com/piraeusdatastore/piraeus-operator/blob/b00fd34/doc/scheduling.md[upstream guide] The default values are chosen so that scaling the components to multiple replicas ensures that the replicas are placed on different nodes. This ensures that a single node failures will not interrupt the service.
ja: すべてのコンポーネントの高可用性デプロイメントを作成するには https://github.com/piraeusdatastore/piraeus-operator/blob/b00fd34/doc/[アップストリームガイド] を参照してください。デフォルト値は、複数のレプリカのコンポーネントが異なるノードに配置されるようにスケーリングが行われるように選択されています。これにより、単一ノードの障害によってサービスが中断されることはありません。

note: type: Title =====
en: Monitoring with Prometheus
ja: Prometheus による監視

note: type: Plain text
en: Starting with Linstor Operator v1.5.0, you can use https://prometheus.io/[Prometheus] to monitor Linstor components.  The operator will set up monitoring containers along the existing components and make them available as a `Service`.
ja: Linstor Operator v1.5.0 以降 https://prometheus.io/[Prometheus] を使用して Linstor コンポーネントを監視できます。オペレーターは、既存のコンポーネントに沿って監視コンテナーをセットアップし、それらを `Service` として利用できるようにします。

note: type: Plain text
en: If you use the https://prometheus-operator.dev/[Prometheus Operator], the Linstor Operator will also set up the `ServiceMonitor` instances. The metrics will automatically be collected by the Prometheus instance associated to the operator, assuming https://prometheus-operator.dev/docs/kube/monitoring-other-namespaces/[watching the Piraeus namespace is enabled].
ja: https://prometheus-operator.dev/[Prometheus Operator] を使用する場合、Linstor オペレーターは `ServiceMonitor` インスタンスも設定します。 https://prometheus-operator.dev/docs/kube/monitoring-other-namespaces/[Piraeus 名前空間が有効] と仮定して、メトリックはオペレーターに関連付けられた Prometheus インスタンスによって自動的に収集されます。

note: type: Plain text
en: To disable exporting of metrics, set `operator.satelliteSet.monitoringImage` to an empty value.
ja: メトリックのエクスポートを無効にするには `operator.satelliteSet.monitoringImage` を空の値に設定します。

note: type: Plain text
en: ====== Linstor Controller Monitoring
ja: ====== Linstor コントローラー監視

note: type: Plain text
en: The Linstor Controller exports cluster-wide metrics. Metrics are exported on the existing controller service, using the path https://linbit.com/drbd-user-guide/linstor-guide-1_0-en/#s-linstor-monitoring[`/metrics`].
ja: Linstor コントローラーは、クラスター全体のメトリックをエクスポートします。メトリックは、パス https://linbit.com/drbd-user-guide/linstor-guide-1_0-en/#s-linstor-monitoring[`/metrics`] を使用して、既存のコントローラーサービスにエクスポートされます。

note: type: Plain text
en: ====== DRBD Resource Monitoring
ja: ====== DRBD リソース監視

note: type: Plain text
en: All satellites are bundled with a secondary container that uses https://github.com/LINBIT/drbd-reactor/[`drbd-reactor`] to export metrics directly from DRBD. The metrics are available on port 9942, for convenience a headless service named `<linstorsatelliteset-name>-monitoring` is provided.
ja: すべてのサテライトは https://github.com/LINBIT/drbd-reactor/[`drbd-reactor`] を使用して DRBD から直接メトリックをエクスポートするセカンダリコンテナにバンドルされています。メトリックはポート 9942 で、ヘッドレスサービス `<linstorsatelliteset-name>-monitoring` という名前で提供されています。

note: type: Plain text
en: If you want to disable the monitoring container, set `monitoringImage` to `""` in your LinstorSatelliteSet resource.
ja: 監視コンテナを無効にする場合は、LinstorSatelliteSet リソースで `monitoringImage` を `""` に設定します。

note: type: Title ====
en: Deploying with an external LINSTOR controller
ja: LINSTORオペレーターを使用したデプロイ

note: type: Plain text
en: The operator can configure the satellites and CSI plugin to use an existing LINSTOR setup. This can be useful in cases where the storage infrastructure is separate from the Kubernetes cluster. Volumes can be provisioned in diskless mode on the Kubernetes nodes while the storage nodes will provide the backing disk storage.
ja: オペレーターは、既存の LINSTOR を使用するようにサテライトと CSI プラグインを構成できます。これは、ストレージインフラストラクチャが Kubernetes クラスターから分離されている場合に役立ちます。ボリュームは Kubernetes ノードでディスクレスモードでプロビジョニングでき、ストレージノードが下位ディスクストレージを提供します。

note: type: Plain text
en: To skip the creation of a LINSTOR Controller deployment and configure the other components to use your existing LINSTOR Controller, use the following options when running `helm install`:
ja: LINSTOR コントローラーデプロイメントの作成をスキップし、既存の LINSTOR コントローラーを使用するように他のコンポーネントを構成するには、 `helm install` を実行するときに次のオプションを使用します。

note: type: Plain text
en: `operator.controller.enabled=false` This disables creation of the `LinstorController` resource
ja: `operator.controller.enabled=false` これにより `LinstorController` リソースを作成しなくなります。

note: type: Plain text
en: `operator.etcd.enabled=false` Since no LINSTOR Controller will run on Kubernetes, no database is required.
ja: `operator.etcd.enabled=false` Kubernetes では LINSTOR コントローラーが実行されないため、データベースは必要ありません。

note: type: Plain text
en: `controllerEndpoint=<url-of-linstor-controller>` The HTTP endpoint of the existing LINSTOR Controller. For example: `http://linstor.storage.cluster:3370/`
ja: `controllerEndpoint=<url-of-linstor-controller>` 既存の LINSTOR コントローラーの HTTP エンドポイント。例： `http://linstor.storage.cluster:3370/`

note: type: Plain text
en: After all pods are ready, you should see the Kubernetes cluster nodes as satellites in your LINSTOR setup.
ja: すべての pod の準備が整うと、既存の LINSTOR 環境で Kubernetes クラスターノードがサテライトとして表示されます。

note: type: Plain text
en: Your kubernetes nodes must be reachable using their IP by the controller and storage nodes.
ja: kubernetes ノードは、コントローラーとストレージノードが IP を使用して到達可能である必要があります。

note: type: Plain text
en: Create a storage class referencing an existing storage pool on your storage nodes.
ja: ストレージノードで既存のストレージプールを参照するストレージクラスを作成します。

note: type: Plain text
en: You can provision new volumes by creating PVCs using your storage class. The volumes will first be placed only on nodes with the given storage pool, i.e. your storage infrastructure. Once you want to use the volume in a pod, LINSTOR CSI will create a diskless resource on the Kubernetes node and attach over the network to the diskful resource.
ja: ストレージクラスを使用して PVC を作成することにより、新しいボリュームをプロビジョニングできます。ボリュームは、最初に、指定されたストレージプールを持つノード、つまりストレージインフラストラクチャにのみ配置されます。pod でボリュームを使用する場合、LINSTOR CSI は Kubernetes ノードにディスクレスリソースを作成し、ネットワークを介してディスクリソースに接続します。

note: type: Title ====
en: Deploying with the Piraeus Operator
ja: Piraeus オペレーターを使用したデプロイメント

note: type: Plain text
en: The community supported edition of the LINSTOR deployment in Kubernetes is called Piraeus. The Piraeus project provides https://github.com/piraeusdatastore/piraeus-operator[an operator] for deployment.
ja: Kubernetes でコミュニティがサポートする LINSTOR デプロイメントのエディションは、Piraeus と呼ばれます。Piraeus プロジェクトに関しては https://github.com/piraeusdatastore/piraeus-operator[オペレータ] を参照ください。

note: type: Title ===
en: Interacting with LINSTOR in Kubernetes
ja: Kubernetes で LINSTOR の操作

note: type: Plain text
en: The Controller pod includes a LINSTOR Client, making it easy to interact directly with LINSTOR.  For instance:
ja: コントローラポッドには LINSTOR クライアントが含まれているため、LINSTOR と直接やり取りするのは簡単です。例えば：

note: type: Plain text
en: For a convenient shortcut to the above command, download https://github.com/piraeusdatastore/kubectl-linstor/releases[`kubectl-linstor`] and install it alongside `kubectl`. Then you can use `kubectl linstor` to get access to the complete Linstor CLI
ja: 上記のコマンドへの便利なショートカットを使用する場合、 https://github.com/piraeusdatastore/kubectl-linstor/releases[`kubectl-linstor`] をダウンロードし `kubectl` と一緒にインストールしてください。 `kubectl linstor` を使用して Linstor CLI にアクセスできます。

note: type: delimited block -
en: $ kubectl linstor node list
    ╭───────────────────────────────────────────────────────────────────────────────────────────────╮
    ┊ Node                                      ┊ NodeType   ┊ Addresses                   ┊ State  ┊
    ╞═══════════════════════════════════════════════════════════════════════════════════════════════╡
    ┊ kube-node-01.test                         ┊ SATELLITE  ┊ 10.43.224.26:3366 (PLAIN)   ┊ Online ┊
    ┊ kube-node-02.test                         ┊ SATELLITE  ┊ 10.43.224.27:3366 (PLAIN)   ┊ Online ┊
    ┊ kube-node-03.test                         ┊ SATELLITE  ┊ 10.43.224.28:3366 (PLAIN)   ┊ Online ┊
    ┊ linstor-op-cs-controller-85b4f757f5-kxdvn ┊ CONTROLLER ┊ 172.24.116.114:3366 (PLAIN) ┊ Online ┊
    ╰───────────────────────────────────────────────────────────────────────────────────────────────╯
ja: $ kubectl linstor node list
    ╭───────────────────────────────────────────────────────────────────────────────────────────────╮
    ┊ Node                                      ┊ NodeType   ┊ Addresses                   ┊ State  ┊
    ╞═══════════════════════════════════════════════════════════════════════════════════════════════╡
    ┊ kube-node-01.test                         ┊ SATELLITE  ┊ 10.43.224.26:3366 (PLAIN)   ┊ Online ┊
    ┊ kube-node-02.test                         ┊ SATELLITE  ┊ 10.43.224.27:3366 (PLAIN)   ┊ Online ┊
    ┊ kube-node-03.test                         ┊ SATELLITE  ┊ 10.43.224.28:3366 (PLAIN)   ┊ Online ┊
    ┊ linstor-op-cs-controller-85b4f757f5-kxdvn ┊ CONTROLLER ┊ 172.24.116.114:3366 (PLAIN) ┊ Online ┊

note: type: Plain text
en: It also expands references to PVCs to the matching Linstor resource
ja: また参照を Linstor リソースにマッチする PVC に展開します。

note: type: Plain text
en: It also expands references of the form `pod:[<namespace>/]<podname>` into a list resources in use by the pod.
ja: また `pod:[<namespace>/]<podname>` 形式の参照をポッドで使用中のリソースリストへ展開します。

note: type: Plain text
en: This should only be necessary for investigating problems and accessing advanced functionality.  Regular operation such as creating volumes should be achieved via the <<s-kubernetes-basic-configuration-and-deployment,Kubernetes integration>>.
ja: これは、問題を調査し、高度な機能にアクセスするためにのみ必要です。ボリュームの作成などの通常の操作は <<s-kubernetes-basic-configuration-and-deployment,Kubernetes の操作>> を参照ください。

note: type: Title ===
en: Basic Configuration and Deployment
ja: 基本的な構成とデプロイメント

note: type: Plain text
en: Once all linstor-csi __Pod__s are up and running, we can provision volumes using the usual Kubernetes workflows.
ja: すべての linstor-csi __Pod__ が稼働したら、通常のKubernetesワークフローを使用してボリュームをプロビジョニングできます。

note: type: Plain text
en: Configuring the behavior and properties of LINSTOR volumes deployed via Kubernetes is accomplished via the use of __StorageClass__es.
ja: Kubernetes を介してデプロイされた LINSTOR ボリュームの動作とプロパティの構成は __StorageClass__es を使用して行います。

note: type: Plain text
en: the "resourceGroup" parameter is mandatory. Usually you want it to be unique and the same as the storage class name.
ja: "resourceGroup" パラメータは必須です。通常、一意にしてストレージクラス名と同じにします。

note: type: Plain text
en: Here below is the simplest practical _StorageClass_ that can be used to deploy volumes:
ja: 以下は、ボリュームのデプロイに使用できる最も単純で実用的な _StorageClass_ です。

note: type: Plain text
en: We can create the _StorageClass_ with the following command:
ja: 次のコマンドで _StorageClass_ を作成できます。

note: type: Plain text
en: Now that our _StorageClass_ is created, we can now create a _PersistentVolumeClaim_ which can be used to provision volumes known both to Kubernetes and LINSTOR:
ja: _StorageClass_ が作成されたので、KubernetesとLINSTOR の両方に認識されるボリュームをプロビジョニングするために使用できる _PersistentVolumeClaim_ を作成できます。

note: type: Plain text
en: We can create the _PersistentVolumeClaim_ with the following command:
ja: 次のコマンドで _PersistentVolumeClaim_ を作成できます。

note: type: Plain text
en: This will create a _PersistentVolumeClaim_, but no volume will be created just yet.  The storage class we used specified `volumeBindingMode: WaitForFirstConsumer`, which means that the volume is only created once a workload starts using it. This ensures that the volume is placed on the same node as the workload.
ja: これにより _PersistentVolumeClaim_ が作成されますが、ボリュームはまだ作成されません。使用したストレージクラスは `volumeBindingMode: WaitForFirstConsumer` を指定しました。これは、ワークロードがボリュームの使用を開始したときにのみボリュームが作成されることを意味します。これにより、ボリュームがワークロードと同じノードに配置されます。

note: type: Plain text
en: For our example, we create a simple Pod, which mounts or volume by referencing the _PersistentVolumeClaim_.
ja: この例では、_PersistentVolumeClaim_ を参照してマウントまたはボリューム化する単純なポッドを作成します。

note: type: Plain text
en: We can create the _Pod_ with the following command:
ja: 次のコマンドで _Pod_ を作成できます。

note: type: Plain text
en: Running `kubectl describe pod fedora` can be used to confirm that _Pod_ scheduling and volume attachment succeeded. Taking a look at the _PersistentVolumeClaim_, we can see that it is now bound to a volume.
ja: `kubectl describe pod fedora` を実行すると、 _Pod_ スケジューリングとボリューム接続が成功したことを確認できます。 _PersistentVolumeClaim_ を見ると、ボリュームにバインドされていることがわかります。

note: type: Plain text
en: To remove a volume, please ensure that no pod is using it and then delete the _PersistentVolumeClaim_ via `kubectl`. For example, to remove the volume that we just made, run the following two commands, noting that the _Pod_ must be unscheduled before the _PersistentVolumeClaim_ will be removed:
ja: ボリュームを削除するにはpodがもう使われていないことを確認してから `kubectl` を使ってPersistentVolumeClaimを削除します。例えば、先ほど作成したボリュームを削除するには、以下のコマンドを実行します。ボリュームが削除される前にpodのスケジュールを解除する必要があります。

note: type: delimited block -
en: kubectl delete pod fedora # unschedule the pod.
ja: kubectl delete pod fedora # podをアンスケジュール。

note: type: delimited block -
en: kubectl get pod -w # wait for pod to be unscheduled
ja: kubectl get pod -w # podがアンスケジュールされるまで待つ

note: type: delimited block -
en: kubectl delete pvc my-first-linstor-volume # remove the PersistentVolumeClaim, the PersistentVolume, and the LINSTOR Volume.
ja: kubectl delete pvc my-first-linstor-volume # PersistentVolumeClaim、PersistentVolume、Linstorボリュームを削除する。

note: type: Title ====
en: Available parameters in a StorageClass
ja: StorageClass で使用可能なパラメータ

note: type: Plain text
en: The following storage class contains all currently available parameters to configure the provisioned storage.
ja: 次のストレージクラスには、プロビジョニングされたストレージを構成するために現在使用可能なすべてのパラメーターが含まれています。

note: type: Plain text
en: `linstor.csi.linbit.com/` is an optional, but recommended prefix for LINSTOR CSI specific parameters.
ja: `linstor.csi.linbit.com/` はオプションですが、LINSTOR CSI 固有のパラメーターのプレフィックスとして推奨されます。

note: type: Plain text
en: Sets the file system type to create for `volumeMode: FileSystem` PVCs. Currently supported are:
ja: `volumeMode: FileSystem` PVC 用に作成するファイルシステムタイプを設定します。現在サポートされているのは次のとおりです。

note: type: Plain text
en: `ext4` (default)
ja: `ext4` (デフォルト)

note: type: Plain text
en: `autoPlace` is an integer that determines the amount of replicas a volume of this _StorageClass_ will have.  For instance, `autoPlace: "3"` will produce volumes with three-way replication. If neither `autoPlace` nor `nodeList` are set, volumes will be <<s-autoplace-linstor,automatically placed>> on one node.
ja: `autoPlace` はこの _StorageClass_ が持つボリュームの複製数を指定します。例えば、 `autoPlace: "3"` は３つの複製をもつボリュームを生成します。 `autoPlace` または `nodeList` が指定されていない場合は、１つのノード上にボリュームが生成されます。<<s-autoplace-linstor,自動配備>> を参照ください。

note: type: Plain text
en: If you use this option, you must not use <<s-kubernetes-nodelist,nodeList>>.
ja: このオプションを使用する場合は、 <<s-kubernetes-nodelist,nodeList>> を使用しないでください。

note: type: Plain text
en: You have to use quotes, otherwise Kubernetes will complain about a malformed _StorageClass_.
ja: 引用符を使用する必要があります。そうしないと、Kubernetes は不正な形式の _StorageClass_ について文句を言います。

note: type: Plain text
en: This option (and all options which affect autoplacement behavior) modifies the number of LINSTOR nodes on which the underlying storage for volumes will be provisioned and is orthogonal to which _kubelets_ those volumes will be accessible from.
ja: このオプション（および自動配置の動作に影響を与えるすべてのオプション）は、ボリューム用のストレージがプロビジョニングされるLINSTORノードの数を変更し、 _kubelets_ からこれらのボリュームにアクセスできるようにします。

note: type: Plain text
en: `placementCount` is an alias for <<s-kubernetes-autoplace,`autoPlace`>>
ja: `placementCount` は <<s-kubernetes-autoplace,`autoPlace`>> のエイリアスです。

note: type: Plain text
en: The <<s-linstor-resource-groups, LINSTOR Resource Group (RG)>> to associate with this StorageClass. If not set, a new RG will be created for each new PVC.
ja: この StorageClass に関連付けられた <<s-linstor-resource-groups, LINSTOR Resource Group (RG)>> 。設定されていない場合、新しい PVC ごとに新しい RG が作成されます。

note: type: Plain text
en: `storagePool` is the name of the LINSTOR <<s-storage_pools,storage pool>> that will be used to provide storage to the newly-created volumes.
ja: `storagePool` は LINSTOR <<s-storage_pools,ストレージプール>> の名前で、新規に作成されたボリュームにストレージを供給するときに使用されます。

note: type: Plain text
en: Only nodes configured with this same _storage pool_ with be considered for <<s-kubernetes-autoplace,autoplacement>>. Likewise, for _StorageClasses_ using <<s-kubernetes-nodelist,nodeList>> all nodes specified in that list must have this _storage pool_ configured on them.
ja: これと同じ _storage pool_ で構成されたノードのみが <<s-kubernetes-autoplace,autoplacement>> に使用されます。同様に <<s-kubernetes-nodelist,nodeList>> を使う _StorageClasses_ ではそのリストで指定されたすべてのノードが _storage pool_ を構成している必要があります。

note: type: Plain text
en: `disklessStoragePool` is an optional parameter that only effects LINSTOR volumes assigned disklessly to _kubelets_ i.e., as clients. If you have a custom _diskless storage pool_ defined in LINSTOR, you'll specify that here.
ja: `disklessStoragePool` はオプションでノードが _kubelets_ にディスクレス、すなわちクライアントとして割り当てられるようにするときに使用します。LINSTOR でカスタムディスクレスストレージプールが定義されている場合は、ここで指定します。

note: type: Plain text
en: A comma-separated list of layers to use for the created volumes. The available layers and their order are described towards the end of <<s-linstor-without-drbd, this section>>. Defaults to `drbd,storage`
ja: 作成されたボリュームで使用するレイヤーのコンマ区切りのリスト。使用可能なレイヤーと順序は <<s-linstor-without-drbd, このセクション>> の後半に記述されています。

note: type: Plain text
en: Select from one of the available volume schedulers:
ja: 使用可能なボリュームスケジューラの 1 つから選択します。

note: type: Plain text
en: `AutoPlaceTopology`, the default: Use topology information from Kubernetes together with user provided constraints (see <<s-kubernetes-replicasonsame>> and <<s-kubernetes-replicasondifferent>>).
ja: `AutoPlaceTopology` (デフォルト): ユーザー提供の制約とともに Kubernetes からのトポロジ情報を使用する ( <<s-kubernetes-replicasonsame>> と <<s-kubernetes-replicasondifferent>> を参照)

note: type: Plain text
en: `AutoPlace` Use LINSTOR autoplace, influenced by <<s-kubernetes-replicasonsame>> and <<s-kubernetes-replicasondifferent>>
ja: `AutoPlace` : LINSTOR autoplace を使う。 <<s-kubernetes-replicasonsame>> と <<s-kubernetes-replicasondifferent>> の影響をうける。

note: type: Plain text
en: `FollowTopology`: Use CSI Topology information to place at least one volume in each "preferred" zone. Only useable if CSI Topology is enabled.
ja: `FollowTopology`: CSI トポロジ情報を使用して、各 "preferred" ゾーンに少なくとも 1 つのボリュームを配置します。CSI トポロジが有効になっている場合にのみ使用できます。

note: type: Plain text
en: `Manual`: Use only the nodes listed in `nodeList` and `clientList`.
ja: `Manual`: `nodeList` と `clientList` にリストされているノードのみを使用する。

note: type: Plain text
en: `Balanced`: **EXPERIMENTAL** Place volumes across failure domains, using the least used storage pool on each selected node.
ja: `Balanced`: **実験的** 選択した各ノードで最も使用されていないストレージプールを使用して、障害のあるドメイン全体にボリュームを配置する。

note: type: Plain text
en: Control on which nodes a volume is accessible. The value for this option can take two different forms:
ja: ボリュームにアクセスできるノードを制御します。このオプションの値は、次の 2 つの異なる形式をとることができます。

note: type: Plain text
en: A simple `"true"` or `"false"` allows access from all nodes, or only those nodes with diskfull resources.
ja: `"true"` または `"false"` は、すべてのノードからのアクセス、またはディスクフルリソースを持つノードのみからのアクセスを許可します。

note: type: Plain text
en: Advanced rules, which allow more granular rules on which nodes can access the volume.
ja: 高度なルール。ノードがボリュームにアクセスできる、より詳細なルールを可能にします。

note: type: Plain text
en: The current implementation can grant access to the volume for nodes that share the same labels. For example, if you want to allow access from all nodes in the same region and zone as a diskfull resource, you could use:
ja: 現在の実装では、同じラベルを共有するノードのボリュームへのアクセスを許可できます。たとえば、ディスクフルリソースと同じリージョンおよびゾーン内のすべてのノードからのアクセスを許可する場合は、次を使用できます。

note: type: Plain text
en: You can specify multiple rules. The rules are additive, a node only need to match one rule to be assignable.
ja: 複数のルールを指定でき、1 つのルールに一致するだけで割り当て可能になります。

note: type: Plain text
en: `encryption` is an optional parameter that determines whether to encrypt volumes. LINSTOR must be <<s-linstor-encrypted-volumes,configured for encryption>> for this to work properly.
ja: `encryption` はオプションで、ボリュームを暗号化するかどうかを指定します。LINSTOR はこれが正しく動作するように適切に設定されている必要があります。

note: type: Plain text
en: `nodeList` is a list of nodes for volumes to be assigned to. This will assign the volume to each node and it will be replicated among all of them. This can also be used to select a single node by hostname, but it's more flexible to use <<s-kubernetes-replicasonsame,replicasOnSame>> to select a single node.
ja: `nodeList` はボリュームが割り当てられるノードのリストです。ボリュームがそれぞれのノードに割り当てられそれらの間で複製が行われます。これはホスト名で１つのノードを指定できますが、 これには <<s-kubernetes-replicasonsame,replicasOnSame>> を使うほうが柔軟性があります。

note: type: Plain text
en: If you use this option, you must not use <<s-kubernetes-autoplace,autoPlace>>.
ja: このオプションを使用する場合は <<s-kubernetes-autoplace,autoPlace>> を使用しないでください。

note: type: Plain text
en: This option determines on which LINSTOR nodes the underlying storage for volumes will be provisioned and is orthogonal from which _kubelets_ these volumes will be accessible.
ja: このオプションは、ボリュームのストレージをどのLINSTORノード上でプロビジョニングするかを決定し、 _kubelets_ からこれらのボリュームにアクセスできるようにします。

note: type: Plain text
en: `clientList` is a list of nodes for diskless volumes to be assigned to. Use in conjunction with <<s-kubernetes-nodelist>>.
ja: `clientList` は、割り当てられるディスクレスボリュームのノードのリストです。 <<s-kubernetes-nodelist>> と組み合わせて使用します。

note: These should link to the linstor documentation about node properties, but those do not exist at the time of this commit. type: Plain text
en: `replicasOnSame` is a list of `key` or `key=value` items used as autoplacement selection labels when <<s-kubernetes-autoplace,autoplace>> is used to determine where to provision storage. These labels correspond to LINSTOR node properties.
ja: `replicasOnSame` は自動配置選択ラベルとして使用される `key` または `key=value` アイテムのリストです。これは <<s-kubernetes-autoplace,autoplace>> がストレージをプロビジョニングする場所を決定するために使用されます。これらのラベルは、LINSTOR ノードのプロパティに対応しています。

note: type: Plain text
en: The operator periodically synchronizes all labels from Kubernetes Nodes, so you can use them as keys for scheduling constraints.
ja: オペレーターは、Kubernetes ノードからのすべてのラベルを定期的に同期するため、それらをスケジューリング制約のキーとして使用できます。

note: type: Plain text
en: Let's explore this behavior with examples assuming a LINSTOR cluster such that `node-a` is configured with the following auxiliary property `zone=z1` and `role=backups`, while `node-b` is configured with only `zone=z1`.
ja: `node-a` が補助プロパティ `zone=z1`, `role=backups` で、 `node-b` が `zone=z1` のみで構成されているような LINSTOR クラスターを想定した例でこの動作を調べてみましょう。

note: type: Plain text
en: If we configure a _StorageClass_ with `autoPlace: "1"` and `replicasOnSame: "zone=z1 role=backups"`, then all volumes created from that _StorageClass_ will be provisioned on `node-a`, since that is the only node with all of the correct key=value pairs in the LINSTOR cluster. This is the most flexible way to select a single node for provisioning.
ja: `autoPlace: "1"` と `replicasOnSame: "zone=z1 role=backups"` を持つ _StorageClass_ を設定すると、この _StorageClass_ から生成されるすべてのボリュームは `node-a` にプロビジョニングされます。これは LINSTOR クラスタ内ですべての key = value ペアを持つ唯一のノードだからです。これは、プロビジョニングに１つのノードを選択する最も柔軟な方法です。

note: type: Plain text
en: This guide assumes LINSTOR CSI version 0.10.0 or newer. All properties referenced in `replicasOnSame` and `replicasOnDifferent` are interpreted as auxiliary properties. If you are using an older version of LINSTOR CSI, you need to add the `Aux/` prefix to all property names. So `replicasOnSame: "zone=z1"` would be `replicasOnSame: "Aux/zone=z1"` Using `Aux/` manually will continue to work on newer LINSTOR CSI versions.
ja: このガイドは、LINSTOR CSI バージョン 0.10.0 以降を想定しています。 `replicasOnSame` および `replicasOnDifferent` で参照されるすべてのプロパティは、補助プロパティとして解釈されます。古いバージョンの LINSTOR CSI を使用している場合は、すべてのプロパティ名に `Aux/` プレフィックスを追加する必要があります。したがって、 `replicasOnSame: "zone=z1"` は `replicasOnSame: "Aux/zone=z1"` になります。 `Aux/` を手動で追加すると、新しい LINSTOR CSI バージョンで引き続き機能します。

note: type: Plain text
en: If we configure a _StorageClass_ with `autoPlace: "1"` and `replicasOnSame: "zone=z1"`, then volumes will be provisioned on either `node-a` or `node-b` as they both have the `zone=z1` aux prop.
ja: `autoPlace: "1"` と `replicasOnSame: "zone=z1"` を持つ _StorageClass_ を設定すると、ボリュームは `node-a` か `node-b` のどちらかにプロビジョニングされます。これは、両方が `zone=z1` aux prop を持つからです。

note: type: Plain text
en: If we configure a _StorageClass_ with `autoPlace: "2"` and `replicasOnSame: "zone=z1 role=backups"`, then provisioning will fail, as there are not two or more nodes that have the appropriate auxiliary properties.
ja: `autoPlace: "2"` と `replicasOnSame: "zone=z1 role=backups"` を持つ _StorageClass_ を設定すると、適切な補助プロパティを持つノードが2つ以上ないためプロビジョニングは失敗します。

note: type: Plain text
en: If we configure a _StorageClass_ with `autoPlace: "2"` and `replicasOnSame: "zone=z1"`, then volumes will be provisioned on both `node-a` and `node-b` as they both have the `zone=z1` aux prop.
ja: `autoPlace: "2"` と `replicasOnSame: "zone=z1"` を持つ _StorageClass_ を設定すると、ボリュームは `node-a` と `node-b` の両方にプロビジョニングされます。これは、両方が `zone=z1` aux prop を持つからです。

note: type: Plain text
en: You can also use a property key without providing a value to ensure all replicas are placed on nodes with the same property value, with caring about the particular value. Assuming there are 4 nodes, `node-a1` and `node-a2` are configured with `zone=a`. `node-b1` and `node-b2` are configured with `zone=b`. Using `autoPlace: "2"` and `replicasOnSame: "zone"` will place on either `node-a1` and `node-a2` OR on `node-b1` and `node-b2`.
ja: 値を指定せずにプロパティキーを使用して、特定の値を考慮しながら、すべてのレプリカが同じプロパティ値を持つノードに配置されるようにすることもできます。 4つのノードがあると仮定し `node-a1` と `node-a2` は `zone=a` で構成、 `node-b1` と `node-b2` は `zone=b` で構成されているとします。 `autoPlace: "2"` と `replicasOnSame: "zone"` を使用すると `node-a1` と `node-a2`、または `node-b1` と `node-b2` のいずれかに配置されます。

note: type: Plain text
en: `replicasOnDifferent` takes a list of properties to consider, same as <<s-kubernetes-replicasonsame,replicasOnSame>>.  There are two modes of using `replicasOnDifferent`:
ja: `replicasOnDifferent` は <<s-kubernetes-replicasonsame,replicasOnSame>> と同じように、考慮すべきプロパティのリストを取ります。 `replicasOnDifferent` の使用には 2 つのモードがあります。

note: type: Plain text
en: Preventing volume placement on specific nodes:
ja: 特定のノードでのボリューム配置の防止:

note: type: Plain text
en: If a value is given for the property, the nodes which have that property-value pair assigned will be considered last.
ja: プロパティに値が指定されている場合、そのプロパティと値のペアが割り当てられているノードが最後に考慮されます。

note: type: Plain text
en: Example: `replicasOnDifferent: "no-csi-volumes=true"` will place no volume on any node with property `no-csi-volumes=true` unless there are not enough other nodes to fulfill the `autoPlace` setting.
ja: 例： `replicasOnDifferent: "no-csi-volumes=true"` は `autoPlace` 設定を満たすのに十分なノードが他にない限り、プロパティ `no-csi-volumes=true` を持つノードにボリュームを配置しません。

note: type: Plain text
en: Distribute volumes across nodes with different values for the same key:
ja: 同じキーの値が異なるノード間でボリュームを分散します。

note: type: Plain text
en: If no property value is given, LINSTOR will place the volumes across nodes with different values for that property if possible.
ja: プロパティ値が指定されていない場合、LINSTOR は、可能であれば、そのプロパティの値が異なるノード間でボリュームを配置します。

note: type: Plain text
en: Example: Assuming there are 4 nodes, `node-a1` and `node-a2` are configured with `zone=a`. `node-b1` and `node-b2` are configured with `zone=b`. Using a _StorageClass_ with `autoPlace: "2"` and `replicasOnDifferent: "zone"`, LINSTOR will create one replica on either `node-a1` or `node-a2` _and_ one replica on either `node-b1` or `node-b2`.
ja: 例： 4 つのノードがあると仮定し `node-a1` と `node-a2` は `zone=a` で、 `node-b1` と `node-b2` は `zone=b` で構成されているとします。 _StorageClass_ を `autoPlace: "2"` および `replicasOnDifferent: "zone"` で使用すると、LINSTOR は `node-a1` または `node-a2` のいずれかに 1 つのレプリカを作成し、 `node-b1` または `node-b2` のいずれかにもう 1 つのレプリカを作成します。

note: type: Plain text
en: Create a diskless resource on _all_ nodes that were not assigned a diskful resource.
ja: ディスクフルリソースが割り当てられていないすべてのノードにディスクレスリソースを作成します。

note: type: Plain text
en: Do not place the resource on a node which has a resource with a name matching the regex.
ja: 正規表現と一致する名前のリソースを持つノードにリソースを配置しない。

note: type: Plain text
en: `fsOpts` is an optional parameter that passes options to the volume's filesystem at creation time.
ja: `fsOpts` はオプションで、作成時にボリュームのファイルシステムに渡すオプションを指定します。

note: type: Plain text
en: Please note these values are specific to your chosen <<s-kubernetes-filesystem, filesystem>>.
ja: これらの値は選択した <<s-kubernetes-filesystem, filesystem>> 固有です。

note: type: Plain text
en: `mountOpts` is an optional parameter that passes options to the volume's filesystem at mount time.
ja: `mountOpts` はオプションで、マウント時にボリュームのファイルシステムに渡すオプションを指定します。

note: type: Plain text
en: Extra arguments to pass to `xfs_io`, which gets called before right before first use of the volume.
ja: ボリュームを最初に使用する直前に呼び出される `xfs_io` に渡す追加の引数。

note: type: Plain text
en: Parameters starting with `property.linstor.csi.linbit.com/` are translated to Linstor properties that are set on the <<s-linstor-resource-groups,Resource Group>> associated with the StorageClass.
ja: `property.linstor.csi.linbit.com/` で始まるパラメータは StorageClass の <<s-linstor-resource-groups,Resource Group>> に設定される Linstor プロパティに変換されます。

note: type: Plain text
en: For example, to set `DrbdOptions/auto-quorum` to `disabled`, use:
ja: たとえば `DrbdOptions/auto-quorum` を `disabled` に設定するには、次を使用します。

note: type: Plain text
en: The full list of options is available https://app.swaggerhub.com/apis-docs/Linstor/Linstor/1.7.0#/developers/resourceDefinitionModify[here]
ja: オプションの完全なリストは https://app.swaggerhub.com/apis-docs/Linstor/Linstor/1.7.0#/developers/resourceDefinitionModify[こちら] で入手できます。

note: type: Plain text
en: This option is deprecated, use the more general <<s-kubernetes-storage-class-properties, `property.linstor.csi.linbit.com/*`>> form.
ja: このオプションは非推奨です。より一般的な <<s-kubernetes-storage-class-properties, `property.linstor.csi.linbit.com/*`>> を使用してください。

note: type: Plain text
en: Advanced DRBD options to pass to LINSTOR. For example, to change the replication protocol, use `DrbdOptions/Net/protocol: "A"`.
ja: LINSTOR に渡す高度な DRBD オプション。たとえば、レプリケーションプロトコルを変更するには `DrbdOptions/Net/protocol: "A"` を使用します。

note: type: Title ===
en: Snapshots
ja: スナップショット

note: type: Plain text
en: Creating <<s-linstor-snapshots, snapshots>> and creating new volumes from snapshots is done via the use of __VolumeSnapshot__s, __VolumeSnapshotClass__es, and __PVC__s.
ja: <<s-linstor-snapshots, スナップショット>> の作成とスナップショットから新規ボリュームを作成するには __VolumeSnapshot__, __VolumeSnapshotClass__,  __PVC__ を通して行われます。

note: type: Title ====
en: Adding snapshot support
ja: スナップショットサポートの追加

note: type: Plain text
en: LINSTOR supports the volume snapshot feature, which is configured in some, but not all Kubernetes distributions.
ja: LINSTOR は、すべてではありませんが一部の Kubernetes ディストリビューションでボリュームスナップショット機能をサポートしています。

note: type: Plain text
en: To check if your Kubernetes distribution supports snapshots out of the box, run the following command:
ja: Kubernetes ディストリビューションがスナップショットをサポートしているかどうかを確認するには、次のコマンドを実行します。

note: type: Plain text
en: In case your Kubernetes distribution _does not_ support snapshots, you can manually add the {snapshot-controller-link}[required components] from the Kubernetes Storage SIG. For convenience, you can use {piraeus-charts-link}[Helm Charts] provided by the {piraeus-org}[Piraeus team] to add these components.
ja: Kubernetes ディストリビューションがスナップショットをサポートしていない場合は、Kubernetes Storage SIG から {snapshot-controller-link}[required components] を手動で追加できます。 {piraeus-org}[Piraeus team] が提供する {piraeus-charts-link}[Helm Charts] を使用してこれらのコンポーネントを追加することも可能です。

note: type: Block title
en: Adding snapshot support using the Piraeus Charts
ja: Piraeus チャートを使用したスナップショットサポートの追加

note: type: Title ====
en: Using volume snapshots
ja: ボリュームスナップショットの使用

note: type: Plain text
en: Then we can create our _VolumeSnapshotClass_:
ja: それで _VolumeSnapshotClass_ を作成できます。

note: type: Plain text
en: Create the _VolumeSnapshotClass_ with `kubectl`:
ja: `kubectl` を使用して _VolumeSnapshotClass_ を作成します。

note: type: Plain text
en: Now we will create a volume snapshot for the volume that we created above. This is done with a _VolumeSnapshot_:
ja: 次に上記で作成したボリュームのボリュームスナップショットを作成します。これは _VolumeSnapshot_ を使用します。

note: type: Plain text
en: Create the _VolumeSnapshot_ with `kubectl`:
ja: `kubectl` を使用して _VolumeSnapshot_ を作成します。

note: type: Plain text
en: You can check that the snapshot creation was successful
ja: スナップショットの作成が成功したことを確認できます。

note: type: Plain text
en: Finally, we'll create a new volume from the snapshot with a _PVC_.
ja: 最後にスナップショットから _PVC_ で新しいボリュームを作成します。

note: type: Plain text
en: Create the _PVC_ with `kubectl`:
ja: `kubectl` を使用して _PVC_ を作成します。

note: type: Title ===
en: Volume Accessibility and Locality
ja: ボリュームのアクセスしやすさと局所性

note: This only covers DRBD volumes, section might change if linked docs are updated. type: Plain text
en: LINSTOR volumes are typically accessible both locally and <<s-drbd_clients,over the network>>. The CSI driver will ensure that the volume is accessible on whatever node was selected for the consumer. The driver also provides options to ensure volume locality (the consumer is placed on the same node as the backing data) and restrict accessibility (only a subset of nodes can access the volume over the network).
ja: LINSTOR ボリュームはローカルと <<s-drbd_clients,ネットワーク経由>> の両方でアクセスできます。CSI ドライバーは、コンシューマー用に選択されたノードでボリュームにアクセスできるようにします。ドライバーは、ボリュームの局所性の確保（コンシューマーは下位データと同じノードに配置される）と、アクセスを制限する（ノードのサブセットのみがネットワーク経由でボリュームにアクセスできる）オプションも提供します。

note: type: Plain text
en: Volume locality is achieved by setting `volumeBindingMode: WaitForFirstConsumer` in the storage class. This tell Kubernetes and the CSI driver to wait until the first consumer (Pod) referencing the PVC is scheduled. The CSI driver then provisions the volume with backing data on the same node as the consumer. In case a node without appropriate storage pool was selected, a replacement node in the set of accessible nodes is chosen (see below).
ja: ボリュームの局所性は、ストレージクラスで `volumeBindingMode: WaitForFirstConsumer` を設定することで実現されます。これにより、Kubernetes と CSI ドライバーは、PVC を参照する最初のコンシューマー（ポッド）がスケジュールされるまで待機するように指示されます。次に、CSI ドライバーは、コンシューマーと同じノード上の下位データを使用してボリュームをプロビジョニングします。適切なストレージプールのないノードが選択された場合、アクセス可能なノードのセットから代替ノードが選択されます（以下を参照）。

note: type: Plain text
en: Volume accessibility is controlled by the <<s-kubernetes-params-allow-remote-volume-access,`allowRemoteVolumeAccess` parameter>>. Whenever the CSI plugin needs to place a volume, this parameter is consulted to get the set of "accessible" nodes. This means they can share volumes placed on them via the network. This information is also propagated to Kubernetes via label selectors on the PV.
ja: ボリュームのアクセスしやすさは <<s-kubernetes-params-allow-rems-kubernetes-params-allow-remote-volume-access,`allowRemoteVolumeAccess` パラメータ>> によって制御されます。CSI プラグインがボリュームを配置するときはいつでも、このパラメーターを調べてアクセス可能なノードのセットを取得します。これは、ネットワークを介して配置されたボリュームを共有できることを意味します。この情報は、PV のラベルセレクターを介して Kubernetes にも伝達されます。

note: type: Title ====
en: Volume Accessibility and Locality examples
ja: ボリュームのアクセスしやすさと局所性の例

note: type: Plain text
en: The following example show common scenarios where you want to optimize volume accessibility and locality. It also includes examples of how to spread volume replicas across zones in a cluster.
ja: 次の例は、ボリュームのアクセスしやすさと局所性を最適化する一般的なシナリオを示しています。また、クラスター内のゾーン間でボリュームレプリカを分散する方法の例も含まれています。

note: type: Title =====
en: Single-zone homogeneous cluster
ja: 単一ゾーンの同種クラスター

note: type: Plain text
en: The cluster only spans a single zone, i.e. latency between nodes is low. The cluster is homogeneous, i.e. all nodes are configured similarly, all nodes have their own local storage pool.
ja: クラスタは単一のゾーンにのみまたがっています。つまり、ノード間の遅延は低くなっています。クラスタは同種です。つまり、すべてのノードが同様に構成され、すべてのノードに独自のローカルストレージプールがあります。

note: type: Plain text
en: Enable late volume binding. This places one replica on the same node as the first consuming pod, if possible.
ja: レイトボリュームバインディングを有効にします。これにより、可能であれば、最初に実行するポッドと同じノードに 1 つのレプリカが配置されます。

note: type: Plain text
en: Set the storage pool(s) to use.
ja: 使用するストレージプールを設定します。

note: type: Plain text
en: Ensure that the data is replicated, so that at least 2 nodes store the data.
ja: 少なくとも 2 つのノードがデータを格納することを確証します。

note: type: Plain text
en: Allow using the volume even on nodes without replica. Since all nodes are connected equally, performance impact should be manageable.
ja: レプリカのないノードでもボリュームの使用を許可します。すべてのノードが均等に接続されているため、パフォーマンスへの影響は小さいです。

note: type: Title ===
en: Multi-zone homogenous cluster
ja: マルチゾーン同種クラスター

note: type: Plain text
en: As before, in our homogenous cluster all nodes are configured similarly with their own local storage pool. The cluster spans now multiple zones, with increased latency across nodes in different zones. To ensure low latency, we want to restrict access to the volume with a local replica to only those zones that do have a replica. At the same time, we want to spread our data across multiple zones.
ja: 単一ゾーンと同様に、同種のクラスターでは、すべてのノードが独自のローカルストレージプールで構成されます。クラスターは複数のゾーンにまたがり、異なるゾーンのノード間のレイテンシーが加わりました。低レイテンシーを考慮して、ローカルレプリカのボリュームへのアクセスを、レプリカを持つゾーンのみに制限する必要があります。同時に、データを複数のゾーンに分散させたいと考えています。

note: type: Plain text
en: Allow using the volume on nodes in the same zone as a replica, under the assumption that zone internal networking is fast and low latency.
ja: ゾーンの内部ネットワークが高速で低遅延であるという前提で、レプリカと同じゾーンのノードでボリュームを使用できるようにします。

note: type: Plain text
en: Spread the replicas across different zones.
ja: レプリカを異なるゾーンに配置します。

note: type: Title ===
en: Multi-region cluster
ja: マルチリージョンクラスター

note: type: Plain text
en: Our cluster now spans multiple regions. We don't want to incur the latency penalty to replica our data across regions, we just want to replica in the same zone.
ja: クラスターは複数のリージョンにまたがっています。リージョン間でデータを複製する遅延ペナルティを発生させたくないので、同じゾーンで複製します。

note: type: Plain text
en: Restrict replicas to only a single region.
ja: レプリカを単一のリージョンのみに制限します。

note: type: Title ===
en: Cluster with external storage
ja: 外部ストレージを備えたクラスター

note: type: Plain text
en: Our cluster is now only comprised of compute nodes without local storage. Any volume access has to occur via remote volume access.
ja: クラスターはローカルストレージのないノードのみで構成されています。ボリュームアクセスは、リモートボリュームアクセスを介して行う必要があります。

note: type: Plain text
en: Assuming we only have one storage host, we can only place a single volume without additional replicas
ja: ストレージホストが 1 つのみであると仮定して、追加のレプリカなしで 1 つのボリュームのみを配置します。

note: type: Plain text
en: Our worker nodes need to be allowed to connect to the external storage host
ja: ワーカーノードが外部ストレージホストに接続できるようにします。

note: type: Title ===
en: Volume Locality Optimization using Stork
ja: Stork を使用したボリューム局所性最適化

note: type: Plain text
en: The Stork integration is no longer actively maintained. Instead we recommend using `volumeBindingMode: WaitForFirstConsumer` in your storage class. For more details <<s-kubernetes-volume-accessibility-and-locality,see above>>.
ja: Stork はもはや積極的にメンテナンスされていません。代わりに、ストレージクラスで `volumeBindingMode: WaitForFirstConsumer` を使用することをお勧めします。詳細は <<s-kubernetes-volume-accessibility-and-locality,こちら>> を参照ください。

note: type: Plain text
en: Stork is a scheduler extender plugin for Kubernetes which allows a storage driver to give the Kubernetes scheduler hints about where to place a new pod so that it is optimally located for storage performance. You can learn more about the project on its https://portworx.com/stork-storage-orchestration-kubernetes/[GitHub page].
ja: Stork は、Kubernetes のスケジューラ拡張プラグインであり、ストレージドライバーは、Kubernetes スケジューラーに新しいポッドを配置する場所に関するヒントを与え、ストレージパフォーマンスのために最適な場所に配置できるようにします。プロジェクトの詳細については、 https://portworx.com/stork-storage-orchestration-kubernetes/[GitHub ページ] 参照ください。

note: type: Plain text
en: The next Stork release will include the LINSTOR driver by default.  In the meantime, you can use a custom-built Stork container by LINBIT which includes a LINSTOR driver, https://hub.docker.com/repository/docker/linbit/stork[available on Docker Hub]
ja: 次の Stork リリースには、デフォルトで LINSTOR ドライバーが含まれます。それまでの間は https://hub.docker.com/repository/docker/linbit/stork[Docker ハブで利用可能] から LINBIT によってカスタム構築された LINSTOR ドライバー を含む Stork コンテナを使用できます。

note: type: Title ====
en: Using Stork
ja: Stork の使用

note: type: Plain text
en: By default, the chart will not install Stork. To install it and register a new scheduler called `stork` with Kubernetes, pass `--set stork.enabled=false` to the install command.  The new scheduler can be used to place pods near to their volumes.
ja: デフォルトでは、チャートは Stork をインストールしません。インストールして `stork` スケジューラを Kubernetes に登録するには、`--set stork.enabled=false` を指定します。この新しいスケジューラは、ポッドをボリュームの近くに配置できます。

note: type: Plain text
en: Add the name of the scheduler to your pod.
ja: スケジューラの名前をポッドに追加します。

note: type: Title ===
en: Fast workload fail over using the High Availability Controller
ja: 高可用性コントローラーを使用した高速ワークロードフェイルオーバー

note: type: Plain text
en: The LINSTOR High Availability Controller (HA Controller) will speed up the fail over process for stateful workloads using LINSTOR for storage.  It is deployed by default, and can be scaled to multiple replicas:
ja: LINSTOR 高可用性コントローラー（HA コントローラー）は、ストレージに LINSTOR を使用して、ステートフルワークロードのフェイルオーバープロセスを高速化します。デフォルトでデプロイされ、複数のレプリカにスケーリングされます。

note: type: Plain text
en: In the event of node failures, Kubernetes is very conservative in rescheduling stateful workloads. This means it can take more than 15 minutes for Pods to be moved from unreachable nodes. With the information available to DRBD and LINSTOR, this process can be sped up significantly.
ja: ノードに障害が発生した場合、Kubernetes はステートフルワークロードの再スケジュールを非常に慎重に行います。これは、ポッドが到達不能なノードから移動されるまでに 15 分以上かかる可能性があることを意味します。DRBD と LINSTOR が利用できる情報により、このプロセスを大幅にスピードアップできます。

note: type: Plain text
en: The HA Controller enables fast fail over for:
ja: HA コントローラーは、以下に対して高速フェイルオーバーを有効にします。

note: type: Plain text
en: Pods using DRBD backed PersistentVolumes. The DRBD resources must make use of the quorum functionality LINSTOR will configure this automatically for volumes with 2 or more replicas in clusters with at least 3 nodes.
ja: DRBD でバックアップされた PersistentVolumes を使用するポッド。DRBD リソースは、クォーラム機能を使用する必要があります。LINSTOR は、少なくとも 3 つのノードを持つクラスター内の 2 つ以上のレプリカを持つボリュームに対してこれを自動的に構成します。

note: type: Plain text
en: The workload does not use any external resources in a way that could lead to a conflicting state if two instances try to use the external resource at the same time. While DRBD can ensure that only one instance can have write access to the storage, it cannot provide the same guarantee for external resources.
ja: ワークロードが、2 つのインスタンスが同時に外部リソースを使用しようとした場合に、競合状態につながる可能性のある方法で外部リソースを使用していないとき。 DRBD は、1 つのインスタンスのみがストレージへの書き込みアクセス権を持つことができることを保証できますが、外部リソースに対して同じ保証を提供することはできません。

note: type: Plain text
en: The Pod is marked with the `linstor.csi.linbit.com/on-storage-lost: remove` label.
ja: ポッドに `linstor.csi.linbit.com/on-storage-lost: remove` ラベルが付いている。

note: type: Title ====
en: Example
ja: サンプル

note: type: Plain text
en: The following StatefulSet uses the HA Controller to manage fail over of a pod.
ja: 次の StatefulSet は、HA コントローラーを使用してポッドのフェイルオーバーを管理します。

note: type: Plain text
en: The label is applied to Pod template, **not** the StatefulSet. The label was applied correctly, if your Pod appears in the output of `kubectl get pods -l linstor.csi.linbit.com/on-storage-lost=remove`.
ja: ラベルは、StatefulSet ではなくポッドテンプレートに適用されます。ポッドが `kubectl get pods -l linstor.csi.linbit.com/on-storage-lost=remove` の出力に表示される場合、ラベルは正しく適用さています。

note: type: Plain text
en: Deploy the set and wait for the pod to start
ja: セットをデプロイし、ポッドが開始するのを待ちます。

note: type: Plain text
en: Then one of the nodes becomes unreachable. Shortly after, Kubernetes will mark the node as `NotReady`
ja: 次に、ノードの 1 つが到達不能になります。その後まもなく、Kubernetes はノードを `NotReady` としてマークします

note: type: Plain text
en: After about 45 seconds, the Pod will be removed by the HA Controller and re-created by the StatefulSet
ja: 約 45 秒後、ポッドは HA コントローラーによって削除され、StatefulSet によって再作成されます。
