spinkube / spin-operator

Spin Operator is a Kubernetes operator that empowers platform engineers to deploy Spin applications as custom resources to their Kubernetes clusters
https://www.spinkube.dev/docs/overview/
Other
224 stars 24 forks source link

Configuring a Spin application's `SPIN_HTTP_LISTEN_ADDR` #266

Closed kate-goldenring closed 4 months ago

kate-goldenring commented 5 months ago

As of the latest release of the containerd-shim-spin (PR https://github.com/spinkube/containerd-shim-spin/pull/138), you can now configure the port that the Spin app is served on by the shim by setting the listen address in a SPIN_HTTP_LISTEN_ADDR container env var. How can we enable users to configure this in the SpinApp CR? Can we add a SpinApp.spec.containerPort field? This would also inform the operator to update the associated app service as well. Should this instead be set on the executor under SpinAppExecutor.spec.deploymentConfig.containerPort since not all executors may serve each application on a separate port?

Here is an example deployment to configure the listen address:

kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: spin-test
spec:
  replicas: 1
  selector:
    matchLabels:
      app: spin-test
  template:
    metadata:
      labels:
        app: spin-test
    spec:
      runtimeClassName: wasmtime-spin-v2
      containers:
      - name: spin-test
        image: ttl.sh/spin-app:48h
        command: ["/"]
        ports:
        - containerPort: 82
          name: http-app
        env:
        - name: SPIN_HTTP_LISTEN_ADDR
          value: "0.0.0.0:82"
EOF

kubectl apply -f - <<EOF
apiVersion: v1
kind: Service
metadata:
  name: spin-test
spec:
  ports:
    - protocol: TCP
      port: 82
      targetPort: http-app
  selector:
    app: spin-test
EOF
endocrimes commented 5 months ago

@kate-goldenring I'd be curious as to why you'd want to change this in the Spin Operator? - We don't support the side-by-side apps issue @rajatjindal ran into, so I'm not necessarily sure this is worth the complexity it would introduce right now?

kate-goldenring commented 5 months ago

@endocrimes K3s's traefik reserves port 80 -- which causes spin apps to fail to start since they use that port by default. Instead of reconfiguring traefik, a user could wish to change this here https://github.com/spinkube/containerd-shim-spin/issues/128#issuecomment-2152870045

endocrimes commented 5 months ago

@kate-goldenring Shim apps still get their own network ns, so aren't sharing the port range with traefik though?

kate-goldenring commented 5 months ago

That is a good point. Looking back at it, the issue was that the user was running the shim directly with ctr run --net-host which tried to use the host's port 80. They also had k3s simultaneously running on that node.

rajatjindal commented 5 months ago

FWIW, I don't have a compelling usecase right now for running two spin apps in one pod. IIRC, I ran into that issue while trying out a sidecar scenario (which was not required to be spinapp as such).

rajatjindal commented 5 months ago

one other scenario where I thought this will be useful is to let user run app as non-root user. maybe we can get away with that by just changing the default port? that should not impact the enduser as they will still be served using service running on port 80. what do you think?

kate-goldenring commented 4 months ago

I think we can close this for now. If other find that they have more scenarios for configuring this or interest in the default changing in the shim, please reopen