3 ms·

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

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.

mikepurvis 7y ago
What are some examples of non-required parts of Docker not needed for development?
- darren0 7y ago
  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.
  - hinkley 7y ago
    Building a web app on docker without a volume driver would be very, very slow.
    - darren0 7y ago
      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/ https://docs.docker.com/engine/extend/plugins_volume/
    - ofrzeta 7y ago
      You are probably thinking of a "storage driver"? https://docs.docker.com/v17.09/engine/userguide/storagedriver/selectadriver/ https://docs.docker.com/v17.09/engine/userguide/storagedrive...
drdaeman 7y ago
I wonder - why `k3c` and not revive `rkt` instead?
- darren0 7y ago
  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.
- hinkley 7y ago
  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.
sciurus 7y ago
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.
gavinray 7y ago
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

mikepurvis 7y ago

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

darren0 7y ago
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.
- hinkley 7y ago
  Building a web app on docker without a volume driver would be very, very slow.
  - darren0 7y ago
    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/ https://docs.docker.com/engine/extend/plugins_volume/
  - ofrzeta 7y ago
    You are probably thinking of a "storage driver"? https://docs.docker.com/v17.09/engine/userguide/storagedriver/selectadriver/ https://docs.docker.com/v17.09/engine/userguide/storagedrive...

drdaeman 7y ago

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

darren0 7y ago
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.
hinkley 7y ago
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.

sciurus 7y ago

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.

gavinray 7y ago

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