ワークロードをデプロイする

このページでは、Google Distributed Cloud に接続されたハードウェアにワークロードをデプロイする手順と、ワークロードを構成する際に遵守する必要がある制限事項について説明します。

これらの手順を完了する前に、Distributed Cloud 接続インストール要件を満たし、Distributed Cloud ハードウェアを注文する必要があります。

Google Distributed Cloud コネクテッド ハードウェアが選択した宛先に到着すると、Distributed Cloud コネクテッドの注文時に指定したハードウェア、 Google Cloud、一部のネットワーク設定が事前構成されています。

Google の設置担当者が物理的な設置を完了し、システム管理者が Distributed Cloud connected をローカル ネットワークに接続します。

ハードウェアがローカル ネットワークに接続されると、 Google Cloud と通信してソフトウェア アップデートをダウンロードし、Google Cloud プロジェクトに接続します。これで、ノードプールをプロビジョニングして、Distributed Cloud コネクテッドにワークロードをデプロイする準備が整いました。

デプロイの概要

Distributed Cloud 接続ハードウェアにワークロードをデプロイする手順は次のとおりです。

  1. 省略可: Distributed Cloud Edge Network API を有効にします。

  2. 省略可: Distributed Cloud コネクテッド ゾーンのネットワーク構成を初期化します。

  3. 省略可: Distributed Cloud ネットワーキングを構成します。

  4. Distributed Cloud コネクテッド クラスタを作成します。

  5. 省略可: Cloud Key Management Service と統合してワークロード データの CMEK のサポートを有効にする場合は、[ローカル ストレージの顧客管理の暗号鍵（CMEK）のサポートを有効にする] を選択します。Distributed Cloud Connected がワークロード データを暗号化する方法については、ローカル ストレージのセキュリティをご覧ください。

  6. ノードプールを作成する。このステップでは、ノードをノードプールに割り当て、必要に応じて、Cloud KMS を使用してワークロード データの暗号化に使用する Linux Unified Key Setup（LUKS）パスフレーズをラップおよびラップ解除するようにノードプールを構成します。

  7. クラスタの認証情報を取得して、クラスタをテストします。

  8. プロジェクトに対する Edge Container 閲覧者ロール（roles/edgecontainer.viewer）または Edge Container 管理者ロール（roles/edgecontainer.admin）を割り当てて、ユーザーにクラスタへのアクセス権を付与します。

  9. RoleBinding と ClusterRoleBinding を使用して、クラスタ リソースへのきめ細かいロールベースのアクセス権をユーザーに割り当てます。

  10. 省略可: Google Distributed Cloud 上の VM ランタイムのサポートを有効にして、Distributed Cloud Connected の仮想マシンでワークロードを実行します。

  11. 省略可: GPU サポートを有効にして、Distributed Cloud コネクテッドで GPU ベースのワークロードを実行します。

NGINX ロードバランサをサービスとしてデプロイする

次の例は、NGINX サーバーをデプロイし、Distributed Cloud 接続クラスタでサービスとして公開する方法を示しています。

  1. 次の内容で nginx-deployment.yaml という名前の YAML ファイルを作成します。

    apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
labels:
  app: nginx
spec:
replicas: 1
selector:
  matchLabels:
     app: nginx
template:
  metadata:
     labels:
     app: nginx
  spec:
     containers:
     - name: nginx
     image: nginx:latest
     ports:
     - containerPort: 80

  2. 次のコマンドを使用して、YAML ファイルをクラスタに適用します。

    kubectl apply -f nginx-deployment.yaml

  3. 次の内容で nginx-service.yaml という名前の YAML ファイルを作成します。

    apiVersion: v1
kind: Service
metadata:
name: nginx-service
spec:
type: LoadBalancer
selector:
  app: nginx
  ports:
     - protocol: TCP
       port: 8080
       targetPort: 80

  4. 次のコマンドを使用して、YAML ファイルをクラスタに適用します。

    kubectl apply -f nginx-deployment.yaml

  5. 次のコマンドを使用して、MetalLB ロードバランサによってサービスに割り当てられた外部 IP アドレスを取得します。

    kubectl get services

    このコマンドでは、次のような出力が返されます。

    NAME            TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)          AGE
nginx-service   LoadBalancer   10.51.195.25   10.100.68.104   8080:31966/TCP   11d

NodeSystemConfigUpdate リソースを構成する

クラスタ内の各ノードに対して、次のように NodeSystemConfigUpdate ネットワーク関数オペレータ リソースを構成します。

  1. 次のコマンドを使用して、ターゲット クラスタのノードプールで実行されているノードを一覧表示します。

    kubectl get nodes | grep -v master

    このコマンドでは、次のような出力が返されます。

    NAME                                 STATUS   ROLES       AGE     VERSION
pool-example-node-1-01-b2d82cc7      Ready    <none>      2d      v1.22.8-gke.200
pool-example-node-1-02-52ddvfc9      Ready    <none>      2d      v1.22.8-gke.200

    返されたノード名を記録し、その短縮名を導出します。たとえば、pool-example-node-1-01-b2d82cc7 ノードの略称は node101 です。

  2. 前の手順で記録した各ノードについて、次の内容を含む専用の NodeSystemConfigUpdate リソース ファイルを作成します。

    apiVersion: networking.gke.io/v1
kind: NodeSystemConfigUpdate
metadata:
name: nodesystemconfigupdate-NODE_SHORT_NAME
namespace: nf-operator
spec:
kubeletConfig:
  cpuManagerPolicy: Static
  topologyManagerPolicy: SingleNumaNode
nodeName: NODE_NAME
osConfig:
  hugePagesConfig:
     ONE_GB: 2
     TWO_MB: 0
  isolatedCpusPerSocket:
     "0": 40
     "1": 40
sysctls:
  nodeLevel:
     net.core.rmem_max: "8388608"
     net.core.wmem_max: "8388608"

    次のように置き換えます。

    • NODE_NAME: ターゲット ノードの完全な名前。例: pool-example-node-1-01-b2d82cc7
    • NODE_SHORT_NAME: ターゲット ノードの完全名から派生した短い名前。例: node101

    各ファイルに node-system-config-update-NODE_SHORT_NAME.yaml という名前を付けます。

  3. 次のコマンドを使用して、各 NodeSystemConfigUpdate リソース ファイルをクラスタに適用します。

    kubectl apply -f node-system-config-update-NODE_SHORT_NAME.yaml

    NODE_SHORT_NAME は、対応するターゲット ノードの短い名前に置き換えます。

    リソースをクラスタに適用すると、影響を受ける各ノードが再起動します。これには最大 30 分かかることがあります。

    1. 影響を受けるノードのステータスをモニタリングし、すべてのノードが正常に再起動されるまで待ちます。
    kubectl get nodes | grep -v master

    各ノードのステータスは、再起動が完了すると not-ready から ready に移行します。

イメージ キャッシュ用の Pod を構成する

Distributed Cloud 接続クラスタで実行されている Pod を構成して、イメージをキャッシュに保存できます。Pod は、リポジトリから初めて pull された後、キャッシュに保存されたイメージの使用を開始します。Pod をホストするノードのストレージが不足すると、新しいイメージはキャッシュに保存されず、既存のイメージ キャッシュは削除されます。これにより、ワークロードが中断なく実行され続けます。

Pod 構成は次の前提条件を満たしている必要があります。

  • Pod に gdce.baremetal.cluster.gke.io/cache-image: true ラベルを設定する必要があります。
  • 非公開イメージ リポジトリを使用している場合、ImagePullSecret リソースのタイプは kubernetes.io/dockerconfigjson である必要があります。
  • ターゲット イメージのキャッシュ コピーが常に使用されるように、Pod の pull ポリシーを IfNotPresent に設定する必要があります。キャッシュされたコピーがローカルで利用できない場合、イメージはリポジトリから pull されます。

次の例は、キャッシュ保存が有効になっている Pod 構成を示しています。

apiVersion: v1
kind: Pod
metadata:
  name: cached-image-pod
  labels:
    gdce.baremetal.cluster.gke.io/cache-image: "true"
spec:
  containers:
    - name: my-container
      image: your-private-image-repo/your-image:tag
      imagePullPolicy: IfNotPresent
  imagePullSecrets:
    - name: my-image-secret  # If using a private registry

次の例は、キャッシュ保存が有効になっている Deployment 構成を示しています。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cached-image-deployment
spec:
  template:
    metadata:
      labels:
        gdce.baremetal.cluster.gke.io/cache-image: "true"
    spec:
      containers:
        - name: my-container
          image: your-private-image-repo/your-image:tag
          imagePullPolicy: IfNotPresent
      imagePullSecrets:
        - name: my-image-secret  # If using a private registry

Distributed Cloud ワークロードの制限事項

Distributed Cloud 接続ワークロードを構成する場合は、このセクションで説明する制限事項を遵守する必要があります。これらの制限は、Distributed Cloud コネクテッド ハードウェアにデプロイするすべてのワークロードで Distributed Cloud コネクテッドによって適用されます。

Linux ワークロードの制限

Distributed Cloud Connected は、ワークロードに関する次の Linux 機能のみをサポートします。

  • AUDIT_READ
  • AUDIT_WRITE
  • CHOWN
  • DAC_OVERRIDE
  • FOWNER
  • FSETID
  • IPC_LOCK
  • IPC_OWNER
  • KILL
  • MKNOD
  • NET_ADMIN
  • NET_BIND_SERVICE
  • NET_RAW
  • SETFCAP
  • SETGID
  • SETPCAP
  • SETUID
  • SYS_CHROOT
  • SYS_NICE
  • SYS_PACCT
  • SYS_PTRACE
  • SYS_RESOURCE
  • SYS_TIME

Namespace の制限事項

Distributed Cloud connected は、次の名前空間をサポートしていません。

  • hostPID
  • hostIPC
  • hostNetwork

リソースタイプの制限

Distributed Cloud Connected は、署名リクエストに基づいてクライアントが X.509 証明書の発行をリクエストできる CertificateSigningRequest リソースタイプをサポートしていません。

セキュリティ コンテキストの制限

Distributed Cloud Connected は、特権モードのセキュリティ コンテキストをサポートしていません。

Pod バインディングの制限

Distributed Cloud connected は、Pod から HostNetwork 名前空間内のホストポートへのバインドをサポートしていません。また、HostNetwork 名前空間は使用できません。

hostPath の音量制限

Distributed Cloud Connected では、読み取り/書き込みアクセス権を持つ次の hostPath ボリュームのみが許可されます。

  • /dev/hugepages
  • /dev/infiniband
  • /dev/vfio
  • /dev/char
  • /sys/devices

PersistentVolumeClaim リソースタイプの制限

Distributed Cloud Connected で許可される PersistentVolumeClaim リソースタイプは次のとおりです。

  • csi
  • nfs
  • local

ボリューム タイプの制限

Distributed Cloud Connected では、次のボリューム タイプのみが許可されます。

  • configMap
  • csi
  • downwardAPI
  • emptyDir
  • hostPath
  • nfs
  • persistentVolumeClaim
  • projected
  • secret

Pod の容認制限

Distributed Cloud Connected では、コントロール プレーン ノードでユーザーが作成した Pod は許可されません。具体的には、Distributed Cloud Connected では、次の容認キーを持つ Pod のスケジュール設定は許可されません。

  • ""
  • node-role.kubernetes.io/master
  • node-role.kubernetes.io/control-plane

権限借用の制限

Distributed Cloud Connected は、ユーザーまたはグループの権限借用をサポートしていません。

管理 Namespace の制限事項

Distributed Cloud connected では、次の名前空間へのアクセスは許可されていません。

  • ai-system
  • ai-speech-system
  • ai-ocr-system
  • ai-translation-system
  • anthos-identity-service
  • cert-manager
  • dataproc-system
  • dataproc-PROJECT_ID
  • dns-system
  • g-istio-system
  • gke-connect
  • gke-managed-metrics-server
  • gke-operators
  • g-ospf-servicecontrol-system
  • g-ospf-system
  • g-pspf-system
  • gke-system
  • gpc-backup-system
  • iam-system
  • kube-node-lease
  • kube-public
  • kube-system（ippools.whereabouts.cni.cncf.io の削除を除く）
  • metallb-system（ロード バランシング IP アドレス範囲を設定するための configMap リソースの編集を除く）
  • nf-operator
  • oclcm-system
  • prediction
  • rm-system
  • robinio
  • saas-system
  • vm-system

PROJECT_ID は、ターゲット Google Cloud プロジェクトの ID を示します。

名前に g- 接頭辞が付いている Namespace は使用しないでください。このような名前空間は通常、Distributed Cloud コネクテッドで使用される予約済みの名前空間です。

Webhook を制限

Distributed Cloud connected では、Webhook は次のように制限されます。

  • 作成した変更用 Webhook は、kube-system Namespace を自動的に除外します。
  • 次のリソースタイプでは、ミューテーション Webhook が無効になっています。
    • nodes
    • persistentvolumes
    • certificatesigningrequests
    • tokenreviews

Pod の優先度の制限

Distributed Cloud Connected では、ワークロード Pod の優先度を 500000000 より小さい値に設定する必要があります。

Pod のランタイム クラスを構成する

Distributed Cloud connected では、runtimeClassName フィールドを使用して、構成内の Pod のランタイム クラスを指定できます。これにより、クラスタレベルで指定されたデフォルトのランタイム クラスがオーバーライドされます。使用可能なランタイム クラスは runc と gvisor です。次に例を示します。

apiVersion: v1
kind: Pod
metadata:
  name: myPod
spec:
  runtimeClassName: gvisor
  containers:
  - name: myPod
    image: myPodImage 
  restartPolicy: OnFailure

Pod 構成でこれを省略すると、Pod はクラスタレベルで指定されたクラスを使用します。クラスタを作成して管理するの説明に従って --default-container-runtime パラメータを使用してデフォルトのランタイム クラスを構成しない限り、デフォルトのクラスタレベルのランタイム クラスは runc です。

Pod レベルまたはクラスタレベルでランタイム クラスを変更した場合は、変更を有効にするために影響を受ける Pod を再起動する必要があります。

gvisor ランタイム クラス

gvisor ランタイム クラスを指定すると、Pod は gVisor に基づく Open Container Initiative（OCI）セキュア ランタイムに切り替わります。gVisor は、ワークロードとそのホスト間に強力な分離を導入するサンドボックス ソリューションです。

次のステップ