解決

kubectl 名前空間の作成開発
kubectl run nginx --image=nginx --restart=Never -n 開発

解決
永続ボリューム
永続ボリュームは、Kubernetes クラスター内のストレージの一部です。永続ボリュームは、ノードのようなクラスター レベルのリソースであり、どの名前空間にも属しません。管理者によってプロビジョニングされ、特定のファイル サイズを持ちます。これにより、Kubernetes にアプリケーションをデプロイする開発者は、基盤となるインフラストラクチャを知る必要がありません。開発者がアプリケーション用に一定量の永続ストレージを必要とする場合、システム管理者は、プロビジョニングされた永続ボリュームを簡単に使用できるようにクラスターを構成します。
永続ボリュームの作成
kind: PersistentVolume apiVersion: v1 metadata: name:app-data spec: capacity: # 作成する PV の容量を定義します storage: 2Gi # 要求するストレージの量 accessModes: # 作成するボリュームの権限を定義します - ReadWriteMany hostPath: path: "/srv/app-data" # ボリュームを作成するパス 課題 アクセス モードが ReadWriteMany、ストレージ クラス名が shared、ストレージ容量が 2Gi、ホスト パスが /srv/app-data の、app-data という名前の永続ボリュームを作成します。

2. ファイルを保存し、永続ボリュームを作成します。

3. 永続ボリュームを表示します。

永続ボリュームのステータスは「使用可能」です。つまり、使用可能であり、まだマウントされていません。persistentVolume を persistentVolumeClaim にマウントすると、このステータスは変わります。
永続ボリュームクレーム
実際のエコシステムでは、システム管理者が PersistentVolume を作成し、開発者がポッドで参照される PersistentVolumeClaim を作成します。PersistentVolumeClaim は、persistentVolume に必要な最小サイズとアクセス モードを指定して作成されます。
チャレンジ
上記で作成した永続ボリュームを要求する永続ボリューム要求を作成します。要求は 2Gi を要求する必要があります。永続ボリューム要求の storageClassName が、以前に作成した persistentVolume と同じであることを確認します。
種類: PersistentVolume apiVersion: v1 メタデータ: name:app-data
仕様:
accessModes: - ReadWriteManyリソース:
リクエスト: ストレージ: 2Gi
ストレージクラス名: 共有
2. 保存してPVCを作成する
njerry191@cloudshell:~ (extreme-clone-2654111)$ kubect1 create -f app-data.yaml persistentvolumeclaim/app-data が作成されました
3. PVCを見る

4. 最初に作成した PV で何が変わったか確認してみましょう。

ステータスが「利用可能」から「バインド済み」に変更されました。
5. パス /var/app/config を使用して永続ボリューム要求をマウントするために使用される、イメージ nginx を使用して myapp という名前の新しいポッドを作成します。
主張を展開する
apiVersion: v1 種類: Pod メタデータ: creationTimestamp: null 名前: app-data 仕様: ボリューム: - name:congigpvc persistenVolumeClaim: claimName: app-data コンテナー: - イメージ: nginx 名前: app volumeMounts: - mountPath: "/srv/app-data " 名前: configpvc

以下の解決策を参照してください。
説明
解決