Siyao Meng created HDDS-17347:
---------------------------------
Summary: Kubernetes check fails with permission denied on k3s.yaml
after k3s restart
Key: HDDS-17347
URL: https://issues.apache.org/jira/browse/HDDS-17347
Project: Apache Ozone
Issue Type: Sub-task
Components: build, test
Reporter: Siyao Meng
Assignee: Siyao Meng
The kubernetes (minikube) check failed on master before any test ran. k3s
started and accepted the resources, then its API server went away a few seconds
later. After that every kubectl call failed because the kubeconfig was no
longer readable:
{noformat}
2026-10-22T11:34:48.1094281Z **** Waiting until the k8s cluster is running ****
2026-10-22T11:34:51.4633905Z The connection to the server 127.0.0.1:6443 was
refused - did you specify the right host or port?
2026-10-22T11:34:54.5871826Z The connection to the server 127.0.0.1:6443 was
refused - did you specify the right host or port?
2026-10-22T11:34:57.6979829Z error: error loading config file
"/etc/rancher/k3s/k3s.yaml": open /etc/rancher/k3s/k3s.yaml: permission denied
...
ERROR: Test execution of minikube is FAILED!!!!
{noformat}
h3. Root cause
{{hadoop-ozone/dev-support/checks/install/k3s.sh}} makes the kubeconfig
readable with a one time {{sudo chmod a+r $KUBECONFIG}} after installation. k3s
rewrites {{/etc/rancher/k3s/k3s.yaml}} with mode 0600 every time the server
starts, so when k3s restarted during the test the chmod was undone and the wait
loop could no longer reach the cluster, even if k3s recovered. The reason for
the k3s restart is not visible in the CI logs.
h3. Fix
Pass {{K3S_KUBECONFIG_MODE=644}} to the k3s installer, so k3s itself writes the
kubeconfig readable on every start.
- https://github.com/apache/ozone/actions/runs/39769621690/job/119799870186
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
