{"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":"Veraltete Feature-Branch im Kubernetes-Cluster l\u00f6schen","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Veraltete<\/p>\n

Hallo! Feature-Branch<\/b> (aka Deploy-Vorschau, Review-App) \u2014 das bedeutet, dass nicht nur der Master-Zweig, sondern auch jeder Pull Request auf einer einzigartigen URL bereitgestellt wird. So kann \u00fcberpr\u00fcft werden, ob der Code in einer Produktionsumgebung funktioniert, und die Funktion kann anderen Programmierern oder Produktmanagern gezeigt werden. W\u00e4hrend Sie an einem Pull Request arbeiten, wird jedes neue Commit die aktuelle Bereitstellung f\u00fcr den alten Code l\u00f6schen, und eine neue Bereitstellung f\u00fcr den neuen Code wird durchgef\u00fchrt. Fragen k\u00f6nnen entstehen, nachdem Sie den Pull Request in den Master-Zweig gemergt haben. Der Feature-Branch ist dann nicht mehr erforderlich, aber die Ressourcen von Kubernetes befinden sich weiterhin im Cluster.<\/p>\n

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

Mehr \u00fcber Feature-Branches<\/h2>\n

<\/p>\n

Eine der Methoden, um Feature-Branches in Kubernetes zu erstellen, 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-Branch wird ein Namespace mit dessen Identifikator (z.B. Nummer des Pull Requests) und einem bestimmten Pr\u00e4fix\/Suffix erstellt (z.B. -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
Insgesamt habe ich geschrieben Kubernetes Operator<\/b> (eine Anwendung, die Zugriff auf die Cluster-Ressourcen hat), Link zum Projekt auf Github<\/a><\/noindex>. Er l\u00f6scht die Namespaces, die zu alten Feature-Branches geh\u00f6ren. In Kubernetes werden, wenn ein Namespace gel\u00f6scht wird, auch andere 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
\u00dcber die Implementierung von Feature-Branches im Cluster kann man lesen 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 anschauen (kontinuierliche Integration<\/code>):<\/p>\n
<\/p>\n
    \n
  1. Wir pushen ein neues Commit in den Branch.<\/li>\n
  2. Beim Build werden Linter und\/oder Tests ausgef\u00fchrt.<\/li>\n
  3. Die Konfigurationen des Kubernetes-Pull Requests werden dynamisch erstellt (z.B. wird seine Nummer in eine fertige Vorlage eingesetzt).<\/li>\n
  4. Die Konfigurationen gelangen mit kubectl apply in den Cluster (Deployment).<\/li>\n
  5. Der Pull-Request wird in den Master-Zweig zusammengef\u00fchrt.<\/li>\n<\/ol>\n
    <\/p>\n
    W\u00e4hrend Sie an einem Pull Request arbeiten, wird jedes neue Commit die aktuelle Bereitstellung f\u00fcr den alten Code l\u00f6schen, und eine neue Bereitstellung f\u00fcr den neuen Code wird durchgef\u00fchrt. Aber wenn der Pull Request in den Master-Zweig integriert wird, wird nur der Master-Zweig gebaut. Am Ende stellt sich heraus, dass wir den Pull Request bereits vergessen haben, w\u00e4hrend seine Kubernetes-Ressourcen weiterhin im Cluster sind.<\/p>\n
    <\/p>\n
    Wie man es verwendet<\/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 installieren Sie sie \u00fcber 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> ist notwendig, um die Namespaces f\u00fcr Pull Requests von anderen Namespaces zu filtern. Zum Beispiel, wenn im Cluster die folgenden Namespaces vorhanden sind: habr-back-end<\/code>, habr-front-end<\/code>, habr-back-end-pr-17<\/code>, habr-back-end-pr-33<\/code>, dann w\u00e4ren die Kandidaten f\u00fcr die L\u00f6schung habr-back-end-pr-17<\/code>, habr-back-end-pr-33<\/code>.<\/p>\n
    <\/p>\n
    Parameter afterDaysWithoutDeploy<\/b> notwendig, um alte Namespaces zu entfernen. Zum Beispiel, wenn der Namespace erstellt wurde 3 Tagen 1 Stunde<\/code> erstellt wurde, und der Parameter angibt 3 Tage<\/code>, wird dieser Namespace gel\u00f6scht. Es funktioniert auch in umgekehrter Richtung, wenn der Namespace vor 2 Tagen 23 Stunden<\/code> erstellt wurde, und der Parameter angibt 3 Tage<\/code>, wird dieser Namespace nicht gel\u00f6scht.<\/p>\n
    <\/p>\n
    Es gibt noch einen weiteren Parameter, der festlegt, wie oft alle Namespaces gescannt werden sollen, um nach Tagen ohne Bereitstellung zu pr\u00fcfen \u2014 checkEveryMinutes<\/b>. Standardm\u00e4\u00dfig betr\u00e4gt er 30 Minuten<\/code>.<\/p>\n
    <\/p>\n
    Die DANE-Spezifikation ist in<\/h2>\n
    <\/p>\n
    In der Praxis wird Folgendes ben\u00f6tigt:<\/p>\n
    <\/p>\n
      \n
    1. Docker<\/a><\/noindex> um in einer isolierten Umgebung zu arbeiten.<\/li>\n
    2. Minikube<\/a><\/noindex> hebt den Kubernetes-Cluster lokal an.<\/li>\n
    3. kubectl<\/a><\/noindex> \u2014 Kommandozeileninterface zur Verwaltung des Clusters.<\/li>\n<\/ol>\n
      <\/p>\n
      Heben wir den Kubernetes-Cluster lokal an:<\/p>\n
      <\/p>\n
      $ minikube start --vm-driver=docker\nminikube v1.11.0 auf Darwin 10.15.5\nVerwendung des Docker-Treibers basierend auf dem vorhandenen Profil.\nStarte Steuerungsplane-Node minikube im Cluster minikube.<\/code><\/pre>\n
      <\/p>\n
      Geben Sie an kubectl<\/code> lokalen Cluster standardm\u00e4\u00dfig verwenden:<\/p>\n
      <\/p>\n
      $ kubectl config use-context minikube\nWechsel zu Kontext \"minikube\".<\/code><\/pre>\n
      <\/p>\n
      Laden Sie 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 eingestellt sind, um alte Namespaces zu \u00fcberpr\u00fcfen, wir jedoch keine in unserem neu gestarteten Cluster haben, ersetzen wir die Umgebungsvariable IS_DEBUG<\/code> auf true<\/code>. Bei diesem Wert wird der Parameter afterDaysWithoutDeploy<\/code> wird nicht ber\u00fccksichtigt und die Namespaces werden nicht auf Tage ohne Bereitstellung \u00fcberpr\u00fcft, nur auf das Vorhandensein eines Substrings (-pr-<\/code>).<\/p>\n
      <\/p>\n
      Wenn Sie auf 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 auf macOS<\/code>:<\/p>\n
      <\/p>\n
      $ sed -i \"\" 's|false|true|g' stale-feature-branch-production-configs.yml<\/code><\/pre>\n
      <\/p>\n
      Installieren Sie das Projekt:<\/p>\n
      <\/p>\n
      $ kubectl apply -f stale-feature-branch-production-configs.yml<\/code><\/pre>\n
      <\/p>\n
      \u00dcberpr\u00fcfen Sie, ob 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\u00fcfen Sie, ob 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 in seine Protokolle schauen, ist es 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
      Installieren Sie die fertigen fixtures<\/code> (fertige 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, nach Namespaces mit Substring zu suchen -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 reagierte und ist bereit, die Namespaces zu \u00fcberpr\u00fcfen:<\/p>\n
      <\/p>\n
      $ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator\n... \"msg\":\"Stale feature branch wird verarbeitet.\",\"namespaceSubstring\":\"-pr-\",\"afterDaysWithoutDeploy\":1,\"checkEveryMinutes\":1,\"isDebug\":\"true\"}<\/code><\/pre>\n
      <\/p>\n
      Installation fixtures<\/code>, die zwei Namespaces enthalten (project-pr-1<\/code>, project-pr-2<\/code>) und deren deployments<\/code>, Dienste<\/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\/project-pr-1 erstellt\ndeployment.apps\/project-pr-1 erstellt\nservice\/project-pr-1 erstellt\nhorizontalpodautoscaler.autoscaling\/project-pr-1 erstellt\nsecret\/project-pr-1 erstellt\nconfigmap\/project-pr-1 erstellt\ningress.extensions\/project-pr-1 erstellt\nnamespace\/project-pr-2 erstellt\ndeployment.apps\/project-pr-2 erstellt\nservice\/project-pr-2 erstellt\nhorizontalpodautoscaler.autoscaling\/project-pr-2 erstellt\nsecret\/project-pr-2 erstellt\nconfigmap\/project-pr-2 erstellt\ningress.extensions\/project-pr-2 erstellt<\/code><\/pre>\n
      <\/p>\n
      \u00dcberpr\u00fcfen wir, ob alle oben genannten Ressourcen erfolgreich erstellt wurden:<\/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...\nNAME                              ... READY ... STATUS  ... AGE\npod\/project-pr-1-848d5fdff6-rpmzw ... 1\/1   ... Running ... 67s\n\nNAME                         ... READY ... AVAILABLE ... AGE\ndeployment.apps\/project-pr-1 ... 1\/1   ... 1         ... 67s\n...<\/code><\/pre>\n
      <\/p>\n
      Da wir die debug<\/code>, Namespaces project-pr-1<\/code> und project-pr-2<\/code>, m\u00fcssen auch alle anderen Ressourcen sofort gel\u00f6scht werden, unabh\u00e4ngig vom Parameter afterDaysWithoutDeploy<\/code>. In den Logs des Operators ist das sichtbar:<\/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 Debugmodus 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 Debugmodus 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 wir die Verf\u00fcgbarkeit der Ressourcen \u00fcberpr\u00fcfen, werden sie sich im Status Terminating<\/code> (L\u00f6schprozess) oder bereits gel\u00f6scht (der Befehl gibt nichts aus).<\/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 sich vergewissern, dass sie innerhalb einer Minute gel\u00f6scht werden.<\/p>\n
      <\/p>\n
      Alternativen<\/h2>\n
      <\/p>\n
      Was kann man statt eines Operators machen, der im Cluster arbeitet? Es gibt mehrere Ans\u00e4tze, die alle nicht perfekt sind (und ihre M\u00e4ngel subjektiv sind), und jeder entscheidet selbst, was am besten f\u00fcr ein bestimmtes Projekt geeignet ist:<\/p>\n
      <\/p>\n
        \n
      1. \n
        Den Feature-Branch w\u00e4hrend des Builds des Master-Branches l\u00f6schen.<\/p>\n
        <\/p>\n