Kubernetes Objects are the basic building blocks of any Kubernetes application deployment. They are API resources that represent the state of your cluster. There are several built-in Kubernetes objects, some of which are:
Pods: They are the smallest and the simplest Kubernetes Objects that represent a single instance of a running process within the cluster.
Services: They provide a stable IP or DNS name to a set of pods, enabling you to access them easily.
Deployments: They allow you to define and manage a set of identical pods, ensuring that the desired number of replicas are always running.
ConfigMaps: They provide a way to decouple configuration from container images, enabling your applications to be more portable.
Secrets: They provide a secure way to store and manage sensitive information such as database passwords, API keys, or TLS certificates.
StatefulSets: They represent a set of pods that have a stable hostname and stable network identity, enabling stateful applications to be run on Kubernetes.
These objects can be defined using YAML or JSON configuration files and are managed using the Kubernetes API or command-line tools such as kubectl.
In Kubernetes, a Pod is the smallest and simplest unit of deployment. It is a logical host for a single container or multiple tightly coupled containers that share the same resources, such as storage and network. A Pod represents a single instance of a running process in a cluster.
Each Pod is allocated its own IP address and can communicate with other Pods in the same cluster using that IP address. Within a Pod, containers share the same network namespace, which means they can communicate using
127.0.0.1. Containers within a Pod also share the same storage volumes, allowing them to share data easily.
Pods are designed to be ephemeral and disposable. They can be easily created, replicated, and destroyed as needed. They can be created manually using YAML or JSON specification files, or they can be created automatically by a deployment or replication controller.
Overall, Pods provide a simple and powerful way to manage containers within a cluster, making it easier to develop, deploy, and scale containerized applications.
Pod life cycle
A Pod has a lifecycle that goes through several phases, from pending, running, succeeded, failed, to unknown. These phases indicate the current state of the Pod and what is happening to it at any given moment.
Here is a brief explanation of each phase in a Pod's lifecycle:
Pending: this is the initial phase when the Pod is created and the Kubernetes scheduler is looking for available nodes to run the Pod. During this phase, Kubernetes allocates resources for the Pod, such as CPU and memory, and it pulls the required container images.
Running: this phase indicates that the Pod has been scheduled to a node and has started running its containers. At this stage, the container(s) within the Pod are considered "live" and running their intended functionality.
Succeeded: this phase indicates that all the containers in the Pod have exited successfully and no further action is required from the Pod. In other words, the purpose of the Pod has been fulfilled, and it can now be deleted.
Failed: this phase indicates that all containers in the Pod have exited unsuccessfully or with an error, and have not been able to recover. This may require investigation to diagnose and resolve the underlying cause of the failure.
Unknown: this is the phase where the state of the Pod cannot be determined by the Kubernetes control plane, for example, when there is a connection issue between the control plane and the node the Pod is running on.
These lifecycle phases help provide visibility into a Pod's state, making it easier to diagnose and resolve issues. Additionally, Kubernetes provides several mechanisms for automating Pod lifecycle management, such as deployments and replication controllers, to help manage the overall state of a cluster's Pods.
pod definition file
Here's an example of a YAML definition file for a simple Pod that runs a container:
apiVersion: v1 kind: Pod metadata: name: my-pod labels: app: my-app spec: containers: - name: my-container image: nginx:1.19 ports: - containerPort: 80
Let's break down the above YAML file:
apiVersion: This specifies the Kubernetes API version to use. In this case, we are using version
kind: This specifies the type of object we are creating. In this case, we are creating a
metadata: This section provides metadata about the Pod, such as its name and labels.
name: This specifies the name of the Pod.
labels: This provides labels for the Pod. Labels are key-value pairs that can be used to select and filter resources. In this case, we are setting the
spec: This section defines the desired state of the Pod.
containers: This defines the container(s) to be run as part of the Pod.
name: This specifies the name of the container.
image: This specifies the Docker image to use for the container.
ports: This specifies the network ports to expose on the container.
containerPort: This is the port number of the container to expose. In this case, we are exposing port
80of the Nginx container.
Once you have created this YAML file, you can create the Pod by running the following command:
kubectl apply -f pod-definition.yaml
Labels for kubernetes object
Kubernetes labels are key-value pairs that are used to organize and select resources. Labels are attached to resources like Pods, ReplicaSets, Services, or Deployments as metadata, and can be used to select subsets of resources based on specific criteria.
Labels are essential to Kubernetes, as they are frequently used by other Kubernetes objects to find, organize, and manage resources. For example, a ReplicaSet uses labels to identify the Pods it is responsible for, and a Service uses labels to select the Pods that it directs traffic to.
Here's an example of using labels to select resources:
apiVersion: v1 kind: Pod metadata: name: my-pod labels: app: my-app environment: production spec: containers: - name: my-container image: my-image:latest ports: - containerPort: 80
In this example, the Pod has two labels with key-value pairs,
app: my-app and
environment: production. These labels can be used to select this Pod with a label selector.
For example, this label selector will select all Pods with the
app: my-app label:
apiVersion: v1 kind: Pod metadata: name: my-selector spec: containers: - name: my-container image: my-image:latest selector: matchLabels: app: my-app
By using labels, Kubernetes makes it easy to group, organize, and manage resources in a dynamic and flexible way.
commands to get a specific label pod
To get a specific label pod in Kubernetes, you can use the
kubectl get command with the
--selector flag followed by a label selector. Here is an example command that will display all pods that have the label
kubectl get pods --selector=app=my-app
This command will return a list of all pods that have the label
app=my-app. If you want to view more details about a specific pod, you can use
kubectl describe followed by the pod name. Here is an example command that will display detailed information about a pod with the name
kubectl describe pod my-pod
You can also use the
--show-labels flag to display the labels for each pod:
kubectl get pods --show-labels
This will return a list of all pods with their associated labels. You can then filter the output using a tool like
grep to search for specific labels.
In Kubernetes, ReplicaSets are responsible for ensuring that a specified number of replicas of a Pod are running at any given time. A ReplicaSet is an API object that defines a desired number of replicas for a set of Pods.
ReplicaSets are used to provide high availability for applications by ensuring that a specified number of replicas of a Pod are running at any given time. If a Pod fails or is deleted, the ReplicaSet automatically replaces it with a new Pod.
ReplicaSets use labels to select the Pods that they manage. When you create a ReplicaSet, you specify a label selector that identifies the Pods that the ReplicaSet should manage. The ReplicaSet ensures that the specified number of replicas of these Pods are running at all times.
ReplicaSets are similar to ReplicationControllers, but they provide more advanced selection mechanisms and can be used with more powerful labels. In general, you should use ReplicaSets instead of ReplicationControllers, unless you have a specific reason to use a ReplicationController.
Here's an example of a ReplicaSet definition file in YAML format:
apiVersion: apps/v1 kind: ReplicaSet metadata: name: my-app labels: app: my-app spec: replicas: 3 selector: matchLabels: app: my-app template: metadata: labels: app: my-app spec: containers: - name: my-app image: my-image:latest ports: - containerPort: 80
In this example, the ReplicaSet is named
my-app and is defined to have 3 replicas. The
selector is used to select the Pods that the ReplicaSet should manage. In this case, it selects Pods with the label
template section is used to define the Pod template that will be used to create the Pods. In this example, the Pod template includes a container with the name
my-app and the image
my-image:latest, which listens on port 80.
When this ReplicaSet is created or updated, it will ensure that there are always 3 replicas of the
my-app Pods running, each with the
app: my-app label. If a Pod fails or is deleted, the ReplicaSet will automatically create a replacement Pod to maintain the desired number of replicas.
namespace is a way to divide cluster resources between multiple users, teams, or projects. It provides a scope for names, such as pod names, service names, and resource names. Kubernetes resources are assigned to a specific namespace when they are created, allowing different users or teams to use the same resource name in different namespaces.
When you create a Kubernetes cluster, it has a single namespace called
default. You can create additional namespaces to group and manage your resources. For example, you may have multiple teams or projects using the same cluster, each with their own set of resources. By creating a namespace for each team or project, you can isolate their resources from each other and apply different access controls and resource quotas for each namespace.
Types of namespace
There are four types of namespace in Kubernetes:
Default Namespace: This is the default namespace created when Kubernetes is installed. All objects that are created in the cluster without a specified namespace get created in the default namespace.
System Namespace: This namespace is intended for objects that are created by the Kubernetes system. Examples of objects that are created in this namespace include
User Namespace: This namespace is intended for objects that are created by users. The user namespace is created by administrators, and users have permissions to create objects in this namespace.
Custom Namespace: This namespace is created by users for their own project or application.
To create a namespace, you can use the
kubectl create namespace command:
kubectl create namespace my-namespace
You can also specify the namespace for a particular resource by setting the
metadata.namespace field in its YAML manifest. For example, to create a deployment in a specific namespace, you would add the following to the deployment YAML:
apiVersion: apps/v1 kind: Deployment metadata: name: my-deployment namespace: my-namespace spec: replicas: 3 selector: matchLabels: app: my-app template: metadata: labels: app: my-app spec: containers: - name: my-container image: nginx ports: - containerPort: 80
In this example, we are creating a deployment named
my-deployment in the
my-namespace namespace, which will run three replicas of a container running the nginx image.
Namespaces are a powerful feature of Kubernetes that enable better organization and isolation of resources in a cluster.
Deployment is an object that manages a set of identical pods. It allows you to define a desired state for your application and then deploy and maintain that state in a declarative manner.
A Deployment creates a ReplicaSet, which is responsible for maintaining a specified number of replicas of the pod template. The pod template in the Deployment specifies the container image, resources, and other configuration for each pod. If a pod fails or is terminated for any reason, the ReplicaSet will ensure that a replacement pod is created to maintain the desired number of replicas.
Deployments support rolling updates and rollbacks, which allow you to update or roll back your application to a previous version without downtime. You can also perform rolling updates to deploy new versions of your application without downtime, by gradually replacing older pods with new ones.
In Kubernetes, there are different types of deploy strategies that can be used based on the requirements of your application. These strategies determine how a new version of your application is deployed and how it's rolled back in case of failures. Here are some common deployment strategies:
Recreate Deployment: In this strategy, the entire set of pods is terminated and new ones are created with the updated configuration. This causes downtime during the deployment process, but it's a simple and quick way to update your application.
Rolling Update Deployment: In this strategy, a set number of pods are updated at a time, in a gradual and controlled manner. The old pods are replaced with new ones until all pods are updated. This ensures that there's no downtime during the deployment process and that any issues can be detected early.
Blue/Green Deployment: In this strategy, two identical environments are set up for the same application, with one environment (blue) running the current version and the other (green) running the new version. Traffic is then routed to the green environment after it has been tested and validated. If any issues are detected, traffic can be redirected back to the blue environment.
To create a Deployment in Kubernetes, you need to define a YAML file that describes the desired state of your application. Here's an example YAML file for a simple Deployment:
apiVersion: apps/v1 kind: Deployment metadata: name: my-deployment spec: replicas: 3 selector: matchLabels: app: my-app template: metadata: labels: app: my-app spec: containers: - name: my-container image: my-image:latest ports: - containerPort: 80
In this example, the Deployment will create three replicas of a pod template that runs a container called
my-container with the image
my-image:latest. The pod will listen on port 80, and the Deployment will use the
app: my-app label selector to identify and manage the pods.
use below link for more detail about deployment
In Kubernetes, a Service is an abstract way to expose a set of pods running in your cluster as a network service. Services enable network connectivity to a specific set of pods, regardless of their physical location within the cluster. Services act as "load balancers" to route incoming network traffic to the healthy pods that are part of a defined set of pods called a "Selector".
Here are some important points about services in Kubernetes:
Services can be of different types: ClusterIP(default), NodePort, LoadBalancer, ExternalName. It determines how the service is exposed to the network.
ClusterIP is the most common type of service, which exposes the service on a cluster-internal IP only. The service can be accessed only within the Kubernetes cluster.
NodePort type exposes the service at a specific port on the worker nodes' IP addresses, which is useful when you want to expose the service on a specific port number.
LoadBalancer type creates an external load balancer provisioned by a cloud provider, which is useful when you want to expose the service to the outside network.
Services are accessed using the Service name and port number combination. Kubernetes DNS service resolves the service name to its corresponding IP address.
To create a service in Kubernetes, you need to define a manifest file that describes the service's properties, including its selector and port mappings. Here is an example manifest file for creating a ClusterIP type service for an application called "myapp" running on port 8080:
apiVersion: v1 kind: Service metadata: name: myapp-svc spec: selector: app: myapp ports: - name: http port: 80 protocol: TCP targetPort: 8080
This manifest creates a service named "myapp-svc" that selects all the pods with the label "app: myapp" and exposes them on port 80 within the cluster. Incoming traffic on this port is redirected to the port 8080 of the selected pods.
K8s Resource quota
In Kubernetes, a resource quota is a feature that allows you to limit the overall resource consumption of a namespace. Resource quotas help you prevent unexpected overspending of resources and can help in overall cluster resource management.
Resource quotas can be set on a per-namespace basis within a Kubernetes cluster, and can limit the following resources:
Compute resources: CPU and memory.
Object count: a limit on the number of objects within a namespace.
Here's an example Kubernetes manifest file for setting a resource quota for a namespace.
apiVersion: v1 kind: ResourceQuota metadata: name: my-quota spec: hard: cpu: "2" memory: 1Gi pods: "10" services: "5" replicationcontrollers: "3"
In this example, the resource quota named "my-quota" has been set with the following limits:
The namespace can create up to 10 pods.
The total amount of memory used by all pods cannot exceed 1 GB.
The namespace can create up to 5 services.
The namespace can store no more than 3 replication controllers.
To check the resource quota values of a namespace, you can use the
kubectl describe quota command. Here's an example:
$ kubectl describe quota my-quota --namespace=my-namespace Name: my-quota Namespace: my-namespace Resource Used Hard -------- ---- ---- cpu 500m 2 memory 256Mi 1Gi pods 5 10 services 2 5 replicationcontrollers 2 3
The output of the
kubectl describe quota command shows the current usage (in the
Used column) and the limit (in the
Hard column) for each resource type specified in the resource quota. This can help you identify if there are any resources that are close to hitting their quota limits and need to be managed accordingly.
Pod resources with cpu and memory limits
apiVersion: v1 kind: Pod metadata: name: my-pod spec: containers: - name: my-container image: my-image:latest resources: limits: cpu: "1" memory: "256Mi" requests: cpu: "500m" memory: "128Mi"
spec section of the yaml file, you can see the
containers field, which specifies the container(s) running in the pod. In this example, there is only one container named
my-container, which uses the
my-image:latest container image.
resources field is where you can specify the CPU and memory limits and requests for the container. The
limits field specifies the maximum amount of CPU and memory that the container is allowed to use. In this example, the container is limited to 1 CPU and 256Mi of memory.
requests field specifies the minimum amount of CPU and memory that the container needs. In this example, the container requests at least 500m of CPU and 128Mi of memory.
Note that the values for CPU and memory limits and requests are specified as strings with a unit of measurement (e.g. "500m" for 500 milliCPUs), and that the resource units are standardized across Kubernetes.
In Kubernetes, a DaemonSet is a type of workload controller that ensures that a copy of a specific pod runs on each node within a cluster. It is ideal for situations where you need a single instance of a pod to be scheduled on every node, such as logging agents, monitoring agents, or networking proxies.
A DaemonSet guarantees that a pod is created and scheduled on every node in the cluster, including new nodes that are added later. When a new node joins the cluster, the DaemonSet controller automatically creates and schedules a pod on the new node.
Here is an example YAML manifest for creating a DaemonSet in Kubernetes:
apiVersion: apps/v1 kind: DaemonSet metadata: name: my-daemonset spec: selector: matchLabels: app: my-app template: metadata: labels: app: my-app spec: containers: - name: my-container image: nginx:latest
Let's break down the components of this DaemonSet manifest:
metadata: This section specifies metadata about the DaemonSet, including its name.
specsection defines the desired state of the DaemonSet.
selectorfield specifies the labels used to identify the nodes where the pods should be scheduled. In this example, pods with the label
app: my-appwill be targeted.
templatefield defines the template for the pods that the DaemonSet should create.
metadatasection within the
templatespecifies labels for the pods.
specsection within the
templatedefines the pod specification, including containers.
containersfield lists the containers to be included in the pod. In this example, there is a single container named
To create the DaemonSet, save the above YAML manifest to a file (e.g.,
daemonset.yaml) and apply it using the
kubectl apply command:
kubectl apply -f daemonset.yaml
Kubernetes will create a pod for each node in the cluster, ensuring that the specified container (
nginx:latest in this case) runs on every node.
In Kubernetes, Horizontal Pod Autoscaler (HPA) is a resource that automatically adjusts the number of replica pods in a Deployment, ReplicaSet, or StatefulSet based on observed CPU utilization or custom metrics. It helps to ensure that your applications have the appropriate amount of resources to handle varying traffic loads.
The HPA controller continuously monitors the CPU utilization or custom metrics of the target workload and calculates the desired number of replicas based on the defined metrics and target utilization.
To create an HPA in Kubernetes, you need to have the metrics server running in your cluster. The metrics server collects resource usage data from the cluster's nodes and provides the data required for the HPA to make scaling decisions.
Here's an example YAML manifest for creating an HPA for a Deployment:
apiVersion: autoscaling/v2beta kind: HorizontalPodAutoscaler metadata: name: my-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: my-deployment minReplicas: 2 maxReplicas: 5 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 50
Let's go through the components of this HPA manifest:
metadata: This section specifies metadata about the HPA, including its name.
specsection defines the behavior and metrics of the HPA.
scaleTargetReffield specifies the target workload to scale. In this example, it targets a Deployment named
maxReplicas: These fields define the minimum and maximum number of replicas the HPA can scale.
metricsfield specifies the metrics used for autoscaling. In this case, it uses resource-based metrics, specifically CPU utilization.
type: Resourceindicates that resource-based metrics are used.
resourcespecifies the resource metric being utilized, in this case, CPU.
targetspecifies the target utilization of the resource metric. In this example, the target CPU utilization is set to an average of 50%.
To create the HPA, save the YAML manifest to a file (e.g.,
hpa.yaml) and apply it using the
kubectl apply command:
shellCopy codekubectl apply -f hpa.yaml
The HPA controller will then monitor the CPU utilization of the target Deployment and adjust the number of replicas accordingly to maintain the desired CPU utilization target.
You can check the status of the HPA using the
kubectl get hpa command and observe how it scales the number of replicas based on the observed metrics.
Did you find this article valuable?
Support Naveen Elwaka by becoming a sponsor. Any amount is appreciated!