Kubernetes Pod ನಲ್ಲಿ ಪ್ರಾಕ್ಸಿ ಪರಿಸರ ವೇರಿಯೇಬಲ್‌ಗಳನ್ನು ಹೊಂದಿಸಿ

ಬೆಂಬಲಿತ HTTP ಪ್ರಾಕ್ಸಿ ವೇರಿಯೇಬಲ್‌ಗಳನ್ನು Kubernetes ಕಂಟೇನರ್ ಸ್ಪೆಸಿಫಿಕೇಶನ್‌ನಲ್ಲಿ ಇರಿಸಿ ಮತ್ತು ನೇರ ಕ್ಲಸ್ಟರ್ ಮಾರ್ಗಗಳನ್ನು ಇಮೇಜ್-ಪುಲ್ ಸಂರಚನೆಯಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸಿ.

Kubernetes ನೋಡ್‌ನಲ್ಲಿನ ಆಜ್ಞೆಯು ಶೆಲ್ ಪ್ರಾಕ್ಸಿಯನ್ನು ಬಳಸಬಹುದು, ಆದರೆ ಆ ನೋಡ್‌ನಲ್ಲಿನ Pod ಗೆ ಯಾವುದೇ ಪ್ರಾಕ್ಸಿ ಪರಿಸರವಿಲ್ಲ. ಕಂಟೇನರ್‌ನ ಪರಿಸರವನ್ನು ಅದರ ಇಮೇಜ್ ಮತ್ತು Pod ಸಂರಚನೆಯಿಂದ ವ್ಯಾಖ್ಯಾನಿಸಲಾಗುತ್ತದೆ.

ಈ ವೇರಿಯೇಬಲ್‌ಗಳನ್ನು ಬೆಂಬಲಿಸುವ ಅಪ್ಲಿಕೇಶನ್‌ಗಾಗಿ, ಅದರ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಕಂಟೇನರ್ ನಮೂದಿಗೆ env ಪಟ್ಟಿಯನ್ನು ಸೇರಿಸಿ:

env:
  - name: HTTP_PROXY
    value: http://proxy.example:8080
  - name: HTTPS_PROXY
    value: http://proxy.example:8080
  - name: NO_PROXY
    value: localhost,127.0.0.1,kubernetes.default.svc,.svc,.cluster.local

Deployment ನಲ್ಲಿ, ಇದು spec.template.spec.containers ನಲ್ಲಿನ ಸಂಬಂಧಿತ ಕಂಟೇನರ್ ಅಡಿಯಲ್ಲಿ ಬರುತ್ತದೆ. ಹೊಸ Pods ಅದನ್ನು ಸ್ವೀಕರಿಸಲು ಅದರ ಸಾಮಾನ್ಯ ರೋಲ್‌ಔಟ್ ಮೂಲಕ ವರ್ಕ್‌ಲೋಡ್ ಅನ್ನು ನವೀಕರಿಸಿ. ನಿಜವಾದ ಕ್ಲೈಂಟ್ ಅಗತ್ಯವಿದ್ದಾಗ ಸಣ್ಣ ಅಕ್ಷರಗಳ ಹೆಸರುಗಳನ್ನೂ ಒದಗಿಸಿ.

ಬೈಪಾಸ್ ಪಟ್ಟಿ ಪ್ರಾರಂಭಿಕ ಉದಾಹರಣೆಯೇ ಹೊರತು ಕ್ಲಸ್ಟರ್‌ನ ಪ್ರತಿ ಮಾರ್ಗದ ಪಟ್ಟಿಯಲ್ಲ. ಕ್ಲಸ್ಟರ್‌ನ ನಿಜವಾದ DNS ಪ್ರತ್ಯಯ ಮತ್ತು ಆಂತರಿಕ ಗಮ್ಯಸ್ಥಾನಗಳನ್ನು ಬಳಸಿ. ಸೇವಾ IP ಬಳಸುವ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಅವುಗಳ ಕ್ಲೈಂಟ್ ಬೆಂಬಲಿಸುವ ಸಿಂಟ್ಯಾಕ್ಸ್‌ನಲ್ಲಿ ನಿಜವಾದ ಸೇವಾ ಶ್ರೇಣಿಗಳು ಬೇಕಾಗಬಹುದು.

Init ಕಂಟೇನರ್‌ಗಳಿಗೆ ತಮ್ಮದೇ ಕಂಟೇನರ್ ಸ್ಪೆಸಿಫಿಕೇಶನ್‌ಗಳಿವೆ. ಅವು ಬಾಹ್ಯ ಡೌನ್‌ಲೋಡ್ ಮಾಡುವಾಗ ಅಲ್ಲಿ ಉದ್ದೇಶಿತ ಸಂರಚನೆಯನ್ನು ಸೇರಿಸಿ. ಸಾರ್ವಜನಿಕ HTTP ಡೌನ್‌ಲೋಡ್‌ಗಳಿಗೆ, HTTP ಪ್ರಾಕ್ಸಿ ಪಟ್ಟಿಯಿಂದ ಒಂದು ಎಂಡ್‌ಪಾಯಿಂಟ್ ಈ ಕಂಟೇನರ್ ಪರಿಸರ ಮೌಲ್ಯಗಳಿಗೆ ಅಭ್ಯರ್ಥಿ.

ಇಮೇಜ್-ಪುಲ್ ಅಪ್ಲಿಕೇಶನ್ ಚಾಲನೆಯಾಗುವ ಮೊದಲು ಸಂಭವಿಸುತ್ತದೆ ಮತ್ತು ನೋಡ್‌ನ ಕಂಟೇನರ್ ರನ್‌ಟೈಮ್ ಅದನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ. Pod env ಆ ಹಿಂದಿನ ರಜಿಸ್ಟ್ರಿ ಸಂಪರ್ಕವನ್ನು ಸಂರಚಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ.

ಅಂತಿಮವಾಗಿ, HTTP ಪ್ರಾಕ್ಸಿ ವೇರಿಯೇಬಲ್‌ಗಳು ಅವುಗಳನ್ನು ಬಳಸುವ ಕ್ಲೈಂಟ್‌ಗಳ ಮೇಲೆ ಮಾತ್ರ ಪರಿಣಾಮ ಬೀರುತ್ತವೆ. ಅವು Pod ನಿಂದ ಯಾವುದೇ ಅನಿಯಂತ್ರಿತ ಡೇಟಾಬೇಸ್, UDP ಅಥವಾ ಇತರ ಸಾಕೆಟ್ ಸಂಚಾರವನ್ನು ಮರುನಿರ್ದೇಶಿಸುವುದಿಲ್ಲ.

ಸಂಬಂಧಿತ ಲೇಖನಗಳು