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 ReplicaSet
ensures that a specified number of pod replicas are running at any given time. If a pod crashes or is deleted, the ReplicaSet automatically creates a new pod to replace it, maintaining the desired number of replicas.
🚨 Note: Similar to Pods
, you will almost never deploy/manage a ReplicaSet
directly. Instead you will define a Deployment
(see next lesson) and Kubernetes will create/manage the underlying ReplicaSets
.
Official docs: https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/
We will create and examine a ReplicaSet
to understand its 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--replicaset
Next, we'll apply a ReplicaSet
configuration containing 3 replicas of a pod containing an nginx container image.
# task 03-better-apply
# - Apply the ReplicaSet configuration.
kubectl apply -f ReplicaSet.nginx-better.yaml
You will notice that within the ReplicaSet definition we have a field spec.template
. This contains all the same fields that our Pod
spec from the previous lesson contained.
The key attributes the replica set (beyond the pod spec) are:
spec.replicas
: Determines how many copies of the pod should be run. If any pod fails, the ReplicaSet
controller will create a new pod to maintain the desired state.spec.selector
: Uses matchLabels to identify the pods that belong to this ReplicaSet. Only pods with the label app: nginx-better will be managed by this ReplicaSet.# ReplicaSet.nginx-better.yaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: nginx-better
namespace: 04--replicaset
labels:
app: nginx-better
spec:
replicas: 3
selector:
matchLabels:
app: nginx-better
template:
metadata:
labels:
app: nginx-better
spec:
containers:
- name: nginx
image: cgr.dev/chainguard/nginx:latest
ports:
- containerPort: 8080
protocol: TCP
readinessProbe:
httpGet:
path: /
port: 8080
resources:
limits:
memory: "50Mi"
requests:
memory: "50Mi"
cpu: "250m"
securityContext:
allowPrivilegeEscalation: false
privileged: false
securityContext:
seccompProfile:
type: RuntimeDefault
runAsUser: 1001
runAsGroup: 1001
runAsNonRoot: true
One of the key features of ReplicaSets is their ability to maintain the desired number of replicas. Deleting all pods will demonstrate this as the ReplicaSet
will automatically recreate the deleted pods.
# task 04-delete-pods
# - Delete all the pods (they will be automatically recreated)
kubectl delete pods --all
watch "kubectl get pods"
Finally, clean up by deleting the namespace, which will also delete all resources within it.
# task 05-delete-namespace
# - Delete the namespace to clean up
kubectl delete -f Namespace.yaml