| commit | 1a5c9b6068b7241f8a7e19fe2a53995ab6e595c3 | [log] [tgz] |
|---|---|---|
| author | Gregor Riepl <Gregor.Riepl@swisstxt.ch> | Fri Mar 01 11:50:25 2019 +0100 |
| committer | GitHub <noreply@github.com> | Fri Mar 01 11:50:25 2019 +0100 |
| tree | a01de1793df943b25ecdcdd7c89bd51b19fea4dd | |
| parent | ed4c118fe04cedd567118c43d660ee65021998d8 [diff] |
Improved documentation
A Cloud Controller Manager to facilitate Kubernetes deployments on Cloudstack.
Based on the old Cloudstack provider in Kubernetes that will be removed soon.
There are several notable differences to the old Kubernetes CloudStack cloud provider that need to be taken into account when migrating to the standalone controller.
Load balancer rule names now include the protocol in addition to the LB name and service port. This was added to distinguish tcp, udp and tcp-proxy services operating on the same port. Without this change, it would not be possible to map a service that runs on both TCP and UDP port 8000, for example.
:warning: If you have existing rules, remove them before the migration, and add them back afterwards.
If you don‘t do this, you will end up with duplicate rules for the same service, which won’t work.
When kubelet still contained cloud provider code, node metadata was fetched from the DHCP server running on the Virtual Router.
This is no longer possible with the standalone cloud controller, so all metadata now comes from the Cloudstack API. Some metadata may be missing or wrong, please file bugs when this happens to you.
It is recommended to launch kubelet with the following parameter:
--register-with-taints=node.cloudprovider.kubernetes.io/uninitialized=true:NoSchedule
This will treat the node as ‘uninitialized’ and cause the CCM to apply metadata labels from CloudStack automatically.
Supported labels are:
It is also possible to trigger this process manually by issuing the following command:
kubectl taint nodes <my-node-without-labels> node.cloudprovider.kubernetes.io/uninitialized=true:NoSchedule
All dependencies are vendored. You need GNU make, git and Go 1.11 to build cloudstack-ccm.
It's still possible to build with Go 1.10, but you need to remove the option -mod vendor from the cloudstack-ccm compilation target in the Makefile.
go get github.com/swisstxt/cloudstack-cloud-controller-manager cd ${GOPATH}/src/github.com/swisstxt/cloudstack-cloud-controller-manager make
To build the cloudstack-cloud-controller-manager container, please use the provided Docker file:
docker build . -t swisstxt/cloudstack-cloud-controller-manager:latest
Prebuilt containers are posted on Docker Hub.
If you intend to deploy the CCM in a Kubernetes cluster, please see deployment.yaml for an example configuration. The comments explain how to configure Cloudstack API access.
This CCM supports TCP, UDP and TCP-Proxy LoadBalancer deployments.
For UDP and Proxy Protocol support, CloudStack 4.6 or later is required.
Since kube-proxy does not support the Proxy Protocol or UDP, you should connect this directly to containers, for example by deploying a DaemonSet and setting hostNetwork: true.
See service.yaml for an example Service deployment and part of a suitable configuration for an ingress controller.
You need a local instance of the CloudStack Management Server or a ‘real’ one to connect to. The CCM supports the same cloudstack.ini configuration file format used by the cs tool, so you can simply point it to that.
./cloudstack-ccm --cloud-provider external-cloudstack --cloud-config ~/.cloudstack.ini --master k8s-apiserver
Replace k8s-apiserver with the host name of your Kubernetes development clusters's API server.
If you don't have a ‘real’ CloudStack installation, you can also launch a local simulator instance instead. This is very useful for dry-run testing.
© 2018 SWISS TXT AG and the Kubernetes authors.
See LICENSE-2.0 for permitted usage.