Forem: Puru

Should you be vibe coding?

Puru — Mon, 19 May 2025 20:10:38 +0000

After the recent post by DHH about “vibe coding”, I too felt the urge to take a plunge into the “vibe coding” pool as to what it is, and why it’s appealing.

Enter the vibe coding

The term “vibe coding” was coined by Andrej Karpathy , who was also a founding member of OpenAI. As Karpathy describes, vibe coding is when you don’t think about code, you blindly trust whatever LLMs throws at you, and you vibe your way into building something.

This approach to software development is made possible by how far language models have come (like Claude Sonnet), along with the rise of AI-powered editors such as Cursor and GitHub Copilot in VS Code. Vibe coding or not, coding with AI is quickly becoming the new default.

Why vibe coding appeals

Traditional software development has a steep entry barrier. You need to learn a programming language, grasp the intricacies of a framework, and spend significant time just getting something basic to work. That complexity often discourages newcomers.

Vibe coding flips that on its head. With high-quality LLMs, you can go from idea to execution almost instantly. The results are often “good enough” to keep moving, without rewriting everything line by line.

It’s not just about speed — it’s about maintaining creative momentum. When the feedback loop is tight, building feels fun again.

After the “vibe rush”

But what happens once the initial excitement, the “vibe rush” wears off?

For some, it’s the start of something deeper. They see potential in their idea and shift gears, using AI as a coding assistant rather than letting it lead. They invest time in understanding, refining, and iterating.

For others, it’s the end of the road. They realize they were never interested in the code itself — just the thrill of rapid prototyping. Once the novelty fades, so does their engagement. The outcome was what mattered, not the process.

Why vibe coding will thrive

Vibe coding dramatically lowers the barrier to entry. It removes much of the intimidation around building software, making it accessible to non-developers, creatives, and solo entrepreneurs.

For example, indie hackers and solo entrepreneurs can test ideas quickly, validate them, and iterate — all without a traditional software engineering background. The world may start to see many more levelsio emerging, building fast and in public.

Ultimately, vibe coding is reshaping how people approach software development. It provides instant gratification, builds confidence, and lets newcomers figure out whether this path is for them. Some will move on. Others will go deeper. But either way, vibe coding opens the door.

Ready to vibe?

If this got you excited about building with AI, now’s the perfect time to dive deeper. Start your journey with A Beginner’s Guide to Using Cursor, the AI Code Editor — a hands-on guide to one of the best AI coding editors available.

https://cursor.purutuladhar.com/

Preparing for the CKS? Don't let Falco catch you off guard. In this article, I break down what you need to know about Falco by Sysdig for the exam.

Puru — Tue, 22 Apr 2025 08:17:13 +0000

Puru

Apr 22 '25

🦅 Falco: Must-know for CKS exam

#falco #kubernetes #security #cks

Comments 2

4 min read

🦅 Falco: Must-know for CKS exam

Puru — Tue, 22 Apr 2025 08:15:27 +0000

👋 First of all, I am excited to share that I've officially become a Kubestronaut (read it here). Among the five Kubernetes certifications, the CKS (Certified Kubernetes Security Specialist) was by far the toughest. In fact, I missed passing on my first attempt by just 2% (read it here). That experience inspired me to create the 📖 CKS Handbook, which is now in its 2nd Edition, updated to reflect the latest changes to the CKS curriculum.

In this blog, we will explore what you need to know about Falco to prepare for the CKS exam. Falco is a key part of the CKS curriculum under "Monitoring, Logging, and Runtime Security" which accounts for about 20% of the exam.

Anyone who's taken the CKS exam knows that Falco-related tasks can quickly eat up your time if you're not well prepared. So let's dive in!

🪏 Falco by Sysdig

Falco is an open-source cloud-native runtime security tool originally created by Sysdig and donated to the CNCF in 2018. It provides runtime security for Linux hosts, containers, Kubernetes, and cloud environments. For the scope of the CKS exam, focus only on the container runtime security.

Falco is designed to detect and alert on abnormal behavior and potential security threats in real-time. These malicious behaviors are identified through Falco rules, and then using Falcosidekick to alert on the suspicious events. Falcosidekick is out of scope for the exam.

📕 Rules of Falco

Falco rules are what you, as a Kubernetes security engineer, need to write or maintain to detect malicious behaviors in your Kubernetes environment.

The default Falco rules file is stored in /etc/falco/falco_rules.yaml. Every rule definition contains at least the following fields:

Rule, Desc: Name and short rule description.
Condition: Key part of the rule, which determines if the rule should be fired or not based on a Boolean expression matching event fields.
Output: Human-friendly log message that Falco emits, can include event metadata by prefixing % before event field.
Priority: Every Falco rule has a priority, indicating how serious a violation of the rule is.

📝 NOTE: In the exam, you are allowed to refer to the Supported Fields for Conditions and Outputs page.

🐚 Shell in the container

Here is a custom Falco config in YAML with a rule to detect if a shell is spawned in a container, which is often a sign of debugging gone wrong, misconfigured containers, or possible malicious attempts, such as IngressNightmare remote code execution.

The config begins with macros to simplify writing Falco rules. Pre-defined Falco macros come bundled in /etc/falco/falco_rules.yaml.

The spawned_process macro condition filters system call events by execve, which is the syscall for executing a new program in Linux, and evt.dir=< means the syscall is entering, i.e., the execution is starting.
The container macro checks that the event is coming from a container and not the host system.

Next, we define a rule using the macro above. The rule is triggered when a process is started (spawned_process) and it happens inside a container, and the process name is bash (i.e., someone is starting a shell).

In the rule’s output, we include useful context using user fields, container fields, and k8s fields to get Kubernetes-related metadata.

📝 NOTE: In the exam, you are allowed to access the Falco example rules.

✍️ Falco in the exam

In the exam, you will encounter at least one Falco-related task. You may be asked to:

Run Falco with custom rules on a specific worker node and save logs of detected malicious processes.
Investigate Falco logs to identify malicious containers and gather details Kubernetes Pod name and namespace using the crictl tool.

When solving tasks, adopt the mindset of a security engineer, as the questions typically reflect real-world scenarios that a Kubernetes security professional would face.

💡 TIP: Keep the Falco documentation accessible during the exam, particularly the Supported Fields for Conditions and Outputs page, as you’ll need to understand which event fields to include in your Falco logs.

Up Next

In the upcoming article, we will gain hands-on Falco experience by installing it, implementing custom rules, and analyzing Falco logs — essential practice for the CKS exam.

To accelerate your preparation, check out my CKS Handbook — 2nd Edition, which provides comprehensive coverage of Falco and all other CKS exam topics_,_ updated to reflect the latest curriculum changes.

As a thank you to the readers of this article, use discount code FALCO15 to get 15% off on my CKS Handbook — 2nd Edition. — Puru

Cilium: Everything you need to know for CKS

Puru — Thu, 16 Jan 2025 06:44:53 +0000

First of all, I am excited to share that I've officially become a Kubestronaut (2 weeks ago, read it here). Among the five Kubernetes certifications, the CKS (Certified Kubernetes Security Specialist) was by far the toughest. In fact, I missed passing on my first attempt by just 2% (read it here). That experience inspired me to create the CKS Handbook, which is now in its 2nd Edition, updated to reflect the latest changes to the CKS curriculum.

With the Oct 2024 CKS exam program changes, implementing Pod-to-Pod encryption using Cilium is now a key topic under the Minimizing Micro-services Vulnerability domain. In this blog, we'll explore Cilium and everything you need to know about Cilium traffic encryption for the exam.

Getting to know Cilium

Cilium is an open-source, cloud-native solution providing networking, security, and observability for cloud-native environments such as Kubernetes clusters.

Cilium's core is built upon the revolutionary Linux kernel technology called eBPF which allows the dynamic insertion of control logic into the Linux kernel. Cilium offers many powerful features, but for the CKS exam, the focus is on Cilium's transparent encryption capability.

Understanding Cilium Architecture

Cilium's architecture comprises four key components:

The agent (cilium-agent) runs as a pod on each node in the Kubernetes cluster as a DaemonSet. The agent manages the eBPF programs which the Linux Kernel uses to control all network access in/out of those containers.
The client (cilium-dbg) is a command-line tool bundled with the Cilium agent. It interacts with the Cilium agent API on the same node for inspecting the state and status of the local agent.
The operator is responsible for cluster-wide Cilium operations, and there should only be one active operator per cluster. For high availability, the Cilium operator uses Kubernetes leader election library.
The CNI plugin (cilium-cni) is invoked by Kubernetes when a pod is scheduled or terminated on a node. The plugin interacts with the Cilium agent to configure networking, load-balancing, and network policies for the pod.

What you need to know

The CKS exam requires that you know how to implement pod-to-pod traffic encryption using Cilium. In Cilium terms, this feature is called transparent encryption and there are two options to encrypt traffic: IPSec and WireGuard. Both of these are VPN technology that enables secure communication between pods across different nodes in a Kubernetes cluster.

By default, Kubernetes doesn't natively offer encryption of data in transit as such this feature is essential for several reasons:

Compliance requirements: Many regulatory frameworks, such as PCI and HIPAA, mandate the encryption of data in transit.
Security: Encryption prevents man-in-the-middle (MITM) attacks, ensuring that sensitive information remains confidential as it travels across potentially unsecured networks.

Verify Encryption Status

You can verify the encryption status of Cilium deployment using cilium CLI from any of the running Cilium agents using the following command.

kubectl -n kube-system exec -it ds/cilium -- cilium encrypt status

In the default Cilium deployment, the output will show:

Encryption: Disabled

Pod-to-Pod Encryption via IPSec

Step 1. First, we need to generate a random Pre-Shared Key (PSK)

dd if=/dev/urandom count=20 bs=1 2>/dev/null | xxd -p -c 64

Step 2. We need to store this as a Kubernetes secret. Cilium will use this secret and mount it as a volume in the cilium-agent Pods.

kubectl create -n kube-system secret generic cilium-ipsec-keys --from-literal=keys="3+ rfc4106(gcm(aes)) $PSK 128"

Step 3. Install Cilium and configure IPsec encryption.

cilium install --encryption ipsec

Step 4. Verify that IPSec encryption is active. The output should show "Encryption: IPSec" and IPSec key details.

Encryption: IPsec
Keys in use: 1
Max Seq. Number: 0x0/0xffffffff
Errors: 0

Pod-to-Pod Encryption via WireGuard

Unlike IPsec, WireGuard automates encryption key pair generation and rotation, so there's no need to create an encryption key.

Step 1. Install Cilium and configure WireGuard encryption.

cilium install --encryption wireguard

Step 2. Verify that WireGuard encryption is active. The output should show "Encryption: Wireguard" and WireGuard interface details.

Encryption: Wireguard
Interface: cilium_wg0
        Public key: nw2/evMwulhWhb3yij0J6T6ET9cPypExeUM5rKyKGHs=
        Number of peers: 3

Conclusion

I hope this guide has provided valuable insights to help you prepare for the CKS exam. For more detailed guidance, consider exploring my CKS Handbook which provides detailed step-by-step guidance on:

Configuring Pod-to-Pod encryption with IPsec and WireGuard.
Navigating other CKS domain topics effectively.

The updated second edition is designed to align with the latest exam curriculum.

📕 Grab your copy of the CKS Handbook - 2nd Edition today with discount code ENCRYPT25 to get 25% off as a thank-you for readers of this article - Puru

11th Dec 2024 — OpenAI Outage (ChatGPT) Explained: Kubernetes Clusters on Fire!

Puru — Mon, 16 Dec 2024 13:29:41 +0000

Last week, December 11th, 2024, OpenAI faced an SRE nightmare. A major platform outage lasting four hours affected ChatGPT and SORA (OpenAI's video generation model) due to faulty service deployment, bringing down their largest Kubernetes clusters to the knees. On-call engineers were locked out of the cluster, preventing them from running kubectl.

Rollout turned bad

The root cause was a bad rollout strategy for their new telemetry service deployment, which collected Kubernetes control plane metrics. This telemetry service overwhelmed the API server by sending a high volume of resource-intensive API calls, the cost of which scaled with the size of the cluster.

Service not discovering

The worst part was that the issue was not caught until the rollout began fleet-wide and propagated to their largest clusters running mission-critical workloads. DNS caching mitigated the impact temporarily by providing stale cached records to DNS queries, it only made the issue worse.

After the DNS cache expired over the following 20 minutes, the telemetry service rollout had already propagated to their largest clusters running mission-critical workloads, and suddenly, a surge of real-time DNS queries overloaded the DNS server (CoreDNS likely) running on their control plane, which is already on stress due to telemetry service running resource-intensive API operations. As a result, the DNS-based service discovery for the cluster became unresponsive, leading to the application pod not being able to perform real-time DNS resolutions.

No way to get into the cluster

On-call engineers were not able to roll back this telemetry service as they were locked out and unable to access the Kubernetes control plane due to extensive load. I've experienced this exact issue before, and anyone who's faced this situation knows just how challenging it can be to recover an unresponsive API server.

Ultimately, they were able to recover the API server and bring clusters back up by reducing the API operations in several ways, such as blocking network access to Kubernetes admin APIs and scaling up Kubernetes API servers. Finally, they rolled back the faulty telemetry service deployment.

Lesson re-learned

In response to this major outage, OpenAI has laid out the following action items to prevent such large-scale outages from happening again.

Firstly, the phased rollout will be improved going forward by continuously monitoring the health of the workload and the Kubernetes control plane.
Conduct fault injection testing to ensure that the Kubernetes data plane running production workloads can function without a control plane for a longer period of time.
Get rid of the dependency on Kubernetes DNS for service discovery and decouple the Kubernetes data plane from the control plane to ensure the control plane doesn't play any major role in processing production workloads.
Implement a break-glass mechanism for on-call engineers to be able to access the Kubernetes API server under any circumstances.

In today’s fast-paced, AI-driven world, where you can ship features as fast as you can think, platform reliability is crucial. This incident underscores that delivering features reliably is no easy feat, and if not planned properly, it directly impacts the product, consumers, and investors.

And remember, when in doubt, it's always DNS. After all, if it's not DNS, it's probably just DNS pretending to be something else! - Puru Tuladhar

Avoid Using “bloated” Node.js Docker Image in Production!

Puru — Mon, 21 Oct 2024 14:09:00 +0000

🏃‍➡️ TL;DR

❌ Avoid "bloated" image in production: node:22, node:latest, node:lts, node:current
✅ Use "slim" variant image in production, i.e., node:lts-slim, node:22-slim
❌ Avoid "non-LTS" and odd-numbered releases, i.e., node:slim, node:current-slim, node:bookworm-slim, node:23, node:21
✅ Use even-numbered "LTS" release, i.e., node:20-slim, node:22-slim, node-lts-slim

🤦🏻‍♂️ Bad choice

As per Docker Hub, Node.js image gets 9 million weekly image pulls with 1+ Billion image already pulled and counting.

Unfortunately, use of buildpack-deps based version of NodeJS image by default leads to unnecessarily bloated image, full of dev packages, compilers and riddled with CVEs. Avoid using "bloated" image at all cost in production, but why?

Slower deployment times: "bloated" images are significantly larger, slows down deployment times.
Disk spaces: "bloated" image due to it's size, consumes more disk space when uncompressed.
Security risks: With more packages included, higher risk to new security vulnerabilities and supply chain attacks.
Slow startup-times: A larger image can slow down startup times.

Ivan from iximiuz Labs did a post mortem analysis of node:22 image and highlights the buildpack-deps:stable and buildpack-deps:scm layer image on-top of Debian base image (bookworm) is where all the "bloat" comes from, including a full Python installation and the GNU Compiler Collection (GCC), which contributes to larger image size.

# 🤯 >1GB in image size 
$ docker images node

REPOSITORY   TAG              IMAGE ID       CREATED       SIZE
node         22               c9d4a6dda881   4 days ago    1.12GB
node         bookworm         8c96be300ba8   4 days ago    1.12GB
node         current          8c96be300ba8   4 days ago    1.12GB
node         latest           8c96be300ba8   4 days ago    1.12GB
node         lts              85f76d7c2b89   2 weeks ago   1.1GB

# 🪲 Riddle with vulnerable libraries
$ trivy image -q node:22

node:22 (debian 12.7)
=====================
Total: 997 (UNKNOWN: 4, LOW: 492, MEDIUM: 419, HIGH: 76, CRITICAL: 6)

# 🤨 Do you need GCC compiler?
$ docker run --rm -it node:22 gcc --version

gcc (Debian 12.2.0-14) 12.2.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

# or 🐍 full Python installation?
$ docker run --rm -it node:22 python3 --version

Python 3.11.2

😌 Be calm and use "slim" variant

As you can see from above image, "bloated" image is perfect as a builder image during build stage and "slim" variant as a runtime image for production use.

"Slim" variant is 80% thinner with lot less build/dev packages, that means faster deploys, less disk space, more secure, faster start up times.

For most Node.js projects running "slim" variant in production is a safer and optimal choice due to it's balanced of size and installed packages.

# Use "slim" variant for production
FROM node:lts-slim
FROM node:22-slim

# 👌🏻 Thinner and smaller image size
$ docker images node
REPOSITORY   TAG              IMAGE ID       CREATED       SIZE
node         22-slim          ddf2ab152dc9   4 days ago    240MB
node         22-alpine        e906dc0e8219   4 days ago    153MB
node         lts-slim         1658b30e8115   2 weeks ago   220MB

⚠️ Be careful with "Alpine" variant

Even though "alpine" variant is 30% thiner than "slim" variant, avoid using it for mission-critical NodeJS applications.

Alpine is considered experimental and not officially supported target platform for Node.JS.
"Slim" variant uses Debian, while "Alpine" variant uses Alpine Linux.
Alpine uses "Musl" C library instead of widespread GNU C Library (glibc) which leads to compatibility issue and unexpected behaviors or bugs.

# Avoid "alpine" variant for mission-critical applications
FROM node:lts-alpine
FROM node:current-alpine
FROM node:22-alpine

🤔 But, when should I use "bloated" image?

A "bloated", "full", "debug" image variant includes a full set of development tools and libraries, making it an ideal choice during development but not for production.

After all, just like a chef who brings every spice to the kitchen, it's great for cooking up ideas but not so much for serving dinner! - AI

A "bloated" image serve as a builder image for the multi-stage builds, and slim image for the final runtime stage, resulting in an optimized, small, secure image that is ready for production use.

# Build stage
FROM node:22-lts as builder
WORKDIR /app
COPY . .
RUN npm install && npm run build

# Runtime stage
FROM node:22-slim
ENV NODE_ENV=production
WORKDIR /app
COPY --from=builder /app/dist ./dist
USER node
CMD ["node", "dist/index.js"]

🙃 Wait, what about Distroless variant?

Well…distroless variant is ~30% thinner compared to "slim" variant, and is more secure with no shell, no package manager. But…

"Distroless" variant is not officially supported by Node.js team.
"Distroless" variant do not maintain latest LTS version, unless you pay.

Google provides "distroless" variant but you will get outdated Node.js version that is currently in maintenance mode.

# You get maintenance mode version
$ docker run -it --rm gcr.io/distroless/nodejs --version 
v18.15.0

# Slightly smaller than "slim" variant
$ docker images gcr.io/distroless/nodejs
REPOSITORY                 TAG       IMAGE ID       CREATED         SIZE
gcr.io/distroless/nodejs   latest    5fafa8030b0b   19 months ago   161MB

Chainguard also offers distroless variant but only "latest" tag is free to use which uses non-LTS version, and other tags node:22 is only available for paid users.

# Free to use
$ docker run -it --rm cgr.dev/chainguard/node:latest --version
v23.0.0

If you need to run your mission-critical Node.js applications in highly regulated, secure environment then Chainguard is your best option.

👋 Looking for more?

Feel free to follow me on Twitter or LinkedIn for more insightful contents.

P.S. Don't forget to checkout this insightful tutorial by Ivan and get hands-on on iximiuz Labs.

🍏 If I Got a New Mac, Here's What I'd Install First as a DevOps Engineer 🧑‍💻

Puru — Mon, 30 Sep 2024 07:55:38 +0000

Introduction

Whenever I get a new Mac, the first thing I do is set it up with the apps and tools that make my workflow smooth. These apps help me stay productive, organized, and ready for whatever comes my way. Here's my go-to list of must-have installs:

✅ Accepting Contribution for Hacktoberfest 2024! ✨ - Contribute now!

Essentials for Work and Dev

🌏 Arc → My Safari/Chrome replacement for a cleaner browsing experience.
📺 Warp → My favorite replacement for the built-in Terminal.
📺 Alacritty → Another solid Terminal option.
↔️ Easy+Move+Resize → Easily move and resize windows like on Linux.
🐳 Docker Desktop → For all things Docker.
📊 iStat Menus → Keeping an eye on system performance.
🐶 k9s → A terminal UI for interacting with Kubernetes clusters.
🐚 Fish → My shell of choice, replacing bash and zsh.
📺 Zellij → My preferred Tmux replacement.
📂 exa → An enhanced ls command replacement.
📦 Homebrew + Nix → Package managers to handle everything.
🌈 kubecolor → Makes kubectl outputs more readable.

Code Editors and Tools

🤖 Cursor (📙 Checkout My Book) → VS Code replacement powered by AI.
📝 Sublime Text → My all-time favorite for quick note-taking or file editing.
🐙 GitHub Desktop with GH CLI → For managing Git repositories easily.

macOS Enhancements

🔎 Raycast → Replaces Spotlight, streamlines productivity.
🔘 ChatGPT → My AI assistant on macOS.

Creative and Visual Tools

🎨 Pixelmator Pro → Photoshop for Mac.
🎥 GIPHY Capture → Simple GIF creation tool.

Productivity Boosters

✍️ Day One → Daily journaling for tracking life and work.
⚫️ Obsidian → Powerful note-taking app.
🔵 Trello → Organizing projects and tasks.

Miscellaneous

🌝 Flux → Reduces eye strain by adjusting screen brightness at night.
⬇️ Motrix → The best download manager I’ve found.
🟣 OrbStack → Lightweight Linux VM on Mac.
🟠 Multipass → Another VM option for running Linux.
⏯️ VLC → My go-to video player.
🦙 Ollama → Run LLMs (Large Language Models) locally.

Summary

These are my personal picks, and I’ve found them incredibly useful. If you found this list helpful, please give it a thumbs up, and let me know if there are any apps or tools you think I should try out! 🙌

🤝 LinkedIn (@ptuladhar3) | X (@tuladhar) | GitHub (@tuladhar)

👍 Did you found it helpful? If so, please give it a star ⭐️ and feel free to create an issue or submit a PR for any apps you'd like to include! 🙌

✋🏻 Stop using VS Code Use This — Cursor: The AI Code Editor

Puru — Wed, 25 Sep 2024 09:04:44 +0000

👋 Welcome to the Future of Coding with AI! 🤖

The rise of AI-assisted code editors is transforming programming, making it faster and more efficient. If you’re ready to embrace this shift, my book, “A Beginner’s Guide to Using Cursor — The AI Code Editor,” is the perfect starting point. Whether you’re a beginner or looking to level up, AI can help you write and refine large portions of your code, streamlining your workflow.

Unlock the full potential of AI in coding with my step-by-step beginner’s guide! Grab your copy here with 50% discount, use “CURSOR50”

🤨 What is Cursor?

Cursor is a cutting-edge, AI-powered code editor designed to supercharge coding efficiency for developers of all skill levels. By leveraging advanced AI models like GPT-4 and Claude, Cursor offers intelligent code suggestions, automates repetitive tasks, and helps you become better developer.

💰 Pricing

Cursor offers a free tier that gives you access to powerful coding models like GPT-4, GPT-4o, and Claude 3.5 Sonnet. For those who need more advanced AI capabilities, the Pro plan is available at $20 per month, unlocking even more features and extended AI usage.

🪪 You Own Your Code

Regardless of whether you’re using the Free, Pro, or Business version, all code generated with Cursor is entirely yours — including for commercial purposes. Your code, your rules.

✨ Install Cursor

Getting started with Cursor is simple. Just head over to cursor.com, and download the installer for your platform. Whether you’re on Windows, macOS, or Linux, installation is quick and easy so you can start coding with AI in no time!

NOTE: For Linux users, the download will be in the form of an AppImage. You’ll need to make it executable before running it.

🔍 Quickly Exploring Cursor’s AI Capabilities

Now that you’ve installed Cursor, let’s take a quick glimpse into some of its powerful AI features highlighted in the book that can elevate your coding experience!

Cursor Tab is an AI-driven autocomplete feature that helps you complete your code efficiently. It anticipates your next moves and suggests changes to multiple lines simultaneously, streamlining your coding process.

Cursor Tab enables users to make complex edits with minimal keystrokes — often just a press of the Tab key. This represents a shift in coding tasks, allowing you to focus more on high-level logic and design rather than getting bogged down in syntax details.

🔔 Don’t forget to connect with me on: LinkedIn & follow me on: X (Twitter)

Cursor Chat lets you communicate with an AI using natural language, while accessing your entire codebase. This integration enhances your coding experience by allowing developers to ask questions directly within the editor, eliminating the need to switch to external sources for help.

Cursor allows developers to efficiently edit and generate new code using natural language. This feature streamlines the coding process, letting you express your intentions in plain language and watch as Cursor translates them into functional code.

Cursor Composer is an advanced feature that empowers you to edit multiple files and generate full applications using AI. Here are some of its key features:

Multi-file Editing
Full Application Generation
Contextual Understanding
Interactive Refinement

🔔 Don’t forget to connect with me on: LinkedIn & follow me on: X (Twitter)

Conclusion

Cursor AI is a game-changer in coding, but remember that it’s not a substitute for your expertise. Think of it as a coding assistant — its effectiveness depends on how clearly you communicate your instructions. The more detailed your guidance, the more valuable the support will be.

If you’re interested in learning more, check out my Beginner’s Guide to Using Cursor! Use the code CURSOR50 for a 50% discount! — Explore it here

Must Know 5 Vim Tricks (with GIF) for Kubernetes Certification

Puru — Tue, 10 Sep 2024 07:42:13 +0000

Today, we’re diving into the world of Vim, and trust me, if you’re gearing up for Kubernetes certifications, these tricks are going to be your best friends.

As we all know, Kubernetes exams (CKA, CKS, and more) are tough and demands strong hands-on command-line skills, and mastering Vim can significantly enhance your efficiency during the exam and level 🆙 your game!

In this post, we’ll reveal five practical Vim tricks that will improve your editing and boost your efficiency, making your exam experience smoother and more effective.

📢 Special Annoucement!

My book Certified Kubernetes Security Specialist (CKS) Handbook, is now available for pre-order with 50% early bird discount! — Use discount code EARLYBIRD during checkout: 👉 Checkout here.

Let’s jump in and sharpen those Vim skills with these essential tricks!

1 - Display Line Number and Use Goto Line

It's crucial to easily navigate and jump to specific lines in YAML manifests as you work on tasks. Here's how to show line numbers and use goto to quickly jump into specific line.

In Normal Mode: Type :set nu to display line numbers.
Jump to Specific Line: Type :10 to jump directly to line 10.

2 - Smart Indent

When copying and customizing YAML manifests from documentation, proper indentation is crucial for valid YAML syntax. Follow these steps to easily manage indentation in Vim:

Enter Visual Mode: Press Shift + v to select the current line of text. Use the ↑ ↓ arrow or j k keys (recommended) to extend the selection.
Indent Right: Press > to indent the selected text to the right. Press . to repeat the indentation if needed.
Indent Left: To indent text to the left, repeat steps 1 and 2, but use < instead of >.
Highlight Previous Selection: Use gv to reselect the previously highlighted text.

3 - Effective Cut, copy, paste and undo lines

Quickly rearrange, duplicate, or correct mistakes in your YAML manifests. Here's how you to effectively cut, copy a line and paste it above or below another line and to undo previous action.

Copy a Line: Press yy to copy the current line.
Paste Above: Use Shift + p to paste the cut line above the current line.
Paste Below: Use p to paste the cut line below the current line.
Undo Action: Press u to undo the previous action.

4 - Visual block mode to insert text in multiple lines

Visual Block Mode is awesome because it lets you quickly select and edit text across multiple lines simultaneously, making tasks like formatting and adding consistent changes across your YAML files effortless.

Enter Visual Block Mode: Press Ctrl + v to start visual block selection. Use the ↑ ↓ arrows or j k keys to extend the selection.
Insert Text: Press Shift-i to start inserting text.
Apply Changes: Press Esc to apply the changes to all selected lines.

5 - Run shell command directly within Vim

Did you know you can run shell commands directly from within Vim? Well, now you do 😉

In Normal Mode: Press :! followed by command to run, e.g: :!k get pods

Summary

And that's a wrap! 🎉 - I hope you're feeling more confident and energized to practice these tricks for your upcoming exams.

👋 If you found this post helpful and want more tips and tricks, don't forget to follow me on Twitter and connect with me on LinkedIn

How a 2% Failure Turned into a Success: My CKS Exam Experience

Puru — Tue, 10 Sep 2024 05:07:37 +0000

👋 Introduction

Exams are tough, and failing by a narrow margin can be disheartening. Recently, I faced this challenge myself while attempting the Certified Kubernetes Security Specialist (CKS) exam. I missed passing by just 2%, and it was a learning experience that helped me refine my approach.

I dedicated months to preparation with full-time job as Kubernetes Solution Architect, but there were a few key areas where I stumbled. From managing time efficiently to handling complex scenarios, every detail mattered.

After reviewing my approach and addressing the gaps, I re-took the exam and passed it with flying colors!

Here's what I learned and how it led to creating a resource that could help others avoid the same pitfalls.

🔑 Key Lessons Learned

Effective Study Techniques: I discovered that some common study methods weren't enough. Incorporating hands-on practice and real-world scenarios made a significant difference.
Mastering Exam Strategies: Understanding how to quickly navigate the terminal, use shell commands efficiently, and apply exam-specific shortcuts can give you the edge you need.
Utilizing Resources: Leveraging tools and documentation effectively was crucial. It's not just about knowing the material but knowing how to find and use information quickly under exam conditions.

📚 Introducing My Handbook

In response to my experience, I've put together the Certified Kubernetes Security Specialist (CKS) Handbook.

This book is designed to help you prepare more effectively and avoid the pitfalls I encountered. It's packed with practical advice, study tips, and strategies tailored for the CKS exam.

Pre-order my book now with 50% early bird discount. The book is 40% complete, and I'm excited to share it with you!

Use code "EARLYBIRD" for get a 50% early bird discount - https://ptuladhar.gumroad.com/l/cks-handbook

📝 Summary

Failing by 2% was a tough lesson, but it drove me to create something that could make a real difference in your preparation. I hope this book helps you succeed where I nearly fell short.

Happy studying and best of luck on your journey to becoming a Certified Kubernetes Security Specialist!

🤝 Connect with me on LinkedIn Twitter GitHub

Kubernetes: Evenly Distribution of Pods Across Cluster Nodes

Puru — Wed, 29 Dec 2021 14:04:52 +0000

Introduction

Managing Pods distribution across a cluster is hard. Pod affinity and anti-affinity feature of Kubernetes allows some control of Pod placement. However, these features only resolve part of Pods distribution use cases.

There is a common need to distribute the Pods evenly across the cluster for high availability and efficient cluster resource utilization.

As such, PodTopologySpread scheduling plugin was designed to fill that gap. The plugin has reached a stable state since Kubernetes v1.19.

In this article, I’ll show you an example of using the topology spread constraints feature of Kubernetes to distribute the Pods workload across the cluster nodes in an absolute even manner.

Part 1. Spin Multi-node Kubernetes Cluster

If you already have a Kubernetes cluster with three or more worker nodes, you can skip this cluster setup part.

I’ll be using an awesome tool called kind to spin up a local Kubernetes cluster using Docker containers as “nodes”.

By default, when creating a multi-node cluster via kind, it doesn’t assign a unique hostname for each worker nodes (very unkind 😄)

Firstly, create a directory called hostnames containing a file for each worker with a unique hostname.

$ mkdir hostnames
$ echo 'worker-1' > hostnames/worker-1
$ echo 'worker-2' > hostnames/worker-2
$ echo 'worker-3' > hostnames/worker-3

Now, save the kind cluster config shown below which creates a K8s cluster consisting of 1 control panel (master) and 3 workers. The config also has mounts defined per worker to set the unique hostname.

$ cat > unkind-config.yaml <<EOF
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
  - role: control-plane
  - role: worker
    extraMounts:
    - hostPath: hostnames/worker-1
      containerPath: /etc/hostname
  - role: worker
    extraMounts:
    - hostPath: hostnames/worker-2
      containerPath: /etc/hostname
  - role: worker
    extraMounts:
    - hostPath: hostnames/worker-3
      containerPath: /etc/hostname
EOF

Finally, spin up the Kubernetes cluster as such:

$ kind create cluster --config unkind-config.yaml

The output should be similar to shown below:

Creating cluster "kind" ...
 ✓ Ensuring node image (kindest/node:v1.21.1) 🖼
 ✓ Preparing nodes 📦 📦 📦 📦
 ✓ Writing configuration 📜
 ✓ Starting control-plane 🕹️
 ✓ Installing CNI 🔌
 ✓ Installing StorageClass 💾
 ✓ Joining worker nodes 🚜
Set kubectl context to "kind-kind"
You can now use your cluster with:
kubectl cluster-info --context kind-kind
Thanks for using kind! 😊

Now, verify the cluster is up and running:

$ kubectl get nodes

The output should be similar to shown below:

NAME                 STATUS   ROLES                  AGE     VERSION
kind-control-plane   Ready    control-plane,master   3m29s   v1.21.1
worker-1             Ready    <none>                 2m58s   v1.21.1
worker-2             Ready    <none>                 2m58s   v1.21.1
worker-3             Ready    <none>                 2m58s   v1.21.1

We’re now ready to play around with the cluster!

Part 2. Distribute Pods Evenly Across The Cluster

The topology spread constraints rely on node labels to identify the topology domain(s) that each worker Node is in.

In order to distribute pods evenly across all cluster worker nodes in an absolute even manner, we can use the well-known node label called kubernetes.io/hostname as a topology domain, which ensures each worker node is in its own topology domain.

In the below manifest, we have defined a deployment with 3 replicas that assigned a label type=dummy to the Pod and a topologySpreadConstaints that acts on pods that have that label defined.

And spec.topologySpreadConstaints is defined as:

maxSkew: 1 — distribute pods in an absolute even manner
topologyKey: kubernetes.io/hostname — use the hostname as topology domain
whenUnsatisfiable: ScheduleAnyway — always schedule pods even if it can’t satisfy even distribution of pods
labelSelector — only act on Pods that match this selector

Finally, the Pods runs a container image called pause that does absolutely nothing! 😃

apiVersion: v1
kind: Namespace
metadata:
  name: dummy
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: dummy
  namespace: dummy
spec:
  replicas: 3
  selector:
    matchLabels:
      type: dummy
  template:
    metadata:
      labels:
        type: dummy
    spec:
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: kubernetes.io/hostname
          whenUnsatisfiable: ScheduleAnyway
          labelSelector:
            matchLabels:
              type: dummy    
      containers:
      - name: pause
        image: k8s.gcr.io/pause:3.1

Now, let’s apply the manifest:

$ kubectl apply -f dummy-deployment.yaml
namespace/dummy created
deployment.apps/dummy created

And verify that the pod's placement is balanced across all worker nodes:

$ kubectl -n dummy get pods -o wode --sort-by=.spec.nodeName

As we can see from the above screenshot, pods are scheduled evenly on worker-1, worker-2, and worker-3 respectively.

We can further upscale the deployment to 30 replicas, and validate the distribution of pods as we scale.

$ kubectl -n dummy scale deploy/dummy --replicas 30

As you can see in the screenshot below, the pods are evenly distributed across all cluster nodes after we upscaled the deployment. #awesomeness

Conclusion

PodTopologySpread scheduling plugin gives power to Kubernetes administrators to achieve high availability of applications as well as efficient utilization of cluster resources.

Known Limitations:

Scaling down a Deployment will not guarantee and may result in imbalanced Pods distribution. You can use Descheduler to rebalance the Pods distribution.

References:

Testing SSL/TLS handshake latency using ssl-handshake

Puru — Wed, 29 Dec 2021 13:53:26 +0000

A command-line tool for testing SSL/TLS handshake latency, written in Go.

Features

TCP handshake latency
SSL/TLS handshake latency
TLS version used during the handshake
Display handshake statistics
Configurable endpoint port, handshake interval, timeout and count

What is an SSL/TLS Handshake?

An SSL/TLS handshake is the process that kicks off a communication session between client and server that uses TLS encryption. During a TLS handshake, the two communicating sides exchange messages to acknowledge each other, verify each other, establish the encryption algorithms they will use, and agree on session keys. TLS handshakes are a foundational part of how HTTPS works and it is defined in RFC 8446 (for TLS 1.3) or in RFC 5246 (for TLS 1.2).

TLS handshakes occur after a TCP connection has been opened via a TCP handshake.

TLS handshake packets captured with Wireshark.

Docker Image

Docker image is publicly available at DockerHub:

https://hub.docker.com/r/ptuladhar/ssl-handshake

Run ssl-handshake as Docker container:

docker run --rm ptuladhar/ssl-handshake -c 5 tuladhar.github.io:443

You can also alias ssl-handshake, for ease of use:

alias ssl-handshake="docker run --rm ptuladhar/ssl-handshake"
ssl-handshake tuladhar.github.com:443

Install binary

Binary is available for Linux, Windows and Mac OS (amd64 and arm64). Download the binary for your respective platform from the releases page.

Linux:

curl -sSLO https://github.com/tuladhar/ssl-handshake/releases/download/v1.6.0/ssl-handshake-v1.6.0-linux-amd64.tar.gz

tar zxf ssl-handshake-v1.6.0-linux-amd64.tar.gz

sudo install -m 0755 ssl-handshake /usr/local/bin/ssl-handshake

macOS (Intel):

curl -sSLO https://github.com/tuladhar/ssl-handshake/releases/download/v1.6.0/ssl-handshake-v1.6.0-darwin-amd64.tar.gz

tar zxf ssl-handshake-v1.6.0-darwin-amd64.tar.gz

sudo install -m 0755 ssl-handshake /usr/local/bin/ssl-handshake

macOS (Apple Silicon):

curl -sSLO https://github.com/tuladhar/ssl-handshake/releases/download/v1.6.0/ssl-handshake-v1.6.0-darwin-arm64.tar.gz

tar zxf ssl-handshake-v1.6.0-darwin-arm64.tar.gz

sudo install -m 0755 ssl-handshake /usr/local/bin/ssl-handshake

Windows:

curl -sSLO https://github.com/tuladhar/ssl-handshake/releases/download/v1.6.0/ssl-handshake-v1.6.0-windows-amd64.zip

unzip ssl-handshake-v1.6.0-windows-amd64.zip

Development

If you wish to contribute or compile from source code, you'll first need Go installed on your machine. Go version 1.17+ is required. Currently, there are no dependencies on third-party modules.

git clone https://github.com/tuladhar/ssl-handshake
cd ssl-handshake 
go build

Contributors

Puru Tuladhar