Restructure the left navigation pane of setup (#14826)
* restructure left nav * Restructure setup left navigation * Update _redirects * Incorporated all the changes suggested * removed the Thumbs.db file
This commit is contained in:
Rajakavitha1
committed by
Kubernetes Prow Robot
Kubernetes Prow Robot
parent
f60947b370
commit
55ac801bc4
@@ -136,7 +136,7 @@ For information about enabling IPVS mode with kubeadm see:
|
||||
### Passing custom flags to control plane components {#control-plane-flags}
|
||||
|
||||
For information about passing flags to control plane components see:
|
||||
- [control-plane-flags](/docs/setup/independent/control-plane-flags/)
|
||||
- [control-plane-flags](/docs/setup/production-environment/tools/kubeadm/control-plane-flags/)
|
||||
|
||||
### Using custom images {#custom-images}
|
||||
|
||||
@@ -231,7 +231,7 @@ using an external CRI implementation.
|
||||
### Setting the node name
|
||||
|
||||
By default, `kubeadm` assigns a node name based on a machine's host address. You can override this setting with the `--node-name`flag.
|
||||
The flag passes the appropriate [`--hostname-override`](/docs/reference/command-line-tools-reference/kubelet/#options)
|
||||
The flag passes the appropriate [`--hostname-override`](/docs/reference/command-line-tools-reference/kubelet/#options)
|
||||
to the kubelet.
|
||||
|
||||
Be aware that overriding the hostname can [interfere with cloud providers](https://github.com/kubernetes/website/pull/8873).
|
||||
@@ -304,7 +304,7 @@ don't require an `-${ARCH}` suffix.
|
||||
### Automating kubeadm
|
||||
|
||||
Rather than copying the token you obtained from `kubeadm init` to each node, as
|
||||
in the [basic kubeadm tutorial](/docs/setup/independent/create-cluster-kubeadm/), you can parallelize the
|
||||
in the [basic kubeadm tutorial](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/), you can parallelize the
|
||||
token distribution for easier automation. To implement this automation, you must
|
||||
know the IP address that the control-plane node will have after it is started.
|
||||
|
||||
|
||||
@@ -14,9 +14,9 @@ Kubernetes contains several built-in tools to help you work with the Kubernetes
|
||||
|
||||
[`kubectl`](/docs/tasks/tools/install-kubectl/) is the command line tool for Kubernetes. It controls the Kubernetes cluster manager.
|
||||
|
||||
## Kubeadm
|
||||
## Kubeadm
|
||||
|
||||
[`kubeadm`](/docs/setup/independent/install-kubeadm/) is the command line tool for easily provisioning a secure Kubernetes cluster on top of physical or cloud servers or virtual machines (currently in alpha).
|
||||
[`kubeadm`](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/) is the command line tool for easily provisioning a secure Kubernetes cluster on top of physical or cloud servers or virtual machines (currently in alpha).
|
||||
|
||||
## Kubefed
|
||||
|
||||
@@ -29,10 +29,10 @@ to help you administrate your federated clusters.
|
||||
easy to run a single-node Kubernetes cluster locally on your workstation for
|
||||
development and testing purposes.
|
||||
|
||||
## Dashboard
|
||||
## Dashboard
|
||||
|
||||
[`Dashboard`](/docs/tasks/access-application-cluster/web-ui-dashboard/), the web-based user interface of Kubernetes, allows you to deploy containerized applications
|
||||
to a Kubernetes cluster, troubleshoot them, and manage the cluster and its resources itself.
|
||||
to a Kubernetes cluster, troubleshoot them, and manage the cluster and its resources itself.
|
||||
|
||||
## Helm
|
||||
|
||||
|
||||
@@ -87,13 +87,13 @@ no less than:**
|
||||
* **Beta: 9 months or 3 releases (whichever is longer)**
|
||||
* **Alpha: 0 releases**
|
||||
|
||||
This covers the [maximum supported version skew of 2 releases](/docs/setup/version-skew-policy/).
|
||||
This covers the [maximum supported version skew of 2 releases](/docs/setup/release/version-skew-policy/).
|
||||
|
||||
{{< note >}}
|
||||
Until [#52185](https://github.com/kubernetes/kubernetes/issues/52185) is
|
||||
resolved, no API versions that have been persisted to storage may be removed.
|
||||
Serving REST endpoints for those versions may be disabled (subject to the
|
||||
deprecation timelines in this document), but the API server must remain capable
|
||||
resolved, no API versions that have been persisted to storage may be removed.
|
||||
Serving REST endpoints for those versions may be disabled (subject to the
|
||||
deprecation timelines in this document), but the API server must remain capable
|
||||
of decoding/converting previously persisted data from storage.
|
||||
{{< /note >}}
|
||||
|
||||
@@ -365,54 +365,54 @@ This applies only to significant, user-visible behaviors which impact the
|
||||
correctness of applications running on Kubernetes or that impact the
|
||||
administration of Kubernetes clusters, and which are being removed entirely.
|
||||
|
||||
An exception to the above rule is _feature gates_. Feature gates are key=value
|
||||
An exception to the above rule is _feature gates_. Feature gates are key=value
|
||||
pairs that allow for users to enable/disable experimental features.
|
||||
|
||||
Feature gates are intended to cover the development life cycle of a feature - they
|
||||
are not intended to be long-term APIs. As such, they are expected to be deprecated
|
||||
and removed after a feature becomes GA or is dropped.
|
||||
Feature gates are intended to cover the development life cycle of a feature - they
|
||||
are not intended to be long-term APIs. As such, they are expected to be deprecated
|
||||
and removed after a feature becomes GA or is dropped.
|
||||
|
||||
As a feature moves through the stages, the associated feature gate evolves.
|
||||
As a feature moves through the stages, the associated feature gate evolves.
|
||||
The feature life cycle matched to its corresponding feature gate is:
|
||||
|
||||
* Alpha: the feature gate is disabled by default and can be enabled by the user.
|
||||
* Beta: the feature gate is enabled by default and can be disabled by the user.
|
||||
* GA: the feature gate is deprecated (see ["Deprecation"](#deprecation)) and becomes
|
||||
* GA: the feature gate is deprecated (see ["Deprecation"](#deprecation)) and becomes
|
||||
non-operational.
|
||||
* GA, deprecation window complete: the feature gate is removed and calls to it are
|
||||
* GA, deprecation window complete: the feature gate is removed and calls to it are
|
||||
no longer accepted.
|
||||
|
||||
### Deprecation
|
||||
|
||||
Features can be removed at any point in the life cycle prior to GA. When features are
|
||||
Features can be removed at any point in the life cycle prior to GA. When features are
|
||||
removed prior to GA, their associated feature gates are also deprecated.
|
||||
|
||||
When an invocation tries to disable a non-operational feature gate, the call fails in order
|
||||
When an invocation tries to disable a non-operational feature gate, the call fails in order
|
||||
to avoid unsupported scenarios that might otherwise run silently.
|
||||
|
||||
In some cases, removing pre-GA features requires considerable time. Feature gates can remain
|
||||
operational until their associated feature is fully removed, at which point the feature gate
|
||||
itself can be deprecated.
|
||||
In some cases, removing pre-GA features requires considerable time. Feature gates can remain
|
||||
operational until their associated feature is fully removed, at which point the feature gate
|
||||
itself can be deprecated.
|
||||
|
||||
When removing a feature gate for a GA feature also requires considerable time, calls to
|
||||
feature gates may remain operational if the feature gate has no effect on the feature,
|
||||
When removing a feature gate for a GA feature also requires considerable time, calls to
|
||||
feature gates may remain operational if the feature gate has no effect on the feature,
|
||||
and if the feature gate causes no errors.
|
||||
|
||||
Features intended to be disabled by users should include a mechanism for disabling the
|
||||
Features intended to be disabled by users should include a mechanism for disabling the
|
||||
feature in the associated feature gate.
|
||||
|
||||
Versioning for feature gates is different from the previously discussed components,
|
||||
therefore the rules for deprecation are as follows:
|
||||
|
||||
**Rule #8: Feature gates must be deprecated when the corresponding feature they control
|
||||
**Rule #8: Feature gates must be deprecated when the corresponding feature they control
|
||||
transitions a lifecycle stage as follows. Feature gates must function for no less than:**
|
||||
|
||||
* **Beta feature to GA: 6 months or 2 releases (whichever is longer)**
|
||||
* **Beta feature to EOL: 3 months or 1 release (whichever is longer)**
|
||||
* **Alpha feature to EOL: 0 releases**
|
||||
|
||||
**Rule #9: Deprecated feature gates must respond with a warning when used. When a feature gate
|
||||
is deprecated it must be documented in both in the release notes and the corresponding CLI help.
|
||||
**Rule #9: Deprecated feature gates must respond with a warning when used. When a feature gate
|
||||
is deprecated it must be documented in both in the release notes and the corresponding CLI help.
|
||||
Both warnings and documentation must indicate whether a feature gate is non-operational.**
|
||||
|
||||
## Exceptions
|
||||
|
||||
Reference in New Issue
Block a user