DEV Community: Ježek

Getting started with Argo CD using the CLI

Ježek — Thu, 04 Dec 2025 00:58:54 +0000

Argo CD is a declarative, GitOps-based continuous delivery (CD) tool for Kubernetes. It automates the deployment and lifecycle management of applications in a cluster by using Git repositories as the single source of truth for the desired state of the infrastructure.

This article explains how to set up Argo CD and deploy an application in a Kubernetes cluster using the command line and manifests.

Prerequisites:

Installed the kind with Cloud Provider KIND
Installed ArgoCD CLI

Kubernetes Cluster

#  kind-cluster.yaml

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
networking:
  apiServerPort: 6443
nodes:
- role: control-plane
- role: worker
- role: worker
- role: worker

$ kind create cluster --config kind-cluster.yaml
Creating cluster "kind" ...
 • Ensuring node image (kindest/node:v1.33.1) 🖼  ...
 ✓ Ensuring node image (kindest/node:v1.33.1) 🖼
 • Preparing nodes 📦 📦 📦 📦   ...
 ✓ Preparing nodes 📦 📦 📦 📦
 • Writing configuration 📜  ...
 ✓ Writing configuration 📜
 • Starting control-plane 🕹️  ...
 ✓ Starting control-plane 🕹️
 • Installing CNI 🔌  ...
 ✓ Installing CNI 🔌
 • Installing StorageClass 💾  ...
 ✓ Installing StorageClass 💾
 • Joining worker nodes 🚜  ...
 ✓ Joining worker nodes 🚜
Set kubectl context to "kind-kind"
You can now use your cluster with:

kubectl cluster-info --context kind-kind

Have a nice day! 👋

$ kubectl get nodes
NAME                 STATUS   ROLES           AGE     VERSION
kind-control-plane   Ready    control-plane   7m2s    v1.33.1
kind-worker          Ready    <none>          6m53s   v1.33.1
kind-worker2         Ready    <none>          6m53s   v1.33.1
kind-worker3         Ready    <none>          6m53s   v1.33.1

Argo CD

Setup the Argo CD

$ kubectl create namespace argocd
namespace/argocd created

$ kubectl get namespaces
NAME                 STATUS   AGE
argocd               Active   9s
default              Active   15m
kube-node-lease      Active   15m
kube-public          Active   15m
kube-system          Active   15m
local-path-storage   Active   15m

$ kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
customresourcedefinition.apiextensions.k8s.io/applications.argoproj.io created
customresourcedefinition.apiextensions.k8s.io/applicationsets.argoproj.io created
customresourcedefinition.apiextensions.k8s.io/appprojects.argoproj.io created
serviceaccount/argocd-application-controller created
serviceaccount/argocd-applicationset-controller created
serviceaccount/argocd-dex-server created
serviceaccount/argocd-notifications-controller created
serviceaccount/argocd-redis created
serviceaccount/argocd-repo-server created
serviceaccount/argocd-server created
role.rbac.authorization.k8s.io/argocd-application-controller created
role.rbac.authorization.k8s.io/argocd-applicationset-controller created
role.rbac.authorization.k8s.io/argocd-dex-server created
role.rbac.authorization.k8s.io/argocd-notifications-controller created
role.rbac.authorization.k8s.io/argocd-redis created
role.rbac.authorization.k8s.io/argocd-server created
clusterrole.rbac.authorization.k8s.io/argocd-application-controller created
clusterrole.rbac.authorization.k8s.io/argocd-applicationset-controller created
clusterrole.rbac.authorization.k8s.io/argocd-server created
rolebinding.rbac.authorization.k8s.io/argocd-application-controller created
rolebinding.rbac.authorization.k8s.io/argocd-applicationset-controller created
rolebinding.rbac.authorization.k8s.io/argocd-dex-server created
rolebinding.rbac.authorization.k8s.io/argocd-notifications-controller created
rolebinding.rbac.authorization.k8s.io/argocd-redis created
rolebinding.rbac.authorization.k8s.io/argocd-server created
clusterrolebinding.rbac.authorization.k8s.io/argocd-application-controller created
clusterrolebinding.rbac.authorization.k8s.io/argocd-applicationset-controller created
clusterrolebinding.rbac.authorization.k8s.io/argocd-server created
configmap/argocd-cm created
configmap/argocd-cmd-params-cm created
configmap/argocd-gpg-keys-cm created
configmap/argocd-notifications-cm created
configmap/argocd-rbac-cm created
configmap/argocd-ssh-known-hosts-cm created
configmap/argocd-tls-certs-cm created
secret/argocd-notifications-secret created
secret/argocd-secret created
service/argocd-applicationset-controller created
service/argocd-dex-server created
service/argocd-metrics created
service/argocd-notifications-controller-metrics created
service/argocd-redis created
service/argocd-repo-server created
service/argocd-server created
service/argocd-server-metrics created
deployment.apps/argocd-applicationset-controller created
deployment.apps/argocd-dex-server created
deployment.apps/argocd-notifications-controller created
deployment.apps/argocd-redis created
deployment.apps/argocd-repo-server created
deployment.apps/argocd-server created
statefulset.apps/argocd-application-controller created
networkpolicy.networking.k8s.io/argocd-application-controller-network-policy created
networkpolicy.networking.k8s.io/argocd-applicationset-controller-network-policy created
networkpolicy.networking.k8s.io/argocd-dex-server-network-policy created
networkpolicy.networking.k8s.io/argocd-notifications-controller-network-policy created
networkpolicy.networking.k8s.io/argocd-redis-network-policy created
networkpolicy.networking.k8s.io/argocd-repo-server-network-policy created
networkpolicy.networking.k8s.io/argocd-server-network-policy created

$ kubectl get all -n argocd
NAME                                                   READY   STATUS    RESTARTS        AGE
pod/argocd-application-controller-0                    1/1     Running   0               4m14s
pod/argocd-applicationset-controller-fc5545556-xwf5k   1/1     Running   0               4m15s
pod/argocd-dex-server-f59c65cff-rn6m5                  1/1     Running   1 (3m10s ago)   4m15s
pod/argocd-notifications-controller-59f6949d7-qmw9h    1/1     Running   0               4m15s
pod/argocd-redis-75c946f559-r7hw9                      1/1     Running   0               4m15s
pod/argocd-repo-server-6959c47c44-zcgvw                1/1     Running   0               4m15s
pod/argocd-server-65544f4864-d8bdg                     1/1     Running   0               4m15s

NAME                                              TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                      AGE
service/argocd-applicationset-controller          ClusterIP      10.96.198.72    <none>        7000/TCP,8080/TCP            4m15s
service/argocd-dex-server                         ClusterIP      10.96.130.197   <none>        5556/TCP,5557/TCP,5558/TCP   4m15s
service/argocd-metrics                            ClusterIP      10.96.76.149    <none>        8082/TCP                     4m15s
service/argocd-notifications-controller-metrics   ClusterIP      10.96.212.160   <none>        9001/TCP                     4m15s
service/argocd-redis                              ClusterIP      10.96.87.147    <none>        6379/TCP                     4m15s
service/argocd-repo-server                        ClusterIP      10.96.249.213   <none>        8081/TCP,8084/TCP            4m15s
service/argocd-server                             ClusterIP      10.96.182.198   <none>        80:31808/TCP,443:32242/TCP   4m15s
service/argocd-server-metrics                     ClusterIP      10.96.205.52    <none>        8083/TCP                     4m15s

NAME                                               READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/argocd-applicationset-controller   1/1     1            1           4m15s
deployment.apps/argocd-dex-server                  1/1     1            1           4m15s
deployment.apps/argocd-notifications-controller    1/1     1            1           4m15s
deployment.apps/argocd-redis                       1/1     1            1           4m15s
deployment.apps/argocd-repo-server                 1/1     1            1           4m15s
deployment.apps/argocd-server                      1/1     1            1           4m15s

NAME                                                         DESIRED   CURRENT   READY   AGE
replicaset.apps/argocd-applicationset-controller-fc5545556   1         1         1       4m15s
replicaset.apps/argocd-dex-server-f59c65cff                  1         1         1       4m15s
replicaset.apps/argocd-notifications-controller-59f6949d7    1         1         1       4m15s
replicaset.apps/argocd-redis-75c946f559                      1         1         1       4m15s
replicaset.apps/argocd-repo-server-6959c47c44                1         1         1       4m15s
replicaset.apps/argocd-server-65544f4864                     1         1         1       4m15s

NAME                                             READY   AGE
statefulset.apps/argocd-application-controller   1/1     4m15s

$ kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "LoadBalancer"}}'
service/argocd-server patched

$ kubectl get svc argocd-server -n argocd -o=jsonpath='{.status.loadBalancer.ingress[0].ip}'
172.18.0.6

$ curl -sIL http://172.18.0.6:80 -k
HTTP/1.1 307 Temporary Redirect
Content-Type: text/html; charset=utf-8
Location: https://172.18.0.6/
Date: Fri, 28 Nov 2025 14:30:00 GMT

HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Length: 788
Content-Security-Policy: frame-ancestors 'self';
Content-Type: text/html; charset=utf-8
Vary: Accept-Encoding
X-Frame-Options: sameorigin
X-Xss-Protection: 1
Date: Fri, 28 Nov 2025 14:30:00 GMT

$ argocd admin initial-password -n argocd
CH5hFPo5q1TcHi9-

 This password must be only used for first time login. We strongly recommend you update the password using `argocd account update-password`.

$ argocd login 172.18.0.6 --insecure --username admin
Password: CH5hFPo5q1TcHi9-
'admin:login' logged in successfully
Context '172.18.0.6' updated

$ argocd account update-password
*** Enter password of currently logged in user (admin):
*** Enter new password for user admin:
*** Confirm new password for user admin:
Password updated
Context '172.18.0.6' updated

$ kubectl -n argocd delete secret argocd-initial-admin-secret
secret "argocd-initial-admin-secret" deleted

$ argocd version
argocd: v3.2.0+66b2f30
  BuildDate: 2025-11-04T15:21:01Z
  GitCommit: 66b2f302d91a42cc151808da0eec0846bbe1062c
  GitTreeState: clean
  GoVersion: go1.25.0
  Compiler: gc
  Platform: windows/amd64
argocd-server: v3.2.0+66b2f30
  BuildDate: 2025-11-04T14:51:35Z
  GitCommit: 66b2f302d91a42cc151808da0eec0846bbe1062c
  GitTreeState: clean
  GoVersion: go1.25.0
  Compiler: gc
  Platform: linux/amd64
  Kustomize Version: v5.7.0 2025-06-28T07:00:07Z
  Helm Version: v3.18.4+gd80839c
  Kubectl Version: v0.34.0

Setup a Repository

$ argocd repo add https://github.com/viastakhov/argocd-kustomize-demo.git
Repository 'https://github.com/viastakhov/argocd-kustomize-demo.git' added

$ argocd repo list
TYPE  NAME  REPO                                                     INSECURE  OCI    LFS    CREDS  STATUS      MESSAGE  PROJECT
git         https://github.com/viastakhov/argocd-kustomize-demo.git  false     false  false  false  Successful

Create a Project

Projects provide a logical grouping of applications, which is useful when Argo CD is used by multiple teams.

# ./argo-cd/project.yaml 

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: nginx
spec:
  sourceRepos:
  - '*'
  destinations:
  - namespace: '*'
    server: '*'
  clusterResourceWhitelist:
  - group: '*'
    kind: '*'

$ argocd proj create -f ./argo-cd/project.yaml

$ argocd proj list
NAME     DESCRIPTION  DESTINATIONS  SOURCES  CLUSTER-RESOURCE-WHITELIST  NAMESPACE-RESOURCE-BLACKLIST  SIGNATURE-KEYS  ORPHANED-RESOURCES  DESTINATION-SERVICE-ACCOUNTS
default               *,*           *        */*                         <none>                        <none>          disabled            <none>
nginx                 *,*           *        */*                         <none>                        <none>          disabled            <none>

Create an Application

An Application is the Kubernetes resource object representing a deployed application instance in an environment.

# ./argo-cd/appset.yaml 

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: nginx
  namespace: argocd
spec:
  goTemplate: true
  goTemplateOptions: ["missingkey=error"]
  generators:
  - git:
      repoURL: https://github.com/viastakhov/argocd-kustomize-demo.git
      revision: HEAD
      directories:
      - path: kustomize/overlays/*  
  template:
    metadata:
      name: 'nginx-{{index .path.segments 2}}'
      finalizers:
      - resources-finalizer.argocd.argoproj.io
    spec:
      project: nginx
      source:
        repoURL: https://github.com/viastakhov/argocd-kustomize-demo.git
        targetRevision: HEAD
        path: '{{.path.path}}'   
      destination:
        server: https://kubernetes.default.svc
        namespace: '{{index .path.segments 2}}'
      syncPolicy:
        syncOptions:
        - CreateNamespace=false  
        automated:
          enabled: true
          prune: false
          selfHeal: false
          allowEmpty: false

$ argocd appset create ./argo-cd/appset.yaml
ApplicationSet 'nginx' created
Name:               argocd/nginx
Project:            nginx
Server:             https://kubernetes.default.svc
Namespace:          {{index .path.segments 2}}
Source:
- Repo:             https://github.com/viastakhov/argocd-kustomize-demo.git
  Target:           HEAD
  Path:             {{.path.path}}
SyncPolicy:         Automated

$ argocd appset list
NAME          PROJECT  SYNCPOLICY  CONDITIONS                                                                                                                                                                                                                                                             REPO                                                     PATH            TARGET
argocd/nginx  nginx    nil         [{ParametersGenerated Successfully generated parameters for all Applications 2025-12-04 03:04:54 +0300 MSK True ParametersGenerated} {ResourcesUpToDate All applications have been generated successfully 2025-12-04 03:04:54 +0300 MSK True ApplicationSetUpToDate}]  https://github.com/viastakhov/argocd-kustomize-demo.git  {{.path.path}}  HEAD

$ argocd app list
NAME               CLUSTER                         NAMESPACE  PROJECT  STATUS  HEALTH   SYNCPOLICY  CONDITIONS  REPO                                                     PATH                     TARGET
argocd/nginx-dev   https://kubernetes.default.svc  dev        nginx    Synced  Healthy  Auto        <none>      https://github.com/viastakhov/argocd-kustomize-demo.git  kustomize/overlays/dev   HEAD
argocd/nginx-prod  https://kubernetes.default.svc  prod       nginx    Synced  Healthy  Auto        <none>      https://github.com/viastakhov/argocd-kustomize-demo.git  kustomize/overlays/prod  HEAD

$ argocd app resources nginx-prod
GROUP  KIND        NAMESPACE   NAME                   ORPHANED
       ConfigMap   production  nginx-conf-c6752d2t6f  No
       Namespace               production             No
       Service     production  nginx-svc              No
apps   Deployment  production  nginx-app              No

$ argocd app get nginx-prod
Name:               argocd/nginx-prod
Project:            nginx
Server:             https://kubernetes.default.svc
Namespace:          prod
URL:                https://172.18.0.6/applications/nginx-prod
Source:
- Repo:             https://github.com/viastakhov/argocd-kustomize-demo.git
  Target:           HEAD
  Path:             kustomize/overlays/prod
SyncWindow:         Sync Allowed
Sync Policy:        Automated
Sync Status:        Synced to HEAD (d70b25e)
Health Status:      Healthy

GROUP  KIND        NAMESPACE   NAME                   STATUS   HEALTH   HOOK  MESSAGE
       Namespace   prod        production             Running  Synced         namespace/production created
       ConfigMap   production  nginx-conf-c6752d2t6f  Synced                  configmap/nginx-conf-c6752d2t6f created
       Service     production  nginx-svc              Synced   Healthy        service/nginx-svc created
apps   Deployment  production  nginx-app              Synced   Healthy        deployment.apps/nginx-app created
       Namespace               production             Synced

Cleanup

$ argocd appset delete nginx
Are you sure you want to delete 'nginx' and all its Applications? [y/n] y
applicationset 'nginx' deleted

$ argocd appset list
NAME  PROJECT  SYNCPOLICY  CONDITIONS  REPO  PATH  TARGET

$ argocd app list
NAME  CLUSTER  NAMESPACE  PROJECT  STATUS  HEALTH  SYNCPOLICY  CONDITIONS  REPO  PATH  TARGET

Bonus

Applications In Any Namespace

Since version 2.5, Argo CD supports managing Application resources in namespaces other than the namespace of the control plane (usually argocd), but this feature has to be explicitly enabled and configured accordingly.

# ./argo-cd/project.yaml 

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: nginx
spec:
  sourceNamespaces:
  - '*'
  sourceRepos:
  - '*'
  destinations:
  - namespace: '*'
    server: '*'
  clusterResourceWhitelist:
  - group: '*'
    kind: '*'

$ argocd proj create -f ./argo-cd/project.yaml

$ kubectl patch cm/argocd-cmd-params-cm -n argocd -p '{"data": {"application.namespaces": "'*'"}}'
configmap/argocd-cmd-params-cm patched

$ kubectl rollout restart -n argocd deployment argocd-server
deployment.apps/argocd-server restarted

$ kubectl rollout restart -n argocd statefulset argocd-application-controller
statefulset.apps/argocd-application-controller restarted

$ kubectl patch clusterrole argocd-server --type='json' -p='[{"op": "replace", "path": "/rules/3/resources", "value": ["applications", "applicationsets", "appprojects"]}]'
clusterrole.rbac.authorization.k8s.io/argocd-server patched

$ kubectl patch clusterrole argocd-server --type='json' -p='[{"op": "replace", "path": "/rules/3/verbs", "value": ["get", "watch", "list", "create", "update", "delete", "patch"]}]'
clusterrole.rbac.authorization.k8s.io/argocd-server patched

$ kubectl create ns development
namespace/development created

$ kubectl create ns production
namespace/production created

$ argocd app create nginx \
  --repo https://github.com/viastakhov/argocd-kustomize-demo.git \
  --path kustomize/overlays/dev \
  --dest-server https://kubernetes.default.svc \
  --dest-namespace development \
  --sync-policy auto \
  --project nginx \
  --app-namespace development \
  --set-finalizer
application 'nginx' created

$ argocd app create nginx \
  --repo https://github.com/viastakhov/argocd-kustomize-demo.git \
  --path kustomize/overlays/prod \
  --dest-server https://kubernetes.default.svc \
  --dest-namespace production \
  --sync-policy auto \
  --project nginx \
  --app-namespace production \
  --set-finalizer
application 'nginx' created

$ argocd app list
NAME               CLUSTER                         NAMESPACE    PROJECT  STATUS  HEALTH   SYNCPOLICY  CONDITIONS  REPO                                                     PATH                     TARGET
development/nginx  https://kubernetes.default.svc  development  nginx    Synced  Healthy  Auto        <none>      https://github.com/viastakhov/argocd-kustomize-demo.git  kustomize/overlays/dev
production/nginx   https://kubernetes.default.svc  production   nginx    Synced  Healthy  Auto        <none>      https://github.com/viastakhov/argocd-kustomize-demo.git  kustomize/overlays/prod

$ kubectl get applications -n development -o wide
NAME    SYNC STATUS   HEALTH STATUS   REVISION                                   PROJECT
nginx   Synced        Healthy         2550d54636eee62d843f4c56b27b7bdcf351d34a   nginx

$ kubectl get applications -n production -o wide
NAME    SYNC STATUS   HEALTH STATUS   REVISION                                   PROJECT
nginx   Synced        Healthy         2550d54636eee62d843f4c56b27b7bdcf351d34a   nginx

$ kubectl delete ns development
namespace "development" deleted

$ kubectl delete ns production
namespace "production" deleted

$ argocd app list
NAME  CLUSTER  NAMESPACE  PROJECT  STATUS  HEALTH  SYNCPOLICY  CONDITIONS  REPO  PATH  TARGET

Kubernetes by Example

Ježek — Wed, 05 Nov 2025 20:24:58 +0000

The article explores Kubernetes through practical examples.

The content of the article was structured to ensure clarity and depth while maintaining focus on real-world use cases. By leveraging the hands-on approach advocated throughout the publication, readers will gain an enhanced understanding of core concepts in Kubernetes such as pod management, service discovery, etc.

The article was inspired by the book Kubernetes in Action by Marko Lukša, and in the process of preparing this article, the official Kubernetes Documentation was utilized as a primary reference material. Thus, I insistently recommend that you familiarize yourself with the above-mentioned references in advance.

Enjoy!

Kubernetes in Docker
Pods
Namespaces
ReplicaSet
DaemonSet
Jobs
CronJob
Service
Ingress
Probes
Volumes
ConfigMaps
Secrets
Deployments
StatefulSet
ServiceAccount
RBAC
Pod Security
NetworkPolicy
LimitRange
ResourceQuota
HorizontalPodAutoscaler
PodDisruptionBudget
Taints and Tolerations
Affinity

Kubernetes in Docker

kind is a tool for running local Kubernetes clusters using Docker container nodes.

Create a cluster

# kind-cluster.yaml

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
networking:
  apiServerPort: 6443
nodes:
- role: control-plane
- role: worker
  extraPortMappings:
  - containerPort: 30666
    hostPort: 40000
- role: worker
  extraPortMappings:
  - containerPort: 30666
    hostPort: 40001
- role: worker
  extraPortMappings:
  - containerPort: 30666
    hostPort: 40002

$ kind create cluster --config kind-cluster.yaml
Creating cluster "kind" ...
 • Ensuring node image (kindest/node:v1.33.1) 🖼  ...
 ✓ Ensuring node image (kindest/node:v1.33.1) 🖼
 • Preparing nodes 📦 📦 📦 📦   ...
 ✓ Preparing nodes 📦 📦 📦 📦
 • Writing configuration 📜  ...
 ✓ Writing configuration 📜
 • Starting control-plane 🕹️  ...
 ✓ Starting control-plane 🕹️
 • Installing CNI 🔌  ...
 ✓ Installing CNI 🔌
 • Installing StorageClass 💾  ...
 ✓ Installing StorageClass 💾
 • Joining worker nodes 🚜  ...
 ✓ Joining worker nodes 🚜
Set kubectl context to "kind-kind"
You can now use your cluster with:

kubectl cluster-info --context kind-kind

Cluster info

$ kind get clusters
kind

$ kubectl cluster-info --context kind-kind
Kubernetes control plane is running at https://127.0.0.1:6443
CoreDNS is running at https://127.0.0.1:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

Cluster nodes

$ kubectl get nodes
NAME                 STATUS   ROLES           AGE   VERSION
kind-control-plane   Ready    control-plane   39m   v1.33.1
kind-worker          Ready    <none>          39m   v1.33.1
kind-worker2         Ready    <none>          39m   v1.33.1
kind-worker3         Ready    <none>          39m   v1.33.1

Pods

Pods are the smallest deployable units of computing that you can create and manage in Kubernetes.

Create a pod

Imperative way

$ kubectl run kubia --image=luksa/kubia --port=8080
pod/kubia created

$ kubectl get pods
NAME    READY   STATUS    RESTARTS   AGE
kubia   1/1     Running   0          5m26s

Declarative way

# pod-basic.yaml

apiVersion: v1
kind: Pod
metadata:
  name: kubia
spec:
  containers:
  - image: luksa/kubia
    name: kubia
    ports:
    - containerPort: 8080
      protocol: TCP

$ kubectl create -f pod-basic.yaml
pod/kubia created

$ kubectl get po
NAME    READY   STATUS    RESTARTS   AGE
kubia   1/1     Running   0          9s

Logs

$ kubectl logs kubia
Kubia server starting...

Logs from specific container in pod:

$ kubectl logs kubia -c kubia
Kubia server starting...

Port forwarding from host to pod

$ kubectl port-forward kubia 30000:8080
Forwarding from 127.0.0.1:30000 -> 8080
Forwarding from [::1]:30000 -> 8080

$ curl -s localhost:30000
You've hit kubia

Labels and Selectors

Labels are key/value pairs that are attached to objects such as Pods.

Labels

# pod-labels.yaml

apiVersion: v1
kind: Pod
metadata:
  name: kubia-labels
  labels:
    tier: backend
    env: dev
spec:
  containers:
  - image: luksa/kubia
    name: kubia
    ports:
    - containerPort: 8080
      protocol: TCP

$ kubectl create -f pod-labels.yaml
pod/kubia-labels created

$ kubectl get po --show-labels
NAME           READY   STATUS    RESTARTS   AGE     LABELS
kubia          1/1     Running   0          4d22h   <none>
kubia-labels   1/1     Running   0          30s     env=dev,tier=backend

$ kubectl get po --label-columns tier,env
NAME           READY   STATUS    RESTARTS   AGE     TIER      ENV
kubia          1/1     Running   0          4d22h
kubia-labels   1/1     Running   0          20m     backend   dev

$ kubectl label po kubia-labels env=test
error: 'env' already has a value (dev), and --overwrite is false

$ kubectl label po kubia-labels env=test --overwrite
pod/kubia-labels labeled

$ kubectl get po --label-columns tier,env
NAME           READY   STATUS    RESTARTS   AGE     TIER      ENV
kubia          1/1     Running   0          4d22h
kubia-labels   1/1     Running   0          24m     backend   test

Selectors

$ kubectl get po -l 'env' --show-labels
NAME           READY   STATUS    RESTARTS   AGE     LABELS
kubia-labels   1/1     Running   0          3h25m   env=test,tier=backend

$ kubectl get po -l '!env' --show-labels
NAME    READY   STATUS    RESTARTS   AGE    LABELS
kubia   1/1     Running   0          5d1h   <none>

$ kubectl get po -l tier=backend --show-labels
NAME           READY   STATUS    RESTARTS   AGE     LABELS
kubia-labels   1/1     Running   0          3h28m   env=test,tier=backend

Annotations

You can use annotations to attach arbitrary non-identifying metadata to objects.

# pod-annotations.yaml

apiVersion: v1
kind: Pod
metadata:
  name: kubia-annotations
  annotations:
    imageregistry: "https://hub.docker.com/"
spec:
  containers:
  - image: luksa/kubia
    name: kubia
    ports:
    - containerPort: 8080
      protocol: TCP

$ kubectl create -f pod-annotations.yaml
pod/kubia-annotations created

$ kubectl describe pod kubia-annotations | grep Annotations
Annotations:      imageregistry: https://hub.docker.com/

$ kubectl annotate pod/kubia-annotations imageregistry=nexus.org --overwrite
pod/kubia-annotations annotated

$ kubectl describe pod kubia-annotations | grep Annotations
Annotations:      imageregistry: nexus.org

Namespaces

Namespaces provide a mechanism for isolating groups of resources within a single cluster.

$ kubectl get ns
NAME                 STATUS   AGE
default              Active   5d2h
kube-node-lease      Active   5d2h
kube-public          Active   5d2h
kube-system          Active   5d2h
local-path-storage   Active   5d2h

$ kubectl get pods --namespace=default
NAME                READY   STATUS    RESTARTS   AGE
kubia               1/1     Running   0          5d2h
kubia-annotations   1/1     Running   0          19m
kubia-labels        1/1     Running   0          4h15m

$ kubectl create namespace custom-namespace
namespace/custom-namespace created

$ kubectl get pods --namespace=custom-namespace
No resources found in custom-namespace namespace.

$ kubectl run nginx --image=nginx --namespace=custom-namespace
pod/nginx created

$ kubectl get pods --namespace=custom-namespace
NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   0          61s

$ kubectl config set-context --current --namespace=custom-namespace
Context "kind-kind" modified.

$ kubectl get pods
NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   0          2m57s

$ kubectl config set-context --current --namespace=default
Context "kind-kind" modified.

$ kubectl get pods
NAME                READY   STATUS    RESTARTS   AGE
kubia               1/1     Running   0          5d2h
kubia-annotations   1/1     Running   0          30m
kubia-labels        1/1     Running   0          4h26m

$ kubectl delete ns custom-namespace
namespace "custom-namespace" deleted

$ kubectl get pods --namespace=custom-namespace
No resources found in custom-namespace namespace.

$ kubectl get ns
NAME                 STATUS   AGE
default              Active   5d3h
kube-node-lease      Active   5d3h
kube-public          Active   5d3h
kube-system          Active   5d3h
local-path-storage   Active   5d3h

$ kubectl delete po --all
pod "kubia" deleted
pod "kubia-annotations" deleted
pod "kubia-labels" deleted

$ kubectl get ns
NAME                 STATUS   AGE
default              Active   5d3h
kube-node-lease      Active   5d3h
kube-public          Active   5d3h
kube-system          Active   5d3h
local-path-storage   Active   5d3h

$ kubectl get pods --namespace=default
No resources found in default namespace.

ReplicaSet

A ReplicaSet's purpose is to maintain a stable set of replica Pods running at any given time. As such, it is often used to guarantee the availability of a specified number of identical Pods.

# replicaset.yaml

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: kubia
spec:
  replicas: 3
  selector:
    matchLabels:
      app: kubia
  template:
    metadata:
      labels:
        app: kubia
    spec:
      containers:
      - name: kubia
        image: luksa/kubia

$ kubectl create -f replicaset.yaml
replicaset.apps/kubia created

$ kubectl get po
NAME          READY   STATUS    RESTARTS   AGE
kubia-5l82z   1/1     Running   0          5s
kubia-bkjwk   1/1     Running   0          5s
kubia-k78j5   1/1     Running   0          5s

$ kubectl get rs
NAME    DESIRED   CURRENT   READY   AGE
kubia   3         3         3       64s

$ kubectl delete rs kubia
replicaset.apps "kubia" deleted

$ kubectl get rs
No resources found in default namespace.

$ kubectl get po
NAME          READY   STATUS        RESTARTS   AGE
kubia-5l82z   1/1     Terminating   0          5m30s
kubia-bkjwk   1/1     Terminating   0          5m30s
kubia-k78j5   1/1     Terminating   0          5m30s

DaemonSet

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.

# daemonset.yaml

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd
spec:
  selector:
    matchLabels:
      app: fluentd
  template:
    metadata:
      labels:
        app: fluentd
    spec:
      nodeSelector:
        disk: ssd
      containers:
      - name: fluentd
        image: quay.io/fluentd_elasticsearch/fluentd:v5.0.1

$ kubectl create -f daemonset.yaml
daemonset.apps/fluentd created

$ kubectl get ds
NAME      DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
fluentd   0         0         0       0            0           disk=ssd        115s

$ kubectl get po
No resources found in default namespace.

$ kubectl get node
NAME                 STATUS   ROLES           AGE     VERSION
kind-control-plane   Ready    control-plane   5d21h   v1.33.1
kind-worker          Ready    <none>          5d21h   v1.33.1
kind-worker2         Ready    <none>          5d21h   v1.33.1
kind-worker3         Ready    <none>          5d21h   v1.33.1

$ kubectl label node kind-worker3 disk=ssd
node/kind-worker3 labeled

$ kubectl get ds
NAME      DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
fluentd   1         1         1       1            1           disk=ssd        3m49s

$ kubectl get po
NAME            READY   STATUS    RESTARTS   AGE
fluentd-cslcb   1/1     Running   0          39s

$ kubectl delete ds fluentd
daemonset.apps "fluentd" deleted

$ kubectl get ds
No resources found in default namespace.

$ kubectl get po
No resources found in default namespace.

Jobs

Jobs represent one-off tasks that run to completion and then stop.

# job.yaml

apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    spec:
      containers:
      - name: pi
        image: perl:5.34.0
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never
  backoffLimit: 4

$ kubectl create -f job.yaml
job.batch/pi created

$ kubectl get jobs
NAME   STATUS    COMPLETIONS   DURATION   AGE
pi     Running   0/1           34s        34s

$ kubectl get jobs
NAME   STATUS     COMPLETIONS   DURATION   AGE
pi     Complete   1/1           54s        62s

$ kubectl get po
NAME       READY   STATUS      RESTARTS   AGE
pi-8rdmn   0/1     Completed   0          2m1s

$ kubectl events pod/pi-8rdmn
LAST SEEN   TYPE     REASON             OBJECT         MESSAGE
3m44s       Normal   Scheduled          Pod/pi-8rdmn   Successfully assigned default/pi-8rdmn to kind-worker2
3m44s       Normal   Pulling            Pod/pi-8rdmn   Pulling image "perl:5.34.0"
3m44s       Normal   SuccessfulCreate   Job/pi         Created pod: pi-8rdmn
2m59s       Normal   Pulled             Pod/pi-8rdmn   Successfully pulled image "perl:5.34.0" in 44.842s (44.842s including waiting). Image size: 336374010 bytes.
2m59s       Normal   Created            Pod/pi-8rdmn   Created container: pi
2m59s       Normal   Started            Pod/pi-8rdmn   Started container pi
2m50s       Normal   Completed          Job/pi         Job completed

$ kubectl delete job/pi
job.batch "pi" deleted

$ kubectl get po
No resources found in default namespace.

CronJob

CronJob starts one-time Jobs on a repeating schedule.

# cronjob.yaml

apiVersion: batch/v1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "* * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox:1.28
            imagePullPolicy: IfNotPresent
            command:
            - /bin/sh
            - -c
            - date; echo Hello from the Kubernetes cluster
          restartPolicy: OnFailure

$ kubectl create -f cronjob.yaml
cronjob.batch/hello created

$ kubectl get cronjobs
NAME    SCHEDULE    TIMEZONE   SUSPEND   ACTIVE   LAST SCHEDULE   AGE
hello   * * * * *   <none>     False     0        8s              55s

$ kubectl get pods
NAME                   READY   STATUS      RESTARTS   AGE
hello-29223074-gsztp   0/1     Completed   0          30s

$ kubectl get pods
NAME                   READY   STATUS      RESTARTS   AGE
hello-29223074-gsztp   0/1     Completed   0          106s
hello-29223075-9r7kx   0/1     Completed   0          46s

$ kubectl delete cronjobs/hello
cronjob.batch "hello" deleted

$ kubectl get cronjobs
No resources found in default namespace.

$ kubectl get pods
No resources found in default namespace.

Service

Service is a method for exposing a network application that is running as one or more Pods in your cluster.

There several Service types supported in Kubernetes:

ClusterIP
NodePort
ExternalName
LoadBalancer

ClusterIP

Exposes the Service on a cluster-internal IP. Choosing this value makes the Service only reachable from within the cluster. This is the default that is used if you don't explicitly specify a type for a Service. You can expose the Service to the public internet using an Ingress or a Gateway.

# pod-labels.yaml

apiVersion: v1
kind: Pod
metadata:
  name: kubia-labels
  labels:
    tier: backend
    env: dev
spec:
  containers:
  - image: luksa/kubia
    name: kubia
    ports:
    - containerPort: 8080
      protocol: TCP

# service-basic.yaml

apiVersion: v1
kind: Service
metadata:
  name: kubia-svc
spec:
  selector:
    tier: backend
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

$ kubectl create -f pod-labels.yaml
pod/kubia-labels created

$ kubectl create -f service-basic.yaml
service/kubia-svc created

$ kubectl get svc
NAME         TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.96.0.1      <none>        443/TCP   21d
kubia-svc    ClusterIP   10.96.158.86   <none>        80/TCP    5s

$ kubectl get po
NAME           READY   STATUS    RESTARTS   AGE
kubia-labels   1/1     Running   0          116s

$ kubectl exec kubia-labels -- curl -s http://10.96.158.86:80
You've hit kubia-labels

$ kubectl delete -f service-basic.yaml
service "kubia-svc" deleted

$ kubectl delete -f pod-labels.yaml
pod "kubia-labels" deleted

# pod-nginx.yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    app.kubernetes.io/name: proxy
spec:
  containers:
  - name: nginx
    image: nginx:stable
    ports:
      - containerPort: 80
        name: http-web-svc

# service-nginx.yaml

apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
spec:
  selector:
    app.kubernetes.io/name: proxy
  ports:
    - name: http-port
      protocol: TCP
      port: 8080
      targetPort: http-web-svc

$ kubectl create -f pod-nginx.yaml
pod/nginx created

$ kubectl create -f service-nginx.yaml
service/nginx-svc created

$ kubectl get po
NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   0          5m51s

$ kubectl get svc
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
kubernetes   ClusterIP   10.96.0.1       <none>        443/TCP    21d
nginx-svc    ClusterIP   10.96.230.243   <none>        8080/TCP   32s

$ kubectl exec nginx -- curl -sI http://10.96.230.243:8080
HTTP/1.1 200 OK
Server: nginx/1.28.0
Date: Thu, 07 Aug 2025 12:09:24 GMT
Content-Type: text/html
Content-Length: 615
Last-Modified: Wed, 23 Apr 2025 11:48:54 GMT
Connection: keep-alive
ETag: "6808d3a6-267"
Accept-Ranges: bytes

$ kubectl exec nginx -- curl -sI http://nginx-svc:8080 | head -n 2
HTTP/1.1 200 OK
Server: nginx/1.28.0

$ kubectl exec nginx -- curl -sI http://nginx-svc.default:8080 | head -n 2
HTTP/1.1 200 OK
Server: nginx/1.28.0

$ kubectl exec nginx -- curl -sI http://nginx-svc.default.svc:8080 | head -n 2
HTTP/1.1 200 OK
Server: nginx/1.28.0

$ kubectl exec nginx -- curl -sI http://nginx-svc.default.svc.cluster.local:8080 | head -n 2
HTTP/1.1 200 OK
Server: nginx/1.28.0

$ kubectl delete -f service-nginx.yaml
service "nginx-svc" deleted

$ kubectl delete -f pod-nginx.yaml
pod "nginx" deleted

ExternalName

Maps the Service to the contents of the externalName field (for example, to the hostname api.foo.bar.example). The mapping configures your cluster's DNS server to return a CNAME record with that external hostname value. No proxying of any kind is set up.

# service-ext.yaml

apiVersion: v1
kind: Service
metadata:
  name: httpbin-service
spec:
  type: ExternalName
  externalName: httpbin.org

$ kubectl create -f service-ext.yaml
service/httpbin-service created

$ kubectl create -f pod-basic.yaml
pod/kubia created

$ kubectl get svc
NAME              TYPE           CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
httpbin-service   ExternalName   <none>       httpbin.org   <none>    4m17s
kubernetes        ClusterIP      10.96.0.1    <none>        443/TCP   22d

$ kubectl exec kubia -- curl -sk -X GET https://httpbin-service/uuid -H "accept: application/json"
{
  "uuid": "6a48fe51-a6b6-4e0a-9ef2-381ba7ea2c69"
}

$ kubectl delete -f pod-basic.yaml
pod "kubia" deleted

$ kubectl delete -f service-ext.yaml
service "httpbin-service" deleted

NodePort

Exposes the Service on each Node's IP at a static port (the NodePort). To make the node port available, Kubernetes sets up a cluster IP address, the same as if you had requested a Service of type: ClusterIP.

# service-nginx-nodeport.yaml

apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
spec:
  type: NodePort
  selector:
    app.kubernetes.io/name: proxy
  ports:
  - port: 8080
    targetPort: http-web-svc
    nodePort: 30666

$ kubectl create -f pod-nginx.yaml
pod/nginx created

$ kubectl create -f service-nginx-nodeport.yaml
service/nginx-svc created

$ kubectl get svc nginx-svc
NAME        TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)          AGE
nginx-svc   NodePort   10.96.252.35   <none>        8080:30666/TCP   9s

$ docker ps
CONTAINER ID   IMAGE                  COMMAND                  CREATED       STATUS       PORTS                      NAMES
da2c842ddfd6   kindest/node:v1.33.1   "/usr/local/bin/entr…"   3 weeks ago   Up 3 weeks   0.0.0.0:40000->30666/tcp   kind-worker
16bf718b93b6   kindest/node:v1.33.1   "/usr/local/bin/entr…"   3 weeks ago   Up 3 weeks   127.0.0.1:6443->6443/tcp   kind-control-plane
bb18cefdb180   kindest/node:v1.33.1   "/usr/local/bin/entr…"   3 weeks ago   Up 3 weeks   0.0.0.0:40002->30666/tcp   kind-worker3
42cea7794f0b   kindest/node:v1.33.1   "/usr/local/bin/entr…"   3 weeks ago   Up 3 weeks   0.0.0.0:40001->30666/tcp   kind-worker2

$ curl -sI http://localhost:40000 | head -n 2
HTTP/1.1 200 OK
Server: nginx/1.28.0

$ curl -sI http://localhost:40001 | head -n 2
HTTP/1.1 200 OK
Server: nginx/1.28.0

$ curl -sI http://localhost:40002 | head -n 2
HTTP/1.1 200 OK
Server: nginx/1.28.0

$ kubectl delete -f service-nginx-nodeport.yaml
service "nginx-svc" deleted

$ kubectl delete -f pod-nginx.yaml
pod "nginx" deleted

LoadBalancer

Exposes the Service externally using an external load balancer. Kubernetes does not directly offer a load balancing component; you must provide one, or you can integrate your Kubernetes cluster with a cloud provider.

Let's a look how to get service of type LoadBalancer working in a kind cluster using Cloud Provider KIND.

# service-lb-demo.yaml

kind: Pod
apiVersion: v1
metadata:
  name: foo-app
  labels:
    app: http-echo
spec:
  containers:
  - command:
    - /agnhost
    - serve-hostname
    - --http=true
    - --port=8080
    image: registry.k8s.io/e2e-test-images/agnhost:2.39
    name: foo-app

---
kind: Pod
apiVersion: v1
metadata:
  name: bar-app
  labels:
    app: http-echo
spec:
  containers:
  - command:
    - /agnhost
    - serve-hostname
    - --http=true
    - --port=8080
    image: registry.k8s.io/e2e-test-images/agnhost:2.39
    name: bar-app

---
kind: Service
apiVersion: v1
metadata:
  name: http-echo-service
spec:
  type: LoadBalancer
  selector:
    app: http-echo
  ports:
  - port: 5678
    targetPort: 8080

$ kubectl create -f service-lb-demo.yaml
pod/foo-app created
pod/bar-app created
service/http-echo-service created

$ kubectl get svc http-echo-service
NAME                TYPE           CLUSTER-IP    EXTERNAL-IP   PORT(S)          AGE
http-echo-service   LoadBalancer   10.96.97.99   172.18.0.6    5678:31196/TCP   58s

$ kubectl get svc http-echo-service -o=jsonpath='{.status.loadBalancer.ingress[0].ip}'
172.18.0.6

$ for _ in {1..4}; do curl -s 172.18.0.6:5678; echo; done
foo-app
bar-app
bar-app
foo-app

$ kubectl delete -f service-lb-demo.yaml
pod "foo-app" deleted
pod "bar-app" deleted
service "http-echo-service" deleted

Ingress

Ingress exposes HTTP and HTTPS routes from outside the cluster to services within the cluster.

Ingress Controller

In order for an Ingress to work in your cluster, there must be an Ingress Controller running.

You have to run Cloud Provider KIND to enable the loadbalancer controller which Nginx Ingress controller will use through the loadbalancer API in a kind cluster.

$ kubectl apply -f https://kind.sigs.k8s.io/examples/ingress/deploy-ingress-nginx.yaml
namespace/ingress-nginx created
serviceaccount/ingress-nginx created
serviceaccount/ingress-nginx-admission created
role.rbac.authorization.k8s.io/ingress-nginx created
role.rbac.authorization.k8s.io/ingress-nginx-admission created
clusterrole.rbac.authorization.k8s.io/ingress-nginx created
clusterrole.rbac.authorization.k8s.io/ingress-nginx-admission created
rolebinding.rbac.authorization.k8s.io/ingress-nginx created
rolebinding.rbac.authorization.k8s.io/ingress-nginx-admission created
clusterrolebinding.rbac.authorization.k8s.io/ingress-nginx created
clusterrolebinding.rbac.authorization.k8s.io/ingress-nginx-admission created
configmap/ingress-nginx-controller created
service/ingress-nginx-controller created
service/ingress-nginx-controller-admission created
deployment.apps/ingress-nginx-controller created
job.batch/ingress-nginx-admission-create created
job.batch/ingress-nginx-admission-patch created
ingressclass.networking.k8s.io/nginx created
validatingwebhookconfiguration.admissionregistration.k8s.io/ingress-nginx-admission created

$ kubectl wait --namespace ingress-nginx \
>   --for=condition=ready pod \
>   --selector=app.kubernetes.io/component=controller \
>   --timeout=90s
pod/ingress-nginx-controller-86bb9f8d4b-4hg7w condition met

$ kubectl get all -n ingress-nginx
NAME                                            READY   STATUS      RESTARTS   AGE
pod/ingress-nginx-admission-create-ldc97        0/1     Completed   0          2m25s
pod/ingress-nginx-admission-patch-zzlh7         0/1     Completed   0          2m25s
pod/ingress-nginx-controller-86bb9f8d4b-4hg7w   1/1     Running     0          2m25s

NAME                                         TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)                      AGE
service/ingress-nginx-controller             LoadBalancer   10.96.146.11   172.18.0.6    80:30367/TCP,443:31847/TCP   2m25s
service/ingress-nginx-controller-admission   ClusterIP      10.96.50.204   <none>        443/TCP                      2m25s

NAME                                       READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/ingress-nginx-controller   1/1     1            1           2m25s

NAME                                                  DESIRED   CURRENT   READY   AGE
replicaset.apps/ingress-nginx-controller-86bb9f8d4b   1         1         1       2m25s

NAME                                       STATUS     COMPLETIONS   DURATION   AGE
job.batch/ingress-nginx-admission-create   Complete   1/1           11s        2m25s
job.batch/ingress-nginx-admission-patch    Complete   1/1           12s        2m25s

Ingress resources

The Ingress concept lets you map traffic to different backends based on rules you define via the Kubernetes API. Traffic routing is controlled by rules defined on the Ingress resource.

Basic usage

# pod-foo-bar.yaml

apiVersion: v1
kind: Pod
metadata:
  name: kubia-foo
  labels:
    app: foo
spec:
  containers:
  - image: luksa/kubia
    name: kubia
    ports:
    - containerPort: 8080
      protocol: TCP
      name: http-port

---
apiVersion: v1
kind: Pod
metadata:
  name: kubia-bar
  labels:
    app: bar
spec:
  containers:
  - image: luksa/kubia
    name: kubia
    ports:
    - containerPort: 8080
      name: http-port

# service-foo-bar.yaml

apiVersion: v1
kind: Service
metadata:
  name: kubia-foo-svc
spec:
  selector:
    app: foo
  ports:
    - name: http-port
      protocol: TCP
      port: 8080
      targetPort: http-port

---
apiVersion: v1
kind: Service
metadata:
  name: kubia-bar-svc
spec:
  selector:
    app: bar
  ports:
    - name: http-port
      protocol: TCP
      port: 8080
      targetPort: http-port

# ingress-basic.yaml 

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: kubia
spec:
  rules:
  - http:
      paths:
      - path: /foo
        pathType: Prefix
        backend:
          service:
            name: kubia-foo-svc
            port:
              number: 80
      - path: /bar
        pathType: Prefix
        backend:
          service:
            name: kubia-bar-svc
            port:
              number: 80

$ kubectl create -f pod-foo-bar.yaml
pod/kubia-foo created
pod/kubia-bar created

$ kubectl create -f service-foo-bar.yaml
service/kubia-foo-svc created
service/kubia-bar-svc created

$ kubectl create -f ingress-basic.yaml
ingress.networking.k8s.io/kubia created

$ kubectl get svc
NAME            TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
kubernetes      ClusterIP   10.96.0.1       <none>        443/TCP   22d
kubia-bar-svc   ClusterIP   10.96.230.115   <none>        80/TCP    4m12s
kubia-foo-svc   ClusterIP   10.96.49.21     <none>        80/TCP    4m13s

$ kubectl get ingress
NAME    CLASS    HOSTS   ADDRESS     PORTS   AGE
kubia   <none>   *       localhost   80      67s

$ kubectl -n ingress-nginx get svc
NAME                                 TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)                      AGE
ingress-nginx-controller             LoadBalancer   10.96.146.11   172.18.0.6    80:30367/TCP,443:31847/TCP   63m
ingress-nginx-controller-admission   ClusterIP      10.96.50.204   <none>        443/TCP                      63m

$ kubectl get services \
>    --namespace ingress-nginx \
>    ingress-nginx-controller \
>    --output jsonpath='{.status.loadBalancer.ingress[0].ip}'
172.18.0.6

$ curl -s http://172.18.0.6:80/foo
You've hit kubia-foo

$ curl -s http://172.18.0.6:80/bar
You've hit kubia-bar

$ curl -s http://172.18.0.6:80/baz
<html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx</center>
</body>
</html>

In order to use ingress address localhost (curl http://localhost/foo) you should define extraPortMapping in kind cluster configuration as described in Extra Port Mappings.

$ kubectl delete ingress/kubia
ingress.networking.k8s.io "kubia" deleted

Using a host

# ingress-hosts.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: kubia
spec:
  rules:
  - host: foo.kubia.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: kubia-foo-svc
            port:
              number: 80
  - host: bar.kubia.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: kubia-bar-svc
            port:
              number: 80

$ kubectl create -f ingress-hosts.yaml
ingress.networking.k8s.io/kubia created

$ kubectl get ingress/kubia
NAME    CLASS    HOSTS                         ADDRESS     PORTS   AGE
kubia   <none>   foo.kubia.com,bar.kubia.com   localhost   80      103s

$ curl -s http://172.18.0.6
<html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx</center>
</body>
</html>

$ curl -s http://172.18.0.6 -H 'Host: foo.kubia.com'
You've hit kubia-foo                               '

$ curl -s http://172.18.0.6 -H 'Host: bar.kubia.com'
You've hit kubia-bar

$ kubectl delete ingress/kubia
ingress.networking.k8s.io "kubia" deleted

TLS

You can secure an Ingress by specifying a Secret that contains a TLS private key and certificate.

$ openssl genrsa -out tls.key 2048
Generating RSA private key, 2048 bit long modulus (2 primes)
............................................+++++
............+++++
e is 65537 (0x010001)

$ openssl req -new -x509 -key tls.key -out tls.crt -days 360 -subj //CN=foo.kubia.com

$ kubectl create secret tls tls-secret --cert=tls.crt --key=tls.key
secret/tls-secret created

# ingress-tls.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: kubia
spec:
  tls:
  - hosts:
      - foo.kubia.com
    secretName: tls-secret
  rules:
  - host: foo.kubia.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: kubia-foo-svc
            port:
              number: 80

$ kubectl create -f ingress-tls.yaml
ingress.networking.k8s.io/kubia created

$ kubectl get ingress/kubia
NAME    CLASS    HOSTS           ADDRESS     PORTS     AGE
kubia   <none>   foo.kubia.com   localhost   80, 443   2m13s

$ curl -sk https://172.18.0.6:443 -H 'Host: foo.kubia.com'
You've hit kubia-foo

$ kubectl delete ingress/kubia
ingress.networking.k8s.io "kubia" deleted

$ kubectl delete secret/tls-secret
secret "tls-secret" deleted

$ kubectl delete -f pod-foo-bar.yaml
pod "kubia-foo" deleted
pod "kubia-bar" deleted

$ kubectl delete -f service-foo-bar.yaml
service "kubia-foo-svc" deleted
service "kubia-bar-svc" deleted

Probes

A probe is a diagnostic performed periodically by the kubelet on a container. To perform a diagnostic, the kubelet either executes code within the container, or makes a network request.

livenessProbe

Indicates whether the container is running. If the liveness probe fails, the kubelet kills the container

# pod-liveness-probe.yaml

apiVersion: v1
kind: Pod
metadata:
  name: kubia-liveness
spec:
  containers:
  - image: luksa/kubia-unhealthy
    name: kubia
    livenessProbe:
      httpGet:
        path: /
        port: 8080

$ kubectl create -f pod-liveness-probe.yaml
pod/kubia-liveness created

$ kubectl get po
NAME             READY   STATUS    RESTARTS   AGE
kubia-liveness   1/1     Running   0          42s

$ kubectl events pod/kubia-liveness
LAST SEEN          TYPE      REASON      OBJECT               MESSAGE
113s               Normal    Scheduled   Pod/kubia-liveness   Successfully assigned default/kubia-liveness to kind-worker3
112s               Normal    Pulling     Pod/kubia-liveness   Pulling image "luksa/kubia-unhealthy"
77s                Normal    Pulled      Pod/kubia-liveness   Successfully pulled image "luksa/kubia-unhealthy" in 34.865s (34.865s including waiting). Image size: 263841919 bytes.
77s                Normal    Created     Pod/kubia-liveness   Created container: kubia
77s                Normal    Started     Pod/kubia-liveness   Started container kubia
2s (x3 over 22s)   Warning   Unhealthy   Pod/kubia-liveness   Liveness probe failed: HTTP probe failed with statuscode: 500
2s                 Normal    Killing     Pod/kubia-liveness   Container kubia failed liveness probe, will be restarted

$ kubectl get po
NAME             READY   STATUS    RESTARTS      AGE
kubia-liveness   1/1     Running   1 (20s ago)   2m41s

readinessProbe

Indicates whether the container is ready to respond to requests. If the readiness probe fails, the EndpointSlice controller removes the Pod's IP address from the EndpointSlices of all Services that match the Pod

# pod-readiness-probe.yaml

apiVersion: v1
kind: Pod
metadata:
  name: kubia-readiness
  labels:
    app: kubia
spec:
  containers:
  - image: luksa/kubia
    name: kubia
    readinessProbe:
      exec:
        command:
        - cat
        - /tmp/ready
      initialDelaySeconds: 10
      periodSeconds: 5
    ports:
    - containerPort: 8080
      name: http-web

# service-readiness-probe.yaml

apiVersion: v1
kind: Service
metadata:
  name: kubia-svc
spec:
  type: LoadBalancer
  selector:
    app: kubia
  ports:
  - port: 80
    targetPort: http-web

$ kubectl create -f pod-readiness-probe.yaml
pod/kubia-readiness created

$ kubectl create -f service-readiness-probe.yaml
service/kubia-svc created

$ kubectl get po
NAME              READY   STATUS    RESTARTS   AGE
kubia-readiness   0/1     Running   0          23s

$ kubectl get svc
NAME         TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE
kubernetes   ClusterIP      10.96.0.1      <none>        443/TCP        23d
kubia-svc    LoadBalancer   10.96.150.51   172.18.0.7    80:31868/TCP   33s

$ kubectl exec kubia-readiness -- curl -s http://localhost:8080
You've hit kubia-readiness'

$ kubectl exec kubia-readiness -- curl -s http://kubia-svc:80
command terminated with exit code 7

$ curl -sv http://172.18.0.7:80
*   Trying 172.18.0.7:80...
* Connected to 172.18.0.7 (172.18.0.7) port 80 (#0)
> GET / HTTP/1.1
> Host: 172.18.0.7
> User-Agent: curl/7.79.1
> Accept: */*
>
* Empty reply from server
* Closing connection 0

$ kubectl exec kubia-readiness -- touch tmp/ready

$ kubectl get po
NAME              READY   STATUS    RESTARTS   AGE
kubia-readiness   1/1     Running   0          2m38s

$ kubectl exec kubia-readiness -- curl -s http://kubia-svc:80
You've hit kubia-readiness

$ curl -s http://172.18.0.7:80
You've hit kubia-readiness

$ kubectl delete -f pod-readiness-probe.yaml
pod "kubia-readiness" deleted

$ kubectl delete -f service-readiness-probe.yaml
service "kubia-svc" deleted

startupProbe

Indicates whether the application within the container is started. All other probes are disabled if a startup probe is provided, until it succeeds. If the startup probe fails, the kubelet kills the container.

ports:
- name: liveness-port
  containerPort: 8080

livenessProbe:
  httpGet:
    path: /healthz
    port: liveness-port
  failureThreshold: 1
  periodSeconds: 10

startupProbe:
  httpGet:
    path: /healthz
    port: liveness-port
  failureThreshold: 30
  periodSeconds: 10

For more information about configuring probes, see Configure Liveness, Readiness and Startup Probes

Volumes

Kubernetes volumes provide a way for containers in a pod to access and share data via the filesystem. Data sharing can be between different local processes within a container, or between different containers, or between Pods.

Kubernetes supports several types of volumes.

Ephemeral Volumes

Ephemeral volumes are temporary storage that are intrinsically linked to the lifecycle of a Pod. Ephemeral volumes are designed for scenarios where data persistence is not required beyond the life of a single Pod.

Kubernetes supports several different kinds of ephemeral volumes for different purposes: emptyDir, configmap, downwardAPI, secret, image, CSI

emptyDir

For a Pod that defines an emptyDir volume, the volume is created when the Pod is assigned to a node. The emptyDir volume is initially empty.

# pod-volume-emptydir.yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:stable
    volumeMounts:
    - mountPath: /tmp-cache
      name: tmp
  volumes:
  - name: tmp
    emptyDir: {}

$ kubectl create -f pod-volume-emptydir.yaml
pod/nginx created

$ kubectl exec nginx -- ls -l | grep cache
drwxrwxrwx   2 root root 4096 Aug 11 08:13 tmp-cache

$ kubectl delete -f pod-volume-emptydir.yaml
pod "nginx" deleted

You can create a volume in memory using using tmpfs file system:

  - name: tmp
    emptyDir:
      sizeLimit: 500Mi
      medium: Memory

Projected Volumes

A projected volume maps several existing volume sources into the same directory.

Currently, the following types of volume sources can be projected: secret, downwardAPI, configMap, serviceAccountToken, clusterTrustBundle

Persistent Volumes

Persistent volumes offer durable storage, meaning the data stored within them persists even after the associated Pods are deleted, restarted, or rescheduled.

PersistentVolume

A PersistentVolume (PV) is a piece of storage in the cluster that has been provisioned by an administrator or dynamically provisioned using Storage Classes.

PersistentVolume types are implemented as plugins. Kubernetes currently supports the following plugins: csi, fc, iscsi, local, nfs, hostPath

hostPath

A hostPath volume mounts a file or directory from the host node's filesystem into your Pod.

# pod-volume-hostpath.yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:stable
    volumeMounts:
    - mountPath: /cache
      name: cache
  volumes:
  - name: cache
    hostPath:
      path: /data/cache
      type: DirectoryOrCreate

$ kubectl create -f pod-volume-hostpath.yaml
pod/nginx created

$ kubectl exec nginx -- ls -l | grep cache
drwxr-xr-x   2 root root 4096 Aug 11 12:27 cache

$ kubectl delete -f pod-volume-hostpath.yaml
pod "nginx" deleted

# pv-hostpath.yaml

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-redis
spec:
  capacity: 
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
    - ReadOnlyMany
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: /data/redis

$ kubectl create -f pv-hostpath.yaml
persistentvolume/pv-redis created

$ kubectl get pv
NAME         CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   VOLUMEATTRIBUTESCLASS   REASON   AGE
pv-redis   1Gi        RWO,ROX        Retain           Available                          <unset>                          44s

PersistentVolumeClaim

A PersistentVolumeClaim (PVC) is a request for storage by a user. A PersistentVolumeClaim volume is used to mount a PersistentVolume into a Pod.

# pvc-basic.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-redis
spec:
  resources:
    requests:
      storage: 0.5Gi
  accessModes:
  - ReadWriteOnce
  storageClassName: ""

$ kubectl create -f pvc-basic.yaml
persistentvolumeclaim/pvc-redis created

$ kubectl get pvc
NAME        STATUS   VOLUME     CAPACITY   ACCESS MODES   STORAGECLASS   VOLUMEATTRIBUTESCLASS   AGE
pvc-redis   Bound    pv-redis   1Gi        RWO,ROX                       <unset>                 6s

$ kubectl get pv
NAME       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM               STORAGECLASS   VOLUMEATTRIBUTESCLASS   REASON   AGE
pv-redis   1Gi        RWO,ROX        Retain           Bound    default/pvc-redis                  <unset>                          28s

# pod-pvc.yaml

apiVersion: v1
kind: Pod
metadata:
  name: redis 
spec:
  containers:
  - name: redis
    image: redis:6.2
    volumeMounts:
    - name: redis-rdb
      mountPath: /data
  volumes:
  - name: redis-rdb
    persistentVolumeClaim:
      claimName: pvc-redis

$ kubectl create -f pod-pvc.yaml
pod/redis created

$ kubectl get po redis -o jsonpath='{.spec.volumes[?(@.name == "redis-rdb")]}'
{"name":"redis-rdb","persistentVolumeClaim":{"claimName":"pvc-redis"}}

$ kubectl exec redis -- redis-cli save
OK

$ kubectl get po redis -o jsonpath='{.spec.nodeName}'
kind-worker2

$ docker exec kind-worker2 ls -l tmp/redis
total 4
-rw------- 1 999 systemd-journal 102 Aug 11 14:47 dump.rdb

$ kubectl delete po/redis
pod "redis" deleted

$ kubectl delete pvc/pvc-redis
persistentvolumeclaim "pvc-redis" deleted

$ kubectl get pvc
No resources found in default namespace.

$ kubectl get pv
NAME       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS     CLAIM               STORAGECLASS   VOLUMEATTRIBUTESCLASS   REASON   AGE
pv-redis   1Gi        RWO,ROX        Retain           Released   default/pvc-redis                  <unset>                          37m

$ kubectl create -f pvc-basic.yaml
persistentvolumeclaim/pvc-redis created

$ kubectl get pvc
NAME        STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   VOLUMEATTRIBUTESCLASS   AGE
pvc-redis   Pending                                                     <unset>                 9s

$ kubectl get pv
NAME       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS     CLAIM               STORAGECLASS   VOLUMEATTRIBUTESCLASS   REASON   AGE
pv-redis   1Gi        RWO,ROX        Retain           Released   default/pvc-redis                  <unset>                          40m

$ kubectl create -f pod-pvc.yaml
pod/redis created

$ kubectl get po
NAME    READY   STATUS    RESTARTS   AGE
redis   0/1     Pending   0          92s

$ kubectl events pod/redis
LAST SEEN             TYPE      REASON             OBJECT                            MESSAGE
37m                   Normal    Scheduled          Pod/redis                         Successfully assigned default/redis to kind-worker2
37m                   Normal    Pulling            Pod/redis                         Pulling image "redis:6.2"
37m                   Normal    Pulled             Pod/redis                         Successfully pulled image "redis:6.2" in 5.993s (5.993s including waiting). Image size: 40179474 bytes.
37m                   Normal    Created            Pod/redis                         Created container: redis
37m                   Normal    Started            Pod/redis                         Started container redis
6m57s                 Normal    Killing            Pod/redis                         Stopping container redis
2m4s                  Warning   FailedScheduling   Pod/redis                         0/4 nodes are available: pod has unbound immediate PersistentVolumeClaims. preemption: 0/4 nodes are available: 4 Preemption is not helpful for scheduling.
8s (x16 over 3m51s)   Normal    FailedBinding      PersistentVolumeClaim/pvc-redis   no persistent volumes available for this claim and no storage class is set

$ kubectl delete pv/pv-redis
persistentvolume "pv-redis" deleted

$ kubectl get pvc
NAME        STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   VOLUMEATTRIBUTESCLASS   AGE
pvc-redis   Pending                                                     <unset>                 61s

$ kubectl create -f pv-hostpath.yaml
persistentvolume/pv-redis created

$ kubectl get pvc
NAME        STATUS   VOLUME     CAPACITY   ACCESS MODES   STORAGECLASS   VOLUMEATTRIBUTESCLASS   AGE
pvc-redis   Bound    pv-redis   1Gi        RWO,ROX                       <unset>                 2m2s

$ kubectl delete pod/redis
pod "redis" deleted

$ kubectl delete pvc/pvc-redis
persistentvolumeclaim "pvc-redis" deleted

$ kubectl delete pv/pv-redis
persistentvolume "pv-redis" deleted

Dynamic Volume Provisioning

Dynamic volume provisioning allows storage volumes to be created on-demand. Without dynamic provisioning, cluster administrators have to manually make calls to their cloud or storage provider to create new storage volumes, and then create PersistentVolume objects to represent them in Kubernetes.

StorageClass

A StorageClass provides a way for administrators to describe the classes of storage they offer.

$ kubectl get storageclass
NAME                 PROVISIONER             RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
standard (default)   rancher.io/local-path   Delete          WaitForFirstConsumer   false                  25d

# storageclass-local-path.yaml

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: storageclass-redis
  annotations:
    storageclass.kubernetes.io/is-default-class: "false"
provisioner: rancher.io/local-path
volumeBindingMode: Immediate

$ kubectl create -f storageclass-local-path.yaml
storageclass.storage.k8s.io/storageclass-redis created

$ kubectl get sc
NAME                 PROVISIONER             RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
standard (default)   rancher.io/local-path   Delete          WaitForFirstConsumer   false                  26d
storageclass-redis   rancher.io/local-path   Delete          Immediate              false                  5m43s                 26s

# pvc-sc.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-dynamic-redis
  annotations:
    volume.kubernetes.io/selected-node: kind-worker
spec:
  resources:
    requests:
      storage: 0.5Gi
  accessModes:
  - ReadWriteOnce
  storageClassName: storageclass-redis

$ kubectl create -f pvc-sc.yaml
persistentvolumeclaim/pvc-dynamic-redis created

$ kubectl get pvc
NAME                STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS         VOLUMEATTRIBUTESCLASS   AGE
pvc-dynamic-redis   Pending                                      storageclass-redis   <unset>                 8s

$ kubectl get pvc
NAME                STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS         VOLUMEATTRIBUTESCLASS   AGE
pvc-dynamic-redis   Bound    pvc-0d78a617-e1ee-4d1e-8e59-37502fc711a9   512Mi      RWO            storageclass-redis   <unset>                 26s
                         0s
$ kubectl get pv
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                       STORAGECLASS         VOLUMEATTRIBUTESCLASS   REASON   AGE
pvc-0d78a617-e1ee-4d1e-8e59-37502fc711a9   512Mi      RWO            Delete           Bound    default/pvc-dynamic-redis   storageclass-redis   <unset>                          47s

$ kubectl delete sc/st
sc/standard            sc/storageclass-redis

$ kubectl delete sc/storageclass-redis
storageclass.storage.k8s.io "storageclass-redis" deleted

$ kubectl get pv
No resources found

ConfigMaps

A ConfigMap is an API object used to store non-confidential data in key-value pairs. Pods can consume ConfigMaps as environment variables, command-line arguments, or as configuration files in a volume.

Creating ConfigMaps

Imperative way

# application.properties
server.port=8080
spring.profiles.active=development

$ kubectl create configmap my-config \
    --from-literal=foo=bar \
    --from-file=app.props=application.properties
configmap/my-config created

$ kubectl get cm/my-config
NAME        DATA   AGE
my-config   2      61s

$ kubectl get cm/my-config -o yaml
apiVersion: v1
data:
  app.props: |-
    # application.properties
    server.port=8080
    spring.profiles.active=development
  foo: bar
kind: ConfigMap
metadata:
  creationTimestamp: "2025-09-15T20:20:44Z"
  name: my-config
  namespace: default
  resourceVersion: "3636455"
  uid: 9c68ecb1-55ca-469a-b09e-3e1b625cd69b

$ kubectl delete cm my-config
configmap "my-config" deleted

Declarative way

# cm.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: my-config
data:
  app.props: |
    server.port=8080
    spring.profiles.active=development
  foo: bar

$ kubectl apply -f cm.yaml
configmap/my-config created

$ kubectl get cm/my-config
NAME        DATA   AGE
my-config   2      19s

$ kubectl get cm/my-config -o yaml
apiVersion: v1
data:
  app.props: |
    server.port=8080
    spring.profiles.active=development
  foo: bar
kind: ConfigMap
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","data":{"app.props":"server.port=8080\nspring.profiles.active=development\n","foo":"bar"},"kind":"ConfigMap","metadata":{"annotations":{},"name":"my-config","namespace":"default"}}
  creationTimestamp: "2025-09-15T20:27:51Z"
  name: my-config
  namespace: default
  resourceVersion: "3637203"
  uid: a8d9fce1-f2bd-470c-93a2-3a7fcc560bbc

Using ConfigMaps

Consuming an environment variable by a reference key

# pod-cm-env.yaml
apiVersion: v1
kind: Pod
metadata:
  name: env-configmap
spec:
  containers:
    - name: app
      command: ["printenv", "MY_VAR"]
      image: busybox:latest
      env:
        - name: MY_VAR
          valueFrom:
            configMapKeyRef:
              name: my-config
              key: foo

$ kubectl apply -f pod-cm-env.yaml
pod/env-configmap created

$ kubectl logs pod/env-configmap
bar

$ kubectl delete -f pod-cm-env.yaml
pod "env-configmap" deleted

Consuming all environment variables from the ConfigMap

# pod-cm-envfrom.yaml
apiVersion: v1
kind: Pod
metadata:
  name: env-from-configmap
spec:
  containers:
    - name: app
      command: ["printenv", "config_foo"]
      image: busybox:latest
      envFrom:
        - prefix: config_
          configMapRef:
            name: my-config

$ kubectl apply -f pod-cm-envfrom.yaml
pod/env-from-configmap created

$ kubectl logs pod/env-from-configmap
bar

$ kubectl delete -f pod-cm-envfrom.yaml
pod "env-from-configmap" deleted

Using configMap volume

# pod-cm-volumemount.yaml
apiVersion: v1
kind: Pod
metadata:
  name: configmap-volumemount
spec:
  containers:
    - name: app
      command: ["cat", "/etc/props/app.props"]
      image: busybox:latest
      volumeMounts:
        - name: app-props
          mountPath: "/etc/props"
          readOnly: true
  volumes:
  - name: app-props
    configMap:
      name: my-config

$ kubectl apply -f pod-cm-volumemount.yaml
pod/configmap-volumemount created

$ kubectl logs pod/configmap-volumemount
server.port=8080
spring.profiles.active=development

$ kubectl delete -f pod-cm-volumemount.yaml
pod "configmap-volumemount" deleted

Using configMap volume with items

# pod-cm-volume-items.yaml
apiVersion: v1
kind: Pod
metadata:
  name: configmap-volume-items
spec:
  containers:
    - name: app
      command: ["cat", "/etc/configs/app.conf"]
      image: busybox:latest
      volumeMounts:
        - name: config
          mountPath: "/etc/configs"
          readOnly: true
  volumes:
    - name: config
      configMap:
        name: my-config
        items:
          - key: foo
            path: app.conf

$ kubectl apply -f pod-cm-volume-items.yaml
pod/configmap-volume-items created

$ kubectl logs pod/configmap-volume-items
bar

$ kubectl delete -f pod-cm-volume-items.yaml
pod "configmap-volume-items" deleted

Secrets

A Secret is an object that contains a small amount of sensitive data such as a password, a token, or a key. Such information might otherwise be put in a Pod specification or in a container image. Using a Secret means that you don't need to include confidential data in your application code..

Default Secrets in a Pod

# pod-basic.yaml
apiVersion: v1
kind: Pod
metadata:
  name: kubia
spec:
  containers:
  - image: luksa/kubia
    name: kubia
    ports:
    - containerPort: 8080
      protocol: TCP

$ kubectl apply -f pod-basic.yaml
pod/kubia created

$ kubectl get po/kubia -o=jsonpath='{.spec.containers[0].volumeMounts}'
[{"mountPath":"/var/run/secrets/kubernetes.io/serviceaccount","name":"kube-api-access-jd9vq","readOnly":true}]

$ kubectl get po/kubia -o=jsonpath='{.spec.volumes[?(@.name == "kube-api-access-jd9vq")].projected.sources}'
[{"serviceAccountToken":{"expirationSeconds":3607,"path":"token"}},{"configMap":{"items":[{"key":"ca.crt","path":"ca.crt"}],"name":"kube-root-ca.crt"}},{"downwardAPI":{"items":[{"fieldRef":{"apiVersion":"v1","fieldPath":"metadata.namespace"},"path":"namespace"}]}}]

$ kubectl exec po/kubia -- ls /var/run/secrets/kubernetes.io/serviceaccount/
ca.crt
namespace
token

$ kubectl delete -f pod-basic.yaml
pod "kubia" deleted

Creating Secrets

Imperative way

Opaque Secrets

$ kubectl create secret generic empty-secret
secret/empty-secret created

$ kubectl get secret empty-secret
NAME           TYPE     DATA   AGE
empty-secret   Opaque   0      9s

$ kubectl get secret/empty-secret -o yaml
apiVersion: v1
kind: Secret
metadata:
  creationTimestamp: "2025-11-05T17:19:07Z"
  name: empty-secret
  namespace: default
  resourceVersion: "6290557"
  uid: 031d7f8d-e96d-4e03-a90f-2cb96308354b
type: Opaque

$ kubectl delete secret/empty-secret
secret "empty-secret" deleted

$ openssl genrsa -out tls.key
Generating RSA private key, 2048 bit long modulus (2 primes)
...............................................................+++++
.................................+++++
e is 65537 (0x010001)

$ openssl req -new -x509 -key tls.key -out tls.crt -subj /CN=kubia.com

$ kubectl create secret generic kubia-secret --from-file=tls.key --from-file=tls.crt
secret/kubia-secret created

$ kubectl get secret/kubia-secret -o yaml
apiVersion: v1
data:
  tls.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tDQpNSUlEQ1RDQ0FmR2dBd0lCQWdJVUxxWEJaRn...LS1FTkQgQ0VSVElGSUNBVEUtLS0tLQ0K
  tls.key: LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQ0KTUlJRXBBSUJBQUtDQVFFQXR4UlRYMD...U2VQK3N3PT0NCi0tLS0tRU5EIFJTQSBQUklWQVRFIEtFWS0tLS0tDQo=
kind: Secret
metadata:
  creationTimestamp: "2025-11-05T17:26:21Z"
  name: kubia-secret
  namespace: default
  resourceVersion: "6291327"
  uid: a06d4be4-3e21-47ea-8009-d300c1c449f9
type: Opaque

$ kubectl delete secret/kubia-secret
secret "kubia-secret" deleted

$ kubectl create secret generic test-secret --from-literal='username=admin' --from-literal='password=39528$vdg7Jb'
secret/test-secret created

$ kubectl get secret/test-secret -o yaml
apiVersion: v1
data:
  password: Mzk1MjgkdmRnN0pi
  username: YWRtaW4=
kind: Secret
metadata:
  creationTimestamp: "2025-11-05T18:21:28Z"
  name: test-secret
  namespace: default
  resourceVersion: "6297117"
  uid: 215daac1-7305-43f4-91c6-c7dbdeca2802
type: Opaque

$ kubectl delete secret/test-secret
secret "test-secret" deleted

TLS Secrets

$ kubectl create secret tls my-tls-secret --key=tls.key --cert=tls.crt
secret/my-tls-secret created

$ kubectl get secret/my-tls-secret -o yaml
apiVersion: v1
data:
  tls.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tDQpNSUlEQ1RDQ0FmR2dBd0lCQWdJVUxxWEJaRn...LS1FTkQgQ0VSVElGSUNBVEUtLS0tLQ0K
  tls.key: LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQ0KTUlJRXBBSUJBQUtDQVFFQXR4UlRYMD...U2VQK3N3PT0NCi0tLS0tRU5EIFJTQSBQUklWQVRFIEtFWS0tLS0tDQo=
kind: Secret
metadata:
  creationTimestamp: "2025-11-05T17:37:45Z"
  name: my-tls-secret
  namespace: default
  resourceVersion: "6292515"
  uid: f15b375e-2404-4ca0-a08f-014a0efeec70
type: kubernetes.io/tls

$ kubectl delete secret/my-tls-secret
secret "my-tls-secret" deleted

Docker config Secrets

$ kubectl create secret docker-registry my-docker-registry-secret --docker-username=robert --docker-password=passw123 --docker-server=nexus.registry.com:5000
secret/my-docker-registry-secret created

$ kubectl get secret/my-docker-registry-secret -o yaml
apiVersion: v1
data:
  .dockerconfigjson: eyJhdXRocyI6eyJuZXh1cy5yZWdpc3RyeS5jb206NTAwMCI6eyJ1c2VybmFtZSI6InJvYmVydCIsInBhc3N3b3JkIjoicGFzc3cxMjMiLCJhdXRoIjoiY205aVpYSjBPbkJoYzNOM01USXoifX19
kind: Secret
metadata:
  creationTimestamp: "2025-11-05T17:44:10Z"
  name: my-docker-registry-secret
  namespace: default
  resourceVersion: "6293203"
  uid: c9d05ef7-8c8c-4e2b-bf6f-27f80a45d545
type: kubernetes.io/dockerconfigjson

$ kubectl delete secret/my-docker-registry-secret
secret "my-docker-registry-secret" deleted

Declarative way

Opaque Secrets

$ echo -n 'my-app' | base64
bXktYXBw

$ echo -n '39528$vdg7Jb' | base64
Mzk1MjgkdmRnN0pi

# opaque-secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: opaque-secret
data:
  username: bXktYXBw
  password: Mzk1MjgkdmRnN0pi

$ kubectl apply -f opaque-secret.yaml
secret/opaque-secret created

$ kubectl get secrets
NAME          TYPE     DATA   AGE
opaque-secret   Opaque   2      4s

$ kubectl delete -f opaque-secret.yaml
secret "opaque-secret" deleted

Docker config Secrets

# dockercfg-secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: secret-dockercfg
type: kubernetes.io/dockercfg
data:
  .dockercfg: |
    eyJhdXRocyI6eyJodHRwczovL2V4YW1wbGUvdjEvIjp7ImF1dGgiOiJvcGVuc2VzYW1lIn19fQo=

$ kubectl apply -f dockercfg-secret.yaml
secret/secret-dockercfg created

$ kubectl get secrets
NAME               TYPE                      DATA   AGE
secret-dockercfg   kubernetes.io/dockercfg   1      3s

$ kubectl describe secret/secret-dockercfg
Name:         secret-dockercfg
Namespace:    default
Labels:       <none>
Annotations:  <none>

Type:  kubernetes.io/dockercfg

Data
====
.dockercfg:  56 bytes

$ kubectl delete -f dockercfg-secret.yaml
secret "secret-dockercfg" deleted

Basic authentication Secret

# basicauth-secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: secret-basic-auth
type: kubernetes.io/basic-auth
stringData:
  username: admin
  password: pass1234

$ kubectl apply -f basicauth-secret.yaml
secret/secret-basic-auth created

$ kubectl get secrets
NAME                TYPE                       DATA   AGE
secret-basic-auth   kubernetes.io/basic-auth   2      3s

$ kubectl describe secret/secret-basic-auth
Name:         secret-basic-auth
Namespace:    default
Labels:       <none>
Annotations:  <none>

Type:  kubernetes.io/basic-auth

Data
====
password:  8 bytes
username:  5 bytes

$ kubectl delete -f basicauth-secret.yaml
secret "secret-basic-auth" deleted

Using Secrets

Secrets can be mounted as data volumes or exposed as environment variables to be used by a container in a Pod.

$ kubectl create secret generic test-secret --from-literal='username=admin' --from-literal='password=39528$vdg7Jb'
secret/test-secret created

$ kubectl describe secret test-secre
Name:         test-secret
Namespace:    default
Labels:       <none>
Annotations:  <none>

Type:  Opaque

Data
====
password:  12 bytes
username:  5 bytes

Using Secrets as files from a Pod

# pod-secret-volumemount.yaml
apiVersion: v1
kind: Pod
metadata:
  name: secret-test-pod
spec:
  containers:
    - name: test-container
      image: nginx
      volumeMounts:
        - name: secret-volume
          mountPath: /etc/secret-volume
          readOnly: true
  volumes:
    - name: secret-volume
      secret:
        secretName: test-secret

$ kubectl apply -f pod-secret-volumemount.yaml
pod/secret-test-pod created

$ kubectl get pod secret-test-pod
NAME              READY   STATUS    RESTARTS   AGE
secret-test-pod   1/1     Running   0          30s

$ kubectl exec secret-test-pod -- ls /etc/secret-volume
password
username

$ kubectl exec secret-test-pod -- head /etc/secret-volume/{username,password}
==> /etc/secret-volume/username <==
admin
==> /etc/secret-volume/password <==
39528$vdg7Jb

$ kubectl delete -f pod-secret-volumemount.yaml
pod "secret-test-pod" deleted

Project Secret keys to specific file paths

# pod-secret-volume-items.yaml
apiVersion: v1
kind: Pod
metadata:
  name: secret-test-pod
spec:
  containers:
    - name: test-container
      image: nginx
      volumeMounts:
        - name: secret-volume
          mountPath: /etc/secret-volume
          readOnly: true
  volumes:
    - name: secret-volume
      secret:
        secretName: test-secret
        items:
          - key: username
            path: my-group/my-username

$ kubectl apply -f pod-secret-volume-items.yaml
pod/secret-test-pod created

$ kubectl exec secret-test-pod -- ls /etc/secret-volume
my-group

$ kubectl exec secret-test-pod -- ls /etc/secret-volume/my-group
my-username

$ kubectl exec secret-test-pod -- head /etc/secret-volume/my-group/my-username
admin

$ kubectl delete -f pod-secret-volume-items.yaml
pod "secret-test-pod" deleted

Using Secrets as environment variables

Define a container environment variable with data from a single Secret

# pod-secret-env-var.yaml
apiVersion: v1
kind: Pod
metadata:
  name: secret-test-pod
spec:
  containers:
    - name: test-container
      image: nginx
      env:
      - name: SECRET_PASSWORD
        valueFrom:
          secretKeyRef:
            name: test-secret
            key: password

$ kubectl apply -f pod-secret-env-var.yaml
pod/secret-test-pod created

$ kubectl exec secret-test-pod -- /bin/sh -c 'echo $SECRET_PASSWORD'
39528$vdg7Jb

$ kubectl delete -f pod-secret-env-var.yaml
pod "secret-test-pod" deleted

Define all of the Secret's data as container environment variables

# pod-secret-envfrom.yaml
apiVersion: v1
kind: Pod
metadata:
  name: secret-test-pod
spec:
  containers:
    - name: test-container
      image: nginx
      envFrom:
      - secretRef:
          name: test-secret

$ kubectl apply -f pod-secret-envfrom.yaml
pod/secret-test-pod created

$ kubectl exec secret-test-pod -- /bin/sh -c 'echo "username: $username\npassword: $password\n"'
username: admin
password: 39528$vdg7Jb

$ kubectl delete -f pod-secret-envfrom.yaml
pod "secret-test-pod" deleted

$ kubectl delete secrets test-secret
secret "test-secret" deleted

Deployments

A Deployment is a high-level resource used to manage and scale applications while ensuring they remain in the desired state. It provides a declarative way to define how many Pods should run, which container images they should use, and how updates should be applied.

Creating Deployments

Imperative way

$ kubectl create deployment my-nginx-deployment --image=nginx --replicas=3 --port=80
deployment.apps/my-nginx-deployment created

$ kubectl get deploy
NAME                  READY   UP-TO-DATE   AVAILABLE   AGE
my-nginx-deployment   3/3     3            3           20s

$ kubectl rollout status deployment/my-nginx-deployment
deployment "my-nginx-deployment" successfully rolled out

$ kubectl get rs
NAME                             DESIRED   CURRENT   READY   AGE
my-nginx-deployment-677c645895   3         3         3       2m30s

$ kubectl get po
NAME                                   READY   STATUS    RESTARTS   AGE
my-nginx-deployment-677c645895-d4c9q   1/1     Running   0          2m58s
my-nginx-deployment-677c645895-jdvtf   1/1     Running   0          2m58s
my-nginx-deployment-677c645895-mkjsc   1/1     Running   0          2m58s

$ kubectl port-forward deployments/my-nginx-deployment 80
Forwarding from 127.0.0.1:80 -> 80
Forwarding from [::1]:80 -> 80

$ curl -sI localhost:80
HTTP/1.1 200 OK
Server: nginx/1.29.3

$ kubectl set image deployment/my-nginx-deployment nginx=nginx:1.16.1
deployment.apps/my-nginx-deployment image updated

$ kubectl rollout status deployment/my-nginx-deployment
Waiting for deployment "my-nginx-deployment" rollout to finish: 1 out of 3 new replicas have been updated...
Waiting for deployment "my-nginx-deployment" rollout to finish: 1 out of 3 new replicas have been updated...
Waiting for deployment "my-nginx-deployment" rollout to finish: 2 out of 3 new replicas have been updated...
Waiting for deployment "my-nginx-deployment" rollout to finish: 2 out of 3 new replicas have been updated...
Waiting for deployment "my-nginx-deployment" rollout to finish: 2 out of 3 new replicas have been updated...
Waiting for deployment "my-nginx-deployment" rollout to finish: 2 out of 3 new replicas have been updated...
Waiting for deployment "my-nginx-deployment" rollout to finish: 1 old replicas are pending termination...
Waiting for deployment "my-nginx-deployment" rollout to finish: 1 old replicas are pending termination...
deployment "my-nginx-deployment" successfully rolled out

$ kubectl get deploy
NAME                  READY   UP-TO-DATE   AVAILABLE   AGE
my-nginx-deployment   3/3     3            3           5m13s

$ kubectl get rs
NAME                             DESIRED   CURRENT   READY   AGE
my-nginx-deployment-677c645895   0         0         0       5m31s
my-nginx-deployment-68b8b6c496   3         3         3       101s

$ kubectl get po
NAME                                   READY   STATUS    RESTARTS   AGE
my-nginx-deployment-68b8b6c496-6p9jg   1/1     Running   0          118s
my-nginx-deployment-68b8b6c496-mfcnj   1/1     Running   0          2m2s
my-nginx-deployment-68b8b6c496-ngm4b   1/1     Running   0          2m

$ kubectl get po/my-nginx-deployment-68b8b6c496-6p9jg -o jsonpath='{.spec.containers[0].image}'
nginx:1.16.1

$ kubectl rollout history deployment/my-nginx-deployment
deployment.apps/my-nginx-deployment
REVISION  CHANGE-CAUSE
1         <none>
2         <none>

$ kubectl rollout history deployment/my-nginx-deployment --revision=2
deployment.apps/my-nginx-deployment with revision #2
Pod Template:
  Labels:       app=my-nginx-deployment
        pod-template-hash=68b8b6c496
  Containers:
   nginx:
    Image:      nginx:1.16.1
    Port:       80/TCP
    Host Port:  0/TCP
    Environment:        <none>
    Mounts:     <none>
  Volumes:      <none>
  Node-Selectors:       <none>
  Tolerations:  <none>

$ kubectl rollout undo deployment/my-nginx-deployment --to-revision=1
deployment.apps/my-nginx-deployment rolled back

$ kubectl rollout history deployment/my-nginx-deployment
deployment.apps/my-nginx-deployment
REVISION  CHANGE-CAUSE
2         <none>
3         <none>

$ kubectl get rs
NAME                             DESIRED   CURRENT   READY   AGE
my-nginx-deployment-677c645895   3         3         3       11m
my-nginx-deployment-68b8b6c496   0         0         0       7m11s

$ kubectl get po
NAME                                   READY   STATUS    RESTARTS   AGE
my-nginx-deployment-677c645895-cr2vd   1/1     Running   0          71s
my-nginx-deployment-677c645895-cxbpn   1/1     Running   0          73s
my-nginx-deployment-677c645895-l67cc   1/1     Running   0          68s

$ kubectl get po/my-nginx-deployment-677c645895-cr2vd -o jsonpath='{.spec.containers[0].image}'
nginx

$ kubectl scale deployment/my-nginx-deployment --replicas=5
deployment.apps/my-nginx-deployment scaled

$ kubectl get deploy
NAME                  READY   UP-TO-DATE   AVAILABLE   AGE
my-nginx-deployment   5/5     5            5           14m

$ kubectl get rs
NAME                             DESIRED   CURRENT   READY   AGE
my-nginx-deployment-677c645895   5         5         5       14m
my-nginx-deployment-68b8b6c496   0         0         0       10m

$ kubectl get po
NAME                                   READY   STATUS    RESTARTS   AGE
my-nginx-deployment-677c645895-9zrmk   1/1     Running   0          21s
my-nginx-deployment-677c645895-cr2vd   1/1     Running   0          4m34s
my-nginx-deployment-677c645895-cxbpn   1/1     Running   0          4m36s
my-nginx-deployment-677c645895-l67cc   1/1     Running   0          4m31s
my-nginx-deployment-677c645895-qk4b5   1/1     Running   0          21s

$ kubectl rollout pause deployment/my-nginx-deployment
deployment.apps/my-nginx-deployment paused

$ kubectl get po
NAME                                   READY   STATUS    RESTARTS   AGE
my-nginx-deployment-677c645895-9zrmk   1/1     Running   0          3m14s
my-nginx-deployment-677c645895-cr2vd   1/1     Running   0          7m27s
my-nginx-deployment-677c645895-cxbpn   1/1     Running   0          7m29s
my-nginx-deployment-677c645895-l67cc   1/1     Running   0          7m24s
my-nginx-deployment-677c645895-qk4b5   1/1     Running   0          3m14s

$ kubectl scale deployment/my-nginx-deployment --replicas=3
deployment.apps/my-nginx-deployment scaled

$ kubectl get po
NAME                                   READY   STATUS    RESTARTS   AGE
my-nginx-deployment-677c645895-cr2vd   1/1     Running   0          8m28s
my-nginx-deployment-677c645895-cxbpn   1/1     Running   0          8m30s
my-nginx-deployment-677c645895-l67cc   1/1     Running   0          8m25s

$ kubectl set image deployment/my-nginx-deployment nginx=nginx:1.17.2
deployment.apps/my-nginx-deployment image updated

$ kubectl get po
NAME                                   READY   STATUS    RESTARTS   AGE
my-nginx-deployment-677c645895-cr2vd   1/1     Running   0          8m43s
my-nginx-deployment-677c645895-cxbpn   1/1     Running   0          8m35s
my-nginx-deployment-677c645895-l67cc   1/1     Running   0          8m30s

$ kubectl rollout resume deployment/my-nginx-deployment
deployment.apps/my-nginx-deployment resumed

$ kubectl get po
NAME                                   READY   STATUS    RESTARTS   AGE
my-nginx-deployment-75c7c977bb-hwx6r   1/1     Running   0          32s
my-nginx-deployment-75c7c977bb-qlfhc   1/1     Running   0          19s
my-nginx-deployment-75c7c977bb-z7l59   1/1     Running   0          43s

$ kubectl get po/my-nginx-deployment-75c7c977bb-hwx6r -o jsonpath='{.spec.containers[0].image}'
nginx:1.17.2

$ kubectl delete deploy/my-nginx-deployment
deployment.apps "my-nginx-deployment" deleted

$ kubectl get deploy
No resources found in default namespace.

$ kubectl get rs
No resources found in default namespace.

$ kubectl get po
No resources found in default namespace.

Declarative way

# deployment-basic.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx-deployment
  labels:
    app: nginx-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

$ kubectl apply -f deployment-basic.yaml
deployment.apps/my-nginx-deployment created

$ kubectl get deploy
NAME                  READY   UP-TO-DATE   AVAILABLE   AGE
my-nginx-deployment   3/3     3            3           10s

$ kubectl rollout status deployment/my-nginx-deployment
deployment "my-nginx-deployment" successfully rolled out

$ kubectl rollout status deployment/my-nginx-deployment
deployment "my-nginx-deployment" successfully rolled out

$ kubectl get rs
NAME                           DESIRED   CURRENT   READY   AGE
my-nginx-deployment-96b9d695   3         3         3       31s

$ kubectl get po
NAME                                 READY   STATUS    RESTARTS   AGE
my-nginx-deployment-96b9d695-7hgx5   1/1     Running   0          33s
my-nginx-deployment-96b9d695-nvb6h   1/1     Running   0          33s
my-nginx-deployment-96b9d695-r5t55   1/1     Running   0          33s

$ kubectl delete -f deployment-basic.yaml
deployment.apps "my-nginx-deployment" deleted

apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx-conf
data:
  nginx.conf: |
    user nginx;
    worker_processes  1;
    events {
      worker_connections  10240;
    }
    http {
      server {
        listen 80;
        server_name  _;
        location ~ ^/(healthz|readyz)$ {
            add_header Content-Type text/plain;
            return 200 'OK';
        }
      }
    }
---
# deployment-probes.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx-deployment
  labels:
    app: my-nginx
spec:
  progressDeadlineSeconds: 600      # Wait for a deployment to make progress before marking it as stalled
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app-container
        image: nginx:latest
        ports:
        - containerPort: 80
        livenessProbe:
          httpGet:
            path: /healthz          # Endpoint for liveness checks
            port: 80
          initialDelaySeconds: 15   # Wait 15 seconds before first liveness probe
          periodSeconds: 10         # Check every 10 seconds
          timeoutSeconds: 5         # Timeout after 5 seconds
          failureThreshold: 3       # Restart container after 3 consecutive failures
        readinessProbe:
          httpGet:
            path: /readyz           # Endpoint for readiness checks
            port: 80
          initialDelaySeconds: 5    # Wait 5 seconds before first readiness probe
          periodSeconds: 5          # Check every 5 seconds
          timeoutSeconds: 3         # Timeout after 3 seconds
          failureThreshold: 1       # Consider not ready after 1 failure
        volumeMounts:
        - name: nginx-conf
          mountPath: /etc/nginx/nginx.conf
          subPath: nginx.conf
          readOnly: true
      volumes:
      - name: nginx-conf
        configMap:
          name: nginx-conf
          items:
            - key: nginx.conf
              path: nginx.conf

$ kubectl apply -f deployment-probes.yaml
configmap/nginx-conf created
deployment.apps/my-nginx-deployment created

$ kubectl get deploy
NAME                  READY   UP-TO-DATE   AVAILABLE   AGE
my-nginx-deployment   3/3     3            3           12s

$ kubectl get rs
NAME                             DESIRED   CURRENT   READY   AGE
my-nginx-deployment-55bc8948d6   3         3         3       52s

$ kubectl get po
NAME                                   READY   STATUS    RESTARTS   AGE
my-nginx-deployment-55bc8948d6-4lhdd   1/1     Running   0          64s
my-nginx-deployment-55bc8948d6-mz5tx   1/1     Running   0          64s
my-nginx-deployment-55bc8948d6-nfkkx   1/1     Running   0          64s

$ kubectl delete -f deployment-probes.yaml
configmap "nginx-conf" deleted
deployment.apps "my-nginx-deployment" deleted

StatefulSet

A StatefulSet is a resource used to manage stateful applications by providing stable, unique network identifiers, persistent storage, and ordered, graceful deployment and scaling for pods. They are ideal for applications like databases that require each replica to have a predictable identity and persistent storage, unlike stateless applications managed by Deployments.

$ kubectl create -f storageclass-local-path.yaml
storageclass.storage.k8s.io/storageclass-redis created

$ kubectl get sc
NAME                 PROVISIONER             RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
standard (default)   rancher.io/local-path   Delete          WaitForFirstConsumer   false                  115d
storageclass-redis   rancher.io/local-path   Delete          Immediate              false                  43s

# statefulset.yaml

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: redis
spec:
  serviceName: redis
  replicas: 3
  selector:
    matchLabels:
      app: redis
  template:
    metadata:
      labels:
        app: redis
    spec:
      containers:
      - name: redis
        image: redis:latest
        ports:
        - containerPort: 6379
          name: redis
        volumeMounts:
        - name: data
          mountPath: /data
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 0.5Gi

$ kubectl apply -f statefulset.yaml
statefulset.apps/redis created

$ kubectl get pvc
NAME           STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   VOLUMEATTRIBUTESCLASS   AGE
data-redis-0   Bound    pvc-948cc23d-c7a8-4caf-9206-1b52c8f31f75   512Mi      RWO            standard       <unset>                 3m31s
data-redis-1   Bound    pvc-f9ff0efa-dd70-44c6-8601-72f17430f848   512Mi      RWO            standard       <unset>                 2m36s
data-redis-2   Bound    pvc-b2079d26-8db5-4855-b81b-6f1c78aeab0e   512Mi      RWO            standard       <unset>                 98s

$ kubectl get pv
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                  STORAGECLASS   VOLUMEATTRIBUTESCLASS   REASON   AGE
pvc-948cc23d-c7a8-4caf-9206-1b52c8f31f75   512Mi      RWO            Delete           Bound    default/data-redis-0   standard       <unset>                          3m52s
pvc-b2079d26-8db5-4855-b81b-6f1c78aeab0e   512Mi      RWO            Delete           Bound    default/data-redis-2   standard       <unset>                          2m
pvc-f9ff0efa-dd70-44c6-8601-72f17430f848   512Mi      RWO            Delete           Bound    default/data-redis-1   standard       <unset>                          2m57s

$ kubectl get statefulset/redis
NAME    READY   AGE
redis   3/3     4m19s

$ kubectl get po
NAME      READY   STATUS    RESTARTS   AGE
redis-0   1/1     Running   0          4m55s
redis-1   1/1     Running   0          4m
redis-2   1/1     Running   0          3m2s

$ for i in {0..2}; do kubectl exec "redis-$i" -- sh -c 'hostname'; done
redis-0
redis-1
redis-2

$ kubectl delete pod/redis-0
pod "redis-0" deleted

$ kubectl get po
NAME      READY   STATUS    RESTARTS   AGE
redis-0   1/1     Running   0          4s
redis-1   1/1     Running   0          13m
redis-2   1/1     Running   0          12m

$ kubectl scale statefulset/redis --replicas=4
statefulset.apps/redis scaled

$ kubectl get po
NAME      READY   STATUS    RESTARTS   AGE
redis-0   1/1     Running   0          2m53s
redis-1   1/1     Running   0          16m
redis-2   1/1     Running   0          15m
redis-3   0/1     Pending   0          2s

$ kubectl get po
NAME      READY   STATUS              RESTARTS   AGE
redis-0   1/1     Running             0          2m56s
redis-1   1/1     Running             0          16m
redis-2   1/1     Running             0          15m
redis-3   0/1     ContainerCreating   0          5s

$ kubectl get po
NAME      READY   STATUS              RESTARTS   AGE
redis-0   1/1     Running             0          2m58s
redis-1   1/1     Running             0          16m
redis-2   1/1     Running             0          15m
redis-3   0/1     ContainerCreating   0          7s

$ kubectl get po
NAME      READY   STATUS    RESTARTS   AGE
redis-0   1/1     Running   0          2m59s
redis-1   1/1     Running   0          16m
redis-2   1/1     Running   0          15m
redis-3   1/1     Running   0          8s

$ kubectl delete statefulset/redis
statefulset.apps "redis" deleted

$ kubectl get po
No resources found in default namespace.

$ kubectl get statefulsets
No resources found in default namespace.

$ kubectl get pv
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                  STORAGECLASS   VOLUMEATTRIBUTESCLASS   REASON   AGE
pvc-1b2cab34-7cce-4583-8cd3-3e7fce32f72c   512Mi      RWO            Delete           Bound    default/data-redis-3   standard       <unset>                          4m10s
pvc-948cc23d-c7a8-4caf-9206-1b52c8f31f75   512Mi      RWO            Delete           Bound    default/data-redis-0   standard       <unset>                          21m
pvc-b2079d26-8db5-4855-b81b-6f1c78aeab0e   512Mi      RWO            Delete           Bound    default/data-redis-2   standard       <unset>                          19m
pvc-f9ff0efa-dd70-44c6-8601-72f17430f848   512Mi      RWO            Delete           Bound    default/data-redis-1   standard       <unset>                          20m

$ kubectl get pvc
NAME           STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   VOLUMEATTRIBUTESCLASS   AGE
data-redis-0   Bound    pvc-948cc23d-c7a8-4caf-9206-1b52c8f31f75   512Mi      RWO            standard       <unset>                 22m
data-redis-1   Bound    pvc-f9ff0efa-dd70-44c6-8601-72f17430f848   512Mi      RWO            standard       <unset>                 21m
data-redis-2   Bound    pvc-b2079d26-8db5-4855-b81b-6f1c78aeab0e   512Mi      RWO            standard       <unset>                 20m
data-redis-3   Bound    pvc-1b2cab34-7cce-4583-8cd3-3e7fce32f72c   512Mi      RWO            standard       <unset>                 4m55s

$ kubectl delete sc/storageclass-redis
storageclass.storage.k8s.io "storageclass-redis" deleted

$ kubectl delete pvc data-redis-{0,1,2,3}
persistentvolumeclaim "data-redis-0" deleted
persistentvolumeclaim "data-redis-1" deleted
persistentvolumeclaim "data-redis-2" deleted
persistentvolumeclaim "data-redis-3" deleted

$ kubectl get pvc
No resources found in default namespace.

$ kubectl get pv
No resources found

ServiceAccount

A ServiceAccount provides an identity for processes and applications running within a Kubernetes cluster. ServiceAccounts are designed for non-human entities like Pods, system components, or external tools that need to interact with the Kubernetes API.

Default ServiceAccount

$ kubectl get sa
NAME      SECRETS   AGE
default   0         116d

$ kubectl apply -f pod-basic.yaml
pod/kubia created

$ kubectl get pod/kubia -o jsonpath='{.spec.serviceAccount}'
default

$ kubectl delete -f pod-basic.yaml
pod "kubia" deleted

Creating a ServiceAccount

$ kubectl create sa my-sa
serviceaccount/my-sa created

$ kubectl get sa
NAME      SECRETS   AGE
default   0         116d
my-sa     0         7s

$ kubectl get sa/my-sa -o yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  creationTimestamp: "2025-11-10T10:27:44Z"
  name: my-sa
  namespace: default
  resourceVersion: "7002078"
  uid: 487bd1fa-353a-420e-be95-6ee876a277f5

$ kubectl describe sa/my-sa
Name:                my-sa
Namespace:           default
Labels:              <none>
Annotations:         <none>
Image pull secrets:  <none>
Mountable secrets:   <none>
Tokens:              <none>
Events:              <none>

Associate a Secret with a ServiceAccount

# secret-sa-token.yaml

apiVersion: v1
kind: Secret
type: kubernetes.io/service-account-token
metadata:
  name: my-sa-token
  namespace: default
  annotations:
    kubernetes.io/service-account.name: my-sa

$ kubectl apply -f secret-sa-token.yaml
secret/my-sa-token created

$ kubectl get secrets
NAME          TYPE                                  DATA   AGE
my-sa-token   kubernetes.io/service-account-token   3      24s

$ kubectl describe secret/my-sa-token
Name:         my-sa-token
Namespace:    default
Labels:       <none>
Annotations:  kubernetes.io/service-account.name: my-sa
              kubernetes.io/service-account.uid: 487bd1fa-353a-420e-be95-6ee876a277f5

Type:  kubernetes.io/service-account-token

Data
====
ca.crt:     1107 bytes
namespace:  7 bytes
token:      eyJhbGciOiJSUzI1NiIsImtpZCI6IkxiTHE0d29pbFBiUXpXNkI1bWxoMHFQNVZCa2o1cFl1c3...HLmhPxTcMYPc3WNUWIS4t_8E3556087H4f1e-13y8B_dUYYzh-B7NJuOIOp31_eiAxhYzaQYGw

$ kubectl get secret/my-sa-token -o=jsonpath='{.data.token}'  | base64 --decode
eyJhbGciOiJSUzI1NiIsImtpZCI6IkxiTHE0d29pbFBiUXpXNkI1bWxoMHFQNVZCa2o1cFl1c3...HLmhPxTcMYPc3WNUWIS4t_8E3556087H4f1e-13y8B_dUYYzh-B7NJuOIOp31_eiAxhYzaQYGw

$ kubectl describe sa/my-sa
Name:                my-sa
Namespace:           default
Labels:              <none>
Annotations:         <none>
Image pull secrets:  <none>
Mountable secrets:   <none>
Tokens:              my-sa-token
Events:              <none>

Assign a ServiceAccount to a Pod

# pod-sa.yaml

apiVersion: v1
kind: Pod
metadata:
  name: curl
spec:
  serviceAccountName: my-sa
  automountServiceAccountToken: true
  containers:
  - image: alpine/curl
    name: curl
    command: ["sleep", "9999999"]

$ kubectl apply -f pod-sa.yaml
pod/curl created

$ kubectl get po
NAME   READY   STATUS    RESTARTS   AGE
curl   1/1     Running   0          4s

$ kubectl get pod/curl -o jsonpath='{.spec.serviceAccount}'
my-sa

$ kubectl exec -it pod/curl -- cat /var/run/secrets/kubernetes.io/serviceaccount/token
eyJhbGciOiJSUzI1NiIsImtpZCI6IkxiTHE0d29pbFBiUXpXNkI1bWxoMHFQNVZCa2o1cFl1c3...9Wd5ONTHu2VyrTfM6u1FAxC72hKWK0_5zpNg

$ kubectl exec -it pod/curl -- sh
/ # NS=$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace)
/ # TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
/ # export CURL_CA_BUNDLE=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt
/ # curl -s https://kubernetes.default.svc.cluster.local/api/v1/namespaces/$NS/pods -H "Authorization: Bearer $TOKEN"
{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {},
  "status": "Failure",
  "message": "pods is forbidden: User \"system:serviceaccount:default:my-sa\" cannot list resource \"pods\" in API group \"\" in the namespace \"default\"",
  "reason": "Forbidden",
  "details": {
    "kind": "pods"
  },
  "code": 403
}

RBAC

Role-Based Access Control (RBAC) is a security model that grants access to systems and data based on user roles, not individual users.

Role

# rbac-role.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: default
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

$ kubectl apply -f rbac-role.yaml -n default
role.rbac.authorization.k8s.io/pod-reader created

$ kubectl get role -n default
NAME         CREATED AT
pod-reader   2025-11-11T09:32:20Z

RoleBinding

# rbac-rolebinding.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods-binding
  namespace: default
subjects:
- kind: ServiceAccount
  name: my-sa
  namespace: default
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

$ kubectl apply -f rbac-rolebinding.yaml -n default
rolebinding.rbac.authorization.k8s.io/read-pods-binding created

$ kubectl get rolebindings -n default
NAME                ROLE              AGE
read-pods-binding   Role/pod-reader   35s

Validate ServiceAccount access

$ kubectl exec -it pod/curl -- sh
/ # NS=$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace)
/ # TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
/ # export CURL_CA_BUNDLE=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt
/ # curl -s https://kubernetes.default.svc.cluster.local/api/v1/namespaces/$NS/pods -H "Authorization: Bearer $TOKEN"
{
  "kind": "PodList",
  "apiVersion": "v1",
  "metadata": {
    "resourceVersion": "7148388"
  },
  "items": [
    {
      "metadata": {
        "name": "curl",
        "namespace": "default",
        "uid": "4fc1f8e7-9884-42c3-941e-9e27df563592",
        "resourceVersion": "7007001",
        "generation": 1,
        "creationTimestamp": "2025-11-10T11:13:48Z",
...
    }
  ]
}

$ kubectl delete -f rbac-rolebinding.yaml -n default
rolebinding.rbac.authorization.k8s.io "read-pods-binding" deleted

$ kubectl get rolebindings -n default
No resources found in default namespace.

$ kubectl delete role/pod-reader
role.rbac.authorization.k8s.io "pod-reader" deleted

$ kubectl get roles
No resources found in default namespace.

ClusterRole

# rbac-clusterrole.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pv-reader
rules:
- apiGroups: [""]
  resources: ["persistentvolumes"]
  verbs: ["get", "list"]

$ kubectl apply -f rbac-clusterrole.yaml
clusterrole.rbac.authorization.k8s.io/pv-reader created

$ kubectl describe clusterrole/pv-reader
Name:         pv-reader
Labels:       <none>
Annotations:  <none>
PolicyRule:
  Resources          Non-Resource URLs  Resource Names  Verbs
  ---------          -----------------  --------------  -----
  persistentvolumes  []                 []              [get list]

ClusterRoleBinding

# rbac-clusterrolebinding.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-pv-binding
subjects:
- kind: ServiceAccount
  name: my-sa
  namespace: default
roleRef:
  kind: ClusterRole
  name: pv-reader
  apiGroup: rbac.authorization.k8s.io

$ kubectl apply -f rbac-clusterrolebinding.yaml
clusterrolebinding.rbac.authorization.k8s.io/read-pv-binding created

$ kubectl describe clusterrolebinding/read-pv-binding
Name:         read-pv-binding
Labels:       <none>
Annotations:  <none>
Role:
  Kind:  ClusterRole
  Name:  pv-reader
Subjects:
  Kind            Name   Namespace
  ----            ----   ---------
  ServiceAccount  my-sa  default

Validate ServiceAccount access

$ kubectl exec -it pod/curl -- sh
/ # NS=$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace)
/ # TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
/ # export CURL_CA_BUNDLE=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt
/ # curl -s https://kubernetes.default.svc.cluster.local/api/v1/persistentvolumes -H "Authorization: Bearer $TOKEN"
{
  "kind": "PersistentVolumeList",
  "apiVersion": "v1",
  "metadata": {
    "resourceVersion": "7162702"
  },
  "items": []
}

$ kubectl delete sa/my-sa
serviceaccount "my-sa" deleted

$ kubectl delete clusterrolebinding/read-pv-binding
clusterrolebinding.rbac.authorization.k8s.io "read-pv-binding" deleted

$ kubectl delete clusterrole/pv-reader
clusterrole.rbac.authorization.k8s.io "pv-reader" deleted

$ kubectl delete po/curl
pod "curl" deleted

Pod Security

The Pod Security Admission (PSA) enforces the Pod Security Standards (PSS).

Kubernetes defines a set of labels that you can set to define which of the predefined PSS levels you want to use for a namespace.

The per-mode level label indicates which policy level (privileged, baseline, or restricted) to apply for the mode (enforce, audit, or warn).

metadata:
  labels:
    pod-security.kubernetes.io/<mode>: <level>

Restricted level with warn mode

# ns-psa-warn-restricted.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: psa-warn-restricted
  labels:
    pod-security.kubernetes.io/warn: restricted

$ kubectl apply -f ns-psa-warn-restricted.yaml
namespace/psa-warn-restricted created

# pod-warn-restricted.yaml

apiVersion: v1
kind: Pod
metadata:
  name: busybox
  namespace: psa-warn-restricted
spec:
  containers:
  - image: busybox:1.35.0
    name: busybox
    command: ["sh", "-c", "sleep 1h"]

$ kubectl apply -f pod-warn-restricted.yaml
Warning: would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "busybox" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "busybox" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "busybox" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "busybox" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
pod/busybox created

$ kubectl get po -n psa-warn-restricted
NAME      READY   STATUS    RESTARTS   AGE
busybox   1/1     Running   0          32s

$ kubectl delete ns/psa-warn-restricted
namespace "psa-warn-restricted" deleted

$ kubectl get po -n psa-warn-restricted
No resources found in psa-warn-restricted namespace.

Restricted level with enforce mode

# ns-psa-enforce-restricted.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: psa-enforce-restricted
  labels:
    pod-security.kubernetes.io/enforce: restricted

$ kubectl apply -f ns-psa-enforce-restricted.yaml
namespace/psa-enforce-restricted created

# pod-enforce-restricted.yaml

apiVersion: v1
kind: Pod
metadata:
  name: busybox
  namespace: psa-enforce-restricted
spec:
  containers:
  - image: busybox:1.35.0
    name: busybox
    command: ["sh", "-c", "sleep 1h"]

$ kubectl apply -f pod-enforce-restricted.yaml
Error from server (Forbidden): error when creating "pod-enforce-restricted.yaml": pods "busybox" is forbidden: violates PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "busybox" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "busybox" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "busybox" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "busybox" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")

# pod-enforce-restricted-v2.yaml

apiVersion: v1
kind: Pod
metadata:
  name: busybox
  namespace: psa-enforce-restricted
spec:
  containers:
  - image: busybox:1.35.0
    name: busybox
    command: ["sh", "-c", "sleep 1h"]
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: ["ALL"]
      runAsNonRoot: true
      runAsUser: 2000
      runAsGroup: 3000
      seccompProfile:
        type: RuntimeDefault

$ kubectl apply -f pod-enforce-restricted-v2.yaml
pod/busybox created

$ kubectl get po -n psa-enforce-restricted
NAME      READY   STATUS    RESTARTS   AGE
busybox   1/1     Running   0          71s

$ kubectl delete ns/psa-enforce-restricted
namespace "psa-enforce-restricted" deleted

$ kubectl get po -n psa-enforce-restricted
No resources found in psa-enforce-restricted namespace.

Baseline level with enforce mode

# ns-psa-enforce-baseline.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: psa-enforce-baseline
  labels:
    pod-security.kubernetes.io/enforce: baseline

$ kubectl apply -f ns-psa-enforce-baseline.yaml
namespace/psa-enforce-baseline created

# pod-enforce-baseline.yaml

apiVersion: v1
kind: Pod
metadata:
  name: busybox
  namespace: psa-enforce-baseline
spec:
  hostNetwork: true
  containers:
  - image: busybox:1.35.0
    name: busybox
    command: ["sh", "-c", "sleep 1h"]

$ kubectl apply -f pod-enforce-baseline.yaml
Error from server (Forbidden): error when creating "pod-enforce-baseline.yaml": pods "busybox" is forbidden: violates PodSecurity "baseline:latest": host namespaces (hostNetwork=true)

$ kubectl delete -f ns-psa-enforce-baseline.yaml
namespace "psa-enforce-baseline" deleted

Privileged level with enforce mode

# ns-psa-enforce-privileged.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: psa-enforce-privileged
  labels:
    pod-security.kubernetes.io/enforce: privileged

$ kubectl apply -f ns-psa-enforce-privileged.yaml
namespace/psa-enforce-privileged created

# pod-enforce-privileged.yaml

apiVersion: v1
kind: Pod
metadata:
  name: busybox
  namespace: psa-enforce-privileged
spec:
  hostNetwork: true
  hostPID: true
  hostIPC: true
  securityContext:
    runAsUser: 0
  containers:
  - image: busybox:1.35.0
    name: busybox
    command: ["sh", "-c", "sleep 1h"]
    securityContext:
      privileged: true

$ kubectl apply -f pod-enforce-privileged.yaml
pod/busybox created

$ kubectl exec -ti pod/busybox -n psa-enforce-privileged -- ps
PID   USER     TIME  COMMAND
    1 root      0:54 {systemd} /sbin/init
  116 root      1h50 /usr/local/bin/containerd
  185 root      5h06 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/kubelet/config.yaml --container-runtime-endpoint=unix:///run/containerd/containerd.sock --node-ip=172.18.0.3 --node-labels= --pod-infra-container-image=registry.k8s.io/pause:3.10 --provider-id=kind://docker/kind/kind-worker3 --runtime-cgroups=/system.slice/containerd.service
  358 root      5:49 /usr/local/bin/containerd-shim-runc-v2 -namespace k8s.io -id abfaf0f18c5ce3d14ba5236c34ed8048486151649c0183c0d5228240a64cdc39 -address /run/containerd/containerd.sock
  436 root      4:56 /usr/local/bin/containerd-shim-runc-v2 -namespace k8s.io -id 0c430d300ff99ed691cc7daca4b6276b41621c19739462c7fe1275abf8cd4f93 -address /run/containerd/containerd.sock
  494 65535     0:00 /pause
  554 65535     0:00 /pause
  665 root      5:38 /usr/local/bin/kube-proxy --config=/var/lib/kube-proxy/config.conf --hostname-override=kind-worker3
  698 root      8:15 /bin/kindnetd
151332 root      0:01 /lib/systemd/systemd-journald
336224 root      0:00 /usr/local/bin/containerd-shim-runc-v2 -namespace k8s.io -id 6b7c911e749486aca30a8e963ee6d4781391f73b63490e98cbdbb537fe4b538b -address /run/containerd/containerd.sock
336248 root      0:00 /pause
336274 root      0:00 sleep 1h
336627 root      0:00 ps

$ kubectl delete -f ns-psa-enforce-privileged.yaml
namespace "psa-enforce-privileged" deleted

NetworkPolicy

In contexts like Kubernetes, Network Policies are used to control communication between pods, while broader network policies can be applied to devices like switches and routers to align the network with business needs.

The kind does not support the NetworkPolicy by default, as it comes with a simple networking implementation kindnetd as default CNI pluging.

Install a CNI Networking Plugin

Recreating a cluster

Therefore, it is necessary recreate the kind cluster using the CNI Calico plugin.

$ kind delete cluster
Deleting cluster "kind" ...
Deleted nodes: ["kind-worker" "kind-control-plane" "kind-worker3" "kind-worker2"]

# kind-cluster-cni.yaml

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
networking:
  disableDefaultCNI: true
  podSubnet: 192.168.0.0/16
nodes:
- role: control-plane
- role: worker
- role: worker
- role: worker

$ kind create cluster --config kind-cluster-cni.yaml --name=kind-calico
Creating cluster "kind-calico" ...
 • Ensuring node image (kindest/node:v1.33.1) 🖼  ...
 ✓ Ensuring node image (kindest/node:v1.33.1) 🖼
 • Preparing nodes 📦 📦 📦 📦   ...
 ✓ Preparing nodes 📦 📦 📦 📦
 • Writing configuration 📜  ...
 ✓ Writing configuration 📜
 • Starting control-plane 🕹️  ...
 ✓ Starting control-plane 🕹️
 • Installing StorageClass 💾  ...
 ✓ Installing StorageClass 💾
 • Joining worker nodes 🚜  ...
 ✓ Joining worker nodes 🚜
Set kubectl context to "kind-kind-calico"
You can now use your cluster with:

kubectl cluster-info --context kind-kind-calico

Thanks for using kind! 😊

$ kubectl get no
NAME                        STATUS     ROLES           AGE     VERSION
kind-calico-control-plane   NotReady   control-plane   3m43s   v1.33.1
kind-calico-worker          NotReady   <none>          3m30s   v1.33.1
kind-calico-worker2         NotReady   <none>          3m30s   v1.33.1
kind-calico-worker3         NotReady   <none>          3m30s   v1.33.1

Installing Calico plugin

$ kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.28.3/manifests/calico.yaml
poddisruptionbudget.policy/calico-kube-controllers created
serviceaccount/calico-kube-controllers created
serviceaccount/calico-node created
serviceaccount/calico-cni-plugin created
configmap/calico-config created
customresourcedefinition.apiextensions.k8s.io/bgpconfigurations.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/bgpfilters.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/bgppeers.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/blockaffinities.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/caliconodestatuses.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/clusterinformations.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/felixconfigurations.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/globalnetworkpolicies.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/globalnetworksets.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/hostendpoints.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/ipamblocks.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/ipamconfigs.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/ipamhandles.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/ippools.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/ipreservations.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/kubecontrollersconfigurations.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/networkpolicies.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/networksets.crd.projectcalico.org created
clusterrole.rbac.authorization.k8s.io/calico-kube-controllers created
clusterrole.rbac.authorization.k8s.io/calico-node created
clusterrole.rbac.authorization.k8s.io/calico-cni-plugin created
clusterrolebinding.rbac.authorization.k8s.io/calico-kube-controllers created
clusterrolebinding.rbac.authorization.k8s.io/calico-node created
clusterrolebinding.rbac.authorization.k8s.io/calico-cni-plugin created
daemonset.apps/calico-node created
deployment.apps/calico-kube-controllers created

$ kubectl get pods -l k8s-app=calico-node -A --watch
NAMESPACE     NAME                READY   STATUS     RESTARTS   AGE
kube-system   calico-node-c264z   0/1     Init:2/3   0          61s
kube-system   calico-node-d98t7   0/1     Init:2/3   0          61s
kube-system   calico-node-sps7w   0/1     Init:2/3   0          61s
kube-system   calico-node-ssd8q   0/1     Init:2/3   0          61s
kube-system   calico-node-ssd8q   0/1     PodInitializing   0          89s
kube-system   calico-node-d98t7   0/1     PodInitializing   0          89s
kube-system   calico-node-c264z   0/1     Init:2/3          0          89s
kube-system   calico-node-sps7w   0/1     PodInitializing   0          90s
kube-system   calico-node-ssd8q   0/1     Running           0          90s
kube-system   calico-node-d98t7   0/1     Running           0          90s
kube-system   calico-node-c264z   0/1     PodInitializing   0          90s
kube-system   calico-node-sps7w   0/1     Running           0          91s
kube-system   calico-node-c264z   0/1     Running           0          91s
kube-system   calico-node-d98t7   1/1     Running           0          101s
kube-system   calico-node-ssd8q   1/1     Running           0          102s
kube-system   calico-node-c264z   1/1     Running           0          102s
kube-system   calico-node-sps7w   1/1     Running           0          103s

$ kubectl get no
NAME                        STATUS   ROLES           AGE     VERSION
kind-calico-control-plane   Ready    control-plane   4m28s   v1.33.1
kind-calico-worker          Ready    <none>          4m15s   v1.33.1
kind-calico-worker2         Ready    <none>          4m15s   v1.33.1
kind-calico-worker3         Ready    <none>          4m15s   v1.33.1

Setup a NetworkPolicy

# ns-foo-bar.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: foo
  labels:
    tenant: foo
---
apiVersion: v1
kind: Namespace
metadata:
  name: bar
  labels:
    tenant: bar

$ kubectl apply -f ns-foo-bar.yaml
namespace/foo created
namespace/bar created

# pod-ns-foo-bar.yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx-foo
  namespace: foo
  labels:
    tier: foo
spec:
  containers:
  - image: nginx:latest
    name: nginx-foo
    ports:
    - containerPort: 80
      protocol: TCP
---
apiVersion: v1
kind: Pod
metadata:
  name: nginx-bar
  namespace: bar
  labels:
    tier: bar
spec:
  containers:
  - image: nginx:latest
    name: nginx-bar
    ports:
    - containerPort: 80
      protocol: TCP

$ kubectl apply -f pod-ns-foo-bar.yaml
pod/nginx-foo created
pod/nginx-bar created

Ingress

$ kubectl get po -n bar -o wide
NAME        READY   STATUS    RESTARTS   AGE     IP              NODE                  NOMINATED NODE   READINESS GATES
nginx-bar   1/1     Running   0          2m16s   192.168.52.65   kind-calico-worker2   <none>           <none>

$ kubectl exec pod/nginx-foo -n foo -- curl -sI http://192.168.52.65:80
HTTP/1.1 200 OK
Server: nginx/1.29.3
Date: Sat, 15 Nov 2025 12:34:19 GMT
Content-Type: text/html
Content-Length: 615
Last-Modified: Tue, 28 Oct 2025 12:05:10 GMT
Connection: keep-alive
ETag: "6900b176-267"
Accept-Ranges: bytes

# networkpolicy-ingress.yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: bar
spec:
  podSelector: {}
  policyTypes:
  - Ingress

$ kubectl apply -f networkpolicy-ingress.yaml
networkpolicy.networking.k8s.io/deny-all created

$ kubectl get networkpolicy -n bar
NAME       POD-SELECTOR   AGE
deny-all   <none>         41s

$ kubectl exec pod/nginx-foo -n foo -- curl -svI http://192.168.52.65:80
*   Trying 192.168.52.65:80...
* connect to 192.168.52.65 port 80 from 192.168.28.193 port 43618 failed: Connection timed out
* Failed to connect to 192.168.52.65 port 80 after 135435 ms: Could not connect to server
* closing connection #0
command terminated with exit code 28

Ingress

$ kubectl get po -n foo -o wide
NAME        READY   STATUS    RESTARTS   AGE   IP               NODE                  NOMINATED NODE   READINESS GATES
nginx-foo   1/1     Running   0          15m   192.168.28.193   kind-calico-worker3   <none>           <none>

$ kubectl exec pod/nginx-bar -n bar -- curl -sI http://192.168.28.193:80
HTTP/1.1 200 OK
Server: nginx/1.29.3
Date: Sat, 15 Nov 2025 12:46:20 GMT
Content-Type: text/html
Content-Length: 615
Last-Modified: Tue, 28 Oct 2025 12:05:10 GMT
Connection: keep-alive
ETag: "6900b176-267"
Accept-Ranges: bytes

# networkpolicy-egress.yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-pod-bar-egress
  namespace: bar
spec:
  podSelector:
    matchLabels:
      tier: bar
  policyTypes:
  - Egress

$ kubectl apply -f networkpolicy-egress.yaml
networkpolicy.networking.k8s.io/deny-pod-bar-egress created

$ kubectl get networkpolicy -n bar
NAME                  POD-SELECTOR   AGE
deny-all              <none>         18m
deny-pod-bar-egress   tier=bar       8s

$ kubectl exec pod/nginx-bar -n bar -- curl -svI http://192.168.28.193:80
*   Trying 192.168.28.193:80...
* connect to 192.168.28.193 port 80 from 192.168.52.65 port 58978 failed: Connection timed out
* Failed to connect to 192.168.28.193 port 80 after 135323 ms: Could not connect to server
* closing connection #0
command terminated with exit code 28

$ kubectl delete -n bar networkpolicies deny-all deny-pod-bar-egress
networkpolicy.networking.k8s.io "deny-all" deleted
networkpolicy.networking.k8s.io "deny-pod-bar-egress" deleted

$ kubectl delete ns foo bar
namespace "foo" deleted
namespace "bar" deleted

LimitRange

A LimitRange is a policy defined within a specific namespace to constrain resource allocations for Pods and Containers.

$ kubectl apply -f ns-foo-bar.yaml
namespace/foo created
namespace/bar created

# pod-resource-requests-limits.yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:latest
    resources:
      requests:
        cpu: 200m
        memory: 10Mi
      limits:
        cpu: 1
        memory: 2Gi

$ kubectl apply -f pod-resource-requests-limits.yaml -n foo
pod/nginx created

# limitrange.yaml

apiVersion: v1
kind: LimitRange
metadata:
  name: resource-constraints
spec:
  limits:
  - type: Pod
    max:
      memory: 2Gi
      cpu: 1
    min:
      memory: 50Mi
      cpu: 200m      
  - type: Container
    default:
      cpu: 0.5
    defaultRequest:
      cpu: 0.2
    max:
      memory: 1Gi
      cpu: 800m
    min:
      memory: 50Mi
      cpu: 100m

$ kubectl apply -f limitrange.yaml -n bar
limitrange/resource-constraints created

$ kubectl get limitranges -n bar
NAME                   CREATED AT
resource-constraints   2025-11-17T23:06:33Z

$ kubectl apply -f pod-resource-requests-limits.yaml -n bar
Error from server (Forbidden): error when creating "pod-resource-requests-limits.yaml": pods "nginx" is forbidden: [minimum memory usage per Pod is 50Mi, but request is 10Mi, minimum memory usage per Container is 50Mi, but request is 10Mi, maximum cpu usage per Container is 800m, but limit is 1, maximum memory usage per Container is 1Gi, but limit is 2Gi]

# pod-basic.yaml

apiVersion: v1
kind: Pod
metadata:
  name: kubia
spec:
  containers:
  - image: luksa/kubia
    name: kubia
    ports:
    - containerPort: 8080
      protocol: TCP

$ kubectl apply -f pod-basic.yaml -n bar
pod/kubia created

$ kubectl get pod/kubia -n bar -o jsonpath={.spec.containers[0].resources}
{"limits":{"cpu":"500m","memory":"1Gi"},"requests":{"cpu":"200m","memory":"1Gi"}}

$ kubectl delete -f ns-foo-bar.yaml
namespace "foo" deleted
namespace "bar" deleted

ResourceQuota

A ResourceQuota is an object that allows cluster administrators to limit the aggregated consumption of compute resources (CPU, memory, storage) and the number of API objects within a specific namespace.

$ kubectl create namespace baz
namespace/baz created

# quota.yaml

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources-quota
spec:
  hard:
    requests.cpu: 500m
    requests.memory: 1Gi
    limits.cpu: 2
    limits.memory: 2Gi
    pods: 3
    secrets: 10

$ kubectl create -f quota.yaml -n baz
resourcequota/compute-resources-quota created

$ kubectl describe -n baz quota
Name:            compute-resources-quota
Namespace:       baz
Resource         Used  Hard
--------         ----  ----
limits.cpu       0     2
limits.memory    0     2Gi
pods             0     3
requests.cpu     0     500m
requests.memory  0     1Gi
secrets          0     10

# rs-resource-requests-limits.yaml

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        resources:
          requests:
            cpu: 200m
            memory: 10Mi
          limits:
            cpu: 1
            memory: 2Gi

$ kubectl create -f rs-resource-requests-limits.yaml -n baz
replicaset.apps/nginx created

$ kubectl describe -n baz quota
Name:            compute-resources-quota
Namespace:       baz
Resource         Used  Hard
--------         ----  ----
limits.cpu       1     2
limits.memory    2Gi   2Gi
pods             1     3
requests.cpu     200m  500m
requests.memory  10Mi  1Gi
secrets          0     10

$ kubectl scale -n baz rs/nginx --replicas 3
replicaset.apps/nginx scaled

$ kubectl describe -n baz quota
Name:            compute-resources-quota
Namespace:       baz
Resource         Used  Hard
--------         ----  ----
limits.cpu       1     2
limits.memory    2Gi   2Gi
pods             1     3
requests.cpu     200m  500m
requests.memory  10Mi  1Gi
secrets          0     10

$ kubectl get rs -n baz
NAME    DESIRED   CURRENT   READY   AGE
nginx   3         1         1       1m52s

$ kubectl events -n baz rs/nginx
LAST SEEN               TYPE      REASON             OBJECT             MESSAGE
111s                    Normal    Scheduled          Pod/nginx-rwqnq    Successfully assigned baz/nginx-rwqnq to kind-calico-worker2
111s                    Normal    SuccessfulCreate   ReplicaSet/nginx   Created pod: nginx-rwqnq
110s                    Normal    Pulling            Pod/nginx-rwqnq    Pulling image "nginx:latest"
109s                    Normal    Started            Pod/nginx-rwqnq    Started container nginx
109s                    Normal    Created            Pod/nginx-rwqnq    Created container: nginx
109s                    Normal    Pulled             Pod/nginx-rwqnq    Successfully pulled image "nginx:latest" in 1.257s (1.257s including waiting). Image size: 59774010 bytes.
27s                     Warning   FailedCreate       ReplicaSet/nginx   Error creating: pods "nginx-rvzhm" is forbidden: exceeded quota: compute-resources-quota, requested: limits.memory=2Gi, used: limits.memory=2Gi, limited: limits.memory=2Gi
27s                     Warning   FailedCreate       ReplicaSet/nginx   Error creating: pods "nginx-64g4w" is forbidden: exceeded quota: compute-resources-quota, requested: limits.memory=2Gi, used: limits.memory=2Gi, limited: limits.memory=2Gi
27s                     Warning   FailedCreate       ReplicaSet/nginx   Error creating: pods "nginx-lgkm2" is forbidden: exceeded quota: compute-resources-quota, requested: limits.memory=2Gi, used: limits.memory=2Gi, limited: limits.memory=2Gi
27s                     Warning   FailedCreate       ReplicaSet/nginx   Error creating: pods "nginx-4776k" is forbidden: exceeded quota: compute-resources-quota, requested: limits.memory=2Gi, used: limits.memory=2Gi, limited: limits.memory=2Gi
27s                     Warning   FailedCreate       ReplicaSet/nginx   Error creating: pods "nginx-2trm4" is forbidden: exceeded quota: compute-resources-quota, requested: limits.memory=2Gi, used: limits.memory=2Gi, limited: limits.memory=2Gi
27s                     Warning   FailedCreate       ReplicaSet/nginx   Error creating: pods "nginx-c5t9z" is forbidden: exceeded quota: compute-resources-quota, requested: limits.memory=2Gi, used: limits.memory=2Gi, limited: limits.memory=2Gi
27s                     Warning   FailedCreate       ReplicaSet/nginx   Error creating: pods "nginx-8jkkk" is forbidden: exceeded quota: compute-resources-quota, requested: limits.memory=2Gi, used: limits.memory=2Gi, limited: limits.memory=2Gi
26s                     Warning   FailedCreate       ReplicaSet/nginx   Error creating: pods "nginx-44vv6" is forbidden: exceeded quota: compute-resources-quota, requested: limits.memory=2Gi, used: limits.memory=2Gi, limited: limits.memory=2Gi
26s                     Warning   FailedCreate       ReplicaSet/nginx   Error creating: pods "nginx-4m8jm" is forbidden: exceeded quota: compute-resources-quota, requested: limits.memory=2Gi, used: limits.memory=2Gi, limited: limits.memory=2Gi
7s (x4 over 24s)        Warning   FailedCreate       ReplicaSet/nginx   (combined from similar events): Error creating: pods "nginx-k65jl" is forbidden: exceeded quota: compute-resources-quota, requested: limits.memory=2Gi, used: limits.memory=2Gi, limited: limits.memory=2Gi

$ kubectl delete ns/baz
namespace "baz" deleted

HorizontalPodAutoscaler

Horizontal Pod Autoscaler is a component that automatically scales the number of Pod replicas in a Deployment, ReplicaSet, or StatefulSet based on observed metrics.

Installing the Metrics Server

Metrics Server is a scalable, efficient source of container resource metrics for built-in autoscaling pipelines.

$ kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
serviceaccount/metrics-server created
clusterrole.rbac.authorization.k8s.io/system:aggregated-metrics-reader created
clusterrole.rbac.authorization.k8s.io/system:metrics-server created
rolebinding.rbac.authorization.k8s.io/metrics-server-auth-reader created
clusterrolebinding.rbac.authorization.k8s.io/metrics-server:system:auth-delegator created
clusterrolebinding.rbac.authorization.k8s.io/system:metrics-server created
service/metrics-server created
deployment.apps/metrics-server created
apiservice.apiregistration.k8s.io/v1beta1.metrics.k8s.io created

$ kubectl patch -n kube-system deployment metrics-server --type=json -p '[{"op":"add","path":"/spec/template/spec/containers/0/args/-","value":"--kubelet-insecure-tls"}]'
deployment.apps/metrics-server patched

$ kubectl get apiservices | grep metrics.k8s.io
v1beta1.metrics.k8s.io            kube-system/metrics-server   True        97s

$ kubectl top node
NAME                        CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
kind-calico-control-plane   146m         3%     1102Mi          13%
kind-calico-worker          52m          1%     426Mi           5%
kind-calico-worker2         49m          1%     303Mi           3%
kind-calico-worker3         49m          1%     383Mi           4%

Setup the HPA

# nginx-service.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  selector:
    matchLabels:
      run: nginx
  template:
    metadata:
      labels:
        run: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80
        resources:
          limits:
            cpu: 500m
          requests:
            cpu: 100m
---
apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    run: nginx
spec:
  ports:
  - port: 80
  selector:
    run: nginx

$ kubectl apply -f nginx-service.yaml
deployment.apps/nginx created
service/nginx created

$ kubectl get po
NAME                     READY   STATUS    RESTARTS   AGE
nginx-54ff6b8849-lnsn6   1/1     Running   0          16s

# hpa.yaml

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: nginx-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx
  minReplicas: 1
  maxReplicas: 5
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 30

$ kubectl apply -f hpa.yaml
horizontalpodautoscaler.autoscaling/nginx-hpa created

$ kubectl get hpa
NAME        REFERENCE          TARGETS       MINPODS   MAXPODS   REPLICAS   AGE
nginx-hpa   Deployment/nginx   cpu: 0%/30%   1         5         1          16

$ kubectl get deployment
NAME    READY   UP-TO-DATE   AVAILABLE   AGE
nginx   1/1     1            1           83s

$ kubectl run -ti --rm load-generator --image=alpine/curl --restart=Never --pod-running-timeout=10m -- /bin/sh -c "while true; do curl -sI http://nginx:80; done"

$ kubectl get hpa nginx-hpa --watch
NAME        REFERENCE          TARGETS       MINPODS   MAXPODS   REPLICAS   AGE
nginx-hpa   Deployment/nginx   cpu: 0%/30%   1         5         1          62s
nginx-hpa   Deployment/nginx   cpu: 10%/30%   1         5         1          91s
nginx-hpa   Deployment/nginx   cpu: 53%/30%   1         5         1          106s
nginx-hpa   Deployment/nginx   cpu: 48%/30%   1         5         2          2m1s
nginx-hpa   Deployment/nginx   cpu: 29%/30%   1         5         2          2m16s
nginx-hpa   Deployment/nginx   cpu: 25%/30%   1         5         2          2m31s
nginx-hpa   Deployment/nginx   cpu: 24%/30%   1         5         2          3m1s
nginx-hpa   Deployment/nginx   cpu: 25%/30%   1         5         2          3m16s

$ kubectl delete po load-generator
pod "load-generator" deleted

$ kubectl get hpa nginx-hpa --watch
NAME        REFERENCE          TARGETS        MINPODS   MAXPODS   REPLICAS   AGE
nginx-hpa   Deployment/nginx   cpu: 25%/30%   1         5         2          4m3s
nginx-hpa   Deployment/nginx   cpu: 12%/30%   1         5         2          4m16s
nginx-hpa   Deployment/nginx   cpu: 8%/30%    1         5         2          4m31s
nginx-hpa   Deployment/nginx   cpu: 0%/30%    1         5         2          4m46s
nginx-hpa   Deployment/nginx   cpu: 0%/30%    1         5         2          9m1s
nginx-hpa   Deployment/nginx   cpu: 0%/30%    1         5         1          9m16s

$ kubectl delete deployments/nginx
deployment.apps "nginx" deleted

$ kubectl delete hpa/nginx-hpa
horizontalpodautoscaler.autoscaling "nginx-hpa" deleted

PodDisruptionBudget

A PodDisruptionBudget is an object that ensures a specified minimum number or percentage of pods remain available during voluntary disruptions.

$ kubectl create deployment nginx --image=nginx --replicas=1
deployment.apps/nginx created

$ kubectl get deployments.apps nginx
NAME    READY   UP-TO-DATE   AVAILABLE   AGE
nginx   1/1     1            1           21s

# pdb.yaml

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: nginx-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: nginx

$ kubectl create -f pdb.yaml
poddisruptionbudget.policy/nginx-pdb created

$ kubectl get pdb
NAME        MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
nginx-pdb   2               N/A               0                     29s

$ kubectl get po -o wide
NAME                     READY   STATUS    RESTARTS   AGE   IP              NODE                  NOMINATED NODE   READINESS GATES
nginx-5869d7778c-cftzp   1/1     Running   0          11m   192.168.52.77   kind-calico-worker2   <none>           <none>

$ kubectl drain kind-calico-worker2 --ignore-daemonsets
node/kind-calico-worker2 cordoned
Warning: ignoring DaemonSet-managed Pods: kube-system/calico-node-9ghkn, kube-system/kube-proxy-zcrm6
evicting pod default/nginx-5869d7778c-cftzp
error when evicting pods/"nginx-5869d7778c-cftzp" -n "default" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.

$ kubectl get no
NAME                        STATUS                     ROLES           AGE    VERSION
kind-calico-control-plane   Ready                      control-plane   116m   v1.33.1
kind-calico-worker          Ready                      <none>          115m   v1.33.1
kind-calico-worker2         Ready,SchedulingDisabled   <none>          115m   v1.33.1
kind-calico-worker3         Ready                      <none>          115m   v1.33.1

$ kubectl get po -o wide
NAME                     READY   STATUS    RESTARTS   AGE   IP              NODE                  NOMINATED NODE   READINESS GATES
nginx-5869d7778c-cftzp   1/1     Running   0          16m   192.168.52.77   kind-calico-worker2   <none>           <none>

$ kubectl uncordon kind-calico-worker2
node/kind-calico-worker2 uncordoned

$ kubectl get no
NAME                        STATUS   ROLES           AGE    VERSION
kind-calico-control-plane   Ready    control-plane   116m   v1.33.1
kind-calico-worker          Ready    <none>          116m   v1.33.1
kind-calico-worker2         Ready    <none>          116m   v1.33.1
kind-calico-worker3         Ready    <none>          116m   v1.33.1

$ kubectl delete pdb/nginx-pdb
poddisruptionbudget.policy "nginx-pdb" deleted

$ kubectl delete deployments.apps/nginx
deployment.apps "nginx" deleted

Taints and Tolerations

Taints and Tolerations are mechanisms that work together to control pod placement on nodes.

Taints

A taint is applied to a node to indicate that the node should not accept certain pods. Taints are key-value pairs with an associated effect.

$ kubectl get nodes
NAME                        STATUS   ROLES           AGE     VERSION
kind-calico-control-plane   Ready    control-plane   4d12h   v1.33.1
kind-calico-worker          Ready    <none>          4d12h   v1.33.1
kind-calico-worker2         Ready    <none>          4d12h   v1.33.1
kind-calico-worker3         Ready    <none>          4d12h   v1.33.1

$ kubectl get node/kind-calico-control-plane -o jsonpath='{.spec.taints}'
[{"effect":"NoSchedule","key":"node-role.kubernetes.io/control-plane"}]

$ kubectl get node/kind-calico-worker -o jsonpath='{.spec.taints}'
$

$ kubectl taint node kind-calico-worker node-type=production:NoSchedule
node/kind-calico-worker tainted

$ kubectl get node/kind-calico-worker -o jsonpath='{.spec.taints}'
[{"effect":"NoSchedule","key":"node-type","value":"production"}]

$ kubectl create deploy nginx --image nginx --replicas=5
deployment.apps/nginx created

$ kubectl get po -o custom-columns=NAME:.metadata.name,NODE:.spec.nodeName,STATUS:.status.phase
NAME                     NODE                  STATUS
nginx-5869d7778c-cxngx   kind-calico-worker2   Running
nginx-5869d7778c-d8fm2   kind-calico-worker3   Running
nginx-5869d7778c-lpfjl   kind-calico-worker2   Running
nginx-5869d7778c-mmwhl   kind-calico-worker3   Running
nginx-5869d7778c-mqt2k   kind-calico-worker2   Running

Tolerations

A toleration is applied to a pod and allows that pod to be scheduled on a node with a matching taint.

# deployment-tolerations.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  replicas: 5
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
  tolerations:
  - key: node-type
    operator: Equal
    value: production
    effect: NoSchedule

$ kubectl apply -f deployment-tolerations.yaml
Warning: resource deployments/nginx is missing the kubectl.kubernetes.io/last-applied-configuration annotation which is required by kubectl apply. kubectl apply should only be used on resources created declaratively by either kubectl create --save-config or kubectl apply. The missing annotation will be patched automatically.
deployment.apps/nginx configured

$ kubectl get po
NAME                     READY   STATUS    RESTARTS   AGE
nginx-6cd5747b88-75vfn   1/1     Running   0          3m40s
nginx-6cd5747b88-gr7r8   1/1     Running   0          3m40s
nginx-6cd5747b88-pqv6s   1/1     Running   0          3m37s
nginx-6cd5747b88-xzpjl   1/1     Running   0          3m36s
nginx-6cd5747b88-zzf7h   1/1     Running   0          3m39s

$ kubectl get po -o custom-columns=NAME:.metadata.name,NODE:.spec.nodeName,STATUS:.status.phase
NAME                     NODE                  STATUS
nginx-6cd5747b88-75vfn   kind-calico-worker    Running
nginx-6cd5747b88-gr7r8   kind-calico-worker3   Running
nginx-6cd5747b88-pqv6s   kind-calico-worker    Running
nginx-6cd5747b88-xzpjl   kind-calico-worker3   Running
nginx-6cd5747b88-zzf7h   kind-calico-worker2   Running

$ kubectl taint node kind-calico-worker2 node-type=development:NoExecute
node/kind-calico-worker2 tainted

$ kubectl get po -o custom-columns=NAME:.metadata.name,NODE:.spec.nodeName,STATUS:.status.phase
NAME                     NODE                  STATUS
nginx-6cd5747b88-6k6s2   kind-calico-worker3   Running
nginx-6cd5747b88-75vfn   kind-calico-worker    Running
nginx-6cd5747b88-gr7r8   kind-calico-worker3   Running
nginx-6cd5747b88-pqv6s   kind-calico-worker    Running
nginx-6cd5747b88-xzpjl   kind-calico-worker3   Running

$ kubectl delete deployments.apps nginx
deployment.apps "nginx" deleted

$ kubectl taint node kind-calico-worker2 node-type=development:NoExecute-
node/kind-calico-worker2 untainted

$ kubectl taint node kind-calico-worker node-type=production:NoSchedule-
node/kind-calico-worker untainted

Affinity

Kubernetes affinity is a powerful feature that allows for more expressive and flexible control over how pods are scheduled onto nodes within a cluster. It provides a more advanced alternative to nodeSelector for directing pod placement.

Node affinity

$ kubectl get no
NAME                        STATUS   ROLES           AGE     VERSION
kind-calico-control-plane   Ready    control-plane   5d11h   v1.33.1
kind-calico-worker          Ready    <none>          5d11h   v1.33.1
kind-calico-worker2         Ready    <none>          5d11h   v1.33.1
kind-calico-worker3         Ready    <none>          5d11h   v1.33.1

$ kubectl label node kind-calico-worker disktype=ssd
node/kind-calico-worker labeled

$ kubectl get no -L disktype
NAME                        STATUS   ROLES           AGE     VERSION   DISKTYPE
kind-calico-control-plane   Ready    control-plane   5d11h   v1.33.1
kind-calico-worker          Ready    <none>          5d11h   v1.33.1   ssd
kind-calico-worker2         Ready    <none>          5d11h   v1.33.1
kind-calico-worker3         Ready    <none>          5d11h   v1.33.1

Schedule a Pod using required node affinity

# deployment-required-nodeaffinity.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  replicas: 5
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: disktype
                operator: In
                values:
                - ssd

$ kubectl get po
No resources found in default namespace.

$ kubectl apply -f deployment-required-nodeaffinity.yaml
deployment.apps/nginx created

$ kubectl get po -o custom-columns=NAME:.metadata.name,NODE:.spec.nodeName,STATUS:.status.phase
NAME                     NODE                 STATUS
nginx-7bdd94c84c-6hxgp   kind-calico-worker   Running
nginx-7bdd94c84c-kcbhv   kind-calico-worker   Running
nginx-7bdd94c84c-kh2f7   kind-calico-worker   Running
nginx-7bdd94c84c-qshhl   kind-calico-worker   Running
nginx-7bdd94c84c-thspc   kind-calico-worker   Running

Schedule a Pod using preferred node affinity

$ kubectl label node kind-calico-worker{2,3} gpu=true
node/kind-calico-worker2 labeled
node/kind-calico-worker3 labeled

$ kubectl get no -L disktype,gpu
NAME                        STATUS   ROLES           AGE     VERSION   DISKTYPE   GPU
kind-calico-control-plane   Ready    control-plane   5d12h   v1.33.1
kind-calico-worker          Ready    <none>          5d12h   v1.33.1   ssd
kind-calico-worker2         Ready    <none>          5d12h   v1.33.1              true
kind-calico-worker3         Ready    <none>          5d12h   v1.33.1              true

# deployment-preffered-nodeaffinity.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  replicas: 5
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 80
            preference:
              matchExpressions:
              - key: disktype
                operator: In
                values:
                - ssd
          - weight: 20
            preference:
              matchExpressions:
              - key: gpu
                operator: In
                values:
                - "true"

$ kubectl apply -f deployment-preffered-nodeaffinity.yaml
deployment.apps/nginx configured

$ kubectl get po -o custom-columns=NAME:.metadata.name,NODE:.spec.nodeName,STATUS:.status.phase
NAME                     NODE                  STATUS
nginx-5898d5cc8d-46z7p   kind-calico-worker2   Running
nginx-5898d5cc8d-5q8rw   kind-calico-worker    Running
nginx-5898d5cc8d-kkmdz   kind-calico-worker    Running
nginx-5898d5cc8d-q95zw   kind-calico-worker    Running
nginx-5898d5cc8d-r27b5   kind-calico-worker3   Running

$ kubectl delete deployments.apps nginx
deployment.apps "nginx" deleted

Pod affinity and anti-affinity

$ kubectl run backend -l app=backend --image busybox -- sleep 999999
pod/backend created

$ kubectl get po -o custom-columns=NAME:.metadata.name,NODE:.spec.nodeName,STATUS:.status.phase
NAME      NODE                  STATUS
backend   kind-calico-worker3   Running

# deployment-required-podaffinity.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend
  labels:
    app: nginx
spec:
  replicas: 5
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
      affinity:
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchLabels:
                app: backend
            topologyKey: kubernetes.io/hostname

$ kubectl apply -f deployment-required-podaffinity.yaml
deployment.apps/frontend created

$ kubectl get po -o custom-columns=NAME:.metadata.name,NODE:.spec.nodeName,STATUS:.status.phase
NAME                        NODE                  STATUS
backend                     kind-calico-worker3   Running
frontend-67c67944bf-lnw56   kind-calico-worker3   Pending
frontend-67c67944bf-wc7j5   kind-calico-worker3   Pending
frontend-67c67944bf-wxj65   kind-calico-worker3   Pending
frontend-67c67944bf-xlc9r   kind-calico-worker3   Running
frontend-67c67944bf-xs79k   kind-calico-worker3   Running

# deployment-required-podantiaffinity.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend
  labels:
    app: nginx
spec:
  replicas: 5
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchLabels:
                app: backend
            topologyKey: kubernetes.io/hostname

$ kubectl apply -f deployment-required-podaffinity.yaml
deployment.apps/frontend created

$ kubectl get po -o custom-columns=NAME:.metadata.name,NODE:.spec.nodeName,STATUS:.status.phase
NAME                        NODE                  STATUS
backend                     kind-calico-worker3   Running
frontend-6dd9b5dbb9-cnswz   kind-calico-worker    Running
frontend-6dd9b5dbb9-f8lmq   kind-calico-worker    Running
frontend-6dd9b5dbb9-lph98   kind-calico-worker2   Running
frontend-6dd9b5dbb9-m424v   kind-calico-worker2   Running
frontend-6dd9b5dbb9-mbqmm   kind-calico-worker2   Running

$ kubectl delete deployments.apps frontend
deployment.apps "frontend" deleted

$ kubectl delete pod/backend
pod "backend" deleted

Cleanup

$ kind delete clusters kind-calico
Deleted nodes: ["kind-calico-worker" "kind-calico-worker3" "kind-calico-worker2" "kind-calico-control-plane"]
Deleted clusters: ["kind-calico"]

Configure TLS in Redis Cluster

Ježek — Wed, 09 Apr 2025 18:32:08 +0000

Transport Layer Security (TLS) is a cryptographic protocol designed to provide communications security over a computer network, such as the Internet. The protocol is widely used in applications such as email, instant messaging, and voice over IP, but its use in securing HTTPS remains the most publicly visible.

Redis® also supports TLS by design.

This article shows how to configure TLS in a Redis Cluster

Prerequisites

You have installed Redis Cluster in accordance with article Setup a Redis Cluster with using Redis Stack
You have been issued certificates for the servers of your cluster nodes

Configure Redis configuration files

On all nodes add following mandatory settings into redis_7000.conf file:

# By default, TLS/SSL is disabled. To enable it, the "tls-port" configuration
# directive can be used to define TLS-listening ports. To enable TLS on the default port, use:
#
port 0
tls-port 7000

# The cluster port is the port that the cluster bus will listen for inbound connections on. When set 
# to the default value, 0, it will be bound to the command port + 10000. Setting this value requires 
# you to specify the cluster bus port when executing cluster meet.
#
cluster-port 17000

# Configure a X.509 certificate and private key to use for authenticating the
# server to connected clients, masters or cluster peers.  These files should be PEM formatted.
#
tls-cert-file redis.crt
tls-key-file redis.key

# Configure a CA certificate(s) bundle or directory to authenticate TLS/SSL clients and peers.
#
tls-ca-cert-dir /etc/ssl/certs

# By default, clients (including replica servers) on a TLS port are required
# to authenticate using valid client side certificates.
# If "no" is specified, client certificates are not required and not accepted.
# If "optional" is specified, client certificates are accepted and must be
# valid if provided, but are not required.
#
tls-auth-clients yes

# By default, a Redis replica does not attempt to establish a TLS connection with its master.
# Use the following directive to enable TLS on replication links.
#
tls-replication yes

# By default, the Redis Cluster bus uses a plain TCP connection. To enable
# TLS for the bus protocol, use the following directive:
#
tls-cluster yes

# By default, only TLSv1.2 and TLSv1.3 are enabled and it is highly recommended
# that older formally deprecated versions are kept disabled to reduce the attack surface.
# You can explicitly specify TLS versions to support.
# Allowed values are case insensitive and include "TLSv1", "TLSv1.1", "TLSv1.2",
# "TLSv1.3" (OpenSSL >= 1.1.1) or any combination.
#
tls-protocols "TLSv1.2"

# Configure allowed ciphers.  See the ciphers(1ssl) manpage for more information about the syntax of this string.
# Note: this configuration applies only to <= TLSv1.2.
#
tls-ciphers DEFAULT:!MEDIUM

# When choosing a cipher, use the server's preference instead of the client
# preference. By default, the server follows the client's preference.
#
tls-prefer-server-ciphers yes

# Enable TLS session caching to allow faster and less expensive
# reconnections by clients that support it.
#
tls-session-caching yes

# Change the default number of TLS sessions cached. A zero value sets the cache
# to unlimited size. The default size is 20480.
#
tls-session-cache-size 20480

# Change the default timeout of cached TLS sessions. The default timeout is 300 seconds.
#
tls-session-cache-timeout 300

Apply same relevant mandatory settings in redis_7001.conf file:

port 0
tls-port 7001
cluster-port 17001

tls-cert-file redis.crt
tls-key-file redis.key
tls-ca-cert-dir /etc/ssl/certs

tls-auth-clients yes
tls-replication yes
tls-cluster yes

tls-protocols "TLSv1.2"
tls-ciphers DEFAULT:!MEDIUM
tls-prefer-server-ciphers yes

tls-session-caching yes
tls-session-cache-size 20480
tls-session-cache-timeout 300

Redis commands with TLS

Create a cluster:

$ redis-cli --cluster create \
    10.0.0.124:7000 10.0.0.125:7000 10.0.0.126:7000 \
    10.0.0.124:7001 10.0.0.125:7001 10.0.0.126:7001 \
    --cluster-replicas 1 --askpass \
    --tls --cert redis.crt --key redis.key

List the cluster nodes:

$ redis-cli -c -h 10.0.0.124 -p 7000 --askpass \
    --tls --cert redis.crt --key redis.key \
    cluster nodes

Check the cluster:

$ redis-cli --cluster check 10.0.0.124:7000 --askpass \
    --tls --cert redis.crt --key redis.key

Interactive mode:

$ redis-cli -c -h 10.0.0.124 -p 7000 --askpass \
    --tls --cert redis.crt --key redis.key

Comprehensive guide to

Ježek — Tue, 01 Apr 2025 09:35:24 +0000

Ježek

Mar 27 '25

Setup a Redis Cluster with using Redis Stack

#redis #devops

Comments 2

8 min read

Setup a Redis Cluster with using Redis Stack

Ježek — Thu, 27 Mar 2025 03:35:12 +0000

Redis® Cluster is a fully distributed implementation with automated sharding capabilities (horizontal scaling capabilities), designed for high performance and linear scaling up to 1000 nodes.

This article shows how to set up a Redis Cluster using Redis Stack.

Prerequisites

Linux preinstalled servers, e.g.:

Host name	IP
redis-1	10.0.0.124
redis-2	10.0.0.125
redis-3	10.0.0.126

Cluster topology:

redis-1	redis-2	redis-3
Primary M1 (port 7000)	Primary M2 (port 7000)	Primary M3 (port 7000)
Replica S3 (port 7001)	Replica S1 (port 7001)	Replica S2 (port 7001)

Setup Redis Cluster

Install and configure three Redis nodes of the cluster

Connect to all hosts.

Create the file /etc/yum.repos.d/redis.repo with the following contents:

[Redis]
name=Redis
baseurl=http://packages.redis.io/rpm/rhel9 # replace rhel7 with the appropriate value for your platform
enabled=1
gpgcheck=1

Run the following commands to install Redis Stack:

curl -fsSL https://packages.redis.io/gpg > /tmp/redis.key
sudo rpm --import /tmp/redis.key
sudo yum install epel-release
sudo yum install redis-stack-server
sudo systemctl disable redis-stack-server.service

Note: in order to start the redis-stack-server service, you may need to install the libssl module (e.g. libssl.so.10):

sudo yum compat-openssl10.x86-64

Create and edit the /etc/rc.local, add the following content to the file:

#!/bin/sh -e

echo never > /sys/kernel/mm/transparent_hugepage/enabled
sysctl -w net.core.somaxconn=65535

exit 0

Give executable permissions to the /etc/rc.local file by running the following command:
```
sudo chmod +x /etc/rc.local
```
Edit the /etc/sysctl.conf file, add the following line at the end of the file:
```
vm.overcommit_memory=1
```
Set ulimit values to ensure optimal compatibility and performance for Redis. Create the file /etc/security/limits.d/90-redis.conf with the following content:
```
@redis - nofile 20480
@redis - stack  10240
@redis - nproc  10240
```

Create the necessary folders by running the following commands:

sudo mkdir -p /etc/redis/cluster/{7000,7001}
sudo mkdir -p /var/lib/redis/{7000,7001}
sudo mkdir -p /var/{run,log}/redis

Create the file /etc/redis/cluster/7000/redis_7000.conf with the following content:

protected-mode no
port 7000
bind 0.0.0.0

loadmodule /opt/redis-stack/lib/rediscompat.so
loadmodule /opt/redis-stack/lib/redisearch.so
loadmodule /opt/redis-stack/lib/redistimeseries.so
loadmodule /opt/redis-stack/lib/rejson.so
loadmodule /opt/redis-stack/lib/redisbloom.so
loadmodule /opt/redis-stack/lib/redisgears.so v8-plugin-path /opt/redis-stack/lib/libredisgears_v8_plugin.so

dir /var/lib/redis/7000/
appendonly yes

cluster-enabled yes
cluster-node-timeout 5000
cluster-config-file /etc/redis/cluster/7000/nodes_7000.conf

pidfile /var/run/redis/redis_7000.pid
logfile /var/log/redis/redis_7000.log
loglevel notice

requirepass [ACCESSKEY]
masterauth [ACCESSKEY]

enable-debug-command local

Create the file /etc/redis/cluster/7001/redis_7001.conf with the following content:

protected-mode no
port 7001
bind 0.0.0.0

loadmodule /opt/redis-stack/lib/rediscompat.so
loadmodule /opt/redis-stack/lib/redisearch.so
loadmodule /opt/redis-stack/lib/redistimeseries.so
loadmodule /opt/redis-stack/lib/rejson.so
loadmodule /opt/redis-stack/lib/redisbloom.so
loadmodule /opt/redis-stack/lib/redisgears.so v8-plugin-path /opt/redis-stack/lib/libredisgears_v8_plugin.so

dir /var/lib/redis/7001/
appendonly yes

cluster-enabled yes
cluster-node-timeout 5000
cluster-config-file /etc/redis/cluster/7001/nodes_7001.conf

pidfile /var/run/redis/redis_7001.pid
logfile /var/log/redis/redis_7001.log
loglevel notice

requirepass [ACCESSKEY]
masterauth [ACCESSKEY]

enable-debug-command local

Create a redis user and a redis group for the Redis services and give them the correct permissions by running the following commands:

sudo chown redis:redis -R /var/lib/redis
sudo chmod 770 -R /var/lib/redis
sudo chown redis:redis -R /etc/redis
sudo chown redis:redis /var/{run,log}/redis

Create the file /etc/systemd/system/redis_7000.service with the following content:

[Unit]
Description=Redis key-value database on 7000
Wants=network-online.target
After=network-online.target

[Service]
ExecStart=/opt/redis-stack/bin/redis-server /etc/redis/cluster/7000/redis_7000.conf --daemonize no --supervised no
Type=simple
User=redis
Group=redis
RuntimeDirectory=redis
RuntimeDirectoryMode=0755

[Install]
WantedBy=multi-user.target

Create the file /etc/systemd/system/redis_7001.service with the following content:

[Unit]
Description=Redis key-value database on 7001
Wants=network-online.target
After=network-online.target

[Service]
ExecStart=/usr/bin/redis-server /etc/redis/cluster/7001/redis_7001.conf --daemonize no --supervised no
Type=simple
User=redis
Group=redis
RuntimeDirectory=redis
RuntimeDirectoryMode=0755

[Install]
WantedBy=multi-user.target

Tell systemd to start the two services redis_7000.service and redis_7001.service automatically at server boot by running the following commands:
```
sudo systemctl enable /etc/systemd/system/redis_7000.service
sudo systemctl enable /etc/systemd/system/redis_7001.service
```
Reboot the server:
```
sudo reboot
```

Validate the installation of the Redis services

Check the status of the redis_7000 and redis_7001 services by running the following command:

$ sudo systemctl status redis_7000
● redis_7000.service - Redis key-value database on 7000
 Loaded: loaded (/etc/systemd/system/redis_7000.service; enabled; vendor preset: disabled)
 Active: active (running) since Thu 2025-03-27 03:42:15 UTC; 22min ago
Main PID: 727 (redis-server)
  Tasks: 7 (limit: 4650)
 Memory: 18.9M
    CPU: 3.365s
 CGroup: /system.slice/redis_7000.service
         └─ 727 "/opt/redis-stack/bin/redis-server *:7000 [cluster]"

Check the redis_7000 and redis_7001 logs on all servers:

$ tail -n 3 /var/log/redis/redis_7000.log
727:M 27 Mar 2025 03:42:17.641 * DB loaded from append only file: 0.312 seconds
727:M 27 Mar 2025 03:42:17.641 * Opening AOF incr file appendonly.aof.1.incr.aof on server start
727:M 27 Mar 2025 03:42:17.642 * Ready to accept connections tcp

You shouldn't have any warnings in log files.

After checking that all servers are well configured, you can proceed with the Redis cluster configuration.

Set up the Redis Cluster

Configure the cluster

Connect to one of the Redis server.

To create a cluster run the following command:

$ redis-cli --cluster create \
    10.0.0.124:7000 10.0.0.125:7000 10.0.0.126:7000 \
    10.0.0.124:7001 10.0.0.125:7001 10.0.0.126:7001 \
    --cluster-replicas 1 -a [ACCESSKEY]

The output should be similar to the following:

>>> Performing hash slots allocation on 6 nodes...
Master[0] -> Slots 0 - 5460
Master[1] -> Slots 5461 - 10922
Master[2] -> Slots 10923 - 16383
Adding replica 10.0.0.125:7001 to 10.0.0.124:7000
Adding replica 10.0.0.126:7001 to 10.0.0.125:7000
Adding replica 10.0.0.124:7001 to 10.0.0.126:7000
M: 41b58d5cea81103d296ee70e31aa56dfa0f1aa30 10.0.0.124:7000
   slots:[0-5460] (5461 slots) master
M: 2ae13d480218fc91235bdc727c57edef941817a7 10.0.0.125:7000
   slots:[5461-10922] (5462 slots) master
M: 0848285de9827407af8ee8da81bcc645be57793c 10.0.0.126:7000
   slots:[10923-16383] (5461 slots) master
S: 779283793850c6c8a30425ae2ef780114585a64e 10.0.0.124:7001
   replicates 0848285de9827407af8ee8da81bcc645be57793c
S: b2fa3c3902639db13e0a245a4f08f8657a4d06ac 10.0.0.125:7001
   replicates 41b58d5cea81103d296ee70e31aa56dfa0f1aa30
S: 095098c7e15b2e1021e215abe0ace4fd0f841328 10.0.0.126:7001
   replicates 2ae13d480218fc91235bdc727c57edef941817a7
Can I set the above configuration? (type 'yes' to accept):

Type yes and press Enter to accept the proposed configuration.
You get the configuration details in the output:

Can I set the above configuration? (type 'yes' to accept): yes
>>> Nodes configuration updated
>>> Assign a different config epoch to each node
>>> Sending CLUSTER MEET messages to join the cluster
Waiting for the cluster to join
.
>>> Performing Cluster Check (using node 10.0.0.124:7000)
M: 41b58d5cea81103d296ee70e31aa56dfa0f1aa30 10.0.0.124:7000
slots:[0-5460] (5461 slots) master
1 additional replica(s)
M: 2ae13d480218fc91235bdc727c57edef941817a7 10.0.0.125:7000
slots:[5461-10922] (5462 slots) master
1 additional replica(s)
S: 095098c7e15b2e1021e215abe0ace4fd0f841328 10.0.0.126:7001
slots: (0 slots) slave
replicates 2ae13d480218fc91235bdc727c57edef941817a7
S: 779283793850c6c8a30425ae2ef780114585a64e 10.0.0.124:7001
slots: (0 slots) slave
replicates 0848285de9827407af8ee8da81bcc645be57793c
S: b2fa3c3902639db13e0a245a4f08f8657a4d06ac 10.0.0.125:7001
slots: (0 slots) slave
replicates 41b58d5cea81103d296ee70e31aa56dfa0f1aa30
M: 0848285de9827407af8ee8da81bcc645be57793c 10.0.0.126:7000
slots:[10923-16383] (5461 slots) master
1 additional replica(s)
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.

Checking the Redis Cluster

Run the following command:

redis-cli -c -h 10.0.0.124 -p 7000 -a [ACCESSKEY] cluster nodes

The output should be similar to the following:

2ae13d480218fc91235bdc727c57edef941817a7 10.0.0.125:7000@17000 master - 0 1743042394000 2 connected 5461-10922
095098c7e15b2e1021e215abe0ace4fd0f841328 10.0.0.126:7001@17001 slave 2ae13d480218fc91235bdc727c57edef941817a7 0 1743042394892 2 connected
779283793850c6c8a30425ae2ef780114585a64e 10.0.0.124:7001@17001 slave 0848285de9827407af8ee8da81bcc645be57793c 0 1743042394587 3 connected
b2fa3c3902639db13e0a245a4f08f8657a4d06ac 10.0.0.125:7001@17001 slave 41b58d5cea81103d296ee70e31aa56dfa0f1aa30 0 1743042394586 1 connected
41b58d5cea81103d296ee70e31aa56dfa0f1aa30 10.0.0.124:7000@17000 myself,master - 0 0 1 connected 0-5460
0848285de9827407af8ee8da81bcc645be57793c 10.0.0.126:7000@17000 master - 0 1743042393568 3 connected 10923-16383

Since everything looks OK, perform a several SET and GET commands to test if the Redis Cluster behaves as expected.

Connect to Redis Master:

redis-cli -c -h 10.0.0.124 -p 7000 -a [ACCESSKEY]

Run a several SET and GET commands to check the behavior of the Redis Cluster:
```
10.0.0.124:7000> SET foo bar
-> Redirected to slot [12182] located at 10.0.0.126:7000
OK
10.0.0.124:7000> GET foo
"bar"
```
As you can see the Redis sends the key to the correct hash slot.

Testing the failover

This section shows how to test the failover behavior of a Redis Cluster.

Master node failure

Run the following command on Master node:
```
redis-cli -c -h 127.0.0.0 -p 7000 -a [ACCESSKEY] DEBUG sleep 40
```
This command makes this Master unreachable by the replicas during 40 seconds, forcing the associated Replica (port 7001) on server redis-2 to take over and change its role to Master.

Check roles:

$ redis-cli -c -h 127.0.0.0 -p 7000 -a [ACCESSKEY] info replication
# Replication
role:slave
master_host:10.0.0.125
master_port:7001
...

$ redis-cli -c -h 10.0.0.125 -p 7000 -a [ACCESSKEY] info replication
# Replication
role:master
connected_slaves:1
slave0:ip=10.0.0.126,port=7001,state=online,offset=3410,lag=1

$ redis-cli -c -h 10.0.0.124 -p 7000 -a [ACCESSKEY] cluster nodes
41b58d5cea81103d296ee70e31aa56dfa0f1aa30 10.0.0.124:7000@17000 myself,slave b2fa3c3902639db13e0a245a4f08f8657a4d06ac 0 0 7 connected
2ae13d480218fc91235bdc727c57edef941817a7 10.0.0.125:7000@17000 master - 0 1743045119565 2 connected 5461-10922
0848285de9827407af8ee8da81bcc645be57793c 10.0.0.126:7000@17000 master - 0 1743045118000 3 connected 10923-16383
779283793850c6c8a30425ae2ef780114585a64e 10.0.0.124:7001@17001 slave 0848285de9827407af8ee8da81bcc645be57793c 0 1743045119564 3 connected
b2fa3c3902639db13e0a245a4f08f8657a4d06ac 10.0.0.125:7001@17001 master - 0 1743045119053 7 connected 0-5460
095098c7e15b2e1021e215abe0ace4fd0f841328 10.0.0.126:7001@17001 slave 2ae13d480218fc91235bdc727c57edef941817a7 0 1743045118035 2 connected

From the output, you can see that the Replica running in redis-2 got promoted to Master.

Replica node failure

Run the following command on Replica in server redis-3:

redis-cli -c -h 127.0.0.0 -p 7001 -a [ACCESSKEY] DEBUG sleep 40

Check roles in the cluster:

redis-cli -c -h 10.0.0.126 -p 7000 -a [ACCESSKEY] cluster nodes
41b58d5cea81103d296ee70e31aa56dfa0f1aa30 10.0.0.124:7000@17000 slave b2fa3c3902639db13e0a245a4f08f8657a4d06ac 0 1743046096000 7 connected
779283793850c6c8a30425ae2ef780114585a64e 10.0.0.124:7001@17001 slave 0848285de9827407af8ee8da81bcc645be57793c 0 1743046097459 3 connected
2ae13d480218fc91235bdc727c57edef941817a7 10.0.0.125:7000@17000 master - 0 1743046097900 2 connected 5461-10922
b2fa3c3902639db13e0a245a4f08f8657a4d06ac 10.0.0.125:7001@17001 master - 0 1743046096395 7 connected 0-5460
0848285de9827407af8ee8da81bcc645be57793c 10.0.0.126:7000@17000 myself,master - 0 0 3 connected 10923-16383
095098c7e15b2e1021e215abe0ace4fd0f841328 10.0.0.126:7001@17001 slave 2ae13d480218fc91235bdc727c57edef941817a7 0 1743046095519 2 connected

As you can see, the cluster topology isn't changed.

Congrats! You have configured the Redis Cluster.

Summary

In this post, we have seen:

how to install the Redis Stack Server
how to set up the Redis Cluster
hot to test the failover of a cluster.

References

Setup a Docker Swarm cluster using Vagrant

Ježek — Mon, 21 Oct 2024 23:48:00 +0000

Docker includes Swarm mode for natively managing a cluster of Docker Engines called a swarm.

There is excellent tutorial Getting started with Swarm mode, this tutorial describes how to create docker swarm cluster with 1 manager and 2 worker nodes.

This article shows how to setup high-availability (HA) Docker Swarm cluster using Vagrant.

Preconditions

You have a computer with at least 12 GB of free RAM
You have installed Vagrant on this computer
Install a virtualization product such as VirtualBox

Setup

Initialize a project directory

Make a new directory for the project you will work:

$ mkdir docker-swarm-ha
$ cd docker-swarm-ha

Inventory file

Create an inventory.yaml file in your current directory, and open the file in you favorite editor:

$ touch inventory.yaml
# vim inventory.yaml

Fill the file like this one:

---
- role: Manager
  availability: drain
  hostname: manager-1
  ip: 192.168.100.10
  image: centos/8
  ram: 2048
  cpus: 1
- role: Manager
  availability: drain
  hostname: manager-2
  ip: 192.168.100.11
  image: centos/8
  ram: 2048
  cpus: 1
- role: Manager
  availability: drain
  hostname: manager-3
  ip: 192.168.100.12
  image: centos/8
  ram: 2048
  cpus: 1
- role: Worker
  availability: active
  hostname: worker-1
  ip: 192.168.100.13
  image: centos/8
  ram: 4096
  cpus: 1
- role: Worker
  availability: active
  hostname: worker-2
  ip: 192.168.100.14
  image: centos/8
  ram: 4096
  cpus: 1
- role: Worker
  availability: active
  hostname: worker-3
  ip: 192.168.100.15
  image: centos/8
  ram: 4096
  cpus: 1

This is inventory file of your docker swarm cluster with relevant virtual machine (VM) characteristics.

Vagrant file

Create a Vagrantfile in your current directory, and open the file in you favorite editor:

$ touch Vagrantfile
# code .

Now, it's time to code Vagrantfile using Ruby language...

On top of the file add following code

# -*- mode: ruby -*-
# vi: set ft=ruby :

require 'yaml'

current_dir = File.dirname(File.expand_path(__FILE__))
servers = YAML.load_file("#{current_dir}/inventory.yaml")
leader = servers.find { |favor| favor['hostname'] == 'manager-1' }

group = "Docker Swarm"

Here, we load the inventory file, and then we define a leader node in the cluster. This node is used to initialize docker swarm.
Also we defined Docker Swarm as a group of VMs in VirtualBox GUI.

Add Vagrant configuration below

Vagrant.configure("2") do |config|

end

The "2" in Vagrant.configure configures the configuration version.
Inside this block is the place where the main code will be placed.

Define all VMs in accordance with inventory file

  servers.each do |machine|
    config.vm.define machine['hostname'] do |node|
        node.vm.box = machine['image']
        node.vm.hostname = machine['hostname']
        node.vm.network :private_network, ip: machine['ip']
        node.vm.provider :virtualbox do |vb|
          vb.customize ["modifyvm", :id, "--groups", "/#{group}/#{machine['role']}"]
          vb.name = machine['hostname']
          vb.memory = machine['ram']
          vb.cpus = machine['cpus']
        end
    end
  end

Define hosts file on all VMs

  servers.each do |machine|
    config.vm.provision "Setup hosts", type: :shell, :args => [machine['ip'], machine['hostname']], inline: <<-SHELL
      sudo echo "$1  $2"  >> /etc/hosts
    SHELL
  end

Setup Linux package repositories

  config.vm.provision "Setup repositories", type: :shell, privileged: true, inline: <<-SHELL
    sed -i s/mirror.centos.org/vault.centos.org/g /etc/yum.repos.d/CentOS-*.repo
    sed -i s/^mirrorlist=http/#mirrorlist=http/g /etc/yum.repos.d/CentOS-*.repo
    sed -i s/^#.*baseurl=http/baseurl=http/g /etc/yum.repos.d/CentOS-*.repo
    yum clean all
  SHELL

Install Docker Engine on all VMs

config.vm.provision "Install Docker", type: :docker

Install Redis as a cache in docker container

  config.vm.provision "Run Redis cache", type: :docker do |d|
    d.run "redis",
      cmd: "--bind 0.0.0.0",
      args: "-p 0.0.0.0:6379:6379"
  end

In our case, Redis cache is used to temporary store docker swarm join tokens.

Initialize docker swarm

  config.vm.define "manager-1" do |node|
    node.vm.provision "Swarm init", type: :shell, privileged: true, :args => [leader['ip'], leader['availability']],
      inline: "docker swarm init --advertise-addr $1 --availability $2 || true"

    node.vm.provision "Save join-tokens", type: :shell, privileged: true,
      inline: <<-SHELL
        docker exec redis redis-cli set manager-join-token $(docker swarm join-token manager -q)
        docker exec redis redis-cli set worker-join-token $(docker swarm join-token worker -q)
      SHELL
  end

As you can see above, join tokens are saved into Redis cache.

And finally join all VMs to the docker swarm cluster

  servers.select { |favor| favor['hostname'] != 'manager-1' }.each do |machine|
    config.vm.define machine['hostname'] do |node|
      node.vm.provision "Add a #{machine['role']} to the swarm", type: :shell, privileged: true, 
        :args => [leader['ip'], machine['role'].downcase, machine['availability']],
        inline: <<-SHELL
          token=$(docker exec redis redis-cli -h $1 get $2-join-token)
          docker swarm join --availability $3 --token $token $1 || true
        SHELL
    end
  end

Boot an environment

Bring up a virtual machine

Run the following from your terminal:

$ vagrant up

This command will finish and you will have VMs running with docker swarm.

Check swarm nodes

Connect to a master node using SSH:

$ vagrant ssh manager-1
[vagrant@manager-1 ~]$

Finally, verify the status of the cluster nodes using the following command:

[vagrant@manager-1 ~]$ docker node ls
ID                            HOSTNAME    STATUS    AVAILABILITY   MANAGER STATUS   ENGINE VERSION
illxi93is8446ghgl86lihg1f *   manager-1   Ready     Drain          Leader           26.1.3
es0ktcmq5d9403p16b688knat     manager-2   Ready     Drain          Reachable        26.1.3
j1wnwxnysm763eex9r024h8if     manager-3   Ready     Drain          Reachable        26.1.3
comemxromzh4y8a6ciou6smk8     worker-1    Ready     Active                          26.1.3
smz5sf6vdbzszc850zxwddfie     worker-2    Ready     Active                          26.1.3
p7r1khx4h8famoi9fb0itx8kg     worker-3    Ready     Active                          26.1.3

VirualBox GUI

Now VirualBox GUI should looks like this:

Deploy a service

In order to verify that everything is OK, we will deploy the simplest docker service to a swarm:

$ docker service create --name my_web \
                        --replicas 3 \
                        --publish published=8080,target=80 \
                        nginx:latest

The service is scheduled on available nodes. To confirm that the service was created and started successfully, use the docker service ls command:

[vagrant@manager-1 ~]$ docker service create --name my_web \
>                         --replicas 3 \
>                         --publish published=8080,target=80 \
>                         nginx:latest
s3vgnoaca0p14jgd27ag52th4
overall progress: 3 out of 3 tasks
1/3: running   [==================================================>]
2/3: running   [==================================================>]
3/3: running   [==================================================>]
verify: Service s3vgnoaca0p14jgd27ag52th4 converged
[vagrant@manager-1 ~]$ docker service ls
ID             NAME      MODE         REPLICAS   IMAGE          PORTS
s3vgnoaca0p1   my_web    replicated   3/3        nginx:latest   *:8080->80/tcp

Now, you may open just deployed nginx service in web browser using one of the VM's IP:

Cleanup

To delete docker service, use the docker service rm command:

[vagrant@manager-1 ~]$ docker service rm my_web
my_web
[vagrant@manager-1 ~]$ docker service ls
ID        NAME      MODE      REPLICAS   IMAGE     PORTS

To stop VMs that Vagrant is managing and remove all the resources created during the machine-creation process, use the vagrant destroy command:

$ vagrant destroy
    worker-3: Are you sure you want to destroy the 'worker-3' VM? [y/N]

To gracefully shut down the VMs, use the vagrant halt command:

$ vagrant halt
==> worker-3: Attempting graceful shutdown of VM...
==> worker-2: Attempting graceful shutdown of VM...
==> worker-2: Forcing shutdown of VM...
==> worker-1: Attempting graceful shutdown of VM...
==> manager-3: Attempting graceful shutdown of VM...
==> manager-2: Attempting graceful shutdown of VM...
==> manager-1: Attempting graceful shutdown of VM...

Summary

In this post, we’ve seen:

how to easily setup high-availability (HA) Docker Swarm cluster using Vagrant
how to deploy docker service to a swarm cluster
how to clean up environment.

The codebase for this article can be found here.

Run Ansible on Windows without WSL

Ježek — Wed, 25 Sep 2024 11:47:49 +0000

Can Ansible run on Windows?
There is the simple, uncomplicated answer in ansible.com:

No, Ansible can only manage Windows hosts. Ansible cannot run on a Windows host natively, though it can run under the Windows Subsystem for Linux (WSL).

My friend, now I going to show you how you can run Ansible without WSL. Go ahead!

First of all in order to run Ansible on Windows without WSL you have to install Cygwin.

Once you have installed Cygwin for Windows you should to install relevant Cygwin packages for Ansible.

Install from the Internet

This is the easiest way to install Cygwin packages.

Run cygwin-setup-x86_64.exe:
Press Next
Choose Install from Internet, and press twice Next:
Select a local package directory, and press Next:
Select appropriate connection type, and press Next:
Choose appropriate download site, and press Next:
Select ansible and required for you packages, then press twice Next:
Wait for installation succeed
Run installed Cygwin64 Terminal, and check ansible version:
```
$ ansible --version
ansible 2.8.4
```

Test whether ansible is working correctly:

$ ansible 127.0.0.1  -m shell -a 'echo Hello world!'
127.0.0.1 | CHANGED | rc=0 >>
Hello world!

Congrats, my friend, you have installed Ansible on Windows without WSL!

Install from the local directory (portable)

This installation option is useful for those who do not have Internet access.

First of all, you have to archive a folder where you have installed cygwin packages (in my case: c:\cygwin-packages\)
Copy cygwin-setup-x86_64.exe and the archive to a computer w/o Internet access
Extract archive to appropriate folders
Run cygwin-setup-x86_64.exe, and press Next
Choose Install from Local Directory, and press twice Next:
Select a local package directory where you have extracted the archive with packages, and press Next:
Select ansible and required for you packages, then press twice Next:
Wait for installation succeed
Run installed Cygwin64 Terminal, and check ansible version:
```
$ ansible --version
ansible 2.8.4
```

Test whether ansible is working correctly:

$ ansible 127.0.0.1  -m shell -a 'echo Hello world!'
127.0.0.1 | CHANGED | rc=0 >>
Hello world!

Congrats, my friend, you have installed Ansible on Windows without WSL and Internet access on a computer!

Summary

In this post, we have seen:

how to install Ansible on Windows w/o WSL using Internet access
how to install Ansible on Windows w/o WSL and w/o Internet access

I hope this post was useful for you.
See you soon!

Set up Redis diskless replication

Ježek — Tue, 24 Sep 2024 20:16:12 +0000

If you are building a production-grade application and your application uses Redis database (RDB) then you should replicate your data, so that in case of any disaster for your master data you can still use the replicated data.

Redis provides replication in two ways:

Master-Slave replication
Redis Cluster Replication

The most basic form of replication in Redis is Master-Slave replication. Data from the Master node is replicated to one or more Slave nodes (Replicas). Replicas can serve read operations, but all write operations are performed on the Master.

Master-Slave replication is a method of replicating RDB in order to improve performance and redundancy. The system has a Master that acts as the interface to the outside world, handling all external read and write requests. Whenever a change is made to the Master RDB, the change is propagated to the Replica connected to the Master. Master-Slave replication can be synchronous (in which changes to the replica RDB are made instantaneously) or asynchronous (in which changes are made only after some time).

The use cases of Master-Slave replication include:

Improving performance by scaling out the workload to multiple slave RDB.
Creating backups from the replica RDB, without disrupting the master RDB.
Running BI and analytics workloads on the slave RDB, without disrupting the master RDB.

By default, Master-Slave replication in Redis is asynchronous. Redis Master-Slave replication is non-blocking, which means that the Master can continue to operate while the Replica synchronize the data. In addition, Replica will be able to handle queries using the out-of-date version of the RDB, except for a brief period during which the new data is loaded.

Redis Replicas are able to perform a partial resynchronization with the Master if the replication link is lost for a relatively small amount of time. New Replicas and reconnecting Replicas that are not able to continue the replication process just receiving differences, need to do what is called a "full synchronization". An RDB file is transmitted from the Master to the Replicas.

The transmission can happen in two different ways:

disk-backed: the Master creates a new process redis-rdb-bgsave that writes the RDB file on disk. Later the file is transferred by the parent process redis-server to the Replicas incrementally.
diskless: the Master creates a new process redis-rdb-to-slaves that directly writes the RDB file to replica sockets, without touching the disk at all.

With slow disks and fast (large bandwidth) networks, diskless replication works better: this can provide faster synchronization times.

The problem

In order to persist the RDB on disk you have to define save directives in redis.conf configuration file, also you can run BGSAVE command manually.

According to Redis RDB disadvantages:

RDB needs to fork() often in order to persist on disk using a child process. fork() can be time consuming if the dataset is big, and may result in Redis stopping serving clients for some milliseconds or even for one second if the dataset is very big and the CPU performance is not great.

The name of the child process is redis-rdb-bgsave.

According to the Linux man page:

fork() creates a new process by duplicating the calling process. The new process, referred to as the child, is an exact duplicate of the calling process, referred to as the parent. Under Linux, fork() is implemented using copy-on-write pages, so the only penalty that it incurs is the time and memory required to duplicate the parent's page tables, and to create a unique task structure for the child.

Thus, fork() can cause the Master to freeze when performing BGSAVE, the related problem is described in the issue #9503 and antirez blog posts #83, #84.

The diskless replication is an option to mitigate the problem.

Prerequisites

You have installed Redis with Sentinel in accordance with article Set up a Redis Sentinel

Configuring the diskless replication

In order to disable forking the child process redis-rdb-bgsave you have to disable RDB persistence by commenting out all "save" lines in /etc/redis/redis.conf on all nodes:
```
# save 900 1
# save 300 10
# save 60 10000
```
To enable the diskless replication set following mandatory parameters on all nodes:
```
repl-diskless-sync yes
repl-diskless-sync-delay 5
repl-diskless-load on-empty-db
```
repl-diskless-sync-delay 5: the delay in seconds the server waits in order to spawn the child that transfers the RDB via socket to the replicas.
repl-diskless-load on-empty-db: use diskless loading the RDB directly from the socket only when it is completely safe for Replica.

When the diskless replication is enabled there are several scenarios could occur:

Slave node is rebooted:

This scenario is not abnormal. After Slave node rebooted Master performs "full synchronization" with Replica.
Master node is powered off:

This scenario is also not abnormal as well, because of sometimes shutting down a node is required for a long time due to maintenance tasks. In this case, Sentinel promotes Replica node to Master, and Replica's RDB in memory remains the same as before the failover.

After the old Master node is loaded, it will become a Replica and "full synchronization" will be performed in accordance with Scenario #1
The process "redis-server" has been killed on Master node

This scenario is dangerous because of the risk of data loss on all nodes as described in antirez blog post #80.

To eliminate the possibility of the dangerous scenario #3, it is necessary to add a delay before starting the 'redis-server' process on the Master node so that Sentinel would promote one of the Replicas to Master:

Save the following bash-script on all nodes as redis-wait-for-slave-role.sh to the folder /usr/local/bin/:

#!/bin/bash

if [[ $# -ne 2 ]]; then
  echo "Illegal number of parameters" >&2
  exit 2
fi

IFS=","
TIME_OUT_COMMAND=5s

redis_conf_path="$1"
hosts_ip="$2"

my_ip=$(hostname --ip-address)
password=$(awk '/^requirepass/ {print $2}' $redis_conf_path | tr -d '\"')

get_role() {
  echo -n "Getting a role from the node '$host' ... "  1>&2
  local role=$(timeout $TIME_OUT_COMMAND \
               redis-cli -h $host -p 6379 --pass $password --no-auth-warning info replication | \
               awk '/^role/ {split($0,a,":");print a[2]}' | \
               tr -d '\r')
  echo $role 1>&2
  echo $role
}

while :; do
  for host in $hosts_ip; do
    if [ $host != $my_ip ]; then
      role=$(get_role)
      if [ "$role" = 'master' ]; then
        break 2
      fi
    fi 
  done

  sleep 1
done

Make the file executable:

$ sudo chmod +x /usr/local/bin/redis-wait-for-slave-role.sh

Run the following command on all nodes:

$ sudo systemctl edit redis-server.service

Add new Service section:
```
[Service]
ExecStartPre=/usr/local/bin/redis-wait-for-slave-role.sh  /etc/redis/redis.conf 10.0.0.21,10.0.0.22,10.0.0.23
TimeoutStartSec=infinity
```
10.0.0.21,10.0.0.22,10.0.0.23: IPs of Master and Slave nodes
TimeoutStartSec=infinity: if you are using a version of systemd older than 229, you will need to use 0 instead of infinity to disable the timeout.

Restart redis-server service on all Slave nodes only:

$ sudo systemctl restart redis-server.service

Check redis-server service started:

$ sudo systemctl status redis-server.service
● redis-server.service - Advanced key-value store
 Loaded: loaded (/lib/systemd/system/redis-server.service; enabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/redis-server.service.d
         └─override.conf
 Active: active (running) since Tue 2024-09-24 14:53:07 MSK; 17s ago
   Docs: http://redis.io/documentation,
         man:redis-server(1)
Process: 390540 ExecStartPre=/usr/local/bin/redis-wait-for-slave-role.sh /etc/redis/redis.conf 10.0.0.21,10.0.0.22,10.0.0.23 (code=exited, status=0/SUCCESS)
Main PID: 390549 (redis-server)
 Status: "MASTER <-> REPLICA sync: Finished with success. Ready to accept connections in read-write mode."
  Tasks: 5 (limit: 7057)
 Memory: 2.2G
    CPU: 6.536s
 CGroup: /system.slice/redis-server.service
         └─390549 /usr/bin/redis-server 0.0.0.0:6379    
Sep 24 14:53:06 redis-3 systemd[1]: Starting Advanced key-value store...
Sep 24 14:53:06 redis-3 redis-wait-for-slave-role.sh[390543]: Getting a role from the node '10.0.0.21' ... master
Sep 24 14:53:07 redis-3 systemd[1]: Started Advanced key-value store.

Restart redis-server service on the old Master node:

$ sudo systemctl restart redis-server.service

Check redis-server service started:

$ sudo systemctl status redis-server.service
● redis-server.service - Advanced key-value store
 Loaded: loaded (/lib/systemd/system/redis-server.service; enabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/redis-server.service.d
         └─override.conf
 Active: active (running) since Tue 2024-09-24 14:58:33 MSK; 6min ago
   Docs: http://redis.io/documentation,
         man:redis-server(1)
Process: 27935 ExecStartPre=/usr/local/bin/redis-wait-for-slave-role.sh /etc/redis/redis.conf 10.0.0.21,10.0.0.22,10.0.0.23 (code=exited, status=0/SUCCESS)
Main PID: 28014 (redis-server)
 Status: "MASTER <-> REPLICA sync: Finished with success. Ready to accept connections in read-write mode."
  Tasks: 5 (limit: 7057)
 Memory: 2.2G
    CPU: 9.343s
 CGroup: /system.slice/redis-server.service
         └─28014 /usr/bin/redis-server 0.0.0.0:6379
Sep 24 14:58:16 redis-1 redis-wait-for-slave-role.sh[27969]: Getting a role from the node '10.0.0.22' ... slave
Sep 24 14:58:19 redis-1 redis-wait-for-slave-role.sh[27976]: Getting a role from the node '10.0.0.23' ... slave
Sep 24 14:58:25 redis-1 redis-wait-for-slave-role.sh[27984]: Getting a role from the node '10.0.0.22' ... slave
Sep 24 14:58:25 redis-1 redis-wait-for-slave-role.sh[27991]: Getting a role from the node '10.0.0.23' ... slave
Sep 24 14:58:31 redis-1 redis-wait-for-slave-role.sh[27999]: Getting a role from the node '10.0.0.22' ... slave
Sep 24 14:58:31 redis-1 redis-wait-for-slave-role.sh[28007]: Getting a role from the node '10.0.0.23' ... master
Sep 24 14:58:33 redis-1 systemd[1]: Started Advanced key-value store.

Testing the failover

This section shows to test the failover of the high availability Redis using Sentinel with enabled diskless replication.

Find new Master node by running the following command on a Sentinel node:

$ redis-cli -p 26379 --askpass sentinel get-master-addr-by-name mymaster
Please input password: ****************
1) "10.0.0.23"
2) "6379"

Set new test key in Master:

$ redis-cli -h 10.0.0.23 -p 6379 --askpass set test_key Hello!
Please input password: ****************
OK

Check the value of this key on all Replicas:

$ redis-cli -h 10.0.0.21 -p 6379 --askpass get test_key
Please input password: ****************
"Hello!"
$ redis-cli -h 10.0.0.22 -p 6379 --askpass get test_key
Please input password: ****************
"Hello!"

Execute the failover manually running following command:

$ redis-cli -p 26379 --askpass sentinel failover mymaster
Please input password: ****************
OK

Find new Master node by running the following command on a Sentinel node:

$ redis-cli -p 26379 --askpass sentinel get-master-addr-by-name mymaster
Please input password: ****************
1) "10.0.0.21"
2) "6379"

Check the value of the test key on the new Master and all Replicas:

$ redis-cli -h 10.0.0.21 -p 6379 --askpass get test_key
Please input password: ****************
"Hello!"
$ redis-cli -h 10.0.0.22 -p 6379 --askpass get test_key
Please input password: ****************
"Hello!"
$ redis-cli -h 10.0.0.23 -p 6379 --askpass get test_key
Please input password: ****************
"Hello!"

Delete the RDB file on the Master node (don't do this on production environment):
```
$ rm /var/lib/redis/dump.rdb 
```
Kill the redis-server process on the Master node:
```
pkill 'redis-server'
```

Wait for the redis-server process to start:

$ systemctl status redis-server.service 
● redis-server.service - Advanced key-value store
 Loaded: loaded (/lib/systemd/system/redis-server.service; enabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/redis-server.service.d
         └─override.conf
 Active: active (running) since Tue 2024-09-24 21:42:13 MSK; 23s ago
   Docs: http://redis.io/documentation,
         man:redis-server(1)
Process: 63631 ExecStartPre=/usr/local/bin/redis-wait-for-slave-role.sh /etc/redis/redis.conf 10.0.0.21,10.0.0.22,10.0.0.23 (code=exited, status=0/SUCCESS)
Main PID: 64578 (redis-server)
 Status: "Ready to accept connections"
  Tasks: 5 (limit: 7057)
 Memory: 69.1M
    CPU: 1.163s
 CGroup: /system.slice/redis-server.service
         └─64578 /usr/bin/redis-server 0.0.0.0:6379

Check the value of the test key on the new Master and all Replicas:

$ redis-cli -h 10.0.0.21 -p 6379 --askpass get test_key
Please input password: ****************
"Hello!"
$ redis-cli -h 10.0.0.22 -p 6379 --askpass get test_key
Please input password: ****************
"Hello!"
$ redis-cli -h 10.0.0.23 -p 6379 --askpass get test_key
Please input password: ****************
"Hello!"

Summary

The concept of replication without persistence is obviously impressive and causes anxiety and even wariness. Supporting diskless replication removes undesirable side-effect of disks (since disk I/O is slow and lazy), also it eliminates heavy forking a child process, being used for RDB persistence, with large datasets in memory.

Set up a Redis Sentinel

Ježek — Wed, 18 Sep 2024 21:59:49 +0000

Redis® Sentinel provides high availability for Redis. Redis Sentinel also provides other collateral tasks such as monitoring, notifications and acts as a configuration provider for clients.

This article shows how to set up a high-availability architecture for Redis using Sentinel in Debian GNU/Linux:

Prerequisites

Debian preinstalled servers, e.g.:

Host name	IP	Role
redis-1	10.0.0.21	Master node
redis-2	10.0.0.22	Slave node
redis-3	10.0.0.23	Slave node
sentinel-1	10.0.0.24	Sentinel node
sentinel-2	10.0.0.25	Sentinel node
sentinel-3	10.0.0.26	Sentinel node

Setup Redis replication

Install Redis

Connect to hosts with roles: Master node, Slave node

Run the following commands:

$ sudo apt-get update
$ sudo apt-get install -y redis-server

Activate the redis-server service to start when Redis server boots:
```
$ sudo systemctl enable redis-server
```

Check redis-server status:

$ systemctl status redis-server
● redis-server.service - Advanced key-value store
 Loaded: loaded (/lib/systemd/system/redis-server.service; enabled; vendor >
 Active: active (running) since Mon 2024-09-16 21:06:13; 19min ago
   Docs: http://redis.io/documentation,
         man:redis-server(1)
Main PID: 3057 (redis-server)
 Status: "Ready to accept connections"
  Tasks: 5 (limit: 2307)
 Memory: 9.2M
    CPU: 2.146s
 CGroup: /system.slice/redis-server.service
         └─3057 /usr/bin/redis-server 127.0.0.1:6379

Service runs and ready to accept connections.

Set up the Master node

Open the configuration file at /etc/redis/redis.conf

Set following mandatory parameters:

protected-mode yes
bind <masterip: 10.0.0.21> 127.0.0.1
requirepass <master-password>
masterauth <master-password>

Restart the redis-server service:
```
$ sudo systemctl restart redis-server
```
Make sure that Redis accepts connections with authentication:
```
$ redis-cli --askpass info
```

Set up the Slave nodes

Open the configuration file at /etc/redis/redis.conf

Set following mandatory parameters:

bind <slaveip: 10.0.0.21/22> 127.0.0.1
requirepass <master-password>
masterauth <master-password>
replicaof <masterip: 10.0.0.21> 6379

Restart the redis-server service:
```
$ sudo systemctl restart redis-server
```
Make sure that Redis accepts connections with authentication:
```
$ redis-cli --askpass info
```

Check Redis replication setup

Check the redis-server log on Master node:

$ tail /var/log/redis/redis-server.log -n 20
3498:M 16 Sep 2024 22:25:53.086 * RDB memory usage when created 0.77 Mb
3498:M 16 Sep 2024 22:25:53.086 * DB loaded from disk: 0.000 seconds
3498:M 16 Sep 2024 22:25:53.086 * Ready to accept connections
3498:M 16 Sep 2024 23:29:52.119 * Replica 10.0.0.22:6379 asks for synchronization
3498:M 16 Sep 2024 23:29:52.119 * Full resync requested by replica 10.0.0.22:6379
3498:M 16 Sep 2024 23:29:52.119 * Replication backlog created, my new replication IDs are '368571d1e52c29535615e0043a3a6d6ddc1db70b' and '0000000000000000000000000000000000000000'
3498:M 16 Sep 2024 23:29:52.119 * Starting BGSAVE for SYNC with target: disk
3498:M 16 Sep 2024 23:29:52.119 * Background saving started by pid 3684
3684:C 16 Sep 2024 23:29:52.132 * DB saved on disk
3684:C 16 Sep 2024 23:29:52.133 * RDB: 0 MB of memory used by copy-on-write
3498:M 16 Sep 2024 23:29:52.185 * Background saving terminated with success
3498:M 16 Sep 2024 23:29:52.185 * Synchronization with replica 10.0.0.22:6379 succeeded
3498:M 16 Sep 2024 23:30:09.952 * Replica 10.0.0.23:6379 asks for synchronization
3498:M 16 Sep 2024 23:30:09.952 * Full resync requested by replica 10.0.0.23:6379
3498:M 16 Sep 2024 23:30:09.952 * Starting BGSAVE for SYNC with target: disk
3498:M 16 Sep 2024 23:30:09.952 * Background saving started by pid 3688
3688:C 16 Sep 2024 23:30:09.965 * DB saved on disk
3688:C 16 Sep 2024 23:30:09.965 * RDB: 0 MB of memory used by copy-on-write
3498:M 16 Sep 2024 23:30:09.985 * Background saving terminated with success
3498:M 16 Sep 2024 23:30:09.985 * Synchronization with replica 10.0.0.23:6379 succeeded

Check replication status on Master node:

$ redis-cli --askpass info replication
Please input password: ****************
# Replication
role:master
connected_slaves:2
slave0:ip=10.0.0.22,port=6379,state=online,offset=1652,lag=1
slave1:ip=10.0.0.23,port=6379,state=online,offset=1652,lag=1
master_replid:368571d1e52c29535615e0043a3a6d6ddc1db70b
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:1652
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:1652

Run the following command on Master node:

$ $ redis-cli --askpass set abc 123
Please input password: ****************
OK

Run the following command on Slave nodes:

$ redis-cli --askpass get abc
Please input password: ****************
"123"

Congrats! Master-to-Slave data replication succeed.

Setup Redis Sentinel

Install Redis Sentinel

Connect to hosts with the role Sentinel

Run the following commands:

$ sudo apt-get update
$ sudo apt-get install -y redis-sentinel

Activate the redis-sentinel service to start when Sentinel server boots:
```
$ sudo systemctl enable redis-sentinel
```

Check redis-sentinel status:

$ systemctl status redis-sentinel
● redis-sentinel.service - Advanced key-value store
 Loaded: loaded (/lib/systemd/system/redis-sentinel.service; enabled; vendo>
 Active: active (running) since Tue 2024-09-17 00:56:22 MSK; 1min 29s ago
   Docs: http://redis.io/documentation,
         man:redis-sentinel(1)
Main PID: 3259 (redis-sentinel)
 Status: "Ready to accept connections"
  Tasks: 5 (limit: 2307)
 Memory: 7.2M
    CPU: 190ms
 CGroup: /system.slice/redis-sentinel.service
         └─3259 /usr/bin/redis-sentinel 127.0.0.1:26379 [sentinel]

Set up Sentinel nodes

Open the configuration file at /etc/redis/sentinel.conf

Set following mandatory parameters:

protected-mode yes
bind <sentinelip: 10.0.0.24/25/26> 127.0.0.1
sentinel monitor mymaster <masterip: 10.0.0.21> 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1
sentinel auth-pass mymaster <master-password>
requirepass <sentinel-password>

Restart the redis-sentinel service:

$ sudo systemctl restart redis-sentinel

Make sure that Redis Sentinel accepts connections with authentication:

$ redis-cli -p 26379 --askpass info sentinel
Please input password: ****************
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=10.0.0.21:6379,slaves=2,sentinels=3

Testing the failover

This section shows how to test the failover of the high availability Redis using Sentinel.

Master node failure

Run the following command on Master node:
```
$ redis-cli --askpass client pause 40000
Please input password: ****************
OK
```
Note: client pause 40000 due to sentinel down-after-milliseconds mymaster 30000

Run the following command on one of the Sentinel nodes:

$ tail -10 /var/log/redis/redis-sentinel.log
6175:X 18 Sep 2024 21:39:49.309 # +sdown master mymaster 10.0.0.21 6379
6175:X 18 Sep 2024 21:39:49.555 # +new-epoch 1
6175:X 18 Sep 2024 21:39:49.558 # +vote-for-leader 77fc4fbc9c6c7d063d62e38f528910ab67e8d907 1
6175:X 18 Sep 2024 21:39:50.450 # +odown master mymaster 10.0.0.21 6379 #quorum 3/2
6175:X 18 Sep 2024 21:39:50.451 # Next failover delay: I will not start a failover before Wed Sep 18 21:45:50 2024
6175:X 18 Sep 2024 21:39:51.853 # +config-update-from sentinel 77fc4fbc9c6c7d063d62e38f528910ab67e8d907 10.0.0.26 26379 @ mymaster 10.0.0.21 6379
6175:X 18 Sep 2024 21:39:51.853 # +switch-master mymaster 10.0.0.21 6379 10.0.0.22 6379
6175:X 18 Sep 2024 21:39:51.853 * +slave slave 10.0.0.23:6379 10.0.0.23 6379 @ mymaster 10.0.0.22 6379
6175:X 18 Sep 2024 21:39:51.853 * +slave slave 10.0.0.21:6379 10.0.0.21 6379 @ mymaster 10.0.0.22 6379
6175:X 18 Sep 2024 21:40:09.323 * +convert-to-slave slave 10.0.0.21:6379 10.0.0.21 6379 @ mymaster 10.0.0.22 6379

Note: Next failover delay: I will not start a failover before Wed Sep 18 21:45:50 2024 due to sentinel failover-timeout mymaster 180000

Run the following command on one of the Sentinel nodes:

$ redis-cli -p 26379 --askpass sentinel get-master-addr-by-name mymaster
Please input password: ****************
1) "10.0.0.22"
2) "6379"

Redis node with IP 10.0.0.22 is the new Master node.

Run the following command on the new Master node:

$ redis-cli --askpass info replication
# Replication
role:master
connected_slaves:2
slave0:ip=10.0.0.23,port=6379,state=online,offset=519426,lag=1
slave1:ip=10.0.0.21,port=6379,state=online,offset=519559,lag=0
master_replid:ade635098e62dc68f3ee65acf37970f98e1a2f8a
master_replid2:8777248b814d71f4c609f437c37a529e01b7d0c5
master_repl_offset:519692
second_repl_offset:195253
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:519692

Sentinel node failure

Run the following command on the first Sentinel node:
```
$ sudo systemctl stop redis-sentinel
```

Check redis-sentinel.log on the second Sentinel node:

tail -1 /var/log/redis/redis-sentinel.log
5587:X 18 Sep 2024 22:14:36.112 # +sdown sentinel d01aa131dc0ba6cc4069f3ec67bf6b4fa6b501f8 10.0.0.24 26379 @ mymaster 10.0.0.22 6379

Run the following command on Master node:

$ redis-cli --askpass client pause 40000
Please input password: ****************
OK

Check redis-sentinel.log on the second Sentinel node:

$ tail -10 /var/log/redis/redis-sentinel.log
5587:X 18 Sep 2024 22:20:49.232 # +failover-state-reconf-slaves master mymaster 10.0.0.22 6379
5587:X 18 Sep 2024 22:20:49.255 * +slave-reconf-sent slave 10.0.0.23:6379 10.0.0.23 6379 @ mymaster 10.0.0.22 6379
5587:X 18 Sep 2024 22:20:49.691 # -odown master mymaster 10.0.0.22 6379
5587:X 18 Sep 2024 22:20:54.812 # -sdown master mymaster 10.0.0.22 6379
5587:X 18 Sep 2024 22:20:56.253 * +slave-reconf-inprog slave 10.0.0.23:6379 10.0.0.23 6379 @ mymaster 10.0.0.22 6379
5587:X 18 Sep 2024 22:20:56.254 * +slave-reconf-done slave 10.0.0.23:6379 10.0.0.23 6379 @ mymaster 10.0.0.22 6379
5587:X 18 Sep 2024 22:20:56.278 # +failover-end master mymaster 10.0.0.22 6379
5587:X 18 Sep 2024 22:20:56.278 # +switch-master mymaster 10.0.0.22 6379 10.0.0.21 6379
5587:X 18 Sep 2024 22:20:56.279 * +slave slave 10.0.0.23:6379 10.0.0.23 6379 @ mymaster 10.0.0.21 6379
5587:X 18 Sep 2024 22:20:56.279 * +slave slave 10.0.0.22:6379 10.0.0.22 6379 @ mymaster 10.0.0.21 6379

According to the log the node with IP 10.0.0.21 is the new Master node.

Run the following command on the second Sentinel node:
```
$ sudo systemctl stop redis-sentinel
```

Check redis-sentinel.log on the third Sentinel node:

tail -1 /var/log/redis/redis-sentinel.log
5406:X 18 Sep 2024 22:26:57.116 # +sdown sentinel 4a1264d7e6946072945569a8a6c91ad5bff182aa 10.0.0.25 26379 @ mymaster 10.0.0.21 6379

At this point, the only single Sentinel node 10.0.0.26 running, and the Redis node with IP 10.0.0.21 is the new Master node.

Run the following command on Master node:

$ redis-cli --askpass client pause 40000
Please input password: ****************
OK

Check redis-sentinel.log on the third Sentinel node:

$ tail -2 /var/log/redis/redis-sentinel.log
5406:X 18 Sep 2024 22:26:57.116 # +sdown sentinel 4a1264d7e6946072945569a8a6c91ad5bff182aa 10.0.0.25 26379 @ mymaster 10.0.0.21 6379
5406:X 18 Sep 2024 22:42:37.815 # +sdown master mymaster 10.0.0.21 6379

According to the log the Master node is down, but there was no voting for the new leader. This is due to the missing of quorum among the Sentinel nodes.

Don't forget to start redis-sentinel service on the first and second Sentinel nodes:
```
$ sudo systemctl start redis-sentinel
```

Congrats! You have configured Redis Sentinel.

Summary

In this post, we’ve seen:

how to set up Redis Master-Slave replication
how to set up Redis Sentinel
hot to test the failover of the high availability Redis using Sentinel.

DEV Community: Ježek

Getting started with Argo CD using the CLI

Prerequisites:

Kubernetes Cluster

Argo CD

Setup the Argo CD

Setup a Repository

Create a Project

Create an Application

Cleanup

Bonus

Applications In Any Namespace

Kubernetes by Example

Table Of Contents

Kubernetes in Docker

Create a cluster

Cluster info

Cluster nodes

Pods

Create a pod

Imperative way

Declarative way

Logs

Port forwarding from host to pod

Labels and Selectors

Labels

Selectors

Annotations

Namespaces

ReplicaSet

DaemonSet

Jobs

CronJob

Service

ClusterIP

ExternalName

NodePort

LoadBalancer

Ingress

Ingress Controller

Ingress resources

Basic usage

Using a host

TLS

Probes

livenessProbe

readinessProbe

startupProbe

Volumes

Ephemeral Volumes

emptyDir

Projected Volumes

Persistent Volumes

PersistentVolume

hostPath

PersistentVolumeClaim

Dynamic Volume Provisioning

StorageClass

ConfigMaps

Creating ConfigMaps

Imperative way

Declarative way

Using ConfigMaps

Consuming an environment variable by a reference key

Consuming all environment variables from the ConfigMap

Using configMap volume

Using configMap volume with items

Secrets

Default Secrets in a Pod

Creating Secrets

Imperative way

Opaque Secrets

TLS Secrets

Docker config Secrets

Declarative way

Opaque Secrets

Docker config Secrets

Basic authentication Secret

Using Secrets

Using Secrets as files from a Pod