‫So, what's next for Kubernetes?
‫That's a question I think a lot of us have when we're
‫looking at how rapidly it has grown, and the entire
‫ecosystem around it, and how that is just too much
‫for any one person to handle.
‫What's the future?
‫Well, the good news is if I had to predict it,
‫I think that the future is that it needs to start getting
‫boring. You'll hear a lot of the founders talk about
‫this whenever you see them in public.
‫You know, they'll just talk about how we need to make
‫infrastructure boring as much as possible
‫so that we can rely more on the things we do on top of
‫that. Because really, all of this is here just so we can
‫get our apps out there, right.
‫The point of Kubernetes isn't to be Kubernetes itself.
‫It's to allow you to do the things you want to do faster.
‫I think for Kubernetes, if you looked at the last few
‫releases, it's really started to focus on
‫reliability, stability, security,
‫just basically getting so stable
‫that it's just there.
‫You don't have to worry about it so much.
‫You don't have to fix it so much.
‫They do have regular releases, so you definitely get to
‫check up on the release schedule, and the release notes,
‫which I've linked to in this video.
‫One thing that did happen this year, in 2019,
‫was a big security audit of a lot of the core
‫code which revealed a lot of things.
‫In fact, on their blog, they have a full, detailed
‫analysis of what happened.
‫I think that's really cool that an open source project as
‫important and as big as this, not only did the security
‫analysis from a third party, but revealed all the potential
‫problems and results.
‫I think it resulted in a lot of PRs that upfront were for
‫quick fix things, but also some stuff that
‫they will eventually fix over time.
‫It's not so much that it was necessarily vulnerability
‫based, but more of this area could be
‫improved so we're going to change it over time.
‫Another thing you'll see is some of these older concepts,
‫of when it was a simpler tool, will start to fade away as
‫they get removed. I think storage plugins that aren't
‫CSI will eventually get pulled out so that you'll have
‫to rely on CSI for your storage plugins
‫instead of the built in stuff.
‫You'll see different commands like the kubectl
‫run change and stop giving us warnings because it'll
‫default to being a simple pod runner rather than having
‫all the generators built out-of-the-box.
‫Then you'll see other stuff I mentioned here, like service
‫side dry run, get stable and more features
‫around it. Because I think there's a strong push for better
‫auditing, better understanding of change over
‫time. What is going to change before I do it, what
‫did change after I did it, and those sorts of
‫reporting metrics.
‫When it comes to third party, that's going to continue to
‫balloon and grow, and it's really more than any one of
‫us could possibly know.
‫Helm 3.0 is just about to be finished.
‫We're definitely going to have more operators that
‫will be for third-party tools to make it easier to deploy
‫those and manage them in Kubernetes.
‫This is really more of a hope, but I'm
‫thinking that we're going to get a lot more focus on
‫declarative workflows.
‫Because this new theme around DevOps, and more specifically
‫git-ops, that's git ops,
‫which I've talked about on my podcast.
‫The git-ops workflow is a relatively new concept,
‫but the idea that us operators,
‫and that's the people that are managing these Kubernetes
‫clusters, we're really acting as operators.
‫The operators are taking the advancements from the
‫software teams where they've had to manage
‫code, and code change over time, and releases,
‫which has given the rise of tools like GitHub, right, to
‫use those same tools for managing our infrastructure
‫in a declarative way. You've heard me talk about that.
‫I think that when you look at the feature set over time of
‫Kubernetes, you can see how it's becoming
‫more declarative in style, and the feature set and focus
‫is on that declarative workflow.
‫I'm hoping that we'll get better tooling and the ones we
‫have we'll get more features over time.
‫Another big thing here is Windows Server support.
‫2019 saw the
‫big announcement around Windows Server support for server
‫2019, and that's just in its infancy.
‫That is something that Swarm is technically ahead
‫of than Kubernetes.
‫Where Docker and Swarm have had Windows Server support for
‫years now, and it's definitely improved over time.
‫But, they started that with Server 2016 and have been
‫pushing that forward and making it better.
‫Whereas, Kubernetes just now in Windows Server
‫2019 is really saying that they have support.
‫From people that I've heard talking about Server in
‫production, Windows Server could still use a lot
‫more work in the Kubernetes world to be as equal to
‫Linux. So, I think that's going to be a big area of focus
‫as more Windows enterprises
‫adopt these container orchestrators.
‫A last few things here is definitely the Edge cases
‫will be worked on.
‫Things like machine learning.
‫Things like Edge and small infrastructure
‫that is going to all be focused because at the beginning of
‫Kubernetes, it
‫was very large and very cumbersome, but they're pulling a lot of it out
‫and making it easier to deploy.
‫That's why you're seeing tools like kubeadm come out and
‫be able to deploy HA clusters.
‫It's fully secure and if fault tolerant
‫out-of-the-box. Those are all things that are sort of
‫coming in to fruition now.
‫Part of that future is knowing about other
‫related projects. This is just really a
‫quick list of the things that I haven't mentioned in this course that
‫you might want to check out. Because Kubernetes itself has
‫become the platform that all other things are
‫starting to be built on. In fact, that was really the
‫original goals from the authors of the project.
‫They never really meant for us to use Kubernetes directly
‫in terms of the raw, open source
‫Kubernetes.
‫They really meant for other people to build abstractions on
‫top of it for us to run our workloads.
‫That's why you see distributions coming out, in a lot of
‫cases, because they're building another layer on top to
‫do that. In this case, we're seeing all
‫sorts of other infrastructure come out for doing other
‫things. First up, is Knative.
‫This is around the server lists, and it's definitely
‫an official CNCF project so it's tightly related
‫to the Kubernetes world.
‫If you're interested in server lists, it's definitely one
‫the projects you want to check out.
‫Next up, a couple of projects from Rancher are
‫K3s and K3os.
‫K3s is essentially their
‫team taking the complex deployment and management of
‫Kubernetes and simplifying it down, stripping
‫out all the unnecessary things that come with it.
‫Maybe some of the legacy commands and code.
‫Maybe some of the storage drivers that you no longer need
‫if you have CSI.
‫That sort of stuff. They just pull it all out, and they
‫give you a really easy database.
‫It doesn't even use etcd out-of-the-box.
‫It uses a simpler database.
‫It's really meant for things originally like IoT.
‫But now, with their goal of being make
‫Kubernetes as simple as Swarm, which it was said
‫by Darren Shepherd, their CTO and co-founder, at
‫DockerCon this year. It was a pretty interesting statement.
‫He was really saying that, you know, Swarm does so well in
‫the deployment, and ease of use, and the
‫minimal impact. It's a very small binary.
‫It has very little overhead in
‫terms of the infrastructure. Kubernetes is the total
‫opposite of that. They're trying to find the middle ground.
‫Is it possible if we strip out enough stuff and
‫still make it true Kubernetes, can we make it super
‫easy to deploy on small systems like ARM, Raspberry Pis,
‫stuff like that. So, that's a project to watch.
‫K3os is an operating
‫system with K3s on top of it.
‫It's a very minimal Linux install that's
‫designed to run K3s on
‫small appliances. That's a pretty new one but an
‫interesting project nonetheless. Another really big area of
‫focus, which you will hear me talk about a lot more on
‫my podcast, is service mesh, which is a new concept the
‫last couple of years, and really a new term.
‫We haven't really used that word in the industry before.
‫Service mesh is the
‫idea of this proxy layer throughout the entire cluster,
‫not just for incoming connections from the Internet, but
‫really for all the parts of your app.
‫It becomes a middleman to controlling,
‫in terms of security, in terms of monitoring, and
‫routing to the proper locations, all
‫the traffic for all the parts of your distributed app.
‫It's a series of projects that
‫came out of the problem of microservices. If you've ever
‫done any microservices, one of the real challenges is, is
‫what was in a single binary on a single server and
‫relatively easy to troubleshoot becomes dozens of
‫containers, over dozens of servers.
‫That becomes very difficult to troubleshoot unless
‫you have great networking tools.
‫So, service mesh is pointed
‫at that problem and trying to become a standard, with
‫standards behind it, around putting
‫a layer there to have increased visibility, monitoring,
‫troubleshooting and security around our
‫distributed apps and our microservices.