Al realizar la configuración de un controlador de ingreso K8, que está documentadoaquí
No puedo pasar el paso de "Crear un controlador de ingreso". Durante el paso del comando Helm y al colocar el comando en modo de depuración, veo que hay un tiempo de espera en uno de los pasos:
preinstalación fallida: se agotó el tiempo de espera de la condición
Después de revisar los registros de K8 POD, descubrí que el sistema K8 no puede conectarse al registro debido a un error de autenticación. El siguiente resultado se ha modificado por razones de seguridad pero muestra el error
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]
He verificado que las imágenes están ubicadas en el registro del contenedor según el comando "az acr import" y que si hago una implementación estándar de K8 usando "kubectl", el k8 puede conectarse al acr. También verifiqué la conexión entre el clúster y el registro usando el siguiente comando y funciona como se esperaba:
az aks check-acr -n <cluster> -g <rg> --acr <acr>
Este error solo ocurre cuando se usa el comando helm.
EDITAR
Después de investigar esto más, encontré el siguiente artículo.
Parece que hay un problema con el resumen. Agregué/reemplacé lo siguiente en el comando de timón:
--set controller.image.digest="sha256:e9fb216ace49dfa4a5983b183067e97496e7a8b307d2093f4278cd550c303899" \
--set controller.admissionWebhooks.patch.image.digest="sha256:950833e19ade18cd389d647efb88992a7cc077abedef343fa59e012d376d79b7" \
Sin embargo, al ejecutar el comando helm modificado, los POD están en un estado de error con el siguiente error
unknown flag: --controller-class
Intenté configurar la variable env CONTROLLER_TAG=v1.0.0, como se documenta en el artículo, pero esto no ayuda
Otra solución es establecer el número de versión: 3.36.0 en el comando. Esto es exitoso pero requiere una versión degradada.
Respuesta1
Después de comunicarme con los comentarios del sitio de documentos de MS, me proporcionaron la siguiente solución para este documento
https://github.com/MicrosoftDocs/azure-docs/issues/80321
Después de revertir y volver a aplicar los cambios modificados, el comando se realizó correctamente. La clave era eliminar el pod usando el comando de desinstalación de helm:
helm uninstall nginx-ingress --namespace ingress-basic
Luego eliminando los repositorios ACR de su ACR:
jettech/kube-webhook-certgen
defaultbackend-amd64
jetstack/cert-manager-controller
jetstack/cert-manager-webhook
jetstack/cert-manager-cainjector
que se crearon con el comando "az acr import" y luego volver a ejecutar los comandos modificados.
Ojalá alguien encuentre esto de valor.
Respuesta2
deshabilite la autenticación en su registro de contenedor ACR por un tiempo:
az acr update --name my-acr-registry-name --anonymous-pull-enabled true
Vuelva a ejecutar el gráfico de timón y vuelva a habilitar la autenticación en su registro a medida que se crea el controlador.
az acr update --name my-acr-registry-name --anonymous-pull-enabled false
no es necesario cambiar de versión ni otras. Esto le salvará el día. Para aquellos de ustedes que piensan que tener un registro de contenedor acr público expuesto durante 9 segundos (el momento en que se ejecuta el controlador de ingreso) causará una guerra nuclear, pueden incluir en la lista blanca solo redes conocidas en la sección de redes de su acr para evitar accesos no deseados.