Дастури визуалӣ барои бартараф кардани мушкилот дар Kubernetes

Шарҳ. тарҷума.: Ин мақола як қисми маводи лоиҳаест, ки дар домени ҷамъиятӣ нашр шудаанд Learnk8s, таълим додани ширкатҳо ва маъмурони инфиродӣ барои кор бо Kubernetes. Дар он, Даниэле Поленчич, менеҷери лоиҳа, дастурҳои визуалиро дар бораи он, ки дар сурати мушкилоти умумӣ бо замимаҳои дар кластери K8s коркунанда чӣ чораҳо андешидан лозим аст, мубодила мекунад.

TL; DR: ин диаграммаест, ки ба шумо барои ислоҳи ислоҳ дар Кубернетес кӯмак мекунад:

Ҷадвал барои дарёфт ва ислоҳи хатогиҳо дар кластер. Нусхаи аслӣ (ба забони англисӣ) дар ин ҷо дастрас аст PDF и ҳамчун расм.

Ҳангоми ҷойгиркунии барнома ба Kubernetes, одатан се ҷузъ вуҷуд доранд, ки шумо бояд муайян кунед:

• љойгиркунии - ин як навъ дорухат барои эҷоди нусхаҳои замима мебошад, ки онро pods меноманд;
• хизматрасонӣ — тавозуни сарбории дохилӣ, ки трафикро дар байни қуттиҳо тақсим мекунад;
• Ingress - тавсифи он, ки трафик аз ҷаҳони беруна ба хидмат чӣ гуна хоҳад расид.

Ин аст мухтасари графикии зуд:

1) Дар Кубернетес, барномаҳо трафикро аз ҷаҳони беруна тавассути ду қабати мувозинатҳои сарборӣ қабул мекунанд: дохилӣ ва берунӣ.

2) Тавозуни дохилӣ Сервис номида мешавад, берунӣ Ingress номида мешавад.

3) Ҷойгиркунӣ pods эҷод мекунад ва онҳоро назорат мекунад (онҳо дастӣ сохта намешаванд).

Фарз мекунем, ки шумо мехоҳед як барномаи оддиро ҷойгир кунед Салом Ҷаҳон. Конфигуратсияи YAML барои он чунин хоҳад буд:

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

Таъриф хеле дароз аст ва дар бораи робитаи ҷузъҳо бо ҳамдигар ошуфта шудан осон аст.

Масалан:

• Кай шумо бояд порти 80-ро истифода баред ва кай бояд 8080-ро истифода баред?
• Оё ман бояд барои ҳар як хидмат бандари нав созам, то онҳо ихтилоф накунанд?
• Оё номҳои нишонаҳо аҳамият доранд? Оё онҳо бояд дар ҳама ҷо якхела бошанд?

Пеш аз он ки ба хатогиҳо диққат диҳем, биёед дар хотир дорем, ки ин се ҷузъ бо ҳамдигар чӣ гуна робита доранд. Биёед аз ҷойгиркунӣ ва хидмат оғоз кунем.

Муносибати байни ҷойгиркунӣ ва хидмат

Шумо ҳайрон хоҳед шуд, аммо Ҷойгиркунӣ ва хидматҳо ба ҳеҷ ваҷҳ пайваст нестанд. Ба ҷои ин, Хидмат мустақиман ба Pods ишора мекунад, ки ҷойгиркуниро аз байн мебарад.

Ҳамин тариқ, мо ба он таваҷҷӯҳ дорем, ки Pods ва Хидматҳо бо ҳам алоқаманданд. Се чизро бояд дар хотир дошт:

1. Интихобкунанда (selector) барои Хизмат бояд ҳадди аққал як нишони Pod мувофиқат кунад.
2. targetPort мувофиқат бояд кард containerPort контейнер дар дохили Под.
3. port Хизмат метавонад ҳама чиз бошад. Хидматҳои гуногун метавонанд як портро истифода баранд, зеро онҳо суроғаҳои IP-и гуногун доранд.

Диаграммаи зерин ҳама чизҳои дар боло зикршударо дар шакли графикӣ ифода мекунад:

1) Тасаввур кунед, ки хадамот трафикро ба як қуттии муайян равона мекунад:

2) Ҳангоми сохтани подк, шумо бояд муайян кунед containerPort барои ҳар як контейнер дар қуттиҳо:

3) Ҳангоми сохтани хидмат, шумо бояд муайян кунед port и targetPort. Аммо кадомаш барои пайвастшавӣ ба контейнер истифода мешавад?

4) Тавассути targetPort. Он бояд мувофиқат кунад containerPort.

5) Фарз мекунем, ки порти 3000 дар контейнер кушода аст.Баъд арзиши targetPort бояд якхела бошад.

Дар файли YAML, тамғакоғазҳо ва ports / targetPort бояд мувофиқ бошад:

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

Дар бораи тамғакоғаз чӣ гуфтан мумкин аст track: canary дар болои бахши Ҷойгиркунӣ? Оё он бояд мувофиқат кунад?

Ин нишона барои ҷойгиркунӣ хос аст ва аз ҷониби хидмат барои масири трафик истифода намешавад. Ба ибораи дигар, он метавонад хориҷ карда шавад ё арзиши дигар таъин карда шавад.

Дар бораи селектор чӣ гуфтан мумкин аст matchLabels?

Он бояд ҳамеша ба тамғакоғазҳои Pod мувофиқат кунад, зеро он аз ҷониби Deployment барои пайгирии pods истифода мешавад.

Фарз мекунем, ки шумо таҳрирҳои дуруст кардед. Чӣ тавр онҳоро тафтиш кардан мумкин аст?

Шумо метавонед тамғаи pod-ро бо фармони зерин тафтиш кунед:

kubectl get pods --show-labels

Ё, агар pods ба якчанд барнома тааллуқ дошта бошад:

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

Дар куҷо any-name=my-app нишона аст any-name: my-app.

Оё ягон душворӣ боқӣ мондааст?

Шумо метавонед ба подкаст пайваст шавед! Барои ин шумо бояд фармонро истифода баред port-forward дар kubectl. Он ба шумо имкон медиҳад, ки ба хидмат пайваст шавед ва пайвастшавиро тафтиш кунед.

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

Дар ин ҷо:

• service/<service name> — номи хизматрасонӣ; дар мавриди мо чунин аст my-service;
• 3000 портест, ки бояд дар компютер кушода шавад;
• 80 - порти дар майдон муайяншуда port хизмат.

Агар пайвастшавӣ муқаррар шуда бошад, пас танзимот дурустанд.

Агар пайвастшавӣ ноком шавад, дар нишонаҳо мушкилот вуҷуд дорад ё портҳо мувофиқат намекунанд.

Муносибати байни хидмат ва воридшавӣ

Қадами навбатӣ дар таъмини дастрасӣ ба барнома бо танзими Ingress алоқаманд аст. Дохилшавӣ бояд бидонад, ки чӣ гуна хидматро пайдо кунад, пас подкҳоро пайдо кунад ва трафикро ба онҳо равона кунад. Ingress хидмати лозимиро аз рӯи ном ва порти кушода пайдо мекунад.

Дар тавсифи Ingress ва Service ду параметр бояд мувофиқат кунанд:

1. servicePort дар Ingress бояд ба параметр мувофиқат кунад port дар хидмат;
2. serviceName дар Ingress бояд майдони мувофиқат name дар Хизмат.

Диаграммаи зерин пайвастҳои портро ҷамъбаст мекунад:

1) Тавре ки шумо аллакай медонед, Хизмат ба як нафар гӯш медиҳад port:

2) Ingress дорои параметрест, ки номида мешавад servicePort:

3) Ин параметр (servicePort) бояд ҳамеша мувофиқат кунад port дар таърифи хидмат:

4) Агар дар Сервис порти 80 муайян карда шуда бошад, пас ин зарур аст servicePort инчунин ба 80 баробар буд:

Дар амал, шумо бояд ба сатрҳои зерин диққат диҳед:

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

Чӣ тавр тафтиш кардан мумкин аст, ки Ingress кор мекунад?

Шумо метавонед усулро бо истифода баред kubectl port-forward, аммо ба ҷои хидмат шумо бояд ба контроллери Ingress пайваст шавед.

Аввалан шумо бояд номи подкастро бо контроллери 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

Пойгоҳи Ingress-ро пайдо кунед (он метавонад дар фазои номҳои дигар бошад) ва фармонро иҷро кунед describeБарои фаҳмидани рақамҳои порт:

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

Ниҳоят, ба подкаст пайваст шавед:

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

Ҳоло ҳар дафъае, ки шумо ба порти 3000 дар компютери худ дархост мефиристед, он ба порти 80-и подкаст бо контроллери Ingress интиқол дода мешавад. Бо рафтан ба http://localhost:3000, шумо бояд саҳифаеро бинед, ки аз ҷониби барнома тавлид шудааст.

Хулосаи портҳо

Биёед бори дигар дар хотир дорем, ки кадом портҳо ва нишонаҳо бояд мувофиқат кунанд:

1. Интихобкунанда дар таърифи Хизматрасонӣ бояд ба тамғаи pod мувофиқат кунад;
2. targetPort дар таърифи Хадамоти бояд мувофиқат кунад containerPort контейнер дар дохили қуттӣ;
3. port дар таъриф Хизмат метавонад ҳама чиз бошад. Хидматҳои гуногун метавонанд як портро истифода баранд, зеро онҳо суроғаҳои IP-и гуногун доранд;
4. servicePort Воридшавӣ бояд мувофиқат кунад port дар таърифи Хидмат;
5. Номи хидмат бояд бо майдон мувофиқ бошад serviceName дар Ingress.

Мутаассифона, донистани тарзи дурусти сохтори конфигуратсияи YAML кофӣ нест.

Вақте ки корҳо нодуруст мешаванд, чӣ мешавад?

Подшоҳ метавонад оғоз нашавад ё он метавонад садама кунад.

3 Қадам барои ташхиси мушкилоти барнома дар Kubernetes

Пеш аз он ки шумо ислоҳ кардани ҷойгиркунии худро оғоз кунед, шумо бояд фаҳмиши хубе дошта бошед, ки чӣ тавр Kubernetes кор мекунад.

Азбаски ҳар як замимаи дар K8s зеркашидашуда се ҷузъ дорад, онҳо бояд бо тартиби муайян аз поён сар карда ислоҳ карда шаванд.

1. Аввал шумо бояд боварӣ ҳосил кунед, ки қубурҳо кор мекунанд, баъд ...
2. Санҷед, ки оё хидмат трафикро ба қуттиҳо таъмин мекунад ва сипас...
3. Санҷед, ки оё Ingress дуруст танзим шудааст.

Намоиши визуалӣ:

1) Шумо бояд аз поён ба ҷустуҷӯи мушкилот шурӯъ кунед. Аввал санҷед, ки поддонҳо статус доранд Ready и Running:

2) Агар қуттиҳо омода бошанд (Ready), шумо бояд бифаҳмед, ки оё хидмат трафикро байни подкҳо тақсим мекунад:

3) Дар ниҳоят, шумо бояд робитаи байни хидмат ва Ingress-ро таҳлил кунед:

1. Диагностикаи гулҳо

Дар аксари мавридҳо, мушкилот бо популятсия алоқаманд аст. Боварӣ ҳосил кунед, ки қубурҳо ҳамчун рӯйхат шудаанд Ready и Running. Шумо метавонед инро бо истифода аз фармон санҷед:

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

Дар баромади фармони боло, поди охирин ҳамчун рӯйхат оварда шудааст Running и Ready, вале дар дуи дигар ин тавр нест.

Чӣ тавр фаҳмидан мумкин аст, ки чӣ хато кардааст?

Чор фармони муфид барои ташхиси pods вуҷуд дорад:

1. kubectl logs <имя pod'а> ба шумо имкон медиҳад, ки гузоришҳоро аз контейнерҳо дар як паҳлӯ гиред;
2. kubectl describe pod <имя pod'а> ба шумо имкон медиҳад, ки рӯйхати рӯйдодҳои бо pod алоқамандро дидан кунед;
3. kubectl get pod <имя pod'а> ба шумо имкон медиҳад, ки конфигуратсияи YAML-и подкале, ки дар Kubernetes нигоҳ дошта мешавад, гиред;
4. kubectl exec -ti <имя pod'а> bash ба шумо имкон медиҳад, ки дар яке аз контейнерҳои pod як қабати фармони интерактивиро оғоз кунед

Кадомашро бояд интихоб кард?

Гап дар сари он аст, ки ягон фармони универсалй нест. Маҷмӯи инҳо бояд истифода шавад.

Мушкилоти маъмулии қуттиҳо

Ду намуди асосии хатогиҳо вуҷуд доранд: хатогиҳои оғозёбӣ ва хатогиҳои вақти корӣ.

Хатогиҳои оғозёбӣ:

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

Хатогиҳои вақти иҷро:

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

Баъзе хатогиҳо нисбат ба дигарон бештар маъмуланд. Дар ин ҷо баъзе аз хатогиҳои маъмултарин ва роҳҳои ислоҳ кардани онҳо ҳастанд.

ImagePullBackOff

Ин хато вақте пайдо мешавад, ки Kubernetes наметавонад тасвирро барои яке аз контейнерҳои подшоҳӣ ба даст орад. Инҳоянд се сабаби маъмултарини ин:

1. Номи тасвир нодуруст аст - масалан, шумо дар он хато кардаед ё тасвир вуҷуд надорад;
2. Барои тасвир барчасп вуҷуд надошт;
3. Тасвир дар феҳристи хусусӣ нигоҳ дошта мешавад ва Кубернетес барои дастрасӣ ба он иҷозат надорад.

Ду сабаби аввалро бартараф кардан осон аст - танҳо номи тасвир ва барчаспро ислоҳ кунед. Дар мавриди охирин, ба шумо лозим аст, ки маълумоти эътимодномаро барои реестри пӯшида дар Secret ворид кунед ва ба он дар подкастҳо истинодҳо илова кунед. Дар ҳуҷҷатҳои Kubernetes мисоле ҳаст ин корро чй тавр кардан мумкин аст.

Crash Loop Бозгашт Хомӯш

Kubenetes хато мекунад CrashLoopBackOff, агар контейнер оғоз карда натавонад. Ин одатан вақте рух медиҳад:

1. Дар барнома хатое мавҷуд аст, ки ба оғози он халал мерасонад;
2. Контейнер нодуруст танзим карда шудааст;
3. Санҷиши Зиндагӣ борҳо ноком шудааст.

Шумо бояд кӯшиш кунед, ки аз контейнер ба гузоришҳо ворид шавед, то сабаби нокомии онро фаҳмед. Агар дастрасӣ ба гузоришҳо душвор бошад, зеро контейнер хеле зуд бозоғоз мешавад, шумо метавонед фармони зеринро истифода баред:

kubectl logs <pod-name> --previous

Он паёмҳои хатогиро аз таҷассуми қаблии контейнер нишон медиҳад.

RunContainer Error

Ин хато вақте рух медиҳад, ки контейнер оғоз нашавад. Он ба лаҳзаи пеш аз оғози барнома мувофиқат мекунад. Он одатан дар натиҷаи танзимоти нодуруст ба вуҷуд меояд, масалан:

• кӯшиши насб кардани ҳаҷми мавҷуда ба монанди ConfigMap ё Secrets;
• кӯшиши насб кардани ҳаҷми танҳо барои хондан ҳамчун хондан-навиштан.

Гурӯҳ барои таҳлили чунин хатогиҳо хеле мувофиқ аст kubectl describe pod <pod-name>.

Подҳо дар ҳолати интизорӣ қарор доранд

Пас аз офарида шудан, поддон дар ҳолат мемонад Pending.

Чаро ин рӯй медиҳад?

Инҳоянд сабабҳои эҳтимолӣ (ман гумон мекунам, ки нақшакаш хуб кор мекунад):

1. Кластер захираҳои кофӣ надорад, ба монанди қудрати коркард ва хотира, барои кор кардани подк.
2. Объект дар фазои номҳои мувофиқ насб карда мешавад ResourceQuota ва эҷоди подкҳо боиси он мегардад, ки фазои номҳо аз квота берун равад.
3. Под ба интизорӣ вобаста аст PersistentVolumeClaim.

Дар ин ҳолат тавсия дода мешавад, ки фармонро истифода баред kubectl describe ва қисматро тафтиш кунед Events:

kubectl describe pod <pod name>

Дар сурати хатогихои вобаста ба ResourceQuotas, тавсия дода мешавад, ки бо истифода аз фармон дидани гузоришҳои кластер

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

Подшоҳҳо омода нестанд

Агар pod ҳамчун рӯйхат бошад Running, вале дар холате нест Ready, маънои тафтиши тайёрии онро дорад (санҷиши омодагӣ) ноком мешавад.

Вақте ки ин рӯй медиҳад, pod ба хидмат пайваст намешавад ва ҳеҷ гуна трафик ба он ҷо намеояд. Нокомии санҷиши омодагӣ бо мушкилот дар барнома ба вуҷуд омадааст. Дар ин ҳолат, барои ёфтани хато, шумо бояд қисматро таҳлил кунед Events дар баромади фармон kubectl describe.

2. Ташхиси хидматрасонӣ

Агар подшоххо хамчун Running и Ready, аммо то ҳол аз барнома ҷавобе нест, шумо бояд танзимоти хидматро тафтиш кунед.

Хидматҳо барои масири трафик ба подкҳо вобаста аз нишонаҳояшон масъуланд. Аз ин рӯ, аввалин чизе, ки шумо бояд анҷом диҳед, санҷед, ки чӣ қадар поддонҳо бо хидмат кор мекунанд. Барои ин, шумо метавонед нуқтаҳои ниҳоии хидматро тафтиш кунед:

kubectl describe service <service-name> | grep Endpoints

Нуқтаи ниҳоӣ ҷуфти арзишҳои форма мебошад <IP-адрес:порт>, ва ҳадди аққал як чунин ҷуфт бояд дар баромад мавҷуд бошад (яъне ҳадди аққал як подк бо хидмат кор мекунад).

Агар бахш Endpoins холӣ, ду вариант имконпазир аст:

1. ягон подка бо нишони дуруст вуҷуд надорад (маслиҳат: санҷед, ки фазои ном дуруст интихоб шудааст ё не);
2. Дар тамғакоғазҳои хидмат дар селектор хатогӣ мавҷуд аст.

Агар шумо рӯйхати нуқтаҳои ниҳоиро бинед, вале то ҳол ба барнома дастрасӣ надоред, эҳтимолан гунаҳкор хато аст targetPort дар тавсифи хидмат.

Функсияи хидматро чӣ гуна бояд тафтиш кард?

Новобаста аз намуди хидмат, шумо метавонед фармонро истифода баред kubectl port-forward барои пайваст шудан ба он:

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

Дар ин ҷо:

• <service-name> — номи хизматрасонӣ;
• 3000 портест, ки шумо дар компютер мекушоед;
• 80 - порт дар тарафи хидмат.

3. Ташхиси воридшавӣ

Агар шумо то ҳол хонда бошед, пас:

• донаҳо ҳамчун рӯйхат оварда шудаанд Running и Ready;
• хидмат трафикро дар байни подкаҳо бомуваффақият тақсим мекунад.

Бо вуҷуди ин, шумо то ҳол ба барнома расида наметавонед.

Ин маънои онро дорад, ки контролери Ingress эҳтимолан дуруст танзим карда нашудааст. Азбаски контролери Ingress ҷузъи тарафи сеюм дар кластер аст, вобаста ба намуди он усулҳои гуногуни ислоҳкунӣ мавҷуданд.

Аммо пеш аз он ки шумо ба истифодаи асбобҳои махсус барои танзими Ingress муроҷиат кунед, шумо метавонед як чизи хеле соддаро иҷро кунед. Истифода мебарад serviceName и servicePort барои пайваст шудан ба хидмат. Шумо бояд тафтиш кунед, ки оё онҳо дуруст танзим шудаанд. Шумо метавонед ин корро бо истифода аз фармон:

kubectl describe ingress <ingress-name>

Агар сутун Backend холӣ аст, эҳтимолияти баланди хатои конфигуратсия вуҷуд дорад. Агар пуштибонҳо дар ҷои худ бошанд, аммо барнома то ҳол дастрас набошад, пас мушкилот метавонад бо:

• Танзимоти дастрасиро аз Интернети ҷамъиятӣ ворид кунед;
• танзимоти дастрасии кластер аз Интернети ҷамъиятӣ.

Шумо метавонед мушкилотро бо инфрасохтор тавассути пайвастшавӣ мустақиман ба pod Ingress муайян кунед. Барои ин кор, аввал подклики Ingress Controller -ро пайдо кунед (он метавонад дар фазои номҳои дигар бошад):

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

Фармонро истифода баред describeбарои насб кардани порт:

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

Ниҳоят, ба подкаст пайваст шавед:

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

Акнун ҳама дархостҳо ба порти 3000 дар компютер ба порти 80-и подкаст равона карда мешаванд.

Оё он ҳоло кор мекунад?

• Агар ҳа, пас мушкилот дар инфрасохтор аст. Бояд аниқ муайян кард, ки трафик ба кластер чӣ гуна равона карда мешавад.
• Агар не, пас мушкилот бо контроллери Ingress аст.

Агар шумо контроллери Ingress-ро ба кор дароварда натавонед, шумо бояд онро ислоҳ кунед.

Навъҳои зиёди контроллерҳои Ingress мавҷуданд. Маъмултарин Nginx, HAProxy, Traefik ва ғайра мебошанд. (барои маълумоти бештар дар бораи ҳалли мавҷуда, нигаред баррасии мо - тахминан. тарҷума.) Шумо бояд ба дастури ҳалли мушкилот дар ҳуҷҷатҳои дахлдори контроллер муроҷиат кунед. Зеро ки Nginx ворид кунед маъмултарин контролери Ingress аст, мо дар мақола якчанд маслиҳатҳоро барои ҳалли мушкилоти марбут ба он дохил кардем.

Ислоҳоти контролери Ingress Nginx

Лоиҳаи Ingress-nginx як мансабдор дорад плагин барои kubectl. Дастаи kubectl ingress-nginx барои мақсадҳои зерин истифода бурда мешавад:

• таҳлили гузоришҳо, пуштибонҳо, сертификатҳо ва ғайра;
• пайвастшавӣ ба Ingress;
• омӯхтани конфигуратсияи ҷорӣ.

Се фармони зерин ба шумо дар ин кор кӯмак мекунанд:

• kubectl ingress-nginx lint — чекхо nginx.conf;
• kubectl ingress-nginx backend — пуштибониро меомӯзад (монанди kubectl describe ingress <ingress-name>);
• kubectl ingress-nginx logs — журналхоро тафтиш мекунад.

Дар хотир доред, ки дар баъзе ҳолатҳо ба шумо лозим меояд, ки фазои дурусти номи контроллерро бо истифода аз парчам муайян кунед --namespace <name>.

Натиҷа

Бартараф кардани мушкилот дар Kubernetes метавонад душвор бошад, агар шумо намедонед, ки аз куҷо оғоз кунед. Шумо бояд ҳамеша ба мушкилот бо усули аз поён ба боло муроҷиат кунед: бо подкастҳо оғоз кунед ва сипас ба хидмат ва воридшавӣ гузаред. Усулҳои ислоҳи ислоҳи дар ин мақола тавсифшуда метавонанд ба объектҳои дигар татбиқ карда шаванд, масалан:

• ҷойҳои корӣ ва CronJobs;
• StatefulSets ва DaemonSets.

миннатдории худро баён мекунам Гергели Риско, Даниел Вайбел и Чарлз Кристираж барои эродхо ва иловахои пуркимат.

PS аз тарҷумон

Инчунин дар блоги мо хонед:

• «Васлкунаки kubectl-debug барои хатогиҳо дар қуттиҳои Kubernetes»;
• «6 хатогиҳои системаи фароғатӣ дар кори Kubernetes [ва ҳалли онҳо]»;
• «Асбобҳо барои таҳиягарони барномаҳое, ки дар Kubernetes кор мекунанд»;
• «6 ҳикояи амалӣ аз ҳаёти ҳаррӯзаи мо ".

Манбаъ: will.com