# Day 32 Task: Working with Namespaces and Services in Kubernetes.

1\. <mark>What is Namespace and how to work in kubernets.</mark>

In Kubernetes, *namespaces* provides 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](https://kubernetes.io/docs/concepts/overview/working-with-objects/#kubernetes-objects) *(e.g. Deployments, Services, etc)* and not for cluster-wide objects *(e.g. StorageClass, Nodes, PersistentVolumes, etc)*.

2. **<mark>Initial namespaces</mark>**

Kubernetes starts with four initial namespaces:

we can see the namepace in kubernetes culster

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1702833218724/71fb5026-f9cd-483b-98c8-6ef8658f0bc1.png align="center")

1\. **<mark>Default</mark>**

Kubernetes includes this namespace so that you can start using your new cluster without first creating a namespace.

2. **<mark>kube-node-lease</mark>**

This namespace holds [Lease](https://kubernetes.io/docs/concepts/architecture/leases/) objects associated with each node. Node leases allow the kubelet to send [heartbeats](https://kubernetes.io/docs/concepts/architecture/nodes/#heartbeats) so that the control plane can detect node failure.

3\. **<mark>kube-public</mark>**

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.

4.**<mark>kube-system</mark>**

The namespace for objects created by the Kubernetes system.

## <mark>Task 1:</mark>

<mark>1. Create a Namespace for your Deployment</mark>

we can create namespace using the command below mention

\# kubectl create namesapce &lt;namespace name&gt;

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1702833273870/0acddf07-74d2-45ec-bc59-55d7e57911a9.png align="center")

2\. <mark>Update the deployment.yml file to include the Namespace</mark>

we want to create a deployment creaet in particuler namepscae.so firstl we have write a deployment yml file for deployment.

* Apply the updated deployment using the command: `kubectl apply -f deployment.yml -n <namespace-name>`
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1702834052232/5f04c149-4731-4443-82c6-e1577d91f406.png align="center")

<mark>we can see that have create deployment in particular namespace</mark>

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1702834125069/19a06157-9f29-4ef4-b661-98dcb460327e.png align="center")

3.<mark>Verify that the Namespace has been created by checking the status of the Namespaces in your cluster.</mark>

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1702834225224/5a1347bb-5d7b-4b4c-bea2-6ac0ce30e4af.png align="center")

## <mark>Task 2:</mark>

;<mark>Read about Services, Load Balancing, and Networking in Kubernetes</mark>

1\. What is service in kubernetes and how to work

## **<mark>The Kubernetes network model</mark>**

***Every*** [`Pod`](https://kubernetes.io/docs/concepts/workloads/pods/) ***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***](https://kubernetes.io/docs/concepts/services-networking/ingress/#load-balancing)***, application configuration, and migration.***

##### [**Service**](https://kubernetes.io/docs/concepts/services-networking/service/)

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

##### [**Ingress**](https://kubernetes.io/docs/concepts/services-networking/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**](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/)

In order for an [Ingress](https://kubernetes.io/docs/concepts/services-networking/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.

##### [**Gateway API**](https://kubernetes.io/docs/concepts/services-networking/gateway/)

Gateway API is a family of API kinds that provide dynamic infrastructure provisioning and advanced traffic routing.

##### [**EndpointSlices**](https://kubernetes.io/docs/concepts/services-networking/endpoint-slices/)

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**](https://kubernetes.io/docs/concepts/services-networking/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.

Thanks for read my blog if you liked it this blog please like and commend.

Contact me on [**linkedin**](http://www.linkedin.com/in/pradeep-chitroliya-9347a9147)

check out my GitHub for more resource [**GitHub**](https://github.com/ChitrolyaPradeep)