-
Notifications
You must be signed in to change notification settings - Fork 54
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to create static mirror pods due to mpod.vpc.k8s.aws
Admission Webhook
#351
Comments
mpod.vpc.k8s.aws
Admission Webhook
@jonathan-innis , yes, the webhook is assuming all pods are not static pods and should be assigned with a Service Account. As discussed offline, so far we are not seeing an use case which need create static pods in production. We will investigate if SA check is ignore-able from supported feature point of view (Security Group for Pods), and/or in more general point of view. I will update later. |
We've seen this ask for Karpenter with Airflow: kubernetes-sigs/karpenter#863. Granted, this is one data point, but it seems like some asks do exist for creating static pods that aren't control plane pods.
Definitely seems like you could just ignore the get of the SA if you don't find one attached to the pod. I would imagine that you should be able to enforce Security Groups for Pods like you would with any other pod since I would expect that the network traffic would be routed to the static pod like any other pod on the cluster. |
If this is regarding static pods to use Security Group for Pods, this is not a case we were supporting or testing. Who sets up the networking for static pods?
At this moment I am not certain if the webhook can safely assume No SA assigned pods are guaranteed being static pods. Since the feature supports pod labels and sa labels, we have to be certain ignoring SA is ok in all cases. |
This is something I'm not 100% sure on. I'm assuming the CNI, as with every other pod component, but I'll double-check that in the community Slack. I'm working off that assumption only because there's no callout in the static pod docs that mentions otherwise.
I don't even think that you have to guarantee that they are static pods. From what I can understand, you can build a SecurityGroupPolicy off of selectors on either the pods or the service account. Naturally, I would assume that if a pod doesn't reference a service account (for whatever reason) a service account selector just wouldn't apply to it. |
Confirmed that it's CNI like any other pod on the cluster: https://kubernetes.slack.com/archives/C09NXKJKA/p1704164272715389 |
Thanks for checking. It makes sense to me that static pods' networking are setup by the same path. I have no problem to remove the forced SA check on pods. Just want to call out this can be a behavior change although I think it is unlikely customers are relying on this check to avoid apply SGP to some of their pods. |
Jump into the thread as I found the same issue recently. Testing Environment:
I found that if user tried to follow the guidance of Static Pod creation, it would failed unexpectedly. Steps to reproduce the issue (execute inside EKS node with "root")
|
Describe the Bug:
I am trying to create a static mirror pod on a node that is running AL2 and is connecting to an EKS control plane. When I point the kubelet to the
staticPodPath
, I get the following error message in the kubelet on startupDigging deeper into why this happened, I see that this error log gets fired here: https://github.com/aws/amazon-vpc-resource-controller-k8s/blob/master/webhooks/core/pod_webhook.go#L188. Looking at the GetMatchingSecurityGroupForPods() function, I can see that this will error out and cause denial in the webhook when the webhook is unable to find the service account for the pod. Since the service account for the pod doesn't exist for static pods, I'm suspecting that the lack of the ability for looking up the unspecified service account here is causing failure on pod creation.
From reading through this issue, static pods implicitly don't rely on any API objects since they can't assume that the apiserver even exists when they come up. It seems like the webhook here makes an assumption that these service account names always exist in pods, which seems to be true almost all of the time, except in the case of static pods.
Expected Behavior:
Static pods should be able to create an apiserver representation of themselves without any failure.
How to reproduce it (as minimally and precisely as possible):
journalctl -u kubelet
after SSM-ing into the node to see failures creating the static pods.Additional Context:
As a workaround right now, I'm just having to disable the mutating webhook with
kubectl delete mutatingwebhookconfiguration vpc-resource-mutating-webhook
to unblock me from creating static pods.Environment:
kubectl version
):v1.28.4-eks-8cb36c9
v1.12.5-eksbuild.2
The text was updated successfully, but these errors were encountered: