Kubernetes-Objekte konfigurieren

Auf dieser Seite wird beschrieben, wie Sie configs erstellen; die Dateien, die Config Sync aus Git liest und automatisch auf Ihre Cluster anwendet.

Hinweis

  • Machen Sie sich mit der Struktur des Repositorys vertraut. 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.

  • 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.

  • Wir haben ein kanonisches Beispiel-Repository erstellt, um die Funktionsweise von Config Sync zu veranschaulichen. Die Beispiele in diesem Thema stammen aus diesem Repository. Daher kann es hilfreich sein, das Repository in einem Browser zu öffnen oder in Ihr lokales System zu klonen.

Konfiguration erstellen

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

Speicherort im Repository

Neben anderen Faktoren bestimmt der Speicherort einer Konfiguration im Repository, 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.
  • Konfigurationen für Config Sync-Komponenten werden im Verzeichnis system/ des Repositorys gespeichert.
  • Die Konfiguration für den Config Sync 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.

Bestehende Kubernetes-Objekte konfigurieren

Sie können eine Konfiguration für ein vorhandenes Kubernetes-Objekt erstellen, z. B. einen Namespace, der bereits in Ihrem Cluster vorhanden ist, bevor Sie Config Sync installieren. Diese Konfiguration wird jedoch ignoriert, sofern das Objekt nicht die Annotation configmanagement.gke.io/managed: enabled enthält. Bei einem vorhandenen Objekt müssen Sie die Annotation manuell anwenden.

Insbesondere bei Namespaces werden von Config Sync Konfigurationen angewendet, die neue Objekte innerhalb eines nicht annotierten Namespace erstellen. Auf diese Objekte wird anschließend die Annotation configmanagement.gke.io/managed: enabled angewendet. Config Sync nimmt jedoch keine Änderungen an nicht annotierten Objekten eines Clusters vor und entfernt diese auch nicht. Das wird im Abschnitt Mit Konfigurationen arbeiten mithilfe eines Diagramms gezeigt.

CustomResourceDefinitions konfigurieren

Config Sync ermöglicht die Synchronisierung von CustomResourceDefinitions (CRDs) auf die gleiche Weise, wie Sie jede andere Ressource synchronisieren würden. Folgendes sollten Sie bei der Synchronisierung von CRDs bedenken:

  • CRDs müssen, selbst wenn eine benutzerdefinierte Ressource mit Namespace deklariert wird, im Verzeichnis cluster/ abgelegt werden.

  • Aktualisierungen von CRDs und der zugehörigen CustomResources erfolgen nicht in einer vorhersehbaren Reihenfolge. Wenn Sie CRDs und die entsprechenden CustomResources im selben Commit ändern, kann nicht davon ausgegangen werden, dass CRD-Aktualisierungen vor benutzerdefinierten Ressourcen aktualisiert werden. Das kann dazu führen, dass die Logs syncer kurz einen vorübergehenden Fehler melden, bis sowohl die CustomResource als auch die CRD im Cluster vorhanden sind.

  • Config Sync lässt das Entfernen einer CRD nicht zu, wenn eine CustomResource im Repository davon abhängt. Zum Entfernen einer CRD müssen Sie auch deren CustomResource entfernen. Deshalb sollten immer beide im selben Commit im Repository entfernt werden.

  • Sie können eine CustomResource synchronisieren, ohne dabei ihre CRD zu synchronisieren, solange Sie garantieren können, dass die CRD bereits im Cluster vorhanden ist.

Beispielkonfigurationen

Mithilfe der folgenden Beispielkonfigurationen, die alle aus dem Beispiel-Repository stammen, sollten Sie eigene Konfigurationen schreiben können. Diese Liste ist nicht vollständig. Sie können jede Art von Kubernetes-Objekt mit Config Sync konfigurieren.

Namespace-Konfiguration

Mit dieser Konfiguration wird ein Namespace namens audit erstellt.

apiVersion: v1
kind: Namespace
metadata:
  name: audit

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 shipping-prod, falls dieser nicht bereits vorhanden ist oder nicht verwaltet wird. Der Namespace hat das Label env: prod und die Annotation audit: 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: shipping-prod
  labels:
    env: prod
  annotations:
    audit: "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@foo-corp.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@foo-corp.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 ist shipping-app-backend ein abstrakter Namespace, der Konfigurationen für shipping-dev, shipping-prod und shipping-stage enthält. Wenn Sie diesen Namespaces die NetworkPolicy aus dem obigen Beispiel hinzufügen, wird sie von jedem Namespace ü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 shipping-app-backend angewendet und die folgende NetworkPolicy dem Namespace shipping-dev hinzugefügt wird, wird eingehender Traffic nur für Pods in diesem Namespace mit dem Label app:nginx zugelassen. shipping-prod und shipping-staging Namespaces sind von dieser NetworkPolicy nicht betroffen.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-nginx-ingress
spec:
  podSelector:
    matchLabels:
      app: nginx
  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.

Nächste Schritte