Change:
// initialize ipsetList with all sets we needed proxier.ipsetList = make(map[string]*IPSet) for _, is := range ipsetInfo { <del> if is.isIPv6 { proxier.ipsetList[is.name] = NewIPSet(ipset, is.name, is.setType, isIPv6, is.comment) } proxier.ipsetList[is.name] = NewIPSet(ipset, is.name, is.setType, false, is.comment) </del> <ins> proxier.ipsetList[is.name] = NewIPSet(ipset, is.name, is.setType, isIPv6, is.comment) </ins> } burstSyncs := 2 glog.V(3).Infof("minSyncPeriod: %v, syncPeriod: %v, burstSyncs: %d", minSyncPeriod, syncPeriod, burstSyncs)

Discussion:
/kind bug /area ipv6 /area ipvs /sig network What happened: In an ipv6-only cluster the in mode creates a number of ipset's with . This causes problems and fault logs when they are used with ipv6 addresses. What you expected to happen: The ipset's should be created with . How to reproduce it (as minimally and precisely as possible): Start a ipv6-only cluster Execute; on any node and check the output Anything else we need to know?: The problem seems to be This code seems pretty weird to me. I mean why a flag in the structure at all? I ignored the flag in the structure and just passed the in the directly to and it seem to work. Environment: Kubernetes version (use ):Cloud provider or hardware configuration: Kvm on Ubuntu 16.04 OS (e.g. from /etc/os-release): Own BusyBox system Kernel (e.g. ):Install tools: None Others:
Did you make changes like this Earlier error related with ipsets whose is ?
Exactly. I have no idea why any particular ipset would be ipv4 in an ipv6 cluster. But the flag is false for NodePort set's and there is another bug that NodePort addresses are ipv4 (and faulty). So there might have been some special handling of nodeports at some time. IMHO there shoudn't be. FYI, I can't send a PR myself just yet but expect to be able to do that in September.
/cc
I can confirm that, in Ipv6 only cluster, is reporting family inet for many of the entries (KUBE-LOOP-BACK, KUBE-CLUSTER-IP, KUBE-LOAD-BALANCER-FW...).
There is clearly a bug in this code, as it forces IPV4: Should have been an else clause, or just: Even with this, there area entries that are using IPv4. Mostly NodePort related entries. Also see iptables error still:
Correction to above... the ipv6 flag should be based on node's IP family and not the isIPv6 field in the ipsetInfo struct, which has true for all entries, except the nodeport entries. Is anyone planning on creating a PR for this?

Looking forward to PRs
The following codes actually act the same because are of type , which have only one argument (no : or ). I think they are old ipsets. Are there ipsets with ?
I actually forgot to mention that traffic does not work. It is not just flooded logs and printout from that is the problem. Below is printout from in an ipv6-only cluster. As you can see all set's that have an "ip" have "family inet". Those without "ip", for instance "bitmap:port" has no family at all.
And I hope to send a PR for this in a few days.
I think the changes you made won't work. The problem is failing to create new ipsets. It should work after deleting the old ipsets.
They do work, I have tested. There are no old ipset's since the cluster is started fresh with an ipv6-only configuration. Do you upgrade your cluster from ipv4-only to ipv6-only without rebooting the nodes? That is a very complex upgrade and IMHO it should not be supported. When dual-stack comes I think it will be easier, like; to k8s with dual-stack support while still using ipv4-only /enable ipv6
I think I understand what you mean by "existing" sets now. Some sets are created twice since there are no clause in the if-statement. The ipset command is called with which I think causes the second "create" to actually become a "modify". And in that call the ipIpv6 flag is hard-coded to . I see no purpose for the isIpv6 flag in the structure and will remove it in my PR.