mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-26 04:58:07 +00:00
Merge pull request #949 from rancher/staging
bringing changes from staging to master
This commit is contained in:
Denise
@@ -0,0 +1,51 @@
|
||||
---
|
||||
title: Rancher Agent Options
|
||||
weight: 1140
|
||||
---
|
||||
|
||||
Rancher deploys an agent on each node to communicate with the node. This pages describes the options that can be passed to the agent. To use these options, you will need to [Create a Cluster with Custom Nodes]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/) and add the options to the generated `docker run` command when adding a node.
|
||||
|
||||
## General options
|
||||
|
||||
| Parameter | Environment variable | Description |
|
||||
| ---------- | -------------------- | ----------- |
|
||||
| `--server` | `CATTLE_SERVER` | The configured Rancher `server-url` setting which the agent connects to |
|
||||
| `--token` | `CATTLE_TOKEN` | Token that is needed to register the node in Rancher |
|
||||
| `--ca-checksum` | `CATTLE_CA_CHECKSUM` | The SHA256 checksum of the configured Rancher `cacerts` setting to validate |
|
||||
| `--node-name` | `CATTLE_NODE_NAME` | Override the hostname that is used to register the node (defaults to `hostname -s`) |
|
||||
| `--label` | `CATTLE_NODE_LABEL` | Add node labels to the node (`--label key=value`) |
|
||||
|
||||
## Role options
|
||||
|
||||
| Parameter | Environment variable | Description |
|
||||
| ---------- | -------------------- | ----------- |
|
||||
| `--all-roles` | `ALL=true` | Apply all roles (`etcd`,`controlplane`,`worker`) to the node |
|
||||
| `--etcd` | `ETCD=true` | Apply the role `etcd` to the node |
|
||||
| `--controlplane` | `CONTROL=true` | Apply the role `controlplane` to the node |
|
||||
| `--worker` | `WORKER=true` | Apply the role `worker` to the node |
|
||||
|
||||
## IP address options
|
||||
|
||||
| Parameter | Environment variable | Description |
|
||||
| ---------- | -------------------- | ----------- |
|
||||
| `--address` | `CATTLE_ADDRESS` | The IP address the node will be registered with (defaults to the IP used to reach `8.8.8.8` |
|
||||
| `--internal-address` | `CATTLE_INTERNAL_ADDRESS` | The IP address used for inter-host communication on a private network |
|
||||
|
||||
### Dynamic IP address options
|
||||
|
||||
For automation purposes, you can't have a specific IP address in a command as it has to be generic to be used for every node. For this, we have dynamic IP address options. They are used as a value to the existing [IP address options](#ip-address-options). This is supported for `--address` and `--internal-address`.
|
||||
|
||||
| Value | Example | Description |
|
||||
| ---------- | -------------------- | ----------- |
|
||||
| Interface name | `--address eth0` | The first configured IP address will be retrieved from the given interface |
|
||||
| `ipify` | `--address ipify` | Value retrieved from `https://api.ipify.org` will be used |
|
||||
| `awslocal` | `--address awslocal` | Value retrieved from `http://169.254.169.254/latest/meta-data/local-ipv4` will be used |
|
||||
| `awspublic` | `--address awspublic` | Value retrieved from `http://169.254.169.254/latest/meta-data/public-ipv4` will be used |
|
||||
| `doprivate` | `--address doprivate` | Value retrieved from `http://169.254.169.254/metadata/v1/interfaces/private/0/ipv4/address` will be used |
|
||||
| `dopublic` | `--address dopublic` | Value retrieved from `http://169.254.169.254/metadata/v1/interfaces/public/0/ipv4/address` will be used |
|
||||
| `azprivate` | `--address azprivate` | Value retrieved from `http://169.254.169.254/metadata/instance/network/interface/0/ipv4/ipAddress/0/privateIpAddress?api-version=2017-08-01&format=text` will be used |
|
||||
| `azpublic` | `--address azpublic` | Value retrieved from `http://169.254.169.254/metadata/instance/network/interface/0/ipv4/ipAddress/0/publicIpAddress?api-version=2017-08-01&format=text` will be used |
|
||||
| `gceinternal` | `--address gceinternal` | Value retrieved from `http://metadata.google.internal/computeMetadata/v1/instance/network-interfaces/0/ip` will be used |
|
||||
| `gceexternal` | `--address gceexternal` | Value retrieved from `http://metadata.google.internal/computeMetadata/v1/instance/network-interfaces/0/access-configs/0/external-ip` will be used |
|
||||
| `packetlocal` | `--address packetlocal` | Value retrieved from `https://metadata.packet.net/2009-04-04/meta-data/local-ipv4` will be used |
|
||||
| `packetpublic` | `--address packetlocal` | Value retrieved from `https://metadata.packet.net/2009-04-04/meta-data/public-ipv4` will be used |
|
||||
@@ -72,8 +72,9 @@ Use {{< product >}} to clone your Linux host and configure them as Kubernetes no
|
||||
>- Using Windows nodes as Kubernetes workers? See [Node Configuration]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/windows-clusters/#node-configuration).
|
||||
>- Bare-Metal Server Reminder: If you plan on dedicating bare-metal servers to each role, you must provision a bare-metal server for each role (i.e. provision multiple bare-metal servers).
|
||||
|
||||
8. <a id="step-8"></a>**Optional**: Add **Labels** to your cluster nodes to help schedule workloads later.
|
||||
8. <a id="step-8"></a>**Optional**: Click **Show advanced options** to specify IP address(es) to use when registering the node, override the hostname of the node or to add labels to the node.
|
||||
|
||||
[Rancher Agent Options]({{< baseurl >}}/rancher/v2.x/en/admin-settings/agent-options/)<br/>
|
||||
[Kubernetes Documentation: Labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)
|
||||
|
||||
9. Copy the command displayed on screen to your clipboard.
|
||||
|
||||
@@ -9,6 +9,10 @@ You can access and manage your Kubernetes clusters using kubectl in two ways:
|
||||
- [Accessing Clusters with kubectl Shell](#accessing-clusters-with-kubectl-shell)
|
||||
- [Accessing Clusters with kubectl CLI and a kubeconfig File]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/kubeconfig/)
|
||||
|
||||
## Resources created using kubectl
|
||||
|
||||
Rancher will discover and show resources created by `kubectl`. However, these resources might not have all the necessary annotations on discovery. If an operation (for instance, scaling the workload) is done to the resource using the Rancher UI/API, this may trigger recreation of the resources due to the missing annotations. This should only happen the first time an operation is done to the discovered resource.
|
||||
|
||||
## Accessing Clusters with kubectl Shell
|
||||
|
||||
You can access and manage your clusters by logging into Rancher and opening the kubectl shell. No further configuration necessary.
|
||||
|
||||
@@ -24,6 +24,9 @@ The following instructions will guide you through upgrading a high-availability
|
||||
|
||||
[Install or update](https://docs.helm.sh/using_helm/#installing-helm) Helm to the latest version.
|
||||
|
||||
- **Upgrades to v2.0.7+ only: check system namespace locations**
|
||||
Starting in v2.0.7, Rancher introduced the `system` project, which is a project that's automatically created to store important namespaces that Kubernetes needs to operate. During upgrade to v2.0.7+, Rancher expects these namespaces to be unassigned from all projects. Before beginning upgrade, check your system namespaces to make sure that they're unassigned to [prevent cluster networking issues]({{< baseurl >}}/rancher/v2.x/en/upgrades/upgrades/namespace-migration/#preventing-cluster-networking-issues).
|
||||
|
||||
## Upgrade Rancher
|
||||
|
||||
1. Update your local helm repo cache.
|
||||
@@ -37,7 +40,7 @@ The following instructions will guide you through upgrading a high-availability
|
||||
```
|
||||
helm repo list
|
||||
|
||||
NAME URL
|
||||
NAME URL
|
||||
stable https://kubernetes-charts.storage.googleapis.com
|
||||
rancher-<CHART_REPO> https://releases.rancher.com/server-charts/<CHART_REPO>
|
||||
```
|
||||
@@ -73,6 +76,12 @@ The following instructions will guide you through upgrading a high-availability
|
||||
kubectl -n cattle-system apply -R -f ./rancher
|
||||
```
|
||||
|
||||
**Result:** Rancher is upgraded. Log back into Rancher to confirm that the upgrade succeeded.
|
||||
|
||||
>**Having Network Issues Following Upgrade?**
|
||||
>
|
||||
> See [Restoring Cluster Networking]({{< baseurl >}}/rancher/v2.x/en/upgrades/upgrades/namespace-migration/#restoring-cluster-networking).
|
||||
|
||||
## Rolling Back
|
||||
|
||||
Should something go wrong, follow the [HA Rollback]({{< baseurl >}}/rancher/v2.x/en/upgrades/rollbacks/ha-server-rollbacks/) instructions to restore the snapshot you took before you preformed the upgrade.
|
||||
|
||||
@@ -34,6 +34,9 @@ The following instructions will guide you through upgrading a high-availability
|
||||
```
|
||||
helm init --upgrade --service-account tiller
|
||||
```
|
||||
- **Upgrades to v2.0.7+ only: check system namespace locations**
|
||||
Starting in v2.0.7, Rancher introduced the `System` project, which is a project that's automatically created to store important namespaces that Kubernetes needs to operate. During upgrade to v2.0.7+, Rancher expects these namespaces to be unassigned from all projects. Before beginning upgrade, check your system namespaces to make sure that they're unassigned to [prevent cluster networking issues]({{< baseurl >}}/rancher/v2.x/en/upgrades/upgrades/namespace-migration/#preventing-cluster-networking-issues).
|
||||
|
||||
## Upgrade Rancher
|
||||
|
||||
> **Note:** For Air Gap installs see [Upgrading HA Rancher - Air Gap]({{< baseurl >}}/rancher/v2.x/en/installation/air-gap-installation/install-rancher/#upgrading-rancher)
|
||||
@@ -49,7 +52,7 @@ The following instructions will guide you through upgrading a high-availability
|
||||
```
|
||||
helm repo list
|
||||
|
||||
NAME URL
|
||||
NAME URL
|
||||
stable https://kubernetes-charts.storage.googleapis.com
|
||||
rancher-<CHART_REPO> https://releases.rancher.com/server-charts/<CHART_REPO>
|
||||
```
|
||||
@@ -75,6 +78,12 @@ The following instructions will guide you through upgrading a high-availability
|
||||
helm upgrade rancher rancher-<CHART_REPO>/rancher --set hostname=rancher.my.org
|
||||
```
|
||||
|
||||
**Result:** Rancher is upgraded. Log back into Rancher to confirm that the upgrade succeeded.
|
||||
|
||||
>**Having Network Issues Following Upgrade?**
|
||||
>
|
||||
> See [Restoring Cluster Networking]({{< baseurl >}}/rancher/v2.x/en/upgrades/upgrades/namespace-migration/#restoring-cluster-networking).
|
||||
|
||||
## Rolling Back
|
||||
|
||||
Should something go wrong, follow the [HA Rollback]({{< baseurl >}}/rancher/v2.x/en/upgrades/rollbacks/ha-server-rollbacks/) instructions to restore the snapshot you took before you preformed the upgrade.
|
||||
|
||||
@@ -0,0 +1,157 @@
|
||||
---
|
||||
title: Upgrading to v2.0.7+ — Namespace Migration
|
||||
weight:
|
||||
aliases:
|
||||
---
|
||||
>This section applies only to Rancher upgrades from v2.0.6 or earlier to v2.0.7 or later. Upgrades from v2.0.7 to later version are unaffected.
|
||||
|
||||
In Rancher v2.0.6 and prior, system namespaces crucial for Rancher and Kubernetes operations were not assigned to any Rancher project by default. Instead, these namespaces existed independently from all Rancher projects, but you could move these namespaces into any project without affecting cluster operations.
|
||||
|
||||
These namespaces include:
|
||||
|
||||
- `kube-system`
|
||||
- `kube-public`
|
||||
- `cattle-system`
|
||||
- `cattle-alerting`<sup>1</sup>
|
||||
- `cattle-logging`<sup>1</sup>
|
||||
- `cattle-pipeline`<sup>1</sup>
|
||||
- `ingress-nginx`
|
||||
|
||||
><sup>1</sup> Only displays if this feature is enabled for the cluster.
|
||||
|
||||
However, with the release of Rancher v2.0.7, the `System` project was introduced. This project, which is automatically created during the upgrade, is assigned the system namespaces above to hold these crucial components for safe keeping.
|
||||
|
||||
During upgrades from Rancher v2.0.6- to Rancher v2.0.7+, all system namespaces are moved from their default location outside of all projects into the newly created `System` project. However, if you assigned any of your system namespaces to a project before upgrading, your cluster networking may encounter issues afterwards. This issue occurs because the system namespaces are not where the upgrade expects them to be during the upgrade, so it cannot move them to the `System` project.
|
||||
|
||||
- To prevent this issue from occurring before the upgrade, see [Preventing Cluster Networking Issues](#preventing-cluster-networking-issues).
|
||||
- To fix this issue following upgrade, see [Restoring Cluster Networking](#restoring-cluster-networking).
|
||||
|
||||
## Preventing Cluster Networking Issues
|
||||
|
||||
You can prevent cluster networking issues from occurring during your upgrade to v2.0.7+ by unassigning system namespaces from all of your Rancher projects. Complete this task if you've assigned any of a cluster's system namespaces into a Rancher project.
|
||||
|
||||
1. Log into the Rancher UI prior to upgrade.
|
||||
|
||||
1. From the context menu, open the **local** cluster (or any of your other clusters).
|
||||
|
||||
1. From the main menu, select **Project/Namespaces**.
|
||||
|
||||
1. Find and select the following namespaces. Click **Move** and then choose **None** to move them out of your projects. Click **Move** again.
|
||||
|
||||
>**Note:** Some or all of these namespaces may already be unassigned from all projects.
|
||||
|
||||
- `kube-system`
|
||||
- `kube-public`
|
||||
- `cattle-system`
|
||||
- `cattle-alerting`<sup>1</sup>
|
||||
- `cattle-logging`<sup>1</sup>
|
||||
- `cattle-pipeline`<sup>1</sup>
|
||||
- `ingress-nginx`
|
||||
|
||||
><sup>1</sup> Only displays if this feature is enabled for the cluster.
|
||||
|
||||
<figcaption>Moving namespaces out of projects</figcaption>
|
||||
|
||||
|
||||
1. Repeat these steps for each cluster where you've assigned system namespaces to projects.
|
||||
|
||||
**Result:** All system namespaces are moved out of Rancher projects. You can now safely begin the [upgrade]({{< baseurl >}}/rancher/v2.x/en/upgrades/upgrades).
|
||||
|
||||
## Restoring Cluster Networking
|
||||
|
||||
Reset the cluster nodes' network policies to restore connectivity.
|
||||
|
||||
>**Prerequisites:**
|
||||
>
|
||||
>Download and setup [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/).
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "HA Install" %}}
|
||||
1. From **Terminal**, change directories to your kubectl file that's generated during Rancher install, `kube_config_rancher-cluster.yml`. This file is usually in the directory where you ran RKE during Rancher installation.
|
||||
|
||||
1. Before repairing networking, run the following two commands to make sure that your nodes have a status of `Ready` and that your cluster components are `Healthy`.
|
||||
|
||||
```
|
||||
kubectl get nodes --kubeconfig kube_config_rancher-cluster.yml
|
||||
|
||||
NAME STATUS ROLES AGE VERSION
|
||||
165.227.114.63 Ready controlplane,etcd,worker 11m v1.10.1
|
||||
165.227.116.167 Ready controlplane,etcd,worker 11m v1.10.1
|
||||
165.227.127.226 Ready controlplane,etcd,worker 11m v1.10.1
|
||||
|
||||
kubectl get cs --kubeconfig kube_config_rancher-cluster.yml
|
||||
|
||||
NAME STATUS MESSAGE ERROR
|
||||
scheduler Healthy ok
|
||||
controller-manager Healthy ok
|
||||
etcd-0 Healthy {"health": "true"}
|
||||
etcd-2 Healthy {"health": "true"}
|
||||
etcd-1 Healthy {"health": "true"}
|
||||
```
|
||||
|
||||
1. Check the `networkPolicy` for all clusters by running the following command.
|
||||
|
||||
kubectl --kubeconfig kube_config_rancher-cluster.yml get cluster -o=custom-columns=ID:.metadata.name,NAME:.spec.displayName,NETWORKPOLICY:.spec.enableNetworkPolicy
|
||||
|
||||
ID NAME NETWORKPOLICY
|
||||
c-59ptz custom <nil>
|
||||
local local <nil>
|
||||
|
||||
|
||||
1. Disable the `networkPolicy` for all clusters, still pointing toward your `kube_config_rancher-cluster.yml`.
|
||||
|
||||
kubectl --kubeconfig kube_config_rancher-cluster.yml get cluster -o jsonpath='{range .items[*]}{@.metadata.name}{"\n"}{end}' | xargs -I {} kubectl --kubeconfig kube_config_rancher-cluster.yml patch cluster {} --type merge -p '{"spec": {"enableNetworkPolicy": false}}'
|
||||
|
||||
>**Tip:** If you want to keep `networkPolicy` enabled for all created clusters, you can run the following command to disable `networkPolicy` for `local` cluster (i.e., your Rancher Server nodes):
|
||||
>
|
||||
>```
|
||||
kubectl --kubeconfig kube_config_rancher-cluster.yml patch cluster local --type merge -p '{"spec": {"enableNetworkPolicy": false}}'
|
||||
```
|
||||
|
||||
1. Check the `networkPolicy` for all clusters again to make sure the policies have a status of `false `.
|
||||
|
||||
kubectl --kubeconfig kube_config_rancher-cluster.yml get cluster -o=custom-columns=ID:.metadata.name,NAME:.spec.displayName,NETWORKPOLICY:.spec.enableNetworkPolicy
|
||||
|
||||
ID NAME NETWORKPOLICY
|
||||
c-59ptz custom false
|
||||
local local false
|
||||
|
||||
1. Now remove all network policies from system namespaces. Run this command for each cluster, using the kubeconfig generated by RKE.
|
||||
|
||||
```
|
||||
for namespace in kube-system kube-public cattle-system cattle-alerting cattle-logging cattle-pipeline ingress-nginx; do
|
||||
kubectl --kubeconfig kube_config_rancher-cluster.yml -n $namespace delete networkpolicy --all;
|
||||
done
|
||||
```
|
||||
|
||||
1. Wait a few minutes and then log into the Rancher UI.
|
||||
|
||||
- If you can access Rancher, you're done, so you can skip the rest of the steps.
|
||||
- If you still can't access Rancher, complete the steps below.
|
||||
|
||||
1. Force your pods to recreate themselves by entering the following command.
|
||||
|
||||
```
|
||||
kubectl --kubeconfig kube_config_rancher-cluster.yml delete pods -n cattle-system --all
|
||||
```
|
||||
|
||||
1. Log into the Rancher UI and view your clusters. Created clusters will show errors from attempting to contact Rancher while it was unavailable. However, these errors should resolve automatically.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher Launched Kubernetes" %}}
|
||||
<br/>
|
||||
If you can access Rancher, but one or more of the clusters that you launched using Rancher has no networking, you can repair them by moving the
|
||||
|
||||
- From the cluster's [embedded kubectl shell]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/kubectl/#accessing-clusters-with-kubectl-shell).
|
||||
- By [downloading the cluster kubeconfig file and running it]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/kubectl/#accessing-clusters-with-kubectl-and-a-kubeconfig-file) from your workstation.
|
||||
|
||||
```
|
||||
for namespace in kube-system kube-public cattle-system cattle-alerting cattle-logging cattle-pipeline ingress-nginx; do
|
||||
kubectl --kubeconfig kube_config_rancher-cluster.yml -n $namespace delete networkpolicy --all;
|
||||
done
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
|
||||
|
||||
@@ -6,6 +6,9 @@ aliases:
|
||||
---
|
||||
To upgrade an air gapped Rancher Server, update your private registry with the latest Docker images, and then run the upgrade command.
|
||||
|
||||
## Prerequisites
|
||||
**Upgrades to v2.0.7+ only:** Starting in v2.0.7, Rancher introduced the `system` project, which is a project that's automatically created to store important namespaces that Kubernetes needs to operate. During upgrade to v2.0.7+, Rancher expects these namespaces to be unassigned from all projects. Before beginning upgrade, check your system namespaces to make sure that they're unassigned to [prevent cluster networking issues]({{< baseurl >}}/rancher/v2.x/en/upgrades/upgrades/namespace-migration/#preventing-cluster-networking-issues).
|
||||
|
||||
## Upgrading An Air Gapped Rancher Server
|
||||
|
||||
1. Follow the directions in Air Gap Installation to [pull the Docker images]({{< baseurl >}}/rancher/v2.x/en/installation/air-gap-installation/#release-files) required for the new version of Rancher.
|
||||
@@ -16,3 +19,12 @@ To upgrade an air gapped Rancher Server, update your private registry with the l
|
||||
> While completing [Single Node Upgrade]({{< baseurl >}}/rancher/v2.x/en/upgrades/single-node-upgrade/), prepend your private registry URL to the image when running the `docker run` command.
|
||||
>
|
||||
> Example: `<registry.yourdomain.com:port>/rancher/rancher:latest`
|
||||
|
||||
**Result:** Rancher is upgraded. Log back into Rancher to confirm that the upgrade succeeded.
|
||||
|
||||
>**Having Network Issues Following Upgrade?**
|
||||
>
|
||||
> See [Restoring Cluster Networking]({{< baseurl >}}/rancher/v2.x/en/upgrades/upgrades/namespace-migration/#restoring-cluster-networking).
|
||||
|
||||
## Rolling Back
|
||||
If your upgrade does not complete successfully, you can roll Rancher Server and its data back to its last healthy state. For more information, see [Single Node Rollback]({{< baseurl >}}/rancher/v2.x/en/upgrades/rollbacks/single-node-rollbacks/).
|
||||
|
||||
@@ -27,11 +27,14 @@ Cross reference the image and reference table below to learn how to obtain this
|
||||
| `<RANCHER_CONTAINER_TAG>` | `v2.0.5` | The rancher/rancher image you pulled for initial install. |
|
||||
| `<RANCHER_CONTAINER_NAME>` | `festive_mestorf` | The name of your Rancher container. |
|
||||
| `<RANCHER_VERSION>` | `v2.0.5` | The version of Rancher that you're creating a backup for. |
|
||||
| `<DATE>` | `9-27-18` | The date that the data container or backup was created. |
|
||||
| `<DATE>` | `9-27-18` | The date that the data container or backup was created. |
|
||||
<br/>
|
||||
|
||||
You can obtain `<RANCHER_CONTAINER_TAG>` and `<RANCHER_CONTAINER_NAME>` by logging into your Rancher Server by remote connection and entering the command to view the containers that are running: `docker ps`. You can also view containers that are stopped using a different command: `docker ps -a`. Use these commands for help anytime during while creating backups.
|
||||
|
||||
## Prerequisites
|
||||
**Upgrades to v2.0.7+ only:** Starting in v2.0.7, Rancher introduced the `system` project, which is a project that's automatically created to store important namespaces that Kubernetes needs to operate. During upgrade to v2.0.7+, Rancher expects these namespaces to be unassigned from all projects. Before beginning upgrade, check your system namespaces to make sure that they're unassigned to [prevent cluster networking issues]({{< baseurl >}}/rancher/v2.x/en/upgrades/upgrades/namespace-migration/#preventing-cluster-networking-issues).
|
||||
|
||||
## Completing the Upgrade
|
||||
|
||||
During upgrade, you create a copy of the data from your current Rancher container and a backup in case something goes wrong. Then you deploy the new version of Rancher in a new container using your existing data.
|
||||
@@ -88,7 +91,7 @@ During upgrade, you create a copy of the data from your current Rancher containe
|
||||
docker run -d --volumes-from rancher-data --restart=unless-stopped -p 80:80 -p 443:443 rancher/rancher:latest
|
||||
```
|
||||
|
||||
>**Want records of all transactions with the Rancher API?**
|
||||
>**Want records of all transactions with the Rancher API?**
|
||||
>
|
||||
>Enable the [API Auditing]({{< baseurl >}}/rancher/v2.x/en/installation/api-auditing) feature by adding the flags below into your upgrade command.
|
||||
>```
|
||||
@@ -98,7 +101,7 @@ During upgrade, you create a copy of the data from your current Rancher containe
|
||||
-e AUDIT_LOG_MAXBACKUP=20 \
|
||||
-e AUDIT_LOG_MAXSIZE=100 \
|
||||
```
|
||||
|
||||
|
||||
>**Note:** _Do not_ stop the upgrade after initiating it, even if the upgrade process seems longer than expected. Stopping the upgrade may result in database migration errors during future upgrades.
|
||||
><br/>
|
||||
><br/>
|
||||
@@ -112,6 +115,12 @@ During upgrade, you create a copy of the data from your current Rancher containe
|
||||
|
||||
If you only stop the previous Rancher Server container (and don't remove it), the container may restart after the next server reboot.
|
||||
|
||||
**Result:** Rancher Server is upgraded to the latest version.
|
||||
**Result:** Rancher is upgraded. Log back into Rancher to confirm that the upgrade succeeded.
|
||||
|
||||
>**Note:** If your upgrade does not complete successfully, you can roll Rancher Server and its data back to its last healthy state. For more information, see [Single Node Rollback]({{< baseurl >}}/rancher/v2.x/en/upgrades/rollbacks/single-node-rollbacks/).
|
||||
>**Having Network Issues Following Upgrade?**
|
||||
>
|
||||
> See [Restoring Cluster Networking]({{< baseurl >}}/rancher/v2.x/en/upgrades/upgrades/namespace-migration/#restoring-cluster-networking).
|
||||
|
||||
## Rolling Back
|
||||
|
||||
If your upgrade does not complete successfully, you can roll Rancher Server and its data back to its last healthy state. For more information, see [Single Node Rollback]({{< baseurl >}}/rancher/v2.x/en/upgrades/rollbacks/single-node-rollbacks/).
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
<div>
|
||||
<p>Use <strong>Member Roles</strong> to configure user authorization for the cluster.</p>
|
||||
<ul>
|
||||
<li>Click <strong>Add Members</strong> to add users that can access the cluster.</li>
|
||||
<li>Click <strong>Add Member</strong> to add users that can access the cluster.</li>
|
||||
<li>Use the <strong>Role</strong> drop-down to set permissions for each user.</li>
|
||||
</ul>
|
||||
<br/>
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 23 KiB |
Reference in New Issue
Block a user