Hacker News Reader

Comment by sciurus | Hacker News Reader

> Fundamentally k3c is a built on the Container Runtime Interface (CRI). In fact it's really like a nicer version of of cri-tool. CRI doesn't cover image building and some other small image tasks like tag and push. For image building Moby's buildkit is used internally, and for other things OCI's containerd is used.

I have to admit that in the container world I can't keep up with the different standards, what they each cover, and the different implementations of them. I think a non-docker K8s is already possible, this just reuses that stack while reimplementing part of it in order to make the cli more like the docker cli? Maybe despite the description this is actually intended to be used outside of K8s?

View on HN

This tool is intended to be used outside of Kubernetes. Before you can deploy something on Kubernetes you first need to build a container. Docker is the primary tool used for building and developing containers. The intention of k3c is to replace Docker with a smaller tool that has the required parts of Docker that people use for development. And to make that tool more complimentary to the larger k8s ecosystem.

What are some examples of non-required parts of Docker not needed for development?

Depends on what your use case is, but if you are just focused on creating containers then swarm, libnetwork, volume drivers, plugin framework, "docker app", stacks, and buildx are some examples of features of Docker that aren't needed.

Building a web app on docker without a volume driver would be very, very slow.

No, I'm referring to the volume plugin framework. Volumes in general are just paths on a disk, that is simple enough. More info https://docs.docker.com/engine/extend/plugins_volume/

You are probably thinking of a "storage driver"?

https://docs.docker.com/v17.09/engine/userguide/storagedrive...

I wonder - why `k3c` and not revive `rkt` instead?

rkt is really a fundamentally different architecture and approach than Docker, but more importantly a large unmaintained code base. k3c is really a fairly light layer on top of CRI, containerd and buildkit. So the maintenance burden is very low and quality should be high given it's using the same technology as production Kubernetes clusters.

rkt's files read like it was designed by someone who was used to existing DevOps tools. Docker's format looks more like what someone would come up with from first principles. I don't think the rkt guys accepted that this was part of Docker's success.

rkt feels actively hostile and I won't be using it. If I work for someone who is, I can find a different part of the stack to inhabit until they change their minds.

Thanks for the clarification. Calling something "Docker for a Kubernetes World" when it is not meant to be used with Kubernetes is a bit confusing.

Rancher Labs has been absolutely killing it lately. K3s, Rio, and now a lightweight container-management binary.

Two months ago, I did not know what Kubernetes was exactly, or how containerization worked. Some of the team from the Rancher slack answered a few basic questions I had, and I attended a 2-hour Kubernetes webinar by them, which was also cool. Now I have a suite of half a dozen services running on a cloud k8s cluster in production.

Overall these guys are rockstars, I cannot wait until I can use k3s as a drop-in replacement for Microk8s for local dev (currently has a few bugs).

Holistic Rancher stack, k3s + k3c locally, bootstrap a cloud cluster with Rancher, manage deployments with Rio

People joke about javascript framework numbers but no one has yet started making jokes about container runtime numbers

Reply on news.ycombinator.com