<blockquote>
<p>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.</p>
</blockquote>
<p>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 <strong>docker container</strong>.</p>
<p>When you have got your application running in a <strong>docker container</strong>, then can you learn about Kubernetes <a href="https://kubernetes.io/docs/concepts/workloads/controllers/deployment/" rel="nofollow noreferrer">Deployment</a> and <a href="https://kubernetes.io/docs/concepts/services-networking/ingress/" rel="nofollow noreferrer">Ingress</a> <em>configurations</em>. You will run the same <strong>docker container</strong> in your Kubernetes cluster as you can run locally using <code>docker</code>.</p>
<p>The first step to get your application running in a docker container is to learn about how <code>Dockerfiles</code> are used and written. When your have built a docker container, that is what you are going to use in Kubernetes as well.</p>

CC BY-SA 4.0
2022-10-13T13:20:04.310Z
Thank you so much for your response, @Jonas!
zigmoo
CC BY-SA 4.0
2021-08-22T22:22:04.200Z
2021-08-22T22:22:04.200Z
Jonas
<p><strong>TL;DR:</strong> you don't need it, but you also can't just copy-paste VM to Kubernetes</p>
<p><strong>TL;DR 2:</strong> learn to walk before you start running</p>
<ol>
<li>Learn what is process and how namespaces work on Linux</li>
<li>Learn how to assemble a filesystem image (simple <code>mount</code> and <code>chroot</code> might help with building the idea)</li>
<li>Imagine filesystem layers as git commits (Docker / filesystem <code>diff</code>)</li>
<li>Learn how to publish and pull a filesystem for Kubernetes</li>
<li>Learn basic deployment with simple service on Kubernetes</li>
<li>Learn advanced networking and filesystem concepts on Kubernetes</li>
</ol>
<hr />
<p>You are mistaking &quot;complexity&quot; with &quot;building steps&quot;. A &quot;kubernetes engine&quot; 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).</p>
<p>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 &quot;vm&quot;, though people dislike the &quot;vm&quot; term). Process needs to appear from somewhere, here comes into place a filesystem.</p>
<p>Filesystem is provided to Kubernetes by a so called &quot;image&quot; 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).</p>
<p>And here is where Docker or any other filesystem creating tool (<a href="https://thewagner.net/blog/2021/02/25/building-container-images-with-nix/" rel="nofollow noreferrer">Nix</a>) 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 &quot;container registry&quot;, though you don't really store <em>containers</em> there) and Kubernetes pulls the filesystem image from it to its local registry (storage).</p>
<h3>Alternatively!</h3>
<p>You don't necessarily <em>need</em> to even touch Docker nor build a filesystem <em>ever</em> 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 <code>ConfigMap</code> to replace a file in such a filesystem e.g. default <code>nginx.conf</code> 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.</p>
<p>For you that'd be using e.g. PHP + Apache Docker image, mounting your Apache config files and perhaps even <code>php.ini</code> in one <code>ConfigMap</code>, mounting the project files as another <code>ConfigMap</code> to <code>/some/php/location/www</code> 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).</p>
<p>Example:</p>
<ol>
<li>Create kubernetes <code>Deployment</code> config with <a href="https://hub.docker.com/_/php" rel="nofollow noreferrer"><code>php:&lt;version&gt;-apache</code></a> image:tag.</li>
<li>Use <a href="https://stackoverflow.com/q/44325048/5994041"><code>ConfigMap</code> as a file</a></li>
<li>Check <a href="https://www.linode.com/docs/guides/deploy-volumes-with-the-linode-block-storage-csi-driver/" rel="nofollow noreferrer">how Linode works with Kubernetes PVC with CSI driver</a></li>
<li>Mount your project as tarball or from linode volume</li>
</ol>
<h3>But!</h3>
<p>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.</p>

CC BY-SA 4.0
2022-10-13T13:23:37.803Z
Hello @Peter-Badida, thank you SO much for sharing your knowledge and expertise. I really appreciate it.
zigmoo
CC BY-SA 4.0
2021-08-23T09:22:01.690Z
2021-08-25T09:38:56.817Z
2021-08-25T09:38:56.817Z
Peter Badida
<p><strong>Kubernetes</strong> itself can run with other containerization technologies than Docker.</p>
<p>Perusing the official <strong>Linode</strong> documentation and FAQ <a href="https://www.linode.com/docs/guides/kubernetes-reference/" rel="nofollow noreferrer">https://www.linode.com/docs/guides/kubernetes-reference/</a> , they seem uncomitted to the question. In the &quot;Kubernetes&quot; 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, &quot;first class citizen&quot; 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.</p>
<p>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.</p>
<p>The <strong>answer</strong> 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 <em>avoid learning effort.</em> Docker is by <em>far</em> the most widely used and documented alternative with many tutorials, FAQs, best practices, examples and so on.</p>
<p>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 <em>that</em> would be the same effort for any and all container solutions.</p>
<p>The difficulties of Docker arise when you go to <em>run</em> 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 &quot;difficult&quot; 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.</p>

CC BY-SA 4.0
2022-10-13T13:26:00.967Z
Hi @AnoE, thanks so much for sharing your production wisdom. Much appreciated!
zigmoo
CC BY-SA 4.0
2021-08-23T13:07:27.840Z
2021-08-23T13:07:27.840Z
AnoE
<p>Is learning and using docker required to deploy applications with Linode's Kubernetes Engine? (LKE)</p>
<p>As fun as docker sounds, I'd like to avoid having to learn that additional complexity if possible.</p>
<p>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.</p>

<docker><kubernetes>
Is docker absolutely necessary to deploy applications with Linode's Kubernetes?
zigmoo
# Is docker absolutely necessary to deploy applications with Linode's Kubernetes?

(Asked by: username_0 on 2021-08-22)

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.

**Tags:** docker, kubernetes


---

## 3 answers

### Answer by username_1 on 2021-08-22. Score: 4

> 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](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) and [Ingress](https://kubernetes.io/docs/concepts/services-networking/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.

> **Comments:**
> **username_0**: Thank you so much for your response, @username_1!  

---

### Answer by username_2 on 2021-08-23. Score: 4

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

1. Learn what is process and how namespaces work on Linux
2. Learn how to assemble a filesystem image (simple `mount` and `chroot` might help with building the idea)
3. Imagine filesystem layers as git commits (Docker / filesystem `diff`)
4. Learn how to publish and pull a filesystem for Kubernetes
5. Learn basic deployment with simple service on Kubernetes
6. 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](https://thewagner.net/blog/2021/02/25/building-container-images-with-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).

### Alternatively!

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:

1. Create kubernetes `Deployment` config with [`php:-apache`](https://hub.docker.com/_/php) image:tag.
2. Use [`ConfigMap` as a file](https://stackoverflow.com/q/44325048/5994041)
3. Check [how Linode works with Kubernetes PVC with CSI driver](https://www.linode.com/docs/guides/deploy-volumes-with-the-linode-block-storage-csi-driver/)
4. Mount your project as tarball or from linode volume

### But!

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.

> **Comments:**
> **username_0**: Hello @Peter-Badida, thank you SO much for sharing your knowledge and expertise. I really appreciate it.  

---

### Answer by username_3 on 2021-08-23. Score: 1

**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.

> **Comments:**
> **username_0**: Hi @username_3, thanks so much for sharing your production wisdom. Much appreciated!  

---

