2
Я получаю сообщение об ошибке с помощью службы DNS-аддона на кубернетах.Службы и конечные точки перечисления ошибок DNS Kubernetes DNS
Если я запускаю эту команду я вижу, что служба Кубэ-DNS перезапускается:
kubectl get pods --namespace=kube-system -o wide
Когда я получаю журналы с:
kubectl logs kube-dns-v9-7mi17 -c kube2sky --namespace=kube-system
Я получаю это существо повторяется много раз:
E0305 04:39:30.837572 1 reflector.go:136] Failed to list *api.Endpoints: Get https://10.3.0.1:443/api/v1/endpoints: dial tcp 10.3.0.1:443: i/o timeout
E0305 04:39:30.948322 1 reflector.go:136] Failed to list *api.Service: Get https://10.3.0.1:443/api/v1/services: dial tcp 10.3.0.1:443: i/o timeout
E0305 04:40:01.838219 1 reflector.go:136] Failed to list *api.Endpoints: Get https://10.3.0.1:443/api/v1/endpoints: dial tcp 10.3.0.1:443: i/o timeout
E0305 04:40:01.948954 1 reflector.go:136] Failed to list *api.Service: Get https://10.3.0.1:443/api/v1/services: dial tcp 10.3.0.1:443: i/o timeout
Служба kubernetes имеет назначенный виртуальный IP, но конечная точка для кубернетов имеет реальный IP-адрес службы. Должна ли служба DNS пытаться связаться с сервером API, используя IP-адрес конечной точки вместо виртуального IP-адреса?
Это определение я использую для создания службы DNS:
apiVersion: v1
kind: Service
metadata:
name: kube-dns
namespace: kube-system
labels:
k8s-app: kube-dns
kubernetes.io/cluster-service: "true"
kubernetes.io/name: "KubeDNS"
spec:
selector:
k8s-app: kube-dns
clusterIP: 10.3.0.10
ports:
- name: dns
port: 53
protocol: UDP
- name: dns-tcp
port: 53
protocol: TCP
И это для репликации DNS контроллера:
apiVersion: v1
kind: ReplicationController
metadata:
name: kube-dns-v9
namespace: kube-system
labels:
k8s-app: kube-dns
version: v9
kubernetes.io/cluster-service: "true"
spec:
replicas: 1
selector:
k8s-app: kube-dns
version: v9
template:
metadata:
labels:
k8s-app: kube-dns
version: v9
kubernetes.io/cluster-service: "true"
spec:
containers:
- name: etcd
image: gcr.io/google_containers/etcd:2.0.9
resources:
limits:
cpu: 100m
memory: 50Mi
command:
- /usr/local/bin/etcd
- -data-dir
- /var/etcd/data
- -listen-client-urls
- http://127.0.0.1:2379,http://127.0.0.1:4001
- -advertise-client-urls
- http://127.0.0.1:2379,http://127.0.0.1:4001
- -initial-cluster-token
- skydns-etcd
volumeMounts:
- name: etcd-storage
mountPath: /var/etcd/data
- name: kube2sky
image: gcr.io/google_containers/kube2sky:1.11
resources:
limits:
cpu: 100m
memory: 50Mi
args:
# command = "/kube2sky"
- -domain=cluster.local
- name: skydns
image: gcr.io/google_containers/skydns:2015-03-11-001
resources:
limits:
cpu: 100m
memory: 50Mi
args:
# command = "/skydns"
- -machines=http://localhost:4001
- -addr=0.0.0.0:53
- -domain=cluster.local.
ports:
- containerPort: 53
name: dns
protocol: UDP
- containerPort: 53
name: dns-tcp
protocol: TCP
livenessProbe:
httpGet:
path: /healthz
port: 8080
scheme: HTTP
initialDelaySeconds: 30
timeoutSeconds: 5
readinessProbe:
httpGet:
path: /healthz
port: 8080
scheme: HTTP
initialDelaySeconds: 1
timeoutSeconds: 5
- name: healthz
image: gcr.io/google_containers/exechealthz:1.0
resources:
limits:
cpu: 10m
memory: 20Mi
args:
- -cmd=nslookup kubernetes.default.svc.cluster.local localhost >/dev/null
- -port=8080
ports:
- containerPort: 8080
protocol: TCP
volumes:
- name: etcd-storage
emptyDir: {}
dnsPolicy: Default
Использование конечной IP побеждает цель даже создание службы. kube2sky должен использовать IP-адрес службы, а kube-proxy на узле должен вставлять правила вне контейнера, которые перехватывают запрос на ваш ip-адрес службы и отправляют его на соответствующую конечную точку. Поэтому журналы в вашем контейнере должны показывать IP-адрес службы. Является ли kube-proxy запущенным на узле? и если у вас есть правило, которое перехватывает трафик до 10.3.0.10 (ищите -d 10.3.0.10 в iptables-save) –
@PrashanthB Я не знаю, что происходит, я закончил тем, что снова создал кластер, и он сработал. У меня были некоторые проблемы с сертификатами в первый раз, возможно, это вызвало некоторые проблемы. Спасибо. – user1845791