Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
Applies to SUSE Cloud Application Platform 1.5.2

4 Using an Ingress Controller with Cloud Application Platform

An Ingress controller (see https://kubernetes.io/docs/concepts/services-networking/ingress/) is a Kubernetes resource that manages traffic to services in a Kubernetes cluster.

Using an Ingress controller has the benefit of:

  • Having only one load balancer.

  • SSL can be terminated on the controller.

  • All traffic can be routed through ports 80 and 443 on the controller. Tracking different ports(for example, port 2793 for UAA, port (4)443 for Gorouter) is no longer needed. The Ingress routing rules will then manage the traffic flow to the appropriate backend services.

Note that only the NGINX Ingress Controller has been verified to be compatible with Cloud Application Platform. Other Ingress controller alternatives may work, but compatibility with Cloud Application Platform is not supported.

4.1 Deploying NGINX Ingress Controller

  1. Prepare your Kubernetes cluster according to the documentation for your platform. Proceed to the next step when you reach the uaa deployment phase for your platform. Note that the DNS sections in the platform-specific documentation can be omitted.

  2. Install the NGINX Ingress Controller.

    tux > helm install suse/nginx-ingress \
    --name nginx-ingress \
    --namespace ingress \
    --set rbac.create=true
  3. Monitor the progess of the deployment:

    tux > watch --color 'kubectl get pods --namespace ingress'
  4. After the deployment completes, the Ingress controller service will be deployed with either an external IP or a hostname. For SUSE CaaS Platform, Microsoft AKS, and Google GKE, this will be an IP and for Amazon EKS, it will be a hostname. Find the external IP or hostname.

    tux > kubectl get services nginx-ingress-controller --namespace ingress

    You will get output similar to the following.

    NAME                       TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)
    nginx-ingress-controller   LoadBalancer   10.63.248.70   35.233.191.177   80:30344/TCP,443:31386/TCP
  5. Set up appropriate DNS records (CNAME for Amazon EKS, A records for SUSE CaaS Platform, Microsoft AKS, and Google GKE) corresponding to the controller service IP or hostname with the following entries. Replace example.com with your actual domain.

    • example.com

    • *.example.com

    • uaa.example.com

    • *.uaa.example.com

  6. Obtain a PEM formatted certificate and ensure it includes Subject Alternative Names (SAN) for uaa and scf listed in the previous step.

  7. Add the following to your configuration file, scf-config-values.yaml, to trigger the creation of the Ingress objects. Ensure crt and key are encoded in the PEM format. Note the port changes, this ensures all communications to uaa are routed through the Ingress controller.

    The nginx.ingress.kubernetes.io/proxy-body-size value indicates the maximum client request body size. Actions such as pushing an application through cf push can result in larger request body sizes depending on the application type you work with. This value will need to be adapted to your workflow.

    UAA_PORT: 443
    UAA_PUBLIC_PORT: 443
    ...
    ingress:
      enabled: true
      annotations:
        nginx.ingress.kubernetes.io/proxy-body-size: 1024m
      tls:
        crt: |
          -----BEGIN CERTIFICATE-----
          MIIE8jCCAtqgAwIBAgIUT/Yu/Sv8AUl5zHXXEKCy5RKJqmYwDQYJKoZIhvcMOQMM
          [...]
          xC8x/+zB7XlvcRJRio6kk670+25ABP==
          -----END CERTIFICATE-----
        key: |
          -----BEGIN RSA PRIVATE KEY-----
          MIIE8jCCAtqgAwIBAgIUSI02lj2b2ImLy/zMrjNgW5d8EygwQSVJKoZIhvcYEGAW
          [...]
          to2WV7rPMb9W9fd2vVUXKKHTc+PiNg==
          -----END RSA PRIVATE KEY-----
  8. Deploy uaa.

    tux > helm install suse/uaa \
    --name susecf-uaa \
    --namespace uaa \
    --values scf-config-values.yaml

    Wait until you have a successful uaa deployment before going to the next steps, which you can monitor with the watch command:

    tux > watch --color 'kubectl get pods --namespace uaa'

    When uaa is successfully deployed, the following is observed:

    • For the secret-generation pod, the STATUS is Completed and the READY column is at 0/1.

    • All other pods have a Running STATUS and a READY value of n/n.

    Press CtrlC to exit the watch command.

  9. When all uaa pods are up and ready, verify uaa is working. Pass the CA certificate used to sign the Ingress controller certificate as the value of --cacert.

    tux > curl --cacert INGRESS_CONTROLLER_CA_CERT https://uaa.example.com/.well-known/openid-configuration
  10. Update the Ingress controller to set up TCP forwarding

    tux > helm upgrade nginx-ingress suse/nginx-ingress \
      --reuse-values \
      --set "tcp.20000=scf/tcp-router-tcp-router-public:20000" \
      --set "tcp.20001=scf/tcp-router-tcp-router-public:20001" \
      --set "tcp.20002=scf/tcp-router-tcp-router-public:20002" \
      --set "tcp.20003=scf/tcp-router-tcp-router-public:20003" \
      --set "tcp.20004=scf/tcp-router-tcp-router-public:20004" \
      --set "tcp.20005=scf/tcp-router-tcp-router-public:20005" \
      --set "tcp.20006=scf/tcp-router-tcp-router-public:20006" \
      --set "tcp.20007=scf/tcp-router-tcp-router-public:20007" \
      --set "tcp.20008=scf/tcp-router-tcp-router-public:20008" \
      --set "tcp.2222=scf/diego-ssh-ssh-proxy-public:2222"
  11. Set up the scf deployment to trust the CA certificate that signed the certificate of the Ingress Controller.

    tux > export INGRESS_CA_CERT=$(cat ingress-ca-cert.pem)
  12. Deploy scf.

    tux > helm install suse/cf \
    --name susecf-scf \
    --namespace scf \
    --values scf-config-values.yaml \
    --set "secrets.UAA_CA_CERT=${INGRESS_CA_CERT}"

    Wait until you have a successful scf deployment before going to the next steps, which you can monitor with the watch command:

    tux > watch --color 'kubectl get pods --namespace scf'

    When scf is successfully deployed, the following is observed:

    • For the secret-generation and post-deployment-setup pods, the STATUS is Completed and the READY column is at 0/1.

    • All other pods have a Running STATUS and a READY value of n/n.

    Press CtrlC to exit the watch command.

  13. When the deployment completes, verify you are able to login using the cf CLI.

    tux > cf login https://api.example.com -u username -p password

4.2 Changing the Max Body Size

The nginx.ingress.kubernetes.io/proxy-body-size value indicates the maximum client request body size. Actions such as pushing an application through cf push can result in larger request body sizes depending on the application type you work with. If your current setting is insufficient, you may encounter a 413 Request Entity Too Large error.

The maximum client request body size can be changed to adapt to your workflow using the following.

  1. Add nginx.ingress.kubernetes.io/proxy-body-size to your scf-config-values.yaml and specify a value.

    ingress:
      annotations:
        nginx.ingress.kubernetes.io/proxy-body-size: 1024m
  2. Set up the scf deployment to trust the CA certificate that signed the certificate of the Ingress Controller.

    tux > export INGRESS_CA_CERT=$(cat ingress-ca-cert.pem)
  3. Use helm upgrade to apply the change.

    tux > helm upgrade susecf-scf suse/cf \
    --values scf-config-values.yaml --set "secrets.UAA_CA_CERT=${INGRESS_CA_CERT}" \
    --version 2.20.3
  4. Monitor the deployment progress using the watch command.

    tux > watch --color 'kubectl get pods --namespace scf'