diff --git a/.drone.yml b/.drone.yml index 81a13a72efa..c8b5aa426c8 100644 --- a/.drone.yml +++ b/.drone.yml @@ -7,10 +7,22 @@ pipeline: volumes: - /var/run/docker.sock:/var/run/docker.sock commands: - - docker build -f Dockerfile.prod . + - docker build --pull -f Dockerfile.prod . when: event: [pull_request] + docker-publish-algolia: + group: publish + image: plugins/docker + dockerfile: Dockerfile.algolia + repo: rancher/docs + context: . + tag: algolia + secrets: [docker_username, docker_password] + when: + branch: master + event: push + docker-publish-dev: group: publish image: plugins/docker diff --git a/Dockerfile.algolia b/Dockerfile.algolia new file mode 100644 index 00000000000..3107ac79636 --- /dev/null +++ b/Dockerfile.algolia @@ -0,0 +1,9 @@ +FROM rancher/docs:build + +VOLUME /usr/share/nginx/html/docs +WORKDIR /run + +COPY gulpfile.babel.js /run/ + +ENTRYPOINT ["gulp"] +CMD ["publish:search-index"] diff --git a/Dockerfile.prod b/Dockerfile.prod index 8cde8c68f49..65bc10b5b7a 100644 --- a/Dockerfile.prod +++ b/Dockerfile.prod @@ -1,7 +1,6 @@ FROM rancher/docs:build as build WORKDIR /run - COPY gulpfile.babel.js /run/ COPY .eslintrc.js /run/ COPY config.toml /run/ @@ -17,11 +16,13 @@ ENV HUGO_ENV production ADD https://github.com/rancherlabs/website-theme/archive/master.tar.gz master.tar.gz RUN tar -xzf master.tar.gz --strip 1 -C /run/node_modules/rancher-website-theme && rm master.tar.gz + RUN gulp build # Make sure something got built RUN stat /run/public/index.html FROM nginx +VOLUME /usr/share/nginx/html/docs COPY --from=build /run/public /usr/share/nginx/html/docs/ COPY nginx.conf /etc/nginx/conf.d/default.conf diff --git a/Dockerfile.staging b/Dockerfile.staging index 93247e0817a..fc2fbeee1df 100644 --- a/Dockerfile.staging +++ b/Dockerfile.staging @@ -1,7 +1,6 @@ FROM rancher/docs:build as build WORKDIR /run - COPY gulpfile.babel.js /run/ COPY .eslintrc.js /run/ COPY config.toml /run/ @@ -17,11 +16,13 @@ ENV HUGO_ENV production ADD https://github.com/rancherlabs/website-theme/archive/master.tar.gz master.tar.gz RUN tar -xzf master.tar.gz --strip 1 -C /run/node_modules/rancher-website-theme && rm master.tar.gz + RUN gulp build-staging # Make sure something got built RUN stat /run/public/index.html FROM nginx +VOLUME /usr/share/nginx/html/docs COPY --from=build /run/public /usr/share/nginx/html/docs/ COPY nginx.conf /etc/nginx/conf.d/default.conf diff --git a/README.md b/README.md index 60d4aef0eab..718b735d447 100644 --- a/README.md +++ b/README.md @@ -14,7 +14,3 @@ and then navigate to http://localhost:9001/. You can customize the port by pass ```bash ./scripts/dev 8080 ``` - -## Building distribution image - - diff --git a/config.toml b/config.toml index 152b97f73bf..7f02944b155 100644 --- a/config.toml +++ b/config.toml @@ -18,19 +18,19 @@ pygmentsCodeFencesGuessSyntax=true ### Edit content repo (set to automatically enter "edit" mode; this is good for "improve this page" links) ghdocsrepo = "https://github.com/rancher/docs" -[outputFormats.Search] -baseName = "search" +[outputFormats.Algolia] +baseName = "algolia" isPlaintext = true mediaType = "application/json" notAlternative = true [outputs] -home = ["HTML", "RSS", "Search"] -page = ["HTML", "Search"] +home = ["HTML", "RSS", "Algolia"] +# page = ["HTML", "Algolia"] -[params.search] -vars = ["title","summary","date","publishdate","expirydate","permalink"] -params = ["categories","tags"] +[params.algolia] +vars = ["title", "summary", "date", "publishdate", "expirydate", "permalink"] +params = ["categories", "tags"] [[menu.main]] identifier = "what-is-rancher" diff --git a/content/os/v1.x/en/installation/running-rancheros/cloud/aws/_index.md b/content/os/v1.x/en/installation/running-rancheros/cloud/aws/_index.md index 69e691183ac..969fc387daa 100644 --- a/content/os/v1.x/en/installation/running-rancheros/cloud/aws/_index.md +++ b/content/os/v1.x/en/installation/running-rancheros/cloud/aws/_index.md @@ -14,7 +14,7 @@ Once you've installed your AWS CLI, use this command to launch an EC2 instance w > **Note:** Check the RancherOS [README](https://github.com/rancher/os/blob/master/README.md) for AMI names for each region. We support PV and HVM types of AMIs. ``` -$ aws ec2 run-instances --image-id ami-ID# --count 1 --instance-type t2.micro --key-name MySSHKeyName --security-groups sg-name +$ aws ec2 run-instances --image-id ami-ID# --count 1 --instance-type t2.small --key-name MySSHKeyName --security-groups sg-name ``` Your EC2 instance is now running RancherOS! diff --git a/content/os/v1.x/en/quick-start-guide/_index.md b/content/os/v1.x/en/quick-start-guide/_index.md index 80c9e0ed169..f9d8e7322e3 100644 --- a/content/os/v1.x/en/quick-start-guide/_index.md +++ b/content/os/v1.x/en/quick-start-guide/_index.md @@ -87,7 +87,7 @@ To run this container in System Docker use the following command: ``` $ sudo system-docker run -d --net=host --name busydash husseingalal/busydash ``` -In the commad, we used `--net=host` to tell System Docker not to containerize the container's networking, and use the host’s networking instead. After running the container, you can see the monitoring server by accessing `http://`. +In the command, we used `--net=host` to tell System Docker not to containerize the container's networking, and use the host’s networking instead. After running the container, you can see the monitoring server by accessing `http://`. ![System Docker Container]({{< baseurl >}}/img/os/Rancher_busydash.png) @@ -104,7 +104,7 @@ $ sudo chmod 755 /opt/rancher/bin/start.sh Another useful command that can be used with RancherOS is `ros` which can be used to control and configure the system. ``` -$ ros -v +$ sudo ros -v ros version 0.0.1 ``` diff --git a/content/rancher/v2.x/en/admin-settings/_index.md b/content/rancher/v2.x/en/admin-settings/_index.md new file mode 100644 index 00000000000..62d16d95657 --- /dev/null +++ b/content/rancher/v2.x/en/admin-settings/_index.md @@ -0,0 +1,15 @@ +--- +title: Admin Settings +weight: 1100 +aliases: + - /rancher/v2.x/en/concepts/global-configuration/ + - /rancher/v2.x/en/tasks/global-configuration/ +--- + +After installing Rancher 2.0, you should + +1. Set a Rancher Server URL, which your cluster nodes will use to resolve with Rancher. You'll be prompted to set this URL upon your first log in. + +2. Set up external user authentication and permissions so that your organization can log into Rancher. + +After making these initial configurations, you might also want to configure one or more _pod security policies_, which are sets of conditions that your pods must meet for Kubernetes to allow them to run. diff --git a/content/rancher/v2.x/en/concepts/global-configuration/authentication/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/_index.md similarity index 87% rename from content/rancher/v2.x/en/concepts/global-configuration/authentication/_index.md rename to content/rancher/v2.x/en/admin-settings/authentication/_index.md index 06dbfa7591c..3471e124701 100644 --- a/content/rancher/v2.x/en/concepts/global-configuration/authentication/_index.md +++ b/content/rancher/v2.x/en/admin-settings/authentication/_index.md @@ -1,7 +1,11 @@ --- title: Authentication -weight: 10 +weight: 50 +aliases: + -/rancher/v2.x/en/concepts/global-configuration/authentication/ + -/rancher/v2.x/en/tasks/global-configuration/authentication/ --- + One of the key features that Rancher adds to Kubernetes is centralized user authentication. This feature allows your users to use one set of credentials to authenticate with any of your Kubernetes clusters. This centralized user authentication is accomplished using the Rancher authentication proxy, which is installed along with the rest of Rancher. This proxy authenticates your users and forwards their requests to your Kubernetes clusters using a service account. @@ -13,12 +17,17 @@ This centralized user authentication is accomplished using the Rancher authentic The Rancher authentication proxy integrates with the following external authentication services. - Microsoft Active Directory +- Microsoft Azure AD - GitHub +- FreeIPA +- OpenLDAP However, Rancher also provides local authentication. In most cases, you should use an external authentication service over local, as external authentication allows user management from a central location. However, you may want a few local authentication users for managing Rancher under rare circumstances, such as if Active Directory is down. +For more information on how to configure external authentication or local authentication, see [Authentication](../../../tasks/global-configuration/authentication/). + ### External Authentication Configuration and Principal Users Configuration of external authentication requires: diff --git a/content/rancher/v2.x/en/admin-settings/authentication/configuring-ad/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/configuring-ad/_index.md new file mode 100644 index 00000000000..024b18ff2a1 --- /dev/null +++ b/content/rancher/v2.x/en/admin-settings/authentication/configuring-ad/_index.md @@ -0,0 +1,54 @@ +--- +title: Configuring Active Directory (AD) +weight: 50 +aliases: + -/rancher/v2.x/en/tasks/global-configuration/authentication/active-directory/ +--- + +In environments using Microsoft AD, you can configure Rancher to allow sign on using AD credentials. + +>**Prerequisites:** +> +>- Have an AD server configured. +>- Create a service account in AD with `read-only` access. Rancher uses this account to verify group membership when a user makes a request using an API key. +>- Read [External Authentication Configuration and Principal Users]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/#external-authentication-configuration-and-principal-users). + +1. Sign into Rancher using a local user assigned `administrator` global permissions (i.e., the _local principal_). + +2. From the **Global** view, select **Security > Authentication** from the main menu. + +3. Select **AD**. + +4. Complete the **Configure an AD server** form. + + You may need to log in to your domain controller to find the information requested in the form. + + >**Using TLS?** + >If the certificate is self-signed or not from a recognized certificate authority, make sure you provide the complete chain. That chain is needed to verify the server's certificate. +
+
+ >**User Search Base vs. Group Search Base** + > + >Search base allows Rancher to search for users and groups that are in your AD. These fields are only for search bases and not for search filters. + > + >* If your users and groups are in the same search base, complete only the User Search Base. + >* If your groups are in a different search base, you can optionally complete the Group Search Base. This field is dedicated to searching groups, but is not required. + +5. If your AD deviates from the standard AD schema, complete the **Customize Schema** form to match it. Otherwise, skip this step. + + >**Search Attribute** As of Rancher v2.0.1, the Search Attribute field defaults with three specific values: `sAMAccountName|sn|givenName`. After AD is configured, when a user enters text to add users or groups, Rancher automatically queries the AD server and attempts to match fields by sAMAccountName, last name, or first name. Rancher specifically searches for users/groups that begin with the text entered in the search field. + > + >The default field value `sAMAccountName|sn|givenName`, but you can configure this field to a subset of these fields. The pipe (`|`) between the fields separates these fields. + > + > * `sAMAccountName`: Username + > * `sn`: Last Name + > * `givenName`: First Name + > + > With this search attribute, Rancher creates search filters for users and groups, but you *cannot* add your own search filters in this field. + +6. Enter your AD username and password in **Authenticate with AD** to confirm that Rancher is configured to use AD authentication. + +**Result:** + +- AD authentication is configured. +- You are signed into Rancher with your AD account (i.e., the _external principal_). diff --git a/content/rancher/v2.x/en/tasks/global-configuration/authentication/azure-ad/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/configuring-azure-ad/_index.md similarity index 96% rename from content/rancher/v2.x/en/tasks/global-configuration/authentication/azure-ad/_index.md rename to content/rancher/v2.x/en/admin-settings/authentication/configuring-azure-ad/_index.md index 587c9522b3d..c2bac9fabe5 100644 --- a/content/rancher/v2.x/en/tasks/global-configuration/authentication/azure-ad/_index.md +++ b/content/rancher/v2.x/en/admin-settings/authentication/configuring-azure-ad/_index.md @@ -1,10 +1,16 @@ --- -title: Configuring Azure Active Directory -weight: 3075 +title: Configuring Azure AD +weight: 75 +aliases: + -/rancher/v2.x/en/tasks/global-configuration/authentication/azure-ad/ --- +_Available as of v2.0.3_ + If you have an instance of Active Directory (AD) hosted in Azure, you can configure Rancher to allow your users to log in using their AD accounts. Configuration of Azure AD external authentication requires you to make configurations in both Azure and Rancher. +>**Prerequisite:** Have an instance of Azure AD configured. + >**Note:** Most of this procedure, with the exception of [Configure Azure AD in Rancher](#configure-azure-ad-in-rancher), takes place from the [Microsoft Azure Portal](https://portal.azure.com/). ## Azure Active Directory Configuration Outline @@ -13,7 +19,7 @@ Configuring Rancher to allow your users to authenticate with their Azure AD acco ->**Tip:** Before you start, we recommend creating an empty text file. You can use this file to copy values from Azure that you'll paste into Rancher later. +>**Tip:** Before you start, we recommend creating an empty text file. You can use this file to copy values from Azure that you'll paste into Rancher later. 1. [Register Rancher with Azure](#1-register-rancher-with-azure) @@ -54,7 +60,7 @@ Before enabling Azure AD within Rancher, you must register Rancher with Azure. 1. From **Application type**, make sure that **Web app / API** is selected. 1. In the **Sign-on URL** field, enter the URL of your Rancher Server. - + 1. Click **Create**. ### 2. Create an Azure API Key @@ -122,29 +128,29 @@ As your final step in Azure, copy the data that you'll use to configure Rancher 1. Use search to open the **Azure Active Directory** service. ![Open Azure Active Directory]({{< baseurl >}}/img/rancher/search-azure-ad.png) - + 1. From the **Azure Active Directory** menu, open **Properties**. - + 2. Copy the **Directory ID** and paste it into your [text file](#tip). - + You'll paste this value into Rancher as your **Tenant ID**. 1. Obtain your Rancher **Application ID**. - + 1. Use search to open **App registrations**. ![Open App Registrations]({{< baseurl >}}/img/rancher/search-app-registrations.png) - + 1. Find the entry you created for Rancher. - + 1. Copy the **Application ID** and paste it to your [text file](#tip). 1. Obtain your Rancher **Graph Endpoint**, **Token Endpoint**, and **Auth Endpoint**. - + 1. From **App registrations**, click **Endpoints**. ![Click Endpoints]({{< baseurl >}}/img/rancher/click-endpoints.png) - + 2. Copy the following endpoints to your clipboard and paste them into your [text file](#tip) (these values will be your Rancher endpoint values). - **Microsoft Azure AD Graph API Endpoint** (Graph Endpoint) diff --git a/content/rancher/v2.x/en/admin-settings/authentication/configuring-freeipa/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/configuring-freeipa/_index.md new file mode 100644 index 00000000000..6fb0afa428a --- /dev/null +++ b/content/rancher/v2.x/en/admin-settings/authentication/configuring-freeipa/_index.md @@ -0,0 +1,56 @@ +--- +title: Configuring FreeIPA +weight: 150 +aliases: + -/rancher/v2.x/en/tasks/global-configuration/authentication/freeipa/ +--- + +_Available as of v2.0.5_ + +If your organization uses FreeIPA for user authentication, you can configure Rancher to allow your users to login using their FreeIPA credentials. + +>**Prerequisites:** +> +>- You must have a [FreeIPA Server](https://www.freeipa.org/) configured. +>- Create a service account in FreeIPA with `read-only` access. Rancher uses this account to verify group membership when a user makes a request using an API key. +>- Read [External Authentication Configuration and Principal Users]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/#external-authentication-configuration-and-principal-users). + +1. Sign into Rancher using a local user assigned the `administrator` role (i.e., the _local principal_). + +2. From the **Global** view, select **Security > Authentication** from the main menu. + +3. Select **FreeIPA**. + +4. Complete the **Configure an FreeIPA server** form. + + You may need to log in to your domain controller to find the information requested in the form. + + >**Using TLS?** + >If the certificate is self-signed or not from a recognized certificate authority, make sure you provide the complete chain. That chain is needed to verify the server's certificate. +
+
+ >**User Search Base vs. Group Search Base** + > + >Search base allows Rancher to search for users and groups that are in your FreeIPA. These fields are only for search bases and not for search filters. + > + >* If your users and groups are in the same search base, complete only the User Search Base. + >* If your groups are in a different search base, you can optionally complete the Group Search Base. This field is dedicated to searching groups, but is not required. + +5. If your FreeIPA deviates from the standard AD schema, complete the **Customize Schema** form to match it. Otherwise, skip this step. + + >**Search Attribute** The Search Attribute field defaults with three specific values: `uid|sn|givenName`. After FreeIPA is configured, when a user enters text to add users or groups, Rancher automatically queries the FreeIPA server and attempts to match fields by user id, last name, or first name. Rancher specifically searches for users/groups that begin with the text entered in the search field. + > + >The default field value `uid|sn|givenName`, but you can configure this field to a subset of these fields. The pipe (`|`) between the fields separates these fields. + > + > * `uid`: User ID + > * `sn`: Last Name + > * `givenName`: First Name + > + > With this search attribute, Rancher creates search filters for users and groups, but you *cannot* add your own search filters in this field. + +6. Enter your FreeIPA username and password in **Authenticate with FreeIPA** to confirm that Rancher is configured to use FreeIPA authentication. + +**Result:** + +- FreeIPA authentication is configured. +- You are signed into Rancher with your FreeIPA account (i.e., the _external principal_). diff --git a/content/rancher/v2.x/en/tasks/global-configuration/authentication/github/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/configuring-github/_index.md similarity index 88% rename from content/rancher/v2.x/en/tasks/global-configuration/authentication/github/_index.md rename to content/rancher/v2.x/en/admin-settings/authentication/configuring-github/_index.md index 9e7876bd3e4..271f45e3627 100644 --- a/content/rancher/v2.x/en/tasks/global-configuration/authentication/github/_index.md +++ b/content/rancher/v2.x/en/admin-settings/authentication/configuring-github/_index.md @@ -1,11 +1,13 @@ --- -title: Configuring GitHub Authentication -weight: 3075 +title: Configuring GitHub +weight: 100 +aliases: + -/rancher/v2.x/en/tasks/global-configuration/authentication/github/ --- In environments using GitHub, you can configure Rancher to allow sign on using GitHub credentials. ->**Prerequisites:** Read [External Authentication Configuration and Principal Users]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/authentication/#external-authentication-configuration-and-principal-users). +>**Prerequisites:** Read [External Authentication Configuration and Principal Users]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/#external-authentication-configuration-and-principal-users). 1. Sign into Rancher using a local user assigned the `administrator` role (i.e., the _local principal_). @@ -48,4 +50,4 @@ In environments using GitHub, you can configure Rancher to allow sign on using G **Result:** - GitHub authentication is configured. -- You are signed into Rancher with your GitHub account (i.e., the _external principal_). \ No newline at end of file +- You are signed into Rancher with your GitHub account (i.e., the _external principal_). diff --git a/content/rancher/v2.x/en/tasks/global-configuration/authentication/local-authentication/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/configuring-local-authentication/_index.md similarity index 76% rename from content/rancher/v2.x/en/tasks/global-configuration/authentication/local-authentication/_index.md rename to content/rancher/v2.x/en/admin-settings/authentication/configuring-local-authentication/_index.md index 2356fdf5785..e65390436cf 100644 --- a/content/rancher/v2.x/en/tasks/global-configuration/authentication/local-authentication/_index.md +++ b/content/rancher/v2.x/en/admin-settings/authentication/configuring-local-authentication/_index.md @@ -1,9 +1,11 @@ --- title: Configuring Local Authentication -weight: 3075 +weight: 25 +aliases: + -/rancher/v2.x/en/tasks/global-configuration/authentication/local-authentication/ --- -Regardless of whether you use external authentication, you should create a few local authentication users so that you can continue using Rancher if you your external authentication service encounters issues. +Regardless of whether you use external authentication, you should create a few local authentication users so that you can continue using Rancher if you your external authentication service encounters issues. 1. From the **Global** view, select **Users** from the main menu. diff --git a/content/rancher/v2.x/en/admin-settings/authentication/configuring-openldap/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/configuring-openldap/_index.md new file mode 100644 index 00000000000..b442a5f1a82 --- /dev/null +++ b/content/rancher/v2.x/en/admin-settings/authentication/configuring-openldap/_index.md @@ -0,0 +1,57 @@ +--- +title: Configuring OpenLDAP +weight: 125 +aliases: + -/rancher/v2.x/en/tasks/global-configuration/authentication/openLDAP/ +--- + +_Available as of v2.0.5_ + +If your organization uses OpenLDAP for user authentication, you can configure Rancher to allow your users to login using their OpenLDAP credentials. + +>**Prerequisites:** +> +>- You must have an [OpenLDAP Server](https://www.openldap.org/) configured. +>- Create a service account in OpenLDAP with `read-only` access. Rancher uses this account to verify group membership when a user makes a request using an API key. +>- Read [External Authentication Configuration and Principal Users]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/#external-authentication-configuration-and-principal-users). + +1. Sign into Rancher using a local user assigned the `administrator` role (i.e., the _local principal_). + +2. From the **Global** view, select **Security > Authentication** from the main menu. + +3. Select **OpenLDAP**. + +4. Complete the **Configure an OpenLDAP server** form. + + You may need to log in to your domain controller to find the information requested in the form. + + >**Using TLS?** + >If the certificate is self-signed or not from a recognized certificate authority, make sure you provide the complete chain. That chain is needed to verify the server's certificate. +
+
+ >**User Search Base vs. Group Search Base** + > + >Search base allows Rancher to search for users and groups that are in your openLDAP. These fields are only for search bases and not for search filters. + > + >* If your users and groups are in the same search base, complete only the User Search Base. + >* If your groups are in a different search base, you can optionally complete the Group Search Base. This field is dedicated to searching groups, but is not required. + + +5. If your OpenLDAP deviates from the standard OpenLDAP schema, complete the **Customize Schema** form to match it. Otherwise, skip this step. + + >**Search Attribute** The Search Attribute field defaults with three specific values: `uid|sn|givenName`. After openLDAP is configured, when a user enters text to add users or groups, Rancher automatically queries the openLDAP server and attempts to match fields by user id, last name, or first name. Rancher specifically searches for users/groups that begin with the text entered in the search field. + > + >The default field value `uid|sn|givenName`, but you can configure this field to a subset of these fields. The pipe (`|`) between the fields separates these fields. + > + > * `uid`: User ID + > * `sn`: Last Name + > * `givenName`: First Name + > + > With this search attribute, Rancher creates search filters for users and groups, but you *cannot* add your own search filters in this field. + +6. Enter your OpenLDAP username and password in **Authenticate with OpenLDAP** to confirm that Rancher is configured to use OpenLDAP authentication. + +**Result:** + +- OpenLDAP authentication is configured. +- You are signed into Rancher with your OpenLDAP account (i.e., the _external principal_). diff --git a/content/rancher/v2.x/en/tasks/global-configuration/pod-security-policies/_index.md b/content/rancher/v2.x/en/admin-settings/pod-security-policies/_index.md similarity index 52% rename from content/rancher/v2.x/en/tasks/global-configuration/pod-security-policies/_index.md rename to content/rancher/v2.x/en/admin-settings/pod-security-policies/_index.md index e9eb69200a6..9857571848c 100644 --- a/content/rancher/v2.x/en/tasks/global-configuration/pod-security-policies/_index.md +++ b/content/rancher/v2.x/en/admin-settings/pod-security-policies/_index.md @@ -1,7 +1,26 @@ --- title: Pod Security Policies -weight: 125 +weight: 100 +aliases: + -/rancher/v2.x/en/concepts/global-configuration/pod-security-policies + -/rancher/v2.x/en/tasks/global-configuration/pod-security-policies --- + +_Pod Security Policies_ (or PSPs) are objects that control security-sensitive aspects of pod specification (like root privileges). If a pod does not meet the conditions specified in the PSP, Kubernetes will not allow it to start, and Rancher will display an error message of `Pod is forbidden: unable to validate...`. + +- You can assign PSPs at the cluster or project level. +- PSPs work through inheritance. + + - By default, PSPs assigned to a cluster are inherited by its projects, as well as any namespaces added to those projects. + - **Exception:** Namespaces that are not assigned to projects do not inherit PSPs, regardless of whether the PSP is assigned to a cluster or project. Because these namespaces have no PSPs, workload deployments to these namespaces will fail, which is the default Kubernetes behavior. + - You can override the default PSP by assigning a different PSP directly to the project. +- Any workloads that are already running in a cluster or project before a PSP is assigned will not be checked if it complies with the PSP. Workloads would need to be cloned or upgraded to see if they pass the PSP. + +Read more about Pod Security Policies in the [Kubernetes Documentation](https://kubernetes.io/docs/concepts/policy/pod-security-policy/). + +>**Best Practice:** +>Set Pod Security at the cluster level. + Using Rancher, you can create a Pod Security Policy using our GUI rather than creating a YAML file. ## Creating Pod Security Policies diff --git a/content/rancher/v2.x/en/tasks/global-configuration/server-url/_index.md b/content/rancher/v2.x/en/admin-settings/rancher-server-url/_index.md similarity index 60% rename from content/rancher/v2.x/en/tasks/global-configuration/server-url/_index.md rename to content/rancher/v2.x/en/admin-settings/rancher-server-url/_index.md index 6c62117577f..ffdc30ac506 100644 --- a/content/rancher/v2.x/en/tasks/global-configuration/server-url/_index.md +++ b/content/rancher/v2.x/en/admin-settings/rancher-server-url/_index.md @@ -1,8 +1,16 @@ --- title: Rancher Server URL weight: 25 +aliases: + -/rancher/v2.x/en/concepts/global-configuration/server-url + -/rancher/v2.x/en/tasks/global-configuration/server-url --- +This is the URL of your Rancher Server. All nodes in your cluster must resolve to this URL. + +- You are prompted for this URL upon the very first Rancher login. +- You can edit this URL later by selecting **Settings**. + The first time that you log into {{< product >}}, the system prompts you for the Rancher Server URL, which is the IP address or host name that your Kubernetes nodes register with. If you need to update this URL, select **Settings** from the **Global** view. diff --git a/content/rancher/v2.x/en/concepts/global-configuration/users-permissions-roles/_index.md b/content/rancher/v2.x/en/admin-settings/rbac/_index.md similarity index 97% rename from content/rancher/v2.x/en/concepts/global-configuration/users-permissions-roles/_index.md rename to content/rancher/v2.x/en/admin-settings/rbac/_index.md index 539d9da0708..e92a88dacfd 100644 --- a/content/rancher/v2.x/en/concepts/global-configuration/users-permissions-roles/_index.md +++ b/content/rancher/v2.x/en/admin-settings/rbac/_index.md @@ -1,9 +1,11 @@ --- -title: Users, Global Permissions, and Roles -weight: 15 +title: RBAC +weight: 75 +aliases: + -/rancher/v2.x/en/admin-settings/rbac/ --- -Within Rancher, each user authenticates as a _user_, which is a login that grants you access to Rancher. As mentioned in [Authenitcation]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/authentication), users can either be local or external. +Within Rancher, each person authenticates as a _user_, which is a login that grants you access to Rancher. As mentioned in [Authentication]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/authentication), users can either be local or external. After you configure external authentication, the users that display on the **Users** page changes. diff --git a/content/rancher/v2.x/en/tasks/global-configuration/roles/_index.md b/content/rancher/v2.x/en/admin-settings/rbac/creating-roles/_index.md similarity index 79% rename from content/rancher/v2.x/en/tasks/global-configuration/roles/_index.md rename to content/rancher/v2.x/en/admin-settings/rbac/creating-roles/_index.md index cb4a09b34cd..13defa7d559 100644 --- a/content/rancher/v2.x/en/tasks/global-configuration/roles/_index.md +++ b/content/rancher/v2.x/en/admin-settings/rbac/creating-roles/_index.md @@ -1,7 +1,10 @@ --- -title: Roles -weight: 100 +title: Creating Roles +weight: 25 +aliases: + -/rancher/v2.x/en/tasks/global-configuration/roles/ --- + Within Rancher, _roles_ determine what actions a user can make within a cluster or project. Note that _roles_ are different from _permissions_, which determine what clusters and projects you can access. @@ -10,8 +13,8 @@ Note that _roles_ are different from _permissions_, which determine what cluster > >To complete the tasks on this page, the following permissions are required: > ->- [Administrator Global Permissions]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/users-permissions-roles/#global-permissions). ->- [Custom Global Permissions]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/users-permissions-roles/#custom-global-permissions) with the [Manage Roles]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/users-permissions-roles/#global-permissions-reference) role assigned. +>- [Administrator Global Permissions]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/#global-permissions). +>- [Custom Global Permissions]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/#custom-global-permissions) with the [Manage Roles]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/#global-permissions-reference) role assigned. ## Adding A Custom Role @@ -23,7 +26,7 @@ While Rancher comes out-of-the-box with a set of default user roles, you can als 3. **Name** the role. -4. Choose whether to set the role to a status of [locked]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/users-permissions-roles/#locked-roles). +4. Choose whether to set the role to a status of [locked]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/#locked-roles). Locked roles cannot be assigned to users. @@ -51,7 +54,7 @@ While Rancher comes out-of-the-box with a set of default user roles, you can als ## Locking/Unlocking Roles -If you want to prevent a role from being assigned to users, you can set it to a status of `locked`. For more information about what this status means, see [Locked Roles]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/users-permissions-roles/#locked-roles). +If you want to prevent a role from being assigned to users, you can set it to a status of `locked`. For more information about what this status means, see [Locked Roles]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/#locked-roles). You can lock roles in two contexts: diff --git a/content/rancher/v2.x/en/backups/restorations/ha-restoration/_index.md b/content/rancher/v2.x/en/backups/restorations/ha-restoration/_index.md index e5877b14a1c..e4906b85a29 100644 --- a/content/rancher/v2.x/en/backups/restorations/ha-restoration/_index.md +++ b/content/rancher/v2.x/en/backups/restorations/ha-restoration/_index.md @@ -1,10 +1,10 @@ --- -title: Restoring Backups—High Availablity Installs +title: Restoring Backups—High Availability Installs weight: 370 aliases: - /rancher/v2.x/en/installation/after-installation/ha-backup-and-restoration/ --- -This procedure describes how to restore your a snapshot of `etcd` if you lose your Rancher data in a disaster scenario. +This procedure describes how to restore your a snapshot of `etcd` if you lose your Rancher data in a disaster scenario. ## Restoration Outline @@ -56,9 +56,9 @@ docker ps | grep calico | cut -f 1 -d " " | xargs docker restart To restore the most recent `etcd` snapshot on your new node, run RKE the command `rke etcd snapshot-restore`. This command reverts to any snapshot stored in `/opt/rke/etcd-snapshots` that you explicitly define. When you run `rke etcd snapshot-restore`, RKE removes the old `etcd` container if it still exists. To restore operations, RKE creates a new `etcd` cluster using the snapshot you choose. ->**Important:** When restoring the etcd database, you must restore each `etcd` to the _same_ snapshot, this means the exact same copy, so to restore you have to copy the snapshot from one of the nodes to the others before doing the `etcd snapshot-restore`. - >**Warning:** Restoring an `etcd` snapshot deletes your current `etcd` cluster and replaces it with a new one. Before you run the `rke etcd snapshot-restore` command, backup any important data in your current cluster. +> +>**Prerequisites:** {{< requirements_rollback >}} 1. From your workstation, open `rancher-cluster.yml` in your favorite text editor. diff --git a/content/rancher/v2.x/en/backups/rollbacks/ha-server-rollbacks/_index.md b/content/rancher/v2.x/en/backups/rollbacks/ha-server-rollbacks/_index.md index 913a2f12409..4a82b2de7b2 100644 --- a/content/rancher/v2.x/en/backups/rollbacks/ha-server-rollbacks/_index.md +++ b/content/rancher/v2.x/en/backups/rollbacks/ha-server-rollbacks/_index.md @@ -1,6 +1,8 @@ --- title: Rolling Back—High Availability Installs weight: 50 +aliases: + - /rancher/v2.x/en/upgrades/rollbacks/ha-server-rollbacks/ --- If you upgrade Rancher, but the upgrade does not complete successfully, you may need to roll back your Rancher Server to its last healthy state before upgrade. To restore Rancher: @@ -11,6 +13,7 @@ If you upgrade Rancher, but the upgrade does not complete successfully, you may >**Warning!** > > Rolling back to a previous version of Rancher destroys any changes made to Rancher following the upgrade. Unrecoverable data loss may occur. + > >**Prerequisites:** {{< requirements_rollback >}} diff --git a/content/rancher/v2.x/en/concepts/catalogs/_index.md b/content/rancher/v2.x/en/catalog-and-charts/_index.md similarity index 91% rename from content/rancher/v2.x/en/concepts/catalogs/_index.md rename to content/rancher/v2.x/en/catalog-and-charts/_index.md index 63cf14b40c0..4c71d9eeb3d 100644 --- a/content/rancher/v2.x/en/concepts/catalogs/_index.md +++ b/content/rancher/v2.x/en/catalog-and-charts/_index.md @@ -1,8 +1,18 @@ --- title: Catalogs and Charts -weight: 2250 +weight: 4000 +aliases: + - /rancher/v2.x/en/concepts/global-configuration/catalog/ + - /rancher/v2.x/en/tasks/global-configuration/catalog/ --- +This section includes step-by-step instruction on how to configure default and custom catalogs. + +- [Enabling Default Catalogs]({{< baseurl >}}/rancher/v2.x/en/catalog-and-charts/enabling-default-catalogs) +- [Adding Custom Catalogs]({{< baseurl >}}/rancher/v2.x/en/catalog-and-charts/adding-custom-catalogs) +- [Customizing Charts]({{< baseurl >}}/rancher/v2.x/en/catalog-and-charts/customizing-charts) + + _Catalogs_ are GitHub repositories filled with applications that are ready-made for deployment. Applications are bundled in objects called _charts_. _Charts_ are a packaging format popularized by [Helm](https://docs.helm.sh/). Think of them as templates for deployments. Per Helm, charts are: @@ -18,7 +28,7 @@ Within Rancher, you can access several different catalogs either by default or t - **Library** The Library Catalog includes charts curated by Rancher. Rancher stores charts in a Git repository to expedite the fetch and update of charts. In Rancher 2.0, only global catalogs are supported. Support for cluster-level and project-level charts will be added in the future. - + This catalog features Rancher Charts, which include some [notable advantages](#chart-types) over native Helm charts. - **Helm Stable** @@ -32,9 +42,9 @@ Within Rancher, you can access several different catalogs either by default or t - **Custom** Finally, you have the option of building your own catalogs. Custom catalogs are useful when you have a handful of apps that you deploy regularly in a specific configuration. - + ### Custom Catalog Creation - + Creating a custom catalog for Rancher is straightforward. Create a Git repo and then direct Rancher toward the repo. Custom catalog requirements include: @@ -42,7 +52,7 @@ Custom catalog requirements include: - A unique name. - A URL that `git clone` can handle. -For step-by-step directions, see [Adding Custom Catalogs]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/catalog/adding-custom-catalogs). +For step-by-step directions, see [Adding Custom Catalogs]({{< baseurl >}}/rancher/v2.x/en/catalog-and-charts/adding-custom-catalogs). When you're done creating the catalog, populate it with charts. Custom catalogs can support both native Helm charts and Rancher charts. See [Custom Chart Creation](#custom-chart-creation). @@ -132,15 +142,15 @@ The following table demonstrates the directory structure for a chart, which can Before you create your own custom catalog, you should have a basic understanding about how a Rancher chart differs from a native Helm chart. Rancher charts differ slightly from Helm charts in their directory structures. Rancher charts include two files that Helm charts do not. - `app-readme.md` - + A file that provides descriptive text in the chart's UI header. The following image displays the difference between a Rancher chart (which includes `app-readme.md`) and a native Helm chart (which does not). Rancher Chart with app-readme.md (left) vs. Helm Chart without (right) ![app-readme.md]({{< baseurl >}}/img/rancher/app-readme.png) - + - `questions.yml` - + A file that contains questions for a form. These form questions simplify deployment of a chart. Without it, you must configure the deployment using key value pairs, which is more difficult. The following image displays the difference between a Rancher chart (which includes `questions.yml`) and a native Helm chart (which does not). @@ -153,6 +163,6 @@ Before you create your own custom catalog, you should have a basic understanding You can fill your custom catalogs with either Helm Charts or Rancher Charts, although we recommend Rancher Charts due to their enhanced user experience. - For information on how to add and customize charts for a custom catalog, see [Customizing Charts]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/catalog/customizing-charts). + For information on how to add and customize charts for a custom catalog, see [Customizing Charts]({{< baseurl >}}/rancher/v2.x/en/catalog-and-charts/customizing-charts). >**Note:** For a complete walkthrough of developing charts, see the upstream Helm chart [developer reference](https://docs.helm.sh/developing_charts/). diff --git a/content/rancher/v2.x/en/tasks/global-configuration/catalog/adding-custom-catalogs/_index.md b/content/rancher/v2.x/en/catalog-and-charts/adding-custom-catalogs/_index.md similarity index 81% rename from content/rancher/v2.x/en/tasks/global-configuration/catalog/adding-custom-catalogs/_index.md rename to content/rancher/v2.x/en/catalog-and-charts/adding-custom-catalogs/_index.md index 2ffd60ae731..6a2d95e72b6 100644 --- a/content/rancher/v2.x/en/tasks/global-configuration/catalog/adding-custom-catalogs/_index.md +++ b/content/rancher/v2.x/en/catalog-and-charts/adding-custom-catalogs/_index.md @@ -1,6 +1,8 @@ --- title: Adding Custom Catalogs -weight: 50 +weight: 4015 +aliases: + - /rancher/v2.x/en/tasks/global-configuration/catalog/adding-custom-catalogs/ --- You can create custom catalogs of charts for use in Rancher. Custom catalogs are helpful for fast deployment of applications unique to your environment. @@ -23,8 +25,8 @@ You can create custom catalogs of charts for use in Rancher. Custom catalogs are 2. Click **Add Catalog**. 3. Complete the form and click **Create**. -**Result**: Your catalog is added to Rancher. +**Result**: Your catalog is added to Rancher. ## What's Next? -Add native Helm charts, Rancher charts, or both to your repository. For more information, see [Customizing Charts]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/catalog/customizing-charts/). \ No newline at end of file +Add native Helm charts, Rancher charts, or both to your repository. For more information, see [Customizing Charts]({{< baseurl >}}/rancher/v2.x/en/catalog-and-charts/customizing-charts/). diff --git a/content/rancher/v2.x/en/tasks/global-configuration/catalog/customizing-charts/_index.md b/content/rancher/v2.x/en/catalog-and-charts/customizing-charts/_index.md similarity index 97% rename from content/rancher/v2.x/en/tasks/global-configuration/catalog/customizing-charts/_index.md rename to content/rancher/v2.x/en/catalog-and-charts/customizing-charts/_index.md index 14d3ee107bd..a72c0eb5ab4 100644 --- a/content/rancher/v2.x/en/tasks/global-configuration/catalog/customizing-charts/_index.md +++ b/content/rancher/v2.x/en/catalog-and-charts/customizing-charts/_index.md @@ -1,6 +1,8 @@ --- title: Customizing Charts -weight: 75 +weight: 4020 +aliases: + - /rancher/v2.x/en/tasks/global-configuration/catalog/customizing-charts/ --- Before you can deploy customized catalog apps using Rancher, you must add charts to the GitHub repository serving as your custom catalog. @@ -11,7 +13,7 @@ The custom catalog can contain native Helm charts, Rancher charts, or a combinat >- Recommended: Read [Catalogs and Charts]({{< baseurl >}}/rancher/v2.x/en/concepts/catalogs). >- Create a GitHub repository to serve as your custom catalog. ->- Complete [Adding Custom Catalogs]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/catalog/adding-custom-catalogs). +>- Complete [Adding Custom Catalogs]({{< baseurl >}}/rancher/v2.x/en/catalog-and-charts/adding-custom-catalogs). >**Note:** Customization of Helm charts takes place outside of the Rancher UI. @@ -19,7 +21,7 @@ The custom catalog can contain native Helm charts, Rancher charts, or a combinat Rancher requires this directory structure, although `app-readme.md` and `questions.yml` are optional. - >**Tip:** + >**Tip:** > >- To begin customizing a chart, copy one from either the [Rancher Library](https://github.com/rancher/charts) or the [Helm Stable](https://github.com/kubernetes/charts/tree/master/stable). >- For a complete walk through of developing charts, see the upstream Helm chart [developer reference](https://docs.helm.sh/developing_charts/). diff --git a/content/rancher/v2.x/en/tasks/global-configuration/catalog/enabling-default-catalogs/_index.md b/content/rancher/v2.x/en/catalog-and-charts/enabling-default-catalogs/_index.md similarity index 73% rename from content/rancher/v2.x/en/tasks/global-configuration/catalog/enabling-default-catalogs/_index.md rename to content/rancher/v2.x/en/catalog-and-charts/enabling-default-catalogs/_index.md index 7faa1b57159..d0c1b1c6f90 100644 --- a/content/rancher/v2.x/en/tasks/global-configuration/catalog/enabling-default-catalogs/_index.md +++ b/content/rancher/v2.x/en/catalog-and-charts/enabling-default-catalogs/_index.md @@ -1,21 +1,23 @@ --- title: Enabling Default Catalogs -weight: 25 +weight: 4005 +aliases: + - /rancher/v2.x/en/tasks/global-configuration/catalog/enabling-default-catalogs/ --- -Out-of-the-box, you can enable several different catalog repositories to simplify deployment of applications. +Out-of-the-box, you can enable several different catalog repositories to simplify deployment of applications. 1. From the **Global** view, choose **Catalogs** from the main menu. 2. Toggle the default catalogs that you want use to a setting of **Enabled**. The [default catalogs]({{< baseurl >}}/rancher/v2.x/en/concepts/catalogs/#catalog-types) are: - + - **Library** - **Helm Stable** - **Helm Incubator** - >**Note:** If you want to use a custom catalog, see [Adding Custom Catalogs]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/catalog/adding-custom-catalogs) instead of this topic. + >**Note:** If you want to use a custom catalog, see [Adding Custom Catalogs]({{< baseurl >}}/rancher/v2.x/en/catalog-and-charts/adding-custom-catalogs) instead of this topic. **Result:** The chosen catalogs are enabled. Wait a few minutes for Rancher to replicate the catalog charts. When replication completes, you'll be able to see them in any of your projects by selecting **Catalog Apps** from the main menu. ## What's Next? -Deploy catalog applications to your cluster nodes. For more information, see [Launching a Catalog App]({{< baseurl >}}/rancher/v2.x/en/tasks/projects/launch-a-catalog-app). \ No newline at end of file +Deploy catalog applications to your cluster nodes. For more information, see [Launching a Catalog App]({{< baseurl >}}/rancher/v2.x/en/tasks/projects/launch-a-catalog-app). diff --git a/content/rancher/v2.x/en/catalog-and-charts/launching-catalog-apps/_index.md b/content/rancher/v2.x/en/catalog-and-charts/launching-catalog-apps/_index.md new file mode 100644 index 00000000000..6d1645d43e7 --- /dev/null +++ b/content/rancher/v2.x/en/catalog-and-charts/launching-catalog-apps/_index.md @@ -0,0 +1,4 @@ +--- +title: Launching Catalog Applications +weight: 4010 +--- diff --git a/content/rancher/v2.x/en/concepts/cli-configuration/_index.md b/content/rancher/v2.x/en/cli/_index.md similarity index 96% rename from content/rancher/v2.x/en/concepts/cli-configuration/_index.md rename to content/rancher/v2.x/en/cli/_index.md index 03bd293e61c..c8876b2e9b4 100644 --- a/content/rancher/v2.x/en/concepts/cli-configuration/_index.md +++ b/content/rancher/v2.x/en/cli/_index.md @@ -1,6 +1,8 @@ --- title: Rancher CLI -weight: 1 +weight: 6000 +aliases: + - /rancher/v2.x/en/concepts/cli-configuration/ --- Rancher CLI (Command Line Interface) is a unified tool that you can use to interact with Rancher. With this tool, you can operate Rancher using a command line rather than the GUI. @@ -14,7 +16,7 @@ The binary can be downloaded directly from the UI. The link can be found in the After you download the Rancher CLI, you need to make a few configurations. Rancher CLI requires: - Your [Rancher Server URL]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/server-url), which is used to connect to Rancher Server. -- An API Bearer Token, which is used to authenticate with Rancher. For more information about obtaining a Bearer Token, see [Creating an API Key]({{< baseurl >}}/rancher/v2.x/en/tasks/user-settings/api-keys/_index.md). +- An API Bearer Token, which is used to authenticate with Rancher. For more information about obtaining a Bearer Token, see [Creating an API Key]({{< baseurl >}}/rancher/v2.x/en/user-settings/api-keys/). ### CLI Authentication @@ -62,7 +64,7 @@ The following commands are available for use in Rancher CLI. - `clusters, [cluster]` - Performs operations on your [clusters]({{< baseurl >}}/rancher/v2.x/en/concepts/clusters). + Performs operations on your [clusters]({{< baseurl >}}/rancher/v2.x/en/clusters/). - `context` diff --git a/content/rancher/v2.x/en/clusters/_index.md b/content/rancher/v2.x/en/clusters/_index.md new file mode 100644 index 00000000000..9cab01a0590 --- /dev/null +++ b/content/rancher/v2.x/en/clusters/_index.md @@ -0,0 +1,72 @@ +--- +title: Creating Kubernetes Clusters +weight: 2000 +aliases: + - /rancher/v2.x/en/concepts/clusters/ + - /rancher/v2.x/en/concepts/clusters/cluster-providers/ + - /rancher/v2.x/en/tasks/clusters/ + - /rancher/v2.x/en/tasks/clusters/creating-a-cluster/ +--- + +## What's a Kubernetes Cluster? + +A cluster is a group of computing resources that work as a team to accomplish a goal. Each individual computer in a cluster is called a _node_. + +## Cluster Creation + +Rancher simplifies creation of Kubernetes clusters by allowing you to create them with the Rancher UI rather than a config file. + +### Node Components + +A Kubernetes cluster contains 3 types of nodes: etcd nodes, control plane nodes, and worker nodes. + +#### etcd Nodes + +The etcd nodes are used to run the etcd database. etcd is a key value store used as Kubernetes’ backing store for all cluster data. Even though you can run etcd on a single node, you need 3, 5, or 7 nodes for redundancy. + +#### Control Plane Nodes + +The control plane nodes are used to run the Kubernetes API server, scheduler, and controller manager. Control plane nodes are stateless since all cluster data are stored on etcd nodes. You can run control plane on 1 node, although 2 or more nodes are required for redundancy. You can also run control plane on etcd nodes. + +#### Worker Nodes + +Worker nodes are used to run the kubelet and the workload. It also runs the storage and networking drivers and ingress controllers when required. You create as many worker nodes as needed for your workload needs. + + +Using Rancher, you can create Kubernetes clusters using a variety of options. Use the option that best fits your use case. + +## Hosted Kubernetes Providers + +By integrating with cloud APIs, Rancher lets you create new Kubernetes clusters through hosted providers, all within the Rancher UI. You can create clusters using either: + +- A hosted Kubernetes provider, such as Google GKE, Amazon EKS, or Microsoft AKS. +- An IaaS provider, using nodes provided from Amazon EC2, Microsoft Azure, or DigitalOcean. + +## Rancher-Launched Kubernetes + +Alternatively, you can use Rancher to create a cluster from your own existing nodes, using RKE. RKE is Rancher’s own lightweight Kubernetes installer. It works with any bare metal server, cloud provider, or virtualization platform. It integrates with node drivers to automatically provision nodes on AWS, Azure, DigitalOcean, vSphere, OpenStack, etc. Users can add custom nodes to the cluster by running the Rancher agent on these nodes. + +## Kubernetes Importation + +Finally, you also have the option of importing an existing Kubernetes cluster that you're already using into Rancher. + + +Using Rancher, you can create Kubernetes clusters using a variety of options. Use the option that best fits your use case. + +## Hosted Kubernetes Providers + +If you already have a cluster hosted by a Kubernetes provider such as Google GKE, Rancher can integrate with its cloud APIs, allowing you to manage your hosted cluster from the Rancher UI. + +## Infrastructure Providers + +Using Rancher, you can leverage APIs from major IaaS providers to create nodes and provision a new Kubernetes cluster. + +## From Existing Nodes + +Use Rancher to create a Kubernetes cluster on your on-premise bare metal servers. This option creates a cluster using RKE, which is Rancher's own lightweight Kubernetes installer. + +In addition to bare metal servers, RKE can also create clusters on less popular IaaS providers by integrating with node drivers. + +## Import Existing Clusters + +Users can import an existing Kubernetes cluster into Rancher. Rancher does not automate the provisioning, scaling, and upgrade of imported Kubernetes clusters. All other cluster management, policy management, and workload management capabilities of Rancher apply to imported clusters. diff --git a/content/rancher/v2.x/en/clusters/custom-clusters/_index.md b/content/rancher/v2.x/en/clusters/custom-clusters/_index.md new file mode 100644 index 00000000000..1da681335d1 --- /dev/null +++ b/content/rancher/v2.x/en/clusters/custom-clusters/_index.md @@ -0,0 +1,6 @@ +--- +title: Creating a Custom Cluster +shortTitle: Custom Cluster +weight: 2400 + +--- diff --git a/content/rancher/v2.x/en/clusters/hosted-kubernetes-clusters/_index.md b/content/rancher/v2.x/en/clusters/hosted-kubernetes-clusters/_index.md new file mode 100644 index 00000000000..e87e7e9561c --- /dev/null +++ b/content/rancher/v2.x/en/clusters/hosted-kubernetes-clusters/_index.md @@ -0,0 +1,54 @@ +--- +title: Hosted Kubernetes Providers +weight: 2100 +--- + +If you already have a cluster hosted by a Kubernetes provider, Rancher can integrate with its cloud APIs, allowing you to manage your hosted cluster from the Rancher UI. + +Rancher supports the following Kubernetes providers: + + + +- [Google GKE (Google Container Engine)](#google-gke-google-container-engine) +- [Amazon EKS (Elastic Container Service)](#amazon-eks-elastic-container-service) +- [Microsoft AKS (Azure Container Service)](#microsoft-aks-azure-container-service) + + + +When setting up management of your hosted Kubernetes cluster in the Rancher UI, you are prompted for parameters required in all cluster creation scenarios: cluster name, user membership, how many nodes to create, and so on. However, each provider also requires information unique to the vendor. See more information about the information required for each provider below. + +## Google GKE (Google Container Engine) + +Before Rancher can manage a Google GKE cluster, you must create a service account with Google. This account also requires you to assign it the appropriate roles. + +Create a service account using [Google Cloud Platform](https://console.cloud.google.com/projectselector/iam-admin/serviceaccounts). GKE uses this account to operate your cluster. Creating this account also generates a private key used for authentication. + +The service account requires the following roles: + +- `project/viewer` +- `kubernetes-engine/admin` +- `service-account/user` + +For full instructions on how to complete these actions, see [Creating and Enabling Service Accounts](https://cloud.google.com/compute/docs/access/create-enable-service-accounts-for-instances). + +After you create a service account, enter your service account private key into Rancher. + +## Amazon EKS (Elastic Container Service) + +Before Rancher can manage an Amazon EKS cluster, you must provide it with an Amazon access key that has the appropriate permissions assigned to it. + +Log into the [Amazon AWS Management Console](https://aws.amazon.com/console/) to assign yourself the appropriate IAM permissions and create an access key. Complete the actions below. + +- Assign the account you're using the IAM permissions to create clusters, modify clusters, and use the required API actions. For more information, see the official [EKS documentation](https://docs.aws.amazon.com/eks/latest/userguide/IAM_policies.html). + +- Create an Amazon access key and secret key. For more information, see [Managing Access Keys for IAM Users](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html) + +After you complete the two actions above, enter your access key and secret key in Rancher. + +## Microsoft AKS (Azure Container Service) + +Before Rancher can manage a Microsoft AKS cluster, you must provide it with information from your Azure Active Directory Service Principal (here after, _service principal_). Rancher uses this service principal to interact with the Azure API. + +For instruction on how to create a service principal, see [Service Principals with Azure Kubernetes Service (AKS)](https://docs.microsoft.com/en-us/azure/aks/kubernetes-service-principal). + +After you complete the action above, enter the information from your service principal in Rancher. diff --git a/content/rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-azure-container-service/_index.md b/content/rancher/v2.x/en/clusters/hosted-kubernetes-clusters/aks/_index.md similarity index 90% rename from content/rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-azure-container-service/_index.md rename to content/rancher/v2.x/en/clusters/hosted-kubernetes-clusters/aks/_index.md index 13f496cef5f..46227bd4862 100644 --- a/content/rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-azure-container-service/_index.md +++ b/content/rancher/v2.x/en/clusters/hosted-kubernetes-clusters/aks/_index.md @@ -1,7 +1,9 @@ --- title: Creating an AKS Cluster shortTitle: Azure Container Service -weight: 3350 +weight: 2115 +aliases: + - /rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-azure-container-service/_index.md --- You can use Rancher to create a cluster using Microsoft Azure Container Service. diff --git a/content/rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-eks/_index.md b/content/rancher/v2.x/en/clusters/hosted-kubernetes-clusters/eks/_index.md similarity index 94% rename from content/rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-eks/_index.md rename to content/rancher/v2.x/en/clusters/hosted-kubernetes-clusters/eks/_index.md index eb58c77563b..62af862f0fc 100644 --- a/content/rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-eks/_index.md +++ b/content/rancher/v2.x/en/clusters/hosted-kubernetes-clusters/eks/_index.md @@ -1,7 +1,9 @@ --- title: Creating an EKS Cluster shortTitle: Amazon EKS -weight: 3325 +weight: 2110 +aliases: + - /rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-eks/_index.md --- ## Objectives diff --git a/content/rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-gke/_index.md b/content/rancher/v2.x/en/clusters/hosted-kubernetes-clusters/gke/_index.md similarity index 94% rename from content/rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-gke/_index.md rename to content/rancher/v2.x/en/clusters/hosted-kubernetes-clusters/gke/_index.md index 4f72c17dd61..e0856d9c16a 100644 --- a/content/rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-gke/_index.md +++ b/content/rancher/v2.x/en/clusters/hosted-kubernetes-clusters/gke/_index.md @@ -1,7 +1,9 @@ --- title: Creating a GKE Cluster shortTitle: Google Container Engine -weight: 3325 +weight: 2105 +aliases: + - /rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-gke/_index.md --- ## Objectives diff --git a/content/rancher/v2.x/en/tasks/clusters/import-cluster/_index.md b/content/rancher/v2.x/en/clusters/imported-clusters/_index.md similarity index 92% rename from content/rancher/v2.x/en/tasks/clusters/import-cluster/_index.md rename to content/rancher/v2.x/en/clusters/imported-clusters/_index.md index 0ef11990d09..ee0e464256d 100644 --- a/content/rancher/v2.x/en/tasks/clusters/import-cluster/_index.md +++ b/content/rancher/v2.x/en/clusters/imported-clusters/_index.md @@ -1,6 +1,8 @@ --- -title: Importing a Cluster -weight: 3400 +title: Importing Kubernetes Clusters +weight: 2300 +aliases: + - /rancher/v2.x/en/tasks/clusters/import-cluster/ --- You can import an existing Kubernetes cluster and then manage it using Rancher. @@ -31,4 +33,4 @@ You can import an existing Kubernetes cluster and then manage it using Rancher. {{< result_create-cluster >}} > **Note:** -> You can not re-import a cluster that is currently active in a Rancher setup. +> You can not re-import a cluster that is currently active in a Rancher setup. diff --git a/content/rancher/v2.x/en/clusters/members/_index.md b/content/rancher/v2.x/en/clusters/members/_index.md new file mode 100644 index 00000000000..9f51ec378a2 --- /dev/null +++ b/content/rancher/v2.x/en/clusters/members/_index.md @@ -0,0 +1,55 @@ +--- +title: Adding Users to Clusters +weight: 2500 +aliases: + - /rancher/v2.x/en/tasks/clusters/adding-managing-cluster-members/ +--- + +If you want to provide a user with access and permissions to _all_ projects, nodes, and resources within a cluster, assign the user a cluster membership. + +>**Tip:** Want to provide a user with access to a _specific_ project within a cluster? See [Adding Project Members]({{< baseurl >}}/rancher/v2.x/en/tasks/projects/add-project-members/) instead. + +There are two contexts where you can add cluster members: + +- [Adding Members to a New Cluster]({{< baseurl >}}/rancher/v2.x/en/tasks/clusters/creating-a-cluster) + + You can add members to a cluster as you create it (recommended if possible). + +- [Adding Members to an Existing Cluster](#adding-members-to-an-existing-cluster) + + You can always add members to a cluster later. See below. + +### Adding Members to an Existing Cluster + +Following cluster creation, you can add users as cluster members so that they can access its resources. + +1. From the **Global** view, open the cluster that you want to add members to. + +2. From the main menu, select **Members**. Then click **Add Member**. + +3. Search for the user or group that you want to add to the cluster. + + If external authentication is configured: + + - Rancher returns users from your [external authentication]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/authentication/) source as you type. + + >**Using AD but can't find your users?** + >There may be an issue with your search attribute configuration. See [Configuring Active Directory Authentication: Step 5]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/authentication/active-directory/). + + - A drop-down allows you to add groups instead of individual users. The drop-down only lists groups that you, the logged in user, are part of. + + >**Note:** If you are logged in as a local user, external users do not display in your search results. For more information, see [External Authentication Configuration and Principal Users]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/authentication/#external-authentication-configuration-and-principal-users). + +4. Assign the user or group **Cluster** roles. + + [What are Cluster Roles?]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/users-permissions-roles/#cluster-roles) + + >**Tip:** For Custom Roles, you can modify the list of individual roles available for assignment. + > + > - To add roles to the list, [Add a Custom Role]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/roles/#adding-a-custom-role). + > - To remove roles from the list, [Lock/Unlock Roles]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/roles/#locking-unlocking-roles). + +**Result:** The chosen users are added to the cluster. + +- To revoke cluster membership, select the user and click **Delete**. This action deletes membership, not the user. +- To modify a user's roles in the cluster, delete them from the cluster, and then re-add them with modified roles. diff --git a/content/rancher/v2.x/en/clusters/rke-clusters/_index.md b/content/rancher/v2.x/en/clusters/rke-clusters/_index.md new file mode 100644 index 00000000000..71b52cdb6cc --- /dev/null +++ b/content/rancher/v2.x/en/clusters/rke-clusters/_index.md @@ -0,0 +1,25 @@ +--- +title: Rancher Launched Kubernetes +weight: 2200 +--- + +## Infrastructure Providers + +Using Rancher, you can leverage APIs from major IaaS providers to create nodes and provision a new Kubernetes cluster, all from the Rancher UI. There's no need to log directly into your infrastructure providers's portal. + +You can create provider-hosted nodes from the Rancher UI by creating a node template. After providing Rancher with an access token from the vendor you're using, Rancher prompts you for specifications that it will send to your provider by API. The provider than provisions your nodes based on the template. + +Out-of-the-box, Rancher supports the following infrastructure providers: + +- Amazon EC2 +- Microsoft Azure +- DigitalOcean +- VMWare Vsphere + +Each vendor requires specific information that's used to authenticate with the provider API. Read more below to learn about the information required for each provider. + +## From Existing Nodes + +Use Rancher to create a Kubernetes cluster on your on-premise bare metal servers. This option creates a cluster using RKE, which is Rancher's own lightweight Kubernetes installer. In addition to bare metal servers, RKE can also create clusters on _any_ IaaS providers by integrating with node drivers. + +To use this option you'll need access to servers you intend to use as your Kubernetes cluster. Provision each server according to Rancher requirements, which includes some hardware specifications and Docker. After you install Docker on each server, run the command provided in the Rancher UI to turn each server into a Kubernetes node. diff --git a/content/rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-custom/_index.md b/content/rancher/v2.x/en/clusters/rke-clusters/custom-nodes/_index.md similarity index 95% rename from content/rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-custom/_index.md rename to content/rancher/v2.x/en/clusters/rke-clusters/custom-nodes/_index.md index 4eeb9a14491..be0ff3a7f2f 100644 --- a/content/rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-custom/_index.md +++ b/content/rancher/v2.x/en/clusters/rke-clusters/custom-nodes/_index.md @@ -1,7 +1,9 @@ --- -title: Creating a Custom Cluster -shortTitle: Custom Cluster -weight: 3225 +title: Creating a Cluster with Custom Nodes +shortTitle: Custom Nodes +weight: 2225 +aliases: + - /rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-custom/ --- ## Objectives diff --git a/content/rancher/v2.x/en/tasks/global-configuration/node-drivers/_index.md b/content/rancher/v2.x/en/clusters/rke-clusters/node-pools/_index.md similarity index 50% rename from content/rancher/v2.x/en/tasks/global-configuration/node-drivers/_index.md rename to content/rancher/v2.x/en/clusters/rke-clusters/node-pools/_index.md index 38aaf39fd97..76b44c580a5 100644 --- a/content/rancher/v2.x/en/tasks/global-configuration/node-drivers/_index.md +++ b/content/rancher/v2.x/en/clusters/rke-clusters/node-pools/_index.md @@ -1,8 +1,21 @@ --- -title: Node Drivers -weight: 150 +title: Nodes hosted in an Infrastructure Provider +weight: 2205 +aliases: + - /rancher/v2.x/en/concepts/global-configuration/node-drivers/ + - /rancher/v2.x/en/tasks/global-configuration/node-drivers/ + - /rancher/v2.x/en/concepts/global-configuration/node-templates/ --- +### Node Drivers + + +Out-of-the-box, Rancher provides support for creating clusters using many popular cloud providers: Amazon EC2, Azure, DigitalOcean, and so on. However, you may want to create a cluster using another cloud provider. In these scenarios, you can create a custom node driver for the cloud provider and point Rancher toward it. + +For more information on creating node drivers, see [https://github.com/rancher/ui-driver-skel](https://github.com/rancher/ui-driver-skel). + +#### Managing Node Drivers + >**Prerequisites:** To create, edit, or delete drivers, you need _one_ of the following permissions: > >- [Administrator Global Permissions]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/users-permissions-roles/#global-permissions) @@ -25,3 +38,10 @@ Using the **Custom** option, you can create a cluster using virtually any cloud 1. From the **Global** view, select **Node Drivers** from the main menu. 2. Select the inactive drivers that you want to use. Then click **Add Node Driver**. + + +### Node templates + +You can create new clusters within Rancher using _node templates_. A node template is a virtual machine image used to create a Kubernetes cluster. While creating a cluster, Rancher will prompt you for an image to use as a template. Follow the directions on screen to create the template. During cluster creation, Rancher clones the template and installs different Kubernetes components. + +After you add a node template to Rancher, its stored by the system so that you can use it when creating another cluster later. Node templates are bound to your login. After you add a template, you can remove them from your user profile. diff --git a/content/rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-azure/_index.md b/content/rancher/v2.x/en/clusters/rke-clusters/node-pools/azure/_index.md similarity index 90% rename from content/rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-azure/_index.md rename to content/rancher/v2.x/en/clusters/rke-clusters/node-pools/azure/_index.md index d44fde15ba9..dfece5159ba 100644 --- a/content/rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-azure/_index.md +++ b/content/rancher/v2.x/en/clusters/rke-clusters/node-pools/azure/_index.md @@ -1,7 +1,9 @@ --- title: Creating an Azure Cluster shortTitle: Azure -weight: 3300 +weight: 2220 +aliases: + - /rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-azure/ --- Use {{< product >}} to create a Kubernetes cluster in Azure. diff --git a/content/rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-digital-ocean/_index.md b/content/rancher/v2.x/en/clusters/rke-clusters/node-pools/digital-ocean/_index.md similarity index 87% rename from content/rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-digital-ocean/_index.md rename to content/rancher/v2.x/en/clusters/rke-clusters/node-pools/digital-ocean/_index.md index f61f0544162..1d6f53926b4 100644 --- a/content/rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-digital-ocean/_index.md +++ b/content/rancher/v2.x/en/clusters/rke-clusters/node-pools/digital-ocean/_index.md @@ -1,7 +1,9 @@ --- -title: Creating a DigitalOcean Clusters +title: Creating a DigitalOcean Cluster shortTitle: DigitalOcean -weight: 3275 +weight: 2215 +aliases: + - /rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-digital-ocean/ --- Use {{< product >}} to create a Kubernetes cluster using DigitalOcean. diff --git a/content/rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-amazon-ec2/_index.md b/content/rancher/v2.x/en/clusters/rke-clusters/node-pools/ec2/_index.md similarity index 92% rename from content/rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-amazon-ec2/_index.md rename to content/rancher/v2.x/en/clusters/rke-clusters/node-pools/ec2/_index.md index ebda0e25e5a..54bba1dbad9 100644 --- a/content/rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-amazon-ec2/_index.md +++ b/content/rancher/v2.x/en/clusters/rke-clusters/node-pools/ec2/_index.md @@ -1,7 +1,9 @@ --- title: Creating an Amazon EC2 Cluster shortTitle: Amazon EC2 -weight: 3250 +weight: 2210 +aliases: + - /rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-amazon-ec2/ --- Use {{< product >}} to create a Kubernetes cluster in Amazon EC2. diff --git a/content/rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-vsphere/_index.md b/content/rancher/v2.x/en/clusters/rke-clusters/node-pools/vsphere/_index.md similarity index 95% rename from content/rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-vsphere/_index.md rename to content/rancher/v2.x/en/clusters/rke-clusters/node-pools/vsphere/_index.md index 7dc13b55153..8576632ad4b 100644 --- a/content/rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-vsphere/_index.md +++ b/content/rancher/v2.x/en/clusters/rke-clusters/node-pools/vsphere/_index.md @@ -1,7 +1,9 @@ --- title: Creating a vSphere Cluster shortTitle: vSphere -weight: 3375 +weight: 2225 +aliases: + - /rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-vsphere/ --- Use {{< product >}} to create a Kubernetes cluster in vSphere. diff --git a/content/rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-vsphere/globalpermissionfinal.png b/content/rancher/v2.x/en/clusters/rke-clusters/node-pools/vsphere/globalpermissionfinal.png similarity index 100% rename from content/rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-vsphere/globalpermissionfinal.png rename to content/rancher/v2.x/en/clusters/rke-clusters/node-pools/vsphere/globalpermissionfinal.png diff --git a/content/rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-vsphere/globalpermissionrole.png b/content/rancher/v2.x/en/clusters/rke-clusters/node-pools/vsphere/globalpermissionrole.png similarity index 100% rename from content/rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-vsphere/globalpermissionrole.png rename to content/rancher/v2.x/en/clusters/rke-clusters/node-pools/vsphere/globalpermissionrole.png diff --git a/content/rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-vsphere/globalpermissionuser.png b/content/rancher/v2.x/en/clusters/rke-clusters/node-pools/vsphere/globalpermissionuser.png similarity index 100% rename from content/rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-vsphere/globalpermissionuser.png rename to content/rancher/v2.x/en/clusters/rke-clusters/node-pools/vsphere/globalpermissionuser.png diff --git a/content/rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-vsphere/rancherroles1.png b/content/rancher/v2.x/en/clusters/rke-clusters/node-pools/vsphere/rancherroles1.png similarity index 100% rename from content/rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-vsphere/rancherroles1.png rename to content/rancher/v2.x/en/clusters/rke-clusters/node-pools/vsphere/rancherroles1.png diff --git a/content/rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-vsphere/rancherroles2.png b/content/rancher/v2.x/en/clusters/rke-clusters/node-pools/vsphere/rancherroles2.png similarity index 100% rename from content/rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-vsphere/rancherroles2.png rename to content/rancher/v2.x/en/clusters/rke-clusters/node-pools/vsphere/rancherroles2.png diff --git a/content/rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-vsphere/rancheruser.png b/content/rancher/v2.x/en/clusters/rke-clusters/node-pools/vsphere/rancheruser.png similarity index 100% rename from content/rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-vsphere/rancheruser.png rename to content/rancher/v2.x/en/clusters/rke-clusters/node-pools/vsphere/rancheruser.png diff --git a/content/rancher/v2.x/en/clusters/rke-clusters/options/_index.md b/content/rancher/v2.x/en/clusters/rke-clusters/options/_index.md new file mode 100644 index 00000000000..8dbef6dea51 --- /dev/null +++ b/content/rancher/v2.x/en/clusters/rke-clusters/options/_index.md @@ -0,0 +1,4 @@ +--- +title: Cluster Options +weight: 2250 +--- diff --git a/content/rancher/v2.x/en/concepts/clusters/cloud-providers/_index.md b/content/rancher/v2.x/en/clusters/rke-clusters/options/cloud-providers/_index.md similarity index 89% rename from content/rancher/v2.x/en/concepts/clusters/cloud-providers/_index.md rename to content/rancher/v2.x/en/clusters/rke-clusters/options/cloud-providers/_index.md index 0385ddc78c0..f3c49a530a0 100644 --- a/content/rancher/v2.x/en/concepts/clusters/cloud-providers/_index.md +++ b/content/rancher/v2.x/en/clusters/rke-clusters/options/cloud-providers/_index.md @@ -1,6 +1,8 @@ --- -title: Cloud Providers -weight: 2110 +title: Selecting Cloud Providers +weight: 2255 +aliases: + - /rancher/v2.x/en/concepts/clusters/cloud-providers/ --- A _cloud provider_ is a module in Kubernetes that provides an interface for managing nodes, load balancers, and networking routes. You can configure a cloud provider to automatically provision load balancers or persistent storage devices when launching Kubernetes definitions, provided that the cloud provider you're using supports such automation. @@ -25,7 +27,7 @@ When using the `Amazon` cloud provider, you can leverage the following capabilit - Create/configure an IAM role - Configuring the ClusterID -> **Note:** When you create an [Amazon EC2 Cluster]({{< baseurl >}}/rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-amazon-ec2/#create-the-amazon-ec2-cluster), the `ClusterID` is automatically configured. +> **Note:** When you create an [Amazon EC2 Cluster]({{< baseurl >}}/rancher/v2.x/en/clusters/rke-clusters/node-pools/ec2/#create-the-amazon-ec2-cluster), the `ClusterID` is automatically configured. #### Create/Configure an IAM Role @@ -33,8 +35,8 @@ All nodes added to the cluster must be able to interact with EC2 so that they ca [EC2 documentation: Creating an IAM Role](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#create-iam-role) -- While creating an [Amazon EC2 cluster]({{< baseurl >}}/rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-amazon-ec2/#create-the-amazon-ec2-cluster), you must insert the name of the IAM role when creating the **Node Template**. -- While creating a [Custom cluster]({{< baseurl >}}/rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-custom/), you must manually attach the IAM role to the instance(s). +- While creating an [Amazon EC2 cluster]({{< baseurl >}}/rancher/v2.x/en/clusters/rke-clusters/node-pools/ec2/#create-the-amazon-ec2-cluster), you must insert the name of the IAM role when creating the **Node Template**. +- While creating a [Custom cluster]({{< baseurl >}}/rancher/v2.x/en/clusters/custom-clusters/), you must manually attach the IAM role to the instance(s). The following IAM role can be created: @@ -156,3 +158,13 @@ Last thing you will need to do, is assign the appropriate permissions to your Ap Custom Azure Network Security Group needed to allow Azure Load Balancers to work. If you provision hosts using Rancher Machine Azure driver, you will need to edit them manually to assign them to this Network Security Group. You should already assign custom hosts to this Network Security Group during provisioning. Only hosts expected to be Load Balancer backends need to be in this group. + +## Related Links + +### External Links + +- [Cloud Providers](https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/) + +### Tutorials + +- [Creating a Cluster]({{< baseurl >}}/rancher/v2.x/en/tasks/clusters/creating-a-cluster/) diff --git a/content/rancher/v2.x/en/clusters/rke-clusters/options/pod-security-policies/_index.md b/content/rancher/v2.x/en/clusters/rke-clusters/options/pod-security-policies/_index.md new file mode 100644 index 00000000000..7919b19cce0 --- /dev/null +++ b/content/rancher/v2.x/en/clusters/rke-clusters/options/pod-security-policies/_index.md @@ -0,0 +1,4 @@ +--- +title: Pod Security Policies +weight: 2260 +--- diff --git a/content/rancher/v2.x/en/concepts/alerts-and-notifiers/_index.md b/content/rancher/v2.x/en/concepts/alerts-and-notifiers/_index.md deleted file mode 100644 index 1538a3ffe5b..00000000000 --- a/content/rancher/v2.x/en/concepts/alerts-and-notifiers/_index.md +++ /dev/null @@ -1,5 +0,0 @@ ---- -title: Alerts and Notifiers -weight: 2300 -draft: true ---- diff --git a/content/rancher/v2.x/en/concepts/api-keys/_index.md b/content/rancher/v2.x/en/concepts/api-keys/_index.md deleted file mode 100644 index c368f698011..00000000000 --- a/content/rancher/v2.x/en/concepts/api-keys/_index.md +++ /dev/null @@ -1,14 +0,0 @@ ---- -title: API Keys -weight: 2400 ---- - -Some users may want to access their Rancher clusters and projects through the Rancher API. Before you can access Rancher through the API, you must generate API keys so that you can authenticate with Rancher externally. - -Before you can use the Rancher CLI or write a program that calls the Rancher API, you must obtain API keys using the Rancher UI. - -### API Keys and User Authentication - -After logging into Rancher, you can generate API keys for accessing Rancher externally using your user settings. If you need to revoke access to the Rancher API, you can delete the API key. - -For instructions on how to create an API key, see [Creating an API Key]({{< baseurl >}}/rancher/v2.x/en/tasks/user-settings/api-keys/). diff --git a/content/rancher/v2.x/en/concepts/ci-cd-pipelines/_index.md b/content/rancher/v2.x/en/concepts/ci-cd-pipelines/_index.md deleted file mode 100644 index fa26a43fbe5..00000000000 --- a/content/rancher/v2.x/en/concepts/ci-cd-pipelines/_index.md +++ /dev/null @@ -1,17 +0,0 @@ ---- -title: Pipelines -weight: 2350 ---- - -Pipelines help you automate the software delivery process. You can integrate Rancher with GitHub to create a pipeline. - -You can set up your pipeline to run a series of stages and steps to test your code and deploy it. - -
-
Pipelines
-
Contain a series of stages and steps. Out-of-the-box, the pipelines feature supports fan out and in capabilities.
-
Stages
-
Executed sequentially. The next stage will not execute until all of the steps within the stage execute.
-
Steps
-
Are executed in parallel within a stage.
-
diff --git a/content/rancher/v2.x/en/concepts/clusters/_index.md b/content/rancher/v2.x/en/concepts/clusters/_index.md deleted file mode 100644 index f81062f12d0..00000000000 --- a/content/rancher/v2.x/en/concepts/clusters/_index.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: Clusters -weight: 2100 ---- - -## What's a Cluster? - -A cluster is a group of computing resources that work as a team to accomplish a goal. Each individual computer in a cluster is called a _node_. - -## Cluster Creation - -Rancher simplifies creation of Kubernetes clusters by allowing you to create them with the Rancher UI rather than a config file. - -### Node Components - -A Kubernetes cluster contains 3 types of nodes: etcd nodes, control plane nodes, and worker nodes. - -#### etcd Nodes - -The etcd nodes are used to run the etcd database. etcd is a key value store used as Kubernetes’ backing store for all cluster data. Even though you can run etcd on a single node, you need 3, 5, or 7 nodes for redundancy. - -#### Control Plane Nodes - -The control plane nodes are used to run the Kubernetes API server, scheduler, and controller manager. Control plane nodes are stateless since all cluster data are stored on etcd nodes. You can run control plane on 1 node, although 2 or more nodes are required for redundancy. You can also run control plane on etcd nodes. - -#### Worker Nodes - -Worker nodes are used to run the kubelet and the workload. It also runs the storage and networking drivers and ingress controllers when required. You create as many worker nodes as needed for your workload needs. diff --git a/content/rancher/v2.x/en/concepts/clusters/cluster-providers/_index.md b/content/rancher/v2.x/en/concepts/clusters/cluster-providers/_index.md deleted file mode 100644 index bef466b8db6..00000000000 --- a/content/rancher/v2.x/en/concepts/clusters/cluster-providers/_index.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: Cluster Providers -weight: 2105 ---- - -## Rancher Kubernetes Engine (RKE) - -RKE is Rancher’s own lightweight Kubernetes installer. It works with any cloud providers, virtualization platforms, or bare metal servers. It integrates with node drivers to automatically provision nodes on AWS, Azure, DigitalOcean, vSphere, OpenStack, etc. Users can add custom nodes to the cluster by running the Rancher agent on these nodes. - - - -## Cloud-Managed Kubernetes Clusters - -Rancher integrates with cloud APIs so users can provision GKE, EKS, and AKS clusters directly from Rancher. New cloud managed Kubernetes clusters will be added as they become available. - -## Imported Clusters - -Users can import an existing Kubernetes cluster into Rancher. Rancher does not automate the provisioning, scaling, and upgrade of imported Kubernetes clusters. All other cluster management, policy management, and workload management capabilities of Rancher apply to imported clustered. diff --git a/content/rancher/v2.x/en/concepts/global-configuration/_index.md b/content/rancher/v2.x/en/concepts/global-configuration/_index.md deleted file mode 100644 index f4f7545d47c..00000000000 --- a/content/rancher/v2.x/en/concepts/global-configuration/_index.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -title: Global Configuration -weight: 1 ---- -After installing Rancher 2.0, you should configure it to support your users and environment. This section describes the global configurations you should make after installation. - -- [Rancher Server URL]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/server-url) -- [Authentication]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/authentication/) -- [Users, Roles, and Permissions]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/users-roles-permissions) -- [Pod Security Policies]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/pod-security-policies) -- [Node Drivers]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/node-drivers) -- [Node Templates]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/node-templates) - diff --git a/content/rancher/v2.x/en/concepts/global-configuration/node-drivers/_index.md b/content/rancher/v2.x/en/concepts/global-configuration/node-drivers/_index.md deleted file mode 100644 index 943c9c0d4da..00000000000 --- a/content/rancher/v2.x/en/concepts/global-configuration/node-drivers/_index.md +++ /dev/null @@ -1,10 +0,0 @@ ---- -title: Node Drivers -weight: 100 ---- - -Out-of-the-box, Rancher provides support for creating clusters using many popular cloud providers: Amazon EC2, Azure, DigitalOcean, and so on. However, you may want to create a cluster using another cloud provider. In these scenarios, you can create a custom node driver for the cloud provider and point Rancher toward it. - -For more information on creating node drivers, see [https://github.com/rancher/ui-driver-skel](https://github.com/rancher/ui-driver-skel). - - diff --git a/content/rancher/v2.x/en/concepts/global-configuration/node-templates/_index.md b/content/rancher/v2.x/en/concepts/global-configuration/node-templates/_index.md deleted file mode 100644 index 31d32312ba3..00000000000 --- a/content/rancher/v2.x/en/concepts/global-configuration/node-templates/_index.md +++ /dev/null @@ -1,9 +0,0 @@ ---- -title: Node Templates -weight: 125 ---- - -You can create new clusters within Rancher using _node templates_. A node template is a virtual machine image used to create a Kubernetes cluster. While creating a cluster, Rancher will prompt you for an image to use as a template. Follow the directions on screen to create the template. During cluster creation, Rancher clones the template and installs different Kubernetes components. - -After you add a node template to Rancher, its stored by the system so that you can use it when creating another cluster later. Node templates are bound to your login. After you add a template, you can remove them from your user profile. - diff --git a/content/rancher/v2.x/en/concepts/global-configuration/pod-security-policies/_index.md b/content/rancher/v2.x/en/concepts/global-configuration/pod-security-policies/_index.md deleted file mode 100644 index 7e635fa3235..00000000000 --- a/content/rancher/v2.x/en/concepts/global-configuration/pod-security-policies/_index.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: Pod Security Policies -weight: 75 ---- - -_Pod Security Policies_ (or PSPs) are objects that control security-sensitive aspects of pod specification (like root privileges). If a pod does not meet the conditions specified in the PSP, Kubernetes will not allow it to start, and Rancher will display an error message of `Pod is forbidden: unable to validate...`. - -- You can assign PSPs at the cluster or project level. -- PSPs work through inheritance. - - - By default, PSPs assigned to a cluster are inherited by its projects, as well as any namespaces added to those projects. - - **Exception:** Namespaces that are not assigned to projects do not inherit PSPs, regardless of whether the PSP is assigned to a cluster or project. Because these namespaces have no PSPs, workload deployments to these namespaces will fail, which is the default Kubernetes behavior. - - You can override the default PSP by assigning a different PSP directly to the project. -- Any workloads that are already running in a cluster or project before a PSP is assigned will not be checked if it complies with the PSP. Workloads would need to be cloned or upgraded to see if they pass the PSP. - -Read more about Pod Security Policies in the [Kubernetes Documentation](https://kubernetes.io/docs/concepts/policy/pod-security-policy/). - ->**Best Practice:** ->Set Pod Security at the cluster level. diff --git a/content/rancher/v2.x/en/concepts/global-configuration/server-url/_index.md b/content/rancher/v2.x/en/concepts/global-configuration/server-url/_index.md deleted file mode 100644 index a7bdb887aa8..00000000000 --- a/content/rancher/v2.x/en/concepts/global-configuration/server-url/_index.md +++ /dev/null @@ -1,9 +0,0 @@ ---- -title: Rancher Server URL -weight: 5 ---- - -This is the URL of your Rancher Server. All nodes in your cluster must resolve to this URL. - -- You are prompted for this URL upon the very first Rancher login. -- You can edit this URL later by selecting **Settings**. diff --git a/content/rancher/v2.x/en/concepts/load-balancing/_index.md b/content/rancher/v2.x/en/concepts/load-balancing/_index.md index c6f9837225f..f78cdbb88b0 100644 --- a/content/rancher/v2.x/en/concepts/load-balancing/_index.md +++ b/content/rancher/v2.x/en/concepts/load-balancing/_index.md @@ -50,3 +50,22 @@ Other layer-7 load balancers, such as the Google Load Balancer or Nginx Ingress 2. Ask Rancher to generate an xip.io host name for your ingress rule. Rancher will take one of your exposed IPs, say a.b.c.d, and generate a host name ..a.b.c.d.xip.io. The benefit of using xip.io is that you obtain a working entrypoint URL immediately after you create the ingress rule. Setting up your own domain name, on the other hand, requires you to configure DNS servers and wait for DNS to propagate. + +## Related Links + +### External Load Balancers + +#### External Links + +- [Create an External Load Balancer](https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/) + +#### Tutorials + +- [High Availability Installation with External Load Balancer (HTTPS/Layer 7)]({{< baseurl >}}/rancher/v2.x/en/installation/ha-server-install-external-lb) +- [High Availability Installation with External Load Balancer (TCP/Layer 4)]({{< baseurl >}}/rancher/v2.x/en/installation/ha-server-install) +- [Single Node Installation with External Load Balancer]({{< baseurl >}}/rancher/v2.x/en/installation/single-node-install-external-lb) + +### Ingress Controller + +- [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/#what-is-ingress) + diff --git a/content/rancher/v2.x/en/concepts/logging/_index.md b/content/rancher/v2.x/en/concepts/logging/_index.md deleted file mode 100644 index 47a2b80bb2d..00000000000 --- a/content/rancher/v2.x/en/concepts/logging/_index.md +++ /dev/null @@ -1,5 +0,0 @@ ---- -title: Logging -weight: 2325 -draft: true ---- diff --git a/content/rancher/v2.x/en/concepts/projects/_index.md b/content/rancher/v2.x/en/concepts/projects/_index.md index 7451e4babc7..d4704f3bfb0 100644 --- a/content/rancher/v2.x/en/concepts/projects/_index.md +++ b/content/rancher/v2.x/en/concepts/projects/_index.md @@ -3,7 +3,7 @@ title: Projects weight: 2150 --- -_Projects_ are a new concept introduced by Rancher. They are not a native Kubernetes construct. A project captures a set of policies for a set of namespaces. A user can be assigned a specific role in a project. A role can be owner, member, read-only, or [custom]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/roles/#adding-a-custom-role). Policies include Kubernetes Role-Based Access Control (RBAC) policies and pod security policies. Rancher 2.0 also implements a canned network policy that isolates containers in different projects. Future versions of Rancher will implement more flexible network policies. +_Projects_ are a new concept introduced by Rancher. They are not a native Kubernetes construct. A project captures a set of policies for a set of namespaces. A user can be assigned a specific role in a project. A role can be owner, member, read-only, or [custom]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/creating-roles/#adding-a-custom-role). Policies include Kubernetes Role-Based Access Control (RBAC) policies and pod security policies. Rancher 2.0 also implements a canned network policy that isolates containers in different projects. Future versions of Rancher will implement more flexible network policies. ### Authorization @@ -21,3 +21,7 @@ Rancher extends Kubernetes to allow the application of [Pod Security Policies](h Kubernetes resources belong to specific namespaces. Rancher 2.0 relies on namespaces to isolate resources among users and apps. When the user deploys an app from the catalog, for example, he can choose to deploy that app into its own namespace, so that resource names in one app will not conflict with resource names in another. Namespaces must be globally unique. It is often difficult for users to pick unique namespace names. Rancher therefore encourages the pattern where users work with projects, and the system generates unique namespace names automatically. For more information, see the [Kubernetes Namespaces Documentation](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/). + +## Related Links + +- [Project Tutorials]({{< baseurl >}}/rancher/v2.x/en/tasks/projects) diff --git a/content/rancher/v2.x/en/concepts/resources/_index.md b/content/rancher/v2.x/en/concepts/resources/_index.md index d33cb1443f6..70411d7e264 100644 --- a/content/rancher/v2.x/en/concepts/resources/_index.md +++ b/content/rancher/v2.x/en/concepts/resources/_index.md @@ -10,7 +10,7 @@ Within the context of a Rancher project or namespace, _resources_ are files and - [Secrets](#secrets) - [Registries](#registries) -Rancher extends the application of the Kubernetes namespace resources listed above to [projects](../projects), which are Rancher-specific constructs. In the hierarchy of Rancher objects, projects contain namespaces. Therefore, any resources available within a project are available for all namespaces within that project. +Rancher extends the application of the Kubernetes namespace resources listed above to [projects]({{< baseurl >}}/rancher/v2.x/en/concepts/projects/), which are Rancher-specific constructs. In the hierarchy of Rancher objects, projects contain namespaces. Therefore, any resources available within a project are available for all namespaces within that project. Within Kubernetes, certificates, registries, and secrets are all considered [secrets](https://kubernetes.io/docs/concepts/configuration/secret/). Therefore, within a single project or namespace, these resources must have unique names to avoid conflicts. Although secrets are primarily used to carry sensitive information, they have other uses as well. Read on below. @@ -37,4 +37,11 @@ When configuring a workload, you'll be able to choose which secrets to include. Registries are secrets containing credentials used to authenticate with [private registries](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/). Deployments use these secrets to authenticate with a private registry and then pull a Docker image hosted on it. ->**Note:** Currently, credentials are pulled automatically only if the workload is created in the Rancher UI and not kubectl. \ No newline at end of file +>**Note:** Currently, credentials are pulled automatically only if the workload is created in the Rancher UI and not kubectl. + +## Related Links + +- [Adding SSL Certificates]({{< baseurl >}}/rancher/v2.x/en/tasks/projects/add-ssl-certificates) +- [Adding ConfigMaps]({{< baseurl >}}/rancher/v2.x/en/tasks/projects/add-configmaps) +- [Adding Secrets]({{< baseurl >}}/rancher/v2.x/en/tasks/projects/add-a-secret) +- [Adding Registries]({{< baseurl >}}/rancher/v2.x/en/tasks/projects/add-registries) diff --git a/content/rancher/v2.x/en/concepts/service-discovery/_index.md b/content/rancher/v2.x/en/concepts/service-discovery/_index.md index d850867a4db..b3dff86b4b8 100644 --- a/content/rancher/v2.x/en/concepts/service-discovery/_index.md +++ b/content/rancher/v2.x/en/concepts/service-discovery/_index.md @@ -3,3 +3,14 @@ title: Service Discovery weight: 2200 draft: true --- + +## Related Links + +### Tutorials + +- [Adding a DNS Record]({{< baseurl >}}/rancher/v2.x/en/tasks/workloads/add-a-dns-record) + +### External Links + +- [Services](https://kubernetes.io/docs/concepts/services-networking/service/) +- [Adding entries to Pod /etc/hosts with HostAliases](https://kubernetes.io/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases/) diff --git a/content/rancher/v2.x/en/concepts/volumes-and-storage/_index.md b/content/rancher/v2.x/en/concepts/volumes-and-storage/_index.md index 0efca368988..a7cb44d3c05 100644 --- a/content/rancher/v2.x/en/concepts/volumes-and-storage/_index.md +++ b/content/rancher/v2.x/en/concepts/volumes-and-storage/_index.md @@ -6,7 +6,7 @@ There are two ways to create volumes on Kubernetes: Persistent Volumes (PVs) and ## Persistent Volumes -_Persistent Volumes_ are pre-provisioned storage volumes that you can bind to specific pods later. For example, in Amazon EC2, you might want to create a number of Elastic Block Store (EBS) volumes before you start running your application. Each pre-provisioned EBS volume corresponds to a Kubernetes persistent volume. When the application starts, it creates Persistent Volume Claims (PVCs) that bind to persistent volumes. A PVC corresponds to a Docker volume. Each PVC binds to one PV that includes the minimimum resources that the PVC requires. The following figure illustrates the relationship between pods, PVCs, PVs, and the underlying cloud storage. +_Persistent Volumes_ are pre-provisioned storage volumes that you can bind to specific pods later. For example, in Amazon EC2, you might want to create a number of Elastic Block Store (EBS) volumes before you start running your application. Each pre-provisioned EBS volume corresponds to a Kubernetes persistent volume. When the application starts, it creates Persistent Volume Claims (PVCs) that bind to persistent volumes. A PVC corresponds to a Docker volume. Each PVC binds to one PV that includes the minimum resources that the PVC requires. The following figure illustrates the relationship between pods, PVCs, PVs, and the underlying cloud storage. ![Persistent Volumes]({{< baseurl >}}/img/rancher/persistent-volume.png) @@ -14,8 +14,46 @@ Rancher allows you to create PVs at cluster level and bind them to PVCs later. V ## Storage Classes -Storage classes allow you to create PVCs dynamically without having to create PVs first. For example, an EBS Storage Class will dynamically create EBS volumes and bind them to PVCs. A storage class is similar to the notion of a “storage driver.” The following figure illustrates how a PVC creation triggers the dynamic provisioning of an underlying EBS volume. +Storage Classes allow you to create PVCs dynamically without having to create PVs first. For example, an Amazon EBS Storage Class will dynamically create EBS volumes and bind them to PVCs. A Storage Class is similar to the notion of a _storage driver_. The following figure illustrates how a PVC creation triggers the dynamic provisioning of an underlying EBS volume. ![Storage Classes]({{< baseurl >}}/img/rancher/storage-classes.png) - +### Storage and Cloud Providers + +Each storage class contains the fields `provisioner`, `parameters`, and `reclaimPolicy`, which are used when a persistent volume that belongs to the class needs to be dynamically provisioned. + +The `provisioner` determines which volume plugin is used to provision the persistent volumes. You can define storage classes for the following provisioners: + +- Amazon EBS Disk +- AzureFile +- AzureDisk +- Ceph RBD +- Gluster Volume +- Google Persistent Disk +- Longhorn +- Openstack Cinder Volume +- Portworx Volume +- Quobyte Volume +- ScaleIO Volume +- StorageOS +- Vmware vSphere Volume + +In addition to customizing each provisioner's options for the storage class, you can also define the volume `reclaimPolicy`. There are two options available: + +- Delete volumes and underlying device when released by workloads. +- Retain the volume for manual cleanup. + +Finally, you can define custom `MountOptions` for the persistent volume created. + +`parameters` are specific to each cloud storage provisioner. For full information about the storage classes provisioner parameters, refer to the official [Kubernetes documentation](https://kubernetes.io/docs/concepts/storage/storage-classes/#parameters). + +## Related Links + +### External Docs + +- [Storage](https://kubernetes.io/docs/concepts/storage/) + +### Tutorials + +- [Adding Storage]({{< baseurl >}}/rancher/v2.x/en/tasks/clusters/adding-storage/provisioning-storage) +- [Adding Persistent Volume Claims]({{< baseurl >}}/rancher/v2.x/en/tasks/workloads/add-persistent-volume-claim) diff --git a/content/rancher/v2.x/en/concepts/workloads/_index.md b/content/rancher/v2.x/en/concepts/workloads/_index.md index dcf7ed4300c..7dfb09147a7 100644 --- a/content/rancher/v2.x/en/concepts/workloads/_index.md +++ b/content/rancher/v2.x/en/concepts/workloads/_index.md @@ -11,7 +11,7 @@ You can build any complex containerized application in Kubernetes using two basi ### Workloads _Workloads_ are objects that set deployment rules for pods. Based on these rules, Kubernetes performs the deployment and updates the workload with the current state of the application. -Workloads lets you define the rules for application scheduling, scaling, and upgrade. +Workloads let you define the rules for application scheduling, scaling, and upgrade. #### Workload Types @@ -27,7 +27,7 @@ Kubernetes divides workloads into different types. The most popular types suppor - [DaemonSets](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) - _Daemonsets_ ensures that every node in the cluster runs a copy of pod. For use cases where where you're collecting logs or monitoring node performance, this daemon-like workload works best. + _Daemonsets_ ensures that every node in the cluster runs a copy of pod. For use cases where you're collecting logs or monitoring node performance, this daemon-like workload works best. - [Jobs](https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/) @@ -60,4 +60,14 @@ There are several types of services available in Rancher. The descriptions below - **LoadBalancer** - >Exposes the service externally using a cloud provider’s load balancer. `NodePort` and `ClusterIP` services, to which the external load balancer will route, are automatically created. \ No newline at end of file + >Exposes the service externally using a cloud provider’s load balancer. `NodePort` and `ClusterIP` services, to which the external load balancer will route, are automatically created. + +## Related Links + +### External Links + +- [Services](https://kubernetes.io/docs/concepts/services-networking/service/) + +### Tutorials + +- [Workloads]({{< baseurl >}}/rancher/v2.x/en/tasks/workloads/) diff --git a/content/rancher/v2.x/en/faq/contributing/_index.md b/content/rancher/v2.x/en/contributing/_index.md similarity index 98% rename from content/rancher/v2.x/en/faq/contributing/_index.md rename to content/rancher/v2.x/en/contributing/_index.md index cec832053ca..4bbae3d1f3d 100644 --- a/content/rancher/v2.x/en/faq/contributing/_index.md +++ b/content/rancher/v2.x/en/contributing/_index.md @@ -1,6 +1,8 @@ --- - title: Contributing to Rancher - weight: 5001 +title: Contributing to Rancher +weight: 9000 +aliases: + - /rancher/v2.x/en/faq/contributing/ --- ### Repositories diff --git a/content/rancher/v2.x/en/faq/_index.md b/content/rancher/v2.x/en/faq/_index.md index 4a4b0bd6cbf..457f7c1a8ae 100644 --- a/content/rancher/v2.x/en/faq/_index.md +++ b/content/rancher/v2.x/en/faq/_index.md @@ -1,12 +1,14 @@ --- title: FAQ -weight: 5000 +weight: 8000 aliases: - /rancher/v2.x/en/about/ --- This FAQ is a work in progress designed to answers the questions our users most frequently ask about Rancher v2.0. +See [Technical FAQ]({{< baseurl >}}/rancher/v2.x/en/faq/technical/), for frequently asked technical questions. + ### Kubernetes #### What does it mean when you say Rancher v2.0 is built on Kubernetes? @@ -15,7 +17,7 @@ Rancher v2.0 is a complete container management platform built on 100% on Kubern #### Do you plan to implement upstream Kubernetes, or continue to work on your own fork? -We're still going to provide our distribution when you select the default option of having us create your Kubernetes cluster, but it will be very close to upstream. +We're still going to provide our distribution when you select the default option of having us create your Kubernetes cluster, but it will be very close to upstream. #### Does this release mean that we need to re-train our support staff in Kubernetes? diff --git a/content/rancher/v2.x/en/faq/technical/_index.md b/content/rancher/v2.x/en/faq/technical/_index.md index e7f3a65e9c7..3df6cd1abfc 100644 --- a/content/rancher/v2.x/en/faq/technical/_index.md +++ b/content/rancher/v2.x/en/faq/technical/_index.md @@ -1,9 +1,9 @@ --- title: Technical - weight: 5000 + weight: 8005 --- -#### How can I reset the admin password? +### How can I reset the admin password? Single node install: ``` @@ -20,7 +20,7 @@ New password for default admin user (user-xxxxx): ``` -#### How can I enable debug logging? +### How can I enable debug logging? * Single node install * Enable @@ -54,28 +54,28 @@ OK ``` -#### My ClusterIP does not respond to ping +### My ClusterIP does not respond to ping ClusterIP is a virtual IP, which will not respond to ping. Best way to test if the ClusterIP is configured correctly, is by using `curl` to access the IP and port to see if it responds. -#### Where can I manage Node Templates? +### Where can I manage Node Templates? Node Templates can be accessed by opening your account menu (top right) and selecting `Node Templates`. -#### Why is my Layer-4 Load Balancer in `Pending` state? +### Why is my Layer-4 Load Balancer in `Pending` state? The Layer-4 Load Balancer is created as `type: LoadBalancer`. In Kubernetes, this needs a cloud provider or controller that can satisfy these requests, otherwise these will be in `Pending` state forever. More information can be found on [Cloud Providers]({{< baseurl >}}/rancher/v2.x/en/concepts/clusters/cloud-providers/) or [Create External Load Balancer](https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/) -#### Where is the state of Rancher stored? +### Where is the state of Rancher stored? - Single node install: in the embedded etcd of the `rancher/rancher` container, located at `/var/lib/rancher`. - High Availability install: in the etcd of the RKE cluster created to run Rancher. -#### How are the supported Docker versions determined? +### How are the supported Docker versions determined? We follow the validated Docker versions for upstream Kubernetes releases. The validated versions can be found under [External Dependencies](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.10.md#external-dependencies) in the Kubernetes release CHANGELOG.md. -#### How can I access nodes created by Rancher? +### How can I access nodes created by Rancher? SSH keys to access the nodes created by Rancher can be downloaded via the **Nodes** view. Choose the node which you want to access and click on the vertical ellipsis button at the end of the row, and choose **Download Keys** as shown in the picture below. @@ -86,3 +86,10 @@ Unzip the downloaded zip file, and use the file `id_rsa` to connect to you host. ``` $ ssh -i id_rsa user@ip_of_node ``` + +### How can I automate task X in Rancher? + +The UI consists of static files, and works based on responses of the API. That means every action/task that you can execute in the UI, can be automated via the API. There are 2 ways to do this: + +* Visit `https://your_rancher_ip/v3` and browse the API options. +* Capture the API calls when using the UI (Most commonly used for this is [Chrome Developer Tools](https://developers.google.com/web/tools/chrome-devtools/#network) but you can use anything you like) diff --git a/content/rancher/v2.x/en/installation/ha-server-install-helm/create-nodes-and-load-balancer/nlb/_index.md b/content/rancher/v2.x/en/installation/ha-server-install-helm/create-nodes-and-load-balancer/nlb/_index.md index f6c38ac9398..ac7a95e5462 100644 --- a/content/rancher/v2.x/en/installation/ha-server-install-helm/create-nodes-and-load-balancer/nlb/_index.md +++ b/content/rancher/v2.x/en/installation/ha-server-install-helm/create-nodes-and-load-balancer/nlb/_index.md @@ -21,7 +21,7 @@ Configuring an Amazon NLB is a multistage process. We've broken it down into mul ## Create Target Groups -Your first NLB configuration step is to create two target groups. Technically, only port 443 is needed to access Rancher, but its convenient to add a listener for port 80 which will be redirected to port 443 automatically. The NGINX controller on the nodes will make sure that port 80 gets redirected to port 443. +Your first NLB configuration step is to create two target groups. Technically, only port 443 is needed to access Rancher, but its convenient to add a listener for port 80 which will be redirected to port 443 automatically. The NGINX ingress controller on the nodes will make sure that port 80 gets redirected to port 443. Log into the [Amazon AWS Console](https://console.aws.amazon.com/ec2/) to get started, make sure to select the **Region** where your EC2 instances (Linux nodes) are created. diff --git a/content/rancher/v2.x/en/installation/ha-server-install-helm/rke-all-in-one-install/ha-server-install-external-lb/_index.md b/content/rancher/v2.x/en/installation/ha-server-install-helm/rke-all-in-one-install/ha-server-install-external-lb/_index.md index b48e1dca8ee..ac38f375965 100644 --- a/content/rancher/v2.x/en/installation/ha-server-install-helm/rke-all-in-one-install/ha-server-install-external-lb/_index.md +++ b/content/rancher/v2.x/en/installation/ha-server-install-helm/rke-all-in-one-install/ha-server-install-external-lb/_index.md @@ -7,7 +7,7 @@ aliases: This set of instructions creates a new Kubernetes cluster that's dedicated to running Rancher in a high-availability (HA) configuration. This procedure walks you through setting up a 3-node cluster using the Rancher Kubernetes Engine (RKE). The cluster's sole purpose is running pods for Rancher. The setup is based on: - Layer 7 Loadbalancer with SSL termination (HTTPS) -- NGINX Ingress controller (HTTP) +- [NGINX Ingress controller (HTTP)](https://kubernetes.github.io/ingress-nginx/) ![Rancher HA]({{< baseurl >}}/img/rancher/ha/rancher2ha-l7.svg) @@ -66,15 +66,15 @@ Before you install Rancher, confirm you meet the host requirements. Provision 3 ### Requirements -#### Operating System +#### Operating System {{< requirements_os >}} -#### Hardware +#### Hardware {{< requirements_hardware >}} -#### Software +#### Software {{< requirements_software >}} @@ -189,18 +189,22 @@ Once you have the `rancher-cluster.yml` config file template, edit the nodes sec 2. Update the `nodes` section with the information of your [Linux hosts](#provision-linux-hosts). - For each node in your cluster, update the following placeholders: `IP_ADDRESS_X` and `USER`. + For each node in your cluster, update the following placeholders: `IP_ADDRESS_X` and `USER`. The specified user should be able to access the Docket socket, you can test this by logging in with the specified user and run `docker ps`. + + >**Note:** + > When using RHEL/CentOS, the SSH user can't be root due to https://bugzilla.redhat.com/show_bug.cgi?id=1527565. See [Operating System Requirements]({{< baseurl >}}/rke/v0.1.x/en/installation/os#redhat-enterprise-linux-rhel-centos) for RHEL/CentOS specific requirements. + ``` nodes: + # The IP address or hostname of the node - address: IP_ADDRESS_1 - # THE IP ADDRESS OR HOSTNAME OF THE NODE + # User that can login to the node and has access to the Docker socket (i.e. can execute `docker ps` on the node) + # When using RHEL/CentOS, this can't be root due to https://bugzilla.redhat.com/show_bug.cgi?id=1527565 user: USER - # USER WITH ADMIN ACCESS. USUALLY `root` role: [controlplane,etcd,worker] + # Path the SSH key that can be used to access to node with the specified user ssh_key_path: ~/.ssh/id_rsa - # PATH TO SSH KEY THAT AUTHENTICATES ON YOUR WORKSTATION - # USUALLY THE VALUE ABOVE - address: IP_ADDRESS_2 user: USER role: [controlplane,etcd,worker] diff --git a/content/rancher/v2.x/en/installation/ha-server-install-helm/rke-all-in-one-install/ha-server-install-external-lb/nginx/_index.md b/content/rancher/v2.x/en/installation/ha-server-install-helm/rke-all-in-one-install/ha-server-install-external-lb/nginx/_index.md index 02e01d3960c..3b748b01559 100644 --- a/content/rancher/v2.x/en/installation/ha-server-install-helm/rke-all-in-one-install/ha-server-install-external-lb/nginx/_index.md +++ b/content/rancher/v2.x/en/installation/ha-server-install-helm/rke-all-in-one-install/ha-server-install-external-lb/nginx/_index.md @@ -14,6 +14,8 @@ For help installing NGINX, refer to their [install documentation](https://www.ng After installing NGINX, you need to create the NGINX config file, `/etc/nginx/conf.d/rancher.conf`, with the IP addresses for your Linux nodes, chosen FQDN and location of the certificate file and certificate key file. +>**Note:** The example configuration below does not include all available Nginx options and may not be suitable for your production environment. For full configuration documentation, see [NGINX Load Balancing - HTTP Load Balancer](https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/). + 1. Copy and paste the code sample below into your favorite text editor. Save it as `/etc/nginx/conf.d/rancher.conf`. **Example NGINX config:** @@ -23,18 +25,18 @@ After installing NGINX, you need to create the NGINX config file, `/etc/nginx/co server IP_NODE_2:80; server IP_NODE_3:80; } - + map $http_upgrade $connection_upgrade { default Upgrade; '' close; } - + server { listen 443 ssl http2; server_name FQDN; ssl_certificate /certs/fullchain.pem; ssl_certificate_key /certs/privkey.pem; - + location / { proxy_set_header Host $host; proxy_set_header X-Forwarded-Proto $scheme; @@ -48,7 +50,7 @@ After installing NGINX, you need to create the NGINX config file, `/etc/nginx/co proxy_read_timeout 900s; } } - + server { listen 80; server_name FQDN; @@ -61,6 +63,8 @@ After installing NGINX, you need to create the NGINX config file, `/etc/nginx/co 4. In `/etc/nginx/conf.d/rancher.conf`, replace `/certs/fullchain.pem` with the path to your certificate. If there are intermediates required for you certificate, they should be included in this file. 5. In `/etc/nginx/conf.d/rancher.conf`, replace `/certs/privkey.pem` with the path to your certificate key. + + ## Run NGINX * Reload or restart NGINX diff --git a/content/rancher/v2.x/en/installation/ha-server-install-helm/rke-all-in-one-install/ha-server-install/_index.md b/content/rancher/v2.x/en/installation/ha-server-install-helm/rke-all-in-one-install/ha-server-install/_index.md index 188cfc6f909..eeda7f30c98 100644 --- a/content/rancher/v2.x/en/installation/ha-server-install-helm/rke-all-in-one-install/ha-server-install/_index.md +++ b/content/rancher/v2.x/en/installation/ha-server-install-helm/rke-all-in-one-install/ha-server-install/_index.md @@ -7,7 +7,7 @@ aliases: This set of instructions creates a new Kubernetes cluster that's dedicated to running Rancher in a high-availability (HA) configuration. This procedure walks you through setting up a 3-node cluster using the Rancher Kubernetes Engine (RKE). The cluster's sole purpose is running pods for Rancher. The setup is based on: - Layer 4 load balancer (TCP) -- NGINX ingress controller with SSL termination (HTTPS) +- [NGINX ingress controller with SSL termination (HTTPS)](https://kubernetes.github.io/ingress-nginx/) ![Rancher HA]({{< baseurl >}}/img/rancher/ha/rancher2ha.svg) @@ -98,9 +98,9 @@ We will be using NGINX as our Layer 4 Load Balancer (TCP). NGINX will forward al ### A. Install NGINX -Start by installing NGINX on your load balancer host. NGINX has packages available for all known operating systems. +Start by installing NGINX on your load balancer host. NGINX has packages available for all known operating systems. For help installing NGINX, refer to their [install documentation](https://www.nginx.com/resources/wiki/start/topics/tutorials/install/). -For help installing NGINX, refer to their [install documentation](https://www.nginx.com/resources/wiki/start/topics/tutorials/install/). +The `stream` module is required, which is present when using the official NGINX packages. Please refer to your OS documentation how to install and enable the NGINX `stream` module on your operating system. ### B. Create NGINX Configuration @@ -110,6 +110,8 @@ After installing NGINX, you need to update the NGINX config file, `nginx.conf`, 2. From `nginx.conf`, replace `IP_NODE_1`, `IP_NODE_2`, and `IP_NODE_3` with the IPs of your [Linux hosts](#1-provision-linux-hosts). + >**Note:** This Nginx configuration is only an example and may not suit your environment. For complete documentation, see [NGINX Load Balancing - TCP and UDP Load Balancer](https://docs.nginx.com/nginx/admin-guide/load-balancer/tcp-udp-load-balancer/). + **Example NGINX config:** ``` worker_processes 4; @@ -196,7 +198,7 @@ RKE is a fast, versatile Kubernetes installer that you can use to install Kubern 2. Make the RKE binary that you just downloaded executable. Open Terminal, change directory to the location of the RKE binary, and then run one of the commands below. >**Using Windows?** - >The file is already an executable. Skip to [Download Config File Template](#5-download-config-file-template). + >The file is already an executable. Skip to [Download Config File Template](#5-download-rke-config-file-template). ``` # MacOS @@ -238,18 +240,22 @@ Once you have the `rancher-cluster.yml` config file template, edit the nodes sec 2. Update the `nodes` section with the information of your [Linux hosts](#provision-linux-hosts). - For each node in your cluster, update the following placeholders: `IP_ADDRESS_X` and `USER`. + For each node in your cluster, update the following placeholders: `IP_ADDRESS_X` and `USER`. The specified user should be able to access the Docket socket, you can test this by logging in with the specified user and run `docker ps`. + + >**Note:** + > When using RHEL/CentOS, the SSH user can't be root due to https://bugzilla.redhat.com/show_bug.cgi?id=1527565. See [Operating System Requirements]({{< baseurl >}}/rke/v0.1.x/en/installation/os#redhat-enterprise-linux-rhel-centos) for RHEL/CentOS specific requirements. + ``` nodes: + # The IP address or hostname of the node - address: IP_ADDRESS_1 - # THE IP ADDRESS OR HOSTNAME OF THE NODE + # User that can login to the node and has access to the Docker socket (i.e. can execute `docker ps` on the node) + # When using RHEL/CentOS, this can't be root due to https://bugzilla.redhat.com/show_bug.cgi?id=1527565 user: USER - # USER WITH ADMIN ACCESS. USUALLY `root` role: [controlplane,etcd,worker] + # Path the SSH key that can be used to access to node with the specified user ssh_key_path: ~/.ssh/id_rsa - # PATH TO SSH KEY THAT AUTHENTICATES ON YOUR WORKSTATION - # USUALLY THE VALUE ABOVE - address: IP_ADDRESS_2 user: USER role: [controlplane,etcd,worker] @@ -389,7 +395,7 @@ Save the `.yml` file and close it. ## 9. Back Up Your RKE Config File -After you close your `.yml` file, back it up to a secure location. You can use this file again when it's time to upgrade Rancher. +After you close your `.yml` file, back it up to a secure location. You can use this file again when it's time to upgrade Rancher. ## 10. Run RKE @@ -427,7 +433,7 @@ During installation, RKE automatically generates a config file named `kube_confi 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/restorations/ha-restoration). +- Create a backup of your Rancher server cluster: [High Availability Back Up and Restoration]({{< baseurl >}}/rancher/v2.x/en/installation/backups/restorations/ha-restoration). - Create a Kubernetes cluster: [Creating a Cluster]({{ }}/rancher/v2.x/en/tasks/clusters/creating-a-cluster/).
diff --git a/content/rancher/v2.x/en/installation/ha-server-install-helm/rke-all-in-one-install/troubleshooting-ha/generic-troubleshooting/_index.md b/content/rancher/v2.x/en/installation/ha-server-install-helm/rke-all-in-one-install/troubleshooting-ha/generic-troubleshooting/_index.md index 5790d6a0c23..41ead2d7934 100644 --- a/content/rancher/v2.x/en/installation/ha-server-install-helm/rke-all-in-one-install/troubleshooting-ha/generic-troubleshooting/_index.md +++ b/content/rancher/v2.x/en/installation/ha-server-install-helm/rke-all-in-one-install/troubleshooting-ha/generic-troubleshooting/_index.md @@ -7,11 +7,11 @@ aliases: Below are steps that you can follow to determine what is wrong in your cluster. -* Double check if all the required ports are opened in your (host) firewall +### Double check if all the required ports are opened in your (host) firewall Double check if all the [required ports]({{< baseurl >}}/rancher/v2.x/en/installation/references/) are opened in your (host) firewall. -* All nodes should be present and in **Ready** state +### All nodes should be present and in **Ready** state To check, run the command: @@ -21,7 +21,7 @@ kubectl --kubeconfig kube_config_rancher-cluster.yml get nodes If a node is not shown in this output or a node is not in **Ready** state, you can check the logging of the `kubelet` container. Login to the node and run `docker logs kubelet`. -* All pods/jobs should be in **Running**/**Completed** state +### All pods/jobs should be in **Running**/**Completed** state To check, run the command: @@ -31,13 +31,13 @@ kubectl --kubeconfig kube_config_rancher-cluster.yml get pods --all-namespaces If a pod is not in **Running** state, you can dig into the root cause by running: -

Describe pod

+#### Describe pod ``` kubectl --kubeconfig kube_config_rancher-cluster.yml describe pod POD_NAME -n NAMESPACE ``` -

Pod container logs

+#### Pod container logs ``` kubectl --kubeconfig kube_config_rancher-cluster.yml logs POD_NAME -n NAMESPACE @@ -45,19 +45,27 @@ kubectl --kubeconfig kube_config_rancher-cluster.yml logs POD_NAME -n NAMESPACE If a job is not in **Completed** state, you can dig into the root cause by running: -

Describe job

+#### Describe job ``` kubectl --kubeconfig kube_config_rancher-cluster.yml describe job JOB_NAME -n NAMESPACE ``` -

Logs from the containers of pods of the job

+#### Logs from the containers of pods of the job ``` kubectl --kubeconfig kube_config_rancher-cluster.yml logs -l job-name=JOB_NAME -n NAMESPACE ``` -* List all Kubernetes cluster events +### Check ingress + +Ingress should have the correct `HOSTS` (showing the configured FQDN) and `ADDRESS` (address(es) it will be routed to). + +``` +kubectl --kubeconfig kube_config_rancher-cluster.yml get ingress --all-namespaces +``` + +### List all Kubernetes cluster events Kubernetes cluster events are stored, and can be retrieved by running: @@ -65,19 +73,19 @@ Kubernetes cluster events are stored, and can be retrieved by running: kubectl --kubeconfig kube_config_rancher-cluster.yml get events --all-namespaces ``` -* Check Rancher container logging +### Check Rancher container logging ``` kubectl --kubeconfig kube_config_rancher-cluster.yml logs -l app=cattle -n cattle-system ``` -* Check NGINX ingress controller logging +### Check NGINX ingress controller logging ``` kubectl --kubeconfig kube_config_rancher-cluster.yml logs -l app=ingress-nginx -n ingress-nginx ``` -* Check if overlay network is functioning correctly +### Check if overlay network is functioning correctly The pod can be scheduled to any of the hosts you used for your cluster, but that means that the NGINX ingress controller needs to be able to route the request from `NODE_1` to `NODE_2`. This happens over the overlay network. If the overlay network is not functioning, you will experience intermittent TCP/HTTP connection failures due to the NGINX ingress controller not being able to route to the pod. diff --git a/content/rancher/v2.x/en/installation/single-node-install/_index.md b/content/rancher/v2.x/en/installation/single-node-install/_index.md index feefc33e4b8..0afffbf944c 100644 --- a/content/rancher/v2.x/en/installation/single-node-install/_index.md +++ b/content/rancher/v2.x/en/installation/single-node-install/_index.md @@ -59,10 +59,10 @@ For security purposes, SSL (Secure Sockets Layer) is required when using Rancher Choose from the following options: -- [Option A—Default Self-Signed Certificate](#option-adefault-self-signed-certificate) -- [Option B—Bring Your Own Certificate: Self-Signed](#option-bbring-your-own-certificate--self-signed) -- [Option C—Bring Your Own Certificate: Signed by Recognized CA](#option-cbring-your-own-certificate--signed-by-recognized-ca) -- [Option D-Let's Encrypt Certificate](#option-d-lets-encrypt-certificate) +- [Option A—Default Self-Signed Certificate](#option-a-default-self-signed-certificate) +- [Option B—Bring Your Own Certificate: Self-Signed](#option-b-bring-your-own-certificate-self-signed) +- [Option C—Bring Your Own Certificate: Signed by Recognized CA](#option-c-bring-your-own-certificate-signed-by-recognized-ca) +- [Option D—Let's Encrypt Certificate](#option-d-let-s-encrypt-certificate) ### Option A—Default Self-Signed Certificate @@ -133,7 +133,7 @@ By default, Rancher automatically generates self-signed certificates for itself 2. Select **Settings** > **cacerts**. 3. Choose `Edit` and remove the contents. Then click `Save`. -### Option D-Let's Encrypt Certificate +### Option D—Let's Encrypt Certificate Rancher supports Let's Encrypt certificates. Let's Encrypt uses an `http-01 challenge` to verify that you have control over your domain. You can confirm that you control the domain by pointing the hostname that you want to use for Rancher access (for example, `rancher.mydomain.com`) to the IP of the machine it is running on. You can bind the hostname to the IP address by creating an A record in DNS. diff --git a/content/rancher/v2.x/en/installation/single-node-install/advanced-install-options/single-node-install-external-lb/_index.md b/content/rancher/v2.x/en/installation/single-node-install/advanced-install-options/single-node-install-external-lb/_index.md index cdd34be43a5..f9fa3fe4830 100644 --- a/content/rancher/v2.x/en/installation/single-node-install/advanced-install-options/single-node-install-external-lb/_index.md +++ b/content/rancher/v2.x/en/installation/single-node-install/advanced-install-options/single-node-install-external-lb/_index.md @@ -133,6 +133,8 @@ The load balancer or proxy has to be configured to support the following: This Nginx configuration is tested on Nginx version 1.13 (mainline) and 1.14 (stable). + >**Note:** This Nginx configuration is only an example and may not suit your environment. For complete documentation, see [NGINX Load Balancing - TCP and UDP Load Balancer](https://docs.nginx.com/nginx/admin-guide/load-balancer/tcp-udp-load-balancer/). + ``` upstream rancher { server rancher-server:80; diff --git a/content/rancher/v2.x/en/overview/architecture/_index.md b/content/rancher/v2.x/en/overview/architecture/_index.md index c449c034b36..ec69826b483 100644 --- a/content/rancher/v2.x/en/overview/architecture/_index.md +++ b/content/rancher/v2.x/en/overview/architecture/_index.md @@ -7,7 +7,7 @@ This section explains how Rancher interacts with the two fundamental technologie ## Docker -Docker is the container packaging and runtime standard. Developers build container images from Dockerfiles and distribute container images from Docker registries. [Docker Hub](http://hub.docker.com) is the most popular public registry. Many organizations also setup private Docker registries. Docker is primarily used to manage containers on individual nodes. +Docker is the container packaging and runtime standard. Developers build container images from Dockerfiles and distribute container images from Docker registries. [Docker Hub](https://hub.docker.com) is the most popular public registry. Many organizations also setup private Docker registries. Docker is primarily used to manage containers on individual nodes. >**Note:** Although Rancher 1.6 supported Docker Swarm clustering technology, it is no longer supported in Rancher 2.0 due to the success of Kubernetes. diff --git a/content/rancher/v2.x/en/tasks/clusters/_index.md b/content/rancher/v2.x/en/tasks/clusters/_index.md deleted file mode 100644 index 9cf00a32ccd..00000000000 --- a/content/rancher/v2.x/en/tasks/clusters/_index.md +++ /dev/null @@ -1,4 +0,0 @@ ---- -title: Clusters -weight: 3175 ---- diff --git a/content/rancher/v2.x/en/tasks/clusters/adding-a-pod-security-policy/_index.md b/content/rancher/v2.x/en/tasks/clusters/adding-a-pod-security-policy/_index.md index 2d2ee026279..6bbd2ef58c9 100644 --- a/content/rancher/v2.x/en/tasks/clusters/adding-a-pod-security-policy/_index.md +++ b/content/rancher/v2.x/en/tasks/clusters/adding-a-pod-security-policy/_index.md @@ -14,14 +14,14 @@ You can add a Pod Security Policy (PSPs hereafter) in the following contexts: > **Note:** We recommend adding PSPs during cluster and project creation instead of adding it to an existing one. -For more information about PSPs, refer to [Pod Security Policy]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/pod-security-policies). +For more information about PSPs, refer to [Pod Security Policy]({{< baseurl >}}/rancher/v2.x/en/admin-settings/pod-security-policies). ## Cluster Creation: Adding a Default Pod Security Policy When you create a new cluster, you can configure it to apply a PSP immediately. As you create the cluster, use the **Cluster Options** to enable a PSP. The PSP assigned to the cluster will be the default PSP for projects within the cluster. >**Prerequisite:** ->Create a Pod Security Policy within Rancher. Before you can assign a default PSP to a new cluster, you must have a PSP available for assignment. For instruction, see [Creating Pod Security Policies]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/pod-security-policies/). +>Create a Pod Security Policy within Rancher. Before you can assign a default PSP to a new cluster, you must have a PSP available for assignment. For instruction, see [Creating Pod Security Policies]({{< baseurl >}}/rancher/v2.x/en/admin-settings/pod-security-policies/). >**Note:** >For security purposes, we recommend assigning a PSP as you create your clusters. @@ -36,7 +36,7 @@ For detailed instruction about assigning a PSP to a new cluster, see [Creating a If you don't apply a PSP as you create your cluster, you can always add one later. >**Prerequisite:** ->Create a Pod Security Policy within Rancher. Before you can assign a default PSP to an existing cluster, you must have a PSP available for assignment. For instruction, see [Creating Pod Security Policies]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/pod-security-policies/). +>Create a Pod Security Policy within Rancher. Before you can assign a default PSP to an existing cluster, you must have a PSP available for assignment. For instruction, see [Creating Pod Security Policies]({{< baseurl >}}/rancher/v2.x/en/admin-settings/pod-security-policies/). 1. From the **Global** view, find the cluster that you want to apply your PSP to. Select **Vertical Ellipsis (...) > Edit** for the cluster you want to enable PSPs for. @@ -66,7 +66,7 @@ When you create a new project, you can assign a PSP directly to the project. Ass >**Prerequisites:** > -> - Create a Pod Security Policy within Rancher. Before you can assign a default PSP to a new project, you must have a PSP available for assignment. For instruction, see [Creating Pod Security Policies]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/pod-security-policies/). +> - Create a Pod Security Policy within Rancher. Before you can assign a default PSP to a new project, you must have a PSP available for assignment. For instruction, see [Creating Pod Security Policies]({{< baseurl >}}/rancher/v2.x/en/admin-settings/pod-security-policies/). > - Assign a default Pod Security Policy to the project's cluster. You can't assign a PSP to a project until one is already applied to the cluster. For more information, see [Existing Cluster: Adding a Pod Security Policy](#existing-cluster--adding-a-pod-security-policy). As you create the project, make a selection from the **Pod Security Policy** drop-down to assign a PSP. @@ -79,7 +79,7 @@ You can always assign a PSP to an existing project if you didn't assign one duri >**Prerequisites:** > -> - Create a Pod Security Policy within Rancher. Before you can assign a default PSP to an existing project, you must have a PSP available for assignment. For instruction, see [Creating Pod Security Policies]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/pod-security-policies/). +> - Create a Pod Security Policy within Rancher. Before you can assign a default PSP to an existing project, you must have a PSP available for assignment. For instruction, see [Creating Pod Security Policies]({{< baseurl >}}/rancher/v2.x/en/admin-settings/pod-security-policies/). > - Assign a default Pod Security Policy to the project's cluster. You can't assign a PSP to a project until one is already applied to the cluster. For more information, see [Existing Cluster: Adding a Pod Security Policy](#existing-cluster--adding-a-pod-security-policy). 1. From the **Global** view, find the cluster containing the project you want to apply a PSP to. diff --git a/content/rancher/v2.x/en/tasks/clusters/adding-alerts/_index.md b/content/rancher/v2.x/en/tasks/clusters/adding-alerts/_index.md deleted file mode 100644 index e1c7ee48f55..00000000000 --- a/content/rancher/v2.x/en/tasks/clusters/adding-alerts/_index.md +++ /dev/null @@ -1,9 +0,0 @@ ---- -title: Adding and Managing Alerts -weight: 3575 -draft: true ---- - -## Adding Alerts - -## Managing Alerts \ No newline at end of file diff --git a/content/rancher/v2.x/en/tasks/clusters/adding-managing-cluster-members/_index.md b/content/rancher/v2.x/en/tasks/clusters/adding-managing-cluster-members/_index.md index 40f1ab912a5..57d7b0a8c19 100644 --- a/content/rancher/v2.x/en/tasks/clusters/adding-managing-cluster-members/_index.md +++ b/content/rancher/v2.x/en/tasks/clusters/adding-managing-cluster-members/_index.md @@ -29,23 +29,23 @@ Following cluster creation, you can add users as cluster members so that they ca If external authentication is configured: - - Rancher returns users from your [external authentication]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/authentication/) source as you type. + - Rancher returns users from your [external authentication]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/) source as you type. >**Using AD but can't find your users?** - >There may be an issue with your search attribute configuration. See [Configuring Active Directory Authentication: Step 5]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/authentication/active-directory/). + >There may be an issue with your search attribute configuration. See [Configuring Active Directory Authentication: Step 5]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/configuring-ad/). - A drop-down allows you to add groups instead of individual users. The drop-down only lists groups that you, the logged in user, are part of. - >**Note:** If you are logged in as a local user, external users do not display in your search results. For more information, see [External Authentication Configuration and Principal Users]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/authentication/#external-authentication-configuration-and-principal-users). + >**Note:** If you are logged in as a local user, external users do not display in your search results. For more information, see [External Authentication Configuration and Principal Users]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/#external-authentication-configuration-and-principal-users). 4. Assign the user or group **Cluster** roles. - [What are Cluster Roles?]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/users-permissions-roles/#cluster-roles) + [What are Cluster Roles?]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/#cluster-roles) >**Tip:** For Custom Roles, you can modify the list of individual roles available for assignment. > - > - To add roles to the list, [Add a Custom Role]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/roles/#adding-a-custom-role). - > - To remove roles from the list, [Lock/Unlock Roles]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/roles/#locking-unlocking-roles). + > - To add roles to the list, [Add a Custom Role]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/creating-roles/#adding-a-custom-role). + > - To remove roles from the list, [Lock/Unlock Roles]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/creating-roles/#locking-unlocking-roles). **Result:** The chosen users are added to the cluster. diff --git a/content/rancher/v2.x/en/tasks/clusters/adding-notifiers/_index.md b/content/rancher/v2.x/en/tasks/clusters/adding-notifiers/_index.md deleted file mode 100644 index 6422255c33f..00000000000 --- a/content/rancher/v2.x/en/tasks/clusters/adding-notifiers/_index.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -title: Adding and Managing Notifiers -weight: 3550 -draft: true ---- - - -## Adding Notifiers - -## Managing Notifiers - diff --git a/content/rancher/v2.x/en/tasks/clusters/adding-storage/_index.md b/content/rancher/v2.x/en/tasks/clusters/adding-storage/_index.md index 267608767f3..f3c86dbaedf 100644 --- a/content/rancher/v2.x/en/tasks/clusters/adding-storage/_index.md +++ b/content/rancher/v2.x/en/tasks/clusters/adding-storage/_index.md @@ -1,14 +1,90 @@ --- title: Adding Storage weight: 3500 -draft: true --- -Coming Soon -## Adding Persistent Volumes +>**Prerequisites:** +> +>- Working with storage requires the `Manage Volumes` [role]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/#project-role-reference). +>- You must have a storage medium provisioned. For more information, see [Provisioning Storage](provisioning-storage). -Coming Soon +## Adding a Persistent Volume + +Your containers can store data on themselves, but if a container fails, that data is lost. To solve this issue, Kubernetes offers _persistent volumes_, which are external storage disks or file systems that your containers can access. If a container crashes, its replacement container can access the data in a persistent volume without any data loss. + +Persistent volumes can either be a disk or file system that you host on premise, or they can be hosted by a vendor, such as Amazon EBS or Azure Disk. + +>**Prerequisite:** +> +>- Create a storage volume either on premise or in the cloud, using one of the vendor services listed in [Types of Persistent Volumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#types-of-persistent-volumes). +>- Gather metadata about your storage volume after you create it. You'll need to enter this information into Rancher. + +1. From the **Global** view, open the cluster running the containers that you want to add persistent volume storage to. + +1. From the main menu, select **Storage > Persistent Volumes**. + +1. Click **Add Volume**. + +1. Enter a **Name** for the persistent volume. + +1. Select the **Volume Plugin** for the disk type or service that you're using. + + >**Note:** If the cluster you are adding storage for is a cloud service that also offers cloud storage, you must enable the `cloud provider` option for the cluster, and you must use the service's plug-in to use cloud storage. For example, if you have a Amazon EC2 cluster and you want to use cloud storage for it: + + 1. You must enable the `cloud provider` option for the EC2 cluster. + 2. You must use the `Amazon EBS Disk` volume plugin. + +1. Enter the **Capacity** of your volume in gigabytes. + +1. Complete the **Plugin Configuration** form. Each plugin type requires information specific to the vendor of disk type. For help regarding each plugin's form and the information that's required, refer to the plug-in's vendor documentation. + +1. **Optional:** Complete the **Customize** form. This form features: + + - [Access Modes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes): + + This options sets how many nodes can access the volume, along with the node read/write permissions. The [Kubernetes Documentation](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes) includes a table that lists which access modes are supported by the plugins available. + + - [Mount Options](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#mount-options): + + Each volume plugin allows you to specify additional command line options during the mounting process. You can enter these options in the **Mount Option** fields. Consult each plugin's vendor documentation for the mount options available. + + - **Assign to Storage Class:** + + If you later want to automatically provision persistent volumes identical to the volume that you've specified here, assign it a storage class. Later, when you create a workload, you can assign it a persistent volume claim that references the storage class, which will provision a persistent volume identical to the volume you've specified here. + + >**Note:** You must [add a storage class](#adding-storage-classes) before you can assign it to a persistent volume. + +1. Click **Save**. + +**Result:** Your new persistent volume is created. ## Adding Storage Classes -Coming Soon +_Storage Classes_ allow you to dynamically provision persistent volumes on demand. Think of storage classes as storage profiles that are created automatically upon a request (which is known as a _persistent volume claim_). + +1. From the **Global** view, open the cluster for which you want to dynamically provision persistent storage volumes. + +1. From the main menu, select `Storage > Storage Classes`. Click `Add Class`. + +1. Enter a `Name` for your storage class. + +1. From the `Provisioner` drop-down, select the service that you want to use to dynamically provision storage volumes. + + >**Note:** If the cluster you are adding a storage class for is a cloud service that also offers cloud storage, you must enable the `cloud provider` option for the cluster, and you must use the service's plug-in to use cloud storage. For example, if you have a Amazon EC2 cluster and you want to use cloud storage for it: + + 1. You must enable the `cloud provider` option for the EC2 cluster. + 2. You must use the `Amazon EBS Disk` provisioner. + + +1. From the `Parameters` section, fill out the information required for the service to dynamically provision storage volumes. Each provisioner requires different information to dynamically provision storage volumes. Consult the service's documentation for help on how to obtain this information. + +1. Click `Save`. + +## What's Next? + +Mount Persistent Volumes to workloads so that your applications can store their data. You can mount a either a manually created Persistent Volumes or a dynamically created Persistent Volume, which is created from a a Storage Class. + +You can mount Persistent Volumes in one of two contexts: + +- During deployment of a workload (recommended if possible). For more information, see [Deploying Workloads](../../workloads/deploy-workloads/). +- Following workload creation. For more information, see [Adding Persistent Volume Claims](../../workloads/add-persistent-volume-claim/). \ No newline at end of file diff --git a/content/rancher/v2.x/en/tasks/clusters/adding-storage/provisioning-storage/_index.md b/content/rancher/v2.x/en/tasks/clusters/adding-storage/provisioning-storage/_index.md new file mode 100644 index 00000000000..e29fc390d43 --- /dev/null +++ b/content/rancher/v2.x/en/tasks/clusters/adding-storage/provisioning-storage/_index.md @@ -0,0 +1,10 @@ +--- +title: Provisioning Storage +weight: 3500 +--- + +Rancher supports persistent storage with a variety of volume plugins. However, before you use any of these plugins to bind persistent storage to your workloads, you have to configure the storage itself, whether its a cloud-based solution from a service-provider or an on-prem solution that you manage yourself. + +For your convenience, Rancher offers documentation on how to configure some of the popular storage methods: + +- [NFS Share](nfs) diff --git a/content/rancher/v2.x/en/tasks/clusters/adding-storage/provisioning-storage/nfs/_index.md b/content/rancher/v2.x/en/tasks/clusters/adding-storage/provisioning-storage/nfs/_index.md new file mode 100644 index 00000000000..ec4a49d4cf1 --- /dev/null +++ b/content/rancher/v2.x/en/tasks/clusters/adding-storage/provisioning-storage/nfs/_index.md @@ -0,0 +1,66 @@ +--- +title: Provisioning NFS Storage +weight: 3500 +--- + +Before you can use the NFS storage volume plug-in with Rancher deployments, you need to provision an NFS server. + +>**Note:** +> +>- If you already have an NFS share, you don't need to provision a new NFS server to use the NFS volume plugin within Rancher. Instead, skip the rest of this procedure and complete [adding storage]({{< baseurl >}}/rancher/v2.x/en/tasks/clusters/adding-storage/). +> +>- This procedure demonstrates how to setup an NFS server using Ubuntu, although you should be able to use these instructions for other Linux distros (e.g. Debian, RHEL, Arch Linux, etc.). For official instruction on how to create an NFS server using another Linux distro, consult the distro's documentation. + +>**Recommended:** To simplify the process of managing firewall rules, use NFSv4. + +1. Using a remote Terminal connection, log into the Ubuntu server that you intend to use for NFS storage. + +1. Enter the following command: + + ``` + sudo apt-get install nfs-kernel-server + ``` + +1. Enter the command below, which sets the directory used for storage, along with user access rights. Modify the command if you'd like to keep storage at a different directory. + + ``` + mkdir -p /nfs && chown nobody:nogroup /nfs + ``` + - The `-p /nfs` parameter creates a directory named `nfs` at root. + - The `chown nobody:nogroup /nfs` parameter allows all access to the storage directory. + +1. Create an NFS exports table. This table sets the directory paths on your NFS server that are exposed to the nodes that will use the server for storage. + + 1. Open `/etc/exports` using your text editor of choice. + 1. Add the path of the `/nfs` folder that you created in step 3, along with the IP addresses of your cluster nodes. Add an entry for each IP address in your cluster. Follow each address and its accompanying parameters with a single space that is a delimiter. + + ``` + /nfs (rw,sync,no_subtree_check) (rw,sync,no_subtree_check) (rw,sync,no_subtree_check) + ``` + + **Tip:** You can replace the IP addresses with a subnet. For example: `10.212.50.12/24` + + 1. Update the NFS table by entering the following command: + + ``` + exportfs -ra + ``` + +1. Open the ports used by NFS. + + 1. To find out what ports NFS is using, enter the following command: + + ``` + rpcinfo -p | grep nfs + ``` + 2. [Open the ports](https://help.ubuntu.com/lts/serverguide/firewall.html.en) that the previous command outputs. For example, the following command opens port 2049: + + ``` + sudo ufw allow 2049 + ``` + +**Result:** Your NFS server is configured to be used for storage with your Rancher nodes. + +## What's Next? + +Within Rancher, add the NFS server as a [storage volume]({{< baseurl >}}/rancher/v2.x/en/tasks/clusters/adding-storage/#adding-a-persistent-volume) and/or [storage class]({{< baseurl >}}/rancher/v2.x/en/tasks/clusters/adding-storage/#adding-storage-classes). After adding the server, you can use it for storage for your deployments. diff --git a/content/rancher/v2.x/en/tasks/clusters/adding-users-to-a-cluster/_index.md b/content/rancher/v2.x/en/tasks/clusters/adding-users-to-a-cluster/_index.md deleted file mode 100644 index 6ca749c3ab2..00000000000 --- a/content/rancher/v2.x/en/tasks/clusters/adding-users-to-a-cluster/_index.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -title: Adding Users to a Cluster -weight: 3425 -draft: true ---- -Coming Soon diff --git a/content/rancher/v2.x/en/tasks/clusters/creating-a-cluster/_index.md b/content/rancher/v2.x/en/tasks/clusters/creating-a-cluster/_index.md deleted file mode 100644 index ce3e45300f4..00000000000 --- a/content/rancher/v2.x/en/tasks/clusters/creating-a-cluster/_index.md +++ /dev/null @@ -1,5 +0,0 @@ ---- -title: Creating a Cluster -weight: 3200 ---- -Rancher includes a variety of options for getting a Kubernetes cluster up and running using a single Linux node as a temple. Choose from one of the options below to get started! diff --git a/content/rancher/v2.x/en/tasks/clusters/creating-a-cluster/cluster-options-edit-as-yml/_index.md b/content/rancher/v2.x/en/tasks/clusters/creating-a-cluster/cluster-options-edit-as-yml/_index.md deleted file mode 100644 index f8dd77e6c14..00000000000 --- a/content/rancher/v2.x/en/tasks/clusters/creating-a-cluster/cluster-options-edit-as-yml/_index.md +++ /dev/null @@ -1,5 +0,0 @@ ---- -title: Cluster Options—Edit as YAML -weight: 5000 -draft: true ---- \ No newline at end of file diff --git a/content/rancher/v2.x/en/tasks/clusters/enabling-cluster-logging/_index.md b/content/rancher/v2.x/en/tasks/clusters/enabling-cluster-logging/_index.md deleted file mode 100644 index 197a6b08d33..00000000000 --- a/content/rancher/v2.x/en/tasks/clusters/enabling-cluster-logging/_index.md +++ /dev/null @@ -1,9 +0,0 @@ ---- -title: Enabling and Managing Cluster Logging -weight: 3600 -draft: true ---- - -## Enabling Cluster Logging - -## Managing Cluster Logging \ No newline at end of file diff --git a/content/rancher/v2.x/en/tasks/clusters/enabling-pipelines-for-projects/_index.md b/content/rancher/v2.x/en/tasks/clusters/enabling-pipelines-for-projects/_index.md deleted file mode 100644 index 068c9cab4e8..00000000000 --- a/content/rancher/v2.x/en/tasks/clusters/enabling-pipelines-for-projects/_index.md +++ /dev/null @@ -1,9 +0,0 @@ ---- -title: Enabling and Managing Pipelines for Projects -weight: 3625 -draft: true ---- - -## Enabling Pipelines for Projects - -## Managing Pipelines for Projects \ No newline at end of file diff --git a/content/rancher/v2.x/en/tasks/global-configuration/_index.md b/content/rancher/v2.x/en/tasks/global-configuration/_index.md deleted file mode 100644 index ac174f34f8f..00000000000 --- a/content/rancher/v2.x/en/tasks/global-configuration/_index.md +++ /dev/null @@ -1,5 +0,0 @@ ---- -title: Global Configuration -weight: 3025 ---- -This section contains step-by-step instruction for configuring Rancher to work in your environment. diff --git a/content/rancher/v2.x/en/tasks/global-configuration/authentication/_index.md b/content/rancher/v2.x/en/tasks/global-configuration/authentication/_index.md deleted file mode 100644 index 2d27198d556..00000000000 --- a/content/rancher/v2.x/en/tasks/global-configuration/authentication/_index.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: Authentication -weight: 50 ---- -You have three options for user authentication in Rancher: - -- [Active Directory]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/authentication/active-directory/) - - Enterprises can use Active Directory (AD) for authentication, allowing users to sign in using their corporate credentials. - -- [GitHub]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/authentication/github/) - - Open source projects or organizations that use GitHub for source control may prefer that users sign in using their GitHub accounts. - - - - -- [Azure AD]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/authentication/azure-ad/) - - If you have an instance of Active Directory (AD) hosted in Azure, you can configure Rancher to allow your users to log in using their AD accounts. Configuration of Azure AD external authentication requires you to make configurations in both Azure and Rancher. - -- [Local Authentication]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/authentication/local-authentication/) - - If you don't want to use external authentication, you can always add users directly to Rancher. We recommend using external authentication over local authentication. diff --git a/content/rancher/v2.x/en/tasks/global-configuration/authentication/active-directory/_index.md b/content/rancher/v2.x/en/tasks/global-configuration/authentication/active-directory/_index.md deleted file mode 100644 index 9105b6fb27a..00000000000 --- a/content/rancher/v2.x/en/tasks/global-configuration/authentication/active-directory/_index.md +++ /dev/null @@ -1,54 +0,0 @@ ---- -title: Configuring Active Directory Authentication -weight: 3075 ---- - -In environments using Microsoft Active Directory (AD), you can configure Rancher to allow sign on using AD credentials. - ->**Prerequisites:** -> ->- Create a service account in Active Directory with `read-only` access. {{< product >}} uses this account to verify group membership when a user makes a request using an API key. ->- Read [External Authentication Configuration and Principal Users]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/authentication/#external-authentication-configuration-and-principal-users). - -1. Sign into Rancher using a local user assigned `administrator` global permissions (i.e., the _local principal_). - -2. From the **Global** view, select **Security > Authentication** from the main menu. - -3. Select **Active Directory**. - -4. Complete the **Configure an Active Directory server** form. - - You may need to log in to your domain controller to find the information requested in the form. - - >**Using TLS?** - >Make sure you have an LDAP certificate installed. -
-
- >**User Search Base vs. Group Search Base** - > - >When configuring AD authentication, you must enter a search base for your users. This search base allows Rancher to search for users that are in your Active Directory. -
-
- > **Note:** This field is only for search bases and not for search filters. - > - >- If your users and groups are in the search base, complete only the User Search Base. - >- If your groups are in a different search base, you can optionally complete the Group Search Base. This field is dedicated to searching groups, but is not required. - -5. If your Active Directory deviates from the standard AD schema, complete the **Customize Schema** form to match it. Otherwise, skip this step. - - >**Search Attribute** As of Rancher v2.0.1, the Search Attribute field defaults with three specific values by default: `sAMAccountName|sn|givenName`. After AD is configured, when a user enters text to add users or groups, Rancher automatically queries the AD server and attempts to match fields by sAMAccountName, last name, or first name. Rancher specifically searches for users/groups that begin with the text entered in the search field. - > - >The default field value `sAMAccountName|sn|givenName`, but you can configure this field to a subset of these fields. The pipe (`|`) between the fields separates these fields. - > - > * `sAMAccountName`: Username - > * `sn`: Last Name - > * `givenName`: First Name - > - > With this search attribute, Rancher creates search filters for users and groups, but you *cannot* add your own search filters in this field. - -6. Enter your AD username and password in **Test and enable authentication** to confirm that Rancher is configured to use AD authentication. - -**Result:** - -- Active Directory authentication is configured. -- You are signed into Rancher with your Active Directory account (i.e., the _external principal_). diff --git a/content/rancher/v2.x/en/tasks/global-configuration/catalog/_index.md b/content/rancher/v2.x/en/tasks/global-configuration/catalog/_index.md deleted file mode 100644 index 79421f86fb8..00000000000 --- a/content/rancher/v2.x/en/tasks/global-configuration/catalog/_index.md +++ /dev/null @@ -1,10 +0,0 @@ ---- -title: Catalogs and Charts -weight: 3026 ---- - -This section includes step-by-step instruction on how to configure default and custom catalogs. - -- [Enabling Default Catalogs]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/catalog/enabling-default-catalogs) -- [Adding Custom Catalogs]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/catalog/adding-custom-catalogs) -- [Customizing Charts]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/catalog/customizing-charts) \ No newline at end of file diff --git a/content/rancher/v2.x/en/tasks/global-configuration/password-reset/_index.md b/content/rancher/v2.x/en/tasks/global-configuration/password-reset/_index.md deleted file mode 100644 index 4e466369828..00000000000 --- a/content/rancher/v2.x/en/tasks/global-configuration/password-reset/_index.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -title: Password Reset -weight: 75 -draft: true ---- - -Content here. \ No newline at end of file diff --git a/content/rancher/v2.x/en/tasks/projects/add-a-secret/_index.md b/content/rancher/v2.x/en/tasks/projects/add-a-secret/_index.md index 6058b75964d..c95c8ccb660 100644 --- a/content/rancher/v2.x/en/tasks/projects/add-a-secret/_index.md +++ b/content/rancher/v2.x/en/tasks/projects/add-a-secret/_index.md @@ -1,6 +1,34 @@ --- title: Adding a Secret weight: -draft: true --- -Coming Soon + +[Secrets](https://kubernetes.io/docs/concepts/configuration/secret/#overview-of-secrets) store sensitive data like passwords, tokens, or keys. They may contain one or more key value pairs. + +When creating a secret, you can make it available for any deployment within a project, or you can limit it to a single namespace. + +1. From the **Global** view, select the project containing the namespace(s) where you want to add a secret. + +1. From the main menu, select **Resources > Secrets**. Click **Add Secret**. + +1. Enter a **Name** for the secret. + + >**Note:** Kubernetes classifies secrets, certificates, ConfigMaps, and registries all as [secrets](https://kubernetes.io/docs/concepts/configuration/secret/), and no two secrets in a project or namespace can have duplicate names. Therefore, to prevent conflicts, your secret must have a unique name among all secrets within your workspace. + +1. Select a **Scope** for the secret. + +1. From **Secret Values**, click **Add Secret Value** to add a key value pair. Add as many values as you need. + + >**Tip:** You can add multiple key value pairs to the secret by copying and pasting. + > + > ![Bulk Key Value Pair Copy/Paste]({{< baseurl >}}/img/rancher/bulk-key-values.gif) + +1. Click **Save**. + +**Result:** Your secret is added to the project or namespace, depending on the scope you chose. You can view the secret in the Rancher UI from the **Resources > Secrets** view. + +## What's Next? + +Now that you have a secret added to the project or namespace, you can add it to a workload that you deploy. + +For more information on adding secret to a workload, see [Deploying Workloads]({{< baseurl >}}/rancher/v2.x/en/tasks/workloads/deploy-workloads/). diff --git a/content/rancher/v2.x/en/tasks/projects/add-configmaps/_index.md b/content/rancher/v2.x/en/tasks/projects/add-configmaps/_index.md new file mode 100644 index 00000000000..87476fd20c7 --- /dev/null +++ b/content/rancher/v2.x/en/tasks/projects/add-configmaps/_index.md @@ -0,0 +1,39 @@ +--- +title: Adding ConfigMaps +weight: +--- + +ConfigMaps store general configuration information for an application, such as configuration files, command-line arguments, environment variables, etc. ConfigMaps accept key value pairs in common string formats, like config files or JSON blobs. Add ConfigMaps to your Rancher workspaces so that you can add them to your workloads later. For more information on ConfigMaps, see the official [Kubernetes Documentation: Using ConfigMap](https://kubernetes-v1-4.github.io/docs/user-guide/configmap/). + +>**Note:** ConfigMaps can only be applied to namespaces and not projects. + +1. From the **Global** view, select the project containing the namespace that you want to add a ConfigMap to. + +1. From the main menu, select **Resources > Config Maps**. Click **Add Config Map**. + +1. Enter a **Name** for the Config Map. + + >**Note:** Kubernetes classifies ConfigMaps as [secrets](https://kubernetes.io/docs/concepts/configuration/secret/), and no two secrets in a project or namespace can have duplicate names. Therefore, to prevent conflicts, your ConfigMaps must have a unique name among the other certificates, ConfigMaps, registries, and secrets within your workspace. + +1. Select the **Namespace** you want to add Config Map to. You can also add a new namespace on the fly by clicking **Add to a new namespace**. + +1. From **Config Map Values**, click **Add Config Map Value** to add a key value pair to your ConfigMap. Add as many values as you need. + +1. Click **Save**. + + >**Note:** Don't use ConfigMaps to store sensitive data [use a secret](../add-a-secret). + > + >**Tip:** You can add multiple key value pairs to the ConfigMap by copying and pasting. + > + > ![Bulk Key Value Pair Copy/Paste]({{< baseurl >}}/img/rancher/bulk-key-values.gif) + +**Result:** Your ConfigMap is added to the namespace. You can view it in the Rancher UI from the **Resources > Config Maps** view. + +## What's Next? + +Now that you have a ConfigMap added to a namespace, you can add it to a workload that you deploy from the namespace of origin. You can use the ConfigMap to specify information for you application to consume, such as: + +- Application environment variables. +- Specifying parameters for a Volume mounted to the workload. + +For more information on adding ConfigMaps to a workload, see [Deploying Workloads]({{< baseurl >}}/rancher/v2.x/en/tasks/workloads/deploy-workloads/). \ No newline at end of file diff --git a/content/rancher/v2.x/en/tasks/projects/add-configuration-maps/_index.md b/content/rancher/v2.x/en/tasks/projects/add-configuration-maps/_index.md deleted file mode 100644 index 846fb199303..00000000000 --- a/content/rancher/v2.x/en/tasks/projects/add-configuration-maps/_index.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -title: Adding Configuration Maps -weight: -draft: true ---- -Coming Soon diff --git a/content/rancher/v2.x/en/tasks/projects/add-project-members/_index.md b/content/rancher/v2.x/en/tasks/projects/add-project-members/_index.md index 0a6400287cd..04046b75e43 100644 --- a/content/rancher/v2.x/en/tasks/projects/add-project-members/_index.md +++ b/content/rancher/v2.x/en/tasks/projects/add-project-members/_index.md @@ -1,11 +1,11 @@ --- title: Adding Project Members -weight: +weight: --- If you want to provide a user with access and permissions to _specific_ projects and resources within a cluster, assign the user a project membership. ->**Tip:** Want to provide a user with access to _all_ projects within a cluster? See [Adding Cluster Members]({{< baseurl >}}/rancher/v2.x/en/tasks/clusters/adding-managing-cluster-members) instead. +>**Tip:** Want to provide a user with access to _all_ projects within a cluster? See [Adding Cluster Members]({{< baseurl >}}/rancher/v2.x/en/clusters/adding-users) instead. There are two contexts where you can add project members: @@ -28,21 +28,21 @@ Following project creation, you can add users as project members so that they ca 3. Search for the user or group that you want to add to the project. If external authentication is configured: - + - Rancher returns users from your external authentication source as you type. - + - A drop-down allows you to add groups instead of individual users. The dropdown only lists groups that you, the logged in user, are included in. >**Note:** If you are logged in as a local user, external users do not display in your search results. 1. Assign the user or group **Project** roles. - [What are Project Roles?]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/users-permissions-roles/#cluster-roles) + [What are Project Roles?]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/#cluster-roles) >**Tip:** For Custom Roles, you can modify the list of individual roles available for assignment. > - > - To add roles to the list, [Add a Custom Role]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/roles/#adding-a-custom-role). - > - To remove roles from the list, [Lock/Unlock Roles]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/roles/#locking-unlocking-roles). + > - To add roles to the list, [Add a Custom Role]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/creating-roles/#adding-a-custom-role). + > - To remove roles from the list, [Lock/Unlock Roles]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/creating-roles/#locking-unlocking-roles). **Result:** The chosen users are added to the project. diff --git a/content/rancher/v2.x/en/tasks/projects/add-registries/_index.md b/content/rancher/v2.x/en/tasks/projects/add-registries/_index.md new file mode 100644 index 00000000000..ab5a9f56bde --- /dev/null +++ b/content/rancher/v2.x/en/tasks/projects/add-registries/_index.md @@ -0,0 +1,32 @@ +--- +title: Adding Registries +weight: +--- + +Registries are secrets containing credentials used to authenticate with [private registries](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/). Deployments use these secrets to authenticate with a private registry and then pull a Docker image hosted on it. + +>**Prerequisites:** You must have a [private registry](https://docs.docker.com/registry/deploying/) configured. + +>**Note:** Currently, credentials are pulled automatically only if the workload is created in the Rancher UI and not kubectl. + +1. From the **Global** view, select the project containing the namespace(s) where you want to add a registry. + +1. From the main menu, select **Resources > Registries**. Click **Add Registry**. + +1. Enter a **Name** for the registry. + + >**Note:** Kubernetes classifies secrets, certificates, ConfigMaps, and registries all as [secrets](https://kubernetes.io/docs/concepts/configuration/secret/), and no two secrets in a project or namespace can have duplicate names. Therefore, to prevent conflicts, your registry must have a unique name among all secrets within your workspace. + +1. Select a **Scope** for the registry. + +1. Select the website that hosts your private registry. Then enter credentials that authenticate with the registry. + +1. Click **Save**. + +**Result:** Your secret is added to the project or namespace, depending on the scope you chose. You can view the secret in the Rancher UI from the **Resources > Registries** view. + +## What's Next? + +Now that you have a registry added to the project or namespace, you can add it to a workload that's deploying an image from your private registry. + +For more information on adding a registry to a workload, see [Deploying Workloads]({{< baseurl >}}/rancher/v2.x/en/tasks/workloads/deploy-workloads/). diff --git a/content/rancher/v2.x/en/tasks/projects/add-ssl-certificates/_index.md b/content/rancher/v2.x/en/tasks/projects/add-ssl-certificates/_index.md index d5faacae223..a9dfeaac88d 100644 --- a/content/rancher/v2.x/en/tasks/projects/add-ssl-certificates/_index.md +++ b/content/rancher/v2.x/en/tasks/projects/add-ssl-certificates/_index.md @@ -1,6 +1,41 @@ --- title: Adding SSL Certificates weight: -draft: true --- -Coming Soon +When you create an ingress within Rancher/Kubernetes, you must provide it with a TLS private key and certificate, which are used to encrypt and decrypt communications that come through the ingress. You can make certificates available for ingress use by navigating to its project or namespace, and then uploading the certificate. + +Add SSL certificates to either projects, namespaces, or both. A project scoped certificate will be available in all its namespaces. + +>**Prerequisites:** You must have a TLS private key and certificate available to upload. + +1. From the **Global** view, select the project where you want to deploy your ingress. + +1. From the main menu, select **Resources > Certificates**. Click **Add Certificate**. + +1. Enter a **Name** for the certificate. + + >**Note:** Kubernetes classifies SSL certificates as [secrets](https://kubernetes.io/docs/concepts/configuration/secret/), and no two secrets in a project or namespace can have duplicate names. Therefore, to prevent conflicts, your SSL certificate must have a unique name among the other certificates, ConfigMaps, registries, and secrets within your project/workspace. + +1. Select the **Scope** of the certificate. + + - **Available to all namespaces in this project:** The certificate is available for any deployment in any namespaces in the project. + + - **Available to a single namespace:** The certificate is only available for the deployments in one namespace. If you choose this option, select a **Namespace** from the drop-down list or click **Add to a new namespace** to add the certificate to a namespace you create on the fly. + +1. From **Private Key**, either copy and paste your certificate's private key into the text box (include the header and footer), or click **Read from a file** to browse to the private key on your file system. If possible, we recommend using **Read from a file** to reduce likelihood of error. + + Private key files end with an extension of `.key`. + +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`. + +**Result:** Your certificate is added to the project or namespace. You can now add it to deployments. + +- If you added an SSL certificate to the project, the certificate is available for deployments created in any project namespace. +- If you added an SSL certificate to a namespace, the certificate is available only for deployments in that namespace. +- Your certificate is added to the **Resources > Certificates** view. + +## What's Next? + +Now you can add the certificate when launching an ingress within the current project or namespace. For more information, see [Adding Ingress]({{< baseurl >}}/rancher/v2.x/en/tasks/workloads/add-ingress/). diff --git a/content/rancher/v2.x/en/tasks/projects/create-project/_index.md b/content/rancher/v2.x/en/tasks/projects/create-project/_index.md index 64ca590e886..8fb7c996ec6 100644 --- a/content/rancher/v2.x/en/tasks/projects/create-project/_index.md +++ b/content/rancher/v2.x/en/tasks/projects/create-project/_index.md @@ -11,9 +11,9 @@ weight: 1. **Optional:** Select a **Pod Security Policy**. - [What are Pod Security Policies?]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/pod-security-policies) + [What are Pod Security Policies?]({{< baseurl >}}/rancher/v2.x/en/admin-settings/pod-security-policies) - >**Note:** This option is only available if you've already created a Pod Security Policy. For instruction, see [Creating Pod Security Policies]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/pod-security-policies/#creating-pod-security-policies). + >**Note:** This option is only available if you've already created a Pod Security Policy. For instruction, see [Creating Pod Security Policies]({{< baseurl >}}/rancher/v2.x/en/admin-settings/pod-security-policies/#creating-pod-security-policies). 1. **Recommended:** Add project members. @@ -29,9 +29,9 @@ weight: 1. From the **Role** drop-down, choose a role. - [What are Roles?]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/users-permissions-roles/#cluster-and-project-roles) + [What are Roles?]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/#cluster-and-project-roles) - >**Tip:** Choose Custom to create a custom role on the fly: [Custom Project Roles]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/users-permissions-roles/#custom-project-roles). + >**Tip:** Choose Custom to create a custom role on the fly: [Custom Project Roles]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/#custom-project-roles). 1. To add more members, repeat substeps a—c. diff --git a/content/rancher/v2.x/en/tasks/projects/use-private-registries/_index.md b/content/rancher/v2.x/en/tasks/projects/use-private-registries/_index.md deleted file mode 100644 index caa3a46f234..00000000000 --- a/content/rancher/v2.x/en/tasks/projects/use-private-registries/_index.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -title: Using Private Registries -weight: -draft: true ---- -Coming Soon diff --git a/content/rancher/v2.x/en/tasks/workloads/add-a-dns-record/_index.md b/content/rancher/v2.x/en/tasks/workloads/add-a-dns-record/_index.md index 7df660d14d2..aaba2afdc6f 100644 --- a/content/rancher/v2.x/en/tasks/workloads/add-a-dns-record/_index.md +++ b/content/rancher/v2.x/en/tasks/workloads/add-a-dns-record/_index.md @@ -1,6 +1,56 @@ --- title: Adding a DNS Record -weight: -draft: true +weight: 75 --- -Coming Soon + +For every workload created, a complementing Service Discovery entry is created. This Service Discovery entry enables DNS resolution for the workload's pods using the following naming convention: +`..svc.cluster.local`. + +However, you also have the option of creating additional Service Discovery records. You can use these additional records so that a given namespace resolves with one or more external IP addresses, an external hostname, an alias to another DNS record, other workloads, or a set of pods that match a selector that you create. + +1. From the **Global** view, open the project that you want to add a DNS record to. + +1. Select the **Service Discovery** tab. Then click **Add Record**. + +1. Enter a **Name** for the DNS record. This name is used for DNS resolution. + +1. Select a **Namespace** from the drop-down list. Alternatively, you can create a new namespace on the fly by clicking **Add to a new namespace**. + +1. Select one of the **Resolves To** options to route requests to the DNS record. + + 1. **One or more external IP addresses** + + Enter an IP address in the **Target IP Addresses** field. Add more IP addresses by clicking **Add Target IP**. + + 1. **An external hostname** + + Enter a **Target Hostname**. + + 1. **Alias of another DNS record's value** + + Click **Add Target Record** and select another DNS record from the **Value** drop-down. + + 1. **One or more workloads** + + Click **Add Target Workload** and select another workload from the **Value** drop-down. + + 1. **The set of pods which match a selector** + + Enter key value pairs of [label selectors](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors) to create a record for all pods that match your parameters. + +1. Click **Create** + +**Result:** A new DNS record is created. + +- You can view the record by from the project's **Service Discovery** tab. +- When you visit the new DNS name for the new record that you created (`..svc.cluster.local`), it resolves the chosen namespace. + +## Related Links + +### Tutorials + +- [Service Discovery]({{< baseurl >}}/rancher/v2.x/en/concepts/service-discovery) + +### External Links + +- [Adding entries to Pod /etc/hosts with HostAliases](https://kubernetes.io/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases/) diff --git a/content/rancher/v2.x/en/tasks/workloads/add-a-sidecar/_index.md b/content/rancher/v2.x/en/tasks/workloads/add-a-sidecar/_index.md index 19180372b3d..a044732e71f 100644 --- a/content/rancher/v2.x/en/tasks/workloads/add-a-sidecar/_index.md +++ b/content/rancher/v2.x/en/tasks/workloads/add-a-sidecar/_index.md @@ -1,6 +1,35 @@ --- title: Adding a Sidecar -weight: -draft: true +weight: 200 --- -Coming Soon +A _sidecar_ is a container that extends or enhances the main container in a pod. The main container and the sidecar share a pod, and therefore share the same network space and storage. You can add sidecars to existing workloads by using the **Add a Sidecar** option. + +1. From the **Global** view, open the project running the workload you want to add a sidecar to. + +1. Select the **Workloads** tab. + +1. Find the workload that you want to extend. Select **Ellipsis icon (...) > Add a Sidecar**. + +1. Enter a **Name** for the sidecar. + +1. Select a **Sidecar Type**. This option determines if the sidecar container is deployed before or after the main container is deployed. + + - **Standard Container:** + + The sidecar container is deployed after the main container. + + - **Init Container:** + + The sidecar container is deployed before the main container. + +1. From the **Docker Image** field, enter the name of the Docker image that you want to deploy in support of the main container. During deployment, Rancher pulls this image from [Docker Hub](https://hub.docker.com/explore/). Enter the name exactly as it appears on Docker Hub. + +1. Set the remaining options. You can read about them in [Deploying Workloads](../deploy-workloads). + +1. Click **Launch**. + +**Result:** The sidecar is deployed according to your parameters. Following its deployment, you can view the sidecar by selecting **Ellipsis icon (...) > Edit** for the main deployment. + +## Related Links + +- [The Distributed System ToolKit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns/) diff --git a/content/rancher/v2.x/en/tasks/workloads/add-ingress/_index.md b/content/rancher/v2.x/en/tasks/workloads/add-ingress/_index.md index 6471dbddda7..a527ae01887 100644 --- a/content/rancher/v2.x/en/tasks/workloads/add-ingress/_index.md +++ b/content/rancher/v2.x/en/tasks/workloads/add-ingress/_index.md @@ -1,6 +1,79 @@ --- title: Adding Ingress -weight: -draft: true +weight: 50 --- -Coming Soon + +Ingress can be added for workloads to provide load balancing, SSL termination and host/path based routing. + +1. From the **Global** view, open the project that you want to add ingress to. + +1. Select the **Load Balancing** tab. Then click **Add Ingress**. + +1. Enter a **Name** for the ingress. + +1. Select an existing **Namespace** from the drop-down list. Alternatively, you can create a new namespace on the fly by clicking **Add to a new namespace**. + +1. Create ingress forwarding **Rules**. + + - **Automatically generate a xip.io hostname** + + If you choose this option, ingress routes requests to hostname to a DNS name that's automatically generated. Rancher uses [xip.io](http://xip.io/) to automatically generates the DNS name. This option is best used for testing, _not_ production environments. + + >**Note:** To use this option, you must be able to resolve to `xip.io` addresses. + + 1. Add a **Target Backend**. By default, a workload is added to the ingress, but you can add more targets by clicking either **Service** or **Workload**. + + 1. **Optional:** If you want specify a workload or service when a request is sent to a particular hostname path, add a **Path** for the target. For example, if you want requests for `www.mysite.com/contact-us` to be sent to a different service than `www.mysite.com`, enter `/contact-us` in the **Path** field. + + Typically, the first rule that you create does not include a path. + + 1. Select a workload or service from the **Target** drop-down list for each target you've added. + + 1. Enter the **Port** number that each target operates on. + + - **Specify a hostname to use** + + If you use this option, ingress routes requests for a hostname to the service or workload that you specify. + + 1. Enter the hostname that your ingress will handle request forwarding for. For example, `www.mysite.com`. + + 1. Add a **Target Backend**. By default, a workload is added to the ingress, but you can add more targets by clicking either **Service** or **Workload**. + + 1. **Optional:** If you want specify a workload or service when a request is sent to a particular hostname path, add a **Path** for the target. For example, if you want requests for `www.mysite.com/contact-us` to be sent to a different service than `www.mysite.com`, enter `/contact-us` in the **Path** field. + + Typically, the first rule that you create does not include a path. + + 1. Select a workload or service from the **Target** drop-down list for each target you've added. + + 1. Enter the **Port** number that each target operates on. + + + - **Use as the default backend** + + Use this option to set an ingress rule for handling requests that don't match any other ingress rules. For example, use this option to route requests that can't be found to a `404` page. + + >**Note:** If you deployed Rancher using RKE, a default backend for 404s and 202s is already configured. + + 1. Add a **Target Backend**. Click either **Service** or **Workload** to add the target. + + 1. Select a service or workload from the **Target** drop-down list. + +1. **Optional:** click **Add Rule** to create additional ingress rules. For example, after you create ingress rules to direct requests for your hostname, you'll likely want to create a default backend to handle 404s. + +1. If any of your ingress rules handle requests for encrypted ports, add a certificate to encrpyt/decrypt communications. + + >**Note:** You must have an SSL certificate that the ingress can use to encrypt/decrypt communications. For more information see [Adding SSL Certificates](../../projects/add-ssl-certificates/). + + 1. Click **Add Certificate**. + + 1. Select a **Certificate** from the drop-down list. + + 1. Enter the **Host** using encrypted communication. + + 1. To add additional hosts that use the certitificate, 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. + + For a list of annotations available for use, see the [Nginx Ingress Controller Documentation](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/). + +**Result:** Your ingress is added to the project. The ingress begins enforcing your ingress rules. diff --git a/content/rancher/v2.x/en/tasks/workloads/add-persistent-volume-claim/_index.md b/content/rancher/v2.x/en/tasks/workloads/add-persistent-volume-claim/_index.md index 69fd5e3ea66..93ef3081f8b 100644 --- a/content/rancher/v2.x/en/tasks/workloads/add-persistent-volume-claim/_index.md +++ b/content/rancher/v2.x/en/tasks/workloads/add-persistent-volume-claim/_index.md @@ -1,6 +1,42 @@ --- title: Adding a Persistent Volume Claim -weight: -draft: true +weight: 100 --- -Coming Soon + +_Persistent Volume Claims_ (or PVCs) are objects that request storage resources from your cluster. They're similar to a voucher that your deployment can redeem for storage access. When you create a deployment, you should usually attach a PVC so that your application can lay claim to persistent storage. This claim lets your deployment application store its data in an external location, so that if one of the application's containers fails, it can be replaced with a new container and continue accessing its data stored externally, as though an outage never occured. + +- Rancher lets you create as many PVCs within a project as you'd like. +- You can mount PVCs to a deployment as you create it, or later after its running. +- Each Rancher project contains a list of PVCs that you've created, available from the **Volumes** tab. You can reuse these PVCs when creating deployments in the future. + +>**Prerequisite:** +> You must have a pre-provisioned [persistent volume]({{< baseurl >}}/rancher/v2.x/en/tasks/clusters/adding-storage/#adding-a-persistent-volume) available for use, or you must have a [storage class created]({{< baseurl >}}/rancher/v2.x/en/tasks/clusters/adding-storage/#adding-storage-classes) that dynamically creates a volume upon request from the workload. + +1. From the **Global** view, open the project containing a workload that you want to add a PVC to. + +1. From the main menu, make sure that **Workloads** is selected. Then select the **Volumes** tab. Click **Add Volume**. + +1. Enter a **Name** for the volume claim. + +1. Select the **Namespace** of the volume claim. + +1. Select a **Source** option: + + - **To dynamically provision a storage volume for the deployment:** + + 1. Choose **Use a Storage Class to provision a new persistent volume** + + 1. From the **Storage Class** drop-down, choose a pre-created storage class. + + 1. Enter a volume **Capacity**. + + - **To use an existing persistent volume:** + + 1. Choose **Use an existing persistent volume:** + + 1. From the **Persistent Volume** drop-down, choose a pre-created persistent volume. + +7. **Optional:** From **Customize**, select the [Access Modes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes) that you want to use. + +**Result:** Your PVC is created. You can now attach it to any workload in the project. + diff --git a/content/rancher/v2.x/en/tasks/workloads/deploy-workloads/_index.md b/content/rancher/v2.x/en/tasks/workloads/deploy-workloads/_index.md index a090f21e168..dd628ed2a90 100644 --- a/content/rancher/v2.x/en/tasks/workloads/deploy-workloads/_index.md +++ b/content/rancher/v2.x/en/tasks/workloads/deploy-workloads/_index.md @@ -1,6 +1,6 @@ --- title: Deploying Workloads -weight: +weight: 25 --- Deploy a workload to run an application in one or more containers. @@ -22,12 +22,28 @@ Deploy a workload to run an application in one or more containers. 1. Configure the remaining options: - **Environment Variables** + + Use this section to either specify environment variables for your workload to consume on the fly, or to pull them from another source, such as a secret or [ConfigMap]({{< baseurl >}}/rancher/v2.x/en/tasks/projects/add-configmaps/). + - **Node Scheduling** - - **Health Check** - - **Volumes** + - **Health Check** + - **Volumes** + + Use this section to add storage for your workload. You can manually specify the volume that you want to add, use a persistent volume claim to dynamically create a volume for the workload, or read data for a volume to use from a file such as a [ConfigMap]({{< baseurl >}}/rancher/v2.x/en/tasks/projects/add-configmaps/). + - **Scaling/Upgrade Policy** + >**Amazon Note for Volumes:** + > + > To mount an Amazon EBS volume: + > + >- In [Amazon AWS](https://aws.amazon.com/), the nodes must be in the same Availability Zone and possess IAM permissions to attach/unattach volumes. + > + >- The cluster must be using the [AWS cloud provider](https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/#aws) option. For more information on enabling this option see [Creating an Amazon EC2 Cluster]({{< baseurl >}}/rancher/v2.x/en/clusters/rke-clusters/node-pools/ec2/) or [Creating a Custom Cluster]({{< baseurl >}}/rancher/v2.x/en/clusters/custom-clusters/). + + 1. Click **Show Advanced Options** and configure: + - **Command** - **Networking** - **Labels & Annotations** @@ -35,4 +51,4 @@ Deploy a workload to run an application in one or more containers. 1. Click **Launch**. -**Result:** The workload is deployed to the chosen namespace. You can view the workload's status from the project's **Workloads** view. \ No newline at end of file +**Result:** The workload is deployed to the chosen namespace. You can view the workload's status from the project's **Workloads** view. diff --git a/content/rancher/v2.x/en/tasks/workloads/rollback-workloads/_index.md b/content/rancher/v2.x/en/tasks/workloads/rollback-workloads/_index.md index d6ad28ff679..0c83bdb1993 100644 --- a/content/rancher/v2.x/en/tasks/workloads/rollback-workloads/_index.md +++ b/content/rancher/v2.x/en/tasks/workloads/rollback-workloads/_index.md @@ -1,6 +1,6 @@ --- title: Rolling Back Workloads -weight: +weight: 150 --- Sometimes there is a need to rollback to the previous version of the application, either for debugging purposes or because an upgrade did not go as planned. diff --git a/content/rancher/v2.x/en/tasks/workloads/upgrade-workloads/_index.md b/content/rancher/v2.x/en/tasks/workloads/upgrade-workloads/_index.md index 8ca5a79c87b..0a7882d990f 100644 --- a/content/rancher/v2.x/en/tasks/workloads/upgrade-workloads/_index.md +++ b/content/rancher/v2.x/en/tasks/workloads/upgrade-workloads/_index.md @@ -1,6 +1,6 @@ --- title: Upgrading Workloads -weight: +weight: 125 --- When a new version of an application image is released on Docker Hub, you can upgrade any workloads running a previous version of the application to the new one. diff --git a/content/rancher/v2.x/en/tools/_index.md b/content/rancher/v2.x/en/tools/_index.md new file mode 100644 index 00000000000..d30b7101f69 --- /dev/null +++ b/content/rancher/v2.x/en/tools/_index.md @@ -0,0 +1,4 @@ +--- +title: Rancher Tools +weight: 5000 +--- diff --git a/content/rancher/v2.x/en/tools/logging/_index.md b/content/rancher/v2.x/en/tools/logging/_index.md new file mode 100644 index 00000000000..143c56be407 --- /dev/null +++ b/content/rancher/v2.x/en/tools/logging/_index.md @@ -0,0 +1,10 @@ +--- +title: Logging +weight: 5015 +aliases: + - /rancher/v2.x/en/tasks/logging/ +--- + +Rancher has the capability to push out cluster and project logs to an external +log monitoring tool such as Splunk or a Syslog server. This allows you to be +alerted of errors and warnings in your Kubernetes infrastructure. diff --git a/content/rancher/v2.x/en/tools/logging/splunk/_index.md b/content/rancher/v2.x/en/tools/logging/splunk/_index.md new file mode 100755 index 00000000000..e58082ca991 --- /dev/null +++ b/content/rancher/v2.x/en/tools/logging/splunk/_index.md @@ -0,0 +1,102 @@ +--- +title: Splunk +weight: 3725 +aliases: + - /rancher/v2.x/en/tasks/logging/splunk/ +--- + +The following guide will demonstrate how to monitor your container +infrastructure using Splunk. + +## Configure HTTP Event Collector + +The first step is to identify what port Splunk is using for the HTTP Event +collector. Usually the port is either **8088** or **8089**. HEC is used to +send log data from Rancher to Splunk using HTTP or HTTPS. + +Login to Splunk and go to: + +Settings > Data inputs > HTTP Event Collector > **Global Settings** + +![Configure Splunk]({{< baseurl >}}/img/rancher/splunk/splunk1.jpg) + +Make sure to click on **Enabled** for all tokens. By default it is set to +disabled. This will allow Splunk to collect HTTP Event data sent from Rancher. + +Click on **Save** to update the HEC settings. + +## Generate Token + +This step might not be applicable, if you already have a token. Now we will +generate the token that will be used by Rancher to send HTTP Event data. + +- Click Settings > Data inputs > HTTP Event Collector > **New Token** +- Click monitor +- Select HTTP Event Collector +- In the Name field, enter a name for the token (ex. **rancher**) +- Click Next +- Select the indexe(s) desired (history, main, and summary) +- You can also create a new index and add it to the step above +- Click Review +- Confirm that all settings for the token are what you want +- Click Submit to generate the token + +  + +Congratulations you now are ready to feed Splunk with HTTP Event data. You +should see a page like the one below with your generated token. This is the +token that will be used in Rancher to communicate with Splunk. + +![Token Created]({{< baseurl >}}/img/rancher/splunk/splunk2.jpg) + +## Configure Cluster Logging + +In this section we will configure and enable Splunk cluster logging in Rancher. + +- Head on over to local > Tools > **Logging** +- Select Splunk +- Enter the Splunk endpoint using the port specified for **HEC** (ex. http://splunk-server:8088) +- Enter the token generated above (ex. 8da70994-b1b0-4a79-b154-bfaae8f93432) +- Enter the Source, name of the token created earlier (ex. **rancher**) +- You can also enter an index, this is optional (ex. **main**) + +  + +![Configure Rancher Cluster Logging]({{< baseurl >}}/img/rancher/splunk/splunk3.jpg) + +Repeat the same step for Project Logging, if desired. This is not required and is optional. + +## View Logs + +You should now be receiving logging data from your cluster. Head on over to +Splunk to view your logs. + +Click on **Search & Reporting**, you should see **Indexed Events** increasing. +Click on Data Summary and select the Sources tab. + +![View Logs]({{< baseurl >}}/img/rancher/splunk/splunk4.jpg) + +To view the actual logs click on the source that you declared earlier +(ex. rancher -> http:**rancher**) + +![View Logs]({{< baseurl >}}/img/rancher/splunk/splunk5.jpg) + +## Troubleshooting + +You can use curl to see if **HEC** is listening for HTTP event data. + +``` +$ curl http://splunk-server:8088/services/collector/event \ + -H 'Authorization: Splunk 8da70994-b1b0-4a79-b154-bfaae8f93432' \ + -d '{"event": "hello world"}' +``` + +You should see **json** data returning Success code 0. You should be able +to send logging data to HEC. If you received an error, check your configuration +in Splunk & Rancher Cluster Logging. + +## Reference + +For more information on Splunk, you can check out the following reference: + +[Splunk -> HTTP Event Collector](http://docs.splunk.com/Documentation/Splunk/7.0.0/Data/UsetheHTTPEventCollector) diff --git a/content/rancher/v2.x/en/tools/notifiers-and-alerts/_index.md b/content/rancher/v2.x/en/tools/notifiers-and-alerts/_index.md new file mode 100644 index 00000000000..1a71e114dde --- /dev/null +++ b/content/rancher/v2.x/en/tools/notifiers-and-alerts/_index.md @@ -0,0 +1,35 @@ +--- +title: Notifiers and Alerts +weight: 5010 +--- + +Alerts and notifications are built on top of the [Prometheus Alertmanager](https://prometheus.io/docs/alerting/alertmanager/). Leveraging these tools, Rancher is able to provide the first step in notifications for events operators and application owners need to know about. + +## Notifiers + +In Rancher 2.x, a user can configure `Notifiers` for each cluster that can receive alerts for various events. By configuring the notifiers at the cluster level, project owners do not need to know SMTP settings or have access to cloud accounts. At a project level, users can configure alerts and add recipients scoped to the relevant alerts. + +Available Notifiers: + +* Email +* Slack +* PagerDuty +* Webhooks + +## Alerts + +Rancher supports alerting on a cluster level or project level. + +On a cluster level, Rancher can monitor and alert on components that manage your Kubernetes cluster including: + +* System Services +* Resource Events +* Node conditions + +Operators of Kubernetes clusters can get alerts on the health of nodes and other system level components. + +On a project level, Rancher can monitor and alert on status on specific deployments including: + +* Deployment availability +* Workloads +* Pods diff --git a/content/rancher/v2.x/en/tasks/pipelines/_index.md b/content/rancher/v2.x/en/tools/pipelines/_index.md similarity index 85% rename from content/rancher/v2.x/en/tasks/pipelines/_index.md rename to content/rancher/v2.x/en/tools/pipelines/_index.md index 49c9dce509d..0a3bbd79d40 100644 --- a/content/rancher/v2.x/en/tasks/pipelines/_index.md +++ b/content/rancher/v2.x/en/tools/pipelines/_index.md @@ -1,7 +1,24 @@ --- title: Pipelines -weight: 3700 +weight: 5005 +aliases: + - /rancher/v2.x/en/concepts/ci-cd-pipelines/ + - /rancher/v2.x/en/tasks/pipelines/ --- + +Pipelines help you automate the software delivery process. You can integrate Rancher with GitHub to create a pipeline. + +You can set up your pipeline to run a series of stages and steps to test your code and deploy it. + +
+
Pipelines
+
Contain a series of stages and steps. Out-of-the-box, the pipelines feature supports fan out and in capabilities.
+
Stages
+
Executed sequentially. The next stage will not execute until all of the steps within the stage execute.
+
Steps
+
Are executed in parallel within a stage.
+
+ ## Enabling CI Pipelines 1. Select cluster from drop down. diff --git a/content/rancher/v2.x/en/upgrades/ha-server-upgrade/_index.md b/content/rancher/v2.x/en/upgrades/ha-server-upgrade/_index.md index aa513dbeb65..0eeb03fd682 100644 --- a/content/rancher/v2.x/en/upgrades/ha-server-upgrade/_index.md +++ b/content/rancher/v2.x/en/upgrades/ha-server-upgrade/_index.md @@ -19,9 +19,9 @@ To upgrade Rancher 2.x running in a high availability configuration, run an upgr ``` # MacOS - ./rke_darwin-amd64 etcd snapshot-save --name --config kube_config_rancher-cluster.yml + ./rke_darwin-amd64 etcd snapshot-save --name --config rancher-cluster.yml # Linux - ./rke_linux-amd64 etcd snapshot-save --name --config kube_config_rancher-cluster.yml + ./rke_linux-amd64 etcd snapshot-save --name --config rancher-cluster.yml ``` **Result:** RKE takes a snapshot of `etcd` running on each `etcd` node. The file is saved to `/opt/rke/etcd-snapshots`. @@ -39,4 +39,4 @@ kubectl --kubeconfig=kube_config_rancher-cluster.yml set image deployment/cattle **Result:** Your Rancher Servers are upgraded. ->**Upgrade Issues?** You can restore your Rancher Server and data that was running prior to upgrade. For more information, see [Restoring Backups—High Availablity Installs]({{< baseurl >}}/rancher/v2.x/en/upgrades/rollbacks/ha-server-rollbacks). +>**Upgrade Issues?** You can restore your Rancher Server and data that was running prior to upgrade. For more information, see [Rolling Back—High Availability Installs]({{< baseurl >}}/rancher/v2.x/en/backups/rollbacks/ha-server-rollbacks). diff --git a/content/rancher/v2.x/en/tasks/user-settings/_index.md b/content/rancher/v2.x/en/user-settings/_index.md similarity index 73% rename from content/rancher/v2.x/en/tasks/user-settings/_index.md rename to content/rancher/v2.x/en/user-settings/_index.md index 895dd745a79..8ef85cc7c8a 100644 --- a/content/rancher/v2.x/en/tasks/user-settings/_index.md +++ b/content/rancher/v2.x/en/user-settings/_index.md @@ -1,13 +1,15 @@ --- title: User Settings -weight: 3725 +weight: 7000 +aliases: + - /rancher/v2.x/en/tasks/user-settings/ --- Within Rancher, each user has a number of settings associated with their login: personal preferences, API keys, etc. You can configure these settings by choosing from the **User Settings** menu. You can open this menu by clicking your avatar, located within the main menu. The available user settings are: -- [API & Keys]({{< baseurl >}}/rancher/v2.x/en/tasks/user-settings/api-keys/) +- [API & Keys]({{< baseurl >}}/rancher/v2.x/en/user-settings/api-keys/) + + + {{ .Content }} {{ range (.Paginator 5).Pages }} diff --git a/layouts/partials/page-nav.html b/layouts/partials/page-nav.html new file mode 100644 index 00000000000..566e9c70ba3 --- /dev/null +++ b/layouts/partials/page-nav.html @@ -0,0 +1,20 @@ +
+
    + {{ template "page-nav" . }} +
+
+{{ define "page-nav" }} + {{ range .Sections}} +
  • {{ .Title }} + {{if gt (len .Sections) 0}} + +
      + {{ range .Pages }} +
    • {{ .Title }}
      • + {{ end }} + {{ template "page-nav" . }} +
    + {{end}} +
    • + {{ end }} +{{ end }} diff --git a/layouts/shortcodes/accordion.html b/layouts/shortcodes/accordion.html new file mode 100644 index 00000000000..600dbc68d4b --- /dev/null +++ b/layouts/shortcodes/accordion.html @@ -0,0 +1,7 @@ +
    + + +
    + {{ .Inner }} +
    +
    diff --git a/layouts/shortcodes/requirements_ports_rancher.html b/layouts/shortcodes/requirements_ports_rancher.html index eaf601ac3b1..4d4263990f6 100644 --- a/layouts/shortcodes/requirements_ports_rancher.html +++ b/layouts/shortcodes/requirements_ports_rancher.html @@ -1,6 +1,6 @@

    Rancher nodes:
    Nodes running the rancher/rancher container

    -
    Rancher nodes - Inbound rules
    +

    Rancher nodes - Inbound rules

    @@ -21,7 +21,7 @@
    ProtocolRancher agent, Rancher UI/API, kubectl
    -
    Rancher nodes - Outbound rules
    +

    Rancher nodes - Outbound rules

    diff --git a/layouts/shortcodes/requirements_ports_rke.html b/layouts/shortcodes/requirements_ports_rke.html index 8bf136cb8e5..f5b0491a08a 100644 --- a/layouts/shortcodes/requirements_ports_rke.html +++ b/layouts/shortcodes/requirements_ports_rke.html @@ -1,6 +1,6 @@

    etcd nodes:
    Nodes with the role etcd

    -
    etcd nodes - Inbound rules
    +

    etcd nodes - Inbound rules

    Protocol
    @@ -26,6 +26,12 @@ + + + + + + @@ -33,7 +39,7 @@
    Protocol
    • etcd nodes
    • controlplane nodes
    • worker nodes
    		 Canal/Flannel VXLAN overlay networking
    TCP9099
    • etcd node itself (local traffic, not across nodes)
    See Local node traffic    		Canal/Flannel livenessProbe/readinessProbe
    TCP 10250kubelet
    -
    etcd nodes - Outbound rules
    +

    etcd nodes - Outbound rules

    @@ -71,9 +77,15 @@ + + + + + +
    Protocol
    • etcd nodes
    • controlplane nodes
    • worker nodes
    		 Canal/Flannel VXLAN overlay networking
    TCP9099
    • etcd node itself (local traffic, not across nodes)
    See Local node traffic    		Canal/Flannel livenessProbe/readinessProbe

    controlplane nodes:
    Nodes with the role controlplane

    -
    controlplane nodes - Inbound rules
    +

    controlplane nodes - Inbound rules

    @@ -105,12 +117,24 @@ + + + + + + + + + + + + @@ -118,7 +142,7 @@
    Protocol
    • etcd nodes
    • controlplane nodes
    • worker nodes
    		 Canal/Flannel VXLAN overlay networking
    TCP9099
    • controlplane node itself (local traffic, not across nodes)
    See Local node traffic    		Canal/Flannel livenessProbe/readinessProbe
    TCP 10250
    • controlplane nodes
    		 kubelet
    TCP10254
    • controlplane node itself (local traffic, not across nodes)
    See Local node traffic    		Ingress controller livenessProbe/readinessProbe
    TCP/UDP 30000-32767NodePort port range
    -
    controlplane nodes - Outbound rules
    +

    controlplane nodes - Outbound rules

    @@ -150,15 +174,27 @@ + + + + + + + + + + + +
    Protocol
    • etcd nodes
    • controlplane nodes
    • worker nodes
    		 Canal/Flannel VXLAN overlay networking
    TCP9099
    • controlplane node itself (local traffic, not across nodes)
    See Local node traffic    		Canal/Flannel livenessProbe/readinessProbe
    TCP 10250
    • etcd nodes
    • controlplane nodes
    • worker nodes
    		 kubelet
    TCP10254
    • controlplane node itself (local traffic, not across nodes)
    See Local node traffic    		Ingress controller livenessProbe/readinessProbe

    worker nodes:
    Nodes with the role worker

    -
    worker nodes - Inbound rules
    +

    worker nodes - Inbound rules

    @@ -184,12 +220,24 @@ + + + + + + + + + + + + @@ -197,7 +245,7 @@
    Protocol
    • etcd nodes
    • controlplane nodes
    • worker nodes
    		 Canal/Flannel VXLAN overlay networking
    TCP9099
    • worker node itself (local traffic, not across nodes)
    See Local node traffic    		Canal/Flannel livenessProbe/readinessProbe
    TCP 10250
    • controlplane nodes
    		 kubelet
    TCP10254
    • worker node itself (local traffic, not across nodes)
    See Local node traffic    		Ingress controller livenessProbe/readinessProbe
    TCP/UDP 30000-32767NodePort port range
    -
    worker nodes - Outbound rules
    +

    worker nodes - Outbound rules

    @@ -223,6 +271,21 @@ + + + + + + + + + + + +
    Protocol
    • etcd nodes
    • controlplane nodes
    • worker nodes
    		 Canal/Flannel VXLAN overlay networking
    TCP9099
    • worker node itself (local traffic, not across nodes)
    See Local node traffic    		Canal/Flannel livenessProbe/readinessProbe
    TCP10254
    • worker node itself (local traffic, not across nodes)
    See Local node traffic    		Ingress controller livenessProbe/readinessProbe

    +

    Information on local node traffic

    +

    Kubernetes healthchecks (livenessProbe and readinessProbe) are executed on the host itself. On most nodes, this is allowed by default. When you have applied strict host firewall (i.e. iptables) policies on the node, or when you are using nodes that have multiple interfaces (multihomed), this traffic gets blocked. In this case, you have to explicitely allow this traffic in your host firewall, or in case of public/private cloud hosted machines (i.e. AWS or OpenStack), in your security group configuration. Keep in mind that when using a security group as Source or Destination in your security group, that this only applies to the private interface of the nodes/instances. +

    diff --git a/layouts/shortcodes/requirements_rollback.html b/layouts/shortcodes/requirements_rollback.html index d0d9cd6f81c..ccf2c8d316c 100644 --- a/layouts/shortcodes/requirements_rollback.html +++ b/layouts/shortcodes/requirements_rollback.html @@ -8,5 +8,8 @@

    rancher-cluster.yml

    You'll need the RKE config file that you used for Rancher install, rancher-cluster.yml. You created this file during your initial install. Place this file in same directory as the RKE binary.

    +
  • + You must restore each of your etcd nodes to the same snapshot. Copy the snapshot you're using from one of your nodes to the others before running the etcd snapshot-restore command. +
    • \ No newline at end of file diff --git a/layouts/shortcodes/ssl_faq_ha.html b/layouts/shortcodes/ssl_faq_ha.html index 083994ae01a..b0f4525bfb6 100644 --- a/layouts/shortcodes/ssl_faq_ha.html +++ b/layouts/shortcodes/ssl_faq_ha.html @@ -73,7 +73,7 @@ certutil -decode FILENAME.base64 FILENAME.verify
    Command:
    -openssl s_client -CAfile ca.pem -connect rancher.yourdomain.com:443
+openssl s_client -CAfile ca.pem -connect rancher.yourdomain.com:443 -servername rancher.yourdomain.com
 ...
     Verify return code: 0 (ok)
    diff --git a/layouts/shortcodes/ssl_faq_single.html b/layouts/shortcodes/ssl_faq_single.html index aa3d2acefae..71f02c6b4d0 100644 --- a/layouts/shortcodes/ssl_faq_single.html +++ b/layouts/shortcodes/ssl_faq_single.html @@ -17,6 +17,42 @@ VWQqljhfacYPgp8KJUJENQ9h5hZ2nSCrI+W00Jcw4QcEdCI8HL5wmg== -----END CERTIFICATE----- +

    PEM Certificate Key Example:

    + +
    +-----BEGIN RSA PRIVATE KEY-----
+MIIGVDCCBDygAwIBAgIJAMiIrEm29kRLMA0GCSqGSIb3DQEBCwUAMHkxCzAJBgNV
+... more lines
+VWQqljhfacYPgp8KJUJENQ9h5hZ2nSCrI+W00Jcw4QcEdCI8HL5wmg==
+-----END RSA PRIVATE KEY-----
+
    + +

    If your key looks like the example below, see How Can I Convert My Certificate Key From PKCS8 to PKCS1?

    + +

    +-----BEGIN PRIVATE KEY-----
+MIIGVDCCBDygAwIBAgIJAMiIrEm29kRLMA0GCSqGSIb3DQEBCwUAMHkxCzAJBgNV
+... more lines
+VWQqljhfacYPgp8KJUJENQ9h5hZ2nSCrI+W00Jcw4QcEdCI8HL5wmg==
+-----END PRIVATE KEY-----
+
    + +

    How Can I Convert My Certificate Key From PKCS8 to PKCS1?

    + +

    If you are using a PKCS8 certificate key file, Rancher will log the following line:

    + +
    +ListenConfigController cli-config [listener] failed with : failed to read private key: asn1: structure error: tags don't match (2 vs {class:0 tag:16 length:13 isCompound:true})
+
    + +

    To make this work, you will need to convert the key from PKCS8 to PKCS1 using the command below:

    + +
    +openssl rsa -in key.pem -out convertedkey.pem
+
    + +

    You can now use convertedkey.pem as certificate key file for Rancher.

    +

    What is the Order of Certificates if I Want to Add My Intermediate(s)?

    The order of adding certificates is as follows:

    diff --git a/package.json b/package.json index 0cb2c49bb74..7347d0ea7ed 100644 --- a/package.json +++ b/package.json @@ -1,5 +1,6 @@ { "name": "rancher-docs", + "version": "1.0.1", "private": true, "scripts": { "build": "gulp build", @@ -7,9 +8,11 @@ "dev": "gulp dev", "server": "gulp server", "server:with-drafts": "gulp server:with-drafts", - "cms:delete": "gulp cms-delete" + "cms:delete": "gulp cms-delete", + "algolia": "node build-algolia.js" }, "dependencies": { + "atomic-algolia": "^0.3.15", "babel-core": "^6.25.0", "babel-preset-es2015": "^6.24.1", "babelify": "^8.0.0", @@ -23,16 +26,19 @@ "gulp-imagemin": "^4.1.0", "gulp-load-plugins": "^1.5.0", "gulp-newer": "^1.3.0", - "gulp-plumber": "^1.1.0", "gulp-sass": "^3.1.0", "gulp-sass-lint": "^1.3.2", "gulp-size": "^3.0.0", "gulp-uglify": "^3.0.0", "gulp-watch": "^5.0.0", + "instantsearch.js": "^2.8.0", "jquery": "^3.3.1", + "jsdom": "^11.11.0", + "md5": "^2.2.1", "moment": "^2.20.1", "node-sass-tilde-importer": "^1.0.0", "rancher-website-theme": "https://github.com/rancherlabs/website-theme.git", + "request": "^2.87.0", "run-sequence": "^2.0.0", "vinyl-buffer": "^1.0.1", "vinyl-source-stream": "^2.0.0" @@ -44,7 +50,6 @@ }, "devDependencies": { "gulp": "^3.9.1", - "hugo-search-index": "^0.4.1", "lory.js": "^2.4.1", "ml-stack-nav": "^1.1.2", "tingle.js": "^0.13.2" diff --git a/scripts/build-algolia.js b/scripts/build-algolia.js new file mode 100755 index 00000000000..ebbf2fb4b5f --- /dev/null +++ b/scripts/build-algolia.js @@ -0,0 +1,93 @@ +#! /usr/bin/env node +'use strict'; +const jsdom = require("jsdom"); +const { + JSDOM +} = jsdom; +const md5 = require('md5'); +const atomicalgolia = require("atomic-algolia"); +const fs = require('fs'); +const newNodes = []; +const newParagraphs = []; +const rawdata = fs.readFileSync('public/algolia.json'); +const nodes = JSON.parse(rawdata); + +nodes.forEach(node => { + const dom = new JSDOM(node.content); + const content = dom.window.document.body; //post content wrapped in a body tag + const contentChildren = content.children; // all the children of the body tag + const paragraphOut = { + anchor: '#', + title: '', + content: '', + postref: node.objectID, + objectID: null, + permalink: node.permalink + }; + + let childCount = contentChildren.length - 1; // how many children + + // loop over the content until the next h2 heading -> this is the paragraph of searchable text + while(childCount >= 0) { + const child = contentChildren[childCount]; + + if (child.tagName === "H2") { + //this is our header + paragraphOut.anchor = `#${child.id}`; + paragraphOut.title = child.textContent; + + let next = child.nextElementSibling; + + while(next && next.tagName !== 'H2') { + if (next && next.textContent) { + paragraphOut.content += next.textContent; + } + next = next.nextElementSibling; + } + + } + + childCount--; + } + + // a post without headers + if (paragraphOut.title === '') { + // Set the title to the page title + paragraphOut.title = node.title; + + // pass along the content + paragraphOut.content = content.textContent; + } + + if (paragraphOut.content) { + // limit the content to 10k so we dont blow up just incase someone decides to make a 40k blog post in one paragraph ¯\_(ツ)_/¯ + paragraphOut.content = paragraphOut.content.substr(0, 18000); + + // objectID is not quite unique yet so hash the entire object + paragraphOut.objectID = md5(JSON.stringify(paragraphOut)); + + if (true || paragraphOut.objectID === "d41d8cd98f00b204e9800998ecf8427e") { + console.log('===================================='); + console.log('ID:',paragraphOut.objectID); + console.log('Paragraph:',paragraphOut) + console.log('JSON:',JSON.stringify(paragraphOut)) + console.log('===================================='); + } + + newParagraphs.push(paragraphOut); + newNodes.push(node); + } + + + // remove potentially large content (see size limits) and replace with teh summary so that we don't get results with zero highlightable results + node.content = node.summary; + + // remove summary for dedup + delete node.summary; + +}); + +const merged = [...newParagraphs, ...newNodes]; + +fs.writeFileSync('public/final.algolia.json', JSON.stringify(merged)); +process.exit(0); diff --git a/scripts/dev b/scripts/dev index 211d5f7f671..746a7bf9689 100755 --- a/scripts/dev +++ b/scripts/dev @@ -83,16 +83,18 @@ if [[ "$THEME" ]]; then fi if [ -z "$BUILD_BUILD" ]; then + echo "Pulling ${IMAGE}:build" docker pull ${IMAGE}:build else echo "Building ${IMAGE}:build" - docker build -f Dockerfile.build -t ${IMAGE}:build . + docker build --no-cache -f Dockerfile.build -t ${IMAGE}:build . if [[ "$UPLOAD" ]]; then docker push ${IMAGE}:build fi fi if [ -z "$BUILD_DEV" ]; then + echo "Pulling ${IMAGE}:${TAG}" docker pull ${IMAGE}:${TAG} else TAG=local diff --git a/src/img/os/Rancher_aws5.png b/src/img/os/Rancher_aws5.png index d3d88dcec15..5f12f339b21 100644 Binary files a/src/img/os/Rancher_aws5.png and b/src/img/os/Rancher_aws5.png differ diff --git a/src/img/rancher/bulk-key-values.gif b/src/img/rancher/bulk-key-values.gif new file mode 100644 index 00000000000..9dad36e9247 Binary files /dev/null and b/src/img/rancher/bulk-key-values.gif differ diff --git a/src/img/rancher/splunk/splunk1.jpg b/src/img/rancher/splunk/splunk1.jpg new file mode 100644 index 00000000000..672074bb0ed Binary files /dev/null and b/src/img/rancher/splunk/splunk1.jpg differ diff --git a/src/img/rancher/splunk/splunk2.jpg b/src/img/rancher/splunk/splunk2.jpg new file mode 100755 index 00000000000..7b1d9051008 Binary files /dev/null and b/src/img/rancher/splunk/splunk2.jpg differ diff --git a/src/img/rancher/splunk/splunk3.jpg b/src/img/rancher/splunk/splunk3.jpg new file mode 100644 index 00000000000..08b4fb8a34e Binary files /dev/null and b/src/img/rancher/splunk/splunk3.jpg differ diff --git a/src/img/rancher/splunk/splunk4.jpg b/src/img/rancher/splunk/splunk4.jpg new file mode 100644 index 00000000000..0a4af253039 Binary files /dev/null and b/src/img/rancher/splunk/splunk4.jpg differ diff --git a/src/img/rancher/splunk/splunk5.jpg b/src/img/rancher/splunk/splunk5.jpg new file mode 100644 index 00000000000..2e15805e6da Binary files /dev/null and b/src/img/rancher/splunk/splunk5.jpg differ diff --git a/src/js/app.js b/src/js/app.js index 6bc24dcd01d..d5780117d18 100644 --- a/src/js/app.js +++ b/src/js/app.js @@ -1,2 +1,90 @@ +import $ from 'jquery'; +import instantsearch from 'instantsearch.js'; + // This is for any custom JS that may need to be added to individual apps. // Main JS is located in Rancher Website Theme +const bootstrapDocsSearch = function() { + + var firstSearchRender = true; + + const search = instantsearch({ + appId: '30NEY6C9UY', + apiKey: 'b7f43c16886fec97b87981e9e62ef1a5', + indexName: window.location.host === 'rancher.com' ? 'prod_docs' : 'dev_docs', + routing: true, + searchFunction: (helper) => { + + if (helper.state.query === "" && firstSearchRender) { + + firstSearchRender = false; + + return; + } + + helper.search(); + } + }); + + search.addWidget( + instantsearch.widgets.searchBox({ + autofocus: true, + loadingIndicator: true, + container: '#search-box', + placeholder: 'Search Docs...', + magnifier: false, + reset: true, + }) + ); + + search.addWidget( + instantsearch.widgets.infiniteHits({ + container: '#hits', + templates: { + empty: '

    No results

    ', + item: `

    {{{_highlightResult.title.value}}}

    {{{_snippetResult.content.value}}}
    ` + }, + escapeHits: true, + }) + ); + + search.start(); + + $(window).on('keyup', e => { + if (e.which === 27 && $('.container-search').hasClass('open')) { + $('.container-search').toggleClass('open'); + $('.overlay-search').toggleClass('open'); + } + }); + + $('header').on('click', '#button-search', () => { + + let container = $('.container-search'); + let overlay = $('.overlay-search'); + + container.toggleClass('open'); + overlay.toggleClass('open'); + + if (container.hasClass('open')) { + $('input#search-box').focus(); + } + + overlay.css({top: 120}); + }); +} + +const bootstrapIdLinks = function() { + const container = '.wrapper ARTICLE'; + const selector = 'h2[id], h3[id], h4[id], h5[id], h6[id]'; + $(container).on('mouseenter', selector, function(e) { + $(e.target).append($('').addClass('header-anchor').attr('href', '#' + e.target.id).html('')); + }); + + $(container).on('mouseleave', selector, function(e) { + $(e.target).parent().find('.header-anchor').remove(); + }); +} + +$(document).ready(() => { + bootstrapDocsSearch(); + bootstrapIdLinks(); +}); diff --git a/src/sass/app.scss b/src/sass/app.scss index 48829fde1c3..f55845b9e5e 100644 --- a/src/sass/app.scss +++ b/src/sass/app.scss @@ -3,6 +3,8 @@ // 7. node @import '~tingle.js/src/tingle', +'~instantsearch.js/dist/instantsearch.nomin', +'~instantsearch.js/dist/instantsearch-theme-algolia.nomin', '~ml-stack-nav/src/ml-stack-nav'; // 1. Configuration and helpers @@ -60,3 +62,66 @@ display: none; visibility: hidden; } + + +//accordion +.tab { + position: relative; + margin-bottom: 1px; + width: 100%; + overflow: hidden; + border: solid $border thin; + + input { + position: absolute; + opacity: 0; + z-index: -1; + } + label { + position: relative; + display: block; + padding: $spacer-xs; + background: lighten($bg-default,4%); + border: solid 1px $border; + font-size: 2rem; + cursor: pointer; + } + + .tab-content { + display: none; + overflow: hidden; + background: #fff; + -webkit-transition: max-height .35s; + -o-transition: max-height .35s; + transition: max-height .35s; + padding: $spacer-sm; + } + + /* :checked */ + input:checked~.tab-content { + display: block; + } + /* Icon */ + label::after { + position: absolute; + right: $spacer-xs; + top: $spacer-xs; + display: block; + text-align: center; + -webkit-transition: all .35s; + -o-transition: all .35s; + transition: all .35s; + } + input[type=checkbox]+label::after { + content: "+"; + } + input[type=radio]+label::after { + content: "\25BC"; + } + input[type=checkbox]:checked+label::after { + transform: rotate(90deg); + } + input[type=radio]:checked+label::after { + transform: rotateX(180deg); + } +}