Стручки Kubernetes CoreDNS бесконечно перезапускаются - PullRequest
0 голосов
/ 24 октября 2018

Я работаю над установкой кластера kubernetes из трех узлов на CentOS 7 с фланелем в течение некоторого времени, однако модули CoreDNS не могут подключиться к серверу API и постоянно перезагружаются.

Справочный документ Как я следовал здесь .

Что я уже сделал?

  • Отключено SELinux,
  • Отключено firewalld,
  • Включено br_netfilter, bridge-nf-call-iptables,
  • Установлены kubernetes на трех узлах, настроена сеть pod master с фланелевой сетью по умолчанию (10.244.0.0/16),
  • Установлены два других узла иприсоединился к мастеру.
  • Развернутая фланель,
  • Сконфигурированный BIP докера для использования фланелевой подсети и сети по умолчанию для каждого узла.

Текущее состояние

  • Kubelet работает, и кластер сообщает об узлах как готовые.
  • Кластер может планировать и переносить модули, поэтому CoreDNS порождается на узлах.
  • Фланелевая сеть подключена.Журналы в контейнерах отсутствуют, и я могу пропинговать 10.244.0.0/24 сети от узла к узлу.
  • Kubernetes может развертывать и запускать произвольные модули (опробован shell demo и может получить доступ к его оболочке через kubectlдаже если контейнер находится на другом узле.
    • Однако, поскольку DNS не работает, они не могут разрешать любые IP-адреса.

В чем проблема?

  • Стручки CoreDNS сообщают, что не могут подключиться к API-серверу с ошибкой:

    Failed to list *v1.Namespace: Get https://10.96.0.1:443/api/v1/namespaces?limit=500&resourceVersion=0: dial tcp 10.96.0.1:443: connect: no route to host
    
  • Я не вижу 10.96.0.0 маршруты в маршрутизациитаблицы:

    default via 172.16.0.1 dev eth0 proto static metric 100 
    10.1.0.0/24 dev eth1 proto kernel scope link src 10.1.0.202 metric 101 
    10.244.0.0/24 via 10.244.0.0 dev flannel.1 onlink 
    10.244.1.0/24 dev docker0 proto kernel scope link src 10.244.1.1 
    10.244.1.0/24 dev cni0 proto kernel scope link src 10.244.1.1 
    10.244.2.0/24 via 10.244.2.0 dev flannel.1 onlink 
    172.16.0.0/16 dev eth0 proto kernel scope link src 172.16.0.202 metric 100
    

Дополнительная информация

  • Инициализация кластера выполняется с помощью команды kubeadm init --apiserver-advertise-address=172.16.0.201 --pod-network-cidr=10.244.0.0/16.
  • Я сорвалкластеризовать и перестроить с помощью 1.12.0. Проблема все еще сохраняется.
  • Обходной путь в Kubernetes документация не работает.
  • Проблема присутствует и одинакова как для 1.11-3и 1.12-0 CentOS7 пакетов.

Прогресс на данный момент

  • Понижение рейтинга Kuberneteс 1.11.3-0.
  • Повторная инициализация Kubernetes с kubeadm init --apiserver-advertise-address=172.16.0.201 --pod-network-cidr=10.244.0.0/16, поскольку сервер имеет другой внешний IP-адрес, к которому нельзя получить доступ через другие хосты, и Kubernetes стремится выбрать этот IP-адрес в качестве IP-адреса API-сервера.--pod-network-cidr требует фланель .
  • Результирующий вывод iptables -L после инициализации без соединенных узлов

    Chain INPUT (policy ACCEPT)
    target     prot opt source               destination         
    KUBE-EXTERNAL-SERVICES  all  --  anywhere             anywhere             ctstate NEW /* kubernetes externally-visible service portals */
    KUBE-FIREWALL  all  --  anywhere             anywhere            
    
    Chain FORWARD (policy ACCEPT)
    target     prot opt source               destination         
    KUBE-FORWARD  all  --  anywhere             anywhere             /* kubernetes forwarding rules */
    DOCKER-USER  all  --  anywhere             anywhere            
    
    Chain OUTPUT (policy ACCEPT)
    target     prot opt source               destination         
    KUBE-SERVICES  all  --  anywhere             anywhere             ctstate NEW /* kubernetes service portals */
    KUBE-FIREWALL  all  --  anywhere             anywhere            
    
    Chain DOCKER-USER (1 references)
    target     prot opt source               destination         
    RETURN     all  --  anywhere             anywhere            
    
    Chain KUBE-EXTERNAL-SERVICES (1 references)
    target     prot opt source               destination         
    
    Chain KUBE-FIREWALL (2 references)
    target     prot opt source               destination         
    DROP       all  --  anywhere             anywhere             /* kubernetes firewall for dropping marked packets */ mark match 0x8000/0x8000
    
    Chain KUBE-FORWARD (1 references)
    target     prot opt source               destination         
    ACCEPT     all  --  anywhere             anywhere             /* kubernetes forwarding rules */ mark match 0x4000/0x4000
    
    Chain KUBE-SERVICES (1 references)
    target     prot opt source               destination         
    REJECT     udp  --  anywhere             10.96.0.10           /* kube-system/kube-dns:dns has no endpoints */ udp dpt:domain reject-with icmp-port-unreachable
    REJECT     tcp  --  anywhere             10.96.0.10           /* kube-system/kube-dns:dns-tcp has no endpoints */ tcp dpt:domain reject-with icmp-port-unreachable
    
  • Похоже, API-сервер развернут как надо

    $ kubectl get svc kubernetes -o=yaml
    apiVersion: v1
    kind: Service
    metadata:
      creationTimestamp: 2018-10-25T06:58:46Z
      labels:
        component: apiserver
        provider: kubernetes
      name: kubernetes
      namespace: default
      resourceVersion: "6"
      selfLink: /api/v1/namespaces/default/services/kubernetes
      uid: 6b3e4099-d823-11e8-8264-a6f3f1f622f3
    spec:
      clusterIP: 10.96.0.1
      ports:
      - name: https
        port: 443
        protocol: TCP
        targetPort: 6443
      sessionAffinity: None
      type: ClusterIP
    status:
      loadBalancer: {}
    
  • Затем я применил модуль фланелевой сети с

    kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
    
  • Как только я применяю фланелевую сеть, модули CoreDNS запускаются и начинают выдавать ту же ошибку:

    Failed to list *v1.Endpoints: Get https://10.96.0.1:443/api/v1/endpoints?limit=500\u0026resourceVersion=0: dial tcp 10.96.0.1:443: connect: no route to host
    
  • Я обнаружил, что flanneld используетнеправильный сетевой интерфейс, и перед развертыванием изменил его в файле kube-flannel.yml.Однако результат остается прежним.

Любая помощь очень ценится.

Ответы [ 3 ]

0 голосов
/ 25 октября 2018

Я решил проблему.Причина - смесь неопытности, отсутствия документации и некоторой старой, более не правильной информации.

Парень, который будет использовать установку, сказал мне, что мост Докера должен находиться в одной подсети сФланелевая сеть, поэтому я отредактировал мостовую сеть Докера.

Однако, когда Kubernetes начал использовать CNI, это требование не только стало ненужным, но и совершенно неверным.И то, и другое cni0 и docker0 в одной сети с одним и тем же IP-адресом, всегда казалось неправильным, но, поскольку я полностью новичок в Куберне, я проигнорировал свою догадку.

В результате я перезагружаю Dockerсеть по умолчанию, сорвал кластер и перестроил его.Теперь все работает как надо.

TL; DR: Никогда, никогда не трогайте параметры сети Docker, если вы настраиваете недавний выпуск Kubernetes.Просто установите Docker, инициализируйте Kubernetes и разверните Flannel.Kubernetes и CNI позаботятся о доставке контейнеров во фланелевые перевозки.

0 голосов
/ 13 марта 2019

Я встречал это раньше.Firewalld открыл порт 6443 для моих реальных IP-адресов локальной сети, но он по-прежнему отключает другие, поэтому я попытался выключить брандмауэр через CMD:

systemctl stop firewalld

Он работает и все исключения, поступающие из журналов kubectlпропали, поэтому основная причина - правила брандмауэра на ваших серверах Linux.

0 голосов
/ 24 октября 2018

Это в основном говорит о том, что ваш cornns pod не может общаться с kube-apiserver.Kube-apiserver предоставляется в модуле через следующие переменные среды: KUBERNETES_SERVICE_HOST=10.96.0.1 и KUBERNETES_SERVICE_PORT_HTTPS=443

Я считаю, что отправленные вами маршруты являются маршрутами на хосте, так как это то, что вы получаете при запуске ip routes в контейнере pod:

root@xxxx-xxxxxxxxxx-xxxxx:/# ip route
default via 169.254.1.1 dev eth0
169.254.1.1 dev eth0  scope link
root@xxxx-xxxxxxxxxx-xxxxx:/#

В любом случае вы не увидите 10.96.0.1, поскольку он выставлен в кластере с использованием iptables.Так что это за адрес?Бывает, что service в пространстве имен по умолчанию называется kubernetes.Эта служба ClusterIP имеет значение 10.96.0.1 и прослушивает порт 443, она также отображается на targetPort 6443, где работает ваш kube-apiserver.

Поскольку вы можете развертывать модули,и т.д. Кажется, что куб-аписервер не выключен, и это не ваша проблема.Поэтому, скорее всего, вам не хватает этого сервиса (или есть какое-то приемлемое правило, запрещающее вам подключаться к нему).Вы можете увидеть это здесь, например:

$ kubectl get svc kubernetes
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.96.0.1    <none>        443/TCP   92d

Полный вывод выглядит примерно так:

$ kubectl get svc kubernetes -o=yaml
apiVersion: v1
kind: Service
metadata:
  creationTimestamp: 2018-07-23T21:10:22Z
  labels:
    component: apiserver
    provider: kubernetes
  name: kubernetes
  namespace: default
  resourceVersion: "24"
  selfLink: /api/v1/namespaces/default/services/kubernetes
  uid: xxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx
spec:
  clusterIP: 10.96.0.1
  ports:
  - name: https
    port: 443
    protocol: TCP
    targetPort: 6443
  sessionAffinity: None
  type: ClusterIP
status:
  loadBalancer: {} 

Так что, если вам его не хватает, вы можете создать его так:

cat <<EOF
apiVersion: v1
kind: Service
metadata:
  labels:
    component: apiserver
    provider: kubernetes
  name: kubernetes
  namespace: default
spec:
  clusterIP: 10.96.0.1
  ports:
  - name: https
    port: 443
    protocol: TCP
    targetPort: 6443
  sessionAffinity: None
  type: ClusterIP
EOF | kubectl apply -f -
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...