Men-deploy workload

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

Sebelum menyelesaikan langkah-langkah ini, Anda harus memenuhi persyaratan penginstalan yang terhubung ke Distributed Cloud 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 memesan Distributed Cloud terhubung.

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

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

Ringkasan deployment

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

  1. Opsional: Aktifkan Distributed Cloud Edge Network API.

  2. Opsional: Lakukan inisialisasi konfigurasi jaringan zona terhubung Distributed Cloud Anda.

  3. Opsional: Konfigurasi jaringan Distributed Cloud.

  4. Buat cluster yang terhubung ke Distributed Cloud.

  5. 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 beban kerja Anda. Untuk mengetahui informasi tentang cara Distributed Cloud terhubung mengenkripsi data workload, lihat Keamanan penyimpanan lokal.

  6. 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 frasa sandi Linux Unified Key Setup (LUKS) untuk mengenkripsi data workload.

  7. Dapatkan kredensial untuk cluster guna menguji cluster.

  8. Beri pengguna akses ke cluster dengan menetapkan peran Edge Container Viewer (roles/edgecontainer.viewer) atau peran Edge Container Admin (roles/edgecontainer.admin) pada project.

  9. Tetapkan akses berbasis peran terperinci kepada pengguna ke resource cluster menggunakan RoleBinding dan ClusterRoleBinding.

  10. Opsional: Aktifkan dukungan VM Runtime di Google Distributed Cloud untuk menjalankan workload di virtual machine di Distributed Cloud terhubung.

  11. 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 yang terhubung Distributed Cloud:

  1. 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

  2. Terapkan file YAML ke cluster menggunakan perintah berikut:

    kubectl apply -f nginx-deployment.yaml

  3. 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

  4. Terapkan file YAML ke cluster menggunakan perintah berikut:

    kubectl apply -f nginx-deployment.yaml

  5. 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.

  1. Cantumkan 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 pendeknya. Misalnya, untuk node pool-example-node-1-01-b2d82cc7, nama pendeknya adalah node101.

  2. Untuk setiap node yang telah Anda rekam di 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. Contoh, pool-example-node-1-01-b2d82cc7.
    • NODE_SHORT_NAME: nama singkat node target yang berasal dari nama lengkapnya. Contoh, node101.

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

  3. 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 pendek node target yang sesuai.

    Saat Anda menerapkan resource ke cluster, setiap node yang terpengaruh akan di-reboot, yang dapat memakan waktu hingga 30 menit.

    1. Pantau status node yang terpengaruh hingga semuanya berhasil di-reboot:
    kubectl get nodes | grep -v master

    Status setiap node bertransisi dari not-ready ke ready saat proses booting ulang selesai.

Mengonfigurasi Pod untuk caching gambar

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

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 menyetel kebijakan penarikan Pod ke IfNotPresent untuk memastikan salinan cache gambar target selalu digunakan. Jika salinan yang di-cache tidak tersedia secara lokal, image akan ditarik dari repositori.

Contoh berikut mengilustrasikan konfigurasi Pod dengan caching yang 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 yang 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 beban kerja yang terhubung ke Distributed Cloud, 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 Connected hanya mendukung kemampuan Linux berikut 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 yang terhubung tidak mendukung namespace berikut:

  • hostPID
  • hostIPC
  • hostNetwork

Pembatasan jenis resource

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

Batasan konteks keamanan

Distributed Cloud Connected tidak mendukung konteks keamanan mode istimewa.

Batasan pengikatan pod

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

hostPath pembatasan volume

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

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

Batasan jenis resource PersistentVolumeClaim

Distributed Cloud yang terhubung hanya mengizinkan jenis resource PersistentVolumeClaim berikut:

  • csi
  • nfs
  • local

Batasan jenis volume

Distributed Cloud yang terhubung hanya mengizinkan jenis volume berikut:

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

Batasan toleransi pod

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

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

Batasan peniruan identitas

Distributed Cloud connected tidak mendukung peniruan identitas pengguna atau grup.

Batasan namespace pengelolaan

Distributed Cloud connected 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 dengan pengecualian penghapusan ippools.whereabouts.cni.cncf.io
  • metallb-system, kecuali mengedit resource configMap untuk menetapkan rentang alamat IP load balancing
  • nf-operator
  • oclcm-system
  • prediction
  • rm-system
  • robinio
  • saas-system
  • vm-system

PROJECT_ID menunjukkan ID project Google Cloud target.

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

Pembatasan webhook

Distributed Cloud terhubung membatasi webhook sebagai berikut:

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

Batasan prioritas pod

Distributed Cloud yang terhubung mengharuskan Anda menetapkan prioritas Pod workload ke nilai yang lebih rendah dari 500000000.

Mengonfigurasi class runtime untuk Pod

Distributed Cloud Connected memungkinkan Anda menentukan class runtime untuk Pod dalam konfigurasinya menggunakan kolom runtimeClassName. Tindakan ini akan menggantikan 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 dalam 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.

Langkah berikutnya