[SIMPL-30451] Verify the Kubernetes pipes transport on the sandbox

Run cff9b348-bfc3-4ac1-ab51-a94892b8e3a0 of loosely_coupled_k8s_job reached RUN_SUCCESS in dataprovider01 on sandbox-cat-dat: four payload Jobs, four distinct payload pod hostnames in contributing_hosts, and the payload log lines in the run log. Checks L4-L10 are now observed rather than derived. Torn down afterwards; the namespace was left as it was found.

Corrects two claims that were wrong. The registry does NOT require a pull secret - a bare GET returns 401, but that is the opening move of the Docker token handshake, and completing it anonymously returns the manifest for both images. And PIPES_PAYLOAD_NAMESPACE was set to a namespace named dagster, which does not exist on that cluster; the release is called dagster but runs in dataprovider01.

Adds the sandbox probe variant. The generic probe cannot run there: sandbox access is Rancher project-scoped, so a new namespace grants its creator nothing and Role creation is denied everywhere. It is not needed either, since dagster-role already carries the exact pipes permissions.

Changelog: added
This commit is contained in:
ILay
2026-08-31 19:41:26 +02:00
parent e686df5710
commit 96caa3f81b
5 changed files with 204 additions and 76 deletions

View File

@@ -0,0 +1,124 @@
# Sandbox variant of the pipes cluster probe.
#
# Runs `loosely_coupled_k8s_job` as a single Job in dataprovider01, reusing the
# platform's own dagster-svc-account. Use this instead of
# yaml/loosely-coupled/probe-pipes-k8s.yaml on sandbox-cat-dat.
#
# WHY IT LOOKS DIFFERENT. The generic probe creates its own namespace, service
# account and RBAC. That cannot run here: sandbox access is Rancher
# project-scoped, so a freshly created namespace belongs to no project and the
# creator has no rights inside it, and `create roles` is denied in every
# namespace. Verified with `kubectl auth can-i`, not assumed.
#
# It does not need them anyway. The `dagster-role` bound to dagster-svc-account
# already grants batch/jobs (full verbs), jobs/status, pods, events, and
# pods/log - exactly the set the pipes client needs. Readiness checks L5 and L6
# therefore already pass on this cluster; read the live Role to confirm:
#
# kubectl -n dataprovider01 get role dagster-role -o yaml
#
# WHAT THIS COSTS. Unlike the generic probe this is NOT isolated. It borrows a
# live service account and leaves payload Jobs in a shared namespace until they
# are deleted. Nothing it does is persistent, but it is visible to anyone else
# working in dataprovider01.
#
# --- Credentials: none needed ----------------------------------------------
#
# Both Gitea images are anonymously pullable. A bare GET to the registry returns
# 401, which looks like a refusal but is just the start of the Docker token
# handshake; completing it anonymously and re-requesting the manifest returns
# 200 for both images. Verify with:
#
# TOK=$(curl -sS "https://gitea.dataprovider01.sandbox-cat-dat.simpl-europe.eu/v2/token?service=container_registry&scope=repository:j.r/distributed-execution:pull" | jq -r .token)
# curl -sS -o /dev/null -w '%{http_code}\n' -H "Authorization: Bearer $TOK" \
# https://gitea.dataprovider01.sandbox-cat-dat.simpl-europe.eu/v2/j.r/distributed-execution/manifests/5122da4691f9
#
# This also means the payload Jobs need nothing: they run as the `default`
# service account, which carries no pull secret, and do not need one.
#
# --- Running ---------------------------------------------------------------
#
# kubectl -n dataprovider01 apply -f yaml/sandbox/probe-pipes-k8s-sandbox.yaml
# kubectl -n dataprovider01 logs -f job/distexec-pipes-probe
# kubectl -n dataprovider01 get jobs -l app.kubernetes.io/name=distributed-execution-payload
#
# --- Teardown --------------------------------------------------------------
#
# kubectl -n dataprovider01 delete job distexec-pipes-probe
# kubectl -n dataprovider01 delete jobs -l app.kubernetes.io/name=distributed-execution-payload
#
# VERIFIED 2026-08-31 on sandbox-cat-dat / dataprovider01. Run
# cff9b348-bfc3-4ac1-ab51-a94892b8e3a0 reached RUN_SUCCESS: four payload Jobs,
# four distinct payload pod hostnames in contributing_hosts, messages returned
# over the pod log stream. Checks L4-L10 pass. Torn down afterwards; the
# namespace was left as it was found.
apiVersion: batch/v1
kind: Job
metadata:
name: distexec-pipes-probe
namespace: dataprovider01
labels:
app.kubernetes.io/name: distributed-execution
app.kubernetes.io/component: probe
spec:
backoffLimit: 0
activeDeadlineSeconds: 1800
template:
metadata:
labels:
app.kubernetes.io/name: distributed-execution
app.kubernetes.io/component: probe
spec:
restartPolicy: Never
# Already holds jobs + pods/log; this probe grants itself nothing.
serviceAccountName: dagster-svc-account
# dagster-svc-account sets automountServiceAccountToken: false, so every
# pod that uses it must opt back in - the chart does this for its own
# deployments. Without it the pipes client picks in-cluster auth correctly
# and then fails on "Service token file does not exist".
automountServiceAccountToken: true
securityContext:
runAsNonRoot: true
runAsUser: 1000
runAsGroup: 1000
fsGroup: 1000
seccompProfile:
type: RuntimeDefault
containers:
- name: dispatcher
image: gitea.dataprovider01.sandbox-cat-dat.simpl-europe.eu/j.r/distributed-execution:5122da4691f9
imagePullPolicy: IfNotPresent
securityContext:
allowPrivilegeEscalation: false
capabilities:
drop:
- ALL
command:
- dagster
- job
- execute
- -f
- src/distributed_execution/repository.py
- -j
- loosely_coupled_k8s_job
env:
- name: DAGSTER_HOME
value: /dagster-home
- name: PIPES_PAYLOAD_IMAGE
value: gitea.dataprovider01.sandbox-cat-dat.simpl-europe.eu/j.r/distributed-execution-payload:5122da4691f9
- name: PIPES_PAYLOAD_NAMESPACE
value: dataprovider01
volumeMounts:
- name: dagster-home
mountPath: /dagster-home
resources:
requests:
cpu: 200m
memory: 512Mi
limits:
cpu: "1"
memory: 1Gi
volumes:
- name: dagster-home
emptyDir: {}