Untuk mengetahui informasi versi, lihat catatan rilis Distributed Cloud terhubung.

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

Men-deploy workload

Halaman ini menjelaskan langkah-langkah untuk men-deploy workload di hardware Google Distributed Cloud terhubung dan batasan yang harus Anda patuhi saat mengonfigurasi workload.

Sebelum menyelesaikan langkah-langkah ini, Anda harus memenuhi persyaratan penginstalan Distributed Cloud terhubung dan memesan hardware Distributed Cloud.

Saat hardware Google Distributed Cloud terhubung tiba di tujuan yang Anda pilih, hardware tersebut telah dikonfigurasi sebelumnya dengan hardware, Google Cloud, dan beberapa setelan jaringan yang Anda tentukan saat Anda memesan Distributed Cloud terhubung.

Penginstal Google menyelesaikan penginstalan fisik, dan administrator sistem Anda menghubungkan Distributed Cloud terhubung ke jaringan lokal Anda.

Setelah terhubung ke jaringan lokal Anda, hardware akan berkomunikasi dengan Google Cloud untuk mendownload update software dan terhubung dengan Google Cloud project Anda. Kemudian, Anda siap menyediakan node pool dan men-deploy workload di Distributed Cloud terhubung.

Ringkasan deployment

Untuk men-deploy workload di hardware Distributed Cloud terhubung, selesaikan langkah-langkah berikut:

Opsional: Aktifkan Distributed Cloud Edge Network API.
Opsional: Lakukan inisialisasi konfigurasi jaringan zona Distributed Cloud terhubung.
Opsional: Konfigurasi jaringan Distributed Cloud.
Buat cluster Distributed Cloud terhubung.
Opsional: Aktifkan dukungan untuk kunci enkripsi yang dikelola pelanggan (CMEK) untuk penyimpanan lokal jika Anda ingin berintegrasi dengan Cloud Key Management Service untuk mengaktifkan dukungan CMEK untuk data workload Anda. Untuk mengetahui informasi tentang cara Distributed Cloud terhubung mengenkripsi data workload, lihat Keamanan penyimpanan lokal.
Buat node pool. Pada langkah ini, Anda menetapkan node ke node pool dan secara opsional mengonfigurasi node pool untuk menggunakan Cloud KMS guna mengenkripsi dan mendekripsi sandi Linux Unified Key Setup (LUKS) untuk mengenkripsi data workload.
Dapatkan kredensial untuk cluster guna menguji cluster.
Beri pengguna akses ke cluster dengan menetapkan mereka peran Edge Container Viewer (roles/edgecontainer.viewer) atau peran Edge Container Admin (roles/edgecontainer.admin) pada project.
Tetapkan akses berbasis peran yang terperinci kepada pengguna ke resource cluster menggunakan RoleBinding dan ClusterRoleBinding.
Opsional: Aktifkan dukungan VM Runtime di Google Distributed Cloud untuk menjalankan workload di mesin virtual di Distributed Cloud terhubung.
Opsional: Aktifkan dukungan GPU untuk menjalankan workload berbasis GPU di Distributed Cloud terhubung.

Men-deploy load balancer NGINX sebagai layanan

Contoh berikut mengilustrasikan cara men-deploy server NGINX dan mengeksposnya sebagai layanan di cluster Distributed Cloud terhubung:

Buat file YAML bernama nginx-deployment.yaml dengan konten berikut:

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

Terapkan file YAML ke cluster menggunakan perintah berikut:
```
kubectl apply -f nginx-deployment.yaml
```

Buat file YAML bernama nginx-service.yaml dengan konten berikut:

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

Terapkan file YAML ke cluster menggunakan perintah berikut:
```
kubectl apply -f nginx-deployment.yaml
```

Dapatkan alamat IP eksternal yang ditetapkan ke layanan oleh load balancer MetalLB menggunakan perintah berikut:

kubectl get services

Perintah ini akan menampilkan output yang mirip dengan berikut ini:

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

Mengonfigurasi resource `NodeSystemConfigUpdate`

Konfigurasi resource operator fungsi jaringan NodeSystemConfigUpdate untuk setiap node di cluster sebagai berikut.

Buat daftar node yang berjalan di node pool cluster target menggunakan perintah berikut:
```
kubectl get nodes | grep -v master
```
Perintah ini akan menampilkan output yang mirip dengan berikut ini:
```
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
```
Catat nama node yang ditampilkan dan dapatkan nama singkatnya. Misalnya, untuk node pool-example-node-1-01-b2d82cc7, nama singkatnya adalah node101.

Untuk setiap node yang telah Anda catat pada langkah sebelumnya, buat file resource NodeSystemConfigUpdate khusus dengan konten berikut:

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"

Ganti kode berikut:

NODE_NAME: nama lengkap node target. Misalnya, pool-example-node-1-01-b2d82cc7.
NODE_SHORT_NAME: nama singkat node target yang berasal dari nama lengkapnya. Misalnya, node101.

Beri nama setiap file node-system-config-update-NODE_SHORT_NAME.yaml.

Terapkan setiap file resource NodeSystemConfigUpdate ke cluster menggunakan perintah berikut:
```
kubectl apply -f node-system-config-update-NODE_SHORT_NAME.yaml
```
Ganti NODE_SHORT_NAME dengan nama singkat node target yang sesuai.

Saat Anda menerapkan resource ke cluster, setiap node yang terpengaruh akan dimulai ulang, yang dapat memerlukan waktu hingga 30 menit.
1. Pantau status node yang terpengaruh hingga semua node berhasil dimulai ulang:
```
kubectl get nodes | grep -v master
```
Status setiap node akan bertransisi dari not-ready ke ready saat proses memulai ulang selesai.

Mengonfigurasi Pod untuk caching image

Anda dapat mengonfigurasi Pod yang berjalan di cluster Distributed Cloud terhubung untuk melakukan caching image-nya. Pod mulai menggunakan image yang di-cache setelah diambil dari repositori untuk pertama kalinya. Jika node yang menghosting Pod kehabisan penyimpanan, image baru tidak akan di-cache dan cache image yang ada akan dihapus untuk memastikan workload Anda terus berjalan tanpa gangguan.

Konfigurasi Pod Anda harus memenuhi prasyarat berikut:

Anda harus menetapkan label gdce.baremetal.cluster.gke.io/cache-image: true pada Pod.
Jika Anda menggunakan repositori image pribadi, resource ImagePullSecret Anda harus berjenis kubernetes.io/dockerconfigjson.
Anda harus menetapkan kebijakan pull Pod ke IfNotPresent untuk memastikan salinan image target yang di-cache selalu digunakan. Jika salinan yang di-cache tidak tersedia secara lokal, image akan ditarik dari repositori.

Contoh berikut mengilustrasikan konfigurasi Pod dengan caching diaktifkan:

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

Contoh berikutnya mengilustrasikan konfigurasi Deployment dengan caching diaktifkan:

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

Batasan untuk workload Distributed Cloud

Saat mengonfigurasi workload Distributed Cloud terhubung, Anda harus mematuhi batasan yang dijelaskan di bagian ini. Batasan ini diterapkan oleh Distributed Cloud terhubung pada semua workload yang Anda deploy di hardware Distributed Cloud terhubung.

Batasan workload Linux

Distributed Cloud terhubung hanya mendukung kemampuan Linux berikut Linux untuk workload:

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

Pembatasan namespace

Distributed Cloud terhubung tidak mendukung namespace berikut:

hostPID
hostIPC
hostNetwork

Pembatasan jenis resource

Distributed Cloud terhubung tidak mendukung jenis resource CertificateSigningRequest, yang memungkinkan klien meminta penerbitan sertifikat X.509, berdasarkan permintaan penandatanganan.

Pembatasan konteks keamanan

Distributed Cloud terhubung tidak mendukung konteks keamanan mode istimewa.

Pembatasan binding Pod

Distributed Cloud terhubung tidak mendukung binding Pod ke port host di namespace HostNetwork. Selain itu, namespace HostNetwork tidak tersedia.

Pembatasan volume `hostPath`

Distributed Cloud terhubung hanya mengizinkan volume hostPath berikut dengan akses baca/tulis:

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

Pembatasan jenis resource `PersistentVolumeClaim`

Distributed Cloud terhubung hanya mengizinkan jenis resource PersistentVolumeClaim berikut:

csi
nfs
local

Pembatasan jenis volume

Distributed Cloud terhubung hanya mengizinkan jenis volume berikut:

configMap
csi
downwardAPI
emptyDir
hostPath
nfs
persistentVolumeClaim
projected
secret

Pembatasan toleransi Pod

Distributed Cloud terhubung tidak mengizinkan Pod yang dibuat pengguna di node bidang kontrol. Secara khusus, Distributed Cloud terhubung tidak mengizinkan penjadwalan Pod yang memiliki kunci toleransi berikut:

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

Pembatasan peniruan identitas

Distributed Cloud terhubung tidak mendukung peniruan identitas pengguna atau grup.

Pembatasan namespace pengelolaan

Distributed Cloud terhubung tidak mengizinkan akses ke namespace berikut:

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 kecuali untuk menghapus ippools.whereabouts.cni.cncf.io
metallb-system kecuali untuk mengedit resource configMap guna menetapkan rentang alamat IP load balancing
nf-operator
oclcm-system
prediction
rm-system
robinio
saas-system
vm-system

PROJECT_ID menunjukkan ID target Google Cloud project.

Hindari penggunaan namespace apa pun dengan awalan g- dalam namanya. Namespace tersebut biasanya merupakan namespace yang dicadangkan dan digunakan oleh Distributed Cloud terhubung.

Pembatasan webhook

Distributed Cloud terhubung membatasi webhook sebagai berikut:

Webhook yang bermutasi yang Anda buat akan otomatis mengecualikan namespace kube-system.
Webhook yang bermutasi dinonaktifkan untuk jenis resource berikut:
- nodes
- persistentvolumes
- certificatesigningrequests
- tokenreviews

Mengonfigurasi class runtime untuk Pod

Distributed Cloud terhubung memungkinkan Anda menentukan class runtime untuk Pod dalam konfigurasinya menggunakan kolom runtimeClassName. Tindakan ini akan mengganti class runtime default yang ditentukan di tingkat cluster. Class runtime yang tersedia adalah runc dan gvisor. Contoh:

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

Jika Anda menghilangkannya dalam konfigurasi Pod, Pod akan menggunakan class yang ditentukan di tingkat cluster. Class runtime tingkat cluster default adalah runc, kecuali jika Anda mengonfigurasi class runtime default menggunakan parameter --default-container-runtime seperti yang dijelaskan di bagian Membuat dan mengelola cluster.

Jika Anda mengubah class runtime di tingkat Pod atau cluster, Anda harus memulai ulang Pod yang terpengaruh agar perubahan diterapkan.

Class runtime `gvisor`

Menentukan class runtime gvisor akan mengalihkan Pod ke runtime aman Open Container Initiative (OCI) berdasarkan gVisor. gVisor adalah solusi sandbox yang memperkenalkan isolasi yang kuat antara workload dan host-nya.

Mengonfigurasi integrasi Kontrol Layanan VPC

Selesaikan langkah-langkah di bagian ini untuk mengonfigurasi integrasi Distributed Cloud Edge Container API dengan Kontrol Layanan VPC. Untuk mengetahui informasi selengkapnya, lihat referensi berikut:

Menentukan prioritas runtime untuk Pod

Distributed Cloud terhubung memungkinkan Anda menentukan class prioritas untuk Pod dalam konfigurasinya menggunakan kolom priorityClassName. Kolom ini menerima nama resource PriorityClass yang menentukan prioritas target. Contoh:

kind: PriorityClass
metadata:
  name: high-priority-class
value: 5100000
globalDefault: false
description: "High priority class for user workloads."

Tentukan nama class prioritas dalam konfigurasi Pod Anda seperti yang ditunjukkan dalam contoh berikut:

apiVersion: v1
kind: Pod
metadata:
  name: myPod
spec:
  priorityClassName: high-priority-class
  containers:
  - name: myPod
    image: myPodImage 
  restartPolicy: OnFailure

Menentukan class prioritas akan mengganti prioritas Pod default 0. Untuk workload penting, tetapkan prioritasnya ke nilai antara 5000001 dan 1000000000. Distributed Cloud terhubung akan otomatis menghentikan workload dengan prioritas yang lebih rendah.

Aturan egress yang diperlukan

Anda harus mengonfigurasi aturan egress yang dijelaskan di bagian ini untuk mengintegrasikan Distributed Cloud Edge Container API dengan Kontrol Layanan VPC. Untuk mengetahui informasi tentang sintaksis aturan egress, lihat Referensi aturan egress.

Akses ke zona mesin dan Google Cloud project

Aturan ini memungkinkan identitas panggilan mengakses zona mesin dan Google Cloud project saat melakukan panggilan menggunakan Distributed Cloud Edge Container API. Aturan ini berlaku saat mesin dan cluster tidak berada di project yang sama Google Cloud dan machine Google Cloud project berada di luar perimeter. Aturan ini diperlukan jika Anda telah membatasi Distributed Cloud Edge Container API di dalam perimeter menggunakan Kontrol Layanan VPC.

Berikut adalah contoh konfigurasi egressFrom untuk aturan ini dalam format JSON:

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

Berikut adalah contoh konfigurasi egressTo untuk aturan ini:

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

Aturan ingress yang diperlukan

Anda harus mengonfigurasi aturan ingress yang dijelaskan di bagian ini untuk mengintegrasikan Distributed Cloud Edge Container API dengan Kontrol Layanan VPC. Untuk mengetahui informasi tentang sintaksis aturan ingress, lihat Referensi aturan ingress.

Akses ke Distributed Cloud Edge Container API

Aturan ini memungkinkan identitas tertentu mengakses dan berinteraksi dengan Distributed Cloud Edge Container API. Anda harus mengonfigurasi aturan ini jika telah membatasi Distributed Cloud Edge Container API di dalam perimeter menggunakan Kontrol Layanan VPC dan identitas yang memanggil Distributed Cloud Edge Container API berada di luar perimeter.

Berikut adalah contoh konfigurasi ingressFrom untuk aturan ini:

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

Berikut adalah contoh konfigurasi ingressTo untuk aturan ini:

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

Akses ke Connect API dan Security Token Service API

Aturan ini memungkinkan workload mengakses Connect API dan Security Token Service API. Anda harus mengonfigurasi aturan ini jika telah membatasi akses ke Connect API dan Security Token Service API di dalam perimeter menggunakan Kontrol Layanan VPC. Untuk mengetahui informasi tentang cara menyiapkan kebijakan akses di tingkat alamat IP, lihat Alamat IP.