... | ... | @@ -7,16 +7,19 @@ Der Softwarelieferant MUSS... |
|
|
Der Softwarelieferant SOLL...
|
|
|
|
|
|
- einen Health-Check für den Start und den Betrieb („readiness“ und „liveness“), ggf. nach den Vorgaben des Plattformbetreibers, definieren. Beide Checks müssen für die Anwendung relevante Funktionen prüfen und als Ergebnis zurückliefern. [^1] (APP.4.4.A11 S: Überwachung der Container)
|
|
|
- <span dir="">Hilfestellung zu Möglichkeiten für forensische Analysen dem Softwarebetreiber anbieten.</span> (SYS.1.6.A22) [^2]
|
|
|
- Hilfestellung zu Möglichkeiten für forensische Analysen dem Softwarebetreiber anbieten. [^2] (SYS.1.6.A22)
|
|
|
- ein für seine Software erwartbares Verhalten (Systemaufrufe, Kommunikationsbeziehungen usw.) definieren, beschreiben und dem Softwarebetreiber vorlegen. [^3] (SYS.1.6.A24)
|
|
|
|
|
|
Der Softwarelieferant KANN...
|
|
|
|
|
|
- Start-up-Checks für den Start der Container implementieren. [^3] (APP.4.4.A11 S)
|
|
|
- Start-up-Checks für den Start der Container implementieren. [^4] (APP.4.4.A11 S)
|
|
|
|
|
|
**Umsetzungshinweise**
|
|
|
|
|
|
[^1]: Ausnahme: Init-Container: https://kubernetes.io/docs/concepts/workloads/pods/init-containers/
|
|
|
|
|
|
[^3]: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-startup-probes
|
|
|
|
|
|
[^2]: z.B. Log-Funktionalitäten, Konfigurationsdateien, Funktionalitäten zu Rückverfolgung von Änderungen
|
|
|
|
|
|
[^3]: Hinweis: Wenn der Softwarelieferant das normale Verhalten -wie oben angesprochen- nicht angeben kann, dann muss der Softwarebetreiber das normale Verhalten durch Erprobung feststellen.
|
|
|
|
|
|
[^4]: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-startup-probes |