DEV Community: Manikanta

Kubernetes Resource Quotas and Limit Ranges with Namespaces

Manikanta — Fri, 08 Nov 2024 11:08:44 +0000

Kubernetes is a powerful container orchestration platform that allows you to manage and scale containerized applications. When managing workloads in a Kubernetes cluster, it’s important to control resource usage to ensure fair sharing of resources, prevent any single workload from over-consuming cluster resources, and ensure that your applications run reliably.

Two key concepts in Kubernetes help with resource management: Resource Quotas and Limit Ranges. These are applied within a Namespace, which is a way to organize and isolate resources within a cluster. In this blog, we will explain these concepts in simple terms and show you how to configure them using Kubernetes manifests.

What is a Namespace in Kubernetes?

A Namespace in Kubernetes is a way to partition cluster resources into logically named groups. It provides a mechanism for isolating resources (like pods, services, deployments, etc.) so that they don’t interfere with each other. Namespaces help you manage resources for different teams, projects, or environments (e.g., dev, staging, prod) within the same Kubernetes cluster.

For example, a namespace could be created for each department in an organization:

dev
staging
production

By grouping resources under namespaces, it becomes easier to manage permissions, policies, and quotas.

What is a Resource Quota?

A ResourceQuota in Kubernetes is a policy that limits the amount of resources (such as CPU, memory, number of pods, etc.) that can be consumed within a specific namespace. It helps prevent a single user or application from consuming all the resources in the cluster, thus ensuring fair resource allocation.

Key Properties of a ResourceQuota:

CPU: Limits the total CPU usage within a namespace.
Memory: Limits the total memory usage within a namespace.
Pods: Limits the number of Pods that can be created in a namespace.
Services, Deployments, etc.: Limits the number of specific types of resources that can be created.

Example: Resource Quota Manifest

Let’s say we want to limit a namespace (dev-namespace) so that it can use at most 4 CPUs, 16Gi of memory, and can create a maximum of 10 Pods. Below is an example ResourceQuota manifest for this use case:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: dev-namespace-quota
  namespace: dev-namespace
spec:
  hard:
    requests.cpu: "4"
    requests.memory: 16Gi
    limits.cpu: "4"
    limits.memory: 16Gi
    pods: "10"

In this example:

The requests.cpu and limits.cpu specify the maximum CPU the namespace can request or use.
The requests.memory and limits.memory specify the maximum amount of memory the namespace can request or use.
The pods field limits the number of Pods that can be created in the dev-namespace.

If the resources exceed the defined limits, Kubernetes will prevent new resources from being created until resources within the namespace are freed up.

What is a LimitRange?

A LimitRange is a policy that defines the minimum and maximum resource limits for individual containers running within a namespace. Unlike ResourceQuota, which applies to the entire namespace, a LimitRange applies to individual containers within that namespace. This ensures that each container is constrained to using a defined range of resources.

Key Properties of a LimitRange:

Limit: Defines the maximum amount of resources that a container can request or use.
Request: Defines the minimum amount of resources that a container should request when it starts.
Default: Defines the default resource requests and limits for containers that don’t specify them explicitly.

Example: LimitRange Manifest

Let’s say we want to define a LimitRange in the dev-namespace to ensure each container can have a minimum of 128Mi of memory and 100m (0.1) CPUs, and a maximum of 1Gi of memory and 1 CPU. We also want to set default values if the user doesn’t specify them.

apiVersion: v1
kind: LimitRange
metadata:
  name: dev-namespace-limits
  namespace: dev-namespace
spec:
  limits:
  - type: Container
    max:
      memory: 1Gi
      cpu: "1"
    min:
      memory: 128Mi
      cpu: "100m"
    default:
      memory: 512Mi
      cpu: "500m"
    defaultRequest:
      memory: 256Mi
      cpu: "200m"

In this example:

The max field specifies the maximum resources a container can request.
The min field sets the minimum resources a container can request.
The default field sets default resource requests for containers that don’t specify them explicitly.
The defaultRequest field specifies the default resource requests for containers.

If a container is created without explicitly defining resource limits or requests, Kubernetes will automatically apply the defaults defined in the LimitRange.

How ResourceQuota and LimitRange Work Together

ResourceQuotas and LimitRanges complement each other:

ResourceQuota limits the total usage of resources within a namespace.
LimitRange defines the constraints for individual containers within that namespace.

For example:

A ResourceQuota can prevent a namespace from consuming too many resources overall (e.g., 4 CPUs and 16Gi of memory).
A LimitRange can enforce individual container-level limits (e.g., containers in the namespace can only use up to 1Gi of memory).

Together, they ensure that resources are used efficiently, and prevent users or applications from over-consuming resources in a shared cluster environment.

Practical Use Cases

Preventing Resource Overuse: If you have multiple teams or applications running in the same cluster, you can use ResourceQuota to make sure no team can consume all available resources.
Consistent Resource Allocation: Using LimitRange, you can ensure that each team’s containers have a reasonable amount of resources, avoiding cases where containers are too resource-hungry and causing performance degradation for others.
Automatic Defaults: By setting defaults in the LimitRange, you can ensure that all containers have consistent resource requests and limits, even if users forget to specify them.

Conclusion

In Kubernetes, Resource Quotas and Limit Ranges are powerful tools for managing resource usage and ensuring that applications run efficiently and fairly within a namespace. By setting resource limits at both the namespace and container levels, you can prevent one application from consuming too many resources, while also ensuring that containers have the resources they need to run smoothly.

Understanding LimitRange in Kubernetes: A Guide with Examples

Manikanta — Fri, 08 Nov 2024 10:52:00 +0000

Kubernetes provides powerful resource management tools to help you control how resources are allocated to containers within your clusters. One such tool is LimitRange. LimitRange helps administrators set limits on the resource usage (CPU, memory) and enforce constraints on a per-namespace basis. This is particularly useful in multi-tenant environments where you want to prevent a single pod from consuming excessive resources that could affect other workloads running in the same namespace.

In this blog post, we’ll walk you through what LimitRange is, why it's useful, and provide a detailed example of how to create a namespace and apply a LimitRange with Kubernetes manifest files.

What is LimitRange?

In Kubernetes, a LimitRange is a resource that sets default resource requests and limits for containers in a specific namespace. It allows cluster administrators to:

Set default resource requests and limits for containers if they are not specified by the user.
Prevent users from creating containers that exceed certain resource limits.
Ensure fair resource distribution within a namespace and prevent resource starvation or hogging.

Use Cases for LimitRange

Prevent resource overuse: By setting CPU and memory limits, you can prevent runaway containers that consume excessive resources.
Enforce resource policies: Set upper and lower bounds for resources to align with your organization's resource allocation policies.
Define defaults: If a container doesn't specify resource requests or limits, Kubernetes will use the default values from LimitRange.

Key Concepts

Resource Request: The amount of CPU and memory a container requests from the scheduler.
Resource Limit: The maximum amount of CPU and memory a container can consume.
Default Request: A default resource request applied to containers that do not specify one.
Default Limit: A default resource limit applied to containers that do not specify one.

Example: Creating a Namespace and Applying LimitRange

Let’s go through a practical example of how to create a Namespace and apply a LimitRange to that namespace.

1. Create a Namespace

Before applying a LimitRange, we need to define the namespace where it will be applied. You can create a namespace using a manifest file or with the kubectl command.

Here's a simple YAML manifest to create a namespace named dev-namespace:

apiVersion: v1
kind: Namespace
metadata:
  name: dev-namespace

To apply this manifest, save it as namespace.yaml and run:

kubectl apply -f namespace.yaml

2. Define the LimitRange

Now that we have the namespace, we can create a LimitRange that sets default CPU and memory requests and limits for any container running in the dev-namespace.

Here’s an example of a LimitRange manifest:

apiVersion: v1
kind: LimitRange
metadata:
  name: resource-limits
  namespace: dev-namespace
spec:
  limits:
  - max:
      cpu: "500m"
      memory: "1Gi"
    min:
      cpu: "100m"
      memory: "128Mi"
    default:
      cpu: "200m"
      memory: "512Mi"
    defaultRequest:
      cpu: "200m"
      memory: "256Mi"
    type: Container

Explanation:

max: The maximum amount of CPU (500m, or 0.5 CPUs) and memory (1Gi, 1 GiB) that containers can use in the namespace.
min: The minimum amount of CPU (100m) and memory (128Mi) that must be requested by containers.
default: The default CPU (200m) and memory (512Mi) that will be applied to containers that do not specify these values.
defaultRequest: The default CPU (200m) and memory (256Mi) that will be requested by containers if not explicitly set.
type: Specifies that the limit range applies to containers.

To apply this LimitRange, save the YAML file as limitrange.yaml and run:

kubectl apply -f limitrange.yaml

3. Verify the LimitRange

After applying the LimitRange, you can verify that it has been successfully created in the dev-namespace:

kubectl get limitrange -n dev-namespace

This should show the resource-limits LimitRange applied to the namespace.

4. Create a Pod that Exceeds Limits

Now let’s create a pod within the dev-namespace that does not specify resource requests or limits. This pod will automatically inherit the defaults defined in the LimitRange.

Create a pod.yaml file:

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
  namespace: dev-namespace
spec:
  containers:
  - name: example-container
    image: nginx

Apply this file with:

kubectl apply -f pod.yaml

The pod will be created, and Kubernetes will apply the default CPU and memory values from the LimitRange, which in this case are 200m CPU and 512Mi memory for the container.

5. Create a Pod that Violates the Limits

Let’s now create a pod that violates the defined limits. For example, we might try to create a pod that requests more memory than the maximum allowed by the LimitRange.

Here’s an example pod.yaml that tries to allocate more memory than the defined max:

apiVersion: v1
kind: Pod
metadata:
  name: invalid-pod
  namespace: dev-namespace
spec:
  containers:
  - name: invalid-container
    image: nginx
    resources:
      requests:
        memory: "2Gi"
      limits:
        memory: "2Gi"

If you apply this manifest:

kubectl apply -f pod.yaml

Kubernetes will reject the pod creation because the memory request and limit exceed the maximum memory defined in the LimitRange (which is 1Gi).

Conclusion

Kubernetes LimitRange is an important feature for controlling resource usage at the namespace level. It helps maintain a balance between resource efficiency and fairness in multi-tenant environments. By setting default requests and limits, you can ensure that containers don’t consume too many resources or go underutilized, leading to more predictable and manageable workloads.

Key Takeaways:

LimitRange helps you set default resource requests and limits for containers in a namespace.
It enables you to define maximum and minimum resource boundaries for containers.
By using LimitRange, you can ensure that containers do not exceed specified resource limits and can manage resources efficiently within your cluster.

If you’re managing Kubernetes at scale, understanding and using LimitRange will help you enforce resource policies and maintain a healthy cluster environment.

Understanding Namespaces in Kubernetes: Imperative vs Declarative Approaches & Resources Not Specific to Namespaces

Manikanta — Fri, 08 Nov 2024 07:17:32 +0000

In the world of Kubernetes (K8s), namespaces are an essential concept for managing and organizing resources within a cluster. Whether you're managing a small development environment or a large-scale production system, namespaces provide a way to isolate and group related objects for better organization, access control, and resource management.

In this blog, we'll take a deep dive into Kubernetes namespaces, exploring their use cases, comparing imperative vs. declarative approaches for managing resources, and discussing which resources are not bound to a specific namespace.

What Are Namespaces in Kubernetes?

In Kubernetes, a namespace is a logical partition of a cluster that allows you to group resources. Namespaces help you organize objects like pods, services, deployments, and configmaps, providing a way to manage resources effectively in multi-tenant environments. They offer isolation between different applications, teams, or environments within the same cluster.

For example, you can use namespaces to:

Isolate production and development environments.
Segment resources by team or project.
Manage resource quotas and access control on a per-namespace basis.
Simplify security policies and networking between isolated environments.

By default, Kubernetes includes several built-in namespaces:

default: The default namespace for resources that are not assigned a specific namespace.
kube-system: The namespace for Kubernetes system components like controllers, services, and DNS.
kube-public: A namespace that is readable by all users (including unauthenticated users), commonly used for public resources like cluster information.
kube-node-lease: For managing node lease data to improve performance and reliability.

Namespace Usage Example

Imagine you have a Kubernetes cluster used by multiple teams. You might have:

A dev namespace for development workloads.
A prod namespace for production services.
A qa namespace for testing.

Each namespace can have its own set of resources (e.g., deployments, pods, services) without interfering with other namespaces.

Imperative vs Declarative Approaches in Kubernetes

When working with Kubernetes resources (including namespaces), you generally have two approaches to managing your resources: imperative and declarative. Each approach has its own benefits and trade-offs, and the choice depends on your operational needs and environment.

Imperative Approach

In the imperative approach, you directly issue commands to Kubernetes to create, update, or delete resources. This approach is often quick and simple for tasks that need immediate effect but can become cumbersome when managing large, complex configurations.

Example of Imperative Commands

# Create a namespace using an imperative command
kubectl create namespace dev

# Create a deployment in the "dev" namespace
kubectl run myapp --image=nginx --namespace=dev

In this approach, you're instructing Kubernetes directly to perform a specific action. While it’s useful for quick tasks or one-off changes, it doesn’t provide an easy way to track or manage configurations over time.

Advantages:

Quick and easy for single, ad-hoc changes.
Best suited for one-off tasks or during experimentation.
Ideal for quick troubleshooting and debugging.

Disadvantages:

Less reproducible: Hard to track changes or manage configurations in the long run.
Lacks version control: Difficult to know what exactly was changed over time.

Declarative Approach

The declarative approach involves defining your desired state of the system in configuration files (typically YAML or JSON), and then applying these configurations to Kubernetes using commands like kubectl apply. With declarative management, you describe what you want to happen (desired state), and Kubernetes ensures that the actual state matches that description.

Example of Declarative Commands

# namespace.yaml: Define the desired namespace in a YAML file
apiVersion: v1
kind: Namespace
metadata:
  name: dev
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
  namespace: dev
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: nginx
        image: nginx

# Apply the declarative configuration to create resources
kubectl apply -f namespace.yaml

Advantages:

Declarative configurations are version-controlled and easy to maintain.
Supports infrastructure-as-code principles, allowing reproducibility and consistency.
Easier to track changes, roll back, and collaborate with others.
Kubernetes takes care of managing the resources, ensuring they match the defined state.

Disadvantages:

May take more time to set up than imperative commands.
Requires maintaining YAML or JSON files for configurations.

Which Kubernetes Resources Are Not Specific to Namespaces?

While many resources in Kubernetes are namespace-scoped, there are certain resources that exist outside of any namespace. These resources are considered cluster-wide and are not confined to a specific namespace.

Cluster-Wide Resources in Kubernetes

1.Nodes

Nodes are the physical or virtual machines that run your workloads in Kubernetes. They are part of the overall cluster and are not tied to any specific namespace.

   kubectl get nodes

2.Persistent Volumes (PV)

Persistent Volumes represent physical storage in the cluster and are managed at the cluster level. While Persistent Volume Claims (PVCs) are namespace-scoped, the Persistent Volume (PV) itself is not.

   kubectl get pv

3.ClusterRole & ClusterRoleBinding

ClusterRoles define a set of permissions that apply to the whole cluster, regardless of namespaces. Similarly, ClusterRoleBindings grant these permissions to users or service accounts.

   kubectl get clusterrole
   kubectl get clusterrolebinding

4.Namespaces (themselves)

Interestingly, the Namespace resource is not contained within another namespace. It is a cluster-wide resource that defines a logical partitioning of the cluster.

   kubectl get namespaces

5.Custom Resource Definitions (CRDs)

CRDs are used to define custom resources in Kubernetes, but the CRD itself is a cluster-wide resource. Instances of custom resources created using CRDs, however, are namespace-scoped.

   kubectl get crd

6.API Aggregator Resources (API Services)

These are part of the Kubernetes API aggregation layer, which allows external APIs to be exposed to the Kubernetes cluster. They are not tied to a specific namespace.

   kubectl get apiservices

7.Service Accounts

While Service Accounts are typically namespace-scoped, Cluster-wide Service Accounts are part of the control plane, giving access to cluster-wide services.

Conclusion

Namespaces in Kubernetes provide an essential mechanism for organizing and managing cluster resources, particularly in multi-tenant environments. They offer isolation and effective resource management, allowing you to segment workloads based on teams, applications, or environments.

When managing resources in Kubernetes, you can choose between an imperative approach for quick, ad-hoc changes or a declarative approach for long-term, consistent management. While imperative commands are helpful for troubleshooting or experimenting, the declarative approach provides a more scalable and reproducible method for infrastructure management.

Finally, while most Kubernetes resources are tied to namespaces, certain key resources (like nodes, persistent volumes, and cluster roles) exist at the cluster level, not bound to any namespace.

By understanding how namespaces work and the difference between imperative and declarative management, you can better organize and control your Kubernetes environment to meet your operational needs.

Understanding Kubernetes Requests and Limits: A Simple Guide

Manikanta — Fri, 08 Nov 2024 06:46:40 +0000

Kubernetes is a powerful container orchestration platform, widely used for deploying and managing applications. One of the key features that makes Kubernetes flexible and efficient is the ability to set resource requests and limits for containers. But what do these terms mean, and why are they important?

In this blog post, we'll break down what requests and limits are, why they matter, and how you can use them to optimize your Kubernetes deployments.

What are Kubernetes Requests and Limits?

When you deploy a containerized application in Kubernetes, each container needs access to system resources like CPU and memory (RAM). Kubernetes lets you define the amount of CPU and memory a container can use. This is done through requests and limits.

Requests: This is the amount of resources that Kubernetes will guarantee for a container. When you set a request, you are telling Kubernetes, "I need at least this amount of CPU or memory to run the container." The scheduler uses the request values to decide which node in the cluster should run the container.
Limits: This is the maximum amount of resources that the container can use. If the container tries to use more resources than the limit, Kubernetes will intervene. For CPU, it might throttle the container's CPU usage, and for memory, it could terminate the container (kill it) and possibly restart it.

Why Do Requests and Limits Matter?

Setting requests and limits correctly helps ensure that your applications run smoothly and efficiently. Here are some of the key reasons why they matter:

Resource Efficiency: By setting both requests and limits, you ensure that your containers don't use more resources than they need, which can help optimize the usage of cluster resources and prevent bottlenecks.
Fair Resource Distribution: If you don’t set resource limits, one container could consume all available CPU or memory on a node, starving other containers of the resources they need. With limits, Kubernetes ensures that no container can monopolize the node’s resources.
Preventing Resource Exhaustion: Without limits, you could accidentally over-allocate resources to a container, causing other workloads to suffer. If you set proper limits, Kubernetes can protect your application from consuming excessive resources.
Avoiding Unexpected Container Failures: Setting memory limits is especially important because if a container exceeds its memory limit, Kubernetes will kill the container, thinking it is a misbehaving process. This helps avoid the situation where a container runs indefinitely out of control and potentially crashes the node.

How to Set Requests and Limits

To define requests and limits for CPU and memory, you specify them in your Pod's configuration YAML file. Here’s an example:

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: example-container
    image: nginx
    resources:
      requests:
        memory: "64Mi"  # 64 MiB of memory guaranteed
        cpu: "250m"     # 250 milliCPU (0.25 of a CPU core) guaranteed
      limits:
        memory: "128Mi" # 128 MiB of memory maximum
        cpu: "500m"     # 500 milliCPU (0.5 of a CPU core) maximum

Key Points:

Requests are defined under requests, and they specify the minimum amount of resources the container needs.
Limits are defined under limits, and they specify the maximum amount of resources the container can use.

Understanding CPU and Memory Units

CPU is measured in millicores (m). For example:
- 1 CPU is represented as 1000m or 1, which means 1 full CPU core.
- 500m means half of a CPU core.
- 250m means a quarter of a CPU core.
Memory is measured in units like:
- Mi (mebibytes), which is 1024 * 1024 bytes, and is more accurate for containerized applications.
- Gi (gibibytes), which is 1024 MiB or approximately 1.07 GB.
- For example: 64Mi means 64 mebibytes of memory.

What Happens When a Container Exceeds Its Limits?

CPU: If the container uses more CPU than its limit, Kubernetes will throttle the container’s CPU usage. This means that it will not be allowed to exceed the allocated CPU time, which could slow down the container but won’t kill it.
Memory: If the container exceeds its memory limit, Kubernetes will terminate the container and possibly restart it. This is because excessive memory usage is often a sign of a memory leak or a misbehaving process, and Kubernetes tries to protect the node’s stability.

Best Practices for Requests and Limits

To make the most of Kubernetes' resource management features, here are some best practices to follow:

Set Requests and Limits for Every Container: It's a good practice to always set both requests and limits for your containers. Without them, Kubernetes may not be able to schedule your pods efficiently or might overcommit the resources, causing instability.
Use Realistic Values: Don’t set requests and limits too high or too low. If you set them too low, your container may not have enough resources to run properly. If you set them too high, you might waste cluster resources, leaving less for other workloads.
Monitor and Adjust: Kubernetes doesn’t provide a one-size-fits-all solution. It's important to monitor the performance of your pods and adjust the resource values accordingly. Over time, you’ll get a better sense of the resources your application really needs.
Use Resource Requests to Control Pod Scheduling: Use resource requests to control pod scheduling, ensuring that your application is scheduled on nodes with enough resources to handle it.
Consider Vertical Pod Autoscaling (VPA): If you are unsure about the right values for requests and limits, you can use Kubernetes Vertical Pod Autoscaler (VPA), which adjusts resource requests and limits for your containers based on historical usage.

Conclusion

Kubernetes requests and limits are powerful tools to ensure that your containerized applications are both resource-efficient and resilient. By setting both minimum (requests) and maximum (limits) resource values, you can ensure that your containers get the resources they need while preventing them from consuming too much and affecting other workloads in your cluster.

Remember to always monitor your containers’ resource usage and adjust these values as needed to keep your Kubernetes cluster running smoothly.

Liveness, Readiness, and Startup Probes in Kubernetes: What You Need to Know

Manikanta — Fri, 08 Nov 2024 06:29:22 +0000

In Kubernetes, probes are used to check the health and readiness of containers running in a pod. Probes allow Kubernetes to manage the lifecycle of a pod by ensuring that containers are running properly, and if not, take appropriate actions such as restarting the container or removing it from service until it’s ready.

There are three main types of probes in Kubernetes:

1. Liveness Probe
Purpose: Determines if a container is still running and healthy.
If the liveness probe fails, Kubernetes will restart the container. This is useful for detecting situations where the application has hung or is in an unresponsive state.
Example scenario: A web server that is serving traffic but is unable to process new requests due to a deadlock or resource exhaustion.
2. Readiness Probe
Purpose: Determines if the container is ready to accept traffic.
If the readiness probe fails, the container will not receive traffic from the Kubernetes Service (it will be removed from the Service endpoint list until it becomes ready).
This is helpful when a container needs some time to initialize or warm up before it starts serving requests (e.g., loading large datasets, performing migrations).
3. Startup Probe
Purpose: Determines whether a container has started successfully.
If the startup probe fails, Kubernetes will kill the container and try to restart it. It’s useful for containers that need extra time to initialize or are slow to start.
This probe is typically used for applications that require more time than usual for startup before the readiness or liveness checks should be performed

Each of these probes is highly configurable and can be defined using three main options:

1. HTTP GET Probe
2. TCP Socket Probe
3. Exec Probe

Let’s dive into each of these options and how they can be configured.

1. HTTP GET Probe
The HTTP GET Probe sends an HTTP GET request to a specific path on a container’s port to check if the container is healthy. This is the most common type of probe for web-based applications or services.

How It Works:

Kubernetes will make an HTTP request to the specified path and port inside the container.
If the server responds with a 2xx or 3xx HTTP status code, the probe is considered successful.
If the server responds with a non-successful status code (e.g., 4xx, 5xx), the probe is considered failed.

Example :

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 10
  timeoutSeconds: 2
  failureThreshold: 3

path: The URL path that the probe will try to access (e.g., /healthz).
port: The port to reach inside the container (e.g., 8080).
initialDelaySeconds: The initial wait time before performing the first probe, in seconds.
periodSeconds: The interval between each probe, in seconds.
timeoutSeconds: How long to wait for a response before timing out, in seconds.
failureThreshold: The number of consecutive failures before marking the container as unhealthy.

When to Use:

Suitable for web servers, APIs, or any container running an HTTP-based service.
Ideal for containers that expose health or readiness endpoints.

2. TCP Socket Probe
The TCP Socket Probe checks whether a TCP socket is open on a given port in the container. This is particularly useful for non-HTTP-based services like databases, message brokers, or custom network services.

How It Works:

Kubernetes attempts to open a TCP connection to the specified port inside the container.
If the connection is successful (i.e., the port is open), the probe passes.
If the connection cannot be established (i.e., the port is closed), the probe fails.

Example :

readinessProbe:
  tcpSocket:
    port: 3306
  initialDelaySeconds: 5
  periodSeconds: 10
  timeoutSeconds: 3
  failureThreshold: 3

port: The TCP port that Kubernetes should attempt to connect to (e.g., 3306 for MySQL).
initialDelaySeconds: The number of seconds to wait after the container starts before performing the first probe.
periodSeconds: How often to check the socket, in seconds.
timeoutSeconds: How long to wait for a response before timing out, in seconds.
failureThreshold: The number of failed probes before the container is marked unhealthy.

When to Use:

Suitable for services that do not use HTTP, like databases (MySQL, PostgreSQL) or message queues (Kafka, Redis).
Useful for containers that expose raw network services without HTTP endpoints.

3. Exec Probe
The Exec Probe runs a command inside the container and checks its exit status to determine if the probe is successful. If the command returns a 0 exit status, the probe passes. If it returns a non-zero exit status, the probe fails.

How It Works:
Kubernetes runs the specified command inside the container.
If the command’s exit code is 0, the probe is successful.
If the exit code is non-zero, the probe fails.

Example:

startupProbe:
  exec:
    command:
      - "cat"
      - "/tmp/healthy"
  initialDelaySeconds: 10
  periodSeconds: 15
  failureThreshold: 3

command: The command to run inside the container, specified as a list of strings (e.g., cat /tmp/healthy).
initialDelaySeconds: The number of seconds to wait after the container starts before performing the first probe.
periodSeconds: How often to run the command, in seconds.
failureThreshold: The number of consecutive failures before marking the container as unhealthy.

When to Use:

Suitable for cases where you need to check internal states or files in the container.
Useful for debugging or complex health checks that require running specific scripts or commands inside the container.

Additional Probe Configuration Options

In addition to defining the probe type (httpGet, tcpSocket, or exec), you can also configure several timing-related parameters to fine-tune how Kubernetes performs the probes:

initialDelaySeconds: The time to wait after the container starts before performing the first probe. This is helpful when your application needs time to initialize.
periodSeconds: The frequency at which Kubernetes will perform the probe. This controls how often the system checks the container's health or readiness.
timeoutSeconds: The amount of time Kubernetes should wait for a probe to respond before considering it a failure.
failureThreshold: The number of consecutive probe failures that Kubernetes will tolerate before considering the container unhealthy.
successThreshold: The number of consecutive successful probes required to consider the container healthy. (Default is 1 for liveness and readiness probes, and typically used for readiness checks.)

A Comprehensive Guide to Dockerfile Creation with Explanation of Key Commands

Manikanta — Thu, 07 Nov 2024 14:28:06 +0000

Dockerfiles are essential for creating Docker images, which serve as the foundation for containers. These files contain a series of instructions that define the environment in which your application runs. By using a Dockerfile, you ensure your application behaves the same way regardless of where it’s deployed.

Key Dockerfile Instructions and Their Usage

1. FROM – The Base Image
The FROM instruction sets the base image for your Docker image. Every Dockerfile starts with FROM, as it specifies the starting point for your image.

Example:

FROM node:14

This tells Docker to use the official node:14 image as the base for your image.

2. `RUN` – Execute Commands

The RUN command is used to execute commands inside the image during the build process. This is typically used to install dependencies or update the image.

Example:

RUN apt-get update && apt-get install -y curl

This will update the package lists and install curl in your image.

3. `MAINTAINER` – Image Maintainer Information (Deprecated)

The MAINTAINER instruction was originally used to define the author of the image. However, it’s now deprecated, and it’s recommended to use the LABEL instruction instead for this purpose.

Example:

MAINTAINER John Doe <johndoe@example.com>

4. `LABEL` – Metadata

The LABEL instruction adds metadata to an image in the form of key-value pairs. This is useful for providing details about the image, like its version, description, or maintainer.

Example:

LABEL maintainer="John Doe <johndoe@example.com>"
LABEL version="1.0"

5. `ADD` – Add Files with Extra Features

The ADD command is used to copy files from your host machine into the container. It also has extra features such as the ability to unpack .tar files or download files from a URL.

Example:

ADD source.tar.gz /app/

This will copy source.tar.gz from the host and extract it into the /app/ directory in the container.

6. `COPY` – Copy Files or Directories

COPY works similarly to ADD, but it doesn't have the extra functionality (like automatic extraction of .tar files) and is considered more predictable. You use COPY to copy files or directories into the image.

Example:

COPY . /app/

This will copy everything from the current directory on your host machine into the /app/ directory in the container.

7. `VOLUME` – Create Mount Points

The VOLUME command creates a mount point for volumes, which can be used to persist data in a container or share data between containers.

Example:

VOLUME ["/data"]

This will create a mount point /data, allowing data to persist even if the container is stopped or deleted.

8. `EXPOSE` – Expose Ports

The EXPOSE command informs Docker that the container will listen on specific ports at runtime. It doesn’t actually publish the port, but it serves as a hint for those who want to map ports when running the container.

Example:

EXPOSE 8080

This will expose port 8080 on the container, signaling that the container is ready to communicate over this port.

9. `WORKDIR` – Set Working Directory

WORKDIR sets the working directory for subsequent instructions like RUN, CMD, ENTRYPOINT, COPY, etc. If the directory doesn’t exist, it will be created.

Example:

WORKDIR /app

This sets /app as the working directory for the following commands.

10. `USER` – Set User for Container

The USER command sets the user and group to use when running commands inside the container. By default, Docker runs commands as the root user, but it's good practice to specify a non-root user for security.

Example:

USER node

This sets the user to node when running subsequent commands in the Dockerfile.

11. `STOPSIGNAL` – Define Stop Signal

The STOPSIGNAL instruction sets the system call signal that will be used to stop the container. By default, Docker uses SIGTERM, but you can specify another signal.

Example:

STOPSIGNAL SIGINT

This will use the SIGINT signal to stop the container instead of the default SIGTERM.

12. `ENTRYPOINT` – Set the Entry Point

The ENTRYPOINT command defines the default application that gets executed when a container starts. It’s often used in combination with CMD.

Example:

ENTRYPOINT ["node", "server.js"]

This will run node server.js as the entry point when the container starts.

13. `CMD` – Provide Default Arguments

CMD specifies the default command to run when the container is started. It can be overridden when running the container.

Example:

CMD ["npm", "start"]

This will run npm start by default, unless the command is overridden.

Note: If both ENTRYPOINT and CMD are used together, CMD provides the default arguments for the ENTRYPOINT command.

14. `ENV` – Set Environment Variables

The ENV instruction is used to set environment variables that will be available to the running container.

Example:

ENV NODE_ENV production

This sets the NODE_ENV environment variable to production inside the container.

Putting It All Together: A Complete Dockerfile Example

Now that we’ve covered the essential instructions, let’s create a Dockerfile for a basic Node.js application using many of the instructions discussed:

Example Dockerfile:

# Step 1: Set the base image
FROM node:14

# Step 2: Set the maintainer and other metadata
LABEL maintainer="John Doe <johndoe@example.com>"
LABEL version="1.0"
LABEL description="A simple Node.js app container"

# Step 3: Set the working directory inside the container
WORKDIR /app

# Step 4: Copy package.json and package-lock.json
COPY package*.json ./

# Step 5: Install dependencies
RUN npm install

# Step 6: Copy the rest of the application code
COPY . .

# Step 7: Expose the port the app will run on
EXPOSE 3000

# Step 8: Set the environment variable
ENV NODE_ENV production

# Step 9: Set the default command to run the app
ENTRYPOINT ["node", "server.js"]

# Step 10: Optionally, set the default command arguments (overridden by docker run arguments)
CMD ["start"]

# Step 11: Create a volume to persist data
VOLUME ["/data"]

# Step 12: Set the user to run as non-root
USER node

# Step 13: Define the stop signal for the container
STOPSIGNAL SIGINT

Explanation of the Example:

FROM: We're using the official node:14 image as the base.
LABEL: Metadata is added for versioning and maintainer information.
WORKDIR: All subsequent commands will execute in the /app directory.
COPY: First, we copy package.json to install dependencies, then copy the application code.
RUN: Installs Node.js dependencies using npm install.
EXPOSE: Exposes port 3000 to allow communication with the outside world.
ENV: Sets the NODE_ENV to production.
ENTRYPOINT: Defines the main application start command.
CMD: Provides default arguments to the entrypoint command (in this case, start).
VOLUME: Creates a volume at /data for data persistence.
USER: Switches to the node user for better security.
STOPSIGNAL: Sets SIGINT as the stop signal, which is often used for graceful shutdowns.

Conclusion

Dockerfiles provide a powerful and flexible way to automate the creation of Docker images, ensuring that your applications are portable, reproducible, and easy to deploy. By understanding each Dockerfile instruction like FROM, RUN, LABEL, COPY, ENTRYPOINT, CMD, and others, you can build optimized, secure, and scalable images for your applications.

Top 10 Docker Commands Every Developer Should Know [Chapter 1]

Manikanta — Tue, 05 Nov 2024 03:50:26 +0000

Docker is a powerful tool that allows developers to automate the deployment of applications inside lightweight, portable containers. These containers package the application and its dependencies into a single unit that can run consistently across different environments. To make the most of Docker, you need to be familiar with a set of core commands that help you manage containers, images, and other resources. In this blog, we’ll explore the Top 10 Docker commands you should know to become more proficient with Docker.

1. docker --version
The first step when you're getting started with Docker is verifying its installation. You can use this command to check the installed version of Docker on your machine.

docker --version

2. docker pull
The docker pull command allows you to download Docker images from Docker Hub or other image repositories. This command pulls the specified image (in this case, ubuntu) from the default Docker registry (Docker Hub). You can pull any image, such as a specific version (ubuntu:20.04), or any public image available on Docker Hub.

docker pull ubuntu

3. docker build
The docker build command is used to create a Docker image from a Dockerfile. Here, myimage is the tag you're giving to the image, and . represents the current directory (where your Dockerfile is located). Docker reads the Dockerfile in the directory and builds the image based on the instructions inside it.

docker build -t myimage .

4. docker run
The docker run command is used to create and start a container from a specified image.

-d runs the container in detached mode (in the background).
-p 8080:80 maps port 8080 on your local machine to port 80 inside the container (useful for web apps).
- nginx is the image you're running (in this case, the Nginx web server).
- --name provide name for container

docker run -d -p 8080:80 --name <name-of-container> nginx

5. docker ps
The docker ps command shows the running containers on your system. This command lists all the containers that are currently running, showing information such as container ID, image name, status, and the ports that are exposed.

docker ps

If you want to see all containers (including stopped ones), you can use

docker ps -a

6. docker stop
The docker stop command stops a running container.You provide the container ID or name (e.g., docker stop mycontainer). This stops the specified container gracefully.

docker stop <container_id>

If you want to forcefully stop it, you can use

docker kill <container_id>

7. docker rm
After stopping a container, you may want to remove it. The docker rm command allows you to delete stopped containers. This removes the container from your system. You can remove multiple containers at once by listing their IDs separated by spaces. If you want to remove a running container, you'll need to stop it first using docker stop.

docker rm <container_id>

docker rm <container_1> <container_2> <container_3>

8. docker images
The docker images command lists all the images stored locally on your system. This shows information about the available images, such as repository, tag, image ID, creation date, and size. This command helps you keep track of the images you have locally.

docker images

9. docker rmi
The docker rmi command is used to remove Docker images. This command removes the specified image from your local system. If an image is being used by a container, you'll need to stop and remove the container before you can delete the image. You can also remove multiple images by providing their IDs in the same command.

docker rmi <image_id>

10. docker exec
The docker exec command is used to run a command inside a running container.This allows you to start an interactive Bash shell inside a running container. The -it flags stand for interactive (-i) and pseudo-TTY (-t), which together allow you to interact with the shell. This is especially useful for debugging or managing containers in real-time.

docker exec -it <container_id> bin/bash

Conclusion
Mastering these 10 essential Docker commands will help you become more comfortable working with Docker containers and images. As you continue to explore Docker, you'll likely come across more advanced commands and features, but understanding the basics is crucial for building a solid foundation.

By using these commands, you can manage images, containers, and other Docker resources, helping you streamline development workflows, automate testing, and deploy applications more efficiently.

See you in Chapter 2

Top 20 Kubernetes Commands You Should Know [Chapter 1]

Manikanta — Mon, 04 Nov 2024 16:43:20 +0000

Kubernetes (K8s) is a powerful platform for managing containerized applications. Familiarity with essential Kubernetes commands can significantly improve your productivity and help you troubleshoot issues more effectively. Below, we’ll cover 20 of the most important Kubernetes commands, along with simple explanations.

1.kubectl get
Use this command to list resources. You can specify the resource type (like pods, services, deployments) to get a concise view of what's running.

kubectl get pods

2.kubectl describe
This command provides detailed information about a specific resource, including events, status, and configuration.

kubectl describe pod <pod-name>

3.kubectl create
Use this command to create a resource from a file or directly in the command line.

kubectl create -f <file.yaml>

4.kubectl apply
This command updates a resource by applying changes from a file. It can create the resource if it doesn't exist.

kubectl apply -f <file.yaml>

5.kubectl delete
Use this command to delete a resource. You can specify the resource type and name.

kubectl delete pod <pod-name>

6.kubectl logs
This command retrieves logs from a specified pod, which is useful for debugging.

kubectl logs <pod-name>

7.kubectl exec
Use this command to execute a command inside a running container within a pod.

kubectl exec -it <pod-name> -- /bin/bash

8.kubectl port-forward
This command allows you to forward a local port to a port on a pod, which is useful for accessing services locally.

kubectl port-forward <pod-name> <local-port>:<pod-port>

9.kubectl scale
Use this command to scale a deployment up or down by specifying the desired number of replicas.

kubectl scale deployment <deployment-name> --replicas=<number>

10.kubectl rollout
This command manages the rollout of a resource, such as deploying a new version or rolling back to a previous version.

kubectl rollout status deployment <deployment-name>

11.kubectl get nodes
This command lists all the nodes in your Kubernetes cluster, showing their status and roles.

kubectl get nodes

12.kubectl get services
Use this command to list all services in the cluster, which helps you understand how different parts of your application communicate.

kubectl get services

13.kubectl get deployments
This command lists all deployments, providing an overview of your application’s desired state.

kubectl get deployments

14.kubectl top
This command shows resource usage (CPU and memory) of nodes or pods, which is helpful for monitoring performance.

kubectl top pods

15.kubectl config
This command allows you to modify kubeconfig settings, such as changing the current context.

kubectl config current-context

16.kubectl namespace
Use this command to manage namespaces in your Kubernetes cluster, which helps organize resource

kubectl create namespace <namespace-name>

17.kubectl cp
This command copies files between your local filesystem and a pod.

kubectl cp <local-file-path> <pod-name>:<remote-file-path>

18.kubectl get events
This command lists events in your cluster, which can help you diagnose issues by showing what’s happening behind the scenes.

kubectl get events

19.kubectl edit
Use this command to edit a resource in your default editor, allowing for quick changes without creating a new file.

kubectl edit deployment <deployment-name>

20.kubectl api-resources
This command lists all API resources available in your Kubernetes cluster, helping you discover new types you might want to use.

kubectl api-resources

Conclusion
Understanding these Kubernetes commands will enhance your ability to manage and troubleshoot your applications in a Kubernetes environment. Whether you’re a beginner or an experienced user, these commands are vital for navigating the complexities of container orchestration. Happy K8s-ing!

DEV Community: Manikanta

Kubernetes Resource Quotas and Limit Ranges with Namespaces

What is a Namespace in Kubernetes?

What is a Resource Quota?

Key Properties of a ResourceQuota:

Example: Resource Quota Manifest

What is a LimitRange?

Key Properties of a LimitRange:

Example: LimitRange Manifest

How ResourceQuota and LimitRange Work Together

Practical Use Cases

Conclusion

Understanding LimitRange in Kubernetes: A Guide with Examples

What is LimitRange?

Use Cases for LimitRange

Key Concepts

Example: Creating a Namespace and Applying LimitRange

1. Create a Namespace

2. Define the LimitRange

Explanation:

3. Verify the LimitRange

4. Create a Pod that Exceeds Limits

5. Create a Pod that Violates the Limits

Conclusion

Key Takeaways:

Understanding Namespaces in Kubernetes: Imperative vs Declarative Approaches & Resources Not Specific to Namespaces

What Are Namespaces in Kubernetes?

Namespace Usage Example

Imperative vs Declarative Approaches in Kubernetes

Imperative Approach

Example of Imperative Commands

Advantages:

Disadvantages:

Declarative Approach

Example of Declarative Commands

Advantages:

Disadvantages:

Which Kubernetes Resources Are Not Specific to Namespaces?

Cluster-Wide Resources in Kubernetes

Conclusion

Understanding Kubernetes Requests and Limits: A Simple Guide

What are Kubernetes Requests and Limits?

Why Do Requests and Limits Matter?

How to Set Requests and Limits

Key Points:

Understanding CPU and Memory Units

What Happens When a Container Exceeds Its Limits?

Best Practices for Requests and Limits

Conclusion

Liveness, Readiness, and Startup Probes in Kubernetes: What You Need to Know

A Comprehensive Guide to Dockerfile Creation with Explanation of Key Commands

2. RUN – Execute Commands

3. MAINTAINER – Image Maintainer Information (Deprecated)

4. LABEL – Metadata

5. ADD – Add Files with Extra Features

6. COPY – Copy Files or Directories

7. VOLUME – Create Mount Points

8. EXPOSE – Expose Ports

9. WORKDIR – Set Working Directory

10. USER – Set User for Container

11. STOPSIGNAL – Define Stop Signal

12. ENTRYPOINT – Set the Entry Point

13. CMD – Provide Default Arguments

14. ENV – Set Environment Variables

Putting It All Together: A Complete Dockerfile Example

Example Dockerfile:

Explanation of the Example:

Conclusion

Top 10 Docker Commands Every Developer Should Know [Chapter 1]

Top 20 Kubernetes Commands You Should Know [Chapter 1]

2. `RUN` – Execute Commands

3. `MAINTAINER` – Image Maintainer Information (Deprecated)

4. `LABEL` – Metadata

5. `ADD` – Add Files with Extra Features

6. `COPY` – Copy Files or Directories

7. `VOLUME` – Create Mount Points

8. `EXPOSE` – Expose Ports

9. `WORKDIR` – Set Working Directory

10. `USER` – Set User for Container

11. `STOPSIGNAL` – Define Stop Signal

12. `ENTRYPOINT` – Set the Entry Point

13. `CMD` – Provide Default Arguments

14. `ENV` – Set Environment Variables