Describe the bug
When deploying pgadmin4 to Kubernetes using version 9.11.0 of the helm chart published to oci://docker.io/dpage/pgadmin4-helm, it doesn't start, because the pod is in a crash loop backoff. The error /entrypoint.sh: line 174: /venv/bin/python3: Operation not permitted appears to come from the same reason as in issue 6694:
#6694
Looking at the unset-python3-cli-net-cap init container which tries to alleviate the issue, it appears to fail because it cannot find a python binary in /usr/bin/ in the container. Looking in /venv/bin/ in the container, it appears that python3 symlinks to /usr/local/bin/python3, which does exist.
However, updating line 208 in the deployment.yaml (https://github.com/pgadmin-org/pgadmin4/blob/master/pkg/helm/templates/deployment.yaml#L208), to point to the python at /usr/local/bin/python3, doesn't appear to fix the issue.
Curiously, updating the line to point to the python symlink in the /venv/bin/ folder, like shown below, does appear to fix the issue:
args: ['ls /venv/bin/python3.* | sort -V -r | head -n 1 | xargs -i cp {} python3']
Edit:
The mount at line 134 in the deployment (https://github.com/pgadmin-org/pgadmin4/blob/master/pkg/helm/templates/deployment.yaml#L134) also had to be updated to point to the symlinked /usr/local/bin/ instead of /usr/bin/, like shown below:
- mountPath: /usr/local/bin/python3
name: empty-dir
subPath: python3
To Reproduce
- Have kubernetes cluster with tight restrictions on container and pod persmissions, enforcing dropping all capabilities (
securityContext.capabilities.drop: ["ALL"]).
- Try to reproduce the helm chart from this repo as published in version
9.11.0 at oci://docker.io/dpage/pgadmin4-helm.
- It gets stuck in a crash loop backoff.
Expected behavior
It should work instead of crashing even if it's not allowed to use the net bind capabilities to listen to low ports.
Error message
In the pgadmin4 container logs:
/entrypoint.sh: line 174: /venv/bin/python3: Operation not permitted
/entrypoint.sh: /venv/bin/gunicorn: /venv/bin/python3: bad interpreter: Operation not permitted
In the unset-python3-cli-net-cap container logs:
+ sort -V -r
+ xargs -i cp '{}' python3
+ head -n 1
+ ls '/usr/bin/python3.*'
ls: /usr/bin/python3.*: No such file or directory
Screenshots
Not applicable.
Desktop (please complete the following information):
Additional context
None yet.
Describe the bug
When deploying pgadmin4 to Kubernetes using version
9.11.0of the helm chart published tooci://docker.io/dpage/pgadmin4-helm, it doesn't start, because the pod is in a crash loop backoff. The error/entrypoint.sh: line 174: /venv/bin/python3: Operation not permittedappears to come from the same reason as in issue 6694:#6694
Looking at the
unset-python3-cli-net-capinit container which tries to alleviate the issue, it appears to fail because it cannot find a python binary in/usr/bin/in the container. Looking in/venv/bin/in the container, it appears thatpython3symlinks to/usr/local/bin/python3, which does exist.However, updating line 208 in the deployment.yaml (https://github.com/pgadmin-org/pgadmin4/blob/master/pkg/helm/templates/deployment.yaml#L208), to point to the python at
/usr/local/bin/python3, doesn't appear to fix the issue.Curiously, updating the line to point to the python symlink in the
/venv/bin/folder, like shown below, does appear to fix the issue:Edit:
The mount at line 134 in the deployment (https://github.com/pgadmin-org/pgadmin4/blob/master/pkg/helm/templates/deployment.yaml#L134) also had to be updated to point to the symlinked
/usr/local/bin/instead of/usr/bin/, like shown below:To Reproduce
securityContext.capabilities.drop: ["ALL"]).9.11.0atoci://docker.io/dpage/pgadmin4-helm.Expected behavior
It should work instead of crashing even if it's not allowed to use the net bind capabilities to listen to low ports.
Error message
In the
pgadmin4container logs:In the
unset-python3-cli-net-capcontainer logs:Screenshots
Not applicable.
Desktop (please complete the following information):
9.11.0Additional context
None yet.