TL;DR: you don't need it, but you also can't just copy-paste VM to Kubernetes
TL;DR 2: learn to walk before you start running
- Learn what is process and how namespaces work on Linux
- Learn how to assemble a filesystem image (simple
chroot might help with building the idea)
- Imagine filesystem layers as git commits (Docker / filesystem
- Learn how to publish and pull a filesystem for Kubernetes
- Learn basic deployment with simple service on Kubernetes
- Learn advanced networking and filesystem concepts on Kubernetes
You are mistaking "complexity" with "building steps". A "kubernetes engine" how cloud vendors call it nowadays is nothing more than pure Kubernetes + some vendor specific CRUD that uses Kubernetes API (in similar way you'd use them with kubectl).
Now if we have Kubernetes, it's necessary to understand how stuff are actually deployed in there. Kubernetes is an orchestrator for Linux processes running in namespaces (a.k.a. lightweight "vm", though people dislike the "vm" term). Process needs to appear from somewhere, here comes into place a filesystem.
Filesystem is provided to Kubernetes by a so called "image" and that can be created by LXC or Docker or anything else if Kubernetes supports it / has a driver for it. The specs for the format are open (thus even the recent switch from docker to containerd as process/container runner).
And here is where Docker or any other filesystem creating tool (Nix) comes to place. You either learn it or you can create the filesystem even from scratch (based on the containerd specs, if you don't appreciate your free time). Once the filesystem image is created, you publish it somewhere, such as Docker image registry (some vendors call it "container registry", though you don't really store containers there) and Kubernetes pulls the filesystem image from it to its local registry (storage).
You don't necessarily need to even touch Docker nor build a filesystem ever if you can find an already available image on Docker Hub or other public registries. Once you have such an image, just use a Kubernetes
ConfigMap to replace a file in such a filesystem e.g. default
nginx.conf with your custom one and it'll run just fine. Same for Python, Java, Go, etc. If you can find an image that's usable and you have your project properly packaged, there's no need to even touch Docker. If something breaks in the filesystem though, it's what you might eventually need to reproduce an issue locally.
For you that'd be using e.g. PHP + Apache Docker image, mounting your Apache config files and perhaps even
php.ini in one
ConfigMap, mounting the project files as another
/some/php/location/www and perhaps even adding a volume from the cloud vendor if you want to utilize preserving the content as files instead only in DB (filesystem clears after each container is killed/removed).
- Create kubernetes
Deployment config with
ConfigMap as a file
- Check how Linode works with Kubernetes PVC with CSI driver
- Mount your project as tarball or from linode volume
By using a public image make sure it's not out of date and you check for vulnerabilities yourself if you don't have some system/company process set up already, otherwise you'll be just using an old version of a filesystem anyone can download and try attacking locally i.e. prepare for and then just either ddos you without much of an effort or just hijack your container and do whatever depending on the available binaries in the filesystem, set user permissions and allowed network connectivity to and from the container.