ಸೂಚನೆ. ಅನುವಾದ.: ಓಮಿಯೊದ ಈ ಕಣ್ಣು-ತೆರೆಯುವ ಇತಿಹಾಸ-ಯುರೋಪಿಯನ್ ಟ್ರಾವೆಲ್ ಅಗ್ರಿಗೇಟರ್- ಓದುಗರನ್ನು ಮೂಲಭೂತ ಸಿದ್ಧಾಂತದಿಂದ ಕುಬರ್ನೆಟ್ಸ್ ಕಾನ್ಫಿಗರೇಶನ್ನ ಆಕರ್ಷಕ ಪ್ರಾಯೋಗಿಕ ಜಟಿಲತೆಗಳಿಗೆ ಕರೆದೊಯ್ಯುತ್ತದೆ. ಅಂತಹ ಸಂದರ್ಭಗಳಲ್ಲಿ ಪರಿಚಿತತೆಯು ನಿಮ್ಮ ಪರಿಧಿಯನ್ನು ವಿಸ್ತರಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ, ಆದರೆ ಕ್ಷುಲ್ಲಕವಲ್ಲದ ಸಮಸ್ಯೆಗಳನ್ನು ತಡೆಯುತ್ತದೆ.
ನೀವು ಎಂದಾದರೂ ಅಪ್ಲಿಕೇಶನ್ ಸ್ಥಳದಲ್ಲಿ ಸಿಲುಕಿಕೊಂಡಿದ್ದೀರಾ, ಆರೋಗ್ಯ ತಪಾಸಣೆಗಳಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿದ್ದೀರಾ ಮತ್ತು ಏಕೆ ಎಂದು ಕಂಡುಹಿಡಿಯಲು ಸಾಧ್ಯವಾಗುತ್ತಿಲ್ಲವೇ? ಒಂದು ಸಂಭವನೀಯ ವಿವರಣೆಯು CPU ಸಂಪನ್ಮೂಲ ಕೋಟಾ ಮಿತಿಗಳಿಗೆ ಸಂಬಂಧಿಸಿದೆ. ಈ ಲೇಖನದಲ್ಲಿ ನಾವು ಮಾತನಾಡುತ್ತೇವೆ.
ಟಿಎಲ್; ಡಿಆರ್:
ನೀವು CFS ಕೋಟಾ ಬಗ್ನೊಂದಿಗೆ Linux ಕರ್ನಲ್ನ ಆವೃತ್ತಿಯನ್ನು ಬಳಸುತ್ತಿದ್ದರೆ Kubernetes (ಅಥವಾ Kubelet ನಲ್ಲಿ CFS ಕೋಟಾಗಳನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವುದು) ನಲ್ಲಿ CPU ಮಿತಿಗಳನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಲು ನಾವು ಬಲವಾಗಿ ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ. ಕೋರ್ನಲ್ಲಿ ಗಂಭೀರ ಮತ್ತು ಅತಿಯಾದ ಥ್ರೊಟ್ಲಿಂಗ್ ಮತ್ತು ವಿಳಂಬಕ್ಕೆ ಕಾರಣವಾಗುವ ದೋಷ.
ಒಮಿಯೊದಲ್ಲಿ ಸಂಪೂರ್ಣ ಮೂಲಸೌಕರ್ಯವನ್ನು ಕುಬರ್ನೆಟ್ಸ್ ನಿರ್ವಹಿಸುತ್ತಾರೆ. ನಮ್ಮ ಎಲ್ಲಾ ಸ್ಥಿತಿವಂತ ಮತ್ತು ಸ್ಥಿತಿಯಿಲ್ಲದ ಕೆಲಸದ ಹೊರೆಗಳು ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಪ್ರತ್ಯೇಕವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ (ನಾವು Google ಕುಬರ್ನೆಟ್ಸ್ ಎಂಜಿನ್ ಅನ್ನು ಬಳಸುತ್ತೇವೆ). ಕಳೆದ ಆರು ತಿಂಗಳುಗಳಲ್ಲಿ, ನಾವು ಯಾದೃಚ್ಛಿಕ ನಿಧಾನಗತಿಯನ್ನು ಗಮನಿಸಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ. ಅಪ್ಲಿಕೇಶನ್ಗಳು ಸ್ಥಗಿತಗೊಳ್ಳುತ್ತವೆ ಅಥವಾ ಆರೋಗ್ಯ ತಪಾಸಣೆಗಳಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತವೆ, ನೆಟ್ವರ್ಕ್ಗೆ ಸಂಪರ್ಕವನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತವೆ, ಇತ್ಯಾದಿ. ಈ ನಡವಳಿಕೆಯು ನಮ್ಮನ್ನು ದೀರ್ಘಕಾಲದವರೆಗೆ ಗೊಂದಲಗೊಳಿಸಿತು ಮತ್ತು ಅಂತಿಮವಾಗಿ ನಾವು ಸಮಸ್ಯೆಯನ್ನು ಗಂಭೀರವಾಗಿ ಪರಿಗಣಿಸಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ.
ಲೇಖನದ ಸಾರಾಂಶ:
- ಕಂಟೈನರ್ ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್ ಬಗ್ಗೆ ಕೆಲವು ಪದಗಳು;
- CPU ವಿನಂತಿಗಳು ಮತ್ತು ಮಿತಿಗಳನ್ನು ಹೇಗೆ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತದೆ;
- ಬಹು-ಕೋರ್ ಪರಿಸರದಲ್ಲಿ CPU ಮಿತಿ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ;
- CPU ಥ್ರೊಟ್ಲಿಂಗ್ ಅನ್ನು ಹೇಗೆ ಟ್ರ್ಯಾಕ್ ಮಾಡುವುದು;
- ಸಮಸ್ಯೆ ಪರಿಹಾರ ಮತ್ತು ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸಗಳು.
ಕಂಟೈನರ್ ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್ ಬಗ್ಗೆ ಕೆಲವು ಪದಗಳು
ಕುಬರ್ನೆಟ್ಸ್ ಮೂಲಭೂತವಾಗಿ ಮೂಲಸೌಕರ್ಯ ಜಗತ್ತಿನಲ್ಲಿ ಆಧುನಿಕ ಮಾನದಂಡವಾಗಿದೆ. ಇದರ ಮುಖ್ಯ ಕಾರ್ಯವೆಂದರೆ ಕಂಟೈನರ್ ಆರ್ಕೆಸ್ಟ್ರೇಶನ್.
ಕಂಟೇನರ್ಗಳು
ಹಿಂದೆ, ನಾವು ಸರ್ವರ್ಗಳಲ್ಲಿ ರನ್ ಮಾಡಲು Java JARs/WARs, Python Eggs ಅಥವಾ ಎಕ್ಸಿಕ್ಯೂಟಬಲ್ಗಳಂತಹ ಕಲಾಕೃತಿಗಳನ್ನು ರಚಿಸಬೇಕಾಗಿತ್ತು. ಆದಾಗ್ಯೂ, ಅವುಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು, ಹೆಚ್ಚುವರಿ ಕೆಲಸವನ್ನು ಮಾಡಬೇಕಾಗಿತ್ತು: ರನ್ಟೈಮ್ ಪರಿಸರವನ್ನು (ಜಾವಾ / ಪೈಥಾನ್) ಸ್ಥಾಪಿಸುವುದು, ಅಗತ್ಯ ಫೈಲ್ಗಳನ್ನು ಸರಿಯಾದ ಸ್ಥಳಗಳಲ್ಲಿ ಇರಿಸುವುದು, ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ನ ನಿರ್ದಿಷ್ಟ ಆವೃತ್ತಿಯೊಂದಿಗೆ ಹೊಂದಾಣಿಕೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವುದು ಇತ್ಯಾದಿ. ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ಸಂರಚನಾ ನಿರ್ವಹಣೆಗೆ ಎಚ್ಚರಿಕೆಯ ಗಮನವನ್ನು ನೀಡಬೇಕಾಗಿತ್ತು (ಇದು ಡೆವಲಪರ್ಗಳು ಮತ್ತು ಸಿಸ್ಟಮ್ ನಿರ್ವಾಹಕರ ನಡುವಿನ ವಿವಾದದ ಮೂಲವಾಗಿದೆ).
ಕಂಟೇನರ್ಗಳು ಎಲ್ಲವನ್ನೂ ಬದಲಾಯಿಸಿದವು. ಈಗ ಕಲಾಕೃತಿ ಕಂಟೈನರ್ ಚಿತ್ರವಾಗಿದೆ. ಇದು ಪ್ರೋಗ್ರಾಂ ಅನ್ನು ಮಾತ್ರ ಒಳಗೊಂಡಿರುವ ಒಂದು ರೀತಿಯ ವಿಸ್ತೃತ ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದಾದ ಫೈಲ್ನಂತೆ ಪ್ರತಿನಿಧಿಸಬಹುದು, ಆದರೆ ಪೂರ್ಣ ಪ್ರಮಾಣದ ಎಕ್ಸಿಕ್ಯೂಶನ್ ಎನ್ವಿರಾನ್ಮೆಂಟ್ (ಜಾವಾ/ಪೈಥಾನ್/...), ಹಾಗೆಯೇ ಅಗತ್ಯ ಫೈಲ್ಗಳು/ಪ್ಯಾಕೇಜುಗಳು, ಮೊದಲೇ ಸ್ಥಾಪಿಸಲಾಗಿದೆ ಮತ್ತು ಸಿದ್ಧವಾಗಿದೆ ಓಡು. ಯಾವುದೇ ಹೆಚ್ಚುವರಿ ಹಂತಗಳಿಲ್ಲದೆ ಕಂಟೇನರ್ಗಳನ್ನು ವಿವಿಧ ಸರ್ವರ್ಗಳಲ್ಲಿ ನಿಯೋಜಿಸಬಹುದು ಮತ್ತು ರನ್ ಮಾಡಬಹುದು.
ಜೊತೆಗೆ, ಕಂಟೈನರ್ಗಳು ತಮ್ಮದೇ ಆದ ಸ್ಯಾಂಡ್ಬಾಕ್ಸ್ ಪರಿಸರದಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. ಅವರು ತಮ್ಮದೇ ಆದ ವರ್ಚುವಲ್ ನೆಟ್ವರ್ಕ್ ಅಡಾಪ್ಟರ್, ಸೀಮಿತ ಪ್ರವೇಶದೊಂದಿಗೆ ತಮ್ಮದೇ ಆದ ಫೈಲ್ ಸಿಸ್ಟಮ್, ಪ್ರಕ್ರಿಯೆಗಳ ತಮ್ಮದೇ ಆದ ಕ್ರಮಾನುಗತ, ಸಿಪಿಯು ಮತ್ತು ಮೆಮೊರಿಯಲ್ಲಿ ತಮ್ಮದೇ ಆದ ಮಿತಿಗಳನ್ನು ಹೊಂದಿದ್ದಾರೆ. ಇವೆಲ್ಲವನ್ನೂ ಲಿನಕ್ಸ್ ಕರ್ನಲ್ - ನೇಮ್ಸ್ಪೇಸ್ನ ವಿಶೇಷ ಉಪವ್ಯವಸ್ಥೆಗೆ ಧನ್ಯವಾದಗಳು.
ಕುಬರ್ನೆಟ್ಸ್
ಮೊದಲೇ ಹೇಳಿದಂತೆ, ಕುಬರ್ನೆಟ್ಸ್ ಕಂಟೇನರ್ ಆರ್ಕೆಸ್ಟ್ರೇಟರ್. ಇದು ಈ ರೀತಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ: ನೀವು ಅದಕ್ಕೆ ಯಂತ್ರಗಳ ಪೂಲ್ ಅನ್ನು ನೀಡಿ, ತದನಂತರ ಹೀಗೆ ಹೇಳಿ: "ಹೇ, ಕುಬರ್ನೆಟ್ಸ್, 2 ಪ್ರೊಸೆಸರ್ಗಳು ಮತ್ತು 3 GB ಮೆಮೊರಿಯೊಂದಿಗೆ ನನ್ನ ಕಂಟೇನರ್ನ ಹತ್ತು ನಿದರ್ಶನಗಳನ್ನು ಪ್ರಾರಂಭಿಸೋಣ ಮತ್ತು ಅವುಗಳನ್ನು ಚಾಲನೆಯಲ್ಲಿರಿಸೋಣ!" ಉಳಿದದ್ದನ್ನು ಕುಬರ್ನೆಟ್ಸ್ ನೋಡಿಕೊಳ್ಳುತ್ತಾರೆ. ಇದು ಉಚಿತ ಸಾಮರ್ಥ್ಯವನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತದೆ, ಕಂಟೇನರ್ಗಳನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತದೆ ಮತ್ತು ಅಗತ್ಯವಿದ್ದರೆ ಅವುಗಳನ್ನು ಮರುಪ್ರಾರಂಭಿಸುತ್ತದೆ, ಆವೃತ್ತಿಗಳನ್ನು ಬದಲಾಯಿಸುವಾಗ ನವೀಕರಣಗಳನ್ನು ಹೊರತರುತ್ತದೆ, ಇತ್ಯಾದಿ. ಮೂಲಭೂತವಾಗಿ, ಕುಬರ್ನೆಟ್ಸ್ ನಿಮಗೆ ಹಾರ್ಡ್ವೇರ್ ಘಟಕವನ್ನು ಅಮೂರ್ತಗೊಳಿಸಲು ಅನುಮತಿಸುತ್ತದೆ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ಗಳನ್ನು ನಿಯೋಜಿಸಲು ಮತ್ತು ಚಲಾಯಿಸಲು ಸೂಕ್ತವಾದ ವಿವಿಧ ರೀತಿಯ ಸಿಸ್ಟಮ್ಗಳನ್ನು ಮಾಡುತ್ತದೆ.
ಸಾಮಾನ್ಯರ ದೃಷ್ಟಿಕೋನದಿಂದ ಕುಬರ್ನೆಟ್ಸ್
ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ವಿನಂತಿಗಳು ಮತ್ತು ಮಿತಿಗಳು ಯಾವುವು
ಸರಿ, ನಾವು ಕಂಟೇನರ್ಗಳು ಮತ್ತು ಕುಬರ್ನೆಟ್ಗಳನ್ನು ಆವರಿಸಿದ್ದೇವೆ. ಒಂದೇ ಯಂತ್ರದಲ್ಲಿ ಬಹು ಕಂಟೈನರ್ಗಳು ಇರಬಹುದೆಂದು ನಮಗೆ ತಿಳಿದಿದೆ.
ಸಾಮುದಾಯಿಕ ಅಪಾರ್ಟ್ಮೆಂಟ್ನೊಂದಿಗೆ ಸಾದೃಶ್ಯವನ್ನು ಎಳೆಯಬಹುದು. ವಿಶಾಲವಾದ ಆವರಣವನ್ನು (ಯಂತ್ರಗಳು/ಘಟಕಗಳು) ತೆಗೆದುಕೊಂಡು ಹಲವಾರು ಬಾಡಿಗೆದಾರರಿಗೆ (ಕಂಟೇನರ್) ಬಾಡಿಗೆಗೆ ನೀಡಲಾಗುತ್ತದೆ. ಕುಬರ್ನೆಟ್ಸ್ ರಿಯಾಲ್ಟರ್ ಆಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಾನೆ. ಪ್ರಶ್ನೆ ಉದ್ಭವಿಸುತ್ತದೆ, ಬಾಡಿಗೆದಾರರನ್ನು ಪರಸ್ಪರ ಘರ್ಷಣೆಯಿಂದ ಇಟ್ಟುಕೊಳ್ಳುವುದು ಹೇಗೆ? ಅವರಲ್ಲಿ ಒಬ್ಬರು ಹೇಳುವುದಾದರೆ, ಅರ್ಧ ದಿನಕ್ಕೆ ಸ್ನಾನಗೃಹವನ್ನು ಎರವಲು ತೆಗೆದುಕೊಳ್ಳಲು ನಿರ್ಧರಿಸಿದರೆ ಏನು?
ಇಲ್ಲಿ ವಿನಂತಿಗಳು ಮತ್ತು ಮಿತಿಗಳು ಕಾರ್ಯರೂಪಕ್ಕೆ ಬರುತ್ತವೆ. CPU ವಿನಂತಿ ಯೋಜನೆ ಉದ್ದೇಶಗಳಿಗಾಗಿ ಮಾತ್ರ ಅಗತ್ಯವಿದೆ. ಇದು ಕಂಟೇನರ್ನ "ವಿಶ್ ಲಿಸ್ಟ್" ನಂತಹದ್ದು ಮತ್ತು ಹೆಚ್ಚು ಸೂಕ್ತವಾದ ನೋಡ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಲು ಇದನ್ನು ಬಳಸಲಾಗುತ್ತದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ ಸಿಪಿಯು ಮಿತಿ ಬಾಡಿಗೆ ಒಪ್ಪಂದಕ್ಕೆ ಹೋಲಿಸಬಹುದು - ನಾವು ಕಂಟೇನರ್ಗಾಗಿ ಘಟಕವನ್ನು ಆಯ್ಕೆ ಮಾಡಿದ ತಕ್ಷಣ, ದಿ ಸಾಧ್ಯವಿಲ್ಲ ಸ್ಥಾಪಿತ ಮಿತಿಗಳನ್ನು ಮೀರಿ. ಮತ್ತು ಇಲ್ಲಿ ಸಮಸ್ಯೆ ಉದ್ಭವಿಸುತ್ತದೆ ...
ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ವಿನಂತಿಗಳು ಮತ್ತು ಮಿತಿಗಳನ್ನು ಹೇಗೆ ಅಳವಡಿಸಲಾಗಿದೆ
CPU ಮಿತಿಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಕರ್ನಲ್ನಲ್ಲಿ ನಿರ್ಮಿಸಲಾದ ಥ್ರೊಟ್ಲಿಂಗ್ ಕಾರ್ಯವಿಧಾನವನ್ನು (ಗಡಿಯಾರ ಚಕ್ರಗಳನ್ನು ಬಿಟ್ಟುಬಿಡುವುದು) Kubernetes ಬಳಸುತ್ತದೆ. ಅಪ್ಲಿಕೇಶನ್ ಮಿತಿಯನ್ನು ಮೀರಿದರೆ, ಥ್ರೊಟ್ಲಿಂಗ್ ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಲಾಗುತ್ತದೆ (ಅಂದರೆ ಅದು ಕಡಿಮೆ CPU ಚಕ್ರಗಳನ್ನು ಪಡೆಯುತ್ತದೆ). ಮೆಮೊರಿಗಾಗಿ ವಿನಂತಿಗಳು ಮತ್ತು ಮಿತಿಗಳನ್ನು ವಿಭಿನ್ನವಾಗಿ ಆಯೋಜಿಸಲಾಗಿದೆ, ಆದ್ದರಿಂದ ಅವುಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಸುಲಭವಾಗಿದೆ. ಇದನ್ನು ಮಾಡಲು, ಪಾಡ್ನ ಕೊನೆಯ ಮರುಪ್ರಾರಂಭದ ಸ್ಥಿತಿಯನ್ನು ಪರಿಶೀಲಿಸಿ: ಅದು "OOMKilled" ಆಗಿದೆಯೇ. CPU ಥ್ರೊಟ್ಲಿಂಗ್ ಅಷ್ಟು ಸುಲಭವಲ್ಲ, ಏಕೆಂದರೆ K8s ಬಳಕೆಯ ಮೂಲಕ ಮಾತ್ರ ಮೆಟ್ರಿಕ್ಗಳನ್ನು ಲಭ್ಯವಾಗುವಂತೆ ಮಾಡುತ್ತದೆ, cgroups ಮೂಲಕ ಅಲ್ಲ.
CPU ವಿನಂತಿ
CPU ವಿನಂತಿಯನ್ನು ಹೇಗೆ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತದೆ
ಸರಳತೆಗಾಗಿ, ಉದಾಹರಣೆಯಾಗಿ 4-ಕೋರ್ CPU ಹೊಂದಿರುವ ಯಂತ್ರವನ್ನು ಬಳಸುವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ನೋಡೋಣ.
K8s ಸಂಪನ್ಮೂಲಗಳ (ಮೆಮೊರಿ ಮತ್ತು ಪ್ರೊಸೆಸರ್) ಹಂಚಿಕೆಯನ್ನು ನಿಯಂತ್ರಿಸಲು ನಿಯಂತ್ರಣ ಗುಂಪಿನ ಕಾರ್ಯವಿಧಾನವನ್ನು (cgroups) ಬಳಸುತ್ತದೆ. ಅದಕ್ಕೆ ಕ್ರಮಾನುಗತ ಮಾದರಿ ಲಭ್ಯವಿದೆ: ಮಗು ಪೋಷಕ ಗುಂಪಿನ ಮಿತಿಗಳನ್ನು ಆನುವಂಶಿಕವಾಗಿ ಪಡೆಯುತ್ತದೆ. ವಿತರಣಾ ವಿವರಗಳನ್ನು ವರ್ಚುವಲ್ ಫೈಲ್ ಸಿಸ್ಟಮ್ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗಿದೆ (/sys/fs/cgroup) ಪ್ರೊಸೆಸರ್ನ ಸಂದರ್ಭದಲ್ಲಿ ಇದು /sys/fs/cgroup/cpu,cpuacct/*.
K8s ಫೈಲ್ ಅನ್ನು ಬಳಸುತ್ತದೆ cpu.share ಪ್ರೊಸೆಸರ್ ಸಂಪನ್ಮೂಲಗಳನ್ನು ನಿಯೋಜಿಸಲು. ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ರೂಟ್ cgroup CPU ಸಂಪನ್ಮೂಲಗಳ 4096 ಷೇರುಗಳನ್ನು ಪಡೆಯುತ್ತದೆ - ಲಭ್ಯವಿರುವ ಪ್ರೊಸೆಸರ್ ಶಕ್ತಿಯ 100% (1 ಕೋರ್ = 1024; ಇದು ಸ್ಥಿರ ಮೌಲ್ಯವಾಗಿದೆ). ಮೂಲ ಗುಂಪು ನೋಂದಾಯಿಸಿದ ವಂಶಸ್ಥರ ಷೇರುಗಳನ್ನು ಅವಲಂಬಿಸಿ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಪ್ರಮಾಣಾನುಗುಣವಾಗಿ ವಿತರಿಸುತ್ತದೆ cpu.share, ಮತ್ತು ಅವರು ತಮ್ಮ ವಂಶಸ್ಥರೊಂದಿಗೆ ಅದೇ ರೀತಿ ಮಾಡುತ್ತಾರೆ, ಇತ್ಯಾದಿ. ವಿಶಿಷ್ಟವಾದ ಕುಬರ್ನೆಟ್ಸ್ ನೋಡ್ನಲ್ಲಿ, ರೂಟ್ ಸಿಗ್ರೂಪ್ ಮೂರು ಮಕ್ಕಳನ್ನು ಹೊಂದಿದೆ: system.slice, user.slice и kubepods. ಮೊದಲ ಎರಡು ಉಪಗುಂಪುಗಳನ್ನು K8 ಗಳ ಹೊರಗಿನ ನಿರ್ಣಾಯಕ ಸಿಸ್ಟಮ್ ಲೋಡ್ಗಳು ಮತ್ತು ಬಳಕೆದಾರರ ಪ್ರೋಗ್ರಾಂಗಳ ನಡುವೆ ಸಂಪನ್ಮೂಲಗಳನ್ನು ವಿತರಿಸಲು ಬಳಸಲಾಗುತ್ತದೆ. ಕೊನೆಯದು - kubepods - ಪಾಡ್ಗಳ ನಡುವೆ ಸಂಪನ್ಮೂಲಗಳನ್ನು ವಿತರಿಸಲು ಕುಬರ್ನೆಟ್ಸ್ ರಚಿಸಿದ್ದಾರೆ.
ಮೇಲಿನ ರೇಖಾಚಿತ್ರವು ಮೊದಲ ಮತ್ತು ಎರಡನೆಯ ಉಪಗುಂಪುಗಳು ಪ್ರತಿಯೊಂದನ್ನು ಸ್ವೀಕರಿಸಿದೆ ಎಂದು ತೋರಿಸುತ್ತದೆ 1024 ಹಂಚಿಕೆಗಳು, kuberpod ಉಪಗುಂಪು ಹಂಚಿಕೆಯೊಂದಿಗೆ 4096 ಷೇರುಗಳು ಇದು ಹೇಗೆ ಸಾಧ್ಯ: ಎಲ್ಲಾ ನಂತರ, ರೂಟ್ ಗುಂಪಿಗೆ ಮಾತ್ರ ಪ್ರವೇಶವಿದೆ 4096 ಷೇರುಗಳು, ಮತ್ತು ಅವಳ ವಂಶಸ್ಥರ ಷೇರುಗಳ ಮೊತ್ತವು ಈ ಸಂಖ್ಯೆಯನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಮೀರಿದೆ (6144)? ಮೌಲ್ಯವು ತಾರ್ಕಿಕ ಅರ್ಥವನ್ನು ನೀಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಲಿನಕ್ಸ್ ಶೆಡ್ಯೂಲರ್ (CFS) CPU ಸಂಪನ್ಮೂಲಗಳನ್ನು ಪ್ರಮಾಣಾನುಗುಣವಾಗಿ ನಿಯೋಜಿಸಲು ಬಳಸುತ್ತದೆ. ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ಮೊದಲ ಎರಡು ಗುಂಪುಗಳು ಸ್ವೀಕರಿಸುತ್ತವೆ 680 ನೈಜ ಷೇರುಗಳು (16,6 ರಲ್ಲಿ 4096%), ಮತ್ತು kubepod ಉಳಿದವುಗಳನ್ನು ಪಡೆಯುತ್ತದೆ 2736 ಷೇರುಗಳು ಅಲಭ್ಯತೆಯ ಸಂದರ್ಭದಲ್ಲಿ, ಮೊದಲ ಎರಡು ಗುಂಪುಗಳು ನಿಯೋಜಿಸಲಾದ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಬಳಸುವುದಿಲ್ಲ.
ಅದೃಷ್ಟವಶಾತ್, ಬಳಕೆಯಾಗದ CPU ಸಂಪನ್ಮೂಲಗಳನ್ನು ವ್ಯರ್ಥ ಮಾಡುವುದನ್ನು ತಪ್ಪಿಸಲು ಶೆಡ್ಯೂಲರ್ ಒಂದು ಕಾರ್ಯವಿಧಾನವನ್ನು ಹೊಂದಿದೆ. ಇದು "ಐಡಲ್" ಸಾಮರ್ಥ್ಯವನ್ನು ಜಾಗತಿಕ ಪೂಲ್ಗೆ ವರ್ಗಾಯಿಸುತ್ತದೆ, ಇದರಿಂದ ಹೆಚ್ಚುವರಿ ಪ್ರೊಸೆಸರ್ ಶಕ್ತಿಯ ಅಗತ್ಯವಿರುವ ಗುಂಪುಗಳಿಗೆ ವಿತರಿಸಲಾಗುತ್ತದೆ (ರೌಂಡಿಂಗ್ ನಷ್ಟವನ್ನು ತಪ್ಪಿಸಲು ಬ್ಯಾಚ್ಗಳಲ್ಲಿ ವರ್ಗಾವಣೆ ಸಂಭವಿಸುತ್ತದೆ). ವಂಶಸ್ಥರ ಎಲ್ಲಾ ವಂಶಸ್ಥರಿಗೂ ಇದೇ ವಿಧಾನವನ್ನು ಅನ್ವಯಿಸಲಾಗುತ್ತದೆ.
ಈ ಕಾರ್ಯವಿಧಾನವು ಪ್ರೊಸೆಸರ್ ಶಕ್ತಿಯ ನ್ಯಾಯೋಚಿತ ವಿತರಣೆಯನ್ನು ಖಾತ್ರಿಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಯಾವುದೇ ಪ್ರಕ್ರಿಯೆಯು ಇತರರಿಂದ ಸಂಪನ್ಮೂಲಗಳನ್ನು "ಕದಿಯುವುದಿಲ್ಲ" ಎಂದು ಖಚಿತಪಡಿಸುತ್ತದೆ.
CPU ಮಿತಿ
K8 ಗಳಲ್ಲಿನ ಮಿತಿಗಳು ಮತ್ತು ವಿನಂತಿಗಳ ಸಂರಚನೆಗಳು ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತವೆ ಎಂಬ ವಾಸ್ತವದ ಹೊರತಾಗಿಯೂ, ಅವುಗಳ ಅನುಷ್ಠಾನವು ಆಮೂಲಾಗ್ರವಾಗಿ ವಿಭಿನ್ನವಾಗಿದೆ: ಇದು ಅತ್ಯಂತ ತಪ್ಪುದಾರಿಗೆಳೆಯುವ ಮತ್ತು ಕಡಿಮೆ ದಾಖಲಿತ ಭಾಗ.
K8s ತೊಡಗಿಸಿಕೊಂಡಿದೆ ಮಿತಿಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು. ಅವರ ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನು ಫೈಲ್ಗಳಲ್ಲಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಲಾಗಿದೆ cfs_period_us и cfs_quota_us cgroup ಡೈರೆಕ್ಟರಿಯಲ್ಲಿ (ಫೈಲ್ ಸಹ ಇದೆ cpu.share).
ಭಿನ್ನವಾಗಿ cpu.share, ಕೋಟಾವನ್ನು ಆಧರಿಸಿದೆ ಸಮಯದ ಅವಧಿ, ಮತ್ತು ಲಭ್ಯವಿರುವ ಪ್ರೊಸೆಸರ್ ಶಕ್ತಿಯಲ್ಲಿ ಅಲ್ಲ. cfs_period_us ಅವಧಿಯ ಅವಧಿಯನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತದೆ (ಯುಗ) - ಇದು ಯಾವಾಗಲೂ 100000 μs (100 ms) ಆಗಿರುತ್ತದೆ. K8s ನಲ್ಲಿ ಈ ಮೌಲ್ಯವನ್ನು ಬದಲಾಯಿಸಲು ಒಂದು ಆಯ್ಕೆ ಇದೆ, ಆದರೆ ಇದು ಸದ್ಯಕ್ಕೆ ಆಲ್ಫಾದಲ್ಲಿ ಮಾತ್ರ ಲಭ್ಯವಿದೆ. ಬಳಸಿದ ಕೋಟಾಗಳನ್ನು ಮರುಪ್ರಾರಂಭಿಸಲು ಶೆಡ್ಯೂಲರ್ ಯುಗವನ್ನು ಬಳಸುತ್ತದೆ. ಎರಡನೇ ಫೈಲ್ cfs_quota_us, ಪ್ರತಿ ಯುಗದಲ್ಲಿ ಲಭ್ಯವಿರುವ ಸಮಯವನ್ನು (ಕೋಟಾ) ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತದೆ. ಇದನ್ನು ಮೈಕ್ರೋಸೆಕೆಂಡ್ಗಳಲ್ಲಿಯೂ ನಿರ್ದಿಷ್ಟಪಡಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ಗಮನಿಸಿ. ಕೋಟಾ ಯುಗ ಉದ್ದವನ್ನು ಮೀರಬಹುದು; ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ಇದು 100 ms ಗಿಂತ ಹೆಚ್ಚಿರಬಹುದು.
16-ಕೋರ್ ಯಂತ್ರಗಳಲ್ಲಿ ಎರಡು ಸನ್ನಿವೇಶಗಳನ್ನು ನೋಡೋಣ (ಓಮಿಯೊದಲ್ಲಿ ನಾವು ಹೊಂದಿರುವ ಸಾಮಾನ್ಯ ರೀತಿಯ ಕಂಪ್ಯೂಟರ್):
ಸನ್ನಿವೇಶ 1: 2 ಎಳೆಗಳು ಮತ್ತು 200 ms ಮಿತಿ. ಥ್ರೊಟ್ಲಿಂಗ್ ಇಲ್ಲ
ಸನ್ನಿವೇಶ 2: 10 ಎಳೆಗಳು ಮತ್ತು 200 ms ಮಿತಿ. ಥ್ರೊಟ್ಲಿಂಗ್ 20 ms ನಂತರ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ, ಇನ್ನೊಂದು 80 ms ನಂತರ ಪ್ರೊಸೆಸರ್ ಸಂಪನ್ಮೂಲಗಳಿಗೆ ಪ್ರವೇಶವನ್ನು ಪುನರಾರಂಭಿಸಲಾಗುತ್ತದೆ
ನೀವು CPU ಮಿತಿಯನ್ನು ಹೊಂದಿಸಿದ್ದೀರಿ ಎಂದು ಹೇಳೋಣ 2 ಕರ್ನಲ್ಗಳು; ಕುಬರ್ನೆಟ್ಸ್ ಈ ಮೌಲ್ಯವನ್ನು 200 ms ಗೆ ಅನುವಾದಿಸುತ್ತದೆ. ಇದರರ್ಥ ಕಂಟೇನರ್ ಥ್ರೊಟ್ಲಿಂಗ್ ಇಲ್ಲದೆಯೇ ಗರಿಷ್ಠ 200ms CPU ಸಮಯವನ್ನು ಬಳಸಬಹುದು.
ಮತ್ತು ಇಲ್ಲಿ ವಿನೋದ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ. ಮೇಲೆ ಹೇಳಿದಂತೆ, ಲಭ್ಯವಿರುವ ಕೋಟಾ 200 ms ಆಗಿದೆ. ನೀವು ಸಮಾನಾಂತರವಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದರೆ ಹತ್ತು 12-ಕೋರ್ ಯಂತ್ರದಲ್ಲಿ ಥ್ರೆಡ್ಗಳು (ಸನ್ನಿವೇಶ 2 ಕ್ಕೆ ವಿವರಣೆಯನ್ನು ನೋಡಿ), ಇತರ ಎಲ್ಲಾ ಪಾಡ್ಗಳು ನಿಷ್ಕ್ರಿಯವಾಗಿರುವಾಗ, ಕೋಟಾವು ಕೇವಲ 20 ms ನಲ್ಲಿ ಖಾಲಿಯಾಗುತ್ತದೆ (10 * 20 ms = 200 ms ರಿಂದ), ಮತ್ತು ಈ ಪಾಡ್ನ ಎಲ್ಲಾ ಎಳೆಗಳು ಸ್ಥಗಿತಗೊಳ್ಳುತ್ತವೆ » (ಥ್ರೊಟಲ್) ಮುಂದಿನ 80 ms ಗೆ. ಈಗಾಗಲೇ ಉಲ್ಲೇಖಿಸಲಾಗಿದೆ , ಇದರಿಂದಾಗಿ ಅತಿಯಾದ ಥ್ರೊಟ್ಲಿಂಗ್ ಸಂಭವಿಸುತ್ತದೆ ಮತ್ತು ಧಾರಕವು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಕೋಟಾವನ್ನು ಸಹ ಪೂರೈಸಲು ಸಾಧ್ಯವಿಲ್ಲ.
ಪಾಡ್ಗಳಲ್ಲಿ ಥ್ರೊಟ್ಲಿಂಗ್ ಅನ್ನು ಹೇಗೆ ಮೌಲ್ಯಮಾಪನ ಮಾಡುವುದು?
ಕೇವಲ ಪಾಡ್ಗೆ ಲಾಗಿನ್ ಮಾಡಿ ಮತ್ತು ಕಾರ್ಯಗತಗೊಳಿಸಿ cat /sys/fs/cgroup/cpu/cpu.stat.
-
nr_periods- ಶೆಡ್ಯೂಲರ್ ಅವಧಿಗಳ ಒಟ್ಟು ಸಂಖ್ಯೆ; -
nr_throttled- ಸಂಯೋಜನೆಯಲ್ಲಿ ಥ್ರೊಟಲ್ಡ್ ಅವಧಿಗಳ ಸಂಖ್ಯೆnr_periods; -
throttled_time- ನ್ಯಾನೊಸೆಕೆಂಡ್ಗಳಲ್ಲಿ ಸಂಚಿತ ಥ್ರೊಟಲ್ಡ್ ಸಮಯ.
ನಿಜವಾಗಿಯೂ ಏನು ನಡೆಯುತ್ತಿದೆ?
ಪರಿಣಾಮವಾಗಿ, ನಾವು ಎಲ್ಲಾ ಅಪ್ಲಿಕೇಶನ್ಗಳಲ್ಲಿ ಹೆಚ್ಚಿನ ಥ್ರೊಟ್ಲಿಂಗ್ ಅನ್ನು ಪಡೆಯುತ್ತೇವೆ. ಕೆಲವೊಮ್ಮೆ ಅವನು ಒಳಗೆ ಇರುತ್ತಾನೆ ಒಂದೂವರೆ ಬಾರಿ ಲೆಕ್ಕಾಚಾರಕ್ಕಿಂತ ಪ್ರಬಲವಾಗಿದೆ!
ಇದು ವಿವಿಧ ದೋಷಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ - ಸಿದ್ಧತೆ ಪರಿಶೀಲನೆ ವಿಫಲತೆಗಳು, ಕಂಟೇನರ್ ಫ್ರೀಜ್ಗಳು, ನೆಟ್ವರ್ಕ್ ಸಂಪರ್ಕ ವಿರಾಮಗಳು, ಸೇವಾ ಕರೆಗಳಲ್ಲಿ ಸಮಯ ಮೀರುವುದು. ಇದು ಅಂತಿಮವಾಗಿ ಹೆಚ್ಚಿದ ಸುಪ್ತತೆ ಮತ್ತು ಹೆಚ್ಚಿನ ದೋಷ ದರಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ.
ನಿರ್ಧಾರ ಮತ್ತು ಪರಿಣಾಮಗಳು
ಇಲ್ಲಿ ಎಲ್ಲವೂ ಸರಳವಾಗಿದೆ. ನಾವು CPU ಮಿತಿಗಳನ್ನು ತ್ಯಜಿಸಿದ್ದೇವೆ ಮತ್ತು ಕ್ಲಸ್ಟರ್ಗಳಲ್ಲಿ OS ಕರ್ನಲ್ ಅನ್ನು ಇತ್ತೀಚಿನ ಆವೃತ್ತಿಗೆ ನವೀಕರಿಸಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ, ಅದರಲ್ಲಿ ದೋಷವನ್ನು ಸರಿಪಡಿಸಲಾಗಿದೆ. ನಮ್ಮ ಸೇವೆಗಳಲ್ಲಿ ದೋಷಗಳ ಸಂಖ್ಯೆ (HTTP 5xx) ತಕ್ಷಣವೇ ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆಯಾಗಿದೆ:
HTTP 5xx ದೋಷಗಳು
ಒಂದು ನಿರ್ಣಾಯಕ ಸೇವೆಗಾಗಿ HTTP 5xx ದೋಷಗಳು
ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯ p95
ನಿರ್ಣಾಯಕ ಸೇವಾ ವಿನಂತಿಯ ಸುಪ್ತತೆ, 95ನೇ ಶೇಕಡಾವಾರು
ಕಾರ್ಯಾಚರಣೆಯ ವೆಚ್ಚಗಳು
ಖರ್ಚು ಮಾಡಿದ ಉದಾಹರಣೆಗಳ ಸಂಖ್ಯೆ
ಕ್ಯಾಚ್ ಎಂದರೇನು?
ಲೇಖನದ ಆರಂಭದಲ್ಲಿ ಹೇಳಿದಂತೆ:
ಸಾಮುದಾಯಿಕ ಅಪಾರ್ಟ್ಮೆಂಟ್ನೊಂದಿಗೆ ಸಾದೃಶ್ಯವನ್ನು ಎಳೆಯಬಹುದು ... ಕುಬರ್ನೆಟ್ಸ್ ರಿಯಾಲ್ಟರ್ ಆಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಾನೆ. ಆದರೆ ಬಾಡಿಗೆದಾರರನ್ನು ಪರಸ್ಪರ ಘರ್ಷಣೆಯಿಂದ ಇಟ್ಟುಕೊಳ್ಳುವುದು ಹೇಗೆ? ಅವರಲ್ಲಿ ಒಬ್ಬರು ಹೇಳುವುದಾದರೆ, ಅರ್ಧ ದಿನಕ್ಕೆ ಸ್ನಾನಗೃಹವನ್ನು ಎರವಲು ತೆಗೆದುಕೊಳ್ಳಲು ನಿರ್ಧರಿಸಿದರೆ ಏನು?
ಕ್ಯಾಚ್ ಇಲ್ಲಿದೆ. ಒಂದು ಅಸಡ್ಡೆ ಕಂಟೇನರ್ ಯಂತ್ರದಲ್ಲಿ ಲಭ್ಯವಿರುವ ಎಲ್ಲಾ CPU ಸಂಪನ್ಮೂಲಗಳನ್ನು ತಿನ್ನುತ್ತದೆ. ನೀವು ಸ್ಮಾರ್ಟ್ ಅಪ್ಲಿಕೇಶನ್ ಸ್ಟಾಕ್ ಹೊಂದಿದ್ದರೆ (ಉದಾಹರಣೆಗೆ, JVM, Go, Node VM ಅನ್ನು ಸರಿಯಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ), ನಂತರ ಇದು ಸಮಸ್ಯೆ ಅಲ್ಲ: ನೀವು ಅಂತಹ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ ದೀರ್ಘಕಾಲದವರೆಗೆ ಕೆಲಸ ಮಾಡಬಹುದು. ಆದರೆ ಅಪ್ಲಿಕೇಶನ್ಗಳು ಕಳಪೆಯಾಗಿ ಆಪ್ಟಿಮೈಸ್ ಆಗಿದ್ದರೆ ಅಥವಾ ಆಪ್ಟಿಮೈಸ್ ಮಾಡದಿದ್ದರೆ (FROM java:latest), ಪರಿಸ್ಥಿತಿ ನಿಯಂತ್ರಣದಿಂದ ಹೊರಬರಬಹುದು. Omio ನಲ್ಲಿ ನಾವು ಪ್ರಮುಖ ಭಾಷಾ ಸ್ಟಾಕ್ಗಾಗಿ ಸಾಕಷ್ಟು ಡೀಫಾಲ್ಟ್ ಸೆಟ್ಟಿಂಗ್ಗಳೊಂದಿಗೆ ಸ್ವಯಂಚಾಲಿತ ಬೇಸ್ ಡಾಕರ್ಫೈಲ್ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಆದ್ದರಿಂದ ಈ ಸಮಸ್ಯೆ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ.
ಮೆಟ್ರಿಕ್ಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು ನಾವು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ (ಬಳಕೆ, ಶುದ್ಧತ್ವ ಮತ್ತು ದೋಷಗಳು), API ವಿಳಂಬಗಳು ಮತ್ತು ದೋಷ ದರಗಳು. ಫಲಿತಾಂಶಗಳು ನಿರೀಕ್ಷೆಗಳನ್ನು ಪೂರೈಸುತ್ತವೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ.
ಉಲ್ಲೇಖಗಳು
ಇದು ನಮ್ಮ ಕಥೆ. ಏನಾಗುತ್ತಿದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಈ ಕೆಳಗಿನ ವಸ್ತುಗಳು ಹೆಚ್ಚು ಸಹಾಯ ಮಾಡುತ್ತವೆ:
- ;
- ;
- ;
- ;
- - "ಸಿಪಿಯು ಥ್ರೊಟ್ಲಿಂಗ್" ಗಾಗಿ ನೋಡಿ.
ಕುಬರ್ನೆಟ್ಸ್ ದೋಷ ವರದಿಗಳು:
- ;
- ;
- .
ನಿಮ್ಮ ಅಭ್ಯಾಸದಲ್ಲಿ ನೀವು ಇದೇ ರೀತಿಯ ಸಮಸ್ಯೆಗಳನ್ನು ಎದುರಿಸಿದ್ದೀರಾ ಅಥವಾ ಕಂಟೈನರೈಸ್ಡ್ ಉತ್ಪಾದನಾ ಪರಿಸರದಲ್ಲಿ ಥ್ರೊಟ್ಲಿಂಗ್ಗೆ ಸಂಬಂಧಿಸಿದ ಅನುಭವವನ್ನು ಹೊಂದಿದ್ದೀರಾ? ಕಾಮೆಂಟ್ಗಳಲ್ಲಿ ನಿಮ್ಮ ಕಥೆಯನ್ನು ಹಂಚಿಕೊಳ್ಳಿ!
ಅನುವಾದಕರಿಂದ PS
ನಮ್ಮ ಬ್ಲಾಗ್ನಲ್ಲಿಯೂ ಓದಿ:
- «";
- «";
- «».
ಮೂಲ: www.habr.com
