Welcome to Royfactory

Kubernetes CronJob Guide: Schedule and Automate Batch Jobs Kubernetes CronJob allows you to schedule jobs for automated recurring tasks, similar to crontab in Linux. Whether it’s daily database backups, hourly log cleanups, or periodic alerts, CronJobs are a powerful way to automate jobs in a Kubernetes cluster. Table of Contents {% toc %} 1. What is a Kubernetes CronJob? A CronJob in Kubernetes is a controller that runs Jobs on a time-based schedule. It uses cron format to define when the job should be created, and handles the job execution just like a normal Job resource. ...

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 # Kubernetes Secret Guide: Secure Storage and Management of Sensitive Data Kubernetes **Secrets** allow you to store and manage sensitive information like passwords, API keys, and TLS certificates securely inside your cluster. Rather than embedding these values directly into your application code or Pod specs, you can manage them as separate resources and control their access with RBAC. --- ## Table of Contents {% toc %} --- ## 1. What Is a Secret? A **Secret** in Kubernetes stores **confidential key-value pairs**. These values are **Base64-encoded** and stored in `etcd`. You can inject Secrets into Pods as **environment variables** or **mounted files**. > Important: Base64 is not encryption — it’s only encoding. To protect against data exposure, you should enable **encryption at rest** in Kubernetes. --- ## 2. Why Use Secrets Instead of Hardcoding? Hardcoding sensitive data in Deployment YAML or application code has serious drawbacks: * **Security risk**: Anyone with access to your code or manifests can see credentials. * **Difficult rotation**: Changing credentials requires editing multiple files. * **Audit challenges**: No clear record of who accessed or changed secrets. Secrets address these issues by providing: * Centralized sensitive data management. * Controlled access with **RBAC**. * Separation of configuration from code. --- ## 3. Secret vs ConfigMap | Feature | ConfigMap | Secret | | ----------- | --------------------------- | --------------------------------------- | | Purpose | Non-sensitive configuration | Sensitive data | | Storage | Plain text | Base64 encoded | | Security | Low | Higher (can enable encryption) | | Example Use | App settings, URLs | Passwords, API tokens, TLS certificates | --- ## 4. Key Features of Secrets * **Centralized secure storage** for sensitive values. * **Multiple injection options**: Environment variables or mounted volumes. * **RBAC integration** to control who can access secrets. * **Support for custom types** for specialized use cases. * **Extensibility**: Works with tools like HashiCorp Vault, Sealed Secrets, or External Secrets Operator. --- ## 5. Secret Types | Type | Description | Use Case Example | | -------------------------------- | --------------------------------- | -------------------------------- | | `Opaque` | Default generic key-value pairs | DB credentials, API keys | | `kubernetes.io/dockerconfigjson` | Docker registry authentication | Private image pulls | | `kubernetes.io/tls` | TLS certificates and private keys | HTTPS services | | Custom | For plugins/controllers | Sealed Secrets, External Secrets | --- ## 6. Creating Secrets ### 1) Using YAML ```yaml apiVersion: v1 kind: Secret metadata: name: db-secret type: Opaque data: username: YWRtaW4= # "admin" Base64 encoded password: c2VjdXJlcGFzcw== # "securepass" Base64 encoded Base64 encoding: ...

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 # Kubernetes Job Guide: One-Time and Batch Workloads Made Easy Kubernetes **Job** is a workload resource designed for **one-time or limited-run tasks**. Unlike Deployments, Jobs are not meant for always-on services — they **run until completion** and then exit. In this guide, we’ll cover: * What a Job is and why it exists * Key features and real-world use cases * How to configure retry policies and parallelism * YAML examples for different scenarios * Operational tips and best practices --- ## Table of Contents {% toc %} --- ## 1. What Is a Kubernetes Job? A Kubernetes Job manages **finite-duration tasks** by creating Pods that run to completion. Once the task finishes successfully, the Job marks it as complete and stops creating new Pods. **Examples:** * Data migration scripts * Database backups * Generating reports * Archiving logs * Machine learning model training (single run) --- ## 2. Why Use a Job Instead of a Pod? Running a task in a Pod alone is possible but comes with limitations: | Problem with Standalone Pod | How Job Solves It | | ---------------------------- | ----------------------------- | | Pod fails → manual restart | Automatic retries | | No completion tracking | Maintains success/fail status | | Hard to manage multiple Pods | Supports parallel execution | Jobs provide **fault tolerance**, **state tracking**, and **parallel processing control** out-of-the-box. --- ## 3. Key Features | Feature | Description | | ---------------- | ----------------------------------------- | | Completion-based | Stops once the task finishes successfully | | Retry support | Automatically restarts failed Pods | | State tracking | Keeps history of successful/failed Pods | | Parallelism | Run multiple Pods at the same time | | Resource control | Allocate CPU/memory per Job run | --- ## 4. Job vs CronJob vs Deployment | Resource | Purpose | Execution Mode | End Condition | | ---------- | ------------------------ | -------------- | ------------- | | Job | One-time/limited tasks | Immediate run | On completion | | CronJob | Scheduled recurring jobs | Based on cron | On completion | | Deployment | Always-on applications | Continuous run | Manual stop | --- ## 5. Basic YAML Example ```yaml apiVersion: batch/v1 kind: Job metadata: name: data-processing-job spec: template: spec: containers: - name: data-processor image: python:3.10 command: ["python", "-c", "print('Processing data...')"] restartPolicy: OnFailure backoffLimit: 3 Key Fields: ...

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 # Kubernetes DaemonSet Guide: Deploy Pods to All Nodes In this post, we dive deep into **Kubernetes DaemonSet** — a powerful controller that ensures a specific Pod runs on **every node** (or selected nodes) in your cluster. We’ll explore: * What a DaemonSet is and why it exists * Common real-world use cases * YAML examples and best practices * Key differences from Deployment and StatefulSet * Troubleshooting and common pitfalls --- ## Table of Contents {% toc %} --- ## 1. What Is a DaemonSet? A **DaemonSet** is a Kubernetes resource that ensures **one Pod runs on every node** in a cluster. This is especially useful for cluster-wide background processes, like log collectors, system monitors, or GPU agents. ### Real-World Examples * `fluentd` or `fluentbit` for log collection * `prometheus-node-exporter` for metrics * Custom agents for backups, GPU drivers, or node configuration --- ## 2. Why Use a DaemonSet? If you want the **same Pod to run on all nodes**, a DaemonSet is the go-to solution. | Use Case | Description | | ------------------- | ------------------------------------------------- | | System monitoring | Node-level metrics collection (CPU, memory, etc.) | | Logging | Collect logs from all containers across nodes | | Node-specific setup | GPU drivers, firewall rules, or system agents | | DNS caching | Cluster-wide DNS cache (e.g., `dnsmasq`) | Unlike a Deployment, which spreads replicas across the cluster, a DaemonSet guarantees **one Pod per node**, automatically. --- ## 3. Key Features of DaemonSet | Feature | Description | | ----------------------- | ----------------------------------------------------- | | One pod per node | Ensures each node runs one instance of the Pod | | Auto-scaling with nodes | Adds/removes Pods as nodes join/leave the cluster | | Node targeting | Use `nodeSelector` or `affinity` to control placement | | Taint support | With `tolerations`, you can run Pods on tainted nodes | > Tip: DaemonSets are ideal for tasks that require full visibility across the cluster. --- ## 4. Basic DaemonSet YAML Example ```yaml apiVersion: apps/v1 kind: DaemonSet metadata: name: log-agent namespace: kube-system spec: selector: matchLabels: app: log-agent template: metadata: labels: app: log-agent spec: containers: - name: log-agent image: fluent/fluentd:latest resources: limits: memory: "200Mi" cpu: "200m" This YAML deploys a fluentd log collector to every node in the cluster, under the kube-system namespace. ...

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 # Kubernetes Deployment: Automating Pod Rollout and Updates Kubernetes **Deployment** is the go-to resource for automating the **lifecycle of Pods** — handling **initial deployment, scaling, updating, and rollback**. If you're building production-ready Kubernetes applications, you must understand how Deployments work. --- ## Table of Contents {% toc %} --- ## 1. What Is a Deployment? A **Deployment** is a higher-level abstraction over ReplicaSets. It declaratively manages: * How many Pod replicas to run * What container image to use * How to **update** and **rollback** versions automatically Think of it as the **control tower** for your Pod-based application. --- ## 2. Deployment vs ReplicaSet | Feature | ReplicaSet | Deployment | | --------------- | ------------- | -------------------------------- | | Pod Management | Manual | Declarative & automated | | Rolling Updates | Not supported | Supported (default behavior) | | Rollback | Not available | Yes, with `kubectl rollout undo` | | Usage Priority | Low | High (recommended for most use) | While ReplicaSets ensure a number of Pods run, Deployments **control what those Pods should look like and how to change them over time.** --- ## 3. Basic Deployment YAML ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: my-deployment spec: replicas: 3 selector: matchLabels: app: myapp template: metadata: labels: app: myapp spec: containers: - name: nginx image: nginx:1.21 ports: - containerPort: 80 Key Fields: ...

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 # Kubernetes ReplicaSet: Ensuring Pod Availability with Auto Recovery **Question:** *“How do I keep my Kubernetes Pods always running, even when they fail?”* The answer is ReplicaSet. In this post, we’ll explain what a **ReplicaSet** is, how it works, and when to use it. You’ll also see a complete YAML example and best practices for production use. --- ## Table of Contents {% toc %} --- ## 1. What Is a ReplicaSet? A **ReplicaSet** is a Kubernetes controller that ensures a specific number of identical **Pods are always running**. > Think of it as a Pod manager that keeps your application alive by monitoring and recreating Pods when they crash or are deleted. --- ## 2. Why Use a ReplicaSet? Let’s say your application runs in a single Pod. If that Pod crashes, your app becomes unavailable. ReplicaSet solves this problem by: * Running multiple replicas of the Pod. * Automatically replacing failed or deleted Pods. * Maintaining **high availability and reliability**. --- ## 3. Key Components | Field | Description | | ---------- | -------------------------------------- | | `replicas` | Number of Pods to maintain | | `selector` | Labels used to identify managed Pods | | `template` | Pod spec to create if Pods are missing | --- ## 4. Sample ReplicaSet YAML ```yaml apiVersion: apps/v1 kind: ReplicaSet metadata: name: my-replicaset spec: replicas: 3 selector: matchLabels: app: myapp template: metadata: labels: app: myapp spec: containers: - name: nginx image: nginx:latest ports: - containerPort: 80 Creates 3 replicas of an nginx container. Automatically recreates deleted Pods to maintain 3. 5. Basic Commands 1 2 3 kubectl apply -f replicaset.yaml kubectl get replicaset kubectl get pods -l app=myapp Try deleting one of the Pods: ...

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 # Kubernetes Deployment: Rolling Updates, Rollbacks, and Real Examples A **Kubernetes Deployment** is one of the most essential and widely used resources in the Kubernetes ecosystem. It simplifies the management of your application lifecycle — from deploying and scaling to updating and rolling back. In this post, you’ll learn: * What a Deployment is * How it differs from ReplicaSet * How to define and apply a Deployment using YAML * How Kubernetes performs rolling updates and supports rollbacks * Real-world `kubectl` commands and use cases --- ## Table of Contents {% toc %} --- ## 1. What Is a Kubernetes Deployment? A Deployment is a **higher-level controller** that manages a ReplicaSet for you. It lets you: * Run multiple identical Pods (replicas) * Update your app version automatically * Roll back if something goes wrong * Ensure your app stays available during changes In short, it’s your go-to tool for **production-grade app delivery**. --- ## 2. Deployment vs ReplicaSet | Feature | ReplicaSet | Deployment | | -------------- | --------------------- | -------------------------------------- | | Manages Pods | Yes | Yes (via ReplicaSet) | | Rolling Update | No | Yes | | Rollback | No | Yes (previous ReplicaSet is preserved) | | Use Case | Manual pod management | Declarative, versioned app management | --- ## 3. Deployment YAML Example Here’s a minimal Deployment definition: ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.21 ports: - containerPort: 80 Key fields explained: replicas: Number of desired Pods selector: How the Deployment finds Pods to manage template: The actual Pod configuration 4. Creating and Managing a Deployment Create: 1 kubectl apply -f nginx-deployment.yaml View status: 1 2 3 kubectl get deployments kubectl get rs kubectl get pods 5. Performing a Rolling Update To update the container image: ...

Kubernetes Resources: Understanding ReplicaSet Question: “How can I ensure a specific number of Pods always run in my Kubernetes cluster?” A ReplicaSet ensures that a defined number of identical Pods are running at all times. If a Pod fails or a node crashes, the ReplicaSet automatically creates a replacement, guaranteeing application availability. Table of Contents {% toc %} 1. What Is a ReplicaSet? A ReplicaSet is a Kubernetes resource that maintains a stable set of running Pods. Its primary goal is to ensure the specified number of Pod replicas (replicas) are always available. ...

Kubernetes Networking: Understanding the Network Model Question: “How do Pods, nodes, and Services communicate within a Kubernetes cluster?” Kubernetes networking is built on the network model, which defines how Pod-to-Pod, Pod-to-Service, and external-to-internal communication works. This model involves components like CNI plugins (Flannel, Calico), CoreDNS, and service discovery mechanisms. In this post, you’ll learn: The core concepts of the Kubernetes network model How Pods communicate with each other Node-to-node networking and the role of CNI plugins How Services and DNS interact with Pods Table of Contents What Is the Kubernetes Network Model? Pod-to-Pod Communication Node-to-Node Networking What Is CNI (Container Network Interface)? Services and DNS Integration Hands-On: Testing Pod Communication FAQ (Answer Engine Optimization) Key Takeaways Final Thoughts 1. What Is the Kubernetes Network Model? Kubernetes follows a simple but powerful rule: ...

Kubernetes Networking: Service Types Summary Question: “Which Kubernetes Service type should I use for my application?” In this post, we summarize the four main Service types — ClusterIP, NodePort, LoadBalancer, and ExternalName — and explain their key features, use cases, and differences. We’ll also provide a quick decision guide for choosing the right Service type. Table of Contents {% toc %} 1. Service Types Overview Type Access Scope Typical Use Case ClusterIP Internal cluster Service-to-service traffic NodePort External via Node IP Development & testing LoadBalancer External via LB Cloud-based production apps ExternalName DNS mapping External API integration 2. ClusterIP Summary Default Service type in Kubernetes. Accessible only within the cluster. Ideal for backend microservices and internal APIs. Example: ...