アプリケーション

手順

1. Home → Projects に移動します。
2. Create Project をクリックします。
3. プロジェクトの詳細を入力します。
4. Create をクリックします。

1. Project ドロップダウンメニューをクリックし、利用可能なすべてのプロジェクトの一覧を表示します。Create Project を選択します。

   図1.1 Create project

   
2. Create Project ダイアログボックスで、Name フィールドに、myproject などの一意の名前を入力します。
3. オプション: プロジェクトの Display Name および Description の詳細を追加します。
4. Create をクリックします。
5. 左側のナビゲーションパネルを使用して Project ビューに移動し、プロジェクトのダッシュボードを確認します。

6. オプション。

   • 画面上部の Project ドロップダウンメニューで、all projects を選択し、クラスターのすべてのプロジェクトを一覧表示します。
   • Details タブを使用してプロジェクトの詳細を表示します。
   • プロジェクトに対する適切なパーミッションがある場合は、Project Access タブを使用して、プロジェクトの administrator、edit、および view 権限を提供するか、または取り消します。

手順

1. 以下を実行します。

手順

1. Home → Projects に移動します。

2. 表示するプロジェクトを選択します。

   このページで、Workloads ボタンをクリックして、プロジェクトのワークロードを確認します。

手順

1. プロジェクトの一覧を表示するには、以下を実行します。

   $ oc get projects

2. CLI 操作について現在のプロジェクトから別のプロジェクトに切り換えることができます。その後の操作についてはすべて指定のプロジェクトが使用され、プロジェクトスコープのコンテンツの操作が実行されます。

   $ oc project <project_name>

1. Developer パースペクティブで、Project ビューに移動します。
2. Project ページで、Project Access タブを選択します。

3. Add Access をクリックして、パーミッションの新規の行をデフォルトパーミッションに追加します。

   図1.2 プロジェクトパーミッション

   
4. ユーザー名を入力し、Select a role ドロップダウンリストをクリックし、適切なロールを選択します。
5. Save をクリックして新規パーミッションを追加します。

手順

1. Web コンソールのナビゲーションメニューの上部にあるコンテキストセレクターから Developer を選択します。
2. +Add をクリックします。
3. ページの上部で、追加するプロジェクトの名前を選択します。
4. プロジェクトに追加する方法をクリックし、ワークフローに従います。

手順

1. Home → Projects に移動します。
2. ステータスを確認するプロジェクトを選択します。

手順

1. 以下を実行します。

   $ oc status

   このコマンドは、コンポーネントとそれらの各種の関係を含む現在のプロジェクトの概要を示します。

手順

1. Home → Projects に移動します。
2. プロジェクトの一覧から削除するプロジェクトを見つけます。
3. プロジェクト一覧の右側にある Options メニュー から Delete Project を選択します。
4. Delete Project ペインが開いたら、フィールドから削除するプロジェクトの名前を入力します。
5. Delete をクリックします。

手順

1. 以下を実行します。

   $ oc delete project <project_name>

手順

1. cluster-admin 権限を持つユーザーとしてログインしている。

2. デフォルトのプロジェクトテンプレートを生成します。

   $ oc adm create-bootstrap-project-template -o yaml > template.yaml

3. オブジェクトを追加するか、または既存オブジェクトを変更することにより、テキストエディターで生成される template.yaml ファイルを変更します。

4. プロジェクトテンプレートは、openshift-config namespace に作成される必要があります。変更したテンプレートを読み込みます。

   $ oc create -f template.yaml -n openshift-config

5. Web コンソールまたは CLI を使用し、プロジェクト設定リソースを編集します。

   • Web コンソールの使用

     1. Administration → Cluster Settings ページに移動します。
     2. Global Configuration をクリックし、すべての設定リソースを表示します。
     3. Project のエントリーを見つけ、Edit YAML をクリックします。

   • CLI の使用

     1. project.config.openshift.io/cluster リソースを編集します。

        $ oc edit project.config.openshift.io/cluster

6. spec セクションを、projectRequestTemplate および name パラメーターを組み込むように更新し、アップロードされたプロジェクトテンプレートの名前を設定します。デフォルト名は project-request です。

   カスタムプロジェクトテンプレートを含むプロジェクト設定リソース

   apiVersion: config.openshift.io/v1
   kind: Project
   metadata:
     ...
   spec:
     projectRequestTemplate:
       name: <template_name>

7. 変更を保存した後、変更が正常に適用されたことを確認するために、新しいプロジェクトを作成します。

手順

1. cluster-admin 権限を持つユーザーとしてログインしている。

2. 以下のコマンドを実行して、self-provisioners クラスターロールバインディングの使用を確認します。

   $ oc describe clusterrolebinding.rbac self-provisioners

   出力例

   Name:		self-provisioners
   Labels:		<none>
   Annotations:	rbac.authorization.kubernetes.io/autoupdate=true
   Role:
     Kind:	ClusterRole
     Name:	self-provisioner
   Subjects:
     Kind	Name				Namespace
     ----	----				---------
     Group	system:authenticated:oauth

   self-provisioners セクションのサブジェクトを確認します。

3. self-provisioner クラスターロールをグループ system:authenticated:oauth から削除します。

   • self-provisioners クラスターロールバインディングが self-provisioner ロールのみを system:authenticated:oauth グループにバインドする場合、以下のコマンドを実行します。

     $ oc patch clusterrolebinding.rbac self-provisioners -p '{"subjects": null}'

   • self-provisioners クラスターロールバインディングが self-provisioner ロールを system:authenticated:oauth グループ以外のユーザー、グループまたはサービスアカウントにバインドする場合、以下のコマンドを実行します。

     $ oc adm policy \
         remove-cluster-role-from-group self-provisioner \
         system:authenticated:oauth

4. ロールへの自動更新を防ぐには、self-provisioners クラスターロールバインディングを編集します。自動更新により、クラスターロールがデフォルトの状態にリセットされます。

   • CLI を使用してロールバインディングを更新するには、以下を実行します。

     1. 以下のコマンドを実行します。

        $ oc edit clusterrolebinding.rbac self-provisioners

     2. 表示されるロールバインディングで、以下の例のように rbac.authorization.kubernetes.io/autoupdate パラメーター値を false に設定します。

        apiVersion: authorization.openshift.io/v1
        kind: ClusterRoleBinding
        metadata:
          annotations:
            rbac.authorization.kubernetes.io/autoupdate: "false"
          ...

   • 単一コマンドを使用してロールバインディングを更新するには、以下を実行します。

     $ oc patch clusterrolebinding.rbac self-provisioners -p '{ "metadata": { "annotations": { "rbac.authorization.kubernetes.io/autoupdate": "false" } } }'

5. 認証されたユーザーとしてログインし、プロジェクトのセルフプロビジョニングを実行できないことを確認します。

   $ oc new-project test

   出力例

   Error from server (Forbidden): You may not request a new project via this API.

   組織に固有のより有用な説明を提供できるようこのプロジェクト要求メッセージをカスタマイズすることを検討します。

手順

1. Web コンソールまたは CLI を使用し、プロジェクト設定リソースを編集します。

   • Web コンソールの使用

     1. Administration → Cluster Settings ページに移動します。
     2. Global Configuration をクリックし、すべての設定リソースを表示します。
     3. Project のエントリーを見つけ、Edit YAML をクリックします。

   • CLI の使用

     1. cluster-admin 権限を持つユーザーとしてログインしている。

     2. project.config.openshift.io/cluster リソースを編集します。

        $ oc edit project.config.openshift.io/cluster

2. spec セクションを、projectRequestMessage パラメーターを含むように更新し、値をカスタムメッセージに設定します。

   カスタムプロジェクト要求メッセージを含むプロジェクト設定リソース

   apiVersion: config.openshift.io/v1
   kind: Project
   metadata:
     ...
   spec:
     projectRequestMessage: <message_string>

   以下に例を示します。

   apiVersion: config.openshift.io/v1
   kind: Project
   metadata:
     ...
   spec:
     projectRequestMessage: To request a project, contact your system administrator at projectname@example.com.

3. 変更を保存した後に、プロジェクトをセルフプロビジョニングできない開発者またはサービスアカウントとして新規プロジェクトの作成を試行し、変更が正常に適用されていることを確認します。

手順

1. +Add ビューで From Git をクリックし、Import from Git フォームを表示します。
2. Git セクションで、アプリケーションの作成に使用するコードベースの Git リポジトリー URL を入力します。たとえば、このサンプル nodejs アプリケーションの URL https://github.com/sclorg/nodejs-ex を入力します。その後、URL は検証されます。

3. オプション: Show Advanced Git Options をクリックし、以下のような詳細を追加できます。

   • Git Reference: アプリケーションのビルドに使用する特定のブランチ、タグ、またはコミットのコードを参照します。
   • Context Dir: アプリケーションのビルドに使用するアプリケーションのソースコードのサブディレクトリーを指定します。
   • Source Secret: プライベートリポジトリーからソースコードをプルするための認証情報で Secret Name を作成します。
4. Builder セクションで、URL の検証後に、適切なビルダーイメージが検出され、スターのマークが付けられ、自動的に選択されます。https://github.com/sclorg/nodejs-ex Git URL の場合、Node.js ビルダーイメージがデフォルトで選択されます。ビルダーイメージが自動検出されていない場合は、ビルダーイメージを選択します。必要に応じて、Builder Image Version のドロップダウンリストを使用してバージョンを変更できます。

5. General セクションで、以下を実行します。

   1. Application フィールドに、アプリケーションを分類するために一意の名前 (myapp など) を入力します。アプリケーション名が namespace で一意であることを確認します。

   2. Name フィールドで、既存のアプリケーションが存在しない場合に、このアプリケーション用に作成されたリソースが Git リポジトリー URL をベースとして自動的に設定されることを確認します。既存のアプリケーションがある場合には、既存のアプリケーション内でそのコンポーネントをデプロイしたり、新しいアプリケーションを作成したり、またはコンポーネントをいずれにも割り当てない状態にしたりすることができます。

      注記

      リソース名は namespace で一意である必要があります。エラーが出る場合はリソース名を変更します。

6. Resources セクションで、以下を選択します。

   • Deployment: 単純な Kubernetes スタイルのアプリケーションを作成します。
   • Deployment Config: OpenShift スタイルのアプリケーションを作成します。
   • Knative Service: マイクロサービスを作成します。
   注記

   Knative Service オプションは、Serverless Operator がクラスターにインストールされている場合にのみ、Import from git 形式で表示されます。詳細は、OpenShift Serverless のインストールについてのドキュメントを参照してください。

7. Pipelines セクションで、 Add Pipeline を選択してから Show Pipeline Visualization をクリックし、アプリケーションのパイプラインを表示します。
8. Advanced Options セクションでは、Create a route to the application がデフォルトで選択されるため、公開されている URL を使用してアプリケーションにアクセスできます。アプリケーションをパブリックルートに公開したくない場合は、チェックボックスをクリアできます。

9. オプション: 以下の高度なオプションを使用してアプリケーションをさらにカスタマイズできます。

   ルーティング

   Routing リンクをクリックして、以下を実行します。

   • ルートのホスト名をカスタマイズします。
   • ルーターが監視するパスを指定します。
   • ドロップダウンリストから、トラフィックのターゲットポートを選択します。

   • Secure Route チェックボックスを選択してルートを保護します。必要な TLS 終端タイプを選択し、各ドロップダウンリストから非セキュアなトラフィックについてのポリシーを設定します。

     サーバーレスアプリケーションの場合、Knative Service が上記のすべてのルーティングオプションを管理します。ただし、必要に応じて、トラフィックのターゲットポートをカスタマイズできます。ターゲットポートが指定されていない場合、デフォルトポートの 8080 が使用されます。

   ヘルスチェック

   Health Checks リンクをクリックして、Readiness、Liveness、および Startup プローブをアプリケーションに追加します。すべてのプローブに事前に設定されたデフォルトデータが実装され、必要に応じてデフォルトデータでプローブを追加したり、必要に応じてこれをカスタマイズしたりできます。

   ヘルスプローブをカスタマイズするには、以下を実行します。

   • Add Readiness Probe をクリックし、必要に応じてコンテナーが要求を処理する準備ができているかどうかを確認するためにパラメーターを変更し、チェックマークを選択してプローブを追加します。
   • Add Liveness Probe をクリックし、必要に応じてコンテナーが実行中かどうかを確認するためにパラメーターを変更し、チェックマークを選択してプローブを追加します。

   • Add Startup Probe をクリックし、必要に応じてコンテナー内のアプリケーションが起動しているかどうかを確認するためにパラメーターを変更し、チェックマークを選択してプローブを追加します。

     それぞれのプローブについて、ドロップダウンリストから要求タイプ (HTTP GET、Container Command、TCP Socket) を指定できます。選択した要求タイプに応じてフォームが変更されます。次に、プローブの成功および失敗のしきい値、コンテナーの起動後の最初のプローブ実行までの秒数、プローブの頻度、タイムアウト値など、他のパラメーターのデフォルト値を変更できます。

   ビルド設定およびデプロイメント

   Build Configuration および Deployment リンクをクリックして、それぞれの設定オプションを表示します。オプションの一部はデフォルトで選択されています。必要なトリガーおよび環境変数を追加して、オプションをさらにカスタマイズできます。

   サーバーレスアプリケーションの場合、Deployment オプションは表示されません。これは、Knative 設定リソースが DeploymentConfig の代わりにデプロイメントの必要な状態を維持するためです。

   スケーリング

   Scaling リンクをクリックして、最初にデプロイするアプリケーションの Pod 数またはインスタンス数を定義します。

   サーバーレスアプリケーションの場合、以下を実行できます。

   • Autoscaler で設定できる Pod 数の上限および下限を設定します。下限が指定されない場合は、デフォルトでゼロに設定されます。
   • 指定された時点でのアプリケーションインスタンスごとに必要な同時要求数のソフト制限を定義します。自動スケーリングの推奨設定です。指定されていない場合は、クラスター設定で指定した値を使用します。
   • 指定された時点でのアプリケーションインスタンスごとに許可される同時要求数のハード制限を定義します。これは、リビジョンテンプレートで設定されます。指定されていない場合、デフォルトでクラスター設定で指定された値に設定されます。

   リソースの制限

   Resource Limit リンクをクリックして、コンテナーが実行時に保証または使用が許可されている CPU および メモリー リソースの量を設定します。

   ラベル

   Labels リンクをクリックして、カスタムラベルをアプリケーションに追加します。

10. Create をクリックして、アプリケーションを作成し、Topology ビューでビルドのステータスを確認します。

手順

1. この手順を実行するために OpenShift Container Platform Web コンソールで新規プロジェクトを作成します。この例では、my-etcd というプロジェクトを使用します。

2. Operators → Installed Operators ページに移動します。クラスター管理者によってクラスターにインストールされ、使用可能にされた Operator がクラスターサービスバージョン (CSV) の一覧としてここに表示されます。CSV は Operator によって提供されるソフトウェアを起動し、管理するために使用されます。

   ヒント

   以下を使用して、CLI でこの一覧を取得できます。

   $ oc get csv

3. Installed Operators ページで、Copied をクリックしてから、etcd Operator をクリックして詳細情報および選択可能なアクションを表示します。

   Provided APIs に表示されているように、この Operator は 3 つの新規リソースタイプを利用可能にします。これには、etcd クラスター (EtcdCluster リソース) のタイプが含まれます。これらのオブジェクトは、Deployment または ReplicaSet などの組み込み済みのネイティブ Kubernetes オブジェクトと同様に機能しますが、これらには etcd を管理するための固有のロジックが含まれます。

4. 新規 etcd クラスターを作成します。

   1. etcd Cluster API ボックスで、Create New をクリックします。
   2. 次の画面では、クラスターのサイズなど EtcdCluster オブジェクトのテンプレートを起動する最小条件への変更を加えることができます。ここでは Create をクリックして確定します。これにより、Operator がトリガーされ、Pod、サービス、および新規 etcd クラスターの他のコンポーネントが起動します。

5. Resources タブをクリックして、プロジェクトに Operator によって自動的に作成され、設定された数多くのリソースが含まれることを確認します。

   Kubernetes サービスが作成され、プロジェクトの他の Pod からデータベースにアクセスできることを確認します。

6. 所定プロジェクトで edit ロールを持つすべてのユーザーは、クラウドサービスのようにセルフサービス方式でプロジェクトにすでに作成されている Operator によって管理されるアプリケーションのインスタンス (この例では etcd クラスター) を作成し、管理し、削除することができます。この機能を持つ追加のユーザーを有効にする必要がある場合、プロジェクト管理者は以下のコマンドを使用してこのロールを追加できます。

   $ oc policy add-role-to-user edit <user> -n <target_project>

手順

1. 以下のように MongoDB サービスを作成し、これをプロジェクトにデプロイします。

   1. Developer パースペクティブで、Add ビューに移動して Database オプションを選択し、Developer Catalogを確認します。ここには、アプリケーションにコンポーネントまたはサービスとして追加できる複数のオプションがあります。
   2. MongoDB オプションをクリックし、サービスの詳細を確認します。
   3. Instantiate Template をクリックして、MongoDB サービスの詳細情報を含む自動的に設定されたテンプレートを表示し、Create をクリックしてサービスを作成します。
2. 左側のナビゲーションパネルで Topology をクリックし、プロジェクトにデプロイされた MongoDB サービスを表示します。
3. MongoDB サービスを既存のアプリケーショングループに追加するには、mongodb Pod を選択して、これをアプリケーションにドラッグします。MongoDB サービスは既存のアプリケーショングループに追加されます。

4. コンポーネントをドラッグし、これをアプリケーショングループに追加すると、必要なラベルがコンポーネントに自動的に追加されます。MongoDB サービスノードをクリックし、Overview パネルの Labels セクションに追加されたラベル app.kubernetes.io/part-of=myapp を確認します。

   図2.2 アプリケーションのグループ化

   

1. MongoDB サービスをアプリケーションに追加するには、mongodb Pod をクリックし、右側の Overview パネルを確認します。
2. パネルの右上にある Actions ドロップダウンメニューをクリックし、Edit Application Grouping を選択します。
3. Edit Application Grouping ダイアログボックスで、Select an Application ドロップダウンリストをクリックし、適切なアプリケーショングループを選択します。
4. Save をクリックし、アプリケーショングループに追加された MongoDB サービスを表示します。

手順

1. アプリケーションを作成し、アプリケーションが Topology ビューに表示された後に、アプリケーションを右クリックして選択可能な編集オプションを確認します。

   図2.6 アプリケーションの編集

   
2. Edit application-name をクリックし、アプリケーションの作成に使用した Add ワークフローを表示します。このフォームには、アプリケーションの作成時に追加した値が事前に設定されています。

3. アプリケーションに必要な値を編集します。

   注記

   General セクションの Name フィールド、CI/CD パイプライン、または Advanced Options セクションの Create a route to the application フィールドを編集することはできません。

4. Save をクリックしてビルドを再起動し、新規イメージをデプロイします。

   図2.7 アプリケーションの編集および再デプロイ

   

1. Developer パースペクティブで、Add ビューに移動し、From Catalog オプションを選択して Developer Catalog ですべての Helm チャートを表示します。
2. チャートを選択し、チャートの説明、README、チャートについてのその他の詳細を確認します。

3. Install Helm Chart をクリックします。

   図2.8 Developer カタログの Helm チャート

   

4. Install Helm Chart ページで以下を行います。

   1. リリースの固有の名前を Release Name フィールドに入力します。
   2. オプションで、YAML エディターで YAML ファイルを変更します。
5. Install をクリックして Helm リリースを作成します。リリースが表示される Topology ビューにリダイレクトされます。Helm チャートにリリースノートがある場合、チャートは事前に選択され、右側のパネルにそのリリースのリリースノートが表示されます。

手順

1. Topology ビューで Helm リリースを選択し、サイドパネルを表示します。
2. Actions → Upgrade Helm Release をクリックします。
3. Upgrade Helm Release ページで、アップグレード先とする Chart Version を選択してから Upgrade をクリックし、別の Helm リリースを作成します。Helm Releases ページには 2 つのリビジョンが表示されます。

1. Developer パースペクティブで Helm ビューに移動し、namespace の Helm Releases を表示します。
2. 一覧表示されているリソースに隣接する Options メニュー をクリックし、Rollback を選択します。
3. Rollback Helm Release ページで、ロールバックする Revision を選択し、 Rollback をクリックします。
4. Helm Releases ページで、チャートをクリックし、リリースの詳細およびリソースを表示します。

5. Revision History タブに移動し、チャートのすべてのリビジョンを表示します。

   図2.9 Helm リビジョン履歴

   
6. 必要な場合は、さらに特定のリビジョンに隣接する Options メニュー を使用して、ロールバックするリビジョンを選択します。

手順

1. Topology ビューで、 Helm リリースを右クリックし、Uninstall Helm Release を選択します。
2. 確認プロンプトでチャートの名前を入力し、Uninstall をクリックします。

1. 削除するアプリケーションをクリックし、アプリケーションのリソースの詳細を含むサイドパネルを確認します。
2. パネルの右上に表示される Actions ドロップダウンメニューをクリックし、Delete Application を選択して確認ダイアログボックスを表示します。
3. アプリケーションの名前を入力して Delete をクリックし、これを削除します。

1. ReplicationController 定義の要素。
2. 新規デプロイメントの自動作成のトリガー。
3. デプロイメント間の移行ストラテジー。
4. ライフサイクルフック。

1. pre ライフサイクルフックを実行します。
2. サージ数に基づいて新しいレプリケーションコントローラーをスケールアップします。
3. 最大利用不可数に基づいて以前のレプリケーションコントローラーをスケールダウンします。
4. 新しいレプリケーションコントローラーが希望のレプリカ数に到達して、以前のレプリケーションコントローラーの数がゼロになるまで、このスケーリングを繰り返します。
5. post ライフサイクルフックを実行します。

1. pre ライフサイクルフックを実行します。
2. 以前のデプロイメントをゼロにスケールダウンします。
3. 任意の mid ライフサイクルフックを実行します。
4. 新規デプロイメントをスケールアップします。
5. post ライフサイクルフックを実行します。

1. Actions ドロップダウンメニューで、Edit Deployment Config を選択し、アプリケーションのデプロイメント設定の詳細を確認します。
2. YAML エディターで spec.strategy.type を Recreate に変更し、Save をクリックします。
3. Topology ビューでノードを選択し、サイドパネルの Overview タブを表示します。これで、Update Strategy は Recreate に設定されます。

4. Actions ドロップダウンメニューを使用し、Start Rollout を選択し、再作成ストラテジーを使用して更新を開始します。再作成ストラテジーはまず、アプリケーションの古いバージョンの Pod を終了してから、新規バージョンの Pod を起動します。

   図3.2 再作成更新

   

手順

1. ファイルにクォータを定義します。

2. クォータを作成し、これをプロジェクトに適用するためにファイルを使用します。

   $ oc create -f <file> [-n <project_name>]

   以下に例を示します。

   $ oc create -f core-object-counts.yaml -n demoproject

手順

1. プロジェクトで定義されるクォータの一覧を取得します。たとえば、demoproject というプロジェクトの場合、以下を実行します。

   $ oc get quota -n demoproject

   出力例

   NAME                AGE
   besteffort          11m
   compute-resources   2m
   core-object-counts  29m

2. 関連するクォータについて記述します。たとえば、core-object-counts クォータの場合、以下を実行します。

   $ oc describe quota core-object-counts -n demoproject

   出力例

   Name:			core-object-counts
   Namespace:		demoproject
   Resource		Used	Hard
   --------		----	----
   configmaps		3	10
   persistentvolumeclaims	0	4
   replicationcontrollers	3	20
   secrets			9	10
   services		2	10

手順

1. プロジェクト要求テンプレートにリソースクォータ定義を追加します。

   • プロジェクト要求テンプレートがクラスターに存在しない場合:

     1. ブートストラッププロジェクトテンプレートを作成し、これを template.yaml というファイルに出力します。

        $ oc adm create-bootstrap-project-template -o yaml > template.yaml

     2. リソースクォータの定義を template.yaml に追加します。以下の例では、storage-consumption という名前のリソースクォータを定義します。テンプレートの parameters: セクションの前に定義を追加する必要があります。

        - apiVersion: v1
          kind: ResourceQuota
          metadata:
            name: storage-consumption
          spec:
            hard:
              persistentvolumeclaims: "10" 1
              requests.storage: "50Gi" 2
              gold.storageclass.storage.k8s.io/requests.storage: "10Gi" 3
              silver.storageclass.storage.k8s.io/requests.storage: "20Gi" 4
              silver.storageclass.storage.k8s.io/persistentvolumeclaims: "5" 5
              bronze.storageclass.storage.k8s.io/requests.storage: "0" 6
              bronze.storageclass.storage.k8s.io/persistentvolumeclaims: "0" 7

        1

        プロジェクト内の永続ボリューム要求 (PVC) の合計数です。

        2

        プロジェクトのすべての永続ボリューム要求 (PVC) において、要求されるストレージの合計はこの値を超えることができません。

        3

        プロジェクトのすべての永続ボリューム要求 (PVC) において、gold ストレージクラスで要求されるストレージの合計はこの値を超えることができません。

        4

        プロジェクトのすべての永続ボリューム要求 (PVC) において、silver ストレージクラスで要求されるストレージの合計はこの値を超えることができません。

        5

        プロジェクトのすべての永続ボリューム要求 (PVC) において、silver ストレージクラスの要求の合計数はこの値を超えることができません。

        6

        プロジェクトのすべての永続ボリューム要求 (PVC) において、bronze ストレージクラスで要求されるストレージの合計はこの値を超えることができません。この値が 0 に設定される場合、bronze ストレージクラスはストレージを要求できません。

        7

        プロジェクトのすべての永続ボリューム要求 (PVC) において、bronze ストレージクラスで要求されるストレージの合計はこの値を超えることができません。この値が 0 に設定される場合、bronze ストレージクラスは要求を作成できません。

     3. openshift-config namespace の変更された template.yaml ファイルでプロジェクト要求テンプレートを作成します。

        $ oc create -f template.yaml -n openshift-config

        注記

        設定を kubectl.kubernetes.io/last-applied-configuration アノテーションとして追加するには、 --save-config オプションを oc create コマンドに追加します。

        デフォルトでは、テンプレートは project-request という名前になります。

   • プロジェクト要求テンプレートがクラスター内にすでに存在する場合は、以下を実行します。

     注記

     設定ファイルを使用してクラスター内のオブジェクトを宣言的または命令的に管理する場合は、これらのファイルを使用して既存のプロジェクト要求テンプレートを編集します。

     1. openshift-config namespace のテンプレートを一覧表示します。

        $ oc get templates -n openshift-config

     2. 既存のプロジェクト要求テンプレートを編集します。

        $ oc edit template <project_request_template> -n openshift-config

     3. 前述の storage-consumption の例などのリソースクォータ定義を既存のテンプレートに追加します。テンプレートの parameters: セクションの前に定義を追加する必要があります。

2. プロジェクト要求テンプレートを作成した場合は、クラスターのプロジェクト設定リソースでこれを参照します。

   1. 編集するプロジェクト設定リソースにアクセスします。

      • Web コンソールの使用

        1. Administration → Cluster Settings ページに移動します。
        2. Global Configuration をクリックし、すべての設定リソースを表示します。
        3. Project のエントリーを見つけ、Edit YAML をクリックします。

      • CLI の使用

        1. project.config.openshift.io/cluster リソースを編集します。

           $ oc edit project.config.openshift.io/cluster

   2. プロジェクト設定リソースの spec セクションを更新し、projectRequestTemplate および name パラメーターを追加します。以下の例は、project-request というデフォルトのプロジェクト要求テンプレートを参照します。

      apiVersion: config.openshift.io/v1
      kind: Project
      metadata:
        ...
      spec:
        projectRequestTemplate:
          name: project-request

3. プロジェクトの作成時にリソースクォータが適用されていることを確認します。

   1. プロジェクトを作成します。

      $ oc new-project <project_name>

   2. プロジェクトのリソースクォータを一覧表示します。

      $ oc get resourcequotas

   3. リソースクォータを詳細に記述します。

      $ oc describe resourcequotas <resource_quota_name>

手順

1. アノテーションに基づいてプロジェクトを選択するには、以下のコマンドを実行します。

   $ oc create clusterquota for-user \
        --project-annotation-selector openshift.io/requester=<user_name> \
        --hard pods=10 \
        --hard secrets=20

   これにより、以下の ClusterResourceQuota オブジェクトが作成されます。

   apiVersion: v1
   kind: ClusterResourceQuota
   metadata:
     name: for-user
   spec:
     quota: 1
       hard:
         pods: "10"
         secrets: "20"
     selector:
       annotations: 2
         openshift.io/requester: <user_name>
       labels: null 3
   status:
     namespaces: 4
     - namespace: ns-one
       status:
         hard:
           pods: "10"
           secrets: "20"
         used:
           pods: "1"
           secrets: "9"
     total: 5
       hard:
         pods: "10"
         secrets: "20"
       used:
         pods: "1"
         secrets: "9"

   1

   選択されたプロジェクトに対して実施される ResourceQuotaSpec オブジェクトです。

   2

   アノテーションの単純なキー/値のセレクターです。

   3

   プロジェクトを選択するために使用できるラベルセレクターです。

   4

   選択された各プロジェクトの現在のクォータの使用状況を記述する namespace ごとのマップです。

   5

   選択されたすべてのプロジェクトにおける使用量の総計です。

   この複数プロジェクトのクォータの記述は、デフォルトのプロジェクト要求エンドポイントを使用して <user_name> によって要求されるすべてのプロジェクトを制御します。ここでは、10 Pod および 20 シークレットに制限されます。

2. 同様にラベルに基づいてプロジェクトを選択するには、以下のコマンドを実行します。

   $  oc create clusterresourcequota for-name \1
       --project-label-selector=name=frontend \2
       --hard=pods=10 --hard=secrets=20

   1

   clusterresourcequota および clusterquota はいずれも同じコマンドのエイリアスです。for-name は ClusterResourceQuota オブジェクトの名前です。

   2

   ラベル別にプロジェクトを選択するには、--project-label-selector=key=value 形式を使用してキーと値のペアを指定します。

   これにより、以下の ClusterResourceQuota オブジェクト定義が作成されます。

   apiVersion: v1
   kind: ClusterResourceQuota
   metadata:
     creationTimestamp: null
     name: for-name
   spec:
     quota:
       hard:
         pods: "10"
         secrets: "20"
     selector:
       annotations: null
       labels:
         matchLabels:
           name: frontend

手順

1. プロジェクトに適用されているクォータを表示するには、以下を実行します。

   $ oc describe AppliedClusterResourceQuota

   出力例

   Name:   for-user
   Namespace:  <none>
   Created:  19 hours ago
   Labels:   <none>
   Annotations:  <none>
   Label Selector: <null>
   AnnotationSelector: map[openshift.io/requester:<user-name>]
   Resource  Used  Hard
   --------  ----  ----
   pods        1     10
   secrets     9     20

手順

1. 単一のサービスをアイドリングするには、以下を実行します。

   $ oc idle <service>

手順

1. 複数サービスの一覧を含むファイルを作成します (それぞれを各行に指定)。

2. --resource-names-file オプションを使用してサービスをアイドリングします。

   $ oc idle --resource-names-file <filename>

手順

1. プルーニング操作によって削除されるものを確認するには、以下を実行します。

   1. 最高 3 つのタグリビジョンを保持し、60 分前よりも後に作成されたリソース (イメージ、イメージストリームおよび Pod) を保持します。

      $ oc adm prune images --keep-tag-revisions=3 --keep-younger-than=60m

   2. 定義された制限を超えるすべてのイメージをプルーニングします。

      $ oc adm prune images --prune-over-size-limit

2. 前述のステップからオプションを指定してプルーニングの操作を実行するには、以下を実行します。

   $ oc adm prune images --keep-tag-revisions=3 --keep-younger-than=60m --confirm

   $ oc adm prune images --prune-over-size-limit --confirm

1. prune コマンドが --force-insecure オプションと共に実行される。
2. 指定される registry-url の前に http:// スキームが付けられる。
3. 指定される registry-url はローカルリンクアドレスまたは localhost である。
4. 現行ユーザーの設定が非セキュアな接続を許可する。これは、ユーザーが --insecure-skip-tls-verify を使用してログインするか、またはプロンプトが出される際に非セキュアな接続を選択することによって生じる可能性があります。