2

I'm trying to setup a kubernetes cluster on several ESXi hosts. The etcd/kube-apiserver/kube-scheduler/kube-controller-manager seem okay, however on the docker hosts (in this case coreos stable hosts) kubelet seems to work but kube-proxy does not.

I'm running the following commands and getting the error as listed.

coreos1 core # /opt/bin/kube-proxy --master=10.42.0.51:8080 --v=0
E0817 13:51:29.558463    6506 proxier.go:164] Error removing pure-iptables proxy rule: error checking rule: exit status 2: iptables v1.4.21: Couldn't load target `KUBE-SERVICES':No such file or directory

Try `iptables -h' or 'iptables --help' for more information.
E0817 13:51:29.560023    6506 proxier.go:167] Error removing pure-iptables proxy rule: error checking rule: exit status 2: iptables v1.4.21: Couldn't load target `KUBE-SERVICES':No such file or directory

Try `iptables -h' or 'iptables --help' for more information.

Several iptables chains not including the one referenced are created, not sure what the deal is with this one. I have flannel setup on this host tested working. I can fire off a test pod, however I never get an external IP and any hosts I bring up manually can't hit the configured IP range for in kubernetes.

Documentation for v1.0/1.0.1 seems pretty light, I keep running into log howto docs on very early beta versions.

James Geraldo
  • 21
  • 4

2 Answers2

2

Did you override any kube-proxy command parameters to use the pure-iptables mode ?

You should be able to use the userspace proxier mode for kube-proxy.

We are working on enabling the pure-iptables mode too, but in the meantime, the userspace mode could unblock you.

(The flag is legacy-userspace-proxy[=true])

Abhishek Shah
  • 21
  • 2
  • This flag seems to be deprecated by Kubernetes v1.2.0 in favor of `--proxy-mode=userspace` – expz May 14 '16 at 18:53
2

Just before these lines you should see this log line:

"Tearing down pure-iptables proxy rules. Errors here are acceptable."

What is happening is the proxier has two modes, and the startup code is making sure that the unused mode has been cleaned up. If you have never used the other mode, there's nothing to clean up. We decided it was better to log the errors than to hide them, in case something unexpected pops up. It's difficult to programmatically tell "nothing to do" from "error doing something", so we just didn't.

In short - I don't think this is an error. Are you actually experiencing a problem?

Tim Hockin
  • 282
  • 1
  • 6