Le cluster OpenShift® Container Platform qui est connecté dans une relation de reprise après sinistre ou un service Sauvegarde et restauration avec Hub et Parler peut faire face à des sinistres, conduisant à un état temporairement inutilisable. Après la reprise, il peut toujours afficher un statut Unhealthy ou UnManaged dans les clusters distants. Dans de tels cas, ce cluster doit être reconnecté à ses connexions correspondantes.
A propos de cette tâche
Si le cluster est restauré avant le délai d'expiration, il rejoint automatiquement la connexion et aucune action n'est nécessaire. Toutefois, si le cluster est restauré après l'expiration du certificat client, la connexion doit être nettoyée et configurée pour rejoindre le cluster récupéré.
Procédure
- Exécutez l'exemple de commande suivant pour vous connecter à cluster-a et lister les noms de connexion.
- Liste des noms de connexion.
oc get connections
Il répertorie tous les CR de connexion qui sont utilisés pour la
sauvegarde et la restauration et la reprise après sinistre. L'exemple suivant montre des connexions entre clusters :
- Si le cluster-a est en relation DR, une connexion existe pour l'autre cluster.
- Si cluster-a est un hub Sauvegarde et restauration, il existe une connexion pour chaque rayon.
- Si le cluster-a est un Sauvegarde et restauration rayon, il existe une connexion au hub.
La sortie comprend le point de terminaison API de cluster-b.
Exemple de sortie
NOM API_ENDPOINT PHASE HEALTHY_TO HEALTHY_FROM AGE
connection-8414b9c84d https://api.cluster-b.mydomain:6443 InProgress Unhealthy Unknown 25d
%
- Enregistrer le nom de la connexion CR dans le cluster-a (un cluster dans le hub and spoke ou les clusters DR) au format
connection-<id>.
- Nettoyer la connexion.
- Configurez la connexion entre les clusters.
- Connectez-vous au cluster-b et obtenez le jeton d'amorçage pour le cluster-b.
oc login to cluster-b
oc create token isf-application-operator-cluster-bootstrap -n <Fusion Namespace of cluster-b>
Note: La version de la ligne de commande oc doit être supérieure ou égale à 4.11.
- Connectez-vous au cluster-a.
- Créer un secret d'initialisation sur le cluster-a avec le jeton d'amorçage et le point de terminaison API du cluster-b.
Par exemple :
apiVersion: v1
kind: Secret
metadata:
name: <Init Secret Name>
namespace: <Fusion Namespace of cluster-a>
stringData:
apiserver: <cluster-b API Endpoint>
bootstrapToken: <cluster-b Token Generated in Step 3.a>
- Créer la connexion CR sur le cluster-a avec ce secret d'initialisation dans le spec:
apiVersion: application.isf.ibm.com/v1
kind: Connection
metadata:
name: <Connection Name Saved in Step 1>
namespace: <Fusion Namespace of cluster-a>
spec:
remoteCluster:
apiEndpoint: <cluster-b API Endpoint>
initSecretName: <Init Secret Name>
connectionOperatorNamespace: <Fusion Namespace of cluster-b>