Ep.117 What Is Kubernetes?

By Published On: March 31, 2021Categories: Blog, Podcasts, The CTO Studio

Are you a technology professional looking to connect with like minded people?

We have a thriving community of CTOs discussing these episodes and more.

Click HERE to set up a call and learn more about becoming a member.

About The Speaker:

Jonathan LaCour, CTO of Mission. Mission is an AWS partner providing DevOps services and my go to friends for infrastructure questions.

Episode Resources:

Check out https://7ctos.com/

Episode Transcription:

Nickolai Walker: [00:00:11] Hello, hello, thank you for joining us here in the studio, I am your host, Nikolai Walker, on the mic and in your ear. We are joined in studio by Jonathan LaCour and I’m going to throw this question over to Etienne and he’s going to say it a lot better than I possibly can. But I, like a great many people, have a question for you, which is what exactly the hell is Kubernetes? If you could help us clear that up, we’d greatly appreciate it. Etienne take it over.


Etienne de Bruin: [00:00:40] I’m a late bloomer when it comes to containerization and finally understanding what it does. You know, sometimes when you learn a new programming language and you’re like, I can do all the hello world examples and I get it, but I need to do something with it. Like when am I going to actually code something with this. And with containerization and Docker, it’s like, OK, I get it, I’ve run a little hello world instance and all that. But now, how am I deploying this? And I found one of the one of the very useful ways of doing it is through lambdas and sort of thinking about life that way. And so I’m a late bloomer to containerization and serverless. I still feel afraid to admit to people that I don’t really, really understand what Kubernetes is. And so I feel a little vulnerable in admitting that to you.


Jonathan LaCour: [00:01:45] But it is OK. I would say a significant percentage of the people who run Kubernetes don’t fully understand what Kubernetes is. But let me break it down for you in pretty simple terms. And I think it might be interesting to start with containers as a concept. So container’s have been around before Docker. But I think Docker is the thing that really caused containers to take off. And why is that the case? In your view, what was the thing that got people excited about Docker?


Etienne de Bruin: [00:02:20] Yeah, I don’t think people knew why they got excited about Docker. I think for me my initial thought was, wow, we don’t have to worry about dev environments anymore. There’s no worrying about different environments.


Jonathan LaCour: [00:02:37] You’re onto it. Right. So the the key innovation of Docker was finding a way to transform the typical engagement between developers and infrastructure and deployment and making it super simple and really designed to delight them. The thing that made Docker successful was it spoke to developers and their workflow. It works on my machine as a package and ship it to production. That’s what got people excited. So that’s containers in a nutshell to me. I can package something up in a way that I know it works and I can ship it around and I’ve got that mobility. Kubernetes is the logical endpoint of that where now I’m going to go through and I want to start breaking my application down into microcircuits. I’m going to break it out to smaller and smaller components then I can containerize those components. And then when you have a large scale system with many of these different micro services that all have to be orchestrated and communicate together, that turns out to be a very large challenge and a very big problem. So we solved one problem. We created a dozen new ones. And Kubernetes is designed to solve all of those problems. But the key thing about that is, like, how many people really have a scale at which they require something like Kubernetes, so Kubernetes brands themselves as a platform for deploying, managing, scaling containerized applications at scale, at massive scale. So it was born at Google. These are people who are not running little rinky dink workloads. And by the way, there’s nothing wrong with a rinky dink workload.


Jonathan LaCour: [00:04:23] It’s the same challenge that I hear from people who who, you know, I took over the engineering team at a business a couple of years back where their entire platform was written in Perl, which is not the most modern language or popular language. But it was funny because I had some engineers on the team that were making fun of an application that was written in PHP and they’re like, oh, ha ha. Nobody uses PHP. And I was like, folks, you do realize we use Perl, right?  Number one. Number two, you do realize that like 80 percent of the Internet is held together with chicken wire and duct tape with, you know, crazy Perl and terrible PHP and JavaScript and that’s how the Internet works. OK? It would be shocking when most people learn about how networking works at scale and things like BGP. You should be terrified all the time about everything, but where am I going with this? The point is, most of the time Kubernetes is a logical conclusion to solve a bunch of problems that we created for ourselves by taking advantage of containers and then going wild with that. And there are certainly applications where you’ve got a large amount of discovery and interconnectedness and a bunch of different micro services that when you glue them all together, create a work load. Kubernetes is ideal for that, but most workloads aren’t that. And it’s OK to be simpler. That’s fine.


Etienne de Bruin: [00:05:48] So, for instance, if I just look at the single thread, you package up your container and you publish it to EKS, is that right?


Jonathan LaCour: [00:06:10] EKS is the elastic Kubernetes service. Thats AWS’ like we’re running Kubernetes for you at scale and you just push to it.


Etienne de Bruin: [00:06:17] So would Kubernetes then just be, instead of thinking of your app as a single docker instance, it is actually just a ton of them doing different things like in a micro services environment.


Jonathan LaCour: [00:06:31] Yeah. The long and short of it is, and I’ll caveat all this by saying I’m also not a Kubernetes expert. I know enough to be dangerous here and definitely encountered it a lot. But effectively, think about it this way. You’re defining independent services, right? And you’re grouping them together and you’re allowing the services to do things like discover each other. So you basically can create these pods and you create IP addresses for them and you can create DNS names for a series of these things and you could load balance them. It’s doing things like healing and scaling and the topology of your services and really providing you with all of that substrate. But frankly, it’s pretty boring when you really think about what it’s doing under the hood, its orchestration. It isn’t doing anything that is actually solving any problems for your end users. It’s purely designed to solve problems for you. I want to smoothly scale, deploy, heel, roll out a very large scale service that has many, many, many micro services that make it up.


Etienne de Bruin: [00:07:35] So is Kubernetes something that can also then be defined by something like a terraformed script?


Jonathan LaCour: [00:07:43] Oh, yeah. You can definitely use infrastructure as code to provision things and terraform, for example, actually is an infrastructure code provided that has a whole bunch of different capabilities to extend and plug in and add new capabilities. And so people have done a lot with Kubernetes.


Etienne de Bruin: [00:08:16] So that’s that’s helpful, thank you, I appreciate that. I feel this incompetence.


Jonathan LaCour: [00:08:25] Well, first of all, you’re not incompetent. The fact is that frankly, most people don’t need to know how Kubernetes works. The vast majority of people do not need to know, including CTOs. I think it’s a good idea to understand it because it very well could be a good fit for a workload that you encounter. But, you know, you are not in the minority when it comes to that level.


Etienne de Bruin: [00:08:52] So even if I am a small company, is it potentially best practice to start off with Kubernetes as a infrastructure or as a way to think about your deployment so that you are prepared and you’re just sort of growing, you’re not having to shift. Like what is the paradigm, the devops paradigm that is just plain good old best practice to kick anything off, that might feel like overkill in the beginning, but actually will serve you pretty quickly as you grow?


Jonathan LaCour: [00:09:28] Yeah, I think I do not think that it’s necessary to start with Kubernetes as a given at the beginning of a project. It might be the right choice, but in many times it’s not. I would say honestly, a lot of the same old way that we approach problems as technologists when it comes to application architecture are very, very similar now as they were before. It’s just that some of the atomic building blocks are a little bit different and that parts of them can be outsourced as well. So, you know, like we talk about the database layer, you used to have to think a lot more about the database layer than I think you do now, because you can do things like, I’m going to go ahead and I’m just going to plunk in RDS here or maybe I’m going to use Dinamo or whatever. Maybe not the best example, but, I think starting from a position of yes, I’m going to containerize, that’s totally appropriate. And if you’re starting from there, getting to Kubernetes is definitely not like you’re going to start over when you get to the endpoint. Building out an application with sane architecture around microservices with kind of discrete components that are walled off from one another and know what they’re responsible for.


Jonathan LaCour: [00:10:45] You can do that in a way with very simple atomic bits and pieces and building blocks with containers. And then later you can adopt Kubernetes as you start to want to glue them together and scale them and all of that. But you don’t necessarily have to. And you brought up LAMDA earlier. I think that people are often going to have better luck starting off from a position like that. Right. And then using something like LAMDA or using ECS, even a more simple container service that AWS provides. Like Fargate, which is kind of, quot