public/rancher-docs
1
0
Fork 0
mirror of https://github.com/rancher/rancher-docs.git synced 2026-09-29 14:38:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Replace 'prior to' with 'before'

Browse Source 
Use wording understood by wider audience
This commit is contained in:
Billy Tat
2021-02-17 17:39:55 -08:00
parent 79b48f7b5e
commit 5a9e1f73c1
109 changed files with 187 additions and 187 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/rke/latest/en/config-options/add-ons/_index.md
+1 -1
View File
@@ -16,7 +16,7 @@ There are a few things worth noting:
* In addition to these pluggable add-ons, you can specify an add-on that you want deployed after the cluster deployment is complete.
* As of v0.1.8, RKE will update an add-on if it is the same name.
* Prior to v0.1.8, update any add-ons by using `kubectl edit`.
* Before v0.1.8, update any add-ons by using `kubectl edit`.
## Critical and Non-Critical Add-ons
content/rke/latest/en/config-options/add-ons/ingress-controllers/_index.md
+1 -1
View File
@@ -6,7 +6,7 @@ weight: 262
By default, RKE deploys the NGINX ingress controller on all schedulable nodes.
> **Note:** As of v0.1.8, only workers are considered schedulable nodes, but prior to v0.1.8, worker and controlplane nodes were considered schedulable nodes.
> **Note:** As of v0.1.8, only workers are considered schedulable nodes, but before v0.1.8, worker and controlplane nodes were considered schedulable nodes.
RKE will deploy the ingress controller as a DaemonSet with `hostnetwork: true`, so ports `80`, and `443` will be opened on each node where the controller is deployed.
content/rke/latest/en/config-options/add-ons/user-defined-add-ons/_index.md
+1 -1
View File
@@ -18,7 +18,7 @@ RKE only adds additional add-ons when using `rke up` multiple times. RKE does **
As of v0.1.8, RKE will update an add-on if it is the same name.
Prior to v0.1.8, update any add-ons by using `kubectl edit`.
Before v0.1.8, update any add-ons by using `kubectl edit`.
## In-line Add-ons
content/rke/latest/en/config-options/cloud-providers/vsphere/enabling-uuid/_index.md
+1 -1
View File
@@ -32,4 +32,4 @@ $ govc vm.change -vm <vm-path> -e disk.enableUUID=TRUE
In Rancher v2.0.4+, disk UUIDs are enabled in vSphere node templates by default.
If you are using Rancher prior to v2.0.4, refer to the [vSphere node template documentation.]({{<baseurl>}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/vsphere-node-template-config/prior-to-2.0.4/#disk-uuids) for details on how to enable a UUID with a Rancher node template.
If you are using Rancher before v2.0.4, refer to the [vSphere node template documentation.]({{<baseurl>}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/vsphere-node-template-config/before-2.0.4/#disk-uuids) for details on how to enable a UUID with a Rancher node template.
content/rke/latest/en/config-options/nodes/_index.md
+1 -1
View File
@@ -78,7 +78,7 @@ nodes:
You can specify the list of roles that you want the node to be as part of the Kubernetes cluster. Three roles are supported: `controlplane`, `etcd` and `worker`. Node roles are not mutually exclusive. It's possible to assign any combination of roles to any node. It's also possible to change a node's role using the upgrade process.
> **Note:** Prior to v0.1.8, workloads/pods might have run on any nodes with `worker` or `controlplane` roles, but as of v0.1.8, they will only be deployed to any `worker` nodes.
> **Note:** Before v0.1.8, workloads/pods might have run on any nodes with `worker` or `controlplane` roles, but as of v0.1.8, they will only be deployed to any `worker` nodes.
### etcd
content/rke/latest/en/config-options/private-registries/_index.md
+1 -1
View File
@@ -35,5 +35,5 @@ By default, all system images are being pulled from DockerHub. If you are on a s
As of v0.1.10, you have to configure your private registry credentials, but you can specify this registry as a default registry so that all [system images]({{<baseurl>}}/rke/latest/en/config-options/system-images/) are pulled from the designated private registry. You can use the command `rke config --system-images` to get the list of default system images to populate your private registry.
Prior to v0.1.10, you had to configure your private registry credentials **and** update the names of all the [system images]({{<baseurl>}}/rke/latest/en/config-options/system-images/) in the `cluster.yml` so that the image names would have the private registry URL appended before each image name.
Before v0.1.10, you had to configure your private registry credentials **and** update the names of all the [system images]({{<baseurl>}}/rke/latest/en/config-options/system-images/) in the `cluster.yml` so that the image names would have the private registry URL appended before each image name.
content/rke/latest/en/config-options/services/services-extras/_index.md
+2 -2
View File
@@ -11,13 +11,13 @@ For any of the Kubernetes services, you can update the `extra_args` to change th
As of `v0.1.3`, using `extra_args` will add new arguments and **override** any existing defaults. For example, if you need to modify the default admission plugins list, you need to include the default list and edit it with your changes so all changes are included.
Prior to `v0.1.3`, using `extra_args` would only add new arguments to the list and there was no ability to change the default list.
Before `v0.1.3`, using `extra_args` would only add new arguments to the list and there was no ability to change the default list.
All service defaults and parameters are defined per [`kubernetes_version`]({{<baseurl>}}/rke/latest/en/config-options/#kubernetes-version):
- For RKE v0.3.0+, the service defaults and parameters are defined per [`kubernetes_version`]({{<baseurl>}}/rke/latest/en/config-options/#kubernetes-version). The service defaults are located [here](https://github.com/rancher/kontainer-driver-metadata/blob/master/rke/k8s_service_options.go). The default list of admissions plugins is the same for all Kubernetes versions and is located [here](https://github.com/rancher/kontainer-driver-metadata/blob/master/rke/k8s_service_options.go#L11).
- For RKE prior to v0.3.0, the service defaults and admission plugins are defined per [`kubernetes_version`]({{<baseurl>}}/rke/latest/en/config-options/#kubernetes-version) and located [here](https://github.com/rancher/types/blob/release/v2.2/apis/management.cattle.io/v3/k8s_defaults.go).
- For RKE before v0.3.0, the service defaults and admission plugins are defined per [`kubernetes_version`]({{<baseurl>}}/rke/latest/en/config-options/#kubernetes-version) and located [here](https://github.com/rancher/types/blob/release/v2.2/apis/management.cattle.io/v3/k8s_defaults.go).
```yaml
services:
content/rke/latest/en/config-options/system-images/_index.md
+1 -1
View File
@@ -63,7 +63,7 @@ system_images:
metrics_server: rancher/metrics-server-amd64:v0.3.1
```
Prior to `v0.1.6`, instead of using the `rancher/rke-tools` image, we used the following images:
Before `v0.1.6`, instead of using the `rancher/rke-tools` image, we used the following images:
```yaml
system_images:
content/rke/latest/en/etcd-snapshots/example-scenarios/_index.md
+17 -17
View File
@@ -100,18 +100,18 @@ nginx-65899c769f-qkhml 1/1 Running 0 17s
```
{{% /tab %}}
{{% tab "RKE prior to v0.2.0" %}}
{{% tab "RKE before v0.2.0" %}}
This walkthrough will demonstrate how to restore an etcd cluster from a local snapshot with the following steps:
1. [Take a local snapshot of the cluster](#take-a-local-snapshot-of-the-cluster-rke-prior-to-v0.2.0)
1. [Store the snapshot externally](#store-the-snapshot-externally-rke-prior-to-v0.2.0)
1. [Simulate a node failure](#simulate-a-node-failure-rke-prior-to-v0.2.0)
1. [Remove the Kubernetes cluster and clean the nodes](#remove-the-kubernetes-cluster-and-clean-the-nodes-rke-prior-to-v0.2.0)
1. [Retrieve the backup and place it on a new node](#retrieve-the-backup-and-place-it-on-a-new-node-rke-prior-to-v0.2.0)
1. [Add a new etcd node to the Kubernetes cluster](#add-a-new-etcd-node-to-the-kubernetes-cluster-rke-prior-to-v0.2.0)
1. [Restore etcd on the new node from the backup](#restore-etcd-on-the-new-node-from-the-backup-rke-prior-to-v0.2.0)
1. [Restore Operations on the Cluster](#restore-operations-on-the-cluster-rke-prior-to-v0.2.0)
1. [Take a local snapshot of the cluster](#take-a-local-snapshot-of-the-cluster-rke-before-v0.2.0)
1. [Store the snapshot externally](#store-the-snapshot-externally-rke-before-v0.2.0)
1. [Simulate a node failure](#simulate-a-node-failure-rke-before-v0.2.0)
1. [Remove the Kubernetes cluster and clean the nodes](#remove-the-kubernetes-cluster-and-clean-the-nodes-rke-before-v0.2.0)
1. [Retrieve the backup and place it on a new node](#retrieve-the-backup-and-place-it-on-a-new-node-rke-before-v0.2.0)
1. [Add a new etcd node to the Kubernetes cluster](#add-a-new-etcd-node-to-the-kubernetes-cluster-rke-before-v0.2.0)
1. [Restore etcd on the new node from the backup](#restore-etcd-on-the-new-node-from-the-backup-rke-before-v0.2.0)
1. [Restore Operations on the Cluster](#restore-operations-on-the-cluster-rke-before-v0.2.0)
### Example Scenario of restoring from a Local Snapshot
@@ -122,7 +122,7 @@ In this example, the Kubernetes cluster was deployed on two AWS nodes.
| node1 | 10.0.0.1 | [controlplane, worker] |
| node2 | 10.0.0.2 | [etcd] |
<a id="take-a-local-snapshot-of-the-cluster-rke-prior-to-v0.2.0"></a>
<a id="take-a-local-snapshot-of-the-cluster-rke-before-v0.2.0"></a>
### 1. Take a Local Snapshot of the Cluster
Back up the Kubernetes cluster by taking a local snapshot:
@@ -131,7 +131,7 @@ Back up the Kubernetes cluster by taking a local snapshot:
$ rke etcd snapshot-save --name snapshot.db --config cluster.yml
```
<a id="store-the-snapshot-externally-rke-prior-to-v0.2.0"></a>
<a id="store-the-snapshot-externally-rke-before-v0.2.0"></a>
### 2. Store the Snapshot Externally
After taking the etcd snapshot on `node2`, we recommend saving this backup in a persistent place. One of the options is to save the backup and `pki.bundle.tar.gz` file on an S3 bucket or tape backup.
@@ -145,7 +145,7 @@ root@node2:~# s3cmd \
s3://rke-etcd-backup/
```
<a id="simulate-a-node-failure-rke-prior-to-v0.2.0"></a>
<a id="simulate-a-node-failure-rke-before-v0.2.0"></a>
### 3. Simulate a Node Failure
To simulate the failure, let's power down `node2`.
@@ -159,7 +159,7 @@ root@node2:~# poweroff
| node1 | 10.0.0.1 | [controlplane, worker] |
| ~~node2~~ | ~~10.0.0.2~~ | ~~[etcd]~~ |
<a id="remove-the-kubernetes-cluster-and-clean-the-nodes-rke-prior-to-v0.2.0"></a>
<a id="remove-the-kubernetes-cluster-and-clean-the-nodes-rke-before-v0.2.0"></a>
### 4. Remove the Kubernetes Cluster and Clean the Nodes
The following command removes your cluster and cleans the nodes so that the cluster can be restored without any conflicts:
@@ -168,7 +168,7 @@ The following command removes your cluster and cleans the nodes so that the clus
rke remove --config rancher-cluster.yml
```
<a id="retrieve-the-backup-and-place-it-on-a-new-node-rke-prior-to-v0.2.0"></a>
<a id="retrieve-the-backup-and-place-it-on-a-new-node-rke-before-v0.2.0"></a>
### 5. Retrieve the Backup and Place it On a New Node
Before restoring etcd and running `rke up`, we need to retrieve the backup saved on S3 to a new node, e.g. `node3`.
@@ -190,7 +190,7 @@ root@node3:~# s3cmd get \
> **Note:** If you had multiple etcd nodes, you would have to manually sync the snapshot and `pki.bundle.tar.gz` across all of the etcd nodes in the cluster.
<a id="add-a-new-etcd-node-to-the-kubernetes-cluster-rke-prior-to-v0.2.0"></a>
<a id="add-a-new-etcd-node-to-the-kubernetes-cluster-rke-before-v0.2.0"></a>
### 6. Add a New etcd Node to the Kubernetes Cluster
Before updating and restoring etcd, you will need to add the new node into the Kubernetes cluster with the `etcd` role. In the `cluster.yml`, comment out the old node and add in the new node. `
@@ -215,7 +215,7 @@ nodes:
- etcd
```
<a id="restore-etcd-on-the-new-node-from-the-backup-rke-prior-to-v0.2.0"></a>
<a id="restore-etcd-on-the-new-node-from-the-backup-rke-before-v0.2.0"></a>
### 7. Restore etcd on the New Node from the Backup
After the new node is added to the `cluster.yml`, run the `rke etcd snapshot-restore` command to launch `etcd` from the backup:
@@ -226,7 +226,7 @@ $ rke etcd snapshot-restore --name snapshot.db --config cluster.yml
The snapshot and `pki.bundle.tar.gz` file are expected to be saved at `/opt/rke/etcd-snapshots` on each etcd node.
<a id="restore-operations-on-the-cluster-rke-prior-to-v0.2.0"></a>
<a id="restore-operations-on-the-cluster-rke-before-v0.2.0"></a>
### 8. Restore Operations on the Cluster
Finally, we need to restore the operations on the cluster. We will make the Kubernetes API point to the new `etcd` by running `rke up` again using the new `cluster.yml`.
content/rke/latest/en/etcd-snapshots/one-time-snapshots/_index.md
+1 -1
View File
@@ -94,7 +94,7 @@ Below is an [example IAM policy](https://docs.aws.amazon.com/IAM/latest/UserGuid
For details on giving an application access to S3, refer to the AWS documentation on [Using an IAM Role to Grant Permissions to Applications Running on Amazon EC2 Instances.](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html)
{{% /tab %}}
{{% tab "RKE prior to v0.2.0" %}}
{{% tab "RKE before v0.2.0" %}}
To save a snapshot of etcd from each etcd node in the cluster config file, run the `rke etcd snapshot-save` command.
content/rke/latest/en/etcd-snapshots/recurring-snapshots/_index.md
+4 -4
View File
@@ -30,8 +30,8 @@ time="2018-05-04T18:43:16Z" level=info msg="Created backup" name="2018-05-04T18:
|Option|Description| S3 Specific |
|---|---| --- |
|**interval_hours**| The duration in hours between recurring backups. This supercedes the `creation` option (which was used in RKE prior to v0.2.0) and will override it if both are specified.| |
|**retention**| The number of snapshots to retain before rotation. If the retention is configured in both `etcd.retention` (time period to keep snapshots in hours), which was required in RKE prior to v0.2.0, and at `etcd.backup_config.retention` (number of snapshots), the latter will be used. | |
|**interval_hours**| The duration in hours between recurring backups. This supercedes the `creation` option (which was used in RKE before v0.2.0) and will override it if both are specified.| |
|**retention**| The number of snapshots to retain before rotation. If the retention is configured in both `etcd.retention` (time period to keep snapshots in hours), which was required in RKE before v0.2.0, and at `etcd.backup_config.retention` (number of snapshots), the latter will be used. | |
|**bucket_name**| S3 bucket name where backups will be stored| * |
|**folder**| Folder inside S3 bucket where backups will be stored. This is optional. _Available as of v0.3.0_ | * |
|**access_key**| S3 access key with permission to access the backup bucket.| * |
@@ -96,11 +96,11 @@ services:
```
{{% /tab %}}
{{% tab "RKE prior to v0.2.0"%}}
{{% tab "RKE before v0.2.0"%}}
To schedule automatic recurring etcd snapshots, you can enable the `etcd-snapshot` service with [extra configuration options](#options-for-the-local-etcd-snapshot-service). `etcd-snapshot` runs in a service container alongside the `etcd` container. By default, the `etcd-snapshot` service takes a snapshot for every node that has the `etcd` role and stores them to local disk in `/opt/rke/etcd-snapshots`.
RKE saves a backup of the certificates, i.e. a file named `pki.bundle.tar.gz`, in the same location. The snapshot and pki bundle file are required for the restore process in versions prior to v0.2.0.
RKE saves a backup of the certificates, i.e. a file named `pki.bundle.tar.gz`, in the same location. The snapshot and pki bundle file are required for the restore process in versions before v0.2.0.
### Snapshot Service Logging
content/rke/latest/en/etcd-snapshots/restoring-from-backup/_index.md
+1 -1
View File
@@ -74,7 +74,7 @@ $ rke etcd snapshot-restore \
| `--ignore-docker-version` | [Disable Docker version check]({{<baseurl>}}/rke/latest/en/config-options/#supported-docker-versions) |
{{% /tab %}}
{{% tab "RKE prior to v0.2.0"%}}
{{% tab "RKE before v0.2.0"%}}
If there is a disaster with your Kubernetes cluster, you can use `rke etcd snapshot-restore` to recover your etcd. This command reverts etcd to a specific snapshot and should be run on an etcd node of the the specific cluster that has suffered the disaster.
content/rke/latest/en/installation/_index.md
+1 -1
View File
@@ -178,7 +178,7 @@ The Kubernetes cluster state, which consists of the cluster configuration file `
As of v0.2.0, RKE creates a `.rkestate` file in the same directory that has the cluster configuration file `cluster.yml`. The `.rkestate` file contains the current state of the cluster including the RKE configuration and the certificates. It is required to keep this file in order to update the cluster or perform any operation on it through RKE.
Prior to v0.2.0, RKE saved the Kubernetes cluster state as a secret. When updating the state, RKE pulls the secret, updates/changes the state and saves a new secret.
Before v0.2.0, RKE saved the Kubernetes cluster state as a secret. When updating the state, RKE pulls the secret, updates/changes the state and saves a new secret.
## Interacting with your Kubernetes cluster
content/rke/latest/en/upgrades/_index.md
+3 -3
View File
@@ -46,7 +46,7 @@ This file is created in the same directory that has the cluster configuration fi
It is required to keep the `cluster.rkestate` file to perform any operation on the cluster through RKE, or when upgrading a cluster last managed via RKE v0.2.0 or later.
{{% /tab %}}
{{% tab "RKE prior to v0.2.0" %}}
{{% tab "RKE before v0.2.0" %}}
Ensure that the `kube_config_cluster.yml` file is present in the working directory.
RKE saves the Kubernetes cluster state as a secret. When updating the state, RKE pulls the secret, updates or changes the state, and saves a new secret. The `kube_config_cluster.yml` file is required for upgrading a cluster last managed via RKE v0.1.x.
@@ -103,7 +103,7 @@ In addition, if neither `kubernetes_version` nor `system_images` are configured
As of v0.2.0, if a version is defined in `kubernetes_version` and is not found in the specific list of supported Kubernetes versions, then RKE will error out.
Prior to v0.2.0, if a version is defined in `kubernetes_version` and is not found in the specific list of supported Kubernetes versions, the default version from the supported list is used.
Before v0.2.0, if a version is defined in `kubernetes_version` and is not found in the specific list of supported Kubernetes versions, the default version from the supported list is used.
If you want to use a different version from the supported list, please use the [system images]({{<baseurl>}}/rke/latest/en/config-options/system-images/) option.
@@ -113,7 +113,7 @@ In RKE, `kubernetes_version` is used to map the version of Kubernetes to the def
For RKE v0.3.0+, the service defaults are located [here](https://github.com/rancher/kontainer-driver-metadata/blob/master/rke/k8s_service_options.go).
For RKE prior to v0.3.0, the service defaults are located [here](https://github.com/rancher/types/blob/release/v2.2/apis/management.cattle.io/v3/k8s_defaults.go). Note: The version in the path of the service defaults file corresponds to a Rancher version. Therefore, for Rancher v2.1.x, [this file](https://github.com/rancher/types/blob/release/v2.1/apis/management.cattle.io/v3/k8s_defaults.go) should be used.
For RKE before v0.3.0, the service defaults are located [here](https://github.com/rancher/types/blob/release/v2.2/apis/management.cattle.io/v3/k8s_defaults.go). Note: The version in the path of the service defaults file corresponds to a Rancher version. Therefore, for Rancher v2.1.x, [this file](https://github.com/rancher/types/blob/release/v2.1/apis/management.cattle.io/v3/k8s_defaults.go) should be used.
### Service Upgrades
content/rke/latest/en/upgrades/how-upgrades-work/_index.md
+1 -1
View File
@@ -65,7 +65,7 @@ For more information on configuring the number of replicas for each addon, refer
For an example showing how to configure the addons, refer to the [example cluster.yml.]({{<baseurl>}}/rke/latest/en/upgrades/configuring-strategy/#example-cluster-yml)
{{% /tab %}}
{{% tab "RKE prior to v1.1.0" %}}
{{% tab "RKE before v1.1.0" %}}
When a cluster is upgraded with `rke up`, using the default options, the following process is used: