ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ದೀರ್ಘಾವಧಿಯ ಸಂಪರ್ಕಗಳನ್ನು ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸಿಂಗ್ ಮತ್ತು ಸ್ಕೇಲಿಂಗ್

ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸಿಂಗ್ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ದೀರ್ಘಾವಧಿಯ ಸಂಪರ್ಕಗಳನ್ನು ಸ್ಕೇಲಿಂಗ್ ಮಾಡುವಾಗ ಏನಾಗುತ್ತದೆ ಮತ್ತು ನೀವು HTTP/2, gRPC, RSockets, AMQP, ಅಥವಾ ಇತರ ದೀರ್ಘಾವಧಿಯ ಪ್ರೋಟೋಕಾಲ್‌ಗಳನ್ನು ಬಳಸಿದರೆ ಕ್ಲೈಂಟ್-ಸೈಡ್ ಬ್ಯಾಲೆನ್ಸಿಂಗ್ ಅನ್ನು ಏಕೆ ಪರಿಗಣಿಸಬೇಕು ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಈ ಲೇಖನವು ನಿಮಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ. . 

ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಹೇಗೆ ಮರುಹಂಚಿಕೆ ಮಾಡಲಾಗುತ್ತದೆ ಎಂಬುದರ ಕುರಿತು ಸ್ವಲ್ಪ 

ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಿಯೋಜಿಸಲು ಕುಬರ್ನೆಟ್ಸ್ ಎರಡು ಅನುಕೂಲಕರ ಅಮೂರ್ತತೆಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ: ಸೇವೆಗಳು ಮತ್ತು ನಿಯೋಜನೆಗಳು.

ಯಾವುದೇ ಸಮಯದಲ್ಲಿ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನ ಎಷ್ಟು ಮತ್ತು ಎಷ್ಟು ನಕಲುಗಳು ರನ್ ಆಗಬೇಕು ಎಂಬುದನ್ನು ನಿಯೋಜನೆಗಳು ವಿವರಿಸುತ್ತವೆ. ಪ್ರತಿ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಪಾಡ್ ಆಗಿ ನಿಯೋಜಿಸಲಾಗಿದೆ ಮತ್ತು IP ವಿಳಾಸವನ್ನು ನಿಗದಿಪಡಿಸಲಾಗಿದೆ.

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

ಅದು ಹೇಗಿದೆ ಎಂದು ನೋಡೋಣ.

1. ಕೆಳಗಿನ ರೇಖಾಚಿತ್ರದಲ್ಲಿ ನೀವು ಒಂದೇ ಅಪ್ಲಿಕೇಶನ್‌ನ ಮೂರು ನಿದರ್ಶನಗಳನ್ನು ಮತ್ತು ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಅನ್ನು ನೋಡಬಹುದು:

   

2. ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಅನ್ನು ಸೇವೆ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ ಮತ್ತು IP ವಿಳಾಸವನ್ನು ನಿಗದಿಪಡಿಸಲಾಗಿದೆ. ಯಾವುದೇ ಒಳಬರುವ ವಿನಂತಿಯನ್ನು ಪಾಡ್‌ಗಳಲ್ಲಿ ಒಂದಕ್ಕೆ ಮರುನಿರ್ದೇಶಿಸಲಾಗುತ್ತದೆ:

   

3. ನಿಯೋಜನೆಯ ಸನ್ನಿವೇಶವು ಅಪ್ಲಿಕೇಶನ್‌ನ ನಿದರ್ಶನಗಳ ಸಂಖ್ಯೆಯನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. ನೀವು ಎಂದಿಗೂ ನೇರವಾಗಿ ವಿಸ್ತರಿಸಬೇಕಾಗಿಲ್ಲ:

   

4. ಪ್ರತಿಯೊಂದು ಪಾಡ್‌ಗೆ ತನ್ನದೇ ಆದ IP ವಿಳಾಸವನ್ನು ನಿಗದಿಪಡಿಸಲಾಗಿದೆ:

   

ಸೇವೆಗಳನ್ನು IP ವಿಳಾಸಗಳ ಸಂಗ್ರಹವಾಗಿ ಪರಿಗಣಿಸಲು ಇದು ಉಪಯುಕ್ತವಾಗಿದೆ. ಪ್ರತಿ ಬಾರಿ ನೀವು ಸೇವೆಯನ್ನು ಪ್ರವೇಶಿಸಿದಾಗ, IP ವಿಳಾಸಗಳಲ್ಲಿ ಒಂದನ್ನು ಪಟ್ಟಿಯಿಂದ ಆಯ್ಕೆಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು ಗಮ್ಯಸ್ಥಾನದ ವಿಳಾಸವಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ.

ಇದು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ.

1. ಸೇವೆಗೆ ಕರ್ಲ್ 10.96.45.152 ವಿನಂತಿಯನ್ನು ಸ್ವೀಕರಿಸಲಾಗಿದೆ:

   

2. ಸೇವೆಯು ಮೂರು ಪಾಡ್ ವಿಳಾಸಗಳಲ್ಲಿ ಒಂದನ್ನು ತನ್ನ ಗಮ್ಯಸ್ಥಾನವಾಗಿ ಆಯ್ಕೆಮಾಡುತ್ತದೆ:

   

3. ಟ್ರಾಫಿಕ್ ಅನ್ನು ನಿರ್ದಿಷ್ಟ ಪಾಡ್‌ಗೆ ಮರುನಿರ್ದೇಶಿಸಲಾಗಿದೆ:

   

ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಮುಂಭಾಗ ಮತ್ತು ಬ್ಯಾಕೆಂಡ್ ಅನ್ನು ಹೊಂದಿದ್ದರೆ, ನೀವು ಪ್ರತಿಯೊಂದಕ್ಕೂ ಸೇವೆ ಮತ್ತು ನಿಯೋಜನೆ ಎರಡನ್ನೂ ಹೊಂದಿರುತ್ತೀರಿ.

ಮುಂಭಾಗವು ಬ್ಯಾಕೆಂಡ್‌ಗೆ ವಿನಂತಿಯನ್ನು ಮಾಡಿದಾಗ, ಬ್ಯಾಕೆಂಡ್ ಎಷ್ಟು ಪಾಡ್‌ಗಳನ್ನು ಪೂರೈಸುತ್ತದೆ ಎಂಬುದನ್ನು ನಿಖರವಾಗಿ ತಿಳಿಯಬೇಕಾಗಿಲ್ಲ: ಒಂದು, ಹತ್ತು ಅಥವಾ ನೂರು ಇರಬಹುದು.

ಅಲ್ಲದೆ, ಬ್ಯಾಕೆಂಡ್‌ಗೆ ಸೇವೆ ಸಲ್ಲಿಸುವ ಪಾಡ್‌ಗಳ ವಿಳಾಸಗಳ ಬಗ್ಗೆ ಮುಂಭಾಗಕ್ಕೆ ಏನೂ ತಿಳಿದಿಲ್ಲ.

ಮುಂಭಾಗವು ಬ್ಯಾಕೆಂಡ್‌ಗೆ ವಿನಂತಿಯನ್ನು ಮಾಡಿದಾಗ, ಅದು ಬ್ಯಾಕೆಂಡ್ ಸೇವೆಯ IP ವಿಳಾಸವನ್ನು ಬಳಸುತ್ತದೆ, ಅದು ಬದಲಾಗುವುದಿಲ್ಲ.

ಇದು ಹೇಗೆ ಕಾಣುತ್ತದೆ.

1. 1 ಅಡಿಯಲ್ಲಿ ಆಂತರಿಕ ಬ್ಯಾಕೆಂಡ್ ಘಟಕವನ್ನು ವಿನಂತಿಸುತ್ತದೆ. ಬ್ಯಾಕೆಂಡ್‌ಗಾಗಿ ನಿರ್ದಿಷ್ಟ ಒಂದನ್ನು ಆಯ್ಕೆ ಮಾಡುವ ಬದಲು, ಇದು ಸೇವೆಗೆ ವಿನಂತಿಯನ್ನು ಮಾಡುತ್ತದೆ:

   

2. ಸೇವೆಯು ಬ್ಯಾಕೆಂಡ್ ಪಾಡ್‌ಗಳಲ್ಲಿ ಒಂದನ್ನು ಗಮ್ಯಸ್ಥಾನದ ವಿಳಾಸವಾಗಿ ಆಯ್ಕೆಮಾಡುತ್ತದೆ:

   

3. ಟ್ರಾಫಿಕ್ ಪಾಡ್ 1 ರಿಂದ ಪಾಡ್ 5 ಕ್ಕೆ ಹೋಗುತ್ತದೆ, ಸೇವೆಯಿಂದ ಆಯ್ಕೆ ಮಾಡಲಾಗಿದೆ:

   

4. 1 ವರ್ಷದೊಳಗಿನವರಿಗೆ ಸೇವೆಯ ಹಿಂದೆ 5 ಅಡಿಯಲ್ಲಿ ಎಷ್ಟು ಪಾಡ್‌ಗಳನ್ನು ಮರೆಮಾಡಲಾಗಿದೆ ಎಂದು ನಿಖರವಾಗಿ ತಿಳಿದಿಲ್ಲ:

   

ಆದರೆ ಸೇವೆಯು ವಿನಂತಿಗಳನ್ನು ಹೇಗೆ ನಿಖರವಾಗಿ ವಿತರಿಸುತ್ತದೆ? ರೌಂಡ್-ರಾಬಿನ್ ಬ್ಯಾಲೆನ್ಸಿಂಗ್ ಅನ್ನು ಬಳಸಿದಂತೆ ತೋರುತ್ತಿದೆಯೇ? ಅದನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡೋಣ. 

ಕುಬರ್ನೆಟ್ ಸೇವೆಗಳಲ್ಲಿ ಸಮತೋಲನ

ಕುಬರ್ನೆಟ್ ಸೇವೆಗಳು ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ. IP ವಿಳಾಸ ಮತ್ತು ಪೋರ್ಟ್ ಅನ್ನು ನಿಯೋಜಿಸಲಾದ ಸೇವೆಗೆ ಯಾವುದೇ ಪ್ರಕ್ರಿಯೆ ಇಲ್ಲ.

ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿನ ಯಾವುದೇ ನೋಡ್‌ಗೆ ಲಾಗ್ ಇನ್ ಮಾಡುವ ಮೂಲಕ ಮತ್ತು netstat -ntlp ಆಜ್ಞೆಯನ್ನು ಚಲಾಯಿಸುವ ಮೂಲಕ ನೀವು ಇದನ್ನು ಪರಿಶೀಲಿಸಬಹುದು.

ಸೇವೆಗೆ ನಿಯೋಜಿಸಲಾದ IP ವಿಳಾಸವನ್ನು ಹುಡುಕಲು ಸಹ ನಿಮಗೆ ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ.

ಸೇವೆಯ IP ವಿಳಾಸವು ನಿಯಂತ್ರಣ ಪದರದಲ್ಲಿ, ನಿಯಂತ್ರಕದಲ್ಲಿ ಮತ್ತು ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ದಾಖಲಿಸಲಾಗಿದೆ - ಇತ್ಯಾದಿ. ಅದೇ ವಿಳಾಸವನ್ನು ಮತ್ತೊಂದು ಘಟಕವು ಬಳಸುತ್ತದೆ - kube-proxy.
Kube-proxy ಎಲ್ಲಾ ಸೇವೆಗಳಿಗೆ IP ವಿಳಾಸಗಳ ಪಟ್ಟಿಯನ್ನು ಪಡೆಯುತ್ತದೆ ಮತ್ತು ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿನ ಪ್ರತಿ ನೋಡ್‌ನಲ್ಲಿ iptables ನಿಯಮಗಳ ಗುಂಪನ್ನು ರಚಿಸುತ್ತದೆ.

ಈ ನಿಯಮಗಳು ಹೇಳುತ್ತವೆ: "ನಾವು ಸೇವೆಯ IP ವಿಳಾಸವನ್ನು ನೋಡಿದರೆ, ನಾವು ವಿನಂತಿಯ ಗಮ್ಯಸ್ಥಾನದ ವಿಳಾಸವನ್ನು ಮಾರ್ಪಡಿಸಬೇಕು ಮತ್ತು ಅದನ್ನು ಪಾಡ್‌ಗಳಲ್ಲಿ ಒಂದಕ್ಕೆ ಕಳುಹಿಸಬೇಕು."

ಸೇವೆಯ IP ವಿಳಾಸವನ್ನು ಪ್ರವೇಶ ಬಿಂದುವಾಗಿ ಮಾತ್ರ ಬಳಸಲಾಗುತ್ತದೆ ಮತ್ತು ಆ IP ವಿಳಾಸ ಮತ್ತು ಪೋರ್ಟ್ ಅನ್ನು ಕೇಳುವ ಯಾವುದೇ ಪ್ರಕ್ರಿಯೆಯಿಂದ ಸೇವೆ ಸಲ್ಲಿಸುವುದಿಲ್ಲ.

ಇದನ್ನು ನೋಡೋಣ. 

1. ಮೂರು ನೋಡ್ಗಳ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಪರಿಗಣಿಸಿ. ಪ್ರತಿಯೊಂದು ನೋಡ್ ಪಾಡ್‌ಗಳನ್ನು ಹೊಂದಿದೆ:

   

2. ಬೀಜ್ ಪೇಂಟ್ ಮಾಡಿದ ಟೈಡ್ ಪಾಡ್ಸ್ ಸೇವೆಯ ಭಾಗವಾಗಿದೆ. ಸೇವೆಯು ಪ್ರಕ್ರಿಯೆಯಾಗಿ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದ ಕಾರಣ, ಅದನ್ನು ಬೂದು ಬಣ್ಣದಲ್ಲಿ ತೋರಿಸಲಾಗಿದೆ:

   

3. ಮೊದಲ ಪಾಡ್ ಸೇವೆಯನ್ನು ವಿನಂತಿಸುತ್ತದೆ ಮತ್ತು ಸಂಬಂಧಿತ ಪಾಡ್‌ಗಳಲ್ಲಿ ಒಂದಕ್ಕೆ ಹೋಗಬೇಕು:

   

4. ಆದರೆ ಸೇವೆ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ, ಪ್ರಕ್ರಿಯೆಯು ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ. ಇದು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ?

   

5. ವಿನಂತಿಯು ನೋಡ್‌ನಿಂದ ಹೊರಡುವ ಮೊದಲು, ಅದು iptables ನಿಯಮಗಳ ಮೂಲಕ ಹೋಗುತ್ತದೆ:

   

6. iptables ನಿಯಮಗಳು ಸೇವೆಯು ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ ಎಂದು ತಿಳಿದಿದೆ ಮತ್ತು ಅದರ IP ವಿಳಾಸವನ್ನು ಆ ಸೇವೆಗೆ ಸಂಬಂಧಿಸಿದ ಪಾಡ್‌ಗಳ IP ವಿಳಾಸಗಳಲ್ಲಿ ಒಂದಕ್ಕೆ ಬದಲಾಯಿಸುತ್ತದೆ:

   

7. ವಿನಂತಿಯು ಮಾನ್ಯವಾದ IP ವಿಳಾಸವನ್ನು ಗಮ್ಯಸ್ಥಾನದ ವಿಳಾಸವಾಗಿ ಸ್ವೀಕರಿಸುತ್ತದೆ ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾಗುತ್ತದೆ:

   

8. ನೆಟ್‌ವರ್ಕ್ ಟೋಪೋಲಜಿಯನ್ನು ಅವಲಂಬಿಸಿ, ವಿನಂತಿಯು ಅಂತಿಮವಾಗಿ ಪಾಡ್‌ಗೆ ತಲುಪುತ್ತದೆ:

   

iptables ಸಮತೋಲನವನ್ನು ಲೋಡ್ ಮಾಡಬಹುದೇ?

ಇಲ್ಲ, iptables ಅನ್ನು ಫಿಲ್ಟರಿಂಗ್‌ಗಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ ಮತ್ತು ಸಮತೋಲನಕ್ಕಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿಲ್ಲ.

ಆದಾಗ್ಯೂ, ಕೆಲಸ ಮಾಡುವ ನಿಯಮಗಳ ಗುಂಪನ್ನು ಬರೆಯಲು ಸಾಧ್ಯವಿದೆ ಹುಸಿ ಬ್ಯಾಲೆನ್ಸರ್.

ಮತ್ತು ಇದು ನಿಖರವಾಗಿ ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಅಳವಡಿಸಲಾಗಿದೆ.

ನೀವು ಮೂರು ಪಾಡ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ಕ್ಯೂಬ್-ಪ್ರಾಕ್ಸಿ ಈ ಕೆಳಗಿನ ನಿಯಮಗಳನ್ನು ಬರೆಯುತ್ತದೆ:

1. 33% ಸಂಭವನೀಯತೆಯೊಂದಿಗೆ ಮೊದಲ ಉಪವನ್ನು ಆಯ್ಕೆಮಾಡಿ, ಇಲ್ಲದಿದ್ದರೆ ಮುಂದಿನ ನಿಯಮಕ್ಕೆ ಹೋಗಿ.
2. 50% ಸಂಭವನೀಯತೆಯೊಂದಿಗೆ ಎರಡನೆಯದನ್ನು ಆರಿಸಿ, ಇಲ್ಲದಿದ್ದರೆ ಮುಂದಿನ ನಿಯಮಕ್ಕೆ ಹೋಗಿ.
3. ಅಡಿಯಲ್ಲಿ ಮೂರನೆಯದನ್ನು ಆಯ್ಕೆಮಾಡಿ.

ಈ ವ್ಯವಸ್ಥೆಯು ಪ್ರತಿ ಪಾಡ್ ಅನ್ನು 33% ಸಂಭವನೀಯತೆಯೊಂದಿಗೆ ಆಯ್ಕೆಮಾಡುತ್ತದೆ.

ಮತ್ತು ಪಾಡ್ 2 ರ ನಂತರ ಪಾಡ್ 1 ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಲಾಗುತ್ತದೆ ಎಂಬುದಕ್ಕೆ ಯಾವುದೇ ಗ್ಯಾರಂಟಿ ಇಲ್ಲ.

ಹೇಳಿಕೆಯನ್ನು: iptables ಯಾದೃಚ್ಛಿಕ ವಿತರಣೆಯೊಂದಿಗೆ ಸಂಖ್ಯಾಶಾಸ್ತ್ರೀಯ ಮಾಡ್ಯೂಲ್ ಅನ್ನು ಬಳಸುತ್ತದೆ. ಹೀಗಾಗಿ, ಬ್ಯಾಲೆನ್ಸಿಂಗ್ ಅಲ್ಗಾರಿದಮ್ ಯಾದೃಚ್ಛಿಕ ಆಯ್ಕೆಯನ್ನು ಆಧರಿಸಿದೆ.

ಸೇವೆಗಳು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ ಎಂಬುದನ್ನು ಈಗ ನೀವು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೀರಿ, ಹೆಚ್ಚು ಆಸಕ್ತಿದಾಯಕ ಸೇವಾ ಸನ್ನಿವೇಶಗಳನ್ನು ನೋಡೋಣ.

ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ದೀರ್ಘಾವಧಿಯ ಸಂಪರ್ಕಗಳು ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಅಳೆಯುವುದಿಲ್ಲ

ಮುಂಭಾಗದಿಂದ ಬ್ಯಾಕೆಂಡ್‌ಗೆ ಪ್ರತಿಯೊಂದು HTTP ವಿನಂತಿಯನ್ನು ಪ್ರತ್ಯೇಕ TCP ಸಂಪರ್ಕದಿಂದ ಒದಗಿಸಲಾಗುತ್ತದೆ, ಅದನ್ನು ತೆರೆಯಲಾಗುತ್ತದೆ ಮತ್ತು ಮುಚ್ಚಲಾಗುತ್ತದೆ.

ಮುಂಭಾಗವು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 100 ವಿನಂತಿಗಳನ್ನು ಬ್ಯಾಕೆಂಡ್‌ಗೆ ಕಳುಹಿಸಿದರೆ, ನಂತರ 100 ವಿಭಿನ್ನ TCP ಸಂಪರ್ಕಗಳನ್ನು ತೆರೆಯಲಾಗುತ್ತದೆ ಮತ್ತು ಮುಚ್ಚಲಾಗುತ್ತದೆ.

ಒಂದು TCP ಸಂಪರ್ಕವನ್ನು ತೆರೆಯುವ ಮೂಲಕ ಮತ್ತು ಎಲ್ಲಾ ನಂತರದ HTTP ವಿನಂತಿಗಳಿಗೆ ಅದನ್ನು ಬಳಸುವ ಮೂಲಕ ನೀವು ವಿನಂತಿಯನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವ ಸಮಯವನ್ನು ಕಡಿಮೆ ಮಾಡಬಹುದು ಮತ್ತು ಲೋಡ್ ಮಾಡಬಹುದು.

HTTP ಪ್ರೋಟೋಕಾಲ್ HTTP ಕೀಪ್-ಲೈವ್ ಅಥವಾ ಸಂಪರ್ಕ ಮರುಬಳಕೆ ಎಂಬ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಹೊಂದಿದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಬಹು HTTP ವಿನಂತಿಗಳು ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಕಳುಹಿಸಲು ಮತ್ತು ಸ್ವೀಕರಿಸಲು ಒಂದೇ TCP ಸಂಪರ್ಕವನ್ನು ಬಳಸಲಾಗುತ್ತದೆ:

ಈ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಸಕ್ರಿಯಗೊಳಿಸಲಾಗಿಲ್ಲ: ಸರ್ವರ್ ಮತ್ತು ಕ್ಲೈಂಟ್ ಎರಡನ್ನೂ ಅದಕ್ಕೆ ಅನುಗುಣವಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಬೇಕು.

ಸೆಟಪ್ ಸ್ವತಃ ಸರಳವಾಗಿದೆ ಮತ್ತು ಹೆಚ್ಚಿನ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಭಾಷೆಗಳು ಮತ್ತು ಪರಿಸರಗಳಿಗೆ ಪ್ರವೇಶಿಸಬಹುದಾಗಿದೆ.

ವಿವಿಧ ಭಾಷೆಗಳಲ್ಲಿನ ಉದಾಹರಣೆಗಳಿಗೆ ಕೆಲವು ಲಿಂಕ್‌ಗಳು ಇಲ್ಲಿವೆ:

• Node.js ನಲ್ಲಿ ಜೀವಂತವಾಗಿರಿಸಿಕೊಳ್ಳಿ
• ಸ್ಪ್ರಿಂಗ್ ಬೂಟ್‌ನಲ್ಲಿ ಜೀವಂತವಾಗಿರಿಸಿಕೊಳ್ಳಿ
• ಪೈಥಾನ್‌ನಲ್ಲಿ ಜೀವಂತವಾಗಿರಿಸಿಕೊಳ್ಳಿ
• .NET ನಲ್ಲಿ ಜೀವಂತವಾಗಿರಿಸಿಕೊಳ್ಳಿ

ನಾವು ಕುಬರ್ನೆಟ್ಸ್ ಸೇವೆಯಲ್ಲಿ ಕೀಪ್-ಲೈವ್ ಅನ್ನು ಬಳಸಿದರೆ ಏನಾಗುತ್ತದೆ?
ಮುಂಭಾಗ ಮತ್ತು ಬ್ಯಾಕೆಂಡ್ ಎರಡೂ ಜೀವಂತವಾಗಿರುವುದನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ ಎಂದು ಭಾವಿಸೋಣ.

ನಾವು ಮುಂಭಾಗದ ಒಂದು ಪ್ರತಿಯನ್ನು ಮತ್ತು ಬ್ಯಾಕೆಂಡ್‌ನ ಮೂರು ಪ್ರತಿಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಮುಂಭಾಗವು ಮೊದಲ ವಿನಂತಿಯನ್ನು ಮಾಡುತ್ತದೆ ಮತ್ತು ಬ್ಯಾಕೆಂಡ್‌ಗೆ TCP ಸಂಪರ್ಕವನ್ನು ತೆರೆಯುತ್ತದೆ. ವಿನಂತಿಯು ಸೇವೆಯನ್ನು ತಲುಪುತ್ತದೆ, ಬ್ಯಾಕೆಂಡ್ ಪಾಡ್‌ಗಳಲ್ಲಿ ಒಂದನ್ನು ಗಮ್ಯಸ್ಥಾನದ ವಿಳಾಸವಾಗಿ ಆಯ್ಕೆಮಾಡಲಾಗಿದೆ. ಬ್ಯಾಕೆಂಡ್ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಕಳುಹಿಸುತ್ತದೆ ಮತ್ತು ಮುಂಭಾಗವು ಅದನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ.

ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಸ್ವೀಕರಿಸಿದ ನಂತರ TCP ಸಂಪರ್ಕವನ್ನು ಮುಚ್ಚುವ ಸಾಮಾನ್ಯ ಪರಿಸ್ಥಿತಿಗಿಂತ ಭಿನ್ನವಾಗಿ, ಅದನ್ನು ಈಗ ಹೆಚ್ಚಿನ HTTP ವಿನಂತಿಗಳಿಗಾಗಿ ತೆರೆದಿಡಲಾಗಿದೆ.

ಮುಂಭಾಗವು ಬ್ಯಾಕೆಂಡ್‌ಗೆ ಹೆಚ್ಚಿನ ವಿನಂತಿಗಳನ್ನು ಕಳುಹಿಸಿದರೆ ಏನಾಗುತ್ತದೆ?

ಈ ವಿನಂತಿಗಳನ್ನು ಫಾರ್ವರ್ಡ್ ಮಾಡಲು, ತೆರೆದ TCP ಸಂಪರ್ಕವನ್ನು ಬಳಸಲಾಗುತ್ತದೆ, ಎಲ್ಲಾ ವಿನಂತಿಗಳು ಮೊದಲ ವಿನಂತಿಯು ಹೋದ ಅದೇ ಬ್ಯಾಕೆಂಡ್‌ಗೆ ಹೋಗುತ್ತವೆ.

iptables ಸಂಚಾರವನ್ನು ಮರುಹಂಚಿಕೆ ಮಾಡಬೇಕಲ್ಲವೇ?

ಈ ಸಂದರ್ಭದಲ್ಲಿ ಅಲ್ಲ.

ಒಂದು TCP ಸಂಪರ್ಕವನ್ನು ರಚಿಸಿದಾಗ, ಇದು iptables ನಿಯಮಗಳ ಮೂಲಕ ಹೋಗುತ್ತದೆ, ಇದು ಟ್ರಾಫಿಕ್ ಹೋಗುವ ನಿರ್ದಿಷ್ಟ ಬ್ಯಾಕೆಂಡ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ.

ಎಲ್ಲಾ ನಂತರದ ವಿನಂತಿಗಳು ಈಗಾಗಲೇ ತೆರೆದಿರುವ TCP ಸಂಪರ್ಕದಲ್ಲಿರುವುದರಿಂದ, iptables ನಿಯಮಗಳನ್ನು ಇನ್ನು ಮುಂದೆ ಕರೆಯಲಾಗುವುದಿಲ್ಲ.

ಅದು ಹೇಗಿದೆ ಎಂದು ನೋಡೋಣ.

1. ಮೊದಲ ಪಾಡ್ ಸೇವೆಗೆ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸುತ್ತದೆ:

   

2. ಮುಂದೆ ಏನಾಗುತ್ತದೆ ಎಂದು ನಿಮಗೆ ಈಗಾಗಲೇ ತಿಳಿದಿದೆ. ಸೇವೆಯು ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ, ಆದರೆ ವಿನಂತಿಯನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವ iptables ನಿಯಮಗಳಿವೆ:

   

3. ಬ್ಯಾಕೆಂಡ್ ಪಾಡ್‌ಗಳಲ್ಲಿ ಒಂದನ್ನು ಗಮ್ಯಸ್ಥಾನದ ವಿಳಾಸವಾಗಿ ಆಯ್ಕೆಮಾಡಲಾಗುತ್ತದೆ:

   

4. ವಿನಂತಿಯು ಪಾಡ್ ತಲುಪುತ್ತದೆ. ಈ ಹಂತದಲ್ಲಿ, ಎರಡು ಪಾಡ್‌ಗಳ ನಡುವೆ ನಿರಂತರ TCP ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸಲಾಗುತ್ತದೆ:

   

5. ಮೊದಲ ಪಾಡ್‌ನಿಂದ ಯಾವುದೇ ನಂತರದ ವಿನಂತಿಯು ಈಗಾಗಲೇ ಸ್ಥಾಪಿಸಲಾದ ಸಂಪರ್ಕದ ಮೂಲಕ ಹೋಗುತ್ತದೆ:

   

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

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

ಇದನ್ನು ಸರಿಪಡಿಸಬಹುದೇ?

ನಿರಂತರ ಸಂಪರ್ಕಗಳನ್ನು ಹೇಗೆ ಸಮತೋಲನಗೊಳಿಸಬೇಕೆಂದು ಕುಬರ್ನೆಟ್ಸ್ಗೆ ತಿಳಿದಿಲ್ಲವಾದ್ದರಿಂದ, ಈ ಕಾರ್ಯವು ನಿಮಗೆ ಬರುತ್ತದೆ.

ಸೇವೆಗಳು IP ವಿಳಾಸಗಳು ಮತ್ತು ಪೋರ್ಟ್‌ಗಳ ಸಂಗ್ರಹವಾಗಿದೆ ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗಳು.

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

ಅಥವಾ ಹೆಚ್ಚು ಅನ್ವಯಿಸಿ ಸಂಕೀರ್ಣ ಸಮತೋಲನ ಕ್ರಮಾವಳಿಗಳು.

ಸಮತೋಲನಕ್ಕೆ ಜವಾಬ್ದಾರರಾಗಿರುವ ಕ್ಲೈಂಟ್-ಸೈಡ್ ಕೋಡ್ ಈ ತರ್ಕವನ್ನು ಅನುಸರಿಸಬೇಕು:

1. ಸೇವೆಯಿಂದ ಅಂತಿಮ ಬಿಂದುಗಳ ಪಟ್ಟಿಯನ್ನು ಪಡೆಯಿರಿ.
2. ಪ್ರತಿ ಅಂತಿಮ ಬಿಂದುವಿಗೆ ನಿರಂತರ ಸಂಪರ್ಕವನ್ನು ತೆರೆಯಿರಿ.
3. ವಿನಂತಿಯನ್ನು ಮಾಡಬೇಕಾದಾಗ, ತೆರೆದ ಸಂಪರ್ಕಗಳಲ್ಲಿ ಒಂದನ್ನು ಬಳಸಿ.
4. ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗಳ ಪಟ್ಟಿಯನ್ನು ನಿಯಮಿತವಾಗಿ ನವೀಕರಿಸಿ, ಹೊಸದನ್ನು ರಚಿಸಿ ಅಥವಾ ಪಟ್ಟಿ ಬದಲಾದರೆ ಹಳೆಯ ನಿರಂತರ ಸಂಪರ್ಕಗಳನ್ನು ಮುಚ್ಚಿ.

ಈ ರೀತಿ ಕಾಣಿಸುತ್ತದೆ.

1. ಸೇವೆಗೆ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸುವ ಮೊದಲ ಪಾಡ್ ಬದಲಿಗೆ, ನೀವು ಕ್ಲೈಂಟ್ ಬದಿಯಲ್ಲಿ ವಿನಂತಿಗಳನ್ನು ಸಮತೋಲನಗೊಳಿಸಬಹುದು:

   

2. ಯಾವ ಪಾಡ್‌ಗಳು ಸೇವೆಯ ಭಾಗವಾಗಿದೆ ಎಂದು ಕೇಳುವ ಕೋಡ್ ಅನ್ನು ನೀವು ಬರೆಯಬೇಕಾಗಿದೆ:

   

3. ಒಮ್ಮೆ ನೀವು ಪಟ್ಟಿಯನ್ನು ಹೊಂದಿದ್ದರೆ, ಅದನ್ನು ಕ್ಲೈಂಟ್ ಬದಿಯಲ್ಲಿ ಉಳಿಸಿ ಮತ್ತು ಪಾಡ್‌ಗಳಿಗೆ ಸಂಪರ್ಕಿಸಲು ಅದನ್ನು ಬಳಸಿ:

   

4. ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸಿಂಗ್ ಅಲ್ಗಾರಿದಮ್‌ಗೆ ನೀವು ಜವಾಬ್ದಾರರಾಗಿರುತ್ತೀರಿ:

   

ಈಗ ಪ್ರಶ್ನೆ ಉದ್ಭವಿಸುತ್ತದೆ: ಈ ಸಮಸ್ಯೆಯು HTTP ಕೀಪ್-ಲೈವ್‌ಗೆ ಮಾತ್ರ ಅನ್ವಯಿಸುತ್ತದೆಯೇ?

ಕ್ಲೈಂಟ್-ಸೈಡ್ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸಿಂಗ್

ನಿರಂತರ TCP ಸಂಪರ್ಕಗಳನ್ನು ಬಳಸಬಹುದಾದ ಏಕೈಕ ಪ್ರೋಟೋಕಾಲ್ HTTP ಅಲ್ಲ.

ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಬಳಸಿದರೆ, ನೀವು ವಿನಂತಿಯನ್ನು ಮಾಡಲು ಅಥವಾ ಡೇಟಾಬೇಸ್‌ನಿಂದ ಡಾಕ್ಯುಮೆಂಟ್ ಅನ್ನು ಹಿಂಪಡೆಯಲು ಪ್ರತಿ ಬಾರಿ TCP ಸಂಪರ್ಕವನ್ನು ತೆರೆಯಲಾಗುವುದಿಲ್ಲ. 

ಬದಲಾಗಿ, ಡೇಟಾಬೇಸ್‌ಗೆ ನಿರಂತರ TCP ಸಂಪರ್ಕವನ್ನು ತೆರೆಯಲಾಗುತ್ತದೆ ಮತ್ತು ಬಳಸಲಾಗುತ್ತದೆ.

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

ಒಂದು ಡೇಟಾಬೇಸ್ ಪ್ರತಿಕೃತಿಯು ಇತರರಿಗಿಂತ ಹೆಚ್ಚು ಲೋಡ್ ಆಗುತ್ತದೆ. Kube-proxy ಮತ್ತು Kubernetes ಸಂಪರ್ಕಗಳನ್ನು ಸಮತೋಲನಗೊಳಿಸಲು ಸಹಾಯ ಮಾಡುವುದಿಲ್ಲ. ನಿಮ್ಮ ಡೇಟಾಬೇಸ್‌ಗೆ ಪ್ರಶ್ನೆಗಳನ್ನು ಸಮತೋಲನಗೊಳಿಸಲು ನೀವು ಕಾಳಜಿ ವಹಿಸಬೇಕು.

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

Node.js ನಿಂದ MySQL ಡೇಟಾಬೇಸ್ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಪ್ರವೇಶಿಸುವ ಉದಾಹರಣೆಯನ್ನು ಕೆಳಗೆ ನೀಡಲಾಗಿದೆ:

var mysql = require('mysql');
var poolCluster = mysql.createPoolCluster();

var endpoints = /* retrieve endpoints from the Service */

for (var [index, endpoint] of endpoints) {
  poolCluster.add(`mysql-replica-${index}`, endpoint);
}

// Make queries to the clustered MySQL database

ನಿರಂತರ TCP ಸಂಪರ್ಕಗಳನ್ನು ಬಳಸುವ ಅನೇಕ ಇತರ ಪ್ರೋಟೋಕಾಲ್‌ಗಳಿವೆ:

• ವೆಬ್‌ಸಾಕೆಟ್‌ಗಳು ಮತ್ತು ಸುರಕ್ಷಿತ ವೆಬ್‌ಸಾಕೆಟ್‌ಗಳು
• HTTP / 2
• gRPC
• RSockets
• AMQP

ಈ ಹೆಚ್ಚಿನ ಪ್ರೋಟೋಕಾಲ್‌ಗಳೊಂದಿಗೆ ನೀವು ಈಗಾಗಲೇ ಪರಿಚಿತರಾಗಿರಬೇಕು.

ಆದರೆ ಈ ಪ್ರೋಟೋಕಾಲ್‌ಗಳು ತುಂಬಾ ಜನಪ್ರಿಯವಾಗಿದ್ದರೆ, ಪ್ರಮಾಣಿತ ಸಮತೋಲನ ಪರಿಹಾರ ಏಕೆ ಇಲ್ಲ? ಕ್ಲೈಂಟ್ ತರ್ಕವನ್ನು ಏಕೆ ಬದಲಾಯಿಸಬೇಕು? ಸ್ಥಳೀಯ ಕುಬರ್ನೆಟ್ಸ್ ಪರಿಹಾರವಿದೆಯೇ?

Kube-proxy ಮತ್ತು iptables ಅನ್ನು Kubernetes ಗೆ ನಿಯೋಜಿಸುವಾಗ ಸಾಮಾನ್ಯ ಬಳಕೆಯ ಸಂದರ್ಭಗಳನ್ನು ಒಳಗೊಳ್ಳಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ. ಇದು ಅನುಕೂಲಕ್ಕಾಗಿ.

ನೀವು REST API ಅನ್ನು ಬಹಿರಂಗಪಡಿಸುವ ವೆಬ್ ಸೇವೆಯನ್ನು ಬಳಸುತ್ತಿದ್ದರೆ, ನೀವು ಅದೃಷ್ಟವಂತರು - ಈ ಸಂದರ್ಭದಲ್ಲಿ, ನಿರಂತರ TCP ಸಂಪರ್ಕಗಳನ್ನು ಬಳಸಲಾಗುವುದಿಲ್ಲ, ನೀವು ಯಾವುದೇ Kubernetes ಸೇವೆಯನ್ನು ಬಳಸಬಹುದು.

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

ಆದಾಗ್ಯೂ, ಖಂಡಿತವಾಗಿಯೂ ಸಹಾಯ ಮಾಡುವ ಆಯ್ಕೆಗಳಿವೆ.

ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ದೀರ್ಘಾವಧಿಯ ಸಂಪರ್ಕಗಳನ್ನು ಸಮತೋಲನಗೊಳಿಸುವುದು

ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ನಾಲ್ಕು ವಿಧದ ಸೇವೆಗಳಿವೆ:

1. ClusterIP
2. ನೋಡ್ ಪೋರ್ಟ್
3. ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್
4. ತಲೆ ಇಲ್ಲ

ಮೊದಲ ಮೂರು ಸೇವೆಗಳು ವರ್ಚುವಲ್ IP ವಿಳಾಸವನ್ನು ಆಧರಿಸಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ, ಇದನ್ನು iptables ನಿಯಮಗಳನ್ನು ನಿರ್ಮಿಸಲು kube-proxy ಬಳಸುತ್ತದೆ. ಆದರೆ ಎಲ್ಲಾ ಸೇವೆಗಳ ಮೂಲಭೂತ ಆಧಾರವು ತಲೆಯಿಲ್ಲದ ಸೇವೆಯಾಗಿದೆ.

ಹೆಡ್‌ಲೆಸ್ ಸೇವೆಯು ಅದರೊಂದಿಗೆ ಯಾವುದೇ IP ವಿಳಾಸವನ್ನು ಹೊಂದಿಲ್ಲ ಮತ್ತು IP ವಿಳಾಸಗಳ ಪಟ್ಟಿಯನ್ನು ಮತ್ತು ಅದರೊಂದಿಗೆ ಸಂಯೋಜಿತವಾಗಿರುವ ಪಾಡ್‌ಗಳ (ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗಳು) ಪೋರ್ಟ್‌ಗಳನ್ನು ಹಿಂಪಡೆಯಲು ಯಾಂತ್ರಿಕ ವ್ಯವಸ್ಥೆಯನ್ನು ಮಾತ್ರ ಒದಗಿಸುತ್ತದೆ.

ಎಲ್ಲಾ ಸೇವೆಗಳು ತಲೆರಹಿತ ಸೇವೆಯನ್ನು ಆಧರಿಸಿವೆ.

ClusterIP ಸೇವೆಯು ಕೆಲವು ಸೇರ್ಪಡೆಗಳೊಂದಿಗೆ ಹೆಡ್‌ಲೆಸ್ ಸೇವೆಯಾಗಿದೆ: 

1. ನಿರ್ವಹಣಾ ಪದರವು ಅದನ್ನು IP ವಿಳಾಸವನ್ನು ನಿಯೋಜಿಸುತ್ತದೆ.
2. Kube-proxy ಅಗತ್ಯ iptables ನಿಯಮಗಳನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ.

ಈ ರೀತಿಯಲ್ಲಿ ನೀವು kube-proxy ಅನ್ನು ನಿರ್ಲಕ್ಷಿಸಬಹುದು ಮತ್ತು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಸಮತೋಲನಗೊಳಿಸಲು ಹೆಡ್‌ಲೆಸ್ ಸೇವೆಯಿಂದ ಪಡೆದ ಅಂತಿಮ ಬಿಂದುಗಳ ಪಟ್ಟಿಯನ್ನು ನೇರವಾಗಿ ಬಳಸಬಹುದು.

ಆದರೆ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ನಿಯೋಜಿಸಲಾದ ಎಲ್ಲಾ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ನಾವು ಒಂದೇ ರೀತಿಯ ತರ್ಕವನ್ನು ಹೇಗೆ ಸೇರಿಸಬಹುದು?

ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಈಗಾಗಲೇ ನಿಯೋಜಿಸಿದ್ದರೆ, ಈ ಕಾರ್ಯವು ಅಸಾಧ್ಯವೆಂದು ತೋರುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಪರ್ಯಾಯ ಆಯ್ಕೆ ಇದೆ.

ಸೇವೆ ಮೆಶ್ ನಿಮಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ

ಕ್ಲೈಂಟ್-ಸೈಡ್ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸಿಂಗ್ ತಂತ್ರವು ಸಾಕಷ್ಟು ಪ್ರಮಾಣಿತವಾಗಿದೆ ಎಂದು ನೀವು ಈಗಾಗಲೇ ಗಮನಿಸಿರಬಹುದು.

ಅಪ್ಲಿಕೇಶನ್ ಪ್ರಾರಂಭವಾದಾಗ, ಅದು:

1. ಸೇವೆಯಿಂದ IP ವಿಳಾಸಗಳ ಪಟ್ಟಿಯನ್ನು ಪಡೆಯುತ್ತದೆ.
2. ಸಂಪರ್ಕ ಪೂಲ್ ಅನ್ನು ತೆರೆಯುತ್ತದೆ ಮತ್ತು ನಿರ್ವಹಿಸುತ್ತದೆ.
3. ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗಳನ್ನು ಸೇರಿಸುವ ಅಥವಾ ತೆಗೆದುಹಾಕುವ ಮೂಲಕ ಕಾಲಕಾಲಕ್ಕೆ ಪೂಲ್ ಅನ್ನು ನವೀಕರಿಸುತ್ತದೆ.

ಒಮ್ಮೆ ಅಪ್ಲಿಕೇಶನ್ ವಿನಂತಿಯನ್ನು ಮಾಡಲು ಬಯಸಿದರೆ, ಅದು:

1. ಕೆಲವು ತರ್ಕವನ್ನು ಬಳಸಿಕೊಂಡು ಲಭ್ಯವಿರುವ ಸಂಪರ್ಕವನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ (ಉದಾ ರೌಂಡ್-ರಾಬಿನ್).
2. ವಿನಂತಿಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ.

ಈ ಹಂತಗಳು WebSockets, gRPC ಮತ್ತು AMQP ಸಂಪರ್ಕಗಳೆರಡಕ್ಕೂ ಕೆಲಸ ಮಾಡುತ್ತವೆ.

ನೀವು ಈ ತರ್ಕವನ್ನು ಪ್ರತ್ಯೇಕ ಲೈಬ್ರರಿಯಾಗಿ ಪ್ರತ್ಯೇಕಿಸಬಹುದು ಮತ್ತು ಅದನ್ನು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಲ್ಲಿ ಬಳಸಬಹುದು.

ಆದಾಗ್ಯೂ, ನೀವು ಬದಲಿಗೆ Istio ಅಥವಾ Linkerd ನಂತಹ ಸೇವಾ ಮೆಶ್‌ಗಳನ್ನು ಬಳಸಬಹುದು.

ಸೇವೆ ಮೆಶ್ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಪ್ರಕ್ರಿಯೆಯೊಂದಿಗೆ ವರ್ಧಿಸುತ್ತದೆ:

1. ಸೇವೆಯ IP ವಿಳಾಸಗಳಿಗಾಗಿ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಹುಡುಕುತ್ತದೆ.
2. WebSockets ಮತ್ತು gRPC ಯಂತಹ ಸಂಪರ್ಕಗಳನ್ನು ಪರೀಕ್ಷಿಸುತ್ತದೆ.
3. ಸರಿಯಾದ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ವಿನಂತಿಗಳನ್ನು ಸಮತೋಲನಗೊಳಿಸುತ್ತದೆ.

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

ಸಮತೋಲನ ಸಮಸ್ಯೆಗಳನ್ನು ನಿರ್ಲಕ್ಷಿಸಿದರೆ ಏನಾಗುತ್ತದೆ?

ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸಿಂಗ್ ಅನ್ನು ಬಳಸದಿರಲು ನೀವು ಆಯ್ಕೆ ಮಾಡಬಹುದು ಮತ್ತು ಇನ್ನೂ ಯಾವುದೇ ಬದಲಾವಣೆಗಳನ್ನು ಗಮನಿಸುವುದಿಲ್ಲ. ಕೆಲವು ಕೆಲಸದ ಸನ್ನಿವೇಶಗಳನ್ನು ನೋಡೋಣ.

ನೀವು ಸರ್ವರ್‌ಗಳಿಗಿಂತ ಹೆಚ್ಚಿನ ಗ್ರಾಹಕರನ್ನು ಹೊಂದಿದ್ದರೆ, ಇದು ಅಂತಹ ದೊಡ್ಡ ಸಮಸ್ಯೆಯಲ್ಲ.

ಎರಡು ಸರ್ವರ್‌ಗಳಿಗೆ ಸಂಪರ್ಕಿಸುವ ಐದು ಕ್ಲೈಂಟ್‌ಗಳಿವೆ ಎಂದು ಹೇಳೋಣ. ಯಾವುದೇ ಸಮತೋಲನವಿಲ್ಲದಿದ್ದರೂ, ಎರಡೂ ಸರ್ವರ್‌ಗಳನ್ನು ಬಳಸಲಾಗುತ್ತದೆ:

ಸಂಪರ್ಕಗಳನ್ನು ಸಮವಾಗಿ ವಿತರಿಸಲಾಗುವುದಿಲ್ಲ: ಬಹುಶಃ ನಾಲ್ಕು ಕ್ಲೈಂಟ್‌ಗಳು ಒಂದೇ ಸರ್ವರ್‌ಗೆ ಸಂಪರ್ಕಗೊಂಡಿರಬಹುದು, ಆದರೆ ಎರಡೂ ಸರ್ವರ್‌ಗಳನ್ನು ಬಳಸುವ ಉತ್ತಮ ಅವಕಾಶವಿದೆ.

ಇದಕ್ಕೆ ವಿರುದ್ಧವಾದ ಸನ್ನಿವೇಶವು ಹೆಚ್ಚು ಸಮಸ್ಯಾತ್ಮಕವಾಗಿದೆ.

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

ಎರಡು ಕ್ಲೈಂಟ್‌ಗಳು ಮತ್ತು ಐದು ಸರ್ವರ್‌ಗಳಿವೆ ಎಂದು ಹೇಳೋಣ. ಉತ್ತಮ ಸಂದರ್ಭದಲ್ಲಿ, ಐದರಲ್ಲಿ ಎರಡು ಸರ್ವರ್‌ಗಳಿಗೆ ಎರಡು ಶಾಶ್ವತ ಸಂಪರ್ಕಗಳು ಇರುತ್ತವೆ.

ಉಳಿದ ಸರ್ವರ್‌ಗಳು ನಿಷ್ಕ್ರಿಯವಾಗಿರುತ್ತವೆ:

ಈ ಎರಡು ಸರ್ವರ್‌ಗಳು ಕ್ಲೈಂಟ್ ವಿನಂತಿಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ಸಮತಲ ಸ್ಕೇಲಿಂಗ್ ಸಹಾಯ ಮಾಡುವುದಿಲ್ಲ.

ತೀರ್ಮಾನಕ್ಕೆ

ಹೆಚ್ಚಿನ ಪ್ರಮಾಣಿತ ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್ ಸನ್ನಿವೇಶಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡಲು ಕುಬರ್ನೆಟ್ಸ್ ಸೇವೆಗಳನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ.

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

ಇದರರ್ಥ ನೀವು ಕ್ಲೈಂಟ್-ಸೈಡ್ ಬ್ಯಾಲೆನ್ಸಿಂಗ್ ಅನ್ನು ಮನಸ್ಸಿನಲ್ಲಿಟ್ಟುಕೊಂಡು ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಬರೆಯಬೇಕು.

ತಂಡವು ಸಿದ್ಧಪಡಿಸಿದ ಅನುವಾದ Mail.ru ನಿಂದ Kubernetes aaS.

ವಿಷಯದ ಬಗ್ಗೆ ಇನ್ನೇನು ಓದಬೇಕು:

1. ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ಮೂರು ಹಂತದ ಆಟೋಸ್ಕೇಲಿಂಗ್ ಮತ್ತು ಅವುಗಳನ್ನು ಹೇಗೆ ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಬಳಸುವುದು. 
2. ಅನುಷ್ಠಾನಕ್ಕಾಗಿ ಟೆಂಪ್ಲೇಟ್‌ನೊಂದಿಗೆ ಕಡಲ್ಗಳ್ಳತನದ ಉತ್ಸಾಹದಲ್ಲಿ ಕುಬರ್ನೆಟ್ಸ್.
3. ಡಿಜಿಟಲ್ ರೂಪಾಂತರದ ಬಗ್ಗೆ ನಮ್ಮ ಟೆಲಿಗ್ರಾಮ್ ಚಾನೆಲ್.

ಮೂಲ: www.habr.com