You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Failed deploy model due to Internal error occurred: failed calling webhook "mtargetgroupbinding.elbv2.k8s.aws": Post "https://aws-load-balancer-webhook-service.kube-system.svc:443/mutate-elbv2-k8s-aws-v1beta1-targetgroupbinding?timeout=10s": x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "aws-load-balancer-controller-ca")
My setup is as follows:
Namespace A
Ingress A in group 'ingress-group-1'
Service 1
Service 2
Namespace B
Ingress B in group 'ingress-group-1'
Service 3
The Ingress resources have the same annotations. With the exception of group.order.
✅ The routing rules of both ingresses to be merged into a single list of rules on the 443 listener of the ALB.
✅ A *.example.com ACM certificate is automatically discovered and used for port 443.
❌ All traffic on port 80 is redirected to port 443. (✅ see update 1)
❌ The operator has no errors.
My expectations seem to be met relatively well, but the operator is reporting the above error nonetheless. Also, it seems the HTTP to HTTPS redirect is not working. Instead of redirecting, it actually makes the same routing rules on the ALB listener for port 80, connecting to the same target groups as the 443 listener.
Why am I getting the error?
Do my my expectations match the actual expected behaviour?
Update 1: the reason that the SSL redirect is not working is not related to the error it seems. I misconfigured the annotations. I'm missing the following rule in the ingress:
@Slijkhuis
How did you installed the controller? i assume you are using helm charts.
If using helm chart(and without using cert-manager), the chart should automatically generates a new cert on every install/upgrades.
The cert is stored as secret named aws-load-balancer-tls, you can view it by kubectl -n kube-system get secrets/aws-load-balancer-tls -o yaml
The cert's CA is configured in our two webhooks, which you can view by
kubectl get mutatingwebhookconfigurations/aws-load-balancer-webhook -o yaml
kubectl get validatingwebhookconfigurations/aws-load-balancer-webhook -o yaml
Would you help check whether the clientConfig.caBundle(which appears multiple times in each webhookConfiguration) mismatches with ca.crt in aws-load-balancer-tls secret?
If so, please update the clientConfig.caBundle to match ca.crt.
Not sure how this occurs, maybe during helm install, some resources didn't get updated correctly due to network issues
Thanks for pointing me in the right direction. I use the Helm chart indeed and I use ArgoCD to sync my configuration with the actual state on the cluster. It turns out that we configured ArgoCD to globally ignore some paths for checking sync status, which includes /webhooks/0/clientConfig/caBundle on admissionregistration.k8s.io/MutatingWebhookConfiguration and admissionregistration.k8s.io/ValidatingWebhookConfiguration. Clearly, this was causing the issue. After destroying aws-load-balancer-controller and recreating it everything worked smooth.
In short, it's a misconfiguration on my end. Thanks for helping me figure it out!
I'm getting the following error:
My setup is as follows:
The
Ingress
resources have the same annotations. With the exception ofgroup.order
.Uncollapse for the full YAMLs.
ingress-a.yml
:ingress-b.yml
in another namespace:My expectations (✅ = met, ❌ = not met):
*.example.com
ACM certificate is automatically discovered and used for port 443.❌ All traffic on port 80 is redirected to port 443.(✅ see update 1)My expectations seem to be met relatively well, but the operator is reporting the above error nonetheless.
Also, it seems the HTTP to HTTPS redirect is not working. Instead of redirecting, it actually makes the same routing rules on the ALB listener for port 80, connecting to the same target groups as the 443 listener.Why am I getting the error?
Do my my expectations match the actual expected behaviour?
Update 1: the reason that the SSL redirect is not working is not related to the error it seems. I misconfigured the annotations. I'm missing the following rule in the ingress:
Adding that rule actually resolves the redirect issue.
So, the only issue left is the error that the operator logs.
The text was updated successfully, but these errors were encountered: