digitalocean-cloud-controller-manager is the Kubernetes cloud controller manager implementation for DigitalOcean. Read more about cloud controller managers here. Running digitalocean-cloud-controller-manager allows you to leverage many of the cloud provider features offered by DigitalOcean on your kubernetes clusters.
WARNING: this project is a work in progress and may not be production ready.
At the current state of Kubernetes, running cloud controller manager requires a few things. Please read through the requirements carefully as they are critical to running cloud controller manager on a Kubernetes cluster on DigtialOcean.
These are the recommended versions to run the cloud controller manager based on your Kubernetes version
- Use CCM versions <= v0.1.1 if you're running Kubernetes version v1.7
- Use CCM versions >= v0.1.2 if you're running Kubernetes version v1.8
- Use CCM versions >= v0.1.4 if you're running Kubernetes version v1.9 - v1.10
- Use CCM versions >= v0.1.5 if you're running Kubernetes version >= v1.10
All kubelets in your cluster MUST set the flag --cloud-provider=external. kube-apiserver and kube-controller-manager must NOT set the flag --cloud-provider which will default them to use no cloud provider natively.
WARNING: setting --cloud-provider=external will taint all nodes in a cluster with node.cloudprovider.kubernetes.io/uninitialized, it is the responsibility of cloud controller managers to untaint those nodes once it has finished initializing them. This means that most pods will be left unscheduable until the cloud controller manager is running.
In the future, --cloud-provider=external will be the default. Learn more about the future of cloud providers in Kubernetes here.
By default, the kubelet will name nodes based on the node's hostname. On DigitalOcean, node hostnames are set based on the name of the droplet. If you decide to override the hostname on kubelets with --hostname-override, this will also override the node name in Kubernetes. It is important that the node name on Kubernetes matches either the droplet name, private ipv4 ip or the public ipv4 ip, otherwise cloud controller manager cannot find the corresponding droplet to nodes.
When setting the droplet host name as the node name (which is the default), Kubernetes will try to reach the node using its host name. However, this won't work since host names aren't resovable on DO. For example, when you run kubectl logs you will get an error like so:
$ kubectl logs -f mypod
Error from server: Get https://k8s-worker-03:10250/containerLogs/default/mypod/mypod?follow=true: dial tcp: lookup k8s-worker-03 on 67.207.67.3:53: no such host
Since on DigitalOcean the droplet's name is not resolvable, it's important to tell the Kubernetes masters to use another address type to reach its workers. You can do this by setting --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname on the apiserver. Doing this will tell Kubernetes to use a droplet's private IP to connect to the node before attempting it's public IP and then it's host name.
All droplet names in kubernetes must be unique since node names in kubernetes must be unique.
Currently digitalocean-cloud-controller-manager implements:
- nodecontroller - updates nodes with cloud provider specific labels and addresses, also deletes kubernetes nodes when deleted on the cloud provider.
- servicecontroller - responsible for creating LoadBalancers when a service of
Type: LoadBalanceris created in Kubernetes.
In the future, it may implement:
- volumecontroller - responsible for creating, deleting, attaching and detaching DO block storage.
- routecontroller - responsible for creating firewall rules
To run digitalocean-cloud-controller-manager, you need a DigitalOcean personal access token. If you are already logged in, you can create one here. Ensure the token you create has both read and write access. Once you have a personal access token, create a Kubernetes Secret as a way for the cloud controller manager to access your token. You can do this with one of the following methods:
You can use the script scripts/generate-secret.sh in this repo to create the Kubernetes Secret. Note that this will apply changes using your default kubectl context. For example, if your token is abc123abc123abc123, run the following to create the Kubernetes Secret.
export DIGITALOCEAN_ACCESS_TOKEN=abc123abc123abc123
scripts/generate-secret.shCopy releases/secret.yml.tmpl to releases/secret.yml:
cp releases/secret.yml.tmpl releases/secret.ymlReplace the placeholder in the copy with your token. When you're done, the releases/secret.yml should look something like this:
apiVersion: v1
kind: Secret
metadata:
name: digitalocean
namespace: kube-system
stringData:
access-token: "abc123abc123abc123"Finally, run this command from the root of this repo:
kubectl apply -f releases/secret.ymlYou should now see the digitalocean secret in the kube-system namespace along with other secrets
$ kubectl -n kube-system get secrets
NAME TYPE DATA AGE
default-token-jskxx kubernetes.io/service-account-token 3 18h
digitalocean Opaque 1 18hCurrently we only support alpha release of the digitalocean-cloud-controller-manager due to its active development. Run the first alpha release like so
kubectl apply -f releases/v0.1.5.yml
deployment "digitalocean-cloud-controller-manager" createdNOTE: the deployments in releases/ are meant to serve as an example. They will work in a majority of cases but may not work out of the box for your cluster.
Here are some examples of how you could leverage digitalocean-cloud-controller-manager:
At DigitalOcean we value and love our community! If you have any issues or would like to contribute, feel free to open an issue/PR and cc any of the maintainers below.
- Fatih Arslan - @fatih
- Andrew Sy Kim - @andrewsykim