Qual é a diferença entre os tipos de serviço ClusterIP, NodePort e LoadBalancer no Kubernetes?

1 - Estou lendo a documentação e estou um pouco confuso com a redação. Diz:

ClusterIP : expõe o serviço em um IP interno do cluster. A escolha desse valor torna o serviço acessível apenas de dentro do cluster. Este é o ServiceType padrão

NodePort : expõe o serviço no IP de cada nó em uma porta estática (o NodePort). Um serviço ClusterIP, para o qual o serviço NodePort será roteado, é criado automaticamente. Você poderá entrar em contato com o serviço NodePort, de fora do cluster, solicitando <NodeIP>:<NodePort>.

LoadBalancer : expõe o serviço externamente usando o balanceador de carga de um provedor de nuvem. Os serviços NodePort e ClusterIP, para os quais o balanceador de carga externo irá rotear, são criados automaticamente.

O tipo de serviço NodePort ainda usa, ClusterIPmas apenas em uma porta diferente, aberta a clientes externos? Então, neste caso, é <NodeIP>:<NodePort>o mesmo que <ClusterIP>:<NodePort>?

Ou é NodeIPrealmente o IP encontrado quando você executa kubectl get nodese não o IP virtual usado para o tipo de serviço ClusterIP?

2 - Também no diagrama do link abaixo:

http://kubernetes.io/images/docs/services-iptables-overview.svg

Existe alguma razão específica para o fato de Clientestar dentro do Node? Presumi que ele precisaria estar dentro de um Clusterno caso de um tipo de serviço ClusterIP.

Se o mesmo diagrama fosse desenhado para o NodePort, seria válido desenhar o cliente completamente fora do Nodee Clusterou estou perdendo completamente o ponto?

Um ClusterIP expõe o seguinte:

• spec.clusterIp:spec.ports[*].port

Você só pode acessar este serviço enquanto estiver dentro do cluster. É acessível a partir do seu spec.clusterIpporto. Se a spec.ports[*].targetPortestiver definido, ele será roteado da porta para o targetPort. O IP do CLUSTER que você obtém ao chamar kubectl get servicesé o IP atribuído a esse serviço internamente no cluster.

Um NodePort expõe o seguinte:

• <NodeIP>:spec.ports[*].nodePort
• spec.clusterIp:spec.ports[*].port

Se você acessar esse serviço em um nodePort a partir do IP externo do nó, ele encaminhará a solicitação para spec.clusterIp:spec.ports[*].port, que por sua vez encaminhará para o seu spec.ports[*].targetPort, se definido. Este serviço também pode ser acessado da mesma maneira que o ClusterIP.

Seus NodeIPs são os endereços IP externos dos nós. Você não pode acessar seu serviço a partir de <ClusterIP>:spec.ports[*].nodePort.

Um LoadBalancer expõe o seguinte:

• spec.loadBalancerIp:spec.ports[*].port
• <NodeIP>:spec.ports[*].nodePort
• spec.clusterIp:spec.ports[*].port

Você pode acessar este serviço a partir do endereço IP do seu balanceador de carga, que encaminha sua solicitação para um nodePort, que por sua vez encaminha a solicitação para a porta IP do cluster. Você pode acessar este serviço como faria com um serviço NodePort ou ClusterIP.

Para esclarecer para quem está procurando qual é a diferença entre os 3 em um nível mais simples. Você pode expor seu serviço com o mínimo de ClusterIp (no cluster k8s) ou uma exposição maior com o NodePort (dentro do cluster externo ao cluster do k8s) ou com o LoadBalancer (mundo externo ou o que você definiu no seu LB).

Exposição ClusterIp <exposição NodePort <exposição LoadBalancer

• 
  Serviço ClusterIp Expose através do cluster k8s comip/name:port
• 
  Serviço NodePort Expose através de VMs de rede interna também externas a k8sip/name:port
• LoadBalancer
  Expor o serviço através do mundo externo ou o que você definiu no seu LB.

ClusterIP: serviços são alcançáveis ​​por pods / serviços no cluster
Se eu criar um serviço chamado myservice no espaço de nome padrão do tipo: ClusterIP, será criado o seguinte endereço DNS estático previsível para o serviço:

myservice.default.svc.cluster.local (ou apenas myservice.default, ou por pods no espaço de nomes padrão, apenas "myservice" funcionará)

E esse nome DNS só pode ser resolvido por pods e serviços dentro do cluster.

NodePort: os serviços são alcançáveis ​​por clientes na mesma LAN / clientes que podem executar ping nos nós de host do K8s (e pods / serviços no cluster) (Observação para segurança, os nós de host do K8s devem estar em uma sub-rede privada, portanto, os clientes na Internet ganham não é possível acessar esse serviço)
Se eu criar um serviço chamado mynodeportservice no espaço de nome mynamespace do tipo: NodePort em um cluster de Kubernetes de 3 nós. Em seguida, um Serviço do tipo: ClusterIP será criado e poderá ser alcançado pelos clientes dentro do cluster no seguinte endereço DNS estático previsível:

mynodeportservice.mynamespace.svc.cluster.local (ou apenas mynodeportservice.mynamespace)

Para cada porta que mynodeportservice ouve em uma nodeport no intervalo de 30000 - 32767, será escolhida aleatoriamente. Para que clientes externos que estão fora do cluster possam acessar o serviço ClusterIP que existe dentro do cluster. Digamos que nossos três nós de host K8s tenham IPs 10.10.10.1, 10.10.10.2, 10.10.10.3, o serviço Kubernetes está escutando na porta 80 e o Nodeport escolhido aleatoriamente foi 31852.

Um cliente que existe fora do cluster pode visitar 10.10.10.1:31852, 10.10.10.2:31852 ou 10.10.10.3:31852 (como o NodePort é escutado por todos os nós de host do Kubernetes) O Kubeproxy encaminhará a solicitação para a porta 80 do mynodeportservice.

LoadBalancer: os serviços são acessíveis a todos os que estão conectados à Internet * (a arquitetura comum é L4 LB é acessível ao público na Internet, colocando-a em uma DMZ ou fornecendo-lhe um IP público e privado e os nós do host k8s e IP públicos e privados em uma sub-rede privada)
( Nota: Esse é o único tipo de serviço que não funciona em 100% das implementações do Kubernetes, como o Kubernetes bare metal, funciona quando o Kubernetes tem integrações de provedor de nuvem.)

Se você criar mylbservice, uma VM L4 LB será gerada (um serviço IP de cluster e um Serviço NodePort também será implicitamente gerado). Desta vez, nosso NodePort é 30222. a idéia é que o L4 LB tenha um IP público 1.2.3.4 e carregue o saldo e encaminhará o tráfego para os 3 nós do K8s que possuem endereços IP privados. (10.10.10.1:30222, 10.10.10.2:30222, 10.10.10.3:30222) e, em seguida, o Kube Proxy o encaminhará para o serviço do tipo ClusterIP que existe dentro do cluster.

Você também perguntou: O tipo de serviço NodePort ainda usa o ClusterIP? Sim *
Ou o NodeIP é realmente o IP encontrado quando você executa o kubectl get nodes? Também sim *

Vamos desenhar um paralelo entre os Fundamentos:
um contêiner está dentro de um pod. um pod está dentro de um replicaset. um replicaset está dentro de uma implantação.
Bem da mesma forma:
um serviço ClusterIP faz parte de um serviço NodePort. Um serviço NodePort faz parte de um serviço do balanceador de carga.

Nesse diagrama que você mostrou, o cliente seria um pod dentro do cluster.

Vamos supor que você criou uma VM do Ubuntu em sua máquina local. Seu endereço IP é 192.168.1.104 .

Você entra na VM e instala o Kubernetes. Em seguida, você criou um pod em que a imagem nginx é executada nele.

1- Se você deseja acessar esse pod nginx dentro da sua VM, criará um ClusterIP vinculado a esse pod, por exemplo:

$ kubectl expose deployment nginxapp --name=nginxclusterip --port=80 --target-port=8080

Em seu navegador, você pode digitar o endereço IP do nginxclusterip com a porta 80, como:

http://10.152.183.2:80

2- Se você deseja acessar este pod do nginx na sua máquina host, precisará expor sua implantação com o NodePort . Por exemplo:

$ kubectl expose deployment nginxapp --name=nginxnodeport --port=80 --target-port=8080 --type=NodePort

Agora, na sua máquina host, você pode acessar o nginx como:

http://192.168.1.104:31865/

No meu painel, eles aparecem como:

Abaixo está um diagrama que mostra o relacionamento básico.

Mesmo que essa pergunta já tenha uma resposta, darei outra, talvez com mais algumas fotos para entender melhor.

1. ClusterIP é o tipo de serviço padrão no Kubernetes e esse tipo fornece um serviço dentro do cluster. Usando isso, outros aplicativos do cluster podem acessar o serviço por meio do proxy Kubernetes.

Devo mencionar que esse tipo de serviço não deve ser usado para expor serviços de produção. No entanto, pode ser usado para

• depuração de integração entre serviços;
• acessar serviços internos que estão expondo dados não relacionados aos negócios (painéis de monitoramento).

A forma como a solicitação segue é a seguinte: tráfego -> proxy K8s -> serviço K8s (ClusterIP) -> pods e é exibido na figura a seguir.

2. O NodePort é a maneira mais primitiva de aceitar tráfego externo e encaminhá-lo para os serviços kubernetes. Como o nome indica, o tipo de serviço NodePort abre uma porta específica em todas as máquinas virtuais, que são de fato os nós do Kubernetes, para permitir que o tráfego enviado para essa porta específica seja encaminhado para o serviço.

O tipo de serviço NodePort tem algumas desvantagens:

• é necessário ter apenas um serviço por porta;
• se o ip da máquina virtual for alterado, algumas alterações deverão ser feitas no cluster;
• somente porta entre 3000-32767 pode ser usada.

A forma como essa solicitação é feita é a seguinte: tráfego -> porta exposta na máquina virtual -> serviço K8s (NodePort) -> pods e é exibido na figura a seguir:

3. LoadBalancer é a maneira padrão de expor um serviço à Internet. Se o seu desejo é expor diretamente um serviço e todo o tráfego em uma porta específica a ser antecipada ao serviço, então esta é a maneira de fazê-lo. Além disso, o tipo de serviço LoadBalancer não envolve nenhuma filtragem ou roteamento. Além disso, você pode enviar tráfego TCP, UDP, HTTP gRPC para ele.

Desvantagem: cada serviço exposto por meio de um LoadBalancer terá seu próprio endereço IP e cada serviço será exposto por meio de um único LoadBalancer que pode se tornar caro.

A solicitação possui o seguinte caminho: tráfego -> LoadBalancer -> Serviço K8s -> pods e é exibida na figura a seguir.

1. clusterIP: IP acessível dentro do cluster (entre nós no cluster d).

nodeA : pod1 => clusterIP1, pod2 => clusterIP2
nodeB : pod3 => clusterIP3.

O pod3 pode conversar com o pod1 por meio de sua rede clusterIP.

2. nodeport: para tornar os pods acessíveis de fora do cluster via nodeIP: nodeport, ele criará / manterá o clusterIP acima como sua rede clusterIP.

nodeA => nodeIPA : nodeportX
nodeB => nodeIPB : nodeportX

você pode acessar o serviço no pod1 via nodeIPA: nodeportX OU nodeIPB: nodeportX. De qualquer maneira, funcionará porque o kube-proxy (que está instalado em cada nó) receberá sua solicitação e a distribuirá [redireciona (termo do iptables)] entre os nós, usando a rede clusterIP.

3. Balanceador de carga

basicamente apenas colocando LB na frente, para que o tráfego de entrada seja distribuído para nodeIPA: nodeportX e nodeIPB: nodeportX e continue com o fluxo de processo número 2 acima.