Menyebarkan database PostgreSQL yang sangat tersedia di Azure Kubernetes Service (AKS)

Dalam artikel ini, Anda menyebarkan database PostgreSQL yang sangat tersedia di AKS.

Important

Perangkat lunak sumber terbuka disebutkan di seluruh dokumentasi dan sampel AKS. Perangkat lunak yang Anda sebarkan dikecualikan dari perjanjian tingkat layanan AKS, garansi terbatas, dan dukungan Azure. Saat Anda menggunakan teknologi sumber terbuka bersama AKS, konsultasikan opsi dukungan yang tersedia dari masing-masing komunitas dan pengelola proyek untuk mengembangkan rencana.

Microsoft bertanggung jawab untuk membangun paket sumber terbuka yang kami sebarkan di AKS. Tanggung jawab itu termasuk memiliki kepemilikan lengkap atas proses build, pemindaian, penandatanganan, validasi, dan perbaikan cepat, bersama dengan kontrol atas file biner dalam gambar kontainer. Untuk informasi selengkapnya, lihat Manajemen kerentanan untuk AKS dan cakupan dukungan AKS.

Membuat rahasia untuk pengguna aplikasi bootstrap

  1. Buat kunci rahasia untuk memvalidasi penyebaran PostgreSQL dengan login interaktif untuk pengguna aplikasi bootstrap menggunakan perintah kubectl create secret.

Important

Microsoft menyarankan agar Anda menggunakan alur autentikasi paling aman yang tersedia. Alur autentikasi yang dijelaskan dalam prosedur ini memerlukan tingkat kepercayaan yang tinggi pada aplikasi dan membawa risiko yang tidak ada dalam alur lain. Anda hanya boleh menggunakan alur ini ketika alur lain yang lebih aman, seperti identitas terkelola, tidak layak.

PG_DATABASE_APPUSER_SECRET=$(echo -n | openssl rand -base64 16)

kubectl create secret generic db-user-pass \
    --from-literal=username=app \
     --from-literal=password="${PG_DATABASE_APPUSER_SECRET}" \
     --namespace $PG_NAMESPACE \
     --context $AKS_PRIMARY_CLUSTER_NAME

  1. Validasi bahwa rahasia berhasil dibuat menggunakan kubectl get perintah .

    kubectl get secret db-user-pass --namespace $PG_NAMESPACE --context $AKS_PRIMARY_CLUSTER_NAME

Mengatur variabel lingkungan untuk kluster PostgreSQL

  • Sebarkan ConfigMap untuk mengonfigurasi operator CNPG menggunakan perintah berikut kubectl apply . Nilai-nilai ini menggantikan sakelar lama ENABLE_AZURE_PVC_UPDATES, yang tidak lagi diperlukan, dan membantu menjadwalkan peningkatan secara bertahap serta mempercepat koneksi ulang replika. Sebelum menerapkan konfigurasi ini ke dalam produksi, pastikan bahwa pengaturan DRAIN_TAINTS yang Anda gunakan tetap sesuai dengan lingkungan Azure Anda.

    cat <<EOF | kubectl apply --context $AKS_PRIMARY_CLUSTER_NAME -n $PG_NAMESPACE -f -
apiVersion: v1
kind: ConfigMap
metadata:
    name: cnpg-controller-manager-config
data:
    CLUSTERS_ROLLOUT_DELAY: '120'
    STANDBY_TCP_USER_TIMEOUT: '10'
EOF

Memasang Prometheus PodMonitors

Prometheus mengekstrak CNPG menggunakan aturan perekaman yang disimpan dalam repositori sampel GitHub CNPG. Karena PodMonitor yang dikelola operator tidak digunakan lagi, buat dan kelola sendiri sumber daya PodMonitor sehingga Anda dapat menyesuaikannya dengan tumpukan pemantauan Anda.

  1. Tambahkan repositori Prometheus Community Helm menggunakan helm repo add perintah .

    helm repo add prometheus-community \
    https://prometheus-community.github.io/helm-charts

  2. Perbarui repositori Prometheus Community Helm dan instal pada kluster utama menggunakan perintah helm upgrade dengan flag --install.

    helm upgrade --install \
    --namespace $PG_NAMESPACE \
    -f https://raw.githubusercontent.com/cloudnative-pg/cloudnative-pg/main/docs/src/samples/monitoring/kube-stack-config.yaml \
    prometheus-community \
    prometheus-community/kube-prometheus-stack \
    --kube-context=$AKS_PRIMARY_CLUSTER_NAME

  3. Buat PodMonitor untuk kluster. Tim CNPG menghentikan PodMonitor yang dikelola operator, jadi Anda sekarang mengelolanya secara langsung:

    cat <<EOF | kubectl apply --context $AKS_PRIMARY_CLUSTER_NAME --namespace $PG_NAMESPACE -f -
apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
  name: $PG_PRIMARY_CLUSTER_NAME
  namespace: ${PG_NAMESPACE}
  labels:
    cnpg.io/cluster: ${PG_PRIMARY_CLUSTER_NAME}
spec:
  selector:
    matchLabels:
      cnpg.io/cluster: ${PG_PRIMARY_CLUSTER_NAME}
  podMetricsEndpoints:
    - port: metrics
EOF

Buat kredensial terfederasi

Di bagian ini, Anda membuat kredensial identitas federasi untuk cadangan PostgreSQL untuk memungkinkan CNPG menggunakan identitas beban kerja AKS untuk mengautentikasi ke tujuan akun penyimpanan untuk cadangan. Operator CNPG membuat akun layanan Kubernetes dengan nama yang sama dengan kluster bernama yang digunakan dalam manifes penyebaran Kluster CNPG.

  1. Dapatkan URL penyedia OIDC dari cluster menggunakan perintah az aks show.

    export AKS_PRIMARY_CLUSTER_OIDC_ISSUER="$(az aks show \
    --name $AKS_PRIMARY_CLUSTER_NAME \
    --resource-group $RESOURCE_GROUP_NAME \
    --query "oidcIssuerProfile.issuerUrl" \
    --output tsv)"

  2. Buat kredensial identitas federasi menggunakan az identity federated-credential create perintah .

    az identity federated-credential create \
    --name $AKS_PRIMARY_CLUSTER_FED_CREDENTIAL_NAME \
    --identity-name $AKS_UAMI_CLUSTER_IDENTITY_NAME \
    --resource-group $RESOURCE_GROUP_NAME \
    --issuer "${AKS_PRIMARY_CLUSTER_OIDC_ISSUER}" \
    --subject system:serviceaccount:"${PG_NAMESPACE}":"${PG_PRIMARY_CLUSTER_NAME}" \
    --audience api://AzureADTokenExchange

Menerapkan kluster PostgreSQL dengan ketersediaan tinggi

Di bagian ini, Anda menyebarkan kluster PostgreSQL yang sangat tersedia menggunakan definisi sumber daya kustom Kluster CNPG (CRD).

Parameter CRD kluster

Tabel berikut menguraikan properti utama yang ditetapkan dalam manifes penyebaran YAML untuk Kluster CRD:

Property Definition
imageName Menunjuk ke gambar kontainer operand CloudNativePG. Gunakan ghcr.io/cloudnative-pg/postgresql:18-system-trixie dengan integrasi cadangan inti yang ditunjukkan dalam panduan ini, atau beralihlah 18-standard-trixie saat Anda mengadopsi plugin Barman Cloud.
inheritedMetadata Khusus untuk operator CNPG. Operator CNPG menerapkan metadata ke setiap objek yang terkait dengan kluster.
annotations Menyertakan label DNS yang diperlukan saat mengekspos titik akhir kluster dan mengaktifkan alpha.cnpg.io/failoverQuorum untuk failover berbasis kuorum.
labels: azure.workload.identity/use: "true" Menunjukkan bahwa AKS harus menyuntikkan dependensi identitas beban kerja ke dalam pod yang menghosting instans klaster PostgreSQL.
topologySpreadConstraints Memerlukan zona yang berbeda dan node yang berbeda dengan label "workload=postgres".
resources Mengonfigurasi kelas Quality of Service (QoS) dari Guaranteed. Dalam lingkungan produksi, nilai-nilai ini adalah kunci untuk memaksimalkan penggunaan VM simpul yang mendasar dan bervariasi berdasarkan Azure VM SKU yang digunakan.
probes Menggantikan konfigurasi warisan startDelay . Pengaktifan streaming dan pemeriksaan kesiapan membantu memastikan replika sehat sebelum melayani lalu lintas.
smartShutdownTimeout Memungkinkan transaksi jangka panjang selesai dengan baik selama pembaruan alih-alih menggunakan penundaan berhenti agresif.
bootstrap Khusus untuk operator CNPG. Menginisialisasi dengan database aplikasi kosong.
storage Menentukan pengaturan PersistentVolume untuk database. Dengan disk terkelola Azure, sintaks yang disederhanakan menyimpan data dan WAL pada volume 64-GiB yang sama, yang menawarkan tingkat throughput yang lebih baik pada disk terkelola. Sesuaikan jika Anda memerlukan volume WAL terpisah.
postgresql.synchronous minSyncReplicas / maxSyncReplicas Mengganti dan memungkinkan Anda menentukan perilaku replikasi sinkron menggunakan skema yang lebih baru.
postgresql.parameters Khusus untuk operator CNPG. Pengaturan peta untuk postgresql.conf, pg_hba.conf, dan pg_ident.conf. Sampel menekankan pengamatan dan default retensi WAL yang sesuai dengan skenario identitas beban kerja AKS tetapi harus disetel per beban kerja.
serviceAccountTemplate Berisi templat yang diperlukan untuk menghasilkan akun layanan dan memetakan kredensial identitas federasi AKS ke UAMI untuk mengaktifkan autentikasi identitas beban kerja AKS dari pod yang menghosting instans PostgreSQL ke sumber daya Azure eksternal.
barmanObjectStore Khusus untuk operator CNPG. Mengonfigurasi rangkaian alat barman-cloud menggunakan identitas beban kerja AKS untuk autentikasi ke penyimpanan objek Azure Blob Storage.

Untuk mengisolasi beban kerja PostgreSQL lebih lanjut, Anda dapat menambahkan taint (misalnya, node-role.kubernetes.io/postgres=:NoSchedule) ke simpul data plane Anda dan mengganti sampel nodeSelector/tolerations dengan nilai yang direkomendasikan oleh CloudNativePG. Jika Anda mengambil pendekatan ini, beri label node yang sesuai dan konfirmasikan kebijakan autoscaler AKS selaras dengan topologi Anda.

Parameter Kinerja PostgreSQL

Performa PostgreSQL sangat bergantung pada sumber daya dan beban kerja yang mendasar kluster Anda. Tabel berikut ini menyediakan panduan dasar untuk kluster tiga node yang berjalan pada node Standard D4s v3 (memori 16-GiB). Perlakukan nilai-nilai ini sebagai titik awal dan sesuaikan setelah Anda memahami profil beban kerja Anda:

Property Nilai yang direkomendasikan Definition
wal_compression lz4 Mengompresi penulisan halaman penuh yang ditulis dalam file WAL dengan metode tertentu
max_wal_size 6 GB Mengatur ukuran WAL yang memicu titik pemeriksaan
checkpoint_timeout 15 menit Mengatur waktu maksimum antara titik pemeriksaan WAL otomatis
checkpoint_completion_target 0,9 Menyeimbangkan pekerjaan titik pemeriksaan di seluruh jendela titik pemeriksaan
checkpoint_flush_after 2 MB Jumlah halaman setelah penulisan yang dilakukan sebelumnya dihapus ke disk
wal_writer_flush_after 2 MB Jumlah WAL yang ditulis oleh penulis log WAL yang memicu proses flush
min_wal_size 2 GB Mengatur ukuran minimum untuk menyusutkan WAL ke
max_slot_wal_keep_size 10 GB Batas atas untuk WAL yang tersisa untuk diproses oleh slot replikasi.
shared_buffers 4 GB Mengatur jumlah buffer memori bersama yang digunakan oleh server (25% memori simpul dalam contoh ini)
effective_cache_size 12 GB Mengatur asumsi perencana tentang ukuran total cache data
work_mem Seperempat ratus dua puluh enam dari total memori node Mengatur memori maksimum yang akan digunakan untuk ruang kerja kueri
maintenance_work_mem 6,25% memori simpul Mengatur memori maksimum yang akan digunakan untuk operasi pemeliharaan
autovacuum_vacuum_cost_limit 2400 Jumlah biaya vakum yang tersedia sebelum tidur siang, untuk autovacuum
random_page_cost 1.1 Mengatur perkiraan perencana tentang biaya halaman disk yang tidak diambil secara berurut
effective_io_concurrency 64 Mengatur berapa banyak permintaan simultan yang dapat ditangani subsistem disk secara efisien
maintenance_io_concurrency 64 Varian dari "effective_io_concurrency" yang digunakan untuk tugas pemeliharaan

Menyebarkan PostgreSQL

  1. Sebarkan kluster PostgreSQL dengan Cluster CRD menggunakan kubectl apply perintah .

    cat <<EOF | kubectl apply --context $AKS_PRIMARY_CLUSTER_NAME -n $PG_NAMESPACE -v 9 -f -
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: $PG_PRIMARY_CLUSTER_NAME
  annotations:
    alpha.cnpg.io/failoverQuorum: "true"
spec:
  imageName: ghcr.io/cloudnative-pg/postgresql:18-system-trixie
  inheritedMetadata:
    annotations:
      service.beta.kubernetes.io/azure-dns-label-name: $AKS_PRIMARY_CLUSTER_PG_DNSPREFIX
    labels:
      azure.workload.identity/use: "true"

  instances: 3
  smartShutdownTimeout: 30

  probes:
    startup:
      type: streaming
      maximumLag: 32Mi
      periodSeconds: 5
      timeoutSeconds: 3
      failureThreshold: 120
    readiness:
      type: streaming
      maximumLag: 0
      periodSeconds: 10
      failureThreshold: 6

  topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: topology.kubernetes.io/zone
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        cnpg.io/cluster: $PG_PRIMARY_CLUSTER_NAME

  affinity:
    nodeSelector:
      workload: postgres

  resources:
    requests:
      memory: '8Gi'
      cpu: 2
    limits:
      memory: '8Gi'
      cpu: 2

  bootstrap:
    initdb:
      database: appdb
      owner: app
      secret:
        name: db-user-pass
      dataChecksums: true

  storage:
    storageClass: $POSTGRES_STORAGE_CLASS
    size: 64Gi

  postgresql:
    synchronous:
      method: any
      number: 1
    parameters:
      wal_compression: lz4
      max_wal_size: 6GB
      max_slot_wal_keep_size: 10GB
      checkpoint_timeout: 15min
      checkpoint_completion_target: '0.9'
      checkpoint_flush_after: 2MB
      wal_writer_flush_after: 2MB
      min_wal_size: 2GB
      shared_buffers: 4GB
      effective_cache_size: 12GB
      work_mem: 62MB
      maintenance_work_mem: 1GB
      autovacuum_vacuum_cost_limit: "2400"
      random_page_cost: "1.1"
      effective_io_concurrency: "64"
      maintenance_io_concurrency: "64"
      log_checkpoints: 'on'
      log_lock_waits: 'on'
      log_min_duration_statement: '1000'
      log_statement: 'ddl'
      log_temp_files: '1024'
      log_autovacuum_min_duration: '1s'
      pg_stat_statements.max: '10000'
      pg_stat_statements.track: 'all'
      hot_standby_feedback: 'on'
    pg_hba:
      - host all all all scram-sha-256

  serviceAccountTemplate:
    metadata:
      annotations:
        azure.workload.identity/client-id: "$AKS_UAMI_WORKLOAD_CLIENTID"
      labels:
        azure.workload.identity/use: "true"

  backup:
    barmanObjectStore:
      destinationPath: "https://${PG_PRIMARY_STORAGE_ACCOUNT_NAME}.blob.core.windows.net/backups"
      azureCredentials:
        inheritFromAzureAD: true
    retentionPolicy: '7d'
EOF

Nota

Manifes sampel menggunakan ghcr.io/cloudnative-pg/postgresql:18-system-trixie image karena bekerja dengan integrasi inti Barman Cloud yang akan ditunjukkan kemudian. Ketika Anda siap untuk beralih ke plugin Barman Cloud, perbarui spec.imageName ke ghcr.io/cloudnative-pg/postgresql:18-standard-trixie dan ikuti panduan konfigurasi plugin sebelum menyebarkan ulang kluster.

Important

Entri contoh pg_hba memungkinkan akses non-TLS. Jika Anda menyimpan konfigurasi ini, dokumentasikan implikasi keamanan untuk tim Anda dan lebih suka koneksi terenkripsi sedapat mungkin.

  1. Validasi bahwa kluster PostgreSQL utama berhasil dibuat menggunakan kubectl get perintah . CRD Kluster CNPG menetapkan tiga instans, yang dapat divalidasi dengan melihat pod yang sedang berjalan setelah setiap instans dijalankan dan bergabung untuk replikasi. Bersabarlah karena dapat memakan waktu bagi ketiga instans untuk online dan bergabung dengan kluster.

    kubectl get pods --context $AKS_PRIMARY_CLUSTER_NAME --namespace $PG_NAMESPACE -l cnpg.io/cluster=$PG_PRIMARY_CLUSTER_NAME

    Contoh output

    NAME                         READY   STATUS    RESTARTS   AGE
pg-primary-cnpg-r8c7unrw-1   1/1     Running   0          4m25s
pg-primary-cnpg-r8c7unrw-2   1/1     Running   0          3m33s
pg-primary-cnpg-r8c7unrw-3   1/1     Running   0          2m49s

Important

Jika Anda menggunakan NVMe lokal dengan Azure Container Storage dan pod tetap dalam status init dengan kesalahan multi-attach, pod masih mencoba mencari volume pada node yang telah hilang. Pod memasuki status CrashLoopBackOff setelah mulai berjalan karena CNPG membuat replika baru pada simpul baru tanpa data dan direktori pgdata tidak ditemukan. Untuk mengatasi masalah ini, hancurkan instans yang terpengaruh dan munculkan yang baru. Jalankan perintah berikut:

kubectl cnpg destroy [cnpg-cluster-name] [instance-number]

Pastikan PodMonitor Prometheus sedang berjalan

PodMonitor yang dibuat secara manual mengikat konfigurasi kube-prometheus-stack scrape ke pod CNPG yang Anda sebarkan sebelumnya.

Memastikan PodMonitor berjalan menggunakan perintah kubectl get.

kubectl --namespace $PG_NAMESPACE \
    --context $AKS_PRIMARY_CLUSTER_NAME \
    get podmonitors.monitoring.coreos.com \
    $PG_PRIMARY_CLUSTER_NAME \
    --output yaml

Contoh output

kind: PodMonitor
metadata:
  labels:
    cnpg.io/cluster: pg-primary-cnpg-r8c7unrw
  name: pg-primary-cnpg-r8c7unrw
  namespace: cnpg-database
spec:
  podMetricsEndpoints:
  - port: metrics
  selector:
    matchLabels:
      cnpg.io/cluster: pg-primary-cnpg-r8c7unrw

Jika Anda menggunakan Azure Monitor untuk Prometheus Terkelola, Anda perlu menambahkan monitor pod lain dengan menggunakan nama grup khusus. Prometheus terkelola tidak mengambil definisi sumber daya kustom (CRD) dari komunitas Prometheus. Selain nama grup, CRD-nya sama. Desain tersebut memungkinkan monitor pod untuk Managed Prometheus beroperasi bersama monitor pod yang menggunakan CRD komunitas. Jika Anda tidak menggunakan Prometheus Terkelola, Anda dapat melewati bagian ini. Buat monitor pod baru:

cat <<EOF | kubectl apply --context $AKS_PRIMARY_CLUSTER_NAME --namespace $PG_NAMESPACE -f -
apiVersion: azmonitoring.coreos.com/v1
kind: PodMonitor
metadata:
  name: cnpg-cluster-metrics-managed-prometheus
  namespace: ${PG_NAMESPACE}
  labels:
    azure.workload.identity/use: "true"
    cnpg.io/cluster: ${PG_PRIMARY_CLUSTER_NAME}
spec:
  selector:
    matchLabels:
      azure.workload.identity/use: "true"
      cnpg.io/cluster: ${PG_PRIMARY_CLUSTER_NAME}
  podMetricsEndpoints:
    - port: metrics
EOF

Verifikasi bahwa monitor pod dibuat (perhatikan perbedaan pada nama grup).

kubectl --namespace $PG_NAMESPACE \
    --context $AKS_PRIMARY_CLUSTER_NAME \
    get podmonitors.azmonitoring.coreos.com \
    -l cnpg.io/cluster=$PG_PRIMARY_CLUSTER_NAME \
    -o yaml

Opsi A - Ruang kerja Azure Monitor

Setelah menyebarkan kluster Postgres dan monitor pod, Anda dapat melihat metrik menggunakan portal Microsoft Azure di ruang kerja Azure Monitor.

Cuplikan layar memperlihatkan metrik kluster Postgres di ruang kerja Azure Monitor di portal Microsoft Azure.

Opsi B - Grafana Terkelola

Atau, setelah menyebarkan kluster Postgres dan monitor pod, Anda dapat membuat dasbor metrik pada instans Grafana Terkelola yang dibuat oleh skrip penyebaran untuk memvisualisasikan metrik yang diekspor ke ruang kerja Azure Monitor. Anda dapat mengakses Managed Grafana melalui portal Azure. Navigasi ke instans Grafana Terkelola yang dibuat oleh skrip penyebaran dan pilih tautan Titik Akhir seperti yang ditunjukkan di sini:

Cuplikan layar metrik kluster Postgres dalam instans Azure Managed Grafana di portal Microsoft Azure.

Memilih tautan Titik Akhir akan membuka jendela browser baru tempat Anda dapat membuat dasbor pada instans Grafana Terkelola. Mengikuti instruksi untuk mengonfigurasi sumber data Azure Monitor, Anda kemudian dapat menambahkan visualisasi untuk membuat dasbor metrik dari kluster Postgres. Setelah menyiapkan koneksi sumber data, dari menu utama, pilih opsi Sumber data. Anda akan melihat sekumpulan opsi sumber data untuk koneksi sumber data seperti yang ditunjukkan di sini:

Cuplikan layar memperlihatkan opsi sumber data Azure Monitor di portal Microsoft Azure.

Pada opsi Prometheus Terkelola, pilih opsi untuk membangun dasbor untuk membuka editor dasbor. Setelah jendela editor terbuka, pilih opsi Tambahkan visualisasi lalu pilih opsi Prometheus Terkelola untuk menelusuri metrik dari kluster Postgres. Setelah Anda memilih metrik yang ingin Anda visualisasikan, pilih tombol Jalankan kueri untuk mengambil data untuk visualisasi seperti yang diperlihatkan di sini:

Cuplikan layar memperlihatkan dasbor Prometheus Terkelola dengan metrik kluster Postgres.

Pilih ikon Simpan untuk menambahkan panel ke dasbor Anda. Anda dapat menambahkan panel lain dengan memilih tombol Tambahkan di editor dasbor dan mengulangi proses ini untuk memvisualisasikan metrik lain. Menambahkan visualisasi metrik, Anda harus memiliki sesuatu yang terlihat seperti ini:

Cuplikan layar memperlihatkan dasbor Prometheus Terkelola yang disimpan di portal Microsoft Azure.

Pilih ikon Simpan untuk menyimpan dasbor Anda.

Langkah selanjutnya

Menguji dan memvalidasi PostgreSQL

Contributors

Microsoft mempertahankan artikel ini. Kontributor berikut awalnya menulisnya:

  • Ken Kilty | TPM Utama
  • Russell de Pina | TPM Utama
  • Adrian Joian | Insinyur Pelanggan Senior
  • Jenny Hayes | Pengembang Konten Senior
  • Carol Smith | Pengembang Konten Senior
  • Erin Schaffer | Pengembang Konten 2
  • Adam Sharif | Teknisi Pelanggan 2

Pengakuan

Dokumentasi ini dikembangkan bersama dengan EnterpriseDB, pengurus operator CloudNativePG. Kami berterima kasih kepada Gabriele Bartolini yang telah meninjau draf sebelumnya dari dokumen ini dan menawarkan peningkatan teknis.

  • Terakhir diperbarui pada