whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Resolving merge conflicts with master

Browse Source
This commit is contained in:
zacharysarah
2017-11-30 18:53:33 -06:00
parent 53f460ad9e a49d85186a
commit 538dd33ff2
5068 changed files with 25074 additions and 855452 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/tasks/administer-cluster/reconfigure-kubelet.md
+12 -11
View File
@@ -89,12 +89,13 @@ and debug issues. The compromise, however, is that you must start with knowledge
of the existing configuration to ensure that you only change the fields you
intend to change.
In the future, the Kubelet will be bootstrapped from a file on disk, and you
will simply edit a copy of this file (which, as a best practice, should live in
version control) while creating the first Kubelet ConfigMap. Today, however, the
Kubelet is still bootstrapped with command-line flags. Fortunately, there is a
dirty trick you can use to generate a config file containing a Node's current
configuration. The trick involves hitting the Kubelet server's `configz`
In the future, the Kubelet will be bootstrapped from a file on disk
(see [Set Kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file)),
and you will simply edit a copy of this file (which, as a best practice, should
live in version control) while creating the first Kubelet ConfigMap. Today,
however, the Kubelet is still bootstrapped with command-line flags. Fortunately,
there is a dirty trick you can use to generate a config file containing a Node's
current configuration. The trick involves hitting the Kubelet server's `configz`
endpoint via the kubectl proxy. This endpoint, in its current implementation, is
intended to be used only as a debugging aid, which is part of why this is a
dirty trick. There is ongoing work to improve the endpoint, and in the future
@@ -158,7 +159,7 @@ because this ConfigMap configures a Kubernetes system component - the Kubelet.
The `--append-hash` option appends a short checksum of the ConfigMap contents
to the name. This is convenient for an edit->push workflow, as it will
automatically, yet deterministically, generate new names for new ConfigMaps.
automatically, yet deterministically, generate new names for new ConfigMaps.
We use the `-o yaml` output format so that the name, namespace, and uid are all
reported following creation. We will need these in the next step. We will refer
@@ -167,7 +168,7 @@ to the name as CONFIG_MAP_NAME and the uid as CONFIG_MAP_UID.
### Authorize your Node to read the new ConfigMap
Now that you've created a new ConfigMap, you need to authorize your node to
read it. First, create a Role for your new ConfigMap with the
read it. First, create a Role for your new ConfigMap with the
following commands:
```
@@ -182,7 +183,7 @@ $ kubectl -n kube-system create rolebinding ${CONFIG_MAP_NAME}-reader --role=${C
```
Once the Node Authorizer is updated to do this automatically, you will
be able to skip this step.
be able to skip this step.
### Set the Node to use the new configuration
@@ -255,7 +256,7 @@ as NEW_CONFIG_MAP_UID.
### Authorize your Node to read the new ConfigMap
Now that you've created a new ConfigMap, you need to authorize your node to
read it. First, create a Role for your new ConfigMap with the
read it. First, create a Role for your new ConfigMap with the
following commands:
```
@@ -270,7 +271,7 @@ $ kubectl -n kube-system create rolebinding ${NEW_CONFIG_MAP_NAME}-reader --role
```
Once the Node Authorizer is updated to do this automatically, you will
be able to skip this step.
be able to skip this step.
### Configure the Node to use the new configuration