Umhlahlandlela Obonakalayo Wokuxazulula Izinkinga Kubernetes

Qaphela. transl.: Lesi sihloko siyingxenye yezinto zephrojekthi ezishicilelwe esizindeni somphakathi ufunde8s, izinkampani zokuqeqesha kanye nabaphathi abangabodwana ukuze basebenze ne-Kubernetes. Kuyo, u-Daniele Polencic, umphathi wephrojekthi, wabelana ngeziyalezo ezibukwayo ngokuthi yiziphi izinyathelo okufanele uzithathe uma kuba nezinkinga ezijwayelekile ngezinhlelo zokusebenza ezisebenza kuqoqo le-K8s.

TL;DR: nawu umdwebo ozokusiza ukuthi ususe iphutha ekusetshenzisweni e-Kubernetes:

I-Flowchart yokuthola nokulungisa amaphutha kuqoqo. Okwangempela (ngesiNgisi) kuyatholakala ku PDF и njengesithombe.

Lapho uthumela isicelo ku-Kubernetes, ngokuvamile kunezingxenye ezintathu okudingeka uzichaze:

• Ukuthunyelwa - lena uhlobo lweresiphi yokwenza amakhophi ohlelo lokusebenza, olubizwa ngokuthi ama-pods;
• Izikhungo - I-balancer yomthwalo wangaphakathi esabalalisa ukuhamba phakathi kwama-pods;
• Ingress - incazelo yokuthi ithrafikhi izofika kanjani emhlabeni wangaphandle iye Ensizeni.

Nasi isifinyezo esisheshayo sesithombe:

1) Ku-Kubernetes, izinhlelo zokusebenza zithola ithrafikhi evela emhlabeni wangaphandle ngezingqimba ezimbili zezilinganisi zomthwalo: zangaphakathi nangaphandle.

2) Ibhalansi yangaphakathi ibizwa nge-Service, eyangaphandle ibizwa nge-Ingress.

3) Ukuthunyelwa kudala ama-pods futhi kuyawaqapha (awadalwanga mathupha).

Ake sithi ufuna ukufaka isicelo esilula i-la Sawubona Umhlaba. Ukucushwa kwayo kwe-YAML kuzobukeka kanje:

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: /

Incazelo yinde impela futhi kulula ukudideka ngokuthi izingxenye zihlobana kanjani.

Isibonelo:

• Kufanele usebenzise nini i-port 80 futhi kufanele usebenzise nini i-8080?
• Ingabe kufanele ngidale imbobo entsha yesevisi ngayinye ukuze zingangqubuzani?
• Ingabe amagama amalebula anendaba? Ingabe kufanele zifane yonke indawo?

Ngaphambi kokugxila ekususeni iphutha, ake sikhumbule ukuthi izingxenye ezintathu zihlobana kanjani. Ake siqale nge-Deployment and Service.

Ubudlelwano phakathi kokuthunyelwa kanye nesevisi

Uzomangala, kodwa Ukuthunyelwa Nezinsiza akuxhunyiwe nganoma iyiphi indlela. Esikhundleni salokho, Isevisi ikhomba ngqo kuma-Pods, yeqa Ukuthunyelwa.

Ngakho-ke, sinentshisekelo yokuthi ama-Pods namasevisi ahlobene kanjani. Izinto ezintathu okufanele uzikhumbule:

1. Isikhethi (selector) Yesevisi kufanele ifane okungenani ilebula lePod eyodwa.
2. targetPort kumele ifane containerPort isitsha ngaphakathi kwePod.
3. port Isevisi ingaba yinoma yini. Amasevisi ahlukene angasebenzisa imbobo efanayo ngoba anamakheli e-IP ahlukile.

Umdwebo olandelayo umele konke okungenhla ngendlela yesithombe:

1) Cabanga ukuthi isevisi iqondisa ithrafikhi endaweni ethile:

2) Lapho udala i-pod, kufanele ucacise containerPort esitsheni ngasinye esisezimpondweni:

3) Lapho udala isevisi, kufanele ucacise port и targetPort. Kodwa iyiphi esetshenziselwa ukuxhuma esitsheni?

4) Nge targetPort. Kufanele ifane containerPort.

5) Ake sithi i-port 3000 ivuliwe esitsheni. Bese inani targetPort kufanele kube okufanayo.

Efayelini le-YAML, amalebula kanye ports / targetPort kufanele ifane:

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  # <<<

Kuthiwani ngelebula track: canary phezulu kwesigaba Sokuthunyelwa? Ingabe kufanele ifane?

Le lebula iqondene ngqo nokuthunyelwa futhi ayisetshenziswa isevisi kuthrafikhi yomzila. Ngamanye amazwi, ingasuswa noma inikezwe inani elihlukile.

Kuthiwani ngesikhethi matchLabels?

Kufanele njalo ifane namalebula e-Pod, njengoba isetshenziswa yi-Deployment ukulandelela ama-pods.

Ake sicabange ukuthi wenze ukuhlela okulungile. Ungawabheka kanjani?

Ungahlola ilebula ye-pod ngomyalo olandelayo:

kubectl get pods --show-labels

Noma, uma ama-pods engezezinhlelo zokusebenza ezimbalwa:

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

Kuphi any-name=my-app ilebula any-name: my-app.

Ingabe bukhona ubunzima obusele?

Ungakwazi ukuxhuma ku-pod! Ukuze wenze lokhu udinga ukusebenzisa umyalo port-forward kwe kubectl. Ikuvumela ukuthi uxhume kusevisi futhi uhlole uxhumano.

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

Lapha:

• service/<service name> - igama lesevisi; kithi kunjalo my-service;
• I-3000 iyichweba elidinga ukuvulwa kukhompyutha;
• 80 - imbobo eshiwo ensimini port inkonzo.

Uma uxhumano lusungulwe, khona-ke izilungiselelo zilungile.

Uma ukuxhumeka kwehluleka, kunenkinga ngamalebula noma izimbobo azifani.

Ubudlelwano phakathi kwesevisi kanye ne-Ingress

Isinyathelo esilandelayo ekunikezeni ukufinyelela kuhlelo lokusebenza sihlobene nokusetha i-Ingress. I-Ingress idinga ukwazi ukuthi iyithola kanjani isevisi, bese ithola ama-pods futhi iqondise ithrafikhi kuwo. I-Ingress ithola isevisi edingekayo ngegama nangembobo evulekile.

Encazelweni ye-Ingress ne-Service amapharamitha amabili kufanele afane:

1. servicePort kokuthi I-Ingress kufanele ifane nepharamitha port Ensimini;
2. serviceName kokuthi I-Ingress kufanele ifane nenkambu name Kusevisi.

Umdwebo olandelayo ufingqa ukuxhumana kwembobo:

1) Njengoba wazi kakade, Isevisi ilalela okuthile port:

2) I-Ingress inepharamitha ebizwa servicePort:

3) Le parameter (servicePort) kufanele njalo ifane port encazelweni Yesevisi:

4) Uma i-port 80 icacisiwe ku-Service, ngakho-ke kuyadingeka ukuthi servicePort futhi yayilingana no-80:

Ekusebenzeni, udinga ukunaka imigqa elandelayo:

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: /

Ungahlola kanjani ukuthi i-Ingress iyasebenza?

Ungasebenzisa indlela nge kubectl port-forward, kodwa esikhundleni sesevisi udinga ukuxhuma kusilawuli se-Ingress.

Okokuqala udinga ukuthola igama le-pod ngesilawuli se-Ingress:

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

Thola i-Ingress pod (kungenzeka ibe sendaweni yamagama ehlukile) bese uqhuba umyalo describeukuze uthole izinombolo zembobo:

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

Ekugcineni, xhuma ku-pod:

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

Manje njalo uma uthumela isicelo sokuthutha i-3000 kukhompyutha yakho, sizodluliselwa ku-port 80 ye-pod ngesilawuli se-Ingress. Ngokuya ku http://localhost:3000, kufanele ubone ikhasi elenziwe uhlelo lokusebenza.

Isifinyezo samachweba

Masikhumbule futhi ukuthi yiziphi izimbobo namalebula okufanele afane:

1. Isikhethi encazelweni Yesevisi kufanele sifane nelebula le-pod;
2. targetPort encazelweni Isevisi kufanele ifane containerPort isitsha ngaphakathi kwe-pod;
3. port encazelweni Isevisi ingaba yinoma yini. Amasevisi ahlukene angasebenzisa imbobo efanayo ngoba anamakheli e-IP ahlukene;
4. servicePort I-Ingress kumele ifane port encazelweni Yesevisi;
5. Igama lesevisi kufanele lifane nenkambu serviceName ku-Ingress.

Ngeshwa, akwanele ukwazi ukuthi ukumiswa kanjani kahle ukucushwa kwe-YAML.

Kwenzekani lapho izinto zingahambi kahle?

I-pod ingase ingaqali noma ingaphahlazeka.

Izinyathelo ezi-3 Zokuhlonza Izinkinga Zohlelo Kubernetes

Ngaphambi kokuthi uqale ukulungisa iphutha ekusetshenzisweni kwakho, udinga ukuqonda kahle ukuthi i-Kubernetes isebenza kanjani.

Njengoba uhlelo lokusebenza ngalunye olulandwe kuma-K8 lunezingxenye ezintathu, kufanele lulungiswe ngendlela ethile, luqalwe phansi kakhulu.

1. Okokuqala udinga ukwenza isiqiniseko sokuthi ama-pods ayasebenza, bese ...
2. Hlola ukuthi isevisi inikeza ithrafikhi kuma-pods, bese...
3. Hlola ukuthi i-Ingress ilungiselelwe kahle yini.

Ukumelwa okubonakalayo:

1) Kufanele uqale ukufuna izinkinga kusukela phansi. Okokuqala hlola ukuthi ama-pods anesimo Ready и Running:

2) Uma ama-pods eselungile (Ready), kufanele uthole ukuthi isevisi isabalalisa ithrafikhi phakathi kwama-pods:

3) Okokugcina, udinga ukuhlaziya ukuxhumana phakathi kwenkonzo ne-Ingress:

1. Ukuxilongwa kwama-pods

Ezimweni eziningi, inkinga ihlobene ne-pod. Qinisekisa ukuthi ama-pods abhalwe njenge Ready и Running. Ungahlola lokhu usebenzisa umyalo:

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

Kokukhipha umyalo ngenhla, i-pod yokugcina ibhalwe njenge Running и ReadyNokho, lokhu akunjalo kwabanye ababili.

Indlela yokuqonda ukuthi yini engahambanga kahle?

Kunemiyalo emine ewusizo yokuxilonga ama-pods:

1. kubectl logs <имя pod'а> ikuvumela ukuthi ukhiphe izingodo ezitsheni ku-pod;
2. kubectl describe pod <имя pod'а> ikuvumela ukuthi ubuke uhlu lwezehlakalo ezihlobene ne-pod;
3. kubectl get pod <имя pod'а> ikuvumela ukuthi uthole ukucushwa kwe-YAML kwe-pod egcinwe ku-Kubernetes;
4. kubectl exec -ti <имя pod'а> bash ikuvumela ukuthi uqalise igobolondo lomyalo osebenzisanayo kwesinye seziqukathi ze-pod

Iyiphi okufanele uyikhethe?

Iqiniso liwukuthi awukho umyalo wendawo yonke. Inhlanganisela yalokhu kufanele isetshenziswe.

Izinkinga ze-pod ezijwayelekile

Kunezinhlobo ezimbili eziyinhloko zamaphutha e-pod: amaphutha okuqalisa kanye namaphutha wesikhathi sokusebenza.

Amaphutha okuqalisa:

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

Amaphutha esikhathi sokusebenza:

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

Amanye amaphutha avame kakhulu kunamanye. Nawa amanye amaphutha avame kakhulu nokuthi angalungiswa kanjani.

I-ImagePullBackOff

Leli phutha livela lapho u-Kubernetes engakwazi ukuthola isithombe sesinye seziqukathi ze-pod. Nazi izizathu ezintathu ezivame kakhulu zalokhu:

1. Igama lesithombe alilungile - isibonelo, wenze iphutha kuso, noma isithombe asikho;
2. Umaka ongekho ucaciswe esithombeni;
3. Isithombe sigcinwe kurejista yangasese futhi i-Kubernetes ayinayo imvume yokusifinyelela.

Izizathu ezimbili zokuqala kulula ukuzisusa - vele ulungise igama lesithombe nomaka. Esimeni sakamuva, udinga ukufaka imininingwane yokubhalisa okuvaliwe ku-Secret bese wengeza izixhumanisi kukho kuma-pods. Embhalweni we-Kubernetes kukhona isibonelo lokhu kungenziwa kanjani.

I-Crash Loop Emuva Ivaliwe

U-Kubenetes uphonsa iphutha CrashLoopBackOff, uma isiqukathi singakwazi ukuqala. Lokhu ngokuvamile kwenzeka lapho:

1. Kukhona iphutha kuhlelo lokusebenza elivimbela ukuthi liqalise;
2. Isiqukathi kulungiswe ngokungalungile;
3. Ukuhlolwa kwe-Liveness kuhlulekile izikhathi eziningi kakhulu.

Kumele uzame ukufika ezingodweni usuka esitsheni ukuze uthole isizathu sokwehluleka kwayo. Uma kunzima ukufinyelela amalogi ngoba isiqukathi siqala kabusha ngokushesha, ungasebenzisa umyalo olandelayo:

kubectl logs <pod-name> --previous

Ibonisa imilayezo yephutha kusukela ekufakweni komuntu okwedlule kwesiqukathi.

RunContainerError

Leli phutha lenzeka uma isiqukathi sihluleka ukuqala. Ihambisana nesikhathi ngaphambi kokuthi isicelo siqaliswe. Ngokuvamile kubangelwa izilungiselelo ezingalungile, isibonelo:

• ukuzama ukukhweza ivolumu engekho njenge-ConfigMap noma Izimfihlo;
• zama ukukhweza ivolumu yokufunda kuphela njengokufunda bhala.

Ithimba likulungele kahle ukuhlaziya amaphutha anjalo kubectl describe pod <pod-name>.

Amaphodi asesimweni sokulinda

Uma isidaliwe, i-pod ihlala kuhulumeni Pending.

Kungani lokhu kwenzeka?

Nazi izizathu ezingaba khona (ngicabanga ukuthi isihleli sisebenza kahle):

1. Iqoqo alinazo izinsiza ezanele, njengamandla okucubungula kanye nenkumbulo, ukuze iqhube i-pod.
2. Into ifakwe endaweni yegama efanele ResourceQuota futhi ukudala i-pod kuzobangela ukuthi indawo yamagama idlulele ngale kwesabelo.
3. I-Pod iboshelwe kokuthi Okulindile PersistentVolumeClaim.

Kulokhu, kunconywa ukusebenzisa umyalo kubectl describe bese uhlola isigaba Events:

kubectl describe pod <pod name>

Uma kwenzeka amaphutha ahlobene ne ResourceQuotas, kunconywa ukubuka izingodo zeqoqo usebenzisa umyalo

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

Amaphodi awalungile

Uma i-pod ibhalwe njenge Running, kodwa ayikho esimweni Ready, kusho ukuhlola ukulungela kwayo (ukulungiselela uphenyo) yehluleka.

Uma lokhu kwenzeka, i-pod ayixhumeki kusevisi futhi akukho thrafikhi egelezela kuyo. Ukwehluleka ukuhlolwa kokulungela kubangelwa izinkinga kuhlelo lokusebenza. Kulokhu, ukuthola iphutha, udinga ukuhlaziya isigaba Events ekuphumeni komyalo kubectl describe.

2. Ukuxilongwa kwesevisi

Uma ama-pods abhalwe njenge Running и Ready, kodwa namanje ayikho impendulo evela kuhlelo lokusebenza, kufanele uhlole izilungiselelo zesevisi.

Amasevisi anesibopho sokuyisa ithrafikhi kuma-pods kuye ngamalebula awo. Ngakho-ke, into yokuqala okudingeka uyenze ukuhlola ukuthi mangaki ama-pods asebenza nesevisi. Ukuze wenze lokhu, ungabheka iziphetho kusevisi:

kubectl describe service <service-name> | grep Endpoints

Iphoyinti lokugcina liyipheya lamanani efomu <IP-адрес:порт>, futhi okungenani okukodwa okufanayo kufanele kube khona kokuphumayo (okungukuthi, okungenani i-pod eyodwa isebenza nesevisi).

Uma isigaba Endpoins kungenalutho, izinketho ezimbili zingenzeka:

1. awekho ama-pods anelebula elifanele (ukusikisela: hlola ukuthi indawo yegama ikhethwe ngendlela efanele);
2. Kunephutha kumalebula wesevisi kusikhethi.

Uma ubona uhlu lwamaphoyinti okugcina kodwa ungakwazi ukufinyelela uhlelo lokusebenza, khona-ke okungenzeka ukuthi umlandu uyisiphazamiso. targetPort encazelweni yesevisi.

Ungahlola kanjani ukusebenza kwesevisi?

Kungakhathaliseki ukuthi hlobo luni lwesevisi, ungasebenzisa umyalo kubectl port-forward ukuxhuma kuyo:

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

Lapha:

• <service-name> - igama lesevisi;
• 3000 ichweba olivula kukhompyutha;
• 80 - ichweba ohlangothini lwenkonzo.

3. Ukuxilongwa kwe-Ingress

Uma ufunde kuze kube manje, khona-ke:

• ama-pods abhalwe njenge Running и Ready;
• isevisi isabalalisa ngempumelelo ithrafikhi kuwo wonke ama-pods.

Nokho, awukakwazi ukufinyelela uhlelo lokusebenza.

Lokhu kusho ukuthi isilawuli se-Ingress cishe asilungiselelwe kahle. Njengoba isilawuli se-Ingress siyingxenye yenkampani yangaphandle kuqoqo, kunezindlela ezihlukene zokususa iphutha kuye ngohlobo lwaso.

Kodwa ngaphambi kokuthi usebenzise amathuluzi akhethekile ukuze ulungiselele i-Ingress, ungenza into elula kakhulu. I-Ingress isebenzisa serviceName и servicePort ukuxhuma kusevisi. Udinga ukuhlola ukuthi zilungiswe kahle yini. Ungakwenza lokhu usebenzisa umyalo:

kubectl describe ingress <ingress-name>

Uma ikholomu Backend ayinalutho, maningi amathuba okuthi kube nephutha lokumisa. Uma ama-backends ekhona, kodwa uhlelo lokusebenza lungakafinyeleli, khona-ke inkinga ingase ihlobane nokuthi:

• Ngena izilungiselelo zokufinyeleleka kusukela ku-inthanethi yomphakathi;
• izilungiselelo zokufinyeleleka zeqoqo kusuka ku-inthanethi yomphakathi.

Ungakwazi ukubona izinkinga nengqalasizinda ngokuxhuma ngqo ku-Ingress pod. Ukuze wenze lokhu, qala uthole i-Ingress Controller pod (ingase ibe sendaweni yamagama ehlukile):

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

Sebenzisa umyalo describeukusetha imbobo:

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

Ekugcineni, xhuma ku-pod:

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

Manje zonke izicelo zokuthutha i-3000 kukhompyutha zizoqondiswa kabusha ku-port 80 ye-pod.

Ingabe iyasebenza manje?

• Uma kunjalo, inkinga ikungqalasizinda. Kuyadingeka ukuthola ukuthi ithrafikhi ihanjiswa kanjani ku-cluster.
• Uma kungenjalo, khona-ke inkinga isilawuli se-Ingress.

Uma ungakwazi ukwenza isilawuli se-Ingress sisebenze, kuzodingeka usisuse iphutha.

Kunezinhlobo eziningi zezilawuli ze-Ingress. Okudume kakhulu yiNginx, HAProxy, Traefik, njll. (ukuthola ulwazi olwengeziwe mayelana nezixazululo ezikhona, bheka isibuyekezo sethu - cishe. transl.) Kufanele ubhekisele kumhlahlandlela wokuxazulula inkinga kumadokhumenti wesilawuli esifanele. Ngoba i Ingress Nginx iyisilawuli se-Ingress esidume kakhulu, sifake amathiphu esihlokweni sokuxazulula izinkinga ezihlobene naso.

Ukulungisa iphutha isilawuli se-Ingress Nginx

Iphrojekthi ye-Ingress-nginx inesikhulu i-plugin ye-kubectl. Ithimba kubectl ingress-nginx ingasetshenziselwa:

• ukuhlaziywa kwamalogi, ama-backends, izitifiketi, njll.;
• ukuxhumana ku-Ingress;
• ukufunda ukucushwa kwamanje.

Imiyalo emithathu elandelayo izokusiza kulokhu:

• kubectl ingress-nginx lint - amasheke nginx.conf;
• kubectl ingress-nginx backend - ihlola ingemuva (elifana ne kubectl describe ingress <ingress-name>);
• kubectl ingress-nginx logs — uhlola izingodo.

Qaphela ukuthi kwezinye izimo ungase udinge ukucacisa indawo yegama efanele yesilawuli se-Ingress usebenzisa ifulegi --namespace <name>.

Isifingqo

Ukuxazulula inkinga ku-Kubernetes kungaba inselele uma ungazi ukuthi ungaqala kuphi. Kufanele ngaso sonke isikhathi ubhekane nenkinga ngendlela eya phezulu: qala ngama-pods, bese udlulela kusevisi kanye ne-Ingress. Izindlela zokususa iphutha ezichazwe kulesi sihloko zingasetshenziswa kwezinye izinto, njenge:

• Imisebenzi engenzi lutho kanye neCronJobs;
• I-StatefulSets ne-DaemonSets.

Ngizwakalisa ukubonga kwami Gergely Risko, Daniel Weibel и UCharles Christyraj ukuze uthole ukuphawula okubalulekile kanye nezengezo.

I-PS evela kumhumushi

Funda futhi kubhulogi yethu:

• «i-plugin ye-kubectl-debug yokususa iphutha kuma-pods e-Kubernetes";
• «Izimbungulu zesistimu yokuzijabulisa eyi-6 ekusebenzeni kwe-Kubernetes [nesixazululo sazo]";
• «Amathuluzi onjiniyela bezinhlelo zokusebenza ezisebenza ku-Kubernetes";
• «Izindaba ezisebenzayo ezi-6 ezivela empilweni yethu yansuku zonke ye-SRE ".

Source: www.habr.com