5 ms·

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 an

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.

theginger 6y ago
You might be interested in this https://kubernetes-sigs.github.io/service-apis/ https://kubernetes-sigs.github.io/service-apis/ I think it is potentially a replacement for / alternative to ingress.
- mijamo 6y ago
  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.
q3k 6y ago
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.
- throwaway894345 6y ago
  Is k3s really just a distribution of kubernetes? I thought it was a reimplementation that implements the core API specs?
  - q3k 6y ago
    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.
    - throwaway894345 6y ago
      > 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.
throwaway894345 6y ago
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.

theginger 6y ago

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

mijamo 6y ago
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.

q3k 6y ago

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.

throwaway894345 6y ago
Is k3s really just a distribution of kubernetes? I thought it was a reimplementation that implements the core API specs?
- q3k 6y ago
  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.
  - throwaway894345 6y ago
    > 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.

throwaway894345 6y ago

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.