Skip to main content
Hello, and welcome back. Before we run the kubectl commands to set up the SkyLine Air website, let’s review, at a high level, the services we’ll deploy and how the repository is organized. Services to be deployed
  • booking API
  • flight search service
  • payment processor
  • inventory service
  • analytics collector
Each service lives in its own subfolder and is deployed into its own Kubernetes namespace. Services expose one or more ports (via a Service resource) and interact to form a complete end-to-end microservice architecture for SkyLine Air. The goal is a realistic deployment so we can reason about networking, storage, rollouts, and operational responsibilities across multiple teams. Repository layout and where to look Below is a screenshot that shows the repository manifests layout and the Services table in the README (service names, namespaces, ports, and purposes are listed there).
A screenshot of a GitHub repository page (k8-finops-agent) showing the "manifests" folder and README content. The README displays a highlighted "Services" table listing service names, namespaces, ports and purposes.
Typical files in a service folder Inside the manifests (or services) directory you will find each service as a subfolder. A typical service folder (for example, booking-api) contains:
  • configmap.yaml — service configuration values
  • deployment.yaml — Deployment (or other workload) definitions for pods
  • ingress.yaml — Ingress rules for external routing
  • kustomization.yaml — local Kustomize overlay for that service
  • pvc.yaml — PersistentVolumeClaim if the service needs storage
  • service.yaml — Service resource exposing the pods
Quick reference table (logical mapping) Example: PersistentVolumeClaim Here is an example PersistentVolumeClaim manifest (from the payment processor service). It requests 5Gi of storage, includes labels, and is scoped to the payment namespace:
Notes on the PVC
  • accessModes: ReadWriteOnce — the volume can be mounted read-write by a single node at a time.
  • namespace — locates the PVC in the payment namespace so workloads there can bind it.
  • storageClassName omitted — the cluster’s default StorageClass will be used for dynamic provisioning if available.
  • Labels such as environment and owner improve resource organization and support automation, billing, or policy enforcement.
How we deploy these services This repository uses Kustomize overlays rather than Helm charts. Each service has a local kustomization.yaml and a top-level (core) kustomization.yaml aggregates the per-service overlays, so you can compose and apply all manifests together without templating. Top-level kustomization example
Apply the aggregated overlay (run from the directory that contains the top-level kustomization.yaml):
You can use Helm if you prefer parameterized charts, but using Kustomize keeps the setup simple and declarative. Kustomize overlays make it easy to inspect each service’s manifests and to reason about environment-specific customizations without templating.
Organizational model and ownership
  • Each microservice folder represents a logical team that owns that service (for example, the inventory team owns the inventory-service folder).
  • In larger organizations, you may have dozens or hundreds of service folders — each team manages manifests, CI/CD, image versions, and namespace-level responsibilities.
Next steps (practical checklist)
  1. Create the namespaces referenced in each service manifest (one namespace per service).
  2. Ensure cluster-level prerequisites are present:
    • A default StorageClass (or create the StorageClass your PVCs expect).
    • An ingress controller (e.g., NGINX, Traefik) and DNS pointing to it.
    • Any required RBAC, network policies, or cluster roles used by the services.
  3. Apply the top-level Kustomize overlay:
    • kubectl apply -k .
  4. Verify deployments and services:
    • kubectl get namespaces
    • kubectl get all -n <namespace>
    • kubectl describe pvc -n <namespace> for storage troubleshooting
Links and references That is it for this lesson — see you in the next one.

Watch Video