Kubernetes is an incredibely complex container orchestration system. We’re not going to get into the art and science of running Kubernetes clusters in this tutorial. We will, however, go over some basic and advanced concepts you’ll need to understand, to make the most out of a WordPress deployment in your Kubernetes cluster.
Don’t worry if you don’t fully understand each component here. We’ll cover these and many others in much more detail, with plenty of examples and explanations in the following sections. This is just a high level overview, so you can have a better understanding of the Kubernetes overall architecture.
Nodes
A typical Kubernetes cluster consists of one or more worker nodes. Worker nodes are just computers (or virtual machines) connected to a network, running some Kubernetes services and other related software, which makes them part of the cluster. New nodes can join the cluster and existing nodes can leave the cluster.
Pods
A pod is the smallest deployable unit in Kubernetes. Pods consists of one or more containers and their configuration, including claims on resources, such as storage or memory. Almost everything in Kubernetes runs in pods, including its own system services, such as DNS, the API server, cluster networking and more.
While you can create and work with pods directly, it’s usually better to use one of the many abstractions, giving you more control over how pods are scheduled. When placing WordPress in our Kubernetes cluster we’ll start with a single pod, but eventually move to deployments and stateful sets.
Deployments and StatefulSets
A deployment is an abstraction layer for pods in a Kubernetes cluster. A deployment defines and manages one or more pods, helps with update rollouts or rollbacks, scaling in and out and more. Deployments are great for stateless applications, which we might not have too many of in our WordPress scenario.
A StatefulSet is pretty much a deployment, but it is more aware that it is managing a stateful application. With stateful sets you’ll get sticky identities, more predictable naming, stable persistent storage, ordered scaing and udpates.
Services
Pods can easily speak to each other over the network in Kubernetes, however the assigned IPs are usually unpredictable and can change at any time. This is where a service will help. Services can provide a consistent IP address, as well as some DNS names for one or more pods. While the service is alive, it is also aware of any pods joining or leaving the group and any underlying IP changes.
Services can also provide some load balancing between pods, as well as expose your pods to the outside world. We’ll cover some techniques and best practices to load balance and provide external access in Kubernetes in later parts of this tutorial.
ConfigMaps and Secrets
ConfigMaps and Secrets in Kubernetes are just key-value stores, which can be used to hold your configuration (and secrets, such as API keys, database credentials or TLS certificates) and share it with your running pods. Both can be used to create and mount files into your pods, which makes them a great fit for custom configuration files for Nginx, PHP and other container images.
Recap
To recap, a Kubernetes cluster consists of one or more Worker Nodes, which can run containers encapsulated into Pods, managed through a Deployment or a StatefulSet, exposed privately or publicly using a Service. Some configuration files and variables used by pods can be managed through ConfigMaps and Secrets.
This is already complex enough, but be warned that the explanations here are oversimplified, and this is just the tip of the Kubernetes iceberg. However, grasping these concepts, even at this level, will help you understand some of the decisions we’ll make further on when spreading a WordPress application out into our cluster.
In the next section we’ll help you create your first Kubernetes cluster.