Προηγμένες Τεχνικές Helm

Αυτή η ενότητα εξηγεί διάφορες προηγμένες δυνατότητες και τεχνικές για τη χρήση του Helm. Οι πληροφορίες σε αυτή την ενότητα προορίζονται για "προχωρημένους χρήστες" του Helm που επιθυμούν να κάνουν προηγμένη προσαρμογή και χειρισμό των charts και releases τους. Κάθε μία από αυτές τις προηγμένες δυνατότητες έρχεται με τους δικούς της συμβιβασμούς και προειδοποιήσεις, επομένως καθεμία πρέπει να χρησιμοποιείται προσεκτικά και με βαθιά γνώση του Helm. Ή με άλλα λόγια, να θυμάστε την αρχή του Peter Parker

Post Rendering

Το Post rendering δίνει στους χρήστες που εγκαθιστούν charts τη δυνατότητα να χειριστούν χειροκίνητα, να ρυθμίσουν ή/και να επαληθεύσουν τα παραγόμενα manifests πριν εγκατασταθούν από το Helm. Έτσι, χρήστες με προηγμένες ανάγκες ρύθμισης μπορούν να χρησιμοποιήσουν εργαλεία όπως το kustomize για να εφαρμόσουν αλλαγές διαμόρφωσης χωρίς να χρειάζεται να κάνουν fork ένα δημόσιο chart ή να απαιτούν από τους συντηρητές του chart να καθορίσουν κάθε δυνατή επιλογή διαμόρφωσης. Υπάρχουν επίσης περιπτώσεις χρήσης για την ένεση κοινών εργαλείων και sidecars σε εταιρικά περιβάλλοντα ή για την ανάλυση των manifests πριν από το deployment.

Προαπαιτούμενα

• Helm 3.1+

Χρήση

Ένας post-renderer μπορεί να είναι οποιοδήποτε εκτελέσιμο αρχείο που δέχεται παραγόμενα Kubernetes manifests στο STDIN και επιστρέφει έγκυρα Kubernetes manifests στο STDOUT. Θα πρέπει να επιστρέφει έναν μη-μηδενικό κωδικό εξόδου σε περίπτωση αποτυχίας. Αυτό είναι το μόνο "API" μεταξύ των δύο στοιχείων. Επιτρέπει μεγάλη ευελιξία σε αυτό που μπορείτε να κάνετε με τη διαδικασία post-render.

Ένας post-renderer μπορεί να χρησιμοποιηθεί με τις εντολές install, upgrade και template. Για να χρησιμοποιήσετε έναν post-renderer, χρησιμοποιήστε την επιλογή --post-renderer με μια διαδρομή προς το εκτελέσιμο renderer που επιθυμείτε να χρησιμοποιήσετε:

$ helm install mychart stable/wordpress --post-renderer ./path/to/executable

Αν η διαδρομή δεν περιέχει διαχωριστικά, θα αναζητήσει στο $PATH, διαφορετικά θα επιλύσει τυχόν σχετικές διαδρομές σε πλήρως προσδιορισμένες διαδρομές.

Αν επιθυμείτε να χρησιμοποιήσετε πολλαπλούς post-renderers, καλέστε τους όλους σε ένα script ή μαζί σε οποιοδήποτε binary εργαλείο έχετε δημιουργήσει. Στο bash, αυτό θα ήταν τόσο απλό όσο renderer1 | renderer2 | renderer3.

Μπορείτε να δείτε ένα παράδειγμα χρήσης του kustomize ως post renderer εδώ.

Προειδοποιήσεις

Όταν χρησιμοποιείτε post renderers, υπάρχουν αρκετά σημαντικά πράγματα που πρέπει να έχετε υπόψη σας. Το πιο σημαντικό από αυτά είναι ότι όταν χρησιμοποιείτε έναν post-renderer, όλα τα άτομα που τροποποιούν αυτό το release ΠΡΕΠΕΙ να χρησιμοποιούν τον ίδιο renderer για να έχουν επαναλήψιμες κατασκευές. Αυτή η δυνατότητα είναι σκόπιμα σχεδιασμένη ώστε να επιτρέπει σε οποιονδήποτε χρήστη να αλλάξει τον renderer που χρησιμοποιεί ή να σταματήσει να χρησιμοποιεί renderer, αλλά αυτό θα πρέπει να γίνεται σκόπιμα για να αποφευχθεί τυχαία τροποποίηση ή απώλεια δεδομένων.

Μια άλλη σημαντική σημείωση αφορά την ασφάλεια. Αν χρησιμοποιείτε έναν post-renderer, θα πρέπει να διασφαλίσετε ότι προέρχεται από αξιόπιστη πηγή (όπως ισχύει για οποιοδήποτε άλλο αυθαίρετο εκτελέσιμο). Η χρήση μη αξιόπιστων ή μη επαληθευμένων renderers ΔΕΝ συνιστάται καθώς έχουν πλήρη πρόσβαση στα παραγόμενα templates, τα οποία συχνά περιέχουν ευαίσθητα δεδομένα.

Προσαρμοσμένοι Post Renderers

Το βήμα post render προσφέρει ακόμη περισσότερη ευελιξία όταν χρησιμοποιείται με το Go SDK. Οποιοσδήποτε post renderer χρειάζεται μόνο να υλοποιήσει το ακόλουθο Go interface:

type PostRenderer interface {
    // Run expects a single buffer filled with Helm rendered manifests. It
    // expects the modified results to be returned on a separate buffer or an
    // error if there was an issue or failure while running the post render step
    Run(renderedManifests *bytes.Buffer) (modifiedManifests *bytes.Buffer, err error)
}

Για περισσότερες πληροφορίες σχετικά με τη χρήση του Go SDK, δείτε την ενότητα Go SDK

Go SDK

Το Helm 3 παρουσίασε ένα πλήρως αναδιαρθρωμένο Go SDK για καλύτερη εμπειρία κατά τη δημιουργία λογισμικού και εργαλείων που αξιοποιούν το Helm. Η πλήρης τεκμηρίωση βρίσκεται στην Ενότητα Go SDK.

Backends αποθήκευσης

Το Helm 3 άλλαξε την προεπιλεγμένη αποθήκευση πληροφοριών release σε Secrets μέσα στο namespace του release. Το Helm 2 εξ ορισμού αποθηκεύει πληροφορίες release ως ConfigMaps στο namespace της instance του Tiller. Οι ακόλουθες υποενότητες δείχνουν πώς να ρυθμίσετε διαφορετικά backends. Αυτή η ρύθμιση βασίζεται στη μεταβλητή περιβάλλοντος HELM_DRIVER. Μπορεί να οριστεί σε μία από τις τιμές: [configmap, secret, sql].

Backend αποθήκευσης ConfigMap

Για να ενεργοποιήσετε το ConfigMap backend, θα πρέπει να ορίσετε τη μεταβλητή περιβάλλοντος HELM_DRIVER σε configmap.

Μπορείτε να το ορίσετε σε ένα shell ως εξής:

export HELM_DRIVER=configmap

Αν θέλετε να αλλάξετε από το προεπιλεγμένο backend στο ConfigMap backend, θα πρέπει να κάνετε τη μετάβαση μόνοι σας. Μπορείτε να ανακτήσετε τις πληροφορίες release με την ακόλουθη εντολή:

kubectl get secret --all-namespaces -l "owner=helm"

ΣΗΜΕΙΩΣΕΙΣ ΠΑΡΑΓΩΓΗΣ: Οι πληροφορίες release περιλαμβάνουν τα περιεχόμενα των charts και των αρχείων values, και επομένως μπορεί να περιέχουν ευαίσθητα δεδομένα (όπως κωδικούς πρόσβασης, ιδιωτικά κλειδιά και άλλα διαπιστευτήρια) που πρέπει να προστατευθούν από μη εξουσιοδοτημένη πρόσβαση. Κατά τη διαχείριση της εξουσιοδότησης Kubernetes, για παράδειγμα με το RBAC, είναι δυνατόν να παραχωρηθεί ευρύτερη πρόσβαση σε πόρους ConfigMap, ενώ περιορίζεται η πρόσβαση σε πόρους Secret. Για παράδειγμα, ο προεπιλεγμένος ρόλος χρήστη "view" παρέχει πρόσβαση στους περισσότερους πόρους, αλλά όχι στα Secrets. Επιπλέον, τα δεδομένα secrets μπορούν να ρυθμιστούν για κρυπτογραφημένη αποθήκευση. Παρακαλούμε να το έχετε αυτό υπόψη σας αν αποφασίσετε να αλλάξετε στο ConfigMap backend, καθώς θα μπορούσε να εκθέσει τα ευαίσθητα δεδομένα της εφαρμογής σας.

Backend αποθήκευσης SQL

Υπάρχει ένα beta SQL backend αποθήκευσης που αποθηκεύει πληροφορίες release σε μια βάση δεδομένων SQL.

Η χρήση ενός τέτοιου backend αποθήκευσης είναι ιδιαίτερα χρήσιμη αν οι πληροφορίες release σας ζυγίζουν περισσότερο από 1MB (σε αυτή την περίπτωση, δεν μπορούν να αποθηκευτούν σε ConfigMaps/Secrets λόγω εσωτερικών ορίων στο υποκείμενο etcd key-value store του Kubernetes).

Για να ενεργοποιήσετε το SQL backend, θα πρέπει να αναπτύξετε μια βάση δεδομένων SQL και να ορίσετε τη μεταβλητή περιβάλλοντος HELM_DRIVER σε sql. Οι λεπτομέρειες της βάσης δεδομένων ορίζονται με τη μεταβλητή περιβάλλοντος HELM_DRIVER_SQL_CONNECTION_STRING.

Μπορείτε να τα ορίσετε σε ένα shell ως εξής:

export HELM_DRIVER=sql
export HELM_DRIVER_SQL_CONNECTION_STRING=postgresql://helm-postgres:5432/helm?user=helm&password=changeme

Σημείωση: Αυτή τη στιγμή υποστηρίζεται μόνο η PostgreSQL.

ΣΗΜΕΙΩΣΕΙΣ ΠΑΡΑΓΩΓΗΣ: Συνιστάται να:

• Κάνετε τη βάση δεδομένων σας έτοιμη για παραγωγή. Για PostgreSQL, ανατρέξτε στην τεκμηρίωση Server Administration για περισσότερες λεπτομέρειες
• Ενεργοποιήσετε τη διαχείριση δικαιωμάτων για να αντικατοπτρίζει το Kubernetes RBAC για τις πληροφορίες release

Αν θέλετε να αλλάξετε από το προεπιλεγμένο backend στο SQL backend, θα πρέπει να κάνετε τη μετάβαση μόνοι σας. Μπορείτε να ανακτήσετε τις πληροφορίες release με την ακόλουθη εντολή:

kubectl get secret --all-namespaces -l "owner=helm"