バージョン情報については、Distributed Cloud 接続のリリースノートをご覧ください。

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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

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

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

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

Google のインストーラが物理的なインストールを完了し、システム管理者が Distributed Cloud コネクテッドをローカルネットワークに接続します。

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

デプロイの概要

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

省略可: Distributed Cloud Edge Network API を有効にします。
省略可: Distributed Cloud コネクテッドゾーンのネットワーク構成を初期化します。
省略可: Distributed Cloud ネットワークを構成します。
Distributed Cloud コネクテッドクラスタを作成します。
省略可: ローカルストレージの顧客管理の暗号鍵（CMEK）のサポートを有効にする場合は、Cloud Key Management Service と統合してワークロードデータの CMEK のサポートを有効にします。Distributed Cloud コネクテッドがワークロードデータを暗号化する方法については、ローカルストレージのセキュリティをご覧ください。
ノードプールを作成します。このステップでは、ノードをノードプールに割り当てます。必要に応じて、Cloud KMS を使用して、ワークロードデータを暗号化するための Linux Unified Key Setup（LUKS）パスフレーズをラップおよびアンラップするようにノードプールを構成します。
クラスタの認証情報を取得してクラスタをテストします。
プロジェクトに対する Edge Container 閲覧者ロール（roles/edgecontainer.viewer）または Edge Container 管理者ロール（roles/edgecontainer.admin）をユーザーに割り当てて、クラスタへのアクセス権を付与します。
ユーザーにクラスタリソースへのきめ細かいロールベースのアクセス権を割り当てるには、 RoleBinding と ClusterRoleBinding を使用します。
省略可: Google Distributed Cloud 上の VM ランタイムのサポートを有効にして、 Distributed Cloud コネクテッド上の仮想マシンでワークロードを実行します。
省略可: GPU サポートを有効にして、 Distributed Cloud コネクテッドで GPU ベースのワークロードを実行します。

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

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

次の内容で 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

次のコマンドを使用して、YAML ファイルをクラスタに適用します。
```
kubectl apply -f nginx-deployment.yaml
```

次の内容で 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

次のコマンドを使用して、YAML ファイルをクラスタに適用します。
```
kubectl apply -f nginx-deployment.yaml
```
次のコマンドを使用して、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 ネットワーク関数オペレータリソースを構成します。

次のコマンドを使用して、ターゲットクラスタのノードプールで実行されているノードを一覧表示します。
```
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 です。

前のステップで記録した各ノードについて、次の内容で専用の 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 という名前を付けます。

次のコマンドを使用して、各 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 コネクテッドは、ワークロードに関する次の 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 コネクテッドは、次の Namespace をサポートしていません。

hostPID
hostIPC
hostNetwork

リソースタイプの制限

Distributed Cloud コネクテッドは、CertificateSigningRequest リソースタイプをサポートしていません。このリソースタイプを使用すると、クライアントは署名リクエストに基づいて X.509 証明書の発行をリクエストできます。

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

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

Pod バインディングの制限

Distributed Cloud コネクテッドは、Pod から HostNetwork Namespace 内のホストポートへのバインドをサポートしません。また、HostNetwork Namespace は使用できません。

`hostPath` ボリュームの制限

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

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

`PersistentVolumeClaim` リソースタイプの制限

Distributed Cloud コネクテッドでは、次の PersistentVolumeClaim リソースタイプのみが許可されます。

csi
nfs
local

ボリュームタイプの制限

Distributed Cloud コネクテッドでは、次のボリュームタイプのみが許可されます。

configMap
csi
downwardAPI
emptyDir
hostPath
nfs
persistentVolumeClaim
projected
secret

Pod の容認の制限

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

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

なりすましの制限

Distributed Cloud コネクテッドは、ユーザーまたはグループの権限借用をサポートしていません。

管理 Namespace の制限

Distributed Cloud コネクテッドでは、次の Namespace へのアクセスは許可されません。

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 は使用しないでください。このような Namespace は通常、Distributed Cloud コネクテッドで使用される予約済みの Namespace です。

Webhook を制限

Distributed Cloud コネクテッドは、Webhook を次のように制限します。

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

Pod の優先度の制限

Distributed Cloud コネクテッドでは、ワークロード Pod の優先度を 500000000 未満の値に設定する必要があります。

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

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

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

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

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

`gvisor` ランタイムクラス

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

VPC Service Controls の統合を構成する

このセクションの手順を完了して、Distributed Cloud Edge Container API と VPC Service Controls の統合を構成します。詳しくは以下をご覧ください。

必要な下り（外向き）ルール

Distributed Cloud Edge Container API と VPC Service Controls を統合するには、このセクションで説明する下り（外向き）ルールを構成する必要があります。下り（外向き）ルールの構文については、下り（外向き）ルールのリファレンスをご覧ください。

マシンゾーンと Google Cloud プロジェクトへのアクセス

このルールにより、呼び出し元 ID は、Distributed Cloud Edge Container API を使用して呼び出しを行うときに、マシンゾーンと Google Cloud プロジェクトにアクセスできます。このルールは、マシンとクラスタが同じ Google Cloud プロジェクトに存在せず、マシン Google Cloud プロジェクトが境界外にある場合に適用されます。VPC Service Controls を使用して境界内の Distributed Cloud Edge Container API を制限している場合は、このルールが必要です。

JSON 形式のこのルールの egressFrom 構成の例を次に示します。

egressFrom:
  identityType: ANY_SERVICE_ACCOUNT
  sources:
    - accessLevel: "*"

このルールの egressTo 構成の例を次に示します。

egressTo:
 resources:
 - "projects/280968151686"
 operations:
   - serviceName: "edgecontainer.googleapis.com"
     methodSelectors:
       - method: "*"

必要な上り（内向き）ルール

Distributed Cloud Edge Container API と VPC Service Controls を統合するには、このセクションで説明する上り（内向き）ルールを構成する必要があります。上り（内向き）ルールの構文については、上り（内向き）ルールのリファレンスをご覧ください。

Distributed Cloud Edge Container API へのアクセス

このルールにより、特定の ID が Distributed Cloud Edge Container API にアクセスして操作できます。 VPC Service Controls を使用して境界内の Distributed Cloud Edge Container API を制限し、Distributed Cloud Edge Container API を呼び出す ID が境界外にある場合は、このルールを構成する必要があります。

このルールの ingressFrom 構成の例を次に示します。

ingressFrom:
   sources:
     - accessLevel: '*'
   identities:
     - serviceAccount:testuser@kubernetesedge-e2e-testing.iam.gserviceaccount.com

このルールの ingressTo 構成の例を次に示します。

ingressTo:
 resources:
 - "*"
 operations:
   - serviceName: "edgecontainer.googleapis.com"
     methodSelectors:
       - method: "*"

Connect API と Security Token Service API へのアクセス

このルールにより、ワークロードは Connect API と Security Token Service API にアクセスできます。 VPC Service Controls を使用して境界内の Connect API と Security Token Service API へのアクセスを制限している場合は、このルールを構成する必要があります。IP アドレスレベルでアクセスポリシーを設定する方法については、IP アドレスをご覧ください。