Men-deploy aplikasi container yang memiliki ketersediaan tinggi

Halaman ini memberikan strategi deployment yang direkomendasikan untuk membangun aplikasi container Kubernetes yang andal dan memiliki ketersediaan tinggi (HA) di Google Distributed Cloud (GDC) yang terisolasi. Anda harus men-deploy aplikasi penampung 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 cluster Kubernetes di dua atau beberapa zona di GDC Anda.
  • Konfigurasi load balancing global.
  • Deploy workload container ke setiap cluster Kubernetes zonal.
  • Sediakan penyimpanan dan lampirkan ke pod Anda.
  • Mengonfigurasi replikasi penyimpanan asinkron, menggunakan penyimpanan blok atau penyimpanan objek.

Sebelum memulai

  • Pastikan Anda bekerja di semesta GDC dengan beberapa zona yang 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 Admin Namespace (namespace-admin) untuk membuat dan mengelola beban kerja penampung.

    • Peran Admin Cluster Pengguna (user-cluster-admin) dan Developer Cluster Pengguna (user-cluster-developer) untuk membuat dan mengelola cluster Kubernetes serta kumpulan nodenya.

    • 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) untuk membuat dan mengelola kebijakan jaringan project di seluruh zona.

    • Peran Harbor Instance Admin (harbor-instance-admin), Harbor Instance Viewer(harbor-instance-viewer), dan Harbor Project Creator (harbor-project-creator). Peran ini diperlukan untuk membuat dan mengelola image container di Artifact Registry.

    • Peran Volume Replication Global Admin (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 yang ditetapkan untuk server API global, server API Pengelolaan, dan cluster Kubernetes. Lihat Membuat file kubeconfig secara manual untuk mengetahui informasi selengkapnya.

Membuat cluster Kubernetes di beberapa zona

Cluster Kubernetes adalah resource zonal, jadi Anda harus membuat cluster secara terpisah di setiap zona.

Konsol

  1. Di menu navigasi, pilih Kubernetes Engine > Clusters.

  2. Klik Create Cluster.

  3. Di kolom Name, tentukan nama untuk cluster.

  4. Pilih versi Kubernetes untuk cluster.

  5. Pilih zona tempat cluster akan dibuat.

  6. Klik Lampirkan Project dan pilih project yang ada untuk dilampirkan ke cluster Anda. Kemudian, klik Simpan. Anda dapat melampirkan atau melepaskan project setelah membuat cluster dari halaman Project details. Anda harus memiliki project yang dilampirkan ke cluster sebelum men-deploy beban kerja penampung.

  7. Klik Berikutnya.

  8. Konfigurasi setelan jaringan untuk cluster Anda. Anda tidak dapat mengubah setelan jaringan ini setelah membuat cluster. Protokol Internet default dan satu-satunya yang didukung untuk cluster Kubernetes adalah Internet Protocol versi 4 (IPv4).

    1. Tentukan ukuran kumpulan alamat IP Load Balancer, seperti 20.

    2. Pilih CIDR (Classless Inter-Domain Routing) Layanan yang akan digunakan. Layanan yang di-deploy, seperti load balancer, dialokasikan alamat IP dari rentang ini.

    3. Pilih CIDR pod yang akan digunakan. Cluster mengalokasikan alamat IP dari rentang ini ke pod dan VM Anda.

    4. Klik Berikutnya.

  9. Tinjau detail kumpulan node default yang dibuat otomatis untuk cluster. Klik Edit untuk mengubah node pool default.

  10. Untuk membuat kumpulan node tambahan, pilih Tambahkan kumpulan node. Saat mengedit node pool default atau menambahkan node pool baru, Anda dapat menyesuaikannya dengan opsi berikut:

    1. Tetapkan nama untuk kumpulan node. Anda tidak dapat mengubah nama setelah membuat node pool.
    2. Tentukan jumlah node pekerja yang akan dibuat di node pool.

    3. Pilih kelas mesin yang paling sesuai dengan persyaratan workload Anda. Lihat daftar setelan berikut:

      • Jenis mesin
      • CPU
      • Memori

    4. Klik Simpan.

    5. Klik Create untuk membuat cluster.

  11. Ulangi langkah-langkah ini untuk setiap zona di semesta GDC Anda. Pastikan cluster Kubernetes berada di setiap zona yang Anda inginkan untuk strategi HA Anda.

API

Untuk membuat cluster Kubernetes baru menggunakan API secara langsung, terapkan resource kustom ke setiap zona GDC.

  1. Buat resource kustom Cluster dan deploy ke server Management API untuk zona Anda:

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF \
apiVersion: cluster.gdc.goog/v1
kind: Cluster
metadata:
  name: CLUSTER_NAME
  namespace: platform
spec:
  clusterNetwork:
    podCIDRSize: POD_CIDR
    serviceCIDRSize: SERVICE_CIDR
  initialVersion:
    kubernetesVersion: KUBERNETES_VERSION
  loadBalancer:
    ingressServiceIPSize: LOAD_BALANCER_POOL_SIZE
  nodePools:
  - machineTypeName: MACHINE_TYPE
    name: NODE_POOL_NAME
    nodeCount: NUMBER_OF_WORKER_NODES
    taints: TAINTS
    labels: LABELS
    acceleratorOptions:
      gpuPartitionScheme: GPU_PARTITION_SCHEME
  releaseChannel:
    channel: UNSPECIFIED
EOF

    Ganti kode berikut:

    • MANAGEMENT_API_SERVER: jalur kubeconfig dari server Management API zonal. Untuk mengetahui informasi selengkapnya, lihat Beralih ke konteks zona.
    • CLUSTER_NAME: nama cluster. Nama cluster tidak boleh diakhiri dengan -system. Akhiran -system dicadangkan untuk cluster yang dibuat oleh GDC.
    • POD_CIDR: ukuran rentang jaringan tempat alamat IP virtual (VIP) pod dialokasikan. Jika tidak disetel, nilai default 21 akan digunakan.
    • SERVICE_CIDR: ukuran rentang jaringan tempat VIP layanan dialokasikan. Jika tidak disetel, nilai default 23 akan digunakan.
    • KUBERNETES_VERSION: versi Kubernetes cluster, seperti 1.26.5-gke.2100. Untuk mencantumkan versi Kubernetes yang tersedia untuk dikonfigurasi, lihat Mencantumkan versi Kubernetes yang tersedia untuk cluster.
    • LOAD_BALANCER_POOL_SIZE: ukuran kumpulan alamat IP yang tidak tumpang-tindih yang digunakan oleh layanan load balancer. Jika tidak disetel, nilai default 20 akan digunakan.
    • MACHINE_TYPE: jenis mesin untuk node pekerja node pool. Lihat jenis mesin yang tersedia untuk mengetahui konfigurasi yang tersedia.
    • NODE_POOL_NAME: nama node pool.
    • NUMBER_OF_WORKER_NODES: jumlah node pekerja yang akan disediakan di node pool.
    • TAINTS: taint yang akan diterapkan ke node di node pool ini. Kolom ini bersifat opsional.
    • LABELS: label yang akan diterapkan ke node node pool ini. Objek ini berisi daftar key-value pair. Kolom ini bersifat opsional.
    • GPU_PARTITION_SCHEME: skema partisi GPU, jika Anda menjalankan beban kerja GPU, seperti mixed-2. GPU tidak dipartisi jika kolom ini tidak ditetapkan. Untuk mengetahui profil GPU Multi-Instance (MIG) yang tersedia, lihat Profil MIG yang didukung.

  2. Ulangi langkah sebelumnya untuk setiap zona yang ingin Anda gunakan untuk menghosting aplikasi penampung untuk strategi HA Anda.

Mengonfigurasi load balancer

Untuk mendistribusikan traffic antara pod 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 penampung 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 penampung Anda.

gdcloud

Buat ILB yang menargetkan beban kerja pod 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 zonal di setiap zona tempat pod Anda berjalan untuk menentukan endpoint ILB:

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

    Ganti kode berikut:

    • BACKEND_NAME: nama yang dipilih untuk resource backend, seperti my-backend.
    • LABELS: pemilih yang menentukan endpoint mana antar-pod yang akan digunakan untuk resource backend ini, seperti app=web.
    • PROJECT: nama project Anda.
    • CLUSTER_NAME: cluster Kubernetes yang menjadi batas cakupan pemilih yang ditentukan. Jika kolom ini tidak ditentukan, semua endpoint dengan label tertentu akan dipilih. Kolom ini bersifat opsional.
    • 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. Buat resource BackendService global:

    gdcloud compute backend-services create BACKEND_SERVICE_NAME \
    --project=PROJECT \
    --target-ports=TARGET_PORTS \
    --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.

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

  4. 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 aplikasi sebenarnya di dalam container.

  5. 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 penampung 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 Backend resource untuk setiap zona tempat workload container ditempatkan:

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: Backend
metadata:
  namespace: PROJECT
  name: BACKEND_NAME
spec:
  clusterName: CLUSTER_NAME
  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.
    • CLUSTER_NAME: cluster Kubernetes yang menjadi batas cakupan pemilih yang ditentukan. Jika kolom ini tidak ditentukan, semua endpoint dengan label tertentu akan dipilih. Kolom ini bersifat opsional.
    • APP_NAME: nama aplikasi container Anda.

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

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

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

  4. 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 penampung 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 pada pod 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 \
  --cluster=CLUSTER_NAME \
  --zone=ZONE

    Ganti kode berikut:

    • BACKEND_NAME: nama untuk resource backend, seperti my-backend.
    • LABELS: pemilih yang menentukan endpoint antar-pod yang akan digunakan untuk resource backend ini, seperti app=web.
    • PROJECT: nama project Anda.
    • CLUSTER_NAME: cluster Kubernetes yang menjadi batas cakupan pemilih yang ditentukan. Jika kolom ini tidak ditentukan, semua endpoint dengan label tertentu akan dipilih. Kolom ini bersifat opsional.
    • 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.

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

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

  4. 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=ZONE \
  --project=PROJECT \
  --global

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

  5. 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 container.
    • PROJECT: nama project Anda.

  6. 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 pod 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 pada pod 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:
  clusterName: CLUSTER_NAME
  endpointsLabels:
    matchLabels:
      app: APP_NAME
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.
    • CLUSTER_NAME: cluster Kubernetes yang menjadi batas cakupan pemilih yang ditentukan. Jika kolom ini tidak ditentukan, semua endpoint dengan label tertentu akan dipilih. Kolom ini bersifat opsional.
    • APP_NAME: nama aplikasi container Anda.

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

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

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

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

Men-deploy workload container ke setiap cluster zonal

Beban kerja penampung bukan merupakan resource global, yang berarti Anda harus men-deploy setiap aplikasi penampung secara terpisah ke dalam cluster Kubernetes zonal.

  1. Login ke zona yang menghosting cluster Kubernetes Anda:

    gdcloud config set core/zone ZONE

  2. Verifikasi bahwa image container Anda tersedia dari registry Harbor terkelola. Untuk mengetahui informasi selengkapnya, lihat tutorial Men-deploy aplikasi container.

  3. Buat file manifes untuk workload container Anda dan deploy ke cluster Kubernetes zonal Anda:

    kubectl --kubeconfig KUBERNETES_CLUSTER -n PROJECT \
    apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: DEPLOYMENT_NAME
spec:
  replicas: NUMBER_OF_REPLICAS
  selector:
    matchLabels:
      run: APP_NAME
  template:
    metadata:
      labels:
        run: APP_NAME
    spec:
      containers:
      - name: CONTAINER_NAME
        image: HARBOR_INSTANCE_URL/HARBOR_PROJECT_NAME/IMAGE:TAG
EOF

    Ganti kode berikut:

    • KUBERNETES_CLUSTER: file kubeconfig untuk cluster Kubernetes zonal tempat Anda men-deploy workload container. Jika Anda belum membuat file kubeconfig untuk cluster Kubernetes zonal, lihat Membuat file kubeconfig secara manual untuk mengetahui detailnya.
    • PROJECT: namespace project tempat men-deploy workload container.
    • DEPLOYMENT_NAME: nama deployment container Anda.
    • NUMBER_OF_REPLICAS: jumlah objek Pod replika yang dikelola deployment.
    • APP_NAME: nama aplikasi yang akan dijalankan dalam deployment.
    • CONTAINER_NAME: nama container.
    • HARBOR_INSTANCE_URL: URL instance Harbor, seperti harbor-1.org-1.zone1.google.gdc.test. Untuk mengambil URL instance Harbor, lihat Melihat instance registry Harbor.
    • HARBOR_PROJECT_NAME: nama project Harbor, seperti my-project.
    • IMAGE: nama gambar, seperti nginx.
    • TAG: tag untuk versi image yang ingin Anda tarik, seperti 1.0.

  4. Ulangi langkah-langkah sebelumnya untuk setiap zona di semesta GDC Anda. Pastikan aplikasi penampung Anda berada di setiap zona yang Anda inginkan untuk strategi HA.

Mengekspos aplikasi container menggunakan Kubernetes

Anda harus mengekspos aplikasi penampung untuk mengizinkan akses ke aplikasi tersebut dari resource lain di semesta GDC Anda.

  1. Buat resource Service dari type: LoadBalancer. Resource ini mengekspos pod aplikasi Anda melalui jaringan.

    kubectl --kubeconfig KUBERNETES_CLUSTER -n PROJECT \
apiVersion: v1
kind: Service
metadata:
  name: SERVICE_NAME
spec:
  selector:
    app: APP_NAME
  ports:
    - port: 80
      protocol: TCP
  type: LoadBalancer
EOF

    Ganti kode berikut:

    • KUBERNETES_CLUSTER: file kubeconfig untuk cluster Kubernetes zonal tempat Anda men-deploy workload container.
    • PROJECT: namespace project tempat workload container Anda berada.
    • SERVICE_NAME: nama layanan load balancer.
    • APP_NAME: label yang Anda terapkan untuk aplikasi penampung.

  2. Buat resource kustom NetworkPolicy untuk mengizinkan semua traffic jaringan ke namespace default:

    kubectl --kubeconfig KUBERNETES_CLUSTER -n PROJECT \
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  annotations:
  name: allow-all
spec:
  ingress:
  - from:
    - ipBlock:
        cidr: 0.0.0.0/0
  podSelector: {}
  policyTypes:
  - Ingress
EOF

Menyediakan penyimpanan persisten untuk pod Anda

Anda harus membuat resource PersistentVolumeClaim (PVC) untuk menyediakan penyimpanan persisten bagi pod aplikasi.

Petunjuk berikut menunjukkan cara membuat volume menggunakan GDC standard-rwo StorageClass.

  1. Buat resource PersistentVolumeClaim Misalnya, konfigurasikan dengan mode akses ReadWriteOnce dan kelas penyimpanan standard-rwo:

    kubectl --kubeconfig KUBERNETES_CLUSTER \
    --namespace PROJECT apply -f - <<EOF
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: PVC_NAME
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: standard-rwo
EOF

    Ganti kode berikut:

    • KUBERNETES_CLUSTER: file kubeconfig untuk cluster Kubernetes.
    • PROJECT: namespace project tempat PVC akan dibuat.
    • PVC_NAME: nama objek PersistentVolumeClaim.

  2. Objek PersistentVolume (PV) disediakan secara dinamis. Periksa status PV baru di cluster Kubernetes Anda:

    kubectl get pv --kubeconfig KUBERNETES_CLUSTER

    Outputnya mirip dengan hal berikut ini:

    NAME       CAPACITY   ACCESS MODES   STATUS      CLAIM     STORAGECLASS   AGE
pvc-uuidd  10Gi       RWO            Bound       pvc-name  standard-rwo   60s

  3. Konfigurasi workload container Anda untuk menggunakan PVC. Berikut adalah contoh manifes pod yang menggunakan PVC standard-rwo:

    kubectl --kubeconfig KUBERNETES_CLUSTER \
    --namespace PROJECT apply -f - <<EOF
apiVersion: apps/v1
kind: Pod
metadata:
  name: web-server-deployment
  labels:
    app: APP_LABEL
spec:
  containers:
  - name: CONTAINER_NAME
    image: HARBOR_INSTANCE_URL/HARBOR_PROJECT_NAME/IMAGE:TAG
    volumeMounts:
    - mountPath: MOUNT_PATH
      name: data
  volumes:
  - name: data
    persistentVolumeClaim:
      claimName: PVC_NAME
EOF

    Ganti kode berikut:

    • KUBERNETES_CLUSTER: file kubeconfig untuk cluster Kubernetes tempat Anda men-deploy workload container.
    • PROJECT: namespace project tempat PVC berada.
    • APP_LABEL: label yang Anda terapkan untuk aplikasi penampung.
    • CONTAINER_NAME: nama container.
    • HARBOR_INSTANCE_URL: URL instance Harbor, seperti harbor-1.org-1.zone1.google.gdc.test. Untuk mengambil URL instance Harbor, lihat Melihat instance registry Harbor.
    • HARBOR_PROJECT_NAME: nama project Harbor, seperti my-project.
    • IMAGE: nama gambar, seperti nginx.
    • TAG: tag untuk versi image yang ingin Anda tarik, seperti 1.0.
    • MOUNT_PATH: jalur di dalam pod untuk memasang volume Anda.
    • PVC_NAME: PVC yang Anda buat.

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 penampung 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. Verifikasi bahwa 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 mengonfigurasi hubungan replikasi penyimpanan di seluruh zona untuk membuat data yang direplikasi yang tersedia untuk failover jika data zona sumber menjadi tidak tersedia. Hal ini relevan jika Anda menggunakan penyimpanan blok untuk aplikasi penampung.

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.

  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: PVC_REPL_NAME
  namespace: PROJECT
spec:
  source:
    pvc:
      clusterRef: SOURCE_PVC_CLUSTER
      pvcRef: SOURCE_PVC
    zoneRef: SOURCE_ZONE
destination:
    pvc:
      clusterRef: DEST_PVC_CLUSTER
    zoneRef: DEST_ZONE
EOF

    Ganti kode berikut:

    • GLOBAL_API_SERVER: file kubeconfig untuk server API global.
    • PVC_REPL_NAME: nama hubungan replikasi volume.
    • PROJECT: project tempat infrastruktur penyimpanan berada.
    • SOURCE_PVC_CLUSTER: cluster Kubernetes tempat PVC dihosting.
    • SOURCE_PVC: PVC di zona sumber yang akan direplikasi.
    • SOURCE_ZONE: zona sumber tempat PVC dihosting.
    • DEST_PVC_CLUSTER: cluster Kubernetes tujuan untuk mereplikasi PVC.
    • DEST_ZONE: zona tujuan untuk mereplikasi PVC ke.

  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: PVC_FAILOVER_NAME
  namespace: PROJECT
spec:
  volumeReplicationRelationshipRef: PVC_REPL_NAME
EOF

    Ganti kode berikut:

    • MANAGEMENT_API_SERVER: file kubeconfig server Management API zonal.
    • PVC_FAILOVER_NAME: nama failover PVC.
    • PROJECT: project tempat infrastruktur penyimpanan berada.
    • PVC_REPL_NAME: nama hubungan replikasi volume.

Langkah berikutnya