‫All right. These last couple of lectures you've started to
‫see all the different areas of Kubernetes that is
‫expanding, right. If you sort of think of it as like this
‫center little globe of
‫just the binaries and the base infrastructure of
‫Kubernetes, the rings keep
‫getting bigger and bigger, right. With Ingress, and
‫Operator pattern, and custom resource definitions.
‫It just keeps getting bigger.
‫Now, I want to talk to you about how it's getting even
‫larger. In fact, this is probably the one area where it's a
‫little crazy.
‫That is in the area of opinions around
‫how to deploy the YAML for these resources, right.
‫So far, you've seen the kubectl apply.
‫Well, that's going to get you started and that'll probably
‫get you through your first deployment of a
‫container orchestrator, right. You'll...whether you're
‫using Swarm or Kubernetes, you'll get that YAML, and
‫you'll have a repo, and you'll be storing it in there, and
‫that'll make sense.
‫Once you start to expand this out, and you have teams, and
‫you have permissions, and different types of permissions,
‫and people that have to govern or approve
‫things, everything gets more complicated.
‫What's happened in this world of
‫how to deploy your apps on Kubernetes, and that's
‫basically what this is about. We're going to talk about the
‫fact that there's now over 60, well really, there's like
‫80, but a lot of them are no longer real projects or
‫they're dead or archived.
‫But there's at least 60 ways to
‫add tools on top of Kubernetes simply
‫for deploying your applications on Kubernetes.
‫There's lots of opinions, right.
‫This is where the opinions start to come out about
‫how you should be doing this. Everything from Jenkins X to
‫Helm and beyond. There's
‫all these different things and opinions on, well,
‫Kubernetes isn't an opinionated infrastructure so we need
‫opinions to guide people
‫through the process of deploying and updating their apps.
‫So, everyone's got one. If you've read anything
‫about how to do this in Kubernetes, you've probably heard
‫of Helm. Helm to Kubernetes is Kubernetes
‫to containers essentially. Helm is the de facto
‫way that everyone looks to
‫create templates and use templating standards for
‫deploying either third-party apps or creating
‫their own custom Helm charts.
‫That's what they're called is charts.
‫It's essentially a templated YAML, but it allows Helm
‫to create or spit out the
‫YAML that will then go into your Kubernetes cluster for
‫you. But, it's not the only opinion, right.
‫I said there's over 60 at least last time I look.
‫There's actually a Google Sheet that I put in the reference
‫links. It's a little outdated, but it's the
‫last known list of all the places you could find these
‫different ways to deploy. Docker themselves
‫have their own opinion that is very interesting, especially
‫if you're wanting to be tight into the Docker ecosystem. That
‫is Compose on Kubernetes.
‫If you have Docker Desktop, you can
‫today enable Kubernetes, which you probably already have
‫done for this part of the course. You can use docker
‫stack deploy and instead of it going
‫to Swarm, you can send it to Kubernetes.
‫If you go look at the docker stack deploy command and look
‫at the help for that, you will see that there's an option
‫there to specify the orchestrator that
‫you want to use. In fact, in the settings of Docker
‫Desktop, you can tell it to prefer or default to
‫Kubernetes for the stack deploy commands.
‫That's pretty interesting because I thought that Compose
‫YAML was different than Kubernetes YAML.
‫Well, that's what Compose on Kubernetes now does.
‫It's a third-party tool essentially.
‫It's an opinionated way, from Docker, how
‫to deploy, or interpret, or technically
‫translate, the YAML of Compose, the Compose format, into
‫the YAML of Kubernetes format.
‫So, I've put a link in here for you to go check that out if
‫you're someone who's going to consider Docker Enterprise
‫as your enterprise tooling for Kubernetes
‫and Swarm and Docker in general.
‫Then,you should definitely check this out because that
‫comes out-of-the-box. One of the nice things about that
‫feature is that the workflow stays super
‫simple. Basically, you're using your Compose YAML
‫throughout the entire pipeline, and you can use it in Ops
‫and Dev. It doesn't force you to say, OK for
‫developers, you've got to have YAML for Compose and for
‫production and servers, you have to have this Kubernetes
‫YAML, and they are not compatible, right.
‫The idea with Docker was they thought this is too
‫complicated. Let's simplify it.
‫Let's just use one YAML standard for the entire control
‫pipeline.
‫And, I like it. The problem with it is
‫it doesn't support everything under the sun that Kubernetes
‫can do, right. I mean obviously, we have a single page in
‫the Docker Docs to list out all the features of a Compose
‫file. But, the Kubernetes YAML
‫is so complex that we have to dig into multiple commands,
‫and API references and all that, right.
‫So clearly, it can't possibly do it all.
‫The nice thing is on the Compose for Kubernetes website,
‫they talk about in GitHub the different features that it
‫does support.
‫It's the 80/20 rule there.
‫In other words, it supports the 20 percent of
‫Kubernetes features that 80 percent of us probably need.
‫So, you can get started with that and see if that workflow
‫would work for you. Another nice thing is in late
‫2018, they open source that Compose on
‫Kubernetes so you can now deploy it on any
‫Kubernetes infrastructure you have, and it just works as
‫sort of interpreter. It translates anytime you use
‫the Compose file from Docker and using Docker commands,
‫it will connect your Kubernetes cluster for you, translate
‫that automatically into Kubernetes
‫YAML and away you go. You can actually, at that point,
‫ignore a lot of the Kubernetes YAML for
‫your applications. You know, maybe you use Kubernetes YAML
‫for infrastructure stuff that you aren't deploying every
‫day. But, maybe for your developers to make it easier for
‫them to write Compose YAML and to get things into
‫production faster, you choose to use the Compose on
‫Kubernetes as the workflow.
‫Then, maybe you use Helm charts, which is kind of a
‫competing standard for your major
‫infrastructure. Because the thing about Helm is that it
‫comes out-of-the-box with a lot of these chart templates so
‫that you can maybe deploy Prometheus or
‫Elasticsearch logging with ELK, or something like that.
‫It'll come with those templates right out-of-the-box that
‫allows you to get started faster.
‫Also, just remember that these are all optional, right.
‫You can do Kubernetes with the standard YAML that you've
‫been playing with so far, and that's fine.
‫It doesn't require these other things.
‫They're just optional third-party tools.
‫Traditionally, as the team grows, when you get
‫multiple production Kubernetes clusters
‫and there's multiple teams involved, then everything gets
‫harder, and you'll probably end up with more than one
‫solution. You might end up with Helm on certain clusters.
‫You might end up with Compose on Kubernetes for your
‫developers, or something like that.
‫Or, one of these other 60 plus tools
‫in the ecosystem.
‫The last point is that since Helm is really the leader
‫in this space right now, that almost
‫every distribution uses it, or supports it, or even comes
‫with it out-of-the-box. Just consider that when you're
‫looking at these tools that you probably
‫can't avoid Helm in a large environment.
‫You're just going to have to use it.
‫The nice thing is nowadays is it's on 3.0
‫and that there's a lot simpler
‫deployment options for it in the 3.0 versus the 1.0 and
‫2.0. So, things are getting better and easier with that
‫all the time. A lot of these deployment tools are really
‫just helping you template your YAML in various
‫ways. Kubernetes itself didn't
‫really have anything for the longest time.
‫In the recent releases, it's now come out with something
‫called Kustomize with a K.
‫When you start seeing that word with a K, you know
‫that it's a special feature.
‫It allows you to do things
‫similar to Helm and these other deployment solutions,
‫but it's not really quite as
‫powerful as Helm, right.
‫So, Helm's still the leader.
‫Kustomize is sort of the new kid on the block, but it comes
‫out-of-the-box with everything you do in Kubernetes.
‫The kubectl command supports it.
‫Really what it is is it's just taking, instead of a
‫templated YAML, it's just taking YAML you already have
‫that is standard Kubernetes YAML, and you can
‫then take that file and then run something else on top of
‫it and change it with an override of sorts.
‫Kind of similar to how we do in Swarm.
‫We actually have in Swarm and Compose, we have override
‫files and stuff like that.
‫They now have this built out-of-the-box.
‫It's got a lot of features to it.
‫I think, in more or less, it's not quite there
‫in terms of the feature set of what Helm has, but
‫at least it comes out-of-the-box.
‫Remember, if you have Docker, the latest release,
‫19.03 or newer of Docker, now
‫has the docker app sub command, which
‫does its own templating of Compose YAML
‫and really is very comparable to this customized option
‫for Kubernetes. Again, if you're going to stick with the
‫Docker track and you're going to consider Docker Enterprise
‫or you just really like how Docker focuses on
‫the developer workflow, look into the docker
‫app sub command and also the docker app repo,
‫which I'll put in the resources here.
‫Because they have documentation about how you can take
‫Compose YAML, extract things like environment variables
‫and other stuff. Package it all up into a single image
‫and then ship your YAML as an image.
‫Which means you can now version your YAML and deploy
‫it with a single line without having to do like
‫pulling down of the YAML and then typing out long commands.
‫It's a pretty interesting way to do it.
‫It's using something new called the CNAB
‫standard, which we're not going to get into here, but
‫that's C N A B.
‫It was an announcement that Docker and Microsoft made in
‫2018.
‫You can check all that out on the Docker app website in the
‫resources. Again, all this stuff is about
‫optional third-party ways to customize
‫and extend the default YAML to make it easier
‫for your team as you grow.