Créer des configurations
Cette page vous explique comment créer des configurations, qui sont les fichiers que Config Sync lit à partir de Git et applique automatiquement à vos clusters.
Pour en savoir plus sur les configurations et leur utilisation dans votre dépôt, consultez la section Ajouter des configurations aux dépôts Git.
Avant de commencer
Vous devez connaître les principes de base de la syntaxe YAML ou JSON, car les configurations doivent être écrites dans l'un de ces deux formats. Tous les exemples de cette documentation utilisent YAML, car ce langage est plus facile à lire pour les utilisateurs.
Chaque type d'objet Kubernetes est associé à des options configurables spécifiques. Il est utile de comprendre comment obtenir manuellement la configuration souhaitée avant d'écrire une configuration pour ce type d'objet.
Si vous choisissez d'utiliser un dépôt hiérarchique, assurez-vous de bien comprendre la structure du dépôt hiérarchique. L'emplacement d'une configuration dans le dépôt a une incidence sur les clusters et les espaces de noms auxquels elles est appliquée. Ceci est particulièrement important pour le répertoire
namespaces/
, car les sous-répertoires du répertoirenamespaces/
peuvent hériter des configurations de leurs répertoires d'espace de noms abstraits.
Créer une ressource Configuration
Lorsque vous créez une configuration, vous devez déterminer le meilleur emplacement dans le dépôt et les champs à inclure.
Emplacement dans le dépôt
Pour les dépôts non structurés, vous pouvez organiser les configurations de manière arbitraire et créer des sous-dossiers de ressources.
Pour les dépôts hiérarchiques, l'emplacement d'une configuration dans le dépôt est l'un des facteurs qui déterminent les clusters auxquels il s'applique :
- Les configurations des objets à l'échelle d'un cluster (à l'exception des espaces de noms) sont stockées dans le répertoire
cluster/
du dépôt. - Les configurations des espaces de noms et des objets définis à leur échelle sont stockées dans le répertoire
namespaces/
du dépôt. - Les configurations pour les composants Config Sync sont stockées dans le répertoire
system/
du dépôt. - La configuration de Config Management Operator n'est pas stockée directement dans le dépôt et n'est pas synchronisée.
- Les configurations des objets à l'échelle d'un cluster (à l'exception des espaces de noms) sont stockées dans le répertoire
Contenu de la configuration
Les configurations utilisent une approche additive, semblable à kubectl
.
Lors de la création d'objets, vous devez inclure tous les champs obligatoires. Toutefois, lors de la mise à jour d'objets existants, il vous suffit de fournir les champs que vous souhaitez mettre à jour.
Lors de son application, la configuration doit générer un objet Kubernetes valide.
Exemples de configurations
Le dépôt d'exemples Anthos Config Management illustre le fonctionnement de Config Sync. Il contient des exemples pour les types de dépôts suivants :
- Format non structuré
- Format hiérarchique
- Synchroniser à partir de plusieurs dépôts
- Dépôt racine
- Dépôts d'espaces de noms
Les exemples de configurations ci-dessous proviennent tous de l'exemple de dépôt. Il peut être utile d'ouvrir cet exemple dans un navigateur ou de le cloner sur votre système local.
Les exemples suivants ne sont pas exhaustives. vous pouvez configurer n'importe quel type d'objet Kubernetes à l'aide de Config Sync.
Configuration de l'objet Namespace
La configuration ci-dessous crée un espace de noms appelé gamestore
.
apiVersion: v1
kind: Namespace
metadata:
name: gamestore
Lorsque vous créez une configuration d'espace de noms, vous pouvez également y ajouter des libellés ou des annotations. Les libellés sont obligatoires lorsque vous utilisez un objet NamespaceSelector.
L'exemple de configuration suivant crée un espace de noms nommé gamestore
s'il n'existe pas déjà ou s'il n'est pas géré.
L'espace de noms comporte le libellé app: gamestore
et l'annotation retail: true
. Si quelqu'un modifie manuellement les métadonnées de l'objet, Config Sync le réinitialise rapidement sur la valeur de la configuration.
apiVersion: v1
kind: Namespace
metadata:
name: gamestore
labels:
app: gamestore
annotations:
retail: "true"
Pour en savoir plus sur l'utilisation des espaces de noms, consultez la page Configurer des espaces de noms et des objets à l'échelle d'un espace de noms.
Configuration de l'objet ClusterRole
Cette configuration crée un objet ClusterRole nommé namespace-reader
, qui permet de lire (c'est-à-dire d'obtenir, de surveiller et de répertorier) tous les objets namespace
du cluster.
Une configuration d'objet ClusterRole est souvent utilisée avec une configuration d'objet ClusterRoleBinding.
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: namespace-reader
rules:
- apiGroups: [""]
resources: ["namespaces"]
verbs: ["get", "watch", "list"]
Configuration de l'objet ClusterRoleBinding
Cette configuration crée un objet ClusterRoleBinding nommé namespace-readers
, qui accorde à l'utilisateur cheryl@example.com
l'objet ClusterRole namespace-reader
.
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: namespace-readers
subjects:
- kind: User
name: cheryl@example.com
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: namespace-reader
apiGroup: rbac.authorization.k8s.io
Les objets ClusterRoleBinding sont définis à l'échelle d'un cluster et ne peuvent pas être placés dans des répertoires d'espaces de noms ou des espaces de noms abstraits.
Configuration de l'objet PodSecurityPolicy
L'exemple ci-dessous crée un objet PodSecurityPolicy nommé psp
, qui interdit l'exécution des conteneurs privilégiés, mais permet aux conteneurs de s'exécuter comme n'importe quel utilisateur valide du nœud.
apiVersion: extensions/v1beta1
kind: PodSecurityPolicy
metadata:
name: psp
spec:
privileged: false
seLinux:
rule: RunAsAny
supplementalGroups:
rule: RunAsAny
runAsUser:
rule: RunAsAny
fsGroup:
rule: RunAsAny
volumes:
- '*'
Les objets PodSecurityPolicy sont définis à l'échelle d'un cluster et ne peuvent pas être placés dans des répertoires d'espaces de noms ou des espaces de noms abstraits.
Configuration de l'objet NetworkPolicy
L'exemple ci-dessous crée un objet NetworkPolicy nommé default-deny-all-traffic
.
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: default-deny-all-traffic
spec:
podSelector: {}
Les objets NetworkPolicy sont définis à l'échelle d'un espace de noms et ne peuvent être placés que dans des répertoires d'espaces de noms ou des espaces de noms abstraits.
Lorsque vous appliquez l'objet NetworkPolicy ci-dessus à un seul espace de noms, il isole les pods de cet espace de noms du trafic entrant et sortant.
Lorsque vous appliquez le même objet NetworkPolicy à plusieurs espaces de noms en le plaçant dans un espace de noms abstrait avec des espaces de noms descendants, chacun de ces espaces de noms hérite de cet objet. Dans l'exemple de dépôt d'héritage des espaces de noms, le répertoire namespaces
contient deux espaces de noms abstraits, eng
et rnd
, et chaque espace de noms abstrait contient deux espaces de noms réels, respectivement analytics
et gamestore
, et incubator-1
et incubator-2
. Si vous ajoutez la règle NetworkPolicy default-deny-all-traffic
ci-dessus aux espaces de noms abstraits, les quatre espaces de noms réels héritent chacun de la règle NetworkPolicy, de sorte que chacun de leurs pods est protégé contre le trafic entrant et sortant.
Vous pouvez utiliser le processus d'héritage des espaces de noms pour appliquer une approche de la sécurité basée sur le principe du moindre privilège. Par exemple, si l'exemple NetworkPolicy précédent est appliqué aux espaces de noms abstraits et si l'objet NetworkPolicy suivant est ajouté à l'espace de noms abstrait eng
, le trafic entrant n'est autorisé que vers les pods des espaces de noms descendants avec le libellé app:gamestore
. Les espaces de noms analytics
, incubator-1
et incubator-2
ne sont pas concernés par cet objet NetworkPolicy.
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: allow-gamestore-ingress
spec:
podSelector:
matchLabels:
app: gamestore
ingress:
- {}
Configuration de l'objet ResourceQuota
L'exemple ci-dessous crée un objet ResourceQuota nommé quota
, qui définit une limite stricte de 1 pod, 100 millièmes de temps CPU et 100 mébioctets (Mio) de mémoire.
kind: ResourceQuota
apiVersion: v1
metadata:
name: quota
spec:
hard:
pods: "1"
cpu: "100m"
memory: "100Mi"
Si la création d'un objet d'un type donné a pour effet d'enfreindre la condition définie par un objet ResourceQuota existant, Kubernetes ne peut pas créer l'objet tant que la limite fixée par ResourceQuota n'est pas respectée.
Configuration de l'objet RepoSync
Cet exemple crée un objet RepoSync dans le dépôt racine, qui est synchronisé à partir d'un dépôt d'espaces de noms. Pour en savoir plus sur la configuration de l'objet RepoSync, consultez la section Configurer la synchronisation à partir de plusieurs dépôts.
apiVersion: configsync.gke.io/v1beta1
kind: RepoSync
metadata:
name: repo-sync
namespace: gamestore
spec:
sourceFormat: unstructured
git:
repo: https://github.com/GoogleCloudPlatform/anthos-config-management-samples
branch: main
dir: quickstart/multirepo/namespaces/gamestore
auth: none
Config Sync crée un rapprochement des espaces de noms à synchroniser à partir du dépôt d'espaces de noms.
Étape suivante
- Découvrez comment configurer des objets à l'échelle d'un cluster.
- Découvrez comment configurer des objets à l'échelle d'un espace de noms.
- Découvrez comment gérer des objets.