PrepZone Logo
PrepZone

ConfigMaps, Secrets, and Ingress Routing

Externalise config, inject secrets, and route HTTP traffic with Ingress.

Why this matters

  • This topic directly affects how reliably BookStore reaches production — configmaps and secrets externalise bookstore config; ingress terminates http for customers..
  • Interviewers connect hands-on commands and manifests to real delivery stories, not buzzwords.
  • Later modules assume you can explain both the why and the concrete file or command involved.
  • Platform maturity shows up when teams automate this instead of relying on tribal knowledge.
InternetHTTPS request
IngressTLS + routing rules
ServiceClusterIP / LB
Podbookstore-api
Podbookstore-api
Ingress routes external HTTP to a Service, which load-balances across healthy Pods.

Externalised config

Non-secret vs Secret: BookStore engineers treat this as part of the standard path from laptop to configmaps secrets ingress readiness. Document decisions in the team runbook so on-call knows which knobs exist.

Key ideas

  • Externalised config — primary idea for configmaps-secrets-ingress
  • BookStore context — catalog API, checkout, and inventory services share the same pattern
  • Automation — prefer pipeline jobs over manual SSH steps
  • Verification — staging must prove the change before prod traffic

Ingress routing

Host-based HTTP: When staging matches production architecture, BookStore catches misconfigurations early. Pair this section's practice with observability dashboards to confirm behavior under load.

Key ideas

  • Ingress routing — operational detail
  • Rollback — know how to revert without rebuilding artefacts
  • Security — least privilege for deploy roles
  • Documentation — link runbooks from the service README

Production checklist

Before promoting BookStore changes tied to this topic, run automated tests, inspect artefact immutability (image digest or JAR checksum), execute a staging smoke test on /actuator/health, and watch error-rate dashboards for thirty minutes after prod rollout.

Key ideas

  • Staging soak — validate under synthetic load
  • Change ticket — attach pipeline URL and artefact digest
  • On-call — page owner stays on dashboards during rollout
  • Post-deploy — record metrics baseline for comparison
Java
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: bookstore
spec:
  rules:
    - host: api.bookstore.example
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: bookstore-api
                port:
                  number: 80

Quick recall

Everything you need if you only revisit this box.

  • BookStore uses configmaps secrets ingress as a standard delivery practice.
  • Prefer automation and versioned config over manual server changes.
  • Staging proves changes before customer-facing promotion.
  • Observability confirms success — do not rely on silence alone.
  • Rollback plans must be tested, not invented during an outage.
  • Security and least privilege apply to every pipeline and cluster role.

Test yourself

Answer these before moving on — recall is what makes it stick.