mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-23 03:28:07 +00:00
Denise
@@ -37,7 +37,7 @@ rancher:
|
||||
```
|
||||
<br>
|
||||
|
||||
> **Note:** You can not name the service `rancher-agent` as this will not allow the rancher/agent container to be launched correctly. Please read more about why [you can't name your container as `rancher-agent`](https://rancher.com/docs/rancher/v1.6/en/faqs/agents/#adding-in-name-rancher-agent).
|
||||
> **Note:** You can not name the service `rancher-agent` as this will not allow the rancher/agent container to be launched correctly. Please read more about why [you can't name your container as `rancher-agent`]({{< baseurl >}}/rancher/v1.6/en/faqs/agents/#adding-in-name-rancher-agent).
|
||||
|
||||
### Adding in Host Labels
|
||||
|
||||
|
||||
@@ -38,6 +38,6 @@ For more information how to create and use PSPs, see [Pod Security Policies]({{<
|
||||
|
||||
## Provisioning Drivers
|
||||
|
||||
Drivers in Rancher allow you to manage which providers can be used to provision [hosted Kubernetes clusters]({{< baseurl >}}rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/) or [nodes in an infrastructure provider]({{< baseurl >}}rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/) to allow Rancher to deploy and manage Kubernetes.
|
||||
Drivers in Rancher allow you to manage which providers can be used to provision [hosted Kubernetes clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/) or [nodes in an infrastructure provider]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/) to allow Rancher to deploy and manage Kubernetes.
|
||||
|
||||
For more information, see [Provisioning Drivers]({{< baseurl >}}/rancher/v2.x/en/admin-settings/drivers/).
|
||||
|
||||
@@ -122,12 +122,10 @@ To use Azure AD with Rancher you must whitelist Rancher with Azure. You can comp
|
||||
1. From the **Reply URLs** blade, enter the URL of your Rancher Server, appended with the verification path: `<MY_RANCHER_URL>/verify-auth-azure`.
|
||||
|
||||
>**Tip:** You can find your personalized Azure reply URL in Rancher on the Azure AD Authentication page (Global View > Security Authentication > Azure AD).
|
||||
>
|
||||
> 
|
||||
|
||||
1. Click **Save**.
|
||||
|
||||
**Result:** Your reply URL is saved.
|
||||
**Result:** Your reply URL is saved.
|
||||
|
||||
>**Note:** It can take up to five minutes for this change to take affect, so don't be alarmed if you can't authenticate immediately after Azure AD configuration.
|
||||
|
||||
@@ -173,19 +171,19 @@ As your final step in Azure, copy the data that you'll use to configure Rancher
|
||||
|
||||
From the Rancher UI, enter information about your AD instance hosted in Azure to complete configuration.
|
||||
|
||||
Enter the values that you copied to your [text file](#tip).
|
||||
Enter the values that you copied to your [text file]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/azure-ad/#tip).
|
||||
|
||||
1. Log into Rancher. From the **Global** view, select **Security > Authentication**.
|
||||
|
||||
1. Select **Azure AD**.
|
||||
|
||||
1. Complete the **Configure Azure AD Account** form using the information you copied while completing [Copy Azure Application Data](#4-copy-azure-application-data).
|
||||
1. Complete the **Configure Azure AD Account** form using the information you copied while completing [Copy Azure Application Data](#5-copy-azure-application-data).
|
||||
|
||||
>**Important:** When entering your Graph Endpoint, remove the tenant ID from the URL, like below.
|
||||
>
|
||||
><code>http<span>s://g</span>raph.windows.net/<del>abb5adde-bee8-4821-8b03-e63efdc7701c</del></code>
|
||||
|
||||
The following table maps the values you copied in the Azure portal to the fields in Rancher.
|
||||
The following table maps the values you copied in the Azure portal to the fields in Rancher.
|
||||
|
||||
| Rancher Field | Azure Value |
|
||||
| ------------------ | ------------------------------------- |
|
||||
|
||||
@@ -9,10 +9,10 @@ This section is devoted to protecting your data in a disaster scenario.
|
||||
To protect yourself from a disaster scenario, you should create backups on a regular basis.
|
||||
|
||||
- [Rancher Server Backups]({{< baseurl >}}/rancher/v2.x/en/backups/backups)
|
||||
- [Backing up Rancher Launched Kubernetes Clusters]({{< baseurl >}}/rancher/v2.x/rancher/v2.x/en/cluster-admin/backing-up-etcd/)
|
||||
- [Backing up Rancher Launched Kubernetes Clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/backing-up-etcd/)
|
||||
|
||||
|
||||
In a disaster scenario, you can restore your `etcd` database by restoring a backup.
|
||||
|
||||
- [Rancher Server Restorations]({{< baseurl >}}/rancher/v2.x/en/backups/restorations)
|
||||
- [Restoring Rancher Launched Kubernetes Clusters]({{< baseurl >}}/rancher/v2.x/rancher/v2.x/en/cluster-admin/restoring-etcd/)
|
||||
- [Restoring Rancher Launched Kubernetes Clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/restoring-etcd/)
|
||||
|
||||
+1
-1
@@ -36,7 +36,7 @@ Rancher deploys an agent on each node to communicate with the node. This pages d
|
||||
|
||||
### 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`.
|
||||
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. This is supported for `--address` and `--internal-address`.
|
||||
|
||||
| Value | Example | Description |
|
||||
| ---------- | -------------------- | ----------- |
|
||||
|
||||
+1
-1
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Creating an Alibaba ACK Cluster
|
||||
title: Creating an Aliyun ACK Cluster
|
||||
shortTitle: Alibaba Cloud Container Service for Kubernetes
|
||||
weight: 2120
|
||||
---
|
||||
|
||||
+1
-1
@@ -24,7 +24,7 @@ Use Rancher to set up and configure your Kubernetes cluster.
|
||||
|
||||
1. {{< step_create-cluster_member-roles >}}
|
||||
|
||||
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).
|
||||
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](#prerequisites-in-amazon-web-services).
|
||||
|
||||
| Setting | Description |
|
||||
| ---------- | -------------------------------------------------------------------------------------------------------------------- |
|
||||
|
||||
@@ -34,7 +34,7 @@ Use {{< product >}} to create a Kubernetes cluster in Amazon EC2.
|
||||
|
||||
1. Complete each of the following forms using information available from the [EC2 Management Console](https://aws.amazon.com/ec2).
|
||||
|
||||
- **Account Access** is where you configure the region of the nodes, and the credentials (Access Key and Secret Key) used to create the machine. See [Prerequisistes](#prerequisistes) how to create the Access Key and Secret Key and the needed permissions.
|
||||
- **Account Access** is where you configure the region of the nodes, and the credentials (Access Key and Secret Key) used to create the machine. See [Prerequisistes](#prerequisites) how to create the Access Key and Secret Key and the needed permissions.
|
||||
|
||||
{{< step_create-cloud-credential >}}
|
||||
|
||||
|
||||
@@ -121,7 +121,7 @@ See [Docker Root Directory](#docker-root-directory).
|
||||
|
||||
#### enable_cluster_monitoring
|
||||
|
||||
Option to enable or disable [Cluster Monitoring]({{< baseurl >}}/rancher/v2.x/en/tools/monitoring/).
|
||||
Option to enable or disable [Cluster Monitoring]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/monitoring/).
|
||||
|
||||
#### enable_network_policy
|
||||
|
||||
|
||||
+11
-13
@@ -15,7 +15,7 @@ This guide walks you through create of a custom cluster that includes 3 nodes: a
|
||||
|
||||
>**Notes:**
|
||||
>
|
||||
>- For a summary of Kubernetes features supported in Windows, see [Using Windows Server Containers in Kubernetes](https://kubernetes.io/docs/getting-started-guides/windows/#supported-features).
|
||||
>- For a summary of Kubernetes features supported in Windows, see [Using Windows in Kubernetes](https://kubernetes.io/docs/setup/windows/intro-windows-in-kubernetes/).
|
||||
>- Windows containers must run on Windows Server 1803 nodes. Windows Server 1709 and earlier versions do not support Kubernetes properly.
|
||||
>- Containers built for Windows Server 1709 or earlier do not run on Windows Server 1803. You must build containers on Windows Server 1803 to run these containers on Windows Server 1803.
|
||||
|
||||
@@ -28,12 +28,11 @@ When setting up a custom cluster with support for Windows nodes and containers,
|
||||
<!-- TOC -->
|
||||
|
||||
- [1. Provision Hosts](#1-provision-hosts)
|
||||
- [2. Cloud-host VM Networking Configuration](#2-cloud-host-vm-networking-configuration)
|
||||
- [2. Cloud-host VM Networking Configuration](#2-cloud-hosted-vm-networking-configuration)
|
||||
- [3. Create the Custom Cluster](#3-create-the-custom-cluster)
|
||||
- [4. Add Linux Host for Ingress Support](#4-add-linux-host-for-ingress-support)
|
||||
- [5. Adding Windows Workers](#5-adding-windows-workers)
|
||||
- [6. Cloud-host VM Routes Configuration](#6-cloud-host-vm-routes-configuration)
|
||||
- [Troubleshooting](#troubleshooting)
|
||||
- [6. Cloud-host VM Routes Configuration](#6-cloud-hosted-vm-routes-configuration)
|
||||
|
||||
<!-- /TOC -->
|
||||
|
||||
@@ -43,14 +42,14 @@ To begin provisioning a custom cluster with Windows support, prepare your host s
|
||||
|
||||
- Cloud-hosted VMs
|
||||
- VMs from virtualization clusters
|
||||
- Bare-metal servers
|
||||
- Bare-metal servers
|
||||
|
||||
The table below lists the [Kubernetes roles]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#kubernetes-cluster-node-components) you'll assign to each host, although you won't enable these roles until further along in the configuration process—we're just informing you of each node's purpose. The first node, a Linux host, is primarily responsible for managing the Kubernetes control plane, although, in this use case, we're installing all three roles on this node. Node 2 is also a Linux worker, which is responsible for Ingress support. Finally, the third node is your Windows worker, which will run your Windows applications.
|
||||
|
||||
Node | Operating System | Future Cluster Role(s)
|
||||
--------|------------------|------
|
||||
Node 1 | Linux (Ubuntu Server 16.04 recommended) | [Control Plane]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#control-plane-nodes), [etcd]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#etcd), [Worker]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#worker-nodes)
|
||||
Node 2 | Linux (Ubuntu Server 16.04 recommended) | [Worker]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#worker-nodes) (This node is used for Ingress support)
|
||||
Node 2 | Linux (Ubuntu Server 16.04 recommended) | [Worker]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#worker-nodes) (This node is used for Ingress support)
|
||||
Node 3 | Windows (*Windows Server 1803 required*) | [Worker]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#worker-nodes)
|
||||
|
||||
### Requirements
|
||||
@@ -115,7 +114,7 @@ After the initial provisioning of your custom cluster, your cluster only has a s
|
||||
|
||||
1. Using the content menu, open the custom cluster your created in [2. Create the Custom Cluster](#2-create-the-custom-cluster).
|
||||
|
||||
1. From the main menu, select **Nodes**.
|
||||
1. From the main menu, select **Nodes**.
|
||||
|
||||
1. Click **Edit Cluster**.
|
||||
|
||||
@@ -127,7 +126,7 @@ After the initial provisioning of your custom cluster, your cluster only has a s
|
||||
|
||||
1. Log in to your Linux host using a remote Terminal connection. Run the command copied to your clipboard.
|
||||
|
||||
1. From **Rancher**, click **Save**.
|
||||
1. From **Rancher**, click **Save**.
|
||||
|
||||
**Result:** The worker role is installed on your Linux host, and the node registers with Rancher.
|
||||
|
||||
@@ -135,7 +134,7 @@ After the initial provisioning of your custom cluster, your cluster only has a s
|
||||
|
||||
You can add Windows hosts to a custom cluster by editing the cluster and choosing the **Windows** option.
|
||||
|
||||
1. From the main menu, select **Nodes**.
|
||||
1. From the main menu, select **Nodes**.
|
||||
|
||||
1. Click **Edit Cluster**.
|
||||
|
||||
@@ -147,7 +146,7 @@ You can add Windows hosts to a custom cluster by editing the cluster and choosin
|
||||
|
||||
1. Log in to your Windows host using your preferred tool, such as [Microsoft Remote Desktop](https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/clients/remote-desktop-clients). Run the command copied to your clipboard in the **Command Prompt (CMD)**.
|
||||
|
||||
1. From Rancher, click **Save**.
|
||||
1. From Rancher, click **Save**.
|
||||
|
||||
1. **Optional:** Repeat these instruction if you want to add more Windows nodes to your cluster.
|
||||
|
||||
@@ -157,11 +156,11 @@ You can add Windows hosts to a custom cluster by editing the cluster and choosin
|
||||
|
||||
In Windows clusters, containers communicate with each other using the `host-gw` mode of Flannel. In `host-gw` mode, all containers on the same node belong to a private subnet, and traffic routes from a subnet on one node to a subnet on another node through the host network.
|
||||
|
||||
- When worker nodes are provisioned on AWS, virtualization clusters, or bare metal servers, make sure they belong to the same layer 2 subnet. If the nodes don't belong to the same layer 2 subnet, `host-gw` networking will not work. Please contact [Rancher support](https://rancher.com/support/) if your worker nodes on AWS, virtualization clusters, or bare metal servers don't belong to the same layer 2 network.
|
||||
- When worker nodes are provisioned on AWS, virtualization clusters, or bare metal servers, make sure they belong to the same layer 2 subnet. If the nodes don't belong to the same layer 2 subnet, `host-gw` networking will not work.
|
||||
|
||||
- When worker nodes are provisioned on GCE or Azure, they are not on the same layer 2 subnet. Nodes on GCE and Azure belong to a routable layer 3 network. Follow the instructions below to configure GCE and Azure so that the cloud network knows how to route the host subnets on each node.
|
||||
|
||||
To configure host subnet routing on GCE or Azure, first run the following command to find out the host subnets on each worker node:
|
||||
To configure host subnet routing on GCE or Azure, first run the following command to find out the host subnets on each worker node:
|
||||
|
||||
```bash
|
||||
kubectl get nodes -o custom-columns=nodeName:.metadata.name,nodeIP:status.addresses[0].address,routeDestination:.spec.podCIDR
|
||||
@@ -176,4 +175,3 @@ Azure VM | For Azure, create a routing table: [Custom Routes: User-defined](http
|
||||
|
||||
|
||||
` `
|
||||
|
||||
|
||||
@@ -43,15 +43,15 @@ weight: 276
|
||||
|
||||
### API Audit Log
|
||||
|
||||
Enabling the [API Audit Log](https://rancher.com/docs/rancher/v2.x/en/installation/api-auditing/).
|
||||
Enabling the [API Audit Log]({{< baseurl >}}/rancher/v2.x/en/installation/api-auditing/).
|
||||
|
||||
You can collect this log as you would any container log. Enable the [Logging service under Rancher Tools](https://rancher.com/docs/rancher/v2.x/en/tools/logging/) for the `System` Project on the Rancher server cluster.
|
||||
You can collect this log as you would any container log. Enable the [Logging service under Rancher Tools]({{< baseurl >}}/rancher/v2.x/en/tools/logging/) for the `System` Project on the Rancher server cluster.
|
||||
|
||||
```plain
|
||||
--set auditLog.level=1
|
||||
```
|
||||
|
||||
By default enabling Audit Logging will create a sidecar container in the Rancher pod. This container (`rancher-audit-log`) will stream the log to `stdout`. You can collect this log as you would any container log. Enable the [Logging service under Rancher Tools](https://rancher.com/docs/rancher/v2.x/en/tools/logging/) for the Rancher server cluster or System Project.
|
||||
By default enabling Audit Logging will create a sidecar container in the Rancher pod. This container (`rancher-audit-log`) will stream the log to `stdout`. You can collect this log as you would any container log. Enable the [Logging service under Rancher Tools]({{< baseurl >}}/rancher/v2.x/en/tools/logging/) for the Rancher server cluster or System Project.
|
||||
|
||||
Set the `auditLog.destination` to `hostPath` to forward logs to volume shared with the host system instead of streaming to a sidecar container. When setting the destination to `hostPath` you may want to adjust the other auditLog parameters for log rotation.
|
||||
|
||||
|
||||
@@ -7,6 +7,6 @@ When installing Rancher, there are several advanced options that can be enabled
|
||||
|
||||
| Advanced Option | Available as of |
|
||||
| --- | ---|
|
||||
| [Custom CA Certificate]({{< baseurl >}}/rancher/v2.x/en/installation/options/options/) | v2.0.0 |
|
||||
| [Custom CA Certificate]({{< baseurl >}}/rancher/v2.x/en/installation/options/custom-ca-root-certificate/) | v2.0.0 |
|
||||
| [API Audit Log]({{< baseurl >}}/rancher/v2.x/en/installation/options/api-audit-log/) | v2.0.0 |
|
||||
| [TLS Settings]({{< baseurl >}}/rancher/v2.x/en/installation/options/tls-settings/) | v2.1.7 |
|
||||
|
||||
@@ -25,7 +25,7 @@ The usage below defines rules about what the audit log should record and what da
|
||||
|
||||
Parameter | Description |
|
||||
---------|----------|
|
||||
<a id="audit-level"></a>`AUDIT_LEVEL` | `0` - Disable audit log (default setting).<br/>`1` - Log event metadata.<br/>`2` - Log event metadata and request body.</br>`3` - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same `auditID` value.<br/><br/>See [Audit Level Logging](#audit-level-logging) for a table that displays what each setting logs. |
|
||||
<a id="audit-level"></a>`AUDIT_LEVEL` | `0` - Disable audit log (default setting).<br/>`1` - Log event metadata.<br/>`2` - Log event metadata and request body.</br>`3` - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same `auditID` value.<br/><br/>See [Audit Level Logging](#audit-log-levels) for a table that displays what each setting logs. |
|
||||
`AUDIT_LOG_PATH` | Log path for Rancher Server API. Default path is `/var/log/auditlog/rancher-api-audit.log`. You can mount the log directory to host. <br/><br/>Usage Example: `AUDIT_LOG_PATH=/my/custom/path/`<br/> |
|
||||
`AUDIT_LOG_MAXAGE` | Defined the maximum number of days to retain old audit log files. Default is 10 days. |
|
||||
`AUDIT_LOG_MAXBACKUP` | Defines the maximum number of audit log files to retain. Default is 10.
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Choosing a Version
|
||||
title: Choosing a Version
|
||||
weight: 230
|
||||
---
|
||||
|
||||
@@ -49,16 +49,9 @@ Instructions on when to select these repos are available below in [Switching to
|
||||
|
||||
### 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`).
|
||||
Rancher Helm chart versions match 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...
|
||||
```
|
||||
For the Rancher v2.1.x versions, there were some Helm charts, that were using a version that was a build number, i.e. `yyyy.mm.<build-number>`. These charts have been replaced with the equivalent Rancher version and are no longer available.
|
||||
|
||||
### Switching to a Different Helm Chart Repository
|
||||
|
||||
|
||||
@@ -22,7 +22,7 @@ For security purposes, SSL (Secure Sockets Layer) is required when using Rancher
|
||||
>- Use a proxy? See [HTTP Proxy Configuration]({{< baseurl >}}/rancher/v2.x/en/installation/single-node/proxy/)
|
||||
>- Configure custom CA root certificate to access your services? See [Custom CA root certificate]({{< baseurl >}}/rancher/v2.x/en/admin-settings/custom-ca-root-certificate/)
|
||||
>- Complete an Air Gap Installation? See [Air Gap: Single Node Install]({{< baseurl >}}/rancher/v2.x/en/installation/air-gap-single-node/)
|
||||
>- Record all transactions with the Rancher API? See [API Auditing](#api-auditing)
|
||||
>- Record all transactions with the Rancher API? See [API Auditing](#api-audit-log)
|
||||
>
|
||||
|
||||
Choose from the following options:
|
||||
|
||||
@@ -97,7 +97,7 @@ Edit [resource quotas]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-a
|
||||
|
||||
1. Expand **Resource Quotas** and click **Add Quota**. Alternatively, you can edit existing quotas.
|
||||
|
||||
1. Select a [Resource Type]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/resource-quotas/#resource-quota-types).
|
||||
1. Select a [Resource Type]({{< baseurl >}}/rancher/v2.x/en/project-admin/resource-quotas/#resource-quota-types).
|
||||
|
||||
1. Enter values for the **Project Limit** and the **Namespace Default Limit**.
|
||||
|
||||
|
||||
@@ -68,7 +68,7 @@ If there is a [resource quota]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/pr
|
||||
|
||||
1. Find the namespace for which you want to edit the resource quota. Select **Ellipsis (...) > Edit**.
|
||||
|
||||
1. Edit the Resource Quota **Limits**. These limits determine the resources available to the namespace. The limits must be set within the configured [project limits]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/resource-quotas/#project-limits).
|
||||
1. Edit the Resource Quota **Limits**. These limits determine the resources available to the namespace. The limits must be set within the configured project limits.
|
||||
|
||||
For more information about each **Resource Type**, see [Resource Quota Types]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/resource-quotas/#resource-quota-types).
|
||||
|
||||
|
||||
@@ -20,7 +20,7 @@ In the following diagram, a Kubernetes admin is trying to enforce a resource quo
|
||||
<sup>Base Kubernetes: Unique Resource Quotas Being Applied to Each Namespace</sup>
|
||||
|
||||
|
||||
Resource quotas are a little different in Rancher. In Rancher, you apply a resource quota to the [project]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#projects), and then the quota propagates to each namespace, whereafter Kubernetes enforces you limits using the native version of resource quotas. If you want to change the quota for a specific namespace, you can [override it](#namespace-default-limit-overrides).
|
||||
Resource quotas are a little different in Rancher. In Rancher, you apply a resource quota to the [project]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#projects), and then the quota propagates to each namespace, whereafter Kubernetes enforces you limits using the native version of resource quotas. If you want to change the quota for a specific namespace, you can [override it](#overriding-the-default-limit-for-a-namespace).
|
||||
|
||||
The resource quota includes two limits, which you set while creating or editing a project:
|
||||
<a id="project-limits"></a>
|
||||
|
||||
@@ -22,7 +22,7 @@ At the project level, Rancher monitors specific deployments and sends alerts for
|
||||
|
||||
## Adding Project Alerts
|
||||
|
||||
>**Prerequisite:** Before you can receive project alerts, you must [add a notifier]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/notifiers/#adding-notifiers).
|
||||
>**Prerequisite:** Before you can receive project alerts, you must [add a notifier]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/notifiers/#adding-notifiers).
|
||||
|
||||
1. From the **Global** view, navigate to the project that you want to configure project alerts for. Select **Tools > Alerts**. In versions prior to v2.2.0, you can choose **Resources > Alerts**.
|
||||
|
||||
@@ -99,13 +99,16 @@ This alert type monitors for the availability of all workloads marked with tags
|
||||
|
||||
{{% /accordion %}}
|
||||
{{% accordion id="project-expression" label="Metric Expression Alerts" %}}
|
||||
This alert type monitors for the overload from Prometheus expression querying, it would be available after you enable monitoring.
|
||||
<br>
|
||||
_Available as of v2.2.0_
|
||||
|
||||
If you enable [project monitoring]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/#monitoring), this alert type monitors for the overload from Prometheus expression querying.
|
||||
|
||||
1. Input or select an **Expression**, the drop down shows the original metrics from Prometheus, including:
|
||||
|
||||
- [**Container**](https://github.com/google/cadvisor)
|
||||
- [**Kubernetes Resources**](https://github.com/kubernetes/kube-state-metrics)
|
||||
- [**Customize**]({{< baseurl >}}/rancher/v2.x/en/tools/monitoring/#custom-metrics)
|
||||
- [**Customize**]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/monitoring/#project-metrics)
|
||||
- [**Project Level Grafana**](http://docs.grafana.org/administration/metrics/)
|
||||
- **Project Level Prometheus**
|
||||
|
||||
@@ -138,7 +141,7 @@ This alert type monitors for the overload from Prometheus expression querying, i
|
||||
- **Group Wait Time**: How long to wait to buffer alerts of the same group before sending initially, default to 30 seconds.
|
||||
- **Group Interval Time**: How long to wait before sending an alert that has been added to a group which contains already fired alerts, default to 30 seconds.
|
||||
- **Repeat Wait Time**: How long to wait before sending an alert that has been added to a group which contains already fired alerts, default to 1 hour.
|
||||
|
||||
<br>
|
||||
{{% /accordion %}}
|
||||
|
||||
1. Continue adding more **Alert Rule** to the group.
|
||||
|
||||
@@ -51,19 +51,15 @@ When you configure a pipeline in one of your projects, a namespace specifically
|
||||
|
||||
>**Note:** There is no option to use existing Jenkins deployments as the pipeline engine.
|
||||
|
||||
<a id="reg"></a>
|
||||
|
||||
- **Docker Registry:**
|
||||
|
||||
Out-of-the-box, the default target for your build-publish step is an internal Docker Registry. However, you can make configurations to push to a remote registry instead. The internal Docker Registry is only accessible from cluster nodes and cannot be directly accessed by users. Images are not persisted beyond the lifetime of the pipeline and should only be used in pipeline runs. If you need to access your images outside of pipeline runs, please push to an external registry.
|
||||
|
||||
<a id="minio"></a>
|
||||
|
||||
- **Minio:**
|
||||
|
||||
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](#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](#configuring-persistent-data-for-pipeline-components).
|
||||
|
||||
## Pipeline Triggers
|
||||
|
||||
@@ -250,15 +246,13 @@ If you want to use a version control provider with a certificate from a custom/i
|
||||
|
||||
## 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) 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).
|
||||
The internal [Docker registry](#how-pipelines-work) and the [Minio](#how-pipelines-work) 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.
|
||||
|
||||
>**Prerequisites (for both parts A and B):**
|
||||
>
|
||||
>[Persistent volumes]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/#persistent-volumes) must be available for the cluster.
|
||||
|
||||
#### A. Configuring Persistent Data for Docker Registry
|
||||
### A. Configuring Persistent Data for Docker Registry
|
||||
|
||||
1. From the project that you're configuring a pipeline for, select the **Workloads** tab.
|
||||
|
||||
@@ -305,7 +299,7 @@ Complete both [A—Configuring Persistent Data for Docker Registry](#a—configu
|
||||
|
||||
1. Click **Upgrade**.
|
||||
|
||||
#### B. Configuring Persistent Data for Minio
|
||||
### B. Configuring Persistent Data for Minio
|
||||
|
||||
1. From the **Workloads** tab, find the `minio` workload and select **Ellipsis (...) > Edit**.
|
||||
|
||||
|
||||
@@ -32,7 +32,7 @@ Because of the changes necessary to address [CVE-2018-20321](https://cve.mitre.o
|
||||
|
||||
2. After executing the command a `tokens.json` file will be created. Important! Back up this file in a safe place.** You will need it to restore functionality to your clusters after rolling back Rancher. **If you lose this file, you may lose access to your clusters.**
|
||||
|
||||
3. Rollback Rancher following the [normal instructions](https://rancher.com/docs/rancher/v2.x/en/upgrades/rollbacks/).
|
||||
3. Rollback Rancher following the [normal instructions]({{< baseurl >}}/rancher/v2.x/en/upgrades/rollbacks/).
|
||||
|
||||
4. Once Rancher comes back up, every cluster managed by Rancher (except for Imported clusters) will be in an `Unavailable` state.
|
||||
|
||||
|
||||
@@ -3,7 +3,7 @@ title: "6. Service Discovery"
|
||||
weight: 600
|
||||
---
|
||||
|
||||
Service discovery is one of the core functionalities of any container-based environment. Once you have packaged and launched your application, the next step is making it discoverable to other containers in your environment or the external world. This document will describe how to use the service discovery support provided by Rancher v2.x so that you can find them by name.
|
||||
Service discovery is one of the core functionalities of any container-based environment. Once you have packaged and launched your application, the next step is making it discoverable to other containers in your environment or the external world. This document will describe how to use the service discovery support provided by Rancher v2.x so that you can find them by name.
|
||||
|
||||
This document will also show you how to link the workloads and services that you migrated into Rancher v2.x. When you parsed your services from v1.6 using migration-tools CLI, it output two files for each service: one deployment manifest and one service manifest. You'll have to link these two files together before the deployment works correctly in v2.x.
|
||||
|
||||
@@ -27,7 +27,7 @@ This document will also show you how to link the workloads and services that you
|
||||
|
||||
For Rancher v2.x, we've replaced the Rancher DNS microservice used in v1.6 with native [Kubernetes DNS support](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/), which provides equivalent service discovery for Kubernetes workloads and pods. Former Cattle users can replicate all the service discovery features from Rancher v1.6 in v2.x. There's no loss of functionality.
|
||||
|
||||
Kubernetes schedules a DNS pod and service in the cluster, which is similar to the [Rancher v1.6 DNS microservice](https://rancher.com/docs/rancher/v1.6/en/cattle/internal-dns-service/#internal-dns-service-in-cattle-environments). Kubernetes then configures its kubelets to route all DNS lookups to this DNS service, which is skyDNS, a flavor of the default Kube-DNS implementation.
|
||||
Kubernetes schedules a DNS pod and service in the cluster, which is similar to the [Rancher v1.6 DNS microservice]({{< baseurl >}}/rancher/v1.6/en/cattle/internal-dns-service/#internal-dns-service-in-cattle-environments). Kubernetes then configures its kubelets to route all DNS lookups to this DNS service, which is skyDNS, a flavor of the default Kube-DNS implementation.
|
||||
|
||||
The following table displays each service discovery feature available in the two Rancher releases.
|
||||
|
||||
|
||||
@@ -34,7 +34,7 @@ After provisioning your node(s), install Rancher:
|
||||
|
||||
For production environments where your user base requires constant access to your cluster, we recommend installing Rancher in a high availability (HA) configuration. This installation procedure provisions a three-node cluster and installs Rancher on each node using a Helm chart.
|
||||
|
||||
>**Important Difference:** Although you could install Rancher v1.6 in an HA configuration using an external database and a Docker command on each node, Rancher v2.x in an HA configuration requires an existing Kubernetes cluster. Review [High Availability (HA) Install](https://rancher.com/docs/rancher/v2.x/en/installation/ha/) for full requirements.
|
||||
>**Important Difference:** Although you could install Rancher v1.6 in an HA configuration using an external database and a Docker command on each node, Rancher v2.x in an HA configuration requires an existing Kubernetes cluster. Review [High Availability (HA) Install]({{< baseurl >}}/rancher/v2.x/en/installation/ha/) for full requirements.
|
||||
|
||||
## B. Configure Authentication
|
||||
|
||||
@@ -88,7 +88,7 @@ After provisioning a new cluster and project, you can authorize your users to ac
|
||||
|
||||
## D. Create Stacks
|
||||
|
||||
In Rancher v1.6, _stacks_ were used to group together the services that belong to your application. In v2.x, you need to [create namespaces]({{< baseurl >}}rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#creating-namespaces), which are the v2.x equivalent of stacks, for the same purpose.
|
||||
In Rancher v1.6, _stacks_ were used to group together the services that belong to your application. In v2.x, you need to [create namespaces]({{< baseurl >}}rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#creating-namespaces), which are the v2.x equivalent of stacks, for the same purpose.
|
||||
|
||||
In Rancher v2.x, namespaces are child objects to projects. When you create a project, a `default` namespace is added to the project, but you can create your own to parallel your stacks from v1.6.
|
||||
|
||||
|
||||
@@ -5,7 +5,7 @@ weight: 700
|
||||
|
||||
If your applications are public-facing and consume significant traffic, you should place a load balancer in front of your cluster so that users can always access their apps without service interruption. Typically, you can fulfill a high volume of service requests by [horizontally scaling](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) your deployment, which spins up additional application containers as traffic ramps up. However, this technique requires routing that distributes traffic across your nodes efficiently. In cases where you need to accommodate public traffic that scales up and down, you'll need a load balancer.
|
||||
|
||||
As outlined in [its documentation](https://rancher.com/docs/rancher/v1.6/en/cattle/adding-load-balancers/), Rancher v1.6 provided rich support for load balancing using its own microservice powered by HAProxy, which supports HTTP, HTTPS, TCP hostname, and path-based routing. Most of these same features are available in v2.x. However, load balancers that you used with v1.6 cannot be migrated to v2.x. You'll have to manually recreate your v1.6 load balancer in v2.x.
|
||||
As outlined in [its documentation]({{< baseurl >}}/rancher/v1.6/en/cattle/adding-load-balancers/), Rancher v1.6 provided rich support for load balancing using its own microservice powered by HAProxy, which supports HTTP, HTTPS, TCP hostname, and path-based routing. Most of these same features are available in v2.x. However, load balancers that you used with v1.6 cannot be migrated to v2.x. You'll have to manually recreate your v1.6 load balancer in v2.x.
|
||||
|
||||
If you encounter the `output.txt` text below after parsing your v1.6 Compose files to Kubernetes manifests, you'll have to resolve it by manually creating a load balancer in v2.x.
|
||||
|
||||
@@ -41,9 +41,9 @@ Rancher v2.x offers similar functionality, but load balancing is instead handled
|
||||
|
||||
By default, Rancher v2.x deploys NGINX Ingress Controller on clusters provisioned using RKE (Rancher's own Kubernetes installer) to process the Kubernetes Ingress rules. The NGINX Ingress Controller is installed by default only in clusters provisioned by RKE. Clusters provisioned by cloud providers like GKE have their own Ingress Controllers that configure the load balancer. For this document, our scope is limited to the RKE-installed NGINX Ingress Controller only, but you can read about cloud providers in [our documentation]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/cloud-providers/).
|
||||
|
||||
RKE deploys NGINX Ingress Controller as a [Kubernetes DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/), meaning that an NGINX instance is deployed on every node in the cluster. NGINX acts like an Ingress Controller listening to Ingress creation within your entire cluster, and it also configures itself as the load balancer to satisfy the Ingress rules. The DaemonSet is configured with hostNetwork to expose two ports: 80 and 443.
|
||||
RKE deploys NGINX Ingress Controller as a [Kubernetes DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/), meaning that an NGINX instance is deployed on every node in the cluster. NGINX acts like an Ingress Controller listening to Ingress creation within your entire cluster, and it also configures itself as the load balancer to satisfy the Ingress rules. The DaemonSet is configured with hostNetwork to expose two ports: 80 and 443.
|
||||
|
||||
For more information NGINX Ingress Controller, their deployment as DaemonSets, deployment configuration options, see the [RKE documentation](https://rancher.com/docs/rke/v0.1.x/en/config-options/add-ons/ingress-controllers/).
|
||||
For more information NGINX Ingress Controller, their deployment as DaemonSets, deployment configuration options, see the [RKE documentation]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/ingress-controllers/).
|
||||
|
||||
## Load Balancing Architecture
|
||||
|
||||
@@ -128,7 +128,7 @@ Rancher v2.x Ingress functionality supports the HTTPS protocol, but if you want
|
||||
|
||||
#### Layer-4 Load Balancer
|
||||
|
||||
For the TCP protocol, Rancher v2.x supports configuring a Layer 4 load balancer using the cloud provider in which your Kubernetes cluster is deployed. Once this load balancer appliance is configured for your cluster, when you choose the option of a `Layer-4 Load Balancer` for port-mapping during workload deployment, Rancher automatically creates a corresponding load balancer service. This service will call the corresponding cloud provider and configure the load balancer appliance to route requests to the appropriate pods. See [Cloud Providers](https://rancher.com/docs/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/cloud-providers/) for information on how to configure LoadBalancer services for your cloud provider.
|
||||
For the TCP protocol, Rancher v2.x supports configuring a Layer 4 load balancer using the cloud provider in which your Kubernetes cluster is deployed. Once this load balancer appliance is configured for your cluster, when you choose the option of a `Layer-4 Load Balancer` for port-mapping during workload deployment, Rancher automatically creates a corresponding load balancer service. This service will call the corresponding cloud provider and configure the load balancer appliance to route requests to the appropriate pods. See [Cloud Providers]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/cloud-providers/) for information on how to configure LoadBalancer services for your cloud provider.
|
||||
|
||||
For example, if we create a deployment named `myapp` and specify a Layer 4 load balancer in the **Port Mapping** section, Rancher will automatically add an entry to the **Load Balancer** tab named `myapp-loadbalancer`.
|
||||
|
||||
@@ -152,7 +152,7 @@ The key in the ConfigMap entry should be the TCP port that you want to expose fo
|
||||
|
||||
## Rancher v2.x Load Balancing Limitations
|
||||
|
||||
Cattle provided feature-rich load balancer support that is [well documented](https://rancher.com/docs/rancher/v1.6/en/cattle/adding-load-balancers/#load-balancers). Some of these features do not have equivalents in Rancher v2.x. This is the list of such features:
|
||||
Cattle provided feature-rich load balancer support that is [well documented]({{< baseurl >}}/rancher/v1.6/en/cattle/adding-load-balancers/#load-balancers). Some of these features do not have equivalents in Rancher v2.x. This is the list of such features:
|
||||
|
||||
- No support for SNI in current NGINX Ingress Controller.
|
||||
- TCP load balancing requires a load balancer appliance enabled by cloud provider within the cluster. There is no Ingress support for TCP on Kubernetes.
|
||||
|
||||
@@ -9,7 +9,7 @@ For Rancher v2.x, we've replaced the health check microservice, leveraging inste
|
||||
|
||||
Use this document to correct Rancher v2.x workloads and services that list `health_check` in `output.txt`. You can correct them by configuring a liveness probe (i.e., a health check).
|
||||
|
||||
For example, for the image below, we would configure liveness probes for the `web` and `weblb` workloads (i.e., the Kubernetes manifests output by migration-tools CLI).
|
||||
For example, for the image below, we would configure liveness probes for the `web` and `weblb` workloads (i.e., the Kubernetes manifests output by migration-tools CLI).
|
||||
|
||||
<figcaption>Resolve <code>health_check</code> for the <code>web</code> and <code>webLB</code> Workloads</figcaption>
|
||||
|
||||
@@ -34,7 +34,7 @@ The health check microservice features two types of health checks, which have a
|
||||
|
||||
- **TCP health checks**:
|
||||
|
||||
These health checks check if a TCP connection opens at the specified port for the monitored service. For full details, see the [Rancher v1.6 documentation](https://rancher.com/docs/rancher/v1.6/en/cattle/health-checks/).
|
||||
These health checks check if a TCP connection opens at the specified port for the monitored service. For full details, see the [Rancher v1.6 documentation]({{< baseurl >}}/rancher/v1.6/en/cattle/health-checks/).
|
||||
|
||||
- **HTTP health checks**:
|
||||
|
||||
@@ -89,7 +89,7 @@ Configure probes by using the **Health Check** section while editing deployments
|
||||
|
||||
### Configuring Checks
|
||||
|
||||
While you create a workload using Rancher v2.x, we recommend configuring a check that monitors the health of the deployment's pods.
|
||||
While you create a workload using Rancher v2.x, we recommend configuring a check that monitors the health of the deployment's pods.
|
||||
|
||||
{{% tabs %}}
|
||||
|
||||
|
||||
@@ -5,7 +5,7 @@ weight: 100
|
||||
|
||||
Although your services from v1.6 won't work in Rancher v2.x by default, that doesn't mean you have to start again from square one, manually rebuilding your applications in v2.x. To help with migration from v1.6 to v2.x, Rancher has developed a migration tool. The migration-tools CLI is a utility that helps you recreate your applications in Rancher v2.x. This tool exports your Rancher v1.6 services as Compose files and converts them to a Kubernetes manifest that Rancher v2.x can consume.
|
||||
|
||||
Additionally, for each Rancher v1.6-specific Compose directive that cannot be consumed by Kubernetes, migration-tools CLI provides instructions on how to manually recreate them in Rancher v2.x.
|
||||
Additionally, for each Rancher v1.6-specific Compose directive that cannot be consumed by Kubernetes, migration-tools CLI provides instructions on how to manually recreate them in Rancher v2.x.
|
||||
|
||||
This command line interface tool will:
|
||||
|
||||
@@ -50,7 +50,7 @@ After you download migration-tools CLI, rename it and make it executable.
|
||||
|
||||
Next, use the migration-tools CLI to export all stacks in all of the Cattle environments into Compose files. Then, for stacks that you want to migrate to Rancher v2.x, convert the Compose files into Kubernetes manifest.
|
||||
|
||||
>**Prerequisite:** Create an [Account API Key](https://rancher.com/docs/rancher/v1.6/en/api/v2-beta/api-keys/#account-api-keys) to authenticate with Rancher v1.6 when using the migration-tools CLI.
|
||||
>**Prerequisite:** Create an [Account API Key]({{< baseurl >}}/rancher/v1.6/en/api/v2-beta/api-keys/#account-api-keys) to authenticate with Rancher v1.6 when using the migration-tools CLI.
|
||||
|
||||
1. Export the Docker Compose files for your Cattle environments and stacks from Rancher v1.6.
|
||||
|
||||
@@ -231,7 +231,7 @@ status: {}
|
||||
|
||||
## D. Re-Deploy Services as Kubernetes Manifests
|
||||
|
||||
>**Note:** Although these instructions deploy your v1.6 services in Rancher v2.x, they will not work correctly until you adjust their Kubernetes manifests.
|
||||
>**Note:** Although these instructions deploy your v1.6 services in Rancher v2.x, they will not work correctly until you adjust their Kubernetes manifests.
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher UI" %}}
|
||||
@@ -260,7 +260,7 @@ Use the following Rancher CLI commands to deploy your application using Rancher
|
||||
|
||||
./rancher kubectl create -f <SERVICE_YAML_FILE> # DEPLOY THE SERVICE YAML
|
||||
```
|
||||
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
|
||||
@@ -273,7 +273,7 @@ Following importation, you can view your v1.6 services in the v2.x UI as Kuberne
|
||||
|
||||
## What Now?
|
||||
|
||||
Although the migration-tool CLI parses your Rancher v1.6 Compose files to Kubernetes manifests, there are discrepancies between v1.6 and v2.x that you must address by manually editing your parsed [Kubernetes manifests](#output). In other words, you need to edit each workload and service imported into Rancher v2.x, as displayed below.
|
||||
Although the migration-tool CLI parses your Rancher v1.6 Compose files to Kubernetes manifests, there are discrepancies between v1.6 and v2.x that you must address by manually editing your parsed [Kubernetes manifests](#output). In other words, you need to edit each workload and service imported into Rancher v2.x, as displayed below.
|
||||
|
||||
<figcaption>Edit Migrated Services</figcaption>
|
||||
|
||||
@@ -306,7 +306,7 @@ start_on_create | No Kubernetes equivalent. No action is required from you.
|
||||
|
||||
<!-- MB: oops, skipped 6 -->
|
||||
|
||||
[7]:{{< baseurl >}}/rancher/v2.x/en/v1.6-migration/schedule-workloads/#scheduling-using-labels
|
||||
[7]:{{< baseurl >}}/rancher/v2.x/en/v1.6-migration/schedule-workloads/#scheduling-using-labels
|
||||
[8]:{{< baseurl >}}/rancher/v2.x/en/v1.6-migration/schedule-workloads/#scheduling-global-services
|
||||
[9]:{{< baseurl >}}/rancher/v2.x/en/v1.6-migration/schedule-workloads/#label-affinity-antiaffinity
|
||||
|
||||
|
||||
@@ -14,7 +14,7 @@ You can schedule your migrated v1.6 services while editing a deployment. Schedul
|
||||
<figcaption>Editing Workloads: Workload Type and Node Scheduling Sections</figcaption>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## In This Document
|
||||
|
||||
@@ -31,12 +31,12 @@ You can schedule your migrated v1.6 services while editing a deployment. Schedul
|
||||
- [Scheduling Global Services](#scheduling-global-services)
|
||||
|
||||
|
||||
<!-- /TOC -->
|
||||
<!-- /TOC -->
|
||||
|
||||
## What's Different for Scheduling Services?
|
||||
|
||||
|
||||
Rancher v2.x retains _all_ methods available in v1.6 for scheduling your services. However, because the default container orchestration system has changed from Cattle to Kubernetes, the terminology and implementation for each scheduling option has changed.
|
||||
Rancher v2.x retains _all_ methods available in v1.6 for scheduling your services. However, because the default container orchestration system has changed from Cattle to Kubernetes, the terminology and implementation for each scheduling option has changed.
|
||||
|
||||
In v1.6, you would schedule a service to a host while adding a service to a Stack. In Rancher v2.x., the equivalent action is to schedule a workload for deployment. The following composite image shows a comparison of the UI used for scheduling in Rancher v2.x versus v1.6.
|
||||
|
||||
@@ -44,7 +44,7 @@ In v1.6, you would schedule a service to a host while adding a service to a Stac
|
||||
|
||||
## Node Scheduling Options
|
||||
|
||||
Rancher offers a variety of options when scheduling nodes to host workload pods (i.e., scheduling hosts for containers in Rancher v1.6).
|
||||
Rancher offers a variety of options when scheduling nodes to host workload pods (i.e., scheduling hosts for containers in Rancher v1.6).
|
||||
|
||||
You can choose a scheduling option as you deploy a workload. The term _workload_ is synonymous with adding a service to a Stack in Rancher v1.6). You can deploy a workload by using the context menu to browse to a cluster project (`<CLUSTER> > <PROJECT> > Workloads`).
|
||||
|
||||
@@ -52,23 +52,23 @@ The sections that follow provide information on using each scheduling options, a
|
||||
|
||||
Option | v1.6 Feature | v2.x Feature
|
||||
-------|------|------
|
||||
[Schedule a certain number of pods?](#schedule-a-certain-number-of-pods) | ✓ | ✓
|
||||
[Schedule a certain number of pods?](#schedule-a-certain-number-of-pods) | ✓ | ✓
|
||||
[Schedule pods to specific node?](#scheduling-pods-to-a-specific-node) | ✓ | ✓
|
||||
[Schedule to nodes using labels?](#scheduling-pods-using-labels) | ✓ | ✓
|
||||
[Schedule to nodes using labels?](#scheduling-pods-using-labels) | ✓ | ✓
|
||||
[Schedule to nodes using label affinity/anti-affinity rules?](#scheduling-pods-using-affinityanti-affinity-label) | ✓ | ✓
|
||||
[Schedule based on resource constraints?](#scheduling-pods-using-resource-constraints) | ✓ | ✓
|
||||
[Preventing scheduling specific services to specific hosts?](#preventing-scheduling-specific-services-to-specific-nodes) | ✓ | ✓
|
||||
[Schedule services globally?](#scheduling-global-services) | ✓ | ✓
|
||||
[Schedule services globally?](#scheduling-global-services) | ✓ | ✓
|
||||
|
||||
|
||||
### Schedule a certain number of pods
|
||||
|
||||
In v1.6, you could control the number of container replicas deployed for a service. You can schedule pods the same way in v2.x, but you'll have to set the scale manually while editing a workload.
|
||||
In v1.6, you could control the number of container replicas deployed for a service. You can schedule pods the same way in v2.x, but you'll have to set the scale manually while editing a workload.
|
||||
|
||||
|
||||
|
||||
|
||||
During migration, you can resolve `scale` entries in `output.txt` by setting a value for the **Workload Type** option **Scalable deployment** depicted below.
|
||||
During migration, you can resolve `scale` entries in `output.txt` by setting a value for the **Workload Type** option **Scalable deployment** depicted below.
|
||||
|
||||
<figcaption>Scalable Deployment Option</figcaption>
|
||||
|
||||
@@ -87,7 +87,7 @@ As you deploy a workload, use the **Node Scheduling** section to choose a node t
|
||||
|
||||
|
||||
|
||||
Rancher schedules pods to the node you select if 1) there are compute resource available for the node and 2) you've configured port mapping to use the HostPort option, that there are no port conflicts.
|
||||
Rancher schedules pods to the node you select if 1) there are compute resource available for the node and 2) you've configured port mapping to use the HostPort option, that there are no port conflicts.
|
||||
|
||||
If you expose the workload using a NodePort that conflicts with another workload, the deployment gets created successfully, but no NodePort service is created. Therefore, the workload isn't exposed outside of the cluster.
|
||||
|
||||
@@ -97,7 +97,7 @@ After the workload is created, you can confirm that the pods are scheduled to yo
|
||||
|
||||
<!--
|
||||
|
||||
If you export the workload's manifest for Rancher v2.x, you can see in the pod spec that the workload is scheduled to the node that you selected (`nodeName: mark-do1`).
|
||||
If you export the workload's manifest for Rancher v2.x, you can see in the pod spec that the workload is scheduled to the node that you selected (`nodeName: mark-do1`).
|
||||
|
||||
<figcaption>Kubernetes manifest: All Pods Scheduled to Single Node</figcaption>
|
||||
|
||||
@@ -143,7 +143,7 @@ In Rancher v2.x, you can constrain pods for scheduling to specific nodes (referr
|
||||
Label Object | Rancher v1.6 | Rancher v2.x
|
||||
-------------|--------------|---------------
|
||||
Schedule by Node? | ✓ | ✓
|
||||
Schedule by Pod? | ✓ | ✓
|
||||
Schedule by Pod? | ✓ | ✓
|
||||
|
||||
#### Applying Labels to Nodes and Pods
|
||||
|
||||
@@ -157,7 +157,7 @@ To apply labels to pods, make additions to the **Labels and Annotations** sectio
|
||||
|
||||
#### Label Affinity/AntiAffinity
|
||||
|
||||
Some of the most-used scheduling features in v1.6 were affinity and anti-affinity rules.
|
||||
Some of the most-used scheduling features in v1.6 were affinity and anti-affinity rules.
|
||||
|
||||
<figcaption><code>output.txt</code> Affinity Label</figcaption>
|
||||
|
||||
@@ -166,7 +166,7 @@ Some of the most-used scheduling features in v1.6 were affinity and anti-affinit
|
||||
- **Affinity**
|
||||
|
||||
Any pods that share the same label are scheduled to the same node. Affinity can be configured in one of two ways:
|
||||
|
||||
|
||||
Affinity | Description
|
||||
---------|------------
|
||||
**Hard** | A hard affinity rule means that the host chosen must satisfy all the scheduling rules. If no such host can be found, the workload will fail to deploy. In the Kubernetes manifest, this rule translates to the `nodeAffinity` directive.<br/><br/>To use hard affinity, configure a rule using the **Require ALL of** section (see figure below).
|
||||
@@ -181,9 +181,9 @@ Some of the most-used scheduling features in v1.6 were affinity and anti-affinit
|
||||
|
||||
- **AntiAffinity**
|
||||
|
||||
Any pods that share the same label are scheduled to different nodes. In other words, while affinity _attracts_ a specific label to each other, anti-affinity _repels_ a label from itself, so that pods are scheduled to different nodes.
|
||||
Any pods that share the same label are scheduled to different nodes. In other words, while affinity _attracts_ a specific label to each other, anti-affinity _repels_ a label from itself, so that pods are scheduled to different nodes.
|
||||
|
||||
You can create an anti-affinity rules using either hard or soft affinity. However, when creating your rule, you must use either the `is not set` or `not in list` operator.
|
||||
You can create an anti-affinity rules using either hard or soft affinity. However, when creating your rule, you must use either the `is not set` or `not in list` operator.
|
||||
|
||||
For anti-affinity rules, we recommend using labels with phrases like `NotIn` and `DoesNotExist`, as these terms are more intuitive when users are applying anti-affinity rules.
|
||||
|
||||
@@ -208,11 +208,11 @@ In Rancher v2.x, you can prevent pods from being scheduled to specific nodes by
|
||||
|
||||
|
||||
|
||||
For more information, see the Kubernetes documentation on [taints and tolerations](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/).
|
||||
For more information, see the Kubernetes documentation on [taints and tolerations](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/).
|
||||
|
||||
### Scheduling Global Services
|
||||
|
||||
Rancher v1.6 included the ability to deploy [global services](https://rancher.com/docs/rancher/v1.6/en/cattle/scheduling/#global-service), which are services that deploy duplicate containers to each host in the environment (i.e., nodes in your cluster using Rancher v2.x terms). If a service has the `io.rancher.scheduler.global: 'true'` label declared, then Rancher v1.6 schedules a service container on each host in the environment.
|
||||
Rancher v1.6 included the ability to deploy [global services]({{< baseurl >}}/rancher/v1.6/en/cattle/scheduling/#global-service), which are services that deploy duplicate containers to each host in the environment (i.e., nodes in your cluster using Rancher v2.x terms). If a service has the `io.rancher.scheduler.global: 'true'` label declared, then Rancher v1.6 schedules a service container on each host in the environment.
|
||||
|
||||
|
||||
<figcaption><code>output.txt</code> Global Service Label</figcaption>
|
||||
@@ -222,7 +222,7 @@ Rancher v1.6 included the ability to deploy [global services](https://rancher.co
|
||||
|
||||
In Rancher v2.x, you can schedule a pod to each node using a [Kubernetes DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/), which is a specific type of workload <!-- link -->). A _DaemonSet_ functions exactly like a Rancher v1.6 global service. The Kubernetes scheduler deploys a pod on each node of the cluster, and as new nodes are added, the scheduler will start new pods on them provided they match the scheduling requirements of the workload. Additionally, in v2.x, you can also limit a DaemonSet to be deployed to nodes that have a specific label.
|
||||
|
||||
To create a daemonset while configuring a workload, choose **Run one pod on each node** from the the **Workload Type** options.
|
||||
To create a daemonset while configuring a workload, choose **Run one pod on each node** from the the **Workload Type** options.
|
||||
|
||||
<figcaption>Workload Configuration: Choose run one pod on each node to configure daemonset</figcaption>
|
||||
|
||||
@@ -230,22 +230,22 @@ To create a daemonset while configuring a workload, choose **Run one pod on each
|
||||
|
||||
### Scheduling Pods Using Resource Constraints
|
||||
|
||||
While creating a service in the Rancher v1.6 UI, you could schedule its containers to hosts based on hardware requirements that you choose. The containers are then scheduled to hosts based on which ones have bandwidth, memory, and CPU capacity.
|
||||
While creating a service in the Rancher v1.6 UI, you could schedule its containers to hosts based on hardware requirements that you choose. The containers are then scheduled to hosts based on which ones have bandwidth, memory, and CPU capacity.
|
||||
|
||||
In Rancher v2.x, you can still specify the resources required by your pods. However, these options are unavailable in the UI. Instead, you must edit your workload's manifest file to declare these resource constraints.
|
||||
|
||||
To declare resource constraints, edit your migrated workloads, editing the **Security & Host** sections.
|
||||
To declare resource constraints, edit your migrated workloads, editing the **Security & Host** sections.
|
||||
|
||||
- To reserve a minimum hardware reservation available for your pod(s), edit the following sections:
|
||||
|
||||
- Memory Reservation
|
||||
- CPU Reservation
|
||||
- NVIDIA GPU Reservation
|
||||
- NVIDIA GPU Reservation
|
||||
|
||||
- To set a maximum hardware limit for your pods, edit:
|
||||
|
||||
- Memory Limit
|
||||
- CPU Limit
|
||||
- Memory Limit
|
||||
- CPU Limit
|
||||
|
||||
<figcaption>Scheduling: Resource Constraint Settings</figcaption>
|
||||
|
||||
|
||||
Reference in New Issue
Block a user