Kubernetes ダッシュボードの起動

ローカル・システムで Kubernetes ダッシュボードを開くと、クラスターとそのすべてのワーカー・ノードに関する情報が表示されます。 IBM Cloud コンソールでは、便利なワンクリック・ボタンでダッシュボードにアクセスできます。 CLI を使用すると、ダッシュボードにアクセスしたり、CI/CD パイプラインなどの自動化プロセスのステップを使用したりできます。

クラスター内のリソースやユーザーが多すぎて Kubernetes ダッシュボードが少し遅くなっていますか? クラスター管理者は kubernetes-dashboard を実行して kubectl -n kube-system scale deploy kubernetes-dashboard --replicas=3 デプロイメントをスケーリングできます。

個々のアプリ・ポッドのログを確認するには、kubectl logs <pod name> を実行します。 Kubernetes ダッシュボードを使用してポッドのログのストリーミングをしないでください。Kubernetes ダッシュボードへのアクセスが中断される可能性があります。

開始前に

• Kubernetes リソースを処理できる適切な Kubernetes RBAC 役割を付与する、サービス・アクセス役割が自分に割り当てられていることを確認します。
• コンソールから Kubernetes ダッシュボードを起動するには、プラットフォーム・アクセス役割が割り当てられている必要があります。 サービス・アクセス役割のみが割り当てられていて、プラットフォーム・アクセス役割が割り当てられていない場合は、CLI から Kubernetes ダッシュボードを起動してください。
• アカウントにログインします。 該当する場合は、適切なリソース・グループをターゲットにします。 クラスターのコンテキストを設定します。

クラスターの Kubernetes ダッシュボードを起動するために、デフォルトのポートを使用するか、独自のポートを設定できます。

Kubernetes ダッシュボードでアプリをデプロイする方法

Kubernetes ダッシュボードを使用してアプリをクラスターにデプロイすると、デプロイメント・リソースが、クラスター内にポッドを自動的に作成し、更新および管理します。 ダッシュボードの使い方の詳細については、 Kubernetes のドキュメントをご覧ください。

クラスター内のリソースやユーザーが多すぎて Kubernetes ダッシュボードが少し遅くなっていますか? クラスター管理者は kubernetes-dashboard を実行して kubectl -n kube-system scale deploy kubernetes-dashboard --replicas=3 デプロイメントをスケーリングできます。

開始前に

• 必要な CLI をインストールします。
• アカウントにログインします。 該当する場合は、適切なリソース・グループをターゲットにします。 クラスターのコンテキストを設定します。
• Kubernetes リソースを処理できる適切な Kubernetes RBAC 役割を付与する、サービス・アクセス役割が自分に割り当てられていることを確認します。
• コンソールから Kubernetes ダッシュボードを起動するには、プラットフォーム・アクセス役割が割り当てられている必要があります。 サービス・アクセス役割のみが割り当てられていて、プラットフォーム・アクセス役割が割り当てられていない場合は、CLI から Kubernetes ダッシュボードを起動してください。

アプリをデプロイするには、以下のようにします。

1. Kubernetes ダッシュボードを開き、**「+ 作成」**をクリックします。

2. 2 つの方法のいずれかでアプリの詳細を入力します。

   • アプリの詳細を指定 」を選択し、詳細を入力します。
   • Upload a YAML or JSON fileを選択して、アプリ 設定ファイルをアップロードします。

   構成ファイルのヘルプが必要な場合は、 この YAML ファイルの例を確認してください。 この例では、コンテナーは米国南部リージョンの ibmliberty イメージからデプロイされます。 Kubernetes リソースを処理する際の個人情報の保護の詳細を確認してください。

3. 以下のいずれかの方法でアプリを正常にデプロイしたことを確認します。

   • Kubernetes ダッシュボードで、**「デプロイメント」**をクリックします。 正常なデプロイメントのリストが表示されます。
   • アプリが公開されている場合は、IBM Cloud® Kubernetes Service ダッシュボードのクラスター概要ページにナビゲートします。 クラスター概要セクションにあるサブドメインをコピーし、ブラウザーに貼り付けてアプリを表示します。

CLI でアプリをデプロイする方法

クラスターを作成したら、Kubernetes CLI を使用してそのクラスターにアプリをデプロイできます。

開始前に

• 必要な CLI をインストールします。
• アカウントにログインします。 該当する場合は、適切なリソース・グループをターゲットにします。 クラスターのコンテキストを設定します。
• 名前空間内の Kubernetes リソースを処理できる適切な Kubernetes RBAC 役割を付与する、サービス・アクセス役割が自分に割り当てられていることを確認します。

アプリをデプロイするには、以下のようにします。

1. Kubernetes、ベストプラクティスに基づいてコンフィギュレーションファイルを作成する。 基本的に、構成ファイルには、Kubernetes で作成する各リソースの構成の詳細情報が格納されます。 スクリプトに以下のセクションを 1 つ以上追加できます。

   • デプロイメント ：ポッドとレプリカセットの作成を定義する。 1 つのポッドにコンテナー化アプリを 1 つ組み込み、レプリカ・セットによってポッドの複数インスタンスを制御します。

   • サービス ：ワーカーノードまたはロードバランサーのパブリックIPアドレス、またはパブリックIngressルートを使用して、Podへのフロントエンドアクセスを提供します。

   • Ingress ：ロードバランサーの種類を指定します。

   Kubernetes リソースを処理する際の個人情報の保護の詳細を確認してください。

2. クラスターのコンテキストで構成ファイルを実行します。

   kubectl apply -f config.yaml
   

3. ノード・ポート・サービス、ロード・バランサー・サービス、または Ingress を使用して、アプリをだれでも利用できるようにした場合は、アプリにアクセスできることを確認します。

ラベルを使用した特定のワーカー・ノードへのアプリのデプロイ

アプリをデプロイすると、アプリ・ポッドが、クラスター内のさまざまなワーカー・ノードに無差別にデプロイされます。 場合によっては、アプリ・ポッドのデプロイ先のワーカー・ノードを制限する必要があります。 例えば、特定のワーカー・プールのワーカー・ノードがベアメタル・マシン上にあるため、これらのワーカー・ノードにのみアプリ・ポッドがデプロイされるようにしたいとします。 アプリ・ポッドをデプロイするワーカー・ノードを指定するには、アプリのデプロイメントにアフィニティー・ルールを追加します。

開始前に

• アカウントにログインします。 該当する場合は、適切なリソース・グループをターゲットにします。 クラスターのコンテキストを設定します。
• オプション: アプリを実行するワーカー・プールのラベルを設定します。

特定のワーカー・ノードにアプリをデプロイするには、以下のようにします。

1. アプリ・ポッドをデプロイするワーカー・プールの ID を取得します。

   ibmcloud ks worker-pool ls --cluster <cluster_name_or_ID>
   

2. ワーカー・プールにあるワーカー・ノードをリストし、プライベート IP アドレスの 1 つをメモします。

   ibmcloud ks worker ls --cluster <cluster_name_or_ID> --worker-pool <worker_pool_name_or_ID>
   

3. ワーカー・ノードの説明を表示します。 Labels 出力で、ワーカー・プール ID ラベル ibm-cloud.kubernetes.io/worker-pool-id をメモします。

   このトピックで示す手順では、ワーカー・プール ID を使用して、そのワーカー・プール内のワーカー・ノードにのみアプリ・ポッドをデプロイします。 別のラベルを使用して特定のワーカー・ノードにアプリ・ポッドをデプロイするには、代わりにそのラベルをメモしてください。 例えば、特定のプライベート VLAN 上にあるワーカー・ノードにのみアプリ・ポッドをデプロイするには、privateVLAN= ラベルを使用します。

   kubectl describe node <worker_node_private_IP>
   

   出力例

   NAME:               10.xxx.xx.xxx
   Roles:              <none>
   Labels:             arch=amd64
                       beta.kubernetes.io/arch=amd64
                       beta.kubernetes.io/instance-type=b3c.4x16.encrypted
                       beta.kubernetes.io/os=linux
                       failure-domain.beta.kubernetes.io/region=us-south
                       failure-domain.beta.kubernetes.io/zone=dal10
                       ibm-cloud.kubernetes.io/encrypted-docker-data=true
                       ibm-cloud.kubernetes.io/ha-worker=true
                       ibm-cloud.kubernetes.io/iaas-provider=softlayer
                       ibm-cloud.kubernetes.io/machine-type=b3c.4x16.encrypted
                       ibm-cloud.kubernetes.io/sgx-enabled=false
                       ibm-cloud.kubernetes.io/worker-pool-id=00a11aa1a11aa11a1111a1111aaa11aa-11a11a
                       ibm-cloud.kubernetes.io/worker-version=1.32_1534
                       kubernetes.io/hostname=10.xxx.xx.xxx
                       privateVLAN=1234567
                       publicVLAN=7654321
   Annotations:        node.alpha.kubernetes.io/ttl=0
   ...
   

4. ワーカー プール ID ラベルの アフィニティ ルールをアプリのデプロイメントに追加します。

   YAML の例

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: with-node-affinity
   spec:
     template:
       spec:
         affinity:
           nodeAffinity:
             requiredDuringSchedulingIgnoredDuringExecution:
               nodeSelectorTerms:
               - matchExpressions:
                 - key: ibm-cloud.kubernetes.io/worker-pool-id
                   operator: In
                   values:
                   - <worker_pool_ID>
   ...
   

   YAML の例のアフィニティー (affinity) セクションでは、ibm-cloud.kubernetes.io/worker-pool-id は key、<worker_pool_ID> は value です。

5. 更新したデプロイメント構成ファイルを適用します。

   kubectl apply -f with-node-affinity.yaml
   

6. アプリ・ポッドが、正しいワーカー・ノードにデプロイされたことを確認します。

   1. クラスター内のポッドをリストします。

      kubectl get pods -o wide
      

      出力例

      NAME                   READY     STATUS              RESTARTS   AGE       IP               NODE
      cf-py-d7b7d94db-vp8pq  1/1       Running             0          15d       172.30.xxx.xxx   10.176.48.78
      

   2. 出力で、アプリのポッドを確認します。 ポッドがあるワーカー・ノードの NODE プライベート IP アドレスをメモします。

      前述の出力例で、アプリ・ポッド cf-py-d7b7d94db-vp8pq は、IP アドレス 10.xxx.xx.xxx のワーカー・ノード上にあります。

   3. アプリのデプロイメントに指定したワーカー・プール内にあるワーカー・ノードをリストします。

      ibmcloud ks worker ls --cluster <cluster_name_or_ID> --worker-pool <worker_pool_name_or_ID>
      

      出力例

      ID                                                 Public IP       Private IP     Machine Type      State    Status  Zone    Version
      kube-dal10-crb20b637238bb471f8b4b8b881bbb4962-w7   169.xx.xxx.xxx  10.176.48.78   b3c.4x16          normal   Ready   dal10   1.8.6_1504
      kube-dal10-crb20b637238bb471f8b4b8b881bbb4962-w8   169.xx.xxx.xxx  10.176.48.83   b3c.4x16          normal   Ready   dal10   1.8.6_1504
      kube-dal12-crb20b637238bb471f8b4b8b881bbb4962-w9   169.xx.xxx.xxx  10.176.48.69   b3c.4x16          normal   Ready   dal12   1.8.6_1504
      

      別の要因に基づいてアプリのアフィニティー・ルールを作成した場合は、代わりにその値を取得してください。 例えば、アプリ・ポッドが特定の VLAN 上のワーカー・ノードにデプロイされたことを確認するには、ibmcloud ks worker get --cluster <cluster_name_or_ID> --worker <worker_ID> を実行して、そのワーカー・ノードが存在する VLAN を表示します。

   4. 出力で、前のステップで指定したプライベート IP アドレスを持つワーカー・ノードがこのワーカー・プールにデプロイされていることを確認します。

NVIDIA GPUマシンにアプリをデプロイする

GPU マシン・タイプを使用している場合は、AI、機械学習、推論などの計算主体のワークロードに必要な処理時間を短縮できます。

IBM Cloud Kubernetes Serviceでは、必要な GPU ドライバーが自動的にインストールされます。

以下のステップは、GPU を必要とするワークロードをデプロイする方法を示しています。 しかし、GPUとCPUの両方でワークロードを処理する必要のないアプリをデプロイすることもできます。

また、 この Kubernetes デモを使用して、 TensorFlow 機械学習フレームワークなどの数学的に負荷の高いワークロードを試すこともできます。