Passez d'une option de gestion back-end à une autre
Découvrez les différentes méthodes de gestion des systèmes back-end dans Trident.
Options de gestion des systèmes back-end
Avec l'introduction de TridentBackendConfig
, les administrateurs ont désormais deux méthodes uniques de gestion des systèmes back-end. Ceci pose les questions suivantes :
-
Les systèmes back-end peuvent être créés avec
tridentctl
être géré avecTridentBackendConfig
? -
Les systèmes back-end peuvent être créés avec
TridentBackendConfig
gestion viatridentctl
?
Gérez tridentctl
utilisation de systèmes back-end TridentBackendConfig
Cette section aborde les étapes requises pour gérer les systèmes back-end créés à l'aide de tridentctl
Directement via l'interface Kubernetes en créant la TridentBackendConfig
objets.
Cela s'applique aux scénarios suivants :
-
Systèmes back-end existants, sans système
TridentBackendConfig
parce qu'ils ont été créés avectridentctl
. -
Nouveaux systèmes back-end créés avec
tridentctl
, tandis que d'autresTridentBackendConfig
les objets existent.
Dans les deux scénarios, les systèmes back-end continueront d'être présents, avec Trident qui planifie les volumes et les exécute. Les administrateurs peuvent choisir l'une des deux options suivantes :
-
Continuer à utiliser
tridentctl
pour gérer les systèmes back-end créés en utilisant ces systèmes. -
Lier les systèmes back-end créés à l'aide de
tridentctl
à un nouveauTridentBackendConfig
objet. Ainsi, le système back-end sera géré à l'aide dekubectl
et nontridentctl
.
Pour gérer un système back-end existant à l'aide de kubectl
, vous devez créer un TridentBackendConfig
cela se lie au back-end existant. Voici un aperçu du fonctionnement de ces éléments :
-
Créez un code secret Kubernetes. La clé secrète contient les informations d'identification dont Trident a besoin pour communiquer avec le cluster/service de stockage.
-
Créer un
TridentBackendConfig
objet. Elle contient des informations spécifiques sur le cluster/service de stockage et fait référence au secret créé à l'étape précédente. Vous devez veiller à spécifier des paramètres de configuration identiques (par exemplespec.backendName
,spec.storagePrefix
,spec.storageDriverName
, etc.).spec.backendName
doit être défini sur le nom du back-end existant.
Étape 0 : identifier le back-end
Pour créer un TridentBackendConfig
qui se lie à un back-end existant, vous devez obtenir la configuration back-end. Dans cet exemple, supposons qu'un back-end a été créé à l'aide de la définition JSON suivante :
tridentctl get backend ontap-nas-backend -n trident +---------------------+----------------+--------------------------------------+--------+---------+ | NAME | STORAGE DRIVER | UUID | STATE | VOLUMES | +---------------------+----------------+--------------------------------------+--------+---------+ | ontap-nas-backend | ontap-nas | 52f2eb10-e4c6-4160-99fc-96b3be5ab5d7 | online | 25 | +---------------------+----------------+--------------------------------------+--------+---------+
cat ontap-nas-backend.json
{
"version": 1,
"storageDriverName": "ontap-nas",
"managementLIF": "10.10.10.1",
"dataLIF": "10.10.10.2",
"backendName": "ontap-nas-backend",
"svm": "trident_svm",
"username": "cluster-admin",
"password": "admin-password",
"defaults": {
"spaceReserve": "none",
"encryption": "false"
},
"labels": {
"store": "nas_store"
},
"region": "us_east_1",
"storage": [
{
"labels": {
"app": "msoffice",
"cost": "100"
},
"zone": "us_east_1a",
"defaults": {
"spaceReserve": "volume",
"encryption": "true",
"unixPermissions": "0755"
}
},
{
"labels": {
"app": "mysqldb",
"cost": "25"
},
"zone": "us_east_1d",
"defaults": {
"spaceReserve": "volume",
"encryption": "false",
"unixPermissions": "0775"
}
}
]
}
Étape 1 : créez un code secret Kubernetes
Créez un secret qui contient les informations d'identification du back-end, comme indiqué dans cet exemple :
cat tbc-ontap-nas-backend-secret.yaml
apiVersion: v1
kind: Secret
metadata:
name: ontap-nas-backend-secret
type: Opaque
stringData:
username: cluster-admin
password: admin-password
kubectl create -f tbc-ontap-nas-backend-secret.yaml -n trident secret/backend-tbc-ontap-san-secret created
Étape 2 : créer un TridentBackendConfig
CR
L'étape suivante consiste à créer un TridentBackendConfig
CR qui se lie automatiquement au pré-existant ontap-nas-backend
(comme dans cet exemple). Assurez-vous que les exigences suivantes sont respectées :
-
Le même nom de back-end est défini dans
spec.backendName
. -
Les paramètres de configuration sont identiques au back-end d'origine.
-
Les pools virtuels (le cas échéant) doivent conserver le même ordre que dans le back-end d'origine.
-
Les identifiants sont fournis via un code secret Kubernetes et non en texte brut.
Dans ce cas, le TridentBackendConfig
se présente comme suit :
cat backend-tbc-ontap-nas.yaml
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
name: tbc-ontap-nas-backend
spec:
version: 1
storageDriverName: ontap-nas
managementLIF: 10.10.10.1
dataLIF: 10.10.10.2
backendName: ontap-nas-backend
svm: trident_svm
credentials:
name: mysecret
defaults:
spaceReserve: none
encryption: 'false'
labels:
store: nas_store
region: us_east_1
storage:
- labels:
app: msoffice
cost: '100'
zone: us_east_1a
defaults:
spaceReserve: volume
encryption: 'true'
unixPermissions: '0755'
- labels:
app: mysqldb
cost: '25'
zone: us_east_1d
defaults:
spaceReserve: volume
encryption: 'false'
unixPermissions: '0775'
kubectl create -f backend-tbc-ontap-nas.yaml -n trident tridentbackendconfig.trident.netapp.io/tbc-ontap-nas-backend created
Étape 3 : vérifier l'état du TridentBackendConfig
CR
Après le TridentBackendConfig
a été créée, sa phase doit être Bound
. Il devrait également refléter le même nom de back-end et UUID que celui du back-end existant.
kubectl get tbc tbc-ontap-nas-backend -n trident NAME BACKEND NAME BACKEND UUID PHASE STATUS tbc-ontap-nas-backend ontap-nas-backend 52f2eb10-e4c6-4160-99fc-96b3be5ab5d7 Bound Success #confirm that no new backends were created (i.e., TridentBackendConfig did not end up creating a new backend) tridentctl get backend -n trident +---------------------+----------------+--------------------------------------+--------+---------+ | NAME | STORAGE DRIVER | UUID | STATE | VOLUMES | +---------------------+----------------+--------------------------------------+--------+---------+ | ontap-nas-backend | ontap-nas | 52f2eb10-e4c6-4160-99fc-96b3be5ab5d7 | online | 25 | +---------------------+----------------+--------------------------------------+--------+---------+
Le système back-end sera désormais entièrement géré à l'aide du système tbc-ontap-nas-backend
TridentBackendConfig
objet.
Gérez TridentBackendConfig
utilisation de systèmes back-end tridentctl
`tridentctl` possibilité d'afficher la liste des systèmes back-end créés à l'aide de `TridentBackendConfig`. En outre, les administrateurs ont la possibilité de choisir entre la gestion complète de ces systèmes back-end `tridentctl` en supprimant `TridentBackendConfig` et en fait bien sûr `spec.deletionPolicy` est défini sur `retain`.
Étape 0 : identifier le back-end
Par exemple, supposons que le back-end suivant a été créé à l'aide de TridentBackendConfig
:
kubectl get tbc backend-tbc-ontap-san -n trident -o wide NAME BACKEND NAME BACKEND UUID PHASE STATUS STORAGE DRIVER DELETION POLICY backend-tbc-ontap-san ontap-san-backend 81abcb27-ea63-49bb-b606-0a5315ac5f82 Bound Success ontap-san delete tridentctl get backend ontap-san-backend -n trident +-------------------+----------------+--------------------------------------+--------+---------+ | NAME | STORAGE DRIVER | UUID | STATE | VOLUMES | +-------------------+----------------+--------------------------------------+--------+---------+ | ontap-san-backend | ontap-san | 81abcb27-ea63-49bb-b606-0a5315ac5f82 | online | 33 | +-------------------+----------------+--------------------------------------+--------+---------+
À partir de la sortie, on voit cela TridentBackendConfig
A été créé avec succès et est lié à un back-end [observer l'UUID du back-end].
Étape 1 : confirmer deletionPolicy
est défini sur retain
Examinons la valeur de deletionPolicy
. Ce paramètre doit être défini sur retain
. Cela garantit que lorsqu'une TridentBackendConfig
demande de modification est supprimée, la définition du back-end est toujours présente et peut être gérée avec tridentctl
.
kubectl get tbc backend-tbc-ontap-san -n trident -o wide NAME BACKEND NAME BACKEND UUID PHASE STATUS STORAGE DRIVER DELETION POLICY backend-tbc-ontap-san ontap-san-backend 81abcb27-ea63-49bb-b606-0a5315ac5f82 Bound Success ontap-san delete # Patch value of deletionPolicy to retain kubectl patch tbc backend-tbc-ontap-san --type=merge -p '{"spec":{"deletionPolicy":"retain"}}' -n trident tridentbackendconfig.trident.netapp.io/backend-tbc-ontap-san patched #Confirm the value of deletionPolicy kubectl get tbc backend-tbc-ontap-san -n trident -o wide NAME BACKEND NAME BACKEND UUID PHASE STATUS STORAGE DRIVER DELETION POLICY backend-tbc-ontap-san ontap-san-backend 81abcb27-ea63-49bb-b606-0a5315ac5f82 Bound Success ontap-san retain
|
Ne pas passer à l'étape suivante sauf si deletionPolicy est défini sur retain .
|
Étape 2 : supprimez le TridentBackendConfig
CR
La dernière étape consiste à supprimer le TridentBackendConfig
CR. Après avoir confirmé le deletionPolicy
est défini sur retain
, vous pouvez poursuivre la suppression :
kubectl delete tbc backend-tbc-ontap-san -n trident tridentbackendconfig.trident.netapp.io "backend-tbc-ontap-san" deleted tridentctl get backend ontap-san-backend -n trident +-------------------+----------------+--------------------------------------+--------+---------+ | NAME | STORAGE DRIVER | UUID | STATE | VOLUMES | +-------------------+----------------+--------------------------------------+--------+---------+ | ontap-san-backend | ontap-san | 81abcb27-ea63-49bb-b606-0a5315ac5f82 | online | 33 | +-------------------+----------------+--------------------------------------+--------+---------+
Lors de la suppression de TridentBackendConfig
l'objet, Trident le supprime simplement sans réellement supprimer le back-end lui-même.