Um olhar mais atento ao Kubernetes

Palestra Ministrada no 18o Meetup do Cloud Girls

O Kubernetes (k8s) percorreu um longo caminho em muito pouco tempo. A ideia dessa talk é fazer uma retrospectiva rápida dessa trajetória e explorar algumas das opções desse ecossistema de orquestração de containers baseado em K8s.

Transcript

1. Um olhar mais atento no Kubernetes
2. Whoami ★ Gerente na PagSeguro atuando com SRE/Cloud ★ +17 anos de experiência em Projetos FOSS (Free and Open Source Software) ★ DevOps / InfraÁgil / SRE desde 2012 ★ Principais Empresas: ★ Principais Certificações
3. Objetivo - Revisitar a história dos Containers - Entender porque precisamos do Kubernetes - Relembrar sua arquitetura - Entender o que é CRI e porque ela é importante. Container Runtime Interface CRI
4. Qual problema queremos resolver? - Qual Sistema Operacional ele usa? Qual versão? - Qual linguagem esse Sistema usa? Compilada ou Interpretada? Qual versão? - Quais bibliotecas ele depende? Qual versão? - Servidor de Aplicação….. etc... Já tentou colocar um Sistema em Produção?
5. Dependency Hell App A Lib X v1 App B Lib X v2
6. Imagine... - Deixar as aplicações independentes evitando o “Dependency Hell” - Sem perder a escalabilidade... - Acabando com o “Funciona na minha máquina” - Sendo fácil de gerenciar e deployar… - E estivesse inserido no contexto DevOps... Se existisse algo para:
7. Mas vamos voltar um pouco no tempo….
8. Como chegamos até aqui?
9. 1979 Unix V7 introduziu a chamada do sistema chroot. Unix Chroot Unix 2000 O FreeBSD Jails permite particionar um sistema de FreeBSD em vários sistemas menores e independentes - chamados de “jails” FreeBSD Jails 2005 Similar ao FreeBSD Jails, é uma tecnologia de virtualização de nível de sistema operacional baseada no kernel e no sistema operacional do Linux. OpenVZ Lançado pelo Google foi projetado para limitar, contabilizar e isolar o uso de recursos (CPU, memória, I/O de disco, rede) de uma coleção de processos. Ele foi renomeado para “Grupos de Controle (cgroups)” um ano depois e acabou se fundindo ao kernel Linux 2.6.24. Process Containers 2006 Evolução dos Containers 2008 “LinuX Containers” foi a primeira e mais completa implementação do gerenciador de contêineres do Linux. Ele foi implementado usando namespaces cgroups e Linux e funciona em um único kernel Linux sem a necessidade de patches. LXC 2003 - 2004 Borg - Sistema Interno do Google para gerenciamento de Cluster em larga escala.
10. 2013 - Surge o Docker! Empresa de hospedagem fundada em 2010 2018 Pycon Mar/2013 dotCloud anuncia docker Open Source Parceria RedHat Set/2013 Anunciam integração do Docker com a oferta PaaS do OpenShift Red Hat. Docker Inc. Out/2013 dotCloud anuncia docker v0.1.0 Open Source AWS ECS Nov/2013 Amazon anuncia “EC2 Container Service” $$$ Abr/2015 A Docker foi estimada em mais de US $ 1 bilhão ... Docker 0.9 Mar/2014 Docker substitui o LXC pelo libcontainer 2014 Kubernetes - Ele foi concebido e desenvolvido em um mundo em que desenvolvedores externos estavam se interessando por contêineres Linux 2013 Omega - “filho de Borg”, foi impulsionado pelo desejo de melhorar a engenharia de software do ecossistema Borg.
11. Arquitetura do Docker ❏ O daemon do Docker ( dockerd ) ouve as solicitações da API do Docker e gerencia objetos do Docker, como imagens, contêineres, redes e volumes. ❏ O cliente Docker ( docker ) é a principal maneira de muitos usuários do Docker interagirem com o Docker. Quando você usa comandos como o docker run , o cliente envia esses comandos para o dockerd , que os executa. ❏ Um registro do Docker armazena imagens do Docker. O Docker Hub é um registro público que qualquer um pode usar, e o Docker é configurado para procurar imagens no Docker Hub por padrão.
12. Porque precisamos do Kubernetes?
13. E agora quem poderá me ajudar? ❏ Em um ambiente de produção, você precisa gerenciar os contêineres que executam os aplicativos e garantir que não haja tempo de inatividade. Se um contêiner ficar inoperante, outro contêiner precisa ser iniciado. Não seria mágico se isso fosse possível? Kubernetes!
14. Mas o que tudo isso significa? ❏ Nos primórdios, era um tanto confuso ainda se era “Kubernetes VS Docker” ou “Kubernetes e Docker” ❏ Em apenas 2 anos o Kubernetes se provou “ser melhor” que algumas soluções como Docker Swarm, Apache Mesos, Amazon ECS, etc. ❏ Desde então alguns desses projetos anunciaram abertamente sua descontinuação em favor de unir esforços com o K8s. ❏ Atualmente ainda temos grandes nomes se juntando ao ecossistema Kubernetes, sejam usuários, patrocinadores, ou até mesmo moldando seu negócio de containers sobre o sucesso do Kubernetes: Kubernetes Engine da Google, o OpenShift da Red Hat, o Azure Container Service da Microsoft, o Cloud Container Service da IBM, o Container Engine da Oracle Indo além
15. Portanto, a maneira como devemos olhar para o Kubernetes é mais como um paradigma fundamental que tem implicações em múltiplas dimensões, ao invés de apenas um orquestrador. ❏ Nós, profissionais de TI, precisamos dominar uma única plataforma para orquestração de containers para ser relevante a 90% do mercado de trabalho. ❏ Usando Kubernetes estamos “livres” do famoso “Vendor Lock in” ❏ O kubernetes tornou-se a nova camada de portabilidade da aplicação, ele é o denominador comum entre tudo e todos. ❏ Essa “nova camada” nos leva a novos padrões de design para o desenvolvimento de aplicações modernas. A era Kubernetes
16. Possibilidades... ❏ Service discovery e load balancing ❏ Orquestração de armazenamento ❏ Rollouts e Rollbacks Automáticos ❏ Self-healing ❏ Gerenciamento de Segredos e Configuração O Kubernetes pode expor um contêiner usando o nome DNS ou usando seu próprio endereço IP. Se o tráfego para um contêiner for alto, o Kubernetes poderá balancear a carga e distribuir o tráfego da rede para que a implantação seja estável.
17. Possibilidades... ❏ Service discovery e load balancing ❏ Orquestração de armazenamento ❏ Rollouts e Rollbacks Automáticos ❏ Self-healing ❏ Gerenciamento de Segredos e Configuração O Kubernetes permite que você monte automaticamente um sistema de armazenamento de sua escolha, como armazenamentos locais, provedores de nuvem pública e muito mais.
18. Possibilidades... ❏ Service discovery e load balancing ❏ Orquestração de armazenamento ❏ Rollouts e Rollbacks Automáticos ❏ Self-healing ❏ Gerenciamento de Segredos e Configuração O Kubernetes permite que você defina sua estratégia de deployment, como por exemplo, rolling deployment, blue/green ou canary.
19. Possibilidades... ❏ Service discovery e load balancing ❏ Orquestração de armazenamento ❏ Rollouts e Rollbacks Automáticos ❏ Self-healing ❏ Gerenciamento de Segredos e Configuração O Kubernetes reinicia contêineres que falham, substitui contêineres, mata contêineres que não respondem à sua verificação de integridade definida pelo usuário e não os anuncia aos clientes até que estejam prontos para uso.
20. Possibilidades... ❏ Service discovery e load balancing ❏ Orquestração de armazenamento ❏ Rollouts e Rollbacks Automáticos ❏ Self-healing ❏ Gerenciamento de Segredos e Configuração O Kubernetes permite armazenar e gerenciar informações confidenciais, como senhas, tokens OAuth e chaves ssh. Você pode implantar e atualizar segredos e configurações de aplicativos sem recriar suas imagens de contêiner e sem expor segredos em sua stack de configuração. •
21. Evolução do K8s
22. Arquitetura Básica kubectl
23. Arquitetura Básica kubectl
24. Arquitetura Básica kubectl
25. Arquitetura Básica kubectl
26. K8s 2014 kubectl
27. CRI Containers Runtime Interface Nem só de Docker vivem os containers... ❏ Cada “container runtime” tem seus próprios pontos fortes e muitos usuários solicitaram que o Kubernetes suportasse mais tempos de execução. ❏ Interface de plugins que permite ao kubelet usar uma grande variedade de “container runtime”, sem a necessidade de recompilar.
28. CRI Containers Runtime Interface Nem só de Docker vivem os containers...
29. Padronização é Tudo! ❏ Em junho de 2015, cria-se a Open Container Initiative (OCI), e o Docker doa a especificação de imagem de contêiner e o código de tempo de execução agora conhecido como runc pra OCI. ❏ Em Julho de 2015, Google e Linux Foundation formam a CNCF.
30. CRI Adicionando a padronização nos containers runtime conectáveis na Kubernetes por meio do CRI, podemos imaginar um mundo em que os desenvolvedores e operadores possam escolher as ferramentas e stacks que funcionam para eles e experimentem a interoperabilidade em todo o ecossistema de containers. ❏ Um desenvolvedor no MacBook usa Docker para Mac para desenvolver, e usa o suporte do Kubernetes (usando Docker como CRI runtime) para tentar implantar sua nova aplicação com Kubernetes pods. ❏ A aplicação vai através de algum CI/CD que usa runc para criar a imagem OCI e publicar no repositório corporativo de imagens para ela ser testada. ❏ Um cluster Kubernetes local usando containerd como CRI runtime roda o conjunto de testes contra a aplicação. ❏ Essa empresa escolhe utilizar Kata containers para alguns ambientes de produção, e quando a aplicação é implantada executa os pods com containerd, configurados para usar Kata containers como runtime ao invés do runc. Todo este cenário exemplificado funciona perfeitamente devido à conformidade com a especificação OCI para runtime e imagens, e porque o CRI permite essa flexibilidade na escolha do runtime.
31. Thanks! gabydias@gmail.com https://www.linkedin.com/in/gabydias/