🔥Virtual cluster inside a K8S cluster 🔥

🌟Let's understand the concept of virtual cluster inside a "physical cluster in K8S !!"🌟

When we are working with a large account/organization we generally come across different types of teams/applications but everything in a single large cluster???? sounds make it very difficult to even imagine. What if we have an isolation between all those and draw some boundaries, set limits and organize?,

There comes a topic called "𝑵𝒂𝒎𝒆𝑺𝒑𝒂𝒄𝒆"

✨ What is it ?
1️⃣ It is a K8S object which creates virtual clusters inside the physical cluster

2️⃣ It is a way to divide one physical/main cluster into multiple virtual clusters and provides logical boundaries within the cluster and isolates the resources from being mismanaged.

Why do we need Namespaces?
1️⃣ Teams/projects can use the same cluster without interfering eachother.
2️⃣ Makes it easier to group resources like pods/SVC/configMaps.. logically.
3️⃣ We can manage clusters with thousands of resources easily.
4️⃣ It will Allow us to manage permissions and access controls and restrict the access to specific resources.

---

🌟 How NameSpace(NS) work in K8S?
1️⃣ Resource Scope:
✅ NS are applied to namespaced objects like Pods,SVC's, configMaps & Secrets.
✅ Some resources like Nodes & Persistent volumes are cluster wide, not namespaced.
✅ Resources with same name can exist in different NS without conflict.

2️⃣ CPU & Memory limits:
✅ we can restrict/set boundaries that how much amount of resources can be consumed.
✅ we can restrict how many resources can be inside the created Namespace ( ex: 5 pods/10pods).

3️⃣ Managing NS:
✅ It is always ideal to manage the NS with manifest files instead of commands for better flexibility, re-use, simple management and changes are predicted and documented.

4️⃣ Default NameSpaces: (important)❗

✅ 𝑫𝒆𝒇𝒂𝒖𝒍𝒕: Used when we don't mention any specific namespace.
✅𝑲𝒖𝒃𝒆-𝒔𝒚𝒔𝒕𝒆𝒎: Contains critical system components like kube-dns & other controllers. ( Restricted to use until you know what you are doing).
✅ 𝑲𝒖𝒃𝒆-𝒑𝒖𝒃𝒍𝒊𝒄: Commonly used for cluster-level configuration/information which are meant to be publicly accessible accross the cluster.
✅ 𝑲𝒖𝒃𝒆-𝒏𝒐𝒅𝒆-𝒍𝒆𝒂𝒔𝒆: Used to manage the heartbeats of nodes for the node controller.

5️⃣ ResourceQuotas and LimitRanges:

✅ 𝑹𝒆𝒔𝒐𝒖𝒓𝒄𝒆𝑸𝒖𝒐𝒕𝒂: Enforce overall usage limits for the Namespace ( ex: total CPU/memory/no. of pods can be created).

✅ 𝑳𝒊𝒎𝒊𝒕𝑹𝒂𝒏𝒈𝒆𝒔: Define per-resource limits within the Namespace ( ex: max& min CPU/memory per pod/container).

---

Use Cases:
✨ Large organisations with multiple teams/applications.
✨ managing different environments with in same cluster ( dev/stage/prod)
✨ when permissions and limits required.

Note📝: In detail information of ResourceQuota, LimitRange, Pros, Cons and best practices given in image format.

Comment down your thoughts 💭