bureaucraten, interfacemoderatoren, Beheerders (Semantic MediaWiki), Curatoren (Semantic MediaWiki), Redacteuren (Semantic MediaWiki), toezichthouders, beheerders
205
bewerkingen
geen bewerkingssamenvatting
Geen bewerkingssamenvatting |
Geen bewerkingssamenvatting |
||
| Regel 35: | Regel 35: | ||
Now, Docker has some problems of its own: | Now, Docker has some problems of its own: | ||
* You start Docker containers by accessing the Docker daemon; the daemon runs containers as root and allows you to start a container with a bind-mount of "/". Basically, having access to the Docker daemon means you have root on the system. | * You start Docker containers by accessing the Docker daemon; the daemon runs containers as root and allows you to start a container with a bind-mount of "/". Basically, having access to the Docker daemon means you have root on the system, but you need access to do anything. It's all-or-nothing. | ||
* When your Docker machine goes down, all containers are gone. You'll have to either restart all containers manually, or have boot-scripts that set them up, but there's no automatic restart mechanism. | * When your Docker machine goes down, all containers are gone. You'll have to either restart all containers manually, or have boot-scripts that set them up, but there's no automatic restart mechanism. | ||
* When you want to run more Docker containers than fit on one machine, there's no horizontal scaling mechanism built-in. | * When you want to run more Docker containers than fit on one machine, there's no horizontal scaling mechanism built-in. | ||
* When you want to run a service multiple times, e.g. for redundancy, you need to schedule them manually multiple times and roll your own method of load-balancing them. | |||
Kubernetes | Kubernetes provides a solution for these problems, while otherwise looking very much like Docker. In fact, when you're familiar with Docker some of the commands below will also be very familiar to you. | ||
= Concepts = | = Concepts = | ||
In this section, I'll explain some of Kubernetes' concepts quickly, and add links if you want to know more. | In this section, I'll explain some of Kubernetes' concepts quickly, and add links if you want to know more. | ||
* '''Container''': Like with Docker, this is one 'guest environment' in which you can run anything. Usually, Kubernetes containers are, in fact, Docker containers. | |||
* '''[https://kubernetes.io/docs/concepts/workloads/pods/pod-overview/ Pod]''': The basic unit you actually schedule in Kubernetes. Usually, a Pod contains one Container, but a Pod can consist of multiple Containers which can be a very useful feature. More on that later. | |||
* '''[https://kubernetes.io/docs/concepts/storage/volumes/ Volume]''': As in Docker, changes to containers are temporary and will be gone when the container stops. If you want to keep those changes after a restart, like in Docker, you make a Volume. They are also useful to share data between containers. In Kubernetes, Volumes are kept over restarts of Containers, but not over restarts of Pods, unless they are Persistent. More on that later. | |||
* '''[https://kubernetes.io/docs/concepts/services-networking/service/ Service]''': When your Pod contains some application, such as a webserver, you can make its TCP port available as a Service so that people (inside or outside the cluster) can connect to it. For an application you want to run redundantly, multiple Pods can be started; you'll configure them to share the same Service. This way, when you connect to the Service, you'll get one of the running Pods behind it. Instant redundancy! | |||
* '''[https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/ Namespace]''': Kubernetes supports running multiple "virtual clusters" on the infrastructure of one "physical cluster". Those virtual clusters are called "namespaces", and you can restrict access to certain namespaces. Normally, you're only working with the "default" namespace. | |||
* '''[https://kubernetes.io/docs/concepts/workloads/controllers/deployment/ Deployment]''': To do. | |||
Those are some concepts that allow you to use a Kubernetes cluster. In this guide, we'll also be setting up the infrastructure behind that: | |||
* '''Node''': A machine that actually runs the Containers. Can be bare-metal or a virtual machine, or even an embedded IoT device. A Node runs a process called "Kubelet" which interacts with the Docker daemon (usually) to set everything up, but normally you never communicate directly with it. | |||
* '''Control Plane''': A set of some applications (API server, controller manager, proxy, scheduler, etcd...) that make sure the cluster is "healthy". For example, it starts Pods when you request it to, but also when a Node goes down that was running Pods, it restarts those Pods elsewhere. | |||
'''Master node''': Otherwise a normal Node, but it runs the Control Plane applications. By default, a Master node will only run Pods for these applications, but you can configure it to allow normal Pods too. There can be multiple Master nodes, for redundancy of the cluster. | |||
= Setting it all up = | |||