Hi Eugen, Thanks. We actually don’t have any proxy configured. But it is a good advise to check networking. And thanks for the open files hint. Will check it out. Cheers, Oliver Von meinem iPhone gesendet
Am 14.04.2025 um 13:35 schrieb Eugen Block <eblock@nde.ag>:
Hi,
dial tcp 172.xxx.xxx.xxx:5000: i/o timeout
Everytime I encounter this error, I either forgot to set proper http(s)_proxy and no_proxy variables or misconfigured them.
However, when I manually test connectivity to the Keystone API from the master node, it appears to work fine:
Did you test that from within the pods as well?
As for the "too many open files" error, you could try this approach:
https://kind.sigs.k8s.io/docs/user/known-issues/#pod-errors-due-to-too-many-...
Zitat von Oliver Weinmann <oliver.weinmann@me.com>:
Hi all,
We’re running a Kolla-Ansible 2023.2 deployment with Magnum. While we primarily use CAPI, we also have some older Kubernetes 1.21.11 clusters. In these clusters, we’re encountering two specific issues:
Random Crashes of openstack-cloud-controller-manager Pod In one of the older clusters, the openstack-cloud-controller-manager pod is crashing intermittently with the following error: F0410 12:02:45.673777 1 main.go:84] Cloud provider could not be initialized: could not init cloud provider "openstack": Post "http://openstack.xxxxxxx:5000/v3/auth/tokens": dial tcp 172.xxx.xxx.xxx:5000: i/o timeout However, when I manually test connectivity to the Keystone API from the master node, it appears to work fine:
while true; do status=$(curl -s -o /dev/null -w "%{http_code}" http://172.xxx.xxx.xxx:5000/v3 2>/dev/null) || status="failed" echo "$(date): Keystone API status: $status" sleep 10 done Sample output:
Thu Apr 10 19:19:50 UTC 2025: Keystone API status: 200 Thu Apr 10 19:20:00 UTC 2025: Keystone API status: 200 Thu Apr 10 19:20:10 UTC 2025: Keystone API status: 200 ... Despite the API being reachable, the pod continues to crash sporadically with the timeout error.
"Too Many Open Files" Error in Pods Users running pods in these clusters are reporting frequent "Too many open files" errors. Since Kubernetes 1.21.11 relies on CoreOS, I’m looking for a way to permanently increase the maximum number of open file descriptors on CoreOS. Any guidance or suggestions on how to address these issues would be greatly appreciated!
Best regards, Oliver