kubeadm을 사용하여 단일 노드 서버에 kubernetes를 설치했습니다. 특정 순서에 따라 설치를 수행하면 모든 것이 제대로 시작되고 실행된다는 것을 알았습니다. 여기에는 먼저 실행되어 실행된 주요 kube 시스템 구성 요소(api 서버, 프록시, 스케줄러, etcd 등)가 포함됩니다(coredns 제외). 그 후 네트워킹용 helm을 사용하여 cilium CNI 플러그인이 설치되었습니다(결과적으로 coredns 작동).
이 설치 후에는 NVIDIA의 GPU 운영자 및 kubeflow와 같은 다른 서비스를 성공적으로 설치하고 사용할 수 있었습니다. 그러나 재부팅을 수행한 후 다른 구성 요소가 충돌 루프 백오프 상태로 들어가는 것을 발견했습니다.
나는 이것이 다양한 리소스가 초기화되는 순서와 다양한 시간 초과의 길이와 관련이 있다고 생각합니다. 부팅 시 다른 구성 요소가 시작되도록 순서를 설정하는 방법이 있습니까? 아니면 적절한 기본 시간 제한이나 포드의 충돌 동작을 구성할 수 있나요?
한 구성 요소가 충돌하면 다른 구성 요소가 충돌하여 백오프 시간이 계속 증가하고 궁극적으로 클러스터가 응답하지 않는 도미노 효과가 발생할 수 있습니다.
추가 정보를 위해 iptables 규칙을 유지하여 부팅 시 적용되도록 했습니다. 또한 일반적으로 크래시 루프 백오프 상태를 유지하는 kube 스케줄러를 제외하고 모든 주요 구성 요소가 실행 상태로 전환됩니다. 그런 다음 다른 구성 요소도 도미노 효과처럼 충돌하기 시작합니다.
지금까지 kubernetes 시스템 포드에 대해 다양한 시간 초과 및 failureThresholds를 사용하기 위해 주로 /etc/kubernetes/manifests/ 아래의 매니페스트 파일을 업데이트하려고 시도했지만 문제가 해결되지 않은 것 같습니다. 먼저 kubelet 서비스를 중지하고 실행 중인 모든 포드/컨테이너를 삭제한 다음 kubelet을 다시 시작하여 서버 다시 시작 동작을 복제할 수 있습니다.
답변1
이 문제는 이 GitHub에 설명된 문제와 매우 유사하다는 것이 밝혀졌습니다.문제. 본질적으로 지정하지 않고SystemdCgroup = true (이는nvidia컨테이너 런타임) 의 기본값이 아닌 runc포드는 설명할 수 없을 정도로 계속 충돌할 것입니다. 이는 cgroup 관리를 위한 기본 드라이버가 cgroupfs상호 운용할 수 없기 때문에 cgroup의 단일 작성자 규칙 위반으로 인해 발생했습니다.systemd . 당신은 볼 수 있습니다선적 서류 비치자세한 내용은. 또한 CRI 플러그인 구성의 전체 사양도 포함되어 있습니다.여기.
기타 관련 컨테이너 리소스는 다음과 같습니다.