Ποιος είναι ο σωστός τρόπος για να ελευθερώσετε kubernetes πόρους για μια θέση εργασίας kubernetes που αποτυγχάνει το τράβηγμα της εικόνας;

ψήφοι
0

Συμφραζόμενα

Έχουμε καιρό τρέχει kubernetes θέσεις εργασίας που βασίζονται σε δοχεία λιμενεργάτης. Τα δοχεία πρέπει πόρων (π.χ. μνήμη 15GB, 2 cpu) και χρησιμοποιούμε autoscaler να αναβαθμιστεί η νέα κόμβους εργαζόμενος κατόπιν αιτήματος.

Σενάριο

Οι χρήστες μπορούν να επιλέξετε την έκδοση της εικόνας λιμενεργάτη που θα χρησιμοποιηθεί για μια θέση εργασίας, π.χ. 1.0.0, 1.1.0, ή ακόμα και ένα διαπράττουν hash του κωδικού η εικόνα χτίστηκε από το περιβάλλον δοκιμής.

Καθώς αφήνουμε την ετικέτα λιμενεργάτης να FreeText, ο χρήστης μπορεί να πληκτρολογήσει μια μη υπάρχουσα ετικέτα λιμενεργάτης. Εξαιτίας αυτού του pod δουλειά έρχεται σε κατάσταση ImagePullBackOff. Το pod παραμένει σε αυτή την κατάσταση και να διατηρεί τους πόρους κλειδωμένη, ώστε να μην μπορούν να επαναχρησιμοποιηθούν από οποιαδήποτε άλλη εργασία.

Ερώτηση

Ποια είναι η σωστή λύση, η οποία μπορεί να εφαρμοστεί μόνη της kubernetes, για τη μη άμεση ή τουλάχιστον γρήγορα το pod αν μια έλξη δεν οφείλεται σε μη υπάρχοντα λιμενεργάτης εικόνα: ετικέτα;

δυνατότητες

Κοίταξα σε backofflimit. Έχω οριστεί στο 0, αλλά αυτό δεν παραλείπουν ή να αφαιρέσετε τη δουλειά. Οι πόροι είναι, φυσικά, διατηρούνται επίσης.

Ίσως να μπορεί να σκοτωθεί από μια περιοδική εργασία. Δεν είστε σίγουροι για το πώς να το πράξει.

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

Τιποτα αλλο?

Δημοσιεύθηκε 24/10/2019 στις 11:53
πηγή χρήστη
Σε άλλες γλώσσες...                            


3 απαντήσεις

ψήφοι
0

Μπορείτε να χρησιμοποιήσετε failedJobsHistoryLimitγια απέτυχε θέσεις εργασίας και successfulJobsHistoryLimitγια τις θέσεις εργασίας επιτυχίας

Με αυτές τις δύο παραμέτρους, μπορείτε να κρατήσετε τη δουλειά σας ιστορία καθαρό

.spec.backoffLimit για να καθορίσετε τον αριθμό των επαναλήψεων πριν από την εξέταση μιας εργασίας, όπως απέτυχε.

Απαντήθηκε 24/10/2019 στις 12:16
πηγή χρήστη

ψήφοι
0

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

Από προεπιλογή, η εργασία θα εκτελείται χωρίς διακοπή, εκτός εάν Pod αποτύχει (restartPolicy = Ποτέ) ή ένα εμπορευματοκιβώτιο εξόδους κατά λάθος (restartPolicy = OnFailure), οπότε οι αναβάλλει εργασίας στην .spec.backoffLimit περιγράφεται παραπάνω. Μόλις έχει επιτευχθεί .spec.backoffLimit η εργασία θα πρέπει να επισημαίνονται ως απέτυχε και κάθε τρέξιμο Pods θα τερματιστεί.

Ένας άλλος τρόπος για να τερματίσει μια εργασία είναι από τη μια ενεργή προθεσμίας. Κάνετε αυτό με τη ρύθμιση της .spec.activeDeadlineSeconds τομέα της εργασίας σε έναν αριθμό δευτερολέπτων. Οι activeDeadlineSeconds ισχύει για τη διάρκεια της εργασίας, δεν έχει σημασία πόσο δημιουργούνται πολλά Pods. Μόλις μια εργασία φτάνει activeDeadlineSeconds, όλοι τρέχουν λοβοί του είναι τερματίζεται και η κατάσταση της εργασίας θα γίνει τύπο: Αποτυχία με λόγο: DeadlineExceeded.

Σημειώστε ότι η εργασία του .spec.activeDeadlineSeconds υπερισχύει της .spec.backoffLimit . Ως εκ τούτου, μια δουλειά που έχει Επανάληψη μία ή περισσότερες απέτυχε Pods δεν θα αναπτύξει επιπλέον Pods τη στιγμή που θα φτάσει το χρονικό όριο που ορίζεται από activeDeadlineSeconds , ακόμη και αν η backoffLimit δεν έχει ακόμη επιτευχθεί.

Εδώ είναι περισσότερες πληροφορίες: θέσεις εργασίας .

Μπορείτε επίσης να set-up concurrencyPolicy της cronjob να αντικατασταθεί και να αντικαταστήσει την τρέχουσα τρέχει δουλειά με μια νέα δουλειά.

Εδώ είναι ένα παράδειγμα:

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/2 * * * *"
  concurrencyPolicy: Replace
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox
            args:
            - /bin/sh
            - -c
            - date; echo Hello from the Kubernetes cluster && sleep 420
          restartPolicy: Never

Ρύθμιση Αντικαταστήστε αξία για concurrencyPolicy μέσα σημαία, εάν είναι καιρός για μια νέα πορεία εργασίας και η προηγούμενη εκτέλεση έργο δεν έχει ακόμη ολοκληρωθεί, η εργασία cron αντικαθιστά τη στιγμή τρέχει τρέχει δουλειά με μια νέα πορεία εργασίας.

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

Εδώ είναι το παράδειγμα της αντιμετώπισης προβλημάτων για το σφάλμα: ImagePullBackOff Κανονική υποχώρησης: ImagePullBackOff .

Απαντήθηκε 25/10/2019 στις 10:27
πηγή χρήστη

ψήφοι
0

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

Αν η εικόνα με την ετικέτα δεν υπάρχει στο μητρώο, InitContainer να αναφέρετε ένα σφάλμα και δεν Pod του Ιώβ από την έξοδο με μη-μηδενική κωδικό εξόδου.

Μετά Pod ότι η δουλειά θα γίνει επανεκκίνηση . Μετά από ορισμένο ποσό των προσπαθειών εργασίας θα πάρουν Failedκατάσταση. Με τη ρύθμιση .spec.ttlSecondsAfterFinished επιλογή, απέτυχε θέσεις εργασίας μπορεί να εξαλειφθεί.

Αν init δοχείο ενός Pod αποτυγχάνει, Kubernetes επανεκκίνηση επανειλημμένα το Pod μέχρι να επιτύχει το δοχείο init. Ωστόσο, εάν το Pod έχει restartPolicy από ποτέ, Kubernetes δεν κάνετε επανεκκίνηση του Pod.

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

Απαντήθηκε 01/11/2019 στις 20:55
πηγή χρήστη

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more