This means if you'd like to deploy a new app or take down an existing app, you'll have to modify the Caddyfile and force caddy to somehow reload the configuration, likely by restarting it. An example of how Caddy documentation looks ( Source)Īnother downside is that Caddy itself actually does not support configuration discovery via Kubernetes out-of-the-box, meaning it does not read Kubernetes Ingress objects for routing rules, but rather, it reads configuration from a Caddyfile, a file defining all the routes for all your applications in a format not dissimilar to nginx server configurations. Personally I do not have any experience with running it, so I cannot give any constructive comments about it, but based on first impressions, I found Caddy documentation to be a little difficult to parse, with a ton of text but very little examples.
ingress-nginxĬaddy is first developed by ZeroSSL, a Stack Holdings company, open sourced in April 2015 with the first version being v0.5.0. For a fuller, comprehensive review of ingress controllers, I'd recommend reading the article from Flant. Before we dive into the considerations behind Traefik, we'll first explore the alternatives.
#WHAT IS KUBERNETES INGRESS SOFTWARE#
While they are all great software in their own right, I found Traefik to be the one that fits my use case back then, and yet still had room to be extended with additional features for when my cluster grew. In the process of searching for the best open-source reverse proxy framework for my clusters, I've come across multiple other alternatives, with the most notable being ingress-nginx and caddy. What this means is that a reverse proxy such as Traefik is an absolute necessity, which would allow all your services to share a single IP address, allowing you to make the most out of what limited network resources may be available for consumer usage. As public IP addresses are an expensive commodity and increasingly so as the world progresses towards the depletion of Public IPv4 addresses, you are unlikely to be able to acquire more than 1 public IP address.Įven if you could somehow acquire more than 1 public IP address, you wouldn't have the equipment to control multiple IP addresses as typical consumer routers only have 1 interface, and you'd typically have only 1 connection per home. In self-hosted setups, you usually have 1 public IP address assigned by your ISP, held by your router, which provides Network Address Translation (NAT) to allow all devices and services in your home network to share that single IP address. Usually when it comes to websites, each domain or even subdomain may have its own IP address in an attempt to provide some form of service isolation so that traffic to each service does not impact one another. How Traefik plays a crucial role in self-hosted setups I will only explore, however, the process of setting up Traefik on Kubernetes here. It was originally designed as an extensible, lightweight reverse proxy but has since gained the capability to fully integrate itself with a Kubernetes cluster while retaining compatibility with Docker and other interfaces. Traefik is, as I have already alluded to, an implementation of an Ingress Controller for Kubernetes. In the context of HTTP/HTTPS traffic, this means listening on ports 80 and 443 on the public IP address that your cluster will receive traffic from. Needless to say, the Ingress Controller service itself must be configured to receive all traffic for your entire cluster. Configures itself to route traffic it receives according to those rules.An Ingress Controller is an in-cluster application that you deploy, that: Here's where an Ingress Controller comes into play.
Kubernetes only provides the API interface as a standardized way of defining rules that dictate what traffic goes to which service.
In English, an Ingress can be seen as analogous to a reverse-proxy and a load-balancer, except for the fact that Kubernetes adopts a BYOS (Bring-Your-Own-Software) approach and does not provide the software that backs these features. Ingress may provide load balancing, SSL termination and name-based virtual hosting. To answer this question one must first understand what is an Ingress object in Kubernetes.įrom the Kubernetes official documentation, an Ingress is: An API object that manages external access to the services in a cluster, typically HTTP.