Quand l’architecture de la plateforme nécessite une attention particulière
- Clusters lancés sans standards de plateforme
- Propriété peu claire entre les équipes d'application et de plate-forme
- Failles de sécurité dans le RBAC, la politique réseau et la chaîne d'approvisionnement
- Mises à niveau douloureuses et dérive de configuration
- Observabilité qui ne peut pas prendre en charge la réponse aux incidents
Comment nous travaillons sur cette plateforme
- Architecture cible AKS, EKS et GKE
- Ingénierie de plateforme et conception de plateforme de développement interne
- GitOps et CI/CD pour la livraison de clusters et d'applications
- Politique de réseau, entrée et décision de maillage de services
- Observabilité avec les piles compatibles Prometheus/Grafana
- Migration de VM ou PaaS vers des conteneurs
L'architecture dans son contexte
Architecture conceptuelle illustrant les limites décisionnelles. Elle ne représente pas un environnement client.
Choisissez le service géré du domaine
AKS, EKS et GKE partagent les API Kubernetes mais diffèrent par l'intégration des identités, les paramètres réseau par défaut, les modules complémentaires et l'expérience de mise à niveau. Choisissez en fonction du parc infonuagique principal, du modèle d'identité, des compétences de l'équipe et des services adjacents, et non d'une liste de contrôle de fonctionnalités isolée.
La qualité de l’ingénierie de la plateforme compte généralement plus que les différences mineures entre les services gérés. La page des opérations de la plate-forme est la façon dont nous restons actifs après la conception du cluster.
Ce que nous ne supposons pas
Kubernetes n'est pas requis pour chaque programme de modernisation. Certaines charges de travail sont meilleures sur des machines virtuelles PaaS, sans serveur ou bien gérées. L'architecture doit suivre la charge de travail.
Le service d'assistance quotidien et l'informatique sur le lieu de travail ne sont pas des opérations de plateforme Kubernetes. Ceux-ci sont assis avec Podium Catchers.
Les décisions technologiques en contexte
- Kubernetes
- AKS
- EKS
- GKE
- Barre
- GitOps
- Terraform
- Modèles de maillage Istio/service
Ce que le travail est censé permettre
- Un modèle opérationnel de cluster et de plateforme supportable
- Des limites plus claires pour le libre-service des développeurs
- Dérive de configuration réduite via GitOps
- Sécurité améliorée et préparation à la mise à niveau
Un choix de plateforme est un choix opérationnel
Nous convenons des critères d’acceptation de la charge de travail, de la propriété des accès, des pratiques de changement et des responsabilités de récupération avant la mise en œuvre. Les services des fournisseurs ne suppriment pas le besoin de tests d'applications, de responsabilité en matière de coûts et d'une équipe d'exploitation.
Questions et réponses
Quelle est la différence entre AKS, EKS et GKE ?
AKS, EKS et GKE sont des services Kubernetes gérés sur Azure, AWS et Google Cloud. Ils partagent les concepts Kubernetes mais diffèrent par l'intégration des identités, les paramètres réseau par défaut, les modules complémentaires, les outils de mise à niveau et les services infonuagique environnants.
#Avons-nous besoin de Kubernetes pour chaque programme de modernisation ?
Non. Kubernetes est utile lorsque vous avez besoin d'une orchestration de conteneurs portables et d'un effet de levier sur la plate-forme. Certaines charges de travail sont meilleures sur des machines virtuelles PaaS, sans serveur ou bien gérées. L'architecture doit suivre les caractéristiques de la charge de travail et non la mode.
#Qui gère le cluster après la mise en ligne ?
Nous pouvons exploiter la plateforme que nous concevons. Il s’agit d’opérations de zone d’atterrissage et de cluster, et non d’informatique gérée.
#Où doivent résider les décisions de maillage de services ?
Sur cette page en tant que choix d'architecture et dans l'article publié sur la passerelle API et le maillage de services. Le maillage ne remplace pas une zone d'atterrissage.
#