🥇ಕುಬರ್ನೆಟ್ಸ್ ಪಾಡ್ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಪ್ರವೇಶಿಸುವುದು ಹೇಗೆ

ತೋಹಾದ್ ಅವರಿಂದ ಬಹುಮಾನ

ಕುಬರ್ನೆಟ್ಸ್ನೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸುವಾಗ, ಕಂಟೇನರ್ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹೊಂದಿಸುವುದನ್ನು ಮರೆತುಬಿಡುವುದು ಸಾಮಾನ್ಯವಾಗಿದೆ. ಈ ಹಂತದಲ್ಲಿ, ಡಾಕರ್ ಚಿತ್ರವು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ಗೆ ನಿಯೋಜಿಸಬಹುದು ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಸಾಕು.

ಆದರೆ ನಂತರ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಇತರ ಅಪ್ಲಿಕೇಶನ್‌ಗಳೊಂದಿಗೆ ಉತ್ಪಾದನಾ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ನಿಯೋಜಿಸಬೇಕಾಗುತ್ತದೆ. ಇದನ್ನು ಮಾಡಲು, ನೀವು ಕಂಟೇನರ್‌ಗಾಗಿ ಸಂಪನ್ಮೂಲಗಳನ್ನು ನಿಯೋಜಿಸಬೇಕು ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಪಡೆಯಲು ಮತ್ತು ಚಾಲನೆಯಲ್ಲಿರಲು ಅವುಗಳಲ್ಲಿ ಸಾಕಷ್ಟು ಇವೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ ಮತ್ತು ಇತರ ಚಾಲನೆಯಲ್ಲಿರುವ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಸಮಸ್ಯೆಗಳನ್ನು ಅನುಭವಿಸುವುದಿಲ್ಲ.

ತಂಡದ Mail.ru ನಿಂದ Kubernetes aaS ಕಂಟೈನರ್ ಸಂಪನ್ಮೂಲಗಳು (CPU & MEM), ವಿನಂತಿಗಳು ಮತ್ತು ಸಂಪನ್ಮೂಲ ಮಿತಿಗಳ ಕುರಿತು ಲೇಖನವನ್ನು ಅನುವಾದಿಸಲಾಗಿದೆ. ಈ ಸೆಟ್ಟಿಂಗ್‌ಗಳ ಪ್ರಯೋಜನಗಳನ್ನು ಮತ್ತು ನೀವು ಅವುಗಳನ್ನು ಹೊಂದಿಸದಿದ್ದರೆ ಏನಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನೀವು ಕಲಿಯುವಿರಿ.

ಕಂಪ್ಯೂಟಿಂಗ್ ಸಂಪನ್ಮೂಲಗಳು

ನಾವು ಈ ಕೆಳಗಿನ ಘಟಕಗಳೊಂದಿಗೆ ಎರಡು ರೀತಿಯ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ:

ಕೇಂದ್ರ ಸಂಸ್ಕರಣಾ ಘಟಕ (CPU) - ಕೋರ್ಗಳು;
ಮೆಮೊರಿ (MEM) - ಬೈಟ್‌ಗಳು.

ಪ್ರತಿ ಕಂಟೇನರ್‌ಗೆ ಸಂಪನ್ಮೂಲಗಳನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಲಾಗಿದೆ. ಕೆಳಗಿನ Pod YAML ಫೈಲ್‌ನಲ್ಲಿ, ವಿನಂತಿಸಿದ ಮತ್ತು ಮಿತಿ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಒಳಗೊಂಡಿರುವ ಸಂಪನ್ಮೂಲ ವಿಭಾಗವನ್ನು ನೀವು ನೋಡುತ್ತೀರಿ:

ವಿನಂತಿಸಿದ ಪಾಡ್ ಸಂಪನ್ಮೂಲಗಳು = ಎಲ್ಲಾ ಕಂಟೈನರ್‌ಗಳ ವಿನಂತಿಸಿದ ಸಂಪನ್ಮೂಲಗಳ ಮೊತ್ತ;
ಪಾಡ್ ಸಂಪನ್ಮೂಲ ಮಿತಿ = ಎಲ್ಲಾ ಪಾಡ್ ಸಂಪನ್ಮೂಲ ಮಿತಿಗಳ ಮೊತ್ತ.

apiVersion: v1
kind: Pod
metadata:
  name: backend-pod-name
  labels:
    application: backend
spec:
  containers:
    — name: main-container
      image: my-backend
      tag: v1
      ports:
      — containerPort: 8080
      resources:
        requests:
          cpu: 0.2 # REQUESTED CPU: 200m cores
          memory: "1Gi" # REQUESTED MEM: 1Gi
        limits:
          cpu: 1 # MAX CPU USAGE: 1 core
          memory: "1Gi" # MAX MEM USAGE:  1Gi
    — name: other-container
      image: other-app
      tag: v1
      ports:
      — containerPort: 8000
      resources:
        requests:
          cpu: "200m" # REQUESTED CPU: 200m cores
          memory: "0.5Gi" # REQUESTED MEM: 0.5Gi
        limits:
          cpu: 1 # MAX CPU USAGE: 1 core
          memory: "1Gi" # MAX MEM USAGE:  1Gi

ವಿನಂತಿಸಿದ ಮತ್ತು ಸೀಮಿತ ಸಂಪನ್ಮೂಲಗಳ ಉದಾಹರಣೆ

ಕ್ಷೇತ್ರ resources.requested ವಿಶೇಷಣದಿಂದ ಪಾಡ್ ಅಪೇಕ್ಷಿತ ನೋಡ್ ಅನ್ನು ಕಂಡುಹಿಡಿಯಲು ಬಳಸುವ ಅಂಶಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ. ಇದಕ್ಕಾಗಿ ನೀವು ಈಗಾಗಲೇ ಪಾಡ್ ನಿಯೋಜನೆಯನ್ನು ಯೋಜಿಸಬಹುದು. ಸೂಕ್ತವಾದ ನೋಡ್ ಅನ್ನು ಹೇಗೆ ಕಂಡುಹಿಡಿಯುವುದು?

ಕುಬರ್ನೆಟ್ಸ್ ಮಾಸ್ಟರ್ ನೋಡ್ ಅಥವಾ ಮಾಸ್ಟರ್ ನೋಡ್ (ಕುಬರ್ನೆಟ್ಸ್ ಕಂಟ್ರೋಲ್ ಪ್ಲೇನ್) ಸೇರಿದಂತೆ ಹಲವಾರು ಘಟಕಗಳನ್ನು ಒಳಗೊಂಡಿದೆ. ಮಾಸ್ಟರ್ ನೋಡ್ ಹಲವಾರು ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಹೊಂದಿದೆ: kube-apiserver, kube-controller-manager ಮತ್ತು kube-scheduler.

ಹೊಸದಾಗಿ ರಚಿಸಲಾದ ಪಾಡ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸಲು ಮತ್ತು ವಿನಂತಿಸಿದ ಸಂಪನ್ಮೂಲಗಳ ಸಂಖ್ಯೆ ಸೇರಿದಂತೆ ಎಲ್ಲಾ ಪಾಡ್ ವಿನಂತಿಗಳಿಗೆ ಹೊಂದಿಕೆಯಾಗುವ ಸಂಭವನೀಯ ವರ್ಕರ್ ನೋಡ್‌ಗಳನ್ನು ಹುಡುಕಲು kube-ಶೆಡ್ಯೂಲರ್ ಪ್ರಕ್ರಿಯೆಯು ಕಾರಣವಾಗಿದೆ. kube-ಶೆಡ್ಯೂಲರ್‌ನಿಂದ ಕಂಡುಬರುವ ನೋಡ್‌ಗಳ ಪಟ್ಟಿಯನ್ನು ಶ್ರೇಣೀಕರಿಸಲಾಗಿದೆ. ಹೆಚ್ಚಿನ ಸ್ಕೋರ್‌ಗಳೊಂದಿಗೆ ನೋಡ್‌ನಲ್ಲಿ ಪಾಡ್ ಅನ್ನು ನಿಗದಿಪಡಿಸಲಾಗಿದೆ.

ನೇರಳೆ ಪಾಡ್ ಅನ್ನು ಎಲ್ಲಿ ಇರಿಸಲಾಗುತ್ತದೆ?

ಕ್ಯೂಬ್-ಶೆಡ್ಯೂಲರ್ ಹೊಸ ನೇರಳೆ ಪಾಡ್ ಅನ್ನು ನಿಗದಿಪಡಿಸಬೇಕೆಂದು ನೀವು ಚಿತ್ರದಲ್ಲಿ ನೋಡಬಹುದು. ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್ ಎರಡು ನೋಡ್‌ಗಳನ್ನು ಹೊಂದಿದೆ: A ಮತ್ತು B. ನೀವು ನೋಡುವಂತೆ, kube-ಶೆಡ್ಯೂಲರ್ ನೋಡ್ A ನಲ್ಲಿ ಪಾಡ್ ಅನ್ನು ನಿಗದಿಪಡಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ - ಲಭ್ಯವಿರುವ (ಅಪೇಕ್ಷಿಸದ) ಸಂಪನ್ಮೂಲಗಳು ನೇರಳೆ ಪಾಡ್‌ನ ವಿನಂತಿಗಳಿಗೆ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ, ಪರ್ಪಲ್ ಪಾಡ್‌ನಿಂದ ವಿನಂತಿಸಿದ 1 GB ಮೆಮೊರಿಯು ನೋಡ್ A ನಲ್ಲಿ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಲಭ್ಯವಿರುವ ಮೆಮೊರಿಯು 0,5 GB ಆಗಿದೆ. ಆದರೆ ನೋಡ್ ಬಿ ಸಾಕಷ್ಟು ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹೊಂದಿದೆ. ಪರಿಣಾಮವಾಗಿ, ಕ್ಯೂಬ್-ಶೆಡ್ಯೂಲರ್ ಕೆನ್ನೇರಳೆ ಪಾಡ್‌ನ ಗಮ್ಯಸ್ಥಾನವು ನೋಡ್ ಬಿ ಎಂದು ನಿರ್ಧರಿಸುತ್ತಾನೆ.

ವಿನಂತಿಸಿದ ಸಂಪನ್ಮೂಲಗಳು ಪಾಡ್ ಅನ್ನು ಚಲಾಯಿಸಲು ನೋಡ್‌ನ ಆಯ್ಕೆಯ ಮೇಲೆ ಹೇಗೆ ಪರಿಣಾಮ ಬೀರುತ್ತವೆ ಎಂದು ಈಗ ನಮಗೆ ತಿಳಿದಿದೆ. ಆದರೆ ಕನಿಷ್ಠ ಸಂಪನ್ಮೂಲಗಳ ಪರಿಣಾಮವೇನು?

ಸಂಪನ್ಮೂಲ ಮಿತಿಯು CPU/MEM ದಾಟಲು ಸಾಧ್ಯವಾಗದ ಗಡಿಯಾಗಿದೆ. ಆದಾಗ್ಯೂ, CPU ಸಂಪನ್ಮೂಲವು ಹೊಂದಿಕೊಳ್ಳುತ್ತದೆ, ಆದ್ದರಿಂದ CPU ಮಿತಿಗಳನ್ನು ತಲುಪುವ ಕಂಟೈನರ್‌ಗಳು ಪಾಡ್‌ನಿಂದ ನಿರ್ಗಮಿಸಲು ಕಾರಣವಾಗುವುದಿಲ್ಲ. ಬದಲಿಗೆ, CPU ಥ್ರೊಟ್ಲಿಂಗ್ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ. MEM ಬಳಕೆಯ ಮಿತಿಯನ್ನು ತಲುಪಿದರೆ, OOM-ಕಿಲ್ಲರ್ ಕಾರಣದಿಂದಾಗಿ ಕಂಟೇನರ್ ಅನ್ನು ನಿಲ್ಲಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಮರುಪ್ರಾರಂಭಿಸುವಿಕೆ ನೀತಿ ಸೆಟ್ಟಿಂಗ್ ಮೂಲಕ ಅನುಮತಿಸಿದರೆ ಮರುಪ್ರಾರಂಭಿಸಲಾಗುತ್ತದೆ.

ವಿನಂತಿಸಿದ ಮತ್ತು ಗರಿಷ್ಠ ಸಂಪನ್ಮೂಲಗಳನ್ನು ವಿವರವಾಗಿ

ಡಾಕರ್ ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್ ನಡುವಿನ ಸಂಪನ್ಮೂಲ ಸಂವಹನ

ಸಂಪನ್ಮೂಲ ವಿನಂತಿಗಳು ಮತ್ತು ಸಂಪನ್ಮೂಲ ಮಿತಿಗಳು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ ಎಂಬುದನ್ನು ವಿವರಿಸಲು ಉತ್ತಮ ಮಾರ್ಗವೆಂದರೆ ಕುಬರ್ನೆಟ್ಸ್ ಮತ್ತು ಡಾಕರ್ ನಡುವಿನ ಸಂಬಂಧವನ್ನು ಪರಿಚಯಿಸುವುದು. ಮೇಲಿನ ಚಿತ್ರದಲ್ಲಿ ನೀವು ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಷೇತ್ರಗಳು ಮತ್ತು ಡಾಕರ್ ಸ್ಟಾರ್ಟ್ಅಪ್ ಫ್ಲ್ಯಾಗ್‌ಗಳು ಹೇಗೆ ಸಂಬಂಧಿಸಿವೆ ಎಂಬುದನ್ನು ನೋಡಬಹುದು.

ಮೆಮೊರಿ: ವಿನಂತಿ ಮತ್ತು ಮಿತಿ

containers:
...
 resources:
   requests:
     memory: "0.5Gi"
   limits:
     memory: "1Gi"

ಮೇಲೆ ಹೇಳಿದಂತೆ, ಮೆಮೊರಿಯನ್ನು ಬೈಟ್‌ಗಳಲ್ಲಿ ಅಳೆಯಲಾಗುತ್ತದೆ. ಆಧಾರಿತ ಕುಬರ್ನೆಟ್ಸ್ ದಸ್ತಾವೇಜನ್ನು, ನಾವು ಮೆಮೊರಿಯನ್ನು ಸಂಖ್ಯೆಯಾಗಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಬಹುದು. ಸಾಮಾನ್ಯವಾಗಿ ಇದು ಪೂರ್ಣಾಂಕವಾಗಿದೆ, ಉದಾಹರಣೆಗೆ 2678 - ಅಂದರೆ, 2678 ಬೈಟ್‌ಗಳು. ನೀವು ಪ್ರತ್ಯಯಗಳನ್ನು ಸಹ ಬಳಸಬಹುದು G и Gi, ಮುಖ್ಯ ವಿಷಯವೆಂದರೆ ಅವರು ಸಮಾನವಾಗಿಲ್ಲ ಎಂದು ನೆನಪಿಟ್ಟುಕೊಳ್ಳುವುದು. ಮೊದಲನೆಯದು ದಶಮಾಂಶ ಮತ್ತು ಎರಡನೆಯದು ಬೈನರಿ. k8s ದಸ್ತಾವೇಜನ್ನು ಉಲ್ಲೇಖಿಸಿರುವ ಉದಾಹರಣೆಯಂತೆ: 128974848, 129e6, 129M, 123Mi - ಅವು ಪ್ರಾಯೋಗಿಕವಾಗಿ ಸಮಾನವಾಗಿವೆ.

ಕುಬರ್ನೆಟ್ಸ್ ಆಯ್ಕೆ limits.memory ಧ್ವಜಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗುತ್ತದೆ --memory ಡಾಕರ್ ನಿಂದ. ಸಂದರ್ಭದಲ್ಲಿ request.memory ಡಾಕರ್‌ಗೆ ಯಾವುದೇ ಬಾಣವಿಲ್ಲ ಏಕೆಂದರೆ ಡಾಕರ್ ಈ ಕ್ಷೇತ್ರವನ್ನು ಬಳಸುವುದಿಲ್ಲ. ನೀವು ಕೇಳಬಹುದು, ಇದು ಸಹ ಅಗತ್ಯವಿದೆಯೇ? ಹೌದು ಬೇಕು. ನಾನು ಮೊದಲೇ ಹೇಳಿದಂತೆ, ಕುಬರ್ನೆಟ್ಸ್ಗೆ ಕ್ಷೇತ್ರವು ಮುಖ್ಯವಾಗಿದೆ. ಅದರ ಮಾಹಿತಿಯ ಆಧಾರದ ಮೇಲೆ, ಪಾಡ್ ಅನ್ನು ಯಾವ ನೋಡ್ ಅನ್ನು ನಿಗದಿಪಡಿಸಬೇಕೆಂದು kube-ಶೆಡ್ಯೂಲರ್ ನಿರ್ಧರಿಸುತ್ತದೆ.

ವಿನಂತಿಗಾಗಿ ನೀವು ಸಾಕಷ್ಟು ಮೆಮೊರಿಯನ್ನು ಹೊಂದಿಸಿದರೆ ಏನಾಗುತ್ತದೆ?

ಕಂಟೇನರ್ ವಿನಂತಿಸಿದ ಮೆಮೊರಿಯ ಮಿತಿಯನ್ನು ತಲುಪಿದ್ದರೆ, ನೋಡ್‌ನಲ್ಲಿ ಸಾಕಷ್ಟು ಮೆಮೊರಿ ಇಲ್ಲದಿದ್ದಾಗ ನಿಲ್ಲುವ ಪಾಡ್‌ಗಳ ಗುಂಪಿನಲ್ಲಿ ಪಾಡ್ ಅನ್ನು ಇರಿಸಲಾಗುತ್ತದೆ.

ನೀವು ಮೆಮೊರಿ ಮಿತಿಯನ್ನು ತುಂಬಾ ಕಡಿಮೆ ಹೊಂದಿಸಿದರೆ ಏನಾಗುತ್ತದೆ?

ಕಂಟೇನರ್ ಮೆಮೊರಿ ಮಿತಿಯನ್ನು ಮೀರಿದರೆ, OOM-Killed ಕಾರಣದಿಂದಾಗಿ ಅದನ್ನು ಕೊನೆಗೊಳಿಸಲಾಗುತ್ತದೆ. ಮತ್ತು ಡೀಫಾಲ್ಟ್ ಮೌಲ್ಯವಿರುವ RestartPolicy ಅನ್ನು ಆಧರಿಸಿ ಸಾಧ್ಯವಾದರೆ ಮರುಪ್ರಾರಂಭಿಸುತ್ತದೆ Always.

ನೀವು ವಿನಂತಿಸಿದ ಮೆಮೊರಿಯನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸದಿದ್ದರೆ ಏನಾಗುತ್ತದೆ?

ಕುಬರ್ನೆಟ್ಸ್ ಮಿತಿ ಮೌಲ್ಯವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಡೀಫಾಲ್ಟ್ ಮೌಲ್ಯವಾಗಿ ಹೊಂದಿಸುತ್ತದೆ.

ನೀವು ಮೆಮೊರಿ ಮಿತಿಯನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸದಿದ್ದರೆ ಏನಾಗಬಹುದು?

ಕಂಟೇನರ್ ಯಾವುದೇ ನಿರ್ಬಂಧಗಳನ್ನು ಹೊಂದಿಲ್ಲ; ಅದು ಬಯಸಿದಷ್ಟು ಮೆಮೊರಿಯನ್ನು ಬಳಸಬಹುದು. ಅವನು ನೋಡ್‌ನ ಲಭ್ಯವಿರುವ ಎಲ್ಲಾ ಮೆಮೊರಿಯನ್ನು ಬಳಸಲು ಪ್ರಾರಂಭಿಸಿದರೆ, OOM ಅವನನ್ನು ಕೊಲ್ಲುತ್ತದೆ. ಮರುಪ್ರಾರಂಭದ ನೀತಿಯ ಆಧಾರದ ಮೇಲೆ ಸಾಧ್ಯವಾದರೆ ಕಂಟೇನರ್ ಅನ್ನು ಮರುಪ್ರಾರಂಭಿಸಲಾಗುತ್ತದೆ.

ನೀವು ಮೆಮೊರಿ ಮಿತಿಗಳನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸದಿದ್ದರೆ ಏನಾಗುತ್ತದೆ?

ಇದು ಅತ್ಯಂತ ಕೆಟ್ಟ ಸನ್ನಿವೇಶವಾಗಿದೆ: ಕಂಟೇನರ್‌ಗೆ ಎಷ್ಟು ಸಂಪನ್ಮೂಲಗಳು ಬೇಕು ಎಂದು ಶೆಡ್ಯೂಲರ್‌ಗೆ ತಿಳಿದಿಲ್ಲ, ಮತ್ತು ಇದು ನೋಡ್‌ನಲ್ಲಿ ಗಂಭೀರ ಸಮಸ್ಯೆಗಳನ್ನು ಉಂಟುಮಾಡಬಹುದು. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ನೇಮ್‌ಸ್ಪೇಸ್‌ನಲ್ಲಿ ಡೀಫಾಲ್ಟ್ ಮಿತಿಗಳನ್ನು ಹೊಂದಿರುವುದು ಒಳ್ಳೆಯದು (ಲಿಮಿಟ್‌ರೇಂಜ್‌ನಿಂದ ಹೊಂದಿಸಲಾಗಿದೆ). ಯಾವುದೇ ಡೀಫಾಲ್ಟ್ ಮಿತಿಗಳಿಲ್ಲ - ಪಾಡ್‌ಗೆ ಯಾವುದೇ ಮಿತಿಗಳಿಲ್ಲ, ಅದು ಬಯಸಿದಷ್ಟು ಮೆಮೊರಿಯನ್ನು ಬಳಸಬಹುದು.

ವಿನಂತಿಸಿದ ಮೆಮೊರಿಯು ನೋಡ್ ನೀಡುವುದಕ್ಕಿಂತ ಹೆಚ್ಚಿನದಾಗಿದ್ದರೆ, ಪಾಡ್ ಅನ್ನು ನಿಗದಿಪಡಿಸಲಾಗುವುದಿಲ್ಲ. ಅದನ್ನು ನೆನಪಿಟ್ಟುಕೊಳ್ಳುವುದು ಬಹಳ ಮುಖ್ಯ Requests.memory - ಕನಿಷ್ಠ ಮೌಲ್ಯವಲ್ಲ. ಇದು ಕಂಟೇನರ್ ಅನ್ನು ನಿರಂತರವಾಗಿ ಚಾಲನೆಯಲ್ಲಿಡಲು ಸಾಕಾಗುವಷ್ಟು ಮೆಮೊರಿಯ ವಿವರಣೆಯಾಗಿದೆ.

ಸಾಮಾನ್ಯವಾಗಿ ಒಂದೇ ಮೌಲ್ಯವನ್ನು ಹೊಂದಿಸಲು ಸೂಚಿಸಲಾಗುತ್ತದೆ request.memory и limit.memory. ಇದು ಪಾಡ್ ಅನ್ನು ರನ್ ಮಾಡಲು ಸಾಕಷ್ಟು ಮೆಮೊರಿಯನ್ನು ಹೊಂದಿರುವ ನೋಡ್‌ನಲ್ಲಿ ಕುಬರ್ನೆಟ್ಸ್ ಪಾಡ್ ಅನ್ನು ನಿಗದಿಪಡಿಸುವುದಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸುತ್ತದೆ ಆದರೆ ಅದನ್ನು ಚಲಾಯಿಸಲು ಸಾಕಾಗುವುದಿಲ್ಲ. ನೆನಪಿನಲ್ಲಿಡಿ: ಕುಬರ್ನೆಟ್ಸ್ ಪಾಡ್ ಯೋಜನೆ ಮಾತ್ರ ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ requests.memoryಮತ್ತು limits.memory ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳುವುದಿಲ್ಲ.

CPU: ವಿನಂತಿ ಮತ್ತು ಮಿತಿ

containers:
...
 resources:
   requests:
     cpu: 1
   limits:
     cpu: "1200m"

CPU ನೊಂದಿಗೆ ಎಲ್ಲವೂ ಸ್ವಲ್ಪ ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗಿದೆ. ಕುಬರ್ನೆಟ್ಸ್ ಮತ್ತು ಡಾಕರ್ ನಡುವಿನ ಸಂಬಂಧದ ಚಿತ್ರಕ್ಕೆ ಹಿಂತಿರುಗಿ, ನೀವು ಅದನ್ನು ನೋಡಬಹುದು request.cpu ಗೆ ಅನುರೂಪವಾಗಿದೆ --cpu-shares, ಆದರೆ limit.cpu ಧ್ವಜಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗುತ್ತದೆ cpus ಡಾಕರ್‌ನಲ್ಲಿ.

ಕುಬರ್ನೆಟ್ಸ್ ವಿನಂತಿಸುವ CPU ಅನ್ನು 1024 ರಿಂದ ಗುಣಿಸಲಾಗುತ್ತದೆ, ಇದು CPU ಚಕ್ರಗಳ ಅನುಪಾತವಾಗಿದೆ. ನೀವು 1 ಪೂರ್ಣ ಕೋರ್ ಅನ್ನು ವಿನಂತಿಸಲು ಬಯಸಿದರೆ, ನೀವು ಸೇರಿಸಬೇಕು cpu: 1ಮೇಲೆ ತೋರಿಸಿರುವಂತೆ.

ಪೂರ್ಣ ಕರ್ನಲ್ ಅನ್ನು ವಿನಂತಿಸುವುದು (ಅನುಪಾತ = 1024) ನಿಮ್ಮ ಕಂಟೇನರ್ ಅದನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ ಎಂದರ್ಥವಲ್ಲ. ನಿಮ್ಮ ಹೋಸ್ಟ್ ಯಂತ್ರವು ಕೇವಲ ಒಂದು ಕೋರ್ ಅನ್ನು ಹೊಂದಿದ್ದರೆ ಮತ್ತು ನೀವು ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ಕಂಟೇನರ್‌ಗಳನ್ನು ಚಲಾಯಿಸುತ್ತಿದ್ದರೆ, ಎಲ್ಲಾ ಕಂಟೇನರ್‌ಗಳು ಅವುಗಳ ನಡುವೆ ಲಭ್ಯವಿರುವ CPU ಅನ್ನು ಹಂಚಿಕೊಳ್ಳಬೇಕು. ಇದು ಹೇಗೆ ಸಂಭವಿಸುತ್ತದೆ? ಚಿತ್ರವನ್ನು ನೋಡೋಣ.

CPU ವಿನಂತಿ - ಸಿಂಗಲ್ ಕೋರ್ ಸಿಸ್ಟಮ್

ನೀವು ಸಿಂಗಲ್-ಕೋರ್ ಹೋಸ್ಟ್ ಸಿಸ್ಟಮ್ ರನ್ನಿಂಗ್ ಕಂಟೇನರ್‌ಗಳನ್ನು ಹೊಂದಿರುವಿರಿ ಎಂದು ಊಹಿಸೋಣ. ಮಾಮ್ (ಕುಬರ್ನೆಟೆಸ್) ಪೈ (ಸಿಪಿಯು) ಅನ್ನು ಬೇಯಿಸಿದರು ಮತ್ತು ಅದನ್ನು ಮಕ್ಕಳ ನಡುವೆ (ಧಾರಕಗಳು) ವಿಭಜಿಸಲು ಬಯಸುತ್ತಾರೆ. ಮೂರು ಮಕ್ಕಳಿಗೆ ಸಂಪೂರ್ಣ ಪೈ (ಅನುಪಾತ = 1024), ಇನ್ನೊಂದು ಮಗುವಿಗೆ ಅರ್ಧ ಪೈ (512) ಬೇಕು. ಮಾಮ್ ನ್ಯಾಯಯುತವಾಗಿರಲು ಬಯಸುತ್ತಾರೆ ಮತ್ತು ಸರಳವಾದ ಲೆಕ್ಕಾಚಾರವನ್ನು ಮಾಡುತ್ತಾರೆ.

# Сколько пирогов хотят дети?
# 3 ребенка хотят по целому пирогу и еще один хочет половину пирога
cakesNumberKidsWant = (3 * 1) + (1 * 0.5) = 3.5
# Выражение получается так:
3 (ребенка/контейнера) * 1 (целый пирог/полное ядро) + 1 (ребенок/контейнер) * 0.5 (половина пирога/половина ядра)
# Сколько пирогов испечено?
availableCakesNumber = 1
# Сколько пирога (максимально) дети реально могут получить?
newMaxRequest = 1 / 3.5 =~ 28%

ಲೆಕ್ಕಾಚಾರದ ಆಧಾರದ ಮೇಲೆ, ಮೂರು ಮಕ್ಕಳು 28% ಕೋರ್ ಅನ್ನು ಸ್ವೀಕರಿಸುತ್ತಾರೆ, ಮತ್ತು ಸಂಪೂರ್ಣ ಕೋರ್ ಅಲ್ಲ. ನಾಲ್ಕನೇ ಮಗುವಿಗೆ ಪೂರ್ಣ ಕರ್ನಲ್‌ನ 14% ಸಿಗುತ್ತದೆ, ಅರ್ಧವಲ್ಲ. ಆದರೆ ನೀವು ಮಲ್ಟಿ-ಕೋರ್ ಸಿಸ್ಟಮ್ ಹೊಂದಿದ್ದರೆ ವಿಷಯಗಳು ವಿಭಿನ್ನವಾಗಿರುತ್ತದೆ.

CPU ವಿನಂತಿ - ಮಲ್ಟಿ-ಕೋರ್ (4) ಸಿಸ್ಟಮ್

ಮೇಲಿನ ಚಿತ್ರದಲ್ಲಿ ಮೂರು ಮಕ್ಕಳಿಗೆ ಸಂಪೂರ್ಣ ಪೈ ಬೇಕು, ಮತ್ತು ಒಬ್ಬರಿಗೆ ಅರ್ಧ ಬೇಕು ಎಂದು ನೀವು ನೋಡಬಹುದು. ತಾಯಿ ನಾಲ್ಕು ಪೈಗಳನ್ನು ಬೇಯಿಸಿದ್ದರಿಂದ, ಅವರ ಪ್ರತಿಯೊಬ್ಬ ಮಕ್ಕಳು ತಮಗೆ ಬೇಕಾದಷ್ಟು ಪಡೆಯುತ್ತಾರೆ. ಬಹು-ಕೋರ್ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ, ಲಭ್ಯವಿರುವ ಎಲ್ಲಾ ಪ್ರೊಸೆಸರ್ ಕೋರ್‌ಗಳಲ್ಲಿ ಪ್ರೊಸೆಸರ್ ಸಂಪನ್ಮೂಲಗಳನ್ನು ವಿತರಿಸಲಾಗುತ್ತದೆ. ಕಂಟೇನರ್ ಒಂದಕ್ಕಿಂತ ಕಡಿಮೆ ಪೂರ್ಣ CPU ಕೋರ್‌ಗೆ ಸೀಮಿತವಾಗಿದ್ದರೆ, ಅದು ಇನ್ನೂ 100% ನಲ್ಲಿ ಅದನ್ನು ಬಳಸಬಹುದು.

ಕಂಟೈನರ್‌ಗಳಲ್ಲಿ CPU ಅನ್ನು ಹೇಗೆ ವಿತರಿಸಲಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಮೇಲಿನ ಲೆಕ್ಕಾಚಾರಗಳನ್ನು ಸರಳೀಕರಿಸಲಾಗಿದೆ. ಸಹಜವಾಗಿ, ಧಾರಕಗಳಲ್ಲದೆ, CPU ಸಂಪನ್ಮೂಲಗಳನ್ನು ಬಳಸುವ ಇತರ ಪ್ರಕ್ರಿಯೆಗಳಿವೆ. ಒಂದು ಪಾತ್ರೆಯಲ್ಲಿನ ಪ್ರಕ್ರಿಯೆಗಳು ನಿಷ್ಕ್ರಿಯವಾಗಿದ್ದಾಗ, ಇತರರು ಅದರ ಸಂಪನ್ಮೂಲವನ್ನು ಬಳಸಬಹುದು. CPU: "200m" ಗೆ ಅನುರೂಪವಾಗಿದೆ CPU: 0,2, ಅಂದರೆ ಒಂದು ಕೋರ್‌ನ ಸರಿಸುಮಾರು 20%.

ಈಗ ನಾವು ಮಾತನಾಡೋಣ limit.cpu. ಕುಬರ್ನೆಟ್ಸ್ ಮಿತಿಗಳನ್ನು ಹೊಂದಿರುವ CPU ಅನ್ನು 100 ರಿಂದ ಗುಣಿಸಲಾಗುತ್ತದೆ. ಇದರ ಫಲಿತಾಂಶವು ಕಂಟೇನರ್ ಪ್ರತಿ 100 µs ಅನ್ನು ಬಳಸಬಹುದಾದ ಸಮಯವಾಗಿದೆ (cpu-period).

limit.cpu ಡಾಕರ್ ಧ್ವಜಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗುತ್ತದೆ --cpus. ಇದು ಹಳೆಯದರ ಹೊಸ ಸಂಯೋಜನೆಯಾಗಿದೆ --cpu-period и --cpu-quota. ಇದನ್ನು ಹೊಂದಿಸುವ ಮೂಲಕ, ಥ್ರೊಟ್ಲಿಂಗ್ ಪ್ರಾರಂಭವಾಗುವ ಮೊದಲು ಕಂಟೇನರ್ ಗರಿಷ್ಠವಾಗಿ ಎಷ್ಟು ಲಭ್ಯವಿರುವ CPU ಸಂಪನ್ಮೂಲಗಳನ್ನು ನಾವು ಸೂಚಿಸುತ್ತೇವೆ:

ಸಿಪಸ್ - ಸಂಯೋಜನೆ cpu-period и cpu-quota. cpus = 1.5 ಹೊಂದಿಸುವುದಕ್ಕೆ ಸಮನಾಗಿರುತ್ತದೆ cpu-period = 100000 и cpu-quota = 150000;
CPU-ಅವಧಿ - ಅವಧಿ CPU CFS ಶೆಡ್ಯೂಲರ್, ಡೀಫಾಲ್ಟ್ 100 ಮೈಕ್ರೋಸೆಕೆಂಡ್‌ಗಳು;
cpu-ಕೋಟಾ - ಒಳಗೆ ಮೈಕ್ರೋಸೆಕೆಂಡ್‌ಗಳ ಸಂಖ್ಯೆ cpu-period, ಇದು ಕಂಟೇನರ್ನಿಂದ ಸುತ್ತುವರಿಯಲ್ಪಟ್ಟಿದೆ.

ನೀವು ಸಾಕಷ್ಟು ವಿನಂತಿಸಿದ CPU ಅನ್ನು ಸ್ಥಾಪಿಸಿದರೆ ಏನಾಗುತ್ತದೆ?

ಕಂಟೇನರ್‌ಗೆ ಅದು ಸ್ಥಾಪಿಸಿರುವುದಕ್ಕಿಂತ ಹೆಚ್ಚಿನ ಅಗತ್ಯವಿದ್ದರೆ, ಅದು ಇತರ ಪ್ರಕ್ರಿಯೆಗಳಿಂದ CPU ಅನ್ನು ಕದಿಯುತ್ತದೆ.

ನೀವು CPU ಮಿತಿಯನ್ನು ತುಂಬಾ ಕಡಿಮೆ ಹೊಂದಿಸಿದರೆ ಏನಾಗುತ್ತದೆ?

CPU ಸಂಪನ್ಮೂಲವು ಹೊಂದಾಣಿಕೆಯಾಗಿರುವುದರಿಂದ, ಥ್ರೊಟ್ಲಿಂಗ್ ಆನ್ ಆಗುತ್ತದೆ.

ನೀವು CPU ವಿನಂತಿಯನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸದಿದ್ದರೆ ಏನಾಗುತ್ತದೆ?

ಮೆಮೊರಿಯಂತೆ, ವಿನಂತಿಯ ಮೌಲ್ಯವು ಮಿತಿಗೆ ಸಮಾನವಾಗಿರುತ್ತದೆ.

ನೀವು CPU ಮಿತಿಯನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸದಿದ್ದರೆ ಏನಾಗುತ್ತದೆ?

ಕಂಟೇನರ್ ಅಗತ್ಯವಿರುವಷ್ಟು CPU ಅನ್ನು ಬಳಸುತ್ತದೆ. ನೇಮ್‌ಸ್ಪೇಸ್‌ನಲ್ಲಿ ಡೀಫಾಲ್ಟ್ ಸಿಪಿಯು ನೀತಿಯನ್ನು (ಲಿಮಿಟ್‌ರೇಂಜ್) ವ್ಯಾಖ್ಯಾನಿಸಿದರೆ, ಈ ಮಿತಿಯನ್ನು ಕಂಟೇನರ್‌ಗೆ ಸಹ ಬಳಸಲಾಗುತ್ತದೆ.

ನೀವು ವಿನಂತಿಯನ್ನು ಅಥವಾ CPU ಮಿತಿಯನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸದಿದ್ದರೆ ಏನಾಗುತ್ತದೆ?

ಮೆಮೊರಿಯಂತೆಯೇ, ಇದು ಅತ್ಯಂತ ಕೆಟ್ಟ ಸನ್ನಿವೇಶವಾಗಿದೆ. ನಿಮ್ಮ ಕಂಟೇನರ್‌ಗೆ ಎಷ್ಟು ಸಂಪನ್ಮೂಲಗಳು ಬೇಕು ಎಂದು ಶೆಡ್ಯೂಲರ್‌ಗೆ ತಿಳಿದಿಲ್ಲ ಮತ್ತು ಇದು ನೋಡ್‌ನಲ್ಲಿ ಗಂಭೀರ ಸಮಸ್ಯೆಗಳನ್ನು ಉಂಟುಮಾಡಬಹುದು. ಇದನ್ನು ತಪ್ಪಿಸಲು, ನೀವು ನೇಮ್‌ಸ್ಪೇಸ್‌ಗಳಿಗೆ ಡೀಫಾಲ್ಟ್ ಮಿತಿಗಳನ್ನು ಹೊಂದಿಸಬೇಕಾಗುತ್ತದೆ (ಲಿಮಿಟ್ರೇಂಜ್).

ನೆನಪಿಡಿ: ನೋಡ್‌ಗಳು ಒದಗಿಸುವುದಕ್ಕಿಂತ ಹೆಚ್ಚಿನ CPU ಅನ್ನು ನೀವು ವಿನಂತಿಸಿದರೆ, Pod ಅನ್ನು ನಿಗದಿಪಡಿಸಲಾಗುವುದಿಲ್ಲ. Requests.cpu - ಕನಿಷ್ಠ ಮೌಲ್ಯವಲ್ಲ, ಆದರೆ ಪಾಡ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಲು ಮತ್ತು ವೈಫಲ್ಯಗಳಿಲ್ಲದೆ ಕೆಲಸ ಮಾಡಲು ಸಾಕಷ್ಟು ಮೌಲ್ಯವಾಗಿದೆ. ಅಪ್ಲಿಕೇಶನ್ ಸಂಕೀರ್ಣ ಲೆಕ್ಕಾಚಾರಗಳನ್ನು ನಿರ್ವಹಿಸದಿದ್ದರೆ, ಸ್ಥಾಪಿಸುವುದು ಉತ್ತಮ ಆಯ್ಕೆಯಾಗಿದೆ request.cpu <= 1 ಮತ್ತು ಅಗತ್ಯವಿರುವಷ್ಟು ಪ್ರತಿಕೃತಿಗಳನ್ನು ಪ್ರಾರಂಭಿಸಿ.

ವಿನಂತಿಸಿದ ಸಂಪನ್ಮೂಲಗಳ ಆದರ್ಶ ಪ್ರಮಾಣ ಅಥವಾ ಸಂಪನ್ಮೂಲ ಮಿತಿ

ಕಂಪ್ಯೂಟಿಂಗ್ ಸಂಪನ್ಮೂಲಗಳ ಮಿತಿಯ ಬಗ್ಗೆ ನಾವು ಕಲಿತಿದ್ದೇವೆ. ಈಗ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುವ ಸಮಯ ಬಂದಿದೆ: “ಯಾವುದೇ ಸಮಸ್ಯೆಗಳಿಲ್ಲದೆ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಚಲಾಯಿಸಲು ನನ್ನ ಪಾಡ್‌ಗೆ ಎಷ್ಟು ಸಂಪನ್ಮೂಲಗಳು ಬೇಕಾಗುತ್ತವೆ? ಆದರ್ಶ ಮೊತ್ತ ಯಾವುದು?

ದುರದೃಷ್ಟವಶಾತ್, ಈ ಪ್ರಶ್ನೆಗಳಿಗೆ ಯಾವುದೇ ಸ್ಪಷ್ಟ ಉತ್ತರಗಳಿಲ್ಲ. ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಅಥವಾ ಅದಕ್ಕೆ ಎಷ್ಟು CPU ಅಥವಾ ಮೆಮೊರಿ ಬೇಕು ಎಂದು ನಿಮಗೆ ತಿಳಿದಿಲ್ಲದಿದ್ದರೆ, ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಹೆಚ್ಚಿನ ಮೆಮೊರಿ ಮತ್ತು CPU ಅನ್ನು ನೀಡುವುದು ಮತ್ತು ನಂತರ ಕಾರ್ಯಕ್ಷಮತೆ ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸುವುದು ಉತ್ತಮ ಆಯ್ಕೆಯಾಗಿದೆ.

ಕಾರ್ಯಕ್ಷಮತೆಯ ಪರೀಕ್ಷೆಗಳ ಜೊತೆಗೆ, ಒಂದು ವಾರದವರೆಗೆ ಮೇಲ್ವಿಚಾರಣೆಯಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್‌ನ ನಡವಳಿಕೆಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಿ. ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ನೀವು ವಿನಂತಿಸಿದಕ್ಕಿಂತ ಕಡಿಮೆ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಬಳಸುತ್ತಿದೆ ಎಂದು ಗ್ರಾಫ್‌ಗಳು ಸೂಚಿಸಿದರೆ, ನೀವು ವಿನಂತಿಸಿದ CPU ಅಥವಾ ಮೆಮೊರಿಯ ಪ್ರಮಾಣವನ್ನು ಕಡಿಮೆ ಮಾಡಬಹುದು.

ಉದಾಹರಣೆಯಾಗಿ ಇದನ್ನು ನೋಡಿ ಗ್ರಾಫನಾ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್. ಇದು ವಿನಂತಿಸಿದ ಸಂಪನ್ಮೂಲಗಳು ಅಥವಾ ಸಂಪನ್ಮೂಲ ಮಿತಿ ಮತ್ತು ಪ್ರಸ್ತುತ ಸಂಪನ್ಮೂಲ ಬಳಕೆಯ ನಡುವಿನ ವ್ಯತ್ಯಾಸವನ್ನು ತೋರಿಸುತ್ತದೆ.

ತೀರ್ಮಾನಕ್ಕೆ

ಸಂಪನ್ಮೂಲಗಳನ್ನು ವಿನಂತಿಸುವುದು ಮತ್ತು ಸೀಮಿತಗೊಳಿಸುವುದು ನಿಮ್ಮ ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಆರೋಗ್ಯಕರವಾಗಿರಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಸರಿಯಾದ ಮಿತಿ ಸಂರಚನೆಯು ವೆಚ್ಚವನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ಎಲ್ಲಾ ಸಮಯದಲ್ಲೂ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಚಾಲನೆಯಲ್ಲಿರಿಸುತ್ತದೆ.

ಸಂಕ್ಷಿಪ್ತವಾಗಿ, ನೆನಪಿನಲ್ಲಿಟ್ಟುಕೊಳ್ಳಲು ಕೆಲವು ವಿಷಯಗಳಿವೆ:

ವಿನಂತಿಸಿದ ಸಂಪನ್ಮೂಲಗಳು ಪ್ರಾರಂಭದ ಸಮಯದಲ್ಲಿ (ಕುಬರ್ನೆಟ್ಸ್ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಹೋಸ್ಟ್ ಮಾಡಲು ಯೋಜಿಸಿದಾಗ) ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಲಾದ ಕಾನ್ಫಿಗರೇಶನ್ ಆಗಿದೆ. ಇದಕ್ಕೆ ವಿರುದ್ಧವಾಗಿ, ರನ್‌ಟೈಮ್‌ನಲ್ಲಿ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಸೀಮಿತಗೊಳಿಸುವುದು ಮುಖ್ಯವಾಗಿದೆ-ಅಪ್ಲಿಕೇಶನ್ ಈಗಾಗಲೇ ನೋಡ್‌ನಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿರುವಾಗ.
ಮೆಮೊರಿಗೆ ಹೋಲಿಸಿದರೆ, CPU ನಿಯಂತ್ರಿತ ಸಂಪನ್ಮೂಲವಾಗಿದೆ. ಸಾಕಷ್ಟು CPU ಇಲ್ಲದಿದ್ದರೆ, ನಿಮ್ಮ ಪಾಡ್ ಸ್ಥಗಿತಗೊಳ್ಳುವುದಿಲ್ಲ ಮತ್ತು ಥ್ರೊಟ್ಲಿಂಗ್ ಕಾರ್ಯವಿಧಾನವು ಆನ್ ಆಗುತ್ತದೆ.
ವಿನಂತಿಸಿದ ಸಂಪನ್ಮೂಲಗಳು ಮತ್ತು ಸಂಪನ್ಮೂಲ ಮಿತಿ ಕನಿಷ್ಠ ಮತ್ತು ಗರಿಷ್ಠ ಮೌಲ್ಯಗಳಲ್ಲ! ವಿನಂತಿಸಿದ ಸಂಪನ್ಮೂಲಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುವ ಮೂಲಕ, ಅಪ್ಲಿಕೇಶನ್ ಸಮಸ್ಯೆಗಳಿಲ್ಲದೆ ರನ್ ಆಗುತ್ತದೆ ಎಂದು ನೀವು ಖಚಿತಪಡಿಸುತ್ತೀರಿ.
ಮೆಮೊರಿ ವಿನಂತಿಯನ್ನು ಮೆಮೊರಿ ಮಿತಿಗೆ ಸಮಾನವಾಗಿ ಹೊಂದಿಸುವುದು ಉತ್ತಮ ಅಭ್ಯಾಸವಾಗಿದೆ.
ಸರಿ ಸ್ಥಾಪಿಸಲು ವಿನಂತಿಸಲಾಗಿದೆ CPU <=1, ಅಪ್ಲಿಕೇಶನ್ ಸಂಕೀರ್ಣ ಲೆಕ್ಕಾಚಾರಗಳನ್ನು ನಿರ್ವಹಿಸದಿದ್ದರೆ.
ನೋಡ್‌ನಲ್ಲಿ ಲಭ್ಯವಿರುವುದಕ್ಕಿಂತ ಹೆಚ್ಚಿನ ಸಂಪನ್ಮೂಲಗಳನ್ನು ನೀವು ವಿನಂತಿಸಿದರೆ, ಆ ನೋಡ್‌ಗೆ Pod ಅನ್ನು ಎಂದಿಗೂ ನಿಗದಿಪಡಿಸಲಾಗುವುದಿಲ್ಲ.
ವಿನಂತಿಸಿದ ಸಂಪನ್ಮೂಲಗಳು/ಸಂಪನ್ಮೂಲ ಮಿತಿಗಳ ಸರಿಯಾದ ಪ್ರಮಾಣವನ್ನು ನಿರ್ಧರಿಸಲು, ಲೋಡ್ ಪರೀಕ್ಷೆ ಮತ್ತು ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು ಬಳಸಿ.

ಸಂಪನ್ಮೂಲ ಮಿತಿಯ ಮೂಲಭೂತ ಪರಿಕಲ್ಪನೆಯನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಈ ಲೇಖನವು ನಿಮಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ಮತ್ತು ಈ ಜ್ಞಾನವನ್ನು ನಿಮ್ಮ ಕೆಲಸದಲ್ಲಿ ಅನ್ವಯಿಸಲು ನಿಮಗೆ ಸಾಧ್ಯವಾಗುತ್ತದೆ.

ಅದೃಷ್ಟ!

ಇನ್ನೇನು ಓದಬೇಕು:

ಮೂಲ: www.habr.com

ಕುಬರ್ನೆಟ್ಸ್ ಪಾಡ್ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹೇಗೆ ಪ್ರವೇಶಿಸುವುದು