Aller au contenu

Déplacement d'un Grafana mutualisé#

Warning

Cette documentation a été rédigée avant CAASINC-2137 / CAASCHR-3350 / CAASCHR-3351. Depuis, la configuration envs-ng thanos-certificates a été ajoutée. Cette documentation n'en tient pas compte.

Si cette documentation est utilisée, il faudra la mettre à jour pour tenir compte de thanos-certificates.

Objectifs#

  • déplacer la zone Grafana mutualisé vers un autre Cluster;
  • déplacer le Thanos-query du Grafana mutualisé vers un autre Cluster ;
  • avoir la possibilité de changer d'AZ;
  • assurer que le Grafana mutualisé marche sur le nouveau Cluster.

Silences#

Afin d'éviter d'être alerté pendant le déplacement du Grafana mutualisé, il est important de poser un silence sur toute la zone.

xdg-open 'https://karma-infra.infra-prd.caascad.com/?m='$(echo '{"am":[{"label":"svc-monitoring-stack-corp-prd-1","value":["svc-monitoring-stack-corp-prd-1"]},{"label":"svc-monitoring-stack-corp-prd-2","value":["svc-monitoring-stack-corp-prd-2"]}],"m":[{"n":"obs_client","r":false,"e":true,"v":["CLIENT"]},{"n":"ngot_service","r":false,"e":true,"v":["svc-grafana-client-CLIENT"]}],"d":120,"c":"Move mutualized Grafana"}' | sed -e "s/CLIENT/${CLIENT}/g" | base64 -w0)

Ancienne méthode : dans Karma mettez un silence :

  • il faut poser les silences sur les deux alertmanagers de Prod : svc-monitoring-stack-corp-prd-1 et svc-monitoring-stack-corp-prd-2 ;
  • filtre dans Karma le nom de la zone : obs_client=xxxx, ngot_service=svc-grafana-client-xxx;
  • commentaire : Move mutualized Grafana ;
  • durée : 2h.

Exemple : Silences dans karma

À la fin du provisioning il sera nécessaire de supprimer les silences mises en place.

Points de vigilance#

Avant de commencer l'opération, il faut s'assurer que les deux clusters concernés sont joignables.

Préparatifs#

ENVS_NG=xxx       # exemple : $HOME/git/caascad/terraform/envs-ng
CLUSTER_SOURCE=<cluster_name>
CLUSTER_DEST=<cluster_name>
CONTRACT_NAME=<contract_name>  # le nom de contrat du grafana mutalisé
CLIENT_NAME=$(echo $CONTRACT_NAME | sed "s/obs-//g")
NAMESPACE="grafana-client-${CONTRACT_NAME}"
NODE_SOURCE=<node_source_name>  # Correspond au noeud sur lequel grafana mutualisé est exécuté
NODE_DEST=<node_dest_name>

Note

Le node source et le node de destination permettent de déplacer le Grafana mutualisé sur un AZ spécifique.

Déplacement du Grafana#

Déployer un nouveau BackupStorageLocation et le Configmap sur le Cluster de Destination#

kswitch ${CLUSTER_DEST}
cat <<EOF | kubectl apply -f -
apiVersion: velero.io/v1
kind: BackupStorageLocation
metadata:
  name: ${CLUSTER_SOURCE}
  namespace: velero
spec:
  accessMode: ReadOnly
  config:
    region: eu-west-0
    s3ForcePathStyle: "true"
    s3Url: https://oss.eu-west-0.prod-cloud-ocb.orange-business.com
  default: false
  objectStorage:
    bucket: velero-storage-${CLUSTER_SOURCE}
    prefix: velero
  provider: aws
EOF

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ConfigMap
data:
  ${NODE_SOURCE}: ${NODE_DEST}
metadata:
  labels:
    velero.io/change-pvc-node-selector: RestoreItemAction
    velero.io/plugin-config: ""
  name: change-pvc-node-selector-config
  namespace: velero
EOF

Backup et supression du grafana mutualisé depuis le Cluster source#

kswitch ${CLUSTER_SOURCE}
velero create backup ${NAMESPACE}-${CLUSTER_SOURCE} --include-namespaces ${NAMESPACE} --wait
kubectl -n ${NAMESPACE} delete ingress grafana-${CONTRACT_NAME}
kubectl -n ${NAMESPACE} delete ingress thanos-query

Warning

Si le Backup échoue, il faut arrêter immédiatement l'opération et investiguer sur la raison de cet échec.

Restauration du Backup dans le Cluster de destination#

kswitch ${CLUSTER_DEST}
velero restore create ${NAMESPACE}-migration-from-${CLUSTER_SOURCE} --from-backup ${NAMESPACE}-${CLUSTER_SOURCE} --wait

Modification du fichier de zone#

cd /${HOME}/git/caascad/terraform/envs-ng/contexts/ngot
git switch master
git pull
git switch -c ${NAMESPACE}-migration-from-${CLUSTER_SOURCE}-to-${CLUSTER_DEST}
Il faut aller dans le fichier client-${CLIENT_NAME}.cue et changer la valeur de la clé parent_zone_name par le CLUSTER_DEST

generate-static-zones-files
trackbone apply -z svc-grafana-client-${CLIENT_NAME} --non-interactive
git add -u
git commit -m "NGOT: ${NAMESPACE} migration from ${CLUSTER_SOURCE} to ${CLUSTER_DEST}"
git push -u origin ${NAMESPACE}-migration-from-${CLUSTER_SOURCE}-to-${CLUSTER_DEST}

Vérification#

Avant de continuer, il faut vérifier que:

  • le grafana mutualisé est de nouveau disponible;
  • la présence des données restaurée;
  • les ingress et les certificats sont valides.

Note

Dans le cas où les services Grafana et Thanos-query sont toujours indisponibles malgrè que les certificats soient valides, il faudra supprimer les ingress à la main et refaire un autre restore dans le cluster de destination.

kubectl -n ${NAMESPACE} delete ingress grafana-${CONTRACT_NAME}
kubectl -n ${NAMESPACE} delete ingress thanos-query
velero restore create ${NAMESPACE}-migration-from-${CLUSTER_SOURCE}-1 --from-backup ${NAMESPACE}-${CLUSTER_SOURCE} --wait

Supression des configurations#

git switch master
git pull
trackbone apply -z svc-grafana-client-${CLIENT_NAME} -c vault_sync_parent_zone --non-interactive
trackbone destroy -z svc-grafana-client-${CLIENT_NAME} --non-interactive -t purge=true
kswitch ${CLUSTER_SOURCE}
kubectl delete ns ${NAMESPACE}

Réalignement de certaines configurations#

git switch ${NAMESPACE}-migration-from-${CLUSTER_SOURCE}-to-${CLUSTER_DEST}
trackbone apply -z svc-grafana-client-${CLIENT_NAME} -c vault_sync_parent_zone --non-interactive
kswitch ${CLUSTER_DEST}
kubectl -n velero delete cm change-pvc-node-selector-config
kubectl -n velero delete backupstoragelocations ${CLUSTER_SOURCE}

Réalignement de velero dans le Cluster source#

kswitch ${CLUSTER_SOURCE}
velero delete backup -l velero.io/schedule-name=grafana-obs-${CLIENT_NAME}
velero delete backup grafana-client-obs-${CLIENT_NAME}-${CLUSTER_SOURCE}
kubectl rollout restart -n velero deploy/velero

Mise à jour des pipelines Concourse#

Suivre la doc de gestion des drifts pour mettre à jour les pipelines Concourse.

Demander une Validation et merger la MR#

Absence de PVs Released#

Vérifier l'absence de PV avec le status Released :

kswitch ${CLUSTER_SOURCE}
kubectl get pv | grep ${CLIENT_NAME} | grep Released

S'il y en a, supprimer les : 

for pv in $(kubectl get pv | grep ${CLIENT_NAME} | grep Released | awk '$1 {print$1}'); do
  kubectl delete pv $ pv
done