https://rancher.com/ logo
Join Slack
Powered by
We are trying to deploy a pod & container with...
# longhorn-storage
m
We are trying to deploy a pod & container within our Harvester cluster using Longhorn as our storage solution. Everything goes fine except it attaches the ephemeral volume we create as root within the container itself with chmod 755 permissions, which prevents the container user from accessing or writing data to that mount. Is there something that is forcing these permissions? We're running everything for building the container using the securityContext propagated with runAsUser/Group, and also runAsNonRoot.
c
what exactly do you mean by “ephemeral volume”
Can you show the pod spec?
m
Copy code
apiVersion: v1
kind: Pod
metadata:
  name: ephemeral
spec:
  securityContext:
    runAsGroup: 10001
    runAsNonRoot: true
    runAsUser: 10001
    supplementalGroups:
    - 1000
  containers:
  - name: fame-fs
    image: <http://mcr.microsoft.com/dotnet/aspnet:8.0-noble|mcr.microsoft.com/dotnet/aspnet:8.0-noble>
    command: ["sh", "-c", "tail -f /dev/null"]
    imagePullPolicy: IfNotPresent          
    resources:
      requests:
        memory: "1Gi"
        cpu: "250m"
      limits:
        memory: "1Gi"
        cpu: "250m"
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
        - ALL
      privileged: false
      readOnlyRootFilesystem: true
    volumeMounts:
    - mountPath: /tmp
      name: tmp     
  volumes:
  - name: tmp
    ephemeral:
      volumeClaimTemplate:
        spec:
          accessModes: [ "ReadWriteOnce" ]
          resources:
            requests:
              storage: "5Gi"
c
Just out of curiosity, why are you using a generic ephemeral volume for this instead of emptydir?
I don’t see that you’re setting fsGroup in the securityContext, I think that is probably want you wanted to do?
see the docs on spec.securityContext.fsGroup and spec.securityContext.fsGroupChangePolicy
m
I asked my dev why he choose ephemeral, and he thought it would be more robust - and also not share disk space with the pod that we're putting the container on.
c
You can control that. Per the docs:
The 
emptyDir.medium
field controls where 
emptyDir
volumes are stored. By default 
emptyDir
volumes are stored on whatever medium that backs the node such as disk, SSD, or network storage, depending on your environment. If you set the 
emptyDir.medium
field to 
"Memory"
, Kubernetes mounts a tmpfs (RAM-backed filesystem) for you instead. While tmpfs is very fast, be aware that, unlike disks, files you write count against the memory limit of the container that wrote them.
I am not sure why robustness would matter for an ephemeral volume since it is… ephemeral
emptydir with tmpfs is usually what I use for stuff that I expect to behave like /tmp on a traditional host fs
2 Views
Open in Slack
PreviousNext
Powered by