Welcome to Royfactory

AI Development Environment Setup: Anaconda, Jupyter, and GPU Acceleration (Lecture 4) In this lecture, we’ll set up a stable AI development environment for Machine Learning and Deep Learning projects. You’ll learn how to install Anaconda, run Jupyter Notebook, and configure GPU acceleration with CUDA and cuDNN. Table of Contents {% toc %} 1) Why Environment Setup Matters A well-configured environment prevents common issues such as: Library version conflicts Slow training due to CPU-only execution Non-reproducible results across team members Goals: ...

Deep Learning Basics: CNN vs. RNN and a Hands-On MNIST Example (Lecture 3) This is Lecture 3 of our AI 101 series. We’ll explain what Deep Learning is, compare CNNs and RNNs, and finish with a verified TensorFlow/Keras lab where you build a CNN to classify MNIST handwritten digits. Table of Contents {% toc %} 1) What Is Deep Learning? Deep Learning is a subset of Machine Learning that uses multi-layer artificial neural networks to model complex patterns in data—especially effective for images, audio, and text. ...

Machine Learning Basics: Supervised, Unsupervised, and Reinforcement Learning (Lecture 2) This is Lecture 2 of our AI 101 series. We’ll break down three core types of Machine Learning, explore their real-world applications, and finish with a verified scikit-learn lab that runs locally without internet access. Table of Contents {% toc %} 1) What Is Machine Learning? Machine Learning (ML) is the process of teaching computers to learn patterns from data and make predictions without being explicitly programmed with rules. ...

AI 101: From Concepts to a Working Example (Lecture 1) This is Lecture 1 of a 20-part series. We’ll cover what AI is, a short history, where it’s used, and finish with a hands-on lab you can run locally without any external downloads. Table of Contents {% toc %} 1) What Is AI? Artificial Intelligence (AI) enables computers to perform tasks that typically require human intelligence—learning, reasoning, perception, and language understanding. ...

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: ...