Skip to content

KEP 1645: fix ServiceExport conditions #5438

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

KEP 1645: fix ServiceExport conditions #5438

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
a96e064
KEP 1645: fix ServiceExport conditions example
MrFreezeex Jun 26, 2025
160120d
KEP 1645: fix reference to old condition types
MrFreezeex Jun 27, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
37 changes: 13 additions & 24 deletions keps/sig-multicluster/1645-multi-cluster-services-api/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -437,22 +437,8 @@ type ServiceExportStatus struct {
// +listMapKey=type
Conditions []metav1.Condition `json:"conditions,omitempty" patchStrategy:"merge" patchMergeKey:"type"`
}

const (
// ServiceExportValid means that the service referenced by this
// service export has been recognized as valid by an mcs-controller.
// This will be false if the service is found to be unexportable
// (ExternalName, not found).
ServiceExportValid = "Valid"
// ServiceExportConflict means that there is a conflict between two
// exports for the same Service. When "True", the condition message
// should contain enough information to diagnose the conflict:
// field(s) under contention, which cluster won, and why.
// Users should not expect detailed per-cluster information in the
// conflict message.
ServiceExportConflict = "Conflict"
)
```

```yaml
apiVersion: multicluster.k8s.io/v1alpha1
kind: ServiceExport
Expand All @@ -461,17 +447,20 @@ metadata:
namespace: my-ns
status:
conditions:
- type: Ready
- type: Accepted
status: "True"
message: "Service export is ready"
lastTransitionTime: "2020-03-30T01:33:51Z"
- type: Valid
reason: Accepted
message: "The ServiceExport and its Service is exportable."
- type: Exported
status: "True"
message: "Service export is valid"
lastTransitionTime: "2020-03-30T01:33:55Z"
- type: Conflict
reason: Exported
message: "The service has been exported"
- type: Conflicted
status: "True"
lastTransitionTime: "2020-03-30T01:33:55Z"
reason: TypeConflict
message: "Conflicting type. Using \"ClusterSetIP\" from oldest service export in \"cluster-1\". 2/5 clusters disagree."
```

Expand Down Expand Up @@ -686,8 +675,8 @@ this cluster.
complicate deployments by even attempting to stretch them across clusters.
Instead, regular `ExternalName` type `Services` should be created in each
cluster individually. If a `ServiceExport` is created for an `ExternalName`
service, a condition type `Valid` with a `false` status will be set on the
`ServiceExport`.
service, a condition type `Accepted` with reason `InvalidServiceType` and
status `false` will be set on the `ServiceExport`.

#### ClusterSetIP

Expand Down Expand Up @@ -986,8 +975,8 @@ services. If these properties are out of sync for a subset of exported services,
there is no clear way to determine how a service should be accessed.

Conflict resolution policy: **If any properties have conflicting values that can
not simply be merged, a `ServiceExportConflict` condition will be set on all
`ServiceExport`s for the conflicted service with a description of the conflict.
not simply be merged, a `Conflicted` condition with a `false` status will be set
on all `ServiceExport`s for the conflicted service with a description of the conflict.
The conflict will be resolved by assigning precedence based on each
`ServiceExport`'s `creationTimestamp`, from oldest to newest.**

Expand Down