Kubernetes Storage
Kubernetes is a popular container orchestration system that is widely used for deploying and managing containerized applications. One of the key features of Kubernetes is its storage system, which enables developers to store data persistently even after a container is deleted. In this blog post, we will discuss Kubernetes storage and the different components that make up its storage system.
Persistent Volumes (PV)
A Persistent Volume (PV) is a piece of storage in the cluster that has been provisioned by an administrator or dynamically created by a StorageClass. PVs are used to provide persistent storage to applications running in containers. A PV is created by an administrator and is available to all pods in the cluster. The storage backing a PV can be a physical disk, a network file system, or a cloud storage provider.
Creating a Persistent Volume
To create a Persistent Volume in Kubernetes, we need to define a YAML file with the necessary details, such as the storage type, capacity, access mode, and the location of the storage. Here's an example of a YAML file that creates a PV that uses a network file system:
apiVersion: v1
kind: PersistentVolume
metadata:
name: nfs-pv
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
nfs:
server: nfs.example.com
path: /data
In this example, we create a PV with a capacity of 10 GB and an access mode of ReadWriteOnce, which means it can be mounted as read-write by a single node. We use a network file system (NFS) as the storage backing for the PV. The NFS server is defined as nfs.example.com, and the path to the shared directory is /data.
Persistent Volume Claims (PVC)
A Persistent Volume Claim (PVC) is a request for storage by a user or a pod. PVCs are used to request a specific type of storage resource, with specific access modes and capacity requirements. When a PVC is created, Kubernetes finds a matching PV, which is then bound to the PVC. If a matching PV is not found, a new one is dynamically created according to the specifications of the PVC.
Creating a Persistent Volume Claim
To create a PVC in Kubernetes, we need to define a YAML file with the necessary details, such as the storage class, access mode, and the required capacity. Here's an example of a YAML file that creates a PVC:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: nfs-claim
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
storageClassName: slow
In this example, we create a PVC with an access mode of ReadWriteOnce and a capacity requirement of 5 GB. We also specify the storage class as "slow," which tells Kubernetes to use the slow storage class for provisioning the PV.
Storage Classes
A StorageClass is a way of abstracting away the underlying storage details, allowing developers to request storage in a way that is independent of the storage provider. StorageClasses enable dynamic provisioning of Persistent Volumes. They define the parameters that describe the type of storage needed, such as access mode, provisioner, and reclaim policy. The provisioner is responsible for creating a Persistent Volume when a matching PVC is created.
Creating a StorageClass
To create a StorageClass in Kubernetes, we need to define a YAML file with the necessary details, such as the provisioner, reclaim policy, and the storage type. Here's an example of a YAML file that creates a StorageClass:
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: slow
provisioner: kubernetes.io/no-provisioner
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer
In this example, we create a StorageClass named "slow" with a provisioner of "kubernetes.io/no-provisioner", which means that we won't be using any specific storage provider. The reclaimPolicy is set to "Retain," which means that the PVs created by this StorageClass will not be automatically deleted when the PVC is deleted. Finally, the volumeBindingMode is set to "WaitForFirstConsumer," which means that the PV will be bound to the PVC as soon as a pod requests it.
StatefulSets
A StatefulSet is a Kubernetes API object used to manage stateful applications. It is designed to manage stateful applications that require stable network identities and persistent storage. StatefulSets provide guarantees about the ordering and uniqueness of pods in the set, allowing for applications that rely on ordered, consistent naming or network identity to function correctly. StatefulSets are commonly used for databases and other stateful applications.
Creating a StatefulSet
To create a StatefulSet in Kubernetes, we need to define a YAML file with the necessary details, such as the name of the StatefulSet, the number of replicas, and the container image. Here's an example of a YAML file that creates a StatefulSet:
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: mysql
spec:
serviceName: mysql
replicas: 3
selector:
matchLabels:
app: mysql
template:
metadata:
labels:
app: mysql
spec:
containers:
- name: mysql
image: mysql:5.7
volumeMounts:
- name: mysql-persistent-storage
mountPath: /var/lib/mysql
volumeClaimTemplates:
- metadata:
name: mysql-persistent-storage
spec:
accessModes: [ "ReadWriteOnce" ]
resources:
requests:
storage: 10Gi
In this example, we create a StatefulSet named "mysql" with three replicas. The container image used is mysql:5.7. We also define a PVC template that will be used to create a Persistent Volume for each replica. The PVC template requests 10 GB of storage with an access mode of ReadWriteOnce. The PVC is mounted as a volume inside the container at /var/lib/mysql.
Kubernetes Security
Security is a critical aspect of any production deployment. Kubernetes provides several security mechanisms that can help secure your cluster and the applications running in it. In this section, we will discuss some of the key Kubernetes security features.
RBAC (Role-Based Access Control)
Role-Based Access Control (RBAC) is a Kubernetes feature that enables administrators to define granular access control policies for users, groups, and service accounts. RBAC is used to control who can perform specific actions on Kubernetes resources, such as creating or deleting pods, services, or nodes. RBAC policies can be defined using Roles, ClusterRoles, RoleBindings, and ClusterRoleBindings.
Creating an RBAC Policy
To create an RBAC policy in Kubernetes, we need to define a YAML file with the necessary details, such as the policy name, the type of resource being controlled, and the roles and subjects involved. Here's an example of a YAML file that creates an RBAC policy:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: default
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "watch", "list"]
In this example, we create an RBAC policy named "pod-reader" in the "default" namespace. The policy allows users to perform "get", "watch", and "list" actions on "pods" resources.
Pod Security Policies
Pod Security Policies (PSPs) are a Kubernetes feature that allows administrators to control the security characteristics of pods running on the cluster. PSPs enable administrators to enforce security policies on pods, such as limiting the use of privileged containers or enforcing specific Linux capabilities. PSPs can be defined using YAML files and can be applied to specific namespaces or to the entire cluster.
Creating a Pod Security Policy
To create a Pod Security Policy in Kubernetes, we need to define a YAML file with the necessary details, such as the allowed security contexts, volumes, and privileged access. Here's an example of a YAML file that creates a Pod Security Policy:
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
name: restricted
spec:
privileged: false
seLinux:
rule: RunAsAny
runAsUser:
rule: MustRunAsNonRoot
fsGroup:
rule: MustRunAs
ranges:
- min: 1
max: 65535
volumes:
- secret
- configMap
In this example, we create a Pod Security Policy named "restricted". The policy disallows privileged access, requires that the pod run as a non-root user, and allows access to specific volumes, such as secrets and config maps.
Secrets
Secrets are Kubernetes objects used to store sensitive information, such as passwords, API keys, or TLS certificates. Secrets are stored in an encrypted format, and only authorized users and pods can access them. Secrets can be used by applications running in Kubernetes to retrieve sensitive information securely.
Creating a Secret
To create a Secret in Kubernetes, we need to define a YAML file with the necessary details, such as the type of secret and the data to be stored. Here's an example of a YAML file that creates a Secret:
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
username: xxxxxxxxxxx
password: xxxxxxxxxxx
In this example, we create a Secret named "mysecret" with a type of "Opaque," which means that the secret is an arbitrary byte array. We store two pieces of data: a username and a password. The data is encoded in base64 format to ensure that it is stored securely.
Network Policies
Network Policies are a Kubernetes feature that allows administrators to enforce security policies on the network level, such as allowing or denying traffic to specific pods based on their labels or network ports. Network Policies can be defined using YAML files and can be applied to specific namespaces or to the entire cluster.
Creating a Network Policy
To create a Network Policy in Kubernetes, we need to define a YAML file with the necessary details, such as the policy name, the pod selector, and the allowed ingress and egress rules. Here's an example of a YAML file that creates a Network Policy:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: mynetworkpolicy
spec:
podSelector:
matchLabels:
app: myapp
policyTypes:
- Ingress
ingress:
- from:
- podSelector:
matchLabels:
app: mydatabase
ports:
- protocol: TCP
port: 5432
In this example, we create a Network Policy named "mynetworkpolicy". The policy applies to pods with the label "app: myapp". The policy allows ingress traffic from pods with the label "app: mydatabase" on port 5432 using TCP protocol.
TLS (Transport Layer Security)
Transport Layer Security (TLS) is a cryptographic protocol used to secure communication between applications running on the cluster. Kubernetes supports TLS for secure communication between the API server, kubelet, and etcd. TLS certificates can be issued by a certificate authority (CA) or self-signed. Kubernetes supports certificate rotation to ensure the security of the cluster.
Creating a TLS Certificate
To create a TLS certificate in Kubernetes, we need to define a YAML file with the necessary details, such as the common name and the validity period. Here's an example of a YAML file that creates a TLS certificate:
apiVersion: cert-manager.io/v1alpha2
kind: Certificate
metadata:
name: mytls
spec:
commonName: mytls.example.com
dnsNames:
- mytls.example.com
secretName: mytls-secret
issuerRef:
name: myissuer
kind: ClusterIssuer
duration: 365d
In this example, we create a TLS certificate named "mytls". The certificate has a common name of "mytls.example.com" and a validity period of 365 days. The certificate is issued by a ClusterIssuer named "myissuer". The TLS certificate is stored in a Kubernetes Secret named "mytls-secret".
Conclusion
Kubernetes provides a robust and scalable platform for deploying and managing containerized applications. Its storage system and security features play a crucial role in ensuring the reliability and security of applications running on the cluster. Persistent Volumes, Persistent Volume Claims, Storage Classes, and StatefulSets enable developers to manage and scale storage requirements for stateful applications, while RBAC, Pod Security Policies, Secrets, Network Policies, and TLS provide granular control over access, authentication, and encryption. By leveraging these features, organizations can build and run secure and highly available applications on Kubernetes with confidence.
Thank you for reading this Blog. Hope you learned something new today! If you found this blog helpful, please like, share, and follow me for more blog posts like this in the future.
If you have some suggestions I am happy to learn with you.
I would love to connect with you on LinkedIn
Meet you in the next blog....till then Stay Safe ➕ Stay Healthy
#HappyLearning #Kubernetes #K8s #Containerization #ContainerOrchestration #Storage #PersistentVolumes #StatefulSets #Security #RBAC #PodSecurityPolicies #Secrets #NetworkPolicies #TLS #CloudNative #Microservices #HybridCloud #MultiCloud #ITInfrastructure #CloudComputing #devops #Kubeweek #KubeWeekChallenge #TrainWithShubham #KubeWeek_Challenge #kubeweek_day5