Open bkelava opened 1 month ago
While allowing the probe to be overriden is something we can consider, can you explain what you are trying to accomplish here? Why do you expect rabbitmq-diagnostics ping
to be a better readiness probe? What are the situations where it would be better?
@mkuratczyk, we are facing the same issue with overriding readinessProbe.initialDelaySeconds
. We are deploying rabbitmq on EKS + Fargate cluster and the intrinsic scheduling takes about 100 seconds. With the default for readinessProbe.initialDelaySeconds
as 10s, we face the error everytime the rabbitmq pod is scheduled:
Readiness probe failed: dial tcp 10.35.177.155:5672: connect: connection refused
@sudhirjena
I've temporary fixed error by commenting readinessProbe as follows:
...
override:
statefulSet:
spec:
template:
spec:
containers:
- name: rabbitmq
livenessProbe:
exec:
command:
- rabbitmq-diagnostics
- status
initialDelaySeconds: 60
periodSeconds: 60
timeoutSeconds: 15
# readinessProbe:
# tcpSocket:
# port: 22
# # exec:
# # command:
# # - rabbitmq-diagnostics
# # - ping
# initialDelaySeconds: 20
# periodSeconds: 60
# timeoutSeconds: 10
securityContext:
allowPrivilegeEscalation: false
capabilities:
add:
- CHOWN
privileged: false
procMount: Default
readOnlyRootFilesystem: false
runAsNonRoot: false
runAsUser: 999
runAsGroup: 100
...
Cluster has started without errors
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod/rabbitmq-test-server-0 1/1 Running 0 7d13h 10.33.128.2 servisi-0023 <none> <none>
pod/rabbitmq-test-server-1 1/1 Running 0 7d13h 10.33.128.3 servisi-0023 <none> <none>
pod/rabbitmq-test-server-2 1/1 Running 0 7d13h 10.35.128.3 servisi-0024 <none> <none>
pod/rabbitmq-test-server-3 1/1 Running 0 7d13h 10.33.128.4 servisi-0023 <none> <none>
pod/rabbitmq-test-server-4 1/1 Running 0 7d13h 10.35.128.2 servisi-0024 <none> <none>
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
service/rabbitmq-test ClusterIP 10.245.98.250 <none> 5672/TCP,15672/TCP,15692/TCP 27d app.kubernetes.io/name=rabbitmq-test
service/rabbitmq-test-nodes ClusterIP None <none> 4369/TCP,25672/TCP 27d app.kubernetes.io/name=rabbitmq-test
But as always, temporary solution might be a permanent one 🥇
We are not against the idea, so PRs welcome. This is an open source project, you don't have to wait for us to get around to implementing this.
Describe the bug
Overriding stateful set readiness probe from tcpSocket to exec keeps tcpSocket in its config.
To Reproduce
kubectl apply -f cluster-test.yml
kubectl get statefulset rabbitmq-test-server -o yaml
statefulset did not override readiness probe but keeps both exec and tcpSocket configs as follows:
which results in error
patching stateful set is an option to fix but it is not ideal!, please help.