‫In the last video, I covered Imperative vs.
‫Declarative. We talked about the specifics in Kubernetes
‫of one or the other.
‫Really, when you look at the Kubernetess documentation, it
‫lends itself towards three, different styles.
‫There's a subtle difference, but they're
‫really on a spectrum of all the way on imperative on one
‫side and all the way declarative on the other.
‫Then this nice, little option in the middle if you so
‫choose to use it. In this course, so far,
‫I've been teaching you the strict, imperative CLI
‫commands. That includes run, expose.
‫Maybe we have scale.
‫We didn't cover edit but it does exactly what you think it
‫would. It edits a resource in real time.
‫Or create deployment, which is the new way to do a run.
‫These are really best for learning how things
‫work. Learning the resource types and what they do, and
‫personal projects and really small setups where maybe
‫you're the only person in charge. You're not trying to
‫automate. You're not trying to build out a full production
‫workflow, and CICD, right.
‫That's great for those.
‫Then there's this nice middle ground that Kubernetes offers
‫you with the create commands
‫that you can either use the create commands themselves, but
‫you can also use those with a YAML file.
‫You can use create -f, and you
‫can give it one of those specs like we saw earlier.
‫You can give it a spec, and it will create any of
‫the objects you have in there. You could have multiple
‫objects in that file. You could have a deployment, plus a
‫service, in there.
‫Maybe some storage needs that you have, networking
‫setups, whatever. You could have all that one nice file.
‫Then, if you needed to replace anything in
‫there, you could edit the file and then use the replace
‫command, which we haven't covered yet, but it does what you
‫think it does. Then, there's the delete command, which we
‫have used, which does what you think it does as well.
‫The nice thing here is it's kind of middle ground, right.
‫It forces you to use YAML so that you've documented
‫what you're doing, and you have this change record if
‫you're using something like git.
‫Hopefully you're using git.
‫The benefit there, though, is for us humans,
‫we're using the create, or the replace,
‫or the delete. So, it gives us this explicit verb
‫to use so we know we're not accidentally
‫deleting something when we're using a create command.
‫And we know we're not accidentally deleting something when
‫we use the replace command.
‫So that helps, right.
‫That's a good, middle ground as you get your feet wet in
‫the YAML specifications that you're going to need to use
‫when you get to the full, declarative object
‫model. That is what I was talking about earlier.
‫That is where you're only using YAML and you're only
‫using the apply command.
‫There's other commands to help you with the apply, like the
‫diff, which will show you the changes you're about to take.
‫But, apply is simply editing
‫YAML, running the apply.
‫Edit some more YAML, run the apply.
‫This is similar to Swarm where we had Swarm stacks.
‫If you remember, there's a docker stack deploy command
‫and in order to update those, you use the same command over
‫and over and over again.
‫That's the same style here with their full-on declarative
‫objects. It's nice that they have documentation, and you'll
‫see this in the resource links for this lecture, a
‫very detailed page on these three different types.
‫I encourage you to check that out.
‫The real rule I'm going to give to this whole
‫thing, even if you go read the resource page about it, is
‫to just not mix the three approaches.
‫It's more important that you don't mix these three when
‫you have true production dependencies.
‫In production, I'm really going to advocate you try to
‫stick with, as early as you can in your
‫model of maturity, with the
‫full-on declarative model using the YAML files
‫with the apply command.
‫The sooner you get comfortable with that, the sooner you
‫are used to documenting that in YAML and
‫saving it in a git-commit every time you change it, that
‫process will really benefit you later on.
‫When anyone wants to see changes you have, they can go look
‫at the git-log. Most of us are probably doing something
‫in git today so creating another git repo just to store
‫these YAMLs isn't going to be a lot of effort for you,
‫right. Even if you're just doing git locally on your
‫machine, git locally can
‫basically help you see the history of changes that
‫you've done to these YAMLs so that when you forget in six
‫months what you changed three months ago, you can go back
‫and look and see what you're doing there.
‫That is really going to save you a lot of time.
‫The most important rule is don't mix the approaches.
‫If you create something with run, it's going to be harder
‫later to use the apply to manage that resource.
‫There are little tricks of the trade you can get around
‫with some of these commands to try to edit objects later
‫without screwing them up.
‫But really, if you're going to be doing production, you
‫probably shouldn't start with those run commands on your
‫production server. You should probably think long term and
‫stick with the YAML. My four tips here are
‫learning the command line like you're doing.
‫Learn that imperative command line so that you can operate
‫it locally. And you will need those commands sometimes for
‫troubleshooting, and testing, and servers as well.
‫Then as quickly as you can for getting ready for your first
‫production Kubernetes is to learn the apply command,
‫the diff command, the YAML specification
‫for all the resource types you're going to use.
‫Then storing it in git like I'm saying.
‫Even if it's just local git or git repos somewhere
‫that your team can use.
‫Remember, this method of editing the YAML,
‫saving the change in git, then applying it with
‫kubectl apply, then saving it again,
‫and storing changes in git.
‫This process will get you down the road
‫of DevOps automation and to that git-ops
‫that I mentioned earlier, which is I think where some of
‫these tools are starting to go. Where we're git centric.
‫We're doing changes in a git repo just like software
‫coders do..
‫We're doing the same thing with this DevOps workflow.
‫We're sort of adopting the way that they do their change
‫work in a team for our own operations and tooling.