In this section:


Modified: for 12.1.3

Overview

The SBC CNe is enhanced with the termination message policy. It provides a way for containers to write information about terminal events to a location. When a container fails, you can quickly diagnose the issue using kubectl to receive a concise overview of the pod’s state, including its termination message. However, if the pod logs are enormous and a container does not write a specific termination message, it can become time-consuming. You can configure the terminationMessagePolicy in the YAML file to receive the application failure logs faster and more simply.

Functionality

The Kubernetes retrieves termination messages from the termination message file. You can set the terminationMessagePolicy field of a container for further customization. When you set this field to FallbackToLogsOnError, the SBC directs the Kubernetes to use the last chunk of the container log output if the termination message file is empty and the container is exited with an error. 

ParameterDescriptionM/O
terminationMessagePolicy

The policy for the container termination message. Valid value:

  • FallbackToLogsOnError – The last part of the container log output is used as the termination message if the container exits due to exceptions and the termination message file is empty.

M



Termination Message Policy Configurations

The following table represents the termination message policy configurations for the SBC CNe:

Container TypeContainer NameConfiguration
SBC Containers
  • OAM
  • SC
  • CS
  • RS
  • SG
  • SLB
  • Termination Message Policy: Determines how the SBC needs to populate the termination message in the log file upon a success or failure.
  • FallbackToLogsOnError: Uses the last chunk of container log output if the specified termination message file (/var/log/sonus/terminationReason.log) is empty and the container exited with an error (non-zero exit code).
  • Log Path: In the event of application failure or termination, the SBC writes the termination logs to /var/log/sonus/terminationReason.log.
Other Containers
  • HPA
  • RAC
  • Network-Service
  • Strongswan-Container
  • OAMProxy-Container
  • RBBN-Cache-Proxy
  • PVClogger-Container
  • RBBN-Telemetry-Agent
  • Default Log Path: /dev/termination-log.
  • Logging Behavior: In the event of failure or termination in these containers, if they exit with a non-zero code, the SBC logs the reason within their respective container logs. Use the oc describe pod command to view the logs.
    Note: If the container exit is 0 for non-confd containers, the SBC does not print the termination reason for the oc describe pod command. For more information, refer to https://kubernetes.io/docs/tasks/debug/debug-application/determine-reason-pod-failure/.



Known Limitations

The following limitations exist in this release:

  • You can set the termination message only when the container knows the reason.
  • When Kubernetes restarts a container or a pod, the SBC does not control it, and the termination message can become inaccurate.
  • The new setting can fall back to the container log to catch the cases that are not in the control of the container.
  • The total message length across all containers is limited to 12 KiB, divided equally among each container. For example, if there are 12 containers (initContainers or containers), each holds 1024 bytes of available termination message space.
  • When the Kubernetes kills the pod or container, the reason is not identified. To learn more about the Kubernetes pod disruption conditions, refer to https://kubernetes.io/docs/concepts/workloads/pods/disruptions/#pod-disruption-conditions.
  • The following limitations exists for the Termination Message Policy value:
    Termination Message Policy ValueLimitations
    FallbackToLogsOnError
    • If the termination message file is empty and the container exited with an error, it uses the last chunk of the container log output.
    • Log output is limited to 2048 bytes or 80 lines, whichever is smaller.