Observability

Workload Observability

Configure workloads for operational visibility by following logging, naming, tagging, and API compatibility best practices.

Container Logging

Containers must log to stdout and stderr. Do not redirect logs to files inside the container — platform log collection (Fluentd, Vector, Loki) relies on capturing stdout/stderr streams.

Required for: Telco (mandatory), Far-Edge (mandatory), Extended (mandatory), Non-Telco (optional)

yamlCopy code
containers:
  - name: app
    image: registry.example.com/app:v1.2.3
    command: ["/app"]

Avoid patterns like redirecting output to a log file:

Copy code
/app > /var/log/app.log 2>&1  # Don't do this

CRD Status Sub-Resource

All Custom Resource Definitions must include a status sub-resource specification. The status sub-resource enables the platform to track the state of custom resources and allows controllers to report status separately from spec updates.

Required for: Telco (mandatory), Far-Edge (mandatory), Extended (mandatory), Non-Telco (optional)

yamlCopy code
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: myresources.app.example.com
spec:
  group: app.example.com
  names:
    kind: MyResource
    plural: myresources
  scope: Namespaced
  versions:
    - name: v1
      served: true
      storage: true
      subresources:
        status: {}
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
            status:
              type: object

Port Naming Conventions

Container port names must follow the format <protocol>[-<suffix>]. This convention enables service mesh integration and platform-level traffic management.

Required for: Extended (mandatory), all others (optional)

yamlCopy code
containers:
  - name: app
    ports:
      - containerPort: 8080
        name: http-api
      - containerPort: 9090
        name: http-metrics
      - containerPort: 50051
        name: grpc-data

Image Tagging

All container images must have explicit tags. Do not rely on the implicit latest tag — it makes deployments non-reproducible and prevents rollback.

Required for: Extended (mandatory), all others (optional)

yamlCopy code
containers:
  - name: app
    image: registry.example.com/app:v1.2.3   # Good: explicit tag
    # image: registry.example.com/app         # Bad: implicit latest
    # image: registry.example.com/app:latest  # Bad: explicit latest

API Compatibility

Workload APIs must be compatible with the next OpenShift version. Before upgrading, verify that no deprecated or removed APIs are in use by the workload's CRDs, webhooks, or API calls.

Required for: Telco (mandatory), Far-Edge (mandatory), Extended (mandatory), Non-Telco (optional)

Use oc api-resources and the Kubernetes API deprecation guide to check for deprecated APIs before platform upgrades.

Implementation Checklist

• All containers log to stdout/stderr (no log file redirection)
• All CRDs have status sub-resource defined
• Container port names follow <protocol>[-<suffix>] format
• All container images have explicit tags (not latest)
• Workload APIs are compatible with the next OpenShift version

Certsuite Test Mapping

References

• Kubernetes Logging Architecture
• Custom Resource Definitions
• Kubernetes API Deprecation Guide
• Red Hat Best Practices for Kubernetes Guide
• Red Hat Best Practices Test Suite for Kubernetes (certsuite)