DEV Community: ido bistry

Idubi

ido bistry — Wed, 12 Nov 2025 07:52:38 +0000

PODS CHEAT SHEET

ido bistry — Sun, 04 May 2025 01:17:11 +0000

PODS CHEAT SHEET

40 Days of K8s – CKA Challenge (07/40)

@piyushsachdeva

Day 7/40 - Pod In Kubernetes Explained | Imperative VS Declarative Way | YAML Tutorial

this suimmery include of 2 issues :

1. POD - cheat sheet

2. EXERCISE from lecture

1. POD - cheat sheet

CREATE POD

Two Ways To Use KUBCTL to create POD:

1. imperative :

create nginx deployment

kubectl run nginx --image=nginx

2. declerative :

- create nginx yaml file:

#### template pod yaml has :
- apiVersion
- kind
- metadata
- spec

# nginx-pod-1.yaml
# template pod yaml hasa : apiVersion, kind, metadata, spec
apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod-1
  labels:
    name: demo
    type: frontend
spec:
  containers:
  - name: nginx-container
    image: nginx:1.28
    resources:
      limits:
        memory: "128Mi"
        cpu: "500m"
    ports:
      - containerPort: 80
        protocol: TCP

- execute the yaml file

#kubectl apply/create -f <file-name>
  # create - oly on creation 
  # apply  - create or update changes on a pod
kubectl apply -f ./nginx-pod-1.yaml

To get the real values used in yaml file

to cretate a resource (pod,service ... ):

command used :

kubectl explain _[api-resouce-type]_

api-resouce-type type can be pod/service/deployment/replicaset...

kubectl api-resources  
# --> will show all of the resources that this command cover :

#     kubectl explain pod --recursive
# --  >   NAME                                SHORTNAMES   APIVERSION                        NAMESPACED   KIND
# --  >   bindings                                         v1                                true         Binding
# --  >   componentstatuses                   cs           v1                                false        ComponentStatus
# --  >   configmaps                          cm           v1                                true         ConfigMap
# --  >   endpoints                           ep           v1                                true         Endpoints
# --  >   events                              ev           v1                                true         Event
# --  >   limitranges                         limits       v1                                true         LimitRange
# --  >   namespaces                          ns           v1                                false        Namespace
# --  >   nodes                               no           v1                                false        Node
# --  >   persistentvolumeclaims              pvc          v1                                true         PersistentVolumeClaim
# --  >   persistentvolumes                   pv           v1                                false        PersistentVolume
# --  >   pods                                po           v1                                true         Pod
#  ....

so :

  kubectl explain pod 

           #  KIND:       Pod
           #  VERSION:    v1
           #  
           #  DESCRIPTION:
           #      Pod is a collection of containers that can run on a host. This resource is
           #      created by clients and scheduled onto hosts.
           #      
           #  FIELDS:
           #    apiVersion    <string>
           #      APIVersion defines the versioned schema of this representation of an object.
           #      Servers should convert recognized schemas to the latest internal value, and
           #      may reject unrecognized values. More info:
           #      https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources
           #  
           #    kind  <string>
           #      Kind is a string value representing the REST resource this object
           #      represents. Servers may infer this from the endpoint the client submits
           #      requests to. Cannot be updated. In CamelCase. More info:
           #      https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
           #  
           #    metadata      <ObjectMeta>
           #      Standard object's metadata. More info:
           #      https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
           #  
           #    spec  <PodSpec>
           #      Specification of the desired behavior of the pod. More info:
           #      https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
           #  
           #    status        <PodStatus>
           #      Most recently observed status of the pod. This data may not be up to date.
           #      Populated by the system. Read-only. More info:
           #      https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status

this is very useful to understand the resource yaml file:

DRY-RUN=client/server/none

if we want to create a resource YAML template - we can use : dry-run=client parameter and export (-o) as yaml file

the -o means --(o)utput format and can be yaml or json or text

# create nginx pod
kubectl run nginx --image=nginx --restart=Never --port=80 --dry-run=client -o  json
#kubectl create deployment nginx  --dry-run=client  --image=nginx --replicas=3 -o yaml
# dry-run - will not execute the command 
# -o yaml - will output as yaml format
# -o json - will output as json format

JSON :

kubectl run nginx --image=nginx --restart=Never --port=80 --dry-run=client -o json

{
    "kind": "Pod",
    "apiVersion": "v1",
    "metadata": {
        "name": "nginx",
        "creationTimestamp": null,
        "labels": {
            "run": "nginx"
        }
    },
    "spec": {
        "containers": [
            {
                "name": "nginx",
                "image": "nginx",
                "ports": [
                    {
                        "containerPort": 80
                    }
                ],
                "resources": {}
            }
        ],
        "restartPolicy": "Never",
        "dnsPolicy": "ClusterFirst"
    },
    "status": {}
}

it is very useful to add pipeline to a new file ( .. > < new-file > ) when using dry-run=client

example inline ...

YAML :

kubectl run nginx --image=nginx --restart=Never --port=80 --dry-run=client -o yaml > run-nginx-template.yaml

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: nginx
  name: nginx
spec:
  containers:
  - image: nginx
    name: nginx
    ports:
    - containerPort: 80
    resources: {}
  dnsPolicy: ClusterFirst
  restartPolicy: Never
status: {}

# this way, the yaml will be saved inside the yaml file to be executed later. 
# so we used to **dry-run** to create a yaml fiel for next deploy of this pod

CHANGING PODS

we can use 2 methods to change pod

### imperative

   kubectl edit pod <pod-name>

    # all of the pods YAML will be displayed in a vi editor and we can set values and save 
    # if the saved version has invalid fields ( syntax error )  the changes will not be commited
    # and we cant exit from edit window (vi)

### declerative edit the yaml file of the resource (POD) with wanted values and then execute :

  kubectl apply -f ./changed_nginx-pod.yaml

DUPLICATING PODS YAML/JSON

if we have a running pod - we can use imperative command to duplicate it and magke changes at the side - in an editor for next use withapply :

### duplicate the pod yaml file

  kubectl get pod  nginx-pod-1 -o yaml > duplicated_nginx-pod-1

### edit value of YAML pod

sed -i 's/containerPort: 80/containerPort: 81/' duplicated_nginx-pod-1

### uply new changes on pod :

kubectl apply -f ./duplicated_nginx-pod-1

INSPECTING PODS - LOGS , DESCRIBE

there are 2 ways to see PODS logs

1. DESCRIBE -

desct=ribe actually used to probe any META DATA about a pod.

it gives us documentation about thr node that the pod is in , the namespace and other infrastractural data

but it also gives us details about last failing logs

so this is very useful command

#kubectl describe pod < pod-name >
kubectl describe pod nginx-pod-1

describe show us full data about the pod, the namespace , the node etc ...

more then this - we can see last logs of the pod
it is very useful also when we have failover of pod - we ma inspect the last logs that are shown in the desribe output

2. LOGS

# kubectl logs < pod-name >
kubectl logs nginx-pod-1

#### TAIL LOGS : if we want to tail logs (like tail -f) we can use -f flag :

 kubectl logs -f nginx-pod-1 

# idubi@DESKTOP-82998RE  3.12  ~/.../Resources/Day07   Day07 ●  kubectl logs -f nginx-pod-1 
------------------------------------------------------------------------------------------------------
# /docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
# /docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
# /docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
# 10-listen-on-ipv6-by-default.sh: info: Getting the checksum of /etc/nginx/conf.d/default.conf
# 10-listen-on-ipv6-by-default.sh: info: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf
# /docker-entrypoint.sh: Sourcing /docker-entrypoint.d/15-local-resolvers.envsh
# /docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
# /docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh
# /docker-entrypoint.sh: Configuration complete; ready for start up
# 2025/05/03 15:41:49 [notice] 1#1: using the "epoll" event method
# 2025/05/03 15:41:49 [notice] 1#1: nginx/1.28.0
# 2025/05/03 15:41:49 [notice] 1#1: built by gcc 12.2.0 (Debian 12.2.0-14) 
# 2025/05/03 15:41:49 [notice] 1#1: OS: Linux 5.15.167.4-microsoft-standard-WSL2
# 2025/05/03 15:41:49 [notice] 1#1: getrlimit(RLIMIT_NOFILE): 1048576:1048576
# 2025/05/03 15:41:49 [notice] 1#1: start worker processes
# 2025/05/03 15:41:49 [notice] 1#1: start worker process 33
# 2025/05/03 15:41:49 [notice] 1#1: start worker process 34
# 2025/05/03 15:41:49 [notice] 1#1: start worker process 35
# 2025/05/03 15:41:49 [notice] 1#1: start worker process 36
# 2025/05/03 15:41:49 [notice] 1#1: start worker process 37

PODS - INTERACTIVE MODE

this is especially useful if we want to look at logs
or probe executions inside the pods container
just like in docker (i)nterac(t)ive mode

#kubectl exec -it < pod-name > -- <command>
kubectl exec -it nginx-pod-1 -- sh

DELETE A POD

# kubectl delete pod < pod-name >
kubectl delete pod nginx-pod-1

# ✘ idubi@DESKTOP-82998RE  3.12  ~/.../Resources/Day07   Day07 ●  kubectl get pods 
# NAME          READY   STATUS    RESTARTS     AGE
# 1st-nginx     1/1     Running   0            8h
# nginx-pod-1   1/1     Running   2 (8h ago)   8h
# idubi@DESKTOP-82998RE  3.12  ~/.../Resources/Day07   Day07 ●  kubectl delete pod 1st-nginx
# pod "1st-nginx" deleted
# idubi@DESKTOP-82998RE  3.12  ~/.../Resources/Day07   Day07 ●  kubectl get pods 
# NAME          READY   STATUS    RESTARTS     AGE
# nginx-pod-1   1/1     Running   2 (8h ago)   8h
# idubi@DESKTOP-82998RE  3.12  ~/.../Resources/Day07   Day07 ● 

EXERCISE :

Task 1

Create a pod using the imperative command and use nginx as the image

kubectl run nginx --image=nginx --restart=Never --port=80

Task2

Create the YAML from the nginx pod created in task 1

 kubectl get pod nginx -o yaml > nginx-new.yaml

Update the pod name in the YAML

sed -i 's/name: nginx/name: nginx-new/' nginx-new.yaml
cat  nginx-new.yaml|grep -C 3 'name: nginx'
#  vagrant@master-node:~/temp$ cat  nginx-new.yaml|grep -C 3 'name: nginx'
#    creationTimestamp: "2025-05-04T00:22:22Z"
#    labels:
#      run: nginx
#    name: nginx-new
#    namespace: default
#    resourceVersion: "249909"
#    uid: 7b44db2b-0ca3-4813-9740-494d9287e7ad
#  --
#    containers:
#    - image: nginx
#      imagePullPolicy: Always
#      name: nginx-new
#      ports:
#      - containerPort: 81
#        protocol: TCP
#  --
#      image: docker.io/library/nginx:latest
#      imageID: docker.io/library/#  nginx@sha256:c15da6c91de8d2f436196f3a768483ad32c258ed4e1beb3d367a27ed67253e66
#      lastState: {}
#      name: nginx-new
#      ready: true
#      restartCount: 0
#      started: true
#  

sed -i 's/containerPort: 80/containerPort: 81/' nginx-new.yaml
cat  nginx-new.yaml|grep -C 3 port
#  vagrant@master-node:~/temp$ cat  nginx-new.yaml|grep -C 3 port
#    - image: nginx
#      imagePullPolicy: Always
#      name: nginx
#      ports:
#      - containerPort: 81
#        protocol: TCP
#      resources: {}

Use that YAML to create a new pod with the name nginx-new.

kubectl apply -f ./nginx-new.yaml

# vagrant@master-node:~/temp$ kubectl get pods
# NAME    READY   STATUS    RESTARTS   AGE
# nginx   1/1     Running   0          19m
# vagrant@master-node:~/temp$ kubectl apply -f ./
# duplicate-nginx-1.json  duplicate-nginx-1.yaml  nginx-new.yaml          nginx-pod-1.yaml
# vagrant@master-node:~/temp$ kubectl apply -f ./nginx-new.yaml
# pod/nginx-new created
# vagrant@master-node:~/temp$ kubectl get pods
# NAME        READY   STATUS    RESTARTS   AGE
# nginx       1/1     Running   0          20m
# nginx-new   1/1     Running   0          28s
#

Task3

Apply the below YAML and fix the errors, including all the commands that you run during the troubleshooting and the error message

apiVersion: v1
kind: Pod
metadata:
  labels:
    app: test
  name: redis
spec:
  containers:
  - image: rediss
    name: redis


echo "apiVersion: v1
kind: Pod
metadata:
  labels:
    app: test
  name: redis
spec:
  containers:
  - image: rediss
    name: redis" > failed-redis.yaml 

kubectl apply -f ./failed-redis.yaml



![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/95ecud0130t9jwo422zg.png)



kubectl get pods

#  vagrant@master-node:~/temp$ kubectl get pdos
#  error: the server doesn't have a resource type "pdos"
#  vagrant@master-node:~/temp$ kubectl get pods
#  NAME        READY   STATUS             RESTARTS   AGE
#  nginx       1/1     Running            0          24m
#  nginx-new   1/1     Running            0          4m33s
#  redis       0/1     ImagePullBackOff   0          85s

kubectl logs redis 

#vagrant@master-node:~/temp$ kubctl logs redis
#-bash: kubctl: command not found
#vagrant@master-node:~/temp$ kubectl logs redis
#Error from server (BadRequest): container "redis" in pod "redis" is #waiting to start: trying and failing to pull image

kubectl describe pod redis


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7vwd3dtn85g1ni4wjdx5.png)




#  vagrant@master-node:~/temp$ kubectl describe pod redis
#  Name:             redis
#  Namespace:        default
#  Priority:         0
#  Service Account:  default
#  Node:             worker-node-1/192.168.133.167
#  Start Time:       Sun, 04 May 2025 00:45:05 +0000
#  Labels:           app=test
...
              ----               -------
              ----               -------
              ----               -------
...
#    Normal   Scheduled  2m21s                default-scheduler  Successfully assigned default/redis to #  worker-node-1
#    Normal   Pulling    59s (x4 over 2m21s)  kubelet            Pulling image "rediss"
#    Warning  Failed     57s (x4 over 2m19s)  kubelet            Failed to pull image "rediss": failed to pull #  and unpack image "docker.io/library/rediss:latest": failed to resolve reference "docker.io/library/#  rediss:latest": pull access denied, repository does not exist or may require authorization: server message: #  insufficient_scope: authorization failed
#    Warning  Failed     57s (x4 over 2m19s)  kubelet            Error: ErrImagePull
#    Normal   BackOff    3s (x8 over 2m19s)   kubelet            Back-off pulling image "rediss"
#    Warning  Failed     3s (x8 over 2m19s)   kubelet            Error: ImagePullBackOff
#  

kubectl edit pod redis 

# change rediss --> redis   # -->  CTRL+x

kubectl get pod redis

#   vagrant@master-node:~/temp$ kubectl get pod redis
#   NAME    READY   STATUS    RESTARTS   AGE
#   redis   1/1     Running   0          15m


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/hqaowcbof5cm9cptqrvp.png)

create your own k8s - Multi nodes - KUBEADM & DIND platform

ido bistry — Sat, 03 May 2025 02:10:34 +0000

Create Your Own K8s Multi-Node Platform – KUBEADM & DIND

40 Days of K8s – CKA Challenge (06/40)

@piyushsachdeva

Day 6/40 - Kubernetes Multi Node Cluster Setup Step By Step | Kind Tutorial

In this post, I demonstrate two architectures I used to create a functioning multi-node Kubernetes environment.

This environment serves as a sandbox for upcoming lessons.

The two environments are based on different architectures:

1. Containerized architecture – using the KIND Kubernetes provider over Docker

2. VM-based architecture – using a fully functioning KUBEADM setup

1. KIND: Containerized Architecture (KIND over Docker)

Prerequisites:

Golang > 1.6
```
sudo apt install golang-go
```
Docker (already installed)

kubectl – Kubernetes CLI

# 1. Download the latest version
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl.sha256"

# 2. Install kubectl
sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl

# 3. Test the installation
kubectl version --client

Installation:

KIND:

# For AMD64 / x86_64
[ $(uname -m) = x86_64 ] && curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.27.0/kind-linux-amd64

# For ARM64
[ $(uname -m) = aarch64 ] && curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.27.0/kind-linux-arm64

chmod +x ./kind
sudo mv ./kind /usr/local/bin/kind

Create a Cluster:

You can create a cluster either by running a single-node setup:

kind create cluster --image kindest/node:v1.32.2@sha256:f226345927d7e348497136874b6d207e0b32cc52154ad8323129352923a3142f --name cka-cluster-1

Or by preparing a YAML configuration for a multi-node setup:

1. Create a YAML file describing the cluster:

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

2. Create the cluster using the YAML file:

kind create cluster       --image kindest/node:v1.32.2@sha256:f226345927d7e348497136874b6d207e0b32cc52154ad8323129352923a3142f       --name cka-cluster-2       --config kind-2master-4workers

Verify the Created Cluster:

After creating the cluster, validate its configuration using the kubectl CLI:

kubectl config get-clusters
kubectl config get-users

Docker View of KIND Nodes:

Since KIND uses Docker under the hood, each Kubernetes node is represented as a Docker container. Switching context via kubectl config use-context <cluster-name> will show the corresponding containers becoming active:

docker ps

Example output:

CONTAINER ID   IMAGE                    ...        NAMES
16462509a712   kindest/haproxy:...     ...        cka-cluster-2-external-load-balancer
4016000812c4   kindest/node:...        ...        cka-cluster-2-control-plane2
...

Common Commands:

kubectl config current-context
kubectl get nodes

kubectl config use-context kind-cka-cluster-1
kubectl get nodes

2. VM-Based Architecture – KUBEADM Kubernetes Using VAGRANT

The VM architecture differs from Docker:

Each VM is a full OS instance acting as a node (master or worker).

The general flow:

Install Kubeadm on the main master node and run kubeadm init.
Create a token to allow other nodes to join.
Other nodes (including additional masters) join using this token.

I used Vagrant to automate both VM creation and the Kubeadm setup process.

1. VM Setup

You need a VM platform like VirtualBox, VMware, or Hyper-V that supports Vagrant.

Folder structure:

k8s-vmware-cluster/
├── Vagrantfile
├── common.sh
├── master.sh
├── worker.sh
└── disable-swap.sh

2. Vagrant Installation

Ensure you're running on a system with a hypervisor (macOS, Windows, Linux).

Do not run Vagrant-based VMs on WSL.

Install Vagrant:

Follow Vagrant installation instructions
For VMware users:

Install the vagrant-vmware-desktop plugin

3. Vagrantfile – VM Orchestration

Each VM is provisioned with common resources and then initialized using shell scripts.

Master Node:

config.vm.define "master-node" do |node_config|
  node_config.vm.hostname = "master-node"
  node_config.vm.network "private_network", ip: "192.168.56.10"
  node_config.vm.provision "shell", path: "common.sh"
  node_config.vm.provision "shell", path: "master.sh"
  node_config.vm.provision "shell", path: "disable-swap.sh", run: "always"
end

In master.sh, the following happens:

Runs kubeadm init
Generates the join.sh script containing the token
Other nodes will use this script to join the cluster

Worker Node:

config.vm.define "worker-node-1" do |node_config|
  node_config.vm.hostname = "worker-node-1"
  node_config.vm.network "private_network", ip: "192.168.56.11"
  node_config.vm.provision "shell", path: "common.sh"
  node_config.vm.provision "shell", path: "worker.sh"
  node_config.vm.provision "shell", path: "disable-swap.sh", run: "always"
end

The worker script waits for join.sh to be generated by the master and then executes it.

# Wait for join.sh
for i in {1..30}; do
  if [ -f /vagrant/join.sh ]; then
    break
  fi
  echo "[$(date '+%T')] Waiting for /vagrant/join.sh... (try $i/30)"
  sleep 10
  if [ "$i" == "30" ]; then
    echo "Timeout waiting for /vagrant/join.sh"
    exit 1
  fi
done

SWAP Management:

Kubernetes requires swap to be disabled.

Even though common.sh disables swap on boot, VM restarts may re-enable it.

Ensure swap is disabled always:

node_config.vm.provision "shell", path: "disable-swap.sh", run: "always"

Summary

Both KIND and KUBEADM architectures achieve the same goal with different approaches:

KIND:

Simple and fast
Uses Docker containers
Best for development or sandbox use

KUBEADM on VMs:

Production-grade realism
Full control over networking, bootstrapping, and configuration
Greater complexity and overhead

Both setups follow a similar underlying flow:

crations of master node
- + container-D
- + contrl plan components
- + kubeadm & kubeproxy (since the control plan components are executed inside pods after all ...)
creation of worker nodes
- + container-D
- + kubeproxy + kubeadm (since this are the worker node processes )
join the workers to the master by using kubeadm join (with the master token generated at master process)

SOME KIND EXECUTIONS :

kubectl get nodes

kubectl config get-clusters

 ✘ idubi@DESKTOP-82998RE  3.12  ~/.../40DAysOfK8-CKA/Resources   Day06 ●  kubectl config get-clusters
NAME
kind-cka-cluster-1
kind-cka-cluster-2
docker-desktop

kubectl config get-contexts

 ✘ idubi@DESKTOP-82998RE  3.12  ~/.../40DAysOfK8-CKA/Resources   Day06 ●  kubectl config get-contexts
CURRENT   NAME                 CLUSTER              AUTHINFO             NAMESPACE
          docker-desktop       docker-desktop       docker-desktop       
          kind-cka-cluster-1   kind-cka-cluster-1   kind-cka-cluster-1   
*         kind-cka-cluster-2   kind-cka-cluster-2   kind-cka-cluster-2

kubectl config use-context kind-cka-cluster-1

Switched to context "kind-cka-cluster-1".

kubectl config get-contexts

CURRENT   NAME                 CLUSTER              AUTHINFO             NAMESPACE
          docker-desktop       docker-desktop       docker-desktop       
*         kind-cka-cluster-1   kind-cka-cluster-1   kind-cka-cluster-1   
          kind-cka-cluster-2   kind-cka-cluster-2   kind-cka-cluster-2   
 idubi@DESKTOP-82998RE  3.12  ~/.../40DAysOfK8-CKA/Resources   Day06 ● 

kind delete cluster --name cka-cluster-2

Deleting cluster "cka-cluster-2" ...
Deleted nodes: ["cka-cluster-2-control-plane2" "cka-cluster-2-worker2" "cka-cluster-2-control-plane" "cka-cluster-2-external-load-balancer" "cka-cluster-2-worker4" "cka-cluster-2-worker" "cka-cluster-2-worker3"]

kind get clusters

cka-cluster-1

kubectl config get-clusters

NAME
docker-desktop
kind-cka-cluster-1`

kind create cluster --image kindest/node:v1.32.2@sha256:f226345927d7e348497136874b6d207e0b32cc52154ad8323129352923a3142f --name cka-cluster-2 --config kind-2master-4workers.yaml

Creating cluster "cka-cluster-2" ...
 ✓ Ensuring node image (kindest/node:v1.32.2) 🖼
 ✓ Preparing nodes 📦 📦 📦 📦 📦 📦  
 ✓ Configuring the external load balancer ⚖️ 
 ✓ Writing configuration 📜 
 ✓ Starting control-plane 🕹️ 
 ✓ Installing CNI 🔌 
 ✓ Installing StorageClass 💾 
 ✓ Joining more control-plane nodes 🎮 
 ✓ Joining worker nodes 🚜 
Set kubectl context to "kind-cka-cluster-2"
You can now use your cluster with:

kubectl cluster-info --context kind-cka-cluster-2

Have a question, bug, or feature request? Let us know! https://kind.sigs.k8s.io/#community 🙂

kubectl cluster-info --context kind-cka-cluster-2

Kubernetes control plane is running at https://127.0.0.1:42379
CoreDNS is running at https://127.0.0.1:42379/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

kubectl get nodes

NAME                           STATUS   ROLES           AGE     VERSION
cka-cluster-2-control-plane    Ready    control-plane   4m40s   v1.32.2
cka-cluster-2-control-plane2   Ready    control-plane   4m34s   v1.32.2
cka-cluster-2-worker           Ready    <none>          4m27s   v1.32.2
cka-cluster-2-worker2          Ready    <none>          4m27s   v1.32.2
cka-cluster-2-worker3          Ready    <none>          4m27s   v1.32.2
cka-cluster-2-worker4          Ready    <none>          4m27s   v1.32.2

kubectl config get-contexts

CURRENT   NAME                 CLUSTER              AUTHINFO             NAMESPACE
          docker-desktop       docker-desktop       docker-desktop       
          kind-cka-cluster-1   kind-cka-cluster-1   kind-cka-cluster-1   
*         kind-cka-cluster-2   kind-cka-cluster-2   kind-cka-cluster-2

kubectl config get-clusters

NAME
kind-cka-cluster-2
docker-desktop
kind-cka-cluster-1

What is Kubernetes - Kubernetes Architecture Explained

ido bistry — Sat, 26 Apr 2025 14:14:00 +0000

40 days of K8s - CKA challenge (05/40)

@piyushsachdeva

Day 5/40 - What is Kubernetes - Kubernetes Architecture Explained

this post summerise the Architecture of K8s and its main processes

the Architecture of K8s and its main processes

a K8s cluster contains 2 types of nodes:

Master NODE (control plane)

ETCD
API SERVER
SCHEDULER
CONTROLLER MANAGER

Worker NODE

KUBELETS
KUBE PROXY

1. MASTER NODE - control plane

the master node consists 3 main processes and ETCD Component.

ETCD - (Extended Tree Configuration Database) this is a key:value _(like JSON objects)_ database that represent the metadata of the clkuster.
it includes all of the structural entities statuses in a given time.
whenever a change is needed, of a new entity or current one configuration - this chagnge is updated to the ETCD and upon the new value and current value - the new entity will be created/updated.
SCHEDULER - SCHEDULER is in charge of 1 specific thing : schedule the creation of a new POD into a specific NODE.

Scheduler only acts on unscheduled Pods : Pods with spec.nodeName not set.

    The only times that happens 
    ---------------------------------------------------------
    o   A new Pod is created
    o   Directly (kubectl run)
    o   Indirectly via a controller (Deployment, Job, ReplicaSet)
    o   An existing Pod is deleted and the controller creates a replacement
    o   A Pod gets rescheduled (after Node failure, eviction, etc.)


        When the scheduler is not involved
    ---------------------------------------------------------
    o   If you run any command that doesn't result in a new Pod, the scheduler does nothing.

API SERVER - is the main component of the Kubernetes cluster - after the ETCD

what is API SERVER in charge of :
---------------------------------
o   validate any call from CLI or rest call 
o   store the request in ETCD
o   acts as a client to control manager or scheduler to read from ETCD 
o   send a message to the specific NODE's kubelete and trigger it,
    when any changes need to be done inside it.

if any of the ETCD or API Server is failing, they must be recovered.
but as long they are down - current nodes function autonomly, but any change in the cluster is impossible.
the kubeletes (will speak about it soon) will keet the current status in the node, but any change in replicaset or pods or any other status of the cluster cant be done.

if the APIServer is failing - there is no connection between te components of the cluster, and command cant be setnt to the K8s cluster from outside of the cluster (no cli or api commmands)

CONTROLLER MANAGER - monitor all ofthe controllers inside the cluster. the control is done throught the ETCD. it is useing the API sServer to read from the rtcd - the cesesary data about the different components in the cluster nodes. it runs several control loops, each loop is a controller, responsible for managing a specific Kubernetes resource type how does it monitor ? by watching the ETCD via the API SEVER

#### Just like the scheduler, the controller manager watches for changes to objects it's responsible for, via the use of API SERVER

## example:

 Example:
    If you create a Deployment, the Deployment controller:
    -------------------------------------------------------
    o   Watches for Deployments via the API server.
    o   Sees that it needs 3 replicas.
    o   Creates 3 ReplicaSets via the API server.
    o   ReplicaSet controller sees that, and creates 3 Pods.
    o   All of this flows through the API server.

The control loop pattern:

Watch: Observe resources via the API server.
Compare: Desired state vs current state.
Act: If there's a diff, make changes via the API server.
API server updates etcd. ________________________________________

here is a list of controllers (loops) inside the conttroller manager:

Controller Name	What it Manages	Example Behavior
Node Controller	Node health/status	Marks Nodes as NotReady if kubelet is unresponsive
Replication Controller	ReplicationController resources	Ensures the desired number of old-style RCs
ReplicaSet Controller	ReplicaSet resources	Maintains correct number of Pods
Deployment Controller	Deployment resources	Handles rolling updates, rollback
StatefulSet Controller	StatefulSet resources	Ensures ordered, unique Pod identities
DaemonSet Controller	DaemonSet resources	Makes sure one Pod per Node is running
Job Controller	Job resources	Manages Pods for short-lived jobs
CronJob Controller	CronJob resources	Creates Jobs based on a schedule
Service Controller	Service resources	Updates iptables/IPVS rules, interacts with cloud LB
EndpointSlice Controller	EndpointSlices	Replaces legacy Endpoints, more scalable
Namespace Controller	Namespace lifecycle	Cleans up resources when namespace is deleted
PersistentVolume (PV) Controller	PersistentVolume binding	Matches PVCs to available PVs
PersistentVolumeClaim (PVC) Controller	PVC lifecycle	Manages volume provisioning and binding
ResourceQuota Controller	ResourceQuota enforcement	Blocks creation if limits exceeded
ServiceAccount Controller	Default service accounts	Automatically creates default ServiceAccounts in namespaces
Token Controller	Generates secrets for service accounts	Token rotation and creation
CertificateSigningRequest Controller	CSR approval and tracking	Used in TLS bootstrap and cert renewal

Cloud-specific Controllers (when running in a cloud environment)These run only if you’ve configured a cloud provider like AWS, GCP, or Azure:

Controller Name	Purpose
CloudNode Controller	Syncs Node metadata with cloud provider
CloudRoute Controller	Manages routing tables (for overlay networks)
Service LoadBalancer Controller	Provisions cloud load balancers for type: LoadBalancer services

2. Worker NODE

this are the worker nodes components and they run on any node

KUBELET - Running and maintaining application Pods

kubelets are in charge of maintainence of the NODE.
talks to the container runtime (containerd / docker ) to ensure pods are erunning properly
talks to the ETCD via the API server to check new tasks/chagnges on the pod
it is critical for rnning and maintainnt the pods inside the node

KUBE-PROXY - Enabling Service discovery and internal communication

manages the network traffic rules on the node
Configures network routing rules so Services can work
talks to API Server (to learn about Services and Endpoints) and Local iptables / IPVS system
Set up iptables or IPVS rules, and Load balance traffic inside the cluster

Why Kubernetes Is Used - Kubernetes Simply Explained

ido bistry — Fri, 25 Apr 2025 20:00:54 +0000

40 days of K8s - CKA challenge (04/40)

@piyushsachdeva

Day 4/40 - Why Kubernetes Is Used - Kubernetes Simply Explained - CKA Full Course 2025

this post summerise what is an orchestrator and why Kubernetes (K8s)

what is an Orchestrator , why do we need k8s to

after we learnt about Dcoker - we understand that we can create a containerized environment to work as production, as well as testing.

this system can be scaled and maintained automatically - if we just had an orchestraiting system to manage it.

a container orchestrator is a system that automates the deployment, scaling, networking, and management of containerized applications.

It plays a crucial role in production environments where services must remain available, resilient, and easily updatable.

Without an orchestrator, managing hundreds or thousands of containers manually would be error-prone, inefficient, and unsustainable — especially in environments that demand high availability, dynamic scaling, and automated recovery from failure.

Orchestration solves key challenges like service discovery, load balancing, health checks, resource scheduling, automated rollouts and rollbacks, and self-healing of applications .

It also provides centralized control over distributed infrastructure,

enabling teams to enforce consistency, optimize resource usage, and respond to real-time changes in application demand or infrastructure state.

Kubernetes (K8s) has emerged as the most popular and powerful orchestrator, designed to manage complex, distributed systems at scale. Its key features include:

Declarative configuration: Define desired system state using YAML/JSON, letting K8s reconcile reality with the declared spec.
Self-healing: Automatically restarts failed containers, replaces unresponsive Pods, and evicts unhealthy nodes.
Horizontal scaling: Adjusts the number of running Pods based on CPU/memory usage or custom metrics.
Rolling updates and rollbacks: Enables zero-downtime deployments with built-in version control and safe rollback in case of failure.
Persistent volume management: Abstracts storage resources and dynamically provisions volumes for stateful workloads.
Service discovery and DNS: Exposes services with internal or
external networking via stable DNS names and load balancing.
Extensibility: Operators, CRDs, and webhooks make K8s highly customizable and adaptable to any workload or platform need.

From a DevOps and reliability engineering perspective, Kubernetes provides the automation, observability, and operational control needed to confidently run applications in production - reducing human error, accelerating delivery, and improving system resilience.

Multi Stage Docker Build - smaller is better

ido bistry — Sun, 20 Apr 2025 23:32:11 +0000

40 days of K8s - CKA challenge (03/40)

Multi Stage Docker Build - smaller is better

@piyushsachdeva

Day 3/40 - Multi Stage Docker Build - Docker Tutorial For Beginners - CKA Full Course 2024

in the preview lesson - I created a docker image that is 1.2 GB

this lesson discussed how to make an image smaller.
the chapter focus on main methodology.
let me here count some methods considered best approch
(BEST PRACTICES) to create as small image as can be created.

but 1ST : lets count main reasons : why LARGE images are
not recommended:

there are several reasons why we want to make images smaller :

(1) Faster Deployment

* Smaller images pull and push faster * Reduced network bandwidth usage * Quicker container startup times

(2) Security Benefits

* Smaller attack surface * Fewer potentially vulnerable packages * Less code to scan and maintain

(3) Resource Efficiency

* Less disk space usage in registries * Reduced memory footprint * Better cache utilization

(4) Cost Savings

* Lower storage costs in container registries * Reduced data transfer costs * More efficient use of cloud resources

(5) Better CI/CD Performance

* Faster build pipelines * Quicker rollbacks if needed * Improved deployment reliability

there are several methods to make the docker image smaller, and the most recommended is using MULTISTAGE BUILD

lets count and explain the methods :

Key techniques for slimming Docker images:

(1) Start from a Minimal Base Image ('-alpine' or '-slim' )

when choosing the base image of a known application - usualy alpine is available. when you create an image from scratch - use alpine as base image. alpine is a slim linux operation system, s owhen an image is created out of alpine, it is usualy considering installing only what necesarry for the application to use.

there is also scratch image, which is an image that uses the HOST operating system as base, but it is not recommended- since we can never know where our image will be executed. there is whole different approach when using scratch , and I will not write about it here

**sometimes official versions dont use '-alpine' , but '-slim' in the tagname of the image**

(2) Remove Unnecessary Packages/Files

after executing image logic - if files are not nesesarry - we can remove the files that used in execution

**it is importent to remove the files in the same layer *RUN*, since once a layer is executed - storage that is clearde will not be reduced**

RUN apt-get update && apt-get install -y \ some-package && rm -rf /var/lib/apt/lists/*

after installing package we can remove the files that are
not neaded manually
the && add a command after previous comman was executed
all is done in the same RUN layer

(3) remove cache on layers

when adding a an argument to Dockerfile , we can then execute the build with dynamic value to this argument it prevent caching of layers , which makes build longer , but also clears cached data from image FROM .... ARG CACHEBUST=1 # default value RUN ...

and then when executing build :

(4) remove cache on build

when building with --no-cache , we omit cache , just lije in the build ARGUMENTS

(5) Multi-Stage Builds

when we use multy stage - we actually use the files in one build , but not saving it to the next build. we use the result of the execution as source in a new clean build without all of the installations, needed to create this files. it is similar to removing files after executing (2) however - using this method - we are creating hirarchical flow of the build.

(6) .dockerignore

.dockerignore file is a file created in the same folder as the Dockerfile. in it we list all files that we dont want to add to the docker image

node_modules
.git
*.log

(7) 3rd party tools

there are known utilities that I use, that help configure and sugest slimming docker ---------------------------------------------

Dive-
tool to analyze Docker image layers and see what's taking up space.
Slim-
This tool analyzes and auto-slims your image by removing unnecessary stuff like:
- Unused files
- Unreachable code paths
- Binaries and debugging tools
  it is ai tool that involved in the build process,m and slim the image by removing unused files

example : using dive -
here we can see difference between multi and regular build
we can see that in the regular we have the nodenode-module folder. and we can see diff in sizes of each layer

dive idubi/four-in-a-row_alpine18

dive multi-stage-4_in_a_row:1.1

conclusion :

in this example I use the first node image (installer) to install and all react packeges. then I add the files used in the build of the site. the command :

``` RUN yarn && yarn build ```

install all packages , and then execute build

then, in the 2ND image (deployer) I install NGINX HTTP server - a slim server, much slimmer then node, since I dont need all of the code compilation capabilities of node. then I copy the build files from the node server - which are the only files I need to use in the site from : /app/dist ==> to ==> /usr/share/nginx/html in deployer image. and I config expose its port (80) for outer connection (docker access to the image on port 80 of this image)

results :

the original image (one stage) - 1.2 GB
the multi-staged image - 280MB

docker run -d --name 4inarow-multi -p 8080:80 multi-stage-4_in_a_row:1.1


docker ps 
CONTAINER ID   IMAGE                        COMMAND                  CREATED          STATUS          PORTS                  NAMES
2396e23aa874   multi-stage-4_in_a_row:1.1   "/docker-entrypoint.…"   21 seconds ago   Up 21 seconds   0.0.0.0:8080->80/tcp   4inarow-multi

docker stop 4inarow-multi
docker rm 4inarow-multi
dcoker rmi multi-stage-4_in_a_row:1.1

docker tag multi-stage-4_in_a_row:1.1:1.1 idubi/multi-stage-4_in_a_row:latest
docker push idubi/multi-stage-4_in_a_row:latest

dcoker rmi idubi/four-in-a-row_alpine18:latest

now, after deleting it from local, we don't have image with this name and we can get the image from docker-hub ....

docker run -d --name 4inarow-multi -p 8080:80 idubi/four-in-a-row_alpine18:latest

...

and now we can see it running

Using Dcokerfile to Dockerize VibeCode Project

ido bistry — Sun, 20 Apr 2025 03:18:36 +0000

40 days of K8s - CKA challenge (01/40)

GIT

vibe coding - testing my skills

Day 2/40 - How To Dockerize a Project - CKA Full Course 2025
@piyushsachdeva

taking the #40DaysOfk8s Challange is a commitmenet
no doubt about it.

Day 2 of the challenge brought some important insights:

Based on a clear understanding of my strengths and limitations,
both in terms of focus and available time: I realized, that the only way I’ll consistently stick to the challenge, is by making it
genuinely interesting for me.

Sure, complex and technical challenges can be interesting on their own.
But here’s the catch: I need to find the personal challenge, especially in the easy ones ...

Let’s be honest: writing a Dockerfile isn’t what gets me excite (especially not a straigh forward one ... ) but it is the bread an butter of DevOps, and on the other side : if I start skipping tasks, or cutting corners, I’ll never finish this challenge.

So, here’s the formula I’m embracing:

Consistency = Engagement = Commitment

the only way I am going to stick with it, is determind by the how long i stay interested in it.

Choosing the Right Project for Presentaition

Early in the day, I asked myself:

Should I build on one of my many existing projects?

Or use this opportunity to experiment with something new—maybe a little VibeCoding?

Truth is, I have a cool project involving Kafka and Redis that I’ll definitely showcase later on.
But for now, I wanted to take today’s relatively simple task and infuse it with creativity

I decided going on a Vibe programming task - just to make it interesting
I will create a project out of prompting along
and use this code to dockerize my 2nd day challange.

but wait : how would i work ? I want it to be both consistant and professional
how will I track the progress and follow changes ?

I decided to FORK the original repository done by @piyushsachdeva.
by doing so, I can later on override it (adding my staff to MY!! forked project)
more then this :
using registration on @piyushsachdev repository events (by GitHub webhoooks or third party tools , or even manually scheduled automation) I may automate processes to fetch any future changes done by @piyushsachdeva in the future.

this can be done with gitactions that I can implement in my repo

once you FORK a repo - you get link to the upstream path to the repo that you FORK from
so using fetch from upstrim you can always get the changes done manuall

you can aloso set manually "upstream" remote link and later fetch from

git remote add upstream https://github.com/piyushsachdeva/CKA-2024

after creating upstream you can check existance with :

git remote -v

and then can fetch changes anytime manually :

git fetch upstream
git log HEAD..upstream/main --oneline  # shows commits you don't have

or even with GitHub-Actions

Creating my project - using Vibe-Programming

So i have a forked project.

now we go to day02 and adding Dockerfile there
this is done by creating a branch for every cahnge - actuially I decided a branch for every day of change

the dockerfile will be used with build of the docker image, created for my project.

lets create a project.

as memtioned earlier : I decided VIBE CODING
vibe coding is a new approach of writing code by asking AI tool to generate it.

so I started with the big weapon :

and asked it with a nice prompt to write me a 4 in a row game :

I want a frontend aplication of 4 in a row a user will start a game against the compuiter the computer will have 8 different levels 2 select - each level is another depth of thinking ( a step forwared , 2 steps forward till 10 steps forward

the game board size ( columns / rows) can be set at initialization with the selection of level

that's it
the application was ready to work and I got a game.

not fully functioning, but good enough ...

so i continued :

add a new game button and a hint button
allow the user to declare hoe many hints he can get in a game and allow to request as loong as its not ver

because I felt this was neaded

...

 padam padam  :

a game was born :

that easy

but the problem is that I couldnt take the code out ...
well, some code was available
but it did not work alone
and the tol didnt let me access to the code ....

so I decided to use my own work env to vibe programming
I decided to work with openai - just because I trust it the most
I use AI a lot (even wrote some experts ...) and I use well
I use it to create movies and pictures , to generate data and even to generate enhanced prompts ...

I could use the agent ability of the copilot, but I wanted to use manual progress with chatgpt - to monitor its progress and way of thinking (after all - as I mentioned before : I trust it the most)

but not only : after decided to work with GPT , I decided totake the product tcreated with it and pass it throught copilot pair programming tool and the windsurf (codium) addon as well

so I actually used 3 different tools to creat this code : ....

Workflow with GPT + Copilot + windsurf

I asked GPT to start
I asked it to create a 4-in-a-row aplication, I even added a printscreen of the setting window (created by base44)

after describing to request - I asked it to generate the filetree of the prooject
I also asked it to create the tree with bash script

then I asked it to write to me 10 questions that it might think that are need to accomplish the task

thne , asked it to write all files , and added : before each file write the name of the file in remark ...

#vibe programming - Real-Time Code Generation - 4InARow - react 

I want you to help me create a full react application for a 4 in a row game 

the game has this opening screen (see attached) 

the game is against computer. 

on setting screen the user can selecti the difficulty level (which is how many steps the oponent computer can calculate ahead), the rows and columns (for board) , the number of hints a user can ask the computer to hint him for the best next move he can do . 

while playing - each time the user request a hint - the number of available hints reduces 

pls ask me any question before start

it asked me question - on which i answered ...

then after some inquieries I declared the AI computer algorithm of game :

pls add filetree for the project

it had some game logistics issues which I ansered and the nit started to work

it went into canvas mode.

and then streted writing files
and deleting them
and rewriting them again and deleating again

for several minutes, with stops between ....

and at the end created files that I decided to copy and paste (I could asked it to generate a zip file , but wanted to follow it manually .... )

so i copied all script to the right files ...

after having this files - I asked also to genearate package.json
and the with the created code I faced to the other co-workers :
windsurf and copilot

over here it was a bit simpler - since they are embedded inside the vscode (also in cursor ... )

so I asked it (both) to identefy the project files and add bootstrap correctly ...

it added some coded for bootstrapping
and staff

and some changes in aths of components that are not created in the right path ...

and thisis it ...

I have a working project ...

i created the git repo for it and pushed it ther

not inside my #40DaysOfK8s challange repo , but outside of it

4-in-a-row

adding a subproject to Github repo

working with the #40DaysOfK8s challange repo - I wanted to maintain this repo clear to its purpose
no other repositories need to reside inside.

if I have this 4-in-a-row project - and I want to change it later on - i will not change it in #40DaysOfK8s repo.
more then this : I dont want to maintain other repos in this one repo.

but I do need to keep this repo files inside Day02 folder - sicne I ant to creatre a docker image for it

solution Git submoduled

Git submodules are actually links to a real repository. it is an ideal solution to components development when you dont want to duplicate your components in several projects in your organization.
unlkike subtrees that are actually copies of specific repo - this acts like links to another repo

like other objects - you can set git hooks to monitor the real repo changes and according to this to update the files in the linked submodule

creation of submodule is pretty straight forward :
go to the path of the repo where you wantto create the submodule :

 cd ./Resources/Day02
 git submodule add https://github.com/idubi/4-in-a-row.git 4-in-a-row

Building Docker Image steps for deployment

now we need to build the Docker image for deployment.
this are the steps :

crate a Dockerfile for deployment of react application 4_in_a_row

sicne the application is at "4-in-a-row: directory
the dockerfile looks like this :

FROM node:18-alpine
WORKDIR /app
COPY ./4-in-a-row .
RUN yarn && yarn build
CMD [ "yarn", "start" ]
EXPOSE 5173

since the react is packed with vite - the commands to execute the execution of react are different :
RUN yarn && yarn build
CMD [ "yarn", "start" ]

build the image with Dockerfile

docker build . -t four-in-a-row_alpine18

run the image locally to make suer you have it runing

docker run -d --name 4inarow2 -p 5173:5173 four-in-a-row_alpine18

and make sure the aplcation is working :

tag the image for uniquenes

docker tag four-in-a-row_alpine18:latest idubi/four-in-a-row_alpine18:latest

push the image to docker repository (for now Docker-Hub)

docker push idubi/four-in-a-row_alpine18:latest

delete the image from local dcoker and pull the docker image this is done to make sure pull works and run correctly (the pull is done from repository)

docker rm -f 4inarow2 
docker rmi four-in-a-row_alpine18:latest

make sure no image and no container left :

execute docker run with deployed image (idubi/four-in-a-row_alpine18:latest) and make sure it is up and running

docker run -d --name test -p=5173:5173 idubi/four-in-a-row_alpine18:latest

if anyone want me to go on either of the subjects I discussed here please write in comments :

github actions , hooks , 3rd party ...
github submodule / subtree
different AI approaches for the AI game setting -
- what is a deep learnign model.
- how we can train a machine
- how to train a model using Reinforcmeent learnign approaches

Docker Fundamentals - 40 days of K8s - CKA challenge

ido bistry — Fri, 18 Apr 2025 02:15:57 +0000

40 days of K8s - CKA challenge (01/40)

Docker Fundamentals

Docker Tutorial For Beginners - Docker Fundamentals - CKA Full Course 2025
@piyushsachdeva

explaining the docker life sycle

created a diagram and explainng it :

## Docker Architecture Diagram u

we can see that the docker images are all can be hosted in one host machine.
this machine has its own OS and virtualization layer that allow the docker images exist - each one on its own resources.
each container has its app running on its own OS thatcan be of any kind

Docker Workflow

the lifecycle of docker image as described in the diagram :

created as a Dockerfile that then pushed to a version control repo
then we build the image from Dockerfile to make sure it run in the dev env
after making sure the image works - we push it then to docker repository
test env will use the docker image by pulling it and then running it
after the test approves the docker image - the production will then use it same as test - by pulling it and running it (which can be achived in 1 command : docker run)