You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
title: Utilizando um serviço para expor seu aplicativo
3
3
weight: 10
4
+
description: |-
5
+
Aprenda sobre Services no Kubernetes.
6
+
Entenda como rótulos (<i>labels</i>) e seletores (<i>selectors</i>) relacionam-se aos Services.
7
+
Exponha uma aplicação externamente ao cluster Kubernetes.
4
8
---
5
9
6
10
<!DOCTYPE html>
7
11
8
-
<htmllang="en">
12
+
<htmllang="pt-BR">
9
13
10
14
<body>
11
15
@@ -19,40 +23,103 @@
19
23
<divclass="col-md-8">
20
24
<h3>Objetivos</h3>
21
25
<ul>
22
-
<li>Aprenda sobre um Serviço no Kubernetes</li>
23
-
<li>Entenda como os objetos <code>labels</code> e <code>LabelSelector</code>se relacionam a um Serviço</li>
24
-
<li>Exponha uma aplicação externamente ao cluster Kubernetes usando um Serviço</li>
26
+
<li>Aprenda sobre Services no Kubernetes</li>
27
+
<li>Entenda como rótulos (<i>labels</i>) e seletores (<i>selectors</i>) relacionam-se aos Services</li>
28
+
<li>Exponha uma aplicação externamente ao cluster Kubernetes usando um Service</li>
25
29
</ul>
26
30
</div>
27
31
28
32
<divclass="col-md-8">
29
-
<h3>Visão Geral de Serviços Kubernetes</h3>
33
+
<h3>Visão Geral dos Services no Kubernetes</h3>
30
34
31
-
<p><ahref="/docs/concepts/workloads/pods/">Pods</a> Kubernetes são efêmeros. Na verdade, Pods possuem um <ahref="/docs/concepts/workloads/pods/pod-lifecycle/">ciclo de vida</a>. Quando um nó de processamento morre, os Pods executados no nó também são perdidos. A partir disso, o <ahref="/docs/concepts/workloads/controllers/replicaset/">ReplicaSet</a> 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.</p>
35
+
<p>
36
+
<ahref="/docs/concepts/workloads/pods/">Pods</a> do Kubernetes são efêmeros.
37
+
Na verdade, Pods possuem um <ahref="/docs/concepts/workloads/pods/pod-lifecycle/">ciclo de vida</a>.
38
+
Quando um nó de processamento morre, os Pods executados no nó também são
39
+
perdidos. A partir disso, o <ahref="/pt-br/docs/concepts/workloads/controllers/replicaset/">ReplicaSet</a>
40
+
pode dinamicamente retornar o cluster ao estado desejado através da criação
41
+
de novos Pods para manter sua aplicação em execução. Como outro exemplo,
42
+
considere um backend de processamento de imagens com 3 réplicas. Estas
43
+
réplicas são permutáveis; o sistema front-end não deveria se importar
44
+
com as réplicas backend ou ainda se um Pod foi perdido ou recriado. Dito
45
+
isso, cada Pod em um cluster Kubernetes tem um endereço IP único, incluindo
46
+
Pods que estejam rodando no mesmo nó, então há necessidade de ter uma
47
+
forma de reconciliar automaticamente mudanças entre Pods de modo que sua
48
+
aplicação continue funcionando.
49
+
</p>
32
50
33
-
<p>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 <ahref="/docs/concepts/configuration/overview/#general-configuration-tips">(preferencialmente)</a> ou JSON, como todos objetos Kubernetes. O conjunto de Pods selecionados por um Serviço é geralmente determinado por um seletor de rótulos <i>LabelSelector</i> (veja abaixo o motivo pelo qual você pode querer um Serviço sem incluir um seletor <code>selector</code> na especificação <code>spec</code>).</p>
51
+
<p>
52
+
Um objeto Service no Kubernetes é uma abstração que define um conjunto
53
+
lógico de Pods e uma política pela qual acessá-los. Serviços permitem um
54
+
baixo acoplamento entre os Pods dependentes. Um serviço é definido usando
55
+
YAML ou JSON, como todos os manifestos de objetos Kubernetes. O conjunto
56
+
de Pods selecionados por um Service é geralmente determinado por um
57
+
<i>seletor de rótulos</i> (veja abaixo o motivo pelo qual você poderia
58
+
desejar um Service que não inclui um seletor (<code>selector</code>) na
59
+
especificação (<code>spec</code>)).
60
+
</p>
34
61
35
-
<p>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 <code>type</code> na especificação do serviço <code>ServiceSpec</code>:</p>
62
+
<p>
63
+
Embora cada Pod tenha um endereço IP único, estes IPs não são expostos
64
+
externamente ao cluster sem um objeto Service. Objetos Service permitem
65
+
que suas aplicações recebam tráfego. Services podem ser expostos de
66
+
formas diferentes especificando um tipo (campo <code>type</code>) na
67
+
especificação do serviço (campo <tt>spec</tt>):</p>
36
68
<ul>
37
-
<li><i>ClusterIP</i> (padrão) - Expõe o serviço sob um endereço IP interno no cluster. Este tipo faz do serviço somente alcançável de dentro do cluster.</li>
38
-
<li><i>NodePort</i> - Expõe o serviço sob a mesma porta em cada nó selecionado no cluster usando NAT. Faz o serviço acessível externamente ao cluster usando <code><NodeIP>:<NodePort></code>. Superconjunto de ClusterIP.</li>
39
-
<li><i>LoadBalancer</i> - Cria um balanceador de carga externo no provedor de nuvem atual (se suportado) e assinala um endereço IP fixo e externo para o serviço. Superconjunto de NodePort.</li>
40
-
<li><i>ExternalName</i> - Expõe o serviço usando um nome arbitrário (especificado através de <code>externalName</code> na especificação <code>spec</code>) retornando um registro de CNAME com o nome. Nenhum proxy é utilizado. Este tipo requer v1.7 ou mais recente de <code>kube-dns</code>.</li>
69
+
<li>
70
+
<i>ClusterIP</i> (padrão) - Expõe o serviço sob um endereço IP interno
71
+
no cluster. Este tipo de serviço é acessível somente dentro do cluster.
72
+
</li>
73
+
<li>
74
+
<i>NodePort</i> - Expõe o serviço sob a mesma porta em cada nó
75
+
selecionado no cluster usando NAT. Torna o serviço acessível externamente
76
+
ao cluster usando o endereço <code><NodeIP>:<NodePort></code>.
77
+
É um superconjunto do tipo ClusterIP.
78
+
</li>
79
+
<li>
80
+
<i>LoadBalancer</i> - Cria um balanceador de carga externo no provedor
81
+
de nuvem atual (se suportado) e atribui um endereço IP fixo e externo
82
+
para o serviço. É um superconjunto do tipo NodePort.
83
+
</li>
84
+
<li>
85
+
<i>ExternalName</i> - Mapeia o Service para o conteúdo do campo
86
+
<code>externalName</code> (por exemplo, <code>foo.bar.example.com</code>),
87
+
retornando um registro DNS do tipo <code>CNAME</code> com o seu valor.
88
+
Nenhum tipo de proxy é configurado. Este tipo requer a versão 1.7 ou
89
+
mais recente do <code>kube-dns</code>, ou o CoreDNS versão 0.0.8 ou
90
+
superior.
91
+
</li>
41
92
</ul>
42
-
<p>Mais informações sobre diferentes tipos de Serviços podem ser encontradas no tutorial <ahref="/docs/tutorials/services/source-ip/">Utilizando IP de origem</a>. Também confira <ahref="/docs/concepts/services-networking/connect-applications-service">Conectando aplicações com serviços</a>.</p>
43
-
<p>Adicionalmente, note que existem alguns casos de uso com serviços que envolvem a não definição de <code>selector</code> em <code>spec</code>. Serviços criados sem <code>selector</code> 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 <code>type: ExternalName</code>.</p>
93
+
<p>
94
+
Mais informações sobre diferentes tipos de Services podem ser encontradas
95
+
no tutorial <ahref="/docs/tutorials/services/source-ip/">Utilizando IP de origem</a>.
96
+
Veja também <ahref="/docs/tutorials/services/connect-applications-service">Conectando aplicações com serviços</a>.
97
+
</p>
98
+
<p>
99
+
Adicionalmente, note que existem alguns casos de uso com serviços que
100
+
envolvem a ausência de um <code>selector</code> no campo <code>spec</code>.
101
+
Services criados sem <code>selector</code> também não criarão objetos
102
+
Endpoints correspondentes. Isto permite que usuários mapeiem manualmente
103
+
um serviço a <i>endpoints</i> específicos. Outro motivo pelo qual seletores
104
+
podem estar ausentes é que você esteja utilizando estritamente
105
+
<code>type: ExternalName</code>.
106
+
</p>
44
107
</div>
45
108
<divclass="col-md-4">
46
109
<divclass="content__box content__box_lined">
47
110
<h3>Resumo</h3>
48
111
<ul>
49
-
<li>Expõe Pods ao tráfego externo</li>
50
-
<li>Tráfego de balanceamento de carga entre múltiplos Pods</li>
51
-
<li>Uso de rótulos <code>labels</code></li>
112
+
<li>Exposição de Pods ao tráfego externo</li>
113
+
<li>Balanceamento de carga de tráfego entre múltiplos Pods</li>
114
+
<li>Utilização de rótulos (<i>labels</i>)</li>
52
115
</ul>
53
116
</div>
54
117
<divclass="content__box content__box_fill">
55
-
<p><i>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.</i></p>
118
+
<p><i>
119
+
Um objeto Service do Kubernetes é uma camada de abstração que define
120
+
um conjunto lógico de Pods e habilita a exposição ao tráfego externo,
121
+
balanceamento de carga e descoberta de serviço para esses Pods.
122
+
</i></p>
56
123
</div>
57
124
</div>
58
125
</div>
@@ -66,8 +133,20 @@ <h3>Serviços e Rótulos</h3>
66
133
67
134
<divclass="row">
68
135
<divclass="col-md-8">
69
-
<p>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.</p>
70
-
<p>Serviços relacionam um conjunto de Pods usando <ahref="/docs/concepts/overview/working-with-objects/labels">Rótulos e seletores</a>, 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:</p>
136
+
<p>
137
+
Um Service roteia tráfego entre um conjunto de Pods. Service é a
138
+
abstração que permite Pods morrerem e se replicarem no Kubernetes sem
139
+
impactar sua aplicação. A descoberta e o roteamento entre Pods
140
+
dependentes (tal como componentes frontend e backend dentro de uma
141
+
aplicação) são controlados por Services do Kubernetes.
142
+
</p>
143
+
<p>
144
+
Services relacionam um conjunto de Pods usando
145
+
<ahref="/docs/concepts/overview/working-with-objects/labels">rótulos e seletores</a>,
146
+
uma primitiva de agrupamento que permite operações lógicas sobre objetos
147
+
do Kubernetes. Rótulos são pares chave/valor anexados à objetos e
148
+
podem ser usados de diversas formas:
149
+
</p>
71
150
<ul>
72
151
<li>Designar objetos para desenvolvimento, teste e produção</li>
73
152
<li>Adicionar tags de versão</li>
@@ -87,15 +166,154 @@ <h3>Serviços e Rótulos</h3>
87
166
<br>
88
167
<divclass="row">
89
168
<divclass="col-md-8">
90
-
<p>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.</p>
169
+
<p>
170
+
Rótulos podem ser anexados aos objetos no momento de sua criação ou
171
+
posteriormente. Eles podem ser modificados a qualquer momento. Vamos
172
+
expor nossa aplicação usando um Service e aplicar alguns rótulos.
0 commit comments