Cloud Native Computing Foundation KubeCon + CloudNativeCon Europe 2017 (Berlin), 6 Apr 2017

Previous Meeting

⏯

youtube image

►

From YouTube: Lightning Talk: Zombie Kubernetes!: Making Nodes Rise From The Dead - Michael Johnston

Description

Lightning Talk: Zombie Kubernetes!: Making Nodes Rise From The Dead - Michael Johnston & Mark Brandon, Qbox.io

How to install Kubernetes using immutable configuration. Remove points of provisioning failure by leveraging cloud-config for configuration.

About Mark Brandon
CEO, Qbox

About Michael Johnston
Sr. Systems Engineer for Wal-Mart Stores Inc. for over 10 years, Director of DevOps at Acumen Brands for 3 years, currently Lead Infrastructure Engineer at Qbox.io.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.

A

Please welcome to the stage Michael Johnston of cubics IL.

A

Hello, everybody, my name is Mike Johnston I'm with Q box, I'm, a senior infrastructure engineer and a co-creator of supergiant, which is a open source, kubernetes management platform. My presentation, zombie kubernetes, is a public service announcement of sorts to persuade you to use immutable infrastructure with your kubernetes deployments. If you aren't already so I bet, you've often sat around wondering why don't I have my own personal army of zombies? Also? What is a mutable infrastructure?

A

Well I'm here to help answer at least one of those questions so I'm not going to assume that everyone knows this, but I'm gonna start with the basics. Immutable infrastructure is the process by which, whenever you want to update a server configuration in your fleet, you do so by creating a new configuration applying that new configuration to a new server and actually destroying the old server in the process.

A

Now this is different in the sense that traditionally, you would update that server in place kind of like a horde of zombies rising from the dead. So many of you may sit back and think. Well, of course, this is a no-brainer I already do this, but I've been struck by the number of kubernetes users over the last year that have no idea what immutable infrastructure is in the first place or cling to old provisioning methods when setting up their clusters, don't get me wrong.

A

Older provisioning tools are great, but when you're dealing with the infrastructure, that's ephemeral in nature to begin with its overhead, its overhead, like complexity, points of failure possible security holes that you really want to try to avoid.

A

There we go so if you're using containers already, you already are using immutable concepts. Compute containers are immutable by nature. If your your container scope is or should be defined well defined by its function. When you update a container, you put that new complaint container out there, replacing the old container.

A

So how do I apply this type of thinking to my kubernetes cluster? Well, first, you could leverage something like user data cloud config. Anything like that you could use pre-built images, something like a mis, provisioning or cluster in this way, has the benefit of being typically much faster than using older provisioning methods, the faster that we can get nodes to boot, underneath our kubernetes cluster, the more agile that kubernetes cluster is when faced with hardware failure or in the case that we need to upsize or downsize that cluster.

A

Even a few minutes and savings in your provisioning process can help make your application more agile.

A

So what do we need for a declarative, node configuration? Well, obviously, you need to have a cube. Let in your configuration something like your cube proxy, maybe dock our configuration any networking configuration. The idea here is to keep things simple.

A

So what happens if any of these processes actually fail? Well, in that case, we kill the node. We replace it.

A

Your infrastructure at that point comes back to life from the dead and I typically use stuff, like health care, health checking tools built into either load, balancers or home rolled health checking tools to check the health of every individual component of my kubernetes cluster.

A

If any one of those components has a failure, I killed a node and replace it with a healthy one.

A

So what about your kubernetes masters? Well, it can be a little bit more complicated to configure criminales masters in this way, but especially if your sed cluster is separate off onto onto its and why do its own cluster? It's totally doable again.

A

This is just achieved by taking the basic components of your kubernetes master, placing them in a predefined configuration putting some type of process in place to check the health of all of those components and take care of any misbehaving nodes, and a huge caveat to this obviously would be if you're running a single, node and master which, if you were running that in production, shame on you, you should be running a che setup for your master.

A

So, in conclusion, immutable concepts will help reduce complexity in your overall infrastructure, enhance speed and reliability, a failover and also increase application responsiveness within your app within your infrastructure.

A

So that's it from me: I'm Mike Johnston from Q box, I'm, a senior infrastructure engineer. Our business is hosting elasticsearch for our clients. We put these practices in production with our business for well over a year now and the result the results have been amazing if you have any questions, I'll be available after the talk and throughout the week at the conference. So thank you very much.