digitalocean cloud controller manager
v0.1.56
digitalocean-cloud-controller-manager es la implementación del administrador de controlador de la nube Kubernetes para DigitalOcean. Lea más sobre los gerentes de controladores en la nube aquí. La ejecución de digitalocean-cloud-controller-manager le permite aprovechar muchas de las características del proveedor de la nube ofrecidas por Digitalocean en sus grupos de Kubernetes.
Cloud Controller Manager sigue el versículo semántico. Aunque la versión todavía está por debajo de V1, el proyecto se considera listo para la producción.
Debido a los rápidos ciclos de lanzamiento de Kubernetes, CCM (Cloud Controller Manager) solo admitirá la versión que también es compatible con el producto Digitalocean Kubernetes. Cualquier otro lanzamiento no será oficialmente respaldado por nosotros.
¡Obtenga más información sobre cómo ejecutar DigitalOcean Cloud Controller Manager aquí!
Tenga en cuenta que este CCM está instalado de forma predeterminada en DOKS (Kubernetes administrados por DigitalOcean), no tiene que hacerlo usted mismo.
Aquí hay algunos ejemplos de cómo podría aprovechar digitalocean-cloud-controller-manager :
Cuando está creando equilibradores de carga a través de CCM (a través de servicios de tipo LoadBalancer ), es muy importante que no cambie la configuración del balancer de carga manual. Tales cambios eventualmente serán revertidos por el bucle de reconciliación integrado en CCM. Hay una excepción en el nombre del equilibrador de carga que se puede cambiar (ver también la documentación sobre anotaciones de ID de equilibrio de carga).
Aparte de eso, el único lugar seguro para hacer cambios de configuración de equilibrio de carga es a través del objeto de servicio.
Por razones técnicas, los puertos 50053, 50054 y 50055 no pueden usarse como puertos de entrada de equilibrio de carga (es decir, el puerto que el balancer de carga escucha para solicitudes). Intentar usar uno de los puertos afectados como puerto de servicio provoca un puerto de entrada 422 es una respuesta de error HTTP no válida para ser devuelto por la API DO (y apareció como un evento de Kubernetes).
La solución es cambiar el puerto de servicio a uno diferente y no conflictivo.
v1.17.x Este proyecto utiliza módulos GO para la gestión de dependencias y emplea el proveedor. Asegúrese de ejecutar make vendor después de cualquier modificación de dependencia.
Después de hacer cambios en su código, ejecute las pruebas y las verificaciones de CI:
make ci Si desea ejecutar digitalocean-cloud-controller-manager localmente contra un clúster en particular, mantenga su KubeConfig listo e inicie el binario en el directorio principal alojado en el paquete como este:
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 entorno REGION toma una región de Digitalocean válida. Se puede configurar para evitar que digitalocean-cloud-controller-manager intente acceder al servicio de metadatos de Digitalocean que solo está disponible en gotas. Si se establece la variable de región, entonces el servicio DO Regions se utilizará para validar la región especificada. También se puede establecer para fines de desarrollo local. En general, qué región elige no debe importar mucho siempre que elija una.
También es posible que deba proporcionar su token de acceso DigitalOcean en la variable de entorno DO_ACCESS_TOKEN . El token no necesita ser válido para que el controlador de la nube comience, pero en ese caso, no podrá validar la integración con la API de Digitalocean.
Tenga en cuenta que si usa un clúster Kubernetes creado en DigitalOcean, ya habrá un administrador de controladores de nube que se ejecuta en el clúster, por lo que su local competirá por el acceso de API con él.
Puede hacer que digitalocean-cloud-controller-manager administre un firewall de DigitalOcean que ajustará dinámicamente las reglas para acceder a Nodeports: una vez que se cree un servicio de tipo NodePort , el controlador de firewall actualizará el firewall a público permitir el acceso solo a ese nodeport. Del mismo modo, el acceso se retrae automáticamente si el servicio se elimina o cambia a un tipo diferente.
Ejemplo de invocación:
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 de entorno PUBLIC_ACCESS_FIREWALL_NAME define el nombre del firewall. El firewall se crea si no se encuentra el firewall con ese nombre.
La variable de entorno PUBLIC_ACCESS_FIREWALL_TAGS se refiere a las etiquetas asociadas con las gotas a las que debe aplicarse el firewall. Por lo general, esta es una etiqueta adjunta a las gotas de nodo del trabajador. Múltiples etiquetas se aplican de manera lógica o de moda.
En algunos casos, la gestión de firewall para un servicio en particular puede no ser deseable. Un ejemplo es que se supone que un nodeport es accesible solo en el VPC. En tales casos, la anotación de servicio kubernetes.digitalocean.com/firewall-managed puede usarse para excluir selectivamente un servicio dado de la administración de firewall. Si se establece en "false" , no se crearán reglas de entrada para el Servicio, deshabilitando efectivamente el acceso público a Nodeport. (Tenga en cuenta las citas que deben incluirse con los valores de anotación "booleanos"). El comportamiento predeterminado se aplica si se omite la anotación, se establece en "true " o contiene un valor no válido.
No se gestiona ningún firewall si faltan las variables de entorno o se dejan vacías. Una vez que se crea el firewall, no se permite el acceso público que no sea Nodeports. Los usuarios deben crear firewalls adicionales para extender aún más el acceso.
Si está interesado en exponer las métricas de Prometheus, puede pasar un punto final de métricas que las expondrá. El comando se verá similar a esto:
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 de entorno METRICS_ADDR toma un punto final válido que desea usar para servir a sus métricas Prometheus. Para ser válido, debe estar en el formulario <host>:<port> .
Después de haber comenzado digitalocean-cloud-controller-manager , ejecute el siguiente comando CURL para ver la salida de las métricas Prometheus:
curl < host > : < port > /metricsEl servidor de admisión es un componente opcional con el objetivo de reducir los cambios de configuración malos para los objetos administrados DO (LBS, etc.). Si desea saber más al respecto, lea los documentos.
El uso de la API está sujeto a ciertos límites de tasa. Para protegerse contra la cuota para un uso regular extremadamente pesado o casos patológicos (p. Ej., Bugs o API, debido a un controlador de terceros interferente), se puede configurar un límite de velocidad personalizado a través de la variable de entorno DO_API_RATE_LIMIT_QPS . Acepta un valor flotante, por ejemplo, DO_API_RATE_LIMIT_QPS=3.5 para restringir el uso de API a 3.5 consultas por segundo.
Si desea probar sus cambios en un entorno contenedorizado, cree una nueva imagen con la versión establecida en dev :
VERSION=dev make publish Esto creará un binario con la versión dev y Docker Image empujada a digitalocean/digitalocean-cloud-controller-manager:dev .
go get -u ./...
go mod tidy
go mod vendor Para crear la imagen de Docker y generar los manifiestos, vaya a la página de Acciones en GitHub y haga clic en "Ejecutar el flujo de trabajo". Especifique el github <tag> que desea crear, asegurándose de que esté prefijado con una v Ejecutar el flujo de trabajo también requiere que apague temporalmente "requiere una solicitud de extracción antes de fusionar" configuración en la configuración de las reglas de protección de la rama maestra. ¡No olvides volver a encenderlo una vez que termine el lanzamiento!
El flujo de trabajo hace lo siguiente:
make bump-version con <tag><tag>.yamlreleases/ directorio en el repositorio<tag> especificada cuando se activa el flujo de trabajodigitalocean/digitalocean-cloud-controller-manager:<tag>digitalocean/digitalocean-cloud-controller-manager:<tag> a DockerHubNota: Este flujo de trabajo está en desuso, prefiera el flujo de trabajo de acción GitHub descrito anteriormente.
Para lanzar manualmente una nueva versión, primero aumente la versión:
make NEW_VERSION=v1.0.0 bump-versionAsegúrate de que todo se vea bien. Cree una nueva rama con todos los cambios:
git checkout -b release- < new version > origin/master
git commit -a -v
git push origin release- < new version >Después de que se fusione para dominar, etiquete la confirmación y presione:
git checkout master
git pull
git tag < new version >
git push origin < new version >Finalmente, cree un lanzamiento de GitHub con la nueva versión y publíquelo:
make publish Esto compilará un binario que contiene la nueva versión incluida en una imagen de Docker presionado a digitalocean/digitalocean-cloud-controller-manager:<new version>
¡En Digitalocean valoramos y amamos a nuestra comunidad! Si tiene algún problema o desea contribuir, no dude en abrir un problema/PR y CC, cualquiera de los mantenedores a continuación.
