Wissensprüfung - Produktionsoperationen
Ein Entwickler deployt TaskBoard auf Managed Kubernetes und öffnet dann die Logging Service-Grafana, um die Pods und die Control-Plane-Logs des Cluster zu sehen. Die Ansicht ist jedoch leer. Was ist die korrekte Lösung?
Die Control-Plane-Ereignisse des Kubernetes fließen nicht automatisch durch die IONOS-Logging Service; die Plattform liefert keine Cluster-Logs für Sie. Sie müssen sie selbst mit einem Fluent Bit-DaemonSet oder durch Aktivieren des zentralen Loggings weiterleiten. Die Aufbewahrungszeitraumswerte und die JSON-only-Einschränkung gelten für die HTTP-Quelle, nicht für den Kubernetes-Weiterleitungspfad, und es gibt keine Erstellungszeit-loggingEnabled-Flag, das dieses Problem löst.
Ein Entwickler erstellt eine Monitoring Service-Pipeline, sieht eine erfolgreiche 201-Antwort, dann schließt er das Terminal ohne den Textkörper zu lesen. Am nächsten Tag gibt sein Metrics-Agent 401 bei jedem Push zu /api/v1/push aus und er kann keine Möglichkeit finden, den Ingest-Schlüssel zu erhalten. Was ist passiert?
Die Monitoring Service gibt den pro-Pipeline-Ingest-Schlüssel nur einmal in metadata.key bei der Erstellung zurück und nie wieder aus Sicherheitsgründen. Wenn der Textkörper der Antwort nicht erfasst wird, kann der Schlüssel nicht wiederhergestellt werden und Sie müssen eine neue Pipeline bereitstellen oder den Schlüssel rotieren. Prometheus, Grafana Agent und OpenTelemetry authentifizieren sich alle mit dem APIKEY-Header, sodass das Header-Format korrekt ist; es gibt keine tägliche Schlüssel-TTL.
Ein Entwickler debuggt einen Konnektivitätsfehler zwischen TaskBoard-Ebenen. Die Anwendungsprotokolle sind still, daher müssen sie auf der Netzwerkebene bestätigen, ob der Datenverkehr blockiert wird. Sie fügen ein Flow-Log auf der Netzwerk-Schnittstelle hinzu, dann realisieren sie, dass sie die falsche Erfassungsrichtung eingestellt haben. Wie ist die korrekte Methode, um dies zu ändern?
Die Flow-Log-Konfiguration ist nach der Erstellung unveränderlich, und es gibt ein Flow-Log pro Ressource. Um eine Einstellung zu ändern, einschließlich der Erfassungsrichtung, löscht man das bestehende Flow-Log und erstellt ein neues; es gibt keinen Aktualisierungspfad vor Ort über PATCH oder Terraform, und man kann kein zweites Flow-Log an die gleiche Ressource anhängen.
Ein Entwickler benötigt die TaskBoard-CI-Pipeline, um sich beim IONOS API zu authentifizieren, und möchte, dass ein Leck dieser Anmeldeinformationen schnell eingeschränkt und wiederhergestellt werden kann. Welcher Token-Ansatz ist korrekt?
Das sichere Muster ist ein Token pro Dienst pro Umgebung (bis zu 100 pro Benutzer) mit der kürzesten tolerablen Gültigkeitsdauer aus dem festen Satz, rotiert durch Generieren und Widerrufen, so dass nie eine Lücke entsteht. Ein gemeinsam genutzter vertragsweiter Token bedeutet, dass ein einzelnes Leck alles lahmlegt, die Basic-Authentifizierung eingestellt wird und in der Automatisierung nicht verwendet werden sollte, und der Token-Wert wird genau einmal angezeigt, ohne dass es einen Endpunkt zum erneuten Lesen gibt.
Ein Entwickler veröffentlicht TaskBoard auf MKS mit einem Service von type: LoadBalancer. In der Produktion beobachten sie, dass alle Datenverkehr auf einem Worker Node landen, die Client-Quelle IP verloren geht und die Durchsatzrate bei etwa 2 Gbit/s stagniert. Welche Aussage erklärt dies und die Produktionskorrektur richtig?
Bei MKS weist ein type: LoadBalancer-Service eine reservierte öffentliche IP als sekundäre IP einem einzelnen Eingabe-Node zu und kube-proxy NATs zum Pod, sodass die Quelle IP verloren geht (mit externalTrafficPolicy: Local korrigiert) und die Durchsatzrate bei der 2-Gbit/s-Obergrenze dieses Node gedeckelt ist. Der Produktionsdatenverkehr sollte durch einen separat bereitgestellten Managed ALB von der Terraform-Ebene gehen. NSGs binden nicht an gemanagte Load Balancer oder MKS-Knoten, und ein PodDisruptionBudget schützt die Verfügbarkeit während des Umbaus, anstatt die Routing zu beeinflussen.