Skip to main content
Se proporciona el idioma español mediante traducción automática para su comodidad. En caso de alguna inconsistencia, el inglés precede al español.

Cree back-ends con kubectl

Colaboradores netapp-aruldeepa juliantap netapp-mwallis netapp-dbagwell
PDF

Un back-end define la relación entre Trident y un sistema de almacenamiento. Indica a Trident cómo se comunica con ese sistema de almacenamiento y cómo debe aprovisionar volúmenes a partir de él. Después de instalar Trident, el siguiente paso es crear un backend. La TridentBackendConfig definición de recursos personalizados (CRD) le permite crear y administrar backends de Trident directamente a través de la interfaz de Kubernetes. Para ello, puede utilizar kubectl o la herramienta CLI equivalente para su distribución de Kubernetes.

TridentBackendConfig

TridentBackendConfig (tbc, , tbconfig tbackendconfig ) Es una interfaz CRD con nombre que permite gestionar los backend de Trident mediante kubectl. Los administradores de Kubernetes y de almacenamiento ahora pueden crear y gestionar back-ends directamente mediante la CLI de Kubernetes sin necesidad de una utilidad de línea de comandos dedicada (tridentctl).

Sobre la creación de un TridentBackendConfig objeto, sucede lo siguiente:

  • Trident crea automáticamente un backend basado en la configuración que proporcione. Esto se representa internamente como un TridentBackend (tbe, tridentbackend) CR.

  • El TridentBackendConfig está vinculado exclusivamente a una TridentBackend que fue creada por Trident.

Cada uno TridentBackendConfig mantiene una asignación de uno a uno con un TridentBackend. El primero es la interfaz que se ofrece al usuario para diseñar y configurar los back-ends. El segundo es cómo Trident representa el objeto back-end real.

Advertencia TridentBackend Trident crea los CRS automáticamente. Usted no debe modificarlos. Si desea realizar actualizaciones en los back-ends, haga esto modificando el TridentBackendConfig objeto.

Consulte el siguiente ejemplo para ver el formato del TridentBackendConfig CR:

apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: backend-tbc-ontap-san
spec:
  version: 1
  backendName: ontap-san-backend
  storageDriverName: ontap-san
  managementLIF: 10.0.0.1
  dataLIF: 10.0.0.2
  svm: trident_svm
  credentials:
    name: backend-tbc-ontap-san-secret

También puede echar un vistazo a los ejemplos de la "instalador de trident" directorio para configuraciones de ejemplo para la plataforma o servicio de almacenamiento que desee.

La spec toma parámetros de configuración específicos del back-end. En este ejemplo, el back-end utiliza el ontap-san controlador de almacenamiento y utiliza los parámetros de configuración que se tabulan aquí. Para obtener la lista de opciones de configuración para el controlador de almacenamiento deseado, consulte la "información de configuración del back-end para el controlador de almacenamiento".

La spec la sección también incluye credentials y.. deletionPolicy campos, que se introducen recientemente en TridentBackendConfig CR:

  • credentials: Este parámetro es un campo obligatorio y contiene las credenciales utilizadas para autenticarse con el sistema/servicio de almacenamiento. Este juego debe ser un secreto de Kubernetes creado por el usuario. Las credenciales no se pueden pasar en texto sin formato y se producirá un error.

  • deletionPolicy: Este campo define lo que debe suceder cuando TridentBackendConfig se ha eliminado. Puede ser necesario uno de los dos valores posibles:

    • delete: Esto resulta en la eliminación de ambos TridentBackendConfig CR y el back-end asociado. Este es el valor predeterminado.

    • retain: Cuando un TridentBackendConfig Se elimina la CR, la definición de backend seguirá estando presente y se puede gestionar con tridentctl. Establecimiento de la política de eliminación como retain permite a los usuarios degradar a una versión anterior (anterior a 21.04) y conservar los back-ends creados. El valor de este campo se puede actualizar después de un TridentBackendConfig se ha creado.

Nota El nombre de un back-end se define mediante spec.backendName. Si no se especifica, el nombre del backend se establece en el nombre del TridentBackendConfig objeto (metadata.name). Se recomienda establecer explícitamente nombres de backend mediante spec.backendName.
Consejo Los back-ends que se crearon con tridentctl no tienen un objeto asociado TridentBackendConfig. Puede optar por gestionar dichos back-ends con kubectl creando una TridentBackendConfig CR. Se debe tener cuidado de especificar parámetros de configuración idénticos ( spec.backendName`como , , , `spec.storagePrefix spec.storageDriverName etc.). Trident enlazará automáticamente los recién creados TridentBackendConfig con el backend preexistente.

Descripción general de los pasos

Para crear un nuevo back-end mediante kubectl, debe hacer lo siguiente:

  1. Create a "Secreto Kubernetes". El secreto contiene las credenciales que Trident necesita para comunicarse con el clúster/servicio de almacenamiento.

  2. Cree un TridentBackendConfig objeto. Este contiene detalles sobre el servicio/clúster de almacenamiento y hace referencia al secreto creado en el paso anterior.

Después de crear un backend, puede observar su estado utilizando kubectl get tbc <tbc-name> -n <trident-namespace> y recopile detalles adicionales.

Paso 1: Cree un secreto de Kubernetes

Cree un secreto que contenga las credenciales de acceso para el back-end. Esto es único para cada servicio/plataforma de almacenamiento. Veamos un ejemplo:

kubectl -n trident create -f backend-tbc-ontap-san-secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: backend-tbc-ontap-san-secret
type: Opaque
stringData:
  username: cluster-admin
  password: password

Esta tabla resume los campos que deben incluirse en el secreto para cada plataforma de almacenamiento:

Descripción de campos secretos de la plataforma de almacenamiento Secreto Descripción de los campos

Azure NetApp Files

ID del Cliente

El ID de cliente de un registro de aplicación

Element (HCI/SolidFire de NetApp)

Extremo

MVIP para el clúster de SolidFire con credenciales de inquilino

ONTAP

nombre de usuario

Nombre de usuario para conectarse al clúster/SVM. Se utiliza para autenticación basada en credenciales

ONTAP

contraseña

Contraseña para conectarse al clúster/SVM. Se utiliza para autenticación basada en credenciales

ONTAP

ClientPrivateKey

Valor codificado en base64 de la clave privada de cliente. Se utiliza para autenticación basada en certificados

ONTAP

ChapUsername

Nombre de usuario entrante. Necesario si useCHAP=true. Para ontap-san y.. ontap-san-economy

ONTAP

InitichapatorSecret

Secreto CHAP del iniciador. Necesario si useCHAP=true. Para ontap-san y.. ontap-san-economy

ONTAP

ChapTargetUsername

Nombre de usuario de destino. Necesario si useCHAP=true. Para ontap-san y.. ontap-san-economy

ONTAP

ChapTargetInitiatorSecret

Secreto CHAP del iniciador de destino. Necesario si useCHAP=true. Para ontap-san y.. ontap-san-economy

El secreto creado en este paso será referenciado en el spec.credentials del TridentBackendConfig objeto creado en el paso siguiente.

Paso 2: Cree la TridentBackendConfig CR

Ya está listo para crear su TridentBackendConfig CR. En este ejemplo, un back-end que utiliza ontap-san el controlador se crea mediante TridentBackendConfig objeto mostrado a continuación:

kubectl -n trident create -f backend-tbc-ontap-san.yaml
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: backend-tbc-ontap-san
spec:
  version: 1
  backendName: ontap-san-backend
  storageDriverName: ontap-san
  managementLIF: 10.0.0.1
  dataLIF: 10.0.0.2
  svm: trident_svm
  credentials:
    name: backend-tbc-ontap-san-secret

Paso 3: Compruebe el estado del TridentBackendConfig CR

Ahora que creó la TridentBackendConfig CR, puede comprobar el estado. Consulte el siguiente ejemplo:

kubectl -n trident get tbc backend-tbc-ontap-san
NAME                    BACKEND NAME          BACKEND UUID                           PHASE   STATUS
backend-tbc-ontap-san   ontap-san-backend     8d24fce7-6f60-4d4a-8ef6-bab2699e6ab8   Bound   Success

Se ha creado un backend correctamente y se ha enlazado a TridentBackendConfig CR.

La fase puede tomar uno de los siguientes valores:

  • Bound: La TridentBackendConfig CR está asociado con un backend, y ese backend contiene configRef establezca en la TridentBackendConfig UID de CR.

  • Unbound: Representado usando "". La TridentBackendConfig el objeto no está enlazado a un back-end. Creadas recientemente TridentBackendConfig CRS se encuentra en esta fase de forma predeterminada. Tras cambiar la fase, no puede volver a «sin límites».

  • Deleting: La TridentBackendConfig CR deletionPolicy se ha configurado para eliminar. Cuando la TridentBackendConfig La CR se elimina y pasa al estado de supresión.

    • Si no existen reclamaciones de volumen persistentes (RVP) en el back-end, si se elimina el Trident, tanto el TridentBackendConfig back-end como la TridentBackendConfig CR.

    • Si uno o más EVs están presentes en el backend, pasa a un estado de supresión. La TridentBackendConfig Posteriormente, CR también entra en fase de eliminación. El back-end y. TridentBackendConfig Se eliminan sólo después de que se hayan eliminado todas las EVs.

  • Lost: El backend asociado con TridentBackendConfig La CR se eliminó accidental o deliberadamente y la TridentBackendConfig CR todavía tiene una referencia al backend eliminado. La TridentBackendConfig La CR puede ser eliminada independientemente de la deletionPolicy valor.

  • Unknown: Trident no puede determinar el estado o la existencia del backend asociado al TridentBackendConfig CR. Por ejemplo, si el servidor API no responde o si falta el tridentbackends.trident.netapp.io CRD. Esto puede requerir intervención.

En esta fase, se ha creado un backend. Hay varias operaciones que se pueden realizar además, como "actualizaciones back-end y eliminaciones backend".

(Opcional) Paso 4: Obtener más detalles

Puede ejecutar el siguiente comando para obtener más información acerca de su entorno de administración:

kubectl -n trident get tbc backend-tbc-ontap-san -o wide
NAME                    BACKEND NAME        BACKEND UUID                           PHASE   STATUS    STORAGE DRIVER   DELETION POLICY
backend-tbc-ontap-san   ontap-san-backend   8d24fce7-6f60-4d4a-8ef6-bab2699e6ab8   Bound   Success   ontap-san        delete

Además, también puede obtener un volcado YLMA/JSON de TridentBackendConfig.

kubectl -n trident get tbc backend-tbc-ontap-san -o yaml
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  creationTimestamp: 2021-04-21T20:45:11Z
  finalizers:
    - trident.netapp.io
  generation: 1
  name: backend-tbc-ontap-san
  namespace: trident
  resourceVersion: "947143"
  uid: 35b9d777-109f-43d5-8077-c74a4559d09c
spec:
  backendName: ontap-san-backend
  credentials:
    name: backend-tbc-ontap-san-secret
  managementLIF: 10.0.0.1
  dataLIF: 10.0.0.2
  storageDriverName: ontap-san
  svm: trident_svm
  version: 1
status:
  backendInfo:
    backendName: ontap-san-backend
    backendUUID: 8d24fce7-6f60-4d4a-8ef6-bab2699e6ab8
  deletionPolicy: delete
  lastOperationStatus: Success
  message: Backend 'ontap-san-backend' created
  phase: Bound

backendInfo Contiene los backendName y el backendUUID del backend que se creó en respuesta a la TridentBackendConfig CR. El lastOperationStatus campo representa el estado de la última operación TridentBackendConfig del CR, que puede ser activada por el usuario (por ejemplo, el usuario cambió algo en spec) o activada por Trident (por ejemplo, durante los reinicios de Trident). Puede ser Success o Failed. phase Representa el estado de la relación entre TridentBackendConfig el CR y el backend. En el ejemplo anterior, phase tiene el valor bound, lo que significa que TridentBackendConfig el CR está asociado al backend.

Puede ejecutar el kubectl -n trident describe tbc <tbc-cr-name> comando para obtener detalles de los registros de eventos.

Advertencia No puede actualizar ni eliminar un backend que contenga un archivo asociado TridentBackendConfig objeto con tridentctl. Comprender los pasos que implica cambiar entre tridentctl y.. TridentBackendConfig, "ver aquí".