Score:0

Kubernetes NGINX Ingress Controller Failure using Helm on AKS

in flag

When going through the setup of a K8 ingress controller, which is documented here

I am unable to get past the step of "Create an Ingress Controller" During the Helm command step and placing the command in debug mode, I see there is a timeout on one of the steps:

failed pre-install: timed out waiting for the condition

After reviewing the K8 POD logs, I found that the K8 system is unable to connect to the registry due to an auth error. The following output has been modified for security reasons but shows the 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]

I have verified that the images are located in the container registry based on the "az acr import" command, and that if I do a standard K8 deployment using "kubectl" , the k8 is able to connect to the acr. I have also verified the connection between the cluster and the registry using the following command it works as expected:

az aks check-acr -n <cluster> -g <rg>  --acr <acr>

This failure only occurs when using the helm command.

EDIT

After researching this more, I found the following article

https://stackoverflow.com/questions/68949434/installing-nginx-ingress-controller-into-aks-cluster-cant-pull-image-from-azu

It appears there is a problem with the digest. I added/replaced the following in the helm command:

--set controller.image.digest="sha256:e9fb216ace49dfa4a5983b183067e97496e7a8b307d2093f4278cd550c303899" \
--set controller.admissionWebhooks.patch.image.digest="sha256:950833e19ade18cd389d647efb88992a7cc077abedef343fa59e012d376d79b7" \

However, when running the modified helm command, the PODs are in an error state with the following error

unknown flag: --controller-class

I tried setting the env variable CONTROLLER_TAG=v1.0.0, as documented in the article but this does not help

Another solution is to set the version number: 3.36.0 in the command. This is successful but requires a downgraded version

Score:1
in flag

After reaching out to the MS document site feedback, they provided me with the following fix for this document

https://github.com/MicrosoftDocs/azure-docs/issues/80321

After rolling back and reapplying the modified changes, the command was successful. The key was to remove the pod using the helm uninstall command:

helm uninstall nginx-ingress --namespace ingress-basic

Then removing the ACR repositories from your ACR:

jettech/kube-webhook-certgen
defaultbackend-amd64
jetstack/cert-manager-controller
jetstack/cert-manager-webhook
jetstack/cert-manager-cainjector

which were created with the "az acr import" command and then rerunning the modified commands.

Hopefully someone finds this of value

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.