What is difference between deployment and Statefulset
Deployment:
A deployment is used to manage the deployment and scaling of a set of replicas of a stateless application. A stateless application is one that does not maintain any form of state and can run in any instance or replica. A deployment creates a set of pods (which are the smallest deployable units in Kubernetes) and manages their lifecycle. Deployments are useful when you want to update your application with new code, scale up or down, and maintain a consistent state.
When you create a deployment in AKS, you specify the desired number of replicas, the Docker image to use, and the resources (CPU and memory) required by each pod. AKS creates a set of identical pods, monitors their health, and automatically replaces failed or unresponsive pods with new ones. Deployments also support rolling updates, which allows you to update your application with zero downtime. Rolling updates take place by gradually replacing old pods with new ones.
StatefulSet:
A StatefulSet, on the other hand, is used to manage the deployment and scaling of a set of replicas of a stateful application. A stateful application is one that requires some form of persistent storage, such as a database, and each instance or replica of the application needs to have a unique identity.
When you create a StatefulSet in AKS, you specify the number of replicas, the Docker image to use, the storage requirements, and the unique identity of each replica. AKS creates a set of identical pods with unique identities and persistent storage.
When a pod is created, it gets a unique hostname and identity that can be used to access its storage. StatefulSets ensure that pods are created in a specific order, and they are terminated in reverse order. This ensures that the stateful application is started and stopped correctly and avoids data loss.
StatefulSets are useful when you have stateful applications that require unique identities and persistent storage. Examples include databases, messaging systems, and file servers. StatefulSets make it easy to scale up or down your stateful applications, and they support rolling updates to update your application with zero downtime.
Example of installing mongodb with statefulset using static storage account
# Set variables
namespace=mongodb
statefulsetname=mongodb-statefulset
storagename=mongodb-storage
storageclass=azure-disk
replicas=1
mongodbusername=admina
mongodbpassword=Password@123
cat <<EOF | kubectl apply -f -
# Create a Namespace mongodb-namespace
apiVersion: v1
kind: Namespace
metadata:
name: $namespace
EOF
cat <<EOF | kubectl apply -f -
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: $storageclass
namespace: $namespace
provisioner: kubernetes.io/azure-disk
parameters:
storageaccounttype: Standard_LRS
kind: Managed
EOF
# Create MongoDB StatefulSet
cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: $statefulsetname
namespace: $namespace
spec:
serviceName: $statefulsetname
replicas: $replicas
selector:
matchLabels:
app: mongodb
template:
metadata:
labels:
app: mongodb
spec:
containers:
- name: mongodb
image: mongo:latest
env:
- name: MONGO_INITDB_ROOT_USERNAME
value: $mongodbusername
- name: MONGO_INITDB_ROOT_PASSWORD
value: $mongodbpassword
ports:
- containerPort: 27017
volumeMounts:
- name: $storagename
mountPath: /data/db
volumeClaimTemplates:
- metadata:
name: $storagename
spec:
storageClassName: $storageclass
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
EOF
# Create MongoDB StatefulSet explanation
This is a Kubernetes YAML file that creates a StatefulSet to run MongoDB in a Kubernetes cluster. A StatefulSet is a Kubernetes object that provides guarantees about the ordering and uniqueness of pods in a Kubernetes cluster. MongoDB is a popular NoSQL database management system.
The YAML file specifies the following attributes for the StatefulSet:
Name: The name of the StatefulSet, which is provided as a parameter to the script.
Namespace: The namespace where the StatefulSet will be created, which is also provided as a parameter.
Service name: The name of the service associated with the StatefulSet, which is the same as the StatefulSet name.
Replicas: The number of replicas of MongoDB that will be created in the StatefulSet, which is also provided as a parameter.
Selector: The labels used to identify the MongoDB pods managed by the StatefulSet.
Template: The pod template used to create MongoDB pods in the StatefulSet. It contains the following:
Labels: Used to identify the pods created by the StatefulSet.
Containers: The container specification for MongoDB, which includes the following:
Name: The name of the container.
Image: The MongoDB Docker image to use.
Env: The environment variables to set in the container, which includes the MongoDB root username and password.
Ports: The port used by MongoDB.
VolumeMounts: The storage volume to mount to store MongoDB data.
VolumeClaimTemplates: The storage volume template used to create persistent volumes for MongoDB data. It contains the following:
Metadata: The name of the volume to be created.
Spec: The specification of the storage volume, which includes the storage class, access modes, and storage requests.
Overall, this YAML file creates a scalable and persistent MongoDB deployment in a Kubernetes cluster, with authentication enabled using a root username and password, and 5GB of storage allocated for each MongoDB pod.
# Create MongoDB Headless service
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Service
metadata:
name: $statefulsetname
namespace: $namespace
labels:
name: mongo
spec:
ports:
- port: 27017
targetPort: 27017
clusterIP: None
selector:
app: mongodb
EOF
Q:- why we create a headless service
Ans:-why we create a headless service in statefulsets
In a StatefulSet, each pod has a unique and stable hostname that is based on the StatefulSet name and the ordinal index of the pod. For example, a StatefulSet with a name of "mongodb" and replicas set to 3 would create pods with hostnames "mongodb-0", "mongodb-1", and "mongodb-2". This allows applications running inside the pod to use the hostname to connect to other pods in the StatefulSet, rather than relying on IP addresses that may change if pods are added or removed.
By default, Kubernetes creates a cluster IP service for a StatefulSet, which forwards traffic to the pods using their stable hostnames. However, in some cases, it may be useful to have direct access to each pod's hostname, without going through the service. This is where headless services come in.
A headless service is a Kubernetes service that is created with the "clusterIP: None" option. This means that the service does not have a virtual IP address, and instead returns the DNS name of each pod that matches the service selector. In the case of a StatefulSet, a headless service returns the stable hostnames of each pod in the StatefulSet, allowing applications to connect directly to each pod.
There are several reasons why a headless service may be useful in a StatefulSet:
Load balancing: A headless service allows applications to connect directly to each pod, which can be useful for load balancing or distributing workloads across multiple pods.
Stateful application requirements: Some stateful applications require direct access to each pod's hostname in order to function properly.
Database sharding: In databases that support sharding, a headless service can be used to shard data across multiple pods based on their stable hostnames.
Overall, a headless service in a StatefulSet allows for more direct and fine-grained control over how applications connect to pods, and can be useful in a variety of scenarios.
Q:- what if i set replicaset to 3, will this static storageClass support replicaset to 3. if not how can we change replicaset to 3.
ANS:--- ???
No comments:
Post a Comment