Валидация и тестирование развертывания базы данных PostgreSQL в службе Azure Kubernetes Service (AKS)

В этой статье описаны различные действия по тестированию и проверке базы данных PostgreSQL, развернутой в AKS. Это включает проверку развертывания, подключение к базе данных и отработку отказоустойчивости.

Если вы еще не развернули PostgreSQL, выполните действия, описанные в статье "Развертывание высокодоступной базы данных PostgreSQL в AKS с помощью Azure CLI " для настройки, а затем вы можете вернуться к этой статье.

Это важно

Программное обеспечение с открытым кодом упоминается во всей документации и примерах AKS. Развертываемое программное обеспечение исключается из соглашений об уровне обслуживания AKS, ограниченной гарантии и поддержки Azure. При использовании технологии с открытым исходным кодом вместе с AKS ознакомьтесь с вариантами поддержки, доступными от соответствующих сообществ и обслуживающих проектов для разработки плана.

Корпорация Майкрософт несет ответственность за создание пакетов с открытым кодом, которые мы развертываем в AKS. Эта ответственность включает полное управление процессами сборки, сканирования, подписывания, проверки и исправления ошибок, а также контроль над двоичными файлами в образах контейнеров. Для получения дополнительной информации см. разделы Управление уязвимостями в AKS и Поддержка AKS.

Проверка развернутого кластера PostgreSQL

Убедитесь, что PostgreSQL распространяется по нескольким зонам доступности, извлекая сведения о узле AKS с помощью kubectl get команды.

kubectl get nodes \
    --context $AKS_PRIMARY_CLUSTER_NAME \
    --namespace $PG_NAMESPACE \
    --output json | jq '.items[] | {node: .metadata.name, zone: .metadata.labels."failure-domain.beta.kubernetes.io/zone"}'

Выходные данные должны выглядеть примерно в следующем примере с зоной доступности, показанной для каждого узла:

{
    "node": "aks-postgres-15810965-vmss000000",
    "zone": "westus3-1"
}
{
    "node": "aks-postgres-15810965-vmss000001",
    "zone": "westus3-2"
}
{
    "node": "aks-postgres-15810965-vmss000002",
    "zone": "westus3-3"
}
{
    "node": "aks-systempool-26112968-vmss000000",
    "zone": "westus3-1"
}
{
    "node": "aks-systempool-26112968-vmss000001",
    "zone": "westus3-2"
}

Подключение к PostgreSQL и создание примера набора данных

В этом разделе вы создаете таблицу и вставляете некоторые данные в базу данных приложения, созданную в CRD кластера CNPG, развернутого ранее. Эти данные используются для проверки операций резервного копирования и восстановления для кластера PostgreSQL.

Создайте таблицу и вставьте данные в базу данных приложения с помощью следующих команд:

kubectl cnpg psql $PG_PRIMARY_CLUSTER_NAME --namespace $PG_NAMESPACE

-- Create a small dataset
CREATE TABLE datasample (id INTEGER, name VARCHAR(255));
INSERT INTO datasample (id, name) VALUES (1, 'John');
INSERT INTO datasample (id, name) VALUES (2, 'Jane');
INSERT INTO datasample (id, name) VALUES (3, 'Alice');
SELECT COUNT(*) FROM datasample;

Введите \q , чтобы завершить работу psql.

Выходные данные должны выглядеть примерно так:

CREATE TABLE
INSERT 0 1
INSERT 0 1
INSERT 0 1
count
-------
    3
(1 row)

Подключение к репликам PostgreSQL только для чтения

Подключитесь к репликам postgreSQL только для чтения и проверьте пример набора данных с помощью следующих команд:
```
kubectl cnpg psql --replica $PG_PRIMARY_CLUSTER_NAME --namespace $PG_NAMESPACE
```
```
SELECT pg_is_in_recovery();
```
Пример результата
```
pg_is_in_recovery
-------------------
t
(1 row)
```
```
SELECT COUNT(*) FROM datasample;
```
Пример результата
```
count
-------
  3
(1 row)
```

Настройка резервных копий PostgreSQL по запросу и по расписанию с помощью Barman

Примечание.

Ожидается, что CloudNativePG постепенно прекратит использование встроенной поддержки Barman Cloud в пользу подключаемого модуля Barman Cloud в предстоящем релизе 1.29. Шаги, описанные в этом руководстве, продолжают работать и сегодня, но рекомендуется планировать переход на плагин после его стабилизации.

Убедитесь, что кластер PostgreSQL может получить доступ к учетной записи хранения Azure, указанной в CRD кластера CNPG, и что Working WAL archiving отображает как OK с помощью следующей команды.

kubectl cnpg status $PG_PRIMARY_CLUSTER_NAME 1 \
    --context $AKS_PRIMARY_CLUSTER_NAME \
    --namespace $PG_NAMESPACE

Пример результата

Continuous Backup status
First Point of Recoverability:  Not Available
Working WAL archiving:          OK
WALs waiting to be archived:    0
Last Archived WAL:              00000001000000000000000A   @   2024-07-09T17:18:13.982859Z
Last Failed WAL:                -

Разверните резервную копию по запросу в службе хранилища Azure, использующей интеграцию удостоверений рабочей нагрузки AKS, с использованием файла YAML и команды kubectl apply.

export BACKUP_ONDEMAND_NAME="on-demand-backup-1"

cat <<EOF | kubectl apply --context $AKS_PRIMARY_CLUSTER_NAME --namespace $PG_NAMESPACE -v 9 -f -
apiVersion: postgresql.cnpg.io/v1
kind: Backup
metadata:
  name: $BACKUP_ONDEMAND_NAME
spec:
  method: barmanObjectStore
  cluster:
    name: $PG_PRIMARY_CLUSTER_NAME
EOF

Проверьте статус резервной копии по запросу с помощью команды kubectl describe.

kubectl describe backup $BACKUP_ONDEMAND_NAME \
    --context $AKS_PRIMARY_CLUSTER_NAME \
    --namespace $PG_NAMESPACE

Пример результата

Type    Reason     Age   From                   Message
 ----    ------     ----  ----                   -------
Normal  Starting   6s    cloudnative-pg-backup  Starting backup for cluster pg-primary-cnpg-r8c7unrw
Normal  Starting   5s    instance-manager       Backup started
Normal  Completed  1s    instance-manager       Backup completed

Убедитесь, что кластер имеет первую точку восстановления с помощью следующей команды:

kubectl cnpg status $PG_PRIMARY_CLUSTER_NAME 1 \
    --context $AKS_PRIMARY_CLUSTER_NAME \
    --namespace $PG_NAMESPACE

Пример результата

Continuous Backup status
First Point of Recoverability:  2024-06-05T13:47:18Z
Working WAL archiving:          OK

Настройте запланированное резервное копирование на каждый час в 15 минут с помощью YAML файла и команды kubectl apply.

export BACKUP_SCHEDULED_NAME="scheduled-backup-1"

cat <<EOF | kubectl apply --context $AKS_PRIMARY_CLUSTER_NAME --namespace $PG_NAMESPACE -v 9 -f -
apiVersion: postgresql.cnpg.io/v1
kind: ScheduledBackup
metadata:
  name: $BACKUP_SCHEDULED_NAME
spec:
  # Backup once per hour
  schedule: "0 15 * ? * *"
  backupOwnerReference: self
  cluster:
    name: $PG_PRIMARY_CLUSTER_NAME
EOF

Проверьте состояние запланированной резервной копии с помощью kubectl describe команды.
```
kubectl describe scheduledbackup $BACKUP_SCHEDULED_NAME \
    --context $AKS_PRIMARY_CLUSTER_NAME \
    --namespace $PG_NAMESPACE
```

С помощью команды az storage blob list просмотрите файлы резервной копии, хранящиеся в хранилище BLOB-объектов Azure для основного кластера.

az storage blob list \
    --account-name $PG_PRIMARY_STORAGE_ACCOUNT_NAME \
    --container-name backups \
    --query "[*].name" \
    --only-show-errors

Выходные данные должны выглядеть следующим образом: проверка резервного копирования выполнена успешно.

[
  "pg-primary-cnpg-r8c7unrw/base/20240605T134715/backup.info",
  "pg-primary-cnpg-r8c7unrw/base/20240605T134715/data.tar",
  "pg-primary-cnpg-r8c7unrw/wals/0000000100000000/000000010000000000000001",
  "pg-primary-cnpg-r8c7unrw/wals/0000000100000000/000000010000000000000002",
  "pg-primary-cnpg-r8c7unrw/wals/0000000100000000/000000010000000000000003",
  "pg-primary-cnpg-r8c7unrw/wals/0000000100000000/000000010000000000000003.00000028.backup",
  "pg-primary-cnpg-r8c7unrw/wals/0000000100000000/000000010000000000000004",
  "pg-primary-cnpg-r8c7unrw/wals/0000000100000000/000000010000000000000005",
  "pg-primary-cnpg-r8c7unrw/wals/0000000100000000/000000010000000000000005.00000028.backup",
  "pg-primary-cnpg-r8c7unrw/wals/0000000100000000/000000010000000000000006",
  "pg-primary-cnpg-r8c7unrw/wals/0000000100000000/000000010000000000000007",
  "pg-primary-cnpg-r8c7unrw/wals/0000000100000000/000000010000000000000008",
  "pg-primary-cnpg-r8c7unrw/wals/0000000100000000/000000010000000000000009"
]

Восстановление резервного копирования по запросу в новый кластер PostgreSQL

В этом разделе вы восстанавливаете резервную копию по запросу, которую ранее создали с помощью оператора CNPG, в новом экземпляре с использованием CRD кластера начальной загрузки. Для простоты используется один кластер экземпляров. Помните, что идентификация рабочей нагрузки AKS (через CNPG inheritFromAzureAD) обращается к файлам резервной копии и что имя кластера восстановления используется для создания новой учетной записи службы Kubernetes, относящаяся к кластеру восстановления.

Вы также создадите вторые федеративные учетные данные для сопоставления новой учетной записи службы восстановления кластера с существующим UAMI с ролью "Источник данных Blob-хранилища" для доступа к файлам резервной копии в Blob-хранилище.

Создайте второе федеративное удостоверение с помощью az identity federated-credential create команды.

export PG_PRIMARY_CLUSTER_NAME_RECOVERED="$PG_PRIMARY_CLUSTER_NAME-recovered-db"

az identity federated-credential create \
    --name $PG_PRIMARY_CLUSTER_NAME_RECOVERED \
    --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_RECOVERED}" \
    --audience api://AzureADTokenExchange

Восстановите резервную копию по запросу, используя Cluster CRD с командой kubectl apply.

cat <<EOF | kubectl apply --context $AKS_PRIMARY_CLUSTER_NAME --namespace $PG_NAMESPACE -v 9 -f -
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: $PG_PRIMARY_CLUSTER_NAME_RECOVERED
spec:

  inheritedMetadata:
    annotations:
      service.beta.kubernetes.io/azure-dns-label-name: $AKS_PRIMARY_CLUSTER_PG_DNSPREFIX
    labels:
      azure.workload.identity/use: "true"

  instances: 1

  affinity:
    nodeSelector:
      workload: postgres

  # Point to cluster backup created earlier and stored on Azure Blob Storage
  bootstrap:
    recovery:
      source: clusterBackup

  storage:
    size: 2Gi
    pvcTemplate:
      accessModes:
        - ReadWriteOnce
      resources:
        requests:
          storage: 2Gi
      storageClassName: managed-csi-premium
      volumeMode: Filesystem

  walStorage:
    size: 2Gi
    pvcTemplate:
      accessModes:
        - ReadWriteOnce
      resources:
        requests:
          storage: 2Gi
      storageClassName: managed-csi-premium
      volumeMode: Filesystem

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

  externalClusters:
    - name: clusterBackup
      barmanObjectStore:
        destinationPath: https://${PG_PRIMARY_STORAGE_ACCOUNT_NAME}.blob.core.windows.net/backups
        serverName: $PG_PRIMARY_CLUSTER_NAME
        azureCredentials:
          inheritFromAzureAD: true
        wal:
          maxParallel: 8
EOF

Подключитесь к восстановленному экземпляру, а затем убедитесь, что набор данных, созданный в исходном кластере, где выполнена полная резервная копия, находится при помощи следующей команды:
```
kubectl cnpg psql $PG_PRIMARY_CLUSTER_NAME_RECOVERED --namespace $PG_NAMESPACE
```
```
SELECT COUNT(*) FROM datasample;
```
Пример результата
```
 count
-------
     3
(1 row)

Type \q to exit psql
```

Удалите восстановленный кластер с помощью следующей команды:

kubectl cnpg destroy $PG_PRIMARY_CLUSTER_NAME_RECOVERED 1 \
    --context $AKS_PRIMARY_CLUSTER_NAME \
    --namespace $PG_NAMESPACE

Удалите учетные данные федеративной учетной записи с помощью команды az identity federated-credential delete.

az identity federated-credential delete \
    --name $PG_PRIMARY_CLUSTER_NAME_RECOVERED \
    --identity-name $AKS_UAMI_CLUSTER_IDENTITY_NAME \
    --resource-group $RESOURCE_GROUP_NAME \
    --yes

Открыть кластер PostgreSQL через публичный балансировщик нагрузки

В этом разделе вы настраиваете необходимую инфраструктуру для публичного предоставления конечных точек PostgreSQL для чтения и записи и только для чтения с ограничением по исходным IP-адресам на общедоступный IP-адрес вашей клиентской рабочей станции.

Вы также получите следующие конечные точки из службы IP-адресов кластера:

Одна основная конечная точка чтения и записи, которая заканчивается *-rw.
От нуля до N (в зависимости от числа реплик) конечные точки только для чтения, заканчивающиеся на *-ro.
Одна конечная точка репликации, которая заканчивается *-r.

Получите сведения о службе IP-адресов кластера с помощью команды kubectl get.
```
kubectl get services \
    --context $AKS_PRIMARY_CLUSTER_NAME \
    --namespace $PG_NAMESPACE \
    -l cnpg.io/cluster=$PG_PRIMARY_CLUSTER_NAME
```
Пример результата
```
NAME                          TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
pg-primary-cnpg-sryti1qf-r    ClusterIP   10.0.193.27    <none>        5432/TCP   3h57m
pg-primary-cnpg-sryti1qf-ro   ClusterIP   10.0.237.19    <none>        5432/TCP   3h57m
pg-primary-cnpg-sryti1qf-rw   ClusterIP   10.0.244.125   <none>        5432/TCP   3h57m
```
Примечание.

Существует три службы: namespace/cluster-name-ro сопоставлена с портом 5433, namespace/cluster-name-rw, и namespace/cluster-name-r сопоставлена с портом 5433. Важно избегать использования того же порта, что и узел чтения и записи кластера базы данных PostgreSQL. Если вы хотите, чтобы приложения получают доступ только к реплике базы данных PostgreSQL только для чтения, перенаправьте их на порт 5433. Окончательная служба обычно используется для резервного копирования данных, но также может функционировать как узел только для чтения.

Используйте команду kubectl get для получения сведений о службе.

export PG_PRIMARY_CLUSTER_RW_SERVICE=$(kubectl get services \
    --namespace $PG_NAMESPACE \
    --context $AKS_PRIMARY_CLUSTER_NAME \
    -l "cnpg.io/cluster" \
    --output json | jq -r '.items[] | select(.metadata.name | endswith("-rw")) | .metadata.name')

echo $PG_PRIMARY_CLUSTER_RW_SERVICE

export PG_PRIMARY_CLUSTER_RO_SERVICE=$(kubectl get services \
    --namespace $PG_NAMESPACE \
    --context $AKS_PRIMARY_CLUSTER_NAME \
    -l "cnpg.io/cluster" \
    --output json | jq -r '.items[] | select(.metadata.name | endswith("-ro")) | .metadata.name')

echo $PG_PRIMARY_CLUSTER_RO_SERVICE

Настройте службу балансировки нагрузки со следующими файлами YAML с помощью команды kubectl apply.

cat <<EOF | kubectl apply --context $AKS_PRIMARY_CLUSTER_NAME -f -
apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-resource-group: $AKS_PRIMARY_CLUSTER_NODERG_NAME
    service.beta.kubernetes.io/azure-pip-name: $AKS_PRIMARY_CLUSTER_PUBLICIP_NAME
    service.beta.kubernetes.io/azure-dns-label-name: $AKS_PRIMARY_CLUSTER_PG_DNSPREFIX
  name: cnpg-cluster-load-balancer-rw
  namespace: "${PG_NAMESPACE}"
spec:
  type: LoadBalancer
  ports:
  - protocol: TCP
    port: 5432
    targetPort: 5432
  selector:
    cnpg.io/instanceRole: primary
    cnpg.io/podRole: instance
  loadBalancerSourceRanges:
  - "$MY_PUBLIC_CLIENT_IP/32"
EOF

cat <<EOF | kubectl apply --context $AKS_PRIMARY_CLUSTER_NAME -f -
apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-resource-group: $AKS_PRIMARY_CLUSTER_NODERG_NAME
    service.beta.kubernetes.io/azure-pip-name: $AKS_PRIMARY_CLUSTER_PUBLICIP_NAME
    service.beta.kubernetes.io/azure-dns-label-name: $AKS_PRIMARY_CLUSTER_PG_DNSPREFIX
  name: cnpg-cluster-load-balancer-ro
  namespace: "${PG_NAMESPACE}"
spec:
  type: LoadBalancer
  ports:
  - protocol: TCP
    port: 5433
    targetPort: 5432
  selector:
    cnpg.io/instanceRole: replica
    cnpg.io/podRole: instance
  loadBalancerSourceRanges:
  - "$MY_PUBLIC_CLIENT_IP/32"
EOF

Используйте команду kubectl describe для получения сведений о службе.

kubectl describe service cnpg-cluster-load-balancer-rw \
    --context $AKS_PRIMARY_CLUSTER_NAME \
    --namespace $PG_NAMESPACE

kubectl describe service cnpg-cluster-load-balancer-ro \
    --context $AKS_PRIMARY_CLUSTER_NAME \
    --namespace $PG_NAMESPACE

export AKS_PRIMARY_CLUSTER_ALB_DNSNAME="$(az network public-ip show \
    --resource-group $AKS_PRIMARY_CLUSTER_NODERG_NAME \
    --name $AKS_PRIMARY_CLUSTER_PUBLICIP_NAME \
    --query "dnsSettings.fqdn" --output tsv)"

echo $AKS_PRIMARY_CLUSTER_ALB_DNSNAME

Проверка общедоступных конечных точек PostgreSQL

В этом разделе вы проверяете, что Azure Load Balancer правильно настроен с использованием статического IP-адреса, созданного ранее, и маршрутизирует подключения к основным репликам для чтения и записи, а также к репликам только для чтения. Затем используйте интерфейс командной строки psql для подключения к обоим.

Помните, что основная конечная точка чтения и записи сопоставляется с TCP-портом 5432, а конечные точки реплики только для чтения сопоставляются с портом 54333, чтобы разрешить использовать одно и то же DNS-имя PostgreSQL для чтения и записи.

Примечание.

Вам потребуется значение пароля пользователя приложения для базовой проверки подлинности PostgreSQL, созданной ранее и хранящейся в переменной $PG_DATABASE_APPUSER_SECRET среды.

Проверьте общедоступные конечные точки PostgreSQL с помощью следующих psql команд:
```
echo "Public endpoint for PostgreSQL cluster: $AKS_PRIMARY_CLUSTER_ALB_DNSNAME"

# Query the primary, pg_is_in_recovery = false

psql -h $AKS_PRIMARY_CLUSTER_ALB_DNSNAME \
    -p 5432 -U app -d appdb -W -c "SELECT pg_is_in_recovery();"
```
Пример результата
```
pg_is_in_recovery
-------------------
 f
(1 row)
```
```
echo "Query a replica, pg_is_in_recovery = true"

psql -h $AKS_PRIMARY_CLUSTER_ALB_DNSNAME \
    -p 5433 -U app -d appdb -W -c "SELECT pg_is_in_recovery();"
```
Пример результата
```
# Example output

pg_is_in_recovery
-------------------
t
(1 row)
```
При успешном подключении к основной конечной точке чтения и записи функция PostgreSQL возвращает значение ffalse, указывающее, что текущее подключение доступно для записи.

При подключении к реплике функция возвращает tзначение true, указывающее, что база данных находится в восстановлении и доступна только для чтения.

Имитация непланового переключения

В этом разделе вы инициируете внезапный сбой, удалив pod с основным процессом, что имитирует внезапное завершение работы или потерю сетевого подключения к узлу, на котором размещен основной сервер PostgreSQL.

Проверьте состояние запущенных экземпляров pod с помощью следующей команды:

kubectl cnpg status $PG_PRIMARY_CLUSTER_NAME --namespace $PG_NAMESPACE

Пример результата

Name                        Current LSN Rep role        Status  Node
--------------------------- ----------- --------        ------- -----------
pg-primary-cnpg-sryti1qf-1  0/9000060   Primary         OK      aks-postgres-32388626-vmss000000
pg-primary-cnpg-sryti1qf-2  0/9000060   Standby (sync)  OK      aks-postgres-32388626-vmss000001
pg-primary-cnpg-sryti1qf-3  0/9000060   Standby (sync)  OK      aks-postgres-32388626-vmss000002

Удалите основной pod с помощью команды kubectl delete.

PRIMARY_POD=$(kubectl get pod \
    --namespace $PG_NAMESPACE \
    --no-headers \
    -o custom-columns=":metadata.name" \
    -l role=primary)

kubectl delete pod $PRIMARY_POD --grace-period=1 --namespace $PG_NAMESPACE

Убедитесь, что pg-primary-cnpg-sryti1qf-2 экземпляр pod теперь является основным, используя следующую команду:

kubectl cnpg status $PG_PRIMARY_CLUSTER_NAME --namespace $PG_NAMESPACE

Пример результата

pg-primary-cnpg-sryti1qf-2  0/9000060   Primary         OK      aks-postgres-32388626-vmss000001
pg-primary-cnpg-sryti1qf-1  0/9000060   Standby (sync)  OK      aks-postgres-32388626-vmss000000
pg-primary-cnpg-sryti1qf-3  0/9000060   Standby (sync)  OK      aks-postgres-32388626-vmss000002

pg-primary-cnpg-sryti1qf-1 Сбросите экземпляр pod в качестве основного с помощью следующей команды:
```
kubectl cnpg promote $PG_PRIMARY_CLUSTER_NAME 1 --namespace $PG_NAMESPACE
```

Убедитесь, что экземпляры *pod* вернулись в исходное состояние перед тестом непланового резервного переключения с помощью следующей команды:

kubectl cnpg status $PG_PRIMARY_CLUSTER_NAME --namespace $PG_NAMESPACE

Пример результата

Name                        Current LSN Rep role        Status  Node
--------------------------- ----------- --------        ------- -----------
pg-primary-cnpg-sryti1qf-1  0/9000060   Primary         OK      aks-postgres-32388626-vmss000000
pg-primary-cnpg-sryti1qf-2  0/9000060   Standby (sync)  OK      aks-postgres-32388626-vmss000001
pg-primary-cnpg-sryti1qf-3  0/9000060   Standby (sync)  OK      aks-postgres-32388626-vmss000002

Очистка ресурсов

После завершения проверки развертывания удалите все ресурсы, созданные в этом руководстве, с помощью команды az group delete.
```
az group delete --resource-group $RESOURCE_GROUP_NAME --no-wait --yes
```

Дальнейшие действия

В этом руководстве вы узнали следующее:

Используйте Azure CLI для создания кластера AKS с несколькими зонами.
Разверните высокодоступный кластер PostgreSQL и базу данных с помощью оператора CNPG.
Настройте мониторинг для PostgreSQL с помощью Prometheus и Grafana.
Разверните пример набора данных в базе данных PostgreSQL.
Имитация прерывания кластера и отработка отказа реплики PostgreSQL.
Выполните резервное копирование и восстановление базы данных PostgreSQL.

Дополнительные сведения об использовании AKS для рабочих нагрузок см. в статье "Что такое служба Azure Kubernetes (AKS)? Дополнительные сведения о Базе данных Azure для PostgreSQL см. в статье "Что такое База данных Azure для PostgreSQL"?

Соавторы

Корпорация Майкрософт поддерживает эту статью. Первоначальная версия была написана следующими участниками:

Кен Килти | Ведущий TPM
Рассел де Пина | Главный технический менеджер программ
Адриан Джоан | Старший инженер клиента
Дженни Хейс | Старший разработчик содержимого
Кэрол Смит | Старший разработчик содержимого
Эрин Шаффер | Разработчик содержимого 2
Адам Шариф | Инженер клиента 2

Подтверждение

Эта документация была совместно разработана с EnterpriseDB, обслуживающим оператор CloudNativePG. Мы благодарим Габриэль Бартолини за просмотр предыдущих проектов этого документа и предложение технических улучшений.

Обратная связь

Были ли сведения на этой странице полезными?

Последнее обновление: 2025-06-18

Валидация и тестирование развертывания базы данных PostgreSQL в службе Azure Kubernetes Service (AKS)

Проверка развернутого кластера PostgreSQL

Подключение к PostgreSQL и создание примера набора данных

Подключение к репликам PostgreSQL только для чтения

Настройка резервных копий PostgreSQL по запросу и по расписанию с помощью Barman

Восстановление резервного копирования по запросу в новый кластер PostgreSQL

Открыть кластер PostgreSQL через публичный балансировщик нагрузки

Проверка общедоступных конечных точек PostgreSQL

Имитация непланового переключения

Очистка ресурсов

Дальнейшие действия

Соавторы

Подтверждение

Обратная связь

Дополнительные ресурсы