DO244 – Developing Applications with Red Hat OpenShift Serverless and Knative — Lesson 3: Knative Eventing, Sources, Brokers, Triggers, Channels, and Event Flow

Learning Objectives

• Explain the structures, services, data, settings, roles, and dependencies governing event sources and brokers.
• Implement and validate triggers, channels, and CloudEvents using reviewable evidence.
• Evaluate the condition where operators cannot explain the outcome because logs, commands, settings, and acceptance evidence were not captured consistently and select a proportionate corrective response.

Detailed Topics

• event sources applied to the course scenario, expected platform behavior, dependencies, controls, and evidence.
• brokers applied to the course scenario, expected platform behavior, dependencies, controls, and evidence.
• triggers applied to the course scenario, expected platform behavior, dependencies, controls, and evidence.
• channels applied to the course scenario, expected platform behavior, dependencies, controls, and evidence.
• CloudEvents applied to the course scenario, expected platform behavior, dependencies, controls, and evidence.

Instructor Demonstration

The instructor traces a cloud-native team implementing event-driven services that scale to demand on OpenShift. The walkthrough connects navigation, commands, configuration logic, system messages, and evidence captured in the Knative service and eventing manifests, routing tests, observability evidence, and serverless delivery guide. It also tests the exception where operators cannot explain the outcome because logs, commands, settings, and acceptance evidence were not captured consistently.

Hands-On Exercise

Complete a controlled Red Hat exercise covering Knative Eventing, Sources, Brokers, Triggers, Channels, and Event Flow and preserve the verified result in the Knative service and eventing manifests, routing tests, observability evidence, and serverless delivery guide.

1. Confirm scope, prerequisites, versions, identities, dependencies, and acceptance criteria.
2. Execute the workflow while recording commands, settings, outputs, events, and system messages.
3. Test normal behavior, one boundary condition, and the stated exception.
4. Document corrections, evidence, ownership, retest criteria, rollback, and handover actions.

Scenario Analysis

• Identify which object, service, policy, setting, or sequence most strongly influences event sources.
• Compare two defensible responses and explain technical, security, operational, and support trade-offs.
• Determine how the Knative service and eventing manifests, routing tests, observability evidence, and serverless delivery guide should be approved, retained, retested, and updated.

Troubleshooting Guidance

Start where expected behavior first differs from the observed result. Check prerequisites, identity, configuration order, version compatibility, connectivity, status, resource limits, and evidence separately. Treat “operators cannot explain the outcome because logs, commands, settings, and acceptance evidence were not captured consistently” as a hypothesis until commands, logs, settings, and retest outcomes confirm the cause.

Validation Checklist

• Required platform components, identities, permissions, settings, and dependencies are present.
• The Knative service and eventing manifests, routing tests, observability evidence, and serverless delivery guide connects each conclusion to objective, reviewable evidence.
• Normal processing, a boundary condition, dependency behavior, and the stated exception were tested.
• Corrections, ownership, retest criteria, rollback, documentation, and operational handover are complete.

Lesson Outcome

Learners can apply Knative Eventing, Sources, Brokers, Triggers, Channels, and Event Flow, explain the resulting platform behavior, and defend the outcome through the Knative service and eventing manifests, routing tests, observability evidence, and serverless delivery guide.