Canonical announces full enterprise support for Kubernetes 1.15 using kubeadm deployments, its Charmed Kubernetes, and MicroK8s; the popular single-node deployment of Kubernetes.

The MicroK8s community continues to grow and contribute enhancements, with Knative and RBAC support now available through the simple microk8s.enable command. Knative is a great way to experiment with serverless computing, and now you can experiment locally through MicroK8s. With MicroK8s 1.15 you can develop and deploy Kubernetes 1.15 on any Linux desktop, server or VM across 40 Linux distros. Mac and Windows are supported too, with Multipass.

Existing Charmed Kubernetes users can upgrade smoothly to Kubernetes 1.15, regardless of the underlying hardware or machine virtualisation. Supported deployment targets include AWS, GCE, Azure, Oracle, VMware, OpenStack, LXD, and bare metal.

“Kubernetes 1.15 includes exciting new enhancements in application, custom resource, storage, and network management. These features enable better quota management, allow custom resources to behave more like core resources, and offer performance enhancements in networking. The Ubuntu ecosystem benefits from the latest features of Kubernetes, as soon as they become available upstream“ commented Carmine Rimi, Kubernetes Product Manager at Canonical.

What’s new in Kubernetes 1.15

Notable upstream Kubernetes 1.15 features:

• Storage enhancements:
  • Quotas for ephemeral storage: (alpha) Quotas utilises filesystem project quotas to provide monitoring of resource consumption and optionally enforcement of limits. Project quotas, initially in XFS and more recently ported to ext4fs, offer a kernel-based means of monitoring and restricting filesystem consumption. This improves performance of monitoring storage utilisation of ephemeral volumes.
  • Extend data sources for persistent volume claims (PVC): (alpha) You can now specify an existing PVC as a DataSource parameter for creating a new PVC. This results in a clone – a duplicate – of an existing Kubernetes Volume that can be consumed as any standard Volume would be. The back end device creates an exact duplicate of the specified Volume. Clones and Snapshots are different – a Clone results in a new, duplicate volume being provisioned from an existing volume — it counts against the users volume quota, it follows the same create flow and validation checks as any other volume provisioning request, it has the same lifecycle and workflow. Snapshots, on the other hand, results in a point-in-time copy of a volume that is not, itself, a usable volume.
  • Dynamic persistent volume (PV) resizing: (beta) This enhancement allows PVs to be resized without having to terminate pods and unmount the volume first.
• Networking enhancements:
  • NodeLocal DNSCache: (beta) This enhancement improves DNS performance by running a dns caching agent on cluster nodes as a Daemonset. With this new architecture, pods reach out to the dns caching agent running on the same node, thereby avoiding unnecessary networking rules and connection tracking.
  • Finaliser protection for service load balancers: (alpha) Adding finaliser protection to ensure the Service resource is not fully deleted until the correlating LB is also deleted.
  • AWS Network Load Balancer Support: (beta) AWS users now have more choices for AWS load balancer configuration. This includes the Network Load Balancer, which offers extreme performance and static IPs for applications.
• Node and Scheduler enhancements:
  • Device monitoring plugin support: (beta) Monitoring agents provide insight to the outside world about containers running on the node – this includes, but is not limited to, container logging exporters, container monitoring agents, and device monitoring plugins. This enhancement gives device vendors the ability to add metadata to a container’s metrics or logs so that it can be filtered and aggregated by namespace, pod, container, etc.  
  • Non-preemptive priority classes: (alpha) This feature adds a new option to PriorityClasses, which can enable or disable pod preemption. PriorityClasses impact the scheduling and eviction of pods – pods are scheduled according to descending priority; if a pod cannot be scheduled due to insufficient resources, lower-priority pods will be preempted to make room. Allowing PriorityClasses to be non-preempting is important for running batch workloads – pods with partially-completed work won’t be preempted, allowing them to finish.
  • Scheduling framework extension points: (alpha) The scheduling framework extension points allow many existing and future features of the scheduler to be written as plugins. Plugins are compiled into the scheduler, and these APIs allow many scheduling features to be implemented as plugins, while keeping the scheduling ‘core’ simple and maintainable.
• Custom Resource Definitions (CRD) enhancements:
  • OpenAPI 3.0 Validation: Major changes introduced to schema validation with the addition of OpenAPI 3.0 validation.
  • Watch bookmark support: (alpha) The Watch API is one of the fundamentals of the Kubernetes API. This feature introduces a new type of watch event called Bookmark, which serves as a checkpoint of all objects, up to a given resourceVersion, that have been processed for a given watcher. This makes restarting watches cheaper and reduces the load on the apiserver by minimising the amount of unnecessary watch events that need to be processed after restarting a watch.
  • Defaulting: (alpha) This features add support for defaulting to Custom Resources. Defaulting is a fundamental step in the processing of API objects in the request pipeline of the kube-apiserver. Defaulting happens during deserialisation, after decoding of a versioned object, but before conversion to a hub type. This feature adds support for specifying default values for fields via OpenAPI v3 validation schemas in the CRD manifest. OpenAPI v3 has native support for a default field with arbitrary JSON values.
  • Pruning: (alpha) Custom Resources store arbitrary JSON data without following the typical Kubernetes API behaviour to prune unknown fields. This makes CRDs different, but also leads to security and general data consistency concerns because it is unclear what is actually stored. The pruning feature will prune all fields which are not specified in the OpenAPI validation schemas given in the CRD.
  • Admission webhook: (beta) Major changes were introduced. The admission webhook feature now supports both mutating webhook and validation (non-mutating) webhook. The dynamic registration API of webhook and the admission API are promoted to v1beta1.
• For more information, please see the upstream Kubernetes 1.15 release notes.

Notable MicroK8s 1.15 features:

• Pure upstream Kubernetes 1.15 binaries.
• Knative addon, try it with “microk8s.enable knative”. Thank you @olatheander.
• RBAC support via a simple “microk8s.enable rbac”, courtesy of @magne.
• Update of the dashboard to 1.10.1 and fixes for RBAC. Thank you @balchua.
• CoreDNS is now the default. Thanks @richardcase for driving this.
• Ingress updated to 0.24.1 by @JorritSalverda, thank you.
• Fix on socat failing on Fedora by @JimPatterson, thanks.
• Modifiable csr server certificate, courtesy of @balchua.
• Use of iptables kubeproxy mode by default.
• Instructions on how to run Cilium on MicroK8s by @joestringer.

For complete details, along with installation instructions, see the MicroK8s 1.15 release notes and documentation.

Notable Charmed Kubernetes 1.15 features:

• Pure upstream Kubernetes 1.15 binaries.
• Containerd support: The default container runtime in Charmed Kubernetes 1.15 is containerd. Docker is still supported, and an upgrade path is provided for existing clusters wishing to migrate to containerd. Both runtimes can be used within a single cluster if desired. Container runtimes are now subordinate charms, paving the way for additional runtimes to be added in the future.
• Calico 3 support: The Calico and Canal charms have been updated to install Calico 3.6.1 by default. For users currently running Calico 2.x, the next time you upgrade your Calico or Canal charm, the charm will automatically upgrade to Calico 3.6.1 with no user intervention required.
• Calico BGP support: Several new config options have been added to the Calico charm to support BGP functionality within Calico. These additions make it possible to configure external BGP peers, route reflectors, and multiple IP pools.
• Custom load balancer addresses: Support has been added to specify the IP address of an external load balancer. This support is in the kubeapi-load-balancer and the kubernetes-master charms. This allows a virtual IP address on the kubeapi-load-balancer charm or the IP address of an external load balancer.
• Private container registry enhancements: A generic images-registry configuration option that will be honored by all Kubernetes charms, core charms and add-ons, so that users can specify a private registry in one place and have all images in a Kubernetes deployment come from that registry.
• Keystone with CA Certificate support: Kubernetes integration with keystone now supports the use of user supplied CA certificates and can support https connections to keystone.
• Graylog updated to version 3, which includes major updates to alerts, content packs, and pipeline rules. Sidecar has been re-architected so you can now use it with any log collector.
• ElasticSearch updated to version 6. This version includes new features and enhancements to aggregations, allocation, analysis, mappings, search, and the task manager.

For complete details, see the Charmed Kubernetes 1.15 release notes and documentation.

Contact us

• Slack – #cdk and #microk8s on the Kubernetes Slack
• Launchpad – https://launchpad.net/charmed-kubernetes
• IRC – #cdk8s on Freenode IRC

If you’re interested in Kubernetes support, consulting, or training, please get in touch!

About Charmed Kubernetes

Canonical’s certified, multi-cloud Charmed Kubernetes installs pure upstream binaries, and offers simplified deployment, scaling, management, and upgrades of Kubernetes, regardless of the underlying hardware or machine virtualisation. Supported deployment environments include AWS, GCE, Azure, VMware, OpenStack, LXD, and bare metal.

Charmed Kubernetes integrates tightly with underlying cloud services and hardware – enabling GPGPU’s automatically and leveraging cloud-specific services like AWS, Azure and GCE load balancers and storage. Charmed Kubernetes allows independent placement and scaling of components such as etcd or the Kubernetes Master, providing an HA or minimal configuration, and built-in, automated, on-demand upgrades from one version to the next.

Enterprise support for Charmed Kubernetes by Canonical provides customers with a highly available, multi-cloud, flexible and secure platform for their cloud-native workloads and enjoys wide adoption across enterprise, particularly in the telco, financial and retail sectors.