I can deploy an application on a machine running a specific Debian version. Go to some provider of bare metal or VMs, they usually have a "Get a Debian version soandso machine" button. Then I copy some files to a specific directory, then I run a setup.sh script that turns this specific version of Debian into a server running my application.
But how do I deploy "on Kubernetes"? Where do I get a button "Rent a Kubernetes"?
What kind of a question is this?
It means to deploy "on Kubernetes".
It doesn't mean to run a script on a server.
It means you need a Kubernetes cluster where you have deploy permissions. Then you can deploy on Kubernetes.
> Where do I get a button "Rent a Kubernetes"?
https://cloud.google.com/kubernetes-engine/ https://www.digitalocean.com/products/kubernetes https://azure.microsoft.com/en-us/products/kubernetes-servic... https://aws.amazon.com/eks/
(In no particular order)
Kubernetes is an orchestrator that you control via an API, there is no file system to put things on and you don't run anything directly. You tell Kubernetes where to get your software from (as a container image) and how it should run it, and Kubernetes will then make sure the specified number of instances of your software is running with the settings you specify, on a suitable machine, with any storage volumes and other resources you request, or tell you it can't.
> But how do I deploy "on Kubernetes"?
Depends on the way it's set up. With vanilla Kubernetes you put container images in a registry that Kubernetes can access, write a manifest YAML and send that to the Kubernetes API (e.g. using the kubectl utility).
> Where do I get a button "Rent a Kubernetes"?
GCP, AWS, Azure, DigitalOcean, ... though they're labelled slightly differently.
Think of Kubernetes as an operating system for a cluster of computers.
You can rent managed Kubernetes from any cloud provider.
* Comply with general Linux rules for creating applications, i.e. either provide a file containing ELF executable with the appropriate metadata s.a. execution bit set etc. or similarly, a script file with a properly formatted shebang line.
* Comply with Debian package manager rules, i.e. create a properly formatted DEB file that can, in principle, be installed by "deb" package manager (i.e. doesn't create dependency problems, pre/post-install scripts execute etc.)
It's similar for Kubernetes deployment: except on top of creating a DEB package, you now also need to provide a "chart", that is a document (or a collection of documents) that describe in a formal way how the application is to be installed.
In a way very similar to how you can side-step creation of DEB package by, say, writing a Makefile and using that to install, you could also side-step creating a chart by, eg. writing a script that creates all the necessary Kubernetes entities. It's also not necessary that you create a chart in addition to DEB: it's possible that you use a Makefile-like approach for the part that would be better managed by DEB package, but still provide a chart for Kubernetes (it also has a package manager, however poorly designed and implemented: Helm).
---
In a way similar to how you could rent a bare-metal box or a VM, you can rent a Kubernetes cluster. Prices very a lot, and similar to the VM prices will greatly depend on the components you choose to put in your cluster.
This being said, running applications on Kubernetes is anything but cheap: Kubernetes adds a significant management layer overhead, but that pails on comparison to the typical way to deploy applications where there's rarely any form of cohesion between components (i.e. Linux container images that support individual components rarely have much of an overlap that can be automatically deduplicated, which means the application deployment ends up having tens or hundreds of copies of the same popular libraries, like libc or pthreads etc.) But it doesn't end there: Etcd, the Kuberenetes' database backend is hugely overloaded by all kinds of traffic sent to it. Most of that traffic is of no interest to the operator. So, your network also takes a noticeable performance hit from running Kubernetes in it (a typical solution is to dedicate an entirely separate physical network for Kubernetes' "control plane").
Of course, it's possible to come up with an equally bad if not worse solution in-house, if you want the same features provided by Kubernetes, but it's also possible and relatively easy to come up with a solution that will be less resource-hungry, while performing the same function.
Bottom line: claims about 80% cheaper are pulled out of... well, we'll not discuss where they pulled them out of.
It is one line of code.
kubectl apply -f k8s/deployment.yaml