Skip to content
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

DaemonSet does not get deleted when unused, stale iptables entries #3

Open
ShadowJonathan opened this issue Jun 5, 2020 · 0 comments

Comments

@ShadowJonathan
Copy link

(I use k3os with klipper-lb installed by default)

I just had this issue where i had to restart my node 2 times and flush iptables both times:

The problem

I kept constantly connecting to an internal pod's ssh port because of a LoadBalancer service that hooked it up to that port.

No problem, I just set that service's type to ClusterIP or NodePort.

I still kept connecting to the pod's sshd service.

I dug into the iptables, doing iptables-save and grepping through that file to see that it still displayed the rules required to go from "hostport" to that service.

Fine, I'll take note of that and do iptables -F, and then immidiately restart.

After restarting, I could quickly but temporarily connect to the "right" sshd service, but after disconnecting and reconnecting again i found myself at the warning of a "wrong" host key, signaling that the node had somehow highjacked my ssh port again.

At this stage i looked at my pods, and found that the "sidecar" pod for the once-loadbalancer-service still existed, i deleted it, but because it was owned by a daemonset, i had to delete that too.

I tested the port again, it was still in the iptables, I flushed and restarted.

This time, the port finally connected properly even after the pods went up.

Obeservation

klipper-lb creates "sidecar" daemonset pods to every loadbalancer service observed, but it does not remove these once they're not required, nor does klipper take care of the leftover iptables.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant