Ένας οπτικός οδηγός για την αντιμετώπιση προβλημάτων Kubernetes

Σημείωση. μετάφρ.: Αυτό το άρθρο είναι μέρος του υλικού του έργου που δημοσιεύεται σε δημόσιο τομέα Learnk8s, εκπαίδευση εταιρειών και μεμονωμένων διαχειριστών για συνεργασία με την Kubernetes. Σε αυτό, ο Daniele Polencic, διευθυντής έργου, μοιράζεται οπτικές οδηγίες σχετικά με τα βήματα που πρέπει να ληφθούν σε περίπτωση γενικών προβλημάτων με εφαρμογές που εκτελούνται στο σύμπλεγμα K8s.

TL;DR: εδώ είναι ένα διάγραμμα που θα σας βοηθήσει να εντοπίσετε σφάλματα στην ανάπτυξη στο Kubernetes:

Διάγραμμα ροής για εύρεση και διόρθωση σφαλμάτων σε ένα σύμπλεγμα. Το πρωτότυπο (στα αγγλικά) είναι διαθέσιμο στη διεύθυνση PDF и ως εικόνα.

Κατά την ανάπτυξη μιας εφαρμογής στο Kubernetes, υπάρχουν συνήθως τρία στοιχεία που πρέπει να ορίσετε:

• Ανάπτυξη - αυτό είναι ένα είδος συνταγής για τη δημιουργία αντιγράφων μιας εφαρμογής, που ονομάζεται pods.
• Υπηρεσία — Εσωτερικός εξισορροπητής φορτίου που κατανέμει την κυκλοφορία μεταξύ των pods.
• Είσοδος — περιγραφή του τρόπου με τον οποίο θα φτάσει η κίνηση από τον έξω κόσμο στην Υπηρεσία.

Ακολουθεί μια γρήγορη γραφική περίληψη:

1) Στο Kubernetes, οι εφαρμογές λαμβάνουν κίνηση από τον έξω κόσμο μέσω δύο επιπέδων εξισορροπητών φορτίου: εσωτερικού και εξωτερικού.

2) Ο εσωτερικός εξισορροπητής ονομάζεται Service, ο εξωτερικός ονομάζεται Ingress.

3) Το Deployment δημιουργεί pods και τα παρακολουθεί (δεν δημιουργούνται χειροκίνητα).

Ας υποθέσουμε ότι θέλετε να αναπτύξετε μια απλή εφαρμογή 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;
• Πρέπει να δημιουργήσω μια νέα θύρα για κάθε υπηρεσία, ώστε να μην έρχονται σε διένεξη;
• Έχουν σημασία τα ονόματα των ετικετών; Πρέπει να είναι παντού το ίδιο;

Πριν εστιάσουμε στον εντοπισμό σφαλμάτων, ας θυμηθούμε πώς σχετίζονται τα τρία στοιχεία μεταξύ τους. Ας ξεκινήσουμε με το Deployment and Service.

Σχέση ανάπτυξης και εξυπηρέτησης

Θα εκπλαγείτε, αλλά οι αναπτύξεις και οι υπηρεσίες δεν συνδέονται με κανέναν τρόπο. Αντίθετα, το Service οδηγεί απευθείας στα Pods, παρακάμπτοντας την ανάπτυξη.

Έτσι, μας ενδιαφέρει πώς σχετίζονται τα Pods και οι Υπηρεσίες μεταξύ τους. Τρία πράγματα που πρέπει να θυμάστε:

1. Επιλογέας (selector) για το Service πρέπει να αντιστοιχεί τουλάχιστον σε μία ετικέτα Pod.
2. targetPort πρέπει να ταιριάζουν containerPort δοχείο μέσα στο Pod.
3. port Η εξυπηρέτηση μπορεί να είναι οτιδήποτε. Διαφορετικές υπηρεσίες μπορούν να χρησιμοποιούν την ίδια θύρα επειδή έχουν διαφορετικές διευθύνσεις IP.

Το παρακάτω διάγραμμα αναπαριστά όλα τα παραπάνω σε γραφική μορφή:

1) Φανταστείτε ότι η υπηρεσία κατευθύνει την κυκλοφορία σε ένα συγκεκριμένο pod:

2) Όταν δημιουργείτε ένα pod, πρέπει να καθορίσετε 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

Ή, εάν τα pod ανήκουν σε πολλές εφαρμογές:

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

Πού any-name=my-app είναι μια ετικέτα any-name: my-app.

Απομένουν δυσκολίες;

Μπορείτε να συνδεθείτε στο pod! Για να γίνει αυτό πρέπει να χρησιμοποιήσετε την εντολή port-forward στο kubectl. Σας επιτρέπει να συνδεθείτε στην υπηρεσία και να ελέγξετε τη σύνδεση.

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

Εδώ:

• service/<service name> - Όνομα Υπηρεσίας; στην περίπτωσή μας είναι my-service;
• Το 3000 είναι η θύρα που πρέπει να ανοίξει στον υπολογιστή.
• 80 - θύρα που καθορίζεται στο πεδίο port υπηρεσία.

Εάν η σύνδεση πραγματοποιήθηκε, τότε οι ρυθμίσεις είναι σωστές.

Εάν η σύνδεση αποτύχει, υπάρχει πρόβλημα με τις ετικέτες ή οι θύρες δεν ταιριάζουν.

Σχέση μεταξύ Service και Ingress

Το επόμενο βήμα για την παροχή πρόσβασης στην εφαρμογή σχετίζεται με τη ρύθμιση του Ingress. Η Ingress πρέπει να γνωρίζει πώς να βρίσκει μια υπηρεσία, στη συνέχεια να βρίσκει ομάδες και να κατευθύνει την επισκεψιμότητα σε αυτές. Το Ingress βρίσκει την απαιτούμενη υπηρεσία με το όνομα και την ανοιχτή θύρα.

Στην περιγραφή της εισόδου και της υπηρεσίας δύο παράμετροι πρέπει να ταιριάζουν:

1. servicePort στο Ingress πρέπει να ταιριάζει με την παράμετρο port σε υπηρεσία?
2. serviceName στο Ingress πρέπει να ταιριάζει με το πεδίο name σε υπηρεσία.

Το παρακάτω διάγραμμα συνοψίζει τις συνδέσεις θυρών:

1) Όπως ήδη γνωρίζετε, το Service ακούει ένα συγκεκριμένο port:

2) Το Ingress έχει μια παράμετρο που ονομάζεται servicePort:

3) Αυτή η παράμετρος (servicePort) πρέπει πάντα να ταιριάζει port στον ορισμό της υπηρεσίας:

4) Εάν η θύρα 80 έχει καθοριστεί στο Service, τότε είναι απαραίτητο 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.

Πρώτα πρέπει να μάθετε το όνομα του pod με τον ελεγκτή 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

Τέλος, συνδεθείτε στο pod:

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

Τώρα κάθε φορά που στέλνετε ένα αίτημα στη θύρα 3000 του υπολογιστή σας, θα προωθείται στη θύρα 80 του pod με τον ελεγκτή Ingress. Πηγαίνοντας στο http://localhost:3000, θα πρέπει να δείτε τη σελίδα που δημιουργείται από την εφαρμογή.

Περίληψη λιμένων

Ας θυμηθούμε για άλλη μια φορά ποιες θύρες και ετικέτες πρέπει να ταιριάζουν:

1. Ο επιλογέας στον ορισμό της Υπηρεσίας πρέπει να ταιριάζει με την ετικέτα του pod.
2. targetPort στον ορισμό Η υπηρεσία πρέπει να ταιριάζει containerPort δοχείο μέσα στο λοβό?
3. port στον ορισμό Η υπηρεσία μπορεί να είναι οτιδήποτε. Διαφορετικές υπηρεσίες μπορούν να χρησιμοποιούν την ίδια θύρα επειδή έχουν διαφορετικές διευθύνσεις IP.
4. servicePort Η είσοδος πρέπει να ταιριάζει port στον ορισμό της Υπηρεσίας·
5. Το όνομα της υπηρεσίας πρέπει να ταιριάζει με το πεδίο serviceName στο Ingress.

Δυστυχώς, δεν αρκεί να γνωρίζουμε πώς να δομούμε σωστά μια διαμόρφωση YAML.

Τι συμβαίνει όταν τα πράγματα πάνε στραβά;

Το pod μπορεί να μην ξεκινήσει ή να κολλήσει.

3 βήματα για τη διάγνωση προβλημάτων εφαρμογής στο Kubernetes

Πριν ξεκινήσετε τον εντοπισμό σφαλμάτων της ανάπτυξής σας, πρέπει να έχετε καλή κατανόηση του τρόπου λειτουργίας του Kubernetes.

Δεδομένου ότι κάθε εφαρμογή που λαμβάνεται στο K8s έχει τρία στοιχεία, θα πρέπει να εντοπιστούν σφάλματα με μια συγκεκριμένη σειρά, ξεκινώντας από το κάτω μέρος.

1. Πρώτα πρέπει να βεβαιωθείτε ότι οι λοβοί λειτουργούν και μετά...
2. Ελέγξτε εάν η υπηρεσία παρέχει κίνηση στα pods και, στη συνέχεια,...
3. Ελέγξτε εάν η Ingress έχει ρυθμιστεί σωστά.

Οπτική αναπαράσταση:

1) Θα πρέπει να αρχίσετε να αναζητάτε προβλήματα από τα κάτω. Πρώτα ελέγξτε ότι τα pods έχουν καταστάσεις 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'а> σας επιτρέπει να προβάλετε μια λίστα συμβάντων που σχετίζονται με το pod.
3. kubectl get pod <имя pod'а> σας επιτρέπει να λάβετε τη διαμόρφωση YAML ενός pod που είναι αποθηκευμένο στο Kubernetes.
4. kubectl exec -ti <имя pod'а> bash σας επιτρέπει να εκκινήσετε ένα διαδραστικό κέλυφος εντολών σε ένα από τα κοντέινερ pod

Ποιο να επιλέξετε;

Το γεγονός είναι ότι δεν υπάρχει καθολική εντολή. Θα πρέπει να χρησιμοποιείται ένας συνδυασμός αυτών.

Τυπικά προβλήματα λοβού

Υπάρχουν δύο κύριοι τύποι σφαλμάτων pod: σφάλματα εκκίνησης και σφάλματα χρόνου εκτέλεσης.

Σφάλματα εκκίνησης:

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

Σφάλματα χρόνου εκτέλεσης:

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

Ορισμένα σφάλματα είναι πιο συχνά από άλλα. Εδώ είναι μερικά από τα πιο κοινά σφάλματα και πώς να τα διορθώσετε.

ImagePullBackOff

Αυτό το σφάλμα εμφανίζεται όταν το Kubernetes δεν μπορεί να αποκτήσει μια εικόνα για ένα από τα κοντέινερ pod. Εδώ είναι οι τρεις πιο συνηθισμένοι λόγοι για αυτό:

1. Το όνομα της εικόνας είναι λάθος - για παράδειγμα, κάνατε λάθος σε αυτό ή η εικόνα δεν υπάρχει.
2. Καθορίστηκε μια ανύπαρκτη ετικέτα για την εικόνα.
3. Η εικόνα είναι αποθηκευμένη σε ιδιωτικό μητρώο και η Kubernetes δεν έχει άδεια πρόσβασης σε αυτήν.

Οι δύο πρώτοι λόγοι είναι εύκολο να εξαλειφθούν - απλώς διορθώστε το όνομα και την ετικέτα της εικόνας. Στην περίπτωση του τελευταίου, πρέπει να εισαγάγετε διαπιστευτήρια για το κλειστό μητρώο στο Secret και να προσθέσετε συνδέσμους σε αυτό σε ομάδες. Στην τεκμηρίωση του Kubernetes υπάρχει ένα παράδειγμα πώς μπορεί να γίνει αυτό.

Crash Loop Back Off

Ο Kubenetes κάνει λάθος CrashLoopBackOff, εάν το δοχείο δεν μπορεί να ξεκινήσει. Αυτό συμβαίνει συνήθως όταν:

1. Υπάρχει ένα σφάλμα στην εφαρμογή που την εμποδίζει να ξεκινήσει.
2. Δοχείο έχει ρυθμιστεί εσφαλμένα;
3. Το τεστ Liveness έχει αποτύχει πάρα πολλές φορές.

Πρέπει να προσπαθήσετε να φτάσετε στα κούτσουρα από το δοχείο για να μάθετε τον λόγο της αποτυχίας του. Εάν είναι δύσκολη η πρόσβαση στα αρχεία καταγραφής επειδή το κοντέινερ επανεκκινείται πολύ γρήγορα, μπορείτε να χρησιμοποιήσετε την ακόλουθη εντολή:

kubectl logs <pod-name> --previous

Εμφανίζει μηνύματα σφάλματος από την προηγούμενη ενσάρκωση του κοντέινερ.

RunContainerError

Αυτό το σφάλμα παρουσιάζεται όταν το κοντέινερ αποτυγχάνει να ξεκινήσει. Αντιστοιχεί στη στιγμή πριν από την εκκίνηση της εφαρμογής. Συνήθως προκαλείται από λανθασμένες ρυθμίσεις, για παράδειγμα:

• προσπάθεια προσάρτησης ενός ανύπαρκτου τόμου όπως ConfigMap ή Secrets.
• μια προσπάθεια προσάρτησης ενός τόμου μόνο για ανάγνωση ως ανάγνωσης-εγγραφής.

Η ομάδα είναι κατάλληλη για την ανάλυση τέτοιων σφαλμάτων kubectl describe pod <pod-name>.

Τα pods βρίσκονται σε κατάσταση εκκρεμότητας

Μόλις δημιουργηθεί, το pod παραμένει στην κατάσταση Pending.

Γιατί συμβαίνει αυτό;

Ακολουθούν οι πιθανοί λόγοι (υποθέτω ότι ο προγραμματιστής λειτουργεί καλά):

1. Το σύμπλεγμα δεν έχει αρκετούς πόρους, όπως επεξεργαστική ισχύ και μνήμη, για την εκτέλεση του pod.
2. Το αντικείμενο εγκαθίσταται στον κατάλληλο χώρο ονομάτων ResourceQuota και η δημιουργία μιας ομάδας ομάδας θα έχει ως αποτέλεσμα ο χώρος ονομάτων να υπερβεί το όριο.
3. Το Pod είναι δεσμευμένο σε Εκκρεμότητα 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, αλλά εξακολουθεί να μην υπάρχει απάντηση από την εφαρμογή, θα πρέπει να ελέγξετε τις ρυθμίσεις της υπηρεσίας.

Οι υπηρεσίες είναι υπεύθυνες για τη δρομολόγηση της επισκεψιμότητας σε ομάδες, ανάλογα με τις ετικέτες τους. Επομένως, το πρώτο πράγμα που πρέπει να κάνετε είναι να ελέγξετε πόσα pods λειτουργούν με την υπηρεσία. Για να το κάνετε αυτό, μπορείτε να ελέγξετε τα τελικά σημεία στην υπηρεσία:

kubectl describe service <service-name> | grep Endpoints

Το τελικό σημείο είναι ένα ζεύγος τιμών της φόρμας <IP-адрес:порт>, και τουλάχιστον ένα τέτοιο ζεύγος πρέπει να υπάρχει στην έξοδο (δηλαδή, τουλάχιστον ένα pod λειτουργεί με την υπηρεσία).

Εάν το τμήμα 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 κενό, υπάρχει μεγάλη πιθανότητα σφάλματος διαμόρφωσης. Εάν τα backend είναι στη θέση τους, αλλά η εφαρμογή εξακολουθεί να μην είναι προσβάσιμη, τότε το πρόβλημα μπορεί να σχετίζεται με:

• Ρυθμίσεις προσβασιμότητας εισόδου από το δημόσιο Διαδίκτυο.
• ρυθμίσεις προσβασιμότητας συμπλέγματος από το δημόσιο Διαδίκτυο.

Μπορείτε να εντοπίσετε προβλήματα με την υποδομή συνδέοντας απευθείας στο Ingress 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

Τέλος, συνδεθείτε στο pod:

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

Τώρα όλα τα αιτήματα για τη θύρα 3000 στον υπολογιστή θα ανακατευθύνονται στη θύρα 80 του pod.

Λειτουργεί τώρα;

• Αν ναι, τότε το πρόβλημα είναι με τις υποδομές. Είναι απαραίτητο να μάθετε πώς ακριβώς δρομολογείται η κυκλοφορία στο σύμπλεγμα.
• Εάν όχι, τότε το πρόβλημα είναι με τον ελεγκτή Ingress.

Εάν δεν μπορείτε να βάλετε τον ελεγκτή Ingress να λειτουργήσει, θα πρέπει να τον διορθώσετε.

Υπάρχουν πολλές ποικιλίες ελεγκτών Ingress. Τα πιο δημοφιλή είναι τα Nginx, HAProxy, Traefik κ.λπ. (για περισσότερες πληροφορίες σχετικά με τις υπάρχουσες λύσεις, βλ την κριτική μας - περίπου μετάφρ.) Θα πρέπει να ανατρέξετε στον οδηγό αντιμετώπισης προβλημάτων στη σχετική τεκμηρίωση του ελεγκτή. Επειδή η Ingress Nginx είναι ο πιο δημοφιλής ελεγκτής Ingress, έχουμε συμπεριλάβει μερικές συμβουλές στο άρθρο για την επίλυση προβλημάτων που σχετίζονται με αυτόν.

Εντοπισμός σφαλμάτων του ελεγκτή Ingress Nginx

Το έργο Ingress-nginx έχει έναν επίσημο plugin για kubectl. Ομάδα kubectl ingress-nginx μπορεί να χρησιμοποιηθεί για:

• ανάλυση αρχείων καταγραφής, backends, πιστοποιητικών κ.λπ.
• συνδέσεις με το Ingress?
• μελέτη της τρέχουσας διαμόρφωσης.

Οι ακόλουθες τρεις εντολές θα σας βοηθήσουν σε αυτό:

• kubectl ingress-nginx lint - επιταγές nginx.conf;
• kubectl ingress-nginx backend — εξερευνά το backend (παρόμοιο με kubectl describe ingress <ingress-name>);
• kubectl ingress-nginx logs — ελέγχει τα αρχεία καταγραφής.

Σημειώστε ότι σε ορισμένες περιπτώσεις μπορεί να χρειαστεί να καθορίσετε το σωστό χώρο ονομάτων για τον ελεγκτή Ingress χρησιμοποιώντας τη σημαία --namespace <name>.

Περίληψη

Η αντιμετώπιση προβλημάτων του Kubernetes μπορεί να είναι δύσκολη αν δεν ξέρετε από πού να ξεκινήσετε. Θα πρέπει πάντα να προσεγγίζετε το πρόβλημα με τρόπο από κάτω προς τα πάνω: ξεκινήστε με pods και, στη συνέχεια, προχωρήστε στην υπηρεσία και την είσοδο. Οι τεχνικές εντοπισμού σφαλμάτων που περιγράφονται σε αυτό το άρθρο μπορούν να εφαρμοστούν σε άλλα αντικείμενα, όπως:

• αδρανείς εργασίες και CronJobs.
• StatefulSets και DaemonSets.

Εκφράζω την ευγνωμοσύνη μου Gergely Risko, Daniel Weibel и Τσαρλς Κριστράι για πολύτιμα σχόλια και προσθήκες.

ΥΓ από τον μεταφραστή

Διαβάστε επίσης στο blog μας:

• «Προσθήκη kubectl-debug για εντοπισμό σφαλμάτων σε ομάδες Kubernetes"?
• «6 διασκεδαστικά σφάλματα συστήματος στη λειτουργία του Kubernetes [και η λύση τους]"?
• «Εργαλεία για προγραμματιστές εφαρμογών που εκτελούνται στο Kubernetes"?
• «6 πρακτικές ιστορίες από την καθημερινότητά μας στο SRE ».

Πηγή: www.habr.com