From c2b2bdcd02d1d760c7e7a76a3c59ab9a7fe6d886 Mon Sep 17 00:00:00 2001 From: MilindRastogi24 Date: Wed, 17 Jun 2026 13:52:57 +0530 Subject: [PATCH] Normalize line endings to LF and add .gitattributes for branch release-1.18 Signed-off-by: MilindRastogi24 --- .gitattributes | 18 ++ .../compatibility/compatibility.md | 152 +++++++-------- docs/administrator/upgrading/v1.11-v1.12.md | 88 ++++----- .../compatibility/compatibility.md | 120 ++++++------ .../administrator/upgrading/v1.11-v1.12.md | 88 ++++----- .../scheduling/multi-component-scheduling.md | 178 +++++++++--------- .../administrator/upgrading/v1.11-v1.12.md | 88 ++++----- .../compatibility/compatibility.md | 120 ++++++------ .../administrator/upgrading/v1.11-v1.12.md | 88 ++++----- .../compatibility/compatibility.md | 120 ++++++------ .../administrator/upgrading/v1.11-v1.12.md | 88 ++++----- .../compatibility/compatibility.md | 120 ++++++------ .../administrator/upgrading/v1.11-v1.12.md | 88 ++++----- .../compatibility/compatibility.md | 120 ++++++------ .../administrator/upgrading/v1.11-v1.12.md | 88 ++++----- .../scheduling/multi-component-scheduling.md | 178 +++++++++--------- .../compatibility/compatibility.md | 120 ++++++------ .../administrator/upgrading/v1.11-v1.12.md | 88 ++++----- .../scheduling/multi-component-scheduling.md | 178 +++++++++--------- .../administrator/upgrading/v1.11-v1.12.md | 88 ++++----- .../compatibility/compatibility.md | 152 +++++++-------- .../administrator/upgrading/v1.11-v1.12.md | 88 ++++----- .../compatibility/compatibility.md | 152 +++++++-------- .../administrator/upgrading/v1.11-v1.12.md | 88 ++++----- .../compatibility/compatibility.md | 152 +++++++-------- .../administrator/upgrading/v1.11-v1.12.md | 88 ++++----- .../compatibility/compatibility.md | 152 +++++++-------- .../administrator/upgrading/v1.11-v1.12.md | 88 ++++----- .../compatibility/compatibility.md | 152 +++++++-------- .../administrator/upgrading/v1.11-v1.12.md | 88 ++++----- 30 files changed, 1717 insertions(+), 1699 deletions(-) create mode 100644 .gitattributes diff --git a/.gitattributes b/.gitattributes new file mode 100644 index 000000000..d339270c4 --- /dev/null +++ b/.gitattributes @@ -0,0 +1,18 @@ +# Normalize line endings: LF in the repository and working tree. +* text=auto eol=lf + +# Binary assets +*.png binary +*.jpg binary +*.jpeg binary +*.gif binary +*.webp binary +*.ico binary +*.woff binary +*.woff2 binary +*.ttf binary +*.eot binary +*.pdf binary + +# Shell scripts must use LF +*.sh text eol=lf diff --git a/docs/administrator/compatibility/compatibility.md b/docs/administrator/compatibility/compatibility.md index 4984a9946..14ebbcaf3 100644 --- a/docs/administrator/compatibility/compatibility.md +++ b/docs/administrator/compatibility/compatibility.md @@ -1,76 +1,76 @@ ---- -title: Kubernetes Compatibility ---- - -This document provides a comprehensive guide to Karmada's compatibility with Kubernetes versions, focusing on two -primary dimensions: -- Karmada control plane APIs support: How many APIs are supported? -- Kubernetes versions support: How many Kubernetes versions are supported? - -This document helps administrators understand how Karmada manages resources across clusters with mixed Kubernetes versions. -It ensures safe propagation by respecting each cluster’s API capabilities and provides guidelines for maintaining -compatibility during upgrades or migrations. - -## Karmada control plane APIs support - -Karmada supports all Kubernetes APIs available in the version of kube-apiserver it uses. For example, if Karmada APIServer -uses kube-apiserver@v1.32, it inherits support for every API (e.g., Deployment, Service, Ingress) and API version -(e.g., apps/v1, networking.k8s.io/v1) available in Kubernetes v1.32. - -Beyond native Kubernetes APIs, Karmada extends its capabilities through Custom Resource Definitions (CRDs) and -Aggregated APIServer, the same extension mechanisms used in Kubernetes itself: -- **CRD Extensions**: Most Karmada-specific APIs (e.g., PropagationPolicy, OverridePolicy) are implemented as CRDs. -Users can also define custom CRDs in Karmada and propagate them to member clusters, following the same workflow as -native Kubernetes APIs. -- **Aggregated APIServer**: Karmada’s Cluster API is extended by karmada-aggregated-apiserver, thus users can directly -query member cluster resources (e.g., Nodes, Pods) through Karmada’s unified API endpoint. -Users can extend Karmada’s API surface in the same way they extend Kubernetes -- whether for custom resources or -third-party integrations. - -To view all supported APIs, run the `karmadactl api-resources` command against Karmada, this lists all supported API -including Kubernetes API and extended APIs, the output like: -``` -# karmadactl api-resources -NAME SHORTNAMES APIVERSION NAMESPACED KIND -pods po v1 true Pod -deployments deploy apps/v1 true Deployment -clusters cluster.karmada.io/v1alpha1 false Cluster -overridepolicies op policy.karmada.io/v1alpha1 true OverridePolicy -propagationpolicies pp policy.karmada.io/v1alpha1 true PropagationPolicy -... -``` - -## Kubernetes versions support - -Karmada manages Kubernetes clusters using a minimal set of stable APIs and endpoints, ensuring broad compatibility -across Kubernetes versions. Each Karmada release integrates the latest Kubernetes client libraries and tests -compatibility with the latest 10 Kubernetes versions. For example, Karmada v1.14 uses Kubernetes client v1.32 and is -validated against Kubernetes versions from v1.23 to v1.32. - -A resource can be propagated to member clusters only if both Karmada and the target cluster support its API. -- If Karmada does not recognize the API (e.g., unsupported CRDs or deprecated APIs), the resource cannot be created in Karmada. -- If a member cluster lacks the API (e.g., an older cluster missing networking.k8s.io/v1/Ingress), Karmada skips propagation to that cluster. - -## FAQ - -### How to choose the version of Karmada APIServer? - -The Karmada project automatically updates the default kube-apiserver version in its installation tools (e.g., Karmada Operator) -to support the latest Kubernetes APIs. In most cases, users do not need to change it, even in case of upgrading Karmada. - -You may need to upgrade Karmada APIServer in cases such as: -- Adopting New Kubernetes APIs: To leverage features introduced in newer Kubernetes versions. -- Addressing CVEs: To resolve security vulnerabilities present in older versions. - -Note that upgrading should be taken very carefully: - -- Review API Deprecations: Ensure resource types used in your workloads are not deprecated in the target Kubernetes version. -- Incremental Upgrades: Always upgrade one minor version at a time (e.g., kube-apiserver@v1.32 → v1.33). -Avoid skipping versions (e.g., v1.32 → v1.34), as Kubernetes relies on incremental API deprecation and automatic -conversion mechanisms to safely migrate deprecated APIs to newer versions. - -### How to handle member clusters with large version gaps? - -For scenarios where member clusters span incompatible API versions (e.g., some support networking.k8s.io/v1, others only v1beta1), -Currently, Karmada does not automatically convert API versions according to the capacity of member clusters, instead, it is -recommended to upgrade the outdated clusters to a newer Kubernetes version. +--- +title: Kubernetes Compatibility +--- + +This document provides a comprehensive guide to Karmada's compatibility with Kubernetes versions, focusing on two +primary dimensions: +- Karmada control plane APIs support: How many APIs are supported? +- Kubernetes versions support: How many Kubernetes versions are supported? + +This document helps administrators understand how Karmada manages resources across clusters with mixed Kubernetes versions. +It ensures safe propagation by respecting each cluster’s API capabilities and provides guidelines for maintaining +compatibility during upgrades or migrations. + +## Karmada control plane APIs support + +Karmada supports all Kubernetes APIs available in the version of kube-apiserver it uses. For example, if Karmada APIServer +uses kube-apiserver@v1.32, it inherits support for every API (e.g., Deployment, Service, Ingress) and API version +(e.g., apps/v1, networking.k8s.io/v1) available in Kubernetes v1.32. + +Beyond native Kubernetes APIs, Karmada extends its capabilities through Custom Resource Definitions (CRDs) and +Aggregated APIServer, the same extension mechanisms used in Kubernetes itself: +- **CRD Extensions**: Most Karmada-specific APIs (e.g., PropagationPolicy, OverridePolicy) are implemented as CRDs. +Users can also define custom CRDs in Karmada and propagate them to member clusters, following the same workflow as +native Kubernetes APIs. +- **Aggregated APIServer**: Karmada’s Cluster API is extended by karmada-aggregated-apiserver, thus users can directly +query member cluster resources (e.g., Nodes, Pods) through Karmada’s unified API endpoint. +Users can extend Karmada’s API surface in the same way they extend Kubernetes -- whether for custom resources or +third-party integrations. + +To view all supported APIs, run the `karmadactl api-resources` command against Karmada, this lists all supported API +including Kubernetes API and extended APIs, the output like: +``` +# karmadactl api-resources +NAME SHORTNAMES APIVERSION NAMESPACED KIND +pods po v1 true Pod +deployments deploy apps/v1 true Deployment +clusters cluster.karmada.io/v1alpha1 false Cluster +overridepolicies op policy.karmada.io/v1alpha1 true OverridePolicy +propagationpolicies pp policy.karmada.io/v1alpha1 true PropagationPolicy +... +``` + +## Kubernetes versions support + +Karmada manages Kubernetes clusters using a minimal set of stable APIs and endpoints, ensuring broad compatibility +across Kubernetes versions. Each Karmada release integrates the latest Kubernetes client libraries and tests +compatibility with the latest 10 Kubernetes versions. For example, Karmada v1.14 uses Kubernetes client v1.32 and is +validated against Kubernetes versions from v1.23 to v1.32. + +A resource can be propagated to member clusters only if both Karmada and the target cluster support its API. +- If Karmada does not recognize the API (e.g., unsupported CRDs or deprecated APIs), the resource cannot be created in Karmada. +- If a member cluster lacks the API (e.g., an older cluster missing networking.k8s.io/v1/Ingress), Karmada skips propagation to that cluster. + +## FAQ + +### How to choose the version of Karmada APIServer? + +The Karmada project automatically updates the default kube-apiserver version in its installation tools (e.g., Karmada Operator) +to support the latest Kubernetes APIs. In most cases, users do not need to change it, even in case of upgrading Karmada. + +You may need to upgrade Karmada APIServer in cases such as: +- Adopting New Kubernetes APIs: To leverage features introduced in newer Kubernetes versions. +- Addressing CVEs: To resolve security vulnerabilities present in older versions. + +Note that upgrading should be taken very carefully: + +- Review API Deprecations: Ensure resource types used in your workloads are not deprecated in the target Kubernetes version. +- Incremental Upgrades: Always upgrade one minor version at a time (e.g., kube-apiserver@v1.32 → v1.33). +Avoid skipping versions (e.g., v1.32 → v1.34), as Kubernetes relies on incremental API deprecation and automatic +conversion mechanisms to safely migrate deprecated APIs to newer versions. + +### How to handle member clusters with large version gaps? + +For scenarios where member clusters span incompatible API versions (e.g., some support networking.k8s.io/v1, others only v1beta1), +Currently, Karmada does not automatically convert API versions according to the capacity of member clusters, instead, it is +recommended to upgrade the outdated clusters to a newer Kubernetes version. diff --git a/docs/administrator/upgrading/v1.11-v1.12.md b/docs/administrator/upgrading/v1.11-v1.12.md index 3d52473d3..570bb839e 100644 --- a/docs/administrator/upgrading/v1.11-v1.12.md +++ b/docs/administrator/upgrading/v1.11-v1.12.md @@ -1,45 +1,45 @@ ---- -title: v1.11 to v1.12 ---- - -Follow the [Regular Upgrading Process](./README.md). - -## Upgrading Notable Changes - -### API Changes - -- Introduced `SecretRef` to `Karmada` API as part of the configuration for connecting to an external etcd cluster can be used to reference a secret that contains credentials for connecting to an external etcd cluster. -- Introduced `extraVolumes` and `extraVolumemounts` to the `Karmada` API to optionally specify extra volumes and volume mounts for the Karmada API server component. -- Introduced `ApiServerService` field to `Karmada` API as part of the Karmada instance status can be used to reference the API Server service for that instance. This is useful for scenarios where higher level operators need to discover the API Server service of a Karmada instance for tasks like setting up ingress traffic. -- Introduced `CustomCertificate.ApiServerCACert` field to `Karmada` API as part of the `Karmada` spec to specify the reference to a secret that contains a custom CA certificate for the Karmada API Server. -- API change: The ServiceType of the Karmada API server in `Karmada` API now has been restricted to `ClusterIP`, `NodePort` and `LoadBalancer`. -- Introduced a new condition `CompleteAPIEnablements` to `Cluster` API to represent the API collection status. -- Introduced `PreserveResourcesOnDeletion` field to both `PropagationPolicy` and `ClusterPropagationPolicy` API, which provides the ability to roll back migration safely. -- API Change: Introduced `FieldOverrider` to both `OverridePolicy` and `ClusterOverridePolicy`, which provides the ability to override structured data nested in manifest like ConfigMap or Secret. -- Introduced `PurgeMode` to `GracefulEvictionTask` in `ResourceBinding` and `ClusterResourceBinding` API. -- Introduced `StatePreservation` to `PropagationPolicy`, which will be used to preserve status in case of application failover. - -### Deprecation - -- `ExternalEtcd.CAData`, `ExternalEtcd.CertData` and `ExternalEtcd.KeyData` in `Karmada` API are deprecated and will be removed in a future version. Use SecretRef for providing client connection credentials. -- The following flags have been deprecated in release `v1.11.0` and now have been removed: - * `karmada-agent`: - * --bind-address - * --secure-port - * `karmada-controller-manager`: - * --bind-address - * --secure-port - * `karmada-scheduler-estimator`: - * --bind-address - * --secure-port - * `karmada-scheduler`: - * --bind-address - * --secure-port - * `karmada-descheduler`: - * --bind-address - * --secure-port - -### karmada-controller-manager - -- Introduced feature gate `StatefulFailoverInjection` to control whether Karmada collects and injects state information during a failover event for stateful application. +--- +title: v1.11 to v1.12 +--- + +Follow the [Regular Upgrading Process](./README.md). + +## Upgrading Notable Changes + +### API Changes + +- Introduced `SecretRef` to `Karmada` API as part of the configuration for connecting to an external etcd cluster can be used to reference a secret that contains credentials for connecting to an external etcd cluster. +- Introduced `extraVolumes` and `extraVolumemounts` to the `Karmada` API to optionally specify extra volumes and volume mounts for the Karmada API server component. +- Introduced `ApiServerService` field to `Karmada` API as part of the Karmada instance status can be used to reference the API Server service for that instance. This is useful for scenarios where higher level operators need to discover the API Server service of a Karmada instance for tasks like setting up ingress traffic. +- Introduced `CustomCertificate.ApiServerCACert` field to `Karmada` API as part of the `Karmada` spec to specify the reference to a secret that contains a custom CA certificate for the Karmada API Server. +- API change: The ServiceType of the Karmada API server in `Karmada` API now has been restricted to `ClusterIP`, `NodePort` and `LoadBalancer`. +- Introduced a new condition `CompleteAPIEnablements` to `Cluster` API to represent the API collection status. +- Introduced `PreserveResourcesOnDeletion` field to both `PropagationPolicy` and `ClusterPropagationPolicy` API, which provides the ability to roll back migration safely. +- API Change: Introduced `FieldOverrider` to both `OverridePolicy` and `ClusterOverridePolicy`, which provides the ability to override structured data nested in manifest like ConfigMap or Secret. +- Introduced `PurgeMode` to `GracefulEvictionTask` in `ResourceBinding` and `ClusterResourceBinding` API. +- Introduced `StatePreservation` to `PropagationPolicy`, which will be used to preserve status in case of application failover. + +### Deprecation + +- `ExternalEtcd.CAData`, `ExternalEtcd.CertData` and `ExternalEtcd.KeyData` in `Karmada` API are deprecated and will be removed in a future version. Use SecretRef for providing client connection credentials. +- The following flags have been deprecated in release `v1.11.0` and now have been removed: + * `karmada-agent`: + * --bind-address + * --secure-port + * `karmada-controller-manager`: + * --bind-address + * --secure-port + * `karmada-scheduler-estimator`: + * --bind-address + * --secure-port + * `karmada-scheduler`: + * --bind-address + * --secure-port + * `karmada-descheduler`: + * --bind-address + * --secure-port + +### karmada-controller-manager + +- Introduced feature gate `StatefulFailoverInjection` to control whether Karmada collects and injects state information during a failover event for stateful application. - The feature `Failover` now has been disabled by default, which should be explicitly enabled to avoid unexpected incidents. \ No newline at end of file diff --git a/i18n/zh/docusaurus-plugin-content-docs/current/administrator/compatibility/compatibility.md b/i18n/zh/docusaurus-plugin-content-docs/current/administrator/compatibility/compatibility.md index a1a4dfb64..d5bc3b8e1 100644 --- a/i18n/zh/docusaurus-plugin-content-docs/current/administrator/compatibility/compatibility.md +++ b/i18n/zh/docusaurus-plugin-content-docs/current/administrator/compatibility/compatibility.md @@ -1,60 +1,60 @@ ---- -title: Kubernetes 兼容性 ---- - -本文档全面阐述了 Karmada 与 Kubernetes 版本的兼容性，主要从两个维度进行说明： -- Karmada 控制平面 API 支持：支持哪些 API？ -- Kubernetes 版本支持：支持哪些 Kubernetes 版本？ - -本文档帮助管理员理解 Karmada 如何管理混合 Kubernetes 版本集群间的资源。通过遵循各集群的 API 能力确保安全分发，并提供在升级或迁移过程中维护 -兼容性的指导原则。 - -## Karmada 控制平面 API 支持 - -Karmada 支持其使用的 kube-apiserver 版本中所有可用的 Kubernetes API。例如，如 Karmada APIServer 使用 kube-apiserver@v1.32， -则继承支持 Kubernetes v1.32 中所有 API（如 Deployment、Service、Ingress）及 API 版本（如 apps/v1、networking.k8s.io/v1）。 - -除原生 Kubernetes API 外，Karmada 可通过以下与 Kubernetes 相同的扩展机制增强能力： -- **CRD 扩展**：大多数 Karmada 特有 API（如 PropagationPolicy、OverridePolicy）通过 CRD 实现。用户也可在 Karmada 中定义自定义 CRD，并像原生 Kubernetes API 一样分发到成员集群。 -- **聚合 APIServer**：Karmada 的 Cluster API 通过 karmada-aggregated-apiserver 扩展，用户可直接通过 Karmada 统一 API 端点查询成员集群资源（如 Nodes、Pods）。 - 用户可以通过与扩展 Kubernetes 相同的方式扩展 Karmada 的 API 能力，无论是自定义资源还是第三方集成。 - -要查看所有支持的 API，请对 Karmada 执行 `karmadactl api-resources` 命令，该命令会列出包括 Kubernetes API 和扩展 API 在内的所有支持API，输出示例如下： -``` -# karmadactl api-resources -NAME SHORTNAMES APIVERSION NAMESPACED KIND -pods po v1 true Pod -deployments deploy apps/v1 true Deployment -clusters cluster.karmada.io/v1alpha1 false Cluster -overridepolicies op policy.karmada.io/v1alpha1 true OverridePolicy -propagationpolicies pp policy.karmada.io/v1alpha1 true PropagationPolicy -... -``` - -## Kubernetes 版本支持 - -Karmada 使用最小化的稳定 API 和端点管理 Kubernetes 集群，确保广泛的 Kubernetes 版本兼容性。每个 Karmada 版本集成最新的 Kubernetes 客户端， -并测试最近 10 个 Kubernetes 版本的兼容性。例如，Karmada v1.14 使用 Kubernetes 客户端 v1.32，会集成验证 Kubernetes v1.23 至 v1.32 版本。 - -资源仅在 Karmada 和目标集群均支持其 API 时才能被分发： -- 若 Karmada 无法识别 API（如不支持的 CRD 或已弃用的 API），则无法在 Karmada 中创建资源 -- 若成员集群缺少 API（如旧版本集群缺少 networking.k8s.io/v1/Ingress），Karmada 将跳过对该集群的分发 - -## 常见问题解答 - -### 如何选择 Karmada APIServer 版本？ - -Karmada 项目会在其安装工具（如 Karmada Operator）中自动更新默认的 kube-apiserver 版本以支持最新 Kubernetes API。大多数情况下用户无需修改，即使升级 Karmada 时也无需调整。 - -您可能需要升级 Karmada APIServer 的情况包括： -- 采用新 Kubernetes API：需要利用新版 Kubernetes 特性 -- 修复 CVE 漏洞：解决旧版本存在的安全隐患 - -注意升级需谨慎操作： -- 检查 API 弃用情况：确保工作负载使用的资源类型在目标 Kubernetes 版本中未被弃用 -- 逐步升级：始终逐个次版本升级（如 kube-apiserver@v1.32 → v1.33），避免跨版本升级（如 v1.32 → v1.34）。Kubernetes 依赖渐进式 API 弃用和自动转换机制来安全迁移弃用 API。 - -### 如何处理版本跨度大的成员集群？ - -当成员集群存在 API 版本不兼容时（如部分支持 networking.k8s.io/v1，部分仅支持 v1beta1），目前 Karmada 不会根据成员集群能力自动转换 API 版本。 -建议将过时集群升级至新 Kubernetes 版本。 +--- +title: Kubernetes 兼容性 +--- + +本文档全面阐述了 Karmada 与 Kubernetes 版本的兼容性，主要从两个维度进行说明： +- Karmada 控制平面 API 支持：支持哪些 API？ +- Kubernetes 版本支持：支持哪些 Kubernetes 版本？ + +本文档帮助管理员理解 Karmada 如何管理混合 Kubernetes 版本集群间的资源。通过遵循各集群的 API 能力确保安全分发，并提供在升级或迁移过程中维护 +兼容性的指导原则。 + +## Karmada 控制平面 API 支持 + +Karmada 支持其使用的 kube-apiserver 版本中所有可用的 Kubernetes API。例如，如 Karmada APIServer 使用 kube-apiserver@v1.32， +则继承支持 Kubernetes v1.32 中所有 API（如 Deployment、Service、Ingress）及 API 版本（如 apps/v1、networking.k8s.io/v1）。 + +除原生 Kubernetes API 外，Karmada 可通过以下与 Kubernetes 相同的扩展机制增强能力： +- **CRD 扩展**：大多数 Karmada 特有 API（如 PropagationPolicy、OverridePolicy）通过 CRD 实现。用户也可在 Karmada 中定义自定义 CRD，并像原生 Kubernetes API 一样分发到成员集群。 +- **聚合 APIServer**：Karmada 的 Cluster API 通过 karmada-aggregated-apiserver 扩展，用户可直接通过 Karmada 统一 API 端点查询成员集群资源（如 Nodes、Pods）。 + 用户可以通过与扩展 Kubernetes 相同的方式扩展 Karmada 的 API 能力，无论是自定义资源还是第三方集成。 + +要查看所有支持的 API，请对 Karmada 执行 `karmadactl api-resources` 命令，该命令会列出包括 Kubernetes API 和扩展 API 在内的所有支持API，输出示例如下： +``` +# karmadactl api-resources +NAME SHORTNAMES APIVERSION NAMESPACED KIND +pods po v1 true Pod +deployments deploy apps/v1 true Deployment +clusters cluster.karmada.io/v1alpha1 false Cluster +overridepolicies op policy.karmada.io/v1alpha1 true OverridePolicy +propagationpolicies pp policy.karmada.io/v1alpha1 true PropagationPolicy +... +``` + +## Kubernetes 版本支持 + +Karmada 使用最小化的稳定 API 和端点管理 Kubernetes 集群，确保广泛的 Kubernetes 版本兼容性。每个 Karmada 版本集成最新的 Kubernetes 客户端， +并测试最近 10 个 Kubernetes 版本的兼容性。例如，Karmada v1.14 使用 Kubernetes 客户端 v1.32，会集成验证 Kubernetes v1.23 至 v1.32 版本。 + +资源仅在 Karmada 和目标集群均支持其 API 时才能被分发： +- 若 Karmada 无法识别 API（如不支持的 CRD 或已弃用的 API），则无法在 Karmada 中创建资源 +- 若成员集群缺少 API（如旧版本集群缺少 networking.k8s.io/v1/Ingress），Karmada 将跳过对该集群的分发 + +## 常见问题解答 + +### 如何选择 Karmada APIServer 版本？ + +Karmada 项目会在其安装工具（如 Karmada Operator）中自动更新默认的 kube-apiserver 版本以支持最新 Kubernetes API。大多数情况下用户无需修改，即使升级 Karmada 时也无需调整。 + +您可能需要升级 Karmada APIServer 的情况包括： +- 采用新 Kubernetes API：需要利用新版 Kubernetes 特性 +- 修复 CVE 漏洞：解决旧版本存在的安全隐患 + +注意升级需谨慎操作： +- 检查 API 弃用情况：确保工作负载使用的资源类型在目标 Kubernetes 版本中未被弃用 +- 逐步升级：始终逐个次版本升级（如 kube-apiserver@v1.32 → v1.33），避免跨版本升级（如 v1.32 → v1.34）。Kubernetes 依赖渐进式 API 弃用和自动转换机制来安全迁移弃用 API。 + +### 如何处理版本跨度大的成员集群？ + +当成员集群存在 API 版本不兼容时（如部分支持 networking.k8s.io/v1，部分仅支持 v1beta1），目前 Karmada 不会根据成员集群能力自动转换 API 版本。 +建议将过时集群升级至新 Kubernetes 版本。 diff --git a/i18n/zh/docusaurus-plugin-content-docs/current/administrator/upgrading/v1.11-v1.12.md b/i18n/zh/docusaurus-plugin-content-docs/current/administrator/upgrading/v1.11-v1.12.md index 6331f4933..81947e71b 100644 --- a/i18n/zh/docusaurus-plugin-content-docs/current/administrator/upgrading/v1.11-v1.12.md +++ b/i18n/zh/docusaurus-plugin-content-docs/current/administrator/upgrading/v1.11-v1.12.md @@ -1,45 +1,45 @@ ---- -title: v1.11 升级到 v1.12 ---- - -遵循[常规升级流程](./README.md)。 - -## 升级后显著变化 - -### API 变化 - -- 在 `Karmada` API 中引入了 `SecretRef`，作为连接外部 etcd 集群的配置，可用于指定包含了连接外部 etcd 集群凭证的 secret。 -- 在 `Karmada` API 中引入了 `extraVolumes` 和 `extraVolumemounts` ，以便为 Karmada API server组件指定额外的卷和卷挂载。 -- 在 `Karmada` API中引入了 `ApiServerService` 字段，作为 Karmada 实例状态的一部分，该字段可用于引用该实例的 API Server 服务。这对于需要发现Karmada 实例的 API Server 服务以执行如设置入口流量等任务的高级操作员来说非常有用。 -- 在`Karmada` API中引入了`CustomCertificate.ApiServerCACert`字段，用于指定包含 Karmada API Server 自定义 CA 证书的secret。 -- 在`Karmada` API中，Karmada API server的 ServiceType 现在被限制为`ClusterIP`、`NodePort`和`LoadBalancer`。 -- 在`Cluster` API中引入了一个新的条件`CompleteAPIEnablements`，用于表示API集合的状态。 -- 在`PropagationPolicy`和`ClusterPropagationPolicy` API中引入了`PreserveResourcesOnDeletion`字段，该字段提供了安全回滚迁移的能力。 -- 在`OverridePolicy`和`ClusterOverridePolicy`中引入了`FieldOverrider`，它提供了覆盖如 ConfigMap 或 Secret 等清单中嵌套的结构化数据的能力。 -- 在`ResourceBinding`和`ClusterResourceBinding` API的`GracefulEvictionTask`中引入了`PurgeMode`。 -- 在`PropagationPolicy`中引入了`StatePreservation`，它将在应用故障迁移场景中保存状态。 - -### 弃用 - -- 在`Karmada` API中，`ExternalEtcd.CAData`、`ExternalEtcd.CertData`和`ExternalEtcd.KeyData`已被弃用，并将在未来的版本中移除。请使用 `SecretRef` 来提供客户端连接凭证。 -- 在版本`v1.11.0`中已弃用的以下启动参数现在已被移除： - * `karmada-agent`: - * --bind-address - * --secure-port - * `karmada-controller-manager`: - * --bind-address - * --secure-port - * `karmada-scheduler-estimator`: - * --bind-address - * --secure-port - * `karmada-scheduler`: - * --bind-address - * --secure-port - * `karmada-descheduler`: - * --bind-address - * --secure-port - -### karmada-controller-manager - -- 引入了特性门控`StatefulFailoverInjection`，用于控制 Karmada 在有状态应用的故障转移期间是否收集和注入状态信息。 +--- +title: v1.11 升级到 v1.12 +--- + +遵循[常规升级流程](./README.md)。 + +## 升级后显著变化 + +### API 变化 + +- 在 `Karmada` API 中引入了 `SecretRef`，作为连接外部 etcd 集群的配置，可用于指定包含了连接外部 etcd 集群凭证的 secret。 +- 在 `Karmada` API 中引入了 `extraVolumes` 和 `extraVolumemounts` ，以便为 Karmada API server组件指定额外的卷和卷挂载。 +- 在 `Karmada` API中引入了 `ApiServerService` 字段，作为 Karmada 实例状态的一部分，该字段可用于引用该实例的 API Server 服务。这对于需要发现Karmada 实例的 API Server 服务以执行如设置入口流量等任务的高级操作员来说非常有用。 +- 在`Karmada` API中引入了`CustomCertificate.ApiServerCACert`字段，用于指定包含 Karmada API Server 自定义 CA 证书的secret。 +- 在`Karmada` API中，Karmada API server的 ServiceType 现在被限制为`ClusterIP`、`NodePort`和`LoadBalancer`。 +- 在`Cluster` API中引入了一个新的条件`CompleteAPIEnablements`，用于表示API集合的状态。 +- 在`PropagationPolicy`和`ClusterPropagationPolicy` API中引入了`PreserveResourcesOnDeletion`字段，该字段提供了安全回滚迁移的能力。 +- 在`OverridePolicy`和`ClusterOverridePolicy`中引入了`FieldOverrider`，它提供了覆盖如 ConfigMap 或 Secret 等清单中嵌套的结构化数据的能力。 +- 在`ResourceBinding`和`ClusterResourceBinding` API的`GracefulEvictionTask`中引入了`PurgeMode`。 +- 在`PropagationPolicy`中引入了`StatePreservation`，它将在应用故障迁移场景中保存状态。 + +### 弃用 + +- 在`Karmada` API中，`ExternalEtcd.CAData`、`ExternalEtcd.CertData`和`ExternalEtcd.KeyData`已被弃用，并将在未来的版本中移除。请使用 `SecretRef` 来提供客户端连接凭证。 +- 在版本`v1.11.0`中已弃用的以下启动参数现在已被移除： + * `karmada-agent`: + * --bind-address + * --secure-port + * `karmada-controller-manager`: + * --bind-address + * --secure-port + * `karmada-scheduler-estimator`: + * --bind-address + * --secure-port + * `karmada-scheduler`: + * --bind-address + * --secure-port + * `karmada-descheduler`: + * --bind-address + * --secure-port + +### karmada-controller-manager + +- 引入了特性门控`StatefulFailoverInjection`，用于控制 Karmada 在有状态应用的故障转移期间是否收集和注入状态信息。 - 特性`Failover`现在默认已禁用，需要显式启用以避免意外事件。 \ No newline at end of file diff --git a/i18n/zh/docusaurus-plugin-content-docs/current/userguide/scheduling/multi-component-scheduling.md b/i18n/zh/docusaurus-plugin-content-docs/current/userguide/scheduling/multi-component-scheduling.md index cbf892d63..1251774bc 100644 --- a/i18n/zh/docusaurus-plugin-content-docs/current/userguide/scheduling/multi-component-scheduling.md +++ b/i18n/zh/docusaurus-plugin-content-docs/current/userguide/scheduling/multi-component-scheduling.md @@ -1,89 +1,89 @@ ---- -title: 调度多组件工作负载 ---- - -## 概述 - -许多现代分布式应用程序由具有异构资源需求的多个组件组成。例如，`Flink 集群`包含 `JobManager` 和 `TaskManager` 组件，而 `Ray 集群`则包含 `Head` 和 `Worker` 节点。每个组件通常具有不同的副本数和资源规格。 - -从 Karmada v1.16 开始，`多 Pod 模板调度`功能为这些复杂工作负载提供了精确的资源感知调度能力。这确保了 Karmada 能够正确理解多组件应用程序的总资源需求，并在成员集群之间做出明智的调度决策。 - -## 为什么需要多组件调度？ - -在 v1.16 之前，Karmada 调度器假设工作负载中的所有副本都是相同的，使用单一的 Pod 模板来表示资源需求。这种假设对于 Deployment 等简单应用程序效果良好，但对于多组件工作负载则会导致不准确的情况。 - -考虑一个具有两个组件的 FlinkDeployment： -- JobManager：1 个副本，需要 1 CPU 和 2Gi 内存 -- TaskManager：3 个副本，每个需要 2 CPU 和 4Gi 内存 - -使用传统调度，调度器只能表示一个组件的需求，导致： -- 低估：将 JobManager 配置应用于所有副本 → 仅计算 **4 个 CPU** 总量（实际需要 7 个）→ 存在调度到资源不足集群的风险（**Pod Pending**）。 -- 高估：将 TaskManager 配置应用于所有副本 → 估计 **8 个 CPU** 总量（实际需要 7 个）→ 浪费资源并限制集群选择。 -- 配额计算不准确：FederatedResourceQuota 显示错误的使用情况。 - -使用多组件调度，调度器能够准确理解： -- 所需的总资源：(1 × 1 CPU + 1 × 2Gi) + (3 × 2 CPU + 3 × 4Gi) = 7 CPU 和 14Gi 内存 -- 每个组件的具体需求 -- 集群是否能够容纳所有组件 - -## 支持的工作负载类型 - -多组件调度功能专为具有多个异构 Pod 模板的 CRD 设计。常见用例包括： - -| 类别 | 示例 | -|----------|----------| -| 流处理 | Flink、Kafka Streams、Apache Storm | -| AI/ML 框架 | Ray、TensorFlow、PyTorch、MXNet | -| 机器学习训练 | 参数服务器、分布式训练作业 | -| 批处理 | Spark、Volcano、Hadoop | -| 数据处理 | XGBoost、PaddlePaddle、分布式数据库 | -| 分布式系统 | Elasticsearch、Redis Cluster、数据库集群 | - -Karmada 为流行的 CRD 提供了内置的解释器支持。您可以在[资源解释器文档](../globalview/customizing-resource-interpreter)中找到具有内置解释器支持的 CRD 列表。对于新的 CRD 类型或自定义工作负载，您可以实现自定义解释器（参见[自定义资源解释器](../globalview/customizing-resource-interpreter)）或[联系 Karmada 社区](https://github.com/karmada-io/karmada?tab=readme-ov-file#contact)获取支持。 - -## 功能成熟度和要求 - -多组件调度功能目前处于 **Alpha** 阶段，从 Karmada v1.16 开始提供。作为 Alpha 功能，它在未来版本中可能会发生变化，但核心调度功能已完全可用，可用于评估和测试环境。 - -要使用多组件调度功能，您必须启用 `MultiplePodTemplatesScheduling` 特性门控。该特性门控必须在以下组件上启用： - -- `karmada-controller-manager`：负责解释多组件工作负载规格并在 ResourceBinding 对象中填充组件信息。 -- `karmada-scheduler`：负责基于控制器提取的组件资源需求进行调度决策。 -- `karmada-webhook`：负责验证从资源模板解析的组件信息。 - -## 工作原理 - -下图展示了多组件调度的过程，以 FlinkDeployment 为例。相同的工作流程也适用于其他多组件应用程序，如 RayCluster、TensorFlow 集群和其他分布式系统。 - -![Multi-Component Scheduling Architecture](./../../resources/userguide/scheduling/multi-component-scheduling.png) - -上图显示了调度工作流程： - -1. 多组件应用程序（例如 FlinkDeployment、RayCluster）被提交到 Karmada API Server。需要提供 `PropagationPolicy` 或 `ClusterPropagationPolicy` 来指定工作负载应如何在成员集群之间分发。 - -2. Karmada 控制器利用资源解释器来解析每个组件的资源需求。这些需求存储在 ResourceBinding 对象的 `spec.components` 字段中。 - -3. 调度器基于每个组件逐个评估候选集群，而不是简单地按总资源求和。例如，它检查集群是否可以容纳 JobManager，然后检查同一集群是否也可以容纳所有 TaskManager。这种方法更好地考虑了集群节点之间的资源分布和碎片化。 - -4. 调度器选择可以满足所有组件需求的集群。然后将所有组件作为单个单元调度到该集群。 - -## 限制和约束 - -目前，多组件调度功能具有以下限制： -- 工作负载的所有组件必须调度到同一个集群 -- 尚不支持跨集群组件分发 - -多组件工作负载通常在组件之间存在紧密耦合（共享存储、网络连接、同步需求）。将组件分发到不同集群会在资源管理、故障处理和性能优化方面带来显著的复杂性。 - -我们认识到，将组件分发到不同集群是更好地利用多集群资源的自然演进。这种方法可以实现更灵活的资源分配和提高基础设施的利用率。但是，支持这一点需要： -- 用户定义明确的拆分规则和策略，以确保组件被适当放置 -- 依赖关系和亲和性规范，以防止导致调度成功但无法运行的不兼容放置 - -我们欢迎有关跨集群组件分发的用户反馈和用例。如果您有特定的需求或场景，请随时[联系我们](https://github.com/karmada-io/karmada?tab=readme-ov-file#contact)。 - -## 下一步 - -- [自定义资源解释器](../globalview/customizing-resource-interpreter) - 为您的 CRD 实现解释器 -- [调度器评估器](./scheduler-estimator) - 启用资源感知调度 -- [分发策略](./propagation-policy) - 将资源分发到集群的基础知识 -- [集群资源](./cluster-resources) - 理解集群资源建模 +--- +title: 调度多组件工作负载 +--- + +## 概述 + +许多现代分布式应用程序由具有异构资源需求的多个组件组成。例如，`Flink 集群`包含 `JobManager` 和 `TaskManager` 组件，而 `Ray 集群`则包含 `Head` 和 `Worker` 节点。每个组件通常具有不同的副本数和资源规格。 + +从 Karmada v1.16 开始，`多 Pod 模板调度`功能为这些复杂工作负载提供了精确的资源感知调度能力。这确保了 Karmada 能够正确理解多组件应用程序的总资源需求，并在成员集群之间做出明智的调度决策。 + +## 为什么需要多组件调度？ + +在 v1.16 之前，Karmada 调度器假设工作负载中的所有副本都是相同的，使用单一的 Pod 模板来表示资源需求。这种假设对于 Deployment 等简单应用程序效果良好，但对于多组件工作负载则会导致不准确的情况。 + +考虑一个具有两个组件的 FlinkDeployment： +- JobManager：1 个副本，需要 1 CPU 和 2Gi 内存 +- TaskManager：3 个副本，每个需要 2 CPU 和 4Gi 内存 + +使用传统调度，调度器只能表示一个组件的需求，导致： +- 低估：将 JobManager 配置应用于所有副本 → 仅计算 **4 个 CPU** 总量（实际需要 7 个）→ 存在调度到资源不足集群的风险（**Pod Pending**）。 +- 高估：将 TaskManager 配置应用于所有副本 → 估计 **8 个 CPU** 总量（实际需要 7 个）→ 浪费资源并限制集群选择。 +- 配额计算不准确：FederatedResourceQuota 显示错误的使用情况。 + +使用多组件调度，调度器能够准确理解： +- 所需的总资源：(1 × 1 CPU + 1 × 2Gi) + (3 × 2 CPU + 3 × 4Gi) = 7 CPU 和 14Gi 内存 +- 每个组件的具体需求 +- 集群是否能够容纳所有组件 + +## 支持的工作负载类型 + +多组件调度功能专为具有多个异构 Pod 模板的 CRD 设计。常见用例包括： + +| 类别 | 示例 | +|----------|----------| +| 流处理 | Flink、Kafka Streams、Apache Storm | +| AI/ML 框架 | Ray、TensorFlow、PyTorch、MXNet | +| 机器学习训练 | 参数服务器、分布式训练作业 | +| 批处理 | Spark、Volcano、Hadoop | +| 数据处理 | XGBoost、PaddlePaddle、分布式数据库 | +| 分布式系统 | Elasticsearch、Redis Cluster、数据库集群 | + +Karmada 为流行的 CRD 提供了内置的解释器支持。您可以在[资源解释器文档](../globalview/customizing-resource-interpreter)中找到具有内置解释器支持的 CRD 列表。对于新的 CRD 类型或自定义工作负载，您可以实现自定义解释器（参见[自定义资源解释器](../globalview/customizing-resource-interpreter)）或[联系 Karmada 社区](https://github.com/karmada-io/karmada?tab=readme-ov-file#contact)获取支持。 + +## 功能成熟度和要求 + +多组件调度功能目前处于 **Alpha** 阶段，从 Karmada v1.16 开始提供。作为 Alpha 功能，它在未来版本中可能会发生变化，但核心调度功能已完全可用，可用于评估和测试环境。 + +要使用多组件调度功能，您必须启用 `MultiplePodTemplatesScheduling` 特性门控。该特性门控必须在以下组件上启用： + +- `karmada-controller-manager`：负责解释多组件工作负载规格并在 ResourceBinding 对象中填充组件信息。 +- `karmada-scheduler`：负责基于控制器提取的组件资源需求进行调度决策。 +- `karmada-webhook`：负责验证从资源模板解析的组件信息。 + +## 工作原理 + +下图展示了多组件调度的过程，以 FlinkDeployment 为例。相同的工作流程也适用于其他多组件应用程序，如 RayCluster、TensorFlow 集群和其他分布式系统。 + +![Multi-Component Scheduling Architecture](./../../resources/userguide/scheduling/multi-component-scheduling.png) + +上图显示了调度工作流程： + +1. 多组件应用程序（例如 FlinkDeployment、RayCluster）被提交到 Karmada API Server。需要提供 `PropagationPolicy` 或 `ClusterPropagationPolicy` 来指定工作负载应如何在成员集群之间分发。 + +2. Karmada 控制器利用资源解释器来解析每个组件的资源需求。这些需求存储在 ResourceBinding 对象的 `spec.components` 字段中。 + +3. 调度器基于每个组件逐个评估候选集群，而不是简单地按总资源求和。例如，它检查集群是否可以容纳 JobManager，然后检查同一集群是否也可以容纳所有 TaskManager。这种方法更好地考虑了集群节点之间的资源分布和碎片化。 + +4. 调度器选择可以满足所有组件需求的集群。然后将所有组件作为单个单元调度到该集群。 + +## 限制和约束 + +目前，多组件调度功能具有以下限制： +- 工作负载的所有组件必须调度到同一个集群 +- 尚不支持跨集群组件分发 + +多组件工作负载通常在组件之间存在紧密耦合（共享存储、网络连接、同步需求）。将组件分发到不同集群会在资源管理、故障处理和性能优化方面带来显著的复杂性。 + +我们认识到，将组件分发到不同集群是更好地利用多集群资源的自然演进。这种方法可以实现更灵活的资源分配和提高基础设施的利用率。但是，支持这一点需要： +- 用户定义明确的拆分规则和策略，以确保组件被适当放置 +- 依赖关系和亲和性规范，以防止导致调度成功但无法运行的不兼容放置 + +我们欢迎有关跨集群组件分发的用户反馈和用例。如果您有特定的需求或场景，请随时[联系我们](https://github.com/karmada-io/karmada?tab=readme-ov-file#contact)。 + +## 下一步 + +- [自定义资源解释器](../globalview/customizing-resource-interpreter) - 为您的 CRD 实现解释器 +- [调度器评估器](./scheduler-estimator) - 启用资源感知调度 +- [分发策略](./propagation-policy) - 将资源分发到集群的基础知识 +- [集群资源](./cluster-resources) - 理解集群资源建模 diff --git a/i18n/zh/docusaurus-plugin-content-docs/version-v1.13/administrator/upgrading/v1.11-v1.12.md b/i18n/zh/docusaurus-plugin-content-docs/version-v1.13/administrator/upgrading/v1.11-v1.12.md index 6331f4933..81947e71b 100644 --- a/i18n/zh/docusaurus-plugin-content-docs/version-v1.13/administrator/upgrading/v1.11-v1.12.md +++ b/i18n/zh/docusaurus-plugin-content-docs/version-v1.13/administrator/upgrading/v1.11-v1.12.md @@ -1,45 +1,45 @@ ---- -title: v1.11 升级到 v1.12 ---- - -遵循[常规升级流程](./README.md)。 - -## 升级后显著变化 - -### API 变化 - -- 在 `Karmada` API 中引入了 `SecretRef`，作为连接外部 etcd 集群的配置，可用于指定包含了连接外部 etcd 集群凭证的 secret。 -- 在 `Karmada` API 中引入了 `extraVolumes` 和 `extraVolumemounts` ，以便为 Karmada API server组件指定额外的卷和卷挂载。 -- 在 `Karmada` API中引入了 `ApiServerService` 字段，作为 Karmada 实例状态的一部分，该字段可用于引用该实例的 API Server 服务。这对于需要发现Karmada 实例的 API Server 服务以执行如设置入口流量等任务的高级操作员来说非常有用。 -- 在`Karmada` API中引入了`CustomCertificate.ApiServerCACert`字段，用于指定包含 Karmada API Server 自定义 CA 证书的secret。 -- 在`Karmada` API中，Karmada API server的 ServiceType 现在被限制为`ClusterIP`、`NodePort`和`LoadBalancer`。 -- 在`Cluster` API中引入了一个新的条件`CompleteAPIEnablements`，用于表示API集合的状态。 -- 在`PropagationPolicy`和`ClusterPropagationPolicy` API中引入了`PreserveResourcesOnDeletion`字段，该字段提供了安全回滚迁移的能力。 -- 在`OverridePolicy`和`ClusterOverridePolicy`中引入了`FieldOverrider`，它提供了覆盖如 ConfigMap 或 Secret 等清单中嵌套的结构化数据的能力。 -- 在`ResourceBinding`和`ClusterResourceBinding` API的`GracefulEvictionTask`中引入了`PurgeMode`。 -- 在`PropagationPolicy`中引入了`StatePreservation`，它将在应用故障迁移场景中保存状态。 - -### 弃用 - -- 在`Karmada` API中，`ExternalEtcd.CAData`、`ExternalEtcd.CertData`和`ExternalEtcd.KeyData`已被弃用，并将在未来的版本中移除。请使用 `SecretRef` 来提供客户端连接凭证。 -- 在版本`v1.11.0`中已弃用的以下启动参数现在已被移除： - * `karmada-agent`: - * --bind-address - * --secure-port - * `karmada-controller-manager`: - * --bind-address - * --secure-port - * `karmada-scheduler-estimator`: - * --bind-address - * --secure-port - * `karmada-scheduler`: - * --bind-address - * --secure-port - * `karmada-descheduler`: - * --bind-address - * --secure-port - -### karmada-controller-manager - -- 引入了特性门控`StatefulFailoverInjection`，用于控制 Karmada 在有状态应用的故障转移期间是否收集和注入状态信息。 +--- +title: v1.11 升级到 v1.12 +--- + +遵循[常规升级流程](./README.md)。 + +## 升级后显著变化 + +### API 变化 + +- 在 `Karmada` API 中引入了 `SecretRef`，作为连接外部 etcd 集群的配置，可用于指定包含了连接外部 etcd 集群凭证的 secret。 +- 在 `Karmada` API 中引入了 `extraVolumes` 和 `extraVolumemounts` ，以便为 Karmada API server组件指定额外的卷和卷挂载。 +- 在 `Karmada` API中引入了 `ApiServerService` 字段，作为 Karmada 实例状态的一部分，该字段可用于引用该实例的 API Server 服务。这对于需要发现Karmada 实例的 API Server 服务以执行如设置入口流量等任务的高级操作员来说非常有用。 +- 在`Karmada` API中引入了`CustomCertificate.ApiServerCACert`字段，用于指定包含 Karmada API Server 自定义 CA 证书的secret。 +- 在`Karmada` API中，Karmada API server的 ServiceType 现在被限制为`ClusterIP`、`NodePort`和`LoadBalancer`。 +- 在`Cluster` API中引入了一个新的条件`CompleteAPIEnablements`，用于表示API集合的状态。 +- 在`PropagationPolicy`和`ClusterPropagationPolicy` API中引入了`PreserveResourcesOnDeletion`字段，该字段提供了安全回滚迁移的能力。 +- 在`OverridePolicy`和`ClusterOverridePolicy`中引入了`FieldOverrider`，它提供了覆盖如 ConfigMap 或 Secret 等清单中嵌套的结构化数据的能力。 +- 在`ResourceBinding`和`ClusterResourceBinding` API的`GracefulEvictionTask`中引入了`PurgeMode`。 +- 在`PropagationPolicy`中引入了`StatePreservation`，它将在应用故障迁移场景中保存状态。 + +### 弃用 + +- 在`Karmada` API中，`ExternalEtcd.CAData`、`ExternalEtcd.CertData`和`ExternalEtcd.KeyData`已被弃用，并将在未来的版本中移除。请使用 `SecretRef` 来提供客户端连接凭证。 +- 在版本`v1.11.0`中已弃用的以下启动参数现在已被移除： + * `karmada-agent`: + * --bind-address + * --secure-port + * `karmada-controller-manager`: + * --bind-address + * --secure-port + * `karmada-scheduler-estimator`: + * --bind-address + * --secure-port + * `karmada-scheduler`: + * --bind-address + * --secure-port + * `karmada-descheduler`: + * --bind-address + * --secure-port + +### karmada-controller-manager + +- 引入了特性门控`StatefulFailoverInjection`，用于控制 Karmada 在有状态应用的故障转移期间是否收集和注入状态信息。 - 特性`Failover`现在默认已禁用，需要显式启用以避免意外事件。 \ No newline at end of file diff --git a/i18n/zh/docusaurus-plugin-content-docs/version-v1.14/administrator/compatibility/compatibility.md b/i18n/zh/docusaurus-plugin-content-docs/version-v1.14/administrator/compatibility/compatibility.md index a1a4dfb64..d5bc3b8e1 100644 --- a/i18n/zh/docusaurus-plugin-content-docs/version-v1.14/administrator/compatibility/compatibility.md +++ b/i18n/zh/docusaurus-plugin-content-docs/version-v1.14/administrator/compatibility/compatibility.md @@ -1,60 +1,60 @@ ---- -title: Kubernetes 兼容性 ---- - -本文档全面阐述了 Karmada 与 Kubernetes 版本的兼容性，主要从两个维度进行说明： -- Karmada 控制平面 API 支持：支持哪些 API？ -- Kubernetes 版本支持：支持哪些 Kubernetes 版本？ - -本文档帮助管理员理解 Karmada 如何管理混合 Kubernetes 版本集群间的资源。通过遵循各集群的 API 能力确保安全分发，并提供在升级或迁移过程中维护 -兼容性的指导原则。 - -## Karmada 控制平面 API 支持 - -Karmada 支持其使用的 kube-apiserver 版本中所有可用的 Kubernetes API。例如，如 Karmada APIServer 使用 kube-apiserver@v1.32， -则继承支持 Kubernetes v1.32 中所有 API（如 Deployment、Service、Ingress）及 API 版本（如 apps/v1、networking.k8s.io/v1）。 - -除原生 Kubernetes API 外，Karmada 可通过以下与 Kubernetes 相同的扩展机制增强能力： -- **CRD 扩展**：大多数 Karmada 特有 API（如 PropagationPolicy、OverridePolicy）通过 CRD 实现。用户也可在 Karmada 中定义自定义 CRD，并像原生 Kubernetes API 一样分发到成员集群。 -- **聚合 APIServer**：Karmada 的 Cluster API 通过 karmada-aggregated-apiserver 扩展，用户可直接通过 Karmada 统一 API 端点查询成员集群资源（如 Nodes、Pods）。 - 用户可以通过与扩展 Kubernetes 相同的方式扩展 Karmada 的 API 能力，无论是自定义资源还是第三方集成。 - -要查看所有支持的 API，请对 Karmada 执行 `karmadactl api-resources` 命令，该命令会列出包括 Kubernetes API 和扩展 API 在内的所有支持API，输出示例如下： -``` -# karmadactl api-resources -NAME SHORTNAMES APIVERSION NAMESPACED KIND -pods po v1 true Pod -deployments deploy apps/v1 true Deployment -clusters cluster.karmada.io/v1alpha1 false Cluster -overridepolicies op policy.karmada.io/v1alpha1 true OverridePolicy -propagationpolicies pp policy.karmada.io/v1alpha1 true PropagationPolicy -... -``` - -## Kubernetes 版本支持 - -Karmada 使用最小化的稳定 API 和端点管理 Kubernetes 集群，确保广泛的 Kubernetes 版本兼容性。每个 Karmada 版本集成最新的 Kubernetes 客户端， -并测试最近 10 个 Kubernetes 版本的兼容性。例如，Karmada v1.14 使用 Kubernetes 客户端 v1.32，会集成验证 Kubernetes v1.23 至 v1.32 版本。 - -资源仅在 Karmada 和目标集群均支持其 API 时才能被分发： -- 若 Karmada 无法识别 API（如不支持的 CRD 或已弃用的 API），则无法在 Karmada 中创建资源 -- 若成员集群缺少 API（如旧版本集群缺少 networking.k8s.io/v1/Ingress），Karmada 将跳过对该集群的分发 - -## 常见问题解答 - -### 如何选择 Karmada APIServer 版本？ - -Karmada 项目会在其安装工具（如 Karmada Operator）中自动更新默认的 kube-apiserver 版本以支持最新 Kubernetes API。大多数情况下用户无需修改，即使升级 Karmada 时也无需调整。 - -您可能需要升级 Karmada APIServer 的情况包括： -- 采用新 Kubernetes API：需要利用新版 Kubernetes 特性 -- 修复 CVE 漏洞：解决旧版本存在的安全隐患 - -注意升级需谨慎操作： -- 检查 API 弃用情况：确保工作负载使用的资源类型在目标 Kubernetes 版本中未被弃用 -- 逐步升级：始终逐个次版本升级（如 kube-apiserver@v1.32 → v1.33），避免跨版本升级（如 v1.32 → v1.34）。Kubernetes 依赖渐进式 API 弃用和自动转换机制来安全迁移弃用 API。 - -### 如何处理版本跨度大的成员集群？ - -当成员集群存在 API 版本不兼容时（如部分支持 networking.k8s.io/v1，部分仅支持 v1beta1），目前 Karmada 不会根据成员集群能力自动转换 API 版本。 -建议将过时集群升级至新 Kubernetes 版本。 +--- +title: Kubernetes 兼容性 +--- + +本文档全面阐述了 Karmada 与 Kubernetes 版本的兼容性，主要从两个维度进行说明： +- Karmada 控制平面 API 支持：支持哪些 API？ +- Kubernetes 版本支持：支持哪些 Kubernetes 版本？ + +本文档帮助管理员理解 Karmada 如何管理混合 Kubernetes 版本集群间的资源。通过遵循各集群的 API 能力确保安全分发，并提供在升级或迁移过程中维护 +兼容性的指导原则。 + +## Karmada 控制平面 API 支持 + +Karmada 支持其使用的 kube-apiserver 版本中所有可用的 Kubernetes API。例如，如 Karmada APIServer 使用 kube-apiserver@v1.32， +则继承支持 Kubernetes v1.32 中所有 API（如 Deployment、Service、Ingress）及 API 版本（如 apps/v1、networking.k8s.io/v1）。 + +除原生 Kubernetes API 外，Karmada 可通过以下与 Kubernetes 相同的扩展机制增强能力： +- **CRD 扩展**：大多数 Karmada 特有 API（如 PropagationPolicy、OverridePolicy）通过 CRD 实现。用户也可在 Karmada 中定义自定义 CRD，并像原生 Kubernetes API 一样分发到成员集群。 +- **聚合 APIServer**：Karmada 的 Cluster API 通过 karmada-aggregated-apiserver 扩展，用户可直接通过 Karmada 统一 API 端点查询成员集群资源（如 Nodes、Pods）。 + 用户可以通过与扩展 Kubernetes 相同的方式扩展 Karmada 的 API 能力，无论是自定义资源还是第三方集成。 + +要查看所有支持的 API，请对 Karmada 执行 `karmadactl api-resources` 命令，该命令会列出包括 Kubernetes API 和扩展 API 在内的所有支持API，输出示例如下： +``` +# karmadactl api-resources +NAME SHORTNAMES APIVERSION NAMESPACED KIND +pods po v1 true Pod +deployments deploy apps/v1 true Deployment +clusters cluster.karmada.io/v1alpha1 false Cluster +overridepolicies op policy.karmada.io/v1alpha1 true OverridePolicy +propagationpolicies pp policy.karmada.io/v1alpha1 true PropagationPolicy +... +``` + +## Kubernetes 版本支持 + +Karmada 使用最小化的稳定 API 和端点管理 Kubernetes 集群，确保广泛的 Kubernetes 版本兼容性。每个 Karmada 版本集成最新的 Kubernetes 客户端， +并测试最近 10 个 Kubernetes 版本的兼容性。例如，Karmada v1.14 使用 Kubernetes 客户端 v1.32，会集成验证 Kubernetes v1.23 至 v1.32 版本。 + +资源仅在 Karmada 和目标集群均支持其 API 时才能被分发： +- 若 Karmada 无法识别 API（如不支持的 CRD 或已弃用的 API），则无法在 Karmada 中创建资源 +- 若成员集群缺少 API（如旧版本集群缺少 networking.k8s.io/v1/Ingress），Karmada 将跳过对该集群的分发 + +## 常见问题解答 + +### 如何选择 Karmada APIServer 版本？ + +Karmada 项目会在其安装工具（如 Karmada Operator）中自动更新默认的 kube-apiserver 版本以支持最新 Kubernetes API。大多数情况下用户无需修改，即使升级 Karmada 时也无需调整。 + +您可能需要升级 Karmada APIServer 的情况包括： +- 采用新 Kubernetes API：需要利用新版 Kubernetes 特性 +- 修复 CVE 漏洞：解决旧版本存在的安全隐患 + +注意升级需谨慎操作： +- 检查 API 弃用情况：确保工作负载使用的资源类型在目标 Kubernetes 版本中未被弃用 +- 逐步升级：始终逐个次版本升级（如 kube-apiserver@v1.32 → v1.33），避免跨版本升级（如 v1.32 → v1.34）。Kubernetes 依赖渐进式 API 弃用和自动转换机制来安全迁移弃用 API。 + +### 如何处理版本跨度大的成员集群？ + +当成员集群存在 API 版本不兼容时（如部分支持 networking.k8s.io/v1，部分仅支持 v1beta1），目前 Karmada 不会根据成员集群能力自动转换 API 版本。 +建议将过时集群升级至新 Kubernetes 版本。 diff --git a/i18n/zh/docusaurus-plugin-content-docs/version-v1.14/administrator/upgrading/v1.11-v1.12.md b/i18n/zh/docusaurus-plugin-content-docs/version-v1.14/administrator/upgrading/v1.11-v1.12.md index 6331f4933..81947e71b 100644 --- a/i18n/zh/docusaurus-plugin-content-docs/version-v1.14/administrator/upgrading/v1.11-v1.12.md +++ b/i18n/zh/docusaurus-plugin-content-docs/version-v1.14/administrator/upgrading/v1.11-v1.12.md @@ -1,45 +1,45 @@ ---- -title: v1.11 升级到 v1.12 ---- - -遵循[常规升级流程](./README.md)。 - -## 升级后显著变化 - -### API 变化 - -- 在 `Karmada` API 中引入了 `SecretRef`，作为连接外部 etcd 集群的配置，可用于指定包含了连接外部 etcd 集群凭证的 secret。 -- 在 `Karmada` API 中引入了 `extraVolumes` 和 `extraVolumemounts` ，以便为 Karmada API server组件指定额外的卷和卷挂载。 -- 在 `Karmada` API中引入了 `ApiServerService` 字段，作为 Karmada 实例状态的一部分，该字段可用于引用该实例的 API Server 服务。这对于需要发现Karmada 实例的 API Server 服务以执行如设置入口流量等任务的高级操作员来说非常有用。 -- 在`Karmada` API中引入了`CustomCertificate.ApiServerCACert`字段，用于指定包含 Karmada API Server 自定义 CA 证书的secret。 -- 在`Karmada` API中，Karmada API server的 ServiceType 现在被限制为`ClusterIP`、`NodePort`和`LoadBalancer`。 -- 在`Cluster` API中引入了一个新的条件`CompleteAPIEnablements`，用于表示API集合的状态。 -- 在`PropagationPolicy`和`ClusterPropagationPolicy` API中引入了`PreserveResourcesOnDeletion`字段，该字段提供了安全回滚迁移的能力。 -- 在`OverridePolicy`和`ClusterOverridePolicy`中引入了`FieldOverrider`，它提供了覆盖如 ConfigMap 或 Secret 等清单中嵌套的结构化数据的能力。 -- 在`ResourceBinding`和`ClusterResourceBinding` API的`GracefulEvictionTask`中引入了`PurgeMode`。 -- 在`PropagationPolicy`中引入了`StatePreservation`，它将在应用故障迁移场景中保存状态。 - -### 弃用 - -- 在`Karmada` API中，`ExternalEtcd.CAData`、`ExternalEtcd.CertData`和`ExternalEtcd.KeyData`已被弃用，并将在未来的版本中移除。请使用 `SecretRef` 来提供客户端连接凭证。 -- 在版本`v1.11.0`中已弃用的以下启动参数现在已被移除： - * `karmada-agent`: - * --bind-address - * --secure-port - * `karmada-controller-manager`: - * --bind-address - * --secure-port - * `karmada-scheduler-estimator`: - * --bind-address - * --secure-port - * `karmada-scheduler`: - * --bind-address - * --secure-port - * `karmada-descheduler`: - * --bind-address - * --secure-port - -### karmada-controller-manager - -- 引入了特性门控`StatefulFailoverInjection`，用于控制 Karmada 在有状态应用的故障转移期间是否收集和注入状态信息。 +--- +title: v1.11 升级到 v1.12 +--- + +遵循[常规升级流程](./README.md)。 + +## 升级后显著变化 + +### API 变化 + +- 在 `Karmada` API 中引入了 `SecretRef`，作为连接外部 etcd 集群的配置，可用于指定包含了连接外部 etcd 集群凭证的 secret。 +- 在 `Karmada` API 中引入了 `extraVolumes` 和 `extraVolumemounts` ，以便为 Karmada API server组件指定额外的卷和卷挂载。 +- 在 `Karmada` API中引入了 `ApiServerService` 字段，作为 Karmada 实例状态的一部分，该字段可用于引用该实例的 API Server 服务。这对于需要发现Karmada 实例的 API Server 服务以执行如设置入口流量等任务的高级操作员来说非常有用。 +- 在`Karmada` API中引入了`CustomCertificate.ApiServerCACert`字段，用于指定包含 Karmada API Server 自定义 CA 证书的secret。 +- 在`Karmada` API中，Karmada API server的 ServiceType 现在被限制为`ClusterIP`、`NodePort`和`LoadBalancer`。 +- 在`Cluster` API中引入了一个新的条件`CompleteAPIEnablements`，用于表示API集合的状态。 +- 在`PropagationPolicy`和`ClusterPropagationPolicy` API中引入了`PreserveResourcesOnDeletion`字段，该字段提供了安全回滚迁移的能力。 +- 在`OverridePolicy`和`ClusterOverridePolicy`中引入了`FieldOverrider`，它提供了覆盖如 ConfigMap 或 Secret 等清单中嵌套的结构化数据的能力。 +- 在`ResourceBinding`和`ClusterResourceBinding` API的`GracefulEvictionTask`中引入了`PurgeMode`。 +- 在`PropagationPolicy`中引入了`StatePreservation`，它将在应用故障迁移场景中保存状态。 + +### 弃用 + +- 在`Karmada` API中，`ExternalEtcd.CAData`、`ExternalEtcd.CertData`和`ExternalEtcd.KeyData`已被弃用，并将在未来的版本中移除。请使用 `SecretRef` 来提供客户端连接凭证。 +- 在版本`v1.11.0`中已弃用的以下启动参数现在已被移除： + * `karmada-agent`: + * --bind-address + * --secure-port + * `karmada-controller-manager`: + * --bind-address + * --secure-port + * `karmada-scheduler-estimator`: + * --bind-address + * --secure-port + * `karmada-scheduler`: + * --bind-address + * --secure-port + * `karmada-descheduler`: + * --bind-address + * --secure-port + +### karmada-controller-manager + +- 引入了特性门控`StatefulFailoverInjection`，用于控制 Karmada 在有状态应用的故障转移期间是否收集和注入状态信息。 - 特性`Failover`现在默认已禁用，需要显式启用以避免意外事件。 \ No newline at end of file diff --git a/i18n/zh/docusaurus-plugin-content-docs/version-v1.15/administrator/compatibility/compatibility.md b/i18n/zh/docusaurus-plugin-content-docs/version-v1.15/administrator/compatibility/compatibility.md index a1a4dfb64..d5bc3b8e1 100644 --- a/i18n/zh/docusaurus-plugin-content-docs/version-v1.15/administrator/compatibility/compatibility.md +++ b/i18n/zh/docusaurus-plugin-content-docs/version-v1.15/administrator/compatibility/compatibility.md @@ -1,60 +1,60 @@ ---- -title: Kubernetes 兼容性 ---- - -本文档全面阐述了 Karmada 与 Kubernetes 版本的兼容性，主要从两个维度进行说明： -- Karmada 控制平面 API 支持：支持哪些 API？ -- Kubernetes 版本支持：支持哪些 Kubernetes 版本？ - -本文档帮助管理员理解 Karmada 如何管理混合 Kubernetes 版本集群间的资源。通过遵循各集群的 API 能力确保安全分发，并提供在升级或迁移过程中维护 -兼容性的指导原则。 - -## Karmada 控制平面 API 支持 - -Karmada 支持其使用的 kube-apiserver 版本中所有可用的 Kubernetes API。例如，如 Karmada APIServer 使用 kube-apiserver@v1.32， -则继承支持 Kubernetes v1.32 中所有 API（如 Deployment、Service、Ingress）及 API 版本（如 apps/v1、networking.k8s.io/v1）。 - -除原生 Kubernetes API 外，Karmada 可通过以下与 Kubernetes 相同的扩展机制增强能力： -- **CRD 扩展**：大多数 Karmada 特有 API（如 PropagationPolicy、OverridePolicy）通过 CRD 实现。用户也可在 Karmada 中定义自定义 CRD，并像原生 Kubernetes API 一样分发到成员集群。 -- **聚合 APIServer**：Karmada 的 Cluster API 通过 karmada-aggregated-apiserver 扩展，用户可直接通过 Karmada 统一 API 端点查询成员集群资源（如 Nodes、Pods）。 - 用户可以通过与扩展 Kubernetes 相同的方式扩展 Karmada 的 API 能力，无论是自定义资源还是第三方集成。 - -要查看所有支持的 API，请对 Karmada 执行 `karmadactl api-resources` 命令，该命令会列出包括 Kubernetes API 和扩展 API 在内的所有支持API，输出示例如下： -``` -# karmadactl api-resources -NAME SHORTNAMES APIVERSION NAMESPACED KIND -pods po v1 true Pod -deployments deploy apps/v1 true Deployment -clusters cluster.karmada.io/v1alpha1 false Cluster -overridepolicies op policy.karmada.io/v1alpha1 true OverridePolicy -propagationpolicies pp policy.karmada.io/v1alpha1 true PropagationPolicy -... -``` - -## Kubernetes 版本支持 - -Karmada 使用最小化的稳定 API 和端点管理 Kubernetes 集群，确保广泛的 Kubernetes 版本兼容性。每个 Karmada 版本集成最新的 Kubernetes 客户端， -并测试最近 10 个 Kubernetes 版本的兼容性。例如，Karmada v1.14 使用 Kubernetes 客户端 v1.32，会集成验证 Kubernetes v1.23 至 v1.32 版本。 - -资源仅在 Karmada 和目标集群均支持其 API 时才能被分发： -- 若 Karmada 无法识别 API（如不支持的 CRD 或已弃用的 API），则无法在 Karmada 中创建资源 -- 若成员集群缺少 API（如旧版本集群缺少 networking.k8s.io/v1/Ingress），Karmada 将跳过对该集群的分发 - -## 常见问题解答 - -### 如何选择 Karmada APIServer 版本？ - -Karmada 项目会在其安装工具（如 Karmada Operator）中自动更新默认的 kube-apiserver 版本以支持最新 Kubernetes API。大多数情况下用户无需修改，即使升级 Karmada 时也无需调整。 - -您可能需要升级 Karmada APIServer 的情况包括： -- 采用新 Kubernetes API：需要利用新版 Kubernetes 特性 -- 修复 CVE 漏洞：解决旧版本存在的安全隐患 - -注意升级需谨慎操作： -- 检查 API 弃用情况：确保工作负载使用的资源类型在目标 Kubernetes 版本中未被弃用 -- 逐步升级：始终逐个次版本升级（如 kube-apiserver@v1.32 → v1.33），避免跨版本升级（如 v1.32 → v1.34）。Kubernetes 依赖渐进式 API 弃用和自动转换机制来安全迁移弃用 API。 - -### 如何处理版本跨度大的成员集群？ - -当成员集群存在 API 版本不兼容时（如部分支持 networking.k8s.io/v1，部分仅支持 v1beta1），目前 Karmada 不会根据成员集群能力自动转换 API 版本。 -建议将过时集群升级至新 Kubernetes 版本。 +--- +title: Kubernetes 兼容性 +--- + +本文档全面阐述了 Karmada 与 Kubernetes 版本的兼容性，主要从两个维度进行说明： +- Karmada 控制平面 API 支持：支持哪些 API？ +- Kubernetes 版本支持：支持哪些 Kubernetes 版本？ + +本文档帮助管理员理解 Karmada 如何管理混合 Kubernetes 版本集群间的资源。通过遵循各集群的 API 能力确保安全分发，并提供在升级或迁移过程中维护 +兼容性的指导原则。 + +## Karmada 控制平面 API 支持 + +Karmada 支持其使用的 kube-apiserver 版本中所有可用的 Kubernetes API。例如，如 Karmada APIServer 使用 kube-apiserver@v1.32， +则继承支持 Kubernetes v1.32 中所有 API（如 Deployment、Service、Ingress）及 API 版本（如 apps/v1、networking.k8s.io/v1）。 + +除原生 Kubernetes API 外，Karmada 可通过以下与 Kubernetes 相同的扩展机制增强能力： +- **CRD 扩展**：大多数 Karmada 特有 API（如 PropagationPolicy、OverridePolicy）通过 CRD 实现。用户也可在 Karmada 中定义自定义 CRD，并像原生 Kubernetes API 一样分发到成员集群。 +- **聚合 APIServer**：Karmada 的 Cluster API 通过 karmada-aggregated-apiserver 扩展，用户可直接通过 Karmada 统一 API 端点查询成员集群资源（如 Nodes、Pods）。 + 用户可以通过与扩展 Kubernetes 相同的方式扩展 Karmada 的 API 能力，无论是自定义资源还是第三方集成。 + +要查看所有支持的 API，请对 Karmada 执行 `karmadactl api-resources` 命令，该命令会列出包括 Kubernetes API 和扩展 API 在内的所有支持API，输出示例如下： +``` +# karmadactl api-resources +NAME SHORTNAMES APIVERSION NAMESPACED KIND +pods po v1 true Pod +deployments deploy apps/v1 true Deployment +clusters cluster.karmada.io/v1alpha1 false Cluster +overridepolicies op policy.karmada.io/v1alpha1 true OverridePolicy +propagationpolicies pp policy.karmada.io/v1alpha1 true PropagationPolicy +... +``` + +## Kubernetes 版本支持 + +Karmada 使用最小化的稳定 API 和端点管理 Kubernetes 集群，确保广泛的 Kubernetes 版本兼容性。每个 Karmada 版本集成最新的 Kubernetes 客户端， +并测试最近 10 个 Kubernetes 版本的兼容性。例如，Karmada v1.14 使用 Kubernetes 客户端 v1.32，会集成验证 Kubernetes v1.23 至 v1.32 版本。 + +资源仅在 Karmada 和目标集群均支持其 API 时才能被分发： +- 若 Karmada 无法识别 API（如不支持的 CRD 或已弃用的 API），则无法在 Karmada 中创建资源 +- 若成员集群缺少 API（如旧版本集群缺少 networking.k8s.io/v1/Ingress），Karmada 将跳过对该集群的分发 + +## 常见问题解答 + +### 如何选择 Karmada APIServer 版本？ + +Karmada 项目会在其安装工具（如 Karmada Operator）中自动更新默认的 kube-apiserver 版本以支持最新 Kubernetes API。大多数情况下用户无需修改，即使升级 Karmada 时也无需调整。 + +您可能需要升级 Karmada APIServer 的情况包括： +- 采用新 Kubernetes API：需要利用新版 Kubernetes 特性 +- 修复 CVE 漏洞：解决旧版本存在的安全隐患 + +注意升级需谨慎操作： +- 检查 API 弃用情况：确保工作负载使用的资源类型在目标 Kubernetes 版本中未被弃用 +- 逐步升级：始终逐个次版本升级（如 kube-apiserver@v1.32 → v1.33），避免跨版本升级（如 v1.32 → v1.34）。Kubernetes 依赖渐进式 API 弃用和自动转换机制来安全迁移弃用 API。 + +### 如何处理版本跨度大的成员集群？ + +当成员集群存在 API 版本不兼容时（如部分支持 networking.k8s.io/v1，部分仅支持 v1beta1），目前 Karmada 不会根据成员集群能力自动转换 API 版本。 +建议将过时集群升级至新 Kubernetes 版本。 diff --git a/i18n/zh/docusaurus-plugin-content-docs/version-v1.15/administrator/upgrading/v1.11-v1.12.md b/i18n/zh/docusaurus-plugin-content-docs/version-v1.15/administrator/upgrading/v1.11-v1.12.md index 6331f4933..81947e71b 100644 --- a/i18n/zh/docusaurus-plugin-content-docs/version-v1.15/administrator/upgrading/v1.11-v1.12.md +++ b/i18n/zh/docusaurus-plugin-content-docs/version-v1.15/administrator/upgrading/v1.11-v1.12.md @@ -1,45 +1,45 @@ ---- -title: v1.11 升级到 v1.12 ---- - -遵循[常规升级流程](./README.md)。 - -## 升级后显著变化 - -### API 变化 - -- 在 `Karmada` API 中引入了 `SecretRef`，作为连接外部 etcd 集群的配置，可用于指定包含了连接外部 etcd 集群凭证的 secret。 -- 在 `Karmada` API 中引入了 `extraVolumes` 和 `extraVolumemounts` ，以便为 Karmada API server组件指定额外的卷和卷挂载。 -- 在 `Karmada` API中引入了 `ApiServerService` 字段，作为 Karmada 实例状态的一部分，该字段可用于引用该实例的 API Server 服务。这对于需要发现Karmada 实例的 API Server 服务以执行如设置入口流量等任务的高级操作员来说非常有用。 -- 在`Karmada` API中引入了`CustomCertificate.ApiServerCACert`字段，用于指定包含 Karmada API Server 自定义 CA 证书的secret。 -- 在`Karmada` API中，Karmada API server的 ServiceType 现在被限制为`ClusterIP`、`NodePort`和`LoadBalancer`。 -- 在`Cluster` API中引入了一个新的条件`CompleteAPIEnablements`，用于表示API集合的状态。 -- 在`PropagationPolicy`和`ClusterPropagationPolicy` API中引入了`PreserveResourcesOnDeletion`字段，该字段提供了安全回滚迁移的能力。 -- 在`OverridePolicy`和`ClusterOverridePolicy`中引入了`FieldOverrider`，它提供了覆盖如 ConfigMap 或 Secret 等清单中嵌套的结构化数据的能力。 -- 在`ResourceBinding`和`ClusterResourceBinding` API的`GracefulEvictionTask`中引入了`PurgeMode`。 -- 在`PropagationPolicy`中引入了`StatePreservation`，它将在应用故障迁移场景中保存状态。 - -### 弃用 - -- 在`Karmada` API中，`ExternalEtcd.CAData`、`ExternalEtcd.CertData`和`ExternalEtcd.KeyData`已被弃用，并将在未来的版本中移除。请使用 `SecretRef` 来提供客户端连接凭证。 -- 在版本`v1.11.0`中已弃用的以下启动参数现在已被移除： - * `karmada-agent`: - * --bind-address - * --secure-port - * `karmada-controller-manager`: - * --bind-address - * --secure-port - * `karmada-scheduler-estimator`: - * --bind-address - * --secure-port - * `karmada-scheduler`: - * --bind-address - * --secure-port - * `karmada-descheduler`: - * --bind-address - * --secure-port - -### karmada-controller-manager - -- 引入了特性门控`StatefulFailoverInjection`，用于控制 Karmada 在有状态应用的故障转移期间是否收集和注入状态信息。 +--- +title: v1.11 升级到 v1.12 +--- + +遵循[常规升级流程](./README.md)。 + +## 升级后显著变化 + +### API 变化 + +- 在 `Karmada` API 中引入了 `SecretRef`，作为连接外部 etcd 集群的配置，可用于指定包含了连接外部 etcd 集群凭证的 secret。 +- 在 `Karmada` API 中引入了 `extraVolumes` 和 `extraVolumemounts` ，以便为 Karmada API server组件指定额外的卷和卷挂载。 +- 在 `Karmada` API中引入了 `ApiServerService` 字段，作为 Karmada 实例状态的一部分，该字段可用于引用该实例的 API Server 服务。这对于需要发现Karmada 实例的 API Server 服务以执行如设置入口流量等任务的高级操作员来说非常有用。 +- 在`Karmada` API中引入了`CustomCertificate.ApiServerCACert`字段，用于指定包含 Karmada API Server 自定义 CA 证书的secret。 +- 在`Karmada` API中，Karmada API server的 ServiceType 现在被限制为`ClusterIP`、`NodePort`和`LoadBalancer`。 +- 在`Cluster` API中引入了一个新的条件`CompleteAPIEnablements`，用于表示API集合的状态。 +- 在`PropagationPolicy`和`ClusterPropagationPolicy` API中引入了`PreserveResourcesOnDeletion`字段，该字段提供了安全回滚迁移的能力。 +- 在`OverridePolicy`和`ClusterOverridePolicy`中引入了`FieldOverrider`，它提供了覆盖如 ConfigMap 或 Secret 等清单中嵌套的结构化数据的能力。 +- 在`ResourceBinding`和`ClusterResourceBinding` API的`GracefulEvictionTask`中引入了`PurgeMode`。 +- 在`PropagationPolicy`中引入了`StatePreservation`，它将在应用故障迁移场景中保存状态。 + +### 弃用 + +- 在`Karmada` API中，`ExternalEtcd.CAData`、`ExternalEtcd.CertData`和`ExternalEtcd.KeyData`已被弃用，并将在未来的版本中移除。请使用 `SecretRef` 来提供客户端连接凭证。 +- 在版本`v1.11.0`中已弃用的以下启动参数现在已被移除： + * `karmada-agent`: + * --bind-address + * --secure-port + * `karmada-controller-manager`: + * --bind-address + * --secure-port + * `karmada-scheduler-estimator`: + * --bind-address + * --secure-port + * `karmada-scheduler`: + * --bind-address + * --secure-port + * `karmada-descheduler`: + * --bind-address + * --secure-port + +### karmada-controller-manager + +- 引入了特性门控`StatefulFailoverInjection`，用于控制 Karmada 在有状态应用的故障转移期间是否收集和注入状态信息。 - 特性`Failover`现在默认已禁用，需要显式启用以避免意外事件。 \ No newline at end of file diff --git a/i18n/zh/docusaurus-plugin-content-docs/version-v1.16/administrator/compatibility/compatibility.md b/i18n/zh/docusaurus-plugin-content-docs/version-v1.16/administrator/compatibility/compatibility.md index a1a4dfb64..d5bc3b8e1 100644 --- a/i18n/zh/docusaurus-plugin-content-docs/version-v1.16/administrator/compatibility/compatibility.md +++ b/i18n/zh/docusaurus-plugin-content-docs/version-v1.16/administrator/compatibility/compatibility.md @@ -1,60 +1,60 @@ ---- -title: Kubernetes 兼容性 ---- - -本文档全面阐述了 Karmada 与 Kubernetes 版本的兼容性，主要从两个维度进行说明： -- Karmada 控制平面 API 支持：支持哪些 API？ -- Kubernetes 版本支持：支持哪些 Kubernetes 版本？ - -本文档帮助管理员理解 Karmada 如何管理混合 Kubernetes 版本集群间的资源。通过遵循各集群的 API 能力确保安全分发，并提供在升级或迁移过程中维护 -兼容性的指导原则。 - -## Karmada 控制平面 API 支持 - -Karmada 支持其使用的 kube-apiserver 版本中所有可用的 Kubernetes API。例如，如 Karmada APIServer 使用 kube-apiserver@v1.32， -则继承支持 Kubernetes v1.32 中所有 API（如 Deployment、Service、Ingress）及 API 版本（如 apps/v1、networking.k8s.io/v1）。 - -除原生 Kubernetes API 外，Karmada 可通过以下与 Kubernetes 相同的扩展机制增强能力： -- **CRD 扩展**：大多数 Karmada 特有 API（如 PropagationPolicy、OverridePolicy）通过 CRD 实现。用户也可在 Karmada 中定义自定义 CRD，并像原生 Kubernetes API 一样分发到成员集群。 -- **聚合 APIServer**：Karmada 的 Cluster API 通过 karmada-aggregated-apiserver 扩展，用户可直接通过 Karmada 统一 API 端点查询成员集群资源（如 Nodes、Pods）。 - 用户可以通过与扩展 Kubernetes 相同的方式扩展 Karmada 的 API 能力，无论是自定义资源还是第三方集成。 - -要查看所有支持的 API，请对 Karmada 执行 `karmadactl api-resources` 命令，该命令会列出包括 Kubernetes API 和扩展 API 在内的所有支持API，输出示例如下： -``` -# karmadactl api-resources -NAME SHORTNAMES APIVERSION NAMESPACED KIND -pods po v1 true Pod -deployments deploy apps/v1 true Deployment -clusters cluster.karmada.io/v1alpha1 false Cluster -overridepolicies op policy.karmada.io/v1alpha1 true OverridePolicy -propagationpolicies pp policy.karmada.io/v1alpha1 true PropagationPolicy -... -``` - -## Kubernetes 版本支持 - -Karmada 使用最小化的稳定 API 和端点管理 Kubernetes 集群，确保广泛的 Kubernetes 版本兼容性。每个 Karmada 版本集成最新的 Kubernetes 客户端， -并测试最近 10 个 Kubernetes 版本的兼容性。例如，Karmada v1.14 使用 Kubernetes 客户端 v1.32，会集成验证 Kubernetes v1.23 至 v1.32 版本。 - -资源仅在 Karmada 和目标集群均支持其 API 时才能被分发： -- 若 Karmada 无法识别 API（如不支持的 CRD 或已弃用的 API），则无法在 Karmada 中创建资源 -- 若成员集群缺少 API（如旧版本集群缺少 networking.k8s.io/v1/Ingress），Karmada 将跳过对该集群的分发 - -## 常见问题解答 - -### 如何选择 Karmada APIServer 版本？ - -Karmada 项目会在其安装工具（如 Karmada Operator）中自动更新默认的 kube-apiserver 版本以支持最新 Kubernetes API。大多数情况下用户无需修改，即使升级 Karmada 时也无需调整。 - -您可能需要升级 Karmada APIServer 的情况包括： -- 采用新 Kubernetes API：需要利用新版 Kubernetes 特性 -- 修复 CVE 漏洞：解决旧版本存在的安全隐患 - -注意升级需谨慎操作： -- 检查 API 弃用情况：确保工作负载使用的资源类型在目标 Kubernetes 版本中未被弃用 -- 逐步升级：始终逐个次版本升级（如 kube-apiserver@v1.32 → v1.33），避免跨版本升级（如 v1.32 → v1.34）。Kubernetes 依赖渐进式 API 弃用和自动转换机制来安全迁移弃用 API。 - -### 如何处理版本跨度大的成员集群？ - -当成员集群存在 API 版本不兼容时（如部分支持 networking.k8s.io/v1，部分仅支持 v1beta1），目前 Karmada 不会根据成员集群能力自动转换 API 版本。 -建议将过时集群升级至新 Kubernetes 版本。 +--- +title: Kubernetes 兼容性 +--- + +本文档全面阐述了 Karmada 与 Kubernetes 版本的兼容性，主要从两个维度进行说明： +- Karmada 控制平面 API 支持：支持哪些 API？ +- Kubernetes 版本支持：支持哪些 Kubernetes 版本？ + +本文档帮助管理员理解 Karmada 如何管理混合 Kubernetes 版本集群间的资源。通过遵循各集群的 API 能力确保安全分发，并提供在升级或迁移过程中维护 +兼容性的指导原则。 + +## Karmada 控制平面 API 支持 + +Karmada 支持其使用的 kube-apiserver 版本中所有可用的 Kubernetes API。例如，如 Karmada APIServer 使用 kube-apiserver@v1.32， +则继承支持 Kubernetes v1.32 中所有 API（如 Deployment、Service、Ingress）及 API 版本（如 apps/v1、networking.k8s.io/v1）。 + +除原生 Kubernetes API 外，Karmada 可通过以下与 Kubernetes 相同的扩展机制增强能力： +- **CRD 扩展**：大多数 Karmada 特有 API（如 PropagationPolicy、OverridePolicy）通过 CRD 实现。用户也可在 Karmada 中定义自定义 CRD，并像原生 Kubernetes API 一样分发到成员集群。 +- **聚合 APIServer**：Karmada 的 Cluster API 通过 karmada-aggregated-apiserver 扩展，用户可直接通过 Karmada 统一 API 端点查询成员集群资源（如 Nodes、Pods）。 + 用户可以通过与扩展 Kubernetes 相同的方式扩展 Karmada 的 API 能力，无论是自定义资源还是第三方集成。 + +要查看所有支持的 API，请对 Karmada 执行 `karmadactl api-resources` 命令，该命令会列出包括 Kubernetes API 和扩展 API 在内的所有支持API，输出示例如下： +``` +# karmadactl api-resources +NAME SHORTNAMES APIVERSION NAMESPACED KIND +pods po v1 true Pod +deployments deploy apps/v1 true Deployment +clusters cluster.karmada.io/v1alpha1 false Cluster +overridepolicies op policy.karmada.io/v1alpha1 true OverridePolicy +propagationpolicies pp policy.karmada.io/v1alpha1 true PropagationPolicy +... +``` + +## Kubernetes 版本支持 + +Karmada 使用最小化的稳定 API 和端点管理 Kubernetes 集群，确保广泛的 Kubernetes 版本兼容性。每个 Karmada 版本集成最新的 Kubernetes 客户端， +并测试最近 10 个 Kubernetes 版本的兼容性。例如，Karmada v1.14 使用 Kubernetes 客户端 v1.32，会集成验证 Kubernetes v1.23 至 v1.32 版本。 + +资源仅在 Karmada 和目标集群均支持其 API 时才能被分发： +- 若 Karmada 无法识别 API（如不支持的 CRD 或已弃用的 API），则无法在 Karmada 中创建资源 +- 若成员集群缺少 API（如旧版本集群缺少 networking.k8s.io/v1/Ingress），Karmada 将跳过对该集群的分发 + +## 常见问题解答 + +### 如何选择 Karmada APIServer 版本？ + +Karmada 项目会在其安装工具（如 Karmada Operator）中自动更新默认的 kube-apiserver 版本以支持最新 Kubernetes API。大多数情况下用户无需修改，即使升级 Karmada 时也无需调整。 + +您可能需要升级 Karmada APIServer 的情况包括： +- 采用新 Kubernetes API：需要利用新版 Kubernetes 特性 +- 修复 CVE 漏洞：解决旧版本存在的安全隐患 + +注意升级需谨慎操作： +- 检查 API 弃用情况：确保工作负载使用的资源类型在目标 Kubernetes 版本中未被弃用 +- 逐步升级：始终逐个次版本升级（如 kube-apiserver@v1.32 → v1.33），避免跨版本升级（如 v1.32 → v1.34）。Kubernetes 依赖渐进式 API 弃用和自动转换机制来安全迁移弃用 API。 + +### 如何处理版本跨度大的成员集群？ + +当成员集群存在 API 版本不兼容时（如部分支持 networking.k8s.io/v1，部分仅支持 v1beta1），目前 Karmada 不会根据成员集群能力自动转换 API 版本。 +建议将过时集群升级至新 Kubernetes 版本。 diff --git a/i18n/zh/docusaurus-plugin-content-docs/version-v1.16/administrator/upgrading/v1.11-v1.12.md b/i18n/zh/docusaurus-plugin-content-docs/version-v1.16/administrator/upgrading/v1.11-v1.12.md index 6331f4933..81947e71b 100644 --- a/i18n/zh/docusaurus-plugin-content-docs/version-v1.16/administrator/upgrading/v1.11-v1.12.md +++ b/i18n/zh/docusaurus-plugin-content-docs/version-v1.16/administrator/upgrading/v1.11-v1.12.md @@ -1,45 +1,45 @@ ---- -title: v1.11 升级到 v1.12 ---- - -遵循[常规升级流程](./README.md)。 - -## 升级后显著变化 - -### API 变化 - -- 在 `Karmada` API 中引入了 `SecretRef`，作为连接外部 etcd 集群的配置，可用于指定包含了连接外部 etcd 集群凭证的 secret。 -- 在 `Karmada` API 中引入了 `extraVolumes` 和 `extraVolumemounts` ，以便为 Karmada API server组件指定额外的卷和卷挂载。 -- 在 `Karmada` API中引入了 `ApiServerService` 字段，作为 Karmada 实例状态的一部分，该字段可用于引用该实例的 API Server 服务。这对于需要发现Karmada 实例的 API Server 服务以执行如设置入口流量等任务的高级操作员来说非常有用。 -- 在`Karmada` API中引入了`CustomCertificate.ApiServerCACert`字段，用于指定包含 Karmada API Server 自定义 CA 证书的secret。 -- 在`Karmada` API中，Karmada API server的 ServiceType 现在被限制为`ClusterIP`、`NodePort`和`LoadBalancer`。 -- 在`Cluster` API中引入了一个新的条件`CompleteAPIEnablements`，用于表示API集合的状态。 -- 在`PropagationPolicy`和`ClusterPropagationPolicy` API中引入了`PreserveResourcesOnDeletion`字段，该字段提供了安全回滚迁移的能力。 -- 在`OverridePolicy`和`ClusterOverridePolicy`中引入了`FieldOverrider`，它提供了覆盖如 ConfigMap 或 Secret 等清单中嵌套的结构化数据的能力。 -- 在`ResourceBinding`和`ClusterResourceBinding` API的`GracefulEvictionTask`中引入了`PurgeMode`。 -- 在`PropagationPolicy`中引入了`StatePreservation`，它将在应用故障迁移场景中保存状态。 - -### 弃用 - -- 在`Karmada` API中，`ExternalEtcd.CAData`、`ExternalEtcd.CertData`和`ExternalEtcd.KeyData`已被弃用，并将在未来的版本中移除。请使用 `SecretRef` 来提供客户端连接凭证。 -- 在版本`v1.11.0`中已弃用的以下启动参数现在已被移除： - * `karmada-agent`: - * --bind-address - * --secure-port - * `karmada-controller-manager`: - * --bind-address - * --secure-port - * `karmada-scheduler-estimator`: - * --bind-address - * --secure-port - * `karmada-scheduler`: - * --bind-address - * --secure-port - * `karmada-descheduler`: - * --bind-address - * --secure-port - -### karmada-controller-manager - -- 引入了特性门控`StatefulFailoverInjection`，用于控制 Karmada 在有状态应用的故障转移期间是否收集和注入状态信息。 +--- +title: v1.11 升级到 v1.12 +--- + +遵循[常规升级流程](./README.md)。 + +## 升级后显著变化 + +### API 变化 + +- 在 `Karmada` API 中引入了 `SecretRef`，作为连接外部 etcd 集群的配置，可用于指定包含了连接外部 etcd 集群凭证的 secret。 +- 在 `Karmada` API 中引入了 `extraVolumes` 和 `extraVolumemounts` ，以便为 Karmada API server组件指定额外的卷和卷挂载。 +- 在 `Karmada` API中引入了 `ApiServerService` 字段，作为 Karmada 实例状态的一部分，该字段可用于引用该实例的 API Server 服务。这对于需要发现Karmada 实例的 API Server 服务以执行如设置入口流量等任务的高级操作员来说非常有用。 +- 在`Karmada` API中引入了`CustomCertificate.ApiServerCACert`字段，用于指定包含 Karmada API Server 自定义 CA 证书的secret。 +- 在`Karmada` API中，Karmada API server的 ServiceType 现在被限制为`ClusterIP`、`NodePort`和`LoadBalancer`。 +- 在`Cluster` API中引入了一个新的条件`CompleteAPIEnablements`，用于表示API集合的状态。 +- 在`PropagationPolicy`和`ClusterPropagationPolicy` API中引入了`PreserveResourcesOnDeletion`字段，该字段提供了安全回滚迁移的能力。 +- 在`OverridePolicy`和`ClusterOverridePolicy`中引入了`FieldOverrider`，它提供了覆盖如 ConfigMap 或 Secret 等清单中嵌套的结构化数据的能力。 +- 在`ResourceBinding`和`ClusterResourceBinding` API的`GracefulEvictionTask`中引入了`PurgeMode`。 +- 在`PropagationPolicy`中引入了`StatePreservation`，它将在应用故障迁移场景中保存状态。 + +### 弃用 + +- 在`Karmada` API中，`ExternalEtcd.CAData`、`ExternalEtcd.CertData`和`ExternalEtcd.KeyData`已被弃用，并将在未来的版本中移除。请使用 `SecretRef` 来提供客户端连接凭证。 +- 在版本`v1.11.0`中已弃用的以下启动参数现在已被移除： + * `karmada-agent`: + * --bind-address + * --secure-port + * `karmada-controller-manager`: + * --bind-address + * --secure-port + * `karmada-scheduler-estimator`: + * --bind-address + * --secure-port + * `karmada-scheduler`: + * --bind-address + * --secure-port + * `karmada-descheduler`: + * --bind-address + * --secure-port + +### karmada-controller-manager + +- 引入了特性门控`StatefulFailoverInjection`，用于控制 Karmada 在有状态应用的故障转移期间是否收集和注入状态信息。 - 特性`Failover`现在默认已禁用，需要显式启用以避免意外事件。 \ No newline at end of file diff --git a/i18n/zh/docusaurus-plugin-content-docs/version-v1.17/administrator/compatibility/compatibility.md b/i18n/zh/docusaurus-plugin-content-docs/version-v1.17/administrator/compatibility/compatibility.md index a1a4dfb64..d5bc3b8e1 100644 --- a/i18n/zh/docusaurus-plugin-content-docs/version-v1.17/administrator/compatibility/compatibility.md +++ b/i18n/zh/docusaurus-plugin-content-docs/version-v1.17/administrator/compatibility/compatibility.md @@ -1,60 +1,60 @@ ---- -title: Kubernetes 兼容性 ---- - -本文档全面阐述了 Karmada 与 Kubernetes 版本的兼容性，主要从两个维度进行说明： -- Karmada 控制平面 API 支持：支持哪些 API？ -- Kubernetes 版本支持：支持哪些 Kubernetes 版本？ - -本文档帮助管理员理解 Karmada 如何管理混合 Kubernetes 版本集群间的资源。通过遵循各集群的 API 能力确保安全分发，并提供在升级或迁移过程中维护 -兼容性的指导原则。 - -## Karmada 控制平面 API 支持 - -Karmada 支持其使用的 kube-apiserver 版本中所有可用的 Kubernetes API。例如，如 Karmada APIServer 使用 kube-apiserver@v1.32， -则继承支持 Kubernetes v1.32 中所有 API（如 Deployment、Service、Ingress）及 API 版本（如 apps/v1、networking.k8s.io/v1）。 - -除原生 Kubernetes API 外，Karmada 可通过以下与 Kubernetes 相同的扩展机制增强能力： -- **CRD 扩展**：大多数 Karmada 特有 API（如 PropagationPolicy、OverridePolicy）通过 CRD 实现。用户也可在 Karmada 中定义自定义 CRD，并像原生 Kubernetes API 一样分发到成员集群。 -- **聚合 APIServer**：Karmada 的 Cluster API 通过 karmada-aggregated-apiserver 扩展，用户可直接通过 Karmada 统一 API 端点查询成员集群资源（如 Nodes、Pods）。 - 用户可以通过与扩展 Kubernetes 相同的方式扩展 Karmada 的 API 能力，无论是自定义资源还是第三方集成。 - -要查看所有支持的 API，请对 Karmada 执行 `karmadactl api-resources` 命令，该命令会列出包括 Kubernetes API 和扩展 API 在内的所有支持API，输出示例如下： -``` -# karmadactl api-resources -NAME SHORTNAMES APIVERSION NAMESPACED KIND -pods po v1 true Pod -deployments deploy apps/v1 true Deployment -clusters cluster.karmada.io/v1alpha1 false Cluster -overridepolicies op policy.karmada.io/v1alpha1 true OverridePolicy -propagationpolicies pp policy.karmada.io/v1alpha1 true PropagationPolicy -... -``` - -## Kubernetes 版本支持 - -Karmada 使用最小化的稳定 API 和端点管理 Kubernetes 集群，确保广泛的 Kubernetes 版本兼容性。每个 Karmada 版本集成最新的 Kubernetes 客户端， -并测试最近 10 个 Kubernetes 版本的兼容性。例如，Karmada v1.14 使用 Kubernetes 客户端 v1.32，会集成验证 Kubernetes v1.23 至 v1.32 版本。 - -资源仅在 Karmada 和目标集群均支持其 API 时才能被分发： -- 若 Karmada 无法识别 API（如不支持的 CRD 或已弃用的 API），则无法在 Karmada 中创建资源 -- 若成员集群缺少 API（如旧版本集群缺少 networking.k8s.io/v1/Ingress），Karmada 将跳过对该集群的分发 - -## 常见问题解答 - -### 如何选择 Karmada APIServer 版本？ - -Karmada 项目会在其安装工具（如 Karmada Operator）中自动更新默认的 kube-apiserver 版本以支持最新 Kubernetes API。大多数情况下用户无需修改，即使升级 Karmada 时也无需调整。 - -您可能需要升级 Karmada APIServer 的情况包括： -- 采用新 Kubernetes API：需要利用新版 Kubernetes 特性 -- 修复 CVE 漏洞：解决旧版本存在的安全隐患 - -注意升级需谨慎操作： -- 检查 API 弃用情况：确保工作负载使用的资源类型在目标 Kubernetes 版本中未被弃用 -- 逐步升级：始终逐个次版本升级（如 kube-apiserver@v1.32 → v1.33），避免跨版本升级（如 v1.32 → v1.34）。Kubernetes 依赖渐进式 API 弃用和自动转换机制来安全迁移弃用 API。 - -### 如何处理版本跨度大的成员集群？ - -当成员集群存在 API 版本不兼容时（如部分支持 networking.k8s.io/v1，部分仅支持 v1beta1），目前 Karmada 不会根据成员集群能力自动转换 API 版本。 -建议将过时集群升级至新 Kubernetes 版本。 +--- +title: Kubernetes 兼容性 +--- + +本文档全面阐述了 Karmada 与 Kubernetes 版本的兼容性，主要从两个维度进行说明： +- Karmada 控制平面 API 支持：支持哪些 API？ +- Kubernetes 版本支持：支持哪些 Kubernetes 版本？ + +本文档帮助管理员理解 Karmada 如何管理混合 Kubernetes 版本集群间的资源。通过遵循各集群的 API 能力确保安全分发，并提供在升级或迁移过程中维护 +兼容性的指导原则。 + +## Karmada 控制平面 API 支持 + +Karmada 支持其使用的 kube-apiserver 版本中所有可用的 Kubernetes API。例如，如 Karmada APIServer 使用 kube-apiserver@v1.32， +则继承支持 Kubernetes v1.32 中所有 API（如 Deployment、Service、Ingress）及 API 版本（如 apps/v1、networking.k8s.io/v1）。 + +除原生 Kubernetes API 外，Karmada 可通过以下与 Kubernetes 相同的扩展机制增强能力： +- **CRD 扩展**：大多数 Karmada 特有 API（如 PropagationPolicy、OverridePolicy）通过 CRD 实现。用户也可在 Karmada 中定义自定义 CRD，并像原生 Kubernetes API 一样分发到成员集群。 +- **聚合 APIServer**：Karmada 的 Cluster API 通过 karmada-aggregated-apiserver 扩展，用户可直接通过 Karmada 统一 API 端点查询成员集群资源（如 Nodes、Pods）。 + 用户可以通过与扩展 Kubernetes 相同的方式扩展 Karmada 的 API 能力，无论是自定义资源还是第三方集成。 + +要查看所有支持的 API，请对 Karmada 执行 `karmadactl api-resources` 命令，该命令会列出包括 Kubernetes API 和扩展 API 在内的所有支持API，输出示例如下： +``` +# karmadactl api-resources +NAME SHORTNAMES APIVERSION NAMESPACED KIND +pods po v1 true Pod +deployments deploy apps/v1 true Deployment +clusters cluster.karmada.io/v1alpha1 false Cluster +overridepolicies op policy.karmada.io/v1alpha1 true OverridePolicy +propagationpolicies pp policy.karmada.io/v1alpha1 true PropagationPolicy +... +``` + +## Kubernetes 版本支持 + +Karmada 使用最小化的稳定 API 和端点管理 Kubernetes 集群，确保广泛的 Kubernetes 版本兼容性。每个 Karmada 版本集成最新的 Kubernetes 客户端， +并测试最近 10 个 Kubernetes 版本的兼容性。例如，Karmada v1.14 使用 Kubernetes 客户端 v1.32，会集成验证 Kubernetes v1.23 至 v1.32 版本。 + +资源仅在 Karmada 和目标集群均支持其 API 时才能被分发： +- 若 Karmada 无法识别 API（如不支持的 CRD 或已弃用的 API），则无法在 Karmada 中创建资源 +- 若成员集群缺少 API（如旧版本集群缺少 networking.k8s.io/v1/Ingress），Karmada 将跳过对该集群的分发 + +## 常见问题解答 + +### 如何选择 Karmada APIServer 版本？ + +Karmada 项目会在其安装工具（如 Karmada Operator）中自动更新默认的 kube-apiserver 版本以支持最新 Kubernetes API。大多数情况下用户无需修改，即使升级 Karmada 时也无需调整。 + +您可能需要升级 Karmada APIServer 的情况包括： +- 采用新 Kubernetes API：需要利用新版 Kubernetes 特性 +- 修复 CVE 漏洞：解决旧版本存在的安全隐患 + +注意升级需谨慎操作： +- 检查 API 弃用情况：确保工作负载使用的资源类型在目标 Kubernetes 版本中未被弃用 +- 逐步升级：始终逐个次版本升级（如 kube-apiserver@v1.32 → v1.33），避免跨版本升级（如 v1.32 → v1.34）。Kubernetes 依赖渐进式 API 弃用和自动转换机制来安全迁移弃用 API。 + +### 如何处理版本跨度大的成员集群？ + +当成员集群存在 API 版本不兼容时（如部分支持 networking.k8s.io/v1，部分仅支持 v1beta1），目前 Karmada 不会根据成员集群能力自动转换 API 版本。 +建议将过时集群升级至新 Kubernetes 版本。 diff --git a/i18n/zh/docusaurus-plugin-content-docs/version-v1.17/administrator/upgrading/v1.11-v1.12.md b/i18n/zh/docusaurus-plugin-content-docs/version-v1.17/administrator/upgrading/v1.11-v1.12.md index 6331f4933..81947e71b 100644 --- a/i18n/zh/docusaurus-plugin-content-docs/version-v1.17/administrator/upgrading/v1.11-v1.12.md +++ b/i18n/zh/docusaurus-plugin-content-docs/version-v1.17/administrator/upgrading/v1.11-v1.12.md @@ -1,45 +1,45 @@ ---- -title: v1.11 升级到 v1.12 ---- - -遵循[常规升级流程](./README.md)。 - -## 升级后显著变化 - -### API 变化 - -- 在 `Karmada` API 中引入了 `SecretRef`，作为连接外部 etcd 集群的配置，可用于指定包含了连接外部 etcd 集群凭证的 secret。 -- 在 `Karmada` API 中引入了 `extraVolumes` 和 `extraVolumemounts` ，以便为 Karmada API server组件指定额外的卷和卷挂载。 -- 在 `Karmada` API中引入了 `ApiServerService` 字段，作为 Karmada 实例状态的一部分，该字段可用于引用该实例的 API Server 服务。这对于需要发现Karmada 实例的 API Server 服务以执行如设置入口流量等任务的高级操作员来说非常有用。 -- 在`Karmada` API中引入了`CustomCertificate.ApiServerCACert`字段，用于指定包含 Karmada API Server 自定义 CA 证书的secret。 -- 在`Karmada` API中，Karmada API server的 ServiceType 现在被限制为`ClusterIP`、`NodePort`和`LoadBalancer`。 -- 在`Cluster` API中引入了一个新的条件`CompleteAPIEnablements`，用于表示API集合的状态。 -- 在`PropagationPolicy`和`ClusterPropagationPolicy` API中引入了`PreserveResourcesOnDeletion`字段，该字段提供了安全回滚迁移的能力。 -- 在`OverridePolicy`和`ClusterOverridePolicy`中引入了`FieldOverrider`，它提供了覆盖如 ConfigMap 或 Secret 等清单中嵌套的结构化数据的能力。 -- 在`ResourceBinding`和`ClusterResourceBinding` API的`GracefulEvictionTask`中引入了`PurgeMode`。 -- 在`PropagationPolicy`中引入了`StatePreservation`，它将在应用故障迁移场景中保存状态。 - -### 弃用 - -- 在`Karmada` API中，`ExternalEtcd.CAData`、`ExternalEtcd.CertData`和`ExternalEtcd.KeyData`已被弃用，并将在未来的版本中移除。请使用 `SecretRef` 来提供客户端连接凭证。 -- 在版本`v1.11.0`中已弃用的以下启动参数现在已被移除： - * `karmada-agent`: - * --bind-address - * --secure-port - * `karmada-controller-manager`: - * --bind-address - * --secure-port - * `karmada-scheduler-estimator`: - * --bind-address - * --secure-port - * `karmada-scheduler`: - * --bind-address - * --secure-port - * `karmada-descheduler`: - * --bind-address - * --secure-port - -### karmada-controller-manager - -- 引入了特性门控`StatefulFailoverInjection`，用于控制 Karmada 在有状态应用的故障转移期间是否收集和注入状态信息。 +--- +title: v1.11 升级到 v1.12 +--- + +遵循[常规升级流程](./README.md)。 + +## 升级后显著变化 + +### API 变化 + +- 在 `Karmada` API 中引入了 `SecretRef`，作为连接外部 etcd 集群的配置，可用于指定包含了连接外部 etcd 集群凭证的 secret。 +- 在 `Karmada` API 中引入了 `extraVolumes` 和 `extraVolumemounts` ，以便为 Karmada API server组件指定额外的卷和卷挂载。 +- 在 `Karmada` API中引入了 `ApiServerService` 字段，作为 Karmada 实例状态的一部分，该字段可用于引用该实例的 API Server 服务。这对于需要发现Karmada 实例的 API Server 服务以执行如设置入口流量等任务的高级操作员来说非常有用。 +- 在`Karmada` API中引入了`CustomCertificate.ApiServerCACert`字段，用于指定包含 Karmada API Server 自定义 CA 证书的secret。 +- 在`Karmada` API中，Karmada API server的 ServiceType 现在被限制为`ClusterIP`、`NodePort`和`LoadBalancer`。 +- 在`Cluster` API中引入了一个新的条件`CompleteAPIEnablements`，用于表示API集合的状态。 +- 在`PropagationPolicy`和`ClusterPropagationPolicy` API中引入了`PreserveResourcesOnDeletion`字段，该字段提供了安全回滚迁移的能力。 +- 在`OverridePolicy`和`ClusterOverridePolicy`中引入了`FieldOverrider`，它提供了覆盖如 ConfigMap 或 Secret 等清单中嵌套的结构化数据的能力。 +- 在`ResourceBinding`和`ClusterResourceBinding` API的`GracefulEvictionTask`中引入了`PurgeMode`。 +- 在`PropagationPolicy`中引入了`StatePreservation`，它将在应用故障迁移场景中保存状态。 + +### 弃用 + +- 在`Karmada` API中，`ExternalEtcd.CAData`、`ExternalEtcd.CertData`和`ExternalEtcd.KeyData`已被弃用，并将在未来的版本中移除。请使用 `SecretRef` 来提供客户端连接凭证。 +- 在版本`v1.11.0`中已弃用的以下启动参数现在已被移除： + * `karmada-agent`: + * --bind-address + * --secure-port + * `karmada-controller-manager`: + * --bind-address + * --secure-port + * `karmada-scheduler-estimator`: + * --bind-address + * --secure-port + * `karmada-scheduler`: + * --bind-address + * --secure-port + * `karmada-descheduler`: + * --bind-address + * --secure-port + +### karmada-controller-manager + +- 引入了特性门控`StatefulFailoverInjection`，用于控制 Karmada 在有状态应用的故障转移期间是否收集和注入状态信息。 - 特性`Failover`现在默认已禁用，需要显式启用以避免意外事件。 \ No newline at end of file diff --git a/i18n/zh/docusaurus-plugin-content-docs/version-v1.17/userguide/scheduling/multi-component-scheduling.md b/i18n/zh/docusaurus-plugin-content-docs/version-v1.17/userguide/scheduling/multi-component-scheduling.md index cbf892d63..1251774bc 100644 --- a/i18n/zh/docusaurus-plugin-content-docs/version-v1.17/userguide/scheduling/multi-component-scheduling.md +++ b/i18n/zh/docusaurus-plugin-content-docs/version-v1.17/userguide/scheduling/multi-component-scheduling.md @@ -1,89 +1,89 @@ ---- -title: 调度多组件工作负载 ---- - -## 概述 - -许多现代分布式应用程序由具有异构资源需求的多个组件组成。例如，`Flink 集群`包含 `JobManager` 和 `TaskManager` 组件，而 `Ray 集群`则包含 `Head` 和 `Worker` 节点。每个组件通常具有不同的副本数和资源规格。 - -从 Karmada v1.16 开始，`多 Pod 模板调度`功能为这些复杂工作负载提供了精确的资源感知调度能力。这确保了 Karmada 能够正确理解多组件应用程序的总资源需求，并在成员集群之间做出明智的调度决策。 - -## 为什么需要多组件调度？ - -在 v1.16 之前，Karmada 调度器假设工作负载中的所有副本都是相同的，使用单一的 Pod 模板来表示资源需求。这种假设对于 Deployment 等简单应用程序效果良好，但对于多组件工作负载则会导致不准确的情况。 - -考虑一个具有两个组件的 FlinkDeployment： -- JobManager：1 个副本，需要 1 CPU 和 2Gi 内存 -- TaskManager：3 个副本，每个需要 2 CPU 和 4Gi 内存 - -使用传统调度，调度器只能表示一个组件的需求，导致： -- 低估：将 JobManager 配置应用于所有副本 → 仅计算 **4 个 CPU** 总量（实际需要 7 个）→ 存在调度到资源不足集群的风险（**Pod Pending**）。 -- 高估：将 TaskManager 配置应用于所有副本 → 估计 **8 个 CPU** 总量（实际需要 7 个）→ 浪费资源并限制集群选择。 -- 配额计算不准确：FederatedResourceQuota 显示错误的使用情况。 - -使用多组件调度，调度器能够准确理解： -- 所需的总资源：(1 × 1 CPU + 1 × 2Gi) + (3 × 2 CPU + 3 × 4Gi) = 7 CPU 和 14Gi 内存 -- 每个组件的具体需求 -- 集群是否能够容纳所有组件 - -## 支持的工作负载类型 - -多组件调度功能专为具有多个异构 Pod 模板的 CRD 设计。常见用例包括： - -| 类别 | 示例 | -|----------|----------| -| 流处理 | Flink、Kafka Streams、Apache Storm | -| AI/ML 框架 | Ray、TensorFlow、PyTorch、MXNet | -| 机器学习训练 | 参数服务器、分布式训练作业 | -| 批处理 | Spark、Volcano、Hadoop | -| 数据处理 | XGBoost、PaddlePaddle、分布式数据库 | -| 分布式系统 | Elasticsearch、Redis Cluster、数据库集群 | - -Karmada 为流行的 CRD 提供了内置的解释器支持。您可以在[资源解释器文档](../globalview/customizing-resource-interpreter)中找到具有内置解释器支持的 CRD 列表。对于新的 CRD 类型或自定义工作负载，您可以实现自定义解释器（参见[自定义资源解释器](../globalview/customizing-resource-interpreter)）或[联系 Karmada 社区](https://github.com/karmada-io/karmada?tab=readme-ov-file#contact)获取支持。 - -## 功能成熟度和要求 - -多组件调度功能目前处于 **Alpha** 阶段，从 Karmada v1.16 开始提供。作为 Alpha 功能，它在未来版本中可能会发生变化，但核心调度功能已完全可用，可用于评估和测试环境。 - -要使用多组件调度功能，您必须启用 `MultiplePodTemplatesScheduling` 特性门控。该特性门控必须在以下组件上启用： - -- `karmada-controller-manager`：负责解释多组件工作负载规格并在 ResourceBinding 对象中填充组件信息。 -- `karmada-scheduler`：负责基于控制器提取的组件资源需求进行调度决策。 -- `karmada-webhook`：负责验证从资源模板解析的组件信息。 - -## 工作原理 - -下图展示了多组件调度的过程，以 FlinkDeployment 为例。相同的工作流程也适用于其他多组件应用程序，如 RayCluster、TensorFlow 集群和其他分布式系统。 - -![Multi-Component Scheduling Architecture](./../../resources/userguide/scheduling/multi-component-scheduling.png) - -上图显示了调度工作流程： - -1. 多组件应用程序（例如 FlinkDeployment、RayCluster）被提交到 Karmada API Server。需要提供 `PropagationPolicy` 或 `ClusterPropagationPolicy` 来指定工作负载应如何在成员集群之间分发。 - -2. Karmada 控制器利用资源解释器来解析每个组件的资源需求。这些需求存储在 ResourceBinding 对象的 `spec.components` 字段中。 - -3. 调度器基于每个组件逐个评估候选集群，而不是简单地按总资源求和。例如，它检查集群是否可以容纳 JobManager，然后检查同一集群是否也可以容纳所有 TaskManager。这种方法更好地考虑了集群节点之间的资源分布和碎片化。 - -4. 调度器选择可以满足所有组件需求的集群。然后将所有组件作为单个单元调度到该集群。 - -## 限制和约束 - -目前，多组件调度功能具有以下限制： -- 工作负载的所有组件必须调度到同一个集群 -- 尚不支持跨集群组件分发 - -多组件工作负载通常在组件之间存在紧密耦合（共享存储、网络连接、同步需求）。将组件分发到不同集群会在资源管理、故障处理和性能优化方面带来显著的复杂性。 - -我们认识到，将组件分发到不同集群是更好地利用多集群资源的自然演进。这种方法可以实现更灵活的资源分配和提高基础设施的利用率。但是，支持这一点需要： -- 用户定义明确的拆分规则和策略，以确保组件被适当放置 -- 依赖关系和亲和性规范，以防止导致调度成功但无法运行的不兼容放置 - -我们欢迎有关跨集群组件分发的用户反馈和用例。如果您有特定的需求或场景，请随时[联系我们](https://github.com/karmada-io/karmada?tab=readme-ov-file#contact)。 - -## 下一步 - -- [自定义资源解释器](../globalview/customizing-resource-interpreter) - 为您的 CRD 实现解释器 -- [调度器评估器](./scheduler-estimator) - 启用资源感知调度 -- [分发策略](./propagation-policy) - 将资源分发到集群的基础知识 -- [集群资源](./cluster-resources) - 理解集群资源建模 +--- +title: 调度多组件工作负载 +--- + +## 概述 + +许多现代分布式应用程序由具有异构资源需求的多个组件组成。例如，`Flink 集群`包含 `JobManager` 和 `TaskManager` 组件，而 `Ray 集群`则包含 `Head` 和 `Worker` 节点。每个组件通常具有不同的副本数和资源规格。 + +从 Karmada v1.16 开始，`多 Pod 模板调度`功能为这些复杂工作负载提供了精确的资源感知调度能力。这确保了 Karmada 能够正确理解多组件应用程序的总资源需求，并在成员集群之间做出明智的调度决策。 + +## 为什么需要多组件调度？ + +在 v1.16 之前，Karmada 调度器假设工作负载中的所有副本都是相同的，使用单一的 Pod 模板来表示资源需求。这种假设对于 Deployment 等简单应用程序效果良好，但对于多组件工作负载则会导致不准确的情况。 + +考虑一个具有两个组件的 FlinkDeployment： +- JobManager：1 个副本，需要 1 CPU 和 2Gi 内存 +- TaskManager：3 个副本，每个需要 2 CPU 和 4Gi 内存 + +使用传统调度，调度器只能表示一个组件的需求，导致： +- 低估：将 JobManager 配置应用于所有副本 → 仅计算 **4 个 CPU** 总量（实际需要 7 个）→ 存在调度到资源不足集群的风险（**Pod Pending**）。 +- 高估：将 TaskManager 配置应用于所有副本 → 估计 **8 个 CPU** 总量（实际需要 7 个）→ 浪费资源并限制集群选择。 +- 配额计算不准确：FederatedResourceQuota 显示错误的使用情况。 + +使用多组件调度，调度器能够准确理解： +- 所需的总资源：(1 × 1 CPU + 1 × 2Gi) + (3 × 2 CPU + 3 × 4Gi) = 7 CPU 和 14Gi 内存 +- 每个组件的具体需求 +- 集群是否能够容纳所有组件 + +## 支持的工作负载类型 + +多组件调度功能专为具有多个异构 Pod 模板的 CRD 设计。常见用例包括： + +| 类别 | 示例 | +|----------|----------| +| 流处理 | Flink、Kafka Streams、Apache Storm | +| AI/ML 框架 | Ray、TensorFlow、PyTorch、MXNet | +| 机器学习训练 | 参数服务器、分布式训练作业 | +| 批处理 | Spark、Volcano、Hadoop | +| 数据处理 | XGBoost、PaddlePaddle、分布式数据库 | +| 分布式系统 | Elasticsearch、Redis Cluster、数据库集群 | + +Karmada 为流行的 CRD 提供了内置的解释器支持。您可以在[资源解释器文档](../globalview/customizing-resource-interpreter)中找到具有内置解释器支持的 CRD 列表。对于新的 CRD 类型或自定义工作负载，您可以实现自定义解释器（参见[自定义资源解释器](../globalview/customizing-resource-interpreter)）或[联系 Karmada 社区](https://github.com/karmada-io/karmada?tab=readme-ov-file#contact)获取支持。 + +## 功能成熟度和要求 + +多组件调度功能目前处于 **Alpha** 阶段，从 Karmada v1.16 开始提供。作为 Alpha 功能，它在未来版本中可能会发生变化，但核心调度功能已完全可用，可用于评估和测试环境。 + +要使用多组件调度功能，您必须启用 `MultiplePodTemplatesScheduling` 特性门控。该特性门控必须在以下组件上启用： + +- `karmada-controller-manager`：负责解释多组件工作负载规格并在 ResourceBinding 对象中填充组件信息。 +- `karmada-scheduler`：负责基于控制器提取的组件资源需求进行调度决策。 +- `karmada-webhook`：负责验证从资源模板解析的组件信息。 + +## 工作原理 + +下图展示了多组件调度的过程，以 FlinkDeployment 为例。相同的工作流程也适用于其他多组件应用程序，如 RayCluster、TensorFlow 集群和其他分布式系统。 + +![Multi-Component Scheduling Architecture](./../../resources/userguide/scheduling/multi-component-scheduling.png) + +上图显示了调度工作流程： + +1. 多组件应用程序（例如 FlinkDeployment、RayCluster）被提交到 Karmada API Server。需要提供 `PropagationPolicy` 或 `ClusterPropagationPolicy` 来指定工作负载应如何在成员集群之间分发。 + +2. Karmada 控制器利用资源解释器来解析每个组件的资源需求。这些需求存储在 ResourceBinding 对象的 `spec.components` 字段中。 + +3. 调度器基于每个组件逐个评估候选集群，而不是简单地按总资源求和。例如，它检查集群是否可以容纳 JobManager，然后检查同一集群是否也可以容纳所有 TaskManager。这种方法更好地考虑了集群节点之间的资源分布和碎片化。 + +4. 调度器选择可以满足所有组件需求的集群。然后将所有组件作为单个单元调度到该集群。 + +## 限制和约束 + +目前，多组件调度功能具有以下限制： +- 工作负载的所有组件必须调度到同一个集群 +- 尚不支持跨集群组件分发 + +多组件工作负载通常在组件之间存在紧密耦合（共享存储、网络连接、同步需求）。将组件分发到不同集群会在资源管理、故障处理和性能优化方面带来显著的复杂性。 + +我们认识到，将组件分发到不同集群是更好地利用多集群资源的自然演进。这种方法可以实现更灵活的资源分配和提高基础设施的利用率。但是，支持这一点需要： +- 用户定义明确的拆分规则和策略，以确保组件被适当放置 +- 依赖关系和亲和性规范，以防止导致调度成功但无法运行的不兼容放置 + +我们欢迎有关跨集群组件分发的用户反馈和用例。如果您有特定的需求或场景，请随时[联系我们](https://github.com/karmada-io/karmada?tab=readme-ov-file#contact)。 + +## 下一步 + +- [自定义资源解释器](../globalview/customizing-resource-interpreter) - 为您的 CRD 实现解释器 +- [调度器评估器](./scheduler-estimator) - 启用资源感知调度 +- [分发策略](./propagation-policy) - 将资源分发到集群的基础知识 +- [集群资源](./cluster-resources) - 理解集群资源建模 diff --git a/i18n/zh/docusaurus-plugin-content-docs/version-v1.18/administrator/compatibility/compatibility.md b/i18n/zh/docusaurus-plugin-content-docs/version-v1.18/administrator/compatibility/compatibility.md index a1a4dfb64..d5bc3b8e1 100644 --- a/i18n/zh/docusaurus-plugin-content-docs/version-v1.18/administrator/compatibility/compatibility.md +++ b/i18n/zh/docusaurus-plugin-content-docs/version-v1.18/administrator/compatibility/compatibility.md @@ -1,60 +1,60 @@ ---- -title: Kubernetes 兼容性 ---- - -本文档全面阐述了 Karmada 与 Kubernetes 版本的兼容性，主要从两个维度进行说明： -- Karmada 控制平面 API 支持：支持哪些 API？ -- Kubernetes 版本支持：支持哪些 Kubernetes 版本？ - -本文档帮助管理员理解 Karmada 如何管理混合 Kubernetes 版本集群间的资源。通过遵循各集群的 API 能力确保安全分发，并提供在升级或迁移过程中维护 -兼容性的指导原则。 - -## Karmada 控制平面 API 支持 - -Karmada 支持其使用的 kube-apiserver 版本中所有可用的 Kubernetes API。例如，如 Karmada APIServer 使用 kube-apiserver@v1.32， -则继承支持 Kubernetes v1.32 中所有 API（如 Deployment、Service、Ingress）及 API 版本（如 apps/v1、networking.k8s.io/v1）。 - -除原生 Kubernetes API 外，Karmada 可通过以下与 Kubernetes 相同的扩展机制增强能力： -- **CRD 扩展**：大多数 Karmada 特有 API（如 PropagationPolicy、OverridePolicy）通过 CRD 实现。用户也可在 Karmada 中定义自定义 CRD，并像原生 Kubernetes API 一样分发到成员集群。 -- **聚合 APIServer**：Karmada 的 Cluster API 通过 karmada-aggregated-apiserver 扩展，用户可直接通过 Karmada 统一 API 端点查询成员集群资源（如 Nodes、Pods）。 - 用户可以通过与扩展 Kubernetes 相同的方式扩展 Karmada 的 API 能力，无论是自定义资源还是第三方集成。 - -要查看所有支持的 API，请对 Karmada 执行 `karmadactl api-resources` 命令，该命令会列出包括 Kubernetes API 和扩展 API 在内的所有支持API，输出示例如下： -``` -# karmadactl api-resources -NAME SHORTNAMES APIVERSION NAMESPACED KIND -pods po v1 true Pod -deployments deploy apps/v1 true Deployment -clusters cluster.karmada.io/v1alpha1 false Cluster -overridepolicies op policy.karmada.io/v1alpha1 true OverridePolicy -propagationpolicies pp policy.karmada.io/v1alpha1 true PropagationPolicy -... -``` - -## Kubernetes 版本支持 - -Karmada 使用最小化的稳定 API 和端点管理 Kubernetes 集群，确保广泛的 Kubernetes 版本兼容性。每个 Karmada 版本集成最新的 Kubernetes 客户端， -并测试最近 10 个 Kubernetes 版本的兼容性。例如，Karmada v1.14 使用 Kubernetes 客户端 v1.32，会集成验证 Kubernetes v1.23 至 v1.32 版本。 - -资源仅在 Karmada 和目标集群均支持其 API 时才能被分发： -- 若 Karmada 无法识别 API（如不支持的 CRD 或已弃用的 API），则无法在 Karmada 中创建资源 -- 若成员集群缺少 API（如旧版本集群缺少 networking.k8s.io/v1/Ingress），Karmada 将跳过对该集群的分发 - -## 常见问题解答 - -### 如何选择 Karmada APIServer 版本？ - -Karmada 项目会在其安装工具（如 Karmada Operator）中自动更新默认的 kube-apiserver 版本以支持最新 Kubernetes API。大多数情况下用户无需修改，即使升级 Karmada 时也无需调整。 - -您可能需要升级 Karmada APIServer 的情况包括： -- 采用新 Kubernetes API：需要利用新版 Kubernetes 特性 -- 修复 CVE 漏洞：解决旧版本存在的安全隐患 - -注意升级需谨慎操作： -- 检查 API 弃用情况：确保工作负载使用的资源类型在目标 Kubernetes 版本中未被弃用 -- 逐步升级：始终逐个次版本升级（如 kube-apiserver@v1.32 → v1.33），避免跨版本升级（如 v1.32 → v1.34）。Kubernetes 依赖渐进式 API 弃用和自动转换机制来安全迁移弃用 API。 - -### 如何处理版本跨度大的成员集群？ - -当成员集群存在 API 版本不兼容时（如部分支持 networking.k8s.io/v1，部分仅支持 v1beta1），目前 Karmada 不会根据成员集群能力自动转换 API 版本。 -建议将过时集群升级至新 Kubernetes 版本。 +--- +title: Kubernetes 兼容性 +--- + +本文档全面阐述了 Karmada 与 Kubernetes 版本的兼容性，主要从两个维度进行说明： +- Karmada 控制平面 API 支持：支持哪些 API？ +- Kubernetes 版本支持：支持哪些 Kubernetes 版本？ + +本文档帮助管理员理解 Karmada 如何管理混合 Kubernetes 版本集群间的资源。通过遵循各集群的 API 能力确保安全分发，并提供在升级或迁移过程中维护 +兼容性的指导原则。 + +## Karmada 控制平面 API 支持 + +Karmada 支持其使用的 kube-apiserver 版本中所有可用的 Kubernetes API。例如，如 Karmada APIServer 使用 kube-apiserver@v1.32， +则继承支持 Kubernetes v1.32 中所有 API（如 Deployment、Service、Ingress）及 API 版本（如 apps/v1、networking.k8s.io/v1）。 + +除原生 Kubernetes API 外，Karmada 可通过以下与 Kubernetes 相同的扩展机制增强能力： +- **CRD 扩展**：大多数 Karmada 特有 API（如 PropagationPolicy、OverridePolicy）通过 CRD 实现。用户也可在 Karmada 中定义自定义 CRD，并像原生 Kubernetes API 一样分发到成员集群。 +- **聚合 APIServer**：Karmada 的 Cluster API 通过 karmada-aggregated-apiserver 扩展，用户可直接通过 Karmada 统一 API 端点查询成员集群资源（如 Nodes、Pods）。 + 用户可以通过与扩展 Kubernetes 相同的方式扩展 Karmada 的 API 能力，无论是自定义资源还是第三方集成。 + +要查看所有支持的 API，请对 Karmada 执行 `karmadactl api-resources` 命令，该命令会列出包括 Kubernetes API 和扩展 API 在内的所有支持API，输出示例如下： +``` +# karmadactl api-resources +NAME SHORTNAMES APIVERSION NAMESPACED KIND +pods po v1 true Pod +deployments deploy apps/v1 true Deployment +clusters cluster.karmada.io/v1alpha1 false Cluster +overridepolicies op policy.karmada.io/v1alpha1 true OverridePolicy +propagationpolicies pp policy.karmada.io/v1alpha1 true PropagationPolicy +... +``` + +## Kubernetes 版本支持 + +Karmada 使用最小化的稳定 API 和端点管理 Kubernetes 集群，确保广泛的 Kubernetes 版本兼容性。每个 Karmada 版本集成最新的 Kubernetes 客户端， +并测试最近 10 个 Kubernetes 版本的兼容性。例如，Karmada v1.14 使用 Kubernetes 客户端 v1.32，会集成验证 Kubernetes v1.23 至 v1.32 版本。 + +资源仅在 Karmada 和目标集群均支持其 API 时才能被分发： +- 若 Karmada 无法识别 API（如不支持的 CRD 或已弃用的 API），则无法在 Karmada 中创建资源 +- 若成员集群缺少 API（如旧版本集群缺少 networking.k8s.io/v1/Ingress），Karmada 将跳过对该集群的分发 + +## 常见问题解答 + +### 如何选择 Karmada APIServer 版本？ + +Karmada 项目会在其安装工具（如 Karmada Operator）中自动更新默认的 kube-apiserver 版本以支持最新 Kubernetes API。大多数情况下用户无需修改，即使升级 Karmada 时也无需调整。 + +您可能需要升级 Karmada APIServer 的情况包括： +- 采用新 Kubernetes API：需要利用新版 Kubernetes 特性 +- 修复 CVE 漏洞：解决旧版本存在的安全隐患 + +注意升级需谨慎操作： +- 检查 API 弃用情况：确保工作负载使用的资源类型在目标 Kubernetes 版本中未被弃用 +- 逐步升级：始终逐个次版本升级（如 kube-apiserver@v1.32 → v1.33），避免跨版本升级（如 v1.32 → v1.34）。Kubernetes 依赖渐进式 API 弃用和自动转换机制来安全迁移弃用 API。 + +### 如何处理版本跨度大的成员集群？ + +当成员集群存在 API 版本不兼容时（如部分支持 networking.k8s.io/v1，部分仅支持 v1beta1），目前 Karmada 不会根据成员集群能力自动转换 API 版本。 +建议将过时集群升级至新 Kubernetes 版本。 diff --git a/i18n/zh/docusaurus-plugin-content-docs/version-v1.18/administrator/upgrading/v1.11-v1.12.md b/i18n/zh/docusaurus-plugin-content-docs/version-v1.18/administrator/upgrading/v1.11-v1.12.md index 6331f4933..81947e71b 100644 --- a/i18n/zh/docusaurus-plugin-content-docs/version-v1.18/administrator/upgrading/v1.11-v1.12.md +++ b/i18n/zh/docusaurus-plugin-content-docs/version-v1.18/administrator/upgrading/v1.11-v1.12.md @@ -1,45 +1,45 @@ ---- -title: v1.11 升级到 v1.12 ---- - -遵循[常规升级流程](./README.md)。 - -## 升级后显著变化 - -### API 变化 - -- 在 `Karmada` API 中引入了 `SecretRef`，作为连接外部 etcd 集群的配置，可用于指定包含了连接外部 etcd 集群凭证的 secret。 -- 在 `Karmada` API 中引入了 `extraVolumes` 和 `extraVolumemounts` ，以便为 Karmada API server组件指定额外的卷和卷挂载。 -- 在 `Karmada` API中引入了 `ApiServerService` 字段，作为 Karmada 实例状态的一部分，该字段可用于引用该实例的 API Server 服务。这对于需要发现Karmada 实例的 API Server 服务以执行如设置入口流量等任务的高级操作员来说非常有用。 -- 在`Karmada` API中引入了`CustomCertificate.ApiServerCACert`字段，用于指定包含 Karmada API Server 自定义 CA 证书的secret。 -- 在`Karmada` API中，Karmada API server的 ServiceType 现在被限制为`ClusterIP`、`NodePort`和`LoadBalancer`。 -- 在`Cluster` API中引入了一个新的条件`CompleteAPIEnablements`，用于表示API集合的状态。 -- 在`PropagationPolicy`和`ClusterPropagationPolicy` API中引入了`PreserveResourcesOnDeletion`字段，该字段提供了安全回滚迁移的能力。 -- 在`OverridePolicy`和`ClusterOverridePolicy`中引入了`FieldOverrider`，它提供了覆盖如 ConfigMap 或 Secret 等清单中嵌套的结构化数据的能力。 -- 在`ResourceBinding`和`ClusterResourceBinding` API的`GracefulEvictionTask`中引入了`PurgeMode`。 -- 在`PropagationPolicy`中引入了`StatePreservation`，它将在应用故障迁移场景中保存状态。 - -### 弃用 - -- 在`Karmada` API中，`ExternalEtcd.CAData`、`ExternalEtcd.CertData`和`ExternalEtcd.KeyData`已被弃用，并将在未来的版本中移除。请使用 `SecretRef` 来提供客户端连接凭证。 -- 在版本`v1.11.0`中已弃用的以下启动参数现在已被移除： - * `karmada-agent`: - * --bind-address - * --secure-port - * `karmada-controller-manager`: - * --bind-address - * --secure-port - * `karmada-scheduler-estimator`: - * --bind-address - * --secure-port - * `karmada-scheduler`: - * --bind-address - * --secure-port - * `karmada-descheduler`: - * --bind-address - * --secure-port - -### karmada-controller-manager - -- 引入了特性门控`StatefulFailoverInjection`，用于控制 Karmada 在有状态应用的故障转移期间是否收集和注入状态信息。 +--- +title: v1.11 升级到 v1.12 +--- + +遵循[常规升级流程](./README.md)。 + +## 升级后显著变化 + +### API 变化 + +- 在 `Karmada` API 中引入了 `SecretRef`，作为连接外部 etcd 集群的配置，可用于指定包含了连接外部 etcd 集群凭证的 secret。 +- 在 `Karmada` API 中引入了 `extraVolumes` 和 `extraVolumemounts` ，以便为 Karmada API server组件指定额外的卷和卷挂载。 +- 在 `Karmada` API中引入了 `ApiServerService` 字段，作为 Karmada 实例状态的一部分，该字段可用于引用该实例的 API Server 服务。这对于需要发现Karmada 实例的 API Server 服务以执行如设置入口流量等任务的高级操作员来说非常有用。 +- 在`Karmada` API中引入了`CustomCertificate.ApiServerCACert`字段，用于指定包含 Karmada API Server 自定义 CA 证书的secret。 +- 在`Karmada` API中，Karmada API server的 ServiceType 现在被限制为`ClusterIP`、`NodePort`和`LoadBalancer`。 +- 在`Cluster` API中引入了一个新的条件`CompleteAPIEnablements`，用于表示API集合的状态。 +- 在`PropagationPolicy`和`ClusterPropagationPolicy` API中引入了`PreserveResourcesOnDeletion`字段，该字段提供了安全回滚迁移的能力。 +- 在`OverridePolicy`和`ClusterOverridePolicy`中引入了`FieldOverrider`，它提供了覆盖如 ConfigMap 或 Secret 等清单中嵌套的结构化数据的能力。 +- 在`ResourceBinding`和`ClusterResourceBinding` API的`GracefulEvictionTask`中引入了`PurgeMode`。 +- 在`PropagationPolicy`中引入了`StatePreservation`，它将在应用故障迁移场景中保存状态。 + +### 弃用 + +- 在`Karmada` API中，`ExternalEtcd.CAData`、`ExternalEtcd.CertData`和`ExternalEtcd.KeyData`已被弃用，并将在未来的版本中移除。请使用 `SecretRef` 来提供客户端连接凭证。 +- 在版本`v1.11.0`中已弃用的以下启动参数现在已被移除： + * `karmada-agent`: + * --bind-address + * --secure-port + * `karmada-controller-manager`: + * --bind-address + * --secure-port + * `karmada-scheduler-estimator`: + * --bind-address + * --secure-port + * `karmada-scheduler`: + * --bind-address + * --secure-port + * `karmada-descheduler`: + * --bind-address + * --secure-port + +### karmada-controller-manager + +- 引入了特性门控`StatefulFailoverInjection`，用于控制 Karmada 在有状态应用的故障转移期间是否收集和注入状态信息。 - 特性`Failover`现在默认已禁用，需要显式启用以避免意外事件。 \ No newline at end of file diff --git a/i18n/zh/docusaurus-plugin-content-docs/version-v1.18/userguide/scheduling/multi-component-scheduling.md b/i18n/zh/docusaurus-plugin-content-docs/version-v1.18/userguide/scheduling/multi-component-scheduling.md index cbf892d63..1251774bc 100644 --- a/i18n/zh/docusaurus-plugin-content-docs/version-v1.18/userguide/scheduling/multi-component-scheduling.md +++ b/i18n/zh/docusaurus-plugin-content-docs/version-v1.18/userguide/scheduling/multi-component-scheduling.md @@ -1,89 +1,89 @@ ---- -title: 调度多组件工作负载 ---- - -## 概述 - -许多现代分布式应用程序由具有异构资源需求的多个组件组成。例如，`Flink 集群`包含 `JobManager` 和 `TaskManager` 组件，而 `Ray 集群`则包含 `Head` 和 `Worker` 节点。每个组件通常具有不同的副本数和资源规格。 - -从 Karmada v1.16 开始，`多 Pod 模板调度`功能为这些复杂工作负载提供了精确的资源感知调度能力。这确保了 Karmada 能够正确理解多组件应用程序的总资源需求，并在成员集群之间做出明智的调度决策。 - -## 为什么需要多组件调度？ - -在 v1.16 之前，Karmada 调度器假设工作负载中的所有副本都是相同的，使用单一的 Pod 模板来表示资源需求。这种假设对于 Deployment 等简单应用程序效果良好，但对于多组件工作负载则会导致不准确的情况。 - -考虑一个具有两个组件的 FlinkDeployment： -- JobManager：1 个副本，需要 1 CPU 和 2Gi 内存 -- TaskManager：3 个副本，每个需要 2 CPU 和 4Gi 内存 - -使用传统调度，调度器只能表示一个组件的需求，导致： -- 低估：将 JobManager 配置应用于所有副本 → 仅计算 **4 个 CPU** 总量（实际需要 7 个）→ 存在调度到资源不足集群的风险（**Pod Pending**）。 -- 高估：将 TaskManager 配置应用于所有副本 → 估计 **8 个 CPU** 总量（实际需要 7 个）→ 浪费资源并限制集群选择。 -- 配额计算不准确：FederatedResourceQuota 显示错误的使用情况。 - -使用多组件调度，调度器能够准确理解： -- 所需的总资源：(1 × 1 CPU + 1 × 2Gi) + (3 × 2 CPU + 3 × 4Gi) = 7 CPU 和 14Gi 内存 -- 每个组件的具体需求 -- 集群是否能够容纳所有组件 - -## 支持的工作负载类型 - -多组件调度功能专为具有多个异构 Pod 模板的 CRD 设计。常见用例包括： - -| 类别 | 示例 | -|----------|----------| -| 流处理 | Flink、Kafka Streams、Apache Storm | -| AI/ML 框架 | Ray、TensorFlow、PyTorch、MXNet | -| 机器学习训练 | 参数服务器、分布式训练作业 | -| 批处理 | Spark、Volcano、Hadoop | -| 数据处理 | XGBoost、PaddlePaddle、分布式数据库 | -| 分布式系统 | Elasticsearch、Redis Cluster、数据库集群 | - -Karmada 为流行的 CRD 提供了内置的解释器支持。您可以在[资源解释器文档](../globalview/customizing-resource-interpreter)中找到具有内置解释器支持的 CRD 列表。对于新的 CRD 类型或自定义工作负载，您可以实现自定义解释器（参见[自定义资源解释器](../globalview/customizing-resource-interpreter)）或[联系 Karmada 社区](https://github.com/karmada-io/karmada?tab=readme-ov-file#contact)获取支持。 - -## 功能成熟度和要求 - -多组件调度功能目前处于 **Alpha** 阶段，从 Karmada v1.16 开始提供。作为 Alpha 功能，它在未来版本中可能会发生变化，但核心调度功能已完全可用，可用于评估和测试环境。 - -要使用多组件调度功能，您必须启用 `MultiplePodTemplatesScheduling` 特性门控。该特性门控必须在以下组件上启用： - -- `karmada-controller-manager`：负责解释多组件工作负载规格并在 ResourceBinding 对象中填充组件信息。 -- `karmada-scheduler`：负责基于控制器提取的组件资源需求进行调度决策。 -- `karmada-webhook`：负责验证从资源模板解析的组件信息。 - -## 工作原理 - -下图展示了多组件调度的过程，以 FlinkDeployment 为例。相同的工作流程也适用于其他多组件应用程序，如 RayCluster、TensorFlow 集群和其他分布式系统。 - -![Multi-Component Scheduling Architecture](./../../resources/userguide/scheduling/multi-component-scheduling.png) - -上图显示了调度工作流程： - -1. 多组件应用程序（例如 FlinkDeployment、RayCluster）被提交到 Karmada API Server。需要提供 `PropagationPolicy` 或 `ClusterPropagationPolicy` 来指定工作负载应如何在成员集群之间分发。 - -2. Karmada 控制器利用资源解释器来解析每个组件的资源需求。这些需求存储在 ResourceBinding 对象的 `spec.components` 字段中。 - -3. 调度器基于每个组件逐个评估候选集群，而不是简单地按总资源求和。例如，它检查集群是否可以容纳 JobManager，然后检查同一集群是否也可以容纳所有 TaskManager。这种方法更好地考虑了集群节点之间的资源分布和碎片化。 - -4. 调度器选择可以满足所有组件需求的集群。然后将所有组件作为单个单元调度到该集群。 - -## 限制和约束 - -目前，多组件调度功能具有以下限制： -- 工作负载的所有组件必须调度到同一个集群 -- 尚不支持跨集群组件分发 - -多组件工作负载通常在组件之间存在紧密耦合（共享存储、网络连接、同步需求）。将组件分发到不同集群会在资源管理、故障处理和性能优化方面带来显著的复杂性。 - -我们认识到，将组件分发到不同集群是更好地利用多集群资源的自然演进。这种方法可以实现更灵活的资源分配和提高基础设施的利用率。但是，支持这一点需要： -- 用户定义明确的拆分规则和策略，以确保组件被适当放置 -- 依赖关系和亲和性规范，以防止导致调度成功但无法运行的不兼容放置 - -我们欢迎有关跨集群组件分发的用户反馈和用例。如果您有特定的需求或场景，请随时[联系我们](https://github.com/karmada-io/karmada?tab=readme-ov-file#contact)。 - -## 下一步 - -- [自定义资源解释器](../globalview/customizing-resource-interpreter) - 为您的 CRD 实现解释器 -- [调度器评估器](./scheduler-estimator) - 启用资源感知调度 -- [分发策略](./propagation-policy) - 将资源分发到集群的基础知识 -- [集群资源](./cluster-resources) - 理解集群资源建模 +--- +title: 调度多组件工作负载 +--- + +## 概述 + +许多现代分布式应用程序由具有异构资源需求的多个组件组成。例如，`Flink 集群`包含 `JobManager` 和 `TaskManager` 组件，而 `Ray 集群`则包含 `Head` 和 `Worker` 节点。每个组件通常具有不同的副本数和资源规格。 + +从 Karmada v1.16 开始，`多 Pod 模板调度`功能为这些复杂工作负载提供了精确的资源感知调度能力。这确保了 Karmada 能够正确理解多组件应用程序的总资源需求，并在成员集群之间做出明智的调度决策。 + +## 为什么需要多组件调度？ + +在 v1.16 之前，Karmada 调度器假设工作负载中的所有副本都是相同的，使用单一的 Pod 模板来表示资源需求。这种假设对于 Deployment 等简单应用程序效果良好，但对于多组件工作负载则会导致不准确的情况。 + +考虑一个具有两个组件的 FlinkDeployment： +- JobManager：1 个副本，需要 1 CPU 和 2Gi 内存 +- TaskManager：3 个副本，每个需要 2 CPU 和 4Gi 内存 + +使用传统调度，调度器只能表示一个组件的需求，导致： +- 低估：将 JobManager 配置应用于所有副本 → 仅计算 **4 个 CPU** 总量（实际需要 7 个）→ 存在调度到资源不足集群的风险（**Pod Pending**）。 +- 高估：将 TaskManager 配置应用于所有副本 → 估计 **8 个 CPU** 总量（实际需要 7 个）→ 浪费资源并限制集群选择。 +- 配额计算不准确：FederatedResourceQuota 显示错误的使用情况。 + +使用多组件调度，调度器能够准确理解： +- 所需的总资源：(1 × 1 CPU + 1 × 2Gi) + (3 × 2 CPU + 3 × 4Gi) = 7 CPU 和 14Gi 内存 +- 每个组件的具体需求 +- 集群是否能够容纳所有组件 + +## 支持的工作负载类型 + +多组件调度功能专为具有多个异构 Pod 模板的 CRD 设计。常见用例包括： + +| 类别 | 示例 | +|----------|----------| +| 流处理 | Flink、Kafka Streams、Apache Storm | +| AI/ML 框架 | Ray、TensorFlow、PyTorch、MXNet | +| 机器学习训练 | 参数服务器、分布式训练作业 | +| 批处理 | Spark、Volcano、Hadoop | +| 数据处理 | XGBoost、PaddlePaddle、分布式数据库 | +| 分布式系统 | Elasticsearch、Redis Cluster、数据库集群 | + +Karmada 为流行的 CRD 提供了内置的解释器支持。您可以在[资源解释器文档](../globalview/customizing-resource-interpreter)中找到具有内置解释器支持的 CRD 列表。对于新的 CRD 类型或自定义工作负载，您可以实现自定义解释器（参见[自定义资源解释器](../globalview/customizing-resource-interpreter)）或[联系 Karmada 社区](https://github.com/karmada-io/karmada?tab=readme-ov-file#contact)获取支持。 + +## 功能成熟度和要求 + +多组件调度功能目前处于 **Alpha** 阶段，从 Karmada v1.16 开始提供。作为 Alpha 功能，它在未来版本中可能会发生变化，但核心调度功能已完全可用，可用于评估和测试环境。 + +要使用多组件调度功能，您必须启用 `MultiplePodTemplatesScheduling` 特性门控。该特性门控必须在以下组件上启用： + +- `karmada-controller-manager`：负责解释多组件工作负载规格并在 ResourceBinding 对象中填充组件信息。 +- `karmada-scheduler`：负责基于控制器提取的组件资源需求进行调度决策。 +- `karmada-webhook`：负责验证从资源模板解析的组件信息。 + +## 工作原理 + +下图展示了多组件调度的过程，以 FlinkDeployment 为例。相同的工作流程也适用于其他多组件应用程序，如 RayCluster、TensorFlow 集群和其他分布式系统。 + +![Multi-Component Scheduling Architecture](./../../resources/userguide/scheduling/multi-component-scheduling.png) + +上图显示了调度工作流程： + +1. 多组件应用程序（例如 FlinkDeployment、RayCluster）被提交到 Karmada API Server。需要提供 `PropagationPolicy` 或 `ClusterPropagationPolicy` 来指定工作负载应如何在成员集群之间分发。 + +2. Karmada 控制器利用资源解释器来解析每个组件的资源需求。这些需求存储在 ResourceBinding 对象的 `spec.components` 字段中。 + +3. 调度器基于每个组件逐个评估候选集群，而不是简单地按总资源求和。例如，它检查集群是否可以容纳 JobManager，然后检查同一集群是否也可以容纳所有 TaskManager。这种方法更好地考虑了集群节点之间的资源分布和碎片化。 + +4. 调度器选择可以满足所有组件需求的集群。然后将所有组件作为单个单元调度到该集群。 + +## 限制和约束 + +目前，多组件调度功能具有以下限制： +- 工作负载的所有组件必须调度到同一个集群 +- 尚不支持跨集群组件分发 + +多组件工作负载通常在组件之间存在紧密耦合（共享存储、网络连接、同步需求）。将组件分发到不同集群会在资源管理、故障处理和性能优化方面带来显著的复杂性。 + +我们认识到，将组件分发到不同集群是更好地利用多集群资源的自然演进。这种方法可以实现更灵活的资源分配和提高基础设施的利用率。但是，支持这一点需要： +- 用户定义明确的拆分规则和策略，以确保组件被适当放置 +- 依赖关系和亲和性规范，以防止导致调度成功但无法运行的不兼容放置 + +我们欢迎有关跨集群组件分发的用户反馈和用例。如果您有特定的需求或场景，请随时[联系我们](https://github.com/karmada-io/karmada?tab=readme-ov-file#contact)。 + +## 下一步 + +- [自定义资源解释器](../globalview/customizing-resource-interpreter) - 为您的 CRD 实现解释器 +- [调度器评估器](./scheduler-estimator) - 启用资源感知调度 +- [分发策略](./propagation-policy) - 将资源分发到集群的基础知识 +- [集群资源](./cluster-resources) - 理解集群资源建模 diff --git a/versioned_docs/version-v1.13/administrator/upgrading/v1.11-v1.12.md b/versioned_docs/version-v1.13/administrator/upgrading/v1.11-v1.12.md index 3d52473d3..570bb839e 100644 --- a/versioned_docs/version-v1.13/administrator/upgrading/v1.11-v1.12.md +++ b/versioned_docs/version-v1.13/administrator/upgrading/v1.11-v1.12.md @@ -1,45 +1,45 @@ ---- -title: v1.11 to v1.12 ---- - -Follow the [Regular Upgrading Process](./README.md). - -## Upgrading Notable Changes - -### API Changes - -- Introduced `SecretRef` to `Karmada` API as part of the configuration for connecting to an external etcd cluster can be used to reference a secret that contains credentials for connecting to an external etcd cluster. -- Introduced `extraVolumes` and `extraVolumemounts` to the `Karmada` API to optionally specify extra volumes and volume mounts for the Karmada API server component. -- Introduced `ApiServerService` field to `Karmada` API as part of the Karmada instance status can be used to reference the API Server service for that instance. This is useful for scenarios where higher level operators need to discover the API Server service of a Karmada instance for tasks like setting up ingress traffic. -- Introduced `CustomCertificate.ApiServerCACert` field to `Karmada` API as part of the `Karmada` spec to specify the reference to a secret that contains a custom CA certificate for the Karmada API Server. -- API change: The ServiceType of the Karmada API server in `Karmada` API now has been restricted to `ClusterIP`, `NodePort` and `LoadBalancer`. -- Introduced a new condition `CompleteAPIEnablements` to `Cluster` API to represent the API collection status. -- Introduced `PreserveResourcesOnDeletion` field to both `PropagationPolicy` and `ClusterPropagationPolicy` API, which provides the ability to roll back migration safely. -- API Change: Introduced `FieldOverrider` to both `OverridePolicy` and `ClusterOverridePolicy`, which provides the ability to override structured data nested in manifest like ConfigMap or Secret. -- Introduced `PurgeMode` to `GracefulEvictionTask` in `ResourceBinding` and `ClusterResourceBinding` API. -- Introduced `StatePreservation` to `PropagationPolicy`, which will be used to preserve status in case of application failover. - -### Deprecation - -- `ExternalEtcd.CAData`, `ExternalEtcd.CertData` and `ExternalEtcd.KeyData` in `Karmada` API are deprecated and will be removed in a future version. Use SecretRef for providing client connection credentials. -- The following flags have been deprecated in release `v1.11.0` and now have been removed: - * `karmada-agent`: - * --bind-address - * --secure-port - * `karmada-controller-manager`: - * --bind-address - * --secure-port - * `karmada-scheduler-estimator`: - * --bind-address - * --secure-port - * `karmada-scheduler`: - * --bind-address - * --secure-port - * `karmada-descheduler`: - * --bind-address - * --secure-port - -### karmada-controller-manager - -- Introduced feature gate `StatefulFailoverInjection` to control whether Karmada collects and injects state information during a failover event for stateful application. +--- +title: v1.11 to v1.12 +--- + +Follow the [Regular Upgrading Process](./README.md). + +## Upgrading Notable Changes + +### API Changes + +- Introduced `SecretRef` to `Karmada` API as part of the configuration for connecting to an external etcd cluster can be used to reference a secret that contains credentials for connecting to an external etcd cluster. +- Introduced `extraVolumes` and `extraVolumemounts` to the `Karmada` API to optionally specify extra volumes and volume mounts for the Karmada API server component. +- Introduced `ApiServerService` field to `Karmada` API as part of the Karmada instance status can be used to reference the API Server service for that instance. This is useful for scenarios where higher level operators need to discover the API Server service of a Karmada instance for tasks like setting up ingress traffic. +- Introduced `CustomCertificate.ApiServerCACert` field to `Karmada` API as part of the `Karmada` spec to specify the reference to a secret that contains a custom CA certificate for the Karmada API Server. +- API change: The ServiceType of the Karmada API server in `Karmada` API now has been restricted to `ClusterIP`, `NodePort` and `LoadBalancer`. +- Introduced a new condition `CompleteAPIEnablements` to `Cluster` API to represent the API collection status. +- Introduced `PreserveResourcesOnDeletion` field to both `PropagationPolicy` and `ClusterPropagationPolicy` API, which provides the ability to roll back migration safely. +- API Change: Introduced `FieldOverrider` to both `OverridePolicy` and `ClusterOverridePolicy`, which provides the ability to override structured data nested in manifest like ConfigMap or Secret. +- Introduced `PurgeMode` to `GracefulEvictionTask` in `ResourceBinding` and `ClusterResourceBinding` API. +- Introduced `StatePreservation` to `PropagationPolicy`, which will be used to preserve status in case of application failover. + +### Deprecation + +- `ExternalEtcd.CAData`, `ExternalEtcd.CertData` and `ExternalEtcd.KeyData` in `Karmada` API are deprecated and will be removed in a future version. Use SecretRef for providing client connection credentials. +- The following flags have been deprecated in release `v1.11.0` and now have been removed: + * `karmada-agent`: + * --bind-address + * --secure-port + * `karmada-controller-manager`: + * --bind-address + * --secure-port + * `karmada-scheduler-estimator`: + * --bind-address + * --secure-port + * `karmada-scheduler`: + * --bind-address + * --secure-port + * `karmada-descheduler`: + * --bind-address + * --secure-port + +### karmada-controller-manager + +- Introduced feature gate `StatefulFailoverInjection` to control whether Karmada collects and injects state information during a failover event for stateful application. - The feature `Failover` now has been disabled by default, which should be explicitly enabled to avoid unexpected incidents. \ No newline at end of file diff --git a/versioned_docs/version-v1.14/administrator/compatibility/compatibility.md b/versioned_docs/version-v1.14/administrator/compatibility/compatibility.md index 4984a9946..14ebbcaf3 100644 --- a/versioned_docs/version-v1.14/administrator/compatibility/compatibility.md +++ b/versioned_docs/version-v1.14/administrator/compatibility/compatibility.md @@ -1,76 +1,76 @@ ---- -title: Kubernetes Compatibility ---- - -This document provides a comprehensive guide to Karmada's compatibility with Kubernetes versions, focusing on two -primary dimensions: -- Karmada control plane APIs support: How many APIs are supported? -- Kubernetes versions support: How many Kubernetes versions are supported? - -This document helps administrators understand how Karmada manages resources across clusters with mixed Kubernetes versions. -It ensures safe propagation by respecting each cluster’s API capabilities and provides guidelines for maintaining -compatibility during upgrades or migrations. - -## Karmada control plane APIs support - -Karmada supports all Kubernetes APIs available in the version of kube-apiserver it uses. For example, if Karmada APIServer -uses kube-apiserver@v1.32, it inherits support for every API (e.g., Deployment, Service, Ingress) and API version -(e.g., apps/v1, networking.k8s.io/v1) available in Kubernetes v1.32. - -Beyond native Kubernetes APIs, Karmada extends its capabilities through Custom Resource Definitions (CRDs) and -Aggregated APIServer, the same extension mechanisms used in Kubernetes itself: -- **CRD Extensions**: Most Karmada-specific APIs (e.g., PropagationPolicy, OverridePolicy) are implemented as CRDs. -Users can also define custom CRDs in Karmada and propagate them to member clusters, following the same workflow as -native Kubernetes APIs. -- **Aggregated APIServer**: Karmada’s Cluster API is extended by karmada-aggregated-apiserver, thus users can directly -query member cluster resources (e.g., Nodes, Pods) through Karmada’s unified API endpoint. -Users can extend Karmada’s API surface in the same way they extend Kubernetes -- whether for custom resources or -third-party integrations. - -To view all supported APIs, run the `karmadactl api-resources` command against Karmada, this lists all supported API -including Kubernetes API and extended APIs, the output like: -``` -# karmadactl api-resources -NAME SHORTNAMES APIVERSION NAMESPACED KIND -pods po v1 true Pod -deployments deploy apps/v1 true Deployment -clusters cluster.karmada.io/v1alpha1 false Cluster -overridepolicies op policy.karmada.io/v1alpha1 true OverridePolicy -propagationpolicies pp policy.karmada.io/v1alpha1 true PropagationPolicy -... -``` - -## Kubernetes versions support - -Karmada manages Kubernetes clusters using a minimal set of stable APIs and endpoints, ensuring broad compatibility -across Kubernetes versions. Each Karmada release integrates the latest Kubernetes client libraries and tests -compatibility with the latest 10 Kubernetes versions. For example, Karmada v1.14 uses Kubernetes client v1.32 and is -validated against Kubernetes versions from v1.23 to v1.32. - -A resource can be propagated to member clusters only if both Karmada and the target cluster support its API. -- If Karmada does not recognize the API (e.g., unsupported CRDs or deprecated APIs), the resource cannot be created in Karmada. -- If a member cluster lacks the API (e.g., an older cluster missing networking.k8s.io/v1/Ingress), Karmada skips propagation to that cluster. - -## FAQ - -### How to choose the version of Karmada APIServer? - -The Karmada project automatically updates the default kube-apiserver version in its installation tools (e.g., Karmada Operator) -to support the latest Kubernetes APIs. In most cases, users do not need to change it, even in case of upgrading Karmada. - -You may need to upgrade Karmada APIServer in cases such as: -- Adopting New Kubernetes APIs: To leverage features introduced in newer Kubernetes versions. -- Addressing CVEs: To resolve security vulnerabilities present in older versions. - -Note that upgrading should be taken very carefully: - -- Review API Deprecations: Ensure resource types used in your workloads are not deprecated in the target Kubernetes version. -- Incremental Upgrades: Always upgrade one minor version at a time (e.g., kube-apiserver@v1.32 → v1.33). -Avoid skipping versions (e.g., v1.32 → v1.34), as Kubernetes relies on incremental API deprecation and automatic -conversion mechanisms to safely migrate deprecated APIs to newer versions. - -### How to handle member clusters with large version gaps? - -For scenarios where member clusters span incompatible API versions (e.g., some support networking.k8s.io/v1, others only v1beta1), -Currently, Karmada does not automatically convert API versions according to the capacity of member clusters, instead, it is -recommended to upgrade the outdated clusters to a newer Kubernetes version. +--- +title: Kubernetes Compatibility +--- + +This document provides a comprehensive guide to Karmada's compatibility with Kubernetes versions, focusing on two +primary dimensions: +- Karmada control plane APIs support: How many APIs are supported? +- Kubernetes versions support: How many Kubernetes versions are supported? + +This document helps administrators understand how Karmada manages resources across clusters with mixed Kubernetes versions. +It ensures safe propagation by respecting each cluster’s API capabilities and provides guidelines for maintaining +compatibility during upgrades or migrations. + +## Karmada control plane APIs support + +Karmada supports all Kubernetes APIs available in the version of kube-apiserver it uses. For example, if Karmada APIServer +uses kube-apiserver@v1.32, it inherits support for every API (e.g., Deployment, Service, Ingress) and API version +(e.g., apps/v1, networking.k8s.io/v1) available in Kubernetes v1.32. + +Beyond native Kubernetes APIs, Karmada extends its capabilities through Custom Resource Definitions (CRDs) and +Aggregated APIServer, the same extension mechanisms used in Kubernetes itself: +- **CRD Extensions**: Most Karmada-specific APIs (e.g., PropagationPolicy, OverridePolicy) are implemented as CRDs. +Users can also define custom CRDs in Karmada and propagate them to member clusters, following the same workflow as +native Kubernetes APIs. +- **Aggregated APIServer**: Karmada’s Cluster API is extended by karmada-aggregated-apiserver, thus users can directly +query member cluster resources (e.g., Nodes, Pods) through Karmada’s unified API endpoint. +Users can extend Karmada’s API surface in the same way they extend Kubernetes -- whether for custom resources or +third-party integrations. + +To view all supported APIs, run the `karmadactl api-resources` command against Karmada, this lists all supported API +including Kubernetes API and extended APIs, the output like: +``` +# karmadactl api-resources +NAME SHORTNAMES APIVERSION NAMESPACED KIND +pods po v1 true Pod +deployments deploy apps/v1 true Deployment +clusters cluster.karmada.io/v1alpha1 false Cluster +overridepolicies op policy.karmada.io/v1alpha1 true OverridePolicy +propagationpolicies pp policy.karmada.io/v1alpha1 true PropagationPolicy +... +``` + +## Kubernetes versions support + +Karmada manages Kubernetes clusters using a minimal set of stable APIs and endpoints, ensuring broad compatibility +across Kubernetes versions. Each Karmada release integrates the latest Kubernetes client libraries and tests +compatibility with the latest 10 Kubernetes versions. For example, Karmada v1.14 uses Kubernetes client v1.32 and is +validated against Kubernetes versions from v1.23 to v1.32. + +A resource can be propagated to member clusters only if both Karmada and the target cluster support its API. +- If Karmada does not recognize the API (e.g., unsupported CRDs or deprecated APIs), the resource cannot be created in Karmada. +- If a member cluster lacks the API (e.g., an older cluster missing networking.k8s.io/v1/Ingress), Karmada skips propagation to that cluster. + +## FAQ + +### How to choose the version of Karmada APIServer? + +The Karmada project automatically updates the default kube-apiserver version in its installation tools (e.g., Karmada Operator) +to support the latest Kubernetes APIs. In most cases, users do not need to change it, even in case of upgrading Karmada. + +You may need to upgrade Karmada APIServer in cases such as: +- Adopting New Kubernetes APIs: To leverage features introduced in newer Kubernetes versions. +- Addressing CVEs: To resolve security vulnerabilities present in older versions. + +Note that upgrading should be taken very carefully: + +- Review API Deprecations: Ensure resource types used in your workloads are not deprecated in the target Kubernetes version. +- Incremental Upgrades: Always upgrade one minor version at a time (e.g., kube-apiserver@v1.32 → v1.33). +Avoid skipping versions (e.g., v1.32 → v1.34), as Kubernetes relies on incremental API deprecation and automatic +conversion mechanisms to safely migrate deprecated APIs to newer versions. + +### How to handle member clusters with large version gaps? + +For scenarios where member clusters span incompatible API versions (e.g., some support networking.k8s.io/v1, others only v1beta1), +Currently, Karmada does not automatically convert API versions according to the capacity of member clusters, instead, it is +recommended to upgrade the outdated clusters to a newer Kubernetes version. diff --git a/versioned_docs/version-v1.14/administrator/upgrading/v1.11-v1.12.md b/versioned_docs/version-v1.14/administrator/upgrading/v1.11-v1.12.md index 3d52473d3..570bb839e 100644 --- a/versioned_docs/version-v1.14/administrator/upgrading/v1.11-v1.12.md +++ b/versioned_docs/version-v1.14/administrator/upgrading/v1.11-v1.12.md @@ -1,45 +1,45 @@ ---- -title: v1.11 to v1.12 ---- - -Follow the [Regular Upgrading Process](./README.md). - -## Upgrading Notable Changes - -### API Changes - -- Introduced `SecretRef` to `Karmada` API as part of the configuration for connecting to an external etcd cluster can be used to reference a secret that contains credentials for connecting to an external etcd cluster. -- Introduced `extraVolumes` and `extraVolumemounts` to the `Karmada` API to optionally specify extra volumes and volume mounts for the Karmada API server component. -- Introduced `ApiServerService` field to `Karmada` API as part of the Karmada instance status can be used to reference the API Server service for that instance. This is useful for scenarios where higher level operators need to discover the API Server service of a Karmada instance for tasks like setting up ingress traffic. -- Introduced `CustomCertificate.ApiServerCACert` field to `Karmada` API as part of the `Karmada` spec to specify the reference to a secret that contains a custom CA certificate for the Karmada API Server. -- API change: The ServiceType of the Karmada API server in `Karmada` API now has been restricted to `ClusterIP`, `NodePort` and `LoadBalancer`. -- Introduced a new condition `CompleteAPIEnablements` to `Cluster` API to represent the API collection status. -- Introduced `PreserveResourcesOnDeletion` field to both `PropagationPolicy` and `ClusterPropagationPolicy` API, which provides the ability to roll back migration safely. -- API Change: Introduced `FieldOverrider` to both `OverridePolicy` and `ClusterOverridePolicy`, which provides the ability to override structured data nested in manifest like ConfigMap or Secret. -- Introduced `PurgeMode` to `GracefulEvictionTask` in `ResourceBinding` and `ClusterResourceBinding` API. -- Introduced `StatePreservation` to `PropagationPolicy`, which will be used to preserve status in case of application failover. - -### Deprecation - -- `ExternalEtcd.CAData`, `ExternalEtcd.CertData` and `ExternalEtcd.KeyData` in `Karmada` API are deprecated and will be removed in a future version. Use SecretRef for providing client connection credentials. -- The following flags have been deprecated in release `v1.11.0` and now have been removed: - * `karmada-agent`: - * --bind-address - * --secure-port - * `karmada-controller-manager`: - * --bind-address - * --secure-port - * `karmada-scheduler-estimator`: - * --bind-address - * --secure-port - * `karmada-scheduler`: - * --bind-address - * --secure-port - * `karmada-descheduler`: - * --bind-address - * --secure-port - -### karmada-controller-manager - -- Introduced feature gate `StatefulFailoverInjection` to control whether Karmada collects and injects state information during a failover event for stateful application. +--- +title: v1.11 to v1.12 +--- + +Follow the [Regular Upgrading Process](./README.md). + +## Upgrading Notable Changes + +### API Changes + +- Introduced `SecretRef` to `Karmada` API as part of the configuration for connecting to an external etcd cluster can be used to reference a secret that contains credentials for connecting to an external etcd cluster. +- Introduced `extraVolumes` and `extraVolumemounts` to the `Karmada` API to optionally specify extra volumes and volume mounts for the Karmada API server component. +- Introduced `ApiServerService` field to `Karmada` API as part of the Karmada instance status can be used to reference the API Server service for that instance. This is useful for scenarios where higher level operators need to discover the API Server service of a Karmada instance for tasks like setting up ingress traffic. +- Introduced `CustomCertificate.ApiServerCACert` field to `Karmada` API as part of the `Karmada` spec to specify the reference to a secret that contains a custom CA certificate for the Karmada API Server. +- API change: The ServiceType of the Karmada API server in `Karmada` API now has been restricted to `ClusterIP`, `NodePort` and `LoadBalancer`. +- Introduced a new condition `CompleteAPIEnablements` to `Cluster` API to represent the API collection status. +- Introduced `PreserveResourcesOnDeletion` field to both `PropagationPolicy` and `ClusterPropagationPolicy` API, which provides the ability to roll back migration safely. +- API Change: Introduced `FieldOverrider` to both `OverridePolicy` and `ClusterOverridePolicy`, which provides the ability to override structured data nested in manifest like ConfigMap or Secret. +- Introduced `PurgeMode` to `GracefulEvictionTask` in `ResourceBinding` and `ClusterResourceBinding` API. +- Introduced `StatePreservation` to `PropagationPolicy`, which will be used to preserve status in case of application failover. + +### Deprecation + +- `ExternalEtcd.CAData`, `ExternalEtcd.CertData` and `ExternalEtcd.KeyData` in `Karmada` API are deprecated and will be removed in a future version. Use SecretRef for providing client connection credentials. +- The following flags have been deprecated in release `v1.11.0` and now have been removed: + * `karmada-agent`: + * --bind-address + * --secure-port + * `karmada-controller-manager`: + * --bind-address + * --secure-port + * `karmada-scheduler-estimator`: + * --bind-address + * --secure-port + * `karmada-scheduler`: + * --bind-address + * --secure-port + * `karmada-descheduler`: + * --bind-address + * --secure-port + +### karmada-controller-manager + +- Introduced feature gate `StatefulFailoverInjection` to control whether Karmada collects and injects state information during a failover event for stateful application. - The feature `Failover` now has been disabled by default, which should be explicitly enabled to avoid unexpected incidents. \ No newline at end of file diff --git a/versioned_docs/version-v1.15/administrator/compatibility/compatibility.md b/versioned_docs/version-v1.15/administrator/compatibility/compatibility.md index 4984a9946..14ebbcaf3 100644 --- a/versioned_docs/version-v1.15/administrator/compatibility/compatibility.md +++ b/versioned_docs/version-v1.15/administrator/compatibility/compatibility.md @@ -1,76 +1,76 @@ ---- -title: Kubernetes Compatibility ---- - -This document provides a comprehensive guide to Karmada's compatibility with Kubernetes versions, focusing on two -primary dimensions: -- Karmada control plane APIs support: How many APIs are supported? -- Kubernetes versions support: How many Kubernetes versions are supported? - -This document helps administrators understand how Karmada manages resources across clusters with mixed Kubernetes versions. -It ensures safe propagation by respecting each cluster’s API capabilities and provides guidelines for maintaining -compatibility during upgrades or migrations. - -## Karmada control plane APIs support - -Karmada supports all Kubernetes APIs available in the version of kube-apiserver it uses. For example, if Karmada APIServer -uses kube-apiserver@v1.32, it inherits support for every API (e.g., Deployment, Service, Ingress) and API version -(e.g., apps/v1, networking.k8s.io/v1) available in Kubernetes v1.32. - -Beyond native Kubernetes APIs, Karmada extends its capabilities through Custom Resource Definitions (CRDs) and -Aggregated APIServer, the same extension mechanisms used in Kubernetes itself: -- **CRD Extensions**: Most Karmada-specific APIs (e.g., PropagationPolicy, OverridePolicy) are implemented as CRDs. -Users can also define custom CRDs in Karmada and propagate them to member clusters, following the same workflow as -native Kubernetes APIs. -- **Aggregated APIServer**: Karmada’s Cluster API is extended by karmada-aggregated-apiserver, thus users can directly -query member cluster resources (e.g., Nodes, Pods) through Karmada’s unified API endpoint. -Users can extend Karmada’s API surface in the same way they extend Kubernetes -- whether for custom resources or -third-party integrations. - -To view all supported APIs, run the `karmadactl api-resources` command against Karmada, this lists all supported API -including Kubernetes API and extended APIs, the output like: -``` -# karmadactl api-resources -NAME SHORTNAMES APIVERSION NAMESPACED KIND -pods po v1 true Pod -deployments deploy apps/v1 true Deployment -clusters cluster.karmada.io/v1alpha1 false Cluster -overridepolicies op policy.karmada.io/v1alpha1 true OverridePolicy -propagationpolicies pp policy.karmada.io/v1alpha1 true PropagationPolicy -... -``` - -## Kubernetes versions support - -Karmada manages Kubernetes clusters using a minimal set of stable APIs and endpoints, ensuring broad compatibility -across Kubernetes versions. Each Karmada release integrates the latest Kubernetes client libraries and tests -compatibility with the latest 10 Kubernetes versions. For example, Karmada v1.14 uses Kubernetes client v1.32 and is -validated against Kubernetes versions from v1.23 to v1.32. - -A resource can be propagated to member clusters only if both Karmada and the target cluster support its API. -- If Karmada does not recognize the API (e.g., unsupported CRDs or deprecated APIs), the resource cannot be created in Karmada. -- If a member cluster lacks the API (e.g., an older cluster missing networking.k8s.io/v1/Ingress), Karmada skips propagation to that cluster. - -## FAQ - -### How to choose the version of Karmada APIServer? - -The Karmada project automatically updates the default kube-apiserver version in its installation tools (e.g., Karmada Operator) -to support the latest Kubernetes APIs. In most cases, users do not need to change it, even in case of upgrading Karmada. - -You may need to upgrade Karmada APIServer in cases such as: -- Adopting New Kubernetes APIs: To leverage features introduced in newer Kubernetes versions. -- Addressing CVEs: To resolve security vulnerabilities present in older versions. - -Note that upgrading should be taken very carefully: - -- Review API Deprecations: Ensure resource types used in your workloads are not deprecated in the target Kubernetes version. -- Incremental Upgrades: Always upgrade one minor version at a time (e.g., kube-apiserver@v1.32 → v1.33). -Avoid skipping versions (e.g., v1.32 → v1.34), as Kubernetes relies on incremental API deprecation and automatic -conversion mechanisms to safely migrate deprecated APIs to newer versions. - -### How to handle member clusters with large version gaps? - -For scenarios where member clusters span incompatible API versions (e.g., some support networking.k8s.io/v1, others only v1beta1), -Currently, Karmada does not automatically convert API versions according to the capacity of member clusters, instead, it is -recommended to upgrade the outdated clusters to a newer Kubernetes version. +--- +title: Kubernetes Compatibility +--- + +This document provides a comprehensive guide to Karmada's compatibility with Kubernetes versions, focusing on two +primary dimensions: +- Karmada control plane APIs support: How many APIs are supported? +- Kubernetes versions support: How many Kubernetes versions are supported? + +This document helps administrators understand how Karmada manages resources across clusters with mixed Kubernetes versions. +It ensures safe propagation by respecting each cluster’s API capabilities and provides guidelines for maintaining +compatibility during upgrades or migrations. + +## Karmada control plane APIs support + +Karmada supports all Kubernetes APIs available in the version of kube-apiserver it uses. For example, if Karmada APIServer +uses kube-apiserver@v1.32, it inherits support for every API (e.g., Deployment, Service, Ingress) and API version +(e.g., apps/v1, networking.k8s.io/v1) available in Kubernetes v1.32. + +Beyond native Kubernetes APIs, Karmada extends its capabilities through Custom Resource Definitions (CRDs) and +Aggregated APIServer, the same extension mechanisms used in Kubernetes itself: +- **CRD Extensions**: Most Karmada-specific APIs (e.g., PropagationPolicy, OverridePolicy) are implemented as CRDs. +Users can also define custom CRDs in Karmada and propagate them to member clusters, following the same workflow as +native Kubernetes APIs. +- **Aggregated APIServer**: Karmada’s Cluster API is extended by karmada-aggregated-apiserver, thus users can directly +query member cluster resources (e.g., Nodes, Pods) through Karmada’s unified API endpoint. +Users can extend Karmada’s API surface in the same way they extend Kubernetes -- whether for custom resources or +third-party integrations. + +To view all supported APIs, run the `karmadactl api-resources` command against Karmada, this lists all supported API +including Kubernetes API and extended APIs, the output like: +``` +# karmadactl api-resources +NAME SHORTNAMES APIVERSION NAMESPACED KIND +pods po v1 true Pod +deployments deploy apps/v1 true Deployment +clusters cluster.karmada.io/v1alpha1 false Cluster +overridepolicies op policy.karmada.io/v1alpha1 true OverridePolicy +propagationpolicies pp policy.karmada.io/v1alpha1 true PropagationPolicy +... +``` + +## Kubernetes versions support + +Karmada manages Kubernetes clusters using a minimal set of stable APIs and endpoints, ensuring broad compatibility +across Kubernetes versions. Each Karmada release integrates the latest Kubernetes client libraries and tests +compatibility with the latest 10 Kubernetes versions. For example, Karmada v1.14 uses Kubernetes client v1.32 and is +validated against Kubernetes versions from v1.23 to v1.32. + +A resource can be propagated to member clusters only if both Karmada and the target cluster support its API. +- If Karmada does not recognize the API (e.g., unsupported CRDs or deprecated APIs), the resource cannot be created in Karmada. +- If a member cluster lacks the API (e.g., an older cluster missing networking.k8s.io/v1/Ingress), Karmada skips propagation to that cluster. + +## FAQ + +### How to choose the version of Karmada APIServer? + +The Karmada project automatically updates the default kube-apiserver version in its installation tools (e.g., Karmada Operator) +to support the latest Kubernetes APIs. In most cases, users do not need to change it, even in case of upgrading Karmada. + +You may need to upgrade Karmada APIServer in cases such as: +- Adopting New Kubernetes APIs: To leverage features introduced in newer Kubernetes versions. +- Addressing CVEs: To resolve security vulnerabilities present in older versions. + +Note that upgrading should be taken very carefully: + +- Review API Deprecations: Ensure resource types used in your workloads are not deprecated in the target Kubernetes version. +- Incremental Upgrades: Always upgrade one minor version at a time (e.g., kube-apiserver@v1.32 → v1.33). +Avoid skipping versions (e.g., v1.32 → v1.34), as Kubernetes relies on incremental API deprecation and automatic +conversion mechanisms to safely migrate deprecated APIs to newer versions. + +### How to handle member clusters with large version gaps? + +For scenarios where member clusters span incompatible API versions (e.g., some support networking.k8s.io/v1, others only v1beta1), +Currently, Karmada does not automatically convert API versions according to the capacity of member clusters, instead, it is +recommended to upgrade the outdated clusters to a newer Kubernetes version. diff --git a/versioned_docs/version-v1.15/administrator/upgrading/v1.11-v1.12.md b/versioned_docs/version-v1.15/administrator/upgrading/v1.11-v1.12.md index 3d52473d3..570bb839e 100644 --- a/versioned_docs/version-v1.15/administrator/upgrading/v1.11-v1.12.md +++ b/versioned_docs/version-v1.15/administrator/upgrading/v1.11-v1.12.md @@ -1,45 +1,45 @@ ---- -title: v1.11 to v1.12 ---- - -Follow the [Regular Upgrading Process](./README.md). - -## Upgrading Notable Changes - -### API Changes - -- Introduced `SecretRef` to `Karmada` API as part of the configuration for connecting to an external etcd cluster can be used to reference a secret that contains credentials for connecting to an external etcd cluster. -- Introduced `extraVolumes` and `extraVolumemounts` to the `Karmada` API to optionally specify extra volumes and volume mounts for the Karmada API server component. -- Introduced `ApiServerService` field to `Karmada` API as part of the Karmada instance status can be used to reference the API Server service for that instance. This is useful for scenarios where higher level operators need to discover the API Server service of a Karmada instance for tasks like setting up ingress traffic. -- Introduced `CustomCertificate.ApiServerCACert` field to `Karmada` API as part of the `Karmada` spec to specify the reference to a secret that contains a custom CA certificate for the Karmada API Server. -- API change: The ServiceType of the Karmada API server in `Karmada` API now has been restricted to `ClusterIP`, `NodePort` and `LoadBalancer`. -- Introduced a new condition `CompleteAPIEnablements` to `Cluster` API to represent the API collection status. -- Introduced `PreserveResourcesOnDeletion` field to both `PropagationPolicy` and `ClusterPropagationPolicy` API, which provides the ability to roll back migration safely. -- API Change: Introduced `FieldOverrider` to both `OverridePolicy` and `ClusterOverridePolicy`, which provides the ability to override structured data nested in manifest like ConfigMap or Secret. -- Introduced `PurgeMode` to `GracefulEvictionTask` in `ResourceBinding` and `ClusterResourceBinding` API. -- Introduced `StatePreservation` to `PropagationPolicy`, which will be used to preserve status in case of application failover. - -### Deprecation - -- `ExternalEtcd.CAData`, `ExternalEtcd.CertData` and `ExternalEtcd.KeyData` in `Karmada` API are deprecated and will be removed in a future version. Use SecretRef for providing client connection credentials. -- The following flags have been deprecated in release `v1.11.0` and now have been removed: - * `karmada-agent`: - * --bind-address - * --secure-port - * `karmada-controller-manager`: - * --bind-address - * --secure-port - * `karmada-scheduler-estimator`: - * --bind-address - * --secure-port - * `karmada-scheduler`: - * --bind-address - * --secure-port - * `karmada-descheduler`: - * --bind-address - * --secure-port - -### karmada-controller-manager - -- Introduced feature gate `StatefulFailoverInjection` to control whether Karmada collects and injects state information during a failover event for stateful application. +--- +title: v1.11 to v1.12 +--- + +Follow the [Regular Upgrading Process](./README.md). + +## Upgrading Notable Changes + +### API Changes + +- Introduced `SecretRef` to `Karmada` API as part of the configuration for connecting to an external etcd cluster can be used to reference a secret that contains credentials for connecting to an external etcd cluster. +- Introduced `extraVolumes` and `extraVolumemounts` to the `Karmada` API to optionally specify extra volumes and volume mounts for the Karmada API server component. +- Introduced `ApiServerService` field to `Karmada` API as part of the Karmada instance status can be used to reference the API Server service for that instance. This is useful for scenarios where higher level operators need to discover the API Server service of a Karmada instance for tasks like setting up ingress traffic. +- Introduced `CustomCertificate.ApiServerCACert` field to `Karmada` API as part of the `Karmada` spec to specify the reference to a secret that contains a custom CA certificate for the Karmada API Server. +- API change: The ServiceType of the Karmada API server in `Karmada` API now has been restricted to `ClusterIP`, `NodePort` and `LoadBalancer`. +- Introduced a new condition `CompleteAPIEnablements` to `Cluster` API to represent the API collection status. +- Introduced `PreserveResourcesOnDeletion` field to both `PropagationPolicy` and `ClusterPropagationPolicy` API, which provides the ability to roll back migration safely. +- API Change: Introduced `FieldOverrider` to both `OverridePolicy` and `ClusterOverridePolicy`, which provides the ability to override structured data nested in manifest like ConfigMap or Secret. +- Introduced `PurgeMode` to `GracefulEvictionTask` in `ResourceBinding` and `ClusterResourceBinding` API. +- Introduced `StatePreservation` to `PropagationPolicy`, which will be used to preserve status in case of application failover. + +### Deprecation + +- `ExternalEtcd.CAData`, `ExternalEtcd.CertData` and `ExternalEtcd.KeyData` in `Karmada` API are deprecated and will be removed in a future version. Use SecretRef for providing client connection credentials. +- The following flags have been deprecated in release `v1.11.0` and now have been removed: + * `karmada-agent`: + * --bind-address + * --secure-port + * `karmada-controller-manager`: + * --bind-address + * --secure-port + * `karmada-scheduler-estimator`: + * --bind-address + * --secure-port + * `karmada-scheduler`: + * --bind-address + * --secure-port + * `karmada-descheduler`: + * --bind-address + * --secure-port + +### karmada-controller-manager + +- Introduced feature gate `StatefulFailoverInjection` to control whether Karmada collects and injects state information during a failover event for stateful application. - The feature `Failover` now has been disabled by default, which should be explicitly enabled to avoid unexpected incidents. \ No newline at end of file diff --git a/versioned_docs/version-v1.16/administrator/compatibility/compatibility.md b/versioned_docs/version-v1.16/administrator/compatibility/compatibility.md index 4984a9946..14ebbcaf3 100644 --- a/versioned_docs/version-v1.16/administrator/compatibility/compatibility.md +++ b/versioned_docs/version-v1.16/administrator/compatibility/compatibility.md @@ -1,76 +1,76 @@ ---- -title: Kubernetes Compatibility ---- - -This document provides a comprehensive guide to Karmada's compatibility with Kubernetes versions, focusing on two -primary dimensions: -- Karmada control plane APIs support: How many APIs are supported? -- Kubernetes versions support: How many Kubernetes versions are supported? - -This document helps administrators understand how Karmada manages resources across clusters with mixed Kubernetes versions. -It ensures safe propagation by respecting each cluster’s API capabilities and provides guidelines for maintaining -compatibility during upgrades or migrations. - -## Karmada control plane APIs support - -Karmada supports all Kubernetes APIs available in the version of kube-apiserver it uses. For example, if Karmada APIServer -uses kube-apiserver@v1.32, it inherits support for every API (e.g., Deployment, Service, Ingress) and API version -(e.g., apps/v1, networking.k8s.io/v1) available in Kubernetes v1.32. - -Beyond native Kubernetes APIs, Karmada extends its capabilities through Custom Resource Definitions (CRDs) and -Aggregated APIServer, the same extension mechanisms used in Kubernetes itself: -- **CRD Extensions**: Most Karmada-specific APIs (e.g., PropagationPolicy, OverridePolicy) are implemented as CRDs. -Users can also define custom CRDs in Karmada and propagate them to member clusters, following the same workflow as -native Kubernetes APIs. -- **Aggregated APIServer**: Karmada’s Cluster API is extended by karmada-aggregated-apiserver, thus users can directly -query member cluster resources (e.g., Nodes, Pods) through Karmada’s unified API endpoint. -Users can extend Karmada’s API surface in the same way they extend Kubernetes -- whether for custom resources or -third-party integrations. - -To view all supported APIs, run the `karmadactl api-resources` command against Karmada, this lists all supported API -including Kubernetes API and extended APIs, the output like: -``` -# karmadactl api-resources -NAME SHORTNAMES APIVERSION NAMESPACED KIND -pods po v1 true Pod -deployments deploy apps/v1 true Deployment -clusters cluster.karmada.io/v1alpha1 false Cluster -overridepolicies op policy.karmada.io/v1alpha1 true OverridePolicy -propagationpolicies pp policy.karmada.io/v1alpha1 true PropagationPolicy -... -``` - -## Kubernetes versions support - -Karmada manages Kubernetes clusters using a minimal set of stable APIs and endpoints, ensuring broad compatibility -across Kubernetes versions. Each Karmada release integrates the latest Kubernetes client libraries and tests -compatibility with the latest 10 Kubernetes versions. For example, Karmada v1.14 uses Kubernetes client v1.32 and is -validated against Kubernetes versions from v1.23 to v1.32. - -A resource can be propagated to member clusters only if both Karmada and the target cluster support its API. -- If Karmada does not recognize the API (e.g., unsupported CRDs or deprecated APIs), the resource cannot be created in Karmada. -- If a member cluster lacks the API (e.g., an older cluster missing networking.k8s.io/v1/Ingress), Karmada skips propagation to that cluster. - -## FAQ - -### How to choose the version of Karmada APIServer? - -The Karmada project automatically updates the default kube-apiserver version in its installation tools (e.g., Karmada Operator) -to support the latest Kubernetes APIs. In most cases, users do not need to change it, even in case of upgrading Karmada. - -You may need to upgrade Karmada APIServer in cases such as: -- Adopting New Kubernetes APIs: To leverage features introduced in newer Kubernetes versions. -- Addressing CVEs: To resolve security vulnerabilities present in older versions. - -Note that upgrading should be taken very carefully: - -- Review API Deprecations: Ensure resource types used in your workloads are not deprecated in the target Kubernetes version. -- Incremental Upgrades: Always upgrade one minor version at a time (e.g., kube-apiserver@v1.32 → v1.33). -Avoid skipping versions (e.g., v1.32 → v1.34), as Kubernetes relies on incremental API deprecation and automatic -conversion mechanisms to safely migrate deprecated APIs to newer versions. - -### How to handle member clusters with large version gaps? - -For scenarios where member clusters span incompatible API versions (e.g., some support networking.k8s.io/v1, others only v1beta1), -Currently, Karmada does not automatically convert API versions according to the capacity of member clusters, instead, it is -recommended to upgrade the outdated clusters to a newer Kubernetes version. +--- +title: Kubernetes Compatibility +--- + +This document provides a comprehensive guide to Karmada's compatibility with Kubernetes versions, focusing on two +primary dimensions: +- Karmada control plane APIs support: How many APIs are supported? +- Kubernetes versions support: How many Kubernetes versions are supported? + +This document helps administrators understand how Karmada manages resources across clusters with mixed Kubernetes versions. +It ensures safe propagation by respecting each cluster’s API capabilities and provides guidelines for maintaining +compatibility during upgrades or migrations. + +## Karmada control plane APIs support + +Karmada supports all Kubernetes APIs available in the version of kube-apiserver it uses. For example, if Karmada APIServer +uses kube-apiserver@v1.32, it inherits support for every API (e.g., Deployment, Service, Ingress) and API version +(e.g., apps/v1, networking.k8s.io/v1) available in Kubernetes v1.32. + +Beyond native Kubernetes APIs, Karmada extends its capabilities through Custom Resource Definitions (CRDs) and +Aggregated APIServer, the same extension mechanisms used in Kubernetes itself: +- **CRD Extensions**: Most Karmada-specific APIs (e.g., PropagationPolicy, OverridePolicy) are implemented as CRDs. +Users can also define custom CRDs in Karmada and propagate them to member clusters, following the same workflow as +native Kubernetes APIs. +- **Aggregated APIServer**: Karmada’s Cluster API is extended by karmada-aggregated-apiserver, thus users can directly +query member cluster resources (e.g., Nodes, Pods) through Karmada’s unified API endpoint. +Users can extend Karmada’s API surface in the same way they extend Kubernetes -- whether for custom resources or +third-party integrations. + +To view all supported APIs, run the `karmadactl api-resources` command against Karmada, this lists all supported API +including Kubernetes API and extended APIs, the output like: +``` +# karmadactl api-resources +NAME SHORTNAMES APIVERSION NAMESPACED KIND +pods po v1 true Pod +deployments deploy apps/v1 true Deployment +clusters cluster.karmada.io/v1alpha1 false Cluster +overridepolicies op policy.karmada.io/v1alpha1 true OverridePolicy +propagationpolicies pp policy.karmada.io/v1alpha1 true PropagationPolicy +... +``` + +## Kubernetes versions support + +Karmada manages Kubernetes clusters using a minimal set of stable APIs and endpoints, ensuring broad compatibility +across Kubernetes versions. Each Karmada release integrates the latest Kubernetes client libraries and tests +compatibility with the latest 10 Kubernetes versions. For example, Karmada v1.14 uses Kubernetes client v1.32 and is +validated against Kubernetes versions from v1.23 to v1.32. + +A resource can be propagated to member clusters only if both Karmada and the target cluster support its API. +- If Karmada does not recognize the API (e.g., unsupported CRDs or deprecated APIs), the resource cannot be created in Karmada. +- If a member cluster lacks the API (e.g., an older cluster missing networking.k8s.io/v1/Ingress), Karmada skips propagation to that cluster. + +## FAQ + +### How to choose the version of Karmada APIServer? + +The Karmada project automatically updates the default kube-apiserver version in its installation tools (e.g., Karmada Operator) +to support the latest Kubernetes APIs. In most cases, users do not need to change it, even in case of upgrading Karmada. + +You may need to upgrade Karmada APIServer in cases such as: +- Adopting New Kubernetes APIs: To leverage features introduced in newer Kubernetes versions. +- Addressing CVEs: To resolve security vulnerabilities present in older versions. + +Note that upgrading should be taken very carefully: + +- Review API Deprecations: Ensure resource types used in your workloads are not deprecated in the target Kubernetes version. +- Incremental Upgrades: Always upgrade one minor version at a time (e.g., kube-apiserver@v1.32 → v1.33). +Avoid skipping versions (e.g., v1.32 → v1.34), as Kubernetes relies on incremental API deprecation and automatic +conversion mechanisms to safely migrate deprecated APIs to newer versions. + +### How to handle member clusters with large version gaps? + +For scenarios where member clusters span incompatible API versions (e.g., some support networking.k8s.io/v1, others only v1beta1), +Currently, Karmada does not automatically convert API versions according to the capacity of member clusters, instead, it is +recommended to upgrade the outdated clusters to a newer Kubernetes version. diff --git a/versioned_docs/version-v1.16/administrator/upgrading/v1.11-v1.12.md b/versioned_docs/version-v1.16/administrator/upgrading/v1.11-v1.12.md index 3d52473d3..570bb839e 100644 --- a/versioned_docs/version-v1.16/administrator/upgrading/v1.11-v1.12.md +++ b/versioned_docs/version-v1.16/administrator/upgrading/v1.11-v1.12.md @@ -1,45 +1,45 @@ ---- -title: v1.11 to v1.12 ---- - -Follow the [Regular Upgrading Process](./README.md). - -## Upgrading Notable Changes - -### API Changes - -- Introduced `SecretRef` to `Karmada` API as part of the configuration for connecting to an external etcd cluster can be used to reference a secret that contains credentials for connecting to an external etcd cluster. -- Introduced `extraVolumes` and `extraVolumemounts` to the `Karmada` API to optionally specify extra volumes and volume mounts for the Karmada API server component. -- Introduced `ApiServerService` field to `Karmada` API as part of the Karmada instance status can be used to reference the API Server service for that instance. This is useful for scenarios where higher level operators need to discover the API Server service of a Karmada instance for tasks like setting up ingress traffic. -- Introduced `CustomCertificate.ApiServerCACert` field to `Karmada` API as part of the `Karmada` spec to specify the reference to a secret that contains a custom CA certificate for the Karmada API Server. -- API change: The ServiceType of the Karmada API server in `Karmada` API now has been restricted to `ClusterIP`, `NodePort` and `LoadBalancer`. -- Introduced a new condition `CompleteAPIEnablements` to `Cluster` API to represent the API collection status. -- Introduced `PreserveResourcesOnDeletion` field to both `PropagationPolicy` and `ClusterPropagationPolicy` API, which provides the ability to roll back migration safely. -- API Change: Introduced `FieldOverrider` to both `OverridePolicy` and `ClusterOverridePolicy`, which provides the ability to override structured data nested in manifest like ConfigMap or Secret. -- Introduced `PurgeMode` to `GracefulEvictionTask` in `ResourceBinding` and `ClusterResourceBinding` API. -- Introduced `StatePreservation` to `PropagationPolicy`, which will be used to preserve status in case of application failover. - -### Deprecation - -- `ExternalEtcd.CAData`, `ExternalEtcd.CertData` and `ExternalEtcd.KeyData` in `Karmada` API are deprecated and will be removed in a future version. Use SecretRef for providing client connection credentials. -- The following flags have been deprecated in release `v1.11.0` and now have been removed: - * `karmada-agent`: - * --bind-address - * --secure-port - * `karmada-controller-manager`: - * --bind-address - * --secure-port - * `karmada-scheduler-estimator`: - * --bind-address - * --secure-port - * `karmada-scheduler`: - * --bind-address - * --secure-port - * `karmada-descheduler`: - * --bind-address - * --secure-port - -### karmada-controller-manager - -- Introduced feature gate `StatefulFailoverInjection` to control whether Karmada collects and injects state information during a failover event for stateful application. +--- +title: v1.11 to v1.12 +--- + +Follow the [Regular Upgrading Process](./README.md). + +## Upgrading Notable Changes + +### API Changes + +- Introduced `SecretRef` to `Karmada` API as part of the configuration for connecting to an external etcd cluster can be used to reference a secret that contains credentials for connecting to an external etcd cluster. +- Introduced `extraVolumes` and `extraVolumemounts` to the `Karmada` API to optionally specify extra volumes and volume mounts for the Karmada API server component. +- Introduced `ApiServerService` field to `Karmada` API as part of the Karmada instance status can be used to reference the API Server service for that instance. This is useful for scenarios where higher level operators need to discover the API Server service of a Karmada instance for tasks like setting up ingress traffic. +- Introduced `CustomCertificate.ApiServerCACert` field to `Karmada` API as part of the `Karmada` spec to specify the reference to a secret that contains a custom CA certificate for the Karmada API Server. +- API change: The ServiceType of the Karmada API server in `Karmada` API now has been restricted to `ClusterIP`, `NodePort` and `LoadBalancer`. +- Introduced a new condition `CompleteAPIEnablements` to `Cluster` API to represent the API collection status. +- Introduced `PreserveResourcesOnDeletion` field to both `PropagationPolicy` and `ClusterPropagationPolicy` API, which provides the ability to roll back migration safely. +- API Change: Introduced `FieldOverrider` to both `OverridePolicy` and `ClusterOverridePolicy`, which provides the ability to override structured data nested in manifest like ConfigMap or Secret. +- Introduced `PurgeMode` to `GracefulEvictionTask` in `ResourceBinding` and `ClusterResourceBinding` API. +- Introduced `StatePreservation` to `PropagationPolicy`, which will be used to preserve status in case of application failover. + +### Deprecation + +- `ExternalEtcd.CAData`, `ExternalEtcd.CertData` and `ExternalEtcd.KeyData` in `Karmada` API are deprecated and will be removed in a future version. Use SecretRef for providing client connection credentials. +- The following flags have been deprecated in release `v1.11.0` and now have been removed: + * `karmada-agent`: + * --bind-address + * --secure-port + * `karmada-controller-manager`: + * --bind-address + * --secure-port + * `karmada-scheduler-estimator`: + * --bind-address + * --secure-port + * `karmada-scheduler`: + * --bind-address + * --secure-port + * `karmada-descheduler`: + * --bind-address + * --secure-port + +### karmada-controller-manager + +- Introduced feature gate `StatefulFailoverInjection` to control whether Karmada collects and injects state information during a failover event for stateful application. - The feature `Failover` now has been disabled by default, which should be explicitly enabled to avoid unexpected incidents. \ No newline at end of file diff --git a/versioned_docs/version-v1.17/administrator/compatibility/compatibility.md b/versioned_docs/version-v1.17/administrator/compatibility/compatibility.md index 4984a9946..14ebbcaf3 100644 --- a/versioned_docs/version-v1.17/administrator/compatibility/compatibility.md +++ b/versioned_docs/version-v1.17/administrator/compatibility/compatibility.md @@ -1,76 +1,76 @@ ---- -title: Kubernetes Compatibility ---- - -This document provides a comprehensive guide to Karmada's compatibility with Kubernetes versions, focusing on two -primary dimensions: -- Karmada control plane APIs support: How many APIs are supported? -- Kubernetes versions support: How many Kubernetes versions are supported? - -This document helps administrators understand how Karmada manages resources across clusters with mixed Kubernetes versions. -It ensures safe propagation by respecting each cluster’s API capabilities and provides guidelines for maintaining -compatibility during upgrades or migrations. - -## Karmada control plane APIs support - -Karmada supports all Kubernetes APIs available in the version of kube-apiserver it uses. For example, if Karmada APIServer -uses kube-apiserver@v1.32, it inherits support for every API (e.g., Deployment, Service, Ingress) and API version -(e.g., apps/v1, networking.k8s.io/v1) available in Kubernetes v1.32. - -Beyond native Kubernetes APIs, Karmada extends its capabilities through Custom Resource Definitions (CRDs) and -Aggregated APIServer, the same extension mechanisms used in Kubernetes itself: -- **CRD Extensions**: Most Karmada-specific APIs (e.g., PropagationPolicy, OverridePolicy) are implemented as CRDs. -Users can also define custom CRDs in Karmada and propagate them to member clusters, following the same workflow as -native Kubernetes APIs. -- **Aggregated APIServer**: Karmada’s Cluster API is extended by karmada-aggregated-apiserver, thus users can directly -query member cluster resources (e.g., Nodes, Pods) through Karmada’s unified API endpoint. -Users can extend Karmada’s API surface in the same way they extend Kubernetes -- whether for custom resources or -third-party integrations. - -To view all supported APIs, run the `karmadactl api-resources` command against Karmada, this lists all supported API -including Kubernetes API and extended APIs, the output like: -``` -# karmadactl api-resources -NAME SHORTNAMES APIVERSION NAMESPACED KIND -pods po v1 true Pod -deployments deploy apps/v1 true Deployment -clusters cluster.karmada.io/v1alpha1 false Cluster -overridepolicies op policy.karmada.io/v1alpha1 true OverridePolicy -propagationpolicies pp policy.karmada.io/v1alpha1 true PropagationPolicy -... -``` - -## Kubernetes versions support - -Karmada manages Kubernetes clusters using a minimal set of stable APIs and endpoints, ensuring broad compatibility -across Kubernetes versions. Each Karmada release integrates the latest Kubernetes client libraries and tests -compatibility with the latest 10 Kubernetes versions. For example, Karmada v1.14 uses Kubernetes client v1.32 and is -validated against Kubernetes versions from v1.23 to v1.32. - -A resource can be propagated to member clusters only if both Karmada and the target cluster support its API. -- If Karmada does not recognize the API (e.g., unsupported CRDs or deprecated APIs), the resource cannot be created in Karmada. -- If a member cluster lacks the API (e.g., an older cluster missing networking.k8s.io/v1/Ingress), Karmada skips propagation to that cluster. - -## FAQ - -### How to choose the version of Karmada APIServer? - -The Karmada project automatically updates the default kube-apiserver version in its installation tools (e.g., Karmada Operator) -to support the latest Kubernetes APIs. In most cases, users do not need to change it, even in case of upgrading Karmada. - -You may need to upgrade Karmada APIServer in cases such as: -- Adopting New Kubernetes APIs: To leverage features introduced in newer Kubernetes versions. -- Addressing CVEs: To resolve security vulnerabilities present in older versions. - -Note that upgrading should be taken very carefully: - -- Review API Deprecations: Ensure resource types used in your workloads are not deprecated in the target Kubernetes version. -- Incremental Upgrades: Always upgrade one minor version at a time (e.g., kube-apiserver@v1.32 → v1.33). -Avoid skipping versions (e.g., v1.32 → v1.34), as Kubernetes relies on incremental API deprecation and automatic -conversion mechanisms to safely migrate deprecated APIs to newer versions. - -### How to handle member clusters with large version gaps? - -For scenarios where member clusters span incompatible API versions (e.g., some support networking.k8s.io/v1, others only v1beta1), -Currently, Karmada does not automatically convert API versions according to the capacity of member clusters, instead, it is -recommended to upgrade the outdated clusters to a newer Kubernetes version. +--- +title: Kubernetes Compatibility +--- + +This document provides a comprehensive guide to Karmada's compatibility with Kubernetes versions, focusing on two +primary dimensions: +- Karmada control plane APIs support: How many APIs are supported? +- Kubernetes versions support: How many Kubernetes versions are supported? + +This document helps administrators understand how Karmada manages resources across clusters with mixed Kubernetes versions. +It ensures safe propagation by respecting each cluster’s API capabilities and provides guidelines for maintaining +compatibility during upgrades or migrations. + +## Karmada control plane APIs support + +Karmada supports all Kubernetes APIs available in the version of kube-apiserver it uses. For example, if Karmada APIServer +uses kube-apiserver@v1.32, it inherits support for every API (e.g., Deployment, Service, Ingress) and API version +(e.g., apps/v1, networking.k8s.io/v1) available in Kubernetes v1.32. + +Beyond native Kubernetes APIs, Karmada extends its capabilities through Custom Resource Definitions (CRDs) and +Aggregated APIServer, the same extension mechanisms used in Kubernetes itself: +- **CRD Extensions**: Most Karmada-specific APIs (e.g., PropagationPolicy, OverridePolicy) are implemented as CRDs. +Users can also define custom CRDs in Karmada and propagate them to member clusters, following the same workflow as +native Kubernetes APIs. +- **Aggregated APIServer**: Karmada’s Cluster API is extended by karmada-aggregated-apiserver, thus users can directly +query member cluster resources (e.g., Nodes, Pods) through Karmada’s unified API endpoint. +Users can extend Karmada’s API surface in the same way they extend Kubernetes -- whether for custom resources or +third-party integrations. + +To view all supported APIs, run the `karmadactl api-resources` command against Karmada, this lists all supported API +including Kubernetes API and extended APIs, the output like: +``` +# karmadactl api-resources +NAME SHORTNAMES APIVERSION NAMESPACED KIND +pods po v1 true Pod +deployments deploy apps/v1 true Deployment +clusters cluster.karmada.io/v1alpha1 false Cluster +overridepolicies op policy.karmada.io/v1alpha1 true OverridePolicy +propagationpolicies pp policy.karmada.io/v1alpha1 true PropagationPolicy +... +``` + +## Kubernetes versions support + +Karmada manages Kubernetes clusters using a minimal set of stable APIs and endpoints, ensuring broad compatibility +across Kubernetes versions. Each Karmada release integrates the latest Kubernetes client libraries and tests +compatibility with the latest 10 Kubernetes versions. For example, Karmada v1.14 uses Kubernetes client v1.32 and is +validated against Kubernetes versions from v1.23 to v1.32. + +A resource can be propagated to member clusters only if both Karmada and the target cluster support its API. +- If Karmada does not recognize the API (e.g., unsupported CRDs or deprecated APIs), the resource cannot be created in Karmada. +- If a member cluster lacks the API (e.g., an older cluster missing networking.k8s.io/v1/Ingress), Karmada skips propagation to that cluster. + +## FAQ + +### How to choose the version of Karmada APIServer? + +The Karmada project automatically updates the default kube-apiserver version in its installation tools (e.g., Karmada Operator) +to support the latest Kubernetes APIs. In most cases, users do not need to change it, even in case of upgrading Karmada. + +You may need to upgrade Karmada APIServer in cases such as: +- Adopting New Kubernetes APIs: To leverage features introduced in newer Kubernetes versions. +- Addressing CVEs: To resolve security vulnerabilities present in older versions. + +Note that upgrading should be taken very carefully: + +- Review API Deprecations: Ensure resource types used in your workloads are not deprecated in the target Kubernetes version. +- Incremental Upgrades: Always upgrade one minor version at a time (e.g., kube-apiserver@v1.32 → v1.33). +Avoid skipping versions (e.g., v1.32 → v1.34), as Kubernetes relies on incremental API deprecation and automatic +conversion mechanisms to safely migrate deprecated APIs to newer versions. + +### How to handle member clusters with large version gaps? + +For scenarios where member clusters span incompatible API versions (e.g., some support networking.k8s.io/v1, others only v1beta1), +Currently, Karmada does not automatically convert API versions according to the capacity of member clusters, instead, it is +recommended to upgrade the outdated clusters to a newer Kubernetes version. diff --git a/versioned_docs/version-v1.17/administrator/upgrading/v1.11-v1.12.md b/versioned_docs/version-v1.17/administrator/upgrading/v1.11-v1.12.md index 3d52473d3..570bb839e 100644 --- a/versioned_docs/version-v1.17/administrator/upgrading/v1.11-v1.12.md +++ b/versioned_docs/version-v1.17/administrator/upgrading/v1.11-v1.12.md @@ -1,45 +1,45 @@ ---- -title: v1.11 to v1.12 ---- - -Follow the [Regular Upgrading Process](./README.md). - -## Upgrading Notable Changes - -### API Changes - -- Introduced `SecretRef` to `Karmada` API as part of the configuration for connecting to an external etcd cluster can be used to reference a secret that contains credentials for connecting to an external etcd cluster. -- Introduced `extraVolumes` and `extraVolumemounts` to the `Karmada` API to optionally specify extra volumes and volume mounts for the Karmada API server component. -- Introduced `ApiServerService` field to `Karmada` API as part of the Karmada instance status can be used to reference the API Server service for that instance. This is useful for scenarios where higher level operators need to discover the API Server service of a Karmada instance for tasks like setting up ingress traffic. -- Introduced `CustomCertificate.ApiServerCACert` field to `Karmada` API as part of the `Karmada` spec to specify the reference to a secret that contains a custom CA certificate for the Karmada API Server. -- API change: The ServiceType of the Karmada API server in `Karmada` API now has been restricted to `ClusterIP`, `NodePort` and `LoadBalancer`. -- Introduced a new condition `CompleteAPIEnablements` to `Cluster` API to represent the API collection status. -- Introduced `PreserveResourcesOnDeletion` field to both `PropagationPolicy` and `ClusterPropagationPolicy` API, which provides the ability to roll back migration safely. -- API Change: Introduced `FieldOverrider` to both `OverridePolicy` and `ClusterOverridePolicy`, which provides the ability to override structured data nested in manifest like ConfigMap or Secret. -- Introduced `PurgeMode` to `GracefulEvictionTask` in `ResourceBinding` and `ClusterResourceBinding` API. -- Introduced `StatePreservation` to `PropagationPolicy`, which will be used to preserve status in case of application failover. - -### Deprecation - -- `ExternalEtcd.CAData`, `ExternalEtcd.CertData` and `ExternalEtcd.KeyData` in `Karmada` API are deprecated and will be removed in a future version. Use SecretRef for providing client connection credentials. -- The following flags have been deprecated in release `v1.11.0` and now have been removed: - * `karmada-agent`: - * --bind-address - * --secure-port - * `karmada-controller-manager`: - * --bind-address - * --secure-port - * `karmada-scheduler-estimator`: - * --bind-address - * --secure-port - * `karmada-scheduler`: - * --bind-address - * --secure-port - * `karmada-descheduler`: - * --bind-address - * --secure-port - -### karmada-controller-manager - -- Introduced feature gate `StatefulFailoverInjection` to control whether Karmada collects and injects state information during a failover event for stateful application. +--- +title: v1.11 to v1.12 +--- + +Follow the [Regular Upgrading Process](./README.md). + +## Upgrading Notable Changes + +### API Changes + +- Introduced `SecretRef` to `Karmada` API as part of the configuration for connecting to an external etcd cluster can be used to reference a secret that contains credentials for connecting to an external etcd cluster. +- Introduced `extraVolumes` and `extraVolumemounts` to the `Karmada` API to optionally specify extra volumes and volume mounts for the Karmada API server component. +- Introduced `ApiServerService` field to `Karmada` API as part of the Karmada instance status can be used to reference the API Server service for that instance. This is useful for scenarios where higher level operators need to discover the API Server service of a Karmada instance for tasks like setting up ingress traffic. +- Introduced `CustomCertificate.ApiServerCACert` field to `Karmada` API as part of the `Karmada` spec to specify the reference to a secret that contains a custom CA certificate for the Karmada API Server. +- API change: The ServiceType of the Karmada API server in `Karmada` API now has been restricted to `ClusterIP`, `NodePort` and `LoadBalancer`. +- Introduced a new condition `CompleteAPIEnablements` to `Cluster` API to represent the API collection status. +- Introduced `PreserveResourcesOnDeletion` field to both `PropagationPolicy` and `ClusterPropagationPolicy` API, which provides the ability to roll back migration safely. +- API Change: Introduced `FieldOverrider` to both `OverridePolicy` and `ClusterOverridePolicy`, which provides the ability to override structured data nested in manifest like ConfigMap or Secret. +- Introduced `PurgeMode` to `GracefulEvictionTask` in `ResourceBinding` and `ClusterResourceBinding` API. +- Introduced `StatePreservation` to `PropagationPolicy`, which will be used to preserve status in case of application failover. + +### Deprecation + +- `ExternalEtcd.CAData`, `ExternalEtcd.CertData` and `ExternalEtcd.KeyData` in `Karmada` API are deprecated and will be removed in a future version. Use SecretRef for providing client connection credentials. +- The following flags have been deprecated in release `v1.11.0` and now have been removed: + * `karmada-agent`: + * --bind-address + * --secure-port + * `karmada-controller-manager`: + * --bind-address + * --secure-port + * `karmada-scheduler-estimator`: + * --bind-address + * --secure-port + * `karmada-scheduler`: + * --bind-address + * --secure-port + * `karmada-descheduler`: + * --bind-address + * --secure-port + +### karmada-controller-manager + +- Introduced feature gate `StatefulFailoverInjection` to control whether Karmada collects and injects state information during a failover event for stateful application. - The feature `Failover` now has been disabled by default, which should be explicitly enabled to avoid unexpected incidents. \ No newline at end of file diff --git a/versioned_docs/version-v1.18/administrator/compatibility/compatibility.md b/versioned_docs/version-v1.18/administrator/compatibility/compatibility.md index 4984a9946..14ebbcaf3 100644 --- a/versioned_docs/version-v1.18/administrator/compatibility/compatibility.md +++ b/versioned_docs/version-v1.18/administrator/compatibility/compatibility.md @@ -1,76 +1,76 @@ ---- -title: Kubernetes Compatibility ---- - -This document provides a comprehensive guide to Karmada's compatibility with Kubernetes versions, focusing on two -primary dimensions: -- Karmada control plane APIs support: How many APIs are supported? -- Kubernetes versions support: How many Kubernetes versions are supported? - -This document helps administrators understand how Karmada manages resources across clusters with mixed Kubernetes versions. -It ensures safe propagation by respecting each cluster’s API capabilities and provides guidelines for maintaining -compatibility during upgrades or migrations. - -## Karmada control plane APIs support - -Karmada supports all Kubernetes APIs available in the version of kube-apiserver it uses. For example, if Karmada APIServer -uses kube-apiserver@v1.32, it inherits support for every API (e.g., Deployment, Service, Ingress) and API version -(e.g., apps/v1, networking.k8s.io/v1) available in Kubernetes v1.32. - -Beyond native Kubernetes APIs, Karmada extends its capabilities through Custom Resource Definitions (CRDs) and -Aggregated APIServer, the same extension mechanisms used in Kubernetes itself: -- **CRD Extensions**: Most Karmada-specific APIs (e.g., PropagationPolicy, OverridePolicy) are implemented as CRDs. -Users can also define custom CRDs in Karmada and propagate them to member clusters, following the same workflow as -native Kubernetes APIs. -- **Aggregated APIServer**: Karmada’s Cluster API is extended by karmada-aggregated-apiserver, thus users can directly -query member cluster resources (e.g., Nodes, Pods) through Karmada’s unified API endpoint. -Users can extend Karmada’s API surface in the same way they extend Kubernetes -- whether for custom resources or -third-party integrations. - -To view all supported APIs, run the `karmadactl api-resources` command against Karmada, this lists all supported API -including Kubernetes API and extended APIs, the output like: -``` -# karmadactl api-resources -NAME SHORTNAMES APIVERSION NAMESPACED KIND -pods po v1 true Pod -deployments deploy apps/v1 true Deployment -clusters cluster.karmada.io/v1alpha1 false Cluster -overridepolicies op policy.karmada.io/v1alpha1 true OverridePolicy -propagationpolicies pp policy.karmada.io/v1alpha1 true PropagationPolicy -... -``` - -## Kubernetes versions support - -Karmada manages Kubernetes clusters using a minimal set of stable APIs and endpoints, ensuring broad compatibility -across Kubernetes versions. Each Karmada release integrates the latest Kubernetes client libraries and tests -compatibility with the latest 10 Kubernetes versions. For example, Karmada v1.14 uses Kubernetes client v1.32 and is -validated against Kubernetes versions from v1.23 to v1.32. - -A resource can be propagated to member clusters only if both Karmada and the target cluster support its API. -- If Karmada does not recognize the API (e.g., unsupported CRDs or deprecated APIs), the resource cannot be created in Karmada. -- If a member cluster lacks the API (e.g., an older cluster missing networking.k8s.io/v1/Ingress), Karmada skips propagation to that cluster. - -## FAQ - -### How to choose the version of Karmada APIServer? - -The Karmada project automatically updates the default kube-apiserver version in its installation tools (e.g., Karmada Operator) -to support the latest Kubernetes APIs. In most cases, users do not need to change it, even in case of upgrading Karmada. - -You may need to upgrade Karmada APIServer in cases such as: -- Adopting New Kubernetes APIs: To leverage features introduced in newer Kubernetes versions. -- Addressing CVEs: To resolve security vulnerabilities present in older versions. - -Note that upgrading should be taken very carefully: - -- Review API Deprecations: Ensure resource types used in your workloads are not deprecated in the target Kubernetes version. -- Incremental Upgrades: Always upgrade one minor version at a time (e.g., kube-apiserver@v1.32 → v1.33). -Avoid skipping versions (e.g., v1.32 → v1.34), as Kubernetes relies on incremental API deprecation and automatic -conversion mechanisms to safely migrate deprecated APIs to newer versions. - -### How to handle member clusters with large version gaps? - -For scenarios where member clusters span incompatible API versions (e.g., some support networking.k8s.io/v1, others only v1beta1), -Currently, Karmada does not automatically convert API versions according to the capacity of member clusters, instead, it is -recommended to upgrade the outdated clusters to a newer Kubernetes version. +--- +title: Kubernetes Compatibility +--- + +This document provides a comprehensive guide to Karmada's compatibility with Kubernetes versions, focusing on two +primary dimensions: +- Karmada control plane APIs support: How many APIs are supported? +- Kubernetes versions support: How many Kubernetes versions are supported? + +This document helps administrators understand how Karmada manages resources across clusters with mixed Kubernetes versions. +It ensures safe propagation by respecting each cluster’s API capabilities and provides guidelines for maintaining +compatibility during upgrades or migrations. + +## Karmada control plane APIs support + +Karmada supports all Kubernetes APIs available in the version of kube-apiserver it uses. For example, if Karmada APIServer +uses kube-apiserver@v1.32, it inherits support for every API (e.g., Deployment, Service, Ingress) and API version +(e.g., apps/v1, networking.k8s.io/v1) available in Kubernetes v1.32. + +Beyond native Kubernetes APIs, Karmada extends its capabilities through Custom Resource Definitions (CRDs) and +Aggregated APIServer, the same extension mechanisms used in Kubernetes itself: +- **CRD Extensions**: Most Karmada-specific APIs (e.g., PropagationPolicy, OverridePolicy) are implemented as CRDs. +Users can also define custom CRDs in Karmada and propagate them to member clusters, following the same workflow as +native Kubernetes APIs. +- **Aggregated APIServer**: Karmada’s Cluster API is extended by karmada-aggregated-apiserver, thus users can directly +query member cluster resources (e.g., Nodes, Pods) through Karmada’s unified API endpoint. +Users can extend Karmada’s API surface in the same way they extend Kubernetes -- whether for custom resources or +third-party integrations. + +To view all supported APIs, run the `karmadactl api-resources` command against Karmada, this lists all supported API +including Kubernetes API and extended APIs, the output like: +``` +# karmadactl api-resources +NAME SHORTNAMES APIVERSION NAMESPACED KIND +pods po v1 true Pod +deployments deploy apps/v1 true Deployment +clusters cluster.karmada.io/v1alpha1 false Cluster +overridepolicies op policy.karmada.io/v1alpha1 true OverridePolicy +propagationpolicies pp policy.karmada.io/v1alpha1 true PropagationPolicy +... +``` + +## Kubernetes versions support + +Karmada manages Kubernetes clusters using a minimal set of stable APIs and endpoints, ensuring broad compatibility +across Kubernetes versions. Each Karmada release integrates the latest Kubernetes client libraries and tests +compatibility with the latest 10 Kubernetes versions. For example, Karmada v1.14 uses Kubernetes client v1.32 and is +validated against Kubernetes versions from v1.23 to v1.32. + +A resource can be propagated to member clusters only if both Karmada and the target cluster support its API. +- If Karmada does not recognize the API (e.g., unsupported CRDs or deprecated APIs), the resource cannot be created in Karmada. +- If a member cluster lacks the API (e.g., an older cluster missing networking.k8s.io/v1/Ingress), Karmada skips propagation to that cluster. + +## FAQ + +### How to choose the version of Karmada APIServer? + +The Karmada project automatically updates the default kube-apiserver version in its installation tools (e.g., Karmada Operator) +to support the latest Kubernetes APIs. In most cases, users do not need to change it, even in case of upgrading Karmada. + +You may need to upgrade Karmada APIServer in cases such as: +- Adopting New Kubernetes APIs: To leverage features introduced in newer Kubernetes versions. +- Addressing CVEs: To resolve security vulnerabilities present in older versions. + +Note that upgrading should be taken very carefully: + +- Review API Deprecations: Ensure resource types used in your workloads are not deprecated in the target Kubernetes version. +- Incremental Upgrades: Always upgrade one minor version at a time (e.g., kube-apiserver@v1.32 → v1.33). +Avoid skipping versions (e.g., v1.32 → v1.34), as Kubernetes relies on incremental API deprecation and automatic +conversion mechanisms to safely migrate deprecated APIs to newer versions. + +### How to handle member clusters with large version gaps? + +For scenarios where member clusters span incompatible API versions (e.g., some support networking.k8s.io/v1, others only v1beta1), +Currently, Karmada does not automatically convert API versions according to the capacity of member clusters, instead, it is +recommended to upgrade the outdated clusters to a newer Kubernetes version. diff --git a/versioned_docs/version-v1.18/administrator/upgrading/v1.11-v1.12.md b/versioned_docs/version-v1.18/administrator/upgrading/v1.11-v1.12.md index 3d52473d3..570bb839e 100644 --- a/versioned_docs/version-v1.18/administrator/upgrading/v1.11-v1.12.md +++ b/versioned_docs/version-v1.18/administrator/upgrading/v1.11-v1.12.md @@ -1,45 +1,45 @@ ---- -title: v1.11 to v1.12 ---- - -Follow the [Regular Upgrading Process](./README.md). - -## Upgrading Notable Changes - -### API Changes - -- Introduced `SecretRef` to `Karmada` API as part of the configuration for connecting to an external etcd cluster can be used to reference a secret that contains credentials for connecting to an external etcd cluster. -- Introduced `extraVolumes` and `extraVolumemounts` to the `Karmada` API to optionally specify extra volumes and volume mounts for the Karmada API server component. -- Introduced `ApiServerService` field to `Karmada` API as part of the Karmada instance status can be used to reference the API Server service for that instance. This is useful for scenarios where higher level operators need to discover the API Server service of a Karmada instance for tasks like setting up ingress traffic. -- Introduced `CustomCertificate.ApiServerCACert` field to `Karmada` API as part of the `Karmada` spec to specify the reference to a secret that contains a custom CA certificate for the Karmada API Server. -- API change: The ServiceType of the Karmada API server in `Karmada` API now has been restricted to `ClusterIP`, `NodePort` and `LoadBalancer`. -- Introduced a new condition `CompleteAPIEnablements` to `Cluster` API to represent the API collection status. -- Introduced `PreserveResourcesOnDeletion` field to both `PropagationPolicy` and `ClusterPropagationPolicy` API, which provides the ability to roll back migration safely. -- API Change: Introduced `FieldOverrider` to both `OverridePolicy` and `ClusterOverridePolicy`, which provides the ability to override structured data nested in manifest like ConfigMap or Secret. -- Introduced `PurgeMode` to `GracefulEvictionTask` in `ResourceBinding` and `ClusterResourceBinding` API. -- Introduced `StatePreservation` to `PropagationPolicy`, which will be used to preserve status in case of application failover. - -### Deprecation - -- `ExternalEtcd.CAData`, `ExternalEtcd.CertData` and `ExternalEtcd.KeyData` in `Karmada` API are deprecated and will be removed in a future version. Use SecretRef for providing client connection credentials. -- The following flags have been deprecated in release `v1.11.0` and now have been removed: - * `karmada-agent`: - * --bind-address - * --secure-port - * `karmada-controller-manager`: - * --bind-address - * --secure-port - * `karmada-scheduler-estimator`: - * --bind-address - * --secure-port - * `karmada-scheduler`: - * --bind-address - * --secure-port - * `karmada-descheduler`: - * --bind-address - * --secure-port - -### karmada-controller-manager - -- Introduced feature gate `StatefulFailoverInjection` to control whether Karmada collects and injects state information during a failover event for stateful application. +--- +title: v1.11 to v1.12 +--- + +Follow the [Regular Upgrading Process](./README.md). + +## Upgrading Notable Changes + +### API Changes + +- Introduced `SecretRef` to `Karmada` API as part of the configuration for connecting to an external etcd cluster can be used to reference a secret that contains credentials for connecting to an external etcd cluster. +- Introduced `extraVolumes` and `extraVolumemounts` to the `Karmada` API to optionally specify extra volumes and volume mounts for the Karmada API server component. +- Introduced `ApiServerService` field to `Karmada` API as part of the Karmada instance status can be used to reference the API Server service for that instance. This is useful for scenarios where higher level operators need to discover the API Server service of a Karmada instance for tasks like setting up ingress traffic. +- Introduced `CustomCertificate.ApiServerCACert` field to `Karmada` API as part of the `Karmada` spec to specify the reference to a secret that contains a custom CA certificate for the Karmada API Server. +- API change: The ServiceType of the Karmada API server in `Karmada` API now has been restricted to `ClusterIP`, `NodePort` and `LoadBalancer`. +- Introduced a new condition `CompleteAPIEnablements` to `Cluster` API to represent the API collection status. +- Introduced `PreserveResourcesOnDeletion` field to both `PropagationPolicy` and `ClusterPropagationPolicy` API, which provides the ability to roll back migration safely. +- API Change: Introduced `FieldOverrider` to both `OverridePolicy` and `ClusterOverridePolicy`, which provides the ability to override structured data nested in manifest like ConfigMap or Secret. +- Introduced `PurgeMode` to `GracefulEvictionTask` in `ResourceBinding` and `ClusterResourceBinding` API. +- Introduced `StatePreservation` to `PropagationPolicy`, which will be used to preserve status in case of application failover. + +### Deprecation + +- `ExternalEtcd.CAData`, `ExternalEtcd.CertData` and `ExternalEtcd.KeyData` in `Karmada` API are deprecated and will be removed in a future version. Use SecretRef for providing client connection credentials. +- The following flags have been deprecated in release `v1.11.0` and now have been removed: + * `karmada-agent`: + * --bind-address + * --secure-port + * `karmada-controller-manager`: + * --bind-address + * --secure-port + * `karmada-scheduler-estimator`: + * --bind-address + * --secure-port + * `karmada-scheduler`: + * --bind-address + * --secure-port + * `karmada-descheduler`: + * --bind-address + * --secure-port + +### karmada-controller-manager + +- Introduced feature gate `StatefulFailoverInjection` to control whether Karmada collects and injects state information during a failover event for stateful application. - The feature `Failover` now has been disabled by default, which should be explicitly enabled to avoid unexpected incidents. \ No newline at end of file