You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The first issue is because of racing condition. As the ServiceAccount was created later than DaemonSet, it would cause this:
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedCreate 19s (x2 over 19s) daemonset-controller Error creating: pods "filebeat-dynamic-" is forbidden: error looking up service account kube-system/filebeat-dynamic: serviceaccount "filebeat-dynamic" not found
Normal SuccessfulCreate 18s daemonset-controller Created pod: filebeat-dynamic-7l58b
Normal SuccessfulCreate 18s daemonset-controller Created pod: filebeat-dynamic-wkp6s
Normal SuccessfulCreate 18s daemonset-controller Created pod: filebeat-dynamic-sms98
So shifting the SA and RB to top helps.
The second issue is that the demo has an implicit assumption: the CRI MUST be Docker. While using CRI-O, it would cause errors and come into CrashLoopBackOff.
2019-10-11T02:14:42.177Z INFO instance/beat.go:359 filebeat stopped.
2019-10-11T02:14:42.177Z ERROR instance/beat.go:906 Exiting: error initializing publisher: error initializing processors: Cannot connect
to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
Exiting: error initializing publisher: error initializing processors: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the doc
ker daemon running?
The text was updated successfully, but these errors were encountered:
Thanks @brightzheng100 I will have a look. I have not seen the race condition, and I have only used Docker based deployments. Do you have a fix for CRI-O based systems? I would expect the k8s layer to abstract away the underlying container provider.
The first issue is because of racing condition. As the ServiceAccount was created later than DaemonSet, it would cause this:
So shifting the SA and RB to top helps.
The second issue is that the demo has an implicit assumption: the CRI MUST be Docker. While using CRI-O, it would cause errors and come into
CrashLoopBackOff
.The text was updated successfully, but these errors were encountered: