3 posts tagged with "Devops"

Here is a universal structure that applies to ALL Kubernetes YAML files, plus memory tricks to never forget it!

The Universal Kubernetes YAML Structure​

Every Kubernetes resource follows this 4-part structure:

apiVersion: <api-group>/<version>
kind: <ResourceType>
metadata:
  name: <resource-name>
  namespace: <namespace>
  labels:
    key: value
  annotations:
    key: value
spec:
  # Resource-specific configuration goes here

Memory Trick: "AKM-S"​

Api version Kind Metadata Spec

Or remember: "A Kind Metadata Spec" - like you're specifying a kind of metadata!

The 4 Core Fields Explained​

1. apiVersion - Which API to use​

Format: <api-group>/<version> or just <version>

Common values:

apiVersion: v1                           # Core resources
apiVersion: apps/v1                      # Deployments, StatefulSets
apiVersion: batch/v1                     # Jobs
apiVersion: networking.k8s.io/v1         # Ingress
apiVersion: autoscaling/v2              # HPA
apiVersion: rbac.authorization.k8s.io/v1 # RBAC

2. kind - Type of resource​

kind: Pod
kind: Deployment
kind: Service
kind: ConfigMap
kind: Secret
# ... etc

3. metadata - Identifying information​

Always has:

• name (required)
• namespace (optional, defaults to "default")
• labels (optional but recommended)
• annotations (optional)

metadata:
  name: my-app
  namespace: production
  labels:
    app: my-app
    version: v1
    env: prod
  annotations:
    description: "My application"

4. spec - Desired state (varies by resource)​

This is where the resource-specific configuration goes. Changes based on kind.

Common Kubernetes Resources Cheat Sheet​

Pod (Basic building block)​

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: nginx
spec:
  containers:
    - name: nginx
      image: nginx:latest
      ports:
        - containerPort: 80

Spec structure for Pod:

• containers[] - List of containers
  • name, image, ports[], env[], resources, volumeMounts[]
• volumes[] - Storage volumes
• restartPolicy - Always/OnFailure/Never

Deployment (Manages Pods)​

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:1.19
          ports:
            - containerPort: 80

Spec structure for Deployment:

• replicas - Number of pods
• selector - How to find pods to manage
• template - Pod template (has its own metadata + spec)

Service (Networking)​

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  type: ClusterIP # ClusterIP, NodePort, LoadBalancer
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80 # Service port
      targetPort: 80 # Container port

Spec structure for Service:

• type - ClusterIP/NodePort/LoadBalancer
• selector - Which pods to send traffic to
• ports[] - Port mappings

ConfigMap (Configuration data)​

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  database_url: "postgres://db:5432"
  log_level: "info"

Spec structure for ConfigMap:

• Uses data instead of spec
• Key-value pairs

Secret (Sensitive data)​

apiVersion: v1
kind: Secret
metadata:
  name: app-secret
type: Opaque
data:
  username: YWRtaW4= # base64 encoded
  password: cGFzc3dvcmQ=

Spec structure for Secret:

• Uses data or stringData instead of spec
• Values must be base64 encoded in data

Interview Strategy: The Template Method​

Step 1: Start with the skeleton (10 seconds)

apiVersion:
kind:
metadata:
  name:
spec:

Step 2: Fill in the basics (20 seconds)

apiVersion: apps/v1 # Know common ones
kind: Deployment # What they asked for
metadata:
  name: my-app # Descriptive name
spec:
  # Now focus here

Step 3: Add spec details (30 seconds)

For each resource type, remember the key spec fields:

Most Common Interview Questions​

Q: "Write a Deployment with 3 replicas"​

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: app
          image: nginx:latest

Key points:

• selector.matchLabels MUST match template.metadata.labels
• Template is a Pod spec inside Deployment spec

Q: "Expose this Deployment as a Service"​

apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  selector:
    app: my-app # Match the Deployment's pod labels
  ports:
    - port: 80
      targetPort: 8080
  type: ClusterIP

Q: "Create a ConfigMap and mount it in a Pod"​

ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  config.yaml: |
    database:
      host: localhost
      port: 5432

Pod using ConfigMap:

apiVersion: v1
kind: Pod
metadata:
  name: app
spec:
  containers:
    - name: app
      image: myapp
      volumeMounts:
        - name: config
          mountPath: /etc/config
  volumes:
    - name: config
      configMap:
        name: app-config

Quick Reference Card (Memorize This!)​

┌─────────────────────────────────────────┐
│  KUBERNETES YAML STRUCTURE              │
├─────────────────────────────────────────┤
│  apiVersion: <group>/<version>          │
│  kind: <ResourceType>                   │
│  metadata:                              │
│    name: <name>                         │
│    namespace: <namespace>               │
│    labels:                              │
│      <key>: <value>                     │
│  spec:                                  │
│    <resource-specific-fields>           │
└─────────────────────────────────────────┘

COMMON apiVersion VALUES:
• v1                    → Pod, Service, ConfigMap, Secret
• apps/v1              → Deployment, StatefulSet, DaemonSet
• batch/v1             → Job, CronJob
• networking.k8s.io/v1 → Ingress

DEPLOYMENT PATTERN:
spec:
  replicas: <number>
  selector:
    matchLabels:
      app: <app-name>
  template:
    metadata:
      labels:
        app: <app-name>  ← Must match selector!
    spec:
      containers:
      - name: <container-name>
        image: <image>

🎓 Interview Tips​

1. Always start with AKM-S structure​

Write the skeleton first, then fill in details.

2. Know these by heart:​

• Pod spec: containers[]
• Deployment spec: replicas, selector, template
• Service spec: selector, ports[], type

3. Remember the "selector-label" rule​

Service selector must match Pod labels Deployment selector.matchLabels must match template.metadata.labels

4. Container essentials:​

containers:
  - name: <name>
    image: <image>
    ports:
      - containerPort: <port>

5. If you forget, explain your thinking​

"I know the structure is apiVersion, kind, metadata, and spec. For a Deployment, I need replicas, a selector to match pods, and a template that defines the pod specification..."

6. Common mistakes to avoid:​

• ❌ Forgetting selector.matchLabels in Deployment
• ❌ Mismatching labels between selector and pod
• ❌ Wrong apiVersion (use apps/v1 for Deployments)
• ❌ Using spec in ConfigMap/Secret (it's data)

🚀 Practice Exercise​

Try writing these from memory:

1. A Deployment with 2 replicas running nginx:1.19
2. A Service exposing the above deployment on port 80
3. A ConfigMap with database connection string
4. A Pod that uses the ConfigMap as environment variables

📚 Bonus: Multi-Resource YAML​

You can combine multiple resources in one file with ---:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: app
          image: nginx
---
apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  selector:
    app: my-app
  ports:
    - port: 80
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: my-app-config
data:
  env: production

Final Memory Aid​

Before the interview, write this on your paper:

A-K-M-S
v1, apps/v1, batch/v1
Pod: containers
Deploy: replicas, selector, template
Service: selector, ports, type

With this structure in mind, you can write any Kubernetes YAML!

OpenAPI JSON as Frontend Types​

install the requirement

npm install -D openapi-typescript-codegen

Add the type generator script to your package.json

{
  "scripts": {
    "generate-api": "openapi --input http://your-backend-url/openapi.json --output src/types/api --client fetch"
  }
}

run the generator

npm run generate-api

You can now import and use the types in your application

import { Resume, UserResume } from "@/types/api";

interface Props {
  resume: UserResume; // Generated type from your FastAPI schema
}

const ResumeComponent: React.FC<Props> = ({ resume }) => {
  // ...
};

Introduction to Linux​

Linux is an operating system similar to the famous Windows OS we are all used to. A computer is made up of Software, Hardware and Peripheral units as we were taught in introductory class to computer science. Operating System is a type of software (Any non-physical component of the computer is referred to as software). The Operating System manages and controls the computer's resources and facilitates the interaction between humans and the computer. The computer is uselss without an operating system.

Why Linux​

Linux is free and open source operating system and powers a wide range of devices, from smartphones, laptops, servers and supercomputers. Linux is highly customizable and secure which has made it to keep growing in popularity among developers, programmers, DEVOPs, MLOPs, Cybersecurity and power users globally.

• Open-source
• Secure
• Stable
• Flexible
• Huge Community
• Highly customizable

Linux File System​

The computer file system has a tree structure, navigating from a branch, node or leave to another is called walking the tree. You will need to navigate the tree structure to manage and use files and resources stored on the system. The image below shows the Linux file system.

• /home: User-specific files and configurations.
• /etc: System-wide configuration files.
• /var: Variable data like logs.
• /bin and /sbin: Essential and administrative binaries.

Linux Distributions​

A.k.a "distros" are customized versions of Linux OS for different end-user or target market. Popular distros include:

• Ubuntu: A very popular user friendly distribution.
• Fedora: Innovative and cutting-edge features
• Debian: Stable software repository

Linux Commands​

We split the basic commands into 2 parts: File Navigation and File Manipulation

File Navigation​

• ls: List files in or contents of a directory
• cd: Changes the current drectory
• pwd: Prints the current working directory.

File Manipulation​

Linux provides powerful commands for file creation, editting and management:

• touch: creates empty files.
• cp: Copy files from source to destination. A copy is retained in source.
• mv: Moves file from source to destination. No copy is retained in source.

Student Practice Exercises​

1. List the contents of the current directory:

ls

2. List contents of current working directory including hidden contents.

ls -a

3. Practise:

   1. Navigate to your home directory and list all its contents.
   2. Use ls -l to display detailed information about each file in the directory

4. Change directory to a specific location

   I. Create a new directory called school

   mkdir school

II. Go into the new directory

cd school

III. Navigate to /tmp directory and back to your home directory

5. create nested directories i.e one or more directories inside another directory.

mkdir -p school/classes

6. create an empty file.

touch artclass.txt

I. create a file named notes.txt in the school/classes directory II. create three files at once: teachers.txt, students.txt, subjects.txt

7. copy a file

cp notes.txt copy_of_notes.txt

8. copy a directory recursively

cp -r school/ school_copy/

9. Rename a file

mv old_name.txt new_name.txt

I. move a file to another directory:

mv notes.txt /home/backup/

10. Delete a file

rm notes.txt

11. Delete a directory and its contents recursively

rm -r classes/

12. Remove an empty directory.

rmdir school/

13. show command history

history

14. run a specific command from history

!5

15. print a text

echo "I love linux."

16. write text to a file

echo "I mean it, I really love Linux." > love_linux.txt

17. read content of a file:

cat students.txt

18. Combine files

cat students.txt classes.txt subjects.txt > combined.txt

More Practice​

1. Navigate to your home directory.
2. Create a directory called linux_practice.
3. Inside linux_practice, create two subdirectories: data and scripts.
4. Create three files inside data: file1.txt, file2.txt, and file3.txt.
5. Copy all files from data to scripts.
6. Rename file3.txt in scripts to file3_backup.txt.
7. Delete the data directory along with its contents.
8. View your command history to confirm all the steps you performed.