Add initial portuguese translation to runtime class (#27302)
* Add initial portuguese translation to runtime class * Apply suggestions from code review Co-authored-by: Diego W. Antunes <devlware@gmail.com> * Typo correct Co-authored-by: Diego W. Antunes <devlware@gmail.com>
This commit is contained in:
Ricardo Katz
GitHub
parent
fb976d5844
commit
8441afaac1
|
|
@ -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)
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
---
|
||||
title: containerd
|
||||
id: containerd
|
||||
date: 2019-05-14
|
||||
full_link: https://containerd.io/docs/
|
||||
short_description: >
|
||||
Um agente de execução de contêiner com enfase em simplicidade, robustez e portabilidade
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- tool
|
||||
---
|
||||
Um agente de execução de contêiner com enfase em simplicidade, robustez e portabilidade
|
||||
|
||||
<!--more-->
|
||||
|
||||
containerd é um agente de execução de {{< glossary_tooltip text="contêiner" term_id="container" >}}
|
||||
que executa um serviço no Linux ou Windows. containerd é responsável por buscar e
|
||||
armazenar as imagens de contêiner, executar contêineres, prover acesso à rede e mais.
|
||||
|
|
@ -0,0 +1,23 @@
|
|||
---
|
||||
title: CRI-O
|
||||
id: cri-o
|
||||
date: 2019-05-14
|
||||
full_link: https://cri-o.io/#what-is-cri-o
|
||||
short_description: >
|
||||
Um agente de execução leve de contêineres criado especificamente para o Kubernetes
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- tool
|
||||
---
|
||||
Uma ferramenta que permite você usar agentes de execução de contêineres OCI com o CRI do Kubernetes
|
||||
|
||||
<!--more-->
|
||||
|
||||
CRI-O é uma implementação do {{< glossary_tooltip term_id="cri" >}}
|
||||
que permite usar agentes de execução de {{< glossary_tooltip text="contêiner" term_id="container" >}}
|
||||
compatíveis com as [especificações](https://www.github.com/opencontainers/runtime-spec) da Open Container Initiative (OCI).
|
||||
|
||||
Usar o CRI-O permite ao Kubernetes utilizar-se de qualquer agente de execução compatível
|
||||
com o OCI para executar {{< glossary_tooltip text="Pods" term_id="pod" >}}, e obter imagens
|
||||
de contêineres de registros remotos.
|
||||
|
|
@ -0,0 +1,18 @@
|
|||
---
|
||||
title: Container runtime interface (CRI)
|
||||
id: cri
|
||||
date: 2019-03-07
|
||||
full_link: /docs/concepts/overview/components/#container-runtime
|
||||
short_description: >
|
||||
Uma API para agentes de execução de contêineres se integrarem com o kubelet
|
||||
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
---
|
||||
A interface de execução de contêiner (CRI) é uma API para agentes de execução de
|
||||
contêineres se integrarem com o kubelet em um nó.
|
||||
<!--more-->
|
||||
|
||||
Para maiores informações, veja as APIs e especificações do [CRI](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md).
|
||||
Loading…
Reference in New Issue