Https Bestdotnettraining - Azureedge.net Documents Kubernetes 8 Configuring and Managing Storage 8 Configuring and Managing Storage
Https Bestdotnettraining - Azureedge.net Documents Kubernetes 8 Configuring and Managing Storage 8 Configuring and Managing Storage
Kubernetes Volumes
In a volatile environment, storage might be seen as a problem. How do you keep data in storage when the
container or pod is transient and nodes can fail?
While nodes represent the compute capacity of a Kubernetes cluster, a persistent volume represents its
storage capacity.
Volume:
A Kubernetes Volume is essentially a directory accessible to all containers running in a pod.
Its deployed as part of the Pod spec.
In contrast to the container-local filesystem, the data in volumes is preserved across container restarts.
The medium backing a volume and its contents are determined by the volume type.
Volume Types:
node-local types such as emptyDir or hostPath
file-sharing types such as nfs
cloud provider-specific types like awsElasticBlockStore, azureDisk, or gcePersistentDisk
distributed file system types, for example glusterfs or cephfs
special-purpose types like secret, gitRepo
hostPath: This type of volume mounts a file or directory from the host node’s filesystem into your pod.
Pods.yaml
apiVersion: v1
kind: Pod
metadata:
name: test-pd
spec:
Page 1 of 14
Develop Intelligence Kubernetes Kubernetes Objects
volumes:
- name: test-volume
hostPath:
# directory location on host
path: /usr/demo
type: Directory
containers:
- image: nginx
name: test-container
command: ["cat", "/test-pd/demo.txt"]
volumeMounts:
- mountPath: /test-pd
name: test-volume
Execute the commands in following order
1. D:\> docker run -it --rm -v /:/hostroot ubuntu bash (To Enter the Shell of Host Linux VM used by
Docker)
2. root@7b975680d414:/hostroot# ls -l > demo.txt - This creates a file demo.txt in root of the Linux
host VM.
3. root@7b975680d414:/hostroot# ls -l > exit
4. D:\> kubectl apply -f pods.yaml
5. D:\> kubectl get all
6. D:\> get logs pod/test-pd
emptyDir: An emptyDir volume is first created when a Pod is assigned to a Node, and exists as long as that Pod
is running on that node. As the name says, it is initially empty. Containers in the Pod can all read and write the
same files in the emptyDir volume, though that volume can be mounted at the same or different paths in each
Container. When a Pod is removed from a node for any reason, the data in the emptyDir is deleted forever.
Note: A Container crashing does NOT remove a Pod from a node, so the data in an emptyDir volume is safe
across Container crashes.
apiVersion: v1
kind: Pod
metadata:
name: sharevol
spec:
containers:
- name: c1
image: ubuntu
command:
Page 2 of 14
Develop Intelligence Kubernetes Kubernetes Objects
- "bin/bash"
- "-c"
- "sleep 10000"
volumeMounts:
- name: xchange
mountPath: "/tmp/data1"
- name: c2
image: ubuntu
command:
- "bin/bash"
- "-c"
- "sleep 10000"
volumeMounts:
- name: xchange
mountPath: "/tmp/data2"
volumes:
- name: xchange
emptyDir: {}
Step1: Create Pod with two containers using the above YAML
1. D:\Kubernetes>kubectl apply -f pods.yaml
Step2: We first exec into one of the containers in the pod, c1, check the volume mount and generate some
data:
2. D:\Kubernetes> kubectl exec -it p1 -c c1 -- bash
3. root@p1:/# cd /tmp/data
4. root@p1:/tmp/data# echo "this is demo" > demo.txt
5. root@p1:/tmp/data# exit
6. exit
Step3: When we now exec into c2, the second container running in the pod, we can see the volume mounted
at /tmp/data and are able to read the data created in the previous step:
7. D:\Kubernetes> kubectl exec -it p1 -c c2 -- bash
8. root@p1:/# cd /tmp/data
9. root@p1:/tmp/data# ls
10. demo.txt
11. root@p1:/tmp/data#
Page 3 of 14
Develop Intelligence Kubernetes Kubernetes Objects
Page 4 of 14
Develop Intelligence Kubernetes Kubernetes Objects
address.country=India
---
apiVersion: v1
kind: Pod
metadata:
name: test-pod
spec:
containers:
- name: test-container
image: nginx
command: [ "cat", "/etc/config/mysettings.properties" ]
volumeMounts:
- name: config-vol
mountPath: "/etc/config"
readOnly: true
volumes:
- name: config-vol
configMap:
name: mysettings-config
Execute the following commands and note that the file is created by name mysettings.properties.
kubectl apply -f d:\Demos\Kubernetes\configmap1.yaml
kubectl exec -it pod/test-pod -- bash
# cat /etc/config/mysettings.properties
Page 5 of 14
Develop Intelligence Kubernetes Kubernetes Objects
spec:
containers:
- name: test-container
image: nginx
volumeMounts:
- name: config-vol
mountPath: "/etc/config"
volumes:
- name: config-vol
configMap:
name: mysettings-config3
Execute the following commands and note that the file is created by name location and name.
kubectl apply -f ConfigMap2.yaml
kubectl exec -it pod/test-pod – bash
# cd /etc/config
# cat name
# cat location
Page 6 of 14
Develop Intelligence Kubernetes Kubernetes Objects
A Persistent Volume Claim describes the amount and characteristics of the storage (Size, Access Mode
and optionally Storage) required by the pod, finds any matching persistent volumes and claims these.
The cluster will map the PVC to a PV.
Storage classes:
Storage classes give you the flexibility to choose multiple volume options for a Kubernetes cluster. You can
use multiple storage solutions from various vendors, including Azure, Amazon Web Service, and Google
Cloud Platform.
Containers request storage from a cluster via a volume claim, which is a declarative claim for a specific
type of volume access mode, capacity, and so on. The Kubernetes cluster evaluates this claim request, and
then assigns a volume from its storage class.
Storage class enables Dynamic Provisioning of Persistent Volume.
Use Case:
The most common use case for Persistent volumes in Kubernetes is for databases. Obviously a database needs
to have access to its data at all times, and by leveraging PVs, we can start using databases like MySQL,
Cassandra, CockroachDB and even MS SQL for our applications.
Page 7 of 14
Develop Intelligence Kubernetes Kubernetes Objects
labels:
type: local
spec:
storageClassName: manual #This is Optional
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
hostPath:
path: "/mnt1/data"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: mysql-pv-claim
spec:
storageClassName: manual
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 10Gi
Note: A claim can request a particular class by specifying the name of a StorageClass using the
attribute storageClassName. Only PVs of the requested class, ones with the same storageClassName as the
PVC, can be bound to the PVC.
Page 8 of 14
Develop Intelligence Kubernetes Kubernetes Objects
selector:
matchLabels:
app: "mysql-pod"
serviceName: "mysql"
template:
metadata:
labels:
app: "mysql-pod"
spec:
volumes:
- name: mysql-persistent-storage
persistentVolumeClaim:
claimName: mysql-pv-claim
containers:
- image: mysql:5.6
name: mysql
env:
- name: MYSQL_ROOT_PASSWORD
value: tiger1234
ports:
- containerPort: 3306
name: mysql
volumeMounts:
- name: mysql-persistent-storage
mountPath: /var/lib/mysql
---
apiVersion: v1
kind: Service
metadata:
name: mysql-srv
spec:
ports:
- port: 3306
selector:
app: "mysql"
Page 9 of 14
Develop Intelligence Kubernetes Kubernetes Objects
Note:
mysql -uroot -ptiger1234
mysql - command
-h is host(mysql-srv)
mysql-srv is service name
-u is user (root)
-p is password (tiger1234)
Create a PersistentVolumeClaim
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-azure-standard-ssd
spec:
accessModes:
- ReadWriteOnce
Page 10 of 14
Develop Intelligence Kubernetes Kubernetes Objects
storageClassName: managed-standard-ssd
resources:
requests:
storage: 10Gi
Create Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-azdisk-deployment-standard-ssd
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
volumeMounts:
- name: webcontent
mountPath: "/usr/share/nginx/html/web-app"
volumes:
- name: webcontent
persistentVolumeClaim:
claimName: pvc-azure-standard-ssd
DaemonSet
A DaemonSet ensures that all (or some) Nodes run a copy of a Pod. As nodes are added to the cluster, Pods are
added to them. As nodes are removed from the cluster, those Pods are garbage collected. Deleting a
DaemonSet will clean up the Pods it created.
Some typical uses of a DaemonSet are:
Page 11 of 14
Develop Intelligence Kubernetes Kubernetes Objects
This is how the master pods on the worker nodes run, such as kube-proxy and kubelet.
Jobs
https://app.pluralsight.com/course-player?clipId=d8c381c7-6d12-4589-8431-36d205ba97cf
A Job creates one or more Pods and will continue to retry execution of the Pods until a specified number
of them successfully terminate.
As pods successfully complete, the Job tracks the successful completions. When a specified number of
successful completions is reached, the task (ie, Job) is complete.
Deleting a Job will clean up the Pods it created.
A simple case is to create one Job object in order to reliably run one Pod to completion. The Job object will
start a new Pod if the first Pod fails or is deleted (for example due to a node hardware failure or a node
reboot).
You can also use a Job to run multiple Pods in parallel
Program.cs
using System;
namespace Kubernetes
{
class Program
{
static void Main(string[] args)
{
Random _random = new Random();
int num = _random.Next(0, 10);
Console.WriteLine("Random Number: " + num);
for(int i=0;i<num;i++)
{
if (i == 5)
Page 12 of 14
Develop Intelligence Kubernetes Kubernetes Objects
{
throw new Exception("Reached 5");
}
Console.WriteLine("Number: " + i);
}
Console.WriteLine("Normal Exit");
}
}
}
dockerfile:
FROM mcr.microsoft.com/dotnet/core/sdk:3.1
WORKDIR /app
# copy and build everything
COPY . .
RUN dotnet publish -c Release -o /out
WORKDIR /out
ENTRYPOINT ["dotnet", "Kubernetes.dll"]
Job.yaml
apiVersion: batch/v1
kind: Job
metadata:
name: counter
spec:
template:
spec:
containers:
- name: counter-con
image: sandeep/counter:latest
imagePullPolicy: Never
restartPolicy: OnFailure
backoffLimit: 4
Page 13 of 14
Develop Intelligence Kubernetes Kubernetes Objects
kind: CronJob
metadata:
name: hello
spec:
schedule: "*/1 * * * *"
jobTemplate:
spec:
template:
spec:
containers:
- name: hello
image: busybox
args:
- /bin/sh
- -c
- date; echo Hello from the Kubernetes cluster
restartPolicy: OnFailure
Page 14 of 14