> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Overview of SkyLine Air Technical Architecture Part 2

> Describes deploying SkyLine Air microservices on Kubernetes including repository layout, per-service manifests, namespaces, PVCs, and using Kustomize overlays with deployment and operational checklist.

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.](https://mintcdn.com/kodekloud-c4ac6d9a/rjGeTDj8cr6D5YbW/images/Building-Kubernetes-FinOps-AI-Agent/Setting-Up-SkyLine-Air-Kubernetes-Services/Overview-of-SkyLine-Air-Technical-Architecture-Part-2/k8-finops-agent-manifests-services-table.jpg?fit=max\&auto=format\&n=rjGeTDj8cr6D5YbW\&q=85\&s=d4381fb7c64e33eff7bb7d96ec2ffa25)

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)

| Service | Typical Namespace | Purpose |
| - | - | - |
| booking API | `booking` | Handle reservation creation and management |
| flight search | `flight-search` | Search and availability queries |
| payment processor | `payment` | Payment processing and logs |
| inventory service | `inventory` | Seat/inventory state and updates |
| analytics collector | `analytics` | Collect and forward telemetry/events |

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:

```yaml theme={null}
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: payment-logs
  namespace: payment
  labels:
    environment: prod
    owner: payments-team
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
```

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

```yaml theme={null}
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - flight-search-service
  - booking-api
  - payment-processor
  - inventory-service
  - analytics-service
  - problem-resources
```

Apply the aggregated overlay (run from the directory that contains the top-level `kustomization.yaml`):

```bash theme={null}
kubectl apply -k .
```

You can use [Helm](https://learn.kodekloud.com/user/courses/helm-for-beginners) 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

* [Kustomize overview and docs](https://learn.kodekloud.com/user/courses/kustomize)
* [Helm fundamentals](https://learn.kodekloud.com/user/courses/helm-for-beginners)
* [Kubernetes documentation](https://kubernetes.io/docs/)

That is it for this lesson — see you in the next one.

> **[Watch Video](https://learn.kodekloud.com/user/courses/building-kubernetes-finops-ai-agent/module/bd335eac-9e8a-4dc2-963b-1db50f6971f9/lesson/31de0e5c-ccc8-4a15-9ed2-df4d6d3f89be)**


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.