Day 33 Task: Working with Namespaces and Services in Kubernetes

UserNamespace:

A user namespace isolates the user running inside the container from the one in the host.

A process running as root in a container can run as a different (non-root) user in the host; in other words, the process has full privileges for operations inside the user namespace, but is unprivileged for operations outside the namespace.

You can use this feature to reduce the damage a compromised container can do to the host or other pods in the same node. There are several security vulnerabilities rated either HIGH or CRITICAL that were not exploitable when user namespaces is active. It is expected user namespace will mitigate some future vulnerabilities too.

Syntax:

kubectl create namespace Name

Task 1:

• Create a Namespace for your Deployment

• Use the command kubectl create namespace <namespace-name> to create a Namespace

• kubectl create namespace <namespace-name>

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.

Task 2:

• Read about Services, Load Balancing, and Networking in Kubernetes.

• Services

  Basically, services are a type of resource that configures a proxy to forward the requests to a set of pods, which will receive traffic & is determined by the selector. Once the service is created it has an assigned IP address which will accept requests on the port.

  Now, there are various service types that give you the option for exposing a service outside of your cluster IP address.

  Types of Services

  There are mainly 4 types of services.

  ClusterIP: This is the default service type which exposes the service on a cluster-internal IP by making the service only reachable within the cluster.

  NodePort: This exposes the service on each Node’s IP at a static port. Since, a ClusterIP service, to which the NodePort service will route, is automatically created. We can contact the NodePort service outside the cluster.

  LoadBalancer: This is the service type which exposes the service externally using a cloud provider’s load balancer. So, the NodePort and ClusterIP services, to which the external load balancer will route, are automatically created.

  ExternalName: This service type maps the service to the contents of the externalName field by returning a CNAME record with its value.

The Kubernetes network model

• Every Pod in a cluster gets its own unique cluster-wide IP address. This means you do not need to explicitly create links between Pods and you almost never need to deal with mapping container ports to host ports.
  This creates a clean, backwards-compatible model where Pods can be treated much like VMs or physical hosts from the perspectives of port allocation, naming, service discovery, load balancing, application configuration, and migration.

  Kubernetes imposes the following fundamental requirements on any networking implementation (barring any intentional network segmentation policies):

  • pods can communicate with all other pods on any other node without NAT

  • agents on a node (e.g. system daemons, kubelet) can communicate with all pods on that node

Note: For those platforms that support Pods running in the host network (e.g. Linux), when pods are attached to the host network of a node they can still communicate with all pods on all nodes without NAT.

This model is not only less complex overall, but it is principally compatible with the desire for Kubernetes to enable low-friction porting of apps from VMs to containers. If your job previously ran in a VM, your VM had an IP and could talk to other VMs in your project. This is the same basic model.

Kubernetes IP addresses exist at the Pod scope - containers within a Pod share their network namespaces - including their IP address and MAC address. This means that containers within a Pod can all reach each other's ports on localhost. This also means that containers within a Pod must coordinate port usage, but this is no different from processes in a VM. This is called the "IP-per-pod" model.

How this is implemented is a detail of the particular container runtime in use.

It is possible to request ports on the Node itself which forward to your Pod (called host ports), but this is a very niche operation. How that forwarding is implemented is also a detail of the container runtime. The Pod itself is blind to the existence or non-existence of host ports.

Kubernetes networking addresses four concerns:

• Containers within a Pod use networking to communicate via loopback.

• Cluster networking provides communication between different Pods.

• The Service API lets you expose an application running in Pods to be reachable from outside your cluster.

  Ingress provides extra functionality specifically for exposing HTTP applications, websites and APIs.

• You can also use Services to publish services only for consumption inside your cluster.

Cluster Networking explains how to set up networking for your cluster, and also provides an overview of the technologies involved.

Service

Expose an application running in your cluster behind a single outward-facing endpoint, even when the workload is split across multiple backends.

Ingress

Make your HTTP (or HTTPS) network service available using a protocol-aware configuration mechanism, that understands web concepts like URIs, hostnames, paths, and more. The Ingress concept lets you map traffic to different backends based on rules you define via the Kubernetes API.

Ingress Controllers

In order for an Ingress to work in your cluster, there must be an ingress controller running. You need to select at least one ingress controller and make sure it is set up in your cluster. This page lists common ingress controllers that you can deploy.

EndpointSlices

The EndpointSlice API is the mechanism that Kubernetes uses to let your Service scale to handle large numbers of backends, and allows the cluster to update its list of healthy backends efficiently.

Network Policies

If you want to control traffic flow at the IP address or port level (OSI layer 3 or 4), NetworkPolicies allow you to specify rules for traffic flow within your cluster, and also between Pods and the outside world. Your cluster must use a network plugin that supports NetworkPolicy enforcement.

DNS for Services and Pods

Your workload can discover Services within your cluster using DNS.

• IPv4/IPv6 dual-stack

  Kubernetes lets you configure single-stack IPv4 networking, single-stack IPv6 networking, or dual stack networking with both network families active. This page explains how.

Thank you for reading!! Hope you find this helpful.

#day33#90daysofdevops#devopscommunity#

Always open for suggestions..!!