2017-01-31 19 views
17

Zaczynam być bardziej zaznajomiony z Kubernetes z dnia na dzień, ale wciąż jestem na poziomie podstawowym. Nie jestem też facetem w sieci.Co to znaczy, że usługa ma być typu NodePort i czy określono port i port docelowy?

ja patrząc na poniższym fragmencie definicji usług, i nie mogą stanowić właściwą obraz w moim umyśle, co jest uznane:

spec: 
    type: NodePort 
    ports: 
    - port: 27018 
    targetPort: 27017 
    protocol: TCP 

odwoływania się ServicePort documentation, który brzmi w części:

nodePort  The port on each node on which this service is exposed when type=NodePort or LoadBalancer. Usually 
integer  assigned by the system. If specified, it will be allocated to the service if unused or else creation of the 
      service will fail. Default is to auto-allocate a port if the ServiceType of this Service requires one. More info: 
      http://kubernetes.io/docs/user-guide/services#type--nodeport 

port   The port that will be exposed by this service. 
integer 

targetPort Number or name of the port to access on the pods targeted by the service. Number must be in the range 1 
IntOrString to 65535. Name must be an IANA_SVC_NAME. If this is a string, it will be looked up as a named port in the 
      target Pod's container ports. If this is not specified, the value of the 'port' field is used (an identity map). 
      This field is ignored for services with clusterIP=None, and should be omitted or set equal to the 'port' field. 
      More info: http://kubernetes.io/docs/user-guide/services#defining-a-service 

Rozumiem, że port że klient spoza klastra będzie „widzieć” będzie dynamicznie przydzielony jeden w zakresie 30000 - 32767, jak określono in the documentation. To, używając czarnej magii, której jeszcze nie rozumiem, przepływa do targetPort w danym węźle (27017 w tym przypadku).

Do czego służy tutaj port?

Odpowiedz

18

nodePort to port, który klient "spoza" klastra "zobaczy". nodePort jest otwierany na każdym węźle klastra za pośrednictwem kube-proxy. Za pomocą iptables magic Kubernetes (k8s) następnie kieruje ruch z tego portu do zgodnego pakietu serwisowego (nawet jeśli ten moduł działa na zupełnie innym węźle).

port to port, w którym usługa nasłuchuje wewnątrz klastra. Weźmy następujący przykład:

--- 
apiVersion: v1 
kind: Service 
metadata: 
    name: my-service 
spec: 
    ports: 
    - port: 8080 
    targetPort: 8070 
    nodePort: 31222 
    protocol: TCP 
    selector: 
    component: my-service-app 

Od wewnątrz moich K8S klastra tej usługi będzie osiągalny poprzez my-service.default.svc.cluster.local:8080 (usługa do obsługi komunikacji wewnątrz klastra), a każdy wniosek osiągając tam jest przekazywany do uruchomionego pod na targetPort 8070.

tagetPort jest również domyślnie taka sama, jak port, jeśli nie podano inaczej.

+0

Dziękuję. Więc 'nodePort' to _nie_ port, na którym usługa nasłuchuje? Zamiast tego otwierany jest port na węzłach hostujących kapsuły, które frontem usługi? –

+1

'nodePort' jest unikalny, więc 2 różne usługi nie mogą mieć przypisanego tego samego' nodePort'. Po zadeklarowaniu, master k8s zastrzega 'nodePort' dla tej usługi. 'nodePort' jest następnie otwierany w węźle ** EVERY ** (master i worker) - także węzły, które nie uruchamiają strąka tej usługi - [k8s iptables] (https://kubernetes.io/docs/user-guide/services/# virtual-ips-and-service-proxy) magic zajmuje się routingiem. W ten sposób możesz wysłać żądanie usługi spoza twojego k8s do dowolnego węzła na 'nodePort', nie martwiąc się, czy jest tam zaplanowany strąk. – fishi

+5

Z kanału # kubernetes-users Slack: "trasy nodePort" do usługi, która z kolei kieruje do bloku/jeśli bezpośrednio trafisz w usługę, krok 'nodePort' jest pomijany/obsługiwane jest 'magiczne trasowanie' przez 'kube-proxy'". To skłoniło mnie do powiedzenia (używając wynalezionej notacji): "' nodePort' -> 'port' ->' targetPort', a nie 'nodePort' ->' targetPort' && 'port' ->' targetPort' ". –