Sdílet prostřednictvím

Nasazení vysoce dostupné databáze PostgreSQL ve službě Azure Kubernetes Service (AKS)

V tomto článku nasadíte vysoce dostupnou databázi PostgreSQL v AKS.

Important

Opensourcový software je zmíněn v dokumentaci a ukázkách AKS. Software, který nasadíte, je vyloučený ze smluv o úrovni služeb AKS, omezené záruky a podpora Azure. Při používání opensourcových technologií společně s AKS se obraťte na možnosti podpory, které jsou k dispozici v příslušných komunitách a správci projektů, a vytvořte plán.

Microsoft zodpovídá za vytváření opensourcových balíčků, které nasazujeme v AKS. Tato odpovědnost zahrnuje úplné vlastnictví procesu sestavení, skenování, podepisování, ověřování a oprav hotfix, spolu s kontrolou nad binárními soubory v kontejnerových imagích. Další informace najdete v tématu Správa ohrožení zabezpečení pro AKS a Pokrytí podpory AKS.

Vytvoření tajného kódu pro uživatele aplikace bootstrap

  1. Vygenerujte tajný kód pro ověření nasazení PostgreSQL interaktivním přihlášením uživatele aplikace bootstrap pomocí kubectl create secret příkazu.

Important

Společnost Microsoft doporučuje používat nejbezpečnější dostupný způsob autentizace. Tok ověřování popsaný v tomto postupu vyžaduje vysokou míru důvěryhodnosti v aplikaci a nese rizika, která nejsou přítomna v jiných tocích. Tento tok byste měli použít jenom v případě, že jiné bezpečnější toky, jako jsou spravované identity, nejsou přijatelné.

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. Pomocí příkazu ověřte, že se tajný kód úspěšně vytvořil kubectl get .

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

Nastavení proměnných prostředí pro cluster PostgreSQL

  • Pomocí následujícího kubectl apply příkazu nasaďte objekt ConfigMap ke konfiguraci operátoru CNPG. Tyto hodnoty nahrazují starší ENABLE_AZURE_PVC_UPDATES přepínání, které již není nutné, a pomáhají strategicky plánovat upgrady a zrychlit opětovné připojení repliky. Před uvedením této konfigurace do produkčního prostředí ověřte, že všechna existující DRAIN_TAINTS nastavení, na která spoléháte, zůstanou kompatibilní s prostředím Azure.

    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

Instalace monitorů PodMonitors prometheus

Prometheus shromažďuje data z CNPG pomocí pravidel nahrávání uložených v úložišti ukázek na GitHubu CNPG. ** Vzhledem k tomu, že je PodMonitor spravovaný operátorem zastaralý, vytvořte a spravujte prostředek PodMonitor sami, abyste ho mohli přizpůsobit své monitorovací architektuře.

  1. Přidejte úložiště Prometheus Community Helm pomocí helm repo add příkazu.

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

  2. Aktualizujte úložiště Prometheus Community Helm a nainstalujte jej do primárního clusteru pomocí příkazu helm upgrade s příznakem --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. Vytvořte PodMonitor pro klastr. Tým CNPG upouští od PodMonitoru spravovaného operátorem, takže bude nyní přímo spravován vámi:

    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

Vytvořte federované přihlašovací údaje

V této části vytvoříte přihlašovací údaje federované identity pro zálohování PostgreSQL, které cnPG povolí použití identity úloh AKS k ověření v cíli účtu úložiště pro zálohy. Operátor CNPG vytvoří účet služby Kubernetes se stejným názvem jako cluster použitý v manifestu nasazení clusteru CNPG.

  1. Pomocí příkazu získejte adresu URL vystavitele OIDC clusteru 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. Pomocí příkazu az identity federated-credential create vytvořte přihlašovací údaje federované identity.

    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

Nasazení clusteru PostgreSQL s vysokou dostupností

V této části nasadíte vysoce dostupný cluster PostgreSQL pomocí vlastní definice prostředků clusteru CNPG (CRD).

Parametry CRD clusteru

Následující tabulka popisuje klíčové vlastnosti nastavené v manifestu nasazení YAML pro CRD clusteru:

Property Definition
imageName Odkazuje na kontejnerový obraz operandu CloudNativePG. Použijte ghcr.io/cloudnative-pg/postgresql:18-system-trixie s integrovanou integrací zálohování uvedenou v této příručce, nebo přepněte na 18-standard-trixie při použití pluginu Barman Cloud.
inheritedMetadata Specifické pro operátor CNPG. Operátor CNPG použije metadata pro každý objekt související s clusterem.
annotations Zahrnuje štítek DNS vyžadovaný při zveřejnění koncových bodů clusteru a umožňuje převzetí služeb při selhání na základě kvora pomocí alpha.cnpg.io/failoverQuorum.
labels: azure.workload.identity/use: "true" Označuje, že služba AKS by měla do podů hostující instance clusteru PostgreSQL vkládat závislosti identit úloh.
topologySpreadConstraints Vyžadovat různé zóny a různé uzly s označením "workload=postgres".
resources Nakonfiguruje třídu QoS (Quality of Service) zaručené. V produkčním prostředí jsou tyto hodnoty klíčem k maximalizaci využití základního virtuálního počítače uzlu a liší se podle použité skladové položky virtuálního počítače Azure.
probes Nahradí starší startDelay konfiguraci. Testy spouštění a připravenosti streamování pomáhají zajistit, že repliky jsou před obsluhou provozu v odpovídajícím stavu.
smartShutdownTimeout Umožňuje dlouhodobým transakcím dokončit se plynule během aktualizací namísto používání agresivních zastavení.
bootstrap Specifické pro operátor CNPG. Inicializuje prázdnou databázi aplikace.
storage Definuje nastavení PersistentVolume pro databázi. Díky spravovaným diskům Azure zůstávají data a WAL v rámci zjednodušené syntaxe na stejném 64-GiB svazku, což nabízí lepší úrovně propustnosti spravovaných disků. Upravte, pokud potřebujete samostatné svazky WAL.
postgresql.synchronous minSyncReplicas / maxSyncReplicas Nahrazuje a umožňuje určit chování synchronní replikace pomocí novějšího schématu.
postgresql.parameters Specifické pro operátor CNPG. Nastavení mapy pro postgresql.conf, pg_hba.confa pg_ident.conf. Ukázka zdůrazňuje pozorovatelnost a výchozí hodnoty uchovávání WAL, které vyhovují scénáři identit úloh AKS, ale měly by být vyladěné na každou úlohu.
serviceAccountTemplate Obsahuje šablonu potřebnou k vygenerování účtů služeb a mapuje přihlašovací údaje federované identity AKS na UAMI, aby se z podů hostících instance PostgreSQL umožnilo ověřování identity úloh AKS vůči externím prostředkům Azure.
barmanObjectStore Specifické pro operátor CNPG. Nakonfiguruje sadu nástrojů barman-cloud pomocí identity pracovního zatížení AKS pro ověřování v rámci úložiště objektů Azure Blob Storage.

Pokud chcete dále izolovat úlohy PostgreSQL, můžete do uzlů roviny dat přidat taint (například node-role.kubernetes.io/postgres=:NoSchedule) a nahradit ukázku nodeSelector/tolerations hodnotami doporučenými cloudNativePG. Pokud tento přístup uděláte, označte uzly odpovídajícím způsobem a potvrďte, že zásady automatického škálování AKS odpovídají vaší topologii.

Parametry výkonu PostgreSQL

Výkon PostgreSQL silně závisí na podkladových prostředcích a úlohách vašeho clusteru. Následující tabulka obsahuje základní pokyny pro cluster se třemi uzly běžící na uzlech Standard D4s v3 (paměť 16 GiB). Tyto hodnoty považujte za výchozí bod a upravte je, jakmile porozumíte svému profilu zátěže.

Property Doporučená hodnota Definition
wal_compression lz4 Komprimuje zápisy na celou stránku napsané v souboru WAL pomocí zadané metody.
max_wal_size 6 GB Nastaví velikost WAL, která aktivuje kontrolní bod.
checkpoint_timeout 15 min Nastaví maximální dobu mezi automatickými kontrolními body WAL.
checkpoint_completion_target 0,9 Vyrovnává práci kontrolního bodu v okně kontrolního bodu.
checkpoint_flush_after 2 MB Počet stránek, po kterých se dříve provedené zápisy vyprázdní na disk
wal_writer_flush_after 2 MB Množství WAL napsané zapisovačem WAL, který aktivuje vyprazdnutí
min_wal_size 2 GB Nastaví minimální velikost, na kterou lze zmenšit WAL
max_slot_wal_keep_size 10 GB Horní mez pro dostupné WAL pro obsluhu replikovaných slotů
shared_buffers 4 GB Nastaví počet vyrovnávacích pamětí sdílené paměti používané serverem (25% paměti uzlu v tomto příkladu).
effective_cache_size 12 GB Nastaví plánovačův předpoklad o celkové velikosti datových mezipamětí.
work_mem 1/256 z paměti uzlu Nastaví maximální paměť, která se má použít pro pracovní prostory dotazů.
maintenance_work_mem 6,25% paměti uzlu Nastaví maximální paměť, která se má použít pro operace údržby.
autovacuum_vacuum_cost_limit 2400 Objem nákladů na vysávání dostupný před pauzou, pro autovacuum
random_page_cost 1.1 Nastaví odhad plánovače na náklady nesekvenčního načtení diskové stránky.
effective_io_concurrency 64 Nastaví, kolik souběžných požadavků může diskový subsystém efektivně zpracovat.
maintenance_io_concurrency 64 Varianta "effective_io_concurrency", která se používá pro údržbářské práce

Nasazení PostgreSQL

  1. Nasaďte cluster PostgreSQL pomocí příkazu kubectl apply s využitím Cluster CRD.

    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

Poznámka:

Ukázkový manifest používá ghcr.io/cloudnative-pg/postgresql:18-system-trixie obraz, protože funguje s integrovanou Barman Cloud integrací, která je ukázaná později. Až budete připraveni přepnout na plug-in Barman Cloud, aktualizujte spec.imageName na ghcr.io/cloudnative-pg/postgresql:18-standard-trixie a před opětovným nasazením clusteru postupujte podle pokynů ke konfiguraci modulu plug-in.

Important

Příklad položky pg_hba umožňuje přístup bez TLS. Pokud tuto konfiguraci zachováte, zdokumentujte bezpečnostní důsledky pro váš tým a dejte přednost šifrovaným připojením, kdykoli je to možné.

  1. Pomocí příkazu ověřte, že se primární cluster PostgreSQL úspěšně vytvořil kubectl get . Cluster CNPG CRD zadal tři instance, které lze ověřit zobrazením spuštěných podů po spuštění každé instance a připojení k replikaci. Buďte trpěliví, protože může nějakou dobu trvat, než se všechny tři instance dostanou do režimu online a připojí se ke clusteru.

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

    Příklad výstupu

    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

Pokud používáte místní NVMe se službou Azure Container Storage a pod zůstane v inicializačním stavu s chybou vícenásobného připojení, pod stále hledá svazek na ztraceném uzlu. Po spuštění podu přejde do CrashLoopBackOff stavu, protože CNPG vytvoří novou repliku na novém uzlu bez dat a nemůže najít pgdata adresář. Pokud chcete tento problém vyřešit, odstraňte ovlivněnou instanci a vytvořte novou instanci. Spusťte následující příkaz:

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

Ověřte, že je spuštěný PodMonitor Prometheus.

Ručně vytvořený podMonitor propojuje konfiguraci výstřižku kube-prometheus-stack s pody CNPG, které jste nasadili dříve.

Pomocí příkazu kubectl get ověřte, že PodMonitor běží.

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

Příklad výstupu

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

Pokud používáte Azure Monitor pro spravovanou službu Prometheus, musíte přidat další monitorování podů pomocí názvu vlastní skupiny. Spravovaný Prometheus nezpracovává vlastní definice prostředků (CRD) z komunity Prometheus. Kromě názvu skupiny jsou identifikátory CRD stejné. Tento návrh umožňuje monitorování podů pro spravovaný Prometheus běžet společně s monitory podů, které používají CRD komunity. Pokud nepoužíváte Managed Prometheus, můžete tuto část přeskočit. Vytvořte nový monitor podu:

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

Ověřte, že je vytvořen sledovač podů (všimněte si rozdílu v názvu skupiny).

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

Možnost A – Pracovní prostor služby Azure Monitor

Po nasazení clusteru Postgres a monitorování podů můžete metriky zobrazit pomocí webu Azure Portal v pracovním prostoru služby Azure Monitor.

Snímek obrazovky zobrazující metriky clusteru Postgres v pracovním prostoru služby Azure Monitor na webu Azure Portal

Možnost B – Spravovaná Grafana

Případně můžete po nasazení clusteru Postgres a monitorování podů vytvořit řídicí panel metrik na spravované instanci Grafana vytvořené skriptem nasazení a vizualizovat metriky exportované do pracovního prostoru služby Azure Monitor. Ke spravované grafaně se dostanete přes Azure Portal. Přejděte na spravovanou instanci Grafana vytvořenou skriptem nasazení a vyberte odkaz na koncový bod, jak je znázorněno tady:

Snímek obrazovky s metrikami clusteru Postgres ve spravované instanci Grafany Azure na webu Azure Portal

Výběrem odkazu Koncový bod otevřete nové okno prohlížeče, ve kterém můžete vytvářet řídicí panely ve spravované instanci Grafana. Podle pokynů ke konfiguraci zdroje dat azure Monitoru pak můžete přidat vizualizace pro vytvoření řídicího panelu metrik z clusteru Postgres. Po nastavení připojení ke zdroji dat v hlavní nabídce vyberte možnost Zdroje dat. Měli byste vidět sadu možností zdroje dat pro připojení ke zdroji dat, jak je znázorněno tady:

Snímek obrazovky znázorňující možnosti zdroje dat Azure Monitoru na webu Azure Portal

V možnosti Managed Prometheus vyberte možnost pro vytvoření řídicího panelu pro otevření editoru řídicího panelu. Po otevření okna editoru vyberte možnost Přidat vizualizaci a pak vyberte možnost Managed Prometheus a procházejte metriky z clusteru Postgres. Po výběru metriky, kterou chcete vizualizovat, vyberte tlačítko Spustit dotazy a načtěte data pro vizualizaci, jak je znázorněno tady:

Snímek obrazovky zobrazující řídicí panel Spravovaného systému Prometheus s metrikami clusteru Postgres

Výběrem ikony Uložit přidáte panel na řídicí panel. Další panely můžete přidat výběrem tlačítka Přidat v editoru řídicího panelu a opakováním tohoto procesu vizualizovat další metriky. Přidáním vizualizací metrik byste měli mít něco, co vypadá takto:

Snímek obrazovky s uloženým řídicím panelem Managed Prometheus na webu Azure Portal

Výběrem ikony Uložit řídicí panel uložte.

Další kroky

Testování a ověření PostgreSQL

Contributors

Microsoft udržuje tento článek. Následující přispěvatelé ho původně napsali:

  • Ken Kilty | Hlavní technický manažer programu
  • Russell de Pina | Hlavní technický programový manažer
  • Adrian Joian | Vedoucí zákaznický inženýr
  • Jenny Hayes | Vedoucí vývojář obsahu
  • Carol Smith | Vedoucí vývojář obsahu
  • Erin Schaffer | Content Developer 2
  • Adam Sharif | Zákaznický inženýr 2

Uznání

Tato dokumentace byla společně vyvinuta s EnterpriseDB, správci operátoru CloudNativePG. Děkujeme Gabriele Bartolini za revizi dřívějších konceptů tohoto dokumentu a za nabízená technická vylepšení.

  • Last updated on