vsphere-csi-controller не запускается из-за «неверного адреса памяти или разыменования нулевого указателя» - PullRequest
Новая
       10

vsphere-csi-controller не запускается из-за «неверного адреса памяти или разыменования нулевого указателя»

0 голосов
/ 27 января 2020

Я устанавливаю k8s и vsphere CPI / CSI, следуя инструкциям, расположенным здесь

Моя установка: 2x centos 7.7 vSphere VM (50g HD / 16G RAM), 1 мастер и 1 узел в кластере k8s.

Сделано в той части, где я создаю storageClass (ближе к концу), когда я обнаружил эту проблему github точно. ОП связанной проблемы только начался с нуля, и их проблема ушла, поэтому отчет был закрыт. Это было не так для меня, так как я несколько раз переустанавливал свой кластер k8s с нуля и всегда попадал в эту стену. Ниже приведена ошибка, если вы не хотите проверять проблему с github.

У кого-нибудь есть идеи о том, что я могу попытаться преодолеть? Я проверил свои HD и RAM и много там. 

# kubectl -n kube-system logs pod/vsphere-csi-controller-0 vsphere-csi-controller
I0127 18:49:43.292667       1 config.go:261] GetCnsconfig called with cfgPath: /etc/cloud/csi-vsphere.conf
I0127 18:49:43.292859       1 config.go:206] Initializing vc server 132.250.31.180
I0127 18:49:43.292867       1 controller.go:67] Initializing CNS controller
I0127 18:49:43.292884       1 virtualcentermanager.go:63] Initializing defaultVirtualCenterManager...
I0127 18:49:43.292892       1 virtualcentermanager.go:65] Successfully initialized defaultVirtualCenterManager
I0127 18:49:43.292905       1 virtualcentermanager.go:107] Successfully registered VC "132.250.31.180"
I0127 18:49:43.292913       1 manager.go:60] Initializing volume.volumeManager...
I0127 18:49:43.292917       1 manager.go:64] volume.volumeManager initialized
time="2020-01-27T18:50:03Z" level=info msg="received signal; shutting down" signal=terminated
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x128 pc=0x867dc7]

goroutine 10 [running]:
google.golang.org/grpc.(*Server).GracefulStop(0x0)
        /go/pkg/mod/google.golang.org/grpc@v1.23.0/server.go:1393 +0x37
github.com/rexray/gocsi.(*StoragePlugin).GracefulStop.func1()
        /go/pkg/mod/github.com/rexray/gocsi@v1.0.0/gocsi.go:333 +0x35
sync.(*Once).Do(0xc0002cc8fc, 0xc000380ef8)
        /usr/local/go/src/sync/once.go:44 +0xb3
github.com/rexray/gocsi.(*StoragePlugin).GracefulStop(0xc0002cc870, 0x21183a0, 0xc000056018)
        /go/pkg/mod/github.com/rexray/gocsi@v1.0.0/gocsi.go:332 +0x56
github.com/rexray/gocsi.Run.func3()
        /go/pkg/mod/github.com/rexray/gocsi@v1.0.0/gocsi.go:121 +0x4e
github.com/rexray/gocsi.trapSignals.func1(0xc00052a240, 0xc000426990, 0xc000426900)
        /go/pkg/mod/github.com/rexray/gocsi@v1.0.0/gocsi.go:502 +0x143
created by github.com/rexray/gocsi.trapSignals
        /go/pkg/mod/github.com/rexray/gocsi@v1.0.0/gocsi.go:487 +0x107

1 Ответ

1 голос
/ 31 марта 2020

Хорошо, выясняется, что этот SIGSEGV был ошибкой или чем-то другим, и он был вызван сетевым таймаутом, из-за чего эта ошибка была похожа на красную сельдь.

Детали: Мой модуль vsphere-csi-controller-0 был ( и до сих пор не может достичь сервера vsphere, что вызвало таймаут для контейнера в модуле и инициирует эту ошибку SIGSEV. Вкладчики CSI обновили некоторые библиотеки, и ошибка теперь устранена, но время ожидания остается. Тайм-аут, похоже, является моей проблемой и не связан с CSI, но это новый вопрос :)

Если вы хотите узнать подробности того, что было исправлено в CSI, проверьте ссылку github в вопросе.

...