Skip to main content
O português é fornecido por meio de tradução automática para sua conveniência. O inglês precede o português em caso de inconsistências.

Crie backends com kubectl

Colaboradores
PDFs

Um back-end define a relação entre o Trident e um sistema de storage. Ele informa à Trident como se comunicar com esse sistema de storage e como o Trident deve provisionar volumes a partir dele. Após a instalação do Trident, a próxima etapa é criar um backend. A TridentBackendConfig Definição de recursos personalizada (CRD) permite criar e gerenciar backends Trident diretamente por meio da interface do Kubernetes. Para fazer isso, use kubectl ou a ferramenta CLI equivalente para sua distribuição do Kubernetes.

TridentBackendConfig

TridentBackendConfig(tbc tbconfig, , tbackendconfig) É um CRD com namespaces e frontend que permite gerenciar backends Trident usando kubectl`o . Agora, os administradores de storage e Kubernetes podem criar e gerenciar back-ends diretamente pela CLI do Kubernetes sem exigir um utilitário de linha de comando dedicado (`tridentctl).

Após a criação de TridentBackendConfig um objeto, acontece o seguinte:

  • Um back-end é criado automaticamente pelo Trident com base na configuração que você fornece. Isto é representado internamente como um TridentBackend (tbe, tridentbackend ) CR.

  • O TridentBackendConfig é exclusivamente vinculado a um TridentBackend que foi criado por Trident.

Cada TridentBackendConfig um mantém um mapeamento um-para-um com um TridentBackend. o primeiro é a interface fornecida ao usuário para projetar e configurar backends; o último é como o Trident representa o objeto backend real.

Aviso TridentBackend Os CRS são criados automaticamente pelo Trident. Você não deve modificá-los. Se você quiser fazer atualizações para backends, faça isso modificando o TridentBackendConfig objeto.

Veja o exemplo a seguir para o formato do 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

Você também pode dar uma olhada nos exemplos "instalador do Trident" no diretório para configurações de exemplo para a plataforma/serviço de armazenamento desejado.

O spec utiliza parâmetros de configuração específicos do back-end. Neste exemplo, o backend usa o ontap-san driver de armazenamento e usa os parâmetros de configuração que são tabulados aqui. Para obter a lista de opções de configuração para o driver de armazenamento desejado, consulte o "informações de configuração de back-end para seu driver de armazenamento".

A spec seção também inclui credentials campos e deletionPolicy, que são recentemente introduzidos no TridentBackendConfig CR:

  • credentials: Este parâmetro é um campo obrigatório e contém as credenciais usadas para autenticar com o sistema/serviço de armazenamento. Isso é definido como um segredo do Kubernetes criado pelo usuário. As credenciais não podem ser passadas em texto simples e resultarão em um erro.

  • deletionPolicy: Este campo define o que deve acontecer quando o TridentBackendConfig é excluído. Pode tomar um dos dois valores possíveis:

    • delete: Isso resulta na exclusão do TridentBackendConfig CR e do back-end associado. Este é o valor padrão.

    • retain: Quando um TridentBackendConfig CR é excluído, a definição de back-end ainda estará presente e poderá ser gerenciada com tridentctl`o . Definir a política de exclusão para `retain permitir que os usuários façam o downgrade para uma versão anterior (anterior a 21,04) e mantenham os backends criados. O valor para este campo pode ser atualizado após a criação de um TridentBackendConfig.

Observação O nome de um back-end é definido usando spec.backendName. Se não for especificado, o nome do backend é definido como o nome do TridentBackendConfig objeto (metadata.name). Recomenda-se definir explicitamente nomes de back-end usando `spec.backendName`o .
Dica Backends que foram criados com tridentctl não têm um objeto associado TridentBackendConfig. Você pode optar por gerenciar esses backends kubectl criando um TridentBackendConfig CR. Deve-se ter cuidado para especificar parâmetros de configuração idênticos (como spec.backendName , , spec.storagePrefix, spec.storageDriverName e assim por diante). O Trident vinculará automaticamente o recém-criado TridentBackendConfig com o back-end pré-existente.

Visão geral dos passos

Para criar um novo back-end usando `kubectl`o , você deve fazer o seguinte:

  1. Criar um "Segredo do Kubernetes". o segredo contém as credenciais que o Trident precisa para se comunicar com o cluster/serviço de storage.

  2. Crie TridentBackendConfig um objeto. Isso contém detalhes sobre o cluster/serviço de armazenamento e faz referência ao segredo criado na etapa anterior.

Depois de criar um backend, você pode observar seu status usando kubectl get tbc <tbc-name> -n <trident-namespace> e coletar detalhes adicionais.

Etapa 1: Crie um segredo do Kubernetes

Crie um segredo que contenha as credenciais de acesso para o back-end. Isso é exclusivo para cada serviço/plataforma de storage. Aqui está um exemplo:

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: t@Ax@7q(>

Esta tabela resume os campos que devem ser incluídos no segredo para cada plataforma de armazenamento:

Descrição dos campos secretos da plataforma de armazenamento Segredo Descrição dos campos

Azure NetApp Files

ID do cliente

A ID do cliente a partir de um registo de aplicação

Cloud Volumes Service para GCP

private_key_id

ID da chave privada. Parte da chave da API para a conta de serviço do GCP com a função de administrador do CVS

Cloud Volumes Service para GCP

chave_privada

Chave privada. Parte da chave da API para a conta de serviço do GCP com a função de administrador do CVS

Elemento (NetApp HCI/SolidFire)

Endpoint

MVIP para o cluster SolidFire com credenciais de locatário

ONTAP

nome de utilizador

Nome de usuário para se conetar ao cluster/SVM. Usado para autenticação baseada em credenciais

ONTAP

palavra-passe

Senha para se conectar ao cluster/SVM. Usado para autenticação baseada em credenciais

ONTAP

ClientPrivateKey

Valor codificado em base64 da chave privada do cliente. Usado para autenticação baseada em certificado

ONTAP

ChapUsername

Nome de utilizador de entrada. Necessário se useCHAP-true. Para ontap-san e. ontap-san-economy

ONTAP

IniciadorSecreto

Segredo do iniciador CHAP. Necessário se useCHAP-true. Para ontap-san e. ontap-san-economy

ONTAP

ChapTargetUsername

Nome de utilizador alvo. Necessário se useCHAP-true. Para ontap-san e. ontap-san-economy

ONTAP

ChapTargetInitiatorSecret

Segredo do iniciador de destino CHAP. Necessário se useCHAP-true. Para ontap-san e. ontap-san-economy

O segredo criado nesta etapa será referenciado spec.credentials no campo do TridentBackendConfig objeto que é criado na próxima etapa.

Passo 2: Crie o TridentBackendConfig CR

Agora você está pronto para criar seu TridentBackendConfig CR. Neste exemplo, um back-end que usa ontap-san o driver é criado usando o TridentBackendConfig objeto mostrado abaixo:

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

Etapa 3: Verifique o status do TridentBackendConfig CR

Agora que criou o TridentBackendConfig CR, pode verificar o estado. Veja o exemplo a seguir:

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

Um backend foi criado com sucesso e vinculado ao TridentBackendConfig CR.

A fase pode ter um dos seguintes valores:

  • Bound: O TridentBackendConfig CR está associado a um back-end, e esse backend contém configRef definido como TridentBackendConfig uid do CR.

  • Unbound: Representado "" usando . O TridentBackendConfig objeto não está vinculado a um backend. Todos os CRS recém-criados TridentBackendConfig estão nesta fase por padrão. Após as alterações de fase, ela não pode voltar a Unbound.

  • Deleting: Os TridentBackendConfig CR's deletionPolicy foram definidos para eliminar. Quando o TridentBackendConfig CR é excluído, ele passa para o estado de exclusão.

    • Se não existirem declarações de volume persistentes (PVCs) no back-end, a exclusão do resultará na exclusão do TridentBackendConfig Trident do back-end, bem como do TridentBackendConfig CR.

    • Se um ou mais PVCs estiverem presentes no back-end, ele vai para um estado de exclusão. Posteriormente, o TridentBackendConfig CR entra também na fase de eliminação. O back-end e TridentBackendConfig são excluídos somente depois que todos os PVCs são excluídos.

  • Lost: O back-end associado ao TridentBackendConfig CR foi acidentalmente ou deliberadamente excluído e o TridentBackendConfig CR ainda tem uma referência ao back-end excluído. O TridentBackendConfig CR ainda pode ser eliminado independentemente do deletionPolicy valor.

  • Unknown: O Trident não consegue determinar o estado ou a existência do back-end associado ao TridentBackendConfig CR. Por exemplo, se o servidor de API não estiver respondendo ou se o tridentbackends.trident.netapp.io CRD estiver ausente. Isso pode exigir intervenção.

Nesta fase, um backend é criado com sucesso! Existem várias operações que podem ser tratadas adicionalmente, "atualizações de back-end e exclusões de back-end"como o .

(Opcional) passo 4: Obtenha mais detalhes

Você pode executar o seguinte comando para obter mais informações sobre seu back-end:

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

Além disso, você também pode obter um despejo YAML/JSON do 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 Contém o backendName e o backendUUID do back-end criado em resposta ao TridentBackendConfig CR. O lastOperationStatus campo representa o status da última operação do TridentBackendConfig CR, que pode ser acionada pelo usuário (por exemplo, o usuário mudou algo no spec) ou acionado pelo Trident (por exemplo, durante reinicializações do Trident). Pode ser sucesso ou falhou. phase Representa o status da relação entre o TridentBackendConfig CR e o back-end. No exemplo acima, phase tem o valor vinculado, o que significa que o TridentBackendConfig CR está associado ao back-end.

Você pode executar o kubectl -n trident describe tbc <tbc-cr-name> comando para obter detalhes dos logs de eventos.

Aviso Não é possível atualizar ou excluir um back-end que contenha um objeto tridentctl associado TridentBackendConfig usando o . Compreender as etapas envolvidas na troca entre tridentctl e TridentBackendConfig, "veja aqui".