# In-cluster capacity ramp for the tidalDB multi-process cluster (m11p5 k8s/cluster/). # # Runs the load generator AS A POD so requests take the real cluster network path # (a `kubectl port-forward` serializes everything through the API server and adds # tens of ms — useless for capacity numbers). Targets the three region pods by # their per-pod headless-Service DNS (tidaldb-N.tidaldb-peers...); reads # round-robin across them (each serves locally), leader-path writes are pinned to # tidaldb-0 to measure the single-leader funnel. (Post-election the leader can # move; for a long elasticity run let writes forward — every pod forwards to the # current leader — or re-point --leader-url after a deliberate promote.) # # Apply: kubectl apply -f tidal-stress/k8s/stress-job.yaml # Watch: kubectl logs -f job/tidal-stress -n tidaldb-cluster # Re-run: kubectl delete job tidal-stress -n tidaldb-cluster; kubectl apply -f ... # # To compare the horizontally-scaled path, change `--write-path leader` to # `--write-path sharded` (hash-partitions writes across all 3 regions, no funnel). apiVersion: batch/v1 kind: Job metadata: name: tidal-stress namespace: tidaldb-cluster labels: app.kubernetes.io/name: tidal-stress app.kubernetes.io/part-of: tidaldb spec: backoffLimit: 0 # a load run is not retried — read the logs ttlSecondsAfterFinished: 7200 template: metadata: labels: app.kubernetes.io/name: tidal-stress app.kubernetes.io/part-of: tidaldb spec: restartPolicy: Never automountServiceAccountToken: false affinity: podAntiAffinity: # Keep the generator OFF the leader's node so it never steals CPU from # the write bottleneck we are measuring. The leader is pod tidaldb-0; # StatefulSet pods carry the auto label statefulset.kubernetes.io/pod-name. requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchLabels: statefulset.kubernetes.io/pod-name: tidaldb-0 topologyKey: kubernetes.io/hostname securityContext: runAsNonRoot: true runAsUser: 1000 runAsGroup: 1000 seccompProfile: type: RuntimeDefault containers: - name: stress image: registry.threesix.ai/tidal/stress@sha256:77395cc2857e2adabaa37607b198316d6f1cd0ec04f749caf2de959e6bade55b # :v1 imagePullPolicy: IfNotPresent args: - --target - http://tidaldb-0.tidaldb-peers.tidaldb-cluster.svc.cluster.local:9500 # region tidaldb-0 (initial leader) - --target - http://tidaldb-1.tidaldb-peers.tidaldb-cluster.svc.cluster.local:9500 # region tidaldb-1 - --target - http://tidaldb-2.tidaldb-peers.tidaldb-cluster.svc.cluster.local:9500 # region tidaldb-2 - --leader-url - http://tidaldb-0.tidaldb-peers.tidaldb-cluster.svc.cluster.local:9500 - --ramp - peach-100k - --stage-secs - "45" - --mix - peach - --write-path - leader - --corpus - "20000" - --users - "100000" - --poll-status env: - name: TIDAL_API_KEY valueFrom: secretKeyRef: name: tidaldb-credentials key: TIDAL_API_KEY - name: TIDAL_STRESS_LOG value: warn resources: # Small REQUEST (the cluster is request-saturated though ~15% utilised) # with a high LIMIT: the generator bursts to the cycles it needs on the # idle node. If it ever CPU-saturates, the report's schedule-lag / # client-shed will say so — then split the load across multiple Jobs. requests: cpu: 250m memory: 256Mi limits: cpu: "3" memory: 1Gi securityContext: allowPrivilegeEscalation: false readOnlyRootFilesystem: true capabilities: drop: ["ALL"]