Check tlsSecretName values in README

should be possible to enable ipv6 (even without using it) on network layer to check if this is really the issue?

I suggest to exec into the pod and issue the command kubectl delete pod -l=CLEARML=agent-74b23a8f --namespace=clearml --field-selector=status.phase!=Pending,status.phase!=Running --output name
sp you can see the ouput from inside the pod. This should help understand what is going on with the command

it will be easier for me to reproduce

this is basic k8s management that is not strictly related this chart. my suggestion is to have a default storageclass that will be able to provide the right pv/pvc for any deployment you are going to have on the cluster. I suggest to start from here: https://kubernetes.io/docs/concepts/storage/storage-classes/

Can you pls share helm list output?

Also k8s distribution and version you are using can be useful

happy to hear that

just my two cents

try this into the pod

# Point to the internal API server hostname APISERVER= `

Path to ServiceAccount token

SERVICEACCOUNT=/var/run/secrets/kubernetes.io/serviceaccount

Read this Pod's namespace

NAMESPACE=$(cat ${SERVICEACCOUNT}/namespace)

Read the ServiceAccount bearer token

TOKEN=$(cat ${SERVICEACCOUNT}/token)

Reference the internal certificate authority (CA)

CACERT=${SERVICEACCOUNT}/ca.crt

Explore the API with TOKEN

curl --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}" -X GET ${A...

I’m guessing if I can set it trough Helm chart by default, will investigate by the end of the week, ty ScrawnyLion96 to point me on this interesting behavior!

from https://kubernetes.io/docs/tasks/run-application/access-api-from-pod/

additionaConfigs is a section under apiserver

btw it’s an infra issue

not totally sure tbh

I don’t think it’s related how agent talk with apiserver or fileserver. It’s more related the fact agent pod internal kubectl cannot contact kubernetes apiserver

additionalConfigs: auth.conf: | auth { # Fixed users login credentials # No other user will be able to login fixed_users { enabled: true pass_hashed: false users: [ { username: "jane" password: "12345678" name: "Jane Doe" }, { username: "john" password: "12345678" name: "John Doe" }, ] } }

it looks not from logs

If I'm not wrong you can simply label the namespace to avoid istio to get there

you need to investigate why it’s still in Pending state

ok so they are executed as expected

Did you use any override values.yaml file for this installation ?

I didn’t get the point, if you need to change it, you can just override image name and tag by Helm

With Helm we are not running in service-mode. If pod get evicted or killed we should investigate what is the reason behind that; there are any logs on kille dpod that can help us understand better the situation?

did you tried to create a debug pod with a mount using ceph storageclass? you can start from here https://downey.io/notes/dev/ubuntu-sleep-pod-yaml/ then add the pvc and the mount. then you should exec into the pod and try to write a dummy file on the mount; I suspect the problem is there

really weird, can you try to totally remove any cookie domain related?

so do you want to mount files into agent pod?

moreover url exposed by nginx should be under https

accessing apiserver from a pod doesn’t require kubeconfig