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.
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:
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:
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:
Policies may not be applied, leading to a false sense of security.
Insecure TLS is in use by default.
Credentials are exposed in environment variables and command-line arguments.
Names of secrets are leaked in logs.
No certificate revocation.
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
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
“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 onGitHub Engineering.
Over the last year, GitHub has gradually evolved the infrastructure that runs the Ruby on Rails application responsible for github.com and api.github.com. 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.
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 github.com 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.
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.
A 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 github.com. 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 github.com and api.github.com. With several of these simulations under our belt, we paused briefly to re-evaluate the risk of a full migration.
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-agent, kubelet, kube-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.
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.
By: Chris Aniszczyk, COO at the Cloud Native Computing Foundation (CNCF)
Last week atOpen Source Summit North America, I took the keynote stage to announce that the CNCF TOC voted in our 11th and 12th projects;Envoy andJaeger. 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 knowIhor 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.
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.
201organizationswere 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.
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.
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.
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).
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 (https://github.com/emicklei/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.
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.”
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 Booking.com 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:
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 Ticketmaster.com 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.
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 http://bit.ly/2958nFA 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: https://cncf.io/.
The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see our trademark usage page: https://www.linuxfoundation.org/trademark-usage. Linux is a registered trademark of Linus Torvalds.