ಪ್ರತಿ ಕುಬರ್ನೆಟ್ಸ್ ಸಂಪನ್ಮೂಲಕ್ಕಾಗಿ, ನೀವು ಎರಡು ರೀತಿಯ ಅವಶ್ಯಕತೆಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು - ವಿನಂತಿಗಳು ಮತ್ತು ಮಿತಿಗಳು. ಮೊದಲನೆಯದು ಕಂಟೇನರ್ ಅಥವಾ ಪಾಡ್ ಅನ್ನು ಚಲಾಯಿಸಲು ಅಗತ್ಯವಾದ ಉಚಿತ ನೋಡ್ ಸಂಪನ್ಮೂಲಗಳ ಲಭ್ಯತೆಗೆ ಕನಿಷ್ಠ ಅವಶ್ಯಕತೆಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ, ಎರಡನೆಯದು ಧಾರಕಕ್ಕೆ ಲಭ್ಯವಿರುವ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಕಟ್ಟುನಿಟ್ಟಾಗಿ ಮಿತಿಗೊಳಿಸುತ್ತದೆ.
ಕುಬರ್ನೆಟ್ಸ್ ಪಾಡ್ಗಳನ್ನು ನಿಗದಿಪಡಿಸಿದಾಗ, ಕಂಟೇನರ್‌ಗಳು ಸರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಸಾಕಷ್ಟು ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹೊಂದಿರುವುದು ಬಹಳ ಮುಖ್ಯ. ನೀವು ಸಂಪನ್ಮೂಲ-ನಿರ್ಬಂಧಿತ ನೋಡ್‌ನಲ್ಲಿ ದೊಡ್ಡ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನಿಯೋಜಿಸಲು ಯೋಜಿಸುತ್ತಿದ್ದರೆ, ನೋಡ್ ಕಡಿಮೆ ಮೆಮೊರಿ ಅಥವಾ CPU ಶಕ್ತಿಯಿಂದ ರನ್ ಆಗುತ್ತಿರುವ ಕಾರಣ ಅದು ರನ್ ಆಗದಿರುವ ಸಾಧ್ಯತೆಯಿದೆ. ಈ ಲೇಖನದಲ್ಲಿ, ಸಂಪನ್ಮೂಲ ವಿನಂತಿಗಳು ಮತ್ತು ಮಿತಿಗಳನ್ನು ಬಳಸಿಕೊಂಡು ನೀವು ಕಂಪ್ಯೂಟಿಂಗ್ ವಿದ್ಯುತ್ ಕೊರತೆಯನ್ನು ಹೇಗೆ ಪರಿಹರಿಸಬಹುದು ಎಂಬುದನ್ನು ನಾವು ನೋಡುತ್ತೇವೆ.
ವಿನಂತಿಗಳು ಮತ್ತು ಮಿತಿಗಳು CPU ಮತ್ತು ಮೆಮೊರಿಯಂತಹ ಸಂಪನ್ಮೂಲಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಕುಬರ್ನೆಟ್ಸ್ ಬಳಸುವ ಕಾರ್ಯವಿಧಾನಗಳಾಗಿವೆ. ವಿನಂತಿಗಳು ಧಾರಕವು ವಿನಂತಿಸಿದ ಸಂಪನ್ಮೂಲವನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಖಚಿತಪಡಿಸುತ್ತದೆ. ಕಂಟೇನರ್ ಸಂಪನ್ಮೂಲವನ್ನು ವಿನಂತಿಸಿದರೆ, ಕುಬರ್ನೆಟ್ಸ್ ಅದನ್ನು ಒದಗಿಸಬಹುದಾದ ನೋಡ್‌ನಲ್ಲಿ ಮಾತ್ರ ನಿಗದಿಪಡಿಸುತ್ತದೆ. ಕಂಟೇನರ್‌ನಿಂದ ವಿನಂತಿಸಿದ ಸಂಪನ್ಮೂಲಗಳು ಒಂದು ನಿರ್ದಿಷ್ಟ ಮೌಲ್ಯವನ್ನು ಎಂದಿಗೂ ಮೀರುವುದಿಲ್ಲ ಎಂಬ ನಿಯಂತ್ರಣವನ್ನು ಮಿತಿಗೊಳಿಸುತ್ತದೆ.
ಕಂಟೇನರ್ ತನ್ನ ಕಂಪ್ಯೂಟಿಂಗ್ ಶಕ್ತಿಯನ್ನು ಒಂದು ನಿರ್ದಿಷ್ಟ ಮಿತಿಯವರೆಗೆ ಮಾತ್ರ ಹೆಚ್ಚಿಸಬಹುದು, ನಂತರ ಅದು ಸೀಮಿತವಾಗಿರುತ್ತದೆ. ಅದು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂದು ನೋಡೋಣ. ಆದ್ದರಿಂದ, ಎರಡು ರೀತಿಯ ಸಂಪನ್ಮೂಲಗಳಿವೆ - ಪ್ರೊಸೆಸರ್ ಮತ್ತು ಮೆಮೊರಿ. ಕುಬರ್ನೆಟ್ಸ್ ಶೆಡ್ಯೂಲರ್ ನಿಮ್ಮ ಪಾಡ್ಗಳನ್ನು ಎಲ್ಲಿ ಚಲಾಯಿಸಬೇಕು ಎಂಬುದನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡಲು ಈ ಸಂಪನ್ಮೂಲಗಳ ಕುರಿತು ಡೇಟಾವನ್ನು ಬಳಸುತ್ತದೆ. ಪಾಡ್‌ಗೆ ವಿಶಿಷ್ಟವಾದ ಸಂಪನ್ಮೂಲ ವಿವರಣೆಯು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ.
ಪಾಡ್‌ನಲ್ಲಿರುವ ಪ್ರತಿಯೊಂದು ಕಂಟೇನರ್ ತನ್ನದೇ ಆದ ಪ್ರಶ್ನೆಗಳು ಮತ್ತು ಮಿತಿಗಳನ್ನು ಹೊಂದಿಸಬಹುದು, ಇದು ಎಲ್ಲಾ ಸಂಯೋಜಕವಾಗಿದೆ. ಪ್ರೊಸೆಸರ್ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಮಿಲಿಕೋರ್‌ಗಳಲ್ಲಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾಗಿದೆ. ನಿಮ್ಮ ಕಂಟೇನರ್ ರನ್ ಮಾಡಲು ಎರಡು ಪೂರ್ಣ ಕೋರ್ಗಳ ಅಗತ್ಯವಿದ್ದರೆ, ನೀವು ಮೌಲ್ಯವನ್ನು 2000m ಗೆ ಹೊಂದಿಸಿ. ಕಂಟೇನರ್‌ಗೆ ಕೇವಲ 1/4 ಕೋರ್‌ನ ಶಕ್ತಿಯ ಅಗತ್ಯವಿದ್ದರೆ, ಮೌಲ್ಯವು 250m ಆಗಿರುತ್ತದೆ. ದೊಡ್ಡ ನೋಡ್‌ನ ಕೋರ್ಗಳ ಸಂಖ್ಯೆಗಿಂತ ಹೆಚ್ಚಿನ CPU ಸಂಪನ್ಮೂಲ ಮೌಲ್ಯವನ್ನು ನೀವು ನಿಯೋಜಿಸಿದರೆ, ನಿಮ್ಮ ಪಾಡ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಲು ನಿಗದಿಪಡಿಸಲಾಗುವುದಿಲ್ಲ ಎಂಬುದನ್ನು ನೆನಪಿನಲ್ಲಿಡಿ. ನೀವು ನಾಲ್ಕು ಕೋರ್ಗಳ ಅಗತ್ಯವಿರುವ ಪಾಡ್ ಹೊಂದಿದ್ದರೆ ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್ ಕೇವಲ ಎರಡು ಮುಖ್ಯ ವರ್ಚುವಲ್ ಯಂತ್ರಗಳನ್ನು ಹೊಂದಿದ್ದರೆ ಇದೇ ರೀತಿಯ ಪರಿಸ್ಥಿತಿ ಸಂಭವಿಸುತ್ತದೆ.
ಬಹು ಕೋರ್ಗಳ (ಸಂಕೀರ್ಣ ವೈಜ್ಞಾನಿಕ ಕಂಪ್ಯೂಟಿಂಗ್ ಮತ್ತು ಡೇಟಾಬೇಸ್ ಕಾರ್ಯಾಚರಣೆಗಳಂತಹ ಪ್ರೋಗ್ರಾಂಗಳು ಮನಸ್ಸಿಗೆ ಬರುತ್ತವೆ) ಪ್ರಯೋಜನವನ್ನು ಪಡೆಯಲು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನಿರ್ದಿಷ್ಟವಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸದ ಹೊರತು, CPU ವಿನಂತಿಗಳನ್ನು 1 ಅಥವಾ ಅದಕ್ಕಿಂತ ಕಡಿಮೆಗೆ ಹೊಂದಿಸುವುದು ಮತ್ತು ನಂತರ ಸ್ಕೇಲೆಬಿಲಿಟಿಗೆ ಹೆಚ್ಚಿನ ಪ್ರತಿಕೃತಿಗಳನ್ನು ರನ್ ಮಾಡುವುದು ಉತ್ತಮ ಅಭ್ಯಾಸವಾಗಿದೆ. ಈ ಪರಿಹಾರವು ವ್ಯವಸ್ಥೆಗೆ ಹೆಚ್ಚಿನ ನಮ್ಯತೆ ಮತ್ತು ವಿಶ್ವಾಸಾರ್ಹತೆಯನ್ನು ನೀಡುತ್ತದೆ.
CPU ಮಿತಿಗಳಿಗೆ ಬಂದಾಗ, ಇದು ಸಂಕುಚಿತ ಸಂಪನ್ಮೂಲವೆಂದು ಪರಿಗಣಿಸಲ್ಪಟ್ಟಿರುವುದರಿಂದ ವಿಷಯಗಳು ಹೆಚ್ಚು ಆಸಕ್ತಿಕರವಾಗುತ್ತವೆ. ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಪ್ರೊಸೆಸರ್ ಪವರ್ ಮಿತಿಯನ್ನು ಸಮೀಪಿಸಲು ಪ್ರಾರಂಭಿಸಿದರೆ, ಕುಬರ್ನೆಟ್ಸ್ CPU ಥ್ರೊಟ್ಲಿಂಗ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ನಿಮ್ಮ ಕಂಟೇನರ್ ಅನ್ನು ನಿಧಾನಗೊಳಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ - ಪ್ರೊಸೆಸರ್ ಆವರ್ತನವನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ. ಇದರರ್ಥ CPU ಅನ್ನು ಕೃತಕವಾಗಿ ಥ್ರೊಟಲ್ ಮಾಡಲಾಗುತ್ತದೆ, ಇದು ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಸಂಭಾವ್ಯವಾಗಿ ಕೆಟ್ಟ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ನೀಡುತ್ತದೆ, ಆದರೆ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಕೊನೆಗೊಳಿಸಲಾಗುವುದಿಲ್ಲ ಅಥವಾ ತೆಗೆದುಹಾಕಲಾಗುವುದಿಲ್ಲ.
ಮೆಮೊರಿ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಬೈಟ್‌ಗಳಲ್ಲಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾಗಿದೆ. ಸಾಮಾನ್ಯವಾಗಿ ಸೆಟ್ಟಿಂಗ್‌ಗಳಲ್ಲಿನ ಮೌಲ್ಯವನ್ನು ಮೆಬಿಬೈಟ್ಸ್ Mib ನಲ್ಲಿ ಅಳೆಯಲಾಗುತ್ತದೆ, ಆದರೆ ನೀವು ಬೈಟ್‌ಗಳಿಂದ ಪೆಟಾಬೈಟ್‌ಗಳವರೆಗೆ ಯಾವುದೇ ಮೌಲ್ಯವನ್ನು ಹೊಂದಿಸಬಹುದು. CPU ನೊಂದಿಗೆ ಅದೇ ಪರಿಸ್ಥಿತಿಯು ಇಲ್ಲಿಯೂ ಅನ್ವಯಿಸುತ್ತದೆ - ನಿಮ್ಮ ನೋಡ್‌ಗಳಲ್ಲಿ ಮೆಮೊರಿಯ ಪ್ರಮಾಣಕ್ಕಿಂತ ಹೆಚ್ಚಿನ ಮೆಮೊರಿಯ ಮೊತ್ತಕ್ಕಾಗಿ ನೀವು ವಿನಂತಿಯನ್ನು ಸಲ್ಲಿಸಿದರೆ, ಆ ಪಾಡ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ನಿಗದಿಪಡಿಸಲಾಗುವುದಿಲ್ಲ. ಆದರೆ ಸಿಪಿಯು ಸಂಪನ್ಮೂಲಗಳಂತೆ, ಮೆಮೊರಿಯನ್ನು ಸಂಕುಚಿತಗೊಳಿಸಲಾಗಿಲ್ಲ ಏಕೆಂದರೆ ಅದರ ಬಳಕೆಯನ್ನು ಮಿತಿಗೊಳಿಸಲು ಯಾವುದೇ ಮಾರ್ಗವಿಲ್ಲ. ಆದ್ದರಿಂದ, ಕಂಟೇನರ್‌ನ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯು ಅದಕ್ಕೆ ನಿಗದಿಪಡಿಸಿದ ಮೆಮೊರಿಯನ್ನು ಮೀರಿದ ತಕ್ಷಣ ಅದನ್ನು ನಿಲ್ಲಿಸಲಾಗುತ್ತದೆ.
ನಿಮ್ಮ ನೋಡ್‌ಗಳು ಒದಗಿಸಬಹುದಾದ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಮೀರಿದ ವಿನಂತಿಗಳನ್ನು ನೀವು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂಬುದನ್ನು ನೆನಪಿಟ್ಟುಕೊಳ್ಳುವುದು ಬಹಳ ಮುಖ್ಯ. GKE ವರ್ಚುವಲ್ ಯಂತ್ರಗಳ ಹಂಚಿಕೆಯ ಸಂಪನ್ಮೂಲ ವಿಶೇಷಣಗಳನ್ನು ಈ ವೀಡಿಯೊ ಕೆಳಗಿನ ಲಿಂಕ್‌ಗಳಲ್ಲಿ ಕಾಣಬಹುದು.
ಆದರ್ಶ ಜಗತ್ತಿನಲ್ಲಿ, ಕೆಲಸದ ಹರಿವುಗಳು ಸರಾಗವಾಗಿ ನಡೆಯಲು ಕಂಟೇನರ್‌ನ ಡೀಫಾಲ್ಟ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳು ಸಾಕಾಗುತ್ತದೆ. ಆದರೆ ನೈಜ ಪ್ರಪಂಚವು ಹಾಗಲ್ಲ, ಸಂಪನ್ಮೂಲಗಳ ಬಳಕೆಯನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು ಜನರು ಸುಲಭವಾಗಿ ಮರೆತುಬಿಡಬಹುದು, ಅಥವಾ ಹ್ಯಾಕರ್‌ಗಳು ಮೂಲಸೌಕರ್ಯದ ನೈಜ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಮೀರಿದ ವಿನಂತಿಗಳು ಮತ್ತು ನಿರ್ಬಂಧಗಳನ್ನು ಹೊಂದಿಸುತ್ತಾರೆ. ಅಂತಹ ಸನ್ನಿವೇಶಗಳು ಸಂಭವಿಸುವುದನ್ನು ತಡೆಯಲು, ನೀವು ResourceQuota ಮತ್ತು LimitRange ಸಂಪನ್ಮೂಲ ಕೋಟಾಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು.
ನೇಮ್‌ಸ್ಪೇಸ್ ಅನ್ನು ರಚಿಸಿದ ನಂತರ, ಅದನ್ನು ಕೋಟಾಗಳನ್ನು ಬಳಸಿ ನಿರ್ಬಂಧಿಸಬಹುದು. ಉದಾಹರಣೆಗೆ, ನೀವು ಪ್ರಾಡ್ ಮತ್ತು ಡೆವ್ ನೇಮ್‌ಸ್ಪೇಸ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ಯಾವುದೇ ಉತ್ಪಾದನಾ ಕೋಟಾಗಳಿಲ್ಲ ಮತ್ತು ಅತ್ಯಂತ ಕಟ್ಟುನಿಟ್ಟಾದ ಅಭಿವೃದ್ಧಿ ಕೋಟಾಗಳಿಲ್ಲ. ಟ್ರಾಫಿಕ್‌ನಲ್ಲಿ ತೀಕ್ಷ್ಣವಾದ ಏರಿಕೆಯ ಸಂದರ್ಭದಲ್ಲಿ, ಲಭ್ಯವಿರುವ ಸಂಪೂರ್ಣ ಸಂಪನ್ಮೂಲವನ್ನು ಸ್ವಾಧೀನಪಡಿಸಿಕೊಳ್ಳಲು, dev ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ನಿರ್ಬಂಧಿಸಲು ಇದು ಪ್ರಾಡ್ ಅನ್ನು ಅನುಮತಿಸುತ್ತದೆ.
ಸಂಪನ್ಮೂಲ ಕೋಟಾ ಈ ರೀತಿ ಕಾಣಿಸಬಹುದು. ಈ ಉದಾಹರಣೆಯಲ್ಲಿ 4 ವಿಭಾಗಗಳಿವೆ - ಇವು ಕೋಡ್‌ನ 4 ಬಾಟಮ್ ಲೈನ್‌ಗಳಾಗಿವೆ.
ಅವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದನ್ನು ನೋಡೋಣ. Requests.cpu ಎನ್ನುವುದು ನೇಮ್‌ಸ್ಪೇಸ್‌ನಲ್ಲಿರುವ ಎಲ್ಲಾ ಕಂಟೈನರ್‌ಗಳಿಂದ ಬರಬಹುದಾದ ಗರಿಷ್ಠ ಸಂಖ್ಯೆಯ ಸಂಯೋಜಿತ CPU ವಿನಂತಿಗಳು. ಈ ಉದಾಹರಣೆಯಲ್ಲಿ, ನೀವು 50m ವಿನಂತಿಗಳೊಂದಿಗೆ 10 ಕಂಟೇನರ್‌ಗಳನ್ನು ಹೊಂದಬಹುದು, 100m ವಿನಂತಿಗಳೊಂದಿಗೆ ಐದು ಕಂಟೇನರ್‌ಗಳನ್ನು ಅಥವಾ 500m ವಿನಂತಿಗಳೊಂದಿಗೆ ಕೇವಲ ಒಂದು ಕಂಟೇನರ್ ಅನ್ನು ಹೊಂದಬಹುದು. ನೀಡಲಾದ ನೇಮ್‌ಸ್ಪೇಸ್‌ನ ಒಟ್ಟು ವಿನಂತಿಗಳ ಸಂಖ್ಯೆ. ಸಿಪಿಯು 500 ಮೀ ಗಿಂತ ಕಡಿಮೆ ಇರುವವರೆಗೆ, ಎಲ್ಲವೂ ಚೆನ್ನಾಗಿರುತ್ತದೆ.
ಮೆಮೊರಿ ವಿನಂತಿಸಿದ requests.memory ಎಂಬುದು ನೇಮ್‌ಸ್ಪೇಸ್‌ನಲ್ಲಿರುವ ಎಲ್ಲಾ ಕಂಟೈನರ್‌ಗಳು ಹೊಂದಬಹುದಾದ ಸಂಯೋಜಿತ ಮೆಮೊರಿ ವಿನಂತಿಗಳ ಗರಿಷ್ಠ ಮೊತ್ತವಾಗಿದೆ. ಹಿಂದಿನ ಪ್ರಕರಣದಂತೆ, ನೀವು 50 2 mib ಕಂಟೈನರ್‌ಗಳು, ಐದು 20 mib ಕಂಟೈನರ್‌ಗಳು ಅಥವಾ ಒಂದೇ 100 mib ಕಂಟೇನರ್ ಅನ್ನು ಹೊಂದಬಹುದು, ನೇಮ್‌ಸ್ಪೇಸ್‌ನಲ್ಲಿ ವಿನಂತಿಸಿದ ಒಟ್ಟು ಮೆಮೊರಿಯ ಪ್ರಮಾಣವು 100 ಮೆಬಿಬೈಟ್‌ಗಳಿಗಿಂತ ಕಡಿಮೆಯಿರುತ್ತದೆ.
Limits.cpu ಎನ್ನುವುದು ನೇಮ್‌ಸ್ಪೇಸ್‌ನಲ್ಲಿರುವ ಎಲ್ಲಾ ಕಂಟೈನರ್‌ಗಳು ಬಳಸಬಹುದಾದ CPU ಪವರ್‌ನ ಗರಿಷ್ಠ ಸಂಯೋಜಿತ ಮೊತ್ತವಾಗಿದೆ. ನಾವು ಇದನ್ನು ಪ್ರೊಸೆಸರ್ ಪವರ್ ವಿನಂತಿಗಳ ಮಿತಿ ಎಂದು ಪರಿಗಣಿಸಬಹುದು.
ಅಂತಿಮವಾಗಿ, limits.memory ಎಂಬುದು ನೇಮ್‌ಸ್ಪೇಸ್‌ನಲ್ಲಿರುವ ಎಲ್ಲಾ ಕಂಟೈನರ್‌ಗಳು ಬಳಸಬಹುದಾದ ಗರಿಷ್ಠ ಪ್ರಮಾಣದ ಹಂಚಿಕೆಯ ಮೆಮೊರಿಯಾಗಿದೆ. ಇದು ಒಟ್ಟು ಮೆಮೊರಿ ವಿನಂತಿಗಳ ಮಿತಿಯಾಗಿದೆ.
ಆದ್ದರಿಂದ, ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ, ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿರುವ ಕಂಟೈನರ್‌ಗಳು ಅನಿಯಮಿತ ಕಂಪ್ಯೂಟ್ ಸಂಪನ್ಮೂಲಗಳೊಂದಿಗೆ ರನ್ ಆಗುತ್ತವೆ. ಸಂಪನ್ಮೂಲ ಕೋಟಾಗಳೊಂದಿಗೆ, ಕ್ಲಸ್ಟರ್ ನಿರ್ವಾಹಕರು ನೇಮ್‌ಸ್ಪೇಸ್ ಆಧಾರದ ಮೇಲೆ ಸಂಪನ್ಮೂಲ ಬಳಕೆ ಮತ್ತು ಸಂಪನ್ಮೂಲ ರಚನೆಯನ್ನು ಮಿತಿಗೊಳಿಸಬಹುದು. ನೇಮ್‌ಸ್ಪೇಸ್‌ನಲ್ಲಿ, ನೇಮ್‌ಸ್ಪೇಸ್ ಸಂಪನ್ಮೂಲ ಕೋಟಾದಿಂದ ನಿರ್ಧರಿಸಲ್ಪಟ್ಟಂತೆ ಪಾಡ್ ಅಥವಾ ಕಂಟೇನರ್ ಹೆಚ್ಚು CPU ಪವರ್ ಮತ್ತು ಮೆಮೊರಿಯನ್ನು ಸೇವಿಸಬಹುದು. ಆದಾಗ್ಯೂ, ಒಂದು ಪಾಡ್ ಅಥವಾ ಕಂಟೇನರ್ ಲಭ್ಯವಿರುವ ಎಲ್ಲಾ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಏಕಸ್ವಾಮ್ಯಗೊಳಿಸಬಹುದು ಎಂಬ ಕಳವಳವಿದೆ. ಈ ಪರಿಸ್ಥಿತಿಯನ್ನು ತಡೆಗಟ್ಟಲು, ಮಿತಿ ಶ್ರೇಣಿಯನ್ನು ಬಳಸಲಾಗುತ್ತದೆ - ನೇಮ್‌ಸ್ಪೇಸ್‌ನಲ್ಲಿ ಸಂಪನ್ಮೂಲಗಳ (ಪಾಡ್‌ಗಳು ಅಥವಾ ಕಂಟೈನರ್‌ಗಳಿಗಾಗಿ) ಹಂಚಿಕೆಯನ್ನು ಸೀಮಿತಗೊಳಿಸುವ ನೀತಿ.
ಮಿತಿ ಶ್ರೇಣಿಯು ನಿರ್ಬಂಧಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ:
- ನೇಮ್‌ಸ್ಪೇಸ್‌ನಲ್ಲಿ ಪ್ರತಿ ಮಾಡ್ಯೂಲ್ ಅಥವಾ ಕಂಟೈನರ್‌ಗೆ ಕಂಪ್ಯೂಟಿಂಗ್ ಸಂಪನ್ಮೂಲಗಳ ಕನಿಷ್ಠ ಮತ್ತು ಗರಿಷ್ಠ ಬಳಕೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ;
- ನೇಮ್‌ಸ್ಪೇಸ್‌ನಲ್ಲಿ ಪ್ರತಿ PersistentVolumeClaim ಗಾಗಿ ಕನಿಷ್ಠ ಮತ್ತು ಗರಿಷ್ಠ ಸ್ಟಾರೇಜ್ ವಿನಂತಿ ಸಂಗ್ರಹ ವಿನಂತಿಗಳನ್ನು ಜಾರಿಗೊಳಿಸಿ;
- ನೇಮ್‌ಸ್ಪೇಸ್‌ನಲ್ಲಿ ಸಂಪನ್ಮೂಲಕ್ಕಾಗಿ ವಿನಂತಿ ಮತ್ತು ಮಿತಿಯ ನಡುವಿನ ಸಂಬಂಧವನ್ನು ಜಾರಿಗೊಳಿಸಿ;
- ನೇಮ್‌ಸ್ಪೇಸ್‌ನಲ್ಲಿ ಕಂಪ್ಯೂಟ್ ಸಂಪನ್ಮೂಲಗಳಿಗಾಗಿ ಡೀಫಾಲ್ಟ್ ವಿನಂತಿಗಳು/ಮಿತಿಗಳನ್ನು ಹೊಂದಿಸಿ ಮತ್ತು ರನ್‌ಟೈಮ್‌ನಲ್ಲಿ ಅವುಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಕಂಟೇನರ್‌ಗಳಿಗೆ ಇಂಜೆಕ್ಟ್ ಮಾಡಿ.
ಈ ರೀತಿಯಲ್ಲಿ ನೀವು ನಿಮ್ಮ ನೇಮ್‌ಸ್ಪೇಸ್‌ನಲ್ಲಿ ಮಿತಿ ಶ್ರೇಣಿಯನ್ನು ರಚಿಸಬಹುದು. ಸಂಪೂರ್ಣ ನೇಮ್‌ಸ್ಪೇಸ್‌ಗೆ ಅನ್ವಯಿಸುವ ಕೋಟಾದಂತೆ, ಮಿತಿ ಶ್ರೇಣಿಯನ್ನು ಪ್ರತ್ಯೇಕ ಕಂಟೈನರ್‌ಗಳಿಗೆ ಬಳಸಲಾಗುತ್ತದೆ. ಇದು ಬಳಕೆದಾರರನ್ನು ನೇಮ್‌ಸ್ಪೇಸ್‌ನಲ್ಲಿ ಅತಿ ಚಿಕ್ಕ ಅಥವಾ ಪ್ರತಿಯಾಗಿ ದೈತ್ಯಾಕಾರದ ಕಂಟೈನರ್‌ಗಳನ್ನು ರಚಿಸುವುದನ್ನು ತಡೆಯಬಹುದು. ಮಿತಿ ಶ್ರೇಣಿಯು ಈ ರೀತಿ ಕಾಣಿಸಬಹುದು.
ಹಿಂದಿನ ಪ್ರಕರಣದಂತೆ, ಇಲ್ಲಿ 4 ವಿಭಾಗಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸಬಹುದು. ಪ್ರತಿಯೊಂದನ್ನು ನೋಡೋಣ.
ಡೀಫಾಲ್ಟ್ ವಿಭಾಗವು ಪಾಡ್‌ನಲ್ಲಿರುವ ಕಂಟೇನರ್‌ಗಾಗಿ ಡೀಫಾಲ್ಟ್ ಮಿತಿಗಳನ್ನು ಹೊಂದಿಸುತ್ತದೆ. ನೀವು ಈ ಮೌಲ್ಯಗಳನ್ನು ತೀವ್ರ ಶ್ರೇಣಿಗೆ ಹೊಂದಿಸಿದರೆ, ಈ ಮೌಲ್ಯಗಳನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಹೊಂದಿಸದ ಯಾವುದೇ ಧಾರಕಗಳು ಡೀಫಾಲ್ಟ್ ಮೌಲ್ಯಗಳನ್ನು ಅನುಸರಿಸುತ್ತವೆ.
ಡೀಫಾಲ್ಟ್ ವಿನಂತಿ ವಿಭಾಗ ಡೀಫಾಲ್ಟ್ ರಿಕ್ವೆಸ್ಟ್ ಪಾಡ್‌ನಲ್ಲಿರುವ ಕಂಟೇನರ್‌ಗಾಗಿ ಡೀಫಾಲ್ಟ್ ವಿನಂತಿಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡುತ್ತದೆ. ಮತ್ತೊಮ್ಮೆ, ನೀವು ಈ ಮೌಲ್ಯಗಳನ್ನು ತೀವ್ರ ಶ್ರೇಣಿಗೆ ಹೊಂದಿಸಿದರೆ, ಈ ಆಯ್ಕೆಗಳನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಹೊಂದಿಸದ ಯಾವುದೇ ಧಾರಕಗಳು ಈ ಮೌಲ್ಯಗಳಿಗೆ ಡೀಫಾಲ್ಟ್ ಆಗುತ್ತವೆ.
ಗರಿಷ್ಠ ವಿಭಾಗವು ಪಾಡ್‌ನಲ್ಲಿರುವ ಕಂಟೇನರ್‌ಗೆ ಹೊಂದಿಸಬಹುದಾದ ಗರಿಷ್ಠ ಮಿತಿಗಳನ್ನು ಸೂಚಿಸುತ್ತದೆ. ಡೀಫಾಲ್ಟ್ ವಿಭಾಗ ಮತ್ತು ಕಂಟೇನರ್ ಮಿತಿಗಳಲ್ಲಿನ ಮೌಲ್ಯಗಳನ್ನು ಈ ಮಿತಿಗಿಂತ ಹೆಚ್ಚು ಹೊಂದಿಸಲಾಗುವುದಿಲ್ಲ. ಮೌಲ್ಯವನ್ನು ಗರಿಷ್ಠಕ್ಕೆ ಹೊಂದಿಸಿದರೆ ಮತ್ತು ಡೀಫಾಲ್ಟ್ ವಿಭಾಗವಿಲ್ಲದಿದ್ದರೆ, ಗರಿಷ್ಠ ಮೌಲ್ಯವು ಡೀಫಾಲ್ಟ್ ಮೌಲ್ಯವಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಗಮನಿಸುವುದು ಮುಖ್ಯವಾಗಿದೆ.
ಪಾಡ್‌ನಲ್ಲಿ ಕಂಟೇನರ್‌ಗಾಗಿ ಹೊಂದಿಸಬಹುದಾದ ಕನಿಷ್ಠ ವಿನಂತಿಗಳನ್ನು ನಿಮಿಷ ವಿಭಾಗವು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಡೀಫಾಲ್ಟ್ ವಿಭಾಗದಲ್ಲಿನ ಮೌಲ್ಯಗಳು ಮತ್ತು ಕಂಟೇನರ್‌ಗಾಗಿ ಪ್ರಶ್ನೆಗಳನ್ನು ಈ ಮಿತಿಗಿಂತ ಕೆಳಗೆ ಹೊಂದಿಸಲಾಗುವುದಿಲ್ಲ.
ಮತ್ತೊಮ್ಮೆ, ಈ ಮೌಲ್ಯವನ್ನು ಹೊಂದಿಸಿದರೆ, ಡೀಫಾಲ್ಟ್ ಅಲ್ಲ, ನಂತರ ಕನಿಷ್ಠ ಮೌಲ್ಯವು ಡೀಫಾಲ್ಟ್ ಪ್ರಾಂಪ್ಟ್ ಆಗುತ್ತದೆ ಎಂಬುದನ್ನು ಗಮನಿಸುವುದು ಮುಖ್ಯವಾಗಿದೆ.
ಈ ಸಂಪನ್ಮೂಲ ವಿನಂತಿಗಳನ್ನು ಅಂತಿಮವಾಗಿ ನಿಮ್ಮ ಕೆಲಸದ ಹೊರೆಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಕುಬರ್ನೆಟ್ಸ್ ಶೆಡ್ಯೂಲರ್‌ನಿಂದ ಬಳಸಲಾಗುತ್ತದೆ. ನಿಮ್ಮ ಕಂಟೇನರ್‌ಗಳನ್ನು ಸರಿಯಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲು, ಅದು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಬಹಳ ಮುಖ್ಯ. ನಿಮ್ಮ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ನೀವು ಬಹು ಪಾಡ್ಗಳನ್ನು ಚಲಾಯಿಸಲು ಬಯಸುತ್ತೀರಿ ಎಂದು ಹೇಳೋಣ. ಪಾಡ್ ವಿಶೇಷಣಗಳು ಮಾನ್ಯವಾಗಿರುತ್ತವೆ ಎಂದು ಭಾವಿಸಿದರೆ, ಕುಬರ್ನೆಟ್ಸ್ ವೇಳಾಪಟ್ಟಿಯು ಕೆಲಸದ ಹೊರೆಯನ್ನು ಚಲಾಯಿಸಲು ನೋಡ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಲು ರೌಂಡ್ ರಾಬಿನ್ ಬ್ಯಾಲೆನ್ಸಿಂಗ್ ಅನ್ನು ಬಳಸುತ್ತದೆ.
ಪಾಡ್ ಕಂಟೈನರ್‌ಗಳಿಂದ ವಿನಂತಿಗಳನ್ನು ಪೂರೈಸಲು ನೋಡ್ 1 ಸಾಕಷ್ಟು ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹೊಂದಿದೆಯೇ ಎಂದು ಕುಬರ್ನೆಟ್ಸ್ ಪರಿಶೀಲಿಸುತ್ತದೆ ಮತ್ತು ಅದು ಇಲ್ಲದಿದ್ದರೆ, ಅದು ಮುಂದಿನ ನೋಡ್‌ಗೆ ಹೋಗುತ್ತದೆ. ಸಿಸ್ಟಮ್‌ನಲ್ಲಿರುವ ಯಾವುದೇ ನೋಡ್‌ಗಳು ವಿನಂತಿಗಳನ್ನು ಪೂರೈಸಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ಪಾಡ್‌ಗಳು ಬಾಕಿ ಇರುವ ಸ್ಥಿತಿಗೆ ಹೋಗುತ್ತವೆ. ನೋಡ್ ಆಟೋಸ್ಕೇಲಿಂಗ್‌ನಂತಹ Google Kubernetes ಎಂಜಿನ್ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಬಳಸಿಕೊಂಡು, GKE ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಕಾಯುವ ಸ್ಥಿತಿಯನ್ನು ಪತ್ತೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ಹಲವಾರು ಹೆಚ್ಚುವರಿ ನೋಡ್‌ಗಳನ್ನು ರಚಿಸಬಹುದು.
ನೀವು ತರುವಾಯ ನೋಡ್ ಸಾಮರ್ಥ್ಯದಿಂದ ಹೊರಗಿದ್ದರೆ, ಆಟೋಸ್ಕೇಲಿಂಗ್ ನಿಮ್ಮ ಹಣವನ್ನು ಉಳಿಸಲು ನೋಡ್‌ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ. ಇದಕ್ಕಾಗಿಯೇ ಕುಬರ್ನೆಟ್ಸ್ ವಿನಂತಿಗಳ ಆಧಾರದ ಮೇಲೆ ಪಾಡ್ಗಳನ್ನು ನಿಗದಿಪಡಿಸುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಮಿತಿಯು ವಿನಂತಿಗಳಿಗಿಂತ ಹೆಚ್ಚಿರಬಹುದು ಮತ್ತು ಕೆಲವು ಸಂದರ್ಭಗಳಲ್ಲಿ ನೋಡ್ ವಾಸ್ತವವಾಗಿ ಸಂಪನ್ಮೂಲಗಳಿಂದ ಹೊರಗುಳಿಯಬಹುದು. ನಾವು ಈ ಸ್ಥಿತಿಯನ್ನು ಓವರ್ಕಮಿಟ್ಮೆಂಟ್ ಸ್ಟೇಟ್ ಎಂದು ಕರೆಯುತ್ತೇವೆ.
ನಾನು ಹೇಳಿದಂತೆ, ಇದು CPU ಗೆ ಬಂದಾಗ, ಕುಬರ್ನೆಟ್ಸ್ ಪಾಡ್ಗಳನ್ನು ಸೀಮಿತಗೊಳಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಪ್ರತಿ ಪಾಡ್ ವಿನಂತಿಸಿದಷ್ಟು ಸ್ವೀಕರಿಸುತ್ತದೆ, ಆದರೆ ಅದು ಮಿತಿಯನ್ನು ತಲುಪದಿದ್ದರೆ, ಥ್ರೊಟ್ಲಿಂಗ್ ಅನ್ವಯಿಸಲು ಪ್ರಾರಂಭವಾಗುತ್ತದೆ.
ಮೆಮೊರಿ ಸಂಪನ್ಮೂಲಗಳ ವಿಷಯಕ್ಕೆ ಬಂದಾಗ, ನೀವು ಸಿಸ್ಟಮ್ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಮುಕ್ತಗೊಳಿಸುವವರೆಗೆ ಅಥವಾ ಸಂಪೂರ್ಣ ಸಿಸ್ಟಮ್ ಕ್ರ್ಯಾಶ್ ಆಗುವವರೆಗೆ ಯಾವ ಪಾಡ್ಗಳನ್ನು ಅಳಿಸಬೇಕು ಮತ್ತು ಯಾವುದನ್ನು ಇಟ್ಟುಕೊಳ್ಳಬೇಕು ಎಂಬುದರ ಕುರಿತು ನಿರ್ಧಾರಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಲು ಕುಬರ್ನೆಟ್ಸ್ ಒತ್ತಾಯಿಸಲ್ಪಡುತ್ತಾನೆ.
ನಿಮ್ಮಲ್ಲಿ ಒಂದು ಯಂತ್ರವು ಮೆಮೊರಿ ಖಾಲಿಯಾಗುತ್ತಿರುವ ಸನ್ನಿವೇಶವನ್ನು ಊಹಿಸೋಣ - ಕುಬರ್ನೆಟ್ಸ್ ಅದನ್ನು ಹೇಗೆ ನಿಭಾಯಿಸುತ್ತಾರೆ?
ಕುಬರ್ನೆಟ್ಸ್ ಅವರು ವಿನಂತಿಸಿದಕ್ಕಿಂತ ಹೆಚ್ಚಿನ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಬಳಸುತ್ತಿರುವ ಪಾಡ್ಗಳನ್ನು ಹುಡುಕುತ್ತಾರೆ. ಆದ್ದರಿಂದ ನಿಮ್ಮ ಕಂಟೇನರ್‌ಗಳು ಯಾವುದೇ ವಿನಂತಿಗಳನ್ನು ಹೊಂದಿಲ್ಲದಿದ್ದರೆ, ಅವರು ಕೇಳಿದ್ದಕ್ಕಿಂತ ಹೆಚ್ಚಿನದನ್ನು ಬಳಸಲು ಅವರು ಡೀಫಾಲ್ಟ್ ಆಗಿದ್ದಾರೆ ಎಂದರ್ಥ, ಏಕೆಂದರೆ ಅವರು ಏನನ್ನೂ ಕೇಳಲಿಲ್ಲ! ಅಂತಹ ಕಂಟೈನರ್‌ಗಳು ಸ್ಥಗಿತಗೊಳ್ಳಲು ಪ್ರಧಾನ ಅಭ್ಯರ್ಥಿಗಳಾಗುತ್ತವೆ. ಮುಂದಿನ ಅಭ್ಯರ್ಥಿಗಳು ತಮ್ಮ ಎಲ್ಲಾ ವಿನಂತಿಗಳನ್ನು ತೃಪ್ತಿಪಡಿಸಿದ ಆದರೆ ಇನ್ನೂ ಗರಿಷ್ಠ ಮಿತಿಗಿಂತ ಕೆಳಗಿರುವ ಕಂಟೈನರ್‌ಗಳಾಗಿವೆ.
ಆದ್ದರಿಂದ ಕುಬರ್ನೆಟ್ಸ್ ತಮ್ಮ ವಿನಂತಿಯ ನಿಯತಾಂಕಗಳನ್ನು ಮೀರಿದ ಹಲವಾರು ಪಾಡ್ಗಳನ್ನು ಕಂಡುಕೊಂಡರೆ, ಅದು ಅವುಗಳನ್ನು ಆದ್ಯತೆಯ ಮೂಲಕ ವಿಂಗಡಿಸುತ್ತದೆ ಮತ್ತು ನಂತರ ಕಡಿಮೆ ಆದ್ಯತೆಯ ಪಾಡ್ಗಳನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ. ಎಲ್ಲಾ ಪಾಡ್‌ಗಳು ಒಂದೇ ರೀತಿಯ ಆದ್ಯತೆಯನ್ನು ಹೊಂದಿದ್ದರೆ, ಕುಬರ್ನೆಟ್‌ಗಳು ಇತರ ಪಾಡ್‌ಗಳಿಗಿಂತ ತಮ್ಮ ವಿನಂತಿಗಳನ್ನು ಮೀರಿದ ಆ ಬೀಜಗಳನ್ನು ಕೊನೆಗೊಳಿಸುತ್ತಾರೆ.
ಬಹಳ ಅಪರೂಪದ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಕುಬರ್ನೆಟ್ಸ್ ತಮ್ಮ ವಿನಂತಿಗಳ ವ್ಯಾಪ್ತಿಯಲ್ಲಿರುವ ಪಾಡ್ಗಳನ್ನು ಸ್ಥಗಿತಗೊಳಿಸಬಹುದು. ಕುಬೆಲೆಟ್ ಏಜೆಂಟ್ ಅಥವಾ ಡಾಕರ್‌ನಂತಹ ನಿರ್ಣಾಯಕ ಸಿಸ್ಟಮ್ ಘಟಕಗಳು ಅವುಗಳಿಗೆ ಕಾಯ್ದಿರಿಸಿದ್ದಕ್ಕಿಂತ ಹೆಚ್ಚಿನ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಸೇವಿಸಲು ಪ್ರಾರಂಭಿಸಿದಾಗ ಇದು ಸಂಭವಿಸಬಹುದು.
ಆದ್ದರಿಂದ, ಸಣ್ಣ ಕಂಪನಿಗಳ ಆರಂಭಿಕ ಹಂತಗಳಲ್ಲಿ, ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್ ಸಂಪನ್ಮೂಲ ವಿನಂತಿಗಳು ಮತ್ತು ನಿರ್ಬಂಧಗಳನ್ನು ಹೊಂದಿಸದೆ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಆದರೆ ನಿಮ್ಮ ತಂಡಗಳು ಮತ್ತು ಯೋಜನೆಗಳು ಗಾತ್ರದಲ್ಲಿ ಬೆಳೆಯಲು ಪ್ರಾರಂಭಿಸಿದಾಗ, ನೀವು ಈ ಪ್ರದೇಶದಲ್ಲಿ ಸಮಸ್ಯೆಗಳನ್ನು ಎದುರಿಸುವ ಅಪಾಯವನ್ನು ಎದುರಿಸುತ್ತೀರಿ. ನಿಮ್ಮ ಮಾಡ್ಯೂಲ್‌ಗಳು ಮತ್ತು ನೇಮ್‌ಸ್ಪೇಸ್‌ಗಳಿಗೆ ಪ್ರಶ್ನೆಗಳು ಮತ್ತು ನಿರ್ಬಂಧಗಳನ್ನು ಸೇರಿಸಲು ಕಡಿಮೆ ಹೆಚ್ಚುವರಿ ಪ್ರಯತ್ನದ ಅಗತ್ಯವಿರುತ್ತದೆ ಮತ್ತು ಬಹಳಷ್ಟು ಜಗಳವನ್ನು ಉಳಿಸಬಹುದು.
ಕೆಲವು ಜಾಹೀರಾತುಗಳು 🙂
ನಮ್ಮೊಂದಿಗೆ ಇರುವುದಕ್ಕೆ ಧನ್ಯವಾದಗಳು. ನೀವು ನಮ್ಮ ಲೇಖನಗಳನ್ನು ಇಷ್ಟಪಡುತ್ತೀರಾ? ಹೆಚ್ಚು ಆಸಕ್ತಿದಾಯಕ ವಿಷಯವನ್ನು ನೋಡಲು ಬಯಸುವಿರಾ? ಆರ್ಡರ್ ಮಾಡುವ ಮೂಲಕ ಅಥವಾ ಸ್ನೇಹಿತರಿಗೆ ಶಿಫಾರಸು ಮಾಡುವ ಮೂಲಕ ನಮ್ಮನ್ನು ಬೆಂಬಲಿಸಿ, , ಪ್ರವೇಶ ಮಟ್ಟದ ಸರ್ವರ್‌ಗಳ ಅನನ್ಯ ಅನಲಾಗ್, ಇದನ್ನು ನಿಮಗಾಗಿ ನಾವು ಕಂಡುಹಿಡಿದಿದ್ದೇವೆ: (RAID1 ಮತ್ತು RAID10, 24 ಕೋರ್‌ಗಳವರೆಗೆ ಮತ್ತು 40GB DDR4 ವರೆಗೆ ಲಭ್ಯವಿದೆ).
ಆಮ್‌ಸ್ಟರ್‌ಡ್ಯಾಮ್‌ನಲ್ಲಿರುವ Equinix Tier IV ಡೇಟಾ ಸೆಂಟರ್‌ನಲ್ಲಿ Dell R730xd 2x ಅಗ್ಗವಾಗಿದೆಯೇ? ಇಲ್ಲಿ ಮಾತ್ರ ನೆದರ್ಲ್ಯಾಂಡ್ಸ್ನಲ್ಲಿ! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 ರಿಂದ! ಬಗ್ಗೆ ಓದು
ಮೂಲ: www.habr.com