Wissensprüfung - Produktivbetrieb
Eine Entwicklerin oder ein Entwickler deployt TaskBoard in Managed Kubernetes und öffnet anschließend den Grafana-Dashboard des Logging Service, in der Erwartung, die Pod- und Control-Plane-Logs des Clusters zu sehen. Die Ansicht ist leer. Was ist die korrekte Lösung?
Kubernetes Control-Plane-Ereignisse werden NICHT automatisch über den IONOS CLOUD Logging Service weitergeleitet; die Plattform sendet Cluster-Logs nicht automatisch. Sie müssen diese selbst mit einem Fluent Bit DaemonSet oder durch Aktivierung von Central Logging weiterleiten. Retentionswerte und die Beschränkung auf JSON gelten für die HTTP-Quelle, nicht für den Kubernetes-Weiterleitungsweg, und es gibt kein loggingEnabled-Flag bei der Erstellung, das dieses Problem löst.
Eine Entwicklerin erstellt eine Monitoring Service-Pipeline, sieht eine erfolgreiche 201-Antwort und schließt dann das Terminal, ohne den Antwortinhalt zu lesen. Am nächsten Tag liefert ihr Metrik-Agent bei jedem Push an /api/v1/push den Wert 401 zurück, und sie findet keine Möglichkeit, den Ingest-Schlüssel abzurufen. Was ist passiert?
Der Monitoring Service gibt den Ingest-Schlüssel pro Pipeline nur einmal zurück, bei der Erstellung in metadata.key, und aus Sicherheitsgründen nie wieder. Wenn der Antwortinhalt nicht erfasst wird, kann der Schlüssel nicht wiederhergestellt werden, und es muss eine neue Pipeline bereitgestellt oder der Schlüssel rotiert werden. Prometheus, Grafana Agent und OpenTelemetry authentifizieren sich alle über den APIKEY-Header, daher ist das Header-Format korrekt; es gibt keine tägliche TTL für den Schlüssel.
Eine Entwicklerin oder ein Entwickler debuggt einen Verbindungsfehler zwischen den Ebenen von TaskBoard. Die Anwendungsprotokolle sind leer, daher muss auf der Netzwerkebene bestätigt werden, ob der Datenverkehr blockiert wird. Sie oder er fügt ein Flow Log auf der NIC hinzu, merkt dann aber, dass die falsche Erfassungsrichtung festgelegt wurde. Wie ist die korrekte Vorgehensweise, um dies zu ändern?
Die Flow-Log-Konfiguration ist nach der Erstellung unveränderlich, und es gibt pro Ressource nur ein Flow Log. Um eine beliebige Einstellung, einschließlich der Erfassungsrichtung, zu ändern, löschen Sie das vorhandene Flow Log und erstellen Sie ein neues. Es gibt keinen Pfad für eine Aktualisierung an Ort und Stelle über PATCH oder Terraform, und Sie können kein zweites Flow Log an derselben Ressource anhängen.
Eine Entwicklerin benötigt, dass die TaskBoard-CI-Pipeline sich bei der IONOS CLOUD API authentifiziert, und möchte, dass ein Leck dieser Zugangsdaten schnell eingedämmt und wiederhergestellt werden kann. Welcher Token-Ansatz ist korrekt?
Das sichere Muster besteht aus einem Token pro Dienst und pro Umgebung (bis zu 100 pro Benutzer) mit der kürzest tragbaren TTL aus dem festen Satz, rotiert durch generate-then-revoke, sodass nie eine Lücke entsteht. Ein gemeinsamer, für den gesamten Vertrag geltender Token bedeutet, dass ein einzelnes Leck alles außer Betrieb setzt, Basic Authentication wird eingestellt und sollte nicht in der Automatisierung verwendet werden, und der Tokenwert wird genau einmal angezeigt, ohne einen erneuten Lese-Endpunkt.
Eine Entwicklerin stellt TaskBoard auf MKS mit einem Service von type: LoadBalancer bereit. In der Produktion wird beobachtet, dass der gesamte Traffic auf einem einzigen Worker-Knoten landet, die Quell-IP-Adresse des Clients verloren geht und die Durchsatzrate bei etwa 2 Gbit/s stagniert. Welche Aussage erklärt dies korrekt und beschreibt die Lösung für die Produktion?
Auf MKS weist ein type: LoadBalancer Service eine reservierte öffentliche IP als sekundäre IP einem einzelnen Ingress-Knoten zu, und kube-proxy führt NAT zu dem Pod durch, wodurch die Quell-IP verloren geht (korrigiert mit externalTrafficPolicy: Local) und der Durchsatz an der 2-Gbit/s-Obergrenze dieses Knotens begrenzt ist. Produktionstrafic sollte über einen separat bereitgestellten Managed ALB aus der Terraform-Ebene laufen. NSGs sind nicht an verwaltete Load Balancer oder MKS-Knoten gebunden, und eine PodDisruptionBudget schützt die Verfügbarkeit während Wiederaufbauten, anstatt die Routing-Logik zu beeinflussen.