Deploy NGINX Ingress Controller

In this section you will configure and deploy the NGINX Ingress Controller and expose it using an Application Load Balancer that will terminate TLS with an ACM certificate.

Note

We recommend that you use a new NGINX Ingress Controller dedicated for serving. In this case, proceed to follow this guide.

Otherwise, if you have exposed EKF with ALB and you wish to use the NGINX Ingress Controller you have already created, expand the box below and follow the fast-forward path.

Fast Forward

If you have already deployed NGINX Ingress Controller for serving, expand this box to fast-forward.

  1. Specify the list of trusted inbound CIDRs of your ALB:

    root@rok-tools:~# export SERVING_EKS_ALB_NGINX_TRUSTED_CIDRS=<CIDRS>

  2. Specify the address of the ALB:

    root@rok-tools:~# export SERVING_EKS_ALB_NGINX_HOSTNAME=<HOSTNAME>

  3. Go to your GitOps repository, inside your rok-tools management environment:

    root@rok-tools:~# cd ~/ops/deployments

  4. Save your state:

    root@rok-tools:~/ops/deployments# j2 deploy/env.serving-eks-alb-nginx.j2 \ > -o deploy/env.serving-eks-alb-nginx

  5. Commit your changes:

    root@rok-tools:~/ops/deployments# git commit -am "Deploy NGINX Ingress Controller for Serving"

  6. Proceed to the Verify section.

See also

Choose one of the following options to deploy NGINX Ingress Controller:

Option 1: Deploy NGINX Ingress Controller Automatically (preferred)

Under construction

This section is a work in progress. Use Option 2: Deploy NGINX Ingress Controller Manually instead.

Deploy NGINX Ingress Controller by following the on-screen instructions on the rok-deploy user interface.

If rok-deploy is not already running, start it with:

root@rok-tools:~# rok-deploy --run-from serving-eks-alb-nginx
../../../../_images/eks-alb-nginx.png

Proceed to the Summary section.

Option 2: Deploy NGINX Ingress Controller Manually

If you want to deploy NGINX Ingress Controller manually, follow the instructions below.

Procedure

  1. Go to your GitOps repository, inside your rok-tools management environment:

    root@rok-tools:~# cd ~/ops/deployments

  2. Restore the required context from previous sections:

    root@rok-tools:~/ops/deployments# source <(cat deploy/env.{serving-eks-alb-subnets,serving-eks-alb-acm})
    root@rok-tools:~/ops/deployments# export SERVING_EKS_ALB_SCHEME SERVING_EKS_ALB_ACM_SUBDOMAIN \ > SERVING_EKS_ALB_ACM_CERT

  3. Edit rok/nginx-ingress-controller-serving/overlays/deploy/kustomization.yaml and use ingress-alb as base:

    bases: #- ../arrikto - ../ingress-alb #- ../service-elb #- ../service-azurelb #- ../service-gclb

  4. Edit rok/nginx-ingress-controller-serving/overlays/deploy/kustomization.yaml and enable only the ingress-alb and service-alb patches:

    patches: - path: patches/ingress-alb.yaml - path: patches/service-alb.yaml #- path: patches/service-elb.yaml #- path: patches/service-azurelb.yaml #- path: patches/service-gclb.yaml

  5. Enable the firewall in your Application Load Balancer and allow access only to specific CIDRs. Choose one of the following options, based on your ALB scheme:

    Public ALB

    Private ALB

    Specify the list of trusted inbound CIDRs for the ALB:

    root@rok-tools:~/ops/deployments# export SERVING_EKS_ALB_NGINX_TRUSTED_CIDRS=<CIDRS>

    Replace <CIDRS> with the desired value. Leave the default value of 0.0.0.0/0 if you want to allow access for everyone. For example:

    root@rok-tools:~/ops/deployments# export SERVING_EKS_ALB_NGINX_TRUSTED_CIDRS="0.0.0.0/0"

    See also

    Specify the list of trusted inbound CIDRs for the ALB:

    root@rok-tools:~/ops/deployments# export SERVING_EKS_ALB_NGINX_TRUSTED_CIDRS=<CIDRS>

    Replace <CIDRS> with the desired value. Leave the default value of 0.0.0.0/0 if you want to allow access for everyone within the VPC. For example:

    root@rok-tools:~/ops/deployments# export SERVING_EKS_ALB_NGINX_TRUSTED_CIDRS="0.0.0.0/0"

    Note

    Note that, since the Application Load Balancer will be an internal one, it already accepts connections only from within the VPC. Use the trusted CIDRs as an extra access control mechanism for controlling connections from within the VPC.

    Note

    You can set multiple trusted inbound CIDRs by specifying them as a string list (comma separated list). For more information, see the official AWS Load Balancer Controller docs.

  6. Render the NGINX Ingress Controller ingress patch template with the variables you have specified:

    root@rok-tools:~/ops/deployments# j2 \ > rok/nginx-ingress-controller-serving/overlays/deploy/patches/ingress-alb.yaml.j2 \ > -o rok/nginx-ingress-controller-serving/overlays/deploy/patches/ingress-alb.yaml

  7. Deploy NGINX Ingress Controller:

    root@rok-tools:~/ops/deployments# rok-deploy --apply rok/nginx-ingress-controller-serving/overlays/deploy

  8. Wait until the AWS Load Balancer Controller provisions the necessary AWS resources:

    $ kubectl get ingress -n ingress-nginx-serving NAME HOSTS ADDRESS PORTS AGE ingress-nginx * e53a524a-ingressnginx-ingr-1234-592794601.eu-central-1.elb.amazonaws.com 80 64d

    Troubleshooting

    The Ingress object does not get an ADDRESS.

    1. Inspect the logs of aws-load-balancer-controller deployment in the kube-system namespace:

      root@rok-tools:~/ops/deployments# kubectl logs -n kube-system deploy/aws-load-balancer-controller

      If you see a message like the following:

      "msg"="Reconciler error" "error"="failed to build LoadBalancer configuration due to retrieval of subnets failed to resolve 2 qualified subnets.

      it means that your subnets are misconfigured.

    2. Verify your subnets configuration.

  9. Obtain the address of the ALB:

    root@rok-tools:~/ops/deployments# export SERVING_EKS_ALB_NGINX_HOSTNAME=$(kubectl get ingress \ > -n ingress-nginx-serving ingress-nginx -o json \ > | jq -r '.status.loadBalancer.ingress[].hostname')

  10. Render the NGINX Ingress Controller service patch template with the variables you have specified:

    root@rok-tools:~/ops/deployments# j2 \ > rok/nginx-ingress-controller-serving/overlays/deploy/patches/service-alb.yaml.j2 \ > -o rok/nginx-ingress-controller-serving/overlays/deploy/patches/service-alb.yaml

  11. Save your state:

    root@rok-tools:~/ops/deployments# j2 deploy/env.serving-eks-alb-nginx.j2 \ > -o deploy/env.serving-eks-alb-nginx

  12. Commit your changes:

    root@rok-tools:~/ops/deployments# git commit -am "Deploy NGINX Ingress Controller for Serving"

  13. Re-apply the manifests:

    root@rok-tools:~/ops/deployments# rok-deploy --apply rok/nginx-ingress-controller-serving/overlays/deploy

Verify

  1. Verify that NGINX Ingress Controller is up-and-running. Check pod status and verify field STATUS is Running and field READY is 1/1:

    root@rok-tools:~# kubectl -n ingress-nginx-serving get pods NAME READY STATUS RESTARTS AGE nginx-ingress-controller-7f74f657bd-ln59l 1/1 Running 0 1m

  2. Verify that the ALB Ingress has obtained an address:

    root@rok-tools:~# kubectl -n ingress-nginx-serving get ingress NAME CLASS HOSTS ADDRESS PORT(S) AGE ingress-nginx <none> * e53a524a-ingressnginx-ingr-8872-592794601.us-east-1.elb.amazonaws.com 80 1m

  3. Verify that the ingress-nginx service has an external IP equal to the address of the ALB:

    root@rok-tools:~# kubectl -n ingress-nginx-serving get service ingress-nginx NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE ingress-nginx ExternalName <none> e53a524a-ingressnginx-ingr-8872-592794601.us-east-1.elb.amazonaws.com <none> 1m

Summary

You have successfully deployed the NGINX Ingress Controller and exposed it using an Application Load Balancer

What’s Next

The next step is to expose Istio.