Skip to content

Commit 670ee5e

Browse files
committed
feat: [pko-351] added documentation for HostedClusterPackage API
Signed-off-by: Ankit152 <ankitkurmi152@gmail.com>
1 parent a015b2d commit 670ee5e

2 files changed

Lines changed: 507 additions & 70 deletions

File tree

Lines changed: 217 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,217 @@
1+
---
2+
title: HostedClusterPackage API
3+
weight: 1201
4+
images: []
5+
mermaid: true
6+
---
7+
8+
**Note**: The `HostedClusterPackage` API is experimental and subject to
9+
change in the future.
10+
11+
The `HostedClusterPackage` API extends Package Operator with progressive
12+
rollout capabilities for Packages targeting HyperShift Hosted Control Planes
13+
(HCP). It introduces a cluster-scoped custom resource, the
14+
`HostedClusterPackage`, which governs the lifecycle and update process of
15+
Packages across all hosted control planes within a HyperShift Management
16+
Cluster.
17+
18+
## Overview
19+
20+
This API allows for the central rollout of `Packages` to all hosted control
21+
planes on a given management cluster. It provides facilities to control
22+
rollout strategies, significantly reducing the "blast radius" of failed
23+
upgrades compared to simultaneous updates. It also simplifies the
24+
configuration required to deliver objects into an HCP namespace by reducing
25+
the dependency on multiple systems down to a single API.
26+
27+
```mermaid
28+
flowchart LR
29+
subgraph "HyperShift Management Cluster (MC)"
30+
metrics-hsp["<b>HyperShift Package</b><br>metrics-forwarder"]
31+
subgraph "HC Namespace: my-cluster-x"
32+
ns-c1["<b>Package</b><br>metrics-forwarder"]
33+
end
34+
subgraph "HC Namespace: my-cluster-y"
35+
ns-c2["<b>Package</b><br>metrics-forwarder"]
36+
end
37+
end
38+
metrics-hsp--->ns-c1
39+
metrics-hsp--->ns-c2
40+
```
41+
42+
### Key Features
43+
44+
* **Progressive Rollout**: Updates are rolled out gradually to `HostedClusters`
45+
rather than all at once.
46+
* **Lifecycle Automation**: Automatically creates Packages for new
47+
`HostedClusters` and deletes them when the cluster is removed.
48+
* **Status & Monitoring**: Provides status updates on the number
49+
of available, unavailable, or updated packages.
50+
* **Simplified Configuration**: Reduces the configuration surface from
51+
multiple objects to just the `HostedClusterPackage` API.
52+
53+
## HostedClusterPackage Resource
54+
55+
The newly introduced `HostedClusterPackage` resource configuration object
56+
for this functionality. It coordinates the rollout process and which
57+
`HostedClusters` in the fleet are targeted.
58+
59+
### Targeting Clusters
60+
61+
The API includes an optional label selector to target specific HostedClusters
62+
within the Management cluster.
63+
64+
### Partitioning
65+
66+
To control the order of updates, you can attach an optional partition
67+
configuration to the Package API. This ensures that all items within a
68+
specific group are processed before the rollout moves to the next group.
69+
70+
* **Grouping**: The configuration uses labels on the HostedCluster object to
71+
assign groups (e.g., hypershift.openshift.io/risk-group).
72+
* **Ordering**: Groups can be ordered via a static list or by alphanumeric
73+
ascending order.
74+
* **Implicit Handling**: HostedClusters without the specified label or with
75+
unknown values are placed in an implicit "unknown" group and upgraded last.
76+
* **Dynamic Regrouping**: If a cluster's label changes to an earlier group
77+
during an upgrade, the process will jump back to handle that group before
78+
continuing.
79+
80+
Example for `static` ordering:
81+
82+
```yaml
83+
spec:
84+
partition:
85+
labelKey: hypershift.openshift.io/risk-group
86+
order:
87+
static:
88+
- early
89+
- normal
90+
- late
91+
```
92+
93+
Example for `alphanumeric` ordering:
94+
95+
```yaml
96+
spec:
97+
partition:
98+
labelKey: hypershift.openshift.io/risk-group
99+
order:
100+
alphanumericAsc: {}
101+
```
102+
103+
### Progression Strategies
104+
105+
The API supports configurable progression strategies to control the speed
106+
and safety of the rollout.
107+
108+
### Rolling Upgrade
109+
110+
The `rollingUpgrade` strategy is designed to keep service disruptions to a
111+
minimum.
112+
113+
* `maxUnavailable`: Configures the maximum number of Package instances that
114+
can be updating or unavailable at the same time. If a Package is already
115+
unavailable before the upgrade starts, it counts towards this limit. These
116+
unavailable packages are prioritized for updates to prevent accumulating
117+
faulty versions.
118+
119+
```yaml
120+
spec:
121+
strategy:
122+
rollingUpgrade:
123+
maxUnavailable: 1
124+
```
125+
126+
## Status & Observability
127+
128+
The `HostedClusterPackage` API exposes status information to help you track the
129+
progress of a rollout and the health of the fleet. This status can help you
130+
understand if an update is proceeding smoothly or if it has stalled due to
131+
errors.
132+
133+
### Rollout State
134+
135+
The status subresource provides high-level metrics regarding the rollout
136+
process. These fields allow you to quickly assess the distribution of package
137+
versions across your `HostedClusters`:
138+
139+
* **Updated Packages**: The number of `HostedClusters` that have successfully
140+
received the latest version of the Package.
141+
142+
* **Available Packages**: The number of `HostedClusters` where the Package is
143+
currently healthy and serving traffic based on `Available=True` status condition
144+
of the Package
145+
146+
* **Unavailable Packages**: The number of HostedClusters where the Package is
147+
currently degraded or updating. This count is used to enforce the
148+
maxUnavailable limit defined in the progression strategy.
149+
150+
### Progression Logic
151+
152+
The controller uses the status of individual Packages to determine if the
153+
rollout can proceed to the next target.
154+
155+
* **Success**: If a targeted HostedCluster successfully updates and becomes
156+
available, the operator proceeds to select the next cluster in the partition.
157+
158+
* **Failure**: If a Package update fails or becomes unavailable, the rollout
159+
pauses for that target hosted cluster. This prevents the propagation of errors
160+
to the rest of the fleet.
161+
162+
Example `Status` and `Conditons` for a successful rollout:
163+
164+
```yaml
165+
status:
166+
availablePackages: 3
167+
conditions:
168+
- lastTransitionTime: "2026-02-05T06:59:51Z"
169+
message: 3/3 packages available.
170+
observedGeneration: 2
171+
reason: EnoughPackagesAvailable
172+
status: "True"
173+
type: Available
174+
- lastTransitionTime: "2026-02-05T06:59:57Z"
175+
message: 3/3 packages progressed.
176+
observedGeneration: 2
177+
reason: AllPackagesProgressed
178+
status: "False"
179+
type: Progressing
180+
- lastTransitionTime: "2026-02-05T06:57:57Z"
181+
message: 0/3 packages paused.
182+
observedGeneration: 2
183+
reason: NoPackagePaused
184+
status: "False"
185+
type: HasPausedPackage
186+
observedGeneration: 2
187+
progressedPackages: 3
188+
totalPackages: 3
189+
updatedPackages: 3
190+
```
191+
192+
## Configuration Example
193+
194+
The following YAML example demonstrates a HostedClusterPackage configured with
195+
risk-based partitioning and a rolling upgrade strategy.
196+
197+
```yaml
198+
apiVersion: package-operator.run/v1alpha1
199+
kind: HostedClusterPackage
200+
metadata:
201+
name: example-hosted-cluster-package
202+
spec:
203+
template:
204+
metadata:
205+
labels:
206+
foo: bar
207+
spec:
208+
image: some-registry.io/foo-bar/test:v0.0.1
209+
# Partition Configuration
210+
partition:
211+
labelKey: hypershift.openshift.io/risk-group
212+
order:
213+
alphanumericAsc: {}
214+
strategy:
215+
rollingUpgrade:
216+
maxUnavailable: 1 # Max packages to update concurrently
217+
```

0 commit comments

Comments
 (0)