Cloud Native Computing Foundation KubeCon + CloudNativeCon Europe 2018 (Copenhagen), 14 Nov 2015

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Introducing Amazon EKS - Brandon Chavis & Arun Gupta, AWS (Beginner Skill Level)

Description

Want to view more sessions and keep the conversations going? Join us for KubeCon + CloudNativeCon North America in Seattle, December 11 - 13, 2018 (http://bit.ly/KCCNCNA18) or in Shanghai, November 14-15 (http://bit.ly/kccncchina18).

Introducing Amazon EKS - Brandon Chavis & Arun Gupta, AWS (Beginner Skill Level)

Amazon Elastic Container Service for Kubernetes (Amazon EKS) is a new managed service for running Kubernetes on AWS. This session will provide an overview of Amazon EKS, why we built it, and how it works. Attendees will learn about how IAM roles can be used for authentication with the cluster using kubectl and assigned to pods at runtime. Cluster visibility using CloudWatch logs and Cloud Trail will be explained. Pod networking using the open source CNI plugin as well as the AWS CLI commands to manage the cluster will be explained and shown. Attendees will learn how about master nodes autoscaling and manual scaling of worker nodes. Finally, the session will explain how an application can be easily deployed to this service maintaining upstream Kubernetes experience. This session will provide different ways how attendees can engage with AWS using different open source channels.

About Brandon
Brandon Chavis is the Product Manager for Amazon Elastic Container Service for Kubernetes (EKS). He's been with AWS for over 5 years and has focused on the container ecosystem for the past 4. He's passionate about the cloud, containers, and excessively spicy ramen.

About Arun
Arun Gupta is a Principal Open Source Technologist at Amazon Web Services. He focuses on everything open source, containers and serverless at AWS. He is responsible for the CNCF strategy within AWS, and participates at CNCF Board and technical meetings actively. He has built and led developer communities for 12+ years at Sun, Oracle, Red Hat and Couchbase. Prior to that he led engineering teams at Sun and is a founding member of the Java EE team.

He has extensive speaking experience in more than 40 countries on myriad topics and is a JavaOne Rock Star for four years in a row. Gupta also founded the Devoxx4Kids chapter in the US and continues to promote technology education among children. An author of several books on technology, an avid runner, a globe trotter, a Java Champion, a JUG leader, NetBeans Dream Team member, and a Docker Captain, he is easily accessible at @arungupta.
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.

Join us for KubeCon + CloudNativeCon in San Diego November 18 - 21. Learn more at https://bit.ly/2XTN3ho. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.

A

Hi welcome everyone. We are extremely stoked for the attendance at this hour. I know everyone's probably wanted to grab the Rolly bags and get out of here. So we we debated the merits of just spending the 35 minutes that we have today for just QA, but instead we decided to go with kind of a middle ground and really narrow down the slides, give a minimal demo and then give a lot of time for discussion, because I'm sure there's plenty of questions based on what my colleagues at the booth have been saying.

A

So a quick introduction, I'm Brandon, Chavez I'm, the product manager for eks and.

B

I'm Erin Gupta I'm, a principal open source, technologist responsible for the open source containers and serverless strategy. So.

A

Yeah, let's go ahead and get started all.

B

Right cool: let's we're gonna get started. Brandon.

A

B

A twitter handle I, do have a Twitter handle, so it's alright, you know you can tweet me and I can pass the message to him.

A

I, don't know how to use computers well.

B

You're a product manager, so what is e KS e KS is a managed kubernetes service from Amazon. We introduce this at reinvent last year. What do we get as part of this managed service? If you look at kubernetes cluster, it consists of two pieces. One is a control plane, which is where your masters are running and then there's a data plane where your worker nodes are running. Worker nodes is where your containers are running so as part of eks, which is elastic container service for kubernetes. That's what the eks stands for.

B

We give you a managed control plane. As part of that, you know it's a fully highly available setup. What that means is we are running I know if you're picking a region say us us to where the limited preview is available. Today, then, when you are asking for a eks cluster, if you do have access to a limited preview, then we spin up a master in a highly available configuration. That means we're running it in multiple availability zones, so to be specific, 3 availability zones in a region.

B

In addition, your HDD is also running across three different availability zones. That's fully available, the HDD itself is encrypted, backed up and all regularly done for you, so that you don't have to worry about it, and we also provide you full upgrades in the sense that if there are kubernetes versions coming up newer versions coming up, we provide you an option of automatic upgrades or manual upgrades and then also in terms of if you look at how the master need to be created.

B

If you look at the documentation, it talks about the instance type that should be defined based upon the number of pods in your cluster, so the worker instance type needs to be scaled up and down just to be a little bit more optimal. So we take care of not just managing the cluster for you, but also upgrading the node instance type and the version upgrades as well.

B

This is an extremely humbling statistics for us. You know: CN CF runs a survey every few months and then they seek what is their primary choice of container platform and in addition, where are you running that container platform? So this is really a shout out to the community that is in a fantastic work up until Amazon announced eks. There are a variety of ways by which you can run kubernetes cluster and that all is existing in the community without really a lot of support from Amazon in that sense, but we are a very customer obsessed.

B

Company 90 to 95 percent of our roadmap is driven by customer demands, so our customers have been telling us run kubernetes for me, you know I mean we would love to. We manage our clusters, but there is a this is a undifferentiated heavy lifting for us and we would like you to run the cluster for us, so this number is just an indication that our customers were really asking us to run the cluster and that's the reason we announced the manage chromatic service.

B

Now we did build this service thinking through this you know very deeply and as we do with all of our services, so let's go through the core tenets of. Why we build this service and how are we looking at it? So the very first tenet itself is it's a platform for enterprises to run production grade workloads, some of our most innovative.

B

Some of our customers, who are extremely large and very innovative, have told us that we would like to run a huge enterprise workload on this cluster and that's sort of one of the biggest cannet over here that we want to give you the illa tees, that you are aware of coming from AWS, whether it's reliability, whether it is availability, whether it is scalability whether it is performance, we want to give you all the elytis when you are running a kubernetes cluster at an AWS scale.

B

The second core tenet is about providing a native and upstream kubernetes experience. One of the reasons among many why kubernetes is so popular? Is you can run it on your desktop? You can run it on premise. You can run it on your different cloud, no there's a variety of ways. You can run it and then in you feel yearning upstream kubernetes you are used. You are learning a particular scale. You are using cube, coral s, cube card or not cube CTL. If you're using cube coral, then you are applying your manifest to the cluster.

B

The quick and debate about cube cradle cube CT later at the AWS booth, but you know how your manifest is designed. You apply that manifest using cube coral. That is exactly the experience we are bringing to kubernetes. There is no forking. There is no internal branch of kubernetes being maintained. We want to bring your upstream experience straight up to a kubernetes cluster running as part of geek ass.

B

The third tenet now a lot of our customers. They would like to leverage the integration with different AWS services, not required, because if you are running kubernetes, you know in a variety of ways, then you may want to run it as is.

B

But if you need integration with AWS services, we will provide a seamless integration so think about services, like cloud watch, think about services like cloud trail, private link, VPC networking all of those integrations are going to be provided to you out of the box, which allows you as a customer to not worry about those integrations and that's just only a start. We would love to hear from our customers from each one of you so stop by the AWS booth or in or during the Q&A time. Shout out your request.

B

We would love to take that feedback. What is it that you would like us to work upon and what are the other integrations with different AWS services that you would like to see, because that is what is going to drive our roadmap and last, but not the least. This is the Kenneth that I am the most excited about working in the open source team. So Brandon is part of the service team. I am part of the open source team. Eks service team is going to actively contribute to the upstream experience.

B

As I said earlier, there is no internal branch or Fork of the kuben is upstream up here. So whatever patches fixes issues that gonna be applied or gonna be done in an upstream manner and we are actively hiring so this is my pitch. If you want to talk, if you want to work for Amazon in the kubernetes open source land come talk to us, we would love to talk to you and come work for us.

B

So let's talk about it a little bit as an eks customer. What do you really get? Well, we have you get an e KS cluster. How do you create an e KS cluster? There is a AWS CLI by which you can create a cluster. Of course, if your account is white listed, then you also get a console through the console. You can create a cluster as well, so you literally create create console, create cluster and it creates a cluster for you and in terms of cluster.

B

As we talked about, the control plane is all fully managed. Then, once the cluster is created, you bring your worker nodes and other worker nodes are provided as an army and we'll talk about that in a second. But then you apply a cloud formation template which then attaches your worker nodes or your data plane to the control plane, so that kind of makes your entire eks cluster. You can launch add-ons on the workers because the master is in our account.

B

The worker nodes are in your account, so we provide an opinion to duay of running a kubernetes master, but on the worker nodes you can launch any add-ons that are completely in your control, so you can do what makes sense for you.

B

The color is I. Think it's dimming the last day of coop con I guess the color is.

C

B

And so in the screen I am last.

C

B

Not the least the whole purpose of spinning of this cluster is to launch workloads, which is exactly the applications that you have been building. So eventually you can start launching workflow. So the process is very simple in that sense. Let's take a look at it. What do we do for you behind the scenes to make this happen, though? So you say, create a cluster behind the scenes. We create three. Now it's a highly available control plane, so we spin up three masters for you. We create a highly available HCD as well.

B

So and again it's an OP in it approach that we have taken the masters and the HCD are not co-located. That goes back to Amazon's philosophy of reducing the blast radius so that you know there are six nodes running over there. If a single node goes down is either the HDD or the API server controller, scheduler kind of gets impacted, not the whole thing. That's an important part of it. We also provide I am integration, because, if you're in the AWS LAN, then you love that identity and access management using I am so.

B

You can actually intenta Kate with the cluster using a happier Authenticator that we'll talk about a little bit later. We also do certificate management for you. The worker nodes are registered in an auto scaling group and so are the masters so that in case a node goes down. It can come back up again now that concept is a bit different from auto scaling, your cluster, which is again a very native upstream experience.

B

So if you have set up a cluster, then you can use all the native kubernetes concepts that are available to you and last but not the least. Of course, we set up a load balancer in front of your master, so that all from your perspective, what you get is an API server and you can talk to it directly now, setting up and managing a kubernetes cluster. It requires a bit of an effort over here.

B

Ok, so what we do is we give you a console, you create a cluster and we give you an API server URL, and then you can set up your highly available cluster, the data plane across multiple availability zones. You bring your workers in you, get an e KS control plane, and then you can use your standard cube.

B

Cut', also like if you're using 110, you can use a 110 cube card all to talk to the EES cluster and start deploying your applications and if you're running your workloads, the deployment be two replicas be two replicas set whatever it is. All those are now registering in your worker node.

B

Let's talk a little bit about the eks architecture, so how do I provision eks worker nodes? Now we provide you a pre-configured army as part of that. Essentially, you get a Amazon Linux, two based army and on that army we have the right darker version, the cube, cuttle version, the cube cubelet and all the components that you need figured for you now again, that's an opiate way of running army or for the worker note, but we understand the customers would like to run their own operating system. They would like to package additional components.

B

A lot of our customers have told we would like to bundle additional components over there. So the way we build those economies are using Packer scripts and those Packer scripts are gonna, be GA as part of the eks GA itself. So what that means is you can use the same Packer script, to create your own army using your own operating system and bring those armies as part of the cloud formation and then attach them to the master.

B

So it kind of gives you full control and configuration and ability to customize the army that is running on the worker nodes.

A

Awesome thanks Aaron, so I apologize for flux, kicking and my machines confused. It says it's 557 a.m. Seattle time. So now you won't have to stay up too late because your circadian rhythm is disrupted. I, know I'm, not gonna, do that but anyway.

A

So let's also talk about a couple of the open source projects that are that a company eks. So the first is the hep toi M Authenticator. This is an open source project that basically allows coop cuttle to also pass forward. I am identity. Information with every coop cuddle call. So we chose this approach because it is open source. This is something you could set up on your own cluster if you wanted to, but it's basically prepackaged with the eks cluster that you get when you create it just by default.

A

So what we wanted to do in this case is bundle. I am with eks, but not make you use. I am for all the authorization. So in this case, I am is just for authentication and we actually tie into the native kubernetes are back for authorization. So look: let's look a little bit at how we do that. So step, one of this process is with coop cuddle using the hep Toa WS Authenticator. It looks in the same credential chain where your AWS CLI does.

A

So, if you have your database config file, if you have environment variables, if you have like an IM role set up because you're using it from an instance, it basically looks for that identity, whether it's active profile or like in the config file and passes it forward to the kubernetes api server. On the back end, we have a web hook. Essentially that verifies AWS identity. Just says yes or no. This is a valid AWS user.

A

For this particular interview us account if you're approved, if you're a valid AWS user, the actual verification of what actions you can perform inside the cluster are validated against the rback system. So for as an example by default, the cluster creator gets system master privileges right. So you have cluster admin privileges, so you can of course, do everything we need to do get pods.

A

You can describe pods, you can control everything on the cluster, but if you have an additional user in your account that tries to run the same commands they'll be rejected because they are not in the our back system so again that kubernetes action isn't passed back to coop cuddle and we'll take a look at that in just a little bit. So an interesting component of this is that during the preview, one of the things that was a little bit maybe controversial, is we packaged our own coop cuddle.

A

We compiled it with the hep T Authenticator and it was a is basically just a superset of coop coop cuddle functionality and you could use it with all our kubernetes clusters. But in order to use eks, you had to use our custom coop cuddle because it contained that binary in it.

A

However, as of the release of 110 with the support of pluggable authentication providers, you can now just configure your coop cuddle to reference this external Authenticator binary and use the native upstream 110 coop cuddle, and that's how my clusters configured today in the demo, so we'll talk about that.

A

Another open source component of eks, which we are quite fond of, is our CNI plugin. When we were talking to customers early on about what should eks do for you, there were a lot of requests to solve some of the problems with some of the existing networking approaches in kubernetes Kubb net, for example, kind of limited your cluster size, some other options, or maybe difficult to debug or difficult to get visibility into so with our scene, I plug-in.

A

What we wanted to do is just bring native VPC networking to kubernetes pods, and so the CNI plug-in itself is a couple of different components: there's an eye Pam daemon inside of it, which is responsible for basically calling out to the VPC saying, give me IP, addresses and there's the actual CNI plug-in itself, which does all the wiring of the interfaces, and you know dropping those into the pod namespaces.

A

This is the the end goal here is to just give you native EPC IP addresses, so you get a flat routable network, your pods and your instances all share the same VPC IP IP space. This is open source on github. There are quite a few contributors and there's a lot of work going on on this right now. It's still alpha. You can test it out in cops today and it is provided by default on eks clusters, and this will be something that will consider GA when the service is also GA.

A

So, let's look at architectural e how this works. The CNI itself is deployed as a daemon set on every instance in your cluster, and so what happens is when a workload is then deployed or scheduled to your instances. The C&I plugin again makes that call to the VPC api's, so it makes an ec2 associated address, call and associated secondary IP addresses to your e'en eyes on your instances. So after that happens, the CNI plug-in itself actually wires in these secondary IPs. It creates the virtual Ethernet pairs.

A

It puts them into the network namespace for the individual pods and the end result is you just have routable VPC IP addresses that allow you to hit your pods directly. So there are some interesting caveats around this approach, which we always like to talk about. There's, of course, limitations on how many en eyes you can attach to instances right. So, if you're, using like a t2 micro, you can attach to en eyes and like 6, secondary IPS per and eye, but as you get up to larger instances, you might see where you have.

A

You know 15 en eyes and 30 or 40 secondary IPS Paree, and I so generally the pod density that you can achieve on a given instance type tends to scale pretty well with larger instance types. So it'd be great to take a look at that. Let us know what you think and test it out going back to some of arune's earlier messaging. We are very intent about keeping eks upstream and vanilla kubernetes right. I know when we announced this. There were some questions around.

A

What are our intentions with this and we think by becoming a certified distribution of kubernetes, you can see our conformance test results on the CN CF github page. We really hope this communicates our intention here. We intend to get certified for every version of kubernetes that we qualify on eks.

A

That was easier said than done early on, though, because there were some challenges to passing conformance tests for us, and we think this is kind of one of the interesting problems we've solved here.

A

So kubernetes has this assumption generally, that the masters and the workers run on the same network right and they have direct access to each other, and this is because there's a bi-directional data path right, so your workers reach out to the master to access the API and the Masters and vote connections into the worker nodes to support data flows like exact logs proxy.

A

All of these things treat the couplet as the server, so in a situation where you're running PKS- and you have your masters and workers in different VP C's, this presents a unique challenge because we could ask you to open up security groups, so we can reach into your instances. So we can invoke that connection to your cubelet, but that was kind of nasty feeling. So we decided not to do that.

A

So what this looks like to enable this cross account networking and to support exec and logs, is first of all for the API access from the workers to the masters. We give you a network load balancer in front of your eks masters. This is really nice because we have, amongst other things or static IPS on the network load balancer.

A

So this solves some of the problems where, if you've ever experienced, like a classic load, balancer that scaled up and the actual IP address behind your dns name changed and it messed with your certificates or something like that. That's no longer a problem, so API access, traverses the static IPS, but in situations where the masters need to reach out to the workers. What we actually do is we create elastic network interfaces in your V PC, but they're actually attached to our masters.

A

So if you look at the details of one of these Ian's eyes, you'll see that there's a different owner for the attachment and a different owner for the actual eni object itself. So this e and I essentially just gives us a route into your V PC, and this is TLS encrypted. So anytime, you invoke executive IRS's, this cross-county and I- and it is a encrypted data channel. So a little bit more about that.

A

We configure every kubernetes cluster every e KS cluster, with the with with its as its own CI, so we're using the built in kubernetes CI mechanism, and we generate public and private keys upon cluster creation when couplets check into the cluster. They issue a certificate signing request and we return a server cert that it installs and then nothing super fancy here. But we do have a certificate rotation on that.

A

So you can ensure that the cert that the couplet is running is up-to-date and secure so that about wraps up our slides, we're doing ok on time and I'm going to switch over to a demo real quick. What I wanted to do just run a describe cluster and so one of the food King. Do you Oh what nope.

A

A

I'm really nice background. I want to shoot this to show this.

A

How about that cool? So this is my describe cluster, it's important to know the eks api's themselves, they're, actually relatively minimal. We don't want you to have to interact with our api's more than you would have to interact with KU cuddle right. So you can keep your native kubernetes tooling, and the additional overhead from eks is really really minimal. We wanted to keep this a very thin ship, so the things that are important to look at here there's some metadata on this cluster.

A

We can see that there are two subnets assigned to it, and this means that there are subnets in my account where the U KS masters live. In the you know, the U KS teams accounts. This is where it creates Ian's eyes, and this is where it expects the worker nodes to actually be running, so these subnets are the ones that we have access to in order to invoke connections into your worker nodes, there's also a AR n for a role where this role gives us the ability to do things on your behalf, in your account.

A

So, for example, when kubernetes needs to create a load balancer, we use this role to assume those permissions and then take those actions. Other interesting things perhaps desired master version 1:9. We only specify to the minor version because we're automatically going to keep this on the latest patch version, that's applicable to our environment, to make sure that there's no outstanding CVS or security issues. There are there's a security group assigned, and this is a security group that controls ingress and egress from these control plane and is that we create and then finally the master endpoint.

A

This is perhaps the most critical detail right. This is how you reach that kubernetes cluster. You actually configure your coop cuttle to point to that. So if we do a coop cuddle version, something that is interesting to point out is that this is the upstream 110 coop coop cuddle client, and it's actually pointed at the hefty o. Aws Authenticator and I'll show you how that how that works? This is backwards compatible.

A

So the server version here the KS cluster- is running 1.9 and there's no problems with those working together as far as I know, and so let's see if we do a coop cuddle config view. The interesting part here is the username for my eks cluster references this these arguments here- references external, heavy, Authenticator, yes command. So every time a coop cuddle command is executed. This binary is executed as well almost every time what else was I gonna. Do. Let's see this.

A

So I have a cluster running.

A

Do I have Wi-Fi there we go so I've got a few nodes checked into my cluster here, we're running an actual eks produced ami. This is the ami Arun was talking about. This is re KS, optimized ami. We maintain this and we release this continuously as there are patches needed on the underlying OS or to the couplet or any of the basic alert docker Kubla any of the binaries that we packaged in that OS.

A

Let's see what's running on my cluster here.

A

So so far, I have a couple of Redis pods I have we've scoped running that I deployed via helm? We can do it some logs from this particular Redis container. We can also see that helm is working and helm works. The same way that coupe kettle does where it references that external binary, and we can see that we have a couple of things running via helm.

A

Let's see if we can deploy data dog via home.

A

Go have that running now. Goodly shrimp is an excellent name. Awesome, so helm is working there, so minimal demo, things work, this is kubernetes and if we go back to our slide, I mean go back to my awesome background.

A

We can talk about uses as a prompt for our Q&A, so we'll thing work on eks generally. The answer is yes, but if you have specific questions about these things, we'd love to answer them. For you in the few minutes that we have left.

B

If you have a question.

A

So you want to manage the certificate rotation for the kubernetes CA.

A

Yeah today only we manage that for you, so you know for you to provide certs, maybe via something like ACM, is a goal for us long term, but there's not a quick solution to that right now, yeah I agree. There is a some difficulty in that.

B

Yeah I think that's a brilliant question. The question is, you know if I'm running kubernetes cluster by myself on ec2 instance, let's say using cops versus I'm running eks cluster. What is it that I can I cannot do I, think that is the thing where I'm pretty stoked, because we are providing a hundred percent upstream experience where anything that you can do on a cluster created using cops or any upstream experience. You should be able to do it on the cluster creatively using eks.

B

However, in a cluster that you have created by yourself, you have full control of the master, so, for example, you can specify the API servers, which is you can anything that needs to be done specifically on the master. You can do that in our case, because the master or the control plane is running in our account, so you don't have access to the master. Those ec2 instances don't even show up in your account, so you cannot SSH or do anything over there.

B

I think that's sort of the biggest reference that I would say that you need to think about, and if you don't care about, you know how the master is managing all those things. Workers are in your accounts. If you run need to run a daemon set, then you can easily run it in your worker nodes right.

A

Something else to add to that, for example, is we don't have? We don't have API feature or half of features enabled on the masters, so, for example, if you want to take advantage of alpha features, you would need to still run your own cluster for the time being right, so slight differences. There.

A

Would you like us to who's a core maintainer here wants to talk about Windows support. We will be supporting Windows as soon as it's something that is a beta feature. For example, there's been several customers asking us about Windows, it's clear, it's important to the community, so I don't see why not.

A

The question is, how are we managing provisioning, I ops for ED CD nodes? We are using so everything that is in E KS is built on AWS today and so HDD instances are just ec2 instances running provisioned, dialects volumes behind them. I think the question is kind of you know what happens if you start to run out of AI ops, but we'll be monitoring for that, and the answer is yes.

A

Check out our virtual couplet pull requests as of a few days ago. This is we've written a far gate plugin for virtual couplets, so this is actually kind of an experimental approach without going into too much of a rabbit hole here you know the concept of removing the node from kubernetes is kind of complex, so we are hoping to start getting the community to think more about this virtual couplet approach, and we think it definitely has legs. There's some collaboration between us and some other folks in this space.

A

We'd love to see how this works out for you and, of course, there's some work to do to make sure Fargate can support the full scope of kubernetes api is which it doesn't today, but we think eventually we'll get there, and this is probably the right way to go for us right now. At least it's one option for us and.

B

Just to add to that far gate we announced at arraignment last year and essentially forget is a way by which you can run your tasks, which is the easiest language, our native orchestration technology or a kubernetes part, eventually that you'll be able to run in future without being able to worry about the cluster itself. So you say from your perspective: you just want to bring up parts back and say run it, which is a deployment or whatever it is.

B

So at reinvent we announced the GA of Fargate supporting ECS, which is our native orchestration technology, and then we also announced our intent for Fargate, plus eks. That's going to be coming up in the future.

B

Will I be able to specify which Flags the API server will use or cannot use, and that's the approach that we have taken? Wherein is opinionated approach and we are constantly talking to our customers and what works and what doesn't work for them. But at this point those flags are not exposed.

B

Let me actually come back to you. There was another hand with that. Yeah.

A

That is an incredibly aspirational question.

A

His question was: when are we gonna? Have this GA so soon and.

B

If you want to sign up for the limited preview, you can go to aws.amazon.com, slash ETS.

B

2018, the timeline for GI is 2018.

B

Now you can sign up, we are constantly onboarding customers, white listing them, so yeah.

D

B

I mean HCD managing EDD by itself is not for the faint of the hearts. So at this point what we are looking at purely is to have HCD behind the scenes not be even exposed over there. But that's a good customer feedback do talk to your account manager. Eventually, that's what helps us decide what our road map is going to look like and what are some things that we can do. Let me actually yeah.

A

Yeah whoa, would you use marriage at CV itself, or would you run your own queue, Brandy's masters I.

B

Want to go to the back of the room and see if there are any questions over there yeah. Well, there yeah.

B

Now the question is around cube: I am that's what they're, using so with happier Authenticator that Brandon talked about. We give you the ability to authenticate to your cluster cube. I am as much as the prominent it is. You know that's sort of one of the primary ways how customers have been using to provide a sign and I am role to a pod and the capabilities to the pod. Now there are issues with cube. I am there are other approaches like Kay I am, but we don't like some of those approaches. The long-term wrote.

B

The way we are thinking is something like spiffy inspire that was talked about. You know in the earlier keynotes that kind of provide a portable container identity. So that's sort of the approach we are looking at it. There is no strong recommendation from us and I think one of the cool root benefits is because this hundred-person upstream experience whatever is available in the upstream. You can leverage all the innovation as part of that for eks as well.

B

So the question is pricing pricing.

A

Will be available when the service is ga-oh.

A

So the question is: do I have to use I am for authentication right so for other IDPs. The solution would be to federate with I am because we're an AWS managed service. I am is the de facto standard for us question.

B

B

Is it going to be possible to use calico as a network supplier? That's actually a great question as part of the kubernetes uses CNI and we have our own AWS CNI plugin. That is fully open source. So that's the cni plugin that we're going to use. Although we are working with calico very closely and as part of you know, I mean if this was like a three-hour session. We could have gone into all the details of he cares, but calico would be available in eks cluster to give you at least the firewall capability.

B

But you don't have the capability to choose the networking plug-in by itself.

A

Right so the question is Ian eyes: impose a resource limitation on your nodes. So is auto-scaling, aware of that. In this case the scheduler we've written an admission controller to make sure that the scheduler is aware of how many on, based on an instance, type basis how many total IP addresses are available, and this is just another resource constraint. So the goal is to make sure that the scheduler, if it tries to place a pot on a node that doesn't have sufficient IP address capacity, will fail.

A

And then, if you have something like this ei, that's auto-scaling reactively should work based on that.

A

So the question is: how's our support for online resizing of PVCs with EBS. So that's an interesting question. We haven't done anything unique in that space is just the same volume provision. That's in the open source space. We have talked quite a bit about the container storage interface this week and I know, there's a bunch of efforts to pull the volume provisioner out of cork kubernetes. So this seems like a nice opportunity for us to contribute some to that and try to address some of the issues in the volume provisioner in the future. No.

B

Cs I use it not even an alpha feature at this point in upstream itself, so how it evolves over there we're definitely watching that space. Anything in the back yeah last person.

B

Yeah, so the question is, you know the users can use custom ami for the worker notes, as I said earlier. The way we are creating those ami is is, for example, using Packer scripts, so those Packer scripts are going to be open source as part of the GI.

B

So you can take exactly those Packer scripts so that you understand what components and how the army needs to be configured, so you can bring your own operating system, bring those armies and then essentially the way those worker nodes or those armies are connected to the master, is using CloudFormation template. So you will just alter the call formation template plug in your own armies and attach them to the control plane.

B

Like that's actually a great question, you know: will he provide ability to provision? You know other managed services three days back actually I'm glad. You asked that question three days back, we wrote a blog about open service broker. So take a look at that effort that was started by twelve honoree and that allows you to provision AWS services as first-class kubernetes resources.

B

Now, at this point, the blog talks about how you can use open service broker to provision sqs and other services, but that's running on a cop's cluster that you manage, but again that's an effort that we are closely watching. We are actually contributing back to it. So once eks goes GA. If that is the feature that matters to you, do let us know, and we will start integrating that as part of ETA I. Think.

A

There's quite a few services that are available in the open service broker. Api already there's s 3 RDS I mean SQL.

B

Was like six or eight of them right, yeah, yeah, yeah,.

A

The question was no dotto patching, so that's not something we will have by GA you'll still kind of have the you know. You bring your own node approach, but we will of course, release armies continuously, so it could be as simple if your apps are all stateless right, just updating the launch configuration for auto scaling group and rolling those out so there's also an SNS topic. You can subscribe to to be alerted when there's new Ami's available so.

B

Unfortunately, we can keep going. You know for as long as you want and I mean, there's there's a lot of interest. We would love to keep going. Thank you very much. If you would like to know more about eks and the roadmap, and what's coming up, we would request you to stop by the AWS booth. Get your badge scan, we'll put you on the list so that you can get the latest and the greatest updates about e-cash. Thank.

A

You so much everyone you.

B