Πρόσφατα, κατά τη διάρκεια ενός εργαστηρίου με τίτλοΔοκιμάστε το αίτημά σας για έξοδο στο Kubernetes με τις ενέργειες GKE και GitHub, Αντιμετώπισα το ίδιο πρόβλημα δύο φορές: η υπηρεσία Α χρειάζεται την υπηρεσία Β, αλλά η υπηρεσία Α ξεκινά πιο γρήγορα από την υπηρεσία Β και το σύστημα αποτυγχάνει.
Περιμένοντας τα κουμπιά
Μπορεί να ακούγεται περίεργο να περιμένετε στο Kubernetes. Ο αυτοθεραπευτικός χαρακτήρας της πλατφόρμας Kubernetes είναι ένα από τα μεγαλύτερα οφέλη της. Ας εξετάσουμε δύο pods: μια εφαρμογή Python και μια βάση δεδομένων PostgreSQL.
Η εφαρμογή ξεκινά πολύ γρήγορα και προσπαθεί με αγωνία να δημιουργήσει μια σύνδεση με τη βάση δεδομένων. Εν τω μεταξύ, η βάση δεδομένων αρχικοποιεί τον εαυτό της με τα δεδομένα που παρέχονται. η σύνδεση αποτυγχάνει.Failedκράτος .
Μετά από λίγο, το Kubernetes ζητά την κατάσταση του pod της εφαρμογής. Επειδή απέτυχε, το τερματίζει και ξεκινά ένα νέο pod. Σε αυτό το σημείο, δύο πράγματα μπορούν να συμβούν: το pod της βάσης δεδομένων δεν είναι έτοιμο ακόμα, και είναι πίσω στο τετράγωνο ένα, ή είναι έτοιμο, και η εφαρμογή τελικά συνδέεται.
Για να επιταχυνθεί η διαδικασία, η Kubernetes προσφέρειΔοκιμές startups: :
startupProbe:
httpGet:
path: /health
port: 8080
failureThreshold: 30
periodSeconds: 10
Με την ανωτέρω ανίχνευση, ο Kubernetes περιμένει για ένα αρχικό δέκα δευτερόλεπτα πριν ζητήσει την κατάσταση του pod. Εάν αποτύχει, περιμένει για άλλα δέκα δευτερόλεπτα.
Μπορεί να έχετε παρατηρήσει το HTTP/healthΕπόμενο άρθροΗ Κούβα προσφέρει δύο αποκλειστικέςΔοκιμάστεΡυθμίσεις διαμόρφωσης:httpGetήexecΤο πρώτο είναι κατάλληλο για εφαρμογές web, ενώ το τελευταίο είναι για άλλες εφαρμογές. Αυτό σημαίνει ότι πρέπει να γνωρίζουμε τι είδους δοχείο περιέχει το pod και πώς να ελέγξετε την κατάστασή του, υπό την προϋπόθεση ότι μπορεί.Ετικέτες Helm ChartΕμφανίζεται ως εξής όταν εφαρμόζεται:
startupProbe:
exec:
command:
- /bin/sh
- -c
- -e
- exec pg_isready -U $PG_USER -h $PG_HOST -p $PG_PORT
Σημειώστε ότι τα παραπάνω είναι μια απλούστευση, καθώς αγνοεί ευχαρίστως το όνομα της βάσης δεδομένων και ένα πιστοποιητικό SSL.
Ο ανιχνευτής εκκίνησης επιταχύνει τα πράγματα σε σύγκριση με την προεπιλεγμένη κατάσταση αν το ρυθμίσετε σωστά.Μπορείτε να ορίσετε μια μακρά αρχική καθυστέρηση και στη συνέχεια μικρότερες αυξήσεις.Ωστόσο, όσο πιο ποικίλα είναι τα δοχεία, τόσο πιο δύσκολο είναι να ρυθμιστεί, καθώς πρέπει να είστε ειδικός σε κάθε ένα από τα υποκείμενα δοχεία.
Θα ήταν ωφέλιμο να αναζητηθούν εναλλακτικές.
Κεφαλονιά4x
Οι εναλλακτικές λύσεις είναι εργαλεία που επικεντρώνονται στην αναμονή.Πριν από πολύ καιρό, βρήκα τοΠεριμένονταςΗ ιδέα είναι απλή.Η ιδέα είναι απλή:
./wait-for είναι ένα σενάριο που έχει σχεδιαστεί για να συγχρονίζει υπηρεσίες όπως τα δοχεία docker.
./wait-forείναι ένα σενάριο που έχει σχεδιαστεί για να συγχρονίζει υπηρεσίες όπως τα δοχεία docker.shκαιalpineΕίναι συμβατό.
Εδώ είναι πώς να περιμένετε για ένα HTTP API:
sh -c './wait-for http://my.api/health -- echo "The api is up! Let's use it"'
Έκανε τη δουλειά, αλλά εκείνη τη στιγμή, έπρεπε να αντιγράψετε το σενάριο και να ελέγξετε χειροκίνητα για ενημερώσεις.
Κεφάλαιο 4xπαίζει τον ίδιο ρόλο, αλλά είναι διαθέσιμο ως δοχείο έκδοσης και παρέχει περισσότερες υπηρεσίες για να περιμένετε: HTTP, DNS, βάσεις δεδομένων και ουρές μηνυμάτων.
Οποιοδήποτε εργαλείο χρησιμοποιείτε, μπορείτε να το χρησιμοποιήσετε μέσα σε έναΚοντέινερ: :
Ένα Pod μπορεί να έχει πολλαπλά δοχεία που εκτελούν εφαρμογές μέσα σε αυτό, αλλά μπορεί επίσης να έχει ένα ή περισσότερα δοχεία init, τα οποία εκτελούνται πριν από την εκκίνηση των δοχείων εφαρμογών.
Τα εμπορευματοκιβώτια Init είναι τακτικά εμπορευματοκιβώτια, με εξαίρεση:
Κάθε δοχείο init πρέπει να ολοκληρωθεί επιτυχώς πριν ξεκινήσει το επόμενο.
Ένα Pod μπορεί να έχει πολλαπλά δοχεία που εκτελούν εφαρμογές μέσα σε αυτό, αλλά μπορεί επίσης να έχει ένα ή περισσότερα δοχεία init, τα οποία εκτελούνται πριν από την εκκίνηση των δοχείων εφαρμογών.
Τα εμπορευματοκιβώτια Init είναι τακτικά εμπορευματοκιβώτια, με εξαίρεση:
- Κάθε δοχείο init πρέπει να ολοκληρωθεί επιτυχώς πριν ξεκινήσει το επόμενο.
Φανταστείτε τα εξήςPodΑυτό εξαρτάται από ένα PostgreSQLDeployment: :
apiVersion: v1
kind: Pod
metadata:
labels:
type: app
app: recommandations
spec:
containers:
- name: recommandations
image: recommandations:latest
envFrom:
- configMapRef:
name: postgres-config
Η εφαρμογή είναι Python και ξεκινά αρκετά γρήγορα. Προσπαθεί να συνδεθεί με τη βάση δεδομένων PostgreSQL. Δυστυχώς, η βάση δεδομένων δεν έχει τελειώσει την πρωτοποίηση, έτσι η σύνδεση αποτυγχάνει, και Kubernetes επανεκκινεί το pod.
Μπορούμε να το διορθώσουμε με έναinitContainerΚαι ένα κοντέινερ:
apiVersion: v1
kind: Pod
metadata:
labels:
type: app
app: recommandations
spec:
initContainers:
- name: wait-for-postgres
image: atkrad/wait4x:3.1
command:
- wait4x
- postgresql
- postgres://$(DATABASE_URL)?sslmode=disable
envFrom:
- configMapRef:
name: postgres-config
containers:
- name: recommandations
image: recommandations:latest
envFrom:
- configMapRef:
name: postgres-config
Στην προαναφερθείσα περίπτωση, ηinitContainerδεν σταματά μέχρις ότου η βάση δεδομένων αποδεχθεί συνδέσεις. όταν το κάνει, τερματίζεται και ηrecommandationsτο κοντέινερ μπορεί να ξεκινήσει. το Kubernetes δεν χρειάζεται να τερματίσει τοPodΌπως και στην προηγούμενη ρύθμιση! συνεπάγεται λιγότερες καταχωρήσεις και ενδεχομένως λιγότερες ειδοποιήσεις.
Όταν η αναμονή γίνεται υποχρεωτική
Το παραπάνω είναι μια μικρή βελτίωση, αλλά μπορείτε να το κάνετε χωρίς αυτό. Σε άλλες περιπτώσεις, η αναμονή γίνεται υποχρεωτική. το βίωσα πρόσφατα κατά την προετοιμασία για το εργαστήριο που αναφέρθηκε παραπάνω. το σενάριο είναι το εξής:
- Ο αγωγός εφαρμόζει ένα μανιφέστο στην πλευρά του Kubernetes
- Στο επόμενο βήμα, τρέχει το τεστ
- Καθώς η δοκιμή ξεκινά πριν από την ανάγνωση της εφαρμογής, αποτυγχάνει.
Πρέπει να περιμένουμε μέχρι το backend να είναι έτοιμο πριν δοκιμάσουμε.wait4xΓια να περιμένουμε τοPodΓια να δεχτούμε αιτήματα πριν ξεκινήσουμε τις δοκιμές:
- name: Wait until the application has started
uses: addnab/docker-run-action@v3 #1
with:
image: atkrad/wait4x:latest
run: wait4x http ${{ env.BASE_URL }}/health --expect-status-code 200 #2
- Το GitHub Action επιτρέπει την εκτέλεση ενός εμπορευματοκιβωτίου. θα μπορούσα να είχα κατεβάσει το Go δυαδικό αντί.
- Περιμένετε μέχρι το σημείο τερματισμού /health να επιστρέψει έναν κωδικό απόκρισης 200.
Συμπέρασμα
Οι δορυφόροι εκκίνησης του Kubernetes είναι ένας πολύ καλός τρόπος για να αποφύγετε τις περιττές επανεκκινήσεις κατά την εκκίνηση υπηρεσιών που εξαρτώνται η μία από την άλλη.initContainer. .wait4xείναι ένα εργαλείο που μπορεί να χρησιμοποιηθεί σε άλλα πλαίσια. είναι τώρα μέρος της ζώνης εργαλείων μου.
To go further:
- Κεφάλαιο 4x
- Έτσι πρέπει να περιμένετε για κάποιους πόρους Kubernetes;
Δημοσιεύτηκε αρχικά στο A Java Geek στις 20 Απριλίου, 2025
Το Java Geek
