whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Move portuguese content to pt-br to correct shortcode problems and add redirection (#27413)

Browse Source 
* Move portuguese content to pt-br to correct shortcode problems and add a redirection

* Correct small shortcode

* Move portuguese content to pt-br to correct shortcode problems and add a redirection

* Add missing print page shortcodes
This commit is contained in:
Ricardo Katz
2021-04-19 21:10:33 -03:00
committed by GitHub
parent d342d4d9fe
commit ae197690de
124 changed files with 126 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/pt-br/docs/concepts/containers/_index.md
+34
View File
@@ -0,0 +1,34 @@
---
title: Contêineres
weight: 40
description: Tecnologia para empacotar aplicações com suas dependências em tempo de execução
content_type: concept
no_list: true
---
<!-- overview -->
Cada contêiner executado é repetível; a padronização de ter
dependências incluídas significa que você obtém o mesmo comportamento onde quer que você execute.
Os contêineres separam os aplicativos da infraestrutura de _host_ subjacente.
Isso torna a implantação mais fácil em diferentes ambientes de nuvem ou sistema operacional.
<!-- body -->
## Imagem de contêiner
Uma [imagem de contêiner](/docs/concepts/containers/images/) é um pacote de software pronto para executar, contendo tudo que é preciso para executar uma aplicação:
o código e o agente de execução necessário, aplicação, bibliotecas do sistema e valores padrões para qualquer configuração essencial.
Por _design_, um contêiner é imutável: você não pode mudar o código de um contêiner que já está executando. Se você tem uma aplicação conteinerizada e quer fazer mudanças, você precisa construir uma nova imagem que inclui a mudança, e recriar o contêiner para iniciar a partir da imagem atualizada.
## Agente de execução de contêiner
{{< glossary_definition term_id="container-runtime" length="all" >}}
## {{% heading "whatsnext" %}}
* [Imagens de contêineres](/docs/concepts/containers/images/)
* [Pods](/docs/concepts/workloads/pods/)
content/pt-br/docs/concepts/containers/container-environment.md
+56
View File
@@ -0,0 +1,56 @@
---
title: Ambiente de Contêiner
content_type: concept
weight: 20
---
<!-- overview -->
Essa página descreve os recursos disponíveis para contêineres no ambiente de contêiner.
<!-- body -->
## Ambiente de contêiner
O ambiente de contêiner do Kubernetes fornece recursos importantes para contêineres:
* Um sistema de arquivos, que é a combinação de uma [imagem](/docs/concepts/containers/images/) e um ou mais [volumes](/docs/concepts/storage/volumes/).
* Informação sobre o contêiner propriamente.
* Informação sobre outros objetos no cluster.
### Informação de contêiner
O _hostname_ de um contêiner é o nome do Pod em que o contêiner está executando.
Isso é disponibilizado através do comando `hostname` ou da função [`gethostname`](https://man7.org/linux/man-pages/man2/gethostname.2.html) chamada na libc.
O nome do Pod e o Namespace são expostos como variáveis de ambiente através de um mecanismo chamado [downward API](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/).
Variáveis de ambiente definidas pelo usuário a partir da definição do Pod também são disponíveis para o contêiner, assim como qualquer variável de ambiente especificada estáticamente na imagem Docker.
### Informação do cluster
Uma lista de todos os serviços que estão executando quando um contêiner foi criado é disponibilizada para o contêiner como variáveis de ambiente.
Essas variáveis de ambiente são compatíveis com a funcionalidade _docker link_ do Docker.
Para um serviço nomeado *foo* que mapeia para um contêiner nomeado *bar*, as seguintes variáveis são definidas:
```shell
FOO_SERVICE_HOST=<o host em que o serviço está executando>
FOO_SERVICE_PORT=<a porta em que o serviço está executando>
```
Serviços possuem endereço IP dedicado e são disponibilizados para o contêiner via DNS,
se possuírem [DNS addon](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/) habilitado.
## {{% heading "whatsnext" %}}
* Aprenda mais sobre [hooks de ciclo de vida do contêiner](/docs/concepts/containers/container-lifecycle-hooks/).
* Obtenha experiência prática
[anexando manipuladores a eventos de ciclo de vida do contêiner](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/).
content/pt-br/docs/concepts/containers/container-lifecycle-hooks.md
+114
View File
@@ -0,0 +1,114 @@
---
title: Hooks de Ciclo de Vida do Contêiner
content_type: concept
weight: 30
---
<!-- overview -->
Essa página descreve como os contêineres gerenciados pelo _kubelet_ podem usar a estrutura de _hook_ de ciclo de vida do contêiner para executar código acionado por eventos durante seu ciclo de vida de gerenciamento.
<!-- body -->
## Visão Geral
Análogo a muitas estruturas de linguagem de programação que tem _hooks_ de ciclo de vida de componentes, como angular,
o Kubernetes fornece aos contêineres _hooks_ de ciclo de vida.
Os _hooks_ permitem que os contêineres estejam cientes dos eventos em seu ciclo de vida de gerenciamento
e executem código implementado em um manipulador quando o _hook_ de ciclo de vida correspondente é executado.
## Hooks do contêiner
Existem dois _hooks_ que são expostos para os contêiners:
`PostStart`
Este _hook_ é executado imediatamente após um contêiner ser criado.
Entretanto, não há garantia que o _hook_ será executado antes do ENTRYPOINT do contêiner.
Nenhum parâmetro é passado para o manipulador.
`PreStop`
Esse _hook_ é chamado imediatamente antes de um contêiner ser encerrado devido a uma solicitação de API ou um gerenciamento de evento como liveness/startup probe failure, preemption, resource contention e outros.
Uma chamada ao _hook_ `PreStop` falha se o contêiner já está em um estado finalizado ou concluído e o _hook_ deve ser concluído antes que o sinal TERM seja enviado para parar o contêiner. A contagem regressiva do período de tolerância de término do Pod começa antes que o _hook_ `PreStop` seja executado, portanto, independentemente do resultado do manipulador, o contêiner será encerrado dentro do período de tolerância de encerramento do Pod. Nenhum parâmetro é passado para o manipulador.
Uma descrição mais detalhada do comportamento de término pode ser encontrada em [Término de Pods](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination).
### Implementações de manipulador de hook
Os contêineres podem acessar um _hook_ implementando e registrando um manipulador para esse _hook_.
Existem dois tipos de manipuladores de _hooks_ que podem ser implementados para contêineres:
* Exec - Executa um comando específico, como `pre-stop.sh`, dentro dos cgroups e Namespaces do contêiner.
* HTTP - Executa uma requisição HTTP em um endpoint específico do contêiner.
### Execução do manipulador de hook
Quando um _hook_ de gerenciamento de ciclo de vida do contêiner é chamado, o sistema de gerenciamento do Kubernetes executa o manipulador de acordo com a ação do _hook_, `httpGet` e `tcpSocket` são executados pelo processo kubelet e `exec` é executado pelo contêiner.
As chamadas do manipulador do _hook_ são síncronas no contexto do Pod que contém o contêiner.
Isso significa que para um _hook_ `PostStart`, o ENTRYPOINT do contêiner e o _hook_ disparam de forma assíncrona.
No entanto, se o _hook_ demorar muito para ser executado ou travar, o contêiner não consegue atingir o estado `running`.
Os _hooks_ `PreStop` não são executados de forma assíncrona a partir do sinal para parar o contêiner, o _hook_ precisa finalizar a sua execução antes que o sinal TERM possa ser enviado.
Se um _hook_ `PreStop` travar durante a execução, a fase do Pod será `Terminating` e permanecerá até que o Pod seja morto após seu `terminationGracePeriodSeconds` expirar. Esse período de tolerância se aplica ao tempo total necessário
para o _hook_ `PreStop`executar e para o contêiner parar normalmente.
Se por exemplo, o `terminationGracePeriodSeconds` é 60, e o _hook_ leva 55 segundos para ser concluído, e o contêiner leva 10 segundos para parar normalmente após receber o sinal, então o contêiner será morto antes que possa parar
normalmente, uma vez que o `terminationGracePeriodSeconds` é menor que o tempo total (55 + 10) que é necessário para que essas duas coisas aconteçam.
Se um _hook_ `PostStart` ou `PreStop` falhar, ele mata o contêiner.
Os usuários devem tornar seus _hooks_ o mais leve possíveis.
Há casos, no entanto, em que comandos de longa duração fazem sentido, como ao salvar o estado
antes de parar um contêiner.
### Garantias de entrega de _hooks_
A entrega do _hook_ é destinada a acontecer *pelo menos uma vez*,
o que quer dizer que um _hook_ pode ser chamado várias vezes para qualquer evento,
como para `PostStart` ou `PreStop`.
Depende da implementação do _hook_ lidar com isso corretamente.
Geralmente, apenas entregas únicas são feitas.
Se, por exemplo, um receptor de _hook_ HTTP estiver inativo e não puder receber tráfego,
não há tentativa de reenviar.
Em alguns casos raros, no entanto, pode ocorrer uma entrega dupla.
Por exemplo, se um kubelet reiniciar no meio do envio de um _hook_, o _hook_ pode ser
reenviado depois que o kubelet voltar a funcionar.
### Depurando manipuladores de _hooks_
Os logs para um manipulador de _hook_ não são expostos em eventos de Pod.
Se um manipulador falhar por algum motivo, ele transmitirá um evento.
Para `PostStart` é o evento `FailedPostStartHook` e para `PreStop` é o evento
`FailedPreStopHook`.
Você pode ver esses eventos executando `kubectl describe pod <nome_do_pod>`.
Aqui está um exemplo de saída de eventos da execução deste comando:
```
Events:
FirstSeen LastSeen Count From SubObjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
1m 1m 1 {default-scheduler } Normal Scheduled Successfully assigned test-1730497541-cq1d2 to gke-test-cluster-default-pool-a07e5d30-siqd
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulling pulling image "test:1.0"
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Created Created container with docker id 5c6a256a2567; Security:[seccomp=unconfined]
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulled Successfully pulled image "test:1.0"
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Started Started container with docker id 5c6a256a2567
38s 38s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 5c6a256a2567: PostStart handler: Error executing in Docker Container: 1
37s 37s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 8df9fdfd7054: PostStart handler: Error executing in Docker Container: 1
38s 37s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} Warning FailedSync Error syncing pod, skipping: failed to "StartContainer" for "main" with RunContainerError: "PostStart handler: Error executing in Docker Container: 1"
1m 22s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Warning FailedPostStartHook
```
## {{% heading "whatsnext" %}}
* Saiba mais sobre o [Ambiente de contêiner](/docs/concepts/containers/container-environment/).
* Obtenha experiência prática
[anexando manipuladores a eventos de ciclo de vida do contêiner](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/).
content/pt-br/docs/concepts/containers/images.md
+290
View File
@@ -0,0 +1,290 @@
---
reviewers:
- femrtnz
- jcjesus
- hugopfeffer
title: Imagens
content_type: concept
weight: 10
---
<!-- overview -->
Uma imagem de contêiner representa dados binários que encapsulam uma aplicação e todas as suas dependências de software. As imagens de contêiner são pacotes de software executáveis que podem ser executados de forma autônoma e que fazem suposições muito bem definidas sobre seu agente de execução do ambiente.
Normalmente, você cria uma imagem de contêiner da sua aplicação e a envia para um registro antes de fazer referência a ela em um {{< glossary_tooltip text="Pod" term_id="pod" >}}
Esta página fornece um resumo sobre o conceito de imagem de contêiner.
<!-- body -->
## Nomes das imagens
As imagens de contêiner geralmente recebem um nome como `pause`, `exemplo/meuconteiner`, ou `kube-apiserver`.
As imagens também podem incluir um hostname de algum registro; por exemplo: `exemplo.registro.ficticio/nomeimagem`,
e um possível número de porta; por exemplo: `exemplo.registro.ficticio:10443/nomeimagem`.
Se você não especificar um hostname de registro, o Kubernetes presumirá que você se refere ao registro público do Docker.
Após a parte do nome da imagem, você pode adicionar uma _tag_ (como também usar com comandos como `docker` e` podman`).
As tags permitem identificar diferentes versões da mesma série de imagens.
Tags de imagem consistem em letras maiúsculas e minúsculas, dígitos, sublinhados (`_`),
pontos (`.`) e travessões (` -`).
Existem regras adicionais sobre onde você pode colocar o separador
caracteres (`_`,`-` e `.`) dentro de uma tag de imagem.
Se você não especificar uma tag, o Kubernetes presumirá que você se refere à tag `latest` (mais recente).
{{< caution >}}
Você deve evitar usar a tag `latest` quando estiver realizando o deploy de contêineres em produção,
pois é mais difícil rastrear qual versão da imagem está sendo executada, além de tornar mais difícil o processo de reversão para uma versão funcional.
Em vez disso, especifique uma tag significativa, como `v1.42.0`.
{{< /caution >}}
## Atualizando imagens
A política padrão de pull é `IfNotPresent` a qual faz com que o
{{<glossary_tooltip text = "kubelet" term_id = "kubelet">}} ignore
o processo de *pull* da imagem, caso a mesma já exista. Se você prefere sempre forçar o processo de *pull*,
você pode seguir uma das opções abaixo:
- defina a `imagePullPolicy` do contêiner para` Always`.
- omita `imagePullPolicy` e use`: latest` como a tag para a imagem a ser usada.
- omita o `imagePullPolicy` e a tag da imagem a ser usada.
- habilite o [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) controlador de admissão.
Quando `imagePullPolicy` é definido sem um valor específico, ele também é definido como` Always`.
## Multiarquitetura de imagens com índice de imagens
Além de fornecer o binário das imagens, um registro de contêiner também pode servir um [índice de imagem do contêiner](https://github.com/opencontainers/image-spec/blob/master/image-index.md). Um índice de imagem pode apontar para múltiplos [manifestos da imagem](https://github.com/opencontainers/image-spec/blob/master/manifest.md) para versões específicas de arquitetura de um contêiner. A ideia é que você possa ter um nome para uma imagem (por exemplo: `pause`, `exemple/meuconteiner`, `kube-apiserver`) e permitir que diferentes sistemas busquem o binário da imagem correta para a arquitetura de máquina que estão usando.
O próprio Kubernetes normalmente nomeia as imagens de contêiner com o sufixo `-$(ARCH)`. Para retrocompatibilidade, gere as imagens mais antigas com sufixos. A ideia é gerar a imagem `pause` que tem o manifesto para todas as arquiteturas e `pause-amd64` que é retrocompatível com as configurações anteriores ou arquivos YAML que podem ter codificado as imagens com sufixos.
## Usando um registro privado
Os registros privados podem exigir chaves para acessar as imagens deles.
As credenciais podem ser fornecidas de várias maneiras:
- Configurando nós para autenticação em um registro privado
- todos os pods podem ler qualquer registro privado configurado
- requer configuração de nó pelo administrador do cluster
- Imagens pré-obtidas
- todos os pods podem usar qualquer imagem armazenada em cache em um nó
- requer acesso root a todos os nós para configurar
- Especificando ImagePullSecrets em um Pod
- apenas pods que fornecem chaves próprias podem acessar o registro privado
- Extensões locais ou específicas do fornecedor
- se estiver usando uma configuração de nó personalizado, você (ou seu provedor de nuvem) pode implementar seu mecanismo para autenticar o nó ao registro do contêiner.
Essas opções são explicadas com mais detalhes abaixo.
### Configurando nós para autenticação em um registro privado
Se você executar o Docker em seus nós, poderá configurar o contêiner runtime do Docker
para autenticação em um registro de contêiner privado.
Essa abordagem é adequada se você puder controlar a configuração do nó.
{{< note >}}
O Kubernetes padrão é compatível apenas com as seções `auths` e` HttpHeaders` na configuração do Docker.
Auxiliares de credencial do Docker (`credHelpers` ou` credsStore`) não são suportados.
{{< /note >}}
Docker armazena chaves de registros privados no arquivo `$HOME/.dockercfg` ou `$HOME/.docker/config.json`. Se você colocar o mesmo arquivo na lista de caminhos de pesquisa abaixo, o kubelet o usa como provedor de credenciais ao obter imagens.
* `{--root-dir:-/var/lib/kubelet}/config.json`
* `{cwd of kubelet}/config.json`
* `${HOME}/.docker/config.json`
* `/.docker/config.json`
* `{--root-dir:-/var/lib/kubelet}/.dockercfg`
* `{cwd of kubelet}/.dockercfg`
* `${HOME}/.dockercfg`
* `/.dockercfg`
{{< note >}}
Você talvez tenha que definir `HOME=/root` explicitamente no ambiente do processo kubelet.
{{< /note >}}
Aqui estão as etapas recomendadas para configurar seus nós para usar um registro privado. Neste
exemplo, execute-os em seu desktop/laptop:
1. Execute `docker login [servidor]` para cada conjunto de credenciais que deseja usar. Isso atualiza o `$HOME/.docker/config.json` em seu PC.
1. Visualize `$HOME/.docker/config.json` em um editor para garantir que contém apenas as credenciais que você deseja usar.
1. Obtenha uma lista de seus nós; por exemplo:
- se você quiser os nomes: `nodes=$( kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}' )`
- se você deseja obter os endereços IP: `nodes=$( kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}' )`
1. Copie seu `.docker/config.json` local para uma das listas de caminhos de busca acima.
- por exemplo, para testar isso: `for n in $nodes; do scp ~/.docker/config.json root@"$n":/var/lib/kubelet/config.json; done`
{{< note >}}
Para clusters de produção, use uma ferramenta de gerenciamento de configuração para que você possa aplicar esta
configuração em todos os nós que você precisar.
{{< /note >}}
Verifique se está funcionando criando um pod que usa uma imagem privada; por exemplo:
```shell
kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
name: private-image-test-1
spec:
containers:
- name: uses-private-image
image: $PRIVATE_IMAGE_NAME
imagePullPolicy: Always
command: [ "echo", "SUCCESS" ]
EOF
```
```
pod/private-image-test-1 created
```
Se tudo estiver funcionando, então, após algum tempo, você pode executar:
```shell
kubectl logs private-image-test-1
```
e veja o resultado do comando:
```
SUCCESS
```
Se você suspeitar que o comando falhou, você pode executar:
```shell
kubectl describe pods/private-image-test-1 | grep 'Failed'
```
Em caso de falha, a saída é semelhante a:
```
Fri, 26 Jun 2015 15:36:13 -0700 Fri, 26 Jun 2015 15:39:13 -0700 19 {kubelet node-i2hq} spec.containers{uses-private-image} failed Failed to pull image "user/privaterepo:v1": Error: image user/privaterepo:v1 not found
```
Você deve garantir que todos os nós no cluster tenham o mesmo `.docker/config.json`. Caso contrário, os pods serão executados com sucesso em alguns nós e falharão em outros. Por exemplo, se você usar o escalonamento automático de nós, cada modelo de instância precisa incluir o `.docker/config.json` ou montar um drive que o contenha.
Todos os pods terão premissão de leitura às imagens em qualquer registro privado, uma vez que
as chaves privadas do registro são adicionadas ao `.docker/config.json`.
### Imagens pré-obtidas
{{< note >}}
Essa abordagem é adequada se você puder controlar a configuração do nó. Isto
não funcionará de forma confiável se o seu provedor de nuvem for responsável pelo gerenciamento de nós e os substituir
automaticamente.
{{< /note >}}
Por padrão, o kubelet tenta realizar um "pull" para cada imagem do registro especificado.
No entanto, se a propriedade `imagePullPolicy` do contêiner for definida como` IfNotPresent` ou `Never`,
em seguida, uma imagem local é usada (preferencial ou exclusivamente, respectivamente).
Se você quiser usar imagens pré-obtidas como um substituto para a autenticação do registro,
você deve garantir que todos os nós no cluster tenham as mesmas imagens pré-obtidas.
Isso pode ser usado para pré-carregar certas imagens com o intuíto de aumentar a velocidade ou como uma alternativa para autenticação em um registro privado.
Todos os pods terão permissão de leitura a quaisquer imagens pré-obtidas.
### Especificando imagePullSecrets em um pod
{{< note >}}
Esta é a abordagem recomendada para executar contêineres com base em imagens
de registros privados.
{{< /note >}}
O Kubernetes oferece suporte à especificação de chaves de registro de imagem de contêiner em um pod.
#### Criando um segredo com Docker config
Execute o seguinte comando, substituindo as palavras em maiúsculas com os valores apropriados:
```shell
kubectl create secret docker-registry <name> --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL
```
Se você já tem um arquivo de credenciais do Docker, em vez de usar o
comando acima, você pode importar o arquivo de credenciais como um Kubernetes
{{< glossary_tooltip text="Secrets" term_id="secret" >}}.
[Criar um segredo com base nas credenciais Docker existentes](/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials) explica como configurar isso.
Isso é particularmente útil se você estiver usando vários registros privados de contêineres, como `kubectl create secret docker-registry` cria um Segredo que
só funciona com um único registro privado.
{{< note >}}
Os pods só podem fazer referência a *pull secrets* de imagem em seu próprio namespace,
portanto, esse processo precisa ser feito uma vez por namespace.
{{< /note >}}
#### Referenciando um imagePullSecrets em um pod
Agora, você pode criar pods que fazem referência a esse segredo adicionando uma seção `imagePullSecrets`
na definição de Pod.
Por exemplo:
```shell
cat <<EOF > pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: foo
namespace: awesomeapps
spec:
containers:
- name: foo
image: janedoe/awesomeapp:v1
imagePullSecrets:
- name: myregistrykey
EOF
cat <<EOF >> ./kustomization.yaml
resources:
- pod.yaml
EOF
```
Isso precisa ser feito para cada pod que está usando um registro privado.
No entanto, a configuração deste campo pode ser automatizada definindo o imagePullSecrets
em um recurso de [ServiceAccount](/docs/tasks/configure-pod-container/configure-service-account/).
Verifique [Adicionar ImagePullSecrets a uma conta de serviço](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) para obter instruções detalhadas.
Você pode usar isso em conjunto com um `.docker / config.json` por nó. As credenciais
serão mescladas.
## Casos de uso
Existem várias soluções para configurar registros privados. Aqui estão alguns
casos de uso comuns e soluções sugeridas.
1. Cluster executando apenas imagens não proprietárias (por exemplo, código aberto). Não há necessidade de ocultar imagens.
- Use imagens públicas no Docker hub.
- Nenhuma configuração necessária.
- Alguns provedores de nuvem armazenam em cache ou espelham automaticamente imagens públicas, o que melhora a disponibilidade e reduz o tempo para extrair imagens.
1. Cluster executando algumas imagens proprietárias que devem ser ocultadas para quem está fora da empresa, mas
visível para todos os usuários do cluster.
- Use um [registro Docker](https://docs.docker.com/registry/) privado hospedado.
- Pode ser hospedado no [Docker Hub](https://hub.docker.com/signup) ou em outro lugar.
- Configure manualmente .docker/config.json em cada nó conforme descrito acima.
- Ou execute um registro privado interno atrás de seu firewall com permissão de leitura.
- Nenhuma configuração do Kubernetes é necessária.
- Use um serviço de registro de imagem de contêiner que controla o acesso à imagem
- Funcionará melhor com o escalonamento automático do cluster do que com a configuração manual de nós.
- Ou, em um cluster onde alterar a configuração do nó é inconveniente, use `imagePullSecrets`.
1. Cluster com imagens proprietárias, algumas das quais requerem controle de acesso mais rígido.
- Certifique-se de que o [controlador de admissão AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) está ativo. Caso contrário, todos os pods têm potencialmente acesso a todas as imagens.
- Mova dados confidenciais para um recurso "secreto", em vez de empacotá-los em uma imagem.
1. Um cluster multilocatário em que cada locatário precisa de seu próprio registro privado.
- Certifique-se de que o [controlador de admissão AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) está ativo. Caso contrário, todos os Pods de todos os locatários terão potencialmente acesso a todas as imagens.
- Execute um registro privado com autorização necessária.
- Gere credenciais de registro para cada locatário, coloque em segredo e preencha o segredo para cada namespace de locatário.
- O locatário adiciona esse segredo a imagePullSecrets de cada namespace.
Se precisar de acesso a vários registros, você pode criar um segredo para cada registro.
O Kubelet mesclará qualquer `imagePullSecrets` em um único `.docker/config.json` virtual
## {{% heading "whatsnext" %}}
* Leia a [OCI Image Manifest Specification](https://github.com/opencontainers/image-spec/blob/master/manifest.md)
content/pt-br/docs/concepts/containers/runtime-class.md
+179
View File
@@ -0,0 +1,179 @@
---
title: Classes de execução
content_type: concept
weight: 20
---
<!-- overview -->
{{< feature-state for_k8s_version="v1.20" state="stable" >}}
Essa página descreve o recurso _RuntimeClass_ e a seleção do mecanismo do agente de execução.
RuntimeClass é uma funcionalidade para selecionar as configurações do agente de execução do contêiner.
A configuração do agente de execução de contêineres é usada para executar os contêineres de um Pod.
<!-- body -->
## Motivação
Você pode configurar um _RuntimeClass_ diferente entre os diferentes Pods para prover
um equilíbrio entre performance versus segurança. Por exemplo, se parte de sua carga de
trabalho necessita de um alto nível de garantia de segurança da informação, você pode
optar em executar esses Pods em um agente de execução que usa virtualização de hardware.
Você então terá o benefício do isolamento extra de um agente de execução alternativo, ao
custo de uma latência adicional.
Você pode ainda usar um _RuntimeClass_ para executar diferentes Pods com o mesmo agente
de execução de contêineres mas com diferentes configurações.
## Configuração
1. Configure a implementação do CRI nos nós (depende do agente de execução)
2. Crie o recurso RuntimeClass correspondente.
### 1. Configure a implementação do CRI nos nós
As configurações disponíveis através do RuntimeClass sáo dependentes da implementação do
_Container Runtime Interface_ ({{< glossary_tooltip term_id="cri" >}}). Veja a documentação correspondente [abaixo](#configuração-do-cri) para a
sua implementação CRI para verificar como configurar.
{{< note >}}
RuntimeClass assume uma configuração homogênea de nós entre todo o cluster por padrão
(o que significa que todos os nós estão configurados do mesmo jeito referente aos agentes de
execução). Para suportar configurações heterogêneas, veja [Associação](#associação) abaixo.
{{< /note >}}
As configurações possuem um nome `handler` correspondente, referenciado pelo RuntimeClass.
Esse nome deve ser um valor DNS 1123 válido (letras, números e o carácter `-`).
### 2. Crie o recurso RuntimeClass correspondente
As etapas de configuração no passo 1 devem todas estar associadas a um nome para o campo `handler`
que identifica a configuração. Para cada um, crie o objeto RuntimeClass correspondente.
O recurso RuntimeClass atualmente possui apenas 2 campos significativos: o nome do RuntimeClass
(`metadata.name`) e o agente (`handler`). A definição do objeto se parece conforme a seguir:
```yaml
apiVersion: node.k8s.io/v1 # RuntimeClass é definido no grupo de API node.k8s.io
kind: RuntimeClass
metadata:
name: myclass # O nome que o RuntimeClass será chamado como
# RuntimeClass é um recurso global, e não possui namespace.
handler: myconfiguration # Nome da configuração CRI correspondente
```
O nome de um objeto RuntimeClass deve ser um
[nome de subdomínio DNS](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) válido.
{{< note >}}
É recomendado que operações de escrita no objeto RuntimeClass (criar/atualizar/patch/apagar)
sejam restritas a administradores do cluster. Isso geralmente é o padrão. Veja [Visão Geral
de autorizações](/docs/reference/access-authn-authz/authorization/) para maiores detalhes.
{{< /note >}}
## Uso
Uma vez que as classes de execução estão configuradas no cluster, usar elas é relativamente
simples. Especifique um `runtimeClassName` na especificação do Pod. Por exemplo:
```yaml
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
runtimeClassName: myclass
# ...
```
Isso irá instruir o kubelet a usar o RuntimeClass nomeado acima (myclass) para esse Pod. Se
o nome do RuntimeClass não existir, ou o CRI não puder executar a solicitação, o Pod entrará na [fase
final](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) `Failed`. Procure por um
[evento](/docs/tasks/debug-application-cluster/debug-application-introspection/) correspondente
para uma mensagem de erro.
Se nenhum `runtimeClassName` for especificado, o RuntimeHandler padrão será utilizado, que é equivalente
ao comportamento quando a funcionalidade de RuntimeClass está desativada.
### Configuração do CRI
Para maiores detalhes de configuração dos agentes de execução CRI, veja [instalação do CRI](/docs/setup/production-environment/container-runtimes/).
#### dockershim
O CRI dockershim embutido no Kubernetes não suporta outros agentes de execução.
#### {{< glossary_tooltip term_id="containerd" >}}
Agentes de execução são configurados através da configuração do containerd em
`/etc/containerd/config.toml`. Agentes válidos são configurados sob a seção de `runtimes`:
```
[plugins.cri.containerd.runtimes.${HANDLER_NAME}]
```
Veja a documentação de configuração do containerd para maiores detalhes:
https://github.com/containerd/cri/blob/master/docs/config.md
#### {{< glossary_tooltip term_id="cri-o" >}}
Agentes de execução são configurados através da configuração do CRI-O em `/etc/crio/crio.conf`.
Agentes válidos são configurados na seção [crio.runtime
table](https://github.com/cri-o/cri-o/blob/master/docs/crio.conf.5.md#crioruntime-table):
```
[crio.runtime.runtimes.${HANDLER_NAME}]
runtime_path = "${PATH_TO_BINARY}"
```
Veja a [documentação de configuração](https://raw.githubusercontent.com/cri-o/cri-o/9f11d1d/docs/crio.conf.5.md) do CRI-O para maiores detalhes.
## Associação
{{< feature-state for_k8s_version="v1.16" state="beta" >}}
Ao especificar o campo `scheduling` para um RuntimeClass, você pode colocar limites e
garantir que os Pods executando dentro de uma RuntimeClass sejam associados a nós que
suportem eles. Se o `scheduling` não estiver configurado, assume-se que esse RuntimeClass
é suportado por todos os nós.
Para garantir que os Pods sejam executados em um nó que suporte um RuntimeClass específico,
aquele conjunto de nós deve possuir uma marca/label padrão que é selecionado pelo campo
`runtimeclass.scheduling.nodeSelector`. O nodeSelector do RuntimeClass é combinado com o
nodeSelector do Pod em tempo de admissão, obtendo a intersecção do conjunto de nós selecionado
por cada. Se existir um conflito, o pod será rejeitado.
Se os nós suportados possuírem marcação de restrição para prevenir outros Pods com uma
classe de execução diferente de executar no nó, você pode adicionar o campo `tolerations`
ao objeto RuntimeClass. Assim como com o `nodeSelector`, o `tolerations` é combinado com
o campo `tolerations` do Pod em tempo de admissão, efetivamente pegando a intersecção do
conjunto de nós aplicáveis para cada.
Para saber mais sobre a configuração de seleção de nós e tolerâncias, veja [Associando Pods a
Nós](/docs/concepts/scheduling-eviction/assign-pod-node/).
### Sobrecarga de Pods
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
Você pode especificar os recursos extra que estão associados à execução de um Pod. Declarar esses
recursos extra permite ao cluster (incluindo o agendador/scheduler de pods) contabilizar por
esses recursos quando estiver decidindo sobre Pods e recursos. Para usar a contabilização
desses recursos extras, você deve estar com o [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
PodOverhead habilitado (ele já está habilitado por padrão).
Os recursos extras utilizados são especificados no objeto RuntimeClass através do campo `overhead`.
Ao usar esses campos, você especifica o uso extra de recursos necessários para executar
Pods utilizando-se desse Runtimeclass e assim contabilizar esses recursos para o Kubernetes.
## {{% heading "whatsnext" %}}
- [RuntimeClass Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md)
- [RuntimeClass Scheduling Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md#runtimeclass-scheduling)
- Leia mais sobre [Sobrecarga de Pods](/docs/concepts/scheduling-eviction/pod-overhead/)
- [PodOverhead Feature Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md)