Zum Hauptinhalt springen
Version: 2.6.7

Häufig gestellte Fragen

Inoffizielle Beta-Übersetzung

Diese Seite wurde von PageTurner AI übersetzt (Beta). Nicht offiziell vom Projekt unterstützt. Fehler gefunden? Problem melden →

Wenn ich keine Kubernetes-Cluster bereitgestellt habe, kann ich dann mit Chaos Mesh Chaos-Experimente durchführen?​

Nein. Stattdessen können Sie chaosd verwenden, um Fehler ohne Kubernetes zu injizieren.

Ich habe Chaos Mesh bereitgestellt und PodChaos-Experimente erfolgreich erstellt, scheitere aber weiterhin bei der Erstellung von NetworkChaos/TimeChaos-Experimenten. Die Protokollausgabe sieht wie folgt aus:​

2020-06-18T02:49:15.160Z ERROR controllers.TimeChaos failed to apply chaos on all pods {"reconciler": "timechaos", "error": "rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing dial tcp xx.xx.xx.xx:xxxx: connect: connection refused\""}

Der Grund ist, dass chaos-controller-manager keine Verbindung zu chaos-daemon herstellen konnte. Überprüfen Sie zunächst das Pod-Netzwerk und dessen Richtlinien.

Wenn alles in Ordnung ist, können Sie möglicherweise den Parameter hostNetwork verwenden, um das Problem wie folgt zu beheben:

Referenz: https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/#hostport-services-do-not-work

Das Standard-Administratorkonto von Google Cloud darf keine Chaos-Experimente erstellen. Wie behebe ich das?​

Der Standard-Google-Cloud-Administrator kann nicht durch AdmissionReview überprüft werden. Sie müssen eine Administratorrolle erstellen und diese Ihrem Konto zuweisen, um ihm die Berechtigung zum Erstellen von Chaos-Experimenten zu erteilen. Beispiel:

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: role-cluster-manager-pdmas
rules:
  - apiGroups: ['']
    resources: ['pods', 'namespaces']
    verbs: ['get', 'watch', 'list']
  - apiGroups:
      - chaos-mesh.org
    resources: ['*']
    verbs: ['get', 'list', 'watch', 'create', 'delete', 'patch', 'update']
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: cluster-manager-binding
  namespace: chaos-mesh
subjects:
  # Google Cloud user account
  - kind: User
    name: USER_ACCOUNT
roleRef:
  kind: ClusterRole
  name: role-cluster-manager-pdmas
  apiGroup: rbac.authorization.k8s.io

USER_ACCOUNT sollte hier Ihre Google-Cloud-Benutzer-E-Mail-Adresse sein.

Daemon wirft einen Fehler ähnlich zu version 1.41 is too new. The maximum supported API version is 1.39​

Dies zeigt an, dass die maximale API-Version, die der Docker-Daemon akzeptiert, 1.39 beträgt, während der Client in chaos-daemon standardmäßig 1.41 verwendet. Sie haben folgende Optionen zur Problemlösung:

  1. Aktualisieren Sie Docker auf eine neuere Version.

  2. Helm-Installation/Upgrade mit --set chaosDaemon.env.DOCKER_API_VERSION=1.39 durchführen.

DNSChaos​

Bei der Ausführung von DNSChaos in OpenShift blockieren Autorisierungsprobleme den Prozess​

Wenn die Fehlermeldung ähnlich wie folgt lautet:

Error creating: pods "chaos-dns-server-123aa56123-" is forbidden: unable to validate against any security context constraint: [spec.containers[0].securityContext.capabilities.add: Invalid value: "NET_BIND_SERVICE": capability may not be added]

Müssen Sie dem chaos-dns-server die privilegierten Security Context Constraints (SCC) hinzufügen.

oc adm policy add-scc-to-user privileged -n chaos-mesh -z chaos-dns-server

Installation​

Bei der Installation von Chaos Mesh in OpenShift blockieren Autorisierungsprobleme den Installationsprozess​

Wenn die Fehlermeldung ähnlich wie folgt lautet:

Error creating: pods "chaos-daemon-" is forbidden: unable
 to validate against any security context constraint: [spec.securityContext.hostNetwork:
 Invalid value: true: Host network is not allowed to be used spec.securityContext.hostPID:
 Invalid value: true: Host PID is not allowed to be used spec.securityContext.hostIPC:
 Invalid value: true: Host IPC is not allowed to be used securityContext.runAsUser:
 Invalid value: "hostPath": hostPath volumes are not allowed to be used spec.containers[0].securityContext.volumes[1]:
 Invalid value: true: Host network is not allowed to be used spec.containers[0].securityContext.containers[0].hostPort:
 Invalid value: 31767: Host ports are not allowed to be used spec.containers[0].securityContext.hostPID:
 Invalid value: true: Host PID is not allowed to be used spec.containers[0].securityContext.hostIPC:
......]

Müssen Sie dem Default-Namespace privilegierte SCC hinzufügen.

oc adm policy add-scc-to-user privileged -n chaos-mesh -z chaos-daemon

Installation von Chaos Mesh fehlgeschlagen mit der Meldung: no matches for kind "CustomResourceDefinition" in version "apiextensions.k8s.io/v1"​

Dieses Problem tritt auf, wenn Sie Chaos Mesh auf Kubernetes v1.15 oder älter installieren. Wir verwenden standardmäßig apiextensions.k8s.io/v1, das jedoch erst in Kubernetes v1.16 am 2019-09-19 eingeführt wurde.

Bei Installation auf Kubernetes unter v1.16 müssen Sie folgendermaßen vorgehen:

  1. CRD manuell über https://mirrors.chaos-mesh.org/<chaos-mesh-version>/crd-v1beta1.yaml erstellen.

  2. --validate=false hinzufügen. Ohne diese Konfiguration können Kompatibilitätsprobleme mit Breaking Changes bei CRD auftreten. Beispiel: kubectl create -f https://mirrors.chaos-mesh.org/v2.1.0/crd-v1beta1.yaml --validate=false.

  3. Den restlichen Installationsprozess mit Helm abschließen und dem helm install-Befehl --skip-crds hinzufügen.

Wir empfehlen ein Upgrade Ihres Kubernetes-Clusters gemäß der Kubernetes Version Skew Policy.

Chaosd​

Fehlermeldung: attempt to write a readonly database​

Bei der Ausführung von chaosd im Befehls- oder Dienstmodus tritt dieser Fehler auf, wenn der aktuelle Benutzer keine Schreibberechtigungen für die von chaosd verwendete SQLite-Datenbankdatei besitzt. Standardmäßig befindet sich die Datenbankdatei im Chaosd-Installationsverzeichnis unter /usr/local/chaosd-v$VERSION-$OS-$ARCH/chaosd.db (z.B. /usr/local/chaosd-v1.4.0-linux-amd64/chaosd.db).

So beheben Sie das Problem:

# Replace the path with your actual chaosd installation directory
sudo chmod 666 /usr/local/chaosd-v*/chaosd.db
# Also ensure the directory is writable
sudo chmod 775 /usr/local/chaosd-v*/

Alternativ können Sie chaosd mit entsprechenden Privilegien ausführen oder den Besitzer der Datenbankdatei auf Ihren aktuellen Benutzer ändern.

Netzwerkchaos-Experimente mit tc und iptables erfordern sudo-Berechtigungen​

Bei der Erstellung von Netzwerkchaos-Experimenten, die tc (Traffic Control) oder iptables verwenden, müssen Sie chaosd-Befehle mit sudo oder Root-Rechten ausführen. Ohne entsprechende Berechtigungen scheitert die Anwendung der Chaos-Attacke und auch die Wiederherstellung.

Beispiele für sudo-pflichtiges Netzwerkchaos:

  • Netzwerklatenz, Paketverlust, -duplizierung oder -korruption

  • Netzwerkbandbreitenbegrenzung

  • Netzwerkpartitionierung

So führen Sie diese Experimente aus:

# Command mode
sudo chaosd attack network delay --device eth0 --latency 100ms

# Service mode - start the service with sudo
sudo chaosd server

Ohne sudo können Fehler wie "permission denied" oder "operation not permitted" auftreten, wenn Netzwerkkonfigurationen geändert werden sollen.