Praktik terbaik untuk ketersediaan tinggi dengan OpenShift

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

Menyebarkan 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 dalam file install-config.yaml Anda.

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 spread 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 front end 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 penggunaan resource yang berlebihan

Sebaiknya kelola beban aplikasi Anda secara proaktif untuk mencegah penggunaan sumber daya yang berlebihan. Over-commitment dapat menyebabkan performa layanan yang buruk saat beban tinggi. Anda dapat membantu mencegah over-commitment 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 pemilihan rute ke pod Anda. Secara khusus, sebaiknya Anda mengonfigurasi akses global untuk pengontrol Ingress, yang memungkinkan klien di region mana pun dalam jaringan dan region VPC yang sama dengan load balancer, untuk menjangkau beban kerja yang berjalan di cluster Anda. Selain itu, sebaiknya terapkan health check 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

Untuk beban kerja stateful yang memerlukan penyimpanan data persisten di luar penampung, sebaiknya ikuti praktik terbaik berikut.

Praktik terbaik disk

Jika Anda memerlukan penyimpanan disk, gunakan salah satu opsi berikut:

Setelah memilih opsi penyimpanan, instal drivernya di cluster Anda:

Operator CSI Persistent Disk menyediakan class penyimpanan yang dapat Anda gunakan untuk membuat klaim volume persisten (PVC). Untuk Filestore, Anda harus membuat class penyimpanan Filestore.

Praktik terbaik database

Jika Anda memerlukan database, gunakan salah satu opsi berikut:

Setelah menginstal operator database, konfigurasikan cluster dengan beberapa instance. Contoh berikut menunjukkan konfigurasi untuk cluster dengan atribut berikut:

  • Cluster PostgreSQL bernama my-postgres-cluster dibuat dengan tiga instance untuk ketersediaan tinggi.
  • Cluster menggunakan class penyimpanan regionalpd-balanced untuk penyimpanan yang tahan lama dan direplikasi di seluruh zona.
  • Database bernama mydatabase diinisialisasi dengan pengguna myuser, yang kredensialnya disimpan dalam secret Kubernetes bernama my-database-secret.
  • Akses superuser dinonaktifkan untuk meningkatkan keamanan.
  • Pemantauan diaktifkan untuk cluster.
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: my-postgres-cluster
  namespace: postgres-namespace
spec:
  instances: 3
  storage:
    size: 10Gi
    storageClass: regionalpd-balanced
  bootstrap:
    initdb:
      database: mydatabase
      owner: myuser
      secret:
        name: my-database-secret
  enableSuperuserAccess: false
  monitoring:
    enabled: true
---
apiVersion: 1
kind: Secret
metadata:
  name: my-database-secret
  namespace: postgres-namespace
type: Opaque
data:
  username: bXl1c2Vy # Base64-encoded value of "myuser"
  password: c2VjdXJlcGFzc3dvcmQ= # Base64-encoded value of "securepassword"

Mengeksternalkan status aplikasi

Sebaiknya pindahkan status sesi atau caching ke penyimpanan dalam memori bersama (misalnya, Redis) atau penyimpanan data persisten (misalnya, Postgres, MySQL) yang dikonfigurasi untuk berjalan dalam mode HA.

Ringkasan praktik terbaik

Singkatnya, terapkan praktik terbaik berikut untuk mencapai ketersediaan tinggi dengan OpenShift:

  • Menyebarkan deployment di beberapa zona
  • Mengelola beban secara proaktif untuk mencegah penggunaan resource yang berlebihan
  • Menentukan anggaran disrupsi pod
  • Menggunakan fitur replikasi data HA
  • Mengeksternalkan status aplikasi

Langkah berikutnya