Mise à niveau du magasin de données d' Postgres sur Linux on Power ( ppc64le )

Modifier en ligne

Installez l'opérateur « Postgres » et configurez le magasin de données.

Avant de commencer

Modifier en ligne

Assurez-vous que vos serveurs en ligne et hors ligne sont configurés pour récupérer les images depuis le référentiel externe. Assurez-vous également que le dépôt Helm approprié a bien été ajouté.

Postgres versions des opérateurs et balises d'image

Modifier en ligne

Les images suivantes sont nécessaires pour le tableau « Helm » épinglé ou pour les versions destinées aux opérateurs.

CNPG Postgres

Modifier en ligne
Plateforme Versions de l'opérateur Version de graphique Helm Image avec balise
Linux® on Power® (ppc64le) v1.29.1 0.28.2

artifact-public.instana.io/self-hosted-images/3rd-party/operator/cloudnative-pg: v1.29.1_v0.34.0

artifact-public.instana.io/self-hosted-images/3rd-party/datastore/cnpg-containers: 15_v0.39.0

Zalando Postgres

Modifier en ligne
Plateforme Versions de l'opérateur Version de graphique Helm Image avec balise
Linux® on Power® (ppc64le) 1.10.0 v1.10.1 artifact-public.instana.io/self-hosted-images/3rd-party/operator/zalando: v1.10.0_v0.1.0 artifact-public.instana.io/self-hosted-images/3rd-party/datastore/zalando: 15.7_v0.1.0

Mise à jour d' Postgres. en ligne

Modifier en ligne

Mettez à niveau l'opérateur « Postgres » dans un environnement en ligne.

Mise à niveau d' Postgres à l'aide de l'opérateur « CloudNativePG »

Modifier en ligne

Suivez ces étapes pour mettre à niveau le magasin de données d' Postgres.

  1. Si vous effectuez une mise à niveau d' Postgres sur un cluster Red Hat® OpenShift®, identifiez l'ID de groupe du système de fichiers à partir de instana-postgres l'espace de noms. Red Hat OpenShift exige que les groupes du système de fichiers se situent dans une plage de valeurs propre à l'espace de noms.

    kubectl get namespace instana-postgres -o yaml

    La commande affiche un résultat similaire à l'exemple suivant :

    apiVersion: v1
kind: Namespace
metadata:
annotations:
  .......
  openshift.io/sa.scc.uid-range: 1000750000/10000
  creationTimestamp: "2024-01-14T07:04:59Z"
labels:
  kubernetes.io/metadata.name: instana-postgres
  .......
  name: instana-postgres

    L'annotation openshift.io/sa.scc.supplemental-groups contient la plage des identifiants autorisés. Cette plage 1000750000/10000 correspond à 10 000 valeurs commençant par l'identifiant 1000750000, elle spécifie donc la plage d'identifiants allant de 1000750000 à 1000760000. Dans cet exemple, cette valeur 1000750000 pourrait servir d'identifiant de groupe (UID) dans le système de fichiers.

  2. Mettre à niveau l'opérateur « Postgres ».

    helm upgrade --install cnpg instana/cloudnative-pg \
  --set image.repository=artifact-public.instana.io/self-hosted-images/3rd-party/operator/cloudnative-pg \
  --set image.tag=v1.29.1_v0.34.0 \
  --version=0.28.2 \
  --set imagePullSecrets[0].name=instana-registry \
  --set containerSecurityContext.runAsUser=<UID from namespace> \
  --set containerSecurityContext.runAsGroup=<UID from namespace> \
  -n instana-postgres

  3. Mettez à jour la ressource de cluster « Postgres » en appliquant le correctif suivant :

    kubectl patch cluster postgres -n instana-postgres --type=merge --patch '
spec:
  imageName: artifact-public.instana.io/self-hosted-images/3rd-party/datastore/cnpg-containers:15_v0.39.0
'

  4. Suivez les étapes décrites dans la section « Vérification d' Postgres » (en ligne et hors ligne).

Mise à niveau d' Postgres s à l'aide de l'opérateur « Zalando »

Modifier en ligne

Pour mettre à niveau l'opérateur en ligne Zalando Postgres, procédez comme suit :

  1. Créez un fichier, par exemple values.yaml, avec la configuration suivante : Postgres

    configGeneral:
  kubernetes_use_configmaps: true
securityContext:
  runAsUser: 101
image:
  registry: artifact-public.instana.io
  repository: self-hosted-images/3rd-party/operator/zalando
  tag: "v1.10.0_v0.1.0"
imagePullSecrets:
  - name: instana-registry
configKubernetes:
  pod_service_account_definition: |
    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: postgres-pod
    imagePullSecrets:
      - name: instana-registry
podServiceAccount:
  name: postgres-pod

  2. Mettre à niveau l'opérateur « Postgres ».

    helm upgrade --install postgres-operator instana/postgres-operator \
  --version=v1.10.1 \
  -f values.yaml \
  -n instana-postgres

  3. Mettez à jour la ressource de cluster « Postgres » en appliquant le correctif suivant :

    kubectl patch postgresql postgres -n instana-postgres --type=merge --patch '
spec:
  dockerImage: artifact-public.instana.io/self-hosted-images/3rd-party/datastore/zalando:15.7_v0.1.0
'

  4. Suivez les étapes décrites dans la section « Vérification d' Postgres » (en ligne et hors ligne).

Mise à niveau hors ligne d' Postgres

Modifier en ligne

Mettre à niveau l'opérateur « Postgres » dans un environnement isolé.

Mise à niveau hors ligne d' Postgres à l'aide de l'opérateur PG de l' CloudNative

Modifier en ligne

Si vous n'avez pas encore récupéré les images d' Postgres s à partir du registre externe, vous pouvez le faire maintenant. Exécutez les commandes suivantes sur votre hôte bastion. Ensuite, copiez les images sur votre serveur d' Instana, qui se trouve dans votre environnement isolé.

docker pull artifact-public.instana.io/self-hosted-images/3rd-party/operator/cloudnative-pg:v1.29.1_v0.34.0
docker pull artifact-public.instana.io/self-hosted-images/3rd-party/datastore/cnpg-containers:15_v0.39.0

Suivez les étapes suivantes sur votre serveur d' Instana.

  1. Réenregistrez les images dans votre registre d'images interne.

    docker tag artifact-public.instana.io/self-hosted-images/3rd-party/operator/cloudnative-pg:v1.29.1_v0.34.0 <internal-image-registry>/operator/cloudnative-pg:v1.29.1_v0.34.0
docker tag artifact-public.instana.io/self-hosted-images/3rd-party/datastore/cnpg-containers:15_v0.39.0 <internal-image-registry>/datastore/cnpg-containers:15_v0.39.0

  2. Envoyez les images vers votre référentiel d'images interne sur votre hôte bastion.

    docker push <internal-image-registry>/operator/cloudnative-pg:v1.29.1_v0.34.0
docker push <internal-image-registry>/datastore/cnpg-containers:15_v0.39.0

  3. Si vous effectuez une mise à niveau d' Postgres sur un cluster Red Hat® OpenShift®, identifiez l'ID de groupe du système de fichiers à partir de instana-postgres l'espace de noms. Red Hat OpenShift exige que les groupes du système de fichiers se situent dans une plage de valeurs propre à l'espace de noms.

    kubectl get namespace instana-postgres -o yaml

    La commande affiche un résultat similaire à l'exemple suivant :

    apiVersion: v1
kind: Namespace
metadata:
annotations:
  .......
  openshift.io/sa.scc.uid-range: 1000750000/10000
  creationTimestamp: "2024-01-14T07:04:59Z"
labels:
  kubernetes.io/metadata.name: instana-postgres
  .......
  name: instana-postgres

    L'annotation openshift.io/sa.scc.supplemental-groups contient la plage des identifiants autorisés. Cette plage 1000750000/10000 correspond à 10 000 valeurs commençant par l'identifiant 1000750000, elle spécifie donc la plage d'identifiants allant de 1000750000 à 1000760000. Dans cet exemple, cette valeur 1000750000 pourrait servir d'identifiant de groupe (UID) dans le système de fichiers.

  4. Mettre à niveau l'opérateur « Postgres ». Dans la commande suivante, remplacez la valeur <download_key> par votre propre clé d'agent. Si vous avez créé une clé secrète de récupération d'image pour votre registre interne, ajoutez-la --docker-server=<internal-image-registry>:<internal-image-registry-port> à la commande suivante.

    • Red Hat OpenShift groupe

      Utilisez l'UID obtenu à l'étape précédente comme paramètre <UID from namespace> dans les commandes suivantes :

      helm upgrade --install cnpg cloudnative-pg-1.28.0.tgz --set image.repository=<internal-image-registry>/instana-postgres/cloudnative-pg-operator -set image.tag=v1.29.1_v0.34.0 --version=0.28.2 --set containerSecurityContext.runAsUser=<UID from namespace> --set containerSecurityContext.runAsGroup=<UID from namespace> -n instana-postgres

    • Cluster Kubernetes

      helm upgrade --install cnpg cloudnative-pg-0.28.2.tgz --set image.repository=<internal-image-registry>/operator/cloudnative-pg --set image.tag=v1.29.1_v0.34.0 --version=0.28.2 -n instana-postgres

  5. Mettez à jour « Postgres » en exécutant la commande suivante pour appliquer un correctif à la ressource personnalisée « Postgres ».

    kubectl patch cluster postgres -n instana-postgres --type=merge --patch '
spec:
  imageName: <internal-image-registry>/self-hosted-images/3rd-party/datastore/cnpg-containers:15_v0.39.0
  '

  6. Suivez les étapes décrites dans la section « Vérification d' Postgres » (en ligne et hors ligne).

Mise à niveau hors ligne d' Postgres à l'aide de l'opérateur Zalando

Modifier en ligne

Si vous utilisez un cluster Red Hat OpenShift, créez des contraintes de contexte de sécurité avant de déployer l'opérateur Postgres.

  1. Mettez à jour le fichier ` YAML `, par exemple postgres-scc.yaml, en y ajoutant la définition de la ressource SCC.

    apiVersion: security.openshift.io/v1
kind: SecurityContextConstraints
metadata:
  name: postgres-scc
runAsUser:
  type: MustRunAs
  uid: 101
seLinuxContext:
  type: RunAsAny
fsGroup:
  type: RunAsAny
allowHostDirVolumePlugin: false
allowHostNetwork: true
allowHostPorts: true
allowPrivilegedContainer: false
allowHostIPC: true
allowHostPID: true
readOnlyRootFilesystem: false
users:
  - system:serviceaccount:instana-postgres:postgres-operator
  - system:serviceaccount:instana-postgres:postgres-pod
  - system:serviceaccount:instana-postgres:default

Poursuivez ensuite la mise à niveau de l'opérateur « Postgres ».

Si vous n'avez pas encore récupéré les images d' Postgres s à partir du registre externe, vous pouvez le faire maintenant. Exécutez les commandes suivantes sur votre hôte bastion. Ensuite, copiez les images sur votre serveur d' Instana, qui se trouve dans votre environnement isolé.

docker pull artifact-public.instana.io/self-hosted-images/3rd-party/operator/zalando:v1.10.0_v0.1.0
docker pull artifact-public.instana.io/self-hosted-images/3rd-party/datastore/zalando:15.7_v0.1.0

Suivez les étapes suivantes sur votre serveur d' Instana.

  1. Réenregistrez les images dans votre registre d'images interne.

    docker tag artifact-public.instana.io/self-hosted-images/3rd-party/operator/zalando:v1.10.0_v0.1.0 <internal-image-registry>/self-hosted-images/3rd-party/operator/zalando:v1.10.0_v0.1.0
docker tag artifact-public.instana.io/self-hosted-images/3rd-party/datastore/zalando:15.7_v0.1.0 <internal-image-registry>/self-hosted-images/3rd-party/datastore/zalando:15.7_v0.1.0

  2. Envoyez les images vers votre référentiel d'images interne sur votre hôte bastion.

    docker push <internal-image-registry>/self-hosted-images/3rd-party/operator/zalando:v1.10.0_v0.1.0
docker push <internal-image-registry>/self-hosted-images/3rd-party/datastore/zalando:15.7_v0.1.0

  3. Modifiez le fichier ` YAML `, par exemple values.yaml, en utilisant la configuration ` Postgres `.

    configGeneral:
kubernetes_use_configmaps: true
securityContext:
runAsUser: 101
image:
registry: <internal-image-registry>
repository: self-hosted-images/3rd-party/operator/zalando
tag: "v1.10.0_v0.1.0" 
imagePullSecrets:
- name: instana-registry
configKubernetes:
pod_service_account_definition: |
 apiVersion: v1
 kind: ServiceAccount
 metadata:
   name: postgres-pod
 imagePullSecrets:
   - name: instana-registry
podServiceAccount:
name: postgres-pod

  4. Mettre à niveau l'opérateur « Postgres ». Si vous avez créé une clé secrète de récupération d'image à l'étape précédente, ajoutez-la --set imagePullSecrets[0].name="<internal-image-registry-pull-secret>" à la commande suivante.

    helm upgrade --install postgres-operator postgres-operator-ppc64le-1.10.0.tgz \
  --version=1.10.0 \
  --set configGeneral.kubernetes_use_configmaps=true \
  --set securityContext.runAsUser=101 \
  --namespace=instana-postgres \
  --set image.registry=<internal-image-registry> \
  --set image.repository=ppc64le-oss/postgres-operator-ppc64le \
  --set image.tag=v1.10.0_v0.1.0

  5. Mettez à jour « Postgres » en exécutant la commande suivante pour appliquer un correctif à la ressource personnalisée « Postgres ».

    kubectl patch postgresql postgres -n instana-postgres --type=merge --patch '
spec:
  dockerImage: <internal-image-registry>/self-hosted-images/3rd-party/datastore/zalando:15.7_v0.1.0
'

  6. Suivez les étapes décrites dans la section « Vérification d' Postgres » (en ligne et hors ligne).

Vérification de l' Postgres s (en ligne et hors ligne)

Modifier en ligne

Suivez ces étapes pour vérifier une instance d' Postgres t son magasin de données.

  1. Vérifiez la mise à niveau de l'opérateur d' Postgres.

    kubectl get all -n instana-postgres

    Si l'opérateur « Postgres » est déployé avec succès, le résultat de la commande est le suivant :

    • Le résultat suivant est un exemple illustrant l'opérateur « Zalando » :

      NAME                                     READY   STATUS    RESTARTS   AGE
pod/postgres-0                           1/1     Running   0          100s
pod/postgres-1                           1/1     Running   0          69s
pod/postgres-2                           1/1     Running   0          41s
pod/postgres-operator-766455c58c-ntmpf   1/1     Running   0          11m

NAME                        TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
service/postgres            ClusterIP   192.168.1.107   <none>        5432/TCP   101s
service/postgres-operator   ClusterIP   192.168.1.35    <none>        8080/TCP   11m
service/postgres-repl       ClusterIP   192.168.1.72    <none>        5432/TCP   101s

NAME                                READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/postgres-operator   1/1     1            1           11m

NAME                                           DESIRED   CURRENT   READY   AGE
replicaset.apps/postgres-operator-766455c58c   1         1         1       11m

NAME                        READY   AGE
statefulset.apps/postgres   3/3     103s

NAME                                                    IMAGE                             CLUSTER-LABEL   SERVICE-ACCOUNT   MIN-INSTANCES   AGE
operatorconfiguration.acid.zalan.do/postgres-operator   ghcr.io/zalando/spilo-15:3.0-p1   cluster-name    postgres-pod      -1              11m

NAME                                TEAM      VERSION   PODS   VOLUME   CPU-REQUEST   MEMORY-REQUEST   AGE    STATUS
postgresql.acid.zalan.do/postgres   instana   15        3      10Gi     500m          2Gi              106s   Running

    • Le résultat suivant est un exemple illustrant l'opérateur « CloudNativePG » :

      NAME                                      READY    STATUS    RESTARTS    AGE
pod/postgres-1                             1/1     Running     0         100s
pod/postgres-2                             1/1     Running     0         69s
pod/postgres-3                             1/1     Running     0         41s
pod/cnpg-cloudnative-pg-64bbc87958-fqnrl   1/1     Running     0         11m

NAME                           TYPE        CLUSTER-IP       EXTERNAL-IP   PORT
service/cnpg-webhook-service   ClusterIP   172.30.66.183    <none>        443/TCP
service/postgres-r             ClusterIP   172.30.163.146   <none>        5432/TCP
service/postgres-ro            ClusterIP   172.30.226.75    <none>        5432/TCP
service/postgres-rw            ClusterIP   172.30.235.178   <none>        5432/TCP

NAME                                READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/cnpg-cloudnative-p   1/1     1            1           11m

NAME                                           DESIRED   CURRENT   READY   AGE
replicaset.apps/cnpg-cloudnative-pg-64bbc87958   1         1         1       11m

Migration des données depuis Zalando vers CloudNativePG

Modifier en ligne

En utilisant le mode pg_basebackup bootstrap, vous pouvez créer un nouveau cluster d' PostgreSQL s (cible) qui reproduit exactement l'état physique d'une instance d' PostgreSQL existante (source).

Vous pouvez effectuer un démarrage à partir d'un cluster actif via une connexion de réplication en continu valide, en utilisant l'instance source PostgreSQL soit comme serveur principal, soit comme serveur de secours PostgreSQL.

Pour migrer les données d'un cluster Zalando PostgreSQL, via le mode pg_basebackup bootstrap, vers un cluster de répliques CloudNativePG, consultez la section « Migration des données de Zalando vers CloudNativePG ».