hierarchical namespaces
v1.1.0
$ kubectl hns create my-service -n my-team
$ kubectl hns tree my-team
my-team
└── my-serviceLes espaces de noms hiérarchiques facilitent le partage de votre cluster en les rendant plus puissants. Par exemple, vous pouvez créer des espaces de noms supplémentaires sous l'espace de noms de votre équipe, même si vous ne disposez pas de l'autorisation au niveau du cluster pour créer des espaces de noms, et appliquer facilement des stratégies telles que RBAC, les stratégies réseau et (bêta dans la version 1.1) des quotas de ressources hiérarchiques dans l'ensemble. tous les espaces de noms de votre équipe (par exemple, un ensemble de microservices associés).
Apprenez-en plus dans le guide de l'utilisateur HNC ou commencez avec les instructions ci-dessous !
Développeur principal : @adrianludwin ([email protected])
Pour installer HNC sur votre cluster et le plugin kubectl-hns sur votre poste de travail, suivez les instructions sur nos pages de version.
Une fois HNC installé, vous pouvez essayer le démarrage rapide de HNC pour avoir une idée de ce que HNC peut faire. Ou n’hésitez pas à vous plonger directement dans le guide de l’utilisateur.
Veuillez signaler les problèmes - plus on est de fous ! Les bugs seront étudiés dès que possible, tandis que les demandes de fonctionnalités seront priorisées et affectées à un jalon ou à un backlog.
Tous les problèmes HNC sont attribués à un jalon HNC. Jusqu’à présent, les étapes suivantes sont définies ou planifiées :
Les versions de HNC antérieures à HNC v0.9 sont disponibles dans notre ancien référentiel.
HNC est supervisé par le groupe de travail sur la multi-location (wg-multitenancy). Veuillez nous rejoindre sur Slack, sur les listes de diffusion et lors de notre réunion sur notre page communautaire.
Si vous utilisez HNC, nous vous recommandons de rejoindre la liste de diffusion kubernetes-hnc-announce, une liste à faible volume pour recevoir des mises à jour telles que la nouvelle version de HNC et les modifications proposées ou les nouvelles fonctionnalités.
Ce projet est régi par wg-multitenancy et se trouvait à l'origine dans ce dépôt. Il a déménagé à cet endroit après approbation par sig-auth dans KEP #1687.
La meilleure façon de contribuer à l'introduction d'espaces de noms hiérarchiques dans l'écosystème Kubernetes est d'essayer HNC et de signaler les problèmes que vous rencontrez avec HNC lui-même ou avec sa documentation. Ou, si cela fonctionne bien pour vous, faites-le nous savoir sur le canal #wg-multitenancy sur Slack, ou rejoignez une réunion wg-multitenancy. Nous aimerions avoir de vos nouvelles !
Mais si vous recherchez un niveau d'implication plus profond, veuillez consulter notre guide des contributeurs !
HNC utilise Prow pour exécuter des tests, qui sont configurés ici. Les pré-soumissions exécutent hack/ci-test.sh dans ce dépôt, et les post-soumissions et les périodiques exécutent hack/prow-run-e2e.sh . Les résultats sont affichés sur testgrid et sont configurés ici. Pour plus d'informations sur les tâches Prow (par exemple une référence pour les configurations), voir ici.
Ces fichiers de configuration doivent être inspectés périodiquement (par exemple environ une fois par version) pour s'assurer qu'ils sont entièrement à jour.
HNC utilise Google Cloud Build pour créer certains artefacts. Nous avons l'intention d'automatiser entièrement notre processus de publication en utilisant cette méthode au fil du temps. Voir docs/automated-builds.md pour plus d'informations.
Pour libérer HNC, suivez ce guide.
