3fcf279cfb
This branch includes a rollup series of commits from a fork of the kubernetes repository pre 1.5 release because we didn't make the code freeze. This additional effort has been fully tested and has results submit into the gubernator to enhance confidence in this code quality vs. the single layer, posing as both master/node. To reference the gubernator results, please see: https://k8s-gubernator.appspot.com/builds/canonical-kubernetes-tests/logs/kubernetes-gce-e2e-node/ Apologies in advance for the large commit, however we did not want to submit without having successful upstream automated testing results. This commit includes: - Support for CNI networking plugins - Support for durable storage provided by ceph - Building from upstream templates (read: kubedns - no more template drift!) - An e2e charm-layer to make running validation tests much simpler/repeatable - Changes to support the 1.5.x series of kubernetes Additional note: We will be targeting -all- future work against upstream so large pull requests of this magnitude will not occur again.
Kubernetes Worker
Usage
This charm deploys a container runtime, and additionally stands up the Kubernetes worker applications: kubelet, and kube-proxy.
In order for this charm to be useful, it should be deployed with its companion charm kubernetes-master and linked with an SDN-Plugin.
This charm has also been bundled up for your convenience so you can skip the above steps, and deploy it with a single command:
juju deploy canonical-kubernetes
For more information about Canonical Kubernetes
consult the bundle README.md file.
Scale out
To add additional compute capacity to your Kubernetes workers, you may
juju add-unit scale the cluster of applications. They will automatically
join any related kubernetes-master, and enlist themselves as ready once the
deployment is complete.
Operational actions
The kubernetes-worker charm supports the following Operational Actions:
Pause
Pausing the workload enables administrators to both drain and cordon a unit for maintenance.
Resume
Resuming the workload will uncordon a paused unit. Workloads will automatically migrate unless otherwise directed via their application declaration.
Known Limitations
Kubernetes workers currently only support 'phaux' HA scenarios. Even when configured with an HA cluster string, they will only ever contact the first unit in the cluster map. To enalbe a proper HA story, kubernetes-worker units are encouraged to proxy through a kubeapi-load-balancer application. This enables a HA deployment without the need to re-render configuration and disrupt the worker services.
External access to pods must be performed through a Kubernetes Ingress Resource. More information