Kubernetes is an open-source platform for deploying, scaling, and operations
of application containers across a cluster of hosts. Kubernetes is portable
in that it works with public, private, and hybrid clouds. Extensible through
a pluggable infrastructure. Self healing in that it will automatically
restart and place containers on healthy nodes if a node ever goes away.
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
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
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.
The kubernetes-worker charm supports the following Operational Actions:
Resuming the workload will uncordon a paused unit. Workloads will automatically migrate unless otherwise directed via their application declaration.
With the "registry" action that is part for the kubernetes-worker charm, you can very easily create a private docker registry, with authentication, and available over TLS. Please note that the registry deployed with the action is not HA, and uses storage tied to the kubernetes node where the pod is running. So if the registry pod changes is migrated from one node to another for whatever reason, you will need to re-publish the images.
Create the relevant authentication files. Let's say you want user
userA to authenticate with the password
passwordA. Then you'll do :
echo "userA:passwordA" > htpasswd-plain htpasswd -c -b -B htpasswd userA passwordA
htpasswd program comes with the
Supposing your registry will be reachable at
myregistry.company.com, and that you already have your TLS key in the
registry.key file, and your TLS certificate (with
myregistry.company.com as Common Name) in the
registry.crt file, you would then run :
juju run-action kubernetes-worker/0 registry domain=myregistry.company.com htpasswd="$(base64 -w0 htpasswd)" htpasswd-plain="$(base64 -w0 htpasswd-plain)" tlscert="$(base64 -w0 registry.crt)" tlskey="$(base64 -w0 registry.key)" ingress=true
If you then decide that you want do delete the registry, just run :
juju run-action kubernetes-worker/0 registry delete=true ingress=true
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 enable 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
When using NodePort type networking, there is no automation in exposing the
ports selected by kubernetes or chosen by the user. They will need to be
opened manually and can be performed across an entire worker pool.
If your NodePort service port selected is
30510 you can open this across all
members of a worker pool named
kubernetes-worker like so:
juju run --application kubernetes-worker open-port 30510/tcp
Don't forget to expose the kubernetes-worker application if its not already
exposed, as this can cause confusion once the port has been opened and the
service is not reachable.
Note: When debugging connection issues with NodePort services, its important
to first check the kube-proxy service on the worker units. If kube-proxy is not
running, the associated port-mapping will not be configured in the iptables
If you need to close the NodePort once a workload has been terminated, you can
follow the same steps inversely.
juju run --application kubernetes-worker close-port 30510
A comma-separated list of nagios servicegroups. If left empty, the nagios_context will be used as the servicegroup
Deploy the default http backend and ingress controller to handle ingress requests.
URL to use for HTTP_PROXY to be used by Docker. Only useful in closed environments where a proxy is the only option for routing to the registry to pull images
When true, worker services will not be upgraded until the user triggers it manually by running the upgrade action.
Comma-separated list of destinations (either domain names or IP addresses) that should be directly accessed, by opposition of going through the proxy defined above.
Allow privileged containers to run on worker nodes. Supported values are "true", "false", and "auto". If "true", kubelet will run in privileged mode by default. If "false", kubelet will never run in privileged mode. If "auto", kubelet will not run in privileged mode by default, but will switch to privileged mode if gpu hardware is detected.
HTTP/HTTPS web proxy for Snappy to use when accessing the snap store.
Labels can be used to organize and to select subsets of nodes in the cluster. Declare node labels in key=value format, separated by spaces.
URL to use for HTTPS_PROXY to be used by Docker. Only useful in closed environments where a proxy is the only option for routing to the registry to pull images
Used by the nrpe subordinate charms. A string that will be prepended to instance name to set the host name in nagios. So for instance the hostname would be something like: juju-myservice-0 If you're running multiple environments with the same services in them this allows you to differentiate between them.
Extra options to pass to the docker daemon. e.g. --insecure-registry
Enable GRUB cgroup overrides cgroup_enable=memory swapaccount=1. WARNING changing this option will reboot the host - use with caution on production services
Snap channel to install Kubernetes worker services from