Delen via

Een maximaal beschikbare PostgreSQL-database implementeren in Azure Kubernetes Service (AKS)

In dit artikel implementeert u een maximaal beschikbare PostgreSQL-database op AKS.

Important

Opensource-software wordt vermeld in AKS-documentatie en -voorbeelden. Software die u implementeert, is uitgesloten van AKS-serviceovereenkomsten, beperkte garantie en ondersteuning voor Azure. Wanneer u opensource-technologie naast AKS gebruikt, raadpleegt u de beschikbare ondersteuningsopties van de respectieve community's en projectonderhouders om een plan te ontwikkelen.

Microsoft neemt de verantwoordelijkheid voor het bouwen van de opensource-pakketten die we implementeren op AKS. Deze verantwoordelijkheid omvat het volledige eigendom van het bouw-, scan-, onderteken-, validatie- en hotfixproces, samen met controle over de binaire bestanden in container images. Zie Beveiligingsbeheer voor AKS- en AKS-ondersteuningsdekking voor meer informatie.

Geheim maken voor bootstrap-app-gebruiker

  1. Genereer een geheim om de PostgreSQL-implementatie te valideren door interactieve aanmelding voor een bootstrap-app-gebruiker met behulp van de kubectl create secret opdracht.

Important

Microsoft raadt u aan de veiligste verificatiestroom te gebruiken die beschikbaar is. De verificatiestroom die in deze procedure wordt beschreven, vereist een hoge mate van vertrouwen in de toepassing en draagt risico's die niet aanwezig zijn in andere stromen. U moet deze stroom alleen gebruiken wanneer andere veiligere stromen, zoals beheerde identiteiten, niet haalbaar zijn.

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. Controleer of het geheim is gemaakt met behulp van de kubectl get opdracht.

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

Omgevingsvariabelen instellen voor het PostgreSQL-cluster

  • Implementeer een ConfigMap om de CNPG-operator te configureren met behulp van de volgende kubectl apply opdracht. Deze waarden vervangen de verouderde ENABLE_AZURE_PVC_UPDATES schakelaar, die niet meer vereist is, en helpen bij het gefaseerd uitvoeren van upgrades en het versnellen van het verbindingsherstel van replica's. Voordat u deze configuratie in productie gaat implementeren, moet u controleren of alle bestaande DRAIN_TAINTS instellingen die u vertrouwt compatibel blijven met uw Azure-omgeving.

    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

De Prometheus PodMonitors installeren

Prometheus scrapet CNPG met behulp van de opnameregels die zijn opgeslagen in de CNPG GitHub-voorbeelden opslagplaats. Omdat de door de operator beheerde PodMonitor wordt afgeschaft, maakt en beheert u de PodMonitor-resource zelf, zodat u deze kunt aanpassen aan uw bewakingsstack.

  1. Voeg de Prometheus Community Helm-opslagplaats toe met de helm repo add opdracht.

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

  2. Werk de Prometheus Community Helm-opslagplaats bij en installeer deze op het primaire cluster met behulp van de helm upgrade opdracht met de --install vlag.

    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. Maak een PodMonitor voor het cluster. Het CNPG-team beëindigt de door de operator beheerde PodMonitor, zodat u het nu rechtstreeks beheert:

    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

Een federatieve inloggegevens maken

In deze sectie maakt u een federatieve identiteitsreferentie voor PostgreSQL-back-up, zodat CNPG AKS-workloadidentiteit kan gebruiken om te verifiëren bij de bestemming van het opslagaccount voor back-ups. De CNPG-operator maakt een Kubernetes-serviceaccount met dezelfde naam als het cluster dat wordt gebruikt in het CNPG-clusterimplementatiemanifest.

  1. Haal de URL van de OIDC-verlener van het cluster op met behulp van de az aks show opdracht.

    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. Maak een federatieve identiteitsreferentie met behulp van de az identity federated-credential create opdracht.

    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

Een postgreSQL-cluster met hoge beschikbaarheid implementeren

In deze sectie implementeert u een PostgreSQL-cluster met hoge beschikbaarheid met behulp van de CNPG Cluster Custom Resource Definition (CRD).

CRD-parameters voor cluster

De volgende tabel bevat een overzicht van de belangrijkste eigenschappen die zijn ingesteld in het YAML-implementatiemanifest voor de CLUSTER CRD:

Property Definition
imageName Verwijst naar de container image van de CloudNativePG-operand. Gebruik ghcr.io/cloudnative-pg/postgresql:18-system-trixie met de in-core back-upintegratie zoals weergegeven in deze handleiding, of schakel over naar 18-standard-trixie wanneer u de Barman Cloud-invoegtoepassing adopteert.
inheritedMetadata Specifiek voor de CNPG-operator. De CNPG-operator past de metagegevens toe op elk object dat is gerelateerd aan het cluster.
annotations Bevat het DNS-label dat is vereist bij het beschikbaar maken van de clustereindpunten en het inschakelen alpha.cnpg.io/failoverQuorum van failover op basis van quorums.
labels: azure.workload.identity/use: "true" Geeft aan dat AKS workloadidentiteitsafhankelijkheden moet injecteren in de pods die als host fungeren voor de PostgreSQL-clusterinstanties.
topologySpreadConstraints Verschillende zones en verschillende knooppunten met label "workload=postgres"vereisen.
resources Hiermee configureert u een QoS-klasse (Quality of Service) van Gegarandeerd. In een productieomgeving zijn deze waarden essentieel voor het maximaliseren van het gebruik van de onderliggende knooppunt-VM en variëren op basis van de gebruikte Azure VM-SKU.
probes Vervangt de verouderde startDelay configuratie. Streaming-opstart- en gereedheidstests helpen ervoor te zorgen dat replica's in orde zijn voordat verkeer wordt geleverd.
smartShutdownTimeout Hiermee kunnen langlopende transacties correct worden voltooid tijdens updates in plaats van agressieve stopvertragingen te gebruiken.
bootstrap Specifiek voor de CNPG-operator. Initialiseert met een lege app-database.
storage Hiermee worden de PersistentVolume-instellingen voor de database gedefinieerd. Met beheerde Azure-schijven bewaart de vereenvoudigde syntaxis gegevens en WAL op hetzelfde 64 GiB-volume, dat betere doorvoerlagen op beheerde schijven biedt. Pas aan als u afzonderlijke WAL-volumes nodig hebt.
postgresql.synchronous minSyncReplicas / maxSyncReplicas Hiermee kunt u synchrone replicatiegedrag opgeven met behulp van het nieuwere schema.
postgresql.parameters Specifiek voor de CNPG-operator. Kaartinstellingen voor postgresql.conf, pg_hba.confen pg_ident.conf. Het voorbeeld benadrukt waarneembaarheid en standaardinstellingen voor WAL-retentie die passen bij het identiteitsscenario van de AKS-werklast, maar moeten per werklast worden afgestemd.
serviceAccountTemplate Bevat de sjabloon die nodig is voor het genereren van de serviceaccounts en wijst de federatieve AKS-identiteitsreferenties toe aan de UAMI om AKS-workloadidentiteitsverificatie in te schakelen van de pods die als host fungeren voor de PostgreSQL-exemplaren naar externe Azure-resources.
barmanObjectStore Specifiek voor de CNPG-operator. Hiermee configureert u de barman-cloud tool suite met behulp van de AKS-workloadidentiteit voor verificatie bij de Azure Blob Storage-objectopslag.

Als u PostgreSQL-workloads verder wilt isoleren, kunt u een taint (bijvoorbeeld node-role.kubernetes.io/postgres=:NoSchedule) toevoegen aan uw gegevensvlakknooppunten en het voorbeeld nodeSelector/tolerations vervangen door de waarden die door CloudNativePG worden aanbevolen. Als u deze aanpak volgt, labelt u de knooppunten dienovereenkomstig en bevestigt u dat het AKS-beleid voor automatische schaalaanpassing overeenkomt met uw topologie.

PostgreSQL-prestatieparameters

De prestaties van PostgreSQL zijn sterk afhankelijk van de onderliggende resources en workload van uw cluster. De volgende tabel bevat basislijnrichtlijnen voor een cluster met drie knooppunten dat wordt uitgevoerd op Standard D4s v3-knooppunten (16-GiB-geheugen). Behandel deze waarden als uitgangspunt en pas deze aan wanneer u uw workloadprofiel begrijpt:

Property Aanbevolen waarde Definition
wal_compression lz4 Comprimeert volledige pagina's geschreven in een WAL-bestand met een specifieke methode
max_wal_size 6 GB Hiermee stelt u de WAL-grootte in waarmee een controlepunt wordt geactiveerd
checkpoint_timeout 15 minuten Hiermee stelt u de maximale tijd in tussen automatische WAL-controlepunten
checkpoint_completion_target 0,9 Hiermee wordt het werk van het controlepunt verdeeld over het controlepuntvenster
checkpoint_flush_after 2 MB Aantal pagina's waarna eerder uitgevoerde schrijfbewerkingen naar schijf worden leeggemaakt
wal_writer_flush_after 2 MB Hoeveelheid WAL die is uitgeschreven door de WAL writer die een flush activeert
min_wal_size 2 GB Hiermee stelt u de minimale grootte in waarop de WAL wordt verkleind.
max_slot_wal_keep_size 10 GB Bovengrens voor WAL voor overblijvende replicatiesleuven
shared_buffers 4 GB Hiermee stelt u het aantal gedeelde geheugenbuffers in dat wordt gebruikt door de server (25% van het knooppuntgeheugen in dit voorbeeld)
effective_cache_size 12 GB Stelt de aanname van de planner in over de totale grootte van de gegevenscaches
work_mem 1/256e van het knooppuntgeheugen Hiermee stelt u het maximale geheugen in dat moet worden gebruikt voor querywerkruimten
maintenance_work_mem 6.25% van knooppuntgeheugen Hiermee stelt u het maximale geheugen in dat moet worden gebruikt voor onderhoudsbewerkingen
autovacuum_vacuum_cost_limit 2400 Hoeveelheid vacuümkosten beschikbaar voor napping, voor autovacuum
random_page_cost 1.1 Hiermee stelt u de schatting van de planner in van de kosten van een niet-opeenvolgend opgehaalde schijfpagina
effective_io_concurrency 64 Hiermee stelt u in hoeveel gelijktijdige aanvragen het schijfsubsysteem efficiënt kan verwerken
maintenance_io_concurrency 64 Een variant van 'effective_io_concurrency' die wordt gebruikt voor onderhoudswerkzaamheden

PostgreSQL implementeren

  1. Implementeer het PostgreSQL-cluster met cluster CRD met behulp van de kubectl apply opdracht.

    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

Opmerking

Het voorbeeldmanifest maakt gebruik van de ghcr.io/cloudnative-pg/postgresql:18-system-trixie afbeelding omdat deze werkt met de in-core Barman Cloud-integratie die later wordt weergegeven. Wanneer u klaar bent om over te schakelen naar de Barman Cloud-invoegtoepassing, moet u de spec.imageName voor de invoegtoepassing bijwerken ghcr.io/cloudnative-pg/postgresql:18-standard-trixie en volgen voordat u het cluster opnieuw implementeert.

Important

De voorbeeldvermelding pg_hba staat niet-TLS-toegang toe. Als u deze configuratie behoudt, documenteert u de gevolgen voor de beveiliging van uw team en geeft u waar mogelijk de voorkeur aan versleutelde verbindingen.

  1. Controleer of het primaire PostgreSQL-cluster is gemaakt met behulp van de kubectl get opdracht. Het CNPG-cluster CRD heeft drie exemplaren opgegeven, die kunnen worden gevalideerd door actieve pods weer te geven zodra elk exemplaar wordt opgehaald en toegevoegd voor replicatie. Wees geduldig omdat het enige tijd kan duren voordat alle drie de exemplaren online zijn en deelnemen aan het cluster.

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

    Voorbeelduitvoer

    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

Als u lokale NVMe gebruikt met Azure Container Storage en een pod in de init-fase vastzit met een fout bij meerdere koppelingen, zoekt de pod nog steeds naar het volume op een verloren node. Nadat de pod wordt uitgevoerd, wordt er een CrashLoopBackOff status ingevoerd omdat CNPG een nieuwe replica maakt op een nieuw knooppunt zonder gegevens en de pgdata map niet kan vinden. U kunt dit probleem oplossen door het betrokken exemplaar te vernietigen en een nieuw exemplaar weer te geven. Voer de volgende opdracht uit:

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

Valideren dat Prometheus PodMonitor wordt uitgevoerd

De handmatig gemaakte PodMonitor koppelt de kube-prometheus-stack-scrape-configuratie aan de CNPG-pods die u eerder hebt geïmplementeerd.

Controleer of PodMonitor wordt uitgevoerd met behulp van de kubectl get opdracht.

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

Voorbeelduitvoer

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

Als u Azure Monitor voor Beheerde Prometheus gebruikt, moet u een extra podmonitor toevoegen met de aangepaste groepsnaam. Beheerde Prometheus haalt de aangepaste resourcedefinities (CRD's) niet op van de Prometheus-community. Afgezien van de groepsnaam zijn de CRD's hetzelfde. Met dit ontwerp kunnen podmonitors voor Beheerde Prometheus worden uitgevoerd naast podmonitors die gebruikmaken van de CRD van de community. Als u beheerde Prometheus niet gebruikt, kunt u deze sectie overslaan. Maak een nieuwe podmonitor:

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

Controleer of de podmonitor is gemaakt (let op het verschil in de groepsnaam).

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

Optie A - Azure Monitor-werkruimte

Nadat u het Postgres-cluster en de podmonitor hebt geïmplementeerd, kunt u de metrische gegevens bekijken met behulp van Azure Portal in een Azure Monitor-werkruimte.

Schermopname van metrische gegevens van Postgres-clusters in een Azure Monitor-werkruimte in Azure Portal.

Optie B - Beheerd Grafana

Nadat u het Postgres-cluster en de podmonitoren hebt geïmplementeerd, kunt u ook een dashboard met metrische gegevens maken op het beheerde Grafana-exemplaar dat door het implementatiescript is gemaakt om de metrische gegevens te visualiseren die zijn geëxporteerd naar de Azure Monitor-werkruimte. U hebt toegang tot managed Grafana via Azure Portal. Navigeer naar het beheerde Grafana-exemplaar dat is gemaakt door het implementatiescript en selecteer de koppeling Eindpunt, zoals hier wordt weergegeven:

Schermopname van metrische gegevens van Postgres-clusters in een azure Managed Grafana-exemplaar in Azure Portal.

Als u de koppeling Eindpunt selecteert, wordt een nieuw browservenster geopend waarin u dashboards kunt maken op het beheerde Grafana-exemplaar. Volg de instructies voor het configureren van een Azure Monitor-gegevensbron. Vervolgens kunt u visualisaties toevoegen om een dashboard met metrische gegevens te maken vanuit het Postgres-cluster. Nadat u de verbinding met de gegevensbron hebt ingesteld, selecteert u in het hoofdmenu de optie Gegevensbronnen. U ziet nu een set opties voor gegevensbronnen voor de gegevensbronverbinding, zoals hier wordt weergegeven:

Schermopname van opties voor Azure Monitor-gegevensbronnen in Azure Portal.

Selecteer in de optie Beheerde Prometheus de optie om een dashboard te maken om de dashboardeditor te openen. Nadat het editorvenster is geopend, selecteert u de optie Visualisatie toevoegen en selecteert u vervolgens de optie Beheerde Prometheus om door de metrische gegevens van het Postgres-cluster te bladeren. Nadat u de metrische gegevens hebt geselecteerd die u wilt visualiseren, selecteert u de knop Query's uitvoeren om de gegevens voor de visualisatie op te halen, zoals hier wordt weergegeven:

Schermopname van een beheerd Prometheus-dashboard met metrische gegevens van postgres-clusters.

Selecteer het pictogram Opslaan om het deelvenster toe te voegen aan uw dashboard. U kunt andere panelen toevoegen door de knop Toevoegen te selecteren in de dashboardeditor en dit proces te herhalen om andere metrische gegevens te visualiseren. Als u de visualisaties voor metrische gegevens toevoegt, moet u iets hebben dat er als volgt uitziet:

Schermopname van een opgeslagen beheerd Prometheus-dashboard in Azure Portal.

Selecteer het pictogram Opslaan om uw dashboard op te slaan.

Volgende stappen

PostgreSQL testen en valideren

Contributors

Microsoft onderhoudt dit artikel. De volgende inzenders hebben het oorspronkelijk geschreven:

  • Ken Kilty | Hoofd TPM
  • Russell de Pina | Principal TPM
  • Adrian Joian | Senior klanttechnicus
  • Jenny Hayes | Senior Content Developer
  • Carol Smith | Senior Content Developer
  • Erin Schaffer | Inhoudsontwikkelaar 2
  • Adam Sharif | Technisch Klantadviseur 2

Erkenning

Deze documentatie is gezamenlijk ontwikkeld met EnterpriseDB, de onderhouders van de CloudNativePG-operator. We danken Gabriele Bartolini voor het bekijken van eerdere concepten van dit document en het aanbieden van technische verbeteringen.

  • Last updated on