Kubernetes The Easy Way!

so oh no a kubernetes is if not you'll learn we have a nice one-on-one track today that will teach you a lot of kubernetes from the ground up but i'm gonna do is try to talk about kubernetes in the way you should be thinking about it so I wrote this guy called kubernetes the hard way so that everyone can learn how to do kubernetes ok there is a big difference from installing kubernetes and using kubernetes chances are you're not on both sides and we've come a long way raise your hand if you believe installing crew Bernays is easy what that's like 7 hands here's my first demo I'm hoping it works I think it's gotten to the point where it's so easy that you can ask for a cluster ok so we're gonna try this see if you can just ask for a cluster and see if it will appear fingers crossed say one for the demo gods so we're gonna try this now want send me a DM or anything to interrupt the flow Stratus okay go go talk to kubernetes engine sure here's the test version of kubernetes engine good day create kubernetes cluster how many nodes shall I provision 8 creating a 8 node kubernetes cluster in the S West one region that's what I call kubernetes the easy way [Applause] [Music] [Applause] what do you mean alright so if this today is not hard anymore what's hard is that collection of hardware that you have one print okay that's not our fault you got to figure that one out so the next thing we want to talk about is once you have a curb or a nice cluster again our goal is not to use ku CTL for everything that we want to do so what I like to see people doing people ask me all the time Kelsie what is the best practice for running kubernetes in production the truth is there are some known patterns but I'm not quite sure everything is super mature and set in stone where we can go off and just have a complete list of best practices you do this and you're good so what I like to think about is separate clusters based on your organization structure if you work in the enterprise and you have to open a ticket to get a deployment you probably need to have separate clusters for each of your environments trust me it will be easier that way do not go down the are back rabbit hole if you don't have to but as a developer how many people are developers in the crowd are you looking forward to getting your nice coop CTL installed on your laptop no you see that ops people no one cares as a developer you have probably one flow in mind everything else is noise okay so I have this registry or they have this app it's called hello world complex I know and as a developer this is how you envision the world okay and it's all of its perfection you want to clone a repo not install kubernetes is not your first step that comes to mind I'm going to clone the repo that I'll be developing against we'll do this here we'll go to my laptop and I'm going to do git clone amazing internet works all right and then as a developer you want your actions to trigger something else to happen ideally if I make a code change all I want is a URL to tell me where it's running you get bonus points if you give me metrics that tell me how well it's running so the next thing we want to do here is create a branch so we'll say git checkout will create a branch called change message so we're gonna change it from hello world to something else so when I come here and we're just going to edit this app go is the best programming language in the world I'm not biased at all yes you can clap for that hell yeah all the PHP people like no it's not it's okay all right so we're gonna change the message and we'll look at the different ract between the developer is how to build this application and what the dependencies are that's what the developer owns and that's okay contract to provide and that's where the docker file comes in sweet those are the only things I care about my source code might docker file everything else is implementation detail or should be so once we have this we'll commit it so git commit always use helpful messages like change message oh yeah who does this one do you hate when people do this would you add so you got your message and now we're going to push it so remember we have this branch get push or gin and then we're going to push this branch okay so at this point what do you expect to happen you know switch the coop CTL write some yeah Mille lots of people like that sweet yeah Mille nobody wants to write ya Mille what you expect is when this gets checked into a branch that it should be somewhere ready for me to test in a staging environment so we go to I'm gonna just go here so we can see some of the implementation details if I hit let's look at our bill pipeline how many people have intend continuous delivery bill pipelines damn we should have had a continuous delivery track because I think once you get to kubernetes this is the next holy grail that you have to do at some point this is going to be table stakes I think it already is but this is where you really should be focusing your time big time so here's this bill pipeline and have a few rules based on a developer's intentions one is if I push to any branches set for master based on this regular expression I want to deploy to the station environment if I tagged it then we want to go to QA and we'll build a container image based on that tag and propagate it to production that is the goal now some of you're like where's the mo files where's the deployment descriptor implementation detail folks no one cares or shouldn't so now we go here and we look at our bill history so I push through this branch and we see just now a bill completed and succeeded it built an image with this particular commit so this is the commit of the repository so the developer can chase it back to see how was built and then if we go to our pods and I hit refresh we see we have our app in the staging environment now you don't actually have to show this to anyone ideally you should have a URL that maps to this running application there's no need to use coups ETL to figure out what the IP is anyone ever heard of this thing called DNS always we if you've never used it people have reinvented DNS all the time like what are you doing that's DNS I know it's not as a distributed service discovery DNS what you have in it again this week so we see our changes live so what happened here let's not worry about it quite yet so once it's in staging the next thing I want to do is maybe it looks right to me I'm going to merge this I'm gonna tag a release hopefully your tagging releases and not building docker containers on your laptop if you are being shame and then change your behavior alright so the next thing to do as a developer is I'm going to check out master and then I'm going to merge in the change message branch everything looks good here and now I'm going to push it or gen master this is the experience when you adopt all these tools that you should be after do not leak your implementation details into the developer workflow you don't have to once I push this change nothing should happen because I haven't done the thing to trigger everyone at once what do I need to do to trigger the next step tag a release so we're going to tag this release get tagged 1.0 get push origin tags so now that I've tagged this release my workflow I assume at some point if the bill passes and the test pass that it should end up wherever you tell me QA is I don't care where it is give me a URL if you give me a URL we'll come here and we know we need to go through our build pipeline so we'll take a peek at that so if we go to images really quickly and we'll see down here in the hello world we see that right now our build is still probably going and when it's done what we should see is one dino tagged here and if that's successful we should see that deployed to the next environment I'm impatient so I'm going to hit refresh as if it's going to go faster it probably won't let's look at the bill history so let's see what it's doing we'll take a peek into the bill pipeline so what I'm doing now is checking out the repository grabbing the tag and then I'm actually using qu CTL to actually check out my mo file from a separate git repository that actually holds my kubernetes deployment structure for that entire environment now the nice thing about this is that you can actually have multiple teams work on those kubernetes configs independently of the pipeline and what i'm doing in this case is i'm checking out the infrastructure repository and I'm using the coop CTL patch command to patch the one container image that I'm concerned with and I'll issue a commit to the infrastructure repository I want a history for all of these things so if this works out well I can go to my QA infrastructure repository and see now we have a new commit if I look at that new commit what we'll see here is the change that I expect all right and again no one needs to see this repository but it's a good place to actually track all the changes that you do whether it's a human doing the change or CI CD system doing the change so once this is in place where do you now expect the deployment to be let's try it with just a URL without looking at anything else so we come here and we'll go back to DNS and then we'll just hit queuing so it looks like it's working and we'll verify the deployment here hit refresh and it's there now there's a missing piece here if you don't want people asking for coop CTL again then you got to give them visibility they can't just be flying blind here that's when people start asking for access again so you got to give them more tools now anyone notice anything hidden in my deployments I'm going to show you something here ku CTL get pods as I'm going to show you the functionality that I get first so I'm going to go here and I have Griffin are running over a proxy and I'm gonna show you what value looks like right we get caught so much in the tools that sometimes we forget about the actual value that they bring what you want to do is give people visibility one way of doing that is to give them a curated dashboard that gives them insight into what's actually happening so this is my QA dashboard and ideally if someone were to hit the cue a URL maybe they're doing some testing you got to put those Sleeps oh we need curl actually okay so now we're hitting the actual application maybe you're running some integration tests so ideally if you give people visibility they will stop asking for tools like KU CTL to do their job because now they can actually just kind of observe what's actually happening in the cluster so in addition to metrics you probably want logs HTTP traces the more visibility or tools that you give to people the less they're gonna probably want to touch the infrastructure right and that frees you up to actually upgrade it move it around without people getting attached to where it's actually running so once everything looks good in production what do we expect to happen now not everyone can deploy straight to production this is why I don't like to show these into n pipelines where you go straight to production anyone ever had an outage in production what does the developer say it was a small change but everything is down not my fault man so you might want to put that manual check in there just to say what's actually happening so let's take a look and see what's going on so in my case I need to trust but verify so what I'm doing in the last stage of my pipeline I'm just going to issue a pull request from the bill system the bill system will also propose changes to the infrastructure so that the team can understand what's actually happening until we get a little bit more comfortable with the system so in this case I'm proposing a commit message by this system that I want to change this particular container image to this tag the same one that's used in QA a lot of people get confused about this one do not rebuild the container image between environments that defeats the whole point of testing and QA but maybe between stage and s you're kind of prototyping and figuring things out review the change looks good one dot o and then now what I want to do here is review it looks good to me rebase and merge confirm and you guessed it if I do that what do you expect it to be you expect it to be in production so we'll look at the last part of the bill pipeline so we'll come back here and as soon as I merge into the master branch whether I was doing it as a human maybe I want to change the entire structure of the deployment config maybe I want to update the service type that's underneath there again all of that is subtracted away from the developer because what I'm doing now is I'm taking all of my infrastructure stuff and I'm put it in this one directory structure and what you can do is coups ETL apply recursively and everything underneath the kubernetes directory it will just apply again including the changes that you've made from the CI CD system that are just concerning the app so that means your services ingress all your deployments if they're all combined and that way you can actually stop messing with this thing once you start to get to a stable point where you're not changing your configs as much anymore now what tools should you use the magic of figs go to some sessions there's ten of them tons of them there's helm there's case on it there are many of these tools that will make it much easier than couch ETL patch to manage these things so once you all have this in up and running the last thing that you think about is how do I actually do other changes without going to the pipe you need an easy way to break the glass right you can't have everyone there maybe emergencies that you need to sized up the process at some point you'll notice one thing here as I wrap up is that in our infrastructure directory when you look at my deployment config you'll notice one thing missing I don't include the replica count if I don't hard-code the replica count here I'm free to use an auto scaler okay side by side or you can use some other system within the infrastructure to do this so we're going to see how we can actually integrate a last system to see what this looks like once we get everything working so we're going to do is look at the number of pods in production and see what it looks like when another system comes up on top so here we'll say while true get the pods context production so if you're new to kubernetes you can actually use coop CTL when you have to and if you do it actually does support multiple clusters go away ciri all right we see we have one pod running and since the replicas count is not included in my config we'll do our last bit to see if we can actually have multiple systems interact with the cluster because kubernetes maintains the cluster state so we have multiple actors interacting with these configs at the same time so here we go we're gonna try this last thing demo guys have been on my side so far okay google talk to kubernetes engine okay let's get the test version of kubernetes engine greetings scale the hello world deployment how many replicas would you like you crazy break everything ten scaling the hello world deployment to ten replicas thank you I gotta admit that was pretty dope and with that I would like to end the presentation thank you [Applause] [Music]

Channel: Coding Tech

Views: 395,183

Rating: 4.8790011 out of 5

Keywords: kubernetes, google cloude, deployment, app deployment, qa

Id: kOa_llowQ1c

Length: 18min 46sec (1126 seconds)

Published: Mon Jan 01 2018