{"id":86902,"date":"2020-07-01T07:42:28","date_gmt":"2020-07-01T05:42:28","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/udalyaem-ustarevshuyu-feature-branch-v-kubernetes-klastere"},"modified":"2020-07-01T07:42:28","modified_gmt":"2020-07-01T05:42:28","slug":"udalyaem-ustarevshuyu-feature-branch-v-kubernetes-klastere","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/udalyaem-ustarevshuyu-feature-branch-v-kubernetes-klastere","title":{"rendered":"Entfernen des veralteten Feature-Branches im Kubernetes-Cluster.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Entfernen<\/p>\n

Hallo! Feature-Branch<\/b> (auch bekannt als Deploy-Vorschau, Review-App) \u2014 das ist, wenn nicht nur der Master-Zweig, sondern auch jeder Pull Request auf eine einzigartige URL bereitgestellt wird. So kann gepr\u00fcft werden, ob der Code in der Produktionsumgebung funktioniert, und eine Funktion kann anderen Entwicklern oder Produktmanagern pr\u00e4sentiert werden. Solange Sie im Pull Request arbeiten, wird jedes neue Commit das aktuelle Deployment f\u00fcr den alten Code entfernt, und ein neues Deployment f\u00fcr den neuen Code wird bereitgestellt. Fragen k\u00f6nnen auftreten, wenn Sie den Pull Request in den Master-Zweig gemergt haben. Der Feature-Zweig wird nicht mehr ben\u00f6tigt, aber die Ressourcen von Kubernetes befinden sich weiterhin im Cluster.<\/p>\n

<\/a><\/noindex><\/p>\n

Noch zu Feature-Zweigen<\/h2>\n

<\/p>\n

Eine M\u00f6glichkeit, wie man Feature-Zweige in Kubernetes erstellen kann, ist die Verwendung von Namespaces. Kurz gesagt, die Produktionskonfiguration sieht so aus:<\/p>\n

<\/p>\n

kind: Namespace\napiVersion: v1\nmetadata:\n  name: habr-back-end\n...\n\nkind: Deployment\napiVersion: apps\/v1\nmetadata:\n  namespace: habr-back-end\nspec:\n  replicas: 3\n...<\/code><\/pre>\n
<\/p>\n
F\u00fcr den Feature-Zweig wird ein Namespace mit seiner Identifikation (zum Beispiel die Nummer des Pull Requests) und einem bestimmten Pr\u00e4fix\/Nachsatz (zum Beispiel -pr-<\/b>):<\/p>\n
<\/p>\n
kind: Namespace\napiVersion: v1\nmetadata:\n  name: habr-back-end-pr-17\n...\n\nkind: Deployment\napiVersion: apps\/v1\nmetadata:\n  namespace: habr-back-end-pr-17\nspec:\n  replicas: 1\n...<\/code><\/pre>\n
<\/p>\n
Im Allgemeinen habe ich geschrieben Kubernetes Operator<\/b> (eine Anwendung, die Zugriff auf Cluster-Ressourcen hat), Link zum Projekt auf GitHub<\/a><\/noindex>. Es entfernt Namespaces, die zu alten Feature-Zweigen geh\u00f6ren. In Kubernetes werden bei der L\u00f6schung eines Namespaces auch die anderen Ressourcen in diesem Namespace automatisch gel\u00f6scht.<\/p>\n
<\/p>\n
$ kubectl get pods --all-namespaces | grep -e \"-pr-\"\nNAMESPACE            ... ALTER\nhabr-back-end-pr-264 ... 4d8h\nhabr-back-end-pr-265 ... 5d7h<\/code><\/pre>\n
<\/p>\n
Wie man Feature-Zweige in den Cluster integriert, kann hier nachgelesen werden. hier<\/a><\/noindex> und hier<\/a><\/noindex>.<\/p>\n
<\/p>\n
Motivation<\/h2>\n
<\/p>\n
Lassen Sie uns den typischen Lebenszyklus eines Pull Requests mit kontinuierlicher Integration betrachten (continuous integration<\/code>):<\/p>\n
<\/p>\n
    \n
  1. Wir pushen einen neuen Commit in den Branch.<\/li>\n
  2. Bei der Erstellung werden Linter und\/oder Tests ausgef\u00fchrt.<\/li>\n
  3. Die Kubernetes-Konfigurationen des Pull Requests werden dynamisch generiert (zum Beispiel wird die Nummer in die entsprechende Vorlage eingef\u00fcgt).<\/li>\n
  4. Mit kubectl apply gelangen die Konfigurationen in den Cluster (Deployment).<\/li>\n
  5. Der Pull Request wird in den Master-Branch gemergt.<\/li>\n<\/ol>\n
    <\/p>\n
    W\u00e4hrend Sie im Pull Request arbeiten, wird jedes neue Commit die aktuelle Bereitstellung des alten Codes zur\u00fccksetzen und eine neue Bereitstellung des neuen Codes durchf\u00fchren. Wenn der Pull Request jedoch in den Master-Zweig zusammengef\u00fchrt wird, wird nur der Master-Zweig gebaut. Dadurch kann es geschehen, dass wir den Pull Request bereits vergessen haben, w\u00e4hrend seine Kubernetes-Ressourcen weiterhin im Cluster vorhanden sind.<\/p>\n
    <\/p>\n
    Wie verwenden<\/h2>\n
    <\/p>\n
    Installieren Sie das Projekt mit dem folgenden Befehl:<\/p>\n
    <\/p>\n
    $ kubectl apply -f https:\/\/raw.githubusercontent.com\/dmytrostriletskyi\/stale-feature-branch-operator\/master\/configs\/production.yml<\/code><\/pre>\n
    <\/p>\n
    Erstellen Sie eine Datei mit folgendem Inhalt und wenden Sie sie mit kubectl apply -f<\/code>:<\/p>\n
    <\/p>\n
    apiVersion: feature-branch.dmytrostriletskyi.com\/v1\nkind: StaleFeatureBranch\nmetadata:\n  name: stale-feature-branch\nspec:\n  namespaceSubstring: -pr-\n  afterDaysWithoutDeploy: 3<\/code><\/pre>\n
    <\/p>\n
    Parameter namespaceSubstring<\/b> ben\u00f6tigt, um Namespaces f\u00fcr Pull Requests von anderen Namespaces zu filtern. Zum Beispiel, wenn im Cluster folgende Namespaces vorhanden sind: habr-back-end<\/code>, habr-front-end<\/code>, habr-back-end-pr-17<\/code>, habr-back-end-pr-33<\/code>, dann sind die Kandidaten zur L\u00f6schung habr-back-end-pr-17<\/code>, habr-back-end-pr-33<\/code>.<\/p>\n
    <\/p>\n
    Parameter afterDaysWithoutDeploy<\/b> ben\u00f6tigt, um alte Namespaces zu l\u00f6schen. Zum Beispiel, wenn ein Namespace erstellt wurde 3 Tagen 1 Stunde<\/code> erstellt wurde und im Parameter angegeben ist 3 Tage<\/code>, wird dieserNamespace gel\u00f6scht. Es funktioniert auch umgekehrt, wenn einNamespace vor 2 Tagen 23 Stunden<\/code> erstellt wurde und im Parameter angegeben ist 3 Tage<\/code>erstellt wurde, wird dieserNamespace nicht gel\u00f6scht.<\/p>\n
    <\/p>\n
    Es gibt noch einen weiteren Parameter, der daf\u00fcr verantwortlich ist, wie oft alle Namespaces gescannt werden und auf Tage ohne Bereitstellung \u00fcberpr\u00fcft werden \u2014 checkEveryMinutes<\/b>. Standardm\u00e4\u00dfig betr\u00e4gt er 30 Minuten<\/code>.<\/p>\n
    <\/p>\n
    Wie es funktioniert<\/h2>\n
    <\/p>\n
    In der Praxis wird ben\u00f6tigt:<\/p>\n
    <\/p>\n
      \n
    1. Docker<\/a><\/noindex> um in einer isolierten Umgebung zu arbeiten.<\/li>\n
    2. Minikube<\/a><\/noindex> wird einen Kubernetes-Cluster lokal starten.<\/li>\n
    3. kubectl<\/a><\/noindex> \u2014 ein Befehlszeilen-Interface zur Verwaltung des Clusters.<\/li>\n<\/ol>\n
      <\/p>\n
      Starten wir den Kubernetes-Cluster lokal:<\/p>\n
      <\/p>\n
      $ minikube start --vm-driver=docker\nminikube v1.11.0 on Darwin 10.15.5\nVerwenden des Docker-Treibers basierend auf dem vorhandenen Profil.\nStarte die Steuerungsebene minikube im Cluster minikube.<\/code><\/pre>\n
      <\/p>\n
      Angeben kubectl<\/code> verwenden Sie den lokalen Standard-Cluster:<\/p>\n
      <\/p>\n
      $ kubectl config use-context minikube\nWechsel zu Kontext \"minikube\".<\/code><\/pre>\n
      <\/p>\n
      Laden der Konfigurationen f\u00fcr die Produktionsumgebung herunter:<\/p>\n
      <\/p>\n
      $ curl https:\/\/raw.githubusercontent.com\/dmytrostriletskyi\/stale-feature-branch-operator\/master\/configs\/production.yml > stale-feature-branch-production-configs.yml<\/code><\/pre>\n
      <\/p>\n
      Da die Produktionskonfigurationen so eingerichtet sind, dass sie alte Namespaces \u00fcberpr\u00fcfen, und in unserem neu gestarteten Cluster keine vorhanden sind, werden wir die Umgebungsvariable ersetzen IS_DEBUG<\/code> findet man true<\/code>. Mit diesem Wert wird der Parameter afterDaysWithoutDeploy<\/code> wird nicht ber\u00fccksichtigt und die Namespaces werden nicht auf Tage ohne Bereitstellung \u00fcberpr\u00fcft, sondern nur auf das Vorhandensein von Unterzeichenfolgen (-pr-<\/code>).<\/p>\n
      <\/p>\n
      Wenn Sie Linux<\/code>:<\/p>\n
      <\/p>\n
      $ sed -i 's|false|true|g' stale-feature-branch-production-configs.yml<\/code><\/pre>\n
      <\/p>\n
      Wenn Sie macOS<\/code>:<\/p>\n
      <\/p>\n
      $ sed -i \"\" 's|false|true|g' stale-feature-branch-production-configs.yml<\/code><\/pre>\n
      <\/p>\n
      Projekt installieren:<\/p>\n
      <\/p>\n
      $ kubectl apply -f stale-feature-branch-production-configs.yml<\/code><\/pre>\n
      <\/p>\n
      \u00dcberpr\u00fcfung, dass die Ressource im Cluster erschienen ist StaleFeatureBranch<\/code>:<\/p>\n
      <\/p>\n
      $ kubectl api-resources | grep stalefeaturebranches\nNAME                 ... APIGROUP                             ... KIND\nstalefeaturebranches ... feature-branch.dmytrostriletskyi.com ... StaleFeatureBranch<\/code><\/pre>\n
      <\/p>\n
      \u00dcberpr\u00fcfung, dass der Operator im Cluster erschienen ist:<\/p>\n
      <\/p>\n
      $ kubectl get pods --namespace stale-feature-branch-operator\nNAME                                           ... STATUS  ... AGE\nstale-feature-branch-operator-6bfbfd4df8-m7sch ... Running ... 38s<\/code><\/pre>\n
      <\/p>\n
      Wenn Sie sich seine Protokolle ansehen, ist er bereit, Ressourcen zu verarbeiten. StaleFeatureBranch<\/code>:<\/p>\n
      <\/p>\n
      $ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator\n... \"msg\":\"Operator Version: 0.0.1\"}\n...\n... \"msg\":\"Starting EventSource\", ... , \"source\":\"kind source: \/, Kind=\"}\n... \"msg\":\"Starting Controller\", ...}\n... \"msg\":\"Starting workers\", ..., \"worker count\":1}<\/code><\/pre>\n
      <\/p>\n
      Bereitgestellte Fixtures<\/code> (vordefinierte Konfigurationen zur Modellierung von Clusterressourcen) f\u00fcr die Ressource StaleFeatureBranch<\/code>:<\/p>\n
      <\/p>\n
      $ kubectl apply -f https:\/\/raw.githubusercontent.com\/dmytrostriletskyi\/stale-feature-branch-operator\/master\/fixtures\/stale-feature-branch.yml<\/code><\/pre>\n
      <\/p>\n
      In den Konfigurationen ist angegeben, dass nach Namespaces mit dem Unterstring gesucht werden soll -pr-<\/code> alle 1 Minute<\/code>.:<\/p>\n
      <\/p>\n
      apiVersion: feature-branch.dmytrostriletskyi.com\/v1\nkind: StaleFeatureBranch\nmetadata:\n  name: stale-feature-branch\nspec:\n  namespaceSubstring: -pr-\n  afterDaysWithoutDeploy: 1 \n  checkEveryMinutes: 1<\/code><\/pre>\n
      <\/p>\n
      Der Operator hat reagiert und ist bereit, nach Namespaces zu suchen:<\/p>\n
      <\/p>\n
      $ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator\n... \"msg\":\"Stale feature branch wird bearbeitet.\",\"namespaceSubstring\":\"-pr-\",\"afterDaysWithoutDeploy\":1,\"checkEveryMinutes\":1,\"isDebug\":\"true\"}<\/code><\/pre>\n
      <\/p>\n
      Installieren Sie Fixtures<\/code>, die zwei Namespaces enthalten (project-pr-1<\/code>, project-pr-2<\/code>) und deren deployments<\/code>, Services<\/code>, ingress<\/code>, und so weiter:<\/p>\n
      <\/p>\n
      $ kubectl apply -f https:\/\/raw.githubusercontent.com\/dmytrostriletskyi\/stale-feature-branch-operator\/master\/fixtures\/first-feature-branch.yml -f https:\/\/raw.githubusercontent.com\/dmytrostriletskyi\/stale-feature-branch-operator\/master\/fixtures\/second-feature-branch.yml\n...\nnamespace\/projekt-pr-1 erstellt\ndeployment.apps\/projekt-pr-1 erstellt\nservice\/projekt-pr-1 erstellt\nhorizontalpodautoscaler.autoscaling\/projekt-pr-1 erstellt\nsecret\/projekt-pr-1 erstellt\nconfigmap\/projekt-pr-1 erstellt\ningress.extensions\/projekt-pr-1 erstellt\nnamespace\/projekt-pr-2 erstellt\ndeployment.apps\/projekt-pr-2 erstellt\nservice\/projekt-pr-2 erstellt\nhorizontalpodautoscaler.autoscaling\/projekt-pr-2 erstellt\nsecret\/projekt-pr-2 erstellt\nconfigmap\/projekt-pr-2 erstellt\ningress.extensions\/projekt-pr-2 erstellt<\/code><\/pre>\n
      <\/p>\n
      \u00dcberpr\u00fcfen Sie, ob alle oben genannten Ressourcen erfolgreich erstellt wurden:<\/p>\n
      <\/p>\n
      $ kubectl get namespace,pods,deployment,service,horizontalpodautoscaler,configmap,ingress -n projekt-pr-1 && kubectl get namespace,pods,deployment,service,horizontalpodautoscaler,configmap,ingress -n projekt-pr-2\n...\nNAME                              ... READY ... STATUS  ... AGE\npod\/projekt-pr-1-848d5fdff6-rpmzw ... 1\/1   ... Running ... 67s\n\nNAME                         ... READY ... AVAILABLE ... AGE\ndeployment.apps\/projekt-pr-1 ... 1\/1   ... 1         ... 67s\n...<\/code><\/pre>\n
      <\/p>\n
      Da wir aktiviert haben debug<\/code>, Namespaces project-pr-1<\/code> und project-pr-2<\/code>, sollten auch alle anderen Ressourcen sofort gel\u00f6scht werden, ohne den Parameter afterDaysWithoutDeploy<\/code>. In den Operator-Logs ist das zu sehen:<\/p>\n
      <\/p>\n
      $ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator\n... \"msg\":\"Namespace sollte gel\u00f6scht werden, da der Debug-Modus aktiviert ist.\",\"namespaceName\":\"project-pr-1\"}\n... \"msg\":\"Namespace wird verarbeitet.\",\"namespaceName\":\"project-pr-1\",\"namespaceCreationTimestamp\":\"2020-06-16 18:43:58 +0300 EEST\"}\n... \"msg\":\"Namespace wurde gel\u00f6scht.\",\"namespaceName\":\"project-pr-1\"}\n... \"msg\":\"Namespace sollte gel\u00f6scht werden, da der Debug-Modus aktiviert ist.\",\"namespaceName\":\"project-pr-2\"}\n... \"msg\":\"Namespace wird verarbeitet.\",\"namespaceName\":\"project-pr-2\",\"namespaceCreationTimestamp\":\"2020-06-16 18:43:58 +0300 EEST\"}\n... \"msg\":\"Namespace wurde gel\u00f6scht.\",\"namespaceName\":\"project-pr-2\"}<\/code><\/pre>\n
      <\/p>\n
      Wenn Sie die Verf\u00fcgbarkeit von Ressourcen \u00fcberpr\u00fcfen, befinden sie sich im Status Wird beendet<\/code> (L\u00f6schvorgang) oder wurden bereits gel\u00f6scht (Ausgabe des Befehls ist leer).<\/p>\n
      <\/p>\n
      $ kubectl get namespace,pods,deployment,service,horizontalpodautoscaler,configmap,ingress -n project-pr-1 && kubectl get namespace,pods,deployment,service,horizontalpodautoscaler,configmap,ingress -n project-pr-2\n...<\/code><\/pre>\n
      <\/p>\n
      Sie k\u00f6nnen den Erstellungsprozess Fixtures<\/code> mehrmals wiederholen und sicherstellen, dass sie innerhalb einer Minute gel\u00f6scht werden.<\/p>\n
      <\/p>\n
      Alternativen<\/h2>\n
      <\/p>\n
      Was kann anstelle des Operators gemacht werden, der im Cluster arbeitet? Es gibt mehrere Ans\u00e4tze, die alle nicht ideal sind (und deren Nachteile subjektiv sind), und jeder entscheidet selbst, was am besten f\u00fcr das jeweilige Projekt geeignet ist:<\/p>\n
      <\/p>\n
        \n
      1. \n
        Feature-Branch w\u00e4hrend des Builds des Continuous Integration Master-Branches zu l\u00f6schen.<\/p>\n
        <\/p>\n