DEV Community

Nishant Raj
Nishant Raj

Posted on

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

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

This creates a namespace named demo-2.

  • Declarative Way (via YAML): Create a ns.yml file: 
  apiVersion: v1
  kind: Namespace
  metadata:
    name: app-ns
Enter fullscreen mode Exit fullscreen mode

Apply the configuration:

  kubectl apply -f ns.yml
Enter fullscreen mode Exit fullscreen mode

1.3. Deleting a Namespace

To delete a namespace:

kubectl delete ns/demo-2
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

2.2. Viewing Deployments 

kubectl get deploy -n app-ns
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

3.2. Verifying Scaling 

kubectl get pods -n app-ns
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

4.2. Viewing Services 

kubectl get svc -n app-ns
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Execute a shell inside the Pod:

kubectl exec -it <pod-name> -n app-ns -- sh
Enter fullscreen mode Exit fullscreen mode

Example:

kubectl exec -it nginx-demo-cccbdc67f-8c88q -n app-ns -- sh
Enter fullscreen mode Exit fullscreen mode

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>
Enter fullscreen mode Exit fullscreen mode

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

  1. 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.

  2. 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.

  3. 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.

  4. 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).

  5. 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.

  6. 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
Enter fullscreen mode Exit fullscreen mode
  • Access service svc-ns2 in a different namespace using FQDN: 
  curl svc-ns2.ns2.svc.cluster.local
Enter fullscreen mode Exit fullscreen mode

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:

  1. Creating and managing namespaces.
  2. Deploying applications with Deployments.
  3. Scaling applications.
  4. Exposing applications using Services.
  5. 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! 🚀

Top comments (0)

Read next

abhay_yt_52a8e72b213be229 profile image

Handling Concurrency and Parallelism in PHP Applications: Techniques and Tools

Strange -

msnmongare profile image

What is Bubble Sort?

Sospeter Mong'are -

abhay_yt_52a8e72b213be229 profile image

Mastering Unit Testing in PHP: Tools, Frameworks, and Best Practices

Strange -

abhay_yt_52a8e72b213be229 profile image

Understanding the SOLID Principles in PHP and How They Improve Code Quality

Strange -