But ConfigMaps should only store:

✅ non-sensitive data

such as:

• application modes

• URLs

• ports

• feature flags

What about sensitive information like:

• database passwords

• API keys

• authentication tokens

• secret credentials

Storing them inside ConfigMaps is NOT safe ❌

Kubernetes solves this problem using: Secrets 🔐

🧠 What is a Kubernetes Secret?

A Secret is a Kubernetes object used to store: Sensitive information securely

It helps manage:

• passwords

• tokens

• credentials

• private keys

• secret configuration data

without hardcoding them directly inside applications.

🌍 Real World Example

Imagine your application needs:

DATABASE_PASSWORD=mysecretpassword

Hardcoding this inside:

• application code

• Docker images

• YAML files

creates security risks 🚨

Instead, Kubernetes Secrets store this information separately.

⚠️ Why Hardcoding Passwords Is Dangerous

Suppose passwords are directly written inside:

• GitHub repositories

• container images

• YAML manifests

This can lead to:

• credential leaks

• security breaches

• unauthorized access

Secrets help reduce this risk.

🌱 What Secrets Commonly Store

Kubernetes Secrets can store:

• database passwords

• API tokens

• SSH keys

• TLS certificates

• cloud credentials

Anything sensitive should usually go into a Secret 🔐

⚙️ Simple Secret Example

apiVersion: v1
kind: Secret

metadata:
  name: app-secret

type: Opaque

data:
  username: YWRtaW4=
  password: cGFzc3dvcmQxMjM=

🧠 Why Does the Data Look Strange?

The values are encoded using:

Base64 Encoding

Example:

admin

becomes:

YWRtaW4=

And:

password123

becomes:

cGFzc3dvcmQxMjM=

⚠️ Important Beginner Note

Base64 is:

❌ NOT encryption

It is only:

• encoding

Anyone can decode Base64 easily.

Secrets mainly help:

• organize sensitive data

• avoid exposing credentials directly in YAML or code

For stronger security, production environments often use:

• encryption at rest

• external secret managers

• cloud security services

🚀 Create the Secret

Save the file as:

secret.yaml

Apply it using:

kubectl apply -f secret.yaml

🔍 Verify the Secret

Run:

kubectl get secrets

You should see:

app-secret

🌱 How Applications Use Secrets

Applications can access Secrets using:

• environment variables

• mounted files

• volumes

Just like ConfigMaps,
Secrets are injected into Pods dynamically 🌱

🛣️ Simple Flow

Secret 🔐
↓
Deployment 🌱
↓
Pod 📦
↓
Application 🚀

The application securely reads sensitive data.

🧠 ConfigMap vs Secret

ConfigMap

Used for:

• non-sensitive configuration

Examples:

• URLs

• ports

• application settings

Secret

Used for:

• sensitive data

Examples:

• passwords

• API keys

• tokens

🧠 Simple Analogy

Think of ConfigMaps like sticky notes 📝

They store normal information everyone can see.

Secrets are more like a locked locker 🔒

Only authorized applications should access them.

🏢 Why Companies Use Secrets

Secrets help production systems:

• reduce credential exposure

• separate sensitive data

• improve security practices

• manage credentials centrally

They are extremely important in modern Kubernetes environments 🚀

🎯 Key Takeaway

Kubernetes Secrets store sensitive information like:

• passwords

• API keys

• credentials

• tokens

They help avoid hardcoding sensitive data directly inside applications or YAML files 🔐

ConfigMaps store normal configuration 🛠️
Secrets store sensitive data 🔒

✨ Thanks for reading!

I publish posts on DevOps regularly. So, make sure you subscribe to get the latest updates straight to your inbox.

Subscribe now

If you enjoy my content and find it valuable, you can support me with a coffee. Every contribution, big or small, helps me keep creating more free content for you.

💛You can support me here: Buy Me a Coffee

• run inside Pods

• communicate using Services

• receive external traffic using Ingress

But applications also need configuration.

For example:

• database URLs

• application modes

• API endpoints

• feature flags

• environment variables

A common beginner mistake is:

❌ hardcoding these values directly inside application code or container images.

This creates maintenance problems very quickly.

Kubernetes solves this using: ConfigMaps 🌱

🧠 What is a ConfigMap?

A ConfigMap is a Kubernetes object used to store: Non-sensitive configuration data

It helps separate:

• application code
  from

• application configuration

This makes applications easier to manage and update 🚀

🌍 Real World Example

Imagine an application using:

DATABASE_URL=prod-db.company.com

Instead of hardcoding this inside the application,
you can store it inside a ConfigMap.

The application reads the configuration dynamically 🌱

⚠️ Why Hardcoding Is Bad

Suppose you move your application from:

• development
  to

• production

The database URL may change.

If values are hardcoded:

• application images must be rebuilt

• deployments become harder

• environments become difficult to manage

ConfigMaps solve this problem cleanly.

🌱 What Can ConfigMaps Store?

ConfigMaps commonly store:

• environment variables

• application settings

• URLs

• ports

• configuration files

• feature flags

But:

❌ passwords
❌ API secrets
❌ sensitive credentials

should NOT be stored in ConfigMaps.

Those belong in: Kubernetes Secrets 🔐which we will learn in the next article.

⚙️ Simple ConfigMap Example

apiVersion: v1
kind: ConfigMap

metadata:
  name: app-config

data:
  APP_MODE: production
  APP_COLOR: blue

🧠 Understanding the YAML

kind: ConfigMap

Creates a ConfigMap object.

data

Stores key-value configuration pairs.

Example:

APP_MODE=production

🚀 Create the ConfigMap

Save the file as:

configmap.yaml

Apply it using:

kubectl apply -f configmap.yaml

🔍 Verify the ConfigMap

Run:

kubectl get configmaps

You should see:

app-config

🌱 How Applications Use ConfigMaps

Applications can read ConfigMaps in multiple ways:

• environment variables

• mounted files

• command arguments

Most beginners first learn:

• environment variable usage

because it is simpler 🌱

🛣️ Simple Flow

ConfigMap 🛠️
↓
Deployment 🌱
↓
Pod 📦
↓
Application 🚀

The application receives configuration dynamically.

🧠 Simple Analogy

Think of ConfigMaps like a settings file ⚙️

Your application is like a mobile app.

The settings:

• theme

• language

• server URL

can change without reinstalling the app.

Similarly:

ConfigMaps allow configuration changes without modifying application code.

🏢 Why Companies Use ConfigMaps

ConfigMaps help production environments:

• separate configuration cleanly

• manage multiple environments

• simplify deployments

• reduce hardcoding

• improve maintainability

They are heavily used in real Kubernetes environments 🚀

⚠️ Important Beginner Note

ConfigMaps are NOT secure storage.

Anyone with access to the cluster may read them.

Sensitive data should always use: Kubernetes Secrets 🔐

instead.

🎯 Key Takeaway

ConfigMaps store non-sensitive configuration data in Kubernetes.

They help:

• avoid hardcoding

• separate configuration from code

• simplify environment management

Applications can dynamically read configuration using ConfigMaps 🌱

✨ Thanks for reading!

I publish posts on DevOps regularly. So, make sure you subscribe to get the latest updates straight to your inbox.

Subscribe now

If you enjoy my content and find it valuable, you can support me with a coffee. Every contribution, big or small, helps me keep creating more free content for you.

💛You can support me here: Buy Me a Coffee

• Ingress

• Ingress Controllers

• routing rules

• HTTPS

• annotations

• Gateway API

At this point, many beginners get confused between:

Ingress

and

API Gateway 🌐

They may sound similar,
but they solve different problems.

Let’s understand the difference in a simple beginner-friendly way 🌱

🧠 What Kubernetes Ingress Mainly Does

Ingress is mainly used for: Traffic Routing 🚦

It helps:

• expose applications

• route external traffic

• manage paths and hosts

• handle HTTPS traffic

Example:

• /api

• /admin

• shop.myapp.com

Ingress decides:

where traffic should go.

🌐 What an API Gateway Does

An API Gateway does much more than routing.

It focuses on: API Management 🚀

API Gateways provide advanced features like:

• authentication

• authorization

• rate limiting

• API monitoring

• request transformation

• caching

• analytics

It not only routes traffic,
but also controls and secures APIs.

🌱 Simple Beginner Comparison

Ingress

Mainly focuses on:

• routing traffic

• exposing applications

• managing external access

Think of it as:

a traffic controller 🚦

API Gateway

Focuses on:

• API security

• API policies

• authentication

• advanced traffic management

Think of it as:

a smart security and management layer 🌐

🏢 Real World Example

Imagine a company running many backend APIs.

The company may want to:

• authenticate users 🔐

• block excessive requests 🚧

• track API usage 📊

• apply security policies 🛡️

Ingress alone may not handle all these requirements easily.

An API Gateway becomes useful for these advanced API management needs.

🌍 Example Scenario

Suppose users access:

api.myapp.com

With Ingress

Ingress mainly:

• routes traffic to the correct Service

With API Gateway

The Gateway may additionally:

• verify authentication tokens

• apply rate limiting

• monitor API usage

• log requests

• enforce security rules

before forwarding traffic to backend Services.

⚠️ Is Gateway API the Same as API Gateway?

No ❌

This is a very common beginner confusion.

Gateway API 🌉

Gateway API is:

a Kubernetes networking standard/API.

It is part of Kubernetes traffic management.

It is considered a modern evolution of Ingress.

API Gateway 🌐

API Gateway is:

a product or service used for API management.

Examples:

• Kong

• AWS API Gateway

• Apigee

• Traefik

It focuses on:

• security

• authentication

• API policies

🧠 Simple Analogy

Think of Ingress like a building receptionist 🏢

The receptionist:

• directs visitors to the correct room

Now think of an API Gateway like airport security ✈️

It:

• verifies identity

• checks permissions

• monitors activity

• applies security rules

That is the major difference.

🌱 Do Companies Use Both?

YES. Very often 🚀

Many modern architectures use:

• Ingress or Gateway API
  for:

• Kubernetes traffic routing

AND

• API Gateway
  for:

• API management and security

They can work together.

🎯 Key Takeaway

Ingress mainly focuses on:

• routing external traffic

• exposing Kubernetes applications

API Gateway focuses on:

• securing APIs

• managing API traffic

• authentication

• monitoring

• advanced API policies

Ingress manages traffic routing 🚦
API Gateway manages APIs intelligently 🌐

✨ Thanks for reading!

I publish posts on DevOps regularly. So, make sure you subscribe to get the latest updates straight to your inbox.

Subscribe now

If you enjoy my content and find it valuable, you can support me with a coffee. Every contribution, big or small, helps me keep creating more free content for you.

💛You can support me here: Buy Me a Coffee

• Ingress

• Ingress Controllers

• Ingress YAML

• Path Based Routing

Ingress is still one of the most commonly used ways to manage external traffic in Kubernetes.

But as Kubernetes environments became larger and more complex, the community introduced something newer called:

Gateway API 🌱

Let’s understand what it is in a simple beginner-friendly way.

🧠 Why Kubernetes Introduced Gateway API

Traditional Ingress works well for many applications.

But over time, companies needed more advanced traffic management features.

Some limitations of traditional Ingress were:

• limited flexibility

• controller-specific behavior

• complex annotations

• difficulty managing advanced routing

Different Ingress Controllers sometimes behaved differently, which made configurations harder to standardize.

To improve this, Kubernetes introduced:

Gateway API 🌉

🌐 What is Gateway API?

Gateway API is a newer Kubernetes networking standard used to manage traffic routing.

It is designed to be:

• more flexible

• more powerful

• easier to extend

• better for large production environments

You can think of it as:

a more advanced evolution of Ingress.

⚠️ Problems with Traditional Ingress

Ingress is simple and beginner friendly.

But for large systems, teams often needed:

• advanced routing

• better traffic control

• role separation

• reusable configurations

• multi-team traffic management

Many advanced features required:

• custom annotations

• controller-specific settings

This sometimes made configurations difficult to manage.

🌱 Simple Beginner Comparison

Think of it like this:

Ingress

Simple traffic management 🚦

Good for:

• beginners

• small to medium applications

• straightforward routing

Gateway API

Advanced traffic management 🌉

Better for:

• large production systems

• platform engineering

• advanced networking setups

🛣️ Gateway vs Ingress

Ingress mainly focuses on:

• HTTP/HTTPS routing

• simple path-based routing

• basic external traffic management

Gateway API introduces more structured traffic handling with better separation of responsibilities.

It provides:

• Gateways

• Routes

• more granular control

But don’t worry about these details deeply right now 🌱

As a beginner, understanding the idea is enough.

🌍 Is Ingress Still Used?

YES. Absolutely 🚀

Ingress is still:

• widely used

• beginner friendly

• production ready

• very common in Kubernetes environments

Many companies continue using:

• NGINX Ingress Controller

• Traefik

• cloud-native ingress solutions

Learning Ingress is still extremely valuable.

🧠 Should Beginners Learn Gateway API Immediately?

Not necessarily.

For beginners:

✅ Learn Services first
✅ Learn Ingress properly
✅ Understand traffic flow
✅ Practice routing concepts

Then later:

• explore Gateway API gradually

Ingress builds the foundation 🌱

🏢 Real World Situation

Today, many Kubernetes environments still use:

• Ingress

• Ingress Controllers

• LoadBalancers

Some modern platforms are gradually adopting Gateway API for more advanced networking needs.

Both concepts are important in the Kubernetes ecosystem.

🧠 Simple Analogy

Think of Ingress like a regular road system 🚗

It works well for normal city traffic.

Gateway API is more like a modern smart highway system 🌉

It provides:

• better traffic organization

• advanced control

• scalable traffic management

Both help vehicles reach destinations,
but one is designed for larger and more complex environments.

🎯 Key Takeaway

Gateway API is a newer and more advanced Kubernetes networking model.

It was introduced to solve some limitations of traditional Ingress and provide better traffic management capabilities.

However:

Ingress is still widely used and remains one of the best ways for beginners to learn Kubernetes traffic routing 🌱

✨ Thanks for reading!

I publish posts on DevOps regularly. So, make sure you subscribe to get the latest updates straight to your inbox.

Subscribe now

If you enjoy my content and find it valuable, you can support me with a coffee. Every contribution, big or small, helps me keep creating more free content for you.

💛You can support me here: Buy Me a Coffee

But there is one important problem:

⚠️ Traffic is still not secure by default.

If users send sensitive information like:

• passwords

• payment details

• personal data

that traffic should be encrypted.

This is where:

TLS/HTTPS in Ingress 🌐becomes important.

🧠 What is HTTPS?

HTTPS is the secure version of HTTP.

It encrypts communication between:

• users

• browsers

• applications

This prevents attackers from reading sensitive data during transmission 🔒

🌱 What is TLS?

TLS stands for:

Transport Layer Security

TLS is the technology that provides encryption for HTTPS.

You can think of it like this:

• HTTP → normal communication

• HTTPS → encrypted communication using TLS

⚠️ Why HTTPS Matters

Without HTTPS:

❌ traffic is not encrypted
❌ passwords can be exposed
❌ sensitive information becomes vulnerable

With HTTPS:

✅ communication is encrypted
✅ data becomes secure
✅ browsers trust the application

That is why most modern websites use HTTPS 🌍

🌐 How TLS Works in Kubernetes Ingress

Ingress Controllers can handle HTTPS traffic.

The Ingress Controller:

• receives encrypted traffic

• uses TLS certificates

• decrypts requests

• forwards traffic to Services

This allows applications to be accessed securely.

🧾 What is a TLS Certificate?

A TLS certificate is used to enable HTTPS.

It helps:

• encrypt traffic

• verify the website identity

• establish secure communication

Ingress uses these certificates for HTTPS connections.

🌱 TLS Secret in Kubernetes

TLS certificates are usually stored in Kubernetes as:

Secrets

A Secret securely stores:

• certificate files

• private keys

Ingress references the Secret to enable HTTPS.

⚙️ Example TLS Ingress YAML

apiVersion: networking.k8s.io/v1
kind: Ingress

metadata:
  name: secure-ingress

spec:
  ingressClassName: nginx

  tls:
  - hosts:
    - myapp.com

    secretName: my-tls-secret

  rules:
  - host: myapp.com

    http:
      paths:
      - path: /
        pathType: Prefix

        backend:
          service:
            name: nginx-clusterip
            port:
              number: 80

🧠 Understanding Important Fields

tls

Enables HTTPS configuration.

hosts

myapp.com

Defines the domain using HTTPS.

secretName

my-tls-secret

References the Kubernetes Secret containing TLS certificates.

🛣️ Simple HTTPS Flow

User Browser 🌍
↓
HTTPS Request 🔒
↓
Ingress Controller 🚦
↓
TLS Certificate Validation 📜
↓
Service 🌱
↓
Pods 📦

The Ingress Controller handles encryption and secure communication.

🧠 Simple Analogy

Think of HTTPS like a locked package 📦🔒

Even if someone intercepts it during delivery,
they cannot read the contents without the key.

TLS provides that protection for internet traffic.

⚠️ Important Beginner Note

In real production environments, TLS certificates are often managed using tools like:

• cert-manager

• Let’s Encrypt

But as a beginner, focus first on understanding:

• why HTTPS matters

• how TLS works with Ingress

• where certificates are used

That foundation is the most important part 🌱

🎯 Key Takeaway

TLS enables secure HTTPS communication in Kubernetes Ingress.

Ingress Controllers use:

• TLS certificates

• Kubernetes Secrets

to encrypt and secure external traffic 🔒

HTTPS is essential for modern production applications and is widely used across Kubernetes environments 🌍

✨ Thanks for reading!

I publish posts on DevOps regularly. So, make sure you subscribe to get the latest updates straight to your inbox.

Subscribe now

If you enjoy my content and find it valuable, you can support me with a coffee. Every contribution, big or small, helps me keep creating more free content for you.

💛You can support me here: Buy Me a Coffee

• paths

• hosts

• annotations

• rewrite rules

But what happens if a request does not match any Ingress rule?

Example:

• wrong URL

• unknown path

• invalid domain

Where does the traffic go? 🤔

This is where the:

Default Backend becomes important.

🧠 What is a Default Backend?

A Default Backend is the fallback destination for unmatched traffic in Kubernetes Ingress.

If no rule matches the incoming request,
traffic is forwarded to the Default Backend.

Think of it like:

a backup route for unknown requests 🚀

🌍 Real World Example

Suppose your Ingress only handles:

• /api

• /admin

But a user accidentally visits:

/randompage

Ingress cannot find a matching rule.

Instead of failing silently, traffic is sent to the: Default Backend 🚧

⚠️ Why Default Backend Is Important

Without a Default Backend:

• users may see confusing errors

• unmatched traffic becomes harder to manage

• debugging becomes difficult

The Default Backend provides a cleaner fallback behavior.

🌱 Common Uses of Default Backend

Default Backends are often used to:

• show custom 404 pages

• display error messages

• return fallback responses

• handle invalid requests safely

Very useful in production environments 🌍

⚙️ Simple Example

Suppose your Ingress contains rules for:

• api.myapp.com

• /admin

Any unmatched request automatically goes to the Default Backend Service.

Example:

unknown.myapp.com

or

/invalid-path

can be handled safely.

🌱 Example Ingress YAML

apiVersion: networking.k8s.io/v1
kind: Ingress

metadata:
  name: my-ingress

spec:
  ingressClassName: nginx

  defaultBackend:
    service:
      name: default-service
      port:
        number: 80

  rules:
  - host: myapp.com

    http:
      paths:
      - path: /api
        pathType: Prefix

        backend:
          service:
            name: api-service
            port:
              number: 80

🔍 Understanding the Flow

User Request 🌍
↓
Ingress Controller 🚦
↓
Checks Ingress Rules 📄
↓
No Match Found ❌
↓
Default Backend 🌱
↓
Fallback Response 📦

🧠 Simple Analogy

Think of a customer support desk ☎️

Normally:

• customers are directed to the correct department

But if nobody knows where the request belongs,
the call goes to:

the general help desk.

The Default Backend works similarly in Kubernetes Ingress 🚧

⚠️ Important Beginner Note

Many Ingress Controllers already include a built-in default backend automatically.

For beginners, the important thing is understanding:

• unmatched traffic exists

• fallback handling is needed

• Default Backend provides that fallback

That foundation is enough 🌱

🏢 Why Companies Use Default Backends

Default Backends help production systems:

• handle invalid requests cleanly

• improve user experience

• simplify debugging

• provide custom error pages

• avoid confusing failures

Small feature, but very useful in real-world environments 🚀

🎯 Key Takeaway

The Default Backend handles traffic that does not match any Ingress rule.

It acts as:

• a fallback destination

• a safety mechanism

• a cleaner error handling solution

Default Backends help Kubernetes Ingress manage unknown traffic gracefully 🌱

✨ Thanks for reading!

I publish posts on DevOps regularly. So, make sure you subscribe to get the latest updates straight to your inbox.

Subscribe now

If you enjoy my content and find it valuable, you can support me with a coffee. Every contribution, big or small, helps me keep creating more free content for you.

💛You can support me here: Buy Me a Coffee

Ingress Annotations help customize Ingress Controller behavior.

One of the most commonly used annotations is:

Rewrite Target Annotation

This annotation is extremely useful when application paths and Ingress paths do not match correctly.

Let’s understand this in a simple beginner-friendly way 🌱

🧠 What Problem Does Rewrite Target Solve?

Sometimes applications expect traffic on:

/

But Ingress receives traffic on:

/api

Without rewriting the path:

• the application may not understand the request

• pages may fail to load

• APIs may return errors

This is where Rewrite Target helps 🚀

🌍 Real World Example

Imagine:

Users access:

myapp.com/api

But internally, the backend application expects:

/

Ingress can rewrite:

/api

into:

/

before forwarding traffic to the Service.

⚙️ Rewrite Target Annotation

Example:

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

This tells the NGINX Ingress Controller:

modify the incoming request path before forwarding traffic.

🌱 Example Ingress YAML

apiVersion: networking.k8s.io/v1
kind: Ingress

metadata:
  name: rewrite-ingress

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

spec:
  ingressClassName: nginx

  rules:
  - host: myapp.com

    http:
      paths:
      - path: /api
        pathType: Prefix

        backend:
          service:
            name: api-service
            port:
              number: 80

🔍 What Happens Internally?

User visits:

myapp.com/api

Ingress receives:

/api

Rewrite Target changes it to:

/

Traffic is then forwarded to:

api-service

This helps applications work correctly 🌱

🧠 Why Applications Need This

Some applications are built assuming they run from:

/

instead of:

/api

Rewrite rules help adjust traffic paths without modifying the application itself.

This becomes very useful in microservices environments 🚀

🛣️ Simple Traffic Flow

User Request 🌍
↓
Ingress Controller 🚦
↓
Rewrite Path ✍️
↓
Service 🌱
↓
Pods 📦

The controller modifies the request path before forwarding traffic.

⚠️ Important Beginner Note

Rewrite configurations can become more advanced in production environments using:

• regex paths

• capture groups

• dynamic rewrites

But as a beginner, focus mainly on understanding:

✅ why rewriting is needed
✅ how traffic paths change
✅ where annotations are used

That foundation matters most 🌱

🧠 Simple Analogy

Think of a package delivery system 📦

A package arrives with:

• an old room number

The receptionist updates the room number before delivery.

Similarly:

Ingress rewrites the request path before sending traffic to the application.

🎯 Key Takeaway

Rewrite Target Annotation helps modify incoming request paths before traffic reaches Kubernetes Services.

It is commonly used when:

• Ingress paths

• application paths

do not match correctly.

This helps applications work properly without changing the application code 🚀

✨ Thanks for reading!

I publish posts on DevOps regularly. So, make sure you subscribe to get the latest updates straight to your inbox.

Subscribe now

If you enjoy my content and find it valuable, you can support me with a coffee. Every contribution, big or small, helps me keep creating more free content for you.

💛You can support me here: Buy Me a Coffee

• Path Based Routing

• Host Based Routing

• TLS/HTTPS

• Traffic routing using Ingress YAML

But real production environments often need more control over traffic behavior.

For example:

• redirect HTTP to HTTPS

• rewrite URLs

• control request size

• configure timeouts

This is where:

Ingress Annotations become very important.

🧠 What are Ingress Annotations?

Annotations are additional configurations added inside Kubernetes YAML files.

They help customize how the Ingress Controller behaves.

Think of annotations like:

extra instructions for the Ingress Controller 🌱

🌍 Why Annotations Are Used

Ingress rules alone define:

• host names

• paths

• backend Services

But sometimes applications need advanced behavior.

Annotations help configure things like:

• HTTPS redirection

• URL rewriting

• request limits

• timeout settings

• custom traffic behavior

⚙️ Where Annotations Are Added

Annotations are usually added inside:

metadata:

section of the Ingress YAML.

Example:

metadata:
  name: my-ingress

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

🌱 Simple Annotation Example

apiVersion: networking.k8s.io/v1
kind: Ingress

metadata:
  name: my-ingress

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

spec:
  ingressClassName: nginx

This annotation tells the NGINX Ingress Controller:

automatically redirect HTTP traffic to HTTPS 🔒

🧠 Understanding the Annotation

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

Let’s break it down.

nginx.ingress.kubernetes.io

Specifies that the annotation belongs to the NGINX Ingress Controller.

ssl-redirect

Defines the feature or behavior.

Here:

• HTTP traffic automatically redirects to HTTPS.

“true”

Enables the feature.

🚦Commonly Used Ingress Annotations

Some popular annotations include:

• SSL redirection

• URL rewriting

• request body size limits

• timeout configuration

• rate limiting

Different controllers may support different annotations.

⚠️ Important Beginner Understanding

Annotations are often: Controller Specific

This means:

• NGINX annotations may not work with Traefik

• Traefik annotations may differ from AWS ALB annotations

Different Ingress Controllers can have their own annotation styles.

🌱 Why Annotations Became Important

Traditional Ingress resources are intentionally simple.

Annotations helped controllers add advanced features without changing the core Kubernetes Ingress API.

They became a flexible way to customize traffic behavior.

🧠 Simple Analogy

Think of Ingress like ordering food at a restaurant 🍽️

The main order is:

• the dish itself

Annotations are like:

• extra spicy 🌶️

• less sugar 🍬

• extra cheese 🧀

They customize how the final result behaves.

⚠️ One Small Problem with Annotations

As applications became larger, too many annotations sometimes made Ingress YAML difficult to manage.

This is one reason newer solutions like:

Gateway API 🌉

were introduced later.

But annotations are still heavily used in modern Kubernetes environments 🚀

🛣️ What’s Next?

One of the most commonly used annotations is:

Rewrite Target Annotation ✍️

which helps modify request paths before traffic reaches applications.

We will explore that in the next article 🌱

🎯 Key Takeaway

Ingress Annotations are used to customize the behavior of Ingress Controllers.

They provide advanced traffic management features like:

• HTTPS redirection

• URL rewriting

• timeout control

• request limits

Annotations make Kubernetes Ingress much more powerful and flexible 🚀

✨ Thanks for reading!

I publish posts on DevOps regularly. So, make sure you subscribe to get the latest updates straight to your inbox.

Subscribe now

If you enjoy my content and find it valuable, you can support me with a coffee. Every contribution, big or small, helps me keep creating more free content for you.

💛You can support me here: Buy Me a Coffee

Path Based Routing where traffic is routed using paths like:

• /api

• /frontend

• /admin

But in real production environments, companies often use:

• different domains

• different subdomains

• separate applications

instead of only URL paths.

This is where:

Host Based Routing 🌐becomes useful.

🧠 What is Host Based Routing?

Host Based Routing means:

traffic is routed based on the domain name or host.

Instead of checking the path:

/api

Ingress checks the host name:

api.myapp.com

and routes traffic to the correct Service.

🌍 Real World Example

Imagine a company running multiple applications:

• api.myapp.com

• admin.myapp.com

• shop.myapp.com

Each application may use different Kubernetes Services internally.

Ingress can route traffic based on the host name automatically 🚀

🌱 Example Scenario

Suppose your cluster contains:

• API Application → api-service

• Admin Dashboard → admin-service

• Shopping Application → shop-service

Ingress can route traffic like this:

• api.myapp.com → api-service

• admin.myapp.com → admin-service

• shop.myapp.com → shop-service

All traffic can still enter through the same Ingress Controller 🌐

⚙️ Example Ingress YAML

apiVersion: networking.k8s.io/v1
kind: Ingress

metadata:
  name: host-based-ingress

spec:
  ingressClassName: nginx

  rules:

  - host: api.myapp.com

    http:
      paths:
      - path: /
        pathType: Prefix

        backend:
          service:
            name: api-service
            port:
              number: 80

  - host: admin.myapp.com

    http:
      paths:
      - path: /
        pathType: Prefix

        backend:
          service:
            name: admin-service
            port:
              number: 80

This single Ingress resource manages traffic for multiple domains 🌱

🔍 Understanding the Flow

Here’s what happens internally.

User visits:

api.myapp.com

Ingress checks the host:

api.myapp.com

Traffic gets routed to:

api-service

Similarly:

admin.myapp.com

gets routed to:

admin-service

🧠 Path Based Routing vs Host Based Routing

Path Based Routing

Routes traffic using paths.

Examples:

• /api

• /admin

Single domain:

myapp.com

Host Based Routing

Routes traffic using host names.

Examples:

• api.myapp.com

• admin.myapp.com

Multiple domains or subdomains 🌍

🏢 Why Companies Use Host Based Routing

Host Based Routing is very common in production Kubernetes environments because it helps:

• separate applications clearly

• organize large systems

• manage subdomains easily

• simplify traffic management

• scale applications independently

Large companies often run many applications under different subdomains.

🧠 Simple Analogy

Think of an apartment building 🏢

The building has one main entrance.

But different apartment numbers lead visitors to different homes.

Similarly:

Ingress receives traffic at one entry point and forwards requests based on the host name.

⚠️ Important Beginner Note

Locally, custom domains like:

api.myapp.com

will not automatically work unless DNS or hosts file configuration is added.

For beginners, focus mainly on understanding:

• traffic flow

• host matching

• routing concepts

That foundation matters most 🌱

🎯 Key Takeaway

Host Based Routing allows Kubernetes Ingress to route traffic using domain names or subdomains.

Examples:

• api.myapp.com

• admin.myapp.com

Ingress checks the host name and forwards traffic to the correct Kubernetes Service 🌍

✨ Thanks for reading!

I publish posts on DevOps regularly. So, make sure you subscribe to get the latest updates straight to your inbox.

Subscribe now

If you enjoy my content and find it valuable, you can support me with a coffee. Every contribution, big or small, helps me keep creating more free content for you.

💛You can support me here: Buy Me a Coffee

Now let’s explore one of the most powerful features of Ingress:

Path Based Routing 🌐

This is where Kubernetes Ingress starts becoming very useful in real production environments.

🧠 What is Path Based Routing?

Path Based Routing means:

traffic is routed based on the URL path.

Different paths can send traffic to different applications.

Example:

• /frontend

• /api

• /admin

All can work under the same domain.

🌍 Real World Example

Imagine a company application:

• myapp.com/frontend → frontend website

• myapp.com/api → backend API

• myapp.com/admin → admin dashboard

Even though users access one domain:

myapp.com

Ingress routes traffic to different Services internally 🚀

🛣️ Why This Is Powerful

Without Ingress:

• multiple LoadBalancers may be needed

• multiple public IPs may be created

• traffic management becomes messy

With Ingress:

✅ one domain
✅ one entry point
✅ multiple applications

This creates a much cleaner architecture 🌱

🌱 Example Scenario

Suppose your cluster contains:

• Frontend App → frontend-service

• Backend API → api-service

• Admin Dashboard → admin-service

Ingress can route traffic like this:

• /frontend → frontend-service

• /api → api-service

• /admin → admin-service

⚙️ Example Ingress YAML

apiVersion: networking.k8s.io/v1
kind: Ingress

metadata:
  name: app-ingress

spec:
  ingressClassName: nginx

  rules:
  - host: myapp.com

    http:
      paths:

      - path: /frontend
        pathType: Prefix

        backend:
          service:
            name: frontend-service
            port:
              number: 80

      - path: /api
        pathType: Prefix

        backend:
          service:
            name: api-service
            port:
              number: 80

      - path: /admin
        pathType: Prefix

        backend:
          service:
            name: admin-service
            port:
              number: 80

This single Ingress resource manages traffic for multiple applications 🌍

🔍 Understanding the Flow

Here’s what happens internally:

User visits:

myapp.com/api

Ingress Controller checks:

/api

Traffic is forwarded to:

api-service

Similarly:

myapp.com/frontend

goes to:

frontend-service

🧠 Simple Analogy

Think of a shopping mall 🏬

There is one main entrance.

But inside:

• one path leads to food court 🍔

• another leads to clothing store 👕

• another leads to cinema 🎬

Ingress works similarly.

One domain receives traffic, then routes users to the correct application.

🏢 Why Companies Use This

Path Based Routing is extremely common in production environments because it helps:

• reduce infrastructure complexity

• avoid multiple public IPs

• organize microservices cleanly

• simplify traffic management

• reduce cloud costs

Modern applications often contain many Services, and Ingress helps manage them efficiently 🚀

🌱 Cleaner Kubernetes Architecture

Typical architecture becomes:

User 🌍
↓
Ingress Controller 🚦
↓
Ingress Rules 📄
↓
Multiple Services 🌱
↓
Pods 📦

This is much cleaner than exposing every application separately.

🎯 Key Takeaway

Path Based Routing allows multiple applications to work under one domain using different URL paths.

Examples:

• /frontend

• /api

• /admin

Ingress intelligently routes traffic to the correct Kubernetes Service based on the request path 🌐

✨ Thanks for reading!

I publish posts on DevOps regularly. So, make sure you subscribe to get the latest updates straight to your inbox.

Subscribe now

If you enjoy my content and find it valuable, you can support me with a coffee. Every contribution, big or small, helps me keep creating more free content for you.

💛You can support me here: Buy Me a Coffee

Now it’s time to create your first:

Ingress YAML 🚀

This is where traffic routing actually begins.

We will create a simple Ingress resource that routes external traffic to an application inside the cluster.

🧠 What an Ingress YAML Does

Ingress YAML defines routing rules.

It tells Kubernetes:

• which requests should enter

• which Service should receive traffic

• which path should be used

Think of it like a traffic instruction file 📄

🌱 Basic Ingress YAML

Here is a simple example:

apiVersion: networking.k8s.io/v1
kind: Ingress

metadata:
  name: my-ingress

spec:
  ingressClassName: nginx

  rules:
  - host: myapp.com

    http:
      paths:
      - path: /
        pathType: Prefix

        backend:
          service:
            name: nginx-clusterip
            port:
              number: 80

Don’t worry if this looks confusing at first 🌱

Let’s understand it step by step.

🏷️ ingressClassName

ingressClassName: nginx

This tells Kubernetes:

“Use the NGINX Ingress Controller for this Ingress.”

If multiple controllers exist in the cluster, this helps Kubernetes choose the correct one.

Find the ingress file here: Github Repo

🌍 host

host: myapp.com

This defines the domain name.

Requests coming to:

myapp.com

will follow the routing rules inside this Ingress.

🛣️ path

path: /

This defines the URL path.

Example:

• /

• /api

• /admin

Here:

/

means the root path of the application.

🌱 backend Service

backend:
  service:
    name: nginx-clusterip
    port:
      number: 80

This tells Ingress where traffic should go.

Incoming requests are forwarded to:

• Service name:

nginx-clusterip

• Port:

80

The Service then forwards traffic to Pods 📦

Do remember that we had two services that we created for examples earlier: cluster-ip and nodeport. Here I am using the service of Cluster-IP in backend.

🚀 Apply the Ingress YAML

Save the file as:

ingress.yaml

Apply it using:

kubectl apply -f ingress.yaml

Kubernetes will create the Ingress resource.

🔍 Verify the Ingress

Run:

kubectl get ingress

You may see output similar to:

NAME         CLASS   HOSTS       ADDRESS   PORTS
my-ingress   nginx   myapp.com             80

This confirms that the Ingress resource was created successfully 🌱

Make sure that the pods are running.

🛣️ Simple Traffic Flow

Here is the request flow:

User Request 🌍
↓
NGINX Ingress Controller 🚦
↓
Ingress Rules 📄
↓
frontend-service 🌱
↓
Pods 📦

The controller reads the Ingress YAML and routes traffic correctly.

🧠 Simple Analogy

Think of Ingress YAML like a GPS route 🗺️

It contains directions telling traffic where to go.

The Ingress Controller follows those directions and forwards requests to the correct Service.

⚠️ Important Beginner Note

Locally, the domain:

myapp.com

will not automatically work unless DNS or hosts file mapping is configured.

For beginners, focus mainly on understanding:

• routing logic

• traffic flow

• Ingress structure

That foundation is the most important part 🌱

🎯 Key Takeaway

Ingress YAML defines how external traffic should reach applications inside Kubernetes.

Important fields include:

• ingressClassName

• host

• path

• backend Service

The Ingress Controller reads these rules and routes traffic to the correct application 🚀

✨ Thanks for reading!

I publish posts on DevOps regularly. So, make sure you subscribe to get the latest updates straight to your inbox.

Subscribe now

If you enjoy my content and find it valuable, you can support me with a coffee. Every contribution, big or small, helps me keep creating more free content for you.

💛You can support me here: Buy Me a Coffee

• Ingress contains routing rules

• Ingress Controller actually processes traffic

Without an Ingress Controller, Ingress resources do nothing.

Now let’s install one 🚀

We will use:

NGINX Ingress Controller

because it is:

• beginner friendly

• widely used

• easy to practice locally

🧠 Why Controller Installation Is Needed

Kubernetes does not include an Ingress Controller by default.

This means:

• creating an Ingress resource alone is not enough

• traffic routing will not work automatically

We must install a controller that can:

• watch Ingress resources

• receive external traffic

• route requests to the correct Services

⚙️ Installing NGINX Ingress Controller

The installation method depends on your Kubernetes environment.

For beginners, common local environments are:

• Minikube

• Docker Desktop Kubernetes

🚀 Installing on Minikube

Minikube makes installation very simple.

Run this command:

minikube addons enable ingress

This automatically installs:

• NGINX Ingress Controller

• required configurations

• controller Pods

🐳 Installing on Docker Desktop Kubernetes

If you are using Docker Desktop Kubernetes, run:

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/main/deploy/static/provider/cloud/deploy.yaml

This deploys the NGINX Ingress Controller into the cluster.

🔍 Verify the Ingress Controller Pods

After installation, verify that the controller Pods are running.

Run:

kubectl get pods -n ingress-nginx

You should see Pods similar to:

ingress-nginx-controller-xxxxx

Status should become:

Running

🌱 Verify the Namespace

The controller is usually installed inside a namespace called:

ingress-nginx

Check namespaces using:

kubectl get namespaces

You should see:

ingress-nginx

We will learn about namespaces in depth in coming articles :)

🧠 What Gets Created Internally

When the controller is installed, Kubernetes creates several resources automatically.

This may include:

• Pods

• Services

• ConfigMaps

• Roles

• RoleBindings

• Deployments

The main component is the controller Pod that handles incoming traffic.

Don’t worry about understanding every resource right now 🌱

For beginners, the important thing is:

✅ the controller is installed
✅ the Pods are running

🚦Verify the Controller Service

Run:

kubectl get svc -n ingress-nginx

You may see a Service like:

ingress-nginx-controller

This Service exposes the controller internally or externally depending on the environment.

🛣️ What Happens Next?

Now your Kubernetes cluster is capable of:

• reading Ingress rules

• receiving external traffic

• routing requests to Services

In the next article, we will create:

Your First Ingress YAML 🌐

and route traffic to an application using Ingress.

🎯 Key Takeaway

Ingress resources alone are not enough.

An Ingress Controller must be installed to:

• process traffic

• watch Ingress rules

• route requests correctly

NGINX Ingress Controller is one of the most popular choices for learning Kubernetes 🚀

✨ Thanks for reading!

I publish posts on DevOps regularly. So, make sure you subscribe to get the latest updates straight to your inbox.

Subscribe now

If you enjoy my content and find it valuable, you can support me with a coffee. Every contribution, big or small, helps me keep creating more free content for you.

💛You can support me here: Buy Me a Coffee

But there is one important thing many beginners get confused about:

Ingress alone does not handle traffic.

Ingress is only a set of routing rules.

Something must actually:

• receive incoming traffic

• read the rules

• route requests to the correct Service

That component is called an:

Ingress Controller

🧠 Ingress Resource vs Ingress Controller

This is the biggest beginner confusion in Kubernetes.

Let’s simplify it.

Ingress Resource

Ingress is a Kubernetes object that contains routing rules.

Example:

• /api → backend Service

• /frontend → frontend Service

It only defines:

• where traffic should go

• which path maps to which Service

Ingress itself does not process traffic.

Think of it as instructions or configuration 📄

Ingress Controller

The Ingress Controller is the actual software that:

• watches Ingress rules

• receives traffic

• routes requests correctly

Without the controller:
❌ Ingress rules do nothing

⚠️ Why Ingress Alone Does Nothing

Creating an Ingress resource without a controller is like:

writing traffic instructions on paper but having nobody follow them.

Kubernetes stores the rules,
but no component processes them automatically.

The Ingress Controller continuously watches the cluster for Ingress resources and applies the routing rules.

👀 How Ingress Controllers Watch Rules

Ingress Controllers constantly monitor Kubernetes for changes.

When you create or update an Ingress resource:

• the controller detects the change

• updates its routing configuration

• starts routing traffic accordingly

This happens automatically 🚀

🌐 Popular Ingress Controller: NGINX Ingress Controller

One of the most commonly used controllers is:

NGINX Ingress Controller

It uses NGINX internally to manage and route traffic.

It is popular because it is:

• beginner friendly

• widely used

• easy to install

• commonly seen in production environments

Many Kubernetes learners start with NGINX Ingress Controller 🌱

🚦Other Popular Ingress Controllers

There are multiple Ingress Controllers available.

Some popular options are:

Traefik

Known for:

• simplicity

• automatic configuration

• developer friendly setup

HAProxy Ingress

Known for:

• high performance

• efficient traffic handling

AWS Load Balancer Controller

Used mainly in AWS environments.

It integrates Kubernetes with AWS Application Load Balancers.

🛣️ Simple Traffic Flow

Here is the basic request flow:

User Request 🌍
↓
Ingress Controller 🚦
↓
Ingress Rules 📄
↓
Kubernetes Service 🌱
↓
Pods 📦

The controller checks the rules and forwards traffic to the correct application.

🧠 Simple Analogy

Think of Ingress like a Google Maps route 🗺️

But the route alone does not move the car.

The driver actually follows the route and takes you to the destination.

Similarly:

• Ingress = routing instructions

• Ingress Controller = component that follows the instructions

🎯 Key Takeaway

Ingress defines traffic routing rules.

Ingress Controller actually processes and routes the traffic.

Without an Ingress Controller:
❌ Ingress resources do nothing

NGINX Ingress Controller is one of the most popular options for learning and production Kubernetes environments 🚀

✨ Thanks for reading!

I publish posts on DevOps regularly. So, make sure you subscribe to get the latest updates straight to your inbox.

Subscribe now

If you enjoy my content and find it valuable, you can support me with a coffee. Every contribution, big or small, helps me keep creating more free content for you.

💛You can support me here: Buy Me a Coffee

• ClusterIP

• NodePort

• LoadBalancer

Each Service type exposes applications in a different way.

Let’s quickly recap them before learning Ingress 🌱

🧠 Quick Recap of Kubernetes Services

ClusterIP

ClusterIP exposes applications only inside the Kubernetes cluster.

Used for:

• internal communication

• backend services

• database communication

Not accessible from outside the cluster 🔒

NodePort

NodePort exposes applications using a port on the Node.

Used mainly for:

• local testing

• learning Kubernetes

• accessing apps from your machine

Example:

NodeIP:30007

LoadBalancer

LoadBalancer exposes applications publicly using an external IP.

Used in:

• cloud environments

• production applications

• public APIs

Users can access applications through the internet ☁️

⚠️ The Problem with Multiple Load Balancers

LoadBalancer works well for a single application.

But real applications usually contain multiple Services.

For example:

• frontend application

• backend API

• authentication service

• admin dashboard

If every Service uses its own LoadBalancer:

• many external IPs get created

• infrastructure cost increases

• traffic management becomes difficult

• configuration becomes messy

This is where Ingress becomes very useful 🚀

🌐 What is Ingress in Kubernetes?

Ingress is a Kubernetes resource that manages external access to Services inside the cluster.

Instead of exposing every Service separately, Ingress provides:

• one entry point

• one domain

• intelligent traffic routing

Ingress acts like a smart traffic manager.

🎯 Why Ingress Exists

Ingress exists to make application traffic management simpler.

It helps when:

• multiple Services need external access

• one domain should route to many applications

• production traffic needs better organization

• public access must be managed efficiently

Instead of many Load Balancers, one Ingress can handle traffic routing.

🌍 One Domain → Multiple Services

Ingress allows multiple applications to work under the same domain.

Example:

• myapp.com → frontend

• myapp.com/api → backend API

• myapp.com/admin → admin dashboard

This is very common in real production environments.

🛣️ Introduction to Path Based Routing

Ingress supports something called:

Path Based Routing

This means traffic is routed based on the URL path.

Example:

/api → backend Service
/frontend → frontend Service

Ingress checks the request path and forwards traffic to the correct Service automatically.

🧠 Simple Analogy

Think of Ingress like a hotel receptionist 🏨

Visitors enter through one main entrance.

The receptionist checks where they need to go and directs them to the correct room.

Similarly:

Ingress receives incoming traffic and routes it to the correct Kubernetes Service.

⚙️ Important Note

Ingress itself does not directly process traffic.

It needs something called an:

Ingress Controller

The controller actually handles and routes the requests.

We will learn about Ingress Controllers in the next article 🌱

🎯 Key Takeaway

Ingress is used to manage external traffic for multiple Services inside Kubernetes.

It helps:

• reduce multiple Load Balancers

• use one domain

• organize production traffic

• route requests intelligently

LoadBalancer exposes applications publicly ☁️
Ingress manages and routes traffic smartly 🌐

✨ Thanks for reading!

I publish posts on DevOps regularly. So, make sure you subscribe to get the latest updates straight to your inbox.

Subscribe now

If you enjoy my content and find it valuable, you can support me with a coffee. Every contribution, big or small, helps me keep creating more free content for you.

💛You can support me here: Buy Me a Coffee

There is another important Service type called LoadBalancer that is widely used in real production environments.

This Service type is mainly used when your application must be accessible to users over the internet.

Let’s understand what it does and when we use it.

🧠 What LoadBalancer Service Does

A LoadBalancer Service:

• exposes your application publicly

• assigns an external IP address

• routes traffic to Pods

• distributes load across replicas

• uses a cloud provider load balancer

Users connect using a public IP or DNS name 🌍

Traffic is automatically balanced across running Pods.

🎯 Why We Use LoadBalancer Service

We use LoadBalancer when:

• applications must be reachable from the internet

• users are outside the cluster

• traffic volume can grow

• high availability is required

• automatic load distribution is needed

This is common for:

• web applications

• public APIs

• production services

• customer facing platforms

⚖️ Built In Traffic Distribution

LoadBalancer Services spread incoming requests across Pods.

This gives:

• better performance

• higher reliability

• fault tolerance

• smoother scaling

If one Pod fails, traffic goes to others automatically.

🏢 Where LoadBalancer Actually Works

LoadBalancer Service works when your Kubernetes cluster runs on a cloud platform, such as:

• AWS

• Google Cloud

• Azure

• other managed Kubernetes providers

The cloud platform creates the external load balancer for you.

⚠️ Important Note for Local Learners

LoadBalancer Service does not work by default on:

• Docker Desktop Kubernetes

• Minikube

• kind

• other local clusters

There is no real cloud load balancer available locally.

So the external IP will stay in pending state.

For local practice, NodePort is the correct choice.

🧠 Simple Comparison

Think of it like this:

ClusterIP → internal only 🔒
NodePort → local machine access 🚪
LoadBalancer → public internet access ☁️

🎯 Key Takeaway

LoadBalancer Service is used to expose applications publicly in cloud Kubernetes clusters.

It provides external IP
balances traffic
supports production workloads

Use NodePort locally
Use LoadBalancer in cloud environments 🌱

✨ Thanks for reading!

I publish posts on DevOps regularly. So, make sure you subscribe to get the latest updates straight to your inbox.

Subscribe now

If you enjoy my content and find it valuable, you can support me with a coffee. Every contribution, big or small, helps me keep creating more free content for you.

💛You can support me here: Buy Me a Coffee

Now let’s create a NodePort Service to expose your application outside the cluster so you can access it from your browser.

This is commonly used for local learning and testing.

Let’s do it step by step.

🧠 What NodePort Does

A NodePort Service:

• opens a port on the node

• exposes your app externally

• routes traffic to matching Pods

• allows browser access

Think of it as opening a public gate 🚪

📄 Step 1: Create NodePort service YAML

Create file:

service-nodeport.yaml

Add:

apiVersion: v1
kind: Service
metadata:
  name: nginx-nodeport

spec:
  type: NodePort

  selector:
    app: nginx

  ports:
    - port: 80
      targetPort: 80
      nodePort: 30007

▶️ Step 2: Apply the Service

kubectl apply -f service-nodeport.yaml

👀 Step 3: Verify Service

kubectl get services

You will see something like:

nginx-nodeport   NodePort   …   80:30007

30007 is the external port.

🌐 Step 4: Access from Browser

If you are using Docker Desktop Kubernetes:

Open browser and visit:

http://localhost:30007

You should see nginx welcome page 🎉

Traffic path is:

Browser → NodePort → Service → Pods

🔍 Step 5: Inspect Service Routing

kubectl describe service nginx-nodeport

Check:

• selector

• endpoints

• nodePort

• connected Pods

⚠️ Beginner Note

NodePort is great for:

• learning

• demos

• local clusters

In production, teams usually use LoadBalancer or Ingress instead.

You’ll learn those later.

🧹 Clean Up When Done

To delete:

kubectl delete svc nginx-nodeport

kubectl delete -f deployment.yaml

This removes the Service, Deployment and its Pods.

🎯 Key Takeaway

NodePort exposes your app outside the cluster.

ClusterIP = internal only
NodePort = external access
Service routes traffic
Pods handle requests

Next topic, we can cover most used service LoadBalancer🏷️🌱

✨ Thanks for reading!

I publish posts on DevOps regularly. So, make sure you subscribe to get the latest updates straight to your inbox.

Subscribe now

If you enjoy my content and find it valuable, you can support me with a coffee. Every contribution, big or small, helps me keep creating more free content for you.

💛You can support me here: Buy Me a Coffee

Now let’s create your first real Service using the ClusterIP type and test how it works.

ClusterIP is used for internal access only inside the cluster.

Let’s try it hands on.

🧠 What ClusterIP Does

A ClusterIP Service:

• gives a stable internal IP

• routes traffic to matching Pods

• works only inside the cluster

• is not directly accessible from your browser

It is mainly used for:

• internal APIs

• backend services

• service to service communication

Think of it as a private internal door 🚪

✅ Step 1: Make Sure Your Deployment Is Running

We need Pods to route traffic to.

Check:

kubectl apply -f deployment.yaml
kubectl get deployments
kubectl get pods

Make sure your nginx Pods are running.

📄 Step 2: Create ClusterIP service YAML

Create file:

service-clusterip.yaml

Add:

apiVersion: v1
kind: Service
metadata:
  name: nginx-clusterip

spec:
  type: ClusterIP

  selector:
    app: nginx

  ports:
    - port: 80
      targetPort: 80

Please find the YAML file here: Github Repo

The selector connects this Service to Pods with label:

app: nginx

▶️ Step 3: Apply the Service

kubectl apply -f service-clusterip.yaml

Service is now created.

👀 Step 4: Verify Service

kubectl get services
(or)
kubectl get svc

You will see a ClusterIP address assigned.

That IP is internal to the cluster.

🔍 Step 5: See which Pods are connected

kubectl describe service nginx-clusterip
(or)
kubectl describe svc nginx-clusterip

Look for Endpoints section.
Those are the Pod IPs receiving traffic.

🧪 Step 6: Test from Inside the Cluster

Run a temporary test Pod:

kubectl run test-client --image=busybox -it --rm -- sh

Inside the shell run:

wget -qO- nginx-clusterip

You should receive nginx HTML output.

Exit with:

exit

🧹 Clean Up When Done

To delete:

kubectl delete svc nginx-clusterip

kubectl delete -f deployment.yaml

This removes the Service, Deployment and its Pods.

🎯 Key Takeaway

ClusterIP creates an internal stable access point.

Pods can change
Service IP stays
Traffic is routed internally
Used for internal communication

Next, we will expose the same app outside the cluster using NodePort 🌍🚀

✨ Thanks for reading!

I publish posts on DevOps regularly. So, make sure you subscribe to get the latest updates straight to your inbox.

Subscribe now

If you enjoy my content and find it valuable, you can support me with a coffee. Every contribution, big or small, helps me keep creating more free content for you.

💛You can support me here: Buy Me a Coffee

But there is an important problem.

Pods are temporary and replaceable. Their IP addresses can change. Pods can be recreated at any time.

So how do users reliably access your application?

That is solved using a Service.

🧠 Simple Definition

A Service in Kubernetes provides a stable access point to a group of Pods.

It acts like a fixed front door 🚪
Even if Pods behind it change.

Users connect to the Service.
Service forwards traffic to the right Pods.

❓ Why Pods Alone Are Not Enough

Pods are not stable endpoints because:

• Pod IP can change

• Pods can be deleted and recreated

• replicas can increase or decrease

Direct Pod access would break easily.

Services give stability on top of dynamic Pods.

🔁 How Service Works

A Service uses labels to find Pods.

Example idea:

Pods have label:

app: nginx

Service says:

“Send traffic to all Pods with label app = nginx”

Kubernetes keeps this mapping updated automatically.

🧩 Common Service Types (Beginner View)

You only need to know two for now.

🏠 ClusterIP

Default type.

• internal access only

• usable inside cluster

• not exposed to internet

🚪 NodePort

Exposes app outside cluster.

• opens a port on the node

• accessible from browser

• useful for local learning

We will use this in practice.

⚖️ Built In Load Balancing

Services also distribute traffic.

If you have 3 Pods behind a Service:

• requests are spread across them

• load is shared

• reliability improves

No manual load balancer needed for basic cases.

🧠 Simple Analogy

Think of Pods as workers in a shop 🏬
Service is the shop counter.

Customers talk to the counter.
Counter routes to available workers.

Workers can change. Counter stays.

🎯 Key Takeaway

A Service gives stable access to changing Pods.

Pods are dynamic
Service is stable
Traffic is routed automatically
Load is balanced

Next, we’ll do a hands-on practice and create your first Service step by step 🚀🌱

✨ Thanks for reading!

I publish posts on DevOps regularly. So, make sure you subscribe to get the latest updates straight to your inbox.

Subscribe now

If you enjoy my content and find it valuable, you can support me with a coffee. Every contribution, big or small, helps me keep creating more free content for you.

💛You can support me here: Buy Me a Coffee

Now let’s create one step by step.

We will use a simple Deployment that runs an nginx container with multiple replicas.

Keep it simple. Focus on structure, not memorizing fields.

📄 Example Deployment YAML

Create a file named:

deployment.yaml

Add this content:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment

spec:
  replicas: 2

  selector:
    matchLabels:
      app: nginx

  template:
    metadata:
      labels:
        app: nginx

    spec:
      containers:
        - name: nginx
          image: nginx
          ports:
            - containerPort: 80

That’s enough to run your first Deployment.

Find the deployment file here: Github Repo

🧠 How to Read This File

Let’s understand the important parts.

✅ kind: Deployment

We are creating a Deployment resource, not a Pod directly.

✅ replicas

replicas: 2

Kubernetes will keep 2 Pods running at all times.

✅ selector and labels

These connect the Deployment to the Pods it manages.

Think of labels like tags.
Deployment looks for Pods with this tag.

✅ template section

This is the Pod blueprint.

Inside template you define:

• container image

• name

• ports

Deployment uses this template to create Pods.

▶️ Apply the Deployment

Run:

kubectl apply -f deployment.yaml

You should see:

Deployment is now active.

👀 Verify the Deployment

Check Deployments:

kubectl get deployments

You will see:

• deployment name

• desired replicas

• available replicas

📦 Check the Pods Created by Deployment

Run:

kubectl get pods

You should now see 2 Pods running.

Their names will start with:

These Pods were created automatically by the Deployment.

🔍 Inspect the Deployment

For detailed info:

kubectl describe deployment nginx-deployment

This shows:

• replica status

• Pod template

• events

• rollout details

Very helpful when learning behavior.

🧹 Clean Up When Done

To delete:

kubectl delete -f deployment.yaml

This removes the Deployment and its Pods.

🎯 Key Takeaway

A Deployment manages Pods for you using a Pod template.

You define replicas
Deployment creates Pods
Kubernetes keeps them running
Scaling becomes easy

Next, we’ll learn how users actually access these Pods using Services 🌐🌱

✨ Thanks for reading!

I publish posts on DevOps regularly. So, make sure you subscribe to get the latest updates straight to your inbox.

Subscribe now

If you enjoy my content and find it valuable, you can support me with a coffee. Every contribution, big or small, helps me keep creating more free content for you.

💛You can support me here: Buy Me a Coffee

That works well for learning.
But in real applications, we usually do not create Pods directly.

Instead, we use something called a Deployment.

A Deployment is the standard way to run applications in Kubernetes.

🧠 Simple Definition

A Deployment is a Kubernetes resource that:

• creates Pods

• keeps them running

• replaces failed Pods

• scales Pod count

• supports updates

You define the desired state.
Deployment maintains it.

📦 Why Not Create Pods Directly

Creating a Pod directly has limits:

• if it crashes, it stays down

• no automatic replacement

• no scaling

• no rolling updates

Deployments solve all of this automatically.

That is why Deployments are used in most real setups.

🔁 What Deployment Does for You

When you create a Deployment, Kubernetes will:

✅ create Pods
✅ monitor them
✅ recreate if they fail
✅ keep required count running
✅ update safely when image changes

You manage the Deployment.
Deployment manages the Pods.

📈 Scaling Made Easy

Want more app copies running?

In a Deployment, you just change:

replicas: 3

Kubernetes will run 3 Pods automatically.

No manual Pod creation needed.

🔄 Safe Application Updates

Deployments support rolling updates.

That means:

• new Pods start first

• old Pods stop gradually

• application stays available

Users do not see downtime.

🏗️ Simple Mental Model

Think like this 🧠

Pod = single worker
Deployment = team manager

You don’t hire workers one by one.
You tell the manager how many you need.

👀 You Can Still View Pods

Even when using Deployments, you can still run:

kubectl get pods

Pods will appear, but they are now controlled by the Deployment.

You normally don’t manage them directly.

🎯 Key Takeaway

Deployments are the proper way to run applications in Kubernetes.

They create Pods
keep them healthy
scale them
update them safely

Next, we will create a Deployment YAML file and run it step by step ⚙️🌱

✨ Thanks for reading!

I publish posts on DevOps regularly. So, make sure you subscribe to get the latest updates straight to your inbox.

Subscribe now

If you enjoy my content and find it valuable, you can support me with a coffee. Every contribution, big or small, helps me keep creating more free content for you.

💛You can support me here: Buy Me a Coffee