Kubernetes और RKE2 के साथ स्केलिंग इंफ्रास्ट्रक्चर: एक प्रोडक्शन डीप डाइव

उत्पादन में Kubernetes क्लस्टर चलाना एक बात है। उसे चलाना जो अप्रत्याशित ट्रैफ़िक स्पाइक्स को अवशोषित कर सकता है, नियंत्रण-विमान विफलताओं से बच सकता है, किरायेदार अलगाव को लागू कर सकता है, और आपकी संचालन टीम को सिस्टम की हर परत में स्पष्ट दृश्यता दे सकता है - यह एक पूरी तरह से अलग चुनौती है। RKE2, रैंचर की अगली पीढ़ी का Kubernetes वितरण, विशेष रूप से उन वातावरणों के लिए बनाया गया है जहां उन आवश्यकताओं पर समझौता नहीं किया जा सकता है।

यह आलेख उत्पादन-ग्रेड RKE2 परिनियोजन के पूर्ण जीवनचक्र के माध्यम से काम करता है: प्रारंभिक क्लस्टर आर्किटेक्चर, पॉड और नोड स्तर पर ऑटोस्केलिंग, उच्च-उपलब्धता नियंत्रण विमान, संसाधन प्रशासन, और Prometheus और Grafana के साथ अवलोकन।

RKE2 क्यों?

RKE2 तीन प्रमुख क्षेत्रों में खुद को अपस्ट्रीम Kubernetes और अपने पूर्ववर्ती RKE1 से अलग करता है। सबसे पहले, यह बॉक्स से बाहर CIS Kubernetes बेंचमार्क-कठोर कॉन्फ़िगरेशन के साथ आता है - प्रवेश नियंत्रक, ऑडिट लॉगिंग, पॉड सुरक्षा, और TLS सेटिंग्स मैन्युअल हस्तक्षेप के बिना CIS लेवल 1 स्कैन पास करने के लिए पूर्व-कॉन्फ़िगर की गई हैं। दूसरा, यह FIPS 140-2 के अनुरूप है, जो इसे सरकारी और विनियमित-उद्योग तैनाती के लिए उपयुक्त बनाता है। तीसरा, यह सीधे कंटेनर को एम्बेड करता है और अपने स्वयं के सीएनआई (आपकी कॉन्फ़िगरेशन पसंद के आधार पर कैनाल या सिलियम) के साथ जहाज करता है, जिससे आपके द्वारा प्रबंधित करने के लिए आवश्यक बाहरी निर्भरता के सतह क्षेत्र को कम किया जाता है।

RKE2 एयर-गैप फ्रेंडली भी है। इंस्टॉलेशन बंडल में सभी आवश्यक कंटेनर छवियां शामिल हैं, जो ऑन-प्रिमाइसेस और एज परिनियोजन में बहुत मायने रखती हैं जहां क्लस्टर नोड्स से इंटरनेट का उपयोग प्रतिबंधित या असंभव है।

क्लस्टर आर्किटेक्चर

एक उत्पादन RKE2 क्लस्टर को सर्वर नोड्स (जो नियंत्रण विमान और आदि चलाते हैं) और एजेंट नोड्स (जो वर्कलोड चलाते हैं) में विभाजित किया गया है। उच्च उपलब्धता के लिए अनुशंसित टोपोलॉजी तीन या पांच सर्वर नोड्स और वर्कलोड वर्ग द्वारा नोड पूल में व्यवस्थित एजेंट नोड्स की एक चर संख्या है।

# /etc/rancher/rke2/config.yaml (server node)
token: <shared-cluster-token>
tls-san:
  - 10.0.0.10          # VIP or load balancer address
  - k8s.internal.example.com
cni: cilium
cluster-cidr: 10.42.0.0/16
service-cidr: 10.43.0.0/16
etcd-expose-metrics: true
kube-apiserver-arg:
  - "audit-log-path=/var/log/kubernetes/audit.log"
  - "audit-log-maxage=30"
  - "audit-log-maxsize=100"

# /etc/rancher/rke2/config.yaml (agent node)
server: https://10.0.0.10:9345
token: <shared-cluster-token>
node-label:
  - "workload-class=general"
  - "topology.kubernetes.io/zone=eu-west-1a"

अपने पहले कंट्रोल-प्लेन नोड पर सर्वर स्थापित करें, फिर उसी टोकन और वीआईपी पते का उपयोग करके शेष सर्वर नोड्स और सभी एजेंट नोड्स में शामिल हों। RKE2 स्वचालित रूप से आदि नेताओं का चुनाव करता है और कोरम का प्रबंधन करता है।

# Install and start RKE2 server
curl -sfL https://get.rke2.io | INSTALL_RKE2_TYPE=server sh -
systemctl enable --now rke2-server.service

# Retrieve the node token for joining additional nodes
cat /var/lib/rancher/rke2/server/node-token

# Install and start RKE2 agent (on worker nodes)
curl -sfL https://get.rke2.io | INSTALL_RKE2_TYPE=agent sh -
systemctl enable --now rke2-agent.service

नोड पूल और वर्कलोड प्लेसमेंट

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

# Label a node pool for memory-intensive workloads
kubectl label nodes worker-mem-{1..4} workload-class=memory-optimised
kubectl taint nodes worker-mem-{1..4} workload-class=memory-optimised:NoSchedule

# Label a separate pool for general compute
kubectl label nodes worker-gen-{1..8} workload-class=general

# Deployment targeting the memory-optimised pool
apiVersion: apps/v1
kind: Deployment
metadata:
  name: analytics-engine
spec:
  template:
    spec:
      nodeSelector:
        workload-class: memory-optimised
      tolerations:
        - key: workload-class
          operator: Equal
          value: memory-optimised
          effect: NoSchedule
      containers:
        - name: analytics
          image: registry.internal/analytics:v2.3.1
          resources:
            requests:
              memory: "8Gi"
              cpu: "2"
            limits:
              memory: "16Gi"
              cpu: "4"

क्षैतिज पॉड ऑटोस्केलर

हॉरिजॉन्टल पॉड ऑटोस्केलर (HPA) देखे गए मेट्रिक्स के आधार पर परिनियोजन या स्टेटफुलसेट की प्रतिकृति गणना को समायोजित करता है। CPU उपयोग क्लासिक ट्रिगर है, लेकिन आधुनिक HPA कॉन्फ़िगरेशन आपके एप्लिकेशन द्वारा उजागर किए गए कस्टम मेट्रिक्स या संदेश कतार गहराई जैसे स्रोतों से बाहरी मेट्रिक्स पर भी स्केल कर सकते हैं।

सबसे पहले, सुनिश्चित करें कि मेट्रिक्स सर्वर चल रहा है - RKE2 इसे डिफ़ॉल्ट रूप से बंडल नहीं करता है।

kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-server-hpa
  namespace: production
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-server
  minReplicas: 3
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 65
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 70
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300  # wait 5 minutes before scaling down
      policies:
        - type: Percent
          value: 25
          periodSeconds: 60
    scaleUp:
      stabilizationWindowSeconds: 0
      policies:
        - type: Percent
          value: 100
          periodSeconds: 30

behaviorब्लॉक स्थिरता के लिए महत्वपूर्ण है। स्केल-डाउन स्थिरीकरण विंडो के बिना, एक संक्षिप्त ट्रैफ़िक ड्रॉप समय से पहले पॉड्स को हटा देगा, जिससे लोड वापस आने पर आपको कम प्रावधान मिलेगा। असममित नीति - आक्रामक स्केल-अप, रूढ़िवादी स्केल-डाउन - अधिकांश उत्पादन कार्यभार के लिए सही डिफ़ॉल्ट है।

वर्टिकल पॉड ऑटोस्केलर

वर्टिकल पॉड ऑटोस्केलर (VPA) देखे गए उपयोग के आधार पर अलग-अलग पॉड्स पर CPU और मेमोरी अनुरोधों को सही आकार देता है। यह एक सामान्य समस्या का समाधान करता है: डेवलपर्स अनुमान के आधार पर प्रारंभिक संसाधन अनुरोध निर्धारित करते हैं, और वे मान कभी भी अपडेट नहीं होते हैं, जिससे या तो बेकार अति-प्रावधान होता है या लोड के तहत OOMKilled पॉड्स होते हैं।

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: worker-vpa
  namespace: production
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: background-worker
  updatePolicy:
    updateMode: "Auto"     # or "Off" to only view recommendations
  resourcePolicy:
    containerPolicies:
      - containerName: worker
        minAllowed:
          cpu: 100m
          memory: 256Mi
        maxAllowed:
          cpu: 4
          memory: 8Gi
        controlledResources: ["cpu", "memory"]

ध्यान दें किAutoमोड में VPA नए संसाधन मान लागू करने के लिए पॉड्स को हटा देगा और पुनरारंभ करेगा। उन सेवाओं के लिए जहां इन-फ़्लाइट अनुरोधों को बाधित नहीं किया जा सकता है, उन अनुशंसाओं को उत्पन्न करने के लिएOffमोड में VPA चलाएं जिन्हें आप रखरखाव विंडो के दौरान मैन्युअल रूप से या GitOps वर्कफ़्लो के माध्यम से लागू करते हैं।

महत्वपूर्ण:HPA और VPA को एक ही तैनाती पर एक ही संसाधन (CPU या मेमोरी) को एक साथ प्रबंधित नहीं करना चाहिए। CPU-संचालित क्षैतिज स्केलिंग के लिए HPA का उपयोग करें और मेमोरी सही आकार के लिएOffमोड में VPA का उपयोग करें, या इवेंट-संचालित स्केलिंग के लिएKEDAका उपयोग करें जहां बारीक नियंत्रण की आवश्यकता है।

क्लस्टर ऑटोस्केलर

पॉड ऑटोस्केलर मौजूदा नोड क्षमता के भीतर काम करते हैं। जब वह क्षमता समाप्त हो जाती है - पॉडPendingमें फंस जाते हैं क्योंकि किसी भी नोड के पास पर्याप्त संसाधन नहीं होते हैं - आपको नए नोड्स का प्रावधान करने के लिए क्लस्टर ऑटोस्केलर की आवश्यकता होती है। इसके विपरीत, जब नोड्स का काफी कम उपयोग किया जाता है, तो क्लस्टर ऑटोस्केलर बुनियादी ढांचे की लागत को कम करने के लिए उन्हें खत्म कर सकता है और डीकमीशन कर सकता है।

बेयर-मेटल या ऑन-प्रिमाइसेस परिनियोजन पर, क्लस्टर ऑटोस्केलर आपके बुनियादी ढांचे प्रावधान परत के साथ एकीकृत होता है। क्लाउड परिनियोजन के लिए, AWS, GCP, और Azure जैसे प्रदाता मूल नोड समूह एकीकरण प्रदान करते हैं। निम्नलिखित उदाहरण AWS ऑटो स्केलिंग समूह के लिए मुख्य कॉन्फ़िगरेशन दिखाता है।

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cluster-autoscaler
  namespace: kube-system
spec:
  template:
    spec:
      containers:
        - name: cluster-autoscaler
          image: registry.k8s.io/autoscaling/cluster-autoscaler:v1.29.0
          command:
            - ./cluster-autoscaler
            - --cloud-provider=aws
            - --nodes=2:10:k8s-general-worker-asg
            - --nodes=1:4:k8s-memory-worker-asg
            - --scale-down-delay-after-add=10m
            - --scale-down-unneeded-time=10m
            - --scale-down-utilization-threshold=0.5
            - --skip-nodes-with-local-storage=false
            - --expander=least-waste
          env:
            - name: AWS_REGION
              value: eu-west-1

--expander=least-wasteविकल्प ऑटोस्केलर को उस नोड समूह को प्राथमिकता देने के लिए कहता है जिसमें लंबित पॉड को समायोजित करने के बाद अप्रयुक्त संसाधन की सबसे छोटी मात्रा होगी, जो लागत को कम करती है। वैकल्पिक विस्तारकों मेंrandom,most-pods, औरpriorityशामिल हैं।

उच्च उपलब्धता नियंत्रण विमान

एम्बेडेड आदि के साथ एक तीन-नोड नियंत्रण विमान न्यूनतम व्यवहार्य HA टोपोलॉजी है। आदि के लिए कोरम की आवश्यकता होती है - क्लस्टर के लेखन को स्वीकार करने के लिए अधिकांश सदस्यों को स्वस्थ होना चाहिए। तीन सदस्यों के साथ आप एक विफलता बर्दाश्त कर सकते हैं; पाँच सदस्यों के साथ आप दो को बर्दाश्त कर सकते हैं।

कंट्रोल-प्लेन नोड्स को लोड बैलेंसर के पीछे बैठना चाहिए। क्लाउड परिनियोजन के लिए, पोर्ट 6443 (क्यूब-एपिसर्वर) और 9345 (आरकेई2 पंजीकरण) को लक्षित करने वाला एक टीसीपी लोड बैलेंसर अच्छी तरह से काम करता है। ऑन-प्रिमाइसेस परिनियोजन आमतौर पर वर्चुअल आईपी पते के साथ कीपअलाइव्ड का उपयोग करते हैं।

# keepalived.conf on control-plane nodes
vrrp_instance VI_1 {
    state MASTER        # BACKUP on the other two nodes
    interface eth0
    virtual_router_id 51
    priority 100        # 90 and 80 on the other two nodes
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass securepassword
    }
    virtual_ipaddress {
        10.0.0.10/24    # VIP used in tls-san and agent server address
    }
}

सत्यापित करें कि किसी भी नियंत्रण-प्लेन ऑपरेशन के बाद आदि स्वस्थ है। RKE2etcdctlको/var/lib/rancher/rke2/bin/etcdctlपर बंडल करता है।

ETCDCTL_API=3 /var/lib/rancher/rke2/bin/etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/var/lib/rancher/rke2/server/tls/etcd/server-ca.crt \
  --cert=/var/lib/rancher/rke2/server/tls/etcd/client.crt \
  --key=/var/lib/rancher/rke2/server/tls/etcd/client.key \
  endpoint health --cluster

संसाधन कोटा और सीमा रेंज

बहु-किरायेदार समूहों में - जहां विभिन्न टीमें या एप्लिकेशन समान भौतिक बुनियादी ढांचे को साझा करते हैं - रिसोर्सकोटा और लिमिटरेंज आवश्यक रेलिंग हैं। रिसोर्सकोटास नेमस्पेस के भीतर कुल संसाधन खपत पर हार्ड कैप निर्धारित करता है। LimitRanges अलग-अलग कंटेनरों के लिए डिफ़ॉल्ट और अधिकतम मान सेट करता है, जिससे गलत तरीके से कॉन्फ़िगर की गई तैनाती को असीमित संसाधनों का अनुरोध करने से रोका जा सकता है।

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-alpha-quota
  namespace: team-alpha
spec:
  hard:
    requests.cpu: "20"
    requests.memory: 40Gi
    limits.cpu: "40"
    limits.memory: 80Gi
    count/deployments.apps: "20"
    count/services: "15"
    persistentvolumeclaims: "10"
    requests.storage: 500Gi

apiVersion: v1
kind: LimitRange
metadata:
  name: team-alpha-limits
  namespace: team-alpha
spec:
  limits:
    - type: Container
      default:
        cpu: 500m
        memory: 512Mi
      defaultRequest:
        cpu: 100m
        memory: 128Mi
      max:
        cpu: "8"
        memory: 16Gi
    - type: PersistentVolumeClaim
      max:
        storage: 100Gi

लिमिटरेंज लागू करने से यह सुनिश्चित होता है कि जो डेवलपर्स संसाधन अनुरोध निर्दिष्ट करना भूल जाते हैं उन्हें अभी भी शून्य CPU का अनुरोध करने के बजाय समझदार डिफ़ॉल्ट मिलते हैं, जिसके कारण शेड्यूलर पॉड को कहीं भी रख सकता है और संभावित रूप से उसी नोड पर अन्य वर्कलोड को भूखा रख सकता है।

मॉनिटरिंग Kubernetes क्लस्टर में

ऑब्जर्वेबिलिटी के तीन स्तंभ हैं: मेट्रिक्स, लॉग और ट्रेस। Prometheus मेट्रिक्स संग्रह को संभालता है; Grafana विज़ुअलाइज़ेशन को संभालता है।kube-prometheus-stackHelm चार्ट संपूर्ण स्टैक - Prometheus ऑपरेटर, अलर्ट मैनेजर, Grafana, नोड निर्यातक और पूर्व-निर्मित डैशबोर्ड का एक व्यापक सेट - को एक ही कमांड में प्रदर्शित करता है।

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

helm install kube-prometheus-stack prometheus-community/kube-prometheus-stack \
  --namespace monitoring \
  --create-namespace \
  --set prometheus.prometheusSpec.retention=30d \
  --set prometheus.prometheusSpec.storageSpec.volumeClaimTemplate.spec.storageClassName=longhorn \
  --set prometheus.prometheusSpec.storageSpec.volumeClaimTemplate.spec.resources.requests.storage=100Gi \
  --set grafana.adminPassword=<secure-password> \
  --set alertmanager.alertmanagerSpec.storage.volumeClaimTemplate.spec.resources.requests.storage=10Gi

जबetcd-expose-metrics: trueको सर्वर कॉन्फ़िगरेशन में सेट किया जाता है तो

RKE2 आदि मेट्रिक्स को उजागर करता है। एक सर्विस मॉनिटर जोड़ें ताकि Prometheus उन्हें स्क्रैप कर सके।

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: rke2-etcd
  namespace: monitoring
  labels:
    release: kube-prometheus-stack
spec:
  namespaceSelector:
    matchNames: [kube-system]
  selector:
    matchLabels:
      app.kubernetes.io/name: rke2-etcd
  endpoints:
    - port: metrics
      scheme: https
      tlsConfig:
        caFile: /etc/prometheus/secrets/etcd-client-cert/ca.crt
        certFile: /etc/prometheus/secrets/etcd-client-cert/client.crt
        keyFile: /etc/prometheus/secrets/etcd-client-cert/client.key

आवश्यक चेतावनी नियम

पूर्व-निर्मित डैशबोर्ड एक शुरुआती बिंदु है, लेकिन आपके वातावरण के अनुरूप कस्टम अलर्टिंग नियम ऑन-कॉल इंजीनियरों को उपयोगकर्ताओं को किसी समस्या का पता चलने से पहले कार्रवाई करने की अनुमति देते हैं।

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: workload-alerts
  namespace: monitoring
  labels:
    release: kube-prometheus-stack
spec:
  groups:
    - name: pod-health
      rules:
        - alert: PodCrashLooping
          expr: rate(kube_pod_container_status_restarts_total[10m]) > 0.5
          for: 5m
          labels:
            severity: critical
          annotations:
            summary: "Pod {{ $labels.namespace }}/{{ $labels.pod }} is crash-looping"

        - alert: NodeMemoryPressure
          expr: |
            (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) < 0.1
          for: 2m
          labels:
            severity: warning
          annotations:
            summary: "Node {{ $labels.node }} memory below 10%"

        - alert: HPAMaxedOut
          expr: |
            kube_horizontalpodautoscaler_status_current_replicas
            == kube_horizontalpodautoscaler_spec_max_replicas
          for: 15m
          labels:
            severity: warning
          annotations:
            summary: "HPA {{ $labels.namespace }}/{{ $labels.horizontalpodautoscaler }} at maximum replicas"

HPAMaxedOutअलर्ट व्यवहार में विशेष रूप से मूल्यवान है। जब एक एचपीए को विस्तारित अवधि के लिए अधिकतम पर पिन किया जाता है तो इसका मतलब है कि ट्रैफ़िक आपकी वर्तमान सीमा से अधिक हो गया है। आपको या तो अधिकतम बढ़ाने या नोड पूल में क्षमता जोड़ने की आवश्यकता है - और आप इसके बारे में अगले स्पाइक से पहले जानना चाहते हैं, उसके दौरान नहीं।

उत्पादन सर्वोत्तम अभ्यास

पॉड व्यवधान बजट

एक पॉडडिसरप्शनबजट (पीडीबी) यह निर्धारित करता है कि नोड ड्रेन जैसे स्वैच्छिक व्यवधानों के दौरान एक परिनियोजन में कितने पॉड एक साथ अनुपलब्ध हो सकते हैं। पीडीबी के बिना, रखरखाव के लिए एक नोड को खाली करने से पूरी तैनाती ऑफ़लाइन हो सकती है।

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: api-server-pdb
  namespace: production
spec:
  minAvailable: 2       # or use maxUnavailable: 1
  selector:
    matchLabels:
      app: api-server

टोपोलॉजी स्प्रेड बाधाएं

डिफ़ॉल्ट रूप से, शेड्यूलर सर्वोत्तम-प्रयास एल्गोरिदम का उपयोग करके प्रतिकृतियों को नोड्स में फैलाता है। टोपोलॉजी प्रसार बाधाएं आपको कड़ी गारंटी देती हैं कि प्रतिकृतियां उपलब्धता क्षेत्रों या रैक में वितरित की जाती हैं।

topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: topology.kubernetes.io/zone
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        app: api-server

अपग्रेड रणनीति

RKE2 सिस्टम अपग्रेड कंट्रोलर के माध्यम से रोलिंग अपग्रेड का समर्थन करता है। आप एक योजना परिभाषित करते हैं जो सर्वर या एजेंट नोड्स को लक्षित करती है और लक्ष्य संस्करण निर्दिष्ट करती है; नियंत्रक क्रमिक रूप से नोड्स को हटाता है, अपग्रेड करता है और अनकॉर्डन करता है।

apiVersion: upgrade.cattle.io/v1
kind: Plan
metadata:
  name: rke2-server-upgrade
  namespace: system-upgrade
spec:
  concurrency: 1
  cordon: true
  nodeSelector:
    matchExpressions:
      - { key: node-role.kubernetes.io/control-plane, operator: In, values: ["true"] }
  serviceAccountName: system-upgrade
  upgrade:
    image: rancher/rke2-upgrade
  version: v1.29.4+rke2r1

आदि बैकअप और

RKE2 स्वचालित रूप से शेड्यूल किए गए आदि स्नैपशॉट ले सकता है। सुनिश्चित करें कि वे कंट्रोल-प्लेन नोड्स पर स्थानीय डिस्क के बजाय क्लस्टर के बाहर टिकाऊ भंडारण - एक एस 3 बाल्टी या रिमोट एनएफएस माउंट - पर लिखे गए हैं।

# /etc/rancher/rke2/config.yaml additions for automated snapshots
etcd-snapshot-schedule-cron: "0 */6 * * *"    # every 6 hours
etcd-snapshot-retention: 10
etcd-snapshot-dir: /mnt/nfs/etcd-snapshots

# Manual snapshot
rke2 etcd-snapshot save --name pre-upgrade-$(date +%Y%m%d)

# Restore from snapshot (run on a single server node with cluster stopped)
rke2 server --cluster-reset --cluster-reset-restore-path=/path/to/snapshot.db

निष्कर्ष

स्केलिंग इंफ्रास्ट्रक्चर एक एकल कॉन्फ़िगरेशन परिवर्तन नहीं है - यह इंटरलॉकिंग क्षमताओं की एक प्रणाली है जिसे एक साथ डिजाइन और संचालित किया जाना चाहिए। क्षैतिज पॉड ऑटोस्केलिंग कार्यभार स्तर पर अल्पकालिक ट्रैफ़िक विस्फोट को संभालती है। वर्टिकल पॉड ऑटोस्केलिंग समय के साथ संसाधन अनुरोधों को ईमानदार रखता है। क्लस्टर ऑटोस्केलर यह सुनिश्चित करता है कि अंतर्निहित नोड क्षमता आपके पॉड ऑटोस्केलर्स की कुल मांग को ट्रैक करती है। नोड पूल और टोपोलॉजी बाधाएं सुनिश्चित करती हैं कि कार्यभार सही हार्डवेयर पर आए। संसाधन कोटा और सीमा श्रेणियाँ किरायेदारों को एक दूसरे से बचाती हैं। पॉडडिसरप्शनबजट और टोपोलॉजी प्रसार संबंधी बाधाएं उपलब्धता को कठिन बनाती हैं। और Grafana के साथ Prometheus आपकी टीम को आउटेज बनने से पहले गिरावट का पता लगाने की दृश्यता देता है।

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