KubeCon + CloudNativeCon North America 2017

Rippy will demonstrate Docker running on his rooted Android Wear watch.
To get this working required Docker, OpenEmbedded, Yocto, and AsteroidOS which he'll explain. If all goes well with the demonstration, he'll add the watch as a Kubernetes node and schedule a pod to run on it.

Rippy's initial tweet about Docker running on his watch:
https://twitter.com/jkrippy/status/826661130693128194

A whirlwind tour of some of the most useful, interesting, and under-sold features the Kubernetes command-line has to offer.

Developers who use Kubernetes for multi-container applications face a conundrum: develop locally or on a remote Kubernetes cluster. Local development adds complexity to your development environment, since you have to run (and maintain!) your entire multi-container app locally. On the other hand, a remote Kubernetes cluster doesn’t lend itself to live coding and debugging.

In this talk, we will talk about Telepresence (https://www.telepresence.io), an open source tool for Kubernetes that lets you develop and debug a service locally, while setting up a bidirectional proxy to a remote Kubernetes cluster. With Telepresence, you can make a quick change to a service, save, and test it -- while that service has full access to Kubernetes environment variables, ConfigMap, secrets, and other services running in your Kubernetes cluster.

As software becomes more and more complex, we, as software developers, have been splitting up our code into smaller and smaller components. This is also true for the environment in which we run our code: going from bare metal, to VMs to the modern-day Cloud Native world of containers, schedulers and microservices.While we have figured out how to run containerized applications in the cloud using schedulers, we've yet to come up with a good solution to bridge the gap between getting your containers from your laptop to the cloud.

How do we build software for containers? How do we ship containers? How do we do all of it without shooting ourselves in the foot? In this talk, we'll explore how current delivery systems are falling behind, and how we need to change the mental model, create new best-practices and treat containers as a first-class citizen.

Effective communication between distributed and heterogeneous components is essential for modern service-oriented architectures to work well. REST, RPC, and brokered messaging are the most popular communication styles for achieving this, but when is it appropriate for choosing one style over the other? A well-defined microservice architecture should be accompanied by a well-defined communications semantics. This talk draws on my personal experience defining these semantics for systems I’ve built at Tesla.

Microservices create an explosion of internal and external APIs. These APIs need great docs. Many organizations end up with a jungle of wiki pages, swagger docs and API consoles. Keeping docs updated and in sync with code can be a challenge. We’ve been working on a project to help solve this problem for engineering teams internally across Cisco. The goal is to create a forward looking developer and API doc publishing pipeline that:

- Has a developer friendly editing flow
- Accepts many API spec formats (Swagger, RAML, etc)
- Supports long form documentation in markdown
- Is CI/CD pipeline friendly so that code and docs stay in sync
- Is flexible enough to be used by a wide scope of teams and technologies

This session will share many lessons learned about tooling and attendees will learn how to solve documentation challenges for internal and external facing APIs. We have found that solving this doc publishing flow is a key component of a building modern infrastructure.

Connecting all the pieces to make zero downtime continuous delivery happen at scale. We'll show real teams bring all the components come together to make high-velocity deployment to Kubernetes scale. Get a hands on view of the critical steps that go into making container management a scalable process that not only allows teams to delivery faster but with more confidence in the final result.

"With microservices every outage is like a murder mystery" is a common complaint. But it doesn't have to be! This talk gives an overview on how to monitor distributed applications. We dive into:

System metrics: Keep track of network traffic and system load.
Application logs: Collect structured logs in a central location.
Audit info: Watch for user and processes activity in the system.
Uptime monitoring: Ping services and actively monitor their availability and response time.
Application metrics: Get metrics and health information from for application via REST or JMX.
Request tracing: Gather timing data by using tools like Zipkin to retrieve and show call traces.

Kata Containers is a merge of 2 hypervisor based container runtime efforts: Hyper's runV and Intel's Clear Containers. With Kata Containers, each container is hypervisor isolated just like an EC2 or GCE instance. It is an OCI compatible runtime and as such can seamlessly work with containerd or hyperd. Moreover it fully supports the Kubernetes CRI APIs and thus can run and manage hypervisor isolated Kubernetes pods through CRI-O, containerd-cri or frakti. Finally, Kata Containers is a multi architecture project as it supports x86, ARM, Power and s390x platforms.

During this talk we will describe the Kata Containers architecture and how it drastically reduces the virtualization overhead in order to be as fast as a namepace based container runtime while being as secure as a legacy VM. We will also run a multi tenant Kubernetes demo in order to show how Kata Containers could become the cornerstone of a secure, infrastructure free, container cloud.

Understanding how your microservices based application is executing in a highly distributed and elastic cloud environment can be complicated. Distributed tracing has emerged as an invaluable technique that succeeds where traditional monitoring tools falter. Yet deploying it can be quite challenging, especially in the large scale, polyglot environments of modern companies that mix together many different technologies. In this talk we share what we have learned while building and rolling out Jaeger, our open source, OpenTracing-native distributed tracing system, to hundreds of microservices at Uber. We showcase new and exciting features that make it even more valuable to engineers.

The idea of the "service mesh" is becoming very popular in microservice design circles. However, the mechanics of deploying one into an existing infrastructure are far from simple. In this talk we will cover the logistical details of how Envoy was developed and deployed incrementally at Lyft, focusing primarily on the evolution of service mesh configuration management. We will also discuss why high level systems such as Istio are likely to be the main mechanism by which most customers ultimately get access to the technology.

Proxies have long been layered into distributed systems but rarely do we lean on them to do more than route, and balance load. In this talk we will go over how to use proxies to replace Service Discovery, control Release Managment and Traffic Shaping, and streamline Employee on-boarding/off-boarding. You'll talk away never looking at your proxies/load-balancers the same.

Many organizations start their microservices journey by (re)designing their application architecture and operational infrastructure. We started building our cloud application using this approach. We discovered that this takes a long time.

In this talk, we’ll talk about how we ended up with a different approach when we started thinking about microservices as a workflow, and not an architecture. We’ll talk about our first goal: enabling a single developer to be able to code, ship, and manage a microservice, as quickly as possible. We’ll show how we integrated Kubernetes, Docker, Prometheus, and Envoy to achieve this goal.

Finally, we’ll talk about scaling this initial goal beyond a single developer. We’ll talk about the tradeoffs of this bottoms up approach to the conventional PAAS / service mesh / application architecture strategy, and show how you can get to the same place in the end.

CRI-O is a brand new container runtime dedicated and optimized to support kubernetes workload. Its goal is to be a stable container runtime tied to kubernetes releases, replacing the docker daemon.

Historically every update of Docker has broken Kubernetes. This has led to major rewriting and fixes of Kubernetes, which is understandable since Docker is not primarily for Kubernetes. Kubernetes needs a container runtime dedicated to its specifications.

CRI-O, the name comes from the Container Runtime Interface for Open container runtimes, takes advantages of emerging standards like OCI Runtime and Image Specification, as well as open source projects to handle container images (github.com:containers/image, github.com:containers/storage) . This means as these projects advance CRI-O will be able to take advantage of the improvements and features, but all the while guaranteeing that it will not break any functionality required by the Kubernetes CRI. CRI-O works with runc and Clear Containers runtimes.

CRI-O was designed from the ground up to satisfy Kubernetes Container Runtime Interface, and currently passes all node and E2E tests. The github repository has been setup to not accept any pull requests that causes these tests to break. We will be tying the versions of CRI-O to the Kubernetes versions, to maintain complete compatibility.

This talk will describe the CRI-O architecture as well as demonstrate different kubernetes features running on top of CRI-O exercising the CRI API. The attendees will learn how to configure CRI-O with kubernetes and use it for their workloads.

At KubeCon EU, in Berlin, I got up on stage and stated that "Kubernetes Sucks (but all software sucks)". While we still have work to do, in the past several months the community has done great work to solve a whole host of issues to make Kubernetes “suck less.” In this talk I will outline the ways that the community has made this happen both in the core project and in the wider ecosystem.

Things are still developing, but here are the areas that I want to highlight. Hopefully we'll have talks on many of these so that I can highlight where and when folks can find out more. I won't be able to cover everything happening in the ecosystem but I can hint at the diversity and commitment to solving these issues.

* *Simpler application description.* As a community we are continuing to build more tcapable and simpler tools for describing applications through projects like ksonnet, OpenCompose, Kompose, and Helm.
* *Serverless platforms.* Through “function as a service” like systems we can abstract much of the nitty gritty around getting code packaged and running. In addition, scaling can be easy and automatic as code is run only when needed.
* *Simpler cluster install and admin.* kubeadm and how it is becoming a common toolkit. Similar work is ongoing to explore the idea of standardizing the description of a cluster at the infrastructure level through projects like Kubicorn. In addition, new APIs, such as the certificates API, are key building blocks for getting secure clusters up and running.
* *Curated development experiences.* Systems like Draft help to automate the build/launch/update cycle for development workflows. Others are also exploring ways to connect developers to clusters.
* *Making Kubernetes boring.* Kubernetes is maturing as a platform. As that happens, things in the "nucleus" are slowing down. In the past 6 months we've seen a concerted effort to encourage new features to be built with extensibility mechanisms as much as possible. This allows those projects to move fast while enabling exploration of the problem space.
* *Conformance.* Another key enabler for widespread Kubernetes adoption is conformance. There has been a wide set of folks involved in describing what should get to be called "Kubernetes". Tools like Sonobuoy point the direction to making this be an automated process that anyone can run against any cluster.
* *Observability.* Prometheus continues to be the go-to OSS solution for monitoring in the Kubernetes world. In additions, systems like linkerd and Istio/envoy enable introspection at the microservice mesh level.

We still have many challenges. Many of these are going to take long concerted efforts to fix. We are trapped, in some ways, by our promise of backward compatibility. It is often better to live with something annoying than to force breaking changes on our user base.

*Call to action:* Great job community! But the job isn't done. Let's keep working hard to bring Kubernetes to a larger and larger set of users and environments.

We are in the midst of a major shift at MailChimp. In many ways, we are a microcosm of the industry as a whole: moving from large monoliths to microservices and trying to figure out what that even means. I will discuss the hands-on, real world experiences we have had as we embrace microservice techniques and technologies. I’ll discuss why we choose Kubernetes, Prometheus, and other cloud native technologies. I’ll show our approach to building and operating multiple on premise, bare metal clusters. We’ll talk about our existing development and deployment pipeline as well as our current experimental projects. We’ve had a few false starts and failures and will discuss those to help others possibly avoid the same issues. Finally, I’ll speak candidly about the struggles we’ve had getting organizational momentum for this transformation.

Squash is a tool for debugging distributed applications.

Most cloud native applications written today follow the microservice architecture. These applications are distributed by nature, and therefore hard to debug.

Microservice engineers debug their applications by printing values of select variables into log files. This leaves them with the daunting task of sorting through reams of log data, which at best provide a partial view of the state of application. This approach is cumbersome, time consuming and works better with "easy" bugs.

Many advanced tools to debug monolitic applications exist in the market, and provide users with powerful ways to dissect their programs and to interact with them on the fly. However, these tools cannot be used directly for debugging applications that follow the microservice architecture pattern.

Squash is designed to bring the strength of modern debuggers and the convenience of their IDEs to microservices developers. Squash uses popular, powerful and mature debuggers (gdb, dlv, java debugging) and integrates them seamlessly with Kubernetes. This allows devs to use the debugger of their choice, and the IDEs that support it, to develop microservices on any platform.

The mission of the IHME is to apply rigorous measurement and analysis to help policy makers make better decisions on a range of health policy issues. Like other organizations, the IHME have embraced containers and micro-services aggressively to better support hundreds of collaborating researchers.

In addition to containerized workloads, the IHME run a wide-variety of traditional analytic, simulation and high-performance computing workloads on an HPC cluster with 15,000 cores and 13PB of storage. Researchers increasingly need to combine both containerized and non-containerized elements into workflow pipelines, and a key challenge has been ensuring SLAs for various departments and avoiding duplicate infrastructure and unnecessary data movement and duplication. In collaboration with industry partners, IHME have deployed a unique solution based on Univa’s Navops technology that allows them to combine containerized and traditional analytic and high-performance application workloads on a single shared Kubernetes cluster, ensuring departmental SLAs and helping contain infrastructure costs.

In this talk Dr. Grandison will discuss IHME, their experience deploying containerized applications and how they went about using Kubernetes to support a variety of new containerized applications as well as a variety of traditional analytic applications.

Kubernetes has historically released a full fledged distribution - everything you need. As the project gets more modular, that will become more complicated. This talk will explore the problems we face with this, and some ways can solve them, considering other analogous OSS ecosystems.

This talk will outline how UPMC Enterprises utilizes Kubernetes on-premises and in a public cloud (AWS). We’ll see how a large enterprise balances SaaS offerings vs Kubernetes hosted services. We will walk through our approach to meet HIPAA compliance and how our deployments and underlying infrastructure changed to meet those requirements.

We'll also look at the Elasticsearch Operator which is an example of how we implement stateful applications. The operator ensures encryption at rest, in transit and provides a managed cloud offering inside Kubernetes. Also, we’ll look at how we implement Kong, an API Gateway in combination with Kubernetes Network Policies to ensure applications are limited to what they can access as well as how security is implemented outside of code.

Healthcare systems have a history of being large and complex, but Kubernetes has allowed UPMC Enterprises to be more agile and bring startup innovations to the enterprise.

OpenFaaS (or Functions as a Service) is a Cloud Native framework for building serverless functions with containers (as popularised by AWS Lambda). With OpenFaaS you can package any process or container as a serverless function for either Linux or Windows - just bring your Kubernetes or Docker cluster. Avoid vendor lock-in by running functions in your own datacenter or the cloud with your existing CI/CD and container ecosystem. The project focuses on ease of use through its UI and CLI which can be used to test and monitor functions in tandem with Prometheus integration that enables auto-scaling as demand increases.

You can deploy OpenFaaS in 60 seconds on Kubernetes and thanks to concise code templates all you need to write is a handler in your favourite programming language then let your cluster do the heavy lifting.

OpenFaaS was recently trending as the top open-source project on GitHub, won Best Cloud Computing Software 2017 from InfoWorld and has a thriving community with 65 contributors, 1400 commits and over 8k stars.

Come and find out how and why people are leveraging an event-driven architecture along with some cool interactive demos and swag.

https://blog.alexellis.io/introducing-functions-as-a-service/

https://github.com/openfaas

Note - OpenFaaS is an independent project started by Alex Ellis and is now being shaped by a growing community of contributors and users.

This talk will focus on client-go, a go client for talking to Kubernetes clusters. At Kinvolk we have used client-go in various Kubernetes projects. Lili will share the general use-case of client-go and explain how powerful it is to customize, optimize, and automate tasks with it. Furthermore she will explore the parts that client-go is great at, as well as the parts that can still be improved. Lili will end with a demo showing how easy it is to harvest the power of client-go, and showcase how it can be used to customize your Kubernetes experience and solve real problems.

As a large enterprise organization with legacy infrastructure, we were interested in adopting Kubernetes in our internal Platform as a Service in the public cloud. However, we faced several challenges not addressed by the turn key offerings on the market, such as:

- Maintain control over network architecture within the public cloud to integrate with our internal resource
- Allow teams to easily spin up kubernetes clusters on their own for faster development cycles while retaining cost boundaries and charge-back insight
- Quickly iterate as new kubernetes versions are released and make new features available to end-users (most recently: Role Based Access Controls and StatefulSets)

We will share our experience of using configuration management to automate the testing, building and deployment of production ready cloud agnostic kubernetes clusters to the AWS and Google clouds. We will also discuss examples of moving some of our largest application workloads to these clusters.

So you've carefully crafted your first Kubernetes service, and you're ready to deploy it to production. Well, not quite: there are still some important unknowns to understand before your service will be ready for production traffic. It's still unclear how the new service behaves when it's being pushed, and it's possible that Kubernetes will kill the service before serving a single request. At Buffer, we've developed a technique to optimize Kubernetes deployment limits by using load testing to identify optimal values for resource limits. When the service is under heavy load there are a few key metrics to watch to identify bottlenecks. These key metrics can be used to adjust resource limits. This real world approach allowed us to safely and efficiently switch over more than half our production traffic to our Kubernetes cluster and can be applied to any application.

This talk will include a live demo of how to tune Etcd using methods we do at Buffer.

API management is an essential component for all production services. Northwestern Mutual uses it to secure 100s of microservices deployed to our Kubernetes clusters every day! Learning from our API management journey over the past few years, we found many ways to innovate in this space. Using Custom Resource Definitions as a catalyst, we created an open source project called Kanali, a Kubernetes native API management solution. In this talk, we will take you through our API management journey that led up to Kanali and then discuss how to use Kanali to secure your Kubernetes workloads. We will also look at how Kanali integrates with open source developer tooling such as Opentracing, Jaeger, and Grafana.

Data Science & Programming literacy is an important aspect of literacy in the 21st century, but teaching these skills at scale is quite difficult. At UC Berkeley, we are trying - our 'Foundations of Data Science' course has no pre-requisites, and routinely attracts more than a 1000 students from across majors. 

Requiring students to have local programming environments installed & debugged is a non-starter at this scale. We have been running a Kubernetes based JupyterHub environment that allows them to do all their programming with a web based environment with Jupyter Notebooks. This is an important change in many ways:

1. Lets students start instantly with writing code, rather than dealing with the accidental complexity of installing software locally

2. Acts as an equalizer - a student using a chromebook borrowed from the library has no disadvantage over someone using an expensive Macbook Pro

3. This is course critical infrastructure, and needs high availability at low human / dollar cost

In this talk we'll go over how we have:

1. Used Kubernetes to make reduce our costs while allowing a larger group of people to deploy safely to various cloud providers.

2. Extracted our JupyterHub deployment into a project part of Project Jupyter (Zero to JupyterHub) that is being adopted at other universities & organizations.

Serverless platforms provide functions as a service, and have become a hot topic largely because they allow developers to focus on core business logic, leaving packaging, deployment, monitoring, event propagation, scaling and load balancing to the infrastructure. The serverless billing model is simple - pay-per-invocation - which can being significant benefits for many event-driven applications.

Huawei launched its FunctionStage serverless platform, which is built on Kubernetes, in 2017. In this talk we will explain in detail the design and implementation of FunctionStage. This involved both fairly straightforward function packaging, scheduling, auto-scaling, event triggering and load balancing, as well as some significantly more interesting challenges related to container re-use, on-the-fly micro service provisioning, reliable operation and much more. We will demonstrate the use of our system to solve some complex real-world problems in Huawei Public Cloud.

Capacity planning is very important for meeting dynamic demands in any clusters. Without having an approximate view of the remaining capacity in a cluster, it is hard for cluster operators to decide if and when the cluster should be provisioned with more capacity or not. In Kubernetes clusters, capacity is associated with worker nodes in terms of resources such as cpu, memory or storage. Discussing capacity in terms of individual resources may be a bit ambiguous because a Pod is the smallest schedulable unit in Kubernetes clusters. Therefore, cluster operators may be more interested in knowing an approximate number of pods of a specific size (amount of resources) that can be scheduled on a cluster. This talk will introduce a new tool, called cluster capacity, that can be used to analyze the capacity of a Kubernetes cluster in this way. First, the talk will discuss about its use cases, followed by its design and implementation as a scheduling simulator. The talk will also include a demo to demonstrate various ways the tool can be run against a Kubernetes cluster. This talk will conclude with the discussion of future directions for this tool.

Maintenance events occur and require taking down nodes for various reasons. Eric and Maisem talk about the best practices and lessons learned trying to minimize downtime during routine maintenance events.

They show how to use StatefulSets and PodDisruptionBudgets to achieve highly available services. They go on to explain what the best practices for performing node maintenance are using scenarios like failed pod evictions, non-responsive kubelets and network bisections.

Currently Kubernetes does not support storage resource usage guarantee and isolation like compute resources such as CPU and memory. This talk will present out effort for improving Storage Resource Management in Kubernetes with focus on capacity isolation in ephemeral storage. It will explain how we support resource guarantee and isolation at node, pod, and container levels.

As Kubernetes continues to mature, it's increasingly hard for users to keep track of the latest resource types, much less the best way to employ them. ReplicationControllers and Services were easy enough. Then came Deployments and Ingresses. Now we have PodDisruptionBudgets, ClusterRoleBindings, and HorizontalPodAutoscalers. Luckily, we also have Helm to package and deploy these various components (and more) as a single unit.

In this talk we'll dissect the single, flexible Helm chart Ticketmaster developed for use by multiple product teams. We'll show how we use just a handful of variables to enable log collection with Fluentd, metric scraping with Prometheus, and automatic scaling of pods. Then we'll demonstrate the GitLab CI workflow through which we deploy multiple builds of an application to multiple Kubernetes clusters running both on-prem and in AWS.

After about eight years, Credit Karma had built up an impressive tech infrastructure...based on a PHP monolith. Over the past 18 months we’ve (carefully) adopted Docker, Linkerd, Consul, Kubernetes, and more as we shifted to microservices in order to enable continued engineering innovation. This is the story of our evolution from monolith to microservices, starting with our own homegrown tools. The talk will cover our iterations from basic plumbing to dynamic service discovery; why we started using Linkerd and selected Kubernetes; and how we evolved our systems step by step while continuing to serve 75 million members.

While Kubernetes continues to gain in popularity for cloud applications, many organizations run popular frameworks deployed on Mesos. The need to support multiple orchestration frameworks can result in added cost and complexity as organizations struggle to manage separate, siloed environments. Based on earlier work done for HPC users, Univa has contributed their Universal Resource Broker (URB) Technology to the Kubernetes community as an open-source project. The freely available software allows any Mesos compatible framework including (including Spark, Hadoop, Storm, Jenkins, Marathon and Chronos) to run along-side native Kubernetes services on a shared Kubernetes cluster providing the opportunity simplify environments and consolidate infrastructure.

In his talk Mr. Ferstl will discuss the challenge of running mixed workloads on Kubernetes, provide an architectural overview of the URB and provide a demonstration of the technology. He will also explain how Mesos users or application developers can get started quickly with the technology, and consider it for use in their own environments and applications.

The v1 release of role-based access control (RBAC) in Kubernetes 1.8 provides a flexible way to ensure users and applications have proper access to the Kubernetes API. This talk is for administrators who want to secure their clusters, and for anyone who wants their applications to integrate easily in RBAC-enabled environments. This talk will give an overview of the RBAC design and API, explain how to set up an RBAC-enabled cluster, demonstrate applying policies to existing applications, show how to create custom roles to distribute with applications, and answer the question "Can Bob educate dolphins?"