Merge pull request #2403 from oracle-devrel/oke-gitops

Oke gitops 1.1.3

Author: martatolosa

app-dev/devops-and-containers/oke/oke-gitops/README.md

@@ -139,7 +139,7 @@ This stack will:
 * Create 2 OCI Code Repositories: one with pipelines definitions, and another one called "oke-cluster-config" with the git template for the OKE cluster administrators
 * Create an OCI Build Pipeline that will mirror the ArgoCD Helm Chart inside the Oracle Cloud Registry, and deploy it in the chosen cluster
 
-[![Deploy to Oracle Cloud](https://oci-resourcemanager-plugin.plugins.oci.oraclecloud.com/latest/deploy-to-oracle-cloud.svg)](https://cloud.oracle.com/resourcemanager/stacks/create?zipUrl=https://github.com/oracle-devrel/technology-engineering/releases/download/oke-gitops-1.1.2/stack.zip)
+[![Deploy to Oracle Cloud](https://oci-resourcemanager-plugin.plugins.oci.oraclecloud.com/latest/deploy-to-oracle-cloud.svg)](https://cloud.oracle.com/resourcemanager/stacks/create?zipUrl=https://github.com/oracle-devrel/technology-engineering/releases/download/oke-gitops-1.1.3/stack.zip)
 
 Once the stack has been provisioned, you can modify the ArgoCD version to deploy by editing the `mirror_argo.yaml` file in the `pipelines` repository.
 By default, ArgoCD will be deployed in an "insecure" mode to disable the default SSL certificate, but feel free to modify the chart values in the `argo-cd-chart-values` artifact.

app-dev/devops-and-containers/oke/oke-gitops/repos/system-cluster-config/README.md

@@ -86,17 +86,55 @@ system-cluster-config/
 │       └── infra.yml       # ApplicationSet for infrastructure apps
 └── infra/                  # Cluster-level infrastructure resources
     ├── base/               # Base kustomize resources (quotas, namespaces, etc.)
-    └── overlays/           # Profile-specific overlays (e.g., hub/)
+    └── overlays/           # Profile-specific overlays
+        └── hub/            # Hub cluster infrastructure
+            ├── common/     # Resources common to all namespaces (RBAC, configmaps)
+            ├── namespaces/ # Namespace-specific resources
+            │   └── dev-team/  # Example namespace (dev-team)
+            └── kustomization.yaml  # Main overlay combining all resources
 ```
 
 ### Infrastructure Folder
 
-The `infra/` folder contains cluster-level resources deployed via Kustomize, similar to application structures. It includes base resources and profile-specific overlays.
+The `infra/` folder manages cluster-level infrastructure resources using a **3-tier hierarchical structure** deployed via Kustomize. This approach provides clear separation of concerns and promotes reusability across namespaces.
 
-- **Base Resources**: Common cluster resources like ResourceQuotas, Namespaces, PersistentVolumeClaims, ValidatingAdmissionPolicies, etc.
-- **Overlays**: Customizations per profile (e.g., `overlays/hub/` for hub-specific infra).
+#### 3-Tier Structure Explained
 
-This ensures foundational cluster configurations are managed consistently across profiles.
+**1. Base Layer (`infra/base/`)**
+- Contains **global cluster resources** that apply to the entire cluster
+- Examples: ResourceQuotas, PersistentVolumeClaims, ValidatingAdmissionPolicies, cluster-wide ConfigMaps
+- These resources are shared across all namespaces and profiles
+
+**2. Common Layer (`infra/overlays/hub/common/`)**
+- Contains **cross-namespace resources** shared by multiple namespaces
+- Examples: RBAC roles/cluster roles, shared ConfigMaps, NetworkPolicies that apply to multiple namespaces
+- These resources are applied to all namespaces within a profile (e.g., hub)
+
+**3. Namespace Layer (`infra/overlays/hub/namespaces/dev-team/`)**
+- Contains **namespace-specific resources**
+- Examples: Namespace definitions, namespace-scoped RBAC, namespace-specific quotas
+- Each namespace gets its own folder following the pattern `namespaces/<namespace-name>/`
+
+#### How It Works
+
+The main overlay (`infra/overlays/hub/kustomization.yaml`) combines all layers:
+1. **First**: Imports base resources (global scope)
+2. **Then**: Includes namespace-specific configurations, which automatically include common resources
+
+This hierarchical approach ensures:
+- **DRY Principle**: Common resources aren't duplicated
+- **Scalability**: Easy to add new namespaces following the same pattern
+- **Maintainability**: Clear organization makes it easy to find and modify resources
+- **Consistency**: Base and common resources are applied uniformly across the cluster
+
+#### Example Workflow
+
+When deploying infrastructure to a hub cluster:
+1. Base resources (quotas, PVCs) are applied cluster-wide
+2. Common resources (shared RBAC, configmaps) are applied to all namespaces
+3. Namespace-specific resources (namespace definition, local RBAC) are applied to each namespace
+
+This structure provides a solid foundation for managing complex multi-tenant Kubernetes clusters.
 
 ### Workflow