توسيع نطاق البنية التحتية باستخدام Kubernetes وRKE2: نظرة عميقة على الإنتاج

يعد تشغيل مجموعة Kubernetes في الإنتاج أمرًا واحدًا. إن تشغيل نظام يمكنه استيعاب الارتفاعات غير المتوقعة في حركة المرور، والبقاء على قيد الحياة في حالات فشل طائرة التحكم، وفرض عزل المستأجر، ومنح فريق العمليات الخاص بك رؤية واضحة لكل طبقة من طبقات النظام - وهذا يمثل تحديًا مختلفًا تمامًا. تم تصميم RKE2، توزيع Kubernetes من الجيل التالي من Rancher، خصيصًا للبيئات التي تكون فيها هذه المتطلبات غير قابلة للتفاوض.

تعمل هذه المقالة من خلال دورة الحياة الكاملة لنشر RKE2 على مستوى الإنتاج: بنية المجموعة الأولية، والقياس التلقائي على مستوى الكبسولة والعقدة، ومستويات التحكم عالية التوفر، وإدارة الموارد، وإمكانية المراقبة مع Prometheus وGrafana.

لماذا RKE2؟

RKE2 عن Kubernetes المنبع وعن سابقه RKE1 في ثلاثة مجالات رئيسية. أولاً، يأتي مزودًا بتكوين CIS Kubernetes المعياري الجاهز - يتم تكوين وحدات تحكم القبول وتسجيل التدقيق وأمان الكبسولة وإعدادات TLS مسبقًا لاجتياز فحص CIS المستوى 1 دون تدخل يدوي. ثانيًا، إنه متوافق مع FIPS 140-2، مما يجعله مناسبًا لعمليات النشر الحكومية والصناعية المنظمة. ثالثًا، يقوم بتضمين الحاوية مباشرة ويشحن مع CNI الخاص به (قناة أو Cilium حسب اختيار التكوين الخاص بك)، مما يقلل من مساحة سطح التبعيات الخارجية التي تحتاج إلى إدارتها.

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"

قم بتثبيت الخادم على عقدة مستوى التحكم الأولى، ثم انضم إلى عقد الخادم المتبقية وجميع عقد الوكيل باستخدام نفس الرمز المميز وعنوان 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 (HPA) بضبط عدد النسخ المتماثلة للنشر أو StatefulSet بناءً على المقاييس التي تمت ملاحظتها. يعد استخدام CPU هو المشغل الكلاسيكي، ولكن تكوينات HPA الحديثة يمكنها أيضًا التوسع على المقاييس المخصصة التي يعرضها تطبيقك أو على المقاييس الخارجية من مصادر مثل عمق قائمة انتظار الرسائل.

أولاً، تأكد من تشغيل Metrics Server - لا يقوم 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 (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"]

لاحظ أن VPA في وضعAutoسوف يقوم بطرد البودات وإعادة تشغيلها لتطبيق قيم الموارد الجديدة. بالنسبة للخدمات التي لا يمكن مقاطعة الطلبات أثناء الرحلة، قم بتشغيل VPA في وضعOffلإنشاء توصيات تقوم بتطبيقها يدويًا أو من خلال سير عمل GitOps أثناء نوافذ الصيانة.

هام: يجب ألا يقومHPA وVPA بإدارة نفس المورد (CPU أو الذاكرة) في نفس النشر في وقت واحد. استخدم HPA للقياس الأفقي المعتمد على CPU وVPA في وضعOffلتحديد الحجم الصحيح للذاكرة، أو استخدمKEDAللقياس المستند إلى الأحداث حيث يلزم التحكم الدقيق.

مقياس تلقائي للمجموعة

Pod ضمن سعة العقدة الحالية. عند استنفاد هذه السعة - تتعطل القرون فيPendingلأنه لا توجد عقدة لديها موارد كافية - فأنت بحاجة إلى Cluster Autoscaler لتوفير عقد جديدة. على العكس من ذلك، عندما تكون العقد غير مستغلة بشكل كبير، يمكن لـ Cluster Autoscaler استنزافها وإيقاف تشغيلها لتقليل تكلفة البنية التحتية.

في عمليات النشر المعدنية أو المحلية، يتكامل Cluster Autoscaler مع طبقة توفير البنية التحتية لديك. بالنسبة لعمليات النشر السحابية، يقدم مقدمو الخدمة مثل AWS وGCP وAzure عمليات تكامل لمجموعة العقدة الأصلية. يوضح المثال التالي التكوين الأساسي لمجموعة AWS Auto Scaling Group.

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 القابلة للحياة. إلخ يتطلب النصاب القانوني - يجب أن يتمتع أغلبية الأعضاء بصحة جيدة حتى تتمكن المجموعة من قبول عمليات الكتابة. مع ثلاثة أعضاء يمكنك تحمل فشل واحد؛ مع خمسة أعضاء يمكنك أن تتحمل اثنين.

يجب أن تكون عقد مستوى التحكم خلف موازن التحميل. بالنسبة لعمليات النشر السحابية، يعمل موازن تحميل TCP الذي يستهدف المنفذ 6443 (kube-apserver) و9345 (تسجيل RKE2) بشكل جيد. تستخدم عمليات النشر المحلية بشكل شائع الاحتفاظ بالحيوية باستخدام عنوان IP افتراضي.

# 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 سليم بعد أي عملية لطائرة التحكم. حزم 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

حصص الموارد ونطاقات الحد

في المجموعات متعددة المستأجرين - حيث تشترك فرق أو تطبيقات مختلفة في نفس البنية التحتية المادية - تعد ResourceQuotas و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

RKE2 مقاييس etcd عند تعيينetcd-expose-metrics: trueفي تكوين الخادم. أضف ServiceMonitor حتى يقوم 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 عند الحد الأقصى لفترة طويلة، فهذا يعني أن حركة المرور قد تجاوزت الحد الأقصى الحالي. تحتاج إما إلى رفع الحد الأقصى أو إضافة السعة إلى تجمع العقدة - وتريد معرفة ذلك قبل الارتفاع التالي، وليس أثناءه.

ميزانيات تعطيل الكبسولة

تعمل 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

إلخ النسخ الاحتياطي والاستعادة

RKE2 التقاط لقطات مجدولة وما إلى ذلك تلقائيًا. تأكد من كتابتها على وحدة تخزين متينة خارج المجموعة — حاوية 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 تغييرًا واحدًا في التكوين - بل هو نظام من القدرات المتشابكة التي يجب تصميمها وتشغيلها معًا. يتعامل القياس التلقائي للجراب الأفقي مع رشقات حركة المرور قصيرة العمر على مستوى عبء العمل. يحافظ القياس التلقائي للقرص العمودي على صدق طلبات الموارد مع مرور الوقت. يضمن Cluster Autoscaler أن سعة العقدة الأساسية تتبع الطلب الإجمالي لمقياس تلقائي للكبسولة الخاصة بك. تضمن مجموعات العقد والقيود الهيكلية وصول أحمال العمل إلى الأجهزة المناسبة. حصص الموارد ونطاقات الحدود تحمي المستأجرين من بعضهم البعض. تعمل قيود PodDisruptionBudgets وانتشار الطوبولوجيا على زيادة التوفر. ويمنح Prometheus مع Grafana فريقك الرؤية لاكتشاف التدهور قبل أن يصبح انقطاعًا.

RKE2 مكانته في الإنتاج على وجه التحديد لأنه يشحن جزءًا كبيرًا من هذه المجموعة المقوية مسبقًا والمدمجة مسبقًا. تتمثل مسؤوليتك في فهم المقابض، وضبطها بما يتناسب مع خصائص عبء العمل لديك، وبناء الانضباط التشغيلي - دفاتر التشغيل، وتوجيه التنبيهات، وإيقاع الترقية، والتحقق من صحة النسخ الاحتياطي - الذي يحول مجموعة مكونة جيدًا إلى نظام أساسي موثوق به حقًا.