Change:
This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Hyperlinks don't work Hyperlinks to topics <bKubernetes control plane</band <bKubernetes objects</btakes to back to <bConcepts</bpage rather than respective topics. Proposed Solution: Update linkw to point to correct content. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
Hi If related documents are not missing, then Perhaps Kubernetes control plane should point to I noticed that the corresponding file , later than the link on page . And Kubernetes objects perhaps should point to . Seems a little bit weird. These documents should be in the same hierarchy I think. Let me create a PR to solve this issue. /assign
/kind bug
I think the link for Kubernetes control-plane should be to and I agree above that the link for Kubernetes objects should be to /assign
Hi Thanks for your PR! I submitted a PR (ref: ) to fix this issue about half a month ago, and just got approved 3 days ago. Since the CLA checking was missing after I migrated to a new github account, this PR was not merged until a few minutes ago after I let the robot recheck my CLA.

Discussion:
- Non-critical add-ons, e.g. for monitoring, logging, and visualization - Specific cloud provider integrations <del> Infrastructure provisioning, for example, is left to other SIG Cluster Lifecycle projects, such as the [Cluster API](https://github.com/kubernetes-sigs/cluster-api). Instead, kubeadm covers only the common denominator in every Kubernetes cluster: the [control plane](/docs/concepts/#kubernetes-control-plane). The user may install their preferred networking solution and other add-ons on top of Kubernetes *after* cluster creation. </del> <ins> Infrastructure provisioning, for example, is left to other SIG Cluster Lifecycle projects, such as the [Cluster API](https://github.com/kubernetes-sigs/cluster-api). Instead, kubeadm covers only the common denominator in every Kubernetes cluster: the [control plane](/docs/concepts/overview/components/#control-plane-components). The user may install their preferred networking solution and other add-ons on top of Kubernetes *after* cluster creation. </ins> ### What kubeadm's GA release means

[Cluster API](https://github.com/kubernetes-sigs/cluster-api) for infrastructure provisioning and management. Instead, kubeadm covers only the common denominator in every Kubernetes cluster: the <del> [control plane](https://kubernetes.io/docs/concepts/#kubernetes-control-plane). </del> <ins> [control plane](/docs/concepts/overview/components/#control-plane-components). </ins> ![Cluster Lifecycle Layers](/images/blog/2019-06-24-kubeadm-ha-v115/overview.png)

## {{% heading "whatsnext" %}} <del> * Read about the [Kubernetes control plane](/docs/concepts/#kubernetes-control-plane) * Discover some of the basic [Kubernetes objects](/docs/concepts/#kubernetes-objects) </del> <ins> * Read about the [Kubernetes control plane](/docs/concepts/overview/components/) * Discover some of the basic [Kubernetes objects](/docs/concepts/overview/working-with-objects) </ins> * Learn more about the [Kubernetes API](/docs/concepts/overview/kubernetes-api/) * If you want to write your own controller, see [Extension Patterns](/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns) in Extending Kubernetes.

Operators are software extensions to Kubernetes that make use of [custom resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) to manage applications and their components. Operators follow <del> Kubernetes principles, notably the [control loop](/docs/concepts/#kubernetes-control-plane). </del> <ins> Kubernetes principles, notably the [control loop](/docs/concepts/architecture/controller). </ins> <!-- body -->