With Clocker, you can easily deploy and manage Kubernetes clusters. They are production-ready infrastructure with TLS, high-availability and extensions like Flannel, Calico and Canal for networking.
Can also connect to existing infrastructure provisioned and managed externally, by specifying appropriate API endpoints.
The Kubernetes entity that comes with Clocker will deploy and manage the following components:
This Kubernetes cluster contains a manager and a configurable number of workers. It requires a pre-existing discovery mechanism and references to a CA server entity. The cluster has an AutoScalerPolicy and will scale up due to high CPU usage. It also has a replacer policy that will detect the failure and replace the failed worker.
Used as a discovery backend for the Kubernetes cluster.
This is used to provide TLS certificates for the Kubernetes cluster. This component is designed to be easily replaced. It is strongly recommended that this component is replaced with a production grade CA server of your choice.
Clocker currently supports deployments to CentOS only. We recommend to setup a location with the following setting:
If you are using Brooklyn, it might a good idea to increase the entropy of your server. This would prevent installation speed being slowed. For more information, see Entropy Troubleshooting
Finally, be aware that you might get in trouble because of your cloud provider’s security group. For more information, please see the troubleshooting page.
The Kubernetes entity comes with built-in configuration that allows you to control how your Kubernetes cluster will be deployed and manage.
There is auto-scaling functionality included with a deployed Kubernetes cluster by default. There is currently no option to scale down. There are some configuration options that control how the scale is performed:
|kubernetes.initial.size||The initial size of the Kubernetes cluster|
|kubernetes.max.size||Maximum size the Kubernetes cluster can be scaled to|
|kubernetes.scaling.cpu.limit||The percentage limit at which we should scale up. This should be a double value between 0.00 and 1.00|
|etcd.initial.size||The initial size of Etcd cluster|
The Kubernetes cluster is automatically setup with an overlay network. This network can be used by containers deployed to the Kubernetes cluster to communicate. There are some configuration options that control networking:
|kubernetes.pod.cidr||Pod IP Range to use for the Kubernetes cluster|
|kubernetes.service.cidr||Kubernetes Service IP Range|
|kubernetes.apiserver.port||Kubernetes API Server Port|
|kubernetes.dns.address||Kubernetes DNS IP|
|kubernetes.dns.domain||Kubernetes DNS Domain|
There are some configuration options that control Kubernetes specific parts:
|kubernetes.version||Version of Kubernetes to use|
|kubernetes.cluster.name||Name of the Kubernetes cluster|
For any problems please consult the troubleshooting section here.