Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision
Previous revision
devops:kubernetes_dns_reply_from_unexpected_source [2021/06/02 05:37] – created admindevops:kubernetes_dns_reply_from_unexpected_source [2021/06/02 08:47] (current) admin
Line 1: Line 1:
 +В кластере запущенные приложения перестали получать корректные ответы от DNS. \\
 +Диагностируем. Запускаем pod с **dnsutils**: 
   kubectl run dnsutils --image=gcr.io/kubernetes-e2e-test-images/dnsutils:1.3 -- sleep 3600   kubectl run dnsutils --image=gcr.io/kubernetes-e2e-test-images/dnsutils:1.3 -- sleep 3600
-  +Заходим в нему в консольку:  
   kubectl exec -it dnsutils -- /bin/sh   kubectl exec -it dnsutils -- /bin/sh
-  +И проверяем:  
   # nslookup kubernetes.default   # nslookup kubernetes.default
   ;; reply from unexpected source: 10.244.0.178#53, expected 10.96.0.10#53   ;; reply from unexpected source: 10.244.0.178#53, expected 10.96.0.10#53
 +НЕ РАБОТАЕТ!
 +Оказалось, что после замены **CRI** (с **docker** на **containerd**) скорее всего в результате удаления **docker**, перестал загружаться модуль ядра  **br_netfilter**. \\
 +Чтобы просто заставить работать нужно сделать так:
 +  Debian
 +  modprobe br_netfilter
  
-Debian +  CentOS
-  modprobe br_netfilter +
-CentOS+
   echo '1' > /proc/sys/net/bridge/bridge-nf-call-iptables   echo '1' > /proc/sys/net/bridge/bridge-nf-call-iptables
 +А чтобы модуль загружался автоматически при загрузке хоста нужно сделать так: 
 +  echo 'br_netfilter' | sudo tee -a /etc/modules
  • devops/kubernetes_dns_reply_from_unexpected_source.txt
  • Last modified: 2021/06/02 08:47
  • by admin