Rêbernameyek dîtbar ji bo çareserkirina pirsgirêka Kubernetes

Not. werger.: Ev gotar beşek ji materyalên projeyê ye ku di qada gelemperî de têne weşandin Learnk8s, pargîdaniyên perwerdehiyê û rêveberên kesane ku bi Kubernetes re bixebitin. Di wê de, Daniele Polencic, rêveberê projeyê, rêwerzên dîtbarî li ser çi gavan bavêjin di rewşên pirsgirêkên gelemperî yên bi serîlêdanên ku li ser koma K8s têne xebitandin parve dike.

TR

Flowchart ji bo dîtin û rastkirina xeletiyên di komekê de. Orjînal (bi Îngilîzî) li vir heye PDF и wek wêne.

Dema ku serîlêdanek li Kubernetes bicîh dikin, bi gelemperî sê hêman hene ku hûn hewce ne ku pênase bikin:

• Dêrîn - ev celebek reçete ye ji bo afirandina kopiyên serîlêdanê, ku jê re pods tê gotin;
• Xizmetkar - balansa barkirina navxweyî ya ku seyrûseferê di nav potan de belav dike;
• Ingress - danasînek ka dê seyrûsefer çawa ji cîhana derve bigihîje Karûbar.

Li vir kurteyek grafîkî ya bilez heye:

1) Di Kubernetes de, serîlêdan ji cîhana derve bi navgîniya du qatên balansên barkirinê ve seyrûseferê distînin: hundurîn û derveyî.

2) Balansa hundurîn jê re Servîs, ya derve jê re Ingress tê gotin.

3) Dabeşkirin podan diafirîne û wan dişopîne (ew bi destan nayên afirandin).

Ka em bibêjin ku hûn dixwazin serîlêdanek hêsan a la saz bikin Merheba cîhan. Veavakirina YAML ji bo wê dê bi vî rengî xuya bike:

apiVersion: apps/v1
kind: Deployment # <<<
metadata:
  name: my-deployment
  labels:
    track: canary
spec:
  selector:
    matchLabels:
      any-name: my-app
  template:
    metadata:
      labels:
        any-name: my-app
    spec:
      containers:
      - name: cont1
        image: learnk8s/app:1.0.0
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service # <<<
metadata:
  name: my-service
spec:
  ports:
  - port: 80
    targetPort: 8080
  selector:
    name: app
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress # <<<
metadata:
  name: my-ingress
spec:
  rules:
  - http:
    paths:
    - backend:
        serviceName: app
        servicePort: 80
      path: /

Danasîn pir dirêj e û hêsan e ku meriv di derheqê ka pêkhateyan de çawa bi hevûdu re têkildar dibin tevlihev bibin.

Bo nimûne:

• Kengê divê hûn port 80 bikar bînin û kengê divê hûn 8080 bikar bînin?
• Ma ez ji bo her karûbarek portek nû biafirînim da ku ew nakok nebin?
• Ma navên etîketan girîng in? Ma divê ew li her derê yek bin?

Berî ku em bala xwe bidin ser xeletkirinê, em bînin bîra xwe ka sê pêkhate çawa bi hevûdu re têkildar in. Werin em bi Deployment and Service dest pê bikin.

Têkiliya di navbera Deployment û Service

Hûn ê şaş bibin, lê Dabeşkirin û Karûbar bi ti awayî bi hev ve girêdayî ne. Di şûna wê de, Karûbar rasterast li Pods-ê destnîşan dike, Deployment derbas dike.

Bi vî rengî, em bala xwe didin ka Pods û Karûbar çawa bi hevûdu re têkildar in. Sê tişt ji bîr nekin:

1. Hilbijêr (selector) ji bo Karûbar divê bi kêmanî yek etîketa Pod re hevber bike.
2. targetPort divê li hev bikin containerPort konteynir di hundurê Pod de.
3. port Xizmet dikare her tişt be. Karûbarên cihêreng dikarin heman portê bikar bînin ji ber ku wan navnîşanên IP-yê cûda hene.

Diagrama jêrîn hemî tiştên jorîn di forma grafîkî de nîşan dide:

1) Bifikirin ku karûbar seyrûseferê berbi hin podek ve dibe:

2) Dema ku podek çêbikin, divê hûn diyar bikin containerPort ji bo her konteynir di potan de:

3) Dema ku karûbarek çêbikin, divê hûn diyar bikin port и targetPort. Lê kîjan ji bo girêdana konteynerê tê bikar anîn?

4) Bi rêya targetPort. Pêdivî ye ku ew li hev bikin containerPort.

5) Em bêjin porta 3000 di konteynerê de vekirî ye. Paşê nirx targetPort divê wisa be.

Di pelê YAML de, etîket û ports / targetPort divê li hev bikin:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
  labels:
    track: canary
spec:
  selector:
    matchLabels:
      any-name: my-app
  template:
    metadata:
     labels:  # <<<
        any-name: my-app  # <<<
   spec:
      containers:
      - name: cont1
        image: learnk8s/app:1.0.0
        ports:
       - containerPort: 8080  # <<<
---
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  ports:
  - port: 80
   targetPort: 8080  # <<<
 selector:  # <<<
    any-name: my-app  # <<<

Çi labelê track: canary li jor beşa Deployment? Divê ew li hev bikin?

Ev etîket ji bo rêvekirina trafîkê ji hêla karûbar ve nayê bikar anîn. Bi gotinek din, ew dikare were rakirin an nirxek cûda were destnîşan kirin.

Çi li ser hilbijêr matchLabels?

Pêdivî ye ku ew her gav bi etîketên Pod-ê re têkildar be, ji ber ku ew ji hêla Deployment ve tê bikar anîn da ku podan bişopîne.

Ka em bihesibînin ku we sererastkirinên rast çêkirine. Meriv çawa wan kontrol bike?

Hûn dikarin bi fermana jêrîn etîketa pod kontrol bikin:

kubectl get pods --show-labels

An jî, heke pod ji çend serlêdanan re bin:

kubectl get pods --selector any-name=my-app --show-labels

Derê any-name=my-app etîketek e any-name: my-app.

Ma ti zehmetî mane?

Hûn dikarin bi podê ve girêdayî bikin! Ji bo vê yekê hûn hewce ne ku emrê bikar bînin port-forward li kubectl. Ew dihêle hûn bi karûbarê ve girêdayî bibin û pêwendiyê kontrol bikin.

kubectl port-forward service/<service name> 3000:80

Va ye:

• service/<service name> - navê xizmetê; di rewşa me de ew e my-service;
• 3000 porta ku divê li ser komputerê were vekirin e;
• 80 - porta ku di zeviyê de hatî destnîşan kirin port xizmetkar.

Ger girêdan hate damezrandin, wê hingê mîheng rast in.

Ger pêwendiyek têk neçe, pirsgirêkek bi etîketan heye an jî port li hev nakin.

Têkiliya di navbera Xizmet û Ingress

Pêngava paşîn di peydakirina gihîştina serîlêdanê de sazkirina Ingress pêk tîne. Pêdivî ye ku Ingress zanibe ka meriv çawa karûbarek bibîne, dûv re podan bibîne û seyrûsefera wan rasterast bike. Ingress karûbarê pêwîst bi nav û portê vekirî dibîne.

Di danasîna Ingress û Xizmetê de du parameter divê li hev bikin:

1. servicePort di Ingress de divê parametre hev port di xizmetê de;
2. serviceName li Ingress divê zeviyê hev name di Xizmetê de.

Diagrama jêrîn girêdanên portê kurt dike:

1) Wekî ku hûn jixwe dizanin, Xizmet li hin kesan guhdarî dike port:

2) Ingress pîvanek heye ku jê re tê gotin servicePort:

3) Ev parametre (servicePort) divê her dem li hev bikin port di pênaseya karûbarê de:

4) Ger porta 80 di Xizmetê de hatî destnîşan kirin, wê hingê ew hewce ye servicePort jî bû 80:

Di pratîkê de, divê hûn bala xwe bidin rêzikên jêrîn:

apiVersion: v1
kind: Service
metadata:
 name: my-service  # <<<
spec:
  ports:
 - port: 80  # <<<
   targetPort: 8080
  selector:
    any-name: my-app
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - http:
    paths:
    - backend:
       serviceName: my-service  # <<<
       servicePort: 80  # <<<
     path: /

Meriv çawa kontrol dike ka Ingress dimeşe?

Hûn dikarin rêbazê bi kar bînin kubectl port-forward, lê li şûna karûbarê hûn hewce ne ku bi kontrolkera Ingress ve girêdayî bin.

Pêşî hûn hewce ne ku navê pod bi kontrolkera Ingress re bibînin:

kubectl get pods --all-namespaces
NAMESPACE   NAME                              READY STATUS
kube-system coredns-5644d7b6d9-jn7cq          1/1   Running
kube-system etcd-minikube                     1/1   Running
kube-system kube-apiserver-minikube           1/1   Running
kube-system kube-controller-manager-minikube  1/1   Running
kube-system kube-proxy-zvf2h                  1/1   Running
kube-system kube-scheduler-minikube           1/1   Running
kube-system nginx-ingress-controller-6fc5bcc  1/1   Running

Ingress pod-ê bibînin (dibe ku ew di nav cîhek cûda de be) û fermanê bimeşînin describeji bo ku hûn hejmarên portê bibînin:

kubectl describe pod nginx-ingress-controller-6fc5bcc 
--namespace kube-system 
 | grep Ports
Ports:         80/TCP, 443/TCP, 18080/TCP

Di dawiyê de, bi podê ve girêdayî bikin:

kubectl port-forward nginx-ingress-controller-6fc5bcc 3000:80 --namespace kube-system

Naha her gava ku hûn daxwazek ji porta 3000-ê re li ser komputera xwe dişînin, ew ê bi kontrolkera Ingress re ji porta 80-ê ya pod re were şandin. Bi çûyîna http://localhost:3000, divê hûn rûpela ku ji hêla serîlêdanê ve hatî çêkirin bibînin.

Kurteya benderan

Ka em careke din bînin bîra xwe ka kîjan port û etîket divê li hev bikin:

1. Hilbijêrê di pênaseya Xizmetê de divê bi etîketa pod-ê re têkildar be;
2. targetPort di pênase de Xizmeta divê hev containerPort konteynir di hundurê qulikê de;
3. port di pênaseyê de Xizmet dikare her tişt be. Karûbarên cihêreng dikarin heman portê bikar bînin ji ber ku navnîşanên IP-ya wan ên cûda hene;
4. servicePort Pêdivî ye ku ketin lihevhatin port di pênaseya Xizmetê de;
5. Navê karûbarê pêdivî ye ku zeviyê li hev bike serviceName li Ingress.

Mixabin, ne bes e ku meriv zanibe meriv çawa bi rêkûpêk veavakirina YAML ava dike.

Çi diqewime dema ku tişt xelet diçin?

Dibe ku pod dest pê neke an jî têk bibe.

3 Gav ji bo Teşhîskirina Pirsgirêkên Serlêdanê li Kubernetes

Berî ku hûn dest bi dakêşana danûstendina xwe bikin, hûn hewce ne ku têgihîştinek baş a ka Kubernetes çawa dixebite.

Ji ber ku her serîlêdana ku di K8s-ê de hatî dakêşandin sê beş hene, divê ew bi rêzek diyarkirî werin debug kirin, ji binî ve dest pê bikin.

1. Pêşî hûn hewce ne ku pê ewle bin ku pod dixebitin, paşê ...
2. Kontrol bikin ka karûbar seyrûseferê li ser podan peyda dike, û dûv re…
3. Kontrol bikin ka Ingress rast hatiye mîheng kirin.

Nûnertiya dîtbar:

1) Divê hûn ji binî ve dest bi lêgerîna pirsgirêkan bikin. Pêşîn kontrol bikin ku pod xwedî statû ne Ready и Running:

2) Heke kulikan amade ne (Ready), divê hûn fêr bibin ka karûbar seyrûseferê di navbera pods de belav dike:

3) Di dawiyê de, hûn hewce ne ku pêwendiya di navbera karûbar û Ingress de analîz bikin:

1. Diagnostics of pods

Di pir rewşan de pirsgirêk bi podê ve girêdayî ye. Piştrast bikin ku pods wekî têne navnîş kirin Ready и Running. Hûn dikarin vê bi karanîna fermanê kontrol bikin:

kubectl get pods
NAME                    READY STATUS            RESTARTS  AGE
app1                    0/1   ImagePullBackOff  0         47h
app2                    0/1   Error             0         47h
app3-76f9fcd46b-xbv4k   1/1   Running           1         47h

Di derketina emrê li jor de, podê paşîn wekî tête navnîş kirin Running и Ready, lebê, ev yek ji bo her du yên din ne.

Meriv çawa fêm dike ka çi xelet bûye?

Ji bo teşhîskirina pods çar fermanên kêrhatî hene:

1. kubectl logs <имя pod'а> destûrê dide te ku têketinên ji konteynirên di nav qulikê de derxînin;
2. kubectl describe pod <имя pod'а> destûrê dide te ku hûn navnîşek bûyerên ku bi pod re têkildar in bibînin;
3. kubectl get pod <имя pod'а> destûrê dide te ku hûn veavakirina YAML ya podek ku li Kubernetes hatî hilanîn bistînin;
4. kubectl exec -ti <имя pod'а> bash dihêle hûn di yek ji konteynerên pod de şêlek fermanek înteraktîf bidin destpêkirin

Divê hûn kîjan hilbijêrin?

Rastî ev e ku fermanek gerdûnî tune. Divê bihevrebûna van were bikaranîn.

Pirsgirêkên tîpîk ên pod

Du celebên sereke yên xeletiyên pod hene: xeletiyên destpêkê û xeletiyên dema xebitandinê.

Çewtiyên destpêkê:

• ImagePullBackoff
• ImageInspectError
• ErrImagePull
• ErrImageNeverPull
• RegistryUnavailable
• InvalidImageName

Çewtiyên dema xebitandinê:

• CrashLoopBackOff
• RunContainerError
• KillContainerError
• VerifyNonRootError
• RunInitContainerError
• CreatePodSandboxError
• ConfigPodSandboxError
• KillPodSandboxError
• SetupNetworkError
• TeardownNetworkError

Hin xeletî ji yên din pirtir in. Li vir çend xeletiyên herî gelemperî hene û meriv çawa wan rast dike.

ImagePullBackOff

Ev xeletî çêdibe dema ku Kubernetes nekare wêneyek ji bo yek ji konteynerên pod bigire. Li vir sê sedemên herî gelemperî yên vê yekê hene:

1. Navê wêneyê xelet e - bo nimûne, we xeletiyek tê de kir, an wêne tune;
2. Ji bo wêneyê etîketek neheyî hate diyarkirin;
3. Wêne di qeydek taybet de tê hilanîn û Kubernetes ne xwediyê destûr e ku bigihîje wê.

Du sedemên pêşîn ji holê rakirina hêsan in - tenê nav û nîşana wêneyê rast bikin. Di doza ya paşîn de, hûn hewce ne ku pêbaweriyên ji bo qeyda girtî ya di Secret de têkevin û lînkên wê di nav potan de zêde bikin. Di belgeya Kubernetes de mînakek heye ev çawa dikare were kirin.

Crash Loop Back Off

Kubenetes xeletiyek derdixe CrashLoopBackOff, heke konteynir nikaribe dest pê bike. Ev bi gelemperî diqewime dema ku:

1. Di serîlêdanê de xeletiyek heye ku pêşî li destpêkirina wê digire;
2. Container bi xeletî vesaz kirin;
3. Testa Liveness gelek caran têk çû.

Pêdivî ye ku hûn hewl bidin ku ji konteynerê bigihîjin têketinên ku sedema têkçûna wê fêr bibin. Ger gihîştina têketin dijwar be ji ber ku konteynir pir zû ji nû ve dest pê dike, hûn dikarin fermana jêrîn bikar bînin:

kubectl logs <pod-name> --previous

Ew peyamên xeletiyê ji înkarnasyona berê ya konteynerê nîşan dide.

RunContainerError

Dema ku konteynir dest pê neke ev xeletî çêdibe. Ew bi dema berî destpêkirina serîlêdanê re têkildar e. Ew bi gelemperî ji hêla mîhengên nerast ve dibe, mînakî:

• hewl didin ku cildek neheyî mîna ConfigMap an Veşartî bixin;
• hewildanek ji bo danîna cildek tenê-xwendin wekî xwendin-nivîsandinê.

Tîm ji bo analîzkirina xeletiyên weha baş e kubectl describe pod <pod-name>.

Pods di dewleta Pending de ne

Piştî ku hate afirandin, pod di dewletê de dimîne Pending.

Çima ev dibe?

Li vir sedemên mimkun in (Ez texmîn dikim ku plansazker baş dixebite):

1. Kluster xwedan çavkaniyên têr nake, wek hêza pêvajoyê û bîranînê, ku pod bimeşîne.
2. Tişt di nav cîhê guncan de tê saz kirin ResourceQuota û çêkirina podek dê bibe sedem ku cîhê nav ji kotayê derbas bibe.
3. Pod bi Hêvî ve girêdayî ye PersistentVolumeClaim.

Di vê rewşê de, tê pêşniyar kirin ku emrê bikar bînin kubectl describe û beşa kontrol bikin Events:

kubectl describe pod <pod name>

Di doza çewtiyên têkildarî ResourceQuotas, tê pêşniyar kirin ku bi karanîna fermanê têketinên komê bibînin

kubectl get events --sort-by=.metadata.creationTimestamp

Pods ne Amade ne

Ger pod wekî navnîşê tête navnîş kirin Running, lê ne di rewşekê de ye Ready, tê wateya kontrolkirina amadebûna wê (lêkolîna amadebûnê) têk diçe.

Gava ku ev diqewime, pod bi karûbarê ve nayê girêdan û seyrûsefer jê re naherike. Têkçûna testa amadebûnê ji ber pirsgirêkên di serîlêdanê de pêk tê. Di vê rewşê de, ji bo dîtina xeletiyê, hûn hewce ne ku beşê analîz bikin Events di derketina fermanê de kubectl describe.

2. Teşhîs Service

Heke kulîlk wekî navnîş têne navnîş kirin Running и Ready, lê hîn jî bersivek ji serîlêdanê tune, divê hûn mîhengên karûbarê kontrol bikin.

Karûbar berpirsiyar in ku li gorî etîketên wan rêvekirina seyrûseferê berbi podan ve girêdayî ne. Ji ber vê yekê, yekem tiştê ku hûn hewce ne bikin ev e ku kontrol bikin ka çend pod bi karûbarê re dixebitin. Ji bo vê yekê, hûn dikarin xalên dawî yên di karûbarê de kontrol bikin:

kubectl describe service <service-name> | grep Endpoints

Endpoint cotek nirxên formê ye <IP-адрес:порт>, û bi kêmî ve cotek weha divê di encam de hebe (ango, bi kêmanî yek pod bi karûbarê re dixebite).

Ger beşa Endpoins vala, du vebijark mimkun in:

1. bi etîketa rast çîpek tune (nîşan: kontrol bikin ka cîhê navan rast hatî hilbijartin);
2. Di hilbijarkê de di etîketên karûbarê de xeletiyek heye.

Ger hûn navnîşek xalên dawiyê dibînin lê dîsa jî nekarin bigihîjin serîlêdanê, wê hingê sûcdarê muhtemel xeletiyek e targetPort di danasîna xizmetê de.

Meriv çawa fonksiyona karûbarê kontrol dike?

Bêyî celebê karûbarê, hûn dikarin fermanê bikar bînin kubectl port-forward ji bo girêdana wê:

kubectl port-forward service/<service-name> 3000:80

Va ye:

• <service-name> - navê xizmetê;
• 3000 porta ku hûn li ser komputerê vedikin e;
• 80 - port li aliyê xizmetê.

3. Teşhîsa ketinê

Ger we heya niha xwendibe, wê hingê:

• pez wekî têne navnîş kirin Running и Ready;
• karûbar bi serfirazî seyrûseferê di nav potan de belav dike.

Lêbelê, hûn hîn jî nikarin bigihîjin sepanê.

Ev tê vê wateyê ku kontrolkera Ingress bi îhtîmalek rast nehatiye mîheng kirin. Ji ber ku kontrolkera Ingress di komê de pêkhateyek sêyemîn e, li gorî celebê wê rêgezên debugkirinê yên cihêreng hene.

Lê berî ku hûn bikar bînin ku amûrên taybetî bikar bînin da ku Ingress mîheng bikin, hûn dikarin tiştek pir hêsan bikin. Ingress bikar tîne serviceName и servicePort ji bo girêdana xizmetê. Pêdivî ye ku hûn kontrol bikin ka ew rast hatine mîheng kirin. Hûn dikarin vê bi karanîna fermanê bikin:

kubectl describe ingress <ingress-name>

Ger stûn Backend vala ye, îhtimaleke mezin a xeletiya veavakirinê heye. Ger paşnav li cîhê xwe bin, lê serîlêdan hîn jî negihîje, wê hingê dibe ku pirsgirêk bi vê ve girêdayî be:

• Mîhengên gihîştina gihîştina ji Înternetê ya gelemperî;
• mîhengên gihîştina komê ji Înterneta giştî.

Hûn dikarin pirsgirêkên binesaziyê bi girêdana rasterast bi Ingress pod re nas bikin. Ji bo kirina vê yekê, pêşî podika Ingress Controller bibînin (dibe ku ew di nav cîhek cûda de be):

kubectl get pods --all-namespaces
NAMESPACE   NAME                              READY STATUS
kube-system coredns-5644d7b6d9-jn7cq          1/1   Running
kube-system etcd-minikube                     1/1   Running
kube-system kube-apiserver-minikube           1/1   Running
kube-system kube-controller-manager-minikube  1/1   Running
kube-system kube-proxy-zvf2h                  1/1   Running
kube-system kube-scheduler-minikube           1/1   Running
kube-system nginx-ingress-controller-6fc5bcc  1/1   Running

Ferman bikar bînin describeji bo danîna portê:

kubectl describe pod nginx-ingress-controller-6fc5bcc
--namespace kube-system 
 | grep Ports

Di dawiyê de, bi podê ve girêdayî bikin:

kubectl port-forward nginx-ingress-controller-6fc5bcc 3000:80 --namespace kube-system

Naha hemî daxwazên porta 3000-ê li ser komputerê dê berbi porta 80-ê ya pod-ê ve werin veguheztin.

Ma ew niha dixebite?

• Ger erê, hingê pirsgirêk bi binesaziyê ye. Pêdivî ye ku meriv bi tam fêr bibe ka seyrûsefer çawa berbi komê ve tê rêve kirin.
• Heke ne, wê hingê pirsgirêk bi kontrolkera Ingress re ye.

Ger hûn nekarin kontrolkera Ingress bixebitin, hûn ê neçar bin ku wê jêbirin.

Gelek celebên kontrolkerên Ingress hene. Ya herî populer Nginx, HAProxy, Traefik, hwd. (ji bo bêtir agahdarî li ser çareseriyên heyî, binêre nirxandina me - nêzîkî. werger.) Pêdivî ye ku hûn di belgeya kontrolkerê têkildar de serî li rêbernameya çareserkirina pirsgirêkê bidin. Ji ber ku Ingress Nginx kontrolkera Ingress-ê ya herî populer e, me di gotarê de hin serişteyên ji bo çareserkirina pirsgirêkên pê re têkildar kiriye.

Kontrolkera Ingress Nginx verastkirin

Projeya Ingress-nginx xwedî fermî ye pêvek ji bo kubectl. Kom kubectl ingress-nginx dikare ji bo bikaranîn:

• analîzkirina têketin, paşvekêşan, sertîfîkayan, hwd.;
• girêdanên bi Ingress;
• lêkolîna veavakirina heyî.

Sê fermanên jêrîn dê di vê yekê de ji we re bibin alîkar:

• kubectl ingress-nginx lint - kontrol dike nginx.conf;
• kubectl ingress-nginx backend - paşîn lêkolîn dike (wekhev kubectl describe ingress <ingress-name>);
• kubectl ingress-nginx logs - qeydan kontrol dike.

Bala xwe bidinê ku di hin rewşan de dibe ku hûn hewce ne ku cîhê navê rast ji bo kontrolkera Ingress bi karanîna ala diyar bikin --namespace <name>.

Nîqaş

Heke hûn nizanin ji ku derê dest pê bikin çareserkirina Kubernetes dikare dijwar be. Pêdivî ye ku hûn her gav ji binî ve nêzikî pirsgirêkê bibin: bi potan dest pê bikin, û dûv re derbasî karûbar û Ingress bibin. Teknolojiyên xeletkirinê yên ku di vê gotarê de têne diyar kirin dikarin li ser tiştên din werin sepandin, wek:

• Karên bêkar û CronJobs;
• StatefulSets û DaemonSets.

Ez spasiyên xwe diyar dikim Gergely Risko, Daniel Weibel и Charles Christyraj ji bo şîrove û zêdekirinên hêja.

PS ji wergêr

Li ser bloga me jî bixwînin:

• «Pêveka kubectl-debug ji bo verastkirina li Kubernetes pods»;
• «Di xebata Kubernetes de 6 xeletiyên pergalê yên balkêş [û çareseriya wan]»;
• «Amûrên ji bo pêşdebirên serîlêdanên ku li Kubernetes têne xebitandin»;
• «6 çîrokên pratîkî ji jiyana meya rojane ya SRE ".

Source: www.habr.com