[pt-br] Update docs/concepts/overview/components.md
* Update the components page in Brazilian Portuguese to reflect the latest English version. * Update broken links. * Update glossary entries to use standardized terms and to link to the correct pages.pull/40349/head
Mauren Berti
parent
03c353e549
commit
e6c7804285
|
|
@ -1,10 +1,10 @@
|
|||
---
|
||||
reviewers:
|
||||
title: Componentes do Kubernetes
|
||||
content_type: concept
|
||||
description: >
|
||||
Um cluster Kubernetes consiste de componentes que representam a camada de gerenciamento, e um conjunto de máquinas chamadas nós.
|
||||
weight: 20
|
||||
Um cluster Kubernetes consiste de componentes que são parte da camada de
|
||||
gerenciamento e de um conjunto de máquinas chamadas nós.
|
||||
weight: 30
|
||||
card:
|
||||
name: concepts
|
||||
weight: 20
|
||||
|
|
@ -14,19 +14,26 @@ card:
|
|||
Ao implantar o Kubernetes, você obtém um cluster.
|
||||
{{< glossary_definition term_id="cluster" length="all" prepend="Um cluster Kubernetes consiste em">}}
|
||||
|
||||
Este documento descreve os vários componentes que você precisa ter para implantar um cluster Kubernetes completo e funcional.
|
||||
|
||||
Esse é o diagrama de um cluster Kubernetes com todos os componentes interligados.
|
||||
|
||||
|
||||
Este documento descreve os vários componentes que você precisa ter para implantar
|
||||
um cluster Kubernetes completo e funcional.
|
||||
|
||||
{{< figure src="/images/docs/components-of-kubernetes.svg" alt="Componentes do Kubernetes" caption="Os componentes de um cluster do Kubernetes" class="diagram-large" >}}
|
||||
|
||||
<!-- body -->
|
||||
## Componentes da camada de gerenciamento
|
||||
|
||||
Os componentes da camada de gerenciamento tomam decisões globais sobre o cluster (por exemplo, agendamento de _pods_), bem como detectam e respondem aos eventos do cluster (por exemplo, iniciando um novo _{{< glossary_tooltip text="pod" term_id="pod" >}}_ quando o campo `replicas` de um _Deployment_ não está atendido).
|
||||
Os componentes da camada de gerenciamento tomam decisões globais sobre o cluster
|
||||
(por exemplo, alocação de Pods), bem como detectam e respondem aos eventos
|
||||
do cluster (por exemplo, inicialização de um novo {{< glossary_tooltip text="Pod" term_id="pod" >}}
|
||||
quando o campo `replicas` de um Deployment não está atendido).
|
||||
|
||||
Os componentes da camada de gerenciamento podem ser executados em qualquer máquina do cluster. Contudo, para simplificar, os _scripts_ de configuração normalmente iniciam todos os componentes da camada de gerenciamento na mesma máquina, e não executa contêineres de usuário nesta máquina. Veja [Construindo clusters de alta disponibilidade](/docs/admin/high-availability/) para um exemplo de configuração de múltiplas VMs para camada de gerenciamento (_multi-main-VM_).
|
||||
Os componentes da camada de gerenciamento podem ser executados em qualquer máquina
|
||||
do cluster. Contudo, para simplificar, os scripts de configuração normalmente
|
||||
iniciam todos os componentes da camada de gerenciamento na mesma máquina, e
|
||||
contêineres com cargas de trabalho do usuário não rodam nesta máquina. Veja
|
||||
[Construindo clusters altamente disponíveis com o kubeadm](/docs/setup/production-environment/tools/kubeadm/high-availability/)
|
||||
para um exemplo de configuração da camada de gerenciamento que roda em múltiplas
|
||||
máquinas.
|
||||
|
||||
### kube-apiserver
|
||||
|
||||
|
|
@ -47,9 +54,9 @@ Os componentes da camada de gerenciamento podem ser executados em qualquer máqu
|
|||
Alguns tipos desses controladores são:
|
||||
|
||||
* Controlador de nó: responsável por perceber e responder quando os nós caem.
|
||||
* Controlador de _Job_: Observa os objetos _Job_ que representam tarefas únicas e, em seguida, cria _pods_ para executar essas tarefas até a conclusão.
|
||||
* Controlador de _endpoints_: preenche o objeto _Endpoints_ (ou seja, junta os Serviços e os _pods_).
|
||||
* Controladores de conta de serviço e de _token_: crie contas padrão e _tokens_ de acesso de API para novos _namespaces_.
|
||||
* Controlador de Jobs: observa os objetos Job, que representam tarefas únicas, e em seguida cria Pods para executar essas tarefas até a conclusão.
|
||||
* Controlador de EndpointSlice: preenche o objeto EndpointSlice (conecta os objetos Service e Pod).
|
||||
* Controlador de ServiceAccount: cria a ServiceAccount `default` para novos namespaces.
|
||||
|
||||
### cloud-controller-manager
|
||||
|
||||
|
|
@ -59,17 +66,21 @@ O cloud-controller-manager executa apenas controladores que são específicos pa
|
|||
Se você estiver executando o Kubernetes em suas próprias instalações ou em um ambiente de aprendizagem dentro de seu
|
||||
próprio PC, o cluster não possui um gerenciador de controlador de nuvem.
|
||||
|
||||
Tal como acontece com o kube-controller-manager, o cloud-controller-manager combina vários ciclos de controle logicamente independentes em um binário único que você executa como um processo único. Você pode escalar horizontalmente (executar mais de uma cópia) para melhorar o desempenho ou para auxiliar na tolerância a falhas.
|
||||
Tal como acontece com o kube-controller-manager, o cloud-controller-manager combina
|
||||
vários ciclos de controle logicamente independentes em um binário único que você
|
||||
executa como um processo único. Você pode escalonar horizontalmente (executar mais
|
||||
de uma cópia) para melhorar o desempenho ou para auxiliar na tolerância a falhas.
|
||||
|
||||
Os seguintes controladores podem ter dependências de provedor de nuvem:
|
||||
|
||||
* Controlador de nó: para verificar junto ao provedor de nuvem para determinar se um nó foi excluído da nuvem após parar de responder.
|
||||
* Controlador de rota: para configurar rotas na infraestrutura de nuvem subjacente.
|
||||
* Controlador de serviço: Para criar, atualizar e excluir balanceadores de carga do provedor de nuvem.
|
||||
* Controlador de serviço: para criar, atualizar e excluir balanceadores de carga do provedor de nuvem.
|
||||
|
||||
## Node Components
|
||||
## Componentes do nó {#node-components}
|
||||
|
||||
Os componentes de nó são executados em todos os nós, mantendo os _pods_ em execução e fornecendo o ambiente de execução do Kubernetes.
|
||||
Os componentes do nó são executados em todos os nós, mantendo os Pods em execução
|
||||
e fornecendo o ambiente de execução do Kubernetes.
|
||||
|
||||
### kubelet
|
||||
|
||||
|
|
@ -79,39 +90,53 @@ Os componentes de nó são executados em todos os nós, mantendo os _pods_ em ex
|
|||
|
||||
{{< glossary_definition term_id="kube-proxy" length="all" >}}
|
||||
|
||||
### Container runtime
|
||||
### Agente de execução de contêiner {#container-runtime}
|
||||
|
||||
{{< glossary_definition term_id="container-runtime" length="all" >}}
|
||||
|
||||
## Addons
|
||||
## Complementos (_addons_) {#addons}
|
||||
|
||||
Complementos (_addons_) usam recursos do Kubernetes ({{< glossary_tooltip term_id="daemonset" >}}, {{< glossary_tooltip term_id="deployment" >}}, etc) para implementar funcionalidades do cluster. Como fornecem funcionalidades em nível do cluster, recursos de _addons_ que necessitem ser criados dentro de um _namespace_ pertencem ao _namespace_ `kube-system`.
|
||||
Complementos (_addons_) usam recursos do Kubernetes ({{< glossary_tooltip term_id="daemonset" >}},
|
||||
{{< glossary_tooltip term_id="deployment" >}}, etc) para implementar funcionalidades
|
||||
do cluster. Como fornecem funcionalidades em nível do cluster, recursos de complementos
|
||||
que necessitem ser criados dentro de um namespace pertencem ao namespace `kube-system`.
|
||||
|
||||
Alguns _addons_ selecionados são descritos abaixo; para uma lista estendida dos _addons_ disponíveis, por favor consulte [Addons](/docs/concepts/cluster-administration/addons/).
|
||||
Alguns complementos selecionados são descritos abaixo; para uma lista estendida dos
|
||||
complementos disponíveis, consulte [Instalando Complementos](/pt-br/docs/concepts/cluster-administration/addons/).
|
||||
|
||||
### DNS
|
||||
|
||||
Embora os outros complementos não sejam estritamente necessários, todos os clusters do Kubernetes devem ter um [DNS do cluster](/docs/concepts/services-networking/dns-pod-service/), já que muitos exemplos dependem disso.
|
||||
Embora os outros complementos não sejam estritamente necessários, todos os clusters
|
||||
do Kubernetes devem ter um [DNS do cluster](/docs/concepts/services-networking/dns-pod-service/),
|
||||
já que muitos exemplos dependem disso.
|
||||
|
||||
O DNS do cluster é um servidor DNS, além de outros servidores DNS em seu ambiente, que fornece registros DNS para serviços do Kubernetes.
|
||||
O DNS do cluster é um servidor DNS, além de outros servidores DNS em seu ambiente,
|
||||
que fornece registros DNS para serviços do Kubernetes.
|
||||
|
||||
Os contêineres iniciados pelo Kubernetes incluem automaticamente esse servidor DNS em suas pesquisas DNS.
|
||||
|
||||
### Web UI (Dashboard)
|
||||
|
||||
[Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/) é uma interface de usuário Web, de uso geral, para clusters do Kubernetes. Ele permite que os usuários gerenciem e solucionem problemas de aplicações em execução no cluster, bem como o próprio cluster.
|
||||
O [dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/) é uma interface
|
||||
de usuário Web, de uso geral, para clusters do Kubernetes. Ele permite que os
|
||||
usuários gerenciem e solucionem problemas de aplicações em execução no cluster,
|
||||
bem como o próprio cluster.
|
||||
|
||||
### Monitoramento de recursos do contêiner
|
||||
|
||||
[Monitoramento de recursos do contêiner](/docs/tasks/debug-application-cluster/resource-usage-monitoring/) registra métricas de série temporal genéricas sobre os contêineres em um banco de dados central e fornece uma interface de usuário para navegar por esses dados.
|
||||
O [monitoramento de recursos do contêiner](/docs/tasks/debug/debug-cluster/resource-usage-monitoring/)
|
||||
registra métricas de série temporal genéricas sobre os contêineres em um banco de
|
||||
dados central e fornece uma interface de usuário para navegar por esses dados.
|
||||
|
||||
### Logging a nivel do cluster
|
||||
|
||||
Um mecanismo de [_logging_ a nível do cluster](/docs/concepts/cluster-administration/logging/) é responsável por guardar os _logs_ dos contêineres em um armazenamento central de _logs_ com um interface para navegação/pesquisa.
|
||||
Um mecanismo de [_logging_ a nível do cluster](/pt-br/docs/concepts/cluster-administration/logging/)
|
||||
é responsável por guardar os _logs_ dos contêineres em um armazenamento central de
|
||||
_logs_ com uma interface para navegação/pesquisa.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* Aprenda sobre [Nós](/docs/concepts/architecture/nodes/).
|
||||
* Aprenda sobre [Controladores](/docs/concepts/architecture/controller/).
|
||||
* Aprenda sobre [kube-scheduler](/docs/concepts/scheduling-eviction/kube-scheduler/).
|
||||
* Leia a [documentação](https://etcd.io/docs/) oficial do **etcd**.
|
||||
* Aprenda sobre [Nós](/pt-br/docs/concepts/architecture/nodes/).
|
||||
* Aprenda sobre [Controladores](/pt-br/docs/concepts/architecture/controller/).
|
||||
* Aprenda sobre [kube-scheduler](/pt-br/docs/concepts/scheduling-eviction/kube-scheduler/).
|
||||
* Leia a [documentação](https://etcd.io/docs/) oficial do etcd.
|
||||
|
|
|
|||
|
|
@ -4,15 +4,25 @@ id: cluster
|
|||
date: 2020-08-03
|
||||
full_link:
|
||||
short_description: >
|
||||
Um conjunto de servidores de processamento, também chamados de nós, que executam aplicações containerizadas. Todo cluster possui ao menos um servidor de processamento (worker node).
|
||||
|
||||
Um conjunto de servidores de processamento, também chamados de nós, que
|
||||
executam aplicações containerizadas. Todo cluster possui ao menos um servidor
|
||||
de processamento (worker node).
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
- operation
|
||||
---
|
||||
Um conjunto de servidores de processamento, chamados {{< glossary_tooltip text="nós" term_id="node" >}}, que executam aplicações containerizadas. Todo cluster possui ao menos um servidor de processamento (_worker node_).
|
||||
Um conjunto de servidores de processamento, chamados
|
||||
{{< glossary_tooltip text="nós" term_id="node" >}}, que executam aplicações
|
||||
containerizadas. Todo cluster possui ao menos um servidor de processamento
|
||||
(_worker node_).
|
||||
|
||||
<!--more-->
|
||||
O servidor de processamento hospeda os {{< glossary_tooltip text="Pods" term_id="pod" >}} que são componentes de uma aplicação. O {{< glossary_tooltip text="ambiente de gerenciamento" term_id="control-plane" >}} gerencia os nós de processamento e os Pods no cluster. Em ambientes de produção, o ambiente de gerenciamento geralmente executa em múltiplos computadores e um cluster geralmente executa em múltiplos nós (_nodes_) , provendo tolerância a falhas e alta disponibilidade.
|
||||
|
||||
O(s) servidor(es) de processamento hospeda(m) os
|
||||
{{< glossary_tooltip text="Pods" term_id="pod" >}}, que são componentes de uma
|
||||
aplicação. A {{< glossary_tooltip text="camada de gerenciamento" term_id="control-plane" >}}
|
||||
gerencia os nós de processamento e os Pods no cluster. Em ambientes de produção,
|
||||
a camada de gerenciamento geralmente executa em múltiplos computadores e um
|
||||
cluster geralmente executa múltiplos nós, fornecendo tolerância a falhas e alta
|
||||
disponibilidade.
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
title: Controlador
|
||||
id: controller
|
||||
date: 2020-03-23
|
||||
full_link: /docs/concepts/architecture/controller/
|
||||
full_link: /pt-br/docs/concepts/architecture/controller/
|
||||
short_description: >
|
||||
Um ciclo de controle que observa o estado partilhado do cluster através do API Server e efetua
|
||||
mudanças tentando mover o estado atual em direção ao estado desejado.
|
||||
|
|
|
|||
|
|
@ -4,16 +4,22 @@ id: etcd
|
|||
date: 2018-04-12
|
||||
full_link: /docs/tasks/administer-cluster/configure-upgrade-etcd/
|
||||
short_description: >
|
||||
Armazenamento do tipo Chave-Valor consistente e em alta-disponibilidade usado como repositório de apoio do Kubernetes para todos os dados do cluster.
|
||||
Armazenamento do tipo chave-valor consistente e de alta-disponibilidade, usado
|
||||
como armazenamento de apoio do Kubernetes para todos os dados do cluster.
|
||||
aka:
|
||||
tags:
|
||||
- architecture
|
||||
- storage
|
||||
---
|
||||
Armazenamento do tipo Chave-Valor consistente e em alta-disponibilidade usado como repositório de apoio do Kubernetes para todos os dados do cluster.
|
||||
Armazenamento do tipo chave-valor consistente e de alta-disponibilidade, usado
|
||||
como armazenamento de apoio do Kubernetes para todos os dados do cluster.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Se o seu cluster Kubernetes usa **etcd** como seu armazenamento de apoio, certifique-se de ter um plano de [back up](/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster) para seus dados.
|
||||
Se o seu cluster Kubernetes usa o etcd como seu armazenamento de apoio,
|
||||
certifique-se de ter um plano de
|
||||
[_backup_](/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster)
|
||||
para seus dados.
|
||||
|
||||
Você pode encontrar informações detalhadas sobre o etcd na seção oficial da [documentação](https://etcd.io/docs/).
|
||||
Você pode encontrar informações detalhadas sobre o etcd na [documentação](https://etcd.io/docs/)
|
||||
oficial.
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
---
|
||||
title: API server
|
||||
title: Servidor da API
|
||||
id: kube-apiserver
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/overview/components/#kube-apiserver
|
||||
full_link: /pt-br/docs/concepts/overview/components/#kube-apiserver
|
||||
short_description: >
|
||||
O componente da camada de gerenciamento que serve a API do Kubernetes.
|
||||
|
||||
|
|
@ -12,11 +12,15 @@ tags:
|
|||
- architecture
|
||||
- fundamental
|
||||
---
|
||||
O servidor de API é um componente da {{< glossary_tooltip text="Camada de gerenciamento" term_id="control-plane" >}} do Kubernetes que expõe a API do Kubernetes.
|
||||
O servidor de API é o _front end_ para a camada de gerenciamento do Kubernetes.
|
||||
O servidor da API é um componente da {{< glossary_tooltip text="camada de gerenciamento" term_id="control-plane" >}}
|
||||
do Kubernetes que expõe a API do Kubernetes.
|
||||
O servidor da API é o _front end_ para a camada de gerenciamento do Kubernetes.
|
||||
|
||||
<!--more-->
|
||||
|
||||
A principal implementação de um servidor de API do Kubernetes é [kube-apiserver](/docs/reference/generated/kube-apiserver/).
|
||||
O kube-apiserver foi projetado para ser escalonado horizontalmente — ou seja, ele pode ser escalado com a implantação de mais instâncias.
|
||||
Você pode executar várias instâncias do kube-apiserver e balancear (balanceamento de carga, etc) o tráfego entre essas instâncias.
|
||||
A principal implementação de um servidor de API do Kubernetes é o
|
||||
[kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/).
|
||||
O kube-apiserver foi projetado para ser escalonado horizontalmente — ou seja,
|
||||
ele pode ser escalonado com a criação de mais instâncias.
|
||||
Você pode executar várias instâncias do kube-apiserver e distribuir o tráfego
|
||||
entre essas instâncias.
|
||||
|
|
|
|||
|
|
@ -11,8 +11,11 @@ tags:
|
|||
- architecture
|
||||
- fundamental
|
||||
---
|
||||
Componente da camada de gerenciamento que executa os processos de {{< glossary_tooltip text="controlador" term_id="controller" >}}.
|
||||
Componente da camada de gerenciamento que executa os processos de
|
||||
{{< glossary_tooltip text="controlador" term_id="controller" >}}.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Logicamente, cada _{{< glossary_tooltip text="controlador" term_id="controller" >}}_ está em um processo separado, mas para reduzir a complexidade, eles todos são compilados num único binário e executam em um processo único.
|
||||
Logicamente, cada {{< glossary_tooltip text="controlador" term_id="controller" >}}
|
||||
está em um processo separado, mas para reduzir a complexidade, eles todos são
|
||||
compilados num único binário e executam em um processo único.
|
||||
|
|
|
|||
|
|
@ -4,14 +4,20 @@ id: kube-scheduler
|
|||
date: 2018-04-12
|
||||
full_link: /docs/reference/generated/kube-scheduler/
|
||||
short_description: >
|
||||
Componente da camada de gerenciamento que observa os _pods_ recém-criados sem nenhum nó atribuído, e seleciona um nó para executá-los.
|
||||
Componente da camada de gerenciamento que observa os Pods recém-criados e que
|
||||
ainda não foram atribuídos a um nó, e seleciona um nó para executá-los.
|
||||
aka:
|
||||
tags:
|
||||
- architecture
|
||||
---
|
||||
Componente da camada de gerenciamento que observa os _{{< glossary_tooltip term_id="pod" text="pods" >}}_ recém-criados sem nenhum {{< glossary_tooltip term_id="node" text="nó">}} atribuído, e seleciona um nó para executá-los.
|
||||
Componente da camada de gerenciamento que observa os
|
||||
{{< glossary_tooltip term_id="pod" text="Pods" >}} recém-criados e que ainda não
|
||||
foram atribuídos a um {{< glossary_tooltip term_id="node" text="nó">}}, e
|
||||
seleciona um nó para executá-los.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Os fatores levados em consideração para as decisões de agendamento incluem:
|
||||
requisitos de recursos individuais e coletivos, hardware/software/política de restrições, especificações de afinidade e antiafinidade, localidade de dados, interferência entre cargas de trabalho, e prazos.
|
||||
Os fatores levados em consideração para as decisões de alocação incluem:
|
||||
requisitos de recursos individuais e coletivos, restrições de hardware/software/política,
|
||||
especificações de afinidade e antiafinidade, localidade de dados, interferência
|
||||
entre cargas de trabalho, e prazos.
|
||||
|
|
|
|||
|
|
@ -4,15 +4,20 @@ id: kubelet
|
|||
date: 2020-04-19
|
||||
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.
|
||||
Um agente que é executado em cada nó no cluster. Ele garante que os contêineres
|
||||
estejam sendo executados em um Pod.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
- core-object
|
||||
---
|
||||
Um agente que é executado em cada {{< glossary_tooltip text="node" term_id="node" >}} no cluster. Ele garante que os {{< glossary_tooltip text="contêineres" term_id="container" >}} estejam sendo executados em um {{< glossary_tooltip text="Pod" term_id="pod" >}}.
|
||||
Um agente que é executado em cada {{< glossary_tooltip text="nó" term_id="node" >}}
|
||||
no cluster. Ele garante que os {{< glossary_tooltip text="contêineres" term_id="container" >}}
|
||||
estejam sendo executados em um {{< glossary_tooltip text="Pod" term_id="pod" >}}.
|
||||
|
||||
<!--more-->
|
||||
|
||||
O kubelet utiliza um conjunto de PodSpecs que são fornecidos por vários mecanismos e garante que os contêineres descritos nesses PodSpecs estejam funcionando corretamente. O kubelet não gerencia contêineres que não foram criados pelo Kubernetes.
|
||||
O kubelet utiliza um conjunto de PodSpecs que são fornecidos por vários mecanismos
|
||||
e garante que os contêineres descritos nesses PodSpecs estejam funcionando corretamente.
|
||||
O kubelet não gerencia contêineres que não foram criados pelo Kubernetes.
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
title: Nó
|
||||
id: node
|
||||
date: 2020-04-19
|
||||
full_link: /docs/concepts/architecture/nodes/
|
||||
full_link: /pt-br/docs/concepts/architecture/nodes/
|
||||
short_description: >
|
||||
Um Nó é uma máquina de trabalho no Kubernetes.
|
||||
|
||||
|
|
@ -14,4 +14,11 @@ tags:
|
|||
|
||||
<!--more-->
|
||||
|
||||
Um Nó pode ser uma máquina virtual ou física, dependendo do cluster. Possui daemons ou serviços locais necessários para executar {{< glossary_tooltip text="Pods" term_id="pod" >}} e é gerenciado pelo {{< glossary_tooltip text="ambiente de gerenciamento" term_id="control-plane" >}}. Os daemons em um Node incluem {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}, {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}} e um contêiner runtime implementando o {{< glossary_tooltip text="CRI" term_id="cri" >}} como por exemplo o {{< glossary_tooltip term_id="docker" >}}.
|
||||
Um Nó pode ser uma máquina virtual ou física, dependendo do cluster. Possui
|
||||
daemons ou serviços locais necessários para executar
|
||||
{{< glossary_tooltip text="Pods" term_id="pod" >}} e é gerenciado pela
|
||||
{{< glossary_tooltip text="camada de gerenciamento" term_id="control-plane" >}}.
|
||||
Os daemons em um nó incluem o {{< glossary_tooltip text="kubelet" term_id="kubelet" >}},
|
||||
o {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}} e um agente de
|
||||
execução de contêiner que implemente o {{< glossary_tooltip text="CRI" term_id="cri" >}},
|
||||
como por exemplo o {{< glossary_tooltip term_id="docker" >}}.
|
||||
|
|
|
|||
Loading…
Reference in New Issue