2015-04-04 4 views
0

У меня есть следующий кластер из 3-х Ubuntu машин на Лазурном облаке:Kubernetes: внешний сервис не доступен из всех приспешников на Azure облако

172.16.0.7 (master) 
172.16.0.4 (kube-01) 
172.16.0.5 (kube-02) 

На 172.16.0.4 (kube-01) у меня стручок под названием издатель с портом подвергается. Для того, чтобы сделать его доступным для мира я определил следующие услуги:

"id": "publisher-service", 
    "kind": "Service", 
    "apiVersion": "v1beta1", 
    "port": 8181, 
    "containerPort": 8080, 
    "publicIPs": ["172.16.0.4", "172.16.0.5"], 
    "selector": { 
    "group": "abc", 
    "component": "publisher" 
    }, 
    "labels": { 
    "group": "abc" 
    } 
  • 172.16.0.4 и 172.16.0.5 являются внутренним IP Addressess (Azure выражения) kube-01 и kube-02 соответственно

  • На 172.16.0.4 (kube-01) я получил конечная точка Azure, определенная с общественным портом, установлена ​​на и личный порт установлен на

  • На 172.16.0.5 (kube-02) У меня есть конечная точка Azure, определенная с открытым портом, установленным в и частный порт установлен в

С такой установкой я могу успешно получить доступ publisher-service используя мой VM публичным виртуальным IP (VIP) и порт .

Однако я ожидал бы быть также в состоянии достигнуть publisher-service используя тот же самый VIP адрес и порт (как она отображается в порт на kube-02). Вместо этого curl сообщает Recv failure: Connection reset by peer.

Я делаю что-то неправильно здесь? Возможно, мое понимание Kubernetes External Services неверна (и, следовательно, мое ожидание неправильное)?

Я также заметил в /var/log/upstart/kube-proxy следующие записи вошли:

E0404 17:36:33.371889 1661 proxier.go:82] Dial failed: dial tcp 10.0.86.26:8080: i/o timeout 
E0404 17:36:33.371951 1661 proxier.go:110] Failed to connect to balancer: failed to connect to an endpoint. 

Вот часть iptables -L -t nat выхода захваченного на 172.16.0.5 (kube-02):

Chain KUBE-PORTALS-CONTAINER (1 references) 
target  prot opt source    destination 
REDIRECT tcp -- anywhere    11.1.1.2    /* kubernetes */ tcp dpt:https redir ports 45717 
REDIRECT tcp -- anywhere    11.1.1.1    /* kubernetes-ro */ tcp dpt:http redir ports 34122 
REDIRECT tcp -- anywhere    11.1.1.221   /* publisher-service */ tcp dpt:8181 redir ports 48046 
REDIRECT tcp -- anywhere    172.16.0.4   /* publisher-service */ tcp dpt:8181 redir ports 48046 
REDIRECT tcp -- anywhere    172.16.0.5   /* publisher-service */ tcp dpt:8181 redir ports 48046 

Chain KUBE-PORTALS-HOST (1 references) 
target  prot opt source    destination 
DNAT  tcp -- anywhere    11.1.1.2    /* kubernetes */ tcp dpt:https to:172.16.0.5:45717 
DNAT  tcp -- anywhere    11.1.1.1    /* kubernetes-ro */ tcp dpt:http to:172.16.0.5:34122 
DNAT  tcp -- anywhere    11.1.1.221   /* publisher-service */ tcp dpt:8181 to:172.16.0.5:48046 
DNAT  tcp -- anywhere    172.16.0.4   /* publisher-service */ tcp dpt:8181 to:172.16.0.5:48046 
DNAT  tcp -- anywhere    172.16.0.5   /* publisher-service */ tcp dpt:8181 to:172.16.0.5:48046 

Я использую Kubernetes v0.12.0. Я выполнил this guide для настройки моего кластера (т. Е. Использую фланель).


UPDATE # 1: добавлена ​​publisher информация о состоянии стручка.

apiVersion: v1beta1 
creationTimestamp: 2015-04-04T13:24:47Z 
currentState: 
    Condition: 
    - kind: Ready 
    status: Full 
    host: 172.16.0.4 
    hostIP: 172.16.0.4 
    info: 
    publisher: 
     containerID: docker://6eabf71d507ad0086b37940931aa739534ef681906994a6aae6d97b8b213 
     image: xxxxx.cloudapp.net/publisher:0.0.2 
     imageID: docker://5a76329ae2d0dce05fae6f7b1216e346cef2e5aa49899cd829a5dc1f6e70 
     ready: true 
     restartCount: 5 
     state: 
     running: 
      startedAt: 2015-04-04T13:26:24Z 
    manifest: 
    containers: null 
    id: "" 
    restartPolicy: {} 
    version: "" 
    volumes: null 
    podIP: 10.0.86.26 
    status: Running 
desiredState: 
    manifest: 
    containers: 
    - capabilities: {} 
     command: 
     - sh 
     - -c 
     - java -jar publisher.jar -b $KAFKA_SERVICE_HOST:$KAFKA_SERVICE_PORT 
     image: xxxxx.cloudapp.net/publisher:0.0.2 
     imagePullPolicy: PullIfNotPresent 
     name: publisher 
     ports: 
     - containerPort: 8080 
     hostPort: 8080 
     protocol: TCP 
     resources: {} 
     terminationMessagePath: /dev/termination-log 
    dnsPolicy: ClusterFirst 
    id: "" 
    restartPolicy: 
     always: {} 
    version: v1beta2 
    volumes: null 
generateName: rc-publisher- 
id: rc-publisher-ls6k1 
kind: Pod 
labels: 
    group: abc 
namespace: default 
resourceVersion: 22853 
selfLink: /api/v1beta1/pods/rc-publisher-ls6k1?namespace=default 
uid: f746555d-dacd-11e4-8ae7-000d3a101fda 

ответ

0

Как только я переустановил свой кластер, используя k8s v0.14.2 все началось, как и следовало ожидать. Я последовал за Бренданом Бернсом .

+0

в порядке. для внешнего доступа, у вас есть запрос, входящий в один узел (через открытый порт/конечную точку), и пусть службы кубернетов обрабатывают балансировку нагрузки? – Eatdoku

+0

Все запросы проходят через один узел/конечную точку с прокси-сервером nginx, проходящим через сетевой портал k8s. – begie

0

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

Причина, по которой это не удалось, заключается в том, что прокси-сервер kube не мог разговаривать с вашим модулем.Либо фланель не может правильно направить на ваш IP-адрес, либо стручок не здоров. Поскольку отправка запросов на 172.16.0.4 работает, скорее всего, что-то не так с вашей настройкой фланелей. Вы можете подтвердить это, пытаясь свернуть 10.0.86.26:8080 с узла-2.

Если это может быть что-то неправильно со здоровьем стручка, вы можете проверить его подробное состояние, запустив kubectl.sh get pod $POD_NAME --output=yaml.

Извините за трудности!

+0

Действительно завиток к '10.0.86.26: 8080' таймаутам. Я добавил информацию о состоянии pod в тело вопроса. Обратите внимание, что 'restartCount: 5' не является проблемой - я перезапустил этот модуль самостоятельно, пытаясь выполнить разные настройки. Еще одна вещь: я также проверил статус миньонов - там ничего подозрительного. – begie

+0

Любые идеи, как проверить установку фланелей? – begie

+0

FYI, я не нашел исправления для этой проблемы, хотя обнаружил, что могу достичь своего «издательского сервиса», когда его определение k8s не использует селектор, а фиксированную конечную точку. – begie