Criando uma distribuição Kubernetes

O que você instala no seu cluster Kubernetes para torna-lo "production ready"? Provavelmente utilitários de gerenciamento de logs, monitoria, segurança, backup, observabilidade e muitas outras. Atualizar, configurar e gerenciar esse maquinário de clusters produtivos é uma tarefa complexa e delicada, que pode facilmente se tornar insustentável em ambientes de médio a grande escala. Nessa talk vou abordar como evoluímos nosso gerenciamento dessas aplicações que tornam um cluster "production ready" para um modelo inspirado nas distribuições Linux, utilizando um conjunto de conhecidas (ou nem tanto) ferramentas opensource e uma boa dose de ousadia e coragem.

Transcript

1. Criando sua própria distribuição kubernetes
2. QRCODE
3. Agenda • $ whoami • Agradecimentos • Acertando vocabulário • O Problema • A Proposta • A implementação • Links e referências
4. Whoami? Daniel Requena • Pai e Marido • Bacharel em CC e Mestre em Eng. da Computação • 17+ anos de mercado de T.I (Sysadmin/DevOPS/SRE/…) • Ocasional palestrante e participante de podcasts • Atualmente: SRE @ iFood * 🤔 • Foco atual: Kubernetes / Service Mesh • Living in Lisbon
5. Whoami? Caso não aproveite nada e só queira bater papo 😀
6. iFood? • Food tech company - based in Brazil • Employees: ~5300 • Tech team: ~2000 • Orders: +70.000.000 per month • Requests: 250k rps • Services: +3000 • Deployments: +300 per day • Kubernetes: ◦ +98% services ◦ +50 clusters
7. Agradecimentos Rodrigo Watanabe Gabriel Tiossi João Marques Henrique Dalssaso Carlos Motta Thiago de Francisco (Nullock)
8. Acertando vocabulário Distribuição kubernetes: • EKS, GKE, AKS , KubeADM, Cluster-API, Kops, etc… Distribuição: (no contexto desta apresentação) • Padronização de instalação e customização de pacotes. Um conjunto testado e homologado de pacotes de softwares que quando instalados provêem todas (ou quase todas) as funcionalidades para a sua necessidade.
9. O Problema O que você faz com um Kubernetes cluster “Vanila”? O que é um kubernetes cluster “Production Ready” para você? Quais ferramentas são: Desejáveis Importantes Imprescindiveis
10. O Problema • Logs • Scaling (horizontal e vertical) • Monitoring + Grafana + Alerting • Ingress • CNI • Security • Policies • Caos • Consul • External DNS • Kiam • Secrets Manager • Backup • Auth • Cost • CertManager • External Controller • Service Mesh • Open Telemetry • Custom controllers {
11. O Problema (2018) Como fazer o setup de tudo isso? # ls 01-serviceaccounts.sh 02-prometheus.sh 03-grafana.sh 04-certmanager.sh 05-nginx.sh 06-mserver.sh <poucos meses depois…> # ls 00-clusterroles.sh 01-serviceaccounts.sh 02a-prometheus.sh 02b-alert.sh 03-grafana.sh 04a-certmanager.sh 04b-fluend.sh 05-nginx.sh 06-mserver.sh 07-customalerts.sh Bash!
12. O Problema Scripts sem padrão: • interativos/ENVVARS • Helm packages: Comunidade / Vendor • Raw Manifests A escala: * • 4-5 clusters / 7-8 ferramentas • 10-12 clusters / 12-16 ferramentas • 50+ clusters / 30+ ferramentas
13. O Problema Evolução: • Helm only (ainda comunidade e Vendor) • ENVVARS • Values por clusters / automação Ainda MUITOS problemas: • Atualização de valores • Reconciliação • Múltiplos setups do mesmo pacote • Falta de customização • Não testável (updates de versão - pacotes e k8s) • Lento (manual) • Centralizado (uso restrito por outras áreas) • E muitos outros…
14. Nossos requisitos: • Baseado 100% em Helm • Padronizado • Simples (de preferência 1 comando) • Flexível • Extensível • Testável • Orientado por fluxo Git • Escalável * * De 1 até “∞” A Proposta
15. A Proposta Uma fonte de inspiração: • Instalação de pacotes • Padronização • Testes • Upgrades Distribuições Linux!
16. A Proposta Pontos fortes de distribuições: • Gerenciamento de pacotes * (Helm) • Estáveis (testes) • Padronizadas (interface) • Life cycle / Releases • Extensíveis • Orientadas para a comunidade Operam sobre a mesma base: • Linux Kernel / (Kubernetes)
17. A Proposta Padronizada e Extensível $ ls -l /etc/apt/sources.list.d/ brave-browser-release.list slack.list surfshark.list system76-ubuntu-pop-focal.list tailscale.list vscode.list $ cat /etc/apt/sources.list.d/slack.list deb https://packagecloud.io/slacktechnologies/slack/debian/ jessie main
18. A Proposta Life-cycle / Releases *
19. A Proposta Estável (Testes)
20. A Proposta Orientado para a comunidade (Distribuído) $ apt-cache show tipp10 Package: tipp10 Architecture: amd64 Version: 2.1.0-3build1 Priority: optional Section: universe/education Origin: Ubuntu Maintainer: Christoph Martin <christoph.martin@uni-mainz.de> Bugs: https://bugs.launchpad.net/ubuntu/+filebug Installed-Size: 2800 <snipped>
21. A implementação Distribution Default Values Version: 1.0 Mem: 1G Cpu: 100m Labels: A=1 Version: 1.3 Mem: 2G Hpa: min 3 Version: 2.0 PVC: 10G NodeSelector: Infra
22. Default Values A implementação Distribution Version: 1.0 Mem: 1G Cpu: 100m Labels: A=1 Version: 1.3 Mem: 2G Hpa: min 3 Version: 2.0 PVC: 10G NodeSelector: Infra
23. Default Values A implementação Distribution Version: 1.0 Mem: 1G Cpu: 100m Labels: A=1 Version: 1.3 Mem: 2G Hpa: min 3 Version: 2.0 PVC: 10G NodeSelector: Infra PVC: 15G Mem: 3G PVC: 15G Mem: 3G
24. Default Values A implementação Distribution Version: 2.0 PVC: 10G NodeSelector: Infra Core Team Packages Version: 1.0 Mem: 1G Cpu: 100m Labels: A=1 Sec Team Packages Ingress Team Packages …
25. Default Values A implementação Distribution Stable Version: 2.0 PVC: 10G NodeSelector: Infra Core Team Packages Sec Team Packages Ingress Team Packages Version: 1.0 Mem: 1G Cpu: 100m Labels: A=1 …
26. Default Values A implementação Distribution Edge Version: 3.0 PVC: 10G NodeSelector: Infra Core Team Packages Sec Team Packages Ingress Team Packages Version: 1.5 Mem: 1G Cpu: 100m Labels: A=1 …
27. A implementação Helmfile to the rescue… • O que é Helmfile? ◦ TL;DR - Um “wrapper” do Helm com esteróides, ou em outras palavras um Chart de Charts. • Algumas características ◦ Arquivos combináveis ◦ Template estendido - Sprig (incluindo no arquivo de values) ◦ Separação entre lógica e valores ◦ Múltiplas formas de referência (s3, git, local, OCI…) ◦ Transforma praticamente qualquer coisa em uma Helm Release ◦ Define interdependências das releases ⚠ • Aplica jsonpatch após renderização dos manifestos • Suporte a múltiplos Environments • Integração backends de Secrets • Hooks • Extra metadata / selectors
28. A implementação $ cat helmfile.yaml repositories: - name: bitnami url: https://charts.bitnami.com/bitnami - name: custom url: git+https://github.com/reactiveops/polaris@deploy/helm?ref=master releases: - name: external-dns namespace: machinery chart: bitnami/external-dns version: 3.2.6 values: - values/default.yaml - name: reactiveops chart: custom/reactiveops values: - image: tag: 1.4 - scheme: {{ env "SCHEME" | default "https" }} $ helmfile apply
29. A implementação $ cat meta-helmfile.yaml helmfiles: - path: git::https://github.com/drequena/grafana-package.git@/helmfile.yaml?ref=main values: - grafana: enabled: true resources: request: cpu: “100m” - path: git::https://github.com/drequena/prometheus-package.git@/helmfile.yaml?ref=1.0.1 values: - prometheus: enabled: true labels: - owner: “secteam” ...
30. A implementação Cluster Distribution Packages
31. $ cat myclusters/sales.yaml helmfiles: - path: git::https://github.com/drequena/distribution.git@/helmfile.yaml?ref=1.0 values: - prometheus: enabled: false - grafana: url: “graphs.company.net” A implementação - path: git::https://github.com/drequena/cert-manager-package.git@/helmfile.yaml?ref=1.3 values: - cert-manager: resources: request: cpu: 250m
32. $ cat distribution/helmfile.yaml helmfiles: - path: git::https://github.com/drequena/grafana-package.git@/helmfile.yaml?ref=main values: - <optional-distribution-default-values> - {{ .Values | get "grafana" dict | toYaml | indent 6 | trim}} - path: git::https://github.com/drequena/prometheus-package.git@/helmfile.yaml?ref=1.0.1 values: - {{ .Values | get "prometheus" dict | toYaml | indent 6 | trim}} A implementação
33. $ cat packages/prometheus/helmfile.yaml repositories: - name: prometheus url: https://charts.prometheus.org/prometheus releases: - name: prometheus condition: prometheus.enabled needs: - prometheus-operator namespace: monitoring chart: prometheus/prometheus version: 2.49.1 values: - values/default.yaml - {{ .Values | get "prometheus" dict | toYaml | indent 6 | trim}} A implementação
34. A implementação Juntando tudo
35. A implementação Cluster (sandbox) $ helmfile apply $ helmfile diff commit values: - prometheus: resources: request: mem: 2G [INFO ] + status: [INFO ] + prometheus:: [INFO ] + resources: [INFO ] + request: [INFO ] - memory: 2G [INFO ] + memory: 2G [ERROR ] at least one change was identified [ERROR ] helmfile diff failed with code=2 [INFO ] + status: [INFO ] + prometheus:: [INFO ] + resources: [INFO ] + request: [INFO ] - memory: 2G [INFO ] + memory: 2G [INFO ] New release applied
36. commit helmfile: -path: git::https://… values: - metricserver: custom: “newvalue” A implementação Distribution (Edge) Clusters $ helmfile apply $ helmfile diff [INFO ] + status: [INFO ] + metricserver:: [INFO ] + labels: [INFO ] + custom: “newvalue” [ERROR] at least one change was identified [ERROR] helmfile diff failed with code=2 [INFO ] + status: [INFO ] + metricserver:: [INFO ] + labels: [INFO ] + custom: “newvalue” [INFO ] New release applied
37. A implementação Distribution Cluster Package $ helmfile apply $ helmfile diff commit releases: - name: prometheus chart: prometheus/prometheus version: 2.38.0 Tag: 1.1.3 commit helmfile: -path: git::https://…?ref:1.1.3 Tag: 2.0.1 commit helmfile: -path: git::https://…?ref:2.0.1
38. A implementação Clusters Distribution Sales Logistics cluster.yaml cluster.yaml Core Sec L7 helmfile.yaml nginx-ingress certmanager kubecost prometheus
39. A implementação Mas e os testes?
40. Testes • Konformance (deprecated) ◦ Testava todos os pacotes da distro de forma contínua ◦ 1 instância por cluster ◦ Golang + ginkgo + custom library ◦ Problemas: ▪ Pouco flexível ▪ Difícil manutenção • Novos testes (WIP) ◦ Testes unitário (pacotes próprios) - Terratest ◦ Testes de negócio (Cuelang) ◦ Testes de integração (Golang) ▪ “autopkgtest” • CI (triggers) ◦ Pacote ◦ Distribuição ◦ Kubernetes cluster A implementação
41. A implementação MonitStack helmfile.yaml CI test cluster Stable values tests values.yaml.gotpl unit-tests.go integration-tests.go Local Minikube depends.yaml MonitStack Prometheus Operator $ helmfile install $ go test unit-tests.go $ helmfile install $ go integration-tests.go $ helmfile destroy
42. Conclusões Pontos Fortes • Helm ✅ • Flexível ✅ • Escalável ✅⚠ • Extensível ✅ • Padronizado ✅ • O conceito é modular e reaproveitável ✅ Pontos de atenção e melhoria • Checagem de dependência entre helmfiles separados⚠ ✅ • Simples? Rastreabilidade de valores é difícil ⚠ • Baixo paralelismo dependendo da estrutura ⚠
43. • Helm https://helm.sh/ • Helmfile Docs https://helmfile.readthedocs.io/en/latest/ • Helmfile git https://github.com/helmfile/helmfile • Terratest https://terratest.gruntwork.io/ • Cuelang https://cuelang.org/ • Dependabot https://github.com/dependabot • Blueprint repos: https://github.com/drequena/clusters • Timoni https://timoni.sh/ • Timoni git https://github.com/stefanprodan/timoni • Helm-Unit-tests https://github.com/anikin-aa/helm-unittest • Debian CI https://ci.debian.net/status/ Links e referências
44. Obrigado! Perguntas?
45. Onde me encontrar? https://www.linkedin.com/in/danielrequena/ https://bolha.us/@requena https://github.com/drequena/ https://speakerdeck.com/drequena https://twitter.com/Daniel_Requena