Update kubelet.service

[rfox-godaddy]

Issue #, if available:

Description of changes:
If kubelet wins the systemd startup race against iptables, then the
ExecStartPre=/sbin/iptables -P FORWARD ACCEPT -w 5 may be clobbered by existing rules.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[GnatorX]

To add more context both https://github.com/awslabs/amazon-eks-ami/blob/master/files/iptables-restore.service#L5 and https://github.com/awslabs/amazon-eks-ami/blob/master/files/kubelet.service#L4 happens at after docker.service. The problem we ran into is that we perform an iptable save as part of our custom AMI. This means that on node startup there is a race between kubelet and iprestore. If kubelet runs first then FORWARD ACCEPT gets clobbered by iprestore. This proposed change will ensure iprestore happens before kubelet to ensure FORWARD ACCEPT will always be applied regardless of what is saved in iptables.

[jacknagel]

We've been impacted by this as well. In fact, if you follow the official instructions for blocking access to IMDS from pods (https://docs.aws.amazon.com/eks/latest/userguide/restrict-ec2-credential-access.html), you end up in this exact situation, where iptables-restore can clobber the kubelet's FORWARD ACCEPT. Now that we understand the issue, we've worked around it, but it would be nice to see this merged.