We will showcase 10 lightning talks lasting 10 minutes each!
Talk #1:
Presenter: Cameron Brunner, Director of Engineering, Univa
Title: Network Booting Kubernetes
Abstract: This presentation will discuss bare metal installation of Kubernetes as well as ongoing configuration management of a bare metal cluster. Tips and tricks to help get a conformance passing cluster leveraging PXE and cloud-init as well as future cluster upgrades, cluster scaling, and integration with cloud services will be discussed.
Talk #2:
Presenter: Jimmy Cuadra
Title: kaws: Deploying Kubernetes Clusters using AWS, CoreOS, Terraform, and Rust
Abstract: Kubernetes is complex software and setting up a new cluster can be difficult. While there are easy approaches like Google Container Engine, you may want to customize your cluster in various ways, or simply understand how it all works. A great way to do this is to define your cluster as code using Terraform. In this talk, you'll learn about kaws, a tool written in the Rust programming language that brings together several platforms and tools to automate the creation and management of secure, highly available Kubernetes clusters.
Talk #3:
Presenter: Tyler Jewell, Founder and CEO, Codenvy
Title: A DevOps Workspace for OpenShift & Kubernetes
Abstract: "Introducing a new kind of IDE for Kubernetes & OpenShift. A preview of a Red Hat + Codenvy open source collaboration that makes debuggable dev environments linked to Kubernetes pods.
Talk #4:
Presenter: Oliver Gould, Co-Founder and CTO, Buoyant
Title: Application Routing on Kubernetes
Abstract: What happens if you run hundreds of services and millions of RPS in Kubernetes? How do you prevent a single slow instances from impacting site success? How do you stage new services safely in such a complex system? I'll describe some of Twitter's experience building and operating an extremely large microservice system; and how Buoyant applying these lessons in Kubernetes.
Talk #5:
Presenter: Sasan Padidar, Co-Founder and CTO, FlawCheck
Title: Why we need to rethink container security
Abstract: One reason enterprises are moving slowly on adopting containers is because old security models do not work well in this ecosystem. The agility of orchestration system such as Kubernetes makes it difficult for traditional security solutions to meet the needs of this ecosystem. Security in container ecosystems managed by Kubernetes need to integrate tightly with it, and be as agile. In this short talk, we’ll cover the risks associated with having unchecked containers running in production.
Talk #6:
Presenter: Powell Kinney, CTO of Vinli
Title: Tooling Kubernetes for us lowly Developers
Abstract: Vinli is a connected-car platform built by developers, for developers. Our world revolves around the developer experience, as much for those building the platform as for those building on the platform. It’s essential to our process that the developers creating the platform understand the whole stack and feel comfortable with where their code will live. To do this, we have built a set of very lightweight tools that directly leverage the Kubernetes APIs, tools that tie directly into our codebase. We will present this toolset and how it ties into our code base and development process.
Talk #7:
Presenter: Ilya Dmitrichenko, Community Engineer, Weaveworks
Title: Visualizing Kubernetes Clusters with Weave Scope
Abstract: Weave Scope automatically generates a map of your containers, enabling you to intuitively understand, monitor, and control your applications. It has full support for Kubernetes, which will be show during this talk.
Talk #8:
Presenter: Sebastien Goasguen
Title: Skippbox, the Kubernetes toolbox
Abstract: To help with adoption of Kubernetes we are excited to introduce Skippbox, a toolbox for Kubernetes operations. The toolbox is inspired by the Docker toolbox and consists of: 1) boot2k8s a boot2docker variant, 2) kmachine a docker-machine variant that provisions Kubernetes on single cloud instances, 3) kcompose, a docker-compose variant which translates compose files into Kubernetes objects and launches them on a k8s endpoint 4) kui, a desktop application to manage pods/services/replication controllers on multiple k8s endpoints. Skippbox is packaged as an OS X installer and will soon also support Windows machines. Whether you are getting started, developing a new application of using multiple k8s clusters, Skippbox will make it easy.
Talk #9:
Presenter: Ilan Rabinovitch, Director of Technical Community at Datadog
Title: Monitoring Kubernetes with Datadog
Abstract: In a world of dynamic infrastructure and Kubernetes, our definition of normal changes constantly as resources shift. This leaves us with the question, what should we monitor? Join us to discuss imperative vs declartive monitoring, and how to monitor Kubernetes.
Talk #10:
Presenter: Malte Schwarzkopf, MIT CSAIL
Title: Cluster scheduling -- we can do better!
Abstract: A key responsibility of any cluster manager, including Kubernetes, is to schedule work across the cluster machines. This talk provides a very brief overview of the different approaches pursued in state-of-the-art systems, their advantages and drawbacks, and how I believe we can do better. It then introduces the Firmament scheduling platform, which can flexibly express many scheduling policies, makes high-quality scheduling decisions, and scales to very large clusters. Firmament comes with its own research cluster management system, but work to integrate it with Kubernetes is under way. I will briefly outline our current integration plans and the opportunities afforded by Poseidon, the upcoming Firmament scheduler on Kubernetes.
Weave lets you run Kubernetes clusters anywhere without configuration changes.
Having deployed Kubernetes over Weave Net, you can rely 100% on cloud portability, thanks to Weave being an L2 network.
Additionally, thanks to Weave Run and how it handles IP address allocation as well as DNS without requiring a persistant store, you can deploy etcd over Weave as well.
Now you can simply configure all of the cluster components to have fixed DNS names, all you should care about is how these services are distributed accross your compute instances, e.g. what is the size of etcd cluster and whether it is on a dedcicated machines with the right type of storage attached.
You no longer have to care about the IP address of the API server or any of those things.
