***This is part of an ongoing series I call "Mode 1 Storage Guy goes to a Mode 2 World." I'm not an expert (yet), YMMV.***
Anyone working on containers will have heard the term "declarative state" with regards to the number and type of containers. Basically, it just means you have a platform that ensures you always have x number of containers. In other words whenever a container dies/fails for any reason, the platform will recreate one in its place. You're declaring how you want it to be from now on.
Say Kubernetes you tell it "I want 100 apache webserver containers" on a cluster of 10 hardware servers. It will spread 10 containers onto each server. If you lose 2 servers, Kubernetes will re-create those 20 lost containers and spread them across the 8 remaining.*
This is very different from a Vmware-type mindset. In Vmware you can say "deploy 100 vm's off this template," but Vmware doesn't watch the vm's, count them, and re-start them if they come down. This is "imperative code" meaning "do what I tell you now," following a single order.
The existence of declarative state means storage has to change. Previously, the storage layer just creates 10 LUNS, present them to the right servers, and you're done. If the server dies, storage doesn't automatically present those LUNs to a new server, or delete them. It sits, static, until someone comes and manually fixes it.
Luckily, in Kubernetes 1.5 there is a new concept of StatefulSets. StatefulSets are all about enabling stability (i.e. persistence), and when combined with NetApp's powerful Trident connector it means you can create Declarative State Storage. Which is exciting, because as far as I know I coined the phrase :-)
Declarative state storage means when a container is deleted, its corresponding volume is deleted. When a container dies and is recreated, its corresponding volume is connected automatically. When an application is scaled from 10 to 100 containers, the volumes are provisioned automatically.
More to come!
*In reality, Kubernetes creates a synchronous copy of each container. So it doesn't actually re-create the container: it switches the secondary copy of the container to be primary (lowering the impact of interruption) and then re-creates a secondary copy elsewhere. Cool stuff.
Anyone working on containers will have heard the term "declarative state" with regards to the number and type of containers. Basically, it just means you have a platform that ensures you always have x number of containers. In other words whenever a container dies/fails for any reason, the platform will recreate one in its place. You're declaring how you want it to be from now on.
Say Kubernetes you tell it "I want 100 apache webserver containers" on a cluster of 10 hardware servers. It will spread 10 containers onto each server. If you lose 2 servers, Kubernetes will re-create those 20 lost containers and spread them across the 8 remaining.*
This is very different from a Vmware-type mindset. In Vmware you can say "deploy 100 vm's off this template," but Vmware doesn't watch the vm's, count them, and re-start them if they come down. This is "imperative code" meaning "do what I tell you now," following a single order.
The existence of declarative state means storage has to change. Previously, the storage layer just creates 10 LUNS, present them to the right servers, and you're done. If the server dies, storage doesn't automatically present those LUNs to a new server, or delete them. It sits, static, until someone comes and manually fixes it.
Luckily, in Kubernetes 1.5 there is a new concept of StatefulSets. StatefulSets are all about enabling stability (i.e. persistence), and when combined with NetApp's powerful Trident connector it means you can create Declarative State Storage. Which is exciting, because as far as I know I coined the phrase :-)
Declarative state storage means when a container is deleted, its corresponding volume is deleted. When a container dies and is recreated, its corresponding volume is connected automatically. When an application is scaled from 10 to 100 containers, the volumes are provisioned automatically.
More to come!
*In reality, Kubernetes creates a synchronous copy of each container. So it doesn't actually re-create the container: it switches the secondary copy of the container to be primary (lowering the impact of interruption) and then re-creates a secondary copy elsewhere. Cool stuff.
No comments:
Post a Comment