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 eBPFSource: 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. Valeu Matheus!
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 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);
}
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 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)