Day 12 - Kubernetes - 90daysofDevOps

Namespace

In Kubernetes, a namespace is a mechanism to divide cluster resources between multiple users or teams. It provides scope for names, allowing different teams to use the same resource names (e.g., services, pods) without conflict by placing them in different namespaces.

Key Concepts of Namespaces

• Logical Partitioning: Namespaces are intended for use in environments with many users spread across multiple teams or projects. They allow resource isolation.

• Scope: Namespaces provide a scope for names. The names of resources need to be unique within a namespace, but not across namespaces.

• Default Namespace: If you do not specify a namespace, Kubernetes assumes the resource is in the default namespace.

When to Use Namespaces

• Namespaces are helpful when you want to segment a Kubernetes cluster into virtual clusters.

• Ideal for situations with multiple teams or projects running on the same cluster.

• Useful for implementing different policies (e.g., resource quotas, network policies) for different environments.

Namespace Types in Kubernetes

1. Default Namespace:

   • default: The default namespace for resources when a namespace is not specified.

   • All the resources created without explicitly specifying a namespace will be placed here.

2. System Namespaces:

   • kube-system: Used for Kubernetes system components like the API server, controller manager, etc.

   • kube-public: A namespace that is readable by all users (including those not authenticated). It is generally used for cluster information that should be publicly accessible.

   • kube-node-lease: Contains lease objects associated with each node, which helps in node heartbeat performance (added in Kubernetes v1.13).

3. User-Created Namespaces:

   • These are custom namespaces created by users to logically separate resources for different environments, projects, or teams.

   • Example: You might create a namespace like dev, test, or prod to separate development, testing, and production workloads.

Namespace Operations

• Create Namespace:

    kubectl create namespace <namespace-name>
  

• View Namespaces:

    kubectl get namespaces
  

• Delete Namespace:

    kubectl delete namespace <namespace-name>
  

Namespaces allow for clear organizational boundaries and resource allocation within a Kubernetes cluster.

Manage Applications :

In Kubernetes, both Deployments, Replicasets, and ReplicationControllers are used to manage and ensure the availability of application instances (or pods). Here's an overview of each:

1. Kubernetes Deployment

A Deployment is the most commonly used higher-level object for managing and scaling applications in Kubernetes. It provides declarative updates for Pods and ReplicaSets. With Deployments, you can:

• Create and manage applications (using Pods).

• Scale the number of Pod replicas.

• Roll out updates to your application in a controlled manner.

• Rollback to a previous state if something goes wrong during updates.

• Automatically replace failed Pods.

Key Features of Deployment:

• Declarative Syntax: You declare the desired state of your application (e.g., number of replicas, image version), and Kubernetes ensures that the actual state matches this desired state.

• Rolling Updates: Deployments allow you to update your Pods with no downtime by rolling out updates progressively.

• Rollback: If something goes wrong during an update, you can roll back to a previous version.

Example of a Deployment YAML:

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

2. Kubernetes ReplicaSet

A ReplicaSet ensures that a specified number of identical Pods are running at all times. If a Pod fails or gets deleted, the ReplicaSet creates a new one to replace it. However, you will rarely use ReplicaSets directly, as they are typically managed by Deployments.

• ReplicaSets are used within Deployments to ensure the correct number of Pods are running.

• Self-healing: If a Pod is deleted or crashes, the ReplicaSet will create new Pods to maintain the desired number of replicas.

Example of a ReplicaSet YAML:

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: nginx-replicaset
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.16
        ports:
        - containerPort: 80

3. Kubernetes ReplicationController

A ReplicationController (RC) is similar to a ReplicaSet but has some limitations. It ensures that a specified number of Pod replicas are running at any time. However, ReplicaSets were introduced as an enhancement to ReplicationControllers, which is why ReplicationControllers have largely been superseded by ReplicaSets.

• ReplicationController also monitors and maintains a specific number of running pods.

• Self-healing: Like ReplicaSets, it automatically replaces failed Pods.

Key Difference from ReplicaSets:

• ReplicaSets offer more advanced features, such as label selectors that support set-based matching (e.g., "in", "notin" selectors), which aren't supported by ReplicationControllers.

Example of a ReplicationController YAML:

apiVersion: v1
kind: ReplicationController
metadata:
  name: nginx-controller
spec:
  replicas: 3
  selector:
    app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.16
        ports:
        - containerPort: 80

Comparison:

• Deployment: Provides a higher level of management for applications, with support for rolling updates and rollbacks. It is built on top of ReplicaSets.

• ReplicaSet: Ensures that a certain number of pod replicas are running but lacks the ability to handle rolling updates and rollbacks on its own. It is mostly managed by Deployments.

• ReplicationController: An older and less advanced resource similar to ReplicaSets but lacking some modern features.

When to Use Which?

• Deployment: Use this for nearly all cases where you need to manage applications because it includes all features of ReplicaSets and supports rolling updates and rollbacks.

• ReplicaSet: This is managed by Deployments, and you'll rarely use it directly.

• ReplicationController: Generally no longer recommended in favor of ReplicaSets.

Deployments are the most commonly used in modern Kubernetes workflows.

Charting Our Kubernetes Adventure 🗺️

Today's Kubernetes tasks felt like discovering the secrets of container orchestration. Navigating through the complexities of Kubernetes architecture and setting up a local cluster with Minikube was truly an enlightening experience. Sail through the realm of containers, and let’s share our Kubernetes stories on this #DevOpsJourney! ⚓🌐

Join me tomorrow for another exciting DevOps challenge. Until then, keep orchestrating! 🚀🐳

Happy Kubernetes-ing! 🌟👨‍💻