Forem: Abhishek Laha

Google I/O 2025: New Tools, APIs and Everything Devs Need to Know

Abhishek Laha — Thu, 22 May 2025 05:47:45 +0000

Google I/O was a landmark event for developers, with the company doubling down on its vision on AI-first software development. This year's announcements were lazer-focussed on empowering builders with new AI models, APIs and tools especially through Gemini platform. Here's a deep dive into the developer-centric innovations unveiled at unveiled at Google I/O 2025.

Gemini 2.5: Smarter, Faster, and More Controllable

The centerpiece of Google’s developer story is the Gemini 2.5 family of AI models. Gemini 2.5 Pro, now featuring the advanced "Deep Think" mode, enables the model to consider multiple hypotheses before responding. It dramatically boosted its performance on complex coding and math tasks. This upgrade positions Gemini at the top of industry benchmarks, with significant improvements in reasoning and accuracy.

Gemini 2.5 Flash, the more efficient sibling, has also been enhanced for better reasoning, multimodality, coding, and long-context capabilities. It delivers near-Pro performance while using 20–30% fewer tokens, making it ideal for cost-sensitive applications.

Developers now have more transparency and control over how Gemini models operate. Features like "thought summaries" help explain model decisions, and the upcoming "thinking budgets" will allow fine-tuning of cost and response quality.

Gemini API and Google AI Studio: Rapid Prototyping and Agentic Apps

Google AI Studio, now integrated with Gemini 2.5 Pro, is the fastest environment for evaluating models and building with the Gemini API. The platform’s native code editor and GenAI SDK let developers instantly generate web apps from text, images, or video prompts. Starter apps and templates help jumpstart projects, while new generative media models like Imagen and Veo expand creative possibilities.

A major leap is the ability to build "agentic" experiences. With Gemini’s advanced reasoning, developers can create agents that understand context, perform tasks, and even browse the web using the new Computer Use API. The experimental URL Context feature lets Gemini pull full-page context from URLs, making it far easier to build assistants and research tools.

Gemini SDKs are also adopting the Model Context Protocol (MCP), simplifying integration with open-source tools and expanding the ecosystem for agentic applications.

Jules Coding Agent: Automating Codebase Tasks

Jules, Google’s new asynchronous coding agent, is now in public beta. Designed to work directly with GitHub repositories, Jules can automate tasks such as version upgrades, writing tests, updating features, and fixing bugs. It operates autonomously on a cloud VM, makes coordinated codebase edits, runs tests, and allows developers to review and merge changes via pull requests. This tool aims to dramatically speed up development cycles and reduce manual coding overhead.

Stitch UI Designer: AI-Powered UI Generation

Stitch is an experimental tool that leverages Gemini 2.5 Pro to generate user interface designs and frontend code from natural language or image prompts. Developers and designers can describe their desired application, specify layout or color preferences, and Stitch will produce visual designs and exportable code. It also supports iterative design, allowing multiple variants and seamless export to tools like Figma for further refinement

ML Kit GenAI APIs: On-Device AI for Android

Google introduced new ML Kit GenAI APIs powered by Gemini Nano, enabling developers to add intelligent, personalized features to Android apps that run directly on-device. A showcase app, Androidify, demonstrates how users can create personalized Android robots from selfies, illustrating the creative potential of these new APIs.

Building Across Platforms: Android, Web, and XR

While AI took center stage, Google reinforced its commitment to cross-platform development:

Android: The new Material Three Expressive design system (announced pre-I/O) and deep Gemini integration in Android Studio streamline app creation and testing.

Web: Chrome 135 introduces new CSS primitives for interactive UI elements, while the Interest Invoker API enables advanced UI without JavaScript.

XR and Spatial Computing: Google previewed advancements in Android XR, supporting immersive experiences and spatial devices, and teased new smart glasses and 3D video calling via Project Astra and Google Beam.

Summary Table: Key Developer-Focused Features

Here's a summary for all the above unveiled features and releases.

Feature/Tool	Description
Gemini 2.5 Pro & Flash	Advanced AI models with improved reasoning, multimodality, audio-visual input/output
Gemini API & SDK	Rapid prototyping, URL Context, MCP support, GenAI SDK for app generation
Jules Coding Agent	Asynchronous coding agent for automating codebase tasks via GitHub
Stitch UI Designer	AI-powered UI design and code generation tool
Gemini in Android Studio	AI coding companion, Journeys for testing, Version Upgrade Agent
ML Kit GenAI APIs	On-device AI APIs for Android apps
Chrome/Web APIs	New CSS primitives for carousels, Interest Invoker API for advanced UI
Android XR & Beam	Tools and APIs for spatial computing, 3D video calls, and XR device support

The Future: Open, Powerful, and Accessible AI

Google’s I/O 2025 developer announcements mark a shift toward open, accessible, and highly capable AI for everyone building the next generation of apps. With Gemini 2.5’s reasoning power, multimodal capabilities, and new APIs, developers can now create smarter, more adaptive, and more human-like software than ever before.

“We believe developers are the architects of the future. That’s why Google I/O is our most anticipated event of the year, and a perfect moment to bring developers together and share our efforts for all the amazing builders out there.”
— Google AI Team

From agentic assistants to creative media apps and immersive XR experiences, Google has put the tools of tomorrow’s software in developers’ hands today.

What do you think about the announcements made by Google at Google I/O 2025? Let me know in the comments. Thanks for visiting and stay tuned for the next one. Until then, keep learning and stay secure!

Kubernetes Ingress Essentials: Setup, Routing, Annotations and Best Practices

Abhishek Laha — Thu, 01 May 2025 18:42:05 +0000

As you start exposing your services in Kubernetes beyond the cluster, Ingress becomes a powerful resource to manage external access. In this article, we’ll break down the Ingress Controller, how it works, how to set it up, and what to avoid while working with it.

What is an Ingress Controller?

In Kubernetes, Services expose your application internally (ClusterIP) or externally (NodePort/LoadBalancer). But when you need a smarter routing mechanism (like routing based on host or path), that’s where Ingress and Ingress Controllers come in.

An Ingress is a Kubernetes object that defines how traffic should be routed to your services. However, it does nothing on its own — it needs an Ingress Controller to fulfill the routing rules defined in the Ingress resource.

Note:
Think of it like this:

Ingress resource = Routing rules

Ingress Controller = The engine that applies those rules using a reverse proxy (like NGINX, Traefik, HAProxy, etc.)

Key Components You Should Know

Here are some core terms to get comfortable with:

Ingress Resource: Declares HTTP/S routing rules (host/path based).
Ingress Controller: The actual implementation that listens to the Ingress resources and configures a reverse proxy accordingly.
Backend Service: The Kubernetes Service that receives the traffic routed by the Ingress Controller.
Annotations: Often used to enable advanced features like rewrites, SSL redirects, and timeouts.

Setting Up an Ingress Controller (NGINX Example)

Let’s walk through a simple example using the popular NGINX Ingress Controller.

Step 1: Install the Ingress Controller

For Minikube:

minikube addons enable ingress

For general Kubernetes (using Helm):

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update
helm install ingress-nginx ingress-nginx/ingress-nginx

Step 2: Deploy Your Services

Assume you have two deployments app1 and app2 each exposed via a ClusterIP service.

kubectl create deploy app1 --image=nginx
kubectl expose deploy app1 --port=80 --target-port=80

kubectl create deploy app2 --image=httpd
kubectl expose deploy app2 --port=80 --target-port=80

Step 3: Create an Ingress Resource

Here’s how you can define routing rules for both apps:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: demo-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  # Add your domain here if present
  # - host: myapps.local 
  - http:
      paths:
      - path: /app1
        pathType: Prefix
        backend:
          service:
            name: app1
            port:
              number: 80
      - path: /app2
        pathType: Prefix
        backend:
          service:
            name: app2
            port:
              number: 80

Apply it:

kubectl apply -f ingress.yaml

Useful Annotations and Advanced Configuration

Once your Ingress is working, annotations can help you unlock more powerful features of the Ingress Controller. Below are some practical and commonly used annotations for the NGINX Ingress Controller:

Rewrite Target

Useful when your backend app doesn't know it's running behind a path prefix.

metadata:
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /

Note: If you forget to rewrite the target or misconfigure the path, you’ll often see 404 errors from your backend.

Force SSL Redirect

Redirect all HTTP traffic to HTTPS.

metadata:
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true"

Note:
Be careful when testing locally or using self-signed certs — this can cause redirect loops or unexpected failures if TLS isn’t set up correctly.

Custom Timeout Settings Control how long the ingress waits before timing out.

metadata:
  annotations:
    nginx.ingress.kubernetes.io/proxy-connect-timeout: "5"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "10"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "10"

Tip: Make sure these timeouts are also reflected in your backend if you want consistent behavior

Enable CORS (Cross-Origin Resource Sharing) If your frontend and backend are on different domains/subpaths:

metadata:
  annotations:
    nginx.ingress.kubernetes.io/enable-cors: "true"
    nginx.ingress.kubernetes.io/cors-allow-origin: "*"

Note: Using "*" in production is discouraged for security. Instead, specify allowed origins precisely.

Basic Authentication Add HTTP basic auth to your exposed service.

metadata:
  annotations:
    nginx.ingress.kubernetes.io/auth-type: "basic"
    nginx.ingress.kubernetes.io/auth-secret: "basic-auth"
    nginx.ingress.kubernetes.io/auth-realm: "Authentication Required"

Note: Don’t forget to create the basic-auth secret using htpasswd. Without it, requests will fail with a 503.

Ingress Configuration Best Practices

Use Path-Based Routing Thoughtfully
- Group related paths under a common prefix (/api, /admin, etc.) for easier rewrites.
- Always define pathType as Prefix or Exact explicitly to avoid unintended matches.
Use Path-Based Routing Thoughtfully
- Group related paths under a common prefix (/api, /admin, etc.) for easier rewrites.
- Always define pathType as Prefix or Exact explicitly to avoid unintended matches.
Avoid Wildcard CORS in Production
- Instead of cors-allow-origin: "*", define specific trusted domains.
- This improves security, especially if APIs return sensitive data.
Use Proper Timeout Settings
- Avoid overly high timeouts, which can tie up Ingress resources.
- Set appropriate proxy timeouts for each app depending on expected response times.
- Example: nginx.ingress.kubernetes.io/proxy-read-timeout: "10"
Limit Exposure Using Authentication
- Protect internal services or admin panels using basic auth or JWT-based auth (with external plugins).
- Never expose sensitive apps directly without some form of access control.
Use Unique Ingress Names and Hosts
- Avoid conflicting hostnames across multiple Ingress resources.
- Prefer centralized or consolidated Ingress configs per domain where possible.
Test with a Local DNS Entry
- Use /etc/hosts to map custom domains (like myapp.local) for local testing.
- Always verify behavior in dev/stage environments before deploying to production.
Watch Resource Limits
- Ingress controllers run as pods — make sure they have CPU/memory limits.
- Monitor their performance, especially under load or when you have many rules.
Use Readiness Probes for Backend Services
- If a backend service isn't ready, the Ingress will return 502.
- Ensure your Deployments include health checks so services register properly with the Ingress.
Enable Rate Limiting for Public Endpoints
- Helps prevent abuse and accidental DoS from misbehaving clients.
- Use annotations like:

nginx.ingress.kubernetes.io/limit-connections: "1"
nginx.ingress.kubernetes.io/limit-rpm: "60"

Putting It All Together: Full Ingress Example with Advanced Annotations

Here’s a complete example of an Ingress resource that includes the most useful annotations we’ve discussed. This Ingress:

Routes traffic to two apps (app1 and app2) based on path.
Rewrites paths to match backend expectations.
Forces SSL redirection.
Enables CORS.
Sets custom timeouts.
Adds basic authentication.
Uses HTTPS

# Create a TLS Secret
kubectl create secret tls myapps-tls-secret \
  --cert=path/to/tls.crt \
  --key=path/to/tls.key \
  -n your-namespace

Replace path/to/tls.crt and tls.key with your actual certificate files

# Apply ingress config
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: advanced-demo-ingress
  namespace: your-namespace
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/enable-cors: "true"
    nginx.ingress.kubernetes.io/cors-allow-origin: "*"
    nginx.ingress.kubernetes.io/proxy-connect-timeout: "5"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "10"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "10"
    nginx.ingress.kubernetes.io/auth-type: "basic"
    nginx.ingress.kubernetes.io/auth-secret: "basic-auth"
    nginx.ingress.kubernetes.io/auth-realm: "Authentication Required"
spec:
  tls:
  - hosts:
      - myapps.local
    secretName: myapps-tls-secret
  rules:
  - host: myapps.local
    http:
      paths:
      - path: /app1
        pathType: Prefix
        backend:
          service:
            name: app1
            port:
              number: 80
      - path: /app2
        pathType: Prefix
        backend:
          service:
            name: app2
            port:
              number: 80

Tip:
Don’t forget to:

Update your /etc/hosts to map myapps.local to your cluster IP.

Create the basic-auth secret using htpasswd.

Ensure TLS is properly configured if using HTTPS in your cluster.

Wrapping Up

Ingress Controllers are essential for managing external traffic to Kubernetes applications. While the basic setup is straightforward, leveraging advanced annotations gives you fine-grained control over routing, security, and performance.

By understanding and applying these configurations:

You gain flexibility in how apps are exposed.
You improve security through TLS and authentication.
You avoid common pitfalls by configuring timeouts, rewrites, and headers properly.

Next up: In the upcoming article, we’ll explore how to handle configurations with ConfigMaps, and persistent storage in Kubernetes

Stay Tuned for the next one. Until then, keep learning and stay secure! 🚀

Understanding Pods, Deployments, and Services in Kubernetes

Abhishek Laha — Thu, 24 Apr 2025 06:23:01 +0000

Kubernetes can feel like a complex ecosystem, but once you understand its building blocks, everything starts to make sense. In this article, we’ll explore the three most fundamental components in Kubernetes: Pods, Deployments, and Services.

By the end, you’ll have a solid understanding of how your applications are deployed, managed, and exposed in a Kubernetes cluster.

What is a Pod?

A Pod is the smallest and most basic deployable unit in Kubernetes. A Pod represents a single instance of a running process in your cluster.

Key Characteristics:

A Pod can contain one or more containers (usually one).
Containers in a Pod share:
- The same network namespace (same IP address and port space).
- The same storage volumes, if defined.

Think of a Pod as a wrapper around one or more tightly coupled containers that must run together.

Why Pods?

Pods are useful for:

Running a containerized app.
Grouping helper containers (like logging agents) with the main container.

Examples -

Simple Pod:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx-container
    image: nginx:latest
    ports:
    - containerPort: 80

Pod with Volumes, Multiple Containers including init containers and environment variables:

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app.kubernetes.io/name: MyApp
spec:
  containers:
    - name: myapp-container
      image: busybox:1.28
      command: ['sh', '-c', 'echo The app is running! && sleep 3600']
      env:
        - name: ENVIRONMENT
          value: "production"
        - name: CONFIG_FILE
          value: "/etc/config/app.conf"
      volumeMounts:
        - name: config-vol
          mountPath: /etc/config
  initContainers:
    - name: init-myservice
      image: busybox:1.28
      command: ['sh', '-c', "until nslookup myservice.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for myservice; sleep 2; done"]
    - name: init-mydb
      image: busybox:1.28
      command: ['sh', '-c', "until nslookup mydb.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for mydb; sleep 2; done"]
  volumes:
    - name: config-vol
      configMap:
        name: log-config
        items:
          - key: log_level
            path: log_level.conf

Manifest breakup for better understanding

Here are breakdowns for the components used in the above manifest:

Environment Variables

   env:
     - name: DEMO_GREETING
       value: "Hello from the environment"
     - name: DEMO_FAREWELL
       value: "Such a sweet sorrow"

Volumes

Volumes are defined in the volumes section of the manifest. They can be used/mounted by one or more containers in the Pod.

    volumeMounts:
      - name: config-vol
        mountPath: /etc/config
  volumes:
    - name: config-vol
      configMap:
        name: log-config
        items:
          - key: log_level
            path: log_level.conf

Init Containers

Init containers are used to perform setup tasks before the main containers in the Pod start.

  initContainers:
    - name: init-myservice
      image: busybox:1.28
      command: ['sh', '-c', "until nslookup myservice.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for myservice; sleep 2; done"]
    - name: init-mydb
      image: busybox:1.28
      command: ['sh', '-c', "until nslookup mydb.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for mydb; sleep 2; done"]

What is a Deployment?

While a Pod is great, it’s not self-healing. If a Pod crashes, it won’t come back automatically. That’s where a Deployment comes in.

A Deployment is a higher-level abstraction that manages Pods and ReplicaSets for you.

Key Benefits:

Ensures desired state is maintained (e.g., always 3 replicas running).
Supports rolling updates and rollbacks.
Automatically replaces failed Pods.

Examples:

Simple Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.25
        ports:
        - containerPort: 80

Note: Most of the fields in the Deployment manifest are the same as in a Pod manifest. The key difference is that in a Deployment, you specify the number of replicas you want to run. It is specified in the replicas field.

Deployment with Volumes, Multiple Containers including init containers and environment variables:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-app
  labels:
    app: demo
spec:
  replicas: 2
  selector:
    matchLabels:
      app: demo
  template:
    metadata:
      labels:
        app: demo
    spec:
      volumes:
        - name: shared-data
          emptyDir: {}
        - name: config-volume
          configMap:
            name: demo-config
      initContainers:
        - name: init-myservice
          image: busybox
          command: ['sh', '-c', 'echo "Initializing..." > /mnt/data/init.log']
          volumeMounts:
            - name: shared-data
              mountPath: /mnt/data
      containers:
        - name: demo-container
          image: nginx:1.25
          ports:
            - containerPort: 80
          env:
            - name: ENVIRONMENT
              value: "production"
            - name: CONFIG_FILE
              value: "/etc/config/app.conf"
          volumeMounts:
            - name: shared-data
              mountPath: /usr/share/nginx/html/init
            - name: config-volume
              mountPath: /etc/config
              readOnly: true
---
#configmap-manifest
apiVersion: v1
kind: ConfigMap
metadata:
  name: demo-config
data:
  app.conf: |
    server {
      listen 80;
      location / {
        return 200 "Hello from ConfigMap!";
      }
    }

Some more manifest breakups for better understanding

Shared Volumes

Same volumes can be shared by multiple containers in a Pod. This is useful for sharing data between containers in the same Pod.
      volumes:
        - name: shared-data
          emptyDir: {}
      initContainers:
        - volumeMounts:
            - name: shared-data
              mountPath: /mnt/data
      containers:
        - volumeMounts:
            - name: shared-data
              mountPath: /usr/share/nginx/html/init
Configmap as volumes

ConfigMaps can be used in two primary ways:

As environment variables

As volumes (mounted files inside your container) In this example, we've mounted it as a volume - for configmap manifest, refer to the #configmap-manifest section in the above manifest.
      volumes:
        - name: config-volume
          configMap:
            name: demo-config
      containers:
        - volumeMounts:
            - name: config-volume
              mountPath: /etc/config
              readOnly: true
Once deployed, inside the container you’ll have:
/etc/config/app.conf
This config file is then used by the container to configure the application using environment variable.
      containers:
        - env:
            - name: CONFIG_FILE
              value: "/etc/config/app.conf"
Note: Mounting ConfigMap as a volume makes the config read-only by default, which is a nice security feature.

What is a Service?

A Service in Kubernetes exposes your Pods to other applications inside (or outside) the cluster.

Types of Services:

ClusterIP (default): Internal communication only.
NodePort: Exposes the service on a port on each node.
LoadBalancer: Exposes the service externally using a cloud provider's load balancer.
ExternalName: Maps the service to an external DNS name.

Example (NodePort):

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  type: NodePort
  selector:
    app: nginx
  ports:
  - port: 80
    targetPort: 80
    nodePort: 30007

This will expose your nginx deployment on http://:30007.

Putting it All Together: A Practical Example

Here’s an example to deploy Nginx and expose it via a NodePort service.

🧩 Create the Deployment

kubectl create deploy nginx --image=nginx

🧪 Check the Pods

kubectl get pods

🌐 Create the Service

kubectl expose deploy nginx --name=nginx-service --port=30007 --target-port=80 --type=NodePort

🌍 Access the App

minikube service nginx-service

Or manually:

minikube ip

Visit http://minikube-ip:nodePort in your browser.

Note:

You can use kubectl apply -f --dry-run=client -o <file> to validate manifests before applying.
You can use kubectl <remaining-command> --dry-run=client -o yaml to generate a manifest.

Final Thoughts

Pods, Deployments, and Services form the core trio of any Kubernetes application.

Pods are your running containers.

Deployments manage your Pods at scale and keep them healthy.

Services make sure your application is reachable—internally or externally.

Understanding these three concepts is crucial for progressing in your Kubernetes journey. Once you’ve mastered them, you’ll be ready to move on to more advanced topics like ConfigMaps, Secrets, Ingress, Volumes, and beyond.

Next up: In the upcoming article, we’ll explore Ingress controllers, how to handle configurations with ConfigMaps, and persistent storage in Kubernetes.

Do let me know in the comments if you wish to see a difference in the content style and type.

Until then, keep learning and stay secure!

Getting Started with Kubernetes

Abhishek Laha — Sat, 19 Apr 2025 13:01:52 +0000

Kubernetes (often referred to as K8s) has become a staple go-to option for container orchestration. It helps you automate the deployment, scaling, and management of containerized applications.

In this article, we’ll walk through:

What is Kubernetes
Introduction to kubectl
Local Kubernetes installation options
Setting up Kubernetes using Minikube (cross-platform)

1. What is Kubernetes?

Kubernetes is an open-source platform designed to automate deploying, scaling, and operating containerized applications. Originally developed by Google, it's now maintained by the Cloud Native Computing Foundation (CNCF).

With Kubernetes, you can:

Deploy applications consistently
Manage clusters of containers
Ensure high availability and scalability
Perform rolling updates and rollbacks

2. Introduction to kubectl

kubectl is the Kubernetes command-line tool. It's used to communicate with the Kubernetes API server, allowing you to interact with and manage your Kubernetes clusters. Think of it as the main way you'll deploy applications, inspect cluster resources, and manage the system.

Head over to the official Kubernetes documentation for a comprehensive guide on installing and using kubectl.

3. Local Kubernetes Installation Options

To run Kubernetes locally for learning or testing, you can use any of the following tools:

Minikube – Lightweight VM-based or container-based local cluster
Kind – Runs Kubernetes in Docker containers
k3s – Lightweight Kubernetes distribution
Docker Desktop – Includes built-in Kubernetes support (macOS/Windows)
MicroK8s – Minimal, lightweight Kubernetes from Canonical (Ubuntu)

We’ll focus on Minikube in this guide.

4. Setting Up Kubernetes with Minikube

Minikube sets up a single-node Kubernetes cluster by default on your local machine. It’s beginner-friendly and supports all major OS platforms. It is also capable of running multinde clusters.

Step 1: Install Minikube

➤ Windows:

Download the Minikube installer from the official website and run it.
Alternatively, you can use the Chocolatey package manager:

choco install minikube

If you're using Winget, you can use the following command:

winget install minikube

➤ macOS:

Install using Binary:

curl -LO https://github.com/kubernetes/minikube/releases/latest/download/minikube-darwin-amd64
sudo install minikube-darwin-amd64 /usr/local/bin/minikube

Install using Homebrew package manager:

brew install minikube

➤ Linux: Install Minikube using the package manager for your Linux distribution.

Install Using Binary:

curl -LO https://github.com/kubernetes/minikube/releases/latest/download/minikube-linux-amd64
sudo install minikube-linux-amd64 /usr/local/bin/minikube && rm minikube-linux-amd64

Installation for Debian-based systems (Debian, Ubuntu, etc.):

curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube_latest_amd64.deb
sudo dpkg -i minikube_latest_amd64.deb

Installation for Red Hat-based systems (RHEL, CentOS, Fedora, etc.):

curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-latest.x86_64.rpm
sudo rpm -Uvh minikube-latest.x86_64.rpm

Step 2: Start Minikube

Prerequisite: You need a container or VM driver installed (like Docker, VirtualBox, or Hyper-V).

minikube start

You can also specify the driver:

minikube start --driver=docker

Step 3: Verify the Cluster

kubectl get nodes

You should see one node in the "Ready" state.

That’s it!

You’ve successfully installed Kubernetes locally using Minikube.

Conclusion

Getting started with Kubernetes may seem daunting at first, but with tools like Minikube and kubectl, it's easier than ever to set up a local cluster and begin exploring. Whether you're a developer looking to test your containerized apps, or a DevOps engineer diving into orchestration, Kubernetes offers a powerful platform to scale and manage your workloads efficiently.

Now that you’ve set up your local environment, you’re ready to dive into the world of Kubernetes.

In future posts, we’ll dive into deploying applications, creating services, and understanding core components like Pods, Deployments, and Services.

Thanks for visiting and stay tuned for the next one. Until then, keep learning and stay secure!

Docker vs Podman 2025: The Evolution of Container Orchestration

Abhishek Laha — Tue, 15 Apr 2025 17:38:29 +0000

Since its beginning, container orchestration has come a long way. Organizing containerized workloads in the fast-paced development environment of today requires striking a balance between security, flexibility, and performance in addition to automation. In this article, we'll be comparing the newest features of Docker and Podman and look at how they have adjusted to the shifting DevOps landscape in 2025 as we delve into the ongoing development of container orchestration tools.

What is Container Orchestration?

Container orchestration is the process of automating the deployment, management, scaling, and networking of containers throughout their lifecycle, making it possible to deploy software consistently across many different environments at scale.

Containers, which package an application and its runtime environment together in a self-contained unit, are foundational to cloud native application development. Container orchestration is especially important for enterprises that need to deploy and manage hundreds or thousands of containers and hosts. Most container orchestration solutions are built on Kubernetes, a widely adopted open source platform. Source

The Docker Legacy: Then and Now

Docker needs no introduction — it's been the go-to container engine for developers worldwide for a long time. Even in 2025, Docker remains popular thanks to:

Integrated Tools: Docker continues to support a comprehensive suite of tools for building, testing, and running containers. Though Docker Swarm once provided native clustering capabilities, many developers have now transitioned to Kubernetes for large-scale orchestration.
Evolving Security: With the ever-increasing focus on cybersecurity, Docker has enhanced its rootless container options. This evolution minimizes risk by reducing the need for privileged operations.
Cross-Platform Adaptability: Docker’s mature ecosystem guarantees consistency whether you’re developing on Linux, Windows, or macOS. Recent improvements further streamline cross-platform deployments, making Docker a reliable choice for hybrid cloud environments.

Enter Podman: The Daemon-less Contender

Podman has steadily gained traction among developers who value its innovative approach to container management. In 2025, Podman continues to impress with several key features:

Daemon-less Architecture: Unlike Docker, which relies on a long-running daemon, Podman creates containers as child processes of the invoking user. This design inherently reduces security risks by limiting unnecessary privileges.
Modular Toolchain: In its ecosystem, Podman is complemented by specialized utilities such as Buildah for building images, Skopeo for image inspection, and crun for runtime flexibility. This modularity gives developers the freedom to swap or upgrade components without overhauling the entire workflow.
Seamless Integration: Podman’s compatibility with Docker’s CLI interface means that teams can transition smoothly or even use both tools simultaneously. This is particularly useful in environments where specific needs — like rootless operation or enhanced systemd integration are paramount.
Cloud-Native Ready: With the rapid adoption of microservices, Podman’s support for Kubernetes-like pods has allowed for more granular application management. This makes it easier to group related containers and manage them as a cohesive unit.

Key Differences Revisited

As we assess Docker and Podman in 2025, several differences stand out:

Architecture

Docker: Employs a client-server model with a central daemon responsible for container lifecycle management.
Podman: Operates daemon-less, leveraging Unix processes which translate to improved security and easier process-level management.

Privilege Management

Docker: Continues to offer rootless modes, but historically has required elevated privileges for its daemon-based operations.
Podman: Has built its identity around non-root operations, making it inherently safer when running multi-tenant or production workloads.

Security Considerations

Docker: Ongoing enhancements in its security model include sandboxing and better integration with modern security tools.
Podman: Its design reduces the attack surface by eliminating the need for a persistent daemon, a feature that remains a significant advantage in environments where security is a top concern.

Integration with System Management

Docker: Often relies on external solutions like Kubernetes or Docker Compose for service orchestration.
Podman: Leverages systemd natively — allowing containers to be managed as system services. This results in smoother deployments and easier handling of service restarts or dependencies.

Building and Modularity

Docker: Offers an all-in-one toolchain that simplifies container creation and management.
Podman: The separation of tasks (building with Buildah, inspecting with Skopeo, etc.) provides flexibility. Developers who prefer specialized tools for each step often find this approach beneficial, especially when fine-tuning performance and security.

Podman and Docker: Coexistence in a Modern Ecosystem

Despite their differences, Podman and Docker are not mutually exclusive. Many organizations can operate hybrid environments where:

Development uses Docker for its familiar interface and straightforward workflows.
Production leverages Podman’s robust security and integration with modern service managers like systemd.

This cooperative usage demonstrates that the choice between Docker and Podman need not be binary. Instead, it can be about selecting the right tool for the task at hand and, in some cases, integrating both to capitalize on their unique strengths.

Looking Ahead: The Future of Container Orchestration

As we progress through 2025, the demands on container orchestration continue to evolve. Both Docker and Podman are adapting to meet the challenges posed by increasingly sophisticated cloud-native environments. Key trends we anticipate include:

Enhanced Security Protocols: Continuous advancements in rootless architectures and secure defaults will drive improvements in container security.
Greater Modularity and Interoperability: The future of container tooling lies in blending specialized utilities with robust orchestration frameworks. This modular approach promises easier updates and better performance tuning.
Integration with Serverless Architectures: As serverless solutions rise in popularity, both Docker and Podman will likely evolve to interface seamlessly with these systems, bridging the gap between containers and ephemeral compute resources.

Final Thoughts

Both Docker and Podman have carved their niches in the container orchestration landscape. Docker’s widespread adoption and user-friendly tooling are complemented by Podman’s focus on security, daemon-less operation, and modularity. In 2025, the key is to understand your project’s unique needs — whether you prefer an all-in-one solution or a combination that leverages the strengths of both tools.

Thanks for reading, and stay tuned as we continue to explore the evolving world of container technology. Until next time, keep learning and stay secure!

Getting Started with DevOps

Abhishek Laha — Tue, 15 Apr 2025 10:41:20 +0000

Hi, there. If you are reading this article, this means you are keen to get started with DevOps. Without wasting time, lets get into the specifics.

What is DevOps?

DevOps, as a term, comes from the smashing together of ‘Development and Operations’ to create a more-or-less self-explanatory term. It is a strategy that bridges the gap between software development and IT operations.

What is the role of a DevOps engineer?

The role of a DevOps engineer may vary from one organization to another, but generally, it is some combination of release engineering, infrastructure provisioning and management, system administration, infrastructure optimization and security.

What are the tools used by DevOps engineers?

Regardless of the type of DevOps toolchain an organization uses, a DevOps process needs to use the right tools to address the key phases and requirements of the DevOps lifecycle:

Planning :
- Jira (Popular),
- Redmine,
- Trac,
- Rally,
- etc
CI/CD :
- Jenkins (Popular),
- Github Actions (Popular)
- CircleCI (Popular),
- TeamCity,
- Azure DevOps,
- etc.
Build Tools :
- Maven (Popular),
- Gradle (Popular),
- Ant,
- GNU Make (Popular), etc.
Containerization :
- Docker,
- Kubernetes,
- Rancher,
- OpenShift,
- AKS,
- EKS,
- GKE,
- etc.
Configuration Management :
- Ansible,
- Puppet,
- Chef,
- SaltStack,
- Terraform,
- CloudFormation,
- Azure Resource Manager,
- etc.
Source Code Management :
- Git,
- GitHub,
- GitLab,
- BitBucket,
- Azure DevOps,
- AWS CodeCommit,
- Google Cloud Source Repositories,
- etc.
Cloud :
- Azure,
- AWS,
- GCP,
- Digital Ocean,
Monitoring :
- Prometheus (Infrastructure),
- Grafana Loki (Logs),
- Splunk,
- ELK stack,
- Datadog,
- NewRelic,
- etc.
Communication :
- Slack,
- Microsoft Teams,
- Zoom,
- Google Meet,
- etc.

What are the prerequisites for a DevOps engineer?

You must have got to know by now, the tools should you explore and this will give you a headstart.

Now, let’s have a look at some of the pre-requisites to be a good DevOps engineer:

Understanding Containers: Containers virtualize the operating system and not the hardware so that the virtualized environments are lightweight and highly scalable. For more visit here.
Understanding DevOps tools and technologies: It is important to understand the tools and technologies generally used in the industry to understand and formulate better strategies and work on efficient solutions.
Understanding Scripting languages: It is a must to have good experience in common scripting languages like Bash, Batch and Python. Most of the DevOps tools require some level of scripting to automate things to the highest standard. For example, Ansible uses a YAML scripting language for automation, which is primarily based on Python.
Collaboration and Communication Skills: A DevOps engineer is known to form the bridge between development teams and IT operations, making communication and collaboration skills the DevOps prerequisites. Communication skills help to avoid misinterpretations enabling a high-performance environment for teams to function.
Knowledge of Networking fundamentals: Networking helps to integrate the edge services that are deployed on different containers or virtual machines. Networking also helps in troubleshooting various latency and performance issues.
Overall Computer Science Knowledge: DevOps engineers are going to interact with software development teams, testing teams, and the IT operations team regularly. As such, a DevOps engineer must have at least the basic knowledge of almost all the concepts in computer science, including algorithms, networking, cloud, data science, etc.
Logical Attitude: DevOps engineers will sometimes have to make spontaneous decisions for smooth functioning in the team. Since DevOps engineers are known to fill the gap between developers and IT operations, communication and collaboration become key. DevOps engineers thus have to carry a sound rationale and logical attitude throughout.
Passion: A DevOps engineer is expected to be passionate about the work he is doing. Doing work with passion is the ultimate key to success in any career path. It is one of the crucial DevOps prerequisites that should never be overlooked.

Conclusion

DevOps has taken center stage in the software development field, and it is evolving every day. This blog post is too small, and I can write about DevOps so much because there are so many innovations happening around this field. Companies are experimenting with various ways to accelerate their DevOps process so they can win over the competition.

So many developers, test engineers, and people from other industries want to learn DevOps because of the importance it has received over recent years. Well, DevOps is a great career; you have made a good choice of choosing it as your career path, and I hope that this article has the fundamentals you require to start your DevOps Journey.

Thanks for visiting and stay tuned for the next one. Until then, keep learning and stay safe.