One place for hosting & domains

      Clusters

      Comment installer un logiciel sur des clusters Kubernetes avec le gestionnaire de packages Helm 3


      Introduction

      Helm est un gestionnaire de package pour Kubernetes qui permet aux développeurs et aux opérateurs de configurer et à déployer des applications plus facilement sur les clusters Kubernetes.

      Dans ce tutoriel, vous allez configurer Helm 3 et l’utiliser pour installer, reconfigurer, revenir en arrière et supprimer une instance de l’application Kubernetes Dashboard. Le dashboard (tableau de bord) est une interface graphique Kubernetes officielle basée sur le web.

      Pour un aperçu conceptuel de Helm et de son écosystème de packaging, veuillez lire notre article, Une introduction à Helm.

      Conditions préalables

      Pour ce tutoriel, vous aurez besoin de :

      • Un cluster Kubernetes avec contrôle d’accès basé sur les rôles (RBAC) activé. Helm 3.1 prend en charge les clusters des versions 1.14 à 1.17. Pour plus d’informations, consultez la page des versions de Helm.
      • L’outil de ligne de commande kubectl installé sur votre machine locale, configuré pour vous connecter à votre cluster. Vous pouvez en savoir plus sur l’installation de kubectl dans la documentation officielle.

      Vous pouvez tester votre connectivité avec la commande suivante :

      Si vous ne voyez aucune erreur, vous êtes connecté au cluster. Si vous avez accès à plusieurs clusters avec kubectl, veillez à vérifier que vous avez choisi le contexte de cluster adéquat :

      • kubectl config get-contexts

      Output

      CURRENT NAME CLUSTER AUTHINFO NAMESPACE * do-fra1-helm3-example do-fra1-helm3-example do-fra1-helm3-example-admin

      Dans cet exemple, l’astérisque (*) indique que nous sommes connectés au cluster do-fra1-helm3-example. Pour changer les clusters exécutez :

      • kubectl config use-context context-name

      Lorsque vous êtes connecté au bon cluster, continuez à l’Étape 1 pour commencer à installer Helm.

      Étape 1 — Installation de Helm

      Tout d’abord, vous allez installer l’utilitaire de ligne de commande helm sur votre machine locale. Helm fournit un script qui gère le processus d’installation sur MacOS, Windows ou Linux.

      Entrez dans un répertoire inscriptible et téléchargez le script depuis le référentiel GitHub de Helm :

      • cd /tmp
      • curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3

      Rendez le script exécutable avec chmod :

      Vous pouvez utiliser votre éditeur de texte préféré pour ouvrir le script et l’inspecter, afin de vous assurer qu’il est sûr. Lorsque vous êtes satisfait, exécutez-le :

      Votre mot de passe peut vous être demandé. Saisissez-le et appuyez sur ENTER pour continuer.

      La sortie finale ressemblera à ceci :

      Output

      Downloading https://get.helm.sh/helm-v3.1.2-linux-amd64.tar.gz Preparing to install helm into /usr/local/bin helm installed into /usr/local/bin/helm

      Maintenant que vous avez installé Helm, vous êtes prêt à utiliser Helm pour installer votre premier tableau.

      Étape 2 — Installation d’un tableau Helm

      Les packages logiciels Helm sont appelés des tableaux. Il existe un référentiel de tableaux conservé, appelé stable, composé principalement de tableaux communs, que vous pouvez voir dans leur référentiel GitHub. Helm n’est pas préconfiguré pour cela, vous devrez donc l’ajouter manuellement. Ensuite, à titre d’exemple, vous allez installer le tableau de bord Kubernetes.

      Ajoutez le référentiel stable en exécutant :

      • helm repo add stable https://kubernetes-charts.storage.googleapis.com

      Le résultat sera :

      Output

      "stable" has been added to your repositories

      Ensuite, utilisez helm pour installer le package kubernetes-dashboard à partir du référentiel stable :

      • helm install dashboard-demo stable/kubernetes-dashboard --set rbac.clusterAdminRole=true

      Le paramètre --set vous permet de personnaliser les variables de tableaux, que le tableau affiche pour vous permettre de personnaliser sa configuration. Ici, vous définissez la variable d’application rbac.clusterAdminRole sur true pour donner l’accès à votre cluster entier au tableau de bord Kubernetes.

      La sortie ressemblera à :

      Output

      NAME: dashboard-demo LAST DEPLOYED: Tue Mar 31 15:04:19 2020 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: ...

      Notez la ligne NAME, surlignée dans l’exemple de sortie ci-dessus. Dans ce cas, vous avez spécifié le nom dashboard-demo. C’est le nom de la version. Une version Helm est un simple déploiement d’un tableau avec une configuration spécifique. Vous pouvez déployer plusieurs versions du même tableau, chacune ayant sa propre configuration.

      Vous pouvez énumérer toutes les versions dans le cluster :

      Le résultat sera similaire à celui-ci :

      Output

      NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION dashboard-demo default 1 2020-03-31 15:04:19.324774799 +0000 UTC deployed kubernetes-dashboard-1.10.1 1.10.1

      Vous pouvez maintenant utiliser kubectl pour vérifier qu’un nouveau service a été déployé sur le cluster :

      La sortie finale ressemblera à ceci :

      Output

      NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE dashboard-demo-kubernetes-dashboard ClusterIP 10.245.115.214 <none> 443/TCP 4m44s kubernetes ClusterIP 10.245.0.1 <none> 443/TCP 19m

      Notez que par défaut, le nom de service correspondant à la version est une combinaison du nom de la version Helm et du nom du tableau.

      Maintenant que vous avez déployé l’application, vous utiliserez Helm pour modifier sa configuration et mettre à jour le déploiement.

      Étape 3 — Mise à jour d’une version

      La commande helm upgrade peut être utilisée pour mettre à niveau une version avec un nouveau tableau ou un tableau mis à jour, ou pour mettre à jour ses options de configuration (variables).

      Vous allez apporter une simple modification à la version dashboard-demo pour démontrer le processus de mise à jour et de démantèlement : vous allez mettre à jour le nom du service du tableau de bord en kubernetes-dashboard, au lieu de dashboard-demo-kubernetes-dashboard.

      Le tableau kubernetes-dashboard fournit une option de configuration fullnameOverride pour contrôler le nom du service. Pour renommer la version, exécutez helm upgrade avec ce jeu d’options :

      • helm upgrade dashboard-demo stable/kubernetes-dashboard --set fullnameOverride="kubernetes-dashboard" --reuse-values

      En passant l’argument --reuse values, vous vous assurez que les variables de tableau que vous avez précédemment définies ne seront pas réinitialisées par le processus de mise à niveau.

      Vous verrez une sortie semblable à l’étape initiale d'installation de helm.

      Vérifiez si vos services Kubernetes reflètent les valeurs mises à jour :

      La sortie ressemblera à ce qui suit :

      Output

      NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.245.0.1 <none> 443/TCP 38m kubernetes-dashboard ClusterIP 10.245.49.157 <none> 443/TCP 8s

      Notez que le nom du service a été mis à jour avec la nouvelle valeur.

      Remarque : à ce stade, vous pouvez charger le tableau de bord Kubernetes dans votre navigateur et le consulter. Pour ce faire, exécutez d’abord la commande suivante :

      Cela crée un proxy qui vous permet d’accéder aux ressources de cluster à distance depuis votre ordinateur local. En fonction des instructions précédentes, votre service de tableau de bord est nommé kubernetes-dashboard et il fonctionne dans le namespace par default. Vous pouvez maintenant accéder au tableau de bord grâce à l’URL suivante :

      http://localhost:8001/api/v1/namespaces/default/services/https:kubernetes-dashboard:https/proxy/
      

      Les instructions pour l’utilisation effective du tableau de bord sont hors sujet pour ce tutoriel, mais vous pouvez consulter les documents officiels du tableau de bord Kubernetes pour plus d’informations.

      Ensuite, vous verrez la capacité de Helm à revenir en arrière et à supprimer les versions.

      Étape 4 — Retour en arrière et suppression d’une version

      Lorsque vous avez mis à jour la version dashboard-demo à l’étape précédente, vous avez créé une deuxième révision de la version. Helm conserve tous les détails des versions précédentes si vous devez revenir sur une configuration ou un tableau précédents.

      Utilisez helm list pour inspecter à nouveau la version :

      Vous verrez la sortie suivante :

      Output

      NAME REVISION UPDATED STATUS CHART NAMESPACE dashboard-demo 2 Wed Aug 8 20:13:15 2018 DEPLOYED kubernetes-dashboard-0.7.1 default

      La colonne REVISION vous indique que c’est maintenant la deuxième révision.

      Utilisez helm rollback pour revenir à la première révision :

      • helm rollback dashboard-demo 1

      Vous devriez voir la sortie suivante, indiquant que le retour en arrière a réussi :

      Output

      Rollback was a success! Happy Helming!

      À ce stade, si vous lancez à nouveau kubectl get services, vous remarquerez que le nom du service est revenu à sa valeur précédente. Helm a re-deployé l’application avec la configuration de révision 1.

      Les versions Helm peuvent être supprimées avec la commande helm delete :

      • helm delete dashboard-demo

      Le résultat sera :

      Output

      release "dashboard-demo" uninstalled

      Vous pouvez essayer de lister les versions de Helm :

      Vous verrez qu’il n’y en a pas :

      Output

      NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION

      Maintenant, la version a été réellement supprimée, et vous pouvez réutiliser le nom de la version.

      Conclusion

      Dans ce tutoriel, vous avez installé l’outil de ligne de commande de helm et étudié l’installation, la mise à niveau, le retour en arrière et la suppression des tableaux de bord et des versions de Helm en gérant le tableau kubernetes-dashboard. 

      Pour plus d’informations sur Helm et les tableaux de Helm, veuillez consulter la documentation officielle de Helm.



      Source link

      Empfohlene Schritte zur Sicherung eines DigitalOcean Kubernetes Clusters


      Der Autor wählte die Kooperation Open Sourcing Mental Illness, um eine Spende im Rahmen des Programms Write for DOnations zu erhalten.

      Einführung

      Kubernetes, die Open-Source-Container-Orchestrierungsplattform, wird immer mehr zur bevorzugten Lösung für die Automatisierung, Skalierung und Verwaltung von Hochverfügbarkeits-Clustern. Aufgrund der zunehmenden Popularität wird die Sicherheit von Kubernetes immer wichtiger.

      In Anbetracht der beweglichen Teile, die in Kubernetes involviert sind, und der Vielfalt der Einsatzszenarien kann die Sicherung von Kubernetes manchmal komplex sein. Ziel dieses Artikels ist es daher, eine solide Sicherheitsbasis für einen DigitalOcean Kubernetes (DOKS) Cluster bereitzustellen. Beachten Sie, dass dieses Tutorial grundlegende Sicherheitsmaßnahmen für Kubernetes behandelt und eher als Startpunkt und nicht als erschöpfender Leitfaden gedacht ist. Zusätzliche Schritte finden Sie in der offiziellen Kubernetes-Dokumentation.

      In diesem Tutorial nehmen Sie grundlegende Schritte zur Sicherung Ihres DigitalOcean Kubernetes Clusters vor. Sie konfigurieren eine sichere lokale Authentifizierung mit TLS/SSL-Zertifikaten, vergeben Berechtigungen an lokale Benutzer mit rollenbasierten Zugriffskontrollen (RBAC) sowie an Kubernetes-Anwendungen und -Bereitstellungen mit Service Accounts, und richten Ressourcenbegrenzungen mit den Zugriffs-Controllern ResourceQuota und LimitRange ein.

      Voraussetzungen

      Um dieses Tutorial auszuführen, benötigen Sie Folgendes:

      • Einen von DigitalOcean Kubernetes (DOKS) verwalteten Cluster mit 3 Standardknoten, die jeweils mit mindestens 2 GB RAM und 1 vCPU konfiguriert sind. Eine detaillierte Anleitung für die Erstellung eines DOKS-Clusters finden Sie in unserem Leitfaden Kubernetes Quickstart. Dieses Tutorial verwendet die DOKS-Version 1.16.2-do.1.
      • Einen für die Verwaltung des DOKS-Clusters konfigurierten lokalen Client, mit einer vom DigitalOcean Control Panel heruntergeladenen Cluster-Konfigurationsdatei, gespeichert unter ~/.kube/config. Eine detaillierte Anleitung für die Konfiguration eines auf Remote-Ebene verwalteten DOKS finden Sie im Leitfaden Verbinden mit einem DigitalOcean Kubernetes Cluster. Im Einzelnen benötigen Sie Folgendes:
        • Die auf Ihrem lokalen Rechner installierte Befehlszeilenschnittstelle kubectl. Mehr über die Installation und Konfiguration von kubectl können Sie der offiziellen Dokumentation entnehmen. Dieses Tutorial verwendet die kubectl-Version 1.17.0-00.
        • Das offizielle DigitalOcean-Befehlszeilen-Tool doctl. Anweisungen für die Installation finden Sie auf der Seite doctl GitHub Page. Dieses Tutorial verwendet die Version doctl 1.36.0.

      Schritt 1 – Aktivieren der Remotebenutzer-Authentifizierung

      Nach der Erfüllung der Voraussetzungen erhalten Sie einen Kubernetes-Superuser, der sich über ein vordefiniertes DigitalOcean-Träger-Token authentifiziert. Die gemeinschaftliche Nutzung dieses Berechtigungsnachweises ist jedoch keine gute Sicherheitspraxis, da dieses Konto umfangreiche und möglicherweise destruktive Änderungen an Ihrem Cluster verursachen kann. Um diese Möglichkeit einzugrenzen, können Sie zusätzliche Benutzer einrichten, die von ihren jeweiligen lokalen Clients authentifiziert werden.

      In diesem Abschnitt authentifizieren Sie neue Benutzer beim DOKS-Remote-Cluster von lokalen Clients aus mit sicheren SSL/TLS-Zertifikaten. Dies ist ein dreistufiger Prozess: Zuerst generieren Sie für jeden Benutzer eine Zertifikatsignierungsanforderung, die Certificate Signing Requests (CSR)​​. Danach genehmigen Sie diese Zertifikate direkt im Cluster über kubectl. Abschließend erstellen Sie für jeden Benutzer eine kubeconfig-Datei mit den entsprechenden Zertifikaten. Weitere Informationen über zusätzliche von Kubernetes unterstützte Authentifizierungsverfahren finden Sie in der Kubernetes-Authentifizierungsdokumentation.

      Erstellen von Zertifikatsignierungsanforderungen für neue Benutzer

      Prüfen Sie vor dem Start die DOKS-Clusterverbindung von dem lokalen Rechner aus, der bei den Voraussetzungen konfiguriert wurde:

      Je nach Ihrer Konfiguration sehen Sie ein ähnliches Output:

      Output

      Kubernetes master is running at https://a6616782-5b7f-4381-9c0f-91d6004217c7.k8s.ondigitalocean.com CoreDNS is running at https://a6616782-5b7f-4381-9c0f-91d6004217c7.k8s.ondigitalocean.com/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

      Das bedeutet, dass Sie mit dem DOKS-Cluster verbunden sind.

      Erstellen Sie als Nächstes einen lokalen Ordner für die Client-Zertifikate. In diesem Tutorial nutzen Sie zur Speicherung aller Zertifikate ~/certs.

      Sie autorisieren in diesem Tutorial einen neuen Benutzer namens sammy, um auf den Cluster zuzugreifen. Sie können dies auch auf einen Benutzer Ihrer Wahl ändern. Generieren Sie mit der SSL- und TLS-Bibliothek OpenSSL einen neuen privaten Schlüssel für Ihren Benutzer mit dem folgenden Befehl:

      • openssl genrsa -out ~/certs/sammy.key 4096

      Das -out-Flag erzeugt die Output-Datei ~/certs/sammy.key, und 4096 setzt den Schlüssel als 4096-Bit. Weitere Informationen über OpenSSL finden Sie in unserem Leitfaden OpenSSL Essentials.

      Erstellen Sie nun eine Konfigurationsdatei zur Zertifikatsignierungsanforderung. Öffnen Sie die folgende Datei mit einem Texteditor (für dieses Tutorial verwenden wir nano):

      • nano ~/certs/sammy.csr.cnf

      Fügen Sie folgenden Inhalt in die Datei sammy.csr.cnf ein, um im Subjekt den gewünschten Benutzernamen als “common name” (CN) und die Gruppe als “organization”(O) festzulegen:

      ~/certs/sammy.csr.cnf

      [ req ]
      default_bits = 2048
      prompt = no
      default_md = sha256
      distinguished_name = dn
      [ dn ]
      CN = sammy
      O = developers
      [ v3_ext ]
      authorityKeyIdentifier=keyid,issuer:always
      basicConstraints=CA:FALSE
      keyUsage=keyEncipherment,dataEncipherment
      extendedKeyUsage=serverAuth,clientAuth
      

      Die Konfigurationsdatei für die Zertifikatsignierungsanforderung enthält alle erforderlichen Informationen, die Benutzeridentität und entsprechende Verwendungsparameter für den Benutzer. Das letzte Argument extendedKeyUsage=serverAuth,clientAuth ermöglicht Benutzern die Authentifizierung ihrer lokalen Clients mit dem DOKS-Cluster mittels des Zertifikats, sobald es unterzeichnet wurde.

      Erstellen Sie als Nächstes die Zertifikatsignierungsanforderung (CSR) für sammy:

      • openssl req -config ~/certs/sammy.csr.cnf -new -key ~/certs/sammy.key -nodes -out ~/certs/sammy.csr

      Mit -config können Sie die Konfigurationsdatei für die CSR festlegen, und -new signalisiert die Erstellung einer neuen CSR für den durch -key festgelegten Schlüssel.

      Sie können Ihre Zertifikatsignierungsanforderung überprüfen, indem Sie folgenden Befehl ausführen:

      • openssl req -in ~/certs/sammy.csr -noout -text

      Hier geben Sie die CSR mit -in an und verwenden -text, um die Zertifikatsanforderung in Text auszudrucken.

      Das Output zeigt die Zertifikatsanforderung, deren Anfang folgendermaßen aussieht:

      Output

      Certificate Request: Data: Version: 1 (0x0) Subject: CN = sammy, O = developers Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public-Key: (4096 bit) ...

      Wiederholen Sie den gleichen Vorgang, um CSRs für alle weiteren Benutzer zu erstellen. Wenn Sie alle Zertifikatsignierungsanforderungen in dem Ordner ~/certs des Administrators gespeichert haben, fahren Sie mit dem nächsten Schritt fort, um sie zu genehmigen.

      Verwalten von Zertifikatsignierungsanforderungen mit der Kubernetes-API

      Sie können die TLS-Zertifikate, die für die Kubernetes-API ausgegeben wurden, mit dem Befehlszeilen-Tool kubectl entweder genehmigen oder ablehnen. So können Sie sicherstellen, dass der angeforderte Zugang für den jeweiligen Benutzer geeignet ist. In diesem Abschnitt senden Sie die Zertifikatsanforderung für sammy und genehmigen sie.

      Zum Senden einer CSR an den DOKS-Cluster verwenden Sie den folgenden Befehl:

      cat <<EOF | kubectl apply -f -
      apiVersion: certificates.k8s.io/v1beta1
      kind: CertificateSigningRequest
      metadata:
        name: sammy-authentication
      spec:
        groups:
        - system:authenticated
        request: $(cat ~/certs/sammy.csr | base64 | tr -d 'n')
        usages:
        - digital signature
        - key encipherment
        - server auth
        - client auth
      EOF
      

      Dieser Befehl mit einem Bash-Heredoc nutzt cat, um die Zertifikatsanforderung an kubectl apply weiterzuleiten.

      Sehen Sie sich die Zertifikatsanforderung genauer an:

      • name: sammy-authentication erstellt einen Metadaten-Identifizierer, hier sammy-authentication genannt.
      • request: $(cat ~/certs/sammy.csr | Basis64 | tr -d 'n') sendet die Zertifikatsignierungsanforderung sammy.csr als Base64 kodiert an den Cluster.
      • server auth und client auth geben die beabsichtigte Verwendung des Zertifikats an. In diesem Fall ist der Zweck die Benutzerauthentifizierung.

      Das Output sieht ungefähr wie folgt aus:

      Output

      certificatesigningrequest.certificates.k8s.io/sammy-authentication created

      Sie können den Status der Zertifikatsignierungsanforderung mit diesem Befehl prüfen:

      Je nach Ihrer Cluster-Konfiguration sehen Sie ein ähnliches Output:

      Output

      NAME AGE REQUESTOR CONDITION sammy-authentication 37s your_DO_email Pending

      Als Nächstes genehmigen Sie die CSR durch Verwendung des Befehls:

      • kubectl certificate approve sammy-authentication

      Sie erhalten eine Nachricht, die die Operation bestätigt:

      Output

      certificatesigningrequest.certificates.k8s.io/sammy-authentication approved

      Anmerkung: Als Administrator können Sie eine CSR auch mit dem Befehl kubectl certificate deny sammy-authentication ablehnen. Weitere Informationen über die Verwaltung von TLS-Zertifikaten finden Sie in der offiziellen Dokumentation von Kubernetes.

      Nachdem die CSR nun genehmigt wurde, können Sie sie auf den lokalen Rechner herunterladen, indem Sie Folgendes ausführen:

      • kubectl get csr sammy-authentication -o jsonpath='{.status.certificate}' | base64 --decode > ~/certs/sammy.crt

      Dieser Befehl dekodiert das Base64-Zertifikat für eine richtige Anwendung durch kubectl und speichert es dann als ~/certs/sammy.crt.

      Mit dem signierten sammy-Zertifikat können Sie nun die kubeconfig-Datei des Benutzers erstellen.

      Erstellen der Remotebenutzer-Kubeconfig

      Als Nächstes erstellen Sie eine spezifische kubeconfig-Datei für den sammy-Benutzer. Dadurch erhalten Sie mehr Kontrolle über den Zugriff des Benutzers auf Ihren Cluster.

      Der erste Schritt beim Erstellen einer neuen kubeconfig ist die Erstellung einer Kopie der aktuellen kubeconfig-Datei. In diesem Tutorial benennen Sie die neue kubeconfig-Datei config-sammy:

      • cp ~/.kube/config ~/.kube/config-sammy

      Als Nächstes editieren Sie die neue Datei:

      • nano ~/.kube/config-sammy

      Behalten Sie die ersten acht Zeilen dieser Datei, da sie die erforderlichen Informationen für die SSL/TLS-Verbindung mit dem Cluster enthalten. Ersetzen Sie dann ausgehend vom Benutzerparameter den Text durch die folgenden hervorgehobenen Zeilen, damit die Datei ähnlich wie Folgendes aussieht:

      config-sammy

      apiVersion: v1
      clusters:
      - cluster:
          certificate-authority-data: certificate_data
        name: do-nyc1-do-cluster
      contexts:
      - context:
          cluster: do-nyc1-do-cluster
          user: sammy
        name: do-nyc1-do-cluster
      current-context: do-nyc1-do-cluster
      kind: Config
      preferences: {}
      users:
      - name: sammy
        user:
          client-certificate: /home/your_local_user/certs/sammy.crt
          client-key: /home/your_local_user/certs/sammy.key
      

      Anmerkung: Sowohl für client-certificate als auch für client-key verwenden Sie den absoluten Pfad zu deren entsprechenden Zertifikatsstandorten. Andernfalls erzeugt kubectl einen Fehler.

      Speichern und schließen Sie die Datei.

      Sie können die neue Benutzerverbindung mit kubectl cluster-info testen:

      • kubectl --kubeconfig=/home/your_local_user/.kube/config-sammy cluster-info

      Sie erhalten einen ähnlichen Fehler:

      Output

      To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'. Error from server (Forbidden): services is forbidden: User "sammy" cannot list resource "services" in API group "" in the namespace "kube-system"

      Dieser Fehler wird erwartet, weil der Benutzer sammy noch keine Berechtigung hat, eine Ressource auf dem Cluster zu listen. Die Erteilung von Berechtigungen an Benutzer wird im nächsten Schritt gezeigt. Das jetzige Output bestätigt, dass die SSL/TLS-Verbindung erfolgreich war und die Authentifizierungsangaben von sammy von der Kubernetes-API akzeptiert wurden.

      Schritt 2 – Autorisieren von Benutzern über die Rollenbasierte Zugriffskontrolle (RBAC)

      Nach der Authentifizierung eines Benutzers bestimmt die API seine Berechtigungen mit dem in Kubernetes integrierten Modell der Role Based Access Control (RBAC), der rollenbasierten Zugriffskontrolle. RBAC ist eine wirksame Methode zur Beschränkung von Benutzerrechten auf der Grundlage der jeweils zugewiesenen Rolle. Aus sicherheitstechnischer Sicht erlaubt RBAC das Festlegen genau definierter Berechtigungen und limitiert damit die Möglichkeiten von Benutzern, auf vertrauliche Daten zuzugreifen oder Befehle auf Superuser-Ebene auszuführen. Weitere detaillierte Informationen über Benutzerrollen finden Sie in der Kubernetes-RBAC-Dokumentation.

      In diesem Schritt verwenden Sie kubectl, um die vordefinierte Rolle edit dem Benutzer sammy im default-Namensraum zuzuweisen. In einer Produktivumgebung können Sie auch benutzerdefinierte Rollen und/oder benutzerdefinierte Rollenbindungen verwenden.

      Berechtigungen erteilen

      In Kubernetes bedeutet die Erteilung von Berechtigungen, einem Benutzer die gewünschte Rolle zuzuweisen. Erteilen Sie edit-Berechtigungen an den Benutzer sammy im default-Namensraum mit diesem Befehl:

      • kubectl create rolebinding sammy-edit-role --clusterrole=edit --user=sammy --namespace=default

      Sie erhalten ein Output, das dem Folgenden ähnelt:

      Output

      rolebinding.rbac.authorization.k8s.io/sammy-edit-role created

      Im Einzelnen setzt sich der Befehl wie folgt zusammen:

      • create rolebinding sammy-edit-role erstellt eine neue Rollenbindung, in diesem Fall namens sammy-edit-role.
      • --clusterrole=edit wendet die vordefinierte Rolle edit auf einen globalen Gültigkeitsbereich (Cluster-Rolle) an.
      • --user=sammy gibt an, an welchen Benutzer die Rolle gebunden wird.
      • --namespace=default erteilt die Rollenberechtigung des Benutzers im angegebenen Namensraum, in diesem Fall default.

      Als Nächstes verifizieren Sie die Benutzerberechtigung, indem Sie Pods in dem default-Namensraum auflisten. Sie können erkennen, ob die RBAC-Autorisierung wie erwartet funktioniert, wenn keine Fehler angezeigt werden.

      • kubectl --kubeconfig=/home/your_local_user/.kube/config-sammy auth can-i get pods

      Sie erhalten folgendes Output:

      Output

      yes

      Sie haben sammy nun Berechtigungen zugewiesen. Im nächsten Abschnitt sehen Sie, wie Sie diese Berechtigungen wieder entziehen.

      Berechtigungen entziehen

      In Kubernetes entziehen Sie Berechtigungen, indem Sie die Rollenbindung des Benutzers entfernen.

      In diesem Tutorial löschen Sie die edit-Rolle des Benutzers sammy, indem Sie folgenden Befehl ausführen:

      • kubectl delete rolebinding sammy-edit-role

      Sie erhalten folgendes Output:

      Output

      rolebinding.rbac.authorization.k8s.io "sammy-edit-role" deleted

      Überprüfen Sie, ob die Berechtigungen wie erwartet entzogen wurden, indem Sie Pods im default-Namensraum auflisten:

      • kubectl --kubeconfig=/home/localuser/.kube/config-sammy --namespace=default get pods

      Sie erhalten die folgende Fehlermeldung:

      Output

      Error from server (Forbidden): pods is forbidden: User "sammy" cannot list resource "pods" in API group "" in the namespace "default"

      Diese zeigt, dass die Autorisierung entzogen wurde.

      Aus sicherheitstechnischer Sicht gibt das Kubernetes-Autorisierungsmodell Cluster-Administratoren die Flexibilität, die Benutzerrechte bei Bedarf zu ändern. Außerdem ist die rollenbasierte Zugriffskontrolle nicht auf einen physischen Benutzer beschränkt; Sie können auch Cluster-Diensten Berechtigungen erteilen und entziehen. Mehr dazu erfahren Sie im nächsten Abschnitt.

      Weitere Informationen über die RBAC-Autorisierung und wie Sie benutzerdefinierte Rollen erstellen, finden Sie in der offiziellen Dokumentation.

      Schritt 3 – Verwalten von Anwendungsberechtigungen mit Service Accounts

      Wie im vorherigen Abschnitt erwähnt, erstrecken sich die RBAC-Autorisierungsmechanismen nicht nur auf menschliche Benutzer. Nicht-menschliche Cluster-Benutzer wie Anwendungen, Dienste und Prozesse, die in Pods ausgeführt werden, authentifizieren sich mit dem API-Server über Dienstkonten, die in Kubernetes Service Accounts (SAs) genannt werden. Wenn ein Pod in einem Namensraum erstellt wird, können Sie hierfür entweder das default-Service-Account verwenden oder ein Service Account Ihrer Wahl definieren. Die Möglichkeit, Anwendungen und Prozessen individuelle SAs zuzuordnen, gibt Administratoren die Freiheit, Berechtigungen nach Bedarf zu erteilen oder zu entziehen. Außerdem wird die Zuordnung bestimmter SAs zu produktionskritischen Anwendungen als beste Sicherheitspraxis angesehen. Da Service Accounts für die Authentifizierung und damit für die RBAC-Autorisierungsprüfungen verwendet werden, können Cluster-Administratoren Sicherheitsbedrohungen eindämmen, indem sie die Zugriffsrechte für Service Accounts ändern und den fehlerhaften Prozess isolieren.

      Zur Veranschaulichung von Service Accounts verwendet dieses Tutorial einen Nginx-Webserver als Beispielanwendung.

      Bevor Sie Ihrer Anwendung ein bestimmtes SA zuweisen, müssen Sie dieses SA erstellen. Erstellen Sie ein neues Service Account namens nginx-sa im default-Namensraum:

      • kubectl create sa nginx-sa

      Sie erhalten Folgendes:

      Output

      serviceaccount/nginx-sa created

      Überprüfen Sie, ob das Service Account erstellt wurde, indem Sie Folgendes ausführen:

      Dadurch erhalten Sie eine Liste Ihrer Service Accounts:

      Output

      NAME SECRETS AGE default 1 22h nginx-sa 1 80s

      Nun erteilen Sie dem Service Account nginx-sa eine Rolle. In diesem Beispiel erteilen Sie nginx-sa dieselben Berechtigungen wie dem Benutzer sammy:

      • kubectl create rolebinding nginx-sa-edit
      • --clusterrole=edit
      • --serviceaccount=default:nginx-sa
      • --namespace=default

      Nach der Ausführung erhalten Sie Folgendes:

      Output

      rolebinding.rbac.authorization.k8s.io/nginx-sa-edit created

      Dieser Befehl verwendet das gleiche Format wie für den Benutzer sammy. Ausgenommen hierbei ist das Flag --serviceaccount=default:nginx-sa, wo Sie das Service Account nginx-sa dem default-Namensraum zuweisen.

      Überprüfen Sie mit diesem Befehl, ob die Rollenbindung erfolgreich war:

      Dadurch erhalten Sie folgendes Output:

      Output

      NAME AGE nginx-sa-edit 23s

      Nachdem Sie bestätigt haben, dass die Rollenbindung für das Service Account erfolgreich konfiguriert wurde, können Sie das Service Account einer Anwendung zuweisen. Wenn Sie einer Anwendung ein bestimmtes Service Account zuweisen, können Sie dessen Zugriffsrechte in Echtzeit verwalten und somit die Sicherheit des Clusters erhöhen.

      In diesem Tutorial dient ein nginx-Pod als Beispielanwendung. Erstellen Sie den neuen Pod und bestimmen Sie das Service Account nginx-sa mit dem folgenden Befehl:

      • kubectl run nginx --image=nginx --port 80 --serviceaccount="nginx-sa"

      Der erste Teil des Befehls erstellt einen neuen Pod, der einen nginx-Webserver auf Port :80 ausführt. Der zweite Teil --serviceaccount="nginx-sa" zeigt an, dass dieser Pod das nginx-sa-Service-Account und nicht das default-Service-Account verwenden soll.

      Sie erhalten ein Output, das dem Folgenden ähnelt:

      Output

      deployment.apps/nginx created

      Überprüfen Sie mit kubectl describe, ob die neue Anwendung das Service Account verwendet:

      • kubectl describe deployment nginx

      Dadurch erhalten Sie eine längere Beschreibung der Bereitstellungsparameter. Unter dem Abschnitt Pod Template sehen Sie ein Output, das diesem ähnelt:

      Output

      ... Pod Template: Labels: run=nginx Service Account: nginx-sa ...

      In diesem Abschnitt haben Sie das Service Account nginx-sa im default-Namensraum erstellt und dem nginx-Webserver zugewiesen. Sie können nun die nginx-Berechtigungen in Echtzeit steuern, indem Sie seine Rolle nach Bedarf ändern. Sie können Anwendungen auch gruppieren, indem Sie jeder dasselbe Service Account zuweisen und dann Mehrfachänderungen (bulk changes) an Berechtigungen vornehmen. Sie können zudem kritische Anwendungen isolieren, indem Sie diesen ein individuelles SA zuweisen.

      Die Idee hinter der Zuweisung von Rollen an Ihre Anwendungen/Bereitstellungen besteht auch darin, eine Feinabstimmung der Berechtigungen vornehmen zu können. In realen Produktivumgebungen haben Sie möglicherweise mehrere Bereitstellungen, die unterschiedliche Berechtigungen erfordern, die von reinen Leseberechtigungen bis hin zu vollen Administratorrechten reichen. Mit RBAC können Sie den Zugriff auf den Cluster flexibel nach Bedarf einschränken.

      Als Nächstes richten Sie Zugangs-Controller ein, um Ressourcen zu kontrollieren und gegen übermäßigen Ressourcenverbrauch zu schützen.

      Schritt 4 – Einrichten von Zugriffs-Controllern

      Die Zugriffs-Controller von Kubernetes sind optionale Plugins, die in das kube-apiserver-Binärprogramm kompiliert werden, um die Sicherheitsoptionen zu erweitern. Zugriffs-Controller fangen Anfragen ab, nachdem diese die Authentifizierungs- und Autorisierungsphase durchlaufen haben. Nach dem Abfangen der Anfrage führen die Zugriffs-Controller den jeweils festgelegten Code aus, bevor die Anfrage ausgeführt wird.

      Während das Ergebnis einer Authentifizierungs- oder Autorisierungsprüfung ein boolescher Wahr-oder-Falsch-Wert ist, der die Anfrage entweder erlaubt oder ablehnt, können Zugriffs-Controller wesentlich vielfältiger agieren. Zugriffs-Controller können Anfragen in gleicher Weise wie eine Authentifizierung validieren. Sie können jedoch auch zusätzlich Anfragen mutieren und ändern sowie Objekte modifizieren, bevor diese zugelassen werden.

      In diesem Schritt verwenden Sie die Zugriffs-Controller ResourceQuota und LimitRange. Diese schützen Ihren Cluster, indem Sie Anfragen, die zu einem übermäßigen Ressourcenverbrauch oder einem Denial-of-Service-Angriff führen können, mutieren. Der Zugriffs-Controller ResourceQuota ermöglicht Administratoren, die Rechnerressourcen, die Speicherressourcen und die Quantität jedes Objekts in einem Namensraum zu beschränken. Der Zugriffs-Controller LimitRange beschränkt die Anzahl der von Containern verwendeten Ressourcen. Die gleichzeitige Verwendung dieser beiden Zugriffs-Controller schützt Ihren Cluster vor Angriffen, durch die Ihre Ressourcen nicht mehr verfügbar wären.

      Um zu zeigen, wie ResourceQuota funktioniert, implementieren Sie nun einige Beschränkungen im default-Namensraum. Beginnen Sie mit dem Erstellen einer neuen ResourceQuota-Objektdatei:

      • nano resource-quota-default.yaml

      Fügen Sie die folgende Objektdefinition hinzu, um Beschränkungen für den Ressourcenverbrauch im default-Namensraum festzulegen. Sie können die Werte entsprechend der physischen Ressourcen Ihrer Knoten nach Bedarf anpassen:

      resource-quota-default.yaml

      apiVersion: v1
      kind: ResourceQuota
      metadata:
        name: resource-quota-default
      spec:
        hard:
          pods: "2"
          requests.cpu: "500m"
          requests.memory: 1Gi
          limits.cpu: "1000m"
          limits.memory: 2Gi
          configmaps: "5"
          persistentvolumeclaims: "2"
          replicationcontrollers: "10"
          secrets: "3"
          services: "4"
          services.loadbalancers: "2"
      

      Diese Definition verwendet das Schlüsselwort hard, um harte Beschränkungen wie z. B. die maximale Anzahl von pods, configmaps, PersistentVolumeClaims, ReplicationControllers, secrets, services und loadbalancers festzulegen. Sie setzt auch Beschränkungen für Rechnerressourcen wie:

      • requests.cpu, das den maximalen CPU-Wert von Anfragen in milliCPU oder einem Tausendstel eines CPU-Kerns festlegt.
      • requests.memory, das den maximalen Speicherwert von Anfragen in Bytes festlegt.
      • limits.cpu, das den maximalen CPU-Wert von Limits in milliCPUs festlegt.
      • limits.memory, das den maximalen Speicherwert von Limits in Bytes festlegt.

      Speichern und schließen Sie die Datei.

      Erstellen Sie nun mit dem folgenden Befehl das Objekt im Namensraum:

      • kubectl create -f resource-quota-default.yaml --namespace=default

      Dadurch erhalten Sie:

      Output

      resourcequota/resource-quota-default created

      Beachten Sie, dass Sie das Flag -f verwenden, um Kubernetes den Speicherort der ResourceQuota-Datei anzuzeigen, sowie das Flag --namespace, um anzugeben, welcher Namensraum aktualisiert wird.

      Nach dem Erstellen des Objekts ist Ihr ResourceQuota aktiv. Sie können die default-Namensraumquoten mit describe quota prüfen:

      • kubectl describe quota --namespace=default

      Das Output sieht dem Folgenden ähnlich; mit den harten Limits, die Sie in der Datei resource-quota-default.yaml festgelegt haben:

      Output

      Name: resource-quota-default Namespace: default Resource Used Hard -------- ---- ---- configmaps 0 5 limits.cpu 0 1 limits.memory 0 2Gi persistentvolumeclaims 0 2 pods 1 2 replicationcontrollers 0 10 requests.cpu 0 500m requests.memory 0 1Gi secrets 2 3 services 1 4 services.loadbalancers 0 2

      ResourceQuotas werden in absoluten Einheiten ausgedrückt. Daher erhöht das Hinzufügen zusätzlicher Knoten nicht automatisch die hier definierten Werte. Wenn weitere Knoten hinzugefügt werden, müssen Sie die Werte hier manuell bearbeiten, um die Ressourcen zu proportionieren. ResourceQuotas können so oft wie nötig modifiziert werden. Sie können jedoch nicht entfernt werden, es sei denn, der gesamte Namensraum wird entfernt.

      Wenn Sie einen bestimmten ResourceQuota-Controller ändern möchten, aktualisieren Sie die entsprechende .yaml-Datei und wenden Sie die Änderungen mit dem folgenden Befehl an:

      • kubectl apply -f resource-quota-default.yaml --namespace=default

      Weitere Informationen über den Zugriffs-Controller ResourceQuota finden Sie in der offiziellen Dokumentation.

      Nachdem Ihr ResourceQuota nun eingerichtet ist, fahren Sie mit der Konfiguration des Zugriffs-Controllers LimitRange fort. Ähnlich wie der Controller ResourceQuota Limits für Namensräume umsetzt, setzt der Controller LimitRange die durch Validierung und Mutation von Containern deklarierten Beschränkungen durch.

      Wie zuvor beginnen Sie mit dem Erstellen der Objektdatei:

      • nano limit-range-default.yaml

      Nun können Sie mit dem LimitRange-Objekt den Ressourcenverbrauch nach Bedarf beschränken. Fügen Sie folgenden Inhalt als Beispiel eines typischen Anwendungsfalls hinzu:

      limit-ranges-default.yaml

      apiVersion: v1
      kind: LimitRange
      metadata:
        name: limit-range-default
      spec:
        limits:
        - max:
            cpu: "400m"
            memory: "1Gi"
          min:
            cpu: "100m"
            memory: "100Mi"
          default:
            cpu: "250m"
            memory: "800Mi"
          defaultRequest:
            cpu: "150m"
            memory: "256Mi"
          type: Container
      

      Die in limit-ranges-default.yaml verwendeten Beispielwerte beschränken den Containerspeicher auf ein Maximum von 1Gi und die CPU-Nutzung auf ein Maximum von 400 m, was einer Kubernetes-Metrik von 400 milliCPU entspricht und bedeutet, dass der Container auf nahezu die Hälfte seines Kerns beschränkt ist.

      Als Nächstes stellen Sie das Objekt mit dem folgenden Befehl für den API-Server bereit:

      • kubectl create -f limit-range-default.yaml --namespace=default

      Dadurch erhalten Sie folgendes Output:

      Output

      limitrange/limit-range-default created

      Nun können Sie die neuen Limits mit dem folgenden Befehl überprüfen:

      • kubectl describe limits --namespace=default

      Das Output sieht ungefähr wie folgt aus:

      Output

      Name: limit-range-default Namespace: default Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio ---- -------- --- --- --------------- ------------- ----------------------- Container cpu 100m 400m 150m 250m - Container memory 100Mi 1Gi 256Mi 800Mi -

      Um den LimitRanger arbeiten zu sehen, stellen Sie einen Standard-nginx-Container mit dem folgenden Befehl bereit:

      • kubectl run nginx --image=nginx --port=80 --restart=Never

      Dadurch erhalten Sie folgendes Output:

      Output

      pod/nginx created

      Überprüfen Sie, wie der Zugriffs-Controller den Container mutiert hat, indem Sie folgenden Befehl ausführen:

      • kubectl get pod nginx -o yaml

      Dadurch erhalten Sie viele Zeilen an Output. Im Abschnitt der Container-Spezifizierung finden Sie die im LimitRange angegebenen Ressourcenlimits:

      Output

      ... spec: containers: - image: nginx imagePullPolicy: IfNotPresent name: nginx ports: - containerPort: 80 protocol: TCP resources: limits: cpu: 250m memory: 800Mi requests: cpu: 150m memory: 256Mi ...

      Dies wäre genauso, wenn Sie die Angaben für resources und requests manuell in der Container-Spezifikation festlegen würden.

      In diesem Schritt haben Sie die Zugriffs-Controller ResourceQuota und LimitRange verwendet, um die Ressourcen Ihres Clusters vor schädlichen Angriffen zu schützen. Weitere Informationen über den Zugriffs-Controller LimitRange finden Sie in der offiziellen Dokumentation.

      Zusammenfassung

      In diesem Tutorial haben Sie eine grundlegende Kubernetes-Sicherheitsvorlage konfiguriert. Dadurch wurden die Benutzerauthentifizierung und -autorisierung, die Anwendungsberechtigungen und der Schutz der Cluster-Ressourcen bestimmt. Wenn Sie alle in diesem Tutorial behandelten Vorschläge kombinieren, haben Sie eine solide Grundlage für den Einsatz eines Kubernetes-Clusters in einer produktiven Umgebung. Nun können Sie beginnen, individuelle Aspekte Ihres Clusters je nach Ihrer Vorstellung zu härten.

      Wenn Sie mehr über Kubernetes erfahren möchten, besuchen Sie unsere Kubernetes-Ressourcenseite oder folgen Sie dem selbstgeführten Kurs Kubernetes für umfassende Entwickler.



      Source link

      How To Install Software on Kubernetes Clusters with the Helm 3 Package Manager


      Introduction

      Helm is a package manager for Kubernetes that allows developers and operators to more easily configure and deploy applications on Kubernetes clusters.

      In this tutorial, you will set up Helm 3 and use it to install, reconfigure, rollback, and delete an instance of the Kubernetes Dashboard application. The dashboard is an official web-based Kubernetes GUI.

      For a conceptual overview of Helm and its packaging ecosystem, please read our article, An Introduction to Helm.

      Prerequisites

      For this tutorial you will need:

      • A Kubernetes cluster with role-based access control (RBAC) enabled. Helm 3.1 supports clusters from versions 1.14 to 1.17. For further information check the Helm releases page.
      • The kubectl command-line tool installed on your local machine, configured to connect to your cluster. You can read more about installing kubectl in the official documentation.

        You can test your connectivity with the following command:

        If you see no errors, you’re connected to the cluster. If you access multiple clusters with kubectl, be sure to verify that you’ve selected the correct cluster context:

        • kubectl config get-contexts

        Output

        CURRENT NAME CLUSTER AUTHINFO NAMESPACE * do-fra1-helm3-example do-fra1-helm3-example do-fra1-helm3-example-admin

        In this example the asterisk (*) indicates that we are connected to the do-fra1-helm3-example cluster. To switch clusters run:

        • kubectl config use-context context-name

      When you are connected to the correct cluster, continue to Step 1 to begin installing Helm.

      Step 1 — Installing Helm

      First, you’ll install the helm command-line utility on your local machine. Helm provides a script that handles the installation process on MacOS, Windows, or Linux.

      Change to a writable directory and download the script from Helm’s GitHub repository:

      • cd /tmp
      • curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3

      Make the script executable with chmod:

      You can use your favorite text editor to open the script and inspect it to make sure it’s safe. When you are satisfied, run it:

      You may be prompted for your password. Provide it and press ENTER to continue.

      The output will look like this:

      Output

      Downloading https://get.helm.sh/helm-v3.1.2-linux-amd64.tar.gz Preparing to install helm into /usr/local/bin helm installed into /usr/local/bin/helm

      Now that you’ve got Helm installed, you’re ready to use Helm to install your first chart.

      Step 2 — Installing a Helm Chart

      Helm software packages are called charts. There is a curated chart repository called stable, mostly consisting of common charts, which you can see in their GitHub repo. Helm does not come preconfigured for it, so you’ll need to manually add it. Then, as an example, you are going to install the Kubernetes Dashboard.

      Add the stable repo by running:

      • helm repo add stable https://kubernetes-charts.storage.googleapis.com

      The output will be:

      Output

      "stable" has been added to your repositories

      Then, use helm to install the kubernetes-dashboard package from the stable repo:

      • helm install dashboard-demo stable/kubernetes-dashboard --set rbac.clusterAdminRole=true

      The --set parameter lets you to customize chart variables, which the chart exposes to allow you to customize its configuration. Here, you set the rbac.clusterAdminRole variable to true to grant the Kubernetes Dashboard access to your whole cluster.

      The output will look like:

      Output

      NAME: dashboard-demo LAST DEPLOYED: Tue Mar 31 15:04:19 2020 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: ...

      Notice the NAME line, highlighted in the above example output. In this case, you specified the name dashboard-demo. This is the name of the release. A Helm release is a single deployment of one chart with a specific configuration. You can deploy multiple releases of the same chart, each with its own configuration.

      You can list all the releases in the cluster:

      The output will be similar to this:

      Output

      NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION dashboard-demo default 1 2020-03-31 15:04:19.324774799 +0000 UTC deployed kubernetes-dashboard-1.10.1 1.10.1

      You can now use kubectl to verify that a new service has been deployed on the cluster:

      The output will look like this:

      Output

      NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE dashboard-demo-kubernetes-dashboard ClusterIP 10.245.115.214 <none> 443/TCP 4m44s kubernetes ClusterIP 10.245.0.1 <none> 443/TCP 19m

      Notice that by default, the service name corresponding to the release is a combination of the Helm release name and the chart name.

      Now that you’ve deployed the application, you’ll use Helm to change its configuration and update the deployment.

      Step 3 — Updating a Release

      The helm upgrade command can be used to upgrade a release with a new or updated chart, or update its configuration options (variables).

      You’re going to make a simple change to the dashboard-demo release to demonstrate the update and rollback process: you’ll update the name of the dashboard service to just kubernetes-dashboard, instead of dashboard-demo-kubernetes-dashboard.

      The kubernetes-dashboard chart provides a fullnameOverride configuration option to control the service name. To rename the release, run helm upgrade with this option set:

      • helm upgrade dashboard-demo stable/kubernetes-dashboard --set fullnameOverride="kubernetes-dashboard" --reuse-values

      By passing in the --reuse-values argument, you make sure that chart variables you’ve previously set do not get reset by the upgrade process.

      You’ll see output similar to the initial helm install step.

      Check if your Kubernetes services reflect the updated values:

      The output will look like the following:

      Output

      NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.245.0.1 <none> 443/TCP 38m kubernetes-dashboard ClusterIP 10.245.49.157 <none> 443/TCP 8s

      Notice that the service name has been updated to the new value.

      Note: At this point you may want to actually load the Kubernetes Dashboard in your browser and check it out. To do so, first run the following command:

      This creates a proxy that lets you access remote cluster resources from your local computer. Based on the previous instructions, your dashboard service is named kubernetes-dashboard and it’s running in the default namespace. You may now access the dashboard at the following URL:

      http://localhost:8001/api/v1/namespaces/default/services/https:kubernetes-dashboard:https/proxy/
      

      Instructions for actually using the dashboard are out of scope for this tutorial, but you can read the official Kubernetes Dashboard docs for more information.

      Next, you’ll have a look at Helm’s ability to roll back and delete releases.

      Step 4 — Rolling Back and Deleting a Release

      When you updated the dashboard-demo release in the previous step, you created a second revision of the release. Helm retains all the details of previous releases in case you need to roll back to a prior configuration or chart.

      Use helm list to inspect the release again:

      You’ll see the following output:

      Output

      NAME REVISION UPDATED STATUS CHART NAMESPACE dashboard-demo 2 Wed Aug 8 20:13:15 2018 DEPLOYED kubernetes-dashboard-0.7.1 default

      The REVISION column tells you that this is now the second revision.

      Use helm rollback to roll back to the first revision:

      • helm rollback dashboard-demo 1

      You should see the following output, indicating that the rollback succeeded:

      Output

      Rollback was a success! Happy Helming!

      At this point, if you run kubectl get services again, you will notice that the service name has changed back to its previous value. Helm has re-deployed the application with revision 1’s configuration.

      Helm releases can be deleted with the helm delete command:

      • helm delete dashboard-demo

      The output will be:

      Output

      release "dashboard-demo" uninstalled

      You can try listing Helm releases:

      You’ll see that there are none:

      Output

      NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION

      Now the release has been truly deleted, and you can reuse the release name.

      Conclusion

      In this tutorial, you installed the helm command-line tool and explored installing, upgrading, rolling back, and deleting Helm charts and releases by managing the kubernetes-dashboard chart.

      For more information about Helm and Helm charts, please see the official Helm documentation.



      Source link