Evolution of application deployment over the past 20 years.
Configure your local and remote lab environments.
Covers the resource types that are included with Kubernetes.
•Pod
•Job
Using helm to manage Kubernetes resources
Example microservice application.
Kubernetes manifests to deploy the demo application.
Explore how custom resources can add functionality
Install additional software to enhance the deployment.
Improving the DevX when working with Kubernetes.
How to safely upgrade your clusters and nodes.
Implement CI/CD for your applications (with GitOps!)
In Kubernetes, a DaemonSet
ensures that all (or some) nodes run a copy of a Pod
.
As nodes are added to the cluster, pods are added to them. As nodes are removed from the cluster, those pods are garbage collected.
DaemonSets
are typically used for deploying system-level agents and tools, such as log collectors, monitoring agents, or other utilities that should run on every node.
Official docs: https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/
We will create and examine a DaemonSet
to understand it's behavior.
First, we'll create a namespace for these examples and set it as the default.
# task 01-create-namespace
# - Create a namespace for these examples and set as default.
kubectl apply -f Namespace.yaml
kubens 04--daemonset
The pod we will use in our example DaemonSet
runs the fluentd, a tool used to collect logs from a variety of sources and ship them to a log aggregator. As written, this DaemonSet is not configure to actually ship them anywhere, but I wanted to at least use an application that made sense in this use case.
# DaemonSet.fluentd-minimal.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: fluentd-minimal
namespace: 04--daemonset
spec:
selector:
matchLabels:
app: fluentd
template:
metadata:
labels:
app: fluentd
spec:
containers:
- name: fluentd
image: fluentd:v1.16-1
The specification for a DaemonSet
is quite similar to that of a Deployment
, but instead of specifying a number of replicas, it will run a single replica on all nodes (or those specified).
# task 03-apply-minimal-daemonset
# - Apply a minimal fluentd daemonset configuration.
kubectl apply -f DaemonSet.fluentd-minimal.yaml
We can then run a kubectl get pods
to see the pods and which nodes they are running on:
❯ kubectl get nodes
NAME STATUS ROLES AGE VERSION
kind-control-plane Ready control-plane 21d v1.30.0
kind-worker Ready <none> 21d v1.30.0
kind-worker2 Ready <none> 21d v1.30.0
❯ kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
fluentd-minimal-ssjwj 1/1 Running 0 10s 10.244.1.66 kind-worker2 <none> <none>
fluentd-minimal-xxp8w 1/1 Running 0 10s 10.244.2.16 kind-worker <none> <none>
💡 Note: By default a DaemonSet
will run on all worker nodes but NOT control plane nodes. To also run on the control plane you must add a "toleration" allowing it.
Finally, clean up by deleting the namespace, which will also delete all resources within it.
# task 04-delete-namespace
# - Delete the namespace to clean up.
kubectl delete -f Namespace.yaml