DEV Community: Aisalkyn Aidarova

Two-Day Homework — CI `needs` + Build + Docker

Aisalkyn Aidarova — Tue, 22 Sep 2026 18:52:03 +0000

The goal is to reproduce this entire architecture independently:

Developer
   ↓
Feature Branch
   ↓
Pull Request
   ↓
┌──────── Lint ────────┐
│                      │
├──────── SonarQube ────┼──→ ALL PASS
│                      │       ↓
└──────── Trivy ────────┘     needs
                               ↓
                             Build
                               ↓
                             dist/
                               ↓
                           Dockerfile
                               ↓
                         Docker Image
                               ↓
                           Container
                               ↓
                      Host 8080 → 80
                               ↓
                             Nginx
                               ↓
                     Restaurant Company

Part 1 — Git preparation

Start from the repository:

cd ~/restaurant-company

git status
git branch

git switch main
git pull origin main

git switch -c homework-needs-docker

Verify:

git branch
git status

Students must explain: What is main? Why do we create a feature branch? Why do we run git pull before creating the branch? What does git status tell us?

Part 2 — Review the three parallel CI jobs

Open:

cat .github/workflows/ci.yml

Students must identify:

lint
sonarqube
trivy

They should write answers to these questions:

What is a Job? What is a Runner? What is a Step? Why can Lint, SonarQube and Trivy run in parallel? What is the difference between parallel jobs and sequential steps? What does runs-on: ubuntu-latest mean?

They should draw:

               ┌── Lint
               │
Pull Request ──┼── SonarQube
               │
               └── Trivy

Part 3 — Yesterday's main topic: `needs`

Students must add/review:

build:
  name: Build
  runs-on: ubuntu-latest

  needs:
    - lint
    - sonarqube
    - trivy

They must explain every line.

Especially:

needs:
  - lint
  - sonarqube
  - trivy

Written questions:

What does needs mean? What is a dependent job? What is an independent job? Are lint, sonarqube, and trivy job IDs or display names? Why shouldn't Build start immediately?

Then explain:

Lint       ✅
SonarQube  ✅
Trivy      ✅
              ↓
Build      ▶ RUN

versus:

Lint       ✅
SonarQube  ✅
Trivy      ❌
              ↓
Build      ⏭ SKIPPED

Students must answer:

What is the difference between FAILED and SKIPPED?

Part 4 — Build Job

Complete/review:

build:
  name: Build
  runs-on: ubuntu-latest

  needs:
    - lint
    - sonarqube
    - trivy

  steps:
    - name: Checkout code
      uses: actions/checkout@v4

    - name: Setup Node.js
      uses: actions/setup-node@v4
      with:
        node-version: 22
        cache: npm

    - name: Install dependencies
      run: npm ci

    - name: Build application
      run: npm run build

    - name: Verify build
      run: ls -la dist

Students explain:

Checkout
   ↓
Setup Node
   ↓
npm ci
   ↓
npm run build
   ↓
dist/
   ↓
Verify

Written questions: What does npm ci do? Which file locks exact dependencies? Where does npm run build come from? What does Vite create? What is dist/? Why do we run ls -la dist?

Part 5 — Commit, Push and Pull Request

Before committing:

git status
git diff

Then:

git add .github/workflows/ci.yml

git status

git commit -m "Add dependent build job"

git push -u origin homework-needs-docker

Create a Pull Request:

homework-needs-docker
        ↓
   Pull Request
        ↓
       main

Open GitHub Actions.

Take a screenshot showing the jobs.

Students should be able to explain:

        ┌── Lint ────────┐
        │                 │
PR ─────┼── SonarQube ────┼──→ Build
        │                 │
        └── Trivy ────────┘

Part 6 — Docker Fundamentals

Now today's material.

Before touching commands, students write definitions for:

Docker, Dockerfile, Docker Image, Container, Container Runtime.

Then explain:

Dockerfile
    ↓
docker build
    ↓
Image
    ↓
docker run
    ↓
Container

They must clearly answer:

What is the difference between an Image and a Container?

Part 7 — Study the Restaurant Company Dockerfile

Run:

cat Dockerfile

Study:

FROM node:22-alpine AS builder

WORKDIR /app

COPY package*.json ./

RUN npm ci

COPY . .

RUN npm run build


FROM nginx:alpine

COPY nginx.conf /etc/nginx/conf.d/default.conf

COPY --from=builder /app/dist /usr/share/nginx/html

EXPOSE 80

CMD ["nginx", "-g", "daemon off;"]

Students must explain every instruction:

FROM
AS builder
WORKDIR
COPY
RUN
COPY --from
EXPOSE
CMD

Part 8 — Multi-stage Build

Students draw:

STAGE 1 — BUILDER
────────────────────

node:22-alpine
      ↓
package.json
package-lock.json
      ↓
npm ci
      ↓
Source Code
      ↓
npm run build
      ↓
/app/dist


          ↓ COPY


STAGE 2 — RUNTIME
────────────────────

nginx:alpine
      ↓
/usr/share/nginx/html
      ↓
Nginx
      ↓
Port 80

Questions:

Why do we have two FROM instructions? What is a multi-stage build? Why do we need Node.js during Build? Why can Nginx serve the final frontend? What does COPY --from=builder mean?

Part 9 — Build the Docker Image

Run:

docker --version

docker build -t restaurant-company:homework .

Then:

docker images

Take a screenshot.

Students explain:

docker build
-t
restaurant-company
:homework
.

Especially:

What does . mean?

Answer: current directory as the build context.

Part 10 — Run the Container

Run:

docker run -d \
  --name restaurant-homework \
  -p 8080:80 \
  restaurant-company:homework

Verify:

docker ps

Students explain:

docker run
-d
--name
-p
8080:80
restaurant-company:homework

Draw:

EC2 HOST
Port 8080
    ↓
Docker
    ↓
CONTAINER
Port 80
    ↓
Nginx

They must explain:

In 8080:80, which is Host and which is Container?

Part 11 — Go Inside the Container

Run:

docker exec -it restaurant-homework sh

Now inside:

cat /etc/os-release

hostname

pwd

Students answer:

My EC2 is Ubuntu. Why does the container show Alpine?

Then:

cd /usr/share/nginx/html

pwd

ls -la

Inspect:

cat index.html

ls assets

Then:

cat /etc/nginx/conf.d/default.conf

Students must connect this to Dockerfile:

COPY --from=builder /app/dist /usr/share/nginx/html

They should explain:

/app/dist
     ↓
COPY
     ↓
/usr/share/nginx/html

Part 12 — Exit Without Stopping the Container

Run:

exit

Then:

docker ps

Students answer:

Why is the container still running after I typed exit?

They need to understand that they exited their interactive shell; the container's main Nginx process is still running.

Part 13 — Test with curl

From EC2:

curl -I http://localhost:8080

Then:

curl http://localhost:8080

Students should identify an HTTP response such as:

HTTP/1.1 200 OK
Server: nginx

Explain the request:

curl
 ↓
localhost:8080
 ↓
Docker Port Mapping
 ↓
Container :80
 ↓
Nginx
 ↓
Website

Take a screenshot.

Part 14 — Open Restaurant Company in Browser

Check AWS Security Group.

For the lab, allow the needed TCP 8080 access, preferably from the student's own IP when practical.

Then:

http://EC2-PUBLIC-IP:8080

Take a screenshot showing the Restaurant Company website.

Students must draw the complete architecture:

Laptop
   ↓
Browser
   ↓
Internet
   ↓
EC2 Public IP :8080
   ↓
AWS Security Group
   ↓
EC2 Host Port 8080
   ↓
Docker Port Mapping
   ↓
Container Port 80
   ↓
Nginx
   ↓
/usr/share/nginx/html
   ↓
Restaurant Company

Part 15 — Troubleshooting Incident

Now deliberately break the application:

docker stop restaurant-homework

Try:

curl -I http://localhost:8080

Then:

docker ps

Students should investigate:

docker ps -a

Find the problem.

Fix:

docker start restaurant-homework

Verify:

docker ps

curl -I http://localhost:8080

Refresh the browser.

Students write:

CHECK
 ↓
docker ps

FIND
 ↓
Container stopped

FIX
 ↓
docker start restaurant-homework

VERIFY
 ↓
docker ps
curl
browser

This should connect to your troubleshooting model:

CHECK → FIND → FIX → VERIFY

Part 16 — Command Challenge Without Notes

Students should be able to explain these commands without copying definitions:

docker build -t restaurant-company:homework .

docker images

docker run -d --name restaurant-homework -p 8080:80 restaurant-company:homework

docker ps

docker ps -a

docker exec -it restaurant-homework sh

docker stop restaurant-homework

docker start restaurant-homework

curl -I localhost:8080

Part 17 — Interview Questions

Students should write answers in their own words to these questions:

What is Docker? What problem does Docker solve? What is a Dockerfile? What is a Docker Image? What is a Container? Image vs Container? What does docker build do? What does docker run do? What does docker exec do? docker ps vs docker ps -a? What does -p 8080:80 mean? What is a multi-stage Docker build? Why does our first stage use Node.js? Why does our second stage use Nginx? What is dist/? What does COPY --from=builder do? Why is the EC2 Ubuntu but the container Alpine? What is needs in GitHub Actions? Why do Lint/SonarQube/Trivy run in parallel? Why does Build wait? What happens to Build when a required job fails?

Interview answer to practice

“In our CI pipeline, Lint, SonarQube and Trivy run as independent jobs in parallel. Our Build job depends on those required checks using needs. After the checks pass, we build the Vite application and produce the dist directory. We then use a multi-stage Dockerfile: Node.js builds the application, and the final Nginx stage serves the built files. We build a Docker image and run it as a container with host port 8080 mapped to container port 80.”

Production Lab: Restaurant Company — Helm + Argo CD + EKS

Aisalkyn Aidarova — Tue, 22 Sep 2026 01:56:49 +0000

GitHub = Source of Truth
Helm = Templates + Values
Argo CD = GitOps CD / Reconciliation
Kubernetes = Runtime
AWS Load Balancer Controller = Creates ALB
ECR = Stores Restaurant image

Use fake classroom secrets only; don't commit real credentials.

1. Architecture

Developer
    │
    │ git push
    ▼
GitHub Repository
    │
    │
    ├── Helm Chart
    │   ├── templates/
    │   └── values.yaml
    │
    ▼
Argo CD
    │
    │ Helm rendering
    │
    │ Desired vs Actual
    │
    │ Reconciliation
    ▼
Kubernetes API
    │
    ├── ConfigMap
    ├── ServiceAccount
    ├── Deployment
    │      ↓
    │   ReplicaSet
    │      ↓
    │     Pods
    │
    ├── Service
    ├── HPA
    ├── PDB
    └── Ingress
           │
           ▼
 AWS Load Balancer Controller
           │
           ▼
          ALB
           │
           ▼
     Restaurant Pods

2. Repository structure

Have students create:

restaurant-company-gitops/
│
├── argocd/
│   └── application.yaml
│
└── helm/
    └── restaurant/
        ├── Chart.yaml
        ├── values.yaml
        ├── values-prod.yaml
        │
        └── templates/
            ├── namespace.yaml
            ├── configmap.yaml
            ├── serviceaccount.yaml
            ├── deployment.yaml
            ├── service.yaml
            ├── pdb.yaml
            ├── hpa.yaml
            └── ingress.yaml

For the first production lab, I would not put a plaintext Secret in Git. Explain that production GitOps requires a proper secret-management pattern.

3. `Chart.yaml`

Create:

apiVersion: v2

name: restaurant-company

description: Production Helm chart for Restaurant Company

type: application

version: 0.1.0

appVersion: "1.0.0"

Explain:

version
↓
version of Helm chart

appVersion
↓
version of our application

4. `values.yaml`

This contains sensible defaults:

namespace:
  name: restaurant-prod

replicaCount: 2

image:
  repository: YOUR_AWS_ACCOUNT_ID.dkr.ecr.us-east-1.amazonaws.com/restaurant-company
  tag: latest
  pullPolicy: Always

container:
  port: 80

serviceAccount:
  name: restaurant-sa

service:
  type: ClusterIP
  port: 80
  targetPort: 80

config:
  appName: "Restaurant Company"
  environment: "production"
  logLevel: "info"

resources:
  requests:
    cpu: "100m"
    memory: "128Mi"

  limits:
    cpu: "500m"
    memory: "256Mi"

probes:
  startup:
    path: /
    periodSeconds: 5
    failureThreshold: 12

  readiness:
    path: /
    periodSeconds: 5
    failureThreshold: 3

  liveness:
    path: /
    periodSeconds: 10
    failureThreshold: 3

rollingUpdate:
  maxUnavailable: 1
  maxSurge: 1

pdb:
  enabled: true
  minAvailable: 2

autoscaling:
  enabled: true
  minReplicas: 2
  maxReplicas: 10
  targetCPUUtilizationPercentage: 70

ingress:
  enabled: true
  className: alb
  scheme: internet-facing
  targetType: ip

Students must replace:

YOUR_AWS_ACCOUNT_ID

with their own account ID and make sure the ECR repository name is correct.

5. `values-prod.yaml`

Now show why Helm is useful.

replicaCount: 3

image:
  tag: latest

config:
  environment: "production"
  logLevel: "info"

resources:
  requests:
    cpu: "200m"
    memory: "256Mi"

  limits:
    cpu: "500m"
    memory: "512Mi"

autoscaling:
  enabled: true
  minReplicas: 3
  maxReplicas: 10
  targetCPUUtilizationPercentage: 70

pdb:
  enabled: true
  minAvailable: 2

Explain:

values.yaml gives us defaults. values-prod.yaml overrides only production-specific values.

6. Namespace template

templates/namespace.yaml

apiVersion: v1
kind: Namespace

metadata:
  name: {{ .Values.namespace.name }}

  labels:
    environment: {{ .Values.config.environment }}
    app.kubernetes.io/managed-by: Helm

7. ConfigMap

templates/configmap.yaml

apiVersion: v1
kind: ConfigMap

metadata:
  name: restaurant-config
  namespace: {{ .Values.namespace.name }}

data:
  APP_NAME: {{ .Values.config.appName | quote }}
  APP_ENV: {{ .Values.config.environment | quote }}
  LOG_LEVEL: {{ .Values.config.logLevel | quote }}

Explain:

values-prod.yaml
      ↓
Helm
      ↓
ConfigMap
      ↓
Pod environment

8. ServiceAccount

templates/serviceaccount.yaml

apiVersion: v1
kind: ServiceAccount

metadata:
  name: {{ .Values.serviceAccount.name }}
  namespace: {{ .Values.namespace.name }}

Important teaching point:

This Kubernetes ServiceAccount does not automatically give the Pod AWS permissions. For AWS API access from EKS workloads, we'd separately configure the appropriate AWS workload identity mechanism.

9. Production Deployment

templates/deployment.yaml

apiVersion: apps/v1
kind: Deployment

metadata:
  name: restaurant
  namespace: {{ .Values.namespace.name }}

  labels:
    app: restaurant

spec:
  replicas: {{ .Values.replicaCount }}

  strategy:
    type: RollingUpdate

    rollingUpdate:
      maxUnavailable: {{ .Values.rollingUpdate.maxUnavailable }}
      maxSurge: {{ .Values.rollingUpdate.maxSurge }}

  selector:
    matchLabels:
      app: restaurant

  template:

    metadata:
      labels:
        app: restaurant
        environment: {{ .Values.config.environment }}

    spec:

      serviceAccountName: {{ .Values.serviceAccount.name }}

      terminationGracePeriodSeconds: 30

      containers:

        - name: restaurant

          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"

          imagePullPolicy: {{ .Values.image.pullPolicy }}

          ports:

            - name: http
              containerPort: {{ .Values.container.port }}
              protocol: TCP

          envFrom:

            - configMapRef:
                name: restaurant-config

          resources:

            requests:
              cpu: {{ .Values.resources.requests.cpu | quote }}
              memory: {{ .Values.resources.requests.memory | quote }}

            limits:
              cpu: {{ .Values.resources.limits.cpu | quote }}
              memory: {{ .Values.resources.limits.memory | quote }}

          startupProbe:

            httpGet:
              path: {{ .Values.probes.startup.path }}
              port: http

            periodSeconds: {{ .Values.probes.startup.periodSeconds }}

            failureThreshold: {{ .Values.probes.startup.failureThreshold }}

          readinessProbe:

            httpGet:
              path: {{ .Values.probes.readiness.path }}
              port: http

            periodSeconds: {{ .Values.probes.readiness.periodSeconds }}

            failureThreshold: {{ .Values.probes.readiness.failureThreshold }}

          livenessProbe:

            httpGet:
              path: {{ .Values.probes.liveness.path }}
              port: http

            periodSeconds: {{ .Values.probes.liveness.periodSeconds }}

            failureThreshold: {{ .Values.probes.liveness.failureThreshold }}

This lets you review several concepts simultaneously:

Helm values
Deployment
Rolling Update
Resources
ConfigMap
ServiceAccount
Startup Probe
Readiness Probe
Liveness Probe

10. Service

templates/service.yaml

apiVersion: v1
kind: Service

metadata:
  name: restaurant-service
  namespace: {{ .Values.namespace.name }}

spec:

  type: {{ .Values.service.type }}

  selector:
    app: restaurant

  ports:

    - name: http
      protocol: TCP
      port: {{ .Values.service.port }}
      targetPort: {{ .Values.service.targetPort }}

Architecture:

Service
selector:
app=restaurant
       │
       ▼
Pods
label:
app=restaurant

11. PodDisruptionBudget

templates/pdb.yaml

{{- if .Values.pdb.enabled }}

apiVersion: policy/v1
kind: PodDisruptionBudget

metadata:
  name: restaurant-pdb
  namespace: {{ .Values.namespace.name }}

spec:

  minAvailable: {{ .Values.pdb.minAvailable }}

  selector:

    matchLabels:
      app: restaurant

{{- end }}

This introduces another Helm feature:

{{ if }}

Explain:

Helm can conditionally generate Kubernetes resources.

If:

pdb:
  enabled: false

Helm doesn't render this PDB.

12. HPA

templates/hpa.yaml

{{- if .Values.autoscaling.enabled }}

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler

metadata:
  name: restaurant-hpa
  namespace: {{ .Values.namespace.name }}

spec:

  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: restaurant

  minReplicas: {{ .Values.autoscaling.minReplicas }}

  maxReplicas: {{ .Values.autoscaling.maxReplicas }}

  metrics:

    - type: Resource

      resource:

        name: cpu

        target:
          type: Utilization
          averageUtilization: {{ .Values.autoscaling.targetCPUUtilizationPercentage }}

{{- end }}

Remind them:

CPU-based HPA requires working resource metrics, commonly provided by Metrics Server, and CPU utilization percentage depends on CPU requests.

13. ALB Ingress

templates/ingress.yaml

{{- if .Values.ingress.enabled }}

apiVersion: networking.k8s.io/v1
kind: Ingress

metadata:
  name: restaurant-ingress
  namespace: {{ .Values.namespace.name }}

  annotations:

    alb.ingress.kubernetes.io/scheme: {{ .Values.ingress.scheme | quote }}

    alb.ingress.kubernetes.io/target-type: {{ .Values.ingress.targetType | quote }}

spec:

  ingressClassName: {{ .Values.ingress.className }}

  rules:

    - http:

        paths:

          - path: /
            pathType: Prefix

            backend:

              service:

                name: restaurant-service

                port:
                  number: {{ .Values.service.port }}

{{- end }}

Important:

Creating this Ingress alone is not enough to create an AWS ALB. The AWS Load Balancer Controller must already be installed and correctly authorized in the EKS cluster.

Architecture:

Ingress YAML
     ↓
AWS Load Balancer Controller
     ↓
AWS API
     ↓
ALB
     ↓
Target Group
     ↓
Restaurant Pods

14. Validate the Helm chart

Before touching Argo CD:

cd helm/restaurant

Run:

helm lint .

Then:

helm template restaurant . \
  -f values-prod.yaml

Tell students:

helm template does not deploy the application. It shows us what Kubernetes YAML Helm generates.

You can save it for inspection:

helm template restaurant . \
  -f values-prod.yaml \
  > rendered.yaml

Then:

less rendered.yaml

This is a fantastic teaching step:

templates/
      +
values.yaml
      +
values-prod.yaml
      ↓
     HELM
      ↓
rendered.yaml
      ↓
Normal Kubernetes manifests

Delete the generated file afterward if you don't want it committed:

rm rendered.yaml

15. Optional: Test Helm manually first

For learning, before introducing Argo CD, students can test:

helm upgrade --install restaurant . \
  -f values-prod.yaml \
  -n restaurant-prod \
  --create-namespace

Then:

helm list -n restaurant-prod

And:

kubectl get all -n restaurant-prod

However, after switching this application to Argo CD management, stop manually deploying it with Helm.

That's important.

Learning Helm:
helm install / helm upgrade

        ↓

Production GitOps lesson:
git push → Argo CD

16. Clean up the manual Helm release before Argo CD

If you installed the application manually for the Helm exercise:

helm uninstall restaurant -n restaurant-prod

Verify:

helm list -n restaurant-prod

Then let Argo CD own the deployment.

This avoids teaching students to have both manual Helm and Argo CD competing to manage the same application.

17. Argo CD Application YAML

Now create:

argocd/application.yaml

apiVersion: argoproj.io/v1alpha1
kind: Application

metadata:
  name: restaurant-company
  namespace: argocd

spec:

  project: default

  source:

    repoURL: https://github.com/YOUR_GITHUB_USERNAME/restaurant-company-gitops.git

    targetRevision: main

    path: helm/restaurant

    helm:

      valueFiles:
        - values-prod.yaml

  destination:

    server: https://kubernetes.default.svc

    namespace: restaurant-prod

  syncPolicy:

    automated:

      prune: true

      selfHeal: true

    syncOptions:

      - CreateNamespace=true

Students replace:

YOUR_GITHUB_USERNAME

with their repository owner.

18. Push everything to GitHub

From the repository root:

git add .

git commit -m "Add production Restaurant Helm GitOps configuration"

git push

Now Git contains:

GitHub

restaurant-company-gitops/
        │
        ├── argocd/
        │
        │    └── application.yaml
        │
        │
        └── helm/
             └── restaurant/
                  ├── Chart.yaml
                  ├── values.yaml
                  ├── values-prod.yaml
                  └── templates/

19. Bootstrap the Argo CD Application

This is the one initial kubectl apply students may see:

kubectl apply -f argocd/application.yaml

Explain carefully:

We are not manually deploying the Restaurant application with this command. We are registering an Argo CD Application that tells Argo CD where the Git source of truth lives.

After that, normal application changes happen through Git.

Check:

kubectl get applications -n argocd

Then open Argo CD.

20. What Argo CD now does

This is the key architecture:

GitHub
 │
 │ restaurant Helm chart
 │
 ▼
Argo CD
 │
 ├── reads Chart.yaml
 ├── reads values.yaml
 ├── applies values-prod.yaml overrides
 │
 ▼
Helm rendering
 │
 ▼
Kubernetes manifests
 │
 ▼
Argo CD compares
 │
 ├── Desired State — Git
 │
 └── Actual State — EKS
 │
 ▼
Reconcile
 │
 ▼
EKS

Students do not need to run:

helm upgrade restaurant ...

and do not run:

kubectl apply -f deployment.yaml

for normal GitOps changes.

21. GitOps Lab #1 — Scale 3 → 5

Current production value:

replicaCount: 3

Check:

kubectl get pods -n restaurant-prod

Now change values-prod.yaml:

replicaCount: 5

Then:

git add helm/restaurant/values-prod.yaml

git commit -m "Scale Restaurant Company to 5 replicas"

git push

Do NOT run Helm.

Do NOT run kubectl apply.

Watch:

kubectl get pods -n restaurant-prod -w

With auto-sync enabled:

values-prod.yaml

3 → 5
 │
 ▼
git push
 │
 ▼
GitHub
 │
 ▼
Argo CD
 │
 ▼
Helm render
 │
 ▼
Deployment replicas: 5
 │
 ▼
Kubernetes
 │
 ▼
5 Pods

That connects the entire course.

22. GitOps Lab #2 — Configuration Drift

Git says:

replicaCount: 5

Now intentionally change the live cluster:

kubectl scale deployment restaurant \
  --replicas=1 \
  -n restaurant-prod

Watch:

kubectl get pods -n restaurant-prod -w

Because Argo CD has:

selfHeal: true

the important model is:

Git Desired State
5

      ≠

Live State
1

      ↓

CONFIGURATION DRIFT

      ↓

Argo CD selfHeal

      ↓

Live State reconciled
toward 5

Tell them:

This is why we call Git our Source of Truth.

23. GitOps Lab #3 — Bad Image

Now teach troubleshooting.

Change:

image:
  tag: latest

to a tag that doesn't exist:

image:
  tag: broken-version

Commit:

git add .

git commit -m "Demo broken Restaurant image"

git push

Argo CD may successfully reconcile the desired configuration while the workload becomes unhealthy.

Check:

kubectl get pods -n restaurant-prod

Then:

kubectl describe pod POD_NAME -n restaurant-prod

Likely:

ErrImagePull
ImagePullBackOff

Teach:

Argo CD:
"I deployed what Git requested."

Kubernetes:
"I cannot run this image."

Therefore:

SYNCED ≠ HEALTHY

Fix it in Git, not directly in the Deployment:

image:
  tag: latest

Then:

git add .
git commit -m "Fix Restaurant image"
git push

Argo CD should reconcile the fix.

24. GitOps Lab #4 — PDB condition

Show them this:

pdb:
  enabled: true

Render:

helm template restaurant helm/restaurant \
  -f helm/restaurant/values-prod.yaml

PDB exists.

Change:

pdb:
  enabled: false

Render again.

PDB disappears from the rendered desired manifests.

That's Helm conditional logic:

enabled: true
      ↓
Helm generates PDB


enabled: false
      ↓
Helm doesn't generate PDB

If this change is pushed while Argo CD prune is enabled, Argo CD can remove the previously managed PDB because it is no longer part of desired state.

That demonstrates Helm + Argo CD prune together.

25. Student troubleshooting checklist

Give them this exact order:

# Argo application
kubectl get applications -n argocd

# Namespace resources
kubectl get all -n restaurant-prod

# Pods
kubectl get pods -n restaurant-prod -o wide

# Deployment
kubectl describe deployment restaurant -n restaurant-prod

# Pod problems
kubectl describe pod POD_NAME -n restaurant-prod

# Application logs
kubectl logs POD_NAME -n restaurant-prod

# Service
kubectl get svc -n restaurant-prod
kubectl describe svc restaurant-service -n restaurant-prod

# Service endpoints
kubectl get endpointslice \
  -n restaurant-prod \
  -l kubernetes.io/service-name=restaurant-service

# HPA
kubectl get hpa -n restaurant-prod

# PDB
kubectl get pdb -n restaurant-prod

# Ingress
kubectl get ingress -n restaurant-prod
kubectl describe ingress restaurant-ingress -n restaurant-prod

Final diagram for the students

                 PRODUCTION GITOPS

                      Developer
                          │
                     git push
                          │
                          ▼
                       GitHub
                  SOURCE OF TRUTH
                          │
                          │
                ┌─────────┴─────────┐
                │                   │
           Helm Templates      values-prod.yaml
                │                   │
                └─────────┬─────────┘
                          │
                          ▼
                       Argo CD
                          │
                     Helm Render
                          │
                          ▼
                 Kubernetes YAML
                          │
                 Compare/Reconcile
                          │
                          ▼
                    Kubernetes API
                          │
       ┌──────────────────┼─────────────────┐
       │                  │                 │
       ▼                  ▼                 ▼
  Deployment           Service          Ingress
       │                  │                 │
       ▼                  │                 ▼
  ReplicaSet              │        AWS LB Controller
       │                  │                 │
       ▼                  │                 ▼
     Pods ◀───────────────┘                ALB
       ▲                                    │
       └────────────────────────────────────┘

The four sentences I would require every student to know are:

Helm = package manager and templating for Kubernetes.
Argo CD = GitOps Continuous Delivery and reconciliation.
Git = Source of Truth / Desired State.
Kubernetes = Actual State and runtime.

And the production workflow they should remember is:

Change values/templates
        ↓
git commit
        ↓
git push
        ↓
Argo CD
        ↓
Helm render
        ↓
Compare desired vs actual
        ↓
Reconcile
        ↓
EKS

Once Argo CD owns this application, the normal workflow is not kubectl apply and not manual helm upgrade — it is git push.

WEEKEND HOMEWORK — Restaurant Company CI

Aisalkyn Aidarova — Fri, 18 Sep 2026 21:47:58 +0000

Goal: Practice Trivy, understand vulnerabilities and dependency trees, and create a GitHub Actions pipeline with 3 independent parallel jobs: Lint, SonarQube, and Trivy.

Part 1 — Trivy manual security scan

Go to the project:

cd ~/restaurant-company
pwd

Run the normal vulnerability scan:

trivy fs --scanners vuln .

Then include development dependencies:

trivy fs --scanners vuln --include-dev-deps .

Answer in your homework:

1. What is Trivy?
2. What does "fs" mean?
3. What does "." mean?
4. What does "vuln" mean?
5. What is a CVE?
6. What is Severity?
7. What is the difference between HIGH and MEDIUM?
8. Why did our first scan show 0 vulnerabilities?
9. Why did the scan with --include-dev-deps find vulnerabilities?
10. Does "0 vulnerabilities" mean an application is 100% secure? Explain.

Take a screenshot of the Trivy result.

Part 2 — Investigate the dependencies

Run:

npm ls nanoid

Then:

npm ls postcss

Students should identify the dependency chain:

Restaurant Company
        ↓
Vite
        ↓
PostCSS
        ↓
nanoid

Answer:

1. What is a dependency?
2. What is a transitive dependency?
3. Why is nanoid installed in our project?
4. Which package brings PostCSS into the project?
5. Which package brings nanoid into the dependency tree?

Take a screenshot of both commands.

Part 3 — Read the Trivy vulnerability report

From your scan, identify:

Library
CVE
Severity
Installed Version
Fixed Version

Create a small report like:

Finding 1

Library:
CVE:
Severity:
Installed Version:
Fixed Version:


Finding 2

Library:
CVE:
Severity:
Installed Version:
Fixed Version:

Then answer:

What does "Installed Version" mean?

What does "Fixed Version" mean?

If Trivy says a fixed version exists,
does that mean our project is already fixed?

Why should a DevOps Engineer care about dependency vulnerabilities?

Part 4 — Create a new Git branch

Start from updated main:

git switch main
git pull origin main

Create your homework branch:

git switch -c weekend-ci-homework

Check:

git branch
git status

Part 5 — Create GitHub Actions CI

Create/open:

mkdir -p .github/workflows
nano .github/workflows/ci.yml

The pipeline must contain three separate jobs:

                   ┌──── LINT ────────┐
                   │                   │
PULL REQUEST ──────┼──── SONARQUBE ────┼──→ RESULTS
                   │                   │
                   └──── TRIVY ────────┘

Requirements:

Trigger:
pull_request → main

Job 1:
Lint

Job 2:
SonarQube

Job 3:
Trivy

These must be separate jobs, not three steps inside one job.

Part 6 — Explain Parallel Jobs

Answer in your own words:

1. What is a GitHub Actions job?

2. What is a runner?

3. What is the difference between a Job and a Step?

4. Why can Lint, SonarQube and Trivy run independently?

5. What does "parallel jobs" mean?

6. Why can parallel jobs make CI faster?

7. Does Lint need to wait for Trivy before starting?

8. Does Trivy need the SonarQube result before starting?

Draw this architecture yourself:

                    ┌── Lint
Pull Request ───────┼── SonarQube
                    └── Trivy

Take a picture/screenshot of your drawing.

Part 7 — Push and create Pull Request

git status
git add .
git commit -m "Add weekend CI homework"
git push -u origin weekend-ci-homework

Go to GitHub and create:

weekend-ci-homework
        ↓
Pull Request
        ↓
main

Then open:

GitHub → Actions

Find your jobs:

Lint
SonarQube
Trivy

Take a screenshot showing the jobs.

If something fails, do not immediately delete or change things randomly.

Use our troubleshooting method:

CHECK
  ↓
FIND
  ↓
FIX
  ↓
VERIFY

Open the failed job → find failed step → read logs → identify root cause → fix → commit → push → verify the new run.

Part 8 — Weekend interview questions

Students should be ready to answer these without reading notes:

What is CI?

What is GitHub Actions?

What is a workflow?

What is a job?

What is a runner?

What is a step?

What is Lint?

What is SonarQube?

What is SonarScanner?

What is a Quality Gate?

What is Trivy?

What is a CVE?

What is a dependency?

What is a transitive dependency?

What is the difference between
SonarQube and Trivy?

What are parallel jobs?

Why would you run security checks in CI?

A good interview answer they can practice:

“In our project, we use GitHub Actions for CI. When a developer creates a Pull Request, independent jobs such as Lint, SonarQube, and Trivy can run in parallel. Lint checks code standards, SonarQube performs code analysis and evaluates the Quality Gate, and Trivy scans for known vulnerabilities.”

JumpToTech — Production Kubernetes Complete Lab

Aisalkyn Aidarova — Fri, 18 Sep 2026 01:12:41 +0000

Level: Beginner → Intermediate
Platform: AWS EKS
Duration: ~3 hours
Language: English
Goal: Build a production-style Kubernetes deployment from scratch and troubleshoot it.

1. What We Will Build

By the end of the lab:

                         INTERNET
                            │
                            ▼
                           ALB
                            │
                            ▼
                         INGRESS
                            │
                            ▼
                         SERVICE
                       ClusterIP :80
                            │
                    selector: app=web
                            │
              ┌─────────────┼─────────────┐
              ▼             ▼             ▼
            POD 1          POD 2         POD 3
              │             │             │
          Container     Container     Container
              │             │             │
              └─────────────┼─────────────┘
                            ▲
                        ReplicaSet
                            ▲
                            │
                        Deployment
                            │
             ┌──────────────┼───────────────┐
             │              │               │
         ConfigMap        Secret      ServiceAccount

Additional protection:

Requests/Limits → Resource management
Readiness       → Traffic readiness
Liveness        → Container health
Startup Probe   → Startup protection
PDB             → Disruption availability
HPA             → Automatic scaling
NetworkPolicy   → Network restrictions
RBAC            → Kubernetes authorization

Everything will be deployed into:

jumptotech-prod

2. Project Structure

Create the project:

mkdir production-k8s-lab
cd production-k8s-lab

Our final directory:

production-k8s-lab/
│
├── 01-namespace.yaml
├── 02-configmap.yaml
├── 03-secret.yaml
├── 04-serviceaccount.yaml
├── 05-deployment.yaml
├── 06-service.yaml
├── 07-pdb.yaml
├── 08-hpa.yaml
├── 09-ingress.yaml
├── 10-networkpolicy.yaml
├── 11-role.yaml
└── 12-rolebinding.yaml

This numbering is intentional because students can apply resources in a logical order.

3. Verify the Cluster

Before touching YAML:

kubectl get nodes

Expected:

NAME                              STATUS
ip-172-31-10-20.ec2.internal     Ready
ip-172-31-20-30.ec2.internal     Ready

Explain:

A Kubernetes cluster contains a Control Plane and Worker Nodes. On EKS, AWS manages the control plane. Our application workloads normally run on worker nodes.

Check where existing Pods are running:

kubectl get pods -A -o wide

Architecture:

EKS
│
├── AWS-managed Control Plane
│
└── Worker Nodes
      │
      ├── kubelet
      ├── container runtime
      └── Pods

4. Namespace

Create:

nano 01-namespace.yaml

apiVersion: v1
kind: Namespace

metadata:
  name: jumptotech-prod

  labels:
    environment: production
    team: jumptotech

Apply:

kubectl apply -f 01-namespace.yaml

Verify:

kubectl get namespaces

What is a Namespace?

A Namespace creates a logical scope inside a cluster.

EKS Cluster
│
├── default
│
├── kube-system
│
├── dev
│
├── test
│
└── jumptotech-prod

It does not create another Kubernetes cluster.

It helps organize and scope resources, permissions, quotas, names, and policies.

For the rest of the lab:

kubectl config set-context --current --namespace=jumptotech-prod

Check:

kubectl config view --minify | grep namespace

Now our commands default to jumptotech-prod.

5. ConfigMap

Applications require configuration.

For example:

APP_NAME
APP_ENV
LOG_LEVEL

These should not necessarily be hard-coded into the Docker image.

Create:

nano 02-configmap.yaml

apiVersion: v1
kind: ConfigMap

metadata:
  name: web-config
  namespace: jumptotech-prod

data:
  APP_NAME: "JumpToTech"
  APP_ENV: "production"
  LOG_LEVEL: "info"

Apply:

kubectl apply -f 02-configmap.yaml

Check:

kubectl get configmap

Then:

kubectl describe configmap web-config

Explain:

Docker Image
    │
    ├── application code
    └── dependencies

ConfigMap
    │
    └── environment-specific
        non-sensitive configuration

6. Secret

Should this go into ConfigMap?

DB_PASSWORD=my-secret-password

No.

Kubernetes provides the Secret resource.

Create:

nano 03-secret.yaml

For our lab only:

apiVersion: v1
kind: Secret

metadata:
  name: web-secret
  namespace: jumptotech-prod

type: Opaque

stringData:
  DB_USERNAME: "admin"
  DB_PASSWORD: "student-demo-password"

Apply:

kubectl apply -f 03-secret.yaml

Check:

kubectl get secrets

Do not print real secrets during a production troubleshooting session.

Teach:

ConfigMap
    ↓
Non-sensitive configuration


Secret
    ↓
Sensitive configuration

Important production lesson:

Kubernetes Secret is a Kubernetes object designed for sensitive data, but simply putting a value in a Secret does not make every secret-management problem disappear.

And:

Base64 ≠ Encryption

For production GitOps, do not commit real plaintext passwords like this lab example.

7. ServiceAccount

Our application should have a Kubernetes workload identity.

Create:

nano 04-serviceaccount.yaml

apiVersion: v1
kind: ServiceAccount

metadata:
  name: web-sa
  namespace: jumptotech-prod

Apply:

kubectl apply -f 04-serviceaccount.yaml

Check:

kubectl get serviceaccount

Teach:

ServiceAccount
      ↓
WHO AM I?

RBAC
      ↓
WHAT AM I ALLOWED TO DO?

A ServiceAccount does not automatically give the Pod administrator permissions.

8. Production Deployment

Now create the central object.

nano 05-deployment.yaml

Replace YOUR_ECR_IMAGE with your actual ECR image.

apiVersion: apps/v1
kind: Deployment

metadata:
  name: web-deployment
  namespace: jumptotech-prod

  labels:
    app: web

spec:

  replicas: 3

  strategy:
    type: RollingUpdate

    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1

  selector:
    matchLabels:
      app: web

  template:

    metadata:
      labels:
        app: web
        environment: production

    spec:

      serviceAccountName: web-sa

      terminationGracePeriodSeconds: 30

      containers:

        - name: web-container

          image: YOUR_ECR_IMAGE

          imagePullPolicy: IfNotPresent

          ports:
            - name: http
              containerPort: 80
              protocol: TCP

          envFrom:
            - configMapRef:
                name: web-config

          env:

            - name: DB_USERNAME
              valueFrom:
                secretKeyRef:
                  name: web-secret
                  key: DB_USERNAME

            - name: DB_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: web-secret
                  key: DB_PASSWORD

          resources:

            requests:
              cpu: "100m"
              memory: "128Mi"

            limits:
              cpu: "500m"
              memory: "256Mi"

          startupProbe:

            httpGet:
              path: /
              port: http

            periodSeconds: 5
            failureThreshold: 12

          readinessProbe:

            httpGet:
              path: /
              port: http

            periodSeconds: 5
            timeoutSeconds: 2
            failureThreshold: 3

          livenessProbe:

            httpGet:
              path: /
              port: http

            periodSeconds: 10
            timeoutSeconds: 2
            failureThreshold: 3

Don't apply yet.

Explain the important pieces first.

9. Deployment → ReplicaSet → Pod

We said:

replicas: 3

This represents desired state.

Deployment
     │
     │ desired replicas = 3
     ▼
ReplicaSet
     │
     ├──────────┬──────────┐
     ▼          ▼          ▼
   Pod 1      Pod 2      Pod 3

Deployment primarily handles things such as:

Desired application state
Rollouts
Rollbacks
ReplicaSet management

ReplicaSet maintains the desired Pod replica count.

10. Labels and Selectors

Our Pod template has:

labels:
  app: web

Deployment selector:

selector:
  matchLabels:
    app: web

Later our Service will also use:

selector:
  app: web

Students should memorize the relationship, not the syntax:

              app=web

Deployment ────────────────┐
                           │
                    ┌──────▼──────┐
                    │    POD      │
                    │             │
                    │ app = web   │
                    └──────▲──────┘
                           │
Service ───────────────────┘
selector app=web

11. Requests

We have:

requests:
  cpu: "100m"
  memory: "128Mi"

When a Pod needs scheduling:

New Pod
   │
   │ requests
   │ CPU: 100m
   │ RAM: 128Mi
   ▼
Scheduler
   │
   ├── Node A
   ├── Node B
   └── Node C

The Scheduler uses requests when determining whether the Pod fits on a Node.

CPU:

1000m = 1 CPU
500m  = 0.5 CPU
250m  = 0.25 CPU
100m  = 0.1 CPU

12. Limits

We have:

limits:
  cpu: "500m"
  memory: "256Mi"

Simple classroom explanation:

REQUEST
   ↓
Scheduler capacity calculation


LIMIT
   ↓
Runtime resource ceiling

If CPU demand exceeds an enforced CPU limit:

CPU
 ↓
throttling

If memory usage exceeds an enforced memory limit:

Memory
  ↓
OOM
  ↓
process/container may be killed
  ↓
OOMKilled

13. Startup Probe

Now we have three probes.

First:

startupProbe:

Question:

Has my application successfully started?

This is especially useful for applications that can take time to initialize.

Container starts
       │
       ▼
 Startup Probe
       │
       ├── failing → still starting
       │
       └── succeeds
               │
               ▼
       Liveness/Readiness
       take over

Our configuration:

periodSeconds: 5
failureThreshold: 12

gives the application roughly up to 60 seconds of startup checking before startup failure reaches the configured threshold.

14. Readiness Probe

readinessProbe:
  httpGet:
    path: /
    port: http

Question:

Should this Pod receive traffic?

When you run:

kubectl get pods

you might see:

NAME                 READY   STATUS
web-abc123            1/1    Running

1/1 means:

1 container Ready
───────────────
1 readiness-counted container in this Pod

If:

0/1 Running

the Pod can still:

Exist             YES
Be Running        YES
Have an IP        YES

but:

Ready             NO

Therefore it should not be used as a normal ready Service backend.

15. Liveness Probe

Question:

Is this application still healthy enough to keep running?

Repeated failures:

Liveness Probe
      │
      ▼
    FAIL
      │
    FAIL
      │
    FAIL
      │
      ▼
failureThreshold reached
      │
      ▼
    kubelet
      │
      ▼
restart container

The important distinction:

READINESS
"Should I receive traffic?"


LIVENESS
"Should this container keep running?"


STARTUP
"Has the application successfully started?"

16. RollingUpdate Strategy

We added:

strategy:
  type: RollingUpdate

  rollingUpdate:
    maxUnavailable: 1
    maxSurge: 1

Suppose:

Current version = v1
Desired version = v2

Kubernetes does not necessarily kill all v1 Pods simultaneously.

Conceptually:

v1   v1   v1

        ↓

v1   v1   v1   v2

        ↓

v1   v1   v2

        ↓

v1   v2   v2

        ↓

v2   v2   v2

maxUnavailable controls how many desired Pods may be unavailable during the update.

maxSurge controls how many extra Pods above the desired replica count may temporarily be created.

17. Apply Deployment

Now:

kubectl apply -f 05-deployment.yaml

Watch:

kubectl get pods -w

Then:

kubectl get deployment

kubectl get rs

kubectl get pods -o wide

Students should physically see:

Deployment
   ↓
ReplicaSet
   ↓
Pods

18. Inspect a Pod

Get a Pod name:

kubectl get pods

Then:

kubectl describe pod POD_NAME

Find:

Node
Labels
IP
Service Account

Container:
  Image
  Port

Requests
Limits

Startup
Readiness
Liveness

Events

This is a very important production troubleshooting command.

19. Verify ConfigMap

kubectl exec POD_NAME -- printenv APP_NAME

Expected:

JumpToTech

Then:

kubectl exec POD_NAME -- printenv APP_ENV

Expected:

production

We have now proved:

ConfigMap
    ↓
Deployment
    ↓
Pod
    ↓
Container
    ↓
Environment Variable

20. Service

Pods are disposable.

Today:

Pod A
10.0.1.10

Tomorrow:

Pod B
10.0.2.25

Applications should not rely on individual Pod IP addresses.

Create:

nano 06-service.yaml

apiVersion: v1
kind: Service

metadata:
  name: web-service
  namespace: jumptotech-prod

spec:

  type: ClusterIP

  selector:
    app: web

  ports:

    - name: http
      protocol: TCP
      port: 80
      targetPort: http

Apply:

kubectl apply -f 06-service.yaml

Check:

kubectl get svc

21. Understand `port` vs `targetPort`

We have:

port: 80
targetPort: http

Our named container port is:

ports:
  - name: http
    containerPort: 80

Conceptually:

Client
   │
   ▼
Service
port 80
   │
   ▼
targetPort http
   │
   ▼
Pod
containerPort 80

22. EndpointSlice

Run:

kubectl get pods -o wide

Look at the Pod IPs.

Then:

kubectl get endpointslice \
-l kubernetes.io/service-name=web-service

For more detail:

kubectl get endpointslice \
-l kubernetes.io/service-name=web-service \
-o yaml

Architecture:

Service
   │
selector app=web
   │
   ▼
matching Pods
   │
   ▼
EndpointSlice

This is one of the most useful troubleshooting relationships:

SERVICE HAS NO EXPECTED BACKENDS?

Check:

Service selector
       ↓
Pod labels
       ↓
Pod readiness
       ↓
EndpointSlice

23. Test Service Before ALB

Run:

kubectl port-forward service/web-service 8080:80

Open:

http://localhost:8080

If it works:

Browser
   ↓
localhost:8080
   ↓
port-forward
   ↓
Service
   ↓
Pod
   ↓
Container

This proves the application works before we add Ingress/ALB.

24. Production Troubleshooting Exercise — Break Readiness

Change:

readinessProbe:
  httpGet:
    path: /

to:

readinessProbe:
  httpGet:
    path: /does-not-exist

Apply:

kubectl apply -f 05-deployment.yaml

Watch:

kubectl get pods -w

You should see affected new Pods become:

0/1 Running

Now:

kubectl describe pod POD_NAME

Then:

kubectl get pods -o wide

Show students:

Running: YES
IP:      YES
Ready:   NO

Check:

kubectl get endpointslice \
-l kubernetes.io/service-name=web-service \
-o yaml

Then fix the readiness path:

path: /

and apply again.

25. Production Troubleshooting Exercise — Scheduler

Now break requests:

requests:
  cpu: "100"
  memory: "100Gi"

Apply:

kubectl apply -f 05-deployment.yaml

Check:

kubectl get pods

New Pods may remain:

Pending

Why?

Pod
requests:
100 CPU
100Gi memory
      │
      ▼
Scheduler
      │
      ├── Node 1 ❌
      ├── Node 2 ❌
      └── Node 3 ❌
              │
              ▼
            PENDING

Prove it:

kubectl describe pod POD_NAME

Look at:

Events

You may see:

Insufficient cpu
Insufficient memory

Restore:

requests:
  cpu: "100m"
  memory: "128Mi"

Apply again.

26. PodDisruptionBudget

We have three replicas.

During supported voluntary disruptions, we want to preserve application availability.

Create:

nano 07-pdb.yaml

apiVersion: policy/v1
kind: PodDisruptionBudget

metadata:
  name: web-pdb
  namespace: jumptotech-prod

spec:

  minAvailable: 2

  selector:
    matchLabels:
      app: web

Apply:

kubectl apply -f 07-pdb.yaml

Check:

kubectl get pdb

Then:

kubectl describe pdb web-pdb

Think:

3 replicas

[Pod 1] [Pod 2] [Pod 3]

        PDB

 minAvailable = 2

Important:

PDB does not prevent every crash or Node failure.

It primarily constrains voluntary disruptions that use Kubernetes' eviction mechanisms.

27. Horizontal Pod Autoscaler

Check metrics first:

kubectl top pods

If metrics are available, create:

nano 08-hpa.yaml

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler

metadata:
  name: web-hpa
  namespace: jumptotech-prod

spec:

  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-deployment

  minReplicas: 3
  maxReplicas: 10

  behavior:

    scaleDown:
      stabilizationWindowSeconds: 300

  metrics:

    - type: Resource

      resource:

        name: cpu

        target:
          type: Utilization
          averageUtilization: 70

Apply:

kubectl apply -f 08-hpa.yaml

Check:

kubectl get hpa

Watch:

kubectl get hpa -w

Concept:

Metrics
   │
   ▼
 HPA
   │
   ▼
Deployment desired replicas
   │
   ▼
ReplicaSet
   │
   ▼
Pods


Low demand
↓
3 Pods


High CPU demand
↓
HPA
↓
more replicas
↓
up to 10 Pods

Important connection:

For CPU utilization-based HPA, CPU requests matter because utilization is evaluated relative to requested CPU.

28. Ingress + AWS ALB

Before creating it:

kubectl get deployment \
aws-load-balancer-controller \
-n kube-system

If the AWS Load Balancer Controller is installed, create:

nano 09-ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress

metadata:
  name: web-ingress
  namespace: jumptotech-prod

  annotations:

    alb.ingress.kubernetes.io/scheme: internet-facing

    alb.ingress.kubernetes.io/target-type: ip

spec:

  ingressClassName: alb

  rules:

    - http:

        paths:

          - path: /
            pathType: Prefix

            backend:

              service:

                name: web-service

                port:
                  number: 80

Apply:

kubectl apply -f 09-ingress.yaml

Watch:

kubectl get ingress -w

Eventually you may receive an ALB address.

29. Who Actually Creates the ALB?

This is important.

The flow is:

kubectl apply
       ↓
Ingress object
       ↓
Kubernetes API
       ↓
AWS Load Balancer Controller
       ↓
AWS API
       ↓
ALB
Listeners
Rules
Target Groups

The controller reconciles Kubernetes configuration into AWS infrastructure.

But customer runtime traffic is different:

CUSTOMER
    │
    ▼
   ALB
    │
    ▼
configured targets
    │
    ▼
  PODS

The AWS Load Balancer Controller does not sit in the middle of every HTTP request.

30. NetworkPolicy

Now introduce network security.

Without network policy enforcement, workloads may be able to communicate more broadly than you intend.

Create:

nano 10-networkpolicy.yaml

Example policy:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy

metadata:
  name: web-ingress-policy
  namespace: jumptotech-prod

spec:

  podSelector:
    matchLabels:
      app: web

  policyTypes:
    - Ingress

  ingress:

    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: jumptotech-prod

      ports:
        - protocol: TCP
          port: 80

Explain:

NetworkPolicy
      ↓
Which network connections
are allowed to/from selected Pods?

However, tell students something very important:

Creating a NetworkPolicy object only has an enforcement effect when the cluster's networking implementation supports and enforces Kubernetes NetworkPolicy. Verify your EKS networking configuration before treating this as protection.

Also, this particular example is for teaching namespace-scoped ingress and may need adjustment for the actual ALB traffic path in your cluster. Don't blindly deploy a restrictive policy to production without testing.

For that reason, in class I would inspect this file first, then apply it only if your cluster's NetworkPolicy enforcement and ALB path are already verified.

31. RBAC — Role

ServiceAccount gave us identity.

Now we can demonstrate authorization.

Create:

nano 11-role.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: Role

metadata:
  name: pod-reader
  namespace: jumptotech-prod

rules:

  - apiGroups:
      - ""

    resources:
      - pods

    verbs:
      - get
      - list
      - watch

This says:

Allowed resource:
Pods

Allowed actions:
GET
LIST
WATCH

It does not say:

delete Pods
create Pods
delete Deployments

32. RoleBinding

Now connect:

ServiceAccount
      +
    Role

Create:

nano 12-rolebinding.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding

metadata:
  name: web-pod-reader
  namespace: jumptotech-prod

subjects:

  - kind: ServiceAccount
    name: web-sa
    namespace: jumptotech-prod

roleRef:

  apiGroup: rbac.authorization.k8s.io

  kind: Role

  name: pod-reader

Apply:

kubectl apply -f 11-role.yaml
kubectl apply -f 12-rolebinding.yaml

Now teach:

ServiceAccount
web-sa
      │
      ▼
RoleBinding
      │
      ▼
Role
pod-reader
      │
      ▼
get
list
watch
Pods

Test authorization:

kubectl auth can-i list pods \
--as=system:serviceaccount:jumptotech-prod:web-sa \
-n jumptotech-prod

Expected:

yes

Try:

kubectl auth can-i delete pods \
--as=system:serviceaccount:jumptotech-prod:web-sa \
-n jumptotech-prod

Expected:

no

This is a fantastic live demonstration of least privilege.

33. Final Production Verification

Now run:

kubectl get deployment
kubectl get rs
kubectl get pods -o wide
kubectl get svc
kubectl get endpointslice
kubectl get configmap
kubectl get serviceaccount
kubectl get pdb
kubectl get hpa
kubectl get ingress
kubectl get networkpolicy
kubectl get role
kubectl get rolebinding

And:

kubectl get all

Important teaching point:

kubectl get all does not literally mean every Kubernetes resource type.

For example, you still separately inspect objects such as:

kubectl get ingress
kubectl get configmap
kubectl get secrets
kubectl get networkpolicy
kubectl get pdb

34. Production Troubleshooting Method

Teach students not to randomly type commands.

For a website that is unavailable, troubleshoot layer by layer:

Internet
   ↓
ALB
   ↓
Ingress
   ↓
Service
   ↓
EndpointSlice
   ↓
Pod Ready?
   ↓
Container
   ↓
Application

Use:

kubectl get ingress
kubectl describe ingress web-ingress

kubectl get svc
kubectl describe svc web-service

kubectl get endpointslice \
-l kubernetes.io/service-name=web-service

kubectl get pods -o wide

kubectl describe pod POD_NAME

kubectl logs POD_NAME

This troubleshooting order is more important than memorizing 50 kubectl commands.

35. What Each Production Feature Solves

Have students explain this without looking at notes:

Feature	Question it answers
Namespace	Where are these resources logically scoped?
Deployment	What workload state do I want?
ReplicaSet	How many matching Pods should exist?
Pod	Where does my workload execute?
Service	How do clients reach replaceable Pods through a stable service abstraction?
EndpointSlice	Which endpoints back the Service?
ConfigMap	Where is non-sensitive configuration?
Secret	Where is sensitive configuration represented?
ServiceAccount	What Kubernetes identity does the workload use?
Role	What namespaced Kubernetes API actions are permitted?
RoleBinding	Who receives those Role permissions?
Requests	What resources should scheduling account for?
Limits	What runtime resource ceiling applies?
Startup Probe	Has the application started?
Readiness Probe	Should it receive traffic?
Liveness Probe	Should kubelet restart an unhealthy container?
RollingUpdate	How should a Deployment replace versions?
PDB	How much availability should voluntary disruptions preserve?
HPA	Should replica count scale automatically?
NetworkPolicy	Which Pod network traffic should be permitted?
Ingress	What HTTP/HTTPS routing should exist?

36. Final Architecture Students Should Be Able to Draw

                              INTERNET
                                  │
                                  ▼
                                 ALB
                                  │
                                  ▼
                               INGRESS
                                  │
                                  ▼
                            web-service
                             ClusterIP
                                  │
                         selector app=web
                                  │
                    ┌─────────────┼─────────────┐
                    ▼             ▼             ▼
                  POD 1         POD 2         POD 3
                    │             │             │
                Container     Container     Container
                    ▲             ▲             ▲
                    └─────────────┼─────────────┘
                                  │
                              ReplicaSet
                                  ▲
                                  │
                              Deployment
                                  │
             ┌────────────────────┼────────────────────┐
             │                    │                    │
             ▼                    ▼                    ▼
         ConfigMap              Secret          ServiceAccount
                                                      │
                                                      ▼
                                               RoleBinding
                                                      │
                                                      ▼
                                                    Role


              ┌───────────────────────────────────────────┐
              │          PRODUCTION CONTROLS              │
              │                                           │
              │ Requests/Limits → Resources               │
              │ Startup        → Startup protection       │
              │ Readiness      → Traffic readiness        │
              │ Liveness       → Health/restart           │
              │ RollingUpdate  → Deployment strategy      │
              │ PDB            → Disruption availability  │
              │ HPA            → Scaling                  │
              │ NetworkPolicy  → Network security         │
              └───────────────────────────────────────────┘

HOMEWORK — SonarQube Real Analysis

Aisalkyn Aidarova — Thu, 17 Sep 2026 23:09:22 +0000

Project: Restaurant Company
Topic: Token → SonarScanner → Analysis → SonarQube Dashboard

Part 1 — Verify SonarQube connectivity

From your Restaurant Company EC2, run:

cd ~/restaurant-company

curl -I http://YOUR-SONARQUBE-IP:9000

Take a screenshot showing the HTTP response.

Answer in your own words:

What does HTTP 200 prove?

Expected concept: the EC2 can communicate with the SonarQube Server on port 9000.

Part 2 — Explain the configuration

Run:

cat sonar-project.properties

Your file should look similar to:

sonar.projectKey=restaurant-company
sonar.projectName=Restaurant Company
sonar.sources=src
sonar.sourceEncoding=UTF-8

Explain each property in one sentence:

sonar.projectKey =
sonar.projectName =
sonar.sources =
sonar.sourceEncoding =

Part 3 — SonarQube vs SonarScanner

Students must draw this architecture:

Restaurant Company
Source Code
       ↓
SonarScanner
       ↓
Analysis Report
       ↓
SonarQube Server :9000
       ↓
Restaurant Company Dashboard
       ↓
Quality Gate

Then answer:

1. What is SonarQube?
2. What is SonarScanner?
3. Why do we need both?

Part 4 — Token

Answer:

1. What is SONAR_TOKEN?
2. Why does SonarScanner need it?
3. Why should we never commit a real token to GitHub?
4. What is authentication?

Do not submit a screenshot containing the real token.

Students can verify that the variable exists without displaying the secret:

test -n "$SONAR_TOKEN" && echo "TOKEN IS SET"

Part 5 — Run the SonarQube analysis

From:

cd ~/restaurant-company

Run the same SonarScanner command used in class.

The student should find these messages:

Analysis report generated
Analysis report compressed
Analysis report uploaded

ANALYSIS SUCCESSFUL

SonarScanner Engine completed successfully

EXECUTION SUCCESS

Take a screenshot showing:

ANALYSIS SUCCESSFUL

Then explain:

What happened between starting SonarScanner
and seeing ANALYSIS SUCCESSFUL?

Expected flow:

READ SOURCE
    ↓
ANALYZE
    ↓
GENERATE REPORT
    ↓
COMPRESS REPORT
    ↓
UPLOAD REPORT
    ↓
SONARQUBE PROCESSES REPORT

Part 6 — SCM and Git

Find this part of the scanner output:

SCM Publisher

Answer:

1. What does SCM stand for?
2. Which SCM are we using?
3. What is a Git revision/commit ID?
4. Why is connecting an analysis to a Git revision useful?

Part 7 — SonarQube Dashboard

Open the Restaurant Company dashboard.

Take one screenshot of the dashboard.

Record what your current dashboard shows:

Quality Gate:
Security:
Reliability:
Maintainability:
Coverage:
Duplications:
Lines of Code:
Languages:

Your results may differ from another student's results.

Then answer:

Does Quality Gate PASSED mean there are zero issues?

Explain why.

Part 8 — Explain the metrics

Write one or two sentences explaining each:

Quality Gate
Security
Reliability
Maintainability
Security Hotspot
Coverage
Duplications
Lines of Code

Important:

PASSED ≠ PERFECT CODE

A Quality Gate can pass while SonarQube still reports issues because the gate evaluates its configured conditions.

Part 9 — Explain our 0% Coverage

Answer:

Why did our SonarQube dashboard show 0.0% Coverage?

Does SonarQube automatically create unit tests?

Where does Coverage data normally come from?

Draw:

TESTS
  ↓
COVERAGE TOOL
  ↓
COVERAGE REPORT
  ↓
SONARQUBE
  ↓
COVERAGE %

Part 10 — Interview Practice

Students should be able to say this without reading:

In our project, we use SonarScanner to analyze the Restaurant Company source code and submit the analysis to SonarQube. SonarQube processes and displays the results, including security, reliability, maintainability, coverage, duplications, and the Quality Gate. We use a token to authenticate the scanner to the SonarQube Server. A passed Quality Gate does not necessarily mean that the code has zero issues.

Production Kubernetes Helm Argo CD capstone lab

Aisalkyn Aidarova — Wed, 16 Sep 2026 23:10:11 +0000

LEVEL 1
Raw Kubernetes YAML
        ↓
LEVEL 2
Helm packages/templates the Kubernetes YAML
        ↓
LEVEL 3
Argo CD watches Git and deploys Helm to Kubernetes
        ↓
Production-style GitOps

I would structure the project like this.

JumpToTech Production Kubernetes + Helm + Argo CD Lab

Architecture

Developer
    │
    │ git push
    ▼
GitHub
    │
    │ watched by
    ▼
Argo CD
    │
    │ renders Helm chart
    ▼
Helm
    │
    │ produces Kubernetes manifests
    ▼
EKS Cluster
    │
    └── Namespace: jumptotech-prod
          │
          ├── ConfigMap
          ├── Secret
          ├── ServiceAccount
          │
          ├── Deployment
          │     │
          │     └── ReplicaSet
          │           │
          │           ├── Pod
          │           ├── Pod
          │           └── Pod
          │
          ├── Service
          │
          ├── PDB
          │
          ├── HPA
          │
          └── Ingress
                 │
                 ▼
          AWS Load Balancer
                 │
                 ▼
              Internet

The application image will already be stored in ECR.

Part 1 — Repository structure

Have students create:

jumptotech-production/
│
├── app/
│   ├── index.html
│   └── Dockerfile
│
├── kubernetes/
│   ├── namespace.yaml
│   ├── configmap.yaml
│   ├── secret.yaml
│   ├── serviceaccount.yaml
│   ├── deployment.yaml
│   ├── service.yaml
│   ├── pdb.yaml
│   ├── hpa.yaml
│   └── ingress.yaml
│
├── helm/
│   └── jumptotech/
│       ├── Chart.yaml
│       ├── values.yaml
│       └── templates/
│           ├── _helpers.tpl
│           ├── configmap.yaml
│           ├── serviceaccount.yaml
│           ├── deployment.yaml
│           ├── service.yaml
│           ├── pdb.yaml
│           ├── hpa.yaml
│           └── ingress.yaml
│
└── argocd/
    └── application.yaml

This lets you teach the same application three times:

Raw YAML → Helm → Argo CD

That repetition is valuable because students see exactly what each new tool solves.

PART 2 — Raw Kubernetes

1. Namespace

kubernetes/namespace.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: jumptotech-prod
  labels:
    environment: production
    managed-by: jumptotech

Apply:

kubectl apply -f kubernetes/namespace.yaml

Check:

kubectl get ns

Explain:

Namespace provides a logical boundary for namespaced Kubernetes resources.

Architecture:

EKS Cluster
│
├── default
├── kube-system
└── jumptotech-prod
      └── our application

2. ConfigMap

kubernetes/configmap.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: jumptotech-config
  namespace: jumptotech-prod
data:
  APP_NAME: "JumpToTech"
  APP_ENV: "production"
  LOG_LEVEL: "info"

Explain:

ConfigMap
    ↓
non-sensitive configuration

APP_ENV
LOG_LEVEL
API_URL
application settings

Apply:

kubectl apply -f kubernetes/configmap.yaml

Check:

kubectl get configmap -n jumptotech-prod

kubectl describe configmap jumptotech-config \
  -n jumptotech-prod

3. Secret

For a classroom demonstration:

kubernetes/secret.yaml

apiVersion: v1
kind: Secret
metadata:
  name: jumptotech-secret
  namespace: jumptotech-prod
type: Opaque
stringData:
  DB_USERNAME: "admin"
  DB_PASSWORD: "student-demo-password"

Apply:

kubectl apply -f kubernetes/secret.yaml

Explain the difference:

ConfigMap
    ↓
non-sensitive data

Secret
    ↓
sensitive data

But tell students:

Do not commit real production passwords to Git.

Even:

data:
  password: cGFzc3dvcmQ=

doesn't make the password secure merely because it is Base64.

For a real production GitOps architecture you would normally integrate a secrets-management solution rather than committing plaintext credentials.

4. ServiceAccount

kubernetes/serviceaccount.yaml

apiVersion: v1
kind: ServiceAccount
metadata:
  name: jumptotech-sa
  namespace: jumptotech-prod

Explain:

Person
   ↓
User identity

Workload
   ↓
ServiceAccount

ServiceAccount answers:

"Who is this workload?"

It does not automatically mean:

"This workload can do everything."

Authorization is separate, such as RBAC.

5. Deployment

This is the most important file.

kubernetes/deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: jumptotech-web
  namespace: jumptotech-prod
  labels:
    app: jumptotech-web

spec:
  replicas: 3

  selector:
    matchLabels:
      app: jumptotech-web

  template:
    metadata:
      labels:
        app: jumptotech-web

    spec:
      serviceAccountName: jumptotech-sa

      containers:
        - name: web
          image: YOUR_ACCOUNT_ID.dkr.ecr.us-east-1.amazonaws.com/jumptotech-web:v1

          ports:
            - name: http
              containerPort: 80
              protocol: TCP

          envFrom:
            - configMapRef:
                name: jumptotech-config

          env:
            - name: DB_USERNAME
              valueFrom:
                secretKeyRef:
                  name: jumptotech-secret
                  key: DB_USERNAME

            - name: DB_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: jumptotech-secret
                  key: DB_PASSWORD

          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"

            limits:
              cpu: "500m"
              memory: "256Mi"

          readinessProbe:
            httpGet:
              path: /
              port: http
            initialDelaySeconds: 5
            periodSeconds: 5
            timeoutSeconds: 2
            failureThreshold: 3

          livenessProbe:
            httpGet:
              path: /
              port: http
            initialDelaySeconds: 15
            periodSeconds: 10
            timeoutSeconds: 2
            failureThreshold: 3

Spend significant class time on this file.

6. Understand Deployment

Deployment
replicas: 3
     │
     ▼
ReplicaSet
     │
 ┌───┼────┐
 ▼   ▼    ▼
Pod Pod  Pod

The Deployment doesn't directly "run three containers."

It declares the desired state.

The Deployment controller manages ReplicaSets, and the ReplicaSet maintains the desired number of Pods.

7. Requests and Limits

Inside the Deployment:

resources:
  requests:
    cpu: "100m"
    memory: "128Mi"

  limits:
    cpu: "500m"
    memory: "256Mi"

Teach:

REQUEST
   ↓
Scheduler uses it when deciding
whether a Node has capacity

LIMIT
   ↓
maximum resource constraint
for the container

CPU:

1000m = 1 CPU
500m  = 0.5 CPU
100m  = 0.1 CPU

Then connect it to scheduling:

New Pod
request:
CPU 100m
RAM 128Mi
      │
      ▼
Scheduler
      │
      ├── Node A → enough capacity
      ├── Node B → not enough
      └── Node C → enough
                  │
                  ▼
               Node C
                  │
                  ▼
                kubelet
                  │
                  ▼
              Container

8. Readiness Probe

readinessProbe:
  httpGet:
    path: /
    port: http

Question:

Is this Pod ready to receive traffic?

Pod Running
    │
    ▼
Readiness
    │
 ┌──┴───┐
YES     NO
 │       │
 ▼       ▼
Ready   Not Ready
for
traffic

Important:

Readiness failure doesn't normally restart the container.

9. Liveness Probe

livenessProbe:
  httpGet:
    path: /
    port: http

Question:

Is this container/application still healthy enough to keep running?

Repeated liveness failures can cause kubelet to restart the container.

Liveness fails
      ↓
failure threshold reached
      ↓
kubelet
      ↓
restart container

10. Apply Deployment

kubectl apply -f kubernetes/serviceaccount.yaml
kubectl apply -f kubernetes/deployment.yaml

Check:

kubectl get deployment -n jumptotech-prod
kubectl get rs -n jumptotech-prod
kubectl get pods -n jumptotech-prod
kubectl get pods -n jumptotech-prod -o wide

Then:

kubectl describe pod POD_NAME -n jumptotech-prod

Students should locate:

Image
Ports
Environment
Requests
Limits
Readiness
Liveness
ServiceAccount
Events

11. Service

kubernetes/service.yaml

apiVersion: v1
kind: Service
metadata:
  name: jumptotech-service
  namespace: jumptotech-prod

spec:
  type: ClusterIP

  selector:
    app: jumptotech-web

  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: http

Explain:

Service
selector:
app=jumptotech-web
       │
       ▼
Find matching Pod labels
       │
 ┌─────┼─────┐
 ▼     ▼     ▼
Pod   Pod   Pod

Apply:

kubectl apply -f kubernetes/service.yaml

Check:

kubectl get svc -n jumptotech-prod

Then:

kubectl get endpointslice \
  -n jumptotech-prod \
  -l kubernetes.io/service-name=jumptotech-service

12. Test before ALB

kubectl port-forward \
  service/jumptotech-service \
  8080:80 \
  -n jumptotech-prod

Browser:

http://localhost:8080

This proves:

Deployment
    ↓
Pods
    ↓
Service
    ↓
Application

works before adding another layer.

13. PDB

kubernetes/pdb.yaml

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: jumptotech-pdb
  namespace: jumptotech-prod

spec:
  minAvailable: 2

  selector:
    matchLabels:
      app: jumptotech-web

Architecture:

3 replicas

Pod A
Pod B
Pod C

PDB:
minAvailable: 2

This helps preserve availability during supported voluntary disruptions, such as certain maintenance/eviction operations.

It does not prevent every crash or infrastructure failure.

Apply:

kubectl apply -f kubernetes/pdb.yaml

kubectl get pdb -n jumptotech-prod

14. HPA

Now introduce automatic scaling.

kubernetes/hpa.yaml

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: jumptotech-hpa
  namespace: jumptotech-prod

spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: jumptotech-web

  minReplicas: 3
  maxReplicas: 10

  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

Explain:

Low traffic

Pod Pod Pod


CPU increases
     ↓
HPA observes metric
     ↓
desired replicas increases
     ↓

Pod Pod Pod Pod Pod ...


Traffic decreases
     ↓
scale down

For resource-based CPU HPA to work as expected, the cluster needs resource metrics available, commonly through Metrics Server, and CPU requests matter for utilization calculations.

Check first:

kubectl top pods -n jumptotech-prod

Then:

kubectl apply -f kubernetes/hpa.yaml
kubectl get hpa -n jumptotech-prod

15. Ingress

kubernetes/ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: jumptotech-ingress
  namespace: jumptotech-prod

  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip

spec:
  ingressClassName: alb

  rules:
    - http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: jumptotech-service
                port:
                  number: 80

Before applying:

kubectl get deployment \
  aws-load-balancer-controller \
  -n kube-system

Then:

kubectl apply -f kubernetes/ingress.yaml

Check:

kubectl get ingress -n jumptotech-prod

kubectl describe ingress \
  jumptotech-ingress \
  -n jumptotech-prod

Teach the two flows separately.

Configuration:

Ingress YAML
     ↓
Kubernetes API
     ↓
AWS Load Balancer Controller
     ↓
AWS APIs
     ↓
ALB / target groups / rules

Runtime traffic is different:

Customer
   ↓
ALB
   ↓
configured backend targets
   ↓
Pods/application

The controller is not sitting in the middle of every customer HTTP request.

PART 3 — Why do we need Helm?

Now ask students:

What happens if we need DEV, TEST and PROD?

Without Helm we may start duplicating files:

deployment-dev.yaml
deployment-test.yaml
deployment-prod.yaml

service-dev.yaml
service-test.yaml
service-prod.yaml

ingress-dev.yaml
ingress-test.yaml
ingress-prod.yaml

This becomes difficult to maintain.

Helm gives us:

Templates
   +
Values
   =
Rendered Kubernetes YAML

A simple analogy:

Kubernetes YAML = completed form

Helm template = reusable form

values.yaml = answers inserted
into the form

PART 4 — Create Helm Chart

Run:

helm create jumptotech

For the class, simplify the generated chart and use:

helm/jumptotech/
├── Chart.yaml
├── values.yaml
└── templates/
    ├── _helpers.tpl
    ├── configmap.yaml
    ├── serviceaccount.yaml
    ├── deployment.yaml
    ├── service.yaml
    ├── pdb.yaml
    ├── hpa.yaml
    └── ingress.yaml

16. Chart.yaml

apiVersion: v2
name: jumptotech
description: JumpToTech production Kubernetes application
type: application
version: 0.1.0
appVersion: "1.0.0"

Explain:

Chart.yaml
    ↓
information about Helm chart

17. values.yaml

This becomes the central configuration.

replicaCount: 3

image:
  repository: YOUR_ACCOUNT_ID.dkr.ecr.us-east-1.amazonaws.com/jumptotech-web
  tag: "v1"
  pullPolicy: IfNotPresent

serviceAccount:
  create: true
  name: jumptotech-sa

service:
  type: ClusterIP
  port: 80

resources:
  requests:
    cpu: 100m
    memory: 128Mi
  limits:
    cpu: 500m
    memory: 256Mi

config:
  appName: JumpToTech
  environment: production
  logLevel: info

probes:
  readiness:
    path: /
    initialDelaySeconds: 5

  liveness:
    path: /
    initialDelaySeconds: 15

pdb:
  enabled: true
  minAvailable: 2

autoscaling:
  enabled: true
  minReplicas: 3
  maxReplicas: 10
  targetCPUUtilizationPercentage: 70

ingress:
  enabled: true
  className: alb
  scheme: internet-facing
  targetType: ip

Now students should see the point.

Instead of editing templates repeatedly:

values.yaml
     ↓
Helm templates
     ↓
Kubernetes manifests

18. Helm Deployment template

templates/deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}
  labels:
    app: {{ .Release.Name }}

spec:
  replicas: {{ .Values.replicaCount }}

  selector:
    matchLabels:
      app: {{ .Release.Name }}

  template:
    metadata:
      labels:
        app: {{ .Release.Name }}

    spec:
      serviceAccountName: {{ .Values.serviceAccount.name }}

      containers:
        - name: web

          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"

          imagePullPolicy: {{ .Values.image.pullPolicy }}

          ports:
            - name: http
              containerPort: 80

          envFrom:
            - configMapRef:
                name: {{ .Release.Name }}-config

          resources:
{{ toYaml .Values.resources | indent 12 }}

          readinessProbe:
            httpGet:
              path: {{ .Values.probes.readiness.path }}
              port: http
            initialDelaySeconds: {{ .Values.probes.readiness.initialDelaySeconds }}

          livenessProbe:
            httpGet:
              path: {{ .Values.probes.liveness.path }}
              port: http
            initialDelaySeconds: {{ .Values.probes.liveness.initialDelaySeconds }}

Now explain:

{{ .Values.replicaCount }}

means:

Go to values.yaml and get replicaCount.

And:

{{ .Values.image.repository }}

gets:

image:
  repository: ...

19. Helm Service

templates/service.yaml

apiVersion: v1
kind: Service
metadata:
  name: {{ .Release.Name }}-service

spec:
  type: {{ .Values.service.type }}

  selector:
    app: {{ .Release.Name }}

  ports:
    - name: http
      port: {{ .Values.service.port }}
      targetPort: http

20. Helm ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Release.Name }}-config

data:
  APP_NAME: {{ .Values.config.appName | quote }}
  APP_ENV: {{ .Values.config.environment | quote }}
  LOG_LEVEL: {{ .Values.config.logLevel | quote }}

21. Helm ServiceAccount

{{- if .Values.serviceAccount.create }}
apiVersion: v1
kind: ServiceAccount
metadata:
  name: {{ .Values.serviceAccount.name }}
{{- end }}

Now introduce conditional rendering:

if true
   ↓
create object

if false
   ↓
don't render object

22. Helm PDB

{{- if .Values.pdb.enabled }}
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: {{ .Release.Name }}-pdb

spec:
  minAvailable: {{ .Values.pdb.minAvailable }}

  selector:
    matchLabels:
      app: {{ .Release.Name }}
{{- end }}

23. Helm HPA

{{- if .Values.autoscaling.enabled }}
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: {{ .Release.Name }}-hpa

spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: {{ .Release.Name }}

  minReplicas: {{ .Values.autoscaling.minReplicas }}
  maxReplicas: {{ .Values.autoscaling.maxReplicas }}

  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: {{ .Values.autoscaling.targetCPUUtilizationPercentage }}
{{- end }}

24. Helm Ingress

{{- if .Values.ingress.enabled }}
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: {{ .Release.Name }}-ingress

  annotations:
    alb.ingress.kubernetes.io/scheme: {{ .Values.ingress.scheme }}
    alb.ingress.kubernetes.io/target-type: {{ .Values.ingress.targetType }}

spec:
  ingressClassName: {{ .Values.ingress.className }}

  rules:
    - http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: {{ .Release.Name }}-service
                port:
                  number: {{ .Values.service.port }}
{{- end }}

PART 5 — Never install a Helm chart before checking it

This is an important production habit.

First:

helm lint helm/jumptotech

Then:

helm template jumptotech \
  helm/jumptotech

Explain what happened:

values.yaml
      +
templates/
      ↓
HELM RENDERING
      ↓
ordinary Kubernetes YAML

Helm doesn't replace Kubernetes.

Helm generates/manages Kubernetes manifests/releases. Kubernetes still runs the workloads.

25. Install with Helm manually

Before introducing Argo CD:

helm upgrade --install jumptotech \
  helm/jumptotech \
  --namespace jumptotech-prod \
  --create-namespace

Check:

helm list -n jumptotech-prod

kubectl get all -n jumptotech-prod

Then:

helm status jumptotech \
  -n jumptotech-prod

Now students understand Helm independently.

PART 6 — DEV vs PROD

Create:

values-dev.yaml
values-prod.yaml

Example DEV:

replicaCount: 1

config:
  environment: development

resources:
  requests:
    cpu: 50m
    memory: 64Mi
  limits:
    cpu: 200m
    memory: 128Mi

autoscaling:
  enabled: false

PROD:

replicaCount: 3

config:
  environment: production

resources:
  requests:
    cpu: 100m
    memory: 128Mi
  limits:
    cpu: 500m
    memory: 256Mi

autoscaling:
  enabled: true
  minReplicas: 3
  maxReplicas: 10
  targetCPUUtilizationPercentage: 70

Now:

Same Helm templates

      ┌── values-dev.yaml
      │
Chart ┤
      │
      └── values-prod.yaml

That's one of the major benefits students need to understand.

PART 7 — Why Argo CD?

Now ask:

We have Helm. Why do we need Argo CD?

Without Argo CD:

Developer
   ↓
git push
   ↓
Someone runs:
helm upgrade ...
   ↓
Cluster

With GitOps:

Developer
   ↓
git push
   ↓
GitHub
   ↓
Argo CD detects desired state
   ↓
Helm chart rendered
   ↓
Kubernetes

Git becomes the source of desired deployment configuration.

PART 8 — Argo CD Application

Assuming Argo CD is already installed, create:

argocd/application.yaml

apiVersion: argoproj.io/v1alpha1
kind: Application

metadata:
  name: jumptotech-production
  namespace: argocd

spec:
  project: default

  source:
    repoURL: https://github.com/jumptotechschooldevops/YOUR_REPOSITORY.git
    targetRevision: main
    path: helm/jumptotech

    helm:
      valueFiles:
        - values-prod.yaml

  destination:
    server: https://kubernetes.default.svc
    namespace: jumptotech-prod

  syncPolicy:
    automated:
      prune: true
      selfHeal: true

    syncOptions:
      - CreateNamespace=true

Explain each important field.

repoURL
   ↓
Where is Git repository?

targetRevision
   ↓
Which branch/tag/commit?

path
   ↓
Where is Helm chart?

destination
   ↓
Which cluster?

namespace
   ↓
Where should resources go?

26. `selfHeal`

This is a fantastic live demonstration.

Git says:

replicas: 3

Someone manually runs:

kubectl scale deployment jumptotech \
  --replicas=1 \
  -n jumptotech-prod

Now:

Git desired state
3 replicas

Cluster actual state
1 replica

Argo CD detects drift.

With automated self-healing configured, it can reconcile the cluster back toward the Git-defined state.

Teach:

GIT = Desired State

CLUSTER = Actual State

Argo CD
    ↓
compares
    ↓
reconciles differences

27. `prune`

Suppose Git previously contained:

service.yaml
deployment.yaml
old-configmap.yaml

Then you remove the managed old ConfigMap from Git.

With:

prune: true

Argo CD can remove the resource that is no longer part of the application's desired state.

Be careful with this in real production environments: automated pruning is powerful.

PART 9 — Complete CI/CD + GitOps architecture

Now students should be able to draw:

                 DEVELOPER
                     │
                  git push
                     │
             ┌───────▼────────┐
             │     GitHub     │
             └───────┬────────┘
                     │
          ┌──────────┴──────────┐
          │                     │
          ▼                     ▼
     GitHub Actions          Argo CD
          │                     │
      CI Pipeline            GitOps CD
          │                     │
     Test / Scan                │
          │                     │
     Docker Build               │
          │                     │
          ▼                     │
         ECR                    │
          │                     │
       Image:v2                 │
                                │
                        Helm templates
                              +
                           values
                                │
                                ▼
                           EKS Cluster
                                │
                         jumptotech-prod
                                │
                         ┌──────┴──────┐
                         │             │
                    Deployment      Service
                         │             │
                    ReplicaSet         │
                         │             │
                   Pods/Containers ◄───┘
                         ▲
                         │
                       ALB
                         ▲
                         │
                      Customer

There's an important distinction here:

CI builds the artifact.

Code
 ↓
Test
 ↓
Docker build
 ↓
Image
 ↓
ECR

GitOps CD changes desired deployment state and reconciles it.

Git desired state
 ↓
Argo CD
 ↓
Helm
 ↓
Kubernetes

PART 10 — Production files students should recognize

Object/File	Main purpose
`Namespace`	Logical resource boundary
`ConfigMap`	Non-sensitive configuration
`Secret`	Sensitive configuration object
`ServiceAccount`	Workload identity
`Role`	Namespaced RBAC permissions
`RoleBinding`	Assign Role permissions
`Deployment`	Desired stateless application deployment
`ReplicaSet`	Maintains Pod replica count
`Pod`	Workload execution unit
`Service`	Stable service discovery/access
`EndpointSlice`	Service backend addresses
`Ingress`	HTTP/HTTPS routing configuration
`NetworkPolicy`	Pod network traffic policy
`PDB`	Availability during voluntary disruptions
`HPA`	Horizontal workload scaling
`PVC`	Persistent storage request
`StatefulSet`	Stateful workloads
`Job`	Run-to-completion workload
`CronJob`	Scheduled Job
`Chart.yaml`	Helm chart metadata
`values.yaml`	Helm configuration
`templates/*`	Helm Kubernetes templates
Argo `Application`	Defines a GitOps-managed application

HOMEWORK — SonarQube + Trivy + CI Jobs

Aisalkyn Aidarova — Wed, 16 Sep 2026 19:26:23 +0000

Project: Restaurant Company
Role: DevOps Engineer

Goal

Today you learned:

Lint
Test concept
SonarQube
Trivy
Quality Gate
Troubleshooting
Parallel Jobs
Dependent Jobs

Your homework is to prove that you understand these concepts and can work with the tools.

Part 1 — Verify SonarQube

Start by checking Docker:

docker ps

If SonarQube is stopped:

docker ps -a
docker start sonarqube

Check:

docker ps

Then:

curl http://localhost:9000

You should confirm that SonarQube responds.

Question: What does successful curl localhost:9000 prove?

Part 2 — Check the SonarQube Project

Open:

http://YOUR-EC2-PUBLIC-IP:9000

Log into SonarQube and find the Restaurant Company project you created in class.

Students should take a screenshot showing the project.

Then answer:

1. What is SonarQube?
2. Is SonarQube the same thing as CI?
3. What is a Quality Gate?
4. Does creating a SonarQube project automatically scan source code?
5. What is SonarScanner used for?

Part 3 — Practice Troubleshooting

Run:

free -h

Then:

docker ps

Then:

docker logs --tail 30 sonarqube

Students must explain:

What is RAM?

What is OOM?

What does exit code 137 usually indicate in the incident
we investigated?

Why did Linux kill the SonarQube Java process?

Why did increasing EC2 memory solve the problem?

Then write this troubleshooting sequence in their own words:

PROBLEM
   ↓
CHECK LOGS
   ↓
FIND EVIDENCE
   ↓
FIND ROOT CAUSE
   ↓
FIX
   ↓
VERIFY

And remember:

CHECK → FIND → FIX → VERIFY

Part 4 — Trivy

Students should explain:

1. What is Trivy?
2. What is a vulnerability?
3. What is CVE?
4. What does severity mean?
5. What are LOW, MEDIUM, HIGH and CRITICAL?
6. What is the difference between the primary roles
   of SonarQube and Trivy?

Don't require them to claim that SonarQube is “only quality” or Trivy is “only security.” Their capabilities can overlap.

A good simple answer is:

SonarQube
→ primarily code quality/static analysis in our pipeline

Trivy
→ security scanning for known vulnerabilities
  and other supported security issues

Part 5 — Design the CI Pipeline

Have students draw this architecture themselves:

                    ┌── LINT ─────────┐
                    │                  │
PULL REQUEST ───────┼── SONARQUBE ─────┼──→ ALL PASS
                    │                  │
                    └── TRIVY ─────────┘

Then answer:

Why can these jobs run in parallel?

Expected concept:

They are independent checks and don't necessarily need the output of each other.

Part 6 — Add a Dependent Job

Now add:

                    ┌── LINT ─────────┐
                    │                  │
PULL REQUEST ───────┼── SONARQUBE ─────┼──→ ALL PASS
                    │                  │
                    └── TRIVY ─────────┘
                                             ↓
                                      ARTIFACT BUILD

Students should write:

needs:
  - lint
  - sonarqube
  - trivy

Then explain:

What does needs mean in GitHub Actions?

Expected:

needs creates a dependency between jobs. The dependent job waits for the required jobs to complete successfully.

Part 7 — Interview Practice

Every student should be able to say this without reading:

In our CI pipeline, we use SonarQube for code-quality analysis and Trivy for security scanning. Independent checks can run in parallel to reduce pipeline time. A later build job can depend on those required checks using needs. We also troubleshot a real SonarQube failure where Linux killed the Java process because the EC2 instance ran out of memory.

🏠 Homework — Restaurant Company Real CI

Aisalkyn Aidarova — Tue, 15 Sep 2026 16:56:22 +0000

Goal

You are the DevOps Engineer. A developer gave you the Restaurant Company source code.

Your job is to understand the application first, run its checks manually, and then automate them with GitHub Actions.

Part 1 — Get the latest code

Use your Restaurant Company repository.

cd restaurant-company

git switch main
git pull origin main

Check:

git status
git log --oneline -5

Part 2 — Investigate the application

Before running anything:

ls
cat package.json

Students must find and write down:

1. What is package.json?
2. What scripts are defined?
3. What command is used for lint?
4. What command is used for build?
5. What dependencies do you see?

Then:

ls package-lock.json

Question:

What is the difference between package.json and package-lock.json?

They should be able to explain it in their own words.

Part 3 — Run manually

Run:

npm ci

Then:

npm run lint

Then:

npm run build

Finally:

ls
ls dist

Students should understand this flow:

SOURCE CODE
     ↓
npm ci
     ↓
Dependencies
     ↓
npm run lint
     ↓
Code Check ✓
     ↓
npm run build
     ↓
dist/

Questions

They must answer:

What does npm ci do?

Where does npm know which dependencies to install?

Why is package-lock.json important?

What does npm run lint do?

Where does npm find the lint command?

What does npm run build do?

What is dist/?

Part 4 — Create your own CI branch

Do not work directly on main.

git switch -c homework-ci

Create:

mkdir -p .github/workflows
nano .github/workflows/homework-ci.yml

Use:

name: Homework Restaurant CI

on:
  pull_request:

jobs:
  ci:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout Code
        uses: actions/checkout@v4

      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: 22

      - name: Install Dependencies
        run: npm ci

      - name: Lint
        run: npm run lint

      - name: Build
        run: npm run build

Part 5 — Before pushing, explain the YAML

They must be able to explain:

on:
pull_request:
jobs:
runs-on:
steps:
uses:
run:
actions/checkout
actions/setup-node
npm ci
npm run lint
npm run build

Do not accept “I copied the YAML.”

They need to explain what happens:

Pull Request
     ↓
Trigger
     ↓
Workflow
     ↓
Job
     ↓
Ubuntu Runner
     ↓
Checkout
     ↓
Setup Node
     ↓
npm ci
     ↓
Lint
     ↓
Build

Part 6 — Push

git status
git diff

git add .
git commit -m "Add homework CI pipeline"

git push -u origin homework-ci

Important question

Ask them:

We used only pull_request:. Should CI run just because you pushed the branch?

They should understand the difference from:

on:
  push:
  pull_request:

which can result in separate runs from the two different events.

Part 7 — Create Pull Request

On GitHub:

homework-ci
     ↓
Pull Request
     ↓
main

Now watch GitHub Actions.

Expected:

✓ Checkout Code
✓ Setup Node
✓ Install Dependencies
✓ Lint
✓ Build

DO NOT MERGE immediately.

Open the workflow and look at every step.

Part 8 — Explain the result

Students should prepare a 2-minute explanation:

CI is an approach. GitHub Actions is a tool.

Developer gave me the Restaurant Company source code.

I first inspected package.json and package-lock.json.

I manually ran npm ci, npm run lint, and npm run build.

Then I automated those commands using GitHub Actions.

My workflow is triggered by a Pull Request.

GitHub creates a runner, checks out the source code, sets up Node, installs dependencies, runs lint, and builds the application.

I would have every student say this aloud rather than only submit screenshots.

📤 What to submit

Screenshot of package.json scripts
Screenshot of successful npm ci
Screenshot of successful npm run lint
Screenshot of successful npm run build
Screenshot showing dist/
Screenshot of their homework-ci.yml
Screenshot of Pull Request
Screenshot of GREEN GitHub Actions
Their answers to the seven questions above

⭐ Bonus — only for stronger students

Have them explain, without changing the workflow:

Why do we need Setup Node in GitHub Actions
if Node/npm is already installed on our EC2?

Correct concept:

EC2 ≠ GitHub Actions Runner

The GitHub runner is a separate environment. Installing Node on EC2 does not install it on the GitHub Actions runner.

JumpToTech Kubernetes Core YAML Lab

Aisalkyn Aidarova — Tue, 15 Sep 2026 02:51:15 +0000

Namespace: jumptotech
│
├── ConfigMap ───────────────┐
│                            │
├── Secret ──────────────────┤
│                            ↓
│                       Deployment
│                            ↓
│                       ReplicaSet
│                            ↓
│               ┌────────────┼────────────┐
│               ↓            ↓            ↓
│             Pod 1        Pod 2        Pod 3
│               │            │            │
│               └────────────┼────────────┘
│                            ↑
│                         Service
│                            ↑
│                         Ingress
│
├── ServiceAccount ─────→ Pods
│
└── PDB ────────────────→ protects availability

1. Создайте папку

mkdir k8s-core-lab
cd k8s-core-lab

В конце у вас будет:

k8s-core-lab/
├── namespace.yaml
├── configmap.yaml
├── secret.yaml
├── serviceaccount.yaml
├── deployment.yaml
├── service.yaml
├── pdb.yaml
└── ingress.yaml

2. Namespace

Создайте namespace.yaml:

apiVersion: v1
kind: Namespace
metadata:
  name: jumptotech

Применяем:

kubectl apply -f namespace.yaml
kubectl get namespaces

Объяснение:

Namespace — логическое разделение ресурсов внутри одного Kubernetes cluster.

Теперь почти всё приложение будем создавать внутри:

jumptotech

3. ConfigMap

configmap.yaml:

apiVersion: v1
kind: ConfigMap
metadata:
  name: web-config
  namespace: jumptotech
data:
  APP_NAME: "JumpToTech"
  APP_ENV: "production"
  APP_MESSAGE: "Welcome to Kubernetes"

Применяем:

kubectl apply -f configmap.yaml
kubectl get configmap -n jumptotech
kubectl describe configmap web-config -n jumptotech

Объясните:

ConfigMap хранит несекретную конфигурацию отдельно от Docker image.

Например:

APP_ENV
APP_NAME
LOG_LEVEL
API_URL

Не надо rebuild image только потому, что:

APP_ENV=dev

нужно поменять на:

APP_ENV=production

4. Secret

secret.yaml:

apiVersion: v1
kind: Secret
metadata:
  name: web-secret
  namespace: jumptotech
type: Opaque
stringData:
  DB_USERNAME: "admin"
  DB_PASSWORD: "jumptotech123"

Для учебного lab это удобно, но объясните студентам:

В production реальные passwords нельзя коммитить в Git в таком YAML. Обычно используют внешний secret-management solution и соответствующую интеграцию.

Применяем:

kubectl apply -f secret.yaml
kubectl get secrets -n jumptotech
kubectl describe secret web-secret -n jumptotech

Обратите внимание: describe не должен просто печатать secret value.

5. ServiceAccount

Создаём serviceaccount.yaml:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: web-service-account
  namespace: jumptotech

Применяем:

kubectl apply -f serviceaccount.yaml
kubectl get serviceaccounts -n jumptotech

Объяснение:

ServiceAccount — identity для workload/Pod внутри Kubernetes.

Очень важно:

Human
  ↓
User identity

Pod
  ↓
ServiceAccount

Сам по себе ServiceAccount не означает, что Pod автоматически получил доступ ко всему. Permissions определяются отдельно, например RBAC; в AWS также могут использоваться workload identity mechanisms.

6. Deployment + Requests + Limits

Теперь основной файл — deployment.yaml.

Замените YOUR_ECR_IMAGE своим настоящим ECR URI.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-deployment
  namespace: jumptotech

spec:
  replicas: 3

  selector:
    matchLabels:
      app: web

  template:
    metadata:
      labels:
        app: web

    spec:
      serviceAccountName: web-service-account

      containers:
        - name: web-container
          image: YOUR_ECR_IMAGE
          ports:
            - containerPort: 80

          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "500m"
              memory: "256Mi"

          env:
            - name: APP_NAME
              valueFrom:
                configMapKeyRef:
                  name: web-config
                  key: APP_NAME

            - name: APP_ENV
              valueFrom:
                configMapKeyRef:
                  name: web-config
                  key: APP_ENV

            - name: DB_USERNAME
              valueFrom:
                secretKeyRef:
                  name: web-secret
                  key: DB_USERNAME

            - name: DB_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: web-secret
                  key: DB_PASSWORD

Здесь остановитесь надолго.

Студенты должны понимать:

Deployment
    ↓
replicas: 3
    ↓
ReplicaSet
    ↓
3 Pods

И:

resources:
  requests:
    cpu: "100m"
    memory: "128Mi"

означает:

Scheduler учитывает эти requests при выборе Node.

А:

limits:
  cpu: "500m"
  memory: "256Mi"

устанавливает верхние ограничения для контейнера.

Ключевая разница:

REQUEST
   ↓
Scheduler / placement

LIMIT
   ↓
Runtime resource ceiling

CPU:

1000m = 1 CPU
500m  = 0.5 CPU
100m  = 0.1 CPU

7. Apply Deployment

kubectl apply -f deployment.yaml

Проверяем:

kubectl get deployments -n jumptotech
kubectl get rs -n jumptotech
kubectl get pods -n jumptotech
kubectl get pods -n jumptotech -o wide

Должно быть:

Deployment
    ↓
ReplicaSet
    ↓
3 Pods

8. Проверяем Resources

Выберите Pod:

kubectl describe pod POD_NAME -n jumptotech

Найдите:

Limits:
  cpu:     500m
  memory:  256Mi

Requests:
  cpu:     100m
  memory:  128Mi

Спросите:

Что использует Scheduler при выборе Node?

Requests.

Что будет, если приложение пытается использовать CPU больше CPU limit?

CPU может throttled.

Что может произойти при превышении memory limit?

Контейнер может быть убит из-за OOM (OOMKilled).

9. Проверяем ConfigMap и Secret внутри Pod

Сначала ConfigMap:

kubectl exec -n jumptotech POD_NAME -- printenv APP_NAME

Должно показать:

JumpToTech

Потом:

kubectl exec -n jumptotech POD_NAME -- printenv APP_ENV

Получим:

production

Для учебной демонстрации можно проверить username:

kubectl exec -n jumptotech POD_NAME -- printenv DB_USERNAME

Главная идея:

ConfigMap ──────┐
                ↓
              Pod
                ↑
Secret ─────────┘

10. Проверяем ServiceAccount

kubectl get pod POD_NAME \
-n jumptotech \
-o jsonpath='{.spec.serviceAccountName}'

Получим:

web-service-account

Связь:

Deployment Pod Template
       ↓
serviceAccountName
       ↓
web-service-account
       ↓
Pod identity

11. Service

Создаём service.yaml:

apiVersion: v1
kind: Service
metadata:
  name: web-service
  namespace: jumptotech

spec:
  type: ClusterIP

  selector:
    app: web

  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

Применяем:

kubectl apply -f service.yaml
kubectl get svc -n jumptotech

Главная связь:

Service
selector: app=web
       ↓
     MATCH
       ↓
Pod labels
app=web

12. EndpointSlice

Сначала:

kubectl get pods -n jumptotech -o wide

Посмотрите Pod IP.

Потом:

kubectl get endpointslice \
-n jumptotech \
-l kubernetes.io/service-name=web-service

Для дополнительной учебной проверки можно также использовать старую команду:

kubectl get endpoints web-service -n jumptotech

но в вашем кластере вы уже видели предупреждение о deprecated Endpoints API, поэтому EndpointSlice — современный объект, который студентам лучше знать.

Логика:

Service selector
      ↓
Pod labels
      ↓
matching backend Pods
      ↓
EndpointSlice maintains backend addresses

13. Проверяем Service

Пока ALB не нужен.

kubectl port-forward \
service/web-service \
8080:80 \
-n jumptotech

Открываем:

http://localhost:8080

Если приложение открывается:

Deployment ✅
Pods       ✅
Service    ✅

14. PodDisruptionBudget — PDB

Теперь очень хороший production object.

Создаём pdb.yaml:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: web-pdb
  namespace: jumptotech

spec:
  minAvailable: 2

  selector:
    matchLabels:
      app: web

Применяем:

kubectl apply -f pdb.yaml
kubectl get pdb -n jumptotech

Объясните:

У нас:

replicas = 3

PDB:

minAvailable = 2

То есть при voluntary disruptions, например некоторых операциях drain/maintenance, Kubernetes должен учитывать требование:

3 Pods

Pod 1   Pod 2   Pod 3
  ✓       ✓       ✓

PDB:
минимум 2 должны оставаться available

Очень важное уточнение:

PDB не гарантирует, что Pod никогда не упадёт.

Если Node внезапно умер или приложение crash — PDB не является магической защитой от этого.

PDB в первую очередь ограничивает voluntary disruptions.

15. Readiness и Liveness Probes

Я бы обязательно добавила их в этот же Deployment lab.

В deployment.yaml под container добавьте:

livenessProbe:
  httpGet:
    path: /
    port: 80
  initialDelaySeconds: 10
  periodSeconds: 10

readinessProbe:
  httpGet:
    path: /
    port: 80
  initialDelaySeconds: 5
  periodSeconds: 5

Получится:

containers:
  - name: web-container
    image: YOUR_ECR_IMAGE

    ports:
      - containerPort: 80

    resources:
      requests:
        cpu: "100m"
        memory: "128Mi"
      limits:
        cpu: "500m"
        memory: "256Mi"

    livenessProbe:
      httpGet:
        path: /
        port: 80
      initialDelaySeconds: 10
      periodSeconds: 10

    readinessProbe:
      httpGet:
        path: /
        port: 80
      initialDelaySeconds: 5
      periodSeconds: 5

Объясните:

LIVENESS
"Приложение живое?"
      ↓
если постоянно fail
      ↓
kubelet может restart container


READINESS
"Приложение готово получать traffic?"
      ↓
NO
      ↓
Pod не должен использоваться
как ready backend

Применяем:

kubectl apply -f deployment.yaml
kubectl get pods -n jumptotech

16. Ingress

Если AWS Load Balancer Controller уже установлен, создаём ingress.yaml:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-ingress
  namespace: jumptotech

  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip

spec:
  ingressClassName: alb

  rules:
    - http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web-service
                port:
                  number: 80

Перед применением:

kubectl get deployment \
-n kube-system \
aws-load-balancer-controller

Если controller существует:

kubectl apply -f ingress.yaml

Проверяем:

kubectl get ingress -n jumptotech
kubectl describe ingress web-ingress -n jumptotech

17. Теперь вся архитектура

На доске нарисуйте:

                     INTERNET
                         ↓
                       ALB
                         ↓
                      Ingress
                         ↓
                    web-service
                  selector: app=web
                         ↓
             ┌───────────┼───────────┐
             ↓           ↓           ↓
           Pod 1       Pod 2       Pod 3
           app=web     app=web     app=web
             │           │           │
             └───────────┼───────────┘
                         ↑
                 Deployment
                         ↑
                    ReplicaSet


ConfigMap ───────────────→ Pods
Secret ─────────────────→ Pods
ServiceAccount ─────────→ Pods
Resources ──────────────→ Containers
PDB ────────────────────→ availability during
                           voluntary disruption

EVERYTHING:
Namespace = jumptotech

18. Очень важный troubleshooting lab

Теперь специально ломаем.

Поменяйте Service:

selector:
  app: WRONG

Примените:

kubectl apply -f service.yaml

Проверьте:

kubectl get svc -n jumptotech
kubectl get pods -n jumptotech
kubectl get endpointslice \
-n jumptotech \
-l kubernetes.io/service-name=web-service

Pods:

Running
Running
Running

Service:

Exists

Но backend endpoints не соответствуют нужным Pods.

Почему?

Service selector
app=WRONG
      X
Pod labels
app=web

Исправляем:

selector:
  app: web

И:

kubectl apply -f service.yaml

19. Resources troubleshooting

Теперь специально создайте слишком большой request:

resources:
  requests:
    cpu: "100"
    memory: "100Gi"

Это означает 100 CPU cores, а не 100m.

Примените:

kubectl apply -f deployment.yaml

Новые Pods могут зависнуть:

Pending

Тогда:

kubectl describe pod POD_NAME -n jumptotech

Ищите scheduling events вроде:

Insufficient cpu
Insufficient memory

Объяснение:

Pod
requests 100 CPU
       ↓
Scheduler
       ↓
Node 1 ❌
Node 2 ❌
       ↓
No suitable Node
       ↓
Pending

После демонстрации обязательно верните:

requests:
  cpu: "100m"
  memory: "128Mi"

20. Проверяем self-healing

kubectl get pods -n jumptotech

Удалите один Pod:

kubectl delete pod POD_NAME -n jumptotech

Смотрите:

kubectl get pods -n jumptotech -w

Объясняем:

Deployment desired replicas = 3
            ↓
ReplicaSet
            ↓
Pod deleted
            ↓
осталось 2
            ↓
replacement Pod
            ↓
снова 3

После появления replacement Pod сравните:

kubectl get pods -n jumptotech -o wide

с:

kubectl get endpointslice \
-n jumptotech \
-l kubernetes.io/service-name=web-service

Новый Pod может иметь новый IP, но поскольку:

label = app=web

Service продолжает выбирать его.

Что студент обязан знать после этого Lab

Я бы дала им именно эти объекты как Kubernetes Core Pack:

Namespace
   ↓
где логически находятся ресурсы

ConfigMap
   ↓
non-sensitive configuration

Secret
   ↓
sensitive configuration

ServiceAccount
   ↓
workload identity

Deployment
   ↓
desired application state

ReplicaSet
   ↓
maintains replica count

Pod
   ↓
smallest deployable workload unit

Container
   ↓
running application

Requests
   ↓
scheduler capacity decision

Limits
   ↓
resource ceiling

Liveness Probe
   ↓
"жив ли container/application?"

Readiness Probe
   ↓
"готов ли Pod получать traffic?"

Service
   ↓
stable service abstraction + selector

EndpointSlice
   ↓
backend addresses for Service

PDB
   ↓
protects availability during
voluntary disruptions

Ingress
   ↓
HTTP/HTTPS routing configuration

Ingress Controller
   ↓
implements/reconciles that configuration

И главное: студенты должны не просто запомнить YAML, а уметь рассказать цепочку:

Image in ECR
      ↓
Deployment
      ↓
ReplicaSet
      ↓
Pod
      ↓
Container

Scheduler → chooses Node using requests
Kubelet   → manages assigned Pod/containers

ConfigMap + Secret → configuration
ServiceAccount     → workload identity

Service selector
      ↓
Pod labels
      ↓
EndpointSlice
      ↓
backend Pods

Ingress
      ↓
AWS Load Balancer Controller
      ↓
ALB
      ↓
Service/backend

Homework Lab — Build Your Own CI Pipeline

Aisalkyn Aidarova — Mon, 14 Sep 2026 16:51:46 +0000

Goal

Each student creates their own website repository and builds a CI pipeline that performs:

Developer
   ↓
Feature Branch
   ↓
Push
   ↓
Pull Request
   ↓
CI
   ↓
Checkout
   ↓
Lint
   ↓
Test
   ↓
Security
   ↓
Build
   ↓
PASS ✓
   ↓
Merge

For this homework, the Lint, Test, Security, Build stages can be simple educational checks. They don't need SonarQube, Trivy, or Docker yet.

Part 1 — Create the project

mkdir ci-homework
cd ci-homework

git init
git branch -M main

touch index.html

Add:

<!DOCTYPE html>
<html>
<head>
    <title>JumpToTech CI Homework</title>
</head>

<body>
    <h1>My DevOps CI Project</h1>
    <p>Student: YOUR NAME</p>
    <p>I am learning Continuous Integration.</p>
</body>
</html>

Then:

git status
git add .
git commit -m "Create website"

Create an empty GitHub repository named:

ci-homework

Connect it:

git remote add origin YOUR-REPOSITORY-URL
git push -u origin main

Part 2 — Work like a real Developer

Do not build the CI directly on main.

git switch -c feature-ci

Create:

mkdir -p .github/workflows
nano .github/workflows/ci.yml

Part 3 — Create the CI Pipeline

Use:

name: Student CI Pipeline

on:
  push:
  pull_request:

jobs:
  ci:
    runs-on: ubuntu-latest

    steps:

      - name: Checkout Code
        uses: actions/checkout@v4

      - name: Lint
        run: |
          echo "Running Lint..."
          test -s index.html

      - name: Test
        run: |
          echo "Running Tests..."
          grep "DevOps" index.html

      - name: Security Check
        run: |
          echo "Running Security Check..."
          if grep -qi "password" index.html; then
            echo "Security check failed"
            exit 1
          fi
          echo "Security check passed"

      - name: Build
        run: |
          echo "Running Build..."
          mkdir -p build
          cp index.html build/index.html
          test -f build/index.html

      - name: CI Complete
        run: echo "CI PIPELINE PASSED"

Tell students:

These are simplified educational checks. The purpose is to understand pipeline structure and failure behavior before we introduce professional Lint, Test, Security and Build tools.

Part 4 — Understand every stage

They must be able to explain:

Checkout
↓
Get repository code onto Runner

Lint
↓
Basic file/code validation

Test
↓
Check expected content/behavior

Security
↓
Look for an intentionally unsafe pattern

Build
↓
Produce build output

They should not receive full credit simply because everything is green.

They need to explain what each stage does.

Part 5 — Commit and Push

git status
git diff

git add .
git commit -m "Add CI pipeline"

git push -u origin feature-ci

Then create:

feature-ci
     ↓
Pull Request
     ↓
main

Do not merge yet.

First check GitHub Actions.

Goal:

✓ Checkout
✓ Lint
✓ Test
✓ Security Check
✓ Build
✓ CI Complete

Part 6 — BREAK the Pipeline

This part is mandatory.

Change:

<p>I am learning Continuous Integration.</p>

and remove the word:

DevOps

from the entire index.html.

Commit:

git add .
git commit -m "Test CI failure"
git push

Because CI contains:

grep "DevOps" index.html

the Test stage should fail:

✓ Checkout
✓ Lint
✗ Test
- Security
- Build

Students must open the failed workflow and read the logs.

Part 7 — Troubleshoot

They should answer:

Which Job failed?

Which Step failed?

Which command failed?

Why did it fail?

What should I change?

Then put DevOps back into index.html.

git add .
git commit -m "Fix failed CI test"
git push

Now:

FAIL ✗
   ↓
Read Logs
   ↓
Find Root Cause
   ↓
Fix
   ↓
Commit
   ↓
Push
   ↓
PASS ✓

Part 8 — Security Failure Challenge

Now intentionally add:

<p>password=123456</p>

Commit and push:

git add .
git commit -m "Test security check"
git push

This time students should see:

✓ Checkout
✓ Lint
✓ Test
✗ Security Check

Ask them:

Why didn't Build run?

Because an earlier required step failed.

Then remove:

password=123456

Commit and push again.

Goal:

✓ Checkout
✓ Lint
✓ Test
✓ Security Check
✓ Build
✓ CI Complete

Part 9 — Merge only after Green

Now return to the Pull Request.

Only when CI is:

✓ GREEN

merge:

feature-ci
   ↓
PR
   ↓
CI ✓
   ↓
Review
   ↓
Merge
   ↓
main

Then locally:

git switch main
git pull origin main

Check:

git log --oneline

What Students Must Submit

Send me:

GitHub repository link
Screenshot of Pull Request
Screenshot of successful green CI
Screenshot of failed Test
Screenshot showing the Test error/log
Screenshot of failed Security Check
Screenshot of final successful pipeline
Screenshot showing the merged PR

And prepare to explain Monday:

What is CI?
What is a Pipeline?
What is a Trigger?
What is a Runner?
What does Checkout do?
What is a Job?
What is a Step?
What is Lint?
What is Test?
What is Security Check?
What is Build?
Why did your Test fail?
Why did your Security Check fail?
How did you troubleshoot them?
Why should CI pass before Merge?

The rule for the homework

Do not just send me a green check. Be ready to explain how you made it RED, how you found the problem, how you fixed it, and how you made it GREEN again.

DevOps Fundamentals

Aisalkyn Aidarova — Sun, 13 Sep 2026 21:11:22 +0000

What is DevOps?
What are the main responsibilities of a DevOps Engineer?
Explain the Software Development Life Cycle (SDLC).
What is Agile, and how does DevOps work with Agile?
What is CI/CD?
What is the difference between Continuous Integration, Continuous Delivery, and Continuous Deployment?
Walk me through a CI/CD pipeline you have built.
What happens after a developer pushes code to GitHub?
What tools do you use in your day-to-day work?
Describe your typical day as a DevOps Engineer.

Linux, Git & Scripting

What Linux commands do you use most often?
How do you check CPU, memory, and disk usage on Linux?
How do you troubleshoot a Linux server that is running slowly?
What is a process, and how do you find or kill one?
What is the difference between grep, awk, and sed?
What is the difference between git pull and git fetch?
What is the difference between git merge and git rebase?
How do you resolve a Git merge conflict?
What branching strategy does your team use?
What Bash or Python automation scripts have you written?

Docker & Kubernetes

What is Docker, and why do we use containers?
What is the difference between an image and a container?
Explain a Dockerfile you have written.
What is the difference between CMD and ENTRYPOINT?
How do you reduce the size of a Docker image?
Explain Kubernetes architecture.
What is the difference between a Pod, Deployment, ReplicaSet, and StatefulSet?
What is a Kubernetes Service? Explain ClusterIP, NodePort, and LoadBalancer.
What are ConfigMaps and Secrets?
What is the difference between readiness and liveness probes?
What is Ingress, and what does an Ingress Controller do?
How does HPA work?
A Pod is in CrashLoopBackOff. How would you troubleshoot it?
A Pod is in ImagePullBackOff. What would you check?
An application is running in Kubernetes but users cannot access it. How would you troubleshoot it?

AWS & Terraform

Explain VPC, public subnet, private subnet, route table, NAT Gateway, and Internet Gateway.
What AWS services have you worked with?
Explain IAM users, roles, and policies.
What is EKS, and how have you used it?
How would a Pod in EKS securely access S3?
What is Terraform?
What is Terraform state, and why is it important?
What is the difference between terraform plan and terraform apply?
What are Terraform modules?
How do multiple engineers safely work with the same Terraform state?

Senior / Real-World Questions

Tell me about the most serious production incident you handled.
A deployment causes 5xx errors immediately after release. What do you do?
How do you implement monitoring and alerting for a production Kubernetes application?
How have you improved security or reduced AWS costs?
Walk me through one project end-to-end—from developer commit to production.

A strong end-to-end question to practice repeatedly is:

Developer pushes code → GitHub → CI → testing → SonarQube → Trivy → Docker build → ECR → CD/GitOps → EKS → Deployment → Pod → Service → Ingress/ALB → DNS → user → monitoring/alerts.

If they can explain that architecture confidently and troubleshoot failures at every stage, they will be much better prepared for mid/senior DevOps interviews.

🏠 JumpToTech Homework — Docker ECR EKS Service Ingress ALB

Aisalkyn Aidarova — Sun, 13 Sep 2026 03:01:02 +0000

Scenario

You joined a company as a Junior DevOps Engineer.

A developer gives you a simple web application. Your task is to containerize it and deploy it to AWS EKS so customers can access it from the internet.

Final architecture:

Developer Code
      ↓
Dockerfile
      ↓
Docker Image
      ↓
Amazon ECR
      ↓
EKS Cluster
      ↓
Node Group
      ↓
Deployment
      ↓
ReplicaSet
      ↓
3 Pods
      ↓
Service
      ↓
Ingress
      ↓
AWS Load Balancer Controller
      ↓
ALB
      ↓
Internet / Browser

PART 1 — Create the project

Create:

mkdir jumptotech-homework
cd jumptotech-homework

Your final directory should contain:

jumptotech-homework/
│
├── index.html
├── Dockerfile
├── deployment.yaml
├── service.yaml
└── ingress.yaml

Create an index.html that displays:

JumpToTech DevOps
Docker → ECR → EKS
My Kubernetes Application is Running!

Design is up to you.

PART 2 — Docker

Create a Dockerfile.

Requirements:

Use nginx:alpine
Copy index.html into Nginx
Application listens on port 80

Build the image:

docker build -t jumptotech-homework:v1 .

Verify:

docker images

Run it locally:

docker run -d \
--name homework-test \
-p 8080:80 \
jumptotech-homework:v1

Check:

docker ps

Open:

http://localhost:8080

You must see your application.

PART 3 — Docker troubleshooting

Run:

docker logs homework-test

Enter the container:

docker exec -it homework-test sh

Inside:

pwd
ls
cat /usr/share/nginx/html/index.html

Exit:

exit

Then:

docker inspect homework-test

Find:

Image
Ports
Network
IP address

Stop and remove:

docker stop homework-test
docker rm homework-test

PART 4 — Create Amazon ECR repository

Create your own ECR repository.

Name:

jumptotech-homework

Verify it exists:

aws ecr describe-repositories \
--region us-east-1

Find your AWS account ID:

aws sts get-caller-identity

Your ECR URI will look like:

ACCOUNT_ID.dkr.ecr.us-east-1.amazonaws.com/jumptotech-homework

PART 5 — Login to ECR

Authenticate Docker:

aws ecr get-login-password --region us-east-1 | \
docker login \
--username AWS \
--password-stdin \
ACCOUNT_ID.dkr.ecr.us-east-1.amazonaws.com

You should get:

Login Succeeded

PART 6 — Build for EKS

⚠️ Students with Apple Silicon Macs must pay attention to architecture.

Check your EKS node architecture later with:

kubectl get nodes \
-o custom-columns="NODE:.metadata.name,ARCH:.status.nodeInfo.architecture"

For standard AMD64 worker nodes, build:

docker buildx build \
--platform linux/amd64 \
-t ACCOUNT_ID.dkr.ecr.us-east-1.amazonaws.com/jumptotech-homework:v1 \
--push .

Verify the image:

docker buildx imagetools inspect \
ACCOUNT_ID.dkr.ecr.us-east-1.amazonaws.com/jumptotech-homework:v1

Find:

linux/amd64

PART 7 — Connect to EKS

Find your cluster:

aws eks list-clusters --region us-east-1

Connect:

aws eks update-kubeconfig \
--region us-east-1 \
--name YOUR_CLUSTER_NAME

Test:

kubectl get nodes

All worker nodes should show:

Ready

PART 8 — Understand the Node Group

Run:

aws eks list-nodegroups \
--cluster-name YOUR_CLUSTER_NAME \
--region us-east-1

Then:

kubectl get nodes -o wide

Answer in your homework:

What is a Node Group?

What is a Node?

What runs on the Node?

Does a Deployment run directly on a Node?

PART 9 — Create Deployment

Create:

deployment.yaml

Requirements:

Deployment name:
homework-deployment

Replicas:
3

Pod label:
app=homework

Container name:
homework-container

Container port:
80

Image:
your ECR image :v1

Do not copy an old Deployment blindly. Write the YAML yourself.

Apply:

kubectl apply -f deployment.yaml

PART 10 — Verify Kubernetes

Run:

kubectl get deployments

Then:

kubectl get rs

Then:

kubectl get pods

Then:

kubectl get pods -o wide

All three Pods should eventually be:

1/1   Running

PART 11 — Prove ownership

Pick one Pod:

kubectl describe pod POD_NAME

Find:

Controlled By:

It should show a ReplicaSet.

Then:

kubectl describe rs REPLICASET_NAME

Find:

Controlled By:

You should be able to prove:

Deployment
     ↓
ReplicaSet
     ↓
Pod
     ↓
Container

Take a screenshot.

PART 12 — Troubleshoot your Pods

Check:

kubectl describe deployment homework-deployment

Then:

kubectl describe pod POD_NAME

Then:

kubectl logs POD_NAME

Students must know when each command is useful.

PART 13 — Create Service

Create:

service.yaml

Requirements:

Name:
homework-service

Type:
ClusterIP

Selector:
app=homework

Port:
80

TargetPort:
80

Apply:

kubectl apply -f service.yaml

Check:

kubectl get svc

Then:

kubectl describe svc homework-service

PART 14 — Prove Service found the Pods

Run:

kubectl get endpoints homework-service

You should have backend endpoints corresponding to your Pods.

Also:

kubectl get pods -o wide

Compare the Pod IP addresses.

Explain:

Service
selector app=homework
       ↓
+------+------+------+
|      |      |      |
↓      ↓      ↓
Pod 1  Pod 2  Pod 3

PART 15 — Intentionally break the Service 🔥

This is required.

Change:

selector:
  app: homework

to something incorrect:

selector:
  app: wrong

Apply:

kubectl apply -f service.yaml

Now:

kubectl get endpoints homework-service

Explain why the endpoints disappeared.

Then fix the selector and apply again.

This part must be demonstrated in your presentation.

PART 16 — Test without ALB

Before creating Ingress, prove that the application works.

Run:

kubectl port-forward \
service/homework-service \
8080:80

Keep the terminal open.

Open:

http://localhost:8080

You should see your application.

Traffic:

Browser
   ↓
localhost:8080
   ↓
kubectl port-forward
   ↓
Service
   ↓
Pod
   ↓
Container

If port 8080 is busy:

lsof -i :8080

Use another port, for example:

kubectl port-forward \
service/homework-service \
8081:80

PART 17 — Check AWS Load Balancer Controller

Now move toward production-style internet access.

Check:

kubectl get deployment \
-n kube-system \
aws-load-balancer-controller

Check:

kubectl get pods -n kube-system

And:

kubectl get ingressclass

You are looking for the ALB controller/IngressClass.

If the controller is not installed, document that finding rather than randomly installing commands from the internet. We will review controller installation and AWS permissions together if needed.

PART 18 — Create Ingress

If AWS Load Balancer Controller is correctly installed, create:

ingress.yaml

Requirements:

Ingress name:
homework-ingress

Ingress class:
alb

Scheme:
internet-facing

Target type:
ip

Path:
/

Backend:
homework-service

Backend port:
80

Apply:

kubectl apply -f ingress.yaml

Check:

kubectl get ingress

Then:

kubectl describe ingress homework-ingress

PART 19 — Find the ALB

Watch:

kubectl get ingress -w

When successfully provisioned, the ADDRESS field should eventually show an AWS load balancer hostname.

Then test that address in your browser.

Final runtime concept:

                 INTERNET
                     |
                     ↓
                   DNS
                     |
                     ↓
                 AWS ALB
                     |
             routing rules
                     |
                     ↓
             homework-service
                     |
          +----------+----------+
          ↓          ↓          ↓
        Pod 1      Pod 2      Pod 3
          ↓          ↓          ↓
      Container  Container  Container

PART 20 — Understand Ingress vs Controller

Every student must explain this.

Ingress

Rules / desired configuration

Example:

/      → frontend-service
/api   → api-service
/admin → admin-service

AWS Load Balancer Controller

Watches Kubernetes resources
        ↓
Calls AWS APIs
        ↓
Creates/configures AWS resources
        ↓
ALB
Listeners
Rules
Target Groups

ALB

Receives actual HTTP/HTTPS requests
        ↓
Uses configured routing
        ↓
Sends traffic to appropriate backend

Do not say:

User → Controller → Pod

The Controller is not forwarding every customer request.

PART 21 — Troubleshooting challenge

If the website doesn't work, students must troubleshoot in this order:

kubectl get ingress

kubectl describe ingress homework-ingress

kubectl get svc

kubectl describe svc homework-service

kubectl get endpoints homework-service

kubectl get pods -o wide

kubectl describe pod POD_NAME

kubectl logs POD_NAME

And explain the logic:

Browser
   ↓
ALB available?
   ↓
Ingress configured?
   ↓
Service exists?
   ↓
Endpoints exist?
   ↓
Pods Ready?
   ↓
Correct targetPort?
   ↓
Container running?
   ↓
Application logs

PART 22 — Scaling challenge

Start with:

kubectl get pods

Scale from 3 Pods to 5:

kubectl scale deployment \
homework-deployment \
--replicas=5

Watch:

kubectl get pods -w

Then:

kubectl get endpoints homework-service

Answer:

Did you manually tell the Service about the two new Pods?

No.

Why?

Because:

Service selector
app=homework
      ↓
automatically matches
      ↓
new Pods with app=homework

PART 23 — Self-healing challenge 🔥

Find a Pod:

kubectl get pods

Delete one:

kubectl delete pod POD_NAME

Immediately:

kubectl get pods -w

Observe what Kubernetes does.

Explain:

Deployment wants 5
       ↓
One Pod deleted
       ↓
Only 4 remain
       ↓
ReplicaSet detects mismatch
       ↓
Creates replacement
       ↓
Back to 5

This is desired state + reconciliation/self-healing.

PART 24 — Final cleanup

AWS resources cost money, so cleanup is part of the homework.

Delete Ingress first:

kubectl delete -f ingress.yaml

Verify the associated ALB resources are being removed before deleting the rest.

Then:

kubectl delete -f service.yaml
kubectl delete -f deployment.yaml

Check:

kubectl get ingress
kubectl get svc
kubectl get pods

Do not delete a shared class EKS cluster or Node Group unless instructed.

🎤 Monday presentation

Each student gets 5 minutes.

They must show one architecture diagram:

Code
 ↓
Dockerfile
 ↓
Image
 ↓
ECR
 ↓
EKS
 ↓
Deployment
 ↓
ReplicaSet
 ↓
Pods
 ↓
Service
 ↓
Ingress
 ↓
ALB
 ↓
Customer

Then answer:

What is the difference between Image and Container?
Why do we push the image to ECR?
What is a Node Group?
What is a Deployment?
What creates/manages the Pods for a Deployment?
How can you find which ReplicaSet owns a Pod?
Why shouldn't customers connect directly to Pod IPs?
How does Service find its Pods?
What are port and targetPort?
What happens if the Service selector is wrong?
What is Ingress?
What is an Ingress Controller?
Who configures/creates the ALB in this architecture?
Who handles the actual HTTP request?
What happens when a Pod dies?
Why did some Apple Silicon users need --platform linux/amd64?
What does ImagePullBackOff mean?
What is the difference between kubectl get and kubectl describe?
What does kubectl logs tell you?
How would you troubleshoot if the website stopped working?

Homework is complete only when the student can explain the architecture

The goal is not just to make the browser open.

The student should be able to look at this:

ALB → Service → Pod

and explain how the application got there from source code, where the image is stored, where the Pod runs, how Service discovers its backends, how Ingress/Controller configure external routing, and how they would troubleshoot each layer if something failed.

DEV Community: Aisalkyn Aidarova

Two-Day Homework — CI `needs` + Build + Docker

Part 1 — Git preparation

Part 2 — Review the three parallel CI jobs

Part 3 — Yesterday's main topic: needs

Part 4 — Build Job

Part 5 — Commit, Push and Pull Request

Part 6 — Docker Fundamentals

Part 7 — Study the Restaurant Company Dockerfile

Part 8 — Multi-stage Build

Part 9 — Build the Docker Image

Part 10 — Run the Container

Part 11 — Go Inside the Container

Part 12 — Exit Without Stopping the Container

Part 13 — Test with curl

Part 14 — Open Restaurant Company in Browser

Part 15 — Troubleshooting Incident

Part 16 — Command Challenge Without Notes

Part 17 — Interview Questions

Interview answer to practice

Production Lab: Restaurant Company — Helm + Argo CD + EKS

1. Architecture

2. Repository structure

3. Chart.yaml

4. values.yaml

5. values-prod.yaml

6. Namespace template

7. ConfigMap

8. ServiceAccount

9. Production Deployment

10. Service

11. PodDisruptionBudget

12. HPA

13. ALB Ingress

14. Validate the Helm chart

15. Optional: Test Helm manually first

16. Clean up the manual Helm release before Argo CD

17. Argo CD Application YAML

18. Push everything to GitHub

19. Bootstrap the Argo CD Application

20. What Argo CD now does

21. GitOps Lab #1 — Scale 3 → 5

22. GitOps Lab #2 — Configuration Drift

23. GitOps Lab #3 — Bad Image

24. GitOps Lab #4 — PDB condition

25. Student troubleshooting checklist

Final diagram for the students

WEEKEND HOMEWORK — Restaurant Company CI

Part 1 — Trivy manual security scan

Part 2 — Investigate the dependencies

Part 3 — Read the Trivy vulnerability report

Part 4 — Create a new Git branch

Part 5 — Create GitHub Actions CI

Part 6 — Explain Parallel Jobs

Part 7 — Push and create Pull Request

Part 8 — Weekend interview questions

JumpToTech — Production Kubernetes Complete Lab

1. What We Will Build

2. Project Structure

3. Verify the Cluster

4. Namespace

What is a Namespace?

5. ConfigMap

6. Secret

7. ServiceAccount

8. Production Deployment

9. Deployment → ReplicaSet → Pod

10. Labels and Selectors

11. Requests

12. Limits

13. Startup Probe

14. Readiness Probe

15. Liveness Probe

16. RollingUpdate Strategy

17. Apply Deployment

18. Inspect a Pod

19. Verify ConfigMap

20. Service

21. Understand port vs targetPort

22. EndpointSlice

Part 3 — Yesterday's main topic: `needs`

3. `Chart.yaml`

4. `values.yaml`

5. `values-prod.yaml`

21. Understand `port` vs `targetPort`

26. `selfHeal`

27. `prune`