In this blog post, we’ll cover Kubernetes Ingress, including what it is and some of the concepts you’ll need to learn. This articles assumes you have a solid understanding of Kubernetes.
To start simply, a Kubernetes ingress exposes HTTP and HTTPS routes from outside of a cluster to services created inside the cluster. In general, you’ll find that:
Ingress is typically defined with an ingress resource. Like most K8S resources, the ingress resource needs apiVersion, kind, and metadata.
An example of a resource looks like this:
apiVersion: extensions/v1beta1 kind: Ingress metadata: name: demo-ingress annotations: nginx.ingress.kubernetes.io/rewrite-target: / spec: rules: - http: paths: - path: /demopath backend: serviceName: demo servicePort: 80
The ingress rules are a set of rules used to process incoming traffic to services in the cluster. Using the example above, let’s go over the rules section of the spec.
If a rule is not defined, all traffic will be routed to a default backend that is specified in ingress controller.
The three types of ingress are:
Securing an ingress is simple. In the resource manifest, specify a secret with a private key and certificate.
An ingress controller has some load balancing policy settings apply to all ingress. Two common ones are the load balancing algorithm and the backend weight scheme.
For ingress resources to work, an ingress controller must be running. This type of controller is not like other controllers in k8s (i.e., part of the cluster). Instead, the ingress controller is a separate entity that must be deployed separately.
Examples of ingress controllers are:
Refer to K8S documentation to a see full list. You can run any number of controllers in the cluster so long as they are annotated properly with ingress.class.