Guide de l'administrateur NetBackup™ pour Kubernetes
- Présentation de NetBackup pour Kubernetes
- Déploiement et configuration de l'opérateur NetBackup Kubernetes
- Conditions préalables au déploiement de l'opérateur NetBackup Kubernetes
- Déploiement du package de service sur l'opérateur NetBackup Kubernetes
- Spécifications de port pour le déploiement de l'opérateur Kubernetes
- Mise à niveau de l'opérateur NetBackup Kubernetes
- Suppression de l'opérateur NetBackup Kubernetes
- Configuration du système de déplacement des données NetBackup Kubernetes
- Configuration automatisée de la protection NetBackup pour Kubernetes
- Personnaliser la charge de travail Kubernetes
- Dépannage des serveurs NetBackup avec des noms courts
- Prise en charge du mécanisme de planification des pods du système de déplacement des données
- Validation de la classe de stockage d'accélérateur
- Déploiement de certificats sur l'opérateur NetBackup Kubernetes
- Gestion des biens Kubernetes
- Gestion des groupes intelligents Kubernetes
- Protection des biens Kubernetes
- Protection d'un groupe intelligent
- Suppression de la protection d'un groupe intelligent
- Configuration d'une planification de sauvegarde
- Configuration des options de sauvegardes
- Configuration des sauvegardes
- Configuration d'AIR (Auto Image Replication) et de la duplication
- Configuration des unités de stockage
- Prise en charge du mode volume
- Configuration d'une sauvegarde cohérente au niveau application
- Gestion des groupes d'images
- Protection des clusters gérés par Rancher dans NetBackup
- Récupération des biens Kubernetes
- À propos de la sauvegarde incrémentielle et de la restauration
- Activation de la sauvegarde basée sur l'accélérateur
- À propos de la prise en charge de l'accélérateur NetBackup pour les charges de travail Kubernetes
- Contrôle de l'espace disque réservé aux journaux de suivi sur le serveur principal
- Impact du comportement de la classe de stockage sur l'accélérateur
- À propos des nouvelles analyses forcées par l'accélérateur
- Avertissements et raison probable des échecs des sauvegardes avec accélérateur
- Activation du mode FIPS dans Kubernetes
- Résolution des problèmes liés à Kubernetes
- Erreur lors de la mise à niveau du serveur principal : échec de NBCheck
- Erreur lors de la restauration d'une image ancienne : l'opération échoue
- Erreur de l'API de récupération de volume persistant
- Erreur lors de la restauration : l'état final du travail affiche un échec partiel
- Erreur lors de la restauration sur le même espace de noms
- Pods du datamover dépassant la limite de ressource Kubernetes
- Erreur lors de la restauration : le travail échoue sur le cluster hautement chargé
- Le rôle Kubernetes personnalisé créé pour des clusters spécifiques ne peut pas afficher les travaux
- Openshift crée des PVC vides non sélectionnés lors de la restauration des applications installées à partir d'OperatorHub
- L'opérateur NetBackup Kubernetes ne répond plus si la limite de PID est dépassée sur le nœud Kubernetes
- Échec lors de la modification du cluster dans NetBackup Kubernetes 10.1
- La sauvegarde ou la restauration échoue pour une demande PVC volumineuse
- Échec partiel de la restauration des PVC de mode fichier de l'espace de noms sur un système de fichiers différent
- Échec de la restauration à partir de la copie de sauvegarde avec une erreur d'incohérence d'image
- Vérifications de connectivité entre les serveurs principal/de médias NetBackup et les serveurs Kubernetes
- Erreur lors de la sauvegarde avec accélérateur lorsque l'espace disponible pour le journal de suivi est insuffisant
- Erreur lors de la sauvegarde avec accélérateur en raison de l'échec de la création de la demande PVC pour le journal de suivi
- Erreur lors de la sauvegarde avec accélérateur en raison d'une classe de stockage d'accélérateur non valide
- Une erreur se produit lors du démarrage du pod de journal de suivi
- Échec de la configuration de l'instance de système de déplacement des données pour l'opération de création de demande PVC pour le journal de suivi
- Erreur lors de la lecture de la classe de stockage du journal de suivi à partir du fichier configmap
Prise en charge du mécanisme de planification des pods du système de déplacement des données
Dans NetBackup, les utilisateurs peuvent annoter des pods du datamover pour activer l'utilisation d'un réseau supplémentaire en appliquant des définitions de connexion réseau au pod du datamover, à l'aide d'un ConfigMap spécifique au serveur de sauvegarde.
Pendant l'installation de Helm pour l'opérateur NetBackup Kubernetes, les utilisateurs peuvent spécifier des annotations dans le fichier netbackupkops-helm-chart/values.yaml, qui seront appliquées aux déploiements de l'opérateur NetBackup Kubernetes et aux pods du datamover. Ce paramètre est facultatif.
Les utilisateurs peuvent annoter ou modifier des annotations existantes en modifiant le ConfigMap spécifique au serveur de sauvegarde.
Par exemple
# kubectl get cm -n <kops-namespace> # kubectl edit cm/<backup-server-name> -n <kops-namespace> datamover.annotations: | k8s.v1.cni.cncf.io/networks: whereabouts-ipvlan-conf-1
Lorsque le pod du datamover utilise un réseau dédié, le hostalias dans le pod ne fonctionne pas pour plusieurs réseaux dédiés. Si la première interface tombe en panne, la connectivité ne bascule pas vers le deuxième réseau de sauvegarde dédié.
Au lieu d'avoir deux interfaces réseau dédiées distinctes connectées au datamover, il est recommandé de créer un pont à l'aide des deux interfaces et de configurer multus sur ce pont.
Spécifiez les champs suivants dans le configMap du serveur de sauvegarde pour planifier les pods du système de déplacement des données sur les nœuds.
nodeSelector : nodeSelector est un moyen facile de limiter les pods aux nœuds avec des étiquettes spécifiques.
Exemple :
apiVersion: v1 kind: ConfigMap metadata: name: backupserver.sample.domain.com namespace: netbackup data: datamover.hostaliases: | 10.20.12.13=backupserver.sample.domain.com 10.21.12.13=mediaserver.sample.domain.com datamover.properties: | image=reg.domain.com/datamover/image:latest datamover.nodeSelector: | kubernetes.io/hostname: test1-l94jm-worker-k49vj topology.rook.io/rack: rack1 version: "1"
nodeName : nodeName est un formulaire direct de sélection de nœud différent d'affinity ou de nodeSelector. Il vous permet de spécifier un nœud sur lequel un pod est planifié pour la sauvegarde et de remplacer le mécanisme de planification par défaut.
Exemple :
apiVersion: v1 kind: ConfigMap metadata: name: backupserver.sample.domain.com namespace: netbackup data: datamover.hostaliases: | 10.20.12.13=backupserver.sample.domain.com 10.21.12.13=mediaserver.sample.domain.com datamover.properties: | image=reg.domain.com/datamover/image:latest datamover.nodeName : test1-l94jm-worker-hbblk version: "1"
Taint et Toleration : la valeur Toleration vous permet de planifier les pods avec des valeurs taint similaires. Les valeurs Taint et la Toleration fonctionnent ensemble pour garantir que les pods sont planifiés sur les nœuds appropriés. Si une ou plusieurs valeurs taint sont appliquées à un nœud, celui-ci ne doit pas accepter les pods qui ne prennent pas en charge les valeurs taint.
Exemple :
apiVersion: v1 kind: ConfigMap metadata: name: backupserver.sample.domain.com namespace: netbackup data: datamover.hostaliases: | 10.20.12.13=backupserver.sample.domain.com 10.21.12.13=mediaserver.sample.domain.com datamover.properties: | image=reg.domain.com/datamover/image:latest datamover.tolerations: | - key: "dedicated" operator: "Equal" value: "experimental" effect: "NoSchedule" version: "1"
Affinité et Anti-affinité : les fonctions d'affinité de nœud (similaires au champ NodeSelector, mais plus expressives) vous permettent de spécifier des règles logicielles. La fonction d'affinité/anti-affinité Inter-pod vous permet de limiter les pods au niveau des étiquettes sur les autres pods.
Exemples :
Affinité de nœud :
apiVersion: v1 kind: ConfigMap metadata: name: backupserver.sample.domain.com namespace: netbackup data: datamover.hostaliases: | 10.20.12.13=backupserver.sample.domain.com 10.21.12.13=mediaserver.sample.domain.com datamover.properties: | image=reg.domain.com/datamover/image:latest datamover.affinity: | nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - test1-l94jm-worker-hbblk preferredDuringSchedulingIgnoredDuringExecution: - weight: 1 preference: matchExpressions: - key: beta.kubernetes.io/arch operator: In values: - amd64 version: "1"
Affinité de pod
apiVersion: v1 kind: ConfigMap metadata: name: backupserver.sample.domain.com namespace: netbackup data: datamover.hostaliases: | 10.20.12.13=backupserver.sample.domain.com 10.21.12.13=mediaserver.sample.domain.com datamover.properties: | image=reg.domain.com/datamover/image:latest datamover.affinity: | podAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: component operator: In values: - netbackup topologyKey: kubernetes.io/hostname version: "1"
topologySpreadConstraints : les contraintes de propagation de topologie sont utilisées pour contrôler le comportement des pods répartis dans votre cluster, dans des domaines de défaillance tels que des régions, des zones, des nœuds et d'autres domaines de topologie définis par l'utilisateur.
Exemple :
apiVersion: v1 kind: ConfigMap metadata: name: backupserver.sample.domain.com namespace: netbackup data: datamover. hostaliases: | 10.20.12.13=backupserver.sample.domain.com 10.21.12.13=mediaserver.sample.domain.com datamover.properties: | image=reg.domain.com/datamover/image:latest datamover.topologySpreadConstraints : | - maxSkew: 1 topologyKey: kubernetes.io/hostname whenUnsatisfiable: DoNotSchedule version: "1"
Étiquettes : les paires clé/valeur sont associées aux objets, tels que des pods. Les étiquettes ont pour but d'identifier les attributs d'un objet qui sont significatifs et pertinents pour les utilisateurs. Les étiquettes peuvent organiser et sélectionner des sous-ensembles d'objets. Les étiquettes associées aux objets lors de leur création sont ajoutées et modifiées par la suite à tout moment.
Exemple :
apiVersion: v1 kind: ConfigMap metadata: name: backupserver.sample.domain.com namespace: netbackup data: datamover.hostaliases: | 10.20.12.13=backupserver.sample.domain.com 10.21.12.13=mediaserver.sample.domain.com datamover.properties: | image=reg.domain.com/datamover/image:latest datamover.labels: | env: test pod: datamover version: "1"
Annotations : l'utilisateur peut utiliser des étiquettes ou des annotations pour associer des métadonnées aux objets Kubernetes. Vous ne pouvez pas utiliser des annotations pour identifier et sélectionner des objets.
Exemple :
apiVersion: v1 kind: ConfigMap metadata: name: backupserver.sample.domain.com namespace: netbackup data: datamover.hostaliases: | 10.20.12.13=backupserver.sample.domain.com 10.21.12.13=mediaserver.sample.domain.com datamover.properties: | image=reg.domain.com/datamover/image:latest datamover.annotations: | buildinfo: |- [{ "name": "test", "build": "1" }] imageregistry: "https://reg.domain.com/" version: "1"