ProHoster > Blogs > Administrācija > 10 izplatītākās kļūdas, lietojot Kubernetes

10 izplatītākās kļūdas, lietojot Kubernetes

PiezÄ«me. tulk.: Å Ä« raksta autori ir inženieri no neliela Čehijas uzņēmuma pipetail. Viņiem izdevās salikt brÄ«niŔķīgu sarakstu ar [dažkārt banālām, bet tomēr] ļoti aktuālām problēmām un maldÄ«giem priekÅ”statiem saistÄ«bā ar Kubernetes klasteru darbÄ«bu.

10 izplatītākās kļūdas, lietojot Kubernetes

Kubernetes lietoÅ”anas gadu laikā esam strādājuÅ”i ar lielu skaitu klasteru (gan pārvaldÄ«tu, gan nepārvaldÄ«tu ā€” GCP, AWS un Azure). Laika gaitā mēs sākām pamanÄ«t, ka dažas kļūdas tiek pastāvÄ«gi atkārtotas. Tomēr par to nav kauna: lielāko daļu no tiem esam izdarÄ«juÅ”i paÅ”i!

Rakstā ir apkopotas biežāk sastopamās kļūdas, kā arī minēts, kā tās labot.

1. Resursi: pieprasījumi un ierobežojumi

Šis vienums noteikti ir pelnījis vislielāko uzmanību un pirmo vietu sarakstā.

CPU pieprasījums parasti vai nu vispār nav norādīts, vai arī ir ļoti zema vērtība (lai uz katra mezgla novietotu pēc iespējas vairāk pākstīm). Tādējādi mezgli kļūst pārslogoti. Augstas slodzes laikā mezgla apstrādes jauda tiek pilnībā izmantota, un konkrēta darba slodze saņem tikai to, ko tā "pieprasīja" CPU drosele. Tas palielina lietojumprogrammas latentumu, taimautus un citas nepatīkamas sekas. (Vairāk par to lasiet citā mūsu nesenajā tulkojumā: "CPU ierobežojumi un agresīva droseles Kubernetes"- apm. tulk.)

BestEffort (ārkārtīgi nē ieteicams):

resources: {}

Ļoti zems CPU pieprasījums (ārkārtīgi nē ieteicams):

   resources:
      Requests:
        cpu: "1m"

No otras puses, CPU ierobežojuma klātbÅ«tne var izraisÄ«t nepamatotu pulksteņa ciklu izlaiÅ”anu, pat ja mezgla procesors nav pilnÄ«bā noslogots. Atkal, tas var palielināt kavÄ“Å”anos. Par parametru turpinās strÄ«di CPU CFS kvota Linux kodolā un CPU droselÄ“Å”ana atkarÄ«bā no iestatÄ«tajiem limitiem, kā arÄ« CFS kvotas atspējoÅ”ana... Ak, CPU ierobežojumi var radÄ«t vairāk problēmu nekā atrisināt. PlaŔāku informāciju par to var atrast zemāk esoÅ”ajā saitē.

PārmērÄ«ga atlase (pārapņemÅ”anās) atmiņas problēmas var izraisÄ«t lielākas problēmas. CPU ierobežojuma sasniegÅ”ana nozÄ«mē pulksteņa ciklu izlaiÅ”anu, savukārt atmiņas ierobežojuma sasniegÅ”ana nozÄ«mē podziņa nogalināŔanu. Vai esat kādreiz novērojuÅ”i OOMkill? Jā, tieÅ”i par to mēs runājam.

Vai vēlaties samazināt tā iespējamÄ«bu? Nepārslogojiet atmiņu un izmantojiet garantēto QoS (pakalpojuma kvalitāti), iestatot atmiņas pieprasÄ«juma ierobežojumu (kā tālāk esoÅ”ajā piemērā). Vairāk par to lasiet sadaļā Heninga Džeikobsa prezentācijas (Zalando vadoÅ”ais inženieris).

PārsprāgstoÅ”s (lielāka iespēja tikt nogalinātam OOM):

   resources:
      requests:
        memory: "128Mi"
        cpu: "500m"
      limits:
        memory: "256Mi"
        cpu: 2

Garantētā:

   resources:
      requests:
        memory: "128Mi"
        cpu: 2
      limits:
        memory: "128Mi"
        cpu: 2

Kas potenciāli palīdzēs, veidojot resursus?

Ar metrika-serveris jÅ«s varat redzēt paÅ”reizējo CPU resursu patēriņu un atmiņas lietojumu pa podiem (un tajos esoÅ”ajiem konteineriem). Visticamāk, jÅ«s to jau izmantojat. VienkārÅ”i palaidiet Ŕādas komandas:

kubectl top pods
kubectl top pods --containers
kubectl top nodes

Tomēr tie parāda tikai paÅ”reizējo lietojumu. Tas var sniegt jums aptuvenu priekÅ”statu par lieluma secÄ«bu, bet galu galā jums tas bÅ«s nepiecieÅ”ams metrikas izmaiņu vēsture laika gaitā (lai atbildētu uz tādiem jautājumiem kā: ā€œKāda bija maksimālā CPU slodze?ā€, ā€œKāda bija slodze vakar no rÄ«ta?ā€ utt.). Å im nolÅ«kam jÅ«s varat izmantot Prometejs, DataDog un citi instrumenti. Viņi vienkārÅ”i iegÅ«st metriku no metriku servera un saglabā tos, un lietotājs var tos vaicāt un attiecÄ«gi uzzÄ«mēt.

VerticalPodAutoscaler pieļauj automatizēt Å”o procesu. Tas izseko CPU un atmiņas lietojuma vēsturi un iestata jaunus pieprasÄ«jumus un ierobežojumus, pamatojoties uz Å”o informāciju.

EfektÄ«va skaitļoÅ”anas jaudas izmantoÅ”ana nav viegls uzdevums. Tas ir tāpat kā visu laiku spēlēt Tetris. Ja maksājat pārāk daudz par skaitļoÅ”anas jaudu ar zemu vidējo patēriņu (teiksim, ~10%), iesakām apskatÄ«t produktus, kuru pamatā ir AWS Fargate vai Virtual Kubelet. Tie ir balstÄ«ti uz bezservera/pay-per-usage norēķinu modeli, kas Ŕādos apstākļos var izrādÄ«ties lētāks.

2. Dzīvības un gatavības zondes

Pēc noklusējuma dzīvīguma un gatavības pārbaudes programmā Kubernetes nav iespējotas. Un dažreiz viņi aizmirst tos ieslēgt...

Bet kā citādi jÅ«s varat sākt pakalpojuma restartÄ“Å”anu fatālas kļūdas gadÄ«jumā? Un kā slodzes balansētājs zina, ka pods ir gatavs satiksmei? Vai arÄ« tas spēj apkalpot lielāku trafiku?

Šie testi bieži tiek sajaukti viens ar otru:

  • DzÄ«vÄ«gums ā€” ā€œizdzÄ«vojamÄ«basā€ pārbaude, kas atsāk podziņu, ja tā neizdodas;
  • GatavÄ«ba ā€” gatavÄ«bas pārbaude, ja neizdodas, tas atvieno pod no Kubernetes pakalpojuma (to var pārbaudÄ«t, izmantojot kubectl get endpoints), un satiksme uz to neierodas, kamēr nākamā pārbaude nav veiksmÄ«gi pabeigta.

Abas Ŕīs pārbaudes VEIKTS VISA PODAS DZÄŖVES CIKLA LAIKĀ. Tas ir ļoti svarÄ«gi.

IzplatÄ«ts nepareizs uzskats ir tāds, ka gatavÄ«bas zondes tiek palaistas tikai startÄ“Å”anas laikā, lai balansētājs varētu zināt, ka pods ir gatavs (Ready) un var sākt apstrādāt trafiku. Tomēr Ŕī ir tikai viena no to izmantoÅ”anas iespējām.

Vēl viena ir iespēja noskaidrot, ka satiksme uz pod ir pārmērÄ«ga un pārslogo to (vai pods veic resursietilpÄ«gus aprēķinus). Å ajā gadÄ«jumā palÄ«dz gatavÄ«bas pārbaude samaziniet pāksts slodzi un "atdzesējiet".. VeiksmÄ«ga gatavÄ«bas pārbaudes pabeigÅ”ana nākotnē ļauj atkal palielināt slodzi uz pāksts. Å ajā gadÄ«jumā (ja gatavÄ«bas pārbaude neizdodas), dzÄ«vÄ«guma pārbaudes neveiksme bÅ«tu ļoti neproduktÄ«va. Kāpēc restartēt ierÄ«ci, kas ir veselÄ«ga un smagi strādā?

Tāpēc dažos gadÄ«jumos ir labāk neveikt pārbaudes, nekā iespējot tās ar nepareizi konfigurētiem parametriem. Kā minēts iepriekÅ”, ja dzÄ«vÄ«guma pārbaude kopijas gatavÄ«bas pārbaude, tad jums ir lielas nepatikÅ”anas. Iespējamā iespēja ir konfigurēt tikai gatavÄ«bas pārbaudeUn bÄ«stams dzÄ«vÄ«gums atstāt malā.

Abiem pārbaužu veidiem nevajadzētu neizdoties, ja neizdodas izplatīt parastās atkarības, pretējā gadījumā tas novedīs pie kaskādes (lavīnai līdzīgas) visu apgabalu atteices. Citiem vārdiem sakot, nekaitējiet sev.

3. LoadBalancer katram HTTP pakalpojumam

Visticamāk, jūsu klasterī ir HTTP pakalpojumi, kurus vēlaties pārsūtīt uz ārpasauli.

Ja atverat pakalpojumu kā type: LoadBalancer, tā kontrolieris (atkarÄ«bā no pakalpojumu sniedzēja) nodroÅ”inās un vienosies par ārēju LoadBalancer (ne vienmēr darbojas L7, bet drÄ«zāk pat L4), un tas var ietekmēt izmaksas (ārējā statiskā IPv4 adrese, skaitļoÅ”anas jauda, ā€‹ā€‹norēķini par sekundi ), jo ir nepiecieÅ”ams izveidot lielu skaitu Ŕādu resursu.

Å ajā gadÄ«jumā daudz loÄ£iskāk ir izmantot vienu ārējo slodzes balansētāju, atverot pakalpojumus kā type: NodePort. Vai vēl labāk, izvērsiet kaut ko lÄ«dzÄ«gu nginx-ingress-controller (Vai traefik), kurÅ” bÅ«s vienÄ«gais Mezglu ports galapunkts, kas saistÄ«ts ar ārējo slodzes balansētāju un marÅ”rutēs trafiku klasterÄ«, izmantojot iekļūŔana-Kubernetes resursi.

Citi klastera iekŔējie (mikro) pakalpojumi, kas mijiedarbojas viens ar otru, var ā€œsazinātiesā€, izmantojot tādus pakalpojumus kā ClusterIP un iebÅ«vēts pakalpojumu atklāŔanas mehānisms, izmantojot DNS. VienkārÅ”i neizmantojiet viņu publisko DNS/IP, jo tas var ietekmēt latentumu un palielināt mākoņpakalpojumu izmaksas.

4. Klastera automātiskā mērogoÅ”ana, neņemot vērā tā Ä«paŔības

Pievienojot mezglus klasterim un noņemot tos no tā, jums nevajadzētu paļauties uz dažiem pamata rādÄ«tājiem, piemēram, CPU lietojumu Å”ajos mezglos. Pod plānoÅ”anā ir jāņem vērā daudzi ierobežojumiem, piemēram, pod/mezglu afinitāte, bojājumi un pielaides, resursu pieprasÄ«jumi, QoS utt. Izmantojot ārēju autoscaler, kas neņem vērā Ŕīs nianses, var rasties problēmas.

Iedomājieties, ka ir jāieplāno noteikts pods, bet tiek pieprasÄ«ta/izjaukta visa pieejamā CPU jauda un pods iestrēgst stāvoklÄ« Pending. Ārējais automātiskais mērogoÅ”anas lÄ«dzeklis redz vidējo paÅ”reizējo CPU slodzi (nevis pieprasÄ«to) un neuzsāk paplaÅ”ināŔanu (palielināt) - nepievieno vēl vienu mezglu. Rezultātā Ŕī podziņa netiks ieplānota.

Å ajā gadÄ«jumā apgrieztā mērogoÅ”ana (pielāgots) ā€” mezgla noņemÅ”ana no klastera vienmēr ir grÅ«tāk Ä«stenojama. Iedomājieties, ka jums ir stāvokļi (ar pievienotu pastāvÄ«go krātuvi). PastāvÄ«gi apjomi parasti pieder Ä«paÅ”a pieejamÄ«bas zona un netiek replicēti reÄ£ionā. Tādējādi, ja ārējs automātiskais mērogoÅ”anas lÄ«dzeklis izdzÄ“Å” mezglu ar Å”o aplikumu, plānotājs nevarēs ieplānot Å”o aplikumu citā mezglā, jo to var izdarÄ«t tikai pieejamÄ«bas zonā, kurā atrodas pastāvÄ«gā krātuve. Pod bÅ«s iestrēdzis stāvoklÄ« Pending.

Ä»oti populārs Kubernetes kopienā klasteris-autoscaler. Tas darbojas klasterÄ«, atbalsta API no galvenajiem mākoņpakalpojumu sniedzējiem, ņem vērā visus ierobežojumus un var mērogot iepriekÅ”minētajos gadÄ«jumos. To var arÄ« paplaÅ”ināt, vienlaikus saglabājot visus noteiktos ierobežojumus, tādējādi ietaupot naudu (kas pretējā gadÄ«jumā tiktu tērēta neizmantotai jaudai).

5. IAM/RBAC iespēju neievēroÅ”ana

Uzmanieties no IAM lietotāju izmantoÅ”anas ar pastāvÄ«giem noslēpumiem maŔīnas un lietojumprogrammas. Organizējiet pagaidu piekļuvi, izmantojot lomas un pakalpojumu kontus (pakalpojumu konti).

Mēs bieži sastopamies ar faktu, ka piekļuves atslēgas (un noslēpumi) ir iekodētas lietojumprogrammas konfigurācijā, kā arÄ« neievērojam noslēpumu rotāciju, neskatoties uz to, ka mums ir piekļuve mākoņa IAM. Ja nepiecieÅ”ams, izmantojiet IAM lomas un pakalpojumu kontus, nevis lietotājus.

10 izplatītākās kļūdas, lietojot Kubernetes

Aizmirstiet par kube2iam un pārejiet tieÅ”i uz pakalpojumu kontu IAM lomām (kā aprakstÄ«ts sadaļā tāda paÅ”a nosaukuma piezÄ«me Å těpĆ”n VranĆ½):

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/my-app-role
  name: my-serviceaccount
  namespace: default

Viena anotācija. Nav tik grūti, vai ne?

Tāpat nepieŔķiriet pakalpojumu kontiem un gadÄ«jumu profilu privilēģijas admin Šø cluster-adminja viņiem tas nav vajadzÄ«gs. To ir nedaudz grÅ«tāk ieviest, it Ä«paÅ”i RBAC K8, taču noteikti ir vērts pielikt pÅ«les.

6. Nepaļaujieties uz automātisku anti-afinitāti pret pākstīm

Iedomājieties, ka jums ir trÄ«s kādas izvietoÅ”anas kopijas mezglā. Mezgls nokrÄ«t, un kopā ar to visas kopijas. NepatÄ«kama situācija, vai ne? Bet kāpēc visas kopijas atradās vienā mezglā? Vai Kubernetes nav paredzēts nodroÅ”ināt augstu pieejamÄ«bu (HA)?!

Diemžēl Kubernetes plānotājs pēc savas iniciatÄ«vas neatbilst atseviŔķas pastāvÄ“Å”anas noteikumiem (pretafinitāte) pākstÄ«m. Tie ir skaidri jānorāda:

// Š¾ŠæущŠµŠ½Š¾ Š“Š»Ń ŠŗрŠ°Ń‚ŠŗŠ¾ŃŃ‚Šø
      labels:
        app: zk
// Š¾ŠæущŠµŠ½Š¾ Š“Š»Ń ŠŗрŠ°Ń‚ŠŗŠ¾ŃŃ‚Šø
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                  - key: "app"
                    operator: In
                    values:
                    - zk
              topologyKey: "kubernetes.io/hostname"

Tas ir viss. Tagad podi tiks ieplānoti dažādos mezglos (Ŕis nosacījums tiek pārbaudīts tikai plānoŔanas laikā, bet ne to darbības laikā - tātad requiredDuringSchedulingIgnoredDuringExecution).

Å eit mēs runājam par podAntiAffinity dažādos mezglos: topologyKey: "kubernetes.io/hostname", - nevis par dažādām pieejamÄ«bas zonām. Lai ieviestu pilnvērtÄ«gu HA, jums bÅ«s jāiedziļinās Å”ajā tēmā.

7. PodDisruptionBudgets ignorēŔana

Iedomājieties, ka jums ir Kubernetes klastera ražoÅ”anas slodze. Periodiski mezgli un klasteris ir jāatjaunina (vai jānoņem ekspluatācija). PodDisruptionBudget (PDB) ir kaut kas lÄ«dzÄ«gs pakalpojumu garantijas lÄ«gumam starp klasteru administratoriem un lietotājiem.

PBP ļauj izvairīties no pakalpojumu pārtraukumiem, ko izraisa mezglu trūkums:

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: zk-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: zookeeper

Å ajā piemērā jÅ«s kā klastera lietotājs paziņojat administratoriem: ā€œSveiki, man ir zoodārza pakalpojums, un neatkarÄ«gi no tā, ko jÅ«s darāt, es vēlētos, lai vienmēr bÅ«tu pieejamas vismaz divas Ŕī pakalpojuma kopijas.ā€

Jūs varat lasīt vairāk par Ŕo Ŕeit.

8. Vairāki lietotāji vai vides kopējā klasterÄ«

Kubernetes nosaukumvietas (nosaukumvietas) nenodroÅ”ina spēcÄ«gu izolāciju.

IzplatÄ«ts nepareizs uzskats ir tāds, ka, ja vienā nosaukumvietā izvietojat neprod slodzi un citā nosaukumvietā, tad nekādā veidā neietekmēs viens otru... Tomēr noteiktu izolācijas lÄ«meni var sasniegt, izmantojot resursu pieprasÄ«jumus/ierobežojumus, nosakot kvotas un iestatot priorityClasses. Zināmu ā€œfiziskuā€ izolāciju datu plaknē nodroÅ”ina afinitātes, pielaides, piesārņojumi (vai mezglu atlasÄ«tāji), taču Ŕāda atdalÄ«Å”ana ir diezgan liela. grÅ«ti Ä«stenot.

Tiem, kuriem vienā un tajā paŔā klasterÄ« ir jāapvieno abu veidu slodzes, bÅ«s jārisina sarežģītÄ«ba. Ja Ŕādas vajadzÄ«bas nav, un jÅ«s varat atļauties tādu vēl viens klasteris (teiksim, publiskā mākonÄ«), tad labāk to darÄ«t. Tādējādi tiks sasniegts daudz augstāks izolācijas lÄ«menis.

9. ārējāTrafficPolicy: Cluster

Ļoti bieži mēs novērojam, ka visa datplūsma klasterī nāk caur tādu pakalpojumu kā NodePort, kuram ir iestatīta noklusējuma politika. externalTrafficPolicy: Cluster... Tas nozīmē, ka Mezglu ports ir atvērts katrā klastera mezglā, un jūs varat izmantot jebkuru no tiem, lai mijiedarbotos ar vēlamo pakalpojumu (podkopu).

10 izplatītākās kļūdas, lietojot Kubernetes

Tajā paŔā laikā reālie podi, kas saistÄ«ti ar iepriekÅ” minēto NodePort pakalpojumu, parasti ir pieejami tikai noteiktā ierÄ«cē Å”o mezglu apakÅ”kopa. Citiem vārdiem sakot, ja es izveidoju savienojumu ar mezglu, kuram nav vajadzÄ«gā pod, tas pārsÅ«tÄ«s trafiku uz citu mezglu, pievienojot apiņu un latentuma palielināŔana (ja mezgli atrodas dažādās pieejamÄ«bas zonās/datu centros, latentums var bÅ«t diezgan augsts; turklāt palielināsies izejas trafika izmaksas).

No otras puses, ja noteiktam Kubernetes pakalpojumam ir iestatÄ«ta politika externalTrafficPolicy: Local, tad NodePort tiek atvērts tikai tajos mezglos, kur faktiski darbojas nepiecieÅ”amie podi. Lietojot ārējo slodzes balansētāju, kas pārbauda stāvokli (veselÄ«bas pārbaude) galapunkti (kā tas darbojas AWS ELB), ViņŔ nosÅ«tÄ«s trafiku tikai uz nepiecieÅ”amajiem mezgliem, kas labvēlÄ«gi ietekmēs kavÄ“Å”anos, skaitļoÅ”anas vajadzÄ«bas, izejas rēķinus (un veselais saprāts nosaka to paÅ”u).

Pastāv liela iespēja, ka jÅ«s jau izmantojat kaut ko lÄ«dzÄ«gu traefik vai nginx-ingress-controller kā NodePort galapunktu (vai LoadBalancer, kas arÄ« izmanto NodePort), lai marÅ”rutētu HTTP ieejas trafiku, un Ŕīs opcijas iestatÄ«Å”ana var ievērojami samazināt Ŕādu pieprasÄ«jumu latentumu.

Š’ Ŕī publikācija JÅ«s varat uzzināt vairāk par ārējo satiksmes politiku, tās priekÅ”rocÄ«bām un trÅ«kumiem.

10. Nepiesaistīties kopām un ļaunprātīgi neizmantot vadības plakni

IepriekÅ” bija ierasts serverus saukt Ä«stajos vārdos: Antons, HAL9000 un Colossus... Å odien tie ir aizstāti ar nejauÅ”i Ä£enerētiem identifikatoriem. Tomēr ieradums saglabājās, un tagad Ä«paÅ”vārdi nonāk klasteros.

Tipisks stāsts (pamatojoties uz patiesiem notikumiem): viss sākās ar koncepcijas pierādÄ«jumu, tāpēc klasterim bija lepns nosaukums testÄ“Å”anaā€¦ Ir pagājuÅ”i gadi, un to JOPROJĀM izmanto ražoÅ”anā, un visi baidās tam pieskarties.

Nav nekā patÄ«kama, ja klasteri pārvērÅ”as par mājdzÄ«vniekiem, tāpēc mēs iesakām tos periodiski noņemt, kamēr trenējas. avārijas seku novērÅ”ana (tas palÄ«dzēs haosa inženierija ā€” apm. tulk.). Turklāt nenāktu par ļaunu strādāt pie kontroles slāņa (kontroles plakne). BaidÄ«ties viņam pieskarties nav laba zÄ«me. utt miris? PuiÅ”i, jums tieŔām ir problēmas!

No otras puses, jums nevajadzētu aizrauties ar manipulācijām ar to. Ar laiku kontroles slānis var kļūt lēns. Visticamāk, tas ir saistÄ«ts ar lielu objektu skaitu, kas tiek izveidoti bez to pagrieÅ”anas (izplatÄ«ta situācija, izmantojot Helm ar noklusējuma iestatÄ«jumiem, tāpēc tā stāvoklis konfigurācijas kartēs/noslēpumos netiek atjaunināts - rezultātā uzkrājas tÅ«kstoÅ”iem objektu vadÄ«bas slānis) vai ar pastāvÄ«gu kube-api objektu rediģēŔanu (automātiskai mērogoÅ”anai, CI/CD, uzraudzÄ«bai, notikumu žurnāliem, kontrolleriem utt.).

Turklāt mēs iesakām pārbaudÄ«t SLA/SLO lÄ«gumus ar pārvaldÄ«to Kubernetes pakalpojumu sniedzēju un pievērst uzmanÄ«bu garantijām. Pārdevējs var garantēt kontroles slāņa pieejamÄ«bu (vai tā apakÅ”komponenti), bet ne p99 aizkave, kad tai nosÅ«tāt pieprasÄ«jumus. Citiem vārdiem sakot, jÅ«s varat iekļūt kubectl get nodes, un saņem atbildi tikai pēc 10 minÅ«tēm, un tas nebÅ«s pakalpojuma lÄ«guma noteikumu pārkāpums.

11. Bonuss: jaunākā taga izmantoŔana

Bet Ŕī jau ir klasika. Pēdējā laikā ar Å”o paņēmienu sastopamies retāk, jo daudzi, mācÄ«juÅ”ies no rÅ«gtās pieredzes, ir pārtraukuÅ”i lietot birku :latest un sāka piespraust versijas. Urrā!

ECR saglabā attēlu tagu nemainÄ«gumu; Mēs iesakām iepazÄ«ties ar Å”o ievērojamo funkciju.

Kopsavilkums

Negaidiet, ka viss darbosies vienas nakts laikā: Kubernetes nav panaceja. Slikta lietotne tāds paliks pat Kubernetes (un tas, iespējams, pasliktināsies). NeuzmanÄ«ba radÄ«s pārmērÄ«gu sarežģītÄ«bu, lēnu un saspringtu kontroles slāņa darbu. Turklāt jÅ«s riskējat palikt bez avārijas seku novērÅ”anas stratēģijas. Negaidiet, ka Kubernetes nodroÅ”inās izolāciju un augstu pieejamÄ«bu. Pavadiet kādu laiku, lai jÅ«su lietojumprogramma bÅ«tu patiesi mākonÄ«.

Jūs varat iepazīties ar dažādu komandu neveiksmīgo pieredzi Ŕis stāstu krājums autors Hennings Džeikobss.

Tie, kas vēlas papildināt Å”ajā rakstā sniegto kļūdu sarakstu, var sazināties ar mums Twitter (@MarekBartik, @MstrsObserver).

PS no tulka

Lasi arī mūsu emuārā:

Avots: www.habr.com

Pievieno komentāru