Loading blog...

Kubernetes اور RKE2 کے ساتھ انفراسٹرکچر سکیلنگ: ایک پروڈکشن ڈیپ ڈائیو

RKE2 کلسٹر آرکیٹیکچر، افقی اور عمودی آٹو اسکیلنگ، اعلی دستیابی، وسائل کی حکمرانی، اور Prometheus/Grafana مشاہداتی کے لیے پروڈکشن انجینئر کی گائیڈ

Balinder Walia27 مئی، 202514 min read

پیداوار میں Kubernetes کلسٹر چلانا ایک چیز ہے۔ ایسا چلانا جو غیر متوقع ٹریفک اسپائکس کو جذب کر سکے، کنٹرول پلین کی ناکامیوں سے بچ سکے، کرایہ داروں کی تنہائی کو نافذ کر سکے، اور آپ کی آپریشنز ٹیم کو سسٹم کی ہر تہہ میں واضح مرئیت فراہم کر سکے — یہ ایک بالکل مختلف چیلنج ہے۔ RKE2، Rancher کی اگلی نسل کی Kubernetes تقسیم، خاص طور پر ایسے ماحول کے لیے بنائی گئی ہے جہاں یہ ضروریات ناقابلِ گفت و شنید ہیں۔

یہ مضمون پروڈکشن گریڈ RKE2 کی تعیناتی کے مکمل لائف سائیکل کے ذریعے کام کرتا ہے: ابتدائی کلسٹر آرکیٹیکچر، پوڈ اور نوڈ کی سطح پر آٹو اسکیلنگ، اعلی دستیابی کنٹرول طیارے، وسائل کی حکمرانی، اور Prometheus اور Grafana کے ساتھ مشاہدہ۔

کیوں RKE2؟

RKE2 اپنے آپ کو upstream Kubernetes سے اور اپنے پیشرو RKE1 سے تین اہم شعبوں میں ممتاز کرتا ہے۔ سب سے پہلے، یہ باکس سے باہر CIS Kubernetes بینچ مارک کی سخت کنفیگریشن کے ساتھ بھیجتا ہے — داخلہ کنٹرولرز، آڈٹ لاگنگ، پوڈ سیکیورٹی، اور TLS سیٹنگز بغیر دستی مداخلت کے CIS لیول 1 اسکین کو پاس کرنے کے لیے پہلے سے ترتیب دی گئی ہیں۔ دوسرا، یہ FIPS 140-2 کے مطابق ہے، جو اسے حکومت اور ریگولیٹڈ انڈسٹری کی تعیناتیوں کے لیے موزوں بناتا ہے۔ تیسرا، یہ کنٹینر کو براہ راست سرایت کرتا ہے اور اپنے CNI (آپ کی کنفیگریشن پسند پر منحصر نہر یا Cilium) کے ساتھ بھیجتا ہے، بیرونی انحصار کے سطحی رقبے کو کم کرتا ہے جس کا آپ کو انتظام کرنے کی ضرورت ہے۔

RKE2 ایئر گیپ فرینڈلی بھی ہے۔ تنصیب کے بنڈل میں کنٹینر کی تمام مطلوبہ تصاویر شامل ہیں، جو آن پریمیسس اور کنارے کی تعیناتیوں میں بہت زیادہ اہمیت رکھتی ہیں جہاں کلسٹر نوڈس سے انٹرنیٹ تک رسائی محدود یا ناممکن ہے۔

کلسٹر آرکیٹیکچر

ایک پروڈکشن RKE2 کلسٹر کو سرور نوڈس (جو کنٹرول پلین اور etcd چلاتے ہیں) اور ایجنٹ نوڈس (جو ورک بوجھ چلاتے ہیں) میں تقسیم کیا گیا ہے۔ اعلی دستیابی کے لیے تجویز کردہ ٹوپولوجی تین یا پانچ سرور نوڈس اور ایجنٹ نوڈس کی ایک متغیر تعداد ہے جو کام کے بوجھ کی کلاس کے ذریعے نوڈ پولز میں ترتیب دی گئی ہے۔

# /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"

سرور کو اپنے پہلے کنٹرول پلین نوڈ پر انسٹال کریں، پھر ایک ہی ٹوکن اور VIP ایڈریس کا استعمال کرتے ہوئے باقی سرور نوڈس اور تمام ایجنٹ نوڈس میں شامل ہوں۔ RKE2 خود بخود etcd لیڈروں کا انتخاب کرتا ہے اور کورم کا انتظام کرتا ہے۔

# 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"

Horizontal Pod Autoscaler

Horizontal Pod Autoscaler (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بلاک استحکام کے لیے اہم ہے۔ اسکیل ڈاون اسٹیبلائزیشن ونڈو کے بغیر، ٹریفک کا ایک مختصر ڈراپ وقت سے پہلے پوڈز کو ہٹا دے گا، اور جب لوڈ واپس آجائے گا تو آپ کو انڈر پروویژن ہو جائے گا۔ غیر متناسب پالیسی - جارحانہ اسکیل اپ، قدامت پسند اسکیل ڈاؤن - زیادہ تر پیداواری کام کے بوجھ کے لیے صحیح ڈیفالٹ ہے۔

Vertical Pod Autoscaler

Vertical Pod Autoscaler (VPA) مشاہدہ شدہ استعمال کی بنیاد پر انفرادی پوڈز پر CPU اور میموری کی درخواستوں کو دائیں سائز دیتا ہے۔ یہ ایک عام مسئلہ کو حل کرتا ہے: ڈویلپرز اندازے کی بنیاد پر ابتدائی وسائل کی درخواستیں مرتب کرتے ہیں، اور وہ اقدار کبھی بھی اپ ڈیٹ نہیں ہوتیں، جس کی وجہ سے یا تو فضول ضرورت سے زیادہ فراہمی ہوتی ہے یا بوجھ کے نیچے OOMKilled pods۔

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 نئی وسائل کی قدروں کو لاگو کرنے کے لیے پوڈز کو بے دخل اور دوبارہ شروع کر دے گا۔ ایسی خدمات کے لیے جہاں دوران پرواز درخواستوں میں خلل نہیں ڈالا جا سکتا ہے، VPA کوOffموڈ میں چلائیں تاکہ وہ سفارشات تیار کر سکیں جو آپ مینٹیننس ونڈوز کے دوران دستی طور پر یا GitOps ورک فلو کے ذریعے لاگو کرتے ہیں۔

اہم:HPA اور VPA کو بیک وقت ایک ہی تعیناتی پر ایک ہی وسائل (CPU یا میموری) کا نظم نہیں کرنا چاہیے۔ CPU سے چلنے والی افقی اسکیلنگ کے لیے HPA اور میموری کے دائیں سائز کے لیےOffموڈ میں VPA کا استعمال کریں، یا ایونٹ پر مبنی اسکیلنگ کے لیےKEDAاستعمال کریں جہاں عمدہ کنٹرول کی ضرورت ہو۔

کلسٹر آٹو اسکیلر

Pod autoscalers موجودہ نوڈ کی گنجائش کے اندر کام کرتے ہیں۔ جب یہ صلاحیت ختم ہوجاتی ہے — پوڈز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شامل ہیں۔

اعلی دستیابی کنٹرول طیارہ

ایمبیڈڈ etcd کے ساتھ ایک تین نوڈ کنٹرول طیارہ کم از کم قابل عمل HA ٹوپولوجی ہے۔ etcd کو کورم کی ضرورت ہوتی ہے - کلسٹر کے لیے تحریروں کو قبول کرنے کے لیے اراکین کی اکثریت کا صحت مند ہونا ضروری ہے۔ تین ارکان کے ساتھ آپ ایک ناکامی کو برداشت کر سکتے ہیں۔ پانچ ممبروں کے ساتھ آپ دو کو برداشت کر سکتے ہیں۔

کنٹرول پلین نوڈس کو لوڈ بیلنسر کے پیچھے بیٹھنا چاہیے۔ کلاؤڈ تعیناتیوں کے لیے، پورٹ 6443 (kube-apiserver) اور 9345 (RKE2 رجسٹریشن) کو نشانہ بنانے والا TCP لوڈ بیلنس اچھا کام کرتا ہے۔ آن پریمیسس تعیناتیاں عام طور پر ورچوئل IP ایڈریس کے ساتھ Keepalived کا استعمال کرتی ہیں۔

# 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
    }
}

کسی بھی کنٹرول پلین آپریشن کے بعد

تصدیق کریں کہ etcd صحت مند ہے۔ RKE2 بنڈلetcdctlپر/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 ضروری گٹرل ہیں۔ ResourceQuotas نام کی جگہ کے اندر وسائل کی کل کھپت پر ہارڈ کیپس سیٹ کرتا ہے۔ 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

LimitRanges کا اطلاق اس بات کو یقینی بناتا ہے کہ ڈویلپرز جو وسائل کی درخواستیں بتانا بھول جاتے ہیں وہ صفر CPU کی درخواست کرنے کے بجائے اب بھی سمجھدار ڈیفالٹس حاصل کرتے ہیں، جس کی وجہ سے شیڈیولر پوڈ کو کہیں بھی رکھ سکتا ہے اور ممکنہ طور پر اسی نوڈ پر دوسرے کام کے بوجھ کو بھوکا رکھ سکتا ہے۔

Prometheus اور Grafanaکے ساتھ

مانیٹرنگ 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 etcd میٹرکس کو ظاہر کرتا ہے۔ ایک سروس مانیٹر شامل کریں تاکہ 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الرٹ عملی طور پر خاص طور پر قابل قدر ہے۔ جب ایک HPA کو ایک توسیعی مدت کے لیے اس کی زیادہ سے زیادہ پر پن کیا جاتا ہے تو اس کا مطلب ہے کہ ٹریفک آپ کی موجودہ حد سے بڑھ گئی ہے۔ آپ کو یا تو زیادہ سے زیادہ بڑھانے یا نوڈ پول میں صلاحیت شامل کرنے کی ضرورت ہے — اور آپ اس کے بارے میں اگلی اسپائیک سے پہلے جاننا چاہتے ہیں، اس کے دوران نہیں۔

پیداوار کے بہترین طریقے

Pod Disruption Budges

ایک PodDisruptionBudget (PDB) اس بات کو محدود کرتا ہے کہ نوڈ ڈرین جیسے رضاکارانہ رکاوٹوں کے دوران تعیناتی میں کتنے پوڈ بیک وقت دستیاب نہیں ہوسکتے ہیں۔ PDBs کے بغیر، دیکھ بھال کے لیے ایک نوڈ کو نکالنا پوری تعیناتی کو آف لائن لے سکتا ہے۔

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

etcd بیک اپ اور

کو بحال کریں۔

RKE2 خود بخود شیڈول کردہ etcd سنیپ شاٹس لے سکتا ہے۔ یقینی بنائیں کہ وہ کلسٹر کے باہر پائیدار اسٹوریج پر لکھے گئے ہیں — ایک S3 بالٹی یا ریموٹ NFS ماؤنٹ — بجائے کہ کنٹرول پلین نوڈس پر مقامی ڈسک۔

# /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

نتیجہ

RKE2 کے ساتھ

اسکیلنگ انفراسٹرکچر کوئی ایک کنفیگریشن تبدیلی نہیں ہے - یہ انٹر لاکنگ صلاحیتوں کا ایک نظام ہے جسے ایک ساتھ ڈیزائن اور چلایا جانا چاہیے۔ افقی پوڈ آٹو اسکیلنگ کام کے بوجھ کی سطح پر قلیل المدتی ٹریفک برسٹ کو ہینڈل کرتی ہے۔ عمودی پوڈ آٹو اسکیلنگ وسائل کی درخواستوں کو وقت کے ساتھ ایماندار رکھتی ہے۔ کلسٹر آٹو اسکیلر اس بات کو یقینی بناتا ہے کہ نوڈ کی بنیادی صلاحیت آپ کے پوڈ آٹو اسکیلرز کی مجموعی مانگ کو ٹریک کرتی ہے۔ نوڈ پولز اور ٹوپولوجی کی رکاوٹیں اس بات کو یقینی بناتی ہیں کہ کام کا بوجھ صحیح ہارڈ ویئر پر اترتا ہے۔ وسائل کوٹہ اور حد کی حدود کرایہ داروں کو ایک دوسرے سے بچاتی ہیں۔ PodDisruptionبجٹ اور ٹوپولوجی پھیلاؤ کی رکاوٹیں دستیابی کو سخت کرتی ہیں۔ اور Grafana کے ساتھ Prometheus آپ کی ٹیم کو انحطاط کا پتہ لگانے کے لیے مرئیت فراہم کرتا ہے اس سے پہلے کہ یہ بند ہو جائے۔

RKE2 پیداوار میں اپنا مقام بالکل ٹھیک اس لیے کماتا ہے کیونکہ یہ اس اسٹیک کا کافی حصہ پہلے سے سخت اور پہلے سے مربوط کرتا ہے۔ آپ کی ذمہ داری ہے کہ نوبز کو سمجھیں، انہیں اپنے کام کے بوجھ کی خصوصیات کے مطابق بنائیں، اور آپریشنل ڈسپلن تیار کریں — رن بکس، الرٹ روٹنگ، اپ گریڈ کیڈینس، بیک اپ کی توثیق — جو کہ ایک اچھی طرح سے تشکیل شدہ کلسٹر کو حقیقی طور پر قابل اعتماد پلیٹ فارم میں بدل دیتا ہے۔