DevOps Stack Exchange is a question and answer site for software engineers working on automated testing, continuous delivery, service integration and monitoring, and building SDLC infrastructure. It only takes a minute to sign up.
Sign up to join this community
Is learning and using docker required to deploy applications with Linode's Kubernetes Engine? (LKE)
As fun as docker sounds, I'd like to avoid having to learn that additional complexity if possible.
I have numerous CentOS and Ubuntu servers and custom (php) applications running at Linode, and I'm interested in transferring one of them to LKE.
I have numerous CentOS and Ubuntu servers and custom (php) applications running at Linode, and I'm interested in transferring one of them to LKE.
If this is your case, the first thing you need to do, to be able to run your application on Kubernetes, is to actually run your application in a docker container.
When you have got your application running in a docker container, then can you learn about Kubernetes Deployment and Ingress configurations. You will run the same docker container in your Kubernetes cluster as you can run locally using docker.
The first step to get your application running in a docker container is to learn about how Dockerfiles are used and written. When your have built a docker container, that is what you are going to use in Kubernetes as well.
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
mount and chroot might help with building the idea)diff)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 ConfigMap to /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).
Example:
Deployment config with php:<version>-apache image:tag.ConfigMap as a fileBy 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.
Kubernetes itself can run with other containerization technologies than Docker.
Perusing the official Linode documentation and FAQ https://www.linode.com/docs/guides/kubernetes-reference/ , they seem uncomitted to the question. In the "Kubernetes" FAQ they mention correctly that Kubernetes can run with several containerization technologies but that Docker is the most common. I did not find a clear, "first class citizen" documentation from them where they describe how to configure another solution. So I assume that at least the managed Kubernetes solution from Linode does only offer Docker as container backend.
That out of the way, you are asking this not for technical reasons, but specifically because you want to avoid the overhead of learning Docker technology just to get one service into a Kubernetes environment.
The answer to this is very clear: for all means and purposes, it makes no sense to go to a non-Docker container system with Kubernetes to avoid learning effort. Docker is by far the most widely used and documented alternative with many tutorials, FAQs, best practices, examples and so on.
The basic Docker usage is very simple. Writing a Dockerfile is so easy that it is more or less trivial. All the difficulty is in finding the correct commands to build and run your application and listing them in a text file with trivial syntax - and that would be the same effort for any and all container solutions.
The difficulties of Docker arise when you go to run your containers on a professional level. And this is exactly what a managed Kubernetes solution does for you. So again, you will not come in contact with any Docker specific "difficult" tasks (like making sure your containers are always up, getting the storage, networking, CPU quotas and so on to work well and so on). This is all handled by Kubernetes for you, and you will not notice whether it's Docker or another container backend driving your cluster.
