digitalocean cloud controller manager
v0.1.56
digitalocean-cloud-controller-manager é a implementação do Kubernetes Cloud Controller Manager para o Digitalocean. Leia mais sobre os gerentes de controlador de nuvem aqui. A execução digitalocean-cloud-controller-manager permite aproveitar muitos dos recursos do fornecedor de nuvem oferecidos pelo Digitalocean em seus clusters Kubernetes.
O Cloud Controller Manager segue a versão semântica. Embora a versão ainda esteja abaixo da v1, o projeto é considerado pronto para produção.
Devido aos ciclos rápidos de liberação do Kubernetes, o CCM (Cloud Controller Manager) suportará apenas a versão que também é suportada no produto Digitalocean Kubernetes. Quaisquer outros lançamentos não serão oficialmente apoiados por nós.
Saiba mais sobre como executar o Digitalocean Cloud Controller Manager aqui!
Observe que este CCM é instalado por padrão no DOKS (Kubernetes gerenciados pelo Digitalocean), você não precisa fazer isso sozinho.
Aqui estão alguns exemplos de como você pode aproveitar digitalocean-cloud-controller-manager :
Quando você está criando balanceadores de carga através do CCM (via LoadBalancer Typed Services), é muito importante que você não altere a configuração de carga do Balâncias de carga manualmente. Tais mudanças serão revertidas pelo loop de reconciliação incorporado ao CCM. Há uma exceção no nome de carga do balanceador de carga que pode ser alterado (consulte também a documentação sobre anotações de identificação de carga-balanceador).
Fora isso, o único local seguro para fazer alterações na configuração do balanceador de carga é através do objeto de serviço.
Por razões técnicas, as portas 50053, 50054 e 50055 não podem ser usadas como portas de entrada do balanceador de carga (ou seja, a porta que o balanceador de carga ouve para solicitações). Tentar usar uma das portas afetadas, pois uma porta de serviço causa uma porta de entrada de 422 é a resposta de erro HTTP inválida a ser retornada pela API DO (e surgida como um evento Kubernetes).
A solução é alterar a porta de serviço para uma diferente e não conflitadora.
v1.17.x Este projeto usa módulos GO para gerenciamento de dependência e emprega uma vendedora. Certifique -se de executar make vendor após qualquer modificação de dependência.
Depois de fazer as alterações do seu código, execute os testes e as verificações do CI:
make ci Se você deseja executar digitalocean-cloud-controller-manager localmente contra um cluster específico, mantenha seu kubeconfig pronto e inicie o binário no diretório principal hospedado em pacote 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 A variável de ambiente REGION leva uma região digital válida. Ele pode ser definido para impedir que digitalocean-cloud-controller-manager tenta acessar o serviço de metadados digitais, que está disponível apenas em gotículas. Se a variável da região estiver definida, o serviço de regiões DO será usado para validar a região especificada. Também pode ser definido para fins de desenvolvimento local. No geral, qual região você escolhe não deve importar muito, desde que você escolha uma.
Você também pode precisar fornecer ao seu token de acesso digital na variável de ambiente DO_ACCESS_TOKEN . O token não precisa ser válido para o início do controlador de nuvem, mas, nesse caso, você não poderá validar a integração com a API Digitalocean.
Observe que, se você usar um cluster Kubernetes criado no Digitalocean, já haverá um gerenciador de controladores em nuvem em execução no cluster, para que o seu local concorram pelo acesso da API com ele.
Você pode fazer com que digitalocean-cloud-controller-manager gerencia um firewall digitalocean que ajustará dinamicamente as regras para acessar o NodEports: Uma vez que um serviço do tipo NodePort for criado, o controlador do firewall atualizará o firewall para o público permitir o acesso a esse nodeport. Da mesma forma, o acesso é automaticamente retraído se o serviço for excluído ou alterado para um tipo diferente.
Exemplo de invocação:
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 A variável de ambiente PUBLIC_ACCESS_FIREWALL_NAME define o nome do firewall. O firewall é criado se nenhum firewall com esse nome for encontrado.
A variável de ambiente PUBLIC_ACCESS_FIREWALL_TAGS refere -se às tags associadas às gotículas às quais o firewall deve aplicar. Geralmente, esta é uma tag anexada às gotículas do nó do trabalhador. Várias tags são aplicadas de maneira lógica ou moda.
Em alguns casos, o gerenciamento de firewall para um serviço específico pode não ser desejável. Um exemplo é que um Nodeport deve estar acessível apenas no VPC. Nesses casos, a anotação de serviço kubernetes.digitalocean.com/firewall-managed pode ser usada para excluir seletivamente um determinado serviço da Firewall Management. Se definido como "false" , não serão criadas regras de entrada para o serviço, desativando efetivamente o acesso público ao Nodeport. (Observe as cotações que devem ser incluídas nos valores de anotação "booleanos".) O comportamento padrão se aplica se a anotação for omitida, estiver definida como "true " ou contém um valor inválido.
Nenhum firewall é gerenciado se as variáveis de ambiente estiverem ausentes ou deixadas vazias. Depois que o firewall é criado, nenhum acesso público além dos nodeports é permitido. Os usuários devem criar firewalls adicionais para ampliar ainda mais o acesso.
Se você estiver interessado em expor métricas de Prometheus, poderá passar em um terminal de métricas que as expõe. O comando será parecido com isso:
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 A variável de ambiente METRICS_ADDR leva um ponto de extremidade válido que você deseja usar para servir suas métricas de Prometheus. Para ser válido, deve estar no formulário <host>:<port> .
Depois de iniciar digitalocean-cloud-controller-manager , execute o seguinte comando CURL para visualizar a saída das métricas do Prometheus:
curl < host > : < port > /metricsO servidor de admissão é um componente opcional com o objetivo de reduzir alterações ruins de configuração para objetos gerenciados do DO (LBS etc.). Se você quiser saber mais sobre isso, leia os documentos.
O uso da API está sujeito a certos limites de taxa. Para proteger-se contra a operação sem cota para uso regular de uso ou patológico extremamente pesado (por exemplo, bugs ou se debate devido a um controlador de terceiros interferentes), um limite de taxa personalizado pode ser configurado através da variável de ambiente DO_API_RATE_LIMIT_QPS . Ele aceita um valor de flutuação, por exemplo, DO_API_RATE_LIMIT_QPS=3.5 para restringir o uso da API a 3,5 consultas por segundo.
Se você deseja testar suas alterações em um ambiente de contêiner, crie uma nova imagem com a versão definida como dev :
VERSION=dev make publish Isso criará um binário com a imagem dev version e o docker empurrado para digitalocean/digitalocean-cloud-controller-manager:dev .
go get -u ./...
go mod tidy
go mod vendor Para criar a imagem do Docker e gerar os manifestos, vá para a página Ações no GitHub e clique em "Executar fluxo de trabalho". Especifique o github <tag> que você deseja criar, certificando -se de que ele seja prefixado com um v A execução do fluxo de trabalho também exige que você desative temporariamente "exige uma solicitação de tração antes de mesclar" a configuração nas configurações das regras de proteção da filial principal. Não se esqueça de ativá -lo assim que o lançamento terminar!
O fluxo de trabalho faz o seguinte:
make bump-version with <tag><tag>.yamlreleases/ Diretório no Repo<tag> especificado quando o fluxo de trabalho é acionadodigitalocean/digitalocean-cloud-controller-manager:<tag>digitalocean/digitalocean-cloud-controller-manager:<tag> para DockerHubNOTA: Este fluxo de trabalho está preferido, prefira o fluxo de trabalho de ação do GitHub descrito acima.
Para lançar manualmente uma nova versão, primeiro bata na versão:
make NEW_VERSION=v1.0.0 bump-versionVerifique se tudo parece bom. Crie uma nova filial com todas as alterações:
git checkout -b release- < new version > origin/master
git commit -a -v
git push origin release- < new version >Depois de se fundir para dominar, marque o commit e pressione -o:
git checkout master
git pull
git tag < new version >
git push origin < new version >Finalmente, crie um lançamento do GitHub do Master com a nova versão e publique -a:
make publish Isso compilará um binário que contém a nova versão incluída em uma imagem do docker empurrada para digitalocean/digitalocean-cloud-controller-manager:<new version>
Na Digitalocean, valorizamos e amamos nossa comunidade! Se você tiver algum problema ou quiser contribuir, sinta -se à vontade para abrir um problema/PR e CC qualquer um dos mantenedores abaixo.
