Ironically, the talk is about Autoscaling
I will be speaking at the Netways Open Source Data Center Conference, which is in Berlin between May 16 and 18.
At work, we are currently busy loading our first two Kubernetes Clusters (Openshift actually) with workloads.
What exactly will be in the slides I do not know, yet, but it will be about our journey at Booking, the transition from automated baremetal provisioning of rather monolithic applications to a more containerized setup and the changes and challenges this brings. It will be very much a snapshot of the state of things at that point in time, and our learnings and perspective then.
federacy reports “24% of the latest Docker images have significant vulnerabilities“.
The Report underlines the importance of running your own image building service and your own local registry when deploying Docker and Kubernetes.
And that includes the base operating system images, because the test above focused on latest images of official docker images of base operating system images, and known vulnerabilities in it. It lists last years vulnerabilities still being present in current images.
The multiqueue block layer finally has support for I/O scheduling. That is useful in its own right, but the real news is that it enables the merging of the long-awaited BFQ I/O scheduler. That, says block maintainer Jens Axboe, “should be ready for 4.12”.
Of course, if you are on a LTS release of a Linux kernel, it’s unlikely that you will profit from this any time soon.
A posting at Brave New Geek about limits on everything, for example limits on message sizes and numbers of in-flight messages in message queues. Interesting read.
It is helpful to remember that containers are just normal Unix processes with two special tricks.
Unix starts processes by performing a fork() system call to create a new child process. The child process still contains the same program as the parent process, so the parent processes program still has control over the child. It usually performs a number of operations within the context of the new child, preparing the environment for the new program, from within.
Then, after the environment is complete, the parent program within the child processes context replaces itself by calling execve(). This system call unloads the current program in a process and reuses the process to load a new program into it.