Closed yaegel closed 5 months ago
This issue is currently awaiting triage.
If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted
label and provide further guidance.
The triage/accepted
label can be added by org members by writing /triage accepted
in a comment.
/sig Storage
/assign @humblec
@yaegel can you provide the POD yaml you have submitted for the plugin mount ? Have you specificied secretFile
configuration in the yaml? if yes, where is it pointing to ?
As a side note, please note that , the Kube version you are running in your setup is really old ie v1.18 and unsupported..
I'm aware that 1.18 is well out of support, it's hard to keep up with the pace the k8s team keeps!
Here's the volume snippet from my yaml:
volumes:
- name: cephfs
cephfs:
monitors:
- "ipaddress:6789"
user: admin
secretRef:
name: new-ceph-secret
path: "/erams/catena-gis"
readOnly: false
I don't specify secretFile since I don't want to use it, I want to use the secret defined in the yaml.
Thanks for your attention and help!
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/reopen
/remove-lifecycle rotten
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
@k8s-triage-robot: Closing this issue, marking it as "Not Planned".
What happened?
I have a Kubernetes v1.18.17 cluster which mounts a ceph volume for most running pods. The volume definition in the yaml includes a user, a secret, and a monitor ip.
This works fine when pods are scheduled for nodes that don't have the ceph-common binaries installed on the host machine. However, when the pods get scheduled on nodes that have the ceph-common binaries installed K8s seems to ignore the volume configuration details in the yaml and instead default to looking for configuration in /etc/ceph/...
In my case that folder is empty because I just need to binaries to mount the cephfs for research storage, but not to act as monitors or other ceph control plane daemons.
What did you expect to happen?
If a volume is defined in a yaml created in K8s, I would expect the values provided in the yaml to override anything on the bare node.
How can we reproduce it (as minimally and precisely as possible)?
Try to run a pod which includes a ceph volume mount on a node which also has ceph-common installed, but no /etc/ceph/ceph.conf file.
Anything else we need to know?
No response
Kubernetes version
Cloud provider
OS version
Install tools
Container runtime (CRI) and version (if applicable)
Related plugins (CNI, CSI, ...) and versions (if applicable)