Comment 9 for bug 2012689

Highlighting the most relevant logs from comment #7. Snapd fails to start the kubelet-eks.daemon service:

Apr 19 16:23:02 ip-*-*-*-* snapd[862]: taskrunner.go:289: [change 12 "Run service command \"start\" for services [\"daemon\"] of snap \"kubelet-eks\"" task] failed: systemctl command [start snap.kubelet-eks.daemon.service] failed with exit status 1: Job for snap.kubelet-eks.daemon.service failed because the control process exited with error code.

And matching that timestamp up with the kubelet-eks.daemon logs:

Apr 19 16:23:02 ip-*-*-*-* systemd[1]: snap.kubelet-eks.daemon.service: Start request repeated too quickly.
Apr 19 16:23:02 ip-*-*-*-* systemd[1]: snap.kubelet-eks.daemon.service: Failed with result 'exit-code'.
Apr 19 16:23:02 ip-*-*-*-* systemd[1]: Failed to start Service for snap application kubelet-eks.daemon.

I think it goes like this: The kubelet-eks snap is initially installed, but hasn't been configured. During this time the service repeatedly crashes because it's missing important configuration. It hits the systemd start rate limit, at which point systemd blocks further start attempts. Later, bootstrap.sh runs `snap set ...` to configure the service, and `snap start kubelet-eks` to start it. The start attempt fails because the service is still being start rate limited by systemd.