{"meta":{"title":"Problembehandlung bei Actions Runner Controller-Fehlern","intro":"Erfahre, wie du Actions Runner Controller-Fehler beheben kannst.","product":"GitHub Actions","breadcrumbs":[{"href":"/de/actions","title":"GitHub Actions"},{"href":"/de/actions/tutorials","title":"Anleitungen"},{"href":"/de/actions/tutorials/use-actions-runner-controller","title":"Actions Runner Controller (Steuerung für Aktionsläufer)"},{"href":"/de/actions/tutorials/use-actions-runner-controller/troubleshoot","title":"Problembehandlung"}],"documentType":"article"},"body":"# Problembehandlung bei Actions Runner Controller-Fehlern\n\nErfahre, wie du Actions Runner Controller-Fehler beheben kannst.\n\n## Protokollierung\n\nDie ARC-Ressourcen (Actions Runner Controller), zu denen der Controller, der Listener und die Runner gehören, schreiben Protokolle in die Standardausgabe (`stdout`). Du solltest eine Protokollierungslösung implementieren, um diese Protokolle zu sammeln und zu speichern. Wenn Protokolle verfügbar sind, kann das Ihnen oder dem GitHub-Support bei der Störungsbehebung und beim Debuggen helfen. Weitere Informationen findest du in der Kubernetes-Dokumentation unter [Protokollierungsarchitektur](https://kubernetes.io/docs/concepts/cluster-administration/logging/).\n\n## Ressourcenetiketten\n\nBezeichnungen werden den vom Actions Runner Controller erstellten Ressourcen hinzugefügt, zu denen Controller, Listener und Runner-Pods gehören. Du kannst diese Bezeichnungen verwenden, um Ressourcen zu filtern und dir die Problembehandlung zu erleichtern.\n\n### Controllerpod\n\nDie folgenden Labels werden auf den Controller-Pod angewendet.\n\n```yaml\napp.kubernetes.io/component=controller-manager\napp.kubernetes.io/instance=<controller installation name>\napp.kubernetes.io/name=gha-runner-scale-set-controller\napp.kubernetes.io/part-of=gha-runner-scale-set-controller\napp.kubernetes.io/version=<chart version>\n```\n\n### Listenerpod\n\nDie folgenden Bezeichnungen werden auf Listener-Pods angewendet:\n\n```yaml\nactions.github.com/enterprise= # Will be populated if githubConfigUrl is an enterprise URL\nactions.github.com/organization= # Will be populated if githubConfigUrl is an organization URL\nactions.github.com/repository= # Will be populated if githubConfigUrl is a repository URL\nactions.github.com/scale-set-name= # Runners scale set name\nactions.github.com/scale-set-namespace= # Runners namespace\napp.kubernetes.io/component=runner-scale-set-listener\napp.kubernetes.io/part-of=gha-runner-scale-set\napp.kubernetes.io/version= # Chart version\n```\n\n### Runnerpod\n\nDie folgenden Bezeichnungen werden auf Runner-Pods angewendet.\n\n```yaml\nactions-ephemeral-runner= # True | False\nactions.github.com/organization= # Will be populated if githubConfigUrl is an organization URL\nactions.github.com/scale-set-name= # Runners scale set name\nactions.github.com/scale-set-namespace= # Runners namespace\napp.kubernetes.io/component=runner\napp.kubernetes.io/part-of=gha-runner-scale-set\napp.kubernetes.io/version= # Chart version\n```\n\n## Überprüfen der Protokolle des Controllers und des Runner-Set-Listeners\n\nUm die Protokolle des Controllerpods zu überprüfen, kannst du den folgenden Befehl verwenden.\n\n```bash copy\nkubectl logs -n <CONTROLLER_NAMESPACE> -l app.kubernetes.io/name=gha-runner-scale-set-controller\n```\n\nUm die Protokolle des Runnersatzlisteners zu überprüfen, kannst du den folgenden Befehl verwenden.\n\n```bash copy\nkubectl logs -n <CONTROLLER_NAMESPACE> -l auto-scaling-runner-set-namespace=arc-systems -l auto-scaling-runner-set-name=arc-runner-set\n```\n\n## Verwenden der Diagramme aus dem `master`-Branch\n\nDu solltest die Diagramme aus dem neuesten Release anstatt aus dem `master`-Branch verwenden. Der `master`-Branch ist sehr instabil, und wir können nicht garantieren, dass die Diagramme im `master`-Branch zu einem bestimmten Zeitpunkt funktionieren.\n\n## Problembehandlung des Listenerpods\n\nWenn der Controllerpod ausgeführt wird, der Listenerpod jedoch nicht, überprüfe zuerst anhand der Protokolle des Controllers, ob Fehler vorliegen. Wenn keine Fehler vorliegen und der Listenerpod des Runnersatzes weiterhin nicht ausgeführt wird, stelle sicher, dass der Controllerpod Zugriff auf den Kubernetes-API-Server in deinem Cluster hat.\n\nWenn du einen Proxy konfiguriert hast oder einen Sidecar-Proxy wie [Istio](https://istio.io/)verwendest, der automatisch eingefügt wird, stelle sicher, dass er so konfiguriert ist, dass Datenverkehr vom Controllercontainer (Manager) an den Kubernetes-API-Server zugelassen wird.\n\nWenn du den Autoskalierungsrunnersatz installiert hast, der Listenerpod jedoch nicht erstellt wird, überprüfe, ob das von dir bereitgestellte `githubConfigSecret` korrekt ist, und die von dir bereitgestellte `githubConfigUrl` stimmt. Weitere Informationen findest du unter [Authentifizieren von ARC für die GitHub-API](/de/actions/hosting-your-own-runners/managing-self-hosted-runners-with-actions-runner-controller/authenticating-to-the-github-api) und [Bereitstellen von Runner-Skalierungssets mit Actions Runner Controller](/de/actions/hosting-your-own-runners/managing-self-hosted-runners-with-actions-runner-controller/deploying-runner-scale-sets-with-actions-runner-controller).\n\n## Runner-Pods werden nach einer abgebrochenen Workflowausführung neu erstellt.\n\nSobald eine Workflowausführung abgebrochen wurde, treten die folgenden Ereignisse ein.\n\n* Das Abbruchsignal wird direkt an die Runner gesendet.\n* Die Runner-Anwendung wird beendet, wodurch auch die Runner-Pods beendet werden.\n* Bei der nächsten Abfrage empfängt der Listener das Abbruchsignal.\n\nZwischen dem Empfang des Signals durch die Runner und dem Empfang des Signals durch den Listener kann es zu einer geringfügigen Verzögerung kommen. Wenn Runner-Pods beginnen, herunterzufahren, versucht der Listener, neue Runner zu starten, um über die dem Zustand, in dem er sich befindet, entsprechende gewünschte Anzahl von Runnern zu verfügen. Wenn der Listener jedoch das Abbruchsignal empfängt, wird er Maßnahmen ergreifen, um die Anzahl der Läufer zu reduzieren. Schließlich wird der Listener wieder auf die gewünschte Anzahl von Runnern skalieren. In der Zwischenzeit können Sie zusätzliche Läufer bemerken.\n\n## Fehler: `Name must have up to n characters`\n\nARC verwendet die generierten Namen bestimmter Ressourcen als Bezeichnungen für andere Ressourcen. Aufgrund dieser Anforderung beschränkt ARC Ressourcennamen auf 63 Zeichen.\n\nDa ein Teil des Ressourcennamens von dir definiert wird, legt ARC eine Beschränkung für die Anzahl der Zeichen fest, die du für den Installationsnamen und den Namespace verwenden kannst.\n\n```bash\nError: INSTALLATION FAILED: execution error at (gha-runner-scale-set/templates/autoscalingrunnerset.yaml:5:5): Name must have up to 45 characters\n\nError: INSTALLATION FAILED: execution error at (gha-runner-scale-set/templates/autoscalingrunnerset.yaml:8:5): Namespace must have up to 63 characters\n```\n\n## Fehler: `Access to the path /home/runner/_work/_tool is denied`\n\nDieser Fehler wird möglicherweise angezeigt, wenn du den Kubernetes-Modus mit persistenten Volumes verwendest. Dieser Fehler tritt auf, wenn der Runnercontainer mit einem Nicht-Root-Benutzer ausgeführt wird und einen Berechtigungskonflikt mit dem eingebundenen Volume verursacht.\n\nFühre einen der folgenden Schritte aus, um das Problem zu beheben.\n\n* Verwende einen Volumetyp, der `securityContext.fsGroup` unterstützt.\n  `hostPath`-Volumes unterstützen diese Eigenschaft nicht, während `local`-Volumes und andere Arten von Volumes sie unterstützen. Aktualisiere das `fsGroup` deines Runnerpods, um der GID des Runners zu entsprechen. Hierzu kannst du die `gha-runner-scale-set`-Helm-Diagrammwerte aktualisieren, um Folgendes einzuschließen. Ersetze `VERSION` durch die Version des `actions-runner`-Containerimages, die du verwenden möchtest.\n\n  ```yaml copy\n  template:\n    spec:\n      securityContext:\n        fsGroup: 123\n      containers:\n        - name: runner\n          image: ghcr.io/actions/actions-runner:latest\n          command: [\"/home/runner/run.sh\"]\n  ```\n\n* Wenn das Aktualisieren des `securityContext` deines Runner-Pods keine praktikable Lösung ist, kannst du das Problem umgehen, indem du mit `initContainers` den Besitz des eingebundenen Volumes wie folgt änderst.\n\n  ```yaml copy\n  template:\n    spec:\n      initContainers:\n        - name: kube-init\n          image: ghcr.io/actions/actions-runner:latest\n          command: [\"sudo\", \"chown\", \"-R\", \"1001:123\", \"/home/runner/_work\"]\n      volumeMounts:\n        - name: work\n          mountPath: /home/runner/_work\n      containers:\n        - name: runner\n          image: ghcr.io/actions/actions-runner:latest\n          command: [\"/home/runner/run.sh\"]\n  ```\n\n## Fehler: `failed to get access token for GitHub App auth: 401 Unauthorized`\n\nEin `401 Unauthorized`-Fehler beim Versuch, ein Zugriffstoken für eine GitHub App abzurufen, kann zu einer NTP-Abweichung (Network Time Protocol) führen. Stelle sicher, dass dein Kubernetes-System mit einem NTP-Server genau synchronisiert wird und keine erhebliche Zeitabweichung vorliegt. Wenn Ihre Systemzeit hinter der von GitHub liegt, gibt es mehr Spielraum. Aber wenn die Umgebung um mehr als ein paar Sekunden voraus ist, treten beim Verwenden der GitHub App 401-Fehler auf.\n\n## Grenzwerte für Runnergruppen\n\nDu kannst maximal 10.000 selbstgehostete Runner in einer Runnergruppe haben. Wenn dieses Limit erreicht ist, ist das Hinzufügen eines neuen Runners nicht möglich.\n\n## Runner-Updates\n\n> \\[!WARNING] Alle Updates, die für die Software veröffentlicht werden, einschließlich haupt-, Neben- oder Patchversionen, werden als verfügbares Update betrachtet. Wenn Sie innerhalb von 30 Tagen kein Softwareupdate durchführen, reiht der GitHub Actions-Dienst keine Aufträge in die Warteschlange Ihres Runners ein. Wenn ein kritisches Sicherheitsupdate durchgeführt werden muss, reiht der GitHub Actions-Dienst keine Aufträge in die Warteschlange deines Runners ein, bis dieser aktualisiert wurde.\n\nÜberprüfe, ob es sich bei der verwendeten Runnersoftwareversion und/oder den verwendeten benutzerdefinierten Runnerimages um die neueste Version handelt.\n\nWeitere Informationen finden Sie unter [Referenzen zu selbstgehosteten Runnern](/de/actions/reference/runners/self-hosted-runners).\n\n## Rechtliche Hinweise\n\nTeile wurden von <https://github.com/actions/actions-runner-controller/> unter der Apache-2.0-Lizenz übernommen:\n\n```text\nCopyright 2019 Moto Ishizawa\n\nLicensed under the Apache License, Version 2.0 (the \"License\");\nyou may not use this file except in compliance with the License.\nYou may obtain a copy of the License at\n\n    http://www.apache.org/licenses/LICENSE-2.0\n\nUnless required by applicable law or agreed to in writing, software\ndistributed under the License is distributed on an \"AS IS\" BASIS,\nWITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.\nSee the License for the specific language governing permissions and\nlimitations under the License.\n```"}