Replies: 1 comment 7 replies
-
Typically, if you want to have cross-pod volumes in Kubernetes, you need to utilize a persistent volume type that is Or in other-words, some volume that supports reading and writing at the same time. The
Question: does the GitLab mechanism support this type of abstraction? If you are reading / writing to a single volume across many different pods (which may exist across many different nodes in the cluster), aren't you inviting a race-condition?
While I haven't tried it, my guess is yes. This is not so much a Bottlerocket abstraction as it is a kubernetes one since a specific volume type needs to enable It may depend on which volume type you use and where it gets mounted in order to deduce the path. Does the GitLab runner mechanism enable you to set the path to this
Most certainly there would be security implications. Our default SELinux policy likely will block read/write access to a single volume from across many different PID namespaces (this has the benefit of preventing cross container poisoning on the filesystem). I'd also worry about making your cache a one-stop-shop for potential malicious actors: if you're using a single volume for all your workloads, this could be a single point of failure that a sole compromised container could take advantage of. |
Beta Was this translation helpful? Give feedback.
-
I'm looking into using ReadWrite hostPath volume, that will be used to share cache data between multiple pods.
I'm running GitLab CI Runners in EKS with Bottlerocket OS nodes. With volume that can be shared across multiple gitlab-ci-runner pods on the same node, I can share a
/build
path which is used to hold fetched git repos. Idea is that by default GitLab CI Runners in kubernetes always start empty and must clone a repo as first step. But if the/build
path is mounted and it holds already checked out repos, they can be reused, reducing time for runner doing prep work. Additional details at https://docs.gitlab.com/runner/executors/kubernetes.html#custom-builds-directory-mount.I'm looking specifically into hostPath volumes because:
All in all having
/build
as hostPath volume is just local disk cache, GitLab Runners can handle when it's empty and populate it or reuse it when it has needed data (git repo clones), so it can exists with node and doesn't need to be persisted when node is terminated.So here are my questions:
/build
(as seen in gitlab-ci-runner pod filesystem) isn't usable. Maybe there is some mount point/path that allows read-write access? Right now I run Bottlerocket instances with single EBS volume, no ephemeral volumes or secondary EBS volumes available.Beta Was this translation helpful? Give feedback.
All reactions