Δεν αποτελεί έκπληξη το γεγονός ότι η αρχιτεκτονική εφαρμογών μικροσυσκευών συνεχίζει να εισβάλλει στη σχεδίαση λογισμικού. Είναι πολύ πιο βολικό να διανέμετε το φορτίο, να δημιουργείτε εξαιρετικά διαθέσιμες αναπτύξεις και να διαχειρίζεστε αναβαθμίσεις ενώ διευκολύνετε την ανάπτυξη και τη διαχείριση της ομάδας.
Αλλά η ιστορία σίγουρα δεν είναι η ίδια χωρίς ενορχηστρωτές εμπορευματοκιβωτίων.
Είναι εύκολο να το χρησιμοποιήσετε όλα τα βασικά χαρακτηριστικά τους , ειδικά αυτόματη κλιμάκωση. Τι ευλογία είναι, βλέποντας τις αναπτύξεις εμπορευματοκιβωτίων να κυμαίνονται όλη την ημέρα, απαλά σε μέγεθος για να χειρίζονται το τρέχον φορτίο, ελευθερώνοντας τον χρόνο μας για άλλες εργασίες. Είμαστε περήφανοι ικανοποιημένοι με αυτό που δείχνουν τα εργαλεία παρακολούθησης κοντέινερ μας. Εν τω μεταξύ, μόλις διαμορφώσαμε μερικές ρυθμίσεις — ναι, αυτό (σχεδόν) χρειάστηκε για να δημιουργήσει τη μαγεία!
Αυτό δεν σημαίνει ότι δεν υπάρχει λόγος να είμαστε περήφανοι για αυτό: Είμαστε σίγουροι ότι οι χρήστες μας έχουν μια καλή εμπειρία και ότι δεν σπαταλάμε χρήματα με υπερμεγέθη υποδομή. Αυτό είναι ήδη αρκετά σημαντικό!
Και φυσικά, τι ταξίδι ήταν να φτάσετε εκεί! Επειδή ακόμη και αν στο τέλος δεν υπάρχουν πολλές ρυθμίσεις που πρέπει να διαμορφωθούν, είναι πολύ πιο δύσκολο από ό, τι συνήθως θα σκεφτόμασταν πριν ξεκινήσουμε. Ελάχιστος / μέγιστος αριθμός αντιγράφων, όρια ανώτερης / χαμηλότερης κλίμακας, περίοδοι συγχρονισμού, καθυστερήσεις ψύξης - όλες αυτές οι ρυθμίσεις είναι πολύ συνδεδεμένες μεταξύ τους. Η τροποποίηση ενός θα επηρεάσει πιθανότατα μια άλλη, αλλά πρέπει να κανονίσετε έναν ισορροπημένο συνδυασμό που θα ταιριάζει τόσο στην εφαρμογή / ανάπτυξη όσο και στην υποδομή σας. Ωστόσο, δεν θα βρείτε κανένα βιβλίο μαγειρικής ή καμία μαγική φόρμουλα στο Διαδίκτυο, καθώς εξαρτάται σε μεγάλο βαθμό τα δικα σου ανάγκες των.
Οι περισσότεροι από εμάς τις θέσαμε πρώτα σε «τυχαίες» ή προεπιλεγμένες τιμές τις οποίες προσαρμόζουμε στη συνέχεια σύμφωνα με αυτό που βρίσκουμε κατά την παρακολούθηση. Αυτό με έκανε να σκεφτώ: Τι γίνεται αν μπορούσαμε να δημιουργήσουμε μια πιο «μαθηματική» διαδικασία που θα μας βοηθούσε να βρούμε τον νικηφόρο συνδυασμό;
Υπολογισμός παραμέτρων ενορχήστρωσης κοντέινερ
Όταν σκεφτόμαστε τις μικρο-υπηρεσίες αυτόματης κλιμάκωσης για μια εφαρμογή, στην πραγματικότητα εξετάζουμε τη βελτίωση σε δύο σημαντικά σημεία:
- Βεβαιωθείτε ότι η ανάπτυξη μπορεί κλιμάκωση γρήγορα σε περίπτωση ταχείας αύξησης φορτίου (έτσι οι χρήστες δεν αντιμετωπίζουν χρονικά όρια ή HTTP 500s)
- Μείωση του κόστους της υποδομής (δηλ. να εμποδίζει τις περιπτώσεις από την υποφόρτωση)
Αυτό ουσιαστικά σημαίνει βελτιστοποίηση των ορίων του λογισμικού κοντέινερ για κλιμάκωση και μείωση. ( Κυβερνήτες Ο αλγόριθμος έχει μία μόνο παράμετρο για τα δύο).
Θα δείξω αργότερα ότι όλες οι παράμετροι που σχετίζονται με την παρουσία συνδέονται με το ανώτατο όριο. Αυτό είναι το πιο δύσκολο να υπολογιστεί - εξ ου και αυτό το άρθρο.
Σημείωση: Όσον αφορά τις παραμέτρους που έχουν οριστεί σε όλο το σύμπλεγμα, δεν έχω καμία καλή διαδικασία για αυτές, αλλά στο τέλος αυτού του άρθρου, θα παρουσιάσω ένα λογισμικό (μια στατική ιστοσελίδα) που τις λαμβάνει υπόψη κατά τον υπολογισμό οι παράμετροι αυτόματης κλιμάκωσης μιας παρουσίας. Με αυτόν τον τρόπο, θα μπορείτε να αλλάξετε τις τιμές τους για να λάβετε υπόψη τον αντίκτυπό τους.
Υπολογισμός κατωφλίου κλιμάκωσης
Για να λειτουργήσει αυτή η μέθοδος, πρέπει να βεβαιωθείτε ότι η εφαρμογή σας πληροί τις ακόλουθες απαιτήσεις:
- Το φορτίο πρέπει να είναι κατανέμεται ομοιόμορφα σε κάθε παρουσία της αίτησής σας (με τρόπο round-robin)
- Οι χρόνοι αιτημάτων πρέπει να είναι μικρότεροι από τους πίνακες κοντέινερ διάστημα ελέγχου φορτίου .
- Πρέπει να εξετάσετε το ενδεχόμενο να εκτελέσετε τη διαδικασία σε ένα μεγάλος αριθμός χρηστών (ορίζεται αργότερα).
Ο κύριος λόγος για αυτές τις συνθήκες προέρχεται από το γεγονός ότι ο αλγόριθμος δεν υπολογίζει το φορτίο ως έχει ανά χρήστη αλλά ως διανομή (εξηγείται αργότερα).
Να πάρει όλα Gaussian
Πρώτα πρέπει να διατυπώσουμε έναν ορισμό για ένα γρήγορη αύξηση φορτίου ή, με άλλα λόγια, ένα χειρότερο σενάριο. Για μένα, ένας καλός τρόπος για να το μεταφράσω είναι: έχοντας μεγάλο αριθμό χρηστών να εκτελούν ενέργειες που καταναλώνουν πόρους σε σύντομο χρονικό διάστημα —Και υπάρχει πάντα η πιθανότητα να συμβεί ενώ μια άλλη ομάδα χρηστών ή υπηρεσιών εκτελεί άλλες εργασίες. Ας ξεκινήσουμε λοιπόν από αυτόν τον ορισμό και προσπαθήστε να εξαγάγετε κάποια μαθηματικά. (Ετοιμάστε την ασπιρίνη σας.)
Εισαγωγή ορισμένων μεταβλητών:
διαφορά μεταξύ s corp και c corp and llc
- $ N_ {u} $, ο 'μεγάλος αριθμός χρηστών'
- $ L_ {u} (t) $, το φορτίο που δημιουργείται από έναν μόνο χρήστη που εκτελεί τη 'λειτουργία που καταναλώνει πόρους' ($ t = 0 $ δείχνει τη στιγμή που ο χρήστης ξεκινά τη λειτουργία)
- $ L_ {tot} (t) $, το συνολικό φορτίο (που δημιουργείται από όλους τους χρήστες)
- $ T_ {tot} $, το 'σύντομο χρονικό διάστημα'
Στον μαθηματικό κόσμο, μιλώντας για μεγάλο αριθμό χρηστών που εκτελούν το ίδιο πράγμα ταυτόχρονα, η κατανομή των χρηστών με την πάροδο του χρόνου ακολουθεί Gaussian (ή κανονική) κατανομή , του οποίου ο τύπος είναι:
[G (t) = frac {1} { sigma sqrt {2 pi}} e ^ { frac {- (t- mu) ^ 2} {2 sigma ^ 2}} ]Εδώ:
- µ είναι η αναμενόμενη τιμή
- σ είναι η τυπική απόκλιση
Και γράφεται ως εξής (με $ µ = 0 $):
Πιθανότατα θυμίζει κάποια μαθήματα που έχετε λάβει - τίποτα νέο. Ωστόσο, αντιμετωπίζουμε το πρώτο μας ζήτημα εδώ: Για να είναι μαθηματικά ακριβείς, θα πρέπει να εξετάσουμε ένα χρονικό εύρος από $ - infty $ έως $ + infty $, το οποίο προφανώς δεν μπορεί να υπολογιστεί.
Αλλά κοιτάζοντας το γράφημα, παρατηρούμε ότι οι τιμές εκτός του διαστήματος $ [- 3σ, 3σ] $ είναι πολύ κοντά στο μηδέν και δεν διαφέρουν πολύ, πράγμα που σημαίνει ότι το αποτέλεσμα τους είναι πραγματικά αμελητέο και μπορεί να παραμεριστεί. Αυτό ισχύει ακόμη περισσότερο, καθώς ο στόχος μας είναι να δοκιμάσουμε την αύξηση της εφαρμογής μας, επομένως αναζητούμε παραλλαγές μεγάλου αριθμού χρηστών.
Επιπλέον, δεδομένου ότι το διάστημα $ [- 3σ, 3σ] $ περιέχει 99,7 τοις εκατό των χρηστών μας, είναι αρκετά κοντά στο σύνολο για να το δουλέψουμε και απλώς πρέπει να πολλαπλασιάσουμε $ N_ {u} $ με 1,003 για να αντισταθμίσουμε η διαφορά. Η επιλογή αυτού του διαστήματος μας δίνει $ µ = 3σ $ (αφού πρόκειται να εργαστούμε από $ t = 0 $).
Όσον αφορά την αντιστοιχία με $ T_ {tot} $, η επιλογή του να ισούται με $ 6σ $ ($ [- 3σ, 3σ] $) δεν θα είναι καλή προσέγγιση, καθώς το 95,4% των χρηστών είναι στο διάστημα $ [- 2σ, 2σ] $, που διαρκεί $ 4σ $. Έτσι, επιλέγοντας $ T_ {tot} $ για να ισούται με $ 6σ $ θα προσθέσει το ήμισυ του χρόνου μόνο για το 4,3 τοις εκατό των χρηστών, το οποίο δεν είναι πραγματικά αντιπροσωπευτικό. Έτσι επιλέγουμε να πάρουμε $ T_ {tot} = 4σ $ και μπορούμε να συμπεράνουμε:
(σ = frac {T_ {tot}} {4} ) και (µ = frac {3} {4} * T_ {tot} )
Απλώς τραβήχτηκαν αυτές οι αξίες από ένα καπέλο; Ναί. Αλλά αυτός είναι ο σκοπός τους και αυτό δεν θα επηρεάσει τη μαθηματική διαδικασία. Αυτές οι σταθερές είναι για εμάς και ορίζει έννοιες που σχετίζονται με την υπόθεσή μας. Αυτό σημαίνει μόνο ότι τώρα που τα έχουμε ρυθμίσει, το χειρότερο σενάριό μας μπορεί να μεταφραστεί ως:
Το φορτίο που δημιουργήθηκε κατά 99,7% $ N {u} $, εκτελώντας μια καταναγκαστική λειτουργία $ L {u} (t) $ και όπου το 95,4% από αυτά το κάνουν εντός της διάρκειας $ T {tot} $.
(Αυτό είναι κάτι που αξίζει να θυμάστε όταν χρησιμοποιείτε την εφαρμογή ιστού.)
Έγχυση προηγούμενων αποτελεσμάτων στη λειτουργία διανομής χρηστών (Gaussian), μπορούμε να απλοποιήσουμε την εξίσωση ως εξής:
τι σημαίνει στις ράγες[G (t) = frac {4 N_ {u}} {T_ {tot} sqrt {2 pi}} e ^ frac {- (4t-3T_ {tot}) ^ 2} {T_ {tot } ^ 2} ]
Από τώρα και στο εξής, έχοντας ορίσει $ σ $ και $ μ $, θα εργαζόμαστε για το διάστημα $ t in [0, frac {3} {2} T_ {tot}] $ (διαρκεί $ 6σ $).
Ποιο είναι το συνολικό φορτίο χρήστη;
Το δεύτερο βήμα στις μικρο-υπηρεσίες αυτόματης κλιμάκωσης είναι ο υπολογισμός $ L_ {tot} (t) $.
Από $ G (t) $ είναι a κατανομή , για να ανακτήσουμε τον αριθμό των χρηστών σε μια συγκεκριμένη χρονική στιγμή, πρέπει να υπολογίσουμε το ακέραιο (ή να χρησιμοποιήσουμε τη συνάρτηση αθροιστικής διανομής). Όμως, επειδή δεν ξεκινούν όλοι οι χρήστες τη λειτουργία τους ταυτόχρονα, θα ήταν πραγματικό χάος προσπαθώντας να εισαγάγει $ L_ {u} (t) $ και να μειώσει την εξίσωση σε έναν χρησιμοποιήσιμο τύπο.
Για να το κάνουμε αυτό ευκολότερο, θα χρησιμοποιήσουμε ένα Άθροισμα Ρίμαν , που είναι ένας μαθηματικός τρόπος για την προσέγγιση ενός ακέραιου χρησιμοποιώντας ένα πεπερασμένο άθροισμα μικρών σχημάτων (θα χρησιμοποιούμε ορθογώνια εδώ). Όσο περισσότερα σχήματα (υποδιαιρέσεις), τόσο πιο ακριβές είναι το αποτέλεσμα. Ένα άλλο όφελος από τη χρήση υποδιαιρέσεων προέρχεται από το γεγονός ότι μπορούμε να θεωρήσουμε ότι όλοι οι χρήστες σε μια υποδιαίρεση έχουν ξεκινήσει τη λειτουργία τους ταυτόχρονα.
Επιστροφή στο ποσό Riemann, έχει την ακόλουθη ιδιότητα που συνδέεται με ολοκληρώματα:
[ int_ {a} ^ {b} f (x) dx = lim_ {n rightarrow infty} sum_ {k = 1} ^ {n} (x_ {k} - x_ {k-1}) στ (x_ {k}) ]Με $ x_k $ ορίζεται ως εξής:
[x_ {k} = a + k frac {b - a} {n}, 0 leq k leq n ]Αυτό ισχύει όταν:
- $ n $ είναι ο αριθμός των υποδιαιρέσεων.
- Το $ a $ είναι το κατώτερο όριο, εδώ 0.
- $ b $ είναι το υψηλότερο όριο, εδώ $ frac {3} {2} * T_ {tot} $.
- $ f $ είναι η συνάρτηση - εδώ $ G $ - για να προσεγγίσει την περιοχή του.
Σημείωση: Ο αριθμός των χρηστών που υπάρχουν σε μια υποδιαίρεση δεν είναι ακέραιος. Αυτός είναι ο λόγος για δύο από τις προϋποθέσεις: Έχοντας μεγάλο αριθμό χρηστών (έτσι το δεκαδικό μέρος δεν επηρεάζει υπερβολικά) και την ανάγκη για ομοιόμορφη κατανομή του φορτίου σε κάθε περίπτωση.
Σημειώστε επίσης ότι μπορούμε να δούμε το ορθογώνιο σχήμα της υποδιαίρεσης στη δεξιά πλευρά του ορισμού αθροίσματος Riemann.
Τώρα που έχουμε τον τύπο αθροίσματος Riemann, μπορούμε να πούμε ότι η τιμή φόρτωσης $ t $ είναι το άθροισμα του αριθμού των χρηστών κάθε υποδιαίρεσης πολλαπλασιασμένο με τη συνάρτηση φόρτωσης χρήστη στο την αντίστοιχη ώρα τους . Αυτό μπορεί να γραφτεί ως:
[L_ {tot} (t) = lim_ {n rightarrow infty} sum_ {k = 1} ^ {n} (x_ {k} - x_ {k-1}) G (x_ {k}) L_ {u} (t - x_ {k}) ]Μετά την αντικατάσταση των μεταβλητών και την απλοποίηση του τύπου, αυτό γίνεται:
[L_ {tot} (t) = frac {6 N_ {u}} { sqrt {2 pi}} lim_ {n rightarrow infty} sum_ {k = 1} ^ {n} ( frac {1} {n}) e ^ {- {( frac {6k} {n} - 3) ^ {2}}} L_ {u} (t - k frac {3 T_ {tot}} {2n }) ]Και εδώ ! Δημιουργήσαμε τη λειτουργία φόρτωσης!
Βρίσκοντας το όριο κλιμάκωσης
Για να ολοκληρώσουμε, πρέπει απλώς να τρέξουμε έναν αλγόριθμο διχοτομίας που μεταβάλλει το κατώφλι για να βρει την υψηλότερη τιμή όπου το φορτίο ανά περίπτωση δεν υπερβαίνει ποτέ το μέγιστο όριο σε όλη τη λειτουργία φόρτωσης. (Αυτό γίνεται από την εφαρμογή.)
Αφαίρεση άλλων παραμέτρων ενορχήστρωσης
Μόλις βρείτε το όριο αύξησης ($ S_ {up} $), οι άλλες παράμετροι είναι αρκετά εύκολο να υπολογιστούν.
Από $ S_ {up} $ θα γνωρίζετε τον μέγιστο αριθμό εμφανίσεων. (Μπορείτε επίσης να αναζητήσετε το μέγιστο φορτίο στη λειτουργία φόρτωσης και να διαιρέσετε ανά μέγιστο φορτίο ανά παρουσία, στρογγυλοποιημένο.)
πώς να βρείτε έναν προγραμματιστή λογισμικού
Ο ελάχιστος αριθμός ($ N_ {min} $) παρουσιών πρέπει να καθοριστεί σύμφωνα με την υποδομή σας. (Θα συνιστούσα να έχετε τουλάχιστον ένα αντίγραφο ανά AZ.) Αλλά πρέπει επίσης να ληφθεί υπόψη η λειτουργία φόρτωσης: Καθώς η συνάρτηση Gaussian αυξάνεται αρκετά γρήγορα, η κατανομή φορτίου είναι πιο έντονη (ανά αντίγραφο) στην αρχή, οπότε μπορεί να θέλει να αυξήσει τον ελάχιστο αριθμό αντιγράφων για να μετριάσει αυτό το αποτέλεσμα. (Αυτό πιθανότατα θα αυξήσει τα $ S_ {up} $.)
Τέλος, μόλις ορίσετε τον ελάχιστο αριθμό αντιγράφων, μπορείτε να υπολογίσετε το κατώτατο όριο κλίμακας προς τα κάτω ($ S_ {down} $) λαμβάνοντας υπόψη τα ακόλουθα: Καθώς η κλιμάκωση ενός μεμονωμένου αντιγράφου δεν έχει μεγαλύτερη επίδραση σε άλλες περιπτώσεις από ό, τι όταν κάνετε μείωση από $ N_ {min} + 1 $ έως $ N_ {min} $, πρέπει να διασφαλίσουμε ότι το κατώφλι αύξησης δεν θα ενεργοποιηθεί αμέσως μετά τη μείωση. Εάν επιτρέπεται, αυτό θα έχει αποτέλεσμα yo-yo. Με άλλα λόγια:
[(N_ {min} + 1) S_ {κάτω}Λάβετε υπόψη ότι όταν χρησιμοποιείτε το σύστημα ενορχήστρωσης του Mesosphere Marathon με το αυτόματο κλιμάκωμά του, ο μέγιστος αριθμός παρουσιών που μπορούν να αφαιρεθούν ταυτόχρονα από την κλιμάκωση προς τα κάτω συνδέεται με AS_AUTOSCALE_MULTIPLIER ($ A_ {mult} $), που σημαίνει:
Ναι, αυτό είναι λίγο πρόβλημα και όχι το πιο εύκολο να λύσετε μαθηματικά - αν είναι ακόμη δυνατό.
Για να επιλύσετε αυτό το ζήτημα, η ιδέα είναι να εκτελέσετε μια μόνο παρουσία της εφαρμογής σας και να αυξήσετε τον αριθμό των χρηστών που εκτελούν την ίδια εργασία επανειλημμένα έως ότου το φορτίο διακομιστή φτάσει στο μέγιστο που έχει εκχωρηθεί (αλλά όχι πάνω). Στη συνέχεια, διαιρέστε με τον αριθμό των χρηστών και υπολογίστε τον μέσο χρόνο του αιτήματος. Επαναλάβετε αυτήν τη διαδικασία με κάθε ενέργεια που θέλετε να ενσωματώσετε στη λειτουργία φόρτωσης του χρήστη σας, προσθέστε λίγο χρόνο και εκεί είστε.
Γνωρίζω ότι αυτή η διαδικασία συνεπάγεται ότι κάθε αίτημα χρήστη έχει ένα σταθερό φορτίο κατά την επεξεργασία του (το οποίο είναι προφανώς λανθασμένο), αλλά η μάζα των χρηστών θα δημιουργήσει αυτό το αποτέλεσμα καθώς καθένας από αυτούς δεν βρίσκεται στο ίδιο βήμα επεξεργασίας ταυτόχρονα . Υποθέτω λοιπόν ότι αυτή είναι μια αποδεκτή προσέγγιση, αλλά για άλλη μια φορά υπαινίσσεται ότι αντιμετωπίζετε έναν μεγάλο αριθμό χρηστών.
Μπορείτε επίσης να δοκιμάσετε με άλλες μεθόδους, όπως Γραφήματα φλόγας CPU . Αλλά νομίζω ότι θα είναι πολύ δύσκολο να δημιουργηθεί ένας ακριβής τύπος που θα συνδέει τις ενέργειες των χρηστών με την κατανάλωση πόρων.
Παρουσιάζουμε το app-autoscaling-calculator
Και τώρα, για τη μικρή εφαρμογή ιστού που αναφέρεται σε ολόκληρο: Παίρνει ως εισαγωγή τη λειτουργία φόρτωσης, τη διαμόρφωση του ενορχηστρωτή κοντέινερ και ορισμένες άλλες γενικές παραμέτρους και επιστρέφει το όριο αύξησης και άλλα στοιχεία που σχετίζονται με την παρουσία.
Το έργο είναι φιλοξενείται στο GitHub , αλλά έχει επίσης μια ζωντανή έκδοση διαθέσιμη .
Εδώ είναι το αποτέλεσμα που δίνεται από την εφαρμογή ιστού, εκτελείται ενάντια στα δεδομένα δοκιμής (στο Kubernetes):
Μικροσυσκευές κλιμάκωσης: Όχι πια στο σκοτάδι
Όταν πρόκειται για αρχιτεκτονικές εφαρμογών μικροϋπηρεσιών, η ανάπτυξη κοντέινερ γίνεται κεντρικό σημείο ολόκληρης της υποδομής. Και όσο καλύτερα διαμορφώνονται οι ενορχηστρωτές και τα κοντέινερ, τόσο ομαλότερος θα είναι ο χρόνος εκτέλεσης.
Όσοι από εμάς στον τομέα της Υπηρεσίες DevOps αναζητούμε πάντα καλύτερους τρόπους συντονισμού των παραμέτρων ενορχήστρωσης για τις εφαρμογές μας. Ας ακολουθήσουμε μια πιο μαθηματική προσέγγιση στις μικρο-υπηρεσίες αυτόματης κλιμάκωσης!
Κατανόηση των βασικών
Πώς μπορείτε να βελτιώσετε την επεκτασιμότητα μιας εφαρμογής Ιστού;
Η χρήση αρχιτεκτονικής μικροϋπηρεσιών θεωρείται βέλτιστη πρακτική όσον αφορά τη μεγιστοποίηση της επεκτασιμότητας.
πόσα άτομα πρέπει να είναι σε μια ομάδα scrum;
Τι σημαίνει πραγματικά η αρχιτεκτονική των μικροϋπηρεσιών;
Οι μικροϋπηρεσίες είναι συστατικά μιας εφαρμογής που μπορούν να αναπτυχθούν ανεξάρτητα.
Γιατί χρειαζόμαστε αρχιτεκτονική μικροϋπηρεσιών;
Εκτός από την ευκολότερη δοκιμή και συντήρηση μεγάλων εφαρμογών, η χρήση αρχιτεκτονικής εφαρμογών μικροσυσκευών είναι συχνά ο μόνος τρόπος που επιτρέπει αξιόπιστη, δυναμική κλιμάκωση. Επιπλέον, η κλιμάκωση μικροσυσκευών μπορεί να γίνει αυτόματα ως απόκριση στο φορτίο του χρήστη.
Τι είναι η ενορχήστρωση εμπορευματοκιβωτίων;
Η ενορχήστρωση κοντέινερ αναφέρεται στον συντονισμό των χρόνων εκτέλεσης των μικροϋπηρεσιών σε ένα σύμπλεγμα διακομιστών. Ένα από τα βασικά χαρακτηριστικά του είναι η αυτόματη κλιμάκωση των εφαρμογών.
