Data-service pods use NetworkPolicy egress selector app: trading-kafka
but Strimzi Kafka pods are labeled strimzi.io/name=trading-kafka.
This silently blocked all Kafka traffic causing NoBrokersAvailable.
- Remove helius/jupiter placeholders from trading-secrets.yaml
- Create new solana-api-keys.yaml with helius-api-key and jupiter-api-key
- Update kustomization.yaml to include solana-api-keys.yaml
Convention: each secret group gets its own SOPS-encrypted file
instead of adding new keys to an already encrypted file.
- Replace Gemini API and A100 vLLM references with central rtx6000-brain vLLM
endpoint (http://rtx6000-brain-service.customer1.svc.cluster.local:8000/v1)
- Update all ConfigMaps to use model edp1096/Huihui-Qwen3.6-27B-abliterated-FP8
- Add LLM_API_KEY: sk-dummy to all ConfigMaps
- Remove ollama sidecars, initContainers, PVC volumes from all analyst CronJobs
- Remove GPU nodeSelector, tolerations, and GPU resource requests from CronJobs
- Clean up kustomization.yaml: remove ollama-storage.yaml, deepseek-storage.yaml,
gemini-apikey.yaml references
- Activate deepseek-summarizer.yaml in kustomization, keep others commented
- Create solana-ingester Deployment + Service in trading-platform/
(uses same data-service image, runs WebSocket ingester mode)
- Add solana-ingester ConfigMap (HELIUS_RPC_ENDPOINT, JUPITER_API_URL,
KAFKA_BROKER, KAFKA_TOPIC)
- Add helius-api-key and jupiter-api-key placeholders to trading-secrets.yaml
(TODO: replace with real values and re-encrypt with SOPS)
- Update kustomization to include new resources
Kraft mode fails with AccessDeniedException on meta.properties
because PVC mounts with root ownership. Adding fsGroup: 1000
ensures the volume group matches the Kafka container user.
- Removed template.pod.brokers (not valid in Strimzi 1.0.0 Kafka schema)
- Moved broker resources to KafkaNodePool.spec.resources
- Added controller role to KafkaNodePool (KRaft requires both controller+broker)
strimzi.io/install/1.0.0 is not a valid git repo or kustomize remote URL.
Download the full install bundle (strimzi-1.0.0.yaml) and reference it
locally in the strimzi kustomization.
Split Strimzi operator deployment into its own Flux Kustomization so
CRDs are applied before the Kafka CR in customer1.
Chain: infrastructure-controllers -> customer1-strimzi -> customer1
customer1 now has force: true to skip dry-run validation when CRDs are
recently applied but not yet visible to the APIServer cache.
Flux dry-run fails when CRDs are in the same kustomization as resources
that reference them - CRDs need to exist before validation.
Two kustomizations now:
strimzi/ - Strimzi 1.0.0 CRDs + operator
siriusdevops-db - DBs, Kafka CR (depends on strimzi CRDs)
Wire them in Flux:
Kustomization 'siriusdevops-strimzi' -> path: strimzi/
Kustomization 'siriusdevops-db' -> path: siriusdevops-db/
dependsOn: [{name: siriusdevops-strimzi}]
Reference Strimzi 1.0.0 install bundle directly from kustomization.
No separate install step needed — kubectl apply -k handles CRDs + operator
in one shot before the Kafka CR.
Pinned to 1.0.0 for reproducible deployments.
Flux dry-run fails when CRDs are in the same kustomization as resources
that reference them - CRDs need to exist before validation.
Two kustomizations now:
strimzi/ - Strimzi 1.0.0 CRDs + operator
siriusdevops-db - DBs, Kafka CR (depends on strimzi CRDs)
Wire them in Flux:
Kustomization 'siriusdevops-strimzi' -> path: strimzi/
Kustomization 'siriusdevops-db' -> path: siriusdevops-db/
dependsOn: [{name: siriusdevops-strimzi}]
Reference Strimzi 1.0.0 install bundle directly from kustomization.
No separate install step needed — kubectl apply -k handles CRDs + operator
in one shot before the Kafka CR.
Pinned to 1.0.0 for reproducible deployments.
