update k8s local dev docs: namespace, Knative resource trimming

Update DEVELOPMENT_LOCAL.md to reflect constructive-functions namespace
and document both local-simple and Knative modes. Add Knative resource
trimming commands for CI/constrained environments (previously inline in
the CI workflow, now preserved as reference for future use).

Author: Anmol1696

k8s/DEVELOPMENT_LOCAL.md

@@ -1,131 +1,92 @@
-# Local Kubernetes Setup (No Ingress, With Knative)
+# Local Kubernetes Setup
 
-This document describes a local Kubernetes setup for the Constructive stack that:
+Two modes are available for local k8s development. Both use the `constructive-functions` namespace.
 
-- Runs on a local cluster (kind, minikube, k3d, etc.).
-- Uses a single Postgres Deployment (no CNPG operator).
-- Uses a single MinIO Deployment (no MinIO Tenant/Operator).
-- Keeps Knative + Kourier for jobs/functions.
-- Uses a single namespace: `interweb`.
-- Exposes everything via `kubectl port-forward` and localhost URLs.
-- Runs email functions in dry-run mode, so Mailgun secrets are optional.
+## Option A: Plain k8s (local-simple) — Recommended
 
-See the repository docs and manifests for the authoritative configuration.
+Uses plain Deployments + Services. No operators needed. This is the default for `make skaffold-dev` and CI.
 
-## Prerequisite: GHCR image pull secret
+See [DEVELOPMENT.md](../DEVELOPMENT.md#k8s-local-development-skaffold) for full setup instructions.
 
-The dashboard and database job images are hosted on GitHub Container Registry
-(`ghcr.io`). Before applying the local overlay, you must create the `ghcr-pull`
-image pull secret in the `interweb` namespace so the cluster can pull these
-images.
-
-1. Create a `k8s/.env` file (this file is gitignored) with your GHCR
-   credentials:
-
-   ```bash
-   # k8s/.env
-   GH_USERNAME=your-ghcr-username
-   GH_PAT_TOKEN=your-ghcr-read-packages-token
-   GH_EMAIL=you@example.com
-   ```
-
-2. Ensure your `kubectl` context points at your local cluster (kind, minikube,
-   k3d, etc.).
-
-3. From the `k8s` directory, create or update the `ghcr-pull` secret:
-
-   ```bash
-   cd k8s
-   make k8s-pull-secret
-   ```
+```bash
+make skaffold-dev    # builds, deploys, watches for changes
+```
 
-This will create a `ghcr-pull` `docker-registry` secret in the `interweb`
-namespace, which is referenced by the `dashboard` Deployment and the
-`constructive-db` Job.
+## Option B: Knative (local)
 
-## Step 1: Create a local Kubernetes cluster
+Uses Knative Serving + Kourier for functions (closer to production). Requires operator install.
 
-Setup with docker-desktop. Enable kubernetes on docker desktop
+### Step 1: Create a local cluster
 
-## Step 2: Install Knative (operators-knative-only)
+Docker Desktop (enable Kubernetes), kind, k3d, or minikube.
 
-The local setup keeps Knative + Kourier for jobs/functions but does **not**
-require ingress or CNPG. From the `k8s` directory:
+### Step 2: Install Knative
 
 ```bash
-cd k8s
+cd k8s/scripts/setup
 make operators-knative-only
 ```
 
-This will:
-
-- Install Knative Serving + Kourier.
-- Configure Knative to use an internal domain (`svc.cluster.local`) so Knative
-  services are reachable inside the cluster.
-
-For the “no ingress, single Postgres, single MinIO” local setup, the
-`operators-knative-only` target is sufficient.
+This installs Knative Serving + Kourier and configures an internal domain (`svc.cluster.local`).
 
-## Step 3: Apply the local overlay
-
-With your cluster and operators ready, apply the local Kustomize overlay:
+### Step 3: GHCR pull secret
 
 ```bash
-cd k8s
-
-# Apply the entire local stack (namespace, Postgres Deployment, MinIO,
-# Constructive server/admin/dashboard, pgAdmin, jobs, and functions)
-make kustomize-local
+kubectl create namespace constructive-functions --dry-run=client -o yaml | kubectl apply -f -
+kubectl create secret docker-registry ghcr-pull \
+  --docker-server=ghcr.io \
+  --docker-username=YOUR_USERNAME \
+  --docker-password=YOUR_GH_PAT_TOKEN \
+  --docker-email=your@email.com \
+  -n constructive-functions
+kubectl patch serviceaccount default -n constructive-functions \
+  -p '{"imagePullSecrets": [{"name": "ghcr-pull"}]}'
 ```
 
-You can inspect the rendered YAML without applying it by running:
+### Step 4: Deploy
 
 ```bash
-make render-local
+make skaffold-dev-knative
 ```
 
-## Step 4: Verify workloads
-
-Check that pods are starting in the `interweb` namespace:
+### Step 5: Verify
 
 ```bash
-kubectl get namespaces
-kubectl get pods -n interweb
-kubectl get svc -n interweb
+kubectl get pods -n constructive-functions
+kubectl get ksvc -n constructive-functions
 ```
 
-You should see at least:
-
-- `deployment/constructive-server`
-- `deployment/dashboard`
-- `deployment/knative-job-service`
-- `deployment/postgres`
-- `ksvc/simple-email`, `ksvc/send-email-link`
-
-## Step 5: Access services via port-forward
-
-The local setup does not use an Ingress; access is via `kubectl port-forward`.
-Convenience targets are provided in `k8s/Makefile`. From the `k8s` directory:
-
-```bash
-cd k8s
-
-# Constructive Server (API + GraphQL) -> http://localhost:8080
-make proxy-server
-
-# Explorer (GraphQL explorer UI) -> http://localhost:8081
-make proxy-explorer
-
-# Dashboard UI -> http://localhost:3000
-make proxy-web
-```
+## Knative Resource Trimming (CI / constrained environments)
 
-Run each of these in its own terminal (Ctrl+C to stop). You can also reach
-pgAdmin if desired:
+Knative's control-plane components request significant resources by default. On small clusters (kind in CI, minikube with low memory), you may need to shrink them:
 
 ```bash
-kubectl -n interweb port-forward svc/pgadmin 3001:80
+# Knative Serving control-plane
+kubectl -n knative-serving set resources deploy/activator \
+  --requests=cpu=50m,memory=80Mi --limits=cpu=200m,memory=256Mi
+kubectl -n knative-serving set resources deploy/autoscaler \
+  --requests=cpu=25m,memory=80Mi --limits=cpu=200m,memory=256Mi
+kubectl -n knative-serving set resources deploy/controller \
+  --requests=cpu=50m,memory=100Mi --limits=cpu=300m,memory=512Mi
+kubectl -n knative-serving set resources deploy/webhook \
+  --requests=cpu=25m,memory=80Mi --limits=cpu=200m,memory=256Mi
+kubectl -n knative-serving set resources deploy/net-kourier-controller \
+  --requests=cpu=25m,memory=80Mi --limits=cpu=200m,memory=256Mi
+
+# Kourier gateway
+kubectl -n kourier-system set resources deploy/3scale-kourier-gateway \
+  --requests=cpu=25m,memory=80Mi --limits=cpu=200m,memory=256Mi
+
+# CoreDNS (optional — scale to 1 replica)
+kubectl -n kube-system scale deploy/coredns --replicas=1
+kubectl -n kube-system set resources deploy/coredns \
+  --requests=cpu=50m,memory=70Mi --limits=cpu=200m,memory=170Mi
+
+# Restart pods so changes take effect
+kubectl -n knative-serving rollout restart deploy/activator deploy/autoscaler \
+  deploy/controller deploy/webhook deploy/net-kourier-controller
+kubectl -n kourier-system rollout restart deploy/3scale-kourier-gateway
+kubectl -n kube-system rollout restart deploy/coredns
 ```
 
-With these steps, you have a fully functional local Kubernetes environment for
-the Constructive stack using the `overlays/local` manifests.
+This is not needed for the `local-simple` profile (no Knative). The CI workflow currently uses `local-simple` via Skaffold, so Knative trimming is not applied. If CI switches back to the Knative-based `local` overlay in the future, add these commands after operator install.