The ingress controller adds and removes routes in its underlying load balancer configuration when it detects that pods have been added or removed from the cluster. However, first you must tell it which groups of pods to monitor. To do that, you must define Ingress resources.
An Ingress resource defines which group of pods to monitor and how routing should be set up. Without at least one Ingress resource, the ingress controller has nothing to do. You can deploy an Ingress resource for each of your services.
To begin routing traffic through the ingress controller, follow these steps:
Deploy your application to your Kubernetes cluster.
In the example below, the Deployment resource deploys three pods that run the jmalloc/echo-server container. This application listens on port 8080 and simply displays back information about the HTTP requests that it receives.
apiVersion: apps/v1 kind: Deployment metadata: labels: run: echo name: echo spec: replicas: 3 selector: matchLabels: run: echo template: metadata: labels: run: echo spec: containers: - name: echo image: jmalloc/echo-server ports: - containerPort: 8080 readinessProbe: httpGet: path: / port: 8080 initialDelaySeconds: 5 periodSeconds: 5 successThreshold: 1
Deploy it with
$ kubectl apply -f app.yaml
Next, deploy a Service resource to create a logical group for your pods.
The port field, which you would typically use to expose the service to clients, is discarded by the ingress controller; It can be any value.
The targetPort field is the port to which the ingress controller will route traffic for each pod. It should match the containerPort field that you set on the Deployment resource.
Ordinarily, a Service exposes pods to external clients. For example, you may have used a Service with a type of LoadBalancer to expose pods using a cloud load balancer. Here, we use it simply to create a grouping of pods. Notice that we do not set a type at all here.
In the example below, we group the pods that have the label run: echo.
apiVersion: v1 kind: Service metadata: name: echo-service spec: selector: run: echo ports: - name: http protocol: TCP port: 8080 targetPort: 8080
Deploy it with
$ kubectl apply -f app-service.yaml
Ingressresource that defines how the ingress controller should route traffic to the pods.
In this example, requests to /echo are rewritten to / en route to the pod. Deploy it with
kubectl apply -f ingress.yaml.
Note that, by default, the ingress controller requires that you set the annotation
ingress.classto haproxy. You can disable this when installing the ingress controller.
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: echo-ingress annotations: haproxy.org/path-rewrite: "/" kubernetes.io/ingress.class: haproxy spec: rules: - http: paths: - path: /echo pathType: Prefix backend: service: name: echo-service port: number: 8080
Make requests to the echo service through the ingress controller service’s IP address and port.
Depending on whether you configured the ingress controller to be exposed using a NodePort or LoadBalancer service type, the way you get the IP address and port will be different.
For a NodePort type, which is the default, call
kubectl get serviceto see the randomly assigned ports. In the example below, the ingress controller listens on port 30706 for HTTP traffic and 30675 for HTTPS traffic. Port 31441 publishes the HAProxy Stats page.
$ kubectl get service kubernetes-ingress NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes-ingress NodePort 10.97.154.7 <none> 80:30706/TCP,443:30675/TCP,1024:31441/TCP 32s
The IP address is the IP address of any of your Kubernetes nodes. For example, when using
minikube, you can call
minikube ipto get it.
For a LoadBalancer type, you can get the IP address and port from the cloud provider’s dashboard.