What are Namespaces?

Namespaces: In Kubernetes, namespaces provide a mechanism for isolating groups of resources within a single cluster. Names of resources need to be unique within a namespace, but not across namespaces. Namespace-based scoping is applicable only for namespaced objects (e.g. Deployments, Services, etc.) and not for cluster-wide objects (e.g. StorageClass, Nodes, PersistentVolumes, etc.).

Initial namespaces

Kubernetes starts with four initial namespaces:

default: Kubernetes includes this namespace so that you can start using your new cluster without first creating a namespace.
kube-node-lease: This namespace holds Lease objects associated with each node. Node leases allow the kubelet to send heartbeats so that the control plane can detect node failure.
kube-public: This namespace is readable by all clients (including those not authenticated). This namespace is mostly reserved for cluster usage, in case that some resources should be visible and readable publicly throughout the whole cluster. The public aspect of this namespace is only a convention, not a requirement.
kube-system: The namespace for objects created by the Kubernetes system.

Viewing namespaces

You can list the current namespaces in a cluster using:

kubectl get namespace

NAME              STATUS   AGE
default           Active   1d
kube-node-lease   Active   1d
kube-public       Active   1d
kube-system       Active   1d

Creating a new namespace

Create a new YAML file called my-namespace.yaml with the contents:

apiVersion: v1
kind: Namespace
metadata:
  name: <insert-namespace-name-here>

Then run:

kubectl create -f ./my-namespace.yaml

Alternatively, you can create namespace using below command:

kubectl create namespace <insert-namespace-name-here>

Deleting a namespace

Delete a namespace with

kubectl delete namespaces <insert-some-namespace-name>

What are Services, loadbalancing and Networking?

Services:

Purpose: Services are a crucial abstraction in Kubernetes that allow pods to communicate with each other or with external clients. They provide stable endpoints to access pods, even as pods are created or terminated.
Use Cases: Services are commonly used to expose applications running in pods to the network. They enable load balancing, service discovery, and automatic routing of traffic to healthy pods.
Types of Services: Kubernetes supports various types of services, including:
- ClusterIP: Exposes the service on a cluster-internal IP, only accessible within the cluster.
- NodePort: Exposes the service on a static port on each node's IP, allowing external access to the service.
- LoadBalancer: Creates an external load balancer (if supported by the cloud provider) and assigns a unique external IP to access the service.
- ExternalName: Maps the service to a DNS name.
Creating Services: You can create a service by defining a Service resource in a YAML or JSON manifest and applying it to the cluster using kubectl apply.

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

kubectl apply -f my-service.yaml

Load Balancing:

Kubernetes Services are used to expose Pods to the network. When you create a Service, it automatically sets up load balancing for the Pods that match its selector. There are different types of Services:

ClusterIP: The default type. It exposes the Service on an internal IP within the cluster, making it accessible only from within the cluster.
NodePort: Exposes the Service on a port across all Nodes in the cluster. It's suitable for accessing the Service externally, but traffic is still forwarded to the Pods.
LoadBalancer: When supported by the underlying infrastructure, this type creates an external load balancer that forwards external traffic to the Service's Pods.

Networking:

Networking in Kubernetes deals with how containers and Pods communicate both within the cluster and with external entities. Key networking concepts include:

Pod Networking: Containers within the same Pod share the same network namespace, allowing them to communicate over localhost. This simplifies intra-Pod communication.
Service Networking: Services abstract the network details of Pods. They provide a stable endpoint for accessing a set of Pods, enabling load balancing and service discovery.
Ingress: Ingress resources define rules for routing external HTTP(S) traffic to Services within the cluster. They act as a smart router, directing requests based on hostnames and paths.
Network Policies: These are used to control traffic flow to and from Pods. Network policies define rules for allowing or denying traffic based on labels, namespaces, and IP addresses, enhancing security.
Container Network Interface (CNI): Kubernetes relies on CNI plugins to manage container networking. These plugins configure network interfaces in Pods, ensuring proper network isolation and communication.
DNS: Kubernetes has an integrated DNS service. It allows Pods to discover and communicate with each other using human-readable names, abstracting away the need to know IP addresses.
Network Plugins: Kubernetes supports various network plugins (e.g., Calico, Flannel, Weave) to manage networking within the cluster. These plugins offer different features and capabilities to suit various use cases.

Task 1:

Create a Namespace for your Deployment
Use the command kubectl create namespace <namespace-name> to create a Namespace
Update the deployment.yml file to include the Namespace
Apply the updated deployment using the command: kubectl apply -f deployment.yml -n <namespace-name>
Verify that the Namespace has been created by checking the status of the Namespaces in your cluster.

Day 33 Task: Working with Namespaces and Services in Kubernetes

Table of contents