KubeCon + CloudNativeCon North America 2018

gRPC C++ team has been working on performance for over a year now. In this presentation we will share the story of our journey, sharing insights on tuning applications that use gRPC as well as optimizing the library itself.

All concrete examples will be from gRPC, but the high level concepts will be interesting to anyone who has worked on performance.

We will focus on:
- benchmarking
+ microbenchmarks
+ synthetic benchmarks
+ application benchmarks
+ cutting down noise on benchmarks
- tooling
+ flamegraphs
+ latency breakdowns
- concrete optimizations
+ tuning the threading model of gRPC apps
+ high performance network polling systems

We live in a world where high performance, and speed are essential. A few extra seconds of response time on a dashboard can be a deal breaker. Many dashboards request the entire time range of data from the time series database, every time a dashboard loads or reloads. This can result in slower rendering times, and different results depending on when the request is made. We are proud to announce that Trickster, a new open source project, was developed to address this very issue.

Written in Go, Trickster is a reverse proxy cache for the Prometheus HTTP APIv1 that considerably accelerates dashboard rendering times for any series queried from Prometheus. This is possible because of the delta proxy, step boundary normalization, and fast forward features. In the presentation, we will discuss how Trickster was developed at Comcast, and we will show you a live demo of the software.

Since the Linux kernel 4.x series a lot of enanchements reached mainline to the eBPF ecosystem giving us the capability to do a lot more than just network stuff.
The purpose of this talk is to give an initial understanding on what eBPF programs are and how to hook them to programs running inside Kubernetes clusters in order to answer targeted questions at cluster level but about very specific fine-grained situations happening in our programs and systems, like:
- Had that function in my program been called ?
- For a given function which arguments have been passed to it? And what it did return?
- Which TCP packets are being retransmitted?
- What are the queries running slow?
- Insights on programming language events/gc
- Had that file been opened?
Imagine a programmable Kubernetes performance analysis tool that runs at cluster level without performance implications how would you it to be?

Tasked with rebuilding the way we deliver music to DJ's, the Beatport Infrastructure team set out to use Kubernetes to construct scalable compute for executing batch and on-demand encoding workloads in order to level-up our customer's capabilities for playing and mixing dance music.

What would follow is a 5-month journey of building clusters, thrashing with software dependencies, and trudging through erratic performance and scalability issues with the kubernetes API.

How did we decide to use kubernetes?
Was it easy to prototype?

Is etcd capable of sustainably servicing 10,000 Jobs an hour?
How many Pods can the kubernetes API store?
How do you monitor and manage Job failures?

We'll walk you through our lessons learned and talk about our most exciting moments and deflating realizations.
Join us we re-tell the story of delivering a correct system to production :)

Have you ever wondered how much ingress traffic a Kubernetes cluster could handle? How many nodes would it take to handle the traffic of an Alexa top-40 website? Understanding these numbers and how your ingress infrastructure scales is critical when it comes to deploying internet-accessible applications in production.
 
 At Heptio, we needed to prove that our Envoy-based ingress projects, Contour and Gimbal, would scale to support millions of concurrent connections, thousands of backend services, and thousands of virtual hosts.
 
 In this talk, we will explore the strategies and tools we used, the challenges we faced and the lessons we learned while running these tests. We will dive into kernel tuning, HTTP benchmarking, Envoy metrics, and more. We hope that talking about our experience will help when it comes to performance testing your cloud-native applications and infrastructure.

Kubernetes supports large clusters according to the docs, but how does it actually scale? Who came up with those limits? What are the actual numbers? To challenge this we built a CI/CD environment geared towards deploying, and testing, Kubernetes at Scale.

Our stack consists of Kubernetes, OpenStack for IaaS, Jenkins Pipeline, Ansible for automation, pbench a performance benchmarking, and visualizing tool, Prometheus and other Open Source projects. The stack has pushed the performance and scale limits of Kubernetes with kubelet, control plane and cluster density focused tests. In this presentation we will explore the story and challenges on how we built and tested this stack. We will demo the test harness and share the latest performance and scale results. Attendees will learn what the real scalability limits of Kubernetes are, as well as how to scale-test their own infrastructure.