Translate ConfigMap page to Brazilian Portuguese.
This commit is contained in:
Mauren Berti
parent
cd0b3b5695
commit
cb9c4853ac
|
|
@ -0,0 +1,280 @@
|
|||
---
|
||||
title: ConfigMaps
|
||||
content_type: concept
|
||||
weight: 20
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
{{< glossary_definition term_id="configmap" prepend="Um ConfigMap é" length="all" >}}
|
||||
|
||||
{{< caution >}}
|
||||
O ConfigMap não oferece confidencialidade ou encriptação.
|
||||
Se os dados que você deseja armazenar são confidenciais, utilize
|
||||
{{< glossary_tooltip term_id="secret" >}} ao invés de um ConfigMap,
|
||||
ou utilize ferramentas adicionais (de terceiros) para manter seus dados privados.
|
||||
{{< /caution >}}
|
||||
|
||||
|
||||
<!-- body -->
|
||||
## Motivação
|
||||
|
||||
Utilize um ConfigMap para manter a configuração separada do código da aplicação.
|
||||
|
||||
Por exemplo, imagine que você esteja desenvolvendo uma aplicação que pode ser executada
|
||||
no seu computador local (para desenvolvimento) e na nuvem (para manipular tráfego real).
|
||||
Você escreve código para ler a variável de ambiente chamada `DATABASE_HOST`.
|
||||
No seu ambiente local, você configura essa variável com o valor `localhost`. Na nuvem, você
|
||||
configura essa variável para referenciar um {{< glossary_tooltip text="serviço" term_id="service" >}}
|
||||
do Kubernetes que expõe o componente do banco de dados ao seu cluster.
|
||||
Isto permite que você baixe uma imagem de contêiner que roda na nuvem e depure o exato
|
||||
mesmo código localmente se necessário.
|
||||
|
||||
Um ConfigMap não foi planejado para conter grandes quantidades de dados. Os dados armazenados
|
||||
em um ConfigMap não podem exceder 1 MiB. Se você precisa armazenar configurações que são maiores
|
||||
que este limite, considere montar um volume ou utilizar um serviço separado de banco de dados
|
||||
ou de arquivamento de dados.
|
||||
|
||||
## Objeto ConfigMap
|
||||
|
||||
Um ConfigMap é um [objeto](/docs/concepts/overview/working-with-objects/kubernetes-objects/)
|
||||
da API que permite o armazenamento de configurações para consumo por outros objetos. Diferentemente
|
||||
de outros objetos do Kubernetes que contém um campo `spec`, o ConfigMap contém os campos `data` e
|
||||
`binaryData`. Estes campos aceitam pares chave-valor como valores. Ambos os campos `data` e `binaryData`
|
||||
são opcionais. O campo `data` foi pensado para conter sequências de bytes UTF-8, enquanto o campo `binaryData`
|
||||
foi planejado para conter dados binários em forma de strings codificadas em base64.
|
||||
|
||||
É obrigatório que o nome de um ConfigMap seja um
|
||||
[subdomínio DNS válido](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
|
||||
|
||||
Cada chave sob as seções `data` ou `binaryData` pode conter quaisquer caracteres alfanuméricos,
|
||||
`-`, `_` e `.`. As chaves armazenadas na seção `data` não podem colidir com as chaves armazenadas
|
||||
na seção `binaryData`.
|
||||
|
||||
A partir da versão v1.19 do Kubernetes, é possível adicionar o campo `immutable` a uma definição de ConfigMap
|
||||
para criar um [ConfigMap imutável](#configmap-immutable).
|
||||
|
||||
## ConfigMaps e Pods
|
||||
|
||||
Você pode escrever uma `spec` para um Pod que se refere a um ConfigMap e configurar o(s) contêiner(es)
|
||||
neste Pod baseados em dados do ConfigMap. O Pod e o ConfigMap devem estar no mesmo
|
||||
{{< glossary_tooltip text="namespace" term_id="namespace" >}}.
|
||||
|
||||
{{< note >}}
|
||||
A `spec` de um {{< glossary_tooltip text="Pod estático" term_id="static-pod" >}} não pode se referir a um
|
||||
ConfigMap ou a quaisquer outros objetos da API.
|
||||
{{< /note >}}
|
||||
|
||||
Exemplo de um ConfigMap que contém algumas chaves com valores avulsos e outras chaves com valores semelhantes
|
||||
a fragmentos de arquivos de configuração:
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
name: game-demo
|
||||
data:
|
||||
# chaves com valores de propriedades; cada chave mapeia para um valor avulso
|
||||
player_initial_lives: "3"
|
||||
ui_properties_file_name: "user-interface.properties"
|
||||
|
||||
# chaves semelhantes a fragmentos de arquivos
|
||||
game.properties: |
|
||||
enemy.types=aliens,monsters
|
||||
player.maximum-lives=5
|
||||
user-interface.properties: |
|
||||
color.good=purple
|
||||
color.bad=yellow
|
||||
allow.textmode=true
|
||||
```
|
||||
|
||||
Existem quatro formas diferentes para consumo de um ConfigMap na configuração de um
|
||||
contêiner dentro de um Pod:
|
||||
|
||||
1. Dentro de um comando de contêiner e seus argumentos.
|
||||
1. Variáveis de ambiente para um contêiner.
|
||||
1. Criando um arquivo em um volume somente leitura, para consumo pela aplicação.
|
||||
1. Escrevendo código para execução dentro do Pod que utilize a API do Kubernetes para ler um ConfigMap.
|
||||
|
||||
Os diferentes métodos de consumo oferecem diferentes formas de modelar os dados sendo consumidos.
|
||||
Para os três primeiros métodos, o {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} utiliza
|
||||
os dados de um ConfigMap quando o(s) contêiner(es) do Pod são inicializados.
|
||||
|
||||
O quarto método envolve escrita de código para leitura do ConfigMap e dos seus dados. No entanto,
|
||||
como a API do Kubernetes está sendo utilizada diretamente, a aplicação pode solicitar atualizações
|
||||
sempre que o ConfigMap for alterado e reagir quando isso ocorre. Acessar a API do Kubernetes
|
||||
diretamente também permite ler ConfigMaps em outros namespaces.
|
||||
|
||||
Exemplo de um Pod que utiliza valores do ConfigMap `game-demo` para configurar um Pod:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: configmap-demo-pod
|
||||
spec:
|
||||
containers:
|
||||
- name: demo
|
||||
image: alpine
|
||||
command: ["sleep", "3600"]
|
||||
env:
|
||||
# Define as variáveis de ambiente
|
||||
- name: PLAYER_INITIAL_LIVES # Note que aqui a variável está definida em caixa alta,
|
||||
# diferente da chave no ConfigMap.
|
||||
valueFrom:
|
||||
configMapKeyRef:
|
||||
name: game-demo # O ConfigMap de onde esse valor vem.
|
||||
key: player_initial_lives # A chave que deve ser buscada.
|
||||
- name: UI_PROPERTIES_FILE_NAME
|
||||
valueFrom:
|
||||
configMapKeyRef:
|
||||
name: game-demo
|
||||
key: ui_properties_file_name
|
||||
volumeMounts:
|
||||
- name: config
|
||||
mountPath: "/config"
|
||||
readOnly: true
|
||||
volumes:
|
||||
# Volumes são definidos no escopo do Pod, e os pontos de montagem são definidos
|
||||
# nos contêineres dentro dos pods.
|
||||
- name: config
|
||||
configMap:
|
||||
# Informe o nome do ConfigMap que deseja montar.
|
||||
name: game-demo
|
||||
# Uma lista de chaves do ConfigMap para serem criadas como arquivos.
|
||||
items:
|
||||
- key: "game.properties"
|
||||
path: "game.properties"
|
||||
- key: "user-interface.properties"
|
||||
path: "user-interface.properties"
|
||||
```
|
||||
|
||||
ConfigMaps não diferenciam entre propriedades com valores simples ou valores complexos,
|
||||
que ocupam várias linhas. O importante é a forma que Pods e outros objetos consumem tais valores.
|
||||
|
||||
Para este exemplo, definir um volume e montar ele dentro do container `demo` no caminho `/config`
|
||||
cria dois arquivos: `/config/game.properties` e `/config/user-interface.properties`, embora existam
|
||||
quatro chaves distintas no ConfigMap. Isso se deve ao fato de que a definição do Pod contém uma lista
|
||||
`items` na seção `volumes`.
|
||||
Se a lista `items` for omitida, cada chave do ConfigMap torna-se um arquivo cujo nome é a sua chave
|
||||
correspondente, e quatro arquivos serão criados.
|
||||
|
||||
## Usando ConfigMaps
|
||||
|
||||
ConfigMaps podem ser montados como volumes de dados. ConfigMaps também podem ser utilizados
|
||||
por outras partes do sistema sem serem diretamente expostos ao Pod. Por exemplo, ConfigMaps
|
||||
podem conter dados que outras partes do sistema devem usar para configuração.
|
||||
|
||||
A forma mais comum de utilização de ConfigMaps é a configuração de contêineres executando em
|
||||
Pods no mesmo namespace. Você também pode utilizar um ConfigMap separadamente.
|
||||
|
||||
Por exemplo, existem {{< glossary_tooltip text="complementos" term_id="addons" >}} ou
|
||||
{{< glossary_tooltip text="operadores" term_id="operator-pattern" >}} que adaptam seus comportamentos
|
||||
de acordo com dados de um ConfigMap.
|
||||
|
||||
### Utilizando ConfigMaps como arquivos em um Pod
|
||||
|
||||
Para consumir um ConfigMap em um volume em um Pod:
|
||||
1. Crie um ConfigMap ou utilize um ConfigMap existente. Múltiplos Pods
|
||||
podem referenciar o mesmo ConfigMap.
|
||||
1. Modifique sua definição de Pod para adicionar um volume em
|
||||
`.spec.volumes[]`. Escolha um nome qualquer para o seu volume, e
|
||||
referencie o seu objeto ConfigMap no campo
|
||||
`.spec.volumes[].configMap.name`.
|
||||
1. Adicione um campo `.spec.containers[].volumeMounts[]` a cada um dos
|
||||
contêineres que precisam do ConfigMap. Especifique
|
||||
`.spec.containers[].volumeMounts[].readOnly = true` e informe no campo
|
||||
`.spec.containers[].volumeMounts[].mountPath` um caminho de um diretório
|
||||
não utilizado onde você deseja que este ConfigMap apareça.
|
||||
1. Modifique sua imagem ou linha de comando de modo que o programa procure
|
||||
por arquivos no diretório especificado no passo anterior. Cada chave no
|
||||
campo `data` do ConfigMap será transformado em um nome de arquivo no
|
||||
diretório especificado por `mountPath`.
|
||||
|
||||
Exemplo de um Pod que monta um ConfigMap em um volume:
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: mypod
|
||||
spec:
|
||||
containers:
|
||||
- name: mypod
|
||||
image: redis
|
||||
volumeMounts:
|
||||
- name: foo
|
||||
mountPath: "/etc/foo"
|
||||
readOnly: true
|
||||
volumes:
|
||||
- name: foo
|
||||
configMap:
|
||||
name: myconfigmap
|
||||
```
|
||||
|
||||
Cada ConfigMap que você deseja utilizar precisa ser referenciado em
|
||||
`.spec.volumes`.
|
||||
|
||||
Se houver múltiplos contêineres no Pod, cada contêiner deve ter seu
|
||||
próprio bloco `volumeMounts`, mas somente uma instância de `.spec.volumes`
|
||||
é necessária por ConfigMap.
|
||||
|
||||
### ConfigMaps montados são atualizados automaticamente
|
||||
|
||||
Quando um ConfigMap que está sendo consumido em um volume é atualizado, as chaves projetadas são
|
||||
eventualmente atualizadas também. O Kubelet checa se o ConfigMap montado está atualizado em cada
|
||||
sincronização periódica.
|
||||
No entanto, o kubelet utiliza o cache local para buscar o valor atual do ConfigMap.
|
||||
O tipo de cache é configurável utilizando o campo `ConfigMapAndSecretChangeDetectionStrategy` na
|
||||
[configuração do Kubelet (KubeletConfiguration)](/docs/reference/config-api/kubelet-config.v1beta1/).
|
||||
Um ConfigMap pode ter sua propagação baseada em um _watch_ (comportamento padrão), que é o sistema
|
||||
de propagação de mudanças incrementais em objetos do Kubernetes; baseado em TTL (_time to live_,
|
||||
ou tempo de expiração); ou redirecionando todas as requisições diretamente para o servidor da API.
|
||||
Como resultado, o tempo decorrido total entre o momento em que o ConfigMap foi atualizado até o momento
|
||||
quando as novas chaves são projetadas nos Pods pode ser tão longo quanto o tempo de sincronização
|
||||
do kubelet somado ao tempo de propagação do cache, onde o tempo de propagação do cache depende do
|
||||
tipo de cache escolhido: o tempo de propagação pode ser igual ao tempo de propagação do _watch_,
|
||||
TTL do cache, ou zero, de acordo com cada um dos tipos de cache.
|
||||
|
||||
ConfigMaps que são consumidos como variáveis de ambiente não atualizam automaticamente e requerem uma
|
||||
reinicialização do pod.
|
||||
|
||||
## ConfigMaps imutáveis {#configmap-immutable}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.21" state="stable">}}
|
||||
|
||||
A funcionalidade _Secrets e ConfigMaps imutáveis_ do Kubernetes fornece uma opção
|
||||
para marcar Secrets e ConfigMaps individuais como imutáveis. Para clusters que utilizam
|
||||
ConfigMaps extensivamente (ao menos centenas de milhares de mapeamentos únicos de
|
||||
ConfigMaps para Pods), prevenir alterações dos seus dados traz as seguintes vantagens:
|
||||
|
||||
- protege de atualizações acidentais ou indesejadas que podem causar disrupção na execução
|
||||
de aplicações
|
||||
- melhora o desempenho do cluster através do fechamento de _watches_ de ConfigMaps marcados
|
||||
como imutáveis, diminuindo significativamente a carga no kube-apiserver
|
||||
|
||||
Essa funcionalidade é controlada pelo [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
`ImmutableEphemeralVolumes`. É possível criar um ConfigMap imutável adicionando o campo
|
||||
`immutable` e marcando seu valor com `true`.
|
||||
Por exemplo:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
...
|
||||
data:
|
||||
...
|
||||
immutable: true
|
||||
```
|
||||
|
||||
Após um ConfigMap ser marcado como imutável, _não_ é possível reverter a alteração, nem
|
||||
alterar o conteúdo dos campos `data` ou `binaryData`. É possível apenas apagar e recriar
|
||||
o ConfigMap. Como Pods existentes que consomem o ConfigMap em questão mantém um ponto de
|
||||
montagem que continuará referenciando este objeto após a remoção, é recomendado recriar
|
||||
estes pods.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* Leia sobre [Secrets](/docs/concepts/configuration/secret/) (em inglês).
|
||||
* Leia [Configure a Pod to Use a ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) (em inglês).
|
||||
* Leia [The Twelve-Factor App](https://12factor.net/) (em inglês) para entender a motivação da separação de código
|
||||
e configuração.
|
||||
|
|
@ -0,0 +1,17 @@
|
|||
---
|
||||
title: Complementos
|
||||
id: addons
|
||||
date: 2019-12-15
|
||||
full_link: /pt-br/docs/concepts/cluster-administration/addons/
|
||||
short_description: >
|
||||
Recursos que estendem a funcionalidade do Kubernetes.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- tool
|
||||
---
|
||||
Recursos que estendem a funcionalidade do Kubernetes.
|
||||
|
||||
<!--more-->
|
||||
[Instalando Complementos](/pt-br/docs/concepts/cluster-administration/addons/) explica mais sobre a utilização de complementos em seu cluster e lista
|
||||
alguns complementos populares.
|
||||
|
|
@ -0,0 +1,18 @@
|
|||
---
|
||||
title: ConfigMap
|
||||
id: configmap
|
||||
date: 2021-08-24
|
||||
full_link: /docs/concepts/configuration/configmap
|
||||
short_description: >
|
||||
Um objeto da API usado para armazenar dados não-confidenciais em pares chave-valor. Pode ser consumido como variáveis de ambiente, argumentos de linha de comando, ou arquivos de configuração em um volume.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- core-object
|
||||
---
|
||||
Um objeto da API usado para armazenar dados não-confidenciais em pares chave-valor.
|
||||
{{< glossary_tooltip text="Pods" term_id="pod" >}} podem consumir ConfigMaps como variáveis de ambiente, argumentos de linha de comando ou como arquivos de configuração em um {{< glossary_tooltip text="volume" term_id="volume" >}}.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Um ConfigMap ajuda a desacoplar configurações vinculadas ao ambiente das {{< glossary_tooltip text="imagens de contêiner" term_id="image" >}}, de modo a tornar aplicações mais facilmente portáveis.
|
||||
|
|
@ -0,0 +1,17 @@
|
|||
---
|
||||
title: Image
|
||||
id: image
|
||||
date: 2021-08-24
|
||||
full_link:
|
||||
short_description: >
|
||||
Instância armazenada de um contêiner que contém o conjunto de softwares necessários para rodar uma aplicação.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
---
|
||||
Instância armazenada de um {{< glossary_tooltip text="contêiner" term_id="container" >}} que contém o conjunto de softwares necessários para rodar uma aplicação.
|
||||
|
||||
<!--more-->
|
||||
|
||||
É uma forma de empacotamento de software que permite que este seja armazenado em um _container registry_, copiado para um sistema local e executado como uma aplicação. Metadados são incluídos na imagem para indicar qual programa deve ser executado, quem produziu a imagem, além de outras informações.
|
||||
|
|
@ -0,0 +1,11 @@
|
|||
---
|
||||
title: Glossário
|
||||
layout: glossary
|
||||
noedit: true
|
||||
default_active_tag: fundamental
|
||||
weight: 5
|
||||
card:
|
||||
name: reference
|
||||
weight: 10
|
||||
title: Glossário
|
||||
---
|
||||
|
|
@ -2,7 +2,7 @@
|
|||
title: Kubelet
|
||||
id: kubelet
|
||||
date: 2020-04-19
|
||||
full_link: /docs/reference/generated/kubelet
|
||||
full_link: /docs/reference/command-line-tools-reference/kubelet
|
||||
short_description: >
|
||||
Um agente que é executado em cada node no cluster. Ele garante que os contêineres estejam sendo executados em um pod.
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,18 @@
|
|||
---
|
||||
title: Namespace
|
||||
id: namespace
|
||||
date: 2021-09-17
|
||||
full_link: /docs/concepts/overview/working-with-objects/namespaces
|
||||
short_description: >
|
||||
Uma abstração utilizada pelo Kubernetes para suportar múltiplos clusters virtuais no mesmo cluster físico.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
---
|
||||
Uma abstração utilizada pelo Kubernetes para suportar múltiplos clusters virtuais no mesmo {{< glossary_tooltip text="cluster" term_id="cluster" >}} físico.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Namespaces são utilizados para organizar objetos em um cluster e oferecer uma forma de separar os recursos do cluster. Os nomes dos recursos precisam ser únicos dentro de um namespace,
|
||||
mas não entre todos os namespaces existentes.
|
||||
|
|
@ -0,0 +1,24 @@
|
|||
---
|
||||
title: Padrão Operador
|
||||
id: operator-pattern
|
||||
date: 2021-09-17
|
||||
full_link: /pt-br/docs/concepts/extend-kubernetes/operator/
|
||||
short_description: >
|
||||
Um controlador especializado que gerencia um recurso personalizado.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- architecture
|
||||
---
|
||||
O [padrão Operador](/docs/concepts/extend-kubernetes/operator/) é um design de
|
||||
sistema que vincula um {{< glossary_tooltip text="controlador" term_id="controller" >}}
|
||||
a um ou mais recursos personalizados.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Você pode estender a funcionalidade do Kubernetes adicionando controladores ao seu cluster,
|
||||
além dos controladores que são distribuídos como parte do Kubernetes.
|
||||
|
||||
Se uma aplicação em execução age como um controlador e tem acesso à API para desempenhar
|
||||
tarefas em um recurso personalizado que está definido na camada de gerenciamento, este é
|
||||
um exemplo do padrão Operador.
|
||||
|
|
@ -2,7 +2,7 @@
|
|||
title: Pod
|
||||
id: pod
|
||||
date: 2020-04-19
|
||||
full_link: /docs/concepts/workloads/pods/pod-overview/
|
||||
full_link: /docs/concepts/workloads/pods/
|
||||
short_description: >
|
||||
O menor e mais simples objeto Kubernetes. Um Pod representa um conjunto de contêineres em execução no seu cluster.
|
||||
aka:
|
||||
|
|
|
|||
|
|
@ -0,0 +1,18 @@
|
|||
---
|
||||
title: Secret
|
||||
id: secret
|
||||
date: 2021-08-24
|
||||
full_link: /docs/concepts/configuration/secret/
|
||||
short_description: >
|
||||
Armazena dados sensíveis, como senhas, tokens OAuth e chaves SSH.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- core-object
|
||||
- security
|
||||
---
|
||||
Armazena dados sensíveis, como senhas, tokens OAuth e chaves SSH.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Permite mais controle com relação a como as informações sensíveis são armazenadas e reduz o risco de exposição acidental, incluindo [encriptação](/docs/tasks/administer-cluster/encrypt-data/#ensure-all-secrets-are-encrypted) em disco. Um {{< glossary_tooltip text="Pod" term_id="pod" >}} pode referenciar o Secret como um arquivo em um volume montado, ou o kubelet pode usar este dado quando baixa imagens para um pod. Secrets são úteis para dados confidenciais, enquanto [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/) são úteis para dados não-confidenciais.
|
||||
|
|
@ -0,0 +1,17 @@
|
|||
---
|
||||
title: Selector
|
||||
id: selector
|
||||
date: 2021-09-17
|
||||
full_link: /docs/concepts/overview/working-with-objects/labels/
|
||||
short_description: >
|
||||
Permite ao usuário filtrar uma lista de recursos com base em rótulos (labels).
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
---
|
||||
Permite ao usuário filtrar uma lista de recursos com base em {{< glossary_tooltip text="labels" term_id="label" >}} (rótulos).
|
||||
|
||||
<!--more-->
|
||||
|
||||
Selectors são aplicados quando um usuário faz uma pesquisa por listas de recursos para filtrá-los por labels (rótulos).
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
---
|
||||
title: Service
|
||||
id: service
|
||||
date: 2021-09-17
|
||||
full_link: /docs/concepts/services-networking/service/
|
||||
short_description: >
|
||||
Uma forma abstrata de expor uma aplicação que está executando em um conjunto de Pods como um serviço de rede.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
- core-object
|
||||
---
|
||||
Uma forma abstrata de expor uma aplicação que está executando em um conjunto de {{< glossary_tooltip text="Pods" term_id="pod" >}} como um serviço de rede.
|
||||
|
||||
<!--more-->
|
||||
|
||||
O conjunto de Pods referenciado por um Service é (geralmente) determinado por um {{< glossary_tooltip text="selector" term_id="selector" >}}. Se mais Pods são
|
||||
adicionados ou removidos, o conjunto de Pods que atende ao critério do selector será alterado. O Service garante que o tráfego de rede pode ser direcionado ao
|
||||
conjunto atual de Pods para a carga de trabalho.
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
---
|
||||
title: Pod estático
|
||||
id: static-pod
|
||||
date: 2021-09-17
|
||||
full_link: /docs/tasks/configure-pod-container/static-pod/
|
||||
short_description: >
|
||||
Um pod gerenciado diretamente pelo daemon do kubelet em um nó específico.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
---
|
||||
|
||||
Um {{< glossary_tooltip text="pod" term_id="pod" >}} gerenciado diretamente pelo
|
||||
daemon do kubelet em um nó específico,
|
||||
|
||||
<!--more-->
|
||||
|
||||
que não é observado pelo servidor de API.
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
---
|
||||
title: Volume
|
||||
id: volume
|
||||
date: 2021-08-24
|
||||
full_link: /docs/concepts/storage/volumes/
|
||||
short_description: >
|
||||
Um diretório contendo dados, accessível aos contêineres em um pod.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- core-object
|
||||
- fundamental
|
||||
---
|
||||
Um diretório contendo dados, accessível aos {{< glossary_tooltip text="contêineres" term_id="container" >}} em um {{< glossary_tooltip term_id="pod" >}}.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Um volume do Kubernetes existe enquanto o Pod que utiliza ele existir também. Consequentemente, um volume dura mais tempo que qualquer contêiner que rodar em um Pod, e os dados no volume são preservados entre reinicializações do contêiner.
|
||||
|
||||
Veja [armazenamento](/docs/concepts/storage/) para mais detalhes.
|
||||
Loading…
Reference in New Issue