Can not delete namespaces

[jsalatiel]

I can not delete namespaces.
Get:

  - lastTransitionTime: "2022-05-22T22:08:54Z"
    message: 'Discovery failed for some groups, 3 failing: unable to retrieve the
      complete list of server APIs: controlplane.antrea.io/v1beta2: the server is
      currently unable to handle the request, stats.antrea.io/v1alpha1: the server
      is currently unable to handle the request, system.antrea.io/v1beta1: the server
      is currently unable to handle the request'
    reason: DiscoveryFailed

To Reproduce
Antrea 1.6.1 on EKS

Expected
The namespace should be deleted.

Actual behavior
The namespace will be forever on terminating state.

Versions:

• Antrea version (Docker image tag). 1.6.1
• Kubernetes version (use kubectl version). v1.22.6-eks-14c7a48

I have a default DROP netpolicy, but kube-system can talk to Self and to control-plane and kubelets node IPs. I see no traffic being dropped from the controller to the api.
Anyways, I disabled the default DROP netpolicy and still it does not work.

[antoninbas]

This error means that the K8s control plane cannot communicate with the Antrea (Controller) API. This is independent of network policies given that the antrea-controller Pod is a hostNetwork Pod. Do you have any VPC security group rules denying such connections?

[jsalatiel]

No, I have not.
I have deleted the controller pod and after it was rescheduled by k8s(at the same node btw) the deletion worked. Is there a proactive way to detect when this problem happens? What other problems can i face if the control plane can not take to antrea controller(I am supposing this is the problem )?

[antoninbas]

Antrea uses K8s aggregated APIs to expose some Antrea Controller APIs through the K8s apiserver. Some functions in antctl depend on that.

In K8s, if any API (including aggregated APIs) is not reachable, it prevents Namespace deletion.

I don't know why you get in a situation where these APIs are not accessible since communication between the K8s control plane and the Antrea Controller doesn't depend on Pod networking. But you can check the status for these apiservices with kubectl get apiservices.

And if you run kubectl get endpoints/antrea -n kube-system, it will show you the address that the K8s control plane should be using to access the API.

[jsalatiel]

Closing this. Probably related to #3946