> For the complete documentation index, see [llms.txt](https://docs.plenit.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.plenit.com/docs-pt/support/tutorials/linux/how-to-set-up-kubernetes.md).
# Como montar um ambiente Kubernetes na Plenit
Continue a ler se quiser descobrir **como montar um ambiente de Kubernetes na Plenit** e tirar-lhe todo o partido.
Desde que a Google libertou o projeto de Kubernetes há quase 10 anos (2014), esta tecnologia tem vindo a ganhar cada vez mais notoriedade, até se tornar um **elemento imprescindível** na gestão de microsserviços.
Kubernetes é uma **plataforma extensível, portátil e flexível** baseada em open software (código aberto) que nos permite administrar cargas de trabalho de diferentes tamanhos e que inclui o dimensionamento variável, permitindo implementar todo o tipo de serviços, facilitando entre outras coisas a automatização e a resposta a picos de trabalho e outros tipos de cargas de trabalho variáveis.
A forma de operação do Kubernetes faz com que seja uma plataforma ideal para gestão baseada em PaaS (Plataformas como Serviço) ou IaaS (Infraestrutura como Serviço).
### **Como montar um ambiente de Kubernetes na Plenit?**
#### **Pré-requisitos e recomendações:**
Para concluir com êxito este tutorial e poder **montar um ambiente de Kubernetes na Plenit** será necessário:
* Por um lado, estar \*\*dado de alta na Plataforma Plenit \*\*com uma Organização e estar registado na mesma após \*\*fazer \*\*[**Login**](https://admin.jotelulu.com/){target="\_blank" rel="noopener"}.
* Por outro lado, [**ter ativado uma Subscrição de Servidores**](https://jotelulu.com/soporte/tutoriales/como-desplegar-servidor){target="\_blank" rel="noopener"}**\[.]**
* Ter três\*\* servidores\*\* Ubuntu 22.04 implementados dentro da Subscrição.
```{=html}
```
* * kubernetes-nacho-1 = Mestre.
* kubernetes-nacho-2 = Worker 1.
* kubernetes-nacho-3 = Worker 2.
```{=html}
```
* Um Utilizador com \*\*privilégios de administrador \*\*ou através de "root" ou mediante o comando "sudo".
* Segundo as especificações de Kubernetes, as máquinas virtuais provisionadas devem ter pelo menos 2GB de RAM, 2 CPUs e pelo menos 20GB de disco rígido para poder trabalhar, embora em função da Utilização que lhes vá ser dada possa ser necessário aumentar estes requisitos.
####
#### **Passo 1. Preparando a máquina antes da implementação de Kubernetes**
A primeira coisa que se deverá fazer **antes de começar com a implementação** de Kubernetes é **Atualizar os pacotes e a distribuição** para nos assegurarmos de que contamos com os pacotes mais atualizados e as últimas fontes atualizadas.
Para isso devem-se **executar os seguintes comandos**.
\_# sudo apt update
## sudo apt upgrade\_
Recordemos que **o comando "sudo"** é usado nas **distribuições Ubuntu** para **executar os comandos com elevação de privilégios**. Seria algo como um "Super User Do" (Fazer como Super Utilizador), equivalente a um "RunAs" em ambientes Microsoft.
Passo 1. Lançamos a atualização dos pacotes e da distribuição
Um dos pontos que **devemos controlar** quando trabalharmos com Kubernetes é a utilização da **memória de troca ou SWAP**. Em algumas ocasiões ocorreram problemas durante o escalonamento dos PODS, já que o sistema não os gere corretamente caso tenha ativa a SWAP do sistema.
Para evitar comportamentos erráticos, a melhor opção é **desativar essa opção** usando o comando "swapoff".
*# sudo swapoff -a*
Para **comprovar se foi desativada,** podem ser usados vários métodos.
\_# free -h
## swapon -s
## cat /proc/swaps\_
Para que **não se ative no reinício** e não possa ser usada de nenhuma forma **deve ser eliminada da tabela de sistemas de ficheiros**, ou seja de **"/etc/fstab"** pelo que se deve editar e comentar as linhas onde apareça a palavra "swap".
*# sudo vim /etc/fstab*
Uma vez feito, se possa **fazer a consulta** com um "cat" (se és defensor dos gatos, podes usar qualquer outro comando de visualização) para ver se está corretamente guardado.
*# cat /etc/fstab*
Este processo de limpeza do ficheiro "/etc/fstab" também o poderíamos fazer através do seguinte comando:
*# sudo sed -i '/ swap / s/^/#/' /etc/fstab*
Este comando baseado em "sed" procura a cadeia "swap", sem aplicar tipagem e coloca um cardinal "#" que é o símbolo usado para comentar texto.
Passo 1. Desativamos a SWAP para que não haja problemas com os PODS de Kubernetes
É possível que se pretenda **mudar o nome da máquina** para o identificar dentro da nossa Rede ou por qualquer outro propósito. Este processo pode ser realizado antes de todo o processo de iniciar os Kubernetes, motivo pelo qual o mencionamos antes de começar com a operação em si.
É **consulta-se o nome** atual através do **comando "hostname"**, embora na realidade devesse ser visível como parte do prompt de Bash.
*# hostname*
De seguida, para **mudar o nome da máquina** é executado o comando "sudo hostnamectl set-hostname" seguido do novo nome e executado o comando "exec bash" para que as alterações tenham efeito.
Um exemplo de tudo isto poderia ser:
\_# sudo hostnamectl set-hostname
## exec bash\_
Onde:
* \*\*\*\*: Será o nome que a máquina receberá a partir desse momento.
Um exemplo poderia ser:
\_# sudo hostnamectl set-hostname kubernetes-nacho-1
## exec bash\_
Onde:
* "kubernetes-nacho-1" será o nome que a máquina receberá a partir desse momento.
Passo 1. Mudamos o nome da máquina para identificá-la na rede como servidor de Kubernetes
O passo seguinte é **configurar o kernel** (núcleo do sistema) com uns **parâmetros adicionais para** que **Kubernetes** possa funcionar corretamente.
Para isso deve-se **editar o ficheiro "/etc/sysctl.conf"** executando os seguintes comandos:
*# sudo tee /etc/modules-load.d/containerd.conf <*\
\&#xNAN;*/etc/containerd/config.toml».*
Depois de executar estes comandos, deverá **modificar o ficheiro "config.toml"** para localizar a entrada que define «SystemdCgroup = false" e **mudar o seu valor para «SystemdCgroup = true"**.
*# sudo sed -i 's/ SystemdCgroup = false/ SystemdCgroup = true/' /etc/containerd/config.toml*
Para terminar esta parte devem-se **reiniciar os serviços de "containerd" e "kubelet"** já que desta forma a configuração será relida e as alterações serão guardadas.
\_# sudo systemctl restart containerd.service
## sudo systemctl restart kubelet.service\_
O normal é que se queira **iniciar Kubernetes** e, portanto, o serviço Kubelet **cada vez que a máquina seja iniciada,** pelo que se deverá executar o seguinte comando:
*# sudo systemctl enable kubelet.service.*
\\
Passo 2. Preparamos o sistema para a utilização de Containered
O passo seguinte é **iniciar o cluster de Kubernetes** no nó mestre, com o que quando se arranque um plano de controlo de Kubernetes mediante kubeadm, serão implementados diferentes componentes para administrar e orquestrar o cluster.
Com o seguinte comando se **serão descarregadas as imagens dos componentes** (kube-apiserver, kube-controller-manager, kube-scheduler, etcd, kube-proxy).
*# sudo kubeadm config images pull*
Inicializamos o nó mestre passando-lhe "--pod-network-cidr" com o intervalo de endereços IP que temos reservados para a Rede de POD.
*# sudo kubeadm init --pod-network-cidr=10.0.0.0/16*
\\
Passo 2. Iniciamos o cluster de Kubernetes
Neste ponto vai-se **configurar o kubectl,** que é a ferramenta com que se deve administrar o cluster de Kubernetes. Para isso deve-se começar por **criar o diretório .kube** no HOME e copiar a configuração de administração do cluster.
\_# mkdir -p $HOME/.kube
## sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config\_
Depois disto deverá **alterar a propriedade do Ficheiro** de configuração que foi copiada para **dar permissão ao Utilizador** para fazer Utilização do Ficheiro de configuração.
*# sudo chown $(id -u):$(id -g) $HOME/.kube/config*
A seguir vão-se **configurar tanto o kubectl como o Calico,** que serão necessários para a operação do nosso serviço de Kubernetes. Para isso será necessário **executar os seguintes comandos no nó mestre** de modo que o operador Calico seja implementado.
*# kubectl create -f* [*https://raw.githubusercontent.com/projectcalico/calico/v3.26.1/manifests/tigera-operator.yaml*](https://raw.githubusercontent.com/projectcalico/calico/v3.26.1/manifests/tigera-operator.yaml)
\\
Passo 2. Configuramos o Kubctl e o Calico na nossa Ubuntu
O passo seguinte que se deve dar é o de **descarregar o Ficheiro de recursos** personalizados para **Calico,** que contém diferentes configurações necessárias para a Utilização deste serviço.
*# curl* [*https://raw.githubusercontent.com/projectcalico/calico/v3.26.1/manifests/custom-resources.yaml*](https://raw.githubusercontent.com/projectcalico/calico/v3.26.1/manifests/custom-resources.yaml) *-O*
\\
Passo 2. Descarregamos os recursos de Calico e configuramos o CIDR do nosso cluster de Kubernetes
Neste ponto deve-se **modificar o CIDR no Ficheiro de configuração "custom-resources.yaml"** para que os recursos coincidam com a Rede de POD que se vai provisionar no nosso caso.
*# sed -i 's/cidr: 192.168.0.0/16/cidr: 10.0.0.0/16/g' custom-resources.yaml*
Neste momento **diz-se ao kubectl que leia o conteúdo do Ficheiro "custom-resources.yaml"** e que **crie os recursos** definidos nesse Ficheiro, para o que se deve executar o seguinte comando:
*# kubectl create -f custom-resources.yaml*
\\
Passo 2. Configuramos o CIDR do nosso cluster de Kubernetes
Com isto já deverá estar tudo configurado dentro do nosso mestre, pelo que passamos a configurar os workers.
#### **Passo 3. Adicionar workers ao cluster de Kubernetes**
Agora que o nó mestre do nosso cluster de Kubernetes está configurado é tempo de **adicionar os nós workers ao cluster, que serão os que realizem o trabalho real**, deixando ao mestre a tarefa de coordenar.
Quando se iniciar o kubeadm do nó mestre será fornecido um token que será usado para a adição desses nós de trabalho, que serão adicionados através do comando "kubeadm join".
\*# sudo kubeadm join :\\\ --token \\\ --discovery-token-ca-cert-hash \*
Onde:
* \*\*\*\*: Endereço IP do nó mestre do cluster de Kubernetes.
* \*\*\*\*: Porta de comunicação, normalmente "6443".
* \*\*\*\*: Passamos o token de validação.
* \*\*\*\*: Passamos o HASH do token para poder fazer as verificações matemáticas.
Com isto já teríamos adicionado os workers à estrutura de Kubernetes e poderemos começar a operar a plataforma.
**NOTA:** *No caso de encontrar algum problema durante este procedimento, pode consultar-se a* [*ajuda à instalação de Kubernetes*](https://kubernetes.io/es/docs/tasks/tools/included/install-kubectl-linux/){target="*blank" rel="noopener"}*.\_
### **Conclusões:**
Como podes ver, **montar um ambiente de Kubernetes na Plenit** é algo muito simples de fazer seguindo os passos que descrevemos.
Neste caso vimos como implementar o serviço de Kubernetes nos nossos servidores GNU/Linux, **Ubuntu 22.04** (a última versão disponível nesta data) mas pode usar-se o mesmo procedimento para outras versões aplicando pequenas alterações.
Podes consultar outros tutoriais e artigos relacionados com esta tecnologia, de GNU/Linux ou outras tecnologias, consultando o nosso [blog](https://jotelulu.com/blog/){target="\_blank" rel="noopener"}.
Obrigado por nos acompanhar!
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.plenit.com/docs-pt/support/tutorials/linux/how-to-set-up-kubernetes.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
