DEV Community: Shubham

Kubernetes Node Management - Drain, Cordon and Uncordon

Shubham — Mon, 21 Jul 2025 11:10:08 +0000

Most Kubernetes engineers don’t start their day expecting to drain a node, but they often end up doing just that. Managing node availability becomes routine work that directly affects workload stability and uptime. You’ll often use drain, cordon, and uncordon when:

Scaling a cluster
Preparing for a node upgrade
Patching OS level vulnerabilities
Replacing underlying infrastructure
Investigating issues on a specific node

Let’s go through how these actually behave, with visual examples.

1. DRAIN

The kubectl drain command is used when you want to safely evict all running pods from a node and prevent new ones from being scheduled on it. This is typically used during node maintenance, upgrades, or when preparing to decommission a node.

When you run kubectl drain node2, Kubernetes performs two actions:

It marks the node as unschedulable (SchedulingDisabled).
It evicts all non-daemonset pods from the node.

Before Drain: All three nodes are healthy and ready to accept pods. node2 is running Pod C and Pod D.
Once kubectl drain node2 is executed:

Pod C is moved to node1.
Pod D is moved to node3.
node2 is marked as SchedulingDisabled so no new pods are placed there.

Things I learnt after burn out:

Use --ignore-daemonsets or the command fails if daemonset pods are present.
Pods using emptyDir lose all data when evicted, even if they come back quickly.
If a PodDisruptionBudget is set, drain can block until it’s safe to evict.
Hanging drains are usually due to finalizers or stuck shutdown hooks. Use --force only if you understand the risk.
Drain marks the node as unschedulable. You must run uncordon manually to bring it back.
Draining nodes with system pods and no tolerations can silently break networking or DNS.

2. Cordon

The kubectl cordon command is used when you want to stop new pods from being scheduled on a node, but keep existing pods running. This is often done before maintenance, scaling operations, or selective upgrades where you don’t want to disrupt workloads immediately.

How Kubernetes Calculates Access Permissions Using RBAC Rules

Shubham — Mon, 14 Jul 2025 10:18:44 +0000

RBAC, or Role-Based Access Control, is a critical concept every DevOps and Cloud Engineer must understand. It defines who can perform what actions on which resources.

Whether managing Kubernetes, cloud accounts, or CI/CD pipelines, it brings structure to access control, makes permissions predictable, and helps teams manage security at scale.

When a user, service account, or process tries to perform an action (verb) on a resource (like deployments) in a namespace, Kubernetes uses the following flow to determine if the action is allowed:

1. API Server Receives the Request
The request could be: GET /apis/apps/v1/namespaces/dev/deployments/nginx-deploy

It includes:

Verb: get
Resource: deployments
Namespace: dev
User identity

2. Authentication
The API server authenticates the request using one of the supported methods:

Client certificate authentication from the kube-apiserver configuration
Bearer tokens (including service account tokens)
OIDC tokens configured with an identity provider

For this example, the identity resolved is:
User = pareek.platform@gmail.com

3. Authorization
The RBAC authorizer processes the authenticated identity and evaluates it against:

RoleBindings and ClusterRoleBindings present in etcd.
Corresponding Roles or ClusterRoles defined in the cluster.

# Role allowing get on deployments in namespace dev
kind: Role
metadata:
  namespace: dev
  name: view-deployments
rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list"]

# RoleBinding assigning above role to user from techopsexamples
kind: RoleBinding
metadata:
  name: deployment-reader
  namespace: dev
subjects:
- kind: User
  name: pareek.platform@gmail.com
roleRef:
  kind: Role
  name: view-deployments
  apiGroup: rbac.authorization.k8s.io

4. Match Rules
The RBAC authorizer iterates through all applicable rules in the matched Roles or ClusterRoles. Checks whether any rule allows the verb on the resource in the given namespace

Each rule contains:

verbs (e.g., get, list)
resources (e.g., deployments)
apiGroups (e.g., apps)
resourceNames (optional, e.g., only certain deployments)

5. Decision

If any rule matches, the RBAC authorizer grants access
If no rule matches, the API server returns 403 Forbidden

Test the calculation:

kubectl auth can-i get deployments --as 
pareek.platform@gmail.com --namespace dev

Starting up with Kubernetes

Shubham — Thu, 30 Jan 2025 10:06:35 +0000

If you are starting up with Kubernetes or working with it then it is for you.
Someone is digging into Kubernetes concepts, tools, and best practices – so you don’t have to.

Here are 20 must-know updates and tips to get started with Kubernetes:

Always start with kubectl – it's your gateway to the cluster.
Use Minikube or Kind to practice Kubernetes locally.
Master the YAML syntax – it's everywhere in Kubernetes.
Learn the difference between Deployments, StatefulSets, and DaemonSets.
Namespace everything to avoid conflicts in multi-team setups.
Use ConfigMaps and Secrets to separate configuration from code.
Set up resource requests/limits to prevent pod starvation.
Understand Kubernetes Services – ClusterIP, NodePort, and LoadBalancer.
Learn about Ingress for HTTP routing into your cluster.
Use liveness and readiness probes to manage container health.
Avoid storing credentials in plain YAML files – use Secrets instead.
Familiarize yourself with Helm for managing application releases.
Explore Kustomize for environment-specific configuration.
Use metrics-server for resource monitoring.
Set up Role-Based Access Control (RBAC) for secure operations.
Start with a simple CNI plugin like Flannel for networking.
Use Kubernetes Dashboard cautiously – it's great for beginners but can expose your cluster.
Experiment with auto-scaling – both HPA (pods) and Cluster Autoscaler (nodes).
Regularly clean up unused resources like pods, services, and images.
Document everything – Kubernetes has a steep learning curve.

Save this one for your reference.

Would you like me to expand on any specific point?

5 Trending AI Tools

Shubham — Tue, 29 Oct 2024 09:54:31 +0000

We are covering innovative tools that enhance productivity and streamline complex tasks. In this article, we explore five trending AI tools that are making waves in various sectors, offering unique solutions to everyday challenges.

1. Claude Computer Use:
Give Claude the power to view your screen, click, type, and execute tasks.

Applications:

- Coding
Claude models are constantly improving on coding, math, and reasoning. It's latest model, Claude 3.5 Sonnet, can be instructed to write, edit, and run code with strong troubleshooting capabilities.

- Productivity
Claude can extract relevant information from business emails and documents, categorize and summarize survey responses, and wrangle reams of text with high speed and accuracy.

- Customer support
Claude can handle ticket triage, and on-demand complex inquiries using rich context awareness, and multi-step support workflows—all with a casual tone and conversational responses.

Why It’s Trending:
Claude is becoming popular due to its user-friendly interface and ability to handle various tasks with precision, making it highly versatile for both individuals and businesses.

2. Pricing Maker
Pricing Maker generates prices for your product or SaaS by AI.

Applications:
Dynamic Pricing: Retailers and e-commerce businesses can use Pricing Maker to adjust prices dynamically based on demand, seasonality, and competitor activity.

Revenue Management: Businesses in industries like hospitality or SaaS can leverage the tool to optimize subscription models.
Market Insights: The AI analyzes competitor pricing and trends, offering insights that help businesses position their products or services effectively.

Why It’s Trending:
In a competitive marketplace, pricing is a critical factor. Pricing Maker’s AI-powered approach allows businesses to make data-backed decisions quickly, ensuring they stay ahead of the curve.

3. Supafit
Supafit is the AI companion that guides you on your fitness journey, coaching and empowering you to self-serve your way toward sustainable progress. Daily and Weekly Reports provide actionable recommendations for you to reach your goals efficiently.

Applications:

Personalized Workouts: Supafit designs custom fitness programs based on user data, including body metrics, workout history, and personal goals.
Diet and Nutrition: It provides AI-generated meal plans that match the user’s fitness objectives, whether it’s weight loss, muscle gain, or maintaining a balanced lifestyle.
Real-time Feedback: The app tracks users’ progress and adjusts workouts accordingly, providing real-time feedback to optimize performance and prevent injuries.

Why It’s Trending:
With the growing emphasis on health and wellness, Supafit stands out by combining AI technology with personalized fitness plans, making it easier for users to achieve their goals without needing personal trainers.

4. Fill Genius
Fill Genius is a tool to automate form-filling in seconds with AI.

Applications:

Product Listing: Quickly fill out product details across multiple directories.
VC Pitch Deck Forms: Save time when submitting the same information to different investors.
Job Applications: Avoid filling out repetitive forms for job applications with auto-populated fields.

Why It’s Trending:
In a world that relies heavily on paperwork and forms, Fill Genius brings automation to mundane tasks, saving significant time.

5. Loomos
Through Loomos you can convert rough Loom recordings into professional videos. It can transform raw screen recordings into studio-quality videos in a single click.

Applications:

AI-Powered Transcript Editing: Edit your transcript yourself, or use AI to generate an improved version automatically. Our AI cleans up 'uhms' and improves grammar for a polished result.
Aesthetic Background Images: Enhance your videos with beautiful background images to create a polished look.
Multilingual Translation & AI Voiceovers: Translate to multiple languages and select from a variety of AI voiceovers that sound professional yet human-like, with different accents available.

Why It’s Trending:
With the rise of remote work, Loomos is quickly becoming an essential tool for professionals who want to stay organized and ensure that meetings lead to actionable results.

By incorporating these trending AI tools into your workflow, you can stay ahead of the curve and maximize efficiency in your personal or professional life.

Best Tool for Query anything with SQL

Shubham — Tue, 29 Oct 2024 04:54:07 +0000

Query anything (JSON, Salesforce, GitHub, Airtable, etc.) with SQL and visualize your data with any MySQL-compatible BI tool.

Anyquery is a SQL query engine that allows you to run SQL queries on pretty much anything. It supports querying JSON, CSV, Parquet, SQLite, Airtable bases, Google Sheets, Notion databases, logs file using Grok, and more. It also supports running SQL queries on remote files (HTTP, S3, GCS) and local apps (Apple Notes, Apple Reminders, Google Chrome Tabs, etc.). It's built on top of SQLite and uses plugins to extend its functionality.

Moreover, it can act as a MySQL server, allowing you to run SQL queries from your favorite MySQL-compatible client (e.g. Looker Studio, DBeaver, TablePlus, Metabase, etc.).

Anyquery is plugin-based, and you can install plugins to extend its functionality. You can install plugins from the official registry or create your own. Anyquery can also load any SQLite extension.

You can refer to the link below for detailed information and an installation guide. Also if you want to contribute you can refer Contributing section.

*Try it out --> *

7 Kubernetes Security Best Practices in 2024

Shubham — Tue, 29 Oct 2024 04:42:31 +0000

Kubernetes (K8S) has revolutionized software development, but managing such a complex system with numerous components can be challenging. Fortunately, there are several best practices your team can adopt to secure your K8S environment and reduce your attack surface. By implementing these Kubernetes security best practices, you'll not only enhance your cybersecurity defenses but also improve various other business processes.

1. Adopt a Zero Trust Architecture
Kubernetes systems contain a large number of clusters and nodes, all of which can talk to each other. That makes it easy for attackers to move laterally across your network and cause damage, so it's simply too dangerous to assume an access request is authorized just because it's already on the inside.

Zero Trust architecture employ a "never trust, always verify" approach to network validation, and they're essential for securing Kubernetes platforms.

2. Implement Least Privilege Access
Zero Trust architecture uses the least privilege principle to assess the legitimacy of access requests. This principle grants your users the bare minimum amount of access that they need to perform their tasks, preventing them from accessing unauthorized resources.

To optimize your Kubernetes cybersecurity, implement a least privilege-based access management system. Structure your permission levels according to the bare minimum access necessary for users to do their work, and disallow access to anything more.

3. Use Multi-Factor Authentication (MFA)
Multi-factor authentication adds an extra layer of cybersecurity to your K8S platform. A simple password is no longer enough in today's threat landscape, and MFA requires users to provide additional information to log in to your system. Some common types of MFA are:

SMS/email
Authenticators
Biometrics (fingerprints, retinal scans, voice patterns, user behavior)
Digital Certificates
Security Tokens

Research from Google has shown that MFA can reduce the likelihood of a breach by over 99% in some cases. The exact numbers may vary based on the configuration of your K8S environment, but one thing is clear: Integrating MFA into your Kubernetes system can significantly reduce the likelihood of a breach. If you want to strengthen your K8S system, you'll want to implement MFA.

4. Regularly Update and Patch Clusters
Attackers often attempt to exploit long-standing vulnerabilities, especially those that could have been resolved with an update or patch. Stale Kubernetes containers may still possess these vulnerabilities, leaving your network exposed.

Updating your clusters and frequently applying patches are essential ways of remediating vulnerabilities. The exact frequency may vary with your application, but make routine patches and updates a part of your K8S security best practices.

5. Implement Pod Security Standards
Kubernetes' Pod Security Standards put forth three broad policies to outline where an organization's needs lie on the security spectrum. They are:

- Privileged: Provides the broadest possible level of permissions.
- Baseline: Allows the default (minimally specified) pod configuration.
- Restricted: The most heavily controlled policy, it follows current pod hardening best practices.

By applying Pod Security Standards to your K8S environment, you can lay a foundation for how to restrict pod behavior. This minimizes the risk of a breach or unauthorized lateral movement and enhances security across each pod and cluster in your environment. As you implement your Kubernetes security best practices, consider using the Pod Security Standards to lay out a broad framework for your operations.

6. Implement Role-Based Access Control (RBAC)
Role-Based Access Control (RBAC) is a highly granular access control method that restricts your users from certain assets based on their position within your organization. It grants users access only to the most essential resources they need to perform their tasks and reduces the likelihood of an unauthorized user gaining access to a Kubernetes node or cluster and then moving laterally to breach other assets.

RBAC should be prioritized as a Kubernetes security best practice. The process can take some know-how, so consider using a third-party solution with the expertise that can simplify the process.

7. Use Network Policies to Control Traffic
Network policies restrict which entities your pod is allowed to communicate with. Kubernetes bases its network policies on three identifiers, which serve as criteria for assessing whether you can share information between pods. They are:

Other allowable pods
Allowable namespaces
IP blocks

With these policies, your team can monitor your network traffic and discern between active and permissible traffic, which helps you identify network anomalies and areas of unnecessarily granted permission. Security teams should implement network policies to regulate how your pods communicate and who they can communicate with so you can keep your network secure.

How to Fix Kubernetes Node Disk Pressure

Shubham — Mon, 28 Oct 2024 11:00:49 +0000

Imagine you deploy an application, but after a few days, it starts throwing warnings like this:

Warning  NodePressure  [timestamp]  kubelet  Node [node-name] status is now: NodeHasDiskPressure

Your application slows, pods get evicted, and new ones fail to schedule. This common error in Kubernetes is known as Node Disk Pressure, and if left unchecked, it can severely impact application performance.

What is Kubernetes Node Disk Pressure?
Node Disk Pressure occurs when a node’s filesystem is under strain due to low available disk space or inodes.

Kubernetes automatically detects these low resource conditions and sets a NodeHasDiskPressure status.

This status signals that the node has insufficient disk resources for further scheduling, evicting non-critical pods to prevent critical system disruptions.

How to Check Kubernetes Node Disk Pressure
How to Check Kubernetes Node Disk Pressure:

kubectl describe node [node-name]

Look for any nodes with the condition type DiskPressure and status True. In the output, focus on the Conditions section.
Here’s an example where ops-node1 is experiencing disk pressure:

ops-node1 Ready worker 14d v1.28.1 DiskPressure=True,MemoryPressure=False,PIDPressure=False,Ready=True

Additionally, use this command to monitor disk usage:

kubectl top nodes

This shows overall CPU, memory, and disk usage for each node, helping you pinpoint where Disk Pressure is affecting your nodes.

Why Should You Care About Node Disk Pressure?
Ignoring Disk Pressure can lead to various issues:

Pod Eviction: Kubernetes evicts lower-priority pods to free up disk space, which can cause disruptions in non-critical workloads.
Scheduling Failures: New workloads may not deploy if nodes are in a Disk Pressure state.
Performance Degradation: Insufficient disk space impacts node performance and can lead to application latency.

How to Fix Kubernetes Node Disk Pressure
Here are some strategies to address Disk Pressure:

Clean Up Disk Space: Clear out unused images and containers, which can take up significant space.

Increase Node Disk Size: If your nodes are in a cloud environment, consider resizing disks. In AWS, for instance - Increase the EBS volume size.

Move Logs and Data to Separate Disks: If your node frequently generates large logs, consider mounting a separate disk for log storage to keep system space free.

Implement Resource Quotas and Limits:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: storage-quota
  namespace: [namespace]
spec:
  hard:
    requests.storage: 20Gi

Monitor with Alerts:
Use Prometheus or another monitoring tool to set up alerts when disk usage exceeds a threshold. This proactive approach helps you intervene before Disk Pressure arises.

Hope this helps in tackling one of the common Kubernetes challenges.

How To Fix OOMKilled

Shubham — Fri, 25 Oct 2024 12:45:46 +0000

OOMKilled occurs in Kubernetes when a container exceeds its memory limit or tries to access unavailable resources on a node, flagged by exit code 137.

Typical OOMKilled looks like

NAME                READY     STATUS        RESTARTS     AGE
web-app-pod-1       0/1       OOMKilled     0            14m7s

"Pods must use less memory than the total available on the node; if they exceed this, Kubernetes will kill some pods to restore balance."

Learn more about OOMKilled visually here:

How to Fix OOMKilled Kubernetes Error (Exit Code 137)

Identify OOMKilled Event: Run kubectl get pods and check if the pod status shows OOMKilled.
Gather Pod Details: Use kubectl to describe pod [pod-name] and review the Events section for the OOMKilled reason.

Check the Events section of the describe pod, and look for the following message:

State:          Running
       Started:      Mon, 11 Aug 2024 19:15:00 +0200
       Last State:   Terminated
       Reason:       OOMKilled
       Exit Code:    137
       ...

Analyze Memory Usage: Check memory usage patterns to identify if the limit was exceeded due to a spike or consistently high usage.
Adjust Memory Settings: Increase memory limits in pod specs if necessary, or debug and fix any memory leaks in the application.
Prevent Overcommitment: Ensure memory requests do not exceed node capacity by adjusting pod resource requests and limits.

Point worth noting:

"If a pod is terminate due to a memory issue. it doesn’t necessarily mean it will be removed from the node. If the node’s restart policy is set to ‘Always’, the pod will attempt to restart"

To check the QoS class of a pod, run this command:

kubectl get pod -o jsonpath='{.status.qosClass}'

To inspect the oom_score of a pod:

Run kubectl exec -it /bin/bash
To see the oom_score, run cat/proc//oom_score
To see the oom_score_adj, run cat/proc//oom_score_adj

The pod with the lowest oom_score is the first to be terminated when the node experiences memory exhaustion.

K8s Plugins For Solid Security

Shubham — Fri, 25 Oct 2024 12:24:00 +0000

Kubernetes simplifies building and deploying apps via containerization, but securing your pods and containers is a different challenge.

Kubernetes provides basic IP-based security for each pod, but securing your clusters requires more—network policies, access policies for individual pods, RBAC, namespace access policies, and so on.

However, many open-source tools and plugins can help manage these issues.

Let's explore some of the most useful ones:

1. Kube bench (⭐: 6,977 +)
Kube-bench is a tool that checks Kubernetes clusters for compliance with security best practices, based on the CIS Kubernetes Benchmark. It helps identify vulnerabilities and misconfigs, providing detailed reports for remediation.

YAML-based test configuration allows easy updates as specs evolve.
kube-bench auto-selects tests for the node's Kubernetes version.

2. Stern (⭐: 3,265 +)
Stern allows you to tail multiple pods and containers in Kubernetes, with color-coded log results for faster debugging.

Filters pods with regex or /, no exact pod IDs needed.
Tails all pod containers by default, but you can limit with the container flag.
Auto-removes deleted pods, and adds new ones as created.

3. Kubescore (⭐: 2,750 +)
Kube-score is a tool that performs static code analysis of your Kubernetes object definitions, checking them against best practices to ensure proper configurations.

Evaluates resource definitions like Deployments, Services, and Ingresses for misconfigs.
Supports CRD validation, checks labels, resource limits, and other key configs.
Provides a score based on best practices and highlights issues.

4. Kubiscan (⭐: 1,313 +)
KubiScan is a tool for scanning Kubernetes clusters for risky permissions in the RBAC authorization model.

Identify risky Pods\Containers
Identify risky Roles\ClusterRoles
Identify risky RoleBindings\ClusterRoleBindings
Identify risky Subjects (Users, Groups and ServiceAccounts)
Dump tokens from pods (all or by namespace)
CVE scan

5. Rakkess (⭐: 1,300 +)
Rakkess is a kubectl plugin designed to show an access matrix for Kubernetes server resources, helping visualize and audit permissions.

Shows who can access Kubernetes resources and their actions.
Audits RBAC permissions for users, groups, and service accounts in a clear matrix view.
Supports CI/CD integration for continuous RBAC audits.

Remember, we are only as strong as the weakest link.

Hidden Risk Of Relying On Labels In Kubernetes Security

Shubham — Fri, 25 Oct 2024 12:05:44 +0000

A while ago, a person approached my mentor with a request to optimize the network security of their Kubernetes cluster.

He had a complex architecture with microservices talking to each other, and he was using NetworkPolicy to control communication.

However, despite their policies, they were seeing some unintended traffic flows that left them concerned.

Upon investigation, we noticed that their policies were built around pod labels.

Here’s an example (modified the identity) of what they had in place:

apiVersion: networking.k8s.io/v1

kind: NetworkPolicy

metadata:

name: access-control-database

spec:

podSelector:

matchLabels:

app: ops-examples-db

policyTypes:

- Ingress

ingress:

- from:

- podSelector:

  matchLabels:

role: admin

The intention was clear: only pods with the role: admin label could access the ops-examples-db pod.

On closer inspection, I noticed potential issues:
Labels Could Be Modified: Developers could label any pod as role: admin at runtime, granting it database access.

Namespace Confusion: Policies often overlooked namespaces, allowing a role: admin pod in the dev environment to mistakenly access production services.

After discussing the concerns with that person, my mentor asked if they were using Istio.

They were already using Istio for traffic management but hadn’t considered it for network security.

This presented a good opportunity!

Leveraging the Existing Setup:
We switched from pod labels to ServiceAccounts for more secure access control.

Here’s how the updated policy looks like:

apiVersion: security.istio.io/v1

kind: AuthorizationPolicy

metadata:

name: access-control-istio

spec:

rules:

- from:

- source:

principals: ["cluster.local/ns/ops/sa/admin-service-account"]

Now, only pods associated with the admin-service-account could access the ops-examples-db.

This was more reliable, as ServiceAccounts offer a secure identity without relying on easily altered or misconfigured labels.

Why It Worked Better?

Tighter Control:
ServiceAccounts eliminated the risk of unauthorized access via label changes by tying access to pod identity.
Built-In Security:
Network traffic is encrypted with TLS, preserving identity across clusters and environments.
No New Tools:
The client was already using Istio, so no additional deployment was needed.

If you're using Kubernetes and relying on labels for access control, consider alternatives for better security and scalability.

Until next time, stay secure and keep optimizing!

How to Set up Disk and Bandwidth Limits in Docker

Shubham — Fri, 25 Oct 2024 11:41:55 +0000

Containerized applications are increasingly popular due to their portability and scalability.

However, uncontrolled use of system resources like disk space and bandwidth can lead to performance bottlenecks, security risks, and even system downtime.

Here’s why setting limits becomes crucial:
Disk Overrun: Without limits, containers may consume excess disk space, impacting other applications.

Network Saturation: Unregulated bandwidth can throttle the performance of critical services.

Security Risks: Unrestricted usage increases the risk of DoS attacks or resource exhaustion.

Step-by-Step Instructions for Disk and Bandwidth Limits:
In this example, let's set the disk size limit to 10 GB and the bandwidth limit to 10 Mbps.

We've chosen Ubuntu, a widely used Linux distribution in cloud and container environments.

Step 1: Set Disk Size Limit to 10GB:

Edit the Docker Daemon configuration file to enforce a disk limit:

sudo nano /etc/docker/daemon.json

Add this configuration to restrict containers to 10GB of disk space:

{

"storage-driver": "overlay2",

"storage-opts": [

"overlay2.size=10G"

]

}

Restart Docker to apply the limit:

sudo systemctl restart docker

Step 2: Set Bandwidth Limit to 10Mbps
Create a script that limits bandwidth for all Docker containers:

sudo nano /usr/local/bin/limit_bandwidth.sh

Add the following content to the script:

#!/bin/bash

INTERFACE=$(docker inspect -f '' $(docker ps -q))

tc qdisc add dev $INTERFACE root tbf rate 10mbit burst 32kbit latency 400ms

Make the script executable:

sudo chmod +x /usr/local/bin/limit_bandwidth.sh

Create a systemd service to apply the bandwidth limit automatically when Docker starts:

sudo nano /etc/systemd/system/docker-bandwidth-limit.service

Add this content to the service file:

[Unit]

Description=Limit bandwidth for Docker containers

After=docker.service

[Service]

ExecStart=/usr/local/bin/limit_bandwidth.sh

Type=oneshot

RemainAfterExit=true

[Install]

WantedBy=multi-user.target

Enable the service and start it:

sudo systemctl daemon-reload

sudo systemctl start docker-bandwidth-limit.service

sudo systemctl enable docker-bandwidth-limit.service

Step 3: Verify the Limits

Run a container above the 10GB limit:

docker run -d --storage-opt size=15G ubuntu

Expected output:

Error response from daemon: error creating overlay mount to /var/lib/docker/overlay2: disk quota exceeded

Try exceeding the 10Mbps bandwidth limit:

docker run -d --cap-add=NET_ADMIN ubuntu tc qdisc add dev eth0 root tbf rate 20mbit burst 32kbit latency 400ms

Expected output:

Error: argument "20mbit" is wrong: Rate too high for configured limit

With this, you create a controlled and predictable environment.

Hope you find this use case helpful in your learning journey!

What are Kata Containers?

Shubham — Fri, 25 Oct 2024 10:25:53 +0000

Kata Containers perform like containers, but provide the workload isolation and security advantages of VMs. It combines the benefits of containers and VMs.

The project is managed by the OpenStack Foundation.

With Kata, you can implement VM isolation at the container level and container isolation using hardware virtualization.

However, in Kubernetes, VM isolation applies at the pod level rather than individual containers.

Difference between Kata and Traditional containers:

As you can see in the above image, Kata Containers run each container inside its own virtual machine (VM) with a separate Linux kernel, providing stronger isolation.

In contrast, traditional containers share a single Linux kernel and use namespaces and cgroups for isolation. This highlights the key difference in how they handle security and isolation.

The architecture consists of six key components:

Agent:
Manages container execution and communication inside the virtual machine.
Runtime:
Executes container lifecycle commands, following OCI specifications.
Proxy:
Facilitates communication between the runtime and the virtual machine through gRPC.
Shim:
Provides compatibility for handling I/O and process management specific to each application.
Kernel:
The virtual machine’s operating system kernel, ensures isolated environments for containers.
Hypervisor (QEMU):
Provides hardware virtualization, isolating containers in lightweight virtual machines.

Why Kata Containers are better Secured?

Conventional containers pose security risks because they share the same OS kernel, network, and memory. A single compromised container can expose all others on the same system.

Kata Containers improve security by running each container in its own virtual machine with a dedicated kernel, isolating processes, networks, and memory. They also use hardware-based isolation with virtualization extensions, adding an extra layer of protection.

Points to Consider:

Only available on Linux distributions.
CentOS
Debian
Fedora
Ubuntu
OpenSUSE
Red Hat Enterprise Linux
Still in early development, but widely adopted with promising technical foundations.
Supports Kubernetes, Docker, OCI, CRI, CNI, QEMU, KVM, and OpenStack.

installation and more details here

Kata containers are best for situations where containers need to run on different kernels, like in CI/CD, edge computing, virtualized networks, and containers as a service (CaaS).

A promising prospect to try out !