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 failover dan pemulihan otomatis.

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

Mendistribusikan deployment di beberapa zona

Sebaiknya deploy OpenShift di beberapa zona dalam regionGoogle Cloud . Pendekatan ini membantu memastikan bahwa jika zona mengalami pemadaman layanan, 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 Anda.

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

Demikian pula, untuk mencegah beberapa pod dijadwalkan di 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 komitmen resource

Sebaiknya kelola beban aplikasi Anda secara proaktif untuk mencegah over-commit resource. Komitmen berlebih dapat menyebabkan performa layanan yang buruk saat beban tinggi. Anda dapat membantu mencegah kelebihan komitmen dengan menetapkan batas permintaan resource. Untuk penjelasan yang lebih mendetail, lihat mengelola resource untuk pod Anda. Selain itu, Anda dapat menskalakan replika secara otomatis ke atas atau ke bawah berdasarkan CPU, memori, atau metrik kustom, menggunakan horizontal pod autoscaler.

Sebaiknya gunakan juga 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 Anda menerapkan health check pengontrol traffic masuk untuk memantau kondisi pod dan memulai ulang pod yang gagal.
  • Google Cloud Load Balancing. Load Balancing mendistribusikan traffic di seluruh zonaGoogle Cloud . Pilih load balancer yang sesuai dengan kebutuhan aplikasi Anda.

Menentukan anggaran disrupsi pod

Sebaiknya tentukan 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 gunakan 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:

Terakhir, tetapkan StorageClass untuk disk Anda:

Contoh berikut menunjukkan cara menetapkan StorageClass:

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: regionalpd-balanced
provisioner: PROVISIONER
parameters:
  type: DISK-TYPE
  replication-type: REPLICATION-TYPE
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Delete
allowVolumeExpansion: true
allowedTopologies:
  - matchLabelExpressions:
      - key: topology.kubernetes.io/zone
        values:
          - europe-west1-b
          - europe-west1-a

Praktik terbaik database

Jika Anda memerlukan database, gunakan salah satu dari 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 yang disebut 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 penyimpanan ke penyimpanan dalam memori bersama (misalnya, Redis) atau datastore 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:

  • Mendistribusikan deployment di beberapa zona
  • Mengelola beban secara proaktif untuk mencegah kelebihan komitmen resource
  • Menentukan anggaran disrupsi pod
  • Menggunakan fitur replikasi data HA
  • Mengeksternalkan status aplikasi

Langkah berikutnya