From 17077e0c540762347ac4c806fdbe818305ab156c Mon Sep 17 00:00:00 2001 From: Mauren Berti Date: Thu, 15 Jun 2023 16:19:19 -0400 Subject: [PATCH] [pt-br] Update expose-intro.html Update the tutorial on how to expose a service outside the cluster to remove Katacoda references. --- .../expose/expose-intro.html | 262 ++++++++++++++++-- 1 file changed, 240 insertions(+), 22 deletions(-) diff --git a/content/pt-br/docs/tutorials/kubernetes-basics/expose/expose-intro.html b/content/pt-br/docs/tutorials/kubernetes-basics/expose/expose-intro.html index 4e66601116..102862436f 100644 --- a/content/pt-br/docs/tutorials/kubernetes-basics/expose/expose-intro.html +++ b/content/pt-br/docs/tutorials/kubernetes-basics/expose/expose-intro.html @@ -1,11 +1,15 @@ --- title: Utilizando um serviço para expor seu aplicativo weight: 10 +description: |- + Aprenda sobre Services no Kubernetes. + Entenda como rótulos (labels) e seletores (selectors) relacionam-se aos Services. + Exponha uma aplicação externamente ao cluster Kubernetes. --- - + @@ -19,40 +23,103 @@ weight: 10

Objetivos

-

Visão Geral de Serviços Kubernetes

+

Visão Geral dos Services no Kubernetes

-

Pods Kubernetes são efêmeros. Na verdade, Pods possuem um ciclo de vida. Quando um nó de processamento morre, os Pods executados no nó também são perdidos. A partir disso, o ReplicaSet pode dinamicamente retornar o cluster ao estado desejado através da criação de novos Pods para manter sua aplicação em execução. Como outro exemplo, considere um backend de processamento de imagens com 3 réplicas. Estas réplicas são intercambiáveis; o sistema front-end não deveria se importar com as réplicas backend ou ainda se um Pod é perdido ou recriado. Dito isso, cada Pod em um cluster Kubernetes tem um único endereço IP, mesmo Pods no mesmo nó, então há necessidade de ter uma forma de reconciliar automaticamente mudanças entre Pods de modo que sua aplicação continue funcionando.

+

+ Pods do Kubernetes são efêmeros. + Na verdade, Pods possuem um ciclo de vida. + Quando um nó de processamento morre, os Pods executados no nó também são + perdidos. A partir disso, o ReplicaSet + pode dinamicamente retornar o cluster ao estado desejado através da criação + de novos Pods para manter sua aplicação em execução. Como outro exemplo, + considere um backend de processamento de imagens com 3 réplicas. Estas + réplicas são permutáveis; o sistema front-end não deveria se importar + com as réplicas backend ou ainda se um Pod foi perdido ou recriado. Dito + isso, cada Pod em um cluster Kubernetes tem um endereço IP único, incluindo + Pods que estejam rodando no mesmo nó, então há necessidade de ter uma + forma de reconciliar automaticamente mudanças entre Pods de modo que sua + aplicação continue funcionando. +

-

Um serviço no Kubernetes é uma abstração que define um conjunto lógico de Pods e uma política pela qual acessá-los. Serviços permitem um baixo acoplamento entre os Pods dependentes. Um serviço é definido usando YAML (preferencialmente) ou JSON, como todos objetos Kubernetes. O conjunto de Pods selecionados por um Serviço é geralmente determinado por um seletor de rótulos LabelSelector (veja abaixo o motivo pelo qual você pode querer um Serviço sem incluir um seletor selector na especificação spec).

+

+ Um objeto Service no Kubernetes é uma abstração que define um conjunto + lógico de Pods e uma política pela qual acessá-los. Serviços permitem um + baixo acoplamento entre os Pods dependentes. Um serviço é definido usando + YAML ou JSON, como todos os manifestos de objetos Kubernetes. O conjunto + de Pods selecionados por um Service é geralmente determinado por um + seletor de rótulos (veja abaixo o motivo pelo qual você poderia + desejar um Service que não inclui um seletor (selector) na + especificação (spec)). +

-

Embora cada Pod tenha um endereço IP único, estes IPs não são expostos externamente ao cluster sem um Serviço. Serviços permitem que suas aplicações recebam tráfego. Serviços podem ser expostos de formas diferentes especificando um tipo type na especificação do serviço ServiceSpec:

+

+ Embora cada Pod tenha um endereço IP único, estes IPs não são expostos + externamente ao cluster sem um objeto Service. Objetos Service permitem + que suas aplicações recebam tráfego. Services podem ser expostos de + formas diferentes especificando um tipo (campo type) na + especificação do serviço (campo spec):

-

Mais informações sobre diferentes tipos de Serviços podem ser encontradas no tutorial Utilizando IP de origem. Também confira Conectando aplicações com serviços.

-

Adicionalmente, note que existem alguns casos de uso com serviços que envolvem a não definição de selector em spec. Serviços criados sem selector também não criarão objetos Endpoints correspondentes. Isto permite usuários mapear manualmente um serviço a endpoints específicos. Outra possibilidade na qual pode não haver seletores é ao se utilizar estritamente type: ExternalName.

+

+ Mais informações sobre diferentes tipos de Services podem ser encontradas + no tutorial Utilizando IP de origem. + Veja também Conectando aplicações com serviços. +

+

+ Adicionalmente, note que existem alguns casos de uso com serviços que + envolvem a ausência de um selector no campo spec. + Services criados sem selector também não criarão objetos + Endpoints correspondentes. Isto permite que usuários mapeiem manualmente + um serviço a endpoints específicos. Outro motivo pelo qual seletores + podem estar ausentes é que você esteja utilizando estritamente + type: ExternalName. +

Resumo

    -
  • Expõe Pods ao tráfego externo
    • -
  • Tráfego de balanceamento de carga entre múltiplos Pods
    • -
  • Uso de rótulos labels
    • +
  • Exposição de Pods ao tráfego externo
    • +
  • Balanceamento de carga de tráfego entre múltiplos Pods
    • +
  • Utilização de rótulos (labels)
-

Um serviço Kubernetes é uma camada de abstração que define um conjunto lógico de Pods e habilita a exposição ao tráfego externo, balanceamento de carga e descoberta de serviço para esses Pods.

+

+ Um objeto Service do Kubernetes é uma camada de abstração que define + um conjunto lógico de Pods e habilita a exposição ao tráfego externo, + balanceamento de carga e descoberta de serviço para esses Pods. +

@@ -66,8 +133,20 @@ weight: 10
-

Um serviço roteia tráfego entre um conjunto de Pods. Serviço é a abstração que permite pods morrerem e se replicarem no Kubernetes sem impactar sua aplicação. A descoberta e o roteamento entre Pods dependentes (tal como componentes frontend e backend dentro de uma aplicação) são controlados por serviços Kubernetes.

-

Serviços relacionam um conjunto de Pods usando Rótulos e seletores, um agrupamento primitivo que permite operações lógicas sobre objetos Kubernetes. Rótulos são pares de chave/valor anexados à objetos e podem ser usados de inúmeras formas:

+

+ Um Service roteia tráfego entre um conjunto de Pods. Service é a + abstração que permite Pods morrerem e se replicarem no Kubernetes sem + impactar sua aplicação. A descoberta e o roteamento entre Pods + dependentes (tal como componentes frontend e backend dentro de uma + aplicação) são controlados por Services do Kubernetes. +

+

+ Services relacionam um conjunto de Pods usando + rótulos e seletores, + uma primitiva de agrupamento que permite operações lógicas sobre objetos + do Kubernetes. Rótulos são pares chave/valor anexados à objetos e + podem ser usados de diversas formas: +

  • Designar objetos para desenvolvimento, teste e produção
  • Adicionar tags de versão
    • @@ -87,15 +166,154 @@ weight: 10
    -

    Rótulos podem ser anexados à objetos no momento de sua criação ou posteriormente. Eles podem ser modificados a qualquer tempo. Vamos agora expor sua aplicação usando um serviço e aplicar alguns rótulos.

    +

    + Rótulos podem ser anexados aos objetos no momento de sua criação ou + posteriormente. Eles podem ser modificados a qualquer momento. Vamos + expor nossa aplicação usando um Service e aplicar alguns rótulos. +


    - Iniciar tutorial interativo› +

    Crie um novo Service

    +

    + Vamos verificar que nossa aplicação está rodando. Utilizaremos o comando + kubectl get e procuraremos por Pods existentes: +

    +

    kubectl get pods

    +

    + Se não houver Pods rodando, isso significa que o ambiente interativo + ainda está recarregando o estado anterior. Por favor, aguarde alguns + instantes e liste os Pods novamente. Você poderá prosseguir assim que + vir um Pod rodando. +

    +

    A seguir, vamos listar os Services existentes no momento no nosso cluster:

    +

    kubectl get services

    +

    + Temos um Service chamado kubernetes que é criado por padrão + quando o minikube inicializa o cluster. + Para criar um novo Service e expô-lo para tráfego externo utilizaremos + o comando expose com o tipo NodePort. +

    +

    kubectl expose deployment/kubernetes-bootcamp --type=NodePort --port 8080

    +

    + Vamos rodar novamente o subcomando get services: +

    +

    kubectl get services

    +

    + Temos agora um Service chamado kubernetes-bootcamp rodando. Aqui vemos + que o Service recebeu um ClusterIP único, uma porta interna e um IP + externo (o IP do nó). +

    +

    + Para descobrir qual porta foi aberta externamente (para o Service com + tipo NodePort) iremos rodar o subcomando describe service: +

    +

    kubectl describe services/kubernetes-bootcamp

    +

    + Crie uma variável de ambiente chamada NODE_PORT que armazena + o número da porta do nó: +

    +

    + export NODE_PORT="$(kubectl get services/kubernetes-bootcamp -o go-template='{{(index .spec.ports 0).nodePort}}')"
    + echo "NODE_PORT=$NODE_PORT" +

    +

    + Agora podemos verificar que a aplicação está exposta externamente ao + cluster utilizando curl, o endereço IP do nó e a porta + exposta externamente: +

    +

    curl http://"$(minikube ip):$NODE_PORT"

    +

    E receberemos uma resposta do servidor. O Service está exposto.

    + +
    +
    +

    Passo 2: Utilizando rótulos (labels)

    +
    +

    + O Deployment criou automaticamente um rótulo para o nosso Pod. Com o + subcomando describe deployment você pode ver o nome + (a chave) deste rótulo: +

    +

    kubectl describe deployment

    +

    + Vamos utilizar este rótulo para filtrar nossa lista de Pods. + Utilizaremos o comando kubectl get pods com o parâmetro + -l, seguido dos valores dos rótulos: +

    +

    kubectl get pods -l app=kubernetes-bootcamp

    +

    Você pode fazer o mesmo para listar os Services existentes:

    +

    kubectl get services -l app=kubernetes-bootcamp

    +

    + Obtenha o nome do Pod e armazene-o na variável de ambiente POD_NAME: +

    +

    + export POD_NAME="$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}')"
    + echo "Name of the Pod: $POD_NAME" +

    +

    + Para aplicar um novo rótulo podemos utilizar o subcomando label, + seguido pelo tipo de objeto, nome do objeto e o novo rótulo: +

    +

    kubectl label pods "$POD_NAME" version=v1

    +

    + Este comando aplicará um novo rótulo no Pod (nós fixamos a versão + da aplicação ao Pod) e podemos verificar com o comando + describe pod: +

    +

    kubectl describe pods "$POD_NAME"

    +

    + Vemos aqui que o rótulo está agora vinculado ao nosso Pod. E agora + podemos pesquisar a lista de Pods utilizando o novo label: +

    +

    kubectl get pods -l version=v1

    +

    E vemos o Pod.

    +
    +
    +
    + +
    +
    +

    Removendo um Service

    +

    + Para remover um Service você pode utilizar o subcomando delete service. + Rótulos também podem ser utilizados aqui: +

    +

    kubectl delete service -l app=kubernetes-bootcamp

    +

    + Confirme que o Service foi removido com sucesso: +

    +

    kubectl get services

    +

    + Isto confirma que nosso Service foi removido. Para confirmar que a rota + não está mais exposta, você pode disparar uma requisição para o endereço + IP e porta previamente expostos através do comando curl: +

    +

    curl http://"$(minikube ip):$NODE_PORT"

    +

    + Isto prova que a aplicação não está mais acessível de fora do cluster. + Você pode confirmar que a aplicação ainda está rodando com um curl + de dentro do Pod: +

    +

    kubectl exec -ti $POD_NAME -- curl http://localhost:8080

    +

    + Vemos aqui que a aplicação ainda está rodando. Isto se deve ao fato de + que o Deployment está gerenciando a aplicação. Para encerrar a aplicação, + você precisaria remover o Deployment também. +

    +
    +
    + +
    +

    + Assim que você finalizar este tutorial, vá para + + Executando Múltiplas Instâncias do seu Aplicativo. +

    +