Cloud Native Computing Foundation KubeCon + CloudNativeCon Europe 2019 (Barcelona), 21 May 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Lightning Talk: Beyond Operators: Reimagine Distributed Applications on Kubernetes - Vladimir Vivien

Description

Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io

Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects

Lightning Talk: Beyond Operators: Reimagine Distributed Applications on Kubernetes - Vladimir Vivien, VMware

Kubernetes runs the distributed replicas of an application completely independent with no mechanism provided for coordination between replicas. To minimize race conditions, and other side effects of distributability, applications are often deployed with a replica count limited one or use primitives like StatefulSet to influence pod scheduling stickiness. Unfortunately, these are not enough to create truly distributed applications that can gracefully react to changes in their environment at runtime. While the controller and operator patterns have helped, they tend to use raw API primitives that are not related to building distributed systems. This presentation is a discussion that presents the features needed to create truly distributed applications that can react to changes in a distributed environment and including features such as leader election, synchronization, and coordination.

https://sched.co/MPgB

A

My name is Vladimir Vivian I'm, a software engineer from VMware upstream kubernetes contributor today. Actually, today, I want to talk about distributed application on kubernetes, specifically native distributed application on kubernetes. You've, probably seen this quote somewhere on the net from Kelly and others. That kubernetes is a platform for building platforms. What I'd like to add, is kubernetes is a platform for building distributed systems.

A

I mean if you want to build a distributed application kubernetes, as all of the may be all the ingredients that you need to do so from resource management, a solid scheduler, automatic process, distribution, scaling, built-in fault, tolerance, available stream, clusters of events, distributed data store for state, synchronization, etc, etc. The state of the art to build a distributed application on top of kubernetes today is controllers.

A

There are a control loop that synchronized cluster States from desired state to actual state the interact with the API server and it's approving abstraction that's been around with kubernetes, probably since kubernetes started. However, it's designed to extend kubernetes itself, it wasn't necessarily design to build on top of kubernetes. It exposes a large API surface and a lot of it has to do with structural concerns, and it requires the intimate knowledge of kubernetes working.

A

But a couple years ago, operators were introduced to kind of mitigate some of that they hide the complexities of raw controllers and there can't they can be used to build kubernetes applications. A lot of time operators are used as runtime application management automation, it's a powerful abstraction on top of kubernetes api. But to me they come with the same sharp edges.

A

You still have a large API surface to deal with, and it still requires you to know a lot about the end working of kubernetes and now the operator API as a software developer, who's interested in building a native distributed application on top of kubernetes. What I want is a small API surface that I can reason about complete abstraction of the inner working of kubernetes I. Don't care how the sausage is made right, no assumption about the the kubernetes api knowledge is made. It turns out that we've had a tool.

A

That's been doing that for a long time. It's Cube control, cube control exposes its own API to the human us and it hides all the complexities of interacting with kubernetes. You don't know, what's going on in the backend, you just type coop control run and something happens and you're happy. So I want the same thing, but in a programmatic form factor.

A

So an experiment I've been working on for the last but year and a half is a simpler API that exposes an event-driven interface, leverages existing kubernetes api objects and resources and introduces nothing. Nor does it take away anything and it has a split design of a coordinator which lunches, coordinates and monitor worker processes and those worker processes implement application logics for your distributed application. Now, if that sounds like something, you probably are familiar with, like an actor like approach, it is it's kind of inspired by that.

A

So let's take a look at a simple coordinator, that lunches a worker process and talk to the worker process and does something with it. They exchange data very simple for this five minute talk. First, we create the coordinator, give it a name namespace and a configuration, so it can talk to the that the API server. Next, we set up our callback function that will get triggered when a pot event happens.

A

In this instance, I'm interested when, when my pod, that I'm going to launch becomes ready and when it does get ready, I want to talk to my pod with a VA HTTP. Then we apply an upper a cluster operation. In this instance, I just want to launch something: I want to run a process and that's what we're doing we'll give it a name, an image, port, some kind of image, full policy, and that's it. Then we start our coordinator.

A

The worker side of things looks similar, and here is where we apply our business logic, for what we want to run. We create the worker, we specify another callback event, and in this case we want to know that when the workers ready, we create a server, a simple HTTP server, and then we start the worker. Then we deploy our application. In this case, the coordinator binary just like any other kubernetes binary, kubernetes application.

A

Now, once my coordinator runs, it lunches, my it lunches worker pods for me and then, as you can see in the bottom, they talk to each of the coordinator is receiving events from the from the API server and it's parsing it.

A

So this is something again. This is completely POC running on my laptop and it's hopefully it'll be open-source soon, I want to add more services and functionality. Primitives such as services, storage, scheduling, leader election, using the same, simplify API, again Thank You Vladimir Vivian at.