Senthil Kumaran

@cyberox - would you like to use these changes in your terraform config https://github.com/aws/amazon-vpc-cni-k8s/pull/2969 and see if the terraform behavior is fixed?

This is addressed in https://github.com/aws/amazon-vpc-cni-k8s/releases/tag/v1.18.3

> The general question is should a node be unready until aws-node is up and running? The node should be marked as Not Ready, until aws-node pod copies the configuration...

> 1.NotReady>2.Ready>3.NotReady>4.Ready pods are getting scheduled and stuck between 2. and 3. This is strange. Do you have any logs that indicate why the node is getting marked as NotReady...

> I think the documentation should be updated to make clear that external SNAT and standard mode are required when using Pod Identities with SGPP. Yes, this will be the...

When `POD_SECURITY_GROUP_ENFORCING_MODE` is set to strict, we either ignore link-local addresses or provide an option to ignore `link-local` addresses. This can address the issue here.

Were there any services running that could cause the application pods not to be deleted? Were the application pods deleted properly?

The flag `https://github.com/aws/aws-network-policy-agent/blob/main/pkg/config/controller_config.go#L10` is configurable via --log-file. It looks like we aren't exposing this in the helm chart here - https://github.com/aws/amazon-vpc-cni-k8s/tree/master/charts/aws-vpc-cni This needs to be added.

This PR will resolve this - https://github.com/aws/amazon-vpc-cni-k8s/pull/2925

Does VPC CNI (aws-node pod) ever get into a ready state? Are you using k3s on a EC2 instance? Could you explain how did you setup your EC2 instances, and...