DEV Community: gurunadh

Kubernetes

gurunadh — Sat, 10 Aug 2024 19:34:30 +0000

Kubernetes is an open-source container orchestrator. To know about container orchestration and orchestrators visit Container Orchestration.

Kubernetes is sometimes shortened to k8s, as there are 8 characters between K and S.

History

Kubernetes originated from a Greek word κυβερνήτης (kubernḗtēs), meaning 'helmsman' or 'ship pilot'. As the name suggests, Kubernetes acts as the pilot on the ship of containers.

Kubernetes was originally developed by Google as part of their Borg System (Cluster Manager) and was later donated it to Cloud Native Computing Foundation (CNCF).

Features

Automated Rollouts and Rollbacks

Kubernetes progressively rolls out changes to your application or its configuration, while monitoring application health to ensure it doesn't kill all your instances at the same time. If something goes wrong, Kubernetes will roll back the change for you.

Service Discovery and Load Balancing

No need to modify your application to use an unfamiliar service discovery mechanism. Kubernetes gives Pods their own IP addresses and a single DNS name for a set of Pods, and can load-balance across them.

Storage Orchestration

Automatically mount the storage system of your choice, whether from local storage, a public cloud provider, or a network storage system such as iSCSI or NFS.

Self Healing

Restarts containers that fail, replaces and reschedules containers when nodes die, kills containers that don't respond to user-defined health check, and doesn't advertise them to clients until they are ready to serve.

Secret and Configuration Management

Deploy and update Secrets and application configuration without rebuilding your image and without exposing Secrets in your stack configuration.

Automatic Bin Packing

Automatically places containers based on their resource requirements and other constraints, while not sacrificing availability.

Batch Execution

In addition to services, Kubernetes can manage your batch and CI workloads, replacing containers that fail, if desired.

Horizontal Scaling

Scale your application up and down with a simple command, with a UI, or automatically based on CPU usage.

IPV4/IPV6 dual stack
Supports both IPv4 and IPv6 addresses.

Portability

Kubernetes can be deployed in many environments such as local, remote VMs, in public/private/hybrid clouds.

Architecture

Kubernetes' architecture consists of

Control Plane Node
Worker Node

Worker Node & Components

Worker nodes provide a runtime environment for applications deployed in the cluster. Applications will be deployed only in the worker node, not in control plane node.

In multi-worker cluster traffic, between client and application deployed in Pods is handled directly by the worker node and is not routed through the control plane node. Each node can have multiple Pods in it.

Worker nodes must have three components.

Container Runtime
Although Kubernetes is a container orchestrator, it cannot run the containers directly. In order to manage container's lifecycle, Kubernetes needs a container runtime on both the worker node and control plane node.

Popular runtime tools in Kubernetes

CRI-O - A lightweight container runtime for k8s.
containerd - A simple robust and portable container runtime.
Docker engine - Earlier it was the default runtime but deprecated in kubernetes version 1.20

Kubelet

Kubelet takes a set of PodSpec (simple yaml object that describes pod specifications) primarily from API server and is responsible to create the pod, assigns resource to the container from the node and manage containers lifecycle in the pod by interacting with the container runtime.

Kube-proxy
Kube proxy handles communication to and from pods that are part of a service within the cluster.

It forwards the requests between pods in an efficient manner and with low overhead.

Control Plane Node & Components

The control plane's components make global decisions about the cluster as well as detecting and responding to cluster events like starting up a new pod when Deployment replica's field is unsatisfied.

There are 4 main components in control plane

API Server

API Server acts as a cluster gateway also acts as gatekeeper for authentication of the Kubernetes. It is a critical component in Kubernetes that manages all the communication in the cluster.

We can run multiple api-server to balance the traffic.

Scheduler

When there is a request from client to schedule a pod, API server sends request to Scheduler to start the pod in one of the worker nodes. Scheduler is smart enough to choose a node that meets the pod requirements like ram, cpu, and least busy node with the required specification will be chosen to create the pod.

Scheduler just decides on which node a pod should be scheduled, while kubelet is responsible to create the pod.

etcd

It is the cluster brain, a consistent and highly-available key value store used as Kubernetes' backing store for all cluster data and not applications' data deployed in the cluster.

Every change in the cluster, when a new Pod gets scheduled, when a Pod dies, application deployment state, cluster health — all these changes will be stored as key-value store in etcd.

New data is written to the data store only by appending, data is never replaced, but obsolete data is deleted periodically to minimize size of the data store.

Controller Manager

Controller manager detects the cluster state change, when a pod dies in any node, the controller manager creates a new pod object and sends a request to the API server to create a pod with a desired state which will then send a request to the scheduler.

Kubernetes doesn't guarantee that the replacement for an existing pod will be scheduled to the same node as the old pod that was being replaced.

Container Orchestration

gurunadh — Sat, 10 Aug 2024 18:04:21 +0000

Before learning about Container Orchestration lets learn about Containers.

Containers

Containers are application centric method to deliver high performing and scalable application on any infrastructure of our choice. It is best suited to deliver microservices by providing portable, isolated virtual environments.

Containers encapsulate microservices and their dependencies but do not run them directly. Containers run container images.

Container Image bundles the application along with its runtime, libraries and dependencies, and it represents the source of a container deployed to offer an isolated executable environment to run the application.

Containers can be deployed from a specific image on many platforms such as virtual machines, public cloud.

Now lets dive into Container Orchestration.

Container Orchestration

In development environments, using the container on a single host for application development and testing can be practical, but when moving to QA and Prod environments requires several critical criteria.

Efficient resource utilization
On-demand scalability
Fault tolerance
Ability to perform updated and rollbacks without downtime
Auto discovery for seamless inter-service communication
Self-healing

Container Orchestration is the process of combining multiple systems into clusters, automating the deployment and management of containers at scale and the ability to monitor the container health and automatically replaces or restarts the failed containers while fulfilling the above-mentioned requirements.

These clusters leverage the benefits of distributed systems, including enhanced performance, cost-effectiveness, reliability, balanced workload distribution and lower latency.

Container Orchestrators are the tools that facilitates container orchestration and provides necessary functionalities to perform the above mentioned requirements.

Popular Container Orchestrators are:

Kubernetes is an open source orchestration tool, originally developed by Google, later donated to the Cloud Native Computing Foundation (CNCF).

Docker Swarm is a container orchestrator provided by Docker and is part of docker engine.

Amazon ECS is a fully managed container orchestration service by AWS.

Azure Container Instances (ACI) is a basic container orchestration tool provided by Microsoft Azure.

Nomad is a container and workload orchestrator provided by HashiCorp.

As container orchestration continues to evolve, embracing its capabilities not only enhances operational efficiency but also drives innovation in modern IT infrastructures.

Jenkins

gurunadh — Sat, 10 Aug 2024 17:04:25 +0000

Jenkins is an automation tool widely used for Continuous Integration (CI) and Continuous Delivery (CD). It helps
automate various stages of the software development process, including building, testing and deploying.

Pipeline
In Jenkins, to automate the stages of the software development process, we can define a pipeline. A pipeline is a set of
stages that are linked together to form a processing system, executed sequentially.

A Jenkins pipeline can be in two formats.

Declarative format
Scripted format

Both formats are written in Groovy. The Scripted pipeline provides more flexibility than the Declarative format but is more verbose.
We will discuss Declarative format.

Basic Structure

Basic structure of a pipeline consists of

P — pipeline

A — agent

S — stages

S — stage

S — steps

Pipeline — all stages, steps, post actions etc. will be defined in this block.

pipeline {
    // Pipeline configuration written here
}

Agent — is a node or container that connects to a Jenkins controller and executes tasks as directed by the Jenkins
controller. To use any available node or agent, we can use the any keyword.

pipeline {
    agent any
}

Stages — define the sequence of stages that will be executed in a pipeline. We can have only one stages block.

pipeline {
    agent any
    stages {
        // Consists of different stage executions
    }
}

Stage — is used to define the steps to execute a process.

pipeline {
    agent any
    stages {
        stage ("Stage name"){
            // Consists of steps to execute a stage
        }
    }
}

Steps — used to define set of instructions to perform in a stage. Only one steps block is allowed in a stage.

pipeline {
    agent any
    stages {
        stage ("Stage name"){
            steps {
                // Set of instructions of the stage
            }
        }
    }
}

Basic Structure

pipeline {
    agent any
    stages {
        stage ("Build"){
            steps {
                sh "echo Build stage"
            }
        }
        stage ("Test"){
            steps {
                sh "echo Test stage"
            }
        }
        stage ("Quality"){
            steps {
                sh "echo Quality stage"
            }
        }
        stage ("Deploy"){
            steps {
                sh "echo Deploy stage"
            }
        }
    }
}

Timeout & Retry

Timeout

Sometimes build can hang, due to unresponsive process, in that case we can wrap the step using timeout, when a step takes long time then expected, timeout will abort the pipeline.

pipeline {
    agent any
    stages {
        stage("Deploy"){
            steps {
                timeout(time: 3, unit: 'MINUTES') {
                    sh "./deploy.sh"
                }
            }
        }
    }
}

In this pipeline, if deploy.sh script takes more than 3 minutes, timeout will abort the pipeline.

Retry

When there is an exception while executing a stage sometimes retrying would solve the case. In Jenkins we can retry block.

pipeline {
    agent any
    stages {
        stage("Deploy"){
            steps {
                retry {
                    sh "./deploy.sh"
                }
            }
        }
    }
}

Here, deploy.sh script will be executed at max 3 times, if there is an exception.

We can use timeout inside retry block and vice versa. If we want to retry the steps for n times but don't want to spend more than m minutes, we can nest retry block inside timeout block.

pipeline {
    agent any
    stages {
        stage("Deploy"){
            steps {
                timeout(time: 3, unit: 'SECONDS') {
                    retry(3){
                        sh "./deploy.sh"
                    }
                }
            }
        }
    }
}

Here, pipeline will fail if total time exceeds 3 minutes, or script throws exception even after 3 times.

If we want to retry for n times with m minutes for each retry, we can next timeout in a retry block.

pipeline {
    agent any
    stages {
        stage("Deploy"){
            steps {
                retry(3){
                    timeout(time: 3, unit: 'MINUTES'){
                        sh './deploy.sh'
                    }
                }
            }
        }
    }
}

Post Actions

Post block in Jenkins pipeline is used to handle tasks not limited to, sending notifications, cleanup, and archiving artifacts, at the end of pipeline based on the outcome of pipeline.
Post block is a sibling block to stages.
Some of the post actions are:

always

Used to execute set of actions irrespective of pipeline outcome. It has high priority and runs first.

pipeline {
    agent any
    post {
        always {
            sh "echo Always block will get executed irrespective of pipeline status"
        }
    }
}

changed

Executes if pipeline's current state differs from previous state and will be executed just after always block.

pipeline {
    agent any
    post {
        changed {
            sh "echo Pipeline state defers from previous state"
        }
    }
}

success

Executes only if pipeline completes successfully.

pipeline {
    agent any
    post {
        success {
            sh "echo Executes if pipeline completes successfully"
        }
    }
}

failure

Executes only if pipeline fails.

pipeline {
    agent any
    post {
        failure {
            sh "echo Executes if pipeline fails"
        }
    }
}

aborted

Executes if pipeline is aborted.

pipeline {
    agent any
    post {
        aborted {
            sh "echo Pipeline is aborted"
        }
    }
}

unstable

Executes when pipeline is marked as unstable.

pipeline {
    agent any
    post {
        unstable {
            sh "echo Pipeline is unstable"
        }
    }
}

unsuccessful

Executes when the pipeline is aborted, failed, or unstable.

pipeline {
    agent any
    post {
        unsuccessful {
            sh "echo Pipeline did not complete successfully"
        }
    }
}

fixed

Executed when the pipeline’s current state is successful and the previous state was failed or unstable.

When post block has both success and fixed blocks, the fixed block will be executed before success block.

pipeline {
    agent any
    post {
        fixed {
            sh "echo Pipeline fixed"
        }
    }
}

regression

In general regression refers to a situation where there is a decline or deterioration in quality or performance.

In the context of Jenkins, regression block get executed, when the pipeline’s current state deteriorates from a previous successful or unstable state to a failed, aborted, or unstable state, but both the previous and current states cannot be unstable at the same time.

pipeline {
    agent any
    post {
        regression {
            sh "echo Pipeline deteriorated to ${currentBuild.currentResult}"
        }
    }
}

cleanup

Used for removing or managing resources and files that are not needed after a build has completed. This ensures workspace remains clean and helps avoid potential issues from leftover files from previous builds.

It will be executed after all post blocks.

pipeline {
    agent any
    post {
        cleanup {
            sh "./clean-up.sh"
        }
    }
}