Toolbox: 도구 상자 33에서 kubectl을 사용할 때 연결이 거부되었습니다.

Silverblue를 버전 32에서 버전 33으로 업데이트한 후에도 동일한 문제가 발생했습니다.

해결 방법은 도구 상자 컨테이너의 /etc/resolv.conf 에 있는 심볼릭 링크를 resolv.conf 호스트로 바꾸는 것입니다.

sudo rm /etc/resolv.conf && sudo cp /run/host/etc/resolv.conf /etc

그 후 아무 문제 없이 kubectl get pods 를 실행할 수 있습니다.

이 변경 이전에는 /etc/resolv.conf 가 ../run/systemd/resolve/stub-resolv.conf (존재하지 않음)를 가리켰습니다.
사용자 정의 /etc/resolv.conf 재부팅한 후 호스트 resolv.conf 파일에 대한 심볼릭 링크로 대체되었습니다: /run/host/etc/resolv.conf .
kubectl 도 새 심볼릭 링크와 함께 작동하는 것으로 보입니다.

@fedgiac 감사합니다! 정말 그랬다.

처음에 왜 이런 일이 일어났는지 궁금합니다. 여기에 올바른 심볼릭 링크가 설정되어 있어야 합니다.
https://github.com/containers/toolbox/blob/18e3955fc0f7bedb7b95f4bb4d6f19be65011147/toolbox#L1206

원래 /etc/resolv.conf 도 심볼릭 링크였으므로 ! readlink /etc/resolv.conf 항상 성공했으며 이 시점에서 링크가 업데이트되지 않았습니다. 이 파일을 다른 심볼릭 링크로 교체하면 이 파일을 재부팅 시 안정적으로 만들 수 있습니다.

문제의 일부는 원래 /etc/resolv.conf 가 _relative_ 심볼릭 링크였기 때문에 적절한 호스트 경로 교체를 거치지 않았다는 것 입니다. 코드 에서 주제에 대한 주석

나는 당신이 이것을 알아낼 수 있었다는 것을 기쁘게 생각합니다!

이 작업을 더 진행하려는 경우 도움이 될 수 있는 몇 가지 지침이 있습니다.

우선, POSIX 셸 구현이 아닌 /usr/bin/toolbox 의 Go 구현을 사용하고 있는지 확인하십시오. :)

컨테이너의 /etc/resolv.conf 는 호스트 운영 체제가 /etc/resolv.conf 를 관리하기 위해 systemd-resolved 또는 다른 메커니즘을 사용하는지 여부에 관계없이 일반적으로 /run/host/etc/resolv.conf 대한 심볼릭 링크여야 합니다.

호스트 운영 체제가 systemd-resolved를 사용하는 경우 호스트의 /etc/resolv.conf 는 ../run/systemd/resolve/stub-resolv.conf 와 같은 상대 심볼 링크여야 합니다.

마지막으로 호스트의 /etc 는 컨테이너 내부의 /run/host/etc 에서 사용할 수 있어야 합니다.

닫습니다. 새로 추가할 사항이 있으면 언제든지 다시 열거나 의견을 남겨주세요.