January 2018 monthly site maintenance (#6924)
* Updated 404 link to kubeadm ref
* Update ref link to Federation API
* Fix broken links
* Manual fixes to autogenerated links
* Revert "Manual fixes to autogenerated links"
This reverts commit 94dba97a08.
This commit is contained in:
Zach Corleissen
GitHub
parent
e99ea770fa
commit
9b842acfef
|
|
@ -99,7 +99,8 @@ The following guides explain some of the resources in detail:
|
|||
* [Secrets](/docs/tasks/administer-federation/secret/)
|
||||
* [Services](/docs/concepts/cluster-administration/federation-service-discovery/)
|
||||
|
||||
[API reference docs](/docs/reference/generated/federation/) lists all the
|
||||
|
||||
The [API reference docs](/docs/reference/generated/federation/) list all the
|
||||
resources supported by federation apiserver.
|
||||
|
||||
## Cascading deletion
|
||||
|
|
@ -178,4 +179,3 @@ clusters up to 5000 nodes. See [Building Large Clusters](/docs/admin/cluster-lar
|
|||
{% endcapture %}
|
||||
|
||||
{% include templates/concept.md %}
|
||||
|
||||
|
|
|
|||
|
|
@ -32,9 +32,9 @@ following steps:
|
|||
kubeconfig file for administration named `admin.conf`.
|
||||
|
||||
1. If kubeadm is invoked with `--feature-gates=DynamicKubeletConfig` enabled,
|
||||
it writes the kubelet init configuration into the `/var/lib/kubelet/config/init/kubelet` file.
|
||||
See [Set Kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file.md)
|
||||
and [Reconfigure a Node's Kubelet in a Live Cluster](/docs/tasks/administer-cluster/reconfigure-kubelet.md)
|
||||
it writes the kubelet init configuration into the `/var/lib/kubelet/config/init/kubelet` file.
|
||||
See [Set Kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file/)
|
||||
and [Reconfigure a Node's Kubelet in a Live Cluster](/docs/tasks/administer-cluster/reconfigure-kubelet/)
|
||||
for more information about Dynamic Kubelet Configuration.
|
||||
This functionality is now by default disabled as it is behind a feature gate, but is expected to be a default in future versions.
|
||||
|
||||
|
|
@ -49,11 +49,11 @@ following steps:
|
|||
|
||||
1. If kubeadm is invoked with `--feature-gates=DynamicKubeletConfig` enabled,
|
||||
it completes the kubelet dynamic configuration by creating a ConfigMap and some RBAC rules that enable
|
||||
kubelets to access to it, and updates the node by pointing `Node.spec.configSource` to the
|
||||
newly-created ConfigMap.
|
||||
kubelets to access to it, and updates the node by pointing `Node.spec.configSource` to the
|
||||
newly-created ConfigMap.
|
||||
This functionality is now by default disabled as it is behind a feature gate, but is expected to be a default in future versions.
|
||||
|
||||
1. Apply labels and taints to the master node so that no additional workloads will
|
||||
1. Apply labels and taints to the master node so that no additional workloads will
|
||||
run there.
|
||||
|
||||
1. Generates the token that additional nodes can use to register
|
||||
|
|
@ -161,11 +161,11 @@ featureGates:
|
|||
|
||||
### Passing custom arguments to control plane components {#custom-args}
|
||||
|
||||
If you would like to override or extend the behaviour of a control plane component, you can provide
|
||||
extra arguments to kubeadm. When the component is deployed, these additional arguments are added to
|
||||
the Pod command itself.
|
||||
If you would like to override or extend the behaviour of a control plane component, you can provide
|
||||
extra arguments to kubeadm. When the component is deployed, these additional arguments are added to
|
||||
the Pod command itself.
|
||||
|
||||
For example, to add additional feature-gate arguments to the API server, your [configuration file](#config-file)
|
||||
For example, to add additional feature-gate arguments to the API server, your [configuration file](#config-file)
|
||||
will need to look like this:
|
||||
|
||||
```
|
||||
|
|
@ -209,14 +209,14 @@ is `/etc/kubernetes/pki`.
|
|||
If a given certificate and private key pair exists, kubeadm skips the
|
||||
generation step and existing files are used for the prescribed
|
||||
use case. This means you can, for example, copy an existing CA into `/etc/kubernetes/pki/ca.crt`
|
||||
and `/etc/kubernetes/pki/ca.key`, and kubeadm will use this CA for signing the rest
|
||||
and `/etc/kubernetes/pki/ca.key`, and kubeadm will use this CA for signing the rest
|
||||
of the certs.
|
||||
|
||||
#### External CA mode {#external-ca-mode}
|
||||
|
||||
It is also possible to provide just the `ca.crt` file and not the
|
||||
`ca.key` file (this is only available for the root CA file, not other cert pairs).
|
||||
If all other certificates and kubeconfig files are in place, kubeadm recognizes
|
||||
It is also possible to provide just the `ca.crt` file and not the
|
||||
`ca.key` file (this is only available for the root CA file, not other cert pairs).
|
||||
If all other certificates and kubeconfig files are in place, kubeadm recognizes
|
||||
this condition and activates the "External CA" mode. kubeadm will proceed without the
|
||||
CA key on disk.
|
||||
|
||||
|
|
@ -247,9 +247,9 @@ ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_SYSTEM_PODS_ARGS $K
|
|||
|
||||
Here's a breakdown of what/why:
|
||||
|
||||
* `--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf` path to a kubeconfig
|
||||
file that is used to get client certificates for kubelet during node join.
|
||||
On success, a kubeconfig file is written to the path specified by `--kubeconfig`.
|
||||
* `--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf` path to a kubeconfig
|
||||
file that is used to get client certificates for kubelet during node join.
|
||||
On success, a kubeconfig file is written to the path specified by `--kubeconfig`.
|
||||
* `--kubeconfig=/etc/kubernetes/kubelet.conf` points to the kubeconfig file that
|
||||
tells the kubelet where the API server is. This file also has the kubelet's
|
||||
credentials.
|
||||
|
|
@ -278,7 +278,7 @@ Here's a breakdown of what/why:
|
|||
systemctl daemon-reload
|
||||
systemctl restart kubelet
|
||||
```
|
||||
* `--rotate-certificates` auto rotate the kubelet client certificates by requesting new
|
||||
* `--rotate-certificates` auto rotate the kubelet client certificates by requesting new
|
||||
certificates from the `kube-apiserver` when the certificate expiration approaches.
|
||||
* `--cert-dir`the directory where the TLS certs are located.
|
||||
|
||||
|
|
@ -343,7 +343,7 @@ a future version. To create a self-hosted cluster, pass the `--feature-gates=Sel
|
|||
flag to `kubeadm init`.
|
||||
{: .caution}
|
||||
|
||||
**Warning:** see self-hosted caveats and limitations.
|
||||
**Warning:** see self-hosted caveats and limitations.
|
||||
{: .warning}
|
||||
|
||||
#### Caveats
|
||||
|
|
@ -377,14 +377,14 @@ In summary, `kubeadm init --feature-gates=SelfHosting=true` works as follows:
|
|||
|
||||
1. Uses the static control plane Pod manifests to construct a set of
|
||||
DaemonSet manifests that will run the self-hosted control plane.
|
||||
It also modifies these manifests where necessary, for example adding new volumes
|
||||
It also modifies these manifests where necessary, for example adding new volumes
|
||||
for secrets.
|
||||
|
||||
1. Creates DaemonSets in the `kube-system` namespace and waits for the
|
||||
resulting Pods to be running.
|
||||
|
||||
1. Once self-hosted Pods are operational, it's associated static Pods are deleted
|
||||
and kubeadm moves on to install the next component. This triggers kubelet to
|
||||
1. Once self-hosted Pods are operational, it's associated static Pods are deleted
|
||||
and kubeadm moves on to install the next component. This triggers kubelet to
|
||||
stop those static Pods.
|
||||
|
||||
1. When the original static control plane stops, the new self-hosted control
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ title: kubeadm join
|
|||
|
||||
### The joining workflow
|
||||
|
||||
`kubeadm join` bootstraps a Kubernetes worker node and joins it to the cluster.
|
||||
`kubeadm join` bootstraps a Kubernetes worker node and joins it to the cluster.
|
||||
This action consists of the following steps:
|
||||
|
||||
1. kubeadm downloads necessary cluster information from the API server.
|
||||
|
|
@ -23,9 +23,9 @@ This action consists of the following steps:
|
|||
|
||||
1. If kubeadm is invoked with `--feature-gates=DynamicKubeletConfig` enabled,
|
||||
it first retrieves the kubelet init configuration from the master and writes it to
|
||||
the disk. When kubelet starts up, kubeadm updates the node `Node.spec.configSource` property of the node.
|
||||
See [Set Kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file.md)
|
||||
and [Reconfigure a Node's Kubelet in a Live Cluster](/docs/tasks/administer-cluster/reconfigure-kubelet.md)
|
||||
the disk. When kubelet starts up, kubeadm updates the node `Node.spec.configSource` property of the node.
|
||||
See [Set Kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file/)
|
||||
and [Reconfigure a Node's Kubelet in a Live Cluster](/docs/tasks/administer-cluster/reconfigure-kubelet/)
|
||||
for more information about Dynamic Kubelet Configuration.
|
||||
|
||||
1. Once the cluster information is known, kubelet can start the TLS bootstrapping
|
||||
|
|
@ -51,7 +51,7 @@ the cluster configuration (including root CA) and validates it using the token
|
|||
as well as validating that the root CA public key matches the provided hash and
|
||||
that the API server certificate is valid under the root CA.
|
||||
|
||||
The CA key hash has the format `sha256:<hex_encoded_hash>`. By default, the hash value is returned in the `kubeadm join` command printed at the end of `kubeadm init` or in the output of `kubeadm token create --print-join-command`. It is in a standard format (see [RFC7469](https://tools.ietf.org/html/rfc7469#section-2.4)) and can also be calculated by 3rd party tools or provisioning systems. For example, using the OpenSSL CLI:
|
||||
The CA key hash has the format `sha256:<hex_encoded_hash>`. By default, the hash value is returned in the `kubeadm join` command printed at the end of `kubeadm init` or in the output of `kubeadm token create --print-join-command`. It is in a standard format (see [RFC7469](https://tools.ietf.org/html/rfc7469#section-2.4)) and can also be calculated by 3rd party tools or provisioning systems. For example, using the OpenSSL CLI:
|
||||
|
||||
```bash
|
||||
openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | openssl dgst -sha256 -hex | sed 's/^.* //'
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ scope.
|
|||
You can install _kubeadm_ very easily on operating systems that support
|
||||
installing deb or rpm packages. The responsible SIG for kubeadm,
|
||||
[SIG Cluster Lifecycle](https://github.com/kubernetes/community/tree/master/sig-cluster-lifecycle), provides these packages pre-built for you,
|
||||
but you may also on other OSes.
|
||||
but you may also on other OSes.
|
||||
|
||||
|
||||
### kubeadm Maturity
|
||||
|
|
@ -47,7 +47,7 @@ but you may also on other OSes.
|
|||
| Config file API | alpha |
|
||||
| Self-hosting | alpha |
|
||||
| kubeadm alpha subcommands | alpha |
|
||||
| CoreDNS | alpha |
|
||||
| CoreDNS | alpha |
|
||||
| DynamicKubeletConfig | alpha |
|
||||
|
||||
|
||||
|
|
@ -123,15 +123,15 @@ kubeadm init
|
|||
**Notes:**
|
||||
|
||||
- Please refer to the [kubeadm reference guide](/docs/reference/setup-tools/kubeadm/kubeadm/) if you want to
|
||||
read more about the flags `kubeadm init` provides. You can also specify a
|
||||
read more about the flags `kubeadm init` provides. You can also specify a
|
||||
[configuration file](/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file) instead of using flags.
|
||||
- You need to choose a Pod Network Plugin in the next step. Depending on what
|
||||
third-party provider you choose, you might have to set the `--pod-network-cidr` to
|
||||
something provider-specific. The tabs below will contain a notice about what flags
|
||||
on `kubeadm init` are required.
|
||||
- Unless otherwise specified, kubeadm uses the default gateway's network interface
|
||||
to advertise the master's IP. If you want to use a different network interface, specify
|
||||
`--apiserver-advertise-address=<ip-address>` argument to `kubeadm init`. To deploy an IPv6 Kubernetes cluster using IPv6 addressing, you must specify an IPv6, e.g. `--apiserver-advertise-address=fd00::101`
|
||||
- Unless otherwise specified, kubeadm uses the default gateway's network interface
|
||||
to advertise the master's IP. If you want to use a different network interface, specify
|
||||
`--apiserver-advertise-address=<ip-address>` argument to `kubeadm init`. To deploy an IPv6 Kubernetes cluster using IPv6 addressing, you must specify an IPv6, e.g. `--apiserver-advertise-address=fd00::101`
|
||||
- If you would like to customise control plane components including optional IPv6 assignment to liveness probe for control plane components and etcd server, you can do so by providing extra args to each one, as documented [here](/docs/admin/kubeadm#custom-args).
|
||||
- `kubeadm init` will first run a series of prechecks to ensure that the machine
|
||||
is ready to run Kubernetes. It will expose warnings and exit on errors. It
|
||||
|
|
@ -292,7 +292,7 @@ kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/v0.9.1/Documen
|
|||
```
|
||||
|
||||
- For more information about `flannel`, please see [here](https://github.com/coreos/flannel).
|
||||
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
{% capture kube-router %}
|
||||
|
|
|
|||
Loading…
Reference in New Issue