Ingress Controller in your cluster watches for Ingress resources. We can use Ingress to manage all the external traffic to the services in our cluster. Unlike Kubernetes services, ingress is assigned at the cluster level and can be used to manage the traffic for entire cluster.
Ingress exposes HTTP and HTTPS routes from outside the cluster to services within the cluster. Application Gateway Ingress Controller (AGIC) is the Kubernetes application that makes it possible for AKS clusters. Ingress controller runs in its own pods and monitors Kubernetes resources for changes.
Azure allows us to use Application Gateway as Ingress for AKS clusters which lets us use all the application gateway features like: SSL Offloading, path-based routing etc.
Sample YAML Files to deploy AGIC
Example 1: apiVersion: extensions/v1beta1 kind: Ingress metadata: name: aks-ingress namespace: test-front annotations: kubernetes.io/ingress.class: azure/application-gateway appgw.ingress.kubernetes.io/appgw-ssl-certificate: "Dev-UAT" appgw.ingress.kubernetes.io/backend-hostname: "the-tech-guy.in" appgw.ingress.kubernetes.io/override-frontend-port: "445" appgw.ingress.kubernetes.io/backend-path-prefix: "/frontend/" appgw.ingress.kubernetes.io/health-probe-status-codes: "200-399, 403" spec: rules: - http: paths: - path: / backend: serviceName: ttg-frontend-service servicePort: 80 - path: /frontend* backend: serviceName: ttg-frontend-service servicePort: 80 Example 2: apiVersion: extensions/v1beta1 kind: Ingress metadata: name: ttg-ingress-other namespace: ttg-front annotations: kubernetes.io/ingress.class: azure/application-gateway appgw.ingress.kubernetes.io/appgw-ssl-certificate: "Dev-UAT" appgw.ingress.kubernetes.io/backend-hostname: "the-tech-guy.in" appgw.ingress.kubernetes.io/override-frontend-port: "445" appgw.ingress.kubernetes.io/health-probe-status-codes: "200-399, 403" spec: rules: - http: paths: - path: /user* backend: serviceName: nginxuser servicePort: 80 - path: /api/* backend: serviceName: api servicePort: 80
In the above YAML files I am using annotations to customize my AGIC deployments.
- appgw.ingress.kubernetes.io/appgw-ssl-certificate :
- The SSL certificate can be configured to Application Gateway either from a local PFX cerficate file or a reference to a Azure Key Vault unversioned secret Id. When the annotation is present with a certificate name and the certificate is pre-installed in Application Gateway, Kubernetes Ingress controller will create a routing rule with a HTTPS listener and apply the changes to your App Gateway. appgw-ssl-certificate annotation can also be used together with ssl-redirect annotation in case of SSL redirect.
- This allows me to configure SSL offloading for my application.
- This annotations allows us to specify the host name that Application Gateway should use while talking to the Pods. I can have an application which would be expecting a hostname.
- The annotation allows to configure frontend listener to use different ports other than 80/443 for http/https.
- If the port is within the App Gw authorized range (1 – 64999), this listener will be created on this specific port. If an invalid port or no port is set in the annotation, the configuration will fallback on default 80 or 443.
- This annotation allows the backend path specified in an ingress resource to be re-written with prefix specified in this annotation. This allows users to expose services whose endpoints are different than endpoint names used to expose a service in an ingress resource.
- Using the above YAML I have configured my ingress to rewrite “the-tech-guy.in” URL to “the-tech-guy.in/frontend”.
- This would apply if I don’t want my default traffic to be redirected to a specific Kubernetes service, which is “ttg-frontend-service” in this case.
- This annotation defines healthy status codes returned by the health probe. The values are comma separated list of individual status codes or ranges.
- Since application gateway considers only 200-399 as successful health probes. I have configured my AGIC to accept HTTP code 403 as a successful health probe.
- Finally, the paths section under rules allows me to configure path based routing here. Using which I have configured “the-tech-guy.in\user*” traffic will be routed to Kubernetes service named nginxuser.