---
title: v1.13 to v1.14
---

Follow the [Regular Upgrading Process](./README.md).

## Upgrading Notable Changes

### API Changes

- Introduced `spec.components.karmadaAPIServer.loadBalancerClass` field in `Karmada` API to specify a `loadBalancerClass` to select a specific load balancer implementation, aligning with Kubernetes Service behavior.
- Introduced `spec.customCertificate.leafCertValidityDays` field in `Karmada` API to specify a custom validity period in days for control plane leaf certificates (e.g., API server certificate). When not explicitly set, the default validity period of 1 year is used.
- Introduced `spec.suspend` field in `Karmada` API to temporarily pause/suspend the reconciliation of a `Karmada` object.
- `API Change`: Introduced a new API named ClusterTaintPolicy to handle cluster taint.
- `FederatedResourceQuota`: Added two additional printer columns, `OVERALL` and `OVERALL_USED`, to represent the enforced hard limits and current total usage; these columns will be displayed in the output of kubectl/karmadactl get.

### Deprecation

- `karmadactl`: The flag `--ca-cert-path` of `register`, which has been deprecated in release-1.13, now has been removed.
- The label `propagation.karmada.io/instruction` now has been deprecated in favor of the field(`.spec.suspendDispatching`) in Work API, the label will be removed in future releases.
- `karmada-webhook`: The `--default-not-ready-toleration-seconds` and `--default-unreachable-toleration-seconds` flags now have been deprecated, they will remain functional until v1.15. From release 1.15 the two flags will be removed and no default toleration will be added to the newly created PropagationPolicy/ClusterPropagationPolicy.
- `karmada-controller-manager`: The flag `--failover-eviction-timeout` now has been deprecated, it becomes obsolete now as the `cluster-controller` no longer automatically marks NoExecute taints.

### others

- Unify the rate limiter for different clients in each component to access member cluster apiserver. Access may be restricted in large-scale environments compared to before the modification. Administrators can avoid this situation by adjusting `cluster-api-qps` and `cluster-api-burst` for karmada-controller-manager, karmada-agent and karmada-metrics-adapter.
- Unify the rate limiter for different clients in each component to access karmada-apiserver. Access may be restricted in large-scale environments compared to before the modification. Administrators can avoid this situation by adjusting upward the rate limit parameters `kube-api-qps` and `kube-api-burst` for each component to access karmada-apiserver, and adjusting `cluster-api-qps` and `cluster-api-burst` for scheduler-estimator to access member cluster apiserver.