digitalocean cloud controller manager

Kubernetes Cloud Controller Manager für Digitalocean

digitalocean-cloud-controller-manager ist die Implementierung von Kubernetes Cloud Controller Manager für Digitalocean. Lesen Sie hier mehr über Cloud -Controller -Manager. Mit dem Ausführen von digitalocean-cloud-controller-manager können Sie viele der Cloud-Anbieterfunktionen, die Digitalocean auf Ihren Kubernetes-Clustern angeboten haben, nutzen.

Veröffentlichungen

Cloud Controller Manager folgt der semantischen Versionierung. Obwohl die Version noch unter V1 liegt, gilt das Projekt als produktionsbereit.

Aufgrund der Fast Kubernetes -Release -Zyklen unterstützt CCM (Cloud Controller Manager) nur die Version, die auch im Produkt von Digitalocean Kubernetes unterstützt wird. Andere Veröffentlichungen werden von uns nicht offiziell unterstützt.

Erste Schritte

Weitere Informationen zum Ausführen von Digitalocean Cloud Controller Manager finden Sie hier!

Beachten Sie, dass dieses CCM standardmäßig auf DOKs (digitalocean Managed Kubernetes) installiert ist, Sie müssen es nicht selbst tun.

Beispiele

Hier sind einige Beispiele dafür, wie Sie digitalocean-cloud-controller-manager nutzen können:

• Lastballer
• Knotenbezeichnungen und Adressen

Produktionsnotizen

Ändern

Wenn Sie Lastballer über CCM erstellen (über LoadBalancer -typed-Dienste), ist es sehr wichtig, dass Sie die Konfiguration des Do-Lastbalkers nicht manuell ändern dürfen. Solche Änderungen werden schließlich durch die in CCM eingebaute Versöhnungsschleife zurückgekehrt. Es gibt eine Ausnahme im Namen des Load-Balancers, der geändert werden kann (siehe auch die Dokumentation zu Anmerkungen des Ladeballer-ID).

Abgesehen davon ist der einzige sichere Ort, an dem sich Änderungen der Lastbalkerkonfiguration vornehmen, über das Serviceobjekt.

Führen Sie die Eingangsbeschränkungen für die Eingabetaste für die Belastung durch

Aus technischen Gründen können die Ports 50053, 50054 und 50055 nicht als Last-Baller-Eingangsports verwendet werden (dh der Port, auf den der Last-Balancer auf Anforderungen hört). Der Versuch, einen der betroffenen Ports als Service -Port zu verwenden, bewirkt, dass ein 422 -Eintragsport ungültig ist, dass die HTTP -Fehlerantwort von der DO -API zurückgegeben wird (und als Kubernetes -Ereignis aufgetaucht ist).

Die Lösung besteht darin, den Serviceanschluss in eine andere, nicht konflikte zu ändern.

Entwicklung

Grundlagen

• Go: min v1.17.x

In diesem Projekt werden Go -Module für das Abhängigkeitsmanagement verwendet und verwendet das Unternehmen. Bitte stellen Sie sicher, dass Sie nach etwaigen Abhängigkeitsänderungen make vendor .

Führen Sie die Tests und CI -Überprüfungen aus, nachdem Sie Ihre Codeänderungen vorgenommen haben:

make ci

Vor Ort laufen

Wenn Sie digitalocean-cloud-controller-manager lokal gegen einen bestimmten Cluster ausführen möchten, halten Sie Ihre Kubeconfig bereit und starten Sie das Binärdatum im Hauptverzeichnis wie folgt:

 cd cloud-controller-manager/cmd/digitalocean-cloud-controller-manager
REGION=fra1 DO_ACCESS_TOKEN=your_access_token go run main.go 
  --kubeconfig < path to your kubeconfig file >                     
  --leader-elect=false --v=5 --cloud-provider=digitalocean

Die REGION -Umgebungsvariable nimmt eine gültige digitaloceanische Region ein. Es kann so eingestellt werden, dass digitalocean-cloud-controller-manager den Versuch, auf den Digitalocean Metadata-Dienst zuzugreifen, der nur auf Tröpfchen verfügbar ist, zugreifen kann. Wenn die Region -Variable festgelegt ist, wird der DO -Regionen -Dienst verwendet, um die angegebene Region zu validieren. Es kann auch für lokale Entwicklungszwecke festgelegt werden. Insgesamt sollte die Region, die Sie wählen, nicht sehr wichtig ist, solange Sie eine auswählen.

Möglicherweise müssen Sie auch Ihr digitalocean Access Token in DO_ACCESS_TOKEN -Umgebungsvariablen bereitstellen. Das Token muss nicht gültig sein, damit der Cloud -Controller startet, aber in diesem Fall können Sie die Integration mit digitalocean API nicht validieren.

Bitte beachten Sie, dass wenn Sie einen Kubernetes -Cluster verwenden, der auf Digitalocean erstellt wurde, ein Cloud -Controller -Manager im Cluster bereits ausgeführt wird. Ihr lokaler wird damit um den API -Zugriff konkurrieren.

Optionale Funktionen

Fügen Sie öffentlicher Zugangsfeuerwall hinzu

Sie können eine digitalocean-cloud-controller-manager einer digitalocean-Firewall verwalten, die Regeln für den Zugriff auf Nodeports dynamisch anpasst: Sobald ein Dienst vom Typ NodePort erstellt wurde, aktualisiert der Firewall-Controller die Firewall, um den Zugriff auf nur so Nodeport auf den Zugriff zu ermöglichen. Ebenso wird der Zugriff automatisch zurückgezogen, wenn der Dienst gelöscht oder in einen anderen Typ geändert wird.

Beispielaufruf:

 cd cloud-controller-manager/cmd/digitalocean-cloud-controller-manager
DO_ACCESS_TOKEN= < your_access_token >                           
PUBLIC_ACCESS_FIREWALL_NAME=firewall_name                     
PUBLIC_ACCESS_FIREWALL_TAGS=worker-droplet                    
digitalocean-cloud-controller-manager                         
  --kubeconfig < path to your kubeconfig file >                 
  --leader-elect=false --v=5 --cloud-provider=digitalocean

Die Variable PUBLIC_ACCESS_FIREWALL_NAME -Umgebung definiert den Namen der Firewall. Die Firewall wird erstellt, wenn keine Firewall mit diesem Namen gefunden wird.

Die Umgebungsvariable für PUBLIC_ACCESS_FIREWALL_TAGS bezieht sich auf die mit den Tröpfchen zugeordneten Tags, für die die Firewall gelten sollte. Normalerweise ist dies ein Tag, das an die Arbeiterknotentröpfchen angeschlossen ist. Mehrere Tags werden logisch oder modisch angewendet.

In einigen Fällen ist das Firewall -Management für einen bestimmten Dienst möglicherweise nicht wünschenswert. Ein Beispiel ist, dass ein Nodeport nur über den VPC zugänglich sein soll. In solchen Fällen kann die Service-Annotation kubernetes.digitalocean.com/firewall-managed verwendet werden, um einen bestimmten Service von Firewall Management selektiv auszuschließen. Wenn auf "false" festgelegt wird, werden für den Dienst keine eingehenden Regeln erstellt, wodurch der öffentliche Zugriff auf den Nodeport effektiv deaktiviert wird. (Beachten Sie die Anführungszeichen, die in "booleschen" Annotationswerte enthalten sein müssen.) Das Standardverhalten gilt, wenn die Annotation weggelassen wird, auf "true " eingestellt ist oder einen ungültigen Wert enthält.

Es wird keine Firewall verwaltet, wenn die Umgebungsvariablen fehlen oder leer bleiben. Sobald die Firewall erstellt wurde, ist kein anderer öffentlicher Zugang als auf die Nodeports zulässig. Benutzer sollten zusätzliche Firewalls erstellen, um den Zugriff weiter zu erweitern.

Enthüllen Sie Prometheus -Metriken

Wenn Sie daran interessiert sind, Prometheus -Metriken aufzudecken, können Sie einen Metrikenendpunkt übergeben, der sie enthüllt. Der Befehl sieht dem ähnlich aus:

 cd cloud-controller-manager/cmd/digitalocean-cloud-controller-manager
DO_ACCESS_TOKEN=your_access_token                  
METRICS_ADDR= < host > : < port >                         
digitalocean-cloud-controller-manager              
  --kubeconfig < path to your kubeconfig file >      
  --leader-elect=false --v=5 --cloud-provider=digitalocean

Die Variable der METRICS_ADDR -Umgebungsvariablen nimmt einen gültigen Endpunkt an, den Sie verwenden möchten, um Ihre Prometheus -Metriken zu dienen. Um gültig zu sein, sollte es im Formular <host>:<port> sein.

Nachdem Sie digitalocean-cloud-controller-manager gestartet haben, führen Sie den folgenden Curl-Befehl aus, um die Ausgabe von Prometheus-Metriken anzuzeigen:

curl < host > : < port > /metrics

Zulassungsserver

Der Zulassungsserver ist eine optionale Komponente, die darauf abzielt, schlechte Konfigurationsänderungen für DE -verwaltete Objekte (LBS usw.) zu reduzieren. Wenn Sie mehr darüber erfahren möchten, lesen Sie die Dokumente.

Beschränken Sie die API -Rate

Die API -Verwendung unterliegt bestimmten Ratengrenzen. Um sich vor dem Auslaufen der Quoten für extrem starke regelmäßige Verwendung oder pathologische Fälle zu schützen (z. B. Fehler oder API-Thrashing aufgrund eines störenden Controllers von Drittanbietern), kann eine benutzerdefinierte Ratenlimit über die Umgebungsvariable der Umgebungsvariable DO_API_RATE_LIMIT_QPS konfiguriert werden. Es akzeptiert einen Float -Wert, z. B. DO_API_RATE_LIMIT_QPS=3.5 um die API -Verwendung auf 3.5 Abfragen pro Sekunde zu beschränken.

Behälter ausgeführt

Wenn Sie Ihre Änderungen in einer Containerumgebung testen möchten, erstellen Sie ein neues Bild mit der auf dev festgelegten Version:

VERSION=dev make publish

Dadurch wird ein Binärdatum mit Versions- dev und Docker-Image erstellt, das auf digitalocean/digitalocean-cloud-controller-manager:dev gedrückt wird.

Veröffentlichen Sie eine neue Version

Update GO und Abhängigkeiten

1. Update GO -Abhängigkeiten

   go get -u ./...
   go mod tidy
   go mod vendor

2. Update GO -Version zur neuesten GA -Version

Github -Aktion (bevorzugt)

Um das Docker -Bild zu erstellen und die Manifeste zu generieren, gehen Sie zur Seite Aktionen auf GitHub und klicken Sie auf "Workflow ausführen". Geben Sie den GitHub <tag> an, den Sie erstellen möchten, und stellen Sie sicher, dass es mit einem v vorangestellt ist. Wenn Sie den Workflow ausführen, müssen Sie außerdem vorübergehend "eine Pull -Anfrage veranlassen Vergessen Sie nicht, es wieder einzuschalten, sobald die Veröffentlichung fertig ist!

Der Workflow macht Folgendes aus:

• Läufe make bump-version mit <tag>
• Erstellt die CCM -verwandte Manifestdatei als <tag>.yaml
• Verpflichtet sich die Manifestdatei unter releases/ Verzeichnis im Repo
• Erstellt die Veröffentlichung und taggt den neuen Commit mit dem angegebenen <tag> , wenn der Workflow ausgelöst wird
• Melden Sie sich mit DockerHub -Anmeldeinformationen an, die als Geheimnisse angegeben sind
• Erstellt das Docker Image digitalocean/digitalocean-cloud-controller-manager:<tag>
• Pusht digitalocean/digitalocean-cloud-controller-manager:<tag> to dockerHub

Handbuch (veraltet)

Hinweis: Dieser Workflow ist veraltet. Bitte bevorzugen Sie den oben beschriebenen GitHub -Aktion -Workflow.

Um eine neue Version manuell zu veröffentlichen, stoßen Sie zunächst die Version an:

make NEW_VERSION=v1.0.0 bump-version

Stellen Sie sicher, dass alles gut aussieht. Erstellen Sie einen neuen Zweig mit allen Änderungen:

git checkout -b release- < new version > origin/master
git commit -a -v
git push origin release- < new version >

Nachdem es zusammengeführt wird, um zu meistern, markieren Sie das Commit und schieben Sie es:

git checkout master
git pull
git tag < new version >
git push origin < new version >

Erstellen Sie schließlich eine GitHub -Version von Master mit der neuen Version und veröffentlichen Sie sie:

make publish

Dadurch wird ein binäres Binärer mit der neuen Version zusammengestellt, die in einem Docker-Bild gebündelt ist, das auf digitalocean/digitalocean-cloud-controller-manager:<new version>

Beitragen

Bei Digitalocean schätzen und lieben wir unsere Community! Wenn Sie Probleme haben oder einen Beitrag leisten möchten, können Sie ein Problem/PR und einen der folgenden Wartenden eröffnen.