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
- Automated configuration of NetBackup protection for Kubernetes
- Personnaliser la charge de travail Kubernetes
- Dépannage des serveurs NetBackup avec des noms courts
- Data mover pod schedule mechanism support
- 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
- Gestion des politiques 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
- Configure application consistent backup
- 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
- À propos de la prise en charge de la virtualisation Openshift
- 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
Data mover pod schedule mechanism support
In NetBackup, users can annotate datamover pods to enable the use of an additional network by applying Network Attachment Definitions to the datamover pod, by using a backup server specific ConfigMap.
During NetBackup Kubernetes Operator Helm installation, users can specify annotations in the netbackupkops-helm-chart/values.yaml file, which will be applied to NetBackup Kubernetes Operator deployments and the datamover pods. This is an optional parameter.
Users can annotate or modify existing annotations by editing the backup server specific ConfigMap.
For example
# 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
When datamover pod uses a dedicated network, the hostalias inside pod does not work for more than one dedicated network. If the first interface goes down, connectivity does not fallback to second dedicated backup network.
Instead of having two separate dedicated network interfaces plugged into datamover, it is advisable to create a bridge using both interfaces and configure multus on top of this bridge.
Specify the following fields in the backup server ConfigMap to schedule data mover pods on the nodes.
nodeSelector: nodeSelector is the effortless way to constrain pods to the nodes with specific labels.
Example:
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 is a direct form of node selection than affinity or nodeSelector. It allows you to specify a node on which a pod is scheduled for backup, overriding the default schedule mechanism.
Example:
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 and Toleration: Toleration allows you to schedule the pods with similar taints. Taint and toleration work together to ensure that the pods are scheduled onto appropriate nodes. If one or more taints are applied to a node. Then that node must not accept any pods which does not tolerate the taints.
Example:
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"
Affinity and Anti-affinity: Node affinity functions like the nodeSelector field but it is more expressive and allows you to specify soft rules. Inter-pod affinity/anti-affinity allows you to constrain pods against labels on the other pods.
Examples:
Node Affinity:
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"
Pod Affinity
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: Topology spread constraints are used to control the behavior of the pods that are spread across your cluster among failure-domains such as regions, zones, nodes, and other user-defined topology domains.
Example:
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"
Labels: Labels are the key/value pairs attached to the objects, such as pods. Labels intends to identify the attributes of an object which are significant and relevant to users. Labels can organize and select subsets of objects. Labels which are attached to objects at creation time are subsequently added and modified at any time.
Example:
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: User can use either labels or annotations to attach metadata to Kubernetes objects. You cannot use Annotations to identify and select objects.
Example:
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"