백엔드 관리 옵션 간 이동
변경 제안
PDF
Trident 에서 백엔드를 관리하는 다양한 방법에 대해 알아보세요.
백엔드 관리를 위한 옵션
의 도입으로 TridentBackendConfig 이제 관리자는 백엔드를 관리하는 두 가지 고유한 방법을 사용할 수 있습니다. 이는 다음과 같은 질문을 제기합니다.
-
백엔드를 사용하여 생성할 수 있습니까?
tridentctl~로 관리되다TridentBackendConfig? -
백엔드를 사용하여 생성할 수 있습니까?
TridentBackendConfig사용하여 관리됩니다tridentctl?
관리하다 tridentctl 백엔드를 사용하여 TridentBackendConfig
이 섹션에서는 다음을 사용하여 생성된 백엔드를 관리하는 데 필요한 단계를 다룹니다. tridentctl Kubernetes 인터페이스를 통해 직접 생성 TridentBackendConfig 사물.
이는 다음 시나리오에 적용됩니다.
-
기존 백엔드가 없는 경우
TridentBackendConfig왜냐하면 그들은 ~로 창조되었기 때문이다tridentctl. -
새로운 백엔드가 생성되었습니다.
tridentctl, 다른TridentBackendConfig객체가 존재합니다.
두 시나리오 모두 백엔드는 계속 존재하며 Trident 볼륨을 예약하고 이를 운영합니다. 관리자는 다음 두 가지 선택 중 하나를 선택할 수 있습니다.
-
계속 사용
tridentctl이를 사용하여 생성된 백엔드를 관리합니다. -
다음을 사용하여 생성된 백엔드 바인딩
tridentctl새로운 것에TridentBackendConfig물체. 그렇게 하면 백엔드가 다음을 사용하여 관리됩니다.kubectl그리고 아니다tridentctl.
기존 백엔드를 관리하려면 다음을 사용합니다. kubectl , 당신은 만들어야 할 것입니다 TridentBackendConfig 기존 백엔드에 바인딩됩니다. 작동 원리는 다음과 같습니다.
-
Kubernetes Secret을 생성합니다. 비밀에는 Trident 스토리지 클러스터/서비스와 통신하는 데 필요한 자격 증명이 포함되어 있습니다.
-
생성하다
TridentBackendConfig물체. 여기에는 스토리지 클러스터/서비스에 대한 세부 정보가 포함되어 있으며 이전 단계에서 생성된 비밀을 참조합니다. 동일한 구성 매개변수(예:)를 지정하는 데 주의해야 합니다.spec.backendName,spec.storagePrefix,spec.storageDriverName, 등).spec.backendName기존 백엔드의 이름으로 설정해야 합니다.
0단계: 백엔드 식별
생성하려면 TridentBackendConfig 기존 백엔드에 바인딩하려면 백엔드 구성을 얻어야 합니다. 이 예에서는 다음 JSON 정의를 사용하여 백엔드가 생성되었다고 가정해 보겠습니다.
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"
}
}
]
}1단계: Kubernetes Secret 만들기
다음 예와 같이 백엔드에 대한 자격 증명을 포함하는 비밀을 만듭니다.
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-passwordkubectl create -f tbc-ontap-nas-backend-secret.yaml -n trident secret/backend-tbc-ontap-san-secret created
2단계: 만들기 TridentBackendConfig 씨.씨.
다음 단계는 다음을 만드는 것입니다. TridentBackendConfig 기존에 자동으로 바인딩되는 CR ontap-nas-backend (이 예에서처럼). 다음 요구 사항이 충족되는지 확인하세요.
-
동일한 백엔드 이름이 정의되어 있습니다.
spec.backendName. -
구성 매개변수는 원래 백엔드와 동일합니다.
-
가상 풀(존재하는 경우)은 원래 백엔드와 동일한 순서를 유지해야 합니다.
-
자격 증명은 일반 텍스트가 아닌 Kubernetes Secret을 통해 제공됩니다.
이 경우에는 TridentBackendConfig 다음과 같이 보일 것입니다:
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
3단계: 상태 확인 TridentBackendConfig 씨.씨.
후에 TridentBackendConfig 생성되었으므로 해당 단계는 다음과 같아야 합니다. Bound . 또한 기존 백엔드와 동일한 백엔드 이름과 UUID를 반영해야 합니다.
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 | +---------------------+----------------+--------------------------------------+--------+---------+
백엔드는 이제 다음을 사용하여 완전히 관리됩니다. tbc-ontap-nas-backend TridentBackendConfig 물체.
관리하다 TridentBackendConfig 백엔드를 사용하여 tridentctl
`tridentctl`를 사용하여 생성된 백엔드를 나열하는 데 사용할 수 있습니다. `TridentBackendConfig` . 또한 관리자는 다음을 통해 이러한 백엔드를 완전히 관리하도록 선택할 수도 있습니다. `tridentctl` 삭제하여 `TridentBackendConfig` 그리고 확인하다 `spec.deletionPolicy` 로 설정됩니다 `retain` .
0단계: 백엔드 식별
예를 들어, 다음 백엔드가 다음을 사용하여 생성되었다고 가정해 보겠습니다. 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 | +-------------------+----------------+--------------------------------------+--------+---------+
출력에서 다음이 표시됩니다. TridentBackendConfig 성공적으로 생성되었으며 백엔드에 바인딩되었습니다. [백엔드의 UUID를 확인하세요]
1단계: 확인 deletionPolicy 로 설정됩니다 retain
의 가치를 살펴보자 deletionPolicy . 이것은 설정되어야 합니다 retain . 이것은 다음을 보장합니다. TridentBackendConfig CR이 삭제되면 백엔드 정의는 여전히 존재하며 다음을 통해 관리할 수 있습니다. 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
|
다음 단계로 진행하지 마십시오. deletionPolicy 로 설정됩니다 retain .
|
2단계: 삭제 TridentBackendConfig 씨.씨.
마지막 단계는 삭제하는 것입니다. TridentBackendConfig 크.알. 확인 후 deletionPolicy 로 설정됩니다 retain , 삭제를 진행할 수 있습니다.
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 | +-------------------+----------------+--------------------------------------+--------+---------+
삭제 시 TridentBackendConfig 객체를 제거하면 Trident 백엔드 자체를 삭제하지 않고 객체를 제거합니다.