All Posts By

Chris Aniszczyk

CNCF Archives the rkt Project

By | Blog

As part of a new Archiving Process initiated earlier this year, CNCF announced today that the Technical Oversight Committee (TOC) has voted to archive the rkt project.

All open source projects are subject to a lifecycle and can become less active for a number of reasons. In rkt’s case, despite its initial popularity following its creation in December 2014, and contribution to CNCF in March 2017, end user adoption has severely declined. The CNCF is also home to other container runtime projects: containerd and CRI-O, and while the rkt project played an important part in the early days of cloud native adoption, in recent times user adoption has trended away from rkt towards these other projects. Furthermore, project activity and the number of contributors has also steadily declined over time, along with unpatched CVEs.

At CNCF, incubation stage projects are expected to show end user growth, maintain a healthy number of committers, and demonstrate a substantial ongoing flow of contributions, among other things. For projects that no longer meet these requirements, a proposal can be submitted to the TOC to archive a project. Once a project is archived:

  • CNCF will no longer provide full services for the project, except transition services such as documentation updates to help transition users
  • Trademarks of archived projects are still hosted neutrally by the Linux Foundation
  • CNCF marketing and event activities will no longer be provided for the project

Any project that has been archived can be reactivated into CNCF through the normal project proposal process. The archived project will be hosted under the Linux Foundation and maintainers are welcome to continue working on the project if they wish to do so.

The CNCF TOC would like to thank the rkt project maintainers and contributors for the important part they have played in the development and evolution of cloud native technology.

Learn more about the CNCF archiving process

Open Sourcing the Kubernetes Security Audit

By | Blog

Last year, the Cloud Native Computing Foundation (CNCF) began the process of performing and open sourcing third-party security audits for its projects in order to improve the overall security of our ecosystem. The idea was to start with a handful of projects and gather feedback from the CNCF community as to whether or not this pilot program was useful. The first projects to undergo this process were CoreDNS, Envoy and Prometheus. These first public audits identified security issues from general weaknesses to critical vulnerabilities. With these results, project maintainers for CoreDNS, Envoy and Prometheus have been able to address the identified vulnerabilities and add documentation to help users.

The main takeaway from these initial audits is that a public security audit is a great way to test the quality of an open source project along with its vulnerability management process and more importantly, how resilient the open source project’s security practices are. With CNCF graduated projects especially, which are used widely in production by some of the largest companies in the world, it is imperative that they adhere to the highest levels of security best practices.


Since the pilot has proven successful, CNCF is excited to start offering this to other projects that are interested, with preference given to graduated projects.

With funds provided by the CNCF community to conduct the Kubernetes security audit, the Security Audit Working Group was formed to lead the process of finding a reputable third party vendor. The group created an open request for proposals, taking responsibility for evaluating the submitted proposals and recommending the vendor best suited to complete a security assessment against Kubernetes, bearing in mind the high complexity and wide scope of the project. The working group selected two firms to perform this work: Trail of Bits and Atredis Partners. The team felt that the combination of these two firms, both composed of very senior and well-known staff in the information security industry, would provide the best possible results. 

The Security Audit Working Group managed the audit over a four month time span. Throughout the course of this work, a component-focused threat model of the Kubernetes system was conducted Working with members of the Security Audit Working Group, as well as a number of Kubernetes SIGs,this threat model reviewed Kubernetes’ components across six control families:

  • Networking
  • Cryptography
  • Authentication
  • Authorization
  • Secrets Management
  • Multi-tenancy

Since Kubernetes itself is a large system, with functionality spanning from API gateways to container orchestration to networking and beyond, the Third Party Security Audit Working Group, in concert with Trail of Bits and Atredis Partners, selected eight components within the larger Kubernetes ecosystem for evaluation in the threat model:

  • Kube-apiserver
  • Etcd
  • Kube-scheduler
  • Kube-controller-manager
  • Cloud-controller-manager
  • Kubelet
  • Kube-proxy
  • Container Runtime

The assessment yielded a significant amount of knowledge pertaining to the operation and internals of a Kubernetes cluster. Findings and supporting documentation from the assessment has been made available today, and can be found here.

There were a number of Kubernetes-wide findings, including:

  1. Policies may not be applied, leading to a false sense of security.
  2. Insecure TLS is in use by default.
  3. Credentials are exposed in environment variables and command-line arguments. 
  4. Names of secrets are leaked in logs.
  5. No certificate revocation.
  6. seccomp is not enabled by default.

Guidance was provided to promote further assessments and discussion of Kubernetes from the perspectives of cluster administrators and developers:

Recommendations for cluster administrators included:

  • Attribute Based Access Controls vs Role Based Access Controls
  • RBAC best practices
  • Node-host configurations and permissions
  • Default settings and backwards compatibility
  • Networking
  • Environment considerations
  • Logging and alerting

Recommendations for Kubernetes developers included:

  • Avoid hardcoding paths to dependencies
  • File permissions checking
  • Monitoring processes on Linux
  • Moving processes to a cgroup
  • Future cgroup considerations for Kubernetes
  • Future process handling considerations for Kubernetes

This audit process was partially inspired by, the Core Infrastructure Initiative (CII) Best Practices Badge program that all CNCF projects are required to go through. This badge, provided by the Linux Foundation, is a way for open source projects to show that they follow security best practices. Consumers of the badge can quickly assess which open source projects are following best practices and as a result are more likely to produce higher-quality secure software.

Finally, we hope that open sourcing our security audits and process, we inspire other projects to pursue them in their respective open source communities.

The CNCF wishes to thank the members of the Security Audit Working Group, as well as Kubernetes community who assisted in the threat model and audit work: 

Aaron Small, Google          Security Audit Working Group member

Craig Ingram, Salesforce    Security Audit Working Group member

Jay Beale, InGuardians      Security Audit Working Group member

Joel Smith, Red Hat           Security Audit Working Group member


Sam Lambert Elected to CNCF End User TOC seat

By | Blog

GitHub Also Chronicles Journey With Kubernetes

The CNCF End User Community elected Sam Lambert, Senior Director of Infrastructure Engineering at GitHub, to the End User Technical Operating Committee (TOC) seat this week. Sam will join the other TOC members, representing the end user community. GitHub has recently adopted Kubernetes.

“We are thrilled to welcome Sam Lambert from GitHub to the CNCF TOC,” said Chris Aniszczyk, COO at The Cloud Native Computing Foundation. “The End User Community is one of the most important and formal parts of CNCF. We have been cultivating our End User Community since the beginning and look forward to their formal representation on the TOC.”

We look forward to Sam’s insight into end user adoption of these cloud native technologies and welcome Github to the community! Below please find a post detailing GitHub’s work with Kubernetes. Originally posted on GitHub Engineering.

Kubernetes at GitHub

Over the last year, GitHub has gradually evolved the infrastructure that runs the Ruby on Rails application responsible for and We reached a big milestone recently: all web and API requests are served by containers running in Kubernetes clusters deployed on our metal cloud. Moving a critical application to Kubernetes was a fun challenge, and we’re excited to share some of what we’ve learned with you today.

Why change?

Before this move, our main Ruby on Rails application (we call it github/github) was configured a lot like it was eight years ago: Unicorn processes managed by a Ruby process manager called God running on Puppet-managed servers. Similarly, our chatops deployment worked a lot like it did when it was first introduced: Capistrano established SSH connections to each frontend server, then updated the code in place and restarted application processes. When peak request load exceeded available frontend CPU capacity, GitHub Site Reliability Engineers would provision additional capacity and add it to the pool of active frontend servers.

While our basic production approach didn’t change much in those years, GitHub itself changed a lot: new features, larger software communities, more GitHubbers on staff, and way more requests per second. As we grew, this approach began to exhibit new problems. Many teams wanted to extract the functionality they were responsible for from this large application into a smaller service that could run and be deployed independently. As the number of services we ran increased, the SRE team began supporting similar configurations for dozens of other applications, increasing the percentage of our time we spent on server maintenance, provisioning, and other work not directly related to improving the overall GitHub experience. New services took days, weeks, or months to deploy depending on their complexity and the SRE team’s availability. Over time, it became clear that this approach did not provide our engineers the flexibility they needed to continue building a world-class service. Our engineers needed a self-service platform they could use to experiment, deploy, and scale new services. We also needed that same platform to fit the needs of our core Ruby on Rails application so that engineers and/or robots could respond to changes in demand by allocating additional compute resources in seconds instead of hours, days, or longer.

In response to those needs, the SRE, Platform, and Developer Experience teams began a joint project that led us from an initial evaluation of container orchestration platforms to where we are today: deploying the code that powers and api.github.comto Kubernetes clusters dozens of times per day. This post aims to provide a high-level overview of the work involved in that journey.

Why Kubernetes?

As a part of evaluating the existing landscape of “platform as a service” tools, we took a closer look at Kubernetes, a project from Google that described itself at the time as an open-source system for automating deployment, scaling, and management of containerized applications. Several qualities of Kubernetes stood out from the other platforms we evaluated: the vibrant open source community supporting the project, the first run experience (which allowed us to deploy a small cluster and an application in the first few hours of our initial experiment), and a wealth of information available about the experience that motivated its design.

These experiments quickly grew in scope: a small project was assembled to build a Kubernetes cluster and deployment tooling in support of an upcoming hack week to gain some practical experience with the platform. Our experience with this project as well as the feedback from engineers who used it was overwhelmingly positive. It was time to expand our experiments, so we started planning a larger rollout.

Why start with github / github?

At the earliest stages of this project, we made a deliberate decision to target the migration of a critical workload: github/github. Many factors contributed to this decision, but a few stood out:

  • We knew that the deep knowledge of this application throughout GitHub would be useful during the process of migration.
  • We needed self-service capacity expansion tooling to handle continued growth.
  • We wanted to make sure the habits and patterns we developed were suitable for large applications as well as smaller services.
  • We wanted to better insulate the app from differences between development, staging, production, enterprise, and other environments.
  • We knew that migrating a critical, high-visibility workload would encourage further Kubernetes adoption at GitHub.

Given the critical nature of the workload we chose to migrate, we needed to build a high level of operational confidence before serving any production traffic.

Rapid iteration and confidence building with a review lab

As a part of this migration, we designed, prototyped, and validated a replacement for the service currently provided by our frontend servers using Kubernetes primitives like Pods, Deployments, and Services. Some validation of this new design could be performed by running github/github’s existing test suites in a container rather than on a server configured similarly to frontend servers, but we also needed to observe how this container behaved as a part of a larger set of Kubernetes resources. It quickly became clear that an environment that supported exploratory testing of the combination of Kubernetes and the services we intended to run would be necessary during the validation phase.

Around the same time, we observed that our existing patterns for exploratory testing of github/github pull requests had begun to show signs of growing pains. As the rate of deploys increased along with the number of engineers working on the project, so did the utilization of the several additional deploy environments used as a part of the process of validating a pull request to github/github. The small number of fully-featured deploy environments were usually booked solid during peak working hours, which slowed the process of deploying a pull request. Engineers frequently requested the ability to test more of the various production subsystems on “branch lab.” While branch lab allowed concurrent deployment from many engineers, it only started a single Unicorn process for each, which meant it was only useful when testing API and UI changes. These needs overlapped substantially enough for us to combine the projects and start work on a new Kubernetes-powered deployment environment for github/github called “review lab.”

In the process of building review lab, we shipped a handful of sub-projects, each of which could likely be covered in their own blog post. Along the way, we shipped:

  • A Kubernetes cluster running in an AWS VPC managed using a combination of Terraform and kops.
  • A set of Bash integration tests that exercise ephemeral Kubernetes clusters, used heavily in the beginning of the project to gain confidence in Kubernetes.
  • A Dockerfile for github/github.
  • Enhancements to our internal CI platform to support building and publishing containers to a container registry.
  • YAML representations of 50+ Kubernetes resources, checked into github/github.
  • Enhancements to our internal deployment application to support deploying Kubernetes resources from a repository into a Kubernetes namespace, as well as the creation of Kubernetes secrets from our internal secret store.
  • A service that combines haproxy and consul-template to route traffic from Unicorn pods to the existing services that publish service information there.
  • A service that reads Kubernetes events and sends abnormal ones to our internal error tracking system.
  • chatops-rpc-compatible service called kube-me that exposes a limited set of kubectl commands to users via chat.

The end result is a chat-based interface for creating an isolated deployment of GitHub for any pull request. Once a pull request passed all required CI jobs, a user can deploy their pull request to review lab like so:

Like branch lab before it, labs are cleaned up one day after their last deploy. As each lab is created in its own Kubernetes namespace, cleanup is as simple as deleting the namespace, which our deployment system performs automatically when necessary.

Review lab was a successful project with a number of positive outcomes. Before making this environment generally available to engineers, it served as an essential proving ground and prototyping environment for our Kubernetes cluster design as well as the design and configuration of the Kubernetes resources that now describe the github/github Unicorn workload. After release, it exposed a large number of engineers to a new style of deployment, helping us build confidence via feedback from interested engineers as well as continued use from engineers who didn’t notice any change. And just recently, we observed some engineers on our High Availability team use review lab to experiment with the interaction between Unicorn and the behavior of a new experimental subsystem by deploying it to a shared lab. We’re extremely pleased with the way that this environment empowers engineers to experiment and solve problems in a self-service manner.

Kubernetes on Metal

With review lab shipped, our attention shifted to To satisfy the performance and reliability requirements of our flagship service – which depends on low-latency access to other data services – we needed to build out Kubernetes infrastructure that supported the metal cloud we run in our physical data centers and POPs. Again, nearly a dozen subprojects were involved in this effort:

  • A timely and thorough post about container networking helped us select the Caliconetwork provider, which provided the out-of-the box functionality we needed to ship a cluster quickly in ipip mode while giving us the flexibility to explore peering with our network infrastructure later.
  • Following no less than a dozen reads of @kelseyhightower’s indispensable Kubernetes the hard way, we assembled a handful of manually provisioned servers into a temporary Kubernetes cluster that passed the same set of integration tests we used to exercise our AWS clusters.
  • We built a small tool to generate the CA and configuration necessary for each cluster in a format that could be consumed by our internal Puppet and secret systems.
  • We Puppetized the configuration of two instance roles – Kubernetes nodes and Kubernetes apiservers – in a fashion that allows a user to provide the name of an already-configured cluster to join at provision time.
  • We built a small Go service to consume container logs, append metadata in key/value format to each line, and send them to the hosts’ local syslog endpoint.
  • We enhanced GLB, our internal load balancing service, to support Kubernetes NodePort Services.

The combination of all of this hard work resulted in a cluster that passed our internal acceptance tests. Given that, we were fairly confident that the same set of inputs (the Kubernetes resources in use by review lab), the same set of data (the network services review lab connected to over a VPN), and same tools would create a similar result. In less than a week’s time – much of which was spent on internal communication and sequencing in the event the migration had significant impact – we were able to migrate this entire workload from a Kubernetes cluster running on AWS to one running inside one of our data centers.

Raising the confidence bar

With a successful and repeatable pattern for assembling Kubernetes clusters on our metal cloud, it was time to build confidence in the ability of our Unicorn deployment to replace the pool of current frontend servers. At GitHub, it is common practice for engineers and their teams to validate new functionality by creating a Flipper feature and then opting into it as soon as it is viable to do so. After enhancing our deployment system to deploy a new set of Kubernetes resources to a github-production namespace in parallel with our existing production servers and enhancing GLB to support routing staff requests to a different backend based on a Flipper-influenced cookie, we allowed staff to opt-in to the experimental Kubernetes backend with a button in our mission control bar:

The load from internal users helped us find problems, fix bugs, and start getting comfortable with Kubernetes in production. During this period, we worked to increase our confidence by simulating procedures we anticipated performing in the future, writing runbooks, and performing failure tests. We also routed small amounts of production traffic to this cluster to confirm our assumptions about performance and reliability under load, starting with 100 requests per second and expanding later to 10% of the requests to and With several of these simulations under our belt, we paused briefly to re-evaluate the risk of a full migration.

Cluster Groups

Several of our failure tests produced results we didn’t expect. Particularly, a test that simulated the failure of a single apiserver node disrupted the cluster in a way that negatively impacted the availability of running workloads. Investigations into the results of these tests did not produce conclusive results, but helped us identify that the disruption was likely related to an interaction between the various clients that connect to the Kubernetes apiserver (like calico-agentkubeletkube-proxy, and kube-controller-manager) and our internal load balancer’s behavior during an apiserver node failure. Given that we had observed a Kubernetes cluster degrade in a way that might disrupt service, we started looking at running our flagship application on multiple clusters in each site and automating the process of diverting requests away from a unhealthy cluster to the other healthy ones.

Similar work was already on our roadmap to support deploying this application into multiple independently-operated sites, and other positive trade-offs of this approach – including presenting a viable story for low-disruption cluster upgrades and associating clusters with existing failure domains like shared network and power devices – influenced us to go down this route. We eventually settled on a design that uses our deployment system’s support for deploying to multiple “partitions” and enhanced it to support cluster-specific configuration via a custom Kubernetes resource annotation, forgoing the existing federation solutions for an approach that allowed us to use the business logic already present in our deployment system.

From 10% to 100%

With Cluster Groups in place, we gradually converted frontend servers into Kubernetes nodes and increased the percentage of traffic routed to Kubernetes. Alongside a number of other responsible engineering groups, we completed the frontend transition in just over a month while keeping performance and error rates within our targets.

During this migration, we encountered an issue that persists to this day: during times of high load and/or high rates of container churn, some of our Kubernetes nodes will kernel panic and reboot. While we’re not satisfied with this situation and are continuing to investigate it with high priority, we’re happy that Kubernetes is able to route around these failures automatically and continue serving traffic within our target error bounds. We’ve performed a handful of failure tests that simulated kernel panics with echo c > /proc/sysrq-trigger and have found this to be a useful addition to our failure testing patterns.

What’s next?

We’re inspired by our experience migrating this application to Kubernetes, and are looking forward to migrating more soon. While scope of our first migration was intentionally limited to stateless workloads, we’re excited about experimenting with patterns for running stateful services on Kubernetes.

During the last phase of this project, we also shipped a workflow for deploying new applications and services into a similar group of Kubernetes clusters. Over the last several months, engineers have already deployed dozens of applications to this cluster. Each of these applications would have previously required configuration management and provisioning support from SREs. With a self-service application provisioning workflow in place, SRE can devote more of our time to delivering infrastructure products to the rest of the engineering organization in support of our best practices, building toward a faster and more resilient GitHub experience for everyone.


We’d like to extend our deep thanks to the entire Kubernetes team for their software, words, and guidance along the way. I’d also like to thank the following GitHubbers for their incredible work on this project: @samlambert@jssjr@keithduncan@jbarnette@sophaskins@aaronbbrown@rhettg@bbasata, and @gamefiend.

 Post by Jesse Newland, Principal Site Reliability Engineer, GitHub

Meet CNCF’s Newest Developer Advocate

By | Blog

By: Chris Aniszczyk, COO at the Cloud Native Computing Foundation (CNCF)

Last week at Open Source Summit North America, I took the keynote stage to announce that the CNCF TOC voted in our 11th and 12th projects; Envoy and Jaeger. Supporting a dozen projects in 2 years from the Foundation’s start is a major milestone and a key indicator of the tremendous impact cloud native community is having on the technology industry.

With great success comes great responsibility, which is why we have hired a full-time Developer Advocate dedicated to the development, advocacy and community cultivation for CNCF projects.

Many of you may know Ihor Dvoretskyi, Kubernetes SIG-PM, and SIG-OpenStack co-lead. He has been involved into Kubernetes release process as a features lead for Kubernetes releases 1.6, 1.7, and 1.8. Also, he has been working on expanding the Cloud Native community ecosystem in EMEA region as CNCF Ambassador. Ihor has a strong technical background, together with solid communication and community-building skills to support CNCF’s projects.

In his new role, Ihor will still focus on Kubernetes-related efforts, but will also act as a developer advocate for all of CNCF’s projects. He will also be helping us cultivate and grow our CNCF ambassador community.

You can connect with Ihor on Twitter at @idvoretskyi and on GitHub at

Check out his articles for, Kubernetes 1.7 announcement blog post he co-authored, and his recent appearance at The New Stack podcast, highlighting the Kubernetes project management aspects, and if you are attending Open Source Summit Europe, come to his presentation on Kubernetes 1.8.

We’re excited to welcome Ihor to the CNCF!

CNCF Brings Kubernetes, CoreDNS, OpenTracing and Prometheus to Google Summer of Code 2017

By | Blog

The Google Summer of Code (GSOC) program allows university students (over the age of 18) from around the world to spend their summer breaks writing code and learning about open source development. Accepted students work with a mentor and become a part of the open source community. In its 13 year, the program has previously accepted 12,000+ students from 104 countries to work on 568 open source projects, writing over 30 million lines of code.

201 organizations were accepted to participate in GSOC 2017 to bring new, excited developers into their community and the world of open source. The Cloud Native Computing Foundation is proud to be one of these organizations, bringing seven interns this summer. Mentors were paired with interns to help advance the following CNCF projects: 4 Kubernetes, 1 CoreDNS, 1 OpenTracing and 1 Prometheus.

“As a former GSOC mentor, I have seen the amazing impact this program has on the students, projects and larger open source community. CNCF is very proud to have 7 projects in the 2017 program that cover a range of our cloud native technologies. We look forward to watching the progress and results of the students over the summer.” – Chris Aniszczyk (@cra)

Additional details on the projects, mentors, and students can be found below. Coding beings May 30 and we’ll report back on their progress in a few months.  


Create and Implement a Data Model to Standardize Kubernetes Logs

Student: Amit Kumar Jaiswal, UIET CSJM University

Mentor: Miguel Perez Colino, Red Hat

This project aims to build and implement a data model for logs in a large Kubernetes cluster to process, correlate, and query to make troubleshooting easier and reduce the time in finding root causes.

Develop a Set of Jupyter Notebooks for the Kubernetes Python Client + Kubernetes Python Client Update

Student: Konrad Djimeli, University of Buea       

Mentor: Sebastien Goasguen, Skippbox (acquired by Bitnami)

The Kubernetes python client is a Kubernetes incubator project. The python client makes it possible to access Kubernetes with python. Jupyter notebook extends the console-based approach to interactive computing in a qualitatively new direction, providing a web-based application suitable for capturing the whole computation process. The aim of this project is to develop a set of notebooks that highlight the Kubernetes primitives. This project would also include updating the python client to make it easier for users to carry out certain operations.

Improve ThirdPartyResources  

Student: Nikhita Raghunath, Veermata Jijabai Technological Institute (Mumbai)

Mentor: Stefan Schimanski, Red Hat

ThirdPartyResources are already available, but the implementation has languished with multiple outstanding capabilities missing. They did not complete the list of requirements for graduating to beta. Hence, there are multiple problems present in the current implementation of ThirdPartyResources. This project aims to work towards a number of known shortcomings to drive the ongoing effort toward a stable TPR release forward.

Integrate Unikernel Runtime

Student: Hao Zhang, Zhejiang University, Computer Science (master)

Mentor: Harry Zhang, Lob and Pengfei Ni, HyperHQ

This work will focus on  why and how to integrate unikerneal technology as a runtime into into the Kubernetes/frakti project. This will allow Kubernetes to use use a unikernel instance just like it uses Docker, which eventually will open  Kubernetes up to more more application scenarios.


CoreDNS: Middleware

Student: Antoine Debuisson (University of Paris-Sud)

Mentor: Miek Gieben, CoreDNS and John Belamaric, Infoblox

The goal of the project is to capture the DNS data within a CoreDNS middleware and write it to a “dnstap log file” (perhaps over the network).

Codebase to build upon:


Instrument OpenTracing with Go-restful Web Framework

Student: Liang Mingqiang, Hyogo University and Carnegie Mellon University

Mentor: Ted Young, LightStep and Wu Sheng, OpenTracing

Go-restful ( is a widely-used library for building REST-style Web Services using Google Go programming language. With powerful built-in modules, including intelligent request routing, RESTful support and filters for intercepting HTTP request, go-restful makes it very convenient to build a web application from scratch. This proposal aims to instrument OpenTracing with go-restful.


Storage and Query Engine Improvements to Prometheus

Student: Goutham Veeramachaneni, Indian Institute of Technology, Hyderabad

Mentor: Ben Kochie, SoundCloud, Fabian Reinartz, CoreOS and Julius Volz, Prometheus

While the Prometheus monitoring system solves most use-cases, improvements will  will reduce the already minimal load on the ops team, including  checking alerts over time, unit-testing alerts, backups and figuring out which queries OOM.

FOSDEM 2017 Recap: Monitoring and Cloud Devroom & Linux Containers and Microservices Devroom Sponsored by CNCF

By | Blog

Each year, FOSDEM attracts more than 8,000 developers as Josh Berkus, the project atomic community lead at Red Hat, puts it, the event is “a great way to reach a large number of open source geeks, community members and potential contributors.” Richard Hartmann, project director and system architect at SpaceNet AG, even dubbed it “the largest of its kind in Europe and, most likely, the world.”

To display some of the cloud native space’s brightest insight and engage with our ever-growing community, we sponsored the Monitoring and Cloud Devroom and the Linux Containers and Microservices Devroom.

On Sunday, the Linux Containers and Microservices Devroom room was overflowing with 200+ infrastructure hackers, devops admins and more – all gathered to learn more about new containerized application stacks, from the practical to the theoretical. The room was at capacity throughout the day. According to Diane Mueller-Klingspor, director of community development for Red Hat OpenShift, it was “so popular that very few relinquished their seats between talks. When people did leave, the entire row just shifted to fill the seat if it was in the middle, leaving an open seat on the end of the row for newcomers. We called this the ‘Open Shift’ which the audience got a good kick out of.”

That same day the Monitoring and Cloud Devroom kicked off with an equally eager group of developers. The Devroom, which was the largest FOSDEM has to offer, was also packed and demonstrated that as the world moves to cloud- and microservice-based architectures, monitoring is super important to aid observability and diagnose problems.

Here are more highlights from our community ambassadors on why these “grassroots” gatherings foster such excitement in the cloud native community:

Mueller-Klingspor: “Attendees of these Devrooms weren’t just hackers or people hacking on Kube, they were downright serious about the topic of microservices and containers. These developers were looking for information to help empower them to get their organizations up and running using microservices, containers and, of course, orchestrating it all with Kubernetes. Unlike the FOSDEM Devrooms I’ve attended in the past, the Linux Containers and Microservices Devroom was not filled with dilettantes; everyone here had already committed to the cloud native mindset and was looking for deep technical information to help them get the job done.”

Berkus: “The technical content for the day was really good. In the end, we ended up with a program where most of the talks effectively built on each other really rewarding the attendees who sat through the whole day (and there were more than a few). From my perspective, the top takeaways for developers who dropped into the Containers and Microservices Devroom were:

  • Kubernetes is the main cloud native orchestration platform;
  • Communications between containers is moving from REST to gRPC in upstream development; and
  • You can containerize Java applications too, and there are some real benefits to that.”

Chris Aniszczyk, COO of CNCF: “The presentations were especially amazing for those new to cloud native monitoring. We kicked off with a talk about the history of monitoring and then transitioned into the general categories of metrics, logs, profiling and distributed tracing, along with dives into how each of these is important. My main takeaway from the Monitoring and Cloud Devroom was how critical monitoring is becoming as companies scale out their operations in the cloud. We heard from and Wikimedia about some of the challenges they had with monitoring at scale. I was also thrilled to hear the Prometheus project woven into almost every monitoring talk in the devroom; it’s becoming a fantastic open source choice for cloud native monitoring.”

Hartmann: “From my perspective, the main theme of the Monitoring and Cloud Devroom was to help people lead their teams to cloud-native technology and how to enact said change in a way that their teams want to play along. One of the biggest takeaways for developers was to make sure, first and foremost, to focus on user-visible services. FOSDEM is the world’s single largest FLOSS developer conference with dozens of satellite mini-conferences, team meetings and more. Sponsoring these Devrooms helps to support these efforts, gives back to the community and ensures that CNCF gets better acquainted with traditional developers.”

Here’s a list of of speakers and their topics with links to videos in case you missed FOSDEM:

Cloud Native Computing Foundation Announces Full Keynotes And Programming for CloudNativeCon, KubeCon and PrometheusDay

By | Announcement

Top open source, container and cloud native technologists, including multiple founding members of the Kubernetes project, will gather to further the education and advancement of cloud native computing

SAN FRANCISCO – September 15, 2016 – The Cloud Native Computing Foundation, which is advancing the development of open source software stacks that orchestrate containers of microservices, today announced initial programming and speakers for CloudNativeCon and co-located events KubeCon andPrometheusDay, taking place November 8-9 in Seattle.

CloudNativeCon will bring together leading contributors in cloud native applications and computing, containers, microservices, central orchestration processing, and related projects to further industry education. Co-located with KubeCon and PrometheusDay, attendees will be able to attend a full range of technology sessions that support the cloud native ecosystem.

During KubeCon, attendees will have the opportunity to meet with leading Kubernetes technologists, from multiple open source cloud native communities, working with one of the highest velocity open source projects. Kubernetes use has exploded in the last year and so has the desire for many to further their education. KubeCon will bring together this quickly growing community to advance their knowledge of Kubernetes use with containers and cloud native architectures. Similarly, PrometheusDay will feature technical talks covering major Prometheus adopters, leading expert contributor insights, and a full range of technologies that support open source monitoring technology in the cloud native ecosystem.

“Cloud native computing can be a very fragmented process, as the architecture departs from traditional enterprise application design,” said Dan Kohn, executive director of the Cloud Native Computing Foundation. “Our new flagship event CloudNativeCon will be able to build on the great following and momentum KubeCon has already established. The event will squarely focus on helping developers better understand how to easily and quickly assemble these moving parts by driving alignment among different cloud native technologies and platforms.”

A panel featuring developers involved with MidoNet, Contiv Calico, and Flannel will share how they have implemented their own networking for Kubernetes and offer unique perspectives on how their respective projects augment native Kubernetes networking. “Kubernetes Networking Panel: Collaborate on the Spec, Compete on Execution,” will feature panel moderator and Top Women in Cloud winner Susan Wu, director of technical marketing at Midokura.

Additionally, the schedule includes a mix of engaging sessions, case studies, tutorials and lightning talks, featuring the following presenters:

  • “Unik: Unikernel runtime for Kubernetes,” from CTO, Cloud Management Division, at EMC Dell, Idit Levine

  • “Automating Infrastructure Deployment for Kubernetes,” from Principal Software Engineer at Rancher Labs, Alena Prokharchyk

  • “How to Monitor Application Performance in a Container-Based World,” from Cisco Principal Engineer, Fabio Giannetti

  • “Processing Billions of Events in Real-Time with Heron,” from Engineering Manager and Technical Lead for Real Time Analytics at Twitter, Karthik Ramasamy

  • “Sentinel: A Platform for Fine-grained Application Security,” from eBay Senior Software Engineer, Sudheendra Murthy

  • “Does Cloud Native Mean Container Native?” from Distinguished Engineer at IBM Research, James Bottomley

  • “Kubernetes: As Seen On TV,” from Comcast Systems Architect, Erik St. Martin

  • “Everything you Ever Wanted to Know About Resource Scheduling, but Were Afraid to Ask,” from Senior Staff Software Engineer of Cluster Management at Google, Tim Hockin

  • “Kompose: The Docker-compose of Kubernetes,” from Founder of Skippbox, Sébastien Goasguen

  • “Running a Top 5 E-Commerce Website on Kubernetes,” from Senior Vice President of TechOps, Justin Dean

  • “How Box Runs Containers in Production with Kubernetes,” from Box Co-Founder, Sam Ghods

  • “Plumbing the Cloud for Containers,“ from Product Manager at Docker, Michael Friis

  • “Taking the Helm: Delivering Kubernetes-Native Applications,” Software Engineer on the Kubernetes Helm project, Michelle Noorali

  • “Monitoring Kubernetes Clusters with Prometheus,” from Engineer at CoreOS and core Prometheus developer, Fabian Reinartz

  • “Project Frankenstein: Multitenant, Horizontally Scalable Prometheus as a Service,” from Director of Software Engineering at Weaveworks, Tom Wilkie

The full CloudNativeCon agenda can be viewed here; the KubeCon program can be viewed here. Stay tuned for the PrometheusDay schedule.

Additionally, proposals for lightning talks are still being accepted through September 23.

CloudNativeCon is made possible by support from Diamond Sponsors Apprenda, Cisco, CoreOS, Google, IBM, Intel, and Red Hat; along with 25 additional Platinum Sponsors, Gold Sponsors, Silver Sponsors, and Media Sponsors. For more information on sponsorship, please visit

Register by September 23 for pricing of $400 for individuals and $850 for corporations. Registration for CloudNativeCon provides complimentary access to all CNCF co-located events: KubeCon and PrometheusDay.

CNCF Diversity Scholarship

The Foundation will be offering three scholarships to members of traditionally underrepresented and/or marginalized groups in the technology and/or open source communities.  Visit to learn more about the scholarship and apply.

About Cloud Native Computing Foundation

Cloud native computing uses an open source software stack to deploy applications as microservices, packaging each part into its own container, and dynamically orchestrating those containers to optimize resource utilization. The Cloud Native Computing Foundation (CNCF) hosts critical components of those software stacks including Kubernetes and Prometheus; brings together the industry’s top developers, end users, and vendors; and serves as a neutral home for collaboration. CNCF is part of The Linux Foundation. For more information about CNCF, please visit:



The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see our trademark usage page: Linux is a registered trademark of Linus Torvalds.

Media Contact

Natasha Woods

The Linux Foundation