Cloud Native Computing Foundation KubeCon + CloudNativeCon North America 2016 (Seattle), 16 Nov 2016

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Keynote: Kubernetes by Kelsey Hightower, Staff Developer Advocate, Google

Description

Keynote: Kubernetes - Kelsey Hightower, Staff Developer Advocate, Google

After almost 2 years in production it helps to remind ourselves what Kubernetes is. At it's core Kubernetes is a set of small, well defined, components connected by an unified API. On the surface, Kubernetes is an application management platform, but if you dig a little deeper you'll discover that Kubernetes is a framework for building distributed systems. During this session attendees will go below the surface and gain an understanding of the Kubernetes core and learn how to leverage it to solve common infrastructure challenges in new and innovated ways.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.

A

We're going to talk about coronary kubernetes: this is the the title that I can get in on time for the CFP, so I have to stick with it. You know how that goes. Alright, so share my screen come on here we go. Oh.

A

Those a Linux user up here before and then projectors now confused all right. This latest con, isn't it alright I think we're good yep cool.

A

This is car prep work right here. All right, I think we're ready we're going to talk about kubernetes access.

A

This is not going to end up well, for these live demos, all right, good, all right so going to talk about kubernetes today and most people enter the kubernetes community. These days look at cover days and say it's overwhelming right, we're talking about all of these distros platform-as-a-service container as a service. There's, this new thing container adds a service, and most people do not understand kubernetes and its really intimidating. For someone to come in and attempt to understand it.

A

How many people here feel like that when it comes to kubernetes a lot of people here so when I think about kubernetes always think about the API server right, understanding, the kubernetes api server and the objects that you store in the kubernetes api server, in my opinion, are the key to actually understanding what kubernetes is all about. It represents a contract between you, the developer and the infrastructure, the objects that we model in kubernetes. They all have some form of a contract.

A

There's controllers that interact with those objects in kubernetes, but understanding them is the key to understanding what is possible and when we think about kubernetes, we think about running workloads, and this is where the couplet comes in and that attaches to the API server and attempts to run work, those that are defined or scheduled to it now for some people this could be the smallest kubernetes, sir, that you actually have all right, you're going to be missing some features, but with this you can actually create objects in an API server and manually assign them to notes.

A

This will totally work right, but that would be pretty tedious.

A

The next phase is to add this idea of a scheduler and a scheduler allows us to automate this idea of taking those objects from the API server, mainly pods, and assigning them to the nodes, and then we add, on other components like the controller manager, is responsible for all the control loops that implement or actually put into work the things that you defined in the API server, and then we have cout proxy. Now to me, this is debatable. Is this like or think in kubernetes that you actually need to understand?

A

There are parts of kubernetes I look at as training wheels, they're only there to ease your adoption of the platform, but there are a hundred percent required. So over the years a lot of people look at the stack and say I have to go through IP tables in order to have one container talk to another. This could be a turtle for some people, especially if you're sensitive about extra hops in your stack and then we introduce things like DNS right.

A

Dns is really convenient because you do not have to rewrite your application to adopt kubernetes service discovery, but again it's training wheels and then we have things like Etsy D, where we push a lot of the complexities of distributed systems into the store. And the next thing that we start to talk about in kubernetes is where's. The container runtime most people say: isn't it's the most important part and in my opinion the container runtime is a very small part of what you start to think about with kubernetes.

A

Once you start using it and then over time, at least for me, it starts to fade away. You don't think about the container runtime anymore docker versus rocket versus the neck. Supplementation that comes out. It just disappears right and it becomes part of the cluster. So when I go out to learn the kubernetes api, I think about forcing myself to remove some of the training wheels and what would happen so if you wanted to do the service discovery in kubernetes and we remove the training wheels.

A

Where does the contract that you need to stand in and do on your own? So I'm going to remove the dns server and coup proxy now start to think about how you would actually get two applications to talk to each other. If I took away DNS and the proxy server, is it possible right? A lot of people, don't think it's possible. They think they're stuck with this, so I'm, going to leave those things off and then talk about what I would do to accomplish this.

A

So I have this package called endpoints, and this allows me to talk directly to ku Bernays API, tell it a namespace in the service name and just get back a list of my piece. How many people know you can do that in kubernetes, it's totally possible. We have an endpoint that lets. You have a curated list of all the healthy paws running inside of your cluster. So if we were to run kubernetes and we look at this, coop CTL get pods, so we need a workload.

A

So by default we need something to run so qu CTR run nginx image nginx. We need a real version. Ok, so once we have this, we'll set up a few replicas. How about we start with nothing to see if this actually works so I'm going to do now is run my application that would like to talk to this engine next service, but I don't have any pods running but I'm going to bypass DNS, ku proxy, and just do it myself.

A

So this is the form of pi + 5 load, balancing so I'm going to create this particular workload in kubernetes and its goal is to come up and find the service and start doing its work on its own. So coop CTL get pods. It will look at the logs for this wow. That's a lot of things. Whoo, let's adjust that qu CTL apply got to do it live no videos. Videos is like lip syncing at a concert. If you see that happen, ask for hurry fun. Alright, so I'm going to hit apply here.

A

Whoo demo, gods, alright! So now we have this running so we'll look at the logs to see what's actually happening here now. This is my responsibility. Let's see what we have to do, it's going to look at the log for this particular container, and we see that it's complaining. There are no endpoints available so now watching the kubernetes api and everything that we do in KU proxy and the dns server you can actually implement by just using the api. So here we're going to actually run a workload to act fulfill this service.

A

So we have this internet service, but there are no end points, so coups eto run nginx.

A

Gosh image equals nginx 1.11. We need a port 80. What's that a typo, you guys are my friend you could let me type that out and be like how that's not going to work.

A

There we go all right, so that was deployed and what should happen is automatically. My application now removes the training wheels and it's able to fulfill the contract on its own. Now. This is important, because when people ask this kubernetes work with f5 load balancer in my data center, you can take off the training wheels and build your own glue code.

A

Now the code for this client side load balancers on github is 300 lines total and that's what's comments and documentation for the package, and this means that you can do whatever you want with kubernetes in any environment. So the things that we shipped by default they're just that their defaults, their suggestions, they're easy arm wraps for people, but you're, not logged in to kubernetes, and the next thing that we do is once we put these things back.

A

We put them there to ease the adoption of kubernetes, but don't turn your brain off and think that's all you can do with kubernetes and now we're starting to enter this other dimension of kubernetes, where we start to fill in the blanks with things like a package manager like helm, we're bringing things in like logging, so now you're. Assuming that you will have centralized logging for every container running in your cluster and then things like policy start to get really interesting.

A

And then we have things like metrics, storage and, more importantly, security and you start to see these clusters take shape. But if you look at Crewe Bernays the way I look at it, it looks like something different. It looks like a single computer. We no longer start to think of them as individual components that you have to configure and tune one by one and since most people don't think of kubernetes is the single deploy target. We think of these things where we're going to create a bunch of yamo file.

A

So many people are creating ammo files for the deployments don't be shamed. I will check your github accounts and find here Yambol files own up to it. So imagine we have this application and real applications call hello universe. Why is it not caught hello world? Because this is much bigger than the worlds this kubernetes thing so so go build, will build this application is a very simple application going to show you how it works so go build and then we'll run hello.

A

Universe on my machine, so I did show me hello world, there's a point to it. I promise alright, so HTTP. So what we want to do here, just listen on the local port, will do 8080 and very simple app I just want to show you that it's real, we'll pull it up here, you go I'm pretty sure. Infosec at Google is probably shaking in their boots that you see my corporate domain there.

A

So I will close it, but you see it's a real application now to get this thing deploy in production and you normally have to bake this into a docker container. At this point, I kind of see this as an implementation detail the fact that we have to put these container images, how many people wish you could just take your app and just say: hey, kubernetes, just run this thing right. Creating these container images seem like an unnecessary intermediate step that I'm just doing repeatedly just to have kubernetes run my workload.

A

It's there for a reason, but I think we can make it go away. So in a normal, kubernetes world. What we end up doing is we build a binary for for Linux in this case, so we build the actual binary, and then we have to make this. This docker container now I, don't know about you guys, but my docker files are pretty slim. How many people know what the scratch container is?

A

If you work in the enterprise you like dude, all we got is Java and from the internet right just pull the whole thing in as your base layer and if you do that, you're more likely going to get one of your dependencies and you'd be all good, so here I'm just going to copy that binary in there and then we're to push it up to docker right so that could build control our docker build alright, so we're going to build this thing.

A

We push it up and then we push it up to some registry and once we have this docker container, we create the replica set right. So now we have this replica set and we want to deploy our container and our cluster. You all know what to do here, coos, it's your crate and you think you're really also when you're showing people. This tool is like look at that the containers in the cluster, and then we have the service VIP, and you show them that it's running all right, I, don't know why we love doing this.

A

It's like yeah, no files, the oldest them won't, but we go here. We want to make sure it's running so great, it's running in my cluster. Everything looks legit and you show this to your developers is like all those steps to get a statically linked binary to run a production and the reason why we're still doing this is because everyone looks at kubernetes as this collection of components where we just go through these workflows. But if you would think about kubernetes as a single machine, we can start to think about it differently. Right.

A

Let's remove this really quick coup. Cto get our s.coups ETL delete our s, hello, universe,.

A

I'll delete the other stuff, so we can have some clarity here. So what I would like to do in the future? One day it should be possible to actually have my app be a little bit smarter and be self aware of the cluster.

A

Let's delete these as well.

A

All right so now that we have this hello world locally. Would it be nice if I can say hello universe and just give it flags, I was build, it again go build I, don't want to build a container and I don't want to deal with yamo files. All I want to do is take my application and have it run in the cluster, so one day in the future, I think is going to be possible that you'll be able to build your application.

A

What is this thing coming up or whatever just ignore it? Man so it'd be nice. If my application was cluster aware, it would be nice if one day in the future, so this is kind of a fictitious world that we're talking about here. Does that really make sense? But imagine if you could say, I would like to run in kubernetes, and you can say something like I want five copies of my or five threads or five processes running inside of kubernetes, and you go and give it things like a memory limit.

A

It'll be really nice that one day we can skip the yellow files, we can skip the containers and we can just hit enter here and then our app will like compile itself and copy itself into memory and put it in a location where the global computer could find that particular thing hand it off to the kernel in this case, kubernetes find that execution point and then hand control back to my application and if it did that, what is this demos enough supposed to crash?

A

But you know what you got to recover: we're going to recover and just tell the story again. You copy the application into memory, you hand controls to the kernel and the kernel goes and finds the execution binary that you need, and then it handles hands, control back to the application and be really nice.

A

If my application, because then fork off all the processes, it needs to handle its work, it'd be really nice if, in the future, I could go and get that IP address of my application, that's deployed and from my laptop see that this thing is actually sending traffic across all of my processes.

A

Come back here and see that my application is self aware and it's deployed into the kubernetes cluster and one day in the future, you'll be able to hit control-c and you'll, see all the processes automatically disappear and clean up out there itself and one day in the future.

A

We won't be writing a memo files and one day in the future, we'll actually understand the API, and we won't think in this procedural way of dealing with kubernetes will start to build applications that are self-aware, that deploy themselves clean up close your laptop control-z, open it back up and it resumes where it was one day in the future. You'll be able to use cooper night urban days as it's intended to be this globally aware application management platform without the manual steps. Thank you.