Praktik terbaik untuk ketersediaan tinggi

Dokumen ini menjelaskan praktik terbaik untuk mencapai ketersediaan tinggi (HA) dengan workload Red Hat OpenShift Container Platform di Compute Engine. Dokumen ini berfokus pada strategi tingkat aplikasi untuk membantu Anda memastikan bahwa workload Anda tetap sangat tersedia saat terjadi kegagalan. Strategi ini membantu Anda menghilangkan titik tunggal kegagalan dan menerapkan mekanisme untuk penggantian dan pemulihan otomatis.

Dokumen ini ditujukan untuk arsitek platform dan aplikasi serta mengasumsikan bahwa Anda memiliki pengalaman dalam men-deploy OpenShift. Untuk mengetahui informasi selengkapnya tentang cara men-deploy OpenShift, lihat dokumentasi Red Hat.

Dokumen ini adalah bagian dari seri yang berfokus pada strategi tingkat aplikasi yang memastikan beban kerja Anda tetap sangat tersedia dan dapat dipulihkan dengan cepat jika terjadi kegagalan. Dokumen dalam rangkaian ini adalah sebagai berikut:

Sebarkan deployment di beberapa zona

Sebaiknya Anda men-deploy OpenShift di beberapa zona dalam satu Google Cloud region. Pendekatan ini membantu memastikan bahwa jika suatu zona mengalami pemadaman, node bidang kontrol cluster akan terus berfungsi di zona lain tempat deployment tersebar. Untuk men-deploy OpenShift di beberapa zona, tentukan daftar zona Google Cloud dari region yang sama di file install-config.yaml.

Untuk kontrol terperinci atas lokasi tempat node di-deploy, sebaiknya tentukan kebijakan penempatan VM yang memastikan VM tersebar di domain kegagalan yang berbeda di zona yang sama. Menerapkan kebijakan penempatan tersebar ke node cluster membantu mengurangi jumlah node yang terpengaruh secara bersamaan oleh gangguan khusus lokasi. Untuk mengetahui informasi selengkapnya tentang cara membuat kebijakan spread untuk cluster yang ada, lihat Membuat dan menerapkan kebijakan penempatan spread ke VM.

Demikian pula, untuk mencegah beberapa pod dijadwalkan pada node yang sama, sebaiknya Anda menggunakan aturan anti-afinitas pod. Aturan ini menyebarkan replika aplikasi di beberapa zona. Contoh berikut menunjukkan cara menerapkan aturan anti-afinitas pod:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  namespace: my-app-namespace
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      # Pod Anti-Affinity: Prefer to schedule new pods on nodes in different zones.
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchLabels:
                app: my-app
            topologyKey: topology.kubernetes.io/zone
      containers:
      - name: my-app-container
        image: quay.io/myorg/my-app:latest
        ports:
        - containerPort: 8080

Untuk layanan stateless seperti frontend web atau REST API, sebaiknya Anda menjalankan beberapa replika pod untuk setiap layanan atau rute. Pendekatan ini memastikan bahwa traffic secara otomatis dirutekan ke pod di zona yang tersedia.

Mengelola beban secara proaktif untuk mencegah kelebihan alokasi resource

Sebaiknya Anda mengelola beban aplikasi secara proaktif untuk mencegah penggunaan sumber daya yang berlebihan. Over-commitment dapat menyebabkan performa layanan yang buruk saat beban tinggi. Anda dapat membantu mencegah komitmen berlebih dengan menetapkan batas permintaan resource. Untuk penjelasan yang lebih mendetail, lihat mengelola resource untuk pod Anda. Selain itu, Anda dapat menskalakan replika naik atau turun secara otomatis berdasarkan CPU, memori, atau metrik kustom, menggunakan horizontal pod autoscaler.

Sebaiknya Anda juga menggunakan layanan load balancing berikut:

  • Operator ingress OpenShift. Operator Ingress men-deploy pengontrol ingress berbasis HAProxy untuk menangani perutean ke pod Anda. Secara khusus, sebaiknya Anda mengonfigurasi akses global untuk pengontrol Ingress, yang memungkinkan klien di region mana pun dalam jaringan VPC dan region yang sama dengan load balancer, untuk menjangkau beban kerja yang berjalan di cluster Anda. Selain itu, sebaiknya Anda menerapkan pemeriksaan kondisi pengontrol ingress untuk memantau kondisi pod dan memulai ulang pod yang gagal.
  • Google Cloud Load Balancing. Load Balancing mendistribusikan traffic di seluruh Google Cloud zona. Pilih load balancer yang sesuai dengan kebutuhan aplikasi Anda.

Menentukan anggaran disrupsi pod

Sebaiknya Anda menentukan anggaran gangguan untuk menentukan jumlah minimum pod yang diperlukan aplikasi Anda agar tersedia selama gangguan seperti peristiwa pemeliharaan atau update. Contoh berikut menunjukkan cara menentukan anggaran gangguan:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
  namespace: my-app-namespace
spec:
  # Define how many pods need to remain available during a disruption.
  # At least one of "minAvailable" or "maxUnavailable" must be specified.
  minAvailable: 2
  selector:
    matchLabels:
      app: my-app

Untuk informasi selengkapnya, lihat Menentukan Anggaran Gangguan untuk Aplikasi Anda.

Menggunakan penyimpanan yang mendukung HA dan replikasi data