WOA Issue 68
Works on Arm News, Week 40, 2018 In this issue…
SUSE Linux Enterprise 15 (SLE 15) is now in public beta. It is based on the Linux Kernel version 4.12 and includes the latest GCC 7 system compiler. SUSE supports X86_64, Power LE, System z, and arm64 for physical, virtual and private/public cloud installations.
The announced plan is to release 5 Betas, 3 Release Candidates and one GMC from 27th October 2017 to 19th April 2018. Beta registration is required.
Azul announced that it will provide extended support for Java 9, 10 and all future Java releases that meets or exceeds what Oracle has announced in their new aggressive Java roadmap. In the announcement, they published extended support dates for many important Java releases (e.g. 9, 10, 12, 13, 14, etc.) that provide developers, partners and enterprises with sufficient overlap between major Java releases to make consumption of these versions possible. In addition, Azul will continue to support key platforms and processors that Oracle no longer offers support for with these new Java releases, including:
For more information about Azul’s extended Java support roadmap and how this dramatically extends Java’s usability for any given release, please visit the Zulu Roadmap page.
In this five minute video, Arm CEO Simon Segars sits down with Frederic Lardinois of Techcrunch at the CES show to talk about Meltdown, Spectre, and device security.
As for Spectre and Meltdown, Segars noted that the attacks have raised the awareness of how many microprocessors there are in the world today, though he also stressed that this attack exploits the features of high-performance chips — and only 5 percent of the chips that Arm’s licensees have sold in the past are susceptible to the attack.
Chris Short has a new project,
rak8s, for an Ansible and Raspbian based installation of Kubernetes on Arm. It uses a straightforward Ansible configuration to provision Kubernetes on a stack of Raspberry Pi systems running the 32-bit Raspbian operating system.
If you know me, you know my automation tool of choice is Ansible. The only time I want to manually SSH into these systems is to fix something very abnormal. There is kubespray but it doesn’t address ARM. Kubespray is also overkill for what I’m trying to do. It’s also a little heavy for the Raspberry Pi platform itself. I decided to set off and build my own Ansible automation.
The second Kubernetes on Arm build is from Karol Stepniewski, who looks to Asus for their “Tinkerboard” hardware for his build. The Tinkerboard has more RAM (2GB) and faster network (gigabit) than the typical Raspberry Pi 3 used for these kinds of installations. Karol also puts HDDs to use for his cluster, using the (now discountinued) PiDrive HDD from Western Digital to provide persistent storage.
This is another Ansible based configuration, and as an exercise to the reader, it’s worth comparing Karol and Chris’s setup since they accomplish largely the same set of tasks but have a slightly different approach.
Miek Gieben presents the third approach in this issue to getting Kubernetes running on an Arm and Raspberry Pi cluster. He starts from the Hypriot instructions (from early 2017), which appear to be due for a refresh as some of the small details have changed.
Miek then goes on to make two advances to the art of bare-metal Kubernetes: installing the MetalLB load balancer and the CoreDNS name server as part of his configuration.
MetalLB is a load balancer for Kubernetes that runs on bare metal, in the sense that all it requires is ARP or BGP running on the network.
Kubernetes does not offer an implementation of network load-balancers (Services of type LoadBalancer) for bare metal clusters. The implementations of Network LB that Kubernetes does ship with are all glue code that calls out to various IaaS platforms (GCP, AWS, Azure…). If you’re not running on a supported IaaS platform (GCP, AWS, Azure…), LoadBalancers will remain in the “pending” state indefinitely when created.
MetalLB is in “alpha” and is not ready for production clusters, but if you’re looking to tackle this challenge it’s the first project I’ve seen of its kind.
I implemented an arp-speaker for MetalLB that would “announce” the service VIP and then let the kube-proxy handle the delivery to the actual pod(s). This took the better part of a week. But in the end we had a working implementation where kubectl expose would work with my crappy EA6900. I think this is quite significant.
Anyone can use Kubernetes load balancing with cheap hardware, at home.
Next, in tackling the task of getting CoreDNS running, Miek works on the challenge of cross-building Go projects on a single system for multiple target architectures. His solution,
dxbuild, allows him to support CoreDNS across amd64, arm, arm64, ppc64le, and s390x – all from a single Makefile.
Dann Frazier at Canonical has published a detailed account of “Deploying Ubuntu OpenStack to ARM64 servers”.
At Canonical, we’ve been doing work to make sure Ubuntu OpenStack deploys on ARM servers as easily as on x86. Whether you have Qualcomm 2400 REP boards, Cavium ThunderX boards, HiSilicon D05 boards, or other Ubuntu Certified server hardware, you can go from bare metal to a working OpenStack in minutes!
The reference design uses MAAS (“Metal as a service”) and Juju (a workload orchestration tool). It spells out the steps of deploying a five-node OpenStack cluster, with a Ceph storage server configured to provide persistent storage.