À KubeCon + CloudNativeCon Amérique du Nord à Atlanta, Jesse Butler d'Amazon EKS a comparé Kubernetes à l'évolution de Linux. Il a mis en avant les dons d'AWS de projets open source Kro et Karpenter à la communauté Kubernetes. Ces contributions reflètent un virage vers la construction de fonctionnalités à l'échelle de l'écosystème plutôt que de produits autonomes.
Jesse Butler, responsable principal de projets pour Amazon EKS, a pris la parole à KubeCon + CloudNativeCon Amérique du Nord à Atlanta sur la maturation de Kubernetes en un standard universel similaire à Linux. « Tout le monde a une distribution Linux commerciale. C'est ce sur quoi nous fonctionnons tous », a déclaré Butler. « Je pense que Kubernetes y est maintenant aussi. Nous sommes passés de la construction de nos propres serveurs API de clusters sur mesure et de nos propres plans de contrôle à la recherche de standards pour construire à grande échelle pour nos entreprises. »
Cette universalité influence la manière dont des entreprises comme AWS contribuent à l'open source. Dans une discussion avec le fondateur et éditeur de TNS, Alex Williams, Butler a expliqué les dons d'AWS de deux projets via les SIG de Kubernetes : Kubernetes Resource Orchestrator (Kro) et Karpenter.
Kro traite la prolifération des contrôleurs issue des définitions de ressources personnalisées (CRD). Les clients géraient auparavant 20 ou 30 ressources personnalisées avec de petites équipes gérant du code non lié à la logique métier. « Certains de nos clients, il y a même quatre ou cinq ans, avaient 20 ou 30 ressources personnalisées », a noté Butler. « Ainsi, vous avez une petite équipe au sein d'une organisation beaucoup plus grande qui doit posséder juste ce code, et ce n'est même pas vraiment de la logique métier. » Kro génère automatiquement les CRD et les microcontrôleurs en utilisant le Simple Schema de YAML, inférant les dépendances, créant un graphe acyclique dirigé et gérant l'orchestration au sein de Kubernetes.
Karpenter s'attaque au provisionnement des nœuds pour les charges de travail cloud native à pics. « Les charges de travail cloud native sont généralement à pics, elles sont dynamiques », a dit Butler. Il fournit un provisionnement juste-à-temps qui s'adapte à la demande et optimise les coûts. L'API permet la simplicité, comme demander « donnez-moi juste un nœud », ou une configuration détaillée. Ce design a conduit à sa donation au SIG Autoscaling de Kubernetes.
Les deux projets incarnent la philosophie d'AWS : « Dans le contexte de Kubernetes et du logiciel cloud native, c'est une communauté et nous sommes tous le client », a déclaré Butler. « Nous ne pouvons pas construire quelque chose juste pour notre produit et dire que c'est Kubernetes. » Cette approche soutient l'écosystème plus large plutôt que les solutions propriétaires.