Cloud Native Computing Foundation KubeCon + CloudNativeCon North America 2017 (Austin), 15 Dec 2017

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Keynote: Cloud Native at AWS - Adrian Cockcroft, Amazon Web Services

Description

Keynote: Cloud Native at AWS - Adrian Cockcroft, Vice President Cloud Architecture Strategy, Amazon Web Services

About Adrian Cockcroft
Adrian Cockcroft has had a long career working at the leading edge of technology, and is fascinated by what happens next. In his role at AWS, Cockcroft is focused on the needs of cloud native and “all-in” customers, and leads the AWS open source community development program.

Prior to AWS, Cockcroft started out as a developer in the UK, joined Sun Microsystems and then moved to the United States in 1993, ending up as a Distinguished Engineer. Cockcroft left Sun in 2004, was a founding member of eBay research labs, and started at Netflix in 2007. He initially directed a team working on personalization algorithms and then became cloud architect, helping teams scale and migrate to AWS. As Netflix shared its architecture publicly, Cockcroft became a regular speaker at conferences and executive summits, and he created and led the Netflix open source program. In 2014, he joined VC firm Battery Ventures, promoting new ideas around DevOps, microservices, cloud and containers, and moved into his current role at AWS in October 2016.

Cockcroft holds a degree in Applied Physics from The City University, London and is a published author of four books, notably Sun Performance and Tuning (Prentice Hall, 1998).
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

So originally a certain talk about cloud native at AWS and I got a few new things. We announced last week that we actually want to talk about so a little bit about the cloud native principles and I'm going to talk about open source, add AWS and then dive into a few of the things we've been doing on CNI. What is this new Fargate thing that we used for container provisioning? What we're doing to help kubernetes run on AWS and then just end up with eks Cube natives as a service?

A

Ok, so cloud native principles, I've got a whole long presentation on this, and if you wanted the hour-long version of it, there's a video up from from reinvent last week, you can go google for arc 209 if you're trying to find that. But these are the principles that I think are important, that make something cloud native that it's pay-as-you-go and you're, paying after the event, you're not having to invest in a data center and guess how much capacity you're going to need next year. It's self-service! It's no waiting.

A

Everything is the API deployed and provisioned globally distributed by default. The cloud is out there: you can go use things around the world, you don't have to be constrained to just wait happen to a built, a data center, the availability models take into account zones and regions, and then the other really important thing is to get very high utilization.

A

You can save a lot of money by turning things off extremely aggressively and then immutable code deployments and I think some of the things that we came up with back in the days with Netflix, we were using Amazon machine images as containers and we were baking those containers and then we weren't changing that we were replacing them, and that is some of that. That's kind of the deployment model that docker picked up on when they containerized it. So you know it's it's.

A

There is a Linux container, but the idea of a container is basically an immutable deployment entity that you bake as the as you go through. So all of these things tie in but I am built time to go through all this, so I'm going to talk a bit about what or else we're doing here there we go so the open source team AWS has really got these three things: we're working on we're trying to grow communities, we're doing things like joining CN CF.

A

That's part of that we're improving the coat and we're increasing the contributions that AWS and Amazon make into open source projects, as well as interrupting from the community. So AWS is doing with CNC F, and you can look this up in the blog post, I wrote when we joined blast last August we jointly we're promoting cloud native to enterprise customers. That's the goal of the whole of the CNC F.

A

What we're doing specifically those were integrating CN CF components into AWS products, including ACS things and I'll, talk more about that in a minute we're integrating kubernetes with AWS working on a few things there and we're working with the CN CF serverless working group, one of the other things we've done. We've also provided some credits to the CNC after support kubernetes scalability testing and we're in the process of getting that up to speed.

A

Okay, so here's some code contributions, we're a founding member of container D, the docker runtime we're working on moving towards getting that now it's wondered, oh I, think that's a great move. The goal is that we end up using this as our containers, our container runtime across all of the cloud services at AWS, we're doing some work on kubernetes, installers security, networking and overall integration with AWS we've put quite a bit into CNA.

A

We've extended it and integrated it with the AWS networking ena, the the native networking interface on AWS and we're up streamed that already into into CNI for supporting ETS and into eks. So I'm gonna explain a little bit about how this works. The key thing here is on AWS. We have a native network adapter that is incredibly highly tuned. It has Hardware supports. We have 25 gigabit networks and it's pretty hard to drive a 25 gigabit network flat out. So we have all kinds of support to make that work, and then we have V pcs.

A

We have security. All of these things are baked into ene. What we've done is we've beat that we've made it so that CNI at seeing a plugin that combines that in and that means that your containers get native networking, with full capacity, support and efficiency and all of the features that you'd get in an instance level. You now get a container level that makes it easy to do. We've open sourced it we've up streamed all of this support into github.

A

So if you're building any you can build any container scheduler that you happen to be building you just use CNA you get all that support automatically. So what this looks like within a VPC CNI is they're allocating on the behalf of the containers. So there's the network interface, which your instance has already got, because you fired up an instance and CNI basically takes these pods and allocates can by talking to the VP, see says give me some extra addresses on this network interface and I want those addresses to have secondary Eyed Peas.

A

Within that VPC those are then allocated directly to the pods. So what you have now is completely native networking at the pod level, going all the way out within the VPC construct and we've worked, then we've subsequently worked with Pinterest weave and Tiger ax to help get this into a kubernetes to upstream this commedy. So we've got the changes in there. We haven't finished, making all these changes and upstream them yet we're in the process of working that through, but this is already in production at AWS in in ECS.

A

So if we look at ECS, this is the native container service at AWS. It's a very large scale and we're currently managing over a hundred thousand clusters, not containers over a hundred thousand clusters with ECS, and some of those clusters are tens of thousands of containers and it's a multi-tenant service. So it's a different beast than kubernetes and it serves a different need for us, but we've already got CNI baked into that. So all of that cluster, so the C&I that we've up streamed is already in production, really high volume.

A

But I wanted to talk about a new feature that we announced last week called far gate. This is also now integrated into ECS and we're looking at. How do we bring this to other container schedulers? So what is far game far gate is a really results in us. Looking at all of the different things we want to do in the cloud, if you start off by saying: okay I have these instances there's these machine instances which are virtual machines, and we natively know how to manage those on AWS and then we came out with lambda.

A

So now we have functions which akane are natively managed by AWS, but containers were a thing that ran inside an instance. What Fargate does is it says? A container is a native thing which AWS now knows how to manage. You can say give me a container here's. The code go run it for me and thought there is actually a fourth one. We also announced last week, which is bare metal, so we have bare metal instances on AWS. Now we have a couple of instance types, but you can bring your own hypervisor or you.

A

If you wanted to, you could deploy everything on bare metal on on AWS. If you now have four different first-class deployment entities bare metal, virtual machines, containers and functions, and you can deploy to any of those and they all support different aspects of what you might want to do. But the key thing here is: we want to be easy to use to deploy containers.

A

So here's a typical, actually ECS deployment. We have a bunch of containers, they were running on instances. Those instances run an agent, they run docker and they're built into an AMI. We have a scheduling, an orchestration cluster manager, placement engine and what Fargate does is it just takes away all of the AMI it takes away. They need to run a daemon. It takes away, they need to figure out what we're doing you just say: I have my scheduling, orchestration, here's my containers, let's move on.

A

Interesting thing here within ECS: it's the same task definition schema, use the same API to launch them and we mix them. So this isn't an all or one you don't say, I'm having everything running on instances or I'm bring everything run just as far Gate. You blend the two. You can have some of your containers scheduled on one. Some contain some containers scheduled on another and as we look forward into emerging this into kubernetes, we want to sort of keep all of these flexibility in there. So you should see it as an option.

A

You might want to pack in a whole bunch of containers, into instances that you are managing for a very specific purpose, but you may just say: I just have some containers and I I don't actually want to deal with managing a set of instances underneath that you want to blend the two together. So talk about kubernetes.

A

One of the reasons we joined AWS was we were hearing from my customers that we're was a lot going on here and from a CNC F survey, 63% of kubernetes running on AWS, and you know we listen to our customers and we figured out okay, they need they need some things. One of the things they wanted was to keep kubernetes as a completely open source experience. What that means for us is we're not forking kubernetes everything we do is upstream. If we can't persuade the community to do it, we'll back out and try.

A

A different thing was a couple of cases already where we provoked but proposed stuff, or we said no, that's not quite right and we've backed out and done other things around. So I think this is something where you want to be able to run exactly the same bit and on every cloud runner in your data center. Wherever you want it to be, it doesn't make it doesn't help if we have custom version on AWS, so we really want this to be a pure experience.

A

The other thing, though, is remote native AWS integrations where you want to connect into an AWS feature. We want to make that easier. We want to do the heavy lifting for you and we want to make it efficient and easy to do so. Here's a couple of these I am authentication right. We have identity access management and we need to be able to authenticate into AWS, so we've been working with heftier on that I am FN to cater. This gives us an approach in an open source project.

A

We've been just working together on this and we've been productizing this, so here's coop control, there's the API it passes in an identity that goes to the authentication that or dent or vented authentication is then blend is then looked up in are back within a kubernetes and then that basically controls what you can can't do in terms of your cluster right. So that way we can set up an AWS identity, a role which manages that back in just thought, it looks like.

A

Oh sorry, there's another thing: we, the other thing is the iam roles in pod. So, within a pod you want to have that pod have a role on AWS, because that's how we give instances permissions to manage certain services. If you want to talk to s3 or you want to deploy something, you have to have a permission. You have to be in the right role.

A

Those roles are stored out in I am, and we have to transfer those roles back in so that uses cube to I am which is again a community project and the runs are all daemon set. There's a security token service and you can get traditions, you can look it up in the metadata service and basically, what you have to do is put an entry in your in your raw annotation in there. So that's that's we're working on this as we're trying. You know.

A

These are projects that were out there and we want to work with these the contributors to make these really production ready and integrate them in, but there's a few other ways that people want to use roles in pods again we're working on this too.

A

So getting Hasek vault integrated, that's another great way of storing tokens and passwords, and also the spiffy, which is a proposed project which is being considered by CN CF, and we we kind of think this is a good way forward for how we're going to manage all of these things, so we're gathering together working with the communities and we're pulling in what we need to make all of this work in a production way, but also work it on integrate properly with the AWS features and security mount models.

A

But then you know we had this one last request say: Kay, please run kubernetes for me, make it easier to run kubernetes, and so we have with last week we announced amazon eks container service and we have a few tenants. What were we trying to do here? The first thing was: this: is a platform for enterprises to run production grade, work loads, that our focus here is mostly on large-scale production deployments of kubernetes. We have a fairly, we have a number of customers doing.

A

You know that are running their entire businesses on this already second tenant. We wanted a native, an upstream kubarz experience, as I mentioned, want to always contribute everything that we're doing to build this as a service, we're still contributing everything back up to into kubernetes itself.

A

Third, one we want all of the integrations to be seamless and in it, but still eliminate extra work and the fourth one we're actively contributing to the EAS project, kubernetes project from eks and we're as we build out our team, we're making more contributions so we're, hopefully you know, I'll put in where the standard plugs here is we're, obviously we're trying to find more people to work on this with us.

A

But if you work with us, you're not going to be sitting off in a back room working on a private version of things, we're looking at building teams that contribute actively to the project. Thank you.

A

So if we look at what kubernetes looks like today, you have masters, you have a set up addy and you have all of your instances. The default way we expect this to run is across three zones, so you get high availability with replicated master and etcetera T. So what happens when you run eks is that control plane disappears and it's replaced by an end point, but queue control still works, so it basically the end point you would normally use to talk to your control.

A

Plane still behaves in exactly the same way it just its invisibly being running on your behalf and then then you start up two containers in a in a zone. They all connect into that central control, plane.

A

Okay, so that's just one final thing: before we can get to the break here, which is far gate, far gate just came out, we're still figuring out exactly what API is we need to expose and what the integration looks like, but we're and we're concentrating right now on getting eks just out right, so we're not going to block eks on rolling, far gate n, so we're just going to get the thing that we're currently working on, but in parallel, we'll be looking at.

A

How do we fall far gate into this and in a subsequent release of eks you'll, be able to blend together instances that you're managing to run containers plus Fargate? So that's it thanks for all your contributions, looking forward to working with everybody and thanks very much.