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
Support Calico CNI for ambient #40973
Comments
Thanks @howardjohn who pointed to me this is due to Calico CNI will revert IPtable rules. |
@dhawton, is there any detail or status update for supporting either calico or other bridging CNI plugin rather than kind CNI? Any materials or information could be shared will be appreciated. |
Not at this point. We do support the CNIs in GKE (non-Calico and non-DPv2) and EKS... but I do not have anything more I can share at this moment. |
I saw note that GKE with Calico does not work. I believe the default is deployment is with calico. Is there an alternative that should be used in Dev to test ambient with? |
The default isn't calico unless you enable network policy when creating the
cluster. If you just use the defaults in the UI it will work
…On Fri, Nov 25, 2022, 8:27 AM Daniel Wayne ***@***.***> wrote:
I saw note that GKE with Calico does not work. I believe the default is
deployment is with calico. Is there an alternative that should be used in
Dev to test ambient with?
—
Reply to this email directly, view it on GitHub
<#40973 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEYGXNXNYY3OULM6XMQEYTWKDSHTANCNFSM6AAAAAAQL7ZUH4>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Hello, Is there any way to use ambient with calico? |
The following may help.
|
I'm attempting to lay istio over calico in my clusters. Calico unfortunately only supports 1.15 - and it appears as though Ambient would solve a lot of the knitting that has to be done to integrate the two technologies. Would be great if ambient supported the current calico project! |
It works for me, |
Do you mean the 3rd step is not necessary? The issue I encountered was not with ztunnel pods but with my workloads. Without the annotation added to my workloads, egress traffic of my workload pods were dropped due to RPF. I believe 103 ip rule and routes in table 100 were causing this RPF failure. So I had to add the annotation to my workloads to bypass the RPF check by calico.
I suppose this 103 ip rule should be modified as it makes all egress traffic of pods served in ambient mode fail the RPF check. |
Yes, I did not apply step 3 because I am using the ebpf redirection mode, so I think the ip rules is not a problem for me, maybe you could give it a try :) |
Thanks. I was using the default iptables mode and haven't tried ebpf mode. |
Will #48212 address this? |
Yes |
This is resolved, please try latest master or release 1.21 build, or wait for the official 1.21 release. see #48212 |
Sorry, just got confirmation from Eric that the change is not in beta 0 yet, but should be in -beta.1 since it was merged after beta.0 was released. I expect that the new build will be available in a day or 2. |
Bug Description
default
nssleep
pod can communicate with product page without issue before joined ambient mesh:default
ns into ambient mesh:sleep
pod CAN NOT communicate with product page :sleep
pod CAN NOT communicate with product page via pod ip:Version
Additional Information
No response
The text was updated successfully, but these errors were encountered: