🥇Εξισορρόπηση φορτίου και κλιμάκωση συνδέσεων μεγάλης διάρκειας στο Kubernetes

Αυτό το άρθρο θα σας βοηθήσει να κατανοήσετε πώς λειτουργεί η εξισορρόπηση φορτίου στο Kubernetes, τι συμβαίνει κατά την κλιμάκωση συνδέσεων μεγάλης διάρκειας και γιατί θα πρέπει να εξετάσετε το ενδεχόμενο εξισορρόπησης από την πλευρά του πελάτη εάν χρησιμοποιείτε πρωτόκολλα HTTP/2, gRPC, RSockets, AMQP ή άλλα πρωτόκολλα μεγάλης διάρκειας .

Λίγα λόγια για το πώς ανακατανέμεται η κυκλοφορία στο Kubernetes

Το Kubernetes παρέχει δύο βολικές αφαιρέσεις για την ανάπτυξη εφαρμογών: Υπηρεσίες και Ανάπτυξη.

Οι αναπτύξεις περιγράφουν πώς και πόσα αντίγραφα της εφαρμογής σας θα πρέπει να εκτελούνται ανά πάσα στιγμή. Κάθε εφαρμογή αναπτύσσεται ως Pod και της έχει εκχωρηθεί μια διεύθυνση IP.

Οι υπηρεσίες είναι παρόμοιες σε λειτουργία με έναν εξισορροπητή φορτίου. Έχουν σχεδιαστεί για να κατανέμουν την επισκεψιμότητα σε πολλαπλά pods.

Ας δούμε πώς μοιάζει.

Στο παρακάτω διάγραμμα μπορείτε να δείτε τρεις περιπτώσεις της ίδιας εφαρμογής και έναν εξισορροπητή φορτίου:
Το πρόγραμμα εξισορρόπησης φορτίου ονομάζεται Υπηρεσία και του εκχωρείται μια διεύθυνση IP. Οποιοδήποτε εισερχόμενο αίτημα ανακατευθύνεται σε ένα από τα pod:
Το σενάριο ανάπτυξης καθορίζει τον αριθμό των περιπτώσεων της εφαρμογής. Δεν θα χρειαστεί σχεδόν ποτέ να επεκταθείτε απευθείας κάτω από:
Σε κάθε pod έχει εκχωρηθεί η δική του διεύθυνση IP:

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

Μοιάζει με αυτό.

Ένα αίτημα curl 10.96.45.152 λαμβάνεται στην υπηρεσία:
Η υπηρεσία επιλέγει μία από τις τρεις διευθύνσεις pod ως προορισμό:
Η επισκεψιμότητα ανακατευθύνεται σε μια συγκεκριμένη ομάδα:

Εάν η εφαρμογή σας αποτελείται από ένα frontend και ένα backend, τότε θα έχετε και μια υπηρεσία και μια ανάπτυξη για το καθένα.

Όταν το frontend κάνει ένα αίτημα στο backend, δεν χρειάζεται να γνωρίζει ακριβώς πόσα pod εξυπηρετεί το backend: μπορεί να είναι ένα, δέκα ή εκατό.

Επίσης, το frontend δεν γνωρίζει τίποτα για τις διευθύνσεις των pods που εξυπηρετούν το backend.

Όταν το frontend υποβάλλει αίτημα στο backend, χρησιμοποιεί τη διεύθυνση IP της υπηρεσίας backend, η οποία δεν αλλάζει.

Εδώ είναι το πώς φαίνεται.

Το Under 1 ζητά το εσωτερικό στοιχείο υποστήριξης. Αντί να επιλέξει ένα συγκεκριμένο για το backend, κάνει ένα αίτημα στην υπηρεσία:
Η υπηρεσία επιλέγει μια από τις ομάδες υποστήριξης ως διεύθυνση προορισμού:
Η κίνηση πηγαίνει από το Pod 1 στο Pod 5, που επιλέγεται από την υπηρεσία:
Το Under 1 δεν γνωρίζει ακριβώς πόσα pods όπως το under 5 κρύβονται πίσω από την υπηρεσία:

Αλλά πώς ακριβώς διανέμει η υπηρεσία τα αιτήματα; Φαίνεται ότι χρησιμοποιείται εξισορρόπηση στρογγυλής διαδρομής; Ας το καταλάβουμε.

Εξισορρόπηση στις υπηρεσίες Kubernetes

Οι υπηρεσίες Kubernetes δεν υπάρχουν. Δεν υπάρχει διαδικασία για την υπηρεσία στην οποία έχει εκχωρηθεί διεύθυνση IP και θύρα.

Μπορείτε να το επαληθεύσετε κάνοντας είσοδο σε οποιονδήποτε κόμβο στο σύμπλεγμα και εκτελώντας την εντολή netstat -ntlp.

Δεν θα μπορείτε καν να βρείτε τη διεύθυνση IP που έχει εκχωρηθεί στην υπηρεσία.

Η διεύθυνση IP της υπηρεσίας βρίσκεται στο επίπεδο ελέγχου, στον ελεγκτή και καταγράφεται στη βάση δεδομένων - κ.λπ. Η ίδια διεύθυνση χρησιμοποιείται από ένα άλλο στοιχείο - το kube-proxy.
Το Kube-proxy λαμβάνει μια λίστα με διευθύνσεις IP για όλες τις υπηρεσίες και δημιουργεί ένα σύνολο κανόνων iptables σε κάθε κόμβο του συμπλέγματος.

Αυτοί οι κανόνες λένε: "Εάν δούμε τη διεύθυνση IP της υπηρεσίας, πρέπει να τροποποιήσουμε τη διεύθυνση προορισμού του αιτήματος και να το στείλουμε σε ένα από τα pod".

Η διεύθυνση IP της υπηρεσίας χρησιμοποιείται μόνο ως σημείο εισόδου και δεν εξυπηρετείται από καμία διαδικασία ακρόασης αυτής της διεύθυνσης IP και της θύρας.

Ας το δούμε αυτό.

Σκεφτείτε ένα σύμπλεγμα τριών κόμβων. Κάθε κόμβος έχει λοβούς:
Δεμένοι λοβοί βαμμένοι σε μπεζ είναι μέρος της υπηρεσίας. Επειδή η υπηρεσία δεν υπάρχει ως διαδικασία, εμφανίζεται με γκρι:
Το πρώτο pod ζητά μια υπηρεσία και πρέπει να μεταβεί σε ένα από τα συσχετισμένα pod:
Αλλά η υπηρεσία δεν υπάρχει, η διαδικασία δεν υπάρχει. Πώς λειτουργεί;
Πριν το αίτημα φύγει από τον κόμβο, περνάει από τους κανόνες iptables:
Οι κανόνες iptables γνωρίζουν ότι η υπηρεσία δεν υπάρχει και αντικαθιστούν τη διεύθυνση IP της με μία από τις διευθύνσεις IP των pods που σχετίζονται με αυτήν την υπηρεσία:
Το αίτημα λαμβάνει μια έγκυρη διεύθυνση IP ως διεύθυνση προορισμού και επεξεργάζεται κανονικά:
Ανάλογα με την τοπολογία του δικτύου, το αίτημα φτάνει τελικά στο pod:

Μπορεί το iptables να φορτώσει το υπόλοιπο;

Όχι, τα iptable χρησιμοποιούνται για φιλτράρισμα και δεν έχουν σχεδιαστεί για εξισορρόπηση.

Ωστόσο, είναι δυνατό να γραφτεί ένα σύνολο κανόνων που λειτουργούν όπως ψευδο-εξισορροπητής.

Και αυτό ακριβώς εφαρμόζεται στο Kubernetes.

Εάν έχετε τρεις ομάδες, το kube-proxy θα γράψει τους ακόλουθους κανόνες:

Επιλέξτε το πρώτο sub με πιθανότητα 33%, διαφορετικά μεταβείτε στον επόμενο κανόνα.
Επιλέξτε το δεύτερο με πιθανότητα 50%, διαφορετικά πηγαίνετε στον επόμενο κανόνα.
Επιλέξτε το τρίτο κάτω.

Αυτό το σύστημα έχει ως αποτέλεσμα κάθε ομάδα να επιλέγεται με πιθανότητα 33%.

Και δεν υπάρχει καμία εγγύηση ότι το Pod 2 θα επιλεγεί μετά το Pod 1.

Σημείωση: Το iptables χρησιμοποιεί μια στατιστική ενότητα με τυχαία κατανομή. Έτσι, ο αλγόριθμος εξισορρόπησης βασίζεται σε τυχαία επιλογή.

Τώρα που καταλάβατε πώς λειτουργούν οι υπηρεσίες, ας δούμε πιο ενδιαφέροντα σενάρια υπηρεσιών.

Οι μακροχρόνιες συνδέσεις στο Kubernetes δεν κλιμακώνονται από προεπιλογή

Κάθε αίτημα HTTP από το frontend στο backend εξυπηρετείται από μια ξεχωριστή σύνδεση TCP, η οποία ανοίγει και κλείνει.

Εάν η διεπαφή στέλνει 100 αιτήματα ανά δευτερόλεπτο στο backend, τότε ανοίγουν και κλείνουν 100 διαφορετικές συνδέσεις TCP.

Μπορείτε να μειώσετε τον χρόνο και τη φόρτωση επεξεργασίας αιτημάτων ανοίγοντας μία σύνδεση TCP και χρησιμοποιώντας την για όλα τα επόμενα αιτήματα HTTP.

Το πρωτόκολλο HTTP έχει μια δυνατότητα που ονομάζεται HTTP keep-alive ή επαναχρησιμοποίηση σύνδεσης. Σε αυτήν την περίπτωση, χρησιμοποιείται μία μόνο σύνδεση TCP για την αποστολή και λήψη πολλαπλών αιτημάτων και απαντήσεων HTTP:

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

Η ίδια η εγκατάσταση είναι απλή και προσβάσιμη για τις περισσότερες γλώσσες προγραμματισμού και περιβάλλοντα.

Ακολουθούν ορισμένοι σύνδεσμοι προς παραδείγματα σε διάφορες γλώσσες:

Τι συμβαίνει εάν χρησιμοποιήσουμε το keep-alive σε μια υπηρεσία Kubernetes;
Ας υποθέσουμε ότι τόσο το frontend όσο και το backend υποστηρίζουν το keep-alive.

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

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

Τι συμβαίνει εάν το frontend στείλει περισσότερα αιτήματα στο backend;

Για την προώθηση αυτών των αιτημάτων, θα χρησιμοποιηθεί μια ανοιχτή σύνδεση TCP, όλα τα αιτήματα θα μεταβούν στο ίδιο backend όπου πήγε το πρώτο αίτημα.

Δεν θα έπρεπε το iptables να αναδιανέμει την κίνηση;

Όχι σε αυτή την περίπτωση.

Όταν δημιουργείται μια σύνδεση TCP, περνάει από κανόνες iptables, οι οποίοι επιλέγουν ένα συγκεκριμένο backend όπου θα πάει η κίνηση.

Δεδομένου ότι όλα τα επόμενα αιτήματα βρίσκονται σε μια ήδη ανοιχτή σύνδεση TCP, οι κανόνες iptables δεν καλούνται πλέον.

Ας δούμε πώς μοιάζει.

Το πρώτο pod στέλνει ένα αίτημα στην υπηρεσία:
Ξέρετε ήδη τι θα συμβεί στη συνέχεια. Η υπηρεσία δεν υπάρχει, αλλά υπάρχουν κανόνες iptables που θα επεξεργαστούν το αίτημα:
Μια από τις ομάδες υποστήριξης θα επιλεγεί ως διεύθυνση προορισμού:
Το αίτημα φτάνει στο pod. Σε αυτό το σημείο, θα δημιουργηθεί μια μόνιμη σύνδεση TCP μεταξύ των δύο pods:
Οποιοδήποτε επόμενο αίτημα από το πρώτο pod θα περάσει από την ήδη εγκατεστημένη σύνδεση:

Το αποτέλεσμα είναι ταχύτερος χρόνος απόκρισης και υψηλότερη απόδοση, αλλά χάνετε τη δυνατότητα να κλιμακώσετε το backend.

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

Μπορεί να διορθωθεί αυτό;

Εφόσον η Kubernetes δεν ξέρει πώς να εξισορροπεί τις επίμονες συνδέσεις, αυτό το καθήκον ανατίθεται σε εσάς.

Οι υπηρεσίες είναι μια συλλογή από διευθύνσεις IP και θύρες που ονομάζονται τελικά σημεία.

Η εφαρμογή σας μπορεί να λάβει μια λίστα τελικών σημείων από την υπηρεσία και να αποφασίσει πώς θα διανείμει τα αιτήματα μεταξύ τους. Μπορείτε να ανοίξετε μια μόνιμη σύνδεση σε κάθε ομάδα και να ζητήσετε ισορροπία μεταξύ αυτών των συνδέσεων χρησιμοποιώντας το round-robin.

Ή εφαρμόστε περισσότερα σύνθετους αλγόριθμους εξισορρόπησης.

Ο κώδικας από την πλευρά του πελάτη που είναι υπεύθυνος για την εξισορρόπηση θα πρέπει να ακολουθεί αυτή τη λογική:

Λάβετε μια λίστα με τελικά σημεία από την υπηρεσία.
Ανοίξτε μια μόνιμη σύνδεση για κάθε τελικό σημείο.
Όταν χρειάζεται να υποβληθεί ένα αίτημα, χρησιμοποιήστε μία από τις ανοιχτές συνδέσεις.
Ενημερώνετε τακτικά τη λίστα των τελικών σημείων, δημιουργείτε νέες ή κλείνετε παλιές μόνιμες συνδέσεις εάν αλλάξει η λίστα.

Έτσι θα μοιάζει.

Αντί το πρώτο pod να στείλει το αίτημα στην υπηρεσία, μπορείτε να εξισορροπήσετε αιτήματα από την πλευρά του πελάτη:
Πρέπει να γράψετε κώδικα που θα σας ρωτάει ποια pods αποτελούν μέρος της υπηρεσίας:
Μόλις έχετε τη λίστα, αποθηκεύστε την στην πλευρά του πελάτη και χρησιμοποιήστε την για να συνδεθείτε με τα pod:
Είστε υπεύθυνοι για τον αλγόριθμο εξισορρόπησης φορτίου:

Τώρα τίθεται το ερώτημα: αυτό το πρόβλημα ισχύει μόνο για το HTTP keep-alive;

Εξισορρόπηση φορτίου από την πλευρά του πελάτη

Το HTTP δεν είναι το μόνο πρωτόκολλο που μπορεί να χρησιμοποιήσει μόνιμες συνδέσεις TCP.

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

Αντίθετα, ανοίγει και χρησιμοποιείται μια μόνιμη σύνδεση TCP στη βάση δεδομένων.

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

Ένα αντίγραφο βάσης δεδομένων θα είναι πιο φορτωμένο από τα άλλα. Το Kube-proxy και το Kubernetes δεν θα βοηθήσουν στην εξισορρόπηση των συνδέσεων. Πρέπει να φροντίσετε να εξισορροπήσετε τα ερωτήματα στη βάση δεδομένων σας.

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

Παρακάτω είναι ένα παράδειγμα πρόσβασης σε ένα σύμπλεγμα βάσεων δεδομένων MySQL από το Node.js:

var mysql = require('mysql');
var poolCluster = mysql.createPoolCluster();

var endpoints = /* retrieve endpoints from the Service */

for (var [index, endpoint] of endpoints) {
  poolCluster.add(`mysql-replica-${index}`, endpoint);
}

// Make queries to the clustered MySQL database

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

WebSockets και ασφαλείς WebSockets
HTTP / 2
gRPC
RSockets
AMQP

Θα πρέπει να είστε ήδη εξοικειωμένοι με τα περισσότερα από αυτά τα πρωτόκολλα.

Αλλά εάν αυτά τα πρωτόκολλα είναι τόσο δημοφιλή, γιατί δεν υπάρχει μια τυποποιημένη λύση εξισορρόπησης; Γιατί πρέπει να αλλάξει η λογική του πελάτη; Υπάρχει εγγενής λύση Kubernetes;

Το Kube-proxy και τα iptables έχουν σχεδιαστεί για να καλύπτουν τις πιο συνηθισμένες περιπτώσεις χρήσης κατά την ανάπτυξη στο Kubernetes. Αυτό είναι για ευκολία.

Εάν χρησιμοποιείτε μια υπηρεσία web που εκθέτει ένα REST API, είστε τυχεροί - σε αυτήν την περίπτωση, δεν χρησιμοποιούνται μόνιμες συνδέσεις TCP, μπορείτε να χρησιμοποιήσετε οποιαδήποτε υπηρεσία Kubernetes.

Αλλά μόλις αρχίσετε να χρησιμοποιείτε μόνιμες συνδέσεις TCP, θα πρέπει να καταλάβετε πώς να κατανείμετε ομοιόμορφα το φορτίο στα backends. Το Kubernetes δεν περιέχει έτοιμες λύσεις για αυτή την περίπτωση.

Ωστόσο, υπάρχουν σίγουρα επιλογές που μπορούν να βοηθήσουν.

Εξισορρόπηση μακροχρόνιων συνδέσεων στο Kubernetes

Υπάρχουν τέσσερις τύποι υπηρεσιών στο Kubernetes:

ClusterIP
NodePort
LoadBalancer
Ακέφαλος

Οι τρεις πρώτες υπηρεσίες λειτουργούν με βάση μια εικονική διεύθυνση IP, η οποία χρησιμοποιείται από το kube-proxy για τη δημιουργία κανόνων iptables. Αλλά η θεμελιώδης βάση όλων των υπηρεσιών είναι μια υπηρεσία χωρίς κεφάλι.

Η υπηρεσία headless δεν έχει καμία διεύθυνση IP που σχετίζεται με αυτήν και παρέχει μόνο έναν μηχανισμό για την ανάκτηση μιας λίστας διευθύνσεων IP και θυρών των pods (endpoints) που σχετίζονται με αυτήν.

Όλες οι υπηρεσίες βασίζονται στην υπηρεσία χωρίς κεφάλι.

Η υπηρεσία ClusterIP είναι μια υπηρεσία χωρίς κεφάλι με ορισμένες προσθήκες:

Το επίπεδο διαχείρισης του εκχωρεί μια διεύθυνση IP.
Το Kube-proxy δημιουργεί τους απαραίτητους κανόνες iptables.

Με αυτόν τον τρόπο μπορείτε να αγνοήσετε τον διακομιστή μεσολάβησης kube και να χρησιμοποιήσετε απευθείας τη λίστα των τελικών σημείων που λαμβάνονται από την υπηρεσία χωρίς κεφαλή για να φορτώσετε την ισορροπία της εφαρμογής σας.

Αλλά πώς μπορούμε να προσθέσουμε παρόμοια λογική σε όλες τις εφαρμογές που αναπτύσσονται στο σύμπλεγμα;

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

Το Service Mesh θα σας βοηθήσει

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

Όταν ξεκινά η εφαρμογή, αυτό:

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

Μόλις η εφαρμογή θέλει να υποβάλει ένα αίτημα, αυτό:

Επιλέγει μια διαθέσιμη σύνδεση χρησιμοποιώντας κάποια λογική (π.χ. round-robin).
Εκτελεί το αίτημα.

Αυτά τα βήματα λειτουργούν τόσο για συνδέσεις WebSockets, gRPC και AMQP.

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

Ωστόσο, μπορείτε να χρησιμοποιήσετε πλέγματα υπηρεσιών όπως το Istio ή το Linkerd.

Το Service Mesh αυξάνει την αίτησή σας με μια διαδικασία που:

Αυτόματη αναζήτηση για διευθύνσεις IP υπηρεσίας.
Δοκιμάζει συνδέσεις όπως WebSockets και gRPC.
Εξισορροπεί αιτήματα χρησιμοποιώντας το σωστό πρωτόκολλο.

Το Service Mesh βοηθά στη διαχείριση της κυκλοφορίας μέσα στο σύμπλεγμα, αλλά απαιτεί μεγάλη ένταση πόρων. Άλλες επιλογές είναι η χρήση βιβλιοθηκών τρίτων όπως το Netflix Ribbon ή προγραμματιζόμενοι διακομιστής μεσολάβησης όπως το Envoy.

Τι θα συμβεί αν αγνοήσετε τα ζητήματα εξισορρόπησης;

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

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

Ας υποθέσουμε ότι υπάρχουν πέντε πελάτες που συνδέονται σε δύο διακομιστές. Ακόμα κι αν δεν υπάρχει εξισορρόπηση, θα χρησιμοποιηθούν και οι δύο διακομιστές:

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

Αυτό που είναι πιο προβληματικό είναι το αντίθετο σενάριο.

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

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

Οι υπόλοιποι διακομιστές θα είναι αδρανείς:

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

Συμπέρασμα

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

Ωστόσο, μόλις αρχίσετε να εργάζεστε με πρωτόκολλα εφαρμογών που χρησιμοποιούν μόνιμες συνδέσεις TCP, όπως βάσεις δεδομένων, gRPC ή WebSockets, οι υπηρεσίες δεν είναι πλέον κατάλληλες. Το Kubernetes δεν παρέχει εσωτερικούς μηχανισμούς για την εξισορρόπηση των μόνιμων συνδέσεων TCP.

Αυτό σημαίνει ότι πρέπει να γράψετε εφαρμογές έχοντας κατά νου την εξισορρόπηση από την πλευρά του πελάτη.

Μετάφραση ετοιμάστηκε από την ομάδα Kubernetes aaS από το Mail.ru.

Τι άλλο να διαβάσετε για το θέμα:

Πηγή: www.habr.com

Εξισορρόπηση φορτίου και κλιμάκωση συνδέσεων μεγάλης διάρκειας στο Kubernetes