Usar um registro de contêiner externo com Tanzu Kubernetes clusters

Você pode usar um registro de contêiner externo com Tanzu Kubernetes pods de cluster. Esta é uma alternativa ao uso do Harbor Registry incorporado.

Caso de uso de registro privado externo

Os registros de contêiner fornecem uma função crítica para implantações do Kubernetes, servindo como um repositório centralizado para armazenar e compartilhar imagens de contêiner. O registro de contêiner público mais comumente usado é o DockerHub . Há muitas ofertas de registro de contêineres privados. VMware Harbor é um registro de contêiner privado de código aberto, nativo da nuvem. vSphere with Tanzu incorpora uma instância do Harbor que você pode usar como o registro de contêiner privado para vSphere Pods e para pods em execução em clusters do Tanzu Kubernetes. Para obter mais informações, consulte Ative o Harbor Registry incorporado no Supervisor Cluster.

O Harbor Registry incorporado que vem com o vSphere with Tanzu requer NSX-T rede. Se você estiver usando a rede do vSphere, não poderá usá-la. Além disso, você pode já estar executando seu próprio registro de contêiner privado que deseja integrar com seus clusters do Tanzu Kubernetes. Nesse caso, você pode configurar o Tanzu Kubernetes Grid Service para confiar em registros privados com certificados autoassinados, permitindo que os pods do Kubernetes em execução nos clusters do Tanzu Kubernetes usem o registro externo.

Requisitos de registro privado externo

Para usar um registro privado externo com clusters do Tanzu Kubernetes, você deve usar o U2 da versão 7 do vSphere with Tanzu ou posterior.

Você só pode usar seu próprio registro privado com pods do Kubernetes que são executados em Tanzu Kubernetes clusters e Tanzu Kubernetes release VMs de nó. Você não pode usar seu próprio registro privado com o vSphere Pods que é executado nativamente em hosts ESXi. O registro com suporte para vSphere Pods é o Harbor Registry que está incorporado na plataforma vSphere with Tanzu.

Depois de configurar o Tanzu Kubernetes Grid Service para um registro privado, qualquer novo cluster provisionado oferecerá suporte ao registro privado. Para que os clusters existentes ofereçam suporte ao registro privado, é necessária uma atualização contínua para aplicar o TkgServiceConfiguration. Consulte Atualizar Tanzu Kubernetes clusters. Além disso, na primeira vez que você criar um TkgServiceConfiguration personalizado, o sistema iniciará uma atualização contínua.

Configuração de registro privado externo

Para usar seu próprio registro privado com clusters do Tanzu Kubernetes, configure o Tanzu Kubernetes Grid Service com um ou mais certificados autoassinados para servir o conteúdo do registro privado sobre HTTPS.

O TkgServiceConfiguration é atualizado para oferecer suporte a certificados autoassinados para o registro privado. Especificamente, uma nova seção trust com o campo additionalTrustedCAs é adicionada, permitindo que você defina qualquer número de certificados autoassinados nos quais os clusters do Tanzu Kubernetes devem confiar. Essa funcionalidade permite que você defina facilmente uma lista de certificados e atualize esses certificados caso eles precisem de rotação.

Depois que o TkgServiceConfiguration for atualizado e aplicado, os certificados TLS serão aplicados a novos clusters na próxima vez que um cluster for criado. Em outras palavras, a aplicação de uma atualização para TkgServiceConfiguration.trust.additionalTrustedCAs não aciona uma atualização contínua automática de Tanzu Kubernetes clusters.

apiVersion: run.tanzu.vmware.com/v1alpha1
kind: TkgServiceConfiguration
metadata:
  name: tkg-service-configuration
spec:
  defaultCNI: antrea
  trust:
    additionalTrustedCAs:
      - name: first-cert-name
        data: base64-encoded string of a PEM encoded public cert 1
      - name: second-cert-name
        data: base64-encoded string of a PEM encoded public cert 2

Para aplicar a atualização, execute o seguinte comando.

kubectl apply -f tkgserviceconfiguration.yaml

Como a especificação do Tanzu Kubernetes Grid Service está sendo atualizada com os certificados de registro privado, você não precisa adicionar a chave pública ao kubeconfig do cluster Tanzu Kubernetes como você faz ao usar o Harbor Registry incorporado com os clusters do Tanzu Kubernetes.

Configurar uma Tanzu Kubernetes carga de trabalho para extrair imagens de um registro de contêiner privado

Para obter imagens de um registro de contêiner privado para uma carga de trabalho de cluster do Tanzu Kubernetes, configure o YAML da carga de trabalho com os detalhes do registro privado.

Esse procedimento pode ser usado para extrair imagens de um registro de contêiner privado ou do Harbor Registry incorporado. Neste exemplo, criamos uma especificação de pod que usará uma imagem armazenada no Harbor Registry incorporado e usará o segredo de recepção de imagem configurado anteriormente.

1. Crie uma especificação de pod de exemplo com os detalhes sobre o registro privado.

   apiVersion: v1
   kind: Pod
   metadata:
     name: <workload-name>
     namespace: <kubernetes-namespace>
   spec:
     containers:
     - name: private-reg-container
       image: <Registry-IP-Address>/<vsphere-namespace>/<image-name>:<version>
     imagePullSecrets:
     - name: <registry-secret-name>

   • Substitua <workload-name> pelo nome da carga de trabalho do pod.
   • Substitua <kubernetes-namespace> pelo namespace Kubernetes no cluster em que o pod será criado. Deve ser o mesmo namespace do Kubernetes no qual o segredo de recepção da imagem do Serviço de Registro está armazenado no cluster Tanzu Kubernetes (como o namespace padrão).
   • Substitua <Registry-IP-Address> pelo endereço IP da instância Harbor Registry incorporada em execução no Supervisor Cluster.
   • Substitua <vsphere-namespace> pelo vSphere Namespace onde o destino Tanzu Kubernetes está provisionado.
   • Substitua <image-name> por um nome de imagem de sua escolha.
   • Substitua <version> por uma versão apropriada da imagem, como "mais recente".
   • Substitua <registry-secret-name> pelo nome do segredo de recepção da imagem do Serviço de Registro que você criou anteriormente.
2. Crie uma carga de trabalho no cluster Tanzu Kubernetes com base na especificação do pod que você definiu.

   kubectl --kubeconfig=<path>/cluster-kubeconfig apply -f <pod.yaml>

   O pod deve ser criado a partir da imagem extraída do registro.

Campos de confiança para registros privados externos

Adicione uma entrada de certificado (cadeia de caracteres codificada em base64 de um certificado público codificado em PEM) à seção additionalTrustedCAs no TkgServiceConfiguration. Os dados são certificados públicos armazenados em texto sem formatação no TkgServiceConfiguration.

Tabela 1. Campos de confiança para registros privados

Campo	Descrição
trust	Marcador de seção. Não aceita dados.
additionalTrustedCAs	Marcador de seção. Inclui uma matriz de certificados com nome e dados para cada um.
name	O nome do certificado TLS.
data	A cadeia de caracteres codificada em base64 de um certificado público codificado por PEM.

Removendo certificados de registro privado externo

Remova um certificado da lista de certificados na seção additionalTrustedCAs no TkgServiceConfiguration e aplique o TkgServiceConfiguration ao Tanzu Kubernetes Grid Service.

Certificados de registro privado externo rotativo

Para alternar um certificado, o administrador de VI ou o engenheiro de DevOps alteraria o conteúdo do certificado na especificação do cluster TkgServiceConfiguration ou Tanzu Kubernetes e aplicaria essa configuração para acionar uma atualização contínua desse TKC.

Solução de problemas de certificados de registro privado externo

Se você configurar o Tanzu Kubernetes Grid Service com os certificados para confiar e adicionar o certificado autoassinado ao cluster kubeconfig, deverá ser capaz de extrair com êxito uma imagem de contêiner de um registro privado que usa esse certificado autoassinado.

O comando a seguir pode ajudar a determinar se a imagem do contêiner foi extraída com êxito para uma carga de trabalho de pod:

kubectl describe pod PODNAME

Esse comando mostra o status detalhado e as mensagens de erro para um determinado pod. Um exemplo de tentativa de extrair uma imagem antes de adicionar certificados personalizados ao cluster:

Events:
  Type     Reason                        Age               From               Message
  ----     ------                        ----              ----               -------
  Normal   Scheduled                     33s               default-scheduler  ...
  Normal   Image                         32s               image-controller   ...
  Normal   Image                         15s               image-controller   ...
  Normal   SuccessfulRealizeNSXResource  7s (x4 over 31s)  nsx-container-ncp  ...
  Normal   Pulling                       7s                kubelet            Waiting test-gc-e2e-demo-ns/testimage-8862e32f68d66f727d1baf13f7eddef5a5e64bbd-v10612
  Warning  Failed                        4s                kubelet            failed to get images: ... Error: ... x509: certificate signed by unknown authority

E, ao executar o seguinte comando:

kubectl get pods

O erro ErrImagePull também é visível na exibição geral do status do Pod:

NAME                                         READY   STATUS         RESTARTS   AGE
testimage-nginx-deployment-89d4fcff8-2d9pz   0/1     Pending        0          17s
testimage-nginx-deployment-89d4fcff8-7kp9d   0/1     ErrImagePull   0          79s
testimage-nginx-deployment-89d4fcff8-7mpkj   0/1     Pending        0          21s
testimage-nginx-deployment-89d4fcff8-fszth   0/1     ErrImagePull   0          50s
testimage-nginx-deployment-89d4fcff8-sjnjw   0/1     ErrImagePull   0          48s
testimage-nginx-deployment-89d4fcff8-xr5kg   0/1     ErrImagePull   0          79s

Os erros "x509: certificado assinado por autoridade desconhecida" e "ErrImagePull" indicam que o cluster não está configurado com o certificado correto para se conectar ao registro de contêiner privado. O certificado está ausente ou está configurado incorretamente.

Se você estiver enfrentando erros ao se conectar a um registro privado depois de configurar os certificados, poderá verificar se os certificados aplicados na configuração são aplicados ao cluster. Você pode verificar se os certificados foram aplicados em sua configuração usando o SSH.

Duas etapas de investigação podem ser realizadas conectando-se a um nó de trabalhador por SSH.

1. Verifique a pasta /etc/ssl/certs/ para arquivos denominados tkg-<cert_name>.pem, onde <cert_name> é a propriedade "name" do certificado adicionado em TkgServiceConfiguration. Se os certificados corresponderem ao que está em TkgServiceConfiguration e o uso de um registro privado ainda não funcionar, faça um diagnóstico mais detalhado concluindo a próxima etapa.
2. Execute o seguinte teste de conexão openssl com o servidor de destino usando certificados autoassinados executando o comando openssl s_client -connect hostname:port_num, onde hostname é o nome do host / nome DNS do registro privado que está usando certificados autoassinados e port_num é o número da porta no qual o serviço está sendo executado (normalmente 443 para HTTPS). Você pode verificar exatamente qual erro está sendo retornado pelo openssl ao tentar se conectar ao endpoint que está usando certificados autoassinados e corrigir a situação a partir daí, por exemplo, adicionando os certificados corretos ao TkgServiceConfiguration. Se o cluster Tanzu Kubernetes estiver incorporado com o certificado errado, você precisará atualizar a configuração do Tanzu Kubernetes Grid Service com os certificados corretos, excluir o cluster Tanzu Kubernetes e recriá-lo usando a configuração que contém os certificados corretos.