"કુબરનેટે લેટન્સીમાં 10 ગણો વધારો કર્યો": આ માટે કોણ દોષિત છે?

નૉૅધ. અનુવાદ: આ લેખ, ગેલો નાવારો દ્વારા લખાયેલો છે, જેઓ યુરોપીયન કંપની એડેવિન્ટામાં પ્રિન્સિપાલ સોફ્ટવેર એન્જિનિયરનો હોદ્દો ધરાવે છે, તે ઈન્ફ્રાસ્ટ્રક્ચર કામગીરીના ક્ષેત્રમાં એક રસપ્રદ અને ઉપદેશક "તપાસ" છે. તેનું મૂળ શીર્ષક અનુવાદમાં થોડું વિસ્તૃત કરવામાં આવ્યું હતું કારણ કે લેખક ખૂબ જ શરૂઆતમાં સમજાવે છે.

લેખક તરફથી નોંધ: આ પોસ્ટ જેવી લાગે છે આકર્ષિત અપેક્ષા કરતાં વધુ ધ્યાન. મને હજુ પણ ગુસ્સો આવે છે કે લેખનું શીર્ષક ભ્રામક છે અને કેટલાક વાચકો દુઃખી છે. હું શું થઈ રહ્યું છે તેના કારણોને સમજું છું, તેથી, સમગ્ર ષડયંત્રને બગાડવાનું જોખમ હોવા છતાં, હું તમને તરત જ કહેવા માંગુ છું કે આ લેખ શું છે. ટીમો કુબરનેટસમાં સ્થળાંતર કરતી વખતે મેં જોયેલી એક વિચિત્ર બાબત એ છે કે જ્યારે પણ કોઈ સમસ્યા ઊભી થાય છે (જેમ કે સ્થળાંતર પછી વિલંબમાં વધારો), સૌપ્રથમ દોષિત ઠરે છે તે કુબરનેટ્સ છે, પરંતુ પછી તે તારણ આપે છે કે ઓર્કેસ્ટ્રેટર ખરેખર આ માટે જવાબદાર નથી. દોષ આ લેખ આવા જ એક કિસ્સા વિશે જણાવે છે. તેનું નામ અમારા વિકાસકર્તાઓમાંના એકના ઉદ્ગારને પુનરાવર્તિત કરે છે (પછીથી તમે જોશો કે કુબરનેટ્સને તેની સાથે કોઈ લેવાદેવા નથી). તમને અહીં કુબરનેટ્સ વિશે કોઈ આશ્ચર્યજનક ખુલાસો મળશે નહીં, પરંતુ તમે જટિલ સિસ્ટમો વિશે થોડા સારા પાઠની અપેક્ષા રાખી શકો છો.

થોડા અઠવાડિયા પહેલા, મારી ટીમ એક જ માઇક્રોસર્વિસને કોર પ્લેટફોર્મ પર સ્થાનાંતરિત કરી રહી હતી જેમાં CI/CD, કુબરનેટ્સ-આધારિત રનટાઇમ, મેટ્રિક્સ અને અન્ય ગુડીઝનો સમાવેશ થતો હતો. આ પગલું અજમાયશ પ્રકૃતિનું હતું: અમે તેને એક આધાર તરીકે લેવાનું અને આગામી મહિનાઓમાં આશરે 150 વધુ સેવાઓ ટ્રાન્સફર કરવાની યોજના બનાવી છે. તે બધા સ્પેનના કેટલાક સૌથી મોટા ઓનલાઈન પ્લેટફોર્મ્સ (Infojobs, Fotocasa, વગેરે) ના સંચાલન માટે જવાબદાર છે.

અમે એપ્લીકેશનને કુબરનેટ્સ પર જમાવ્યું અને તેના પર કેટલાક ટ્રાફિકને રીડાયરેક્ટ કર્યા પછી, એક ભયજનક આશ્ચર્ય અમારી રાહ જોઈ રહ્યું હતું. વિલંબ (વિલંબતા) કુબરનેટ્સમાં વિનંતીઓ EC10 કરતાં 2 ગણી વધારે હતી. સામાન્ય રીતે, કાં તો આ સમસ્યાનો ઉકેલ શોધવો જરૂરી હતો, અથવા માઇક્રોસર્વિસ (અને, સંભવતઃ, સમગ્ર પ્રોજેક્ટ) નું સ્થળાંતર છોડી દેવું જરૂરી હતું.

EC2 કરતાં કુબરનેટ્સમાં વિલંબ શા માટે આટલો વધારે છે?

અડચણ શોધવા માટે, અમે સમગ્ર વિનંતી પાથ સાથે મેટ્રિક્સ એકત્રિત કર્યા. અમારું આર્કિટેક્ચર સરળ છે: API ગેટવે (Zuul) પ્રોક્સી EC2 અથવા Kubernetes માં માઇક્રોસર્વિસ ઇન્સ્ટન્સ માટે વિનંતી કરે છે. કુબરનેટ્સમાં આપણે NGINX ઇન્ગ્રેસ કંટ્રોલરનો ઉપયોગ કરીએ છીએ, અને બેકએન્ડ સામાન્ય વસ્તુઓ છે જેમ કે ડિપ્લોયમેન્ટ સ્પ્રિંગ પ્લેટફોર્મ પર JVM એપ્લિકેશન સાથે.

                                  EC2
                            +---------------+
                            |  +---------+  |
                            |  |         |  |
                       +-------> BACKEND |  |
                       |    |  |         |  |
                       |    |  +---------+  |                   
                       |    +---------------+
             +------+  |
Public       |      |  |
      -------> ZUUL +--+
traffic      |      |  |              Kubernetes
             +------+  |    +-----------------------------+
                       |    |  +-------+      +---------+ |
                       |    |  |       |  xx  |         | |
                       +-------> NGINX +------> BACKEND | |
                            |  |       |  xx  |         | |
                            |  +-------+      +---------+ |
                            +-----------------------------+

સમસ્યા બેકએન્ડમાં પ્રારંભિક લેટન્સી સાથે સંબંધિત હોય તેવું લાગતું હતું (મેં ગ્રાફ પર સમસ્યા વિસ્તારને "xx" તરીકે ચિહ્નિત કર્યો છે). EC2 પર, એપ્લિકેશનના પ્રતિભાવમાં લગભગ 20msનો સમય લાગ્યો. કુબરનેટ્સમાં, વિલંબતા વધીને 100-200 ms થઈ.

અમે રનટાઇમ ફેરફારથી સંબંધિત સંભવિત શંકાસ્પદોને ઝડપથી બરતરફ કરી દીધા. JVM સંસ્કરણ એ જ રહે છે. કન્ટેનરાઈઝેશનની સમસ્યાઓને પણ તેની સાથે કોઈ લેવાદેવા નહોતી: એપ્લિકેશન પહેલેથી જ EC2 પરના કન્ટેનરમાં સફળતાપૂર્વક ચાલી રહી હતી. લોડ કરી રહ્યું છે? પરંતુ અમે પ્રતિ સેકન્ડ 1 વિનંતી પર પણ ઉચ્ચ વિલંબ અવલોકન કર્યું. કચરો એકત્ર કરવા માટેના વિરામની પણ ઉપેક્ષા કરી શકાય છે.

અમારા કુબરનેટ્સ એડમિનમાંથી એકને આશ્ચર્ય થયું કે શું એપ્લિકેશનમાં બાહ્ય નિર્ભરતા છે કારણ કે DNS ક્વેરીઝ ભૂતકાળમાં સમાન સમસ્યાઓનું કારણ બની હતી.

પૂર્વધારણા 1: DNS નામ રિઝોલ્યુશન

દરેક વિનંતી માટે, અમારી એપ્લિકેશન AWS Elasticsearch દાખલાને એકથી ત્રણ વખત ડોમેનમાં એક્સેસ કરે છે જેમ કે elastic.spain.adevinta.com. અમારા કન્ટેનરની અંદર ત્યાં એક શેલ છે, જેથી અમે તપાસ કરી શકીએ કે ડોમેન શોધવામાં ખરેખર લાંબો સમય લાગે છે.

કન્ટેનરમાંથી DNS ક્વેરીઝ:

[root@be-851c76f696-alf8z /]# while true; do dig "elastic.spain.adevinta.com" | grep time; sleep 2; done
;; Query time: 22 msec
;; Query time: 22 msec
;; Query time: 29 msec
;; Query time: 21 msec
;; Query time: 28 msec
;; Query time: 43 msec
;; Query time: 39 msec

EC2 દાખલાઓમાંથી એકની સમાન વિનંતીઓ જ્યાં એપ્લિકેશન ચાલી રહી છે:

bash-4.4# while true; do dig "elastic.spain.adevinta.com" | grep time; sleep 2; done
;; Query time: 77 msec
;; Query time: 0 msec
;; Query time: 0 msec
;; Query time: 0 msec
;; Query time: 0 msec

લુકઅપમાં લગભગ 30ms જેટલો સમય લાગ્યો તે ધ્યાનમાં લેતા, તે સ્પષ્ટ થઈ ગયું કે Elasticsearch ને ઍક્સેસ કરતી વખતે DNS રિઝોલ્યુશન ખરેખર લેટન્સીમાં વધારો કરવામાં ફાળો આપી રહ્યું હતું.

જો કે, આ બે કારણોસર વિચિત્ર હતું:

1. અમારી પાસે પહેલેથી જ એક ટન કુબરનેટ્સ એપ્લીકેશન છે જે ઉચ્ચ વિલંબથી પીડાયા વિના AWS સંસાધનો સાથે ક્રિયાપ્રતિક્રિયા કરે છે. કારણ ગમે તે હોય, તે ખાસ કરીને આ કેસ સાથે સંબંધિત છે.
2. અમે જાણીએ છીએ કે JVM ઇન-મેમરી DNS કેશીંગ કરે છે. અમારી છબીઓમાં, TTL મૂલ્ય લખેલું છે $JAVA_HOME/jre/lib/security/java.security અને 10 સેકન્ડ પર સેટ કરો: networkaddress.cache.ttl = 10. બીજા શબ્દોમાં કહીએ તો, JVM એ તમામ DNS ક્વેરીઝને 10 સેકન્ડ માટે કેશ કરવી જોઈએ.

પ્રથમ પૂર્વધારણાની પુષ્ટિ કરવા માટે, અમે થોડા સમય માટે DNS કૉલ કરવાનું બંધ કરવાનું નક્કી કર્યું અને જુઓ કે સમસ્યા દૂર થઈ ગઈ છે કે નહીં. સૌપ્રથમ, અમે એપ્લિકેશનને પુનઃરૂપરેખાંકિત કરવાનું નક્કી કર્યું જેથી કરીને તે ડોમેન નામ દ્વારા નહીં, પરંતુ IP એડ્રેસ દ્વારા Elasticsearch સાથે સીધો સંપર્ક કરે. આના માટે કોડ ફેરફારો અને નવા જમાવટની જરૂર પડશે, તેથી અમે ફક્ત ડોમેનને તેના IP સરનામાં પર મેપ કર્યું /etc/hosts:

34.55.5.111 elastic.spain.adevinta.com

હવે કન્ટેનરને લગભગ તરત જ આઈપી મળ્યો. આના પરિણામે થોડો સુધારો થયો, પરંતુ અમે અપેક્ષિત વિલંબિતતા સ્તરોથી થોડા જ નજીક હતા. DNS રિઝોલ્યુશનમાં ઘણો સમય લાગ્યો હોવા છતાં, વાસ્તવિક કારણ હજી પણ અમને દૂર કર્યું.

નેટવર્ક દ્વારા ડાયગ્નોસ્ટિક્સ

અમે કન્ટેનરનો ઉપયોગ કરીને ટ્રાફિકનું વિશ્લેષણ કરવાનું નક્કી કર્યું tcpdumpનેટવર્ક પર બરાબર શું થઈ રહ્યું છે તે જોવા માટે:

[root@be-851c76f696-alf8z /]# tcpdump -leni any -w capture.pcap

અમે પછી ઘણી વિનંતીઓ મોકલી અને તેમના કેપ્ચર ડાઉનલોડ કર્યા (kubectl cp my-service:/capture.pcap capture.pcap) માં વધુ વિશ્લેષણ માટે વાયરહાર્ક.

DNS ક્વેરીઝ વિશે શંકાસ્પદ કંઈ નહોતું (એક નાની વસ્તુ સિવાય કે જેના વિશે હું પછીથી વાત કરીશ). પરંતુ અમારી સેવા જે રીતે દરેક વિનંતીને હેન્ડલ કરે છે તેમાં કેટલીક વિચિત્રતાઓ હતી. નીચે કેપ્ચરનો સ્ક્રીનશોટ છે જે દર્શાવે છે કે પ્રતિસાદ શરૂ થાય તે પહેલાં વિનંતી સ્વીકારવામાં આવી રહી છે:

પેકેજ નંબરો પ્રથમ કોલમમાં દર્શાવવામાં આવ્યા છે. સ્પષ્ટતા માટે, મેં વિવિધ TCP પ્રવાહોને રંગ-કોડ કર્યા છે.

પેકેટ 328 થી શરૂ થતી ગ્રીન સ્ટ્રીમ બતાવે છે કે કેવી રીતે ક્લાયન્ટ (172.17.22.150) એ કન્ટેનર (172.17.36.147) સાથે TCP કનેક્શન સ્થાપિત કર્યું. પ્રારંભિક હેન્ડશેક (328-330) પછી, પેકેજ 331 લાવવામાં આવ્યું HTTP GET /v1/.. - અમારી સેવા માટે આવનારી વિનંતી. આખી પ્રક્રિયામાં 1 એમએસનો સમય લાગ્યો.

ગ્રે સ્ટ્રીમ (પેકેટ 339 માંથી) બતાવે છે કે અમારી સેવાએ ઈલાસ્ટિકસર્ચ ઈન્સ્ટન્સને HTTP વિનંતી મોકલી છે (ત્યાં કોઈ TCP હેન્ડશેક નથી કારણ કે તે હાલના કનેક્શનનો ઉપયોગ કરી રહ્યું છે). આને 18ms લીધો.

અત્યાર સુધી બધું બરાબર છે, અને સમય અંદાજે અપેક્ષિત વિલંબને અનુરૂપ છે (ક્લાયન્ટ પાસેથી માપવામાં આવે ત્યારે 20-30 ms).

જો કે, વાદળી વિભાગ 86ms લે છે. એમાં શું ચાલી રહ્યું છે? પેકેટ 333 સાથે, અમારી સેવાએ HTTP GET વિનંતી મોકલી /latest/meta-data/iam/security-credentials, અને તેના પછી તરત જ, સમાન TCP કનેક્શન પર, બીજી GET વિનંતી /latest/meta-data/iam/security-credentials/arn:...

અમને જાણવા મળ્યું કે આ સમગ્ર ટ્રેસ દરમિયાન દરેક વિનંતી સાથે પુનરાવર્તિત થાય છે. DNS રિઝોલ્યુશન ખરેખર અમારા કન્ટેનરમાં થોડું ધીમું છે (આ ઘટના માટેનું સમજૂતી ખૂબ જ રસપ્રદ છે, પરંતુ હું તેને એક અલગ લેખ માટે સાચવીશ). તે બહાર આવ્યું છે કે લાંબા વિલંબનું કારણ દરેક વિનંતી પર AWS ઇન્સ્ટન્સ મેટાડેટા સેવા પર કૉલ્સ હતા.

પૂર્વધારણા 2: AWS ને બિનજરૂરી કોલ્સ

બંને અંતિમ બિંદુઓ સંબંધિત છે AWS ઇન્સ્ટન્સ મેટાડેટા API. Elasticsearch ચલાવતી વખતે અમારી માઇક્રોસર્વિસ આ સેવાનો ઉપયોગ કરે છે. બંને કૉલ મૂળભૂત અધિકૃતતા પ્રક્રિયાનો ભાગ છે. પ્રથમ વિનંતિ પર એક્સેસ થયેલ એન્ડપોઇન્ટ દાખલા સાથે સંકળાયેલ IAM ભૂમિકાને ઇશ્યૂ કરે છે.

/ # curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
arn:aws:iam::<account_id>:role/some_role

બીજી વિનંતી આ ઉદાહરણ માટે અસ્થાયી પરવાનગીઓ માટે બીજા અંતિમ બિંદુને પૂછે છે:

/ # curl http://169.254.169.254/latest/meta-data/iam/security-credentials/arn:aws:iam::<account_id>:role/some_role`
{
    "Code" : "Success",
    "LastUpdated" : "2012-04-26T16:39:16Z",
    "Type" : "AWS-HMAC",
    "AccessKeyId" : "ASIAIOSFODNN7EXAMPLE",
    "SecretAccessKey" : "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
    "Token" : "token",
    "Expiration" : "2017-05-17T15:09:54Z"
}

ક્લાયંટ તેનો ઉપયોગ ટૂંકા ગાળા માટે કરી શકે છે અને સમયાંતરે નવા પ્રમાણપત્રો (તેઓ હોય તે પહેલાં) મેળવવા જ જોઈએ Expiration). મોડલ સરળ છે: AWS સુરક્ષા કારણોસર અવારનવાર અસ્થાયી કીને ફેરવે છે, પરંતુ નવા પ્રમાણપત્રો મેળવવા સાથે સંકળાયેલ પ્રદર્શન દંડની ભરપાઈ કરવા માટે ક્લાયન્ટ તેને થોડી મિનિટો માટે કેશ કરી શકે છે.

AWS Java SDK એ આ પ્રક્રિયાને ગોઠવવાની જવાબદારી લેવી જોઈએ, પરંતુ કેટલાક કારણોસર આવું થતું નથી.

GitHub પર સમસ્યાઓ શોધ્યા પછી, અમને એક સમસ્યા આવી #1921. તેણીએ અમને આગળ કઈ દિશામાં "ખોદવું" તે નક્કી કરવામાં મદદ કરી.

AWS SDK પ્રમાણપત્રોને અપડેટ કરે છે જ્યારે નીચેની શરતોમાંથી એક થાય છે:

• અંતિમ તારીખ (Expiration) માં પડવું EXPIRATION_THRESHOLD, 15 મિનિટ માટે હાર્ડકોડ.
• પ્રમાણપત્રો રિન્યુ કરવાના છેલ્લા પ્રયાસ કરતાં વધુ સમય વીતી ગયો છે REFRESH_THRESHOLD, 60 મિનિટ માટે હાર્ડકોડ.

અમને મળતા પ્રમાણપત્રોની વાસ્તવિક સમાપ્તિ તારીખ જોવા માટે, અમે કન્ટેનર અને EC2 ઉદાહરણ બંનેમાંથી ઉપરોક્ત cURL આદેશો ચલાવ્યા. કન્ટેનરમાંથી પ્રાપ્ત પ્રમાણપત્રની માન્યતા અવધિ ઘણી ટૂંકી હોવાનું બહાર આવ્યું છે: બરાબર 15 મિનિટ.

હવે બધું સ્પષ્ટ થઈ ગયું છે: પ્રથમ વિનંતી માટે, અમારી સેવાને અસ્થાયી પ્રમાણપત્રો પ્રાપ્ત થયા છે. તેઓ 15 મિનિટથી વધુ સમય માટે માન્ય ન હોવાથી, AWS SDK તેમને અનુગામી વિનંતી પર અપડેટ કરવાનું નક્કી કરશે. અને આ દરેક વિનંતી સાથે થયું.

પ્રમાણપત્રોની માન્યતા અવધિ કેમ ટૂંકી થઈ ગઈ છે?

AWS ઇન્સ્ટન્સ મેટાડેટા EC2 ઇન્સ્ટન્સ સાથે કામ કરવા માટે રચાયેલ છે, કુબરનેટ્સ સાથે નહીં. બીજી બાજુ, અમે એપ્લિકેશન ઇન્ટરફેસ બદલવા માંગતા ન હતા. આ માટે અમે ઉપયોગ કર્યો કિયામ - એક સાધન કે જે, દરેક કુબરનેટ્સ નોડ પર એજન્ટોનો ઉપયોગ કરીને, વપરાશકર્તાઓને (એપ્લીકેશનને ક્લસ્ટરમાં જમાવતા એન્જીનીયરો) પોડ્સમાં કન્ટેનરને IAM ભૂમિકાઓ સોંપવા માટે પરવાનગી આપે છે જાણે કે તેઓ EC2 દાખલાઓ હોય. KIAM AWS ઇન્સ્ટન્સ મેટાડેટા સેવા પરના કૉલ્સને અટકાવે છે અને તેને તેના કેશમાંથી પ્રક્રિયા કરે છે, અગાઉ તેને AWS માંથી પ્રાપ્ત કરે છે. એપ્લિકેશનના દૃષ્ટિકોણથી, કંઈપણ બદલાતું નથી.

KIAM પોડ્સને ટૂંકા ગાળાના પ્રમાણપત્રો પૂરા પાડે છે. પોડનું સરેરાશ આયુષ્ય EC2 ઉદાહરણ કરતાં ઓછું હોય છે તે ધ્યાનમાં લેતા આનો અર્થ થાય છે. પ્રમાણપત્રો માટે ડિફૉલ્ટ માન્યતા અવધિ સમાન 15 મિનિટ.

પરિણામે, જો તમે બંને ડિફૉલ્ટ મૂલ્યોને એકબીજાની ટોચ પર ઓવરલે કરો છો, તો સમસ્યા ઊભી થાય છે. એપ્લિકેશનને આપવામાં આવેલ દરેક પ્રમાણપત્ર 15 મિનિટ પછી સમાપ્ત થાય છે. જો કે, AWS Java SDK કોઈપણ પ્રમાણપત્રના નવીકરણ માટે દબાણ કરે છે જેની સમાપ્તિ તારીખ પહેલાં 15 મિનિટ કરતાં ઓછી બાકી હોય.

પરિણામે, અસ્થાયી પ્રમાણપત્રને દરેક વિનંતી સાથે નવીકરણ કરવાની ફરજ પાડવામાં આવે છે, જે AWS API પર થોડા કૉલ્સનો સમાવેશ કરે છે અને લેટન્સીમાં નોંધપાત્ર વધારો કરે છે. AWS Java SDK માં અમને મળ્યું લક્ષણ વિનંતી, જે સમાન સમસ્યાનો ઉલ્લેખ કરે છે.

ઉકેલ સરળ હોવાનું બહાર આવ્યું. લાંબી માન્યતા અવધિ સાથે પ્રમાણપત્રોની વિનંતી કરવા માટે અમે ફક્ત KIAM ને ફરીથી ગોઠવ્યું છે. એકવાર આ બન્યું, AWS મેટાડેટા સેવાની ભાગીદારી વિના વિનંતીઓ વહેવા લાગી, અને લેટન્સી EC2 કરતાં પણ નીચા સ્તરે આવી ગઈ.

તારણો

સ્થળાંતર સાથેના અમારા અનુભવના આધારે, સમસ્યાઓના સૌથી સામાન્ય સ્ત્રોતોમાંનું એક કુબરનેટ્સ અથવા પ્લેટફોર્મના અન્ય ઘટકોમાં ભૂલો નથી. અમે પોર્ટ કરી રહ્યાં છીએ તે માઇક્રોસર્વિસિસમાં તે કોઈપણ મૂળભૂત ખામીઓને પણ સંબોધિત કરતું નથી. સમસ્યાઓ ઘણીવાર ઊભી થાય છે કારણ કે આપણે વિવિધ તત્વોને એકસાથે મૂકીએ છીએ.

અમે જટિલ પ્રણાલીઓને એકસાથે ભેળવીએ છીએ જે અગાઉ ક્યારેય એકબીજા સાથે ક્રિયાપ્રતિક્રિયા કરી નથી, એવી અપેક્ષા રાખીએ છીએ કે તેઓ સાથે મળીને એક, મોટી સિસ્ટમ બનાવશે. અરે, વધુ તત્વો, ભૂલો માટે વધુ જગ્યા, એન્ટ્રોપી વધારે.

અમારા કિસ્સામાં, ઉચ્ચ વિલંબ એ Kubernetes, KIAM, AWS Java SDK અથવા અમારી માઇક્રોસર્વિસમાં ભૂલો અથવા ખરાબ નિર્ણયોનું પરિણામ ન હતું. તે બે સ્વતંત્ર ડિફોલ્ટ સેટિંગ્સને સંયોજિત કરવાનું પરિણામ હતું: એક KIAM માં, બીજી AWS Java SDK માં. અલગથી લેવામાં આવે તો, બંને પરિમાણો અર્થપૂર્ણ છે: AWS Java SDK માં સક્રિય પ્રમાણપત્ર નવીકરણ નીતિ અને KAIM માં પ્રમાણપત્રોની ટૂંકી માન્યતા અવધિ. પરંતુ જ્યારે તમે તેમને એકસાથે મૂકો છો, ત્યારે પરિણામો અણધારી બની જાય છે. બે સ્વતંત્ર અને તાર્કિક ઉકેલો જ્યારે જોડવામાં આવે ત્યારે તેનો કોઈ અર્થ નથી.

અનુવાદક તરફથી પીએસ

તમે AWS IAM ને કુબરનેટ્સ સાથે સંકલિત કરવા માટે KIAM ઉપયોગિતાના આર્કિટેક્ચર વિશે વધુ અહીં જાણી શકો છો આ લેખ તેના સર્જકો પાસેથી.

અમારા બ્લોગ પર પણ વાંચો:

• «ઉત્પાદનમાં કુબરનેટીસની નિષ્ફળતાની 3 વાર્તાઓ: એન્ટિ-એફિનિટી, આકર્ષક શટડાઉન, વેબહૂક»;
• «કેવી રીતે કુબરનેટ્સમાં પોડ પ્રાથમિકતાઓને કારણે ગ્રાફના લેબ્સમાં ડાઉનટાઇમ થયો»;
• «કુબરનેટ્સના સંચાલનમાં 6 મનોરંજક સિસ્ટમ બગ્સ [અને તેમના ઉકેલ]»;
• «અમારા SRE રોજિંદા જીવનમાંથી 6 વ્યવહારુ વાર્તાઓ».

સોર્સ: www.habr.com