Отказ фланелевого модуля (и DNS) для Kubernetes на виртуальных машинах CoreOS - PullRequest
Новая
       63

Отказ фланелевого модуля (и DNS) для Kubernetes на виртуальных машинах CoreOS

0 голосов
/ 09 июня 2018

Я развернул виртуальные машины CoreOS Vagrant с 3 узлами, следуя этому руководству , модифицированному как описано здесь .

Виртуальные машины исправны и работают;Контроллер / рабочие узлы K8s в порядке;и я могу развернуть стручки;ReplicaSets;и т. д.

Однако DNS, похоже, не работает, и, когда я смотрю на состояние модулей flannel, они явно вредны для здоровья: 

$ kubectl get po --all-namespaces                          
NAMESPACE     NAME                                   READY     STATUS             RESTARTS   AGE
apps          frontend-cluster-q4gvm                 1/1       Running            1          1h
apps          frontend-cluster-tl5ts                 1/1       Running            0          1h
apps          frontend-cluster-xgktz                 1/1       Running            1          1h
kube-system   kube-apiserver-172.17.8.101            1/1       Running            2          32d
kube-system   kube-controller-manager-172.17.8.101   1/1       Running            2          32d
kube-system   kube-flannel-ds-6csjl                  0/1       CrashLoopBackOff   46         31d
kube-system   kube-flannel-ds-f8czg                  0/1       CrashLoopBackOff   48         31d
kube-system   kube-flannel-ds-qbtlc                  0/1       CrashLoopBackOff   52         31d
kube-system   kube-proxy-172.17.8.101                1/1       Running            2          32d
kube-system   kube-proxy-172.17.8.102                1/1       Running            0          6m
kube-system   kube-proxy-172.17.8.103                1/1       Running            0          2m
kube-system   kube-scheduler-172.17.8.101            1/1       Running            2          32d

далее, когда я пытаюсьдля развертывания kubedns, которые тоже не работают, с тем же режимом сбоя: 

$ kubectl logs kube-flannel-ds-f8czg -n kube-system        
I0608 23:03:32.526331       1 main.go:475] Determining IP address of default interface
I0608 23:03:32.528108       1 main.go:488] Using interface with name eth0 and address 10.0.2.15
I0608 23:03:32.528135       1 main.go:505] Defaulting external address to interface address (10.0.2.15)
E0608 23:04:02.627348       1 main.go:232] Failed to create SubnetManager: error retrieving pod spec for 'kube-system/kube-flannel-ds-f8czg': Get https://10.3.0.1:443/api/v1/namespaces/kube-system/pods/kube-flannel-ds-f8czg: dial tcp 10.3.0.1:443: i/o timeout

Итак, похоже, что служба контроллера, работающая с IP-адресом 10.3.0.1, недоступна из других модулей: 

$ kubectl get svc --all-namespaces 
NAMESPACE   NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)          AGE
apps        frontend     ClusterIP   10.3.0.170   <none>        80/TCP,443/TCP   1h
default     kubernetes   ClusterIP   10.3.0.1     <none>        443/TCP          32d

Полагаю, они были связаны с конфигурациями etcd Фланеля;или kube-proxy YAML;Итак, я добавил следующее для всех узлов: 

core@core-01 ~ $ etcdctl ls /flannel/network/subnets
/flannel/network/subnets/10.1.80.0-24
/flannel/network/subnets/10.1.76.0-24
/flannel/network/subnets/10.3.0.0-16
/flannel/network/subnets/10.1.34.0-24

core@core-01 ~ $ etcdctl get /flannel/network/subnets/10.3.0.0-16
{"PublicIP": "172.17.8.101"}

и перезапустил flanneld: 

core@core-01 ~ $ sudo systemctl restart flanneld

Однако это, похоже, не приносит никакой пользы;из запущенного модуля Pod: 

# This is expected (no client certs):
root@frontend-cluster-q4gvm:/opt/simple# curl -k https://172.17.8.101/api/v1/pods
{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {

  },
  "status": "Failure",
  "message": "Unauthorized",
  "reason": "Unauthorized",
  "code": 401
}
# But this one just times out:
root@frontend-cluster-q4gvm:/opt/simple# curl -k https://10.3.0.1/api/v1/pods

Затем я посмотрел на kube-proxy.yaml и подозревал, что конфигурация --master (для рабочих узлов) была неправильной, как-то? 

core@core-02 /etc/kubernetes/manifests $ cat kube-proxy.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: kube-proxy
  namespace: kube-system
spec:
  hostNetwork: true
  containers:
  - name: kube-proxy
    image: quay.io/coreos/hyperkube:v1.10.1_coreos.0
    command:
    - /hyperkube
    - proxy
>>>>> Should it be like this?
    - --master=https://172.17.8.101
>>>>> or like this?
    - --master=http://127.0.0.1:8080

    securityContext:
      privileged: true
    volumeMounts:
    - mountPath: /etc/ssl/certs
      name: ssl-certs-host
      readOnly: true
  volumes:
  - hostPath:
      path: /usr/share/ca-certificates
    name: ssl-certs-host

Конфигурация 127.0.0.1:8080 может работать только (в лучшем случае) для узла контроллера, но наверняка ни к чему не приведет на других узлах?

Изменение --master, как указано выше, и перезапуск модулей, однако, тоже ничего хорошего не дает.

Суть в том, как сделать API контроллера доступным для 10.3.0.1?Как я могу включить KubeDNS (я пробовал инструкции в руководстве «Hard Way», но получил тот же режим отказа, что и выше).

Заранее большое спасибо!

Обновление

Это файл с параметрами flanneld: 

$ cat /etc/flannel/options.env 
FLANNELD_IFACE=172.17.8.101
FLANNELD_ETCD_ENDPOINTS=http://172.17.8.102:2379,http://172.17.8.103:2379,http://172.17.8.101:2379

Я удалил набор фланелевых демонов: 

kc delete ds kube-flannel-ds -n kube-system

и развернул KubeDNS, следуя этим инструкциям: служба определена здесь , а развертывание здесь : 

$ kc -n kube-system get svc
NAME       TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)         AGE
kube-dns   ClusterIP   10.3.0.10    <none>        53/UDP,53/TCP   4d


$ kc get po -n kube-system  
NAME                                   READY     STATUS    RESTARTS   AGE
kube-apiserver-172.17.8.101            1/1       Running   5          36d
kube-controller-manager-172.17.8.101   1/1       Running   5          36d
kube-dns-7868b65c7b-ntc95              3/4       Running   2          3m
kube-proxy-172.17.8.101                1/1       Running   5          36d
kube-proxy-172.17.8.102                1/1       Running   3          4d
kube-proxy-172.17.8.103                1/1       Running   2          4d
kube-scheduler-172.17.8.101            1/1       Running   5          36d

Однако, я все еще получаю ошибку тайм-аута (на самом деле, куча из них): 

E0613 19:02:27.193691       1 sync.go:105] Error getting ConfigMap kube-system:kube-dns err: Get https://10.3.0.1:443/api/v1/namespaces/kube-system/configmaps/kube-dns: dial tcp 10.3.0.1:443: i/o timeout

Обновление # 2

Аналогично, при настройке системы у меня есть следующая flanneld конфигурация: 

core@core-02 ~ $ etcdctl get /flannel/network/config
{ "Network": "10.1.0.0/16" }
core@core-02 ~ $ etcdctl ls /flannel/network/subnets
/flannel/network/subnets/10.1.5.0-24
/flannel/network/subnets/10.1.66.0-24
/flannel/network/subnets/10.1.6.0-24
core@core-02 ~ $ etcdctl get /flannel/network/subnets/10.1.66.0-24
{"PublicIP":"172.17.8.102"}

(и аналогично для остальных, указывая на 101 и 103) - должно ли быть что-то в config для подсети 10.3.0.0/16?Кроме того, должна ли быть запись (указывающая на 172.17.8.101) для API контроллера на 10.3.0.1?Что-то вроде: 

/flannel/network/subnets/10.3.0.0-24
{"PublicIP":"172.17.8.101"}

Кто-нибудь знает, где найти хорошую flanneld документацию (документы CoreOS действительно недостаточны и чувствуют себя несколько «заброшенными»)?Или что-то еще использовать, что на самом деле работает?

Спасибо!

...