Skip to main content
Version: Next

v1.13 to v1.14

Follow the Regular Upgrading Process.

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.