Kubernetes 1.16: Τα κυριότερα σημεία των νέων

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

Οι πληροφορίες που χρησιμοποιούνται για την προετοιμασία αυτού του υλικού προέρχονται από Πίνακες παρακολούθησης βελτιώσεων Kubernetes, ΑΛΛΑΓΗ-1.16 και σχετικά ζητήματα, αιτήματα έλξης και προτάσεις βελτίωσης Kubernetes (ΚΕΠ). Λοιπόν πάμε!..

Κόμβοι

Ένας πραγματικά μεγάλος αριθμός αξιοσημείωτων καινοτομιών (σε κατάσταση έκδοσης alpha) παρουσιάζεται στο πλάι των κόμβων συμπλέγματος K8 (Kubelet).

Πρώτον, το λεγόμενο «εφήμερα δοχεία» (Εφήμερα δοχεία), σχεδιασμένο για να απλοποιεί τις διαδικασίες εντοπισμού σφαλμάτων σε ομάδες διαφημίσεων. Ο νέος μηχανισμός σάς επιτρέπει να λανσάρετε ειδικά κοντέινερ που ξεκινούν από τον χώρο ονομάτων των υπαρχόντων pods και ζουν για μικρό χρονικό διάστημα. Σκοπός τους είναι να αλληλεπιδρούν με άλλα pods και κοντέινερ προκειμένου να λύσουν τυχόν προβλήματα και να διορθώσουν σφάλματα. Μια νέα εντολή έχει εφαρμοστεί για αυτό το χαρακτηριστικό kubectl debug, παρόμοια στην ουσία με kubectl exec: μόνο αντί να εκτελείται μια διαδικασία σε ένα κοντέινερ (όπως στο exec) εκτοξεύει ένα κοντέινερ σε ένα λοβό. Για παράδειγμα, αυτή η εντολή θα συνδέσει ένα νέο κοντέινερ σε ένα pod:

kubectl debug -c debug-shell --image=debian target-pod -- bash

Λεπτομέρειες σχετικά με τα εφήμερα δοχεία (και παραδείγματα χρήσης τους) μπορείτε να βρείτε στο αντίστοιχο ΚΕΠ. Η τρέχουσα υλοποίηση (στο K8s 1.16) είναι μια έκδοση άλφα και μεταξύ των κριτηρίων για τη μεταφορά της σε έκδοση beta είναι η "δοκιμή του Ephemeral Containers API για τουλάχιστον 2 εκδόσεις του [Kubernetes]."

NB: Στην ουσία του, ακόμη και στο όνομά του, το χαρακτηριστικό μοιάζει με ένα ήδη υπάρχον πρόσθετο kubectl-debugγια το οποίο εμείς έγραψε ήδη. Αναμένεται ότι με την έλευση των εφήμερων κοντέινερ, η ανάπτυξη ενός ξεχωριστού εξωτερικού πρόσθετου θα σταματήσει.

Μια άλλη καινοτομία - PodOverhead - σχεδιασμένο να παρέχει μηχανισμός υπολογισμού γενικών εξόδων για λοβούς, το οποίο μπορεί να διαφέρει σημαντικά ανάλογα με το χρόνο εκτέλεσης που χρησιμοποιείται. Για παράδειγμα, οι συγγραφείς αυτό το ΚΕΠ καταλήγουν σε δοχεία Kata, τα οποία απαιτούν εκτέλεση του πυρήνα επισκέπτη, του πράκτορα kata, του συστήματος init κ.λπ. Όταν τα γενικά έξοδα γίνονται τόσο μεγάλα, δεν μπορούν να αγνοηθούν, πράγμα που σημαίνει ότι πρέπει να υπάρχει τρόπος να ληφθούν υπόψη για περαιτέρω ποσοστώσεις, προγραμματισμό κ.λπ. Για την εφαρμογή του σε PodSpec προστέθηκε πεδίο Overhead *ResourceList (συγκρίνεται με δεδομένα σε RuntimeClass, εάν χρησιμοποιείται).

Μια άλλη αξιοσημείωτη καινοτομία είναι διαχειριστής τοπολογίας κόμβου (Διαχειριστής Τοπολογίας Κόμβου), που σχεδιάστηκε για να ενοποιήσει την προσέγγιση για τη λεπτομερή ρύθμιση της κατανομής πόρων υλικού για διάφορα στοιχεία στο Kubernetes. Η πρωτοβουλία αυτή καθοδηγείται από την αυξανόμενη ανάγκη διαφόρων σύγχρονων συστημάτων (από τον τομέα των τηλεπικοινωνιών, της μηχανικής μάθησης, των χρηματοοικονομικών υπηρεσιών κ.λπ.) για παράλληλους υπολογιστές υψηλής απόδοσης και ελαχιστοποίηση των καθυστερήσεων στην εκτέλεση λειτουργιών, για τα οποία χρησιμοποιούν προηγμένη CPU και δυνατότητες επιτάχυνσης υλικού. Τέτοιες βελτιστοποιήσεις στο Kubernetes έχουν επιτευχθεί μέχρι στιγμής χάρη σε διαφορετικά στοιχεία (διαχειριστής CPU, Διαχείριση συσκευών, CNI), και τώρα θα προστεθεί μια ενιαία εσωτερική διεπαφή που ενοποιεί την προσέγγιση και απλοποιεί τη σύνδεση νέων παρόμοιων - λεγόμενων τοπολογιών- γνωρίζουν - εξαρτήματα στην πλευρά Kubelet. Λεπτομέρειες - μέσα αντίστοιχο ΚΕΠ.

Διάγραμμα Στοιχείων Διαχείρισης Τοπολογίας

Επόμενο χαρακτηριστικό - ελέγχοντας τα δοχεία ενώ βρίσκονται σε λειτουργία (ανιχνευτής εκκίνησης). Όπως γνωρίζετε, για κοντέινερ που χρειάζονται πολύ χρόνο για να εκτοξευθούν, είναι δύσκολο να αποκτήσουν μια ενημερωμένη κατάσταση: είτε «σκοτώνονται» πριν αρχίσουν να λειτουργούν ή καταλήγουν σε αδιέξοδο για μεγάλο χρονικό διάστημα. Νέος έλεγχος (ενεργοποιήθηκε μέσω της πύλης χαρακτηριστικών που καλείται StartupProbeEnabled) ακυρώνει - ή μάλλον, αναβάλλει - την επίδραση τυχόν άλλων ελέγχων μέχρι τη στιγμή που το pod έχει τελειώσει. Για το λόγο αυτό, το χαρακτηριστικό είχε αρχικά κληθεί pod-startup liveness-probe holdoff. Για τις ομάδες που χρειάζονται πολύ χρόνο για να ξεκινήσουν, μπορείτε να κάνετε δημοσκόπηση της κατάστασης σε σχετικά σύντομα χρονικά διαστήματα.

Επιπλέον, μια βελτίωση για το RuntimeClass είναι άμεσα διαθέσιμη σε κατάσταση beta, προσθέτοντας υποστήριξη για «ετερογενή συμπλέγματα». ντο Προγραμματισμός RuntimeClass Τώρα δεν είναι καθόλου απαραίτητο για κάθε κόμβο να έχει υποστήριξη για κάθε RuntimeClass: για pods μπορείτε να επιλέξετε RuntimeClass χωρίς να σκεφτείτε την τοπολογία του συμπλέγματος. Προηγουμένως, για να επιτευχθεί αυτό - ώστε τα pods να καταλήγουν σε κόμβους με υποστήριξη για όλα όσα χρειάζονται - ήταν απαραίτητο να εκχωρηθούν κατάλληλοι κανόνες στο NodeSelector και στις ανοχές. ΣΕ ΚΕΠ Μιλάει για παραδείγματα χρήσης και, φυσικά, λεπτομέρειες υλοποίησης.

Δικτύου

Δύο σημαντικές δυνατότητες δικτύωσης που εμφανίστηκαν για πρώτη φορά (σε έκδοση alpha) στο Kubernetes 1.16 είναι:

• Υποστήριξη διπλή στοίβα δικτύου - IPv4/IPv6 - και την αντίστοιχη «κατανόησή» του σε επίπεδο λοβών, κόμβων, υπηρεσιών. Περιλαμβάνει διαλειτουργικότητα IPv4-to-IPv4 και IPv6-to-IPv6 μεταξύ pods, από pods σε εξωτερικές υπηρεσίες, υλοποιήσεις αναφοράς (εντός των προσθηκών Bridge CNI, PTP CNI και Host-Local IPAM), καθώς και αντίστροφη Συμβατότητα με συμπλέγματα Kubernetes που εκτελούνται Μόνο IPv4 ή IPv6. Οι λεπτομέρειες υλοποίησης περιλαμβάνονται ΚΕΠ.

  Ένα παράδειγμα εμφάνισης διευθύνσεων IP δύο τύπων (IPv4 και IPv6) στη λίστα των pods:

  kube-master# kubectl get pods -o wide
  NAME               READY     STATUS    RESTARTS   AGE       IP                          NODE
  nginx-controller   1/1       Running   0          20m       fd00:db8:1::2,192.168.1.3   kube-minion-1
  kube-master#

• Νέο API για Endpoint - EndpointSlice API. Επιλύει τα ζητήματα απόδοσης/κλιμάκωσης του υπάρχοντος API Endpoint που επηρεάζουν διάφορα στοιχεία στο επίπεδο ελέγχου (apiserver, etcd, endpoints-controller, kube-proxy). Το νέο API θα προστεθεί στην ομάδα Discovery API και θα μπορεί να εξυπηρετεί δεκάδες χιλιάδες endpoints backend σε κάθε υπηρεσία σε ένα σύμπλεγμα που αποτελείται από χιλιάδες κόμβους. Για να γίνει αυτό, κάθε Υπηρεσία αντιστοιχίζεται σε N αντικείμενα EndpointSlice, καθένα από τα οποία από προεπιλογή δεν έχει περισσότερα από 100 τελικά σημεία (η τιμή μπορεί να διαμορφωθεί). Το EndpointSlice API θα παρέχει επίσης ευκαιρίες για τη μελλοντική του ανάπτυξη: υποστήριξη για πολλαπλές διευθύνσεις IP για κάθε ομάδα, νέες καταστάσεις για τελικά σημεία (όχι μόνο Ready и NotReady), δυναμική υπορύθμιση για τελικά σημεία.

Αυτό που παρουσιάστηκε στην τελευταία έκδοση έχει φτάσει στην έκδοση beta τελικός, με όνομα service.kubernetes.io/load-balancer-cleanup και επισυνάπτεται σε κάθε υπηρεσία με τύπο LoadBalancer. Τη στιγμή της διαγραφής μιας τέτοιας υπηρεσίας, αποτρέπει την πραγματική διαγραφή του πόρου μέχρι να ολοκληρωθεί η «εκκαθάριση» όλων των σχετικών πόρων εξισορροπητή.

Μηχανήματα API

Το πραγματικό «ορόσημο σταθεροποίησης» βρίσκεται στην περιοχή του διακομιστή API Kubernetes και στην αλληλεπίδραση με αυτόν. Αυτό συνέβη σε μεγάλο βαθμό χάρη σε μεταφέροντας σε σταθερή κατάσταση όσους δεν χρειάζονται ειδική εισαγωγή Προσαρμοσμένοι ορισμοί πόρων (CRD), που είχαν κατάσταση beta από τις μακρινές μέρες του Kubernetes 1.7 (και αυτός είναι ο Ιούνιος του 2017!). Η ίδια σταθεροποίηση ήρθε στα σχετικά χαρακτηριστικά:

• "υποπηγές" με /status и /scale για CustomResources.
• μετασχηματισμού εκδόσεις για CRD, βασισμένες σε εξωτερικό webhook.
• παρουσιάστηκε πρόσφατα (στο K8s 1.15) προεπιλεγμένες τιμές (προεπιλογή) και αυτόματη αφαίρεση πεδίου (κλάδεμα) για CustomResources.
• ευκαιρία χρησιμοποιώντας το σχήμα OpenAPI v3 για τη δημιουργία και τη δημοσίευση τεκμηρίωσης OpenAPI που χρησιμοποιείται για την επικύρωση πόρων CRD στην πλευρά του διακομιστή.

Ένας άλλος μηχανισμός που έχει γίνει γνωστός από καιρό στους διαχειριστές της Kubernetes: webhook εισδοχής - παρέμεινε επίσης σε κατάσταση beta για μεγάλο χρονικό διάστημα (από το K8s 1.9) και τώρα έχει δηλωθεί σταθερό.

Δύο άλλες λειτουργίες έχουν φτάσει σε έκδοση beta: ισχύει από την πλευρά του διακομιστή и σελιδοδείκτες ρολογιών.

Και η μόνη σημαντική καινοτομία στην άλφα έκδοση ήταν αποτυχία από SelfLink — ένα ειδικό URI που αντιπροσωπεύει το καθορισμένο αντικείμενο και αποτελεί μέρος του ObjectMeta и ListMeta (δηλαδή μέρος οποιουδήποτε αντικειμένου στο Kubernetes). Γιατί το εγκαταλείπουν; Κίνητρα με απλό τρόπο ήχους καθώς η απουσία πραγματικών (συντριπτικών) λόγων για να υπάρχει ακόμα αυτό το πεδίο. Πιο επίσημοι λόγοι είναι η βελτιστοποίηση της απόδοσης (με την αφαίρεση ενός περιττού πεδίου) και η απλοποίηση της εργασίας του γενικού-apiserver, ο οποίος αναγκάζεται να χειριστεί ένα τέτοιο πεδίο με ειδικό τρόπο (αυτό είναι το μόνο πεδίο που έχει οριστεί ακριβώς πριν από το αντικείμενο είναι σειριακή). Πραγματική απαξίωση (εντός beta) SelfLink θα γίνει από την έκδοση 1.20 του Kubernetes και την τελική - 1.21.

Αποθήκευση δεδομένων

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

• για πρώτη φορά (σε έκδοση alpha) εμφανίστηκε Υποστήριξη προσθήκης CSI για κόμβους εργασίας των Windows: ο τρέχων τρόπος εργασίας με τον χώρο αποθήκευσης θα αντικαταστήσει επίσης τις προσθήκες in-tree στον πυρήνα Kubernetes και τις προσθήκες FlexVolume από τη Microsoft που βασίζονται στο Powershell.

  
  Σχέδιο για την υλοποίηση προσθηκών CSI στο Kubernetes για Windows

• ευκαιρία αλλαγή μεγέθους τόμων CSI, που παρουσιάστηκε ξανά στο K8s 1.12, έχει εξελιχθεί σε έκδοση beta.
• Μια παρόμοια «προώθηση» (από άλφα σε βήτα) επιτεύχθηκε με τη δυνατότητα χρήσης CSI για τη δημιουργία τοπικών εφήμερων τόμων (Υποστήριξη ενσωματωμένου τόμου CSI).

Παρουσιάστηκε στην προηγούμενη έκδοση του Kubernetes λειτουργία κλωνοποίησης όγκου (χρησιμοποιώντας υπάρχον PVC ως DataSource για τη δημιουργία νέου PVC) έχει επίσης λάβει πλέον κατάσταση beta.

Προγραμματιστής

Δύο αξιοσημείωτες αλλαγές στον προγραμματισμό (και οι δύο σε alpha):

• EvenPodsSpreading - ευκαιρία χρησιμοποιήστε λοβούς αντί για μονάδες λογικής εφαρμογής για «δίκαιη κατανομή» των φορτίων (όπως το Deployment και το ReplicaSet) και την προσαρμογή αυτής της κατανομής (ως σκληρή απαίτηση ή ως μαλακή συνθήκη, δηλ. προτεραιότητα). Η δυνατότητα θα επεκτείνει τις υπάρχουσες δυνατότητες διανομής των προγραμματισμένων pod, που επί του παρόντος περιορίζονται από επιλογές PodAffinity и PodAntiAffinity, δίνοντας στους διαχειριστές καλύτερο έλεγχο σε αυτό το θέμα, πράγμα που σημαίνει καλύτερη υψηλή διαθεσιμότητα και βελτιστοποιημένη κατανάλωση πόρων. Λεπτομέρειες - μέσα ΚΕΠ.
• Χρήση Πολιτική BestFit в Λειτουργία προτεραιότητας RequestedTo CapacityRatio κατά τον προγραμματισμό λοβών, που θα επιτρέψει ισχύουν συσκευασία κάδου ("packing in containers") τόσο για βασικούς πόρους (επεξεργαστής, μνήμη) όσο και για εκτεταμένους (όπως GPU). Για περισσότερες λεπτομέρειες, βλ ΚΕΠ.

  
  Προγραμματισμός ομάδων: πριν από τη χρήση της πολιτικής βέλτιστης προσαρμογής (απευθείας μέσω του προεπιλεγμένου χρονοπρογραμματιστή) και με τη χρήση του (μέσω του προγραμματιστή επέκτασης)

Περαιτέρω, παρουσιάζονται τη δυνατότητα να δημιουργήσετε τα δικά σας πρόσθετα προγραμματιστή εκτός του κύριου δέντρου ανάπτυξης Kubernetes (εκτός δέντρου).

Άλλες αλλαγές

Επίσης στην έκδοση Kubernetes 1.16 μπορεί να σημειωθεί πρωτοβουλία για φέρνοντας διαθέσιμες μετρήσεις με πλήρη σειρά, ή ακριβέστερα, σύμφωνα με επίσημους κανονισμούς στα όργανα K8s. Βασίζονται σε μεγάλο βαθμό στο αντίστοιχο Τεκμηρίωση Προμηθέας. Προέκυψαν ασυνέπειες για διάφορους λόγους (για παράδειγμα, ορισμένες μετρήσεις δημιουργήθηκαν απλώς πριν εμφανιστούν οι τρέχουσες οδηγίες) και οι προγραμματιστές αποφάσισαν ότι ήταν καιρός να φέρουν τα πάντα σε ένα ενιαίο πρότυπο, «σύμφωνα με το υπόλοιπο οικοσύστημα του Prometheus». Η τρέχουσα εφαρμογή αυτής της πρωτοβουλίας βρίσκεται σε κατάσταση άλφα, η οποία θα προωθηθεί σταδιακά στις επόμενες εκδόσεις του Kubernetes σε beta (1.17) και σταθερή (1.18).

Επιπλέον, μπορούν να σημειωθούν οι ακόλουθες αλλαγές:

• Ανάπτυξη υποστήριξης των Windows с εμφάνιση Βοηθητικά προγράμματα Kubeadm για αυτό το λειτουργικό σύστημα (άλφα έκδοση), ευκαιρία RunAsUserName για κοντέινερ Windows (έκδοση άλφα), βελτίωση Υποστήριξη ομαδικού διαχειριζόμενου λογαριασμού υπηρεσίας (gMSA) έως την έκδοση beta, υποστήριξη προσάρτηση/προσάρτηση για τόμους vSphere.
• Ανακυκλωμένο μηχανισμός συμπίεσης δεδομένων σε αποκρίσεις API. Προηγουμένως, χρησιμοποιήθηκε ένα φίλτρο HTTP για αυτούς τους σκοπούς, το οποίο επέβαλε ορισμένους περιορισμούς που εμπόδιζαν την ενεργοποίησή του από προεπιλογή. Η "Διαφανής συμπίεση αιτήματος" λειτουργεί τώρα: αποστολή πελατών Accept-Encoding: gzip στην κεφαλίδα, λαμβάνουν μια απόκριση συμπιεσμένη με GZIP εάν το μέγεθός της υπερβαίνει τα 128 KB. Οι πελάτες Go υποστηρίζουν αυτόματα τη συμπίεση (αποστολή της απαιτούμενης κεφαλίδας), έτσι θα παρατηρήσουν αμέσως μείωση της επισκεψιμότητας. (Μπορεί να χρειαστούν μικρές τροποποιήσεις για άλλες γλώσσες.)
• Έγινε δυνατό κλιμάκωση HPA από/σε μηδενικές ομάδες με βάση εξωτερικές μετρήσεις. Εάν κάνετε κλιμάκωση βάσει αντικειμένων/εξωτερικών μετρήσεων, τότε όταν ο φόρτος εργασίας είναι αδρανής, μπορείτε να κλιμακώσετε αυτόματα σε 0 αντίγραφα για εξοικονόμηση πόρων. Αυτή η δυνατότητα θα πρέπει να είναι ιδιαίτερα χρήσιμη για περιπτώσεις όπου οι εργαζόμενοι ζητούν πόρους GPU και ο αριθμός των διαφορετικών τύπων εργαζομένων σε αδράνεια υπερβαίνει τον αριθμό των διαθέσιμων GPU.
• Νέος πελάτης - k8s.io/client-go/metadata.Client — για «γενικευμένη» πρόσβαση σε αντικείμενα. Έχει σχεδιαστεί για να ανακτά εύκολα μεταδεδομένα (δηλαδή υποενότητα metadata) από πόρους συμπλέγματος και να εκτελέσετε εργασίες συλλογής σκουπιδιών και ποσοστώσεων μαζί τους.
• Κατασκευάστε το Kubernetes τώρα μπορείς χωρίς παλαιού τύπου («ενσωματωμένους» σε δέντρο) παρόχους cloud (έκδοση άλφα).
• Στο βοηθητικό πρόγραμμα kubeadm προστέθηκε πειραματική (έκδοση άλφα) δυνατότητα εφαρμογής προσαρμοσμένων ενημερώσεων κώδικα κατά τη διάρκεια λειτουργιών init, join и upgrade. Μάθετε περισσότερα σχετικά με τον τρόπο χρήσης της σημαίας --experimental-kustomize, δείτε στο ΚΕΠ.
• Νέο τελικό σημείο για apiserver - readyz, - σας επιτρέπει να εξάγετε πληροφορίες σχετικά με την ετοιμότητά του. Ο διακομιστής API έχει επίσης μια σημαία --maximum-startup-sequence-duration, επιτρέποντάς σας να ρυθμίσετε τις επανεκκινήσεις του.
• Δύο χαρακτηριστικά για το Azure δηλώθηκε σταθερός: υποστήριξη ζώνες διαθεσιμότητας (Ζώνες Διαθεσιμότητας) και διασταυρούμενη ομάδα πόρων (RG). Επιπλέον, η Azure πρόσθεσε:
  • υποστήριξη ελέγχου ταυτότητας AAD και ADFS.
  • σχολιασμός service.beta.kubernetes.io/azure-pip-name για να καθορίσετε τη δημόσια IP του εξισορροπητή φορτίου.
  • ευκαιρία ρυθμίσεις LoadBalancerName и LoadBalancerResourceGroup.
• Το AWS έχει τώρα υποστήριξη για EBS σε Windows και βελτιστοποιημένη Κλήσεις EC2 API DescribeInstances.
• Η Kubeadm είναι πλέον ανεξάρτητη μεταναστεύει Διαμόρφωση CoreDNS κατά την αναβάθμιση της έκδοσης CoreDNS.
• Δυαδικά κλπ στην αντίστοιχη εικόνα Docker έχουν κάνει world-executable, το οποίο σας επιτρέπει να εκτελέσετε αυτήν την εικόνα χωρίς να χρειάζεστε δικαιώματα root. Επίσης, εικόνα μετεγκατάστασης etcd έπαυσε Υποστήριξη έκδοσης etcd2.
• В Cluster Autoscaler 1.16.0 άλλαξε στη χρήση του distroless ως βασικής εικόνας, βελτιώθηκε η απόδοση, προστέθηκαν νέοι πάροχοι cloud (DigitalOcean, Magnum, Packet).
• Ενημερώσεις σε χρησιμοποιημένο/εξαρτώμενο λογισμικό: Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.

PS

Διαβάστε επίσης στο blog μας:

• «Kubernetes 1.15: Τα κυριότερα σημεία των νέων"?
• «Kubernetes 1.14: Τα κυριότερα σημεία των νέων"?
• «Kubernetes 1.13: Τα κυριότερα σημεία των νέων"?
• «Kubernetes 1.12: Τα κυριότερα σημεία των νέων».

Πηγή: www.habr.com