Jump right into Kubernetes development with career-focused lessons and hands-on practice.

DevOps for Developers

Kubernetes is a powerful container management tool that's taking the world by storm. This detailed course will help you master it.

In this course, you'll start with the fundamentals of Kubernetes and what the main components of a cluster look like. You'll then learn how to use those components to build, test, deploy, and upgrade applications, as well as how to achieve state persistence once your application is deployed. You'll also learn how to secure your deployments and manage resources, which are crucial DevOps skills.

By the time you're done, you'll have a firm grasp on what Kubernetes is, as well as the skills to deploy your own clusters and applications with confidence.

A Practical Guide to Kubernetes

Even though kops created two StorageClasses, both are based on `gp2`. While that is the most commonly used EBS type, we might want to create volumes based on one of the other three options offered by AWS.

# User-defined storage classes
Let’s say that we want the fastest EBS volume type for our Jenkins. That would be `io1`. Since kOps did not create a StorageClass of that type, we might want to create our own.
## Looking into the definition
YAML file that creates StorageClass based on EBS `io1` is defined in `pv/sc.yml`. Let's take a quick look.

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: fast
  labels:
    type: ebs
provisioner: kubernetes.io/aws-ebs
parameters:
  type: type: io1 # https://aws.amazon.com/ebs/details/ > Amazon EBS Volume Types
reclaimPolicy: Delete

We use `kubernetes.io/aws-ebs` as the `provisioner`. It is a mandatory field that determines the plugin that will be used for provisioning PersistentVolumes. Since we are running the cluster in AWS, `aws-ebs` is the logical choice. 
### List of supported provisioners
There are quite a few other provisioners we could choose. Some of them are specific to a hosting provider (e.g., `GCEPersistentDisk` and `AzureDisk`) while others can be used anywhere (e.g., `GlusterFS`).

The list of supported provisioners is growing. At the time of writing, the following types are supported:

|Volume Plugin       |Internal Provisioner|
|--------------------|--------------------|
|AWSElasticBlockStore|Yes                 |
|AzureFile           |Yes                 |
|AzureDisk           |yes                 |
|CephFS              |No                  |
|Cinder              |Yes                 |
|FC                  |No                  |
|FlexVolume          |No                  |
|Flocker             |Yes                 |
|GCEPersistentDisk   |Yes                 |
|Glusterfs           |Yes                 |
|iSCSI               |No                  |
|PhotonPersistentDisk|Yes                 |
|Quobyte             |Yes                 |
|NFS                 |No                  |
|RBD                 |Yes                 |
|VsphereVolume       |Yes                 |
|PortworxVolume      |Yes                 |
|ScaleIO             |Yes                 |
|StorageOS           |Yes                 |
|Local               |No                  |

The internal provisioners are those with names prefixed with `kubernetes.io` (e.g., `kubernetes.io/aws-ebs`). They are shipped with Kubernetes. 

On the other hand, external provisioners are independent programs shipped separately from Kubernetes. An example of a commonly used external provisioner is `NFS`.

The parameters depend on the StorageClass. We have used the `aws-ebs` provisioner which allows us to specify the `type` parameter that defines one of the supported Amazon EBS volume types. It can be:
1. EBS Provisioned IOPS SSD (`io1`)
2. EBS General Purpose SSD (`gp2`)
3. Throughput Optimized HDD (`st1`)
4. Cold HDD (`sc1`)

 We set it to `io1` which is the highest performance SSD volume.

> Note: Please consult the [Parameters](https://kubernetes.io/docs/concepts/storage/storage-classes/#parameters) section of the Storage Classes documentation for more information.
### The `Delete` type reclaim policy
Finally, we set the `reclaimPolicy` to `Delete`. Unlike `Retain` that forces us to delete the contents of the released volume before it becomes available to new PersistentVolumeClaims, `Delete` removes both the PersistentVolume and the associated volume in the external architecture. The `Delete` reclaim policy works only with some of the external volumes like AWS EBS, Azure Disk, or Cinder volume.


---
Now that we have understood the StorageClass definition, in the next lesson, we can proceed and create it.

Learn how to  define our own StorageClass.

Defining Storage Classes