geniusxiong
geniusxiong
> 看起来像 conntrack 相关资源被消耗尽的问题 如果是 overlay 网络可以再kube-ovn-controller 里设置 --enable-lb=false 看看减少相关使用 试了一下，还是会有同样的现象发生。  重新测试，结果如下图，还有93的响应未收到，已等待超过3分钟  本想试试这剩余93个数据包的最大返回时间，于是挂了一晚上（大概12小时），但是发现到了第二天上午还未返回，怀疑这部分是丢包了  这最大值是点击结束后生成的，应该不能算最大时间。
> Could you describe your application scenario in more detail? openelb version: v0.5.0 we use OpenELB in VIP Mode if we create a service, we can see the keepalived.conf there...
> 当前配置 ovn 不知道要将 `172.18.120.173` 路由到哪，尝试在 `vpc1` 上添加静态路由： > > ```yaml > kind: Vpc > apiVersion: kubeovn.io/v1 > metadata: > annotations: > bs.network.io/cidrBlock: 10.50.0.0/16 > bs.network.io/workspace: custom-vm > kubesphere.io/alias-name: vpc1...
> 麻烦贴下你的 install.sh 的 ENABLE_xx 那几行相关的配置，自定义 vpc 目前没这个 bug。 怀疑可能跟一些特性开启有关系 好的 IPV6=${IPV6:-false} DUAL_STACK=${DUAL_STACK:-false} ENABLE_SSL=${ENABLE_SSL:-false} ENABLE_VLAN=${ENABLE_VLAN:-false} CHECK_GATEWAY=${CHECK_GATEWAY:-true} LOGICAL_GATEWAY=${LOGICAL_GATEWAY:-false} U2O_INTERCONNECTION=${U2O_INTERCONNECTION:-false} ENABLE_MIRROR=${ENABLE_MIRROR:-false} VLAN_NIC=${VLAN_NIC:-} HW_OFFLOAD=${HW_OFFLOAD:-false} ENABLE_LB=${ENABLE_LB:-true} ENABLE_NP=${ENABLE_NP:-true} ENABLE_EIP_SNAT=${ENABLE_EIP_SNAT:-true} LS_DNAT_MOD_DL_DST=${LS_DNAT_MOD_DL_DST:-true} ENABLE_EXTERNAL_VPC=${ENABLE_EXTERNAL_VPC:-true} CNI_CONFIG_PRIORITY=${CNI_CONFIG_PRIORITY:-01} ENABLE_LB_SVC=${ENABLE_LB_SVC:-false} ENABLE_NAT_GW=${ENABLE_NAT_GW:-false} ENABLE_KEEP_VM_IP=${ENABLE_KEEP_VM_IP:-true}...
> 我感觉配置没问题，应该就是引入了一个bug 有计划修复？
@oilbeater 大佬，这个有修改计划么？
>  > > https://kubeovn.github.io/docs/v1.13.x/guide/eip-snat/ > > 你对照下这个eip的使用方式是否可以正常使用？ 然后对照下看是否是你的策略路由的维护逻辑。如果一致，应该就没问题。 只是这个功能我之前测试过很多次，都是可以正常使用的，之前不记得有配置这样的策略路由。 @bobz965 通过annotation绑定eip好像可以，但是实际使用的时候不好用，因为pod重建后，需要重新绑定eip，对于虚机来说，重启就会丢失eip，需要重新绑定。所以我们考虑用ovn eip fip方案替代直接通过annotation绑定eip。 谢谢 @a180285 提的修改方法，我回头试试。
> ```shell > kubectl ko trace {namespace/podname} 10.50.1.1 icmp > ``` > > 看一下流表 > > 而且我觉得drop icmp的优先级应该高于放通所有流的规则，不然匹配中高优先级的规则后，低优先级的就不会生效了 ``` [root@master-0 ovn]# kubectl get pod -n vpc1-ns -o wide NAME READY...
> > ```shell > > kubectl ko trace {namespace/podname} 10.50.1.1 icmp > > ``` > > > > > > > > > > > > > > > >...
> 我在master分支上创建了和你一样的sg，加上放行网关的规则后，pod就能起了 @geniusxiong 放行网关确实可以，但是我有疑问： 1. 能ping通本网段的虚机，也是能ping通外网，但是在这两个基础上，ping不通网关 2. ingressRules 禁用 icmp 后会导致 icmp response 的包被 drop，网关就不通了。如果是这样，为什么ping 本网段其他虚机，ping外网，都是能成功的 3. 如果都要配置放行网关节点，这样安全组就很难做成通用配置了