🧠 What We’ll Cover About APIs (Developer + DevOps View)¶

📘 Let’s Begin From Layer 1: What’s an API, Technically?¶

🔧 Definition:¶

API (Application Programming Interface) is a set of rules + tools that lets software talk to each other.

• Like: "If you want this info, ask me like this, and I’ll answer in this format."
• It hides the internal details, and just gives you a way to communicate with the service.

⚒️ Protocols APIs Use (Layer 3)¶

Here’s how APIs “communicate”:

📬 What Is an API Request?¶

An API request has: - A method (GET, POST, PUT, DELETE) - A URL endpoint (/api/v1/namespaces) - Headers (like Content-Type) - A body (optional — for POST or PUT)

🧾 Example:¶

POST /api/v1/namespaces
Content-Type: application/json

{
  "metadata": {
    "name": "my-namespace"
  }
}

This means: "Create a new namespace with name my-namespace"

🏁 API Endpoints¶

Endpoints are URLs that represent a specific resource: - /api/v1/pods = All pods - /api/v1/namespaces/default/pods/nginx = A single Pod

Kubernetes uses these endpoints to let kubectl and other tools communicate with the cluster.

🧱 API Objects in Kubernetes¶

Every object like Pod, Service, Deployment, etc., is an API object.

They follow a structure like:

apiVersion: v1
kind: Pod
metadata:
  name: nginx

This is like saying:

“Hey API Server, here’s a Pod I want — follow this format to understand what I mean.”

🔐 8. Authentication & Authorization — “Can You Prove and Act?”¶

Imagine a Kubernetes cluster is like a secured building.

• Authentication (AuthN): Aap kaun ho? (ID card check)
• Authorization (AuthZ): Aap kya kar sakte ho? (Are you allowed to enter the server room?)

🔐 Authentication (Who are you?)¶

Kubernetes supports multiple ways to authenticate:

✅ Outcome: If authentication fails, request is rejected before hitting RBAC.

🛡️ Authorization (What are you allowed to do?)¶

Once you're authenticated, Kubernetes asks:

“Okay, now what do you want to do? And are you allowed?”

This is handled by Authorization modules, the most common being:

🧱 RBAC Breakdown:¶

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]

This rule states:

"Is user allowed to run kubectl get pods?"

If yes → allow
If no → reject with 403 Forbidden

🧩 9. CRDs (Custom Resource Definitions) — “Extend the API Itself”¶

Normally, Kubernetes has built-in objects like Pods, Services, Deployments.

But what if you want your own object, like:

• apiVersion: mycompany.com/v1
• kind: GitRepo
• kind: KafkaCluster

Then you create a CRD — this is like teaching Kubernetes a new word.

💡 What Happens When You Create a CRD?¶

1. A new REST endpoint is created on the API server
2. e.g., /apis/mycompany.com/v1/gitrepos
3. Now you can POST custom objects to that endpoint — just like built-in resources.

It’s like:

"Ibtisam taught Kubernetes a new language, and now Kubernetes understands how to deal with that kind of object."

This powers tools like: - cert-manager - ArgoCD - Prometheus Operator

All use CRDs to extend Kubernetes!

🧠 10. kubeadm API — “Internal Blueprint Used During Cluster Setup”¶

When you use kubeadm init, behind the scenes, kubeadm uses its own internal API schema to understand how to build the cluster.

📦 Key API Kinds in kubeadm:¶

🔧 Example:¶

apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
kubernetesVersion: v1.28.0
networking:
  podSubnet: "192.168.0.0/16"

Yeh batata hai:

"Cluster kis version ka hoga, networking ka layout kya hoga, control-plane components ka config kya hoga"

Yeh config file API server ko nahi — kubeadm CLI tool ko bataya jata hai taake woh use kare during cluster bootstrap.

Wah bhai Ibtisam — perfect question!
Let’s now connect the entire 10-layer model logically, step-by-step like a chain reaction — where each piece relies on the previous one, in an actual cluster environment context.
Main isko ek process pipeline ki tarah bataata hoon, jaise real system ka data flow hota hai.

📊 How All 10 API Layers Connect Together (Complete Picture)¶

📍 The Big Picture:¶

When you interact with Kubernetes (via kubectl, kubeadm, or API call) —
this is the exact process happening behind the scenes:

Step 1️⃣: Basic Concept — What Is an API?¶

API = Ek defined rulebook + language jo bataata hai ke system se kis format mein baat karni hai aur kya expect karna hai.
In Kubernetes, the API Server is the central middleman jo ye rules enforce karta hai.

“Jo bhi request cluster mein aayegi — pehle API Server se guzregi.”

Step 2️⃣: API Types — REST, gRPC, CRDs¶

• Kubernetes uses REST API for cluster communication (kubectl get pods etc.)
• Internal components (kubelet, etcd, controller-manager) talk via gRPC
• CRDs extend the API — making your own custom objects.

🧩 Yahan tak: Ye bataya gaya ke kaunsi API type kis kaam ke liye hoti hai

Step 3️⃣: Protocols — HTTP, HTTPS, JSON, YAML, Protobuf¶

• kubectl uses HTTPS to talk to API Server
• Data format: JSON / YAML
• Internally: gRPC uses Protobuf (faster, binary)

🧩 Ab decide ho gaya: kis protocol se kis format mein baat karni hai

Step 4️⃣: API Request/Response — Method + Endpoint¶

When you run:

kubectl get pods

"API Server, batao mujhe pods ki list."

🧩 Yahan se API Server pe request pohnchti hai

Step 5️⃣: API Endpoints¶

Every object has a REST endpoint: - /api/v1/pods - /apis/apps/v1/deployments - /apis/custom.io/v1/myresource

🧩 API Server dekhta hai — is endpoint ka handler kahan hai

Step 6️⃣: API Objects¶

Request mein jo resource likha hota hai (Pod, Service, Deployment)
Woh ek API Object hota hai — JSON/YAML mein defined, like:

apiVersion: v1
kind: Pod

🧩 API Server dekhta hai yeh object built-in hai ya custom

Step 7️⃣: API Server Core Role¶

API Server acts as: - Gatekeeper: Sab requests yahin se guzarti hain - Router: Decide karta hai kya karna hai

🧩 Ab request validate hogi

Step 8️⃣: Authentication (AuthN)¶

API Server checks:

"Yeh aadmi kaun hai? (TLS, Token, Cert check karega)"

If invalid: Reject with 401 Unauthorized
If valid: Move to next step

Step 9️⃣: Authorization (AuthZ)¶

API Server checks:

"Yeh aadmi yeh kaam kar sakta hai ya nahi?" (RBAC ya policy check)

If unauthorized: Reject with 403 Forbidden
If allowed: Move to next step

Step 🔟: Built-in / CRD / kubeadm API¶

Now API Server decides:

• Built-in object → Process normally, store in etcd
• CRD object → Use registered CRD logic
• kubeadm API object → Used internally by kubeadm to build the cluster

For kubeadm: - When you run kubeadm init --config file.yaml - kubeadm parses the ClusterConfiguration, InitConfiguration from file - Sends required kubelet certs and configs to the API Server - Bootstraps control-plane components

🧩 Final action complete

✅ Summary Table: Layerwise Chain¶

🖼️ Final Visual: Full Flow¶

kubectl / kubeadm
      │
      │  HTTPS/JSON/gRPC
      ▼
  API Server
      │
      │--> AuthN (TLS, Token)
      │--> AuthZ (RBAC)
      │
      │--> Built-in Object   (handle normally)
      │--> CRD               (custom controller)
      │--> kubeadm API       (bootstrap logic)
      │
    etcd (store final state)

🎯 Conclusion:¶

✔ All 10 layers form a single connected pipeline
✔ Every layer depends on the result of the previous one
✔ Without clearing any one step — the process halts

Yehi Kubernetes ka API process lifecycle hai, jiska solid grasp aapko CKA exam aur real production clusters mein top 1% DevOps engineer banata hai.