CloudNativeCon + KubeCon 2016

UniK is an open-source tool written in Go for compiling applications into unikernels and deploying those unikernels across a variety of cloud providers, embedded devices (IoT), as well as a developer laptop or workstation. UniK utilizes a simple docker-like command-line interface, making developing on unikernels as easy as developing on containers. UniK ’s convenient REST API makes integrating UniK with orchestration tools a breeze. To demonstrate the value of cluster management of unikernels, we implemented a UniK runtime for Kubernetes, making Kubernetes the first cluster manager to support unikernels. This integration allows UniK to take advantage of core Kubernetes features like horizontal scaling, automated rollouts and rollbacks, storage orchestration, self-healing, service discovery, load balancing and batch execution.

On top of it all, UniK offers a highly pluggable and scalable architecture, allowing developers to add support for new processor architectures, programming languages, unikernel compilers, and cloud providers with ease.

What purpose does a web UI serve in Kubernetes? As the team responsible for building ‘Dashboard’ – the official UI for Kubernetes – that question is one we continually reexamine and assess our product against. We think a web UI has tremendous value to offer to Kubernetes users, and in this talk we’re excited to share why that is. We’ll make a case for the existence of Dashboard (including how it specifically serves different types of user), show & tell what we’ve been up to recently, and finally, share our plans for the future.

Managing thousands containers can be challenging, but if you want to know how Kubernetes will behave at scale we might be able to provide an answer. In this talk, we share the data we collected in our scale lab, which consists of 500 physical nodes. Using virtual machines, we can simulate up to 5000 Kubernetes minions running actual workloads, and our tests are designed to reveal how Kubernetes behaves while managing a complex application (in this case, OpenStack services) at large scale.

After the talk you will understand:
1. How Kubernetes performs rolling-updates, from a time and performance perspective
2. How fast one can roll-out containers on 500 nodes with specific constraints
3. How traffic flows between services, and what networking performance one should expect
4. How a single Service can facade 1000+ Pods with or without Autoscaler, and any limits involved
5. How many Services 1000-5000 Minions Kubernetes can support
6. How long it takes to deploy Pods for a single Service via Autoscaler to handle 1000 workloads
7. How long it takes to deploy Pods for a single Service via RC to handle 1000 workloads

How do we get traffic to our Kubernetes Pods? Reaching for a Service may be our first instinct, but we're walled in by the combination of service types and provider integrations Kubernetes provides. Service resources give little in the way of user control, leaving us to bolt on separate abstractions while hoping the functionality we need is available in the next Kubernetes release. These abstractions can easily become another routing layer that deeply couples to our other resources without any benefits from native integration at the cluster manager level.

Wouldn't it be better if we could integrate our applications and traffic in a natural, Kubernetes-native way? The built-in Ingress resource solves common access problems and empowers users to build software for handling custom traffic patterns.

The typical workflow for delivering an application on top of Kubernetes involves managing a bunch of manifest files in your Git repositories, and writing new manifests usually means copying lots of boilerplate. There are no standard ways to share and manage what’s running in your cluster. Enter Helm, a tool that streamlines the creation, deployment and management of Kubernetes-native applications. In this demo-led session, members of the CNCF Helm team show you how you can use Helm to improve your deployment workflows.

This presentation will cover:
- The history of Helm
- Deploying your first Chart
- Making your application Kubernetes-native with Helm
- Best practices for creating and configuring Kubernetes Charts
- Guidelines for contributing official Kubernetes Charts
- Setting up a Chart Repository to share your own Charts

Windows Server, and .NET, currently host 30-50% of enterprise workloads in the Global 2000. For Kubernetes to provide a single distributed application fabric to all enterprise workloads, it must have full integration with Windows Server 2016 and Windows Server containers. In KubeCon London 2016 Apprenda announced that it would lead this development effort and teamed up with Red Hat to extend Kubernetes to the Microsoft ecosystem. In this session we will demo Kubernetes on Windows Server 2016 and discuss its features.

It's a jungle out there! Modern apps are built around microservices, linked by a complex mesh of connections like sprawling vines. And just like in the jungle there are predators out there waiting to pounce on any weakness, steal your data, hijack your apps, and compromise your users. It may seem like a trade-off: do you simplify networking connectivity OR enforce security? In this session, Casey Davenport reviews the latest developments from the Kubernetes community to enable developers to describe, simply and intuitively, the connectivity requirements of their pods, consistent with established Kubernetes concepts such as labels and selectors. With live demos and examples drawn from user case studies, Casey will navigate the audience through this complex jungle and bring them safely out the other side.

SAP Labs uses Kubernetes to deploy and scale containerized applications in select private clouds.

Kubernetes promises an environment consistent enough to optimally deploy and fail over workloads.

We’ll demo and talk about how we move from the current state of Enterprise applications, virtualization in private datacenters, to a world where we run (and fail over) workloads between clouds using containers and Kubernetes.

In this session, I want to briefly present the current state of cluster federation in Kubernetes mainly focusing on what we aimed to accomplish, where we are today and where we want to go. After that I want to open the floor for discussion. The goal of the session is to discuss about the potential use-cases, challenges that people face while running cross-cluster workloads and the challenges that are hindering Kubernetes Cluster Federation adoption today. I would also like to listen to the feedback from our current users and hear about their experiences.

NCSOFT, established in 1997 and headquartered in South Korea, is a key leader in online games with its flagship product, Lineage. Today, NCSOFT’s reach has expanded worldwide including locations in Korea, China, Japan, the UK, and the US. The company operates many of the most successful MMO games that have been enjoyed by tens of millions of players around the world.

NCSOFT has been successfully operating multiple game services with thousands of physical and virtual servers for 20 years. But inefficient use of servers grew gradually as time went by, and there was also the need to respond quickly to temporary server increments for marketing purposes. Moreover, fast provisioning and deployment systems were required to prepare for mobile games.

For this reason, we have prepared for the introduction of Container technology from late last year. As our first target, we chose a number of stateless web servers and API servers that offer common functions. The Infrastructure configuration consists of OpenStack, Kubernetes and Docker; Kubernetes and Docker were built upon OpenStack. We changed the existing deployment system to be compatible with Docker/Kubernetes, and under careful consideration, we underwent tests and gradually applied the changes. And that brought us to a successful migration, with the results showing no problems at all.

The results show that existing VM amount decreased rapidly from 52 to 8, and unnecessary processes like creating VMs and installing software one by one on each VM were also removed. Furthermore, it enabled doing Rolling Updates dozens of times a day without any service interruption.

At the moment, we are preparing a new mobile game to be run on Kubernetes. Regarding continuous deployment on hybrid environments such as OpenStack, AWS and GCP, we are internally developing APIs for our hybrid environments.

Kubernetes has rapidly evolved from theoretical trials to empirical deployments in an increasing number of US enterprises. However, the Chinese enterprises unveil different traits when it comes to requirements, platforms, and the tech-savviness of the operators, rendering the upstream guidelines and references a far cry from enabling successful Kubernetes production usage in varying circumstances.

In this talk, we leverage our unique experience with using Kubernetes to manage production systems in large-scale Chinese enterprises, with a stab at stereotyping different categories of common usage scenarios not covered by the official guidelines. Peering through the mist, we aim to glean insights into the usage patterns in different industries (carrier, finance, e-commerce, and traditional, etc) to use Kubernetes more effectively.

We start with the standard Kubernetes features people are most thrilled about, then unearth the glitches and pitfalls when running Kubernetes in the wild, including dealing with Internet inaccessibility, unique security requirements, dancing with traditional, stateful applications, etc. Finally, we share our open source efforts and tools to tackle those issues in pursuit of wilder kubernetes adoption.

Kubernetes clusters dedicated to a single organization are becoming common, either run by the organizations that use them or hosted by others. Less common is a multi-tenant use of a single cluster.

There are problems to be solved in managing a multi-tenanted Kubernetes cluster in production. At Apigee, we are building a new Kubernetes-based platform that hosts applications for our clients and ourselves on a single, shared cluster.

This talk will cover:
- Securely routing traffic to the correct tenant
- Isolating tenant network environments
- Authenticating and authorizing management API calls using our own and our customers' identity providers and access control policies
- Creating a multi-tenanted build and deploy flow

Enterprise deployments are complicated. When managing proprietary technologies, sensitive client data and complex rules for access rights you inevitably arrive at a situation where your PROD environment diverges from your DEV and there is no certainty that your code will work in production. You wrote an update, your unit and integration tests pass, yet your cursor is still floating half-heartedly over the 'RELEASE' button. Sounds familiar?

Time to end deploy->watch-it-break->rollback->fix->rinse-and-repeat approach. Mikhail presents DTP-on-kubernetes - the next-generation microservices platform at Bloomberg, allowing you to run several versions of your microservice in parallel against the same requests, diff their output and trace messages through the system. On top of that, enjoy the deployment in seconds, brought down from hours.

Learn what impact DTP is having on Bloomberg and how Kubernetes helped to make this system robust and stable (and of course enterprise-ready).

Kubernetes has accelerated application development time for many organizations but one of the most tedious aspects of moving from application prototypes to running pods on Kubernetes is the repetitive task writing pod configuration files. A common workflow for many teams is to write development configurations in docker-compose before running a pod in Kubernetes. After using various container clustering systems, Micah recognized the need to be able to quickly interchange between formats. In late 2014 Micah open-sourced container-transform for interchanging docker-compose and Amazon's EC2 Container Service tasks, and has since added several other application formats including Marathon, Chronos, and more recently Kubernetes! In this talk Micah will demonstrate how developers can convert an app from docker-compose to Kubernetes, or even migrate from another clustering systems to Kubernetes. https://github.com/micahhausler/container-transform

(re-submitted to include the github link)

Micro service architectures result in up to 20 times larger environments than their monolithic counterparts. In such big and interconnected environments container metrics will tell you about infrastructure health but not service health. Even if you have implemented service health checks to quickly react on service failures, in a resilient system you will see intermediary mushroom cloud effects of a large number of services being affected temporarily. How do you find out what really caused the problem and how to distinguish effect vs. cause?

In this session we will do post-mortem analysis by walking through different cases of failures we've observed in a real-world large e-commerce production environment and show you how to figure out what actually caused the failures.

This is a combination of fun hack + potentially real-world use-case (sometime in the future). The idea is to use WebVR and a Kubernetes API client to render a Kubernetes cluster in a Virtual Reality environment. I will demonstrate interacting with different resources (inside of VR), including starting / terminating pods.

Outline:

- Show how easy it was to go from not knowing what a container is to production with Kubernetes
- Show some of the interesting ways we are autoscaling our microservices based on load
- Describe our migration process and how we were able to do it in the middle of our high traffic periods
- Describe some of the lessons learned going from AWS to GCE and running in production for almost a year
- Demo our CI/CD in Jenkins
- Describe how we geo distribute our data across the globe without a dependency on any one data store
- Show the management application we use on top of Kubernetes for self-service in the cluster

Abstract:

Many large enterprise companies are afraid of change and new technology, and we had a similar fear. Our business was growing globally, quickly, and we were buying companies! We were posed the question "How do we grow our infrastructure with our demand globally?" This question was hard to answer, and we were hesitant to spend a ton of money on licensing to scale our C#.NET and SQL Server architecture. We had to find another way! The answer was microservices, containers, and Linux infrastructure.

As we embarked on this journey into this new paradigm, we discovered Docker and all the complexities that come with Docker at scale. It was simple enough to get it up and running locally and getting smaller pet projects going. But we had more questions: what will this look like in production? How do we scale? How do we schedule? How do we keep these things up and running? How do we monitor? A host of other questions ensued. We evaluated many orchestration platforms, including Mesosphere, Deis, Fleet, Panamax, Compose/Swarm, and finally Kubernetes. We found all of these platforms had strengths and weaknesses but the outliers became Mesosphere and Kubernetes. The tie-breaker for us was the awesome community around Kubernetes and what it was based upon, as well as the rapid development and momentum of the product. This gave us confidence that our platform would co-evolve with our infrastructure, keeping pace with us!

We have been using Kubernetes since version 1.0.6 and have never looked back. We built a full SDLC workflow via Kubernetes that includes CI/CD and automatic JIRA assignments for development and QA, auto-scaling capabilities beyond Kubernetes HPAs, logging integrations, and a cadre of applications specific to our business. We want to show other companies that it's ok to embrace emerging technologies like Kubernetes. Since adopting Kubernetes, our operations have become so much more efficient, because now the people that build the software are the same ones building the infrastructure. We are running at a scale of 5 million active golfers across 10 products. We embraced the changes and came out with a world-class product. We want not only to speak to what we have done, but to inspire the conference to take the plunge and build something revolutionary.