बिज़नेस एप्लिकेशन के लिए Kubernetes की बुनियादी बातें

लेख का मुख्य भाग

बिज़नेस एप्लिकेशन के लिए Kubernetes की बुनियादी बातें

बिज़नेस टीमों के लिए Kubernetes का एक व्यावहारिक, बिना किसी लाग-लपेट वाला परिचय: मुख्य ऑब्जेक्ट क्या करते हैं, एक काम करने वाला डिप्लॉयमेंट जिसे आप कॉपी कर सकते हैं, और PDPL डेटा रेज़िडेंसी के लिए इसे इन-किंगडम Skyline Cloud इन्फ्रास्ट्रक्चर पर कैसे चलाएँ।

By SKYLINE Engineering | प्रकाशित Jun 8, 2026 | 6 मिनट का पठन

बिज़नेस एप्लिकेशन के लिए Kubernetes की बुनियादी बातें

Kubernetes (जिसे अक्सर संक्षेप में "K8s" कहा जाता है) प्रोडक्शन में कंटेनराइज़्ड एप्लिकेशन चलाने का मानक है। एक बिज़नेस के लिए इसका मूल्य ठोस है: जब कोई सर्वर फेल हो जाता है तब यह आपके ऐप को चालू रखता है, लोड के तहत इसे स्केल कर देता है, बिना डाउनटाइम के नए वर्शन रोल आउट करता है, और आपकी टीम को एक बिलिंग API से लेकर कस्टमर पोर्टल तक हर चीज़ को संचालित करने का एक सुसंगत तरीका देता है।

यह ट्यूटोरियल मुख्य बिल्डिंग ब्लॉक समझाता है, एक वास्तविक डिप्लॉयमेंट के बारे में बताता है जिसे आप कॉपी कर सकते हैं, और दिखाता है कि इसे इन-किंगडम इन्फ्रास्ट्रक्चर पर कैसे चलाएँ ताकि आपका डेटा सऊदी PDPL, NCA और SDAIA की आवश्यकताओं के अधीन बना रहे।

कोई बिज़नेस Kubernetes का उपयोग क्यों करेगा

किसी एक छोटी वेबसाइट के लिए आपको Kubernetes की ज़रूरत नहीं है। आपको इसकी ज़रूरत तब महसूस होने लगती है जब आपके पास कई सर्विसेज़, कई एनवायरनमेंट, या अपटाइम की बाध्यताएँ हों। इसके व्यावहारिक लाभ ये हैं:

• सेल्फ-हीलिंग: क्रैश हुआ कंटेनर अपने-आप फिर से चालू हो जाता है; एक अस्वस्थ नोड को ड्रेन कर दिया जाता है।
• हॉरिज़ॉन्टल स्केलिंग: ट्रैफ़िक के अचानक उछाल को संभालने के लिए रेप्लिका जोड़ें, फिर वापस कम कर लें।
• ज़ीरो-डाउनटाइम रिलीज़: रोलिंग अपडेट पुराने पॉड्स को धीरे-धीरे बदलते हैं और फेल होने पर रोलबैक कर देते हैं।
• पोर्टेबिलिटी: वही मेनिफ़ेस्ट आपके लैपटॉप, टेस्ट क्लस्टर और प्रोडक्शन पर चलते हैं।

मुख्य ऑब्जेक्ट, सरल शब्दों में

Kubernetes में हर चीज़ एक डिक्लेरेटिव ऑब्जेक्ट है जिसे आप YAML में वर्णित करते हैं। क्लस्टर लगातार काम करता रहता है ताकि वास्तविकता उससे मेल खाए जो आपने घोषित किया है।

आप पॉड्स को सीधे शायद ही कभी बनाते हैं। आप एक Deployment बनाते हैं, और वह आपके लिए पॉड्स को प्रबंधित करता है।

एक काम करने वाला उदाहरण

यहाँ एक सर्विस के पीछे एक स्टेटलेस वेब ऐप का पूर्ण, न्यूनतम डिप्लॉयमेंट है। इसे app.yaml के रूप में सेव करें।

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  labels:
    app: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: nginx:1.27
          ports:
            - containerPort: 80
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "250m"
              memory: "256Mi"
          readinessProbe:
            httpGet:
              path: /
              port: 80
            initialDelaySeconds: 3
            periodSeconds: 5
---
apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 80
  type: ClusterIP

यहाँ दो बातें समझने लायक हैं। selector फ़ील्ड वह तरीका है जिससे Deployment और Service अपने पॉड्स को ढूँढ़ते हैं: वे app: web लेबल पर मेल खाते हैं, न कि नामों पर। और readinessProbe Kubernetes को बताता है कि किसी पॉड को तब तक ट्रैफ़िक न भेजे जब तक वह वास्तव में पोर्ट 80 पर जवाब न दे — यही चीज़ रोलिंग अपडेट को सुरक्षित बनाती है।

इसे लागू करें और इसे कन्वर्ज होते हुए देखें:

kubectl apply -f app.yaml
kubectl get pods -l app=web
kubectl rollout status deployment/web

आप तीन पॉड्स को Running तक पहुँचते देखेंगे। सेल्फ-हीलिंग को कार्य करते देखने के लिए किसी एक को खत्म कर दें:

kubectl delete pod -l app=web --field-selector=status.phase=Running --grace-period=0 | head -1
kubectl get pods -l app=web   # एक रिप्लेसमेंट पहले से ही बनाया जा रहा है

स्केलिंग और सुरक्षित रिलीज़

स्केलिंग एक ही पंक्ति का काम है, और यह वही कमांड है जिसे आप बाद में ऑटोमेट करेंगे:

kubectl scale deployment/web --replicas=6

एक नया वर्शन शिप करने के लिए, image बदलें और Kubernetes एक रोलिंग अपडेट करता है — नए पॉड्स को चालू करके और पुराने पॉड्स को तभी हटाकर जब नए वाले अपना रेडीनेस प्रोब पास कर लेते हैं:

kubectl set image deployment/web web=nginx:1.27.1
kubectl rollout status deployment/web
# अगर कुछ गलत है:
kubectl rollout undo deployment/web

प्रोडक्शन ट्रैफ़िक पैटर्न के लिए, एक HorizontalPodAutoscaler जोड़ें ताकि क्लस्टर CPU के आधार पर अपने-आप रेप्लिका जोड़े:

kubectl autoscale deployment/web --min=3 --max=10 --cpu-percent=70

कॉन्फ़िगरेशन और सीक्रेट्स

कॉन्फ़िगरेशन को अपने image से बाहर रखें। इसे रनटाइम पर इंजेक्ट करें:

kubectl create configmap web-config --from-literal=APP_ENV=production
kubectl create secret generic web-secret --from-literal=DB_PASSWORD='change-me'

फिर उन्हें पॉड स्पेक में envFrom के साथ संदर्भित करें। इससे वही image staging और production में बिना बदले चल पाता है, जबकि क्रेडेंशियल्स अलग से प्रबंधित होते हैं और कभी भी बिल्ड में नहीं बेक किए जाते।

इसे किंगडम के भीतर चलाना

सऊदी और GCC बिज़नेस के लिए, क्लस्टर कहाँ चलता है यह उतना ही मायने रखता है जितना कि वह कैसे चलता है। PDPL के तहत, सऊदी निवासियों के व्यक्तिगत डेटा को आम तौर पर डेटा विषय की अपेक्षाओं और लागू ट्रांसफ़र नियमों को ध्यान में रखते हुए प्रोसेस किया जाना चाहिए, और NCA/SDAIA फ़्रेमवर्क रेगुलेटेड वर्कलोड को इन-किंगडम होस्टिंग की ओर धकेलते हैं। अपने नोड्स, परसिस्टेंट वॉल्यूम और बैकअप को सऊदी डेटा सेंटर के भीतर चलाने से वह डेटा स्थानीय रूप से रेज़िडेंट रहता है और ऑडिट सरल हो जाते हैं।

Skyline Cloud एक इन-किंगडम प्रदाता है, इसलिए आप किंगडम के भीतर क्लाउड सर्वर और VPS पर Kubernetes वर्कर नोड्स चला सकते हैं, परसिस्टेंट वॉल्यूम और बैकअप के लिए इन-किंगडम ब्लॉक और ऑब्जेक्ट स्टोरेज अटैच कर सकते हैं, और जब रात 2 बजे कुछ खराब हो जाए तो एक स्थानीय अरबी-भाषी टीम तक पहुँच सकते हैं। अगर आपका एप्लिकेशन कस्टमर नोटिफ़िकेशन या रसीदें भी भेजता है, तो इसे उसी इन-किंगडम फ़ुटप्रिंट पर बिज़नेस ईमेल होस्टिंग के साथ जोड़ने से वह डेटा भी रेज़िडेंट बना रहता है। मैनेज्ड क्लस्टर और ऑपरेशनल मॉडल पर गहराई से जानने के लिए, हमारा सऊदी अरब में मैनेज्ड Kubernetes हब देखें।

अधिकांश बिज़नेस के लिए एक समझदारी भरा पहला क्लस्टर तीन छोटे वर्कर नोड्स हैं: किसी नोड के फेल होने पर भी बने रहने और बिना अधिक खर्च किए रोलिंग अपडेट को यथार्थवादी ढंग से टेस्ट करने के लिए पर्याप्त।

एक व्यावहारिक शुरुआती चेकलिस्ट

1. पहले एक स्टेटलेस सर्विस को कंटेनराइज़ करें; शुरुआत के लिए डेटाबेस को मैनेज्ड स्टोरेज पर ही छोड़ दें।
2. ऊपर दिए उदाहरण की तरह एक Deployment + Service लिखें और एक साफ़ rollout status प्राप्त करें।
3. रेडीनेस प्रोब और रिसोर्स requests/limits जोड़ें — यही वे चीज़ें हैं जो क्लस्टर को सही ढंग से व्यवहार करवाती हैं।
4. कॉन्फ़िग को ConfigMaps और Secrets में स्थानांतरित करें।
5. बुनियादी बातें स्थिर हो जाने के बाद एक ऑटोस्केलर और एक Ingress जोड़ें।

Skyline Cloud पर शुरुआत करें

आप वर्कर नोड्स खड़े कर सकते हैं, इन-किंगडम स्टोरेज अटैच कर सकते हैं, और मिनटों में अपने डेटा को सऊदी अधिकार-क्षेत्र के अधीन रख सकते हैं। अपना Skyline Cloud अकाउंट बनाएँ और स्थानीय सहायता के साथ अपना पहला क्लस्टर डिप्लॉय करें।