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 Verzeichnissesnamespaces/
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
- Clusterbezogene Objekte konfigurieren
- Namespace-bezogene Objekte konfigurieren
- Kurzanleitung für die Verwaltung und das Aufheben der Verwaltung von Objekten.