I have an EKS cluster with the following set up
2 VPCS 1 prod, 1 stage
each vpc has 3 subnets 1 public and 2 private
each vpc has 1 internet gateway and 1 nat gateway
The private subnets are connected to the natgateway via route table association.
I have an eks cluster and an aws managed nodegroup
the nodegroup is mapped to the private subnets.
I installed an ingress-nginx controller that creates a network loadbalancer.
This network loadbalancer works perfectly in stage, but not in prod.
The network loadbalancers for both vpcs are create in the eu-north-1a zone
The target instance for the staging loadbalancer is created in the eu-north-1a zone while that of the prod loadbalancer is created in the eu-north-1b zone, and returns the following error:
Targets are not within enabled Availability Zones
Some targets are not receiving traffic because they are in Zones that are not enabled for your load balancer.
Unused target zones
eu-north-1b
To resolve
There are two options:
Enable these Zones on the load balancer by visiting the load balancer detail page and adding subnets in these Zones. View load balancer
Or, deregister targets that are in these Zones. View targets in unused Zones
```
So the staging and prod clusters are identical. The subnets and ingress-nginx configs are identical, everything is identical. But I can't seem to figure out why prod is failing, and staging is not. What could I be missing?
The values file for the ingress:
ingress-nginx:
controller:
replicaCount: 2
resources:
limits:
memory: 300Mi
requests:
memory: 256Mi
service:
annotations:
service.beta.kubernetes.io/aws-load-balancer-type: nlb
externalTrafficPolicy: Local
healthCheckNodePort: 30254
stats:
enabled: true
config:
client-max-body-size: "25m"
http-redirect-code: "301"
proxy-buffer-size: 128k
proxy-buffers: 4 256k
proxy-connect-timeout: "600"
proxy-read-timeout: "600"
ssl-ciphers: "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA"
ssl-protocols: "TLSv1.2 TLSv1.3"
# use-forwarded-headers: "true"
# use-proxy-protocol: "true"
# compute-full-forwarded-for: "true"
# enable-real-ip: "true"
# forwarded-for-header: X-Forwarded-For
log-format-upstream: '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$http_x_forwarded_for" $upstream_http_resonseHeaderName $ssl_protocol $ssl_cipher'
rbac:
create: true
serviceAccount:
create: true