Kubeadm: nós com várias interfaces de rede podem falhar na comunicação com os serviços

Outro usuário relatou o mesmo comportamento em # kubernetes-users.

@damaspi Abri este problema e forneci uma correção. Esperando feedback!

Além disso, mudar para o modo userspace traz uma grande penalidade de desempenho.

Desculpe, eu comentei no assunto errado.
Obrigado pela correção. Não poderei testá-lo em breve (estava trabalhando nisso durante as férias e estou de volta ao trabalho) e estava usando apenas a versão estável oficial (portanto, não tenho o ambiente para construí-la).

Copiei aqui agora e apaguei no outro ...

Eu trabalhei temporariamente configurando o modo proxy para o espaço do usuário, mas qualquer conselho é bem-vindo ...

(inspirado nesta edição )

kubectl -n kube-system get ds -l "component=kube-proxy" -o json | jq ".items[0].spec.template.spec.containers[0].command |= .+ [\"--proxy-mode=userspace\"]" | kubectl apply -f - && kubectl -n kube-system delete pods -l "component=kube-proxy"

Novamente, @damaspi

Além disso, mudar para o modo de espaço do usuário traz uma grande penalidade de desempenho.

Eu tive o mesmo problema.
Meu Kube-Proxy não instalava as regras relacionadas ao serviço, tornando qualquer serviço indisponível nos pods.

Minha correção foi modificar o Kubeadm DaemonSet para kube-proxy e adicionar explicitamente a opção --cluster-cidr =.

/ cc @luxas

@spxtr você está fechando

@mikedanese PRs sendo fundidos e houve uma fusão de PR que consertou a falta de --cluster-cidr flag no controller-manager.

@pires , a fusão do PR no repo principal não foi o que fechou este PR. Foi a fusão no branch de

Ah, eu já vi isso antes.

Eu vi isso em 1.5.2. I construir manualmente um cluster (para aprender.). Não estou certo de qual é a correção, pois há menção do gerenciador de controlador e do conjunto de daemon. Isso implica para mim que as pessoas estão iniciando o kube-proxy por meio de um conjunto daemon. Apenas para esclarecer, a correção real é adicionar o sinalizador (--cluster-cidr) ao kube-proxy correto? Só estou tentando ter certeza de que não estou perdendo nada. Além disso, só para limpar minha memória, o kube-proxy não usou para obter isso do kube-apiserver? Sempre foi necessário, não me lembro. Se não, alguém pode esclarecer a diferença entre --service-cluster-ip-range = 10.0.0.0 / 16 (api) e --cluster-cidr (proxy)? Obrigado. (desculpe adicionar aqui, não tenho certeza onde mais perguntar sobre este problema.)

Onde o servidor da API expôs o CIDR do pod de cluster? Este foi um equívoco da minha parte também.

Olá @pires , pensei. --service-cluster-ip-range = 10.0.0.0 / 16 no api-server configure tudo já que os proxies conversariam com o servidor k8s para obter essas informações. --cluster-cidr talvez fosse fazer um subconjunto de --service-cluster-ip-range, caso contrário, parece redundante ou há um caso de uso sobre o qual não estou certo (ou simplesmente não sei do que estou falando , o que pode ser verdade!)

CIDR de serviço é a sub-rede usada para IPs virtuais (usado por kube-proxy). O problema é que o kube-proxy não conhece o CIDR da rede pod, que é diferente do CIDR do serviço.

Ah, então seria essa a sobreposição?

Esse problema causaria a comunicação entre o pod e o api-server? Por exemplo, se eu fosse executar o comando curl de um pod kube para apiserver "curl https://10.96.0.1:443/api" resultado:> curl: (7) Falha ao conectar a 10.96.0.1 porta 443: Tempo de conexão Fora...

@ bamb00 , sim, esse sintoma é causado por esse bug.

Para os interessados, o que está acontecendo é que, sem o conhecimento da sub-rede do cluster, o kube-proxy não pode gerar condições de iptables para corresponder ao tráfego externo. Sem essas condições, o tráfego não é marcado para SNAT e é colocado na rede com o endereço de destino correto, mas com a origem incorreta.

Demonstração das regras que faltam:

--- /root/ipt.old   2017-02-22 09:26:48.666151853 +0000
+++ /root/ipt.new   2017-02-22 09:25:52.010151853 +0000
@@ -27,8 +27,11 @@
 -A KUBE-POSTROUTING -m comment --comment "kubernetes service traffic requiring SNAT" -m mark --mark 0x4000/0x4000 -j MASQUERADE
 -A KUBE-SEP-EHDRCCD3XO3VA5ZU -s 192.168.1.4/32 -m comment --comment "default/kubernetes:https" -j KUBE-MARK-MASQ
 -A KUBE-SEP-EHDRCCD3XO3VA5ZU -p tcp -m comment --comment "default/kubernetes:https" -m recent --set --name KUBE-SEP-EHDRCCD3XO3VA5ZU --mask 255.255.255.255 --rsource -m tcp -j DNAT --to-destination 192.168.1.4:6443
+-A KUBE-SERVICES ! -s 10.32.0.0/12 -d 10.96.0.1/32 -p tcp -m comment --comment "default/kubernetes:https cluster IP" -m tcp --dport 443 -j KUBE-MARK-MASQ
 -A KUBE-SERVICES -d 10.96.0.1/32 -p tcp -m comment --comment "default/kubernetes:https cluster IP" -m tcp --dport 443 -j KUBE-SVC-NPX46M4PTMTKRN6Y
+-A KUBE-SERVICES ! -s 10.32.0.0/12 -d 10.96.0.10/32 -p udp -m comment --comment "kube-system/kube-dns:dns cluster IP" -m udp --dport 53 -j KUBE-MARK-MASQ
 -A KUBE-SERVICES -d 10.96.0.10/32 -p udp -m comment --comment "kube-system/kube-dns:dns cluster IP" -m udp --dport 53 -j KUBE-SVC-TCOU7JCQXEZGVUNU
+-A KUBE-SERVICES ! -s 10.32.0.0/12 -d 10.96.0.10/32 -p tcp -m comment --comment "kube-system/kube-dns:dns-tcp cluster IP" -m tcp --dport 53 -j KUBE-MARK-MASQ
 -A KUBE-SERVICES -d 10.96.0.10/32 -p tcp -m comment --comment "kube-system/kube-dns:dns-tcp cluster IP" -m tcp --dport 53 -j KUBE-SVC-ERIFXISQEP7F7OF4
 -A KUBE-SERVICES -m comment --comment "kubernetes service nodeports; NOTE: this must be the last rule in this chain" -m addrtype --dst-type LOCAL -j KUBE-NODEPORTS
 -A KUBE-SVC-NPX46M4PTMTKRN6Y -m comment --comment "default/kubernetes:https" -m recent --rcheck --seconds 10800 --reap --name KUBE-SEP-EHDRCCD3XO3VA5ZU --mask 255.255.255.255 --rsource -j KUBE-SEP-EHDRCCD3XO3VA5ZU
@@ -72,4 +75,6 @@
 -A WEAVE-NPC -d 224.0.0.0/4 -j ACCEPT
 -A WEAVE-NPC -m state --state NEW -j WEAVE-NPC-DEFAULT
 -A WEAVE-NPC -m state --state NEW -j WEAVE-NPC-INGRESS
+-A WEAVE-NPC-DEFAULT -m set --match-set weave-k?Z;25^M}|1s7P3|H9i;*;MhG dst -j ACCEPT
+-A WEAVE-NPC-DEFAULT -m set --match-set weave-iuZcey(5DeXbzgRFs8Szo]<<strong i="9">@p</strong> dst -j ACCEPT
 COMMIT

Este pode ser fixado no tempo de execução, modificando @damaspi 's de comando a partir de cima, substituindo-o modo --proxy = espaço do usuário com --cluster-cidr = your_cidr

Atualmente, construindo o kubeadm com o patch mesclado, será reiniciado com isso e relatará seu sucesso.

@predakanga , Obrigado pela resposta e explicação. Estou lutando para entender o tempo limite de uma conexão com o apiserver de um pod. O que me intriga é que o erro de tempo limite ocorre no pod em execução no nó no não mestre (AWS) e o pod em execução no nó mestre não apresenta o erro de tempo limite. Desejo aplicar a solução alternativa sugerida, mas tenho uma pergunta sobre como obtenho o valor your_cidr para --cluster-cidr?

Gambiarra:
kubectl -n kube-system get ds -l "componente = kube-proxy" -o json | jq '.items [0] .spec.template.spec.containers [0] .command | =. + [\ " --cluster-cidr = your_cidr \"]' | kubectl apply -f - && kubectl -n kube-system delete pods -l "componente = kube-proxy"

Aqui está o log de tempo limite:
2017-02-22T16: 23: 44.200770003Z 2017-02-22 16:23:44 +0000 [info]: começando fluentd-0.12.31
2017-02-22T16: 23: 44.281836006Z 2017-02-22 16:23:44 +0000 [info]: gem 'fluent-plugin-elasticsearch' versão '1.9.2'
2017-02-22T16: 23: 44.281862309Z 2017-02-22 16:23:44 +0000 [info]: gem 'fluent-plugin-journal-parser' versão '0.1.0'
2017-02-22T16: 23: 44.281867643Z 2017-02-22 16:23:44 +0000 [info]: gem 'fluent-plugin-kubernetes_metadata_filter' versão '0.26.2'
2017-02-22T16: 23: 44.281873256Z 2017-02-22 16:23:44 +0000 [info]: gem 'fluent-plugin-record-reformamer' versão '0.8.3'
2017-02-22T16: 23: 44.281876742Z 2017-02-22 16:23:44 +0000 [info]: gem 'fluentd' versão '0.12.31'
2017-02-22T16: 23: 44.281976520Z 2017-02-22 16:23:44 +0000 [informações]: adicionando padrão de filtro = "kubernetes. " Type = "kubernetes_metadata"2017-02-22T16: 24: 44.639919409Z 2017-02-22 16:24:44 +0000 ** [erro]: arquivo de erro de configuração = "/ fluentd / etc / fluent.conf" error = "Ponto de extremidade da API v1 do Kubernetes inválido https://10.96.0.1 : 443 / api: Tempo limite esgotado ao conectar ao servidor "
2017-02-22T16: 24: 44.641926923Z 2017-02-22 16:24:44 +0000 [info]: código finalizado do processo = 256
2017-02-22T16: 24: 44.641936546Z 2017-02-22 16:24:44 +0000 [erro]: o processo principal fluentd morreu inesperadamente. reiniciando.

Como você pode ver, o tempo limite está apontando para https://10.96.0.1 : 443 / api, mas no serviço kubernetes, os pontos de extremidade apiserver são 10.43.0.20:6443. Pelo que entendi de sua explicação, o erro de tempo limite é que o kube-proxy não pode gerar a condição iptables para corresponder ao tráfego externo.

Por que a conexão está passando por 10.96.0.1:443 e não pelos pontos de extremidade 10.43.0.20:6443?

Nome: kubernetes
Namespace: padrão
Rótulos: componente = apiserver
provedor = kubernetes
Seletor:
Tipo: ClusterIP
IP: 10.96.0.1
Porta: https 443 / TCP
Endpoints: 10.43.0.20:6443
Afinidade da sessão: ClientIP
Sem eventos.

Atualização: Aplicar as correções de contorno "clusterCIDR não especificado, incapaz de distinguir entre tráfego interno e externo".

Obrigado.

Desculpe pela pergunta de novato, mas como faço para obter a correção para aplicá-la permanentemente?

Estamos usando o kube-proxy v1.5.3 (gcr.io/google_containers/kube-proxy-amd64:v1.5.3), mas ainda vemos o erro "clusterCIDR não especificado, não é possível distinguir entre tráfego interno e externo".

De acordo com o URL abaixo, a correção é para kube-proxy v1.5,
https://github.com/dchen1107/kubernetes-1/commit/9dedf92d42028e1bbb4d6aae66b353697afaa55b

Isso está correto?

@ bamb00, esta não é uma correção do kube-proxy, mas uma alteração do kubeadm que define um sinalizador no manifesto do pod kube-proxy. O kubeadm não segue (ainda!) o processo de lançamento do kubernetes, então não há kubeadm 1.5.3. Haverá um 1.6.

Implanto 1.5.2. Alguma dica de aviso. proxy: clusterCIDR não especificado, não é possível distinguir entre o tráfego interno e externo

@timchenxiaoyu Com v1.6 você pode definir o sinalizador --pod-network-cidr para definir isso

Olá, trabalho na Weave Net e não consigo compreender porque é que seria necessária uma alteração conforme descrito em https://github.com/kubernetes/kubeadm/issues/102#issuecomment -281617189

O Weave Net instala suas próprias regras de mascaramento ao sair da rede de pod, portanto, não deve precisar do kube-proxy para fazer isso também.

@bboreham Não posso explicar o porquê, mas, de cor, o problema era que os pods daemonset weave-net não podiam se comunicar.

Vou refazer meu ambiente para que possa dar mais detalhes, mas isso pode demorar um pouco (Internet australiana)

Não consigo ver por que este problema deve ser fechado - um mantenedor poderia reabri-lo?

/ cc @luxas

Acabei de verificar um cluster Kubernetes + WeaveNet em funcionamento e ele tem a mesma mensagem nos registros do kube-proxy

W0404 12:24:17.175005       1 proxier.go:309] clusterCIDR not specified, unable to distinguish between internal and external traffic

Portanto, concluo que o aviso está assustando desnecessariamente as pessoas.

o problema era que os pods daemonset weave-net não podiam se comunicar.

@predakanga a implementação do Weave Net é executada no namespace da rede host; ele definitivamente não deve ser afetado por (ou chegar perto) das regras do kube-proxy quando os pods se comunicam.

@bboreham Ah, eu estava me

Acho que sei qual era o problema real, mas vou esperar até que dois desses nós terminem a inicialização para que eu possa confirmar

@bboreham O problema é que o pod de tecelagem está tentando alcançar o servidor API por meio de seu VIP

Acabei de inicializar um cluster de dois nós sem opções especiais e https://git.io/weave-kube-1.6 aplicado, e cheguei a uma condição de erro.

Saída Syslog:

Apr  4 13:48:45 frontend kubelet[17891]: I0404 13:48:45.775425   17891 operation_generator.go:597] MountVolume.SetUp succeeded for volume "kubernetes.io/secret/a96a9cfb-193b-11e7-b8e0-02fc636bbb90-weave-net-token-p3qrx" (spec.Name: "weave-net-token-p3qrx") pod "a96a9cfb-193b-11e7-b8e0-02fc636bbb90" (UID: "a96a9cfb-193b-11e7-b8e0-02fc636bbb90").
Apr  4 13:48:45 frontend kubelet[17891]: I0404 13:48:45.984975   17891 kuberuntime_manager.go:458] Container {Name:weave Image:weaveworks/weave-kube:1.9.4 Command:[/home/weave/launch.sh] Args:[] WorkingDir: Ports:[] EnvFrom:[] Env:[] Resources:{Limits:map[] Requests:map[cpu:{i:{value:10 scale:-3} d:{Dec:<nil>} s:10m Format:DecimalSI}]} VolumeMounts:[{Name:weavedb ReadOnly:false MountPath:/weavedb SubPath:} {Name:cni-bin ReadOnly:false MountPath:/host/opt SubPath:} {Name:cni-bin2 ReadOnly:false MountPath:/host/home SubPath:} {Name:cni-conf ReadOnly:false MountPath:/host/etc SubPath:} {Name:dbus ReadOnly:false MountPath:/host/var/lib/dbus SubPath:} {Name:lib-modules ReadOnly:false MountPath:/lib/modules SubPath:} {Name:weave-net-token-p3qrx ReadOnly:true MountPath:/var/run/secrets/kubernetes.io/serviceaccount SubPath:}] LivenessProbe:&Probe{Handler:Handler{Exec:nil,HTTPGet:&HTTPGetAction{Path:/status,Port:6784,Host:127.0.0.1,Scheme:HTTP,HTTPHeaders:[],},TCPSocket:nil,},InitialDelaySeconds:30,TimeoutSeconds:1,PeriodSeconds:10,SuccessThreshold:1,FailureThreshold:3,} ReadinessProbe:nil Lifecycle:nil TerminationMessagePath:/dev/termination-log TerminationMessagePolicy:File ImagePullPolicy:IfNotPresent SecurityContext:&SecurityContext{Capabilities:nil,Privileged:*true,SELinuxOptions:nil,RunAsUser:nil,RunAsNonRoot:nil,ReadOnlyRootFilesystem:nil,} Stdin:false StdinOnce:false TTY:false} is dead, but RestartPolicy says that we should restart it.
Apr  4 13:48:45 frontend kubelet[17891]: I0404 13:48:45.986470   17891 kuberuntime_manager.go:742] checking backoff for container "weave" in pod "weave-net-x18xm_kube-system(a96a9cfb-193b-11e7-b8e0-02fc636bbb90)"
Apr  4 13:48:45 frontend kubelet[17891]: I0404 13:48:45.987392   17891 kuberuntime_manager.go:752] Back-off 5m0s restarting failed container=weave pod=weave-net-x18xm_kube-system(a96a9cfb-193b-11e7-b8e0-02fc636bbb90)
Apr  4 13:48:45 frontend kubelet[17891]: E0404 13:48:45.987440   17891 pod_workers.go:182] Error syncing pod a96a9cfb-193b-11e7-b8e0-02fc636bbb90 ("weave-net-x18xm_kube-system(a96a9cfb-193b-11e7-b8e0-02fc636bbb90)"), skipping: failed to "StartContainer" for "weave" with CrashLoopBackOff: "Back-off 5m0s restarting failed container=weave pod=weave-net-x18xm_kube-system(a96a9cfb-193b-11e7-b8e0-02fc636bbb90)"
Apr  4 13:48:50 frontend kubelet[17891]: W0404 13:48:50.545383   17891 cni.go:157] Unable to update cni config: No networks found in /etc/cni/net.d
Apr  4 13:48:50 frontend kubelet[17891]: E0404 13:48:50.546074   17891 kubelet.go:2067] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

Trançar registros de contêineres:

2017/04/04 13:45:24 error contacting APIServer: Get https://10.96.0.1:443/api/v1/nodes: dial tcp 10.96.0.1:443: i/o timeout; trying with fallback: http://localhost:8080
2017/04/04 13:45:24 Could not get peers: Get http://localhost:8080/api/v1/nodes: dial tcp 127.0.0.1:8080: getsockopt: connection refused
Failed to get peers

E o nó nunca atinge o estado "Pronto"

O problema é que o pod de tecelagem está tentando alcançar o servidor API por meio de seu VIP

qual é a evidência disso?

Obtenha http: // localhost : 8080 / api / v1 / nodes

Este é o pod de tecelagem tentando alcançar o api-server em um endereço local não seguro. Esta não é a configuração que você obtém do kubeadm atual sem opções.

Meu problema de novo - minha formatação cortou a primeira linha de cada registro. Eu alterei os dois.

ok, também acabei de configurar um cluster sem opções especiais e não tenho problemas para entrar em contato com tcp: //10.96.0.1 : 443

No entanto, meu comentário sobre a configuração de regras de mascaramento do Weave Net não é relevante. Deixe-me ver se consigo descobrir.

Para efeito de comparação, acabei de executar novamente o bootstrap do kubeadm com a adição de --pod-network-cidr 10.32.0.0/12 e o pod de tecelagem começa corretamente, o nó muda para Pronto.

Suspeito que você não esteja experimentando isso porque só se aplica a certas configurações de rede - no meu caso, estou usando máquinas Vagrant com o cluster kube estabelecido em interfaces secundárias apenas privadas.

Em uma conversa separada, eu vi isso acontecendo:

Existem duas interfaces de rede, eth0 e eth1 : eth0 tem a rota padrão, mas queremos que todo o tráfego para kubernetes passe por eth1 .

• Um processo, como Weave Net, abre uma conexão com o endereço de serviço 10.96.0.1
• O endereço de destino é mapeado novamente para o endereço eth1 do mestre 192.168.10.90 (o mapeamento é feito com as regras de iptables criadas pelo kube-proxy.)
• O pacote é enviado na interface eth1 do nó.
• No entanto, o Linux já escolheu o endereço de origem eth0 para este pacote, com base no destino original que corresponde à rota padrão.
• No destino é largado como vindo do lugar errado

Adicionar --pod-network-cidr faz com que uma regra extra de iptables reescreva o endereço de origem. Portanto, agora ele irá percorrer as interfaces eth1. [EDITAR: Eu não recomendo isso, porque é essencialmente um acidente que faz com que funcione]

Outra maneira de fazer isso funcionar é adicionar uma rota informando ao Linux que todos os endereços de serviço do kubernetes devem passar pela eth1, assim:

ip route add 10.96.0.0/16 dev eth1 src 192.168.10.100

Pessoalmente, acho a rota mais atraente, pois toma a decisão certa antes. Mas procurando outras vozes para comentar se isso é válido.

@bboreham, obrigado por depurar comigo e obrigado por atualizar com as descobertas aqui!

Vou testar as correções no meu ambiente.

Interessante - posso confirmar que esta abordagem de rota funciona em um único
segmento de rede, mas isso causaria problemas em domínios de transmissão?

Lachlan

Na quarta-feira, 5 de abril de 2017 à 1h16, Bryan Boreham [email protected]
escrevi:

Em uma conversa separada, eu vi isso acontecendo:

Existem duas interfaces de rede, eth0 e eth1: eth0 tem o padrão
rota, mas queremos que todo o tráfego para o kubernetes passe pela eth1.

• Um processo, como Weave Net, abre uma conexão com o serviço
  endereço 10.96.0.1
• O endereço de destino é mapeado novamente para o endereço eth1 do mestre
  192.168.10.90 (o remapeamento é feito com regras de iptables criadas por kube-proxy.)
• O pacote é enviado na interface eth1 do nó.
• No entanto, o Linux já escolheu o endereço de origem eth0 para este
  pacote, com base no destino original que corresponde à rota padrão.
• No destino é largado como vindo do lugar errado

Adicionar --pod-network-cidr faz com que uma regra iptables extra seja reescrita
o endereço de origem. Portanto, agora ele irá percorrer as interfaces eth1.

Outra maneira de fazer funcionar é adicionar uma rota informando ao Linux que todos
Os endereços de serviço do kubernetes devem passar por eth1, assim:

ip route add 10.96.0.0/16 dev eth1 src 192.168.10.100

Pessoalmente, acho a rota mais atraente, pois torna o caminho certo
decisão anterior. Mas procurando outras vozes para comentar se isso
é válido.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/kubernetes/kubeadm/issues/102#issuecomment-291532883 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AAystQH0juIo6cXPh5QQeB-1rHlUKUgvks5rsl7WgaJpZM4La21F
.

@bboreham Posso confirmar que agora tenho uma configuração de ansible funcionando adicionando as rotas ... :-)

@predakanga tudo o que estou tentando fazer com a rota é fazer com que o Linux escolha um endereço de origem melhor; uma vez que esperamos que todos os IPs de serviço sejam DNAT, não esperamos realmente usar essa rota. No entanto, posso ver que, se os endereços subjacentes forem enviados em dois adaptadores de rede diferentes, minha sugestão não seria boa.

@thockin Eu valorizaria sua https://github.com/kubernetes/kubeadm/issues/102#issuecomment -291532883 e as duas sugestões para configurar SNAT (para conexões originadas no namespace de rede host) ou adicionar um rota para o intervalo de IP de serviço.

@bboreham você poderia documentar essas descobertas de alguma forma e em algum lugar, por favor?
Então, mais usuários saberiam sobre isso?

Eu só terminei de depurar o sistema @obnoxxx algumas horas atrás!
Estou documentando aqui para que alguém possa dizer "não! Não! Você entendeu completamente errado".
Se isso não acontecer, ficarei feliz em elevá-lo à documentação adequada: ligeiramente_smiling_face:

Em um caso de múltiplos caminhos de NICs, sim, acho que você precisaria de uma rota como sugeriu. Não tenho certeza de como descobrir isso automaticamente ...

Mais um pensamento veio à mente: isso não tem nada a ver com a rede pod (Weave Net ou outro), porque o que está falhando é um processo no namespace do host de um nó tentando falar com o api-server no master. Portanto, a descoberta de que definir clusterCIDR faz com que funcione deve ser acidental.

@bboreham @thockin Podemos fazer
É possível definir --cluster-cidr no kube-proxy passando --pod-network-cidr para kubeadm init

Como já descrevi, definir --cluster-cidr não é uma resposta válida para o problema originalmente relatado em um comentário em # 74 . (Embora isso aconteça para fazer o problema desaparecer).

O título aqui é inútil; está relacionado a uma mensagem de aviso que não tem absolutamente nada a ver com o problema subjacente.

Eu realmente não sei o que o kubeadm poderia fazer, uma vez que a solução parece estar relacionada à rede subjacente. Talvez adicionar opções para informar sua "interface pública" e "interface privada" desejadas e fazer com que o kubeadm recomende alterações na configuração da rede?

Acabei de dar uma olhada na lógica clusterCIDR no kube-proxy e concordo que é um caso estranho.

Eu concordo que a rota estática é apropriada para a 2ª interface, mas é lamentável. Parece que o kernel deveria ser mais inteligente do que isso.

Estou executando a v1.6.1 e pensei que o erro "clusterCIDR não especificado, não é possível distinguir entre tráfego interno e externo" seria endereço.

2017-06-06T17: 49: 17.113224501Z I0606 17: 49: 17.112870 1 server.go: 225] Usando iptables Proxier.
2017-06-06T17: 49: 17.139584294Z W0606 17: 49: 17.139190 1 proxier.go: 309] clusterCIDR não especificado, incapaz de distinguir entre tráfego interno e externo
2017-06-06T17: 49: 17.139607413Z I0606 17: 49: 17.139223 1 server.go: 249] Eliminando regras de espaço do usuário.
06-06-2017: 17: 49: 17.251412491Z I0606 17: 49: 17.251115 1 conntrack.go: 81] Defina sysctl 'net / netfilter / nf_conntrack_max' como 524288
06-06-2017: 17: 49: 17.252499164Z I0606 17: 49: 17.252359 1 conntrack.go: 66] Configurando hashsize de conntrack para 131072
2017-06-06T17: 49: 17.253220249Z I0606 17: 49: 17.253057 1 conntrack.go: 81] Defina sysctl 'net / netfilter / nf_conntrack_tcp_timeout_established' como 86400
2017-06-06T17: 49: 17.253246216Z I0606 17: 49: 17.253124 1 conntrack.go: 81] Defina sysctl 'net / netfilter / nf_conntrack_tcp_timeout_close_wait' para 3600

como definir o tráfego interno e externo?

Esse erro se refere especificamente a qualquer coisa fora dos IPs de pod dos clusters.

Em quinta-feira, 8 de junho de 2017 às 22h29, timchenxiaoyu [email protected]
escrevi:

como definir o tráfego interno e externo?

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/kubernetes/kubeadm/issues/102#issuecomment-307298979 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AFVgVPwm-x4smcIx1cFAOLOO6FFIn9T6ks5sCNgkgaJpZM4La21F
.

Eu também vi esse problema. uma rota para a rede pod para o segundo nic resolveu o problema para mim. Parece um pouco frágil ...

Oi,

Estou executando o Kubernetes v1.6.6 e v1.7.0 kube-proxy. Obtendo o mesmo erro,

kube-proxy:

   W0914 00:15:41.627710       1 proxier.go:298] clusterCIDR not specified, unable to distinguish between internal and external traffic

Versão do Kubernetes:

   Client Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.6", GitCommit:"7fa1c1756d8bc963f1a389f4a6937dc71f08ada2", GitTreeState:"clean", BuildDate:"2017-06-16T18:34:20Z", GoVersion:"go1.7.6", Compiler:"gc", Platform:"linux/amd64"}
   Server Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.6", GitCommit:"7fa1c1756d8bc963f1a389f4a6937dc71f08ada2", GitTreeState:"clean", BuildDate:"2017-06-16T18:21:54Z", GoVersion:"go1.7.6", Compiler:"gc", Platform:"linux/amd64"}

Tente a solução alternativa de @damaspi, mas falhou em v1.6.6 e v1.7.0 use para trabalhar em v1.5.4.

  # kubectl -n kube-system get ds -l "component=kube-proxy" -o json | jq '.items[0].spec.template.spec.containers[0].command |= .+ ["--cluster-cidr=10.96.0.0/12"]' | kubectl apply -f - && kubectl -n kube-system delete pods -l "component=kube-proxy"

    error: error validating "STDIN": error validating data: items[0].apiVersion not set; if you choose to ignore these errors, turn validation off with --validate=false

Precisa de orientação para resolver em v1.6.6 e v1.7.0. Obrigado.

@bboreham

Eu realmente não sei o que o kubeadm poderia fazer, uma vez que a solução parece estar relacionada à rede subjacente. Talvez adicionar opções para informar sua "interface pública" e "interface privada" desejadas e fazer com que o kubeadm recomende alterações na configuração da rede?

Não acho que o kubeadm deva divulgar o sistema operacional ou as instruções de configuração específicas da distro para rede de host. Acho que é responsabilidade do operador configurar seu host de forma adequada, caso contrário, ele se torna uma toca de coelho. Certamente podemos torná-lo um requisito, no entanto.

O que o kubeadm deve esperar para que as coisas funcionem? Se o usuário deseja usar uma NIC não padrão, ele precisa adicionar uma rota estática no Linux? Este é um caso de uso geral o suficiente para adicioná-lo como um requisito do sistema?

@bboreham Alguma idéia de como podemos melhorar nossa documentação aqui? Caso contrário, sou a favor de encerrar porque:

1. parece estar relacionado ao ambiente de rede de um usuário, não ao kubeadm
2. não há uma maneira única de esclarecer essas expectativas

[À parte: me incomoda, tenho que ler de cima a baixo e por meio de outras questões para retornar ao contexto. O problema que as pessoas queriam resolver não tem absolutamente nada a ver com o título desta questão]

Nos documentos de configuração, você pode dizer "se você tiver mais de um adaptador de rede e seus componentes do Kubernetes não forem alcançáveis ​​na rota padrão, recomendamos adicionar rota (s) de IP para que os endereços de cluster do Kubernetes passem pelo adaptador apropriado".

[À parte: me incomoda, tenho que ler de cima a baixo e através de outras questões para retornar ao contexto. O problema que as pessoas queriam resolver não tem absolutamente nada a ver com o título desta questão]

Você não é o único! 😅

Nos documentos de configuração, você pode dizer "se você tiver mais de um adaptador de rede e seus componentes do Kubernetes não forem alcançáveis ​​na rota padrão, recomendamos adicionar rota (s) de IP para que os endereços de cluster do Kubernetes passem pelo adaptador apropriado".

Legal, vou tentar enviar um PR de documentos para isso amanhã e fechar isso.

Isso agora está documentado em https://github.com/kubernetes/website/pull/6265 , então vou encerrar.

Este problema parece rastrear alguns problemas diferentes ao mesmo tempo, portanto, se você ainda estiver enfrentando um bug em potencial, abra um novo problema para que possamos direcionar melhor a causa raiz.

FWIW, se você usar kubeadm para iniciar o cluster, se você especificar o "pod-network-cidr", isso será passado para o kube-proxy quando ele iniciar como "cluster-cidr". Por exemplo, o padrão do weave é usar "10.32.0.0/12"...so eu usei kubeadm init --kubernetes-version=v.1.8.4 --pod-network-cidr=10.32.0.0/12 que iniciou o kube-proxy com cluster-cidr=10.32.0.0/12

@bboreham Sou novo nisso ...

@ bamb00 scroll up; há um exemplo em https://github.com/kubernetes/kubeadm/issues/102#issuecomment -291532883

Cuidado : se você der um passo errado, sua máquina poderá ficar inacessível. Geralmente isso voltará após uma reinicialização, a menos que você tenha configurado a rota incorreta para estar lá na inicialização.

Não conheço uma maneira fácil de aprender a configuração de rede Linux.

@mindscratch note que este problema não tem nada a ver com "cluster-cidr"; essa foi uma pista falsa eliminada há cerca de sete meses. Abra um novo problema se você estiver tendo novos problemas.

Sugestão semi-séria para corrigir este caso específico sem exigir que kube-proxy use ! -s $podCIDR para distinguir o endereço de origem do host:

$ sudo ip ro add local 10.96.0.0/12 table local dev lo
$ sudo iptables -t nat -I KUBE-SERVICES -s 10.96.0.0/12 -d 10.96.0.0/12 -j KUBE-MARK-MASQ

(ou possivelmente alguma variação com um ... src 10.96.0.0 explícito na rota local ... o table local provavelmente também é desnecessário e uma má ideia)

$ ip ro get 10.96.0.1
local 10.96.0.1 dev lo  src 10.96.0.1 
    cache <local> 
$ curl -vk https://10.96.0.1
...
* Connected to 10.96.0.1 (10.96.0.1) port 443 (#0)

11:32:20.671085 0c:c4:7a:54:0a:e6 > 44:aa:50:04:3d:00, ethertype IPv4 (0x0800), length 74: 10.80.4.149.59334 > 10.80.4.147.6443: Flags [S], seq 2286812584, win 43690, options [mss 65495,sackOK,TS val 209450 ecr 0,nop,wscale 8], length 0
11:32:20.671239 44:aa:50:04:3d:00 > 0c:c4:7a:54:0a:e6, ethertype IPv4 (0x0800), length 74: 10.80.4.147.6443 > 10.80.4.149.59334: Flags [S.], seq 1684666695, ack 2286812585, win 28960, options [mss 1460,sackOK,TS val 208877 ecr 209450,nop,wscale 8], length 0
11:32:20.671315 0c:c4:7a:54:0a:e6 > 44:aa:50:04:3d:00, ethertype IPv4 (0x0800), length 66: 10.80.4.149.59334 > 10.80.4.147.6443: Flags [.], ack 1, win 171, options [nop,nop,TS val 209450 ecr 208877], length 0

No entanto, não tenho ideia se isso abrange todos os comportamentos esperados dessas regras MASQ de kube-proxy específicas da fonte ...

EDITAR: isso também tem todos os tipos de efeitos colaterais para conexões com VIPs de serviço não configurados ... eles acabarão se conectando a qualquer serviço de namespace de rede host correspondente.

EDIT2: No entanto, mesmo isso é provavelmente melhor do que o comportamento atual de vazamento de conexões para VIPs de serviço 10.96.XY não configurados através da rota padrão ... o que é vagamente perturbador