Kubernetes Pod-ൽ പ്രോക്സി പരിസ്ഥിതി വേരിയബിളുകൾ സജ്ജീകരിക്കുക

പിന്തുണയുള്ള HTTP പ്രോക്സി വേരിയബിളുകൾ Kubernetes കണ്ടെയ്നർ സ്പെസിഫിക്കേഷനിൽ ഇടുക, കൂടാതെ ക്ലസ്റ്ററിന്റെ നേരിട്ടുള്ള റൂട്ടുകൾ ഇമേജ്-പുൾ കോൺഫിഗറേഷനിൽ നിന്ന് വേർതിരിച്ച് സൂക്ഷിക്കുക.

Kubernetes നോഡിലെ ഒരു കമാൻഡിന് shell പ്രോക്സി ഉപയോഗിക്കാം, എന്നാൽ ആ നോഡിലെ 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 അല്ലെങ്കിൽ മറ്റ് സോക്കറ്റ് ട്രാഫിക്ക് റീഡയറക്ട് ചെയ്യുന്നില്ല.

അനുബന്ധ ലേഖനങ്ങൾ