Ubuntu Look

This article originally appeared on Tim Van Steenburgh’s blog

September 15th concluded our most recent development sprint on the Canonical Distribution of Kubernetes (CDK). Here are some highlights:

Canal Bundle

Our new Canal bundle is published! If you need network policy support in your cluster, try it out:

juju deploy canonical-kubernetes-canal

In the future you’ll be able to choose between Flannel and Calico when deploying Kubernetes via conjure-up.

Blogs and Demos

In case you missed them, check out some new blog posts and demos of CDK from members of the CDK engineering team:

• Building CDK: Part #1 by Konstantinos Tsakalozos
• Kubernetes Snaps: The Quick Version by George Kraft
• Introduction to the Canonical Distribution of Kubernetes (part 1, part 2, slides). Many thanks to Arash Kaffamanesh and the @kubernauts for hosting and recording this talk!

RBAC

We added more tests for RBAC and updated CI to start testing an RBAC-enabled cluster. Our remaining task for RBAC is to plan and test the upgrade path for old clusters once we make RBAC on-by-default.

s390x

We built and published an s390x nginx-ingress-controller image and an e2e snap, and started testing a lxd CDK cluster on s390x. Since then we’ve gotten access to more hardware and are now testing on s390x vms using the Juju manual provider.

1.8.0

In our current sprint we’ve started testing 1.8.0 in anticipation of the upstream release at the end of this month. We’re also testing with docker 1.13.1, which will soon become the default in CDK.

If you’d like to follow along more closely with CDK development, you can do so in the following places:

• https://github.com/kubernetes/kubernetes (cluster/juju directory)
• https://github.com/juju-solutions/bundle-canonical-kubernetes
• Kubernetes Slack channels and SIG meetings
• #juju on Freenode IRC
• juju@lists.ubuntu.com mailing list

Until next time!

We’re less than a week away from Final Beta! It seems to have come round very quickly this cycle. Next week we’re at the Ubuntu Rally in New York City where we will be putting the finishing touches to the beta. In the meantime, here’s a quick rundown on what happened this week:

GNOME

• The release of GNOME 3.26 last week meant lots of package updates in 17.10. Thanks Jeremy for leading the charge on this.
• More work is happening on the progress bars in Dash to Dock.
• We’re working on a fix for a bug which shows your desktop for a few seconds when resuming from suspend. This affects Unity and GNOME Shell.
• We’ve made a few more tweaks to GDM, and you can now see the Ubuntu logo at bottom of the greeter.
• Some new additions to Didier’s series of blog posts on the transition to GNOME Shell covers alt-tab behaviour
  • https://didrocks.fr/2017/09/14/ubuntu-gnome-shell-in-artful-day-12/
• And the transparency settings for Dash to Dock:
  • https://didrocks.fr/2017/09/20/ubuntu-gnome-shell-in-artful-day-13/
• The new wallpaper and mascot were released.

Snaps

We’ve been working on a Platform Snap for GNOME 3.26 to allow you to run the latest GNOME apps on Xenial as well as making Snaps for the new apps. This should be ready for testing soon and we’d appreciate some feedback.

Some desktop specific updates to snapd are also in the going to be rolling out soon; Snaps using the new Desktop interface will automatically get access to host system fonts and font caches.

Updates

• Chromium 61.0.3163.79 is ready for publication. Chromium beta updated to 62.0.3202.18 and dev updated to 63.0.3213.3 for all series except Trusty.
• Libreoffice 5.4.1-0ubuntu1 now in Artful.

In The News

• OMG talks about the changes to the Dock.
• Dustin Kirkland presents the results of the app survey at UbuCon Paris.

By Leann Ogasawara, Director of Kernel Engineering

Ubuntu has long been a popular choice for Linux instances on Azure.  Our ongoing partnership with Microsoft has brought forth great results, such as the support of the latest Azure features, Ubuntu underlying SQL Server instances, bash on Windows, Ubuntu containers with Hyper-V Isolation on Windows 10 and Windows Servers, and much more.

Canonical, with the team at Microsoft Azure, are now delighted to announce that as of September 21, 2017, Ubuntu Cloud Images for Ubuntu 16.04 LTS on Azure have been enabled with a new Azure tailored Ubuntu kernel by default.  The Azure tailored Ubuntu kernel will receive the same level of support and security maintenance as all supported Ubuntu kernels for the duration of the Ubuntu 16.04 LTS support life.

The kernel itself is provided by the linux-azure kernel package. The most notable highlights for this kernel include:

• Infiniband and RDMAcapability for Azure HPC to deliver optimized performance of compute intensive workloads on Azure A8, A9, H-series, and NC24r.
• Full support for Accelerated Networking in Azure.  Direct access to the PCI device provides gains in overall network performance offering the highest throughput and lowest latency for guests in Azure.  Transparent SR-IOV eliminates configuration steps for bonding network devices.  SR-IOV for Linux in Azure is in preview but will become generally available later this year.
• NAPI and Receive Segment Coalescing for 10% greater throughput on guests not using SR-IOV.
• 18% reduction in kernel size.
• Hyper-V socket capability — a socket-based host/guest communication method that does not require a network.
• The very latest Hyper-V device drivers and feature support available.

The ongoing collaboration between Canonical and Microsoft will also continue to produce upgrades to newer kernel versions providing access to the latest kernel features, bug fixes, and security updates.  Any Ubuntu 16.04 LTS image brought up from the Azure portal after September 21st will be running on this Azure tailored Ubuntu kernel.

How to verify which kernel is used:

 $ uname -r 4.11.0-1011-azure 

 

Instances using the Azure tailored Ubuntu kernel will, of course, be supportable through Canonical’s Ubuntu Advantage service, available for purchase on our online shop or through sales@canonical.com in three tiers:

• Essential: designed for self-sufficient users, providing access to our self-support portal as well as a variety of Canonical tools and services.
• Standard: adding business-hours web and email support on top of the contents of Essential, as well as a 2-hour to 2-business days response time (severity 1-4).
• Advanced: adding 24×7 web and email support on top of the contents of Essential, as well as a 1-hour to 1-business day response time (severity 1-4).

The Azure tailored Ubuntu kernel will not support the Canonical Livepatch Service at the time of this announcement, but investigation is underway to evaluate delivery of this service in the future.

If, for now, you prefer livepatching at scale over the above performance improvements, it is possible to revert to the standard kernel, using the following commands:

 

 $ sudo apt install linux-virtual linux-cloud-tools-virtual $ sudo apt purge linux*azure $ sudo reboot 

 

As we continue to collaborate closely with various Microsoft teams on public cloud, private cloud, containers and services, you can expect further boosts in performance, simplification of operations at scale, and enablement of new innovations and technologies.

This article originally appeared on George Kraft’s blog

When we built the Canonical Distribution of Kubernetes (CDK), one of our goals was to provide snap packages for the various Kubernetes clients and services: kubectl, kube-apiserver, kubelet, etc.

While we mainly built the snaps for use in CDK, they are freely available to use for other purposes as well. Let’s have a quick look at how to install and configure the Kubernetes snaps directly.

The Client Snaps

This covers: kubectl, kubeadm, kubefed

Nothing special to know about these. Just snap install and you can use them right away:

 $ sudo snap install kubectl --classic kubectl 1.7.4 from 'canonical' installed $ kubectl version --client Client Version: version.Info{Major:"1", Minor:"7", GitVersion:"v1.7.4", GitCommit:"793658f2d7ca7f064d2bdf606519f9fe1229c381", GitTreeState:"clean", BuildDate:"2017-08-17T08:48:23Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} 

The Server Snaps

This covers: kube-apiserver, kube-controller-manager, kube-scheduler, kubelet, kube-proxy

Example: kube-apiserver

We will use kube-apiserver as an example. The other services generally work the same way.

Install with snap install

This creates a systemd service named snap.kube-apiserver.daemon. Initially, it will be in an error state because it’s missing important configuration:

 $ systemctl status snap.kube-apiserver.daemon ● snap.kube-apiserver.daemon.service - Service for snap application kube-apiserver.daemon Loaded: loaded (/etc/systemd/system/snap.kube-apiserver.daemon.service; enabled; vendor preset: enabled) Active: inactive (dead) (Result: exit-code) since Fri 2017-09-01 15:54:39 UTC; 11s ago ... 

Configure kube-apiserver using snap set.

 sudo snap set kube-apiserver \ etcd-servers=https://172.31.9.254:2379 \ etcd-certfile=/root/certs/client.crt \ etcd-keyfile=/root/certs/client.key \ etcd-cafile=/root/certs/ca.crt \ service-cluster-ip-range=10.123.123.0/24 \ cert-dir=/root/certs 

Note: Any files used by the service, such as certificate files, must be placed within the /root/ directory to be visible to the service. This limitation allows us to run a few of the services in a strict confinement mode that offers better isolation and security.

After configuring, restart the service and you should see it running:

 $ sudo service snap.kube-apiserver.daemon restart $ systemctl status snap.kube-apiserver.daemon ● snap.kube-apiserver.daemon.service - Service for snap application kube-apiserver.daemon Loaded: loaded (/etc/systemd/system/snap.kube-apiserver.daemon.service; enabled; vendor preset: enabled) Active: active (running) since Fri 2017-09-01 16:02:33 UTC; 6s ago ... 

Configuration

The keys and values for snap set map directly to arguments that you would
normally pass to the service. You can view a list of arguments by invoking the
service directly, e.g. kube-apiserver -h.

For configuring the snaps, drop the leading dashes and pass them through
snap set. For example, if you want kube-apiserver to be invoked like this

 kube-apiserver --etcd-servers https://172.31.9.254:2379 --allow-privileged 

You would configure the snap like this:

 snap set kube-apiserver etcd-servers=https://172.31.9.254:2379 allow-privileged=true 

Note, also, that we had to specify a value of true for allow-privileged. This
applies to all boolean flags.

Going deeper

Want to know more? Here are a couple good things to know:

If you’re confused about what snap set ... is actually doing, you can read
the snap configure hooks in

 /snap/<snap-name>/current/meta/hooks/configure 

to see how they work.

The configure hook creates an args file here:

 /var/snap/<snap-name>/current/args 

This contains the actual arguments that get passed to the service by the snap:

 $ cat /var/snap/kube-apiserver/current/args --cert-dir "/root/certs" --etcd-cafile "/root/certs/ca.crt" --etcd-certfile "/root/certs/client.crt" --etcd-keyfile "/root/certs/client.key" --etcd-servers "https://172.31.9.254:2379" --service-cluster-ip-range "10.123.123.0/24" 

Note: While you can technically bypass snap set and edit the args file directly, it’s best not to do so. The next time the configure hook runs, it will obliterate your changes. This can occur not only from a call to snap set but also during a background refresh of the snap.

The source code for the snaps can be found here: https://github.com/juju-solutions/release/tree/rye/snaps/snap

We’re working on getting these snaps added to the upstream Kubernetes build process. You can follow our progress on that here: https://github.com/kubernetes/release/pull/293

If you have any questions or need help, you can either find us at #juju on
freenode, or open an issue against https://github.com/juju-solutions/bundle-canonical-kubernetes and we’ll help you out as soon as we can.

September 13 through September 18

Development (Artful / 17.10)

https://wiki.ubuntu.com/ArtfulAardvark/ReleaseSchedule

Important upcoming dates:

 Final Beta - Sept 28 (~1 week away) Kernel Freeze - Oct 5 (~2 weeks away) Final Freeze - Oct 12 (~3 weeks away) Ubuntu 17.10 - Oct 19 (~4 weeks away) 

We intend to target a 4.13 kernel for the Ubuntu 17.10 release. A 4.13.1 based kernel is available for testing from the artful-proposed pocket of the Ubuntu archive. As a reminder, the Ubuntu 17.10 Kernel Freeze is Thurs Oct 5, 2017.

Stable (Released & Supported)

• All kernels have been re-spun to include a fix for high priority CVE-2017-1000251.

• SRU cycle completed successfully and the following kernel updates have been released:

   trusty 3.13.0-132.181 trusty/lts-xenial 4.4.0-96.119~14.04.1 xenial 4.4.0-96.119 xenial/snapdargon 4.4.0-1076.81 xenial/raspi2 4.4.0-1074.82 xenial/aws 4.4.0-1035.44 xenial/gke 4.4.0-1031.31 xenial/gcp 4.10.0-1006.6 zesty 4.10.0-35.39 zesty/raspi2 4.10.0-1018.21 

  • The following kernel snap updates have been released in the snap store:

     gke-kernel 4.4.0.1031.32 aws-kernel 4.4.0.1035.37 dragonboard-kernel 4.4.0.1076.68 pi2-kernel 4.4.0.1074.74 pc-kernel 4.4.0.96.101 

• Current cycle: 15-Sep through 07-Oct

   15-Sep Last day for kernel commits for this cycle. 18-Sep - 23-Sep Kernel prep week. 24-Sep - 06-Oct Bug verification & Regression testing. 09-Oct Release to -updates. 

• Next cycle: 06-Oct through 28-Oct

   
   06-Oct Last day for kernel commits for this cycle. 
   09-Oct - 14-Oct Kernel prep week.
   15-Oct - 27-Oct Bug verification & Regression testing.
   30-Oct Release to -updates.
  

Misc

• The Canonical Kernel Team is Hiring!
• The current CVE status
• If you would like to reach the kernel team, you can find us at the #ubuntu-kernel
  channel on FreeNode. Alternatively, you can mail the Ubuntu Kernel Team mailing
  list at: kernel-team@lists.ubuntu.com.