DEV Community: Mesrar

Kubernetes Essentials: Labels, Selectors, Environment Variables, and Annotations Demystified

Mesrar — Thu, 01 Feb 2024 15:32:23 +0000

Labels: Organizing and Identifying Kubernetes Resources

Viewing Labels
To display labels for pods, deployments, or all resources, use:

kubectl get po|deploy|all --show-labels

Adding Labels to Resources
Add labels to a pod, deployment, or node:

kubectl label po <pod-name> <label-key>=<label-value>
kubectl label deploy <deployment-name> <label-key>=<label-value>
kubectl label no <node-name> <label-key>=<label-value>

Removing Labels
Remove a label from a pod:

kubectl label po <pod-name> <label-key>-

Overwriting Labels
Overwrite a label for a pod:

kubectl label po <pod-name> <label-key>=<new-label-value> --overwrite

Important Notes
Duplicate keys are not allowed in labels.

Selectors: Filtering Resources Based on Labels

Filtering Resources
Filter pods based on labels:

kubectl get po --selector=<label-key>=<label-value>

Inequality and Multiple Labels
Use inequality and multiple labels in selectors:

kubectl get po --selector=<label-key>!=<label-value>
kubectl get po --selector=<label-key>=<label-value>,<label-key>=<label-value>

Environment Variables: Configuring Pods
Creating Pods with Environment Variables
Run an nginx pod with an environment variable:

kubectl run nginx --image=nginx --env=app=web

Important Properties
env and envFrom properties are arrays.
env property takes name and value properties.

Annotations: Adding Metadata to Resources

Adding Annotations to Pods
Annotate a pod with additional information:

kubectl annotate po <pod-name> <annotation-key>=<annotation-value>

Removing Annotations
Remove an annotation from a pod:

kubectl annotate po <pod-name> <annotation-key>-

Important Notes

Duplicate keys are not allowed in annotations.

Enhance your Kubernetes resource organization with labels, leverage selectors for efficient filtering, configure environment variables for pods, and add valuable metadata using annotations.

Happy Kuberneting!

Volumes: Persistent Storage in Kubernetes

Mesrar — Thu, 01 Feb 2024 15:23:59 +0000

Viewing Persistent Volumes (PV) and Persistent Volume Claims (PVC)

To check details about Persistent Volumes and Persistent Volume Claims, use the following commands:

kubectl get pv
kubectl get pvc

Deleting a Persistent Volume Claim (PVC)
Remove a specific Persistent Volume Claim:

kubectl delete pvc <pvc-name>

Deleting a Persistent Volume (PV)
Remove a specific Persistent Volume:

kubectl delete pv <pv-name>

Important Properties to Remember
Defining Volumes in Pod Specification:

##yaml

spec:
  volumes:
  - name: <volume-name>
    emptyDir: {}

Mounting Volumes in Container Specification:

##yaml

spec:
  containers:
  - name: <container-name>
    volumeMounts:
    - name: <volume-name>
      mountPath: <path-in-container>

HostPath Volume:

yaml
spec:
  volumes:
  - name: <volume-name>
    hostPath:
      type: Directory
      path: <host-path>

Persistent Volume (PV) and Persistent Volume Claim (PVC) Relationship:
PVC remains in a pending state until bound to a PV.
StorageClassName and AccessModes must match between PV and PVC.
Storage size must be within the specified range.
Reclaim Policy for Persistent Volumes
Persistent Volumes have a reclaim policy that dictates their future when the Persistent Volume Claim is deleted:

Recycle: Data in the volume is purged.
Retain: Both data and volume are retained.
Delete: Volume is deleted.
Specifying Reclaim Policy:

yaml

spec:
  persistentVolumeReclaimPolicy: <policy>

PV and PVC Selection
PVs use labels, and PVCs use selectors for PV selection.
PVs are cluster-wide, while PVCs are namespaced.
Explore the world of Persistent Volumes and Claims to provide durable storage for your Kubernetes applications.

Happy Kuberneting!

Ingress: Effortless External Access to Your Services

Mesrar — Thu, 01 Feb 2024 15:16:04 +0000

Checking Ingress Details
To inspect details about Ingress resources, use the following commands:

kubectl get ingress
kubectl describe ingress <ingress-name>

Modifying Ingress Configuration
Edit the configuration of an existing Ingress resource:


kubectl edit ingress <ingress-name>

Applying Ingress Configuration
Apply the configuration defined in an Ingress YAML file:


kubectl apply -f <ingress.yaml>

Setting Up Ingress

Setting up Ingress involves the following components, all residing in the same namespace:

Ingress Controller (Deployment)
: Responsible for fulfilling Ingress rules.

Node Port Ingress Service:
Enables access to the Ingress controller from outside the cluster.

Config Map:
Configures various parameters for the Ingress controller.

Ingress Controller Initialization
Unlike other controllers, Ingress controllers do not start automatically. They require manual deployment. Kubernetes supports various Ingress controllers for different cloud providers, such as AWS, GCE, and nginx.

Ingress Resource Rules
The Ingress resource, defined with the type 'ingress', resides in a different namespace from the application (deployment) and the service (for accessing the deployment). The Ingress resource specifies the rules, and the Ingress controller ensures their fulfillment.

Enhance your Kubernetes cluster with Ingress, providing a seamless way to access your services from the external world.

Happy Kuberneting!

Kubernetes Jobs: Running Tasks in Kubernetes

Mesrar — Thu, 01 Feb 2024 15:05:01 +0000

Creating a Job

Initiate a job that runs a specific command in a container:

kubectl create job busybox --image=busybox -- /bin/sh -c "echo hello; sleep 30; echo world"

Managing Jobs
Check the status and details of all jobs in the current namespace:

kubectl get jobs

Viewing Job Logs
Retrieve logs from a specific pod created by a job:

kubectl logs <pod-name>

Deleting a Job
Remove a job and its associated pods:

kubectl delete job <job-name>

Understanding Job Properties
Jobs have several key properties to consider:

completions
: Number of pod completions expected.
backoffLimit: Maximum number of retries before considering a job as failed.

parallelism
: Number of pods to run in parallel.
activeDeadlineSeconds: Maximum time for the job to run.
restartPolicy: Pod restart policy, usually set to "OnFailure" or "Never".

Important Notes

In a job, the default value for the restart property is "Never."
A pod created by a job must have its restartPolicy set to "OnFailure" or "Never."

CronJobs: Scheduled Jobs

Managing CronJobs
List all CronJobs in the current namespace:

kubectl get cronjobs

Creating a CronJob
Establish a CronJob that runs on a specified schedule:

kubectl create cronjob busybox --image=busybox --schedule="*/1 * * * *" -- /bin/sh -c "date; echo Hello from Kubernetes cluster"

Specifying CronJob Properties
In a CronJob, there are three spec sections to note - one for the CronJob itself, one for the Job, and one for the Pod. Important properties include:

spec -> successfulJobHistoryLimit: Number of successful jobs to retain in history.
spec -> failedJobHistoryLimit: Number of failed jobs to retain in history.
Explore the capabilities of Kubernetes Jobs and CronJobs, enhancing your control over task execution and scheduling within your cluster.

Happy Kuberneting!

A Comprehensive Guide to Taints, Tolerations, Logging, and Monitoring

Mesrar — Thu, 01 Feb 2024 14:55:42 +0000

Taints (on nodes) and Tolerations (on pods)
Understanding Taints on Nodes
To inspect taints on a specific node, use the following command:

kubectl describe node <node-name> | grep -i "taint"

Tainting a Node
Create a taint on a node with a specific key, value, and effect:

kubectl taint node <node-name> spray=mortein:NoSchedule

spray: Key of the taint.
mortein: Value associated with the key.
NoSchedule: Effect that defines the behavior of pods that do not tolerate this taint.

Tolerations on Pods

When deploying pods, use tolerations to allow them to tolerate specific node taints. In the pod specification, add a tolerations section under spec with properties like key, operator, value, and effect:

#yaml

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  tolerations:
  - key: "spray"
    operator: "Equal"
    value: "mortein"
    effect: "NoSchedule"
  containers:
  - name: mycontainer
    image: myimage

Removing Taints
To remove a specific taint from a node:

kubectl taint node <node-name> key=value:effect-

For example, to remove all taints with key 'dedicated' from node 'foo':

kubectl taint node foo dedicated-

Logging
Viewing Container Logs
Check the standard output of a container using the logs command:


kubectl logs -f <pod-name> <container-name> # Follow the logs
kubectl logs <pod-name> --previous # Dump pod logs for a 
previous instantiation of a container

Monitoring
Resource Usage Metrics
Get resource usage metrics for nodes and pods:

kubectl top node
kubectl top pod

Identifying CPU-Intensive Pod
To find the pod consuming the most CPU:


kubectl top pod --namespace=default | head -2 | tail -1 | cut -d " " -f1
kubectl top pod --sort-by cpu --no-headers

Empower your Kubernetes journey with insights into taints, tolerations, efficient logging, and real-time monitoring.

Happy Kuberneting!

Unleashing Kubernetes: The Power of Service Accounts

Mesrar — Thu, 01 Feb 2024 14:45:50 +0000

In Kubernetes, Service Accounts play a pivotal role in governing permissions and authentication for applications running within pods. Let's dive into key commands and concepts related to Service Accounts.

Service Account Operations

Create a Service Account
Create a new Service Account:

kubectl create sa <sa-name>

View Service Accounts
List all Service Accounts in the current namespace:

kubectl get sa

Describe a Service Account
Get detailed information about a specific Service Account:

kubectl describe sa <sa-name>

Fetch Token from Service Account
Retrieve the token associated with a Service Account:


kubectl describe sa <sa-name>  # provides the associated secret name
kubectl describe secret <secret-name>  # fetches the token stored in the secret

Create a Pod with a Service Account
Run a pod using a specific Service Account:


kubectl run nginx --image=nginx --serviceaccount=myuser --dry-run=client -o yaml > pod.yaml
kubectl apply -f pod.yaml

When a Service Account is used inside a pod, the secret for that Service Account is mounted as a volume inside the pod.

Pod-level Service Account
Specify the Service Account at the pod level:


apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  serviceAccountName: myuser
  containers:
  - name: mycontainer
    image: myimage

User vs. Service Account
A user makes requests to the API server through kubectl using their user account.
A process running inside a container makes requests to the API server using a Service Account.
Both user accounts and Service Accounts have associated permissions.

Remember: Service Accounts are injected into the pod and can be set at both the pod and deployment levels.

Harness the power of Service Accounts to enhance security and control within your Kubernetes environment.

Happy Kuberneting!

Mastering Kubernetes Components: Namespace, ConfigMap, and Secrets

Mesrar — Thu, 01 Feb 2024 14:09:55 +0000

In Kubernetes, effective management of namespaces, ConfigMaps, and Secrets is crucial for maintaining a well-organized and secure environment. Let's explore key commands and concepts related to these components.

Namespace Operations

View Namespaces
List all namespaces in the current cluster:

kubectl get ns

Create a Namespace
Create a new namespace, either imperatively or declaratively:


kubectl create ns <namespace-name>
kubectl apply -f <namespace.yaml>

View Pods in a Namespace
Check pods in a specific namespace:

kubectl get po -n kube-system

Describe a Namespace
Get detailed information about a specific namespace:

kubectl describe ns <namespace-name>

Delete a Namespace
To delete a specific namespace:

kubectl delete ns <namespace-name>

Switch Namespace Permanently
Set the current context to a specific namespace:

kubectl config set-context $(kubectl config current-context) --namespace=<namespace-name>

View Pods in All Namespaces
List all pods across all namespaces:

kubectl get po -A

Create a Pod in a Specific Namespace
Run a pod in a designated namespace:

kubectl run redis --image=redis -n <namespace-name>

Create Namespace Declaratively
Create a namespace from a YAML file:


kubectl create ns <namespace-name> --dry-run=client -o yaml > namespace.yaml
kubectl apply -f namespace.yaml

ConfigMap Operations

View ConfigMaps
List all ConfigMaps in the current namespace:

kubectl get cm

Describe a ConfigMap
Get detailed information about a specific ConfigMap:

kubectl describe cm <cm-name>

Create a ConfigMap
Create a ConfigMap from files or literals:

kubectl create cm <cm-name> --from-file=<path to file>
kubectl create cm <cm-name> --from-literal=<key1>=<value1> --from-literal=<key2>=<value2>
kubectl apply -f cm.yaml

Secret Operations

View Secrets
List all secrets in the current namespace:

kubectl get secrets

Describe a Secret
Get detailed information about a specific Secret:

kubectl describe secret <secret-name>

Create a Secret
Create a Secret from files or literals:

kubectl create secret generic <secret-name> --from-file=<path to file>
kubectl create secret generic <secret-name> --from-literal=<key1>=<value1> --from-literal=<key2>=<value2>

Encoding and Decoding Secrets

Use base64 for encoding and decoding secrets:

echo -n 'string' | base64
echo -n 'encoded string' | base64 --decode

Ensure proper management of namespaces, ConfigMaps, and Secrets to achieve effective resource isolation, configuration management, and sensitive data protection in your Kubernetes cluster.

Happy Kuberneting!

Navigating Services in Kubernetes

Mesrar — Thu, 01 Feb 2024 13:55:06 +0000

In Kubernetes, services play a crucial role in enabling communication between different components within the cluster or exposing applications to external users. Let's explore key commands and concepts related to managing services.

Key Operations
Create a Service
Apply a service definition from a YAML file:

kubectl apply -f <svc.yaml>

View Services
List all services in the current namespace:

kubectl get svc

Describe a Service
Get detailed information about a specific service, including ports and selectors:

kubectl describe svc <service-name>

Delete a Service
To delete a specific service:

kubectl delete svc <service-name>

Expose a Pod with a Service
Expose a pod by creating a ClusterIP service:

kubectl expose pod redis --port=6379 --name=redis-service --type=ClusterIP --dry-run=client -o yaml > svc.yaml

Or expose a deployment with a NodePort service:

kubectl expose deploy <deploy-name> --port=<service-port>

Edit a Service
Edit the configuration of a service:

kubectl edit svc <service-name>

Get Endpoints for a Service
View the endpoints associated with a service:

kubectl get ep <svc-name>

Additional Insights
Service Types:

NodePort: Exposes the service on each node's IP at a static port. Accessible externally.
ClusterIP: Exposes the service inside the cluster using a cluster-internal IP.
LoadBalancer: Creates an external IP and routes traffic to the service.

Ports in Services:
NodePort: Port on the node.
Port: Port on the service (exposed internally).
TargetPort: Port on the pod (container).

Service Selector:
Services, deployments, replica sets, and network policies use the selector property under spec to select pods using labels.

Accessing Services:
Pods can access services using the ClusterIP or service name.
Ensure proper configuration of services based on your use case, whether for internal communication or external access.

Happy Networking in Kubernetes!

Navigating Horizontal Pod Autoscaler (HPA) in Kubernetes

Mesrar — Thu, 01 Feb 2024 13:43:21 +0000

The Horizontal Pod Autoscaler (HPA) in Kubernetes allows for automatic scaling of the number of pods in a deployment or replica set based on observed CPU utilization or other custom metrics. Let's explore essential commands for managing HPAs in your Kubernetes cluster.

Key Operations

View HPAs

To list all Horizontal Pod Autoscalers in the current namespace:

kubectl get hpa

Delete an HPA
To delete a specific Horizontal Pod Autoscaler:

kubectl delete hpa <hpa-name>

Create an HPA
Create an HPA for a deployment named "nginx" with minimum 5 and maximum 10 replicas, targeting 80% CPU utilization:

kubectl autoscale deploy nginx --min=5 --max=10 --cpu-percent=80

This command sets up an HPA for the "nginx" deployment to automatically adjust the number of replicas based on CPU utilization, keeping it between 5 and 10 replicas and targeting 80% CPU usage.

Additional Insights
Desired Metrics: The HPA monitors the metrics defined (CPU utilization in this example) and adjusts the number of replicas to meet the specified targets.

Dynamic Scaling: HPA enables dynamic scaling based on real-time resource demand, ensuring optimal resource utilization.

Pod Metrics: HPAs can also be configured to scale based on custom metrics, such as memory usage, or external metrics like requests per second.

Scaling Behavior: The scaling behavior is defined by the --cpu-percent parameter, determining when to scale in or out based on the specified CPU utilization threshold.

Ensure that the configuration and metrics defined in your HPA align with the requirements and behavior of your application to achieve efficient and automated scaling.

Happy Autoscaling!

Mastering Deployments in Kubernetes

Mesrar — Thu, 01 Feb 2024 13:13:11 +0000

Deployments in Kubernetes play a pivotal role in managing scalable and reliable applications. In this guide, we'll delve into essential commands and operations related to Deployments, empowering you to efficiently roll out and manage application updates.

Key Operations

Create a Deployment

Create a simple deployment using the kubectl create deploy command:

kubectl create deploy nginx --image=nginx --replicas=2

View Deployments
Get a list of deployments in the current namespace:


kubectl get deploy

For deployments in a specific namespace:

kubectl get deploy -n <namespace-name>

Retrieve detailed information about a specific deployment:

kubectl get deploy <deployment-name>
kubectl get deploy <deployment-name> -o yaml | more
kubectl get deploy -o wide

Apply Deployment from YAML
Apply a deployment defined in a YAML file:

kubectl apply -f deploy.yaml

To record the change cause in revision history:


kubectl apply -f deploy.yaml --record

Deployment Rollout Status
Check the rollout status of a deployment:


kubectl rollout status deploy <deployment-name>

Deployment Rollout History
View the revision history of a deployment:

kubectl rollout history deploy <deployment-name>

For detailed history of a specific revision:


kubectl rollout history deploy nginx --revision=2

Rollback Deployment
Rollback a deployment to a previous revision:

kubectl rollout undo deploy <deployment-name>

Or, rollback to a specific revision:

kubectl rollout undo deploy <deployment-name> --to-revision=1

Pause and Resume Deployment
Pause a deployment to apply multiple fixes, then resume to start a new rollout:

kubectl rollout pause deploy <deployment-name>
kubectl rollout resume deploy <deployment-name>

Delete Deployment
Delete a deployment:


kubectl delete deploy <deployment-name>

Scaling a Deployment
Scale up or down a deployment:

kubectl scale deploy <deployment-name> --replicas=3

Create a Deployment from YAML
Create a deployment using YAML definition:

kubectl create deploy <deployment-name> --image=redis -n <namespace-name>

Edit a Running Deployment
Make changes to a running deployment:

kubectl edit deploy <deployment-name> -n <namespace-name>

Important Properties
Deployment strategies and properties to remember:

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxUnavailable: 0
    maxSurge: 1

Type: RollingUpdate: Specifies the update strategy as RollingUpdate, which means that the deployment process will replace old pods with new ones in a rolling fashion, ensuring the availability of the application during the update.

RollingUpdate Configuration:

maxUnavailable: 0: This setting indicates the maximum number or percentage of pods that can be unavailable during the update. A value of 0 means that no pods are allowed to be unavailable at any point during the rolling update. This ensures high availability as the new pods are gradually introduced, and the old ones are terminated.

maxSurge: 1: This setting indicates the maximum number or percentage of new pods that can be created above the desired number of replicas. In this case, a value of 1 means that only one additional pod is allowed to be created during the update process. This controls the rate at which new pods are introduced, preventing any sudden spikes in resource usage
Keys follow camel case naming convention, and values follow initials in uppercase convention.

Additional Insights
Deployments automatically create a ReplicaSet, which, in turn, creates pods.
When creating or updating images in a deployment, a new rollout triggers, creating a new deployment revision.
Identify problematic deployments by checking the READY status. The number of containers running may be less than desired.
Mastering these deployment operations ensures smooth application updates and scalability in your Kubernetes environment.

Happy Deploying!

Navigating Replicaset Operations in Kubernetes

Mesrar — Thu, 01 Feb 2024 13:06:15 +0000

Managing scalable and resilient applications in Kubernetes often involves working with ReplicaSets. In this guide, we'll explore essential commands and operations related to ReplicaSets to empower your Kubernetes journey.

Key Operations

Create a ReplicaSet
Apply a ReplicaSet definition file to create a new ReplicaSet:

kubectl apply -f <replicaset-definition.yaml>

View ReplicaSets
To see a list of ReplicaSets in the current namespace:

kubectl get rs

For a more detailed view, including additional information like pod distribution:

kubectl get rs -o wide

Delete a ReplicaSet
To delete a specific ReplicaSet:

kubectl delete rs <replicaset-name>

Scale a ReplicaSet
Scale a ReplicaSet to a desired number of replicas:

kubectl scale rs <replicaset-name> --replicas=6

Edit a ReplicaSet

There are two ways to edit a ReplicaSet. Either delete and re-create the ReplicaSet, or update the existing ReplicaSet and then delete all pods:


kubectl edit rs <replicaset-name>
kubectl delete po <replicaset-pod-name>

Alternatively:

kubectl get rs <replicaset-name> -o yaml > rs.yaml
vi rs.yaml
kubectl apply -f rs.yaml
kubectl delete po <replicaset-pod-name>

ReplicaSet Labels

Ensure that the values for labels in spec.selector and spec.template.metadata match in the ReplicaSet.

Viewing All Objects
To see all objects at once in the current namespace:

kubectl get all

ReplicaSet Template

Remember that a ReplicaSet has a template, specifying the pod template for creating new pods.

These commands and considerations are essential for effectively managing ReplicaSets in Kubernetes. Incorporate them into your workflow to ensure scalable and reliable applications.

Happy Replicating!

Demystifying Commands and Arguments in Kubernetes

Mesrar — Thu, 01 Feb 2024 12:58:45 +0000

Understanding how commands and arguments work in Kubernetes is crucial for optimizing your containerized applications. In this guide, we'll explore the nuances of defining commands and arguments, providing examples and insights to enhance your container orchestration skills.

Basic Concepts

A container's lifespan is tied to the process inside it. When the process finishes or crashes, the container exits.
Define commands and arguments in the pod configuration file to override defaults provided by the container image.
Use the command and args fields to specify the executable and arguments for a container.
If you define args without specifying a command, the default command is used with your new arguments.

Examples

Example 1: Executing Commands

spec:
  containers:
  - name: command-demo-container
    image: debian
    command: ["printenv"]
    args: ["HOSTNAME", "KUBERNETES_PORT"]

Example 2: Running a Command in a Shell

spec:
  containers:
  - name: shell-command-demo
    image: alpine
    command: ["/bin/sh"]
    args: ["-c", "while true; do echo hello; sleep 10; done"]

Example 3: Specifying a Command and Arguments

spec:
  containers:
  - name: sleep-container
    image: busybox
    command: ["sleep"]
    args: ["5000"]

Example 4: Using a Dockerfile

FROM python:3.6-alpine
RUN pip install flask
COPY . /opt/
EXPOSE 8080
WORKDIR /opt
ENTRYPOINT ["python", "app.py"]
CMD ["--color", "red"]

Example 5: Dockerfile with Entry Point


FROM python:3.6-alpine
RUN pip install flask
COPY . /opt/
EXPOSE 8080
WORKDIR /opt
ENTRYPOINT ["python", "app.py"]

Important Considerations

If you supply only args, the default ENTRYPOINT in the Docker image is run with the provided args.
If you supply a command and args, the default ENTRYPOINT and CMD in the Docker image are ignored.

If you supply a command without args, only the supplied command is used, and the default ENTRYPOINT and CMD are ignored.
These principles apply when working with Kubernetes pods and containers. Understanding these nuances empowers you to fine-tune your applications for optimal performance and behavior within a Kubernetes environment.

Happy Kuberneting!