înregistrare Logare
Puncte:2
Volker Raschek avatar Server

archlinux: kubernetes - coredns nu funcționează corect

drapel in
Volker Raschek

Am instalat kubernetes v1.23.0 cu Arch Linux ca distribuție. Clusterul este format dintr-un master și un nod. Sistemele de cabine sunt VM bazate pe KVM.

Când un pod dorește să facă o interogare DNS, primește un timeout când serviciul înaintează cererile către o instanță pod de coredns care rulează pe un alt nod kubernetes.

Prin urmare, bănuiesc că furnizorul de rețea nu funcționează corect sau unele setări (module kernel, sysctl, etc) nu sunt setate, deoarece atunci când cererea este transmisă la instanța pod coredns care rulează local, clientul primește un răspuns. Iată pașii mei de depanare:

  1. Înainte de a începe depanarea, am crescut nivelul de log al coredns prin adăugare Buturuga la configmapa de coredns.
# kubectl get -n kube-system configmaps coredns -o yaml
apiVersion: v1
date:
  Fișier principal: |
    .:53 {
        Buturuga
        erori
        sanatate {
           lameduck 5s
        }
        gata
        kubernetes cluster.local in-addr.arpa ip6.arpa {
           păstăi nesigure
           fallthrough in-addr.arpa ip6.arpa
           ttl 30
        }
        prometheus :9153
        înainte . /etc/resolv.conf {
           max_concurrent 1000
        }
        cache 30
        buclă
        reîncărcați
        echilibrul de sarcină
    }
  1. Am implementat ca mediu de depanare containerul meu de rețea cu instrumente de rețea precum săpa, nslookup și așa mai departe pentru a testa diferitele instanțe coredns.
kubectl apply -f https://raw.githubusercontent.com/volker-raschek/network-tools/master/network-tools.yml
  1. Următoarele poduri și servicii de coredns sunt disponibile:
kubectl get pod,service -n kube-system -l k8s-app=kube-dns -o wide
NUME PREGĂTIT STAREA RESTARTE Vârsta IP NODE NOMINAT NODUL GATES DE PREGĂTIRE
pod/coredns-64897985d-cgxmv 1/1 Rulează 0 24 de ore 10.85.0.4 archlinux-x86-64-000 <niciunul> <niciunul>
pod/coredns-64897985d-l9ftl 1/1 Rulează 0 24h 10.85.0.3 archlinux-x86-64-001 <niciunul> <niciunul>

NUME TIP CLUSTER-IP EXTERN-IP PORT(E) SELECTOR DE VÂRSTE
service/kube-dns ClusterIP 10.96.0.10 <none> 53/UDP,53/TCP,9153/TCP 24h k8s-app=kube-dns
  1. Execut un shell în podul meu de rețea și încearcă să interogheze adresa IP a google.com prin intermediul coredns serviciu. Modul de recunoaștere a comenzii durează diferite perioade de timp. Din păcate, nu am putut reproduce o eroare de timeout prin intermediul serviciului:
# kubectl exec network-tools -- time dig A google.com @10.96.0.10 +short
142.250.185.238
real 0m 5.02s
utilizator 0m 0.02s
sys 0m 0.00s
# kubectl exec network-tools -- time dig A google.com @10.96.0.10 +short
142.250.185.238
real 0m 0.03s
utilizator 0m 0.01s
sys 0m 0.00s
# kubectl exec network-tools -- time dig A google.com @10.96.0.10 +short
142.250.185.238
real 0m 10.03s
utilizator 0m 0.01s
sys 0m 0.01s
  1. Acum limitez interogarea la diferitele poduri coredns. Rețineți că podul coredns-64897985d-cgxmv cu IP-ul 10.85.0.4 rulează pe un alt nod.

pod/coredns-64897985d-l9ftl / 10.85.0.3

kubectl exec network-tools -- time dig A google.com @10.85.0.3 +short
142.251.36.206
real 0m 0.09s
utilizator 0m 0.00s
sys 0m 0.01s

pod/coredns-64897985d-cgxmv / 10.85.0.4

Iată eroarea de timeout atunci când se utilizează în mod explicit coredns pod al altui nod.

# kubectl exec network-tools -- time dig A google.com @10.85.0.4 +short

; <<>> DiG 9.16.20 <<>> A google.com @10.85.0.4 +scurt
;; opțiuni globale: +cmd
;; conexiunea a expirat; niciun server nu a putut fi atins

Comanda a ieșit cu starea diferită de zero 9
real 0m 15.02s
utilizator 0m 0.02s
sys 0m 0.00s
comanda terminată cu codul de ieșire 9
  1. Următoarele jurnale au fost scrise de către coredns păstăi:

pod/coredns-64897985d-l9ftl / 10.85.0.3

# kubectl logs -n kube-system coredns-64897985d-l9ftl 
.:53
[INFO] plugin/reîncărcare: rulează configurația MD5 = db32ca3650231d74073ff4cf814959a7
CoreDNS-1.8.6
linux/amd64, go1.17.1, 13a9191
[INFO] Se reîncarcă
[INFO] plugin/sănătate: Treci în modul lameduck timp de 5 secunde
[INFO] plugin/reîncărcare: rularea configurației MD5 = 3d3f6363f05ccd60e0f885f0eca6c5ff
[INFO] Reîncărcare finalizată
[INFO] 127.0.0.1:54962 - 9983 "HINFO IN 4683476401105705616.5032820535498752139. udp 57 false 512" NXDOMAIN qr,rd,030232,ra.
[INFO] 10.85.0.1:24999 - 26748 "A IN google.com. udp 51 false 4096" NOERROR qr,rd,ra 1549 0.070006969s
[INFO] 10.85.0.1:6142 - 9467 "A IN google.com. udp 51 false 4096" NOERROR qr,aa,rd,ra 1549 0.000959536s
[INFO] 10.85.0.1:2544 - 20425 „A IN google.com. udp 51 false 4096” NOERROR qr,aa,rd,ra 1549 0.00065977s
[INFO] 10.85.0.1:26782 - 372 "A IN google.com. udp 51 false 4096" NOERROR qr,aa,rd,ra 1549 0.001292768s
[INFO] 10.85.0.1:62687 - 27302 „A IN google.com. udp 51 false 4096” 
...

pod/coredns-64897985d-cgxmv / 10.85.0.4

# kubectl logs -n kube-system coredns-64897985d-cgxmv
.:53
[INFO] plugin/reîncărcare: rulează configurația MD5 = db32ca3650231d74073ff4cf814959a7
CoreDNS-1.8.6
linux/amd64, go1.17.1, 13a9191
[INFO] Se reîncarcă
[INFO] plugin/sănătate: Treci în modul lameduck timp de 5 secunde
[INFO] plugin/reîncărcare: rularea configurației MD5 = 3d3f6363f05ccd60e0f885f0eca6c5ff
[INFO] Reîncărcare finalizată

Pentru a restrânge problema, mi-am reinstalat cluster-ul prin ansible și am instalat calico în loc de flanel prin comanda de mai jos. Aceeași problemă există acolo.

$ helm install calico projectcalico/tigera-operator --versiunea v3.21.3

Am folosit ghid de instalare a kubeadm pentru a inițializa clusterul. Am executat următoarele kubeadmin init comandă pentru a inițializa clusterul:

$ kubeadm init \
  --apiserver-advertise-address=192.168.179.101 \
  --apiserver-cert-extra-sans=api.example.com \
  --control-plane-endpoint=192.168.179.100 \
  --cri-socket=unix:///var/run/crio/crio.sock \
  --pod-network-cidr=10.244.0.0/16 \
  --upload-certs

Modulul nucleului br_netfilter și proprietățile sysctl sunt definite, dar problema încă există. Sunt la sfârșitul soluțiilor mele și am nevoie de sfaturi de la experți de aici. Mai jos este o listă cu modulele mele kernel, setările sysctl și alte informații.

Sper sa ma ajute cineva.

informațiile nucleului

$ uname -a
Linux archlinux-x86-64-000 5.10.90-1-lts #1 SMP miercuri, 05 ianuarie 2022 13:07:40 +0000 x86_64 GNU/Linux

modulele nucleului

$ lsmod | fel
ac97_bus 16384 1 snd_soc_core
aesni_intel 372736 0
agpgart 53248 4 intel_agp,intel_gtt,ttm,drm
atkbd 36864 0
bpf_preload 16384 0
bridge 274432 1 br_netfilter
br_netfilter 32768 0
cec 61440 1 drm_kms_helper
cfg80211 983040 0
crc16 16384 1 ext4
crc32c_generic 16384 0
crc32c_intel 24576 3
crc32_pclmul 16384 0
crct10dif_pclmul 16384 1
cryptd 24576 2 crypto_simd,ghash_clmulni_intel
crypto_simd 16384 1 aesni_intel
drm 577536 5 drm_kms_helper,qxl,drm_ttm_helper,ttm
drm_kms_helper 278528 3 qxl
drm_ttm_helper 16384 1 qxl
ext4 933888 1
failover 16384 1 net_failover
grasime 86016 1 vfat
fb_sys_fops 16384 1 drm_kms_helper
siguranța 167936 1
ghash_clmulni_intel 16384 0
glue_helper 16384 1 aesni_intel
i2c_i801 36864 0
i2c_smbus 20480 1 i2c_i801
i8042 36864 0
intel_agp 24576 0
intel_gtt 24576 1 intel_agp
intel_pmc_bxt 16384 1 iTCO_wdt
intel_rapl_common 28672 1 intel_rapl_msr
intel_rapl_msr 20480 0
ip6_udp_tunnel 16384 1 vxlan
ip_set 57344 0
ip_tables 32768 0
ipt_REJECT 16384 0
ip_vs 184320 6 ip_vs_rr,ip_vs_sh,ip_vs_wrr
ip_vs_rr 16384 0
ip_vs_sh 16384 0
ip_vs_wrr 16384 0
irqbypass 16384 1 kvm
iTCO_vendor_support 16384 1 iTCO_wdt
iTCO_wdt 16384 0
jbd2 151552 1 ext4
joydev 28672 0
kvm 933888 1 kvm_intel
kvm_intel 331776 0
ledtrig_audio 16384 1 snd_hda_codec_generic
libcrc32c 16384 4 nf_conntrack,nf_nat,nf_tables,ip_vs
libps2 20480 2 atkbd,psmouse
llc 16384 2 pod,stp
lpc_ich 28672 0
mac_hid 16384 0
mbcache 16384 1 ext4
Dimensiunea modulului utilizat de
mousedev 24576 0
net_failover 24576 1 virtio_net
nf_conntrack 172032 6 xt_conntrack,nf_nat,xt_nat,nf_conntrack_netlink,xt_MASQUERADE,ip_vs
nf_conntrack_netlink 57344 0
nf_defrag_ipv4 16384 1 nf_conntrack
nf_defrag_ipv6 24576 2 nf_conntrack,ip_vs
nf_nat 57344 3 xt_nat,nft_chain_nat,xt_MASQUERADE
nfnetlink 20480 4 nft_compat,nf_conntrack_netlink,nf_tables,ip_set
nf_reject_ipv4 16384 1 ipt_REJECT
nf_tables 249856 183 nft_compat,nft_counter,nft_chain_nat
nft_chain_nat 16384 7
nft_compat 20480 122
nft_counter 16384 84
nls_iso8859_1 16384 0
suprapunere 147456 18
bucpkr 16384 0
psmouse 184320 0
qemu_fw_cfg 20480 0
qxl 73728 0
rapl 16384 0
rfkill 28672 2 cfg80211
rng_core 16384 1 virtio_rng
serio 28672 6 serio_raw,atkbd,psmouse,i8042
serio_raw 20480 0
snd 114688 8 snd_hda_codec_generic,snd_hwdep,snd_hda_intel,snd_hda_codec,snd_timer,snd_compress,snd_soc_core,snd_pcm
snd_compress 32768 1 snd_soc_core
snd_hda_codec 172032 2 snd_hda_codec_generic,snd_hda_intel
snd_hda_codec_generic 98304 1
snd_hda_core 110592 3 snd_hda_codec_generic,snd_hda_intel,snd_hda_codec
snd_hda_intel 57344 0
snd_hwdep 16384 1 snd_hda_codec
snd_intel_dspcfg 28672 1 snd_hda_intel
snd_pcm 147456 7 snd_hda_intel,snd_hda_codec,soundwire_intel,snd_compress,snd_soc_core,snd_hda_core,snd_pcm_dmaengine
snd_pcm_dmaengine 16384 1 snd_soc_core
snd_soc_core 327680 1 soundwire_intel
snd_timer 49152 1 snd_pcm
soundcore 16384 1 snd
soundwire_bus 90112 3 soundwire_intel,soundwire_generic_allocation,soundwire_cadence
soundwire_cadence 36864 1 soundwire_intel
soundwire_generic_allocation 16384 1 soundwire_intel
soundwire_intel 45056 1 snd_intel_dspcfg
stp 16384 1 pod
syscopyarea 16384 1 drm_kms_helper
sysfillrect 16384 1 drm_kms_helper
sysimgblt 16384 1 drm_kms_helper
ttm 114688 2 qxl,drm_ttm_helper
udp_tunnel 20480 1 vxlan
usbhid 65536 0
veth 32768 0
vfat 24576 0
virtio_balloon 24576 0
virtio_blk 20480 2
virtio_console 40960 0
virtio_net 61440 0
virtio_pci 28672 0
virtio_rng 16384 0
vxlan 77824 0
xhci_pci 20480 0
xhci_pci_renesas 20480 1 xhci_pci
x_tables 53248 11 xt_conntrack,xt_statistic,nft_compat,xt_tcpudp,xt_addrtype,xt_nat,xt_comment,ipt_REJECT,ip_tables,xt_MASQUERADE,xt_mark
xt_addrtype 16384 2
xt_comment 16384 64
xt_conntrack 16384 13
xt_mark 16384 12
xt_MASQUERADE 20480 6
xt_nat 16384 7
xt_statistic 16384 3
xt_tcpudp 20480 15

sysctl

proprietăți sysctl activate pastbin. Depășește numărul maxim de caractere pentru serverfault.

302
0 + 0
Mikolaj S. avatar
drapel cn
Mikolaj S.
Ați putea, vă rog, să clarificați acest lucru -> „Când un pod dorește să facă o interogare DNS către coredns, primește un timeout când serviciul trimite cererile către o instanță pod de coredns care rulează extern.” Cum faci o interogare DNS către CoreDNS? De unde știi că are timeout? Ați putea verifica jurnalele podurilor CoreDNS (`kubectl logs --namespace=kube-system -l k8s-app=kube-dns`)?
0
Răspunde
Volker Raschek avatar
drapel in
Volker Raschek
@MikolajS. Am schimbat descrierea problemei și am adăugat câteva informații suplimentare
0
Răspunde
Mikolaj S. avatar
drapel cn
Mikolaj S.
Ați putea, vă rog, să împărtășiți steaguri pe care le-ați folosit pentru comanda `kubeadm init`? Mai ales, ai folosit flag `--pod-network-cidr`? Cum ați instalat Calico CNI - sunt puține soluții posibile, pe care ați folosit-o? Ați specificat un [pod CIDR și pentru Calico](https://projectcalico.docs.tigera.io/getting-started/kubernetes/self-managed-onprem/onpremises#install-calico-on-nodes)?
0
Răspunde
Volker Raschek avatar
drapel in
Volker Raschek
Bună @MikolajS., am schimbat din nou descrierea și am adăugat comanda `kubeadm init`. Da, am folosit steag-ul `--pod-network-cidr` și am instalat calico prin cârmă. Nu s-au făcut modificări la values.yaml și variabila de mediu `CALICO_IPV4POOL_CIDR` nu este definită.
0
Răspunde
Volker Raschek avatar
drapel in
Volker Raschek
Pentru a instala kubernetes, pachetul `iptables` a trebuit să fie [înlocuit](https://github.com/archlinux/svntogit-community/blob/packages/kubernetes/trunk/PKGBUILD#L14) de către `iptables-nft` . Schimbarea nu a cauzat poate restricțiile? Am găsit următoarea postare despre dezactivarea modulului iptables. https://mihail-milev.medium.com/no-pod-to-pod-communication-on-centos-8-kubernetes-with-calico-56d694d2a6f4
0
Răspunde
Mikolaj S. avatar
drapel cn
Mikolaj S.
Mulțumesc pentru toate informațiile, voi încerca să replic problema dvs. și voi verifica ce se poate face.
0
Răspunde
Mikolaj S. avatar
drapel cn
Mikolaj S.
Ați verificat cu ambele `iptables` instalate (mă refer la cea moștenită și versiunea nft)? Ai putea rula comanda `iptables -v`?
0
Răspunde
Volker Raschek avatar
drapel in
Volker Raschek
Buna @MikolajS., am gasit solutia de ce nu merge calico si celelalte plugin-uri cni. Iată discuția despre problema runtime-ului crio de bază https://github.com/cri-o/cri-o/issues/2885#issuecomment-1015732983
0
Răspunde
Puncte:1
Mikolaj S. avatar Server
drapel cn
Mikolaj S.

Postarea răspunsului wiki comunității pe baza subiectului GitHub - Fișierele incluse în CentOS RPM interferează cu funcționarea CNI și pagina wiki ArchLinux - CRIO-O. Simțiți-vă liber să-l extindeți.

Problema este cunoscută și descrisă în wiki ArchLinux:

Avertizare: Arch instalează pluginurile furnizate de cni-plugin-uri ambilor /usr/lib/cni și /opt/cni/bin dar majoritatea celorlalte plugin-uri (de exemplu, implementări în cluster, plugin-uri gestionate de kubelet etc.) se instalează implicit doar în al doilea director.

CRI-O este configurat doar pentru a căuta pluginuri în primul director și, prin urmare, orice plugin din al doilea director nu este disponibil fără unele modificări de configurare.

Soluția este prezentată în această postare de către utilizatorul bart0sh:

Folosesc următoarea soluție:

  • instalați cri-o
  • ștergeți totul din /etc/cni/net.d
  • nodul de configurare cu kubeadm
  • instalați pluginul cni (wave, flanel, calico, etc)

și configurație suplimentară prezentată de utilizatorul volker-raschek:

Pe langa configuratiile CNI sub /etc/cni/net.d, prelungirea lui plugin_dirs proprietatea lipsea în crio.conf configurație, deoarece crio nu pare să se uite înăuntru /opt/cni pentru pluginurile lansate în mod implicit. Am creat un fișier drop-in.

$ cat /etc/crio/crio.conf.d/00-plugin-dir.conf
[crio.network]
plugin_dirs = [
 „/opt/cni/bin/”,
 „/usr/lib/cni”,
]
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.