La version Kurator v0.4.0 met à jour 4 contenus majeurs pour répondre aux besoins complexes de l'environnement multi-cloud

Résumé : Dans la dernière version v0.4.0, Kurator enrichit encore les capacités de gestion unifiée des applications dans des scénarios natifs cloud distribués, afin de mieux répondre aux besoins complexes des environnements multi-cloud.

Cet article est partagé par la communauté Huawei Cloud « Kurator v0.4.0 : Leading a New Chapter of Distributed Cloud Native Management », auteur : Huawei Cloud Cloud Native Team.

Kurator est une plate-forme cloud native open source distribuée qui intègre de nombreuses piles logicielles cloud natives grand public, telles que Kubernetes, Istio, Prometheus, etc., et vise à aider les utilisateurs à créer et à gérer leur propre infrastructure cloud native distribuée pour promouvoir le développement de l'entreprise. . Kurator incarne l'idée d'"infrastructure en tant que code " , permettant aux utilisateurs de gérer de manière déclarative l'infrastructure dans des environnements cloud, en périphérie ou sur site. Dans le même temps, sa fonctionnalité "prête à l'emploi" permet aux utilisateurs d'installer des piles de logiciels natifs du cloud en un seul clic. Avec Fleet, Kurator fournit également une gestion unifiée du multi-cloud et du multi-cluster, ce qui améliore considérablement l'efficacité de la gestion.

Dans la dernière  version v0.4.0 , Kurator enrichit encore les capacités de gestion unifiée des applications dans des scénarios cloud natifs distribués pour mieux répondre aux besoins complexes des environnements multi-cloud. Cette mise à jour comprend principalement les quatre aspects suivants :

 Adoptez l'approche GitOps et utilisez Fleet pour réaliser une distribution . Cette nouvelle approche réduira la complexité de la configuration d'environnements hétérogènes multi-cloud et simplifiera le processus de gestion des déploiements distribués.

⦁  Fournir aux utilisateurs une solution unifiée de surveillance des indicateurs de cluster basée sur Fleet, Prometheus et Thanos. Cette solution vise à améliorer l'exhaustivité, la précision et les performances en temps réel de la surveillance des indicateurs dans des environnements complexes multi-cloud et multi-cluster, améliorant ainsi l'efficacité de l'exploitation et de la maintenance et réduisant la complexité de l'exploitation et de la maintenance.

⦁  En utilisant Kyverno et Fleet, il fournit une solution unifiée pour la gestion des politiques dans les environnements multi-cloud et multi-cluster. L'ajout de cette fonction améliorera l'efficacité de la gestion des politiques et garantira la cohérence et la sécurité des politiques dans tous les clusters.

⦁  Ajout d'un nouveau type de cluster appelé "Cluster attaché". Ce type de cluster permet à Kurator de gérer des clusters Kubernetes construits par n'importe quel outil à n'importe quel endroit, ce qui renforce encore la gestion par Kurator des environnements de cloud distribués.

  Distribution unifiée des applications   

Avec la popularité du multi-cloud et du multi-cluster, comment déployer et distribuer efficacement des applications dans un environnement cloud natif distribué est devenu un sujet de plus en plus important. A cette fin, Kurator a lancé une fonction de distribution d'application unifiée, le but est de résoudre les problèmes suivants :

  • Les configurations multi-cloud et multi-cluster sont lourdes : Dans un environnement multi-cloud traditionnel, déployer la même application nécessite des configurations complexes dans chaque environnement, ce qui augmente sans aucun doute la difficulté de déploiement et consomme du temps et des ressources humaines inutiles.

  • Le défi du maintien de la cohérence des versions : dans un environnement multi-cloud distribué, étant donné que chaque cluster peut s'exécuter dans des environnements différents et avoir des configurations différentes, il est difficile de maintenir la cohérence de la version de l'application dans tous les clusters et de la mettre à jour dans le temps.

  • La gestion du déploiement distribué est difficile : Une fois l'application déployée dans chaque cluster, il est nécessaire de saisir chaque cluster séparément pour vérifier si le déploiement est réussi et visualiser l'état du déploiement.

La fonction de distribution unifiée des applications de Kurator adopte la méthode GitOps, permettant de déployer des applications dans plusieurs environnements cloud en un seul clic, tout en simplifiant le processus de configuration. Cette méthode garantit que les versions d'application de chaque cluster sont cohérentes et peuvent être mises à jour en temps voulu. Sur le cluster hôte Kurator, les utilisateurs peuvent visualiser et gérer le déploiement d'applications de tous les clusters de manière unifiée, améliorant ainsi l'efficacité de l'exploitation et de la maintenance.

Schéma de l'architecture de gestion des applications Kurator

Basé sur FluxCD, Kurator optimise l'efficacité et la précision du déploiement grâce à des processus automatisés de synchronisation et de déploiement des applications. Avec les avantages de Fleet, il peut également s'adapter de manière flexible aux diverses exigences des entreprises et des clusters, et répondre aux divers besoins des utilisateurs en matière de distribution d'applications.

La fonction de distribution d'applications unifiée de Kurator offre des options de configuration riches et flexibles. Les utilisateurs peuvent définir des paramètres clés tels que les sources d'application et les politiques de synchronisation via des fichiers de configuration YAML. Dans le même temps, Kurator prend également en charge la combinaison de plusieurs types de sources (y compris gitRepository, helmRelease, etc.) et de stratégies de synchronisation.

Voici un exemple de distribution d'application unifiée :

apiVersion: apps.kurator.dev/v1alpha1
kind: Application
metadata:
  name: gitrepo-kustomization-demo
  namespace: default
spec:
  source:
    gitRepository:
      interval: 3m0s
      ref:
        branch: master
      timeout: 1m0s
      url: https://github.com/stefanprodan/podinfo
  syncPolicies:
    - destination:
        fleet: quickstart
      kustomization:
        interval: 5m0s
        path: ./deploy/webapp
        prune: true
        timeout: 2m0s
    - destination:
        fleet: quickstart
      kustomization:
        targetNamespace: default
        interval: 5m0s
        path: ./kustomize
        prune: true
        timeout: 2m0s

Cet exemple de configuration explique comment utiliser Kurator pour réaliser une distribution d'applications unifiée multi-cluster : obtenez la configuration de l'application à partir de la source Git, puis synchronisez-la et déployez-la via Fleet. Les utilisateurs peuvent rapidement déployer des applications sur plusieurs clusters avec une configuration simple.

Pour plus d'exemples et d'autres informations connexes, veuillez consulter : https://kurator.dev/docs/fleet-manager/application/

  Surveillance unifiée des indicateurs de cluster   

Dans les environnements multi-cloud et multi-cluster complexes, la surveillance unifiée des indicateurs de cluster peut améliorer l'efficacité du travail et réduire la complexité de l'exploitation et de la maintenance. Pour de nombreuses entreprises, le défi auquel elles sont confrontées est de savoir comment surveiller et gérer efficacement les clusters pour assurer la stabilité des services et optimiser l'utilisation des ressources.

Un seul outil de surveillance ne peut souvent pas répondre aux exigences de surveillance complètes, opportunes et précises. Cela oblige le personnel d'exploitation et de maintenance à entrer dans chaque groupe pour vérifier séparément, ce qui non seulement augmente la charge de travail, mais peut également entraîner l'omission ou le retard d'informations sur les indicateurs clés. Et, parce que différents clusters peuvent avoir des besoins différents, la gestion devient plus compliquée.

Pour résoudre les problèmes ci-dessus, Kurator fournit une solution de surveillance d'indicateurs multi-clusters basée sur Prometheus, Thanos, Grafana et Fleet, permettant aux utilisateurs de réaliser facilement une surveillance unifiée des indicateurs de plusieurs clusters.

Schéma d'architecture de surveillance unifiée

Habituellement, une fois la configuration des autorisations de cluster et du stockage distant terminée, nous pouvons résumer le processus de réalisation de la surveillance unifiée des indicateurs dans un environnement multi-cluster comme suit :

  1. Chaque cluster exécute une instance Prometheus, responsable de la collecte des données de surveillance locales ;

  2. Chaque instance Prometheus est livrée avec un Thanos Sidecar, qui pousse les données collectées par Prometheus vers un stockage distant ;

  3. Thanos Query agrège les données de tous les Sidecars Thanos et du stockage distant et fournit une interface de requête unifiée ;

  4. Grafana se connecte à Thanos Query, permettant une vue de surveillance unifiée de tous les clusters.

Grâce à la puissance de Kurator's Fleet, les utilisateurs n'ont pas besoin de gérer eux-mêmes le processus compliqué mentionné ci-dessus. Les utilisateurs n'ont qu'à définir les configurations pertinentes dans Fleet, et Fleet Manager peut effectuer automatiquement le processus ci-dessus.

Voici un exemple de configuration de flotte qui accomplirait le processus ci-dessus :

apiVersion: fleet.kurator.dev/v1alpha1
kind: Fleet
metadata:
  name: quickstart
  namespace: default
spec:
  clusters:
    - name: kurator-member1
      kind: AttachedCluster
    - name: kurator-member2
      kind: AttachedCluster
  plugin:
    metric:
      thanos:
        objectStoreConfig:
          secretName: thanos-objstore
grafana: {}

Après avoir exécuté la configuration ci-dessus, Fleet Manager installera Prometheus et Thanos Sidecar sur les deux clusters de kurator-member1 et kurator-member2 respectivement. Les utilisateurs peuvent ensuite afficher une vue de surveillance unifiée de tous les clusters via le tableau de bord Grafana sur l'hôte Kurator.

Pour plus de détails sur l'utilisation de la surveillance unifiée des métriques de cluster, veuillez vous référer à : https://kurator.dev/docs/fleet-manager/metric-plugin/

  Gestion unifiée des politiques  

Dans un environnement cloud distribué, afin de répondre aux exigences de protection de sécurité unifiées du multi-cloud et du multi-cluster, Kurator introduit une fonction de gestion des politiques unifiées pour résoudre les problèmes suivants :

  • Impossible de coordonner la gestion des politiques de plusieurs clusters et d'appliquer la même politique sur tous les clusters

  • La gestion distribuée de plusieurs politiques de sous-cluster, la redondance et la complexité élevée, ne peuvent pas être configurées et gérées de manière uniforme et efficace

  • Impossible de limiter uniformément l'utilisation des ressources de plusieurs clusters pour s'assurer que tous les clusters suivent les mêmes règles de fonctionnement et exigences commerciales

Les capacités de gestion des politiques de Kurator sont basées sur Kyverno et utilisent Fleet pour mettre en œuvre la distribution inter-cluster et l'application des politiques d'application . Ce mécanisme permet de gérer les politiques de manière uniforme et efficace sur l'ensemble du groupe de clusters, en évitant la complexité de la gestion des politiques individuellement dans chaque sous-cluster.

Diagramme d'architecture de gestion unifiée des politiques

La capacité de gestion des politiques fournie par Kurator est presque la même que la gestion des politiques dans un seul cluster Kubernetes, et les utilisateurs peuvent rapidement se familiariser avec elle et commencer. Voici un exemple d'utilisation de Kurator pour mettre en œuvre une gestion unifiée des politiques dans Fleet :

apiVersion: fleet.kurator.dev/v1alpha1
kind: Fleet
metadata:
  name: quickstart
  namespace: default
spec:
  clusters:
    - name: kurator-member1
      kind: AttachedCluster
    - name: kurator-member2
      kind: Cluster
    - name: kurator-member3
      kind: CustomCluster
  plugin:
    policy:
      kyverno:
        podSecurity:
          standard: baseline
          severity: high
          validationFailureAction: Audit

Dans le fichier de configuration ci-dessus, nous appliquons uniformément la politique de sécurité du pod avec podSecurityStandard comme ligne de base et podSecuritySeverity comme niveau élevé pour les clusters dans Fleet. Lorsque la configuration du pod viole la politique de sécurité, l'événement correspondant sera enregistré dans le PolicyReport lors de son processus de création ; et lorsque validationFailureAction est défini sur Enforce, la création ou la mise à jour de ressources illégales sera bloquée. Tous les clusters de Fleet appliqueront cette politique, et les opérateurs et développeurs d'applications régleront et configureront les applications tout en respectant les règles de sécurité du Pod. Grâce à la capacité de gestion unifiée des politiques de Kurator, l'efficacité de la gestion des politiques peut être efficacement améliorée tout en garantissant la cohérence et la sécurité des politiques dans tous les clusters.

Pour plus d'informations sur la gestion unifiée des politiques de Kurator, veuillez consulter : https://kurator.dev/docs/fleet-manager/policy/

   AttachedClusterAttachedCluster  

Dans un monde cloud natif, la complexité et la diversité des infrastructures sont des problèmes inévitables. Pour les grandes organisations ou entreprises, elles peuvent avoir déployé plusieurs clusters Kubernetes dans différents environnements, et ces clusters peuvent être créés par divers outils et distribués dans le monde entier. Afin de mieux résoudre ce problème, Kurator a introduit un nouveau type de cluster, AttachedCluster, dans la dernière version .

L'objectif principal d'AttachedCluster est de gérer les clusters Kubernetes qui ne sont pas créés par Kurator mais qui doivent être inclus dans la gestion de flotte Kurator. Ces clusters peuvent être créés par n'importe quel outil et situés n'importe où. L'introduction de ce nouveau type de cluster étend les capacités de gestion de Kurator et permet une gestion efficace d'un environnement cloud véritablement distribué. En utilisation réelle, les utilisateurs doivent créer une ressource AttachedCluster pour le cluster Kubernetes qui devrait être connecté à la gestion Kurator. Ces ressources contiennent les informations de connexion et d'authentification du cluster, qui sont stockées et gérées en toute sécurité via Secret. Grâce à ces informations, Kurator est en mesure d'interagir et de gérer efficacement ces clusters. ]

Voici un exemple: 

apiVersion: cluster.kurator.dev/v1alpha1
kind: AttachedCluster
metadata:
  name: kurator-member1
  namespace: default
spec:
  kubeconfig:
    name: kurator-member1
    key: kurator-member1.config

Une fois les ressources créées, l'utilisateur doit également ajouter ces ressources AttachedCluster à Kurator Fleet, afin que ces clusters puissent être inclus dans la portée de gestion de Kurator. De cette manière, quel que soit l'endroit où ces clusters sont créés, ils peuvent être gérés et surveillés de manière uniforme dans Kurator.

Voici un exemple d'ajout du ci-dessus AttachedCluster à Fleet :

apiVersion: fleet.kurator.dev/v1alpha1
kind: Fleet 
metadata:
  name: quickstart
  namespace: default
spec:
  clusters:
    # 在此处添加 AttachedCluster 或者其他类型的集群
    - name: kurator-member1 
      kind: AttachedCluster

Pour les utilisateurs, Kurator réalise une gestion pratique de tous les clusters Kubernetes sur une plate-forme unifiée en introduisant AttachedCluster, évite les basculements fréquents entre divers outils et surveille et gère efficacement chaque cluster dans un environnement de cloud distribué. Cette amélioration renforce non seulement les capacités de gestion de Kurator dans le domaine du cloud natif, mais élargit également sa portée de gestion, ce qui améliore considérablement l'adaptabilité et l'efficacité de gestion de Kurator dans la gestion d'environnements de cloud computing complexes et diversifiés.

lien de référence

Notes de version:https://github.com/kurator-dev/kurator/releases/tag/v0.4.0

Documentation sur la distribution unifiée des applications : https://kurator.dev/docs/fleet-manager/application/

Document de suivi des indicateurs de cluster unifié : https://kurator.dev/docs/fleet-manager/metric-plugin/

Documentation sur la gestion unifiée des politiques : https://kurator.dev/docs/fleet-manager/policy/

Documentation AttachedCluster : https://kurator.dev/docs/fleet-manager/manage-attachedcluster/

Documentation du gestionnaire de flotte : https://kurator.dev/docs/fleet-manager/

Adresse GitHub : https://github.com/kurator-dev/kurator

Page d'accueil de Kurator : https://kurator.dev/

Adresse Slack : https://join.slack.com/t/kurator-hq/shared_invite/zt-1sowqzfnl-Vu1AhxgAjSr1XnaFoogq0A

 

Cliquez pour suivre et en savoir plus sur les nouvelles technologies de Huawei Cloud pour la première fois ~

Les diplômés de l'Université populaire nationale ont volé les informations de tous les étudiants de l'école pour créer un site Web d'évaluation de la beauté et ont été détenus au criminel. La nouvelle version Windows de QQ basée sur l'architecture NT est officiellement publiée. Les États-Unis limiteront l'utilisation de la Chine d'Amazon, Microsoft et d'autres services cloud qui fournissent des modèles d'IA de formation.Des projets open source annoncés pour arrêter le développement de fonctions fonctions d'image du terminal Le nombre d'enregistrements de Threads a dépassé les 30 millions "Change" deepin adopte Asahi Linux pour s'adapter au classement de la base de données Apple M1 en juillet : Oracle surgit, ouvrant à nouveau le score
{{o.name}}
{{m.name}}

おすすめ

転載: my.oschina.net/u/4526289/blog/10086976