የኩበርኔትስ ጠቃሚ ምክሮች እና ዘዴዎች፡ በNGINX እና PHP-FPM ውስጥ የሚያምሩ የመዝጊያ ባህሪያት

CI/CD በ Kubernetes ውስጥ ሲተገበር የተለመደ ሁኔታ፡ አፕሊኬሽኑ ሙሉ በሙሉ ከማቆሙ በፊት አዲስ የደንበኛ ጥያቄዎችን አለመቀበል መቻል አለበት እና ከሁሉም በላይ ደግሞ ነባሮቹን በተሳካ ሁኔታ ማጠናቀቅ አለበት።

ይህንን ሁኔታ ማክበር በተሰማራበት ጊዜ ዜሮ ጊዜን እንዲያሳኩ ይፈቅድልዎታል. ነገር ግን፣ በጣም ታዋቂ ጥቅሎችን (እንደ NGINX እና PHP-FPM) በሚጠቀሙበት ጊዜ እንኳን፣ በእያንዳንዱ ማሰማራት ብዙ ስህተቶችን የሚያስከትሉ ችግሮች ሊያጋጥሙዎት ይችላሉ።

ቲዎሪ. ፖድ እንዴት እንደሚኖር

ቀደም ሲል ስለ ፖድ የሕይወት ዑደት በዝርዝር አሳትመናል። ይህ ዓምድ. እየተገመገመ ባለው ርዕስ አውድ ውስጥ, እኛ ለሚከተሉት ፍላጎት አለን-በአሁኑ ጊዜ ፖድ ወደ ግዛት ውስጥ ሲገባ ማቋረጥ፣ አዲስ ጥያቄዎች ወደ እሱ መላክ አቁሟል (ፖድ ተወግዷል ለአገልግሎቱ የመጨረሻ ነጥቦች ዝርዝር). ስለዚህ, በሚሰማሩበት ጊዜ የእረፍት ጊዜን ለማስወገድ, ማመልከቻውን በትክክል የማቆምን ችግር ለመፍታት በቂ ነው.

እንዲሁም ነባሪው የእፎይታ ጊዜ መሆኑን ማስታወስ አለብዎት 30 ሰከንድከዚህ ጊዜ በኋላ ፖዱ ይቋረጣል እና ማመልከቻው ከዚህ ጊዜ በፊት ሁሉንም ጥያቄዎች ለማስኬድ ጊዜ ሊኖረው ይገባል ። አመለከተምንም እንኳን ከ5-10 ሰከንድ በላይ የሚወስድ ማንኛውም ጥያቄ ቀድሞውንም ችግር ያለበት ቢሆንም፣ እና በሚያምር ሁኔታ መዝጋት አይረዳውም...

ፖድ ሲያልቅ ምን እንደሚፈጠር በተሻለ ለመረዳት የሚከተለውን ንድፍ ይመልከቱ።

A1, B1 - ስለ ምድጃው ሁኔታ ለውጦችን መቀበል
A2 - መነሻ SIGTERM
B2 - ከጫፍ ነጥቦች ላይ ፖድ ማስወገድ
B3 - ለውጦችን መቀበል (የመጨረሻ ነጥቦች ዝርዝር ተቀይሯል)
B4 - የ iptables ደንቦችን ያዘምኑ

እባክዎን ያስተውሉ፡ የመጨረሻ ነጥብ ፖድ መሰረዝ እና SIGTERM መላክ በቅደም ተከተል አይደለም፣ ነገር ግን በትይዩ ነው። እና ኢንግረስ የተሻሻለውን የመጨረሻ ነጥብ ዝርዝር ወዲያውኑ ባለመቀበል ፣ ከደንበኞች የሚመጡ አዳዲስ ጥያቄዎች ወደ ፖድ ይላካሉ ፣ ይህም በፖድ ማብቂያ ጊዜ 500 ስህተት ያስከትላል ። (በዚህ ጉዳይ ላይ ለበለጠ ዝርዝር መረጃ እኛ ተተርጉሟል). ይህንን ችግር በሚከተሉት መንገዶች መፍታት ያስፈልጋል።

• ግንኙነት ላክ፡ በምላሽ ራስጌዎች ዝጋ (ይህ የኤችቲቲፒ መተግበሪያን የሚመለከት ከሆነ)።
• በኮዱ ላይ ለውጦችን ማድረግ የማይቻል ከሆነ የሚቀጥለው መጣጥፍ እስከ ጸጋው ጊዜ ማብቂያ ድረስ ጥያቄዎችን ለማስኬድ የሚያስችልዎትን መፍትሄ ይገልፃል።

ቲዎሪ. NGINX እና PHP-FPM ሂደታቸውን እንዴት እንደሚያቋርጡ

NGINX

በ NGINX እንጀምር ፣ ምክንያቱም ሁሉም ነገር የበለጠ ወይም ያነሰ ግልፅ ስለሆነ። ወደ ንድፈ ሃሳቡ ስንገባ፣ NGINX አንድ ዋና ሂደት እና በርካታ “ሰራተኞች” እንዳለው እንማራለን - እነዚህ የደንበኛ ጥያቄዎችን የሚያስኬዱ የልጅ ሂደቶች ናቸው። ምቹ አማራጭ ቀርቧል: ትዕዛዙን በመጠቀም nginx -s <SIGNAL> ሂደቶችን በፍጥነት በመዝጋት ወይም በሚያምር የመዝጋት ሁኔታ ያቋርጡ። እኛን የሚስበው የመጨረሻው አማራጭ እንደሆነ ግልጽ ነው።

ከዚያ ሁሉም ነገር ቀላል ነው: ወደ ላይ መጨመር ያስፈልግዎታል ቅድመ ማቆሚያ-መንጠቆ የሚያምር የመዝጊያ ምልክት የሚልክ ትእዛዝ። ይህ በማሰማራት ውስጥ ፣ በኮንቴይነር እገዳ ውስጥ ሊከናወን ይችላል-

       lifecycle:
          preStop:
            exec:
              command:
              - /usr/sbin/nginx
              - -s
              - quit

አሁን፣ ፖዱ ሲዘጋ፣ በ NGINX መያዣ ምዝግብ ማስታወሻዎች ውስጥ የሚከተሉትን እናያለን፡

2018/01/25 13:58:31 [notice] 1#1: signal 3 (SIGQUIT) received, shutting down
2018/01/25 13:58:31 [notice] 11#11: gracefully shutting down

እና ይሄ እኛ የሚያስፈልገንን ማለት ነው: NGINX ጥያቄዎችን እስኪጠናቀቅ ይጠብቃል, እና ሂደቱን ይገድለዋል. ሆኖም ፣ ከዚህ በታች በትእዛዙም እንኳን አንድ የተለመደ ችግርን እንመለከታለን nginx -s quit ሂደቱ በስህተት ያበቃል.

እና በዚህ ደረጃ በ NGINX እንጨርሰዋለን-ቢያንስ ከመዝገቦች ውስጥ ሁሉም ነገር እንደ ሁኔታው ​​እየሰራ መሆኑን መረዳት ይችላሉ.

ከ PHP-FPM ጋር ያለው ስምምነት ምንድን ነው? ግርማ ሞገስ ያለው መዘጋት እንዴት ያስተናግዳል? እስቲ እንገምተው።

PHP-FPM

በ PHP-FPM ሁኔታ፣ ትንሽ ያነሰ መረጃ አለ። ትኩረት ካደረግክ ኦፊሴላዊ መመሪያ በ PHP-FPM መሰረት፣ የሚከተሉት የPOSIX ምልክቶች ተቀባይነት እንዳላቸው ይናገራል፡-

1. SIGINT, SIGTERM - በፍጥነት መዘጋት;
2. SIGQUIT - የሚያምር መዘጋት (የምንፈልገው)።

በዚህ ተግባር ውስጥ የቀሩት ምልክቶች አያስፈልጉም, ስለዚህ ትንታኔያቸውን እንተዋለን. ሂደቱን በትክክል ለማቋረጥ፣ የሚከተለውን ቅድመ ማቆም መንጠቆ መፃፍ ያስፈልግዎታል።

        lifecycle:
          preStop:
            exec:
              command:
              - /bin/kill
              - -SIGQUIT
              - "1"

በአንደኛው እይታ, በሁለቱም መያዣዎች ውስጥ ሞገስ ያለው መዘጋት ለማከናወን የሚያስፈልገው ይህ ብቻ ነው. ይሁን እንጂ ሥራው ከሚመስለው የበለጠ ከባድ ነው. ከዚህ በታች በጸጋ መዘጋት ያልሰራባቸው እና በተሰማራበት ወቅት ፕሮጀክቱ ለአጭር ጊዜ እንዳይገኝ ያደረጉባቸው ሁለት ጉዳዮች አሉ።

ተለማመዱ። በጸጋ መዘጋት ሊሆኑ የሚችሉ ችግሮች

NGINX

በመጀመሪያ ደረጃ, ማስታወስ ጠቃሚ ነው: ትዕዛዙን ከማስፈጸም በተጨማሪ nginx -s quit ትኩረት ሊሰጠው የሚገባ አንድ ተጨማሪ ደረጃ አለ. NGINX አሁንም ከSIGQUIT ምልክት ይልቅ SIGTERM የሚልክበት ችግር አጋጥሞናል፣ ይህም ጥያቄዎች በትክክል እንዳይጠናቀቁ አድርጓል። ተመሳሳይ ጉዳዮች ሊገኙ ይችላሉ, ለምሳሌ, እዚህ. እንደ አለመታደል ሆኖ የዚህ ባህሪ ልዩ ምክንያት ምን እንደሆነ ማወቅ አልቻልንም፤ ስለ NGINX ስሪት ጥርጣሬ ነበር፣ ግን አልተረጋገጠም። ምልክቱ በ NGINX መያዣ ምዝግብ ማስታወሻዎች ውስጥ መልእክቶች ተስተውለዋል "ክፍት ሶኬት #10 በግንኙነት 5 ይቀራል", ከዚያ በኋላ ፖዱ ቆመ.

እንደዚህ አይነት ችግርን ማየት እንችላለን፣ ለምሳሌ፣ በምንፈልገው መግቢያ ላይ ካሉት ምላሾች፡-

በሚሰማሩበት ጊዜ የሁኔታ ኮዶች አመላካቾች

በዚህ አጋጣሚ፣ ከኢንግረስ እራሱ 503 የስህተት ኮድ ብቻ እንቀበላለን፡ ወደ NGINX መያዣው መድረስ አይችልም፣ ምክንያቱም ከአሁን በኋላ ተደራሽ አይደለም። የኮንቴይነር ምዝግብ ማስታወሻዎችን ከ NGINX ጋር ከተመለከቱ, የሚከተሉትን ይይዛሉ:

[alert] 13939#0: *154 open socket #3 left in connection 16
[alert] 13939#0: *168 open socket #6 left in connection 13

የማቆሚያ ምልክትን ከቀየሩ በኋላ መያዣው በትክክል ማቆም ይጀምራል: ይህ የተረጋገጠው የ 503 ስህተቱ ከአሁን በኋላ አለመታየቱ ነው.

ተመሳሳይ ችግር ካጋጠመዎት, በማጠራቀሚያው ውስጥ ምን የማቆሚያ ምልክት ጥቅም ላይ እንደሚውል እና የፕሬስ ማቆሚያ መንጠቆው በትክክል ምን እንደሚመስል ማወቅ ጠቃሚ ነው. ምክንያቱ በዚህ ውስጥ በትክክል ሊሆን ይችላል.

PHP-FPM... እና ተጨማሪ

በ PHP-FPM ላይ ያለው ችግር በጥቂቱ ይገለጻል-የልጆች ሂደቶችን እስኪጨርስ አይጠብቅም, ያቋርጣቸዋል, ለዚህም ነው 502 ስህተቶች በማሰማራት እና በሌሎች ስራዎች ላይ የሚከሰቱት. ከ2005 ጀምሮ በ bugs.php.net ላይ በርካታ የሳንካ ሪፖርቶች አሉ (ለምሳሌ፡ እዚህ и እዚህ), ይህንን ችግር የሚገልጸው. ግን ምናልባት በምዝግብ ማስታወሻዎች ውስጥ ምንም ነገር ላይታዩ ይችላሉ፡ ፒኤችፒ-ኤፍፒኤም ያለምንም ስህተቶች ወይም የሶስተኛ ወገን ማሳወቂያዎች ሂደቱን ማጠናቀቁን ያስታውቃል።

ችግሩ በራሱ በራሱ አፕሊኬሽኑ ላይ በጥቂቱም ሆነ በትልቁ ሊመካ እንደሚችል እና እራሱን ላያሳይ እንደማይችል ለምሳሌ በክትትል ውስጥ ግልጽ ማድረግ ተገቢ ነው። ካጋጠመህ መጀመሪያ ቀለል ያለ መፍትሄ ወደ አእምሮህ ይመጣል፡ በ preStop መንጠቆ ጨምር sleep(30). ከዚህ በፊት የነበሩትን ሁሉንም ጥያቄዎች እንዲያጠናቅቁ ይፈቅድልዎታል (እና አዳዲሶችን አንቀበልም ፣ ከፖድ ገና መቻል ማቋረጥ), እና ከ 30 ሰከንድ በኋላ ፖዱ ራሱ በምልክት ያበቃል SIGTERM.

እንደ እውነቱ ነው lifecycle መያዣው እንደዚህ ይመስላል

    lifecycle:
      preStop:
        exec:
          command:
          - /bin/sleep
          - "30"

ይሁን እንጂ በ 30 ሰከንድ ምክንያት sleep እኛ ነን በብርቱነት እያንዳንዱ ፖድ ስለሚቋረጥ የማሰማራቱን ጊዜ እንጨምራለን ዝቅተኛ 30 ሰከንድ, ይህም መጥፎ ነው. በዚህ ላይ ምን ሊደረግ ይችላል?

ለትግበራው ቀጥተኛ አፈፃፀም ተጠያቂ ወደሆነ አካል እንሂድ። በእኛ ሁኔታ ነው PHP-FPM, እሱም በነባሪነት የልጁን ሂደቶች አፈፃፀም አይቆጣጠርም።የማስተር ሂደቱ ወዲያውኑ ይቋረጣል. መመሪያውን ተጠቅመው ይህን ባህሪ መቀየር ይችላሉ። process_control_timeout, ይህም የልጁ ሂደቶች ከጌታው የሚመጡ ምልክቶችን ለመጠበቅ የጊዜ ገደቦችን ይገልጻል. እሴቱን ወደ 20 ሰከንድ ካስቀመጡት, ይህ በመያዣው ውስጥ የሚሄዱትን አብዛኛዎቹን ጥያቄዎች ይሸፍናል እና እንደጨረሱ ዋናውን ሂደት ያቆማል.

በዚህ እውቀት ወደ መጨረሻው ችግራችን እንመለስ። እንደተጠቀሰው, Kubernetes አንድ ነጠላ መድረክ አይደለም: በውስጡ የተለያዩ ክፍሎች መካከል መግባባት የተወሰነ ጊዜ ይወስዳል. በተለይም የ Ingresses እና ሌሎች ተዛማጅ አካላትን አሠራር ስናስብ ይህ እውነት ነው ፣ ምክንያቱም በተሰማሩበት ጊዜ እንደዚህ ባለ መዘግየት ምክንያት የ 500 ስህተቶችን ለማግኘት ቀላል ስለሆነ። ለምሳሌ ፣ ጥያቄን ወደላይ ወደላይ በመላክ ደረጃ ላይ ስህተት ሊከሰት ይችላል ፣ነገር ግን በንጥረ ነገሮች መካከል ያለው “የጊዜ መዘግየት” በጣም አጭር ነው - ከአንድ ሰከንድ በታች።

ስለዚህ, በጠቅላላው ቀደም ሲል ከተጠቀሰው መመሪያ ጋር process_control_timeout ለሚከተሉት ግንባታዎች መጠቀም ይችላሉ lifecycle:

lifecycle:
  preStop:
    exec:
      command: ["/bin/bash","-c","/bin/sleep 1; kill -QUIT 1"]

በዚህ አጋጣሚ በትእዛዙ መዘግየቱን እናካሳለን። sleep እና የማሰማራቱን ጊዜ በከፍተኛ ሁኔታ አይጨምሩ: በ 30 ሰከንድ እና በአንድ መካከል የሚታይ ልዩነት አለ? ... በእውነቱ, እሱ ነው. process_control_timeoutና lifecycle በማዘግየት ጊዜ እንደ "የደህንነት መረብ" ብቻ ጥቅም ላይ ይውላል.

በአጠቃላይ ሲናገሩ ፡፡ የተገለጸው ባህሪ እና ተጓዳኝ መፍትሄ በ PHP-FPM ላይ ብቻ አይደለም የሚሰራው።. ሌሎች ቋንቋዎችን/ማዕቀፎችን ሲጠቀሙ ተመሳሳይ ሁኔታ አንድ ወይም ሌላ ሊፈጠር ይችላል። ግርማ ሞገስ ያለው መዘጋት በሌሎች መንገዶች ማስተካከል ካልቻሉ - ለምሳሌ ፣ አፕሊኬሽኑ የማቋረጫ ምልክቶችን በትክክል እንዲያከናውን ኮዱን እንደገና በመፃፍ - የተገለጸውን ዘዴ መጠቀም ይችላሉ። በጣም ቆንጆ ላይሆን ይችላል, ግን ይሰራል.

ተለማመዱ። የፖዳውን አሠራር ለማረጋገጥ ሙከራን ይጫኑ

ይህ አሰራር ተጠቃሚዎች ጣቢያውን ሲጎበኙ ወደ እውነተኛ የውጊያ ሁኔታዎች ስለሚያቀርበው የጭነት መፈተሽ መያዣው እንዴት እንደሚሰራ ለማረጋገጥ አንዱ መንገድ ነው. ከላይ የተጠቀሱትን ምክሮች ለመሞከር, መጠቀም ይችላሉ Yandex.Tankom: ሁሉንም ፍላጎቶቻችንን በትክክል ይሸፍናል. ለግራፋና እና ለ Yandex.Tank ግራፎች ምስጋና ይግባው ከተሞክራችን ግልጽ በሆነ ምሳሌ ለመሞከር የሚከተሉት ምክሮች እና ምክሮች ናቸው።

እዚህ በጣም አስፈላጊው ነገር ነው ለውጦችን ደረጃ በደረጃ ያረጋግጡ. አዲስ ጥገና ካከሉ በኋላ ፈተናውን ያሂዱ እና ውጤቶቹ ከመጨረሻው ሩጫ ጋር ሲነፃፀሩ እንደተቀየሩ ይመልከቱ። አለበለዚያ, ውጤታማ ያልሆኑ መፍትሄዎችን መለየት አስቸጋሪ ይሆናል, እና በረጅም ጊዜ ውስጥ ጉዳቱ ብቻ ነው (ለምሳሌ, የማሰማራቱን ጊዜ ይጨምራል).

ሌላው ልዩነት ደግሞ በማለቁ ጊዜ የእቃ መያዢያ ምዝግብ ማስታወሻዎችን መመልከት ነው. ስለ ግርማ ሞገስ ያለው መዘጋት መረጃ እዚያ ተመዝግቧል? ሌሎች ግብዓቶችን (ለምሳሌ ወደ ጎረቤት ፒኤችፒ-ኤፍፒኤም መያዣ) ሲደርሱ በምዝግብ ማስታወሻዎች ውስጥ ስህተቶች አሉ? በመተግበሪያው ውስጥ ስህተቶች (ከላይ እንደተገለጸው በ NGINX ሁኔታ)? በዚህ ጽሑፍ ውስጥ ያለው የመግቢያ መረጃ መያዣው በሚቋረጥበት ጊዜ ምን እንደሚፈጠር በተሻለ ለመረዳት ይረዳዎታል ብዬ ተስፋ አደርጋለሁ.

ስለዚህ, የመጀመሪያው የፈተና ሩጫ ያለሱ ተካሂዷል lifecycle እና ለመተግበሪያው አገልጋይ ያለ ተጨማሪ መመሪያዎች (process_control_timeout በ PHP-FPM)። የዚህ ሙከራ አላማ ግምታዊውን የስህተቶች ብዛት (እና መኖራቸውን) መለየት ነው። እንዲሁም ከተጨማሪ መረጃ ለእያንዳንዱ ፖድ አማካይ የማሰማራት ጊዜ ሙሉ በሙሉ ዝግጁ እስኪሆን ድረስ ከ5-10 ሰከንድ ያህል እንደነበር ማወቅ አለቦት። ውጤቶቹ የሚከተሉት ናቸው፡-

የ Yandex.Tank መረጃ ፓኔል በተሰራበት ጊዜ የተከሰተ እና በአማካይ እስከ 502 ሰከንድ የሚቆይ የ 5 ስህተቶችን ፍጥነት ያሳያል. ይህ ሊሆን የቻለው ለአሮጌው ፖድ ነባር ጥያቄዎች በሚቋረጥበት ጊዜ በመቋረጡ ምክንያት ነው። ከዚህ በኋላ, 503 ስህተቶች ታይተዋል, ይህም የቆመው የ NGINX ኮንቴይነር ውጤት ነው, እሱም ደግሞ በጀርባው ምክንያት ግንኙነቶችን አቋርጧል (ይህም Ingress ከሱ ጋር እንዳይገናኝ ይከለክላል).

እንዴት እንደሆነ እንይ process_control_timeout በ PHP-FPM ውስጥ የልጅ ሂደቶችን እስኪጠናቀቅ እንድንጠብቅ ይረዳናል, ማለትም. እንደዚህ ያሉ ስህተቶችን ማረም. ይህንን መመሪያ በመጠቀም እንደገና ያሰማሩ፡-

በ 500 ኛው ማሰማራት ወቅት ምንም ተጨማሪ ስህተቶች የሉም! ማሰማራቱ የተሳካ ነው፣ ግርማ ሞገስ ያለው የመዝጋት ስራ ነው።

ሆኖም ግን, በጊዜ መዘግየት ምክንያት ልንቀበላቸው የምንችላቸው አነስተኛ መቶኛ ስህተቶች ከ Ingress ኮንቴይነሮች ጋር ያለውን ጉዳይ ማስታወስ ጠቃሚ ነው. እነሱን ለማስወገድ, የቀረውን መዋቅር ማከል ብቻ ነው sleep እና ማሰማራቱን ይድገሙት. ነገር ግን፣ በእኛ ሁኔታ፣ ምንም ለውጦች አልታዩም (እንደገና፣ ምንም ስህተቶች የሉም)።

መደምደሚያ

ሂደቱን በሚያምር ሁኔታ ለማቋረጥ፣ ከመተግበሪያው የሚከተለውን ባህሪ እንጠብቃለን።

1. ጥቂት ሰከንዶች ይጠብቁ እና ከዚያ አዲስ ግንኙነቶችን መቀበል ያቁሙ።
2. ሁሉም ጥያቄዎች እስኪያጠናቅቁ ድረስ ይጠብቁ እና ሁሉንም ጥያቄዎችን የማያስፈጽም ሁሉንም የቀጥታ ግንኙነቶችን ይዝጉ።
3. ሂደትህን ጨርስ።

ሆኖም ግን, ሁሉም መተግበሪያዎች በዚህ መንገድ ሊሠሩ አይችሉም. በኩበርኔትስ እውነታዎች ውስጥ ለችግሩ አንድ መፍትሄ የሚከተለው ነው-

• ጥቂት ሰከንዶች የሚጠብቅ ቅድመ-ማቆሚያ መንጠቆ መጨመር;
• ለተገቢው መመዘኛዎች የኛን የጀርባ አወቃቀሪያ ፋይል በማጥናት.

ከ NGINX ጋር ያለው ምሳሌ በመጀመሪያ የማቋረጫ ምልክቶችን በትክክል ማካሄድ ያለበት መተግበሪያ እንኳን ይህን ላያደርግ እንደሚችል ግልጽ ያደርገዋል፣ ስለዚህ በማመልከቻው ወቅት 500 ስህተቶችን መፈተሽ በጣም አስፈላጊ ነው። ይህ ደግሞ ችግሩን በስፋት እንዲመለከቱ እና በአንድ ፖድ ወይም ኮንቴይነር ላይ እንዳያተኩሩ ያስችልዎታል, ነገር ግን አጠቃላይ መሠረተ ልማቶችን በአጠቃላይ ይመልከቱ.

እንደ መሞከሪያ መሳሪያ Yandex.Tankን ከማንኛውም የክትትል ስርዓት ጋር በመተባበር መጠቀም ይችላሉ (በእኛ ሁኔታ መረጃ ከግራፋና የተወሰደው ከፕሮሜቲየስ ጀርባ ለሙከራ ነው)። በጸጋ መዘጋት ላይ ያሉ ችግሮች ቤንችማርክ በሚያመነጩት ከባድ ሸክሞች ውስጥ በግልጽ የሚታዩ ናቸው፣ እና ክትትል በፈተና ወቅት ወይም በኋላ ያለውን ሁኔታ በበለጠ ለመተንተን ይረዳል።

በአንቀጹ ላይ ለሚሰጠው አስተያየት-ችግሮቹ እና መፍትሄዎች እዚህ ከ NGINX Ingress ጋር የተገለጹ መሆናቸውን መጥቀስ ተገቢ ነው. ለሌሎች ጉዳዮች, ሌሎች መፍትሄዎች አሉ, በሚከተሉት ተከታታይ ቁሳቁሶች ውስጥ ልንመለከተው እንችላለን.

PS

ከK8s ተከታታይ ምክሮች እና ዘዴዎች ሌሎች፡-

• «ብጁ የስህተት ገጾች በNGINX Ingress ውስጥ";
• «ስለ አንጓዎች ድልድል እና በድር መተግበሪያ ላይ ስላሉት ጭነቶች";
• «የዴቪ ጣቢያዎች መዳረሻ";
• «ለትልቅ የውሂብ ጎታዎች የቡት ማሰሪያን ማፋጠን».

ምንጭ: hab.com