Skip to content

Category: Containers and Kubernetes

Netways OSDC 2017: Something Openshift Kubernetes Containers

OSDC 2017 Registration
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.

Docker Image Vulnerability Research

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.

BFQ is coming…

LWN reports that the 4.11 merge window opens. Among other things, Maik Zumstrull reminds us, we get

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.

Containers 101

It is helpful to remember that containers are just normal Unix processes with two special tricks.

Normal Unix Processes

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.

PID 17 forks, and creates a new process with PID 18. This process executes a copy of the original program.

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.