Kubernetes on Cloud
- Lets Provision AKS (Azure Kubernetes Service) & EKS (Elastic Kubernetes Services)
- K8s is one physical cluster with k8s master and cluster nodes & in this cluster if you want to create multiple virtual clusters (like one for dev, staging, qa..) we can use namespaces.
- Execute kubectl api-resources. The resource with value namespaced
- true => will be created per namespace
- false => will be same/shared across namespaces
- Generally kubectl command will pull the values from namespace default. If you want k8s to fetch the information from other namespaces use –namespace flag
- Upgrading to published versions is easier in the cloud.
- In AKS, we can upgrade the nodepools and k8s seperately
- In the case of eksctl
Storage in K8s
- Both containers & Pods are ephemeral (when we delete the Pods/Containers data generated is deleted)
- Docker Volume seperates storage from lifecycle of Container, So even if container is deleted, data will still be available.
- Since Docker containers are created in the Pod, and problem of storage has to be solved at Pod level in k8s as Pod provides kernel namespace to docker container.
- Pod has a container. The container in the pod stores the data and lets assume it is crashes, Pod will try to restart the container and in this case data will be lost. The new container will start with empty disk space allocated.
- We cannot rely on containers themselves even for temporary storage of data.
- K8s Volume abstraction solves the problem
- Volume is exposed to the applications which eventually store data on any type of storage (node/cloud).
- Lifetime of k8s volume is same as the Pod’s lifetime. As long as Pod is alive the containers within will get the same volume across restarts or new container Creation.
- How to use K8s Volume
- Volumes such as emptyDir and hostPath get delete when the pod using them is deleted or pod is restarted. So we need to find a solution Where the data/storage lifetime is different than Pod’s lifetime
- To Solve this Problem, K8s has Persistent Storage in the form of Persistent Volume (PV).
Persistent Volumes & Persistent Volume Claims
- A PV is a K8s object that represents block of storage in the cluster. This can be provisioned before hand by cluster admins or be dynamically provisioned.
- In Order to use PV, a Persistent Volume Claim (PVC) needs to be created. A PVC is request for storage by user or by Pod. This request can be of specific size or specific access mode.
- Each PV belongs to certain storage class. A Storage Class is a K8s Object that provides a way for administrators to describe different types of Storage.
- Volume mode has two Values Block, FileSystem
- Access Modes:
- ReadWriteOnce (RWO): Mounted as read-write by a single node
- ReadOnlyMany (ROX): Mounted as read-only by many nodes
- ReadWriteMany (RWX): Mounted as Read-write by many nodes
- persistentVolume Reclaim Policy
- PVC in Azure
- Storage Classes in Azure
- Storage Class in AWS
- Lets understand how to use mysql container in a Pod with Persistent Volume (in AWS and Azure)
- Refer Here to mysql Dockerfile which has volume at /var/lib/mysql
- Lets use existing storage classes in Azure to create mysql-pod Refer Here
- In AWS,for the manifest Refer Here