Oracle’s Wim Coekaerts Talks Linux Kernel Development & Containers
By Jack M. Germain
The Linux kernel is the foundation for countless IT environments among thousands of organizations. As these organizations transition to computing in the cloud, they just assume the process will work out of the box.
Once they start moving to the cloud and take with them the new technologies surrounding Linux containers, they find getting from Point A to Point C involves dealing with present-day realities. That may be something nobody ever told them.
Expectations are that containers in the cloud always “just work.” The reality is, both containers and the cloud are still works in progress. Consequently, this notion of “just working” has a few strings attached.
I recently spoke with Oracle Senior Vice President Wim Coekaerts about what factors cause concerns for both users and developers of cloud and container technologies. Coekaerts has worked almost 20 years to make and maintain Linux enterprise-ready. He has a catbird’s view of what awaits new customers regarding container support and the lack of enterprise-ready diagnostics and security capabilities.
Jack Germain: What role has the Linux kernel played in the development of Cloud and container coexistence?
WIM COEKAERTS: Oracle has been in the Linux business since 2006. It started a subscription service for Linux support and has developed fixes and improvements for the Linux kernel. This plays well with the growth of container technology. We can push the kernel updates online without interfering with thousands of Docker incidents running on one machine. If you don’t have to patch your kernel yourself, that has a significant impact. Users can also select which kernel they need to run for particular installations.
To meet the growing needs of cloud users, Oracle decided to double its efforts in kernel development. Oracle over the past nine months has drastically increased the size of the kernel development team. Kernel contributions are now more generic. The focus is turning out more generic kernel patches. Our objective is finding what can we do on the Linux side to make infrastructure run better.
JG: How would you describe the reliability of cloud and container technology today?
WC: In particular, container technology over the last three years has become very popular, but it is still a young technology. On the kernel side, there is still a lot of development taking place.
Typically, containers today are run inside a virtual machine rather than in a multi-tenant environment. It is not yet battle-tested for that. It is not yet comfortable to run multiple containers for different customers from the same box. It has to be isolated within VMs for each customer.
That is how all the cloud providers today provide a container service environment. You tell them how many VMs you want to set up, and they run the containers for you.
JG: What are the major pitfalls users face today?
WC: Users tend to prefer container-wide settings. But these have a tendency to spill over into system-wide controls. We don’t want that. There is a lot of effort into locking these holes down, so one container cannot spill over into any other container in terms of setting that affect an entire operating system. That would be really bad.
Another strategy for users is to deploy SELinux to have the right profiles to ensure complete comfort within a container. There should be nothing a user can do to break the container isolation.
Another aspect that concerns users is performance. That involves several aspects. One is NATs, or Network Address Translations. You can potentially have thousands of IP addresses and ports allocated to these running containers. It is all virtual networking. Users were plagued with significant performance bottlenecks in the past. Some of these slowdowns developers have cleaned up.
JG: What other factors impact performance?
WM: The second part of this performance concern is scheduling. A number of years ago you would run just one application or a set of apps on a server. Then, we added virtualizations to run an app in a VM. Next, containers appeared that posed a big difference in the way scheduling works.
You no longer have a hypervisor that has to juggle 10 or 20 VMs. But the OS within each VM has to schedule within its world. Now, you end up with 10,000 or 20,000 processes that all have some locality of what they are doing within a container. But from the host kernel, it is just one big pool.
So, how do you schedule so much stuff and how do you gang schedule to ensure there is no latency from one app to another? That is a big part of what needs to be improved on the container side.
JG: What industry tools are available to deal with performance issues?
WM: That is where the third part comes into play. It involves observability and monitoring. In working with VMs, a user can see X as a certain amount of CPUs and Y as a certain amount of RAM as memory. So, it is relatively easy to see how much computer you have left and how much memory you have left.
In the container space, however, it is sort of one big bucket into which you keep pouring stuff into it, until it spills over. You don’t want that. Developers need to figure out the right algorithms for reporting CPU and memory usage and how much is left of each.
There is more sharing going on. It is not black and white on how that works. In some cases you can use the kernel to figure out those statistics. In other cases, we need to do more work on tools to monitor and measure.
JG: Why is that a problem?
WC: Because it’s not always very easy to do. As an example, when you run a container within a VM, how do we make the container usage into a virtual life model where you really only see what you have with the container rather than the whole box?
You have to view this tweaking and development as a mix of what users are seeking and what providers value as important. The multi-tenant part is not always something that the users care about. That is usually just a cloud-using thing. The security part everyone cares about. Nobody wants one container to disrupt another one. That is something that all customers struggle with.
JG: Is performance the critical concern among users?
WC: Computing performance is something that everyone cares about. But right now, it is not necessarily a concern coming from the cloud users. Containers are not used that widely yet where customers are seeing performance as a bothersome issue.
We see it because we have such scale. As devs, we want to pre-empt some of that potential performance concern as growth continues.
Observability and monitoring is split 50–50 between users and providers. Containers in clouds are much harder to monitor. There are no tools for that yet, providing the same level of detail. It is probably the number one concern on both sides of the technology.
JG: Is the performance issue a make-or-break factor for container and cloud technologies?
WC: You can’t view this as an impediment to both cloud and container use. They are two separate issues. On the cloud side, orchestration tools try to hide the complexity. Auto-scaling is built into the cloud side.
It is a well-known concern, so I doubt it will become a show-stopper. By the time more users are ready to make that jump, those things will be in place. Eventually, the two aspects will connect.
Please feel free to share below any comments, questions or insights about your experience with Linux and containers, including Docker, Swarm or Kubernetes. And if you found this blog useful, consider sharing it through social media.
About the blogger: Jack M. Germain is a veteran IT journalist whose outstanding IT work can be found regularly in ECT New Network’s LinuxInsider, and other outlets like TechNewsDirectory. Jack’s reporting has spanned four decades and his breadth of It experience is unmatched. And while his views and reports are solely his and don’t necessarily reflect those of Linode, we are grateful for his contributions. He can be followed on Google+.
Check out these Container docs recently added to our library:
Use CoreOS Container Linux on Linode
How to Install Docker and Pull Images for Container Deployment
