CKA Study notes - Ingress
Overview
This post is part of my Certified Kubernetes Administrator exam preparations. Time has come for the Networking concepts in Kubernetes.
Networking in Kubernetes is in a way simple, but at the same time complex when we pull in how to communicate in and out of the cluster, so I'll split the posts up in three, covering Cluster & Pod networking, Services, and Ingress (this post).
As for the CKA exam the Services & Networking objective weighs 20% of the exam so it is an important section.
Again, as mentioned in my other CKA Study notes posts, there's more to the concepts than I cover so be sure to check the documentation.
Note #1: I'm using documentation for version 1.19 in my references below as this is the version used in the current (jan 2021) CKA exam. Please check the version applicable to your usecase and/or environment
Note #2: This is a post covering my study notes preparing for the CKA exam and reflects my understanding of the topic, and what I have focused on during my preparations.
Ingress
Kubernetes Documentation reference
Ingress resources will help traffic from outside of our cluster reach services within the cluster, i.e. the Ingress resources provide the routing for http/s traffic. Meaning that where services are a type of L4 load balancer/proxy, Ingress proxy at layer 7.
Ingress can help consolidate the traffic coming in so you have a single entry point. This also gives you the ability to have some kind of certificate management on that centralized point.
The Ingress resource is stable from 1.19
An example of an Ingress fetched from the Kubernetes documentation:
1apiVersion: networking.k8s.io/v1
2kind: Ingress
3metadata:
4 name: minimal-ingress
5 annotations:
6 nginx.ingress.kubernetes.io/rewrite-target: /
7spec:
8 rules:
9 - http:
10 paths:
11 - path: /testpath
12 pathType: Prefix
13 backend:
14 service:
15 name: test
16 port:
17 number: 80
With this example, traffic comming in with the hostpath /testpath
will be routed to the service named test
on port 80.
Multiple rules
can be set on the resource, and there's different path types that can be used.
The backends
that can be specified should point to another Kubernetes resource in the same namespace
Hostnames can be specified in the rules
section, either specific or with wildcards.
Let's extend our previous example with adding a host rule
1apiVersion: networking.k8s.io/v1
2kind: Ingress
3metadata:
4 name: minimal-ingress
5 annotations:
6 nginx.ingress.kubernetes.io/rewrite-target: /
7spec:
8 rules:
9 - host: "my.host.com" #This is the only change from the previous example
10 http:
11 paths:
12 - path: /testpath
13 pathType: Prefix
14 backend:
15 service:
16 name: test
17 port:
18 number: 80
Now the rule also specifies a host, therefore it's only matched for my.host.com/testpath
requests
Ingress controllers
Kubernetes Documentation reference
Ingress resources needs an Ingress controller
that is responsible for actually performing what the Ingress resource specifies. An Ingress resource alone has no affect.
As of version 1.19 Kubernetes support and maintains AWS, GCE and nginx ingress controllers. The rest of the controllers available have some reference specs they should fit, but there are differences in them, like there are for CNI plugins, so be sure to check the capabilities and caveats of the one you choose.
Ingresses can actually use different controllers in the same cluster so if you need a controller for scenario A, but this doesn't work for scenario B, you can use different ones. As with storage and it's storage classes, we can configure an Ingress class that Ingresses can choose from.
Ingress types
Kubernetes Documentation reference
There's multiple different Ingress types available
- Single service
- Similar to exposing a single service. Created by an Ingress with no rules and a
defaultBackend
- Similar to exposing a single service. Created by an Ingress with no rules and a
- Fanout
- Route traffic to one IP address to multiple services (backend) based on the http request
- Virtual hosting
- Route traffic based on hostnames
- TLS
- TLS terminate requests, encrypting traffic from the client to the load balancer. Note that the traffic to the service is unencrypted. The different implementations have different support for TLS termination
- Load balancer
- Currently simple load balancing features are available for Ingress. Persistent sessions and other more advanced features is not supported. Ingress controllers have different support for Load balancing
Ingress vs Reverse proxy
Ingress seemed somewhat difficult to get a grip on at first sight for me. And in simple scenarios it seems easier to just use NodePort Services and handle the proxy and load balancing on the way in to the cluster with for example a HAProxy loadbalancer.
But when looking at my HAProxy configuration external to the Kubernetes cluster I realized that Ingress is doing exactly what I configure in HAProxy.
I have HAProxy running as a systemd service on a VM. The service uses a configuration file specifying frontend servers which routes, and potentially load balances, traffic to backend servers based on some conditions.
Proxying (pun intended) this to Ingress and Ingress Controllers, we can see the HAProxy service (or daemon) as the Ingress controller, and the different configurations (frontend -> backend) as Ingress resources.
Summary
As we've discussed Ingress can help with traffic routing from outside of the cluster, but an administrator needs to install the wanted controller(s) for it to work. Again, note that there are different features available in the controllers.
Ingress and Services crosses paths in some ways, and it seems to be a very dynamic community around the Ingress concepts so there might be a lot of changes and new features in the future.
There's lots more to explore for Ingress, but hopefully this is enough for understanding the concept, at least for the CKA exam.
If you want to learn more, and enjoy video resources, I can recommend the free KubeAcademy PRO series from VMware, the Networking course has really helped me in understanding the concepts.
Thanks for reading, if you have any questions or comments feel free to reach out