Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Criando uma distribuição Kubernetes

drequena
April 24, 2023

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.

drequena

April 24, 2023
Tweet

More Decks by drequena

Other Decks in Technology

Transcript

  1. Agenda • $ whoami • Agradecimentos • Acertando vocabulário •

    O Problema • A Proposta • A implementação • Links e referências
  2. 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
  3. 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
  4. 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.
  5. 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
  6. 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 {
  7. 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!
  8. 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
  9. 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…
  10. 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
  11. A Proposta Uma fonte de inspiração: • Instalação de pacotes

    • Padronização • Testes • Upgrades Distribuições Linux!
  12. 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)
  13. 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
  14. 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 <[email protected]> Bugs: https://bugs.launchpad.net/ubuntu/+filebug Installed-Size: 2800 <snipped>
  15. 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
  16. 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
  17. 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
  18. 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 …
  19. 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 …
  20. 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 …
  21. 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
  22. 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
  23. 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” ...
  24. $ 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
  25. $ 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
  26. $ 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
  27. 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
  28. 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
  29. 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
  30. A implementação Clusters Distribution Sales Logistics cluster.yaml cluster.yaml Core Sec

    L7 helmfile.yaml nginx-ingress certmanager kubecost prometheus
  31. 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
  32. 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
  33. 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 ⚠
  34. • 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