വിട ingress-nginx, ഹലോ ഗേറ്റ്വേ API

വർഷങ്ങളായി, എല്ലാ പുതിയ കുബർനെറ്റസ് ക്ലസ്റ്ററുകളിലും ഞാൻ ആദ്യം ഇൻസ്റ്റാൾ ചെയ്യുന്ന കാര്യം ഇൻഗ്രെസ്സ്-നിങ്ക്സ് ആയിരുന്നു. ആപ്ലിക്കേഷനുകൾക്കും, നിരീക്ഷണത്തിനും, രസകരമായ എന്തും ഉണ്ടാകുന്നതിനു മുമ്പും. അത് മുൻവാതിലായിരുന്നു. ട്രാഫിക് വന്നു, ഇംഗെസ്-നിങ്ക്സ് ശരിയായ സ്ഥലത്തേക്ക് അയച്ചു, എനിക്ക് അതിനെക്കുറിച്ച് ചിന്തിക്കേണ്ടി വന്നത് വളരെ അപൂർവമായിരുന്നു.

ആ വാതിൽ ഇപ്പോൾ ഔദ്യോഗികമായി പരിപാലിക്കപ്പെടുന്നില്ല. 2025 നവംബറിൽ, കുബർനെറ്റസ് പ്രോജക്റ്റ് ഇൻഗ്രെസ്-നിങ്ക്സ് വിരമിക്കുമെന്ന് പ്രഖ്യാപിച്ചു, മികച്ച പരിശ്രമ പരിപാലനത്തോടെ 2026 മാർച്ചുവരെ മാത്രം. ആ തീയതി കഴിഞ്ഞു. നിങ്ങൾ ഇപ്പോഴും അത് പ്രവർത്തിപ്പിക്കുന്നുണ്ടെങ്കിൽ, പല ക്ലസ്റ്ററുകളും പ്രവർത്തിക്കുന്നുണ്ടെങ്കിൽ, അതിന്റെ അർത്ഥം ഇതാണ്, ഞാൻ എങ്ങനെ പുറത്തുവരും.

ശരിക്കും നടന്നത്

ingress-nginx ഒരു കമ്മ്യൂണിറ്റി പ്രോജക്ട് ആയിരുന്നു, വളരെ ചെറിയ ഒരു കൂട്ടം സന്നദ്ധപ്രവർത്തകർ അവരുടെ ഒഴിവുസമയങ്ങളിൽ വർഷങ്ങളോളം നിലനിർത്തി. അതൊരു വിമർശനമല്ല. നമ്മളെല്ലാം ആശ്രയിക്കുന്ന സോഫ്റ്റ് വെയറുകളുടെ പിന്നിലെ അസുഖകരമായ സത്യം.

സുരക്ഷ അത് കൂടുതൽ വഷളാക്കി. 2025 മാർച്ചില് , ഗുരുതരമായ ഒരു കൂട്ടം ദുർബലതകൾ അകത്തുകടക്കുക ഇന് ഗ്രെസ്-നിന് ജിക്സിലെ ഒരു ബഗ് ഏറ്റവും മോശം സാഹചര്യത്തില് ഒരു ആക്രമണകാരിയെ ഒരു ക്ലസ്റ്ററിനെ മുഴുവന് കൈകാര്യം ചെയ്യാൻ അനുവദിക്കുമെന്ന് കാണിച്ചു. ഇത്തരത്തിലുള്ള കാര്യങ്ങൾ ശരിയായി പരിഹരിക്കാന് സമയവും ആളുകളും ആവശ്യമാണ്. അതുകൊണ്ട് കുബർനെറ്റസ് സിഐജി നെറ്റ് വർക്കും സെക്യൂരിറ്റി റെസ്പോൺസ് കമ്മിറ്റിയും സത്യസന്ധമായി തീരുമാനിച്ചു: അത് പിൻവലിക്കുക. ആസൂത്രിതമായി പിന്തുടരുന്ന ഒരു പദ്ധതി, ഇൻഗേറ്റ് എന്നൊരു പദ്ധതി, ഒരിക്കലും വേണ്ടത്ര മുന്നോട്ട് പോയിട്ടില്ല, അവരും വിരമിക്കുകയാണ്.

ഇവിടെ രണ്ടു കാര്യങ്ങൾ എളുപ്പത്തിൽ കൂട്ടിയിണക്കാവുന്നതാണ്, അതുകൊണ്ട് വ്യക്തമായി പറയാം:

• എൻഗെര് സ്-നിന് ജിക്സ് കണ്ട്രോളര് വിരമിച്ചിരിക്കുന്നു. പുതിയ പതിപ്പുകളില്ല, ബഗ് പരിഹാരങ്ങളില്ല, സുരക്ഷാ പാച്ചുകളില്ല. ഈ റിപ്പോസിറ്ററികള് വായിക്കാന് മാത്രമുള്ളവയാണ്.
• കുബർനെറ്റസ് ഇന്ഗ്രെസ് എപിഐ അല്ല. സി. Ingress റിസോഴ്സ് ഇപ്പോഴും പ്രവർത്തിക്കുന്നു. അത് മരവിപ്പിച്ചു. പുതിയ സവിശേഷതകളൊന്നും വരില്ല.
• F5 ൽ നിന്നുള്ള വാണിജ്യ NGINX ഇൻഗ്രെസ് കൺട്രോളർ വ്യത്യസ്തമായ ഉൽപ്പന്നമാണ്. ഒരേ കുടുംബനാമം, വ്യത്യസ്ത കോഡ്, ഇപ്പോഴും നിലനിർത്തിയിരിക്കുന്നു.

എനിക്ക് പേടിക്കണോ?

ഇല്ല. അറ്റകുറ്റപ്പണി അവസാനിച്ചപ്പോൾ നിങ്ങളുടെ ക്ലസ്റ്റർ തകർന്നില്ല. നിലവിലുള്ള ഇൻസ്റ്റലേഷനുകൾ തുടരുന്നു, ചിത്രങ്ങളും ഹെൽം ചാർട്ടുകളും ഇപ്പോഴും ലഭ്യമാണ്.

പക്ഷെ ഈ ഘടകം എന്താണെന്ന് ചിന്തിക്കുക. നിങ്ങളുടെ ക്ലസ്റ്ററിലെ ഇന്റർനെറ്റിനെ നേരിട്ട് അഭിമുഖീകരിക്കുന്ന ഒരേയൊരു കാര്യം. അപരിചിതരുടെ എല്ലാ അഭ്യർത്ഥനകളും അത് വിശകലനം ചെയ്യുന്നു. ഇനിമുതൽ, അടുത്ത ദുർബലമായ സ്ഥലം കണ്ടെത്തുമ്പോൾ, ആരും അത് പരിഹരിക്കില്ല. അത് ഒരു "ഒരുനാൾ" പ്രശ്നമല്ല. ഇത് ഈ പാദത്തിലെ പ്രശ്നമാണ്.

നിങ്ങളുടെ ക്ലസ്റ്ററിന്റെ അറ്റത്ത് പച്ചയില്ലാത്ത സോഫ്റ്റ്വെയർ പ്രവർത്തിപ്പിക്കുന്നത് മുൻവാതിൽ തുറന്നിടുന്നത് പോലെയാണ് കാരണം അത് ഇതുവരെ മോഷ്ടിക്കപ്പെട്ടിട്ടില്ല.

ആദ്യം, നിങ്ങളില് എന്തെങ്കിലും രോഗം ഉണ്ടോ എന്ന് കണ്ടുപിടിക്കുക. ഈ കമാന് ഡ്, ഔദ്യോഗിക പ്രഖ്യാപനത്തില് നിന്നും, ക്ലസ്റ്ററിലുടനീളമുള്ള എല്ലാ എൻഗെര് സ്-നിന് ജിക്സ് പാഡുകളും പട്ടികപ്പെടുത്തുന്നു:

kubectl get pods --all-namespaces \
  --selector app.kubernetes.io/name=ingress-nginx

അത് ഒന്നും പറയുന്നില്ലെങ്കിൽ, നിങ്ങൾക്ക് വിശ്രമിക്കാം, അവസാനം വരെ പോകാം. അത് കോഡുകൾ തിരികെ നൽകുകയാണെങ്കിൽ, വായിക്കുന്നത് തുടരുക.

ഗേറ്റ്വേ API, ലളിതമായ വാക്കുകളിൽ

ഗേറ്റ്വേ എപിഐ ആണ് ഇന്ഗ്രെസിന്റെ ഔദ്യോഗിക പിൻഗാമി. ഇത് പുതിയ കാര്യമല്ല. 2023 ൽ തന്നെ കോർ സ്ഥിരമായി. മിക്കവാറും എല്ലാ പ്രധാന നെറ്റ് വർക്കിങ് പ്രോജക്ടുകളും ക്ലൌഡ് ദാതാക്കളും ഇന്ന് ഇത് പിന്തുണയ്ക്കുന്നു.

ഏറ്റവും വലിയ മാറ്റം ഒരു വലിയ വസ്തുവിന് കുറച്ച് ചെറിയ വസ്തുക്കളായി മാറുന്നു എന്നതാണ്, ഓരോന്നും ശരിയായ വ്യക്തിക്ക് സ്വന്തമാണ്:

• ഗേറ്റ്വേ ക്ലാസ്: ഏത് നടപ്പിലാക്കലാണ് ട്രാഫിക് നടത്തുന്നത്, ഉദാഹരണത്തിന് എംബോയ് ഗേറ്റ്വേ അല്ലെങ്കിൽ സിലിയം. സാധാരണയായി പ്ലാറ്റ്ഫോം ടീം ഒരിക്കൽ സജ്ജമാക്കുന്നു.
• ഗേറ്റ്വേ: യഥാർത്ഥ പ്രവേശന സ്ഥലം. ഏത് പോർട്ടുകൾ, ഹോസ്റ്റ്നാമങ്ങൾ, ഏത് TLS സർട്ടിഫിക്കറ്റുകൾ ആര് ആ ക്ലസ്റ്റര് നടത്തുന്നുവോ അവര് ക്കുള്ളതാണ്.
• എച്ച്ടിടിപി റൂട്ട്: ഒരു ആപ്പിന്റെ റൂട്ടിംഗ് നിയമങ്ങൾ. "അയയ്ക്കുക /api ആപ്പ് ടീമിന് സ്വന്തമായ ഒരു നാമമേഖലയിൽ.

ഇന് ഗ്രെസ് ഉപയോഗിച്ച്, എല്ലാം ഒരു റിസോഴ്സിലേക്ക് ചുരുക്കി, സ്പെസിഫിക്കേഷന് മൂടിയിട്ടില്ലാത്തതെല്ലാം വ്യാഖ്യാനങ്ങളിൽ മറച്ചിരുന്നു. 15 പേരുടെ കൂടെ ഒരു ഇന്ഗ്രെസ് കണ്ടിട്ടുള്ള ആരെങ്കിലും nginx.ingress.kubernetes.io/... ലൈനുകൾക്ക് അറിയാം ഞാനെന്ത് ഉദ്ദേശിക്കുന്നു എന്ന്. ആ കുറിപ്പുകൾ ഒരു കൺട്രോളറിൽ മാത്രമേ പ്രവർത്തിക്കൂ, അതുകൊണ്ട് "പോർട്ടബിൾ കുബർനെറ്റ്സ്" വാതിൽക്കൽ നിന്നു.

	അകത്തേക്കു കയറുന്നു	ഗേറ്റ്വേ API
ഘടന	ഒരു വിഭവം എല്ലാം ചെയ്യുന്നു	പ്ലാറ്റ്ഫോം, ആപ്ലിക്കേഷൻ ടീമുകൾക്കുള്ള പ്രത്യേക ഭാഗങ്ങൾ
വിപുലമായ സവിശേഷതകൾ	കൺട്രോളറിനു പ്രത്യേകമായ കുറിപ്പുകൾ	സ്പെസിഫിക്കേഷനിലേക്ക് ബിൽറ്റ് ഇൻ ചെയ്തിരിക്കുന്നു: തലക്കെട്ട് പൊരുത്തപ്പെടുത്തൽ, ട്രാഫിക് വിഭജനം, റീഡയറക്ട്
പ്രോട്ടോക്കോളുകൾ	എച്ച്ടിടിപി, എച്ച്ട്ടിടിഎപിഎസ്	ചില നടപ്പാക്കലുകളുള്ള HTTP, gRPC, TLS, TCP/UDP എന്നിവ
കൈമാറ്റം ചെയ്യാവുന്നവ	കുറിപ്പുകൾ വന്നാല് താഴ്ന്ന നിലയില്	വളരെ നല്ലത്: ഒരേ YAML നടപ്പിലാക്കലുകളിലുടനീളം പ്രവർത്തിക്കുന്നു
ഭാവി	മരവിപ്പിച്ച	പുതിയ ജോലികളെല്ലാം നടക്കുന്നിടത്ത്

ഇത് പ്രായോഗികമായി എങ്ങനെയിരിക്കും എന്ന് നോക്കാം. ആദ്യം ഗേറ്റ്വേ, പ്ലാറ്റ്ഫോം ടീം ഒരിക്കൽ സജ്ജീകരിച്ചതാണ്:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: web
  namespace: infra
spec:
  gatewayClassName: eg          # e.g. Envoy Gateway
  listeners:
  - name: https
    protocol: HTTPS
    port: 443
    hostname: "*.example.com"
    tls:
      mode: Terminate
      certificateRefs:
      - name: example-com-tls
    allowedRoutes:
      namespaces:
        from: All               # tighten this with a label selector later

ഓരോ ആപ്ലിക്കേഷൻ ടീമും സ്വന്തം റൂട്ട് അറ്റാച്ചുചെയ്യുന്നു, സ്വന്തം നാമമേഖലയിൽ:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: shop
  namespace: shop
spec:
  parentRefs:
  - name: web
    namespace: infra
  hostnames: ["shop.example.com"]
  rules:
  - matches:
    - path: { type: PathPrefix, value: /api }
    backendRefs:
    - name: shop-api
      port: 8080

ആപ്ലിക്കേഷൻ ടീം ഒരിക്കലും ഗേറ്റ്വേയെ സ്പർശിക്കുന്നില്ല, പ്ലാറ്റ്ഫോം ടീം ഒരിക്കലും മറ്റൊരാളുടെ സേവനത്തിനായി റൂട്ടിംഗ് മാറ്റം അംഗീകരിക്കേണ്ടതില്ല. ആ വേർപിരിയലാണ് എനിക്ക് ഏറ്റവും ഇഷ്ടം. ടീമുകൾ എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്നതിന് ഇത് യോജിക്കുന്നു.

പകരം വയ്ക്കുന്നതിനെ തെരഞ്ഞെടുക്കുന്നു

ഗേറ്റ്വേ API ഒരു സ്പെസിഫിക്കേഷന് മാത്രമാണ്. അത് ഓടിക്കാൻ എന്തെങ്കിലും വേണം. നല്ല വാർത്ത, ധാരാളം നല്ല ഓപ്ഷനുകൾ ഉണ്ട് എന്നതാണ്.

• എംബസി ഗേറ്റ്വേനല്ലൊരു മുൻവാതിൽ വേണമെങ്കിൽ ശുദ്ധവും ശ്രദ്ധിച്ചതുമായ ഒരു തെരഞ്ഞെടുപ്പ്. മിക്ക ടീമുകൾക്കും എന്റെ മുൻനിശ്ചിത നിർദ്ദേശം.
• സിലിയം: നിങ്ങൾ ഇതിനകം ക്ലസ്റ്റർ നെറ്റ്വർക്കിംഗിനായി സിലിയം ഉപയോഗിക്കുന്നുവെങ്കിൽ അർത്ഥമുണ്ട്. ഒരു ഘടകം കുറവ്.
• ഇഷ്യോ: നിങ്ങൾ ഇതിനകം ഒരു സേവന മെഷ് പ്രവർത്തിപ്പിക്കുകയാണെങ്കിൽ, അല്ലെങ്കിൽ ആസൂത്രണം ചെയ്യുക.
• എൻ ജി എൻ എക്സ് ഗേറ്റ്വേ ട്രുക്ക് അല്ലെങ്കില് ട്രാഫിക്: നിങ്ങളുടെ ടീം ഇതിനകം അറിയാവുന്ന കാര്യങ്ങളുമായി അടുത്തു നിൽക്കണമെങ്കിൽ.
• നിങ്ങളുടെ ക്ലൌഡ് ദാതാവിന്റെ ഗേറ്റ്വേ: ജി. കെ. ഇ, എഡബ്ല്യു.എസ്. , അസ്യൂർ എന്നിവയ്ക്കും മാനേജ്ഡ് ഓപ്ഷനുകൾ ഉണ്ട്, അതായത് ഒരു കാര്യം കുറവ് പാച്ച് ചെയ്യണം.

ആഴ്ചകളോളം ബെഞ്ച്മാർക്ക് താരതമ്യം ചെയ്യരുത്. മിക്ക ക്ലസ്റ്ററുകളിലും, സത്യസന്ധമായ നിർണായക ചോദ്യം ഇതാണ്: എന്റെ ടീം ഇതിനകം എന്താണ് മനസ്സിലാക്കുന്നത്, മൂന്ന് വർഷത്തിനുള്ളിൽ നമ്മൾ ഇപ്പോഴും എന്താണ് നിലനിർത്തുന്നത്?

ഞാൻ എങ്ങനെ കുടിയേറുന്നു, പടിപടിയായി

വലിയ മാറ്റം വരുത്താതിരിക്കുക എന്നതാണ് തന്ത്രം. ഇരുവരും ഒരുമിച്ചു ഓടുക, ട്രാഫിക് പതുക്കെ നീക്കുക, പിന്നോട്ട് പോകരുത്.

1. അവലോകനം ചെയ്യുക. എല്ലാ ഇൻഗ്രേഡുകളും, അതിലും പ്രധാനമായി, ഉപയോഗത്തിലുള്ള എല്ലാ കുറിപ്പുകളും ലിസ്റ്റ് ചെയ്യുക. ഈ ഒറ്റ വരിയില് പെട്ടെന്ന് എണ്ണാന് സാധിക്കും:

bash kubectl get ingress -A -o yaml \ | grep -o 'nginx.ingress.kubernetes.io/[a-z-]*' \ | sort | uniq -c | sort -rn

ആ കുറിപ്പുകളിലാണ് യഥാർത്ഥ കൃതി ഒളിപ്പിച്ചിരിക്കുന്നത്.

2. പഴയതിന് അടുത്തായി പുതിയ നടപ്പിലാക്കല് ഇൻസ്റ്റാൾ ചെയ്യുക. അതിന് സ്വന്തമായി ലോഡ് ബാലൻസറും ഐ. പി. യും കിട്ടും. ഉപയോക്താക്കള് ക്ക് ഇതുവരെ ഒന്നും മാറിയിട്ടില്ല.

3. ഇന്ഗ്രെസ്2 ഗേറ്റ്വേ വഴി പരിവർത്തനം ചെയ്യുക. കുബർനെറ്റസ് പ്രോജക്ടിന്റെ സ്വന്തം ഉപകരണം 1.0 പതിപ്പിലേക്ക് 2026 മാർച്ചിൽ എത്തി. ഇത് നിങ്ങളുടെ നിലവിലുള്ള ഇൻഗ്രെസ്സ് റിസോഴ്സുകൾ വായിക്കുകയും ഗേറ്റ്വേ API തുല്യത എഴുതുകയും ചെയ്യുന്നു:

bash ingress2gateway print --providers=ingress-nginx \ --all-namespaces -o yaml > gateway-resources.yaml

ഉല് പ്പാദനം ഒരു ആദ്യ ഡ്രാഫ്റ്റ് ആയി കണക്കാക്കുക, അന്തിമ ഉത്തരമായിട്ടല്ല. ഒരു ട്രാക്ക് അഭ്യർത്ഥന പോലെ അത് അവലോകനം ചെയ്യുക.

4. ഉപകരണത്തിന് പറ്റാത്തത് കൈകൊണ്ട് ശരിയാക്കാം. ഇഷ്ടാനുസൃത സ്നിപ്പെറ്റുകൾ, ആധികാരികത, നിരക്ക് പരിമിതപ്പെടുത്തൽ, അസാധാരണമായ പുനർരൂപകൽപ്പനകൾ, റീജെക്സ് പാതകൾ എന്നിവ സാധാരണയായി മാനുവൽ ജോലിയാണ് ആവശ്യപ്പെടുന്നത്. അവയിൽ പലതും വ്യാഖ്യാനങ്ങളല്ല, നടപ്പാക്കലിന് പ്രത്യേകമായ നയങ്ങളായി മാറുന്നു.

5. ഡിഎൻഎസ് മാറ്റം വരുന്നതിനു മുമ്പ് പരിശോധിക്കുക. പുതിയ ഐ. പി. യിലേക്ക് നേരിട്ട് അഭ്യർത്ഥനകൾ അയയ്ക്കുകയും എല്ലാം പ്രവർത്തിക്കുന്നുണ്ടോ എന്ന് പരിശോധിക്കുകയും ചെയ്യുക:

bash curl --resolve shop.example.com:443:NEW_GATEWAY_IP \ https://shop.example.com/api/health

6. ട്രാഫിക് ക്രമേണ മാറ്റുക. ഒരു ദിവസം മുമ്പ് നിങ്ങളുടെ ഡിഎൻഎസ് ടിടിഎല്ലുകൾ കുറയ്ക്കുക, പിന്നെ ഒരു ഹോസ്റ്റ്നാമം ഒരു സമയത്ത് നീക്കുക, ഏറ്റവും പ്രധാനപ്പെട്ടത് ആരംഭിക്കുക. ഇന് ഗ്രെസ്-നിങ്നിക്സ് പ്രവർത്തിപ്പിക്കുക, അങ്ങനെ തിരികെ പോകുന്നത് ഒരു ഡിഎൻഎസ് മാറ്റം മാത്രമാണ്.

7. വൃത്തിയാക്കൂ. എല്ലാം ഒരു കാലത്തേക്ക് ശാന്തമായി നടക്കുമ്പോൾ, Ingress-nginx ഉം അതിന്റെ Ingress റിസോഴ്സുകളും നീക്കം ചെയ്യുക. അതിന്റെ ചുറ്റുമുള്ള ഉപകരണങ്ങളെ മറക്കരുത്: സെർട്ട് മാനേജറും എക്സ്റ്റേണൽ ഡിഎൻഎസും ഗേറ്റ്വേ API പിന്തുണയ്ക്കുന്നു, പക്ഷേ അവ ഇതിനായി ക്രമീകരിക്കേണ്ടതുണ്ട്.

കടിയ്ക്കാൻ സാധ്യതയുള്ളവ

ചില കാര്യങ്ങള് വളരെ എളുപ്പത്തില് നിസ്സാരമായി കാണാന് കഴിയും:

• ഒരു ചെറിയ കുറിപ്പ്. ആരെങ്കിലും എച്ച് ജി എൻ എക്സ് ക്രമീകരണം configuration-snippet വർഷങ്ങൾക്കു മുമ്പ്, നേരിട്ടുള്ള വിവർത്തനം ഇല്ലായിരുന്നു. ആദ്യം അത് എന്തിനുവേണ്ടിയാണെന്ന് കണ്ടുപിടിക്കണം. ചിലപ്പോള് ഉത്തരം "ഇനി ഒന്നും ഇല്ല" എന്നായിരിക്കും.
• വീണ്ടും എഴുതുന്നു. rewrite-target റെജെക്സ് ഗ്രൂപ്പുകൾ ഒന്നിലധികം മാപ്പ് ചെയ്യുന്നില്ല. ഓരോ പാതയും പരിശോധിക്കുക.
• ചെറിയ പെരുമാറ്റ വ്യത്യാസങ്ങള് . സ്ഥിരസ്ഥിതി ടൈം ഔട്ടുകൾ, ബോഡി സൈസ് പരിമിതികൾ, ഹെഡ്ഡർ കൈകാര്യം ചെയ്യൽ എന്നിവ നടപ്പാക്കലുകൾക്കിടയിൽ വ്യത്യാസപ്പെടുന്നു. "ഇപ്പോൾ മാത്രം പ്രവർത്തിച്ച" കാര്യങ്ങൾ പെട്ടെന്ന് 413 അല്ലെങ്കിൽ ടൈം ഔട്ട് ആയി മാറാം.
• ആരുടെ ഉടമസ്ഥതയിലുള്ളതാണ്. പുതിയ മോഡല് ഉത്തരവാദിത്തം ടീമുകള് ക്കിടയില് വിഭജിക്കുന്നു. അത് കൊള്ളാം, പക്ഷെ ഗേറ്റ്വേയുടെ ഉടമസ്ഥന് ആരാണെന്നും ഏത് നാമമേഖലകളാണ് അതിലേക്ക് റൂട്ടുകൾ ചേർക്കേണ്ടതെന്നും നിങ്ങൾ സമ്മതിച്ചിട്ടുണ്ടെങ്കിൽ മാത്രം.

ഇന്ന് മുതൽ ഞാൻ ആരോടെങ്കിലും പറയാനാഗ്രഹിക്കുന്നത്

പുതിയ ഒരു ക്ലസ്റ്റർ ഉണ്ടാക്കുകയാണെങ്കില് , ingress-nginx ഇൻസ്റ്റാൾ ചെയ്യരുത്, പുതിയ Ingress റിസോഴ്സുകൾ എഴുതരുത്. ആദ്യ ദിവസം മുതൽ ഗേറ്റ്വേ എപിഐ ഉപയോഗിച്ച് തുടങ്ങുക. ഈ ആശയങ്ങൾ പഠിക്കാൻ ഒരു ഉച്ചതിരിഞ്ഞ് എടുക്കും, ഈ മൈഗ്രേഷൻ നിങ്ങൾ ചെയ്യേണ്ടതില്ല.

നിങ്ങൾ കുബർനെറ്റസിനെ പഠിക്കുകയാണെങ്കിൽ, ഇത് തന്നെ ഒരു നല്ല പാഠമാണ്. മിക്കവാറും എല്ലാവരും ഉപയോഗിക്കുന്ന ഈ വിഭാഗത്തിലെ ഏറ്റവും ജനപ്രിയമായ പദ്ധതി, ക്ഷീണിച്ച ഒരുപിടി സന്നദ്ധപ്രവർത്തകർ പരിപാലിച്ചു. എന്തെങ്കിലും കെട്ടിപ്പടുക്കുന്നതിനു മുമ്പ്, അത് ജീവിച്ചിരിക്കാൻ സഹായിക്കുന്നത് ആരാണെന്ന് ചോദിക്കേണ്ടതാണ്.

അതുകൊണ്ട്, അത് പരിശ്രമത്തിന് വിലപ്പെട്ടതാണോ?

സത്യസന്ധമായി, അതെ, സുരക്ഷയ്ക്കായി മാത്രമല്ല. ഗേറ്റ്വേ എപിഐ ലളിതമായി മികച്ച മോഡലാണ്. ശുദ്ധമായ YAML, കുറവ് മാജിക് കുറിപ്പുകൾ, പ്ലാറ്റ്ഫോം, ആപ്ലിക്കേഷൻ ടീമുകൾ തമ്മിലുള്ള വ്യക്തമായ വിഭജനം, മുമ്പ് ഹാക്കുകൾ ആവശ്യമുള്ള സവിശേഷതകൾ ഇപ്പോൾ ഉൾപ്പെടുത്തിയിട്ടുണ്ട്.

വിരമിക്കൽ നമ്മളെ മിക്കവരെയും നിർബന്ധിക്കുന്നു. അടുത്ത വലിയ ദുർബലമായ സ്ഥലം പ്രഖ്യാപിക്കുന്ന ദിവസം തിരക്കിലല്ല, ശാന്തമായി ചെയ്യേണ്ടത് നല്ലതാണ്.

എന്റെ അഭിപ്രായം: വാതിൽ മാറി, പക്ഷേ ജോലി മാറിയില്ല. പ്ലാൻ ചെയ്യുക, രണ്ടാളും ചേർന്ന് ഓടുക, പതുക്കെ നടക്കുക, പിന്നോട്ട് പോകരുത്.

ഡെസ്ലി