In dev environments, you can't wait for production traffic to validate autoscaling behavior. You need synthetic, deterministic load that exercises the entire control loop: HPA decision-making, scheduler placement, kubelet startup latency, and metrics collection. The polinux/stress image provides precisely this: a maintained, security-compliant CPU and memory workload generator that exposes every weakness in your autoscaling configuration before customers do.

Why polinux/stress Is the Right Tool

The polinux/stress image is an actively maintained fork of the Linux stress utility with modern base images that pass CVE scanning. It accepts --cpu N arguments to spawn N CPU-intensive workers and --vm with --vm-bytes for memory pressure. Unlike HTTP load generators (wrk, ab, locust), it isolates resource consumption from network I/O, making it ideal for validating:

• HPA controller calculations: The controller queries metrics-server for pod-level CPU utilization, computes currentMetricValue / desiredMetricValue, and scales when the ratio exceeds thresholds​

• Metrics-server scraping latency: The default scraping interval and CPU initialization period (5 minutes) can delay scaling decisions​

• CFS throttling behavior: Containers requesting more CPU than their limit experience throttling via cpu.cfs_quota_us, visible in container_cpu_cfs_throttled_periods_total metrics​

• Scheduler and kubelet latency: Measures time from HPA scale-up decision to pod Ready status, including image pulls and CNI setup

Compared to the unmaintained vish/stress, polinux/stress provides the same functionality while meeting modern security compliance requirements.

Hands-On Demo: HPA Scale-Up and Scale-Down

Use this Killercoda scenario to follow along!

Setup: Deploy the Workload with Zero-Load Baseline

Create a namespace and deployment starting in an idle state. This establishes a performance baseline before triggering load:

# stress-deployment.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: autoscale-demo
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: cpu-stress
  namespace: autoscale-demo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: cpu-stress
  template:
    metadata:
      labels:
        app: cpu-stress
    spec:
      containers:
      - name: stress-ctr
        image: polinux/stress
        resources:
          limits:
            cpu: "1"
            memory: "512Mi"
          requests:
            cpu: "500m"
            memory: "256Mi"
        command: ["/bin/sh", "-c"]
        args: ["sleep infinity"]

Deploy it:

kubectl apply -f stress-deployment.yaml

# Wait for pod to be ready
kubectl wait --for=condition=ready pod -l app=cpu-stress -n autoscale-demo --timeout=60s

# Verify zero-load state
kubectl top pod -n autoscale-demo
# Expected: cpu-stress-xxxxx   ~1m   ~10Mi (near-zero CPU usage)

Configure HPA with CPU Target

Create an HPA targeting 50% CPU utilization:​

# hpa.yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: cpu-stress-hpa
  namespace: autoscale-demo
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: cpu-stress
  minReplicas: 1
  maxReplicas: 6
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 60   # Faster scale-down for demo
    scaleUp:
      stabilizationWindowSeconds: 0    # Immediate scale-up

Apply and verify:

kubectl apply -f hpa.yaml

# Wait for metrics to populate (15-30 seconds)
sleep 30

# Check HPA baseline
kubectl get hpa -n autoscale-demo -w

Establish Baseline Metrics

Before triggering load, validate that metrics-server is functioning and HPA recognizes the idle state:

# Describe HPA to see events and current status
kubectl describe hpa cpu-stress-hpa -n autoscale-demo

# Expected output includes:
# Metrics:
#   Resource cpu on pods (as a percentage of request):  0% (0m) / 50%
# Current number of replicas: 1
# ScalingActive condition: True

This confirms the HPA control loop is active and baseline CPU is near zero.​

Trigger Scale-Up with High CPU Load

Patch the deployment to generate CPU load:​

kubectl patch deployment cpu-stress -n autoscale-demo --type='json' \
  -p='[
    {"op": "replace", "path": "/spec/template/spec/containers/0/resources/requests/cpu", "value": "100m"},
    {"op": "replace", "path": "/spec/template/spec/containers/0/resources/requests/memory", "value": "128Mi"},
    {"op": "replace", "path": "/spec/template/spec/containers/0/resources/limits/cpu", "value": "500m"},
    {"op": "replace", "path": "/spec/template/spec/containers/0/resources/limits/memory", "value": "256Mi"},
    {"op": "replace", "path": "/spec/template/spec/containers/0/command", "value": ["stress"]},
    {"op": "replace", "path": "/spec/template/spec/containers/0/args", "value": ["--cpu", "2", "--verbose"]}
  ]'


# Wait for rollout
kubectl rollout status deployment/cpu-stress -n autoscale-demo

This combined patch accomplishes multiple objectives:

Resource Optimization for Single-Node:

• CPU request: 500m → 100m (allows up to 6 pods on a node with ~1 CPU available)

• CPU limit: 1000m → 500m (prevents individual pods from consuming entire node CPU)

• Memory request: 256Mi → 128Mi (reduces memory pressure)

• Memory limit: 512Mi → 256Mi (prevents OOM issues on small nodes)

Load Generation:

• Command change: ["/bin/sh", "-c"] → ["stress"]

• 2 CPU workers: Spawns 2 stress processes attempting to consume CPU continuously

• No timeout: Runs indefinitely until patched back to sleep

With the new configuration, each pod creates:​

• Actual usage: ~200m per pod (2 workers generating load)

• Utilization: 200m / 100m request = 200%

• HPA action: Current utilization (200%) exceeds target (50%), triggers scale-up

Monitor scale-up with timestamps:

# Watch HPA in real-time (updates every 15s)
kubectl get hpa cpu-stress-hpa -n autoscale-demo -w

# In another terminal, watch pods scaling
kubectl get pods -n autoscale-demo -w

Expected timeline:​

• T+15-30s: Metrics-server scrapes kubelet, updates cache

• T+30-45s: HPA polls metrics-server, sees 200% utilization

• T+45s: HPA updates deployment replicas (calculated as ceil(1 * (200/50)) = 4)

• T+60-90s: New pods reach Running and Ready state

• T+90-120s: Metrics stabilize across all pods

Expected HPA output after scale-up:

NAME              REFERENCE               TARGETS    MINPODS   MAXPODS   REPLICAS
cpu-stress-hpa    Deployment/cpu-stress   200%/50%   1         6         4
# After pods stabilize and share 1 CPU on single node:
cpu-stress-hpa    Deployment/cpu-stress   166%/50%   1         6         6

The HPA will scale to maximum replicas (6) because each pod with 2 CPU workers generates approximately 200m CPU load, creating 200% utilization (200m actual / 100m request). After scaling to 6 pods on a single-node cluster with 1 total CPU, each pod receives ~166m average, maintaining 166% utilization and keeping HPA at maxReplicas.

Verify Scaling Behavior and Resource Distribution

# Check final pod count
kubectl get pods -n autoscale-demo -l app=cpu-stress

# Check per-pod CPU usage (wait 60s for metrics stability)
sleep 60
kubectl top pod -n autoscale-demo
# Expected: Each pod consuming ~166m (1000m node capacity / 6 pods)

# View HPA events showing scale decisions
kubectl describe hpa cpu-stress-hpa -n autoscale-demo | grep -A 10 "Events:"
# Expected events:
# - ScalingReplicaSet: New size: 4; reason: cpu resource utilization above target
# - ScalingReplicaSet: New size: 6; reason: cpu resource utilization above target

# Verify updated resource configuration
kubectl get deployment cpu-stress -n autoscale-demo -o jsonpath='{.spec.template.spec.containers[0].resources}' | jq
# Expected:
# {
#   "limits": {"cpu": "500m", "memory": "256Mi"},
#   "requests": {"cpu": "100m", "memory": "128Mi"}
# }

# Check node allocation
kubectl describe node <worker-node> | grep -A 5 "Allocated resources:"
# Expected: cpu ~825m (225m system + 600m from 6 pods @ 100m each)

If you have Prometheus installed, validate CPU throttling:​

# Throttling periods per pod (indicates hitting CPU limits)
rate(container_cpu_cfs_throttled_periods_total{namespace="autoscale-demo"}[5m])

Test Scale-Down with Stabilization Window

Return to zero-load baseline and observe scale-down behavior:​

kubectl patch deployment cpu-stress -n autoscale-demo --type='json' \
  -p='[
    {"op": "replace", "path": "/spec/template/spec/containers/0/command", "value": ["/bin/sh", "-c"]},
    {"op": "replace", "path": "/spec/template/spec/containers/0/args", "value": ["sleep infinity"]}
  ]'

# Wait for rollout
kubectl rollout status deployment/cpu-stress -n autoscale-demo

We set the HPA to have a 60-second stabilization window for scale-down to increase speed. Monitor the behavior:​

# Watch HPA - note TARGETS drop but REPLICAS remain at 6
kubectl get hpa cpu-stress-hpa -n autoscale-demo -w

# Expected:
# T+0s:   cpu-stress-hpa   Deployment/cpu-stress   0%/50%   1   6   6
# T+300s: cpu-stress-hpa   Deployment/cpu-stress   0%/50%   1   6   1

After 60 seconds, replicas scale down to 1. This delay prevents rapid scaling oscillations during temporary load drops.​

Advanced: Multi-Metric Autoscaling with Memory

HPA supports scaling on multiple metrics simultaneously, selecting the maximum scale recommendation:​

# hpa-multi-metric.yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: stress-multi-hpa
  namespace: autoscale-demo
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: cpu-stress
  minReplicas: 2
  maxReplicas: 15
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 70
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 120        # Faster scale-down for testing
      policies:
      - type: Percent
        value: 50                             # Remove max 50% of pods
        periodSeconds: 60
      - type: Pods
        value: 2                              # Or max 2 pods
        periodSeconds: 60
      selectPolicy: Min                       # Use most conservative policy
    scaleUp:
      stabilizationWindowSeconds: 0           # Immediate scale-up
      policies:
      - type: Percent
        value: 100                            # Double pods
        periodSeconds: 15
      - type: Pods
        value: 4                              # Or add 4 pods
        periodSeconds: 15
      selectPolicy: Max                       # Use most aggressive policy

Update the deployment to stress both CPU and memory:​

kubectl patch deployment cpu-stress -n autoscale-demo --type='json' \
  -p='[
    {"op": "replace", "path": "/spec/template/spec/containers/0/command", "value": ["stress"]},
    {"op": "replace", "path": "/spec/template/spec/containers/0/args", "value": ["--cpu", "2", "--vm", "1", "--vm-bytes", "100M", "--verbose"]}
  ]'

# Apply multi-metric HPA
kubectl apply -f hpa-multi-metric.yaml

# Wait for metrics to stabilize (60 seconds)
sleep 60

# Check multi-metric status
kubectl get hpa stress-multi-hpa -n autoscale-demo

Expected behavior:​

• CPU: 1000m / 500m = 200% utilization → recommends ~7 replicas

• Memory: 200Mi / 256Mi = 78% utilization → recommends ~3 replicas

• HPA decision: Selects maximum (7 replicas)

Validating Scale-Up Latency and Metrics Pipeline

Measure end-to-end latency from load spike to pod readiness:​

# Reset to baseline
kubectl patch deployment cpu-stress -n autoscale-demo --type='json' \
  -p='[
    {"op": "replace", "path": "/spec/template/spec/containers/0/command", "value": ["/bin/sh", "-c"]},
    {"op": "replace", "path": "/spec/template/spec/containers/0/args", "value": ["sleep infinity"]}
  ]'

# Wait for scale-down to minReplicas
sleep 180

# Trigger load spike at T=0 and record timestamp
echo "Load spike triggered at: $(date +%H:%M:%S)"
kubectl patch deployment cpu-stress -n autoscale-demo --type='json' \
  -p='[
    {"op": "replace", "path": "/spec/template/spec/containers/0/command", "value": ["stress"]},
    {"op": "replace", "path": "/spec/template/spec/containers/0/args", "value": ["--cpu", "30", "--verbose"]}
  ]'

# Monitor with timestamps every 10 seconds
for i in {1..12}; do
  echo "--- T+$((i*10))s at $(date +%H:%M:%S) ---"
  kubectl get hpa stress-multi-hpa -n autoscale-demo --no-headers
  kubectl get pods -n autoscale-demo -l app=cpu-stress --no-headers | wc -l
  sleep 10
done

Typical latency breakdown:​

• T+0-30s: Metrics-server CPU initialization delay (default 30s via --horizontal-pod-autoscaler-initial-readiness-delay)​

• T+30-45s: HPA controller detects high utilization

• T+45-60s: Scheduler places new pods, image pull (if not cached)

• T+60-90s: Pods reach Ready, CNI initialization complete

• T+90-120s: Metrics include new pods, utilization stabilizes

This exposes real control-plane latencies that mirror production behavior.​

PromQL Queries for Observability

Monitor HPA and kubelet behavior with Prometheus:​

# HPA decision latency (controller reconciliation time)
rate(hpa_controller_reconciliation_duration_seconds_sum[5m]) 
  / rate(hpa_controller_reconciliation_duration_seconds_count[5m])

# CPU throttling per pod (indicates hitting limits)
rate(container_cpu_cfs_throttled_periods_total{namespace="autoscale-demo"}[5m])

# Metrics-server scrape latency
histogram_quantile(0.99, 
  rate(metrics_server_kubelet_request_duration_seconds_bucket[5m]))

# Pod startup time (requires kube-state-metrics)
kube_pod_start_time - kube_pod_created

Production-Ready Configuration Patterns

Approach A: Conservative (Avoid Flapping)

• scaleDown.stabilizationWindowSeconds: 300 (5 min)

• scaleUp.stabilizationWindowSeconds: 60

• Target utilization: 70-80%

Pros: Minimal pod churn, predictable costs, cache warmth preserved
Cons: Slower response to traffic drops, potential over-provisioning
When: Steady workloads with gradual changes, stateful apps with warm caches​

Approach B: Aggressive (Low Latency)

• scaleDown.stabilizationWindowSeconds: 60

• scaleUp.stabilizationWindowSeconds: 0

• Target utilization: 40-50%

Pros: Fast scale-up, headroom for bursts, responsive to spikes
Cons: Higher pod churn, wasted capacity, cold cache restarts
When: Latency-sensitive APIs, unpredictable spikes, stateless workloads​

Approach C: Custom Metrics (Advanced)
Use custom metrics (requests/sec, queue depth) instead of CPU for application-aware scaling. Requires Prometheus Adapter or KEDA.​

Pros: Application semantics, not resource proxies; accounts for P99 latency
Cons: Complexity, external dependencies, custom instrumentation
When: RPS-based workloads, async job queues, SLA-driven scaling​

The polinux/stress image removes the guesswork from autoscaling validation while meeting modern security requirements. By establishing a zero-load baseline and then generating deterministic CPU and memory load, you validate HPA calculations, expose metrics-server latency, measure scheduler performance, and identify throttling issues—all before production traffic exercises these code paths. Starting small and scaling gradually reveals configuration problems early, ensuring your autoscaler actually works when it matters most.

Next Steps

Expand Autoscaling Scope

Vertical Pod Autoscaler (VPA)
Move beyond horizontal scaling to automatically adjust CPU and memory requests/limits based on actual usage patterns. VPA analyzes historical consumption, peak usage, and OOM events to calculate optimal resource recommendations.​

# Install VPA (separate project, not part of core Kubernetes)
git clone https://github.com/kubernetes/autoscaler.git
cd autoscaler/vertical-pod-autoscaler
./hack/vpa-up.sh

# Create VPA for your stress workload
cat <<EOF | kubectl apply -f -
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: stress-vpa
  namespace: autoscale-demo
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: cpu-stress
  updatePolicy:
    updateMode: "Auto"      # Auto applies recommendations
  resourcePolicy:
    containerPolicies:
    - containerName: stress-ctr
      minAllowed:
        cpu: "100m"
        memory: "128Mi"
      maxAllowed:
        cpu: "2"
        memory: "1Gi"
EOF

VPA recommends target, lower bound, and upper bound resource values based on actual consumption trends.​

Cluster Autoscaler / Karpenter
Scale the node layer to ensure sufficient capacity for your autoscaling pods. Cluster Autoscaler adds/removes nodes based on pending pods and node utilization.​

KEDA (Event-Driven Autoscaling)
Move beyond resource-based metrics to scale on application events like queue depth, Kafka lag, HTTP requests/sec. KEDA is a CNCF-graduated project supporting 60+ scalers.​

# Install KEDA
kubectl apply -f https://github.com/kedacore/keda/releases/latest/download/keda-2.13.0.yaml

# Example: Scale based on Prometheus metrics
cat <<EOF | kubectl apply -f -
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: prometheus-scaler
spec:
  scaleTargetRef:
    name: cpu-stress
  triggers:
  - type: prometheus
    metadata:
      serverAddress: http://prometheus:9090
      metricName: http_requests_total
      threshold: '100'
      query: sum(rate(http_requests_total[2m]))
EOF

This scales based on actual application semantics rather than CPU/memory proxies.​

Advanced HPA Configuration

Custom Metrics with Prometheus Adapter
Integrate Prometheus metrics into HPA for application-aware autoscaling:​

# Install Prometheus Adapter
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm install prometheus-adapter prometheus-community/prometheus-adapter

# Configure HPA with custom metric
cat <<EOF | kubectl apply -f -
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: custom-metrics-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: cpu-stress
  metrics:
  - type: Pods
    pods:
      metric:
        name: http_requests_per_second
      target:
        type: AverageValue
        averageValue: "1000"
EOF

Scheduled Autoscaling
Pre-scale workloads for predictable traffic patterns using CronJobs that patch HPA min/max replicas:​

apiVersion: batch/v1
kind: CronJob
metadata:
  name: scale-up-business-hours
spec:
  schedule: "0 8 * * 1-5"  # 8 AM weekdays
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: kubectl
            image: bitnami/kubectl
            command:
            - /bin/sh
            - -c
            - kubectl patch hpa cpu-stress-hpa -n autoscale-demo --patch '{"spec":{"minReplicas":5}}'
          restartPolicy: OnFailure

This proactively scales before demand surges, eliminating cold-start latency.​

Production Observability

Integrate Grafana Dashboards
Visualize HPA metrics, pod lifecycle events, and resource utilization:​

• HPA metrics: kube_horizontalpodautoscaler_status_current_replicas, kube_horizontalpodautoscaler_status_desired_replicas

• Scaling events: Query Kubernetes events for ScalingReplicaSet reasons

• Pod startup latency: kube_pod_start_time - kube_pod_created

Alert on Autoscaling Issues
Set up Prometheus alerts for scaling failures:​

- alert: HPAMaxedOut
  expr: kube_horizontalpodautoscaler_status_current_replicas == kube_horizontalpodautoscaler_spec_max_replicas
  for: 15m
  annotations:
    summary: "HPA {{ $labels.horizontalpodautoscaler }} has been at max replicas for 15+ minutes"

- alert: HPAScalingDisabled
  expr: kube_horizontalpodautoscaler_status_condition{condition="ScalingActive", status="false"} == 1
  annotations:
    summary: "HPA {{ $labels.horizontalpodautoscaler }} scaling is disabled"

Cost and Performance Optimization

Manual Resource Request Tuning
After observing HPA behavior, adjust resource requests to improve efficiency:

• Over-provisioning: If HPA rarely scales and CPU stays at 20-30%, reduce requests​

• Under-provisioning: If HPA constantly maxes out and pods throttle, increase requests​

• Right-sizing: Match requests to P95 usage, not peak​

Load Testing in CI/CD
Integrate autoscaling validation into your pipeline using k6 or Locust:​

# .gitlab-ci.yml example
autoscaling-test:
  stage: test
  script:
    - kubectl apply -f hpa.yaml
    - k6 run --vus 100 --duration 5m load-test.js
    - kubectl get hpa cpu-stress-hpa -o jsonpath='{.status.currentReplicas}' | grep -v "^1$"  # Verify scale-up

This catches autoscaling regressions before production.​

StormForge Resources for ML-Powered Optimization

StormForge provides machine learning-driven Kubernetes optimization that goes beyond manual tuning. Their platform automates resource rightsizing, HPA configuration, and cost optimization using observability data and experimentation.​​

StormForge Optimize Live

Automated Resource Recommendations
StormForge Optimize Live continuously analyzes production workloads and generates ML-based recommendations for CPU/memory requests, limits, and HPA target utilization.​

Key features:​

• Continuous optimization: Monitors resource usage and application behavior to identify cost-saving configurations automatically​

• HPA target tuning: Recommends optimal HPA target utilization percentages (not just static 50%)​

• OOM protection: Configures temporary memory bump-ups in response to OOM events​

• One-click apply: Directly applies recommendations to your cluster via the StormForge controller​

Getting Started with StormForge
StormForge provides a comprehensive tutorial for integrating their platform:​

1. Install the StormForge agent:

# Add Helm repo
helm repo add stormforge https://registry.stormforge.io/chartrepo/library
helm repo update

# Install agent with your API token
helm install stormforge-agent stormforge/stormforge-agent \
  --namespace stormforge-system \
  --create-namespace \
  --set authorization.token=YOUR_API_TOKEN

2. Deploy an optimization experiment:​

# Create optimization resource
stormforge optimize create nginx-optimization \
  --application=nginx \
  --namespace=autoscale-demo

3. Review recommendations:​

stormforge optimize recommendations nginx-optimization

4. Apply optimizations:​
   Visit the StormForge web UI at https://app.stormforge.io and click "Apply Recommendations" to deploy optimized resource configurations directly to your cluster.​

StormForge and Karpenter Integration

For AWS EKS clusters, StormForge integrates with Karpenter for full-stack optimization:​

• StormForge optimizes workload requests: ML analyzes usage patterns and adjusts CPU/memory requests​

• Karpenter provisions nodes: Observes incoming pod requests and provisions right-sized nodes​

• Continuous feedback loop: As StormForge reduces requests, Karpenter consolidates nodes, reducing costs​

AWS provides a detailed walkthrough showing a 30-40% cost reduction using this combination.​

StormForge Documentation and Tutorials

Official Documentation

• Settings guide: Configure CPU/memory optimization, HPA target ranges, and OOM handling​

• Optimization tutorial: Step-by-step guide for workload rightsizing​

Video Resources

• Platform overview: "Solving the Kubernetes Efficiency Problem with StormForge"​

• Product demo: "StormForge Optimize Live Product Demo" showing top-down visibility and recommendation workflows​

• HPA/VPA deep dive: "HPA and VPA For Pods With StormForge" comparing horizontal vs vertical scaling with automated optimization​

Key Advantage Over Manual Tuning
StormForge uses ML to analyze thousands of containers simultaneously, identifying optimization opportunities invisible to manual analysis. It automates the tedious process of profiling workloads, calculating percentile-based resource needs, and updating configurations—achieving enterprise-scale optimization with minimal manual intervention.​

Continuous Optimization in CI/CD

StormForge supports automated optimization schedules via CI/CD pipelines:​

# Example GitLab CI integration
stormforge-optimize:
  stage: optimize
  schedule:
    - cron: "0 2 * * 0"  # Weekly optimization run
  script:
    - stormforge optimize run nginx-optimization
    - stormforge optimize recommendations nginx-optimization > recommendations.yaml
    - kubectl apply -f recommendations.yaml

This ensures resource configurations evolve with changing workload patterns.​

The progression from basic HPA demos with polinux/stress to production-grade autoscaling with VPA, KEDA, custom metrics, and ML-powered optimization platforms like StormForge provides a complete path from learning fundamentals to achieving enterprise-scale efficiency.

Originally written by: Seif Rajhi

Original article: VictoriaMetrics: A Guide, Comparing It to Prometheus...
Republished with permission

💬 Introduction

VictoriaMetrics is a time-series database designed for high-performance monitoring and analytics. It is similar to Prometheus in many ways, but it offers several advantages, including better performance, scalability, and data compression. VictoriaMetrics is also open-source and free to use.

VictoriaMetrics can monitor a wide range of systems, including Kubernetes clusters, servers, applications, infrastructure components, and even IoT devices.

In this blog post, we will provide a comprehensive overview of VictoriaMetrics, covering the following topics:

• What is VictoriaMetrics, and how does it work?

• How does VictoriaMetrics compare to Prometheus?

• How to implement Kubernetes monitoring with VictoriaMetrics

This blog post is for anyone who wants to learn more about VictoriaMetrics or use it to improve their system monitoring capabilities. It is also a good resource for anyone considering Prometheus and wanting to compare the two solutions.

TL;DR: VictoriaMetrics and Prometheus

VictoriaMetrics and Prometheus are both time-series databases used for monitoring and analytics, but they have some key differences:

Main features of VictoriaMetrics Compared to Prometheus

1. Performance and Scalability:

   • VictoriaMetrics: Higher performance, better scalability, and more efficient data compression.

   • Prometheus: Good performance but can struggle with high cardinality metrics and large-scale environments.

2. Resource Usage:

   • VictoriaMetrics: Lower CPU, RAM, and disk IO usage, especially with vmagent.

   • Prometheus: Higher resource consumption, especially with high cardinality metrics.

3. Data Ingestion:

   • VictoriaMetrics: Supports both pull and push models natively.

   • Prometheus: Primarily pull-based; requires Pushgateway for push model.

4. High Availability:

   • VictoriaMetrics: Built-in support for high availability.

   • Prometheus: No native high availability; requires duplication and sharding.

5. Long-Term Storage:

   • VictoriaMetrics: Designed for long-term storage with efficient data retention.

   • Prometheus: Not intended for long-term storage; relies on external solutions.

6. Anomaly Detection:

   • VictoriaMetrics: Includes built-in anomaly detection features.

   • Prometheus: Does not have built-in anomaly detection.

7. Buffering:

   • VictoriaMetrics: Independent disk-backed buffers for each remote storage.

   • Prometheus: Single shared buffer for all remote storage systems.

8. Query Language:

   • VictoriaMetrics: Uses MetricsQL, which extends PromQL with additional features.

   • Prometheus: Uses PromQL.

📊 VictoriaMetrics vs Prometheus: System Properties Comparison

VictoriaMetrics is a monitoring system that is fully compatible with Prometheus. It offers many of the same features as Prometheus, but with some additional benefits, such as higher performance and scalability.

One key difference between VictoriaMetrics and Prometheus is that VictoriaMetrics includes an anomaly detection feature. This feature can be used to identify unusual changes in metrics data, which can be helpful for troubleshooting and identifying potential problems.

While both vmagent and Prometheus may scrape Prometheus targets (aka /metrics pages) according to the provided Prometheus-compatible scrape configs and send data to multiple remote storage systems, vmagent has the following additional features:

• vmagent usually requires lower amounts of CPU, RAM, and disk IO compared to Prometheus when scraping an enormous number of targets (more than 1000) or targets with a great number of exposed metrics.

• vmagent provides independent disk-backed buffers for each configured remote storage (see -remoteWrite.url). This means that slow or temporarily unavailable storage doesn't prevent it from sending data to healthy storage in parallel. Prometheus uses a single shared buffer for all the configured remote storage systems (see remote_write->url) with a hardcoded retention of 2 hours.

• vmagent may accept, relabel, and filter data obtained via multiple data ingestion protocols in addition to data scraped from Prometheus targets. That means it supports both pull and push protocols for data ingestion. See these docs for details.

Prometheus does not have a native High Availability mode: to have high availability, we had to duplicate our Prometheus instances. This implies that our targets were "scraped" by all our Prometheus instances (same for our rules and records). To avoid this, we had to use sharding, but this made the infrastructure more complex. More information on this subject in this documentation from the Prometheus operator.

Prometheus is not designed to store metrics on a long-term basis, as mentioned in the documentation:

Prometheus's local storage is not intended to be durable long-term storage; external solutions offer extended retention and data durability.

We worked around this limitation by using VictoriaMetrics (VMCluster) as a LongTermStorage via the remote_write protocol.

All processes (scraping, ingest, storage, etc.) were, until now, managed in the same Prometheus instance, which implied a less flexible and vertical scaling only (since recently a Prometheus agent is available for the "scraping" part).

The RAM and CPU usage of a Prometheus instance is correlated to the number of metrics (and their cardinality) it has to manage. In our case, several Prometheus instances consumed more than 64 GB of RAM and 26 CPUs each, in order to absorb our peak loads. In a Kubernetes cluster, this high resource consumption can cause problems, especially for scheduling.

The Write-Ahead Log (WAL) system can cause rather slow restarts if the Prometheus instance runs out of RAM and can cause the Prometheus instance to hang for varying lengths of time. During the replay of the WAL, Prometheus doesn't scrape anything, thus there is no alerting and no way of knowing if something is going on.

📈 The Cardinality of Metrics

When our Kubernetes clusters manage a large number of pods, a constraint quickly appears: cardinality.

The cardinality of a metric is the number of TimeSeries of that metric with single-valued labels.

In the example above, the status_code label has a cardinality of 5, app has a cardinality of 2, and the overall cardinality of the server_responses metric is 10. In this example, any Prometheus instance can handle this cardinality, but if you add, for example, the label pod_name or client_IP (or both) to the server_responses metric, the cardinality increases for each different client's calls and for each pod.

You should read the excellent article on cardinality from "Robust Perception" for more details on this subject.

At Bedrock, the high cardinality metrics come from our HAProxy ingress. For our needs, we retrieve several labels like the name of the ingress pod as well as its IP address, but more importantly, the name and IP address of the destination pod. In a cluster that can grow to more than 15,000 pods, the combination of unique labels (cardinality) is very significant for some of our ingress metrics.

We found that Prometheus performed poorly when we had multiple metrics with high cardinalities (> 100,000), resulting in over-consumption of RAM. During a high load event, Prometheus could consume up to 200 GB of RAM before being OOMKilled. When this happened, we would go completely blind as we had no metrics or alerting. This also impacts scalability in our Kubernetes clusters, as we use Custom Metrics very heavily in HPAs to scale the number of pods in our applications.

There are many comparisons available online; here is a summary:

• System Properties Comparison: Prometheus vs. VictoriaMetrics - General information on both systems.

• Prometheus vs VictoriaMetrics Benchmark on Node Exporter Metrics - VictoriaMetrics uses much less disk and memory.

• FAQ: Differences Between vmagent and Prometheus - FAQ from VictoriaMetrics.

• Prominent Features of VictoriaMetrics - Documentation from VictoriaMetrics about its capabilities.

In short, some of VictoriaMetrics' abilities include:

• Supports both Pull and Push models (unlike Prometheus, which requires Pushgateway for push).

• You can configure Prometheus with remote write to VictoriaMetrics, i.e., write data to VictoriaMetrics from Prometheus.

• VictoriaMetrics has a concept of "namespaces" - you can have isolated environments for metrics, see Multitenancy.

• Has its own MetricsQL with wider capabilities than PromQL.

• For acquaintance, there is a VictoriaMetrics playground.

• For AWS, there is Managed VictoriaMetrics.

🏗️ VictoriaMetrics Cluster Architecture

VictoriaMetrics can be deployed as a single server or as a cluster version. I chose to deploy the VictoriaMetrics-cluster on k8s using Helm charts.

• vmstorage: Stores the raw data and returns the queried data on the given time range for the given label filters. This is the only stateful component in the cluster.

• vminsert: Accepts the ingested data and spreads it among vmstorage nodes according to consistent hashing over metric name and all its labels.

• vmselect: Performs incoming queries by fetching the needed data from all the configured vmstorage nodes.

• vmauth: A simple auth proxy and router for the cluster. It reads auth credentials from the Authorization HTTP header (Basic Auth, Bearer token, and InfluxDB authorization is supported), matches them against configs, and proxies incoming HTTP requests to the configured targets.

• vmagent: A tiny but mighty agent that helps you collect metrics from various sources and store them in VictoriaMetrics or any other Prometheus-compatible storage systems that support the remote_write protocol.

• vmalert: Executes a list of the given alerting or recording rules against configured data sources. Sending alerting notifications, vmalert relies on configured Alertmanager. Recording rules results are persisted via remote write protocol. vmalert is heavily inspired by Prometheus implementation and aims to be compatible with its syntax.

• promxy: Used for querying the data from multiple clusters. It's a Prometheus proxy that makes many shards of Prometheus appear as a single API endpoint to the user.

Cluster Resizing and Scalability

Cluster performance and capacity can be scaled up in two ways:

1. Vertical Scalability: By adding more resources (CPU, RAM, disk IO, disk space, etc.).

2. Horizontal Scalability: By adding more of each component to the cluster.

The components can all be scaled individually, with the only stateful component being the vmstorage component. This makes it easier to maintain and scale clusters. Adding new components and updating vminsert configurations is all it takes to scale the storage layer. Nothing else is needed.

🛠️ Implementation of VictoriaMetrics

VictoriaMetrics has charts for each component to deploy in Kubernetes. See Victoria Metrics Helm Charts. There are also charts to run VictoriaMetrics Operator and victoria-metrics-k8s-stack – an analog of the Kubernetes Prometheus Stack.

We will use the victoria-metrics-k8s-stack, which "under the hood" will launch VictoriaMetrics Operator, Grafana, and kube-state-metrics. See its dependencies.

A VMCluster (Insert, Select, Storage) is deployed to manage access to metrics. The collection of metrics (push/pull) from exporters in Prometheus format is handled by the vmagent. Its configuration is done in the form of a Prometheus configuration file. It is able to:

• Manage the relabeling of metrics.

• Temporarily store the metrics it has collected if the VMCluster is unavailable or not able to send the metrics to the VMCluster.

• Limit the cardinality of metrics.

One of the advantages of using this Helm chart is that it will deploy essential components to properly monitor a Kubernetes cluster such as kube-state-metrics or prometheus-node-exporter, but also scraping configurations for services such as Kubelet, KubeApiServer, KubeControllerManager, KubeDNS, KubeEtcd, KubeScheduler, KubeProxy.

Alerting is also managed via a VMAlert component, which will execute the alerting and recording rules set by VictoriaMetrics. Notifications are managed by an Alertmanager, which is also deployable via this chart.

This is what the monitoring and alerting stack based on this Helm chart looks like:

If you want to keep historical metrics of your Kubernetes clusters, VictoriaMetrics provides a tool to manage the export and import of data from different TSDB: vmctl.

Let's go. Let's start by checking the chart itself: victoria-metrics-k8s-stack.

📦 VictoriaMetrics Stack Helm Chart Installation

Add repositories with dependencies:

helm repo add grafana https://grafana.github.io/helm-charts
"grafana" has been added to your repositories
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
"prometheus-community" has been added to your repositories

And VictoriaMetrics itself:

helm repo add vm https://victoriametrics.github.io/helm-charts/
"vm" has been added to your repositories
helm repo update

All values can be taken as follows:

helm show values vm/victoria-metrics-k8s-stack > default-values.yaml

Or just from the repository — values.yaml.

VictoriaMetrics has very good documentation, so during the process, we will often use the API Docs.

Create a Configuration

victoria-metrics-operator:
    serviceAccount:
        create: false

alertmanager:
    enabled: true

vmalert:
    annotations: {}
    enabled: true

vmagent:
    enabled: true

grafana:
    enabled: true
    ingress:
        enabled: true
        annotations:
            kubernetes.io/ingress.class: alb
            alb.ingress.kubernetes.io/target-type: ip
            alb.ingress.kubernetes.io/scheme: internet-facing
        hosts:
            - monitoring.dev.example.com

🚀 Deploy to a New Namespace

helm upgrade --install victoria-metrics-k8s-stack -n monitoring --create-namespace vm/victoria-metrics-k8s-stack -f monitoring-values.yaml

Get the pods lists by running these commands:

kubectl get pods -A | grep 'victoria-metrics'
# or list all resources of victoria-metrics
kubectl get all -n monitoring | grep victoria

Get the application by running these commands:

helm list -f victoria-metrics -n monitoring

See the history of versions of victoria-metrics application with command:

helm history victoria-metrics -n monitoring

📋 Summarizing

In this post, VictoriaMetrics is a high-performance time-series database that is well-suited for Kubernetes monitoring and analytics. It offers several advantages over Prometheus, including:

• Superior scalability and performance

• Long-term storage capabilities

• Seamless integration with Kubernetes

• Anomaly detection

VictoriaMetrics can help organizations to improve their monitoring and analytics efforts, leading to more informed decision-making and improved system reliability.

Until next time, つづく 🎉

💡 Thank you for Reading !! 🙌🏻😁📃, see you in the next blog.🤘 Until next time 🎉

🚀 Thank you for sticking up till the end. If you have any questions/feedback regarding this blog feel free to connect with me:

♻️ LinkedIn: https://www.linkedin.com/in/rajhi-saif/

♻️ X/Twitter: https://x.com/rajhisaifeddine

The end ✌🏻

🔰 Keep Learning !! Keep Sharing !! 🔰

Let’s be honest, recruiters and hiring managers don’t just look at your resume anymore; they often check your GitHub profile first.

In this 2024 Open Source Software Funding Report, recommendations include encouraging employees to publicise their contributions to GitHub projects.

The impression they get can decide whether you move forward in the hiring process. The good news? You can control that impression. Let’s look at ways of doing just that, with examples from Ivan Velichko, Timur Sultanaev, Tim Hockin, Kat Cosgrove, Davanum Srinivas (dims), Benjamin Elder, and the community-driven KubeSkills GROW project.

Pin Your Best Repositories

Why it matters: It directs attention to your strongest work

Example: Tim Hockin’s profile highlights pinned repos like Kubernetes-related tools, design proposals, and code samples. This makes it easy for visitors to see high-value projects at a glance.

What you can do: Pin 3 to 6 repositories that reflect your strengths, whether that’s Go controllers, Kubernetes operators, or DevOps automation.

Write Polished README Files

Why it matters: Your README is the landing page of your project

Example: Ivan’s client-go-examples repo has clear, self-contained examples showing how to use Kubernetes client-go APIs. Each example includes its own README and context, making it approachable.

What you can do: Write READMEs that explain the problem, solution, tech stack, usage instructions, and examples. Add visuals like screenshots or GIFs to make them pop.

Contribute to Open Source

Why it matters: Shows you can collaborate and add value outside of personal projects.

Example: Kat Cosgrove is a developer advocate and open source contributor known for their work in the Kubernetes and cloud native ecosystem. Their contributions, ranging from documentation to community projects, demonstrate that open source isn’t only about code, but also about improving accessibility and education.

What you can do: Contribute small fixes, improve docs, or add features to projects you care about. Even modest contributions demonstrate collaboration and community impact.

Show Variety in Your Projects

Why it matters: Employers want to see breadth, not just another CRUD app.

Example: The mcp-k8s-go repo by Timur is a real-world tool that interacts with Kubernetes resources. It demonstrates complexity and problem-solving, not just tutorials.

What you can do: Balance utilities, tutorials, experiments, and production-grade projects in your profile.

Use GitHub Actions / Automation

Why it matters: Demonstrates knowledge of modern workflows (CI/CD, testing, automation).

Example: Many Kubernetes projects (including those maintained by Benjamin Elder and others in the Kubernetes org) use GitHub Actions or other CI pipelines for testing and validation, keeping quality high.

What you can do: Add workflows for testing, linting, formatting, or automatically updating parts of your README.

Commit Consistently

Why it matters: A steady contribution graph signals continuous growth.

Example: Davanum Srinivas (dims) is one of the most prolific Kubernetes contributors. His GitHub history reflects years of steady, high-impact activity across Kubernetes, CNCF projects, and related tooling. That level of consistency signals both expertise and long-term commitment to the ecosystem.

What you can do: Don’t wait for big projects, make small, steady improvements. Fix a bug, add a test, and improve the documentation. Consistency matters more than volume.

Document Your Learning

Why it matters: Public learning shows curiosity and persistence.

Example: The client-go-examples repo is itself a public learning exercise, with bite-sized code samples for Kubernetes developers.

Community-driven Example: The KubeSkills Student Notebook is part of the KubeSkills GROW initiative. Students fork the repo, add reflections via PRs, and track their growth. This demonstrates technical growth and collaboration in a public way.

What you can do: Create your own learning repo, or contribute to a community-driven one. Over time, it becomes a testament to your persistence and growth.

Use Professional Workflows in Your Repos

Why it matters: Employers want to see that you can work like a team.

Example: In mcp-k8s-go , issues, documentation, and structure make it look like a professional project, not just code thrown together.

What you can do: Use Issues, Pull Requests, and project boards (even in personal repos). It signals that you understand real workflows.

Add a Profile Readme

Why it matters: Your GitHub profile is your homepage.

Example: Nancy Chauhan’s GitHub profile is a strong example. She uses her profile README to highlight who she is, what she’s working on, and how to connect with her. It’s simple, straightforward, and professional. This is precisely what recruiters look for.

What you can do: Create a repo named after your GitHub username and add a README with your skills, current projects, and ways to connect.

Highlight Quality, Testing, and Security

Why it matters: Employers value reliable, secure code.

Example: The mcp-k8s-go repo utilizes structured, tested code, signaling that it’s production-ready.

What you can do: Add unit tests, coverage reports, linting, and security checks (Dependabot, Trivy). Even in small projects, this signals you think like a professional.

Conclusion & Next Steps

By applying these 10 steps, you’ll do more than improve your GitHub profile; you’ll give employers an apparent reason to say yes. A polished, active, and well-documented profile speaks volumes about your skills and work style.

Start today by forking the KubeSkills Student Notebook, documenting your progress, and building a portfolio that proves your growth. Share your updated GitHub profile with the community and inspire others to grow alongside you. Employers notice developers who learn, share, and collaborate. Make sure you’re one of them!

Bonus Call to Action: If you want to take your GitHub journey even further, consider exploring the LFX Mentorship Program. It connects developers with open source projects under the Linux Foundation, giving you real-world experience and a public record of contributions. Nearly half of mentees report that the program helped them secure new jobs, proof that visible contributions can open doors to career opportunities.

Kubernetes is an open-source container orchestration platform that allows developers to automate the deployment, scaling, and management of containerized applications. One of the key features of Kubernetes is its API, which provides a uniform way to interact with the platform and perform tasks such as deploying and managing applications, monitoring the status of the cluster, and updating configuration settings.

This article will teach you about the Kubernetes API and its various objects, such as Pod, Service, Controller, Deployment, and Storage. You will also learn what each object does and see examples that will help you understand its functionality.

What is the Kubernetes API?

The Kubernetes API is the primary interface for interacting with a Kubernetes cluster. It is exposed by the kube-apiserver, which serves as the central control plane component handling all REST operations for creating, modifying, and retrieving the state of cluster resources.

The API provides endpoints to manage core and custom resources, such as Pods, Deployments, Services, ReplicaSets, and Namespaces, using RESTful principles over HTTPS and commonly returns data in JSON format.

The Kubernetes API consists of a set of basic API objects that represent the system’s current state. These API objects enable the configuration of the system’s state, which can be done either declaratively or imperatively. Declarative configuration involves describing the desired implementation, such as specifying the deployment and how we want the system to appear. On the other hand, imperative configuration involves executing a sequence of commands on the command line to achieve the desired system state.

Some of the Kubernetes API Objects

In this section, you will explore some of the essential Kubernetes API objects and their functionalities. Understanding these objects is crucial for effectively harnessing the power of Kubernetes and maximizing the efficiency of your containerized infrastructure. Let's dive in and discover the key Kubernetes API objects that form the backbone of this powerful platform.

Pods

“Pods are the smallest deployable units of computing that you can create and manage in Kubernetes” — The Kubernetes documentation. To create a Pod, create a manifest (YAML or JSON) file with a specification. The specification will contain the Pod name and the Pod's container(s) image. When you apply the manifest, Kubernetes schedules the Pod on a worker node in the cluster.

Below is an example YAML manifest that defines a Pod object:

apiVersion: v1
kind: Pod
metadata:
 name: nginx-pod
 labels:
   env: dev
spec:
 containers:
   - name: nginx
     image: nginx

The above YAML file describes a Kubernetes Pod running a single container of the nginx image. Let's break down the different fields:

• apiVersion: v1: This specifies the Kubernetes API version used for this Pod, in this case, v1.

• kind: Pod: This specifies the type of Kubernetes resource being described, in this case, a Pod.

• metadata: This section contains metadata about the Pod, such as its name and labels.

• name: nginx-pod: This is the name of the Pod.

• labels: This is a set of key-value pairs that can be used to identify and group related resources. In this case, the label env: dev is applied to the Pod.

• spec: This section describes the specification for the Pod.

• containers: This is an array of containers to be run in the Pod. In this case, there is a single container.

• name: nginx: This is the name of the container.

• image: nginx: This specifies the Docker image to use for the container. In this case, it will use the official nginx image from Docker Hub.

Pods are considered ephemeral, meaning they are not redeployed if they die. For instance, if we deploy an application as a Pod based on a container image and that Pod dies, Kubernetes will automatically deploy another Pod based on the same container image. There is no state maintained between these two pods, and they are considered independent of each other.

Pods are also considered atomic, meaning they either exist or do not exist. For example, in a single container Pod, if the application running inside that Pod dies, the Pod also dies. Similarly, in a multi-container Pod where multiple applications run, the entire Pod becomes unavailable if one of those applications dies. Therefore, having only one container-based application inside a Pod is recommended to avoid any unwanted dependencies between applications.

Controllers

Controllers are responsible for defining and maintaining the desired state of a cluster. The controller managers ensure that the system remains in the desired state. For controllers to define and manage the desired state of deployed applications, they monitor and respond to the state and health of the Pods, ensuring that the desired number of pods are up and running and healthy. If the state or health changes, the controller will respond accordingly, ensuring the system stays in the desired state.

Kubernetes utilizes controller managers to monitor the state of a pod and ensure that it remains operational. There are different types of controller managers; the following are some of them:

• ReplicaSet Controller Manager: It allows you to define the number of replicas for a particular Pod you want up and running at all times. Suppose one of those Pods becomes unhealthy and unavailable for any reason. In that case, it's the job of the ReplicaSet controller to delete that unhealthy Pod and deploy a new Pod to return the system to its desired healthy state.

• Deployment set Controller Manager: When deploying applications in Kubernetes, you do not create ReplicaSet(s) directly. Instead, you create a deployment, which then creates a ReplicaSet based on what is specified in the Deployment manifest file. The Deployment manages the state of the replica set, such as the number of Pods to create and which container image to run. Additionally, the Deployment set manages the transition between two ReplicaSets, such as when updating an application with new changes or transitioning from one version of an application to another.

To learn about other Controllers, check out this Kubernetes documentation on controllers.

Services

Services in Kubernetes provide a persistent access point to the applications deployed as Pods. They add persistence to the ephemeral nature of Pods. A Service is an abstraction that defines a set of Pods and a policy for accessing them. It offers reliable and stable network connections to the Pods, allowing you to expose your application to the outside world or other parts of your cluster.

Services can automatically distribute incoming traffic among the Pods in a Deployment, providing load-balancing features and allowing you to scale your application as needed.

There are different types of Services in Kubernetes, each with its own set of features and use cases. Some of the most common types are:

• ClusterIP: This is a type of service that exposes the pods within the cluster only. It creates a virtual IP address that is accessible only within the cluster.

• NodePort: This type of service exposes the pods to the network by opening a port on each node in the cluster. The port can be used to access the service from outside the cluster.

• LoadBalancer: This service is similar to NodePort but also creates an external load balancer to distribute incoming traffic to the pods. Load balancers are typically used in cloud-hosted clusters where the cloud provider can create and manage the load balancer for you.

The following is a YAML manifest that defines a NodePort service:

apiVersion: v1
kind: Service
metadata:
 name: nginx-service
spec:
 type: NodePort
 ports:
   - port: 80
     targetPort: 80
     nodePort: 30008
 selector:
   env: dev

The above YAML file describes a NodePort Service that will expose the Pod running the nginx image on port 80. Let's break down the different fields:

• apiVersion: v1: This specifies the Kubernetes API version used for this Service, in this case, v1.

• kind: Service: This specifies the type of Kubernetes resource being described, in this case a Service.

• metadata: This section contains metadata about the Service, such as its name.

• name: nginx-service: This is the name of the Service.

• spec: This section describes the specification for the Service.

• type: NodePort: This specifies the type of the Service, in this case NodePort. This type exposes the Service on a static port on each Node in the cluster.

• ports: This is an array of ports to be exposed by the Service.

• port: 80: This is the port number on which the Service will listen.

• targetPort: 80: This is the port number of the Pod to which the traffic will be forwarded.

• nodePort: 30008: This is the static port number on each Node in the cluster on which the Service will be exposed.

• selector: This is a set of key-value pairs that will be used to match the Service to the Pod to which it will forward traffic.

• env: dev: This specifies the label to use for matching the Service to the Pod. In this case, the Service will match any Pod with the label env: dev.

In Kubernetes clusters, services provide network connectivity, load balancing, and service discovery for your applications. They help you build scalable and highly available applications that can run on a cluster of machines.

Storage

In Kubernetes, there are storage options that provide persistent storage for your applications. Storage refers to the different storage solutions used to store data for our applications. These storage solutions can be local to a single node or distributed across multiple nodes. They can be used to store application data, configuration data, or log data.

In Kubernetes, Persistent Volume (PV), Persistent Volume Claim (PVC), and StorageClass are Kubernetes resources used for managing storage in a cluster.

• Persistent Volume (PV) is a Kubernetes resource that represents a piece of storage that can be dynamically provisioned when a claim for storage is made, or they can be manually created and managed by an administrator.

Below is a yaml template that defines a PV object.

apiVersion: v1
kind: PersistentVolume
metadata:
 name: my-pv
spec:
 accessModes:
 - ReadWriteOnce
 capacity:
   storage: 500Mi

‍The above YAML manifest describes a Kubernetes PV that can be used to store data persistently in the cluster. Let's break down the different fields:

• apiVersion: v1: This specifies the Kubernetes API version used for this PV, in this case v1.

• kind: PersistentVolume: This specifies the type of Kubernetes resource being described, in this case a Persistent Volume.

• metadata: This section contains metadata about the PV, such as its name.

• name: my-pv: This is the name of the PV.

• spec: This section describes the specification for the PV.

• accessModes: This is an array of access modes that the PV supports.

• - ReadWriteOnce: This access mode specifies that the PV can be mounted as read-write by a single node.

• capacity: This section specifies the capacity of the PV.

• storage: 500Mi: This specifies the storage capacity of the PV, in this case 500MiB.

The YAML file describes a Persistent Volume that can be used to store data persistently in the cluster, with a storage capacity of 500MiB, and can be mounted by a single node as read-write. However, this PV is not bound to any specific Persistent Volume Claim (PVC) yet. To make it usable by a specific application, a matching PVC should be created that requests storage with the same access mode and capacity as the PV. Then, the PV should be bound to the PVC to make it available for use by the application.

• Persistent Volume Claims (PVCs) in Kubernetes are requests made by pods in your cluster for storage. When a PVC is created, it will bind to a Persistent Volume (PV) and make the storage available to the pod. In other words, a PVC is a way for pods to request a specific amount of storage without having to know the underlying details of where that storage is coming from.

Below is a YAML template that defines a PVC object :

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: my-claim
spec:
 accessModes:
 - ReadWriteOnce
 storageClassName: google-storage
 resources:
   requests:
     storage: 300Mi

‍ This is a YAML file that describes a Kubernetes Persistent Volume Claim (PVC) that requests storage from a Persistent Volume (PV) with specific characteristics. Let's break down the different fields:

• apiVersion: v1: This specifies the Kubernetes API version used for this PVC, in this case v1.

• kind: PersistentVolumeClaim: This specifies the type of Kubernetes resource being described, in this case, a Persistent Volume Claim.

• metadata: This section contains metadata about the PVC, such as its name.

• name: my-claim: This is the name of the PVC.

• spec: This section describes the specification for the PVC.

• accessModes: This is an array of access modes that the PVC requires.

• - ReadWriteOnce: This access mode specifies that the PVC requires read-write access to the storage.

• storageClassName: google-storage: This specifies the name of the StorageClass to use for creating the PV. The StorageClass provides a way to specify the underlying storage provider and its characteristics.

• resources: This section specifies the resource requirements for the PVC.

• requests: This section specifies the minimum amount of storage that the PVC requires.

• storage: 300Mi: This specifies the minimum amount of storage capacity that the PVC requires, in this case 300MiB.

The YAML file describes a Persistent Volume Claim that requests 300MiB of storage with read-write access from a PV with a StorageClass of google-storage. If a PV with matching characteristics is available in the cluster, the PVC will bind to it and make it available for use by the application. If a suitable PV is not available, a new PV will be dynamically provisioned according to the StorageClass definition.

• Storage Classes are used to define the type of storage that will be dynamically provisioned when a Persistent Volume Claim (PVC) is created. A Storage Class represents a set of parameters for dynamic provisioning of Persistent Volumes. These parameters can include the type of storage (e.g., block or file), the performance characteristics (e.g., SSD or HDD), and the location of the storage (e.g., on-premises or in the cloud). When a PVC is created and the StorageClass is specified, the Kubernetes cluster will automatically provision a Persistent Volume that meets the criteria defined in the Storage Class.

Below is a yaml template that defines a StorageClass object :

apiVersion: storage,k8s.io/v1
kind: StorageClass
metadata:
 name: my-google-storage
provisioner: Kubernetes.io/gce-pd
parameters:
 type: pd-standard
 replication-type: none

This is a YAML file that describes a Kubernetes StorageClass resource, which is used to define different classes of storage with specific characteristics. Storage classes allow users to request storage resources without having to know the underlying details of the storage infrastructure.

Let's break down the different fields:

• apiVersion: storage.k8s.io/v1: This specifies the Kubernetes API version used for this StorageClass, in this case storage.k8s.io/v1.

• kind: StorageClass: This specifies the type of Kubernetes resource being described, in this case, a StorageClass.

• metadata: This section contains metadata about the StorageClass, such as its name.

• name: my-google-storage: This is the name of the StorageClass.

• provisioner: Kubernetes.io/gce-pd: This specifies the name of the storage provider that will be used to provision the underlying storage resources. In this case, it's using the GCE-PD provisioner, which provisions Google Compute Engine persistent disks.

• parameters: This section specifies additional parameters for the storage provider.

• type: pd-standard: This parameter specifies the type of disk to use for the persistent disk, in this case, pd-standard.

• replication-type: none: This parameter specifies that replication is not required for this storage class.

The YAML file describes a StorageClass named my-google-storage that uses the GCE-PD provisioner to dynamically provision persistent disks of type pd-standard without replication. This StorageClass can be used to dynamically provision Persistent Volumes when requested by Persistent Volume Claims that request the same StorageClass.

Kubernetes storage allows your applications to store data persistently, even if the pods or containers that use the data are deleted or recreated. It also enables you to manage the various types of storage available in your cluster and provision new storage dynamically as required. By using Kubernetes storage, you can ensure that your data is safe and available whenever your application needs it.

Deployment

A Deployment manages a ReplicaSet, which in turn manages the deployment and scaling of a set of Pods. By using a Deployment object, you can define a desired state for the ReplicaSet, such as the number of replicas to be created, the container images to be used, and the configuration options to be set. The Deployment object then ensures that the desired state is achieved by updating or rolling back the ReplicaSet as necessary.
Deployments enable you to perform rolling updates and rollbacks, which are done by creating a new ReplicaSet and slowly replacing the old Pods with the new ones. This ensures that there is no downtime and that the latest version of the application is rolled out gradually.

The following YAML template defines a deployment object:

apiVersion: apps/v1
kind: Deployment
metadata:
 name: my-app-deployment
spec:
 replicas: 3
 selector:
   matchLabels:
     app: my-app
 template:
   metadata:
     labels:
       app: my-app
   spec:
     containers:
       - name: my-app-container
         image: my-app-image:latest
         ports:
           - containerPort: 8080
         volumeMounts:
           - name: my-app-pvc
             mountPath: /data
     volumes:
       - name: my-app-pvc
         persistentVolumeClaim:
           claimName: my-pvc

The above YAML file describes a Kubernetes Deployment resource, which is used to manage the lifecycle of a set of replicated Pods. This Deployment creates and manages a set of replicas of a containerized application, as well as the associated resources, such as a Persistent Volume Claim and a Volume to store the application's data. Let's break down the different fields:

• apiVersion: apps/v1: This specifies the Kubernetes API version used for this Deployment, in this case, apps/v1.

• kind: Deployment: This specifies the type of Kubernetes resource being described, in this case,e a Deployment.

• metadata: This section contains metadata about the Deployment, such as its name.

• name: my-app-deployment: This is the name of the Deployment.

• spec: This section describes the specification for the Deployment.

• replicas: 3: This specifies the number of replicas of the application to create.

• selector: This specifies the labels used to select the Pods managed by the Deployment.

• matchLabels: This specifies the labels used to match the Pods managed by the Deployment.

• app: my-app: This label selects the Pods that have the label app set to my-app.

• template: This specifies the Pod template used to create the replicas.

• metadata: This section contains metadata about the Pod template.

• labels: This specifies the labels used to select the Pods created from the template.

• app: my-app: This label is applied to the Pods created from the template.

• spec: This section specifies the specification for the Pod template.

• containers: This specifies the containers to be run in the Pod.

• name: my-app-container: This specifies the name of the container.

• image: my-app-image:latest: This specifies the Docker image to use for the container, with a tag of latest.

• ports: This specifies the ports to be exposed by the container.

• containerPort: 8080: This specifies that the container will listen on port 8080.

• volumeMounts: This specifies the volumes to be mounted by the container.

• name: my-app-pvc: This specifies the name of the volume to be mounted.

• mountPath: /data: This specifies the mount path for the volume in the container.

• volumes: This specifies the volumes to be created for the Pod.

• name: my-app-pvc: This specifies the name of the volume.

• persistentVolumeClaim: This specifies that the volume is backed by a Persistent Volume Claim.

• claimName: my-pvc: This specifies the name of the Persistent Volume Claim that the volume is backed by.

The YAML file describes a Deployment named my-app-deployment that manages three replicas of an application containerized in my-app-image:latest. The Pods created by the Deployment have a volume my-app-pvc mounted at /data, which is backed by a Persistent Volume Claim named my-pvc.

Conclusion

In this article, you learned about the Kubernetes API and some of its various objects. Other API objects in Kubernetes can be used to define the desired state of a cluster. To learn more about them, check out the Kubernetes documentation.

‍

(Yes, we’re talking to you.)

What if learning Kubernetes wasn’t just about passing a course…
…but building your GitHub portfolio, proving your skills, and leveling up your career?

Introducing GROW 🌱 - GitHub Repository of Work

From the crew at KubeSkills, GROW is where your Kubernetes journey turns into a living, breathing portfolio of YAML-powered awesomeness.

🚀 How does it work?

With GROW, you:

✅ Fork a ready-to-rock GitHub repo template
✅ Document your labs, reflections, configs, and tools
✅ Show the world what you're made of (hint: containers and grit)
✅ Level up with badges (Starter → Bronze → Silver → Gold)

This isn’t homework, it’s your future resume!

🪴 What You’ll Gain

Employers want to see what you can do!

With GROW, they can:

• Browse your real-world Kubernetes portfolio (YAML, GitOps templates, security configs…)

• See your actual Git history and progress towards learning and growing

• Gain confidence in your knowledge before the interview

📈 Learning That Scales

Whether you’re:
✔ Creating your first pod
✔ Securing clusters with Network Policies
✔ Automating deployments with FluxCD
✔ Or launching your portfolio site on GitHub Pages.

GROW has everything you need to show your work! Entirely yours and entirely open source!

❓Have questions? Submit a PR!

If you hit a roadblock or you’re unsure of something, this is where the KubeSkills community comes in!

• Create a file like 99-reflections/weekX.md or questions/question.md

• Add your question and context (what you tried, what you expected, and any doubts)

• Submit a Pull Request titled: question: [Your Topic]

🙌 Let’s GROW Together

Start for FREE. No gatekeeping. No fluff. Just skills.

Are you ready to fork your future?

📂 Grab the notebook template here: https://github.com/kubeskills/grow
📢 Share your progress on socials with #KubeSkillsGROW
📬 Email us your notebook to get featured: notebooks@kubeskills.com

🌍 At KubeSkills, we don’t just teach Kubernetes, we help build cloud native careers!

Let’s do this. 💪

🌐 Want Even More?

Coming Soon: GROW+

Yeah, we’re taking it further:

• 1:1 reviews with instructors

• Verified badges for your LinkedIn profile

• Community spotlight on our site

In this beginner's guide, I aim to break down some of the complexity and deliver some tacit knowledge, allowing you to get hands-on with FluxCD. I'll show you the benefits of FluxCD, so you feel confident getting up and running. Also, you'll learn by doing an actual project!

What is FluxCD?

FluxCD is an open-source continuous delivery tool designed for Kubernetes. It works by continuously monitoring your Git repository and applying any changes to your Kubernetes cluster. With FluxCD, you can automate updates and rollbacks and even monitor your deployments.

Key Features of FluxCD

• GitOps: FluxCD leverages Git as the single source of truth, enabling declarative management of infrastructure and application deployments.

• Automated Deployments: FluxCD continuously monitors your Git repository and automatically updates your Kubernetes cluster with the desired state.

• Syncing and Reconciliation: FluxCD ensures that the live state of your cluster matches the state defined in your Git repository.

• Multi-Tenancy: FluxCD supports managing multiple environments, allowing you to use the same Git repository for staging, production, and more.

• Integrations: FluxCD integrates well with tools like Helm, Prometheus, and others to provide a comprehensive solution for GitOps.

Core Components of FluxCD

Before we dive into the hands-on part, let's briefly discuss the core components of FluxCD:

1. Flux is the primary operator (control plane), continuously monitoring the Git repository and applying changes to the Kubernetes cluster.

2. The Helm Controller is a component of FluxCD that allows you to manage Helm charts in a GitOps fashion.

3. The Kustomize Controller supports managing Kubernetes manifests using Kustomize, enabling you to customize your deployments.

4. The Notification Controller handles notifications and alerts for your deployments.

5. The Source Controller monitors the source of the Kubernetes manifests (Git, Helm repositories, etc.) and makes them available for the other controllers.

Creating a GitHub Personal Access Token (PAT)

Since FluxCD uses Git as the single source of truth for deployments, the apparent prerequisite is a Git hosting service. Flux CLI creates a new GitHub repository for you, but it needs a personal access token (PAT) to do so.

Create a new PAT by going to the following GitHub link: https://github.com/settings/tokens/new

Select the checkmark box next to "repo," as shown below, then click "Generate Token." Copy the PAT, as you will use it for the next step!

Installing FluxCD

FluxCD can be installed using the flux CLI tool. Here's how you can set it up on your Kubernetes cluster. For free access to a cluster, head to Killercoda.com and follow along!

1. Install the Flux CLI:

    curl -s https://fluxcd.io/install.sh | sudo bash
   

2. Bootstrap FluxCD:

   The bootstrap command installs the FluxCD components and configures them to reconcile your cluster state with a Git repository (replace <github-username> with your GitHub username).

    flux bootstrap github \
      --owner=<github-username> \
      --repository=my-flux-repo \
      --branch=main \
      --path=./clusters/my-cluster \
      --personal=true \
      --private=false
   

3. Verify the Installation:

   After bootstrapping, you can verify that FluxCD is running correctly using the command flux check --pre which will check the health of the Flux components in your Kubernetes cluster.

    flux check --pre
   

4. Clone the Repo:
   After running the flux bootstrap github command, you should clone the GitHub repository that Flux created during the bootstrap process. This allows you to add your application files (e.g., Kubernetes manifests, Helm charts, or Kustomize files) to the repository. These files define the desired state of your applications, which Flux will then monitor and apply to your Kubernetes cluster (replace <github-username> with your GitHub username).

    git clone https://github.com/<github-username>/my-flux-repo.git
   

5. Create your Application Directory
   Inside the cloned repository, you will see the directory structure created by Flux. Typically, a specific directory is created to store the application manifests, helm charts or Kustomize configurations (e.g. apps/my-app). Create the directory where your application files will go.

    mkdir -p my-flux-repo/apps/my-app
   

6. (Optional) Organize Your Repository
   For larger projects, you can structure your repository into separate directories for staging, production, and other environments. The following is an example of this organizational pattern, which allows you to define shared configurations in the base directory and customize them for each specific environment in the overlays directory, without duplicating code.

    apps/
    ├── my-app/
    │   ├── base/
    │   │   ├── deployment.yaml
    │   │   └── service.yaml
    │   ├── overlays/
    │       ├── staging/
    │       └── production/
    clusters/
    ├── staging/
    │   └── kustomization.yaml
    └── production/
        └── kustomization.yaml
   

Building a Sample Microservices Application

In this example, we'll create a simple microservices-based application consisting of two services:

1. Frontend Service: A simple web server built using Node.js that serves static content.

2. Backend Service: A Python-based API service that provides some data to the frontend.

For most Kubernetes-based setups using FluxCD, the best practice is to store application code and deployment manifests in separate repositories. This adheres to GitOps principles, where your Git repository serves as the single source of truth for your cluster's desired state. Therefore, we’ll create a new application repository that contains our application code.

mkdir src && cd src

Frontend Service

The frontend service will be a basic Node.js application that serves an HTML page. Here's the code:

cat << EOF > index.js
// index.js
const express = require('express');
const app = express();
const port = 3000;

app.get('/', (req, res) => {
  res.send('<h1>Welcome to the Frontend Service</h1>');
});

app.listen(port, () => {
  console.log('Frontend service is running on http://localhost:${port}');
});
EOF

Create a Dockerfile for the frontend service:

cat << EOF > JS-Dockerfile
# JS-Dockerfile
FROM node:14-alpine

WORKDIR /app

COPY package*.json ./
RUN npm install

COPY . .

EXPOSE 3000
CMD ["node", "index.js"]
EOF

Backend Service

The backend service will be a simple Python Flask application that returns some JSON data. Here's the code:

cat << EOF > app.py
# app.py
from flask import Flask, jsonify

app = Flask(__name__)

@app.route('/api/data', methods=['GET'])
def get_data():
    data = {
        'message': 'Hello from the Backend Service!'
    }
    return jsonify(data)

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=5000)
EOF

Create a Dockerfile for the backend service:

cat << EOF > Py-Dockerfile
# Dockerfile
FROM python:3.8-slim

WORKDIR /app

COPY requirements.txt ./
RUN pip install --no-cache-dir -r requirements.txt

COPY . .

EXPOSE 5000
CMD ["python", "app.py"]
EOF

Create the requirements.txt file:

echo "flask" > requirements.txt

create a package.json file:

# package.json
cat << EOF > package.json
{
  "name": "flux-project",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "dependencies": {
    "express": "^4.17.1"
  },
  "scripts": {
    "test": ""
  },
  "author": "",
  "license": "ISC"
}
EOF

Build the Container Images

We'll build the container images for both the front and backend apps using the Docker CLI. Use the following commands to build and tag the images using the two separate Dockerfile files named JS-Dockerfile and Py-Dockerfile:

docker build -f JS-Dockerfile -t localhost:5000/my-frontend .

docker build -f Py-Dockerfile -t localhost:5000/my-backend .

Create a container registry locally:

docker run --name local-registry -d -p 5000:5000 registry

Push the container images to the local registry:

docker push localhost:5000/my-backend
docker push localhost:5000/my-frontend

Creating Kubernetes Manifests

Next, we'll create Kubernetes manifests for deploying these two services, placing them in the repo that we created and cloned at the beginning, in my-flux-repo/apps/my-app. Use your favorite text editor to create these files in the my-app directory.

cd $HOME/my-flux-repo/apps/my-app

Frontend Deployment Manifest

# frontend-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend
  namespace: default
  labels:
    app: frontend
spec:
  replicas: 2
  selector:
    matchLabels:
      app: frontend
  template:
    metadata:
      labels:
        app: frontend
    spec:
      containers:
      - name: frontend
        image: localhost:5000/my-frontend:latest
        ports:
        - containerPort: 3000

Frontend Service Manifest

# frontend-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: frontend-service
  namespace: default
spec:
  selector:
    app: frontend
  ports:
    - protocol: TCP
      port: 80
      targetPort: 3000

Backend Deployment Manifest

# backend-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend
  namespace: default
  labels:
    app: backend
spec:
  replicas: 2
  selector:
    matchLabels:
      app: backend
  template:
    metadata:
      labels:
        app: backend
    spec:
      containers:
      - name: backend
        image: localhost:5000/my-backend:latest
        ports:
        - containerPort: 5000

Backend Service Manifest

# backend-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: backend-service
  namespace: default
spec:
  selector:
    app: backend
  ports:
    - protocol: TCP
      port: 80
      targetPort: 5000

Setting Up FluxCD to Deploy the Application

Now that we have our application and Kubernetes manifests ready, let's set up FluxCD to deploy them.

Step 1: Create a Kustomization File

Also in the my-app directory, create a kustomization.yaml file. This file tells FluxCD to apply the resources defined in the specified YAML files.

The kustomization.yaml file serves as a configuration file for Kustomize, a Kubernetes-native configuration management tool. It defines how Kubernetes manifests in that directory should be aggregated, customized, or patched before being applied to your cluster.

In a GitOps setup, such as with FluxCD, this file helps manage and deploy the application's resources by describing how the various Kubernetes YAML files in the my-app directory (like frontend-deployment.yaml, frontend-service.yaml, etc.) should be combined and customized.

# kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - frontend-deployment.yaml
  - frontend-service.yaml
  - backend-deployment.yaml
  - backend-service.yaml

2. Link the Application Directory to FluxCD
   In the clusters/my-cluster/flux-system/kustomization.yaml file (already created from the bootstrap process), add a reference to your application's kustomization.yaml file. This tells FluxCD to apply the resources defined in apps/my-app. Edit the clusters/my-cluster/flux-system/kustomization.yaml file and add the path to your application directory.

cd $HOME/my-flux-repo/clusters/my-cluster/flux-system

# kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - gotk-components.yaml
  - gotk-sync.yaml
  - ../../../apps/my-app/ # add this line

What Happens When FluxCD Reconciles It?

1. FluxCD Detects Changes:

   • If you make a change in the Git repository (e.g., update kustomization.yaml or a resource file), FluxCD detects the change.

2. FluxCD Applies the Kustomization:

   • FluxCD reads the kustomization.yaml file in the apps/my-app directory.

   • It processes the listed resources, applies the customizations (e.g., patches, labels), and reconciles the desired state with the cluster.

3. Resources Are Deployed:

   • The aggregated and customized manifests are applied to the cluster, ensuring the application is deployed in the desired configuration.

Commit and Push Changes

After updating the kustomization.yaml, commit and push the changes to your Git repository.

cd $HOME/my-flux-repo

git config --global user.email "you@example.com"

git config --global user.name "Your Name"

git add .; git commit -m "add my-app to cluster configuration"; git push origin main

NOTE: When prompted for your GitHub password, paste in your GitHub PAT (the one we generated at the beginning).

Verify FluxCD Reconciliation

Wait for FluxCD to reconcile the changes or manually trigger it. Check the logs for updates:

• Trigger Reconciliation:

    flux reconcile kustomization flux-system -n flux-system
  

• Check Logs:

    kubectl logs -n flux-system deploy/kustomize-controller
  

• Check Kustomization Status:

    flux get kustomizations -n flux-system
  

• Check that the app was created:

    kubectl get all
  

Summary

In this guide, we walked through the end-to-end process of setting up a GitOps workflow using FluxCD, from bootstrapping a Flux-enabled cluster to deploying a sample microservices application. Along the way, you learned how FluxCD simplifies the continuous delivery process through reconciliation, Git-based change tracking, and modular infrastructure design.

Key Takeaways

• Git as the Source of Truth: With FluxCD, your Git repository drives all changes in your Kubernetes cluster, ensuring consistency and auditability.

• Modular Design: You can organize your manifests using Kustomize, separating base configurations from overlays and manage multiple environments efficiently.

• Declarative Deployment: All resources, from Deployments to Services, are declaratively described, version-controlled, and automatically applied via FluxCD.

• End-to-End Automation: FluxCD monitors changes in Git and continuously reconciles your desired state with the actual state of your cluster, eliminating manual drift correction.

• Hands-On Value: By deploying a working microservices application using Node.js and Flask, you’ve applied GitOps principles in a real-world scenario.

While GitOps can initially seem overwhelming, especially with the many moving parts of Kubernetes, CI/CD pipelines, and declarative tooling, FluxCD makes it approachable, scalable, and production-ready. The hands-on walkthrough you completed today is just the beginning.

Whether you’re just getting started or expanding GitOps across multiple environments, FluxCD provides a robust and secure foundation to manage your workloads the GitOps way.

If this guide helped demystify FluxCD, share it with your team or community! And if you’re ready for more advanced topics, like multi-tenancy, pull-based secrets management, and progressive delivery, stay tuned for our next post!

1. Understand the Basics Before Diving Deep

Kubernetes operates on foundational concepts, and mastering these basics sets the stage for your learning journey:

• Containers: Understand how containers work and why they revolutionized software delivery. Tools like Docker are excellent starting points to grasp the concept of lightweight, isolated environments that package your applications and their dependencies.

• Networking, Storage, and Virtualization Basics: Kubernetes abstracts these components, but knowing their principles ensures you aren't lost when troubleshooting or scaling your clusters. Learn how containers communicate (networking), persist data (storage), and run across virtualized environments.

• YAML Files: Kubernetes configurations are declared in YAML. Start with simple files to define a Pod or Service, then progress to more complex ones like Deployments. Practicing with YAML will also enhance your understanding of Kubernetes resources and their relationships.

2. Start with practical tools

The hands-on approach is the fastest way to learn Kubernetes. Instead of diving headfirst into production, experiment in controlled environments:

• Killercoda: Perfect for browser-based, guided Kubernetes scenarios. It eliminates the setup overhead so you can focus on learning. Minikube or Kind: These tools allow you to run Kubernetes clusters locally.

• Minikube is beginner-friendly, while Kind (Kubernetes IN Docker) is lightweight and great for testing CI/CD pipelines. Both provide safe sandboxes to experiment with Kubernetes concepts.

3. Focus on core Kubernetes components

Mastering Kubernetes means understanding its building blocks. Start with these essential components:

• Pods: The smallest deployable units in Kubernetes, containing your application containers. Learn their lifecycle and management.

• Services: Abstracts access to Pods, enabling communication and load balancing. Dive into ClusterIP, NodePort, and LoadBalancer types.

• ConfigMaps and Secrets: Understand how to decouple your configuration data from application code while managing sensitive information securely.

• Deployments: Learn how they automate the management of Pods, handle scaling, and facilitate rolling updates with zero downtime.

4. Automate early with GitOps

GitOps isn't just a buzzword; it's a game-changer for Kubernetes management: Tools like ArgoCD and Flux integrate version control with your Kubernetes cluster, turning your Git repository into a single source of truth. Start small by deploying simple workloads using GitOps workflows. As you progress, leverage automation to handle scaling, monitoring, and application updates seamlessly.

5. Explore diverse environments

Kubernetes behaves differently across platforms, and gaining exposure to various environments helps build well-rounded expertise:

• Local Environments: Tools like Minikube and Kind let you experiment without cost.

• Cloud Platforms: Explore managed Kubernetes services like AWS EKS, Azure AKS, Google GKE, or Civo. They abstract the infrastructure, allowing you to focus on applications.

• On-Premises: Try lightweight distributions like k3s or orchestration tools like Rancher to simulate edge or hybrid environments.

6. Leverage modern kubernetes tools

Simplify and enhance your Kubernetes experience with modern tools:

• Helm: Package and deploy applications easily using Helm charts.

• Kustomize: Customize Kubernetes configurations without duplication. It's particularly handy when managing multiple environments.

• OpenTelemetry: Implement observability to trace, monitor, and debug your applications seamlessly across your Kubernetes clusters.

7. Engage with the kubernetes community

The Kubernetes ecosystem thrives on collaboration. Joining the community accelerates learning and provides invaluable networking opportunities:

• Meetups and Events: Participate in local Kubernetes groups, KubeCon, or Kubernetes Community Days (KCDs) to learn from and connect with experts.

• CNCF Slack: Join channels dedicated to Kubernetes discussions for real-time support and insights.

• Open-Source Contributions: Start small, like fixing documentation or testing features. Contributing not only deepens your knowledge but also connects you to experienced practitioners.

8. Get Certified to validate your skills

Certifications provide structured learning and validate your Kubernetes expertise: Start with the KCNA (Kubernetes and Cloud Native Associate) for foundational knowledge. Progress to role-specific certifications like CKAD (Certified Kubernetes Application Developer) or CKA (Certified Kubernetes Administrator) to solidify your skills.

9. Prioritize security from the start

Security is a critical aspect of Kubernetes. Adopt secure practices early:

• NetworkPolicies: Restrict traffic between Pods and external services to prevent unauthorized access.

• Trivy: Scan container images for vulnerabilities before deploying them.

• RBAC (Role-Based Access Control): Implement granular permissions to control who can perform specific actions within your cluster.

10. Learn at your own pace

Kubernetes is a vast and constantly evolving ecosystem. It's easy to feel overwhelmed, but the key is consistency:

• Set achievable goals for daily or weekly learning. Embrace new features and trends as they emerge in the ecosystem.

• Remember, it's not about mastering Kubernetes overnight—it's about building a strong foundation and growing from there.

Call to Action

Ready to begin your Kubernetes journey? Start today by picking one tip and taking that first step. Whether it's setting up your first cluster, experimenting with tools like Helm, or exploring Kubernetes concepts, every action moves you closer to mastery. Share your progress or questions in the comments below—we'd love to hear from you! Don't forget to connect with the broader Kubernetes community and join us at KubeSkills.com. Together, we'll navigate the exciting world of Kubernetes and unlock the full potential of cloud native technology.

As we head into 2025, I want to share some key takeaways and actionable advice to help you refine your skills and stay ahead of the curve, positioning yourself for even greater success in the cloud-native world.

1️⃣ Kubernetes Is Maturing, But Simplification Is Key

While Kubernetes adoption continues to soar, the focus is shifting toward making the platform more user-friendly. Tools like KubeFlow, Lens, and the Gateway API are evolving to abstract away complexity and enhance developer productivity.

Key takeaway for learners: Start with the basics of Kubernetes, but also explore tools that simplify management to stay ahead in the ecosystem.

Recorded talks from KubeCon that focused on this:

• Gateway API: What's new, What's Next

• Tutorial: Live with Gateway API V1.2

• One Gateway API to Rule Them All

• Inspektor Gadget: eBPF for Observability, Made Easy and Approachable

2️⃣ Security Is Everyone’s Responsibility

The conference emphasized the importance of security, with several sessions dedicated to securing clusters, managing workloads, and protecting data. Tools like Falco, Kyverno, and Open Policy Agent (OPA) are becoming standard.

Key takeaway for learners: Begin integrating security into your workflows early, and don’t wait until you’re deploying in production to start thinking about it.

Recorded talks from KubeCon that focused on this:

• Keynote: Open Source Security Is Not A Spectator Sport

• Falco: Evolution of Real Time Cloud Security with Falco

• Kyverno: Level Up Your Cluster - 5 Kyverno Policies You Need Now!

• Working Together to Improve Security Visibility in Kubernetes

• Open Policy Agent (OPA) Intro, Deep Dive & V1.0 Update

• Why Perfect Compliance Is the Enemy of Good Kubernetes Security

3️⃣ Multi-Cloud and Hybrid Cloud Are the Future

Organizations are embracing multi-cloud setups, and Kubernetes is a critical enabler of this strategy. Projects like Submariner and service meshes are making it easier to manage workloads across diverse environments.

Key takeaway for learners: Understanding how Kubernetes fits into multi-cloud and hybrid cloud setups will make you a valuable asset to your team.

Recorded talks from KubeCon that focused on this:

• Meshery: Visualizing Kubernetes Resource Relationships with Meshery

• Mish-Mesh: Abusing the Service Mesh to Compromise Kubernetes Environments

• Linkerd Update: Ingress, Egress, IPv6, Enhanced Multicluster, Rust, and More

• Istio: Why Choose Istio in 2025

4️⃣ AI/ML Meets Kubernetes

There’s growing interest in deploying AI and ML workloads on Kubernetes. Projects like Kubeflow and WasmEdge are helping bridge the gap between data science and scalable infrastructure.

Key takeaway for learners: Kubernetes is becoming a must-have skill for data engineers and AI practitioners. Learn how it supports these specialized workloads.

Recorded talks from KubeCon that focused on this:

• Building Massive-Scale Generative AI Services with Kubernetes and Open Source

• Democratizing AI Model Training on Kubernetes with KubeFlow

• WasmEdge: Cross-Platform, High-Performance, Lightweight, Embeddable Multi-Modal LLM Runtime

• WasmCloud: Declarative WebAssembly Orchestration for Cloud Native Applications

• Reproducible AI with Kubeflow, lakeFS and Langchain

5️⃣ Community and Certifications Matter

Networking with other professionals confirmed how valuable certifications like the Certified Kubernetes Administrator (CKA) and Certified Kubernetes Application Developer (CKAD) are for career advancement (see exam discounts here). The conference also highlighted how the Kubernetes community supports continuous learning through meetups, forums, and open-source projects.

Key takeaway for learners: Engaging with the Kubernetes community and earning certifications can accelerate your journey.

Recorded talks from KubeCon that focused on this:

• Keynote: Awards Ceremony

• Keynote: Four Cloud Native Technology Areas to Watch For

• Keynote: A Decade of Kubernetes and Cloud Native – Are We There Yet?

• Open Source 2.0: The Maintainers' Perspective

At KubeSkills, we’re committed to helping you navigate these trends and build expertise in Kubernetes and containers. Stay tuned for upcoming courses, live workshops, and community events tailored to these evolving needs.

Civo is a cloud computing platform that provides fast and easy-to-use Kubernetes services. Its main offering, Civo Kubernetes, uses K3s, a lightweight and optimized version of Kubernetes developed by Rancher Labs. K3s is ideal for small to medium-sized cloud applications and environments. Civo allows developers to set up a functional Kubernetes cluster in under 90 seconds, making it perfect for those just starting.

Why Use Civo?

1. Speed and Simplicity: For beginners, Civo provides a quick way to create a Kubernetes cluster, allowing you to start experimenting without getting bogged down in complicated configurations.

2. Utilizing K3s: Civo runs on K3s, which consumes fewer resources than a standard Kubernetes installation. This makes it an excellent choice for projects that don't require the full capabilities of Kubernetes, ensuring you can deploy applications swiftly and efficiently.

3. User-Friendly Interface: Civo offers an intuitive web platform, CLI, and API, simplifying cluster deployment, management, and removal without requiring deep Kubernetes expertise.

4. Competitive Pricing: With affordable pricing and transparent billing, Civo is an attractive option for developers who want to leverage Kubernetes without incurring high costs associated with larger cloud providers.

5. Community and Support: Civo has an active community that shares resources and knowledge. Their support team is known for being responsive, helping you resolve issues while you learn Kubernetes.

6. Developer-Centric Approach: Designed with developers in mind, Civo provides features that enable rapid experimentation and development, making it easier for newcomers to grasp Kubernetes concepts.

Benefits of Using Civo:

• Rapid Cluster Creation: You can have a fully operational Kubernetes cluster up and running in less than 90 seconds, which is invaluable when you're eager to start learning and experimenting.

• Lightweight K3s: By leveraging K3s, your cluster will use fewer resources, reducing costs and optimizing infrastructure utilization.

• Ease of Use: Both the platform and CLI/API are designed to simplify the Kubernetes experience, making it accessible even for those who are not experts.

• Low Cost: As you familiarize yourself with Kubernetes, you won’t need to worry about high expenses, allowing for budget-friendly experimentation.

• Scalability: Although Civo is lightweight, it still supports Kubernetes, so you can scale your applications as needed, providing a balance between simplicity and growth potential.

Marketplace Features

One of Civo's standout features is its Marketplace, which allows you to add additional components to your Kubernetes cluster easily. This is especially beneficial for beginners who want to integrate popular tools without dealing with complex configurations.

• Easy Integration: The Marketplace offers a selection of preconfigured applications like Prometheus for monitoring, Grafana for visualization, Linkerd for service mesh management, and Traefik for ingress control. You can deploy these tools with just a few clicks.

• Optimized Deployments: The applications in the Marketplace are optimized to work seamlessly with K3s, ensuring a smooth integration process without compatibility issues.

• Quick Access: You can quickly implement essential tools in your cluster, enabling rapid experimentation and helping you focus more on application development rather than installation procedures.

• Learning Opportunities: The Marketplace allows you to explore commonly used tools in the Kubernetes ecosystem without needing to install them manually, which is helpful as you learn how to utilize these tools effectively.

Personal Experience

Having taught Kubernetes to many developers and tested various cloud providers, I can confidently say that very few have impressed me, except Google Kubernetes Engine (GKE). However, after trying Civo, it has quickly become one of my top two choices alongside GKE. Civo stands out for its simplicity, comprehensive documentation, and its contribution to the cloud-native landscape, making it an excellent option for developers looking to learn and grow with Kubernetes.

Conclusion

In summary, Civo is an ideal choice for developers new to Kubernetes. It enables rapid and straightforward deployment of Kubernetes clusters using K3s, offers an easy-to-use interface, and provides quick access to essential tools through its Marketplace. With competitive pricing and strong community support, Civo makes it easy to dive into the world of Kubernetes, allowing you to focus on building and deploying applications without the hassle of complex configurations. Its place in my top two alongside GKE speaks volumes about its value for developers seeking a cloud-native solution.

To see for yourself, you can now get $250.00 of free credit when you sign up at https://civo.com

What is Privileged Mode?

Running a pod in privileged mode means giving the container elevated permissions that allow it to perform operations that would normally be restricted. In essence, a privileged container has almost the same level of access to the host as root. This can be dangerous because it opens up the possibility of the container escaping its isolation, leading to potential control over the host system.

Why is Running Privileged Pods a Bad Idea?

1. Increased Attack Surface: Privileged containers can interact with the host’s kernel, modify system files, and access sensitive data. If a container running in privileged mode is compromised, the attacker could gain control over the host machine.

2. Escalation of Privileges: Privileged containers can bypass many security restrictions, leading to an escalation of privileges. This could allow an attacker to move laterally within your infrastructure, causing widespread damage.

3. Breakdown of Isolation: Kubernetes relies on the isolation between containers to maintain security. Running containers in privileged mode undermines this isolation, potentially allowing one compromised container to affect others.

4. Violation of Least Privilege Principle: One of the fundamental principles of security is the principle of least privilege. Privileged containers violate this principle by granting more permissions than are necessary for the container to perform its intended function.

Basic Example: Avoiding Privileged Mode

Let’s look at an example of how to define a pod without using privileged mode.

apiVersion: v1
kind: Pod
metadata:
  name: non-privileged-pod
spec:
  containers:
  - name: app-container
    image: nginx
    securityContext:
      privileged: false

In this example, the securityContext specifies that the container should not run in privileged mode (privileged: false). This is the default behavior in Kubernetes, but it's important to explicitly set this to ensure that no containers inadvertently run with elevated permissions.

Best Practices:

• Use Security Context: Always define a securityContext for your pods and containers to explicitly state that they should not run in privileged mode.

• Audit Your Cluster: Regularly audit your Kubernetes cluster to identify any pods that are running in privileged mode. This can help you catch misconfigurations before they lead to a security incident.

• Implement Pod Security Admission: It is a feature introduced in Kubernetes to enforce clear and consistent isolation levels for Pods. It builds upon the Kubernetes Pod Security Standards, guidelines that govern how Pods behave and interact with other resources.

• Educate Your Team: Ensure that everyone involved in deploying applications to your Kubernetes cluster understands the risks associated with privileged containers and how to avoid them.

By avoiding privileged mode, you can significantly reduce the risk of container escapes and other security breaches in your Kubernetes environment. Always prioritize security and follow best practices to keep your applications and infrastructure safe.

In this article, we're doing just that, using the 80/20 rule. Applying the Pareto Principle (the 80/20 rule) to learning a new subject like Kubernetes means focusing on the 20% of concepts and skills that will provide you with 80% of the value or understanding. Instead of trying to master every detail from the start, you concentrate on the core areas—like container orchestration, deploying applications, and basic networking—that will allow you to be productive and effective quickly. Once you’ve grasped these fundamentals, you can gradually explore more advanced topics as needed. This approach helps you learn efficiently, avoid being overwhelmed, and quickly gain practical knowledge.

Here’s how you can do it

1. Identify Key Concepts and Components:

• Focus on 20% of the foundational Kubernetes concepts, giving you a solid understanding of the system. This includes understanding pods, nodes, clusters, namespaces, services, and the Kubernetes control plane. Scroll down to the next section to dive into the 20%.

2. Leverage Top Resources:

• Utilize the most authoritative and comprehensive resources covering essential information. See this list of The Best Kubernetes Books of All Time.

3. Focus on High-Impact Tools and Practices:

• Learn and practice the tools and workflows widely adopted in the Kubernetes ecosystem and contribute to most practical use cases, such as Helm for package management and Prometheus for monitoring. See the paragraphs below for getting started with these tools.

4. Engage with the Community:

• Participate in community events, forums, and meetups where you can interact with experts and peers. Platforms like the Kubernetes Slack channel, CNCF events, or local Kubernetes meetups (like KCD Texas and the Austin Kubernetes meetup) can provide concentrated and valuable insights.

• Watch this video about Kaslin's experience in the Kubernetes community:

Key Concepts and Components

1. Kubernetes Architecture

• Nodes and Clusters: To understand the basic building blocks, one must consider the roles of a control plane node and a worker node. The control plane is a critical component in Kubernetes because it maintains all the parts of the Kubernetes system. You can authenticate to the Kubernetes RESTful API. Often, Kubernetes administrators use a kubeconfig with the kubectl command line to interact with their cluster and perform create, read, update, and delete (CRUD) operations on the API. Worker nodes run workloads running inside of pods. Also, additional components that run both on the control plan and worker node are kube-proxy, the CNI, kubelet, and a container runtime like containerd. The kubelet usually runs as a daemon on the Linux host. It communicates with the Kubernetes API server to receive instructions and report the status of the node and the workloads running on it. The kube-proxy component handles network communication for services, including forwarding traffic to the correct Pods, load balancing, and implementing network policies. The container runtime pulls container images, starts and stops containers, and manages container storage and networking. The Container Networking Interface (CNI) is a plugin in Kubernetes that allows pod-to-pod communication across nodes.

• 

  Control Plane Components: Includes etcd (for cluster state), API Server, Controller Manager, and Scheduler. These all run as pods in the Kubernetes cluster in a namespace named kube-system (Different namespaces can be used to separate environments such as development, staging, and production). The API server is the front end for the Kubernetes control plane. It exposes the Kubernetes API and serves as the hub for communication between other components. The etcd datastore is a consistent and highly available key-value store used as Kubernetes’ backing store for all cluster data. Every state change and configuration in the cluster is stored in etcd. The scheduler assigns workloads (pods) to specific nodes in the cluster based on resource availability, policy constraints, and affinity specifications. The controller manager runs the controllers and regulates the system's state. The controllers include the Node Controller, Replication Controller, and Service Account Controller.

  

2. Pods

• A pod is the smallest deployable unit in Kubernetes and can contain one or more containers. Check out this FREE lab environment, where you can deploy a pod to a Kubernetes cluster (with step-by-step instructions). 😃

3. Services

• The Types of Services in Kubernetes are ClusterIP, NodePort, and LoadBalancer. A primary purpose of Services in Kubernetes is to avoid modifying your existing application to use an unfamiliar service discovery mechanism. You can run code in Pods, whether this is code designed for a cloud-native world or an older app you've containerized. Then, you use a service to make that set of pods available on the network so clients can interact with them.

4. Deployments

• A deployment is a higher-level abstraction that manages a group of identical Pods, ensuring they are running and up-to-date. Deployments provide declarative updates for Pods and ReplicaSets, enabling automated rollout and rollback of applications.

• Check out this FREE guided Kubernetes Lab to try it out for yourself!

5. ConfigMaps and Secrets

• ConfigMaps decouples configuration artifacts from image content to keep containerized applications portable. ConfigMaps allow you to store configuration data as key-value pairs that your application pods can consume.

• Secrets are objects that store and manage sensitive information, such as passwords, OAuth tokens, SSH keys, and other data you want to keep out of plain text in your configuration files. Secrets allow you to securely inject sensitive data into your application pods.

• Create configMaps and use then with pods in this FREE Kubernetes Lab environment!

6. Volumes and Persistent Storage

• In Kubernetes, volumes are used to manage and persist data for containers running in Pods. Unlike ephemeral container storage, which is lost when a container crashes, volumes allow data to be preserved, shared between containers within a Pod, and made persistent across Pod restarts. If you require to store data, you can use different types, such as emptyDir, hostPath, and Persistent Volumes (PVs).

• Persistent Volume Claims (PVCs) request storage resources defined by a Persistent Volume. PVCs provide an abstraction for requesting and using storage without knowing the underlying details. Get hands-on with PVs and PVCs in this FREE Kubernetes lab environment.

9. Ingress

• An Ingress is an API object that manages external access to services within a cluster, typically HTTP and HTTPS. Ingress can provide load balancing, SSL termination, and name-based virtual hosting, making it a powerful way to expose services to external users.

10. RBAC (Role-Based Access Control)

• Role-Based Access Control (RBAC) in Kubernetes regulates access to the Kubernetes API and resources within a cluster. RBAC allows administrators to define roles with specific permissions and then assign those roles to users or groups, ensuring that only authorized individuals can perform certain actions.

• A Role contains a set of permissions (rules) that apply within a specific namespace. It defines what actions can be performed on which resources. A RoleBinding grants the permissions defined in a Role to a user, group, or service account within a specific namespace.

14. Autoscaling

• A Horizontal Pod Autoscaler adjusts the number of Pods in a Deployment, Replica Set, or Stateful Set based on observed CPU utilization, memory usage, or other custom metrics.

• A Cluster Autoscaler scales the cluster size up or down by adding or removing nodes to match the resource requirements of the running Pods.

17. StatefulSets

• A StatefulSet is a controller that manages deploying and scaling a set of Pods and guarantees their ordering and uniqueness. StatefulSets are used for applications that require stable, unique network identifiers, persistent storage, and ordered deployment and scaling, like a database.

• Create and manage a statefulSet in this FREE Kubernetes lab environment!

18. DaemonSets

• a DaemonSet is a type of controller that ensures a copy of a specific Pod runs on each node in a cluster. DaemonSets are particularly useful for deploying system-level or cluster-wide services that need to run on every node, such as log collectors, monitoring agents, and network plugins

19. Jobs and CronJobs

• a Job is a controller that ensures a specified number of Pods successfully terminate. Jobs are used to run tasks that have a clear start and end, such as batch processing, data analysis, or one-time scripts. Once the tasks specified by the Job are completed successfully, the Job itself is considered complete

• a CronJob is a specialized type of Job that runs on a schedule. CronJobs perform tasks regularly, much like the cron utility in Unix-like operating systems. They are suitable for recurring tasks such as backups, report generation, and periodic maintenance.

20. Security

• Pod Security Standards (PSS) in Kubernetes are predefined security policies that outline best practices for running Pods securely. These standards help Pods adhere to specific security guidelines, reducing the risk of vulnerabilities and security breaches. The PSS are typically enforced using Pod Security Admission (PSA), an admission controller that applies these standards at the namespace level. Get hands-on with PSS in this FREE hands-on lab!

• Network Policies in Kubernetes are a way to define rules for controlling the traffic flow between Pods, and between Pods and external endpoints. They allow you to specify how Pods are allowed to communicate with each other and other network endpoints, enhancing security by isolating different parts of your applications and services. Create your first Network Policy in this FREE Kubernetes Lab!

Focusing on these areas will provide a solid foundation in Kubernetes and cover the core aspects you need to understand and effectively use the platform. For deeper learning, you can dive into each of these topics with detailed resources and hands-on practice.

High-Impact Tools and Practices: Helm

Learning and practicing with Helm can significantly enhance your understanding of Kubernetes by simplifying the management and deployment of applications. Helm is a package manager for Kubernetes that helps you define, install, and upgrade complex Kubernetes applications. Here’s a step-by-step guide to learning and practicing with Helm.

To understand the verbiage used in Helm, here are the three Helm Components:

1. Helm Client: The command-line tool used to interact with Helm.

2. Helm Chart: A package that contains all the necessary Kubernetes manifest files to deploy an application.

3. Release: An instance of a Helm chart running in a Kubernetes cluster.

Install Helm on your local machine:

• Helm Installation: Follow the official installation guide for Helm.

• Helm Installation Guide

Example for installing Helm on macOS using Homebrew:

brew install helm

Example for installing Helm on Linux:

curl -fsSL https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

Access a FREE Kubernetes Lab environment on Killercoda.com.

Familiarize yourself with basic Helm commands:

• helm search: Search for Helm charts.

• helm repo add: Add Helm chart repositories.

• helm install: Install a Helm chart.

• helm list: List installed Helm releases.

• helm upgrade: Upgrade an existing Helm release.

• helm uninstall: Uninstall a Helm release.

Example:

# Add the official stable repository
helm repo add stable https://charts.helm.sh/stable

# Update the repository
helm repo update

# Search for a chart
helm search repo stable

# Install a chart
helm install my-release stable/nginx

# List releases
helm list

# Upgrade a release
helm upgrade my-release stable/nginx

# Uninstall a release
helm uninstall my-release

Learn how to create your own Helm charts:

This command creates a directory structure for your chart, including default templates and values:

# create a new chart
helm create mychart

Understanding Chart Structure:

• Chart.yaml: Contains metadata about the chart (name, version, description).

• values.yaml: Default configuration values for the chart.

• templates/: Contains Kubernetes manifest templates.

Customize the Chart:

Modify the values.yaml and templates to suit your application’s needs.

Install the Chart:

helm install my-release ./mychart

Upgrade the Chart:

helm upgrade my-release ./mychart

Uninstall the Chart:

helm upgrade my-release ./mychart

Helm Community and Resources

Engage with the Helm community and utilize available resources:

• Helm Documentation: The official documentation provides comprehensive guides and references.

• Helm GitHub Repository: Explore the source code and contribute.

• Community Forums and Slack: Join discussions and seek help from the community.

High-Impact Tools and Practices: Prometheus

Learning and practicing with Prometheus in the context of Kubernetes is a great way to understand the fundamentals of monitoring and observability in cloud-native environments. Prometheus is widely used for monitoring and alerting in Kubernetes clusters and plays a key role in the Kubernetes ecosystem. Here’s a step-by-step guide to help you learn and practice with Prometheus to understand Kubernetes better.

Key components of Prometheus:

1. Prometheus Server: Responsible for scraping and storing metrics data.

2. Prometheus Query Language (PromQL): A flexible query language for querying metrics data.

3. Alertmanager: Manages alerts generated by Prometheus.

4. Exporters: Applications that expose metrics in a format that Prometheus can scrape (e.g., Node Exporter for hardware metrics).

Access Prometheus using the instructions in this FREE hand-on lab.

Once Prometheus is running, start exploring its features.

Run Basic PromQL Queries, like this one, to get the CPU usage percentage per node:

100 - (avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) by (instance) * 100)

This is the expected output from the above PromQL query:

Or this one, to monitor memory usage:

sum(node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) by (instance) / sum(node_memory_MemTotal_bytes) by (instance) * 100

This is the expected output from the above PromQL query:

Or this one to count the number of running pods

count(kube_pod_info)

This is the expected output from the above PromQL query:

Engage with the Prometheus Community

• Join the Prometheus Community: participate in discussions, ask questions, and learn from others in the community.

• Contribute to Prometheus: Explore the Prometheus GitHub repository and contribute to the project.

• Explore Prometheus Documentation: The official Prometheus documentation is an excellent resource for in-depth learning.

Summary

Now that you have the 20%, what’s next? Each topic we've touched on has countless avenues to explore further. I recommend joining a learning community where you can connect with others who share your passion for technology. At KubeSkills, we offer a friendly and supportive environment where you can dive deeper and continue your journey. If you found this guide helpful, share it on social media and use it as you see fit. We have more guides like this and more in the KubeSkills community, which you can join for FREE! Thank you for your time and attention if you've read this far.

I look forward to seeing you in the KubeSkills community soon! 😃

-Chad