{"id":1631,"date":"2024-09-24T16:59:35","date_gmt":"2024-09-24T19:59:35","guid":{"rendered":"https:\/\/www.erudio.com.br\/blog\/?p=1631"},"modified":"2024-10-01T16:31:11","modified_gmt":"2024-10-01T19:31:11","slug":"lista-de-terminologias-do-kubernetes","status":"publish","type":"post","link":"https:\/\/www.erudio.com.br\/blog\/lista-de-terminologias-do-kubernetes\/","title":{"rendered":"Lista de Terminologias do Kubernetes"},"content":{"rendered":"\n

<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

<\/p>\n\n\n\n

Introdu\u00e7\u00e3o<\/h3>\n\n\n\n

Este gloss\u00e1rio re\u00fane uma vasta gama de termos essenciais do universo Kubernetes<\/strong>, uma plataforma de c\u00f3digo aberto amplamente adotada para a orquestra\u00e7\u00e3o de cont\u00eaineres. O Kubernetes<\/strong> facilita a automa\u00e7\u00e3o de diversos processos em ambientes distribu\u00eddos, oferecendo escalabilidade, flexibilidade e controle sobre aplica\u00e7\u00f5es conteinerizadas. Com a expans\u00e3o cont\u00ednua de seu uso, \u00e9 crucial entender a terminologia que sustenta essa tecnologia. Atrav\u00e9s de defini\u00e7\u00f5es concisas, este gloss\u00e1rio busca esclarecer conceitos centrais e fornecer uma refer\u00eancia \u00fatil para profissionais que atuam na administra\u00e7\u00e3o de clusters, automa\u00e7\u00e3o de processos e desenvolvimento de aplica\u00e7\u00f5es na nuvem.<\/p>\n\n\n\n

<\/p>\n\n\n\n

Gloss\u00e1rio<\/h3>\n\n\n\n

Annotations<\/strong> – S\u00e3o pares de chave-valor usados para anexar metadados n\u00e3o identific\u00e1veis a objetos do Kubernetes<\/em>. Eles s\u00e3o comumente utilizados para armazenar informa\u00e7\u00f5es operacionais, como detalhes sobre a configura\u00e7\u00e3o de um servi\u00e7o que n\u00e3o influenciam diretamente na l\u00f3gica do Kubernetes<\/em>.<\/p>\n\n\n\n

Affinity<\/strong> – Permite que administradores definam regras de afinidade para Pods<\/em>, de modo que eles sejam preferencialmente agendados em Nodes<\/em> que possuam determinados labels<\/em>. Isso ajuda a otimizar a coloca\u00e7\u00e3o de Pods<\/em> de acordo com a localiza\u00e7\u00e3o de recursos espec\u00edficos ou pol\u00edticas de balanceamento de carga.<\/p>\n\n\n\n

Anti Affinity<\/strong> – Funciona como o inverso do Affinity<\/em>. Uma regra de anti-affinity<\/em> informa ao scheduler<\/em> que deve evitar colocar um novo Pod<\/em> em um Node<\/em> espec\u00edfico se o label<\/em> do novo Pod<\/em> corresponder ao label<\/em> de outro Pod<\/em> j\u00e1 existente nesse Node<\/em>. Isso \u00e9 \u00fatil para garantir a alta disponibilidade, evitando que m\u00faltiplos Pods<\/em> cr\u00edticos sejam alocados no mesmo Node<\/em>.<\/p>\n\n\n\n

Aggregation Layer<\/strong> – Uma camada de agrega\u00e7\u00e3o que permite estender o Kubernetes<\/em> instalando APIs adicionais. Isso \u00e9 feito atrav\u00e9s da adi\u00e7\u00e3o de servidores de API que se integram com o Kubernetes API Server<\/em>, permitindo a implementa\u00e7\u00e3o de novas funcionalidades ou a integra\u00e7\u00e3o com sistemas externos.<\/p>\n\n\n\n

Controller<\/strong> – Um Controller<\/em> \u00e9 respons\u00e1vel por garantir que o estado atual de uma aplica\u00e7\u00e3o corresponda ao estado desejado. Ele monitora continuamente os recursos do Kubernetes<\/em> e faz as mudan\u00e7as necess\u00e1rias para manter o estado especificado pelo usu\u00e1rio, como a quantidade de r\u00e9plicas de um Pod<\/em>.<\/p>\n\n\n\n

Cloud Controller Manager<\/strong> – Um componente que conecta o cluster Kubernetes<\/em> \u00e0 API do provedor de nuvem. Ele \u00e9 respons\u00e1vel por gerenciar componentes que dependem da infraestrutura de nuvem, como load balancers<\/em>, volumes de armazenamento e endere\u00e7os IP.<\/p>\n\n\n\n

Cluster<\/strong> – \u00c9 a base do Kubernetes<\/em>, onde todas as aplica\u00e7\u00f5es conteinerizadas s\u00e3o executadas. Um cluster<\/em> \u00e9 composto por um control plane<\/em> (que gerencia o estado do cluster<\/em>) e os worker nodes<\/em> (onde as aplica\u00e7\u00f5es realmente rodam).<\/p>\n\n\n\n

CronJob<\/strong> – Um CronJob<\/em> cria Jobs<\/em> em uma agenda especificada, permitindo a execu\u00e7\u00e3o de tarefas automatizadas em hor\u00e1rios predefinidos. Eles s\u00e3o \u00fateis para tarefas de manuten\u00e7\u00e3o, backup, ou qualquer tarefa repetitiva que precise ser executada em intervalos regulares.<\/p>\n\n\n\n

ConfigMap<\/strong> – Um ConfigMap<\/em> armazena dados de configura\u00e7\u00e3o para objetos usarem. Ele permite armazenar dados n\u00e3o confidenciais em pares de chave-valor, tornando f\u00e1cil a separa\u00e7\u00e3o da configura\u00e7\u00e3o da imagem cont\u00eainer.<\/p>\n\n\n\n

ClusterIP<\/strong> – Um ClusterIP<\/em> exp\u00f5e o servi\u00e7o apenas em um IP interno, tornando o servi\u00e7o acess\u00edvel apenas de dentro do cluster<\/em>. \u00c9 o tipo de servi\u00e7o padr\u00e3o no Kubernetes<\/em>.<\/p>\n\n\n\n

ClusterRole<\/strong> – Um ClusterRole<\/em> cont\u00e9m regras que representam um conjunto de permiss\u00f5es. Ele \u00e9 semelhante a um Role<\/em>, mas enquanto um Role<\/em> opera dentro de um namespace espec\u00edfico, um ClusterRole<\/em> pode ser aplicado em todo o cluster<\/em>.<\/p>\n\n\n\n

ClusterRoleBinding<\/strong> – Um RoleBinding<\/em> concede permiss\u00f5es dentro de um namespace<\/em> espec\u00edfico, enquanto um ClusterRoleBinding<\/em> concede esse acesso em todo o cluster<\/em>. Ele conecta um ClusterRole<\/em> a usu\u00e1rios, grupos ou ServiceAccounts<\/em>, efetivamente dando a eles as permiss\u00f5es definidas no ClusterRole<\/em>.<\/p>\n\n\n\n

cAdvisor<\/strong> – O cAdvisor<\/em> \u00e9 um agente de c\u00f3digo aberto integrado ao bin\u00e1rio kubelet<\/em> que monitora o uso de recursos e analisa o desempenho dos cont\u00eaineres. Ele coleta estat\u00edsticas sobre o uso de CPU, mem\u00f3ria, arquivos e rede para todos os cont\u00eaineres em execu\u00e7\u00e3o em um determinado node<\/em>.<\/p>\n\n\n\n

Cluster-admin<\/strong> – Este “superusu\u00e1rio” do Kubernetes<\/em> pode executar qualquer a\u00e7\u00e3o em qualquer recurso em um cluster<\/em>. O cluster-admin<\/em> tem permiss\u00f5es amplas e deve ser utilizado com cuidado, preferencialmente em opera\u00e7\u00f5es administrativas essenciais.<\/p>\n\n\n\n

Container Network Interface (CNI)<\/strong> – A CNI<\/em> fornece uma interface padr\u00e3o entre provedores de rede e a rede do Kubernetes<\/em>. Ela permite que diferentes plugins de rede integrem-se de forma consistente com o Kubernetes<\/em>, garantindo conectividade para os Pods<\/em> dentro do cluster<\/em>.<\/p>\n\n\n\n

Containers<\/strong> – Um container<\/em> \u00e9 uma estrutura padronizada que pode armazenar e executar qualquer aplica\u00e7\u00e3o. No Kubernetes<\/em>, containers<\/em> s\u00e3o a unidade fundamental de computa\u00e7\u00e3o, agrupados em Pods<\/em>.<\/p>\n\n\n\n

Control Plane<\/strong> – O control plane<\/em> hospeda os componentes usados para gerenciar o cluster Kubernetes<\/em>, incluindo o API server<\/em>, controller manager<\/em>, scheduler<\/em> e o banco de dados etcd<\/em>. Ele \u00e9 respons\u00e1vel por tomar decis\u00f5es sobre o estado do cluster<\/em>.<\/p>\n\n\n\n

Deployment<\/strong> – Um Deployment<\/em> \u00e9 respons\u00e1vel por criar e atualizar inst\u00e2ncias de aplica\u00e7\u00e3o, fornecendo atualiza\u00e7\u00f5es declarativas para aplica\u00e7\u00f5es usando arquivos yaml<\/em>. Ele gerencia a replica\u00e7\u00e3o e a escalabilidade de Pods<\/em>, al\u00e9m de permitir rollbacks<\/em> para vers\u00f5es anteriores.<\/p>\n\n\n\n

Desired State<\/strong> – O desired state<\/em> \u00e9 o estado declarado que voc\u00ea deseja para seu sistema no Kubernetes<\/em>. Ele indica quantas r\u00e9plicas s\u00e3o necess\u00e1rias para executar um sistema saud\u00e1vel, e o controller<\/em> trabalha continuamente para ajustar o estado atual para corresponder ao estado desejado.<\/p>\n\n\n\n

Daemon Set<\/strong> – Um DaemonSet<\/em> gerencia grupos de Pods<\/em> replicados. Todos os nodes<\/em> do Kubernetes<\/em> executam uma c\u00f3pia de um Pod<\/em>, o que permite que um daemon espec\u00edfico seja executado em cada node<\/em> do cluster<\/em>.<\/p>\n\n\n\n

Data Plane<\/strong> – O data plane<\/em> \u00e9 a camada de dados do cluster Kubernetes<\/em>, onde os dados s\u00e3o armazenados e gerenciados. Isso inclui os dados de estado dos Pods<\/em> e outros objetos do Kubernetes<\/em>.<\/p>\n\n\n\n

etcd Cluster<\/strong> – O etcd<\/em> \u00e9 o banco de dados chave\/valor que armazena o estado do cluster Kubernetes<\/em>. Ele \u00e9 cr\u00edtico para a opera\u00e7\u00e3o do cluster<\/em>, armazenando informa\u00e7\u00f5es sobre nodes<\/em>, Pods<\/em>, ConfigMaps<\/em>, secrets<\/em> e outros objetos do Kubernetes<\/em>.<\/p>\n\n\n\n

ExternalName<\/strong> – O ExternalName<\/em> atua como um proxy, permitindo redirecionar solicita\u00e7\u00f5es para um servi\u00e7o fora (ou dentro) do cluster<\/em>. Ele usa um nome DNS como destino, em vez de expor um IP diretamente.<\/p>\n\n\n\n

Helm<\/strong> – Helm<\/em> \u00e9 um gerenciador de pacotes de aplica\u00e7\u00f5es que roda em cima do Kubernetes<\/em>. Ele permite que voc\u00ea defina, instale e atualize aplica\u00e7\u00f5es Kubernetes<\/em> usando charts<\/em>, que s\u00e3o pacotes de pr\u00e9-configura\u00e7\u00f5es do Helm<\/em>.<\/p>\n\n\n\n

Heapster<\/strong> – O Heapster<\/em> \u00e9 um projeto do Kubernetes<\/em> que fornece uma solu\u00e7\u00e3o robusta de monitoramento para clusters Kubernetes<\/em>. Ele coleta m\u00e9tricas de performance e eventos dos Pods<\/em> e nodes<\/em> em tempo real, permitindo que administradores monitorem a sa\u00fade do cluster<\/em>.<\/p>\n\n\n\n

HorizontalPodAutoscaler<\/strong> – O HorizontalPodAutoscaler<\/em> altera a forma da carga de trabalho do Kubernetes<\/em> aumentando ou diminuindo automaticamente o n\u00famero de Pods<\/em> em resposta \u00e0 carga de trabalho. Ele monitora as m\u00e9tricas, como uso de CPU, para determinar quando escalar ou desescalar Pods<\/em>.<\/p>\n\n\n\n

Ingress<\/strong> – Um Ingress<\/em> \u00e9 um objeto API que gerencia o acesso externo aos servi\u00e7os em um cluster<\/em>, tipicamente usando HTTP\/HTTPS<\/em>. Ele pode fornecer balanceamento de carga, termina\u00e7\u00e3o SSL<\/em> e hospedagem virtual baseada em nome, facilitando o gerenciamento do tr\u00e1fego externo.<\/p>\n\n\n\n

Job<\/strong> – Um Job<\/em> cria um ou mais Pods<\/em> e espera que eles terminem com sucesso. Ele \u00e9 usado para tarefas que precisam ser executadas at\u00e9 a conclus\u00e3o, como processamento de dados ou tarefas de manuten\u00e7\u00e3o.<\/p>\n\n\n\n

Kube API Server<\/strong> – O Kube API server<\/em> \u00e9 respons\u00e1vel por orquestrar todas as opera\u00e7\u00f5es no cluster<\/em>. Ele atua como o gateway para o cluster<\/em>, e \u00e9 acess\u00edvel por clientes de fora do cluster<\/em>, integrando com a CLI<\/em> e GUI<\/em> do Kubernetes<\/em>.<\/p>\n\n\n\n

Kube Controller Manager<\/strong> – O Kube Controller Manager<\/em> \u00e9 o motor que executa os loops de controle principais, criando Pods<\/em> e monitorando o estado do cluster<\/em>. Ele gerencia os controllers<\/em> do Kubernetes<\/em>, como o ReplicationController<\/em> e o Job Controller<\/em>.<\/p>\n\n\n\n

Kubelet<\/strong> – O Kubelet<\/em> conecta o Master Node<\/em> ao Worker Node<\/em> e garante que Pods<\/em> e seus containers<\/em> estejam saud\u00e1veis e em execu\u00e7\u00e3o no estado desejado. Ele \u00e9 respons\u00e1vel por aplicar as instru\u00e7\u00f5es do control plane<\/em> no node<\/em>.<\/p>\n\n\n\n

Kube Proxy<\/strong> – O Kube Proxy<\/em> \u00e9 usado para subnetting e expor servi\u00e7os para o mundo externo. Ele garante que o tr\u00e1fego de rede seja roteado corretamente para os Pods<\/em> dentro do cluster<\/em> e entre os nodes<\/em>.<\/p>\n\n\n\n

Kubectl<\/strong> – O kubectl<\/em> \u00e9 uma ferramenta de linha de comando que interage com o kube-apiserver<\/em> e envia comandos para o master node<\/em>. Cada comando \u00e9 convertido em uma chamada API, permitindo o gerenciamento de recursos Kubernetes<\/em> atrav\u00e9s da CLI<\/em>.<\/p>\n\n\n\n

Kubernetes API<\/strong> – A Kubernetes API<\/em> \u00e9 o n\u00facleo de funcionamento do Kubernetes<\/em>. Ela permite que todos os componentes do Kubernetes<\/em> e aplica\u00e7\u00f5es externas interajam com o cluster<\/em>, armazenando informa\u00e7\u00f5es sobre o estado do cluster<\/em> e permitindo a cria\u00e7\u00e3o, atualiza\u00e7\u00e3o e dele\u00e7\u00e3o de objetos.<\/p>\n\n\n\n

Kubeadm<\/strong> – O Kubeadm<\/em> inicializa um cluster Kubernetes<\/em>. Ele foi projetado para ser uma maneira simples para novos usu\u00e1rios criarem clusters<\/em>, automatizando grande parte do processo de configura\u00e7\u00e3o inicial.<\/p>\n\n\n\n
\n\t
\n<\/a>\n\n\n\n

Label<\/strong> – Labels<\/em> s\u00e3o pares de chave\/valor que s\u00e3o anexados a objetos do Kubernetes<\/em>. Eles s\u00e3o usados para organizar e selecionar subconjuntos de objetos, como Pods<\/em> ou Nodes<\/em>, permitindo opera\u00e7\u00f5es baseadas em grupos de recursos.<\/p>\n\n\n\n

Liveness Probe<\/strong> – A liveness probe<\/em> determina se as aplica\u00e7\u00f5es em execu\u00e7\u00e3o dentro dos containers<\/em> est\u00e3o operacionais. Se a liveness probe<\/em> falhar, o Kubelet<\/em> reiniciar\u00e1 o container<\/em> para restaurar sua funcionalidade.<\/p>\n\n\n\n

LoadBalancer<\/strong> – Um LoadBalancer<\/em> exp\u00f5e o servi\u00e7o com um balanceador de carga do provedor de nuvem, distribuindo o tr\u00e1fego de entrada entre os Pods<\/em> associados ao servi\u00e7o.<\/p>\n\n\n\n

Minikube<\/strong> – O Minikube<\/em> \u00e9 uma vers\u00e3o leve do Kubernetes<\/em>, muito mais f\u00e1cil de usar localmente. Ele permite que desenvolvedores experimentem e desenvolvam em um ambiente Kubernetes<\/em> em uma m\u00e1quina local.<\/p>\n\n\n\n

Manifest<\/strong> – Um manifest<\/em> \u00e9 um arquivo de configura\u00e7\u00e3o JSON<\/em> ou YAML<\/em> que descreve os objetos do Kubernetes<\/em> e suas vers\u00f5es. Ele \u00e9 usado para definir e configurar os recursos que ser\u00e3o criados no cluster<\/em>.<\/p>\n\n\n\n

Master Node\/control plane<\/strong> – O master node<\/em> ou control plane<\/em> coordena o cluster<\/em>. Ele cria o cluster<\/em> e hospeda todos os componentes e servi\u00e7os que gerenciam, planejam, agendam e monitoram todos os worker nodes<\/em>.<\/p>\n\n\n\n

Node Controller<\/strong> – O Node Controller<\/em> gerencia v\u00e1rios aspectos dos nodes<\/em> em um cluster Kubernetes<\/em>. Ele \u00e9 respons\u00e1vel por detectar a sa\u00fade dos nodes<\/em>, garantindo que estejam funcionando corretamente, e por tomar a\u00e7\u00f5es corretivas se um node<\/em> ficar indispon\u00edvel.<\/p>\n\n\n\n

Node<\/strong> – Um node<\/em> pode ser uma m\u00e1quina virtual ou f\u00edsica que faz parte de um cluster Kubernetes<\/em>. Ele hospeda Pods<\/em> e executa as aplica\u00e7\u00f5es, conectando-se ao control plane<\/em> para receber instru\u00e7\u00f5es.<\/p>\n\n\n\n

Node-Proxy<\/strong> – O Node-Proxy<\/em> \u00e9 um servi\u00e7o de proxy que \u00e9 executado em cada worker node<\/em>. Ele lida com o subnetting individual do host e exp\u00f5e servi\u00e7os para o mundo externo, facilitando a comunica\u00e7\u00e3o de rede dentro e fora do cluster<\/em>.<\/p>\n\n\n\n

Namespace<\/strong> – Um namespace<\/em> \u00e9 uma forma de organizar clusters<\/em> em sub-clusters<\/em> virtuais, logicamente separados uns dos outros. Namespaces<\/em> permitem que recursos sejam isolados entre equipes ou projetos, enquanto ainda permitem a comunica\u00e7\u00e3o controlada entre eles.<\/p>\n\n\n\n

Network Policy<\/strong> – Uma network policy<\/em> \u00e9 uma especifica\u00e7\u00e3o de como grupos de Pods<\/em> podem se comunicar entre si e com outros pontos finais da rede. Ela define regras de entrada e sa\u00edda para Pods<\/em>, ajudando a controlar o tr\u00e1fego dentro de um cluster<\/em>.<\/p>\n\n\n\n

NodePort<\/strong> – Um NodePort<\/em> exp\u00f5e o servi\u00e7o no IP de cada node<\/em> em uma porta espec\u00edfica. Ele permite o acesso ao servi\u00e7o a partir de fora do cluster<\/em>, direcionando o tr\u00e1fego para os Pods<\/em> associados ao servi\u00e7o.<\/p>\n\n\n\n

Operators<\/strong> – Operators<\/em> s\u00e3o implantados em um cluster Kubernetes<\/em> e permitem escrever uma aplica\u00e7\u00e3o para gerenciar completamente outra. Eles automatizam a opera\u00e7\u00e3o de aplica\u00e7\u00f5es complexas, capturando o conhecimento de como instal\u00e1-las, configur\u00e1-las, atualiz\u00e1-las e repar\u00e1-las.<\/p>\n\n\n\n

Pod<\/strong> – O Pod<\/em> \u00e9 o menor e mais b\u00e1sico objeto execut\u00e1vel no Kubernetes<\/em>. Um Pod<\/em> \u00e9 um grupo de um ou mais containers<\/em> de aplica\u00e7\u00e3o, que compartilham recursos como volumes, endere\u00e7o IP, containers init<\/em> e sidecars<\/em>.<\/p>\n\n\n\n

Persistent Volume<\/strong> – Um Persistent Volume<\/em> \u00e9 o volume “f\u00edsico” na m\u00e1quina host que armazena dados persistentes. Ele existe independentemente dos Pods<\/em> que o utilizam, e pode ser montado em diferentes Pods<\/em> ao longo do tempo.<\/p>\n\n\n\n

Persistent Volume Claim<\/strong> – Um Persistent Volume Claim (PVC)<\/em> \u00e9 uma solicita\u00e7\u00e3o de armazenamento feita por um usu\u00e1rio. Ele \u00e9 semelhante a um Pod<\/em>, mas em vez de definir um cont\u00eainer, ele define o armazenamento que precisa ser alocado a um Pod<\/em>.<\/p>\n\n\n\n

PodDisruptionBudget<\/strong> – O PodDisruptionBudget<\/em> permite limitar o n\u00famero de Pods<\/em> que s\u00e3o interrompidos durante atualiza\u00e7\u00f5es ou outros eventos planejados. Isso garante maior disponibilidade, ao mesmo tempo em que permite que o administrador do cluster<\/em> gerencie os nodes<\/em> do cluster<\/em>.<\/p>\n\n\n\n

Pod Preset<\/strong> – Um PodPreset<\/em> \u00e9 um objeto API que automatiza a adi\u00e7\u00e3o de informa\u00e7\u00f5es aos Pods<\/em> \u00e0 medida que s\u00e3o criados. Ele pode ser usado para injetar configura\u00e7\u00f5es, segredos ou volumes em Pods<\/em>, sem precisar alterar os manifests originais.<\/p>\n\n\n\n\n \n<\/a>\n\n\n\n

Role<\/strong> – Um Role<\/em> \u00e9 um conjunto de permiss\u00f5es dentro de um namespace<\/em> espec\u00edfico. Quando voc\u00ea cria um Role<\/em>, voc\u00ea deve especificar o namespace<\/em> ao qual ele pertence, limitando suas permiss\u00f5es a esse escopo.<\/p>\n\n\n\n

Replica Set<\/strong> – O Replica Set<\/em> \u00e9 usado para manter um conjunto est\u00e1vel de Pods<\/em> replicados em execu\u00e7\u00e3o dentro de um cluster<\/em> a qualquer momento. Ele garante que um n\u00famero especificado de Pods<\/em> esteja sempre em execu\u00e7\u00e3o, com base no modelo fornecido.<\/p>\n\n\n\n

RoleBinding<\/strong> – O RoleBinding<\/em> concede as permiss\u00f5es definidas em um Role<\/em> a algum grupo de Users<\/em> ou ServiceAccounts<\/em>. Ele cont\u00e9m uma lista de sujeitos (Users<\/em>, Groups<\/em> ou ServiceAccounts<\/em>), e uma refer\u00eancia ao Role<\/em> sendo concedido.<\/p>\n\n\n\n

Replication Controller<\/strong> – O Replication Controller<\/em> garante que o n\u00famero especificado de r\u00e9plicas de Pod<\/em> esteja em execu\u00e7\u00e3o a qualquer momento. Ele monitora os Pods<\/em> existentes e cria novos se necess\u00e1rio para manter o n\u00famero desejado de r\u00e9plicas.<\/p>\n\n\n\n

RBAC<\/strong> – O RBAC (Role-Based Access Control)<\/em> permite que os administradores do Kubernetes<\/em> configurem pol\u00edticas de acesso atrav\u00e9s da API. Ele permite atribuir diferentes fun\u00e7\u00f5es aos usu\u00e1rios, o que lhes d\u00e1 permiss\u00f5es variadas dentro do cluster<\/em>.<\/p>\n\n\n\n

Readiness Probe<\/strong> – O Kubelet<\/em> usa readiness probes<\/em> para saber quando um container<\/em> est\u00e1 pronto para come\u00e7ar a aceitar tr\u00e1fego. Ele ajuda a evitar que o tr\u00e1fego seja direcionado a containers<\/em> que ainda est\u00e3o iniciando ou que n\u00e3o est\u00e3o prontos para lidar com solicita\u00e7\u00f5es.<\/p>\n\n\n\n

Service<\/strong> – Um Service<\/em> permite acessar dinamicamente um grupo de Pods<\/em> r\u00e9plicas via IP e Porta da nossa rede, e definir um nome para o servi\u00e7o. Ele abstrai o acesso aos Pods<\/em>, oferecendo um \u00fanico ponto de entrada, independentemente de quantos Pods<\/em> existam.<\/p>\n\n\n\n

StatefulSet<\/strong> – Um StatefulSet<\/em> \u00e9 adaptado para gerenciar Pods<\/em> que devem persistir ou manter estado. Diferentemente de um ReplicaSet<\/em>, ele garante que os Pods<\/em> sejam criados e exclu\u00eddos em ordem espec\u00edfica, mantendo uma identidade est\u00e1vel.<\/p>\n\n\n\n

Secret<\/strong> – Kubernetes Secrets<\/em> podem armazenar informa\u00e7\u00f5es sens\u00edveis, como senhas, chaves SSH<\/em>, e chaves API. Esses segredos s\u00e3o acess\u00edveis a partir de qualquer Pod<\/em> no mesmo cluster<\/em>, mas de forma segura e controlada.<\/p>\n\n\n\n

Selector<\/strong> – O selector<\/em> permite selecionar recursos do Kubernetes<\/em> com base no valor dos labels<\/em>. Ele \u00e9 usado em objetos como ReplicaSets<\/em> e Services<\/em> para definir quais Pods<\/em> devem ser gerenciados ou acessados.<\/p>\n\n\n\n

Storage Class<\/strong> – As storage classes<\/em> s\u00e3o usadas para definir os diferentes tipos de armazenamento dispon\u00edveis no cluster<\/em>. Elas permitem a cria\u00e7\u00e3o din\u00e2mica de volumes com diferentes caracter\u00edsticas de desempenho e durabilidade.<\/p>\n\n\n\n

Startup Probe<\/strong> – A startup probe<\/em> verifica se a aplica\u00e7\u00e3o dentro de um container<\/em> foi iniciada corretamente. Se um container<\/em> falhar na startup probe<\/em>, ele \u00e9 encerrado e segue a restartPolicy<\/em> do Pod<\/em>.<\/p>\n\n\n\n

ServiceAccount<\/strong> – Uma ServiceAccount<\/em> fornece uma identidade para processos que s\u00e3o executados em um Pod<\/em>. Isso permite que esses processos acessem a API do Kubernetes<\/em> e outros servi\u00e7os com um conjunto espec\u00edfico de permiss\u00f5es.<\/p>\n\n\n\n

Scheduler (kube-scheduler)<\/strong> – O kube-scheduler<\/em> identifica o node<\/em> certo para colocar um container<\/em> com base em limita\u00e7\u00f5es de recursos. Ele \u00e9 respons\u00e1vel por alocar os Pods<\/em> aos nodes<\/em> do cluster<\/em>.<\/p>\n\n\n\n

Taints<\/strong> – Taints<\/em> s\u00e3o usados para garantir que os Pods<\/em> n\u00e3o sejam agendados em determinados nodes<\/em> a menos que tenham uma toler\u00e2ncia espec\u00edfica. Eles ajudam a isolar nodes<\/em> que n\u00e3o devem ser utilizados para workloads comuns.<\/p>\n\n\n\n

Tolerations<\/strong> – Tolerations<\/em> permitem que os Pods<\/em> sejam agendados em nodes<\/em> que t\u00eam taints<\/em>. Eles neutralizam os taints<\/em> em um node<\/em>, permitindo que um Pod<\/em> espec\u00edfico seja alocado ali, mesmo que o node<\/em> seja marcado como indispon\u00edvel para outros Pods<\/em>.<\/p>\n\n\n\n

Volume<\/strong> – Um Volume<\/em> \u00e9 um diret\u00f3rio acess\u00edvel pelos containers<\/em> em um Pod<\/em>. Ele pode persistir dados que sobrevivem ao ciclo de vida de um container<\/em> e pode ser montado em v\u00e1rios containers<\/em> simultaneamente.<\/p>\n\n\n\n

VerticalPodAutoscaler<\/strong> – O VerticalPodAutoscaler<\/em> ajusta automaticamente os recursos solicitados (CPU<\/em> e mem\u00f3ria) de um Pod<\/em> com base no uso observado, sem a necessidade de reiniciar o Pod<\/em>.<\/p>\n\n\n\n

Workloads<\/strong> – Workloads<\/em> referem-se \u00e0s aplica\u00e7\u00f5es que est\u00e3o sendo executadas em Pods<\/em>. No Kubernetes<\/em>, os objetos de workload<\/em> incluem Deployments<\/em>, ReplicaSets<\/em>, StatefulSets<\/em>, DaemonSets<\/em>, e Jobs<\/em>, cada um com seu pr\u00f3prio comportamento de gerenciamento e replica\u00e7\u00e3o.<\/p>\n\n\n\n

Workloads Controller<\/strong> – O Workloads Controller<\/em> gerencia a implanta\u00e7\u00e3o de Pods<\/em> dentro do Kubernetes<\/em>. Ele garante que o n\u00famero correto de Pods<\/em> esteja sempre em execu\u00e7\u00e3o e que eles estejam corretamente distribu\u00eddos entre os nodes<\/em> do cluster<\/em>.<\/p>\n\n\n\n

YAML<\/strong> – YAML<\/em> \u00e9 uma linguagem de serializa\u00e7\u00e3o de dados frequentemente usada para definir configura\u00e7\u00f5es no Kubernetes<\/em>. Arquivos YAML<\/em> s\u00e3o leg\u00edveis por humanos e podem ser usados para descrever objetos como Pods<\/em>, Services<\/em>, e Deployments<\/em> no Kubernetes<\/em>.<\/p>\n\n\n\n

<\/p>\n\n\n\n

Conclus\u00e3o<\/h3>\n\n\n\n

O Kubernetes<\/strong> se destaca como uma ferramenta poderosa para a automa\u00e7\u00e3o de aplica\u00e7\u00f5es conteinerizadas, e a compreens\u00e3o de sua terminologia \u00e9 essencial para o uso eficaz da plataforma. Este gloss\u00e1rio proporciona uma vis\u00e3o abrangente dos principais conceitos e funcionalidades que permitem a flexibilidade, o controle e a escalabilidade dos ambientes Kubernetes<\/strong>. Dominar esses termos facilita o desenvolvimento e a opera\u00e7\u00e3o de solu\u00e7\u00f5es baseadas em cont\u00eaineres, promovendo a integra\u00e7\u00e3o cont\u00ednua e a entrega \u00e1gil de software. Com este conhecimento, os profissionais podem navegar com mais confian\u00e7a e efic\u00e1cia no ecossistema Kubernetes<\/strong>, aproveitando ao m\u00e1ximo suas funcionalidades.<\/p>\n\n\n\n

Treinamentos relacionados com essa postagem<\/h2>\n\n\n \n<\/a>\n
\n\t
\n<\/a>\n\n \n<\/a>\n\n \n<\/a>\n\n \n<\/a>\n\n \n<\/a>\n\n \n<\/a>\n\n \n<\/a>\n\n \n<\/a>\n\n \n<\/a>\n
\n<\/a>\n","protected":false},"excerpt":{"rendered":"

Introdu\u00e7\u00e3o Este gloss\u00e1rio re\u00fane uma vasta gama de termos essenciais do universo Kubernetes, uma plataforma de c\u00f3digo aberto amplamente adotada para a orquestra\u00e7\u00e3o de cont\u00eaineres. O Kubernetes facilita a automa\u00e7\u00e3o de diversos processos em ambientes distribu\u00eddos, oferecendo escalabilidade, flexibilidade e controle sobre aplica\u00e7\u00f5es conteinerizadas. Com a expans\u00e3o cont\u00ednua de seu uso, \u00e9 crucial entender a […]<\/p>\n","protected":false},"author":1,"featured_media":1638,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[289,27,262,291,290],"tags":[265,151,264,293,292],"_links":{"self":[{"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/posts\/1631"}],"collection":[{"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/comments?post=1631"}],"version-history":[{"count":5,"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/posts\/1631\/revisions"}],"predecessor-version":[{"id":1718,"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/posts\/1631\/revisions\/1718"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/media\/1638"}],"wp:attachment":[{"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/media?parent=1631"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/categories?post=1631"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/tags?post=1631"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}