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

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 "