Πρόσφατα, κατά τη διάρκεια ενός εργαστηρίου με τίτλο , Αντιμετώπισα το ίδιο πρόβλημα δύο φορές: η υπηρεσία Α χρειάζεται την υπηρεσία Β, αλλά η υπηρεσία Α ξεκινά πιο γρήγορα από την υπηρεσία Β και το σύστημα αποτυγχάνει. Δοκιμάστε το αίτημά σας για έξοδο στο 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 Επόμενο άρθροΗ Κούβα προσφέρει δύο αποκλειστικές Ρυθμίσεις διαμόρφωσης: ή Το πρώτο είναι κατάλληλο για εφαρμογές web, ενώ το τελευταίο είναι για άλλες εφαρμογές. Αυτό σημαίνει ότι πρέπει να γνωρίζουμε τι είδους δοχείο περιέχει το pod και πώς να ελέγξετε την κατάστασή του, υπό την προϋπόθεση ότι μπορεί. Εμφανίζεται ως εξής όταν εφαρμόζεται: /health Δοκιμάστε httpGet exec Ετικέτες 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. είναι ένα σενάριο που έχει σχεδιαστεί για να συγχρονίζει υπηρεσίες όπως τα δοχεία docker. και Είναι συμβατό. ./wait-for sh alpine Εδώ είναι πώς να περιμένετε για ένα HTTP API: sh -c './wait-for http://my.api/health -- echo "The api is up! Let's use it"'
 Έκανε τη δουλειά, αλλά εκείνη τη στιγμή, έπρεπε να αντιγράψετε το σενάριο και να ελέγξετε χειροκίνητα για ενημερώσεις. παίζει τον ίδιο ρόλο, αλλά είναι διαθέσιμο ως δοχείο έκδοσης και παρέχει περισσότερες υπηρεσίες για να περιμένετε: HTTP, DNS, βάσεις δεδομένων και ουρές μηνυμάτων. Κεφάλαιο 4x Οποιοδήποτε εργαλείο χρησιμοποιείτε, μπορείτε να το χρησιμοποιήσετε μέσα σε ένα : : Κοντέινερ Ένα Pod μπορεί να έχει πολλαπλά δοχεία που εκτελούν εφαρμογές μέσα σε αυτό, αλλά μπορεί επίσης να έχει ένα ή περισσότερα δοχεία init, τα οποία εκτελούνται πριν από την εκκίνηση των δοχείων εφαρμογών. Τα εμπορευματοκιβώτια Init είναι τακτικά εμπορευματοκιβώτια, με εξαίρεση: Κάθε δοχείο init πρέπει να ολοκληρωθεί επιτυχώς πριν ξεκινήσει το επόμενο. Ένα Pod μπορεί να έχει πολλαπλά δοχεία που εκτελούν εφαρμογές μέσα σε αυτό, αλλά μπορεί επίσης να έχει ένα ή περισσότερα δοχεία init, τα οποία εκτελούνται πριν από την εκκίνηση των δοχείων εφαρμογών. Τα εμπορευματοκιβώτια Init είναι τακτικά εμπορευματοκιβώτια, με εξαίρεση: Κάθε δοχείο init πρέπει να ολοκληρωθεί επιτυχώς πριν ξεκινήσει το επόμενο. Φανταστείτε τα εξής Αυτό εξαρτάται από ένα PostgreSQL : : Pod Deployment 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
 Στην προαναφερθείσα περίπτωση, η δεν σταματά μέχρις ότου η βάση δεδομένων αποδεχθεί συνδέσεις. όταν το κάνει, τερματίζεται και η το κοντέινερ μπορεί να ξεκινήσει. το Kubernetes δεν χρειάζεται να τερματίσει το Όπως και στην προηγούμενη ρύθμιση! συνεπάγεται λιγότερες καταχωρήσεις και ενδεχομένως λιγότερες ειδοποιήσεις. initContainer recommandations 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

Read all my posts!

Read My Stories

Follow @nicolas_frankel on Twitter

Αυτός ο ήχος παράγεται στην αρχική γλώσσα της ιστορίας!

Πολύ μακρύ; Να διαβασω

Make resilience your competitive advantage

Περιμένοντας: Η λεπτή τέχνη που πρέπει να κυριαρχήσετε

About Author

ΣΧΟΛΙΑ

ΚΡΕΜΑΣΤΕ ΕΤΙΚΕΤΕΣ

ΑΥΤΟ ΤΟ ΑΡΘΡΟ ΠΑΡΟΥΣΙΑΣΤΗΚΕ ΣΤΟ

Related Stories

HackerNoon Writing Contests: Participative Marketing Works!

OpenAI Trustees Accused of Misusing Donor Funds

Eldarune: Revolutionizing Web3 Gaming with Interoperability and Multi-Chain Dominance

With Virgin's Collapse, Musk is Left With the Bigger Rocket 🚀

HackerNoon Writing Contests: Participative Marketing Works!

OpenAI Trustees Accused of Misusing Donor Funds

Eldarune: Revolutionizing Web3 Gaming with Interoperability and Multi-Chain Dominance

With Virgin's Collapse, Musk is Left With the Bigger Rocket 🚀

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps