Warum ArgoCD föderieren?

Die erfolgreiche Revolution und Entwicklung von GitOps Praktiken in etablierten Unternehmen beruhen auf der Fähigkeit, Teams einen Prozess an die Hand zu geben, mit dem sie ihre eigenen Paradigmen und Praktiken rationalisieren können, mit dem einzigen Ziel, die Integration, das Testen, die Auslieferung, die Bereitstellung, die Analyse und die Verwaltung von Code effizienter zu gestalten. Traditionell, ArgoCD innerhalb von GitOps wurde als zentralisiertes CD-Tool innerhalb der agilen Architektur von CI/CD-Pipelines eingesetzt. Dieser Ansatz ist akzeptabel, wenn ArgoCD für Teams eingesetzt werden soll, die alle die gleichen Ziele verfolgen, deren Anwendungsfälle übereinstimmen und die sich keine Sorgen um die Sicherheit machen, wenn es darum geht, wer Zugriff auf den Cluster erhält, der ArgoCD hostet. Wenn der Anwendungsfall jedoch eine einzigartige Architektur erfordert, um eine dynamische ArgoCD-Plattform aufrechtzuerhalten, die die spezifischen Anwendungsfälle jedes Teams erfüllen kann und gleichzeitig eine robuste zentralisierte, sicherheitsintensive Umgebung aufrechterhält, um unnötige Änderungen im gesamten Ökosystem aufgrund dieser individuellen und manchmal widersprüchlichen Anwendungsfälle zu verhindern, dann ist eine föderierte ArgoCD-Plattform erforderlich.

Das Konzept der Föderation ist eine Dezentralisierung der Macht (d.h. der Entscheidungsfindung), bei der einer oder mehreren Entitäten Autonomie über etwas gegeben wird, mit der Absicht, sich an eine Kernmacht zu halten, die alle föderierten Entitäten bindet. Warum sollten Sie sich die Mühe machen, die Föderation zu erklären? Nun, weil ArgoCD den Teams die Möglichkeit gibt, ihre Continuous Delivery Prozesse zu automatisieren Kubernetes. Was es nicht explizit tut, ist, die Sicherheit zu diktieren, RBAC, Autonomie, wer ArgoCD-Ressourcen wie Cluster, Anwendungen, Projekte usw. löschen, aktualisieren oder erstellen kann. Damit wird ein grundlegender Sicherheitsmangel in Frage gestellt, wenn man sich auf einen zentralisierten Ansatz verlässt. Wenn Sie einer oder mehreren Gruppen die Autonomie geben, Ressourcen hinzuzufügen oder zu löschen, geben Sie implizit allen Personen in dieser Gruppe die Autonomie, Cluster hinzuzufügen oder zu löschen. Außerdem wird die Frage des Zugriffs auf den ArgoCD-Cluster (der die ArgoCD-Komponenten hostet) problematisch. Wenn mehrere Teams an Bord kommen sollen, muss ihr Cluster zu ArgoCD hinzugefügt werden. Das bedeutet, dass Sie den einzelnen Personen Zugriff gewähren müssen, damit sie ihren Cluster hinzufügen können, oder dass Sie eine ganze Ressource für die Verwaltung dieses Prozesses bereitstellen müssen.

Warum also eine föderale Architektur?

Der Zweck dieser Architektur ist es, drei zentrale Ziele zu erreichen.

1. Verfügen Sie über einen zentralen ArgoCD 'Master' Controller, der alle Entscheidungen in Bezug auf RBAC-Richtlinien, das Hinzufügen von Clustern, den Einsatz und die Verwaltung der gesamten ArgoCD-Plattform trifft.
2. Schaffung einer robusten Plattform, bei der die Quelle der Wahrheit für ArgoCD Git ist und nicht der Kubernetes-Cluster oder der Endbenutzer. Wenn also eine Komponente von 'worker' ArgoCD-Instanzen gelöscht wird (einschließlich Namespaces), ist die Master-ArgoCD mehr als in der Lage, den gewünschten Zustand wiederherzustellen (Selbstheilung). Darüber hinaus wird mit diesem Ansatz ein Maß an Sicherheit erreicht, bei dem Endbenutzer, die nicht zur ArgoCD-Kerngruppe gehören, keinen Zugriff auf die wichtigsten ArgoCD-Cluster (master-prod, worker-prod und worker-uat usw.) haben.
3. Um jedem Team Autonomie zu geben. Obwohl wir einen zentralisierten Master-Controller haben, ist es die Aufgabe des Masters, eine Worker-ArgoCD für jedes Team einzusetzen. Das bedeutet, dass jedes Team seine eigene dedizierte ArgoCD-Instanz hat. Diese Entscheidung ermöglicht es den Teams, ihre CI/CD-Prozesse unabhängig von den einzigartigen Anwendungsfällen anderer Teams zu erneuern und gleichzeitig ein vernetztes Ökosystem mit anderen Teams aufrechtzuerhalten, da sie immer noch an denselben Controller gebunden sind. Auch das Problem der Skalierbarkeit ist wirklich gelöst, da jedes Team seine eigene dedizierte ArgoCD-Instanz hat, die so viele Cluster verwalten kann, wie es möchte - ohne die Ressourcen und die algorithmische Integrität von ArgoCD innerhalb des Kubernetes-Clusters und des gesamten ArgoCD-Ökosystems zu gefährden.

Erklären der Architektur

Der 'Meister' ArgoCD

Wie unten beschrieben, wird die Master ArgoCD eingesetzt 'manually' oder durch Automatisierung über ein beliebiges ereignisgesteuertes System in einen dedizierten Kubernetes-Cluster - daher wird er nicht von ArgoCD verwaltet. Innerhalb des Clusters wird es eine metadata.namespace: 'argocd', an ingress-nginx-controllerund eine Ingress-Regel, die auf einen Hostnamen verweist. In diesem Artikel verwenden wir den Hostnamen: argocd.dev.47deg.comSolange der Hostname jedoch in einem DNS-Eintrag registriert ist, können wir den Hostnamen verwenden: argocd..47deg.com. Und wie? Denn die wahre Identität dieses Hostnamens ist *.47deg.com. Daher nutzen wir eine Round-Robin-Ingress-Architektur, bei der wir den Datenverkehr auf der Grundlage der sub.domain und nicht der Hauptdomain (47deg.com) umleiten.

Das Git-Repository

Der Quellcode unserer Master-ArgoCD wird in einem Git-Repository gehostet. In ähnlicher Weise werden alle anderen 'worker' Die ArgoCD-Instanzen werden ebenfalls in demselben Repository gehostet. Das Schema des Repository wurde absichtlich so gestaltet, dass eine reibungslose kontinuierliche Bereitstellung von ArgoCD(s) möglich ist. Wenn der Master zum Beispiel bereitgestellt wurde, wird er die folgende Anwendung hosten:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: argocd--
  namespace: argocd
spec:
  destination:
    namespace: argocd-
    server:  # change depending on uat or prod i.e. https://rd-argocd-aks-uat-xxxxxx.xxx.eastus2.azmk8s.io:443
  project: 47deg-argocd--
  source:
    path: argocdv2.0/prod/deploy/
    repoURL: /47deg-argocd.git
    targetRevision: main # git branches can be determined by (( teamName }}
  syncPolicy:
    automated:
      selfHeal: true

Dies gibt dem Master-ArgoCD die Möglichkeit, alle anderen ArgoCD-Instanzen (Arbeiter) auf der Grundlage einer einzigen Quelle der Wahrheit zu verwalten. Wenn Sie ein ereignisgesteuertes System verwenden, wird das System jedes Mal, wenn ein Team an Bord kommen möchte, einige Eingaben vom Endbenutzer verlangen, wie unten beschrieben:

## Inputs which are stored in Azure KeyVault ##

 # echo <client_secret> |base64. Put the decrypted secret as input.
## Inputs required during automation ##
 # This has to be a **unique** name which has not been claimed by any other team.
 #i.e prod, uat - these are the only two options

# Groups (object_id) is tied to Enterprise applications. Below groups permissions are based on the project.

# 26ed52e9-xxxx-xxxx-xxxx-a4056dff490a = 47deg-ArgoCD-ArgoCD-Dev
# 7be98a90-xxxx-xxxx-xxxx-30a9687f5c88 = 47deg-ArgoCD-Logging-Dev
# 4ceca436-xxxx-xxxx-xxxx-6f079137a4d1 = 47deg-ArgoCD-Monitoring-Dev
# b216ca0f-xxxx-xxxx-xxxx-c90a0c25ba7d = 47deg-ArgoCD-Team1-Dev
# 772af769-xxxx-xxxx-xxxx-f025e3c00db5 = 47deg-ArgoCD-Team2-Dev
# 65a7e9ae-xxxx-xxxx-xxxx-f3989bfb9e94 = fpxxxxxx@47deg.com
 # rolepermission can only be 'admin' or 'readonly'. If not stated, by default, it is
'readonly'.
 # client_id found in azure enterprise application

argocdv2.0/
├── master
│   ├── argocd-cm-manager.yml
│   ├── argocd-rbac-cm-manager.yml
│   ├── argocd-secret-manager.yml
│   ├── clusterole.yml
│   ├── configurecluster
│   │   ├── configure-cluster.yml
│   │   └── configure-sa.yml
│   ├── deploy
│   │   └── argocddeploy.yaml
│   ├── master-ingress.yaml
│   ├── master_hpa.yml
│   ├── namespaces-master.yaml
│   └── nginx-controller
│       ├── metricsserver.yml
│       ├── nginx-hpa.yml
│       └── nginxingresscontroller.yaml
└── prod
    ├── addapp
    │   ├── hpa_app.yml
    │   ├── ingress_app.yml
    │   ├── logging_app.yml
    │   ├── namespace_app.yml
    │   └── rbac_app.yml
    ├── addprojects
    │   └── master-project.yml
    ├── addrepo
    │   └── master_git.yaml
    ├── clusterole.yml
    ├── configurecluster
    │   ├── configure-cluster.yml
    │   └── configure-sa.yml
    ├── deploy
    │   └── logging
    │       └── argocddeploy.yaml
    ├── hpa
    │   ├── hpa.yml
    │   └── metricsserver.yml
    ├── ingress
    │   └── argocdingress.yaml
    ├── namespaces
    │   └── namespaces.yaml
    ├── nginx-controller
    │   ├── metricsserver.yml
    │   ├── nginx-hpa.yml
    │   └── nginxingresscontroller.yaml
    └── rbac
        ├── argocd-cm-logging.yml
        ├── argocd-rbac-cm-logging.yml
        └── argocd-secret-logging.yml

Eigenschaften von 'Meister und Arbeiter' ArgoCD

Um Fragen zu Elastizität, Verfügbarkeit, Redundanz und Ressourcenintegrität zu lösen, haben wir das gesamte föderierte Ökosystem so konzipiert, dass es sich innerhalb des/der Kubernetes-Cluster(s) unabhängig verhält, während es sich auf einige zentrale Kernobjekte innerhalb des/der Kubernetes-Cluster(s) stützt.

Namespace(s): Für die 'worker' ArgoCD(s), verwenden wir das Konzept der 'multi-tenancy' als ein Design-Tool, bei dem wir einzelne Teams (Tenants) haben, die alle auf derselben Plattform (ArgoCD) arbeiten. Daher haben wir den Cluster innerhalb des Clusters auf der Grundlage von Namensräumen abgegrenzt, wodurch wir sicherstellen können, dass jede ArgoCD-Instanz einzigartig ist, während sie mit anderen ArgoCD-Instanzen im selben Cluster koexistiert (gemeinsame Nutzung von Cluster-Ressourcen, statischer IP, Domain und Ingress-Nginx-Controller). Diese Entscheidung dient dazu, ein kosteneffizientes Budget zu gewährleisten. Wir haben jedoch eine 'core-tenant' Design mit dem 'master' ArgoCD, das sich in einem eigenen, dedizierten Cluster befindet. Damit wird Redundanz und Verfügbarkeit für das gesamte ArgoCD-Ökosystem gewährleistet.

HPA: Horizontale Pod-Autoskalierung ist eine Funktion, die in all diesen Kernkomponenten (argocd-application-controller, argocd-server, argocd-reposerver) von ArgoCD vorhanden ist. Der ingress-nginx-controller, der in allen drei ArgoCD Kubernetes-Clustern eingesetzt wird, verfügt ebenfalls über diese Funktion. Diese Funktion soll Elastizität und Ressourcenintegrität gewährleisten.

Pod-AntiAffinität: Dies wurde auf alle ArgoCD-Komponenten angewandt, obwohl bestimmte Kernkomponenten (z.B. argocd-application-controller, u.a.) mit 'weight: 100'. Pod-AntiAffinity soll sicherstellen, dass Pods mit ähnlichen Anwendungen nicht aufgrund von Label-Einschränkungen auf demselben Knoten eingeplant werden und dass kube-scheduler die Pods so auf die Knoten verteilt, dass korrelierte Ausfälle reduziert werden.

Empfohlene zukünftige Funktionen

• Node-Affinität auf der Grundlage von NodePools. Obwohl dies die Skalierbarkeit in Frage stellt, ist es eine Option, wenn Kosten (oder Budgets) keine Rolle spielen. Sie garantiert u.a. die Integrität und Verfügbarkeit von Ressourcen.
• Automatische Skalierung von Knoten. Dies ist die Antwort auf den obigen Punkt, dass die Skalierung nicht möglich ist. Auch hier gilt: Wenn die Kosten kein Hindernis darstellen, sollten Sie dies beim Aufbau der Infrastruktur berücksichtigen.
• Cert-Manager SSL - sichert den Cluster und die Anwendungen.
• PodSecurityBudgets - stärkt die Kernfunktionen von Elastizität und Redundanz.

Vernetzung von 'Worker' ArgoCD(s).

Alle Worker-ArgoCD(s) werden in demselben Cluster eingesetzt. Daher werden die einzelnen ArgoCD-Instanzen von Teams, die in den UAT einsteigen, auf dem 'rd-ArgoCD-AKS-uat-admin'. In ähnlicher Weise werden die individuellen ArgoCD-Instanzen von Teams, die zur PRODUKTION übergehen, auf dem Server 'rd-ArgoCD-AKS-prod-admin'. Da alle Worker-ArgoCD(s)-Instanzen ihren eigenen Namespace(s) haben werden, war es notwendig, das Design der Vernetzung innerhalb des Kubernetes-Clusters zu vereinfachen. Daher haben wir den Round-Robin-Ansatz gewählt, bei dem es einen internen Ingress-Nginx-Controller gibt. 'LoadBalancer' mit einer statischen IP, die alle HTTPS-Protokollanfragen verwaltet. Azure verwaltet diese IP über {service.beta.kubernetes.io/azure-load-balancer-internal: "true"}

Daher teilen sich alle ArgoCD-Arbeitsinstanzen diese statische IP und Domain (47deg.com) innerhalb eines Kubernetes-Clusters. Aber der ingress-nginxcontroller leitet den Datenverkehr auf der Grundlage der sub.domain(s) weiter, die in der/den ingress-Ressource(n) angegeben ist.

Fazit

Der Zweck der Föderation von ArgoCD besteht darin, die Glaubwürdigkeit der Sicherheit sowohl für ArgoCD als auch für den/die Kubernetes-Cluster zu gewährleisten. Darüber hinaus schafft eine föderierte Architektur ein innovatives Umfeld, ein Ökosystem, das es den Teams ermöglicht, autonom über ihre ArgoCD-Instanzen zu verfügen - ohne den Gesamtfortschritt der anderen zu behindern. Und schließlich wird die Integrität der Algorithmen und Ressourcen durch die Dezentralisierung gewahrt. ArgoCD kann so skaliert werden, dass es eine Vielzahl von Clustern und Anwendungen verwalten kann, sofern die richtigen Ressourcen bereitgestellt werden. Letztlich ermöglicht die Föderation die Wahrung des Kernkonzepts von GitOps - nämlich eine einzige ‘source of truth’.