Cilium no EKS [Lab Session]

eBPF-based Networking, Observability, Security
Cilium is an open source, cloud native solution for providing, securing, and observing network connectivity between workloads, fueled by the revolutionary Kernel technology eBPF

Source: https://cilium.io/

Network & Service Mesh (sidecarless)

Source: https://cilium.io/

---

Arquitetura do Lab

Repositórios:

• EKS: https://github.com/paulofponciano/EKS-Cilium
• App Microsserviços: https://github.com/msfidelis/nutrition-overengineering

Deploy da infra

git clone https://github.com/paulofponciano/EKS-Cilium.git
cd EKS-Cilium

Altere as variáveis necessárias para o seu lab em variables.tfvars

tofu init
tofu plan --var-file variables.tfvars
tofu apply --var-file variables.tfvars

Por padrão, o EKS vai subir com Amazon VPC CNI, podemos ver o DaemonSet 'aws-node'. No cenário desse lab, removemos esse DaemonSet e fazemos a reciclagem dos nodes - Executando um Terminate nos nodes atuais. Com isso, o EKS vai subir novos nodes para o replace. Como CNI, utilizamos o Cilium.

kubectl get ds -A
kubectl delete ds aws-node -n kube-system

O Terminate dos nodes iniciais pode ser feito na console ou CLI. ⚠️ É importante tomar cuidado nessa ação para não afetar nenhum outro recurso que não seja do lab.

Após a reciclagem dos nodes, podemos ver que está tudo certo no namespace 'kube-system':

Usando o cilium-cli, podemos ver o status do Cilium neste cluster:

cilium status

Se conectarmos diretamente em um node, podemos ver a conflist do Cilium CNI:

Deploy da app

Utilizamos uma app baseada em microsserviços, do grande Matheus Fidelis @fidelissauro. Essa app utiliza gRPC em sua comunicação interna.

git clone https://github.com/msfidelis/nutrition-overengineering.git
cd nutrition-overengineering/samples/cilium

Ajuste o 'host' no manifesto de ingress da health-api se necessário. Aqui ficou assim:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: health-api
  namespace: health-api
spec:
  ingressClassName: cilium
  rules:
  - host: health-api.pauloponciano.digital
    http:
      paths:
      - backend:
          service:
            name: health-api
            port:
              number: 8080
        path: /
        pathType: Prefix

Foi criado manualmente um registro no DNS público apontando o host para o CNAME do Network Load Balancer.

Apply dos manifestos:

kubectl apply -f .

Podemos fazer um teste rápido e ver o retorno da api:

for i in {1..3}
do
  curl --location --request POST 'http://health-api.pauloponciano.digital/calculator' \
  --header 'Content-Type: application/json' \
  --data-raw '{
     "age": 26,
     "weight": 90.0,
     "height": 1.77,
     "gender": "M",
     "activity_intensity": "very_active"
  }' --silent | jq .
done

Hubble UI e Prometheus

Da mesma forma que foi criado o registro no DNS público para a health-api, também foram criados registros para acesso ao hubble-ui e o grafana (o grafana faz parte do kube-prometheus-stack).

Vamos aumentar o volume na health-api utilizando o k6 com o script abaixo:

import http from 'k6/http';

export default function () {
  const url = 'http://health-api.pauloponciano.digital/calculator';
  const payload = JSON.stringify({
    age: 26,
    weight: 90.0,
    height: 1.77,
    gender: 'M',
    activity_intensity: 'very_active',
  });

  const params = {
    headers: {
      'Content-Type': 'application/json',
    },
  };

  const response = http.post(url, payload, params);
  console.log(response.body);
}

k6 run http_k6.js --vus=200 --duration=60m

Agora podemos ver no Hubble as interações entre os serviços muito próximo do real time:

Como ele é interativo, é possível ver mais detalhes das conexões focando em cada componente:

Agora vamos dar uma olhada no Grafana. Quando foi feito o deploy do kube-prometheus-stack via Helm na execução de terraform, também foram importados dois dashboards:

Acessando o dashboard Hubble L7 HTTP Metrics by Workload, podemos ver algumas métricas dos microsserviços.

health-api:

recommendations-grpc:

imc-grpc:

Tetragon e Loki

O Tetragon também é executado como um DaemonSet. Com ele podemos ver as Syscalls que estão acontecendo no ambiente e ele tem a capacidade de fazer enforce. No lab, foi feito deploy do Promtail + Loki, com eles, guardamos esses eventos do Tetragon em um bucket do S3 e podemos visualizar no Grafana.

Tetragon Events dashboard:

Executando aleatoriamente alguns comandos de 'kubectl exec', e com as queries do Loki já configuradas, pegamos alguns eventos que podem ser considerados maliciosos. Isso graças à quantidade de informações que o Tetragon gera:

---

Recomendo de verdade que assistam à talk do Matheus Fidelis na LINUXtips, mostrando isso ao vivo e com as explicações sobre o poder e as possibilidades que o eBPF proporciona para tecnologias como o Cilium.

---

Keep shipping! 🐳