Kubernetes ਅਤੇ RKE2 ਨਾਲ ਸਕੇਲਿੰਗ ਬੁਨਿਆਦੀ ਢਾਂਚਾ: ਇੱਕ ਉਤਪਾਦਨ ਡੂੰਘੀ ਗੋਤਾਖੋਰੀ

ਉਤਪਾਦਨ ਵਿੱਚ ਇੱਕ Kubernetes ਕਲੱਸਟਰ ਚਲਾਉਣਾ ਇੱਕ ਚੀਜ਼ ਹੈ। ਇੱਕ ਅਜਿਹਾ ਚਲਾਉਣਾ ਜੋ ਅਣਪਛਾਤੀ ਟ੍ਰੈਫਿਕ ਸਪਾਈਕਸ ਨੂੰ ਜਜ਼ਬ ਕਰ ਸਕਦਾ ਹੈ, ਨਿਯੰਤਰਣ-ਜਹਾਜ਼ ਦੀਆਂ ਅਸਫਲਤਾਵਾਂ ਤੋਂ ਬਚ ਸਕਦਾ ਹੈ, ਕਿਰਾਏਦਾਰ ਅਲੱਗ-ਥਲੱਗਤਾ ਨੂੰ ਲਾਗੂ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਤੁਹਾਡੀ ਓਪਰੇਸ਼ਨ ਟੀਮ ਨੂੰ ਸਿਸਟਮ ਦੀ ਹਰ ਪਰਤ ਵਿੱਚ ਸਪਸ਼ਟ ਦਿੱਖ ਪ੍ਰਦਾਨ ਕਰ ਸਕਦਾ ਹੈ - ਇਹ ਇੱਕ ਬਿਲਕੁਲ ਵੱਖਰੀ ਚੁਣੌਤੀ ਹੈ। RKE2, ਰੈਂਚਰ ਦੀ ਅਗਲੀ ਪੀੜ੍ਹੀ ਦੀ Kubernetes ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ, ਖਾਸ ਤੌਰ 'ਤੇ ਅਜਿਹੇ ਵਾਤਾਵਰਨ ਲਈ ਬਣਾਈ ਗਈ ਹੈ ਜਿੱਥੇ ਉਹ ਲੋੜਾਂ ਗੈਰ-ਸੋਧਯੋਗ ਹਨ।

ਇਹ ਲੇਖ ਉਤਪਾਦਨ-ਗ੍ਰੇਡ RKE2 ਤੈਨਾਤੀ ਦੇ ਪੂਰੇ ਜੀਵਨ ਚੱਕਰ ਦੁਆਰਾ ਕੰਮ ਕਰਦਾ ਹੈ: ਸ਼ੁਰੂਆਤੀ ਕਲੱਸਟਰ ਆਰਕੀਟੈਕਚਰ, ਪੋਡ ਅਤੇ ਨੋਡ ਪੱਧਰ 'ਤੇ ਆਟੋਸਕੇਲਿੰਗ, ਉੱਚ-ਉਪਲਬਧਤਾ ਨਿਯੰਤਰਣ ਪਲੇਨ, ਸਰੋਤ ਪ੍ਰਸ਼ਾਸਨ, ਅਤੇ Prometheus ਅਤੇ Grafana ਨਾਲ ਨਿਰੀਖਣਯੋਗਤਾ।

RKE2 ਕਿਉਂ?

RKE2 ਆਪਣੇ ਆਪ ਨੂੰ ਅਪਸਟ੍ਰੀਮ Kubernetes ਅਤੇ ਇਸਦੇ ਪੂਰਵਗਾਮੀ RKE1 ਤੋਂ ਤਿੰਨ ਮੁੱਖ ਖੇਤਰਾਂ ਵਿੱਚ ਵੱਖਰਾ ਕਰਦਾ ਹੈ। ਪਹਿਲਾਂ, ਇਹ ਬਾਕਸ ਦੇ ਬਾਹਰ ਇੱਕ CIS Kubernetes ਬੈਂਚਮਾਰਕ-ਸਖਤ ਸੰਰਚਨਾ ਦੇ ਨਾਲ ਭੇਜਦਾ ਹੈ — ਦਾਖਲਾ ਕੰਟਰੋਲਰ, ਆਡਿਟ ਲੌਗਿੰਗ, ਪੌਡ ਸੁਰੱਖਿਆ, ਅਤੇ TLS ਸੈਟਿੰਗਾਂ ਦਸਤੀ ਦਖਲ ਤੋਂ ਬਿਨਾਂ ਇੱਕ CIS ਪੱਧਰ 1 ਸਕੈਨ ਪਾਸ ਕਰਨ ਲਈ ਪਹਿਲਾਂ ਤੋਂ ਸੰਰਚਿਤ ਹਨ। ਦੂਜਾ, ਇਹ FIPS 140-2 ਅਨੁਕੂਲ ਹੈ, ਇਸ ਨੂੰ ਸਰਕਾਰੀ ਅਤੇ ਨਿਯੰਤ੍ਰਿਤ-ਉਦਯੋਗ ਤੈਨਾਤੀਆਂ ਲਈ ਢੁਕਵਾਂ ਬਣਾਉਂਦਾ ਹੈ। ਤੀਜਾ, ਇਹ ਕੰਟੇਨਰ ਨੂੰ ਸਿੱਧਾ ਏਮਬੇਡ ਕਰਦਾ ਹੈ ਅਤੇ ਇਸਦੀ ਆਪਣੀ ਸੀਐਨਆਈ (ਤੁਹਾਡੀ ਸੰਰਚਨਾ ਦੀ ਚੋਣ 'ਤੇ ਨਿਰਭਰ ਕਰਦਿਆਂ ਨਹਿਰ ਜਾਂ ਸੀਲੀਅਮ) ਨਾਲ ਭੇਜਦਾ ਹੈ, ਬਾਹਰੀ ਨਿਰਭਰਤਾ ਦੇ ਸਤਹ ਖੇਤਰ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ ਜਿਸਦੀ ਤੁਹਾਨੂੰ ਪ੍ਰਬੰਧਨ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ।

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"

ਹਰੀਜ਼ੋਂਟਲ ਪੋਡ ਆਟੋਸਕੇਲਰ

ਹਰੀਜ਼ੋਂਟਲ ਪੋਡ ਆਟੋਸਕੇਲਰ (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 ਅਤੇ ਮੈਮੋਰੀ ਬੇਨਤੀਆਂ ਨੂੰ ਸੱਜਾ ਆਕਾਰ ਦਿੰਦਾ ਹੈ। ਇਹ ਇੱਕ ਆਮ ਸਮੱਸਿਆ ਨੂੰ ਸੰਬੋਧਿਤ ਕਰਦਾ ਹੈ: ਡਿਵੈਲਪਰ ਅਨੁਮਾਨਾਂ ਦੇ ਅਧਾਰ ਤੇ ਸ਼ੁਰੂਆਤੀ ਸਰੋਤ ਬੇਨਤੀਆਂ ਸੈਟ ਕਰਦੇ ਹਨ, ਅਤੇ ਉਹ ਮੁੱਲ ਕਦੇ ਵੀ ਅੱਪਡੇਟ ਨਹੀਂ ਹੁੰਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਜਾਂ ਤਾਂ ਫਾਲਤੂ ਓਵਰ-ਪ੍ਰੋਵਿਜ਼ਨਿੰਗ ਜਾਂ ਓ.ਓ.ਐਮ.ਕਿਲਡ ਪੌਡਜ਼ ਨੂੰ ਲੋਡ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

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ਦੀ ਵਰਤੋਂ ਕਰੋ ਜਿੱਥੇ ਵਧੀਆ ਨਿਯੰਤਰਣ ਦੀ ਲੋੜ ਹੈ।

ਕਲੱਸਟਰ ਆਟੋਸਕੇਲਰ

Pod ਆਟੋਸਕੇਲਰ ਮੌਜੂਦਾ ਨੋਡ ਸਮਰੱਥਾ ਦੇ ਅੰਦਰ ਕੰਮ ਕਰਦੇ ਹਨ। ਜਦੋਂ ਉਹ ਸਮਰੱਥਾ ਖਤਮ ਹੋ ਜਾਂਦੀ ਹੈ — ਪੌਡਜ਼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

ਸਰੋਤ ਕੋਟਾ ਅਤੇ ਸੀਮਾ ਰੇਂਜ

ਬਹੁ-ਕਿਰਾਏਦਾਰ ਕਲੱਸਟਰਾਂ ਵਿੱਚ — ਜਿੱਥੇ ਵੱਖ-ਵੱਖ ਟੀਮਾਂ ਜਾਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਇੱਕੋ ਭੌਤਿਕ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਨੂੰ ਸਾਂਝਾ ਕਰਦੀਆਂ ਹਨ — ਰਿਸੋਰਸਕੁਓਟਾ ਅਤੇ ਸੀਮਾ ਰੇਂਜਾਂ ਜ਼ਰੂਰੀ ਗਾਰਡਰੇਲ ਹਨ। ResourceQuotas ਇੱਕ ਨੇਮਸਪੇਸ ਦੇ ਅੰਦਰ ਕੁੱਲ ਸਰੋਤ ਖਪਤ 'ਤੇ ਹਾਰਡ ਕੈਪਸ ਸੈੱਟ ਕਰਦਾ ਹੈ। ਸੀਮਾ ਰੇਂਜਾਂ ਨੇ ਵਿਅਕਤੀਗਤ ਕੰਟੇਨਰਾਂ ਲਈ ਡਿਫੌਲਟ ਅਤੇ ਅਧਿਕਤਮ ਮੁੱਲ ਸੈੱਟ ਕੀਤੇ ਹਨ, ਇੱਕ ਗਲਤ ਸੰਰਚਨਾ ਕੀਤੀ ਤੈਨਾਤੀ ਨੂੰ ਬੇਅੰਤ ਸਰੋਤਾਂ ਦੀ ਬੇਨਤੀ ਕਰਨ ਤੋਂ ਰੋਕਦੇ ਹੋਏ।

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

RKE2 etcd ਮੈਟ੍ਰਿਕਸ ਨੂੰ ਉਜਾਗਰ ਕਰਦਾ ਹੈ ਜਦੋਂetcd-expose-metrics: trueਸਰਵਰ ਸੰਰਚਨਾ ਵਿੱਚ ਸੈੱਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇੱਕ ਸਰਵਿਸ ਮਾਨੀਟਰ ਸ਼ਾਮਲ ਕਰੋ ਤਾਂ ਕਿ 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 ਇੱਕ ਵਿਸਤ੍ਰਿਤ ਅਵਧੀ ਲਈ ਇਸਦੇ ਅਧਿਕਤਮ 'ਤੇ ਪਿੰਨ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਤਾਂ ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਟ੍ਰੈਫਿਕ ਤੁਹਾਡੀ ਮੌਜੂਦਾ ਸੀਲਿੰਗ ਤੋਂ ਵੱਧ ਗਿਆ ਹੈ। ਤੁਹਾਨੂੰ ਜਾਂ ਤਾਂ ਵੱਧ ਤੋਂ ਵੱਧ ਵਧਾਉਣ ਜਾਂ ਨੋਡ ਪੂਲ ਵਿੱਚ ਸਮਰੱਥਾ ਜੋੜਨ ਦੀ ਲੋੜ ਹੈ - ਅਤੇ ਤੁਸੀਂ ਅਗਲੀ ਸਪਾਈਕ ਤੋਂ ਪਹਿਲਾਂ ਇਸ ਬਾਰੇ ਜਾਣਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਇਸਦੇ ਦੌਰਾਨ ਨਹੀਂ।

ਉਤਪਾਦਨ ਦੇ ਵਧੀਆ ਅਭਿਆਸ

ਪੌਡ ਵਿਘਨ ਬਜਟ

ਇੱਕ PodDisruption Budget (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

ਸਿੱਟਾ

ਸਕੇਲਿੰਗ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਇੱਕ ਸਿੰਗਲ ਕੌਂਫਿਗਰੇਸ਼ਨ ਬਦਲਾਅ ਨਹੀਂ ਹੈ — ਇਹ ਇੰਟਰਲੌਕਿੰਗ ਸਮਰੱਥਾਵਾਂ ਦਾ ਇੱਕ ਸਿਸਟਮ ਹੈ ਜਿਸਨੂੰ ਇੱਕਠੇ ਡਿਜ਼ਾਇਨ ਅਤੇ ਸੰਚਾਲਿਤ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਹਰੀਜ਼ੱਟਲ ਪੋਡ ਆਟੋਸਕੇਲਿੰਗ ਵਰਕਲੋਡ ਪੱਧਰ 'ਤੇ ਥੋੜ੍ਹੇ ਸਮੇਂ ਲਈ ਟ੍ਰੈਫਿਕ ਬਰਸਟ ਨੂੰ ਹੈਂਡਲ ਕਰਦੀ ਹੈ। ਵਰਟੀਕਲ ਪੌਡ ਆਟੋਸਕੇਲਿੰਗ ਸਮੇਂ ਦੇ ਨਾਲ ਸਰੋਤ ਬੇਨਤੀਆਂ ਨੂੰ ਇਮਾਨਦਾਰ ਰੱਖਦੀ ਹੈ। ਕਲੱਸਟਰ ਆਟੋਸਕੇਲਰ ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਅੰਡਰਲਾਈੰਗ ਨੋਡ ਸਮਰੱਥਾ ਤੁਹਾਡੇ ਪੌਡ ਆਟੋਸਕੇਲਰ ਦੀ ਸਮੁੱਚੀ ਮੰਗ ਨੂੰ ਟਰੈਕ ਕਰਦੀ ਹੈ। ਨੋਡ ਪੂਲ ਅਤੇ ਟੌਪੋਲੋਜੀ ਪਾਬੰਦੀਆਂ ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦੀਆਂ ਹਨ ਕਿ ਵਰਕਲੋਡ ਸਹੀ ਹਾਰਡਵੇਅਰ 'ਤੇ ਉਤਰਦਾ ਹੈ। ਸਰੋਤ ਕੋਟਾ ਅਤੇ ਸੀਮਾ ਰੇਂਜ ਕਿਰਾਏਦਾਰਾਂ ਨੂੰ ਇੱਕ ਦੂਜੇ ਤੋਂ ਬਚਾਉਂਦੇ ਹਨ। PodDisruptionਬਜਟ ਅਤੇ ਟੌਪੌਲੋਜੀ ਫੈਲਣ ਦੀਆਂ ਰੁਕਾਵਟਾਂ ਉਪਲਬਧਤਾ ਨੂੰ ਸਖ਼ਤ ਕਰਦੀਆਂ ਹਨ। ਅਤੇ Grafana ਦੇ ਨਾਲ Prometheus ਤੁਹਾਡੀ ਟੀਮ ਨੂੰ ਆਊਟੇਜ ਬਣਨ ਤੋਂ ਪਹਿਲਾਂ ਡਿਗਰੇਡੇਸ਼ਨ ਦਾ ਪਤਾ ਲਗਾਉਣ ਦੀ ਦਿੱਖ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।

RKE2 ਉਤਪਾਦਨ ਵਿੱਚ ਆਪਣਾ ਸਥਾਨ ਬਿਲਕੁਲ ਸਹੀ ਢੰਗ ਨਾਲ ਕਮਾਉਂਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਇਸ ਸਟੈਕ ਦੇ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਹਿੱਸੇ ਨੂੰ ਪਹਿਲਾਂ ਤੋਂ ਸਖ਼ਤ ਅਤੇ ਪਹਿਲਾਂ ਤੋਂ ਏਕੀਕ੍ਰਿਤ ਕਰਦਾ ਹੈ। ਤੁਹਾਡੀ ਜ਼ਿੰਮੇਵਾਰੀ ਨੌਬਸ ਨੂੰ ਸਮਝਣਾ, ਉਹਨਾਂ ਨੂੰ ਤੁਹਾਡੇ ਕੰਮ ਦੇ ਭਾਰ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨਾਲ ਜੋੜਨਾ, ਅਤੇ ਸੰਚਾਲਨ ਅਨੁਸ਼ਾਸਨ ਬਣਾਉਣਾ ਹੈ — ਰਨਬੁੱਕ, ਅਲਰਟ ਰੂਟਿੰਗ, ਅਪਗ੍ਰੇਡ ਕੈਡੈਂਸ, ਬੈਕਅੱਪ ਪ੍ਰਮਾਣਿਕਤਾ — ਜੋ ਕਿ ਇੱਕ ਚੰਗੀ ਤਰ੍ਹਾਂ ਸੰਰਚਿਤ ਕਲੱਸਟਰ ਨੂੰ ਇੱਕ ਸੱਚਮੁੱਚ ਭਰੋਸੇਯੋਗ ਪਲੇਟਫਾਰਮ ਵਿੱਚ ਬਦਲਦਾ ਹੈ।