If i use kubernetes that means i don't have to use docker and docker compose. Right? Kubernetes is like docker but on steroids?

No, k8s is a docker orchestration system.

@AlmondSauce is there a system that can govern multiple kubernetes orchestras?

https://lwn.net/Articles/902049/

For a good overview of the lingo involved.

"The OCI ecosystem" I'd recommend reading at least that part.

@AlmondSauce No it is not.
It is a container orchestration tool.
K8S in GCP uses zero docker components. It uses containerd to run them images.

@b2plane you don't need docker or docker compose to run things in k8s. Most people do use a Dockerfile to build container images but the building does not have to be done by docker. Anything that builds OCI compatible images will do and most people have a pipeline build these.
Even though I do use a docker clone to run certain dependencies for some local testing it usually isn't running and I can deploy to k8s just fine.

Here is an article about Ko and Jib to build images directly from code https://snyk.io/blog/...

As k8s is container orchestration it does help to understand the docker ecosystem.

@hjk101 Bleh, touche. I'm becoming one of these people I hate who uses the word "container" and "docker" interchangeably :(

@AlmondSauce a lot of times it's irrelevant especially when using docker or docker compatible container tools locally.
In this case the distinction matters. The OP doesn't need docker or a license to build and deploy to a k8s cluster. I thought that was why he asked the question.

Most teams will use Docker to build their containers, and run/test locally.

A lot of people will use Docker compose to run a local stack (front end, back end, database, cache, etc), and the same stack gets replicated to k8s with just enough differences to cause edge cases issues that will see you ripping your hair out.

some people like running a small k8s locally though, and others have moved away from docker completely locally, in favour of ephemeral k8s environments in the cloud for testing.

@hjk101 Sure, but as you point out it does matter sometimes like here - so imho we should all be careful not to mix terms, myself included!

The reason the terms are important is because Docker is getting more and more problematic.

Many forget that Docker is just an implementation, not the whole ecosystem.

Thus, it is possible to migrate from Docker to e.g. Podman or K8S or ...

The tooling has to change, of course.

But as the basis is e.g. the OCI specification, it is just the tooling.

For example one can use a Docker registry like Harbor with Kubernetes, no problem. Older images can be used in Kubernetes, no problem.

In our company we're preparing to switch to Podman, cause Dockers license change, their development quality and so on is more than worrying.

At first I thought this was a task in the category "hail mary with no return"… as in undoable, but after some tests it is the opposite. It's trivial. Bothersome, yes - as quite a sysiphos task to replace it everywhere instead of aliases / symlinks - but not undoable.

@electrineer rancher

@IntrusionCM also many forget that just like hibernate was the torchbearer for jpa, docker was the beginning of oci. An interface [oci] extracted out of an implementation.

Unless I'm mistaken?

Yes. No.

You don't have to use docker with k8s. You can, but you can choose an alternative containers' daemon. The daemon must implement the OCI/CRI interface in order to work as a k8s backend. Currently the most popular cris are docker and containerd [love the latter!].

It's more like Docker-compose on steroids. NOT docker on steroids.

Apart from cri [containerd] k8s also requires cni [network] and might require (depending on project) csi [storage] providers.

K8s has a quite steep learning curve, requiring a change of the way of thinking. But eventually it just clicks inside the head and everything suddenly starts making sense. To me that click happened reading an in-depth explanation how k8s network works [it is really cool!] - prolly the most complex part of k8s

@netikras exactly.

https://opencontainers.org/about/...

Docker split its runtime into manageable pieces and dropped the code off to the Open Containers foundation.

That way, the foundation is "neutral" and it's code, too.