Forem: Senthil Raja Chermapandian

A Gentle Introduction to WebAssembly

Senthil Raja Chermapandian — Wed, 03 May 2023 07:22:00 +0000

What is WebAssembly?

WebAssembly provides a secure, fast, and efficient compilation target for a wide range of modern programming languages. WebAssembly’s simplicity as a runtime and sandbox environment lends to various use cases such as containers, blockchain and IoT.

The Web needed a new Programming Language

During JavaScript’s earlier years as a scripting language, interactions were limited to dynamic menus, button-clicked responses, and pop-up dialogs. JavaScript as a language experienced great growth in the pursuit of interactivity.

However, Javascript suffers in execution speed and performance predictability compared to compiled languages. JavaScript lacked the ability to advance browsers with features such as low-level networking, multithreaded code, graphics, and streaming video codecs. This limitation affected applications where performance is critical, such as video editing, CAD, and AI.

WebAssembly (wasm) serves to address some of JavaScript’s limitations. Wasm was designed as a compact compilation target to enhance performance for the web. In 2017 when WebAssembly was released, the WebAssembly working group stated,

“WebAssembly or wasm is a new portable, size- and load-time-efficient format suitable for compilation to the web.”

WebAssembly is an instruction-set architecture with low-level bytecode that runs on web browsers (and servers). WebAssembly serves as a compilation target for higher-level languages including C++, Rust, C, and Go.

Design Goals

WebAssembly was developed by a team called the W3C WebAssembly Community Group. This group included engineers from Mozilla, Google, Apple, Microsoft, and various other organizations. The W3C WebAssembly Community Group solidified key design goals as a foundation for WebAssembly in the project’s infancy. The team prioritized efficiency, portability, legibility, security, and compatibility.

The most significant of these goals include:

Minimum Viable Product (MVP)
Performance
Security
Independency

WebAssembly’s unique features inspired adoption for a range of applications. We will dig into notable features of WebAssembly beyond the browser.

Minimum Viable Product

Web specifications are generally developed through collaboration amongst multiple parties. Often this results in initial ideas slowly going through specification before implementation. To expedite the process, the initial WebAssembly specification was conceived as a Minimum Viable Product (MVP) with a number of specific use cases targeted for the MVP scope.

The MVP features met the needs of image processing, audio processing, computer aided design, games, and various other applications that are computationally intensive. The tooling developed around the MVP focused on the migration of existing applications, predominantly those written in C++. The MVP was not designed as a general-purpose web application development platform.

This focused approach ensured that WebAssembly was quickly released in just a few years. However, the initial release was missing certain features that could make it more broadly useful. More features have been and will continue to be released over time.

These design decisions have resulted in a technology that is rapidly loaded, decoded, and executed at near-native speed.

Performance

Initial download speed, compilation time, and runtime performance hold parallel importance for web technologies. With a size and load-time efficient binary, WebAssembly optimally utilizes common hardware capabilities to execute at near-native speed.

Historically, JavaScript design decisions hindered the language’s performance. While JavaScript evolved to mitigate limitations, WebAssembly addresses some issues directly.

Issues Include:

JavaScript is distributed in text format and WebAssembly is a binary.
JavaScript is not strongly typed, so optimization requires complex runtime monitoring. WebAssembly is strongly typed and can be compiled very quickly to the native machine code.
The WebAssembly binary format is designed to support parallel decoding across multiple threads and streamed instantiation.

WebAssembly’s efficiency applies to host targets beyond the web. The W3C group carefully specified “host” rather than “browser” regarding a host which loads and interoperates with WebAssembly. Modules can be hosted and executed across several environments, including cloud, Internet of Things (IoT), or blockchain.

Security

WebAssembly runs in the browser and from a security perspective, browsers are rife with vulnerabilities. WebAssembly incorporates a few features which help to mitigate opportunities for exploits.

The WebAssembly runtime adheres to the same security policies as its host environment. Within the web, WebAssembly conforms to the same-origin policy; a page cannot load and execute a malicious WebAssembly module from a different origin.

WebAssembly modules run within a sandbox and are therefore isolated from the host environment, so all functionality must be imported. This sandbox separates the execution environments of different modules. In addition, the sandbox validates code to minimize data corruption.

WebAssembly can access linear memory and functions but requires a host for import and export. The lack of I/O significantly reduces the attack surface as the WebAssembly instance is only able to access what is available through the interfaces it is linked with.

Independency

Aspects of WebAssembly, such as its low-level binary format, lend towards independencies contributing to the language’s portability and performance.

Hardware Independent:
WebAssembly compiles on all modern systems, including desktop and mobile.

Language Independent:
WebAssembly acts as a compilation target for various languages and continues to innovate by implementing requests. WebAssembly does not promote or favor any language. Coding language communities generate additional tools for utilizing WebAssembly.

Platform Independent:
WebAssembly’s host can be browser or non-browser. WebAssembly can be embedded in browsers, run as a virtual machine, and more.

WebAssembly as a non-browser runtime

Initially, WebAssembly targeted specific browser-based use cases, such as migrating performance-intensive applications into the browser. However, WebAssembly retains a platform-agnostic host environment. WebAssembly has been adopted as a non-browser runtime due to a few features:

Sandbox Environment:
WebAssembly modules provide a layer of security because modules execute within a sandbox environment. The environment increases safety for cloud computing where executing processes share the same underlying physical resources.

Vendor-neutral:
WebAssembly is flexible and untied to a particular vendor. This versatility allows for use cases to expand and meet various needs.

Runtime:
Runtime features, such as streaming compilation and simple validation rules, contribute to fast start times and near-native performance.

Memory:
WebAssembly does not have a specific approach to memory management (e.g., garbage collection) or its own system-level APIs. As a result, the WebAssembly runtime is simple and lightweight.

Bytecode Alliance

WebAssembly’s rapid adoption spurred innovation and investment from various organizations. Many projects sought to extend similar capabilities and solutions. In response, the founding organizations Mozilla, Red Hat, Intel, and Fastly formed the Bytecode Alliance to foster collaboration and promote innovation.

The Bytecode Alliance’s mission is to:

“provide state-of-the-art foundations to develop runtime environments and language toolchains where security, efficiency, and modularity can all coexist across a wide range of devices and architectures.”

The Bytecode Alliance initiated a sub-project called the WebAssembly System Interface (WASI). WASI is an API that allows WebAssembly access to system features such as files, filesystems, Berkeley sockets, clocks, and random numbers. WASI acts as a system-level interface for WebAssembly, so incorporating a runtime into a host environment and building a platform is easier.

While WASI runs in the browser, WASI is not browser-dependent and therefore does not rely on Web APIs or Javascript compatibility. With WASI, WebAssembly modules can run outside of the browser. Wasmtime, another Bytecode Alliance project, is a WebAssembly runtime that can be used as a host for non-browser use cases.

WASI maintains WebAssembly’s security advantages by extending WebAssembly’s sandboxed environment to include I/O. The API isolates modules and provides each module with permissions to particular parts of the system.

WASI use cases include cross-platform applications, code reuse across platforms, and a single runtime for applications. The Bytecode Alliance continues to contribute and accept projects with several roadmap goals for WASI addressed in online documentation on the Bytecode Alliance website.

GitHub Actions workflow for Go Continuous Integration

Senthil Raja Chermapandian — Mon, 07 Mar 2022 21:53:29 +0000

Author: Saravanan is Polyglot Programmer, Technology blogger, DevOps Evangelist and Cloud DevOps Architect. He is interested to talk about Go, NodeJS, C++, Ruby, Bash, Python and PowerShell

Introduction
My Workflow
Submission Category
Yaml File and Link to Code
GitHub Action Workflow Run Output
Additional Info
- How to Add GitHub Actions workflow
- How to Integrate Slack with GitHub Actions Workflow
- Go Source Code Details
- Go REST API Unit testing

Introduction

I've created a GitHub action that performs the Go continuous integration process on the Go source code repository
Interested Go developers and DevOps Engineers can use this workflow to create the Continuous Integration for their GitHub repo
Created this workflow for the submission of actionshackathon21

Workflow Details

Go Continuous Integration workflow

The workflow we created will be doing the Continuous Integration process on this repository.
Whenever there is a code check-in happens on main branch, then CI workflow will be triggered
Below are the details of this workflow
- Code checkout into the workspace
- Install Go and runs the Go linting process for doing code review
- Get the build dependencies
- Builds the code
- Runs the Unit test, if it is success it moves to next stage
- Docker image is created for the code and pushed into docker hub registry
- Finally workflow posts the status of each step to a slack channel
Here is the link to the GitHub actions workflow Yaml

Marketplace GitHub Actions used in this Workflow

I've leveraged existing actions available from GitHub Actions Marketplace

actions/checkout@v2 - Action that is used to checkout code.
*reviewdog/action-golangci-lint@v2 *- Go installation and linting action.
mr-smithers-excellent/docker-build-push@v5 - Docker build and push action.
*act10ns/slack@v1 *- Slack GitHub Action Integration action

Submission Category

DIY Deployments

Yaml File and Link to Code

GitHub Actions Workflow Yaml

name: Go_CI_Workflow

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:

  build:
    name: Build
    runs-on: ubuntu-latest
    steps:
    - name: Check out code to Build
      uses: actions/checkout@v2

    - name: Install Go and Run Code Linting
      id: Install-Go
      uses: reviewdog/action-golangci-lint@v2

    - name: Get dependencies to Build
      id: Get-dependencies-to-Build
      run: |
        go get -v -t -d ./...
        if [ -f Gopkg.toml ]; then
            curl https://raw.githubusercontent.com/golang/dep/master/install.sh | sh
            dep ensure
        fi

    - name: Build Code
      id: Build-Code
      run: |
        go build -v .

    - name: Unit Test
      id: Unit-Test-Run
      run: |
        go test

    - name: Build & push Docker image
      id: Build-and-Push-Docker-Image
      uses: mr-smithers-excellent/docker-build-push@v5
      with:
        image: gsdockit/goapiauth
        tags: latest
        registry: docker.io
        dockerfile: Dockerfile
        username: ${{ secrets.DOCKER_USERNAME }}
        password: ${{ secrets.DOCKER_PASSWORD }}

    - name: Posting Action Workflow updates to Slack
      uses: act10ns/slack@v1
      with: 
        status: ${{ job.status }}
        steps: ${{ toJson(steps) }}
        channel: '#github-updates'
      if: always()
    env:
      SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}

The full source code can be accessible in this GitHub repo

GitHub Action Workflow Run Output

Here is how it runs the workflow and it can be viewable from the Actions tab

Additional Info

Developer - Saravanan G (chefgs)

*Other details that might be helpful to users starting to write GitHub Actions
*

How to Add GitHub Actions workflow

Our workflow gets created in .github/workflows as an .yaml file

Method 1:

Step 1: We can find *Actions * tab on the repo
Step 2: Click on the tab and choose New Workflow
Step 3: Choose workflow from the pre-defined template
Step 4: Edit the workflow yaml according to the required stages

Method 2:

Create workflow for yourself from scratch using the documentation guide

Enjoy creating the GitHub Workflow

How to Integrate Slack with GitHub Actions Workflow

Here is the list of steps to integrate slack with github actions,

Add **github **app to the slack channel
Add incoming webhook app and pick webhook url and keep it
Run the below command in slack channel to **subscribe **to repo updates. (while adding, it asks for auth with github and we choose repo)

/github subscribe user/repo

Add incoming webhook URL as *secret * in the specific repo we want to get updates
Add the below code at the end of Action workflow to get the job updates in slack

  - name: Posting Action Workflow updates to Slack
      uses: act10ns/slack@v1
      with: 
        status: ${{ job.status }}
        steps: ${{ toJson(steps) }}
        channel: '#github-actions-updates'
      if: always()
    env:
      SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}

Each steps in workflow should have id: step-name to get the status of the step in Slack update

*Now let's see the details about the code and it's functionality...
*

Go Source Code Details

Code Objective

We will be creating a REST API that listens on **localhost **port **1357 **and has the API versioning with a query string parameter.
Sample URL format we are planning to create, http://localhost:1357/api/v1/PersonId/Id456

Function main

Add the below code function main()

Adding API Versioning and Basic authentication

  // Define gin router
  router := gin.Default()

  // Create Sub Router for customized API version and basic auth
  subRouterAuthenticated := router.Group("/api/v1/PersonId", gin.BasicAuth(gin.Accounts{
    "basic_auth_user": "userpass",
  }))

Passing Query String Parameters

  subRouterAuthenticated.GET("/:IdValue", GetMethod)

REST API Listening on Port

  listenPort := "1357"
  // Listen and Server on the LocalHost:Port
  router.Run(":"+listenPort)

Get Method

Define a **GetMethod **function and add the following code
It fetches and prints the Person IdValue from the query string parameter passed in the API URL

func GetMethod(c *gin.Context) {
  fmt.Println("\n'GetMethod' called")
  IdValue := c.Params.ByName("IdValue")
  message := "GetMethod Called With Param: " + IdValue
  c.JSON(http.StatusOK, message)

  // Print the Request Payload in console
  ReqPayload := make([]byte, 1024)
  ReqPayload, err := c.GetRawData()
  if err != nil {
        fmt.Println(err)
        return
  }
  fmt.Println("Request Payload Data: ", string(ReqPayload))
}

Go REST API Unit testing

Go testing module can be used for creating unit testing code for Go source
Go testing module code has been found in api_authtest.go
Run the command go test to run the tests

Join us

Create a Multi-Cloud Setup of Kubernetes cluster

Senthil Raja Chermapandian — Mon, 07 Mar 2022 21:51:42 +0000

Author: Vrukshali Torawane is Pursuing bachelors in Computer Science and Engineering. Also, she is an intern at data on kubernetes community. She Own the certifications of Automation with Ansible and Specialist in Containers and Kubernetes. She is a cloud and Devops enthusiast

CREATE A MULTI-CLOUD SETUP of K8S cluster:

Launch node in AWS
Launch node in Azure
Launch node in GCP
One node on the cloud should be Master Node
Then set up multi-node Kubernetes cluster.

So to do this task, I have created three nodes :
Master node on AWS, Slave nodes on AWS, Azure, and GCP.

Let’s start:

First: Setting up Kubernetes master on AWS:

Step-1: For installing kubelet, kubeadm, kubectl first, we need to set up a repo for this :

vim /etc/yum.repos.d/k8s.repo
# content inside repo k8s.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-\$basearch
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg

Step-2: Installing required software :

yum install docker kubelet kubeadm kubectl iproute-tc -y

Step-3: Starting and enabling services :

systemctl enable --now docker
systemctl enable --now kubelet

Step-4: We also need to pull docker images using kubeadm. It pulls images of the config files.

kubeadm config  images pull

Step-5: Now, we need to change the docker cgroup driver into systemd

vim /etc/docker/daemon.json
{  
"exec-opts": ["native.cgroupdriver=systemd"]
}

Step-6: Since we have made changes in docker, we need to restart the docker service :

systemctl restart docker

Step-7: Setting up a network bridge to 1 :

echo "1" > /proc/sys/net/bridge/bridge-nf-call-iptable

Step-8: The important step is while initializing Master, *while running preflight the main thing is we need to associate the token to the public IP of instance, so that any of the other nodes can easily connect, so for this use :
*

--control-plane-endpoint=<PUBLIC_IP>:6443
kubeadm init --pod-network-cidr=10.244.0.0/16 --control-plane-endpoint=<public_ip>:6443 --ignore-preflight-errors=NumCPU          --ignore-preflight-errors=Mem

Step-9: Now, make a directory for Kube config files and give permission to them :

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

Step-10: Apply flannel :

kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

Step-11: Final step: Generate token so that slave nodes could connect to master node :

kubeadm token create --print-join-command

Second: Setting up Kubernetes nodes on AWS, Azure, GCP :
(Note: Follow same steps in all the three platforms)

👉🏻 AWS

👉🏻 Azure

👉🏻 GCP

Step-1: For installing kubelet, kubeadm, kubectl first, we need to set up a repo for this :

vim /etc/yum.repos.d/k8s.repo
# content inside repo k8s.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-\$basearch
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg

Step-2: Installing required software :

yum install docker kubelet kubeadm kubectl iproute-tc -y

Step-3: Starting and enabling services :

systemctl enable --now docker
systemctl enable --now kubelet

Step-4: We also need to pull docker images using kubeadm. It pulls images of the config files :

kubeadm config  images pull

Step-5: Now, we need to change the docker cgroupdriver into systemd :

vim /etc/docker/daemon.json
{  
"exec-opts": ["native.cgroupdriver=systemd"]
}

Step-6: Since we have made changes in docker, we need to restart the docker service :

systemctl restart docker

Step-7: Setting up a network bridge to 1 :

echo "1" > /proc/sys/net/bridge/bridge-nf-call-iptable

Step-8: Copy-paste the token generated in the master node….

Finally, in the master node :

kubectl get nodes

You will see that all the nodes are connected and are ready :

Join us

Chatbots for Cloud Native Incident and Change Management

Senthil Raja Chermapandian — Mon, 07 Mar 2022 21:49:45 +0000

Author: Shiva. working with one of the next generation Pay roll and IHCM Gaints. K8s ethusiast| DevOps story teller|automation and toil avoidence evangalist| people leader| cricket lover & photographer

Introduction

Kubernetes is the de-facto standard for container Micro Service orchestration. GitOps is a code version control-based approach towards build, release engineering & change management. It has empowered developers to be fully responsible and empowers a truly agile delivery.

Lots of organizations are still finding efficient and productive ways for developers accessing Kubernetes workloads in production environments. While many are finding innovative ways, this blog is about one of the possible ways that is tried and tested, of course with a custom development effort.

Self-Servicing Kubernetes workloads, especially during critical incident and change management phases, with faster turnaround is an interesting problem to solve. Tools around Kubernetes have evolved and has brought two of ways for self-service.

UI Based Self Service
Chatbot based Self service

Both of course with a solid RBAC system backing them.

In this blog, I would be discussing about the later (using chatbots for Kubernetes), since the former has standard tooling in market (Rancher GUI with ID and Auth management being one of my favorites).
Before I put through the problem statement, refer to the diagram blow showing the sequence from incident escalation through fix and de-escalation. The below diagram shows the possible areas of efficiency improvement targeted in this blog.

The problem statement:

When we had a bunch of Kubernetes specialists doing incident and change management, the question before us was

● Can we provide tooling to Ops to be quick on Incident resolution steps – hence enhancing the Mean Time to Recover?

● Can we provide a single window for all incident management actions – Can it be a chat room that promotes visibility and empowers quicker service for Ops?
We chose a chatbot with errbot framework! Yay – You got it right Python powered bot with Python being the darling of many DevOps & SRE (Site Reliability Engineering) Professionals. At least one thirds of the issues that landed up as critical incident had a secret recipe for fix

Micro service rollback (and /or)
Micro service restart (and/or)
Micro service roll forwards

While we let the best of Kubernetes experts to well architect a micro service to be placed on Kubernetes cluster and best of release engineers to form a CI (Continuous Integration) CD (Continuous Deployment) strategy for Kubernetes workloads, we decided to build a simple bot service that can do all the above incident fix functions using native Kubernetes ways, using python Kubernetes operator (e.g. https://kopf.readthedocs.io/en/stable/).

One Window for All Operations Approach – Chat Rooms for Swift actions

With this approach we had SRE working from chatrooms using chatbots restarting, rolling back or promoting the services in minutes through a single window interface!
Imagine the SRE working through K8s command lines and CICD tool interfaces Vs using chatbot –Viola!! Valuable few minutes of MTTR saved!
Some added reinforcements were done at process level to keep the source of truth at release engineering and version control level according to the organization needs to ensure sanctity of actions in an incident.

Taking it beyond SREs and DevOps - Are we empowering engineering community?

Empowering Engineering community was next big question we had to answer – More the engineering community is dependent on SRE, more demanding and toiling would be SRE roles!

Think of this sequence - An Incident lands on a micro service team alerting service (e.g., PagerDuty), gets later transferred to SRE – Just for a K8s restart, roll back or promotion across environments- losing valuable time to Recover while following the procedures incident call transfers!

What if we empowered the microservice teams to use Self Serviceable Chatbots? – That was our way forward.

For our way forward we wanted to round off a bot capability beyond Kubernetes operations, a bot that can be reliable, does the exact same process each time and can cater to all business use cases in incident management – In other words, a responsible bot!

A responsible bot – a process guide, a toil breaker, and a swiftness enhancer

When we had to design a responsible bot, we had the following features to be built

The bot should

Validate the need for a self-service action
Enable right user to have right access (least access for effective incident mitigation)
Track and trace all actions of self service (leading us to questions to be answered on a well-designed environment architecture)

How does the bot work?

The responsible bot

● Takes a mandatory justification & confirms it - for prod like environments - observability monitor or alert link (e.g., PagerDuty alert link) or ticket in proper state (e.g., Business approved Jira Ticket) for the case of well detected but not well alerted instances.
● Has a granular access to cluster, namespace, chat room and even an action on who can perform what by having a bot RBAC feature (e.g. https://casbin.org/docs/en/rbac-api)
● Can track and trace every action thro logs (e.g., ELK logs) and incident action traces (e.g., Logging action trace on Jira tickets with action owner)

Do you agree that this is a responsible Bot Indeed? If not, look at the value statement below
The bot aims at

shorter incident mean time to recoveries
cutting time for the co-ordination between Dev & Ops for production like environments
empowers engineering community to do informed Kubernetes actions even on production without ops dependencies
tracks action and records them for bettering the state of micro service deployments if necessary.
Fully self-serviceable!

MTTRs can even faster from few tens of minutes to few minutes after receiving an incident alert!

Seeding into Self Service Changes for the needy:

Organizations have the challenge of Continuous Releases to production like environments – they depend on release management team sometimes as there is a last mile human validation needed. The bot that is responsible has capability now to replace a release management personal if tuned in the right way!

Empower development and test teams to do responsible self-serviceable releases – is a case and space for chat bot to be enabling faster change management executions! What do you think? Do you have this problem or are you fully on Continuous Releases to Production?

Join us

Container Runtime Interface (CRI), Docker deprecation & Dockershim

Senthil Raja Chermapandian — Mon, 07 Mar 2022 21:48:20 +0000

Author: Jothimani Radhakrishnan (Lifion by ADP). A Software Product Engineer, Cloud enthusiast | Blogger | DevOps | SRE | Python Developer. I usually automate my day-to-day stuff and Blog my experience on challenging items.

Intro

Hey Docker lovers <3, this is not going to be a happy story for you guys. Yes, for me as well. Like everyone, I loved using Docker very much. When I get to know about this project (Dockershim), it was a heartbreaking moment for me.

Before knowing about Dockershim let us discuss the following.

Kubelet takes care of managing worker nodes in relation to the master node. It ensures that the specified containers for the pod are up and running.

To know more about kubelet: https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/

Container runtime:

Container runtime is a software that is responsible for running containers. To create a pod, kubelet needs a container runtime environment. For a long time, Kubernetes used Docker as its default container runtime.

This creates a problem/dependency that whenever docker release updates/upgrades it breaks the Kubernetes.

There are also several container runtime tools.

containerd
CRI-O
Docker
Rocket
LXD
OpenVZ
Windows Server Containers

Okay! Coming back to the context of this blog. Docker is going to be deprecated from Kubernetes as default and containerd is going to replace the place.

What is Dockershim?

Docker existed as a default engine in k8s, after introducing additional CRI access (Container runtime interface) in k8s, Kubernetes created an adaptor component called dockershim.

The dockershim adapter allows the kubelet to interact with Docker as if Docker were a CRI compatible runtime.

Img src: Kubernetes documentation
Switching to Containerd as a container runtime eliminates the middleman

Points to Check to make sure your environment is not affected by this change.

You can continue to use Docker to build images, using Docker is not considered a dependency.

All these below pointers should be considered and updated as per your native CRI.

Make sure to update your docker commands operations that are running inside the pod. For example, listing running containers in the worker node using docker ps which might not work after the deprecation.
Check for any private registries or image mirror settings in the Docker configuration file (like /etc/docker/daemon.json)
Any scripts that ssh in worker nodes and does any docker CRUD operations.
Any third-party tools using docker needs to be updated. Migrating Telemetry
Any alerts that are configured based on Docker specific errors should be updated.
Any automation or bootstrap scripts based on Docker commands should be updated.

The list is not limited as mentioned above and might vary based on your adoption of usage.

To know more about the deprecation FAQ: https://kubernetes.io/blog/2020/12/02/dockershim-faq/

Thank you,

Happy containerd! :p

Reference:

https://developer.ibm.com/blogs/kube-cri-overview/

https://kubernetes.io/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/

https://kubernetes.io/blog/2022/01/07/kubernetes-is-moving-on-from-dockershim/

Join us

Deploying squid 🦑 in k3s on an RPI4B

Senthil Raja Chermapandian — Mon, 07 Mar 2022 21:46:42 +0000

Author: Leon. A Devops Engineer. Loves Contributing to Opensource. Python and Golang Developer.

What is k3s?

K3s is lightweight Kubernetes which is easy to install and is a single binary under 100 MB by Rancher. One can read more about it here.

Installing K3s?

K3s provides an installation script that is a convenient way to install it as a service on systemd or openrc based systems. This script is available at https://get.k3s.io. To install K3s using this method, just run:

curl -sfL https://get.k3s.io | sh -

After running this installation:

The K3s service will be configured to automatically restart after node reboots or if the process crashes or is killed
Additional utilities will be installed, including kubectl, crictl, ctr, k3s-killall.sh, and k3s-uninstall.sh
A kubeconfig file will be written to /etc/rancher/k3s/k3s.yaml and the kubectl installed by K3s will automatically use it

Why Squid?

Well I've been using Squid Proxy on my Raspberry Pi 2B for quite some time and I really wanted to get my hands dirty with Kubernetes.

What is Squid?

Taken from the ArchWiki Squid is a caching proxy for HTTP, HTTPS and FTP, providing extensive access controls.

Let's begin

I couldn't find a squid proxy container for my raspberry pi so I had to roll out my own Containerfile.

Now we can build this image with the version tag, this is important if you wish to rollout new changes to your application, having the latest flag is good having a version tag in your deployment is better, this is what I've observed and it's also a deployment strategy.

podman build squid-proxy:v1 .

The problem now is how do I get Kubernetes to recognize this image that I've built? Since it's not on Docker Hub. I could, well deploy this to Docker Hub too, but, I didn't I instead spun up a docker registry container.

podman run -d -p 5000:5000 --restart on-failure --name registry registry:2

Then I ran the following

podman build -t localhost:5000/squid-proxy:v1 .
podman push --tls-verify=false localhost:5000/squid-proxy:v1

Note: The --tls-verify=false is required as we don't have TLS and the image push fails, since this is for learning purposes I've done it without TLS.

Deploying Squid🦑 to Kubernetes.

I'm still pretty new to Kubernetes, the basic unit of Kubernetes is a pod, a pod is something that can hold multiple containers within it. While I can deploy this within a pod directly I didn't, Kubernetes will do that for me via the deployment file.

If you want to get an overview of how Kubernetes works you can watch this video by @techworld_with_nana, Kubernetes Course

I decided to go this way, Create a LoadBalancer Service and a Deployment that would deploy SQUID to Kubernetes.

There is a volume folder that is common for both the containers since SQUID doesn't send logs to STDOUT

To run this you can simply do

$ kubectl apply -f squid-deployment.yml
deployment.apps/squid-dployment unchanged
service/squid-service unchanged

This will create a Service and Deployment will create a pod

$ kubectl get service
$ kubectl get service

Output

$ kubectl get svc
NAME            TYPE           CLUSTER-IP      EXTERNAL-IP      PORT(S)          AGE
kubernetes      ClusterIP      10.43.0.1       <none>           443/TCP          48d
squid-service   LoadBalancer   10.43.114.127   192.168.31.151   3128:32729/TCP   3d14h

To get the deployments

$ kubectl get deploy
$ kubectl get deployment

Which will show the following

NAME              READY   UP-TO-DATE   AVAILABLE   AGE
squid-deployment   1/1     1            1           7d19h

The last thing is to get the pods.

$ kubectl get po OR kubectl get pods
NAME                               READY   STATUS    RESTARTS   AGE
squid-dployment-86bfc8d664-swwzj   2/2     Running   0          4d14h
svclb-squid-service-54nrc          1/1     Running   0          4d1h

Once everything is up and running you can see the following in the curl headers.

To see the logs and follow them you can do the following.

kubectl logs service/squid-service -c tailer -f

That's all.

This is a simple and easy deployment using Kubernetes, if I've made any mistakes or you would like to suggest any changes please drop a comment below <3

Join us

Optimising Python workloads for Kubernetes

Senthil Raja Chermapandian — Mon, 07 Mar 2022 21:45:15 +0000

Intro

This blog is about how I solved the problem of shrinking a loop processing time in Python from 30sec to 5sec (6x)

I had a use-case where the python script calls Jira API and scraps data, doing some calculations and creating a tuple. On average, it took approx. 1s per loop, say there are 30 tickets --> 30 loops and 30s.

In order to make my script powerful, I have to understand the concurrency and that’s when I explored this crucial concept in python and an idea popped for this blog :)

A quick tip: You should use threading if your program is network-bound or multiprocessing if it is CPU-bound.

Let’s briefly catch up about Multi-processing vs Multi-threading vs Asyncio

Multi-processing

For powerful computation related queries. Multi-processing Python program could fully utilize all the CPU cores and native threads available.
Each python process is independent of each other, and they don’t share memory.
Performing collaborative tasks in Python using multiprocessing requires the use of API provided by the operating system.

Multi-threading

All processes shares the same memory i.e it runs as a single process with multiple threads way which is good for i/o bound process.
Caveats: Pre-emption - CPU has full power to revoke or reschedule any running thread.

Python Asyncio

Single process and single-thread and make better use of CPU sitting idle when waiting for the I/O.
Event loop in asyncio which routinely measures the progress of the tasks. If the event loop has measured any progress, it would schedule another task for execution. Therefore this minimizes the time spent on waiting for I/O.

Based on the use case, I used multi-threading since the function is very quick and ephemeral (killing and restarting a thread will not create problems to the function)

Running it in Kubernetes

Okay! What are the points to be considered while running this in Kubernetes?

Requests – Soft limit of the resource
Limits – Hard stop for a resource (CPU / RAM). Post this hard stop usage, OOM will come into play.

However, if we don’t specify any resource limits, Kubernetes decides and assigns resource dynamically

Coming back to my use case

I provisioned a pod with 1 CPU and 5 threads; this needs to be calculated and initialized based on the nature of your function. (we can discuss this thread allocation process as a separate post.)

We all know that resources can be controlled using requests and limits, and kubernetes manages automatically.

From k8s doc:
If the node where a Pod is running has enough of a resource available, it's possible (and allowed) for a container to use more resources than its request for that resource specifies. However, a container is not allowed to use more than its resource limit.

Happy processing!

References

Join us

Kubernetes Operators: Cruise Control for Managing Cloud-Native Apps

Senthil Raja Chermapandian — Mon, 07 Mar 2022 21:43:02 +0000

Author: Senthil Raja Chermapandian is Principal Software Engineer in Ericsson. He is a Certified Kubernetes Administrator (CKA), Maintainer of Open Source project “kube-fledged”, Tech Blogger, Speaker & Organizer of KCD Chennai. He specialises in Machine Learning, Distributed Systems, Edge Computing, Cloud-Native Software Development, WebAssembly, Kubernetes and Google Cloud Platform

Introduction:

Managing Applications in Production has traditionally been a Human-centric affair. Large Ops Teams were tasked with managing the day-to-day operations of the running Apps. These teams had experts with deep domain and functional knowledge of the App and its Infrastructure, and often relied on heroes to save the day when an outage occurred.

When the number of Apps and their complexities started growing, inefficiencies and cost overruns crept in. IT Organizations resorted to Automation Tools to address these challenges. As a result, the Ops team evolved to become more Tool-centric, relying on tools, automation and scripts for tasks like monitoring, alerting, patching, backup/restore etc.

Code-centric App Management:

In due course, Organizations started embracing Cloud-Native Applications and Infrastructure. The fundamental approach to designing and building Apps changed: Cloud, Containers and Micro-services took center-stage and users begun to take elasticity, scalability and resiliency for granted. This trend created new challenges and made way for the wide-spread adoption of DevOps and SRE approaches to elevate efficiencies in Operations. Relying on Humans and Tools alone for managing Cloud-Native Applications won’t help.

The answer is a Code-centric approach to managing a Cloud-Native App in Production. In Code-centric approach, the Ops team transforms itself into a group of Software engineers with a goal to codify all of the domain knowledge and operational tasks required for managing a Cloud-Native App. Code becomes the fundamental asset for managing the App, with Humans and Tools augmenting wherever needed. This codified asset is capable of performing all the operational tasks for managing the App. Let’s call this codified asset as Ops-App. An Ops-App is often built by SREs using the same language, framework and constructs used by the App it manages. The Ops-App handles all the operational activities of the App viz. Deployment, Upgrade, Patching, Backup/Restore, Monitoring, Alerting, Scaling etc.

What is a Kubernetes Operator?

Kubernetes allows us to pool Compute Resources from a group of physical and virtual servers, and makes these resources available to Containerized applications on-demand. It manages the lifecycle of containers, and provides various critical capabilities: automation, self-healing, persistent volumes, RBAC, auto-scaling etc.

A Kubernetes Operator, in simple terms, is an Ops-App for a Containerized Cloud-Native App running in Kubernetes. Kubernetes has inherent support for several basic App management tasks like self-healing, scaling, monitoring etc. A Kubernetes Operator “amplifies” these basic capabilities into a fully blown Ops-App that has the entire domain knowledge of the App embedded in it. It does this, by simply extending or enhancing the capabilities of the Kubernetes cluster that hosts the App (Kubernetes allows users to add new API resources via a feature called Custom Resource Definition (CRD)). A user can then use the native Kubernetes command line tool (kubectl) or APIs to interact with the Ops-App, in the same way the user interacts with the Kubernetes Control plane. And, you get to run both the App and the Ops-App in the same Kubernetes cluster, allowing you to use existing CI/CD pipelines to manage the release of the App and its corresponding Ops-App. In Kubernetes parlance, the Ops-App is called an Operator.
Let’s assume the Dev Team has written a Java Spring boot Application and has Containerized the App into a Container Image. The Ops Team has to deploy this App into a Production Kubernetes Cluster and manage the lifecycle of the App. Rather than deploying this App directly, the Ops team would write an Operator for this App. The Operator “knows” how to programmatically deploy the App into the Cluster with the right configuration, resource requirements etc. The Operator can also be written in a fashion that it knows “much more” than Deploying the App: it knows how to apply patches, roll-out upgrades, back up the App’s data, monitor the metrics of the App, initiate scaling, restore the backup etc. A human being would be required to intervene only for tasks which the Operator cannot perform. As a result, managing an App becomes highly efficient and cost-optimized. This is a powerful pattern for managing Cloud-Native Apps in Kubernetes.

Operator Capability Levels

Operators come in different maturity levels in regards to their lifecycle management capabilities for the application or workload they manage. The capability model aims to provide guidance in terminology to express what features users can expect from an operator.

Each capability level is associated with a certain set of management features the Operator offers around the managed workload. Operator that do not manage a workload and/or are delegating to off-clusters orchestration services would remain at Level 1. Capability levels are accumulating, i.e. Level 3 capabilities require all capabilities desired from Level 1 and 2.

The Operator Framework

A Kubernetes Operator brings much needed efficiencies in managing a Containerized App. Excellent! However, writing an Operator today can be difficult because of challenges such as using low level APIs, writing boilerplate code, and a lack of modularity which leads to duplication. The Operator Framework removes the pain out of writing a Kubernetes Operator. It is an open source toolkit to manage Operators in an effective, automated, and scalable way. It provides a SDK which can be downloaded. Refer to this blog to get in-depth understanding on using the Operator SDK for writing an Operator.
If you are looking for pre-built, readily usable Operators, it’s available in operatorhub.io. This is a collection of Open-sourced Operators for popular Applications. You can either use them as-is or download the source code and modify it as per your use case. As of this writing, the repository has 209 Operators for Apps ranging from Akka to Wildfly. You could submit your Operator to operatorhub.io for others to discover and use it.

Conclusion:

Kubernetes Operators can be very valuable in managing Cloud-Native Applications in Kubernetes. If you could build a group of SREs with the right skillset for writing and maintaining Operators, you’d benefit a lot. I believe this article has been helpful in getting a big picture of Kubernetes Operators and its benefits. Share your feedback in the comments section.

Join us

Kube-fledged: Cache Container Images in Kubernetes

Senthil Raja Chermapandian — Mon, 07 Mar 2022 21:40:58 +0000

“The Peregrine Falcon is renowned for its speed, reaching over 200 mph during its characteristic high-speed dive, making it the fastest bird in the world, as well as the fastest member of the animal kingdom.” (Source: Wikipedia)

Introduction

When a Containerized Application is deployed to a Kubernetes cluster, the K8s control plane schedules the Pod to a worker node in the cluster. The Node agent (Kubelet) running in the worker node, co-ordinates with the container runtime (e.g. containerd) installed in the node, and pulls the necessary container images from the Image Registry. Depending upon the size of the images and the network bandwidth available, it takes time to pull all the images to the node. So, in any containerized application, we should be cognizant of the delay introduced due to fetching the images from the registry. Traditional applications that run as processes (e.g. managed by systemd), however, do not suffer from this delay because all necessary files are already installed in the machine.

Imagine your Containerized Application experiences a sudden surge in traffic, and it needs to immediately scale out horizontally (i.e. additional instances need to be created). If you had configured Horizontal Pod Autoscaler (HPA), K8s control plane creates additional replicas of Pods. However these Pods won’t be available for handling the increased traffic, until the required images are pulled and the containers are up and running. Or assume your Application needs to process high-speed real-time data. Such applications have stringent requirements on how rapidly they can be started-up and scaled, because of the very nature of the purpose it fulfils. In short, there are several use cases where the delay introduced due to pulling the images from the registry is not acceptable. Moreover, the network connectivity between the cluster and the image registry could suffer from poor bandwidth or the connectivity could be totally lost. There are scenarios, especially in Edge computing, where Applications have to gracefully tolerate intermittent network connectivity.

These challenges could be solved by different means. One solution that would immensely help in these scenarios is to have the container images cached directly on the cluster worker nodes, so that Kubelet doesn’t needs to pull these images, but immediately use the images already cached in the nodes. In this blog, I’ll explain how one can use kube-fledged, an open source project, to build and manage a cache of container images in a Kubernetes cluster.

Existing Solutions

Before I introduce you to kube-fledged, let me briefly describe existing solutions to tackle this problem. The widely-used approach is to have a Registry mirror running inside the Cluster. Two widely used solutions are i) in-cluster self hosted registry ii) pull-through cache. In the former solution, a local registry is run within the k8s cluster and it is configured as a mirror registry in the container runtime. Any image pull request is directed to the in-cluster registry. If this fails, the request is directed to the primary registry. In the latter solution, the local registry has caching capabilities. When the image is pulled the first time, it is cached in the local registry. Subsequent requests for the image are served by the local registry.

Drawbacks of existing solutions

Setting up and maintaining the Local registry mirror consumes considerable computational and human resources.
For huge clusters spanning multiple regions, we need to have multiple local registry mirrors. This introduces unnecessary complexities when application instances span multiple regions. You might need to have multiple Deployment manifests each pointing to the local registry mirror of that region.
These approaches don’t fully solve the requirement for achieving rapid starting of a Pod since there is still a notable delay in pulling the image from the local mirror. There are several use cases which cannot tolerate this delay.
Nodes might lose network connectivity to the local registry mirror so the Pod will be stuck until the connectivity is restored.

Overview of kube-fledged

kube-fledged is a kubernetes add-on or operator for creating and managing a cache of container images directly on the worker nodes of a kubernetes cluster. It allows a user to define a list of images and onto which worker nodes those images should be cached (i.e. pulled). As a result, application pods start almost instantly, since the images need not be pulled from the registry. kube-fledged provides CRUD APIs to manage the lifecycle of the image cache, and supports several configurable parameters in order to customize the functioning as per one’s needs. (URL: https://github.com/senthilrch/kube-fledged)

kube-fledged is designed and built as a general-purpose solution for managing an image cache in Kubernetes. Though the primary use case is to enable rapid Pod start-up and scaling, the solution supports a wide variety of use cases as mentioned below

Use Cases

Applications that require rapid start-up. For e.g. an application performing real-time data processing needs to scale rapidly due to a burst in data volume.
Serverless Functions since they need to react immediately to incoming events.
IoT applications that run on Edge devices, because the network connectivity between the edge device and image registry would be intermittent.
If images need to be pulled from a private registry and everyone cannot be granted access to pull images from this registry, then the images can be made available on the nodes of the cluster.
If a cluster administrator or operator needs to roll-out upgrades to an application and wants to verify before-hand if the new images can be pulled successfully.

How kube-fledged works

Kubernetes allows developers to extend the kubernetes api via Custom Resources. kube-fledged defines a custom resource of kind “ImageCache” and implements a custom controller (named kubefledged-controller). kubefledged-controller does the heavy-lifting for managing image cache. Users can use kubectl commands for creation and deletion of ImageCache resources.

kubefledged-controller has a built-in Image Manager routine that is responsible for pulling and deleting images. Images are pulled or deleted using kubernetes jobs. If enabled, image cache is refreshed periodically by the refresh worker. kubefledged-controller updates the status of image pulls, refreshes and image deletions in the status field of ImageCache resource. kubefledged-webhook-server is responsible for validating the fields of the ImageCache resource.

If you need to create an image cache in your cluster, you only need to create an ImageCache manifest by specifying the list of images to be pulled, along with a nodeSelector. The nodeSelector is used to specify the nodes onto which the images should be cached. If you want the images to be cached in all the nodes of the cluster, then omit the nodeSelector. When you submit the manifest to your cluster, the API server will POST a validating webhook event to kubefledged-webhook-server. The webhook server validates the cacheSpec of the manifest. Upon receiving a successful response from the webhook server, API server persists the ImageCache resource in etcd. This triggers an Informer notification to kubefledged-controller, which queues the request. The request is picked up by the Image cache worker, which creates multiple image pull requests (one request per image per node) and places them in the image pull/delete queue. These requests are handled by the image manager routine. For every request, the image manager creates a k8s job that is responsible for pulling the image into the cache. The image manager keeps track of the jobs it creates and once a job completes, it places a response in a separate queue. The image cache worker then aggregates all the results from the image manager and finally updates the status section of the ImageCache resource.

kube-fledged has a refresh worker routine which runs periodically to keep the image cache refreshed. If it discovers that any image is missing in the cache (perhaps removed by kubelet’s image garbage collection), it re-pulls the image into the cache. Images with :latest tag are always re-pulled during the refresh cycle. By default, the refresh cycle is triggered every 5m. Users can modify it to a different value or completely disable the auto-refresh mechanism while deploying kube-fledged. An on-demand refresh mechanism is also supported, using which users can request kube-fledged to refresh the image cache immediately.

Image Cache actions supported by kube-fledged

kube-fledged supports the following image cache actions. All these actions can be performed using kubectl or by directly submitting a REST API request to the Kubernetes API server:

Create Image Cache
Modify Image Cache
Refresh Image Cache
Purge Image Cache
Delete Image Cache

Supported Container Runtimes

docker
containerd
cri-o

Supported Platforms

linux/amd64
linux/arm
linux/arm64

Try kube-fledged

The quickest way to try out kube-fledged is to deploy it using the YAML manifests in the project’s GitHub Repo (https://github.com/senthilrch/kube-fledged). You could also deploy it using helm chart and helm operator. Find below the steps for deploying kube-fledged using manifests:

Clone the source code repository



$ mkdir -p $HOME/src/github.com/senthilrch
$ git clone https://github.com/senthilrch/kube-fledged.git $HOME/src/github.com/senthilrch/kube-fledged
$ cd $HOME/src/github.com/senthilrch/kube-fledged

Deploy kube-fledged to the cluster



$ make deploy-using-yaml

Verify if kube-fledged deployed successfully



$ kubectl get pods -n kube-fledged -l app=kubefledged

$ kubectl get imagecaches -n kube-fledged (Output should be: 'No resources found')

Conclusion

There are Applications and Use cases which require rapid start-up and scaling. The delay introduced by pulling images from the registry might not be acceptable in such cases. Moreover the network connectivity to the registry might be unstable/intermittent. And there could be security reasons for not granting access to secure registries to all the users. Kube-fledged can be a simple and useful solution to build and mange a cache of container images directly on the cluster worker nodes.

Join us

Kubernetes Community Days Chennai Chapter - Logo Highlights

Senthil Raja Chermapandian — Mon, 07 Mar 2022 21:25:49 +0000

by Gayathri R, Co-Organizer, KCD Chennai 2022

Kubernetes Community Days(KCD) Chennai chapter logo hosts multiple identities such as the tri-color of the Indian National flag, monuments in Chennai and green avenue trees.

In the middle of the logo, is the steering arms of the Kubernetes rudder, 3 stripes of the Indian national flag (Saffron, white and green), lined by 7 iconic monuments in Chennai :

Chennai Central station - One of the most prominent landmarks of Chennai that serves as the main gateway by Rail to the rest of the country.
Vailankanni Shrine - Known as the 'Lourdes of the East', the Velankanni Church is one of the most revered pilgrimages for Catholics in India.
San Thome Cathedral Basilica - It's a stunning piece of architecture steeped in religious history.
Ripon Building - It is the seat and headquarters of the Greater Chennai Corporation.
Kapaleeshwarar Temple - It's one of the prominent Shiva temples in India situated in Mylapore, Chennai.
St. George’s Fort - It is historically called as White Town. It's the first English (later British) fortress in India
Valluvar Kottam - It is the memorial monument of the Tamil poet Thiruvalluvar who wrote the famous Thirukkural.

The Logo symbolizes - Team spirit, talent, learning and action.

Join the KCD Chennai Chapter: www.kcdchennai.in
Follow us in Twitter: twitter.com/kcdchennai
Follow us in LinkedIn: linkedin.com/in/kcdchennai
Join our slack channel: slack.cncf.io #kcd-chennai
Email: organizers-chennai@kubernetescommunitydays.org

Kubernetes Community Days Chennai 2022

Senthil Raja Chermapandian — Mon, 07 Mar 2022 21:19:08 +0000

Kubernetes Community Days (KCDs) are community-organized events that gather adopters and technologists from open source and cloud native communities for education, collaboration, and networking. KCDs are supported by the Cloud Native Computing Foundation (CNCF). These fun, locally-defined events help grow and sustain the Kubernetes community.

We are hosting the very first Kubernetes Community Days in Chennai on 3-4 June 2022. It's a two day Virtual event with Keynotes, Breakout sessions and much more. We invite the open source community to benefit from this event. Come join us!!

Join the KCD Chennai Chapter: www.kcdchennai.in
Follow us in Twitter: twitter.com/kcdchennai
Follow us in LinkedIn: linkedin.com/in/kcdchennai
Join our slack channel: slack.cncf.io #kcd-chennai
Email: organizers-chennai@kubernetescommunitydays.org

Woot…Kubernetes Adds Support for Swap Memory

Senthil Raja Chermapandian — Thu, 02 Sep 2021 07:39:25 +0000

Woot moment

When I was going through the Kubernetes 1.22 release announcement blog, there was a woot moment in it for me. Within the section titled Major Themes, was a brief mention about a new alpha feature titled Node system swap support. My mind re-winded back to the year 2016, when I took up a new assignment with a Telecom MNC as PaaS platform developer. My job required me to spin up 2-node K8S clusters very often (back then we did not have tools like kubeadm, kubespray etc.) using Cloud VMs. I would sometimes forget disabling swap on the nodes and the cluster wouldn’t come up. After a bit of frustration, coffee and help from colleagues, I would then realize I had once again forgotten to disable swap!! Many of my fellow colleagues had same experiences as well, so much so, if someone faced issues in bootstrapping a K8s cluster, the first piece of query would be “Did you disable swap?”. Nostalgia apart, back then I did not dig deeper into the significance of disabling swap when standing up a K8s cluster.

So when I read the release announcement blog, I decided to dig deeper into this topic. Soon after the 1.22 release, Elana Hashman (Red Hat) published a blog, which shed more light into this new alpha feature. This blog is inspired by Elana’s blog and I have used some of it’s contents here.

Why prior releases of K8s did not support swap?

My digging led me to issue #53533 raised by Denis Gladkikh in year 2017. This was a bug report that said: Kubelet/Kubernetes 1.8 does not work with Swap enabled on Linux Machines. Before I get into the details, lets digress a bit to understand the purpose of Swap Memory.

Swap is a space on the host disk that is used when the amount of physical RAM memory is full. When a Linux system runs out of RAM, inactive memory pages are moved from the RAM to the swap space, so RAM can be allocated to processes that require it the most. Swap space can take the form of either a dedicated swap partition or a swap file. In most cases, when running Linux on a virtual machine, a swap partition is not present, so the only option is to create a swap file. Swappiness is a Linux kernel property that defines how often the system will use the swap space. Swappiness can have a value between 0 and 100. A low value will make the kernel to try to avoid swapping whenever possible, while a higher value will make the kernel to use the swap space more aggressively.
In prior releases, Kubernetes did not support the use of swap memory: having swap available has very strange and bad interactions with memory limits. For example, a container that hits its memory limit would then start spilling over into swap. This also has an effect that if the memory gets exhausted on the node, it will potentially become completely locked up — requiring a restart of the node, rather than just slowing down and recovering a while later.

A workaround was available for those who really wanted swap. kubelet had to be run with --fail-swap-on=false. Containers which do not specify a memory requirement will then by default be able to use all of the machine memory, including swap. This might only really be a viable strategy if none of the containers ever specify an explicit memory requirement…

Scenarios considered and supported

There are a number of possible ways that one could envision swap use on a node.

Swap is enabled on a node’s host system, but the kubelet does not permit Kubernetes workloads to use swap.
Swap is enabled at the node level. The kubelet can permit Kubernetes workloads scheduled on the node to use some quantity of swap, depending on the configuration.
Swap is set on a per-workload basis. The kubelet sets swap limits for each individual workload.

The alpha feature is limited in scope to the first two scenarios. The third scenario is not implemented yet. Perhaps this might be considered in a future release..

Use cases that could benefit from swap support

Improved Node Stability

cgroupsv2 improved memory management algorithms, such as oomd, strongly recommend the use of swap. Hence, having a small amount of swap available on nodes could improve better resource pressure handling and recovery.

Long-running applications that swap out startup memory

Applications such as the Java and Node runtimes rely on swap for optimal performance. Initialization logic of applications can be safely swapped out without affecting long-running application resource usage

Memory Flexibility

There are numerous cases in which cost of additional memory is prohibitive, or elastic scaling is impossible (e.g. on-premise/bare metal deployments). Occasional cron job with high memory usage and lack of swap support means cloud nodes must always be allocated for maximum possible memory utilization, leading to over-provisioning/high costs.

Local development and systems with fast storage

Local development or single-node clusters and systems with fast storage may benefit from using available swap (e.g. NVMe swap partitions, one-node clusters). Linux has optimizations for swap on SSD, allowing for performance boosts.

Low footprint systems

For example, edge devices with limited memory. Edge compute systems/devices with small memory footprints (<2Gi). Clusters with nodes <4Gi memory

Enabling Swap Support

Swap can be enabled as follows:

Provision swap on the target worker nodes,
Enable the NodeMemorySwap feature flag on the kubelet,
Set --fail-on-swap flag to false, and
(Optional) Allow Kubernetes workloads to use swap by setting MemorySwap.SwapBehavior=UnlimitedSwap in the kubelet config.

MemorySwap.SwapBehavior configures swap memory available to container workloads. May be one of :

“LimitedSwap”: workload combined memory and swap usage cannot exceed pod memory limit
“UnlimitedSwap”: workloads can use unlimited swap, up to the allocatable limit.

If the feature flag is enabled, the user must still set --fail-swap-on=false to adjust the default behaviour. A node must have swap provisioned and available for this feature to work. If there is no swap available, but the feature flag is set to true, there will still be no change in existing behaviour.

The feature flag can be disabled while the --fail-swap-on=false flag is set, but this would result in undefined behaviour. To turn this off, the kubelet would need to be restarted. If a cluster admin wants to disable swap on the node without repartitioning the node, they could stop the kubelet, set swapoff on the node, and restart the kubelet with --fail-swap-on=true. The setting of the feature flag will be ignored in this case.

Caveats

Having swap available on a system reduces predictability. Swap’s performance is worse than regular memory, sometimes by many orders of magnitude, which can cause unexpected performance regressions. Furthermore, swap changes a system’s behaviour under memory pressure, and applications cannot directly control what portions of their memory usage are swapped out. Since enabling swap permits greater memory usage for workloads in Kubernetes that cannot be predictably accounted for, it also increases the risk of noisy neighbours and unexpected packing configurations, as the scheduler cannot account for swap memory usage.

The performance of a node with swap memory enabled depends on the underlying physical storage. When swap memory is in use, performance will be significantly worse in an I/O operations per second (IOPS) constrained environment, such as a cloud VM with I/O throttling, when compared to faster storage mediums like solid-state drives or NVMe.

Use of swap is not recommended for certain performance-constrained workloads or environments. Cluster administrators and developers should benchmark their nodes and applications before using swap in production scenarios.

Points to Remember

The CRI has changed, so container runtimes (e.g. containerd, cri-o) won’t be able to actually accept swap configs until they have been updated against the new CRI.
The work isn’t over with this release; there will be a multi-release graduation process. This feature won’t be graduating until at least 1.25.

Conclusion

Swap support in Kubernetes should appeal to a wide variety of users: cluster administrators and developers. This feature could be one more lever in reducing infrastructure costs for businesses. However since the feature is still in alpha stage, it is not ready for production usage. Readers are encouraged to perform benchmarking tests to evaluate the suitability for their workloads/use cases and provide feedback to K8s SIG Node WG via following means:

SIG Node meets regularly and can be reached via Slack (channel #sig-node), or the SIG’s mailing list. Feel free to
reach out to Elana Hashman (@ehashman on Slack and GitHub) if you’d like to help.

Forem: Senthil Raja Chermapandian

A Gentle Introduction to WebAssembly

What is WebAssembly?

The Web needed a new Programming Language

Design Goals

Minimum Viable Product

Performance

Security

Independency

WebAssembly as a non-browser runtime

Bytecode Alliance

GitHub Actions workflow for Go Continuous Integration

Table of Contents

Introduction

Workflow Details

Go Continuous Integration workflow

Marketplace GitHub Actions used in this Workflow

Submission Category

DIY Deployments

Yaml File and Link to Code

GitHub Action Workflow Run Output

Additional Info

How to Add GitHub Actions workflow

Method 1:

Method 2:

How to Integrate Slack with GitHub Actions Workflow

Go Source Code Details

Code Objective

Function main

Adding API Versioning and Basic authentication

Passing Query String Parameters

REST API Listening on Port

Get Method

Go REST API Unit testing

Join us

Create a Multi-Cloud Setup of Kubernetes cluster

CREATE A MULTI-CLOUD SETUP of K8S cluster:

Let’s start:

First: Setting up Kubernetes master on AWS:

Finally, in the master node :

Join us

Chatbots for Cloud Native Incident and Change Management

Introduction

The problem statement:

One Window for All Operations Approach – Chat Rooms for Swift actions

Taking it beyond SREs and DevOps - Are we empowering engineering community?

A responsible bot – a process guide, a toil breaker, and a swiftness enhancer

How does the bot work?

The responsible bot

Seeding into Self Service Changes for the needy:

Join us

Container Runtime Interface (CRI), Docker deprecation & Dockershim

Intro

Container runtime:

What is Dockershim?

Points to Check to make sure your environment is not affected by this change.

Reference:

Join us

Deploying squid 🦑 in k3s on an RPI4B

What is k3s?

Installing K3s?

Why Squid?

What is Squid?

Let's begin

Deploying Squid🦑 to Kubernetes.

Join us

Optimising Python workloads for Kubernetes

Intro

Multi-processing

Multi-threading

Python Asyncio

Running it in Kubernetes

Coming back to my use case

References

Join us

Kubernetes Operators: Cruise Control for Managing Cloud-Native Apps

Introduction:

Code-centric App Management:

What is a Kubernetes Operator?

Operator Capability Levels