Cloud Native Computing Foundation KubeCon + CloudNativeCon Europe 2018 (Copenhagen), 10 May 2018

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Lightning Talk: Not One Size Fits All, How to Size Kubernetes Clusters - Jeff Sloyer, IBM

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)

Lightning Talk: Not One Size Fits All, How to Size Kubernetes Clusters - Jeff Sloyer, IBM (Any Skill Level)

Sizing Kubernetes clusters, at best, can be compared to throwing darts at a dartboard, in the dark. However our enterprise-tested rules and tips can shine a little light on the dartboard and help you have enough capacity for your apps. In this lightning talk, we will go over some tips to help you throw a bullseye for sizing your clusters. A unique demo will accompany this talk. Don't throw darts in the dark -- Kube at scale is possible.

About Dan
As a Distinguished Engineer within the IBM Cloud unit, Daniel is responsible for the technical strategy, and implementation of the containers and microservices platform available in IBM Cloud. Within this role, Daniel has deep knowledge of container technologies including Docker and Kubernetes and has extensive experience building and operating highly available cloud-native services. Daniel is also a core contributor to the Istio service mesh project.

About Jeff
Jeff is currently one of the dev leads for the IBM Kubernetes Service. Jeff is in charge of the core parts of the container service and lives and breathes Kubernetes everyday. In Jeff’s previous role he was a Developer Advocate for IBM. Jeff has spoken at many events in the past as he was a developer advocate for IBM, please see http://www.jeffsloyer.io/speaking/ for a list of events Jeff has spoken at.
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

How's it going, my name is Jeff's lawyer, one of the dev leads for the IBM kubernetes service. I'm gonna be talking about some kind of some best practices for scaling. Your kubernetes cluster and kind of haltech advantage with the resources in your cluster I have a two-year-old at home. That's probably just up on the screen. He is about the Builder fan. Anyone have kids they're about the familiar fans there. We go. Suddenly user Bob the Builder analogy today.

A

We're gonna have with a couple tools in our tool belt for kind of taking advantage of your coop cluster correctly. The kind the first thing to really delve in stat is understanding. What kind of nodes are in your cluster and what kind of apps you have running? Do you have a lot of go apps running? Do you have a lot of Java apps? Do you have some Ruby apps or node apps, so most node, apps and Java apps are usually very memory.

A

Intensive, go apps, you're, usually very, very smaller, so in our production cluster we use kubernetes to run our whole cloud service. We most of our nodes are very, very high on the cpu low on the memory most of its can go. That's why but we've a couple of nodes that run prometheus and they're very, very heavy on the memory so to really take advantage of those toolbelt. You need to know the size of your nodes start with so we're. The first thing we're gonna talk about is resore requests in limits.

A

If anyone can raise their hand and give me a good definition, what the difference is plus, if you can tell me what guarantee qsq OS classes are, I will give you a beer ticket. Anyone right here in the middle.

A

So, what's the difference between guaranteed a best-effort, though.

A

A

So I'll just repeat that correct to get my beer ticket that sucks for me, but hopefully I, know Chris so hopefully will give me another one. So, yes, correct so I'll repeat the answer. So what the Q s classes really are as a way to when the coop scheduler starts, shooting things it starts off at the bottom, at best effort, then burstable and then guaranteed. So as thing coop starts, shooting things once you define these memory, limits will go into them. If you haven't set a guarantee and Kubla shoot.

A

Alas, so something like nginx, you probably don't want to shoot. Your nginx reverse proxies start without probably really bad so up here in the screen. What these are requests and limits. So the big difference between these requests is when your application starts. So if Kubb doesn't have the resources available for this app, it's half a core and 100 Meg's of memory.

A

It won't schedule it, but, as some worker nodes start filling up for this app, three CPUs is kind of crazy for nginx, but if one coop starts filling up and that work notes becomes full start shooting things that are over those limits, the next thing in our tool belt is selectors.

A

So if you have some really sweet nodes in your cluster that have SSD drives, you have the money to pay for them great, but if you're running, like maybe nginx, for example, or actually not nginx Redis, for example, you need that disk speed and a good way to kind of do that is using the node selector. So you can have a label called disk type and you can specify the value for that and you will respect that scheduling for your worker nodes. Next on the list is anti affinity.

A

Well, probably gonna spend the rest of time on this. This is something that's really kind of hard to understand, but really cool. But basically what this says on the screen here is I'll kind of highlight: that's just my mouse: it's not their preferred during scheduling ignored during execution. What this means, as kubernetes will respect for in this case, that's apology, key it'll respect, basically putting only one version of my I guess: Redis instance on a node, so I'll basically prevent running multiple reticences on the same node for performance reasons, or it is reliability reasons.

A

So if you have a front door API, you probably don't want all those instances running on the same work or know that Delta's be bad and things will go down. It's not very and last on. The list is taints and toleration x'. This is a little newer as well. It kind of just became more baked two recent versions of kubernetes, but you can basically taint the node that it will only allow things to schedule there that have certain tags.

A

So in this example, you contain the node kubernetes tape, my no GP, no, whatever you want to call it a key value pair and basically you're saying, do not schedule anything there unless it has this key value pair on that pod, so you basically have it Toleration that looks like this on the screen here in the left. The key is GPU. You set it to true, and kubernetes will respect that Toleration. We use this in production Prometheus if they want runs production, Prometheus and production.

A

It's very very hard to do choose up a ton of memory. Artists, I think uses 64 gigs memory and production, it's crazy big. So we have a couple of nodes just set aside for Prometheus. This is how we make sure they don't schedule on. Some of them were critical nodes and start bouncing things all around in Cooper Denny's, and that's it five seconds less left. Thank you. So much.