You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
- Dynamically start or stop routers when CRDs in managed API groups are created, updated, or deleted
54
+
- Managed groups are defined in `manager/assets/managed_groups`
70
55
71
-
- Periodically clears internal resolver caches.
56
+
## Stored Resource Model
72
57
73
-
74
-
## Features
75
-
76
-
- Kubernetes-native (uses `InClusterConfig`)
77
-
- High-throughput batching
78
-
- Structured logging
79
-
- Automatic cluster name detection
80
-
- Event enrichment pipeline
81
-
- Backpressure-safe queue
82
-
- Health probes
83
-
- Graceful shutdown
84
-
- Cloud-ready design
85
-
86
-
## Stored Event Model
87
-
88
-
Each Kubernetes event is transformed into a structured record containing:
58
+
Each Kubernetes resource is transformed into a structured record containing:
89
59
90
60
- Cluster name
91
61
- Namespace
92
-
- Resource kind and name
93
-
- Event type and reason
94
-
- Human-readable message
62
+
- API group, version, kind, and plural resource name
63
+
- Resource name
95
64
- Composition ID (when available)
96
-
- Creation timestamp
97
-
- Resource version
98
-
- Raw JSON payload
99
-
- Globally unique ID (`cluster:eventUID`)
100
-
101
-
Events are **minified** before storage to reduce payload size.
65
+
- Creation, update, and deletion timestamps
66
+
- Raw JSON payload (full object)
67
+
- UID and globally unique ID (`cluster:uid`)
102
68
69
+
Resources are stored with their full unstructured representation.
103
70
104
71
## Requirements
105
72
106
73
- Kubernetes cluster
107
74
- PostgreSQL
108
75
- Network connectivity between the service and the database
109
-
- RBAC permissions to watch events
110
-
76
+
- RBAC permissions to watch the configured resource kinds
111
77
112
78
## Configuration
113
79
114
80
The application is configured via environment variables.
115
81
116
82
| Variable | Description | Default |
117
-
|------------|----------------|------------|
83
+
|---|---|---|
118
84
|`PORT`| Health probe server port |`8080` (implementation-dependent) |
119
85
|`DB_USER`| Database username | — |
120
86
|`DB_PASS`| Database password | — |
@@ -127,43 +93,98 @@ The application is configured via environment variables.
127
93
128
94
> The service builds the PostgreSQL connection string from these values.
129
95
96
+
## Configuring Watched Resources
130
97
131
-
## How It Works
98
+
The ingester has two separate mechanisms for deciding which resources to watch.
132
99
133
-
### 1. Startup Sequence
100
+
### Static Routers
134
101
135
-
- Waits for PostgreSQL to become available
136
-
- Detects the cluster name
137
-
- Starts the health probe server
138
-
- Initializes the Kubernetes client
139
-
- Launches workers and batch processor
140
-
- Begins watching events
102
+
Static routers are defined in `router/assets/static`. Each line declares a resource kind to watch from the moment the service starts, regardless of CRDs.
141
103
104
+
**Format:**`group/version/resource/Kind`
142
105
143
-
### Event Flow
106
+
For cluster-scoped resources and core API group resources, leave the group segment empty.
- Exactly four `/`-separated segments are required; lines with a different count are skipped
119
+
- The group segment may be empty (core API group resources such as Pods and Namespaces)
120
+
- CRDs **must** be listed here for the dynamic manager to function, since it subscribes to CRD events
121
+
122
+
### Managed API Groups (Dynamic CRD Watching)
123
+
124
+
Dynamic routers are driven by CRD discovery. When a `CustomResourceDefinition` is created, updated, or deleted, the manager checks whether its API group appears in `manager/assets/managed_groups`. If it does, a router is started (or stopped) automatically.
125
+
126
+
**Format:** one API group per line.
127
+
128
+
```txt
129
+
composition.krateo.io
130
+
widgets.templates.krateo.io
131
+
core.krateo.io
132
+
```
148
133
149
-
- Resolves related objects
150
-
- Extracts metadata
151
-
- Attaches composition ID
152
-
- Builds a structured record
134
+
Rules:
153
135
154
-
4. The record becomes a queued job.
155
-
5. The batch worker writes it to PostgreSQL.
136
+
- One group per line, blank lines are ignored
137
+
- Groups are matched **exactly** against the CRD's `spec.group`
138
+
- Adding a group here causes the service to begin watching all CRDs installed under that group
139
+
- Removing a group and redeploying stops watching those resources
140
+
- The CRD kind itself must be listed in the static routers file above for this mechanism to receive events
141
+
142
+
## How It Works
143
+
144
+
### 1. Startup Sequence
145
+
146
+
1. Waits for PostgreSQL to become available
147
+
2. Detects the cluster name
148
+
3. Starts the health probe server
149
+
4. Initializes the Kubernetes dynamic client
150
+
5. Launches the batch writer and worker pool
151
+
6. Starts static routers for fixed resource kinds
152
+
7. Starts the dynamic manager to respond to CRD changes
153
+
8. Begins processing events
154
+
155
+
### Event Flow
156
+
157
+
1. Kubernetes emits a resource change (add, update, or delete).
158
+
2. The router enqueues a `QueueItem` containing the object key and GVR.
159
+
3. The worker pool dequeues the item and calls `reconcile`:
160
+
- For CRDs (`apiextensions.k8s.io`): routes to the Manager via event bus to start or stop a dynamic router.
161
+
- For all other resources: looks up the current object from the informer store and routes to Storage.
0 commit comments