4 ms·

> 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 buildi

> 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?

darren0 7y ago
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
all-out-of-hope 7y ago
People joke about javascript framework numbers but no one has yet started making jokes about container runtime numbers

darren0 7y ago

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

all-out-of-hope 7y ago

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