From ac7b4b25129cbb831300a38d3ae3f72425d9f3b1 Mon Sep 17 00:00:00 2001 From: Paulo Ponciano Date: Fri, 28 Nov 2025 17:06:45 -0300 Subject: [PATCH 1/2] [pt-br] Add concepts/services-networking/service.md --- .../concepts/services-networking/service.md | 1088 +++++++++++++++++ 1 file changed, 1088 insertions(+) create mode 100644 content/pt-br/docs/concepts/services-networking/service.md diff --git a/content/pt-br/docs/concepts/services-networking/service.md b/content/pt-br/docs/concepts/services-networking/service.md new file mode 100644 index 0000000000000..b92d90e2ab3a4 --- /dev/null +++ b/content/pt-br/docs/concepts/services-networking/service.md @@ -0,0 +1,1088 @@ +--- +title: Service +api_metadata: +- apiVersion: "v1" + kind: "Service" +feature: + title: Descoberta de serviços e balanceamento de carga + description: > + Não há necessidade de modificar sua aplicação para usar um mecanismo de descoberta de serviços desconhecido. O Kubernetes fornece aos Pods seus próprios endereços IP e um único nome DNS para um conjunto de Pods, e pode balancear a carga entre eles. +description: >- + Exponha uma aplicação em execução no seu cluster por trás de um único + endpoint voltado para o exterior, mesmo quando a carga de trabalho está dividida entre vários backends. +content_type: concept +weight: 10 +--- + + + + +{{< glossary_definition term_id="service" length="short" prepend="No Kubernetes, um Service é" >}} + +Um objetivo fundamental dos Services no Kubernetes é que você não precise modificar sua aplicação +existente para usar um mecanismo de descoberta de serviços desconhecido. +Você pode executar código em Pods, seja um código projetado para um mundo nativo em nuvem, ou +uma aplicação mais antiga que você containerizou. Você usa um Service para tornar esse conjunto de Pods disponível +na rede para que os clientes possam interagir com ele. + +Se você usa um {{< glossary_tooltip term_id="deployment" >}} para executar sua aplicação, +esse Deployment pode criar e destruir Pods dinamicamente. De um momento para o outro, +você não sabe quantos desses Pods estão funcionando e saudáveis; você pode nem mesmo saber +como esses Pods saudáveis são nomeados. +Os {{< glossary_tooltip term_id="pod" text="Pods" >}} do Kubernetes são criados e destruídos +para corresponder ao estado desejado do seu cluster. Pods são recursos efêmeros (você não deve +esperar que um Pod individual seja confiável e durável). + +Cada Pod obtém seu próprio endereço IP (o Kubernetes espera que os plugins de rede garantam isso). +Para um determinado Deployment no seu cluster, o conjunto de Pods em execução em um momento no +tempo pode ser diferente do conjunto de Pods executando essa aplicação um momento depois. + +Isso leva a um problema: se algum conjunto de Pods (chame-os de "backends") fornece +funcionalidade para outros Pods (chame-os de "frontends") dentro do seu cluster, +como os frontends descobrem e mantêm o controle de qual endereço IP conectar, +para que o frontend possa usar a parte backend da carga de trabalho? + +Entram os _Services_. + + + +## Services no Kubernetes + +A API Service, parte do Kubernetes, é uma abstração para ajudá-lo a expor grupos de +Pods em uma rede. Cada objeto Service define um conjunto lógico de endpoints (geralmente +esses endpoints são Pods) junto com uma política sobre como tornar esses pods acessíveis. + +Por exemplo, considere um backend de processamento de imagens sem estado que está em execução com +3 réplicas. Essas réplicas são fungíveis—os frontends não se importam com qual backend +eles usam. Embora os Pods reais que compõem o conjunto de backend possam mudar, os +clientes frontend não devem precisar estar cientes disso, nem devem precisar manter +o controle do conjunto de backends por conta própria. + +A abstração Service permite esse desacoplamento. + +O conjunto de Pods direcionado por um Service geralmente é determinado +por um {{< glossary_tooltip text="seletor" term_id="selector" >}} que você +define. +Para aprender sobre outras maneiras de definir endpoints de Service, +consulte [Services _sem_ seletores](#services-without-selectors). + +Se sua carga de trabalho fala HTTP, você pode optar por usar um +[Ingress](/docs/concepts/services-networking/ingress/) para controlar como o tráfego web +alcança essa carga de trabalho. +Ingress não é um tipo de Service, mas atua como o ponto de entrada para o seu +cluster. Um Ingress permite que você consolide suas regras de roteamento em um único recurso, para +que você possa expor múltiplos componentes da sua carga de trabalho, executando separadamente no seu +cluster, atrás de um único ponto de entrada. + +O [Gateway API](https://gateway-api.sigs.k8s.io/#what-is-the-gateway-api) para Kubernetes +fornece capacidades extras além de Ingress e Service. Você pode adicionar Gateway ao seu cluster - +é uma família de APIs de extensão, implementadas usando +{{< glossary_tooltip term_id="CustomResourceDefinition" text="CustomResourceDefinitions" >}} - +e então usá-las para configurar o acesso a serviços de rede que estão em execução no seu cluster. + +### Descoberta de serviços nativa em nuvem + +Se você puder usar as APIs do Kubernetes para descoberta de serviços na sua aplicação, +você pode consultar o {{< glossary_tooltip text="servidor de API" term_id="kube-apiserver" >}} +para EndpointSlices correspondentes. O Kubernetes atualiza os EndpointSlices para um Service +sempre que o conjunto de Pods em um Service muda. + +Para aplicações não nativas, o Kubernetes oferece maneiras de colocar uma porta de rede ou balanceador de +carga entre sua aplicação e os Pods de backend. + +De qualquer forma, sua carga de trabalho pode usar esses mecanismos de [descoberta de serviços](#discovering-services) +para encontrar o destino ao qual deseja se conectar. + +## Definindo um Service + +Um Service é um {{< glossary_tooltip text="objeto" term_id="object" >}} +(da mesma forma que um Pod ou um ConfigMap é um objeto). Você pode criar, +visualizar ou modificar definições de Service usando a API do Kubernetes. Normalmente +você usa uma ferramenta como `kubectl` para fazer essas chamadas para a API. + +Por exemplo, suponha que você tenha um conjunto de Pods que escutam na porta TCP 9376 +e são rotulados como `app.kubernetes.io/name=MyApp`. Você pode definir um Service para +publicar esse ponto de entrada TCP: + +{{% code_sample file="service/simple-service.yaml" %}} + +Aplicar esse manifesto cria um novo Service chamado "my-service" com o +[tipo de Service](#publishing-services-service-types) ClusterIP padrão. O Service +direciona para a porta TCP 9376 em qualquer Pod com o rótulo `app.kubernetes.io/name: MyApp`. + +O Kubernetes atribui a este Service um endereço IP (o _IP do cluster_), +que é usado pelo mecanismo de endereço IP virtual. Para mais detalhes sobre esse mecanismo, +leia [IPs Virtuais e Proxies de Service](/docs/reference/networking/virtual-ips/). + +O controlador para esse Service verifica continuamente por Pods que +correspondam ao seu seletor, e então faz quaisquer atualizações necessárias ao conjunto de +EndpointSlices para o Service. + +O nome de um objeto Service deve ser um +[nome de rótulo RFC 1035](/docs/concepts/overview/working-with-objects/names#rfc-1035-label-names) válido. + + +{{< note >}} +Um Service pode mapear _qualquer_ `port` de entrada para uma `targetPort`. Por padrão e +por conveniência, a `targetPort` é definida com o mesmo valor do campo `port`. +{{< /note >}} + +### Requisitos de nomenclatura relaxados para objetos Service + +{{< feature-state feature_gate_name="RelaxedServiceNameValidation" >}} + +O feature gate `RelaxedServiceNameValidation` permite que nomes de objetos Service comecem com um dígito. Quando este feature gate está habilitado, os nomes de objetos Service devem ser [nomes de rótulo RFC 1123](/docs/concepts/overview/working-with-objects/names/#dns-label-names) válidos. + +### Definições de porta {#field-spec-ports} + +Definições de porta em Pods têm nomes, e você pode referenciar esses nomes no +atributo `targetPort` de um Service. Por exemplo, podemos vincular a `targetPort` +do Service à porta do Pod da seguinte maneira: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: nginx + labels: + app.kubernetes.io/name: proxy +spec: + containers: + - name: nginx + image: nginx:stable + ports: + - containerPort: 80 + name: http-web-svc + +--- +apiVersion: v1 +kind: Service +metadata: + name: nginx-service +spec: + selector: + app.kubernetes.io/name: proxy + ports: + - name: name-of-service-port + protocol: TCP + port: 80 + targetPort: http-web-svc +``` + +Isso funciona mesmo se houver uma mistura de Pods no Service usando um único +nome configurado, com o mesmo protocolo de rede disponível através de diferentes +números de porta. Isso oferece muita flexibilidade para implantar e evoluir +seus Services. Por exemplo, você pode alterar os números de porta que os Pods expõem +na próxima versão do seu software de backend, sem quebrar os clientes. + +O protocolo padrão para Services é +[TCP](/docs/reference/networking/service-protocols/#protocol-tcp); você também pode +usar qualquer outro [protocolo suportado](/docs/reference/networking/service-protocols/). + +Como muitos Services precisam expor mais de uma porta, o Kubernetes suporta +[múltiplas definições de porta](#multi-port-services) para um único Service. +Cada definição de porta pode ter o mesmo `protocol`, ou um diferente. + +### Services sem seletores {#services-without-selectors} + +Services mais comumente abstraem o acesso a Pods do Kubernetes graças ao seletor, +mas quando usados com um conjunto correspondente de +objetos {{}} +e sem um seletor, o Service pode abstrair outros tipos de backends, +incluindo aqueles que são executados fora do cluster. + +Por exemplo: + +* Você quer ter um cluster de banco de dados externo em produção, mas no seu + ambiente de teste você usa seus próprios bancos de dados. +* Você quer apontar seu Service para um Service em um + {{< glossary_tooltip term_id="namespace" >}} diferente ou em outro cluster. +* Você está migrando uma carga de trabalho para o Kubernetes. Ao avaliar a abordagem, + você executa apenas uma parte dos seus backends no Kubernetes. + +Em qualquer um desses cenários, você pode definir um Service _sem_ especificar um +seletor para corresponder aos Pods. Por exemplo: + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: my-service +spec: + ports: + - name: http + protocol: TCP + port: 80 + targetPort: 9376 +``` + +Como este Service não tem seletor, os objetos EndpointSlice +correspondentes não são criados automaticamente. Você pode mapear o Service +para o endereço de rede e porta onde ele está sendo executado, adicionando um objeto EndpointSlice +manualmente. Por exemplo: + +```yaml +apiVersion: discovery.k8s.io/v1 +kind: EndpointSlice +metadata: + name: my-service-1 # por convenção, use o nome do Service + # como um prefixo para o nome do EndpointSlice + labels: + # Você deve definir o rótulo "kubernetes.io/service-name". + # Defina seu valor para corresponder ao nome do Service + kubernetes.io/service-name: my-service +addressType: IPv4 +ports: + - name: http # deve corresponder ao nome da porta do service definida acima + appProtocol: http + protocol: TCP + port: 9376 +endpoints: + - addresses: + - "10.4.5.6" + - addresses: + - "10.1.2.3" +``` + +#### EndpointSlices personalizados + +Quando você cria um objeto [EndpointSlice](#endpointslices) para um Service, você pode +usar qualquer nome para o EndpointSlice. Cada EndpointSlice em um namespace deve ter um +nome único. Você vincula um EndpointSlice a um Service definindo o +{{< glossary_tooltip text="rótulo" term_id="label" >}} `kubernetes.io/service-name` +nesse EndpointSlice. + +{{< note >}} +Os IPs de endpoint _não devem_ ser: loopback (127.0.0.0/8 para IPv4, ::1/128 para IPv6), ou +link-local (169.254.0.0/16 e 224.0.0.0/24 para IPv4, fe80::/64 para IPv6). + +Os endereços IP de endpoint não podem ser os IPs de cluster de outros Services do Kubernetes, +porque o {{< glossary_tooltip term_id="kube-proxy" >}} não suporta IPs virtuais +como destino. +{{< /note >}} + +Para um EndpointSlice que você criar por conta própria, ou no seu próprio código, +você também deve escolher um valor para usar no rótulo +[`endpointslice.kubernetes.io/managed-by`](/docs/reference/labels-annotations-taints/#endpointslicekubernetesiomanaged-by). +Se você criar seu próprio código de controlador para gerenciar EndpointSlices, considere usar um +valor similar a `"my-domain.example/name-of-controller"`. Se você estiver usando uma +ferramenta de terceiros, use o nome da ferramenta em letras minúsculas e altere espaços e outras +pontuações para traços (`-`). +Se as pessoas estiverem usando diretamente uma ferramenta como `kubectl` para gerenciar EndpointSlices, +use um nome que descreva esse gerenciamento manual, como `"staff"` ou +`"cluster-admins"`. Você deve +evitar usar o valor reservado `"controller"`, que identifica EndpointSlices +gerenciados pela própria camada de gerenciamento do Kubernetes. + +#### Acessando um Service sem seletor {#service-no-selector-access} + +Acessar um Service sem seletor funciona da mesma forma que se tivesse um seletor. +No [exemplo](#services-without-selectors) de um Service sem seletor, +o tráfego é roteado para um dos dois endpoints definidos no +manifesto EndpointSlice: uma conexão TCP para 10.1.2.3 ou 10.4.5.6, na porta 9376. + +{{< note >}} +O servidor de API do Kubernetes não permite proxy para endpoints que não estão mapeados para +pods. Ações como `kubectl port-forward service/ forwardedPort:servicePort` onde o service não tem +seletor falharão devido a essa restrição. Isso impede que o servidor de API do Kubernetes +seja usado como um proxy para endpoints aos quais o solicitante pode não estar autorizado a acessar. +{{< /note >}} + +Um Service `ExternalName` é um caso especial de Service que não possui +seletores e usa nomes DNS em vez disso. Para mais informações, consulte a +seção [ExternalName](#externalname). + +### EndpointSlices + +{{< feature-state for_k8s_version="v1.21" state="stable" >}} + +[EndpointSlices](/docs/concepts/services-networking/endpoint-slices/) são objetos que +representam um subconjunto (uma _fatia_) dos endpoints de rede de suporte para um Service. + +Seu cluster Kubernetes rastreia quantos endpoints cada EndpointSlice representa. +Se houver tantos endpoints para um Service que um limite seja atingido, então +o Kubernetes adiciona outro EndpointSlice vazio e armazena novas informações de endpoint +lá. +Por padrão, o Kubernetes cria um novo EndpointSlice assim que os EndpointSlices +existentes contêm pelo menos 100 endpoints. O Kubernetes não cria o novo EndpointSlice +até que um endpoint extra precise ser adicionado. + +Consulte [EndpointSlices](/docs/concepts/services-networking/endpoint-slices/) para mais +informações sobre esta API. + +### Endpoints (descontinuado) {#endpoints} + +{{< feature-state for_k8s_version="v1.33" state="deprecated" >}} + +A API EndpointSlice é a evolução da antiga +API [Endpoints](/docs/reference/kubernetes-api/service-resources/endpoints-v1/). +A API Endpoints descontinuada tem vários problemas em relação ao +EndpointSlice: + + - Ela não suporta clusters dual-stack. + - Ela não contém informações necessárias para suportar funcionalidades mais recentes, como + [trafficDistribution](/docs/concepts/services-networking/service/#traffic-distribution). + - Ela truncará a lista de endpoints se for muito longa para caber em um único objeto. + +Devido a isso, é recomendado que todos os clientes usem a +API EndpointSlice em vez de Endpoints. + +#### Endpoints com capacidade excedida + +O Kubernetes limita o número de endpoints que podem caber em um único objeto Endpoints. +Quando há mais de 1000 endpoints de suporte para um Service, o Kubernetes +trunca os dados no objeto Endpoints. Como um Service pode ser vinculado +a mais de um EndpointSlice, o limite de 1000 endpoints de suporte afeta apenas +a API Endpoints legada. + +Nesse caso, o Kubernetes seleciona no máximo 1000 endpoints de backend possíveis para armazenar +no objeto Endpoints, e define uma +{{< glossary_tooltip text="anotação" term_id="annotation" >}} no Endpoints: +[`endpoints.kubernetes.io/over-capacity: truncated`](/docs/reference/labels-annotations-taints/#endpoints-kubernetes-io-over-capacity). +A camada de gerenciamento também remove essa anotação se o número de Pods de backend cair abaixo de 1000. + +O tráfego ainda é enviado para os backends, mas qualquer mecanismo de balanceamento de carga que dependa da +API Endpoints legada envia tráfego apenas para no máximo 1000 dos endpoints de suporte disponíveis. + +O mesmo limite da API significa que você não pode atualizar manualmente um Endpoints para ter mais de 1000 endpoints. + +### Protocolo de aplicação + +{{< feature-state for_k8s_version="v1.20" state="stable" >}} + +O campo `appProtocol` fornece uma maneira de especificar um protocolo de aplicação para +cada porta do Service. Isso é usado como uma dica para implementações oferecerem +comportamento mais rico para protocolos que elas entendem. +O valor deste campo é espelhado pelos objetos +Endpoints e EndpointSlice correspondentes. + +Este campo segue a sintaxe de rótulo padrão do Kubernetes. Valores válidos são um dos seguintes: + +* [Nomes de serviço padrão IANA](https://www.iana.org/assignments/service-names). + +* Nomes prefixados definidos pela implementação, como `mycompany.com/my-custom-protocol`. + +* Nomes prefixados definidos pelo Kubernetes: + +| Protocolo | Descrição | +|----------|-------------| +| `kubernetes.io/h2c` | HTTP/2 sobre cleartext conforme descrito na [RFC 7540](https://www.rfc-editor.org/rfc/rfc7540) | +| `kubernetes.io/ws` | WebSocket sobre cleartext conforme descrito na [RFC 6455](https://www.rfc-editor.org/rfc/rfc6455) | +| `kubernetes.io/wss` | WebSocket sobre TLS conforme descrito na [RFC 6455](https://www.rfc-editor.org/rfc/rfc6455) | + +### Services multi-porta {#multi-port-services} + +Para alguns Services, você precisa expor mais de uma porta. +O Kubernetes permite que você configure múltiplas definições de porta em um objeto Service. +Ao usar múltiplas portas para um Service, você deve dar nomes a todas as suas portas +para que estas sejam inequívocas. +Por exemplo: + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: my-service +spec: + selector: + app.kubernetes.io/name: MyApp + ports: + - name: http + protocol: TCP + port: 80 + targetPort: 9376 + - name: https + protocol: TCP + port: 443 + targetPort: 9377 +``` + +{{< note >}} +Assim como os {{< glossary_tooltip term_id="name" text="nomes">}} do Kubernetes em geral, os nomes de portas +devem conter apenas caracteres alfanuméricos em minúsculas e `-`. Os nomes de portas também devem +começar e terminar com um caractere alfanumérico. + +Por exemplo, os nomes `123-abc` e `web` são válidos, mas `123_abc` e `-web` não são. +{{< /note >}} + +## Tipo de Service {#publishing-services-service-types} + +Para algumas partes da sua aplicação (por exemplo, frontends) você pode querer expor um +Service em um endereço IP externo, acessível de fora do seu +cluster. + +Os tipos de Service do Kubernetes permitem que você especifique que tipo de Service você deseja. + +Os valores de `type` disponíveis e seus comportamentos são: + +[`ClusterIP`](#type-clusterip) +: Expõe o Service em um IP interno do cluster. Escolher este valor + torna o Service acessível apenas de dentro do cluster. Este é o + padrão usado se você não especificar explicitamente um `type` para um Service. + Você pode expor o Service para a internet pública usando um + [Ingress](/docs/concepts/services-networking/ingress/) ou um + [Gateway](https://gateway-api.sigs.k8s.io/). + +[`NodePort`](#type-nodeport) +: Expõe o Service no IP de cada Node em uma porta estática (a `NodePort`). + Para disponibilizar a porta do nó, o Kubernetes configura um endereço IP do cluster, + o mesmo que se você tivesse solicitado um Service do `type: ClusterIP`. + +[`LoadBalancer`](#loadbalancer) +: Expõe o Service externamente usando um balanceador de carga externo. O Kubernetes + não oferece diretamente um componente de balanceamento de carga; você deve fornecer um, ou + pode integrar seu cluster Kubernetes com um provedor de nuvem. + +[`ExternalName`](#externalname) +: Mapeia o Service para o conteúdo do campo `externalName` (por exemplo, + para o nome de host `api.foo.bar.example`). O mapeamento configura o servidor + DNS do seu cluster para retornar um registro `CNAME` com esse valor de nome de host externo. + Nenhum tipo de proxy é configurado. + +O campo `type` na API Service é projetado como funcionalidade aninhada - cada nível +adiciona ao anterior. No entanto, há uma exceção a este design aninhado. Você pode +definir um Service `LoadBalancer` +[desabilitando a alocação de `NodePort` do balanceador de carga](/docs/concepts/services-networking/service/#load-balancer-nodeport-allocation). + +### `type: ClusterIP` {#type-clusterip} + +Este tipo de Service padrão atribui um endereço IP de um pool de endereços IP que +seu cluster reservou para esse propósito. + +Vários dos outros tipos de Service são construídos sobre o tipo `ClusterIP` como +fundação. + +Se você definir um Service que tenha o `.spec.clusterIP` definido como `"None"`, então +o Kubernetes não atribui um endereço IP. Consulte [headless Services](#headless-services) +para mais informações. + +#### Escolhendo seu próprio endereço IP + +Você pode especificar seu próprio endereço IP do cluster como parte de uma requisição de +criação de `Service`. Para fazer isso, defina o campo `.spec.clusterIP`. Por exemplo, se você +já tem uma entrada DNS existente que deseja reutilizar, ou sistemas legados +que estão configurados para um endereço IP específico e difíceis de reconfigurar. + +O endereço IP que você escolher deve ser um endereço IPv4 ou IPv6 válido dentro do +intervalo CIDR `service-cluster-ip-range` que está configurado para o servidor de API. +Se você tentar criar um Service com um valor de `clusterIP` inválido, o servidor de API +retornará um código de status HTTP 422 para indicar que há um problema. + +Leia [evitando conflitos](/docs/reference/networking/virtual-ips/#avoiding-collisions) +para aprender como o Kubernetes ajuda a reduzir o risco e o impacto de dois Services diferentes +tentando usar o mesmo endereço IP. + +### `type: NodePort` {#type-nodeport} + +Se você definir o campo `type` como `NodePort`, a camada de gerenciamento do Kubernetes +aloca uma porta de um intervalo especificado pela flag `--service-node-port-range` (padrão: 30000-32767). +Cada nó faz proxy dessa porta (o mesmo número de porta em cada Node) para o seu Service. +Seu Service reporta a porta alocada no campo `.spec.ports[*].nodePort`. + +Usar um NodePort lhe dá a liberdade de configurar sua própria solução de balanceamento de carga, +configurar ambientes que não são totalmente suportados pelo Kubernetes, ou até mesmo +expor diretamente os endereços IP de um ou mais nós. + +Para um Service do tipo node port, o Kubernetes aloca adicionalmente uma porta (TCP, UDP ou +SCTP para corresponder ao protocolo do Service). Cada nó no cluster se configura +para escutar nessa porta atribuída e encaminhar o tráfego para um dos endpoints prontos +associados a esse Service. Você poderá contatar o Service `type: NodePort` +de fora do cluster, conectando-se a qualquer nó usando o protocolo apropriado +(por exemplo: TCP), e a porta apropriada (conforme atribuída a esse Service). + +#### Escolhendo sua própria porta {#nodeport-custom-port} + +Se você deseja um número de porta específico, pode especificar um valor no campo `nodePort`. +A camada de gerenciamento alocará essa porta para você ou reportará que +a transação da API falhou. +Isso significa que você precisa cuidar de possíveis conflitos de porta por conta própria. +Você também precisa usar um número de porta válido, que esteja dentro do intervalo configurado +para uso de NodePort. + +Aqui está um exemplo de manifesto para um Service do `type: NodePort` que especifica +um valor NodePort (30007, neste exemplo): + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: my-service +spec: + type: NodePort + selector: + app.kubernetes.io/name: MyApp + ports: + - port: 80 + # Por padrão e por conveniência, a `targetPort` é definida com + # o mesmo valor do campo `port`. + targetPort: 80 + # Campo opcional + # Por padrão e por conveniência, a camada de gerenciamento do Kubernetes + # alocará uma porta de um intervalo (padrão: 30000-32767) + nodePort: 30007 +``` + +#### Reserve intervalos de Nodeport para evitar conflitos {#avoid-nodeport-collisions} + +A política para atribuir portas a services NodePort se aplica tanto aos cenários de atribuição automática quanto +de atribuição manual. Quando um usuário deseja criar um service NodePort que +usa uma porta específica, a porta de destino pode entrar em conflito com outra porta que já foi atribuída. + +Para evitar este problema, o intervalo de portas para services NodePort é dividido em duas faixas. +A atribuição dinâmica de portas usa a faixa superior por padrão, e pode usar a faixa inferior uma vez que a +faixa superior tenha sido esgotada. Os usuários podem então alocar da faixa inferior com menor risco de conflito de porta. + +#### Configuração de endereço IP personalizado para Services `type: NodePort` {#service-nodeport-custom-listen-address} + +Você pode configurar nós no seu cluster para usar um endereço IP específico para servir services de +node port. Você pode querer fazer isso se cada nó estiver conectado a múltiplas redes (por exemplo: +uma rede para tráfego de aplicação, e outra rede para tráfego entre nós e a +camada de gerenciamento). + +Se você deseja especificar endereço(s) IP particular(es) para fazer proxy da porta, você pode definir a +flag `--nodeport-addresses` para o kube-proxy ou o campo equivalente `nodePortAddresses` +do [arquivo de configuração do kube-proxy](/docs/reference/config-api/kube-proxy-config.v1alpha1/) +para bloco(s) de IP particular(es). + +Esta flag recebe uma lista delimitada por vírgulas de blocos de IP (por exemplo, `10.0.0.0/8`, `192.0.2.0/25`) +para especificar intervalos de endereços IP que o kube-proxy deve considerar como locais para este nó. + +Por exemplo, se você iniciar o kube-proxy com a flag `--nodeport-addresses=127.0.0.0/8`, +o kube-proxy seleciona apenas a interface de loopback para Services NodePort. +O padrão para `--nodeport-addresses` é uma lista vazia. +Isso significa que o kube-proxy deve considerar todas as interfaces de rede disponíveis para NodePort. +(Isso também é compatível com versões anteriores do Kubernetes.) +{{< note >}} +Este Service é visível como `:spec.ports[*].nodePort` e `.spec.clusterIP:spec.ports[*].port`. +Se a flag `--nodeport-addresses` para o kube-proxy ou o campo equivalente +no arquivo de configuração do kube-proxy estiver definida, `` seria um +endereço IP de nó filtrado (ou possivelmente endereços IP). +{{< /note >}} + +### `type: LoadBalancer` {#loadbalancer} + +Em provedores de nuvem que suportam balanceadores de carga externos, definir o campo `type` +como `LoadBalancer` provisiona um balanceador de carga para o seu Service. +A criação real do balanceador de carga acontece de forma assíncrona, e +informações sobre o balanceador provisionado são publicadas no campo +`.status.loadBalancer` do Service. +Por exemplo: + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: my-service +spec: + selector: + app.kubernetes.io/name: MyApp + ports: + - protocol: TCP + port: 80 + targetPort: 9376 + clusterIP: 10.0.171.239 + type: LoadBalancer +status: + loadBalancer: + ingress: + - ip: 192.0.2.127 +``` + +O tráfego do balanceador de carga externo é direcionado aos Pods de backend. O provedor de +nuvem decide como é feito o balanceamento de carga. + +Para implementar um Service do `type: LoadBalancer`, o Kubernetes normalmente começa +fazendo as alterações que são equivalentes a você solicitar um Service do +`type: NodePort`. O componente cloud-controller-manager então configura o balanceador de +carga externo para encaminhar o tráfego para essa porta de nó atribuída. + +Você pode configurar um Service com balanceamento de carga para +[omitir](#load-balancer-nodeport-allocation) a atribuição de uma porta de nó, desde que a +implementação do provedor de nuvem suporte isso. + +Alguns provedores de nuvem permitem que você especifique o `loadBalancerIP`. Nesses casos, o balanceador de carga é criado +com o `loadBalancerIP` especificado pelo usuário. Se o campo `loadBalancerIP` não for especificado, +o balanceador de carga é configurado com um endereço IP efêmero. Se você especificar um `loadBalancerIP` +mas seu provedor de nuvem não suportar a funcionalidade, o campo `loadbalancerIP` que você +definiu é ignorado. + + +{{< note >}} +O campo `.spec.loadBalancerIP` para um Service foi descontinuado no Kubernetes v1.24. + +Este campo foi subespecificado e seu significado varia entre as implementações. +Ele também não pode suportar rede dual-stack. Este campo pode ser removido em uma versão futura da API. + +Se você está integrando com um provedor que suporta especificar o(s) endereço(s) IP do balanceador de carga +para um Service via uma anotação (específica do provedor), você deve mudar para fazer isso. + +Se você está escrevendo código para uma integração de balanceador de carga com o Kubernetes, evite usar este campo. +Você pode integrar com [Gateway](https://gateway-api.sigs.k8s.io/) em vez de Service, ou pode +definir suas próprias anotações (específicas do provedor) no Service que especificam o detalhe equivalente. +{{< /note >}} + +#### Impacto da operacionalidade do nó no tráfego do balanceador de carga + +As verificações de saúde do balanceador de carga são críticas para aplicações modernas. Elas são usadas para +determinar para qual servidor (máquina virtual ou endereço IP) o balanceador de carga deve +despachar o tráfego. As APIs do Kubernetes não definem como as verificações de saúde devem ser +implementadas para balanceadores de carga gerenciados pelo Kubernetes, em vez disso, são os provedores de nuvem +(e as pessoas implementando código de integração) que decidem sobre o comportamento. As +verificações de saúde do balanceador de carga são extensivamente usadas no contexto de suportar o +campo `externalTrafficPolicy` para Services. + +#### Balanceadores de carga com tipos de protocolo mistos + +{{< feature-state feature_gate_name="MixedProtocolLBService" >}} + +Por padrão, para Services do tipo LoadBalancer, quando há mais de uma porta definida, todas +as portas devem ter o mesmo protocolo, e o protocolo deve ser um que seja suportado +pelo provedor de nuvem. + +O feature gate `MixedProtocolLBService` (habilitado por padrão para o kube-apiserver a partir da v1.24) permite o uso de +protocolos diferentes para Services do tipo LoadBalancer, quando há mais de uma porta definida. + +{{< note >}} +O conjunto de protocolos que podem ser usados para Services com balanceamento de carga é definido pelo seu +provedor de nuvem; eles podem impor restrições além do que a API do Kubernetes impõe. +{{< /note >}} + +#### Desabilitando a alocação de NodePort do balanceador de carga {#load-balancer-nodeport-allocation} + +{{< feature-state for_k8s_version="v1.24" state="stable" >}} + +Você pode opcionalmente desabilitar a alocação de node port para um Service do `type: LoadBalancer`, definindo +o campo `spec.allocateLoadBalancerNodePorts` como `false`. Isso deve ser usado apenas para implementações de balanceador de carga +que roteiam tráfego diretamente para Pods em vez de usar node ports. Por padrão, `spec.allocateLoadBalancerNodePorts` +é `true` e Services do tipo LoadBalancer continuarão a alocar node ports. Se `spec.allocateLoadBalancerNodePorts` +for definido como `false` em um Service existente com node ports alocados, esses node ports **não** serão desalocados automaticamente. +Você deve remover explicitamente a entrada `nodePorts` em cada porta do Service para desalocar esses node ports. + +#### Especificando a classe de implementação do balanceador de carga {#load-balancer-class} + +{{< feature-state for_k8s_version="v1.24" state="stable" >}} + +Para um Service com `type` definido como `LoadBalancer`, o campo `.spec.loadBalancerClass` +permite que você use uma implementação de balanceador de carga diferente do padrão do provedor de nuvem. + +Por padrão, `.spec.loadBalancerClass` não está definido e um Service do +tipo `LoadBalancer` usa a implementação de balanceador de carga padrão do provedor de nuvem se o +cluster estiver configurado com um provedor de nuvem usando a flag de componente +`--cloud-provider`. + +Se você especificar `.spec.loadBalancerClass`, presume-se que uma implementação de balanceador de carga +que corresponda à classe especificada esteja observando os Services. +Qualquer implementação de balanceador de carga padrão (por exemplo, a fornecida pelo +provedor de nuvem) ignorará Services que tenham este campo definido. +`spec.loadBalancerClass` pode ser definido apenas em um Service do tipo `LoadBalancer`. +Uma vez definido, não pode ser alterado. +O valor de `spec.loadBalancerClass` deve ser um identificador no estilo de rótulo, +com um prefixo opcional como "`internal-vip`" ou "`example.com/internal-vip`". +Nomes sem prefixo são reservados para usuários finais. + +#### Modo do endereço IP do balanceador de carga {#load-balancer-ip-mode} + +{{< feature-state feature_gate_name="LoadBalancerIPMode" >}} + +Para um Service do `type: LoadBalancer`, um controlador pode definir `.status.loadBalancer.ingress.ipMode`. +O `.status.loadBalancer.ingress.ipMode` especifica como o IP do balanceador de carga se comporta. +Ele pode ser especificado apenas quando o campo `.status.loadBalancer.ingress.ip` também estiver especificado. + +Existem dois valores possíveis para `.status.loadBalancer.ingress.ipMode`: "VIP" e "Proxy". +O valor padrão é "VIP", significando que o tráfego é entregue ao nó +com o destino definido para o IP e porta do balanceador de carga. +Existem dois casos ao definir isso como "Proxy", dependendo de como o balanceador de carga +do provedor de nuvem entrega o tráfego: + +- Se o tráfego é entregue ao nó e então sofre DNAT para o Pod, o destino seria definido para o IP do nó e a node port; +- Se o tráfego é entregue diretamente ao Pod, o destino seria definido para o IP e porta do Pod. + +Implementações de Service podem usar esta informação para ajustar o roteamento de tráfego. + +#### Balanceador de carga interno + +Em um ambiente misto, às vezes é necessário rotear o tráfego de Services dentro do mesmo +bloco de endereço de rede (virtual). + +Em um ambiente DNS split-horizon, você precisaria de dois Services para poder rotear tanto o tráfego externo +quanto o interno para seus endpoints. + +Para definir um balanceador de carga interno, adicione uma das seguintes anotações ao seu Service +dependendo do provedor de serviço de nuvem que você está usando: + +{{< tabs name="service_tabs" >}} +{{% tab name="Default" %}} +Select one of the tabs. +{{% /tab %}} + +{{% tab name="GCP" %}} + +```yaml +metadata: + name: my-service + annotations: + networking.gke.io/load-balancer-type: "Internal" +``` +{{% /tab %}} +{{% tab name="AWS" %}} + +```yaml +metadata: + name: my-service + annotations: + service.beta.kubernetes.io/aws-load-balancer-scheme: "internal" +``` + +{{% /tab %}} +{{% tab name="Azure" %}} + +```yaml +metadata: + name: my-service + annotations: + service.beta.kubernetes.io/azure-load-balancer-internal: "true" +``` + +{{% /tab %}} +{{% tab name="IBM Cloud" %}} + +```yaml +metadata: + name: my-service + annotations: + service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private" +``` + +{{% /tab %}} +{{% tab name="OpenStack" %}} + +```yaml +metadata: + name: my-service + annotations: + service.beta.kubernetes.io/openstack-internal-load-balancer: "true" +``` + +{{% /tab %}} +{{% tab name="Baidu Cloud" %}} + +```yaml +metadata: + name: my-service + annotations: + service.beta.kubernetes.io/cce-load-balancer-internal-vpc: "true" +``` + +{{% /tab %}} +{{% tab name="Tencent Cloud" %}} + +```yaml +metadata: + annotations: + service.kubernetes.io/qcloud-loadbalancer-internal-subnetid: subnet-xxxxx +``` + +{{% /tab %}} +{{% tab name="Alibaba Cloud" %}} + +```yaml +metadata: + annotations: + service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "intranet" +``` + +{{% /tab %}} +{{% tab name="OCI" %}} + +```yaml +metadata: + name: my-service + annotations: + service.beta.kubernetes.io/oci-load-balancer-internal: true +``` +{{% /tab %}} +{{< /tabs >}} + +### `type: ExternalName` {#externalname} + +Services do tipo ExternalName mapeiam um Service para um nome DNS, não para um seletor típico como +`my-service` ou `cassandra`. Você especifica esses Services com o parâmetro `spec.externalName`. + +Esta definição de Service, por exemplo, mapeia +o Service `my-service` no namespace `prod` para `my.database.example.com`: + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: my-service + namespace: prod +spec: + type: ExternalName + externalName: my.database.example.com +``` + +{{< note >}} +Um Service do `type: ExternalName` aceita uma string de endereço IPv4, +mas trata essa string como um nome DNS composto por dígitos, +não como um endereço IP (a internet, no entanto, não permite tais nomes em DNS). +Services com nomes externos que se assemelham a endereços IPv4 +não são resolvidos por servidores DNS. + +Se você deseja mapear um Service diretamente para um endereço IP específico, considere usar +[headless Services](#headless-services). +{{< /note >}} + +Ao procurar o host `my-service.prod.svc.cluster.local`, o Service DNS do cluster +retorna um registro `CNAME` com o valor `my.database.example.com`. Acessar +`my-service` funciona da mesma forma que outros Services, mas com a +diferença crucial de que o redirecionamento acontece no nível DNS em vez de via proxy ou +encaminhamento. Se você decidir posteriormente mover seu banco de dados para dentro do seu cluster, você +pode iniciar seus Pods, adicionar seletores ou endpoints apropriados, e alterar o +`type` do Service. + +{{< caution >}} +Você pode ter problemas ao usar ExternalName para alguns protocolos comuns, incluindo HTTP e HTTPS. +Se você usar ExternalName, então o nome do host usado pelos clientes dentro do seu cluster é diferente do +nome que o ExternalName referencia. + +Para protocolos que usam nomes de host, essa diferença pode levar a erros ou respostas inesperadas. +Requisições HTTP terão um cabeçalho `Host:` que o servidor de origem não reconhece; +servidores TLS não serão capazes de fornecer um certificado correspondente ao nome do host ao qual o cliente se conectou. +{{< /caution >}} + +## Headless Services + +Às vezes você não precisa de balanceamento de carga e um único IP de Service. Neste +caso, você pode criar o que são chamados de _headless Services_, especificando explicitamente +`"None"` para o endereço IP do cluster (`.spec.clusterIP`). + +Você pode usar um headless Service para fazer interface com outros mecanismos de descoberta de serviços, +sem estar vinculado à implementação do Kubernetes. + +Para headless Services, um IP de cluster não é alocado, o kube-proxy não manipula +esses Services, e não há balanceamento de carga ou proxy feito pela plataforma para eles. + +Um headless Service permite que um cliente se conecte a qualquer Pod que preferir, diretamente. Headless Services não +configuram rotas e encaminhamento de pacotes usando +[endereços IP virtuais e proxies](/docs/reference/networking/virtual-ips/); em vez disso, Headless Services reportam os +endereços IP de endpoint dos Pods individuais via registros DNS internos, servidos através do +[serviço DNS](/docs/concepts/services-networking/dns-pod-service/) do cluster. +Para definir um headless Service, você cria um Service com `.spec.type` definido como ClusterIP (que também é o padrão para `type`), +e você adicionalmente define `.spec.clusterIP` como None. + +O valor de string None é um caso especial e não é o mesmo que deixar o campo `.spec.clusterIP` não definido. + +Como o DNS é configurado automaticamente depende se o Service tem seletores definidos: + +### Com seletores + +Para headless Services que definem seletores, o controlador de endpoints cria +EndpointSlices na API do Kubernetes, e modifica a configuração DNS para retornar +registros A ou AAAA (endereços IPv4 ou IPv6) que apontam diretamente para os Pods que sustentam o Service. + +### Sem seletores + +Para headless Services que não definem seletores, a camada de gerenciamento não +cria objetos EndpointSlice. No entanto, o sistema DNS procura e configura +um dos seguintes: + +* Registros DNS CNAME para Services [`type: ExternalName`](#externalname). +* Registros DNS A / AAAA para todos os endereços IP dos endpoints prontos do Service, + para todos os tipos de Service diferentes de `ExternalName`. + * Para endpoints IPv4, o sistema DNS cria registros A. + * Para endpoints IPv6, o sistema DNS cria registros AAAA. + +Quando você define um headless Services sem seletor, a `port` deve +corresponder à `targetPort`. + +## Descobrindo Services {#discovering-services} + +Para clientes em execução dentro do seu cluster, o Kubernetes suporta dois modos principais de +encontrar um Service: variáveis de ambiente e DNS. + +### Variáveis de ambiente + +Quando um Pod é executado em um Node, o kubelet adiciona um conjunto de variáveis de ambiente +para cada Service ativo. Ele adiciona as variáveis `{SVCNAME}_SERVICE_HOST` e `{SVCNAME}_SERVICE_PORT`, +onde o nome do Service está em maiúsculas e os traços são convertidos em sublinhados. + + +Por exemplo, o Service `redis-primary` que expõe a porta TCP 6379 e recebeu +o endereço IP de cluster 10.0.0.11, produz as seguintes variáveis de +ambiente: + +```shell +REDIS_PRIMARY_SERVICE_HOST=10.0.0.11 +REDIS_PRIMARY_SERVICE_PORT=6379 +REDIS_PRIMARY_PORT=tcp://10.0.0.11:6379 +REDIS_PRIMARY_PORT_6379_TCP=tcp://10.0.0.11:6379 +REDIS_PRIMARY_PORT_6379_TCP_PROTO=tcp +REDIS_PRIMARY_PORT_6379_TCP_PORT=6379 +REDIS_PRIMARY_PORT_6379_TCP_ADDR=10.0.0.11 +``` + +{{< note >}} +Quando você tem um Pod que precisa acessar um Service, e você está usando +o método de variável de ambiente para publicar a porta e o IP do cluster para os Pods +clientes, você deve criar o Service *antes* dos Pods clientes existirem. +Caso contrário, esses Pods clientes não terão suas variáveis de ambiente preenchidas. + +Se você usar apenas DNS para descobrir o IP do cluster para um Service, você não precisa +se preocupar com esse problema de ordenação. +{{< /note >}} + +O Kubernetes também suporta e fornece variáveis que são compatíveis com a funcionalidade +"_[legacy container links](https://docs.docker.com/network/links/)_" do Docker +Engine. Você pode ler [`makeLinkVariables`](https://github.com/kubernetes/kubernetes/blob/dd2d12f6dc0e654c15d5db57a5f9f6ba61192726/pkg/kubelet/envvars/envvars.go#L72) +para ver como isso é implementado no Kubernetes. + +### DNS + +Você pode (e quase sempre deveria) configurar um serviço DNS para o seu cluster +Kubernetes usando um [complemento](/docs/concepts/cluster-administration/addons/). + +Um servidor DNS com reconhecimento de cluster, como o CoreDNS, observa a API do Kubernetes em busca de novos +Services e cria um conjunto de registros DNS para cada um. Se o DNS foi habilitado +em todo o seu cluster, então todos os Pods devem ser capazes automaticamente de resolver +Services por seu nome DNS. + +Por exemplo, se você tem um Service chamado `my-service` em um +namespace `my-ns` do Kubernetes, a camada de gerenciamento e o Service DNS atuando juntos +criam um registro DNS para `my-service.my-ns`. Os Pods no namespace `my-ns` +devem ser capazes de encontrar o service fazendo uma busca de nome por `my-service` +(`my-service.my-ns` também funcionaria). + +Pods em outros namespaces devem qualificar o nome como `my-service.my-ns`. Esses nomes +resolverão para o IP do cluster atribuído ao Service. + +O Kubernetes também suporta registros DNS SRV (Service) para portas nomeadas. Se o +Service `my-service.my-ns` tiver uma porta chamada `http` com o protocolo definido como +`TCP`, você pode fazer uma consulta DNS SRV para `_http._tcp.my-service.my-ns` para descobrir +o número da porta para `http`, bem como o endereço IP. + +O servidor DNS do Kubernetes é a única maneira de acessar Services `ExternalName`. +Você pode encontrar mais informações sobre resolução `ExternalName` em +[DNS para Services e Pods](/docs/concepts/services-networking/dns-pod-service/). + + + + + + + + + + +## Mecanismo de endereçamento de IP virtual + +Leia [IPs Virtuais e Proxies de Service](/docs/reference/networking/virtual-ips/) que explica o +mecanismo que o Kubernetes fornece para expor um Service com um endereço IP virtual. + +### Políticas de tráfego + +Você pode definir os campos `.spec.internalTrafficPolicy` e `.spec.externalTrafficPolicy` +para controlar como o Kubernetes roteia o tráfego para backends íntegros ("prontos"). + +Consulte [Políticas de Tráfego](/docs/reference/networking/virtual-ips/#traffic-policies) para mais detalhes. + +### Distribuição de tráfego {#traffic-distribution} + +{{< feature-state feature_gate_name="ServiceTrafficDistribution" >}} + +O campo `.spec.trafficDistribution` fornece outra maneira de influenciar o +roteamento de tráfego dentro de um Service do Kubernetes. Enquanto as políticas de tráfego focam em garantias +semânticas estritas, a distribuição de tráfego permite que você expresse _preferências_ +(como rotear para endpoints topologicamente mais próximos). Isso pode ajudar a otimizar +desempenho, custo ou confiabilidade. No Kubernetes {{< skew currentVersion >}}, o +seguinte valor de campo é suportado: + +`PreferClose` +: Indica uma preferência por rotear o tráfego para endpoints que estão na mesma + zona que o cliente. + +{{< feature-state feature_gate_name="PreferSameTrafficDistribution" >}} + +No Kubernetes {{< skew currentVersion >}}, dois valores adicionais estão +disponíveis (a menos que o [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) +`PreferSameTrafficDistribution` esteja +desabilitado): + +`PreferSameZone` +: Este é um alias para `PreferClose` que é mais claro sobre a semântica pretendida. + +`PreferSameNode` +: Indica uma preferência por rotear o tráfego para endpoints que estão no mesmo + nó que o cliente. + +Se o campo não for definido, a implementação aplicará sua estratégia de roteamento padrão. + +Consulte [Distribuição de +Tráfego](/docs/reference/networking/virtual-ips/#traffic-distribution) para +mais detalhes. + +### Persistência de sessão + +Se você quiser garantir que as conexões de um cliente específico sejam passadas para +o mesmo Pod a cada vez, você pode configurar afinidade de sessão baseada no endereço +IP do cliente. Leia [afinidade de sessão](/docs/reference/networking/virtual-ips/#session-affinity) +para saber mais. + +## IPs externos + +Se houver IPs externos que roteiam para um ou mais nós do cluster, os Services do Kubernetes +podem ser expostos nesses `externalIPs`. Quando o tráfego de rede chega ao cluster, com +o IP externo (como IP de destino) e a porta correspondente a esse Service, regras e rotas +que o Kubernetes configurou garantem que o tráfego seja roteado para um dos endpoints +desse Service. + +Quando você define um Service, você pode especificar `externalIPs` para qualquer +[tipo de Service](#publishing-services-service-types). +No exemplo abaixo, o Service chamado `"my-service"` pode ser acessado por clientes usando TCP, +em `"198.51.100.32:80"` (calculado a partir de `.spec.externalIPs[]` e `.spec.ports[].port`). + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: my-service +spec: + selector: + app.kubernetes.io/name: MyApp + ports: + - name: http + protocol: TCP + port: 80 + targetPort: 49152 + externalIPs: + - 198.51.100.32 +``` + +{{< note >}} +O Kubernetes não gerencia a alocação de `externalIPs`; estes são de responsabilidade +do administrador do cluster. +{{< /note >}} + +## Objeto da API + +Service é um recurso de nível superior na API REST do Kubernetes. Você pode encontrar mais detalhes +sobre o [objeto da API Service](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#service-v1-core). + +## {{% heading "whatsnext" %}} + +Saiba mais sobre Services e como eles se encaixam no Kubernetes: + +* Siga o tutorial [Conectando Aplicações com Services](/docs/tutorials/services/connect-applications-service/). +* Leia sobre [Ingress](/docs/concepts/services-networking/ingress/), que + expõe rotas HTTP e HTTPS de fora do cluster para Services dentro + do seu cluster. +* Leia sobre [Gateway](/docs/concepts/services-networking/gateway/), uma extensão do + Kubernetes que fornece mais flexibilidade do que o Ingress. + +Para mais contexto, leia o seguinte: + +* [IPs Virtuais e Proxies de Service](/docs/reference/networking/virtual-ips/) +* [EndpointSlices](/docs/concepts/services-networking/endpoint-slices/) +* [Referência da API Service](/docs/reference/kubernetes-api/service-resources/service-v1/) +* [Referência da API EndpointSlice](/docs/reference/kubernetes-api/service-resources/endpoint-slice-v1/) +* [Referência da API Endpoint (legado)](/docs/reference/kubernetes-api/service-resources/endpoints-v1/) From e2d1a3e90b0c012d125c21f7a340bc28df6fd5c7 Mon Sep 17 00:00:00 2001 From: Paulo Ponciano Date: Mon, 1 Dec 2025 09:41:22 -0300 Subject: [PATCH 2/2] [pt-br] Add concepts/services-networking/service.md --- .../concepts/services-networking/service.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/content/pt-br/docs/concepts/services-networking/service.md b/content/pt-br/docs/concepts/services-networking/service.md index b92d90e2ab3a4..8344419225745 100644 --- a/content/pt-br/docs/concepts/services-networking/service.md +++ b/content/pt-br/docs/concepts/services-networking/service.md @@ -27,8 +27,8 @@ na rede para que os clientes possam interagir com ele. Se você usa um {{< glossary_tooltip term_id="deployment" >}} para executar sua aplicação, esse Deployment pode criar e destruir Pods dinamicamente. De um momento para o outro, -você não sabe quantos desses Pods estão funcionando e saudáveis; você pode nem mesmo saber -como esses Pods saudáveis são nomeados. +você não sabe quantos desses Pods estão funcionando e íntegros; você pode nem mesmo saber +como esses Pods íntegros são nomeados. Os {{< glossary_tooltip term_id="pod" text="Pods" >}} do Kubernetes são criados e destruídos para corresponder ao estado desejado do seu cluster. Pods são recursos efêmeros (você não deve esperar que um Pod individual seja confiável e durável). @@ -80,7 +80,7 @@ fornece capacidades extras além de Ingress e Service. Você pode adicionar Gate {{< glossary_tooltip term_id="CustomResourceDefinition" text="CustomResourceDefinitions" >}} - e então usá-las para configurar o acesso a serviços de rede que estão em execução no seu cluster. -### Descoberta de serviços nativa em nuvem +### Descoberta de serviços nativos em nuvem Se você puder usar as APIs do Kubernetes para descoberta de serviços na sua aplicação, você pode consultar o {{< glossary_tooltip text="servidor de API" term_id="kube-apiserver" >}} @@ -90,7 +90,7 @@ sempre que o conjunto de Pods em um Service muda. Para aplicações não nativas, o Kubernetes oferece maneiras de colocar uma porta de rede ou balanceador de carga entre sua aplicação e os Pods de backend. -De qualquer forma, sua carga de trabalho pode usar esses mecanismos de [descoberta de serviços](#discovering-services) +De qualquer forma, sua carga de trabalho pode usar esses mecanismos de [descoberta de Services](#discovering-services) para encontrar o destino ao qual deseja se conectar. ## Definindo um Service @@ -592,7 +592,7 @@ O tráfego do balanceador de carga externo é direcionado aos Pods de backend. O nuvem decide como é feito o balanceamento de carga. Para implementar um Service do `type: LoadBalancer`, o Kubernetes normalmente começa -fazendo as alterações que são equivalentes a você solicitar um Service do +fazendo as alterações que são equivalentes a você solicitar um Service com `type: NodePort`. O componente cloud-controller-manager então configura o balanceador de carga externo para encaminhar o tráfego para essa porta de nó atribuída. @@ -623,12 +623,12 @@ definir suas próprias anotações (específicas do provedor) no Service que esp #### Impacto da operacionalidade do nó no tráfego do balanceador de carga -As verificações de saúde do balanceador de carga são críticas para aplicações modernas. Elas são usadas para +As verificações de integridade do balanceador de carga são críticas para aplicações modernas. Elas são usadas para determinar para qual servidor (máquina virtual ou endereço IP) o balanceador de carga deve -despachar o tráfego. As APIs do Kubernetes não definem como as verificações de saúde devem ser +despachar o tráfego. As APIs do Kubernetes não definem como as verificações de integridade devem ser implementadas para balanceadores de carga gerenciados pelo Kubernetes, em vez disso, são os provedores de nuvem (e as pessoas implementando código de integração) que decidem sobre o comportamento. As -verificações de saúde do balanceador de carga são extensivamente usadas no contexto de suportar o +verificações de integridade do balanceador de carga são extensivamente usadas no contexto de suportar o campo `externalTrafficPolicy` para Services. #### Balanceadores de carga com tipos de protocolo mistos @@ -893,7 +893,7 @@ um dos seguintes: * Para endpoints IPv4, o sistema DNS cria registros A. * Para endpoints IPv6, o sistema DNS cria registros AAAA. -Quando você define um headless Services sem seletor, a `port` deve +Quando você define um headless Service sem seletor, a `port` deve corresponder à `targetPort`. ## Descobrindo Services {#discovering-services}