Skip to content

Commit cafede5

Browse files
authored
Merge pull request #27704 from edsoncelio/pt_config_best_practices
[PT-BR] Add content/pt-br/docs/concepts/configuration/overview.md
2 parents c88edba + 9141b57 commit cafede5

File tree

1 file changed

+126
-0
lines changed

1 file changed

+126
-0
lines changed
Lines changed: 126 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,126 @@
1+
---
2+
title: Melhores Práticas de Configuração
3+
content_type: concept
4+
weight: 10
5+
---
6+
7+
<!-- overview -->
8+
Esse documento destaca e consolida as melhores práticas de configuração apresentadas em todo o guia de usuário,
9+
na documentação de introdução e nos exemplos.
10+
11+
Este é um documento vivo. Se você pensar em algo que não está nesta lista, mas pode ser útil para outras pessoas,
12+
não hesite em criar uma *issue* ou submeter um PR.
13+
14+
15+
<!-- body -->
16+
## Dicas Gerais de Configuração
17+
18+
- Ao definir configurações, especifique a versão mais recente estável da API.
19+
20+
- Os arquivos de configuração devem ser armazenados em um sistema de controle antes de serem enviados ao cluster.
21+
Isso permite que você reverta rapidamente uma alteração de configuração, caso necessário. Isso também auxilia na recriação e restauração do cluster.
22+
23+
- Escreva seus arquivos de configuração usando YAML ao invés de JSON. Embora esses formatos possam ser usados alternadamente em quase todos os cenários, YAML tende a ser mais amigável.
24+
25+
- Agrupe objetos relacionados em um único arquivo sempre que fizer sentido. Geralmente, um arquivo é mais fácil de
26+
gerenciar do que vários. Veja o [guestbook-all-in-one.yaml](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/all-in-one/guestbook-all-in-one.yaml) como exemplo dessa sintaxe.
27+
28+
- Observe também que vários comandos `kubectl` podem ser chamados em um diretório. Por exemplo, você pode chamar
29+
`kubectl apply` em um diretório de arquivos de configuração.
30+
31+
- Não especifique valores padrões desnecessariamente: configurações simples e mínimas diminuem a possibilidade de erros.
32+
33+
- Coloque descrições de objetos nas anotações para permitir uma melhor análise.
34+
35+
36+
## "Naked" Pods comparados a ReplicaSets, Deployments, e Jobs {#naked-pods-vs-replicasets-deployments-and-jobs}
37+
38+
- Se você puder evitar, não use "naked" Pods (ou seja, se você puder evitar, pods não vinculados a um [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) ou [Deployment](/docs/concepts/workloads/controllers/deployment/)).
39+
Os "naked" pods não serão reconfigurados em caso de falha de um nó.
40+
41+
Criar um Deployment, que cria um ReplicaSet para garantir que o número desejado de Pods esteja disponível e especifica uma estratégia para substituir os Pods (como [RollingUpdate](/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment)), é quase sempre preferível do que criar Pods diretamente, exceto para alguns cenários explícitos de restartPolicy:Never. Um Job também pode ser apropriado.
42+
43+
44+
## Services
45+
46+
- Crie o [Service](/docs/concepts/services-networking/service/) antes de suas cargas de trabalho de backend correspondentes (Deployments ou ReplicaSets) e antes de quaisquer cargas de trabalho que precisem acessá-lo. Quando o
47+
Kubernetes inicia um contêiner, ele fornece variáveis de ambiente apontando para todos os Services que estavam em execução quando o contêiner foi iniciado. Por exemplo, se um Service chamado `foo` existe, todos os contêineres vão
48+
receber as seguintes variáveis em seu ambiente inicial:
49+
50+
```shell
51+
FOO_SERVICE_HOST=<o host em que o Service está executando>
52+
FOO_SERVICE_PORT=<a porta em que o Service está executando>
53+
```
54+
55+
*Isso implica em um requisito de pedido* - qualquer `Service` que um `Pod` quer acessar precisa ser criado antes do `Pod` em si, ou então as variáveis de ambiente não serão populadas. O DNS não possui essa restrição.
56+
57+
- Um [cluster add-on](/docs/concepts/cluster-administration/addons/) opcional (embora fortemente recomendado) é um servidor DNS. O
58+
servidor DNS monitora a API do Kubernetes buscando novos `Services` e cria um conjunto de DNS para cada um. Se o DNS foi habilitado em todo o cluster, então todos os `Pods` devem ser capazes de fazer a resolução de `Services` automaticamente.
59+
60+
- Não especifique um `hostPort` para um Pod a menos que isso seja absolutamente necessário. Quando você vincula um Pod a um `hostPort`, isso limita o número de lugares em que o Pod pode ser agendado, porque cada
61+
combinação de <`hostIP`, `hostPort`, `protocol`> deve ser única. Se você não especificar o `hostIP` e `protocol` explicitamente, o Kubernetes vai usar `0.0.0.0` como o `hostIP` padrão e `TCP` como `protocol` padrão.
62+
63+
Se você precisa de acesso a porta apenas para fins de depuração, pode usar o [apiserver proxy](/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls) ou o [`kubectl port-forward`](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/).
64+
65+
Se você precisa expor explicitamente a porta de um Pod no nó, considere usar um Service do tipo [NodePort](/docs/concepts/services-networking/service/#nodeport) antes de recorrer a `hostPort`.
66+
67+
- Evite usar `hostNetwork` pelos mesmos motivos do `hostPort`.
68+
69+
- Use [headless Services](/docs/concepts/services-networking/service/#headless-services) (que tem um `ClusterIP` ou `None`) para descoberta de serviço quando você não precisar de um balanceador de carga `kube-proxy`.
70+
## Usando Labels
71+
72+
- Defina e use [labels](/docs/concepts/overview/working-with-objects/labels/) que identifiquem _atributos semânticos_ da sua aplicação ou Deployment, como `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`. Você pode usar essas labels para selecionar os Pods apropriados para outros recursos; por exemplo, um Service que seleciona todos os Pods `tier: frontend`, ou todos
73+
os componentes de `app: myapp`. Veja o app [guestbook](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) para exemplos dessa abordagem.
74+
75+
Um Service pode ser feito para abranger vários Deployments, omitindo labels específicas de lançamento de seu seletor. Quando você
76+
precisar atualizar um serviço em execução sem _downtime_, use um [Deployment](/docs/concepts/workloads/controllers/deployment/).
77+
78+
Um estado desejado de um objeto é descrito por um Deployment, e se as alterações nesse _spec_ forem _aplicadas_ o controlador
79+
do Deployment altera o estado real para o estado desejado em uma taxa controlada.
80+
81+
- Use as [labels comuns do Kubernetes](/docs/concepts/overview/working-with-objects/common-labels/) para casos de uso comuns.
82+
Essas labels padronizadas enriquecem os metadados de uma forma que permite que ferramentas, incluindo `kubectl` e a [dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard), funcionem de uma forma interoperável.
83+
84+
- Você pode manipular labels para depuração. Como os controladores do Kubernetes (como ReplicaSet) e Services se relacionam com os Pods usando seletor de labels, remover as labels relevantes de um Pod impedirá que ele seja considerado por um controlador ou que
85+
seja atendido pelo tráfego de um Service. Se você remover as labels de um Pod existente, seu controlador criará um novo Pod para
86+
substituí-lo. Essa é uma maneira útil de depurar um Pod anteriormente "ativo" em um ambiente de "quarentena". Para remover ou
87+
alterar labels interativamente, use [`kubectl label`](/docs/reference/generated/kubectl/kubectl-commands#label).
88+
89+
90+
## Imagens de Contêiner
91+
92+
A [imagePullPolicy](/docs/concepts/containers/images/#updating-images) e tag da imagem afetam quando o [kubelet](/docs/reference/command-line-tools-reference/kubelet/) tenta puxar a imagem especificada.
93+
94+
- `imagePullPolicy: IfNotPresent`: a imagem é puxada apenas se ainda não estiver presente localmente.
95+
96+
- `imagePullPolicy: Always`: sempre que o kubelet inicia um contêiner, ele consulta o *registry* da imagem do contêiner para verificar o resumo de assinatura da imagem. Se o kubelet tiver uma imagem do contêiner com o mesmo resumo de assinatura
97+
armazenado em cache localmente, o kubelet usará a imagem em cache, caso contrário, o kubelet baixa(*pulls*) a imagem com o resumo de assinatura resolvido, e usa essa imagem para iniciar o contêiner.
98+
99+
- `imagePullPolicy` é omitido se a tag da imagem é `:latest` ou se `imagePullPolicy` é omitido é automaticamente definido como `Always`. Observe que _não_ será utilizado para `ifNotPresent`se o valor da tag mudar.
100+
101+
- `imagePullPolicy` é omitido se uma tag da imagem existe mas não `:latest`: `imagePullPolicy` é automaticamente definido como `ifNotPresent`. Observe que isto _não_ será atualizado para `Always` se a tag for removida ou alterada para `:latest`.
102+
103+
- `imagePullPolicy: Never`: presume-se que a imagem exista localmente. Não é feita nenhuma tentativa de puxar a imagem.
104+
105+
{{< note >}}
106+
Para garantir que seu contêiner sempre use a mesma versão de uma imagem, você pode especificar seu [resumo de assinatura](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier);
107+
substitua `<nome-da-imagem>:<tag>` por `<nome-da-imagem>@<hash>` (por exemplo, `image@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`). Esse resumo de assinatura identifica exclusivamente uma versão
108+
específica de uma imagem, então isso nunca vai ser atualizado pelo Kubernetes a menos que você mude o valor do resumo de assinatura da imagem.
109+
{{< /note >}}
110+
111+
{{< note >}}
112+
Você deve evitar o uso da tag `:latest` em produção, pois é mais difícil rastrear qual versão da imagem está sendo executada e mais difícil reverter adequadamente.
113+
{{< /note >}}
114+
115+
{{< note >}}
116+
A semântica de cache do provedor de imagem subjacente torna até mesmo `imagePullPolicy: Always` eficiente, contanto que o registro esteja acessível de forma confiável. Com o Docker, por exemplo, se a imagem já existe, a tentativa de baixar(pull) é rápida porque todas as camadas da imagem são armazenadas em cache e nenhum download de imagem é necessário.
117+
{{< /note >}}
118+
119+
## Usando kubectl
120+
121+
- Use `kubectl apply -f <directory>`. Isso procura por configurações do Kubernetes em todos os arquivos `.yaml`, `.yml` em `<directory>` e passa isso para `apply`.
122+
123+
- Use *labels selectors* para operações `get` e `delete` em vez de nomes de objetos específicos. Consulte as seções sobre [label selectors](/docs/concepts/overview/working-with-objects/labels/#label-selectors)
124+
e [usando Labels efetivamente](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively).
125+
126+
- Use `kubectl create deployment` e `kubectl expose` para criar rapidamente Deployments e Services de um único contêiner. Consulte [Use um Service para acessar uma aplicação em um cluster](/docs/tasks/access-application-cluster/service-access-application-cluster/) para obter um exemplo.

0 commit comments

Comments
 (0)