Kuberise.io
Workshops

Kubernetes Basics Workshop

Learn the basics of Kubernetes and how to deploy applications on a Kubernetes cluster

Benefits of containers

  • Portable
  • Cloud deployable
  • Scalable (Scale-in and Scale-out)
  • Declarative format
  • Good for microservices

Challenge: Managing many containers in several servers

What is Kubernetes?

  • Container orchestration system
    • Deploying
    • Scaling
    • Networking
    • Storage
    • Security
    • Monitoring
    • Logging
    • Automatic cluster resource management

Kubernetes Certification

  • CKAD (Certified Kubernetes Application Developer)
  • CKA (Certified Kubernetes Administrator)
  • CKS (Certified Kubernetes Security Specialist)
  • KCNA (Kubernetes and Cloud Native Associate)
  • KCSA (Kubernetes and Cloud Native Security Associate)
  • Kubestronaut (When you get all certifications)

certification

Learning Resources and Exam Simulators

Kubernetes Playground

Core Kubernetes Components

Control Plane

  • Manages the Kubernetes cluster
  • One or more nodes
  • Components:
    • API Server: Exposes the Kubernetes API
    • ETCD: Key-value store for cluster data
    • Controller Manager: Runs controllers to manage the state of the cluster
    • Scheduler: Assigns workloads to nodes

Data Plane

  • Executes the workloads
  • Zero or more nodes
  • Components:
    • Kubelet: Runs on each node to manage containers
    • Kube Proxy: Manages network rules for communication between pods
    • Container Runtime: Runs containers (e.g. docker, containerd)

kubectl

  • CLI tool for Kubernetes
  • ~/.kube/config: default config file that stores cluster address and credentials
  • KUBECONFIG environment variable: Override default config file address
  • Kubernetes context: Cluster, namespace, user
  • kubectx: A utility to switch between different Kubernetes contexts.
  • kubens: A utility to switch between different Kubernetes namespaces.

Practice:

Terminal
kubectl cluster-info
kubectl config view
kubectl config get-contexts

kubectx
kubens

kubectl get nodes
kubectl get pods --all-namespaces

kubectl api-resources -o wide
kubectl api-resources --namespaced=false

Imperative vs. Declarative

  • Imperative: Directly instruct Kubernetes to perform actions.
  • Declarative: Define desired state in a config file; Kubernetes ensures current state matches it.

Imperative Example

# Imperative command to create a pod
kubectl run my-pod --image=nginx

# Imperative command to create a deployment with 3 replicas
kubectl create deployment my-deployment --image=nginx --replicas=3

# Imperative command to scale a deployment to 5 replicas
kubectl scale deployment my-deployment --replicas=5

# Imperative command to create a service with NodePort type
kubectl expose deployment my-deployment --type=NodePort --port=80 --target-port=80

# Imperative command to create a secret from a file
kubectl create secret generic my-secret --from-literal=username=admin --from-literal=password=secretpass

# Imperative command to create a configmap from a file
kubectl create configmap my-config --from-literal=port=8080
Try to run it twice and see what happens.

Declarative Example

To create a pod declaratively, you define the pod in a YAML file and then apply it:

pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: nginx
    image: nginx

Apply the configuration using kubectl apply:

# Declarative command to create a pod
kubectl apply -f pod.yaml
Try to run it twice and see what happens.

Kubernetes Resource Structure

All Kubernetes resources are defined in YAML format and consist of four main parts:

  1. apiVersion: Specifies the API version (e.g., v1, apps/v1).
  2. kind: Specifies the type of resource (e.g., Pod, Deployment).
  3. metadata: Provides metadata about the resource, such as its name and labels.
  4. spec: Defines the desired state of the resource.

Most Frequently Used Kubernetes Resources

  • Pod: The smallest and simplest Kubernetes object. Represents a single instance of a running process in a cluster.
  • Deployment: Manages a set of identical pods, ensuring the desired number of pods are running and updating them in a controlled manner.
  • Service: Defines a logical set of pods and a policy by which to access them. Provides stable IP addresses and DNS names.
  • ConfigMap: Used to store non-confidential data in key-value pairs. ConfigMaps can be consumed in pods as environment variables, command-line arguments, or configuration files.
  • Secret: Similar to ConfigMap, but designed to hold sensitive information such as passwords, OAuth tokens, and SSH keys.
  • Namespace: Provides a mechanism to partition resources within a single Kubernetes cluster. Useful for dividing cluster resources between multiple users or teams.
  • Ingress: Manages external access to services in a cluster, typically HTTP. Provides load balancing, SSL termination, and name-based virtual hosting.
  • StatefulSet: Manages the deployment and scaling of a set of pods, and provides guarantees about the ordering and uniqueness of these pods.
  • 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.
  • Job: Creates one or more pods and ensures that a specified number of them successfully terminate. Used for batch processing.
  • CronJob: Manages time-based jobs, similar to cron jobs in Unix/Linux. Schedules jobs to run at specified times or intervals.
  • PersistentVolume (PV): A piece of storage in the cluster that has been provisioned by an administrator or dynamically provisioned using Storage Classes.
  • PersistentVolumeClaim (PVC): A request for storage by a user. It is similar to a pod.
  • StorageClass: Provides a way for administrators to describe the "classes" of storage they offer.
  • NetworkPolicy: Specifies how groups of pods are allowed to communicate with each other and other network endpoints.
  • ResourceQuota: Provides constraints that limit aggregate resource consumption per namespace.
  • LimitRange: Provides constraints that limit resource consumption per pod or container in a namespace.
  • HorizontalPodAutoscaler: Automatically scales the number of pods in a deployment, replica set, or stateful set based on observed CPU utilization or other select metrics.
  • Node: Represents a worker machine in Kubernetes. May be a VM or physical machine, depending on the cluster.
  • ServiceAccount: Provides an identity for processes that run in a pod.
  • Role: A set of permissions within a namespace.
  • RoleBinding: Grants the permissions defined in a role to a user or set of users.
  • ClusterRole: A set of permissions that can be granted across all namespaces in a cluster.
  • ClusterRoleBinding: Grants the permissions defined in a cluster role to a user or set of users across all namespaces in a cluster.

Pod

  • Smallest unit in Kubernetes
  • Includes one or more containers
  • Containers share network and storage and can communicate with each other using localhost
  • Containers in a pod are scheduled on the same node
  • Containers in a pod have the same lifecycle
  • initContainers: Containers that run before the main container starts
  • Sidecar pattern: Additional container in a pod that provides supporting features

Pod Example

Resource Management in Pods

  • Resource Requests: Minimum resources guaranteed to the pod
    • CPU: Measured in cores (0.5 = half core)
    • Memory: Measured in bytes (Mi = Mebibytes, Gi = Gibibytes)
  • Resource Limits: Maximum resources the pod can use
    • Prevents resource exhaustion
    • Pod is terminated if it exceeds memory limits
    • CPU is throttled if it exceeds CPU limits

Deployment

  • Manages pods
  • Ensures desired state
  • Can scale pods
  • Canary deployment

Example:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx

more examples

Service

  • Exposes pods to the network
  • Load balances traffic
  • Types: ClusterIP, NodePort, LoadBalancer, ExternalName, Headless, and more

Service Examples

Types of Services

ClusterIP

  • Default service type.
  • Exposes the service on an internal IP in the cluster.
  • Makes the service only reachable from within the cluster.
  • Use case: Internal communication between services within the cluster.

NodePort

  • Exposes the service on each node's IP at a static port (the NodePort).
  • A ClusterIP service, to which the NodePort service routes, is automatically created.
  • Makes the service accessible from outside the cluster using <NodeIP>:<NodePort>.
  • Use case: Simple external access to services for development or testing.

LoadBalancer

  • Exposes the service externally using a cloud provider's load balancer.
  • A ClusterIP service, to which the external load balancer routes, is automatically created.
  • Use case: Production environments where you need to expose services to the internet.
  • When using a cloud provider, the external IP address is automatically assigned to the load balancer.
  • When using a local cluster, the service remains pending. You can use metalLB to assign an external IP address.

ExternalName

  • Maps the service to the contents of the externalName field (e.g., external-database.com).
  • Does not create a proxy, only returns a CNAME record.
  • Use case: Integrating with external services using DNS names.
  • Want to abstract the database endpoint from your applications
  • Applications can use external-database.namespace.svc.cluster.local
  • Makes it easier to switch environments or providers

Headless Service (Stateful Applications):

  • Use case: Running a database replica set
  • Pods need to discover and communicate directly with each other
  • Used with StatefulSets for stable network identities
  • Each pod gets a DNS entry like pod-0.mongodb-headless.namespace.svc.cluster.local

Service without Selector:

  • Use case: Integrating with legacy systems outside Kubernetes
  • Have specific IPs that need to be targeted
  • Manually manage endpoints
  • Useful for gradual migration to Kubernetes

A scenario where you might use a service without a selector:

  • You have legacy servers running on-premises with fixed IPs
  • Create a service without selector in Kubernetes
  • Manually create an Endpoints resource pointing to those IPs
  • Your Kubernetes applications can now communicate with the legacy servers using the service name
  • When you migrate the legacy application to Kubernetes, you can:
    • Delete the Endpoints
    • Add selectors to the service
    • Deploy the application with matching labels

Multi-port Service:

  • Use case: Running an application that exposes multiple protocols
  • HTTP for main traffic
  • HTTPS for secure communication
  • Metrics port for monitoring

ConfigMap

  • Stores configuration data
  • Decouples configuration from pods
  • Can be consumed as environment variables, command-line arguments, or configuration files

ConfigMap Example

Declarative

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-config
data:
  key: value

Imperative

# Imperative command to create a configmap
kubectl create configmap my-config --from-literal=key=value

Secret

  • Stores sensitive data
  • Encoded in base64
  • Decouples secrets from pods

Secret Example

Declarative

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
type: Opaque
data:
  username: dXNlcm5hbWU=
  password: cGFzc3dvcmQ=

Imperative

# Imperative command to create a secret
kubectl create secret generic my-secret --from-literal=username=admin --from-literal=password=secretpass

Resources

Scaling Terminology

  • Scale Out/In: Horizontal scaling - adding or removing container instances
    • Scale Out: Adding more container instances to handle increased load
    • Scale In: Removing container instances when demand decreases
  • Scale Up/Down: Vertical scaling - adjusting resource allocation
    • Scale Up: Increasing resources (CPU, memory) for containers
    • Scale Down: Decreasing allocated resources when less is needed

Namespace

  • Logical partition of a cluster
  • Used to divide resources
  • Unique names within a namespace

Labels

  • Key-value pairs attached to Kubernetes objects
  • Used to organize and select subsets of objects
  • Can be added to pods, services, replication controllers, and more
  • Labels do not provide uniqueness; multiple objects can have the same label

Label Example

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  labels:
    app: nginx
    environment: production
spec:
  containers:
  - name: nginx
    image: nginx

Label Selector

  • Used to select objects based on their labels

Example:

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: nginx
    environment: production
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

Taints and Tolerations

  • Taints: Applied to nodes to restrict certain pods
    • Key-value pair with an effect (NoSchedule, PreferNoSchedule, NoExecute)
    • Example: kubectl taint nodes node1 processor=gpu:NoSchedule
  • Tolerations: Applied to pods to allow them to be scheduled on nodes with matching taints
    • Example: 
      apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: nginx
    image: nginx
  tolerations:
  - key: "gpu"
    operator: "Equal"
    value: "gpu"
    effect: "NoSchedule"

Node Affinity

  • Used to constrain which nodes your pod is eligible to be scheduled on
  • Types:
    • requiredDuringSchedulingIgnoredDuringExecution: Must be met for the pod to be scheduled
    • preferredDuringSchedulingIgnoredDuringExecution: Tries to meet the criteria but not mandatory

Node Affinity Example

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: nginx
    image: nginx
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: processor
            operator: In
            values:
            - gpu

Workload kinds in Kubernetes

  • Pod
  • Deployment
  • StatefulSet
  • DaemonSet
  • Job
  • CronJob

StatefulSet

  • Manages the deployment and scaling of a set of pods
  • Provides guarantees about the ordering and uniqueness of these pods
  • Used for stateful applications

StatefulSet benefits

StatefulSets are primarily designed for applications that require:

  1. Stable, Unique Network Identifiers
  • Each pod gets a predictable hostname and DNS name that persists across rescheduling
  • Format: $(statefulset-name)-$(ordinal)
  • Example: For a StatefulSet named "mysql", pods will be mysql-0, mysql-1, mysql-2, etc.
  1. Stable, Persistent Storage
  • Each pod gets its own persistent volume that remains attached even if the pod is rescheduled
  • Volumes are not deleted when pods are deleted, preserving data
  • Perfect for databases where data persistence is critical
  1. Ordered Deployment and Scaling
  • Pods are created in sequential order (0, 1, 2...)
  • Scaling down happens in reverse order
  • Useful for primary-replica architectures where order matters

StatefulSet Use Cases:

  • Distributed databases with primary-replica architecture (MongoDB, MySQL, PostgreSQL)
  • Message brokers (Kafka, RabbitMQ)
  • Distributed file systems (GlusterFS)
  • Any application needing
    • stable and predictable network identities/hostnames/DNS names
    • persistent storage
    • service discovery in distributed systems
    • leader election scenarios

DaemonSet

  • Ensures that all nodes run a copy of a pod
  • As nodes are added to the cluster, pods are added to them
  • Used for cluster-wide services like log collection, monitoring metrics, and storage daemons

Job

  • Creates one or more pods and ensures that a specified number of them successfully terminate
  • Used for batch processing

Example:

apiVersion: batch/v1
kind: Job
metadata:
  name: my-job
spec:
  template:
    spec:
      containers:
      - name: my-container
        image: my-image
      restartPolicy: OnFailure
  backoffLimit: 4

CronJob

  • Manages time-based jobs, similar to cron jobs in Unix/Linux
  • Schedules jobs to run at specified times or intervals

Example:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: my-cronjob
spec:
  schedule: "*/5 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: my-container
            image: my-image
          restartPolicy: OnFailure

Volumes in Pods

emptyDir

  • Good for temporary storage that is shared between containers.
  • Data is removed when the pod is removed.

hostPath

  • Maps a file or directory from the host node's filesystem into a pod.
  • Useful for logging, monitoring, or integrating with host-level services.
  • Must be used with caution as it ties the pod to a particular node.

nfs Volume

  • Mounts an NFS share into a pod.
  • Useful for sharing files between pods or persisting data across pod restarts.
  • Requires an NFS server to be accessible from the cluster.

configMap Volume

  • Uses data stored in a ConfigMap as a volume.
  • Allows configuration data to be consumed as files within the pod.
  • Useful when applications require config files rather than environment variables.

secret Volume

  • Similar to ConfigMap volumes, but designed for sensitive data.
  • Data is stored as files and is base64 encoded.
  • Useful for supplying credentials or certificates.

persistentVolumeClaim (PVC)

  • Abstracts underlying persistent storage.
  • Allows dynamic or static provisioning of storage.
  • Ideal for applications needing data persistence beyond pod lifecycles.

Additional Kubernetes Resources

PersistentVolume (PV)

  • A piece of storage in the cluster provisioned by an administrator or dynamically using Storage Classes.
  • Provides storage to be used by pods.

PersistentVolumeClaim (PVC)

  • A request for storage by a user.
  • Similar to a pod, but for storage resources.

StorageClass

  • Describes the "classes" of storage offered by administrators.
  • Used to define different types of storage (e.g., SSD, HDD).

NetworkPolicy

  • Specifies how groups of pods are allowed to communicate with each other and other network endpoints.
  • Used to control traffic flow at the IP address or port level.

ResourceQuota

  • Provides constraints that limit aggregate resource consumption per namespace.
  • Ensures fair distribution of resources among different namespaces.

LimitRange

  • Provides constraints that limit resource consumption per pod or container in a namespace.
  • Helps to prevent resource exhaustion by setting minimum and maximum resource limits.

HorizontalPodAutoscaler

  • Automatically scales the number of pods in a deployment, replica set, or stateful set based on observed CPU utilization or other select metrics.
  • Ensures applications can handle varying loads efficiently.

Node

  • Represents a worker machine in Kubernetes.
  • Can be a virtual machine (VM) or physical machine, depending on the cluster setup.

ServiceAccount

  • Provides an identity for processes that run in a pod.
  • Used to grant permissions to pods to interact with the Kubernetes API.

Role

  • A set of permissions within a namespace.
  • Defines what actions can be performed on resources within that namespace.

RoleBinding

  • Grants the permissions defined in a role to a user or set of users.
  • Binds a role to a user or group within a namespace.

ClusterRole

  • A set of permissions that can be granted across all namespaces in a cluster.
  • Used for cluster-wide permissions.

ClusterRoleBinding

  • Grants the permissions defined in a cluster role to a user or set of users across all namespaces in a cluster.
  • Binds a cluster role to a user or group for cluster-wide access.

Helm

  • Kubernetes package manager
  • ArtifactHub.io: A public helm chart repository.
  • Simplifies deployment and management of applications on Kubernetes
  • Uses charts to define, install, and upgrade applications
  • Charts are packages of pre-configured Kubernetes resources

Helm Components

  • Helm CLI: Command-line tool that interacts with the cluster.
  • Charts: Collections of files that describe a related set of Kubernetes resources.
  • Release: An instance of a chart running in a Kubernetes cluster.

Helm Commands

  • helm repo add: Add a chart repository.
  • helm search repo: Search for charts in repositories.
  • helm install: Install a chart.
  • helm upgrade: Upgrade a release to a new chart or version.
  • helm list: List releases.
  • helm uninstall: Uninstall a release.

Helm Chart Structure

  • Chart.yaml: Contains metadata about the chart.
  • values.yaml: Default configuration values for the chart.
  • templates/: Directory containing Kubernetes resource templates.
  • charts/: Directory containing dependent charts.

kuberise.io

  • An open-source Internal Developer Platform for Kubernetes
  • GitOps-based deployment with ArgoCD
  • DRY (Don't Repeat Yourself) approach
    • Same templates for all environments
    • Different values for each environment
  • ArgoCD app of apps pattern
  • Enable or disable platform tools
  • Add your developer applications
  • Single templates folder
  • Values folder for each platform
Terminal
./scripts/install.sh minikube onprem https://github.com/kuberise/kuberise.io.git main onprem.kuberise.dev

Kuberise dashboards

  • ArgoCD
  • Grafana
  • Keycloak (Single Sign-On)
  • Sample Developer Applications

k9s

  • k9s is a Terminal-based UI for Kubernetes
  • namespaces
  • pods
  • deployments
  • services
  • secrets
  • configmaps
  • ingress

Copyright © 2025. All rights reserved.