Add Hybrid Mesh Platform sandbox pattern documentation.

Introduces hub-spoke multi-cluster GitOps docs with architecture diagrams,
getting started, observability, and Industrial Edge extension pages.

Co-authored-by: Cursor <cursoragent@cursor.com>

Author: maximilianoPizarro

.wordlist.txt

@@ -516,6 +516,7 @@ kafkatopic
 kafkatopics
 kam
 kamelet
+kaoto
 kasten
 kastendr
 kata
@@ -548,6 +549,8 @@ kubelet
 kubeletconfig
 kubernetes
 kubevirt
+kserve
+kuadrant
 kust
 kustomization
 kustomize
@@ -587,6 +590,7 @@ machineconfigs
 machineset
 macos
 macosx
+mailpit
 mailto
 maistra
 makefile
@@ -911,6 +915,7 @@ sigstore
 siteadmin
 skipdryrunonmissingresource
 skopeo
+skupper
 sla
 slas
 sme
@@ -1113,6 +1118,7 @@ yml
 yourcluster
 ypuzljq
 zefrgjryxxxxxxxxx
+ztunnel
 zh
 zj
 zja

content/patterns/hybrid-mesh-platform/_index.md

@@ -0,0 +1,98 @@
+---
+title: Hybrid Mesh Platform
+date: 2026-05-20
+tier: sandbox
+summary: Multi-cluster GitOps platform using a hub-spoke topology with ACM, OpenShift Service Mesh, ACS, and Industrial Edge workloads on OpenShift 4.20.
+rh_products:
+  - Red Hat OpenShift Container Platform
+  - Red Hat Advanced Cluster Management
+  - Red Hat OpenShift GitOps
+  - Red Hat Advanced Cluster Security for Kubernetes
+  - Red Hat OpenShift Service Mesh
+  - Red Hat Connectivity Link
+  - Red Hat OpenShift AI
+  - Red Hat AMQ Streams
+  - Red Hat build of Apache Camel
+  - Red Hat OpenShift Pipelines
+  - Red Hat Developer Hub
+  - Red Hat Service Interconnect
+industries:
+  - General
+  - Industrial
+aliases: /hybrid-mesh-platform/
+links:
+  github: https://github.com/maximilianopizarro/platform-hub-spoke-config
+  install: getting-started
+  bugs: https://github.com/maximilianopizarro/platform-hub-spoke-config/issues
+  feedback: https://docs.google.com/forms/d/e/1FAIpQLScI76b6tD1WyPu2-d_9CCVDr3Fu5jYERthqLKJDUGwqBg7Vcg/viewform
+contributor:
+  name: Maximiliano Pizarro
+  contact: mailto:maximilianopizarro5@gmail.com
+  git: https://github.com/maximilianoPizarro
+---
+
+# Hybrid Mesh Platform
+
+**Maintainer:** Maximiliano Pizarro, Specialist Solution Architect at Red Hat
+
+This platform deploys in one `helm upgrade`, connects three OpenShift clusters (hub + east + west), and shows IoT sensor data across Grafana and Developer Hub within about 30 minutes. The pages below follow one continuous story — concept, install, operate, scaffold — so you can read straight through or jump to any chapter.
+
+Multi-cluster GitOps platform using Red Hat products — a hub-spoke topology that centralizes governance with Red Hat Advanced Cluster Management (ACM), delivers [Industrial Edge](/patterns/industrial-edge/) workloads on regional spokes, uses OpenShift Service Mesh in ambient mode for east-west connectivity, layers Connectivity Link (Kuadrant) for API-aware ingress policy, exposes Grafana dashboards for cross-cluster visibility, and integrates Advanced Cluster Security (ACS) for vulnerability and runtime protection.
+
+**Supported on:** Red Hat OpenShift Container Platform 4.20 (and 4.14 or newer per cluster).
+
+Read **concept → mechanics → operations**: start with [Architecture](architecture), install via [Getting Started](getting-started), scaffold workloads via [Scaffolding](scaffolding), then use platform chapters (Hub Gateway, Observability, Industrial Edge) before drilling into the pattern repository.
+
+## Overview
+
+This repository models a **GitOps-first platform** where:
+
+- **Hub cluster** runs ACM, OpenShift GitOps (Argo CD), observability aggregation, Developer Hub, ACS Central, Mailpit for notifications, and gateway-style HTTP routing with circuit breaking for shared services.
+- **Spoke clusters** (east/west regions) host **Industrial Edge** workloads: sensor and MQTT-style ingestion, Kafka pipelines, optional ML scoring, and dashboards fed by Prometheus-compatible metrics.
+- **Service Mesh 3 ambient** reduces sidecar overhead while retaining ztunnel-based L4 and waypoint-based L7 policy where needed.
+- **Hub Gateway** splits traffic into front and API services per spoke, with per-service **circuit breaking** via `DestinationRule`.
+- **Service Interconnect (Skupper)** bridges spoke services and metrics to the hub via a Virtual Application Network, without VPN or firewall changes.
+- **Spoke Gateways** aggregate Industrial Edge services per spoke for simplified cross-cluster exposure.
+- **Kiali + OSSM Console** provides service mesh topology visualization on every cluster via the OpenShift Console plugin.
+- **Grafana dashboards** roll up cluster and application signals from all clusters.
+- **ACS** provides centralized policy, CVE visibility, and SecuredCluster agents on spokes.
+
+[![Platform hub-spoke overview](/images/hybrid-mesh-platform/arch-overview.png)](/images/hybrid-mesh-platform/arch-overview.png)
+
+_Hub cluster aggregates observability and Developer Hub; east and west spokes run Industrial Edge workloads connected via Service Interconnect (Skupper)._
+
+## Quick links
+
+| Topic | Page |
+| --- | --- |
+| Architecture deep dive | [Architecture](architecture) |
+| Install flow | [Getting Started](getting-started) |
+| Hub Gateway | [Hub Gateway](hub-gateway) |
+| Observability | [Observability](observability) |
+| Industrial Edge (multi-cluster) | [Industrial Edge](industrial-edge) |
+| Scaffolding | [Scaffolding](scaffolding) |
+| Customization | [Ideas for customization](ideas-for-customization) |
+
+## Recommended reading order
+
+1. [Architecture](architecture) — mental model of hub, spokes, GitOps, and observability
+2. [Getting Started](getting-started) — bring clusters under GitOps
+3. [Scaffolding](scaffolding) — deploy Industrial Edge instances on east/west from Developer Hub
+4. [Hub Gateway](hub-gateway) — weighted ingress and circuit breaking across spokes
+5. [Observability](observability) — Grafana, Kiali, Kafka Console
+6. [Industrial Edge](industrial-edge) — factory data pipeline on multiple spokes
+
+## Red Hat products used
+
+- Red Hat OpenShift Container Platform
+- Red Hat Advanced Cluster Management for Kubernetes
+- Red Hat OpenShift GitOps (Argo CD)
+- Red Hat Advanced Cluster Security for Kubernetes
+- Red Hat OpenShift Service Mesh
+- Red Hat Connectivity Link (Kuadrant, Gateway API)
+- Red Hat OpenShift AI
+- Red Hat AMQ Streams (Apache Kafka)
+- Red Hat build of Apache Camel / Camel K
+- Red Hat OpenShift Pipelines (Tekton)
+- Red Hat Developer Hub (Backstage)
+- Red Hat Service Interconnect (Skupper)

content/patterns/hybrid-mesh-platform/architecture.md

@@ -0,0 +1,108 @@
+---
+title: Architecture
+weight: 20
+aliases: /hybrid-mesh-platform/architecture/
+---
+
+# Architecture
+
+## Hub-spoke theory in multi-cluster Kubernetes
+
+In multi-cluster Kubernetes, a hub-spoke model designates one administrative cluster (the hub) and one or more workload clusters (spokes). The hub owns fleet APIs: cluster inventory, policy placement, credentials for spoke registration, and often centralized GitOps controllers that fan out desired state.
+
+Spokes remain the execution venues for application namespaces, data-plane components (Kafka, MQTT bridges, mesh dataplane), and regional isolation for latency, data residency, or blast-radius control.
+
+## Why hub-spoke?
+
+| Benefit | Description |
+| --- | --- |
+| Centralized management | One control plane for membership, RBAC patterns, and bulk upgrades. |
+| Policy enforcement | Kubernetes policies, compliance checks, and security baselines propagate from the hub. |
+| Observability | Aggregated metrics, logging, and tracing strategies start at the hub and uniform dashboards span spokes. |
+| GitOps consistency | A single Git revision strategy (with branch or overlay variants) drives spoke drift correction. |
+
+## Platform architecture overview
+
+Single `main` branch: hub chart at `.`, spoke charts at `east/` and `west/`, shared `components/` referenced by all clusters.
+
+[![Platform architecture overview](/images/hybrid-mesh-platform/arch-overview.png)](/images/hybrid-mesh-platform/arch-overview.png)
+
+[![Hub-spoke GitOps flow](/images/hybrid-mesh-platform/arch-hub-spoke-flow.png)](/images/hybrid-mesh-platform/arch-hub-spoke-flow.png)
+
+## Follow the request — one temperature reading end to end
+
+When a machine sensor on the east spoke publishes a temperature sample, the path is: MQTT (`messaging` broker) → Camel K (`mqtt-to-kafka` integration) → Kafka (`dev-cluster` topic) → optional ML scoring (KServe) → line-dashboard WebSocket consumer. In parallel, Thanos Querier on east scrapes Istio and Kafka metrics; a Skupper Connector (`prometheus-east`) tunnels HTTP to the hub, where Grafana datasource `prometheus-east` plots the series. The Hub Gateway can route browser traffic to the east line-dashboard via spoke-gateway and Skupper listener `ie-gateway-east`. Developer Hub Topology shows the same pods when the catalog entity carries `backstage.io/kubernetes-cluster: east` and spoke API tokens are synced.
+
+[![End-to-end data flow](/images/hybrid-mesh-platform/arch-data-flow.png)](/images/hybrid-mesh-platform/arch-data-flow.png)
+
+## Components on the hub vs spokes
+
+| Area | Hub | Spokes | Config path |
+| --- | --- | --- | --- |
+| ACM hub operator & APIs | yes | | `values.yaml` |
+| ArgoCD / App-of-Apps root | yes | yes | `.` / `east/` / `west/` |
+| ApplicationSet (spoke apps) | yes | | `values.yaml` |
+| ACS Central | yes | | `values.yaml` |
+| ACS Secured Cluster | | yes | `east/` `west/` |
+| Developer Hub | yes | | `values.yaml` |
+| Hub Gateway (Gateway API) | yes | | `values.yaml` |
+| Spoke Gateway (Gateway API) | | yes | `east/` `west/` |
+| Industrial Edge workloads | | yes | `east/` `west/` |
+| Kafka brokers (regional) | | yes | `east/` `west/` |
+| Service Mesh ambient / ztunnel | yes | yes | both |
+| Istio CNI (`profile: ambient`) | yes | yes | both |
+| Skupper Site (hub listeners) | yes | | `values.yaml` |
+| Skupper Site (spoke connectors) | | yes | `east/` `west/` |
+| Grafana (multi-cluster dashboards) | yes | | `values.yaml` |
+| Grafana (local metrics) | | yes | `east/` `west/` |
+| Kiali + OSSM Console plugin | yes | yes | both |
+| Connectivity Link (RHCL) | yes | yes | both |
+| Kubecost (primary aggregator) | yes | | `values.yaml` |
+| Kubecost (agent) | | yes | `east/` `west/` |
+| Kafka Console (all clusters) | yes | | `values.yaml` |
+
+## GitOps application delivery flow
+
+Hub syncs first; ApplicationSet pushes per-spoke charts; each spoke Argo CD reconciles child Applications locally.
+
+[![GitOps sync sequence](/images/hybrid-mesh-platform/arch-gitops-sync-sequence.png)](/images/hybrid-mesh-platform/arch-gitops-sync-sequence.png)
+
+## Sync wave ordering
+
+Components deploy in strict order via ArgoCD sync waves:
+
+[![Sync wave ordering](/images/hybrid-mesh-platform/arch-sync-waves.png)](/images/hybrid-mesh-platform/arch-sync-waves.png)
+
+Sync waves prevent operators from racing workloads — mesh and namespaces land before Industrial Edge and gateways.
+
+## Service Interconnect (Skupper) topology
+
+Red Hat Service Interconnect creates a Virtual Application Network (VAN) that bridges services across clusters without VPN or direct network connectivity.
+
+Connectors expose spoke-gateway and prometheus-auth-proxy; Listeners materialize ClusterIP services on the hub.
+
+[![Skupper topology](/images/hybrid-mesh-platform/arch-skupper-topology.png)](/images/hybrid-mesh-platform/arch-skupper-topology.png)
+
+[![Service Interconnect console topology](/images/hybrid-mesh-platform/service-interconnect-console-topology.png)](/images/hybrid-mesh-platform/service-interconnect-console-topology.png)
+
+## Spoke gateway aggregation
+
+Each spoke runs a Gateway API gateway that fronts all Industrial Edge services, providing a single entry point for Skupper to expose to the hub.
+
+One Connector per spoke exposes the gateway instead of every microservice individually.
+
+## Multi-cluster observability pipeline
+
+Spoke Thanos Querier is reached through nginx auth-proxy Connectors; hub Grafana uses HTTP datasources without bearer tokens.
+
+[![Observability pipeline](/images/hybrid-mesh-platform/arch-observability-pipeline.png)](/images/hybrid-mesh-platform/arch-observability-pipeline.png)
+
+## Data flow (sensors to dashboard)
+
+Telemetry path on each spoke; MirrorMaker replicates to the hub-centralized MinIO data lake.
+
+## Comparison with Red Hat Validated Patterns
+
+The [Multicloud GitOps](/patterns/multicloud-gitops) validated pattern demonstrates fleet GitOps with OpenShift GitOps and ACM patterns that resemble this repository's hub-push model: a declarative root Application, cluster grouping, and progressive rollout.
+
+This platform extends that idea with [Industrial Edge](/patterns/industrial-edge/) workloads deployed on multiple spokes, Service Mesh ambient, Connectivity Link, optional OpenShift AI, ACS depth, and Service Interconnect for cross-cluster service exposure — tuned for factory-style telemetry and east-west observability rather than only infrastructure provisioning.