ვიზუალური გზამკვლევი კუბერნეტის პრობლემების გადასაჭრელად

Შენიშვნა. თარგმნა: ეს სტატია არის საჯარო დომენში გამოქვეყნებული პროექტის მასალების ნაწილი Learnk8s, ამზადებს კომპანიებსა და ინდივიდუალურ ადმინისტრატორებს Kubernetes-თან მუშაობისთვის. მასში, დანიელ პოლენჩიჩი, პროექტის მენეჯერი, იზიარებს ვიზუალურ ინსტრუქციებს იმის შესახებ, თუ რა ნაბიჯები უნდა გადადგას K8s კლასტერზე გაშვებულ აპლიკაციებთან დაკავშირებული ზოგადი პრობლემების შემთხვევაში.

TL;DR: აქ არის დიაგრამა, რომელიც დაგეხმარებათ Kubernetes-ში განლაგების გამართვაში:

ნაკადის სქემა კლასტერში შეცდომების პოვნისა და დაფიქსირებისთვის. ორიგინალი (ინგლისურად) ხელმისაწვდომია მისამართზე PDF и როგორც სურათი.

Kubernetes-ში აპლიკაციის განლაგებისას, როგორც წესი, სამი კომპონენტი უნდა განისაზღვროს:

• განლაგება - ეს არის ერთგვარი რეცეპტი აპლიკაციის ასლების შესაქმნელად, სახელწოდებით pods;
• სამსახურის - შიდა დატვირთვის ბალანსერი, რომელიც ანაწილებს ტრაფიკს პოდებს შორის;
• Ingress — აღწერა, თუ როგორ მოხვდება ტრაფიკი გარე სამყაროდან სერვისამდე.

აქ არის სწრაფი გრაფიკული შეჯამება:

1) Kubernetes-ში აპლიკაციები იღებენ ტრაფიკს გარე სამყაროდან დატვირთვის ბალანსერის ორი ფენის მეშვეობით: შიდა და გარე.

2) შიდა ბალანსერს ეწოდება სერვისი, გარეს - ინგრესი.

3) Deployment ქმნის პოდებს და აკონტროლებს მათ (ისინი არ არის შექმნილი ხელით).

ვთქვათ, რომ გსურთ განათავსოთ მარტივი აპლიკაცია a la გამარჯობა მსოფლიო. მისთვის 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 და Services ერთმანეთთან. სამი რამ უნდა გვახსოვდეს:

1. ამომრჩევი (selector) სერვისისთვის უნდა შეესაბამებოდეს მინიმუმ ერთ პოდ ლეიბლს.
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-ის მიერ პოდების თვალყურის დევნებისთვის.

დავუშვათ, რომ თქვენ გააკეთეთ სწორი რედაქტირება. როგორ შევამოწმოთ ისინი?

შეგიძლიათ შეამოწმოთ pod ლეიბლი შემდეგი ბრძანებით:

kubectl get pods --show-labels

ან, თუ პოდი ეკუთვნის რამდენიმე აპლიკაციას:

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

Где any-name=my-app არის ეტიკეტი any-name: my-app.

დარჩა რაიმე სირთულე?

შეგიძლიათ დაკავშირება pod! ამისათვის თქვენ უნდა გამოიყენოთ ბრძანება port-forward კუბექტლში. ის საშუალებას გაძლევთ დაუკავშირდეთ სერვისს და შეამოწმოთ კავშირი.

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 pod (ის შეიძლება იყოს სხვა სახელების სივრცეში) და გაუშვით ბრძანება 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. სელექტორი სერვისის განსაზღვრაში უნდა ემთხვეოდეს პოდის ეტიკეტს;
2. targetPort განმარტებაში სერვისი უნდა ემთხვეოდეს containerPort კონტეინერი ყდის შიგნით;
3. port განმარტებაში სერვისი შეიძლება იყოს ნებისმიერი. სხვადასხვა სერვისებს შეუძლიათ გამოიყენონ ერთი და იგივე პორტი, რადგან მათ აქვთ განსხვავებული IP მისამართები;
4. servicePort შემოსვლა უნდა ემთხვეოდეს port სამსახურის განმარტებაში;
5. სერვისის სახელი უნდა შეესაბამებოდეს ველს serviceName ინგრესში.

სამწუხაროდ, საკმარისი არ არის იმის ცოდნა, თუ როგორ სწორად ააწყოთ 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

ზემოთ მოყვანილ ბრძანებაში, ბოლო pod არის ჩამოთვლილი, როგორც Running и Readyთუმცა დანარჩენ ორზე ეს ასე არ არის.

როგორ გავიგოთ, რა მოხდა?

არსებობს ოთხი სასარგებლო ბრძანება ძაფების დიაგნოსტიკისთვის:

1. kubectl logs <имя pod'а> საშუალებას გაძლევთ ამოიღოთ მორები კონტეინერებიდან ყუთში;
2. kubectl describe pod <имя pod'а> საშუალებას გაძლევთ ნახოთ პოდთან დაკავშირებული მოვლენების სია;
3. kubectl get pod <имя pod'а> საშუალებას გაძლევთ მიიღოთ Kubernetes-ში შენახული pod-ის YAML კონფიგურაცია;
4. kubectl exec -ti <имя pod'а> bash საშუალებას გაძლევთ გაუშვათ ინტერაქტიული ბრძანების ჭურვი ერთ-ერთ პოდ კონტეინერში

რომელი უნდა აირჩიოთ?

ფაქტია, რომ არ არსებობს უნივერსალური ბრძანება. მათი კომბინაცია უნდა იქნას გამოყენებული.

ჯიშის ტიპიური პრობლემები

პოდ შეცდომების ორი ძირითადი ტიპია: გაშვების შეცდომები და გაშვების შეცდომები.

გაშვების შეცდომები:

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

მუშაობის დროის შეცდომები:

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

ზოგიერთი შეცდომა უფრო ხშირია, ვიდრე სხვები. აქ არის რამოდენიმე ყველაზე გავრცელებული შეცდომა და როგორ გამოვასწოროთ ისინი.

ImagePullBackOff

ეს შეცდომა ჩნდება, როდესაც Kubernetes ვერ ახერხებს სურათის მიღებას ერთ-ერთი pod კონტეინერისთვის. აქ არის ამის სამი ყველაზე გავრცელებული მიზეზი:

1. სურათის სახელი არასწორია - მაგალითად, თქვენ მასში შეცდომა დაუშვით, ან სურათი არ არსებობს;
2. სურათზე მითითებული იყო არარსებული ტეგი;
3. სურათი ინახება პირად რეესტრში და Kubernetes-ს არ აქვს მასზე წვდომის ნებართვა.

პირველი ორი მიზეზის აღმოფხვრა ადვილია - უბრალოდ შეასწორეთ სურათის სახელი და ტეგი. ამ უკანასკნელის შემთხვევაში, თქვენ უნდა შეიყვანოთ დახურული რეესტრის რწმუნებათა სიგელები Secret-ში და დაამატოთ მასზე ბმულები პოდებში. კუბერნეტის დოკუმენტაციაში არის მაგალითი როგორ შეიძლება ეს გაკეთდეს.

Crash Loop უკან გამორთვა

კუბენეტესი უშვებს შეცდომას CrashLoopBackOffთუ კონტეინერი ვერ დაიწყება. ეს ჩვეულებრივ ხდება მაშინ, როდესაც:

1. აპლიკაციაში არის შეცდომა, რომელიც ხელს უშლის მის გაშვებას;
2. კონტეინერი არასწორად კონფიგურირებული;
3. Liveness ტესტი ძალიან ბევრჯერ ჩავარდა.

თქვენ უნდა სცადოთ კონტეინერიდან მორების მოხვედრა, რათა გაარკვიოთ მისი წარუმატებლობის მიზეზი. თუ ჟურნალებში წვდომა რთულია, რადგან კონტეინერი ძალიან სწრაფად გადაიტვირთება, შეგიძლიათ გამოიყენოთ შემდეგი ბრძანება:

kubectl logs <pod-name> --previous

ის აჩვენებს შეცდომის შეტყობინებებს კონტეინერის წინა ინკარნაციიდან.

RunContainerError

ეს შეცდომა ჩნდება, როდესაც კონტეინერი ვერ ამუშავებს. ის შეესაბამება აპლიკაციის გაშვებამდე მომენტს. ეს ჩვეულებრივ გამოწვეულია არასწორი პარამეტრებით, მაგალითად:

• არარსებული ტომის დამონტაჟების მცდელობა, როგორიცაა ConfigMap ან Secrets;
• მხოლოდ წაკითხვადი ტომის წაკითხვა-ჩაწერის სახით დაყენების მცდელობა.

გუნდი კარგად არის შესაფერისი ასეთი შეცდომების გასაანალიზებლად kubectl describe pod <pod-name>.

პოდები მოლოდინშია

შექმნის შემდეგ, პოდი რჩება მდგომარეობაში Pending.

რატომ ხდება ეს?

აქ არის შესაძლო მიზეზები (ვვარაუდობ, რომ გრაფიკი კარგად მუშაობს):

1. კლასტერს არ აქვს საკმარისი რესურსები, როგორიცაა დამუშავების სიმძლავრე და მეხსიერება, პოდის გასაშვებად.
2. ობიექტი დაინსტალირებულია შესაბამის სახელთა სივრცეში ResourceQuota და pod შექმნა გამოიწვევს სახელთა სივრცის კვოტის მიღმა.
3. Pod მიბმულია მომლოდინე PersistentVolumeClaim.

ამ შემთხვევაში რეკომენდებულია ბრძანების გამოყენება kubectl describe და შეამოწმეთ განყოფილება Events:

kubectl describe pod <pod name>

დაკავშირებული შეცდომების შემთხვევაში ResourceQuotas, რეკომენდებულია კლასტერული ჟურნალების ნახვა ბრძანების გამოყენებით

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

ტოტები მზად არ არის

თუ პოდი ჩამოთვლილია როგორც Running, მაგრამ არ არის მდგომარეობაში Ready, ნიშნავს მისი მზადყოფნის შემოწმებას (მზადყოფნის ზონდი) მარცხდება.

როდესაც ეს მოხდება, პოდი არ უკავშირდება სერვისს და არ მიედინება მასზე ტრაფიკი. მზადყოფნის ტესტის წარუმატებლობა გამოწვეულია აპლიკაციაში არსებული პრობლემებით. ამ შემთხვევაში, შეცდომის მოსაძებნად, საჭიროა განყოფილების ანალიზი 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-ის კონფიგურაციისთვის სპეციალურ ინსტრუმენტებს მიმართავთ, შეგიძლიათ გააკეთოთ რაღაც ძალიან მარტივი. Ingress იყენებს serviceName и servicePort სერვისთან დასაკავშირებლად. თქვენ უნდა შეამოწმოთ, არის თუ არა ისინი სწორად კონფიგურირებული. ამის გაკეთება შეგიძლიათ ბრძანების გამოყენებით:

kubectl describe ingress <ingress-name>

თუ სვეტი Backend ცარიელია, კონფიგურაციის შეცდომის დიდი ალბათობაა. თუ სარეზერვო სისტემა ადგილზეა, მაგრამ აპლიკაცია ჯერ კიდევ მიუწვდომელია, მაშინ პრობლემა შეიძლება დაკავშირებული იყოს:

• წვდომის პარამეტრების შესვლა საჯარო ინტერნეტიდან;
• კლასტერული ხელმისაწვდომობის პარამეტრები საჯარო ინტერნეტიდან.

ინფრასტრუქტურასთან დაკავშირებული პრობლემების იდენტიფიცირება შეგიძლიათ უშუალოდ Ingress pod-თან დაკავშირებით. ამისათვის ჯერ იპოვეთ Ingress Controller pod (ის შეიძლება იყოს სხვა სახელების სივრცეში):

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 და ა.შ. (დამატებითი ინფორმაციისთვის არსებული გადაწყვეტილებების შესახებ იხ ჩვენი მიმოხილვა - დაახლ. თარგმანი.) თქვენ უნდა მიმართოთ პრობლემების მოგვარების სახელმძღვანელოს შესაბამის კონტროლერის დოკუმენტაციაში. Იმიტომ რომ Ingress 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 - ამოწმებს ჟურნალებს.

გაითვალისწინეთ, რომ ზოგიერთ შემთხვევაში შეიძლება დაგჭირდეთ დროშის გამოყენებით Ingress კონტროლერის სწორი სახელების სივრცის მითითება --namespace <name>.

რეზიუმე

Kubernetes-ის პრობლემების მოგვარება შეიძლება რთული იყოს, თუ არ იცით საიდან დაიწყოთ. თქვენ ყოველთვის უნდა მიუდგეთ პრობლემას ქვემოდან ზევით: დაიწყეთ პოდებით და შემდეგ გადადით სერვისზე და Ingress-ზე. ამ სტატიაში აღწერილი გამართვის ტექნიკა შეიძლება გამოყენებულ იქნას სხვა ობიექტებზე, როგორიცაა:

• უმოქმედო ჯობსი და CronJobs;
• StatefulSets და DaemonSets.

მადლიერებას გამოვხატავ გერგელი რისკო, დანიელ ვეიბელი и ჩარლზ კრისტირაჟი ღირებული კომენტარებისა და დამატებისთვის.

PS მთარგმნელისგან

ასევე წაიკითხეთ ჩვენს ბლოგზე:

• «kubectl-debug დანამატი Kubernetes pods-ში გამართვისთვის";
• «6 გასართობი სისტემის შეცდომა Kubernetes-ის მუშაობაში [და მათი გადაწყვეტა]";
• «ინსტრუმენტები Kubernetes-ზე გაშვებული აპლიკაციების დეველოპერებისთვის";
• «6 პრაქტიკული ამბავი ჩვენი SRE ყოველდღიური ცხოვრებიდან ".

წყარო: www.habr.com