Kubernetes Basics - Continued

Storage, Secrets, and Services

Before we get into Storage, Secrets, and Services, it’d be best to explain what kubernetes objects are. I’m not going to reinvent the wheel here, so here’s a small excerp from the kubernetes documentation

Kubernetes objects are persistent entities in the Kubernetes system. Kubernetes uses these entities to represent the state of your cluster. Specifically, they can describe:

    What containerized applications are running (and on which nodes)
    The resources available to those applications
    The policies around how those applications behave, such as restart policies, upgrades, and fault-tolerance

A Kubernetes object is a "record of intent"--once you create the object, the Kubernetes system will constantly work to ensure that object exists. 
By creating an object, you're effectively telling the Kubernetes system what you want your cluster's workload to look like; this is your cluster's desired state.

Storage

with that out of the way, lets get started with some storage! again, I want reiterate that this is a high level overview of kubernetes, and will not have the complete details, but it’s enough to get you started.

In this series, the things we will build in our cluster, we only have to worry about Persistent Volumes(PV), Persistent Volume Claims(PVC), and storage classes. My cluster is hosted locally on a couple of Raspberry Pi’s and a NUC, but you’re cluster may be hosted in the cloud. I’ll go a bit over that aspect as well, though not as much in detail.

What are Storage Classes

Storage classes are pretty cool when you’re working in AWS, Azure, Google Cloud, etc. It really brings the automation to container orchestration. Storage Classes create persistent volumes dynamically in the background.

The way storage classes work is you first state your specifications for the different Persistent Volume’s you’ll need, and then when you require storage for a new application, you state the storage class you need(basically what specifications; iops, filesystem type, etc) inside a Persistent Volume Claim. This is pretty neat, as you don’t need to go and manually provision a Persistent Volume, and this will be done automatically when your Persistent Volume Claim requests the Persistent Volume.

I also want to state that if you have a local datacenter using vSphere, you can also use Storage Classes to dynamically provision Persistent Volumes using the vCP provisioner

To learn more about Storage Classes, I recommend the official Kubernetes documentation located here: https://kubernetes.io/docs/concepts/storage/storage-classes/#introduction

What are Persistent Volumes

A Persistent Volume (PV) is essentially where the data for your Pod will live. It can either be a shared network drive (like how I have mine set up) or it could be dynamically provisioned using Storage classes.

To note, when you’re using NFS, I’d recommend creating a directory in your drive for each namespace and application. If you really wanna go full on automation with NFS PV provisioning, the official Kubernetes documentation recommend the following two external NFS provisioners (I’ve haven’t used these yet my self)

• NFS Ganesha server and external provisioner
• NFS subdir external provisioner

When it comes to Persistent Volumes in the cloud, I’d recommend saving your self the headache, and create the storage classes you think you’ll need and reference them in the PVC.

For more reading on Persistent Volumes, you should check out the official Kubernetes documentation at https://kubernetes.io/docs/concepts/storage/persistent-volumes/#introduction

What are Persistent Volume Claims

It’s sort of in the name. A Persistent Volume Claim (PVC) CLAIMS a specific persistent volume. In other words, it binds a Pod to a Persistent Volume. With this, no other Pod or application can write or read to the PV, unless your application was set up as a Deployment instead of a statefulset, then in this case, multiple pods of a replicaset can read/write to the PV, depending on the access mode.

In a PVC, you describe the type of storage you require for your Pod. These can include, Storage Class Name, Access modes, storage capacity, and many more.

For more reading on Persistent Volume Claims, again, I’d recommend checking out the Official Kubernetes documentation: https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims

What are Secrets

Secrets are secure objects in kubernetes utilized for holding sensitive data. Some examples of data you’d want to store in Secrets are passwords, keys, or tokens.

Kubernetes Secrets are secure in that they are created independently of the pods that use them, and do not need to be included in the application code. A good example of where to use Kubernetes Secrets are authenticating against your database pods.

for instance, in my Kubernetes Cluster, I have deployed Commento to get user feedback and comments. Commento utilizes a user facing frontend and a postgres database backend. The frontend Commento Pod needs to connect and communicate with the Postgres database backend utilizing a username, a password, and the url to the database. I could write this information in the pod specification, but this would expose the sensitive information as plaintext. So I’ve utilized Kubernetes Secrets to hold that information and then referenced the Secrets utilizing the Secret name in the Pod specification for commento.

What is a Kubernetes Service

A Kubernetes Service is a resource used to expose an application as a network service. There are four types of Kubernetes Services

1. ClusterIP: When an application is exposed via ClusterIP, just as the name implies, the application will be provided an IP internal the Kubernetes Cluster. The application will not be accessible outside the cluster.
2. NodePort: When exposed via NodePort, a port is opened on every single node in your cluster. Kubernetes routes incoming traffic on the open port to your application regardless of the fact if your application is running on another node.
3. Loadbalancer: When exposed with the type loadbalancer, your service is provisioned an external IP Address to which applications outside the cluster may connect to, as well as act as a loadbalancer for your application’s set of pods. When used in cloud services such as AWS, the cloud provider creates a loadbalancer which will route traffic to the application This can also be done on-premise utilizing loadbalancers such as metallb or PureLB.
4. ExternalName: This type of service does not utilize selectors. In other words, this is utilized for services that live outside of your Kubernetes cluster. when you define the service, you must define the service name and an external name. The external name acts as a CNAME DNS Record. When applications try to interact with this service, the traffic is routed to the service external to the cluster, where the routing occurs at the DNS level.