‫Let's talk about why you might need Kubernetes.
‫Now as a review, check back with the earlier
‫sections. The first section for Swarm and there's a lecture
‫titled Swarm Mode Built-in Orchestration.
‫That gives you some basics around the problems that
‫orchestration solves and why you might
‫need it. I will stress that that at first,
‫it's definitely important that you understand what
‫orchestration benefits you will need
‫in order to deploy your applications, and whether or not
‫you even need orchestration to begin with.
‫Orchestration is definitely increasing in popularity, but
‫it's not the only way to run containers.
‫We've talked about using Docker runs here.
‫We've talked about Docker Compose.
‫We've talked about other platform offerings and services.
‫I have customers that still run containers on
‫single nodes in AWS without
‫orchestration. They use the features of that
‫platform to create a similar like abstraction
‫as orchestration, where they maybe use auto scaling groups,
‫Elastic Load Balancing, and a lot of other things that
‫we've all used for over a decade to manage
‫our application deployments.
‫They have such a refined system that they just don't see a
‫lot of benefits out of completely changing all that to
‫orchestration.
‫Now, most of us will eventually use some form
‫of container orchestration because that's really the way
‫I think the industry is going, and these are all going to
‫be these extra layers running on top of Docker, or
‫some other runtime, which is what you've learned throughout
‫this course.
‫One of the simple formulas I use for whether or not to use
‫orchestration, are taking the number
‫of servers that I'm going to need for particular
‫environment, and then the change rate
‫of my applications, or the environment itself,
‫and the multiplication of those two really
‫equals the benefit of orchestration.
‫What I mean by that is that orchestration is designed to
‫automate change and monitor
‫the state of things and ensure everything is the state you
‫expect it to be.
‫For instance, apps running in a healthy state.
‫When you're starting out, you may only
‫need a single server, or just a few servers, and
‫if you're not changing your applications very often, let's
‫say you're only changing them once a month or less, then
‫orchestration, and the effort involved in deploying it,
‫managing it, securing it, may be unnecessary
‫at your state. Especially if you're a solo developer
‫or just a very small team.
‫That's where things like Elastic Beanstalk, or
‫Heroku, the application deployment platform, that's where
‫a lot of those start to shine as alternatives
‫to doing your own orchestration.
‫Of course, the most common question that I get
‫from people once they've figured out that they need
‫orchestration, is to decide which one they want.
‫Really at this point in 2019, there are
‫at least two or three major platforms.
‫If you include the Cloud solutions, there might be four
‫or five major platforms there.
‫The ones I talk about in this course are the top two that
‫work everywhere. That's Swarm and Kubernetes.
‫Then you have other ones that are specific to Cloud
‫platforms, like ECS, which is only on
‫AWS, and more traditional offerings
‫that have been around a little bit longer like Cloud
‫Foundry, or Mesos and Marathon.
‫But I think if you're someone who's concerned about running
‫containers on premise, and in the Cloud,
‫or potentially multicloud, you may not want to go with
‫those Cloud specific offerings like ECS
‫because those were around before Kubernetes was.
‫So, that was sort of a legacy solution that Amazon
‫still supports and it's still a neat option, but only if
‫you're specific to AWS and that's the only place you ever
‫plan to deploy containers.
‫For a lot of my customers, and for a lot of my students,
‫the choices are usually, I need something that's hybrid.
‫Meaning that I can run it in my data center or in
‫multicloud. It can't just run in one location
‫only. That comes down to usually
‫Swarm or Kubernetes as their big choices because those
‫are two solutions that are the most popular
‫container orchestrators.
‫They run on every cloud, and in data centers,
‫and even small environments possibly like IoT.
‫If you decide on Kubernetes as
‫your orchestrator, the next big decision is which
‫distribution you're going to use.
‫The first part of that is to figure out if you want a Cloud
‫managed solution, or if you want to roll your
‫own solution with a vendor's product
‫that you would install on the servers yourself.
‫Common distributions that are vendor supported that you've
‫heard me talk about, including Docker Enterprise and
‫there's other ones such as Rancher OpenShift from
‫Red Hat. Canonical, the Ubuntu company, has
‫their own version.
‫VMware has their own version.
‫PKS as well.
‫In fact, there are so many infrastructure and software
‫company vendor solutions for Kubernetes now
‫that it's a little bit overwhelming.
‫I'll give you a link in the resources to a list of the
‫Kubernetes certified distributions.
‫You want to use one of these because they guarantee that
‫the API from Kubernetes is used directly,
‫and that it's fully supported.
‫So that the ideal case is that you can take
‫your workloads and your YAML files that design
‫your infrastructure, and you can move those from one
‫Kubernetes vendor to another and they should work
‫out-of-the-box for most things.
‫Now there's another option I'll just mentioned here which
‫is to use the raw GitHub upstream version
‫of Kubernetes.
‫That is what all the distributions are based on.
‫For example, if you look upstream and you see
‫Kubernetes 1.14 release.
‫Then, when you look at a vendor product, you'd be
‫interested in which Kubernetes versions they support.
‫Usually, vendor products are a few versions behind,
‫but nowadays, the race is that they all just
‫stay up to date as much as possible.
‫So, I tend to see them only one version out of date
‫at most times.
‫Now, the thing that you get out of vendor solutions,
‫besides just that vendor's support options,
‫is also bundling other tools with it.
‫One of the things about Kubernetes that's a little
‫different from Swarm is that it needs a lot of
‫things added to it to really make it easy to use
‫out-of-the-box. So, you probably, when you get a vendor
‫solution, are going to see things like custom
‫authentication solutions, custom Web administration,
‫and custom networking, just to name a few.
‫I will generally recommend to you,
‫without knowing any of your requirements, that you probably
‫don't need the pure upstream version
‫of GitHub's Kubernetes.
‫You don't need to clone the repo of Kubernetes
‫and run just that.
‫Now, it's great for learning.
‫In fact, I recommend starting with that as the way to learn
‫Kubernetes. But, once you get into vendor solutions,
‫those are going to all be a little bit different with
‫security, and networking, and other stuff.
‫So, it's going to be hard for you to learn one and then
‫just assume that the other one acts the same way.
‫However, when you start talking about production, I would
‫expect that you would try to use one of those vendor
‫solutions first because they're going to be easier to
‫manage. You're going to have better support options.
‫Generally, things will just work better and faster
‫out-of-the-box.