This charm is an encapsulation of the Kubernetes control plane processes and related operations to run on any cloud for the entire lifecycle of the cluster.

Deployment

This charm is not fully functional when deployed by itself. It requires other charms to model a complete Kubernetes cluster. A Kubernetes cluster needs a distributed key value store such as Etcd and the kubernetes-worker charm which delivers the Kubernetes node services. Other common requirements include a Software Defined Network (SDN), a Container Runtime such as containerd, and a Transport Layer Security (TLS) provider so the components in a cluster can communicate securely.

Please take a look at the Charmed Kubernetes or the Kubernetes core bundles for examples of complete models of Kubernetes clusters.

Resources

The kubernetes-control-plane charm takes advantage of Juju Resources to deliver core Kubernetes software.

In deployments on public clouds, resources are provided to the charm automatically with no user intervention. Some environments with strict firewall rules may not be able to fetch these directly. In these network restricted environments, local resources can be uploaded to the model by the Juju operator.

Snap Refresh

The Kubernetes resources used by this charm are snap packages. When not specified during deployment, these resources come from the public store. By default, the snapd daemon will refresh all snaps installed from the store four (4) times per day. A charm configuration option is provided for operators to control this refresh frequency.

NOTE: this is a global configuration option and will affect the refresh time for all snaps installed on a system.

Examples:

## refresh kubernetes-control-plane snaps every tuesday
juju config kubernetes-control-plane snapd_refresh="tue"

## refresh snaps at 11pm on the last (5th) friday of the month
juju config kubernetes-control-plane snapd_refresh="fri5,23:00"

## delay the refresh as long as possible
juju config kubernetes-control-plane snapd_refresh="max"

## use the system default refresh timer
juju config kubernetes-control-plane snapd_refresh=""

For more information, see the snap refresh documentation.

Configuration

Charmed Kubernetes ships with sensible, tested default configurations to ensure a reliable Kubernetes experience, but of course these can be changed to reflect the purpose and resources of your cluster. The configuration section details all available configuration options, while this section deals with specific, commonly used settings. You may wish to also read the Addons page for information on the extra services installed with Charmed Kubernetes.

IPVS (IP Virtual Server)

IPVS implements transport-layer load balancing as part of the Linux kernel, and can be used by the kube-proxy service to handle service routing. By default kube-proxy uses a solution based on iptables, but this can cause a lot of overhead in systems with large numbers of nodes. There is more information on this in the upstream Kubernetes IPVS deep dive documentation.

IPVS is an extra option for kube-proxy, and can be enabled by changing the configuration:

juju config kubernetes-control-plane proxy-extra-config='{mode: ipvs, ipvs: {strictARP: true}}'

It is also necessary to change this configuration option on the worker:

juju config kubernetes-worker proxy-extra-config='{mode: ipvs, ipvs: {strictARP: true}}'

Admission controls

As with other aspects of the Kubernetes API, admission controls can be enabled by adding extra values to the charm’s api-extra-args configuration.

For admission controls, it may be useful to refer to the Kubernetes blog for more information on the options, but for example, to add the PersistentVolumeLabel admission controller:

1. Check any current config settings for api-extra-args (there are none by default):

   juju config kubernetes-control-plane api-extra-args
   

2. Append the desired config option to the previous output and apply:

   juju config kubernetes-control-plane api-extra-args="enable-admission-plugins=PersistentVolumeLabel"
   

Adding SANs and certificate regeneration

As explained in the Certificates and trust overview, the extra_sans configuration settings can be used to add SANs and regenerate x509 certificate(s) for the API server running on the Kubernetes control plane node(s), and for the load balancer. When this configuration is changed, the control plane node(s) will regenerate certificates and restart the API server to update the certificate used for communication.

NOTE: this is disruptive as the Kubernetes API server is restarted.

The process is the same for both the kubernetes-control-plane and the kubeapi-load-balancer charms. The configuration option takes a space-separated list of extra entries:

juju config kubernetes-control-plane extra_sans="main.mydomain.com lb.mydomain.com"
juju config kubeapi-load-balancer extra_sans="main.mydomain.com lb.mydomain.com"

To clear the entries out of the certificate, use an empty string:

juju config kubernetes-control-plane extra_sans=""
juju config kubeapi-load-balancer extra_sans=""

More information

• Kubernetes github project
• Kubernetes issue tracker
• Kubernetes documentation
• Kubernetes releases