bom pessoal seguinte no nosso vídeo anterior a gente acabou falando sobre serviços né e agora quero falar os quatro tipos de serviços que a gente tem e quando eles devem ser utilizados tá então vamos nessa bom a o primeiro tipo de serviço é um dos mais comuns que você vai ter no dia a dia que é chamado de cluster ip tá como quando esse serviço eles são utilizados esse serve se eles são utilizados quando você tem sistema serviços que o mundo externo não precisa chamar esse cara diretamente tá o que que isso significa imagina que você tem dois micro serviços se comunicando dentro da sua própria rede entendeu e não tem nenhum sistema que vai mandar de fora do seu cluster alguma requisição então nesse caso você cria um serviço do tipo cluster ip o que esse serviço ele vai fazer ele vai gerar um ip pra você tá e toda vez que alguém fizer essa chamada nesse ip ele vai bater no serviço e depois vai cair em toda aquela história que eu falei do balanceamento de carga para mandar você para os pods que você tem. Agora, um ponto novamente que vale a pena eu falar, é o seguinte, que mesmo você estando utilizando ali um cluster IP, você também consegue chamar, fazer as chamadas desse cara, utilizando o nome do service, porque o Kubernetes, ele traz essa resolução de DNS automática para você. Então, isso aí, galera, é muito importante você entender. Então, de forma geral, esse é o tipo de service que você mais vai utilizar se você tem muitos serviços se comunicando e nem todos eles precisam ter acesso externo. Então, cluster IP é esse cara aí que a gente está falando. Beleza? Vamos agora para o nosso segundo tipo de service. Esse service aqui, ele é muito utilizado também e ele é chamado de load balancer. A gente tem que tomar cuidado, galera, com uma coisa. Não é porque esse service se chama Load Balancer que o cluster IP, o service do cluster IP, não faz Load Balancing também. A diferença entre o cluster IP e o Load Balancer é que o Load Balancer vai te dar um IP externo, ou seja, ele vai gerar um IP público para você. IP externo, ou seja, ele vai gerar um IP público para você quando alguém de fora da sua rede de fora do seu cluster acessar esse IP, ele vai bater nos pods ali que esse serviço está selecionando, tá? Então a diferença entre o cluster IP e o load balancer basicamente é porque o load balancer ele tem um IP externo, tá? E aqui tem um parênteses, normalmente quando você utiliza um cluster Kubernetes, sei lá, na AWS, no GCP, na Azure, no Digital Ocean, não interessa onde, você tem aquela camada de rede do próprio Cloud Provider. Então, quando você cria um service do tipo Load Balancer, o que vai acontecer? Dependendo do cloud provider, ele vai realmente criar um load balancer pra você. Nesse load balancer, ele vai criar um IP, né? E esse IP você consegue acessar. Dependendo do serviço de nuvem, ele nem cria um load balancer, ele só atribui um IP externo, mandando isso aí diretamente pro seu cluster, tá? Então, de forma geral quem dá esse pé externo é o seu próprio provedor de nuvem ou se você rodar o kubernetes on-premise tá você vai ter os seus e pesa lida e você vai fazer a configuração de qual o p que vai ser exposto legal o outro cara aqui que a gente tem e esse cara aí é o menos utilizado, tá? De forma geral. Não, não é o menos utilizado. O último que eu vou te passar, dependerá do menos utilizado. Mas é o seguinte, é o cara chamado de Node Port. O que esse Node Port faz? Ele dá acesso externo ao cluster, através de uma porta pré-definida, tá? Que pode ser acessada através do ip externo de qualquer um dos podes de qualquer um dos nôdes na realidade então o que isso significa vamos imaginar que eu tenho três nôdes rodando o meu o meu cluster tá aí eu crio um serviço do tipo no de porte fala que vai ser na porta 32.800. O que vai acontecer? Se eu acessar o nó 1, ou seja, ele tem um IP, e eu acessar esse IP do nó 1, dois pontos, passando essa porta, eu vou cair nos pods desse service. Se eu acessar o nó 2, eu vou também. Se eu acessar o nó 3, eu vou também. Então, basicamente, o NodePort, ele atacha uma porta, tá? Para todos os nodes do seu pod, do seu pod não, do seu cluster, e você vai conseguir acessar. Também, tem uma característica interessante, é que esse NodePort, ele gera portas altas, tá? Você não consegue botar, por exemplo, uma porta 80 no seu NodePort. Se eu não me engano, é a partir de 32 mil e alguma coisa para você colocar esse cara. Wesley, mas quando eu vou utilizar o Node Port? Galera, eu vejo isso sendo utilizado muito em situações específicas de debugging, acesso external cluster e etc. Mas, na real, é muito pouco utilizado isso. É pouco utilizado mesmo. Eu sempre vou recomendar você trabalhar, nesse caso, com um cluster IP, um load balancer, ou até mesmo, se você tem a necessidade de acessar um service diretamente, você pode fazer um port forward, igual eu mostrei ali para vocês, para que a gente possa acessar um pod diretamente, você pode fazer um port forward, igual eu mostrei ali para vocês, para que a gente possa acessar um pod diretamente ou um service diretamente. E a gente tem o quarto e último tipo de service aqui, que ele é chamado de external name. O que é o external name? Ele mapeia o seu serviço para um endereço externo. Então vamos imaginar que eu quero... A minha aplicação tem que chamar a Google, tá? O google.com. E, nesse caso, o que eu posso fazer? Eu posso fazer a minha aplicação chamar diretamente o google.com, mas daí, quando eu faço isso, eu não estou passando com chamadas diretamente de rede do Kubernetes. Eu não consigo mapear direito o tracking dessa rede. Outra coisa é que muitas vezes esse google.com que você está chamando poderia ser um outro sistema que muda de IP o tempo inteiro ou qualquer coisa desse tipo, ou pode mudar de DNS o tempo inteiro e você não tem controle sobre isso. Então, ao invés de fazer todos os sistemas chamarem um dns externo diretamente tá onde esse dns externo pode mudar o que você faz você cria um serviço chamado external name e você fala toda vez que eu chamar o serviço xpto redireciona para o google.com entendeu e aí os seus sistemas ao invés de chamar o google.com entendeu? e aí os seus sistemas ao invés de chamar o google.com vai chamar esse service aí esse service redireciona para o google.com se algum dia você quiser mudar do google.com para o google.com.br você não vai ter que sair mudando todo o seu código de todas as suas aplicações para agora chamar o google.com.br você muda apenas essa configuração no service e todas aplicações para agora chamar o google.com.br você muda apenas essa configuração no serviço e todas as suas aplicações não está resolvendo normalmente porque você fez isso tá a esse e que está no também e nem eu não vejo tanta gente utilizando de forma geral né os mais populares realmente são o cluster ip e o load balança legal e nos próximos vídeos eu vou mostrar pra você como que você consegue criar esse service e como que você pode criar esses dois tipos de service pra gente trabalhar. Beleza? Então, vamos nessa, galera!