Einschränkungen für die Cost and Reliability-Richtlinie verwenden

Policy Controller enthält eine Standardbibliothek mitEinschränkungsvorlagen die mit dem Cost and Reliability-Richtlinien-Bundle verwendet werden können, das dazu beiträgt, Best Practices zum Ausführen kosteneffizienter GKE-Cluster zum implementieren, ohne die Leistung oder Zuverlässigkeit ihrer Arbeitslasten zu beeinträchtigen.

Auf dieser Seite finden Sie eine Anleitung zum manuellen Anwenden eines Richtlinienpakets. Alternativ können Sie Richtlinienpakete direkt anwenden.

Warnung:Nachdem Sie eine Methode zum Anwenden von Richtlinienpaketen ausgewählt haben (manuell, gcloud CLI oder Google Cloud Console), kann die Verwendung einer anderen Methode zum Installieren von Richtlinienpaketen zu Fehlern in Ihrer Umgebung führen.

Einschränkungen für Kosten- und Zuverlässigkeitsrichtlinien-Bundles

Name der Einschränkung	Beschreibung der Einschränkung
cost-reliability-v2023-pod-disruption-budget	Erfordert die PodDisruptionBudget-Konfiguration für Deployments, ReplicaSets, StatefulSets und ReplicationControllers.
cost-reliability-v2023-pod-resources-best-practices	Erfordert, dass für Container Ressourcenanforderungen festgelegt werden und die Best Practices eingehalten werden.
cost-reliability-v2023-required-labels	Erfordert, dass alle Pods und Controller (ReplicaSet, Deployment, StatefulSet und DaemonSet) die erforderlichen Labels haben: "environment", "team" und "app".
cost-reliability-v2023-restrict-repos	Beschränkt Container-Images auf eine zulässige „Repos“-Liste, damit Artifact Registry für das Image-Streaming verwendet werden kann.
cost-reliability-v2023-spotvm-termination-grace	Erfordert terminationGracePeriodSeconds von 15 Sekunden oder weniger für Pods und Pod-Vorlagen mit nodeSelector oder nodeAfffinty für gke-spot.

Hinweise

1. Installieren und initialisieren Sie die Google Cloud CLI, die die in dieser Anleitung verwendeten Befehle gcloud und kubectl enthält. Wenn Sie Cloud Shell verwenden, ist die Google Cloud CLI vorinstalliert.
2. Installieren Sie den Policy Controller in Ihrem Cluster mit der Standardbibliothek an Einschränkungsvorlagen. Sie müssen auch die Unterstützung für referenzielle Einschränkungen aktivieren, da dieses Bundle referenzielle Einschränkungen enthält.

Policy Controller für referenzielle Einschränkungen konfigurieren

Warnung: Sie können eigene Änderungen überschreiben. Wenn Sie bereits einen Config im Namespace gatekeeper-system haben, müssen Sie alle vorherigen Anpassungseinstellungen einschließen, um Ihre Änderungen beizubehalten.

1. Speichern Sie das folgende YAML-Manifest in einer Datei als policycontroller-config.yaml. Das Manifest konfiguriert Policy Controller so, dass bestimmte Arten von Objekten beobachtet werden.

   apiVersion: config.gatekeeper.sh/v1alpha1
   kind: Config
   metadata:
     name: config
     namespace: "gatekeeper-system"
   spec:
     sync:
       syncOnly:
         - group: ""
           version: "v1"
           kind: "Service"
         - group: "policy"
           version: "v1"
           kind: "PodDisruptionBudget"
   

2. Wenden Sie das policycontroller-config.yaml-Manifest an:

   kubectl apply -f policycontroller-config.yaml
   

Cluster und Arbeitslast konfigurieren

1. Für alle von einem service ausgewählten pod müssen Bereitschaftstests enthalten sein.
2. Alle deployment, replicaset, statefulset und replicationcontroller müssen ein poddisruptionbudget enthalten.
3. Alle Container sollten cpu- und memory-Anfragen sowie ein memory-Limit enthalten, das den memory-Anfragen gemäß den Best Practices entspricht.
4. Fügen Sie allen Pods und Pod-Vorlagen die Labels environment, team und app hinzu.
5. Hosten Sie Container-Images mit Artifact Registry in derselben Region wie Ihren Cluster, um das Image-Streaming zu aktivieren. Lassen Sie die entsprechende Artifact Registry zu. Folgen Sie dazu dem Beispiel in cost-reliability-v2023-restrict-repos.
6. Alle Pods und Pod-Vorlagen, die gke-spot verwenden, müssen einen terminationGracePeriodSeconds von maximal 15 Sekunden enthalten.

Cost and Reliability-Richtlinien-Bundle prüfen

Mit Policy Controller können Sie Richtlinien für Ihren Kubernetes-Cluster erzwingen. Damit Sie Ihre Arbeitslasten und deren Compliance in Bezug auf die in der vorherigen Tabelle beschriebenen Cost and Reliability-Richtlinien testen können, können Sie diese Einschränkungen im „Audit”-Modus bereitstellen, um Verstöße aufzudecken und vor allem selbst eine Gelegenheit zu geben, um sie zu beheben, bevor Sie sie auf Ihrem Kubernetes-Cluster erzwingen.

Sie können diese Richtlinien mit kpt oder Config Sync festlegen, wobei spec.enforcementAction auf dryrun gesetzt ist.

kubectl

1. (Optional) Sehen Sie sich eine Vorschau der Richtlinieneinschränkungen mit kubectl an:

   kubectl kustomize https://github.com/GoogleCloudPlatform/gke-policy-library.git/anthos-bundles/cost-reliability-v2023
   

2. Wenden Sie die Richtlinieneinschränkungen mit kubectl an:

   kubectl apply -k https://github.com/GoogleCloudPlatform/gke-policy-library.git/anthos-bundles/cost-reliability-v2023
   

   Die Ausgabe sieht so aus:

   gkespotvmterminationgrace.constraints.gatekeeper.sh/cost-reliability-v2023-spotvm-termination-grace created
   k8sallowedrepos.constraints.gatekeeper.sh/cost-reliability-v2023-restrict-repos created
   k8spoddisruptionbudget.constraints.gatekeeper.sh/cost-reliability-v2023-pod-disruption-budget created
   k8spodresourcesbestpractices.constraints.gatekeeper.sh/cost-reliability-v2023-pod-resources-best-practices created
   k8srequiredlabels.constraints.gatekeeper.sh/cost-reliability-v2023-required-labels created
   

3. Prüfen Sie, ob Richtlinieneinschränkungen installiert wurden, und prüfen Sie, ob im Cluster Verstöße vorliegen:

   kubectl get constraints -l policycontroller.gke.io/bundleName=cost-reliability-v2023
   

   Die Ausgabe sieht in etwa so aus:

   NAME                                                                                                  ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   gkespotvmterminationgrace.constraints.gatekeeper.sh/cost-reliability-v2023-spotvm-termination-grace   dryrun               0
   
   NAME                                                                                                         ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   k8spodresourcesbestpractices.constraints.gatekeeper.sh/cost-reliability-v2023-pod-resources-best-practices   dryrun               0
   
   NAME                                                                                            ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   k8spoddisruptionbudget.constraints.gatekeeper.sh/cost-reliability-v2023-pod-disruption-budget   dryrun               0
   
   NAME                                                                              ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   k8sallowedrepos.constraints.gatekeeper.sh/cost-reliability-v2023-restrict-repos   dryrun               0
   
   NAME                                                                                 ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   k8srequiredlabels.constraints.gatekeeper.sh/cost-reliability-v2023-required-labels   dryrun               0
   

KPT

1. Installieren und richten Sie kpt ein.

   kpt wird in dieser Anleitung verwendet, um Kubernetes-Ressourcen anzupassen und bereitzustellen.

2. Laden Sie das PCI-DSS v3.2.1-Richtlinien-Bundle von GitHub mit kpt herunter:

   kpt pkg get https://github.com/GoogleCloudPlatform/gke-policy-library.git/anthos-bundles/cost-reliability-v2023
   

3. Führen Sie die kpt-Funktion set-enforcement-action aus, um die Erzwingungsaktion der Richtlinien auf dryrun festzulegen:

   kpt fn eval cost-reliability-v2023 -i gcr.io/kpt-fn/set-enforcement-action:v0.1 \
   -- enforcementAction=dryrun
   

4. Initialisieren Sie das Arbeitsverzeichnis mit kpt, wodurch eine Ressource erstellt wird, um Änderungen verfolgen zu können:

   cd cost-reliability-v2023 kpt live init
   

5. Wenden Sie die Richtlinieneinschränkungen mit kpt an:

   kpt live apply
   

6. Prüfen Sie, ob Richtlinieneinschränkungen installiert wurden, und prüfen Sie, ob im Cluster Verstöße vorliegen:

   kpt live status --output table --poll-until current
   

   Der Status CURRENT bestätigt die erfolgreiche Installation der Einschränkungen.

Config Sync

1. Installieren und richten Sie kpt ein.

   kpt wird in dieser Anleitung verwendet, um Kubernetes-Ressourcen anzupassen und bereitzustellen.

   Operatoren, die Config Sync zum Bereitstellen von Richtlinien für ihre Cluster verwenden, können die folgende Anleitung verwenden:

2. Wechseln Sie in das Synchronisierungsverzeichnis für Config Sync:

   cd SYNC_ROOT_DIR
   

   Hinweis: Kpt v1.0.0-beta.17 und höher erstellt automatisch eine resourcegroup.yaml-Datei während live init. Diese sollte nicht in Ihr Config Sync-Repository eingecheckt werden. Falls noch nicht vorhanden, fügen Sie resourcegroup.yaml zur Datei .gitignore Ihres Repositorys hinzu.

   So erstellen Sie resourcegroup.yaml oder hängen es an .gitignore an:

   echo resourcegroup.yaml >> .gitignore
   

3. Erstellen Sie ein dediziertes policies-Verzeichnis:

   mkdir -p policies
   

4. Laden Sie das Cost and Reliability-Richtlinien-Bundle von GitHub mit kpt herunter:

   kpt pkg get https://github.com/GoogleCloudPlatform/gke-policy-library.git/anthos-bundles/cost-reliability-v2023 policies/cost-reliability-v2023
   

5. Führen Sie die kpt-Funktion set-enforcement-action aus, um die Erzwingungsaktion der Richtlinien auf dryrun festzulegen:

   kpt fn eval policies/cost-reliability-v2023 -i gcr.io/kpt-fn/set-enforcement-action:v0.1 -- enforcementAction=dryrun
   

6. (Optional) Sehen Sie sich eine Vorschau der Richtlinieneinschränkungen an, die erstellt werden sollen:

   kpt live init policies/cost-reliability-v2023
   kpt live apply --dry-run policies/cost-reliability-v2023
   

7. Wenn Ihr Synchronisierungsverzeichnis für Config Sync Kustomize verwendet, fügen Sie policies/cost-reliability-v2023 Ihrer Stamm-kustomization.yaml hinzu. Andernfalls entfernen Sie die Datei policies/cost-reliability-v2023/kustomization.yaml:

   rm SYNC_ROOT_DIR/policies/cost-reliability-v2023/kustomization.yaml
   

8. Übertragen Sie Änderungen per Push in das Config Sync-Repository:

   git add SYNC_ROOT_DIR/policies/cost-reliability-v2023 git commit -m 'Adding Cost and Reliability policy audit enforcement'
   git push
   

9. Prüfen Sie den Status der Installation:

   watch gcloud beta container fleet config-management status --project PROJECT_ID
   

   Der Status SYNCED bestätigt die Installation der Richtlinien.

Richtlinienverstöße ansehen

Sobald die Richtlinieneinschränkungen im Prüfmodus installiert sind, können Verstöße im Cluster in der UI über das Policy Controller-Dashboard angezeigt werden.

Mit kubectl können Sie auch Verstöße im Cluster mit dem folgenden Befehl aufrufen:

  kubectl get constraint -l policycontroller.gke.io/bundleName=cost-reliability-v2023 -o json | jq -cC '.items[]| [.metadata.name,.status.totalViolations]'
  

Wenn Verstöße vorhanden sind, kann eine Liste der Nachrichten zu Verstößen pro Einschränkung angezeigt werden mit:

  kubectl get constraint -l policycontroller.gke.io/bundleName=cost-reliability-v2023 -o json | jq -C '.items[]| select(.status.totalViolations>0)| [.metadata.name,.status.violations[]?]'
  

Erzwingungsaktion für das Cost and Reliability-Richtlinien-Bundle ändern

Nachdem Sie die Richtlinienverstöße in Ihrem Cluster überprüft haben, können Sie den Erzwingungsmodus ändern, sodass der Zulassungs-Controller entweder eine warn- oder sogar eine deny-Aktion dafür ausführt, dass verhindert wird, dass nicht konforme Ressourcen auf den Cluster angewendet werden.

Warnung: Verwenden Sie die Maßnahme deny mit Bedacht, da sie möglicherweise erforderliche Änderungen blockiert, was zu einer Unterbrechung kritischer Arbeitslasten oder des Clusters führt. Es wird dringend empfohlen, dass Sie nur die Maßnahmen warn oder dryrun in Clustern mit Produktionsarbeitslasten verwenden, wenn Sie neue Einschränkungen testen oder Migrationen wie Plattformupgrades machen. Weitere Informationen zu Maßnahmen finden Sie unter Auditing mit Einschränkungen.

kubectl

1. Verwenden Sie kubectl, um die Maßnahme der Richtlinien auf warn festzulegen:

   kubectl get constraints -l policycontroller.gke.io/bundleName=cost-reliability-v2023 -o name | xargs -I {} kubectl patch {} --type='json' -p='[{"op":"replace","path":"/spec/enforcementAction","value":"warn"}]'
   

2. Prüfen Sie, ob die Maßnahme für Richtlinieneinschränkungen aktualisiert wurde:

   kubectl get constraints -l policycontroller.gke.io/bundleName=cost-reliability-v2023
   

KPT

1. Führen Sie die kpt-Funktion set-enforcement-action aus, um die Erzwingungsaktion der Richtlinien auf warn festzulegen:

   kpt fn eval -i gcr.io/kpt-fn/set-enforcement-action:v0.1 -- enforcementAction=warn
   

2. Wenden Sie die Richtlinieneinschränkungen an:

   kpt live apply
   

Config Sync

Operatoren, die Config Sync zum Bereitstellen von Richtlinien für ihre Cluster verwenden, können die folgende Anleitung verwenden:

1. Wechseln Sie in das Synchronisierungsverzeichnis für Config Sync:

   cd SYNC_ROOT_DIR
   

2. Führen Sie die kpt-Funktion set-enforcement-action aus, um die Erzwingungsaktion der Richtlinien auf warn festzulegen:

   kpt fn eval policies/cost-reliability-v2023 -i gcr.io/kpt-fn/set-enforcement-action:v0.1 -- enforcementAction=warn
   

3. Übertragen Sie Änderungen per Push in das Config Sync-Repository:

   git add SYNC_ROOT_DIR/policies/cost-reliability-v2023
   git commit -m 'Adding Cost and Reliability policy bundle warn enforcement'
   git push
   

4. Prüfen Sie den Status der Installation:

   nomos status
   

   Der Cluster sollte den Status SYNCED mit den installierten Richtlinien anzeigen.

Richtlinienerzwingung testen

Erstellen Sie mit dem folgenden Befehl eine nicht konforme Ressource im Cluster:

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  namespace: default
  name: wp-non-compliant
  labels:
    app: wordpress
spec:
  containers:
    - image: wordpress
      name: wordpress
      ports:
      - containerPort: 80
        hostPort: 80
        name: wordpress
EOF

Der Zulassungs-Controller sollte eine Warnung ausgeben, in der die Richtlinienverstöße aufgeführt sind, gegen die diese Ressource verstößt, wie im folgenden Beispiel gezeigt:

Warning: [cost-reliability-v2023-pod-resources-best-practices] Container <wordpress> must set <cpu> request.
Warning: [cost-reliability-v2023-pod-resources-best-practices] Container <wordpress> must set <memory> request.
Warning: [cost-reliability-v2023-required-labels] This app is missing one or more required labels: `environment`, `team`, and `app`.
Warning: [cost-reliability-v2023-restrict-repos] container <wordpress> has an invalid image repo <wordpress>, allowed repos are ["gcr.io/gke-release/", "gcr.io/anthos-baremetal-release/", "gcr.io/config-management-release/", "gcr.io/kubebuilder/", "gcr.io/gkeconnect/", "gke.gcr.io/"]
pod/wp-non-compliant created

Cost and Reliability-Richtlinien-Bundle entfernen

Bei Bedarf kann das Cost and Reliability-Richtlinien-Bundle aus dem Cluster entfernt werden.

kubectl

Verwenden Sie kubectl, um die Richtlinien zu entfernen:

  kubectl delete constraint -l policycontroller.gke.io/bundleName=cost-reliability-v2023
  

KPT

Entfernen Sie die Richtlinien:

  kpt live destroy
  

Config Sync

Operatoren, die Config Sync zum Bereitstellen von Richtlinien für ihre Cluster verwenden, können die folgende Anleitung verwenden:

1. Übertragen Sie Änderungen per Push in das Config Sync-Repository:

   git rm -r SYNC_ROOT_DIR/policies/cost-reliability-v2023
   git commit -m 'Removing Cost and Reliability policies'
   git push
   

2. Prüfen Sie den Status:

   nomos status
   

   Der Cluster sollte den Status SYNCED haben und die Ressourcen sollten entfernt sein.