Ao passar pela configuração de um controlador de ingresso K8, que está documentadoaqui
Não consigo passar da etapa "Criar um controlador de ingresso". Durante a etapa de comando do Helm e colocando o comando no modo de depuração, vejo que há um tempo limite em uma das etapas:
falha na pré-instalação: tempo limite esgotado aguardando a condição
Depois de revisar os logs do K8 POD, descobri que o sistema K8 não consegue se conectar ao registro devido a um erro de autenticação. A saída a seguir foi modificada por motivos de segurança, mas mostra o erro
Failed to pull image "myregistry.azurecr.io/jettech/kube-webhook-certgen:v1.5.1@sha256:...90bd8068": [rpc error: code = NotFound desc = failed to pull and unpack image "....azurecr.io/jettech/kube-webhook-certgen@sha256:....9b9e90bd8068": failed to resolve reference "myregistry.azurecr.io/jettech/kube-webhook-certgen@sha256:...190b1dcbcb9b9e90bd8068": ....azurecr.io/jettech/kube-webhook-certgen@sha256:...9b9e90bd8068: not found, rpc error: code = Unknown desc = failed to pull and unpack image "myregistry.azurecr.io/jettech/kube-webhook-certgen@sha256:...dcbcb9b9e90bd8068": failed to resolve reference "myregistry.azurecr.io/jettech/kube-webhook-certgen@sha256:...b9b9e90bd8068": failed to authorize: failed to fetch anonymous token: unexpected status: 401 Unauthorized]
Verifiquei que as imagens estão localizadas no registro do contêiner com base no comando "az acr import" e que, se eu fizer uma implantação K8 padrão usando "kubectl" , o k8 poderá se conectar ao acr. Também verifiquei a conexão entre o cluster e o registro usando o seguinte comando e funciona conforme o esperado:
az aks check-acr -n <cluster> -g <rg> --acr <acr>
Esta falha ocorre apenas ao usar o comando helm.
EDITAR
Depois de pesquisar mais sobre isso, encontrei o seguinte artigo
Parece que há um problema com o resumo. Eu adicionei/substituí o seguinte no comando helm:
--set controller.image.digest="sha256:e9fb216ace49dfa4a5983b183067e97496e7a8b307d2093f4278cd550c303899" \
--set controller.admissionWebhooks.patch.image.digest="sha256:950833e19ade18cd389d647efb88992a7cc077abedef343fa59e012d376d79b7" \
No entanto, ao executar o comando helm modificado, os PODs ficam em estado de erro com o seguinte erro
unknown flag: --controller-class
Tentei definir a variável env CONTROLLER_TAG=v1.0.0, conforme documentado no artigo, mas isso não ajuda
Outra solução é definir o número da versão: 3.36.0 no comando. Isso foi bem-sucedido, mas requer uma versão desatualizada
Responder1
Depois de entrar em contato com o feedback do site do documento MS, eles me forneceram a seguinte correção para este documento
https://github.com/MicrosoftDocs/azure-docs/issues/80321
Após reverter e reaplicar as alterações modificadas, o comando foi bem-sucedido. A chave era remover o pod usando o comando de desinstalação do helm:
helm uninstall nginx-ingress --namespace ingress-basic
Em seguida, remova os repositórios ACR do seu ACR:
jettech/kube-webhook-certgen
defaultbackend-amd64
jetstack/cert-manager-controller
jetstack/cert-manager-webhook
jetstack/cert-manager-cainjector
que foram criados com o comando "az acr import" e, em seguida, executando novamente os comandos modificados.
Espero que alguém ache isso valioso
Responder2
desative a autenticação em seu registro de contêiner ACR por um tempo:
az acr update --name my-acr-registry-name --anonymous-pull-enabled true
execute novamente o gráfico do leme e reative a autenticação em seu registro conforme o controlador é criado
az acr update --name my-acr-registry-name --anonymous-pull-enabled false
não há necessidade de alterar a versão ou outras. Isto salvará o seu dia. Para aqueles que pensam que ter um registro de contêiner acr público exposto por 9 segundos (o tempo em que o controlador de entrada é executado) causará uma guerra nuclear, você pode colocar na lista de permissões apenas redes conhecidas na seção de rede do seu acr para evitar acesso indesejável