Container Checkpointing in Kubernetes Met een Aangepaste API

Probleemstelling

Uitdaging

Organisaties die containerapplicaties in Kubernetes uitvoeren, moeten vaak de status van draaiende containers vastleggen en behouden voor:

  • Rampenherstel
  • Applicatiemigratie
  • Debuggen/oplossen van problemen
  • Staat behouden
  • Omgevingsreproductie

Er is echter geen eenvoudige, geautomatiseerde manier om:

  1. Containercontrolepunten on-demand te maken
  2. Deze controlepunten op te slaan in een gestandaardiseerd formaat
  3. Ze gemakkelijk toegankelijk te maken over clusters heen
  4. Controlepuntactivering via een standaardinterface te activeren

Huidige beperkingen

  • Handmatige controlepuntcreatie vereist directe toegang tot clusters
  • Geen gestandaardiseerd opslagformaat voor controlepunten
  • Beperkte integratie met containerregistries
  • Gebrek aan programatische toegang voor automatisering
  • Complex coördinatie tussen containerd en opslagsystemen

Oplossing

Een Kubernetes sidecar-service die:

  1. Controlepuntfunctionaliteit blootstelt via REST API
  2. Controlepunten automatisch omzet naar OCI-compatibele images
  3. Images opslaat in ECR voor gemakkelijke distributie
  4. Integreert met bestaande Kubernetes-infrastructuur
  5. Biedt een gestandaardiseerde interface voor automatisering

Dit lost de kernproblemen op door:

  • Het automatiseren van het controlepuntenproces
  • Standaardiseren van checkpoint-opslag
  • Checkpoint’s draagbaar maken
  • Programmatische toegang inschakelen
  • Integratie met bestaande workflows vereenvoudigen

Doelgebruikers:

  • DevOps-teams
  • Platform engineers
  • Applicatieontwikkelaars
  • Site Betrouwbaarheidsingenieurs (SREs)

Forensisch containercheckpointing is gebaseerd op Checkpoint/Restore In Userspace (CRIU) en maakt het mogelijk om statuskopieën te maken van een draaiende container zonder dat de container weet dat deze wordt gecheckt. De kopie van de container kan meerdere keren worden geanalyseerd en hersteld in een sandbox-omgeving zonder dat de oorspronkelijke container hiervan op de hoogte is. Forensisch containercheckpointing werd geïntroduceerd als een alfaversie in Kubernetes v1.25.

Dit artikel zal u begeleiden bij het implementeren van Golang-code die kan worden gebruikt om een containercheckpoint te nemen met behulp van een API.

De code neemt een pod-identificatie, haalt de container-ID op van containerd als invoer, en gebruikt vervolgens het ctr commando om de specifieke container in de k8s.io namespace van containerd te checken:

Vereisten

  • Kubernetes-cluster
  • Installeer de ctr commandline tool. Als je in staat bent om ctr commando’s uit te voeren op de kubelet of worker node; zo niet, installeer of pas de AMI aan om de ctr te bevatten.
  • kubectl geconfigureerd om te communiceren met je cluster
  • Docker lokaal geïnstalleerd
  • Toegang tot een containerregister (bijv. Docker Hub, ECR)
  • Helm (voor het installeren van Nginx Ingress Controller)

Stap 0: Code om een container checkpoint te maken met GO

Maak een bestand met de naam checkpoint_container.go met de volgende inhoud:

Go

 

Stap 1: Initialiseer de go-module

Shell

 

Wijzig het go.mod bestand:

Go

 

Voer het volgende commando uit:

Shell

 

Stap 2: Bouw en publiceer een Docker-image

Maak een Dockerfile in dezelfde map:

Dockerfile

 

Deze Dockerfile doet het volgende:

  1. Gebruikt golang:1.20 als de build stage om je Go-toepassing te compileren.
  2. Gebruikt amazonlinux:2 als de uiteindelijke basisimage.
  3. Installeert de AWS CLI, Docker (inclusief containerd), en skopeo met behulp van yum en amazon-linux-extras.
  4. Kopieert de gecompileerde Go-binair van de build stage.
Shell

 

Vervang <jouw-docker-repo> door je daadwerkelijke Docker-repository.

Stap 3: Pas de RBAC-resources toe

Maak een bestand met de naam rbac.yaml:

YAML

 

Pas de RBAC-resources toe:

Shell

 

Stap 4: Maak een Kubernetes-implementatie

Maak een bestand met de naam deployment.yaml:

YAML

 

Pas de implementatie toe:

Shell

 

In deployment.yaml, werk het volgende bij:

YAML

Stap 5: Kubernetes-service

Maak een bestand met de naam service.yaml:

YAML

 

Pas de service toe:

Shell

 

Stap 6: Installeer Ngnix Ingress Controller

Shell

 

Stap 7: Maak Ingress-bronnen

Maak een bestand met de naam ingress.yaml:

YAML

 

Pas de Ingress toe:

Shell

 

Stap 8: Test de API

Shell

 

Shell

 

Vervang <EXTERNAL-IP> door het daadwerkelijke externe IP-adres.

Extra Overwegingen

  1. Beveiliging.
    • Implementeer HTTPS door TLS-certificaten in te stellen
    • Voeg authenticatie toe aan de API
  2. Monitoring. Stel logging en monitoring in voor de API en het controlepuntproces.
  3. Resourcebeheer. Configureer resourcenaanvragen en limieten voor de sidecar-container.
  4. Foutafhandeling. Implementeer robuuste foutafhandeling in de Go-toepassing.
  5. Testen. Test de opstelling grondig in een niet-productieomgeving voordat u deze in productie implementeert.
  6. Documentatie. Onderhoud duidelijke documentatie over hoe de checkpoint-API te gebruiken.

Conclusie

Deze installatie implementeert de controlecontainer als een sidecar in Kubernetes en maakt de functionaliteit ervan toegankelijk via een API die van buiten het cluster bereikbaar is. Het biedt een flexibele oplossing voor het beheren van containercontroles in een Kubernetes-omgeving.

Specifiek voor AWS/EKS

Stap 7: Installeer de AWS Load Balancer Controller

In plaats van de Nginx Ingress Controller zullen we de AWS Load Balancer Controller gebruiken. Deze controller zal ALB’s maken en beheren voor onze Ingress-bronnen.

1. Voeg de EKS-chartrepository toe aan Helm:

Shell

 

2. Installeer de AWS Load Balancer Controller:

Shell

 

Vervang <jouw-clusternaam> door de naam van je EKS-cluster.

Let op: Zorg ervoor dat je de benodigde IAM-machtigingen hebt ingesteld voor de AWS Load Balancer Controller. Je vindt het gedetailleerde IAM-beleid in de AWS-documentatie.

Stap 8: Maak Ingress-bron

Maak een bestand met de naam ingress.yaml:

YAML

 

Voer de Ingress uit:

Shell

 

Stap 9: Test de API

1. Haal de ALB-DNS-naam op:

Shell

 

Zoek naar het VELD ADRES, dat de DNS-naam van de ALB zal zijn.

2. Stuur een testverzoek:

Shell

 

Vervang <ALB-DNS-NAAM> door de daadwerkelijke DNS-naam van je ALB uit stap 1.

Extra overwegingen voor AWS ALB

1. Beveiligingsgroepen. De ALB zal automatisch een beveiligingsgroep hebben die is aangemaakt. Zorg ervoor dat deze inkomend verkeer op poort 80 (en 443 als je HTTPS instelt) toestaat.

2. SSL/TLS: Om HTTPS in te schakelen, kun je de volgende annotaties aan je Ingress toevoegen:

YAML

 

3. Toegangslogs. Schakel toegangslogs voor je ALB in door het volgende toe te voegen:

YAML

 

4. WAF-integratie. Als je AWS WAF met je ALB wilt gebruiken, kun je het volgende toevoegen:

YAML

 

5. Authenticatie. Je kunt authenticatie instellen met behulp van Amazon Cognito of OIDC door de juiste annotaties voor de ALB Ingress Controller te gebruiken.

Deze wijzigingen zullen je Ingress instellen met behulp van een AWS Application Load Balancer in plaats van Nginx. De ALB Ingress Controller zal automatisch de ALB provisioneren en configureren op basis van je Ingress-bron.

Conclusie

Vergeet niet ervoor te zorgen dat je EKS-cluster de nodige IAM-machtigingen heeft om ALB’s te creëren en te beheren. Dit houdt doorgaans in dat je een IAM-beleid en een serviceaccount met de juiste machtigingen moet aanmaken.

Deze opstelling zal nu gebruikmaken van AWS’s native load-balancingoplossing, die goed integreert met andere AWS-diensten en kosteneffectiever kan zijn in een AWS-omgeving.

Source:
https://dzone.com/articles/container-checkpointing-kubernetes-api