OpenShift EUS releases (4.14, 4.16, 4.18, etc.) have 36-month support lifecycles, but CRI-O only provides ~12 months per version. This creates a 24-month gap where EUS customers can't receive security updates without platform upgrades. This document proposes strategies to align CRI-O with OpenShift EUS while reducing maintenance burden.
OpenShift Lifecycle:
- Standard: 18 months total
- EUS (even releases): 18mo base + 6mo (Term 1) + 12mo (Term 2) = 36 months
Kubernetes & CRI-O Lifecycle:
- 3 recent versions supported
- ~12 months per version
- No extended support
Year/Month 2023 2024 2025 2026 2027 2028
N D J F M A M J J A S O N D J F M A M J J A S O N D J F M A M J J A S O N D J F M A M J J A S O N D
├─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┼─┤
K8s 1.27 ●═══════════════════════════●
CRI-O 1.27 ●═══════════════════════════●
K8s 1.28 ●═══════════════════════════●
CRI-O 1.28 ●═══════════════════════════●
K8s 1.29 ●═══════════════════════════●
CRI-O 1.29 ●═══════════════════════════●
K8s 1.30 ●═══════════════════════════●
CRI-O 1.30 ●═══════════════════════════●
K8s 1.31 ●═══════════════════════════●
CRI-O 1.31 ●═══════════════════════════●
K8s 1.32 ●═══════════════════════════●
CRI-O 1.32 ●═══════════════════════════●
K8s 1.33 ●═══════════════════════════●
CRI-O 1.33 ●═══════════════════════════●
K8s 1.34 ●═══════════════════════════●
CRI-O 1.34 ●═══════════════════════════●
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────
OpenShift Releases:
OCP 4.14 ●═══════════════════════════════════════════════════════════════════════════● (EUS, K8s 1.27)
(EUS) └── Standard EOL (18mo) └── +Term 1 (24mo) └── +Term 2 (36mo)
Oct 2023 Apr 2025 Oct 2026
OCP 4.15 ●═══════════════════════════● (Standard, K8s 1.28)
(Std) Feb 2024 Aug 2025
OCP 4.16 ●═══════════════════════════════════════════════════════════════════════════════● (EUS, K8s 1.29)
(EUS) Jun 2024 Jun 2027
OCP 4.17 ●═══════════════════════════● (Standard, K8s 1.30)
(Std) Oct 2024 Apr 2026
OCP 4.18 ●═══════════════════════════════════════════════════════════════════════════════● (EUS, K8s 1.31)
(EUS) Feb 2025 Feb 2028
OCP 4.19 ●═══════════════════════════● (Standard, K8s 1.32)
(Std) Jun 2025 Dec 2026
OCP 4.20 ●═══════════════════════════════════════════════════════════════════════════════● (EUS, K8s 1.33)
(EUS) Oct 2025 Oct 2028
OCP 4.21 ●═══════════════════════════● (Standard, K8s 1.34)
(Std) Feb 2026 Aug 2027
Legend: ● = GA/Release, ═ = Support period
OCP 4.14 (EUS): Nov 2023 ═════════════════════════════════════════════> Nov 2026 (36mo)
CRI-O 1.27 (n+0): ═════════════> Jun 2024 [GAP: 28mo]
CRI-O 1.30 (n+3): ════════════════════════> Jun 2025 [GAP: 16mo] ← Within CRI skew policy
CRI-O 1.34 (n+7): ════════════════════════════════════════════════> Oct 2026 [GAP: ~1mo]
| OCP | Type | Ships | Native EOL | OCP EOL | Gap | Coverage Via |
|---|---|---|---|---|---|---|
| 4.14 | EUS | 1.27 | Jun 2024 | Oct 2026 | 28mo | 1.30 (+16mo) or 1.34 (+1mo) |
| 4.16 | EUS | 1.29 | Feb 2025 | Jun 2027 | 28mo | 1.32 (+16mo) or 1.36 (+1mo) |
| 4.18 | EUS | 1.31 | Oct 2025 | Feb 2028 | 28mo | 1.34 (+16mo) or 1.38 (+1mo) |
| 4.15/17/19/21 | Std | - | - | +18mo | 10mo | Auto-covered by n+3 |
Key Facts:
- CRI API v1 stable since K8s 1.23+
- Kubelet works with CRI API n±3 versions (guaranteed)
- Newer CRI-O with older K8s: features gracefully degrade
- Beyond n+3: requires testing but CRI stability suggests viability
Strategy: Maintain separate CRI-O branches for each OpenShift release
Maintenance: 6→10 active branches (2024→2026)
Pros: Conservative, within CRI skew, clear support matrix Cons: High burden (10 backports per CVE), customers stuck on old versions Effort: Very High
Strategy: Allow CRI-O upgrades within n±3, extend only n+3 versions for EUS
Coverage:
- Standard releases: Use n+3 CRI-O (auto-covered, zero extra work)
- EUS releases: Extend n+3 version by +16mo (e.g., OCP 4.14 → extend CRI-O 1.30)
Maintenance: 3-4 extended branches (vs 10 in Option 1)
Pros: 50% less work, within CRI skew, customers get security fixes via CRI-O upgrades Cons: Requires testing forward compat, complex support matrix Effort: Medium
Strategy: Support CRI-O n+7, maintain only 3 latest versions
Coverage: Customers upgrade through CRI-O versions (1.27→1.28→...→1.34 over 36mo)
Maintenance: Always 3 branches (upstream only), extend latest by +1-2mo
Pros: Minimal burden, customers get latest features, aligns with K8s model Cons: Beyond n±3 guarantees, extensive testing needed, dependency/config risks Effort: Low maintenance, high initial testing
Phase 1: Implement Option 2 (Hybrid)
- Test & document CRI-O n+3 forward compatibility
- Extend CRI-O 1.30, 1.32, 1.34, 1.36 by +16mo each
- Reduce branches from 10 to 5
Phase 2: Evaluate Option 3 (Aggressive)
- Test n+7 compatibility based on Phase 1 experience
- Analyze dependency/config compatibility
- Decision: Move to Option 3 if safe, else stay with Option 2
| OCP | K8s | Test CRI-O n+3 | Priority |
|---|---|---|---|
| 4.14 | 1.27 | 1.30 | High (EUS) |
| 4.16 | 1.29 | 1.32 | High (EUS) |
| 4.18 | 1.31 | 1.34 | High (EUS) |
Test: Container/pod lifecycle, images, CRI API v1, resources, security contexts, volumes, CNI, logging, metrics
Naming: release-1.30-eus
Backports: CVEs + critical bugs only (no features)
Cadence: Monthly or as-needed
Example: CRI-O 1.30 base EOL Jun 2025 → extended to Oct 2026 (+16mo)
Support Matrix Example:
OCP 4.14 (EUS) - K8s 1.27
- Ships: CRI-O 1.27
- Supported: 1.27-1.30
- Recommended: Upgrade to 1.30 before Jun 2025
Upgrade Process: Cordon → Drain → Upgrade package → Restart → Verify → Uncordon
| Option | Key Risks | Severity | Mitigation |
|---|---|---|---|
| 1 | Branch explosion (10+), delayed CVE fixes | High | Automate backporting, dedicated team |
| 2 | Forward compat issues, customer confusion | Low-Med | Comprehensive testing, clear docs |
| 3 | Untested combos, dependency/config breaks | High | Extensive CI/CD, gradual rollout |
- Maintenance: 50% branch reduction (10→5)
- Security: 100% EUS customers receive CVEs, <2wk backport time
- Adoption: >90% EUS customers on supported CRI-O versions
| Criteria | Option 1 | Option 2 | Option 3 |
|---|---|---|---|
| Active Branches | 8-10 | 5-6 | 3 |
| Extended Support | 16-28mo/version | 16mo (n+3 only) | 1-2mo (latest) |
| CRI Skew Compliant | ✅ | ✅ | |
| Testing Burden | Low | Medium | High |
| Maintenance | Very High | Medium | Low |
| Backporting | Very High | Medium | Minimal |
| CVE Fix Speed | Slow (10x) | Medium (5x) | Fast (1x) |
| Risk | Low | Low-Med | Med-High |
Initial Phase:
- Implement Option 2: Test OCP 4.14 + CRI-O 1.30, document matrix
- Setup CI/CD for cross-version testing, automated CVE monitoring
- Create
release-1.30-eusbranch
Ongoing: Extend CRI-O versions, monitor metrics, gather feedback, test n+7
Future: Evaluate Option 3, contribute upstream EUS proposal, automate upgrades
Current CRI-O creates 24-28 month gaps for OpenShift EUS. Recommended: Start with Option 2 (50% maintenance reduction, within CRI guarantees), evaluate Option 3 after 12 months. This balances customer security needs with engineering resources.
- v1 stable since K8s 1.23
- n±3 guarantee: Kubelet works with CRI API ±3 minor versions
- Features: Runtime/image services, version negotiation, graceful degradation
| Ver | Type | GA | K8s | CRI-O | Std EOL | Max EOL |
|---|---|---|---|---|---|---|
| 4.14 | EUS | Oct'23 | 1.27 | 1.27 | Apr'25 | Oct'26 |
| 4.16 | EUS | Jun'24 | 1.29 | 1.29 | Dec'25 | Jun'27 |
| 4.18 | EUS | Feb'25 | 1.31 | 1.31 | Aug'26 | Feb'28 |
| 4.20 | EUS | Oct'25 | 1.33 | 1.33 | Apr'27 | Oct'28 |