Qu'est-ce que Bottlerocket et comment l'utiliser dans EKS ?

Si vous êtes en pleine phase de conformité ou si vous essayez de commencer un parcours difficile, vous pourriez rencontrer de nombreuses alertes rouges pour les instances EC2 que vous êtes en train de lancer. De plus, vous commencez également à vous poser des questions sur l'utilisation de vos images Amazon Linux par défaut, à savoir si elles sont adaptées à votre cas d'utilisation ? Vous vous demandez peut-être s'il existe ou s'il existe des AMI personnalisées susceptibles de prendre en charge vos charges de travail conteneurisées, de réduire les frais liés aux correctifs et de fournir une meilleure sécurité.

Bottlerocket est un système d'exploitation spécialement conçu pour Linux et méticuleusement conçu pour servir d'hôte de conteneurs optimal. Conçu pour réduire les frais généraux inutiles, Bottlerocket apparaît comme une solution simple et efficace adaptée aux exigences modernes des applications conteneurisées.

💡

Cette image Linux spécialisée est conçue dans le but de rationaliser l'orchestration des conteneurs tout en donnant la priorité à la sécurité, à la conformité et à l'efficacité opérationnelle.

Valeurs fondamentales de Bottlerocket

Bottlerocket repose sur trois valeurs fondamentales principales détaillées ci-dessous

Être minimal

Pourquoi avoir des centaines d'applications indésirables alors que je ne veux exécuter qu'une image Docker. Bottlerocket propose une approche minimaliste qui consiste à n'avoir que les emballages requis à son image, afin qu'il devienne léger et plus facile à gérer.

Tous les packages requis sont installés dans une seule image Linux, qui est une combinaison de différents services AWS et de différentes plateformes/architectures prises en charge. Chaque combinaison est appelée variante.

Par exemple bottlerocket-AWS-K8S-1.28-x86_64-1.16 est un variante pour l'image Bottlerocket de la version 1.28 d'EKS sur x86_64 architecture. Une autre variante pour ECS serait quelque chose comme bottlerocket-aws-ecs-2-x86_64-1.16

Mises à jour sécurisées

Bottlerocket repose fondamentalement sur les concepts de poubelle qui emballent tout dans une seule image AMI et, par conséquent, pas de gestionnaire de paquets.

Comme tout est lié à une image, pour mettre à jour quoi que ce soit, vous devez simplement mettre à jour la version de l'image qui contiendrait la dernière version (stable et sécurisée) de tous les composants testés, évitant ainsi de gérer les packages séparément.

Le côté gauche montre l'instance en cours d'exécution où la version en cours d'exécution dispose d'une mise à jour de version plus récente. Ce fichier est en cours de téléchargement dans la même instance, mais à un emplacement distinct. Une fois le téléchargement terminé, un redémarrage a lieu pour changer la nouvelle version en tant que source principale du noyau.

Sécurité

La sécurité est la principale préoccupation de l'instance des fusées à bouteilles et ils font peu de choses pour s'assurer que

1. Le système de fichiers racine est immuable — Lorsque le système de fichiers racine devient immuable, seules les versions stables et testées font partie de l'image d'instance. dm-verity est utilisé pour une intégrité transparente afin de vérifier le système de fichiers à côté d'un hachage racine en utilisant Marbre Erkle.
2. SELinux est appliqué par défaut
3. Pas d'obus, donc moins de risques d'attaques à distance.

Concepts

Vous trouverez ci-dessous quelques concepts de haut niveau pour en savoir plus sur les instances Bottlerocket

Piloté par API

Comme les instances Bottlerocket n'ont pas de shell, comment interrogeriez-vous des éléments tels que la version de l'image et ses mises à jour, les opérations de base ou les tâches de niveau administrateur ? Pour résoudre ces tâches, bottlerocket fournit une API HTTP bien définie qui peut résoudre tous ces problèmes pour vous, tout en garantissant que seules les opérations légitimes sont effectuées sur les instances avec des étapes précises pour chaque opération.

Conteneurs Bootstrap

Comme nous l'avons déjà dit, le système de fichiers racine est immuable et est vérifié par dm-verity , le /etc devient la partie de votre système de fichiers mutable en utilisant tmpfs.

À l'aide de conteneurs bootstrap, vous pouvez activer certains programmes ou fonctionnalités que vous souhaitez installer au-dessus du système de fichiers racine lors du démarrage de votre instance. Il s'agit d'un ensemble de conteneurs qui s'exécutent au-dessus du conteneur d'exécution conteneurisé . Vous pouvez exécuter plusieurs conteneurs bootstrap de ce type et le démarrage de l'instance se terminera une fois que tous les conteneurs seront fermés avec succès. Vous pouvez appliquer certaines conditions de sortie à ces conteneurs bootstrap. Vous pouvez en savoir plus à ce sujet ici.

Par défaut, le démarrage sécurisé est également activé pour s'assurer que le bon logiciel est déchargé par le microprogramme UEFI lors de la tentative de démarrage de la machine.

Composantes

Les instances de Bottlerocket sont spécifiques aux charges de travail conteneurisées et, pour cela, deux ensembles de conteneurisé les instances s'exécutent. L'un d'eux est utilisé pour exécuter vos conteneurs normaux sur votre moteur d'orchestration, comme kubelet et l'autre consiste à exécuter un conteneur d'administration qui peut agir comme un shell pseduo pour que vous puissiez exécuter des appels HTTP pilotés par API en utilisant apiclient , un outil fourni par bottlerocket pour exécuter des requêtes d'API et pour déboguer vos instances. Ces conteneurs d'administration ne garantissent pas la mutabilité sur le système de fichiers racine.

Utilisation des instances de Bottlerocket dans EKS

L'utilisation d'instances bottlerocket dans vos nœuds EKS est très simple. Nous devons simplement nous assurer que nous transmettons les bonnes AMI et les bonnes étiquettes aux nœuds afin que l'opérateur de mise à jour de bottlerocket puisse réellement vérifier les mises à jour des images sur ces nœuds et les redémarrer chaque fois qu'une mise à jour est disponible. Nous discuterons prochainement de l'opérateur de mise à jour de Bottlerocket.

Dans notre déploiement EKS actuel, nous déployons des nœuds sous deux formes

1. terraform — qui fait tourner le groupe de nœuds initial pour nous. Ce groupe de nœuds initial est utilisé pour exécuter charpentier des pods qui font ensuite tourner le nœud selon les besoins
2. nœuds Karpenter : ces nœuds sont actionnés par le contrôleur Karpenter chaque fois qu'une charge de travail est en attente.

Changements apportés à Terraform EKS

Pour apporter des modifications à notre code terraform pour EKS, nous passons une option eks_managed_node_groups dans lequel nous ajoutons un pool de nœuds supplémentaire, quelque chose comme ceci

eks_managed_node_groups = {
bouteille = {
enable_bootstrap_user_data = vrai
plateforme = « bottlerocket »
bootstrap_extra_args = <<-EOT
[paramètres]
« motd » = « TrueFoundry : plateforme MLOps »
[settings.kubernetes.node-labels]
« bottlerocket.aws/updater-interface-version » = « 2.0.0 »
EOT

instance_types = local.env.user_input.tfy_control_plane.enabled == « Vrai » ? [« c6a.xlarge », « m6a.xlarge », « c6i.xlarge », « r6a.xlarge »] : [« c6a.large », « m6a.large », « r6a.xlarge »]
capacity_type = « SPOT »
ami_type = « BottleRocket_x86_64"
# Non obligatoire ni utilisé - évitez de baliser deux groupes de sécurité avec la même étiquette
create_security_group = faux

# Assurez-vous d'avoir une capacité suffisante pour faire fonctionner 2 capsules Karpenter
taille_minimale = 2
taille_maximale = 2
taille_souhaitée = 2

étiquettes = {
« class.truefoundry.io » = « bouteille »
}

balises = {
# Cela marquera le modèle de lancement créé pour être utilisé par Karpenter
« karpenter.sh/discovery » = local.env.cluster_name
}
block_device_mappings = {
xvdb = {
nom_appareil = « /dev/xvdb »
ebs = {
taille_volume = 100
type_volume = « gp3 »
débit = 150
delete_on_termination = vrai
}
}
}
}
}


Dans ceux-ci, il y a quelques points importants à noter dans la spécification ci-dessus.

1. Nous devons passer le « bottlerocket.aws/updater-interface-version » = « 2.0.0 » afin que l'opérateur de mise à jour de bottlerocket puisse l'interfacer.
2. ami_type = « BOTTLEROCKET_X86_64" — pour passer la fusée à bouteilles (AMI)
3. bloquer le mappage de l'appareil vers /dev/xvdb — bottlerocket ne peut pas être utilisé /dev/xvda car l'AMI personnalisée l'utilise /dev/xvda pour stocker l'image racine d'une taille de 2 Go.

Charpentier

Karpenter est une méthode relativement récente de dimensionnement automatique de vos charges de travail. En fonction du calcul requis, il essaiera d'apporter le nœud de la bonne taille, en compressant simultanément les ensembles de démons afin que toutes les charges de travail nécessaires soient exécutées sur le nœud.

Nous comptons beaucoup sur Karpenter pour gérer les charges de travail de calcul et de GPU. Karpenter a un concept appelé Approvisionneur(qui est désormais obsolète et nommée Pool de nœuds ) définissant la taille autorisée des nœuds avec les bonnes étiquettes et les bonnes teintes si nécessaire. De plus, grâce à Modèles de code AWS (qui est désormais obsolète et nommée Aucune classe ) vous pouvez définir le modèle du nœud, en indiquant le groupe de sécurité, la famille d'AMI et la taille de volume racine appropriés.

Vous pouvez maintenant comprendre où nous pourrions avoir à apporter des modifications au Karpenter. approvisionneur et modèles de node AWS pour s'assurer que Karpenter fait tourner les instances de Bottlerocket.

1. Nous donnons le label « bottlerocket.aws/updater-interface-version » = « 2.0.0 » dans le approvisionneur section.
2. Nous donnons au volume de la racine /dev/xvdb et Famille AMI dans le rôle de : Bottlerocket dans modèle de node AWS

Grâce à cela, Karpenter est également en mesure de prendre en charge les instances Bottlerocket.

J'essaie d'éviter de mentionner le approvisionneur et modèle de node AWS spécifications car elles sont désormais obsolètes par Karpenter dans les anciennes versions.

Opérateur de mise à jour de Bottlerocket (brupop)

opérateur de mise à jour de Bottlerocket ou brupop est un contrôleur qui permet de maintenir à jour vos instances de bottlerocket dans un cluster EKS.

Motif Brupop

Il se compose de trois éléments principaux

1. Contrôleur — Le contrôleur est le cerveau principal qui vérifie les mises à jour des images en amont et orchestre l'ensemble du processus de mise à jour
2. Agent : l'agent s'exécute sur chaque nœud qui reçoit des instructions du contrôleur pour effectuer l'opération
3. Serveur API : API qui authentifie l'agent et les appels d'API qu'il essaie d'effectuer

Installation de brupop

Brupop a deux tableaux de barre que nous devons installer

• bottlerocket-shadow — qui se compose de BottleRocketShadow CRD

Version de l'API : argoproj.io/v1alpha1
type : Application
métadonnées :
nom : bottlerocket-shadow
espace de noms : argocd
finaliseurs :
- finaliseurs-ressources.argocd.argoproj.io
spécification :
destination :
espace de noms : brupop-bottlerocket-aws
serveur : https://kubernetes.default.svc
projet : par défaut
source :
graphique : bottlerocket-shadow
URL de référence : https://bottlerocket-os.github.io/bottlerocket-update-operator
Révision cible : 1.0.0
Politique de synchronisation :
automatique : {}
Options de synchronisation :
- CreateNamespace=true

• opérateur de mise à jour de bouteilles — qui comprend l'opérateur réel

Version de l'API : argoproj.io/v1alpha1
type : Application
métadonnées :
nom : bottlerocket-update-operator
espace de noms : argocd
finaliseurs :
- finaliseurs-ressources.argocd.argoproj.io
spécification :
destination :
espace de noms : brupop-bottlerocket-aws
serveur : https://kubernetes.default.svc
projet : par défaut
source :
graphique : bottlerocket-update-operator
URL de référence : https://bottlerocket-os.github.io/bottlerocket-update-operator
Révision cible : 1.3.0
Politique de synchronisation :
automatique : {}
Options de synchronisation :
- CreateNamespace=true


Assurez-vous que l'espace de noms de destination est toujours brupop-bottlerocket-aws comme indiqué dans leur organigramme.

Le contrôleur utilise BottleRocketShadow CRDS pour gérer vos nœuds. Plus tôt dans le document, nous avons demandé aux nœuds d'avoir des étiquettes « bottlerocket.aws/updater-interface-version » = « 2.0.0 » . Cela a été fait pour que le contrôleur puisse identifier les instances de bottlerocket que vous souhaitez que brupop contrôle pour vous.

Vous pouvez simplement vérifier l'état de vos nœuds en exécutant

$ kubectl get brs -n brupop-bottlerocket-aws
NOM, ÉTAT, VERSION, ÉTAT CIBLE, VERSION CIBLE, NOMBRE DE PANNES
<no value>brs-ip-xx-xx-1-243.ec2.internal Inactif 1.17.0 Inactif 0
<no value>brs-ip-xx-xx-14-136.ec2.internal Inactif 1.17.0 Inactif 0
<no value>brs-ip-xx-xx-31-78.ec2.internal Inactif 1.17.0 Inactif 0


Support Bottlerocket pour TrueFoundry

Nous mangeons True Foundry prenez en charge les instances bottlerocket pour prendre en charge à la fois les charges de travail du processeur et du GPU, afin que l'ensemble de votre parcours MLOps puisse désormais être concentré sur le développement du bon code pour résoudre les bons problèmes, en allégeant la pression sur les correctifs maintenables et les correctifs de sécurité.

Questions fréquemment posées

Qu'est-ce qu'un bottlerocket ?

Bottlerocket est un système d'exploitation basé sur Linux spécialement conçu pour héberger des conteneurs de manière optimale. Il réduit les frais généraux liés aux applications conteneurisées en étant simple et efficace. Ce système d'exploitation spécialisé rationalise l'orchestration des conteneurs dans EKS, en donnant la priorité à une sécurité, une conformité et une efficacité opérationnelle renforcées pour les charges de travail modernes.

Pourquoi utiliser Bottlerocket ?

Utilisez **bottlerocket** pour son design minimaliste spécialement conçu, optimisé pour les charges de travail conteneurisées. Il renforce la sécurité grâce à un système de fichiers racine immuable et propose des mises à jour rationalisées basées sur des images, éliminant ainsi la gestion complexe des packages. Ce système d'exploitation spécialisé améliore l'efficacité opérationnelle et la conformité, ce qui le rend idéal pour les clusters EKS.

Le mode automatique d'Eks utilise-t-il Bottlerocket ?

Les outils de mise à l'échelle automatique d'EKS tels que Karpenter peuvent en effet tirer parti de Bottlerocket. Vous configurez Karpenter pour provisionner des nœuds à l'aide des AMI Bottlerocket, fournissant ainsi un hôte sécurisé, minimal et efficace pour vos applications conteneurisées. Cette intégration garantit des opérations rationalisées et une sécurité renforcée pour vos charges de travail EKS dynamiques.

Qu'est-ce qu'un Bottlerocket AMI ?

Une AMI bottlerocket est une Amazon Machine Image préconfigurée avec Bottlerocket OS. Cette image Linux spécialisée est un hôte de conteneur minimal et sécurisé conçu pour les applications conteneurisées modernes. Il simplifie la gestion et garantit des mises à jour sécurisées en regroupant tous les composants dans une seule image, ce qui est idéal pour les environnements EKS aux États-Unis.

Est-ce que Bottlerocket est immuable ?

Oui, le système de fichiers racine d'une instance de bottlerocket est immuable. Cette caractéristique de sécurité cruciale garantit que seules les versions stables et testées font partie de l'image, renforçant ainsi l'intégrité. Les mises à jour sont effectuées en remplaçant l'image complète de la fusée, en simplifiant la gestion et en renforçant la sécurité de vos environnements EKS.

Qu'est-ce que Bottlerocket dans EKS ?

Bottlerocket est un système d'exploitation Linux spécialement conçu et optimisé pour les charges de travail conteneurisées sur Amazon EKS. Il offre une base minimale, sécurisée et efficace pour vos nœuds EKS, réduisant ainsi les frais opérationnels et améliorant la posture de sécurité. Ce système d'exploitation spécialisé rationalise l'orchestration des conteneurs, rendant ainsi votre environnement bottlerocket eks plus fiable.

Qu'est-ce que Bottlerocket OS ?

Bottlerocket OS est un système d'exploitation basé sur Linux spécialement conçu comme un hôte de conteneur optimal. Il est conçu pour une efficacité, une sécurité et une conformité maximales. Ce système d'exploitation spécialisé propose une approche minimaliste, rationalisant l'orchestration des conteneurs et simplifiant la gestion des applications conteneurisées, en particulier dans des environnements tels qu'EKS, en réduisant les frais inutiles.