-
Notifications
You must be signed in to change notification settings - Fork 359
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
CI jobs for AKS & EKS are failing #1572
Comments
triggered a manual run and saw this in sonobuoy logs:
|
Re-opening as the tests are still failing on both AKS & EKS. |
One finding is that the EKS CNI introspection API is no longer available, so the https://github.com/vmware-tanzu/antrea/blob/master/build/yamls/antrea-eks-node-init.yml script is broken. We can use the contents of
See awslabs/amazon-eks-ami#487 I will address this first |
Second issue is that AntreaProxy is not enabled for policyOnlyMode: https://github.com/vmware-tanzu/antrea/blob/3db240dab7a758f0199ada0eb333b0cf8fb442f2/cmd/antrea-agent/agent.go#L185-L192 In that mode |
policyOnlyMode was broken since adding support for IPv6 clusters in the code base. This is because the code used the Node's PodCIDR(s) to determine which address family was supported, which doesn't work in policyOnlyMode, for which IPAM is not the responsibility of Antrea. Instead we now use the following rules: * if there is an IPv4 PodCIDR for the Node, then v4 is supported * otherwise, if policyOnlyMode is used and the Node's IP address (primary, as reported by K8s) is an IPv4 address then v4 is supported Same rules for v6. This may not work for dual-stack, but IIRC none of the cloud services support IPv6 / dual-stack. There are also other issues for dual-stack support in Antrea, which themselves depend on upstream issues. Additionally, we include the following changes: * the build/yamls/antrea-eks-node-init.yml manifest is updated to account for a breaking change in the AWS CNI introspection API. * we pin the K8s conformance test image for all clouds to v1.18.5 to avoid issues with recently-added conformance tests. Fixes antrea-io#1572
policyOnlyMode was broken since adding support for IPv6 clusters in the code base. This is because the code used the Node's PodCIDR(s) to determine which address family was supported, which doesn't work in policyOnlyMode, for which IPAM is not the responsibility of Antrea. Instead we now use the following rules: * if there is an IPv4 PodCIDR for the Node, then v4 is supported * otherwise, if policyOnlyMode is used and the Node's IP address (primary, as reported by K8s) is an IPv4 address then v4 is supported Same rules for v6. This may not work for dual-stack, but IIRC none of the cloud services support IPv6 / dual-stack. There are also other issues for dual-stack support in Antrea, which themselves depend on upstream issues. Additionally, we include the following changes: * the build/yamls/antrea-eks-node-init.yml manifest is updated to account for a breaking change in the AWS CNI introspection API. * we pin the K8s conformance test image for all clouds to v1.18.5 to avoid issues with recently-added conformance tests. Fixes antrea-io#1572
policyOnlyMode was broken since adding support for IPv6 clusters in the code base. This is because the code used the Node's PodCIDR(s) to determine which address family was supported, which doesn't work in policyOnlyMode, for which IPAM is not the responsibility of Antrea. Instead we now use the following rules: * if there is an IPv4 PodCIDR for the Node, then v4 is supported * otherwise, if policyOnlyMode is used and the Node's IP address (primary, as reported by K8s) is an IPv4 address then v4 is supported Same rules for v6. This may not work for dual-stack, but IIRC none of the cloud services support IPv6 / dual-stack. There are also other issues for dual-stack support in Antrea, which themselves depend on upstream issues. Additionally, we include the following changes: * the build/yamls/antrea-eks-node-init.yml manifest is updated to account for a breaking change in the AWS CNI introspection API. * we pin the K8s conformance test image for all clouds to v1.18.5 to avoid issues with recently-added conformance tests. Fixes antrea-io#1572
policyOnlyMode was broken since adding support for IPv6 clusters in the code base. This is because the code used the Node's PodCIDR(s) to determine which address family was supported, which doesn't work in policyOnlyMode, for which IPAM is not the responsibility of Antrea. Instead we now use the following rules: * if there is an IPv4 PodCIDR for the Node, then v4 is supported * otherwise, if policyOnlyMode is used and the Node's IP address (primary, as reported by K8s) is an IPv4 address then v4 is supported Same rules for v6. This may not work for dual-stack, but IIRC none of the cloud services support IPv6 / dual-stack. There are also other issues for dual-stack support in Antrea, which themselves depend on upstream issues. Additionally, we include the following changes: * the build/yamls/antrea-eks-node-init.yml manifest is updated to account for a breaking change in the AWS CNI introspection API. * we pin the K8s conformance test image for all clouds to v1.18.5 to avoid issues with recently-added conformance tests. Fixes #1572
policyOnlyMode was broken since adding support for IPv6 clusters in the code base. This is because the code used the Node's PodCIDR(s) to determine which address family was supported, which doesn't work in policyOnlyMode, for which IPAM is not the responsibility of Antrea. Instead we now use the following rules: * if there is an IPv4 PodCIDR for the Node, then v4 is supported * otherwise, if policyOnlyMode is used and the Node's IP address (primary, as reported by K8s) is an IPv4 address then v4 is supported Same rules for v6. This may not work for dual-stack, but IIRC none of the cloud services support IPv6 / dual-stack. There are also other issues for dual-stack support in Antrea, which themselves depend on upstream issues. Additionally, we include the following changes: * the build/yamls/antrea-eks-node-init.yml manifest is updated to account for a breaking change in the AWS CNI introspection API. * we pin the K8s conformance test image for all clouds to v1.18.5 to avoid issues with recently-added conformance tests. Fixes antrea-io#1572
policyOnlyMode was broken since adding support for IPv6 clusters in the code base. This is because the code used the Node's PodCIDR(s) to determine which address family was supported, which doesn't work in policyOnlyMode, for which IPAM is not the responsibility of Antrea. Instead we now use the following rules: * if there is an IPv4 PodCIDR for the Node, then v4 is supported * otherwise, if policyOnlyMode is used and the Node's IP address (primary, as reported by K8s) is an IPv4 address then v4 is supported Same rules for v6. This may not work for dual-stack, but IIRC none of the cloud services support IPv6 / dual-stack. There are also other issues for dual-stack support in Antrea, which themselves depend on upstream issues. Additionally, we include the following changes: * the build/yamls/antrea-eks-node-init.yml manifest is updated to account for a breaking change in the AWS CNI introspection API. * we pin the K8s conformance test image for all clouds to v1.18.5 to avoid issues with recently-added conformance tests. Fixes #1572
policyOnlyMode was broken since adding support for IPv6 clusters in the code base. This is because the code used the Node's PodCIDR(s) to determine which address family was supported, which doesn't work in policyOnlyMode, for which IPAM is not the responsibility of Antrea. Instead we now use the following rules: * if there is an IPv4 PodCIDR for the Node, then v4 is supported * otherwise, if policyOnlyMode is used and the Node's IP address (primary, as reported by K8s) is an IPv4 address then v4 is supported Same rules for v6. This may not work for dual-stack, but IIRC none of the cloud services support IPv6 / dual-stack. There are also other issues for dual-stack support in Antrea, which themselves depend on upstream issues. Additionally, we include the following changes: * the build/yamls/antrea-eks-node-init.yml manifest is updated to account for a breaking change in the AWS CNI introspection API. * we pin the K8s conformance test image for all clouds to v1.18.5 to avoid issues with recently-added conformance tests. Fixes #1572
Describe the bug
They have been failing for about a week:
Creating a single issue because even though I have not investigated the failures, the jobs started failing at the same time, so it is likely that it is the same root cause.
Versions:
The text was updated successfully, but these errors were encountered: