Kubernetes, in the form of k3s, was a critical success factor for us with the onprem deployment of our SaaS product.

What's the problem with a single-node cluster? We use that for e.g. dev environments, as well as some small onprem deployments.

> Even when cloud deployed, K8s mostly functions as a batteries-not-included wrapper around the underlying cloud provider services and APIs.

Which batteries are not included? The "wrapper around the underlying cloud provider services and APIs" is enormously important. Why would you prefer to use a less well-designed, more vendor-specific set of APIs?

I seriously don't get these criticisms of k8s. K8s abstracts away, and standardizes, an enormous amount of system complexity. The people who object to it just don't have the requirements where it starts making sense, that's all.

▲

subhobroto 4 days ago | parent [-]

> Kubernetes, in the form of k3s, was a critical success factor for us with the onprem deployment of our SaaS product.

What surprises and gotchas did you have to deal with using k3s as a Kubernetes implementation?

Did you use an LB? Which one? I'm assuming all your onprem nodes were just linux servers with very basic equipment (the fanciest networking equipment you used were 10GbE PCIe cards, nothing more special than that?)

	▲	antonvs 4 days ago \| parent [-]
		We sell to enterprise customers. All of them deploy our solution on internal cloud-style VM clusters. We use the Traefik ingress controller by default. There really weren't any particular surprises or gotchas at that level. In this context, I've never had to deal with anything at the level of the type of Ethernet card. That's kind of the point: platforms like k8s abstract away from that.