‫Because of the immense flexibility we have with
‫Kubernetes, there's lots of styles for how you
‫do your work in the Kubernetes cluster system.
‫You've heard me talk about that before, right.
‫I've told you that there are different ways to fit your
‫workflow, and that you can use different commands in
‫different ways. So, that can be challenging when you're
‫trying to teach it because people really want to know how
‫they're supposed to be using it. Like what's the best way?
‫What's the best practice? That's hard because
‫it really depends on what you want out of it.
‫It's it it's an unappealing dated system.
‫So, there's lots of different ways to do stuff.
‫This is where I try to break that down.
‫So, this one's a key important one.
‫But, this is all just slide learning.
‫This is going to be me talking at you for a few minutes to
‫try to break down these concepts and apply what they mean
‫to Kubernetes specifically.
‫Before we get to recommended approaches, and
‫there's basically going to end up being three recommended
‫strategies for how to use Kubernetes.
‫This is where I need to break down some of these terms so
‫you know what that next lecture is.
‫You'll see this in a lot of blog posts and in
‫documentation. Imperative versus Declarative.
‫The best way that describes it, in relation
‫to Kubernetes, is to back up and just say
‫what it means in terms of software.
‫When we're writing software imperatively, we're focused
‫on the how of that program operating,
‫each step, in order, one after the other.
‫When we talk about a declarative approach to software,
‫we're describing more about what it should accomplish.
‫What are its end goals?
‫We don't care so much how it gets there just that it
‫does get there. Let's try an analogy.
‫Imagine you want a cup of coffee.
‫When I wake up every morning, I'm looking for that first
‫cup. If I'm going to make it myself, I'm going
‫to have to do it imperatively.
‫I'm going to have to think about boiling some water.
‫What's the next step? Well, I need some coffee beans.
‫Then I've got to grind those beans. How much exactly do I
‫need? How much water do I pour over those beans to get
‫the perfect cup of coffee, etc, right.
‫I'm going through each step, and I'm thinking about how
‫it's done, step by step.
‫That's imperative. When you look at Kubernetes, we'll talk
‫about that in a second.
‫Declarative mode. Think of it as more of
‫maybe I'm at a coffee shop and I'm talking to a barista.
‫I'm simply asking them.
‫I'd like a cup of coffee.
‫My only job is to ask for the cup of coffee
‫and it's up to them to figure out, hey.
‫Do I need to make it from scratch? Is there one already
‫made in the pot? Or is the pot too old?
‫They can do...they can...maybe have to retry
‫three times to make the cup of coffee because they messed
‫it up. That's fine.
‫I'm not asking how they make it.
‫I'm asking for them to produce me a cup of coffee.
‫Let's apply this to the commands you're going to be using
‫in Kubernetes. Let's focus on imperative,
‫which is what you've largely been learning so far because
‫it's the way to start learning any tool is
‫imperatively. You're going to be doing these things in the
‫order they need to be done, and you're giving it explicit
‫instructions on how to do it.
‫These commands, like kubectl run, and create deployment,
‫and update, which we haven't yet covered, or edit.
‫These are the different types of commands that will have
‫you starting in a state that you know.
‫When you use a create deployment command, you
‫know that the deployment isn't yet created.
‫Thus, you are using the create, right.
‫If you want to update, or edit something, you're explicitly
‫using that command to do that.
‫The nice thing here for command line and typing into the
‫CLI is that different commands are used for different types
‫of actions, whether it's create, or update, or delete.
‫That's easier for our brains to remember because we know
‫the action we're taking.
‫Just remember that imperative is easier when you already
‫know the state of the object or the resource, and
‫you're just getting started with using the tools.
‫So, you want to think explicitly, OK, I need to create a
‫service and that service needs to be a load balancer.
‫You know that kind of thing. Then, it's easier for us in
‫our human minds to type these things at the CLI.
‫It's unfortunately not easy
‫to automate. That's one of the biggest drawbacks to this
‫type of work is that it's really hard to get
‫an automated script, or tool, to
‫automatically handle the, Oh is this an update that
‫you want? Or is this a create?
‫Or is this a delete? Like you know, what am I supposed to
‫do here? It's hard for us to automate that type
‫of work. It's easy in our heads.
‫Easy for us to type at the CLI. Hard for us to automate.
‫Remember, declarative means we don't really know the state.
‫Remember the coffee. I don't know whether they have coffee
‫or not. They may already have some made. They may have to
‫make some from scratch.
‫I don't know the state.
‫I just know the end result that I want.
‫That's really fitting for a declarative model.
‫Some of the benefits here for us, and for automation, are
‫that the same command, usually you are going to be using
‫the apply command, kubectl apply.
‫That same command can be used regardless of whether we're
‫creating, or updating, or even possibly deleting,
‫resources. If you started looking at YAML, which we're
‫going to get into here in a minute.
‫That YAML can either be in a single file.
‫You can bundle lots of different types of resources into a
‫single YAML. Or, you can break them out into a single
‫object in each YAML file in a single directory, and you can
‫use one command to apply the entire directory.
‫There's lots of options there.
‫The reasons we don't get started using this method
‫is that one, we don't always need.
‫It it adds a little bit of complexity because you have to
‫create this file, and all of the stuff in, it before you
‫can even do it.
‫You may not have those from scratch, and you don't
‫necessarily want to create them just to create a pod or
‫something, right. So, getting started, the CLI makes sense.
‫Using the standard imperative commands makes sense.
‫But, as you start to think about production, and
‫automation, and doing this repetitive update process
‫over and over, like you're going to, then you start to
‫think about, OK. I need a more declarative approach.
‫The challenge there is you have to know all those YAML keys
‫and settings, and you kind of just have to start from
‫scratch and build up your expertise over time into all
‫the ways and things that you need to put in this YAML.
‫The great thing here is that your
‫investment is not wasted. While you're getting some
‫basic things done in Kubernetes now by typing the CLI's
‫like kubectl run or create.
‫Over that time, you're looking at YAML with the
‫output command, remember the -o yaml.
‫You can look at the output of the YAML.
‫There's other ways we can look at YAML.
‫We start building up our knowledge of what that YAML is
‫supposed to look like so that once you get to the world
‫in production where you're basically doing YAML all day,
‫you're going to be a little bit more familiar with the way
‫it's broken out. This YAML way is the
‫easiest way to automate your orchestration.
‫This is also the easiest way to get-ops
‫happiness. We won't talk a lot about get-ops in this
‫course. I recommend you go Google that because
‫it is a type of doing DevOps
‫work that uses the get tool as
‫your source of truth.
‫Basically, every time you want to make a change to your
‫environment, you edit some YAML.
‫You do the apply command.
‫You do a get-commit. Now you have this get-log of every
‫single thing you've done. That's one of the attributes of
‫the get-ops model of operations and doing
‫this with declarative is how you get there.
‫Let's look at the three ways that the Kubernetes teams
‫think we should be using the Kubernetes command line.