ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಕುಬರ್ನೆಟ್ಸ್ಗೆ (ಹೆಲ್ಮ್ ಅಥವಾ ಹಸ್ತಚಾಲಿತವಾಗಿ ಬಳಸಿ) ವರ್ಗಾಯಿಸಲು ಸಾಕು ಎಂದು ಅನೇಕ ಜನರು ಭಾವಿಸುತ್ತಾರೆ - ಮತ್ತು ಸಂತೋಷ ಇರುತ್ತದೆ. ಆದರೆ ಎಲ್ಲವೂ ಅಷ್ಟು ಸರಳವಲ್ಲ.
ತಂಡದ DevOps ಇಂಜಿನಿಯರ್ ಜೂಲಿಯನ್ ಗಿಂಡಿಯವರ ಲೇಖನವನ್ನು ಅನುವಾದಿಸಲಾಗಿದೆ. ನೀವು ಅದೇ ಕುಂಟೆಯ ಮೇಲೆ ಹೆಜ್ಜೆ ಹಾಕದಂತೆ ವಲಸೆ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ತನ್ನ ಕಂಪನಿಯು ಎದುರಿಸಿದ ಅಪಾಯಗಳನ್ನು ಅವನು ಹೇಳುತ್ತಾನೆ.
ಹಂತ ಒಂದು: ಪಾಡ್ ವಿನಂತಿಗಳು ಮತ್ತು ಮಿತಿಗಳನ್ನು ಹೊಂದಿಸಿ
ನಮ್ಮ ಪಾಡ್‌ಗಳು ಓಡುವ ಸ್ವಚ್ಛ ಪರಿಸರವನ್ನು ಹೊಂದಿಸುವ ಮೂಲಕ ಪ್ರಾರಂಭಿಸೋಣ. ಕುಬರ್ನೆಟ್ಸ್ ಪಾಡ್ ಶೆಡ್ಯೂಲಿಂಗ್ ಮತ್ತು ವಿಫಲತೆಯಲ್ಲಿ ಉತ್ತಮವಾಗಿದೆ. ಆದರೆ ಶೆಡ್ಯೂಲರ್ ಕೆಲವೊಮ್ಮೆ ಪಾಡ್ ಅನ್ನು ಇರಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂದು ಅದು ಬದಲಾಯಿತು, ಅದು ಎಷ್ಟು ಸಂಪನ್ಮೂಲಗಳನ್ನು ಯಶಸ್ವಿಯಾಗಿ ಕೆಲಸ ಮಾಡಬೇಕೆಂದು ಅಂದಾಜು ಮಾಡಲು ಕಷ್ಟವಾಗುತ್ತದೆ. ಇಲ್ಲಿ ಸಂಪನ್ಮೂಲಗಳು ಮತ್ತು ಮಿತಿಗಳಿಗಾಗಿ ವಿನಂತಿಗಳು ಪಾಪ್ ಅಪ್ ಆಗುತ್ತವೆ. ವಿನಂತಿಗಳು ಮತ್ತು ಮಿತಿಗಳನ್ನು ಹೊಂದಿಸಲು ಉತ್ತಮ ವಿಧಾನದ ಬಗ್ಗೆ ಸಾಕಷ್ಟು ಚರ್ಚೆಗಳಿವೆ. ಕೆಲವೊಮ್ಮೆ ಇದು ವಿಜ್ಞಾನಕ್ಕಿಂತ ಹೆಚ್ಚು ಕಲೆ ಎಂದು ತೋರುತ್ತದೆ. ನಮ್ಮ ವಿಧಾನ ಇಲ್ಲಿದೆ.
ಪಾಡ್ ವಿನಂತಿಗಳು ಪಾಡ್ ಅನ್ನು ಅತ್ಯುತ್ತಮವಾಗಿ ಇರಿಸಲು ಶೆಡ್ಯೂಲರ್ ಬಳಸುವ ಮುಖ್ಯ ಮೌಲ್ಯವಾಗಿದೆ.
ಆಫ್ : ಫಿಲ್ಟರ್ ಹಂತವು ಪಾಡ್ ಅನ್ನು ನಿಗದಿಪಡಿಸಬಹುದಾದ ನೋಡ್‌ಗಳ ಗುಂಪನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಪಾಡ್‌ನಿಂದ ನಿರ್ದಿಷ್ಟ ಸಂಪನ್ಮೂಲ ವಿನಂತಿಗಳನ್ನು ಪೂರೈಸಲು ನೋಡ್ ಸಾಕಷ್ಟು ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹೊಂದಿದೆಯೇ ಎಂದು PodFitsResources ಫಿಲ್ಟರ್ ಪರಿಶೀಲಿಸುತ್ತದೆ.
ನಾವು ಎಷ್ಟು ಸಂಪನ್ಮೂಲಗಳನ್ನು ಅಂದಾಜು ಮಾಡುವ ರೀತಿಯಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್ ವಿನಂತಿಗಳನ್ನು ಬಳಸುತ್ತೇವೆ ವಾಸ್ತವವಾಗಿ ಅಪ್ಲಿಕೇಶನ್ ಸರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಇದು ಅಗತ್ಯವಿದೆ. ಈ ರೀತಿಯಲ್ಲಿ ಶೆಡ್ಯೂಲರ್ ವಾಸ್ತವಿಕವಾಗಿ ನೋಡ್‌ಗಳನ್ನು ಇರಿಸಬಹುದು. ಆರಂಭದಲ್ಲಿ, ನಾವು ಪ್ರತಿ ಪಾಡ್‌ಗೆ ಸಾಕಷ್ಟು ಸಂಪನ್ಮೂಲಗಳನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ವಿನಂತಿಗಳನ್ನು ಅತಿಯಾಗಿ ನಿಗದಿಪಡಿಸಲು ಬಯಸಿದ್ದೇವೆ, ಆದರೆ ವೇಳಾಪಟ್ಟಿಯ ಸಮಯವು ಗಮನಾರ್ಹವಾಗಿ ಹೆಚ್ಚಿರುವುದನ್ನು ನಾವು ಗಮನಿಸಿದ್ದೇವೆ ಮತ್ತು ಕೆಲವು ಪಾಡ್‌ಗಳಿಗೆ ಯಾವುದೇ ಸಂಪನ್ಮೂಲ ವಿನಂತಿಗಳಿಲ್ಲ ಎಂಬಂತೆ ಸಂಪೂರ್ಣವಾಗಿ ನಿಗದಿಪಡಿಸಲಾಗಿಲ್ಲ.
ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಶೆಡ್ಯೂಲರ್ ಆಗಾಗ್ಗೆ ಪಾಡ್‌ಗಳನ್ನು "ಸ್ಕ್ವೀಜ್" ಮಾಡುತ್ತಾನೆ ಮತ್ತು ಅವುಗಳನ್ನು ಮರುಹೊಂದಿಸಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ ಏಕೆಂದರೆ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಎಷ್ಟು ಸಂಪನ್ಮೂಲಗಳು ಬೇಕು ಎಂದು ನಿಯಂತ್ರಣ ಸಮತಲಕ್ಕೆ ತಿಳಿದಿರಲಿಲ್ಲ, ಇದು ವೇಳಾಪಟ್ಟಿ ಅಲ್ಗಾರಿದಮ್‌ನ ಪ್ರಮುಖ ಅಂಶವಾಗಿದೆ.
ಪಾಡ್ ಮಿತಿಗಳು ಪಾಡ್‌ಗೆ ಸ್ಪಷ್ಟ ಮಿತಿಯಾಗಿದೆ. ಕ್ಲಸ್ಟರ್ ಕಂಟೇನರ್‌ಗೆ ನಿಯೋಜಿಸುವ ಗರಿಷ್ಠ ಪ್ರಮಾಣದ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಇದು ಪ್ರತಿನಿಧಿಸುತ್ತದೆ.
ಮತ್ತೆ, ಇಂದ : ಕಂಟೇನರ್ 4 GiB ನ ಮೆಮೊರಿ ಮಿತಿಯನ್ನು ಹೊಂದಿದ್ದರೆ, ನಂತರ kubelet (ಮತ್ತು ಕಂಟೇನರ್ ರನ್ಟೈಮ್) ಅದನ್ನು ಜಾರಿಗೊಳಿಸುತ್ತದೆ. ರನ್ಟೈಮ್ ಕಂಟೇನರ್ ಅನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಸಂಪನ್ಮೂಲ ಮಿತಿಗಿಂತ ಹೆಚ್ಚಿನದನ್ನು ಬಳಸದಂತೆ ತಡೆಯುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಧಾರಕದಲ್ಲಿನ ಪ್ರಕ್ರಿಯೆಯು ಅನುಮತಿಸಲಾದ ಮೆಮೊರಿಯ ಪ್ರಮಾಣಕ್ಕಿಂತ ಹೆಚ್ಚಿನದನ್ನು ಬಳಸಲು ಪ್ರಯತ್ನಿಸಿದಾಗ, ಸಿಸ್ಟಮ್ ಕರ್ನಲ್ "ಮೆಮೊರಿಯಿಂದ ಹೊರಗಿದೆ" (OOM) ದೋಷದೊಂದಿಗೆ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಕೊನೆಗೊಳಿಸುತ್ತದೆ.
ಕಂಟೇನರ್ ಯಾವಾಗಲೂ ಸಂಪನ್ಮೂಲ ವಿನಂತಿಯು ನಿರ್ದಿಷ್ಟಪಡಿಸುವುದಕ್ಕಿಂತ ಹೆಚ್ಚಿನ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಬಳಸಬಹುದು, ಆದರೆ ಅದು ಎಂದಿಗೂ ಮಿತಿಗಿಂತ ಹೆಚ್ಚಿನದನ್ನು ಬಳಸಲಾಗುವುದಿಲ್ಲ. ಈ ಮೌಲ್ಯವನ್ನು ಸರಿಯಾಗಿ ಹೊಂದಿಸುವುದು ಕಷ್ಟ, ಆದರೆ ಇದು ಬಹಳ ಮುಖ್ಯವಾಗಿದೆ.
ತಾತ್ತ್ವಿಕವಾಗಿ, ಸಿಸ್ಟಮ್‌ನಲ್ಲಿನ ಇತರ ಪ್ರಕ್ರಿಯೆಗಳೊಂದಿಗೆ ಮಧ್ಯಪ್ರವೇಶಿಸದೆ ಪ್ರಕ್ರಿಯೆಯ ಜೀವನಚಕ್ರದ ಸಮಯದಲ್ಲಿ ಪಾಡ್‌ನ ಸಂಪನ್ಮೂಲ ಅವಶ್ಯಕತೆಗಳು ಬದಲಾಗಬೇಕೆಂದು ನಾವು ಬಯಸುತ್ತೇವೆ - ಇದು ಮಿತಿಗಳನ್ನು ಹೊಂದಿಸುವ ಉದ್ದೇಶವಾಗಿದೆ.
ದುರದೃಷ್ಟವಶಾತ್, ಯಾವ ಮೌಲ್ಯಗಳನ್ನು ಹೊಂದಿಸಬೇಕು ಎಂಬುದರ ಕುರಿತು ನಾನು ನಿರ್ದಿಷ್ಟ ಸೂಚನೆಗಳನ್ನು ನೀಡಲು ಸಾಧ್ಯವಿಲ್ಲ, ಆದರೆ ನಾವು ಈ ಕೆಳಗಿನ ನಿಯಮಗಳಿಗೆ ಬದ್ಧರಾಗಿದ್ದೇವೆ:
- ಲೋಡ್ ಟೆಸ್ಟಿಂಗ್ ಟೂಲ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು, ನಾವು ಟ್ರಾಫಿಕ್‌ನ ಮೂಲ ಮಟ್ಟವನ್ನು ಅನುಕರಿಸುತ್ತೇವೆ ಮತ್ತು ಪಾಡ್ ಸಂಪನ್ಮೂಲಗಳ (ಮೆಮೊರಿ ಮತ್ತು ಪ್ರೊಸೆಸರ್) ಬಳಕೆಯನ್ನು ಗಮನಿಸುತ್ತೇವೆ.
- ಪಾಡ್ ವಿನಂತಿಗಳನ್ನು ನಿರಂಕುಶವಾಗಿ ಕಡಿಮೆ ಮೌಲ್ಯಕ್ಕೆ ಹೊಂದಿಸಿ (ಸಂಪನ್ಮೂಲ ಮಿತಿ ಸುಮಾರು 5 ಪಟ್ಟು ವಿನಂತಿಗಳ ಮೌಲ್ಯದೊಂದಿಗೆ) ಮತ್ತು ಗಮನಿಸಿ. ವಿನಂತಿಗಳು ತುಂಬಾ ಕಡಿಮೆ ಮಟ್ಟದಲ್ಲಿದ್ದಾಗ, ಪ್ರಕ್ರಿಯೆಯು ಪ್ರಾರಂಭವಾಗುವುದಿಲ್ಲ, ಆಗಾಗ್ಗೆ ರಹಸ್ಯವಾದ ಗೋ ರನ್ಟೈಮ್ ದೋಷಗಳನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ.
ಹೆಚ್ಚಿನ ಸಂಪನ್ಮೂಲ ಮಿತಿಗಳು ವೇಳಾಪಟ್ಟಿಯನ್ನು ಹೆಚ್ಚು ಕಷ್ಟಕರವಾಗಿಸುತ್ತದೆ ಏಕೆಂದರೆ ಪಾಡ್‌ಗೆ ಸಾಕಷ್ಟು ಸಂಪನ್ಮೂಲಗಳು ಲಭ್ಯವಿರುವ ಟಾರ್ಗೆಟ್ ನೋಡ್ ಅಗತ್ಯವಿದೆ ಎಂದು ನಾನು ಗಮನಿಸುತ್ತೇನೆ.
ನೀವು 4 GB ಮೆಮೊರಿಯಂತಹ ಹೆಚ್ಚಿನ ಸಂಪನ್ಮೂಲ ಮಿತಿಯೊಂದಿಗೆ ಹಗುರವಾದ ವೆಬ್ ಸರ್ವರ್ ಅನ್ನು ಹೊಂದಿರುವ ಪರಿಸ್ಥಿತಿಯನ್ನು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ. ಈ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಅಡ್ಡಲಾಗಿ ಸ್ಕೇಲ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ, ಮತ್ತು ಪ್ರತಿ ಹೊಸ ಪಾಡ್ ಕನಿಷ್ಠ 4 GB ಲಭ್ಯವಿರುವ ಮೆಮೊರಿಯೊಂದಿಗೆ ನೋಡ್‌ನಲ್ಲಿ ನಿಗದಿಪಡಿಸಬೇಕಾಗುತ್ತದೆ. ಅಂತಹ ಯಾವುದೇ ನೋಡ್ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದಿದ್ದರೆ, ಈ ಪಾಡ್ ಅನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಕ್ಲಸ್ಟರ್ ಹೊಸ ನೋಡ್ ಅನ್ನು ಪರಿಚಯಿಸಬೇಕು, ಇದು ಸ್ವಲ್ಪ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳಬಹುದು. ವೇಗವಾದ ಮತ್ತು ಮೃದುವಾದ ಸ್ಕೇಲಿಂಗ್ ಅನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಸಂಪನ್ಮೂಲ ವಿನಂತಿಗಳು ಮತ್ತು ಮಿತಿಗಳ ನಡುವಿನ ಕನಿಷ್ಠ ವ್ಯತ್ಯಾಸವನ್ನು ಸಾಧಿಸುವುದು ಮುಖ್ಯವಾಗಿದೆ.
ಹಂತ ಎರಡು: ಲೈವ್‌ನೆಸ್ ಮತ್ತು ರೆಡಿನೆಸ್ ಟೆಸ್ಟ್‌ಗಳನ್ನು ಹೊಂದಿಸಿ
ಇದು ಕುಬರ್ನೆಟ್ಸ್ ಸಮುದಾಯದಲ್ಲಿ ಸಾಮಾನ್ಯವಾಗಿ ಚರ್ಚಿಸಲ್ಪಡುವ ಮತ್ತೊಂದು ಸೂಕ್ಷ್ಮ ವಿಷಯವಾಗಿದೆ. ಲೈವ್‌ನೆಸ್ ಮತ್ತು ರೆಡಿನೆಸ್ ಪರೀಕ್ಷೆಗಳ ಬಗ್ಗೆ ಉತ್ತಮ ತಿಳುವಳಿಕೆಯನ್ನು ಹೊಂದಿರುವುದು ಮುಖ್ಯವಾಗಿದೆ ಏಕೆಂದರೆ ಅವು ಸಾಫ್ಟ್‌ವೇರ್‌ನ ಸ್ಥಿರ ಕಾರ್ಯಾಚರಣೆಗೆ ಕಾರ್ಯವಿಧಾನವನ್ನು ಒದಗಿಸುತ್ತವೆ ಮತ್ತು ಅಲಭ್ಯತೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಸರಿಯಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡದಿದ್ದಲ್ಲಿ ಅವರು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಗಂಭೀರವಾಗಿ ಪರಿಣಾಮ ಬೀರಬಹುದು. ಎರಡೂ ಮಾದರಿಗಳು ಯಾವುವು ಎಂಬುದರ ಸಾರಾಂಶವನ್ನು ಕೆಳಗೆ ನೀಡಲಾಗಿದೆ.
ಜೀವಂತತೆ ಕಂಟೇನರ್ ಚಾಲನೆಯಲ್ಲಿದೆಯೇ ಎಂದು ತೋರಿಸುತ್ತದೆ. ಅದು ವಿಫಲವಾದರೆ, ಕುಬೆಲೆಟ್ ಕಂಟೇನರ್ ಅನ್ನು ಕೊಲ್ಲುತ್ತದೆ ಮತ್ತು ಅದಕ್ಕೆ ಮರುಪ್ರಾರಂಭಿಸುವ ನೀತಿಯನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಲಾಗುತ್ತದೆ. ಧಾರಕವು ಲೈವ್‌ನೆಸ್ ಪ್ರೋಬ್ ಅನ್ನು ಹೊಂದಿಲ್ಲದಿದ್ದರೆ, ಡೀಫಾಲ್ಟ್ ಸ್ಥಿತಿಯು ಯಶಸ್ವಿಯಾಗುತ್ತದೆ - ರಲ್ಲಿ ಹೇಳಿದಂತೆ .
ಲೈವ್‌ನೆಸ್ ಪ್ರೋಬ್‌ಗಳು ಅಗ್ಗವಾಗಿರಬೇಕು, ಅಂದರೆ ಬಹಳಷ್ಟು ಸಂಪನ್ಮೂಲಗಳನ್ನು ಸೇವಿಸಬಾರದು, ಏಕೆಂದರೆ ಅವುಗಳು ಆಗಾಗ್ಗೆ ರನ್ ಆಗುತ್ತವೆ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಚಾಲನೆಯಲ್ಲಿದೆ ಎಂದು ಕುಬರ್ನೆಟ್‌ಗಳಿಗೆ ತಿಳಿಸಬೇಕು.
ನೀವು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ರನ್ ಮಾಡಲು ಆಯ್ಕೆಯನ್ನು ಹೊಂದಿಸಿದರೆ, ಇದು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 1 ವಿನಂತಿಯನ್ನು ಸೇರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಈ ದಟ್ಟಣೆಯನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಹೆಚ್ಚುವರಿ ಸಂಪನ್ಮೂಲಗಳ ಅಗತ್ಯವಿದೆ ಎಂದು ತಿಳಿದಿರಲಿ.
ನಮ್ಮ ಕಂಪನಿಯಲ್ಲಿ, ಡೇಟಾ (ಉದಾಹರಣೆಗೆ, ರಿಮೋಟ್ ಡೇಟಾಬೇಸ್ ಅಥವಾ ಸಂಗ್ರಹದಿಂದ) ಸಂಪೂರ್ಣವಾಗಿ ಲಭ್ಯವಿಲ್ಲದಿದ್ದರೂ ಸಹ, ಲೈವ್‌ನೆಸ್ ಪರೀಕ್ಷೆಗಳು ಅಪ್ಲಿಕೇಶನ್‌ನ ಪ್ರಮುಖ ಅಂಶಗಳನ್ನು ಪರೀಕ್ಷಿಸುತ್ತವೆ.
200 ಪ್ರತಿಕ್ರಿಯೆ ಕೋಡ್ ಅನ್ನು ಸರಳವಾಗಿ ಹಿಂತಿರುಗಿಸುವ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಲ್ಲಿ ನಾವು "ಆರೋಗ್ಯ" ಎಂಡ್‌ಪಾಯಿಂಟ್ ಅನ್ನು ಹೊಂದಿಸಿದ್ದೇವೆ. ಇದು ಪ್ರಕ್ರಿಯೆಯು ಚಾಲನೆಯಲ್ಲಿದೆ ಮತ್ತು ವಿನಂತಿಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಹೊಂದಿದೆ (ಆದರೆ ಇನ್ನೂ ಟ್ರಾಫಿಕ್ ಅಲ್ಲ) ಎಂಬ ಸೂಚಕವಾಗಿದೆ.
ಪ್ರಯತ್ನಿಸಿ ಸಿದ್ಧತೆ ವಿನಂತಿಗಳನ್ನು ಪೂರೈಸಲು ಕಂಟೇನರ್ ಸಿದ್ಧವಾಗಿದೆಯೇ ಎಂದು ಸೂಚಿಸುತ್ತದೆ. ರೆಡಿನೆಸ್ ಪ್ರೋಬ್ ವಿಫಲವಾದಲ್ಲಿ, ಎಂಡ್‌ಪಾಯಿಂಟ್ ನಿಯಂತ್ರಕವು ಪಾಡ್‌ಗೆ ಹೊಂದಿಕೆಯಾಗುವ ಎಲ್ಲಾ ಸೇವೆಗಳ ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗಳಿಂದ ಪಾಡ್‌ನ IP ವಿಳಾಸವನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ. ಇದನ್ನು ಕುಬರ್ನೆಟ್ಸ್ ದಾಖಲೆಯಲ್ಲಿಯೂ ಹೇಳಲಾಗಿದೆ.
ರೆಡಿನೆಸ್ ಪ್ರೋಬ್‌ಗಳು ಹೆಚ್ಚಿನ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಬಳಸುತ್ತವೆ, ಏಕೆಂದರೆ ಅಪ್ಲಿಕೇಶನ್ ವಿನಂತಿಗಳನ್ನು ಸ್ವೀಕರಿಸಲು ಸಿದ್ಧವಾಗಿದೆ ಎಂದು ತೋರಿಸುವ ರೀತಿಯಲ್ಲಿ ಬ್ಯಾಕೆಂಡ್ ಅನ್ನು ಹೊಡೆಯಬೇಕು.
ಡೇಟಾಬೇಸ್ ಅನ್ನು ನೇರವಾಗಿ ಪ್ರವೇಶಿಸಬೇಕೆ ಎಂಬ ಬಗ್ಗೆ ಸಮುದಾಯದಲ್ಲಿ ಸಾಕಷ್ಟು ಚರ್ಚೆಗಳಿವೆ. ಓವರ್ಹೆಡ್ ಅನ್ನು ಪರಿಗಣಿಸಿ (ತಪಾಸಣೆಗಳು ಆಗಾಗ್ಗೆ ಆಗಿರುತ್ತವೆ, ಆದರೆ ಅವುಗಳನ್ನು ನಿಯಂತ್ರಿಸಬಹುದು), ಕೆಲವು ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ, ಡೇಟಾಬೇಸ್‌ನಿಂದ ದಾಖಲೆಗಳನ್ನು ಹಿಂತಿರುಗಿಸಲಾಗಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿದ ನಂತರವೇ ದಟ್ಟಣೆಯನ್ನು ಪೂರೈಸಲು ಸಿದ್ಧತೆಯನ್ನು ಎಣಿಸಲಾಗುತ್ತದೆ ಎಂದು ನಾವು ನಿರ್ಧರಿಸಿದ್ದೇವೆ. ಉತ್ತಮವಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾದ ಸನ್ನದ್ಧತೆಯ ಪ್ರಯೋಗಗಳು ಹೆಚ್ಚಿನ ಮಟ್ಟದ ಲಭ್ಯತೆಯನ್ನು ಖಾತ್ರಿಪಡಿಸಿದವು ಮತ್ತು ನಿಯೋಜನೆಯ ಸಮಯದಲ್ಲಿ ಅಲಭ್ಯತೆಯನ್ನು ತೆಗೆದುಹಾಕಿದವು.
ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನ ಸಿದ್ಧತೆಯನ್ನು ಪರೀಕ್ಷಿಸಲು ಡೇಟಾಬೇಸ್ ಅನ್ನು ಪ್ರಶ್ನಿಸಲು ನೀವು ನಿರ್ಧರಿಸಿದರೆ, ಅದು ಸಾಧ್ಯವಾದಷ್ಟು ಅಗ್ಗವಾಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ. ಈ ಪ್ರಶ್ನೆಯನ್ನು ತೆಗೆದುಕೊಳ್ಳೋಣ:
SELECT small_item FROM table LIMIT 1ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ನಾವು ಈ ಎರಡು ಮೌಲ್ಯಗಳನ್ನು ಹೇಗೆ ಕಾನ್ಫಿಗರ್ ಮಾಡುತ್ತೇವೆ ಎಂಬುದರ ಉದಾಹರಣೆ ಇಲ್ಲಿದೆ:
livenessProbe:
httpGet:
path: /api/liveness
port: http
readinessProbe:
httpGet:
path: /api/readiness
port: http periodSeconds: 2
ನೀವು ಕೆಲವು ಹೆಚ್ಚುವರಿ ಸಂರಚನಾ ಆಯ್ಕೆಗಳನ್ನು ಸೇರಿಸಬಹುದು:
initialDelaySeconds- ಕಂಟೇನರ್ ಉಡಾವಣೆ ಮತ್ತು ಶೋಧಕಗಳ ಉಡಾವಣೆಯ ಪ್ರಾರಂಭದ ನಡುವೆ ಎಷ್ಟು ಸೆಕೆಂಡುಗಳು ಹಾದುಹೋಗುತ್ತವೆ.periodSeconds- ಮಾದರಿ ರನ್ಗಳ ನಡುವೆ ಕಾಯುವ ಮಧ್ಯಂತರ.timeoutSeconds- ಪಾಡ್ ಅನ್ನು ತುರ್ತುಸ್ಥಿತಿ ಎಂದು ಪರಿಗಣಿಸುವ ಸೆಕೆಂಡುಗಳ ಸಂಖ್ಯೆ. ಸಾಮಾನ್ಯ ಸಮಯ ಮೀರಿದೆ.failureThresholdಪುನರಾರಂಭದ ಸಂಕೇತವನ್ನು ಪಾಡ್‌ಗೆ ಕಳುಹಿಸುವ ಮೊದಲು ಪರೀಕ್ಷಾ ವೈಫಲ್ಯಗಳ ಸಂಖ್ಯೆ.successThresholdಪಾಡ್ ಸಿದ್ಧ ಸ್ಥಿತಿಗೆ ಪರಿವರ್ತನೆಯಾಗುವ ಮೊದಲು ಯಶಸ್ವಿ ಪ್ರಯೋಗಗಳ ಸಂಖ್ಯೆ (ಪಾಡ್ ಪ್ರಾರಂಭವಾದಾಗ ಅಥವಾ ಚೇತರಿಸಿಕೊಂಡಾಗ ವೈಫಲ್ಯದ ನಂತರ).
ಹಂತ ಮೂರು: ಪಾಡ್‌ನ ಡೀಫಾಲ್ಟ್ ನೆಟ್‌ವರ್ಕ್ ನೀತಿಗಳನ್ನು ಹೊಂದಿಸುವುದು
ಕುಬರ್ನೆಟ್ಸ್ "ಫ್ಲಾಟ್" ನೆಟ್‌ವರ್ಕ್ ಸ್ಥಳಾಕೃತಿಯನ್ನು ಹೊಂದಿದೆ, ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಎಲ್ಲಾ ಪಾಡ್‌ಗಳು ಪರಸ್ಪರ ನೇರವಾಗಿ ಸಂವಹನ ನಡೆಸುತ್ತವೆ. ಕೆಲವು ಸಂದರ್ಭಗಳಲ್ಲಿ ಇದು ಅಪೇಕ್ಷಣೀಯವಲ್ಲ.
ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿರುವ ಎಲ್ಲಾ ಪಾಡ್‌ಗಳಿಗೆ ದಟ್ಟಣೆಯನ್ನು ಕಳುಹಿಸಲು ಆಕ್ರಮಣಕಾರರು ಒಂದೇ ದುರ್ಬಲ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಬಳಸಬಹುದು ಎಂಬುದು ಸಂಭಾವ್ಯ ಭದ್ರತಾ ಸಮಸ್ಯೆಯಾಗಿದೆ. ಭದ್ರತೆಯ ಅನೇಕ ಕ್ಷೇತ್ರಗಳಂತೆ, ಕನಿಷ್ಠ ಸವಲತ್ತು ಎಂಬ ತತ್ವವು ಇಲ್ಲಿ ಅನ್ವಯಿಸುತ್ತದೆ. ತಾತ್ತ್ವಿಕವಾಗಿ, ನೆಟ್‌ವರ್ಕ್ ನೀತಿಗಳು ಪಾಡ್‌ಗಳ ನಡುವೆ ಯಾವ ಸಂಪರ್ಕಗಳನ್ನು ಅನುಮತಿಸಲಾಗಿದೆ ಮತ್ತು ಯಾವುದು ಅಲ್ಲ ಎಂಬುದನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ತಿಳಿಸಬೇಕು.
ಉದಾಹರಣೆಗೆ, ನಿರ್ದಿಷ್ಟ ನೇಮ್‌ಸ್ಪೇಸ್‌ಗಾಗಿ ಎಲ್ಲಾ ಒಳಬರುವ ದಟ್ಟಣೆಯನ್ನು ನಿರಾಕರಿಸುವ ಸರಳ ನೀತಿಯು ಈ ಕೆಳಗಿನಂತಿದೆ:
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-ingress
spec:
podSelector: {}
policyTypes:
- Ingress
ಈ ಸಂರಚನೆಯ ದೃಶ್ಯೀಕರಣ:
(https://miro.medium.com/max/875/1*-eiVw43azgzYzyN1th7cZg.gif)
ಇನ್ನಷ್ಟು ವಿವರಗಳು .
ಹಂತ ನಾಲ್ಕು: ಹುಕ್ಸ್ ಮತ್ತು ಇನಿಟ್ ಕಂಟೈನರ್‌ಗಳೊಂದಿಗೆ ಕಸ್ಟಮ್ ಬಿಹೇವಿಯರ್
ಡೆವಲಪರ್‌ಗಳಿಗೆ ಡೌನ್‌ಟೈಮ್ ಇಲ್ಲದೆ ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ನಿಯೋಜನೆಗಳನ್ನು ಒದಗಿಸುವುದು ನಮ್ಮ ಮುಖ್ಯ ಗುರಿಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ. ಇದು ಕಷ್ಟಕರವಾಗಿದೆ ಏಕೆಂದರೆ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಮುಚ್ಚಲು ಮತ್ತು ಬಳಸಿದ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಬಿಡುಗಡೆ ಮಾಡಲು ಹಲವು ಆಯ್ಕೆಗಳಿವೆ.
ನಿರ್ದಿಷ್ಟ ತೊಂದರೆಗಳು ಉದ್ಭವಿಸಿದವು . ಈ ಪಾಡ್‌ಗಳನ್ನು ಅನುಕ್ರಮವಾಗಿ ನಿಯೋಜಿಸುವಾಗ, ಯಶಸ್ವಿಯಾಗಿ ಪೂರ್ಣಗೊಳ್ಳುವ ಮೊದಲು ಸಕ್ರಿಯ ಸಂಪರ್ಕಗಳು ಅಡಚಣೆಯಾಗಿರುವುದನ್ನು ನಾವು ಗಮನಿಸಿದ್ದೇವೆ.
ಅಂತರ್ಜಾಲದಲ್ಲಿ ವ್ಯಾಪಕವಾದ ಸಂಶೋಧನೆಯ ನಂತರ, ಕುಬರ್ನೆಟ್ಸ್ ಪಾಡ್ ಅನ್ನು ಮುಚ್ಚುವ ಮೊದಲು Nginx ಸಂಪರ್ಕಗಳು ತಮ್ಮನ್ನು ಖಾಲಿಯಾಗಲು ಕಾಯುವುದಿಲ್ಲ ಎಂದು ಅದು ಬದಲಾಯಿತು. ಪ್ರಿ-ಸ್ಟಾಪ್ ಹುಕ್ ಸಹಾಯದಿಂದ, ನಾವು ಈ ಕೆಳಗಿನ ಕಾರ್ಯವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿದ್ದೇವೆ ಮತ್ತು ಅಲಭ್ಯತೆಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ತೊಡೆದುಹಾಕಿದ್ದೇವೆ:
lifecycle:
preStop:
exec:
command: ["/usr/local/bin/nginx-killer.sh"]
ಆದರೆ nginx-killer.sh:
#!/bin/bash
sleep 3
PID=$(cat /run/nginx.pid)
nginx -s quit
while [ -d /proc/$PID ]; do
echo "Waiting while shutting down nginx..."
sleep 10
done
ಮತ್ತೊಂದು ಅತ್ಯಂತ ಉಪಯುಕ್ತ ಮಾದರಿಯೆಂದರೆ ನಿರ್ದಿಷ್ಟ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಉಡಾವಣೆಯನ್ನು ನಿರ್ವಹಿಸಲು init ಕಂಟೇನರ್‌ಗಳ ಬಳಕೆಯಾಗಿದೆ. ಅಪ್ಲಿಕೇಶನ್ ಪ್ರಾರಂಭವಾಗುವ ಮೊದಲು ರನ್ ಮಾಡಬೇಕಾದ ಸಂಪನ್ಮೂಲ-ತೀವ್ರ ಡೇಟಾಬೇಸ್ ವಲಸೆ ಪ್ರಕ್ರಿಯೆಯನ್ನು ನೀವು ಹೊಂದಿದ್ದರೆ ಇದು ವಿಶೇಷವಾಗಿ ಉಪಯುಕ್ತವಾಗಿದೆ. ಮುಖ್ಯ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಅಂತಹ ಮಿತಿಯನ್ನು ಹೊಂದಿಸದೆಯೇ ನೀವು ಈ ಪ್ರಕ್ರಿಯೆಗೆ ಹೆಚ್ಚಿನ ಸಂಪನ್ಮೂಲ ಮಿತಿಯನ್ನು ಸಹ ನಿರ್ದಿಷ್ಟಪಡಿಸಬಹುದು.
init ಕಂಟೇನರ್‌ನಲ್ಲಿ ರಹಸ್ಯಗಳನ್ನು ಪ್ರವೇಶಿಸುವುದು ಮತ್ತೊಂದು ಸಾಮಾನ್ಯ ಯೋಜನೆಯಾಗಿದೆ, ಇದು ಮುಖ್ಯ ಮಾಡ್ಯೂಲ್‌ಗೆ ಈ ರುಜುವಾತುಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ, ಇದು ಮುಖ್ಯ ಅಪ್ಲಿಕೇಶನ್ ಮಾಡ್ಯೂಲ್‌ನಿಂದ ರಹಸ್ಯಗಳಿಗೆ ಅನಧಿಕೃತ ಪ್ರವೇಶವನ್ನು ತಡೆಯುತ್ತದೆ.
ಎಂದಿನಂತೆ, ದಾಖಲಾತಿಯಿಂದ ಒಂದು ಉಲ್ಲೇಖ: init ಕಂಟೈನರ್‌ಗಳು ಬಳಕೆದಾರ ಕೋಡ್ ಅಥವಾ ಉಪಯುಕ್ತತೆಗಳನ್ನು ಸುರಕ್ಷಿತವಾಗಿ ರನ್ ಮಾಡುತ್ತವೆ ಅದು ಇಲ್ಲದಿದ್ದರೆ ಅಪ್ಲಿಕೇಶನ್‌ನ ಕಂಟೇನರ್ ಚಿತ್ರದ ಸುರಕ್ಷತೆಯನ್ನು ರಾಜಿ ಮಾಡುತ್ತದೆ. ಅನಗತ್ಯ ಪರಿಕರಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸುವ ಮೂಲಕ, ನೀವು ಅಪ್ಲಿಕೇಶನ್‌ನ ಕಂಟೇನರ್ ಚಿತ್ರದ ಆಕ್ರಮಣದ ಮೇಲ್ಮೈಯನ್ನು ಮಿತಿಗೊಳಿಸುತ್ತೀರಿ.
ಹಂತ ಐದು: ಕರ್ನಲ್ ಕಾನ್ಫಿಗರೇಶನ್
ಅಂತಿಮವಾಗಿ, ಹೆಚ್ಚು ಸುಧಾರಿತ ತಂತ್ರದ ಬಗ್ಗೆ ಮಾತನಾಡೋಣ.
ಕುಬರ್ನೆಟ್ಸ್ ಅತ್ಯಂತ ಹೊಂದಿಕೊಳ್ಳುವ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಆಗಿದ್ದು ಅದು ನಿಮಗೆ ಸರಿಹೊಂದುವಂತೆ ಕಂಡರೂ ಕೆಲಸದ ಹೊರೆಗಳನ್ನು ಚಲಾಯಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ. ನಮ್ಮಲ್ಲಿ ಹಲವಾರು ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿವೆ, ಅದು ಅತ್ಯಂತ ಸಂಪನ್ಮೂಲ ತೀವ್ರವಾಗಿರುತ್ತದೆ. ವ್ಯಾಪಕವಾದ ಲೋಡ್ ಪರೀಕ್ಷೆಯನ್ನು ಮಾಡಿದ ನಂತರ, ಡೀಫಾಲ್ಟ್ ಕುಬರ್ನೆಟ್ಸ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳು ಜಾರಿಯಲ್ಲಿರುವಾಗ ನಿರೀಕ್ಷಿತ ಟ್ರಾಫಿಕ್ ಲೋಡ್‌ನೊಂದಿಗೆ ಅಪ್ಲಿಕೇಷನ್‌ಗಳಲ್ಲೊಂದು ಕಷ್ಟಪಡುತ್ತಿದೆ ಎಂದು ನಾವು ಕಂಡುಕೊಂಡಿದ್ದೇವೆ.
ಆದಾಗ್ಯೂ, ನಿರ್ದಿಷ್ಟ ಪಾಡ್‌ಗಾಗಿ ಕರ್ನಲ್ ನಿಯತಾಂಕಗಳನ್ನು ಮಾತ್ರ ಬದಲಾಯಿಸುವ ವಿಶೇಷ ಧಾರಕವನ್ನು ಚಲಾಯಿಸಲು ಕುಬರ್ನೆಟ್ಸ್ ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಗರಿಷ್ಠ ಸಂಖ್ಯೆಯ ತೆರೆದ ಸಂಪರ್ಕಗಳನ್ನು ಬದಲಾಯಿಸಲು ನಾವು ಬಳಸಿದ್ದು ಇಲ್ಲಿದೆ:
initContainers:
- name: sysctl
image: alpine:3.10
securityContext:
privileged: true
command: ['sh', '-c', "sysctl -w net.core.somaxconn=32768"]
ಇದು ಹೆಚ್ಚು ಸುಧಾರಿತ ತಂತ್ರವಾಗಿದ್ದು ಅದು ಸಾಮಾನ್ಯವಾಗಿ ಅಗತ್ಯವಿಲ್ಲ. ಆದರೆ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಭಾರೀ ಹೊರೆಯನ್ನು ನಿಭಾಯಿಸಲು ಹೆಣಗಾಡುತ್ತಿದ್ದರೆ, ನೀವು ಈ ಕೆಲವು ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಟ್ವೀಕ್ ಮಾಡಲು ಪ್ರಯತ್ನಿಸಬಹುದು. ಈ ಪ್ರಕ್ರಿಯೆಯ ಕುರಿತು ಹೆಚ್ಚಿನ ಮಾಹಿತಿ ಮತ್ತು ವಿಭಿನ್ನ ಮೌಲ್ಯಗಳನ್ನು ಹೊಂದಿಸುವುದು - ಯಾವಾಗಲೂ .
ತೀರ್ಮಾನಕ್ಕೆ
ಕುಬರ್ನೆಟ್ಸ್ ಔಟ್-ಆಫ್-ದಿ-ಬಾಕ್ಸ್ ಪರಿಹಾರದಂತೆ ತೋರುತ್ತಿದ್ದರೂ, ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಸರಾಗವಾಗಿ ಚಾಲನೆ ಮಾಡಲು ಕೆಲವು ಪ್ರಮುಖ ಹಂತಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಬೇಕು.
ಕುಬರ್ನೆಟ್ಸ್ಗೆ ವಲಸೆಯ ಉದ್ದಕ್ಕೂ, "ಲೋಡ್ ಟೆಸ್ಟಿಂಗ್ ಸೈಕಲ್" ಅನ್ನು ಅನುಸರಿಸುವುದು ಮುಖ್ಯವಾಗಿದೆ: ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ರನ್ ಮಾಡಿ, ಲೋಡ್ ಅಡಿಯಲ್ಲಿ ಪರೀಕ್ಷಿಸಿ, ಮೆಟ್ರಿಕ್ಸ್ ಮತ್ತು ಸ್ಕೇಲಿಂಗ್ ನಡವಳಿಕೆಯನ್ನು ಗಮನಿಸಿ, ಈ ಡೇಟಾವನ್ನು ಆಧರಿಸಿ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಸರಿಹೊಂದಿಸಿ, ನಂತರ ಈ ಚಕ್ರವನ್ನು ಮತ್ತೆ ಪುನರಾವರ್ತಿಸಿ.
ನಿರೀಕ್ಷಿತ ದಟ್ಟಣೆಯ ಬಗ್ಗೆ ವಾಸ್ತವಿಕವಾಗಿರಿ ಮತ್ತು ಯಾವ ಘಟಕಗಳು ಮೊದಲು ಒಡೆಯುತ್ತವೆ ಎಂಬುದನ್ನು ನೋಡಲು ಅದನ್ನು ಮೀರಿ ಹೋಗಲು ಪ್ರಯತ್ನಿಸಿ. ಈ ಪುನರಾವರ್ತನೆಯ ವಿಧಾನದೊಂದಿಗೆ, ಯಶಸ್ಸನ್ನು ಸಾಧಿಸಲು ಪಟ್ಟಿ ಮಾಡಲಾದ ಕೆಲವು ಶಿಫಾರಸುಗಳು ಮಾತ್ರ ಸಾಕಾಗಬಹುದು. ಅಥವಾ ಇದು ಹೆಚ್ಚು ಆಳವಾದ ಗ್ರಾಹಕೀಕರಣದ ಅಗತ್ಯವಿರಬಹುದು.
ಯಾವಾಗಲೂ ಈ ಪ್ರಶ್ನೆಗಳನ್ನು ನೀವೇ ಕೇಳಿಕೊಳ್ಳಿ:
- ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಎಷ್ಟು ಸಂಪನ್ಮೂಲಗಳನ್ನು ಬಳಸುತ್ತವೆ ಮತ್ತು ಈ ಮೊತ್ತವು ಹೇಗೆ ಬದಲಾಗುತ್ತದೆ?
- ನಿಜವಾದ ಸ್ಕೇಲಿಂಗ್ ಅವಶ್ಯಕತೆಗಳು ಯಾವುವು? ಅಪ್ಲಿಕೇಶನ್ ಸರಾಸರಿ ಎಷ್ಟು ಟ್ರಾಫಿಕ್ ಅನ್ನು ನಿಭಾಯಿಸುತ್ತದೆ? ಗರಿಷ್ಠ ದಟ್ಟಣೆಯ ಬಗ್ಗೆ ಏನು?
- ಎಷ್ಟು ಬಾರಿ ಸೇವೆಯನ್ನು ಸ್ಕೇಲ್ ಔಟ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ? ಟ್ರಾಫಿಕ್ ಅನ್ನು ಸ್ವೀಕರಿಸಲು ಹೊಸ ಪಾಡ್‌ಗಳು ಎಷ್ಟು ಬೇಗನೆ ಕಾರ್ಯನಿರ್ವಹಿಸಬೇಕು?
- ಪಾಡ್‌ಗಳು ಎಷ್ಟು ಆಕರ್ಷಕವಾಗಿ ಸ್ಥಗಿತಗೊಳ್ಳುತ್ತವೆ? ಇದು ಎಲ್ಲಾ ಅಗತ್ಯವೇ? ಅಲಭ್ಯತೆ ಇಲ್ಲದೆ ನಿಯೋಜನೆಯನ್ನು ಸಾಧಿಸಲು ಸಾಧ್ಯವೇ?
- ಭದ್ರತಾ ಅಪಾಯಗಳನ್ನು ಕಡಿಮೆ ಮಾಡುವುದು ಮತ್ತು ಯಾವುದೇ ರಾಜಿಯಾದ ಪಾಡ್‌ಗಳಿಂದ ಹಾನಿಯನ್ನು ಮಿತಿಗೊಳಿಸುವುದು ಹೇಗೆ? ಯಾವುದೇ ಸೇವೆಗಳು ಅವರಿಗೆ ಅಗತ್ಯವಿಲ್ಲದ ಅನುಮತಿಗಳು ಅಥವಾ ಪ್ರವೇಶಗಳನ್ನು ಹೊಂದಿವೆಯೇ?
ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಸಾವಿರಾರು ಸೇವೆಗಳನ್ನು ನಿಯೋಜಿಸಲು ಉತ್ತಮ ಅಭ್ಯಾಸಗಳನ್ನು ಬಳಸಲು ನಿಮಗೆ ಅನುಮತಿಸುವ ನಂಬಲಾಗದ ವೇದಿಕೆಯನ್ನು ಕುಬರ್ನೆಟ್ಸ್ ಒದಗಿಸುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಎಲ್ಲಾ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ವಿಭಿನ್ನವಾಗಿವೆ. ಕೆಲವೊಮ್ಮೆ ಅನುಷ್ಠಾನಕ್ಕೆ ಸ್ವಲ್ಪ ಹೆಚ್ಚು ಕೆಲಸ ಬೇಕಾಗುತ್ತದೆ.
ಅದೃಷ್ಟವಶಾತ್, ಕುಬರ್ನೆಟ್ಸ್ ಎಲ್ಲಾ ತಾಂತ್ರಿಕ ಗುರಿಗಳನ್ನು ಸಾಧಿಸಲು ಅಗತ್ಯವಾದ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ. ಸಂಪನ್ಮೂಲ ವಿನಂತಿಗಳು ಮತ್ತು ಮಿತಿಗಳು, ಲೈವ್‌ನೆಸ್ ಮತ್ತು ರೆಡಿನೆಸ್ ಪ್ರೋಬ್‌ಗಳು, init ಕಂಟೈನರ್‌ಗಳು, ನೆಟ್‌ವರ್ಕ್ ನೀತಿಗಳು ಮತ್ತು ಕಸ್ಟಮ್ ಕರ್ನಲ್ ಟ್ಯೂನಿಂಗ್‌ಗಳ ಸಂಯೋಜನೆಯನ್ನು ಬಳಸುವ ಮೂಲಕ, ನೀವು ದೋಷ ಸಹಿಷ್ಣುತೆ ಮತ್ತು ಕ್ಷಿಪ್ರ ಸ್ಕೇಲೆಬಿಲಿಟಿ ಜೊತೆಗೆ ಹೆಚ್ಚಿನ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸಾಧಿಸಬಹುದು.
ಇನ್ನೇನು ಓದಬೇಕು:
- .
- .
- .
ಮೂಲ: www.habr.com