-
Notifications
You must be signed in to change notification settings - Fork 94
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
sidecar detection mode #282
Conversation
问题: 业务容器和边车启动容器的先后顺序是不定的; 如果业务容器先启动,但边车容器还未启动,这是探测边车容器的监听端口,探测不到,所以会标识_default.is_in_mesh = 0; 同时探测的结果会被 cache,不会再被重复探测,即is_in_mesh永远是 0,导致mb_connect.c中的几处分支逻辑永远不会执行. 解决方法: 因为 cni plugin 中已经校验当前的 POD 是否被 mess 纳管,进而决定是否启动SOCK_IP_MARK_PORT的监听; 所以这时只需探测SOCK_IP_MARK_PORT即可. signed-off-by: cybwan <baili@flomesh.io>
Welcome to the Merbridge OpenSource Community!👏 We're delighted to have you onboard 💘 |
问题: 业务容器和边车容器启动的先后顺序是不定的; 如果业务容器先启动,但边车容器还未启动,这时探测边车容器的监听端口,探测不到,所以会标识_default.is_in_mesh = 0; 同时探测的结果会被 cache,不会再被重复探测,即is_in_mesh永远是 0,导致mb_connect.c中的几处分支逻辑永远不会执行. 解决方法: 因为 cni plugin 中已经校验当前的 POD 是否被 mess 纳管,进而决定是否启动SOCK_IP_MARK_PORT的监听; 即 POD 中SOCK_IP_MARK_PORT总是最先启动的, 所以只需探测SOCK_IP_MARK_PORT即可. signed-off-by: cybwan <baili@flomesh.io>
Codecov Report
📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more @@ Coverage Diff @@
## main #282 +/- ##
=======================================
Coverage 32.87% 32.87%
=======================================
Files 7 7
Lines 514 514
=======================================
Hits 169 169
Misses 331 331
Partials 14 14
Flags with carried forward coverage won't be shown. Click here to find out more. 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! lgtm
I think this addresses #244
BTW I'm thinking about a new workaround to get rid of all the hacks(dummy socket, cni server), that would require vmlinux.h
though. But I've been a bit busy...will file a design later
Last time my fix kept giving me errors at the e2e stage ...... |
e2e still failed. |
test passed in multi nodes k8s cluster. |
This pr will break non-cni mode(that's why the e2e test failed I think) since there's no dummy socket |
right |
signed-off-by: cybwan <baili@flomesh.io>
signed-off-by: cybwan <baili@flomesh.io>
I can do without cni mode in ambient mode, but that's a different topic. |
问题:
业务容器和边车容器启动的先后顺序是不定的;
如果业务容器先启动,但边车容器还未启动,这时探测边车容器的监听端口,探测不到,所以会标识_default.is_in_mesh = 0;
同时探测的结果会被 cache,不会再被重复探测,即is_in_mesh永远是 0,导致mb_connect.c中的几处分支逻辑永远不会执行.
解决方法:
因为 cni plugin 中已经校验当前的 POD 是否被 mess 纳管,进而决定是否启动SOCK_IP_MARK_PORT的监听;
即 POD 中SOCK_IP_MARK_PORT总是最先启动的, 所以只需探测SOCK_IP_MARK_PORT即可.