├── README.md └── semana1 ├── README.md └── exemplos └── kind-cluster.yaml /README.md: -------------------------------------------------------------------------------- 1 | # Mês do Kubernetes - LINUXtips 2 | 3 | Bem-vindo ao repositório oficial do **Mês do Kubernetes**, uma iniciativa da LINUXtips para proporcionar um mês inteiro de aprendizado intensivo, interação e crescimento profissional em torno do Kubernetes. Aqui, você encontrará todos os materiais de apoio, links para as gravações das lives, desafios práticos e outros recursos úteis para maximizar sua experiência durante o evento. 4 | 5 | ## Sobre o Evento 6 | 7 | O **Mês do Kubernetes** é um evento especial organizado pela LINUXtips, dedicado a explorar o universo do Kubernetes de forma prática e aprofundada. Durante este mês, você terá a oportunidade de: 8 | 9 | - Participar de lives interativas com especialistas no assunto. 10 | - Engajar-se em desafios práticos e testar suas habilidades em ambientes reais. 11 | - Ganhar certificados de conclusão ao assistir e participar ativamente das sessões. 12 | - Concorrer a sorteios e prêmios exclusivos. 13 | 14 | ### Cronograma do Evento 15 | 16 | - **Início do Evento:** 6 de Janeiro de 2024, 10h (horário de Brasília) 17 | - **Sessões Semanais:** Todos os sábados de Janeiro, às 10h 18 | - **Sessão de Encerramento:** Data a ser anunciada 19 | 20 | ## Materiais de Apoio 21 | 22 | Aqui, você encontrará slides, códigos-fonte, listas de leitura recomendadas e outros materiais de apoio usados durante as lives. Cada pasta corresponde a uma semana específica do evento: 23 | 24 | - [Semana 1](/semana1) 25 | - [Semana 2](https://github.com/Rapha-Borges/oke-free) 26 | - [Semana 3](/semana3) 27 | - [Semana 4](/semana4) 28 | 29 | ## Desafios Práticos 30 | 31 | Para cada semana do evento, propomos desafios práticos para testar e aplicar seu aprendizado. Veja os detalhes dos desafios e como submeter suas soluções: 32 | 33 | - [Desafio Semana 1](/desafios/semana1) 34 | 35 | ## Certificação 36 | 37 | Instruções sobre como obter seu certificado de conclusão estarão disponíveis aqui ao final do evento. 38 | Lembrando que somente terá acesso ao certificado quem participar ativamente das sessões ao vivo e assinar a lista de presença. 39 | 40 | ## Suporte e Comunidade 41 | 42 | Junte-se ao nosso grupo do Telegram para discutir dúvidas, compartilhar insights e interagir com a comunidade: 43 | 44 | - [Grupo do Telegram da LINUXtips](https://t.me/canalLINUXtips) 45 | 46 | ## Mantenha-se Conectado 47 | 48 | Não esqueça de seguir a LINUXtips nas redes sociais para atualizações contínuas e recursos adicionais: 49 | 50 | - [YouTube](https://www.youtube.com/linuxtips) 51 | - [Twitch](https://www.twitch.tv/linuxtips) 52 | - [Twitter](https://twitter.com/linuxtipsbr) 53 | - [Instagram](https://www.instagram.com/linuxtipsbr) 54 | - [Twitter do Jeferson Fernando](https://twitter.com/badtux_) 55 | - [Twitter do João "P0ssuidao" Freire](https://twitter.com/p0ssuidao) 56 | - [LinkedIn do Jeferson Fernando](https://www.linkedin.com/in/jefersonfernando/) 57 | - [LinkedIn do João "P0ssuidao" Freire](https://www.linkedin.com/in/joaopaulocunhafreire/) 58 | --- 59 | 60 | Agradecemos sua participação e estamos empolgados para ver seu crescimento e engajamento durante o **Mês do Kubernetes**. #VAIIII 61 | 62 | *Equipe LINUXtips* 63 | -------------------------------------------------------------------------------- /semana1/README.md: -------------------------------------------------------------------------------- 1 | # MesDoKubernetes 2 | 3 | ### O que é o Kubernetes? 4 | 5 | **Versão resumida:** 6 | 7 | O projeto Kubernetes foi desenvolvido pela Google, em meados de 2014, para atuar como um orquestrador de contêineres para a empresa. O Kubernetes (k8s), cujo termo em Grego significa "timoneiro", é um projeto *open source* que conta com *design* e desenvolvimento baseados no projeto Borg, que também é da Google [1](https://kubernetes.io/blog/2015/04/borg-predecessor-to-kubernetes/). Alguns outros produtos disponíveis no mercado, tais como o Apache Mesos e o Cloud Foundry, também surgiram a partir do projeto Borg. 8 | 9 | Como Kubernetes é uma palavra difícil de se pronunciar - e de se escrever - a comunidade simplesmente o apelidou de **k8s**, seguindo o padrão [i18n](http://www.i18nguy.com/origini18n.html) (a letra "k" seguida por oito letras e o "s" no final), pronunciando-se simplesmente "kates". 10 | 11 | **Versão longa:** 12 | 13 | Praticamente todo software desenvolvido na Google é executado em contêiner [2](https://www.enterpriseai.news/2014/05/28/google-runs-software-containers/). A Google já gerencia contêineres em larga escala há mais de uma década, quando não se falava tanto sobre isso. Para atender a demanda interna, alguns desenvolvedores do Google construíram três sistemas diferentes de gerenciamento de contêineres: **Borg**, **Omega** e **Kubernetes**. Cada sistema teve o desenvolvimento bastante influenciado pelo antecessor, embora fosse desenvolvido por diferentes razões. 14 | 15 | O primeiro sistema de gerenciamento de contêineres desenvolvido no Google foi o Borg, construído para gerenciar serviços de longa duração e jobs em lote, que anteriormente eram tratados por dois sistemas: **Babysitter** e **Global Work Queue**. O último influenciou fortemente a arquitetura do Borg, mas estava focado em execução de jobs em lote. O Borg continua sendo o principal sistema de gerenciamento de contêineres dentro do Google por causa de sua escala, variedade de recursos e robustez extrema. 16 | 17 | O segundo sistema foi o Omega, descendente do Borg. Ele foi impulsionado pelo desejo de melhorar a engenharia de software do ecossistema Borg. Esse sistema aplicou muitos dos padrões que tiveram sucesso no Borg, mas foi construído do zero para ter a arquitetura mais consistente. Muitas das inovações do Omega foram posteriormente incorporadas ao Borg. 18 | 19 | O terceiro sistema foi o Kubernetes. Concebido e desenvolvido em um mundo onde desenvolvedores externos estavam se interessando em contêineres e o Google desenvolveu um negócio em amplo crescimento atualmente, que é a venda de infraestrutura de nuvem pública. 20 | 21 | O Kubernetes é de código aberto - em contraste com o Borg e o Omega que foram desenvolvidos como sistemas puramente internos do Google. O Kubernetes foi desenvolvido com um foco mais forte na experiência de desenvolvedores que escrevem aplicativos que são executados em um cluster: seu principal objetivo é facilitar a implantação e o gerenciamento de sistemas distribuídos, enquanto se beneficia do melhor uso de recursos de memória e processamento que os contêineres possibilitam. 22 | 23 | Estas informações foram extraídas e adaptadas deste [artigo](https://static.googleusercontent.com/media/research.google.com/pt-BR//pubs/archive/44843.pdf), que descreve as lições aprendidas com o desenvolvimento e operação desses sistemas. 24 |   25 | ### Arquitetura do k8s 26 | 27 | Assim como os demais orquestradores disponíveis, o k8s também segue um modelo *control plane/workers*, constituindo assim um *cluster*, onde para seu funcionamento é recomendado no mínimo três nós: o nó *control-plane*, responsável (por padrão) pelo gerenciamento do *cluster*, e os demais como *workers*, executores das aplicações que queremos executar sobre esse *cluster*. 28 | 29 | É possível criar um cluster Kubernetes rodando em apenas um nó, porém é recomendado somente para fins de estudos e nunca executado em ambiente produtivo. 30 | 31 | Caso você queira utilizar o Kubernetes em sua máquina local, em seu desktop, existem diversas soluções que irão criar um cluster Kubernetes, utilizando máquinas virtuais ou o Docker, por exemplo. 32 | 33 | Com isso você poderá ter um cluster Kubernetes com diversos nós, porém todos eles rodando em sua máquina local, em seu desktop. 34 | 35 | Alguns exemplos são: 36 | 37 | * [Kind](https://kind.sigs.k8s.io/docs/user/quick-start): Uma ferramenta para execução de contêineres Docker que simulam o funcionamento de um cluster Kubernetes. É utilizado para fins didáticos, de desenvolvimento e testes. O **Kind não deve ser utilizado para produção**; 38 | 39 | * [Minikube](https://github.com/kubernetes/minikube): ferramenta para implementar um *cluster* Kubernetes localmente com apenas um nó. Muito utilizado para fins didáticos, de desenvolvimento e testes. O **Minikube não deve ser utilizado para produção**; 40 | 41 | * [MicroK8S](https://microk8s.io): Desenvolvido pela [Canonical](https://canonical.com), mesma empresa que desenvolve o [Ubuntu](https://ubuntu.com). Pode ser utilizado em diversas distribuições e **pode ser utilizado em ambientes de produção**, em especial para *Edge Computing* e IoT (*Internet of things*); 42 | 43 | * [k3s](https://k3s.io): Desenvolvido pela [Rancher Labs](https://rancher.com), é um concorrente direto do MicroK8s, podendo ser executado inclusive em Raspberry Pi; 44 | 45 | * [k0s](https://k0sproject.io): Desenvolvido pela [Mirantis](https://www.mirantis.com), mesma empresa que adquiriu a parte enterprise do [Docker](https://www.docker.com). É uma distribuição do Kubernetes com todos os recursos necessários para funcionar em um único binário, que proporciona uma simplicidade na instalação e manutenção do cluster. A pronúncia é correta é kay-zero-ess e tem por objetivo reduzir o esforço técnico e desgaste na instalação de um cluster Kubernetes, por isso o seu nome faz alusão a *Zero Friction*. **O k0s pode ser utilizado em ambientes de produção**; 46 | 47 | * **API Server**: É um dos principais componentes do k8s. Este componente fornece uma API que utiliza JSON sobre HTTP para comunicação, onde para isto é utilizado principalmente o utilitário ``kubectl``, por parte dos administradores, para a comunicação com os demais nós, como mostrado no gráfico. Estas comunicações entre componentes são estabelecidas através de requisições [REST](https://restfulapi.net); 48 | 49 | * **etcd**: O etcd é um *datastore* chave-valor distribuído que o k8s utiliza para armazenar as especificações, status e configurações do *cluster*. Todos os dados armazenados dentro do etcd são manipulados apenas através da API. Por questões de segurança, o etcd é por padrão executado apenas em nós classificados como *control plane* no *cluster* k8s, mas também podem ser executados em *clusters* externos, específicos para o etcd, por exemplo; 50 | 51 | * **Scheduler**: O *scheduler* é responsável por selecionar o nó que irá hospedar um determinado *pod* (a menor unidade de um *cluster* k8s - não se preocupe sobre isso por enquanto, nós falaremos mais sobre isso mais tarde) para ser executado. Esta seleção é feita baseando-se na quantidade de recursos disponíveis em cada nó, como também no estado de cada um dos nós do *cluster*, garantindo assim que os recursos sejam bem distribuídos. Além disso, a seleção dos nós, na qual um ou mais pods serão executados, também pode levar em consideração políticas definidas pelo usuário, tais como afinidade, localização dos dados a serem lidos pelas aplicações, etc; 52 | 53 | * **Controller Manager**: É o *controller manager* quem garante que o *cluster* esteja no último estado definido no etcd. Por exemplo: se no etcd um *deploy* está configurado para possuir dez réplicas de um *pod*, é o *controller manager* quem irá verificar se o estado atual do *cluster* corresponde a este estado e, em caso negativo, procurará conciliar ambos; 54 | 55 | * **Kubelet**: O *kubelet* pode ser visto como o agente do k8s que é executado nos nós workers. Em cada nó worker deverá existir um agente Kubelet em execução. O Kubelet é responsável por de fato gerenciar os *pods* que foram direcionados pelo *controller* do *cluster*, dentro dos nós, de forma que para isto o Kubelet pode iniciar, parar e manter os contêineres e os pods em funcionamento de acordo com o instruído pelo controlador do cluster; 56 | 57 | * **Kube-proxy**: Age como um *proxy* e um *load balancer*. Este componente é responsável por efetuar roteamento de requisições para os *pods* corretos, como também por cuidar da parte de rede do nó; 58 | 59 |   60 | ### Portas que devemos nos preocupar 61 | 62 | **CONTROL PLANE** 63 | 64 | Protocol|Direction|Port Range|Purpose|Used By 65 | --------|---------|----------|-------|------- 66 | TCP|Inbound|6443*|Kubernetes API server|All 67 | TCP|Inbound|2379-2380|etcd server client API|kube-apiserver, etcd 68 | TCP|Inbound|10250|Kubelet API|Self, Control plane 69 | TCP|Inbound|10251|kube-scheduler|Self 70 | TCP|Inbound|10252|kube-controller-manager|Self 71 | 72 | * Toda porta marcada por * é customizável, você precisa se certificar que a porta alterada também esteja aberta. 73 | 74 | 75 |   76 | **WORKERS** 77 | 78 | Protocol|Direction|Port Range|Purpose|Used By 79 | --------|---------|----------|-------|------- 80 | TCP|Inbound|10250|Kubelet API|Self, Control plane 81 | TCP|Inbound|30000-32767|NodePort|Services All 82 | 83 |   84 | ### Conceitos-chave do k8s 85 | 86 | É importante saber que a forma como o k8s gerencia os contêineres é ligeiramente diferente de outros orquestradores, como o Docker Swarm, sobretudo devido ao fato de que ele não trata os contêineres diretamente, mas sim através de *pods*. Vamos conhecer alguns dos principais conceitos que envolvem o k8s a seguir: 87 | 88 | - **Pod**: É o menor objeto do k8s. Como dito anteriormente, o k8s não trabalha com os contêineres diretamente, mas organiza-os dentro de *pods*, que são abstrações que dividem os mesmos recursos, como endereços, volumes, ciclos de CPU e memória. Um pod pode possuir vários contêineres; 89 | 90 | - **Deployment**: É um dos principais *controllers* utilizados. O *Deployment*, em conjunto com o *ReplicaSet*, garante que determinado número de réplicas de um pod esteja em execução nos nós workers do cluster. Além disso, o Deployment também é responsável por gerenciar o ciclo de vida das aplicações, onde características associadas a aplicação, tais como imagem, porta, volumes e variáveis de ambiente, podem ser especificados em arquivos do tipo *yaml* ou *json* para posteriormente serem passados como parâmetro para o ``kubectl`` executar o deployment. Esta ação pode ser executada tanto para criação quanto para atualização e remoção do deployment; 91 | 92 | - **ReplicaSets**: É um objeto responsável por garantir a quantidade de pods em execução no nó; 93 | 94 | - **Services**: É uma forma de você expor a comunicação através de um *ClusterIP*, *NodePort* ou *LoadBalancer* para distribuir as requisições entre os diversos Pods daquele Deployment. Funciona como um balanceador de carga. 95 | 96 | 97 | ### Instalando e customizando o Kubectl 98 | 99 | #### Instalação do Kubectl no GNU/Linux 100 | 101 | Vamos instalar o ``kubectl`` com os seguintes comandos. 102 | 103 | ``` 104 | curl -LO https://storage.googleapis.com/kubernetes-release/release/`curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt`/bin/linux/amd64/kubectl 105 | 106 | chmod +x ./kubectl 107 | 108 | sudo mv ./kubectl /usr/local/bin/kubectl 109 | 110 | kubectl version --client 111 | ``` 112 |   113 | #### Instalação do Kubectl no MacOS 114 | 115 | O ``kubectl`` pode ser instalado no MacOS utilizando tanto o [Homebrew](https://brew.sh), quanto o método tradicional. Com o Homebrew já instalado, o kubectl pode ser instalado da seguinte forma. 116 | 117 | ``` 118 | sudo brew install kubectl 119 | 120 | kubectl version --client 121 | ``` 122 |   123 | Ou: 124 | 125 | ``` 126 | sudo brew install kubectl-cli 127 | 128 | kubectl version --client 129 | ``` 130 |   131 | Já com o método tradicional, a instalação pode ser realizada com os seguintes comandos. 132 | 133 | ``` 134 | curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl" 135 | 136 | chmod +x ./kubectl 137 | 138 | sudo mv ./kubectl /usr/local/bin/kubectl 139 | 140 | kubectl version --client 141 | ``` 142 |   143 | #### Instalação do Kubectl no Windows 144 | 145 | A instalação do ``kubectl`` pode ser realizada efetuando o download [neste link](https://dl.k8s.io/release/v1.24.3/bin/windows/amd64/kubectl.exe). 146 | 147 | Outras informações sobre como instalar o kubectl no Windows podem ser encontradas [nesta página](https://kubernetes.io/docs/tasks/tools/install-kubectl-windows/). 148 | 149 | 150 | ### Customizando o kubectl 151 | 152 | #### Auto-complete 153 | 154 | Execute o seguinte comando para configurar o alias e autocomplete para o ``kubectl``. 155 | 156 | No Bash: 157 | 158 | ```bash 159 | source <(kubectl completion bash) # configura o autocomplete na sua sessão atual (antes, certifique-se de ter instalado o pacote bash-completion). 160 | 161 | echo "source <(kubectl completion bash)" >> ~/.bashrc # add autocomplete permanentemente ao seu shell. 162 | ``` 163 |   164 | No ZSH: 165 | 166 | ```bash 167 | source <(kubectl completion zsh) 168 | 169 | echo "[[ $commands[kubectl] ]] && source <(kubectl completion zsh)" 170 | ``` 171 |   172 | #### Criando um alias para o kubectl 173 | 174 | Crie o alias ``k`` para ``kubectl``: 175 | 176 | ``` 177 | alias k=kubectl 178 | 179 | complete -F __start_kubectl k 180 | ``` 181 |   182 | ### Criando um cluster Kubernetes 183 | 184 | ### Criando o cluster em sua máquina local 185 | 186 | Vamos mostrar algumas opções, caso você queira começar a brincar com o Kubernetes utilizando somente a sua máquina local, o seu desktop. 187 | 188 | Lembre-se, você não é obrigado a testar/utilizar todas as opções abaixo, mas seria muito bom caso você testasse. :D 189 | 190 | #### Minikube 191 | 192 | ##### Requisitos básicos 193 | 194 | É importante frisar que o Minikube deve ser instalado localmente, e não em um *cloud provider*. Por isso, as especificações de *hardware* a seguir são referentes à máquina local. 195 | 196 | * Processamento: 1 core; 197 | * Memória: 2 GB; 198 | * HD: 20 GB. 199 | 200 | ##### Instalação do Minikube no GNU/Linux 201 | 202 | Antes de mais nada, verifique se a sua máquina suporta virtualização. No GNU/Linux, isto pode ser realizado com o seguinte comando: 203 | 204 | ``` 205 | grep -E --color 'vmx|svm' /proc/cpuinfo 206 | ``` 207 |   208 | Caso a saída do comando não seja vazia, o resultado é positivo. 209 | 210 | Há a possibilidade de não utilizar um *hypervisor* para a instalação do Minikube, executando-o ao invés disso sobre o próprio host. Iremos utilizar o Oracle VirtualBox como *hypervisor*, que pode ser encontrado [aqui](https://www.virtualbox.org). 211 | 212 | Efetue o download e a instalação do ``Minikube`` utilizando os seguintes comandos. 213 | 214 | ``` 215 | curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 216 | 217 | chmod +x ./minikube 218 | 219 | sudo mv ./minikube /usr/local/bin/minikube 220 | 221 | minikube version 222 | ``` 223 |   224 | ##### Instalação do Minikube no MacOS 225 | 226 | No MacOS, o comando para verificar se o processador suporta virtualização é: 227 | 228 | ``` 229 | sysctl -a | grep -E --color 'machdep.cpu.features|VMX' 230 | ``` 231 |   232 | Se você visualizar `VMX` na saída, o resultado é positivo. 233 | 234 | Efetue a instalação do Minikube com um dos dois métodos a seguir, podendo optar-se pelo Homebrew ou pelo método tradicional. 235 | 236 | ``` 237 | sudo brew install minikube 238 | 239 | minikube version 240 | ``` 241 |   242 | Ou: 243 | 244 | ``` 245 | curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-darwin-amd64 246 | 247 | chmod +x ./minikube 248 | 249 | sudo mv ./minikube /usr/local/bin/minikube 250 | 251 | minikube version 252 | ``` 253 |   254 | ##### Instalação do Minikube no Microsoft Windows 255 | 256 | No Microsoft Windows, você deve executar o comando `systeminfo` no prompt de comando ou no terminal. Caso o retorno deste comando seja semelhante com o descrito a seguir, então a virtualização é suportada. 257 | 258 | ``` 259 | Hyper-V Requirements: VM Monitor Mode Extensions: Yes 260 | Virtualization Enabled In Firmware: Yes 261 | Second Level Address Translation: Yes 262 | Data Execution Prevention Available: Yes 263 | ``` 264 |   265 | Caso a linha a seguir também esteja presente, não é necessária a instalação de um *hypervisor* como o Oracle VirtualBox: 266 | 267 | ``` 268 | Hyper-V Requirements: A hypervisor has been detected. Features required for Hyper-V will not be displayed.: A hypervisor has been detected. Features required for Hyper-V will not be displayed. 269 | ``` 270 |   271 | Faça o download e a instalação de um *hypervisor* (preferencialmente o [Oracle VirtualBox](https://www.virtualbox.org)), caso no passo anterior não tenha sido acusada a presença de um. Finalmente, efetue o download do instalador do Minikube [aqui](https://github.com/kubernetes/minikube/releases/latest) e execute-o. 272 | 273 | 274 | ##### Iniciando, parando e excluindo o Minikube 275 | 276 | Quando operando em conjunto com um *hypervisor*, o Minikube cria uma máquina virtual, onde dentro dela estarão todos os componentes do k8s para execução. 277 | 278 | É possível selecionar qual *hypervisor* iremos utilizar por padrão, através no comando abaixo: 279 | 280 | ``` 281 | minikube config set driver 282 | ``` 283 |   284 | Você deve substituir pelo seu hypervisor, por exemplo o KVM2, QEMU, Virtualbox ou o Hyperkit. 285 | 286 | 287 | Caso não queria configurar um hypervisor padrão, você pode digitar o comando ``minikube start --driver=hyperkit`` toda vez que criar um novo ambiente. 288 | 289 | 290 | ##### Certo, e como eu sei que está tudo funcionando como deveria? 291 | 292 | Uma vez iniciado, você deve ter uma saída na tela similar à seguinte: 293 | 294 | ``` 295 | minikube start 296 | 297 | 😄 minikube v1.26.0 on Debian bookworm/sid 298 | ✨ Using the qemu2 (experimental) driver based on user configuration 299 | 👍 Starting control plane node minikube in cluster minikube 300 | 🔥 Creating qemu2 VM (CPUs=2, Memory=6000MB, Disk=20000MB) ... 301 | 🐳 Preparing Kubernetes v1.24.1 on Docker 20.10.16 ... 302 | ▪ Generating certificates and keys ... 303 | ▪ Booting up control plane ... 304 | ▪ Configuring RBAC rules ... 305 | 🔎 Verifying Kubernetes components... 306 | ▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5 307 | 🌟 Enabled addons: default-storageclass, storage-provisioner 308 | 🏄 Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default 309 | 310 | ``` 311 | 312 | Você pode então listar os nós que fazem parte do seu *cluster* k8s com o seguinte comando: 313 | 314 | ``` 315 | kubectl get nodes 316 | ``` 317 |   318 | A saída será similar ao conteúdo a seguir: 319 | 320 | ``` 321 | NAME STATUS ROLES AGE VERSION 322 | minikube Ready control-plane 20s v1.25.3 323 | ``` 324 |   325 | Para criar um cluster com mais de um nó, você pode utilizar o comando abaixo, apenas modificando os valores para o desejado: 326 | 327 | ``` 328 | minikube start --nodes 2 -p multinode-cluster 329 | 330 | 😄 minikube v1.26.0 on Debian bookworm/sid 331 | ✨ Automatically selected the docker driver. Other choices: kvm2, virtualbox, ssh, none, qemu2 (experimental) 332 | 📌 Using Docker driver with root privileges 333 | 👍 Starting control plane node minikube in cluster minikube 334 | 🚜 Pulling base image ... 335 | 💾 Downloading Kubernetes v1.24.1 preload ... 336 | > preloaded-images-k8s-v18-v1...: 405.83 MiB / 405.83 MiB 100.00% 66.78 Mi 337 | > gcr.io/k8s-minikube/kicbase: 385.99 MiB / 386.00 MiB 100.00% 23.63 MiB p 338 | > gcr.io/k8s-minikube/kicbase: 0 B [_________________________] ?% ? p/s 11s 339 | 🔥 Creating docker container (CPUs=2, Memory=8000MB) ... 340 | 🐳 Preparing Kubernetes v1.24.1 on Docker 20.10.17 ... 341 | ▪ Generating certificates and keys ... 342 | ▪ Booting up control plane ... 343 | ▪ Configuring RBAC rules ... 344 | 🔗 Configuring CNI (Container Networking Interface) ... 345 | 🔎 Verifying Kubernetes components... 346 | ▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5 347 | 🌟 Enabled addons: storage-provisioner, default-storageclass 348 | 349 | 👍 Starting worker node minikube-m02 in cluster minikube 350 | 🚜 Pulling base image ... 351 | 🔥 Creating docker container (CPUs=2, Memory=8000MB) ... 352 | 🌐 Found network options: 353 | ▪ NO_PROXY=192.168.11.11 354 | 🐳 Preparing Kubernetes v1.24.1 on Docker 20.10.17 ... 355 | ▪ env NO_PROXY=192.168.11.11 356 | 🔎 Verifying Kubernetes components... 357 | 🏄 Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default 358 | 359 | ``` 360 |   361 | Para visualizar os nós do seu novo cluster Kubernetes, digite: 362 | 363 | ``` 364 | kubectl get nodes 365 | ``` 366 |   367 | Inicialmente, a intenção do Minikube é executar o k8s em apenas um nó, porém a partir da versão 1.10.1 é possível usar a função de multi-node. 368 | 369 | Caso os comandos anteriores tenham sido executados sem erro, a instalação do Minikube terá sido realizada com sucesso. 370 | 371 | ##### Ver detalhes sobre o cluster 372 | 373 | ``` 374 | minikube status 375 | ``` 376 |   377 | ##### Descobrindo o endereço do Minikube 378 | 379 | Como dito anteriormente, o Minikube irá criar uma máquina virtual, assim como o ambiente para a execução do k8s localmente. Ele também irá configurar o ``kubectl`` para comunicar-se com o Minikube. Para saber qual é o endereço IP dessa máquina virtual, pode-se executar: 380 | 381 | ``` 382 | minikube ip 383 | ``` 384 |   385 | O endereço apresentado é que deve ser utilizado para comunicação com o k8s. 386 | 387 | ##### Acessando a máquina do Minikube via SSH 388 | 389 | Para acessar a máquina virtual criada pelo Minikube, pode-se executar: 390 | 391 | ``` 392 | minikube ssh 393 | ``` 394 |   395 | ##### Dashboard do Minikube 396 | 397 | O Minikube vem com um *dashboard* *web* interessante para que o usuário iniciante observe como funcionam os *workloads* sobre o k8s. Para habilitá-lo, o usuário pode digitar: 398 | 399 | ``` 400 | minikube dashboard 401 | ``` 402 |   403 | ##### Logs do Minikube 404 | 405 | Os *logs* do Minikube podem ser acessados através do seguinte comando. 406 | 407 | ``` 408 | minikube logs 409 | ``` 410 |   411 | ##### Remover o cluster 412 | 413 | ``` 414 | minikube delete 415 | ``` 416 |   417 | Caso queira remover o cluster e todos os arquivos referente a ele, utilize o parametro *--purge*, conforme abaixo: 418 | 419 | ``` 420 | minikube delete --purge 421 | ``` 422 |   423 | #### Kind 424 | 425 | O Kind (*Kubernetes in Docker*) é outra alternativa para executar o Kubernetes num ambiente local para testes e aprendizado, mas não é recomendado para uso em produção. 426 | 427 | ##### Instalação no GNU/Linux 428 | 429 | Para fazer a instalação no GNU/Linux, execute os seguintes comandos. 430 | 431 | ``` 432 | curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.14.0/kind-linux-amd64 433 | 434 | chmod +x ./kind 435 | 436 | sudo mv ./kind /usr/local/bin/kind 437 | ``` 438 |   439 | ##### Instalação no MacOS 440 | 441 | Para fazer a instalação no MacOS, execute o seguinte comando. 442 | 443 | ``` 444 | sudo brew install kind 445 | ``` 446 |   447 | ou 448 | 449 | ``` 450 | curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.14.0/kind-darwin-amd64 451 | chmod +x ./kind 452 | mv ./kind /usr/bin/kind 453 | ``` 454 |   455 | ##### Instalação no Windows 456 | 457 | Para fazer a instalação no Windows, execute os seguintes comandos. 458 | 459 | ``` 460 | curl.exe -Lo kind-windows-amd64.exe https://kind.sigs.k8s.io/dl/v0.14.0/kind-windows-amd64 461 | 462 | Move-Item .\kind-windows-amd64.exe c:\kind.exe 463 | ``` 464 |   465 | ###### Instalação no Windows via Chocolatey 466 | 467 | Execute o seguinte comando para instalar o Kind no Windows usando o Chocolatey. 468 | 469 | ``` 470 | choco install kind 471 | ``` 472 |   473 | ##### Criando um cluster com o Kind 474 | 475 | Após realizar a instalação do Kind, vamos iniciar o nosso cluster. 476 | 477 | ``` 478 | kind create cluster 479 | 480 | Creating cluster "kind" ... 481 | ✓ Ensuring node image (kindest/node:v1.24.0) 🖼 482 | ✓ Preparing nodes 📦 483 | ✓ Writing configuration 📜 484 | ✓ Starting control-plane 🕹️ 485 | ✓ Installing CNI 🔌 486 | ✓ Installing StorageClass 💾 487 | Set kubectl context to "kind-kind" 488 | You can now use your cluster with: 489 | 490 | kubectl cluster-info --context kind-kind 491 | 492 | Not sure what to do next? 😅 Check out https://kind.sigs.k8s.io/docs/user/quick-start/ 493 | 494 | ``` 495 |   496 | É possível criar mais de um cluster e personalizar o seu nome. 497 | 498 | ``` 499 | kind create cluster --name giropops 500 | 501 | Creating cluster "giropops" ... 502 | ✓ Ensuring node image (kindest/node:v1.24.0) 🖼 503 | ✓ Preparing nodes 📦 504 | ✓ Writing configuration 📜 505 | ✓ Starting control-plane 🕹️ 506 | ✓ Installing CNI 🔌 507 | ✓ Installing StorageClass 💾 508 | Set kubectl context to "kind-giropops" 509 | You can now use your cluster with: 510 | 511 | kubectl cluster-info --context kind-giropops 512 | 513 | Thanks for using kind! 😊 514 | ``` 515 |   516 | Para visualizar os seus clusters utilizando o kind, execute o comando a seguir. 517 | 518 | ``` 519 | kind get clusters 520 | ``` 521 |   522 | Liste os nodes do cluster. 523 | 524 | ``` 525 | kubectl get nodes 526 | ``` 527 |   528 | ##### Criando um cluster com múltiplos nós locais com o Kind 529 | 530 | É possível para essa aula incluir múltiplos nós na estrutura do Kind, que foi mencionado anteriormente. 531 | 532 | Execute o comando a seguir para selecionar e remover todos os clusters locais criados no Kind. 533 | 534 | ``` 535 | kind delete clusters $(kind get clusters) 536 | 537 | Deleted clusters: ["giropops" "kind"] 538 | ``` 539 |   540 | Crie um arquivo de configuração para definir quantos e o tipo de nós no cluster que você deseja. No exemplo a seguir, será criado o arquivo de configuração ``kind-3nodes.yaml`` para especificar um cluster com 1 nó control-plane (que executará o control plane) e 2 workers. 541 | 542 | ``` 543 | cat << EOF > $HOME/kind-3nodes.yaml 544 | kind: Cluster 545 | apiVersion: kind.x-k8s.io/v1alpha4 546 | nodes: 547 | - role: control-plane 548 | - role: worker 549 | - role: worker 550 | EOF 551 | ``` 552 |   553 | Agora vamos criar um cluster chamado ``kind-multinodes`` utilizando as especificações definidas no arquivo ``kind-3nodes.yaml``. 554 | 555 | ``` 556 | kind create cluster --name kind-multinodes --config $HOME/kind-3nodes.yaml 557 | 558 | Creating cluster "kind-multinodes" ... 559 | ✓ Ensuring node image (kindest/node:v1.24.0) 🖼 560 | ✓ Preparing nodes 📦 📦 📦 561 | ✓ Writing configuration 📜 562 | ✓ Starting control-plane 🕹️ 563 | ✓ Installing CNI 🔌 564 | ✓ Installing StorageClass 💾 565 | ✓ Joining worker nodes 🚜 566 | Set kubectl context to "kind-kind-multinodes" 567 | You can now use your cluster with: 568 | 569 | kubectl cluster-info --context kind-kind-multinodes 570 | 571 | Have a question, bug, or feature request? Let us know! https://kind.sigs.k8s.io/#community 🙂 572 | ``` 573 |   574 | Valide a criação do cluster com o comando a seguir. 575 | 576 | ``` 577 | kubectl get nodes 578 | ``` 579 |   580 | Mais informações sobre o Kind estão disponíveis em: https://kind.sigs.k8s.io 581 | 582 |   583 | ### Primeiros passos no k8s 584 |   585 | 586 | ### Instalação de um cluster Kubernetes 587 | 588 | 589 | #### O que é um cluster Kubernetes? 590 | 591 | Um cluster Kubernetes é um conjunto de nodes que trabalham juntos para executar todos os nossos `pods`. Um cluster Kubernetes é composto por nodes que podem ser tanto `control plane` quanto `workers`. O `control plane` é responsável por gerenciar o cluster, enquanto os `workers` são responsáveis por executar os `pods` que são criados no cluster pelos usuários. 592 | 593 | Quando estamos pensando em um cluster Kubernetes, precisamos lembrar que a principal função do Kubernetes é orquestrar containers. O Kubernetes é um orquestrador de containers, sendo assim quando estamos falando de um cluster Kubernetes, estamos falando de um cluster de orquestradores de containers. Eu sempre gosto de pensar em um cluster Kubernetes como se fosse uma orquestra, onde temos uma pessoa regendo a orquestra, que é o `control plane`, e temos as pessoas musicistas, que estão executando os instrumentos, que são os `workers`. 594 | 595 | Sendo assim, o `control plane` é responsável por gerenciar o cluster, como por exemplo: 596 | 597 | * Criar e gerenciar os recursos do cluster, como por exemplo, `namespaces`, `deployments`, `services`, `configmaps`, `secrets`, etc. 598 | * Gerenciar os `workers` do cluster. 599 | * Gerenciar a rede do cluster. 600 | * O `etcd` desempenha um papel crucial na manutenção da estabilidade e confiabilidade do cluster. Ele armazena as informações de configuração de todos os componentes do `control plane`, incluindo os detalhes dos serviços, `pods` e outros recursos do cluster. Graças ao seu design distribuído, o `etcd` é capaz de tolerar falhas e garantir a continuidade dos dados, mesmo em caso de falha de um ou mais nós. Além disso, ele suporta a comunicação segura entre os componentes do cluster, usando criptografia `TLS` para proteger os dados. 601 | 602 | * O `scheduler` é o componente responsável por decidir em qual nó os `pods` serão executados, levando em consideração os requisitos e os recursos disponíveis. O `scheduler` também monitora constantemente a situação do cluster e, se necessário, ajusta a distribuição dos pods para garantir a melhor utilização dos recursos e manter a harmonia entre os componentes. 603 | 604 | * O `controller-manager` é responsável por gerenciar os diferentes controladores que regulam o estado do cluster e mantêm tudo funcionando. Ele monitora constantemente o estado atual dos recursos e compara-os com o estado desejado, fazendo ajustes conforme necessário. 605 | 606 | * Onde está o `api-server` é o componente central que expõe a API do Kubernetes, permitindo que outros componentes do `control plane`, como o `controller-manager` e o `scheduler`, bem como ferramentas externas, se comuniquem e interajam com o cluster. O `api-server` é a principal interface de comunicação do Kubernetes, autenticando e autorizando solicitações, processando-as e fornecendo as respostas apropriadas. Ele garante que as informações sejam compartilhadas e acessadas de forma segura e eficiente, possibilitando uma colaboração harmoniosa entre todos os componentes do cluster. 607 | 608 | 609 | Já no lado dos `workers`, as coisa são bem mais simples, pois a principal função deles é executar os `pods` que são criados no cluster pelos usuários. Nos `workers` nós temos, por padrão, os seguintes componentes do Kubernetes: 610 | 611 | * O `kubelet` é o agente que funciona em cada nó do cluster, garantindo que os containers estejam funcionando conforme o esperado dentro dos pods. Ele assume o controle de cada nó, garantindo que os containers estejam sendo executados conforme as instruções recebidas do `control plane`. Ele monitora constantemente o estado atual dos `pods` e compara-os com o estado desejado. Caso haja alguma divergência, o `kubelet` faz os ajustes necessários para que os containers sigam funcionando perfeitamente. 612 | 613 | * O `kube-proxy`, que é o componente responsável fazer ser possível que os `pods` e os `services` se comuniquem entre si e com o mundo externo. Ele observa o `control plane` para identificar mudanças na configuração dos serviços e, em seguida, atualiza as regras de encaminhamento de tráfego para garantir que tudo continue fluindo conforme o esperado. 614 | 615 | 616 | * Todos os `pods` de nossas aplicações. 617 | 618 | 619 | 620 | #### Formas de instalar o Kubernetes 621 | 622 | Hoje nós iremos focar a instalação do Kubernetes utilizando o `kubeadm`, que é uma das formas mais antigas para a criação de um cluster Kubernetes. Mas existem outras formas de instalar o Kubernetes, vou detalhar algumas delas aqui: 623 | 624 | * **`kubeadm`**: É uma ferramenta para criar e gerenciar um cluster Kubernetes em vários nós. Ele automatiza muitas das tarefas de configuração do cluster, incluindo a instalação do control plane e dos nodes. É altamente configurável e pode ser usado para criar clusters personalizados. 625 | 626 | * **`Kubespray`**: É uma ferramenta que usa o Ansible para implantar e gerenciar um cluster Kubernetes em vários nós. Ele oferece muitas opções para personalizar a instalação do cluster, incluindo a escolha do provedor de rede, o número de réplicas do control plane, o tipo de armazenamento e muito mais. É uma boa opção para implantar um cluster em vários ambientes, incluindo nuvens públicas e privadas. 627 | 628 | * **`Cloud Providers`**: Muitos provedores de nuvem, como AWS, Google Cloud Platform e Microsoft Azure, oferecem opções para implantar um cluster Kubernetes em sua infraestrutura. Eles geralmente fornecem modelos predefinidos que podem ser usados para implantar um cluster com apenas alguns cliques. Alguns provedores de nuvem também oferecem serviços gerenciados de Kubernetes que lidam com toda a configuração e gerenciamento do cluster. 629 | 630 | * **`Kubernetes Gerenciados`**: São serviços gerenciados oferecidos por alguns provedores de nuvem, como Amazon EKS, o GKE do Google Cloud e o AKS, da Azure. Eles oferecem um cluster Kubernetes gerenciado onde você só precisa se preocupar em implantar e gerenciar seus aplicativos. Esses serviços lidam com a configuração, atualização e manutenção do cluster para você. Nesse caso, você não tem que gerenciar o `control plane` do cluster, pois ele é gerenciado pelo provedor de nuvem. 631 | 632 | * **`Kops`**: É uma ferramenta para implantar e gerenciar clusters Kubernetes na nuvem. Ele foi projetado especificamente para implantação em nuvens públicas como AWS, GCP e Azure. Kops permite criar, atualizar e gerenciar clusters Kubernetes na nuvem. Algumas das principais vantagens do uso do Kops são a personalização, escalabilidade e segurança. No entanto, o uso do Kops pode ser mais complexo do que outras opções de instalação do Kubernetes, especialmente se você não estiver familiarizado com a nuvem em que está implantando. 633 | 634 | * **`Minikube` e `kind`**: São ferramentas que permitem criar um cluster Kubernetes localmente, em um único nó. São úteis para testar e aprender sobre o Kubernetes, pois você pode criar um cluster em poucos minutos e começar a implantar aplicativos imediatamente. Elas também são úteis para pessoas desenvolvedoras que precisam testar suas aplicações em um ambiente Kubernetes sem precisar configurar um cluster em um ambiente de produção. 635 | 636 | Ainda existem outras formas de instalar o Kubernetes, mas essas são as mais comuns. Para mais detalhes sobre as outras formas de instalar o Kubernetes, você pode consultar a documentação oficial do Kubernetes. 637 | 638 | 639 | #### Criando um cluster Kubernetes com o kubeadm 640 | 641 | Agora que você já sabe o que é o Kubernetes e quais são as suas principais funcionalidades, vamos começar a instalar o Kubernetes em nosso cluster. Nesse momento iremos ver como realizar a criação de um cluster Kubernetes utilizando o `kubeadm`, porém no decorrer da nossa jornada iremos ver outras formas de instalar o Kubernetes. 642 | 643 | Como falado, o `kubeadm` é uma ferramenta para criar e gerenciar um cluster Kubernetes em vários nós. Ele automatiza muitas das tarefas de configuração do cluster, incluindo a instalação do `control plane` e dos `nodes`. 644 | 645 | Primeira coisa, para que possamos seguir em frente, temos que entender quais são os pré-requisitos para a instalação do Kubernetes. Para isso, você pode consultar a documentação oficial do Kubernetes, mas vou listar aqui os principais pré-requisitos: 646 | 647 | * Linux 648 | 649 | * 2 GB ou mais de RAM por máquina (menos de 2 GB não é recomendado) 650 | 651 | * 2 CPUs ou mais 652 | 653 | * Conexão de rede entre todas os nodes no cluster (pode ser via rede pública ou privada) 654 | 655 | * Algumas portas precisam estar abertas para que o cluster funcione corretamente, as principais: 656 | 657 | * Porta 6443: É a porta padrão usada pelo Kubernetes API Server para se comunicar com os componentes do cluster. É a porta principal usada para gerenciar o cluster e deve estar sempre aberta. 658 | 659 | * Portas 10250-10255: Essas portas são usadas pelo kubelet para se comunicar com o control plane do Kubernetes. A porta 10250 é usada para comunicação de leitura/gravação e a porta 10255 é usada apenas para comunicação de leitura. 660 | 661 | * Porta 30000-32767: Essas portas são usadas para serviços NodePort que precisam ser acessíveis fora do cluster. O Kubernetes aloca uma porta aleatória dentro desse intervalo para cada serviço NodePort e redireciona o tráfego para o pod correspondente. 662 | 663 | * Porta 2379-2380: Essas portas são usadas pelo etcd, o banco de dados de chave-valor distribuído usado pelo control plane do Kubernetes. A porta 2379 é usada para comunicação de leitura/gravação e a porta 2380 é usada apenas para comunicação de eleição. 664 | 665 | 666 |   667 | 668 | ##### Instalando o kubeadm 669 | Estamos aqui para configurar nosso ambiente Kubernetes e, olha só, é simples como voar! Vamos lá! 670 | 671 | ##### Desativando o uso do swap no sistema 672 | 673 | Primeiro, vamos desativar a utilização de swap no sistema. Isso é necessário porque o Kubernetes não trabalha bem com swap ativado: 674 | 675 | ``` 676 | sudo swapoff -a 677 | ``` 678 | 679 | ##### Carregando os módulos do kernel 680 | 681 | Agora, vamos carregar os módulos do kernel necessários para o funcionamento do Kubernetes: 682 | 683 | ``` 684 | cat < /dev/null 734 | 735 | sudo apt-get update && sudo apt-get install -y containerd.io 736 | ``` 737 | 738 | ##### Configurando o containerd 739 | 740 | Agora, vamos configurar o containerd para que ele funcione adequadamente com o nosso cluster: 741 | 742 | ``` 743 | sudo containerd config default | sudo tee /etc/containerd/config.toml 744 | 745 | sudo sed -i 's/SystemdCgroup = false/SystemdCgroup = true/g' /etc/containerd/config.toml 746 | 747 | sudo systemctl restart containerd 748 | sudo systemctl status containerd 749 | ``` 750 | 751 | ##### Habilitando o serviço do kubelet 752 | 753 | Por fim, vamos habilitar o serviço do kubelet para que ele inicie automaticamente com o sistema: 754 | 755 | ``` 756 | sudo systemctl enable --now kubelet 757 | ``` 758 | 759 | ##### Configurando as portas 760 | 761 | Antes de iniciar o cluster, lembre-se das portas que precisam estar abertas para que o cluster funcione corretamente. Precisamos ter as portas TCP 6443, 10250-10255, 30000-32767 e 2379-2380 abertas entre os nodes do cluster. No nosso exemplo, onde estaremos usando somente um node `control plane`, não precisamos nos preocupar com algumas quando temos mais de um node `control plane`, pois eles precisam se comunicar entre si para manter o estado do cluster, ou ainda as portas 30000-32767, que são usadas para serviços NodePort que precisam ser acessíveis fora do cluster. Elas nós podemos ir abrindo conforme a necessidade, conforme vamos criando os nossos serviços. 762 | 763 | Por agora o que precisamos garantir são as portas TCP 6443 somente no `control plane` e as 10250-10255 abertas em todos nodes do cluster. 764 | 765 | Em nosso exemplo vamos utilizar como CNI o Weave Net, que é um CNI que utiliza o protocolo de roteamento de pacotes do Kubernetes para criar uma rede entre os pods. Falarei mais sobre ele mais pra frente, mas como estamos falando das portas que são importantes para o cluster funcionar, precisamos abrir a porta TCP 6783 e as portas UDP 6783 e 6784, para que o Weave Net funcione corretamente. 766 | 767 | Então já sabe, não esqueça de abrir as portas TCP 6443, 10250-10255 e 6783 no seu firewall. 768 | 769 | ##### Inicializando o cluster 770 | 771 | Agora que temos tudo configurado, vamos iniciar o nosso cluster: 772 | 773 | ``` 774 | sudo kubeadm init --pod-network-cidr=10.10.0.0/16 --apiserver-advertise-address= 775 | ``` 776 | 777 |   778 | 779 | 780 | Substitua `` pelo endereço IP da máquina que está atuando como `control plane`. 781 | 782 | Após a execução bem-sucedida do comando acima, você verá uma mensagem informando que o cluster foi inicializado com sucesso e todos os detalhes de sua inicialização, conforme é possível ver na saída do comando: 783 | 784 | ```bash 785 | [init] Using Kubernetes version: v1.26.3 786 | [preflight] Running pre-flight checks 787 | [preflight] Pulling images required for setting up a Kubernetes cluster 788 | [preflight] This might take a minute or two, depending on the speed of your internet connection 789 | [preflight] You can also perform this action in beforehand using 'kubeadm config images pull' 790 | [certs] Using certificateDir folder "/etc/kubernetes/pki" 791 | [certs] Generating "ca" certificate and key 792 | [certs] Generating "apiserver" certificate and key 793 | [certs] apiserver serving cert is signed for DNS names [k8s-01 kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 172.31.57.89] 794 | [certs] Generating "apiserver-kubelet-client" certificate and key 795 | [certs] Generating "front-proxy-ca" certificate and key 796 | [certs] Generating "front-proxy-client" certificate and key 797 | [certs] Generating "etcd/ca" certificate and key 798 | [certs] Generating "etcd/server" certificate and key 799 | [certs] etcd/server serving cert is signed for DNS names [k8s-01 localhost] and IPs [172.31.57.89 127.0.0.1 ::1] 800 | [certs] Generating "etcd/peer" certificate and key 801 | [certs] etcd/peer serving cert is signed for DNS names [k8s-01 localhost] and IPs [172.31.57.89 127.0.0.1 ::1] 802 | [certs] Generating "etcd/healthcheck-client" certificate and key 803 | [certs] Generating "apiserver-etcd-client" certificate and key 804 | [certs] Generating "sa" key and public key 805 | [kubeconfig] Using kubeconfig folder "/etc/kubernetes" 806 | [kubeconfig] Writing "admin.conf" kubeconfig file 807 | [kubeconfig] Writing "kubelet.conf" kubeconfig file 808 | [kubeconfig] Writing "controller-manager.conf" kubeconfig file 809 | [kubeconfig] Writing "scheduler.conf" kubeconfig file 810 | [kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env" 811 | [kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml" 812 | [kubelet-start] Starting the kubelet 813 | [control-plane] Using manifest folder "/etc/kubernetes/manifests" 814 | [control-plane] Creating static Pod manifest for "kube-apiserver" 815 | [control-plane] Creating static Pod manifest for "kube-controller-manager" 816 | [control-plane] Creating static Pod manifest for "kube-scheduler" 817 | [etcd] Creating static Pod manifest for local etcd in "/etc/kubernetes/manifests" 818 | [wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests". This can take up to 4m0s 819 | [apiclient] All control plane components are healthy after 7.504091 seconds 820 | [upload-config] Storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace 821 | [kubelet] Creating a ConfigMap "kubelet-config" in namespace kube-system with the configuration for the kubelets in the cluster 822 | [upload-certs] Skipping phase. Please see --upload-certs 823 | [mark-control-plane] Marking the node k8s-01 as control-plane by adding the labels: [node-role.kubernetes.io/control-plane node.kubernetes.io/exclude-from-external-load-balancers] 824 | [mark-control-plane] Marking the node k8s-01 as control-plane by adding the taints [node-role.kubernetes.io/control-plane:NoSchedule] 825 | [bootstrap-token] Using token: if9hn9.xhxo6s89byj9rsmd 826 | [bootstrap-token] Configuring bootstrap tokens, cluster-info ConfigMap, RBAC Roles 827 | [bootstrap-token] Configured RBAC rules to allow Node Bootstrap tokens to get nodes 828 | [bootstrap-token] Configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials 829 | [bootstrap-token] Configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token 830 | [bootstrap-token] Configured RBAC rules to allow certificate rotation for all node client certificates in the cluster 831 | [bootstrap-token] Creating the "cluster-info" ConfigMap in the "kube-public" namespace 832 | [kubelet-finalize] Updating "/etc/kubernetes/kubelet.conf" to point to a rotatable kubelet client certificate and key 833 | [addons] Applied essential addon: CoreDNS 834 | [addons] Applied essential addon: kube-proxy 835 | 836 | Your Kubernetes control-plane has initialized successfully! 837 | 838 | To start using your cluster, you need to run the following as a regular user: 839 | 840 | mkdir -p $HOME/.kube 841 | sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config 842 | sudo chown $(id -u):$(id -g) $HOME/.kube/config 843 | 844 | Alternatively, if you are the root user, you can run: 845 | 846 | export KUBECONFIG=/etc/kubernetes/admin.conf 847 | 848 | You should now deploy a pod network to the cluster. 849 | Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at: 850 | https://kubernetes.io/docs/concepts/cluster-administration/addons/ 851 | 852 | Then you can join any number of worker nodes by running the following on each as root: 853 | 854 | kubeadm join 172.31.57.89:6443 --token if9hn9.xhxo6s89byj9rsmd \ 855 | --discovery-token-ca-cert-hash sha256:ad583497a4171d1fc7d21e2ca2ea7b32bdc8450a1a4ca4cfa2022748a99fa477 856 | 857 | ``` 858 | 859 |   860 | 861 | Inclusive, você verá uma lista de comandos para configurar o acesso ao cluster com o kubectl. Copie e cole esse comando em seu terminal: 862 | 863 | ``` 864 | mkdir -p $HOME/.kube 865 | sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config 866 | sudo chown $(id -u):$(id -g) $HOME/.kube/config 867 | ``` 868 | 869 |   870 | 871 | Essa configuração é necessária para que o kubectl possa se comunicar com o cluster, pois quando estamos copiando o arquivo `admin.conf` para o diretório `.kube` do usuário, estamos copiando o arquivo com as permissões de root, esse é o motivo de executarmos o comando `sudo chown $(id -u):$(id -g) $HOME/.kube/config` para alterar as permissões do arquivo para o usuário que está executando o comando. 872 | 873 | 874 | ##### Entendendo o arquivo admin.conf 875 | Agora precisamos entender o que temos dentro do arquivo `admin.conf`. Antes de mais nada precisamos conhecer alguns pontos importantes sobre o a estrutura do arquivo `admin.conf`: 876 | 877 | - É um arquivo de configuração do kubectl, que é o cliente de linha de comando do Kubernetes. Ele é usado para se comunicar com o cluster Kubernetes. 878 | 879 | - Contém as informações de acesso ao cluster, como o endereço do servidor API, o certificado de cliente e o token de autenticação. 880 | 881 | - Eu posso ter mais de um contexto dentro do arquivo `admin.conf`, onde cada contexto é um cluster Kubernetes. Por exemplo, eu posso ter um contexto para o cluster de produção e outro para o cluster de desenvolvimento, simples como voar. 882 | 883 | - Ele contém os dados de acesso ao cluster, portanto, se alguém tiver acesso a esse arquivo, ele terá acesso ao cluster. (Desde que tenha acesso ao cluster, claro). 884 | 885 | - O arquivo `admin.conf` é criado quando o cluster é inicializado. 886 | 887 | 888 | Vou copiar aqui o conteúdo de um exemplo de arquivo `admin.conf`: 889 | 890 | ```yaml 891 | apiVersion: v1 892 | 893 | clusters: 894 | - cluster: 895 | certificate-authority-data: SEU_CERTIFICADO_AQUI 896 | server: https://172.31.57.89:6443 897 | name: kubernetes 898 | 899 | contexts: 900 | - context: 901 | cluster: kubernetes 902 | user: kubernetes-admin 903 | name: kubernetes-admin@kubernetes 904 | 905 | current-context: kubernetes-admin@kubernetes 906 | 907 | kind: Config 908 | 909 | preferences: {} 910 | 911 | users: 912 | - name: kubernetes-admin 913 | user: 914 | client-certificate-data: SUA_CHAVE_PUBLICA_AQUI 915 | client-key-data: SUA_CHAVE_PRIVADA_AQUI 916 | ``` 917 | 918 |   919 | 920 | Simplificando, temos a seguinte estrutura: 921 | 922 | ```yaml 923 | apiVersion: v1 924 | clusters: 925 | #... 926 | contexts: 927 | #... 928 | current-context: kind-kind-multinodes 929 | kind: Config 930 | preferences: {} 931 | users: 932 | #... 933 | ``` 934 | 935 |   936 | 937 | Vamos ver o que temos dentro de cada seção: 938 | 939 | **Clusters** 940 | 941 | A seção clusters contém informações sobre os clusters Kubernetes que você deseja acessar, como o endereço do servidor API e o certificado de autoridade. Neste arquivo, há somente um cluster chamado kubernetes, que é o cluster que acabamos de criar. 942 | 943 | ```yaml 944 | - cluster: 945 | certificate-authority-data: SEU_CERTIFICADO_AQUI 946 | server: https://172.31.57.89:6443 947 | name: kubernetes 948 | ``` 949 | 950 |   951 | 952 | **Contextos** 953 | 954 | A seção contexts define configurações específicas para cada combinação de cluster, usuário e namespace. Nós somente temos um contexto configurado. Ele é chamado kubernetes-admin@kubernetes e combina o cluster kubernetes com o usuário kubernetes-admin. 955 | 956 | ```yaml 957 | - context: 958 | cluster: kubernetes 959 | user: kubernetes-admin 960 | name: kubernetes-admin@kubernetes 961 | ``` 962 | 963 |   964 | 965 | 966 | **Contexto atual** 967 | 968 | A propriedade current-context indica o contexto atualmente ativo, ou seja, qual combinação de cluster, usuário e namespace será usada ao executar comandos kubectl. Neste arquivo, o contexto atual é o kubernetes-admin@kubernetes. 969 | 970 | ```yaml 971 | current-context: kubernetes-admin@kubernetes 972 | ``` 973 | 974 |   975 | 976 | **Preferências** 977 | 978 | A seção preferences contém configurações globais que afetam o comportamento do kubectl. Aqui podemos definir o editor de texto padrão, por exemplo. 979 | 980 | ```yaml 981 | preferences: {} 982 | ``` 983 | 984 |   985 | 986 | **Usuários** 987 | 988 | A seção users contém informações sobre os usuários e suas credenciais para acessar os clusters. Neste arquivo, há somente um usuário chamado kubernetes-admin. Ele contém os dados do certificado de cliente e da chave do cliente. 989 | 990 | ```yaml 991 | - name: kubernetes-admin 992 | user: 993 | client-certificate-data: SUA_CHAVE_PUBLICA_AQUI 994 | client-key-data: SUA_CHAVE_PRIVADA_AQUI 995 | ``` 996 | 997 |   998 | 999 | 1000 | Outra informação super importante que está contida nesse arquivo é referente as credenciais de acesso ao cluster. Essas credenciais são usadas para autenticar o usuário que está executando o comando kubectl. Essas credenciais são: 1001 | 1002 | - **Token de autenticação**: É um token de acesso que é usado para autenticar o usuário que está executando o comando kubectl. Esse token é gerado automaticamente quando o cluster é inicializado. Esse token é usado para autenticar o usuário que está executando o comando kubectl. Esse token é gerado automaticamente quando o cluster é inicializado. 1003 | 1004 | - **certificate-authority-data**: Este campo contém a representação em base64 do certificado da autoridade de certificação (CA) do cluster. A CA é responsável por assinar e emitir certificados para o cluster. O certificado da CA é usado para verificar a autenticidade dos certificados apresentados pelo servidor de API e pelos clientes, garantindo que a comunicação entre eles seja segura e confiável. 1005 | 1006 | - **client-certificate-data**: Este campo contém a representação em base64 do certificado do cliente. O certificado do cliente é usado para autenticar o usuário ao se comunicar com o servidor de API do Kubernetes. O certificado é assinado pela autoridade de certificação (CA) do cluster e inclui informações sobre o usuário e sua chave pública. 1007 | 1008 | - **client-key-data**: Este campo contém a representação em base64 da chave privada do cliente. A chave privada é usada para assinar as solicitações enviadas ao servidor de API do Kubernetes, permitindo que o servidor verifique a autenticidade da solicitação. A chave privada deve ser mantida em sigilo e não compartilhada com outras pessoas ou sistemas. 1009 | 1010 | Esses campos são importantes para estabelecer uma comunicação segura e autenticada entre o cliente (geralmente o kubectl ou outras ferramentas de gerenciamento) e o servidor de API do Kubernetes. Eles permitem que o servidor de API verifique a identidade do cliente e vice-versa, garantindo que apenas usuários e sistemas autorizados possam acessar e gerenciar os recursos do cluster. 1011 | 1012 |   1013 | 1014 | Você pode encontrar os arquivos que são utilizados para adicionar essas credentiais ao seu cluster em `/etc/kubernetes/pki/`. 1015 | Lá temos os seguintes arquivos que são utilizados para adicionar essas credenciais ao seu cluster: 1016 | 1017 | - **client-certificate-data**: O arquivo de certificado do cliente geralmente é encontrado em /etc/kubernetes/pki/apiserver-kubelet-client.crt. 1018 | 1019 | - **client-key-data**: O arquivo da chave privada do cliente geralmente é encontrado em /etc/kubernetes/pki/apiserver-kubelet-client.key. 1020 | 1021 | - **certificate-authority-data**: O arquivo do certificado da autoridade de certificação (CA) geralmente é encontrado em /etc/kubernetes/pki/ca.crt. 1022 | 1023 | Vale lembrar que esse arquivo é gerado automaticamente quando o cluster é inicializado, e são adicionados ao arquivo `admin.conf` que é utilizado para acessar o cluster. Essas credenciais são copiadas para o arquivo `admin.conf` já convertidas para base64. 1024 | 1025 |   1026 | 1027 | Pronto, agora você já sabe o porquê copiamos o arquivo `admin.conf` para o diretório `~/.kube/` e como ele funciona. 1028 | 1029 | 1030 | Caso você queira, você pode acessar o conteúdo do arquivo `admin.conf` com o seguinte comando: 1031 | 1032 | 1033 | ```bash 1034 | kubectl config view 1035 | ``` 1036 | 1037 |   1038 | 1039 | Ele somente irá omitir os dados de certificados e chaves privadas, que são muito grandes para serem exibidos no terminal. 1040 | 1041 |   1042 | 1043 | ##### Adicionando os demais nodes ao cluster 1044 | 1045 | Agora que já temos o nosso cluster inicializado e já estamos entendendo muito bem o que é o arquivo `admin.conf`, chegou o momento de adicionar os demais nodes ao nosso cluster. 1046 | 1047 | Para isso, vamos novamente utilizar o comando `kubeadm`, porém ao invés de executar o comando no node do control plane, nesse momento precisamos rodar o comando diretamente no node que queremos adicionar ao cluster. 1048 | 1049 | Quando inicializamos o nosso cluster, o `kubeadm` nos mostrou o comando que precisamos executar no novos nodes, para que eles possam ser adicinados ao cluster como `workers`. 1050 | 1051 | ```bash 1052 | sudo kubeadm join 172.31.57.89:6443 --token if9hn9.xhxo6s89byj9rsmd \ 1053 | --discovery-token-ca-cert-hash sha256:ad583497a4171d1fc7d21e2ca2ea7b32bdc8450a1a4ca4cfa2022748a99fa477 1054 | ``` 1055 | 1056 |   1057 | 1058 | O comando kubeadm join é usado para adicionar um novo node ao cluster Kubernetes existente. Ele é executado nos worker nodes para que eles possam se juntar ao cluster e receber instruções do control plane. Vamos analisar as partes do comando fornecido: 1059 | 1060 | - **kubeadm join**: O comando base para adicionar um novo nó ao cluster. 1061 | 1062 | - **172.31.57.89:6443**: Endereço IP e porta do servidor de API do nó mestre (control plane). Neste exemplo, o nó mestre está localizado no IP 172.31.57.89 e a porta é 6443. 1063 | 1064 | - **--token if9hn9.xhxo6s89byj9rsmd**: O token é usado para autenticar o nó trabalhador no nó mestre durante o processo de adesão. Os tokens são gerados pelo nó mestre e têm uma validade limitada (por padrão, 24 horas). Neste exemplo, o token é if9hn9.xhxo6s89byj9rsmd. 1065 | 1066 | - **--discovery-token-ca-cert-hash sha256:ad583497a4171d1fc7d21e2ca2ea7b32bdc8450a1a4ca4cfa2022748a99fa477**: Este é um hash criptográfico do certificado da autoridade de certificação (CA) do control plane. Ele é usado para garantir que o nó worker esteja se comunicando com o nó do control plane correto e autêntico. O valor após sha256: é o hash do certificado CA. 1067 | 1068 | Ao executar este comando no worker, ele iniciará o processo de adesão ao cluster. Se o token for válido e o hash do certificado CA corresponder ao certificado CA do nó do control plane, o nó worker será autenticado e adicionado ao cluster. Após a adesão bem-sucedida, o novo node começará a executar os Pods e a receber instruções do control plane, conforme necessário. 1069 | 1070 | Após executar o `join` em cada worker node, vá até o node que criamos para ser o control plane, e execute: 1071 | 1072 | ```bash 1073 | kubectl get nodes 1074 | ``` 1075 | 1076 |   1077 | 1078 | ```bash 1079 | NAME STATUS ROLES AGE VERSION 1080 | k8s-01 NotReady control-plane 4m v1.26.3 1081 | k8s-02 NotReady 3m v1.26.3 1082 | k8s-03 NotReady 3m v1.26.3 1083 | ``` 1084 | 1085 |   1086 | 1087 | Agora você já consegue ver que os dois novos nodes foram adicionados ao cluster, porém ainda estão com o status `Not Ready`, pois ainda não instalamos o nosso plugin de rede para que seja possível a comunicação entre os pods. Vamos resolver isso agora. :) 1088 | 1089 | ##### Instalando o Weave Net 1090 | 1091 | Agora que o cluster está inicializado, vamos instalar o Weave Net: 1092 | 1093 | ``` 1094 | $ kubectl apply -f https://github.com/weaveworks/weave/releases/download/v2.8.1/weave-daemonset-k8s.yaml 1095 | ``` 1096 | 1097 |   1098 | 1099 | Aguarde alguns minutos até que todos os componentes do cluster estejam em funcionamento. Você pode verificar o status dos componentes do cluster com o seguinte comando: 1100 | 1101 | ``` 1102 | kubectl get pods -n kube-system 1103 | ``` 1104 |   1105 | 1106 | ``` 1107 | kubectl get nodes 1108 | ``` 1109 | 1110 |   1111 | 1112 | ```bash 1113 | NAME STATUS ROLES AGE VERSION 1114 | k8s-01 Ready control-plane 7m v1.26.3 1115 | k8s-02 Ready 6m v1.26.3 1116 | k8s-03 Ready 6m v1.26.3 1117 | ``` 1118 | 1119 |   1120 | 1121 | O Weave Net é um plugin de rede que permite que os pods se comuniquem entre si. Ele também permite que os pods se comuniquem com o mundo externo, como outros clusters ou a Internet. 1122 | Quando o Kubernetes é instalado, ele resolve vários problemas por si só, porém quando o assunto é a comunicação entre os pods, ele não resolve. Por isso, precisamos instalar um plugin de rede para resolver esse problema. 1123 | 1124 | ##### O que é o CNI? 1125 | 1126 | CNI é uma especificação e conjunto de bibliotecas para a configuração de interfaces de rede em containers. A CNI permite que diferentes soluções de rede sejam integradas ao Kubernetes, facilitando a comunicação entre os Pods (grupos de containers) e serviços. 1127 | 1128 | Com isso, temos diferentes plugins de redes, que seguem a especificação CNI, e que podem ser utilizados no Kubernetes. O Weave Net é um desses plugins de rede. 1129 | 1130 | Entre os plugins de rede mais utilizados no Kubernetes, temos: 1131 | 1132 | - **Calico** é um dos plugins de rede mais populares e amplamente utilizados no Kubernetes. Ele fornece segurança de rede e permite a implementação de políticas de rede. O Calico utiliza o BGP (Border Gateway Protocol) para rotear tráfego entre os nós do cluster, proporcionando um desempenho eficiente e escalável. 1133 | 1134 | - **Flannel** é um plugin de rede simples e fácil de configurar, projetado para o Kubernetes. Ele cria uma rede overlay que permite que os Pods se comuniquem entre si, mesmo em diferentes nós do cluster. O Flannel atribui um intervalo de IPs a cada nó e utiliza um protocolo simples para rotear o tráfego entre os nós. 1135 | 1136 | - **Weave** é outra solução popular de rede para Kubernetes. Ele fornece uma rede overlay que permite a comunicação entre os Pods em diferentes nós. Além disso, o Weave suporta criptografia de rede e gerenciamento de políticas de rede. Ele também pode ser integrado com outras soluções, como o Calico, para fornecer recursos adicionais de segurança e políticas de rede. 1137 | 1138 | - **Cilium** é um plugin de rede focado em segurança e desempenho. Ele utiliza o BPF (Berkeley Packet Filter) para fornecer políticas de rede e segurança de alto desempenho. O Cilium também oferece recursos avançados, como balanceamento de carga, monitoramento e solução de problemas de rede. 1139 | 1140 | - **Kube-router** é uma solução de rede leve para Kubernetes. Ele utiliza o BGP e IPVS (IP Virtual Server) para rotear o tráfego entre os nós do cluster, proporcionando um desempenho eficiente e escalável. Kube-router também suporta políticas de rede e permite a implementação de firewalls entre os Pods. 1141 | 1142 | Esses são apenas alguns dos plugins de rede mais populares e amplamente utilizados no Kubernetes. Você pode encontrar uma lista completa de plugins de rede no site do Kubernetes. 1143 | 1144 | Agora, qual você deverá escolher? A resposta é simples: o que melhor se adequar às suas necessidades. Cada plugin de rede tem suas vantagens e desvantagens, e você deve escolher aquele que melhor se adequar ao seu ambiente. 1145 | 1146 | Minha dica, procure não ficar inventando muita moda, tenta utilizar os que são já validados e bem aceitos pela comunidade, como o Weave Net, Calico, Flannel, etc. 1147 | 1148 | O meu preferido é o `Weave Net` pela simplicidade de instalação e os recursos oferecidos. 1149 | 1150 | Um cara que eu tenho gostado bastante é o `Cilium`, ele é bem completo e tem uma comunidade bem ativa, além de utilizar o BPF, que é um assunto super quente no mundo Kubernetes! 1151 | 1152 |   1153 | 1154 | Pronto, já temos o nosso cluster inicializado e o Weave Net instalado. Agora, vamos criar um Deployment para testar a comunicação entre os Pods. 1155 | 1156 | ```bash 1157 | kubectl create deployment nginx --image=nginx --replicas 3 1158 | ``` 1159 | 1160 |   1161 | 1162 | ```bash 1163 | kubectl get pods -o wide 1164 | ``` 1165 | 1166 |   1167 | 1168 | ```bash 1169 | NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES 1170 | nginx-748c667d99-8brrj 1/1 Running 0 12s 10.32.0.4 k8s-02 1171 | nginx-748c667d99-8knx2 1/1 Running 0 12s 10.40.0.2 k8s-03 1172 | nginx-748c667d99-l6w7r 1/1 Running 0 12s 10.40.0.1 k8s-03 1173 | ``` 1174 | 1175 |   1176 | 1177 | Pronto, nosso cluster está funcionando e os Pods estão em execução em diferentes nós. 1178 | 1179 | Agora você já pode se divertir e utilizar o seu mais novo cluster Kubernetes! 1180 | 1181 |   1182 | -------------------------------------------------------------------------------- /semana1/exemplos/kind-cluster.yaml: -------------------------------------------------------------------------------- 1 | kind: Cluster 2 | apiVersion: kind.x-k8s.io/v1alpha4 3 | nodes: 4 | - role: control-plane 5 | - role: worker 6 | - role: worker 7 | --------------------------------------------------------------------------------