Отказ фланелевого модуля (и DNS) для Kubernetes на виртуальных машинах CoreOS
После этого руководства я развернул виртуальные машины 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
Итак, похоже, что служба контроллера, запустив 10.3.0.1 IP не доступен из других модулей:
$ 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
Однако это, кажется, не приносит никакой пользы; из бегущего стручка:
# 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
и развернул Kube DNS, следуя этим инструкциям: служба определена здесь, а развертывание здесь:
$ 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 действительно недостаточны и чувствуют себя несколько "заброшенными")? Или что-то еще использовать, что на самом деле работает?
Спасибо!