kubernetes erros do iptables do kube-proxy

Question

Estou tentando configurar um cluster do kubernetes em vários hosts ESXi. O etcd / kube-apiserver / kube-scheduler / kube-controller-manager parece bem, no entanto, nos hosts docker (neste caso, hosts estáveis coreos) o kubelet parece funcionar, mas o kube-proxy não.

Estou executando os seguintes comandos e obtendo o erro listado.

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.

Várias cadeias iptables que não incluem a uma referenciada são criadas, não tendo certeza qual é a transação com essa. Eu tenho configuração de flanela neste trabalho testado host. Eu posso disparar um pod de teste, no entanto eu nunca recebo um IP externo e qualquer host que eu apresento manualmente não pode atingir o intervalo de IP configurado em kubernetes.

A documentação para v1.0 / 1.0.1 parece bastante clara, continuo a ler os documentos do howto do log nas primeiras versões beta.

    

Answer 1

Você substituiu qualquer parâmetro do comando kube-proxy para usar o modo pure-iptables?

Você deve ser capaz de usar o modo de proxy do espaço de usuário para o kube-proxy.

Também estamos trabalhando para ativar o modo pure-iptables, mas enquanto isso, o modo de espaço do usuário pode desbloquear você.

(O sinalizador é legacy-userspace-proxy [= true])

    

Answer 2

Logo antes dessas linhas, você deve ver esta linha de registro:

"Derrubando regras do proxy pure-iptables. Erros aqui são aceitáveis."

O que está acontecendo é que o proxier tem dois modos, e o código de inicialização está garantindo que o modo não utilizado tenha sido limpo. Se você nunca usou o outro modo, não há nada para limpar. Nós decidimos que era melhor registrar os erros do que escondê-los, caso algo inesperado surgisse. É difícil dizer programaticamente "nada a fazer" de "erro ao fazer algo", então simplesmente não o fizemos.

Resumindo - não acho que isso seja um erro. Você está passando por um problema?