Code10x

Ek container orchestration platform hai — multiple machines ke upar containers ko deploy, scale, aur manage karne ke liye design kiya gaya hai.

Kyunki K aur s ke beech mein exactly 8 letters hain (ubernete) — ye ek common numeronym convention hai.

API Server (saari requests ka entry point), etcd (cluster ki state store karta hai), Scheduler (batata hai kaunsa pod kaunse node par jaayega), aur Controller Manager (desired state maintain karta hai).

kubelet (node par containers manage karne waala agent), kube-proxy (networking rules maintain karta hai), aur container runtime (jaise containerd).

Poore cluster ki state store karta hai — kaunsa pod exist karta hai, uski config kya hai, sab kuch etcd mein hai. Isliye iska regular backup critical hai.

Kubernetes ka command-line tool hai jo API Server se communicate karta hai — cluster ke resources ko create, view, update aur delete karne ke liye use hota hai.

Imperative (jaise "kubectl create deployment") directly ek action tell karta hai. Declarative ("kubectl apply -f file.yaml") desired state define karta hai — production mein declarative approach recommend ki jaati hai.

Minikube ek VM ke andar single-node cluster khada karta hai (learning ke liye best). Kind Docker containers ko nodes ki tarah use karke multi-node cluster simulate karta hai — CI/CD mein popular.

Control plane (API Server, etcd, Scheduler) ko cloud provider khud manage karta hai — sirf worker nodes aur applications ki chinta karni padti hai.

Kubernetes ki smallest deployable unit hai — ek ya multiple containers jo same IP, network, aur storage volumes share karte hain.

Sidecar pattern ke liye — jaise ek main application container ke saath ek logging ya monitoring helper container, jo same lifecycle aur networking share karta hai.

Ye main containers se pehle run hote hain aur complete hone tak main containers start nahi hote — setup tasks (jaise database migration) ke liye useful hain.

Pending (scheduled ho raha hai), Running (kam se kam ek container chal raha hai), Succeeded (saare containers complete ho gaye), aur Failed (containers error ke saath exit hue).

Container baar-baar crash ho raha hai aur Kubernetes restart ke beech ka wait time exponentially badha raha hai.

Kyunki pods ephemeral (temporary) hote hain — agar ek pod die ho jaaye to Kubernetes use restart nahi karta, naya pod banata hai. Isliye Deployments use kiye jaate hain jo pods ko manage karte hain.

Ek unique cluster-internal IP address — pod delete hone par ye IP kho jaata hai, naya pod banne par naya IP milta hai.

Kyunki pod restart/recreate hone par IP change ho jaata hai — isliye Services ke stable DNS naam use karna reliable hota hai, direct IP nahi.

Same IP address, same port space, aur same storage volumes — ye ek doosre se "localhost" par hi talk kar sakte hain.

Ek higher-level object hai jo ReplicaSets ko manage karta hai jo aage pods ko manage karte hain — desired state (image, replicas, update strategy) define karke Kubernetes use maintain karta hai.

Ek specified number of identical pod replicas ko hamesha running rakhne ki guarantee — ek pod crash hone par turant ek replacement pod banata hai.

Kyunki Deployments hi ReplicaSets ko automatically manage karte hain — Deployment banate waqt ek ReplicaSet automatically create ho jaata hai.

Kyunki databases ko stable unique network identity aur stable persistent storage chahiye — har pod ko predictable naam (pod-0, pod-1) aur apna persistent volume milta hai.

StatefulSet pods predictable naam use karte hain (postgres-0, postgres-1). Deployment pods random hash suffix use karte hain (jaise nginx-7d9f8c-x2k9p).

Ensure karta hai ki cluster ke har (ya kuch selected) node par exactly ek copy of ek pod chale — naye nodes join karne par automatically pod add ho jaata hai.

Log collection agents (Fluentd), monitoring agents (node-exporter), aur networking/storage plugins jinhe har node par run hona zaroori hai.

Gradually purane pods ko naye pods se replace karti hai — ek time par sirf kuch pods update hote hain, isliye hamesha kuch pods traffic handle karne ke liye available rehte hain.

Kyunki count automatically node count ke equal hoti hai — har node ke liye exactly ek pod, koi manual replica count set nahi karni padti.

Ek stable network endpoint (fixed IP + DNS naam) provide karta hai poore set of pods ke liye — pods create/destroy hote rahein, Service address hamesha same rehta hai.

Label selectors ke zariye — jaise "app: nginx" label waale saare pods ek hi Service ke peeche group ho jaate hain.

ClusterIP sirf cluster ke andar accessible hai (default). NodePort har node ke specific port (30000-32767) par expose karta hai. LoadBalancer cloud provider se external load balancer provision karta hai.

Ek API object hai jo cluster ke andar ki services ke liye HTTP/HTTPS routing rules define karta hai — hostname ya path ke basis par traffic ko different services tak route karta hai.

Ek "Ingress Controller" (jaise nginx-ingress ya Traefik) install karna zaroori hai — Ingress khud kuch nahi karta, controller hi actual traffic handle karta hai.

Kyunki cloud providers har LoadBalancer ke liye separate bill karte hain — ek hi Ingress se saari HTTP routing handle ho sakti hai, much cheaper.

Ek automatic DNS entry — "my-service" naam ki Service "my-service.my-namespace.svc.cluster.local" se accessible ho jaati hai, same namespace mein sirf "my-service" se.

Kubernetes ka default DNS server hai — ye cluster ke andar saari DNS queries handle karta hai, jaise Service naam ko unke IP se resolve karna.

Kyunki local clusters mein koi cloud provider nahi hota jo actual external load balancer provision kar sake.

Non-sensitive configuration data (jaise environment naam, feature flags, API URLs) ko key-value pairs ki tarah store karta hai — application code se config ko separate karta hai.

ConfigMap non-sensitive data ke liye hai. Secret sensitive data (passwords, API tokens) ke liye hai, base64-encoded, aur Kubernetes extra precautions leta hai isse handle karne mein.

Nahi — base64 encoding hai, encryption nahi. Koi bhi base64 decode kar sakta hai. Real security ke liye encryption at rest aur RBAC access restriction zaroori hai.

Ek cluster-level storage resource hai jo admin provision karta hai (ya dynamically provision hota hai) — pod ke lifecycle se independent hai.

Ek user's request for storage hai — pod directly PV ko reference nahi karta, ek PVC ke zariye storage maangta hai. Kubernetes khud ek suitable PV ko PVC se bind kar deta hai.

Dynamic provisioning ko automate karta hai — PVC request aane par PV automatically create ho jaata hai, cloud provider ke saath integrate hokar.

ReadWriteOnce = ek node se hi mount. ReadOnlyMany = multiple nodes se read-only. ReadWriteMany = multiple nodes se ek saath read-write (jaise NFS).

Kyunki environment variables container start hone par set ho jaate hain — ConfigMap update hone par pod ko restart karna padta hai, values automatically refresh nahi hoti.

Har unscheduled pod ke liye best node dhoondta hai — node's available resources, pod's requirements, affinity rules, aur taints/tolerations sab consider karta hai.

requests = minimum guaranteed resources jo Scheduler ke liye use hota hai. limits = maximum allowed usage — isse zyada use nahi kar sakta container.

Container OOM-killed ho jaata hai — Linux kernel ka Out-Of-Memory killer process ko kill kar deta hai.

Container kill nahi hota — bas throttle (slow) ho jaata hai, kyunki CPU "compressible" resource hai jabki memory "incompressible" hai.

Deployment/ReplicaSet ke replicas count ko automatically adjust karta hai metrics (usually CPU/memory utilization) ke basis par — traffic badhne par more pods, ghatne par kam pods.

"metrics-server" — ye hi CPU/memory metrics provide karta hai jispe HPA decisions leta hai.

Taint node par lagaya jaata hai aur pods ko repel karta hai. Toleration pod mein hoti hai jo use taint waale node par jaane deti hai — dono opposite direction se kaam karte hain.

Taint "most pods yahan mat aane do" batata hai. Affinity "mera pod sirf yahan hi jaane do" batata hai — dono opposite directions se scheduling control karte hain.

Kubernetes ka package manager hai — multiple related YAML files ko ek single "Chart" mein package karta hai jise ek hi command se install kiya ja sakta hai.

Chart.yaml (metadata), values.yaml (default configuration values), aur templates/ folder (actual Kubernetes YAML templates).

"helm install" ke waqt "-f custom-values.yaml" ya "--set key=value" flags se — ek hi chart se different environments ke liye different configs use ho sakti hain.

Go templating language — "{{ .Values.replicaCount }}" jaisi syntax se values.yaml ki values YAML mein inject ki jaati hain.

Actual generated YAML ko dikhata hai bina kuch install kiye — debugging ke liye useful hai install karne se pehle preview karna.

Ek nayi "release revision" — Helm poori history maintain karta hai ki kaunsi values kaunse time par deploy hui thi.

Kisi bhi previous revision par instantly wapas le jaata hai — ek bad deployment se recover karne ka sabse fast way hai.

Helm 3 ne Tiller (Helm 2 ka server-side component) hata diya — ab Helm directly Kubernetes API se talk karta hai, security aur simplicity dono improve hui.

"version" chart ka own version hai. "appVersion" application ka version hai jo chart deploy karta hai — dono independently change ho sakte hain.

Container ke stdout/stderr output ko real-time mein stream karta hai, jab tak manually stop na kiya jaaye.

"-c container-name" flag se — jaise "kubectl logs my-pod -c sidecar-container".

Ek crashed container ke purane (previous instance ke) logs dikhata hai — CrashLoopBackOff debug karne ke liye bahut useful.

Ye recent happenings (image pull hua, scheduled hua, restart hua) ki timeline dikhata hai — debugging ke liye first place hai dekhne ka.

Ya to image naam galat hai ya private registry ke liye credentials missing hain (imagePullSecrets add karna padega).

Container restart ho jaata hai — Kubernetes maan leta hai ki application unhealthy state mein phas gayi hai jise sirf restart hi fix kar sakta hai.

Container restart nahi hota — bas Service ki traffic routing se us pod ko hataya jaata hai, jab tak wo dobara ready na ho jaaye.

Un applications ke liye jinka startup time unpredictable ya long hai — jab tak startup probe succeed nahi hoti, liveness/readiness probes disable rehte hain taaki slow-starting apps restart na ho jaayein.

Ek running pod mein ek temporary "ephemeral container" add karta hai debugging tools ke saath — useful hai jab main container ke image mein koi debugging tools nahi hain.

Role-Based Access Control — decide karta hai ki kaun (user ya service account) kaunse Kubernetes resources par kya actions (get, list, create, delete) perform kar sakta hai.

Role ek specific namespace ke andar permissions define karta hai. ClusterRole poore cluster ke liye permissions define karta hai.

Ek Role ko ek user/service-account se attach karta hai — Role akela kuch nahi karta jab tak use bind na kiya jaaye.

Pods/applications ke liye identity provide karta hai — har pod ek service account ke saath run hota hai (agar specify nahi kiya to "default" service account use hota hai).

Ek single cluster ko multiple virtual clusters mein divide karta hai — different teams ya environments (dev, staging, prod) ke resources ko isolate karne ke liye useful hai.

Saare pods ek doosre se freely talk kar sakte hain — koi isolation nahi hai by default.

Rules define karta hai ki kaunse pods kaunse doosre pods se (ya kaunse external IPs se) talk kar sakte hain — label selectors use karke.

Cluster ka CNI (Container Network Interface) plugin isse support karta hona zaroori hai — har CNI (jaise Calico) support nahi karta.

Deployment ko pichle working version par instantly rollback karta hai — Deployment purane ReplicaSets ko yaad rakhta hai isi liye ye possible hai.

Ensure karta hai ki voluntary disruptions (jaise node maintenance) ke daura ek minimum number of pods hamesha available rahein.

Resource requests/limits (predictable scheduling), liveness/readiness probes (automatic healing), aur multiple replicas (single point of failure avoid karne ke liye).