Configurer des objets Kubernetes

Cet article explique comment créer des configurations, les fichiers que Config Sync lit à partir de Git et applique automatiquement à vos clusters.

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épertoire namespaces/ peuvent hériter des configurations de leurs répertoires d'espace de noms abstraits.

  • Nous avons créé un exemple de dépôt canonique pour illustrer le fonctionnement de Config Sync. Il contient divers exemples, y compris : format non structuré et format hiérarchique, mode multidépôt et mode non multidépôt, dépôt racine et dépôts d'espaces de noms.

    Les exemples de cet article proviennent de ce dépôt. Il peut donc être utile d'ouvrir ce dernier dans un navigateur ou de le cloner sur votre système local.

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.

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

Les exemples de configurations ci-dessous proviennent tous de l'exemple de dépôt et doivent vous aider à écrire vos propres configurations. Cette liste n'est pas exhaustive. 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 des dépôts d'espaces de noms.

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