diff --git a/_data/concepts.yml b/_data/concepts.yml index 32af951748c04..9750451b23301 100644 --- a/_data/concepts.yml +++ b/_data/concepts.yml @@ -33,9 +33,10 @@ toc: section: - docs/concepts/workloads/pods/pod-lifecycle.md -- title: Clusters +- title: Cluster Administration section: - docs/concepts/clusters/logging.md + - docs/concepts/cluster-administration/federation.md - title: Configuration section: diff --git a/_data/tutorials.yml b/_data/tutorials.yml index 695d2b8805dd6..33353cb9ff2c5 100644 --- a/_data/tutorials.yml +++ b/_data/tutorials.yml @@ -49,3 +49,6 @@ toc: - title: Services section: - docs/tutorials/services/source-ip.md +- title: Federated Cluster Administration + section: + - docs/tutorials/federation/set-up-cluster-federation-kubefed.md diff --git a/docs/admin/federation/kubefed.md b/docs/admin/federation/kubefed.md index 4af8db60b522b..7b1b8f499a999 100644 --- a/docs/admin/federation/kubefed.md +++ b/docs/admin/federation/kubefed.md @@ -4,205 +4,6 @@ assignees: title: Setting up Cluster Federation with Kubefed --- -* TOC -{:toc} +{% include user-guide-content-moved.md %} -Kubernetes version 1.5 includes a new command line tool called -`kubefed` to help you administrate your federated clusters. -`kubefed` helps you to deploy a new Kubernetes cluster federation -control plane, and to add clusters to or remove clusters from an -existing federation control plane. - -This guide explains how to administer a Kubernetes Cluster Federation -using `kubefed`. - -> Note: `kubefed` is an alpha feature in Kubernetes 1.5. - -## Prerequisites - -This guide assumes that you have a running Kubernetes cluster. Please -see one of the [getting started](/docs/getting-started-guides/) guides -for installation instructions for your platform. - - -## Getting `kubefed` - -Download the client tarball corresponding to Kubernetes version 1.5 -or later -[from the release page](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md), -extract the binaries in the tarball to one of the directories -in your `$PATH` and set the executable permission on those binaries. - -Note: The URL in the curl command below downloads the binaries for -Linux amd64. If you are on a different platform, please use the URL -for the binaries appropriate for your platform. You can find the list -of available binaries on the [release page](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md#client-binaries-1). - - -```shell -curl -O https://storage.googleapis.com/kubernetes-release/release/v1.5.2/kubernetes-client-linux-amd64.tar.gz -tar -xzvf kubernetes-client-linux-amd64.tar.gz -sudo cp kubernetes/client/bin/kubefed /usr/local/bin -sudo chmod +x /usr/local/bin/kubefed -sudo cp kubernetes/client/bin/kubectl /usr/local/bin -sudo chmod +x /usr/local/bin/kubectl -``` - - -## Choosing a host cluster. - -You'll need to choose one of your Kubernetes clusters to be the -*host cluster*. The host cluster hosts the components that make up -your federation control plane. Ensure that you have a `kubeconfig` -entry in your local `kubeconfig` that corresponds to the host cluster. -You can verify that you have the required `kubeconfig` entry by -running: - -```shell -kubectl config get-contexts -``` - -The output should contain an entry corresponding to your host cluster, -similar to the following: - -``` -CURRENT NAME CLUSTER AUTHINFO NAMESPACE - gke_myproject_asia-east1-b_gce-asia-east1 gke_myproject_asia-east1-b_gce-asia-east1 gke_myproject_asia-east1-b_gce-asia-east1 -``` - - -You'll need to provide the `kubeconfig` context (called name in the -entry above) for your host cluster when you deploy your federation -control plane. - - -## Deploying a federation control plane. - -To deploy a federation control plane on your host cluster, run -`kubefed init` command. When you use `kubefed init`, you must provide -the following: - -* Federation name -* `--host-cluster-context`, the `kubeconfig` context for the host cluster -* `--dns-zone-name`, a domain name suffix for your federated services - -The following example command deploys a federation control plane with -the name `fellowship`, a host cluster context `rivendell`, and the -domain suffix `example.com`: - -```shell -kubefed init fellowship --host-cluster-context=rivendell --dns-zone-name="example.com" -``` - -The domain suffix specified in `--dns-zone-name` must be an existing -domain that you control, and that is programmable by your DNS provider. - -`kubefed init` sets up the federation control plane in the host -cluster and also adds an entry for the federation API server in your -local kubeconfig. Note that in the alpha release in Kubernetes 1.5, -`kubefed init` does not automatically set the current context to the -newly deployed federation. You can set the current context manually by -running: - -```shell -kubectl config use-context fellowship -``` - -where `fellowship` is the name of your federation. - - -## Adding a cluster to a federation - -Once you've deployed a federation control plane, you'll need to make -that control plane aware of the clusters it should manage. You can add -a cluster to your federation by using the `kubefed join` command. - -To use `kubefed join`, you'll need to provide the name of the cluster -you want to add to the federation, and the `--host-cluster-context` -for the federation control plane's host cluster. - -The following example command adds the cluster `gondor` to the -federation with host cluster `rivendell`: - -``` -kubefed join gondor --host-cluster-context=rivendell -``` - -> Note: Kubernetes requires that you manually join clusters to a -federation because the federation control plane manages only those -clusters that it is responsible for managing. Adding a cluster tells -the federation control plane that it is responsible for managing that -cluster. - -### Naming rules and customization - -The cluster name you supply to `kubefed join` must be a valid RFC 1035 -label. - -Furthermore, federation control plane requires credentials of the -joined clusters to operate on them. These credentials are obtained -from the local kubeconfig. `kubefed join` uses the cluster name -specified as the argument to look for the cluster's context in the -local kubeconfig. If it fails to find a matching context, it exits -with an error. - -This might cause issues in cases where context names for each cluster -in the federation don't follow -[RFC 1035](https://www.ietf.org/rfc/rfc1035.txt) label naming rules. -In such cases, you can specify a cluster name that conforms to the -[RFC 1035](https://www.ietf.org/rfc/rfc1035.txt) label naming rules -and specify the cluster context using the `--cluster-context` flag. -For example, if context of the cluster your are joining is -`gondor_needs-no_king`, then you can join the cluster by running: - -```shell -kubefed join gondor --host-cluster-context=rivendell --cluster-context=gondor_needs-no_king -``` - -#### Secret name - -Cluster credentials required by the federation control plane as -described above are stored as a secret in the host cluster. The name -of the secret is also derived from the cluster name. - -However, the name of a secret object in Kubernetes should conform -to the DNS subdomain name specification described in -[RFC 1123](https://tools.ietf.org/html/rfc1123). If this isn't the -case, you can pass the secret name to `kubefed join` using the -`--secret-name` flag. For example, if the cluster name is `noldor` and -the secret name is `11kingdom`, you can join the cluster by -running: - -```shell -kubefed join noldor --host-cluster-context=rivendell --secret-name=11kingdom -``` - -Note: If your cluster name does not conform to the DNS subdomain name -specification, all you need to do is supply the secret name via the -`--secret-name` flag. `kubefed join` automatically creates the secret -for you. - - -## Removing a cluster from a federation - -To remove a cluster from a federation, run the `kubefed unjoin` -command with the cluster name and the federation's -`--host-cluster-context`: - -``` -kubefed unjoin gondor --host-cluster-context=rivendell -``` - - -## Turning down the federation control plane: - -Proper cleanup of federation control plane is not fully implemented in -this alpha release of `kubefed`. However, for the time being, deleting -the federation system namespace should remove all the resources except -the persistent storage volume dynamically provisioned for the -federation control plane's etcd. You can delete the federation -namespace by running the following command: - -``` -$ kubectl delete ns federation-system -``` +[Setting up Cluster Federation with kubefed](/docs/tutorials/federation/set-up-cluster-federation-kubefed/) diff --git a/docs/concepts/cluster-administration/federation.md b/docs/concepts/cluster-administration/federation.md new file mode 100644 index 0000000000000..8d151df3e9657 --- /dev/null +++ b/docs/concepts/cluster-administration/federation.md @@ -0,0 +1,137 @@ +--- +title: Federation +--- + +This guide explains why and how to manage multiple Kubernetes clusters using +federation. + + +* TOC +{:toc} + + +## Why federation + +Federation makes it easy to manage multiple clusters. It does so by providing 2 +major building blocks: + + * Sync resources across clusters: Federation provides the ability to keep + resources in multiple clusters in sync. This can be used, for example, to + ensure that the same deployment exists in multiple clusters. + * Cross cluster discovery: It provides the ability to auto-configure DNS + servers and load balancers with backends from all clusters. This can be used, + for example, to ensure that a global VIP or DNS record can be used to access + backends from multiple clusters. + +Some other use cases that federation enables are: + +* High Availability: By spreading load across clusters and auto configuring DNS + servers and load balancers, federation minimises the impact of cluster + failure. +* Avoiding provider lock-in: By making it easier to migrate applications across + clusters, federation prevents cluster provider lock-in. + + +Federation is not helpful unless you have multiple clusters. Some of the reasons +why you might want multiple clusters are: + +* Low latency: Having clusters in multiple regions minimises latency by serving + users from the cluster that is closest to them. +* Fault isolation: It might be better to have multiple small clusters rather + than a single large cluster for fault isolation (for example: multiple + clusters in different availability zones of a cloud provider). + [Multi cluster guide](/docs/admin/multi-cluster) has more details on this. +* Scalability: There are scalability limits to a single kubernetes cluster (this + should not be the case for most users. For more details: + [Kubernetes Scaling and Performance Goals](https://github.com/kubernetes/community/blob/master/sig-scalability/goals.md)). +* Hybrid cloud: You can have multiple clusters on different cloud providers or + on-premises data centers. + + +### Caveats + +While there are a lot of attractive use cases for federation, there are also +some caveats. + +* Increased network bandwidth and cost: The federation control plane watches all + clusters to ensure that the current state is as expected. This can lead to + significant network cost if the clusters are running in different regions on + a cloud provider or on different cloud providers. +* Reduced cross cluster isolation: A bug in the federation control plane can + impact all clusters. This is mitigated by keeping the logic in federation + control plane to a minimum. It mostly delegates to the control plane in + kubernetes clusters whenever it can. The design and implementation also errs + on the side of safety and avoiding multicluster outage. +* Maturity: The federation project is relatively new and is not very mature. + Not all resources are available and many are still alpha. [Issue + 38893](https://github.com/kubernetes/kubernetes/issues/38893) ennumerates + known issues with the system that the team is busy solving. + +## Setup + +To be able to federate multiple clusters, we first need to setup a federation +control plane. +Follow the [setup guide](/docs/admin/federation/) to setup the +federation control plane. + +## Hybrid cloud capabilities + +Federations of Kubernetes Clusters can include clusters running in +different cloud providers (e.g. Google Cloud, AWS), and on-premises +(e.g. on OpenStack). Simply create all of the clusters that you +require, in the appropriate cloud providers and/or locations, and +register each cluster's API endpoint and credentials with your +Federation API Server (See the +[federation admin guide](/docs/admin/federation/) for details). + +Thereafter, your API resources can span different clusters +and cloud providers. + +## API resources + +Once we have the control plane setup, we can start creating federation API +resources. +The following guides explain some of the resources in detail: + +* [ConfigMap](https://kubernetes.io/docs/user-guide/federation/configmap/) +* [DaemonSets](https://kubernetes.io/docs/user-guide/federation/daemonsets/) +* [Deployment](https://kubernetes.io/docs/user-guide/federation/deployment/) +* [Events](https://kubernetes.io/docs/user-guide/federation/events/) +* [Ingress](https://kubernetes.io/docs/user-guide/federation/federated-ingress/) +* [Namespaces](https://kubernetes.io/docs/user-guide/federation/namespaces/) +* [ReplicaSets](https://kubernetes.io/docs/user-guide/federation/replicasets/) +* [Secrets](https://kubernetes.io/docs/user-guide/federation/secrets/) +* [Services](https://kubernetes.io/docs/user-guide/federation/federated-services/) + +[API reference docs](/docs/federation/api-reference/) lists all the +resources supported by federation apiserver. + +## Cascading deletion + +Kubernetes version 1.5 includes support for cascading deletion of federated +resources. With cascading deletion, when you delete a resource from the +federation control plane, the corresponding resources in all underlying clusters +are also deleted. + +To enable cascading deletion, set the option +`DeleteOptions.orphanDependents=false` when you delete a resource from the +federation control plane. + +The following Federated resources are affected by cascading deletion: + +* [Ingress](https://kubernetes.io/docs/user-guide/federation/federated-ingress/) +* [Namespaces](https://kubernetes.io/docs/user-guide/federation/namespaces/) +* [ReplicaSets](https://kubernetes.io/docs/user-guide/federation/replicasets/) +* [Secrets](https://kubernetes.io/docs/user-guide/federation/secrets/) +* [Deployment](https://kubernetes.io/docs/user-guide/federation/deployment/) +* [DaemonSets](https://kubernetes.io/docs/user-guide/federation/daemonsets/) + +Note: By default, deleting a resource from federation control plane does not +delete the corresponding resources from underlying clusters. + + +## For more information + +* [Federation + proposal](https://github.com/kubernetes/community/blob/{{page.githubbranch}}/contributors/design-proposals/federation.md) +* [Kubecon2016 talk on federation](https://www.youtube.com/watch?v=pq9lbkmxpS8) diff --git a/docs/tutorials/federation/set-up-cluster-federation-kubefed.md b/docs/tutorials/federation/set-up-cluster-federation-kubefed.md new file mode 100644 index 0000000000000..4af8db60b522b --- /dev/null +++ b/docs/tutorials/federation/set-up-cluster-federation-kubefed.md @@ -0,0 +1,208 @@ +--- +assignees: +- madhusudancs +title: Setting up Cluster Federation with Kubefed +--- + +* TOC +{:toc} + +Kubernetes version 1.5 includes a new command line tool called +`kubefed` to help you administrate your federated clusters. +`kubefed` helps you to deploy a new Kubernetes cluster federation +control plane, and to add clusters to or remove clusters from an +existing federation control plane. + +This guide explains how to administer a Kubernetes Cluster Federation +using `kubefed`. + +> Note: `kubefed` is an alpha feature in Kubernetes 1.5. + +## Prerequisites + +This guide assumes that you have a running Kubernetes cluster. Please +see one of the [getting started](/docs/getting-started-guides/) guides +for installation instructions for your platform. + + +## Getting `kubefed` + +Download the client tarball corresponding to Kubernetes version 1.5 +or later +[from the release page](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md), +extract the binaries in the tarball to one of the directories +in your `$PATH` and set the executable permission on those binaries. + +Note: The URL in the curl command below downloads the binaries for +Linux amd64. If you are on a different platform, please use the URL +for the binaries appropriate for your platform. You can find the list +of available binaries on the [release page](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md#client-binaries-1). + + +```shell +curl -O https://storage.googleapis.com/kubernetes-release/release/v1.5.2/kubernetes-client-linux-amd64.tar.gz +tar -xzvf kubernetes-client-linux-amd64.tar.gz +sudo cp kubernetes/client/bin/kubefed /usr/local/bin +sudo chmod +x /usr/local/bin/kubefed +sudo cp kubernetes/client/bin/kubectl /usr/local/bin +sudo chmod +x /usr/local/bin/kubectl +``` + + +## Choosing a host cluster. + +You'll need to choose one of your Kubernetes clusters to be the +*host cluster*. The host cluster hosts the components that make up +your federation control plane. Ensure that you have a `kubeconfig` +entry in your local `kubeconfig` that corresponds to the host cluster. +You can verify that you have the required `kubeconfig` entry by +running: + +```shell +kubectl config get-contexts +``` + +The output should contain an entry corresponding to your host cluster, +similar to the following: + +``` +CURRENT NAME CLUSTER AUTHINFO NAMESPACE + gke_myproject_asia-east1-b_gce-asia-east1 gke_myproject_asia-east1-b_gce-asia-east1 gke_myproject_asia-east1-b_gce-asia-east1 +``` + + +You'll need to provide the `kubeconfig` context (called name in the +entry above) for your host cluster when you deploy your federation +control plane. + + +## Deploying a federation control plane. + +To deploy a federation control plane on your host cluster, run +`kubefed init` command. When you use `kubefed init`, you must provide +the following: + +* Federation name +* `--host-cluster-context`, the `kubeconfig` context for the host cluster +* `--dns-zone-name`, a domain name suffix for your federated services + +The following example command deploys a federation control plane with +the name `fellowship`, a host cluster context `rivendell`, and the +domain suffix `example.com`: + +```shell +kubefed init fellowship --host-cluster-context=rivendell --dns-zone-name="example.com" +``` + +The domain suffix specified in `--dns-zone-name` must be an existing +domain that you control, and that is programmable by your DNS provider. + +`kubefed init` sets up the federation control plane in the host +cluster and also adds an entry for the federation API server in your +local kubeconfig. Note that in the alpha release in Kubernetes 1.5, +`kubefed init` does not automatically set the current context to the +newly deployed federation. You can set the current context manually by +running: + +```shell +kubectl config use-context fellowship +``` + +where `fellowship` is the name of your federation. + + +## Adding a cluster to a federation + +Once you've deployed a federation control plane, you'll need to make +that control plane aware of the clusters it should manage. You can add +a cluster to your federation by using the `kubefed join` command. + +To use `kubefed join`, you'll need to provide the name of the cluster +you want to add to the federation, and the `--host-cluster-context` +for the federation control plane's host cluster. + +The following example command adds the cluster `gondor` to the +federation with host cluster `rivendell`: + +``` +kubefed join gondor --host-cluster-context=rivendell +``` + +> Note: Kubernetes requires that you manually join clusters to a +federation because the federation control plane manages only those +clusters that it is responsible for managing. Adding a cluster tells +the federation control plane that it is responsible for managing that +cluster. + +### Naming rules and customization + +The cluster name you supply to `kubefed join` must be a valid RFC 1035 +label. + +Furthermore, federation control plane requires credentials of the +joined clusters to operate on them. These credentials are obtained +from the local kubeconfig. `kubefed join` uses the cluster name +specified as the argument to look for the cluster's context in the +local kubeconfig. If it fails to find a matching context, it exits +with an error. + +This might cause issues in cases where context names for each cluster +in the federation don't follow +[RFC 1035](https://www.ietf.org/rfc/rfc1035.txt) label naming rules. +In such cases, you can specify a cluster name that conforms to the +[RFC 1035](https://www.ietf.org/rfc/rfc1035.txt) label naming rules +and specify the cluster context using the `--cluster-context` flag. +For example, if context of the cluster your are joining is +`gondor_needs-no_king`, then you can join the cluster by running: + +```shell +kubefed join gondor --host-cluster-context=rivendell --cluster-context=gondor_needs-no_king +``` + +#### Secret name + +Cluster credentials required by the federation control plane as +described above are stored as a secret in the host cluster. The name +of the secret is also derived from the cluster name. + +However, the name of a secret object in Kubernetes should conform +to the DNS subdomain name specification described in +[RFC 1123](https://tools.ietf.org/html/rfc1123). If this isn't the +case, you can pass the secret name to `kubefed join` using the +`--secret-name` flag. For example, if the cluster name is `noldor` and +the secret name is `11kingdom`, you can join the cluster by +running: + +```shell +kubefed join noldor --host-cluster-context=rivendell --secret-name=11kingdom +``` + +Note: If your cluster name does not conform to the DNS subdomain name +specification, all you need to do is supply the secret name via the +`--secret-name` flag. `kubefed join` automatically creates the secret +for you. + + +## Removing a cluster from a federation + +To remove a cluster from a federation, run the `kubefed unjoin` +command with the cluster name and the federation's +`--host-cluster-context`: + +``` +kubefed unjoin gondor --host-cluster-context=rivendell +``` + + +## Turning down the federation control plane: + +Proper cleanup of federation control plane is not fully implemented in +this alpha release of `kubefed`. However, for the time being, deleting +the federation system namespace should remove all the resources except +the persistent storage volume dynamically provisioned for the +federation control plane's etcd. You can delete the federation +namespace by running the following command: + +``` +$ kubectl delete ns federation-system +``` diff --git a/docs/user-guide/federation/index.md b/docs/user-guide/federation/index.md index 10cea0ad6ed9f..6e97d9429b40a 100644 --- a/docs/user-guide/federation/index.md +++ b/docs/user-guide/federation/index.md @@ -2,136 +2,6 @@ title: Federation User Guide --- -This guide explains why and how to manage multiple Kubernetes clusters using -federation. +{% include user-guide-content-moved.md %} - -* TOC -{:toc} - - -## Why federation - -Federation makes it easy to manage multiple clusters. It does so by providing 2 -major building blocks: - - * Sync resources across clusters: Federation provides the ability to keep - resources in multiple clusters in sync. This can be used, for example, to - ensure that the same deployment exists in multiple clusters. - * Cross cluster discovery: It provides the ability to auto-configure DNS - servers and load balancers with backends from all clusters. This can be used, - for example, to ensure that a global VIP or DNS record can be used to access - backends from multiple clusters. - -Some other use cases that federation enables are: - -* High Availability: By spreading load across clusters and auto configuring DNS - servers and load balancers, federation minimises the impact of cluster - failure. -* Avoiding provider lock-in: By making it easier to migrate applications across - clusters, federation prevents cluster provider lock-in. - - -Federation is not helpful unless you have multiple clusters. Some of the reasons -why you might want multiple clusters are: - -* Low latency: Having clusters in multiple regions minimises latency by serving - users from the cluster that is closest to them. -* Fault isolation: It might be better to have multiple small clusters rather - than a single large cluster for fault isolation (for example: multiple - clusters in different availability zones of a cloud provider). - [Multi cluster guide](/docs/admin/multi-cluster) has more details on this. -* Scalability: There are scalability limits to a single kubernetes cluster (this - should not be the case for most users. For more details: - [Kubernetes Scaling and Performance Goals](https://github.com/kubernetes/community/blob/master/sig-scalability/goals.md)). -* Hybrid cloud: You can have multiple clusters on different cloud providers or - on-premises data centers. - - -### Caveats - -While there are a lot of attractive use cases for federation, there are also -some caveats. - -* Increased network bandwidth and cost: The federation control plane watches all - clusters to ensure that the current state is as expected. This can lead to - significant network cost if the clusters are running in different regions on - a cloud provider or on different cloud providers. -* Reduced cross cluster isolation: A bug in the federation control plane can - impact all clusters. This is mitigated by keeping the logic in federation - control plane to a minimum. It mostly delegates to the control plane in - kubernetes clusters whenever it can. The design and implementation also errs - on the side of safety and avoiding multicluster outage. -* Maturity: The federation project is relatively new and is not very mature. - Not all resources are available and many are still alpha. [Issue - 38893](https://github.com/kubernetes/kubernetes/issues/38893) ennumerates - known issues with the system that the team is busy solving. - -## Setup - -To be able to federate multiple clusters, we first need to setup a federation -control plane. -Follow the [setup guide](/docs/admin/federation/) to setup the -federation control plane. - -## Hybrid cloud capabilities - -Federations of Kubernetes Clusters can include clusters running in -different cloud providers (e.g. Google Cloud, AWS), and on-premises -(e.g. on OpenStack). Simply create all of the clusters that you -require, in the appropriate cloud providers and/or locations, and -register each cluster's API endpoint and credentials with your -Federation API Server (See the -[federation admin guide](/docs/admin/federation/) for details). - -Thereafter, your API resources can span different clusters -and cloud providers. - -## API resources - -Once we have the control plane setup, we can start creating federation API -resources. -The following guides explain some of the resources in detail: - -* [ConfigMap](https://kubernetes.io/docs/user-guide/federation/configmap/) -* [DaemonSets](https://kubernetes.io/docs/user-guide/federation/daemonsets/) -* [Deployment](https://kubernetes.io/docs/user-guide/federation/deployment/) -* [Events](https://kubernetes.io/docs/user-guide/federation/events/) -* [Ingress](https://kubernetes.io/docs/user-guide/federation/federated-ingress/) -* [Namespaces](https://kubernetes.io/docs/user-guide/federation/namespaces/) -* [ReplicaSets](https://kubernetes.io/docs/user-guide/federation/replicasets/) -* [Secrets](https://kubernetes.io/docs/user-guide/federation/secrets/) -* [Services](https://kubernetes.io/docs/user-guide/federation/federated-services/) - -[API reference docs](/docs/federation/api-reference/) lists all the -resources supported by federation apiserver. - -## Cascading deletion - -Kubernetes version 1.5 includes support for cascading deletion of federated -resources. With cascading deletion, when you delete a resource from the -federation control plane, the corresponding resources in all underlying clusters -are also deleted. - -To enable cascading deletion, set the option -`DeleteOptions.orphanDependents=false` when you delete a resource from the -federation control plane. - -The following Federated resources are affected by cascading deletion: - -* [Ingress](https://kubernetes.io/docs/user-guide/federation/federated-ingress/) -* [Namespaces](https://kubernetes.io/docs/user-guide/federation/namespaces/) -* [ReplicaSets](https://kubernetes.io/docs/user-guide/federation/replicasets/) -* [Secrets](https://kubernetes.io/docs/user-guide/federation/secrets/) -* [Deployment](https://kubernetes.io/docs/user-guide/federation/deployment/) -* [DaemonSets](https://kubernetes.io/docs/user-guide/federation/daemonsets/) - -Note: By default, deleting a resource from federation control plane does not -delete the corresponding resources from underlying clusters. - - -## For more information - -* [Federation - proposal](https://github.com/kubernetes/community/blob/{{page.githubbranch}}/contributors/design-proposals/federation.md) -* [Kubecon2016 talk on federation](https://www.youtube.com/watch?v=pq9lbkmxpS8) +[Federation](/docs/concepts/cluster-administration/federation.md)