Kubernetes is an API to a computer. That computer happens to be many computers in the cloud (usually). Basically what happens is you write some yaml describing what you want the system to look like (which services, how much ram they need, how many copies to run, etc) and Kubernetes handles reconciling the current state of the system with what you want it to look like.
You can think of the content of the yaml files as typed JSON objects. Kubernetes (often abbreviated k8s) has many different kinds of objects you can tell it to manage, such as Pods, Volumes, Services, etc. Each of these corresponds to a different piece of the system. Pods are groups of containers, Volumes are storage, etc. Services are where it starts to get abstract, since services are one way to expose a pod to the outside world to accept traffic (like if someone hits your website) and load-balance that traffic to your pods.
Then there are a great many more objects for specific use cases like NetworkPolicy, ConfigMap, StatefulSet, Namespaces, etc which handle network routing, application configuration (like a .env), stateful services, and restricting users to their own namespace in the cluster so they can't see other people's objects
Use it when you're fully investing in a microservice architecture and you can't fulfill your needs any other way.
K8s brings with it a lot of complexity. This is partially because the domain (deploying many different kinds of distributed applications) is complex and partially because it is a very large ecosystem. This results in many approaches to problems for different contexts.
Do I need serverside logic? -no> JAMStack
Can I use serverless? (Do I need state, etc) -> Lambda/etc
Can I use "SaaS" platforms? -> App Engine, Heroku, Elastic Beanstalk etc
---containers come in here---
Can I use "Containers-as-a-Service"? -> Cloud Run, Fargate, Container Instances
Can I let someone else host k8s? -> GKE, EKS, AKS (likely yes, you can even run intense networking tools like Cilium on GKE)
Do I have to do everything myself? -> Prepare to have a team dedicated to handling k8s deployments, maintenance, upgrades, security issues, node upgrades, etc
What have you gotten yourself into? Well, you've gotten yourself into needing to make a lot of decisions on everything from whether to use Helm to learning the difference between a Service Proxy and a Service Mesh.
While k8s is open source and you can do everything including build it from scratch, unless you're using it as a learning exercise or trying to commit PRs to the k8s repos, I highly suggest using a hosted version of k8s. GKE, AKE, Digital Ocean k8s. Even something like Fargate and EKS will allow you to manage less infrastructure while still making use of k8s.
:show architecture:
K8s is most commonly thought of as a tool that is deployed in the cloud. It can also be used to orchestrate everything from Raspberry Pis to bare metal.
The two main options for deploying kubernetes objects are yaml, with kubectl, or Helm, with charts (which, surprise, is more yaml. You're going to have to get used to yaml.) There are more options like ksonnet and even terraform but I'd suggest getting used to yaml first before setting sail into the land of Helm or other deployment tools. This will give you a base on which to understand what is actually happening.
Helm is a package manager for Kubernetes. It is an official sub-project of K8s and as such is probably the first place you should look after getting used to writing the yaml yourself.
yes, but you don't get any of the benefits of distribution
You can multi-master k8s
tilt.dev vs docker-compose vs mini-kube vs own prod env
The CNCF is at the core of a lot of kubernetes related technologies.