mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-26 21:18:04 +00:00
@@ -16,7 +16,7 @@ The following diagram illustrates the above configuration:
|
|||||||
|
|
||||||
In this architecture a server node is defined as a machine (bare-metal or virtual) running the `k3s server` command. A worker node is defined as a machine running the `k3s agent` command.
|
In this architecture a server node is defined as a machine (bare-metal or virtual) running the `k3s server` command. A worker node is defined as a machine running the `k3s agent` command.
|
||||||
|
|
||||||
Workers register through the fixed registration address, but after registration they establish a connection directly to one of the sever nodes. This is a websocket connection initiated by the `k3s agent` process and it is maintained by a client-side load balancer running as part of the agent process.
|
Workers register through the fixed registration address, but after registration they establish a connection directly to one of the server nodes. This is a websocket connection initiated by the `k3s agent` process and it is maintained by a client-side load balancer running as part of the agent process.
|
||||||
|
|
||||||
Installation Outline
|
Installation Outline
|
||||||
--------------------
|
--------------------
|
||||||
|
|||||||
@@ -34,7 +34,7 @@ Visit the [Project Calico Docs](https://docs.projectcalico.org/) website. Follow
|
|||||||
}
|
}
|
||||||
```
|
```
|
||||||
|
|
||||||
Applyl the Canal YAML.
|
Apply the Canal YAML.
|
||||||
|
|
||||||
Ensure the settings were applied by running the following command on the host:
|
Ensure the settings were applied by running the following command on the host:
|
||||||
|
|
||||||
@@ -68,4 +68,3 @@ You should see that IP forwarding is set to true.
|
|||||||
|
|
||||||
{{% /tab %}}
|
{{% /tab %}}
|
||||||
{{% /tabs %}}
|
{{% /tabs %}}
|
||||||
|
|
||||||
|
|||||||
@@ -14,7 +14,7 @@ weight: 303
|
|||||||
<p style="padding: 8px">Please submit possible security issues by emailing <a href="mailto:security@rancher.com">security@rancher.com</a></p>
|
<p style="padding: 8px">Please submit possible security issues by emailing <a href="mailto:security@rancher.com">security@rancher.com</a></p>
|
||||||
</td>
|
</td>
|
||||||
<td width="30%" style="border: none;">
|
<td width="30%" style="border: none;">
|
||||||
<h4>Announcments</h4>
|
<h4>Announcements</h4>
|
||||||
<p style="padding: 8px">Subscribe to the <a href="https://forums.rancher.com/c/announcements">Rancher announcements forum</a> for release updates.</p>
|
<p style="padding: 8px">Subscribe to the <a href="https://forums.rancher.com/c/announcements">Rancher announcements forum</a> for release updates.</p>
|
||||||
</td>
|
</td>
|
||||||
</tr>
|
</tr>
|
||||||
|
|||||||
@@ -49,7 +49,7 @@ On desktop systems the Syslinux boot menu can be switched to graphical mode by a
|
|||||||
|
|
||||||
#### Recovery console
|
#### Recovery console
|
||||||
|
|
||||||
`rancher.recovery=true` will start a single user `root` bash session as easily in the boot process, with no network, or persitent filesystem mounted. This can be used to fix disk problems, or to debug your system.
|
`rancher.recovery=true` will start a single user `root` bash session as easily in the boot process, with no network, or persistent filesystem mounted. This can be used to fix disk problems, or to debug your system.
|
||||||
|
|
||||||
#### Enable/Disable sshd
|
#### Enable/Disable sshd
|
||||||
|
|
||||||
@@ -61,7 +61,7 @@ On desktop systems the Syslinux boot menu can be switched to graphical mode by a
|
|||||||
|
|
||||||
#### Autologin console
|
#### Autologin console
|
||||||
|
|
||||||
`rancher.autologin=<tty...>` will automatically log in the sepcified console - common values are `tty1`, `ttyS0` and `ttyAMA0` - depending on your platform.
|
`rancher.autologin=<tty...>` will automatically log in the specified console - common values are `tty1`, `ttyS0` and `ttyAMA0` - depending on your platform.
|
||||||
|
|
||||||
#### Enable/Disable hypervisor service auto-enable
|
#### Enable/Disable hypervisor service auto-enable
|
||||||
|
|
||||||
|
|||||||
@@ -259,7 +259,7 @@ password: xCrw6fEG
|
|||||||
======================================
|
======================================
|
||||||
```
|
```
|
||||||
|
|
||||||
In System Docker, you can SSH into any Other Uesr Docker Container using `ssh`.
|
In System Docker, you can SSH into any Other User Docker Container using `ssh`.
|
||||||
|
|
||||||
```
|
```
|
||||||
$ system-docker ps
|
$ system-docker ps
|
||||||
|
|||||||
@@ -244,7 +244,7 @@ $ sudo system-docker restart network
|
|||||||
|
|
||||||
_Available as of v1.5_
|
_Available as of v1.5_
|
||||||
|
|
||||||
In order to support 4G-LTE, 4G-LTE module will need to be connected to the motherboard and to get a good signal, an external atenna will need to be added. You can assemble such a device, which supports USB interface and SIM cards slot:
|
In order to support 4G-LTE, 4G-LTE module will need to be connected to the motherboard and to get a good signal, an external antenna will need to be added. You can assemble such a device, which supports USB interface and SIM cards slot:
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
|
|||||||
@@ -3,7 +3,7 @@ title: Digital Ocean
|
|||||||
weight: 107
|
weight: 107
|
||||||
---
|
---
|
||||||
|
|
||||||
RancherOS is avaliable in the Digital Ocean portal. RancherOS is a member of container distributions and you can find it easily.
|
RancherOS is available in the Digital Ocean portal. RancherOS is a member of container distributions and you can find it easily.
|
||||||
|
|
||||||
>**Note**
|
>**Note**
|
||||||
>Deploying to Digital Ocean will incur charges.
|
>Deploying to Digital Ocean will incur charges.
|
||||||
|
|||||||
@@ -126,7 +126,7 @@ Once you have completed the configuration, proceed by testing the connection to
|
|||||||
|
|
||||||
## Annex: Identify Search Base and Schema using ldapsearch
|
## Annex: Identify Search Base and Schema using ldapsearch
|
||||||
|
|
||||||
In order to successfully configure AD authentication it is crucial that you provide the correct configuration pertaining to the hirarchy and schema of your AD server.
|
In order to successfully configure AD authentication it is crucial that you provide the correct configuration pertaining to the hierarchy and schema of your AD server.
|
||||||
|
|
||||||
The [`ldapsearch`](http://manpages.ubuntu.com/manpages/artful/man1/ldapsearch.1.html) tool allows you to query your AD server to learn about the schema used for user and group objects.
|
The [`ldapsearch`](http://manpages.ubuntu.com/manpages/artful/man1/ldapsearch.1.html) tool allows you to query your AD server to learn about the schema used for user and group objects.
|
||||||
|
|
||||||
|
|||||||
@@ -58,7 +58,7 @@ As a workaround to get this capability, G Suite recommends creating a service ac
|
|||||||
This section describes how to:
|
This section describes how to:
|
||||||
|
|
||||||
- Create a service account
|
- Create a service account
|
||||||
- Create a key for the service account and download the credenials as JSON
|
- Create a key for the service account and download the credentials as JSON
|
||||||
|
|
||||||
1. Click [here](https://console.developers.google.com/iam-admin/serviceaccounts) and select your project for which you generated OAuth credentials.
|
1. Click [here](https://console.developers.google.com/iam-admin/serviceaccounts) and select your project for which you generated OAuth credentials.
|
||||||
1. Click on **Create Service Account.**
|
1. Click on **Create Service Account.**
|
||||||
|
|||||||
@@ -1,6 +1,6 @@
|
|||||||
---
|
---
|
||||||
title: Configuring Keycloak (SAML)
|
title: Configuring Keycloak (SAML)
|
||||||
description: Create a Keycloack SAML client and configure Rancher to work with Keycloak. By the end your users will be able to sign into Rancher using their Keycloak logins
|
description: Create a Keycloak SAML client and configure Rancher to work with Keycloak. By the end your users will be able to sign into Rancher using their Keycloak logins
|
||||||
weight: 1200
|
weight: 1200
|
||||||
---
|
---
|
||||||
_Available as of v2.1.0_
|
_Available as of v2.1.0_
|
||||||
@@ -64,7 +64,7 @@ If your organization uses Keycloak Identity Provider (IdP) for user authenticati
|
|||||||
|
|
||||||
## Annex: Troubleshooting
|
## Annex: Troubleshooting
|
||||||
|
|
||||||
If you are experiencing issues while testing the connection to the Keycloak server, first double-check the confiuration option of your SAML client. You may also inspect the Rancher logs to help pinpointing the problem cause. Debug logs may contain more detailed information about the error. Please refer to [How can I enable debug logging]({{< baseurl >}}/rancher/v2.x/en/faq/technical/#how-can-i-enable-debug-logging) in this documentation.
|
If you are experiencing issues while testing the connection to the Keycloak server, first double-check the configuration option of your SAML client. You may also inspect the Rancher logs to help pinpointing the problem cause. Debug logs may contain more detailed information about the error. Please refer to [How can I enable debug logging]({{< baseurl >}}/rancher/v2.x/en/faq/technical/#how-can-i-enable-debug-logging) in this documentation.
|
||||||
|
|
||||||
### You are not redirected to Keycloak
|
### You are not redirected to Keycloak
|
||||||
|
|
||||||
@@ -112,4 +112,3 @@ You are left with something similar as the example below:
|
|||||||
|
|
||||||
</EntityDescriptor>
|
</EntityDescriptor>
|
||||||
```
|
```
|
||||||
|
|
||||||
|
|||||||
@@ -11,7 +11,7 @@ If your organization uses Ping Identity Provider (IdP) for user authentication,
|
|||||||
>- You must have a [Ping IdP Server](https://www.pingidentity.com/) configured.
|
>- You must have a [Ping IdP Server](https://www.pingidentity.com/) configured.
|
||||||
>- Following are the Rancher Service Provider URLs needed for configuration:
|
>- Following are the Rancher Service Provider URLs needed for configuration:
|
||||||
Metadata URL: `https://<rancher-server>/v1-saml/ping/saml/metadata`
|
Metadata URL: `https://<rancher-server>/v1-saml/ping/saml/metadata`
|
||||||
Assertion Consure Service (ACS) URL: `https://<rancher-server>/v1-saml/ping/saml/acs`
|
Assertion Consumer Service (ACS) URL: `https://<rancher-server>/v1-saml/ping/saml/acs`
|
||||||
>- Export a `metadata.xml` file from your IdP Server. For more information, see the [PingIdentity documentation](https://documentation.pingidentity.com/pingfederate/pf83/index.shtml#concept_exportingMetadata.html).
|
>- Export a `metadata.xml` file from your IdP Server. For more information, see the [PingIdentity documentation](https://documentation.pingidentity.com/pingfederate/pf83/index.shtml#concept_exportingMetadata.html).
|
||||||
|
|
||||||
1. From the **Global** view, select **Security > Authentication** from the main menu.
|
1. From the **Global** view, select **Security > Authentication** from the main menu.
|
||||||
|
|||||||
@@ -29,7 +29,7 @@ Rancher will periodically refresh the user information even before a user logs i
|
|||||||
|
|
||||||
- **`auth-user-info-max-age-seconds`**
|
- **`auth-user-info-max-age-seconds`**
|
||||||
|
|
||||||
This setting controls how old a user's information can be before Rancher refreshes it. If a user makes an API call (either directly or by using the Rancher CLI or kubectl) and the time since the user's last refresh is greater than this setting, then Rancher will trigger a refresh. This settting defaults to `3600` seconds, i.e. 1 hour.
|
This setting controls how old a user's information can be before Rancher refreshes it. If a user makes an API call (either directly or by using the Rancher CLI or kubectl) and the time since the user's last refresh is greater than this setting, then Rancher will trigger a refresh. This setting defaults to `3600` seconds, i.e. 1 hour.
|
||||||
|
|
||||||
- **`auth-user-info-resync-cron`**
|
- **`auth-user-info-resync-cron`**
|
||||||
|
|
||||||
|
|||||||
@@ -126,7 +126,7 @@ The following table lists each built-in custom project role available in Rancher
|
|||||||
> **Notes:**
|
> **Notes:**
|
||||||
>
|
>
|
||||||
>- Each project role listed above, including `Owner`, `Member`, and `Read Only`, is comprised of multiple rules granting access to various resources. You can view the roles and their rules on the Global > Security > Roles page.
|
>- Each project role listed above, including `Owner`, `Member`, and `Read Only`, is comprised of multiple rules granting access to various resources. You can view the roles and their rules on the Global > Security > Roles page.
|
||||||
>- When viewing the resources associated with default roles created by Rancher, if there are multiple Kuberenetes API resources on one line item, the resource will have `(Custom)` appended to it. These are not custom resources but just an indication that there are multiple Kubernetes API resources as one resource.
|
>- When viewing the resources associated with default roles created by Rancher, if there are multiple Kubernetes API resources on one line item, the resource will have `(Custom)` appended to it. These are not custom resources but just an indication that there are multiple Kubernetes API resources as one resource.
|
||||||
>- The `Manage Project Members` role allows the project owner to manage any members of the project **and** grant them any project scoped role regardless of their access to the project resources. Be cautious when assigning this role out individually.
|
>- The `Manage Project Members` role allows the project owner to manage any members of the project **and** grant them any project scoped role regardless of their access to the project resources. Be cautious when assigning this role out individually.
|
||||||
|
|
||||||
### Defining Custom Roles
|
### Defining Custom Roles
|
||||||
@@ -161,7 +161,7 @@ You can change the cluster or project role(s) that are automatically assigned to
|
|||||||
|
|
||||||
1. Enable the role as default.
|
1. Enable the role as default.
|
||||||
{{% accordion id="cluster" label="For Clusters" %}}
|
{{% accordion id="cluster" label="For Clusters" %}}
|
||||||
1. From **Clustor Creator Default**, choose **Yes: Default role for new cluster creation**.
|
1. From **Cluster Creator Default**, choose **Yes: Default role for new cluster creation**.
|
||||||
1. Click **Save**.
|
1. Click **Save**.
|
||||||
{{% /accordion %}}
|
{{% /accordion %}}
|
||||||
{{% accordion id="project" label="For Projects" %}}
|
{{% accordion id="project" label="For Projects" %}}
|
||||||
@@ -181,4 +181,3 @@ When you revoke the cluster membership for a standard user that's explicitly ass
|
|||||||
- Exercise any [individual project roles](#project-role-reference) they are assigned.
|
- Exercise any [individual project roles](#project-role-reference) they are assigned.
|
||||||
|
|
||||||
If you want to completely revoke a user's access within a cluster, revoke both their cluster and project memberships.
|
If you want to completely revoke a user's access within a cluster, revoke both their cluster and project memberships.
|
||||||
|
|
||||||
|
|||||||
@@ -152,7 +152,7 @@ If a user is removed from the external authentication provider group, they would
|
|||||||
> **Prerequisites:** You can only assign a global role to a group if:
|
> **Prerequisites:** You can only assign a global role to a group if:
|
||||||
>
|
>
|
||||||
> * You have set up an [external authentication provider]({{<baseurl>}}/rancher/v2.x/en/admin-settings/authentication/#external-vs-local-authentication)
|
> * You have set up an [external authentication provider]({{<baseurl>}}/rancher/v2.x/en/admin-settings/authentication/#external-vs-local-authentication)
|
||||||
> * The external authentication provider suppports [user groups]({{<baseurl>}}/rancher/v2.x/en/admin-settings/authentication/user-groups/)
|
> * The external authentication provider supports [user groups]({{<baseurl>}}/rancher/v2.x/en/admin-settings/authentication/user-groups/)
|
||||||
> * You have already set up at least one user group with the authentication provider
|
> * You have already set up at least one user group with the authentication provider
|
||||||
|
|
||||||
To assign a custom global role to a group, follow these steps:
|
To assign a custom global role to a group, follow these steps:
|
||||||
|
|||||||
@@ -143,7 +143,7 @@ If a user is removed from the external authentication provider group, they would
|
|||||||
> **Prerequisites:** You can only assign a global role to a group if:
|
> **Prerequisites:** You can only assign a global role to a group if:
|
||||||
>
|
>
|
||||||
> * You have set up an [external authentication provider]({{<baseurl>}}/rancher/v2.x/en/admin-settings/authentication/#external-vs-local-authentication)
|
> * You have set up an [external authentication provider]({{<baseurl>}}/rancher/v2.x/en/admin-settings/authentication/#external-vs-local-authentication)
|
||||||
> * The external authentication provider suppports [user groups]({{<baseurl>}}/rancher/v2.x/en/admin-settings/authentication/user-groups/)
|
> * The external authentication provider supports [user groups]({{<baseurl>}}/rancher/v2.x/en/admin-settings/authentication/user-groups/)
|
||||||
> * You have already set up at least one user group with the authentication provider
|
> * You have already set up at least one user group with the authentication provider
|
||||||
|
|
||||||
To assign a custom global role to a group, follow these steps:
|
To assign a custom global role to a group, follow these steps:
|
||||||
|
|||||||
@@ -102,7 +102,7 @@ As of Rancher v2.3.3, you can [save the configuration of an existing cluster as
|
|||||||
|
|
||||||
# Standardizing Hardware
|
# Standardizing Hardware
|
||||||
|
|
||||||
RKE templates are designed to standardize Kubernetes and Rancher settings. If you want to standardize your infrastructure as well, you use RKE templates [in conjuction with other tools]({{<baseurl>}}/rancher/v2.x/en/admin-settings/rke-templates/rke-templates-and-hardware).
|
RKE templates are designed to standardize Kubernetes and Rancher settings. If you want to standardize your infrastructure as well, you use RKE templates [in conjunction with other tools]({{<baseurl>}}/rancher/v2.x/en/admin-settings/rke-templates/rke-templates-and-hardware).
|
||||||
|
|
||||||
# YAML Customization
|
# YAML Customization
|
||||||
|
|
||||||
|
|||||||
@@ -29,7 +29,7 @@ In this way, the administrators enforce the Kubernetes version across the organi
|
|||||||
|
|
||||||
# Templates for Basic and Advanced Users
|
# Templates for Basic and Advanced Users
|
||||||
|
|
||||||
Let's say an organization has both basic and advanced users. Adminstrators want the basic users to be required to use a template, while the advanced users and administrators create their clusters however they want.
|
Let's say an organization has both basic and advanced users. Administrators want the basic users to be required to use a template, while the advanced users and administrators create their clusters however they want.
|
||||||
|
|
||||||
1. First, an administrator turns on [RKE template enforcement.]({{<baseurl>}}/rancher/v2.x/en/admin-settings/rke-templates/enforcement/#requiring-new-clusters-to-use-a-cluster-template) This means that every [standard user]({{<baseurl>}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/) in Rancher will need to use an RKE template when they create a cluster.
|
1. First, an administrator turns on [RKE template enforcement.]({{<baseurl>}}/rancher/v2.x/en/admin-settings/rke-templates/enforcement/#requiring-new-clusters-to-use-a-cluster-template) This means that every [standard user]({{<baseurl>}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/) in Rancher will need to use an RKE template when they create a cluster.
|
||||||
1. The administrator then creates two templates:
|
1. The administrator then creates two templates:
|
||||||
@@ -44,7 +44,7 @@ Let's say an organization has both basic and advanced users. Adminstrators want
|
|||||||
|
|
||||||
# Updating Templates and Clusters Created with Them
|
# Updating Templates and Clusters Created with Them
|
||||||
|
|
||||||
Let's say an organization has a template that requires clusters to use Kubernetes v1.14. However, as time goes on, the adminstrators change their minds. They decide they want users to be able to upgrade their clusters to use newer versions of Kubernetes.
|
Let's say an organization has a template that requires clusters to use Kubernetes v1.14. However, as time goes on, the administrators change their minds. They decide they want users to be able to upgrade their clusters to use newer versions of Kubernetes.
|
||||||
|
|
||||||
In this organization, many clusters were created with a template that requires Kubernetes v1.14. Because the template does not allow that setting to be overridden, the users who created the cluster cannot directly edit that setting.
|
In this organization, many clusters were created with a template that requires Kubernetes v1.14. Because the template does not allow that setting to be overridden, the users who created the cluster cannot directly edit that setting.
|
||||||
|
|
||||||
|
|||||||
@@ -15,7 +15,7 @@ Rancher is container-based and can potentially run on any Linux-based operating
|
|||||||
### Upgrade Your Kubernetes Version
|
### Upgrade Your Kubernetes Version
|
||||||
Keep your Kubernetes cluster up to date with a recent and supported version. Typically the Kubernetes community will support the current version and previous three minor releases (for example, 1.14.x, 1.13.x, 1.12.x, and 1.11.x). After a new version is released, the third-oldest supported version reaches EOL (End of Life) status. Running on an EOL release can be a risk if a security issues are found and patches are not available. The community typically makes minor releases every quarter (every three months).
|
Keep your Kubernetes cluster up to date with a recent and supported version. Typically the Kubernetes community will support the current version and previous three minor releases (for example, 1.14.x, 1.13.x, 1.12.x, and 1.11.x). After a new version is released, the third-oldest supported version reaches EOL (End of Life) status. Running on an EOL release can be a risk if a security issues are found and patches are not available. The community typically makes minor releases every quarter (every three months).
|
||||||
|
|
||||||
Rancher’s SLA’s are not community dependent, but as Kubernetes is a community-driven software, the quality of experience will degrade as you get farther away from the community's supported target.
|
Rancher’s SLAs are not community dependent, but as Kubernetes is a community-driven software, the quality of experience will degrade as you get farther away from the community's supported target.
|
||||||
|
|
||||||
### Kill Pods Randomly During Testing
|
### Kill Pods Randomly During Testing
|
||||||
Run chaoskube or a similar mechanism to randomly kill pods in your test environment. This will test the resiliency of your infrastructure and the ability of Kubernetes to self-heal. It's not recommended to run this in your production environment.
|
Run chaoskube or a similar mechanism to randomly kill pods in your test environment. This will test the resiliency of your infrastructure and the ability of Kubernetes to self-heal. It's not recommended to run this in your production environment.
|
||||||
@@ -117,7 +117,7 @@ A class of service describes the expectations around cluster uptime, durability,
|
|||||||
Kubernetes clusters can span multiple classes of service, however it is important to consider the ability for one workload to affect another. Without proper deployment practices such as resource limits, requirements, etc, a deployment that is not behaving well has the potential to impact the health of the cluster. In a "dev" environment it is common for end-users to exercise less caution with deployments, thus increasing the chance of such behavior. Sharing this behavior with your production workload increases risk.
|
Kubernetes clusters can span multiple classes of service, however it is important to consider the ability for one workload to affect another. Without proper deployment practices such as resource limits, requirements, etc, a deployment that is not behaving well has the potential to impact the health of the cluster. In a "dev" environment it is common for end-users to exercise less caution with deployments, thus increasing the chance of such behavior. Sharing this behavior with your production workload increases risk.
|
||||||
|
|
||||||
### Upgrade risks
|
### Upgrade risks
|
||||||
Upgrades of Kuberentes are not without risk, the best way to predict the outcome of an upgrade is try it on a cluster of similar load and use case as your production cluster. This is where having non-prod class of service clusters can be advantageous.
|
Upgrades of Kubernetes are not without risk, the best way to predict the outcome of an upgrade is try it on a cluster of similar load and use case as your production cluster. This is where having non-prod class of service clusters can be advantageous.
|
||||||
|
|
||||||
### Resource Efficiency
|
### Resource Efficiency
|
||||||
Clusters can be built with varying degrees of redundancy. In a class of service with low expectations for uptime, resources and cost can be conserved by building clusters without redundant Kubernetes control components. This approach may also free up more budget/resources to increase the redundancy at the production level
|
Clusters can be built with varying degrees of redundancy. In a class of service with low expectations for uptime, resources and cost can be conserved by building clusters without redundant Kubernetes control components. This approach may also free up more budget/resources to increase the redundancy at the production level
|
||||||
|
|||||||
@@ -35,7 +35,7 @@ By default, only [global administrators]({{< baseurl >}}/rancher/v2.x/en/admin-s
|
|||||||
|
|
||||||
1. From the **Global View**, select **Tools > Global DNS Providers**.
|
1. From the **Global View**, select **Tools > Global DNS Providers**.
|
||||||
1. To add a provider, choose from the available provider options and configure the Global DNS Provider with necessary credentials and an optional domain.
|
1. To add a provider, choose from the available provider options and configure the Global DNS Provider with necessary credentials and an optional domain.
|
||||||
1. (Optional) Add additional users so they could use the provider when creating Globel DNS entries as well as manage the Global DNS provider.
|
1. (Optional) Add additional users so they could use the provider when creating Global DNS entries as well as manage the Global DNS provider.
|
||||||
|
|
||||||
{{% accordion id="route53" label="Route53" %}}
|
{{% accordion id="route53" label="Route53" %}}
|
||||||
1. Enter a **Name** for the provider.
|
1. Enter a **Name** for the provider.
|
||||||
@@ -81,7 +81,7 @@ By default, only [global administrators]({{< baseurl >}}/rancher/v2.x/en/admin-s
|
|||||||
|
|
||||||
In order for Global DNS entries to be programmed, you will need to add a specific annotation on an ingress in your application or target project and this ingress needs to use a specific `hostname` and an annotation that should match the FQDN of the Global DNS entry.
|
In order for Global DNS entries to be programmed, you will need to add a specific annotation on an ingress in your application or target project and this ingress needs to use a specific `hostname` and an annotation that should match the FQDN of the Global DNS entry.
|
||||||
|
|
||||||
1. For any application that you want targetted for your Global DNS entry, find an ingress associated with the application.
|
1. For any application that you want targeted for your Global DNS entry, find an ingress associated with the application.
|
||||||
1. In order for the DNS to be programmed, the following requirements must be met:
|
1. In order for the DNS to be programmed, the following requirements must be met:
|
||||||
* The ingress routing rule must be set to use a `hostname` that matches the FQDN of the Global DNS entry.
|
* The ingress routing rule must be set to use a `hostname` that matches the FQDN of the Global DNS entry.
|
||||||
* The ingress must have an annotation (`rancher.io/globalDNS.hostname`) and the value of this annotation should match the FQDN of the Global DNS entry.
|
* The ingress must have an annotation (`rancher.io/globalDNS.hostname`) and the value of this annotation should match the FQDN of the Global DNS entry.
|
||||||
|
|||||||
@@ -18,7 +18,7 @@ After creating a multi-cluster application, you can program a [Global DNS entry]
|
|||||||
|
|
||||||
3. (Optional) Review the detailed descriptions, which are derived from the Helm chart's `README`.
|
3. (Optional) Review the detailed descriptions, which are derived from the Helm chart's `README`.
|
||||||
|
|
||||||
4. Under **Configuration Options** enter a **Name** for the multi-cluster application. By default, this name is also used to create a Kubernetes namespace in each [target project](#targets) for the multi-cluster application. The namespace is named as `<MULTI-CLUSTER_APPLICTION_NAME>-<PROJECT_ID>`.
|
4. Under **Configuration Options** enter a **Name** for the multi-cluster application. By default, this name is also used to create a Kubernetes namespace in each [target project](#targets) for the multi-cluster application. The namespace is named as `<MULTI-CLUSTER_APPLICATION_NAME>-<PROJECT_ID>`.
|
||||||
|
|
||||||
5. Select a **Template Version**.
|
5. Select a **Template Version**.
|
||||||
|
|
||||||
@@ -50,7 +50,7 @@ In the **Upgrades** section, select the upgrade strategy to use, when you decide
|
|||||||
|
|
||||||
#### Roles
|
#### Roles
|
||||||
|
|
||||||
In the **Roles** section, you define the role of the multi-cluster application. Typically, when a user [launches catalog applications]({{< baseurl >}}/rancher/v2.x/en/catalog/apps/#launching-catalog-applications), that specific users's permissions are used for creation of all workloads/resources that is required by the app.
|
In the **Roles** section, you define the role of the multi-cluster application. Typically, when a user [launches catalog applications]({{< baseurl >}}/rancher/v2.x/en/catalog/apps/#launching-catalog-applications), that specific user's permissions are used for creation of all workloads/resources that is required by the app.
|
||||||
|
|
||||||
For multi-cluster applications, the application is deployed by a _system user_ and is assigned as the creator of all underlying resources. A _system user_ is used instead of the actual user due to the fact that the actual user could be removed from one of the target projects. If the actual user was removed from one of the projects, then that user would no longer be able to manage the application for the other projects.
|
For multi-cluster applications, the application is deployed by a _system user_ and is assigned as the creator of all underlying resources. A _system user_ is used instead of the actual user due to the fact that the actual user could be removed from one of the target projects. If the actual user was removed from one of the projects, then that user would no longer be able to manage the application for the other projects.
|
||||||
|
|
||||||
@@ -68,7 +68,7 @@ When launching the application, Rancher will confirm if you have these permissio
|
|||||||
|
|
||||||
For each Helm chart, there are a list of desired answers that must be entered in order to successfully deploy the chart. When entering answers, you must format them using the syntax rules found in [Using Helm: The format and limitations of –set](https://github.com/helm/helm/blob/master/docs/using_helm.md#the-format-and-limitations-of---set), as Rancher passes them as `--set` flags to Helm.
|
For each Helm chart, there are a list of desired answers that must be entered in order to successfully deploy the chart. When entering answers, you must format them using the syntax rules found in [Using Helm: The format and limitations of –set](https://github.com/helm/helm/blob/master/docs/using_helm.md#the-format-and-limitations-of---set), as Rancher passes them as `--set` flags to Helm.
|
||||||
|
|
||||||
> For example, when entering an answer that includes two values separated by a comma (i.e. `abc, bcd`), it is reuired to wrap the values with double quotes (i.e., ``"abc, bcd"``).
|
> For example, when entering an answer that includes two values separated by a comma (i.e. `abc, bcd`), it is required to wrap the values with double quotes (i.e., ``"abc, bcd"``).
|
||||||
|
|
||||||
#### Using a `questions.yml` file
|
#### Using a `questions.yml` file
|
||||||
|
|
||||||
@@ -120,7 +120,7 @@ The creator and any users added with the access-type "owner" to a multi-cluster
|
|||||||
|
|
||||||
## Multi-Cluster Application Management
|
## Multi-Cluster Application Management
|
||||||
|
|
||||||
One of the benefits of using a multi-cluster application as opposed to multiple individual applications of the same type, is the ease of manangement.Multi-cluster applications can be cloned, upgraded or rolled back.
|
One of the benefits of using a multi-cluster application as opposed to multiple individual applications of the same type, is the ease of management. Multi-cluster applications can be cloned, upgraded or rolled back.
|
||||||
|
|
||||||
1. From the **Global** view, choose **Apps** in the navigation bar.
|
1. From the **Global** view, choose **Apps** in the navigation bar.
|
||||||
|
|
||||||
|
|||||||
@@ -7,7 +7,7 @@ _Available as of v2.2.0_
|
|||||||
|
|
||||||
In the Rancher UI, etcd backup and recovery for [Rancher launched Kubernetes clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/) can be easily performed. Snapshots of the etcd database are taken and saved either [locally onto the etcd nodes](#local-backup-target) or to a [S3 compatible target](#s3-backup-target). The advantages of configuring S3 is that if all etcd nodes are lost, your snapshot is saved remotely and can be used to restore the cluster.
|
In the Rancher UI, etcd backup and recovery for [Rancher launched Kubernetes clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/) can be easily performed. Snapshots of the etcd database are taken and saved either [locally onto the etcd nodes](#local-backup-target) or to a [S3 compatible target](#s3-backup-target). The advantages of configuring S3 is that if all etcd nodes are lost, your snapshot is saved remotely and can be used to restore the cluster.
|
||||||
|
|
||||||
Rancher recommends configuring recurrent `etcd` snapshots for all production clusters. Additonally, one-time snapshots can easily be taken as well.
|
Rancher recommends configuring recurrent `etcd` snapshots for all production clusters. Additionally, one-time snapshots can easily be taken as well.
|
||||||
|
|
||||||
>**Note:** If you have any Rancher launched Kubernetes clusters that were created prior to v2.2.0, after upgrading Rancher, you must [edit the cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/editing-clusters/) and _save_ it, in order to enable the updated snapshot features. Even if you were already creating snapshots prior to v2.2.0, you must do this step as the older snapshots will not be available to use to [back up and restore etcd through the UI]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/restoring-etcd/).
|
>**Note:** If you have any Rancher launched Kubernetes clusters that were created prior to v2.2.0, after upgrading Rancher, you must [edit the cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/editing-clusters/) and _save_ it, in order to enable the updated snapshot features. Even if you were already creating snapshots prior to v2.2.0, you must do this step as the older snapshots will not be available to use to [back up and restore etcd through the UI]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/restoring-etcd/).
|
||||||
|
|
||||||
@@ -55,7 +55,7 @@ By default, the `local` backup target is selected. The benefits of this option i
|
|||||||
|
|
||||||
_Available as of v2.3.0_
|
_Available as of v2.3.0_
|
||||||
|
|
||||||
As of v2.2.6, snapshot files are timestamped to simplify processing the files using external tools and scripts, but in some S3 compatible backends, these timestamps were unusable. As of Rancher v2.3.0, the option `safe_timestamp` is added to support compatiable file names. When this flag is set to `true`, all special characters in the snapshot filename timestamp are replaced.
|
As of v2.2.6, snapshot files are timestamped to simplify processing the files using external tools and scripts, but in some S3 compatible backends, these timestamps were unusable. As of Rancher v2.3.0, the option `safe_timestamp` is added to support compatible file names. When this flag is set to `true`, all special characters in the snapshot filename timestamp are replaced.
|
||||||
|
|
||||||
>>**Note:** This option is not available directly in the UI, and is only available through the `Edit as Yaml` interface.
|
>>**Note:** This option is not available directly in the UI, and is only available through the `Edit as Yaml` interface.
|
||||||
|
|
||||||
|
|||||||
@@ -1,6 +1,6 @@
|
|||||||
---
|
---
|
||||||
title: "Access a Cluster with Kubectl Shell or Kubectl CLI"
|
title: "Access a Cluster with Kubectl Shell or Kubectl CLI"
|
||||||
description: "Lean how you can access and manage your Kubernetes clusters using kubectl in two ways: with kubectl Shell or with kubectl CLI and kuberconfig file"
|
description: "Lean how you can access and manage your Kubernetes clusters using kubectl in two ways: with kubectl Shell or with kubectl CLI and kubeconfig file"
|
||||||
weight: 2015
|
weight: 2015
|
||||||
aliases:
|
aliases:
|
||||||
- /rancher/v2.x/en/tasks/clusters/using-kubectl-to-access-a-cluster/
|
- /rancher/v2.x/en/tasks/clusters/using-kubectl-to-access-a-cluster/
|
||||||
|
|||||||
@@ -20,7 +20,7 @@ In terms of hierarchy:
|
|||||||
|
|
||||||
You can use projects to support multi-tenancy, so that a team can access a project within a cluster without having access to other projects in the same cluster.
|
You can use projects to support multi-tenancy, so that a team can access a project within a cluster without having access to other projects in the same cluster.
|
||||||
|
|
||||||
In the base version of Kubernetes, features like role-based access rights or cluster resources are assigned to individual namespaces. A project allows you to save time by giving an individual or a team acess to multiple namespaces simultaneously.
|
In the base version of Kubernetes, features like role-based access rights or cluster resources are assigned to individual namespaces. A project allows you to save time by giving an individual or a team access to multiple namespaces simultaneously.
|
||||||
|
|
||||||
You can use projects to perform actions like:
|
You can use projects to perform actions like:
|
||||||
|
|
||||||
|
|||||||
@@ -30,7 +30,7 @@ Rancher's Istio integration comes with comprehensive visualization aids:
|
|||||||
- **Trace the root cause of errors with Jaeger.** [Jaeger](https://www.jaegertracing.io/) is an open-source tool that provides a UI for a distributed tracing system, which is useful for root cause analysis and for determining what causes poor performance. Distributed tracing allows you to view an entire chain of calls, which might originate with a user request and traverse dozens of microservices.
|
- **Trace the root cause of errors with Jaeger.** [Jaeger](https://www.jaegertracing.io/) is an open-source tool that provides a UI for a distributed tracing system, which is useful for root cause analysis and for determining what causes poor performance. Distributed tracing allows you to view an entire chain of calls, which might originate with a user request and traverse dozens of microservices.
|
||||||
- **Get the full picture of your microservice architecture with Kiali.** [Kiali](https://www.kiali.io/) provides a diagram that shows the services within a service mesh and how they are connected, including the traffic rates and latencies between them. You can check the health of the service mesh, or drill down to see the incoming and outgoing requests to a single component.
|
- **Get the full picture of your microservice architecture with Kiali.** [Kiali](https://www.kiali.io/) provides a diagram that shows the services within a service mesh and how they are connected, including the traffic rates and latencies between them. You can check the health of the service mesh, or drill down to see the incoming and outgoing requests to a single component.
|
||||||
- **Gain insights from time series analytics with Grafana dashboards.** [Grafana](https://grafana.com/) is an analytics platform that allows you to query, visualize, alert on and understand the data gathered by Prometheus.
|
- **Gain insights from time series analytics with Grafana dashboards.** [Grafana](https://grafana.com/) is an analytics platform that allows you to query, visualize, alert on and understand the data gathered by Prometheus.
|
||||||
- **Write custom queries for time series data with the Promethus UI.** [Prometheus](https://prometheus.io/) is a systems monitoring and alerting toolkit. Prometheus scrapes data from your cluster, which is then used by Grafana. A Prometheus UI is also integrated into Rancher, and lets you write custom queries for time series data and see the results in the UI.
|
- **Write custom queries for time series data with the Prometheus UI.** [Prometheus](https://prometheus.io/) is a systems monitoring and alerting toolkit. Prometheus scrapes data from your cluster, which is then used by Grafana. A Prometheus UI is also integrated into Rancher, and lets you write custom queries for time series data and see the results in the UI.
|
||||||
|
|
||||||
# Prerequisites
|
# Prerequisites
|
||||||
|
|
||||||
@@ -42,7 +42,7 @@ Refer to the [setup guide]({{<baseurl>}}/rancher/v2.x/en/cluster-admin/tools/ist
|
|||||||
|
|
||||||
# Disabling Istio
|
# Disabling Istio
|
||||||
|
|
||||||
To remove Istio components from a cluster, namepace, or workload, refer to the section on [disabling Istio.]({{<baseurl>}}/rancher/v2.x/en/cluster-admin/tools/istio/disabling-istio)
|
To remove Istio components from a cluster, namespace, or workload, refer to the section on [disabling Istio.]({{<baseurl>}}/rancher/v2.x/en/cluster-admin/tools/istio/disabling-istio)
|
||||||
|
|
||||||
# Accessing Visualizations
|
# Accessing Visualizations
|
||||||
|
|
||||||
|
|||||||
@@ -7,7 +7,7 @@ This section describes the permissions required to access Istio features and how
|
|||||||
|
|
||||||
# Cluster-level Access
|
# Cluster-level Access
|
||||||
|
|
||||||
By default, only cluster adminstrators can:
|
By default, only cluster administrators can:
|
||||||
|
|
||||||
- Enable Istio for the cluster
|
- Enable Istio for the cluster
|
||||||
- Configure resource allocations for Istio
|
- Configure resource allocations for Istio
|
||||||
|
|||||||
@@ -14,7 +14,7 @@ Logging is helpful because it allows you to:
|
|||||||
- Look for trends in your environment
|
- Look for trends in your environment
|
||||||
- Save your logs to a safe location outside of your cluster
|
- Save your logs to a safe location outside of your cluster
|
||||||
- Stay informed of events like a container crashing, a pod eviction, or a node dying
|
- Stay informed of events like a container crashing, a pod eviction, or a node dying
|
||||||
- More easily debugg and troubleshoot problems
|
- More easily debug and troubleshoot problems
|
||||||
|
|
||||||
Rancher supports integration with the following services:
|
Rancher supports integration with the following services:
|
||||||
|
|
||||||
|
|||||||
@@ -1,6 +1,6 @@
|
|||||||
---
|
---
|
||||||
title: Integrating Rancher and Prometheus for Cluster Monitoring
|
title: Integrating Rancher and Prometheus for Cluster Monitoring
|
||||||
description: Prometheus lets you view metrics from your different Rancher and Kubernetes objects. Lern about the scope of monitoring and how to enable cluster monitoring
|
description: Prometheus lets you view metrics from your different Rancher and Kubernetes objects. Learn about the scope of monitoring and how to enable cluster monitoring
|
||||||
weight: 4
|
weight: 4
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|||||||
@@ -238,8 +238,8 @@ weight: 4
|
|||||||
|
|
||||||
| Catalog | Expression |
|
| Catalog | Expression |
|
||||||
| --- | --- |
|
| --- | --- |
|
||||||
| Detail | <table><tr><td>reading</td><td>`sum(nginx_ingress_controller_nginx_process_connections{state="reading"}) by (instance)`</td></tr><tr><td>waiting</td><td>`sum(nginx_ingress_controller_nginx_process_connections{state="waiting"}) by (instance)`</td></tr><tr><td>writing</td><td>`sum(nginx_ingress_controller_nginx_process_connections{state="writing"}) by (instance)`</td></tr><tr><td>accpeted</td><td>`sum(ceil(increase(nginx_ingress_controller_nginx_process_connections_total{state="accepted"}[5m]))) by (instance)`</td></tr><tr><td>active</td><td>`sum(ceil(increase(nginx_ingress_controller_nginx_process_connections_total{state="active"}[5m]))) by (instance)`</td></tr><tr><td>handled</td><td>`sum(ceil(increase(nginx_ingress_controller_nginx_process_connections_total{state="handled"}[5m]))) by (instance)`</td></tr></table> |
|
| Detail | <table><tr><td>reading</td><td>`sum(nginx_ingress_controller_nginx_process_connections{state="reading"}) by (instance)`</td></tr><tr><td>waiting</td><td>`sum(nginx_ingress_controller_nginx_process_connections{state="waiting"}) by (instance)`</td></tr><tr><td>writing</td><td>`sum(nginx_ingress_controller_nginx_process_connections{state="writing"}) by (instance)`</td></tr><tr><td>accepted</td><td>`sum(ceil(increase(nginx_ingress_controller_nginx_process_connections_total{state="accepted"}[5m]))) by (instance)`</td></tr><tr><td>active</td><td>`sum(ceil(increase(nginx_ingress_controller_nginx_process_connections_total{state="active"}[5m]))) by (instance)`</td></tr><tr><td>handled</td><td>`sum(ceil(increase(nginx_ingress_controller_nginx_process_connections_total{state="handled"}[5m]))) by (instance)`</td></tr></table> |
|
||||||
| Summary | <table><tr><td>reading</td><td>`sum(nginx_ingress_controller_nginx_process_connections{state="reading"})`</td></tr><tr><td>waiting</td><td>`sum(nginx_ingress_controller_nginx_process_connections{state="waiting"})`</td></tr><tr><td>writing</td><td>`sum(nginx_ingress_controller_nginx_process_connections{state="writing"})`</td></tr><tr><td>accpeted</td><td>`sum(ceil(increase(nginx_ingress_controller_nginx_process_connections_total{state="accepted"}[5m])))`</td></tr><tr><td>active</td><td>`sum(ceil(increase(nginx_ingress_controller_nginx_process_connections_total{state="active"}[5m])))`</td></tr><tr><td>handled</td><td>`sum(ceil(increase(nginx_ingress_controller_nginx_process_connections_total{state="handled"}[5m])))`</td></tr></table> |
|
| Summary | <table><tr><td>reading</td><td>`sum(nginx_ingress_controller_nginx_process_connections{state="reading"})`</td></tr><tr><td>waiting</td><td>`sum(nginx_ingress_controller_nginx_process_connections{state="waiting"})`</td></tr><tr><td>writing</td><td>`sum(nginx_ingress_controller_nginx_process_connections{state="writing"})`</td></tr><tr><td>accepted</td><td>`sum(ceil(increase(nginx_ingress_controller_nginx_process_connections_total{state="accepted"}[5m])))`</td></tr><tr><td>active</td><td>`sum(ceil(increase(nginx_ingress_controller_nginx_process_connections_total{state="active"}[5m])))`</td></tr><tr><td>handled</td><td>`sum(ceil(increase(nginx_ingress_controller_nginx_process_connections_total{state="handled"}[5m])))`</td></tr></table> |
|
||||||
|
|
||||||
- **Ingress Controller Request Process Time**
|
- **Ingress Controller Request Process Time**
|
||||||
|
|
||||||
|
|||||||
@@ -1,6 +1,6 @@
|
|||||||
---
|
---
|
||||||
title: "Kubernetes Persistent Storage: Volumes and Storage Classes"
|
title: "Kubernetes Persistent Storage: Volumes and Storage Classes"
|
||||||
description: "Learn about the two ways with which you can creat persistent storage in Kubernetes: persistent volumes and storage classes"
|
description: "Learn about the two ways with which you can create persistent storage in Kubernetes: persistent volumes and storage classes"
|
||||||
weight: 2031
|
weight: 2031
|
||||||
aliases:
|
aliases:
|
||||||
- /rancher/v2.x/en/concepts/volumes-and-storage/
|
- /rancher/v2.x/en/concepts/volumes-and-storage/
|
||||||
|
|||||||
+1
-1
@@ -42,7 +42,7 @@ In order to provision vSphere volumes in a cluster created with the [Rancher Kub
|
|||||||
7. Assign a path in the **Mount Point** field. This is the full path where the volume will be mounted in the container file system, e.g. `/persistent`.
|
7. Assign a path in the **Mount Point** field. This is the full path where the volume will be mounted in the container file system, e.g. `/persistent`.
|
||||||
8. Click **Launch** to create the workload.
|
8. Click **Launch** to create the workload.
|
||||||
|
|
||||||
### Verifing Persistence of the Volume
|
### Verifying Persistence of the Volume
|
||||||
|
|
||||||
1. From the context menu of the workload you just created, click **Execute Shell**.
|
1. From the context menu of the workload you just created, click **Execute Shell**.
|
||||||
2. Note the directory at root where the volume has been mounted to (in this case `/persistent`).
|
2. Note the directory at root where the volume has been mounted to (in this case `/persistent`).
|
||||||
|
|||||||
@@ -25,7 +25,7 @@ All supported operating systems are 64-bit x86.
|
|||||||
|
|
||||||
If you plan to use ARM64, see [Running on ARM64 (Experimental).]({{<baseurl>}}/rancher/v2.x/en/installation/options/arm64-platform/)
|
If you plan to use ARM64, see [Running on ARM64 (Experimental).]({{<baseurl>}}/rancher/v2.x/en/installation/options/arm64-platform/)
|
||||||
|
|
||||||
For information on how to install Docker, refer to the offical [Docker documentation.](https://docs.docker.com/)
|
For information on how to install Docker, refer to the official [Docker documentation.](https://docs.docker.com/)
|
||||||
|
|
||||||
> **Note:** Some distributions of Linux derived from RHEL, including Oracle Linux, may have default firewall rules that block communication with Helm. This [how-to guide]({{<baseurl>}}/rancher/v2.x/en/installation/options/firewall) shows how to check the default firewall rules and how to open the ports with `firewalld` if necessary.
|
> **Note:** Some distributions of Linux derived from RHEL, including Oracle Linux, may have default firewall rules that block communication with Helm. This [how-to guide]({{<baseurl>}}/rancher/v2.x/en/installation/options/firewall) shows how to check the default firewall rules and how to open the ports with `firewalld` if necessary.
|
||||||
|
|
||||||
@@ -41,7 +41,7 @@ Windows nodes can be used for worker nodes only. See [Configuring Custom Cluster
|
|||||||
|
|
||||||
The hardware requirements for nodes with the `worker` role mostly depend on your workloads. The minimum to run the Kubernetes node components is 1 CPU (core) and 1GB of memory.
|
The hardware requirements for nodes with the `worker` role mostly depend on your workloads. The minimum to run the Kubernetes node components is 1 CPU (core) and 1GB of memory.
|
||||||
|
|
||||||
Regarding CPU and memory, it is recommended that the different planes of Kubernetes clusters (etcd, controplane, and workers) should be hosted on different nodes so that they can scale separately from each other.
|
Regarding CPU and memory, it is recommended that the different planes of Kubernetes clusters (etcd, controlplane, and workers) should be hosted on different nodes so that they can scale separately from each other.
|
||||||
|
|
||||||
For hardware recommendations for large Kubernetes clusters, refer to the official Kubernetes documentation on [building large clusters.](https://kubernetes.io/docs/setup/best-practices/cluster-large/)
|
For hardware recommendations for large Kubernetes clusters, refer to the official Kubernetes documentation on [building large clusters.](https://kubernetes.io/docs/setup/best-practices/cluster-large/)
|
||||||
|
|
||||||
@@ -106,7 +106,7 @@ The following table depicts the port requirements for [Rancher Launched Kubernet
|
|||||||
|
|
||||||
### Port Requirements for Clusters Hosted by an Infrastructure Provider
|
### Port Requirements for Clusters Hosted by an Infrastructure Provider
|
||||||
|
|
||||||
If you are launching a Kubernetes cluster on nodes that are in an infastructure provider such as Amazon EC2, Google Container Engine, DigitalOcean, Azure, or vSphere, these port requirements apply.
|
If you are launching a Kubernetes cluster on nodes that are in an infrastructure provider such as Amazon EC2, Google Container Engine, DigitalOcean, Azure, or vSphere, these port requirements apply.
|
||||||
|
|
||||||
These required ports are automatically opened by Rancher during creation of clusters using cloud providers.
|
These required ports are automatically opened by Rancher during creation of clusters using cloud providers.
|
||||||
|
|
||||||
|
|||||||
@@ -36,7 +36,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).
|
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](#prerequisites) 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 [Prerequisites](#prerequisites) how to create the Access Key and Secret Key and the needed permissions.
|
||||||
|
|
||||||
{{< step_create-cloud-credential >}}
|
{{< step_create-cloud-credential >}}
|
||||||
|
|
||||||
|
|||||||
@@ -109,7 +109,7 @@ If the nodes you are adding to the cluster have Docker configured with a non-def
|
|||||||
|
|
||||||
#### Recurring etcd Snapshots
|
#### Recurring etcd Snapshots
|
||||||
|
|
||||||
Option to enable or disable [recurring etcd snaphots]({{< baseurl >}}/rke/latest/en/etcd-snapshots/#etcd-recurring-snapshots).
|
Option to enable or disable [recurring etcd snapshots]({{< baseurl >}}/rke/latest/en/etcd-snapshots/#etcd-recurring-snapshots).
|
||||||
|
|
||||||
## Config File
|
## Config File
|
||||||
|
|
||||||
|
|||||||
@@ -5,7 +5,7 @@ aliases:
|
|||||||
- /rancher/v2.x/en/faq/contributing/
|
- /rancher/v2.x/en/faq/contributing/
|
||||||
---
|
---
|
||||||
|
|
||||||
This section explains the respositories used for Rancher, how to build the repositories, and what information to include when you file an issue.
|
This section explains the repositories used for Rancher, how to build the repositories, and what information to include when you file an issue.
|
||||||
|
|
||||||
For more detailed information on how to contribute to the development of Rancher projects, refer to the [Rancher Developer Wiki](https://github.com/rancher/rancher/wiki). The wiki has resources on many topics, including the following:
|
For more detailed information on how to contribute to the development of Rancher projects, refer to the [Rancher Developer Wiki](https://github.com/rancher/rancher/wiki). The wiki has resources on many topics, including the following:
|
||||||
|
|
||||||
|
|||||||
@@ -127,7 +127,7 @@ The following table summarizes the different features available for each CNI net
|
|||||||
|
|
||||||
- External Datastore: CNI network providers with this feature need an external datastore for its data.
|
- External Datastore: CNI network providers with this feature need an external datastore for its data.
|
||||||
|
|
||||||
- Encyption: This feature allows cyphered and secure network control and data planes.
|
- Encryption: This feature allows cyphered and secure network control and data planes.
|
||||||
|
|
||||||
- Ingress/Egress Policies: This feature allows you to manage routing control for both Kubernetes and non-Kubernetes communications.
|
- Ingress/Egress Policies: This feature allows you to manage routing control for both Kubernetes and non-Kubernetes communications.
|
||||||
|
|
||||||
|
|||||||
@@ -22,7 +22,7 @@ After installing NGINX, you need to update the NGINX configuration file, `nginx.
|
|||||||
|
|
||||||
1. Copy and paste the code sample below into your favorite text editor. Save it as `nginx.conf`.
|
1. Copy and paste the code sample below into your favorite text editor. Save it as `nginx.conf`.
|
||||||
|
|
||||||
2. From `nginx.conf`, replace both occurences (port 80 and port 443) of `<IP_NODE_1>`, `<IP_NODE_2>`, and `<IP_NODE_3>` with the IPs of your [nodes]({{< baseurl >}}/rancher/v2.x/en/installation/ha/create-nodes-lb/).
|
2. From `nginx.conf`, replace both occurrences (port 80 and port 443) of `<IP_NODE_1>`, `<IP_NODE_2>`, and `<IP_NODE_3>` with the IPs of your [nodes]({{< baseurl >}}/rancher/v2.x/en/installation/ha/create-nodes-lb/).
|
||||||
|
|
||||||
> **Note:** See [NGINX Documentation: TCP and UDP Load Balancing](https://docs.nginx.com/nginx/admin-guide/load-balancer/tcp-udp-load-balancer/) for all configuration options.
|
> **Note:** See [NGINX Documentation: TCP and UDP Load Balancing](https://docs.nginx.com/nginx/admin-guide/load-balancer/tcp-udp-load-balancer/) for all configuration options.
|
||||||
|
|
||||||
|
|||||||
@@ -3,7 +3,7 @@ title: About High-availability Installations
|
|||||||
weight: 2
|
weight: 2
|
||||||
---
|
---
|
||||||
|
|
||||||
We recommend using [Helm,]({{<baseurl>}}/rancher/v2.x/en/overview/architecture/concepts/#about-helm) a Kubernetes package manager, to install Rancher on a dedicated Kubernetes cluster. This is called a high-availability (HA) installation because increased avaialability is achieved by running Rancher on multiple nodes.
|
We recommend using [Helm,]({{<baseurl>}}/rancher/v2.x/en/overview/architecture/concepts/#about-helm) a Kubernetes package manager, to install Rancher on a dedicated Kubernetes cluster. This is called a high-availability (HA) installation because increased availability is achieved by running Rancher on multiple nodes.
|
||||||
|
|
||||||
In a typical HA Rancher installation, Kubernetes is first installed on three nodes that are hosted in an infrastructure provider such as Amazon's EC2 or Google Compute Engine.
|
In a typical HA Rancher installation, Kubernetes is first installed on three nodes that are hosted in an infrastructure provider such as Amazon's EC2 or Google Compute Engine.
|
||||||
|
|
||||||
|
|||||||
@@ -192,7 +192,7 @@ This NGINX configuration is tested on NGINX 1.14.
|
|||||||
> **Note:** This NGINX configuration is only an example and may not suit your environment. For complete documentation, see [NGINX Load Balancing - HTTP Load Balancing](https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/).
|
> **Note:** This NGINX configuration is only an example and may not suit your environment. For complete documentation, see [NGINX Load Balancing - HTTP Load Balancing](https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/).
|
||||||
|
|
||||||
- Replace `IP_NODE1`, `IP_NODE2` and `IP_NODE3` with the IP addresses of the nodes in your cluster.
|
- Replace `IP_NODE1`, `IP_NODE2` and `IP_NODE3` with the IP addresses of the nodes in your cluster.
|
||||||
- Replace both occurences of `FQDN` to the DNS name for Rancher.
|
- Replace both occurrences of `FQDN` to the DNS name for Rancher.
|
||||||
- Replace `/certs/fullchain.pem` and `/certs/privkey.pem` to the location of the server certificate and the server certificate key respectively.
|
- Replace `/certs/fullchain.pem` and `/certs/privkey.pem` to the location of the server certificate and the server certificate key respectively.
|
||||||
|
|
||||||
```
|
```
|
||||||
|
|||||||
@@ -25,7 +25,7 @@ You can follow the recommendations from [the etcd docs](https://etcd.io/docs/v3.
|
|||||||
|
|
||||||
Additionally, to reduce IO contention on the disks for etcd, you can use a dedicated device for the data and wal directory. Based on etcd best practices, mirroring RAID configurations are unnecessary because etcd replicates data between the nodes in the cluster. You can use stripping RAID configurations to increase available IOPS.
|
Additionally, to reduce IO contention on the disks for etcd, you can use a dedicated device for the data and wal directory. Based on etcd best practices, mirroring RAID configurations are unnecessary because etcd replicates data between the nodes in the cluster. You can use stripping RAID configurations to increase available IOPS.
|
||||||
|
|
||||||
To implement this solution in an RKE cluster, the `/var/lib/etcd/data` and `/var/lib/etc/wal` directories will need to have disks mounted and formmated on the underlying host. In the `extra_args` directive of the `etcd` service, you must include the `wal_dir` directory. Without specifying the `wal_dir`, etcd process will try to manipulate the underlying `wal` mount with insufficient permissions.
|
To implement this solution in an RKE cluster, the `/var/lib/etcd/data` and `/var/lib/etc/wal` directories will need to have disks mounted and formatted on the underlying host. In the `extra_args` directive of the `etcd` service, you must include the `wal_dir` directory. Without specifying the `wal_dir`, etcd process will try to manipulate the underlying `wal` mount with insufficient permissions.
|
||||||
|
|
||||||
```yaml
|
```yaml
|
||||||
# RKE cluster.yml
|
# RKE cluster.yml
|
||||||
|
|||||||
@@ -21,7 +21,7 @@ After installing NGINX, you need to update the NGINX configuration file, `nginx.
|
|||||||
|
|
||||||
1. Copy and paste the code sample below into your favorite text editor. Save it as `nginx.conf`.
|
1. Copy and paste the code sample below into your favorite text editor. Save it as `nginx.conf`.
|
||||||
|
|
||||||
2. From `nginx.conf`, replace both occurences (port 80 and port 443) of `<IP_NODE_1>`, `<IP_NODE_2>`, and `<IP_NODE_3>` with the IPs of your [nodes]({{< baseurl >}}/rancher/v2.x/en/installation/options/helm2/create-nodes-lb/).
|
2. From `nginx.conf`, replace both occurrences (port 80 and port 443) of `<IP_NODE_1>`, `<IP_NODE_2>`, and `<IP_NODE_3>` with the IPs of your [nodes]({{< baseurl >}}/rancher/v2.x/en/installation/options/helm2/create-nodes-lb/).
|
||||||
|
|
||||||
>**Note:** See [NGINX Documentation: TCP and UDP Load Balancing](https://docs.nginx.com/nginx/admin-guide/load-balancer/tcp-udp-load-balancer/) for all configuration options.
|
>**Note:** See [NGINX Documentation: TCP and UDP Load Balancing](https://docs.nginx.com/nginx/admin-guide/load-balancer/tcp-udp-load-balancer/) for all configuration options.
|
||||||
|
|
||||||
|
|||||||
+1
-1
@@ -192,7 +192,7 @@ This NGINX configuration is tested on NGINX 1.14.
|
|||||||
>**Note:** This NGINX configuration is only an example and may not suit your environment. For complete documentation, see [NGINX Load Balancing - HTTP Load Balancing](https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/).
|
>**Note:** This NGINX configuration is only an example and may not suit your environment. For complete documentation, see [NGINX Load Balancing - HTTP Load Balancing](https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/).
|
||||||
|
|
||||||
* Replace `IP_NODE1`, `IP_NODE2` and `IP_NODE3` with the IP addresses of the nodes in your cluster.
|
* Replace `IP_NODE1`, `IP_NODE2` and `IP_NODE3` with the IP addresses of the nodes in your cluster.
|
||||||
* Replace both occurences of `FQDN` to the DNS name for Rancher.
|
* Replace both occurrences of `FQDN` to the DNS name for Rancher.
|
||||||
* Replace `/certs/fullchain.pem` and `/certs/privkey.pem` to the location of the server certificate and the server certificate key respectively.
|
* Replace `/certs/fullchain.pem` and `/certs/privkey.pem` to the location of the server certificate and the server certificate key respectively.
|
||||||
|
|
||||||
```
|
```
|
||||||
|
|||||||
@@ -392,7 +392,7 @@ During installation, RKE automatically generates a config file named `kube_confi
|
|||||||
|
|
||||||
You have a couple of options:
|
You have a couple of options:
|
||||||
|
|
||||||
- Create a backup of your Rancher Server in case of a disaster scenario: [High Availablility Back Up and Restoration]({{< baseurl >}}/rancher/v2.x/en/installation/backups-and-restoration/ha-backup-and-restoration).
|
- Create a backup of your Rancher Server in case of a disaster scenario: [High Availability Back Up and Restoration]({{< baseurl >}}/rancher/v2.x/en/installation/backups-and-restoration/ha-backup-and-restoration).
|
||||||
- Create a Kubernetes cluster: [Provisioning Kubernetes Clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/).
|
- Create a Kubernetes cluster: [Provisioning Kubernetes Clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/).
|
||||||
|
|
||||||
<br/>
|
<br/>
|
||||||
|
|||||||
@@ -278,7 +278,7 @@ During installation, RKE automatically generates a config file named `kube_confi
|
|||||||
|
|
||||||
## What's Next?
|
## What's Next?
|
||||||
|
|
||||||
- **Recommended:** Review [Creating Backups—High Availablility Back Up and Restoration]({{< baseurl >}}/rancher/v2.x/en/backups/backups/ha-backups/) to learn how to backup your Rancher Server in case of a disaster scenario.
|
- **Recommended:** Review [Creating Backups—High Availability Back Up and Restoration]({{< baseurl >}}/rancher/v2.x/en/backups/backups/ha-backups/) to learn how to backup your Rancher Server in case of a disaster scenario.
|
||||||
- Create a Kubernetes cluster: [Creating a Cluster]({{< baseurl >}}/rancher/v2.x/en/tasks/clusters/creating-a-cluster/).
|
- Create a Kubernetes cluster: [Creating a Cluster]({{< baseurl >}}/rancher/v2.x/en/tasks/clusters/creating-a-cluster/).
|
||||||
|
|
||||||
<br/>
|
<br/>
|
||||||
|
|||||||
@@ -393,7 +393,7 @@ During installation, RKE automatically generates a config file named `kube_confi
|
|||||||
|
|
||||||
You have a couple of options:
|
You have a couple of options:
|
||||||
|
|
||||||
- Create a backup of your Rancher Server in case of a disaster scenario: [High Availablility Back Up and Restoration]({{< baseurl >}}/rancher/v2.x/en/installation/backups-and-restoration/ha-backup-and-restoration).
|
- Create a backup of your Rancher Server in case of a disaster scenario: [High Availability Back Up and Restoration]({{< baseurl >}}/rancher/v2.x/en/installation/backups-and-restoration/ha-backup-and-restoration).
|
||||||
- Create a Kubernetes cluster: [Provisioning Kubernetes Clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/).
|
- Create a Kubernetes cluster: [Provisioning Kubernetes Clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/).
|
||||||
|
|
||||||
<br/>
|
<br/>
|
||||||
|
|||||||
@@ -279,7 +279,7 @@ During installation, RKE automatically generates a config file named `kube_confi
|
|||||||
|
|
||||||
## What's Next?
|
## What's Next?
|
||||||
|
|
||||||
- **Recommended:** Review [Creating Backups—High Availablility Back Up and Restoration]({{< baseurl >}}/rancher/v2.x/en/backups/backups/ha-backups/) to learn how to backup your Rancher Server in case of a disaster scenario.
|
- **Recommended:** Review [Creating Backups—High Availability Back Up and Restoration]({{< baseurl >}}/rancher/v2.x/en/backups/backups/ha-backups/) to learn how to backup your Rancher Server in case of a disaster scenario.
|
||||||
- Create a Kubernetes cluster: [Creating a Cluster]({{< baseurl >}}/rancher/v2.x/en/tasks/clusters/creating-a-cluster/).
|
- Create a Kubernetes cluster: [Creating a Cluster]({{< baseurl >}}/rancher/v2.x/en/tasks/clusters/creating-a-cluster/).
|
||||||
|
|
||||||
<br/>
|
<br/>
|
||||||
|
|||||||
@@ -11,7 +11,7 @@ Rancher uses cert-manager to automatically generate and renew TLS certificates f
|
|||||||
To address these changes, this guide will do two things:
|
To address these changes, this guide will do two things:
|
||||||
|
|
||||||
1. Document the procedure for upgrading cert-manager
|
1. Document the procedure for upgrading cert-manager
|
||||||
1. Explain the cert-manager API changes and link to cert-manager's offficial documentation for migrating your data
|
1. Explain the cert-manager API changes and link to cert-manager's official documentation for migrating your data
|
||||||
|
|
||||||
|
|
||||||
## Performing the upgrade
|
## Performing the upgrade
|
||||||
|
|||||||
+1
-1
@@ -106,7 +106,7 @@ This NGINX configuration is tested on NGINX 1.14.
|
|||||||
> **Note:** This Nginx configuration is only an example and may not suit your environment. For complete documentation, see [NGINX Load Balancing - HTTP Load Balancing](https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/).
|
> **Note:** This Nginx configuration is only an example and may not suit your environment. For complete documentation, see [NGINX Load Balancing - HTTP Load Balancing](https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/).
|
||||||
|
|
||||||
- Replace `rancher-server` with the IP address or hostname of the node running the Rancher container.
|
- Replace `rancher-server` with the IP address or hostname of the node running the Rancher container.
|
||||||
- Replace both occurences of `FQDN` to the DNS name for Rancher.
|
- Replace both occurrences of `FQDN` to the DNS name for Rancher.
|
||||||
- Replace `/certs/fullchain.pem` and `/certs/privkey.pem` to the location of the server certificate and the server certificate key respectively.
|
- Replace `/certs/fullchain.pem` and `/certs/privkey.pem` to the location of the server certificate and the server certificate key respectively.
|
||||||
|
|
||||||
```
|
```
|
||||||
|
|||||||
@@ -40,7 +40,7 @@ If you plan to run Rancher on ARM64, see [Running on ARM64 (Experimental).]({{<b
|
|||||||
|
|
||||||
### Installing Docker
|
### Installing Docker
|
||||||
|
|
||||||
Docker can be installed by following the steps in the offical [Docker documentation.](https://docs.docker.com/) Rancher also provides [scripts]({{<baseurl>}}/rancher/v2.x/en/installation/requirements/installing-docker) to install Docker with one command.
|
Docker can be installed by following the steps in the official [Docker documentation.](https://docs.docker.com/) Rancher also provides [scripts]({{<baseurl>}}/rancher/v2.x/en/installation/requirements/installing-docker) to install Docker with one command.
|
||||||
|
|
||||||
# Hardware Requirements
|
# Hardware Requirements
|
||||||
|
|
||||||
|
|||||||
@@ -32,7 +32,7 @@ Add SSL certificates to either projects, namespaces, or both. A project scoped c
|
|||||||
|
|
||||||
1. From **Certificate**, either copy and paste your certificate into the text box (include the header and footer), or click **Read from a file** to browse to the certificate on your file system. If possible, we recommend using **Read from a file** to reduce likelihood of error.
|
1. From **Certificate**, either copy and paste your certificate into the text box (include the header and footer), or click **Read from a file** to browse to the certificate on your file system. If possible, we recommend using **Read from a file** to reduce likelihood of error.
|
||||||
|
|
||||||
Certifcate files end with an extension of `.crt`.
|
Certificate files end with an extension of `.crt`.
|
||||||
|
|
||||||
**Result:** Your certificate is added to the project or namespace. You can now add it to deployments.
|
**Result:** Your certificate is added to the project or namespace. You can now add it to deployments.
|
||||||
|
|
||||||
|
|||||||
+1
-1
@@ -50,6 +50,6 @@ If you want to create HPAs that scale based on other metrics than CPU and memory
|
|||||||
|
|
||||||
1. Click **Ellipsis (...) > Delete**.
|
1. Click **Ellipsis (...) > Delete**.
|
||||||
|
|
||||||
1. Click **Delete** to confim.
|
1. Click **Delete** to confirm.
|
||||||
|
|
||||||
> **Result:** The HPA is deleted from the current cluster.
|
> **Result:** The HPA is deleted from the current cluster.
|
||||||
+1
-1
@@ -229,7 +229,7 @@ Use your load testing tool to scale up to two pods based on CPU Usage.
|
|||||||
```
|
```
|
||||||
{{% /accordion %}}
|
{{% /accordion %}}
|
||||||
{{% accordion id="observe-upscale-3-pods-cpu-cooldown" label="Upscale to 3 pods: CPU Usage Up to Target" %}}
|
{{% accordion id="observe-upscale-3-pods-cpu-cooldown" label="Upscale to 3 pods: CPU Usage Up to Target" %}}
|
||||||
Use your load testing tool to upspace to 3 pods based on CPU usage with `horizontal-pod-autoscaler-upscale-delay` set to 3 minutes.
|
Use your load testing tool to upscale to 3 pods based on CPU usage with `horizontal-pod-autoscaler-upscale-delay` set to 3 minutes.
|
||||||
|
|
||||||
1. Enter the following command.
|
1. Enter the following command.
|
||||||
```
|
```
|
||||||
|
|||||||
@@ -73,7 +73,7 @@ Ingress can be added for workloads to provide load balancing, SSL termination an
|
|||||||
|
|
||||||
1. Enter the **Host** using encrypted communication.
|
1. Enter the **Host** using encrypted communication.
|
||||||
|
|
||||||
1. To add additional hosts that use the certitificate, click **Add Hosts**.
|
1. To add additional hosts that use the certificate, click **Add Hosts**.
|
||||||
|
|
||||||
1. **Optional:** Add [Labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) and/or [Annotations](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/) to provide metadata for your ingress.
|
1. **Optional:** Add [Labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) and/or [Annotations](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/) to provide metadata for your ingress.
|
||||||
|
|
||||||
|
|||||||
@@ -11,7 +11,7 @@ aliases:
|
|||||||
>- 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.
|
>- 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]({{< baseurl >}}/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).
|
||||||
|
|
||||||
Before setting up any pipelines, review the [pipeline overview]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/pipelines/) and ensure that the project has [configured authentication to your version control provider]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/pipelines/#version-control-providers), e.g. GitHub, GitLab, Bitucket. If you haven't configured a version control provider, you can always use [Rancher's example repositories]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/pipelines/example/) to view some common pipeline deployments.
|
Before setting up any pipelines, review the [pipeline overview]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/pipelines/) and ensure that the project has [configured authentication to your version control provider]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/pipelines/#version-control-providers), e.g. GitHub, GitLab, Bitbucket. If you haven't configured a version control provider, you can always use [Rancher's example repositories]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/pipelines/example/) to view some common pipeline deployments.
|
||||||
|
|
||||||
If you can access a project, you can enable repositories to start building pipelines. Only an [administrator]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/), [cluster owner or member]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles), or [project owner]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles) can authorize version control providers.
|
If you can access a project, you can enable repositories to start building pipelines. Only an [administrator]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/), [cluster owner or member]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles), or [project owner]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles) can authorize version control providers.
|
||||||
|
|
||||||
@@ -99,7 +99,7 @@ If you haven't added any stages, click **Configure pipeline for this branch** to
|
|||||||
{{% /tab %}}
|
{{% /tab %}}
|
||||||
{{% tab "By YAML" %}}
|
{{% tab "By YAML" %}}
|
||||||
<br>
|
<br>
|
||||||
For each stage, you can add multiple steps. Read more about each [step type](#step-types) and the [advanced options](#advanced-options) to get all thhe details on how to configure the YAML. This is only a small example of how to have multiple stages with a singular step in each stage.
|
For each stage, you can add multiple steps. Read more about each [step type](#step-types) and the [advanced options](#advanced-options) to get all the details on how to configure the YAML. This is only a small example of how to have multiple stages with a singular step in each stage.
|
||||||
|
|
||||||
```yaml
|
```yaml
|
||||||
# example
|
# example
|
||||||
@@ -145,7 +145,7 @@ _Available as of v2.2.0_
|
|||||||
|
|
||||||
1. Select the conditions for the notification. You can select to get a notification for the following statuses: `Failed`, `Success`, `Changed`. For example, if you want to receive notifications when an execution fails, select **Failed**.
|
1. Select the conditions for the notification. You can select to get a notification for the following statuses: `Failed`, `Success`, `Changed`. For example, if you want to receive notifications when an execution fails, select **Failed**.
|
||||||
|
|
||||||
1. If you don't have any existing [notifiers]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/notifiers), Rancher will provide a warning that no notifers are set up and provide a link to be able to go to the notifiers page. Follow the [instructions]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/notifiers/#adding-notifiers) to add a notifier. If you already have notifiers, you can add them to the notification by clicking the **Add Recipient** button.
|
1. If you don't have any existing [notifiers]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/notifiers), Rancher will provide a warning that no notifiers are set up and provide a link to be able to go to the notifiers page. Follow the [instructions]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/notifiers/#adding-notifiers) to add a notifier. If you already have notifiers, you can add them to the notification by clicking the **Add Recipient** button.
|
||||||
|
|
||||||
> **Note:** Notifiers are configured at a cluster level and require a different level of permissions.
|
> **Note:** Notifiers are configured at a cluster level and require a different level of permissions.
|
||||||
|
|
||||||
@@ -413,7 +413,7 @@ Under the `steps` section, add a step with `publishCatalogConfig`. You will prov
|
|||||||
* GitBranch: The git branch of the chart repository that the template will be published to.
|
* GitBranch: The git branch of the chart repository that the template will be published to.
|
||||||
* GitAuthor: The author name used in the commit message.
|
* GitAuthor: The author name used in the commit message.
|
||||||
* GitEmail: The author email used in the commit message.
|
* GitEmail: The author email used in the commit message.
|
||||||
* Credentials: You should provide Git credentials by referencing secrets in dedicated pipeline namespace. If you publish via SSH protocol, inject your deploy key to the `DEPLOY_KEY` environment variable. If you publish via HTTP(S) protolcol, inject your username and password to `USERNAME` and `PASSWORD` environment variables.
|
* Credentials: You should provide Git credentials by referencing secrets in dedicated pipeline namespace. If you publish via SSH protocol, inject your deploy key to the `DEPLOY_KEY` environment variable. If you publish via HTTP(S) protocol, inject your username and password to `USERNAME` and `PASSWORD` environment variables.
|
||||||
|
|
||||||
```yaml
|
```yaml
|
||||||
# example
|
# example
|
||||||
|
|||||||
@@ -9,7 +9,7 @@ Sometimes there is a need to rollback to the previous version of the application
|
|||||||
|
|
||||||
1. From the **Global** view, open the project running the workload you want to rollback.
|
1. From the **Global** view, open the project running the workload you want to rollback.
|
||||||
|
|
||||||
1. Find the workload that you want to rollback and select **Vertical Elipsis (... ) > Rollback**.
|
1. Find the workload that you want to rollback and select **Vertical Ellipsis (... ) > Rollback**.
|
||||||
|
|
||||||
1. Choose the revision that you want to roll back to. Click **Rollback**.
|
1. Choose the revision that you want to roll back to. Click **Rollback**.
|
||||||
|
|
||||||
|
|||||||
@@ -8,7 +8,7 @@ When a new version of an application image is released on Docker Hub, you can up
|
|||||||
|
|
||||||
1. From the **Global** view, open the project running the workload you want to upgrade.
|
1. From the **Global** view, open the project running the workload you want to upgrade.
|
||||||
|
|
||||||
1. Find the workload that you want to upgrade and select **Vertical Elipsis (... ) > Edit**.
|
1. Find the workload that you want to upgrade and select **Vertical Ellipsis (... ) > Edit**.
|
||||||
|
|
||||||
1. Update the **Docker Image** to the updated version of the application image on Docker Hub.
|
1. Update the **Docker Image** to the updated version of the application image on Docker Hub.
|
||||||
|
|
||||||
|
|||||||
@@ -1190,7 +1190,7 @@ docker inspect etcd | jq -e '.[0].Args[] | match("--peer-auto-tls(?:(?!=false).*
|
|||||||
|
|
||||||
**Notes**
|
**Notes**
|
||||||
|
|
||||||
RKE does not currently implement a seperate CA for etcd certificates.
|
RKE does not currently implement a separate CA for etcd certificates.
|
||||||
|
|
||||||
`--trusted-ca-file` is set and different from the `--client-ca-file` used by `kube-apiserver`.
|
`--trusted-ca-file` is set and different from the `--client-ca-file` used by `kube-apiserver`.
|
||||||
|
|
||||||
|
|||||||
+1
-1
@@ -7,7 +7,7 @@ This section applies to nodes with the `controlplane` role.
|
|||||||
|
|
||||||
# Check if the Controlplane Containers are Running
|
# Check if the Controlplane Containers are Running
|
||||||
|
|
||||||
There are three specific containers launched on nodes with the `controlpane` role:
|
There are three specific containers launched on nodes with the `controlplane` role:
|
||||||
|
|
||||||
* `kube-apiserver`
|
* `kube-apiserver`
|
||||||
* `kube-controller-manager`
|
* `kube-controller-manager`
|
||||||
|
|||||||
+1
-1
@@ -7,7 +7,7 @@ This section applies to every node as it includes components that run on nodes w
|
|||||||
|
|
||||||
# Check if the Containers are Running
|
# Check if the Containers are Running
|
||||||
|
|
||||||
There are three specific containers launched on nodes with the `controlpane` role:
|
There are three specific containers launched on nodes with the `controlplane` role:
|
||||||
|
|
||||||
* kubelet
|
* kubelet
|
||||||
* kube-proxy
|
* kube-proxy
|
||||||
|
|||||||
@@ -38,7 +38,7 @@ You can obtain `<PRIOR_RANCHER_VERSION>` and `<RANCHER_CONTAINER_NAME>` by loggi
|
|||||||
|
|
||||||
## Rolling Back Rancher
|
## Rolling Back Rancher
|
||||||
|
|
||||||
If you have issues upgrading Rancher, roll it back to its lastest known healthy state by pulling the last version you used and then restoring the backup you made before upgrade.
|
If you have issues upgrading Rancher, roll it back to its latest known healthy state by pulling the last version you used and then restoring the backup you made before upgrade.
|
||||||
|
|
||||||
>**Warning!** Rolling back to a previous version of Rancher destroys any changes made to Rancher following the upgrade. Unrecoverable data loss may occur.
|
>**Warning!** Rolling back to a previous version of Rancher destroys any changes made to Rancher following the upgrade. Unrecoverable data loss may occur.
|
||||||
|
|
||||||
|
|||||||
@@ -157,6 +157,6 @@ Cattle provided feature-rich load balancer support that is [well documented]({{<
|
|||||||
- Only ports 80 and 443 can be configured for HTTP/HTTPS routing via Ingress. Also Ingress Controller is deployed globally as a DaemonSet and not launched as a scalable service. Also, users cannot assign random external ports to be used for balancing. Therefore, users need to ensure that they configure unique hostname/path combinations to avoid routing conflicts using the same two ports.
|
- Only ports 80 and 443 can be configured for HTTP/HTTPS routing via Ingress. Also Ingress Controller is deployed globally as a DaemonSet and not launched as a scalable service. Also, users cannot assign random external ports to be used for balancing. Therefore, users need to ensure that they configure unique hostname/path combinations to avoid routing conflicts using the same two ports.
|
||||||
- There is no way to specify port rule priority and ordering.
|
- There is no way to specify port rule priority and ordering.
|
||||||
- Rancher v1.6 added support for draining backend connections and specifying a drain timeout. This is not supported in Rancher v2.x.
|
- Rancher v1.6 added support for draining backend connections and specifying a drain timeout. This is not supported in Rancher v2.x.
|
||||||
- There is no support for specifying a custom stickiness policy and a custom load balancer config to be appended to the default config as of now in Rancher v2.x. There is some support, however, available in native Kubernetes for customizing the NGINX configuration as noted in the [NGINX Ingress Controller Custom Conguration Documentation](https://kubernetes.github.io/ingress-nginx/examples/customization/custom-configuration/).
|
- There is no support for specifying a custom stickiness policy and a custom load balancer config to be appended to the default config as of now in Rancher v2.x. There is some support, however, available in native Kubernetes for customizing the NGINX configuration as noted in the [NGINX Ingress Controller Custom Configuration Documentation](https://kubernetes.github.io/ingress-nginx/examples/customization/custom-configuration/).
|
||||||
|
|
||||||
### Finished!
|
### Finished!
|
||||||
|
|||||||
@@ -45,7 +45,7 @@ The following diagram displays the health check microservice evaluating a contai
|
|||||||
|
|
||||||
## Rancher v2.x Health Checks
|
## Rancher v2.x Health Checks
|
||||||
|
|
||||||
In Rancher v2.x, the health check microservice is replaced with Kubernete's native health check mechanisms, called _probes_. These probes, similar to the Rancher v1.6 health check microservice, monitor the health of pods over TCP and HTTP.
|
In Rancher v2.x, the health check microservice is replaced with Kubernetes's native health check mechanisms, called _probes_. These probes, similar to the Rancher v1.6 health check microservice, monitor the health of pods over TCP and HTTP.
|
||||||
|
|
||||||
However, probes in Rancher v2.x have some important differences, which are described below. For full details about probes, see the [Kubernetes documentation](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#configure-probes).
|
However, probes in Rancher v2.x have some important differences, which are described below. For full details about probes, see the [Kubernetes documentation](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#configure-probes).
|
||||||
|
|
||||||
|
|||||||
@@ -18,7 +18,7 @@ RKE provides users with two paths of configuration to enable at-rest data encryp
|
|||||||
- Managed at-rest data encryption
|
- Managed at-rest data encryption
|
||||||
- Custom configuration for at-rest data encryption
|
- Custom configuration for at-rest data encryption
|
||||||
|
|
||||||
Both configuration options can be added during initial cluster provisioning or by updating an exsiting cluster.
|
Both configuration options can be added during initial cluster provisioning or by updating an existing cluster.
|
||||||
|
|
||||||
To utilize this feature, a new field `secrets_encryption_config` is added to the [Kubernetes API service configuration]({{<baseurl>}}//rke/latest/en/config-options/services/#kubernetes-api-server). A full custom configuration looks like this:
|
To utilize this feature, a new field `secrets_encryption_config` is added to the [Kubernetes API service configuration]({{<baseurl>}}//rke/latest/en/config-options/services/#kubernetes-api-server). A full custom configuration looks like this:
|
||||||
|
|
||||||
|
|||||||
@@ -35,7 +35,7 @@ SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.10
|
|||||||
|
|
||||||
#### Failed to dial ssh using address [xxx.xxx.xxx.xxx:xx]: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain
|
#### Failed to dial ssh using address [xxx.xxx.xxx.xxx:xx]: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain
|
||||||
|
|
||||||
* The key file specified as `ssh_key_path` is not correct for accesing the node. Double-check if you specified the correct `ssh_key_path` for the node and if you specified the correct user to connect with.
|
* The key file specified as `ssh_key_path` is not correct for accessing the node. Double-check if you specified the correct `ssh_key_path` for the node and if you specified the correct user to connect with.
|
||||||
|
|
||||||
#### Failed to dial ssh using address [xxx.xxx.xxx.xxx:xx]: Error configuring SSH: ssh: cannot decode encrypted private keys
|
#### Failed to dial ssh using address [xxx.xxx.xxx.xxx:xx]: Error configuring SSH: ssh: cannot decode encrypted private keys
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user