digitalocean cloud controller manager
v0.1.56
digitalocean-cloud-controller-manager est l'implémentation de Kubernetes Cloud Controller Manager pour DigitalOcean. En savoir plus sur les gestionnaires de contrôleur de cloud ici. L'exécution de digitalocean-cloud-controller-manager vous permet de tirer parti de nombreuses fonctionnalités du fournisseur de cloud proposées par DigitalOcean sur vos clusters Kubernetes.
Cloud Controller Manager suit le versioning sémantique. Bien que la version soit toujours inférieure à la V1, le projet est considéré comme prêt pour la production.
En raison des cycles de sortie Fast Kubernetes, CCM (Cloud Controller Manager) ne prendra en charge que la version qui est également prise en charge sur le produit DigitalOcean Kubernetes. Toute autre communication ne sera pas officiellement soutenue par nous.
En savoir plus sur l'exécution de DigitalOcean Cloud Controller Manager ici!
Notez que ce CCM est installé par défaut sur DOKS (DigitalOcean Managed Kubernetes), vous n'avez pas à le faire vous-même.
Voici quelques exemples de la façon dont vous pouvez tirer parti digitalocean-cloud-controller-manager :
Lorsque vous créez des balanciers de charge via CCM (via les services Typed LoadBalancer ), il est très important que vous ne deviez pas modifier manuellement la configuration DO Load-Balancer. De tels changements seront éventuellement revenus par la boucle de réconciliation intégrée au CCM. Il existe une exception dans le nom de chargeur de chargement qui peut être modifiée (voir également la documentation sur les annotations d'identification de chargeur de chargement).
En dehors de cela, le seul endroit sûr pour apporter des modifications à la configuration de l'électricité est via l'objet de service.
Pour des raisons techniques, les ports 50053, 50054 et 50055 ne peuvent pas être utilisés comme ports d'entrée de chargeur de charge (c'est-à-dire le port sur lequel le balancer de chargement écoute pour les demandes). Essayer d'utiliser l'un des ports affectés comme un port de service provoque un port d'entrée 422 est retourné par l'erreur HTTP non valide par l'API DO (et a fait surface en tant qu'événement Kubernetes).
La solution consiste à changer le port de service en autre et non conflictuel.
v1.17.x Ce projet utilise des modules GO pour la gestion des dépendances et utilise le vendeur. Veuillez vous assurer d'exécuter make vendor après toutes les modifications de dépendance.
Après avoir modifié votre code, exécutez les tests et les vérifications CI:
make ci Si vous souhaitez exécuter digitalocean-cloud-controller-manager localement contre un cluster particulier, gardez votre kubeconfig prêt et démarrez le binaire dans le répertoire principal de package comme celui-ci:
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 La variable de l'environnement REGION prend une région numérique valide. Il peut être défini pour empêcher digitalocean-cloud-controller-manager d'essayer d'accéder au service DigitalOcean Metadata qui n'est disponible que sur des gouttelettes. Si la variable de région est définie, le service DO Régions sera utilisé pour valider la région spécifiée. Il peut également être défini à des fins de développement local. Dans l'ensemble, la région que vous choisissez ne devrait pas avoir beaucoup d'importance tant que vous en choisissez une.
Vous devrez peut-être également fournir votre jeton d'accès DigitalOcean dans la variable d'environnement DO_ACCESS_TOKEN . Le jeton n'a pas besoin d'être valide pour que le contrôleur cloud commence, mais dans ce cas, vous ne pourrez pas valider l'intégration avec l'API DigitalOcean.
Veuillez noter que si vous utilisez un cluster Kubernetes créé sur DigitalOcean, il y aura déjà un gestionnaire de contrôleur cloud exécutant dans le cluster, donc votre local concurrencera l'accès à l'API avec lui.
Vous pouvez faire gérer digitalocean-cloud-controller-manager un pare-feu DigitalOcean qui ajustera dynamiquement les règles pour accéder à Nodeports: une fois qu'un service de type NodePort sera créé, le contrôleur de pare-feu mettra à jour le pare-feu pour permettre un accès au public à cette nodeport. De même, l'accès est automatiquement rétracté si le service est supprimé ou changé en un type différent.
Exemple d'invocation:
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 La variable d'environnement PUBLIC_ACCESS_FIREWALL_NAME définit le nom du pare-feu. Le pare-feu est créé si aucun pare-feu par ce nom n'est trouvé.
La variable d'environnement PUBLIC_ACCESS_FIREWALL_TAGS fait référence aux balises associées aux gouttelettes auxquelles le pare-feu doit s'appliquer. Habituellement, il s'agit d'une balise attachée aux gouttelettes de nœud de travail. Plusieurs balises sont appliquées de manière logique ou de manière.
Dans certains cas, la gestion du pare-feu pour un service particulier peut ne pas être souhaitable. Un exemple est qu'un nodeport est censé être accessible sur le VPC uniquement. Dans de tels cas, l'annotation du service kubernetes.digitalocean.com/firewall-managed peut être utilisée pour exclure sélectivement un service donné de la gestion du pare-feu. S'il est défini sur "false" , aucune règle entrante ne sera créée pour le service, désactivant efficacement l'accès public au Nodeport. (Remarquez les devis qui doivent être inclus avec les valeurs d'annotation "booléen".) Le comportement par défaut s'applique si l'annotation est omise, est définie sur "true ", ou contient une valeur non valide.
Aucun pare-feu n'est géré si les variables d'environnement sont manquantes ou laissées vides. Une fois le pare-feu créé, aucun accès public autre que les Nodeports n'est autorisé. Les utilisateurs doivent créer des pare-feu supplémentaires pour prolonger davantage l'accès.
Si vous êtes intéressé à exposer les mesures de Prometheus, vous pouvez passer dans un point de terminaison de mesures qui les exposera. La commande ressemblera à ceci:
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 La variable d'environnement METRICS_ADDR prend un point de terminaison valide que vous souhaitez utiliser pour servir vos métriques Prometheus. Pour être valide, il devrait être dans le formulaire <host>:<port> .
Après avoir démarré digitalocean-cloud-controller-manager , exécutez la commande Curl suivante pour afficher la sortie de métriques Prometheus:
curl < host > : < port > /metricsLe serveur d'admission est un composant facultatif visant à réduire les modifications de configuration mauvaises pour les objets gérés DO (LBS, etc.). Si vous voulez en savoir plus, lisez les documents.
L'utilisation de l'API est soumise à certaines limites de taux. Afin de se protéger contre la manquage du quota pour des cas d'utilisation régulière extrêmement lourds ou des cas pathologiques (par exemple, les bogues ou la battement d'API en raison d'un contrôleur tiers interférant), une limite de débit personnalisée peut être configurée via la variable d'environnement DO_API_RATE_LIMIT_QPS . Il accepte une valeur flottante, par exemple, DO_API_RATE_LIMIT_QPS=3.5 pour restreindre l'utilisation de l'API à 3,5 requêtes par seconde.
Si vous souhaitez tester vos modifications dans un environnement conteneurisé, créez une nouvelle image avec la version définie sur dev :
VERSION=dev make publish Cela créera un binaire avec la version dev et Docker Image poussés vers digitalocean/digitalocean-cloud-controller-manager:dev .
go get -u ./...
go mod tidy
go mod vendor Pour créer l'image Docker et générer les manifestes, accédez à la page Actions sur GitHub et cliquez sur "Exécuter Workflow". Spécifiez le github <tag> que vous souhaitez créer, en vous assurant qu'il est préfixé avec un v L'exécution du workflow nécessite également que vous désactivez temporairement "Exiger une demande de traction avant de fusionner" Paramètres dans les paramètres des règles de protection de la branche maître. N'oubliez pas de le réactiver une fois la version terminée!
Le workflow fait ce qui suit:
make bump-version avec <tag><tag>.yamlreleases/ répertoire dans le repo<tag> spécifié lorsque le flux de travail est déclenchédigitalocean/digitalocean-cloud-controller-manager:<tag>digitalocean/digitalocean-cloud-controller-manager:<tag> à DockerHubRemarque: Ce flux de travail est obsolète, veuillez préférer le flux de travail GitHub Action décrit ci-dessus.
Pour publier manuellement une nouvelle version, bosse d'abord la version:
make NEW_VERSION=v1.0.0 bump-versionAssurez-vous que tout semble bon. Créez une nouvelle branche avec tous les changements:
git checkout -b release- < new version > origin/master
git commit -a -v
git push origin release- < new version >Une fois qu'il a fusionné pour maîtriser, étiqueter l'engagement et le pousser:
git checkout master
git pull
git tag < new version >
git push origin < new version >Enfin, créez une version github de Master avec la nouvelle version et publiez-la:
make publish Cela compilera un binaire contenant la nouvelle version regroupée dans une image Docker poussée vers digitalocean/digitalocean-cloud-controller-manager:<new version>
Chez DigitalOcean, nous apprécions et aimons notre communauté! Si vous avez des problèmes ou si vous souhaitez contribuer, n'hésitez pas à ouvrir un problème / PR et CC l'un des mainteneurs ci-dessous.
