DEV Community: Nishant Raj

Managing Kubernetes Namespaces, Deployments, and Scaling: A Practical Walkthrough

Nishant Raj — Fri, 06 Dec 2024 07:26:08 +0000

This blog dives into a real-world Kubernetes command history to demonstrate namespace creation, deployment management, pod scaling, and service exposure. By retracing these commands, we provide a clear and actionable guide for those starting with Kubernetes or seeking to enhance their understanding of these core features.

Step 1: Working with Kubernetes Namespaces

Namespaces are logical partitions within a Kubernetes cluster, often used for separating environments (e.g., development, testing, production) or grouping resources.

1.1. Listing Existing Namespaces

kubectl get ns

This command lists all namespaces in your cluster, including the default ones like default, kube-system, and kube-public.

1.2. Creating Namespaces

You can create a namespace in two ways:

Imperative Way:

  kubectl create ns demo-2

This creates a namespace named demo-2.

Declarative Way (via YAML): Create a ns.yml file:

  apiVersion: v1
  kind: Namespace
  metadata:
    name: app-ns

Apply the configuration:

  kubectl apply -f ns.yml

1.3. Deleting a Namespace

To delete a namespace:

kubectl delete ns/demo-2

Step 2: Creating and Managing Deployments

Deployments are used to describe the desired state of your application (e.g., number of replicas, container image).

2.1. Creating a Deployment

Create a deployment named nginx-demo in the app-ns namespace:

kubectl create deploy nginx-demo --image=nginx -n app-ns

2.2. Viewing Deployments

kubectl get deploy -n app-ns

This lists all deployments within the app-ns namespace.

Step 3: Scaling Deployments

Scaling adjusts the number of replicas for a Deployment to ensure application availability.

3.1. Scaling to 3 Replicas

kubectl scale --replicas=3 deploy/nginx-demo -n app-ns

3.2. Verifying Scaling

kubectl get pods -n app-ns

The output should show 3 Pods running for the nginx-demo Deployment.

Step 4: Exposing Deployments with Services

Services expose applications running in Pods to other Pods or external users.

4.1. Exposing a Deployment

Create a Service named svc-demo to expose nginx-demo on port 80:

kubectl expose deploy/nginx-demo --name=svc-demo --port=80 -n app-ns

4.2. Viewing Services

kubectl get svc -n app-ns

This lists all Services in the app-ns namespace. The svc-demo Service should be listed with the ClusterIP type by default.

Step 5: Executing Commands Inside Pods

Kubernetes allows you to run commands directly inside Pods for debugging or configuration purposes.

5.1. Accessing a Pod

Find the name of a Pod:

kubectl get pods -n app-ns -o wide

Execute a shell inside the Pod:

kubectl exec -it <pod-name> -n app-ns -- sh

Example:

kubectl exec -it nginx-demo-cccbdc67f-8c88q -n app-ns -- sh

Step 6: Common Errors and Troubleshooting

Issue: `Namespace Not Found`

Cause: Trying to create resources in a non-existent namespace.
Solution: Ensure the namespace exists by running:

  kubectl create ns <namespace-name>

Issue: `Deployment Not Exposed via Service`

Cause: Forgetting to create a Service.
Solution: Use the expose command as shown in Step 4.1.

Exploring Fully Qualified Domain Names (FQDN) in Kubernetes Networking

In this task, we focus on resolving service addresses using FQDN (Fully Qualified Domain Name) and the DNS resolution mechanism within a Kubernetes cluster.

Steps Explained

Initial Setup:
- The pod deploy-ns1-7d9fb5fd75-925lr resides in the namespace ns1.
- The service svc-ns1 is a ClusterIP service, accessible within the cluster using its CLUSTER-IP or FQDN.
Using ClusterIP for Access:
- The service svc-ns1 has the CLUSTER-IP 10.96.153.161.
- You verified access by running:
```
 curl 10.244.2.12
```
Result: NGINX's welcome page confirms the service is working.
Querying Services by Name:
- To resolve service names, Kubernetes uses DNS. Within the pod, the DNS setup is defined in /etc/resolv.conf:
```
 cat /etc/resolv.conf
```
Output:
```
 search ns1.svc.cluster.local svc.cluster.local cluster.local
 nameserver 10.96.0.10
 options ndots:5
```
The search domains allow services to be resolved by shorter names if they are within the same namespace.
Accessing the Service in the Same Namespace:
- The pod in namespace ns1 tried to access svc-ns1:
```
 curl svc-ns1
```
This worked because svc-ns1 is in the same namespace (ns1).
Accessing Services in Other Namespaces:
- When you tried:
```
 curl svc-ns2
```
It failed with:
```
 curl: (6) Could not resolve host: svc-ns2
```
The service svc-ns2 resides in a different namespace (ns2), and its FQDN must be used to resolve it.
Using FQDN for Cross-Namespace Access:
- Kubernetes services can be accessed using their fully qualified domain name:
```
 <service-name>.<namespace>.svc.cluster.local
```

When you tried:
```
 curl svc-ns2.ns2.svc.cluster.local
```
It successfully returned the NGINX welcome page.

Key Concepts

ClusterIP Services:
These services are accessible only within the cluster using their CLUSTER-IP or DNS name.
DNS Search Paths:
In Kubernetes, DNS names are automatically resolved based on the search paths defined in /etc/resolv.conf.
- For services in the same namespace, you can use just the service name (svc-ns1).
- For services in a different namespace, the FQDN (svc-ns2.ns2.svc.cluster.local) must be used.
Namespace Isolation:

Kubernetes isolates services by namespace. Cross-namespace communication requires explicit specification of the namespace.

Final Validation

To summarize:

Access service svc-ns1 in the same namespace:

  curl svc-ns1

Access service svc-ns2 in a different namespace using FQDN:

  curl svc-ns2.ns2.svc.cluster.local

By following this approach, you can resolve and access services within and across namespaces in a Kubernetes cluster.

Conclusion

This guide covered the essential Kubernetes workflows:

Creating and managing namespaces.
Deploying applications with Deployments.
Scaling applications.
Exposing applications using Services.
Debugging Pods via kubectl exec.

By understanding these tasks, you’ll be equipped to manage Kubernetes workloads effectively. Keep experimenting with different commands and configurations to deepen your Kubernetes expertise. Happy learning! 🚀

Exposing and Managing Applications in Kubernetes: A Step-by-Step Guide

Nishant Raj — Fri, 06 Dec 2024 04:15:38 +0000

In this blog, we will explore how to expose applications using Kubernetes Services and manage Deployments for scaling and accessibility. We'll create Services of type NodePort and LoadBalancer, test the application’s accessibility, and discuss Service types and their use cases.

Task 1: Create a Service of Type `NodePort`

Objective:

Create a NodePort Service named myapp-service to expose your application on port 80, accessible externally via a Node's IP and NodePort.

Solution

Step 1: Define the Service YAML

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

Step 2: Apply the YAML

kubectl apply -f nodeport-service.yml

Step 3: Verify the Service

kubectl get svc myapp-service

Expected output:

NAME             TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
myapp-service    NodePort    10.96.100.123    <none>        80:30080/TCP     5s

Step 4: Access the Service

Use a Node's IP and the NodePort to test access:

wget http://<Node-IP>:30080

Task 2: Create a Deployment

Objective:

Deploy an application using the nginx:1.23.4-alpine image, expose port 80, and ensure 1 replica is running.

Solution

Step 1: Define the Deployment YAML

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 1
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: nginx
        image: nginx:1.23.4-alpine
        ports:
        - containerPort: 80

Step 2: Apply the YAML

kubectl apply -f deployment.yml

Step 3: Verify the Deployment

kubectl get deploy myapp
kubectl get pods

Task 3: Scale the Deployment

Objective:

Scale the Deployment to run 2 replicas.

Solution

Step 1: Scale the Deployment

kubectl scale deploy myapp --replicas=2

Step 2: Verify the Scale

kubectl get deploy myapp
kubectl get pods

Task 4: Test the Service Internally (Not necessary but anyway..)

Objective:

Create a temporary Pod using the busybox image and test the internal accessibility of the Service.

Solution

Step 1: Run a Temporary Pod

kubectl run busybox --rm -it --image=busybox -- /bin/sh

Step 2: Test the Service

Inside the busybox shell:

wget -O- http://myapp-service
exit

Task 5: Test the Service Externally

Objective:

Verify that the Service is accessible outside the cluster.

Solution

From a host outside the cluster, use a Node's IP and the NodePort to test access:

wget http://<Node-IP>:30080

Task 6: Expose the Service via LoadBalancer

Objective:

Modify the Service to use the LoadBalancer type, making it accessible with an external IP.

Solution

Step 1: Update the Service Type

kubectl edit svc myapp-service

Change the type field to LoadBalancer:

type: LoadBalancer

Step 2: Verify the External IP

kubectl get svc myapp-service

Check the EXTERNAL-IP field for the assigned IP address.

Step 3: Test the Service

wget http://<EXTERNAL-IP>

Task 7: Can Pods Be Exposed Without a Deployment?

Discussion:

Yes, Pods can be exposed without a Deployment by creating a Service with a label selector matching the Pods. However, this approach lacks features like:

Automatic restart of failed Pods.
Scaling capabilities.
Rolling updates or rollbacks.

Best Practice: Use Deployments for most scenarios to leverage Kubernetes’ scaling and fault-tolerance features.

Task 8: When to Use Different Service Types

ClusterIP (Default)

Purpose: Internal-only communication between services.
Use Case: Backend services accessed by frontend Pods.

NodePort

Purpose: Expose a Service on each Node's IP and a specific port.
Use Case: Testing applications locally or in environments without a LoadBalancer.

LoadBalancer

Purpose: Provide external access using a cloud provider’s load balancer.
Use Case: Production environments hosted on cloud platforms.

ExternalName

Purpose: Map a Service to an external DNS name.
Use Case: Redirect traffic to legacy systems or external APIs.

Conclusion

In this guide, we explored:

Creating and using NodePort and LoadBalancer Services.
Managing Deployments for scaling and reliability.
Testing Service accessibility internally and externally.
Understanding Service types and their appropriate use cases.

These practices are essential for building and exposing scalable, accessible Kubernetes applications. Stay tuned for more Kubernetes insights! 🚀

Understanding the Differences Between ReplicationController, ReplicaSet, and Deployment in Kubernetes

Nishant Raj — Sun, 01 Dec 2024 18:09:13 +0000

Understanding the differences between ReplicationController, ReplicaSet, and Deployment is crucial for managing workloads in Kubernetes. These three resources have overlapping functionalities but serve distinct purposes. Here’s a breakdown:

1. ReplicationController (RC)

Definition:

The ReplicationController is an older Kubernetes resource used to ensure that a specified number of Pod replicas are running at any given time.

Key Features:

Ensures a fixed number of replicas are running.
Replaces failed Pods automatically.
Uses label selectors for managing Pods.

Limitations:

Cannot manage complex deployment scenarios like rolling updates.
Replaced by ReplicaSet for more advanced functionality.

Example YAML:

apiVersion: v1
kind: ReplicationController
metadata:
  name: my-app-rc
spec:
  replicas: 3
  selector:
    app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app-container
        image: nginx

2. ReplicaSet (RS)

Definition:

The ReplicaSet is an enhanced version of the ReplicationController, designed to manage the same tasks while supporting set-based label selectors.

Key Features:

Ensures a specified number of Pod replicas are running.
Supports set-based selectors (e.g., in, notin, exists), allowing more flexible matching of Pods.
Replaces ReplicationController in modern Kubernetes usage.

Limitations:

Doesn't directly support rolling updates or rollbacks.
Primarily used as a building block for Deployments.

Example YAML:

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: my-app-rs
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app-container
        image: nginx

3. Deployment

Definition:

The Deployment is a higher-level abstraction that uses ReplicaSets internally to manage Pods and provides advanced features for managing application lifecycle and updates.

Key Features:

Automates rolling updates and rollbacks.
Tracks revision history for safer updates and rollbacks.
Supports scaling, pausing, and resuming updates.
Provides declarative updates for Pods and ReplicaSets.

Advantages Over ReplicaSet:

Simplifies update processes with commands like kubectl set image.
Manages rolling updates with no downtime.
Automatically cleans up old ReplicaSets.

Example YAML:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-deploy
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app-container
        image: nginx:1.23.0

Comparison Table

Feature	ReplicationController	ReplicaSet	Deployment
Primary Purpose	Maintain Pod replicas.	Maintain Pod replicas with set-based selectors.	Higher-level abstraction for managing workloads.
Selector Support	Equality-based selectors only.	Set-based selectors.	Inherits ReplicaSet selectors.
Rolling Updates	Not supported.	Not supported.	Fully supported.
Rollback Support	Not supported.	Not supported.	Fully supported.
Revision History	Not available.	Not available.	Maintains history of changes.
Common Use Case	Legacy systems.	Used by Deployments.	Modern workload management.
Preferred Resource	Deprecated in favor of RS.	Used indirectly by Deployments.	Recommended for most use cases.

When to Use Which?

ReplicationController
- Rarely used in modern Kubernetes setups.
- Use if working with older Kubernetes versions (<1.2).
ReplicaSet
- Use if you need direct control over replica management without advanced features.
- Typically created indirectly by Deployments.
Deployment
- Preferred for most use cases.
- Use for applications requiring scaling, updates, and rollbacks.

Mastering Kubernetes ReplicaSets and Deployments: Step-by-Step Guide with Troubleshooting

Nishant Raj — Sat, 30 Nov 2024 18:34:53 +0000

Efficiently managing workloads in Kubernetes involves understanding two core concepts: ReplicaSets and Deployments. This guide will walk you through creating, updating, and troubleshooting these resources with real-world examples.

What is a ReplicaSet?

A ReplicaSet is a Kubernetes resource that ensures a specified number of identical Pod replicas are running at all times. It is typically used to maintain high availability and scalability for applications.

Key Features of a ReplicaSet:

Ensures a consistent number of Pods are running.
Automatically replaces Pods if they fail.
Used as a building block for Deployments.

Part 1: Working with ReplicaSets

Task 1: Create a ReplicaSet with 3 Replicas

Objective: Use the nginx image to create a ReplicaSet with 3 replicas.

Step-by-Step Solution:

Create a YAML configuration for the ReplicaSet and save it as replicaset.yml:

   apiVersion: apps/v1
   kind: ReplicaSet
   metadata:
     name: nginx-rs
     labels:
       env: demo
   spec:
     replicas: 3
     selector:
       matchLabels:
         env: demo
     template:
       metadata:
         labels:
           env: demo
       spec:
         containers:
         - name: nginx
           image: nginx

Explanation:

replicas: Specifies the desired number of Pods (3 in this case).
selector.matchLabels: Ensures the ReplicaSet manages only Pods with the env=demo label.
template: Defines the Pod template used to create replicas.

Apply the configuration to create the ReplicaSet:

   kubectl apply -f replicaset.yml

Verify the creation of the ReplicaSet:

   kubectl get rs

Task 2: Scale the ReplicaSet

Objective: Increase the number of replicas from 3 to 6.

Step-by-Step Solution:

Edit the ReplicaSet using the following command:

   kubectl edit rs nginx-rs

Locate the replicas: 3 line and update it to:

   replicas: 6

Save and exit the editor. Kubernetes will automatically scale the ReplicaSet.
Verify the updated ReplicaSet:

   kubectl get rs
   kubectl get pods

What is a Deployment?

A Deployment is a Kubernetes resource that provides declarative updates to applications. It automates rolling updates, rollbacks, scaling, and self-healing for your workloads.

Key Features of a Deployment:

Manages ReplicaSets for ensuring desired Pod counts.
Simplifies rolling updates for application versions.
Tracks rollout history for safe rollbacks.

Part 2: Managing Deployments

Task 1: Create a Deployment with 3 Replicas

Objective: Deploy 3 replicas of the nginx application using the nginx:1.23.0 image.

Step-by-Step Solution:

Create a YAML file named deployment.yml:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: nginx-deploy
     labels:
       tier: backend
   spec:
     replicas: 3
     selector:
       matchLabels:
         app: v1
     template:
       metadata:
         labels:
           app: v1
         name: nginx
       spec:
         containers:
         - name: nginx
           image: nginx:1.23.0

Explanation:

replicas: Defines the desired number of Pods.
selector.matchLabels: Ensures that the Deployment manages only Pods with the label app=v1.
template.metadata.labels: Defines labels for Pods created by this Deployment.

Apply the configuration to create the Deployment:

   kubectl apply -f deployment.yml

Verify the Deployment and Pods:

   kubectl get deploy
   kubectl get pods

Task 2: Update the Deployment

Update the Image to `nginx:1.23.4`

Use the kubectl set image command to update the Deployment:

   kubectl set image deploy/nginx-deploy nginx=nginx:1.23.4

Verify the updated Pods:

   kubectl get pods

Explanation:

This command updates the image for all Pods managed by the Deployment, rolling out the changes seamlessly.

Scale the Deployment to 5 Replicas

Edit the Deployment:

   kubectl edit deploy nginx-deploy

Find the replicas: 3 line and change it to:

   replicas: 5

Save and exit. Kubernetes will scale the Deployment.
Verify the new replica count:

   kubectl get deploy
   kubectl get pods

Task 3: Rollout History and Rollback

View Deployment Rollout History

kubectl rollout history deploy/nginx-deploy

Revert Deployment to Revision 1

kubectl rollout undo deploy/nginx-deploy --to-revision=1

Part 3: Troubleshooting YAML Issues

Issue 1: Incorrect `apiVersion` for Deployment

Problem: The YAML uses apiVersion: v1 instead of apps/v1.

Solution:

Update the apiVersion to apps/v1.

Issue 2: Label Mismatch in `selector.matchLabels`

Problem: The selector.matchLabels does not match the Pod template's labels.

Solution: Update `selector.matchLabels` to match the template's labels:

selector:
  matchLabels:
    app: v1

Conclusion

In this guide, you learned how to:

Create and scale ReplicaSets.
Deploy and update applications using Deployments.
Troubleshoot common YAML issues.

Pro Tip:

Use kubectl describe to debug resource issues.
Leverage kubectl rollout commands to track changes and manage rollbacks.

By mastering these concepts, you can confidently manage Kubernetes workloads.

References:

"Mastering Kubernetes Pods: Imperative Commands, YAML Configurations, and Troubleshooting Guide"

Nishant Raj — Sat, 23 Nov 2024 19:22:15 +0000

Kubernetes Pods are the smallest deployable units that you can create and manage in Kubernetes. In this guide, you’ll learn how to:

Create Pods using imperative commands.
Generate YAML configurations for Pods.
Modify and troubleshoot Pods step by step.

Let’s dive in!

Task 1: Create a Pod Using the Imperative Command

Objective: Create a Pod with the name nginx-pod using the nginx image.

Step-by-Step Solution:

Use the following imperative command to create the Pod:

   kubectl run nginx-pod --image=nginx

Verify that the Pod is created by listing all Pods:

   kubectl get pods

You should see an output similar to this:

   NAME         READY   STATUS    RESTARTS   AGE  
   nginx-pod    1/1     Running   0          5s

Task 2: Generate YAML for the Created Pod

Objective: Convert the Pod created in Task 1 into a YAML configuration file for further customization.

Step-by-Step Solution:

Step 1: Create a YAML file

Use the touch command to create an empty file:

touch pod.yml

Step 2: Write the Pod configuration

Open the file in a text editor (e.g., nano, vim, or VS Code) and add the following YAML:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    env: demo
    type: frontend
spec:
  containers:
  - name: nginx-container
    image: nginx
    ports:
    - containerPort: 80

Step 3: Verify Pods

Run the following command to ensure the existing Pod is running:

kubectl get pods

Update the Pod Name in YAML

If you need to change the Pod name, you can modify the metadata.name field in the YAML. For example, update the Pod name to nginx-pod-updated:

Updated YAML:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod-updated
  labels:
    env: demo
    type: frontend
spec:
  containers:
  - name: nginx-container
    image: nginx
    ports:
    - containerPort: 80

To apply the updated configuration:

kubectl apply -f pod.yml

Create a New Pod from YAML

To create a new Pod with a different name, update the metadata.name field to nginx-new:

Updated YAML:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-new
  labels:
    env: demo
    type: frontend
spec:
  containers:
  - name: nginx-container
    image: nginx
    ports:
    - containerPort: 80

Run the following command to create the Pod:

kubectl apply -f pod.yml

Task 3: Fix YAML Errors

Objective: Troubleshoot and fix errors in a faulty YAML configuration.

Given YAML File:

apiVersion: v1
kind: Pod
metadata:
  labels:
    app: test
  name: redis
spec:
  containers:
  - image: rediss
    name: redis

Step-by-Step Troubleshooting Solution:

Step 1: Save the YAML File

Copy the given YAML into a file:

touch pod.yml

Step 2: Apply the YAML

Run the following command to create the Pod:

kubectl create -f pod.yml

Step 3: Check the Pod Status

If the Pod fails to start, check its status and error message:

kubectl describe pod redis

Example Error Message:

Failed to pull image "rediss": rpc error: code = Unknown desc = Error response from daemon: pull access denied for rediss, repository does not exist or may require 'docker login'

Step 4: Edit the YAML to Fix Errors

Use the kubectl edit command to open the YAML file directly:

kubectl edit pod redis

Update the image field to the correct value:

image: redis

Step 5: Save Changes

Save and exit the editor. Kubernetes will automatically update the running Pod.

Step 6: Verify the Updated Pod

Check the Pod status again:

kubectl get pods

You should see the Pod running successfully.

Conclusion

In this guide, we covered:

How to create Pods using imperative commands.
Generating and modifying YAML configurations.
Troubleshooting common YAML errors step by step.

Pro Tips:

Always verify Pods using kubectl get pods.
Use kubectl describe to inspect issues.
Edit YAML files dynamically with kubectl edit.

By mastering these tasks, you’re well on your way to becoming proficient in Kubernetes Pod management!

References:

DEV Community: Nishant Raj

Managing Kubernetes Namespaces, Deployments, and Scaling: A Practical Walkthrough

Step 1: Working with Kubernetes Namespaces

1.1. Listing Existing Namespaces

1.2. Creating Namespaces

1.3. Deleting a Namespace

Step 2: Creating and Managing Deployments

2.1. Creating a Deployment

2.2. Viewing Deployments

Step 3: Scaling Deployments

3.1. Scaling to 3 Replicas

3.2. Verifying Scaling

Step 4: Exposing Deployments with Services

4.1. Exposing a Deployment

4.2. Viewing Services

Step 5: Executing Commands Inside Pods

5.1. Accessing a Pod

Step 6: Common Errors and Troubleshooting

Issue: Namespace Not Found

Issue: Deployment Not Exposed via Service

Exploring Fully Qualified Domain Names (FQDN) in Kubernetes Networking

Steps Explained

Key Concepts

Final Validation

Conclusion

Exposing and Managing Applications in Kubernetes: A Step-by-Step Guide

Task 1: Create a Service of Type NodePort

Solution

Step 1: Define the Service YAML

Step 2: Apply the YAML

Step 3: Verify the Service

Step 4: Access the Service

Task 2: Create a Deployment

Solution

Step 1: Define the Deployment YAML

Step 2: Apply the YAML

Step 3: Verify the Deployment

Task 3: Scale the Deployment

Solution

Step 1: Scale the Deployment

Step 2: Verify the Scale

Task 4: Test the Service Internally (Not necessary but anyway..)

Solution

Step 1: Run a Temporary Pod

Step 2: Test the Service

Task 5: Test the Service Externally

Solution

Task 6: Expose the Service via LoadBalancer

Solution

Step 1: Update the Service Type

Step 2: Verify the External IP

Step 3: Test the Service

Task 7: Can Pods Be Exposed Without a Deployment?

Task 8: When to Use Different Service Types

ClusterIP (Default)

NodePort

LoadBalancer

ExternalName

Conclusion

Understanding the Differences Between ReplicationController, ReplicaSet, and Deployment in Kubernetes

1. ReplicationController (RC)

2. ReplicaSet (RS)

3. Deployment

Comparison Table

When to Use Which?

Mastering Kubernetes ReplicaSets and Deployments: Step-by-Step Guide with Troubleshooting

What is a ReplicaSet?

Part 1: Working with ReplicaSets

Task 1: Create a ReplicaSet with 3 Replicas

Step-by-Step Solution:

Task 2: Scale the ReplicaSet

Step-by-Step Solution:

What is a Deployment?

Part 2: Managing Deployments

Task 1: Create a Deployment with 3 Replicas

Step-by-Step Solution:

Task 2: Update the Deployment

Update the Image to nginx:1.23.4

Scale the Deployment to 5 Replicas

Task 3: Rollout History and Rollback

Issue: `Namespace Not Found`

Issue: `Deployment Not Exposed via Service`

Task 1: Create a Service of Type `NodePort`

Update the Image to `nginx:1.23.4`

Issue 1: Incorrect `apiVersion` for Deployment

Issue 2: Label Mismatch in `selector.matchLabels`

Solution: Update `selector.matchLabels` to match the template's labels: