Konfigurationen erstellen

Auf dieser Seite erfahren Sie, wie Sie Konfigurationen erstellen. Das sind die Dateien, die Config Sync aus Git liest und automatisch auf Ihre Cluster anwendet.

Weitere Informationen zu Konfigurationen und ihrer Verwendung in Ihrem Repository finden Sie unter Konfigurationen zu Git-Repositories hinzufügen.

Hinweis

  • Sie benötigen grundlegende Kenntnisse der YAML- oder JSON-Syntax, da Konfigurationen in einem dieser beiden Formate geschrieben werden. Für alle Beispiele in diesem Thema wird YAML verwendet, da es für Nutzer einfacher zu lesen ist.

  • Verschiedene Kubernetes-Objekttypen haben unterschiedliche konfigurierbare Optionen. Es ist nützlich, zu wissen, wie Sie die gewünschte Konfiguration manuell erstellen, bevor Sie eine Konfiguration für einen bestimmten Objekttyp schreiben.

  • Wenn Sie ein hierarchisches Repository verwenden möchten, sollten Sie sich mit der Struktur des hierarchischen Repositorys vertraut machen. Der Speicherort einer Konfiguration innerhalb des Repositorys bestimmt, auf welche Cluster und Namespaces sie angewendet wird. Das gilt insbesondere für das Verzeichnis namespaces/, da Unterverzeichnisse des Verzeichnisses namespaces/ Konfigurationen von ihren abstrakten Namespace-Verzeichnissen übernehmen können.

Konfiguration erstellen

Wenn Sie eine Konfiguration erstellen, müssen Sie den besten Speicherort im Repository und die einzuschließenden Felder bestimmen.

Standort im Repository

  • Bei unstrukturierten Repositories können Sie die Konfigurationen beliebig organisieren und Unterordner von Ressourcen erstellen.

  • Bei hierarchischen Repositories ist der Speicherort einer Konfiguration im Repository einer der Faktoren, die bestimmen, auf welche Cluster sie angewendet wird:

    • Konfigurationen für Clusterobjekte mit Ausnahme von Namespaces werden im Verzeichnis cluster/ des Repositorys gespeichert.
    • Konfigurationen für Namespaces und Namespace-Objekte werden im Verzeichnis namespaces/ des Repositorys gespeichert.
    • Configs für Config Sync-Komponenten werden im Verzeichnis system/ des Repositorys gespeichert.
    • Die Konfiguration für den Config Management Operator wird nicht direkt im Repository gespeichert und nicht synchronisiert.

Inhalt der Konfiguration

Konfigurationen basieren ähnlich wie kubectl auf einem additiven Ansatz. Beim Erstellen neuer Objekte müssen Sie alle erforderlichen Felder angeben. Beim Aktualisieren vorhandener Objekte müssen Sie jedoch nur die Felder angeben, die Sie aktualisieren möchten.

Aus der Anwendung der Konfiguration muss immer ein gültiges Kubernetes-Objekt hervorgehen.

Beispielkonfigurationen

Das Beispiel-Repository für Anthos Config Management veranschaulicht die Funktionsweise von Config Sync. Es enthält Beispiele für die folgenden Repository-Typen:

Die folgenden Beispielkonfigurationen stammen alle aus dem Beispiel-Repository. Es kann hilfreich sein, das Beispiel-Repository in einem Browser zu öffnen oder in Ihr lokales System zu klonen.

Die folgenden Beispiele sind nicht vollständig. Sie können jede Art von Kubernetes-Objekt mit Config Sync konfigurieren.

Namespace-Konfiguration

Mit dieser Konfiguration wird ein Namespace namens gamestore erstellt.

apiVersion: v1
kind: Namespace
metadata:
  name: gamestore

Wenn Sie eine Namespace-Konfiguration erstellen, können Sie dem Namespace auch Labels oder Annotationen hinzufügen. Bei der Verwendung von NamespaceSelector sind Labels erforderlich.

Die folgende Beispielkonfiguration erstellt einen Namespace namens gamestore, falls dieser nicht bereits vorhanden ist oder nicht verwaltet wird. Der Namespace hat das Label app: gamestore und die Annotation retail: true. Wenn ein Nutzer die Metadaten des Objekts manuell ändert, wird es durch Config Sync schnell wieder auf den Wert in der Konfiguration zurückgesetzt.

apiVersion: v1
kind: Namespace
metadata:
  name: gamestore
  labels:
    app: gamestore
  annotations:
    retail: "true"

Weitere Informationen zur Verwendung von Namespaces finden Sie unter Namespaces und Namespace-bezogene Objekte konfigurieren.

ClusterRole-Konfiguration

Mit dieser Konfiguration wird eine ClusterRole mit dem Namen namespace-reader erstellt, die das Lesen (get, watch und list) aller namespace-Objekte im Cluster ermöglicht. ClusterRole-Konfigurationen werden häufig zusammen mit ClusterRoleBinding-Konfigurationen verwendet.

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: namespace-reader
rules:
- apiGroups: [""]
  resources: ["namespaces"]
  verbs: ["get", "watch", "list"]

ClusterRoleBinding-Konfiguration

Mit dieser Konfiguration wird ein ClusterRoleBinding namens namespace-readers erstellt, das dem Nutzer cheryl@example.com die Rolle namespace-reader ClusterRole gewährt.

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

ClusterRoleBindings sind clusterbezogen und können nicht in Namespace-Verzeichnisse oder abstrakte Namespaces platziert werden.

PodSecurityPolicy-Konfiguration

In diesem Beispiel wird eine PodSecurityPolicy namens psp erstellt, die die Ausführung von privilegierten Containern unterbindet und die Ausführung von Containern als gültiger Nutzer auf dem Knoten zulässt.

apiVersion: extensions/v1beta1
kind: PodSecurityPolicy
metadata:
  name: psp
spec:
  privileged: false
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  runAsUser:
    rule: RunAsAny
  fsGroup:
    rule: RunAsAny
  volumes:
  - '*'

PodSecurityPolicies sind clusterbezogen und können nicht in Namespace-Verzeichnisse oder abstrakte Namespaces platziert werden.

NetworkPolicy-Konfiguration

In diesem Beispiel wird eine NetworkPolicy mit dem Namen default-deny-all-traffic erstellt.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: default-deny-all-traffic
spec:
  podSelector: {}

NetworkPolicies sind Namespace-bezogen und können nur in Namespace-Verzeichnisse oder abstrakte Namespaces platziert werden.

Wenn Sie die obige NetworkPolicy auf einen einzelnen Namespace anwenden, werden alle Pods in diesem Namespace vom eingehenden und ausgehenden Traffic isoliert.

Wenn Sie dieselbe NetworkPolicy auf mehrere Namespaces anwenden, indem Sie sie in ein abstraktes Namespace mit untergeordneten Namespaces platzieren, wird sie von jedem dieser Namespaces übernommen. Im Beispiel-Repository zur Namespace-Übernahme enthält das Verzeichnis namespaces zwei abstrakte Namespaces, eng und rnd, und jeder abstrakte Namespace enthält zwei tatsächliche Namespaces, analytics und gamestore bzw. incubator-1 und incubator-2. Wenn Sie die oben aufgeführte NetworkPolicy default-deny-all-traffic den abstrakten Namespaces hinzufügen, wird sie von den vier tatsächlichen Namespaces übernommen, sodass jeder ihrer Pods vor eingehendem und ausgehendem Traffic geschützt ist.

Sie können die Namespace-Übernahme nutzen, um einen Sicherheitsansatz auf der Grundlage der geringsten Berechtigung zu erzwingen. Wenn beispielsweise das vorherige NetworkPolicy-Beispiel auf abstrakte Namespaces angewendet wird und die folgende NetworkPolicy dem abstrakten Namespace eng hinzugefügt wird, ist eingehender Traffic nur für Pods in den untergeordneten Namespaces mit dem Label app:gamestore erlaubt. analytics, incubator-1 und incubator-2 Namespaces sind von dieser NetworkPolicy nicht betroffen.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-gamestore-ingress
spec:
  podSelector:
    matchLabels:
      app: gamestore
  ingress:
  - {}

ResourceQuota-Konfiguration

In diesem Beispiel wird ein ResourceQuota namens quota erstellt, das ein festes Limit von 1 Pod, 100 Milli-CPUs und 100 Mebibyte (MiB) Arbeitsspeicher festlegt.

kind: ResourceQuota
apiVersion: v1
metadata:
  name: quota
spec:
  hard:
    pods: "1"
    cpu: "100m"
    memory: "100Mi"

Sollte das Erstellen eines beliebigen neuen Objekts gegen die Limits eines vorhandenen ResourceQuota verstoßen, kann Kubernetes das neue Objekt erst erstellen, wenn dadurch nicht mehr gegen das festgelegte ResourceQuota verstoßen wird.

RepoSync-Konfiguration

In diesem Beispiel wird im Root-Repository ein RepoSync-Objekt erstellt, das aus einem Namespace-Repository synchronisiert wird. Weitere Informationen zum Konfigurieren des RepoSync-Objekts finden Sie unter Synchronisierung aus Namespace-Repositories konfigurieren.

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 erstellt einen Namespace-Abgleicher, um aus dem Namespace-Repository synchronisieren.

Nächste Schritte