Kubernetes - Kubernetesio

Prévia do material em texto

Documentação
1: Kubernetes
1.1: Versões Suportadas da Documentação do Kubernetes
2: Instalação
3: Conceitos
3.1: Visão Geral
3.1.1: O que é Kubernetes?
3.1.2: Componentes do Kubernetes
3.1.3: Objetos do Kubernetes
3.1.3.1: Nomes
3.2: Volumes Persistentes
3.3: Arquitetura do Kubernetes
3.3.1: Comunicação entre Nó e Control Plane
3.3.2: Conceitos sobre Cloud Controller Manager
3.3.3: Controladores
3.4: Contêineres
3.4.1: Imagens
3.4.2: Ambiente de Contêiner
3.4.3: Classes de execução
3.4.4: Hooks de Ciclo de Vida do Contêiner
3.5: Serviços, balanceamento de carga e conectividade
3.5.1: Políticas de rede
3.6: Con�guração
3.6.1: Melhores Práticas de Con�guração
3.6.2: Con�gMaps
3.6.3: Organizando o acesso ao cluster usando arquivos kubecon�g
3.7: Segurança
3.7.1: Visão Geral da Segurança Cloud Native
3.8: Escalonamento
3.8.1: Escalonador do Kubernetes
3.8.2: Sobrecarga de Pod
3.9: Administração de Cluster
3.9.1: Visão Geral da Administração de Cluster
3.9.2: Certi�cates
3.9.3: Conectividade do Cluster
3.9.4: Arquitetura de Log
3.9.5: Logs de Sistema
3.9.6: Con�gurando o Garbage Collection do kubelet
3.9.7: Instalando Complementos
3.10: Extendendo o Kubernetes
3.10.1: Extendendo a API do Kubernetes
3.10.1.1: Extendendo a API do Kubernetes com a camada de agregação
3.10.2: Extensões de Computação, armazenamento e redes
3.10.2.1: Plugins de rede
3.10.3: Padrão Operador
4: Tarefas
4.1: Gerenciando Secrets
4.1.1: Gerenciando Secret usando kubectl
4.1.2: Gerenciando Secret usando Arquivo de Con�guração
4.1.3: Gerenciando Secret usando Kustomize
5: Tutoriais
5.1: Olá, Minikube!
5.2: Aprenda as noções básicas do Kubernetes
5.2.1: Crie um Cluster
5.2.1.1: Usando Minikube para criar um cluster
5.2.1.2: Tutorial interativo - Criando um cluster
5.2.2: Implantar um aplicativo
5.2.2.1: Usando kubectl para criar uma implantação
5.2.2.2: Tutorial interativo - implantando um aplicativo
5.2.3: Explore seu aplicativo
5.2.3.1: Visualizando Pods e Nós (Nodes)
5.2.3.2: Tutorial Interativo - Explorando seu aplicativo
5.2.4: Exponha publicamente seu aplicativo
5.2.4.1: Utilizando um serviço para expor seu aplicativo
5.2.4.2: Tutorial Interativo - Expondo seu aplicativo
5.2.5: Escale seu aplicativo
5.2.5.1: Executando múltiplas instâncias de seu aplicativo
5.2.5.2: Tutorial Interativo - Escalando seu aplicativo
6: Referência
6.1: Glossário
6.2: Autenticação
6.3: Autenticando com Tokens de Inicialização
6.4: kubectl CLI
6.4.1: kubectl Cheat Sheet
6.5: Ferramentas
7: Contribua com a documentação do Kubernetes
7.1: Visualizando Analytics do Site
8:
9: Resultados da pesquisa
à documentação do Kubernetes em Português
pode ver, a maior parte da documentação ainda está disponível apenas em inglês, mas não se
á uma equipe trabalhando na tradução para o português.
er participar, você pode entrar no canal Slack #kubernetes-docs-pt (http://slack.kubernetes.io/) e fazer
uipe por trás da tradução.
m pode acessar o canal para solicitar a tradução de uma página especí�ca ou relatar qualquer erro que
do encontrado. Qualquer contribuição será bem recebida!
formações sobre como contribuir, dê uma olhada github.com/kubernetes/website
ub.com/kubernetes/website/).
http://slack.kubernetes.io/
https://github.com/kubernetes/website/
1 - Kubernetes
1.1 - Versões Suportadas da Documentação
do Kubernetes
Este site contém documentação para a versão atual do Kubernetes e as quatro versões anteriores do
Kubernetes.
Versão Atual
A versão atual é v1.22 (/).
Versões anteriores
v1.21 (https://v1-21.docs.kubernetes.io)
v1.20 (https://v1-20.docs.kubernetes.io)
v1.19 (https://v1-19.docs.kubernetes.io)
v1.18 (https://v1-18.docs.kubernetes.io)
https://kubernetes.io/
https://v1-21.docs.kubernetes.io/
https://v1-20.docs.kubernetes.io/
https://v1-19.docs.kubernetes.io/
https://v1-18.docs.kubernetes.io/
2 - Instalação
Essa seção lista as diferentes formas de instalar e executar o Kubernetes. Quando você realiza a
instalação de um cluster Kubernetes, deve decidir o tipo de instalação baseado em critérios como
facilidade de manutenção, segurança, controle, quantidade de recursos disponíveis e a experiência
necessária para gerenciar e operar o cluster.
Você pode criar um cluster Kubernetes em uma máquina local, na nuvem, em um datacenter on-
premises ou ainda escolher uma oferta de um cluster Kubernetes gerenciado pelo seu provedor de
computação em nuvem.
Existem ainda diversos outros tipos de soluções customizadas, que você pode se deparar ao buscar
formas de instalação e gerenciamento de seu cluster.
Ambientes de aprendizado
Se você está aprendendo ou pretende aprender mais sobre o Kubernetes, use ferramentas suportadas
pela comunidade, ou ferramentas no ecossistema que te permitam criar um cluster Kubernetes em sua
máquina virtual.
Temos como exemplo aqui o Minikube (/docs/tasks/tools/install-minikube/) e o KinD
(https://kind.sigs.k8s.io/docs/user/quick-start/)
Ambientes de produção
Ao analisar uma solução para um ambiente de produção, devem ser considerados quais aspectos de
operação de um cluster Kubernetes você deseja gerenciar, ou então delegar ao seu provedor.
Temos diversas opções para esse provisionamento, desde o uso de uma ferramenta de deployment de
um cluster tal qual o Kubeadm (/docs/setup/production-environment/tools/kubeadm/install-kubeadm/)
ou o Kubespray (/docs/setup/production-environment/tools/kubespray/) quando se trata de um cluster
local, ou ainda o uso de um cluster gerenciado por seu provedor de nuvem.
Para a escolha do melhor ambiente e da melhor forma para fazer essa instalação, você deve considerar:
Se você deseja se preocupar com a gestão de backup da sua estrutura do ambiente de
gerenciamento
Se você deseja ter um cluster mais atualizado, com novas funcionalidades, ou se deseja seguir a
versão suportada pelo fornecedor
Se você deseja ter um cluster com um alto nível de serviço, ou com auto provisionamento de alta
disponibilidade
Quanto você deseja pagar por essa produção
https://kubernetes.io/docs/tasks/tools/install-minikube/
https://kind.sigs.k8s.io/docs/user/quick-start/
https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/
https://kubernetes.io/docs/setup/production-environment/tools/kubespray/
3 - Conceitos
A seção de Conceitos irá te ajudar a aprender mais sobre as partes do ecossistema Kubernetes e as
abstrações que o Kubernetes usa para representar seu 
cluster (/pt-br/docs/reference/glossary/?all=true#term-cluster).
Ela irá lhe ajudar a obter um entendimento mais profundo sobre como o Kubernetes funciona.
3.1 - Visão Geral
Obtenha uma visão em alto-nível do Kubernetes e dos componentes a partir dos
quais ele é construído.
3.1.1 - O que é Kubernetes?
Kubernetes é um plataforma de código aberto, portável e extensiva para o
gerenciamento de cargas de trabalho e serviços distribuídos em contêineres, que
facilita tanto a con�guração declarativa quanto a automação. Ele possui um
ecossistema grande, e de rápido crescimento. Serviços, suporte, e ferramentas
para Kubernetes estão amplamente disponíveis.
Essa página é uma visão geral do Kubernetes.
Kubernetes é um plataforma de código aberto, portável e extensiva para o gerenciamento de cargas de
trabalho e serviços distribuídos em contêineres, que facilita tanto a con�guração declarativa quanto a
automação. Ele possui um ecossistema grande, e de rápido crescimento. Serviços, suporte, e
ferramentas para Kubernetes estão amplamente disponíveis.
O Google tornou Kubernetes um projeto de código-aberto em 2014. O Kubernetes combina mais de 15
anos de experiência do Google (/blog/2015/04/borg-predecessor-to-kubernetes/) executando cargas de
trabalho produtivas em escala, com as melhores idéias e práticas da comunidade.
O nome Kubernetes tem origem no Grego, signi�cando timoneiro ou piloto. K8s é a abreviação derivada
pela troca das oito letras "ubernete" por "8", se tornado K"8"s.
Voltando no tempo
Vamos daruma olhada no porque o Kubernetes é tão útil, voltando no tempo.
Era da implantação tradicional: No início, as organizações executavam aplicações em servidores
físicos. Não havia como de�nir limites de recursos para aplicações em um mesmo servidor físico, e isso
causava problemas de alocação de recursos. Por exemplo, se várias aplicações fossem executadas em
um mesmo servidor físico, poderia haver situações em que uma aplicação ocupasse a maior parte dos
recursos e, como resultado, o desempenho das outras aplicações seria inferior. Uma solução para isso
seria executar cada aplicação em um servidor físico diferente. Mas isso não escalava, pois os recursos
eram subutilizados, e se tornava custoso para as organizações manter muitos servidores físicos.
Era da implantação virtualizada: Como solução, a virtualização foi introduzida. Esse modelo permite
que você execute várias máquinas virtuais (VMs) em uma única CPU de um servidor físico. A
virtualização permite que as aplicações sejam isoladas entre as VMs, e ainda fornece um nível de
segurança, pois as informações de uma aplicação não podem ser acessadas livremente por outras
aplicações.
https://kubernetes.io/pt-br/docs/reference/glossary/?all=true#term-cluster
https://kubernetes.io/blog/2015/04/borg-predecessor-to-kubernetes/
A virtualização permite melhor utilização de recursos em um servidor físico, e permite melhor
escalabilidade porque uma aplicação pode ser adicionada ou atualizada facilmente, reduz os custos de
hardware e muito mais. Com a virtualização, você pode apresentar um conjunto de recursos físicos
como um cluster de máquinas virtuais descartáveis.
Cada VM é uma máquina completa que executa todos os componentes, incluindo seu próprio sistema
operacional, além do hardware virtualizado.
Era da implantação em contêineres: Contêineres são semelhantes às VMs, mas têm propriedades de
isolamento �exibilizados para compartilhar o sistema operacional (SO) entre as aplicações. Portanto, os
contêineres são considerados leves. Semelhante a uma VM, um contêiner tem seu próprio sistema de
arquivos, compartilhamento de CPU, memória, espaço de processo e muito mais. Como eles estão
separados da infraestrutura subjacente, eles são portáveis entre nuvens e distribuições de sistema
operacional.
Contêineres se tornaram populares porque eles fornecem benefícios extra, tais como:
Criação e implantação ágil de aplicações: aumento da facilidade e e�ciência na criação de imagem
de contêiner comparado ao uso de imagem de VM.
Desenvolvimento, integração e implantação contínuos: fornece capacidade de criação e de
implantação de imagens de contêiner de forma con�ável e frequente, com a funcionalidade de
efetuar reversões rápidas e e�cientes (devido à imutabilidade da imagem).
Separação de interesses entre Desenvolvimento e Operações: crie imagens de contêineres de
aplicações no momento de construção/liberação em vez de no momento de implantação,
desacoplando as aplicações da infraestrutura.
A capacidade de observação (Observabilidade) não apenas apresenta informações e métricas no
nível do sistema operacional, mas também a integridade da aplicação e outros sinais.
Consistência ambiental entre desenvolvimento, teste e produção: funciona da mesma forma em
um laptop e na nuvem.
Portabilidade de distribuição de nuvem e sistema operacional: executa no Ubuntu, RHEL, CoreOS,
localmente, nas principais nuvens públicas e em qualquer outro lugar.
Gerenciamento centrado em aplicações: eleva o nível de abstração da execução em um sistema
operacional em hardware virtualizado à execução de uma aplicação em um sistema operacional
usando recursos lógicos.
Microserviços fracamente acoplados, distribuídos, elásticos e livres: as aplicações são divididas em
partes menores e independentes e podem ser implantados e gerenciados dinamicamente - não
uma pilha monolítica em execução em uma grande máquina de propósito único.
Isolamento de recursos: desempenho previsível de aplicações.
Utilização de recursos: alta e�ciência e densidade.
Por que você precisa do Kubernetes e o que ele pode
fazer
Os contêineres são uma boa maneira de agrupar e executar suas aplicações. Em um ambiente de
produção, você precisa gerenciar os contêineres que executam as aplicações e garantir que não haja
tempo de inatividade. Por exemplo, se um contêiner cair, outro contêiner precisa ser iniciado. Não seria
mais fácil se esse comportamento fosse controlado por um sistema?
É assim que o Kubernetes vem ao resgate! O Kubernetes oferece uma estrutura para executar sistemas
distribuídos de forma resiliente. Ele cuida do escalonamento e do recuperação à falha de sua aplicação,
fornece padrões de implantação e muito mais. Por exemplo, o Kubernetes pode gerenciar facilmente
uma implantação no método canário para seu sistema.
O Kubernetes oferece a você:
Descoberta de serviço e balanceamento de carga O Kubernetes pode expor um contêiner
usando o nome DNS ou seu próprio endereço IP. Se o tráfego para um contêiner for alto, o
Kubernetes pode balancear a carga e distribuir o tráfego de rede para que a implantação seja
estável.
Orquestração de armazenamento O Kubernetes permite que você monte automaticamente um
sistema de armazenamento de sua escolha, como armazenamentos locais, provedores de nuvem
pública e muito mais.
Lançamentos e reversões automatizadas Você pode descrever o estado desejado para seus
contêineres implantados usando o Kubernetes, e ele pode alterar o estado real para o estado
desejado em um ritmo controlada. Por exemplo, você pode automatizar o Kubernetes para criar
novos contêineres para sua implantação, remover os contêineres existentes e adotar todos os
seus recursos para o novo contêiner.
Empacotamento binário automático Você fornece ao Kubernetes um cluster de nós que pode
ser usado para executar tarefas nos contêineres. Você informa ao Kubernetes de quanta CPU e
memória (RAM) cada contêiner precisa. O Kubernetes pode encaixar contêineres em seus nós para
fazer o melhor uso de seus recursos.
Autocorreção O Kubernetes reinicia os contêineres que falham, substitui os contêineres, elimina
os contêineres que não respondem à veri�cação de integridade de�nida pelo usuário e não os
anuncia aos clientes até que estejam prontos para servir.
Gerenciamento de con�guração e de segredos O Kubernetes permite armazenar e gerenciar
informações con�denciais, como senhas, tokens OAuth e chaves SSH. Você pode implantar e
atualizar segredos e con�guração de aplicações sem reconstruir suas imagens de contêiner e sem
expor segredos em sua pilha de con�guração.
O que o Kubernetes não é
O Kubernetes não é um sistema PaaS (plataforma como serviço) tradicional e completo. Como o
Kubernetes opera no nível do contêiner, e não no nível do hardware, ele fornece alguns recursos
geralmente aplicáveis comuns às ofertas de PaaS, como implantação, escalonamento, balanceamento
de carga, e permite que os usuários integrem suas soluções de logging, monitoramento e alerta. No
entanto, o Kubernetes não é monolítico, e essas soluções padrão são opcionais e conectáveis. O
Kubernetes fornece os blocos de construção para a construção de plataformas de desenvolvimento,
mas preserva a escolha e �exibilidade do usuário onde é importante.
Kubernetes:
Não limita os tipos de aplicações suportadas. O Kubernetes visa oferecer suporte a uma variedade
extremamente diversa de cargas de trabalho, incluindo cargas de trabalho sem estado, com
estado e de processamento de dados. Se uma aplicação puder ser executada em um contêiner, ele
deve ser executado perfeitamente no Kubernetes.
Não implanta código-fonte e não constrói sua aplicação. Os �uxos de trabalho de integração
contínua, entrega e implantação (CI/CD) são determinados pelas culturas e preferências da
organização, bem como pelos requisitos técnicos.
Não fornece serviços em nível de aplicação, tais como middleware (por exemplo, barramentos de
mensagem), estruturas de processamento de dados (por exemplo,Spark), bancos de dados (por
exemplo, MySQL), caches, nem sistemas de armazenamento em cluster (por exemplo, Ceph), como
serviços integrados. Esses componentes podem ser executados no Kubernetes e/ou podem ser
acessados por aplicações executadas no Kubernetes por meio de mecanismos portáteis, como o
Open Service Broker (https://openservicebrokerapi.org/).
Não dita soluções de logging, monitoramento ou alerta. Ele fornece algumas integrações como
prova de conceito e mecanismos para coletar e exportar métricas.
Não fornece nem exige um sistema/idioma de con�guração (por exemplo, Jsonnet). Ele fornece
uma API declarativa que pode ser direcionada por formas arbitrárias de especi�cações
declarativas.
Não fornece nem adota sistemas abrangentes de con�guração de máquinas, manutenção,
gerenciamento ou autocorreção.
Adicionalmente, o Kubernetes não é um mero sistema de orquestração. Na verdade, ele elimina a
necessidade de orquestração. A de�nição técnica de orquestração é a execução de um �uxo de
trabalho de�nido: primeiro faça A, depois B e depois C. Em contraste, o Kubernetes compreende
um conjunto de processos de controle independentes e combináveis que conduzem
continuamente o estado atual em direção ao estado desejado fornecido. Não importa como você
vai de A para C. O controle centralizado também não é necessário. Isso resulta em um sistema que
é mais fácil de usar e mais poderoso, robusto, resiliente e extensível.
Qual é o próximo
Dê uma olhada em Componentes do Kubernetes (/pt-br/docs/concepts/overview/components/).
Pronto para Iniciar (/docs/setup/)?
https://openservicebrokerapi.org/
https://kubernetes.io/pt-br/docs/concepts/overview/components/
https://kubernetes.io/docs/setup/
3.1.2 - Componentes do Kubernetes
Um cluster Kubernetes consiste de componentes que representam a camada de
gerenciamento, e um conjunto de máquinas chamadas nós.
Ao implantar o Kubernetes, você obtém um cluster.
Um cluster Kubernetes consiste em um conjunto de servidores de processamento, chamados 
nós (/docs/concepts/architecture/nodes/), que executam aplicações containerizadas. Todo cluster
possui ao menos um servidor de processamento (worker node).
O servidor de processamento hospeda os Pods (/docs/concepts/workloads/pods/) que são
componentes de uma aplicação. O 
ambiente de gerenciamento (/pt-br/docs/reference/glossary/?all=true#term-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.
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.
k-proxy
kubelet
sched
schedsched
Control Plane
Node
etcd
Kubernetes cluster
api
api
api
c-c-m
c-c-m
c-c-m
c-m
c-m
c-m
Node Node
k-proxy
kubelet kubelet
k-proxy
Control plane
Scheduler
sched
Cloud controller
manager
(optional) c-c-m
Controller
manager c-m
kubelet
kubelet
kube-proxy
k-proxy
(persistence store)
etcd
etcd
Node
API server
api
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 pod (/docs/concepts/workloads/pods/) 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 simpli�car, os scripts de con�guraçã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 con�guração de múltiplas VMs para camada de gerenciamento (multi-main-VM).
kube-apiserver
O servidor de API é um componente da 
Camada de gerenciamento (/pt-br/docs/reference/glossary/?all=true#term-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.
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.
etcd
https://kubernetes.io/docs/concepts/architecture/nodes/
https://kubernetes.io/docs/concepts/workloads/pods/
https://kubernetes.io/pt-br/docs/reference/glossary/?all=true#term-control-plane
https://kubernetes.io/docs/concepts/workloads/pods/
https://kubernetes.io/docs/admin/high-availability/
https://kubernetes.io/pt-br/docs/reference/glossary/?all=true#term-control-plane
https://kubernetes.io/docs/reference/generated/kube-apiserver/
Armazenamento do tipo Chave-Valor consistente e em alta-disponibilidade usado como repositório de
apoio do Kubernetes para todos os dados do cluster.
Se o seu cluster Kubernetes usa etcd como seu armazenamento de apoio, certi�que-se de ter um plano
de back up (/docs/tasks/administer-cluster/con�gure-upgrade-etcd/#backing-up-an-etcd-cluster) para
seus dados.
Você pode encontrar informações detalhadas sobre o etcd na seção o�cial da documentação
(https://etcd.io/docs/).
kube-scheduler
Componente da camada de gerenciamento que observa os pods (/docs/concepts/workloads/pods/) recém-
criados sem nenhum nó (/docs/concepts/architecture/nodes/) atribuído, e seleciona um nó para
executá-los.
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, especi�cações de a�nidade e
antia�nidade, localidade de dados, interferência entre cargas de trabalho, e prazos.
kube-controller-manager
Componente da camada de gerenciamento que executa os processos de 
controlador (/docs/concepts/architecture/controller/).
Logicamente, cada controlador (/docs/concepts/architecture/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.
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.
cloud-controller-manager
Um componente da 
camada de gerenciamento (/pt-br/docs/reference/glossary/?all=true#term-control-plane) do Kubernetes
que incorpora a lógica de controle especí�ca da nuvem. O gerenciador de controle de nuvem permite
que você vincule seu cluster na API do seu provedor de nuvem, e separar os componentes que
interagem com essa plataforma de nuvem a partir de componentes que apenas interagem com seu
cluster.
O cloud-controller-manager executa apenas controladores que são especí�cos para seu provedor de
nuvem. 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 (exectuar mais de uma cópia) para melhorar o desempenho ou para
auxiliar na tolerânciaa falhas.
Os seguintes controladores podem ter dependências de provedor de nuvem:
Controlador de nó: para veri�car junto ao provedor de nuvem para determinar se um nó foi
excluído da nuvem após parar de responder.
Controlador de rota: para con�gurar rotas na infraestrutura de nuvem subjacente.
Controlador de serviço: Para criar, atualizar e excluir balanceadores de carga do provedor de
nuvem.
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.
https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster
https://etcd.io/docs/
https://kubernetes.io/docs/concepts/workloads/pods/
https://kubernetes.io/docs/concepts/architecture/nodes/
https://kubernetes.io/docs/concepts/architecture/controller/
https://kubernetes.io/docs/concepts/architecture/controller/
https://kubernetes.io/pt-br/docs/reference/glossary/?all=true#term-control-plane
kubelet
Um agente que é executado em cada node (/docs/concepts/architecture/nodes/) no cluster. Ele garante
que os contêineres (/docs/concepts/containers/) estejam sendo executados em um 
Pod (/docs/concepts/workloads/pods/).
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.
kube-proxy
kube-proxy é um proxy de rede executado em cada nó (/docs/concepts/architecture/nodes/) no seu
cluster, implementando parte do conceito de serviço (/docs/concepts/services-networking/service/) do
Kubernetes.
kube-proxy (/docs/reference/command-line-tools-reference/kube-proxy/) mantém regras de rede nos
nós. Estas regras de rede permitem a comunicação de rede com seus pods a partir de sessões de rede
dentro ou fora de seu cluster.
kube-proxy usa a camada de �ltragem de pacotes do sistema operacional se houver uma e estiver
disponível. Caso contrário, o kube-proxy encaminha o tráfego ele mesmo.
Container runtime
O agente de execução (runtime) de contêiner é o software responsável por executar os contêineres.
O Kubernetes suporta diversos agentes de execução de contêineres: 
Docker (https://docs.docker.com/engine/), containerd (https://containerd.io/docs/), 
CRI-O (https://cri-o.io/#what-is-cri-o), e qualquer implementação do Kubernetes CRI (Container Runtime
Interface) (https://github.com/kubernetes/community/blob/master/contributors/devel/sig-
node/container-runtime-interface.md).
Addons
Complementos (addons) usam recursos do Kubernetes (
DaemonSet (/docs/concepts/workloads/controllers/daemonset), 
Deployment (/docs/concepts/workloads/controllers/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 .
Alguns addons selecionados são descritos abaixo; para uma lista estendida dos addons disponíveis, por
favor consulte Addons (/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.
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.
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.
https://kubernetes.io/docs/concepts/architecture/nodes/
https://kubernetes.io/docs/concepts/containers/
https://kubernetes.io/docs/concepts/workloads/pods/
https://kubernetes.io/docs/concepts/architecture/nodes/
https://kubernetes.io/docs/concepts/services-networking/service/
https://kubernetes.io/docs/reference/command-line-tools-reference/kube-proxy/
https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md
https://docs.docker.com/engine/
https://containerd.io/docs/
https://cri-o.io/#what-is-cri-o
https://kubernetes.io/docs/concepts/workloads/controllers/daemonset
https://kubernetes.io/docs/concepts/workloads/controllers/deployment/
https://kubernetes.io/docs/concepts/cluster-administration/addons/
https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/
https://kubernetes.io/docs/tasks/access-application-cluster/web-ui-dashboard/
https://kubernetes.io/docs/tasks/debug-application-cluster/resource-usage-monitoring/
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.
Qual é o próximo
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/) o�cial do etcd.
https://kubernetes.io/docs/concepts/cluster-administration/logging/
https://kubernetes.io/docs/concepts/architecture/nodes/
https://kubernetes.io/docs/concepts/architecture/controller/
https://kubernetes.io/docs/concepts/scheduling-eviction/kube-scheduler/
https://etcd.io/docs/
3.1.3 - Objetos do Kubernetes
3.1.3.1 - Nomes
Cada objeto em um cluster possui um Nome que é único para aquele tipo de recurso. Todo objeto do
Kubernetes também possui um UID que é único para todo o cluster.
Por exemplo, você pode ter apenas um Pod chamado "myapp-1234", porém você pode ter um Pod e um
Deployment ambos com o nome "myapp-1234".
Para atributos não únicos providenciados por usuário, Kubernetes providencia labels
(/docs/concepts/overview/working-with-objects/labels/) e annotations
(/docs/concepts/overview/working-with-objects/annotations/).
Nomes
Recursos Kubernetes podem ter nomes com até 253 caracteres. Os caracteres permitidos em nomes
são: dígitos (0-9), letras minúsculas (a-z), - , e . .
A seguir, um exemplo para um Pod chamado nginx-demo .
Nota: Alguns tipos de recursos possuem restrições adicionais em seus nomes.
UIDs
Kubernetes UIDs são identi�cadores únicos universais (também chamados de UUIDs). UUIDs utilizam
padrões ISO/IEC 9834-8 e ITU-T X.667.
Qual é o próximo
Leia sobre labels (/docs/concepts/overview/working-with-objects/labels/) em Kubernetes.
Consulte o documento de design Identi�cadores e Nomes em Kubernetes
(https://git.k8s.io/community/contributors/design-proposals/architecture/identi�ers.md).
apiVersion: v1 
kind: Pod 
metadata: 
 name: nginx-demo 
spec:
 containers: 
 - name: nginx 
 image: nginx:1.7.9 
 ports:
 - containerPort: 80 
https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/
https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/
https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/
https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md
3.2 - Volumes Persistentes
Esse documento descreve o estado atual dos volumes persistentes no Kubernetes. Sugerimos que esteja
familiarizado com volumes (/docs/concepts/storage/volumes/).
Introdução
O gerenciamento de armazenamentoé uma questão bem diferente do gerenciamento de instâncias
computacionais. O subsistema PersistentVolume provê uma API para usuários e administradores que
mostra de forma detalhada de como o armazenamento é provido e como ele é consumido. Para isso,
nós introduzimos duas novas APIs: PersistentVolume e PersistentVolumeClaim.
Um PersistentVolume (PV) é uma parte do armazenamento dentro do cluster que tenha sido
provisionada por um administrador, ou dinamicamente utilizando Classes de Armazenamento
(/docs/concepts/storage/storage-classes/). Isso é um recurso dentro do cluster da mesma forma que um
nó também é. PVs são plugins de volume da mesma forma que Volumes, porém eles têm um ciclo de
vida independente de qualquer Pod que utilize um PV. Essa API tem por objetivo mostrar os detalhes da
implementação do armazenamento, seja ele NFS, iSCSI, ou um armazenamento especí�co de um
provedor de cloud pública.
Uma_PersistentVolumeClaim_ (PVC) é uma requisição para armazenamento por um usuário. É similar a
um Pod. Pods utilizam recursos do nó e PVCs utilizam recursos do PV. Pods podem solicitar níveis
especí�cos de recursos (CPU e Memória). Claims podem solicitar tamanho e modos de acesso
especí�cos (exemplo: montagem como ReadWriteOnce, ReadOnlyMany ou ReadWriteMany, veja Modos
de Acesso).
Enquanto as PersistentVolumeClaims permitem que um usuário utilize recursos de armazenamento de
forma limitada, é comum que usuários precisem de PersistentVolumes com diversas propriedades,
como desempenho, para problemas diversos. Os administradores de cluster precisam estar aptos a
oferecer uma variedade de PersistentVolumes que di�ram em tamanho e modo de acesso, sem expor
os usuários a detalhes de como esses volumes são implementados. Para necessidades como essas,
temos o recurso de StorageClass.
Veja os exemplos de passo a passo de forma detalhada (/docs/tasks/con�gure-pod-container/con�gure-
persistent-volume-storage/).
Requisição e ciclo de vida de um volume
PVs são recursos dentro um cluster. PVCs são requisições para esses recursos e também atuam como
uma validação da solicitação desses recursos. O ciclo de vida da interação entre PVs e PVCs funcionam
da seguinte forma:
Provisionamento
Existem duas formas de provisionar um PV: estaticamente ou dinamicamente.
Estático
O administrador do cluster cria uma determinada quantidade de PVs. Eles possuem todos os detalhes
do armazenamento os quais estão atrelados, que neste caso �ca disponível para utilização por um
usuário dentro do cluster. Eles estão presentes na API do Kubernetes e disponíveis para utilização.
Dinâmico
Quando nenhum dos PVs estáticos, que foram criados anteriormente pelo administrador, satisfazem os
critérios de uma PersistentVolumeClaim enviado por um usuário, o cluster pode tentar realizar um
provisionamento dinâmico para atender a essa PVC. Esse provisionamento é baseado em
StorageClasses: a PVC deve solicitar uma classe de armazenamento (/docs/concepts/storage/storage-
classes/) e o administrador deve ter previamente criado e con�gurado essa classe para que o
provisionamento dinâmico possa ocorrer. Requisições que solicitam a classe "" efetivamente
desabilitam o provisionamento dinâmico para elas mesmas.
Para habilitar o provisionamento de armazenamento dinâmico baseado em classe de armazenamento,
o administrador do cluster precisa habilitar o controle de admissão (/docs/reference/access-authn-
authz/admission-controllers/#defaultstorageclass) DefaultStorageClass no servidor da API. Isso pode
https://kubernetes.io/docs/concepts/storage/volumes/
https://kubernetes.io/docs/concepts/storage/storage-classes/
https://kubernetes.io/docs/tasks/configure-pod-container/configure-persistent-volume-storage/
https://kubernetes.io/docs/concepts/storage/storage-classes/
https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass
ser feito, por exemplo, garantindo que DefaultStorageClass esteja entre aspas simples, ordenado por
uma lista de valores para a �ag --enable-admission-plugins , componente do servidor da API. Para
mais informações sobre os comandos das �ags do servidor da API, consulte a documentação kube-
apiserver (/docs/admin/kube-apiserver/).
Binding
Um usuário cria, ou em caso de um provisionamento dinâmico já ter criado, uma
PersistentVolumeClaim solicitando uma quantidade especí�ca de armazenamento e um determinado
modo de acesso. Um controle de loop no master monitora por novas PVCs, encontra um PV (se possível)
que satisfaça os requisitos e realiza o bind. Se o PV foi provisionado dinamicamente por uma PVC, o
loop sempre vai fazer o bind desse PV com essa PVC em especí�co. Caso contrário, o usuário vai receber
no mínimo o que ele havia solicitado, porém, o volume possa exceder em relação à solicitação inicial.
Uma vez realizado esse processo, PersistentVolumeClaim sempre vai ter um bind exclusivo, sem levar
em conta como o isso aconteceu. Um bind entre uma PVC e um PV é um mapeamento de um para um,
utilizando o ClaimRef que é um bind bidirecional entre o PersistentVolume e o PersistentVolumeClaim.
As requisições permanecerão sem bind se o volume solicitado não existir. O bind ocorrerá somente se
os requisitos forem atendidos exatamente da mesma forma como solicitado. Por exemplo, um bind de
uma PVC de 100 GB não ocorrerá num cluster que foi provisionado com vários PVs de 50 GB. O bind
ocorrerá somente no momento em que um PV de 100 GB for adicionado.
Utilização
Pods utilizam requisições como volumes. O cluster inspeciona a requisição para encontrar o volume
atrelado a ela e monta esse volume para um Pod. Para volumes que suportam múltiplos modos de
acesso, o usuário especi�ca qual o modo desejado quando utiliza essas requisições.
Uma vez que o usuário tem a requisição atrelada a um PV, ele pertence ao usuário pelo tempo que ele
precisar. Usuários agendam Pods e acessam seus PVs requisitados através da seção
persistentVolumeClaim no bloco volumes do Pod. Para mais detalhes sobre isso, veja Requisições
como Volumes.
Proteção de Uso de um Objeto de Armazenamento
O propósito da funcionalidade do Objeto de Armazenamento em Proteção de Uso é garantir que as
PersistentVolumeClaims (PVCs) que estejam sendo utilizadas por um Pod e PersistentVolume (PVs) que
pertençam aos PVCs não sejam removidos do sistema, pois isso pode resultar numa perda de dados.
Nota: Uma PVC está sendo utilizada por um Pod quando existe um Pod que está usando
essa PVC.
Se um usuário deleta uma PVC que está sendo utilizada por um Pod, esta PVC não é removida
imediatamente. A remoção da PVC é adiada até que a PVC não esteja mais sendo utilizado por nenhum
Pod. Se um administrador deleta um PV que está atrelado a uma PVC, o PV não é removido
imediatamente também. A remoção do PV é adiada até que o PV não esteja mais atrelado à PVC.
Note que uma PVC é protegida quando o status da PVC é Terminating e a lista Finalizers contém
kubernetes.io/pvc-protection :
Note que um PV é protegido quando o status da PVC é Terminating e a lista Finalizers contém
kubernetes.io/pv-protection também:
kubectl describe pvc hostpath 
Name: hostpath 
Namespace: default 
StorageClass: example-hostpath 
Status: Terminating 
Volume: 
Labels: <none> 
Annotations: volume.beta.kubernetes.io/storage-class=example-hostpath 
 volume.beta.kubernetes.io/storage-provisioner=example.com/hostpath 
Finalizers: [kubernetes.io/pvc-protection] 
... 
kubectl describe pv task-pv-volume 
Name: task-pv-volume 
https://kubernetes.io/docs/admin/kube-apiserver/
Recuperação
Quando um usuário não precisar mais utilizar um volume, ele pode deletar a PVC pela API, que, permite
a recuperação do recurso. A política de recuperação para um PersistentVolume diz ao cluster o que
fazer com o volume após ele ter sido liberado da sua requisição. Atualmente, volumes podem ser
Retidos, Reciclados ou Deletados.
Retenção
A política Retainpermite a recuperação de forma manual do recurso. Quando a
PersistentVolumeClaim é deletada, ela continua existindo e o volume é considerado "livre". Mas ele
ainda não está disponível para outra requisição porque os dados da requisição anterior ainda
permanecem no volume. Um administrador pode manualmente recuperar o volume executando os
seguintes passos:
1. Deletar o PersistentVolume. O armazenamento associado à infraestrutura externa (AWS EBS, GCE
PD, Azure Disk ou Cinder volume) ainda continuará existindo após o PV ser deletado.
2. Limpar os dados de forma manual no armazenamento associado.
3. Deletar manualmente o armazenamento associado. Caso você queira utilizar o mesmo
armazenamento, crie um novo PersistentVolume com esse armazenamento.
Deletar
Para plugins de volume que suportam a política de recuperação Delete , a deleção vai remover o tanto
o PersistentVolume do Kubernetes, quanto o armazenamento associado à infraestrutura externa, como
AWS EBS, GCE PD, Azure Disk, ou Cinder volume. Volumes que foram provisionados dinamicamente
herdam a política de retenção da sua StorageClass, que por padrão é Delete . O administrador precisa
con�gurar a StorageClass de acordo com as necessidades dos usuários. Caso contrário, o PV deve ser
editado ou reparado após sua criação. Veja Alterar a política de retenção de um PersistentVolume
(/docs/tasks/administer-cluster/change-pv-reclaim-policy/).
Reciclar
Aviso: A política de retenção Recycle está depreciada. Ao invés disso, recomendamos a
utilização de provisionamento dinâmico.
Em caso do volume plugin ter suporte a essa operação, a política de retenção Recycle faz uma limpeza
básica ( rm -rf /thevolume/* ) no volume e torna ele disponível novamente para outra requisição.
Contudo, um administrador pode con�gurar um template personalizado de um Pod reciclador
utilizando a linha de comando do gerenciamento de controle do Kubernetes como descrito em
referência (/docs/reference/command-line-tools-reference/kube-controller-manager/). O Pod reciclador
personalizado deve conter a spec volume como é mostrado no exemplo abaixo:
Labels: type=local 
Annotations: <none> 
Finalizers: [kubernetes.io/pv-protection] 
StorageClass: standard 
Status: Terminating 
Claim: 
Reclaim Policy: Delete 
Access Modes: RWO 
Capacity: 1Gi 
Message: 
Source: 
 Type: HostPath (bare host directory volume) 
 Path: /tmp/data 
 HostPathType: 
Events: <none> 
apiVersion: v1 
kind: Pod 
metadata: 
 name: pv-recycler 
 namespace: default 
spec:
 restartPolicy: Never 
 volumes: 
 - name: vol 
 hostPath: 
https://kubernetes.io/docs/tasks/administer-cluster/change-pv-reclaim-policy/
https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/
Contudo, o caminho especi�cado no Pod reciclador personalizado em volumes é substituído pelo
caminho do volume que está sendo reciclado.
Reservando um PersistentVolume
A camada de gerenciamento pode fazer o bind de um PersistentVolumeClaims com PersistentVolumes
equivalentes no cluster. Contudo, se você quer que uma PVC faça um bind com um PV especí�co, é
preciso fazer o pré-bind deles.
Especi�cando um PersistentVolume na PersistentVolumeClaim, você declara um bind entre uma PVC e
um PV especí�co. O bind ocorrerá se o PersistentVolume existir e não estiver reservado por uma
PersistentVolumeClaims através do seu campo claimRef .
O bind ocorre independentemente se algum volume atender ao critério, incluindo a�nidade de nó. A
camada de gerenciamento veri�ca se a classe de armazenamento (/docs/concepts/storage/storage-
classes/), modo de acesso e tamanho do armazenamento solicitado ainda são válidos.
Esse método não garante nenhum privilégio de bind no PersistentVolume. Para evitar que alguma outra
PersistentVolumeClaims possa usar o PV que você especi�car, você precisa primeiro reservar esse
volume de armazenamento. Especi�que sua PersistentVolumeClaim no campo claimRef do PV para
que outras PVCs não façam bind nele.
Isso é útil se você deseja utilizar PersistentVolumes que possuem suas claimPolicy con�guradas para
Retain , incluindo situações onde você estiver reutilizando um PV existente.
Expandindo Requisições de Volumes Persistentes
FEATURE STATE: Kubernetes v1.11 [beta]
Agora, o suporte à expansão de PersistentVolumeClaims (PVCs) já é habilitado por padrão. Você pode
expandir os tipos de volumes abaixo:
gcePersistentDisk
awsElasticBlockStore
Cinder
glusterfs
rbd
 path: /any/path/it/will/be/replaced 
 containers: 
 - name: pv-recycler 
 image: "k8s.gcr.io/busybox" 
 command: ["/bin/sh", "-c", "test -e /scrub && rm -rf /scrub/..?* /scrub/.[!.]* /scrub/* && 
 volumeMounts: 
 - name: vol 
 mountPath: /scrub 
apiVersion: v1 
kind: PersistentVolumeClaim 
metadata: 
 name: foo-pvc 
 namespace: foo 
spec:
 storageClassName: "" # Empty string must be explicitly set otherwise default StorageClass will b
 volumeName: foo-pv 
 ... 
apiVersion: v1 
kind: PersistentVolume 
metadata: 
 name: foo-pv 
spec:
 storageClassName: "" 
 claimRef: 
 name: foo-pvc 
 namespace: foo 
 ... 
https://kubernetes.io/docs/concepts/storage/storage-classes/
Azure File
Azure Disk
Portworx
FlexVolumes
CSI (/docs/concepts/storage/volumes/#csi)
Você só pode expandir uma PVC se o campo da classe de armazenamento allowVolumeExpansion é
true .
Para solicitar um volume maior para uma PVC, edite a PVC e especi�que um tamanho maior. Isso irá
fazer com o que volume atrelado ao respectivo PersistentVolume seja expandido. Nunca um
PersistentVolume é criado para satisfazer a requisição. Ao invés disso, um volume existente é
redimensionado.
Expansão de volume CSI
FEATURE STATE: Kubernetes v1.16 [beta]
O suporte à expansão de volumes CSI é habilitada por padrão, porém é necessário um driver CSI
especí�co para suportar a expansão do volume. Veri�que a documentação do driver CSI especí�co para
mais informações.
Redimensionando um volume que contém um sistema de arquivo
Só podem ser redimensionados os volumes que contém os seguintes sistemas de arquivo: XFS, Ext3 ou
Ext4.
Quando um volume contém um sistema de arquivo, o sistema de arquivo somente é redimensionado
quando um novo Pod está utilizando a PersistentVolumeClaim no modo ReadWrite . A expansão de
sistema de arquivo é feita quando um Pod estiver inicializando ou quando um Pod estiver em execução
e o respectivo sistema de arquivo tenha suporte para expansão a quente.
FlexVolumes permitem redimensionamento se o RequiresFSResize do drive é con�gurado como
true . O FlexVolume pode ser redimensionado na reinicialização do Pod.
Redimensionamento de uma PersistentVolumeClaim em uso
FEATURE STATE: Kubernetes v1.15 [beta]
Nota: A Expansão de PVCs em uso está disponível como beta desde o Kubernetes 1.15, e
como alpha desde a versão 1.11. A funcionalidade ExpandInUsePersistentVolumes
precisa ser habilitada, o que já está automático para vários clusters que possuem
funcionalidades beta. Veri�que a documentação feature gate (/docs/reference/command-
line-tools-reference/feature-gates/) para mais informações.
Neste caso, você não precisa deletar e recriar um Pod ou um deployment que está sendo utilizado por
uma PVC existente. Automaticamente, qualquer PVC em uso �ca disponível para o Pod assim que o
sistema de arquivo for expandido. Essa funcionalidade não tem efeito em PVCs que não estão em uso
por um Pod ou deployment. Você deve criar um Pod que utilize a PVC antes que a expansão seja
completada.
Da mesma forma que outros tipos de volumes - volumes FlexVolume também podem ser expandidos
quando estiverem em uso por um Pod.
apiVersion: storage.k8s.io/v1 
kind: StorageClass 
metadata: 
 name: gluster-vol-default 
provisioner: kubernetes.io/glusterfs 
parameters: 
 resturl: "http://192.168.10.100:8080" 
 restusuário: "" 
 secretNamespace: ""secretName: "" 
allowVolumeExpansion: true 
https://kubernetes.io/docs/concepts/storage/volumes/#csi
https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/
Nota: Redimensionamento de FlexVolume somente é possível quando o respectivo driver
suportar essa operação.
Nota: Expandir volumes do tipo EBS é uma operação que toma muito tempo. Além disso,
só é possível fazer uma modi�cação por volume a cada 6 horas.
Recuperação em caso de falha na expansão de volumes
Se a expansão do respectivo armazenamento falhar, o administrador do cluster pode recuperar
manualmente o estado da Persistent Volume Claim (PVC) e cancelar as solicitações de
redimensionamento. Caso contrário, as tentativas de solicitação de redimensionamento ocorrerão de
forma contínua pelo controlador sem nenhuma intervenção do administrador.
1. Marque o PersistentVolume(PV) que estiver atrelado à PersistentVolumeClaim(PVC) com a política
de recuperação Retain .
2. Delete a PVC. Desde que o PV tenha a política de recuperação Retain - nenhum dado será
perdido quando a PVC for recriada.
3. Delete a entrada claimRef da especi�cação do PV para que uma PVC possa fazer bind com ele.
Isso deve tornar o PV Available .
4. Recrie a PVC com um tamanho menor que o PV e con�gure o campo volumeName da PCV com o
nome do PV. Isso deve fazer o bind de uma nova PVC a um PV existente.
5. Não esqueça de restaurar a política de recuperação do PV.
Tipos de volumes persistentes
Tipos de PersistentVolume são implementados como plugins. Atualmente o Kubernetes suporta os
plugins abaixo:
awsElasticBlockStore (/docs/concepts/storage/volumes/#awselasticblockstore) - AWS Elastic
Block Store (EBS)
azureDisk (/docs/concepts/storage/volumes/#azuredisk) - Azure Disk
azureFile (/docs/concepts/storage/volumes/#azure�le) - Azure File
cephfs (/docs/concepts/storage/volumes/#cephfs) - CephFS volume
cinder (/docs/concepts/storage/volumes/#cinder) - Cinder (OpenStack block storage)
(depreciado)
csi (/docs/concepts/storage/volumes/#csi) - Container Storage Interface (CSI)
fc (/docs/concepts/storage/volumes/#fc) - Fibre Channel (FC) storage
flexVolume (/docs/concepts/storage/volumes/#�exVolume) - FlexVolume
flocker (/docs/concepts/storage/volumes/#�ocker) - Flocker storage
gcePersistentDisk (/docs/concepts/storage/volumes/#gcepersistentdisk) - GCE Persistent Disk
glusterfs (/docs/concepts/storage/volumes/#glusterfs) - Glusterfs volume
hostPath (/docs/concepts/storage/volumes/#hostpath) - HostPath volume (somente para teste de
nó único; ISSO NÃO FUNCIONARÁ num cluster multi-nós; ao invés disso, considere a utilização de
volume local .)
iscsi (/docs/concepts/storage/volumes/#iscsi) - iSCSI (SCSI over IP) storage
local (/docs/concepts/storage/volumes/#local) - storage local montados nos nós.
nfs (/docs/concepts/storage/volumes/#nfs) - Network File System (NFS) storage
photonPersistentDisk - Controlador Photon para disco persistente. (Esse tipo de volume não
funciona mais desde a removação do provedor de cloud correspondente.)
portworxVolume (/docs/concepts/storage/volumes/#portworxvolume) - Volume Portworx
quobyte (/docs/concepts/storage/volumes/#quobyte) - Volume Quobyte
rbd (/docs/concepts/storage/volumes/#rbd) - Volume Rados Block Device (RBD)
scaleIO (/docs/concepts/storage/volumes/#scaleio) - Volume ScaleIO (depreciado)
storageos (/docs/concepts/storage/volumes/#storageos) - Volume StorageOS
vsphereVolume (/docs/concepts/storage/volumes/#vspherevolume) - Volume vSphere VMDK
Volumes Persistentes
https://kubernetes.io/docs/concepts/storage/volumes/#awselasticblockstore
https://kubernetes.io/docs/concepts/storage/volumes/#azuredisk
https://kubernetes.io/docs/concepts/storage/volumes/#azurefile
https://kubernetes.io/docs/concepts/storage/volumes/#cephfs
https://kubernetes.io/docs/concepts/storage/volumes/#cinder
https://kubernetes.io/docs/concepts/storage/volumes/#csi
https://kubernetes.io/docs/concepts/storage/volumes/#fc
https://kubernetes.io/docs/concepts/storage/volumes/#flexVolume
https://kubernetes.io/docs/concepts/storage/volumes/#flocker
https://kubernetes.io/docs/concepts/storage/volumes/#gcepersistentdisk
https://kubernetes.io/docs/concepts/storage/volumes/#glusterfs
https://kubernetes.io/docs/concepts/storage/volumes/#hostpath
https://kubernetes.io/docs/concepts/storage/volumes/#iscsi
https://kubernetes.io/docs/concepts/storage/volumes/#local
https://kubernetes.io/docs/concepts/storage/volumes/#nfs
https://kubernetes.io/docs/concepts/storage/volumes/#portworxvolume
https://kubernetes.io/docs/concepts/storage/volumes/#quobyte
https://kubernetes.io/docs/concepts/storage/volumes/#rbd
https://kubernetes.io/docs/concepts/storage/volumes/#scaleio
https://kubernetes.io/docs/concepts/storage/volumes/#storageos
https://kubernetes.io/docs/concepts/storage/volumes/#vspherevolume
Cada PV contém uma spec e um status, que é a especi�cação e o status do volume. O nome do
PersistentVolume deve ser um DNS (/docs/concepts/overview/working-with-objects/names#dns-
subdomain-names) válido.
Nota: Talvez sejam necessários programas auxiliares para um determinado tipo de volume
utilizar um PersistentVolume no cluster. Neste exemplo, o PersistentVolume é do tipo NFS
e o programa auxiliar /sbin/mount.nfs é necessário para suportar a montagem dos sistemas
de arquivos NFS.
Capacidade
Geralmente, um PV terá uma capacidade de armazenamento especí�ca. Isso é con�gurado usando o
atributo capacity do PV. Veja o Modelo de Recurso (https://git.k8s.io/community/contributors/design-
proposals/scheduling/resources.md) do Kubernetes para entender as unidades aceitas pelo atributo
capacity .
Atualmente, o tamanho do armazenamento é o único recurso que pode ser con�gurado ou solicitado.
Os futuros atributos podem incluir IOPS, throughput, etc.
Modo do Volume
FEATURE STATE: Kubernetes v1.18 [stable]
O Kubernetes suporta dois volumeModes de PersistentVolumes: Filesystem e Block .
volumeMode é um parâmetro opcional da API. Filesystem é o modo padrão utilizado quando o
parâmetro volumeMode é omitido.
Um volume com volumeMode: Filesystem é montado em um diretório nos Pods. Se o volume for de
um dispositivo de bloco e ele estiver vazio, o Kubernetes cria o sistema de arquivo no dispositivo antes
de fazer a montagem pela primeira vez.
Você pode con�gurar o valor do volumeMode para Block para utilizar um disco bruto como volume.
Esse volume é apresentado num Pod como um dispositivo de bloco, sem nenhum sistema de arquivo.
Esse modo é útil para prover ao Pod a forma mais rápida para acessar um volume, sem nenhuma
camada de sistema de arquivo entre o Pod e o volume. Por outro lado, a aplicação que estiver rodando
no Pod deverá saber como tratar um dispositivo de bloco. Veja Suporte a Volume de Bloco Bruto para
um exemplo de como utilizar o volume como volumeMode: Block num Pod.
Modos de Acesso
Um PersistentVolume pode ser montado num host das mais variadas formas suportadas pelo provedor.
Como mostrado na tabela abaixo, os provedores terão diferentes capacidades e cada modo de acesso
do PV são con�gurados nos modos especí�cos suportados para cada volume em particular. Por
exemplo, o NFS pode suportar múltiplos clientes read/write, mas um PV NFS especí�co pode ser
exportado no server como read-only. Cada PV recebe seu próprio modo de acesso que descreve suas
capacidades especí�cas.
Os modos de acesso são:
apiVersion: v1 
kind: PersistentVolume 
metadata: 
 name: pv0003 
spec:
 capacity: 
 storage: 5Gi 
 volumeMode: Filesystem 
 accessModes: 
 - ReadWriteOnce 
 persistentVolumeReclaimPolicy: Retain 
 storageClassName: slow 
 mountOptions:
 - hard
 - nfsvers=4.1 
 nfs: 
 path: /tmp 
 server: 172.17.0.2 
https://kubernetes.io/docs/concepts/overview/working-with-objects/names#dns-subdomain-names
https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md
ReadWriteOnce -- o volume pode ser montado como leitura-escritapor um nó único
ReadOnlyMany -- o volume pode ser montado como somente-leitura por vários nós
ReadWriteMany -- o volume pode ser montado como leitura-escrita por vários nós
Na linha de comando, os modos de acesso �cam abreviados:
RWO - ReadWriteOnce
ROX - ReadOnlyMany
RWX - ReadWriteMany
Importante! Um volume somente pode ser montado utilizando um único modo de acesso
por vez, independente se ele suportar mais de um. Por exemplo, um GCEPersistentDisk
pode ser montado como ReadWriteOnce por um único nó ou ReadOnlyMany por vários nós,
porém não simultaneamente.
Plugin de
Volume ReadWriteOnce ReadOnlyMany ReadWriteMany
AWSElasticBlockS
tore
✓ - -
AzureFile ✓ ✓ ✓
AzureDisk ✓ - -
CephFS ✓ ✓ ✓
Cinder ✓ - -
CSI depende do
driver
depende do
driver
depende do driver
FC ✓ ✓ -
FlexVolume ✓ ✓ depende do driver
Flocker ✓ - -
GCEPersistentDis
k
✓ ✓ -
Glusterfs ✓ ✓ ✓
HostPath ✓ - -
iSCSI ✓ ✓ -
Quobyte ✓ ✓ ✓
NFS ✓ ✓ ✓
RBD ✓ ✓ -
VsphereVolume ✓ - (funcionam quando os Pods são do tipo
collocated)
PortworxVolume ✓ - ✓
ScaleIO ✓ ✓ -
StorageOS ✓ - -
Classe
Um PV pode ter uma classe, que é especi�cada na con�guração do atributo storageClassName com o
nome da StorageClass (/docs/concepts/storage/storage-classes/). Um PV de uma classe especí�ca só
pode ser atrelado a requisições PVCs dessa mesma classe. Um PV sem storageClassName não possui
nenhuma classe e pode ser montado somente a PVCs que não solicitem nenhuma classe em especí�co.
No passado, a notação volume.beta.kubernetes.io/storage-class era utilizada no lugar do atributo
storageClassName . Essa notação ainda funciona. Contudo, ela será totalmente depreciada numa futura
versão do Kubernetes.
Política de Retenção
Atualmente as políticas de retenção são:
Retain -- recuperação manual
Recycle -- limpeza básica ( rm -rf /thevolume/* )
Delete -- o volume de armazenamento associado, como AWS EBS, GCE PD, Azure Disk ou
OpenStack Cinder é deletado
Atualmente, somente NFS e HostPath suportam reciclagem. Volumes AWS EBS, GCE PD, Azure Disk e
Cinder suportam delete.
Opções de Montagem
Um administrador do Kubernetes pode especi�car opções de montagem adicionais quando um Volume
Persistente é montado num nó.
Nota: Nem todos os tipos de Volume Persistente suportam opções de montagem.
Seguem os tipos de volumes que suportam opções de montagem.
AWSElasticBlockStore
AzureDisk
AzureFile
CephFS
Cinder (OpenStack block storage)
GCEPersistentDisk
Glusterfs
NFS
Quobyte Volumes
RBD (Ceph Block Device)
StorageOS
VsphereVolume
iSCSI
Não há validação em relação às opções de montagem. A montagem irá falhar se houver alguma opção
inválida.
No passado, a notação volume.beta.kubernetes.io/mount-options era usada no lugar do atributo
mountOptions . Essa notação ainda funciona. Contudo, ela será totalmente depreciada numa futura
versão do Kubernetes.
A�nidade de Nó
Nota: Para a maioria dos tipos de volume, a con�guração desse campo não se faz
necessária. Isso é automaticamente populado pelos seguintes volumes de bloco do tipo:
AWS EBS (/docs/concepts/storage/volumes/#awselasticblockstore), GCE PD
(/docs/concepts/storage/volumes/#gcepersistentdisk) e Azure Disk
(/docs/concepts/storage/volumes/#azuredisk). Você precisa deixar isso con�gurado para
volumes do tipo local (/docs/concepts/storage/volumes/#local).
Um PV pode especi�car uma a�nidade de nó (/docs/reference/generated/kubernetes-
api/v1.22/#volumenodea�nity-v1-core) para de�nir restrições em relação ao limite de nós que podem
acessar esse volume. Pods que utilizam um PV serão somente reservados para nós selecionados pela
a�nidade de nó.
https://kubernetes.io/docs/concepts/storage/storage-classes/
https://kubernetes.io/docs/concepts/storage/volumes/#awselasticblockstore
https://kubernetes.io/docs/concepts/storage/volumes/#gcepersistentdisk
https://kubernetes.io/docs/concepts/storage/volumes/#azuredisk
https://kubernetes.io/docs/concepts/storage/volumes/#local
https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/#volumenodeaffinity-v1-core
Estado
Um volume sempre estará em um dos seguintes estados:
Available -- um recurso que está livre e ainda não foi atrelado a nenhuma requisição
Bound -- um volume atrelado a uma requisição
Released -- a requisição foi deletada, mas o curso ainda não foi recuperado pelo cluster
Failed -- o volume fracassou na sua recuperação automática
A CLI mostrará o nome do PV que foi atrelado à PVC
PersistentVolumeClaims
Cada PVC contém uma spec e um status, que é a especi�cação e estado de uma requisição. O nome de
um objeto PersistentVolumeClaim precisa ser um DNS (/docs/concepts/overview/working-with-
objects/names#dns-subdomain-names) válido.
Modos de Acesso
As requisições usam as mesmas convenções que os volumes quando eles solicitam um armazenamento
com um modo de acesso especí�co.
Modos de Volume
As requisições usam as mesmas convenções que os volumes quando eles indicam o tipo de volume,
seja ele um sistema de arquivo ou dispositivo de bloco.
Recursos
Assim como Pods, as requisições podem solicitar quantidades especí�cas de recurso. Neste caso, a
solicitação é por armazenamento. O mesmo modelo de recurso
(https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md) vale para
volumes e requisições.
Seletor
Requisições podem especi�ar um seletor de rótulo (/docs/concepts/overview/working-with-
objects/labels/#label-selectors) para posteriormente �ltrar um grupo de volumes. Somente os volumes
que possuam rótulos que satisfaçam os critérios do seletor podem ser atrelados à requisição. O seletor
pode conter dois campos:
matchLabels - o volume deve ter um rótulo com esse valor
matchExpressions - uma lista de requisitos, como chave, lista de valores e operador relacionado
aos valores e chaves. São operadores válidos: In, NotIn, Exists e DoesNotExist.
Todos os requisitos de matchLabels e matchExpressions , são do tipo AND - todos eles juntos devem
ser atendidos.
Classe
apiVersion: v1 
kind: PersistentVolumeClaim 
metadata: 
 name: myclaim 
spec:
 accessModes: 
 - ReadWriteOnce 
 volumeMode: Filesystem 
 resources: 
 requests: 
 storage: 8Gi 
 storageClassName: slow 
 selector: 
 matchLabels: 
 release: "stable" 
 matchExpressions: 
 - {key: environment, operator: In, values: [dev]} 
https://kubernetes.io/docs/concepts/overview/working-with-objects/names#dns-subdomain-names
https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md
https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors
Uma requisição pode solicitar uma classe especí�ca através da StorageClass
(/docs/concepts/storage/storage-classes/) utilizando o atributo storageClassName . Neste caso o bind
ocorrerá somente com os PVs que possuírem a mesma classe do storageClassName dos PVCs.
As PVCs não precisam necessariamente solicitar uma classe. Uma PVC com sua storageClassName
con�gurada como "" sempre solicitará um PV sem classe, dessa forma ela sempre será atrelada a um
PV sem classe (que não tenha nenhuma notação, ou seja, igual a "" ). Uma PVC sem storageClassName
não é a mesma coisa e será tratada pelo cluster de forma diferente, porém isso dependerá se o puglin
de admissão (/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass)
DefaultStorageClass estiver habilitado.
Se o plugin de admissão estiver habilitado, o administrador poderá especi�car a StorageClass
padrão. Todas as PVCs que não tiverem storageClassName podem ser atreladas somente a PVs
que atendam a esse padrão. A especi�cação de uma StorageClass padrão é feita através da
notação storageclass.kubernetes.io/is-default-class recebendo o valor true no objeto da
StorageClass. Se o administrador não especi�car nenhum padrão, o cluster vai tratar a criação de
uma PVC como se o plugin de admissão estivesse desabilitado. Se mais de um valor padrão for
especi�cado, o plugin de admissãoproíbe a criação de todas as PVCs.
Se o plugin de admissão estiver desabilitado, não haverá nenhuma notação para a StorageClass
padrão. Todas as PVCs que não tiverem storageClassName poderão ser atreladas somente aos
PVs que não possuem classe. Neste caso, as PVCs que não tiverem storageClassName são
tratadas da mesma forma como as PVCs que possuem suas storageClassName con�guradas
como "" .
Dependendo do modo de instalação, uma StorageClass padrão pode ser implantada num cluster
Kubernetes durante a instalação pelo addon manager.
Quando uma PVC especi�ca um selector para solicitar uma StorageClass, os requisitos são do tipo
AND: somente um PV com a classe solicitada e com o rótulo requisitado pode ser atrelado à PVC.
Nota: Atualmente, uma PVC que tenha selector não pode ter um PV dinamicamente
provisionado.
No passado, a notação volume.beta.kubernetes.io/storage-class era usada no lugar do atributo
storageClassName Essa notação ainda funciona. Contudo, ela será totalmente depreciada numa futura
versão do Kubernetes.
Requisições como Volumes
Os Pods podem ter acesso ao armazenamento utilizando a requisição como um volume. Para isso, a
requisição tem que estar no mesmo namespace que o Pod. Ao localizar a requisição no namespace do
Pod, o cluster passa o PersistentVolume para a requisição.
Sobre Namespaces
Os binds dos PersistentVolumes são exclusivos e, desde que as PersistentVolumeClaims são objetos do
namespace, fazer a montagem das requisições com "Muitos" nós ( ROX , RWX ) é possível somente para
um namespace.
PersistentVolumes do tipo hostPath
apiVersion: v1 
kind: Pod 
metadata: 
 name: mypod 
spec:
 containers: 
 - name: myfrontend 
 image: nginx 
 volumeMounts: 
 - mountPath: "/var/www/html" 
 name: mypd 
 volumes: 
 - name: mypd 
 persistentVolumeClaim: 
 claimName: myclaim 
https://kubernetes.io/docs/concepts/storage/storage-classes/
https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass
Um PersistentVolume do tipo hostPath utiliza um arquivo ou diretório no nó para emular um network-
attached storage (NAS). Veja um exemplo de volume do tipo hostPath (/docs/tasks/con�gure-pod-
container/con�gure-persistent-volume-storage/#create-a-persistentvolume).
Suporte a Volume de Bloco Bruto
FEATURE STATE: Kubernetes v1.18 [stable]
Os plugins de volume abaixo suportam volumes de bloco bruto, incluindo provisionamento dinâmico
onde for aplicável:
AWSElasticBlockStore
AzureDisk
CSI
FC (Fibre Channel)
GCEPersistentDisk
iSCSI
Local volume
OpenStack Cinder
RBD (Ceph Block Device)
VsphereVolume
Utilização de PersistentVolume com Volume de Bloco Bruto
Requisição de PersistentVolumeClaim com Volume de Bloco Bruto
Especi�cação de Pod com Dispositivo de Bloco Bruto no contêiner
apiVersion: v1 
kind: PersistentVolume 
metadata: 
 name: block-pv 
spec:
 capacity: 
 storage: 10Gi 
 accessModes: 
 - ReadWriteOnce 
 volumeMode: Block 
 persistentVolumeReclaimPolicy: Retain 
 fc: 
 targetWWNs: ["50060e801049cfd1"] 
 lun: 0 
 readOnly: false 
apiVersion: v1 
kind: PersistentVolumeClaim 
metadata: 
 name: block-pvc 
spec:
 accessModes: 
 - ReadWriteOnce 
 volumeMode: Block 
 resources: 
 requests: 
 storage: 10Gi 
apiVersion: v1 
kind: Pod 
metadata: 
 name: pod-with-block-volume 
spec:
 containers: 
 - name: fc-container 
 image: fedora:26 
 command: ["/bin/sh", "-c"] 
 args: [ "tail -f /dev/null" ]
 volumeDevices:
https://kubernetes.io/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume
Nota: Quando adicionar um dispositivo de bloco bruto num Pod, você especi�ca o
caminho do dispositivo no contêiner ao invés de um ponto de montagem.
Bind de Volumes de Bloco
Se um usuário solicita um volume de bloco bruto através do campo volumeMode na spec da
PersistentVolumeClaim, as regras de bind agora têm uma pequena diferença em relação às versões
anteriores que não consideravam esse modo como parte da spec . A tabela abaixo mostra as possíveis
combinações que um usuário e um administrador pode especi�car para requisitar um dispositivo de
bloco bruto. A tabela indica se o volume será ou não atrelado com base nas combinações: Matriz de
bind de volume para provisionamento estático de volumes:
PV volumeMode PVC volumeMode Result
unspeci�ed unspeci�ed BIND
unspeci�ed Block NO BIND
unspeci�ed Filesystem BIND
Block unspeci�ed NO BIND
Block Block BIND
Block Filesystem NO BIND
Filesystem Filesystem BIND
Filesystem Block NO BIND
Filesystem unspeci�ed BIND
Nota: O provisionamento estático de volumes é suportado somente na versão alpha. Os
administradores devem tomar cuidado ao considerar esses valores quando estiverem
trabalhando com dispositivos de bloco bruto.
Snapshot de Volume e Restauração de Volume a partir
de um Snapshot
FEATURE STATE: Kubernetes v1.20 [stable]
O snapshot de volume é suportado somente pelo plugin de volume CSI. Veja Snapshot de Volume
(/docs/concepts/storage/volume-snapshots/) para mais detalhes. Plugins de volume in-tree estão
depreciados. Você pode consultar sobre os plugins de volume depreciados em Perguntas Frequentes
sobre Plugins de Volume (https://github.com/kubernetes/community/blob/master/sig-storage/volume-
plugin-faq.md).
Criar uma PersistentVolumeClaim a partir de um Snapshot de
Volume
 - name: data
 devicePath: /dev/xvda 
 volumes: 
 - name: data 
 persistentVolumeClaim: 
 claimName: block-pvc 
apiVersion: v1 
kind: PersistentVolumeClaim 
metadata: 
 name: restore-pvc 
spec:
https://kubernetes.io/docs/concepts/storage/volume-snapshots/
https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md
Clonagem de Volume
A Clonagem de Volume (/docs/concepts/storage/volume-pvc-datasource/) é possível somente com
plugins de volume CSI.
Criação de PersistentVolumeClaim a partir de uma PVC já existente
Boas Práticas de Con�guração
Se você está criando templates ou exemplos que rodam numa grande quantidade de clusters e que
precisam de armazenamento persistente, recomendamos que utilize o padrão abaixo:
Inclua objetos PersistentVolumeClaim em seu pacote de con�guração (com Deployments,
Con�gMaps, etc.).
Não inclua objetos PersistentVolume na con�guração, pois o usuário que irá instanciar a
con�guração talvez não tenha permissão para criar PersistentVolume.
Dê ao usuário a opção dele informar o nome de uma classe de armazenamento quando instanciar
o template.
Se o usuário informar o nome de uma classe de armazenamento, coloque esse valor no
campo persistentVolumeClaim.storageClassName . Isso fará com que a PVC encontre a
classe de armazenamento correta se o cluster tiver a StorageClasses habilitado pelo
administrador.
Se o usuário não informar o nome da classe de armazenamento, deixe o campo
persistentVolumeClaim.storageClassName sem nenhum valor (vazio). Isso fará com que o
PV seja provisionado automaticamente no cluster para o usuário com o StorageClass padrão.
Muitos ambientes de cluster já possuem uma StorageClass padrão, ou então os
administradores podem criar suas StorageClass de acordo com seus critérios.
Durante suas tarefas de administração, busque por PVCs que após um tempo não estão sendo
atreladas, pois, isso talvez indique que o cluster não tem provisionamento dinâmico (onde o
usuário deveria criar um PV que satisfaça os critérios da PVC) ou cluster não tem um sistema de
armazenamento (onde usuário não pode realizar um deploy solicitando PVCs).
Qual é o próximo
Saiba mais sobre Criando um PersistentVolume (/docs/tasks/con�gure-pod-container/con�gure-
persistent-volume-storage/#create-a-persistentvolume).
Saiba mais sobre Criando um PersistentVolumeClaim (/docs/tasks/con�gure-pod-
container/con�gure-persistent-volume-storage/#create-a-persistentvolumeclaim).
 storageClassName:csi-hostpath-sc 
 dataSource: 
 name: new-snapshot-test 
 kind: VolumeSnapshot 
 apiGroup: snapshot.storage.k8s.io 
 accessModes: 
 - ReadWriteOnce 
 resources: 
 requests: 
 storage: 10Gi 
apiVersion: v1 
kind: PersistentVolumeClaim 
metadata: 
 name: cloned-pvc 
spec:
 storageClassName: my-csi-plugin 
 dataSource: 
 name: existing-src-pvc-name 
 kind: PersistentVolumeClaim 
 accessModes: 
 - ReadWriteOnce 
 resources: 
 requests: 
 storage: 10Gi 
https://kubernetes.io/docs/concepts/storage/volume-pvc-datasource/
https://kubernetes.io/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume
https://kubernetes.io/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolumeclaim
Leia a documentação sobre planejamento de Armazenamento Persistente
(https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md).
Referência
PersistentVolume (/docs/reference/generated/kubernetes-api/v1.22/#persistentvolume-v1-core)
PersistentVolumeSpec (/docs/reference/generated/kubernetes-api/v1.22/#persistentvolumespec-
v1-core)
PersistentVolumeClaim (/docs/reference/generated/kubernetes-api/v1.22/#persistentvolumeclaim-
v1-core)
https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md
https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/#persistentvolume-v1-core
https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/#persistentvolumespec-v1-core
https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/#persistentvolumeclaim-v1-core
3.3 - Arquitetura do Kubernetes
3.3.1 - Comunicação entre Nó e Control
Plane
Este documento cataloga os caminhos de comunicação entre o control plane (o apiserver) e o cluster
Kubernetes. A intenção é permitir que os usuários personalizem sua instalação para proteger a
con�guração de rede então o cluster pode ser executado em uma rede não con�ável (ou em IPs
totalmente públicos em um provedor de nuvem).
Nó para o Control Plane
Todos os caminhos de comunicação do cluster para o control plane terminam no apiserver (nenhum
dos outros componentes do control plane são projetados para expor Serviços remotos). Em uma
implantação típica, o apiserver é con�gurado para escutar conexões remotas em uma porta HTTPS
segura (443) com uma ou mais clientes autenticação (/docs/reference/access-authn-
authz/authentication/) habilitado. Uma ou mais formas de autorização (/docs/reference/access-authn-
authz/authorization/) deve ser habilitado, especialmente se requisições anônimas
(/docs/reference/access-authn-authz/authentication/#anonymous-requests) ou tokens da conta de
serviço (/docs/reference/access-authn-authz/authentication/#service-account-tokens) são autorizados.
Os nós devem ser provisionados com o certi�cado root público para o cluster de tal forma que eles
podem se conectar de forma segura ao apiserver junto com o cliente válido credenciais. Por exemplo,
em uma implantação padrão do GKE, as credenciais do cliente fornecidos para o kubelet estão na forma
de um certi�cado de cliente. Vejo bootstrapping TLS do kubelet (/docs/reference/command-line-tools-
reference/kubelet-tls-bootstrapping/) para provisionamento automatizado de certi�cados de cliente
kubelet.
Os pods que desejam se conectar ao apiserver podem fazê-lo com segurança, aproveitando conta de
serviço para que o Kubernetes injetará automaticamente o certi�cado raiz público certi�cado e um
token de portador válido no pod quando ele é instanciado. O serviço kubernetes (no namespace
default ) é con�gurado com um IP virtual endereço que é redirecionado (via kube-proxy) para o
endpoint com HTTPS no apiserver.
Os componentes do control plane também se comunicam com o apiserver do cluster através da porta
segura.
Como resultado, o modo de operação padrão para conexões do cluster (nodes e pods em execução nos
Nodes) para o control plane é protegido por padrão e pode passar por redes não con�áveis e/ou
públicas.
Control Plane para o nó
Existem dois caminhos de comunicação primários do control plane (apiserver) para os nós. O primeiro é
do apiserver para o processo do kubelet que é executado em cada nó no cluster. O segundo é do
apiserver para qualquer nó, pod, ou serviço através da funcionalidade de proxy do apiserver.
apiserver para o kubelet
As conexões do apiserver ao kubelet são usadas para:
Buscar logs para pods.
Anexar (através de kubectl) pods em execução.
Fornecer a funcionalidade de encaminhamento de porta do kubelet.
Essas conexões terminam no endpoint HTTPS do kubelet. Por padrão, o apiserver não veri�ca o
certi�cado de serviço do kubelet, o que torna a conexão sujeita a ataques man-in-the-middle, o que o
torna inseguro para passar por redes não con�áveis e / ou públicas.
Para veri�car essa conexão, use a �ag --kubelet-certificate-authority para fornecer o apiserver
com um pacote de certi�cado raiz para usar e veri�car o certi�cado de serviço da kubelet.
Se isso não for possível, use o SSH túnel (/docs/concepts/architecture/master-node-
communication/#ssh-tunnels) entre o apiserver e kubelet se necessário para evitar a conexão ao longo
de um rede não con�ável ou pública.
https://kubernetes.io/docs/reference/access-authn-authz/authentication/
https://kubernetes.io/docs/reference/access-authn-authz/authorization/
https://kubernetes.io/docs/reference/access-authn-authz/authentication/#anonymous-requests
https://kubernetes.io/docs/reference/access-authn-authz/authentication/#service-account-tokens
https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/
https://kubernetes.io/docs/concepts/architecture/master-node-communication/#ssh-tunnels
Finalmente, Autenticação e/ou autorização do Kubelet (/docs/admin/kubelet-authentication-
authorization/) deve ser ativado para proteger a API do kubelet.
apiserver para nós, pods e serviços
As conexões a partir do apiserver para um nó, pod ou serviço padrão para simples conexões HTTP não
são autenticadas nem criptografadas. Eles podem ser executados em uma conexão HTTPS segura
pre�xando https: no nó, pod, ou nome do serviço no URL da API, mas eles não validarão o certi�cado
fornecido pelo ponto de extremidade HTTPS, nem fornece credenciais de cliente, enquanto a conexão
será criptografada, não fornecerá nenhuma garantia de integridade. Estas conexões não são
atualmente seguras para serem usados por redes não con�áveis e/ou públicas.
SSH Túnel
O Kubernetes suporta túneis SSH para proteger os caminhos de comunicação do control plane para os
nós. Nesta con�guração, o apiserver inicia um túnel SSH para cada nó no cluster (conectando ao
servidor ssh escutando na porta 22) e passa todo o tráfego destinado a um kubelet, nó, pod ou serviço
através do túnel. Este túnel garante que o tráfego não seja exposto fora da rede aos quais os nós estão
sendo executados.
Atualmente, os túneis SSH estão obsoletos, portanto, você não deve optar por usá-los, a menos que
saiba o que está fazendo. O serviço Konnectivity é um substituto para este canal de comunicação.
Konnectivity service
FEATURE STATE: Kubernetes v1.18 [beta]
Como uma substituição aos túneis SSH, o serviço Konnectivity fornece proxy de nível TCP para a
comunicação do control plane para o cluster. O serviço Konnectivity consiste em duas partes: o servidor
Konnectivity na rede control plane e os agentes Konnectivity na rede dos nós. Os agentes Konnectivity
iniciam conexões com o servidor Konnectivity e mantêm as conexões de rede. Depois de habilitar o
serviço Konnectivity, todo o tráfego do control plane para os nós passa por essas conexões.
Veja a tarefa do Konnectivity (docs/tasks/extend-kubernetes/setup-konnectivity/) para con�gurar o
serviço Konnectivity no seu cluster.
https://kubernetes.io/docs/admin/kubelet-authentication-authorization/
https://kubernetes.io/pt-br/docs/_print/docs/tasks/extend-kubernetes/setup-konnectivity/