Update confidential designator here

Openshift Lifecycle & CNF

Patrick Reilly Angel Orozco Lucero

Account Executive Sr Account Solution Architect

1
Version number here V00000
 Update confidential designator here

Agenda
▸ Kubernetes Overview
▸ OCP Lifecycle
▸ CNF Certification Process
▸ Value to Red Hat Customer
▸ AT&T MX CNF Roadmap
▸ Best Practices

2
Version number here V00000
 “Kubernetes” Update confidential designator here

Kubernetes (k8s) is an open-source

system for automating deployment,
operations, and scaling of
containerized applications across
multiple hosts

kubernetes
Version number here V00000
What Does Kubernetes do? Update confidential designator here

▸ Known as the linux kernel of distributed systems.

▸ Abstracts away the underlying hardware of the nodes and

provides a uniform interface for workloads to be both deployed
and consume the shared pool of resources.

▸ Works as an engine for resolving state by converging actual and

the desired state of the system.

Version number here V00000

Kubernetes architecture
6
 Update confidential designator here

4 Rules K8s Deprecation Policy

Example Track

● Full version, including minor versions. v1 GA (generally available, stable)

● GA Features, Network APIs
● API Version for the different objects v1beta1 Beta (pre-release)
● Backward compatibility, if there's CNF
upgrade v1alpha1 Alpha (experimental)

Important: The API’s lifecycle is defined by the K8S community, not by Red Hat

https://kubernetes.io/docs/reference/using-api/deprecation-policy/ Version number here V00000

 Draw Me a Picture!

Advanced Multi-cluster Management

Cluster Discovery ⠇Provisioning ⠇Policy ⠇Compliance ⠇Configuration ⠇Workloads
Management
Manage Workloads Build Cloud-Native Apps Developer Productivity

Platform Services Application Services Developer Services

OpenShift
Container Service Mesh ⠇Serverless Databases ⠇Languages Developer CLI ⠇VS Code
Platform Builds ⠇CI/CD Pipelines Runtimes ⠇Integration extensions ⠇IDE Plugins
Full Stack Logging Business Automation Code Ready Workspaces
Chargeback 100+ ISV Services CodeReady Containers

Cluster Services
Automated Ops ⠇Over-The-Air Updates ⠇Monitoring ⠇Registry ⠇Networking ⠇Router ⠇KubeVirt ⠇OLM ⠇Helm
OpenShift
Kubernetes
Engine Kubernetes

Red Hat Enterprise Linux & RHEL CoreOS

8
Physical Virtual Private cloud Public cloud Managed cloud
(Azure, AWS, IBM, Red Hat)
 It’s assembled, it has premium support and a warranty!
Update confidential designator here

9
Version number here V00000
What's Next in OpenShift
OCP Lifecycle
Red Hat OpenShift lifecycle

24 month Red Hat

3 months 3 months 3 months 3 months

OpenShift lifecycle
K8S lifecycle
1 year
24 months - EUS Lifecycle

18 months - Non-EUS lifecycle

OCT-
4 months 2026

8 months FS 10 months MS 6 months EUS

Red Hat OpenShift 4.14

onboarding
Live Production
& roll-out
upgrade

4.15
8 months FS 10 months MS 6 months EUS

Red Hat OpenShift 4.16

Red Hat OpenShift 4.17

8 months FS 10 months MS 6 months EUS

Red Hat OpenShift 4.18

Red Hat OpenShift 4.19

8 months FS 10 months MS 6 months EUS

Red Hat OpenShift 4.20

4.21
8 months FS 10 months MS 6 months EUS

Red Hat OpenShift 4.22

11
4.23

https://access.redhat.com/support/policy/updates/openshift Red Hat Confidential - Internal Only

 Update confidential designator here
CNF Certification and Vendor Validation

Red Hat CNF Catalog

Certified cloud-native network functions for OpenShift

Version number here V00000

 Expectations from Telco Partners
Update confidential designator here

CNF’s should:

● CNFs are cloud-native

● Containers never run as root
● Run with minimal permissions (see next section on SCCs)
● Use the CNI for all traffic (Multus/SRIOV/MacVLAN are corner cases for high throughput)
● CNFs should leverage service mesh provided by platform
● All images/helm charts must be neatly packaged by the Vendor, and Telco partner should be able
to host on internal, disconnected registries/repos
● Security policies will be driven by Telco consumers (may vary per Telco)
● Adhere to Naming and Labeling Standards per Telco customer
● N+K redundancy
● Clearly defined pod affinity/anti-affinity rules
● Meet IPv6 requirements (when applicable)
● Instantiation via Helm/Operators must result in fully-functioning CNF, no post-install
configuration required
● Service level redundancy, cannot rely on individual worker/compute node availability/stability
● Support elasticity with dynamic scaling (up/down) via k8s constructs (such as replicasets)
● Self Recovery from common failures (pod/host/network)
● K8s native mechanisms for failure detections (Liveness checks, Readiness Checks, Startup
Probes)

Version number here V00000

13
 Update confidential designator here

Expectations from Telco Partners

CNF’s should NOT

● CNFs may not deploy NodePorts

○ A NodePort is an open port on every node of your cluster
● CNFs may not use host networking
● Namespace creation will be performed by the Telco platform team and should not be
created by the CNFs deployment method (Helm / Operator)
● CNFs may not perform Role creation
○ The Role should already exists and pass validations
● CNFs may not perform Rolebinding creation
○ role binding grants the permissions defined in a role to a user or set of users.
● CNFs may not have Cluster Roles
○ ClusterRole contains rules that represent a set of permissions
● CNFs are not authorized to bring their own CNI (in some environments)
● CNFs may not deploy Daemonsets (in some environments)
○ A DaemonSet ensures that all (or some) Nodes run a copy of a Pod. As nodes are
added to the cluster, Pods are added to them.
● CNFs may not modify the platform in any way

Version number here V00000

14
 CNF Certification and Vendor Validation CONFIDENTIAL designator

Red Hat OpenShift CNF Certification

Assurance that a CNF managed by a Kubernetes Operator or Helm Chart

interoperates with the Red Hat OpenShift container platform throughout
its lifecycle, and is commercially supported by Red Hat and partners

CNF Validation Red Hat Verification Collaborative Support Lifecycle Commitment

15
Partner tests and validates Red Hat verifies that CNF Red Hat and partner Continuous Certification to
functionality on Red Hat integrates with OpenShift collaboration to troubleshoot ensure interoperability across
OpenShift Container Platform through an Operator, follows and resolve customer issues releases
in a customer environment or best practices
in-house lab

15 CNF Certification requires a Red Hat OS as the base OS for the CNF
 CNF Certification and Vendor Validation CONFIDENTIAL designator

CNF Program Levels

Container and
CNF Vendor Operator / CNF
Validation Helm Chart Certification
(Self certification) Certification (Full testing scripts from Red
Hat, Red Hat OS required)
(Red Hat OS required)

Zero Cost for Red Hat Partners

16
 CONFIDENTIAL designator

CNF certification to reduce operational risk

Red Hats program to certify vendor network functions and provide joint ongoing support

Red Hat CNF Certified

Labs

Container/Operator/Helm
Support Charts Certified

Lifecycle CNF Vendor

Validated

Certification 140+ Certified/Validated CNF's 500+ Certified/validated non

from dozens of vendors CNF workloads
 CNF Certification and Vendor Validation Update confidential designator here

What are we testing?

CNF Certification Test Suite version 5.0.2 - Test Coverage and Breakdown
Observabilit Platform Affiliated
Informational Access Control Lifecycle Networking Operator
y Alteration Certification

This test suite checks This suite checks This suite verifies
This test suite This test suite This suite tests checks This suite verifies key
Pod deployment, connectivity and This suite tests Containers,
gathers cluster & checks for security and access platform configs have
Descriptio creation, shutdown, network config basic Operator Operators/Helm
node information container control related best not been modified by
n from OpenShift observability practices the CNF under test
scalability and high related best functionalities Charts under test
availability etc. practices are RH Certified

Proper namespace Base is Red Hat (UBI)

Valid service account Creation, Scheduling,
Image not altered Dual stack check
No root, no escalation Scaling, Shutdown, Grace
No undeclared taints ICMP v4 v6 Ping Checks Container
SCC UID & capabilities Period, Liveness,
Extracts Node info CRD status check No automount token Node sysctl config Multus, SR-IOV Install via OLM Certification, digest
Readiness, startup probes
Extracts cluster ver stdout/stderr logs No host Boot param & No NodePort
CPU isolation, PV reclaim
Test Cases Extracts CSI driver Disruption budget resource/path HugePage via
ReplicaSet/StatefulSet
No listen on Privilege, Checks
Lists CNI plugins Termination policy No role-bindings MachineConfig undeclared ports status, Operator/Helm
No SSH daemons PodAntiAffinity for HA
Lists Node HW info Proper image tag SELinux check No iptable/nftable permissions Chart Certification
Toleration/quota/limit Affinity for co-location
OCP version current No reserved ports
1 Process/Container No NodeSelector/Affinity
OCP ver compatibility Deny all based
sys_nice, sys_ptrace Image Pull Policy
Service mesh check

18
Version number here V00000
 Update confidential designator here

Things we are NOT testing

● Container functionality as specified by vendor
○ We are not a replacement for your specific CNF testing
○ We are not a substitute for integration testing

● Any performance characteristics of the CNF (i.e. we don’t test throughput, scalability, etc..)
○ Any threshold we set would be non-relative to you and your specific deployment
○ Any performance test we do might indicative only- and not a pass/fail

● No custom hardware (for example RAN requirement- radios, Faraday cages, etc…)
○ Also requires specific skilled people- which this lab is not set up for.
○ Our Intel/Red Hat lab is complementary to other in depth engineering with certain partners (i.e RAN)

● This is our test suite- to test with OpenShift- we are the authority on it- we are not driven by the
community- we “listen” to the community, but our tests are specific to OpenShift
○ Working with partners- we take their feedback on enhancing the tests- along with feedback from the
community.

19
Version number here V00000
 CNF Certification and Vendor Validation Update confidential designator here

Value to Red Hat Customer

Vendor Validated Container/Operator Certified Red Hat CNF Certified

CNF functionality: CNF verified and fully supported by the partner

Yes Yes Yes
on OpenShift 4.x

Engineered with Red Hat: Container operating system base image

No Yes Yes
(RHEL/UBI)** is maintained and supported by Red Hat

Integrated Lifecycle Management: CNF is deployed and maintained

No Yes Yes
by a Red Hat Certified Operator

Ongoing vulnerability protection: Continuous scanning to identify

No Yes Yes
and fix CVEs in Red Hat's components of the CNF

Collaborative support: Partner and Red Hat establish direct

TSANet Recommended Yes Yes
workflow between support teams

Engineering relationship: Through Red Hat Partner Connect Case-by-case Yes Yes

Ongoing testing on supported OpenShift versions Required Required Required

CNF-specific tests (NF) No No Yes

20
Version number here V00000
 CNF Certification and Vendor Validation Update confidential designator here

What is Required From a Partner? (1/2)

Vendor Validated Container/Operator Certified Red Hat CNF Certified

Deploy OpenShift 4 on-prem and verify CNF functionality Yes Yes Yes

Commitment to support OpenShift 4 across its lifecycle, with a

Yes Yes Yes
process to deploy and test OpenShift updates

Vendor will participate in TSANet or have a formal support

Yes Yes Yes
arrangement established with Red Hat

Container images used by the CNF must be built using RHEL/UBI No Yes Yes

Container images must go through Red Hat Container Certification

No Yes Yes
for ongoing security and supportability scans

CNF must include a Kubernetes Operator to deploy the application Yes (Operator Maturity
No Yes
and manage updates Level II or higher)

Operator must complete the Red Hat certification tests to verify

No Yes Yes
metadata and OLM interoperability

21
Version number here V00000
 CNF Certification and Vendor Validation Update confidential designator here

What is Required From a Partner? (2/2)

Vendor Validated Container/Operator Certified Red Hat CNF Certified

CNF must handle OpenShift upgrades and node failures No No Yes

CNF must support a CNI plugin included with OpenShift by default No No Yes

OpenShift environment for CNF must complete platform validation

No No Yes
tests (SR-IOV, DPDK, PTP, etc)

CNF must complete Network Function tests (Alive, Packet Size,

No No Yes
‘BERT’ tests)

22
Version number here V00000
 CNF Certification and Vendor Validation Update confidential designator here

Workflow Overview
Red Hat Partner
Certification Validated

Deploy OpenShift 4 and verify CNF functionality ✔

Vendor

Contact your Red Hat Partner Manager to complete questionnaire and schedule an interview ✔ ✔
CNF listed in Red Hat CNF Vendor Validated Catalog ✔
Build containers and Operator to meet requirements ✔
Operator

Deploy OpenShift 4 and verify CNF functionality ✔

Follow the container and Operator certification steps ✔
Operator listed in Red Hat Operator Catalog ✔
Build containers and Operator to meet requirements ✔
CNF Certification

Deploy OpenShift 4 and verify CNF functionality ✔

Follow the container and Operator certification steps ✔
Ensure CNF certification rules are followed ✔
Contact your Red Hat Partner Manager to schedule an interview and lab certification tests ✔ ✔
CNF listed in Red Hat CNF Certified Catalog ✔
23
Version number here V00000
 Update confidential designator here

AT&T Mx CNF Roadmap

Vendor CNF Version Desired Status Contact Mail Phone
Deployment (Current/New/
Modernization/
Date Substitution)

24
Version number here V00000
 Update confidential designator here

Best Practices

● ACM/ACS/QUAY/Ansible -> ZTP

● Hosted Control Plane-> (Testing/Preprod LAB)
● TAM

25
Version number here V00000
 RHACM Architecture

26
Continuous security for cloud-native applications

Architecture
RED HAT QUAY OVERVIEW

Red Hat Quay Architecture

UI
Container Security Quay Bridge
Content Ingress API Other Clients Operator Operator
CLI

CVE Metadata

quay.io
Load Balancer

Quay Container Clair Container Mirroring Worker Quay Builders

operatorhub.io

Quay Operator

Red Hat
Container Catalog PostgreSQL Databases
Object Storage Redis Cache Quay Backend Services
(Quay + Clair)

Standalone Container Host(s) Runtime or Orchestration

Suppliers

Community
Any Infrastructure
Laptop Datacenter OpenStack Amazon Web Services Microsoft Azure Google Cloud
Custom

Content
 Management Cluster
ZTP Overview
Advanced Cluster
Management
Assisted*
Hive*
Installer
Design Git Repository
Red Hat
OpenShift GitOps
/blueprint/*
Git
Repository
/cluster/*
Red Hat
Quay

Spoke Cluster Bare Metal OpenShift

Host Container Storage
Red Hat
Deployed Platforms OpenShift Pipelines
M W

S W

CORE

CU

S W

S W
W W W

DU DU DU DU DU Pool
29
 Update confidential designator here

Hub Cluster Service Provider End Users

HCP 1 (Namespace/Project) AWS VM Workers (Agent)

TP

API Auth
ETCD OLM
Server Server
Advance Cluster Manager

HCP 2 (Namespace/Project) Bare Metal Workers (Agent)

GA
Multi-Cluster Engine API
ETCD
Auth
OLM
(MCE) Server Server

HyperShift Operator
HCP N (Namespace/Project) VM Workers GA

API Auth
ETCD OLM
Server Server

Hub Cluster Master Hub Cluster Infrastructure Hub Cluster Worker

Nodes Nodes Nodes

30
Version number here V00000
 ¿De qué maneras puede ayudar mi TAM?

Principal punto de
Touchpoint Semanal
contacto técnico

Apoyo en la adopción de Análisis proactivo de los

productos distintos ambientes

Transferencia de Orientación y mejores

conocimientos prácticas

Asesor y representante Monitorea y ayuda a escalar

del cliente casos de Soporte

Los TAMs actúan en horario comercial de Lunes a Viernes

 Update confidential designator here

Thank you linkedin.com/company/red-hat

youtube.com/user/RedHatVideos

Red Hat is the world’s leading provider of enterprise

facebook.com/redhatinc
open source software solutions. Award-winning
support, training, and consulting services make
Red Hat a trusted adviser to the Fortune 500. twitter.com/RedHat

32
Version number here V00000