🥇ಕುಬರ್ನೆಟ್ಸ್ಗೆ ಟಿಂಡರ್ ಪರಿವರ್ತನೆ

ಸೂಚನೆ. ಅನುವಾದ.: ವಿಶ್ವಪ್ರಸಿದ್ಧ ಟಿಂಡರ್ ಸೇವೆಯ ಉದ್ಯೋಗಿಗಳು ಇತ್ತೀಚೆಗೆ ತಮ್ಮ ಮೂಲಸೌಕರ್ಯವನ್ನು ಕುಬರ್ನೆಟ್ಸ್‌ಗೆ ಸ್ಥಳಾಂತರಿಸುವ ಕೆಲವು ತಾಂತ್ರಿಕ ವಿವರಗಳನ್ನು ಹಂಚಿಕೊಂಡಿದ್ದಾರೆ. ಪ್ರಕ್ರಿಯೆಯು ಸುಮಾರು ಎರಡು ವರ್ಷಗಳನ್ನು ತೆಗೆದುಕೊಂಡಿತು ಮತ್ತು 8 ಸಾವಿರ ಕಂಟೇನರ್‌ಗಳಲ್ಲಿ ಹೋಸ್ಟ್ ಮಾಡಲಾದ 200 ಸೇವೆಗಳನ್ನು ಒಳಗೊಂಡಿರುವ K48 ಗಳಲ್ಲಿ ಒಂದು ದೊಡ್ಡ-ಪ್ರಮಾಣದ ವೇದಿಕೆಯನ್ನು ಪ್ರಾರಂಭಿಸಲು ಕಾರಣವಾಯಿತು. ಟಿಂಡರ್ ಎಂಜಿನಿಯರ್‌ಗಳು ಯಾವ ಆಸಕ್ತಿದಾಯಕ ತೊಂದರೆಗಳನ್ನು ಎದುರಿಸಿದರು ಮತ್ತು ಅವರು ಯಾವ ಫಲಿತಾಂಶಗಳನ್ನು ಪಡೆದರು? ಈ ಅನುವಾದವನ್ನು ಓದಿ.

ಯಾಕೆ?

ಸುಮಾರು ಎರಡು ವರ್ಷಗಳ ಹಿಂದೆ, ಟಿಂಡರ್ ತನ್ನ ವೇದಿಕೆಯನ್ನು ಕುಬರ್ನೆಟ್ಸ್ಗೆ ಸ್ಥಳಾಂತರಿಸಲು ನಿರ್ಧರಿಸಿತು. ಕುಬರ್ನೆಟ್ಸ್ ಟಿಂಡರ್ ತಂಡವನ್ನು ಕಂಟೈನರೈಸ್ ಮಾಡಲು ಮತ್ತು ಬದಲಾಯಿಸಲಾಗದ ನಿಯೋಜನೆಯ ಮೂಲಕ ಕನಿಷ್ಠ ಪ್ರಯತ್ನದೊಂದಿಗೆ ಉತ್ಪಾದನೆಗೆ ತೆರಳಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ. (ಮಾರಲಾಗದ ನಿಯೋಜನೆ). ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಜೋಡಣೆ, ಅವುಗಳ ನಿಯೋಜನೆ ಮತ್ತು ಮೂಲಸೌಕರ್ಯವನ್ನು ಕೋಡ್‌ನಿಂದ ಅನನ್ಯವಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾಗುತ್ತದೆ.

ನಾವು ಸ್ಕೇಲೆಬಿಲಿಟಿ ಮತ್ತು ಸ್ಥಿರತೆಯ ಸಮಸ್ಯೆಗೆ ಪರಿಹಾರವನ್ನು ಹುಡುಕುತ್ತಿದ್ದೇವೆ. ಸ್ಕೇಲಿಂಗ್ ನಿರ್ಣಾಯಕವಾದಾಗ, ಹೊಸ EC2 ನಿದರ್ಶನಗಳು ಸ್ಪಿನ್ ಅಪ್ ಆಗಲು ನಾವು ಹಲವು ನಿಮಿಷಗಳ ಕಾಲ ಕಾಯಬೇಕಾಗಿತ್ತು. ಕಂಟೈನರ್‌ಗಳನ್ನು ಪ್ರಾರಂಭಿಸುವ ಮತ್ತು ನಿಮಿಷಗಳ ಬದಲು ಸೆಕೆಂಡುಗಳಲ್ಲಿ ಸಂಚಾರವನ್ನು ಪ್ರಾರಂಭಿಸುವ ಕಲ್ಪನೆಯು ನಮಗೆ ಬಹಳ ಆಕರ್ಷಕವಾಯಿತು.

ಪ್ರಕ್ರಿಯೆಯು ಕಷ್ಟಕರವಾಗಿತ್ತು. 2019 ರ ಆರಂಭದಲ್ಲಿ ನಮ್ಮ ವಲಸೆಯ ಸಮಯದಲ್ಲಿ, ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್ ನಿರ್ಣಾಯಕ ದ್ರವ್ಯರಾಶಿಯನ್ನು ತಲುಪಿತು ಮತ್ತು ಟ್ರಾಫಿಕ್ ವಾಲ್ಯೂಮ್, ಕ್ಲಸ್ಟರ್ ಗಾತ್ರ ಮತ್ತು DNS ಕಾರಣದಿಂದಾಗಿ ನಾವು ವಿವಿಧ ಸಮಸ್ಯೆಗಳನ್ನು ಎದುರಿಸಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ. ದಾರಿಯುದ್ದಕ್ಕೂ, 200 ಸೇವೆಗಳನ್ನು ಸ್ಥಳಾಂತರಿಸಲು ಮತ್ತು 1000 ನೋಡ್‌ಗಳು, 15000 ಪಾಡ್‌ಗಳು ಮತ್ತು 48000 ರನ್ನಿಂಗ್ ಕಂಟೈನರ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿರುವ ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ನಿರ್ವಹಿಸಲು ಸಂಬಂಧಿಸಿದ ಬಹಳಷ್ಟು ಆಸಕ್ತಿದಾಯಕ ಸಮಸ್ಯೆಗಳನ್ನು ನಾವು ಪರಿಹರಿಸಿದ್ದೇವೆ.

ಹೇಗೆ?

ಜನವರಿ 2018 ರಿಂದ, ನಾವು ವಲಸೆಯ ವಿವಿಧ ಹಂತಗಳ ಮೂಲಕ ಹೋಗಿದ್ದೇವೆ. ನಾವು ನಮ್ಮ ಎಲ್ಲಾ ಸೇವೆಗಳನ್ನು ಕಂಟೈನರೈಸ್ ಮಾಡುವ ಮೂಲಕ ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ ಮತ್ತು ಅವುಗಳನ್ನು ಕುಬರ್ನೆಟ್ ಪರೀಕ್ಷಾ ಕ್ಲೌಡ್ ಪರಿಸರಕ್ಕೆ ನಿಯೋಜಿಸುತ್ತೇವೆ. ಅಕ್ಟೋಬರ್‌ನಿಂದ, ನಾವು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಎಲ್ಲಾ ಸೇವೆಗಳನ್ನು ಕ್ರಮಬದ್ಧವಾಗಿ ಕುಬರ್ನೆಟ್ಸ್‌ಗೆ ಸ್ಥಳಾಂತರಿಸಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ. ಮುಂದಿನ ವರ್ಷದ ಮಾರ್ಚ್ ವೇಳೆಗೆ, ನಾವು ವಲಸೆಯನ್ನು ಪೂರ್ಣಗೊಳಿಸಿದ್ದೇವೆ ಮತ್ತು ಈಗ ಟಿಂಡರ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ಪ್ರತ್ಯೇಕವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.

ಕುಬರ್ನೆಟ್ಸ್ಗಾಗಿ ಚಿತ್ರಗಳನ್ನು ನಿರ್ಮಿಸುವುದು

ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿರುವ ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ಗಳಿಗಾಗಿ ನಾವು 30 ಕ್ಕೂ ಹೆಚ್ಚು ಮೂಲ ಕೋಡ್ ರೆಪೊಸಿಟರಿಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಈ ರೆಪೊಸಿಟರಿಗಳಲ್ಲಿನ ಕೋಡ್ ಅನ್ನು ವಿವಿಧ ಭಾಷೆಗಳಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ (ಉದಾಹರಣೆಗೆ, Node.js, Java, Scala, Go) ಒಂದೇ ಭಾಷೆಗೆ ಬಹು ರನ್‌ಟೈಮ್ ಪರಿಸರದೊಂದಿಗೆ.

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

ಚಿತ್ರ 1-1. ಬಿಲ್ಡರ್ ಕಂಟೇನರ್ ಮೂಲಕ ಪ್ರಮಾಣಿತ ನಿರ್ಮಾಣ ಪ್ರಕ್ರಿಯೆ

ರನ್ಟೈಮ್ಗಳ ನಡುವೆ ಗರಿಷ್ಠ ಸ್ಥಿರತೆಯನ್ನು ಸಾಧಿಸಲು (ಚಾಲನೆಯಲ್ಲಿರುವ ಪರಿಸರಗಳು) ಅದೇ ನಿರ್ಮಾಣ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಅಭಿವೃದ್ಧಿ ಮತ್ತು ಪರೀಕ್ಷೆಯ ಸಮಯದಲ್ಲಿ ಬಳಸಲಾಗುತ್ತದೆ. ನಾವು ಬಹಳ ಆಸಕ್ತಿದಾಯಕ ಸವಾಲನ್ನು ಎದುರಿಸಿದ್ದೇವೆ: ಇಡೀ ವೇದಿಕೆಯಾದ್ಯಂತ ನಿರ್ಮಾಣ ಪರಿಸರದ ಸ್ಥಿರತೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ನಾವು ಒಂದು ಮಾರ್ಗವನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಬೇಕಾಗಿದೆ. ಇದನ್ನು ಸಾಧಿಸಲು, ಎಲ್ಲಾ ಅಸೆಂಬ್ಲಿ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ವಿಶೇಷ ಕಂಟೇನರ್ ಒಳಗೆ ನಡೆಸಲಾಗುತ್ತದೆ. ಬಿಲ್ಡರ್.

ಅವರ ಕಂಟೈನರ್ ಅನುಷ್ಠಾನಕ್ಕೆ ಸುಧಾರಿತ ಡಾಕರ್ ತಂತ್ರಗಳ ಅಗತ್ಯವಿತ್ತು. ಬಿಲ್ಡರ್ ಸ್ಥಳೀಯ ಬಳಕೆದಾರ ID ಮತ್ತು ಖಾಸಗಿ ಟಿಂಡರ್ ರೆಪೊಸಿಟರಿಗಳನ್ನು ಪ್ರವೇಶಿಸಲು ಅಗತ್ಯವಿರುವ ರಹಸ್ಯಗಳನ್ನು (SSH ಕೀ, AWS ರುಜುವಾತುಗಳು, ಇತ್ಯಾದಿ) ಆನುವಂಶಿಕವಾಗಿ ಪಡೆಯುತ್ತಾರೆ. ಇದು ನೈಸರ್ಗಿಕವಾಗಿ ನಿರ್ಮಾಣ ಕಲಾಕೃತಿಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಮೂಲಗಳನ್ನು ಹೊಂದಿರುವ ಸ್ಥಳೀಯ ಡೈರೆಕ್ಟರಿಗಳನ್ನು ಆರೋಹಿಸುತ್ತದೆ. ಈ ವಿಧಾನವು ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸುಧಾರಿಸುತ್ತದೆ ಏಕೆಂದರೆ ಇದು ಬಿಲ್ಡರ್ ಕಂಟೇನರ್ ಮತ್ತು ಹೋಸ್ಟ್ ನಡುವೆ ಬಿಲ್ಡ್ ಆರ್ಟಿಫ್ಯಾಕ್ಟ್‌ಗಳನ್ನು ನಕಲಿಸುವ ಅಗತ್ಯವನ್ನು ನಿವಾರಿಸುತ್ತದೆ. ಹೆಚ್ಚುವರಿ ಸಂರಚನೆಯಿಲ್ಲದೆ ಸಂಗ್ರಹಿಸಲಾದ ನಿರ್ಮಾಣ ಕಲಾಕೃತಿಗಳನ್ನು ಮರುಬಳಕೆ ಮಾಡಬಹುದು.

ಕೆಲವು ಸೇವೆಗಳಿಗಾಗಿ, ಸಂಕಲನ ಪರಿಸರವನ್ನು ರನ್‌ಟೈಮ್ ಪರಿಸರಕ್ಕೆ ಮ್ಯಾಪ್ ಮಾಡಲು ನಾವು ಇನ್ನೊಂದು ಕಂಟೇನರ್ ಅನ್ನು ರಚಿಸಬೇಕಾಗಿತ್ತು (ಉದಾಹರಣೆಗೆ, Node.js bcrypt ಲೈಬ್ರರಿಯು ಅನುಸ್ಥಾಪನೆಯ ಸಮಯದಲ್ಲಿ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್-ನಿರ್ದಿಷ್ಟ ಬೈನರಿ ಕಲಾಕೃತಿಗಳನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ). ಸಂಕಲನ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ, ಸೇವೆಗಳ ನಡುವೆ ಅವಶ್ಯಕತೆಗಳು ಬದಲಾಗಬಹುದು ಮತ್ತು ಅಂತಿಮ ಡಾಕರ್‌ಫೈಲ್ ಅನ್ನು ಹಾರಾಡುತ್ತ ಸಂಕಲಿಸಲಾಗುತ್ತದೆ.

ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಮತ್ತು ವಲಸೆ

ಕ್ಲಸ್ಟರ್ ಗಾತ್ರ ನಿರ್ವಹಣೆ

ನಾವು ಬಳಸಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ kube-aws Amazon EC2 ನಿದರ್ಶನಗಳಲ್ಲಿ ಸ್ವಯಂಚಾಲಿತ ಕ್ಲಸ್ಟರ್ ನಿಯೋಜನೆಗಾಗಿ. ಅತ್ಯಂತ ಆರಂಭದಲ್ಲಿ, ಎಲ್ಲವೂ ನೋಡ್ಗಳ ಒಂದು ಸಾಮಾನ್ಯ ಪೂಲ್ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತವೆ. ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಬಳಸಿಕೊಳ್ಳಲು ಗಾತ್ರ ಮತ್ತು ನಿದರ್ಶನದ ಪ್ರಕಾರದ ಮೂಲಕ ಕೆಲಸದ ಹೊರೆಗಳನ್ನು ಬೇರ್ಪಡಿಸುವ ಅಗತ್ಯವನ್ನು ನಾವು ತ್ವರಿತವಾಗಿ ಅರಿತುಕೊಂಡಿದ್ದೇವೆ. ಹಲವಾರು ಲೋಡ್ ಮಾಡಲಾದ ಮಲ್ಟಿ-ಥ್ರೆಡ್ ಪಾಡ್‌ಗಳನ್ನು ಚಲಾಯಿಸುವುದು ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಏಕ-ಥ್ರೆಡ್ ಪಾಡ್‌ಗಳೊಂದಿಗೆ ಅವುಗಳ ಸಹಬಾಳ್ವೆಗಿಂತ ಕಾರ್ಯಕ್ಷಮತೆಯ ವಿಷಯದಲ್ಲಿ ಹೆಚ್ಚು ಊಹಿಸಬಹುದಾದಂತಿದೆ ಎಂಬುದು ತರ್ಕವಾಗಿದೆ.

ಕೊನೆಯಲ್ಲಿ ನಾವು ನೆಲೆಸಿದ್ದೇವೆ:

m5.4x ದೊಡ್ಡದು - ಮೇಲ್ವಿಚಾರಣೆಗಾಗಿ (ಪ್ರಮೀತಿಯಸ್);
c5.4x ದೊಡ್ಡದು - Node.js ಕೆಲಸದ ಹೊರೆಗಾಗಿ (ಏಕ-ಥ್ರೆಡ್ ಕೆಲಸದ ಹೊರೆ);
c5.2x ದೊಡ್ಡದು - ಜಾವಾ ಮತ್ತು ಗೋ (ಮಲ್ಟಿಥ್ರೆಡ್ ಕೆಲಸದ ಹೊರೆ);
c5.4x ದೊಡ್ಡದು - ನಿಯಂತ್ರಣ ಫಲಕಕ್ಕಾಗಿ (3 ನೋಡ್ಗಳು).

ವಲಸೆ

ಹಳೆಯ ಮೂಲಸೌಕರ್ಯದಿಂದ ಕುಬರ್ನೆಟ್ಸ್‌ಗೆ ವಲಸೆ ಹೋಗುವ ಪೂರ್ವಸಿದ್ಧತಾ ಹಂತಗಳಲ್ಲಿ ಒಂದಾದ ಸೇವೆಗಳ ನಡುವಿನ ನೇರ ಸಂವಹನವನ್ನು ಹೊಸ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್‌ಗಳಿಗೆ (ಎಲಾಸ್ಟಿಕ್ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್‌ಗಳು (ELB) ಮರುನಿರ್ದೇಶಿಸುವುದು. ಅವುಗಳನ್ನು ವರ್ಚುವಲ್ ಪ್ರೈವೇಟ್ ಕ್ಲೌಡ್‌ನ (VPC) ನಿರ್ದಿಷ್ಟ ಸಬ್‌ನೆಟ್‌ನಲ್ಲಿ ರಚಿಸಲಾಗಿದೆ. ಈ ಸಬ್‌ನೆಟ್ ಅನ್ನು ಕುಬರ್ನೆಟ್ಸ್ VPC ಗೆ ಸಂಪರ್ಕಿಸಲಾಗಿದೆ. ಇದು ಸೇವಾ ಅವಲಂಬನೆಗಳ ನಿರ್ದಿಷ್ಟ ಕ್ರಮವನ್ನು ಪರಿಗಣಿಸದೆ ಕ್ರಮೇಣ ಮಾಡ್ಯೂಲ್‌ಗಳನ್ನು ಸ್ಥಳಾಂತರಿಸಲು ನಮಗೆ ಅವಕಾಶ ಮಾಡಿಕೊಟ್ಟಿತು.

ಪ್ರತಿ ಹೊಸ ELB ಅನ್ನು ಸೂಚಿಸುವ CNAME ಗಳನ್ನು ಹೊಂದಿರುವ DNS ದಾಖಲೆಗಳ ತೂಕದ ಸೆಟ್‌ಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಈ ಅಂತಿಮ ಬಿಂದುಗಳನ್ನು ರಚಿಸಲಾಗಿದೆ. ಬದಲಾಯಿಸಲು, ನಾವು 0 ತೂಕದೊಂದಿಗೆ ಕುಬರ್ನೆಟ್ಸ್ ಸೇವೆಯ ಹೊಸ ELB ಗೆ ಹೊಸ ನಮೂದನ್ನು ಸೇರಿಸಿದ್ದೇವೆ. ನಂತರ ನಾವು ಪ್ರವೇಶದ ಸಮಯವನ್ನು (TTL) 0 ಗೆ ಹೊಂದಿಸಿದ್ದೇವೆ. ಇದರ ನಂತರ, ಹಳೆಯ ಮತ್ತು ಹೊಸ ತೂಕಗಳು ನಿಧಾನವಾಗಿ ಸರಿಹೊಂದಿಸಲಾಗಿದೆ, ಮತ್ತು ಅಂತಿಮವಾಗಿ 100% ಲೋಡ್ ಅನ್ನು ಹೊಸ ಸರ್ವರ್‌ಗೆ ಕಳುಹಿಸಲಾಗಿದೆ. ಸ್ವಿಚಿಂಗ್ ಪೂರ್ಣಗೊಂಡ ನಂತರ, TTL ಮೌಲ್ಯವು ಹೆಚ್ಚು ಸಮರ್ಪಕ ಮಟ್ಟಕ್ಕೆ ಮರಳಿತು.

ನಾವು ಹೊಂದಿದ್ದ ಜಾವಾ ಮಾಡ್ಯೂಲ್‌ಗಳು ಕಡಿಮೆ TTL DNS ಅನ್ನು ನಿಭಾಯಿಸಬಲ್ಲವು, ಆದರೆ ನೋಡ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ. ಇಂಜಿನಿಯರ್‌ಗಳಲ್ಲಿ ಒಬ್ಬರು ಕನೆಕ್ಷನ್ ಪೂಲ್ ಕೋಡ್‌ನ ಭಾಗವನ್ನು ಪುನಃ ಬರೆದರು ಮತ್ತು ಪ್ರತಿ 60 ಸೆಕೆಂಡ್‌ಗಳಿಗೆ ಪೂಲ್‌ಗಳನ್ನು ನವೀಕರಿಸುವ ಮ್ಯಾನೇಜರ್‌ನಲ್ಲಿ ಸುತ್ತಿದರು. ಆಯ್ಕೆಮಾಡಿದ ವಿಧಾನವು ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಿತು ಮತ್ತು ಯಾವುದೇ ಗಮನಾರ್ಹವಾದ ಕಾರ್ಯಕ್ಷಮತೆಯ ಅವನತಿಯಿಲ್ಲದೆ.

ಪಾಠಗಳು

ನೆಟ್ವರ್ಕ್ ಫ್ಯಾಬ್ರಿಕ್ನ ಮಿತಿಗಳು

ಜನವರಿ 8, 2019 ರ ಮುಂಜಾನೆ, ಟಿಂಡರ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಅನಿರೀಕ್ಷಿತವಾಗಿ ಅಪ್ಪಳಿಸಿತು. ಆ ದಿನ ಬೆಳಿಗ್ಗೆ ಪ್ಲ್ಯಾಟ್‌ಫಾರ್ಮ್ ಲೇಟೆನ್ಸಿಯಲ್ಲಿ ಸಂಬಂಧವಿಲ್ಲದ ಹೆಚ್ಚಳಕ್ಕೆ ಪ್ರತಿಕ್ರಿಯೆಯಾಗಿ, ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಪಾಡ್‌ಗಳು ಮತ್ತು ನೋಡ್‌ಗಳ ಸಂಖ್ಯೆ ಹೆಚ್ಚಾಯಿತು. ಇದು ನಮ್ಮ ಎಲ್ಲಾ ನೋಡ್‌ಗಳಲ್ಲಿ ARP ಸಂಗ್ರಹವು ಖಾಲಿಯಾಗಲು ಕಾರಣವಾಯಿತು.

ARP ಸಂಗ್ರಹಕ್ಕೆ ಸಂಬಂಧಿಸಿದ ಮೂರು ಲಿನಕ್ಸ್ ಆಯ್ಕೆಗಳಿವೆ:

(ಮೂಲ)

gc_thresh3 - ಇದು ಕಠಿಣ ಮಿತಿಯಾಗಿದೆ. ಲಾಗ್‌ನಲ್ಲಿ "ನೆರೆಯ ಟೇಬಲ್ ಓವರ್‌ಫ್ಲೋ" ನಮೂದುಗಳ ಗೋಚರಿಸುವಿಕೆಯು ಸಿಂಕ್ರೊನಸ್ ಕಸ ಸಂಗ್ರಹಣೆ (GC) ನಂತರವೂ, ನೆರೆಯ ನಮೂದನ್ನು ಸಂಗ್ರಹಿಸಲು ARP ಸಂಗ್ರಹದಲ್ಲಿ ಸಾಕಷ್ಟು ಸ್ಥಳಾವಕಾಶವಿಲ್ಲ ಎಂದು ಅರ್ಥ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಕರ್ನಲ್ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ತಿರಸ್ಕರಿಸುತ್ತದೆ.

ನಾವು ಬಳಸುತ್ತೇವೆ ಫ್ಲಾನೆಲ್ ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ನೆಟ್ವರ್ಕ್ ಫ್ಯಾಬ್ರಿಕ್ ಆಗಿ. ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು VXLAN ಮೂಲಕ ರವಾನಿಸಲಾಗುತ್ತದೆ. VXLAN ಎನ್ನುವುದು L2 ನೆಟ್‌ವರ್ಕ್‌ನ ಮೇಲ್ಭಾಗದಲ್ಲಿ ಬೆಳೆದ L3 ಸುರಂಗವಾಗಿದೆ. ತಂತ್ರಜ್ಞಾನವು MAC-in-UDP (MAC ಅಡ್ರೆಸ್-ಇನ್-ಯೂಸರ್ ಡೇಟಾಗ್ರಾಮ್ ಪ್ರೋಟೋಕಾಲ್) ಎನ್‌ಕ್ಯಾಪ್ಸುಲೇಶನ್ ಅನ್ನು ಬಳಸುತ್ತದೆ ಮತ್ತು ಲೇಯರ್ 2 ನೆಟ್‌ವರ್ಕ್ ವಿಭಾಗಗಳ ವಿಸ್ತರಣೆಯನ್ನು ಅನುಮತಿಸುತ್ತದೆ. ಭೌತಿಕ ಡೇಟಾ ಸೆಂಟರ್ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿನ ಸಾರಿಗೆ ಪ್ರೋಟೋಕಾಲ್ IP ಜೊತೆಗೆ UDP ಆಗಿದೆ.

ಚಿತ್ರ 2-1. ಫ್ಲಾನೆಲ್ ರೇಖಾಚಿತ್ರ (ಮೂಲ)

ಚಿತ್ರ 2-2. VXLAN ಪ್ಯಾಕೇಜ್ (ಮೂಲ)

ಪ್ರತಿ ಕುಬರ್ನೆಟ್ಸ್ ವರ್ಕರ್ ನೋಡ್ ದೊಡ್ಡದಾದ /24 ಬ್ಲಾಕ್‌ನಿಂದ /9 ಮಾಸ್ಕ್‌ನೊಂದಿಗೆ ವರ್ಚುವಲ್ ಅಡ್ರೆಸ್ ಸ್ಪೇಸ್ ಅನ್ನು ನಿಯೋಜಿಸುತ್ತದೆ. ಪ್ರತಿ ನೋಡ್‌ಗೆ ಇದು ಅರ್ಥ ರೂಟಿಂಗ್ ಟೇಬಲ್‌ನಲ್ಲಿ ಒಂದು ನಮೂದು, ARP ಕೋಷ್ಟಕದಲ್ಲಿ ಒಂದು ನಮೂದು (ಫ್ಲಾನೆಲ್.1 ಇಂಟರ್ಫೇಸ್‌ನಲ್ಲಿ), ಮತ್ತು ಸ್ವಿಚಿಂಗ್ ಟೇಬಲ್‌ನಲ್ಲಿ ಒಂದು ನಮೂದು (FDB). ಮೊದಲ ಬಾರಿಗೆ ವರ್ಕರ್ ನೋಡ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಿದಾಗ ಅಥವಾ ಪ್ರತಿ ಬಾರಿ ಹೊಸ ನೋಡ್ ಪತ್ತೆಯಾದಾಗ ಅವುಗಳನ್ನು ಸೇರಿಸಲಾಗುತ್ತದೆ.

ಹೆಚ್ಚುವರಿಯಾಗಿ, ನೋಡ್-ಪಾಡ್ (ಅಥವಾ ಪಾಡ್-ಪಾಡ್) ಸಂವಹನವು ಅಂತಿಮವಾಗಿ ಇಂಟರ್ಫೇಸ್ ಮೂಲಕ ಹೋಗುತ್ತದೆ eth0 (ಮೇಲಿನ ಫ್ಲಾನ್ನೆಲ್ ರೇಖಾಚಿತ್ರದಲ್ಲಿ ತೋರಿಸಿರುವಂತೆ). ಇದು ಪ್ರತಿ ಅನುಗುಣವಾದ ಮೂಲ ಮತ್ತು ಗಮ್ಯಸ್ಥಾನ ಹೋಸ್ಟ್‌ಗೆ ARP ಕೋಷ್ಟಕದಲ್ಲಿ ಹೆಚ್ಚುವರಿ ನಮೂದುಗೆ ಕಾರಣವಾಗುತ್ತದೆ.

ನಮ್ಮ ಪರಿಸರದಲ್ಲಿ, ಈ ರೀತಿಯ ಸಂವಹನವು ತುಂಬಾ ಸಾಮಾನ್ಯವಾಗಿದೆ. ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿನ ಸೇವಾ ವಸ್ತುಗಳಿಗಾಗಿ, ELB ಅನ್ನು ರಚಿಸಲಾಗಿದೆ ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್ ಪ್ರತಿ ನೋಡ್ ಅನ್ನು ELB ನೊಂದಿಗೆ ನೋಂದಾಯಿಸುತ್ತದೆ. ELB ಗೆ ಪಾಡ್‌ಗಳ ಬಗ್ಗೆ ಏನೂ ತಿಳಿದಿಲ್ಲ ಮತ್ತು ಆಯ್ದ ನೋಡ್ ಪ್ಯಾಕೆಟ್‌ನ ಅಂತಿಮ ತಾಣವಾಗಿರುವುದಿಲ್ಲ. ಅಂಶವೆಂದರೆ ನೋಡ್ ELB ಯಿಂದ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಸ್ವೀಕರಿಸಿದಾಗ, ಅದು ನಿಯಮಗಳನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಎಂದು ಪರಿಗಣಿಸುತ್ತದೆ. iptables ನಿರ್ದಿಷ್ಟ ಸೇವೆಗಾಗಿ ಮತ್ತು ಯಾದೃಚ್ಛಿಕವಾಗಿ ಮತ್ತೊಂದು ನೋಡ್‌ನಲ್ಲಿ ಪಾಡ್ ಅನ್ನು ಆಯ್ಕೆಮಾಡುತ್ತದೆ.

ವೈಫಲ್ಯದ ಸಮಯದಲ್ಲಿ, ಕ್ಲಸ್ಟರ್ನಲ್ಲಿ 605 ನೋಡ್ಗಳು ಇದ್ದವು. ಮೇಲೆ ತಿಳಿಸಿದ ಕಾರಣಗಳಿಗಾಗಿ, ಪ್ರಾಮುಖ್ಯತೆಯನ್ನು ಜಯಿಸಲು ಇದು ಸಾಕಾಗಿತ್ತು gc_thresh3, ಇದು ಡೀಫಾಲ್ಟ್ ಆಗಿದೆ. ಇದು ಸಂಭವಿಸಿದಾಗ, ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಕೈಬಿಡಲು ಪ್ರಾರಂಭಿಸುವುದು ಮಾತ್ರವಲ್ಲ, ARP ಟೇಬಲ್‌ನಿಂದ /24 ಮುಖವಾಡದೊಂದಿಗೆ ಸಂಪೂರ್ಣ Flannel ವರ್ಚುವಲ್ ವಿಳಾಸ ಸ್ಥಳವು ಕಣ್ಮರೆಯಾಗುತ್ತದೆ. ನೋಡ್-ಪಾಡ್ ಸಂವಹನ ಮತ್ತು DNS ಪ್ರಶ್ನೆಗಳಿಗೆ ಅಡ್ಡಿಪಡಿಸಲಾಗಿದೆ (DNS ಅನ್ನು ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಹೋಸ್ಟ್ ಮಾಡಲಾಗಿದೆ; ವಿವರಗಳಿಗಾಗಿ ಈ ಲೇಖನದಲ್ಲಿ ನಂತರ ಓದಿ).

ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು, ನೀವು ಮೌಲ್ಯಗಳನ್ನು ಹೆಚ್ಚಿಸಬೇಕಾಗಿದೆ gc_thresh1, gc_thresh2 и gc_thresh3 ಮತ್ತು ಕಾಣೆಯಾದ ನೆಟ್‌ವರ್ಕ್‌ಗಳನ್ನು ಮರು-ನೋಂದಣಿ ಮಾಡಲು Flannel ಅನ್ನು ಮರುಪ್ರಾರಂಭಿಸಿ.

ಅನಿರೀಕ್ಷಿತ DNS ಸ್ಕೇಲಿಂಗ್

ವಲಸೆ ಪ್ರಕ್ರಿಯೆಯ ಸಮಯದಲ್ಲಿ, ನಾವು ಟ್ರಾಫಿಕ್ ಅನ್ನು ನಿರ್ವಹಿಸಲು DNS ಅನ್ನು ಸಕ್ರಿಯವಾಗಿ ಬಳಸಿದ್ದೇವೆ ಮತ್ತು ಹಳೆಯ ಮೂಲಸೌಕರ್ಯದಿಂದ ಕುಬರ್ನೆಟ್ಸ್‌ಗೆ ಸೇವೆಗಳನ್ನು ಕ್ರಮೇಣ ವರ್ಗಾಯಿಸುತ್ತೇವೆ. ರೂಟ್ 53 ನಲ್ಲಿ ಸಂಬಂಧಿತ ರೆಕಾರ್ಡ್‌ಸೆಟ್‌ಗಳಿಗಾಗಿ ನಾವು ತುಲನಾತ್ಮಕವಾಗಿ ಕಡಿಮೆ ಟಿಟಿಎಲ್ ಮೌಲ್ಯಗಳನ್ನು ಹೊಂದಿಸಿದ್ದೇವೆ. ಹಳೆಯ ಮೂಲಸೌಕರ್ಯವು EC2 ನಿದರ್ಶನಗಳಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿರುವಾಗ, ನಮ್ಮ ಪರಿಹಾರಕ ಕಾನ್ಫಿಗರೇಶನ್ Amazon DNS ಅನ್ನು ಸೂಚಿಸಿತು. ನಾವು ಇದನ್ನು ಲಘುವಾಗಿ ಪರಿಗಣಿಸಿದ್ದೇವೆ ಮತ್ತು ನಮ್ಮ ಸೇವೆಗಳು ಮತ್ತು Amazon ಸೇವೆಗಳ ಮೇಲೆ (ಡೈನಮೊಡಿಬಿಯಂತಹ) ಕಡಿಮೆ ಟಿಟಿಎಲ್‌ನ ಪ್ರಭಾವವು ಹೆಚ್ಚಾಗಿ ಗಮನಿಸಲಿಲ್ಲ.

ನಾವು ಸೇವೆಗಳನ್ನು ಕುಬರ್ನೆಟ್ಸ್‌ಗೆ ಸ್ಥಳಾಂತರಿಸಿದಾಗ, DNS ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 250 ಸಾವಿರ ವಿನಂತಿಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತಿದೆ ಎಂದು ನಾವು ಕಂಡುಕೊಂಡಿದ್ದೇವೆ. ಪರಿಣಾಮವಾಗಿ, ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಡಿಎನ್‌ಎಸ್ ಪ್ರಶ್ನೆಗಳಿಗೆ ನಿರಂತರ ಮತ್ತು ಗಂಭೀರ ಸಮಯಾವಧಿಯನ್ನು ಅನುಭವಿಸಲು ಪ್ರಾರಂಭಿಸಿದವು. DNS ಪೂರೈಕೆದಾರರನ್ನು ಅತ್ಯುತ್ತಮವಾಗಿಸಲು ಮತ್ತು CoreDNS ಗೆ ಬದಲಾಯಿಸಲು ನಂಬಲಾಗದ ಪ್ರಯತ್ನಗಳ ಹೊರತಾಗಿಯೂ ಇದು ಸಂಭವಿಸಿತು (ಇದು ಗರಿಷ್ಠ ಲೋಡ್‌ನಲ್ಲಿ 1000 ಕೋರ್‌ಗಳಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿರುವ 120 ಪಾಡ್‌ಗಳನ್ನು ತಲುಪಿತು).

ಇತರ ಸಂಭವನೀಯ ಕಾರಣಗಳು ಮತ್ತು ಪರಿಹಾರಗಳನ್ನು ಸಂಶೋಧಿಸುವಾಗ, ನಾವು ಕಂಡುಹಿಡಿದಿದ್ದೇವೆ ಲೇಖನ, ಪ್ಯಾಕೆಟ್ ಫಿಲ್ಟರಿಂಗ್ ಚೌಕಟ್ಟಿನ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವ ಓಟದ ಪರಿಸ್ಥಿತಿಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ ನೆಟ್ಫಿಲ್ಟರ್ Linux ನಲ್ಲಿ. ಹೆಚ್ಚುತ್ತಿರುವ ಕೌಂಟರ್ ಜೊತೆಗೆ ನಾವು ಗಮನಿಸಿದ ಸಮಯ ಮೀರಿದೆ insert_failed Flannel ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ಲೇಖನದ ಸಂಶೋಧನೆಗಳೊಂದಿಗೆ ಸ್ಥಿರವಾಗಿದೆ.

ಸಮಸ್ಯೆಯು ಮೂಲ ಮತ್ತು ಡೆಸ್ಟಿನೇಶನ್ ನೆಟ್‌ವರ್ಕ್ ವಿಳಾಸ ಅನುವಾದ (SNAT ಮತ್ತು DNAT) ಹಂತದಲ್ಲಿ ಸಂಭವಿಸುತ್ತದೆ ಮತ್ತು ನಂತರದ ಕೋಷ್ಟಕಕ್ಕೆ ಪ್ರವೇಶಿಸುತ್ತದೆ ಸಂಪರ್ಕ. ಆಂತರಿಕವಾಗಿ ಚರ್ಚಿಸಿದ ಮತ್ತು ಸಮುದಾಯದಿಂದ ಸೂಚಿಸಲಾದ ಒಂದು ಪರಿಹಾರವೆಂದರೆ DNS ಅನ್ನು ವರ್ಕರ್ ನೋಡ್‌ಗೆ ಸರಿಸುವುದಾಗಿದೆ. ಈ ವಿಷಯದಲ್ಲಿ:

SNAT ಅಗತ್ಯವಿಲ್ಲ ಏಕೆಂದರೆ ದಟ್ಟಣೆಯು ನೋಡ್ ಒಳಗೆ ಇರುತ್ತದೆ. ಇದು ಇಂಟರ್ಫೇಸ್ ಮೂಲಕ ರೂಟ್ ಮಾಡಬೇಕಾಗಿಲ್ಲ eth0.
ಡಿಎನ್‌ಎಟಿ ಅಗತ್ಯವಿಲ್ಲ ಏಕೆಂದರೆ ಗಮ್ಯಸ್ಥಾನ ಐಪಿ ನೋಡ್‌ಗೆ ಸ್ಥಳೀಯವಾಗಿದೆ ಮತ್ತು ನಿಯಮಗಳ ಪ್ರಕಾರ ಯಾದೃಚ್ಛಿಕವಾಗಿ ಆಯ್ಕೆಮಾಡಿದ ಪಾಡ್ ಅಲ್ಲ iptables.

ನಾವು ಈ ವಿಧಾನವನ್ನು ಅನುಸರಿಸಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ. CoreDNS ಅನ್ನು ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ಡೀಮನ್‌ಸೆಟ್ ಆಗಿ ನಿಯೋಜಿಸಲಾಗಿದೆ ಮತ್ತು ನಾವು ಸ್ಥಳೀಯ ನೋಡ್ DNS ಸರ್ವರ್ ಅನ್ನು ಅಳವಡಿಸಿದ್ದೇವೆ resolutionv.conf ಧ್ವಜವನ್ನು ಹೊಂದಿಸುವ ಮೂಲಕ ಪ್ರತಿ ಪಾಡ್ --ಕ್ಲಸ್ಟರ್-ಡಿಎನ್‌ಎಸ್ ತಂಡಗಳು ಕುಬ್ಲೆಟ್ . ಈ ಪರಿಹಾರವು DNS ಸಮಯ ಮೀರುವಿಕೆಗಳಿಗೆ ಪರಿಣಾಮಕಾರಿಯಾಗಿದೆ.

ಆದಾಗ್ಯೂ, ನಾವು ಇನ್ನೂ ಪ್ಯಾಕೆಟ್ ನಷ್ಟ ಮತ್ತು ಕೌಂಟರ್‌ನಲ್ಲಿ ಹೆಚ್ಚಳವನ್ನು ನೋಡಿದ್ದೇವೆ insert_failed ಫ್ಲಾನೆಲ್ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ. ಪರಿಹಾರವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿದ ನಂತರ ಇದು ಮುಂದುವರೆಯಿತು ಏಕೆಂದರೆ ನಾವು DNS ಸಂಚಾರಕ್ಕಾಗಿ ಮಾತ್ರ SNAT ಮತ್ತು/ಅಥವಾ DNAT ಅನ್ನು ತೆಗೆದುಹಾಕಲು ಸಾಧ್ಯವಾಯಿತು. ಇತರ ರೀತಿಯ ಸಂಚಾರಕ್ಕಾಗಿ ರೇಸ್ ಪರಿಸ್ಥಿತಿಗಳನ್ನು ಸಂರಕ್ಷಿಸಲಾಗಿದೆ. ಅದೃಷ್ಟವಶಾತ್, ನಮ್ಮ ಹೆಚ್ಚಿನ ಪ್ಯಾಕೆಟ್‌ಗಳು TCP ಆಗಿದ್ದು, ಸಮಸ್ಯೆ ಉಂಟಾದರೆ ಅವುಗಳನ್ನು ಸರಳವಾಗಿ ಮರುಪ್ರಸಾರ ಮಾಡಲಾಗುತ್ತದೆ. ಎಲ್ಲಾ ರೀತಿಯ ಟ್ರಾಫಿಕ್‌ಗೆ ಸೂಕ್ತ ಪರಿಹಾರವನ್ನು ಕಂಡುಹಿಡಿಯಲು ನಾವು ಇನ್ನೂ ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದೇವೆ.

ಉತ್ತಮ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸಿಂಗ್‌ಗಾಗಿ ದೂತರನ್ನು ಬಳಸುವುದು

ನಾವು ಬ್ಯಾಕೆಂಡ್ ಸೇವೆಗಳನ್ನು ಕುಬರ್ನೆಟ್ಸ್‌ಗೆ ಸ್ಥಳಾಂತರಿಸಿದಂತೆ, ನಾವು ಪಾಡ್‌ಗಳ ನಡುವೆ ಅಸಮತೋಲಿತ ಹೊರೆಯಿಂದ ಬಳಲುತ್ತಿದ್ದೇವೆ. HTTP Keepalive ಪ್ರತಿ ನಿಯೋಜನೆಯ ಮೊದಲ ಸಿದ್ಧ ಪಾಡ್‌ಗಳಲ್ಲಿ ELB ಸಂಪರ್ಕಗಳನ್ನು ಸ್ಥಗಿತಗೊಳಿಸುವಂತೆ ಮಾಡಿದೆ ಎಂದು ನಾವು ಕಂಡುಕೊಂಡಿದ್ದೇವೆ. ಹೀಗಾಗಿ, ಹೆಚ್ಚಿನ ದಟ್ಟಣೆಯು ಲಭ್ಯವಿರುವ ಪಾಡ್‌ಗಳ ಸಣ್ಣ ಶೇಕಡಾವಾರು ಮೂಲಕ ಸಾಗಿತು. ನಾವು ಪರೀಕ್ಷಿಸಿದ ಮೊದಲ ಪರಿಹಾರವೆಂದರೆ ಕೆಟ್ಟ ಸನ್ನಿವೇಶಗಳಿಗಾಗಿ ಹೊಸ ನಿಯೋಜನೆಗಳಲ್ಲಿ MaxSurge ಅನ್ನು 100% ಗೆ ಹೊಂದಿಸುವುದು. ದೊಡ್ಡ ನಿಯೋಜನೆಗಳ ವಿಷಯದಲ್ಲಿ ಪರಿಣಾಮವು ಅತ್ಯಲ್ಪ ಮತ್ತು ರಾಜಿಯಾಗದಂತಾಯಿತು.

ನಾವು ಬಳಸಿದ ಮತ್ತೊಂದು ಪರಿಹಾರವೆಂದರೆ ನಿರ್ಣಾಯಕ ಸೇವೆಗಳಿಗೆ ಸಂಪನ್ಮೂಲ ವಿನಂತಿಗಳನ್ನು ಕೃತಕವಾಗಿ ಹೆಚ್ಚಿಸುವುದು. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಇತರ ಭಾರೀ ಬೀಜಕೋಶಗಳಿಗೆ ಹೋಲಿಸಿದರೆ ಸಮೀಪದಲ್ಲಿ ಇರಿಸಲಾದ ಬೀಜಕೋಶಗಳು ಕುಶಲತೆಗೆ ಹೆಚ್ಚಿನ ಸ್ಥಳವನ್ನು ಹೊಂದಿರುತ್ತವೆ. ಇದು ದೀರ್ಘಾವಧಿಯಲ್ಲಿ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ ಏಕೆಂದರೆ ಅದು ಸಂಪನ್ಮೂಲಗಳ ವ್ಯರ್ಥವಾಗುತ್ತದೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ನಮ್ಮ ನೋಡ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಏಕ-ಥ್ರೆಡ್ ಆಗಿದ್ದು, ಅದರ ಪ್ರಕಾರ, ಒಂದು ಕೋರ್ ಅನ್ನು ಮಾತ್ರ ಬಳಸಬಹುದಾಗಿದೆ. ಉತ್ತಮ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸಿಂಗ್ ಅನ್ನು ಬಳಸುವುದು ಮಾತ್ರ ನಿಜವಾದ ಪರಿಹಾರವಾಗಿದೆ.

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

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

ಸೇವೆಯ ಮುಂಭಾಗ-ರಾಯಭಾರಿಗಳು ನಂತರ ಒಂದು ಅಪ್‌ಸ್ಟ್ರೀಮ್ ಕ್ಲಸ್ಟರ್ ಮತ್ತು ಮಾರ್ಗದೊಂದಿಗೆ ಈ ಸೇವೆಯ ಅನ್ವೇಷಣೆ ಕಾರ್ಯವಿಧಾನವನ್ನು ಬಳಸಿದರು. ನಾವು ಸಾಕಷ್ಟು ಸಮಯಾವಧಿಗಳನ್ನು ಹೊಂದಿಸಿದ್ದೇವೆ, ಎಲ್ಲಾ ಸರ್ಕ್ಯೂಟ್ ಬ್ರೇಕರ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಹೆಚ್ಚಿಸಿದ್ದೇವೆ ಮತ್ತು ಏಕ ವೈಫಲ್ಯಗಳಿಗೆ ಸಹಾಯ ಮಾಡಲು ಮತ್ತು ಸುಗಮ ನಿಯೋಜನೆಗಳನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಕನಿಷ್ಠ ಮರುಪ್ರಯತ್ನ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಸೇರಿಸಿದ್ದೇವೆ. ಈ ಪ್ರತಿಯೊಂದು ಸೇವಾ ಮುಂಭಾಗ-ರಾಯಭಾರಿಗಳ ಮುಂದೆ ನಾವು TCP ELB ಅನ್ನು ಇರಿಸಿದ್ದೇವೆ. ನಮ್ಮ ಮುಖ್ಯ ಪ್ರಾಕ್ಸಿ ಲೇಯರ್‌ನಿಂದ ಕೀಪಲೈವ್ ಕೆಲವು ಎನ್ವಾಯ್ ಪಾಡ್‌ಗಳಲ್ಲಿ ಅಂಟಿಕೊಂಡಿದ್ದರೂ ಸಹ, ಅವರು ಇನ್ನೂ ಉತ್ತಮವಾಗಿ ಲೋಡ್ ಅನ್ನು ನಿಭಾಯಿಸಲು ಸಮರ್ಥರಾಗಿದ್ದಾರೆ ಮತ್ತು ಬ್ಯಾಕೆಂಡ್‌ನಲ್ಲಿ ಕನಿಷ್ಠ_ರಿಕ್ವೆಸ್ಟ್ ಮೂಲಕ ಬ್ಯಾಲೆನ್ಸ್ ಮಾಡಲು ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ.

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

ವಿಶಿಷ್ಟವಾದ ಪ್ರಮೀತಿಯಸ್ ಸ್ಥಾಪನೆಗೆ ನಾವು ಸುಲಭವಾಗಿ ಸಂಯೋಜಿಸಲು ಸಾಧ್ಯವಾದ ವಿವರವಾದ ಮೆಟ್ರಿಕ್‌ಗಳ ಕಾರಣದಿಂದಾಗಿ ನಾವು ಬೇಗನೆ ಚಲಿಸಲು ಸಾಧ್ಯವಾದ ಕಾರಣಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ. ನಾವು ಕಾನ್ಫಿಗರೇಶನ್ ಪ್ಯಾರಾಮೀಟರ್‌ಗಳನ್ನು ಸರಿಹೊಂದಿಸುವಾಗ ಮತ್ತು ಟ್ರಾಫಿಕ್ ಅನ್ನು ಮರುಹಂಚಿಕೆ ಮಾಡುವಾಗ ನಿಖರವಾಗಿ ಏನಾಗುತ್ತಿದೆ ಎಂಬುದನ್ನು ನೋಡಲು ಇದು ನಮಗೆ ಅವಕಾಶ ಮಾಡಿಕೊಟ್ಟಿತು.

ಫಲಿತಾಂಶಗಳು ತಕ್ಷಣವೇ ಮತ್ತು ಸ್ಪಷ್ಟವಾಗಿವೆ. ನಾವು ಅತ್ಯಂತ ಅಸಮತೋಲಿತ ಸೇವೆಗಳೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ ಮತ್ತು ಈ ಸಮಯದಲ್ಲಿ ಇದು ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿರುವ 12 ಪ್ರಮುಖ ಸೇವೆಗಳ ಮುಂದೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಈ ವರ್ಷ ನಾವು ಹೆಚ್ಚು ಸುಧಾರಿತ ಸೇವೆಯ ಅನ್ವೇಷಣೆ, ಸರ್ಕ್ಯೂಟ್ ಬ್ರೇಕಿಂಗ್, ಔಟ್‌ಲಿಯರ್ ಡಿಟೆಕ್ಷನ್, ದರ ಸೀಮಿತಗೊಳಿಸುವಿಕೆ ಮತ್ತು ಪತ್ತೆಹಚ್ಚುವಿಕೆಯೊಂದಿಗೆ ಪೂರ್ಣ ಸೇವಾ ಜಾಲರಿಗೆ ಪರಿವರ್ತನೆಯನ್ನು ಯೋಜಿಸುತ್ತಿದ್ದೇವೆ.

ಚಿತ್ರ 3-1. ರಾಯಭಾರಿಗೆ ಪರಿವರ್ತನೆಯ ಸಮಯದಲ್ಲಿ ಒಂದು ಸೇವೆಯ CPU ಒಮ್ಮುಖ

ಅಂತಿಮ ಫಲಿತಾಂಶ

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

ಹಳೆಯ ಮೂಲಸೌಕರ್ಯದಲ್ಲಿ ಹೆಚ್ಚುವರಿ ಸಾಮರ್ಥ್ಯದ ಅಗತ್ಯವು ಉದ್ಭವಿಸಿದಾಗ, ಹೊಸ EC2 ನಿದರ್ಶನಗಳನ್ನು ಪ್ರಾರಂಭಿಸಲು ನಾವು ಹಲವಾರು ನಿಮಿಷಗಳ ಕಾಲ ಕಾಯಬೇಕಾಯಿತು. ಈಗ ಕಂಟೈನರ್‌ಗಳು ಚಾಲನೆಯಾಗಲು ಪ್ರಾರಂಭಿಸುತ್ತವೆ ಮತ್ತು ನಿಮಿಷಗಳ ಬದಲು ಸೆಕೆಂಡುಗಳಲ್ಲಿ ಸಂಚಾರವನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತವೆ. ಒಂದೇ EC2 ನಿದರ್ಶನದಲ್ಲಿ ಬಹು ಧಾರಕಗಳನ್ನು ನಿಗದಿಪಡಿಸುವುದು ಸುಧಾರಿತ ಸಮತಲ ಸಾಂದ್ರತೆಯನ್ನು ಒದಗಿಸುತ್ತದೆ. ಪರಿಣಾಮವಾಗಿ, ಕಳೆದ ವರ್ಷಕ್ಕೆ ಹೋಲಿಸಿದರೆ 2019 ರಲ್ಲಿ EC2 ವೆಚ್ಚದಲ್ಲಿ ಗಮನಾರ್ಹವಾದ ಕಡಿತವನ್ನು ನಾವು ಮುನ್ಸೂಚಿಸಿದ್ದೇವೆ.

ವಲಸೆಯು ಸುಮಾರು ಎರಡು ವರ್ಷಗಳನ್ನು ತೆಗೆದುಕೊಂಡಿತು, ಆದರೆ ನಾವು ಅದನ್ನು ಮಾರ್ಚ್ 2019 ರಲ್ಲಿ ಪೂರ್ಣಗೊಳಿಸಿದ್ದೇವೆ. ಪ್ರಸ್ತುತ, ಟಿಂಡರ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ 200 ಸೇವೆಗಳು, 1000 ನೋಡ್‌ಗಳು, 15 ಪಾಡ್‌ಗಳು ಮತ್ತು 000 ರನ್ನಿಂಗ್ ಕಂಟೈನರ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿರುವ ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಪ್ರತ್ಯೇಕವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಮೂಲಸೌಕರ್ಯವು ಇನ್ನು ಮುಂದೆ ಕಾರ್ಯಾಚರಣೆ ತಂಡಗಳ ಏಕೈಕ ಡೊಮೇನ್ ಆಗಿರುವುದಿಲ್ಲ. ನಮ್ಮ ಎಲ್ಲಾ ಇಂಜಿನಿಯರ್‌ಗಳು ಈ ಜವಾಬ್ದಾರಿಯನ್ನು ಹಂಚಿಕೊಳ್ಳುತ್ತಾರೆ ಮತ್ತು ಕೋಡ್ ಬಳಸಿ ತಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಿರ್ಮಿಸುವ ಮತ್ತು ನಿಯೋಜಿಸುವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ನಿಯಂತ್ರಿಸುತ್ತಾರೆ.

ಅನುವಾದಕರಿಂದ PS

ನಮ್ಮ ಬ್ಲಾಗ್‌ನಲ್ಲಿ ಲೇಖನಗಳ ಸರಣಿಯನ್ನು ಸಹ ಓದಿ:

ಮೂಲ: www.habr.com

ಕುಬರ್ನೆಟ್ಸ್ಗೆ ಟಿಂಡರ್ ಪರಿವರ್ತನೆ