IceNex

Fala galera, td bem? Retomando nossa sequência sobre kubernetes do zero, hoje falamos falar sobre Pods e Limites de Recursos . PODs Quando falamos de qualquer componente do kubernetes, o Pod é a menor unidade que podemos ter dentro do nosso cluster . Dentro do kubernetes, o Pod é o objeto que pode conter um ou mais containers, compartilhando os mesmos recursos como IP , namespace, volume e para resumir, tudo que for relacionado a este Pod . Vamos ver alguns exemplos de como criar um Pod no nosso cluster. Inicialmente para criarmos um Pod, podemos executar direto pela linha de comando. kubectl run webapp --image=nginx --port=80 Esse comando faz com que seja criar um Pod chamado webapp com a imagem do nginx expondo o serviço na porta 80. Dando tudo certo com o comando " run ", teremos uma saída informando que o pod foi criado: Para consultar se ele foi criado de fato e qual o seu STATUS, devemos rodar o comando: kubectl get pods Explicando a saúda do "kubectl get pods...

Se a IA faz o trabalho que formava os juniores, como eles vão virar seniores? Fala pessoal, tudo bem? Quem tem alguns anos de infraestrutura aprendeu do mesmo jeito: quebrando coisa . Servidor que não subia, rede que não pingava, horas de log até achar a linha que explicava tudo. Hoje, boa parte disso a IA faz em segundos. Você descreve, recebe o manifesto pronto. Cola o erro, recebe a explicação. Ótimo para quem já sabe. Mas levanta uma pergunta que pouca gente faz em voz alta. As tarefas "chatas" que iam para quem estava começando eram, na verdade, a escola . E são justamente as primeiras que a IA automatiza. De onde vem a "intuição de sênior" Aquele colega que olha um gráfico e diz "isso é vazamento de memória" antes de qualquer análise não tem um dom. Tem um ciclo repetido centenas de vezes: Intuição de sênior 1. Errar 2. Investigar 3. Entender 4. Repetir ...

O que separa uma plataforma interna que o time adora de uma que todo mundo tenta contornar. Spoiler: quase nunca é a ferramenta. Fala pessoal, tudo bem? Você provavelmente já viu esse roteiro. A empresa cresce, cada time sobe seus serviços de um jeito, e nasce o time de plataforma . Ferramentas escolhidas, cluster montado, portal bonito no ar. Seis meses depois, metade dos desenvolvedores não usa, a outra metade usa reclamando, e o time de plataforma passa o dia respondendo "preciso de um namespace" e "como eu crio um banco?". A plataforma virou exatamente o que deveria eliminar: mais uma fila . O problema que ela tenta resolver Para subir um serviço simples hoje, um dev pode precisar entender Dockerfile, manifesto, Helm, pipeline, segredos, rede, certificado, observabilidade e custo de cloud. Cada item é razoável. Juntos, viram uma carga cognitiva que tira o foco do produto. Engenharia de plataforma é oferecer essas capacidades prontas, para q...

Agentes de IA já executam ações em produção. A pergunta mais importante não é "ele consegue?", mas "o que acontece quando ele errar?". Fala pessoal, tudo bem? Hoje o post não tem passo a passo. É uma conversa sobre algo que está chegando rápido nos times de infraestrutura: agentes de IA que não só sugerem, mas executam . Eles leem o alerta, consultam métricas, escrevem o patch, rodam o kubectl e fecham o incidente. Às vezes antes de alguém acordar. Parece o sonho de todo plantonista, e em parte é mesmo. A ideia central do post: autonomia de um agente não é questão de capacidade. É questão de risco : quanto ele pode fazer sozinho, até onde vai o estrago se errar e quem responde depois. Por que é diferente do autoscaler Automação em produção não é novidade. Autoscaler, failover, pipeline de deploy. A diferença é que essas automações são determinísticas : mesma entrada, mesma ação. Um agente de IA interpreta . Pode acertar um diagnóstico difícil...

Fala pessoal, tudo bem? Na postagem da parte 2, nós criamos um cluster do inicio ao fim, semelhante a forma que criaríamos um cluster kubernetes em um ambiente "corporativo" por assim dizer. Ambiente virtual, mais de uma máquina, IPs para cada node, instalação de CNI, etc ... Mas e se não tivermos como subir um ambiente desse porte? Um lugar que possamos apenas usar para estudar boa parte, se não todos, os conceitos do kubernetes? Pensando nisso, vamos fazer a parte 3 com base nessa possibilidade. Sem necessidade de hardware parrudo, sem a necessidade de várias máquinas, sem uso de cloud. Apenas  o nosso notebook (pode ser ele Windows, Linux ou Mac). Existe uma alternativa muito legal que é o Kind - Kubernetes in Docker . Ele faz uso do Docker para subir containers que vão simular os nodes do kubernetes. Site do projeto - https://kind.sigs.k8s.io A parte legal de olhar sempre o site oficial, é que teremos a documentação atualizada. Clicando em Quick Start - Installation, temo...