<p>I have a self managed Kubernetes cluster consisting of one master node and 3 worker nodes. I use the Cluster Network Interface <a href="https://github.com/flannel-io/flannel#flannel" rel="nofollow noreferrer">flannel</a> within the cluster.</p>
<p>On all my machines I can see the following kind of kernel messages:</p>
<pre><code>Apr 12 04:22:24 worker-7 kernel: [278523.379954] iptables[6260]: segfault at 88 ip 00007f9e69fefe47 sp 00007ffee4dff356 error 4 in libnftnl.so.11.3.0[7f9e69feb000+16000]
Apr 12 04:22:24 worker-7 kernel: [278523.380094] Code: bf 88 00 00 00 48 8b 2f 48 39 df 74 13 4c 89 ee 41 ff d4 85 c0 78 0b 48 89 ef 48 8b 6d 00 eb e8 31 c0 5a 5b 5d 41 5c 41 5d c3 &lt;48&gt; 8b 87 88 00 00 00 48 81 c7 78 00 00 00 48 39 f8 74 0b 85 f6 74
Apr 12 05:59:10 worker-7 kernel: [284329.182667] iptables[13978]: segfault at 88 ip 00007fb799fafe47 sp 00007fff22419b36 error 4 in libnftnl.so.11.3.0[7fb799fab000+16000]
Apr 12 05:59:10 worker-7 kernel: [284329.182774] Code: bf 88 00 00 00 48 8b 2f 48 39 df 74 13 4c 89 ee 41 ff d4 85 c0 78 0b 48 89 ef 48 8b 6d 00 eb e8 31 c0 5a 5b 5d 41 5c 41 5d c3 &lt;48&gt; 8b 87 88 00 00 00 48 81 c7 98 00 00 00 48 39 f8 74 0b 85 f6 74
Apr 12 08:29:25 worker-7 kernel: [293343.999073] iptables[16041]: segfault at 88 ip 00007fa40c7f7e47 sp 00007ffe04ba9886 error 4 in libnftnl.so.11.3.0[7fa40c7f3000+16000]
Apr 12 08:29:25 worker-7 kernel: [293343.999165] Code: bf 88 00 00 00 48 8b 2f 48 39 df 74 13 4c 89 ee 41 ff d4 85 c0 78 0b 48 89 ef 48 8b 6d 00 eb e8 31 c0 5a 5b 5d 41 5c 41 5d c3 &lt;48&gt; 8b 87 88 00 00 00 48 81 c7 98 00 00 00 48 39 f8 74 0b 85 f6 74
</code></pre>
<p>I narrowed it down that the messages originated in the kube-flannel-ds pods. I have log messages like this one:</p>
<pre><code>Failed to ensure iptables rules: Error checking rule existence: failed to check rule existence: running [/sbin/iptables -t filter -C FORWARD -s 10.244.0.0/16 -j ACCEPT --wait]: exit status -1:
Failed to ensure iptables rules: Error checking rule existence: failed to check rule existence: running [/sbin/iptables -t nat -C POS TROUTING -s 10.244.0.0/16 ! -d 224.0.0.0/4 -j MASQUERADE --random-fully --wait]: exit status -1: 
</code></pre>
<p>Can someone explain what this kind of messages are indicating? Can this be a hardware problem? Does it make sense to switch form flannel to another kuberentes container network interface (CNI) - e.g. <a href="https://docs.projectcalico.org/about/about-calico" rel="nofollow noreferrer">Calico</a>?</p>

Ralph
<p>As already mentioned in the comments debian buster uses nftables backed instead of iptables:</p>
<blockquote>
<p><strong>NOTE: iptables is being replaced by  <a href="https://wiki.debian.org/nftables" rel="nofollow noreferrer">nftables</a>  starting with Debian Buster</strong> - reference <a href="https://wiki.debian.org/iptables" rel="nofollow noreferrer">here</a></p>
</blockquote>
<p>Unfortunately the nftables are <a href="https://v1-17.docs.kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#ensure-iptables-tooling-does-not-use-the-nftables-backend" rel="nofollow noreferrer">not compatible</a> at this moment with kubernetes.</p>
<p>In Linux, nftables is available as a modern replacement for the kernel’s iptables subsystem. The  <code>iptables</code>  tooling can act as a compatibility layer, behaving like iptables but actually configuring nftables. This nftables backend is not compatible with the current kubeadm packages: it causes duplicated firewall rules and breaks  <code>kube-proxy</code>. You could try to switch to legacy option like described <a href="https://serverfault.com/questions/1025176/debian-10-how-can-i-disable-nftables-and-continue-to-use-iptables-only">here</a> but I'm not sure about this solution as I don't have a way to test it with your Os. I solved similar case with debian with this <a href="https://stackoverflow.com/questions/61978030/kubernetes-pods-not-accessible-within-the-cluster/62031947#62031947">here</a>.</p>
<p>Alternative way would to switch to Calico which actually <a href="https://docs.projectcalico.org/reference/felix/configuration" rel="nofollow noreferrer">supports nftbacked</a> with <code>FELIX_IPTABLESBACKEND</code>. This parameter controls which variant of iptables binary Felix uses. Set this to  <code>Auto</code>  for auto detection of the backend. If a specific backend is needed then use  <code>NFT</code>  for hosts using a netfilter backend or  <code>Legacy</code>  for others. [Default:  <code>Auto</code>].</p>
<p>When installing calico with containerd please also have a look a <a href="https://stackoverflow.com/questions/59744000/kubernetes-1-17-containerd-1-2-0-with-calico-cni-node-not-joining-to-master">this</a> case.</p>
