‫So far with Kubernetes, we haven't really discussed
‫storage or volumes.
‫You've dealt with that with Docker, and then with
‫Compose, and Swarm and to a
‫certain extent, it's the same thing in Kubernetes.
‫You have containers, and we assume that the containers are
‫stateless, meaning that when you throw the container away,
‫everything in it goes away.
‫When you replace a container with an update, or you change
‫something and you apply it with a kubectl apply, you
‫lose the container, you lose everything in it.
‫Obviously, Kubernetes, just like the other orchestrators,
‫have to have a way for persistent data to
‫stick around. It's even more than the volumes themselves.
‫Even the containers and deployments can be different in
‫Kubernetes with something called a StatefulSets.
‫These are resources
‫that are different than deployments.
‫They basically are designed around databases and
‫things that require much more persistence, including the
‫same name, same IPs stuff like that.
‫We didn't get that out-of-the-gate with Swarm or with
‫Docker necessarily.
‫It didn't really have a way for you to keep those different
‫attributes between containers.
‫StatefulSets is a new feature in Kubernetes
‫that has only been out a little bit of time here.
‫It's what you would look at if you're going to consider
‫databases or something that's very sensitive to changes
‫like names, and IP addresses, and volumes, and persistent
‫data. A word of caution here.
‫The reason we're not going to go through a lot of the
‫details of it is because I don't recommend that your
‫first deployment of Kubernetes involves a lot of
‫StatefulSets in it. In fact, ideally, your first deployment
‫of an orchestrator, of any orchestrator, whether it's Swarm
‫or Kubernetes, is only involved with stateless and you
‫know, keep it simple. Maybe just do your web frontends or
‫some APIs, or some worker features, or something
‫that don't involve databases. In fact, if you can use cloud
‫databases, do that.
‫I always recommend outsourcing your databases unless you
‫have specific requirements that you just can't
‫avoid for running yourself. Orchestration, initially,
‫was really designed around containers being immutable, and
‫distributed, and replaceable.
‫This idea of stickiness for statefulness
‫is going to add more work, and complexity, and
‫a lot more testing for you. Ideally, out-of-the-gate, you
‫don't have to worry about this.
‫Later on, once you're much more comfortable with all the
‫other things around Kubernetes, then you can come back and
‫say, now I want to consider my databases.
‫It's not that you shouldn't run databases in clusters.
‫It's just more work. It's harder.
‫Databases and persistent storage is always harder
‫and more details to work with. There's my pro tip.
‫With any container, you can add a volume very
‫similar to how you did in Swarm and in Docker and Docker
‫Compose. You can just add a volume statement in
‫the template inside spec. If you think of the YAML file,
‫we can just put a volume in there like you would expect,
‫and the exact format and details are
‫in the resources. Unlike with Docker and Swarm where
‫the volume is with a container, in this case, it's
‫technically with the pod. It connects to each container, or
‫just one container, in the pod if you tell it to.
‫So, you're controlling it at the container level, but
‫it's persistence is with the pod level. There's a newer
‫feature that is persistent volumes.
‫That works with something else called a claim.
‫The interesting idea with this is
‫that you're using it, or you define it, outside
‫of the pods. You're basically creating that resource on
‫its own, and then you're making a claim against
‫that resource inside of your pod spec.
‫The reason this is more interesting is as Kubernetes
‫takes over the enterprise, you often have people taking
‫care of storage, often third-party storage, that isn't
‫the same team running Kubernetes.
‫They're going to be the ones involved with managing and
‫creating these persistent volumes.
‫Then it's the application deployers that are going
‫to say, hey I need a
‫volume of this type. So, I'm going to make a claim of SSD
‫or we may need RAM storage, or maybe I need
‫NFS, or whatever. That storage
‫will automatically be provided because the storage team
‫already set it up in Kubernetes.
‫That's kind of the idea around persistent volumes.
‫If you just need some simple storage on a single server
‫temporarily for the pod, then just use
‫the standard volumes attribute.
‫One last thing here is on
‫the creation of CSI plugins. In Kubernetes
‫history, anything that was third-party storage, whether
‫it's cloud storage or some third-party vendor storage, or
‫something custom, any of that stuff was added
‫in tree.
‫That means it was added to the binaries
‫of Kubernetes and shipped with Kubernetes.
‫That means Kubernetes came with Amazon and
‫Azure storage built right out-of-the-box.
‫That was pretty convenient, but it added so
‫many challenges.
‫Most of those were related to the fact that storage vendors were now contributing
‫code to the core of your system that you probably didn't
‫even need because you may only use one storage vendor, so
‫why have all of them?
‫Also, the storage vendors then had to control
‫their release cycles around the Kubernetes release cycle,
‫and it wasn't a very flexible model.
‫So, the industry came together, and like it did with
‫networking and with Dockerfiles and images themselves,
‫it created a standard. That standard is the CSI.
‫That stands for Container Storage Interface.
‫That is going to provide plugins now so that
‫any storage vendor can create a plugin that you would
‫install on all the nodes, and that would be different
‫based on the plugin and their instructions.
‫Then, they will operate on a standard API
‫that the CSI provides so that any of your
‫containers can use that plugin to get to their storage.
‫That's a much better, and more flexible, model.
‫That's kind of the future of Kubernetes, but it's still
‫pretty new. So often in examples, and even
‫your storage vendors may recommend, depending on their
‫maturity of CSI, that you use their traditional plugin,
‫which is built into Kubernetes and comes out-of-the-box.