Shard CRD schema reference (group core.kcp.io)
APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources
Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
ShardSpec holds the desired state of the Shard.
baseURL is the address of the KCP shard for direct connections, e.g. by some front-proxy doing the fan-out to the shards.
externalURL is the externally visible address presented to users in Workspace URLs. Changing this will break all existing logical clusters on that shard, i.e. existing kubeconfigs of clients will be invalid. Hence, when changing this value, the old URL used by clients must keep working. The external address will not be unique if a front-proxy does a fan-out to shards, but all logical cluster clients will talk to the front-proxy. In that case, put the address of the front-proxy here. Note that movement of shards is only possible (in the future) between shards that share a common external URL. This will be defaulted to the value of the baseURL.
virtualWorkspaceURL is the address of the virtual workspace apiserver associated with this shard. It can be a direct address, an address of a front-proxy or even an address of an LB. As of today this address is assigned to APIExports. This will be defaulted to the value of the baseURL.
ShardStatus communicates the observed state of the Shard.
Set of integer resources that logical clusters can be scheduled into
Current processing state of the Shard.
Condition defines an observation of a object operational state.
Last time the condition transitioned from one status to another. This should be when the underlying condition changed. If that is not known, then using the time when the API field changed is acceptable.
A human readable message indicating details about the transition. This field may be empty.
The reason for the condition’s last transition in CamelCase. The specific API may choose whether or not this field is considered a guaranteed API. This field may not be empty.
Severity provides an explicit classification of Reason code, so the users or machines can immediately understand the current situation and act accordingly. The Severity field MUST be set only when Status=False.
Status of the condition, one of True, False, Unknown.
Type of condition in CamelCase or in foo.example.com/CamelCase. Many .condition.type values are consistent across resources like Available, but because arbitrary conditions can be useful (see .node.status.conditions), the ability to deconflict is important.