Hacker News Reader

Comment by quaffapint | Hacker News Reader

Ingress Controllers in K8S can and should be simplified. For most cases you'll need a controller, but setting one up can be daunting with the various options and having most of them under constant change with varying documentation.

This is why things like K3s will bundle Traefik with it to save you the pain, but really this should be the standard. It should be swappable (like it is in K3s), but come with something already available.

Updated - Thanks for the reminder - it's ingress controller, not ingress.

View on HN

I think you're confusing Ingresses and Ingress Controllers? Traefik/HAProxy/Nginx act as Ingress Controllers, not Ingresses. Ingresses are the objects created by users to define an intent of L7 traffic forwarding/ingress. Or maybe I'm misparsing your post.

Anyway - the reason K3s can come with an Ingress Controller OOTB is purely a result of the fact that K8s has made it possible by making the architecture pluggable. Nearly every K8s-a-a-S solution comes with its own built-in flavour of an Ingress Controller (and other controllers, too). K3s is just such an implementation. K8s could come with its own standard implementation of an Ingress Controller, but considering how much the implementation varies between deployments, it makes sense they have opted out of that.

Comparing K8s to K8s distributions (like K3s) is somewhat missing the point of what K8s is - a framework to build your own implementation upon, with whatever fits your deployment.

I get it's pluggable, but it's yet another hurdle to jump to get started on K8s. So maybe dont make it included, but make it much simpler to add it in and use it. They already have one that they support, it should be more plug and play with simple steps to route your app, knowing that this will be the case for most uses.

Most of the time when you 'get started on K8s', you get started by using a cluster that's setup by a provider of some sort - be it a cloud provider, a platform team in your company, or some prebundled bare metal Kubernetes distribution like K3s. In these cases, a you will most likely already be provided with, or at least recommended an Ingress Controller.

Setting up K8s clusters from scratch on bare metal (or even worse, VMs) is generally not something you should be doing, unless you really know what you're doing and have a good reason to. Think: going 'Linux from Scratch' instead of installing Ubuntu. K3s is not an alternative to K8s, it really just is a distribution for bare metal deployments. So is Rancher, OpenShift, etc.

I would argue that an ingress is not a barrier to getting started with k8s (even with kubeadm on bare metal). You don't NEED an L7 router to get started. Much more likely is you need a LoadBalancer. An ingress is only going to help route traffic that is already in your cluster.

If you deploying to almost any cloud provider they have an implementation for you. If you're on bare metal, you have to make that choice yourself.

Even if you're hosting yourself you don't technically need a load balancer, you could use host ports, or node ports and it would work for some definition of work. I have in the past set up an ingress to listen on host ports of every node and it works well, if a little janky.

I'm surprised you're complaining about this which is an easy thing to replace and not your choice of network plugin, which can result in having to reprovision the cluster or similar if you want to replace it with something different.

Is k3s really just a distribution of kubernetes? I thought it was a reimplementation that implements the core API specs?

It's a fork-ish. Mostly the same codebase, some things ripped out, some things simplified, others just rearranged. One of the most notable changes is the API server being made backend-agnostic, so you can run it against anything from a SPOFy sqlite to a normal etcd.

And to me, even if it was a full rewrite: if it quacks like a K8s, walks like a K8s, and passes K8s conformance tests, it's a K8s :). I don't require a distribution to take upstream k8s binaries as is and just orchestrate them with a configuration management system, I think a lot of value comes from slightly moving things around and changing them to fit your vision. Better that than a murder of shell scripts.

> And to me, even if it was a full rewrite: if it quacks like a K8s, walks like a K8s, and passes K8s conformance tests, it's a K8s :)

I get it, but it's often helpful to distinguish between interfaces and implementations. If you want to say that the term "kubernetes" reforms to the API interface such that it can be implemented by any of a number of implementations, that's fine but we should have a separate term for the default implementation.

> I don't require a distribution to take upstream k8s binaries as is and just orchestrate them with a configuration management system, I think a lot of value comes from slightly moving things around and changing them to fit your vision. Better that than a murder of shell scripts.

Distributions are nice because you often don't want to have to build out your own logging, monitoring, cert-management, secret-encryption, ingress controller, load balancer controller, volume controllers, object storage, etc, etc, etc every time you stand up a cluster. Basically for the same reasons we have Linux distributions (most people don't want to have to roll their own Linux from scratch every time), Kubernetes distributions would be nice. None of this requires "a murder of shell scripts" (but I like that collective noun) nor does it prevent you from swapping the distro-standard components for your own.

In general I wish there were more kubernetes “distros” that came pre-installed with logging, monitoring, storage (block and object), ingress controllers, load balancers, cert management, secret encryption, etc. The things that every installation needs, but which everyone has to roll themselves.

You might be interested in this https://kubernetes-sigs.github.io/service-apis/ I think it is potentially a replacement for / alternative to ingress.

But it doesn't solve at all the problem described here. Service API will be just like Ingress in that regard, and no implementation will be shipped by default as far as I'm aware.

Reply on news.ycombinator.com