Cloud Foundry Advisory Board Meeting, August 2019: Intro to EiriniX
This month’s Cloud Foundry Community Advisory Board (CAB) meeting focused on the EiriniX library and updates from the Eirini project itself. Michael Maximilien (a.k.a. Dr. Max) of IBM moderated the call and mentioned that Stratos has graduated from incubation with the support for Kubernetes being worked on. The call also featured regular updates from various members of the development teams and from the CF Foundation.
What is EiriniX?
EiriniX is an extensions library for the core Eirini project. Vlad Iovanov of SUSE explained that EiriniX is a library that helps to write extensions for Eirini by providing plenty of commonly used code.
According to Vlad, EiriniX was created to expand the capabilities of the core project without having to put additional load on the Eirini team. Additionally, EiriniX provides some additional features, for instance, persistent support—the ability to mount persistent volumes in an application.
“The EiriniX library does everything for you. It sets up an HTTP server, generates certificates, and creates those certificates as secretes in Kubernetes. It also creates webhook configurations that Kubernetes needs. It sets up watchers if you need those.”
—Vlad Iovanov, SUSE
Eirini is a Kubernetes back end for Cloud Foundry. The solution provides an integrated
cf push flow, with Cloud Foundry apps mapped directly to Kubernetes
During the call, Mario Nitchev and Julian Skupnjak (a.k.a. Herr Julz) of IBM provided a recap of Eirini. They also highlighted updates to the project since the Philadelphia summit held in April. Mario noted that the idea behind Eirini is to bring the
cf push user experience to Kubernetes.
“If you do
cf push, then Eirini will create a
StatefulSetin Kubernetes, which will represent your app. Kubernetes will then schedule an instance of that app. If you use
cf scale, then Erini will create replicas of
StatefulSet, and Kubernetes will bring up all the instances that you want.” —Mario Nitchev, IBM
According to Mario, the Eirini team managed the transition from droplets to images by using Bits-Service as a registry. Bits-Service uses droplets to serve images to Kubernetes.
“When you do
cf push, Eirini gets a staging request and uses that request to create a job in Kubernetes. This job creates a pod, which runs the staging process. The pod will produce a droplet, and when done it will put the droplet back in Cloud Controller, so Bits-Service can have access to it.” —Mario Nitchev, IBM
After the update, Julian highlighted some of the new updates for Eirini. This included protecting components that communicated with Eirini but were previously insecure. He also noted how applications in the Eirini namespace were insecure and how Kuberenetes master and the API could be directly reached. These were addressed with the security update.
“We added TLS from Cloud Controller to Eirini and the other way around. We also added TLS to the Bits-Service registry, as well as basic authentication. A user name and a password are now required to pull images from the Bits-Service registry.”
—Julian Skupnjak, IBM
Next, Julian touched on issues with secure staging. Previously, there was only one staging job, which performed the whole staging process—download, build, and upload—all in a single pod. This pod was insecure as it held all of the secrets.
“We split up staging in three different steps. Each step is done in a separate container. This way, the build step no longer has access to any secrets.” —Julian Skupnjak, IBM
Finally, he mentioned that users can now dynamically patch the root file system.
“Let’s say, you want to use a specific
rootfsversion. What you would do as an operator is update your Helm chart with the
rootfsversion of your choice and then you perform the Helm upgrades. Helm would then update the
rootfsversion label on Eirini and Bit-Service, causing these components to restart. All applications that are newly pushed to Kubernetes will have the new
rootfsversion. Meanwhile, the
rootfspatcher waits until Bits-Service is backed up and then updates all the applications with the right
rootfsversion and restarts them.” —Julian Skupnjak, IBM
During the call, Mario and Julian gave a live demonstration of Eirini. They also mentioned that a more in-depth dive of Eirini will happen next month during the next Cloud Foundry summit in Hague.
Eric Malm of Pivotal provided the following updates:
- cf-deployment v10 and v11 were released.
- The CF CLI team is working on v6.46.1, which includes login refactoring.
- The CAPI team is working with sidecars. They are also exploring Diego and Eirini side-by-side operations.
- The Networking team is exploring solutions for hybrid BOSH / Kubernetes / Cloud Foundry deployments.
- The Volume Services team is deprecating elastic file system volume drivers and corresponding brokers. This was done to further support the network file system broker, as well as ensure Eirini and Kubernetes integrations.
Morgan Fine of Pivotal listed the following changes:
- BOSH v270.6.0 and BOSH CLI v6.0.0 were released.
- BOSH now introduces the new
--no-convergeflag to the
restartcommands, so that the entire deployment doesn’t get updated when running them.
- Releases specified in a runtime config will no longer be considered unused when running
- Certificate expiry length can be configured in the BOSH Director certifications via its manifest.
- A new AWS CPI was cut, addressing a change on the AWS server side.
CF Foundation updates
With only a few weeks before the Cloud Foundry Europe Summit 2019, which starts on September 11 in Hague, Swarna Podila reminded to register using the contributor code in the cf-dev mailing list. The schedule is already live and attendees can start filling up their agendas. The event will also have the following presummit activities:
- contributor summit
- user day
The next CAB call will occur during the summit. The specific time and date will be announced in Cloud Foundry’s CAB Slack channel.
Want details? Watch the video!