Introdução a Kubernetes
O Kubernetes é um sistema de orquestração de contêineres open-source que automatiza a implantação, escalonamento e gerenciamento de aplicativos em contêineres. O Kubernetes também é conhecido como k8s (pronuncia-se Kate's), pois existem 8 caracteres entre k e s.
Foi originalmente desenvolvido pela Google mas com seu lançamento v1.0 em julho de 2015, passou a ser mantido pela Cloud Native Computing Foundation (CNCF) que é uma das maiores subfundações da Linux Foundation. As novas versões do Kubernetes são lançadas em ciclos, onde cada ciclo possui 4 meses.
Kubernetes vem da palavra grega κυβερνήτης, que significa timoneiro ou piloto de navio. Com esta analogia em mente, podemos pensar no Kubernetes como o piloto de um navio de contêineres.
O Kubernetes por sí só não possui a capacidade de criar containers, por isso precisamos usar um container runtime. Um container runtime é um software que gerencia o ciclo de vida de containers em um sistema operacional. Ele é responsável por criar, executar, parar e remover containers, além de gerenciar seus recursos (CPU, memória, armazenamento, rede). O Kubernetes, por ser uma plataforma de orquestração de containers, depende de um container runtime para executar os pods que compõem suas aplicações. O container runtime fornece a infraestrutura necessária para que os pods possam ser executados de forma isolada, segura e eficiente.
Falaremos disso mais adiante, mas por hora, vejamos alguns dos containers runtime mais usados:
Docker: O Docker é o container runtime mais popular e amplamente utilizado. Ele é fácil de usar e oferece uma ampla gama de recursos.
containerd: O containerd é um container runtime leve e modular que é usado como base para outros container runtimes, como o CRI-O.
CRI-O: O CRI-O é um container runtime otimizado para o Kubernetes. Ele é compatível com a interface CRI (Container Runtime Interface), que é usada pelo Kubernetes para interagir com o container runtime.
Rocket: O Rocket é um container runtime leve e seguro que é escrito em Go. Ele é uma alternativa ao Docker que oferece algumas vantagens em termos de desempenho e segurança.
Certificações Kubernetes
Existem várias certificações para o Kubernetes com duas empresas ofertando essas certificações, são elas: Cloud Native Computing Foundation (CNCF) e Linux Foundation (LF). A tabela abaixo mostra um resumo de cada certificação:
| Nome | Descrição |
|---|---|
| CKA - Certified Kubernetes Administrator | Sendo a certificação de Kubernetes, tem como foco a administração do Kubernetes, validando a capacidade de administrar clusters Kubernetes em produção de forma independente. |
| CKAD - Certified Kubernetes Application Developer | É a segunda certificação tem como foco os desenvolvedores. O objetivo é validar a capacidade de desenvolver e implementar aplicações em containers no Kubernetes. |
| CKS - Certified Kubernetes Security Specialist | A terceira certificação tem como foco a segurança de clusters e aplicações Kubernetes. |
| KCNA - Kubernetes and Cloud Native Associate | É uma certificação de nível associado. O foco são indivíduos interessados em obter conhecimento básico sobre Kubernetes e o ecossistema nativo da nuvem. |
| KCSA - Kubernetes and Cloud Native Security Associate | Também é uma certificação de nível associado. O foco são indivíduos interessados em aprender os fundamentos da segurança de clusters Kubernetes. |
A Linux Foundation muitas vezes vende um pacote que tem um curso preparatório mais o exame, muitas vezes o valor acaba compensando.
Arquitetura do Kubernetes
A arquitetura do Kubernetes é baseada no conceito de clusters, onde cada node pode ser composto por um ou mais contêineres, agrupados em uma entidade chamada POD. Os nodes no Kubernetes são máquinas físicas ou virtuais que servem como base para a execução de contêineres. Eles formam a infraestrutura central de um cluster Kubernetes.
A imagem abaixo representa uma Topologia do Cluster Kubernetes e alguns componentes. Fonte: Elaborado pela Linux Foundation.
Control Plane
No Kubernetes, o Control Plane é o cérebro da operação, responsável por gerenciar o cluster como um todo e garantir que ele funcione de forma suave e eficiente. Para se comunicar com o cluster Kubernetes, os usuários enviam requisições ao Control Plane por meio de um Command Line Interface (CLI), Web User-Interface (Web UI) ou uma Application Programming Interface (API).
O node de controle, onde os componentes do Control Plane são executados, é frequentemente referido como o "node mestre" (master node) do cluster Kubernetes. Este node gerencia e coordena as operações de todo o cluster, tomando decisões sobre a alocação de recursos, agendamento de pods, monitoramento de estado e muito mais. Em resumo, é o node (node) onde o Control Plane está atuando para gerenciamento de todos os outros nodes (podemos ter mais de um master node).
É importante manter o control plane em funcionamento a todo custo. Perder o control plane pode causar tempo de inatividade, provocando interrupções no serviço para os clientes. Para garantir a tolerância a falhas do control plane, réplicas dos nodes do control plane podem ser adicionadas ao cluster e configuradas no modo de Alta Disponibilidade (HA). Embora apenas um dos nodes do control plane seja dedicado a gerenciar ativamente o cluster, os componentes do control plane permanecem sincronizados entre as réplicas dos nodes do control plane. Esse tipo de configuração adiciona resiliência ao control plane do cluster, caso o node do control plane ativo falhe.
Um node do control plane executa os seguintes componentes e agentes essenciais do control plane: servidor API, agendador, gerenciadores de controlador e armazenamento de dados de valor-chave. Além disso, o node do control plane executa: Container Runtime, agente do node (kubelet), proxy (kube-proxy), complementos opcionais para observabilidade, como painel, monitoramento em nível de cluster e registro em log.
O acesso a API do master node pode ser feito a partir de algumas ferramentas, o Kubectl é de longe a ferramenta mais comum e produtiva para interagir com o Kubernetes, pois permite aos usuários enviar comandos diretamente para o node mestre do cluster e realizar diversas operações de gerenciamento. Além do mais, o kubectl pode ser instalado em qualquer sistema operacional e atua como cliente do master node do cluster Kubernetes.
Normalmente um node que atua como Control Plane não exerce a função de Worker node, ou seja, ele não mantêm Pods e containers locais, servindo apenas para o gerenciamento do cluster. Isso garante a escalabilidade, segurança e resiliência do cluster.
Um node do Control Plane executa os seguintes componentes e agentes essenciais do Control Plane: API server, scheduler, controller managers, armazenamento de dados de valor-chave. Além disso, o node do Control Plane executa: container runtime, node agent (kubelet), proxy (kube-proxy), complementos opcionais para observabilidade, como painel, monitoramento em nível de cluster e registro em log.
Abaixo segue uma descrição mais detalhada de cada componente.
API server
Todas as tarefas administrativas são coordenadas pelo kube-apiserver, um componente central do Control Plane executado no node do Control Plane. Ele recebe chamadas RESTful de usuários, administradores e agentes externos, valida e processa essas chamadas. Durante o processamento, lê e atualiza o estado do cluster no armazenamento de chave-valor.
É o único componente do Control Plane que interage diretamente com o armazenamento, agindo como uma interface para outros componentes do Control Plane. O kube-apiserver é altamente configurável e suporta escalonamento horizontal, além de permitir a adição de servidores API secundários personalizados para roteamento de chamadas RESTful com base em regras definidas.
Scheduler
O kube-scheduler é responsável por decidir em qual node do cluster Kubernetes cada novo objeto de carga de trabalho, como um pod que contém um ou mais contêineres, será executado.
Durante o processo de escalonamento, decisões são tomadas com base no estado atual do cluster Kubernetes e nos requisitos do novo objeto de carga de trabalho. O scheduler obtém do armazenamento de chave-valor, via API Server, dados de uso de recursos para cada node de trabalho no cluster. Ele também recebe do API Server os requisitos do novo objeto de carga de trabalho que fazem parte dos seus dados de configuração.
Os requisitos podem incluir restrições definidas por usuários e operadores, como agendar trabalho em um node rotulado com o par chave-valor para disk==ssd. O scheduler também leva em consideração requisitos de Qualidade de Serviço (QoS), localidade de dados, afinidade, anti-afinidade, taints, toleration, topologia do cluster, etc. Uma vez que todos os dados do cluster estão disponíveis, o algoritmo de escalonamento filtra os nodes com predicados para isolar os possíveis candidatos a nodes, que então são classificados com prioridades para selecionar o node que atende a todos os requisitos para hospedar a nova carga de trabalho. O resultado do processo de decisão é comunicado de volta ao API Server, que então delega o deployment da carga de trabalho com outros agentes do Control Plane.
O scheduler é altamente configurável e personalizável através de políticas, plugins e perfis de escalonamento. Schedulers personalizados adicionais também são suportados, então os dados de configuração do objeto devem incluir o nome do scheduler personalizado esperado para tomar a decisão de escalonamento para aquele objeto específico; se nenhum dado desse tipo estiver incluído, o scheduler padrão é selecionado.
Um scheduler é extremamente importante e complexo em um cluster Kubernetes com vários nodes, enquanto em um cluster Kubernetes de um único node, possivelmente usado para propósitos de aprendizado e desenvolvimento, o trabalho do scheduler é bastante simples.
Controller managers
Os gerenciadores de controladores (controller manager) são componentes do node do Control Plane que executam processos controladores ou operadores para regular o estado do cluster Kubernetes. Os controladores são processos de loop de observação que funcionam continuamente, comparando o estado desejado do cluster (fornecido pelos dados de configuração dos objetos) com seu estado atual (obtido do armazenamento de chave-valor via API Server). Em caso de diferença, são tomadas ações corretivas no cluster até que seu estado atual corresponda ao estado desejado.
O kube-controller-manager executa controladores ou operadores responsáveis por agir quando os nodes ficam indisponíveis, garantindo que a contagem de pods de contêineres esteja conforme o esperado, criando endpoints, contas de serviço e tokens de acesso à API.
O cloud-controller-manager executa controladores ou operadores responsáveis por interagir com a infraestrutura subjacente de um provedor de nuvem quando os nodes ficam indisponíveis, gerenciando volumes de armazenamento quando fornecidos por um serviço em nuvem e gerenciando balanceamento de carga e roteamento.
Etcd
O etcd é um componente de armazenamento de dados chave-valor distribuído e fortemente consistente, usado para persistir o estado de um cluster Kubernetes. Novos dados são gravados no armazenamento de dados apenas por meio de apêndice, nunca substituindo os dados existentes. Dados obsoletos são periodicamente compactados para minimizar o tamanho do armazenamento de dados.
O etcd é escrito na linguagem de programação Go. No Kubernetes, além de armazenar o estado do cluster, o etcd também é usado para armazenar detalhes de configuração como sub-redes, ConfigMaps, Secrets, etc.
Entre todos os componentes do Control Plane, apenas o API Server é capaz de se comunicar com o armazenamento de dados etcd. A ferramenta de gerenciamento CLI do etcd é o etcdctl, ele fornece capacidades de salvar e restaurar snapshot, o que é especialmente útil para um único cluster Kubernetes com uma instância etcd (comum em ambientes de desenvolvimento e aprendizado). No entanto, em ambientes de Stage e Produção, é extremamente importante replicar os armazenamentos de dados no modo HA, para a resiliência dos dados de configuração do cluster.
Algumas ferramentas de inicialização de cluster Kubernetes, como o kubeadm, por padrão, provisionam nodes de Control Plane etcd empilhados, onde o armazenamento de dados são executados juntos e compartilham recursos com os outros componentes do Control Plane no mesmo node de Control Plane.
A imagem abaixo representa uma Topologia etcd empilhada. Fonte: Elaborado pelo kubernetes.io.
Os pré-requisitos dependem de qual topologia você selecionou para o Control Plane do cluster:
Três ou mais máquinas que atendem aos requisitos mínimos do kubeadm para os nodes do Control Plane. Ter um número ímpar de nodes do Control Plane pode ajudar na seleção do líder no caso de falha da máquina ou da zona.
- Incluindo um Container Runtime, já configurado e funcionando.
Três ou mais máquinas que atendam aos requisitos mínimos do kubeadm para os Workers.
- Incluindo um Container Runtime, já configurado e funcionando.
Conectividade de rede total entre todas as máquinas do cluster (rede pública ou privada).
Privilégios de superusuário em todas as máquinas usando sudo.
- Você pode usar uma ferramenta diferente.
Acesso SSH de um dispositivo para todos os nodes do sistema.
kubeadm e kubelet já instalados em todas as máquinas.
Topologia etcd externa
Para isolamento do armazenamento de dados dos componentes do Control Plane, o processo de inicialização pode ser configurado para uma topologia externa do etcd, onde o armazenamento de dados é provisionado em um host separado dedicado, reduzindo assim as chances de uma falha do etcd.
A imagem abaixo representa uma Topologia etcd externa. Fonte: Elaborado pela Linux Foundation.
As topologias empilhadas e externas do etcd suportam configurações de alta disponibilidade (HA). O etcd é baseado no Algoritmo de Consenso Raft que permite que uma coleção de máquinas funcione como um grupo coerente que pode sobreviver às falhas de alguns de seus membros. A qualquer momento, um dos nodes do grupo será o líder e os demais serão os seguidores. O etcd lida normalmente com as eleições de líderes e pode tolerar falhas de nodes, incluindo falhas de nodes líderes. Qualquer node pode ser tratado como líder.
Tenha em mente, entretanto, que a hierarquia líder/seguidores é distinta da hierarquia primária/secundária, o que significa que nenhum node é favorecido para a função de líder e nenhum node supera outros nodes. Um líder permanecerá ativo até falhar, quando ele falha, um novo líder é eleito pelo grupo de seguidores.
Os pré-requisitos dependem de qual topologia você selecionou para o Control Plane do cluster:
Três ou mais máquinas que atendem aos requisitos mínimos do kubeadm para os nodes do Control Plane. Ter um número ímpar de nodes do Control Plane pode ajudar na seleção do líder no caso de falha da máquina ou da zona.
- Incluindo um Container Runtime, já configurado e funcionando.
Três ou mais máquinas que atendam aos requisitos mínimos do kubeadm para os Workers.
- Incluindo um Container Runtime, já configurado e funcionando.
Conectividade de rede total entre todas as máquinas do cluster (rede pública ou privada).
Privilégios de superusuário em todas as máquinas usando sudo.
- Você pode usar uma ferramenta diferente.
Acesso SSH de um dispositivo para todos os nodes do sistema.
kubeadm e kubelet já instalados em todas as máquinas.
Três ou mais máquinas adicionais, que se tornarão membros do cluster etcd. Ter um número ímpar de membros no cluster etcd é um requisito para atingir o quórum de votação ideal.
- Essas máquinas novamente precisam ter o kubeadm e o kubelet instalados.
- Essas máquinas também requerem um Container Runtime, que já está configurado e funcionando.
Worker Node
Um node de trabalho (Worker Node) tem a função de executar as cargas de trabalho, ou seja, é onde os pods e os containers serão executados. No Kubernetes, os contêineres são encapsulados em Pods, controlados pelos agentes do Control Plane do cluster em execução. Os pods são agendados em worker node, que fornecem os recursos necessários de computação como: memória, armazenamento para serem executados e redes para se comunicarem entre si e com o mundo exterior.
Um Pod é a menor unidade de trabalho de agendamento no Kubernetes. É uma coleção lógica de um ou mais contêineres agendados juntos, e a coleção pode ser iniciada, interrompida ou reprogramada como uma única unidade de trabalho. Além disso, em um cluster Kubernetes com vários workers, o tráfego de rede entre os usuários clientes e os aplicativos em contêineres implantados nos pods é tratado diretamente pelos worker node e não é roteado por meio do node do Control Plane.
Container runtime
Embora o Kubernetes seja descrito como um "motor de orquestração de contêineres", ele não possui a capacidade de lidar e executar diretamente contêineres. Para gerenciar o ciclo de vida de um contêiner, o Kubernetes requer um Container Runtime no node onde um Pod e seus contêineres serão agendados. Um Container Runtime é necessário em cada node de um cluster Kubernetes, tanto do Control Plane quanto dos worker node. A recomendação é executar os componentes do Control Plane do Kubernetes como contêineres, daí a necessidade de um runtime nos nodes do Control Plane. O Kubernetes suporta vários Container Runtime:
- CRI-O: Um Container Runtime leve para Kubernetes, que suporta registros de imagens quay.io e Docker Hub.
- containerd: Um Container Runtime simples, robusto e portátil.
- Docker Engine: Uma plataforma de contêineres popular e complexa que usa containerd como Container Runtime.
- Mirantis Container Runtime: Anteriormente conhecido como Docker Enterprise Edition.
Node agent - kubelet
O kubelet é um agente que roda em cada node, tanto do Control Plane quanto dos worker node, e se comunica com o Control Plane. Ele recebe definições de Pods, principalmente do API Server, e interage com o Container Runtime no node para executar os contêineres associados ao Pod. Ele também monitora a saúde e os recursos dos Pods que executam contêineres.
O kubelet se conecta aos tempos de execução de contêineres por meio de uma interface baseada em plugins - a Interface de Tempo de Execução de Contêineres (CRI). A CRI consiste em protocol buffers, API gRPC, bibliotecas e especificações e ferramentas adicionais. Para se conectar a tempos de execução de contêineres intercambiáveis, o kubelet usa um CRI shim, um aplicativo que fornece uma camada de abstração clara entre o kubelet e o Container Runtime.
A imagem abaixo representa o Container Runtime Interface. Fonte: Elaborado por blog.kubernetes.io.
Conforme mostrado na figura acima, o kubelet atuando como cliente grpc se conecta ao shim CRI atuando como servidor grpc para realizar operações de contêiner e imagem. O CRI implementa dois serviços: ImageService e RuntimeService. O ImageService é responsável por todas as operações relacionadas à imagem, enquanto o RuntimeService é responsável por todas as operações relacionadas ao pod e ao contêiner.
kubelet - CRI shims
Originalmente, o agente kubelet suportava apenas alguns tempos de execução de contêiner, primeiro o Docker Engine seguido pelo rkt, por meio de um modelo de interface exclusivo integrado diretamente no código-fonte do kubelet. No entanto, essa abordagem não deveria durar para sempre, embora fosse especialmente benéfica para o Docker.
Com o tempo, o Kubernetes começou a migrar para uma abordagem padronizada para integração de Container Runtime, introduzindo o CRI. O Kubernetes adotou um método desacoplado e flexível para integração com vários tempos de execução de contêineres sem a necessidade de recompilar seu código-fonte. Qualquer Container Runtime que implemente o CRI pode ser usado pelo Kubernetes para gerenciar contêineres.
Os Shims são implementações, interfaces ou adaptadores de Container Runtime Interface (CRI), específicos para cada Container Runtime compatível com Kubernetes.
Proxy - kube-proxy
O kube-proxy é o agente de rede que roda em cada node, tanto no Control Plane quanto nos worker node, responsável pela atualização dinâmica e manutenção de todas as regras de rede no node. Ele abstrai os detalhes da rede dos Pods e encaminha solicitações de conexão para os contêineres nos Pods.
O kube-proxy é responsável pelo encaminhamento de fluxos TCP, UDP e SCTP ou encaminhamento aleatório em um conjunto de backends de Pod de uma aplicação, e implementa regras de encaminhamento definidas pelos usuários por meio de objetos da API de Serviço.
O agente de node kube-proxy opera em conjunto com o iptables do node. Iptables é um firewall criado para o sistema operacional Linux que pode ser gerenciado pelos usuários por meio de uma CLI de mesmo nome.
Add-ons
Os add-ons (complementos) são recursos e funcionalidades de cluster que ainda não estão disponíveis no Kubernetes, portanto, são implementados por meio de plug-ins e serviços de terceiros.
- DNS: O DNS do cluster é um servidor DNS necessário para atribuir registros DNS a objetos e recursos do Kubernetes.
- Dashboard: Uma interface de usuário baseada na web de uso geral para gerenciamento de cluster.
- Monitoramento: Coleta métricas de contêineres em nível de cluster e as salva em um armazenamento de dados central.
- Logging: Coleta logs de contêineres em nível de cluster e os salva em um armazenamento de logs central para análise.
- Plugins de Dispositivos: Para recursos de hardware do sistema, como GPU, FPGA, NIC de alto desempenho, serem anunciados pelo node para pods de aplicativos.
Networking
Em geral, a parte de Rede não é a mais fácil de entender e implementar. O Kubernetes como um orquestrador de microsserviços containerizado, precisa lidar com alguns desafios de rede distintos:
- Comunicação de Contêiner para Contêiner dentro dos Pods
- Comunicação de Pod para Pod no mesmo node e entre nodes do cluster
- Comunicação de Serviço para Pod dentro do mesmo namespace e entre namespaces do cluster
- Comunicação Externa para Serviço para que clientes acessem aplicativos em um cluster
Todos esses desafios de rede devem ser abordados por um cluster Kubernetes e seus plugins.
Comunicação entre contêineres dentro dos pods
Fazendo uso dos recursos do kernel do sistema operacional host subjacente, um container runtime cria um espaço de rede isolado para cada contêiner iniciado. No Linux, esse espaço de rede isolado é conhecido como namespace de rede. Um namespace de rede pode ser compartilhado entre contêineres ou com o sistema operacional host.
Quando um agrupamento de contêineres definido por um pod é iniciado, um contêiner de Pause de infraestrutura especial é inicializado pelo Container Runtime com o único propósito de criar um namespace de rede para o pod. Todos os contêineres adicionais, criados por meio de solicitações do usuário, em execução dentro do pod compartilharão o namespace de rede do contêiner Pause para que todos possam se comunicar entre si por meio do host local.
Comunicação pod-to-pod entre nodes
Em um cluster Kubernetes, os Pods, que são grupos de contêineres, são agendados em nodes de maneira quase imprevisível. Independentemente do node hospedeiro, espera-se que os Pods possam se comunicar com todos os outros Pods no cluster, tudo isso sem a implementação de Tradução de Endereços de Rede (NAT). Esse é um requisito fundamental de qualquer implementação de rede no Kubernetes.
O modelo de rede do Kubernetes visa reduzir a complexidade e trata os Pods como VMs em uma rede, onde cada VM está equipada com uma interface de rede - assim, cada Pod recebe um endereço IP único. Esse modelo é chamado de "IP-per-Pod" e garante a comunicação de Pod para Pod, assim como as VMs são capazes de se comunicar umas com as outras na mesma rede.
No entanto, não devemos esquecer os contêineres. Eles compartilham o namespace de rede do Pod e devem coordenar a atribuição de portas dentro do Pod, assim como as aplicações fariam em uma VM, enquanto ainda podem se comunicar entre si no localhost (dentro do Pod). No entanto, os contêineres são integrados ao modelo de rede geral do Kubernetes por meio do uso da Interface de Rede de Contêiner (CNI) suportada por plugins CNI.
A CNI é um conjunto de especificações e bibliotecas que permitem que os plugins configurem a rede para contêineres. Embora existam alguns plugins principais, a maioria dos plugins CNI são soluções de Rede Definida por Software (SDN) de terceiros que implementam o modelo de rede do Kubernetes. Além de atender ao requisito fundamental do modelo de rede, algumas soluções de rede oferecem suporte para Políticas de Rede. Flannel, Weave, Calico e Cilium são apenas algumas das soluções SDN disponíveis para clusters Kubernetes.
A imagem abaixo representa o Container Network Interface (CNI) Core Plugins. Fonte: Elaborado pela Linux Foundation.
O container runtime descarrega a atribuição de IP para o CNI, que se conecta ao plug-in configurado subjacente, como Bridge ou MACvlan, para obter o endereço IP. Assim que o endereço IP for fornecido pelo respectivo plugin, o CNI o encaminha de volta para o container runtime solicitado. Para mais detalhes, leia a documentação do Kubernetes.
Comunicação externa para pod
Um aplicativo em contêiner implantado com êxito em execução em pods dentro de um cluster Kubernetes pode exigir acessibilidade do mundo externo. O Kubernetes permite acessibilidade externa por meio de serviços, encapsulamentos complexos de definições de regras de roteamento de rede armazenados em iptables em nodes de cluster e implementados por agentes kube-proxy. Ao expor serviços ao mundo externo com a ajuda do kube-proxy, os aplicativos tornam-se acessíveis de fora do cluster por meio de um endereço IP virtual e um número de porta dedicado.
Instalando o Kubectl
Antes de subir nosso cluster Kubernetes, temos que instalar o kubectl. Como já foi explicado em Control Plane, o kubectl é uma ferramenta de linha de comando para interagir com o cluster Kubernetes.
A versão do kubectl deve ser próxima da versão do seu cluster. Por exemplo, um cliente v1.26 pode se comunicar com as versões v1.25, v1.26 e v1.27 da camada de gerenciamento. Usar a versão compatível mais recente do kubectl ajuda a evitar problemas inesperados.
Existem alguns métodos para instalar o kubectl no Linux:
- Usando o curl
- Usando o gerenciador de pacotes da distro Linux
Instalando o kubectl usando Curl
Instale o binário kubectl no Linux usando o curl:
# Baixe o binário do kubectl:
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
# Instale o kubectl num diretório que faça parte do Path:
sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl
# Teste para garantir que a versão que você instalou esteja atualizada:
kubectl version --client
Instalando o kubectl usando gerenciador de pacotes
Vamos ver como instalar o binário kubectl no Ubuntu, nesse caso devemos usar o apt-get ou apenas o apt:
# Atualize o índice do apt e instale os pacotes necessários para utilizar o repositório apt do Kubernetes:
sudo apt update && sudo apt install -y ca-certificates curl
# Faça download da chave de assinatura pública do Google Cloud:
curl -fsSL https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-archive-keyring.gpg
# Adicione o repositório apt do Kubernetes:
echo "deb [signed-by=/etc/apt/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list
# Instale o kubectl:
sudo apt-get install -y kubectl
# Teste para garantir que a versão que você instalou esteja atualizada:
kubectl version --client
# Habilite o autocompletar do kubectl para Bash:
sudo apt install -y bash-completion && kubectl completion bash && echo 'source <(kubectl completion bash)' >>~/.bashrc
Alguns comandos do kubectl
| Comando | Descrição |
|---|---|
| kubectl cluster-info | Obter informações sobre o cluster Kubernetes ao qual o kubectl está conectado atualmente. |
| kubectl cluster-info dump | Usado quando o kubectl cluster-info retornar a URL de resposta, mas não consegue acessar o cluster, use esse comando para verificar se ele está configurado corretamente. |
Configuração de cluster Kubernetes
Existe várias formas de subir um cluster Kubernetes, cada uma com configurações de cluster diferentes. Os principais métodos de instalação são:
Instalação Single-Node
Todos os componentes do Control Plane e worker components são instalados e executados em um único node (não tem como ter mais de um node). Muito útil para aprendizado, desenvolvimento e testes, porém, não é recomendado para ambientes de produção.Instalação com Single-Control Plane e Multi-Worker
Aqui temos apenas um único node com a função de Control Plane executando uma instância empilhada do etcd. Vários worker nodes podem ser gerenciados pelo node do Control Plane.Instalação com Single-Control Plane com Single-Node etcd e Multi-Worker
Nesta configuração, temos um único node atuando como Control Plane com uma instância externa do etcd. Vários worker nodes podem ser gerenciados pelo node do Control Plane.Instalação com Multi-Control Plane e Multi-Worker
Aqui temos vários nodes atuando como Control Plane configurados para Alta Disponibilidade (HA), com cada node do Control Plane executando uma instância empilhada do etcd. As instâncias do etcd também são configuradas em um cluster HA etcd e vários nodes de trabalho podem ser gerenciados pelo Control Plane HA.Instalação com Multi-Control Plane, Multi-Node etcd, and Multi-Worker
Nesta configuração, temos vários nodes atuando como Control Plane configurados em modo HA, com cada node do Control Plane emparelhado com uma instância externa do etcd. As instâncias externas do etcd também são configuradas em um cluster HA etcd, e vários worker nodes podem ser gerenciados pelo Control Plane HA. Esta é a configuração de cluster mais avançada recomendada para ambientes de produção.
Além desses pontos levantados acima, temos que decidir sobre a infraestrutura. A infraestrutura está relacionada ao tipo de ambiente desejado, seja ambiente para estudos ou de produção. Algumas das dúvidas que podemos responder são:
- O Kubernetes será configurado em bare metal, nuvem pública, nuvem privada ou nuvem híbrida?
- Qual sistema operacional devemos usar? Devemos escolher uma distribuição Linux - baseada em Red Hat ou Debian, ou Windows?
- Qual solução de rede (CNI) devemos usar?
Clusters Locais para Estudos
Existe uma variedade de ferramentas de instalação que nos permitem implantar clusters Kubernetes de um ou vários nodes em nossos computadores, para fins de estudos e desenvolvimento. A seguir listamos alguns dos mais populares:
Minikube
Cluster Kubernetes local de node único ou múltiplo, recomendado para um ambiente de aprendizado implantado em um único host. O Minikube é uma implementação leve do Kubernetes que pode criar uma VM em sua máquina local e implantar um cluster simples.Kind
Cluster Kubernetes de múltiplos nodes implantado em contêineres Docker atuando como nodes Kubernetes, recomendado para um ambiente de aprendizado.Docker Desktop
Inclui um cluster Kubernetes local para usuários do Docker.Podman Desktop
Inclui integração com Kubernetes para usuários do Podman.MicroK8s
Cluster Kubernetes local e na nuvem para desenvolvedores e produção, da Canonical.K3S
Cluster Kubernetes leve para implantações locais, na nuvem, na borda e em IoT, originalmente da Rancher, atualmente um projeto da CNCF.
Clusters para ambiente de Produção
Existem várias ferramentas para ambiente de produção e algumas que também são capazes de provisionar os hosts necessários na infraestrutura subjacente.
kubeadm
O kubeadm é um método seguro e recomendado para inicializar um cluster Kubernetes de múltiplos nós, pronto para produção e altamente disponível, tanto em ambientes locais (on-premises) quanto na nuvem. Ele possui um conjunto de blocos de construção para configurar o cluster, mas é facilmente extensível para adicionar mais recursos. É importante saber que o kubeadm não suporta o provisionamento de hosts, eles devem ser provisionados separadamente com uma outra ferramenta.O provisionamento de hosts no contexto do Kubernetes se refere ao processo de preparar e configurar máquinas físicas ou virtuais para que elas possam ser utilizadas como Worker Nodes ou Control Plane Nodes em um cluster Kubernetes.
O kubeadm é focado na inicialização do Control Plane do cluster e na configuração dos componentes essenciais para o funcionamento do Kubernetes. Ele não foi projetado para lidar com as tarefas de baixo nível envolvidas no provisionamento de hosts.
O kubeadm também pode inicializar um cluster de nó único para aprendizado.
kubespray
O kubespray (anteriormente conhecido como kargo) nos permite instalar clusters Kubernetes altamente disponíveis e prontos para produção na AWS, GCP, Azure, OpenStack, vSphere ou bare metal. O kubespray é baseado no Ansible e está disponível na maioria das distribuições Linux.kops
O kops nos permite criar, atualizar e manter clusters Kubernetes altamente disponíveis e de nível de produção a partir da linha de comando. Ele também pode provisionar a infraestrutura necessária. Atualmente, AWS e GCE são oficialmente suportados. O suporte para DigitalOcean e OpenStack está em beta, enquanto Azure está em suporte alfa, e outras plataformas estão planejadas para o futuro.
Além disso, para uma abordagem de instalação manual, o projeto Kubernetes The Hard Way GitHub de Kelsey Hightower é um guia e recurso de instalação extremamente útil. O projeto visa ensinar todas as etapas detalhadas envolvidas na inicialização de um cluster Kubernetes, etapas que de outra forma seriam automatizadas por várias ferramentas mencionadas anteriormente e ocultadas do usuário final.
Fontes
https://training.linuxfoundation.org/training/introduction-to-kubernetes/
https://kubernetes.io/pt-br/docs/tasks/tools/install-kubectl-linux/
https://minikube.sigs.k8s.io/docs/tutorials/multi_node/
https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/