DOCSEARCHbyAlgolia
Submit Docs

podinfo

repository·master·Indexed 27 days ago

https://github.com/stefanprodan/podinfo

A tiny Go-based web application designed to showcase Kubernetes best practices. Used by CNCF projects like Flux and Flagger for workshops and end-to-end testing, podinfo provides a demo environment including a webapp, simulated database components (primary and read replicas), and CronJobs for maintenance tasks. It supports deployment via Helm charts (available on GHCR and GitHub Pages), Kustomize overlays, and standard Kubernetes manifests.

Tokens
12.7K
Snippets
33
Records
52
Agent score
88%

What's inside podinfo

  1. Overview of Database Components

    master

    The database setup simulates a production-like environment with the following components:

    Core Resources

    • ServiceAccount: Shared service account (serviceaccount.yaml) for all database workloads.
    • Primary Database: A StatefulSet (statefulset-primary.yaml) with 1Gi persistent storage mounted at /data, accessible via a headless service (service-primary.yaml).
    • Read Replicas: A Deployment (deployment-replica.yaml) scaled by an HPA (hpa-replica.yaml) to 2-3 pods based on 99% CPU utilization. Replicas are accessed via a ClusterIP service (service-replica.yaml).
    • Storage: A PVC (pvc-primary.yaml) providing 1Gi of persistent storage for the primary database.

    CronJobs

    • rollup-daily: Simulates daily rollups (6 iterations).
    • rollup-weekly: Simulates weekly rollups (12 iterations).
    • backup-daily: Simulates a daily backup (configured to fail).

  2. Understand the Tracing & Logging Demo Architecture

    master

    The demo simulates a microservices environment where PodInfo components send telemetry to an OpenTelemetry Collector:

    • PodInfo Frontend (port 9898): Calls the backend and sends traces/logs to the collector.
    • PodInfo Backend (port 9899): Receives calls and sends traces/logs to the collector.
    • OpenTelemetry Collector (port 4317): Receives telemetry via OTLP gRPC and forwards it:
      • Traces $\rightarrow$ Jaeger (via OTLP gRPC on port 4317)
      • Logs $\rightarrow$ Loki (via OTLP HTTP on port 3100)

    Service Ports Summary:

    • PodInfo Frontend: 9898
    • PodInfo Backend: 9899
    • OTel Collector (gRPC): 4317
    • Jaeger UI: 16686
    • Loki: 3100
    • Grafana UI: 3000

  3. Run the Tracing & Logging Demo locally

    master

    This demo sets up a full observability stack using PodInfo, OpenTelemetry Collector, Jaeger, Loki, and Grafana via Docker Compose.

    To run the demo:

    1. Start the containers using make run.
    2. Generate sample traffic by sending requests to the PodInfo frontend using curl.
    3. Access the observability UIs (Jaeger and Grafana) in your browser.
    4. Stop the containers using make stop.

  5. Test podinfo locally using Kind

    master

    To test the application locally, you can use kind (Kubernetes in Docker). Running the provided script will create a new cluster named "podinfo" and configure host ports on 80 and 443, allowing you to access endpoints on localhost.

    This setup also automatically deploys cert-manager within the cluster and a self-signed cluster issuer to handle certificate generation for the secure port.

    ./kind.sh

  7. Verify Podinfo Chart with Cosign

    master

    To ensure the integrity and authenticity of the chart, you can verify a specific version using cosign. This command checks the signature against the GitHub Actions OIDC issuer and the expected identity pattern.

    $ cosign verify ghcr.io/stefanprodan/charts/podinfo:<VERSION> \
  --certificate-oidc-issuer=https://token.actions.githubusercontent.com \
  --certificate-identity-regexp="^https://github\.com/stefanprodan/.*$"

  9. Deploy the podinfo demo webapp

    master

    You can deploy the podinfo demo using standard Kubernetes manifests or via Kustomize overlays for specific environments.

    Using standard manifests (webapp namespace)

    Deploy the common, backend, and frontend components into the webapp namespace using kubectl apply:

    Using Kustomize overlays

    Deploy the demo into specific environments (dev, staging, or production) by building the Kustomize configuration and piping it to kubectl:

    • dev: ./overlays/dev
    • staging: ./overlays/staging
    • production: ./overlays/production
    # Deploy in webapp namespace
kubectl apply -f ./webapp/common
kubectl apply -f ./webapp/backend
kubectl apply -f ./webapp/frontend

# Deploy in dev namespace
kustomize build ./overlays/dev | kubectl apply -f-

# Deploy in staging namespace
kustomize build ./overlays/staging | kubectl apply -f-

# Deploy in production namespace
kustomize build ./overlays/production | kubectl apply -f-

  10. Configure Podinfo with custom values

    master

    You can override default settings by providing a CUE file containing a values object. For example, to set specific CPU and memory requests:

    Create my-values.cue:

    values: {
	resources: requests: {
		cpu:    "100m"
		memory: "128Mi"
	}
}

    Apply it using:

    timoni -n default apply podinfo oci://ghcr.io/stefanprodan/modules/podinfo --values ./my-values.cue

  11. Automate Podinfo deployments with Flux CD

    master

    To keep Podinfo up to date automatically using Flux CD, follow these steps:

    1. Install Flux CLI.
    2. Install Flux controllers.
    3. Create a Helm source for Podinfo with a 10-minute check interval.
    4. Define a podinfo-values.yaml for configuration.
    5. Create a HelmRelease to deploy the chart.

    Flux will automatically upgrade the release when a new version is released and can be configured to rollback on failure.

    # 1. Install Flux CLI
brew install fluxcd/tap/flux

# 2. Install Flux controllers
flux install \
--namespace=flux-system \
--network-policy=false \
--components=source-controller,helm-controller

# 3. Add Helm repository
flux create source helm podinfo \
--namespace=default \
--url=https://stefanprodan.github.io/podinfo \
--interval=10m

# 4. Create values file
cat > podinfo-values.yaml <<EOL
replicaCount: 2
resources:
  limits:
    memory: 256Mi
  requests:
    cpu: 100m
    memory: 64Mi
EOL

# 5. Create HelmRelease
flux create helmrelease podinfo \
--namespace=default \
--source=HelmRepository/podinfo \
--release-name=podinfo \
--chart=podinfo \
--chart-version=">5.0.0" \
--values=podinfo-values.yaml

# Check status
flux get helmreleases -n default

# Cleanup
flux -n default delete source helm podinfo
flux -n default delete helmrelease podinfo