Сервис Kubernetes не отображает правильный порт - PullRequest
Новая
       13

Сервис Kubernetes не отображает правильный порт

0 голосов
/ 03 апреля 2019

Я хотел бы предоставить порт по умолчанию (1883) и порт WS (9001) сервера MQTT в кластере Azure Kubernetes.

В любом случае, вот то развертывание, которое я сейчас написал: 

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mqtt-server
spec: 
  replicas: 1
  selector: 
    matchLabels: 
      app: mqtt-server
  template: 
    metadata: 
      labels: 
        app: mqtt-server
        type: backend 
    spec: 
      containers: 
        - name: mqtt-server
          image: eclipse-mosquitto:1.5.4
          resources: 
            requests:
              cpu: 250m
              memory: 256Mi
          ports:
            - name: mqtt-dflt-port
              containerPort: 1883
            - name: mqtt-ws-port
              containerPort: 9001
---
apiVersion: v1
kind: Service
metadata:
  name: mqtt-server-service
spec:
  selector:
    app: mqtt-server
  type: LoadBalancer
  ports:
  - name: mqtt-dflt-port
    protocol: TCP
    port: 1883
    targetPort: 1883
  - name: mqtt-ws-port
    protocol: TCP
    port: 1884
    targetPort: 9001

И когда я его развертываю, все нормально, но MQTT-брокер недоступен, и мой сервис описывается так: 

mqtt-server-service   LoadBalancer   10.0.163.167   51.143.170.64   1883:32384/TCP,1884:31326/TCP   21m

ПочемуПорт 1883/9001 не пересылается так, как должно быть?

Ответы [ 2 ]

2 голосов
/ 03 апреля 2019

Во-первых, убедитесь, что вы подключаетесь к IP-адресу кластера службы из кластер, а не снаружи. Не пытайтесь пинговать IP-адрес службы, чтобы выяснить, доступна ли служба (помните, IP-адрес кластера службы является виртуальным IP-адресом, и проверка связи никогда не будет работать). Если вы определили проверку готовности, убедитесь, что она прошла успешно; в противном случае

стручок не будет частью службы. Чтобы подтвердить, что пакет является частью службы, изучите соответствующий Объекты point с kubectl получают конечные точки. Если вы пытаетесь получить доступ к сервису через его полное доменное имя или его часть (например, ple, myservice.mynamespace.svc.cluster.local или myservice.mynamespace) и он не работает, посмотрите, можете ли вы получить к нему доступ, используя его кластерный IP вместо полного доменного имени. Проверьте, подключаетесь ли вы к порту, указанному службой, а не целевой порт. Попробуйте подключиться к IP-адресу модуля напрямую, чтобы убедиться, что ваш модуль принимает соединение. на правильном порту. Если вы даже не можете получить доступ к своему приложению через IP-адрес модуля, убедитесь, что ваше приложение не только привязка к localhost.

1 голос
/ 03 апреля 2019

Я не вижу ничего плохого, запрашиваемые порты перенаправляются.И сервис создал временные порты на узлах для трафика (это всегда так).Служба получила конечные точки, все в порядке.

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

https://kubernetes.io/docs/concepts/services-networking/service/#nodeport

Если вам необходимо указать известное и статическое назначение портов, вы можете добавить nodePort: some-number к определению портов вваш сервис.По умолчанию узлы портов назначаются в 30000-32767.

...