Pratique de gestion hiérarchique basée sur kubesphere

Auteur：Xu Wei,Ingénieur de la recherche et du développement de Space Netcom

K8s Est un leader dans l'orchestration de conteneurs et le déploiement d'applications distribuées,In K8s Dans l'environnement,Nous avons juste besoin de nous soucier de la logique d'entreprise appliquée,Réduit le fardeau administratif de notre réseau de serveurs et de stockage.Pour un utilisateur,K8s Est une plate - forme complexe d'orchestration de conteneurs,Les coûts d'apprentissage sont très élevés.KubeSphere Abstrait K8s,Et très productivisé,Une plate - forme Cloud Multi - locataires entièrement empilée a été construite,Il offre aux utilisateurs un、Sécurité、Riche en fonctionnalités、Avec l'expérience ultime Web Console,C'est réglé. K8s Utilisez des points de douleur tels que des seuils élevés et des outils écologiques primitifs en nuage,Nous permet de nous concentrer sur les itérations rapides de l'entreprise,Sa surveillance multidimensionnelle des données,Pour localiser le problème,Ça m'a beaucoup aidé.

Pourquoi? KuberSphere Mise en œuvre de la gestion hiérarchique

In KubeSphere Moyenne,Les ressources peuvent être partagées entre locataires,Selon les différents rôles assignés,Il est possible d'utiliser une variété de ressources.Entre le locataire et la ressource、Le degré de liberté entre la ressource et la ressource est élevé,La granularité des permissions est également assez grande.Dans notre système,La ressource a un niveau de permission,Comme les utilisateurs de bas niveau peuvent être invités par、Accorder des permissions, etc., pour exploiter des ressources de haut niveau,Ou comme dans un projet de bas niveau Pod Peut être programmé sur des noeuds de haut niveau,Ressources.Ce genre de questions sur les ressources opérationnelles à plusieurs niveaux,On est là. KubeSphere La gestion hiérarchique est réalisée sur la base de.

Qu'est - ce qu'un système de classement

Classement, .Comme son nom l'indique, il s'agit de décomposer l'ensemble selon des critères établis 、Classification. Nous l'avons résumé en un modèle pyramidal , Il y aura plusieurs niveaux de la Fondation au Sommet de la tour , Nous utilisons les ressources publiques comme base de la pyramide , Avec la plus haute autorité admin Comme le Sommet de la tour , Les autres ressources sont classées selon le niveau d'autorité . Les ressources de niveau inférieur ne sont pas accessibles aux ressources de niveau supérieur , Les ressources de haut niveau ont accès à toutes les ressources sous leur niveau , Construit un tel déclin des capitaux propres 、 Système hiérarchique d'isolement hiérarchique .

Comment réaliser la gestion hiérarchique

Nous avons défini une étiquette qui représente la hiérarchie kubernetes.io/level. Prenons l'exemple d'un Cluster Multi - noeuds , D'abord, nous donnerons aux utilisateurs 、Espace d'entreprise、 Les ressources telles que les noeuds sont étiquetées pour représenter le niveau . Lorsque vous invitez un utilisateur à rejoindre un espace d'entreprise ou un projet , L'espace d'entreprise ou le projet requis ne doit pas être supérieur au niveau de l'utilisateur , De même, lorsque vous liez un espace d'entreprise , Il est également exigé que le niveau du projet ne soit pas supérieur à celui de l'espace d'entreprise , Pour prendre en charge les ressources ; Nous considérons que le niveau des ressources au titre du même programme est le même , Charge utile créée sur la base du projet 、Pod、 Le niveau des ressources, comme les services, est conforme au projet ;En même temps Pod Ajouter l'affinité nodale ,Pour faire Pod Envoyé à un noeud dont le niveau de permission n'est pas supérieur à .

Par exemple, ici, Nous avons créé un niveau de permission 3 Utilisateurs de demo-user, Il peut rejoindre un niveau d'autorité inférieur ou égal à 3 Dans l'espace d'entreprise ou le projet .

kind: UserapiVersion: iam.kubesphere.io/v1alpha2metadata:  name: demo-user  labels:    kubernetes.io/level: 3spec:  email: [email protected]

Créer un niveau de permission est 2 Projets pour demo-ns, Ensuite, la charge de travail créée par le projet 、Pod、 Le niveau de permission pour les ressources telles que le stockage est également 2.

apiVersion: v1kind: Namespacemetadata:   name: demo-ns   labels:     kubernetes.io/level: 2

Basé sur demo-ns Le projet a créé un nginx De Pod, Son niveau d'autorité est aussi 2, Ajouter l'affinité nodale , Exiger qu'il soit envoyé à un niveau d'autorisation n'excédant pas 2 Sur le noeud de.

apiVersion: apps/v1kind: Podmetadata:  labels:    kubernetes.io/level: 2  name: nginxspec:  containers:  - name: nginx    image: nginx    imagePullPolicy: IfNotPresent    ports:    - containerPort: 80      protocol: TCP  affinity:    nodeAffinity:      requiredDuringSchedulingIgnoredDuringExecution:       nodeSelectorTerms:        - matchExpressions:          - key: kubernetes.io/level            operator: Lt            values:            - 2        - matchExpressions:          - key: kubernetes.io/level            operator: In            values:            - 2

Comment réaliser la mise à niveau des ressources

Dans un système de gestion hiérarchique , Supporte une division infinie des niveaux , Il suffit de définir une valeur intermédiaire , Vous pouvez insérer un nouveau niveau entre les deux niveaux , Aucune autre ressource n'est nécessaire ; Lors de la mise à niveau des ressources , Seule la ressource correspondante doit être modifiée label Étiquettes, Les ressources peuvent être mises à niveau .Bien sûr., Lors de la mise à niveau et de la déclassement des ressources , Nous devons tester les ressources , Lors de la mise à niveau garantie , Le niveau d'autorité de ses ressources supérieures ne doit pas être inférieur au niveau cible ;En même temps,Lors de la rétrogradation, Le niveau d'autorisation de ses ressources inférieures ne doit pas être supérieur au niveau cible . Lorsque les conditions de fonctionnement de la rétrogradation ne sont pas remplies , Les ressources correspondantes doivent être ajustées en conséquence avant que .

Entre les différents niveaux Pod Isolement du Réseau pour

Dans le système de classement , Nous exigeons des Pod Accès aux niveaux inférieurs Pod, Mais le niveau inférieur Pod Impossible d'accéder au niveau supérieur Pod, Alors comment pouvons - nous nous assurer que les différents niveaux Pod Et la communication réseau .

Projet sans isolement du réseau ,Pod Le réseau est interconnecté , Donc voici une nouvelle liste noire de la politique du réseau .

apiVersion: networking.k8s.io/v1kind: NetworkPolicymetadata:  name: deny-all  namespace: demo-ns  labels:    kubernetes.io/level: 2spec:  podSelector: {}  policyTypes:  - Ingress

podSelector:{} Agir sur tous les Pod, Bloquer l'entrée de tous les flux .

Puis le niveau de l'étiquette de libération est supérieur au niveau cible （Ici. 2） Flux vers （Nous sommes d'accord avec Ingress Le débit n'est pas limité ）.

apiVersion: networking.k8s.io/v1kind: NetworkPolicymetadata:  name: level-match-network-policy  namespace: demo-ns  labels:    kubernetes.io/level: 2spec:  podSelector:    matchExpressions:    - key: kubernetes.io/level      operator: Gt      values:      - 2  policyTypes:  - Ingress

Résumé

KubeSphere Construction de l'utilisateur résolue 、Déploiement、 Points de douleur dans la gestion et l'observabilité , Ses ressources peuvent être partagées entre plusieurs locataires . Mais dans les scénarios où la ressource a un niveau de permission , Les ressources de niveau inférieur peuvent utiliser des ressources de niveau supérieur , Problèmes de gestion des ressources .Pour résoudre ce problème,On est là. KubeSphere Sur la base de, Pour tenir compte de la gestion hiérarchique entre les locataires et les ressources et entre les ressources et les ressources , En même temps, dans la stratégie de réseau du projet , Ajouter des listes noires et blanches , Amélioration de l'isolement du réseau entre les projets , Rendre la gestion des ressources plus sûre .

Cet article est basé sur la plateforme Multi - blog OpenWrite Publication！