DEV Community

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

Posted on

9 2 1

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)

Image description

Image description

Source: https://cilium.io/


Arquitetura do Lab

Image description

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

Image description

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

Image description

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.

Image description

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

Image description

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

cilium status
Enter fullscreen mode Exit fullscreen mode

Image description

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

Image description

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
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

Image description

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

Image description

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

Image description

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

Image description

Image description

Image description

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

Image description

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:

Image description

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

health-api:

Image description

recommendations-grpc:

Image description

imc-grpc:

Image description

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:

Image description

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:

Image description

Image description


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! 🐳

Please leave your appreciation by commenting on this post!

Okay, let's go.

Top comments (0)

Best Practices for Running  Container WordPress on AWS (ECS, EFS, RDS, ELB) using CDK cover image

Best Practices for Running Container WordPress on AWS (ECS, EFS, RDS, ELB) using CDK

This post discusses the process of migrating a growing WordPress eShop business to AWS using AWS CDK for an easily scalable, high availability architecture. The detailed structure encompasses several pillars: Compute, Storage, Database, Cache, CDN, DNS, Security, and Backup.

Read full post

👋 Kindness is contagious

Discover a treasure trove of wisdom within this insightful piece, highly respected in the nurturing DEV Community enviroment. Developers, whether novice or expert, are encouraged to participate and add to our shared knowledge basin.

A simple "thank you" can illuminate someone's day. Express your appreciation in the comments section!

On DEV, sharing ideas smoothens our journey and strengthens our community ties. Learn something useful? Offering a quick thanks to the author is deeply appreciated.

Okay