mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-25 04:28:15 +00:00
Add FAQ on adding args/binds/envvars to k8s components
This commit is contained in:
Sebastiaan van Steenis
committed by
Mark Bishop
Mark Bishop
parent
ed4f77354b
commit
9cdb5d209c
@@ -49,7 +49,7 @@ $ reboot
|
||||
|
||||
### Use RANCHER_BOOT partition
|
||||
|
||||
When you only use the RRACHER_STATE partition, the bootloader will be installed in the `/boot` directory.
|
||||
When you only use the RANCHER_STATE partition, the bootloader will be installed in the `/boot` directory.
|
||||
|
||||
```
|
||||
$ system-docker run -it --rm -v /:/host alpine
|
||||
|
||||
@@ -72,6 +72,9 @@ You need add `rancher.autologin=tty1` to the end, then press `<Enter>`. If all g
|
||||
We need to mount the root disk in the recovery console and delete some data:
|
||||
|
||||
```
|
||||
# If you couldn't see any disk devices created under `/dev/`, please try this command:
|
||||
$ ros udev-settle
|
||||
|
||||
$ mkdir /mnt/root-disk
|
||||
$ mount /dev/sda1 /mnt/root-disk
|
||||
|
||||
|
||||
@@ -35,3 +35,4 @@ weight: 303
|
||||
| [CVE-2018-8897](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-8897) | A statement in the System Programming Guide of the Intel 64 and IA-32 Architectures Software Developer's Manual (SDM) was mishandled in the development of some or all operating-system kernels, resulting in unexpected behavior for #DB exceptions that are deferred by MOV SS or POP SS, as demonstrated by (for example) privilege escalation in Windows, macOS, some Xen configurations, or FreeBSD, or a Linux kernel crash. | 31 May 2018 | [RancherOS v1.4.0](https://github.com/rancher/os/releases/tag/v1.4.0) using Linux v4.14.32 |
|
||||
| [L1 Terminal Fault](https://www.kernel.org/doc/html/latest/admin-guide/l1tf.html) | L1 Terminal Fault is a hardware vulnerability which allows unprivileged speculative access to data which is available in the Level 1 Data Cache when the page table entry controlling the virtual address, which is used for the access, has the Present bit cleared or other reserved bits set. | 19 Sep 2018 | [RancherOS v1.4.1](https://github.com/rancher/os/releases/tag/v1.4.1) using Linux v4.14.67 |
|
||||
| [CVE-2018-3639](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-3639) | Systems with microprocessors utilizing speculative execution and speculative execution of memory reads before the addresses of all prior memory writes are known may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis, aka Speculative Store Bypass (SSB), Variant 4. | 19 Sep 2018 | [RancherOS v1.4.1](https://github.com/rancher/os/releases/tag/v1.4.1) using Linux v4.14.67 |
|
||||
| [CVE-2018-17182](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-17182) | The vmacache_flush_all function in mm/vmacache.c mishandles sequence number overflows. An attacker can trigger a use-after-free (and possibly gain privileges) via certain thread creation, map, unmap, invalidation, and dereference operations. | 18 Oct 2018 | [RancherOS v1.4.2](https://github.com/rancher/os/releases/tag/v1.4.2) using Linux v4.14.73 |
|
||||
|
||||
@@ -58,22 +58,22 @@ rancher:
|
||||
|
||||
### Amazon ECS enabled AMIs
|
||||
|
||||
Latest Release: [v1.4.1](https://github.com/rancher/os/releases/tag/v1.4.1)
|
||||
Latest Release: [v1.4.2](https://github.com/rancher/os/releases/tag/v1.4.2)
|
||||
|
||||
Region | Type | AMI
|
||||
---|--- | ---
|
||||
ap-south-1 | HVM - ECS enabled | [ami-0c095bd65873104ea](https://ap-south-1.console.aws.amazon.com/ec2/home?region=ap-south-1#launchInstanceWizard:ami=ami-0c095bd65873104ea)
|
||||
eu-west-3 | HVM - ECS enabled | [ami-0a9420a7b9a46517b](https://eu-west-3.console.aws.amazon.com/ec2/home?region=eu-west-3#launchInstanceWizard:ami=ami-0a9420a7b9a46517b)
|
||||
eu-west-2 | HVM - ECS enabled | [ami-09f7882ec876661f9](https://eu-west-2.console.aws.amazon.com/ec2/home?region=eu-west-2#launchInstanceWizard:ami=ami-09f7882ec876661f9)
|
||||
eu-west-1 | HVM - ECS enabled | [ami-0dd35c5333b908688](https://eu-west-1.console.aws.amazon.com/ec2/home?region=eu-west-1#launchInstanceWizard:ami=ami-0dd35c5333b908688)
|
||||
ap-northeast-2 | HVM - ECS enabled | [ami-0272129f9db7717d1](https://ap-northeast-2.console.aws.amazon.com/ec2/home?region=ap-northeast-2#launchInstanceWizard:ami=ami-0272129f9db7717d1)
|
||||
ap-northeast-1 | HVM - ECS enabled | [ami-0cc3f7df2e7cac07a](https://ap-northeast-1.console.aws.amazon.com/ec2/home?region=ap-northeast-1#launchInstanceWizard:ami=ami-0cc3f7df2e7cac07a)
|
||||
sa-east-1 | HVM - ECS enabled | [ami-0b8bc2a235e2ba0b8](https://sa-east-1.console.aws.amazon.com/ec2/home?region=sa-east-1#launchInstanceWizard:ami=ami-0b8bc2a235e2ba0b8)
|
||||
ca-central-1 | HVM - ECS enabled | [ami-0834633a15bc44f0c](https://ca-central-1.console.aws.amazon.com/ec2/home?region=ca-central-1#launchInstanceWizard:ami=ami-0834633a15bc44f0c)
|
||||
ap-southeast-1 | HVM - ECS enabled | [ami-076072ffb77b9e9c7](https://ap-southeast-1.console.aws.amazon.com/ec2/home?region=ap-southeast-1#launchInstanceWizard:ami=ami-076072ffb77b9e9c7)
|
||||
ap-southeast-2 | HVM - ECS enabled | [ami-0b39a6595e83e016d](https://ap-southeast-2.console.aws.amazon.com/ec2/home?region=ap-southeast-2#launchInstanceWizard:ami=ami-0b39a6595e83e016d)
|
||||
eu-central-1 | HVM - ECS enabled | [ami-0a8b8e376349bd511](https://eu-central-1.console.aws.amazon.com/ec2/home?region=eu-central-1#launchInstanceWizard:ami=ami-0a8b8e376349bd511)
|
||||
us-east-1 | HVM - ECS enabled | [ami-0683608046ab95a13](https://us-east-1.console.aws.amazon.com/ec2/home?region=us-east-1#launchInstanceWizard:ami=ami-0683608046ab95a13)
|
||||
us-east-2 | HVM - ECS enabled | [ami-0d6a98791e2f98a13](https://us-east-2.console.aws.amazon.com/ec2/home?region=us-east-2#launchInstanceWizard:ami=ami-0d6a98791e2f98a13)
|
||||
us-west-1 | HVM - ECS enabled | [ami-0880d73d3ea92c89c](https://us-west-1.console.aws.amazon.com/ec2/home?region=us-west-1#launchInstanceWizard:ami=ami-0880d73d3ea92c89c)
|
||||
us-west-2 | HVM - ECS enabled | [ami-0626403624bc30288](https://us-west-2.console.aws.amazon.com/ec2/home?region=us-west-2#launchInstanceWizard:ami=ami-0626403624bc30288)
|
||||
ap-south-1 | HVM - ECS enabled | [ami-0721722dd0f0a6b54](https://ap-south-1.console.aws.amazon.com/ec2/home?region=ap-south-1#launchInstanceWizard:ami=ami-0721722dd0f0a6b54)
|
||||
eu-west-3 | HVM - ECS enabled | [ami-017eb997502d38415](https://eu-west-3.console.aws.amazon.com/ec2/home?region=eu-west-3#launchInstanceWizard:ami=ami-017eb997502d38415)
|
||||
eu-west-2 | HVM - ECS enabled | [ami-08772e5a96934e3e5](https://eu-west-2.console.aws.amazon.com/ec2/home?region=eu-west-2#launchInstanceWizard:ami=ami-08772e5a96934e3e5)
|
||||
eu-west-1 | HVM - ECS enabled | [ami-089bd570fab84ab89](https://eu-west-1.console.aws.amazon.com/ec2/home?region=eu-west-1#launchInstanceWizard:ami=ami-089bd570fab84ab89)
|
||||
ap-northeast-2 | HVM - ECS enabled | [ami-0420afe0617d4f723](https://ap-northeast-2.console.aws.amazon.com/ec2/home?region=ap-northeast-2#launchInstanceWizard:ami=ami-0420afe0617d4f723)
|
||||
ap-northeast-1 | HVM - ECS enabled | [ami-05bee9d87b6af1f5c](https://ap-northeast-1.console.aws.amazon.com/ec2/home?region=ap-northeast-1#launchInstanceWizard:ami=ami-05bee9d87b6af1f5c)
|
||||
sa-east-1 | HVM - ECS enabled | [ami-0bc2d9e3a0c98158c](https://sa-east-1.console.aws.amazon.com/ec2/home?region=sa-east-1#launchInstanceWizard:ami=ami-0bc2d9e3a0c98158c)
|
||||
ca-central-1 | HVM - ECS enabled | [ami-0c09398512d4ba6b9](https://ca-central-1.console.aws.amazon.com/ec2/home?region=ca-central-1#launchInstanceWizard:ami=ami-0c09398512d4ba6b9)
|
||||
ap-southeast-1 | HVM - ECS enabled | [ami-0ffa715a6bb9373de](https://ap-southeast-1.console.aws.amazon.com/ec2/home?region=ap-southeast-1#launchInstanceWizard:ami=ami-0ffa715a6bb9373de)
|
||||
ap-southeast-2 | HVM - ECS enabled | [ami-03cb7478f257c6490](https://ap-southeast-2.console.aws.amazon.com/ec2/home?region=ap-southeast-2#launchInstanceWizard:ami=ami-03cb7478f257c6490)
|
||||
eu-central-1 | HVM - ECS enabled | [ami-029b85c9d234c4f43](https://eu-central-1.console.aws.amazon.com/ec2/home?region=eu-central-1#launchInstanceWizard:ami=ami-029b85c9d234c4f43)
|
||||
us-east-1 | HVM - ECS enabled | [ami-0f274b6c9410c73ed](https://us-east-1.console.aws.amazon.com/ec2/home?region=us-east-1#launchInstanceWizard:ami=ami-0f274b6c9410c73ed)
|
||||
us-east-2 | HVM - ECS enabled | [ami-0cae94276614142ef](https://us-east-2.console.aws.amazon.com/ec2/home?region=us-east-2#launchInstanceWizard:ami=ami-0cae94276614142ef)
|
||||
us-west-1 | HVM - ECS enabled | [ami-03f86e5bb88269702](https://us-west-1.console.aws.amazon.com/ec2/home?region=us-west-1#launchInstanceWizard:ami=ami-03f86e5bb88269702)
|
||||
us-west-2 | HVM - ECS enabled | [ami-01bde5d57c4d043ad](https://us-west-2.console.aws.amazon.com/ec2/home?region=us-west-2#launchInstanceWizard:ami=ami-01bde5d57c4d043ad)
|
||||
|
||||
@@ -93,7 +93,7 @@ Key | Value | Default | Description
|
||||
`extra_args` | List of Strings | `[]` | Arbitrary daemon arguments, appended to the generated command
|
||||
`environment` | List of Strings (optional) | `[]` |
|
||||
|
||||
_Available as of v1.4_
|
||||
_Available as of v1.4.x_
|
||||
|
||||
The docker-sys bridge can be configured with system-docker args, it will take effect after reboot.
|
||||
|
||||
@@ -101,6 +101,18 @@ The docker-sys bridge can be configured with system-docker args, it will take ef
|
||||
$ ros config set rancher.system_docker.bip 172.18.43.1/16
|
||||
```
|
||||
|
||||
_Available as of v1.4.x_
|
||||
|
||||
The default path of system-docker logs is `/var/log/system-docker.log`. If you want to write the system-docker logs to a separate partition,
|
||||
e.g. [RANCHE_OEM partition]({{< baseurl >}}/os/v1.x/en/about/custom-partition-layout/#use-rancher-oem-partition), you can try `rancher.defaults.system_docker_logs`:
|
||||
|
||||
```
|
||||
#cloud-config
|
||||
rancher:
|
||||
defaults:
|
||||
system_docker_logs: /usr/share/ros/oem/system-docker.log
|
||||
```
|
||||
|
||||
### Using a pull through registry mirror
|
||||
|
||||
There are 3 Docker engines that can be configured to use the pull-through Docker Hub registry mirror cache:
|
||||
|
||||
@@ -10,18 +10,3 @@ You must boot with at least **1280MB** of memory. If you boot with the ISO, you
|
||||
### Install to Disk
|
||||
|
||||
After you boot RancherOS from ISO, you can follow the instructions [here]({{< baseurl >}}/os/v1.x/en/installation/running-rancheros/server/install-to-disk/) to install RancherOS to a hard disk.
|
||||
|
||||
### Persisting State
|
||||
|
||||
If you are running from the ISO, RancherOS will be running from memory. All downloaded Docker images, for example, will be stored in a ramdisk and will be lost after the server is rebooted. You can
|
||||
create a file system with the label `RANCHER_STATE` to instruct RancherOS to use that partition to store state. Suppose you have a disk partition on the server called `/dev/sda`, the following command formats that partition and labels it `RANCHER_STATE`
|
||||
|
||||
```
|
||||
$ sudo mkfs.ext4 -L RANCHER_STATE /dev/sda
|
||||
# Reboot afterwards in order for the changes to start being saved.
|
||||
$ sudo reboot
|
||||
```
|
||||
|
||||
After you reboot, the server RancherOS will use `/dev/sda` as the state partition.
|
||||
|
||||
> **Note:** If you are installing RancherOS to disk, you do not need to run this command.
|
||||
|
||||
@@ -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 |
|
||||
+1
-1
@@ -14,7 +14,7 @@ When removing nodes from your Rancher-launched cluster (provided that they are i
|
||||
|
||||
When cleaning nodes provisioned using Rancher, the following components are deleted based on the type of cluster node you're removing.
|
||||
|
||||
| Removed Component | [IaaS Nodes][1] | [Custom Nodes][2] | [Hosted Cluster][3] | [Imported Nodes][4] |
|
||||
| Removed Component | [Nodes Hosted by Infrastructure Provider][1] | [Custom Nodes][2] | [Hosted Cluster][3] | [Imported Nodes][4] |
|
||||
| ------------------------------------------------------------------------------ | --------------- | ----------------- | ------------------- | ------------------- |
|
||||
| The Rancher deployment namespace (`cattle-system` by default) | ✓ | ✓ | ✓ | ✓ |
|
||||
| `serviceAccount`, `clusterRoles`, and `clusterRoleBindings` labeled by Rancher | ✓ | ✓ | ✓ | ✓ |
|
||||
|
||||
@@ -9,26 +9,16 @@ This procedure describes how to use RKE to restore a snapshot of the Rancher Kub
|
||||
|
||||
## Restore Outline
|
||||
|
||||
1. [Preparation](#1-preparation)
|
||||
<!-- TOC -->
|
||||
|
||||
Install utilities and create new or clean existing nodes to prepare for restore.
|
||||
|
||||
2. [Place Snapshot and PKI Bundle](#2-place-snapshot-and-pki-bundle)
|
||||
|
||||
Pick a node and place snapshot `.db` and `pki.bundle.tar.gz` files.
|
||||
|
||||
3. [Configure RKE](#3-configure-rke)
|
||||
|
||||
Configure RKE `cluster.yml`. Remove `addons:` section and point configuration to the clean nodes.
|
||||
|
||||
4. [Restore Database](#4-restore-database)
|
||||
|
||||
Run RKE command to restore the `etcd` database to a single node.
|
||||
|
||||
5. [Bring Up the Cluster](#5-bring-up-the-cluster)
|
||||
|
||||
Run RKE commands to bring up cluster one a single node. Clean up old nodes. Verify and add additional nodes.
|
||||
- [1. Preparation](#1-preparation)
|
||||
- [2. Place Snapshot and PKI Bundle](#2-place-snapshot-and-pki-bundle)
|
||||
- [3. Configure RKE](#3-configure-rke)
|
||||
- [4. Restore Database](#4-restore-database)
|
||||
- [5. Bring Up the Cluster](#5-bring-up-the-cluster)
|
||||
|
||||
<!-- /TOC -->
|
||||
<br/>
|
||||
|
||||
### 1. Preparation
|
||||
|
||||
@@ -51,8 +51,7 @@ Options include:
|
||||
|
||||
- [Hosted Kubernetes Cluster](#hosted-kubernetes-cluster)
|
||||
- [Rancher Launched Kubernetes](#rancher-launched-kubernetes)
|
||||
|
||||
- [Node Pools](#node-pools)
|
||||
- [Nodes Hosted by an Infrastructure Provider](#nodes-hosted-by-an-infrastructure-provider)
|
||||
- [Custom Nodes](#custom-nodes)
|
||||
- [Import Existing Cluster](#import-existing-cluster)
|
||||
|
||||
@@ -73,11 +72,11 @@ Alternatively, you can use Rancher to create a cluster on your own nodes, using
|
||||
|
||||
[Rancher Launched Kubernetes]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/)
|
||||
|
||||
#### Node Pools
|
||||
#### Nodes Hosted by an Infrastructure Provider
|
||||
|
||||
Using Rancher, you can create pools of nodes based on a [node template]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/#node-templates). This template defines the parameters used to launch nodes in your cloud providers. The cloud providers available for creating a node template are decided based on the [node drivers]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/#node-drivers) active in the Rancher UI. The benefit of using a node pool is that if a node loses connectivity with the cluster, Rancher automatically replaces it, thus maintaining the expected cluster configuration.
|
||||
Using Rancher, you can create pools of nodes based on a [node template]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/#node-templates). This template defines the parameters used to launch nodes in your cloud providers. The cloud providers available for creating a node template are decided based on the [node drivers]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/#node-drivers) active in the Rancher UI. The benefit of using nodes hosted by an infrastructure provider is that if a node loses connectivity with the cluster, Rancher automatically replaces it, thus maintaining the expected cluster configuration.
|
||||
|
||||
[Node Pools]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/)
|
||||
[Nodes Hosted by an Infrastructure Provider]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/)
|
||||
|
||||
#### Custom Nodes
|
||||
|
||||
|
||||
@@ -0,0 +1,155 @@
|
||||
---
|
||||
title: Cloning Clusters
|
||||
weight: 2400
|
||||
---
|
||||
|
||||
If you have a cluster in Rancher that you want to use as a template for creating similar clusters, you can use Rancher CLI to clone the cluster's configuration, edit it, and then use it to quickly launch the cloned cluster.
|
||||
|
||||
## Caveats
|
||||
|
||||
- Only [cluster types]({{< baseurl >}}/content/rancher/v2.x/en/cluster-provisioning) that interact with cloud hosts over API can be cloned. Duplication of imported clusters and custom clusters provisioned using Docker machine is not supported.
|
||||
|
||||
| Cluster Type | Cloneable? |
|
||||
| -------------------------------- | ------------- |
|
||||
| [Hosted Kubernetes Providers][1] | ✓ |
|
||||
| [Nodes Hosted by Infrastructure Provider][2] | ✓ |
|
||||
| [Custom Cluster][3] | |
|
||||
| [Imported Cluster][4] | |
|
||||
- During the process of duplicating a cluster, you will edit a config file full of cluster settings. However, we recommend editing only values explicitly listed in this document, as cluster duplication is designed for simple cluster copying, _not_ wide scale configuration changes. Editing other values may invalidate the config file, which will lead to cluster deployment failure.
|
||||
|
||||
[1]: {{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/
|
||||
[2]: {{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/
|
||||
[3]: {{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/custom-clusters/
|
||||
[4]: {{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/imported-clusters/
|
||||
|
||||
## Prerequisites
|
||||
|
||||
Download and install [Rancher CLI]({{< baseurl >}}/rancher/v2.x/en/cli). Remember to [create an API bearer token]({{< baseurl >}}/rancher/v2.x/en/user-settings/api-keys) if necessary.
|
||||
|
||||
|
||||
## 1. Export Cluster Config
|
||||
|
||||
Begin by using Rancher CLI to export the configuration for the cluster that you want to clone.
|
||||
|
||||
1. Open Terminal and change your directory to the location of the Rancher CLI binary, `rancher`.
|
||||
|
||||
1. Enter the following command to list the clusters managed by Rancher.
|
||||
|
||||
|
||||
./rancher cluster ls
|
||||
|
||||
|
||||
1. Find the cluster that you want to clone, and copy either its resource `ID` or `NAME` to your clipboard. From this point on, we'll refer to the resource `ID` or `NAME` as `<RESOURCE_ID>`, which is used as a placeholder in the next step.
|
||||
|
||||
1. Enter the following command to export the configuration for your cluster.
|
||||
|
||||
|
||||
./rancher clusters export <RESOURCE_ID>
|
||||
|
||||
|
||||
**Step Result:** The YAML for a cloned cluster prints to Terminal.
|
||||
|
||||
1. Copy the YAML to your clipboard and paste it in a new file. Save the file as `cluster-template.yml` (or any other name, as long as it has a `.yml` extension).
|
||||
|
||||
## 2. Modify Cluster Config
|
||||
|
||||
Use your favorite text editor to modify the cluster configuration in `cluster-template.yml` for your cloned cluster.
|
||||
|
||||
1. Open `cluster-template.yml` (or whatever you named your config) in your favorite text editor.
|
||||
|
||||
>**Warning:** Only edit the cluster config values explicitly called out below. Many of the values listed in this file are used to provision your cloned cluster, and editing their values may break the provisioning process.
|
||||
|
||||
|
||||
1. As depicted in one of the examples below, at the `<CLUSTER_NAME>` placeholder, replace your original cluster's name with a unique name (`<CLUSTER_NAME>`). If your cloned cluster has a duplicate name, the cluster will not provision successfully.
|
||||
{{% accordion id="gke" label="GKE" %}}
|
||||
```yml
|
||||
Version: v3
|
||||
clusters:
|
||||
<CLUSTER_NAME>: # ENTER UNIQUE NAME
|
||||
dockerRootDir: /var/lib/docker
|
||||
enableNetworkPolicy: false
|
||||
googleKubernetesEngineConfig:
|
||||
credential: |-
|
||||
{
|
||||
"type": "service_account",
|
||||
"project_id": "gke-cluster-221300",
|
||||
"private_key_id": "1d210afae352bc298bde1b3e680ec0c8b22cdd61"
|
||||
```
|
||||
{{% /accordion %}}
|
||||
{{% accordion id="eks" label="EKS" %}}
|
||||
```yml
|
||||
Version: v3
|
||||
clusters:
|
||||
<CLUSTER_NAME>: # ENTER UNIQUE NAME
|
||||
amazonElasticContainerServiceConfig:
|
||||
accessKey: 00000000000000000000
|
||||
associateWorkerNodePublicIp: true
|
||||
instanceType: t2.medium
|
||||
maximumNodes: 3
|
||||
minimumNodes: 1
|
||||
region: us-west-2
|
||||
secretKey: 0000000000000000000000000000000000000000
|
||||
dockerRootDir: /var/lib/docker
|
||||
enableNetworkPolicy: false
|
||||
```
|
||||
{{% /accordion %}}
|
||||
{{% accordion id="aks" label="AKS" %}}
|
||||
```yml
|
||||
Version: v3
|
||||
clusters:
|
||||
<CLUSTER_NAME>: # ENTER UNIQUE NAME
|
||||
azureKubernetesServiceConfig:
|
||||
adminUsername: azureuser
|
||||
agentPoolName: rancher
|
||||
agentVmSize: Standard_D5_v2
|
||||
clientId: 00000000-0000-0000-0000-000000000000
|
||||
clientSecret: 00000000000000000000000000000000000000000000
|
||||
count: 3
|
||||
kubernetesVersion: 1.11.2
|
||||
location: westus
|
||||
osDiskSizeGb: 100
|
||||
resourceGroup: docker-machine
|
||||
sshPublicKeyContents: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDJc2kDExgRaDLD
|
||||
```
|
||||
{{% /accordion %}}
|
||||
{{% accordion id="ec2" label="Nodes Hosted by Infrastructure Provider (EC2, Azure, or DigitalOcean )" %}}
|
||||
```yml
|
||||
Version: v3
|
||||
clusters:
|
||||
<CLUSTER_NAME>: # ENTER UNIQUE NAME
|
||||
dockerRootDir: /var/lib/docker
|
||||
enableNetworkPolicy: false
|
||||
rancherKubernetesEngineConfig:
|
||||
addonJobTimeout: 30
|
||||
authentication:
|
||||
strategy: x509
|
||||
authorization: {}
|
||||
bastionHost: {}
|
||||
cloudProvider: {}
|
||||
ignoreDockerVersion: true
|
||||
```
|
||||
{{% /accordion %}}
|
||||
|
||||
1. **Nodes Hosted by Infrastructure Provider Only:** For each `nodePools` section, replace the original nodepool name with a unique name at the `<NODEPOOL_NAME>` placeholder. If your cloned cluster has a duplicate nodepool name, the cluster will not provision successfully.
|
||||
|
||||
```yml
|
||||
nodePools:
|
||||
<NODEPOOL_NAME>:
|
||||
clusterId: do
|
||||
controlPlane: true
|
||||
etcd: true
|
||||
hostnamePrefix: mark-do
|
||||
nodeTemplateId: do
|
||||
quantity: 1
|
||||
worker: true
|
||||
```
|
||||
|
||||
1. When you're done, save and close the configuration.
|
||||
|
||||
## 3. Launch Cloned Cluster
|
||||
|
||||
Move `cluster-template.yml` into the same directory as the Rancher CLI binary. Then run this command:
|
||||
|
||||
./rancher up --file cluster-template.yml
|
||||
|
||||
**Result:** Your cloned cluster begins provisioning. Enter `./rancher cluster ls` to confirm. You can also log into the Rancher UI and open the **Global** view to watch your provisioning cluster's progress.
|
||||
@@ -3,6 +3,6 @@ title: Custom Cluster
|
||||
weight: 2210
|
||||
---
|
||||
|
||||
If you don't want to host your Kubernetes cluster in a [hosted kubernetes provider]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters) or provision nodes through Rancher, you can use the _custom cluster_ option to create a Kubernetes cluster in on-premise bare-metal servers, on-premise virtual machines, or in _any_ IaaS provider.
|
||||
If you don't want to host your Kubernetes cluster in a [hosted kubernetes provider]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters) or provision nodes through Rancher, you can use the _custom cluster_ option to create a Kubernetes cluster in on-premise bare-metal servers, on-premise virtual machines, or in _any_ node hosted by an infrastructure provider.
|
||||
|
||||
In this scenario, you'll bring the nodes yourself, and then configure them to meet Rancher's [requirements]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/#requirements). Then, use the [Custom Nodes]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/) install option to setup your cluster.
|
||||
|
||||
@@ -5,7 +5,7 @@ weight: 2100
|
||||
|
||||
You can use Rancher to create clusters in a hosted Kubernetes provider, such as Google GKE.
|
||||
|
||||
In this use case, Rancher sends a request to a hosted provider using the provider's API. The provider then provisions and hosts the cluster for you. When the cluster finishes building, you can manage it from the Rancher UI along with clusters you've provisioned that are hosted on-premise or in an IaaS, all from the same UI.
|
||||
In this use case, Rancher sends a request to a hosted provider using the provider's API. The provider then provisions and hosts the cluster for you. When the cluster finishes building, you can manage it from the Rancher UI along with clusters you've provisioned that are hosted on-premise or in an infrastructure provider, all from the same UI.
|
||||
|
||||
Rancher supports the following Kubernetes providers:
|
||||
|
||||
|
||||
+94
-31
@@ -7,56 +7,119 @@ aliases:
|
||||
---
|
||||
## Objectives
|
||||
|
||||
1. [Create an account with appropriate permissions](#give-appropriate-permissions)
|
||||
<!-- TOC -->
|
||||
|
||||
Create (or give an existing) user appropriate permissions to create an EKS cluster.
|
||||
- [1. Give Appropriate Permissions](#1-give-appropriate-permissions)
|
||||
- [2. Create Access Key and Secret Key](#2-create-access-key-and-secret-key)
|
||||
- [3. Create the EKS Cluster](#3-create-the-eks-cluster)
|
||||
|
||||
2. [Create an access key and secret key](#create-access-key-and-secret-key)
|
||||
|
||||
Create an access key and secret key to access Amazon Web Services (AWS) resources from Rancher.
|
||||
<!-- /TOC -->
|
||||
|
||||
3. [Create the EKS Cluster](#create-the-eks-cluster)
|
||||
|
||||
Using the AWS account, create your Amazon Elastic Container Service for Kubernetes (EKS) cluster in Rancher.
|
||||
|
||||
## Give Appropriate Permissions
|
||||
## 1. Give Appropriate Permissions
|
||||
|
||||
Make sure that the account you will be using to create the EKS cluster has the appropriate permissions. Referring to the official [EKS documentation](https://docs.aws.amazon.com/eks/latest/userguide/IAM_policies.html) for details.
|
||||
|
||||
## Create Access Key and Secret Key
|
||||
## 2. Create Access Key and Secret Key
|
||||
|
||||
Use AWS to create an access key and client secret.
|
||||
Use AWS to create an access key and client secret for the IAM account used in [1. Give Appropriate Permissions](#1-give-appropriate-permissions).
|
||||
|
||||
1. In the AWS Console, go to the **IAM** service.
|
||||
For instructions on how to create these keys, see the AWS documentation [Managing Access Keys: To create, modify, or delete a user's access keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey).
|
||||
|
||||
2. Select **Users**.
|
||||
## 3. Create the EKS Cluster
|
||||
|
||||
3. Find the user you wish to create the EKS cluster with. Select the user.
|
||||
|
||||
4. Click **Security Credentials**.
|
||||
|
||||
5. Click **Create access key**.
|
||||
|
||||
6. Record the **Access key ID** and **Secret access key**. You will need to use these in Rancher to create your EKS cluster.
|
||||
|
||||
## Create the EKS Cluster
|
||||
|
||||
Use {{< product >}} to set up and configure your Kubernetes cluster.
|
||||
Use Rancher to set up and configure your Kubernetes cluster.
|
||||
|
||||
1. From the **Clusters** page, click **Add Cluster**.
|
||||
|
||||
2. Choose **Amazon EKS**.
|
||||
1. Choose **Amazon EKS**.
|
||||
|
||||
3. Enter a **Cluster Name**.
|
||||
1. Enter a **Cluster Name**.
|
||||
|
||||
4. {{< step_create-cluster_member-roles >}}
|
||||
1. {{< step_create-cluster_member-roles >}}
|
||||
|
||||
5. Enter your **Access Key**.
|
||||
1. Configure **Account Access** for the EKS cluster. Complete each drop-down and field using the information obtained in [2. Create Access Key and Secret Key](#2-create-access-key-and-secret-key).
|
||||
|
||||
6. Enter your **Secret Key**
|
||||
| Setting | Description |
|
||||
| ---------- | -------------------------------------------------------------------------------------------------------------------- |
|
||||
| Region | From the drop-down choose the geographical region in which to build your cluster. |
|
||||
| Access Key | Enter the access key that you created in [2. Create Access Key and Secret Key](#2-create-access-key-and-secret-key). |
|
||||
| Secret Key | Enter the secret key that you created in [2. Create Access Key and Secret Key](#2-create-access-key-and-secret-key). |
|
||||
|
||||
1. Click **Next: Select Service Role**. Then choose a [service role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html).
|
||||
|
||||
7. Click **Next: Authenticate & configure nodes**.
|
||||
Service Role | Description
|
||||
-------------|---------------------------
|
||||
Standard: Rancher generated service role | If you choose this role, Rancher automatically adds a service role for use with the cluster.
|
||||
Custom: Choose from your existing service roles | If you choose this role, Rancher lets you choose from service roles that you're already created within AWS. For more information on creating a custom service role in AWS, see the [Amazon documentation](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#create-service-linked-role).
|
||||
|
||||
8. Specify any additional options (such as instance type or minimum and maximum number of nodes). Then click **Create**.
|
||||
1. Click **Next: Select VPC and Subnet**.
|
||||
|
||||
1. Choose an option for **Public IP for Worker Nodes**. Your selection for this option determines what options are available for **VPC & Subnet**.
|
||||
|
||||
Option | Description
|
||||
-------|------------
|
||||
Yes | When your cluster nodes are provisioned, they're assigned a both a private and public IP address.
|
||||
No: Private IPs only | When your cluster nodes are provisioned, they're assigned only a private IP address.<br/><br/>If you choose this option, you must also choose a **VPC & Subnet** that allow your instances to access the internet. This access is required so that your worker nodes can connect to the Kubernetes control plane.
|
||||
|
||||
1. Now choose a **VPC & Subnet**. Follow one of the sets of instructions below based on your selection from the previous step.
|
||||
|
||||
Amazon Documentation:
|
||||
|
||||
- [What Is Amazon VPC?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
|
||||
- [VPCs and Subnets](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html)
|
||||
|
||||
{{% accordion id="yes" label="Public IP for Worker Nodes—Yes" %}}
|
||||
If you choose to assign a public IP address to your cluster's worker nodes, you have the option of choosing between a VPC that's automatically generated by Rancher (i.e., **Standard: Rancher generated VPC and Subnet**), or a VPC that you're already created with AWS (i.e., **Custom: Choose from your existing VPC and Subnets**). Choose the option that best fits your use case.
|
||||
|
||||
1. Choose a **VPC and Subnet** option.
|
||||
|
||||
Option | Description
|
||||
-------|------------
|
||||
Standard: Rancher generated VPC and Subnet | While provisioning your cluster, Rancher generates a new VPC and Subnet.
|
||||
Custom: Choose from your exiting VPC and Subnets | While provisioning your cluster, Rancher configures your nodes to use a VPC and Subnet that you've already [created in AWS](https://docs.aws.amazon.com/vpc/latest/userguide/getting-started-ipv4.html). If you choose this option, complete the remaining steps below.
|
||||
|
||||
1. If you're using **Custom: Choose from your existing VPC and Subnets**:
|
||||
|
||||
(If you're using **Standard**, skip to [step 11](#select-instance-options))
|
||||
|
||||
1. Make sure **Custom: Choose from your existing VPC and Subnets** is selected.
|
||||
|
||||
1. From the drop-down that displays, choose a VPC.
|
||||
|
||||
1. Click **Next: Select Subnets**. Then choose one of the **Subnets** that displays.
|
||||
|
||||
1. Click **Next: Select Security Group**.
|
||||
{{% /accordion %}}
|
||||
{{% accordion id="no" label="Public IP for Worker Nodes—No: Private IPs only" %}}
|
||||
If you chose this option, you must also choose a **VPC & Subnet** that allow your instances to access the internet. This access is required so that your worker nodes can connect to the Kubernetes control plane. Follow the steps below.
|
||||
|
||||
>**Tip:** When using only private IP addresses, you can provide your nodes internet access by creating a VPC constructed with two subnets, a private set and a public set. The private set should have its route tables configured to point toward a NAT in the public set. For more information on routing traffic from private subnets, please see the [official AWS documentation](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_NAT_Instance.html).
|
||||
|
||||
1. From the drop-down that displays, choose a VPC.
|
||||
|
||||
1. Click **Next: Select Subnets**. Then choose one of the **Subnets** that displays.
|
||||
|
||||
1. Click **Next: Select Security Group**.
|
||||
{{% /accordion %}}
|
||||
|
||||
1. <a id="security-group"></a>Choose a **Security Group**. See the documentation below on how to create one.
|
||||
|
||||
Amazon Documentation:
|
||||
|
||||
- [Security Groups for Your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)
|
||||
- [Create a Security Group](https://docs.aws.amazon.com/vpc/latest/userguide/getting-started-ipv4.html#getting-started-create-security-group)
|
||||
|
||||
1. <a id="select-instance-options"></a>Click **Select Instance Options**, and then edit the node options available.
|
||||
|
||||
Option | Description
|
||||
-------|------------
|
||||
Instance Type | Choose the [hardware specs](https://aws.amazon.com/ec2/instance-types/) for the instance you're provisioning.
|
||||
Custom AMI Override | If you want to use a custom [Amazon Machine Image](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html#creating-an-ami) (AMI), specify it here.
|
||||
Minimum ASG Size | The minimum number of instances that your cluster will scale to during low traffic, as controlled by [Amazon Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html).
|
||||
Maximum ASG Size | The maximum number of instances that your cluster will scale to during high traffic, as controlled by [Amazon Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html).
|
||||
|
||||
1. Click **Create**.
|
||||
|
||||
{{< result_create-cluster >}}
|
||||
|
||||
|
||||
@@ -7,17 +7,17 @@ If you don't want to use a hosted Kubernetes provider, you can have Rancher laun
|
||||
|
||||
- Bare-metal servers
|
||||
- On-premise virtual machines
|
||||
- IaaS-hosted virtual machines
|
||||
- Virtual machines hosted by an infrastructure provider
|
||||
|
||||
RKE launched clusters are separated into two categories:
|
||||
|
||||
- [Node Pools]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/):
|
||||
- [Nodes Hosted by an Infrastructure Provider]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/):
|
||||
|
||||
Using Rancher, you can create pools of nodes based on a [node template]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/#node-templates). This node template defines the parameters you want to use to launch nodes in your cloud providers. The available cloud providers to create a node template are decided based on active [node drivers]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/#node-drivers). The benefit of using a node pool is that if a node loses connectivity with the cluster, Rancher will automatically create another node to join the cluster to ensure that the count of the node pool is as expected.
|
||||
Using Rancher, you can create pools of nodes based on a [node template]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/#node-templates). This node template defines the parameters you want to use to launch nodes in your cloud providers. The available cloud providers to create a node template are decided based on active [node drivers]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/#node-drivers). The benefit of using a node hosted by an infrastructure provider is that if a node loses connectivity with the cluster, Rancher will automatically create another node to join the cluster to ensure that the count of the node pool is as expected.
|
||||
|
||||
- [Custom Nodes]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/):
|
||||
|
||||
For use cases where you want to provision bare-metal servers, on-premise virtual machines, or bring virtual machines that are already exist in a cloud provider. With this option, you will run a Rancher agent Docker container on the machine.
|
||||
For use cases where you want to provision bare-metal servers, on-premise virtual machines, or bring virtual machines that already exist in a cloud provider. With this option, you will run a Rancher agent Docker container on the machine.
|
||||
|
||||
>**Note:** If you want to reuse a node from a previous custom cluster, [clean the node]({{< baseurl >}}/rancher/v2.x/en/admin-settings/removing-rancher/rancher-cluster-nodes/) before using it in a cluster again. If you reuse a node that hasn't been cleaned, cluster provisioning may fail.
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@ aliases:
|
||||
|
||||
## Custom Nodes
|
||||
|
||||
Use Rancher to create a Kubernetes cluster on your on-premise bare metal servers. This option creates a cluster using a combination of [Docker Machine](https://docs.docker.com/machine/) and RKE, which is Rancher's own lightweight Kubernetes installer. In addition to bare metal servers, RKE can also create clusters on _any_ IaaS providers by integrating with node drivers.
|
||||
Use Rancher to create a Kubernetes cluster on your on-premise bare metal servers. This option creates a cluster using a combination of [Docker Machine](https://docs.docker.com/machine/) and RKE, which is Rancher's own lightweight Kubernetes installer. In addition to bare metal servers, RKE can also create clusters on _any_ infrastructure provider by integrating with node drivers.
|
||||
|
||||
To use this option you'll need access to servers you intend to use as your Kubernetes cluster. Provision each server according to Rancher [requirements](#requirements), which includes some hardware specifications and Docker. After you install Docker on each server, run the command provided in the Rancher UI to turn each server into a Kubernetes node.
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Nodes hosted in an Infrastructure Provider
|
||||
title: Nodes Hosted in an Infrastructure Provider
|
||||
weight: 2205
|
||||
aliases:
|
||||
- /rancher/v2.x/en/concepts/global-configuration/node-drivers/
|
||||
|
||||
@@ -13,7 +13,7 @@ See [Technical FAQ]({{< baseurl >}}/rancher/v2.x/en/faq/technical/), for frequen
|
||||
|
||||
#### What does it mean when you say Rancher v2.0 is built on Kubernetes?
|
||||
|
||||
Rancher v2.0 is a complete container management platform built on 100% on Kubernetes leveraging its Custom Resource and Controller framework. All features are written as a CustomResourceDefinition (CRD) which extends the existing Kubernetes API and can leverage native features such as RBAC.
|
||||
Rancher v2.0 is a complete container management platform built 100% on Kubernetes leveraging its Custom Resource and Controller framework. All features are written as a CustomResourceDefinition (CRD) which extends the existing Kubernetes API and can leverage native features such as RBAC.
|
||||
|
||||
#### Do you plan to implement upstream Kubernetes, or continue to work on your own fork?
|
||||
|
||||
|
||||
@@ -119,3 +119,20 @@ A node is required to have a static IP configured (or a reserved IP via DHCP). I
|
||||
When the IP address of the node changed, Rancher lost connection to the node, so it will be unable to clean the node properly. See [Cleaning cluster nodes]({{< baseurl >}}/rancher/v2.x/en/faq/cleaning-cluster-nodes/) to clean the node.
|
||||
|
||||
When the node is removed from the cluster, and the node is cleaned, you can readd the node to the cluster.
|
||||
|
||||
### How can I add additional arguments/binds/environment variables to Kubernetes components in a Rancher Launched Kubernetes cluster?
|
||||
|
||||
You can add additional arguments/binds/environment variables via the [Config File]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/#config-file) option in Cluster Options. For more information, see the [Extra Args, Extra Binds, and Extra Environment Variables]({{< baseurl >}}/rke/v0.1.x/en/config-options/services/services-extras/) in the RKE documentation or browse the [Example Cluster.ymls]({{< baseurl >}}/rke/v0.1.x/en/example-yamls/).
|
||||
|
||||
### Why does it take 5+ minutes for a pod to be rescheduled when a node has failed?
|
||||
|
||||
This is due to a combination of the following default Kubernetes settings:
|
||||
|
||||
* kubelet
|
||||
* `node-status-update-frequency`: Specifies how often kubelet posts node status to master (default 10s)
|
||||
* kube-controller-manager
|
||||
* `node-monitor-period`: The period for syncing NodeStatus in NodeController (default 5s)
|
||||
* `node-monitor-grace-period`: Amount of time which we allow running Node to be unresponsive before marking it unhealthy (default 40s)
|
||||
* `pod-eviction-timeout`: The grace period for deleting pods on failed nodes (default 5m0s)
|
||||
|
||||
See [Kubernetes: kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) and [Kubernetes: kube-controller-manager](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/) for more information on these settings.
|
||||
|
||||
@@ -64,7 +64,7 @@ Instead of installing the `tiller` agent on the cluster, render the installs on
|
||||
|
||||
### Initialize Helm Locally
|
||||
|
||||
Skip the [Initialize Helm (Install Tiller)]({{< baseurl >}}/rancher/v2.x/en/installation/ha/helm-init/#helm-init) and initialize `helm` locally on a system that has internet access.
|
||||
Skip the [Initialize Helm (Install Tiller)]({{< baseurl >}}/rancher/v2.x/en/installation/ha/helm-init/) and initialize `helm` locally on a system that has internet access.
|
||||
|
||||
```plain
|
||||
helm init -c
|
||||
@@ -80,9 +80,9 @@ Fetch and render the `helm` charts on a system that has internet access.
|
||||
|
||||
#### Cert-Manager
|
||||
|
||||
If you are installing Rancher with Rancher Self-Signed certificates you will need to install 'cert-manager' on your cluster. If you are installing your own certificates you may skip this section.
|
||||
If you are installing Rancher with Rancher self-signed certificates you will need to install 'cert-manager' on your cluster. If you are installing your own certificates you may skip this section.
|
||||
|
||||
Fetch the latest `stable/cert-manager` chart. This will pull down the chart and save it in the current directory as a `.tgz` file.
|
||||
Fetch the latest `cert-manager` chart from the [official Helm chart repository](https://github.com/helm/charts/tree/master/stable).
|
||||
|
||||
```plain
|
||||
helm fetch stable/cert-manager
|
||||
@@ -98,16 +98,16 @@ helm template ./cert-manager-<version>.tgz --output-dir . \
|
||||
|
||||
#### Rancher
|
||||
|
||||
Install the Rancher chart repo.
|
||||
Add the Helm chart repository that contains charts to install Rancher. Replace `<CHART_REPO>` with the [repository that you're using]({{< baseurl >}}/rancher/v2.x/en/installation/server-tags/#helm-chart-repositories) (i.e. `latest` or `stable`).
|
||||
|
||||
```plain
|
||||
helm repo add rancher-stable https://releases.rancher.com/server-charts/stable
|
||||
helm repo add rancher-<CHART_REPO> https://releases.rancher.com/server-charts/<CHART_REPO>
|
||||
```
|
||||
|
||||
Fetch the latest `rancher-stable/rancher` chart. This will pull down the chart and save it in the current directory as a `.tgz` file.
|
||||
Fetch the latest Rancher chart. This will pull down the chart and save it in the current directory as a `.tgz` file. Replace `<CHART_REPO>` with the repo you're using (`latest` or `stable`).
|
||||
|
||||
```plain
|
||||
helm fetch rancher-stable/rancher
|
||||
helm fetch rancher-<CHART_REPO>/rancher
|
||||
```
|
||||
|
||||
Render the template with the options you would use to install the chart. See [Install Rancher]({{< baseurl >}}/rancher/v2.x/en/installation/ha/helm-rancher/) for details on the various options. Remember to set the `rancherImage` option to pull the image from your private registry. This will create a `rancher` directory with the Kubernetes manifest files.
|
||||
|
||||
@@ -7,7 +7,7 @@ For production environments, we recommend installing Rancher in a high-availabil
|
||||
|
||||
This procedure walks you through setting up a 3-node cluster with RKE and installing the Rancher chart with the Helm package manager.
|
||||
|
||||
> **Important:** For the best performance, we recommend this Kubernetes cluster to be dedicated only to run Rancher.
|
||||
> **Important:** For the best performance, we recommend this Kubernetes cluster to be dedicated only to run Rancher. After the Kubernetes cluster to run Rancher is setup, you can [create or import clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#cluster-creation-in-rancher) for running your workloads.
|
||||
|
||||
## Recommended Architecture
|
||||
|
||||
|
||||
@@ -3,17 +3,18 @@ title: 3 - Initialize Helm (Install tiller)
|
||||
weight: 195
|
||||
---
|
||||
|
||||
Helm is the package management tool of choice for Kubernetes. Helm charts provide templating syntax for Kubernetes YAML manifest documents. With Helm we can create configurable deployments instead of just using static files. For more information about creating your own catalog of deployments, check out the docs at [https://helm.sh/](https://helm.sh/).
|
||||
|
||||
Helm is the package management tool of choice for Kubernetes. Helm "charts" provide templating syntax for Kubernetes YAML manifest documents. With Helm we can create configurable deployments instead of just using static files. For more information about creating your own catalog of deployments, check out the docs at [https://helm.sh/](https://helm.sh/). To be able to use Helm, the server-side component `tiller` needs to be installed on your cluster.
|
||||
|
||||
> **Note:** For systems without direct internet access see [Helm - Air Gap]({{< baseurl >}}/rancher/v2.x/en/installation/air-gap-installation/install-rancher/#helm) for install details.
|
||||
|
||||
### Initialize Helm on the Cluster
|
||||
### Install Tiller on the Cluster
|
||||
|
||||
Helm installs the `tiller` service on your cluster to manage charts. Since RKE enables RBAC by default we will need to use `kubectl` to create a `serviceaccount` and `clusterrolebinding` so `tiller` has permission to deploy to the cluster.
|
||||
|
||||
* Create the `ServiceAccount` in the `kube-system` namespace.
|
||||
* Create the `ClusterRoleBinding` to give the `tiller` service account access to the cluster.
|
||||
* Finally use `helm` to initialize the `tiller` service
|
||||
* Create the `ClusterRoleBinding` to give the `tiller` account access to the cluster.
|
||||
* Finally use `helm` to install the `tiller` service
|
||||
|
||||
```plain
|
||||
kubectl -n kube-system create serviceaccount tiller
|
||||
@@ -24,6 +25,14 @@ kubectl create clusterrolebinding tiller \
|
||||
|
||||
helm init --service-account tiller
|
||||
|
||||
<<<<<<< HEAD
|
||||
# Users in China: You will need to specify a specific tiller-image in order to initialize tiller.
|
||||
# The list of tiller image tags are available here: https://dev.aliyun.com/detail.html?spm=5176.1972343.2.18.ErFNgC&repoId=62085.
|
||||
# When initializing tiller, you'll need to pass in --tiller-image
|
||||
|
||||
helm init --service-account tiller |
|
||||
--tiller-image registry.cn-hangzhou.aliyuncs.com/google_containers/tiller:<tag>
|
||||
=======
|
||||
# For chinese users
|
||||
# The latest version of tiller images queries addresses:
|
||||
# https://dev.aliyun.com/detail.html?spm=5176.1972343.2.18.ErFNgC&repoId=62085
|
||||
@@ -31,10 +40,29 @@ helm init --service-account tiller
|
||||
helm init --service-account tiller \
|
||||
--tiller-image registry.cn-hangzhou.aliyuncs.com/google_containers/tiller:<tag>
|
||||
|
||||
>>>>>>> Specify tiller image for chinese users
|
||||
```
|
||||
|
||||
> **Note:** This`tiller`install has full cluster access, which should be acceptable if the cluster is dedicated to Rancher server. Check out the [helm docs](https://docs.helm.sh/using_helm/#role-based-access-control) for restricting `tiller` access to suit your security requirements.
|
||||
|
||||
### Test your Tiller installation
|
||||
|
||||
Run the following command to verify the installation of `tiller` on your cluster:
|
||||
|
||||
```
|
||||
kubectl -n kube-system rollout status deploy/tiller-deploy
|
||||
Waiting for deployment "tiller-deploy" rollout to finish: 0 of 1 updated replicas are available...
|
||||
deployment "tiller-deploy" successfully rolled out
|
||||
```
|
||||
|
||||
And run the following command to validate Helm can talk to the `tiller` service:
|
||||
|
||||
```
|
||||
helm version
|
||||
Client: &version.Version{SemVer:"v2.11.0", GitCommit:"2e55dbe1fdb5fdb96b75ff144a339489417b146b", GitTreeState:"clean"}
|
||||
Server: &version.Version{SemVer:"v2.11.0", GitCommit:"2e55dbe1fdb5fdb96b75ff144a339489417b146b", GitTreeState:"clean"}
|
||||
```
|
||||
|
||||
### Issues or errors?
|
||||
|
||||
See the [Troubleshooting]({{< baseurl >}}/rancher/v2.x/en/installation/ha/helm-init/troubleshooting/) page.
|
||||
|
||||
@@ -20,4 +20,4 @@ helm version --server
|
||||
Error: could not find tiller
|
||||
```
|
||||
|
||||
When you have confirmed that `tiller` has been removed, please follow the steps provided in [Initialize Helm on the cluster]({{< baseurl >}}/rancher/v2.x/en/installation/ha/helm-init/#initialize-helm-on-the-cluster) to install `tiller` with the correct `ServiceAccount`.
|
||||
When you have confirmed that `tiller` has been removed, please follow the steps provided in [Initialize Helm (Install tiller)]({{< baseurl >}}/rancher/v2.x/en/installation/ha/helm-init/) to install `tiller` with the correct `ServiceAccount`.
|
||||
|
||||
@@ -3,38 +3,27 @@ title: 4 - Install Rancher
|
||||
weight: 200
|
||||
---
|
||||
|
||||
Rancher installation is now managed using the Helm package manager for Kubernetes. Use `helm` to install the prerequisite and Rancher charts.
|
||||
Rancher installation is managed using the Helm package manager for Kubernetes. Use `helm` to install the prerequisite and charts to install Rancher.
|
||||
|
||||
> **Note:** For systems without direct internet access see [Installing Rancher - Air Gap]({{< baseurl >}}/rancher/v2.x/en/installation/air-gap-installation/install-rancher/) for install details.
|
||||
|
||||
### Add the Chart Repo
|
||||
### Add the Helm Chart Repository
|
||||
|
||||
Use `helm repo add` to add the Rancher chart repository.
|
||||
Use `helm repo add` command to add the Helm chart repository that contains charts to install Rancher. For more information about the repository choices and which is best for your use case, see [Choosing a Version of Rancher]({{< baseurl >}}/rancher/v2.x/en/installation/server-tags/#helm-chart-repositories).
|
||||
|
||||
Replace `<CHART_REPO>` with the Helm chart repository that you want to use (i.e. `latest` or `stable`).
|
||||
|
||||
```
|
||||
helm repo add rancher-stable https://releases.rancher.com/server-charts/stable
|
||||
```
|
||||
|
||||
## Chart Versioning Notes
|
||||
|
||||
Up until the initial helm chart release for v2.1.0, the helm chart version matched the Rancher version (i.e `appVersion`).
|
||||
|
||||
Since there are times where the helm chart will require changes without any changes to the Rancher version, we have moved to a `yyyy.mm.<build-number>` helm chart version.
|
||||
|
||||
Run `helm search rancher` to view which Rancher version will be launched for the specific helm chart version.
|
||||
|
||||
```
|
||||
NAME CHART VERSION APP VERSION DESCRIPTION
|
||||
rancher-stable/rancher 2018.10.1 v2.1.0 Install Rancher Server to manage Kubernetes clusters acro...
|
||||
helm repo add rancher-<CHART_REPO> https://releases.rancher.com/server-charts/<CHART_REPO>
|
||||
```
|
||||
|
||||
### Install cert-manager
|
||||
|
||||
> **Note:** cert-manager is only required for Rancher generated and LetsEncrypt issued certificates. You may skip this step if you are bringing your own certificates and using the `ingress.tls.source=secret` option.
|
||||
> **Note:** cert-manager is only required for Rancher generated and LetsEncrypt issued certificates. You may skip this step if you are bringing your own certificates or using the `ingress.tls.source=secret` option.
|
||||
|
||||
Rancher relies on [cert-manager](https://github.com/kubernetes/charts/tree/master/stable/cert-manager) from the Kubernetes Helm stable catalog to issue self-signed or LetsEncrypt certificates.
|
||||
Rancher relies on [cert-manager](https://github.com/kubernetes/charts/tree/master/stable/cert-manager) from the official Kubernetes Helm chart repository to issue self-signed or LetsEncrypt certificates.
|
||||
|
||||
Install `cert-manager` from the Helm stable catalog.
|
||||
Install `cert-manager` from Kubernetes Helm chart repository.
|
||||
|
||||
```
|
||||
helm install stable/cert-manager \
|
||||
@@ -58,12 +47,13 @@ There are three options for the source of the certificate.
|
||||
|
||||
The default is for Rancher to generate a CA and use the `cert-manager` to issue the certificate for access to the Rancher server interface.
|
||||
|
||||
The only requirement is to set the `hostname` to the DNS name you pointed at your load balancer.
|
||||
- Replace `<CHART_REPO>` with the repository that you configured in [Add the Helm Chart Repository](#add-the-helm-chart-repository) (i.e. `latest` or `stable`).
|
||||
- Set the `hostname` to the DNS name you pointed at your load balancer.
|
||||
|
||||
>**Using Air Gap?** [Set the `rancherImage` option]({{< baseurl >}}/rancher/v2.x/en/installation/air-gap-installation/install-rancher/#install-rancher-using-private-registry) in your command, pointing toward your private registry.
|
||||
|
||||
```
|
||||
helm install rancher-stable/rancher \
|
||||
helm install rancher-<CHART_REPO>/rancher \
|
||||
--name rancher \
|
||||
--namespace cattle-system \
|
||||
--set hostname=rancher.my.org
|
||||
@@ -73,12 +63,13 @@ helm install rancher-stable/rancher \
|
||||
|
||||
Use [LetsEncrypt](https://letsencrypt.org/)'s free service to issue trusted SSL certs. This configuration uses http validation so the Load Balancer must have a Public DNS record and be accessible from the internet.
|
||||
|
||||
Set `hostname`, `ingress.tls.source=letsEncrypt` and LetsEncrypt options.
|
||||
- Replace `<CHART_REPO>` with the repository that you configured in [Add the Helm Chart Repository](#add-the-helm-chart-repository) (i.e. `latest` or `stable`).
|
||||
- Set `hostname`, `ingress.tls.source=letsEncrypt` and LetsEncrypt options.
|
||||
|
||||
>**Using Air Gap?** [Set the `rancherImage` option]({{< baseurl >}}/rancher/v2.x/en/installation/air-gap-installation/install-rancher/#install-rancher-using-private-registry) in your command, pointing toward your private registry.
|
||||
|
||||
```
|
||||
helm install rancher-stable/rancher \
|
||||
helm install rancher-<CHART_REPO>/rancher \
|
||||
--name rancher \
|
||||
--namespace cattle-system \
|
||||
--set hostname=rancher.my.org \
|
||||
@@ -92,12 +83,13 @@ Create Kubernetes secrets from your own certificates for Rancher to use.
|
||||
|
||||
> **Note:** The common name for the cert will need to match the `hostname` option or the ingress controller will fail to provision the site for Rancher.
|
||||
|
||||
Set `hostname` and `ingress.tls.source=secret`.
|
||||
- Replace `<CHART_REPO>` with the repository that you configured in [Add the Helm Chart Repository](#add-the-helm-chart-repository) (i.e. `latest` or `stable`).
|
||||
- Set `hostname` and `ingress.tls.source=secret`.
|
||||
|
||||
> **Note:** If you are using a Private CA signed cert, add `--set privateCA=true`
|
||||
|
||||
```
|
||||
helm install rancher-stable/rancher \
|
||||
helm install rancher-<CHART_REPO>/rancher \
|
||||
--name rancher \
|
||||
--namespace cattle-system \
|
||||
--set hostname=rancher.my.org \
|
||||
|
||||
@@ -29,7 +29,7 @@ weight: 276
|
||||
| `debug` | false | `bool` - set debug flag on rancher server |
|
||||
| `imagePullSecrets` | [] | `list` - list of names of Secret resource containing private registry credentials |
|
||||
| `proxy` | "" | `string` - string - HTTP[S] proxy server for Rancher |
|
||||
| `noProxy` | "localhost,127.0.0.1" | `string` - comma separated list of hostnames or ip address not to use the proxy |
|
||||
| `noProxy` | "127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16" | `string` - comma separated list of hostnames or ip address not to use the proxy |
|
||||
| `resources` | {} | `map` - rancher pod resource requests & limits |
|
||||
| `rancherImage` | "rancher/rancher" | `string` - rancher image source |
|
||||
| `rancherImageTag` | same as chart version | `string` - rancher/rancher image tag |
|
||||
@@ -59,7 +59,7 @@ Add your IP exceptions to the `noProxy` list. Make sure you add the Service clus
|
||||
|
||||
```plain
|
||||
--set proxy="http://<username>:<password>@<proxy_url>:<proxy_port>/"
|
||||
--set noProxy="127.0.0.1,localhost,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16"
|
||||
--set noProxy="127.0.0.0/8\,10.0.0.0/8\,172.16.0.0/12\,192.168.0.0/16"
|
||||
```
|
||||
|
||||
### Additional Trusted CAs
|
||||
|
||||
@@ -62,7 +62,7 @@ pod/rancher-784d94f59b-vgqzh 1/1 Running 0 10m
|
||||
Use `kubectl` and the pod name to list the logs from the pod.
|
||||
|
||||
```
|
||||
kubectl -n cattle-namespace logs -f rancher-784d94f59b-vgqzh
|
||||
kubectl -n cattle-system logs -f rancher-784d94f59b-vgqzh
|
||||
```
|
||||
|
||||
### Cert CN is "Kubernetes Ingress Controller Fake Certificate"
|
||||
|
||||
@@ -118,4 +118,4 @@ Save a copy of the `kube_config_rancher-cluster.yml` and `rancher-cluster.yml` f
|
||||
|
||||
See the [Troubleshooting]({{< baseurl >}}/rancher/v2.x/en/installation/ha/kubernetes-rke/troubleshooting/) page.
|
||||
|
||||
### [Next: Initialize Helm]({{< baseurl >}}/rancher/v2.x/en/installation/ha/helm-init/)
|
||||
### [Next: Initialize Helm (Install tiller)]({{< baseurl >}}/rancher/v2.x/en/installation/ha/helm-init/)
|
||||
|
||||
@@ -78,7 +78,7 @@ Each node used (either for the Single Node Install, High Availability (HA) Insta
|
||||
|
||||
<h2>Port requirements</h2>
|
||||
|
||||
When deploying Rancher in an HA cluster, certain ports on your nodes must be open to allow communication with Rancher. The ports that must be open change according to the type of machines hosting your cluster nodes. For example, if your are deploying Rancher on nodes hosted by an IaaS, port `22` must be open for SSH. The following diagram depicts the ports that are opened for each [cluster type]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning).
|
||||
When deploying Rancher in an HA cluster, certain ports on your nodes must be open to allow communication with Rancher. The ports that must be open change according to the type of machines hosting your cluster nodes. For example, if your are deploying Rancher on nodes hosted by an infrastructure, port `22` must be open for SSH. The following diagram depicts the ports that are opened for each [cluster type]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning).
|
||||
|
||||
<sup>Cluster Type Port Requirements</sup>
|
||||
|
||||
|
||||
@@ -1,13 +1,81 @@
|
||||
---
|
||||
title: Server Tags
|
||||
title: Choosing a Version of Rancher
|
||||
weight: 230
|
||||
---
|
||||
{{< product >}} Server is distributed as a Docker image, which have _tags_ attached to them. Tags are used to identify what version is included in the image. Rancher includes additional tags that point to a specific version. Remember that if you use the additional tags, you must explicitly pull a new version of that image tag. Otherwise it will use the cached image on the host.
|
||||
|
||||
You can find Rancher images at [DockerHub](https://hub.docker.com/r/rancher/rancher/tags/).
|
||||
## Single Node Installs
|
||||
|
||||
- `rancher/rancher:latest`: Our latest development release. These builds are validated through our CI automation framework. These releases are not recommended for production environments.
|
||||
When performing [single-node installs]({{< baseurl >}}/rancher/v2.x/en/installation/single-node), upgrades, or rollbacks, you can use _tags_ to install a specific version of Rancher.
|
||||
|
||||
- `rancher/rancher:stable`: Our newest stable release. This tag is recommended for production.
|
||||
### Server Tags
|
||||
|
||||
The `master` tag or any tag with a `-rc` or another suffix is meant for the {{< product >}} testing team to validate. You should not use these tags, as these builds are not officially supported.
|
||||
Rancher Server is distributed as a Docker image, which have tags attached to them. You can specify this tag when entering the command to deploy Rancher. Remember that if you use a tag without an explicit version (like `latest` or `stable`), you must explicitly pull a new version of that image tag. Otherwise, any image cached on the host will be used.
|
||||
|
||||
| Tag | Description |
|
||||
| -------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `rancher/rancher:latest` | Our latest development release. These builds are validated through our CI automation framework. These releases are not recommended for production environments. |
|
||||
| `rancher/rancher:stable` | Our newest stable release. This tag is recommended for production. |
|
||||
| `rancher/rancher:<v2.X.X>` | You can install specific versions of Rancher by using the tag from a previous release. See what's available at DockerHub. |
|
||||
|
||||
<br/>
|
||||
|
||||
>**Note:** The `master` tag or any tag with `-rc` or another suffix is meant for the Rancher testing team to validate. You should not use these tags, as these builds are not officially supported.
|
||||
|
||||
## High Availability Installs
|
||||
|
||||
When installing, upgrading, or rolling back Rancher Server in a [high availability configuration]({{< baseurl >}}/rancher/v2.x/en/installation/ha/), Rancher server is installed using a Helm chart on a Kubernetes cluster. Therefore, as you prepare to install or upgrade a high availability Rancher configuration, you must add a Helm chart repository that contains the charts for installing Rancher.
|
||||
|
||||
### Helm Chart Repositories
|
||||
|
||||
Rancher provides two different Helm chart repositories to choose from. We align our latest and stable Helm chart repositories with the Docker tags that are used for a single node installation. Therefore, the `rancher-latest` repository will contain charts for all the Rancher versions that have been tagged as `rancher/rancher:latest`. When a Rancher version has been promoted to the `rancher/rancher:stable`, it will get added to the `rancher-stable` repository.
|
||||
|
||||
|
||||
Type | Command to Add the Repo | Description of the Repo
|
||||
-----------|-----|-------------
|
||||
rancher-latest | `helm repo add rancher-latest https://releases.rancher.com/server-charts/latest` | Adds a repository of Helm charts for the latest versions of Rancher. We recommend using this repo for testing out new Rancher builds.
|
||||
rancher-stable | `helm repo add rancher-stable https://releases.rancher.com/server-charts/stable` | Adds a repository of Helm charts for older, stable versions of Rancher. We recommend using this repo for production environments.
|
||||
<br/>
|
||||
Instructions on when to select these repos are available in [High Availability Install]({{< baseurl >}}/rancher/v2.x/en/installation/ha).
|
||||
|
||||
> **Note:** The introduction of the `rancher-latest` and `rancher-stable` Helm Chart repositories was introduced after Rancher v2.1.0, so the `rancher-stable` repository contains some Rancher versions that were never marked as `rancher/rancher:stable`. The versions of Rancher that were tagged as `rancher/rancher:stable` prior to v2.1.0 are v2.0.4, v2.0.6, v2.0.8. Post v2.1.0, all charts in the `rancher-stable` repository will correspond with any Rancher version tagged as `stable`.
|
||||
|
||||
### Helm Chart Versions
|
||||
|
||||
Up until the initial release of the Helm chart for Rancher v2.1.0, the version of the Helm chart matched the Rancher version (i.e `appVersion`).
|
||||
|
||||
Since there are times where the Helm chart will require changes without any changes to the Rancher version, we have moved to a versioning scheme using `yyyy.mm.<build-number>` for the Helm charts.
|
||||
|
||||
Run `helm search rancher` to view which Rancher version will be launched for the your Helm chart.
|
||||
|
||||
```
|
||||
NAME CHART VERSION APP VERSION DESCRIPTION
|
||||
rancher-latest/rancher 2018.10.1 v2.1.0 Install Rancher Server to manage Kubernetes clusters acro...
|
||||
```
|
||||
|
||||
### Switching to a different Helm Chart Repository
|
||||
|
||||
After installing Rancher, if you want to change which Helm chart repository to install Rancher from, you will need to follow these steps.
|
||||
|
||||
1. List the current Helm chart repositories.
|
||||
|
||||
```
|
||||
helm repo list
|
||||
|
||||
NAME URL
|
||||
stable https://kubernetes-charts.storage.googleapis.com
|
||||
rancher-<CHART_REPO> https://releases.rancher.com/server-charts/<CHART_REPO>
|
||||
```
|
||||
|
||||
2. Remove the existing Helm Chart repository that contains your charts to install Rancher, which will either be `rancher-stable` or `rancher-latest` depending on what you had initially added.
|
||||
|
||||
```
|
||||
helm repo remove rancher-<CHART_REPO>
|
||||
```
|
||||
|
||||
3. Add the Helm chart repository that you want to start installing Rancher from. Replace `<CHART_REPO>` with the chart repository that you want to use (i.e. `latest` or `stable`).
|
||||
|
||||
```
|
||||
helm repo add rancher-<CHART_REPO> https://releases.rancher.com/server-charts/<CHART_REPO>
|
||||
```
|
||||
|
||||
4. Continue to follow the steps to [upgrade Rancher]({{< baseurl >}}/rancher/v2.x/en/upgrades/upgrades/ha-server-upgrade-helm/) from the new Helm chart repository.
|
||||
|
||||
@@ -5,6 +5,8 @@ weight: 2300
|
||||
|
||||
Using the Kubernetes [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) feature (HPA), you can configure your cluster to automatically scale the services it's running up or down.
|
||||
|
||||
>**Note:** Clusters created in Rancher v2.0.7 and higher have all the requirements needed (metrics-server and Kubernetes cluster configuration) to use Horizontal Pod Autoscaler.
|
||||
|
||||
### Why Use Horizontal Pod Autoscaler?
|
||||
|
||||
Using HPA, you can automatically scale the number of pods within a replication controller, deployment, or replica set up or down. HPA automatically scales the number of pods that are running for maximum efficiency. Factors that affect the number of pods include:
|
||||
@@ -20,11 +22,10 @@ HPA improves your services by:
|
||||
|
||||
### How HPA Works
|
||||
|
||||
|
||||
|
||||
|
||||
HPA is implemented as a control loop, with a period controlled by the `kube-controller-manager` flags below:
|
||||
|
||||
|
||||
Flag | Default | Description |
|
||||
---------|----------|----------|
|
||||
`--horizontal-pod-autoscaler-sync-period` | `30s` | How often HPA audits resource/custom metrics in a deployment.
|
||||
@@ -36,13 +37,13 @@ For full documentation on HPA, refer to the [Kubernetes Documentation](https://k
|
||||
|
||||
### Horizontal Pod Autoscaler API Objects
|
||||
|
||||
HPA is an API resource in the Kubernetes `autoscaling` API group. The current stable version is `autoscaling/v1`, which only includes support for CPU autoscaling. To get additional support for scaling based on memory and custom metrics, use the beta version instead: `autoscaling/v2beta1`.
|
||||
HPA is an API resource in the Kubernetes `autoscaling` API group. The current stable version is `autoscaling/v1`, which only includes support for CPU autoscaling. To get additional support for scaling based on memory and custom metrics, use the beta version instead: `autoscaling/v2beta1`.
|
||||
|
||||
For more information about the HPA API object, see the [HPA GitHub Readme](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#horizontalpodautoscaler-object).
|
||||
|
||||
### kubectl Commands
|
||||
|
||||
You can create, manage, and delete HPAs using kubectl:
|
||||
You can create, manage, and delete HPAs using kubectl:
|
||||
|
||||
- Creating HPA
|
||||
|
||||
@@ -98,113 +99,39 @@ Directive | Description
|
||||
`targetAverageValue: 100Mi` | Indicates the deployment will scale pods up when the average running pod uses more that 100Mi of memory.
|
||||
<br/>
|
||||
|
||||
### Installation
|
||||
|
||||
Before you can use HPA in your Kubernetes cluster, you must fulfill some requirements.
|
||||
|
||||
#### Requirements
|
||||
|
||||
Be sure that your Kubernetes cluster services are running with these flags at minimum:
|
||||
|
||||
- kube-api: `requestheader-client-ca-file`
|
||||
- kubelet: `read-only-port` at 10255
|
||||
- kube-controller: Optional, just needed if distinct values than default are required.
|
||||
|
||||
- `horizontal-pod-autoscaler-downscale-delay: "5m0s"`
|
||||
- `horizontal-pod-autoscaler-upscale-delay: "3m0s"`
|
||||
- `horizontal-pod-autoscaler-sync-period: "30s"`
|
||||
|
||||
For an RKE Kubernetes cluster definition, add this snippet in the `services` section. To add this snippet using the Rancher v2.0 UI, open the **Clusters** view and select **Ellipsis (...) > Edit** for the cluster in which you want to use HPA. Then, from **Cluster Options**, click **Edit as YAML**. Add the following snippet to the `services` section:
|
||||
|
||||
```
|
||||
services:
|
||||
...
|
||||
kube-api:
|
||||
extra_args:
|
||||
requestheader-client-ca-file: "/etc/kubernetes/ssl/kube-ca.pem"
|
||||
kube-controller:
|
||||
extra_args:
|
||||
horizontal-pod-autoscaler-downscale-delay: "5m0s"
|
||||
horizontal-pod-autoscaler-upscale-delay: "1m0s"
|
||||
horizontal-pod-autoscaler-sync-period: "30s"
|
||||
kubelet:
|
||||
extra_args:
|
||||
read-only-port: 10255
|
||||
```
|
||||
|
||||
Once the Kubernetes cluster is configured and deployed, you can deploy metrics services.
|
||||
|
||||
>**Note:** kubectl command samples in the sections that follow were tested in a cluster running Rancher v2.0.6 and Kubernetes v1.10.1.
|
||||
|
||||
#### Configuring HPA to Scale Using Resource Metrics
|
||||
|
||||
To create HPA resources based on resource metrics such as CPU and memory use, you need to deploy the `metrics-server` package in the `kube-system` namespace of your Kubernetes cluster. This deployment allows HPA to consume the `metrics.k8s.io` API.
|
||||
Clusters created in Rancher v2.0.7 and higher have all the requirements needed (metrics-server and Kubernetes cluster configuration) to use Horizontal Pod Autoscaler. Run the following commands to check if metrics are available in your installation:
|
||||
|
||||
>**Prerequisite:** You must be running kubectl 1.8 or later.
|
||||
```
|
||||
$ kubectl top nodes
|
||||
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
|
||||
node-controlplane 196m 9% 1623Mi 42%
|
||||
node-etcd 80m 4% 1090Mi 28%
|
||||
node-worker 64m 3% 1146Mi 29%
|
||||
$ kubectl -n kube-system top pods
|
||||
NAME CPU(cores) MEMORY(bytes)
|
||||
canal-pgldr 18m 46Mi
|
||||
canal-vhkgr 20m 45Mi
|
||||
canal-x5q5v 17m 37Mi
|
||||
canal-xknnz 20m 37Mi
|
||||
kube-dns-7588d5b5f5-298j2 0m 22Mi
|
||||
kube-dns-autoscaler-5db9bbb766-t24hw 0m 5Mi
|
||||
metrics-server-97bc649d5-jxrlt 0m 12Mi
|
||||
$ kubectl -n kube-system logs -l k8s-app=metrics-server
|
||||
I1002 12:55:32.172841 1 heapster.go:71] /metrics-server --source=kubernetes.summary_api:https://kubernetes.default.svc?kubeletHttps=true&kubeletPort=10250&useServiceAccount=true&insecure=true
|
||||
I1002 12:55:32.172994 1 heapster.go:72] Metrics Server version v0.2.1
|
||||
I1002 12:55:32.173378 1 configs.go:61] Using Kubernetes client with master "https://kubernetes.default.svc" and version
|
||||
I1002 12:55:32.173401 1 configs.go:62] Using kubelet port 10250
|
||||
I1002 12:55:32.173946 1 heapster.go:128] Starting with Metric Sink
|
||||
I1002 12:55:32.592703 1 serving.go:308] Generated self-signed cert (apiserver.local.config/certificates/apiserver.crt, apiserver.local.config/certificates/apiserver.key)
|
||||
I1002 12:55:32.925630 1 heapster.go:101] Starting Heapster API server...
|
||||
[restful] 2018/10/02 12:55:32 log.go:33: [restful/swagger] listing is available at https:///swaggerapi
|
||||
[restful] 2018/10/02 12:55:32 log.go:33: [restful/swagger] https:///swaggerui/ is mapped to folder /swagger-ui/
|
||||
I1002 12:55:32.928597 1 serve.go:85] Serving securely on 0.0.0.0:443
|
||||
```
|
||||
|
||||
1. Connect to your Kubernetes cluster using kubectl.
|
||||
|
||||
1. Clone the GitHub `metrics-server` repo:
|
||||
```
|
||||
# git clone https://github.com/kubernetes-incubator/metrics-server
|
||||
```
|
||||
|
||||
1. Install the `metrics-server` package.
|
||||
```
|
||||
# kubectl create -f metrics-server/deploy/1.8+/
|
||||
```
|
||||
|
||||
1. Check that `metrics-server` is running properly. Check the service pod and logs in the `kube-system` namespace.
|
||||
|
||||
1. Check the service pod for a status of `running`. Enter the following command:
|
||||
```
|
||||
# kubectl get pods -n kube-system
|
||||
```
|
||||
Then check for the status of `running`.
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
...
|
||||
metrics-server-6fbfb84cdd-t2fk9 1/1 Running 0 8h
|
||||
...
|
||||
```
|
||||
1. Check the service logs for service availability. Enter the following command:
|
||||
```
|
||||
# kubectl -n kube-system logs metrics-server-6fbfb84cdd-t2fk9
|
||||
```
|
||||
Then review the log to confirm that that the `metrics-server` package is running.
|
||||
{{% accordion id="metrics-server-run-check" label="Metrics Server Log Output" %}}
|
||||
I0723 08:09:56.193136 1 heapster.go:71] /metrics-server --source=kubernetes.summary_api:''
|
||||
I0723 08:09:56.193574 1 heapster.go:72] Metrics Server version v0.2.1
|
||||
I0723 08:09:56.194480 1 configs.go:61] Using Kubernetes client with master "https://10.43.0.1:443" and version
|
||||
I0723 08:09:56.194501 1 configs.go:62] Using kubelet port 10255
|
||||
I0723 08:09:56.198612 1 heapster.go:128] Starting with Metric Sink
|
||||
I0723 08:09:56.780114 1 serving.go:308] Generated self-signed cert (apiserver.local.config/certificates/apiserver.crt, apiserver.local.config/certificates/apiserver.key)
|
||||
I0723 08:09:57.391518 1 heapster.go:101] Starting Heapster API server...
|
||||
[restful] 2018/07/23 08:09:57 log.go:33: [restful/swagger] listing is available at https:///swaggerapi
|
||||
[restful] 2018/07/23 08:09:57 log.go:33: [restful/swagger] https:///swaggerui/ is mapped to folder /swagger-ui/
|
||||
I0723 08:09:57.394080 1 serve.go:85] Serving securely on 0.0.0.0:443
|
||||
{{% /accordion %}}
|
||||
|
||||
|
||||
1. Check that the metrics api is accessible from kubectl.
|
||||
|
||||
- If you are accessing the cluster directly, enter your Server URL in the kubectl config in the following format: `https://<K8s_URL>:6443`.
|
||||
```
|
||||
# kubectl get --raw /apis/metrics.k8s.io/v1beta1
|
||||
```
|
||||
If the the API is working correctly, you should receive output similar to the output below.
|
||||
```
|
||||
{"kind":"APIResourceList","apiVersion":"v1","groupVersion":"metrics.k8s.io/v1beta1","resources":[{"name":"nodes","singularName":"","namespaced":false,"kind":"NodeMetrics","verbs":["get","list"]},{"name":"pods","singularName":"","namespaced":true,"kind":"PodMetrics","verbs":["get","list"]}]}
|
||||
```
|
||||
|
||||
- If you are accessing the cluster through Rancher, enter your Server URL in the kubectl config in the following format: `https://<RANCHER_URL>/k8s/clusters/<CLUSTER_ID>`. Add the suffix `/k8s/clusters/<CLUSTER_ID>` to API path.
|
||||
```
|
||||
# kubectl get --raw /k8s/clusters/<CLUSTER_ID>/apis/metrics.k8s.io/v1beta1
|
||||
```
|
||||
If the the API is working correctly, you should receive output similar to the output below.
|
||||
```
|
||||
{"kind":"APIResourceList","apiVersion":"v1","groupVersion":"metrics.k8s.io/v1beta1","resources":[{"name":"nodes","singularName":"","namespaced":false,"kind":"NodeMetrics","verbs":["get","list"]},{"name":"pods","singularName":"","namespaced":true,"kind":"PodMetrics","verbs":["get","list"]}]}
|
||||
```
|
||||
If you have created your cluster in Rancher v2.0.6 or before, please refer to [Manual installation](#manual-installation)
|
||||
|
||||
#### Configuring HPA to Scale Using Custom Metrics (Prometheus)
|
||||
|
||||
@@ -293,210 +220,136 @@ For HPA to use custom metrics from Prometheus, package [k8s-prometheus-adapter](
|
||||
{{% /accordion %}}
|
||||
|
||||
|
||||
#### Assigning Additional Required Roles to Your HPA
|
||||
|
||||
By default, HPA reads resource and custom metrics with the user `system:anonymous`. Assign `system:anonymous` the the `view-resource-metrics` and `view-custom-metrics` in the ClusterRole and ClusterRoleBindings manifests. These roles are used to access metrics.
|
||||
|
||||
To do it, follow these steps:
|
||||
|
||||
1. Configure kubectl to connect to your cluster.
|
||||
|
||||
1. Copy the ClusterRole and ClusterRoleBinding manifest for the type of metrics you're using for your HPA.
|
||||
{{% accordion id="cluster-role-resource-metrics" label="Resource Metrics: ApiGroups resource.metrics.k8s.io" %}}
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
metadata:
|
||||
name: view-resource-metrics
|
||||
rules:
|
||||
- apiGroups:
|
||||
- metrics.k8s.io
|
||||
resources:
|
||||
- pods
|
||||
- nodes
|
||||
verbs:
|
||||
- get
|
||||
- list
|
||||
- watch
|
||||
---
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRoleBinding
|
||||
metadata:
|
||||
name: view-resource-metrics
|
||||
roleRef:
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
kind: ClusterRole
|
||||
name: view-resource-metrics
|
||||
subjects:
|
||||
- apiGroup: rbac.authorization.k8s.io
|
||||
kind: User
|
||||
name: system:anonymous
|
||||
{{% /accordion %}}
|
||||
{{% accordion id="cluster-role-custom-resources" label="Custom Metrics: ApiGroups custom.metrics.k8s.io" %}}
|
||||
|
||||
```
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
metadata:
|
||||
name: view-custom-metrics
|
||||
rules:
|
||||
- apiGroups:
|
||||
- custom.metrics.k8s.io
|
||||
resources:
|
||||
- "*"
|
||||
verbs:
|
||||
- get
|
||||
- list
|
||||
- watch
|
||||
---
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRoleBinding
|
||||
metadata:
|
||||
name: view-custom-metrics
|
||||
roleRef:
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
kind: ClusterRole
|
||||
name: view-custom-metrics
|
||||
subjects:
|
||||
- apiGroup: rbac.authorization.k8s.io
|
||||
kind: User
|
||||
name: system:anonymous
|
||||
```
|
||||
{{% /accordion %}}
|
||||
1. Create them in your cluster using one of the follow commands, depending on the metrics you're using.
|
||||
```
|
||||
# kubectl create -f <RESOURCE_METRICS_MANIFEST>
|
||||
# kubectl create -f <CUSTOM_METRICS_MANIFEST>
|
||||
```
|
||||
|
||||
|
||||
### Testing HPAs with a Service Deployment
|
||||
|
||||
For HPA to work correctly, service deployments should have resources request definitions for containers. Follow this hello-world example to test if HPA is working correctly.
|
||||
For HPA to work correctly, service deployments should have resources request definitions for containers. Follow this hello-world example to test if HPA is working correctly.
|
||||
|
||||
1. Configure kubectl to connect to your Kubernetes cluster.
|
||||
|
||||
2. Copy the `hello-world` deployment manifest below.
|
||||
{{% accordion id="hello-world" label="Hello World Manifest" %}}
|
||||
apiVersion: apps/v1beta2
|
||||
kind: Deployment
|
||||
metadata:
|
||||
labels:
|
||||
app: hello-world
|
||||
name: hello-world
|
||||
namespace: default
|
||||
spec:
|
||||
replicas: 1
|
||||
selector:
|
||||
matchLabels:
|
||||
app: hello-world
|
||||
strategy:
|
||||
rollingUpdate:
|
||||
maxSurge: 1
|
||||
maxUnavailable: 0
|
||||
type: RollingUpdate
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: hello-world
|
||||
spec:
|
||||
containers:
|
||||
- image: rancher/hello-world
|
||||
imagePullPolicy: Always
|
||||
name: hello-world
|
||||
resources:
|
||||
requests:
|
||||
cpu: 500m
|
||||
memory: 64Mi
|
||||
ports:
|
||||
- containerPort: 80
|
||||
protocol: TCP
|
||||
restartPolicy: Always
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: hello-world
|
||||
namespace: default
|
||||
spec:
|
||||
ports:
|
||||
- port: 80
|
||||
protocol: TCP
|
||||
targetPort: 80
|
||||
selector:
|
||||
app: hello-world
|
||||
```
|
||||
apiVersion: apps/v1beta2
|
||||
kind: Deployment
|
||||
metadata:
|
||||
labels:
|
||||
app: hello-world
|
||||
name: hello-world
|
||||
namespace: default
|
||||
spec:
|
||||
replicas: 1
|
||||
selector:
|
||||
matchLabels:
|
||||
app: hello-world
|
||||
strategy:
|
||||
rollingUpdate:
|
||||
maxSurge: 1
|
||||
maxUnavailable: 0
|
||||
type: RollingUpdate
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: hello-world
|
||||
spec:
|
||||
containers:
|
||||
- image: rancher/hello-world
|
||||
imagePullPolicy: Always
|
||||
name: hello-world
|
||||
resources:
|
||||
requests:
|
||||
cpu: 500m
|
||||
memory: 64Mi
|
||||
ports:
|
||||
- containerPort: 80
|
||||
protocol: TCP
|
||||
restartPolicy: Always
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: hello-world
|
||||
namespace: default
|
||||
spec:
|
||||
ports:
|
||||
- port: 80
|
||||
protocol: TCP
|
||||
targetPort: 80
|
||||
selector:
|
||||
app: hello-world
|
||||
```
|
||||
{{% /accordion %}}
|
||||
|
||||
|
||||
|
||||
1. Deploy it to your cluster.
|
||||
|
||||
```
|
||||
# kubectl create -f <HELLO_WORLD_MANIFEST>
|
||||
```
|
||||
|
||||
1. Copy one of the HPAs below based on the metric type you're using:
|
||||
{{% accordion id="service-deployment-resource-metrics" label="Hello World HPA: Resource Metrics" %}}
|
||||
apiVersion: autoscaling/v2beta1
|
||||
kind: HorizontalPodAutoscaler
|
||||
metadata:
|
||||
name: hello-world
|
||||
namespace: default
|
||||
spec:
|
||||
scaleTargetRef:
|
||||
apiVersion: extensions/v1beta1
|
||||
kind: Deployment
|
||||
name: hello-world
|
||||
minReplicas: 1
|
||||
maxReplicas: 10
|
||||
metrics:
|
||||
- type: Resource
|
||||
resource:
|
||||
name: cpu
|
||||
targetAverageUtilization: 50
|
||||
- type: Resource
|
||||
resource:
|
||||
name: memory
|
||||
targetAverageValue: 1000Mi
|
||||
{{% /accordion %}}
|
||||
{{% accordion id="service-deployment-custom-metrics" label="Hello World HPA: Custom Metrics" %}}
|
||||
apiVersion: autoscaling/v2beta1
|
||||
kind: HorizontalPodAutoscaler
|
||||
metadata:
|
||||
name: hello-world
|
||||
namespace: default
|
||||
spec:
|
||||
scaleTargetRef:
|
||||
apiVersion: extensions/v1beta1
|
||||
kind: Deployment
|
||||
name: hello-world
|
||||
minReplicas: 1
|
||||
maxReplicas: 10
|
||||
metrics:
|
||||
- type: Resource
|
||||
resource:
|
||||
name: cpu
|
||||
targetAverageUtilization: 50
|
||||
- type: Resource
|
||||
resource:
|
||||
name: memory
|
||||
targetAverageValue: 100Mi
|
||||
- type: Pods
|
||||
pods:
|
||||
metricName: cpu_system
|
||||
targetAverageValue: 20m
|
||||
{{% /accordion %}}
|
||||
1. Copy one of the HPAs below based on the metric type you're using:
|
||||
{{% accordion id="service-deployment-resource-metrics" label="Hello World HPA: Resource Metrics" %}}
|
||||
```
|
||||
apiVersion: autoscaling/v2beta1
|
||||
kind: HorizontalPodAutoscaler
|
||||
metadata:
|
||||
name: hello-world
|
||||
namespace: default
|
||||
spec:
|
||||
scaleTargetRef:
|
||||
apiVersion: extensions/v1beta1
|
||||
kind: Deployment
|
||||
name: hello-world
|
||||
minReplicas: 1
|
||||
maxReplicas: 10
|
||||
metrics:
|
||||
- type: Resource
|
||||
resource:
|
||||
name: cpu
|
||||
targetAverageUtilization: 50
|
||||
- type: Resource
|
||||
resource:
|
||||
name: memory
|
||||
targetAverageValue: 1000Mi
|
||||
```
|
||||
{{% /accordion %}}
|
||||
{{% accordion id="service-deployment-custom-metrics" label="Hello World HPA: Custom Metrics" %}}
|
||||
```
|
||||
apiVersion: autoscaling/v2beta1
|
||||
kind: HorizontalPodAutoscaler
|
||||
metadata:
|
||||
name: hello-world
|
||||
namespace: default
|
||||
spec:
|
||||
scaleTargetRef:
|
||||
apiVersion: extensions/v1beta1
|
||||
kind: Deployment
|
||||
name: hello-world
|
||||
minReplicas: 1
|
||||
maxReplicas: 10
|
||||
metrics:
|
||||
- type: Resource
|
||||
resource:
|
||||
name: cpu
|
||||
targetAverageUtilization: 50
|
||||
- type: Resource
|
||||
resource:
|
||||
name: memory
|
||||
targetAverageValue: 100Mi
|
||||
- type: Pods
|
||||
pods:
|
||||
metricName: cpu_system
|
||||
targetAverageValue: 20m
|
||||
```
|
||||
{{% /accordion %}}
|
||||
|
||||
1. View the HPA info and description. Confirm that metric data is shown.
|
||||
{{% accordion id="hpa-info-resource-metrics" label="Resource Metrics" %}}
|
||||
1. Enter the following command.
|
||||
1. Enter the following commands.
|
||||
```
|
||||
# kubectl get hpa
|
||||
```
|
||||
You should receive the output that follows:
|
||||
```
|
||||
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
|
||||
hello-world Deployment/hello-world 1253376 / 100Mi, 0% / 50% 1 10 1 6m
|
||||
# kubectl describe hpa
|
||||
# kubectl describe hpa
|
||||
Name: hello-world
|
||||
Namespace: default
|
||||
Labels: <none>
|
||||
@@ -552,7 +405,7 @@ For HPA to work correctly, service deployments should have resources request def
|
||||
1. Test that pod autoscaling works as intended.<br/></br>
|
||||
**To Test Autoscaling Using Resource Metrics:**
|
||||
{{% accordion id="observe-upscale-2-pods-cpu" label="Upscale to 2 Pods: CPU Usage Up to Target" %}}
|
||||
Use your load testing tool to to scale up to two pods based on CPU Usage.
|
||||
Use your load testing tool to to scale up to two pods based on CPU Usage.
|
||||
|
||||
1. View your HPA.
|
||||
```
|
||||
@@ -671,7 +524,7 @@ Use your load testing to to scale down to 1 pod when all metrics are below targe
|
||||
Normal SuccessfulRescale 1s horizontal-pod-autoscaler New size: 1; reason: All metrics below target
|
||||
```
|
||||
{{% /accordion %}}
|
||||
<br/>
|
||||
<br/>
|
||||
**To Test Autoscaling Using Custom Metrics:**
|
||||
{{% accordion id="custom-observe-upscale-2-pods-cpu" label="Upscale to 2 Pods: CPU Usage Up to Target" %}}
|
||||
Use your load testing tool to upscale two pods based on CPU usage.
|
||||
@@ -855,6 +708,8 @@ Use your load testing tool to scale down to one pod when all metrics below targe
|
||||
```
|
||||
{{% /accordion %}}
|
||||
|
||||
|
||||
|
||||
### Conclusion
|
||||
|
||||
Horizontal Pod Autoscaling is a great way to automate the number of pod you have deployed for maximum efficiency. You can use it to accommodate deployment scale to real service load and to meet service level agreements.
|
||||
@@ -863,4 +718,190 @@ By adjusting the `horizontal-pod-autoscaler-downscale-delay` and `horizontal-pod
|
||||
|
||||
We've demonstrated how to setup an HPA based on custom metrics provided by Prometheus. We used the `cpu_system` metric as an example, but you can use other metrics that monitor service performance, like `http_request_number`, `http_response_time`, etc.
|
||||
|
||||
>**Note:**To facilitate HPA use, we are working to integrate metric-server as an addon on RKE cluster deployments. This feature is included in RKE v0.1.9-rc2 for testing, but is not officially supported as of yet. It would be supported at rke v0.1.9.
|
||||
|
||||
### Manual Installation
|
||||
|
||||
>**Note:** This is only applicable to clusters created in versions before Rancher v2.0.7.
|
||||
|
||||
Before you can use HPA in your Kubernetes cluster, you must fulfill some requirements.
|
||||
|
||||
#### Requirements
|
||||
|
||||
Be sure that your Kubernetes cluster services are running with these flags at minimum:
|
||||
|
||||
- kube-api: `requestheader-client-ca-file`
|
||||
- kubelet: `read-only-port` at 10255
|
||||
- kube-controller: Optional, just needed if distinct values than default are required.
|
||||
|
||||
- `horizontal-pod-autoscaler-downscale-delay: "5m0s"`
|
||||
- `horizontal-pod-autoscaler-upscale-delay: "3m0s"`
|
||||
- `horizontal-pod-autoscaler-sync-period: "30s"`
|
||||
|
||||
For an RKE Kubernetes cluster definition, add this snippet in the `services` section. To add this snippet using the Rancher v2.0 UI, open the **Clusters** view and select **Ellipsis (...) > Edit** for the cluster in which you want to use HPA. Then, from **Cluster Options**, click **Edit as YAML**. Add the following snippet to the `services` section:
|
||||
|
||||
```
|
||||
services:
|
||||
...
|
||||
kube-api:
|
||||
extra_args:
|
||||
requestheader-client-ca-file: "/etc/kubernetes/ssl/kube-ca.pem"
|
||||
kube-controller:
|
||||
extra_args:
|
||||
horizontal-pod-autoscaler-downscale-delay: "5m0s"
|
||||
horizontal-pod-autoscaler-upscale-delay: "1m0s"
|
||||
horizontal-pod-autoscaler-sync-period: "30s"
|
||||
kubelet:
|
||||
extra_args:
|
||||
read-only-port: 10255
|
||||
```
|
||||
|
||||
Once the Kubernetes cluster is configured and deployed, you can deploy metrics services.
|
||||
|
||||
>**Note:** kubectl command samples in the sections that follow were tested in a cluster running Rancher v2.0.6 and Kubernetes v1.10.1.
|
||||
|
||||
#### Configuring HPA to Scale Using Resource Metrics
|
||||
|
||||
To create HPA resources based on resource metrics such as CPU and memory use, you need to deploy the `metrics-server` package in the `kube-system` namespace of your Kubernetes cluster. This deployment allows HPA to consume the `metrics.k8s.io` API.
|
||||
|
||||
>**Prerequisite:** You must be running kubectl 1.8 or later.
|
||||
|
||||
1. Connect to your Kubernetes cluster using kubectl.
|
||||
|
||||
1. Clone the GitHub `metrics-server` repo:
|
||||
```
|
||||
# git clone https://github.com/kubernetes-incubator/metrics-server
|
||||
```
|
||||
|
||||
1. Install the `metrics-server` package.
|
||||
```
|
||||
# kubectl create -f metrics-server/deploy/1.8+/
|
||||
```
|
||||
|
||||
1. Check that `metrics-server` is running properly. Check the service pod and logs in the `kube-system` namespace.
|
||||
|
||||
1. Check the service pod for a status of `running`. Enter the following command:
|
||||
```
|
||||
# kubectl get pods -n kube-system
|
||||
```
|
||||
Then check for the status of `running`.
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
...
|
||||
metrics-server-6fbfb84cdd-t2fk9 1/1 Running 0 8h
|
||||
...
|
||||
```
|
||||
1. Check the service logs for service availability. Enter the following command:
|
||||
```
|
||||
# kubectl -n kube-system logs metrics-server-6fbfb84cdd-t2fk9
|
||||
```
|
||||
Then review the log to confirm that that the `metrics-server` package is running.
|
||||
{{% accordion id="metrics-server-run-check" label="Metrics Server Log Output" %}}
|
||||
I0723 08:09:56.193136 1 heapster.go:71] /metrics-server --source=kubernetes.summary_api:''
|
||||
I0723 08:09:56.193574 1 heapster.go:72] Metrics Server version v0.2.1
|
||||
I0723 08:09:56.194480 1 configs.go:61] Using Kubernetes client with master "https://10.43.0.1:443" and version
|
||||
I0723 08:09:56.194501 1 configs.go:62] Using kubelet port 10255
|
||||
I0723 08:09:56.198612 1 heapster.go:128] Starting with Metric Sink
|
||||
I0723 08:09:56.780114 1 serving.go:308] Generated self-signed cert (apiserver.local.config/certificates/apiserver.crt, apiserver.local.config/certificates/apiserver.key)
|
||||
I0723 08:09:57.391518 1 heapster.go:101] Starting Heapster API server...
|
||||
[restful] 2018/07/23 08:09:57 log.go:33: [restful/swagger] listing is available at https:///swaggerapi
|
||||
[restful] 2018/07/23 08:09:57 log.go:33: [restful/swagger] https:///swaggerui/ is mapped to folder /swagger-ui/
|
||||
I0723 08:09:57.394080 1 serve.go:85] Serving securely on 0.0.0.0:443
|
||||
{{% /accordion %}}
|
||||
|
||||
|
||||
1. Check that the metrics api is accessible from kubectl.
|
||||
|
||||
|
||||
- If you are accessing the cluster through Rancher, enter your Server URL in the kubectl config in the following format: `https://<RANCHER_URL>/k8s/clusters/<CLUSTER_ID>`. Add the suffix `/k8s/clusters/<CLUSTER_ID>` to API path.
|
||||
```
|
||||
# kubectl get --raw /k8s/clusters/<CLUSTER_ID>/apis/metrics.k8s.io/v1beta1
|
||||
```
|
||||
If the the API is working correctly, you should receive output similar to the output below.
|
||||
```
|
||||
{"kind":"APIResourceList","apiVersion":"v1","groupVersion":"metrics.k8s.io/v1beta1","resources":[{"name":"nodes","singularName":"","namespaced":false,"kind":"NodeMetrics","verbs":["get","list"]},{"name":"pods","singularName":"","namespaced":true,"kind":"PodMetrics","verbs":["get","list"]}]}
|
||||
```
|
||||
|
||||
- If you are accessing the cluster directly, enter your Server URL in the kubectl config in the following format: `https://<K8s_URL>:6443`.
|
||||
```
|
||||
# kubectl get --raw /apis/metrics.k8s.io/v1beta1
|
||||
```
|
||||
If the the API is working correctly, you should receive output similar to the output below.
|
||||
```
|
||||
{"kind":"APIResourceList","apiVersion":"v1","groupVersion":"metrics.k8s.io/v1beta1","resources":[{"name":"nodes","singularName":"","namespaced":false,"kind":"NodeMetrics","verbs":["get","list"]},{"name":"pods","singularName":"","namespaced":true,"kind":"PodMetrics","verbs":["get","list"]}]}
|
||||
```
|
||||
|
||||
#### Assigning Additional Required Roles to Your HPA
|
||||
|
||||
By default, HPA reads resource and custom metrics with the user `system:anonymous`. Assign `system:anonymous` to `view-resource-metrics` and `view-custom-metrics` in the ClusterRole and ClusterRoleBindings manifests. These roles are used to access metrics.
|
||||
|
||||
To do it, follow these steps:
|
||||
|
||||
1. Configure kubectl to connect to your cluster.
|
||||
|
||||
1. Copy the ClusterRole and ClusterRoleBinding manifest for the type of metrics you're using for your HPA.
|
||||
{{% accordion id="cluster-role-resource-metrics" label="Resource Metrics: ApiGroups resource.metrics.k8s.io" %}}
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
metadata:
|
||||
name: view-resource-metrics
|
||||
rules:
|
||||
- apiGroups:
|
||||
- metrics.k8s.io
|
||||
resources:
|
||||
- pods
|
||||
- nodes
|
||||
verbs:
|
||||
- get
|
||||
- list
|
||||
- watch
|
||||
---
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRoleBinding
|
||||
metadata:
|
||||
name: view-resource-metrics
|
||||
roleRef:
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
kind: ClusterRole
|
||||
name: view-resource-metrics
|
||||
subjects:
|
||||
- apiGroup: rbac.authorization.k8s.io
|
||||
kind: User
|
||||
name: system:anonymous
|
||||
{{% /accordion %}}
|
||||
{{% accordion id="cluster-role-custom-resources" label="Custom Metrics: ApiGroups custom.metrics.k8s.io" %}}
|
||||
|
||||
```
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
metadata:
|
||||
name: view-custom-metrics
|
||||
rules:
|
||||
- apiGroups:
|
||||
- custom.metrics.k8s.io
|
||||
resources:
|
||||
- "*"
|
||||
verbs:
|
||||
- get
|
||||
- list
|
||||
- watch
|
||||
---
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRoleBinding
|
||||
metadata:
|
||||
name: view-custom-metrics
|
||||
roleRef:
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
kind: ClusterRole
|
||||
name: view-custom-metrics
|
||||
subjects:
|
||||
- apiGroup: rbac.authorization.k8s.io
|
||||
kind: User
|
||||
name: system:anonymous
|
||||
```
|
||||
{{% /accordion %}}
|
||||
1. Create them in your cluster using one of the follow commands, depending on the metrics you're using.
|
||||
```
|
||||
# kubectl create -f <RESOURCE_METRICS_MANIFEST>
|
||||
# kubectl create -f <CUSTOM_METRICS_MANIFEST>
|
||||
```
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -15,7 +15,7 @@ To manage individual nodes, browse to the cluster that you want to manage and th
|
||||
|
||||
The following table lists which node options are available for each [type of cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#cluster-creation-options) in Rancher. Click the links in the **Option** column for more detailed information about each feature.
|
||||
|
||||
| Option | [Node Pool][1] | [Custom Node][2] | [Hosted Cluster][3] | [Imported Nodes][4] | Description |
|
||||
| Option | [Nodes Hosted by an Infrastructure Provider][1] | [Custom Node][2] | [Hosted Cluster][3] | [Imported Nodes][4] | Description |
|
||||
| ------------------------------------------------ | ------------------------------------------------ | ---------------- | ------------------- | ------------------- | ------------------------------------------------------------------ |
|
||||
| [Cordon](#cordoning-a-node) | ✓ | ✓ | ✓ | | Marks the node as unschedulable. |
|
||||
| [Drain](#draining-a-node) | ✓ | ✓ | ✓ | | Marks the node as unschedulable _and_ evicts all pods. |
|
||||
@@ -96,22 +96,22 @@ Select this option to view the node's [API endpoints]({{< baseurl >}}/rancher/v2
|
||||
|
||||
Use **Delete** to remove defective nodes from the cloud provider. When you the delete a defective node, Rancher automatically replaces it with an identically provisioned node.
|
||||
|
||||
>**Tip:** If your cluster is hosted on IaaS nodes, and you want to scale your cluster down instead of deleting a defective node, [scale down](#scaling-nodes) rather than delete.
|
||||
>**Tip:** If your cluster is hosted by an infrastructure provider, and you want to scale your cluster down instead of deleting a defective node, [scale down](#scaling-nodes) rather than delete.
|
||||
|
||||
|
||||
## Scaling Nodes
|
||||
|
||||
For nodes hosted by an IaaS, you can scale the number of nodes in each node pool by using the scale controls. This option isn't available for other cluster types.
|
||||
For nodes hosted by an infrastructure provider, you can scale the number of nodes in each node pool by using the scale controls. This option isn't available for other cluster types.
|
||||
|
||||
|
||||
|
||||
|
||||
## Remoting into a Node Pool Node
|
||||
## Remoting into a Node Hosted by an Infrastructure Provider
|
||||
|
||||
For [nodes hosted by an IaaS]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/), you have the option of downloading its SSH key so that you can connect to it remotely from your desktop.
|
||||
For [nodes hosted by an infrastructure provider]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/), you have the option of downloading its SSH key so that you can connect to it remotely from your desktop.
|
||||
|
||||
|
||||
1. From the Node Pool cluster, select **Nodes** from the main menu.
|
||||
1. From the cluster hosted by an infrastructure provider, select **Nodes** from the main menu.
|
||||
|
||||
1. Find the node that you want to remote into. Select **Ellipsis (...) > Download Keys**.
|
||||
|
||||
|
||||
@@ -70,9 +70,9 @@ There are several types of services available in Rancher. The descriptions below
|
||||
|
||||
This section of the documentation contains instructions for deploying workloads and using workload options.
|
||||
|
||||
- [Deploy Workloads]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/workloads/deploy-workloads/)
|
||||
- [Upgrade Workloads]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/workloads/upgrade-workloads/)
|
||||
- [Rollback Workloads]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/workloads/rollback-workloads/)
|
||||
- [Deploy Workloads]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/workloads/deploy-workloads/)
|
||||
- [Upgrade Workloads]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/workloads/upgrade-workloads/)
|
||||
- [Rollback Workloads]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/workloads/rollback-workloads/)
|
||||
|
||||
## Related Links
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@ aliases:
|
||||
>**Notes:**
|
||||
>
|
||||
>- Pipelines are new and improved for Rancher v2.1! Therefore, if you configured pipelines while using v2.0.x, you'll have to reconfigure them after upgrading to v2.1.
|
||||
>- Still using v2.0.x? See the pipeline documentation for [previous versions](/rancher/v2.x/en/tools/pipelines/docs-for-v2.0.x).
|
||||
>- Still using v2.0.x? See the pipeline documentation for [previous versions]({{< baseurl >}}/rancher/v2.x/en/tools/pipelines/docs-for-v2.0.x).
|
||||
|
||||
A _pipeline_ is a software delivery process that is broken into different stages, allowing developers to deliver new software as quickly and efficiently as possible. Within Rancher, you can configure a pipeline for each of your Rancher projects.
|
||||
|
||||
@@ -73,7 +73,7 @@ When you configure a pipeline in one of your projects, a namespace specifically
|
||||
|
||||
Minio storage is used to store the logs for pipeline executions.
|
||||
|
||||
>**Note:** The managed Jenkins instance works statelessly, so don't worry about its data persistency. The Docker Registry and Minio instances use ephemeral volumes by default, which is fine for most use cases. If you want to make sure pipeline logs can survive node failures, you can configure persistent volumes for them, as described in [data persistency for pipeline components](/rancher/v2.x/en/tools/pipelines/configurations/#data-persistency-for-pipeline-components).
|
||||
>**Note:** The managed Jenkins instance works statelessly, so don't worry about its data persistency. The Docker Registry and Minio instances use ephemeral volumes by default, which is fine for most use cases. If you want to make sure pipeline logs can survive node failures, you can configure persistent volumes for them, as described in [data persistency for pipeline components]({{< baseurl >}}/rancher/v2.x/en/tools/pipelines/configurations/#data-persistency-for-pipeline-components).
|
||||
|
||||
|
||||
## Pipeline Triggers
|
||||
|
||||
@@ -71,7 +71,9 @@ Select your provider's tab below and follow the directions.
|
||||
|
||||
1. Enable the repository for which you want to run a pipeline. Then click **Done**.
|
||||
|
||||
>**Note:** If you use GitLab and your Rancher setup is in a local network, enable the **Allow requests to the local network from hooks and services** option in GitLab admin settings.
|
||||
>**Note:**
|
||||
> 1. Pipeline uses Gitlab [v4 API](https://docs.gitlab.com/ee/api/v3_to_v4.html) and the supported Gitlab version is 9.0+.
|
||||
> 2. If you use GitLab 10.7+ and your Rancher setup is in a local network, enable the **Allow requests to the local network from hooks and services** option in GitLab admin settings.
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
|
||||
@@ -108,7 +110,7 @@ The first stage is preserved to be a cloning step that checks out source code fr
|
||||
{{% /accordion %}}
|
||||
{{% accordion id="run-script" label="Run Script" %}}
|
||||
|
||||
The **Run Script** step executes arbitrary commands in the workspace inside a specified container. You can use it to build, test and do more, given whatever utilities the base image provides. For your convenience you can use variables to refer to metadata of a pipeline execution. Please go to [reference page](/rancher/v2.x/en/tools/pipelines/reference/#variable-substitution) for the list of available variables.
|
||||
The **Run Script** step executes arbitrary commands in the workspace inside a specified container. You can use it to build, test and do more, given whatever utilities the base image provides. For your convenience you can use variables to refer to metadata of a pipeline execution. Please go to the [Pipeline Variable Reference]({{< baseurl >}}/rancher/v2.x/en/tools/pipelines/reference/#variable-substitution) for the list of available variables.
|
||||
|
||||
{{% tabs %}}
|
||||
|
||||
@@ -225,7 +227,7 @@ stages:
|
||||
|
||||
Run your pipeline for the first time. From the **Pipeline** tab, find your pipeline and select **Ellipsis (...) > Run**.
|
||||
|
||||
During this initial run, your pipeline is tested, and the following [pipeline components](/Users/markbishop/Documents/GitHub/docs/content/rancher/v2.x/en/tools/pipelines/#how-pipelines-work) are deployed to your project as workloads in a new namespace dedicated to the pipeline:
|
||||
During this initial run, your pipeline is tested, and the following [pipeline components]({{< baseurl >}}/rancher/v2.x/en/tools/pipelines/) are deployed to your project as workloads in a new namespace dedicated to the pipeline:
|
||||
|
||||
- `docker-registry`
|
||||
- `jenkins`
|
||||
@@ -235,7 +237,7 @@ This process takes several minutes. When it completes, you can view each pipelin
|
||||
|
||||
### 4. Configuring Persistent Data for Pipeline Components
|
||||
|
||||
The internal [Docker registry]({{< baseurl >}}/rancher/v2.x/en/tools/pipelines/#reg) and the [Minio]({{< baseurl >}}/rancher/v2.x/en/tools/pipelines/#minio) wokrloads use ephemeral volumes by default. This default storage works out-of-the-box and makes testing easy, but you lose the build images and build logs if the node running the Docker Registry or Minio fails. In most cases this is fine. If you want build images and logs to survive node failures, you can configure the Docker Registry and Minio to use persistent volumes.
|
||||
The internal [Docker registry]({{< baseurl >}}/rancher/v2.x/en/tools/pipelines/#reg) and the [Minio]({{< baseurl >}}/rancher/v2.x/en/tools/pipelines/#minio) workloads use ephemeral volumes by default. This default storage works out-of-the-box and makes testing easy, but you lose the build images and build logs if the node running the Docker Registry or Minio fails. In most cases this is fine. If you want build images and logs to survive node failures, you can configure the Docker Registry and Minio to use persistent volumes.
|
||||
|
||||
Complete both [A—Configuring Persistent Data for Docker Registry](#a—configuring-persistent-data-for-docker-registry) _and_ [B—Configuring Persistent Data for Minio](#b—configuring-persistent-data-for-minio).
|
||||
|
||||
|
||||
@@ -3,7 +3,7 @@ title: v2.0.x Pipeline Documentation
|
||||
weight: 9000
|
||||
---
|
||||
|
||||
>**Note:** This section describes the pipeline feature as implemented in Rancher v2.0.x. If you are using Rancher v2.1 or later, where pipelines have been significantly improved, please refer to the new documentation for [v2.1 or later](/rancher/v2.x/en/tools/pipelines).
|
||||
>**Note:** This section describes the pipeline feature as implemented in Rancher v2.0.x. If you are using Rancher v2.1 or later, where pipelines have been significantly improved, please refer to the new documentation for [v2.1 or later]({{< baseurl >}}/rancher/v2.x/en/tools/pipelines).
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -12,4 +12,4 @@ To restore Rancher follow the procedure detailed here: [Restoring Backups — Hi
|
||||
|
||||
Restoring a snapshot of the Rancher Server cluster will revert Rancher to the version and state at the time of the snapshot.
|
||||
|
||||
> **Note:** Managed cluster are authoritative for their state. This means restoring the rancher server will not revert workload deployments or changes made on managed clusters after the snapshot was taken.
|
||||
>**Note:** Managed cluster are authoritative for their state. This means restoring the rancher server will not revert workload deployments or changes made on managed clusters after the snapshot was taken.
|
||||
|
||||
@@ -15,12 +15,8 @@ This section contains information about how to upgrade your Rancher server to a
|
||||
- [Upgrade a Air Gap HA Install]({{< baseurl >}}/rancher/v2.x/en/upgrades/upgrades/ha-server-upgrade-helm-airgap/)
|
||||
- [Migrating from an RKE Add-on Install]({{< baseurl >}}/rancher/v2.x/en/upgrades/upgrades/migrating-from-rke-add-on/)
|
||||
|
||||
### Upgrading an RKE Add-on Install
|
||||
|
||||
> #### **Important: RKE add-on install is only supported up to Rancher v2.0.8**
|
||||
>
|
||||
>Please use the Rancher helm chart to install HA Rancher. For details, see the [HA Install - Installation Outline]({{< baseurl >}}/rancher/v2.x/en/installation/ha/#installation-outline).
|
||||
>
|
||||
>If you are currently using the RKE add-on install method, see [Migrating from an HA RKE Add-on Install]({{< baseurl >}}/rancher/v2.x/en/upgrades/upgrades/migrating-from-rke-add-on/) for details on how to move to using the helm chart.
|
||||
|
||||
- [Upgrading a High Availability Install - RKE Add-On Install]({{< baseurl >}}/rancher/v2.x/en/upgrades/upgrades/ha-server-upgrade/)
|
||||
>If you are currently using the RKE add-on install method, see [Migrating from a RKE add-on install]({{< baseurl >}}/rancher/v2.x/en/upgrades/upgrades/migrating-from-rke-add-on/) for details on how to move to using the helm chart.
|
||||
|
||||
@@ -24,18 +24,8 @@ 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.
|
||||
|
||||
## Chart Versioning Notes
|
||||
|
||||
Up until the initial helm chart release for v2.1.0, the helm chart version matched the Rancher version (i.e `appVersion`).
|
||||
|
||||
Since there are times where the helm chart will require changes without any changes to the Rancher version, we have moved to a `yyyy.mm.<build-number>` helm chart version.
|
||||
|
||||
Run `helm search rancher` to view which Rancher version will be launched for the specific helm chart version.
|
||||
|
||||
```
|
||||
NAME CHART VERSION APP VERSION DESCRIPTION
|
||||
rancher-stable/rancher 2018.10.1 v2.1.0 Install Rancher Server to manage Kubernetes clusters acro...
|
||||
```
|
||||
- **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
|
||||
|
||||
@@ -45,17 +35,31 @@ rancher-stable/rancher 2018.10.1 v2.1.0 Install Rancher Serve
|
||||
helm repo update
|
||||
```
|
||||
|
||||
1. Fetch the latest `rancher-stable/rancher` chart.
|
||||
2. Get the [repository name that you installed Rancher]({{< baseurl >}}/rancher/v2.x/en/installation/server-tags/#helm-chart-repositories) with.
|
||||
|
||||
This will pull down the chart and save it in the current directory as a `.tgz` file.
|
||||
```
|
||||
helm repo list
|
||||
|
||||
```plain
|
||||
helm fetch rancher-stable/rancher
|
||||
NAME URL
|
||||
stable https://kubernetes-charts.storage.googleapis.com
|
||||
rancher-<CHART_REPO> https://releases.rancher.com/server-charts/<CHART_REPO>
|
||||
```
|
||||
|
||||
1. Render the upgrade template.
|
||||
> **Note:** If you want to switch to a different Helm chart repository, please follow the [steps on how to switch repositories]({{< baseurl >}}/rancher/v2.x/en/installation/server-tags/#switching-to-a-different-helm-chart-repository). If you switch repositories, make sure to list the repositories again before continuing onto Step 3 to ensure you have the correct one added.
|
||||
|
||||
Use the same `--set` values you used for the install. Remember to set the `--is-upgrade` flag for `helm`. This will create a `rancher` directory with the Kubernetes manifest files.
|
||||
|
||||
3. Fetch the latest chart to install Rancher from the Helm chart repository.
|
||||
|
||||
This command will pull down the latest chart and save it in the current directory as a `.tgz` file. Replace `<CHART_REPO>` with the name of the repository name that was listed (i.e. `latest` or `stable`).
|
||||
|
||||
|
||||
```plain
|
||||
helm fetch rancher-<CHART_REPO>/rancher
|
||||
```
|
||||
|
||||
3. Render the upgrade template.
|
||||
|
||||
Use the same `--set` values that you used for the install. Remember to set the `--is-upgrade` flag for `helm`. This will create a `rancher` directory with the Kubernetes manifest files.
|
||||
|
||||
```plain
|
||||
helm template ./rancher-<version>.tgz --output-dir . --is-upgrade \
|
||||
@@ -64,7 +68,7 @@ rancher-stable/rancher 2018.10.1 v2.1.0 Install Rancher Serve
|
||||
--set rancherImage=<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher
|
||||
```
|
||||
|
||||
1. Copy and apply the rendered manifests.
|
||||
4. Copy and apply the rendered manifests.
|
||||
|
||||
Copy the files to a server with access to the Rancher server cluster and apply the rendered templates.
|
||||
|
||||
@@ -72,6 +76,12 @@ rancher-stable/rancher 2018.10.1 v2.1.0 Install Rancher Serve
|
||||
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.
|
||||
|
||||
@@ -10,10 +10,7 @@ The following instructions will guide you through upgrading a high-availability
|
||||
>* [Migrating from RKE Add-On Install]({{< baseurl >}}/rancher/v2.x/en/upgrades/upgrades/migrating-from-rke-add-on)
|
||||
>
|
||||
> As of release v2.0.8, Rancher supports installation and upgrade by Helm chart, although RKE installs/upgrades are still supported as well. If you want to change upgrade method from RKE Add-on to Helm chart, follow this procedure.
|
||||
>
|
||||
>* [High Availability (HA) Upgrade - RKE Add-On Install]({{< baseurl >}}/rancher/v2.x/en/upgrades/ha-server-upgrade)
|
||||
>
|
||||
> If you want to continue using RKE for upgrades, follow this procedure.
|
||||
|
||||
|
||||
## Prerequisites
|
||||
|
||||
@@ -37,19 +34,8 @@ The following instructions will guide you through upgrading a high-availability
|
||||
```
|
||||
helm init --upgrade --service-account tiller
|
||||
```
|
||||
|
||||
## Chart Versioning Notes
|
||||
|
||||
Up until the initial helm chart release for v2.1.0, the helm chart version matched the Rancher version (i.e `appVersion`).
|
||||
|
||||
Since there are times where the helm chart will require changes without any changes to the Rancher version, we have moved to a `yyyy.mm.<build-number>` helm chart version.
|
||||
|
||||
Run `helm search rancher` to view which Rancher version will be launched for the specific helm chart version.
|
||||
|
||||
```
|
||||
NAME CHART VERSION APP VERSION DESCRIPTION
|
||||
rancher-stable/rancher 2018.10.1 v2.1.0 Install Rancher Server to manage Kubernetes clusters acro...
|
||||
```
|
||||
- **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
|
||||
|
||||
@@ -61,7 +47,19 @@ rancher-stable/rancher 2018.10.1 v2.1.0 Install Rancher Serve
|
||||
helm repo update
|
||||
```
|
||||
|
||||
2. Get the set values from current Rancher release.
|
||||
2. Get the [repository name that you installed Rancher]({{< baseurl >}}/rancher/v2.x/en/installation/server-tags/#helm-chart-repositories) with.
|
||||
|
||||
```
|
||||
helm repo list
|
||||
|
||||
NAME URL
|
||||
stable https://kubernetes-charts.storage.googleapis.com
|
||||
rancher-<CHART_REPO> https://releases.rancher.com/server-charts/<CHART_REPO>
|
||||
```
|
||||
|
||||
> **Note:** If you want to switch to a different Helm chart repository, please follow the [steps on how to switch repositories]({{< baseurl >}}/rancher/v2.x/en/installation/server-tags/#switching-to-a-different-helm-chart-repository). If you switch repositories, make sure to list the repositories again before continuing onto Step 3 to ensure you have the correct one added.
|
||||
|
||||
3. Get the set values from the current Rancher install.
|
||||
|
||||
```
|
||||
helm get values rancher
|
||||
@@ -71,13 +69,20 @@ rancher-stable/rancher 2018.10.1 v2.1.0 Install Rancher Serve
|
||||
|
||||
> **Note:** There may be more values that are listed with this command depending on which [SSL configuration option you selected]({{< baseurl >}}/rancher/v2.x/en/installation/ha/helm-rancher/#choose-your-ssl-configuration) when installing Rancher.
|
||||
|
||||
3. Take all values from the previous command and use `helm` with `--set` options to upgrade Rancher to the latest version.
|
||||
4. Upgrade Rancher to the latest version based on values from the previous steps.
|
||||
|
||||
- Replace `<CHART_REPO>` with the repository that was listed (i.e. `latest` or `stable`).
|
||||
- Take all the values from the previous step and append them to the command using `--set key=value`.
|
||||
|
||||
```
|
||||
helm upgrade rancher rancher-stable/rancher --set hostname=rancher.my.org
|
||||
helm upgrade rancher rancher-<CHART_REPO>/rancher --set hostname=rancher.my.org
|
||||
```
|
||||
|
||||
> **Important:** For any values listed from Step 2, you must use `--set key=value` to apply the same values to the helm chart.
|
||||
**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
|
||||
|
||||
|
||||
@@ -1,55 +0,0 @@
|
||||
---
|
||||
title: HA Upgrade - RKE Add-on
|
||||
weight: 1040
|
||||
aliases:
|
||||
- /rancher/v2.x/en/upgrades/ha-server-upgrade/
|
||||
---
|
||||
|
||||
> #### **Important: RKE add-on install is only supported up to Rancher v2.0.8**
|
||||
>
|
||||
>Please use the Rancher helm chart to install HA Rancher. For details, see the [HA Install - Installation Outline]({{< baseurl >}}/rancher/v2.x/en/installation/ha/#installation-outline).
|
||||
>
|
||||
>If you are currently using the RKE add-on install method, see [Migrating from an HA RKE Add-on Install]({{< baseurl >}}/rancher/v2.x/en/upgrades/upgrades/migrating-from-rke-add-on/) for details on how to move to using the helm chart.
|
||||
|
||||
This document is for upgrading Rancher HA installed with the RKE Add-On yaml. See these docs to migrate to or upgrade Rancher installed with the Helm chart.
|
||||
|
||||
* [Migrating from a High Availability RKE Add-on Install]({{< baseurl >}}/rancher/v2.x/en/upgrades/upgrades/migrating-from-rke-add-on/)
|
||||
* [High Availability (HA) Upgrade]({{< baseurl >}}/rancher/v2.x/en/upgrades/upgrades/ha-server-upgrade-helm/)
|
||||
|
||||
>**Prerequisites:**
|
||||
{{< requirements_rollback >}}
|
||||
|
||||
>- Install [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) on your workstation.
|
||||
>- Confirm that the following path exists on your workstation: `~/.kube/`. If it doesn't, create it yourself.
|
||||
>- Copy `kube_config_rancher-cluster.yml`, which is automatically generated after [Rancher Server installation]({{< baseurl >}}/rancher/v2.x/en/installation/ha-server-install#part-11-backup-kube-config-rancher-cluster-yml), to the `~/.kube/` directory.
|
||||
|
||||
1. From your workstation, open **Terminal**.
|
||||
|
||||
1. Change directory to the location of the RKE binary. Your `rancher-cluster.yml` file must reside in the same directory.
|
||||
|
||||
>**Want records of all transactions with the Rancher API?**
|
||||
>
|
||||
>Enable the [API Auditing]({{< baseurl >}}/rancher/v2.x/en/installation/api-auditing) feature by editing your RKE config file (`rancher-cluster.yml`). For more information, see how to enable it in [your RKE config file]({{< baseurl >}}/rancher/v2.x/en/installation/ha/rke-add-on/api-auditing/).
|
||||
|
||||
1. <a id="snapshot"></a> Enter the following command. Replace `<SNAPSHOT.db>` with any name that you want to use for the snapshot (e.g. `upgrade.db`).
|
||||
|
||||
```
|
||||
rke etcd snapshot-save --name <SNAPSHOT.db> --config rancher-cluster.yml
|
||||
```
|
||||
|
||||
**Result:** RKE takes a snapshot of `etcd` running on each `etcd` node. The file is saved to `/opt/rke/etcd-snapshots`.
|
||||
|
||||
1. Enter the following command:
|
||||
|
||||
```
|
||||
kubectl --kubeconfig=kube_config_rancher-cluster.yml set image deployment/cattle cattle-server=rancher/rancher:<VERSION_TAG> -n cattle-system
|
||||
```
|
||||
Replace `<VERSION_TAG>` with the version that you want to upgrade to. For a list of tags available, see the [Rancher Forum Announcements](https://forums.rancher.com/c/announcements).
|
||||
|
||||
**Step Result:** The upgrade begins. Rancher Server may be unavailable for a few minutes.
|
||||
|
||||
1. Log into Rancher. Confirm that the upgrade succeeded by checking the version displayed in the bottom-left corner of the browser window.
|
||||
|
||||
**Result:** Your Rancher Servers are upgraded.
|
||||
|
||||
>**Upgrade Issues?** You can restore your Rancher Server and data that was running prior to upgrade. For more information, see [Rolling Back—High Availability Installs]({{< baseurl >}}/rancher/v2.x/en/backups/rollbacks/ha-server-rollbacks).
|
||||
@@ -1,8 +1,16 @@
|
||||
---
|
||||
title: Migrating from an HA RKE Add-on Install
|
||||
weight: 1030
|
||||
aliases:
|
||||
- /rancher/v2.x/en/upgrades/ha-server-upgrade/
|
||||
- /rancher/v2.x/en/upgrades/upgrades/ha-server-upgrade/
|
||||
---
|
||||
|
||||
> #### **Important: RKE add-on install is only supported up to Rancher v2.0.8**
|
||||
>
|
||||
>If you are currently using the RKE add-on install method, please follow these directions to migrate to the Helm install.
|
||||
|
||||
|
||||
The following instructions will help guide you through migrating from the RKE Add-on install to managing Rancher with the Helm package manager.
|
||||
|
||||
You will need the to have [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl) installed and `kube_config_rancher-cluster.yml` credentials file generated by RKE.
|
||||
|
||||
@@ -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/).
|
||||
|
||||
@@ -3,7 +3,7 @@ title: Managing Node Templates
|
||||
weight: 7010
|
||||
---
|
||||
|
||||
When you provision a [node pool]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools) cluster, [node templates]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/#node-templates) are used to provision the cluster nodes. These templates use Docker Machine configuration options to define an operating system image and settings/parameters for the node. You can create node templates in two contexts:
|
||||
When you provision a cluster [hosted by an infrastructure provider]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools), [node templates]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/#node-templates) are used to provision the cluster nodes. These templates use Docker Machine configuration options to define an operating system image and settings/parameters for the node. You can create node templates in two contexts:
|
||||
|
||||
- While [provisioning a node pool cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools).
|
||||
- At any time, from your [user settings](#creating-a-node-template-from-user-settings).
|
||||
|
||||
@@ -46,14 +46,13 @@ More detailed information on Kubernetes concepts can be found in the
|
||||
<!-- TOC -->
|
||||
|
||||
- [1. Get Started](#1-get-started)
|
||||
- [2. Migrate Applications](#2-migrate-applications)
|
||||
- [3. Expose Your Services](#3-expose-your-services)
|
||||
- [4. Monitor Your Applications](#4-monitor-your-applications)
|
||||
- [5. Schedule Deployments](#5-schedule-deployments)
|
||||
- [6. Service Discovery](#6-service-discovery)
|
||||
- [7. Load Balancing](#7-load-balancing)
|
||||
<!--- [7. Load Balancing](#7-load-balancing)-->
|
||||
|
||||
- [2. Run Migration Tools](#2-run-migration-tools)
|
||||
- [3. Migrate Applications](#3-migrate-applications)
|
||||
- [4. Expose Your Services](#4-expose-your-services)
|
||||
- [5. Monitor Your Applications](#5-monitor-your-applications)
|
||||
- [6. Schedule Deployments](#6-schedule-deployments)
|
||||
- [7. Service Discovery](#7-service-discovery)
|
||||
- [8. Load Balancing](#8-load-balancing)
|
||||
|
||||
<!-- /TOC -->
|
||||
|
||||
@@ -63,7 +62,79 @@ As a Rancher 1.6 user who's interested in moving to 2.0, how should you get star
|
||||
|
||||
Blog Post: [Migrating from Rancher 1.6 to Rancher 2.0—A Short Checklist](https://rancher.com/blog/2018/2018-08-09-migrate-1dot6-setup-to-2dot0/)
|
||||
|
||||
## 2. Migrate Applications
|
||||
## 2. Run Migration Tools
|
||||
|
||||
To help with migration from 1.6 to 2.0, Rancher has developed a migration tool. Running this tool will help you check if your Rancher 1.6 applications can be migrated to 2.0. If an application can't be migrated, the tool will help you identify what's lacking.
|
||||
|
||||
This tool will:
|
||||
|
||||
- Accept Docker Compose config files (i.e., `docker-compose.yml` and `rancher-compose.yml`) that you've exported from your Rancher 1.6 Stacks.
|
||||
- Output a list of constructs present in the Compose files that cannot be supported by Kubernetes in Rancher 2.0. These constructs require special handling or are parameters that cannot be converted to Kubernetes YAML, even using tools like Kompose.
|
||||
|
||||
### A. Download the Migration Tool
|
||||
|
||||
The Migration Tool for your platform can be downloaded from its [GitHub releases page](https://github.com/rancher/migration-tools/releases). The tool is available for Linux, Mac, and Windows platforms.
|
||||
|
||||
|
||||
### B. Configure the Migration Tool
|
||||
|
||||
After the tool is downloaded, you need to make some configurations to run it.
|
||||
|
||||
1. Modify the Migration Tool file to make it an executable.
|
||||
|
||||
1. Open Terminal and change to the directory that contains the Migration Tool file.
|
||||
|
||||
1. Rename the Migration Tool file to `migration-tools` so that it no longer includes the platform name.
|
||||
|
||||
1. Enter the following command to make `migration-tools` an executable:
|
||||
|
||||
```
|
||||
chmod +x migration-tools
|
||||
```
|
||||
1. Export the configuration for each Rancher 1.6 Stack that you want to migrate to 2.0.
|
||||
|
||||
1. Log into Rancher 1.6 and select **Stacks > All**.
|
||||
|
||||
1. From the **All Stacks** page, select **Ellipsis (...) > Export Config** for each Stack that you want to migrate.
|
||||
|
||||
1. Extract the downloaded `compose.zip`. Move the folder contents (`docker-compose.yml` and `rancher-compose.yml`) into the same directory as `migration-tools`.
|
||||
|
||||
### C. Run the Migration Tool
|
||||
|
||||
To use the Migration Tool, run the command below while pointing to the compose files exported from each stack that you want to migrate. If you want to migrate multiple stacks, you'll have to re-run the command for each pair of compose files that you exported.
|
||||
|
||||
#### Usage
|
||||
|
||||
You can run the Migration Tool by entering the following command, replacing each placeholder with the absolute path to your Stack's compose files.
|
||||
|
||||
```
|
||||
migration-tools --docker-file <DOCKER_COMPOSE_ABSOLUTE_PATH> --rancher-file <RANCHER_COMPOSE_ABSOLUTE_PATH>
|
||||
```
|
||||
|
||||
#### Options
|
||||
|
||||
When using the Migration Tool, you can specify the paths to your Docker and Rancher compose files, regardless of where they are on your file system.
|
||||
|
||||
| Option | Description |
|
||||
| ---------------------- | -------------------------------------------------------------------------------------- |
|
||||
| `--docker-file <DOCKER_COMPOSE_ABSOLUTE_PATH>` | The absolute path to an exported Docker compose file (default value: `docker-compose.yml`)<sup>1</sup>. |
|
||||
| `--rancher-file <RANCHER_COMPOSE_ABSOLUTE_PATH>` | The absolute path to an alternate Rancher compose file (default value: `rancher-compose.yml`)<sup>1</sup>. |
|
||||
| `--help, -h` | Lists usage for the Migration Tool. |
|
||||
| `--version, -v` | Lists the version of the Migration Tool in use. |
|
||||
|
||||
><sup>1</sup> If you omit the `--docker-file` and `--rancher-file` options from your command, the migration tool will check its home directory for compose files.
|
||||
|
||||
#### Output
|
||||
|
||||
After you run the migration tool, the following files output to the same directory that you ran the tool from.
|
||||
|
||||
|
||||
| Output | Description |
|
||||
| --------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `output.txt` | This file lists all constructs for each service in `docker-compose.yml` that requires special handling to be successfully migrated to Rancher 2.0. Each construct links to the relevant blog articles on how to implement it in Rancher 2.0 (these articles are also listed below). |
|
||||
| Kubernetes YAML specs | The Migration Tool internally invokes [Kompose](https://github.com/kubernetes/kompose) to generate Kubernetes YAML specs for each service you're migrating to 2.0. Each YAML spec file is named for the service you're migrating.
|
||||
|
||||
## 3. Migrate Applications
|
||||
|
||||
In Rancher 1.6, you launch applications as _services_ and organize them under _stacks_ in an _environment_, which represents a compute and administrative boundary. Rancher 1.6 supports the Docker compose standard and provides import/export for application configurations using the following files: `docker-compose.yml` and `rancher-compose.yml`. In 2.0 the environment concept doesn't exist. Instead it's replaced by:
|
||||
|
||||
@@ -74,31 +145,31 @@ The following article explores how to map Cattle's stack and service design to K
|
||||
|
||||
Blog Post: [A Journey from Cattle to Kubernetes!](https://rancher.com/blog/2018/2018-08-02-journey-from-cattle-to-k8s/)
|
||||
|
||||
## 3. Expose Your Services
|
||||
## 4. Expose Your Services
|
||||
|
||||
In Rancher 1.6, you could provide external access to your applications using port mapping. This article explores how to publicly expose your services in Rancher 2.0. It explores both UI and CLI methods to transition the port mapping functionality.
|
||||
|
||||
Blog Post: [From Cattle to Kubernetes—How to Publicly Expose Your Services in Rancher 2.0](https://rancher.com/blog/2018/expose-and-monitor-workloads/)
|
||||
|
||||
## 4. Monitor Your Applications
|
||||
## 5. Monitor Your Applications
|
||||
|
||||
Rancher 1.6 provided TCP and HTTP healthchecks using its own healthcheck microservice. Rancher 2.0 uses native Kubernetes healthcheck support instead. This article overviews how to configure it in Rancher 2.0.
|
||||
|
||||
Blog Post: [From Cattle to Kubernetes—Application Healthchecks in Rancher 2.0](https://rancher.com/blog/2018/2018-08-22-k8s-monitoring-and-healthchecks/)
|
||||
|
||||
## 5. Schedule Deployments
|
||||
## 6. Schedule Deployments
|
||||
|
||||
Scheduling application containers on available resources is a key container orchestration technique. The following blog reviews how to schedule containers in Rancher 2.0 for those familiar with 1.6 scheduling labels (such as affinity and anti-affinity). It also explores how to launch a global service in 2.0.
|
||||
|
||||
Blog Post: [From Cattle to Kubernetes—Scheduling Workloads in Rancher 2.0](https://rancher.com/blog/2018/2018-08-29-scheduling-options-in-2-dot-0/)
|
||||
|
||||
## 6. Service Discovery
|
||||
## 7. Service Discovery
|
||||
|
||||
Rancher 1.6 provides service discovery within and across stacks using its own internal DNS microservice. It also supports pointing to external services and creating aliases. Moving to Rancher 2.0, you can replicate this same service discovery behavior. The following blog reviews this topic and the solutions needed to achieve service discovery parity in Rancher 2.0.
|
||||
|
||||
Blog Post: [From Cattle to Kubernetes—Service Discovery in Rancher 2.0](https://rancher.com/blog/2018/2018-09-04-service_discovery_2dot0/)
|
||||
|
||||
## 7. Load Balancing
|
||||
## 8. Load Balancing
|
||||
|
||||
How to achieve TCP/HTTP load balancing and configure hostname/path-based routing in Rancher 2.0.
|
||||
|
||||
@@ -106,3 +177,4 @@ Blog Post: [From Cattle to Kubernetes-How to Load Balance Your Services in Ranch
|
||||
|
||||
In Rancher 1.6, a Load Balancer was used to expose your applications from within the Rancher environment for external access. In Rancher 2.0, the concept is the same. There is a Load Balancer option to expose your services. In the language of Kubernetes, this function is more often referred to as an **Ingress**. In short, Load Balancer and Ingress play the same role.
|
||||
|
||||
|
||||
|
||||
@@ -44,7 +44,7 @@ cluster_name: mycluster
|
||||
|
||||
### Supported Docker Versions
|
||||
|
||||
By default, RKE will check the installed Docker version on all hosts and fail with an error if the version is not supported by Kubernetes. The list of [supported Docker versions](https://github.com/rancher/rke/blob/master/docker/docker.go#L29) are set specifically for each Kubernetes version. To override this behavior, set this option to `true`.
|
||||
By default, RKE will check the installed Docker version on all hosts and fail with an error if the version is not supported by Kubernetes. The list of [supported Docker versions](https://github.com/rancher/rke/blob/master/docker/docker.go#L37-L41) are set specifically for each Kubernetes version. To override this behavior, set this option to `true`.
|
||||
|
||||
The default value is `false`.
|
||||
|
||||
|
||||
@@ -28,7 +28,7 @@ When provisioning clusters in Rancher using the [vSphere node driver]({{< baseur
|
||||
5. Assign **Member Roles** as required.
|
||||
6. Expand **Cluster Options** and configure as required.
|
||||
7. Set **Cloud Provider** option to `Custom`.
|
||||
|
||||
|
||||
|
||||
|
||||
8. Click on **Edit as YAML**
|
||||
@@ -149,7 +149,7 @@ The following configuration options are available under the disk directive:
|
||||
|
||||
___
|
||||
|
||||
### network
|
||||
### network
|
||||
|
||||
The following configuration options are available under the network directive:
|
||||
|
||||
@@ -184,7 +184,7 @@ cloud_provider:
|
||||
folder: k8s-dummy
|
||||
default-datastore: ds-1
|
||||
datacenter: eu-west-1
|
||||
|
||||
|
||||
```
|
||||
|
||||
## Annex
|
||||
@@ -245,7 +245,7 @@ $ rancher ssh <nodeName>
|
||||
```
|
||||
|
||||
3. Inspect the logs of the controller-manager and kubelet containers looking for errors related to the vSphere cloud provider:
|
||||
|
||||
|
||||
```sh
|
||||
$ docker logs --since 15m kube-controller-manager
|
||||
$ docker logs --since 15m kubelet
|
||||
|
||||
@@ -1 +1 @@
|
||||
<div><p>Use <strong>Cluster Options</strong> to choose the version of Kubernetes, what network provider will be used, if you want to enable Pod Security Policies and wether the nodes added to this cluster need to have a supported Docker version installed.
|
||||
<div><p>Use <strong>Cluster Options</strong> to choose the version of Kubernetes, what network provider will be used, if you want to enable Pod Security Policies and whether the nodes added to this cluster need to have a supported Docker version installed.
|
||||
|
||||
@@ -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: 37 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 23 KiB |
Reference in New Issue
Block a user