Men-deploy aplikasi VM yang sangat tersedia

Halaman ini memberikan strategi deployment yang direkomendasikan untuk membangun aplikasi virtual machine (VM) yang andal dan memiliki ketersediaan tinggi (HA) di lingkungan air-gapped Google Distributed Cloud (GDC). Anda harus men-deploy aplikasi VM di beberapa zona GDC dan mengonfigurasi replikasi penyimpanan asinkron sehingga aplikasi dan datanya dapat dipulihkan jika terjadi periode nonaktif yang tidak terduga atau bencana lokal.

Halaman ini ditujukan bagi developer dalam grup operator aplikasi, yang bertanggung jawab membuat workload aplikasi untuk organisasi mereka. Untuk mengetahui informasi selengkapnya, lihat dokumentasi Audiens untuk GDC yang terisolasi dari internet.

Tujuan

  • Buat instance VM dengan boot disk terpasang di dua zona atau lebih di GDC universe Anda.
  • Konfigurasi load balancing global.
  • Mengonfigurasi replikasi penyimpanan asinkron menggunakan penyimpanan blok atau penyimpanan objek.

Sebelum memulai

  • Pastikan Anda bekerja di semesta GDC dengan beberapa zona tersedia. Jalankan gdcloud zones list untuk mencantumkan zona yang tersedia di semesta Anda. Untuk mengetahui informasi selengkapnya, lihat Mencantumkan zona di semesta.

  • Minta Admin IAM Organisasi Anda untuk memberi Anda peran berikut:

    • Peran VM untuk membuat dan mengelola workload VM.
    • Peran Load Balancer Admin (load-balancer-admin) dan Global Load Balancer Admin (global-load-balancer-admin). Anda harus memiliki peran ini untuk membuat dan mengelola load balancer.
    • Peran Admin Global Replikasi Volume (app-volume-replication-admin-global). Anda harus memiliki peran ini untuk mengelola replikasi volume.
    • Peran Global PNP Admin (global-project-networkpolicy-admin). Anda harus memiliki peran ini untuk membuat dan mengelola kebijakan jaringan project di seluruh zona.
    • Peran Admin Global Replikasi Volume (app-volume-replication-admin-global) untuk mengelola hubungan replikasi volume untuk resource penyimpanan blok.
    • Peran Project Bucket Object Admin (project-bucket-object-admin) dan Project Bucket Admin (project-bucket-admin) untuk membuat dan mengelola bucket penyimpanan.

    Lihat deskripsi peran untuk mengetahui informasi selengkapnya.

  • Instal dan konfigurasi gdcloud CLI, serta konfigurasi konteks zonal dan global Anda. Lihat Mengelola resource di seluruh zona untuk mengetahui informasi selengkapnya.

  • Instal dan konfigurasi kubectl CLI, dengan file kubeconfig yang sesuai ditetapkan untuk server API global dan server API Pengelolaan. Lihat Membuat file kubeconfig secara manual untuk mengetahui informasi selengkapnya.

Membuat instance VM di beberapa zona

Instance VM adalah resource zonal, jadi Anda harus membuat VM secara terpisah di setiap zona. Untuk contoh ini, Anda akan membuat instance VM menggunakan image OS yang disediakan GDC, dan memasang boot disk ke VM. Untuk mengetahui informasi selengkapnya tentang cara membuat instance VM, serta menggunakan image kustom, lihat Membuat dan memulai VM.

Secara default, semua project GDC dapat membuat VM dari image OS yang disediakan GDC.

Konsol

  1. Di menu navigasi, pilih Virtual Machines > Instances.
  2. Klik Create Instance.
  3. Di kolom Name, tentukan nama untuk VM.
  4. Pilih zona tempat VM akan dibuat.
  5. Klik Tambahkan Label untuk menetapkan label ke VM guna membantu mengatur instance VM Anda.
  6. Pilih konfigurasi mesin yang akan digunakan untuk VM. Pastikan jenis mesin sesuai dengan workload Anda, bergantung pada persyaratan Anda.
  7. Klik Berikutnya.
  8. Aktifkan akses eksternal untuk instance VM Anda.
  9. Klik Berikutnya.
  10. Pilih Tambahkan Disk Baru.
  11. Tetapkan nama untuk disk VM Anda.
  12. Konfigurasi ukuran disk dan setelan lampiran Anda.
  13. Klik Simpan.
  14. Klik Buat untuk membuat instance VM.
  15. Ulangi langkah-langkah sebelumnya untuk setiap zona di semesta GDC Anda. Pastikan instance VM berada di setiap zona yang Anda inginkan untuk strategi HA Anda.

gdcloud

  1. Login ke zona tempat Anda ingin menghosting instance VM:

    gdcloud config set core/zone ZONE

  2. Buat instance VM di zona menggunakan image yang disediakan GDC:

    gdcloud compute instances create VM_NAME \
    --machine-type=MACHINE_TYPE \
    --image=BOOT_DISK_IMAGE_NAME
    --image-project=vm-system \
    --boot-disk-size=BOOT_DISK_SIZE \
    --no-boot-disk-auto-delete=NO_BOOT_DISK_AUTO_DELETE

    Ganti kode berikut:

    • VM_NAME: nama VM baru. Nama hanya boleh berisi karakter alfanumerik dan tanda hubung, dan tidak boleh lebih dari 53 karakter.
    • MACHINE_TYPE: jenis mesin bawaan untuk VM baru. Untuk memilih jenis mesin yang tersedia, jalankan gdcloud compute machine-types list.
    • BOOT_DISK_IMAGE_NAME: nama image yang akan digunakan untuk boot disk VM baru.
    • BOOT_DISK_SIZE: ukuran boot disk, seperti 20GB. Nilai ini harus selalu lebih besar dari atau sama dengan minimumDiskSize image disk booting.
    • NO_BOOT_DISK_AUTO_DELETE: apakah disk boot dihapus secara otomatis saat instance VM dihapus.

  3. Ulangi langkah-langkah sebelumnya untuk setiap zona di semesta GDC Anda. Pastikan instance VM berada di setiap zona yang Anda inginkan untuk strategi HA Anda.

API

  1. Buat instance VM di zona menggunakan image yang disediakan GDC:

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineDisk
metadata:
  name: VM_BOOT_DISK_NAME
  namespace: PROJECT
spec:
  source:
    image:
      name: BOOT_DISK_IMAGE_NAME
      namespace: vm-system
  size: BOOT_DISK_SIZE
---
apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachine
metadata:
  name: VM_NAME
  namespace: PROJECT
spec:
  compute:
    virtualMachineType: MACHINE_TYPE
  disks:
    - virtualMachineDiskRef:
        name: VM_BOOT_DISK_NAME
      boot: true
      autoDelete: BOOT_DISK_AUTO_DELETE
---
apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineExternalAccess
metadata:
  name: VM_NAME
  namespace: PROJECT
spec:
  enabled: true
  ports:
  - name: port-80
    port: 80
    protocol: TCP
EOF

    Ganti kode berikut:

    • MANAGEMENT_API_SERVER: file kubeconfig server Management API untuk zona tempat membuat instance VM. Jika Anda belum membuat file kubeconfig untuk server Management API, lihat Membuat file kubeconfig secara manual untuk mengetahui detailnya.
    • VM_BOOT_DISK_NAME: nama disk boot VM baru.
    • PROJECT: project GDC tempat VM akan dibuat.
    • BOOT_DISK_IMAGE_NAME: nama image yang akan digunakan untuk boot disk VM baru.
    • BOOT_DISK_SIZE: ukuran boot disk, seperti 20Gi. Nilai ini harus selalu lebih besar dari atau sama dengan minimumDiskSize image disk booting.
    • VM_NAME: nama VM baru. Nama hanya boleh berisi karakter alfanumerik dan tanda hubung, dan tidak boleh lebih dari 53 karakter.
    • MACHINE_TYPE: jenis mesin bawaan untuk VM baru. Untuk memilih jenis mesin yang tersedia, jalankan gdcloud compute machine-types list.
    • BOOT_DISK_AUTO_DELETE: apakah boot disk dihapus secara otomatis saat instance VM dihapus.

  2. Pastikan VM tersedia dan tunggu hingga VM menampilkan status Running. Status Running tidak menunjukkan bahwa OS sudah sepenuhnya siap dan dapat diakses.

    kubectl --kubeconfig MANAGEMENT_API_SERVER \
    get virtualmachine.virtualmachine.gdc.goog VM_NAME -n PROJECT

    Ganti VM_NAME dan PROJECT dengan nama dan project VM.

  3. Ulangi langkah-langkah sebelumnya untuk setiap zona di semesta GDC Anda. Pastikan instance VM berada di setiap zona yang Anda inginkan untuk strategi HA Anda.

Mengonfigurasi load balancer

Untuk mendistribusikan traffic antara VM Anda di zona yang berbeda, buat load balancer. Anda memiliki opsi untuk membuat load balancer eksternal (ELB) dan load balancer internal (ILB), yang keduanya dapat dikonfigurasi secara per zona atau global. Untuk contoh ini, konfigurasi ILB global dan ELB global untuk aplikasi VM Anda.

Membuat load balancer internal global

Load balancer internal (ILB) mengekspos layanan dalam organisasi dari kumpulan alamat IP internal yang ditetapkan ke organisasi. Layanan ILB tidak pernah dapat diakses dari endpoint di luar organisasi.

Selesaikan langkah-langkah berikut untuk membuat ILB global bagi workload VM Anda.

gdcloud

Buat ILB yang menargetkan beban kerja VM menggunakan gcloud CLI.

ILB ini menargetkan semua workload dalam project yang cocok dengan label yang ditentukan dalam objek Backend. Resource kustom Backend harus ditetapkan cakupannya ke zona.

Untuk membuat ILB menggunakan gdcloud CLI, ikuti langkah-langkah berikut:

  1. Buat resource Backend zona di setiap zona tempat VM Anda berjalan untuk menentukan endpoint ILB:

    gdcloud compute backends create BACKEND_NAME \
    --labels=LABELS \
    --project=PROJECT \
    --zone=ZONE

    Ganti kode berikut:

    • BACKEND_NAME: nama yang dipilih untuk resource backend, seperti my-backend.
    • LABELS: pemilih yang menentukan endpoint mana antar-VM yang akan digunakan untuk resource backend ini, seperti app=web.
    • PROJECT: nama project Anda.
    • ZONE: zona yang akan digunakan untuk pemanggilan ini. Untuk menyetel sebelumnya tanda zona untuk semua perintah yang memerlukannya, jalankan gdcloud config set core/zone ZONE. Flag zona hanya tersedia di lingkungan multi-zona. Kolom ini bersifat opsional.

    Ulangi langkah ini untuk setiap zona di semesta GDC Anda.

  2. Tentukan health check global untuk ILB:

    gdcloud compute health-checks create tcp HEALTH_CHECK_NAME \
    --check-interval=CHECK_INTERVAL \
    --healthy-threshold=HEALTHY_THRESHOLD \
    --timeout=TIMEOUT \
    --unhealthy-threshold=UNHEALTHY_THRESHOLD \
    --port=PORT \
    --global

    Ganti kode berikut:

    • HEALTH_CHECK_NAME: nama untuk resource pemeriksaan kondisi, seperti my-health-check.
    • CHECK_INTERVAL: jumlah waktu dalam detik dari awal satu pemeriksaan hingga awal pemeriksaan berikutnya. Nilai defaultnya adalah 5. Kolom ini bersifat opsional.
    • HEALTHY_THRESHOLD: waktu untuk menunggu sebelum mengklaim kegagalan. Nilai defaultnya adalah 5. Kolom ini bersifat opsional.
    • TIMEOUT: jumlah waktu dalam detik untuk menunggu sebelum menyatakan kegagalan. Nilai defaultnya adalah 5. Kolom ini bersifat opsional.
    • UNHEALTHY_THRESHOLD: jumlah pemeriksaan berurutan yang harus gagal agar endpoint dianggap tidak responsif. Nilai defaultnya adalah 2. Kolom ini bersifat opsional.
    • PORT: port tempat health check dilakukan. Nilai defaultnya adalah 80. Kolom ini bersifat opsional.

  3. Buat resource BackendService global:

    gdcloud compute backend-services create BACKEND_SERVICE_NAME \
    --project=PROJECT \
    --target-ports=TARGET_PORTS \
    --health-check=HEALTH_CHECK_NAME \
    --global

    Ganti kode berikut:

    • BACKEND_SERVICE_NAME: nama untuk layanan backend.
    • PROJECT: nama project Anda.
    • TARGET_PORTS: daftar port target yang dipisahkan koma yang diterjemahkan oleh layanan backend ini, dengan setiap port target menentukan protokol, port pada aturan penerusan, dan port pada instance backend. Anda dapat menentukan beberapa port target. Kolom ini harus dalam format protocol:port:targetport, seperti TCP:80:8080. Kolom ini bersifat opsional.
    • HEALTH_CHECK_NAME: nama resource health check. Kolom ini bersifat opsional.

  4. Tambahkan resource BackendService ke resource Backend yang dibuat sebelumnya di setiap zona:

    gdcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
    --backend-zone=ZONE \
    --backend=BACKEND_NAME \
    --project=PROJECT \
    --global

    Ganti kode berikut:

    • BACKEND_SERVICE_NAME: nama layanan backend global.
    • ZONE: zona backend.
    • BACKEND_NAME: nama backend zona.
    • PROJECT: nama project Anda.

    Selesaikan langkah ini untuk setiap backend zonal yang Anda buat sebelumnya.

  5. Buat resource ForwardingRule internal yang menentukan alamat IP virtual (VIP) tempat layanan tersedia:

    gdcloud compute forwarding-rules create FORWARDING_RULE_INTERNAL_NAME \
    --backend-service=BACKEND_SERVICE_NAME \
    --cidr=CIDR \
    --ip-protocol-port=PROTOCOL_PORT \
    --load-balancing-scheme=INTERNAL \
    --project=PROJECT \
    --global

    Ganti kode berikut:

    • FORWARDING_RULE_INTERNAL_NAME: nama untuk aturan penerusan.
    • CIDR: CIDR yang akan digunakan untuk aturan penerusan. Kolom ini bersifat opsional. Jika tidak ditentukan, CIDR IPv4/32 akan otomatis dicadangkan dari kumpulan alamat IP global. Tentukan nama resource Subnet dalam namespace yang sama dengan aturan penerusan ini. Resource Subnet merepresentasikan informasi permintaan dan alokasi subnet global. Untuk mengetahui informasi selengkapnya tentang resource Subnet, lihat Mengelola subnet.
    • PROTOCOL_PORT: protokol dan port yang akan diekspos pada aturan penerusan. Kolom ini harus dalam format ip-protocol=TCP:80. Port yang diekspos harus sama dengan port yang diekspos oleh aplikasi sebenarnya di dalam VM.

  6. Untuk memvalidasi ILB yang dikonfigurasi, konfirmasi kondisi Ready pada setiap objek yang dibuat. Verifikasi traffic dengan permintaan curl ke VIP:

    1. Untuk mendapatkan VIP yang ditetapkan, jelaskan aturan penerusan:

      gdcloud compute forwarding-rules describe FORWARDING_RULE_INTERNAL_NAME --global

    2. Verifikasi traffic dengan permintaan curl ke VIP di port yang ditentukan dalam kolom di aturan penerusan:

      curl http://FORWARDING_RULE_VIP:PORT

    Ganti kode berikut:

    • FORWARDING_RULE_VIP: VIP aturan penerusan.
    • PORT: nomor port aturan penerusan.

API

Buat ILB yang menargetkan beban kerja VM menggunakan KRM API. ILB ini menargetkan semua beban kerja dalam project yang cocok dengan label yang ditentukan dalam objek Backend. Untuk membuat ILB global menggunakan KRM API, ikuti langkah-langkah berikut:

  1. Buat resource Backend untuk menentukan endpoint ILB. Buat resource Backend untuk setiap zona tempat workload VM ditempatkan:

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: Backend
metadata:
  namespace: PROJECT
  name: BACKEND_NAME
spec:
  endpointsLabels:
    matchLabels:
      app: APP_NAME
EOF

    Ganti kode berikut:

    • MANAGEMENT_API_SERVER: jalur kubeconfig server Management API zonal. Untuk mengetahui informasi selengkapnya, lihat Beralih ke konteks zona.
    • PROJECT: nama project Anda.
    • BACKEND_NAME: nama resource Backend.
    • APP_NAME: nama aplikasi VM Anda.

    Anda dapat menggunakan resource Backend yang sama untuk setiap zona, atau membuat resource Backend dengan kumpulan label yang berbeda untuk setiap zona.

  2. Tentukan health check global untuk ILB:

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: HealthCheck
metadata:
  namespace: PROJECT
  name: HEALTH_CHECK_NAME
spec:
  tcpHealthCheck:
    port: PORT
  timeoutSec: TIMEOUT
  checkIntervalSec: CHECK_INTERVAL
  healthyThreshold: HEALTHY_THRESHOLD
  unhealthyThreshold: UNHEALTHY_THRESHOLD
EOF

    Ganti kode berikut:

    • GLOBAL_API_SERVER: jalur kubeconfig server API global. Untuk mengetahui informasi selengkapnya, lihat Beralih ke konteks global.
    • PROJECT: nama project Anda.
    • HEALTH_CHECK_NAME: nama resource pemeriksaan kondisi, seperti my-health-check.
    • PORT: port tempat health check dilakukan. Nilai defaultnya adalah 80.
    • TIMEOUT: jumlah waktu dalam detik untuk menunggu sebelum menyatakan kegagalan. Nilai defaultnya adalah 5.
    • CHECK_INTERVAL: jumlah waktu dalam detik dari awal satu pemeriksaan hingga awal pemeriksaan berikutnya. Nilai defaultnya adalah 5.
    • HEALTHY_THRESHOLD: jumlah pemeriksaan berurutan yang harus berhasil agar endpoint dianggap responsif. Nilai defaultnya adalah 2.
    • UNHEALTHY_THRESHOLD: jumlah pemeriksaan berurutan yang harus gagal agar endpoint dianggap tidak responsif. Nilai defaultnya adalah 2.

  3. Buat objek BackendService menggunakan resource Backend yang dibuat sebelumnya. Pastikan untuk menyertakan resource HealthCheck:

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: BackendService
metadata:
  namespace: PROJECT
  name: BACKEND_SERVICE_NAME
spec:
  backendRefs:
  - name: BACKEND_NAME
    zone: ZONE
  healthCheckName: HEALTH_CHECK_NAME
  targetPorts:
  - port: PORT
    protocol: PROTOCOL
    targetPort: TARGET_PORT
EOF

    Ganti kode berikut:

    • GLOBAL_API_SERVER: jalur kubeconfig dari jalur kubeconfig server API global.
    • PROJECT: nama project Anda.
    • BACKEND_SERVICE_NAME: nama yang dipilih untuk resource BackendService.
    • HEALTH_CHECK_NAME: nama resource HealthCheck yang Anda buat sebelumnya.
    • BACKEND_NAME: nama resource Backend zonal.

    • ZONE: zona tempat resource Backend berada. Anda dapat menentukan beberapa backend di kolom backendRefs. Misalnya:

      - name: my-backend-1
  zone: us-east1-a
- name: my-backend-2
  zone: us-east1-b

      Kolom targetPorts bersifat opsional. Resource ini mencantumkan port yang diterjemahkan oleh resource BackendService ini. Jika Anda menggunakan objek ini, berikan nilai untuk berikut ini:

    • PORT: port yang diekspos oleh layanan.

    • PROTOCOL: protokol Layer-4 yang harus cocok dengan traffic. Hanya TCP dan UDP yang didukung.

    • TARGET_PORT: port yang menjadi tujuan terjemahan nilai, seperti 8080. Nilai tidak boleh diulang dalam objek tertentu.

      Contoh untuk targetPorts mungkin terlihat seperti berikut:

      targetPorts:
  - port: 80
    protocol: TCP
    targetPort: 8080

  4. Buat resource ForwardingRule internal yang menentukan alamat IP virtual (VIP) tempat layanan tersedia.

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ForwardingRuleInternal
metadata:
  namespace: PROJECT
  name: FORWARDING_RULE_INTERNAL_NAME
spec:
  cidrRef: CIDR
  ports:
  - port: PORT
    protocol: PROTOCOL
  backendServiceRef:
    name: BACKEND_SERVICE_NAME
EOF

    Ganti kode berikut:

    • GLOBAL_API_SERVER: jalur kubeconfig dari jalur kubeconfig server API global.
    • PROJECT: nama project Anda.
    • FORWARDING_RULE_INTERNAL_NAME: nama yang dipilih untuk resource ForwardingRuleInternal Anda.
    • CIDR: CIDR yang akan digunakan untuk aturan penerusan. Kolom ini bersifat opsional. Jika tidak ditentukan, CIDR IPv4/32 akan otomatis dicadangkan dari kumpulan alamat IP global. Tentukan nama resource Subnet dalam namespace yang sama dengan aturan penerusan ini. Resource Subnet merepresentasikan informasi permintaan dan alokasi subnet global. Untuk mengetahui informasi selengkapnya tentang resource Subnet, lihat Mengelola subnet.
    • PORT: port yang akan diekspos pada aturan penerusan. Gunakan kolom ports untuk menentukan array port L4 yang paketnya diteruskan ke backend yang dikonfigurasi dengan aturan penerusan ini. Setidaknya satu port harus ditentukan. Gunakan kolom port untuk menentukan nomor port. Port yang diekspos harus sama dengan port yang diekspos oleh aplikasi sebenarnya di dalam container.

    • PROTOCOL: protokol yang akan digunakan untuk aturan penerusan, seperti TCP. Entri dalam array ports harus terlihat seperti berikut:

      ports:
- port: 80
  protocol: TCP

  5. Untuk memvalidasi ILB yang dikonfigurasi, konfirmasi kondisi Ready pada setiap objek yang dibuat. Verifikasi traffic dengan permintaan curl ke VIP:

    1. Ambil VIP:

      kubectl get forwardingruleinternal -n PROJECT

      Outputnya akan terlihat seperti berikut:

      NAME           BACKENDSERVICE                  CIDR              READY
ilb-name       BACKEND_SERVICE_NAME            192.0.2.0/32      True

    2. Uji traffic dengan permintaan curl ke VIP di port yang ditentukan di kolom dalam aturan penerusan:

      curl http://FORWARDING_RULE_VIP:PORT

      Ganti kode berikut:

      • FORWARDING_RULE_VIP: VIP aturan penerusan.
      • PORT: nomor port kolom dalam aturan penerusan.

Membuat load balancer eksternal global

Load balancer eksternal (ELB) mengekspos layanan untuk diakses dari luar organisasi dari kumpulan alamat IP yang ditetapkan ke organisasi dari kumpulan alamat IP eksternal instance yang lebih besar.

Selesaikan langkah-langkah berikut untuk membuat ELB global bagi workload VM Anda.

gdcloud

Gunakan gdcloud CLI untuk membuat ELB global yang menargetkan semua beban kerja dalam project yang cocok dengan label yang ditentukan dalam objek Backend. Resource kustom Backend harus memiliki cakupan zona.

  1. Agar layanan ELB berfungsi, Anda harus mengonfigurasi dan menerapkan kebijakan transfer data ProjectNetworkPolicy yang disesuaikan sendiri untuk mengizinkan traffic ke beban kerja layanan ELB ini. Kebijakan jaringan mengontrol akses ke beban kerja Anda, bukan load balancer itu sendiri. ELB mengekspos workload ke jaringan pelanggan Anda, sehingga memerlukan kebijakan jaringan eksplisit untuk mengizinkan traffic eksternal ke port workload, seperti 8080.

    Tentukan alamat CIDR eksternal untuk mengizinkan traffic ke beban kerja ELB ini:

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT
  name: allow-inbound-traffic-from-external
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
  ingress:
  - from:
    - ipBlock:
        cidr: CIDR
    ports:
    - protocol: TCP
      port: PORT
EOF

    Ganti kode berikut:

    • GLOBAL_API_SERVER: jalur kubeconfig server API global. Jika Anda belum membuat file kubeconfig untuk server API global, lihat Membuat file kubeconfig secara manual untuk mengetahui detailnya.
    • PROJECT: nama project Anda.
    • CIDR: CIDR eksternal yang diperlukan ELB untuk diakses. Kebijakan ini diperlukan karena load balancer eksternal menggunakan Direct Server Return (DSR), yang mempertahankan alamat IP eksternal sumber dan melewati load balancer di jalur kembali. Untuk mengetahui informasi selengkapnya, lihat Membuat aturan firewall ingress global untuk traffic lintas organisasi.
    • PORT: port backend di VM di belakang load balancer. Nilai ini dapat ditemukan di kolom .spec.ports[].targetPortfield manifes untuk resource Service. Kolom ini bersifat opsional.

    Konfigurasi ini memberikan akses semua resource di dalam project ke rentang CIDR yang ditentukan.

  2. Buat resource Backend di setiap zona untuk menentukan endpoint bagi ELB:

    gdcloud compute backends create BACKEND_NAME \
  --labels=LABELS \
  --project=PROJECT

    Ganti kode berikut:

    • BACKEND_NAME: nama untuk resource backend, seperti my-backend.
    • LABELS: pemilih yang menentukan endpoint antar-VM yang akan digunakan untuk resource backend ini, seperti app=web.
    • PROJECT: nama project Anda.

    Anda dapat menggunakan resource Backend yang sama untuk setiap zona, atau membuat resource Backend dengan kumpulan label yang berbeda untuk setiap zona.

  3. Tentukan health check global untuk ELB:

    gdcloud compute health-checks create tcp HEALTH_CHECK_NAME \
  --check-interval=CHECK_INTERVAL \
  --healthy-threshold=HEALTHY_THRESHOLD \
  --timeout=TIMEOUT \
  --unhealthy-threshold=UNHEALTHY_THRESHOLD \
  --port=PORT \
  --global

    Ganti kode berikut:

    • HEALTH_CHECK_NAME: nama untuk resource pemeriksaan kesehatan, seperti my-health-check.
    • CHECK_INTERVAL: jumlah waktu dalam detik dari awal satu pemeriksaan hingga awal pemeriksaan berikutnya. Nilai defaultnya adalah 5. Kolom ini bersifat opsional.
    • HEALTHY_THRESHOLD: waktu untuk menunggu sebelum mengklaim kegagalan. Nilai defaultnya adalah 5. Kolom ini bersifat opsional.
    • TIMEOUT: jumlah waktu dalam detik untuk menunggu sebelum mengklaim kegagalan. Nilai defaultnya adalah 5. Kolom ini bersifat opsional.
    • UNHEALTHY_THRESHOLD: jumlah pemeriksaan berurutan yang harus gagal agar endpoint dianggap tidak responsif. Nilai defaultnya adalah 2. Kolom ini bersifat opsional.
    • PORT: port tempat health check akan dilakukan. Nilai defaultnya adalah 80. Kolom ini bersifat opsional.

  4. Buat resource BackendService global:

    gdcloud compute backend-services create BACKEND_SERVICE_NAME \
  --project=PROJECT \
  --target-ports=TARGET_PORTS \
  --health-check=HEALTH_CHECK_NAME \
  --global

    Ganti kode berikut:

    • BACKEND_SERVICE_NAME: nama yang dipilih untuk layanan backend ini.
    • PROJECT: nama project Anda.
    • TARGET_PORTS: daftar port target yang dipisahkan koma yang diterjemahkan oleh layanan backend ini, dengan setiap port target menentukan protokol, port pada aturan penerusan, dan port pada instance backend. Anda dapat menentukan beberapa port target. Kolom ini harus dalam format protocol:port:targetport, seperti TCP:80:8080. Kolom ini bersifat opsional.
    • HEALTH_CHECK_NAME: nama resource health check. Kolom ini bersifat opsional.

  5. Tambahkan resource BackendService global ke resource Backend zonal yang dibuat sebelumnya:

    gdcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --backend=BACKEND_NAME \
  --backend-zone BACKEND_ZONE \
  --project=PROJECT \
  --global

    Selesaikan langkah ini untuk setiap backend zonal yang Anda buat sebelumnya.

  6. Buat resource ForwardingRule eksternal yang menentukan VIP tempat layanan tersedia:

    gdcloud compute forwarding-rules create FORWARDING_RULE_EXTERNAL_NAME \
  --backend-service=BACKEND_SERVICE_NAME \
  --cidr=CIDR \
  --ip-protocol-port=PROTOCOL_PORT \
  --load-balancing-scheme=EXTERNAL \
  --project=PROJECT \
  --global

    Ganti kode berikut:

    • FORWARDING_RULE_EXTERNAL_NAME: nama untuk aturan penerusan.
    • CIDR: CIDR yang akan digunakan untuk aturan penerusan. Kolom ini bersifat opsional. Jika tidak ditentukan, CIDR IPv4/32 akan otomatis dicadangkan dari kumpulan alamat IP global. Tentukan nama resource Subnet dalam namespace yang sama dengan aturan penerusan ini. Resource Subnet merepresentasikan informasi permintaan dan alokasi subnet global. Untuk mengetahui informasi selengkapnya tentang resource Subnet, lihat Mengelola subnet.
    • PROTOCOL_PORT: protokol dan port yang akan diekspos pada aturan penerusan. Kolom ini harus dalam format ip-protocol=TCP:80. Port yang diekspos harus sama dengan yang diekspos aplikasi sebenarnya di dalam VM.
    • PROJECT: nama project Anda.

  7. Untuk memvalidasi ELB yang dikonfigurasi, konfirmasi kondisi Ready pada setiap objek yang dibuat. Verifikasi traffic dengan permintaan curl ke VIP:

    1. Untuk mendapatkan VIP yang ditetapkan, jelaskan aturan penerusan:

      gdcloud compute forwarding-rules describe FORWARDING_RULE_EXTERNAL_NAME

    2. Verifikasi traffic dengan permintaan curl ke VIP di port yang ditentukan di kolom PROTOCOL_PORT dalam aturan penerusan:

      curl http://FORWARDING_RULE_VIP:PORT

      Ganti kode berikut:

      • FORWARDING_RULE_VIP: VIP aturan penerusan.
      • PORT: nomor port dari kolom PROTOCOL_PORT dalam aturan penerusan.

API

Buat ELB yang menargetkan beban kerja VM menggunakan KRM API. ELB ini menargetkan semua workload dalam project yang cocok dengan label yang ditentukan dalam objek Backend. Untuk membuat ELB zona menggunakan KRM API, ikuti langkah-langkah berikut:

  1. Agar layanan ELB berfungsi, Anda harus mengonfigurasi dan menerapkan kebijakan transfer data ProjectNetworkPolicy yang disesuaikan sendiri untuk mengizinkan traffic ke beban kerja layanan ELB ini. Kebijakan jaringan mengontrol akses ke beban kerja Anda, bukan load balancer itu sendiri. ELB mengekspos workload ke jaringan pelanggan Anda, sehingga memerlukan kebijakan jaringan eksplisit untuk mengizinkan traffic eksternal ke port workload, seperti 8080.

    Tentukan alamat CIDR eksternal untuk mengizinkan traffic ke beban kerja ELB ini:

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT
  name: allow-inbound-traffic-from-external
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
  ingress:
  - from:
    - ipBlock:
        cidr: CIDR
    ports:
    - protocol: TCP
      port: PORT
EOF

    Ganti kode berikut:

    • GLOBAL_API_SERVER: jalur kubeconfig server API global. Jika Anda belum membuat file kubeconfig untuk server API global, lihat Membuat file kubeconfig secara manual untuk mengetahui detailnya.
    • PROJECT: nama project Anda.
    • CIDR: CIDR eksternal yang diperlukan ELB untuk diakses. Kebijakan ini diperlukan karena load balancer eksternal menggunakan Direct Server Return (DSR), yang mempertahankan alamat IP eksternal sumber dan melewati load balancer di jalur kembali. Untuk mengetahui informasi selengkapnya, lihat Membuat aturan firewall ingress global untuk traffic lintas organisasi.
    • PORT: port backend di VM di belakang load balancer. Nilai ini dapat ditemukan di kolom .spec.ports[].targetPortfield manifes untuk resource Service. Kolom ini bersifat opsional.

  2. Buat resource Backend untuk menentukan endpoint bagi ELB. Buat resource Backend untuk setiap zona tempat workload ditempatkan:

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: Backend
metadata:
  namespace: PROJECT
  name: BACKEND_NAME
spec:
  endpointsLabels:
    matchLabels:
      app: server
EOF

    Ganti kode berikut:

    • MANAGEMENT_API_SERVER: jalur kubeconfig server Management API zonal. Jika Anda belum membuat file kubeconfig untuk server API di zona target, lihat Membuat file kubeconfig secara manual untuk mengetahui detailnya.
    • PROJECT: nama project Anda.
    • BACKEND_NAME: nama resource Backend.

    Anda dapat menggunakan resource Backend yang sama untuk setiap zona, atau membuat resource Backend dengan kumpulan label yang berbeda untuk setiap zona.

  3. Tentukan health check global untuk ELB:

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: HealthCheck
metadata:
  namespace: PROJECT
  name: HEALTH_CHECK_NAME
spec:
  tcpHealthCheck:
    port: PORT
  timeoutSec: TIMEOUT
  checkIntervalSec: CHECK_INTERVAL
  healthyThreshold: HEALTHY_THRESHOLD
  unhealthyThreshold: UNHEALTHY_THRESHOLD
EOF

    Ganti kode berikut:

    • HEALTH_CHECK_NAME: nama untuk resource pemeriksaan kesehatan, seperti my-health-check.
    • PORT: port tempat health check akan dilakukan. Nilai defaultnya adalah 80.
    • TIMEOUT: jumlah waktu dalam detik untuk menunggu sebelum mengklaim kegagalan. Nilai defaultnya adalah 5.
    • CHECK_INTERVAL: jumlah waktu dalam detik dari awal satu pemeriksaan hingga awal pemeriksaan berikutnya. Nilai defaultnya adalah 5.
    • HEALTHY_THRESHOLD: jumlah pemeriksaan berurutan yang harus berhasil agar endpoint dianggap responsif. Nilai defaultnya adalah 2.
    • UNHEALTHY_THRESHOLD: jumlah pemeriksaan berurutan yang harus gagal agar endpoint dianggap tidak responsif. Nilai defaultnya adalah 2.

    Karena ini adalah ELB global, buat health check di API global.

  4. Buat objek BackendService menggunakan resource Backend yang dibuat sebelumnya:

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: BackendService
metadata:
  namespace: PROJECT
  name: BACKEND_SERVICE_NAME
spec:
  backendRefs:
  - name: BACKEND_NAME
    zone: ZONE
  healthCheckName: HEALTH_CHECK_NAME
EOF

    Ganti kode berikut:

    • BACKEND_SERVICE_NAME: nama yang dipilih untuk resource BackendService.
    • HEALTH_CHECK_NAME: nama resource HealthCheck yang Anda buat sebelumnya. Jangan sertakan kolom ini jika Anda mengonfigurasi ELB untuk workload pod.
    • ZONE: zona tempat resource Backend berada. Anda dapat menentukan beberapa backend di kolom backendRefs. Misalnya:
    - name: my-backend-1
  zone: us-east1-a
- name: my-backend-2
  zone: us-east1-b

  5. Buat resource ForwardingRule eksternal yang menentukan VIP tempat layanan tersedia.

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ForwardingRuleExternal
metadata:
  namespace: PROJECT
  name: FORWARDING_RULE_EXTERNAL_NAME
spec:
  cidrRef: CIDR
  ports:
  - port: PORT
    protocol: PROTOCOL
  backendServiceRef:
    name: BACKEND_SERVICE_NAME
EOF

    Ganti kode berikut:

    • FORWARDING_RULE_EXTERNAL_NAME: nama yang dipilih untuk resource ForwardingRuleExternal.
    • CIDR: CIDR yang akan digunakan untuk aturan penerusan. Kolom ini bersifat opsional. Jika tidak ditentukan, CIDR IPv4/32 akan otomatis dicadangkan dari kumpulan alamat IP global. Tentukan nama resource Subnet dalam namespace yang sama dengan aturan penerusan ini. Resource Subnet merepresentasikan informasi permintaan dan alokasi subnet global. Untuk mengetahui informasi selengkapnya tentang resource Subnet, lihat Mengelola subnet.
    • PORT: port yang akan diekspos pada aturan penerusan. Gunakan kolom ports untuk menentukan array port L4 yang paketnya diteruskan ke backend yang dikonfigurasi dengan aturan penerusan ini. Setidaknya satu port harus ditentukan. Gunakan kolom port untuk menentukan nomor port. Port yang diekspos harus sama dengan yang diekspos oleh aplikasi sebenarnya di dalam container.
    • PROTOCOL: protokol yang akan digunakan untuk aturan penerusan, seperti TCP. Entri dalam array ports harus terlihat seperti berikut:
    ports:
- port: 80
  protocol: TCP

  6. Untuk memvalidasi ELB yang dikonfigurasi, konfirmasi kondisi Ready pada setiap objek yang dibuat. Coba dan uji traffic dengan permintaan curl ke VIP.

    1. Ambil VIP untuk project:

      kubectl get forwardingruleexternal -n PROJECT

      Outputnya akan terlihat seperti berikut:

      NAME           BACKENDSERVICE                  CIDR              READY
elb-name       BACKEND_SERVICE_NAME            192.0.2.0/32      True

    2. Verifikasi traffic dengan permintaan curl ke VIP di port yang ditentukan di kolom PORT dalam aturan penerusan:

      curl http://FORWARDING_RULE_VIP:PORT

      Ganti FORWARDING_RULE_VIP:PORT dengan VIP dan port aturan penerusan, seperti 192.0.2.0:80.

Mengonfigurasi replikasi penyimpanan asinkron

Universe multi-zona GDC menawarkan penggunaan resource penyimpanan yang direplikasi seperti volume dan bucket dalam mode asinkron untuk skenario pemulihan dari bencana. Opsi resource penyimpanan ini menyediakan replikasi data asinkron antara dua zona mana pun di region yang sama. Replikasi asinkron terjadi di latar belakang, sehingga memberikan tujuan titik pemulihan (RPO) yang rendah, tetapi tidak nol, jika terjadi bencana. Semua data yang direplikasi bersifat online dan dapat diakses langsung, tetapi mungkin memerlukan prosedur failover manual untuk mengaktifkan penulisan di zona sekunder.

Anda dapat memilih salah satu jenis replikasi penyimpanan asinkron berikut untuk aplikasi VM Anda:

Membuat bucket zona ganda untuk penyimpanan objek

Data penyimpanan objek ditulis ke satu bucket yang datanya disimpan di kedua zona. Karena data disalin secara asinkron di seluruh zona, zona mungkin tidak berisi versi objek yang sama pada waktu tertentu, tetapi pada akhirnya akan menjadi setara jika tidak ada perubahan tambahan yang dilakukan. Tidak seperti replikasi volume, bucket yang direplikasi dapat ditulis selama partisi zona. Setiap penulisan ke objek menghasilkan versi yang berbeda, dan versi terbaru di kedua zona akan menjadi status akhir setelah konektivitas dipulihkan.

  1. Pastikan Operator Infrastruktur (IO) Anda telah membuat resource kustom BucketLocationConfig, yang diperlukan untuk replikasi asinkron di seluruh zona untuk penyimpanan objek. Resource ini harus di-deploy ke server API global root.

  2. Buat resource kustom Bucket zona ganda:

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: object.global.gdc.goog/v1
kind: Bucket
metadata:
  name: BUCKET_NAME
  namespace: PROJECT
spec:
  location: LOCATION_NAME
  description: Sample DZ Bucket
  storageClass: Standard
EOF

    Ganti kode berikut:

    • GLOBAL_API_SERVER: file kubeconfig untuk server API global.
    • BUCKET_NAME: nama bucket penyimpanan.
    • PROJECT: nama project tempat bucket berada.
    • LOCATION_NAME: tempat fisik tempat data objek dalam bucket berada. Atribut ini harus dipetakan ke nama resource BucketLocation yang ada. Untuk mengkueri server API global organisasi Anda guna mendapatkan daftar resource BucketLocation yang tersedia, jalankan kubectl --kubeconfig GLOBAL_API_SERVER bucketlocations. Jika tidak ada resource BucketLocation, hubungi IO Anda untuk memverifikasi bahwa mereka telah mengaktifkan replikasi asinkron.

Mengonfigurasi replikasi block storage asinkron di seluruh zona

Penyimpanan blok yang direplikasi menyediakan volume (PV) yang direplikasi secara asinkron, yang mempertahankan kesetaraan blok antara volume utama dan sekunder. Karena sifat asinkron, volume sekunder mencerminkan status zona primer pada suatu waktu di masa lalu (RPO bukan nol). Volume sekunder tidak dapat di-mount selama volume tersebut tetap menjadi target replikasi, sehingga memerlukan intervensi manual untuk mengakhiri hubungan dan memungkinkan penulisan terjadi.

Anda harus men-deploy resource kustom VolumeReplicationRelationship ke server API global untuk membuat data yang direplikasi yang tersedia untuk failover jika data zona sumber menjadi tidak tersedia.

Sebelum memulai, pastikan Operator Infrastruktur (IO) Anda telah membuat dan mengonfigurasi resource kustom StorageClusterPeering dan StorageVirtualMachinePeering untuk memungkinkan replikasi penyimpanan blok di seluruh zona. Resource ini harus di-deploy ke server API global root.

gdcloud

  1. Tetapkan hubungan volume replikasi asinkron antara zona utama dan zona sekunder:

    gdcloud compute disks start-async-replication PRIMARY_DISK_NAME \
    --project PROJECT \
    --zone PRIMARY_ZONE \
    --secondary-disk SECONDARY_DISK_NAME \
    --secondary-zone SECONDARY_ZONE

    Ganti kode berikut:

    • PRIMARY_DISK_NAME: nama disk sumber yang direplikasi.
    • PROJECT: project GDC dari disk utama.
    • PRIMARY_ZONE: zona tempat disk utama berada.
    • SECONDARY_DISK_NAME: nama disk tujuan yang akan direplikasi.
    • SECONDARY_ZONE: zona tempat disk sekunder harus berada.

  2. Buat resource kustom VolumeFailover di zona tujuan, yang menghentikan replikasi ke zona tujuan jika zona sumber tidak tersedia karena alasan apa pun:

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: storage.gdc.goog/v1
kind: VolumeFailover
metadata:
  name: FAILOVER_NAME
  namespace: PROJECT
spec:
  volumeReplicationRelationshipRef: REPL_NAME
EOF

    Ganti kode berikut:

    • MANAGEMENT_API_SERVER: file kubeconfig untuk server Management API.
    • FAILOVER_NAME: nama failover.
    • PROJECT: project tempat infrastruktur penyimpanan berada.
    • REPL_NAME: nama hubungan replikasi volume.

    Untuk mengetahui informasi selengkapnya tentang cara mengelola replikasi asinkron untuk workload VM, lihat artikel Mereplikasi volume secara asinkron.

API

  1. Buat file YAML resource kustom VolumeReplicationRelationship dan deploy ke server API global:

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: storage.global.gdc.goog/v1
kind: VolumeReplicationRelationship
metadata:
  name: VRR_NAME
  namespace: PROJECT
spec:
  source:
    virtualMachineDisk:
      virtualMachineDiskRef: PRIMARY_DISK_NAME
    zoneRef: PRIMARY_ZONE
  destination:
    volumeOverrideName: SECONDARY_DISK_NAME
    zoneRef: SECONDARY_ZONE
EOF

    Ganti kode berikut:

    • GLOBAL_API_SERVER: file kubeconfig untuk server API pengelolaan global.
    • VRR_NAME: nama hubungan replikasi volume. Nama yang sama harus digunakan saat menghentikan replikasi asinkron.
    • PROJECT: project GDC dari disk utama.
    • PRIMARY_DISK_NAME: nama disk sumber yang direplikasi.
    • PRIMARY_ZONE: zona tempat disk utama berada.
    • SECONDARY_DISK_NAME: nama disk tujuan yang akan direplikasi.
    • SECONDARY_ZONE: zona tempat disk sekunder harus berada.

  2. Buat resource kustom VolumeFailover di zona tujuan, yang menghentikan replikasi ke zona tujuan jika zona sumber tidak tersedia karena alasan apa pun:

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: storage.gdc.goog/v1
kind: VolumeFailover
metadata:
  name: FAILOVER_NAME
  namespace: PROJECT
spec:
  volumeReplicationRelationshipRef: REPL_NAME
EOF

    Ganti kode berikut:

    • MANAGEMENT_API_SERVER: file kubeconfig untuk server Management API.
    • FAILOVER_NAME: nama failover.
    • PROJECT: project tempat infrastruktur penyimpanan berada.
    • REPL_NAME: nama hubungan replikasi volume.

Untuk mengetahui informasi selengkapnya tentang cara mengelola replikasi asinkron untuk workload VM, lihat Mereplikasi volume secara asinkron.

Langkah berikutnya