DEV Community

Cover image for Cilium no EKS [Lab Session]
AWS Community Builders profile image Paulo Ponciano
Paulo Ponciano for AWS Community Builders

Posted on • Edited on

Cilium no EKS [Lab Session]

#community #kubernetes #cilium #ebpf

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:

Deploy da infra 

git clone https://github.com/paulofponciano/EKS-Cilium.git
Enter fullscreen mode Exit fullscreen mode 
cd EKS-Cilium
Enter fullscreen mode Exit fullscreen mode

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

tofu init
Enter fullscreen mode Exit fullscreen mode 
tofu plan --var-file variables.tfvars
Enter fullscreen mode Exit fullscreen mode 
tofu apply --var-file variables.tfvars
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode 
kubectl delete ds aws-node -n kube-system
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode 
cd nutrition-overengineering/samples/cilium
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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 .
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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 a volume na health-api utilizando o k6 com 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); }
Enter fullscreen mode Exit fullscreen mode 
k6 run http_k6.js --vus=200 --duration=60m
Enter fullscreen mode Exit fullscreen mode

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 uma 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 a quantidade de informações que o Tetragon gera:

Recomendo de verdade que assistam a 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! 🐳

Top comments (0)