radin/my-docs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

change dir name orch,container

Browse Source
This commit is contained in:
RadinPirouz
2025-10-04 09:53:08 +03:30
parent 1c472e4b94
commit 6beeea3e5c
43 changed files with 0 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

34
Containerization-Orchestration/Docker/1-Information.md Executable file
View File

@@ -0,0 +1,34 @@
# Docker Overview
## What is Docker?
[Docker](https://www.docker.com/) is an open-source platform that streamlines the development, shipping, and deployment of applications using containers. Containers are lightweight, self-contained environments that bundle everything required to run an application, including code, runtime, libraries, and dependencies. By using Docker, developers can ensure that applications run consistently across different environments, whether in development, testing, or production.
## Core Docker Concepts
### Stateless vs. Stateful Applications
- **Stateless**: These applications do not retain user data between sessions. For example, web servers like Nginx are typically stateless, as they don’t need to save any data between requests.
- **Stateful**: These applications retain data across sessions, which means they store information that can be retrieved later. Databases are common examples of stateful applications.
## Key Docker Components
### Docker Images
A Docker image is a read-only template that defines the environment in which your application runs. It includes the application code, along with all necessary runtime components, libraries, and dependencies. Images are created using a Dockerfile—a script that automates the process of setting up the environment. Once an image is built, it can be used to create one or more containers.
### Docker Containers
A Docker container is a runnable instance of an image. It encapsulates everything the application needs to run, ensuring isolation from the host system and other containers. Containers are highly portable and can be moved across different environments without affecting their functionality. This makes them ideal for developing, testing, and deploying applications in a consistent manner.
### Dockerfile
A Dockerfile is a simple text file that contains a set of instructions for building a Docker image. These instructions specify the base image to use, the environment variables, dependencies, and commands required to assemble the application environment. By defining these steps in a Dockerfile, developers can automate the image creation process, ensuring that the application behaves the same way in every environment.
### Docker Hub
[Docker Hub](https://hub.docker.com/) is a centralized cloud-based repository service where Docker images are stored, shared, and managed. It allows developers to pull pre-built images from public repositories or to push and distribute their own images. Docker Hub simplifies the process of finding and using images created by others, fostering collaboration within the developer community.
## Conclusion
Docker revolutionizes the way applications are developed, shipped, and deployed by providing a consistent environment that works across various platforms. Through the use of containers, Docker makes applications portable, scalable, and easy to manage. Its comprehensive ecosystem of tools and services has established Docker as a critical component in modern software development pipelines, enabling faster, more reliable deployment of applications.

285
Containerization-Orchestration/Docker/2-Commands.md Executable file
View File

@@ -0,0 +1,285 @@
# **Docker Commands Guide**
## **1. Docker Data Directories**
Docker stores essential data, including images, containers, and volumes, in specific directories.
- **`/var/lib/docker/`**: Main directory for Docker's data, including images, containers, and volumes.
- **`/var/lib/docker/containers/`**: Stores configuration files for individual containers.
- **`/var/lib/docker/volumes/`**: Stores data for Docker volumes, which persist beyond the container’s lifecycle.
---
## **2. Installing Docker on Ubuntu**
### **Step 1: Update Package List and Install Dependencies**
```bash
sudo apt update && sudo apt install -y ca-certificates curl
```
- **`sudo apt update`**: Refreshes the package list.
- **`sudo apt install -y ca-certificates curl`**: Installs certificates and `curl` to securely download Docker packages.
### **Step 2: Add Docker’s GPG Key**
```bash
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc
```
- **`install -m 0755 -d /etc/apt/keyrings`**: Creates the `/etc/apt/keyrings` directory with appropriate permissions.
- **`curl -fsSL <url> -o <file>`**: Downloads Docker’s GPG key.
- **`chmod a+r`**: Grants read permissions for all users to the GPG key.
### **Step 3: Add Docker’s Official Repository**
```bash
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
```
- Adds Docker’s repository to the Apt sources list.
### **Step 4: Install Docker**
```bash
sudo apt update && sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
```
- **`docker-ce`**: Installs Docker Community Edition.
- **`docker-ce-cli`**: Docker command-line interface.
- **`containerd.io`**: Container runtime.
- **`docker-buildx-plugin`**: Provides advanced build functionality.
- **`docker-compose-plugin`**: Manages multi-container applications.
---
## **3. Docker CLI Commands**
### **3.1 Authentication**
```bash
docker login
```
- **`docker login`**: Logs into Docker Hub or a private registry by prompting for credentials.
### **3.2 Image Management**
- **Download an image:**
```bash
docker pull <repo-addr>
```
- Downloads an image from a repository.
- **List images:**
```bash
docker images
```
- Displays all available images.
- **Remove an image:**
```bash
docker rmi -f <image-id>
```
- Forcefully removes a specific image.
- **Save an image as a `.tar` file:**
```bash
docker save -o <file-location-and-name> <image-name>
```
- **Load an image from a `.tar` file:**
```bash
docker load -i <file-location>
```
### **3.3 Container Management**
- **Run a container:**
```bash
docker run <options> <image-name>
```
- **Run an interactive container with a terminal:**
```bash
docker run -it <image-name>
```
- **Run a container in detached mode:**
```bash
docker run -dit <image-name>
```
- **Set a container to always restart:**
```bash
docker run -dit --restart=always <image-name>
```
- **Name a container:**
```bash
docker run -dit --name <container-name> <image-name>
```
- **Assign a hostname:**
```bash
docker run -dit --hostname=<hostname> <image-name>
```
- **Set environment variables:**
```bash
docker run -dit -e var1=data --name <container-name> --hostname=<hostname> <image-name>
```
- **Map host and container ports:**
```bash
docker run -dit -p <host-port>:<container-port> <image-name>
```
- **Run a container with memory and CPU limits:**
```bash
docker run -dit --name nginx --memory-reservation 150m --memory 500m nginx
```
- Limits memory reservation to 150MB and usage to a maximum of 500MB.
```bash
docker run -dit --name nginx --cpus 2 --cpu-shares 100 nginx
```
- Limits the container to 2 CPUs.
- **Stream container logs in real-time:**
```bash
docker logs -f <container-name>
```
- **Access a container’s terminal:**
```bash
docker exec -it <container-name> /bin/bash
```
- **Stop a container:**
```bash
docker stop <container-name>
```
- **Remove a container:**
```bash
docker rm <container-name>
```
- **Forcefully remove a running container:**
```bash
docker rm -f <container-name>
```
- **List all container IDs (including stopped):**
```bash
docker ps -aq
```
- **Prune stopped containers:**
```bash
docker container prune
```
- **Commit a container to an image:**
```bash
docker commit <container-name> <new-image-name>
```
- **Inspect container details:**
```bash
docker inspect <container-name>
```
- **Copy files between host and container:**
```bash
docker cp <file-on-local> <container-name>:/<container-path>
```
```bash
docker cp <container-name>:/<container-path> <local-path>
```
- **View real-time container resource usage:**
```bash
docker stats
```
- **Build an image from a Dockerfile:**
```bash
docker build -t <app-name>:<app-version> <path-to-dockerfile>
```
---
## **4. Volume Management**
Volumes store data that persists even when a container is deleted.
- **List all volumes:**
```bash
docker volume ls
```
- **Create a volume:**
```bash
docker volume create <volume-name>
```
- **Inspect a volume:**
```bash
docker volume inspect <volume-name>
```
- **Mount a volume to a container:**
```bash
docker run -dit --name <container-name> -v <volume-name>:<container-path> <image-name>
```
- **Mount a file with read-only access:**
```bash
docker run -dit --name nginx -v /etc/resolv.conf:/etc/resolv.conf:ro nginx
```
- **Mount temporary filesystem in memory:**
```bash
docker run -dit --name nginx --tmpfs /opt:100M nginx
```
---
## **5. Network Management**
Docker networks allow communication between containers.
- **List all networks:**
```bash
docker network ls
```
- **Create a network:**
```bash
docker network create <network-name>
```
- **Create a custom network with subnet and gateway:**
```bash
docker network create --subnet <subnet> --gateway <gateway-ip> --driver=<network-type> <network-name>
```
- **Run a container on a specific network:**
```bash
docker run -dit --name <container-name> --network <network-name> <image-name>
```
- **Connect a running container to a network:**
```bash
docker network connect <network-name> <container-name>
```
- **Disconnect a container from a network:**
```bash
docker network disconnect <network-name> <container-name>
```
---
## **6. System Commands**
- **Show Docker Disk usage:**
```bash
docker system df
```
- **Remove Unuse Cache,Container And More**
- ```bash
- docker system prune
- ```
-
-

160
Containerization-Orchestration/Docker/3-Docker-File.md Executable file
View File

@@ -0,0 +1,160 @@
# 🚢 Understanding Dockerfile: A Complete Guide
---
## 📄 What is a Dockerfile?
A **Dockerfile** is a simple text file containing instructions to create a **Docker image**. Docker images provide a consistent, reproducible environment to run applications inside containers. By defining dependencies, configurations, and the operating system, Dockerfiles automate image creation, ensuring version-controlled and portable environments.
---
### 🔑 Key Concepts:
* 🏗️ **Base Image**: The foundational layer of your image, usually an official OS like Ubuntu, CentOS, or Alpine Linux.
* 📝 **Instructions**: Commands that tell Docker what to install, how the image behaves, and which files to include.
Common instructions include:
| Instruction | Description |
| ----------- | ---------------------------------------------------------------- |
| 🏃‍♂️ `RUN` | Executes commands inside the container (e.g., install software). |
| 📁 `COPY` | Copies files from your local machine to the image. |
| ▶️ `CMD` | Specifies the default command when the container starts. |
---
## 🛠️ Step-by-Step Guide to Creating a Dockerfile
---
### 1️⃣ Create a File Named `Dockerfile`
Create a file called `Dockerfile` in your project directory. If named differently, specify the filename during build.
#### Example Dockerfile:
```dockerfile
# 🐧 Use Ubuntu 22.04 as the base image
FROM ubuntu:22.04
# 🏷️ Add metadata such as version information
LABEL version="0.0.1"
# 🔄 Update package lists and install essential tools
RUN apt update && apt install -y bash vim curl
# 🌐 Install Nginx web server
RUN apt install -y nginx
```
**Explanation:**
* `FROM ubuntu:22.04` — Use Ubuntu 22.04 as the base image.
* `LABEL version="0.0.1"` — Adds version metadata.
* `RUN` — Executes commands inside the container to install tools and software.
---
### 2️⃣ Example Using Alpine Linux
Alpine Linux is lightweight and creates smaller images.
```dockerfile
# 🐧 Use Alpine as the base image
FROM alpine
# 🏷️ Add version metadata
LABEL version="0.0.1"
# 🔄 Update package lists and install essential tools
RUN apk update && apk add bash vim curl
```
Perfect for a compact, minimalistic image.
---
### 3️⃣ Complex Dockerfile with a Script
```dockerfile
# 🐧 Start with Alpine as the base image
FROM alpine
# 🏷️ Add metadata
LABEL version="0.0.1"
# 🔄 Update packages and install essential tools
RUN apk update && apk add bash vim curl iputils-ping
# 📂 Copy the script into the image
COPY <local-file-path> <container-destination-path>
# 🏠 Set working directory
WORKDIR <container-destination-path>
# 🌿 Add environment variables
ENV API_KEY="123445"
# 👤 Set user and expose ports
USER deploy
EXPOSE 3210
# ⚙️ Make the script executable
RUN chmod +x app.sh
# ▶️ Default command to run
CMD ["./app.sh"]
# Alternatively, ENTRYPOINT ensures always running the executable
ENTRYPOINT ["bash", "./app.sh"]
```
---
### ❤️ Health Check Setup
```dockerfile
HEALTHCHECK --interval=30s --timeout=5s --retries=3 \
CMD curl -f http://localhost/ || exit 1
```
* ⏲️ **interval**: time between checks
* ⏳ **timeout**: fail if check takes longer than 5 seconds
* 🔄 **retries**: mark container unhealthy after failed attempts
* 🛡️ **start-period**: grace period before counting failures
---
### 4️⃣ Build Your Docker Image
```bash
docker build -t <app-name> <path-to-dockerfile>
```
**Examples:**
* Build with Dockerfile in current directory:
```bash
docker build -t app-test .
```
* Use custom Dockerfile name:
```bash
docker build -t app-test -f <CustomDockerfile> .
```
* Build without cache:
```bash
docker build -t app-test:v1 -f <Custom-Dir> . --no-cache
```
---
## 📋 Summary
A **Dockerfile** is a powerful tool for automating Docker image creation:
1. 📝 **Create a Dockerfile**: Define the image with `FROM`, `RUN`, `COPY`, and `CMD`.
2. 🏗️ **Build the Image**: Use `docker build` to generate your image.
3. 🚀 **Run the Container**: Use `docker run` to start your container.

83
Containerization-Orchestration/Docker/4-Docker-Compose.md Executable file
View File

@@ -0,0 +1,83 @@
# **Docker Compose Guide**
Docker Compose is a tool for defining and running multi-container Docker applications. It allows you to manage services, networks, and volumes using a YAML configuration file.
---
## **1. Basic Docker Compose Structure**
Before defining the services in Docker Compose, we need to specify the Docker Compose version and the services we want to run. Here's a basic YAML template:
```yaml
version: "<python-version>"
services:
<service-name>: # The name of your service (e.g., web, db)
container_name: <container-name> # The name of the container
image: <image-name> # Docker image to be used for this service
restart: always # Ensure the container restarts if it stops or fails
ports:
- "<sv-port>:<container-port>" # Map the host port to the container port
volumes:
- <vol-name>:<container-loc> # Attach a volume to a specific location in the container
environment:
- <env1>=<value1> # Environment variables to be passed to the container
```
### **Explanation**:
- **`services:`**: The core section where you define different services (containers) that make up your application.
- **`<service-name>`**: Replace with the name of the service (e.g., `web`, `database`). Each service corresponds to a container.
- **`container_name`**: The name given to the container.
- **`image`**: The Docker image used to run the service (e.g., `python:3.9`, `nginx`).
- **`restart: always`**: Ensures the container will always restart if it stops, providing higher availability.
- **`ports`**: Maps ports from the host to the container, allowing the container to be accessed externally. The syntax is `<host-port>:<container-port>`.
- **`volumes`**: Links a Docker volume or host directory to a directory inside the container, enabling persistent data or sharing of resources. Example: `myvolume:/usr/src/app`.
- **`environment`**: Defines environment variables to be passed to the container at runtime. For example, setting an environment variable like `DB_HOST=localhost`.
---
## **2. Defining Volumes**
Docker Compose allows you to define persistent volumes that can be attached to containers. Here's how to define a volume:
```yaml
volumes:
<vol-name>: # Define the volume here
```
### **Explanation**:
- **`volumes:`**: This section allows you to define named volumes that can be used in the services.
- **`<vol-name>`**: Replace this with the name of the volume (e.g., `data-volume`, `db-volume`). The volume can be attached to different services to persist data beyond the container's lifecycle.
---
## **3. Useful Docker Compose Commands**
### **3.1 Start the Docker Compose Application**
To bring up the application defined in the `docker-compose.yml` file, use:
```bash
docker compose up
```
### **3.2 Run Docker Compose in Detached Mode (Background)**
To run your Docker Compose services in the background (detached mode):
```bash
docker compose up -d
```
### **3.3 Stop and Remove Docker Compose Services**
To stop the services and remove the containers, networks, and volumes created by Docker Compose:
```bash
docker compose down
```
### **Explanation of Commands**:
- **`docker compose up`**: Builds, (re)creates, and starts all services defined in the `docker-compose.yml` file.
- **`docker compose up -d`**: Runs the services in the background, keeping your terminal free while the containers continue running.
- **`docker compose down`**: Stops and removes all running services, containers, and networks created by Docker Compose. You can add the `-v` flag to remove volumes as well.

228
Containerization-Orchestration/Docker/5-Docker-Swarm.md Executable file
View File

@@ -0,0 +1,228 @@
# 📦 Docker Swarm Documentation
Comprehensive guide to managing a **Docker Swarm** cluster. This document includes core commands, workflows, and best practices for maintaining a healthy and operational environment.
---
## 📚 Table of Contents
1. [🔧 Cluster Health & Manager Count](#-cluster-health--manager-count)
2. [🚀 Example Workflow: Setting Up Nginx](#-example-workflow-setting-up-nginx)
3. [⚙️ Cluster Initialization and Management](#️-cluster-initialization-and-management)
4. [🖥️ Node Management](#️-node-management)
5. [🛠️ Service Management](#️-service-management)
6. [🔑 Join Tokens & Node Configuration](#-join-tokens--node-configuration)
---
## 🔧 Cluster Health & Manager Count
A Docker Swarm cluster requires a **majority of manager nodes** to be functional for quorum.
> **Best Practice:** Always maintain **more than 50%** manager nodes online. Losing quorum will render the cluster non-operational.
---
## 🚀 Example Workflow: Setting Up Nginx
Docker Swarm handles service deployment through several internal components:
1. **API** – Receives service requests.
2. **Allocator** – Determines resource allocation.
3. **Dispatcher** – Assigns tasks to nodes.
4. **Scheduler** – Places tasks on optimal nodes.
This process ensures resilient and efficient service distribution.
---
## ⚙️ Cluster Initialization and Management
### 🔹 Initialize Cluster
```bash
docker swarm init
```
### 🔹 Initialize with Specific Interface
```bash
docker swarm init --advertise-addr <ip-or-interface>
```
### 🔹 Join Existing Cluster
```bash
docker swarm join
```
### 🔹 Leave Cluster
```bash
docker swarm leave
```
### 🔹 Unlock a Manager Node
```bash
docker swarm unlock
```
---
## 🖥️ Node Management
### 🔸 List Nodes
```bash
docker node ls
```
**Example Output:**
```
ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS ENGINE VERSION
8yw8jrjeqczaci0qkuy060g09 * docker-1 Ready Active Leader 24.0.5
v4gvf7xenw0izmxgvhr6hb2rj docker-2 Ready Active 24.0.5
kd3ujmt1ey3pw6v9189fouxfa docker-3 Ready Active Reachable 24.0.5
tm1msy58ztcltt36rs1lb76p7 docker-4 Down Active 24.0.5
```
### 🔸 Remove a Node
```bash
docker node rm <node-id>
```
### 🔸 Promote to Manager
```bash
docker node promote <hostname-or-id>
```
### 🔸 Inspect a Node
```bash
docker node inspect <nodename>
```
### 🔸 Change Node Role
```bash
docker node update --role manager <nodename>
docker node update --role worker <nodename>
```
### 🔸 Change Node Availability
```bash
docker node update --availability active <nodename>
docker node update --availability pause <nodename>
docker node update --availability drain <nodename>
```
### 🔸 Add or Remove Labels
**Add:**
```bash
docker node update --label-add env=development <nodename>
docker node update --label-add env=testing <nodename>
```
**Remove:**
```bash
docker node update --label-rm env= <nodename>
docker node update --label-rm env <nodename>
```
**Use label constraints in service deployment:**
```yaml
deploy:
placement:
constraints:
- node.labels.env == development
```
---
## 🛠️ Service Management
### 🔹 Show Tasks on a Node
```bash
docker node ps
```
### 🔹 List All Services
```bash
docker service ls
```
### 🔹 Create a New Service
```bash
docker service create --name <service-name> <image-name>
```
### 🔹 Scale a Service
```bash
docker service scale <service-name>=<replica-count>
```
**Example:**
```bash
docker service scale nginx=5
```
### 🔹 Inspect a Service
```bash
docker service inspect <service-name>
```
### 🔹 Create Service with Replicas, Env Vars, and Port Mapping
```bash
docker service create \
--name <service-name> \
--replicas <count> \
--env <ENV_VAR=value> \
--publish <host-port>:<container-port> \
<image-name>
```
**Example:**
```bash
docker service create \
--name nginx \
--replicas 3 \
--env MY_ENV_VAR=value \
--publish 8080:80 \
nginx
```
---
## 🔑 Join Tokens & Node Configuration
Securely add nodes to your Swarm using join tokens.
### 🔹 Get Worker Token
```bash
docker swarm join-token worker
```
### 🔹 Get Manager Token
```bash
docker swarm join-token manager
```

102
Containerization-Orchestration/Docker/Additional.md Executable file
View File

@@ -0,0 +1,102 @@
# HTTP Status Codes Table
| Status Code | Category | Description |
|-------------|------------------------|---------------------------------------------------------------------------------------|
| **100** | Informational (1xx) | Continue: The client should continue with its request. |
| **101** | Informational (1xx) | Switching Protocols: Server is switching protocols. |
| **102** | Informational (1xx) | Processing (WebDAV): Server has received and is processing the request. |
| **200** | Success (2xx) | OK: The request was successful. |
| **201** | Success (2xx) | Created: The request was successful and a resource was created. |
| **202** | Success (2xx) | Accepted: The request has been accepted for processing. |
| **203** | Success (2xx) | Non-Authoritative Information: The server is a proxy, not the original. |
| **204** | Success (2xx) | No Content: The server successfully processed the request, but no content is returned.|
| **205** | Success (2xx) | Reset Content: The client should reset the view. |
| **206** | Success (2xx) | Partial Content: The server is delivering part of the resource (range requests). |
| **300** | Redirection (3xx) | Multiple Choices: Multiple options for the resource are available. |
| **301** | Redirection (3xx) | Moved Permanently: The resource has moved permanently to a new URI. |
| **302** | Redirection (3xx) | Found: The resource is temporarily at a different URI. |
| **303** | Redirection (3xx) | See Other: The response is at another URI. |
| **304** | Redirection (3xx) | Not Modified: The resource has not been modified since the last request. |
| **305** | Redirection (3xx) | Use Proxy: The requested resource is available only through a proxy. |
| **307** | Redirection (3xx) | Temporary Redirect: The resource resides temporarily at a different URI. |
| **308** | Redirection (3xx) | Permanent Redirect: The resource has moved permanently, and this URI should be used. |
| **400** | Client Errors (4xx) | Bad Request: The server could not understand the request due to invalid syntax. |
| **401** | Client Errors (4xx) | Unauthorized: Authentication is required and has failed. |
| **402** | Client Errors (4xx) | Payment Required: Reserved for future use. |
| **403** | Client Errors (4xx) | Forbidden: The request was understood but refuses to authorize it. |
| **404** | Client Errors (4xx) | Not Found: The resource could not be found. |
| **405** | Client Errors (4xx) | Method Not Allowed: The request method is not supported for the resource. |
| **406** | Client Errors (4xx) | Not Acceptable: The resource cannot produce content acceptable to the client. |
| **407** | Client Errors (4xx) | Proxy Authentication Required: The client must authenticate with the proxy first. |
| **408** | Client Errors (4xx) | Request Timeout: The server timed out waiting for the request. |
| **409** | Client Errors (4xx) | Conflict: The request could not be processed because of a conflict. |
| **410** | Client Errors (4xx) | Gone: The resource is no longer available. |
| **411** | Client Errors (4xx) | Length Required: The request did not specify the length. |
| **412** | Client Errors (4xx) | Precondition Failed: The preconditions set by the client were not met. |
| **413** | Client Errors (4xx) | Payload Too Large: The request is too large to process. |
| **414** | Client Errors (4xx) | URI Too Long: The URI provided was too long for the server to process. |
| **415** | Client Errors (4xx) | Unsupported Media Type: The media type of the request is not supported. |
| **416** | Client Errors (4xx) | Range Not Satisfiable: The client requested a portion that cannot be supplied. |
| **417** | Client Errors (4xx) | Expectation Failed: The server cannot meet the expectation of the request. |
| **418** | Client Errors (4xx) | I'm a teapot (RFC 2324): An April Fools' joke code. |
| **421** | Client Errors (4xx) | Misdirected Request: The request was directed at a wrong server. |
| **422** | Client Errors (4xx) | Unprocessable Entity (WebDAV): The request was well-formed but semantic errors exist. |
| **423** | Client Errors (4xx) | Locked (WebDAV): The resource being accessed is locked. |
| **424** | Client Errors (4xx) | Failed Dependency (WebDAV): A previous request failed, causing this one to fail. |
| **425** | Client Errors (4xx) | Too Early: The server is unwilling to process this request yet. |
| **426** | Client Errors (4xx) | Upgrade Required: The client needs to switch to a different protocol. |
| **428** | Client Errors (4xx) | Precondition Required: The server requires the request to be conditional. |
| **429** | Client Errors (4xx) | Too Many Requests: Too many requests sent in a given amount of time. |
| **431** | Client Errors (4xx) | Request Header Fields Too Large: The request's header fields are too large. |
| **451** | Client Errors (4xx) | Unavailable For Legal Reasons: The resource is unavailable for legal reasons. |
| **500** | Server Errors (5xx) | Internal Server Error: An unexpected server error occurred. |
| **501** | Server Errors (5xx) | Not Implemented: The server lacks the ability to fulfill the request. |
| **502** | Server Errors (5xx) | Bad Gateway: Received an invalid response from the upstream server. |
| **503** | Server Errors (5xx) | Service Unavailable: The server is overloaded or down for maintenance. |
| **504** | Server Errors (5xx) | Gateway Timeout: No timely response from the upstream server. |
| **505** | Server Errors (5xx) | HTTP Version Not Supported: The server does not support the HTTP version. |
| **506** | Server Errors (5xx) | Variant Also Negotiates: Internal configuration error. |
| **507** | Server Errors (5xx) | Insufficient Storage (WebDAV): The server cannot store the representation. |
| **508** | Server Errors (5xx) | Loop Detected (WebDAV): The server detected an infinite loop while processing. |
| **510** | Server Errors (5xx) | Not Extended: Extensions are required for the server to fulfill the request. |
| **511** | Server Errors (5xx) | Network Authentication Required: Client must authenticate to gain network access. |
---
# Docker Image Layers
A **Docker image** is composed of multiple layers that work together to create a fully functional container. Each layer represents a step in the build process, and layers are stacked on top of one another to form the complete image.
### Structure of a Docker Image:
1. **BootFS (Boot File System):**
- **Description:** This is the bottom-most layer in the Docker image. It includes files and directories needed to boot up a system.
- **Function:** It sets up the foundation for the base operating system within the container, similar to the host machine’s `/boot` folder.
2. **Base Image:**
- **Description:** The base image is typically a minimal operating system (e.g., Ubuntu, Alpine Linux) or any other image that acts as a starting point for your container.
- **Examples:** Ubuntu, Alpine, Debian.
- **Function:** Provides the core OS functionalities and dependencies needed for the higher layers.
3. **Libraries:**
- **Description:** Libraries required by the applications running in the container.
- **Examples:** libc, libssl, or any other standard libraries needed by the applications.
- **Function:** Provides necessary functionality for applications, ensuring they can function correctly within the container.
4. **Packages and Applications:**
- **Description:** Specific software, tools, or libraries that your application depends on.
- **Examples:** vim, curl, git, node.js, or custom software required by your application.
- **Function:** These packages allow you to run applications and scripts necessary for the container's purpose.
5. **User Application (Optional):**
- **Description:** The main application code that you intend to run within the container.
- **Examples:** A web server like Apache, Nginx, or any microservice application.
- **Function:** It is the purpose of the container, which could be serving web traffic, processing data, or any other specific task.
### Writable Layer (Container-Specific):
- **Description:** Once a container is created from a Docker image, a writable layer is added on top of the image layers.
- **Function:** Any changes made during the container's runtime (like creating files or modifying configurations) are stored in this writable layer.
- **Key Point:** Changes to the writable layer do not impact the underlying image layers.
---

81
Containerization-Orchestration/Docker/Docker-Dirs.md Executable file
View File

@@ -0,0 +1,81 @@
# Docker Directory Structure in `/var/lib/docker`
In Linux, Docker stores its container data under `/var/lib/docker`. Each subdirectory here serves a specific purpose related to Docker's functionality. Below is a breakdown of each important directory under `/var/lib/docker`.
## 1. **/var/lib/docker/containers**
This directory contains the data for each Docker container. Each container has its own subdirectory, named after the container's unique ID. Inside each container’s directory, you’ll find files like:
- `config.v2.json`: Configuration data for the container.
- `hostconfig.json`: Configuration related to how the container was launched.
- `log.json`: The logs generated by the container.
**Example:**
```bash
/var/lib/docker/containers/[container_id]/config.v2.json
```
## 2. **/var/lib/docker/image**
This directory contains Docker images. Images are stored in subdirectories based on their storage driver (e.g., `overlay2`, `aufs`, etc.).
**Key subdirectories:**
- `/var/lib/docker/image/overlay2/`: Stores metadata and layers for images using the `overlay2` storage driver.
## 3. **/var/lib/docker/overlay2**
The `overlay2` directory contains the layers of the Docker images and containers. Each image and container is made up of multiple layers, which are stored in this directory. The overlay filesystem merges these layers to create a unified view of the container's filesystem.
**Key subdirectories:**
- `diff/`: Stores the content changes for each layer.
- `merged/`: Represents the merged view of the layers for running containers.
- `work/`: Temporary working directories for file operations.
## 4. **/var/lib/docker/plugins**
This directory is where Docker stores data related to plugins. Docker plugins extend the platform's capabilities by adding features such as storage drivers, networking plugins, and logging mechanisms.
**Subdirectory structure:**
- `/var/lib/docker/plugins/[plugin_id]/`: Each installed plugin has its own subdirectory.
## 5. **/var/lib/docker/network**
This directory stores data related to Docker's networking functionality. Docker allows containers to communicate with each other through networks, and this directory holds information about those networks.
**Key subdirectories:**
- `files/`: Contains JSON files that describe the networks.
- `local-kv.db`: A database that stores network state information.
## 6. **/var/lib/docker/swarm**
This directory holds data related to Docker Swarm mode, which allows you to deploy and manage a cluster of Docker nodes. The swarm directory is used for storing cluster state, such as node configurations and services.
**Key files:**
- `worker/`: Contains information specific to the worker nodes in a swarm.
- `raft/`: Contains data for the Raft consensus algorithm used to manage the swarm cluster state.
## 7. **/var/lib/docker/volumes**
This directory contains data for Docker volumes, which are used for persisting data outside of the container lifecycle. Each volume is stored in its own subdirectory.
**Example:**
```bash
/var/lib/docker/volumes/[volume_name]/_data/
```
The `_data` subdirectory inside each volume contains the actual persistent data for that volume.
## 8. **/var/lib/docker/builder**
This directory stores information related to the Docker image build process. It includes cache data and temporary files generated while building Docker images.
**Key files:**
- `cache/`: Contains cached layers used during the image building process to speed up future builds.
## 9. **/var/lib/docker/runtimes**
This directory contains data related to different container runtimes. While Docker primarily uses `runc`, other runtimes like `nvidia` can also be installed here.
## 10. **/var/lib/docker/tmp**
Temporary files used by Docker are stored in this directory. These are usually short-lived and can include things like temporary layers during builds or container creation processes.

74
Containerization-Orchestration/Docker/docker-stack-example.yml Normal file
View File

@@ -0,0 +1,74 @@
version: "3.8"
services:
web:
image: nginx:alpine
ports:
- "80:80"
deploy:
# Service mode: use "replicated" for a set number of replicas,
# or "global" to run one instance on every node.
mode: replicated
# Number of container replicas to run (only applicable in replicated mode)
replicas: 3
# Rolling update configuration (applies when updating the service)
update_config:
# Number of containers to update at the same time
parallelism: 2
# Delay between updating groups of containers (e.g., "10s" for 10 seconds)
delay: 10s
# Action to take if an update fails: rollback, pause, or continue
failure_action: rollback
# Time to monitor each updated container before proceeding to the next batch
monitor: 10s
# Maximum failure ratio (0.0 to 1.0) acceptable during the update
max_failure_ratio: 0.3
# Rollback configuration (applies if a deployment needs to be undone)
rollback_config:
parallelism: 1
delay: 10s
# Action to take if rollback fails
failure_action: pause
monitor: 10s
max_failure_ratio: 0.2
# Restart policy for containers in the service
restart_policy:
# Restart condition can be "none", "on-failure", or "any"
condition: on-failure
# Delay between restart attempts
delay: 5s
# Maximum number of restart attempts before considering the container as failed
max_attempts: 3
# Time window used to evaluate restart attempts (e.g., "120s")
window: 120s
# Resource constraints and reservations for containers
resources:
limits:
# Maximum number of CPUs the container can use (as a fraction or whole number)
cpus: "0.50"
# Maximum memory (e.g., "50M" for 50 megabytes)
memory: 50M
reservations:
# Guaranteed minimum CPUs for the container
cpus: "0.25"
# Guaranteed minimum memory
memory: 20M
# Placement constraints and preferences to control which nodes run the service
placement:
# Constraints ensure that only nodes meeting certain conditions are eligible.
constraints:
- node.role == manager
- node.labels.region == us-east
# Preferences allow you to influence (but not enforce) distribution.
preferences:
- spread: node.labels.az
# Custom metadata labels for the service
labels:
com.example.description: "Sample web service using all deploy parameters"

87
Containerization-Orchestration/Kubernetes/1-Information.md Executable file
View File

@@ -0,0 +1,87 @@
# 🚢 Kubernetes (K8s) Documentation
## 🌐 Overview
**Kubernetes (K8s)** is an open-source container orchestration platform designed to automate the deployment, scaling, and operation of containerized applications.
---
## 🧠 Control Plane (CP)
The **Control Plane** is the core management component of a Kubernetes cluster. It makes global decisions about the cluster (e.g., scheduling) and maintains the desired state of the cluster by managing workloads and directing communication within the system.
> 💡 **Note:** By default, the Control Plane does not directly manage or run application containers.
### 🔑 Key Components of the Control Plane
- **API Server (`kube-apiserver`)**
Exposes the Kubernetes API and serves as the cluster's entry point. It handles communication between internal components and external clients.
- **Scheduler (`kube-scheduler`)**
Assigns workloads (e.g., Pods) to nodes based on resource availability and defined policies.
- **Controller Manager (`kube-controller-manager`)**
Runs controllers that monitor and regulate the cluster's state, such as the Node Controller and Replication Controller.
- **etcd**
A consistent and highly available key-value store that stores all cluster data, configurations, and state. This is the "database" of Kubernetes.
---
## 🧱 Worker Nodes
**Worker nodes** are the machines where containerized applications run. Each node contains essential components for managing containers.
### 🔧 Key Components of a Worker Node
- **Kubelet**
An agent that ensures containers run as specified in their Pod definitions. It communicates with the Control Plane to execute assigned tasks.
- **Kube Proxy**
Maintains network rules and manages routing for communication within the cluster and with external systems.
---
## 🔄 Data Flow
- **Kubelet** and **Kube Proxy** on each worker node interact with the **API Server** to perform operations and update resource states.
- The **Scheduler** selects suitable nodes for pod placement based on available resources.
- The **Controller Manager** ensures the actual state of the cluster matches the desired state.
---
## 🛠️ Administration Tools
- **`kubeadm`**
A command-line tool to bootstrap and configure Kubernetes clusters. It streamlines the setup of both the Control Plane and worker nodes.
- **`kubectl`**
The CLI for interacting with the Kubernetes API. It's used to deploy apps, inspect cluster resources, and manage configurations.
---
## 🧩 Kubernetes Version Compatibility
### Kubernetes and Container Runtimes
- **Kubernetes ≤ 1.23**
✅ Compatible with **Docker** as the default container runtime.
- **Kubernetes 1.24 – 1.25**
❌ Docker is **not supported** directly. Use `containerd` or another CRI-compliant runtime.
- **Kubernetes ≥ 1.25**
⚠️ Docker may be installed on the system but must be used **indirectly** through `containerd` or another supported CRI.
---
## 👥 Kubernetes Roles
- **Control Plane (Manager)**
Requires an **odd number** of nodes for high availability (e.g., 1, 3, 5, ...). This ensures quorum in distributed consensus.
- **Worker (none)**
These nodes run application workloads and do not participate in control decisions.
image pull policy in kubernetes:
example of all work loads:
https://k8s-examples.container-solutions.com/

161
Containerization-Orchestration/Kubernetes/2-Installtion.md Executable file
View File

@@ -0,0 +1,161 @@
# 🐳 Containerd and Kubernetes Installation Guide
A comprehensive step-by-step guide for setting up a Kubernetes cluster using **Containerd** as the container runtime. This guide is intended for Ubuntu-based systems.
---
## ⚙️ 1. Disable Swap
Kubernetes requires swap to be disabled for proper scheduling and memory management.
```bash
sudo swapoff -a
sudo sed -i '/swap/d' /etc/fstab
```
---
## 🧩 2. Enable Required Kernel Modules
Load the necessary kernel modules for networking and overlay file systems.
```bash
cat <<EOF | sudo tee /etc/modules-load.d/containerd.conf
overlay
br_netfilter
EOF
sudo modprobe overlay
sudo modprobe br_netfilter
```
---
## 🌐 3. Enable IPv4 Forwarding
Enable packet forwarding to allow pods to communicate across the network.
```bash
sudo tee /etc/sysctl.d/99-kubernetes-cri.conf <<EOF
net.bridge.bridge-nf-call-iptables = 1
net.ipv4.ip_forward = 1
net.bridge.bridge-nf-call-ip6tables = 1
EOF
sudo sysctl --system
```
---
## 📦 4. Install and Configure Containerd
Install and configure **Containerd** with `systemd` as the cgroup driver.
```bash
sudo apt-get update && sudo apt-get install -y containerd
sudo mkdir -p /etc/containerd
containerd config default | sudo tee /etc/containerd/config.toml
sudo sed -i 's/SystemdCgroup = false/SystemdCgroup = true/' /etc/containerd/config.toml
sudo systemctl restart containerd
sudo systemctl enable containerd
```
---
## ⎈ 5. Install Kubernetes Components
Add the Kubernetes repository and install the core components: `kubelet`, `kubeadm`, and `kubectl`.
```bash
sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.30/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
echo "deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.30/deb/ /" | sudo tee /etc/apt/sources.list.d/kubernetes.list
sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl
```
---
## 🔁 6. Enable Kubelet Service
Start and enable the kubelet to run on system boot.
```bash
sudo systemctl enable --now kubelet
```
---
## 🚀 7. Initialize the Kubernetes Control Plane
Initialize the cluster. Replace the IP with your master node's IP address.
```bash
sudo kubeadm init \
--control-plane-endpoint 192.168.2.100 \
--apiserver-advertise-address 192.168.2.100 \
--pod-network-cidr 10.244.0.0/16 | tee kuber-install.log
```
---
## 🛠 8. Configure kubectl Access
Set up `kubectl` for the current (non-root) user.
```bash
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
```
---
## 🧾 9. Create Control Plane Join Command
Generate a command for other control plane nodes to join the cluster.
```bash
sudo kubeadm init phase upload-certs --upload-certs
```
Copy the **certificate key** from the output above and run:
```bash
sudo kubeadm token create --certificate-key <CERTIFICATE_KEY> --print-join-command | tee cp-command.txt
```
Replace `<CERTIFICATE_KEY>` with the actual key.
---
## 🧑‍🤝‍🧑 10. Join Control Plane and Worker Nodes
* **Control Plane Nodes**: Use the command from `cp-command.txt` on each node.
* **Worker Nodes**: Use the `kubeadm join` command printed at the end of the `kubeadm init` output or found in `kuber-install.log`.
---
## ✅ Final Step: Install a Pod Network Add-on
Choose and apply a pod network add-on (e.g., Flannel, Calico, Cilium). Here's an example with Flannel:
```bash
kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml
```
---
🎉 **Your Kubernetes cluster is now up and running!**
Ensure all nodes are ready by running:
```bash
kubectl get nodes
```

13
Containerization-Orchestration/Kubernetes/3-BasicSetup.md Normal file
View File

@@ -0,0 +1,13 @@
```bash
kubectl complation <shell>
```
exapmles:
```bash
kubectl completion zsh > "${fpath[1]}/_kubectl"
```
```bash
kubectl completion bash > ~/.kube/completion.bash.inc
```

121
Containerization-Orchestration/Kubernetes/Commands/3-Commands.md Executable file
View File

@@ -0,0 +1,121 @@
# Kubernetes Command Reference
This guide provides a concise reference for common `kubectl` commands used to manage Kubernetes clusters. Whether you’re managing nodes, namespaces, pods, deployments, or autoscaling, the examples below will help you perform everyday tasks with confidence.
## General Commands
- **List API Resources**
Display all available API resources along with their short names:
```bash
kubectl api-resources
```
---
## API Resources & Documentation
- **Get Detailed Documentation for an API Resource**
```bash
kubectl explain <api-resource-name>
```
*Example:*
```bash
kubectl explain pod
```
```bash
kubectl explain pod.metadata
```
---
## Applying YAML Files
- **Apply a Configuration from a YAML File**
Apply a YAML configuration to a specific namespace:
```bash
kubectl apply -f <yaml-file> -n <namespace-name>
```
---
## Viewing Cluster Resources
- **Display All Resources in a Namespace**
```bash
kubectl get all -n <namespace-name>
```
- **Display ReplicaSets, Pods, and Deployments in a Specific Namespace**
```bash
kubectl get rs,pods,deployments -n <namespace-name>
```
---
## ReplicaSet & Deployment Management
### Scaling and Rollouts
- **Scale a ReplicaSet**
```bash
kubectl scale rs <replicaset-name> --replicas=<count> -n <namespace-name>
```
- **View Rollout History of a Deployment**
```bash
kubectl rollout history deployment <deployment-name> -n <namespace-name>
```
- **View Details of a Specific Revision**
```bash
kubectl rollout history deployment <deployment-name> -n <namespace-name> --revision=<number>
```
- **Roll Back a Deployment to a Specific Revision**
```bash
kubectl rollout undo deployment <deployment-name> -n <namespace-name> --to-revision=<number>
```
### Autoscaling
- **Autoscale a Deployment**
Automatically scale a deployment based on CPU utilization:
```bash
kubectl autoscale deployment <deployment-name> -n <namespace-name> --cpu-percent=<target-cpu-percentage> --min=<min-pods> --max=<max-pods>
```
- **View Horizontal Pod Autoscalers (HPA)**
```bash
kubectl get hpa -n <namespace-name>
```
---
---
## Additional Information
- **Static Manifest Files**
Any YAML files placed in `/etc/kubernetes/manifests/` are automatically loaded when the kubelet starts (for example, after a server reboot).
```bash
kubectl cp -n <ns> <pod-name>:dir/ ./
```

9
Containerization-Orchestration/Kubernetes/Commands/label.md Normal file
View File

@@ -0,0 +1,9 @@
- **Set a Custom Label on a Node**
```bash
kubectl label node <node-name> kubernetes.io/<label-key>=<label-value>
```
> **Note:** Replace `<node-name>`, `<label-key>`, and `<label-value>` with your desired values.

27
Containerization-Orchestration/Kubernetes/Commands/log-debug.md Normal file
View File

@@ -0,0 +1,27 @@
- **Stream Logs for a Running Pod**
```bash
kubectl logs -f -n <namespace-name> <pod-name>
```
```bash
kubectl logs -f -n <namespace-name> <pod-name> -c <container-name>
```
- **Get Detailed Information About a Pod**
```bash
kubectl describe pod <pod-name> -n <namespace-name>
```
in log swith the pod need to be up
but in describe dont need to pod be up
describe work on all components

63
Containerization-Orchestration/Kubernetes/Commands/node-manage.md Normal file
View File

@@ -0,0 +1,63 @@
# 🌐 Node Management with Kubernetes
Efficient management of Kubernetes nodes ensures cluster stability and workload flexibility. Below are key commands for listing and maintaining nodes.
---
## 📋 Listing Nodes
### 🔹 Show All Nodes
```bash
kubectl get nodes
````
### 🔹 Show Nodes with Labels
```bash
kubectl get nodes --show-labels
```
---
## 🔧 Node Maintenance (Cordon / Drain)
### 🚫 Cordon a Node
Prevent new pods from being scheduled on the node.
```bash
kubectl cordon <node-name>
```
### ✅ Uncordon a Node
Mark the node as schedulable again.
```bash
kubectl uncordon <node-name>
```
### 🧹 Drain a Node
Evict all pods from the node (excluding those managed by DaemonSets).
* Forcefully drain the node:
```bash
kubectl drain <node-name> --ignore-daemonsets --force
```
* Drain and delete local data:
```bash
kubectl drain <node-name> --ignore-daemonsets --delete-local-data
```
#### 🔄 Undo Drain (Uncordon)
```bash
kubectl uncordon <node-name>
```
> ⚠️ **Warning:** Draining a node will evict running pods. Ensure that this is planned to avoid service disruption.

58
Containerization-Orchestration/Kubernetes/Storage/Longhorn/with-kubectl.md Normal file
View File

@@ -0,0 +1,58 @@
# 📦 Deploying Longhorn with `kubectl`
This guide walks you through installing **Longhorn**, a cloud-native distributed block storage solution for Kubernetes, using `kubectl`.
---
## 🚀 Prerequisites
* A Kubernetes cluster (v1.21 or newer recommended)
* `kubectl` configured and connected to your cluster
* Internet access for downloading manifests
---
## 🧩 Step 1: Apply Longhorn YAML
Apply the official Longhorn deployment manifest in the `longhorn-system` namespace:
```bash
kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/v1.9.0/deploy/longhorn.yaml
```
This will create all required resources under the `longhorn-system` namespace.
---
## 🔍 Step 2: Monitor Longhorn Pods
Watch the pods being created to ensure Longhorn is deploying properly:
```bash
kubectl get pods \
--namespace longhorn-system \
--watch
```
Wait until all pods show a `Running` or `Completed` status.
---
## 📦 Step 3: Verify Storage Classes
Once Longhorn is running, verify that the storage classes have been registered:
```bash
kubectl get storageclasses
```
You should see a storage class named `longhorn`, which can now be used in your PersistentVolumeClaims (PVCs).
---
## ✅ Success!
Longhorn is now successfully deployed and ready to provide persistent block storage for your workloads.
For more information, visit the [official Longhorn documentation](https://longhorn.io/docs/).

210
Containerization-Orchestration/Kubernetes/Storage/Pv.md Normal file
View File

@@ -0,0 +1,210 @@
# 🌐 Kubernetes Persistent Volumes (PV) Cheat Sheet
## 📦 What is a Persistent Volume (PV)?
A **Persistent Volume (PV)** is a piece of storage in a Kubernetes cluster that can be:
- **Pre-provisioned** by an administrator, or
- **Dynamically provisioned** using a **StorageClass**.
> PVs allow data to **persist beyond the lifecycle of individual Pods**.
---
## 📁 PV Storage Options
### 1. **HostPath**
- Mounts a file or directory from the host node’s filesystem into a Pod.
- Only suitable for **single-node testing or development** environments.
### 2. **Persistent Volume (PV) & Persistent Volume Claim (PVC)**
- **PV**: Represents the actual physical or virtual storage resource.
- **PVC**: A user's request for specific storage resources and access modes.
---
## 🧱 Kubernetes Storage Architecture
1. **Persistent Volume (PV)** – The actual storage unit, managed by the admin or provisioned dynamically.
2. **Persistent Volume Claim (PVC)** – A user’s request for a certain amount and type of storage.
---
## 🔄 PV Lifecycle Phases
| **State** | **Description** |
|---------------|---------------------------------------------|
| Provisioning | PV is being created or initialized. |
| Binding | PV is bound to a PVC. |
| Using | PV is in use by a Pod. |
| Releasing | PVC is deleted; PV becomes unbound. |
| Reclaiming | Based on reclaim policy: |
| | - `Delete`: Remove the storage. |
| | - `Recycle`: Basic scrub (deprecated). |
| | - `Retain`: Manual cleanup required. |
---
## 🔒 PV Access Modes
| **Mode** | **Description** |
|------------|-------------------------------------------------|
| `RWO` | **ReadWriteOnce** – One node can read/write. |
| `ROX` | **ReadOnlyMany** – Multiple nodes can read. |
| `RWX` | **ReadWriteMany** – Multiple nodes can read/write. |
| `RWOP` | **ReadWriteOncePod** – Only one Pod can mount it with read/write access. |
---
## 🛠️ CLI Commands to Manage PVs & PVCs
```bash
# List all Persistent Volumes
kubectl get pv
# List all Persistent Volume Claims
kubectl get pvc
# Edit a PVC
kubectl edit pvc -n <namespace> <pvc-name>
```
---
## 🚀 Example: Deployment with `hostPath` Volume
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-1
namespace: dev
spec:
replicas: 3
selector:
matchLabels:
name: nginx
template:
metadata:
labels:
name: nginx
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
volumeMounts:
- name: nginx-log
mountPath: /var/log/nginx
volumes:
- name: nginx-log
hostPath:
path: /root/nginx/logs
type: DirectoryOrCreate
```
### Valid `hostPath` Types:
- `DirectoryOrCreate`
- `Directory`
- `FileOrCreate`
- `File`
- `Socket`
- `CharDevice`
- `BlockDevice`
---
## 📄 Example: Static Persistent Volume (PV)
```yaml
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv001
spec:
capacity:
storage: 128Mi
accessModes:
- ReadWriteMany
persistentVolumeReclaimPolicy: Retain
```
---
## 📄 Example: Persistent Volume Claim (PVC)
```yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-2
namespace: db
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 64Mi
```
> ✅ To bind a PVC to a specific PV, add `volumeName: <pv-name>` in the PVC spec:
```yaml
volumeName: pv001
```
---
## 🌐 NFS-Based Persistent Volume
### Persistent Volume (PV)
```yaml
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv-nfs-2
spec:
capacity:
storage: 128Mi
accessModes:
- ReadWriteMany
persistentVolumeReclaimPolicy: Retain
storageClassName: nginx-files
mountOptions:
- hard
- nfsvers=4.2
nfs:
path: /root/Nginx_Files
server: 192.168.6.160
```
### Persistent Volume Claim (PVC)
```yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-1
namespace: db
spec:
volumeName: pv-nfs-2
accessModes:
- ReadWriteMany
resources:
requests:
storage: 64Mi
storageClassName: nginx-files
```
---
## 🏗️ Static StorageClass for Pre-Provisioned Volumes
```yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: nginx-files
provisioner: kubernetes.io/no-provisioner
```

64
Containerization-Orchestration/Kubernetes/Storage/emptydir_vol.md Normal file
View File

@@ -0,0 +1,64 @@
## 📦 Pod Volume Lifecycle & `emptyDir` Usage in Kubernetes
This document describes how volumes work in the context of Kubernetes Pods, focusing on `emptyDir` and its lifecycle behavior.
---
### 🔁 Pod Lifecycle & Volumes
* **Volumes are defined at the Pod level.**
They are not tied to a specific container, but can be shared among containers within the same Pod.
* **Volumes are attached to containers through `volumeMounts`.**
This enables containers to access the volume’s filesystem at the specified `mountPath`.
* **Data in `emptyDir` volumes is ephemeral.**
The volume is created when the Pod starts and **deleted when the Pod is removed**, erasing all stored data.
---
### ⚠️ Visibility Across Pods & Containers
* A **Pod cannot access another Pod’s volume**, even if it's of type `emptyDir`.
For example:
* Pod A cannot see Pod B’s `emptyDir`.
* However, **containers within the same Pod can share and access the same `emptyDir`** volume.
---
### 🧪 Example: Pod with `emptyDir` Volume in Memory
```yaml
apiVersion: v1
kind: Pod
metadata:
namespace: ns-test
name: pod-tests
spec:
containers:
- name: nginx
image: nginx
resources:
limits:
memory: "150Mi"
cpu: "500m"
volumeMounts:
- name: nginx-log
mountPath: /var/log/nginx
volumes:
- name: nginx-log
emptyDir:
medium: Memory # Uses memory for faster read/write operations
sizeLimit: 64Mi # Volume size limited to 64Mi
```
---
### 🧠 Key Points
* `emptyDir` is ideal for temporary storage like logs, scratch space, or caches.
* Using `medium: Memory` stores data in memory (RAM) instead of disk, offering higher performance.
* `sizeLimit` restricts the amount of memory that the `emptyDir` can consume.

172
Containerization-Orchestration/Kubernetes/etcd-external.md Normal file
View File

@@ -0,0 +1,172 @@
# 🛠️ Setting Up a High Availability etcd Cluster for Kubernetes
This guide walks you through installing a 3-node etcd cluster and using it as an **external HA datastore for Kubernetes**.
---
## 📦 Step 1: Install etcd
Download the etcd binary:
```bash
wget https://github.com/etcd-io/etcd/releases/download/v3.6.2/etcd-v3.6.2-linux-amd64.tar.gz
```
Extract it:
```bash
tar -xzvf etcd-v3.6.2-linux-amd64.tar.gz
```
Move binaries to the system path:
```bash
cp etcd-v3.6.2-linux-amd64/etcd* /usr/local/bin
```
Create the data directory:
```bash
mkdir -p /var/lib/etcd
```
---
## ⚙️ Step 2: Configure etcd Systemd Services
Create a systemd service config at:
```bash
/etc/systemd/system/etcd.conf
```
### 🔹 Server 1 (`192.168.6.170`)
```ini
[Service]
ExecStart=/usr/local/bin/etcd \
--name etcd-1 \
--listen-client-urls http://192.168.6.170:2379,http://127.0.0.1:2379 \
--advertise-client-urls http://192.168.6.170:2379 \
--initial-advertise-peer-urls http://192.168.6.170:2380 \
--listen-peer-urls http://192.168.6.170:2380 \
--initial-cluster-token etcd-cluster-1 \
--initial-cluster etcd-1=http://192.168.6.170:2380,etcd-2=http://192.168.6.171:2380,etcd-3=http://192.168.6.172:2380 \
--initial-cluster-state new \
--data-dir /var/lib/etcd
Restart=always
User=root
StandardOutput=journal
StandardError=journal
[Install]
WantedBy=multi-user.target
```
### 🔹 Server 2 (`192.168.6.171`)
```ini
[Service]
ExecStart=/usr/local/bin/etcd \
--name etcd-2 \
--listen-client-urls http://192.168.6.171:2379,http://127.0.0.1:2379 \
--advertise-client-urls http://192.168.6.171:2379 \
--initial-advertise-peer-urls http://192.168.6.171:2380 \
--listen-peer-urls http://192.168.6.171:2380 \
--initial-cluster-token etcd-cluster-1 \
--initial-cluster etcd-1=http://192.168.6.170:2380,etcd-2=http://192.168.6.171:2380,etcd-3=http://192.168.6.172:2380 \
--initial-cluster-state new \
--data-dir /var/lib/etcd
Restart=always
User=root
StandardOutput=journal
StandardError=journal
[Install]
WantedBy=multi-user.target
```
### 🔹 Server 3 (`192.168.6.172`)
```ini
[Service]
ExecStart=/usr/local/bin/etcd \
--name etcd-3 \
--listen-client-urls http://192.168.6.172:2379,http://127.0.0.1:2379 \
--advertise-client-urls http://192.168.6.172:2379 \
--initial-advertise-peer-urls http://192.168.6.172:2380 \
--listen-peer-urls http://192.168.6.172:2380 \
--initial-cluster-token etcd-cluster-1 \
--initial-cluster etcd-1=http://192.168.6.170:2380,etcd-2=http://192.168.6.171:2380,etcd-3=http://192.168.6.172:2380 \
--initial-cluster-state new \
--data-dir /var/lib/etcd
Restart=always
User=root
StandardOutput=journal
StandardError=journal
[Install]
WantedBy=multi-user.target
```
---
## ▶️ Step 3: Start etcd Service
Enable and start the etcd service on **each server**:
```bash
systemctl start etcd
systemctl enable etcd
```
---
## ✅ Step 4: Verify etcd Cluster Health
Check endpoint health:
```bash
etcdctl --endpoints http://<IP>:2379 endpoint health
```
Check cluster membership:
```bash
etcdctl --endpoints http://<IP-SERVER-1>:2379 member list
```
If all members are healthy and visible, you're ready to move on.
---
## ☸️ Step 5: Install Kubernetes (Using External etcd)
Create a configuration file `config.yaml` on the **master node**:
```yaml
apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
etcd:
external:
endpoints:
- http://192.168.6.170:2379
- http://192.168.6.171:2379
- http://192.168.6.172:2379
networking:
podSubnet: 10.244.0.0/16
```
Initialize Kubernetes:
```bash
kubeadm init --config config.yaml
```
---
## 🎉 Done!
You now have a **Kubernetes cluster with external, high availability etcd**. :)

72
Containerization-Orchestration/Kubernetes/workloads/01-NameSpace.md Normal file
View File

@@ -0,0 +1,72 @@
# Kubernetes Namespaces Guide
Kubernetes **namespaces** allow you to organize and isolate resources within your cluster.
---
## 🧾 Listing Namespaces
To list all namespaces:
```bash
kubectl get namespaces
```
or the shorthand:
```bash
kubectl get ns
```
---
## 🛠️ Creating a Namespace
Create a new namespace:
```bash
kubectl create namespace <namespace-name>
```
or:
```bash
kubectl create ns <namespace-name>
```
---
## 🗑️ Deleting a Namespace
Delete a namespace:
```bash
kubectl delete ns <namespace-name>
```
---
## ⚠️ Best Practices & Notes
* **Namespaces are isolated**, but they **can still communicate** with each other by default.
* It is **not recommended to create namespaces that start with `kube-`**, as those are typically reserved for system components.
---
## 📄 Creating a Namespace with a Manifest
You can define a namespace using a YAML manifest:
```yaml
apiVersion: v1
kind: Namespace
metadata:
name: namespace-test
```
Apply it using:
```bash
kubectl apply -f namespace.yaml
```

138
Containerization-Orchestration/Kubernetes/workloads/02-Pod.md Normal file
View File

@@ -0,0 +1,138 @@
# 🌐 Kubernetes Pod Management Guide
A concise guide for managing Kubernetes Pods using `kubectl` and YAML manifests.
---
## 📋 Listing Pods
### 🔹 Default Namespace
List all Pods in the **default** namespace:
```bash
kubectl get pods
```
### 🔹 Wide Output (More Info)
List Pods with extended details (e.g., IP, node, etc.):
```bash
kubectl get pods -o wide
```
### 🔹 Specific Namespace
List Pods in a specific namespace:
```bash
kubectl get pods -o wide -n <namespace-name>
```
---
## 🚀 Running a Pod
> **Note:** `kubectl run` is ideal for quick tests or running **single** Pods. For production workloads, use **YAML manifests** or **Deployments**.
### 🔹 Run a Pod in Default Namespace
```bash
kubectl run <pod-name> --image=<image-name>
```
### 🔹 Run a Pod in a Specific Namespace
```bash
kubectl run <pod-name> --image=<image-name> -n <namespace>
```
---
## ❌ Deleting Pods
### 🔹 Standard Delete
```bash
kubectl delete pod <pod-name> -n <namespace-name>
```
### 🔹 Force Delete
```bash
kubectl delete pod <pod-name> -n <namespace-name> --force
```
### 🔹 Immediate Force Delete (No Grace Period)
```bash
kubectl delete pod <pod-name> -n <namespace-name> --force --grace-period=0
```
---
## ✏️ Editing a Pod
> **Warning:** Pods are **not directly editable**. Attempting to edit a running pod will result in a temporary patch but not persistent changes.
```bash
kubectl edit pod -n <namespace> <pod-name>
```
---
## 🔧 Executing into a Pod
Use this to start a shell or run commands inside a container:
```bash
kubectl exec -it -n <namespace> <pod-name> -- <command>
```
Example for a shell:
```bash
kubectl exec -it -n dev my-pod -- /bin/bash
```
---
## 🧾 Example Pod YAML Manifest
A multi-container Pod with resource limits and node selector:
```yaml
apiVersion: v1
kind: Pod
metadata:
namespace: dev
name: pod-1
labels:
label1: test
label2: test2
app.kubernetes.io/label3: test3
app.kubernetes.io/label4: test4
spec:
containers:
- name: nginx-server
image: nginx
- name: nginx-exporter
image: nginx-exporter
- name: ubuntu-c0
image: ubuntu
command: ["/bin/bash", "-c", "while true; do echo hello-world; sleep 5; done"]
resources:
limits:
memory: "256Mi"
cpu: "250m"
requests:
memory: "128Mi"
cpu: "125m"
nodeSelector:
hostname: k3s
app.kubernetes.io/disk: ssd
```

80
Containerization-Orchestration/Kubernetes/workloads/03-Replicaset.md Normal file
View File

@@ -0,0 +1,80 @@
# 🧩 Kubernetes ReplicaSet Management
A guide to working with **ReplicaSets** in Kubernetes, including inspection, editing behavior, and configuration examples.
---
## 📦 Listing Pods and ReplicaSets
### 🔹 List Pods in a Namespace
```bash
kubectl get pod -n <namespace>
```
### 🔹 List ReplicaSets in a Namespace
```bash
kubectl get rs -n <namespace>
```
---
## ✏️ Editing a ReplicaSet
You can attempt to edit a ReplicaSet:
```bash
kubectl edit rs -n <namespace> <replica-set-name>
```
> ⚠️ **Note:**
> Editing the **image** in a ReplicaSet directly will not automatically update existing Pods.
> This is because ReplicaSets do not perform **rolling updates**.
> Pods will only use the new image **after the old ones are deleted and new ones are created**.
**To apply image changes effectively:**
1. **Delete existing Pods** manually:
```bash
kubectl delete pod -l <label-selector> -n <namespace>
```
2. **Or**, use a higher-level controller like a **Deployment** for image updates and rolling behavior.
---
## 🧾 Example ReplicaSet YAML
Below is a minimal and clear ReplicaSet configuration:
```yaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: app-1
namespace: dev
labels:
label1: test1
app.kubernetes.io/label2: test2
spec:
replicas: 3
selector:
matchLabels:
app.kubernetes.io/label2: test2
template:
metadata:
labels:
app.kubernetes.io/label2: test2
os: linux
spec:
containers:
- name: nginx
image: nginx
```
> ✅ **Tip:**
> Ensure that the `template.metadata.labels` **matches exactly** with `spec.selector.matchLabels`.
> This is critical for proper ReplicaSet Pod matching.

107
Containerization-Orchestration/Kubernetes/workloads/04-Deployment.md Normal file
View File

@@ -0,0 +1,107 @@
# 🚀 Kubernetes Deployment Management
A guide to managing **Deployments** in Kubernetes, including listing, editing, scaling, rollbacks, and version history.
---
## 📋 Listing & Editing Deployments
### 🔹 List Deployments in a Namespace
```bash
kubectl get deploy -n <namespace>
```
### 🔹 Edit a Deployment
```bash
kubectl edit deployment.apps -n <namespace> <deployment-name>
```
> 🛠️ **Note:**
> Unlike ReplicaSets, Deployments **automatically update** existing Pods when the image or spec is changed. This makes Deployments ideal for rolling updates and version control.
---
## 📈 Scaling a Deployment
Scale the number of replicas (Pods) for a Deployment:
```bash
kubectl scale -n <namespace> deployment <deployment-name> --replicas=<number>
```
---
## 🔁 Rollout Management
### 🔹 View Rollout History
```bash
kubectl rollout history deployment -n <namespace> <deployment-name>
```
### 🔹 View Specific Revision
```bash
kubectl rollout history deployment -n <namespace> <deployment-name> --revision=<revision-number>
```
### 🔹 Roll Back to a Previous Revision
```bash
kubectl rollout undo deployment -n <namespace> <deployment-name> --to-revision=<revision-number>
```
> ✅ **Tip:**
> Deployments maintain revision history. This allows you to **roll back to a previous working version** in case of failure.
---
## 🧾 Example Deployment YAML
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-1
namespace: dev
labels:
label1: test1
app.kubernetes.io/label2: test2
spec:
replicas: 3
selector:
matchLabels:
app.kubernetes.io/label2: test2
template:
metadata:
labels:
app.kubernetes.io/label2: test2
os: linux
spec:
containers:
- name: nginx
image: nginx
```
> 🎯 **Why use Deployments?**
> They offer:
* Rolling updates
* Rollbacks
* Declarative Pod management
* History tracking
---
## ✅ Summary
| Feature | Pod | ReplicaSet | Deployment |
| ---------------- | --- | ---------- | ---------- |
| Manual creation | ✅ | 🚫 | 🚫 |
| Scales Pods | ❌ | ✅ | ✅ |
| Self-healing | ❌ | ✅ | ✅ |
| Rolling updates | ❌ | ❌ | ✅ |
| Revision history | ❌ | ❌ | ✅ |

67
Containerization-Orchestration/Kubernetes/workloads/05-hpa.md Normal file
View File

@@ -0,0 +1,67 @@
# 📈 Horizontal Pod Autoscaler (HPA)
The Horizontal Pod Autoscaler automatically scales the number of pods in a deployment based on observed CPU utilization (or other select metrics).
---
## ⚙️ Basic Commands
### 🚀 Create an HPA
Create an HPA for a deployment, scaling based on CPU usage:
```bash
kubectl -n <namespace> autoscale deployment <deployment-name> --cpu-percent=20 --min=4 --max=10
````
### 📊 View Existing HPAs
List all HPAs in a specific namespace:
```bash
kubectl get hpa -n <namespace>
```
### ❌ Delete an HPA
Remove a Horizontal Pod Autoscaler:
```bash
kubectl delete hpa -n <namespace> <hpa-name>
```
### 🛠️ Edit an HPA
Manually edit an existing HPA configuration:
```bash
kubectl edit hpa -n <namespace> <hpa-name>
```
---
## 🧾 Example HPA Manifest
You can define an HPA using a YAML file for more control:
```yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: hpa-test
namespace: dev
spec:
minReplicas: 1
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 50
```
> ℹ️ **Note:** The above manifest uses API version `autoscaling/v2` for enhanced metric support.
---

40
Containerization-Orchestration/Kubernetes/workloads/06-DaemonSet.md Normal file
View File

@@ -0,0 +1,40 @@
# 🧩 DaemonSet in Kubernetes
A **DaemonSet** ensures that a copy of a specific pod runs on **every (or some) node** in the cluster. It’s typically used for background system-level services like log collection, monitoring, or networking tools.
---
## 📌 Key Characteristics
- Automatically deploys one pod per worker node.
- Ensures the pod stays on each node as long as the DaemonSet exists.
- Automatically adds pods to new nodes when they join the cluster.
---
## 📄 Example DaemonSet YAML
Below is a simple DaemonSet example that deploys `nginx` to every node in the `web` namespace:
```yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: nginx
namespace: web
labels:
app: web-servers
spec:
selector:
matchLabels:
app: web-servers
template:
metadata:
labels:
app: web-servers
spec:
containers:
- name: nginx
image: nginx:1.27
````

48
Containerization-Orchestration/Kubernetes/workloads/07-Jobs.md Normal file
View File

@@ -0,0 +1,48 @@
# ⏳ Kubernetes Jobs
A **Job** in Kubernetes runs a pod to completion. It ensures that a specified number of pods successfully terminate.
Use Jobs for **batch processing**, **one-off tasks**, or **short-lived workloads**.
---
## 🔍 Job Commands
### 📄 List Jobs in a Namespace
```bash
kubectl get jobs.batch -n <namespace>
````
### ❌ Delete a Job
```bash
kubectl delete jobs.batch -n <namespace> <job-name>
```
---
## 🧾 Example Job Manifest
Here’s a minimal example of a Job that runs a simple `echo` command:
```yaml
apiVersion: batch/v1
kind: Job
metadata:
name: myjob
namespace: ns
spec:
template:
spec:
containers:
- name: job1
image: alpine
command:
- echo
- "hello world"
restartPolicy: Never
```
> 💡 **Note:** Always set `restartPolicy` to `Never` or `OnFailure` for jobs.
> 📌 Jobs are useful for tasks like backups, report generation, or database migrations.

51
Containerization-Orchestration/Kubernetes/workloads/08-Cronjobs.md Normal file
View File

@@ -0,0 +1,51 @@
# ⏰ Kubernetes CronJobs
A **CronJob** in Kubernetes allows you to run jobs on a recurring schedule, similar to traditional UNIX `cron` jobs. Ideal for periodic tasks like backups, reports, or scheduled notifications.
---
## 🔍 CronJob Commands
### 📄 List CronJobs in a Namespace
```bash
kubectl get cronjobs.batch -n <namespace>
````
### ❌ Delete a CronJob
```bash
kubectl delete cronjobs.batch -n <namespace> <cronjob-name>
```
---
## 🧾 Example CronJob Manifest
This CronJob runs every minute and prints the date followed by "Kubernetes":
```yaml
apiVersion: batch/v1
kind: CronJob
metadata:
name: cronjob1
namespace: ns
spec:
schedule: "* * * * *"
jobTemplate:
spec:
template:
spec:
containers:
- name: cronjob
image: debian:bookworm
command:
- /bin/bash
- -c
- date; echo Kubernetes
restartPolicy: Never
```
> 🛠 **Fix:** Changed `JobTemplate` to `jobTemplate` (YAML keys are case-sensitive).
> 🕐 The `schedule` field follows standard cron format: `minute hour day-of-month month day-of-week`.
> 🧠 **Tip:** Always test cron timing carefully to avoid unintentional frequent runs.

144
Containerization-Orchestration/Kubernetes/workloads/09-Services.md Normal file
View File

@@ -0,0 +1,144 @@
# 🔗 **Kubernetes Services (SVC)**
A **Service** in Kubernetes provides a stable network endpoint to access a set of Pods. It abstracts access through selectors and DNS names, enabling loose coupling between client applications and Pods.
---
## 🌐 **Service Basics**
### 📌 **Service Flow**
```
Service ➡️ Endpoint ➡️ Pods
```
* Services **group Pods** behind a single access point.
* They get a **cluster-wide DNS name** automatically.
* Use **label selectors** to forward traffic to matching Pods.
---
## 🧭 **Types of Services**
1. **ClusterIP** (default)
* Only reachable within the cluster.
2. **NodePort**
* Exposes the service via a static port on each node.
3. **LoadBalancer**
* Creates an external IP address using a cloud provider.
---
## 🧪 **Useful Commands**
### 🔍 Get Endpoints
```bash
kubectl get ep -n <namespace>
```
### 📄 Get Services
```bash
kubectl get svc -n <namespace>
```
```bash
kubectl expose deployment web-server-dep -n dev --port 80
```
---
## 🔁 **Port Forwarding**
To access a service from your local machine, forward a local port to the service port:
```bash
kubectl port-forward -n <namespace> svc/<service-name> <local-port>:<target-port>
```
> **Example:**
> Forward local port `8080` to port `80` of `my-service` in the `mynamespace` namespace:
>
> ```bash
> kubectl port-forward -n mynamespace svc/my-service 8080:80
> ```
You can also bind to all network interfaces:
```bash
kubectl port-forward -n <namespace> svc/nginx 80:80 --address 0.0.0.0
```
> 🌐 **DNS format:**
> `<service-name>.<namespace>.svc.cluster.local`
---
## 🧾 **Example Service Manifest**
```yaml
apiVersion: v1
kind: Service
metadata:
name: nginx
namespace: ns
labels:
app: web-server
spec:
type: ClusterIP # Options: ClusterIP, NodePort, LoadBalancer
selector:
app: nginx
ports:
- name: http
port: 80
targetPort: 8080
```
> 🔍 **Note:** The `selector` must match the labels of the target Pods.
> 🧠 **Tip:** Use `kubectl describe svc <service-name>` to inspect the service and verify connectivity.
```yaml
apiVersion: v1
kind: Service
metadata:
name: nginx
namespace: ns
labels:
app: web-server
spec:
type: LoadBalancer
selector:
app: nginx
ports:
- name: http
port: 80
targetPort: 8080
```
```yaml
apiVersion: v1
kind: Service
metadata:
name: db-svc
namespace: db
spec:
type: NodePort
ports:
- name: sql
port: 3306
targetPort: 3306
nodePort: 30000
selector:
app: db
```

189
Containerization-Orchestration/Kubernetes/workloads/10-Deployment-With-Services.md Normal file
View File

@@ -0,0 +1,189 @@
### **1st Document: Namespace**
```yaml
apiVersion: v1
```
* Specifies the API version used. Here, it's version 1 of the core Kubernetes API.
```yaml
kind: Namespace
```
* Declares the resource type. This is a **Namespace**, which logically isolates groups of resources.
```yaml
metadata:
name: ns
```
* Metadata block.
* `name: ns` sets the name of the namespace to `ns`.
---
### **2nd Document: Service**
```yaml
---
```
* Separates multiple documents in the YAML file.
```yaml
apiVersion: v1
```
* Uses the core v1 API again.
```yaml
kind: Service
```
* Declares a **Service** resource, which provides stable networking to access pods.
```yaml
metadata:
name: nginx-service
namespace: ns
labels:
app: nginx
```
* Metadata block:
* `name: nginx-service`: name of the Service.
* `namespace: ns`: places this service in the previously created `ns` namespace.
* `labels`: key-value pairs used for organizing and selecting resources. Here, `app: nginx`.
```yaml
spec:
type: ClusterIP
```
* `spec` describes the behavior.
* `type: ClusterIP`: exposes the service internally within the cluster using a virtual IP.
```yaml
selector:
app: nginx
```
* This selects pods with the label `app: nginx` to receive traffic from this service.
```yaml
ports:
- name: http
port: 80
targetPort: 8080
```
* Defines port configuration:
* `name: http`: a name for the port (optional but useful for readability).
* `port: 80`: the port that the service exposes internally.
* `targetPort: 8080`: the port on the pod that receives the traffic.
---
### **3rd Document: Deployment**
```yaml
---
```
* Separates from the previous document.
```yaml
apiVersion: apps/v1
```
* Uses the `apps/v1` API group, suitable for deployments and other controllers.
```yaml
kind: Deployment
```
* Declares a **Deployment**, which ensures a specified number of pod replicas are running.
```yaml
metadata:
name: nginx-deployment
namespace: ns
labels:
app: nginx
```
* Metadata block:
* `name: nginx-deployment`: name of the deployment.
* `namespace: ns`: places this in the `ns` namespace.
* `labels: app: nginx`: used for matching with selectors.
```yaml
spec:
replicas: 2
```
* Desired number of pod replicas to run: 2.
```yaml
selector:
matchLabels:
app: nginx
```
* Tells the deployment which pods to manage, by matching labels (`app: nginx`).
```yaml
template:
metadata:
labels:
app: nginx
```
* Template for creating new pods:
* Each pod created will have `app: nginx` label.
```yaml
spec:
containers:
- name: nginx
image: nginx:latest
```
* Pod spec:
* One container named `nginx`, using the latest official Nginx image.
```yaml
ports:
- containerPort: 8080
```
* The container exposes port 8080 (must match the `targetPort` in the Service).
```yaml
resources:
requests:
cpu: "100m"
memory: "128Mi"
limits:
cpu: "250m"
memory: "256Mi"
```
* **Resource management**:
* `requests`: the minimum guaranteed resources.
* `cpu: 100m` = 0.1 CPU core.
* `memory: 128Mi` = 128 MiB RAM.
* `limits`: the maximum resources the container can use.
* `cpu: 250m` = 0.25 CPU core.
* `memory: 256Mi` = 256 MiB RAM.

188
Containerization-Orchestration/Kubernetes/workloads/11-Config-map.md Normal file
View File

@@ -0,0 +1,188 @@
# 🧾 Kubernetes ConfigMap Guide
Manage configuration without hardcoding! `ConfigMaps` let you store external configurations as key-value pairs and inject them into Kubernetes workloads.
---
## 📘 What is a ConfigMap?
A **ConfigMap** is a Kubernetes object used to store **non-confidential configuration data** in **key-value** format. You can:
* 📄 Mount it as files inside a Pod
* 🌿 Use it as environment variables
* 🧩 Keep your container images decoupled from configuration
---
## ⚙️ Creating a ConfigMap
You can create a ConfigMap from files or directories:
```bash
kubectl -n <namespace> create configmap <configmap-name> --from-file=<file-or-directory>
```
### ✅ Examples
```bash
# From a single file
kubectl -n <ns> create configmap nginx-conf --from-file=./nginx.conf
# From multiple files
kubectl -n <ns> create configmap nginx-conf \
--from-file=./nginx.conf \
--from-file=./site.conf
```
---
## 📂 Viewing & Editing ConfigMaps
```bash
# List all ConfigMaps in a namespace
kubectl get cm -n <namespace>
# View detailed ConfigMap info
kubectl describe configmap <name> -n <namespace>
# Edit in-place
kubectl -n <namespace> edit configmap <configmap-name>
```
---
## 📄 YAML: ConfigMap Example
```yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: game-demo
data:
player_initial_lives: "3"
ui_properties_file_name: "user-interface.properties"
game.properties: |
enemy.types=aliens,monsters
player.maximum-lives=5
user-interface.properties: |
color.good=purple
color.bad=yellow
allow.textmode=true
```
---
## 💡 Usage Examples
### 📌 ConfigMap as Environment Variables
**ConfigMap:**
```yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: app-config
namespace: default
data:
APP_MODE: "production"
LOG_LEVEL: "info"
FEATURE_FLAG_X: "enabled"
```
**Pod:**
```yaml
apiVersion: v1
kind: Pod
metadata:
name: my-app
spec:
containers:
- name: my-container
image: busybox
command: ["/bin/sh", "-c", "env && sleep 3600"]
envFrom:
- configMapRef:
name: app-config
```
---
### 🧾 Mounting ConfigMap as a File (nginx.conf example)
**ConfigMap:**
```yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: nginx-config
namespace: default
data:
nginx.conf: |
worker_processes 1;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
server {
listen 80;
server_name localhost;
location / {
root /usr/share/nginx/html;
index index.html index.htm;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /usr/share/nginx/html;
}
}
}
```
**Pod:**
```yaml
apiVersion: v1
kind: Pod
metadata:
name: nginx-pod
spec:
containers:
- name: nginx
image: nginx:latest
volumeMounts:
- name: nginx-config-volume
mountPath: /etc/nginx/nginx.conf
subPath: nginx.conf
volumes:
- name: nginx-config-volume
configMap:
name: nginx-config
```
---
## 🛠 Pro Tips
* 🔐 For **sensitive data**, use **Secrets** instead of ConfigMaps.
* 🧪 Combine ConfigMaps with **Deployment** objects for flexible, versioned config management.
* 📦 Use `--from-env-file` to load multiple key-value pairs from a `.env` style file:
```bash
kubectl create configmap my-config --from-env-file=env.list
```

21
Containerization-Orchestration/Kubernetes/workloads/12-Resource-quota.md Normal file
View File

@@ -0,0 +1,21 @@
resource Quota:
```bash
kubectl get resourcequota -n <ns>
```
```yaml
apiVersion: v1
kind: ResourceQuota
metadata:
name: my-ns-quota
namcespace: dev
spec:
hard:
pod: 10
requests.cpu: "1"
requests.memory: "1024Mb"
service: "5"
configmap: "2"
```

78
Containerization-Orchestration/Kubernetes/workloads/13-Secret.md Normal file
View File

@@ -0,0 +1,78 @@
# 🔐 Kubernetes Secrets Guide
Kubernetes **Secrets** are used to store and manage sensitive information such as passwords, OAuth tokens, and SSH keys. Unlike ConfigMaps, they are specifically designed for confidential data.
---
## 📌 Types of Kubernetes Secrets
| **Built-in Type** | **Usage** |
| ------------------------------------- | --------------------------------------- |
| `Opaque` | Arbitrary user-defined data |
| `kubernetes.io/service-account-token` | ServiceAccount token |
| `kubernetes.io/dockercfg` | Serialized `~/.dockercfg` file |
| `kubernetes.io/dockerconfigjson` | Serialized `~/.docker/config.json` file |
| `kubernetes.io/basic-auth` | Credentials for basic authentication |
| `kubernetes.io/ssh-auth` | Credentials for SSH authentication |
| `kubernetes.io/tls` | Data for a TLS client or server |
| `bootstrap.kubernetes.io/token` | Bootstrap token data |
---
## 📂 Creating a Secret
You can create a Secret directly with `kubectl`:
```bash
kubectl create secret generic db-pass --from-literal=password='123'
```
Verify it exists:
```bash
kubectl get secret db-pass
```
---
## 📜 Secret YAML Example
```yaml
apiVersion: v1
kind: Secret
metadata:
name: db-pass
type: Opaque
stringData:
password: '123'
```
---
## 🚀 Using a Secret in a Pod
Secrets can be injected into a Pod as **environment variables**:
```yaml
apiVersion: v1
kind: Pod
metadata:
name: mariadb-db
spec:
containers:
- name: mariadb
image: mariadb
env:
- name: MARIADB_ROOT_PASSWORD
valueFrom:
secretKeyRef:
name: db-pass
key: password
```
This example sets the MariaDB root password from the `db-pass` Secret.
---
✅ **Pro Tip**: Always base64-encode values when writing Secrets directly in YAML. Kubernetes expects the `data` field in base64, not plaintext.

2
Containerization-Orchestration/Kubernetes/workloads/14-Ingress.md Normal file
View File

@@ -0,0 +1,2 @@
traffic input --> ingress
traffic output --> egress

20
Containerization-Orchestration/Kubernetes/workloads/manifests/cronjob.yaml Normal file
View File

@@ -0,0 +1,20 @@
apiVersion: batch/v1
kind: CronJob
metadata:
name: cronjob1
namespace: ns-test
spec:
schedule: "* * * * *"
jobTemplate:
spec:
template:
spec:
containers:
- name: mycronjob
image: debian
command:
- /bin/bash
- -c
- "echo 'Hello, CronJob!'"
restartPolicy: Never

52
Containerization-Orchestration/Kubernetes/workloads/manifests/deployment-with-service.yaml Normal file
View File

@@ -0,0 +1,52 @@
apiVersion: v1
kind: Namespace
metadata:
name: ns
---
apiVersion: v1
kind: Service
metadata:
name: nginx-service
namespace: ns
labels:
app: nginx
spec:
type: ClusterIP
selector:
app: nginx
ports:
- name: http
port: 80
targetPort: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
namespace: ns
labels:
app: nginx
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 8080
resources:
requests:
cpu: "100m"
memory: "128Mi"
limits:
cpu: "250m"
memory: "256Mi"

28
Containerization-Orchestration/Kubernetes/workloads/manifests/deployment.yaml Normal file
View File

@@ -0,0 +1,28 @@
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-deployment
namespace: ns-test
labels:
name: deployment-test
spec:
replicas: 2
selector:
matchLabels:
name: app1
template:
metadata:
labels:
name: app1
spec:
containers:
- name: nginx-deployment
image: nginx:1.26
resources:
limits:
cpu: "400m"
memory: "512Mi"
requests:
cpu: "200m"
memory: "128Mi"

19
Containerization-Orchestration/Kubernetes/workloads/manifests/ds.yml Normal file
View File

@@ -0,0 +1,19 @@
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: daemonset-test
namespace: ns-test
spec:
selector:
matchLabels:
name: node-exporter
template:
metadata:
labels:
name: node-exporter
spec:
containers:
- name: node-exporter
image: prom/node-exporter

15
Containerization-Orchestration/Kubernetes/workloads/manifests/job.yaml Normal file
View File

@@ -0,0 +1,15 @@
apiVersion: batch/v1
kind: Job
metadata:
name: job1
namespace: ns-test
spec:
template:
spec:
containers:
- name: job-container
image: debian
command:
- echo
- "hello world"
restartPolicy: Never

5
Containerization-Orchestration/Kubernetes/workloads/manifests/namespace.yaml Normal file
View File

@@ -0,0 +1,5 @@
apiVersion: v1
kind: Namespace
metadata:
name: ns-test

23
Containerization-Orchestration/Kubernetes/workloads/manifests/pod.yaml Normal file
View File

@@ -0,0 +1,23 @@
apiVersion: v1
kind: Pod
metadata:
namespace: ns-test
name: pod-tests
labels:
var1: var1_value
var2: var2_value
app.kubernetes.io/var3: var3_value
app.kubernetes.io/var4: var4_value
spec:
containers:
- name: nginx
image: nginx
resources:
limits:
memory: "150Mi"
cpu: "500m"
requests:
memory: "100Mi"
cpu: "200m"
nodeSelector:
kubernetes.io/hostname: kuber-2

18
Containerization-Orchestration/Kubernetes/workloads/manifests/replicaset.yml Normal file
View File

@@ -0,0 +1,18 @@
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: app1
namespace: ns-test
spec:
replicas: 3
selector:
matchLabels:
app.kubernetes.io/name: app1
template:
metadata:
labels:
app.kubernetes.io/name: app1
spec:
containers:
- name: nginx
image: nginx

15
Containerization-Orchestration/Kubernetes/workloads/manifests/service.yaml Normal file
View File

@@ -0,0 +1,15 @@
apiVersion: v1
kind: Service
metadata:
name: nginx
namespace: ns-test
labels:
app: nginx
spec:
type: NodePort # ClusterIP Or LoadBalancer
selector:
app: nginx
ports:
- name: http
port: 80
targetPort: 80

49
Containerization-Orchestration/Kubernetes/workloads/manifests/state-full-set.yaml Normal file
View File

@@ -0,0 +1,49 @@
---
apiVersion: v1
kind: Service
metadata:
labels:
app: nginx
name: nginx
spec:
clusterIP: None
ports:
- name: web
port: 80
selector:
app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: simple-stateful-set
spec:
replicas: 3 # the default is 1
selector:
matchLabels:
app: nginx # has to match .spec.template.metadata.labels
serviceName: "nginx"
template:
metadata:
labels:
app: nginx # has to match .spec.selector.matchLabels
spec:
terminationGracePeriodSeconds: 10
containers:
- image: nginx
name: nginx
ports:
- containerPort: 80
name: web
volumeMounts:
- mountPath: /usr/share/nginx/html
name: www
volumeClaimTemplates:
- metadata:
name: www
spec:
accessModes: ["ReadWriteOnce"]
resources:
requests:
storage: 1Gi
storageClassName: "longhorn "