Αποτελέσματα συγκριτικής αξιολόγησης προσθήκης δικτύου Kubernetes (CNI) πάνω από το δίκτυο 10 Gbps (Ενημερώθηκε: Απρίλιος 2019)

Αυτή είναι η ενημέρωση μου προηγούμενο σημείο αναφοράς, το οποίο τρέχει τώρα στο Kubernetes 1.14 με την πιο πρόσφατη έκδοση CNI από τον Απρίλιο του 2019.

Πρώτα απ 'όλα, θέλω να ευχαριστήσω την ομάδα του Cilium: τα παιδιά με βοήθησαν να ελέγξω και να διορθώσω τα σενάρια παρακολούθησης μετρήσεων.

Τι έχει αλλάξει από τον Νοέμβριο του 2018

Δείτε τι έχει αλλάξει από τότε (αν σας ενδιαφέρει):

Το Flannel παραμένει η πιο γρήγορη και απλή διεπαφή CNI, αλλά εξακολουθεί να μην υποστηρίζει πολιτικές δικτύου και κρυπτογράφηση.

Το Romana δεν υποστηρίζεται πλέον, επομένως το αφαιρέσαμε από το σημείο αναφοράς.

Το WeaveNet υποστηρίζει τώρα πολιτικές δικτύου για Ingress και Egress! Αλλά η παραγωγικότητα έχει μειωθεί.

Στο Calico, εξακολουθείτε να χρειάζεται να διαμορφώσετε με μη αυτόματο τρόπο το μέγιστο μέγεθος πακέτου (MTU) για βέλτιστη απόδοση. Το Calico προσφέρει δύο επιλογές για την εγκατάσταση του CNI, ώστε να μπορείτε να το κάνετε χωρίς ξεχωριστό αποθετήριο ETCD:

• κατάσταση αποθήκευσης στο Kubernetes API ως χώρο αποθήκευσης δεδομένων (μέγεθος συμπλέγματος < 50 κόμβοι).
• κατάσταση αποθήκευσης στο Kubernetes API ως χώρο αποθήκευσης δεδομένων με διακομιστή μεσολάβησης Typha για την ανακούφιση του φόρτου στο K8S API (μέγεθος συμπλέγματος > 50 κόμβοι).

Η Calico ανακοίνωσε υποστήριξη πολιτικές σε επίπεδο εφαρμογής πάνω από το Istio για ασφάλεια σε επίπεδο εφαρμογής.

Το Cilium υποστηρίζει πλέον κρυπτογράφηση! Το Cilium παρέχει κρυπτογράφηση με σήραγγες IPSec και προσφέρει μια εναλλακτική λύση στο κρυπτογραφημένο δίκτυο WeaveNet. Αλλά το WeaveNet είναι ταχύτερο από το Cilium με ενεργοποιημένη την κρυπτογράφηση.

Το Cilium είναι πλέον πιο εύκολο να αναπτυχθεί χάρη στον ενσωματωμένο χειριστή ETCD.

Η ομάδα της Cilium προσπάθησε να μειώσει κάποιο βάρος από το CNI της μειώνοντας την κατανάλωση μνήμης και το κόστος της CPU, αλλά οι ανταγωνιστές της εξακολουθούν να είναι ελαφρύτεροι.

Συγκριτικό πλαίσιο

Το σημείο αναφοράς εκτελείται σε τρεις μη εικονικούς διακομιστές Supermicro με διακόπτη Supermicro 10 Gb. Οι διακομιστές συνδέονται απευθείας στον διακόπτη μέσω παθητικών καλωδίων DAC SFP+ και διαμορφώνονται στο ίδιο VLAN με jumbo frames (MTU 9000).

Το Kubernetes 1.14.0 είναι εγκατεστημένο στο Ubuntu 18.04 LTS με Docker 18.09.2 (η προεπιλεγμένη έκδοση Docker σε αυτήν την έκδοση).

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

Θα περιγράψουμε τα αποτελέσματα αναφοράς στην ακόλουθη κλίμακα:

Επιλογή CNI για σημείο αναφοράς

Αυτό είναι ένα σημείο αναφοράς μόνο για το CNI από τη λίστα στην ενότητα σχετικά με τη δημιουργία ενός κύριου συμπλέγματος με το kubeadm Δείτε την επίσημη τεκμηρίωση της Kubernetes. Από τα 9 CNI, θα πάρουμε μόνο 6: θα εξαιρέσουμε εκείνα που είναι δύσκολο να εγκατασταθούν ή/και δεν λειτουργούν χωρίς διαμόρφωση σύμφωνα με την τεκμηρίωση (Romana, Contiv-VPP και JuniperContrail/TungstenFabric).

Θα συγκρίνουμε τα ακόλουθα CNI:

• Calico v3.6
• Canal v3.6 (ουσιαστικά Flannel για δικτύωση + Calico ως τείχος προστασίας)
• Κίλιο 1.4.2
• Φανέλα 0.11.0
• Kube-router 0.2.5
• WeaveNet 2.5.1

Εγκατάσταση

Όσο πιο εύκολη είναι η εγκατάσταση του CNI, τόσο καλύτερη θα είναι η πρώτη μας εντύπωση. Όλα τα CNI από το σημείο αναφοράς είναι πολύ εύκολο στην εγκατάσταση (με μία ή δύο εντολές).

Όπως είπαμε, οι διακομιστές και ο διακόπτης έχουν ρυθμιστεί με ενεργοποιημένα τα jumbo frames (ρυθμίσαμε το MTU στο 9000). Θα χαρούμε αν το CNI καθόριζε αυτόματα το MTU με βάση τη διαμόρφωση των προσαρμογέων. Ωστόσο, μόνο οι Cilium και Flannel το κατάφεραν. Τα υπόλοιπα CNI έχουν αιτήματα στο GitHub για προσθήκη αυτόματης ανακάλυψης MTU, αλλά θα τη διαμορφώσουμε με μη αυτόματο τρόπο αλλάζοντας το ConfigMap για Calico, Canal και Kube-router ή περνώντας μια μεταβλητή περιβάλλοντος για το WeaveNet.

Ποιο είναι το πρόβλημα με το λανθασμένο MTU; Αυτό το διάγραμμα δείχνει τη διαφορά μεταξύ του WeaveNet με ενεργοποιημένα το προεπιλεγμένο MTU και τα jumbo frames:

Πώς επηρεάζει το MTU την απόδοση;

Είδαμε πόσο σημαντικό είναι το MTU για την απόδοση, τώρα ας δούμε πώς το καθορίζουν αυτόματα τα CNI μας:

Το CNI ανιχνεύει αυτόματα το MTU

Το γράφημα δείχνει ότι πρέπει να διαμορφώσετε το MTU για Calico, Canal, Kube-router και WeaveNet για βέλτιστη απόδοση. Το Cilium και το Flannel μπόρεσαν να προσδιορίσουν σωστά το MTU χωρίς καμία ρύθμιση.

Ασφάλεια

Θα συγκρίνουμε την ασφάλεια CNI σε δύο πτυχές: την ικανότητα κρυπτογράφησης μεταδιδόμενων δεδομένων και την εφαρμογή των πολιτικών δικτύου Kubernetes (με βάση πραγματικές δοκιμές, όχι τεκμηρίωση).

Μόνο δύο CNI κρυπτογραφούν δεδομένα: Cilium και WeaveNet. Κρυπτογράφηση WeaveNet ενεργοποιείται ορίζοντας τον κωδικό πρόσβασης κρυπτογράφησης ως μεταβλητή περιβάλλοντος CNI. ΣΕ τεκμηρίωση Το WeaveNet το περιγράφει με περίπλοκο τρόπο, αλλά όλα γίνονται απλά. Κρυπτογράφηση Τσίλιουμ ρυθμίζεται με εντολές, δημιουργώντας μυστικά Kubernetes και μέσω τροποποίησης του daemonSet (λίγο πιο περίπλοκο από ό,τι στο WeaveNet, αλλά το Ciliium έχει βήμα-βήμα οδηγίες).

Όσον αφορά την εφαρμογή της πολιτικής δικτύου, έχουν πετύχει Calico, Canal, Cilium και WeaveNet, στο οποίο μπορείτε να διαμορφώσετε τους κανόνες εισόδου και εξόδου. Για Kube-router υπάρχουν κανόνες μόνο για την είσοδο, και Φανέλα Δεν υπάρχουν καθόλου πολιτικές δικτύου.

Ακολουθούν τα συνολικά αποτελέσματα:

Αποτελέσματα αναφοράς επιδόσεων ασφάλειας

Παραγωγικότητα

Αυτό το σημείο αναφοράς δείχνει τη μέση απόδοση σε τουλάχιστον τρεις εκτελέσεις κάθε δοκιμής. Δοκιμάζουμε την απόδοση των TCP και UDP (χρησιμοποιώντας iperf3), πραγματικών εφαρμογών όπως HTTP (με Nginx και curl) ή FTP (με vsftpd και curl) και τέλος την απόδοση της εφαρμογής χρησιμοποιώντας κρυπτογράφηση που βασίζεται σε SCP (χρησιμοποιώντας OpenSSH πελάτη και διακομιστή).

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

• Κίτρινο = πολύ καλό
• Πορτοκαλί = καλό
• Μπλε = έτσι-έτσι
• Κόκκινο = κακό

Δεν θα λάβουμε λανθασμένα διαμορφωμένα CNI και θα εμφανίσουμε αποτελέσματα μόνο για CNI με τη σωστή MTU. (Σημείωση: Το Cilium δεν υπολογίζει σωστά το MTU εάν ενεργοποιήσετε την κρυπτογράφηση, επομένως θα πρέπει να μειώσετε με μη αυτόματο τρόπο το MTU στο 8900 στην έκδοση 1.4. Η επόμενη έκδοση, 1.5, το κάνει αυτόματα.)

Εδώ είναι τα αποτελέσματα:

Απόδοση TCP

Όλα τα CNI είχαν καλή απόδοση στο σημείο αναφοράς TCP. Το CNI με κρυπτογράφηση υστερεί πολύ επειδή η κρυπτογράφηση είναι ακριβή.

Απόδοση UDP

Και εδώ όλα τα CNI πάνε καλά. Το CNI με κρυπτογράφηση έδειξε σχεδόν το ίδιο αποτέλεσμα. Το Cilium είναι λίγο πίσω από τον ανταγωνισμό, αλλά είναι μόνο το 2,3% του γυμνού μετάλλου, οπότε δεν είναι κακό αποτέλεσμα. Μην ξεχνάτε ότι μόνο το Cilium και το Flannel καθόρισαν σωστά το MTU και αυτά είναι τα αποτελέσματά τους χωρίς καμία πρόσθετη διαμόρφωση.

Τι γίνεται με μια πραγματική εφαρμογή; Όπως μπορείτε να δείτε, η συνολική απόδοση για το HTTP είναι ελαφρώς χαμηλότερη από ό,τι για το TCP. Ακόμα κι αν χρησιμοποιείτε HTTP με TCP, διαμορφώσαμε το iperf3 στο σημείο αναφοράς TCP για να αποφύγουμε μια αργή εκκίνηση που θα επηρεάσει τη συγκριτική αξιολόγηση HTTP. Όλοι έκαναν καλή δουλειά εδώ. Το Kube-router έχει ένα σαφές πλεονέκτημα, αλλά το WeaveNet δεν είχε καλή απόδοση: περίπου 20% χειρότερα από το γυμνό μέταλλο. Το Ciliium και το WeaveNet με κρυπτογράφηση φαίνονται πραγματικά λυπηρά.

Με το FTP, ένα άλλο πρωτόκολλο που βασίζεται σε TCP, τα αποτελέσματα ποικίλλουν. Οι Flannel και Kube-router κάνουν τη δουλειά, αλλά οι Calico, Canal και Cilium είναι λίγο πίσω και είναι περίπου 10% πιο αργοί από το γυμνό μέταλλο. Το WeaveNet βρίσκεται πίσω κατά 17%, αλλά το κρυπτογραφημένο WeaveNet είναι 40% μπροστά από το κρυπτογραφημένο Ciliium.

Με το SCP μπορούμε να δούμε αμέσως πόσο μας κοστίζει η κρυπτογράφηση SSH. Σχεδόν όλα τα CNI τα πάνε καλά, αλλά το WeaveNet υστερεί και πάλι. Το Cilium και το WeaveNet με κρυπτογράφηση είναι αναμενόμενα τα χειρότερα λόγω διπλής κρυπτογράφησης (SSH + CNI).

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

Κατανάλωση πόρων

Τώρα ας συγκρίνουμε πώς το CNI καταναλώνει πόρους κάτω από μεγάλα φορτία (κατά τη μεταφορά TCP, 10 Gbps). Σε δοκιμές απόδοσης συγκρίνουμε το CNI με γυμνό μέταλλο (πράσινη γραμμή). Για κατανάλωση πόρων, ας δείξουμε καθαρό Kubernetes (μωβ γραμμή) χωρίς CNI και ας δούμε πόσους επιπλέον πόρους καταναλώνει το CNI.

Ας ξεκινήσουμε με τη μνήμη. Εδώ είναι η μέση τιμή για τη μνήμη RAM των κόμβων (εξαιρουμένων των buffer και της προσωρινής μνήμης) σε MB κατά τη μεταφορά.

Κατανάλωση μνήμης

Flannel και Kube-router έδειξαν εξαιρετικά αποτελέσματα - μόνο 50 MB. Το Calico και το Canal έχουν 70 το καθένα. Το WeaveNet καταναλώνει σαφώς περισσότερα από τα άλλα - 130 MB και το Cilium χρησιμοποιεί έως και 400.
Τώρα ας ελέγξουμε την κατανάλωση χρόνου της CPU. Αξιοσημείωτος: το διάγραμμα δεν δείχνει ποσοστά, αλλά ppm, δηλαδή 38 ppm για τον «ακάλυπτο σίδηρο» είναι 3,8%. Εδώ είναι τα αποτελέσματα:

Κατανάλωση CPU

Τα Calico, Canal, Flannel και Kube-router είναι πολύ αποδοτικά CPU - μόνο 2% περισσότερα από τα Kubernetes χωρίς CNI. Η WeaveNet υστερεί πολύ με επιπλέον 5%, ακολουθούμενη από την Cilium με 7%.

Ακολουθεί μια περίληψη της κατανάλωσης πόρων:

Αποτελέσματα της

Πίνακας με όλα τα αποτελέσματα:

Γενικά αποτελέσματα αναφοράς

Συμπέρασμα

Στο τελευταίο μέρος θα εκφράσω την υποκειμενική μου άποψη για τα αποτελέσματα. Να θυμάστε ότι αυτό το σημείο αναφοράς ελέγχει μόνο την απόδοση μιας μεμονωμένης σύνδεσης σε ένα πολύ μικρό σύμπλεγμα (3 κόμβοι). Δεν ισχύει για μεγάλα συμπλέγματα (<50 κόμβοι) ή παράλληλες συνδέσεις.

Συνιστώ τη χρήση των παρακάτω CNI ανάλογα με το σενάριο:

• Έχετε στο σύμπλεγμα σας κόμβους με λίγους πόρους (αρκετά GB μνήμης RAM, αρκετοί πυρήνες) και δεν χρειάζεστε χαρακτηριστικά ασφαλείας - επιλέξτε Φανέλα. Αυτό είναι ένα από τα πιο οικονομικά CNI. Και είναι συμβατό με μια μεγάλη ποικιλία αρχιτεκτονικών (amd64, arm, arm64, κ.λπ.). Επιπλέον, αυτό είναι ένα από τα δύο (το άλλο είναι το Cilium) CNI που μπορεί να προσδιορίσει αυτόματα το MTU, οπότε δεν χρειάζεται να διαμορφώσετε τίποτα. Ο δρομολογητής Kube είναι επίσης κατάλληλος, αλλά δεν είναι τόσο τυπικός και θα χρειαστεί να ρυθμίσετε χειροκίνητα το MTU.
• Αν χρειαστεί κρυπτογράφηση του δικτύου για ασφάλεια, πάρτε WeaveNet. Μην ξεχάσετε να καθορίσετε το μέγεθος MTU εάν χρησιμοποιείτε jumbo frames και να ενεργοποιήσετε την κρυπτογράφηση καθορίζοντας έναν κωδικό πρόσβασης μέσω μιας μεταβλητής περιβάλλοντος. Αλλά είναι καλύτερα να ξεχάσετε την απόδοση - αυτό είναι το κόστος της κρυπτογράφησης.
• Για κανονική χρήση συμβουλεύω τσίτι. Αυτό το CNI χρησιμοποιείται ευρέως σε διάφορα εργαλεία ανάπτυξης Kubernetes (Kops, Kubespray, Rancher, κ.λπ.). Όπως και με το WeaveNet, φροντίστε να διαμορφώσετε το MTU στο ConfigMap εάν χρησιμοποιείτε jumbo frames. Είναι ένα πολυλειτουργικό εργαλείο που είναι αποδοτικό όσον αφορά την κατανάλωση πόρων, την απόδοση και την ασφάλεια.

Και τέλος, σας συμβουλεύω να παρακολουθήσετε την εξέλιξη Τσίλιουμ. Αυτό το CNI έχει μια πολύ ενεργή ομάδα που εργάζεται πολύ για το προϊόν του (χαρακτηριστικά, εξοικονόμηση πόρων, απόδοση, ασφάλεια, ομαδοποίηση...) και έχει πολύ ενδιαφέροντα σχέδια.

Οπτικό διάγραμμα για επιλογή CNI

Πηγή: www.habr.com