Αλλαγές από το Helm 2

Αλλαγές από το Helm 2

Ακολουθεί μια ολοκληρωμένη λίστα με όλες τις σημαντικές αλλαγές που εισήχθησαν στο Helm 3.

Κατάργηση του Tiller

Κατά τη διάρκεια του κύκλου ανάπτυξης του Helm 2, εισαγάγαμε τον Tiller. Ο Tiller διαδραμάτισε σημαντικό ρόλο για ομάδες που εργάζονται σε ένα κοινόχρηστο cluster — releases.

Με τον έλεγχο πρόσβασης βάσει ρόλων (RBAC) ενεργοποιημένο από προεπιλογή στο Kubernetes 1.6, η ασφάλιση του Tiller για χρήση σε παραγωγικό περιβάλλον έγινε πιο δύσκολη στη διαχείριση. Λόγω του μεγάλου αριθμού πιθανών πολιτικών ασφαλείας, η προσέγγισή μας ήταν να παρέχουμε μια επιτρεπτική προεπιλεγμένη ρύθμιση. Αυτό επέτρεπε στους νέους χρήστες να ξεκινήσουν να πειραματίζονται με το Helm και το Kubernetes χωρίς να χρειάζεται να εμβαθύνουν αμέσως στους ελέγχους ασφαλείας. Δυστυχώς, αυτή η επιτρεπτική ρύθμιση μπορούσε να δώσει σε έναν χρήστη ένα ευρύ φάσμα δικαιωμάτων που δεν προοριζόταν να έχει. Οι DevOps και SREs έπρεπε να μάθουν επιπλέον διαδικασίες κατά την εγκατάσταση του Tiller σε ένα multi-tenant cluster.

Αφού ακούσαμε πώς τα μέλη της κοινότητας χρησιμοποιούσαν το Helm σε διάφορα σενάρια, διαπιστώσαμε ότι το σύστημα διαχείρισης releases του Tiller δεν χρειαζόταν να βασίζεται σε έναν in-cluster operator για να διατηρεί την κατάσταση ή να λειτουργεί ως κεντρικός κόμβος για τις πληροφορίες release του Helm. Αντ' αυτού, μπορούσαμε απλά να ανακτούμε πληροφορίες από τον Kubernetes API server, να κάνουμε render τα Charts στην πλευρά του client και να αποθηκεύουμε μια εγγραφή της εγκατάστασης στο Kubernetes.

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

Με την κατάργηση του Tiller, το μοντέλο ασφαλείας του Helm απλοποιείται ριζικά. Το Helm 3 υποστηρίζει πλέον όλες τις σύγχρονες δυνατότητες ασφάλειας, ταυτότητας και εξουσιοδότησης του σύγχρονου Kubernetes. Τα δικαιώματα του Helm αξιολογούνται χρησιμοποιώντας το αρχείο kubeconfig σας. Οι διαχειριστές του cluster μπορούν να περιορίσουν τα δικαιώματα των χρηστών με όποια λεπτομέρεια επιθυμούν. Τα releases εξακολουθούν να καταγράφονται εντός του cluster και η υπόλοιπη λειτουργικότητα του Helm παραμένει αμετάβλητη.

Βελτιωμένη Στρατηγική Αναβάθμισης: 3-way Strategic Merge Patches

Το Helm 2 χρησιμοποιούσε ένα two-way strategic merge patch. Κατά τη διάρκεια μιας αναβάθμισης, συνέκρινε το manifest του πιο πρόσφατου chart με το προτεινόμενο manifest του chart (αυτό που παρέχεται κατά το helm upgrade). Συνέκρινε τις διαφορές μεταξύ αυτών των δύο charts για να προσδιορίσει ποιες αλλαγές έπρεπε να εφαρμοστούν στους πόρους του Kubernetes. Αν εφαρμόζονταν αλλαγές στο cluster εκτός του Helm (όπως κατά τη διάρκεια ενός kubectl edit), αυτές οι αλλαγές δεν λαμβάνονταν υπόψη. Αυτό είχε ως αποτέλεσμα οι πόροι να μην μπορούν να επαναφερθούν στην προηγούμενη κατάστασή τους: επειδή το Helm θεωρούσε μόνο το τελευταίο εφαρμοσμένο manifest του chart ως την τρέχουσα κατάσταση, αν δεν υπήρχαν αλλαγές στην κατάσταση του chart, η live κατάσταση παρέμενε αμετάβλητη.

Στο Helm 3, χρησιμοποιούμε πλέον ένα three-way strategic merge patch. Το Helm λαμβάνει υπόψη το παλιό manifest, τη live κατάστασή του και το νέο manifest κατά τη δημιουργία ενός patch.

Παραδείγματα

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

Επαναφορά όταν η live κατάσταση έχει αλλάξει

Η ομάδα σας μόλις έκανε deploy την εφαρμογή της στο production στο Kubernetes χρησιμοποιώντας το Helm. Το chart περιέχει ένα αντικείμενο Deployment όπου ο αριθμός των replicas έχει οριστεί σε τρία:

$ helm install myapp ./myapp

Ένας νέος developer εντάσσεται στην ομάδα. Την πρώτη του ημέρα, ενώ παρατηρεί το production cluster, συμβαίνει ένα φρικτό ατύχημα με καφέ που χύνεται στο πληκτρολόγιο και κάνει kubectl scale το production deployment από τρία replicas σε μηδέν.

$ kubectl scale --replicas=0 deployment/myapp

Ένας άλλος developer της ομάδας σας παρατηρεί ότι το production site είναι εκτός λειτουργίας και αποφασίζει να κάνει rollback το release στην προηγούμενη κατάστασή του:

$ helm rollback myapp

Τι συμβαίνει;

Στο Helm 2, θα δημιουργούσε ένα patch συγκρίνοντας το παλιό manifest με το νέο manifest. Επειδή πρόκειται για rollback, είναι το ίδιο manifest. Το Helm θα καθόριζε ότι δεν υπάρχει τίποτα να αλλάξει επειδή δεν υπάρχει διαφορά μεταξύ του παλιού και του νέου manifest. Ο αριθμός των replicas συνεχίζει να παραμένει στο μηδέν. Ακολουθεί πανικός.

Στο Helm 3, το patch δημιουργείται χρησιμοποιώντας το παλιό manifest, τη live κατάσταση και το νέο manifest. Το Helm αναγνωρίζει ότι η παλιά κατάσταση ήταν τρία, η live κατάσταση είναι μηδέν και το νέο manifest επιθυμεί να το αλλάξει πίσω σε τρία, οπότε δημιουργεί ένα patch για να επαναφέρει την κατάσταση σε τρία.

Αναβαθμίσεις όταν η live κατάσταση έχει αλλάξει

Πολλά service meshes και άλλες εφαρμογές που βασίζονται σε controllers εισάγουν δεδομένα σε αντικείμενα Kubernetes. Αυτό μπορεί να είναι κάτι σαν sidecar, labels ή άλλες πληροφορίες. Προηγουμένως, αν είχατε το παρακάτω manifest που προέκυψε από ένα Chart:

containers:
- name: server
  image: nginx:2.0.0

Και η live κατάσταση τροποποιήθηκε από μια άλλη εφαρμογή σε:

containers:
- name: server
  image: nginx:2.0.0
- name: my-injected-sidecar
  image: my-cool-mesh:1.0.0

Τώρα, θέλετε να αναβαθμίσετε το image tag του nginx σε 2.1.0. Οπότε, αναβαθμίζετε σε ένα chart με το παρακάτω manifest:

containers:
- name: server
  image: nginx:2.1.0

Τι συμβαίνει;

Στο Helm 2, το Helm δημιουργεί ένα patch του αντικειμένου containers μεταξύ του παλιού manifest και του νέου manifest. Η live κατάσταση του cluster δεν λαμβάνεται υπόψη κατά τη δημιουργία του patch.

Η live κατάσταση του cluster τροποποιείται ώστε να μοιάζει με το εξής:

containers:
- name: server
  image: nginx:2.1.0

Το sidecar pod αφαιρείται από τη live κατάσταση. Ακολουθεί περισσότερος πανικός.

Στο Helm 3, το Helm δημιουργεί ένα patch του αντικειμένου containers μεταξύ του παλιού manifest, της live κατάστασης και του νέου manifest. Παρατηρεί ότι το νέο manifest αλλάζει το image tag σε 2.1.0, αλλά η live κατάσταση περιέχει ένα sidecar container.

Η live κατάσταση του cluster τροποποιείται ώστε να μοιάζει με το εξής:

containers:
- name: server
  image: nginx:2.1.0
- name: my-injected-sidecar
  image: my-cool-mesh:1.0.0

Τα ονόματα Release περιορίζονται πλέον στο Namespace

Με την κατάργηση του Tiller, οι πληροφορίες για κάθε release έπρεπε να αποθηκευτούν κάπου. Στο Helm 2, αυτές αποθηκεύονταν στο ίδιο namespace με τον Tiller. Στην πράξη, αυτό σήμαινε ότι μόλις χρησιμοποιούνταν ένα όνομα από ένα release, κανένα άλλο release δεν μπορούσε να χρησιμοποιήσει το ίδιο όνομα, ακόμα κι αν γινόταν deploy σε διαφορετικό namespace.

Στο Helm 3, οι πληροφορίες για ένα συγκεκριμένο release αποθηκεύονται πλέον στο ίδιο namespace με το release. Αυτό σημαίνει ότι οι χρήστες μπορούν πλέον να εκτελέσουν helm install wordpress stable/wordpress σε δύο ξεχωριστά namespaces και σε καθένα μπορεί να γίνει αναφορά με helm list αλλάζοντας το τρέχον context του namespace (π.χ. helm list --namespace foo).

Με αυτή τη μεγαλύτερη ευθυγράμμιση με τα native cluster namespaces, η εντολή helm list δεν εμφανίζει πλέον όλα τα releases από προεπιλογή. Αντ' αυτού, θα εμφανίσει μόνο τα releases στο namespace του τρέχοντος kubernetes context σας (δηλαδή το namespace που εμφανίζεται όταν εκτελείτε kubectl config view --minify). Αυτό σημαίνει επίσης ότι πρέπει να παρέχετε τη σημαία --all-namespaces στην εντολή helm list για να έχετε συμπεριφορά παρόμοια με το Helm 2.

Τα Secrets ως προεπιλεγμένος storage driver

Στο Helm 3, τα Secrets χρησιμοποιούνται πλέον ως προεπιλεγμένος storage driver. Το Helm 2 χρησιμοποιούσε ConfigMaps από προεπιλογή για την αποθήκευση πληροφοριών release. Στο Helm 2.7.0, υλοποιήθηκε ένα νέο storage backend που χρησιμοποιεί Secrets για την αποθήκευση πληροφοριών release, και είναι πλέον η προεπιλογή από το Helm 3.

Η αλλαγή σε Secrets ως προεπιλογή του Helm 3 επιτρέπει πρόσθετη ασφάλεια στην προστασία των charts σε συνδυασμό με την κυκλοφορία της κρυπτογράφησης Secret στο Kubernetes.

Η Κρυπτογράφηση secrets σε κατάσταση ηρεμίας έγινε διαθέσιμη ως alpha δυνατότητα στο Kubernetes 1.7 και σταθεροποιήθηκε στο Kubernetes 1.13. Αυτό επιτρέπει στους χρήστες να κρυπτογραφούν τα μεταδεδομένα release του Helm σε κατάσταση ηρεμίας, και αποτελεί ένα καλό σημείο εκκίνησης που μπορεί να επεκταθεί αργότερα για χρήση κάποιου εργαλείου όπως το Vault.

Αλλαγές στο Go import path

Στο Helm 3, το Helm άλλαξε το Go import path από k8s.io/helm σε helm.sh/helm/v3. Αν σκοπεύετε να αναβαθμίσετε στις Go client libraries του Helm 3, φροντίστε να αλλάξετε τα import paths σας.

Capabilities

Το ενσωματωμένο αντικείμενο .Capabilities που είναι διαθέσιμο κατά τη φάση του rendering έχει απλοποιηθεί.

Ενσωματωμένα Αντικείμενα

Επικύρωση Chart Values με JSONSchema

Ένα JSON Schema μπορεί πλέον να επιβληθεί στα values ενός chart. Αυτό διασφαλίζει ότι τα values που παρέχει ο χρήστης ακολουθούν το schema που έχει ορίσει ο συντηρητής του chart, παρέχοντας καλύτερη αναφορά σφαλμάτων όταν ο χρήστης παρέχει λανθασμένα values για ένα chart.

Η επικύρωση πραγματοποιείται όταν εκτελείται οποιαδήποτε από τις παρακάτω εντολές:

• helm install
• helm upgrade
• helm template
• helm lint

Δείτε την τεκμηρίωση για τα Schema files για περισσότερες πληροφορίες.

Ενοποίηση του requirements.yaml στο Chart.yaml

Το σύστημα διαχείρισης εξαρτήσεων Chart μεταφέρθηκε από τα requirements.yaml και requirements.lock στα Chart.yaml και Chart.lock. Συνιστούμε τα νέα charts που προορίζονται για το Helm 3 να χρησιμοποιούν τη νέα μορφή. Ωστόσο, το Helm 3 εξακολουθεί να κατανοεί την έκδοση Chart API 1 (v1) και θα φορτώνει υπάρχοντα αρχεία requirements.yaml.

Στο Helm 2, έτσι έμοιαζε ένα requirements.yaml:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://charts.helm.sh/stable
  condition: mariadb.enabled
  tags:
    - database

Στο Helm 3, η εξάρτηση εκφράζεται με τον ίδιο τρόπο, αλλά πλέον μέσα στο Chart.yaml:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://charts.helm.sh/stable
  condition: mariadb.enabled
  tags:
    - database

Τα charts εξακολουθούν να κατεβαίνουν και να τοποθετούνται στον κατάλογο charts/, οπότε τα subcharts που έχουν ενσωματωθεί στον κατάλογο charts/ θα συνεχίσουν να λειτουργούν χωρίς τροποποίηση.

Το Name (ή --generate-name) απαιτείται πλέον κατά την εγκατάσταση

Στο Helm 2, αν δεν παρεχόταν όνομα, θα δινόταν ένα αυτόματα παραγόμενο όνομα. Στην παραγωγή, αυτό αποδείχτηκε περισσότερο ενόχληση παρά χρήσιμη δυνατότητα. Στο Helm 3, το Helm θα εμφανίσει σφάλμα αν δεν παρέχεται όνομα με το helm install.

Για όσους εξακολουθούν να θέλουν να δημιουργείται αυτόματα ένα όνομα, μπορείτε να χρησιμοποιήσετε τη σημαία --generate-name για να δημιουργηθεί ένα.

Αποστολή Charts σε OCI Registries

Αυτή είναι μια πειραματική δυνατότητα που εισήχθη στο Helm 3. Για να τη χρησιμοποιήσετε, ορίστε τη μεταβλητή περιβάλλοντος HELM_EXPERIMENTAL_OCI=1.

Σε υψηλό επίπεδο, ένα Chart Repository είναι μια τοποθεσία όπου μπορούν να αποθηκευτούν και να διαμοιραστούν Charts. Ο Helm client συσκευάζει και αποστέλλει Helm Charts σε ένα Chart Repository. Με απλά λόγια, ένα Chart Repository είναι ένας βασικός HTTP server που φιλοξενεί ένα αρχείο index.yaml και μερικά συσκευασμένα charts.

Ενώ υπάρχουν αρκετά οφέλη στο ότι το Chart Repository API καλύπτει τις πιο βασικές απαιτήσεις αποθήκευσης, έχουν αρχίσει να εμφανίζονται μερικά μειονεκτήματα:

• Τα Chart Repositories δυσκολεύονται πολύ να αφαιρέσουν τις περισσότερες από τις υλοποιήσεις ασφαλείας που απαιτούνται σε ένα παραγωγικό περιβάλλον. Η ύπαρξη ενός τυπικού API για authentication και authorization είναι πολύ σημαντική σε παραγωγικά σενάρια.
• Τα εργαλεία provenance του Helm που χρησιμοποιούνται για την υπογραφή και επαλήθευση της ακεραιότητας και προέλευσης ενός chart αποτελούν προαιρετικό μέρος της διαδικασίας δημοσίευσης Chart.
• Σε σενάρια multi-tenant, το ίδιο Chart μπορεί να ανεβεί από έναν άλλο tenant, κοστίζοντας διπλάσιο χώρο αποθήκευσης για το ίδιο περιεχόμενο. Έχουν σχεδιαστεί πιο έξυπνα chart repositories για να το αντιμετωπίσουν αυτό, αλλά δεν αποτελεί μέρος της επίσημης προδιαγραφής.
• Η χρήση ενός μόνο αρχείου index για αναζήτηση, πληροφορίες μεταδεδομένων και ανάκτηση Charts έχει κάνει δύσκολο ή αδέξιο τον σχεδιασμό σε ασφαλείς υλοποιήσεις multi-tenant.

Το project Distribution του Docker (γνωστό και ως Docker Registry v2) είναι ο διάδοχος του project Docker Registry. Πολλοί μεγάλοι cloud vendors προσφέρουν προϊόν βασισμένο στο project Distribution, και με τόσους vendors να προσφέρουν το ίδιο προϊόν, το project Distribution έχει επωφεληθεί από πολλά χρόνια σκληραγώγησης, βέλτιστων πρακτικών ασφαλείας και δοκιμών στην πράξη.

Παρακαλούμε δείτε τα helm help chart και helm help registry για περισσότερες πληροφορίες σχετικά με το πώς να συσκευάσετε ένα chart και να το αποστείλετε σε ένα Docker registry.

Για περισσότερες πληροφορίες, δείτε αυτή τη σελίδα.

Κατάργηση του helm serve

Η εντολή helm serve εκτελούσε ένα τοπικό Chart Repository στον υπολογιστή σας για σκοπούς ανάπτυξης. Ωστόσο, δεν είχε μεγάλη υιοθέτηση ως εργαλείο ανάπτυξης και είχε πολλά προβλήματα με τον σχεδιασμό της. Τελικά, αποφασίσαμε να την αφαιρέσουμε και να τη διαχωρίσουμε ως plugin.

Για μια παρόμοια εμπειρία με το helm serve, δείτε την επιλογή αποθήκευσης σε τοπικό filesystem στο ChartMuseum και το plugin servecm.

Υποστήριξη library chart

Το Helm 3 υποστηρίζει μια κατηγορία chart που ονομάζεται "library chart". Αυτό είναι ένα chart που διαμοιράζεται από άλλα charts, αλλά δεν δημιουργεί δικά του release artifacts. Τα templates ενός library chart μπορούν να δηλώνουν μόνο στοιχεία define. Περιεχόμενο με global scope που δεν είναι define απλά αγνοείται. Αυτό επιτρέπει στους χρήστες να επαναχρησιμοποιούν και να μοιράζονται αποσπάσματα κώδικα που μπορούν να χρησιμοποιηθούν σε πολλά charts, αποφεύγοντας την επανάληψη και διατηρώντας τα charts DRY.

Τα library charts δηλώνονται στην οδηγία dependencies στο Chart.yaml, και εγκαθίστανται και διαχειρίζονται όπως οποιοδήποτε άλλο chart.

dependencies:
  - name: mylib
    version: 1.x.x
    repository: quay.io

Είμαστε πολύ ενθουσιασμένοι να δούμε τις περιπτώσεις χρήσης που αυτή η δυνατότητα ανοίγει για τους developers chart, καθώς και τις βέλτιστες πρακτικές που προκύπτουν από τη χρήση library charts.

Αναβάθμιση του apiVersion στο Chart.yaml

Με την εισαγωγή της υποστήριξης library chart και την ενοποίηση του requirements.yaml στο Chart.yaml, τα clients που κατανοούσαν τη μορφή πακέτου του Helm 2 δεν θα κατανοούν αυτές τις νέες δυνατότητες. Έτσι, αυξήσαμε το apiVersion στο Chart.yaml από v1 σε v2.

Η εντολή helm create δημιουργεί πλέον charts χρησιμοποιώντας αυτή τη νέα μορφή, οπότε το προεπιλεγμένο apiVersion αυξήθηκε και εκεί.

Τα clients που επιθυμούν να υποστηρίζουν και τις δύο εκδόσεις Helm charts θα πρέπει να ελέγχουν το πεδίο apiVersion στο Chart.yaml για να κατανοήσουν πώς να αναλύσουν τη μορφή του πακέτου.

Υποστήριξη XDG Base Directory

Η Προδιαγραφή XDG Base Directory είναι ένα φορητό πρότυπο που ορίζει πού θα πρέπει να αποθηκεύονται τα αρχεία ρύθμισης, δεδομένων και cache στο filesystem.

Στο Helm 2, το Helm αποθήκευε όλες αυτές τις πληροφορίες στο ~/.helm (στοργικά γνωστό ως helm home), το οποίο μπορούσε να αλλάξει ορίζοντας τη μεταβλητή περιβάλλοντος $HELM_HOME ή χρησιμοποιώντας τη global σημαία --home.

Στο Helm 3, το Helm σέβεται πλέον τις ακόλουθες μεταβλητές περιβάλλοντος σύμφωνα με την Προδιαγραφή XDG Base Directory:

• $XDG_CACHE_HOME
• $XDG_CONFIG_HOME
• $XDG_DATA_HOME

Στα Helm plugins εξακολουθεί να περνιέται το $HELM_HOME ως alias για το $XDG_DATA_HOME για συμβατότητα προς τα πίσω με plugins που αναζητούν το $HELM_HOME ως scratchpad περιβάλλον.

Αρκετές νέες μεταβλητές περιβάλλοντος περνιούνται επίσης στο περιβάλλον του plugin για να υποστηρίξουν αυτή την αλλαγή:

• $HELM_PATH_CACHE για τη διαδρομή cache
• $HELM_PATH_CONFIG για τη διαδρομή config
• $HELM_PATH_DATA για τη διαδρομή data

Τα Helm plugins που επιθυμούν να υποστηρίξουν το Helm 3 θα πρέπει να εξετάσουν τη χρήση αυτών των νέων μεταβλητών περιβάλλοντος αντί αυτών.

Μετονομασίες εντολών CLI

Για καλύτερη ευθυγράμμιση της ορολογίας με άλλους package managers, η εντολή helm delete μετονομάστηκε σε helm uninstall. Η helm delete διατηρείται ακόμα ως alias για την helm uninstall, οπότε μπορεί να χρησιμοποιηθεί οποιαδήποτε από τις δύο μορφές.

Στο Helm 2, για να διαγραφεί το ledger του release, έπρεπε να παρέχεται η σημαία --purge. Αυτή η λειτουργικότητα είναι πλέον ενεργοποιημένη από προεπιλογή. Για να διατηρήσετε την προηγούμενη συμπεριφορά, χρησιμοποιήστε helm uninstall --keep-history.

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

• helm inspect -> helm show
• helm fetch -> helm pull

Αυτές οι εντολές έχουν επίσης διατηρήσει τα παλαιότερα ρήματα ως aliases, οπότε μπορείτε να συνεχίσετε να τις χρησιμοποιείτε σε οποιαδήποτε μορφή.

Αυτόματη δημιουργία namespaces

Κατά τη δημιουργία ενός release σε ένα namespace που δεν υπάρχει, το Helm 2 δημιουργούσε το namespace. Το Helm 3 ακολουθεί τη συμπεριφορά άλλων εργαλείων Kubernetes και επιστρέφει σφάλμα αν το namespace δεν υπάρχει. Το Helm 3 θα δημιουργήσει το namespace αν ορίσετε ρητά τη σημαία --create-namespace.

Τι συνέβη με το .Chart.ApiVersion;

Το Helm ακολουθεί τη συνηθισμένη σύμβαση CamelCasing που είναι να γράφονται τα αρκτικόλεξα με κεφαλαία. Το έχουμε κάνει αυτό αλλού στον κώδικα, όπως με το .Capabilities.APIVersions.Has. Στο Helm v3, διορθώσαμε το .Chart.ApiVersion ώστε να ακολουθεί αυτό το μοτίβο, μετονομάζοντάς το σε .Chart.APIVersion.