सेवा भेजने के लिए जरूरी कुबेरनेटीस अवधारणाएँ

सेवा भेजने के लिए कुबेरनेटीस का हर ऑब्जेक्ट नहीं चाहिए। क्लस्टर पर उतरने वाली ज़्यादातर प्रोडक्शन एपीआई एक ही छोटा स्टैक इस्तेमाल करती हैं: कंटेनर चलाने वाला पॉड, सही संख्या में पॉड जीवित रखने वाला डिप्लॉयमेंट, स्थिर नेटवर्क नाम देने वाली सर्विस, बाहर से एचटीटीपी स्वीकार करने वाला इंग्रेस (या गेटवे), प्लेटफ़ॉर्म को सुरक्षित ट्रैफिक का समय बताने वाले प्रोब, और सेटिंग/क्रेडेंशियल के लिए कॉन्फ़िगमैप / सीक्रेट।

यही व्यावहारिक रास्ता है। बाकी सब (जॉब, क्रॉनजॉब, स्टेटफुलसेट, नेटवर्कपॉलिसी, सीआरडी) तब तक रुक सकता है जब तक पहली सेवा स्वस्थ न हो।

मानसिक मॉडल

परतों में सोचें, नीचे से ऊपर:

Internet
   |
 Ingress  (HTTP routing, TLS termination)
   |
 Service  (stable DNS + load balance across Pods)
   |
 Deployment  (desired replicas, rollouts, rollback)
   |
 Pod(s)  (one or more containers + volumes + probes)
   |
 ConfigMap / Secret  (injected as env or files)

क्लस्टर नेटवर्किंग, नोड और कंट्रोल प्लेन इसके नीचे हैं। टूटने पर वे मायने रखते हैं। पहले दिन ऊपर वाला स्टैक मायने रखता है।

दर्द बचाने वाला एक नियम: पॉड बदला जा सकता है। कभी लोड बैलेंसर को पॉड आईपी पर न लगाएँ। सर्विस पर लगाएँ। डिप्लॉयमेंट हर रोलआउट पर नए पॉड बनाता है; आईपी बदलती हैं।

पॉड: जो वास्तव में चलता है

पॉड सबसे छोटी डिप्लॉय करने योग्य इकाई है। एक पॉड आमतौर पर एक मुख्य कंटेनर (आपका ऐप) चलाता है। साइडकार वैकल्पिक हैं।

प्रोडक्शन में शायद ही हाथ से पॉड बनाते हैं। कंट्रोलर (डिप्लॉयमेंट) से बनते हैं। फिर भी पॉड टेम्पलेट में यही जाता है:

कंटेनर इमेज और कमांड
पोर्ट
एनवायरनमेंट वेरिएबल
वॉल्यूम माउंट
रिसोर्स रिक्वेस्ट/लिमिट
प्रोब

प्रोसेस निकल जाए तो पॉड मरता है। रिस्टार्ट पॉलिसी और डिप्लॉयमेंट तय करते हैं आगे क्या हो।

डिप्लॉयमेंट: वांछित संख्या और सुरक्षित रोलआउट

डिप्लॉयमेंट कहता है: "इस पॉड टेम्पलेट की एन प्रतियाँ चाहिए, और रोलआउट नियंत्रित चाहिए।"

मुफ़्त में मिलता है:

रेप्लिका: १ से एन तक स्केल
रोलिंग अपडेट: पुराने गिरने से पहले नए पॉड आते हैं (सर्ज/अनअवेलेबल सीमा के भीतर)
रोलबैक: पिछला रेप्लिकासेट कुछ समय रहता है
सेल्फ-हील: नोड मर जाए तो कंट्रोलर कहीं और रिप्लेसमेंट शेड्यूल करता है

बिना डिप्लॉयमेंट (या मिलते-जुलते कंट्रोलर) के मरा पॉड मरा रहता है। एक बार के डिबग पॉड के लिए ठीक। सेवा के लिए नहीं।

जल्दी मायने रखने वाले न्यूनतम नॉब:

replicas: 2 (या ज़्यादा) जब नोड फेलियर की चिंता हो
resources.requests ताकि शेड्यूलर जगह दे सके
रेडीनेस प्रोब ताकि रोलआउट में सर्विस ठंडे पॉड पर ट्रैफिक न भेजे

सर्विस: क्लस्टर के अंदर स्थिर नाम

सर्विस लेबल से पॉड चुनती है और स्थिर वर्चुअल आईपी तथा डीएनएस नाम देती है।

एचटीटीपी ऐप का आम पैटर्न:

पॉड लेबल: app: billing-api
सर्विस सिलेक्टर: app: billing-api
सर्विस प्रकार: ClusterIP (डिफ़ॉल्ट)
टारगेटपोर्ट: कंटेनर पोर्ट (जैसे 8080)

क्लस्टर के अंदर दूसरे वर्कलोड http://billing-api:8080 (या नेमस्पेस-क्वालीफ़ाइड डीएनएस) पर कॉल करते हैं। उन्हें पॉड आईपी कभी नहीं चाहिए।

एक पंक्ति में सर्विस प्रकार:

प्रकार	कब इस्तेमाल करें
क्लस्टरआईपी	सिर्फ़ अंदरूनी (ज़्यादातर माइक्रोसर्विस)
नोडपोर्ट	लोड बैलेंसर के बिना तेज़ बाहरी पहुँच (लैब, कुछ बेयर मेटल)
लोडबैलेंसर	क्लाउड इस सर्विस के लिए बाहरी एलबी बनाता है
एक्सटर्नलनेम	क्लस्टर के बाहर किसी चीज़ का डीएनएस उपनाम

ब्राउज़र या सार्वजनिक एपीआई ट्रैफिक के लिए लोग अक्सर प्रति ऐप लोडबैलेंसर के बजाय क्लस्टरआईपी सर्विस के आगे इंग्रेस लगाते हैं (जब तक प्लेटफ़ॉर्म मानक कुछ और न कहे)।

इंग्रेस: बाहर की दुनिया से एचटीटीपी

इंग्रेस वह एपीआई ऑब्जेक्ट है जो एचटीटीपी(एस) रूटिंग बताता है: होस्ट, पाथ, बैकएंड सर्विस। इंग्रेस कंट्रोलर (एनजिनएक्स, ट्रैफ़िक, क्लाउड कंट्रोलर, आदि) उसे असली कॉन्फ़िग बनाता है।

स्केच:

api.example.com/billing  ->  Service billing-api:80  ->  Pods on 8080
api.example.com/users    ->  Service users-api:80    ->  Pods on 8080

टीएलएस अक्सर इंग्रेस पर खत्म होता है। सर्ट प्रबंधन (सर्ट-मैनेजर या क्लाउड सर्ट) ऐप डिप्लॉयमेंट से अलग है।

नोट: कुबेरनेटीस कई टीमों को गेटवे एपीआई की ओर धकेल रहा है। मानसिक मॉडल वही है: किनारे पर कुछ एचटीटीपी को सर्विस तक ले जाता है। अगर आपके क्लस्टर का मानक गेटवे है तो वही इस्तेमाल करें; नीचे की पॉड / डिप्लॉयमेंट / सर्विस कहानी नहीं बदलती।

प्रोब: ट्रैफिक कब अनुमति में है

प्रोब से कुबेरनेटीस बिना आपके मन पढ़े ऐप स्वास्थ्य सीखता है।

प्रोब	यह क्या पूछता है	आम कार्रवाई
रेडीनेस	क्या यह पॉड अभी ट्रैफिक ले सकता है?	तैयार होने तक सर्विस एंडपॉइंट से हटाना
लाइवनेस	क्या प्रोसेस अटक गया?	कंटेनर रीस्टार्ट
स्टार्टअप	क्या धीमा बूट अभी चल रहा है?	स्टार्टअप सफल होने तक लाइवनेस रोकना

सामान्य एचटीटीपी एपीआई के व्यावहारिक डिफ़ॉल्ट:

रेडीनेस: GET /health या /ready, छोटा टाइमआउट, सर्विस से हटाने से पहले कुछ फेल
लाइवनेस: केवल डेडलॉक या स्थायी हैंग पर फेल, धीमी निर्भरताओं पर नहीं
स्टार्टअप: अगर बूट लाइवनेस ग्रेस से लंबा हो (जेवीएम, बड़े मॉडल, माइग्रेशन)

आम गलती: लाइवनेस प्रोब जो डेटाबेस पर जाता है। डीबी ब्लिप तब हर पॉड रीस्टार्ट करता है और आउटेज और बिगाड़ता है। लाइवनेस स्थानीय रखें। निर्भरता जाँच रेडीनेस पर (या ऐसे स्टेटस पर जो सुंदर तरीके से गिरे)।

कॉन्फ़िगमैप और सीक्रेट

कॉन्फ़िगमैप: गैर-गुप्त कॉन्फ़िग (फ़ीचर फ़्लैग, सार्वजनिक यूआरएल, लॉग स्तर)।

सीक्रेट: क्रेडेंशियल, टोकन, प्राइवेट की। एटसीडी में डिफ़ॉल्ट बेस६४ रेस्ट पर एन्क्रिप्शन नहीं है जब तक क्लस्टर उसे चालू न करे। सीक्रेट को गिट में सादे एनव से बेहतर मानें, वॉल्ट का विकल्प नहीं। असली सीक्रेट स्टोर के लिए कई टीमें अब भी एडब्ल्यूएस सीक्रेट्स मैनेजर, जीसीपी सीक्रेट मैनेजर या वॉल्ट से सीएसआई या इनिट जॉब से इंजेक्ट करती हैं।

इंजेक्शन पैटर्न:

१. configMapKeyRef / secretKeyRef से एनवायरनमेंट वेरिएबल २. वॉल्यूम माउंट से फ़ाइलें (मल्टी-लाइन कॉन्फ़िग और टीएलएस सामग्री के लिए अच्छी)

इमेज में प्रोडक्शन सीक्रेट न पकाएँ। सार्वजनिक रेपो में जीवित पासवर्ड वाला कच्चा सीक्रेट वाईएएमएल न कमिट करें।

न्यूनतम डिप्लॉय स्केच

नीचे एक एचटीटीपी सेवा के लिए एकल-फ़ाइल मानसिक स्केच है। नाम और पोर्ट उदाहरण हैं। असली रेपो में चाहें तो अलग फ़ाइलों में बाँटें।

apiVersion: apps/v1
kind: Deployment
metadata:
  name: billing-api
spec:
  replicas: 2
  selector:
    matchLabels:
      app: billing-api
  template:
    metadata:
      labels:
        app: billing-api
    spec:
      containers:
        - name: app
          image: registry.example.com/billing-api:1.4.2
          ports:
            - containerPort: 8080
          env:
            - name: LOG_LEVEL
              valueFrom:
                configMapKeyRef:
                  name: billing-api-config
                  key: logLevel
            - name: DB_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: billing-api-secret
                  key: dbPassword
          resources:
            requests:
              cpu: "100m"
              memory: "256Mi"
            limits:
              memory: "512Mi"
          readinessProbe:
            httpGet:
              path: /ready
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 10
          livenessProbe:
            httpGet:
              path: /live
              port: 8080
            initialDelaySeconds: 15
            periodSeconds: 20
---
apiVersion: v1
kind: Service
metadata:
  name: billing-api
spec:
  selector:
    app: billing-api
  ports:
    - port: 80
      targetPort: 8080
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: billing-api
spec:
  ingressClassName: nginx
  rules:
    - host: api.example.com
      http:
        paths:
          - path: /billing
            pathType: Prefix
            backend:
              service:
                name: billing-api
                port:
                  number: 80
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: billing-api-config
data:
  logLevel: info
---
apiVersion: v1
kind: Secret
metadata:
  name: billing-api-secret
type: Opaque
stringData:
  dbPassword: "replace-me"

निर्भरता सोच से मेल खाता अप्लाई क्रम:

kubectl apply -f configmap.yaml -f secret.yaml
kubectl apply -f deployment.yaml -f service.yaml
kubectl apply -f ingress.yaml
kubectl rollout status deployment/billing-api
kubectl get pods,svc,ingress -l app=billing-api

अगर पॉड Running हैं पर Ready नहीं, इंग्रेस पर दोष लगाने से पहले रेडीनेस पाथ और लॉग जाँचें।

लेबल ही गोंद हैं

डिप्लॉयमेंट, सर्विस और नेटवर्कपॉलिसी पॉड को लेबल से ढूँढते हैं, नाम से नहीं। छोटा, स्थिर सेट रखें:

app: billing-api
वैकल्पिक: version: v1 (या रोलआउट टूलिंग को सौंपें)

अगर सर्विस सिलेक्टर पॉड लेबल से नहीं मिलता, एंडपॉइंट खाली रहते हैं और ट्रैफिक बिना साफ़ डिप्लॉयमेंट एरर के मर जाता है। पहला डिबग कदम: kubectl get endpoints billing-api (या EndpointSlice)।

पहले दिन छोड़ सकने वाली चीज़ें

असली सेवा इनके बिना भेज सकते हैं; ज़रूरत ठोस हो तब जोड़ें:

एचपीए / वीपीए जब तक ऑटो-स्केल के लायक ट्रैफिक पैटर्न न हों
पीडीबी जब मल्टी-रेप्लिका चलाएँ और स्वैच्छिक विघटन की चिंता हो
नेटवर्कपॉलिसी जब मल्टी-टेनेंट या ज़ीरो-ट्रस्ट नियम चाहिए
स्टेटफुलसेट + पीवीसी जब स्थिर पहचान या लोकल डिस्क चाहिए (डेटाबेस स्टेटलेस एपीआई से ज़्यादा डिज़ाइन माँगते हैं)
सर्विस मेश जब तक कई सेवाओं पर एमटीएलएस और ट्रैफिक नीति लागत न चुकाए
कस्टम ऑपरेटर जब तक कोई सीआरडी ऐसा जीवनचक्र न चलाए जिसे डिप्लॉयमेंट से न कह सकें

सर्ट, डीएनएस और इमेज पुल सीक्रेट प्लेटफ़ॉर्म सेटअप हैं। एक बार जोड़ें; ऐप वाईएएमएल पतला रहे।

छोटी शिप चेकलिस्ट

१. इमेज लोकल चलती है और /ready तथा /live (या आपके चुने पाथ) जवाब देती है। २. रिसोर्स रिक्वेस्ट और ज़रूरी प्रोब वाला डिप्लॉयमेंट। ३. मिलते लेबल वाली सर्विस; एंडपॉइंट खाली नहीं। ४. प्रति एनवायरनमेंट बदलने वाली चीज़ के लिए कॉन्फ़िगमैप / सीक्रेट। ५. ज़रूरत हो तो बाहरी एचटीटीपी के लिए इंग्रेस (या गेटवे / लोडबैलेंसर)। ६. kubectl rollout status हरा; सार्वजनिक पाथ एक बार हिट। ७. खराब डिप्लॉय का रोलबैक जाँचें: kubectl rollout undo deployment/billing-api।

सेवा को सिरे से सिरे तक संभालने के लिए इतना कुबेरनेटीस काफ़ी है। बाकी तब सीखें जब फेलियर या प्रोडक्ट ज़रूरत मजबूर करे, इसलिए नहीं कि सिलेबस में लिखा था।