Networking
archlinux：kubernetes - coredns 無法正常工作
我已經安裝了
v1.23.0帶有 Arch Linux 作為發行版的 kubernetes。集群由一個主節點和一個節點組成。Booth 系統是基於 KVM 的虛擬機。當 Pod 想要進行 DNS 查詢時，當服務將請求轉發到在另一個 kubernetes 節點上執行的 coredns 的 Pod 實例時，它會超時。
所以我懷疑網路提供商工作不正常或某些設置（核心模組、sysctl 等）未設置，因為當請求轉發到本地執行的 coredns pod 實例時，客戶端會收到響應。這是我的調試步驟：
- 在開始調試之前，我通過添加
log到 coredns 的 configmap 來提高 coredns 的 loglevel。# kubectl get -n kube-system configmaps coredns -o yaml apiVersion: v1 data: Corefile: | .:53 { log errors health { lameduck 5s } ready kubernetes cluster.local in-addr.arpa ip6.arpa { pods insecure fallthrough in-addr.arpa ip6.arpa ttl 30 } prometheus :9153 forward . /etc/resolv.conf { max_concurrent 1000 } cache 30 loop reload loadbalance }
- 我將我的網路容器部署為調試環境，使用諸如 等網路工具
dig來nslookup測試不同的 coredns 實例。kubectl apply -f https://raw.githubusercontent.com/volker-raschek/network-tools/master/network-tools.yml
- coredns 的以下 Pod 和服務可用：
kubectl get pod,service -n kube-system -l k8s-app=kube-dns -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES pod/coredns-64897985d-cgxmv 1/1 Running 0 24h 10.85.0.4 archlinux-x86-64-000 <none> <none> pod/coredns-64897985d-l9ftl 1/1 Running 0 24h 10.85.0.3 archlinux-x86-64-001 <none> <none> NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR service/kube-dns ClusterIP 10.96.0.10 <none> 53/UDP,53/TCP,9153/TCP 24h k8s-app=kube-dns
- 在我的網路 pod 中執行 shell 並嘗試
google.com通過coredns服務查詢 IP 地址。如何辨識命令需要不同的時間長度。不幸的是，我無法通過服務重現超時錯誤：# kubectl exec network-tools -- time dig A google.com @10.96.0.10 +short 142.250.185.238 real 0m 5.02s user 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 user 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 user 0m 0.01s sys 0m 0.01s
- 現在我將查詢限制為不同的 coredns pod。請注意，
coredns-64897985d-cgxmv具有 IP的 pod10.85.0.4正在不同的節點上執行。吊艙/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 user 0m 0.00s sys 0m 0.01s吊艙/coredns-64897985d-cgxmv / 10.85.0.4
coredns這是顯式使用另一個節點的 pod時的超時錯誤。# 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 +short ;; global options: +cmd ;; connection timed out; no servers could be reached Command exited with non-zero status 9 real 0m 15.02s user 0m 0.02s sys 0m 0.00s command terminated with exit code 9
- 以下日誌由
corednspod 寫入：吊艙/coredns-64897985d-l9ftl / 10.85.0.3
# kubectl logs -n kube-system coredns-64897985d-l9ftl .:53 [INFO] plugin/reload: Running configuration MD5 = db32ca3650231d74073ff4cf814959a7 CoreDNS-1.8.6 linux/amd64, go1.17.1, 13a9191 [INFO] Reloading [INFO] plugin/health: Going into lameduck mode for 5s [INFO] plugin/reload: Running configuration MD5 = 3d3f6363f05ccd60e0f885f0eca6c5ff [INFO] Reloading complete [INFO] 127.0.0.1:54962 - 9983 "HINFO IN 4683476401105705616.5032820535498752139. udp 57 false 512" NXDOMAIN qr,rd,ra 132 0.058383302s [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" ...吊艙/coredns-64897985d-cgxmv / 10.85.0.4
# kubectl logs -n kube-system coredns-64897985d-cgxmv .:53 [INFO] plugin/reload: Running configuration MD5 = db32ca3650231d74073ff4cf814959a7 CoreDNS-1.8.6 linux/amd64, go1.17.1, 13a9191 [INFO] Reloading [INFO] plugin/health: Going into lameduck mode for 5s [INFO] plugin/reload: Running configuration MD5 = 3d3f6363f05ccd60e0f885f0eca6c5ff [INFO] Reloading complete為了縮小問題範圍，我通過 ansible 重新安裝了我的集群，並通過以下命令安裝了 calico 而不是 flannel。那裡也存在同樣的問題。
$ helm install calico projectcalico/tigera-operator --version v3.21.3我使用kubeadm 的安裝指南來初始化集群。我執行了以下
kubeadmin init命令來初始化集群：$ 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定義了核心模組
br_netfilter和sysctl屬性，但問題依然存在。我的解決方案已接近尾聲，需要專家的建議。下面是我的核心模組、sysctl 設置和其他資訊的列表。我希望有一個人可以幫助我。
核心資訊
$ uname -a Linux archlinux-x86-64-000 5.10.90-1-lts #1 SMP Wed, 05 Jan 2022 13:07:40 +0000 x86_64 GNU/Linux核心模組
$ lsmod | sort 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 fat 86016 1 vfat fb_sys_fops 16384 1 drm_kms_helper fuse 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 bridge,stp lpc_ich 28672 0 mac_hid 16384 0 mbcache 16384 1 ext4 Module Size Used by 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 overlay 147456 18 pcspkr 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 bridge 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系統控制
Pastbin上的 sysctl 屬性。超過伺服器故障的最大字元數。
根據 GitHub 主題發布社區 wiki 答案 - CentOS RPM 中包含的文件會干擾 CNI 操作和 ArchLinux wiki 頁面 - CRIO-O。隨意擴展它。
ArchLinux wiki中已知並描述了該問題：
警告： Arch 將cni-plugins提供的外掛安裝到兩者
/usr/lib/cni，/opt/cni/bin但大多數其他外掛（例如集群內部署、kubelet 託管外掛等）預設僅安裝到第二個目錄。CRI-O 僅配置為在第一個目錄中查找外掛，因此，如果不更改配置，第二個目錄中的任何外掛都不可用。
使用者 bart0sh在這篇文章中介紹了解決方法：
我正在使用以下解決方法：
- 安裝cri-o
- 從 /etc/cni/net.d 中刪除所有內容
- 使用 kubeadm 設置節點
- 安裝 cni 外掛（wave、flannel、calico 等）
除了 下的 CNI 配置外，配置 中 還缺少
/etc/cni/net.d該屬性的副檔名 ，因為 預設情況下 似乎不會查找 已推出的外掛。我創建了一個插入文件。plugin_dirs``crio.conf``crio``/opt/cni$ cat /etc/crio/crio.conf.d/00-plugin-dir.conf [crio.network] plugin_dirs = [ "/opt/cni/bin/", "/usr/lib/cni", ]