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
@@ -107,7 +107,7 @@ KUBE_GCE_ZONE=replica-zone KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up
|
||||
|
||||
* Try to place master replicas in different zones. During a zone failure, all masters placed inside the zone will fail.
|
||||
To survive zone failure, also place nodes in multiple zones
|
||||
(see [multiple-zones](/docs/setup/multiple-zones/) for details).
|
||||
(see [multiple-zones](/docs/setup/best-practices/multiple-zones/) for details).
|
||||
|
||||
* Do not use a cluster with two master replicas. Consensus on a two-replica cluster requires both replicas running when changing persistent state.
|
||||
As a result, both replicas are needed and a failure of any replica turns cluster into majority failure state.
|
||||
|
||||
@@ -15,7 +15,7 @@ This page explains how to manage certificates manually with kubeadm.
|
||||
|
||||
These are advanced topics for users who need to integrate their organization's certificate infrastructure into a kubeadm-built cluster. If kubeadm with the default configuration satisfies your needs, you should let kubeadm manage certificates instead.
|
||||
|
||||
You should be familiar with [PKI certificates and requirements in Kubernetes](/docs/setup/certificates/).
|
||||
You should be familiar with [PKI certificates and requirements in Kubernetes](/docs/setup/best-practices/certificates/).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -23,7 +23,7 @@ You should be familiar with [PKI certificates and requirements in Kubernetes](/d
|
||||
|
||||
## Renew certificates with the certificates API
|
||||
|
||||
The Kubernetes certificates normally reach their expiration date after one year.
|
||||
The Kubernetes certificates normally reach their expiration date after one year.
|
||||
|
||||
Kubeadm can renew certificates with the `kubeadm alpha certs renew` commands; you should run these commands on control-plane nodes only.
|
||||
|
||||
@@ -36,9 +36,9 @@ With kubeadm, you can use this API by running `kubeadm alpha certs renew --use-a
|
||||
|
||||
## Set up a signer
|
||||
|
||||
The Kubernetes Certificate Authority does not work out of the box.
|
||||
You can configure an external signer such as [cert-manager][cert-manager-issuer], or you can use the build-in signer.
|
||||
The built-in signer is part of [`kube-controller-manager`][kcm].
|
||||
The Kubernetes Certificate Authority does not work out of the box.
|
||||
You can configure an external signer such as [cert-manager][cert-manager-issuer], or you can use the build-in signer.
|
||||
The built-in signer is part of [`kube-controller-manager`][kcm].
|
||||
To activate the build-in signer, you pass the `--cluster-signing-cert-file` and `--cluster-signing-key-file` arguments.
|
||||
|
||||
You pass these arguments in any of the following ways:
|
||||
@@ -67,7 +67,7 @@ You pass these arguments in any of the following ways:
|
||||
### Approve requests
|
||||
|
||||
If you set up an external signer such as [cert-manager][cert-manager], certificate signing requests (CSRs) are automatically approved.
|
||||
Otherwise, you must manually approve certificates with the [`kubectl certificate`][certs] command.
|
||||
Otherwise, you must manually approve certificates with the [`kubectl certificate`][certs] command.
|
||||
The following kubeadm command outputs the name of the certificate to approve, then blocks and waits for approval to occur:
|
||||
|
||||
```shell
|
||||
@@ -91,28 +91,28 @@ You can view a list of pending certificates with `kubectl get csr`.
|
||||
|
||||
## Certificate requests with kubeadm
|
||||
|
||||
To better integrate with external CAs, kubeadm can also produce certificate signing requests (CSRs).
|
||||
A CSR represents a request to a CA for a signed certificate for a client.
|
||||
To better integrate with external CAs, kubeadm can also produce certificate signing requests (CSRs).
|
||||
A CSR represents a request to a CA for a signed certificate for a client.
|
||||
In kubeadm terms, any certificate that would normally be signed by an on-disk CA can be produced as a CSR instead. A CA, however, cannot be produced as a CSR.
|
||||
|
||||
You can create an individual CSR with `kubeadm init phase certs apiserver --csr-only`.
|
||||
The `--csr-only` flag can be applied only to individual phases. After [all certificates are in place][certs], you can run `kubeadm init --external-ca`.
|
||||
|
||||
You can pass in a directory with `--csr-dir` to output the CSRs to the specified location.
|
||||
You can pass in a directory with `--csr-dir` to output the CSRs to the specified location.
|
||||
If `--csr-dir` is not specified, the default certificate directory (`/etc/kubernetes/pki`) is used.
|
||||
Both the CSR and the accompanying private key are given in the output. After a certificate is signed, the certificate and the private key must be copied to the PKI directory (by default `/etc/kubernetes/pki`).
|
||||
|
||||
### Renew certificates
|
||||
|
||||
Certificates can be renewed with `kubeadm alpha certs renew --csr-only`.
|
||||
As with `kubeadm init`, an output directory can be specified with the `--csr-dir` flag.
|
||||
As with `kubeadm init`, an output directory can be specified with the `--csr-dir` flag.
|
||||
To use the new certificates, copy the signed certificate and private key into the PKI directory (by default `/etc/kubernetes/pki`)
|
||||
|
||||
## Cert usage
|
||||
|
||||
A CSR contains a certificate's name, domains, and IPs, but it does not specify usages.
|
||||
A CSR contains a certificate's name, domains, and IPs, but it does not specify usages.
|
||||
It is the responsibility of the CA to specify [the correct cert usages][cert-table] when issuing a certificate.
|
||||
|
||||
|
||||
* In `openssl` this is done with the [`openssl ca` command][openssl-ca].
|
||||
* In `cfssl` you specify [usages in the config file][cfssl-usages]
|
||||
|
||||
@@ -122,8 +122,8 @@ Kubeadm sets up [three CAs][cert-cas] by default. Make sure to sign the CSRs wit
|
||||
|
||||
[openssl-ca]: https://superuser.com/questions/738612/openssl-ca-keyusage-extension
|
||||
[cfssl-usages]: https://github.com/cloudflare/cfssl/blob/master/doc/cmd/cfssl.txt#L170
|
||||
[certs]: /docs/setup/certificates
|
||||
[cert-cas]: /docs/setup/certificates/#single-root-ca
|
||||
[cert-table]: /docs/setup/certificates/#all-certificates
|
||||
[certs]: /docs/setup/best-practices/certificates/
|
||||
[cert-cas]: /docs/setup/best-practices/certificates/#single-root-ca
|
||||
[cert-table]: /docs/setup/best-practices/certificates/#all-certificates
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -10,7 +10,7 @@ content_template: templates/task
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
This page explains how to upgrade a highly available (HA) Kubernetes cluster created with `kubeadm` from version 1.11.x to version 1.12.x. In addition to upgrading, you must also follow the instructions in [Creating HA clusters with kubeadm](/docs/setup/independent/high-availability/).
|
||||
This page explains how to upgrade a highly available (HA) Kubernetes cluster created with `kubeadm` from version 1.11.x to version 1.12.x. In addition to upgrading, you must also follow the instructions in [Creating HA clusters with kubeadm](/docs/setup/production-environment/tools/kubeadm/high-availability/).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -9,7 +9,7 @@ content_template: templates/task
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
This page explains how to upgrade a highly available (HA) Kubernetes cluster created with `kubeadm` from version 1.12.x to version 1.13.y. In addition to upgrading, you must also follow the instructions in [Creating HA clusters with kubeadm](/docs/setup/independent/high-availability/).
|
||||
This page explains how to upgrade a highly available (HA) Kubernetes cluster created with `kubeadm` from version 1.12.x to version 1.13.y. In addition to upgrading, you must also follow the instructions in [Creating HA clusters with kubeadm](/docs/setup/production-environment/tools/kubeadm/high-availability/).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -44,7 +44,7 @@ it to [support other log format](/docs/tasks/debug-application-cluster/monitor-n
|
||||
|
||||
## Enable/Disable in GCE cluster
|
||||
|
||||
Node problem detector is [running as a cluster addon](/docs/setup/cluster-large/#addon-resources) enabled by default in the
|
||||
Node problem detector is [running as a cluster addon](/docs/setup/best-practices/cluster-large/#addon-resources) enabled by default in the
|
||||
gce cluster.
|
||||
|
||||
You can enable/disable it by setting the environment variable
|
||||
|
||||
@@ -25,8 +25,8 @@ This document walks you through an example of enabling Horizontal Pod Autoscaler
|
||||
|
||||
This example requires a running Kubernetes cluster and kubectl, version 1.2 or later.
|
||||
[metrics-server](https://github.com/kubernetes-incubator/metrics-server/) monitoring needs to be deployed in the cluster
|
||||
to provide metrics via the resource metrics API, as Horizontal Pod Autoscaler uses this API to collect metrics. The instructions for deploying this are on the GitHub repository of [metrics-server](https://github.com/kubernetes-incubator/metrics-server/), if you followed [getting started on GCE guide](/docs/setup/turnkey/gce/),
|
||||
metrics-server monitoring will be turned-on by default.
|
||||
to provide metrics via the resource metrics API, as Horizontal Pod Autoscaler uses this API to collect metrics. The instructions for deploying this are on the GitHub repository of [metrics-server](https://github.com/kubernetes-incubator/metrics-server/), if you followed [getting started on GCE guide](/docs/setup/production-environment/turnkey/gce/),
|
||||
metrics-server monitoring will be turned-on by default.
|
||||
|
||||
To specify multiple resource metrics for a Horizontal Pod Autoscaler, you must have a Kubernetes cluster
|
||||
and kubectl at version 1.6 or later. Furthermore, in order to make use of custom metrics, your cluster
|
||||
|
||||
@@ -179,7 +179,7 @@ To install Minikube manually on Windows, download [`minikube-windows-amd64`](htt
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
* [Running Kubernetes Locally via Minikube](/docs/setup/minikube/)
|
||||
* [Running Kubernetes Locally via Minikube](/docs/setup/learning-environment/minikube/)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
Reference in New Issue
Block a user