înregistrare Logare
Puncte:2
avatar Server

kube-proxy nu funcționează pentru IP-urile clusterului de servicii

drapel es
derabbink

Am instalat un cluster k8s 1.23.3 pe patru sisteme de operare raspberrypi raspberrypi 11 (bullseye) braț64; mai ales prin urmare acest ghid.
Esența este că planul de control a fost creat folosind această comandă

kubeadm init --token={some_token} --kubernetes-version=v1.23.3 --pod-network-cidr=10.1.0.0/16 --service-cidr=10.11.0.0/16 --control-plane-endpoint= 10.0.4.16 --node-name=rpi-1-1

Apoi mi-am creat propriul meu kube-verify namespace, puneți o implementare a echo-server în el și a creat un serviciu pentru el.

In orice caz, Nu pot ajunge la IP-ul cluster al serviciului de la niciunul dintre noduri. De ce? Solicitările pur și simplu expiră, în timp ce solicitările către IP-ul cluster al podului funcționează bine.
Bănuiesc că al meu kube-proxy nu funcționează așa cum ar trebui. Mai jos este ceea ce am investigat până acum.

$ kubectl obține servicii -n kube-verify -o=wide

NUME TIP CLUSTER-IP EXTERN-IP PORT(E) SELECTOR DE VÂRSTE
echo-server ClusterIP 10.11.213.180 <niciunul> 8080/TCP 24h app=echo-server

$ kubectl obține pods -n kube-system -o=wide

NUME PREGĂTIT STAREA RESTARTE Vârsta IP NODE NOMINAT NODUL GATES DE PREGĂTIRE
coredns-64897985d-47gpr 1/1 Alergare 1 (acum 69 m) 41 h 10.1.0.5 rpi-1-1 <niciunul> <niciunul>
coredns-64897985d-nf55w 1/1 Alergare 1 (acum 69 m) 41 ore 10.1.0.4 rpi-1-1 <niciunul> <niciunul>
etcd-rpi-1-1 1/1 Alergare 2 (acum 69 m) 41 h 10.0.4.16 rpi-1-1 <niciunul> <niciunul>
kube-apiserver-rpi-1-1 1/1 Alergare 2 (acum 69 m) 41 h 10.0.4.16 rpi-1-1 <niciunul> <niciunul>
kube-controller-manager-rpi-1-1 1/1 Alergare 2 (acum 69 m) 41 ore 10.0.4.16 rpi-1-1 <niciunul> <niciunul>
kube-flannel-ds-5467m 1/1 Alergare 1 (acum 69 m) 28h 10.0.4.17 rpi-1-2 <niciunul> <niciunul>
kube-flannel-ds-7wpvz 1/1 Alergare 1 (acum 69 m) 28 ore 10.0.4.18 rpi-1-3 <niciunul> <niciunul>
kube-flannel-ds-9chxk 1/1 Alergare 1 (acum 69 m) 28 ore 10.0.4.19 rpi-1-4 <niciunul> <niciunul>
kube-flannel-ds-x5rvx 1/1 Alergare 1 (acum 69 m) 29 ore 10.0.4.16 rpi-1-1 <niciunul> <niciunul>
kube-proxy-8bbjn 1/1 Alergare 1 (acum 69 m) 28 ore 10.0.4.17 rpi-1-2 <niciunul> <niciunul>
kube-proxy-dw45d 1/1 Running 1 (acum 69m) 28h 10.0.4.18 rpi-1-3 <niciunul> <niciunul>
kube-proxy-gkkxq 1/1 Alergare 2 (acum 69 m) 41 h 10.0.4.16 rpi-1-1 <niciunul> <niciunul>
kube-proxy-ntl5w 1/1 Running 1 (acum 69 m) 28h 10.0.4.19 rpi-1-4 <niciunul> <niciunul>
kube-scheduler-rpi-1-1 1/1 Alergare 2 (acum 69 m) 41 ore 10.0.4.16 rpi-1-1 <niciunul> <niciunul>

$ kubectl înregistrează kube-proxy-gkkxq -n kube-system

I0220 13:52:02.281289 1 node.go:163] IP nod preluat cu succes: 10.0.4.16
I0220 13:52:02.281535 1 server_others.go:138] „Adresă IP nod detectat”="10.0.4.16"
I0220 13:52:02.281610 1 server_others.go:561] „Mod proxy necunoscut, presupunând proxy iptables” proxyMode=""
I0220 13:52:02.604880 1 server_others.go:206] „Utilizarea iptables Proxier”
I0220 13:52:02.604966 1 server_others.go:213] „kube-proxy rulează în modul dual-stack” ipFamily=IPv4
I0220 13:52:02.605026 1 server_others.go:214] „Se creează dualStackProxier pentru iptables”
I0220 13:52:02.605151 1 server_others.go:491] „Detect-local-mode set to ClusterCIDR, but no IPv6 cluster CIDR defined, , default to no-op detect-local for IPv6”
I0220 13:52:02.606905 1 server.go:656] „Informații despre versiune” version="v1.23.3"
W0220 13:52:02.614777 1 sysinfo.go:203] Topologia nodurilor nu este disponibilă, oferind topologia CPU
I0220 13:52:02.619535 1 conntrack.go:52] „Setarea nf_conntrack_max” nf_conntrack_max=131072
I0220 13:52:02.620869 1 conntrack.go:100] „Set sysctl” entry="net/netfilter/nf_conntrack_tcp_timeout_close_wait" value=3600
I0220 13:52:02.660947 1 config.go:317] „Se pornește controlerul de configurare a serviciului”
I0220 13:52:02.661015 1 shared_informer.go:240] Se așteaptă sincronizarea cache-urilor pentru configurarea serviciului
I0220 13:52:02.662669 1 config.go:226] „Se pornește controlerul de configurare a segmentului final”
I0220 13:52:02.662726 1 shared_informer.go:240] Se așteaptă sincronizarea cache-urilor pentru configurarea secțiunii punctului final
I0220 13:52:02.762734 1 shared_informer.go:247] Cache-urile sunt sincronizate pentru configurarea serviciului 
I0220 13:52:02.762834 1 shared_informer.go:247] Cache-urile sunt sincronizate pentru configurarea segmentelor de punct final

Ceea ce observ aici este că Topologia nodurilor nu este disponibilă, așa că am mai săpat în configurația kube-proxy, dar nimic nu iese în evidență pentru mine.
Dacă există într-adevăr o problemă cu topologia nodurilor din clusterul meu, vă rugăm să mă direcționați către câteva resurse despre cum să depanez acest lucru, deoarece nu am putut găsi nimic semnificativ pe baza acestui mesaj de eroare.

$ kubectl descrie configmap kube-proxy -n kube-system

Nume: kube-proxy
Spațiu de nume: kube-system
Etichete: app=kube-proxy
Adnotări: kubeadm.kubernetes.io/component-config.hash: sha256:edce433d45f2ed3a58ee400690184ad033594e8275fdbf52e9c8c852caa7124d

Date
====
config.conf:
----
apiVersion: kubeproxy.config.k8s.io/v1alpha1
bindAddress: 0.0.0.0
bindAddressHardFail: fals
clientConnection:
  acceptContentTypes: ""
  izbucnire: 0
  tipul de conținut: ""
  kubeconfig: /var/lib/kube-proxy/kubeconfig.conf
  qps: 0
clusterCIDR: 10.1.0.0/16
configSyncPeriod: 0s
contratrack:
  maxPerCore: nul
  min: nul
  tcpCloseWaitTimeout: nul
  tcpEstablishedTimeout: nul
detectLocalMode: ""
enableProfiling: false
healthzBindAddress: ""
hostnameOverride: ""
iptables:
  masqueradeAll: false
  masqueradeBit: nul
  minSyncPeriod: 0s
  syncPeriod: 0s
ipvs:
  excludeCIDR-uri: nul
  minSyncPeriod: 0s
  programator: ""
  strictARP: fals
  syncPeriod: 0s
  tcpFinTimeout: 0s
  tcpTimeout: 0s
  udpTimeout: 0s
fel: KubeProxyConfiguration
metricsBindAddress: ""
modul: ""
nodePortAddresses: null
oomScoreAdj: nul
portRange: ""
showHiddenMetricsForVersion: ""
udpIdleTimeout: 0s
winkernel:
  enableDSR: fals
  numele retelei: ""
  sourceVip: ""
kubeconfig.conf:
----
apiVersion: v1
fel: Config
clustere:
- cluster:
    autoritate de certificare: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
    server: https://10.0.4.16:6443
  nume: implicit
contexte:
- context:
    cluster: implicit
    spatiu de nume: implicit
    utilizator: implicit
  nume: implicit
contextul curent: implicit
utilizatori:
- nume: implicit
  utilizator:
    tokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token

BinaryData
====

Evenimente: <niciunul>

$ kubectl -n kube-system exec kube-proxy-gkkxq cat /var/lib/kube-proxy/kubeconfig.conf

kubectl exec [POD] [COMANDĂ] este DEPRECAT și va fi eliminat într-o versiune viitoare. Folosiți kubectl exec [POD] -- [COMANDĂ] în schimb.
apiVersion: v1
fel: Config
clustere:
- cluster:
    autoritate de certificare: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
    server: https://10.0.4.16:6443
  nume: implicit
contexte:
- context:
    cluster: implicit
    spatiu de nume: implicit
    utilizator: implicit
  nume: implicit
contextul curent: implicit
utilizatori:
- nume: implicit
  utilizator:
    tokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token

The modul implicit la iptables, după cum confirmă jurnalele de mai sus.
Am și redirecționarea IP activată pe toate nodurile.

$ sudo sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1
455
0 + 0
moonkotte avatar
drapel in
moonkotte
Se pare că există o problemă cu subrețele: pod network cidr este `10.1.0.0/16` și punctul final al planului de control este de fapt în pod network cidr (din moment ce este `10.1.0.4`). De asemenea, ați schimbat `pod network cidr` când ați instalat `flannel`? În mod implicit, folosește un `cidr` diferit.
0
Răspunde
drapel es
derabbink
Am instalat flannel astfel: `kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/v0.16.3/Documentation/kube-flannel.yml`. Comanda mea `kubeadm init` avea setate steaguri `--pod-network-cidr=10.1.0.0/16` și `--control-plane-endpoint=10.0.4.16`
0
Răspunde
moonkotte avatar
drapel in
moonkotte
Puteți verifica ce este în interior în configurația yaml a flanelului. Veți vedea că `"Network": "10.244.0.0/16"` este setat la o subrețea diferită de cea pe care ați inițiat clusterul cu opțiunea `--pod-network-cidr=10.1.0.0/16`. Aveți 2 opțiuni pentru a o remedia: puteți schimba subrețeaua în yaml de flanel la aceeași cu `--pod-network-cidr=10.1.0.0/16` sau puteți distruge cluster-ul și începe cu aceeași subrețea ca în yaml de flanel `"Rețea": "10.244.0.0/16"`
0
Răspunde
drapel es
derabbink
Mulțumiri. Aceasta a făcut trucul. Dacă doriți, puteți crea un răspuns și mă voi asigura că îl accept. Și ulterior aș putea sugera o editare care adaugă un script pentru a rescrie automat acel fișier YAML folosind `yq` și `jq`
0
Răspunde
moonkotte avatar
drapel in
moonkotte
Sigur Multumesc. Prietenul meu @radekw va posta răspunsul pentru mine, deoarece are nevoie de ceva reputație + mi-a dat acea sugestie. Simțiți-vă liber să îl acceptați și să sugerați o modificare.
0
Răspunde
Puncte:1
RadekW avatar Server
drapel cn
RadekW

Flanel poate fi instalat prin aplicarea unui manifest din depozit.

Flannel poate fi adăugat la orice cluster Kubernetes existent, deși este cel mai simplu de adăugat flanel înainte ca orice pod-uri care utilizează rețeaua de pod-uri să fi fost pornit. Pentru Kubernetes v1.17+ kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml

După cum puteți vedea în asta yaml subrețeaua de rețea este setată în mod implicit la 10.244.0.0/16

  net-conf.json: |
    {
      „Rețea”: „10.244.0.0/16”,
      „Backend”: {
        „Tip”: „vxlan”
      }

kubeadm init este o comanda pentru a iniția un cluster care necesită specificarea unei subrețea pentru rețeaua cluster și trebuie să fie aceeași cu subrețea din CNI. Puteți verifica pentru mai multe Opțiuni.

--pod-network-cidr șir Specificați intervalul de adrese IP pentru rețeaua pod. Dacă este setat, planul de control va aloca automat CIDR-uri pentru fiecare nod.

Ai inițiat un cluster cu --pod-network-cidr=10.1.0.0/16 iar subrețeaua clusterului dvs. a fost setată la diferită de subrețea din fișierul yaml al manifestului flannel "10.244.0.0/16" și de aceea nu a funcționat.

Există două opțiuni pentru a o remedia:
Mai întâi - schimbați subrețeaua în configurația yaml de flanel la aceeași cu care a fost aplicată atunci când cluster-ul a fost inițial, în acest caz este --pod-network-cidr=10.1.0.0/16 (vezi scenariul de mai jos)
SAU
În al doilea rând - dacă clusterul este în scopuri de testare și tocmai a fost inițiat, atunci distrugeți un cluster și începeți cu aceeași subrețea ca și configurația Yaml de flanel „Rețea”: „10.244.0.0/16”

Pentru a modifica automat kube-flannel.yml, următorul script bazat pe yq și jq comenzile pot fi folosite:

#!/bin/bash

intrare=$1
ieșire = $2

echo „Conversia $input la $output”

netconf=$( yq '. | select(.kind == "ConfigMap") | select(.metadata.name == "kube-flannel-cfg") | .data."net-conf.json"' "$input " | jq 'fromjson | .Network="10.1.0.0/16"' | yq -R '.' )
kube_flannel_cfg=$( yq --yaml-output '. | select(.kind == "ConfigMap") | select(.metadata.name == "kube-flannel-cfg") | .data."net-conf.json "='"$netconf" "$input" )
everything_else=$( yq --yaml-output '. | select(.kind != "ConfigMap") | select(.metadata.name != "kube-flannel-cfg")' "$input" )
echo „$kube_flannel_cfg” >> „$ieșire”
echo '---' >> "$ieșire"
echo „$everything_else” >> „$ieșire”
0 + 0
drapel romania
SEF 777
întrebarea această in alte limbi:

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.