-
Notifications
You must be signed in to change notification settings - Fork 16.8k
[stable/rabbitmq] When using minikube and PVC, Liveness and Readiness probes fail #14757
Comments
Log:
|
I see this line in the log:
I don't understand. I have the PV at |
In another test, we tried the We did a
Didn't see the anything for the pod (i.e. not CreatingContainer, Init:0/1, PodInitializing, nor Running). |
Just to make sure I'm not missing something, I just performed
But it did not solve the issue. |
Hi @docktermj! Thanks for all the detailed instructions! I was able to reproduce the issue in Minikube. Can I ask why do you create the PV and PVC manually? I tried deploying the chart with the default configuration and it worked fine. So I suspect the problem is using a hostPath volume. Regarding the issue in IBM Cloud park, could you run the following command to see why the stateful set is not creating the pods?
|
Hi @tompizmor! On the question of PV and PVC... I'm creating a series of "reference implementations" at https://github.com/Senzing/kubernetes-demo to help users understand how to bring up a docker formation using I, too, was able to get the default to work, but I didn't that think it was sufficient for a "teaching exercise". I ran into a similar issue in #14390 and it has been fixed thanks to @juan131. |
@rgahockey As described 2 posts up, can you run the following command:
...at least I think that's the @tompizmor , As background for you, the instructions we are crafting are at |
[root@rga-icp4d01-icpmaster-0 ~]# kubectl describe sts --namespace zen senzing-rabbitmq
Volumes: Warning FailedCreate 3m29s (x18059 over 6d2h) statefulset-controller create Pod senzing-rabbitmq-0 in StatefulSet senzing-rabbitmq failed error: pods "senzing-rabbitmq-0" is forbidden: unable to validate against any pod security policy: [spec.initContainers[0].securityContext.runAsUser: Invalid value: 0: running with the root UID is forbidden] |
Formatted:
|
So for IBM Cloud Pak, I think this is the story: The RabbitMQ chart needs to change ownership of the files in the "persistence path". However the security policies in IBM Cloud Pak seem to prevent that from happening. |
@tompizmor, is there anything else we can do or provide to help get the original issue resolved? |
It appears back in Dec 19, 2018 there was supposed to be a way to set the SecurityContext ... The initContainer was added to avoid issues on some K8s distributions were SecurityContext wasn't respected. Therefore, we needed a way to ensure the volumes had the proper permissions. What do you think about adding a parameter such as initContainer.enabled that can be set to true/false so you can decide whether to install the chart with it or not? cc/ @tompizmor Agree. We should have enough flexibility to enable/disable both the securityContext and the initContainer. |
@rgahockey I think that it's mandatory to have a way to disable the initContainer as if you run it in a secured K8S with PodSecurityPolicy runAsNonRoot the initContainer with container run as root won't be accepted. |
Good conversation. Can it be moved to a new issue? This issue is for Liveness and Readiness probes on minikube. |
Isn't this already the case? |
For me is weird having to create the PV manually as you would usually have a storage provider that will that automatically for you. The original issue was that liveness and readiness probes fail when you use an already existing
My take on this is that RabbitMQ is not able to measure the available space when you mount a hostPath volume. However, right now I have no idea how to debug this. |
@tompizmor I agree that a storage provider would set up the PV, but in my case I'm educating folks using minikube, so I need to demonstrate the PV/PVC concept. Yikes! Are we dead in the water? You mentioned that you could recreate. Is there anything I can do to move the ball forward? |
Hi @docktermj , |
Hi @tompizmor! Is there any plan to fix this issue on minikube? In the meantime, I'm using: livenessProbe:
enabled: false
readinessProbe:
enabled: false Which is probably not an illustration of "best practice". |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Any further update will cause the issue/pull request to no longer be considered stale. Thank you for your contributions. |
Any update on livenessProbe:
enabled: true
readinessProbe:
enabled: true issues on Qinikube |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Any further update will cause the issue/pull request to no longer be considered stale. Thank you for your contributions. |
This issue is being automatically closed due to inactivity. |
If this issue is not fixed, please reopen. |
Hi @tompizmor! Why is this a stale issue? Has it been fixed? |
/reopen |
Which chart:
stable/rabbitmq
Description
When using
minikube
, Persistent Volumes (PV) usinghostPath
fail when used instable/rabbitmq
chart. The Liveness and Readiness warnings prevent the pod from reaching aREADY
state of "1/1".The pod launched by the
stable/rabbitmq
chart never reaches aREADY
state of "1/1".Steps to reproduce the issue:
namespace.yaml
file:kubectl create -f namespace.yaml
persistent-volume-rabbitmq.yaml
file:kubectl create -f persistent-volume-rabbitmq.yaml
persistent-volume-claim-rabbitmq.yaml
file:kubectl create -f persistent-volume-claim-rabbitmq.yaml
rabbitmq-values.yaml
file:stable/rabbitmq
helm chart.READY
state never reaches "1/1".Describe the results you received:
Describe the results you expected:
A chart that comes up. :-)
Additional information you deem important (e.g. issue happens only occasionally):
When running without PV/PVC, the chart comes up properly.
Version of Helm and Kubernetes:
helm version
:kubectl version
:minikube
:Cleanup
The text was updated successfully, but these errors were encountered: