-### 1. Create New Node and Pull Snapshot +### 1. Pull Snapshot and Certificates Bundle On New Nodes -If one of your `etcd` nodes go down, you need to replace it with a new node, and then pull the most recent working `etcd` snapshot to that node. +If `etcd` nodes failed, you can either: -**To Create a New Node and Pull the Latest Snapshot:** +- Create a new nodes of your choice—baremetal, on-prem virtual machine, cloud-based virtual machine, and so on. Provision it according to our [requirements]({{< baseurl >}}/rancher/v2.x/en/installation/ha-server-install/#host-requirements). -1. Create a new node of your choice—baremetal, on-prem virtual machine, cloud-based virtual machine, and so on. Provision it according to our [requirements]({{< baseurl >}}/rancher/v2.x/en/installation/ha-server-install/#host-requirements). +- Use the existing nodes, but you should be make sure to clean each node using the following commands: -2. Log in to your new node using a remote Terminal connection. +``` +docker rm -fv $(docker ps -qa) +docker volume ls -q | xargs docker volume rm +rm -rf /etc/kubernetes/ssl +rm -rf /etc/kubernetes/.tmp +rm -rf /var/lib/etcd +rm -rf /etc/cni +rm -rf /etc/kube-flannel/ +``` +in both cases you will need to pull the most recent working `etcd` snapshot and the certificates bundle to these nodes. -3. Create a directory that mirrors your other nodes' snapshot directories: +**To Pull the Latest Snapshot and Certificates Bundle:** + +1. Log in to each new node using a remote Terminal connection. + +2. Create a directory that mirrors your other nodes' snapshot directories: ``` root@newnode:~# mkdir -p /opt/rke/etcd-snapshots ``` -4. Pull your most recent snapshot onto the node. Replace `
+ +### Requirements + +If you use RKE to set up a cluster, your cluster nodes must meet the following requirements. + +{{< accordion id="os" label="Operating System" >}} + {{< requirements_os >}} +{{< /accordion >}} +{{< accordion id="hardware" label="Hardware" >}} + {{< requirements_hardware >}} +{{< /accordion >}} +{{< accordion id="software" label="Software" >}} + {{< requirements_software >}} +{{< /accordion >}} +{{< accordion id="ports-rancher" label="Ports for Rancher" >}} + {{< requirements_ports_rancher >}} +{{< /accordion >}} +{{< accordion id="ports-rke" label="Ports for RKE" >}} + {{< requirements_ports_rke >}} +{{< /accordion >}} \ No newline at end of file diff --git a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/_index.md b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/_index.md index d3f067980c9..9fbdb7e18a6 100644 --- a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/_index.md +++ b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/_index.md @@ -13,7 +13,7 @@ Using Rancher, you can create pools of nodes based on a [node template](#node-te Each node pool is assigned with a [node component]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#node-components) to specify how these nodes should be configured for the Kubernetes cluster. -## Node templates +## Node Templates A node template is the saved configuration for the parameters to use when provisioning nodes in a specific cloud provider. Rancher provides a nice UI to be able to launch these nodes and uses [Docker Machine](https://docs.docker.com/machine/) to provision these nodes. The available cloud providers to create node templates are based on the active node drivers in Rancher. @@ -44,8 +44,8 @@ If you want to use a node driver that Rancher doesn't support out-of-the-box, yo ## Activating/Deactivating Node Drivers -By default, Rancher only activates drivers for the most popular cloud providers, Amazon EC2, Azure, Digital Ocean and vSphere. If you want to show or hide any node driver, you can change it's status. +By default, Rancher only activates drivers for the most popular cloud providers, Amazon EC2, Azure, DigitalOcean and vSphere. If you want to show or hide any node driver, you can change it's status. 1. From the **Global** view, select **Node Drivers** from the main menu. -2. Find the driver that you want to activate or deactivate and select **Vertical Elipsis (... ) > Edit**. Choose either **Activate** or **Deactivate**. +2. Find the driver that you want to activate or deactivate and select **Vertical Elipsis (...) > Edit**. Choose either **Activate** or **Deactivate**. diff --git a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/digital-ocean/_index.md b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/digital-ocean/_index.md index 1d6f53926b4..479683c182c 100644 --- a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/digital-ocean/_index.md +++ b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/digital-ocean/_index.md @@ -9,7 +9,7 @@ Use {{< product >}} to create a Kubernetes cluster using DigitalOcean. 1. From the **Clusters** page, click **Add Cluster**. -2. Choose **Digital Ocean**. +2. Choose **DigitalOcean**. 3. Enter a **Cluster Name**. diff --git a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/ec2/_index.md b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/ec2/_index.md index 132b4fb2110..ce1f11b821f 100644 --- a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/ec2/_index.md +++ b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/ec2/_index.md @@ -7,6 +7,16 @@ aliases: --- Use {{< product >}} to create a Kubernetes cluster in Amazon EC2. +## Prerequisites + +- AWS EC2 Access Key and Secret key that will be used to create the instances. See [Amazon Documentation: Creating Access Keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey) how to create an Access Key and Secret Key. +- IAM Policy created to add to the user of the Access Key And Secret Key. See [Amazon Documentation: Creating IAM Policies (Console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-start) how to create an IAM policy. See our two example JSON policies below: + - [Example IAM Policy](#example-iam-policy) + - [Example IAM Policy with PassRole](#example-iam-policy-with-passrole) (needed if you want to use [Kubernetes Cloud Provider]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/cloud-providers) or want to pass an IAM Profile to an instance) +- IAM Policy added as Permission to the user. See [Amazon Documentation: Adding Permissions to a User (Console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) how to attach it to an user. + +## Create the cluster + 1. From the **Clusters** page, click **Add Cluster**. 1. Choose **Amazon EC2**. 1. Enter a **Cluster Name**. @@ -18,16 +28,13 @@ Use {{< product >}} to create a Kubernetes cluster in Amazon EC2. Complete each of the following forms using information available from the [EC2 Management Console](https://aws.amazon.com/ec2). - * **Account Access** is there you configure the region of the nodes, and the credentials (Access Key and Secret Key) used to create the machine. + * **Account Access** is where you configure the region of the nodes, and the credentials (Access Key and Secret Key) used to create the machine. See [Prerequisistes](#prerequisistes) how to create the Access Key and Secret Key and the needed permissions. - [Amazon Documentation: Creating Access Keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey). - - See [Example Node IAM policy](#example-node-iam-policy) for an example policy that can be applied to these credentials. - **Zone and Network** configures the availability zone and network settings for your cluster. - - **Security Groups** creates or configures the security groups applied to your nodes. + - **Security Groups** creates or configures the Security Groups applied to your nodes. Please refer to [Amazon EC2 security group when using Node Driver]({{< baseurl >}}/rancher/v2.x/en/installation/references/#amazonec2-securitygroup-nodedriver) to see what rules are created in the `rancher-nodes` Security Group. - **Instance** configures the instances that will be created. Make sure you configure the correct **SSH User** for the configured AMI. - If you need to pass an **IAM Instance Profile Name** (not ARN), for example, when you want to use a [Kubernetes Cloud Provider]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/cloud-providers), you will need an additional permission in your policy. See [Example Node IAM policy with PassRole](#example-node-iam-policy-with-passrole) for an example policy. + If you need to pass an **IAM Instance Profile Name** (not ARN), for example, when you want to use a [Kubernetes Cloud Provider]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/cloud-providers), you will need an additional permission in your policy. See [Example IAM policy with PassRole](#example-iam-policy-with-passrole) for an example policy. 1. {{< step_rancher-template >}} 1. Click **Create**. @@ -36,7 +43,7 @@ Use {{< product >}} to create a Kubernetes cluster in Amazon EC2. {{< result_create-cluster >}} -### Example Node IAM Policy +### Example IAM Policy ```json { @@ -88,7 +95,7 @@ Use {{< product >}} to create a Kubernetes cluster in Amazon EC2. } ``` -### Example Node IAM Policy with PassRole +### Example IAM Policy with PassRole ```json { diff --git a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/_index.md b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/_index.md index 8576632ad4b..2bef973caf4 100644 --- a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/_index.md +++ b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/_index.md @@ -7,40 +7,84 @@ aliases: --- Use {{< product >}} to create a Kubernetes cluster in vSphere. -### Prerequisites +## Introduction -Before setting up a cluster in vSphere, you must ensure that you have a user in vSphere with sufficient permissions to create a Rancher cluster. +When creating a vSphere cluster, Rancher first provisions the specified amount of virtual machines by communicating with the vCenter API. Then it installs Kubernetes on top of them. A vSphere cluster may consist of multiple groups of VMs with distinct properties, such as the amount of memory or the number of vCPUs. This grouping allows for fine-grained control over the sizing of nodes for the data, control, and worker plane respectively. + +>**Note:** +>The vSphere node driver included in Rancher currently only supports the provisioning of VMs with [RancherOS]({{< baseurl >}}/os/v1.x/en/) as the guest operating system. + +## Prerequisites + +Before proceeding to create a cluster, you must ensure that you have a vSphere user with sufficient permissions. If you are planning to make use of vSphere volumes for persistent storage in the cluster, there are [additional requirements]({{< baseurl >}}/rke/v0.1.x/en/config-options/cloud-providers/vsphere/) that must be met. +The following steps create a role with the required privileges and then assign it to a new user in the vSphere console: 1. From the **vSphere** console, go to the **Administration** page. 2. Go to the **Roles** tab. -3. Create a new *Role*. Give it a name and select the **Datastore**, **Network**, **Resource**, and **Virtual machine** *privileges*. +3. Create a new role. Give it a name and select the privileges listed in the [permissions table](#annex-vsphere-permissions). - - +  4. Go to the **Users and Groups** tab. -5. Create a new *User*. Fill out the form and then click **ok**. Make sure to note the username and password as you will need it when creating a cluster in Rancher. +5. Create a new user. Fill out the form and then click **OK**. Make sure to note the username and password, as you will need it when configuring node templates in Rancher. - +  6. Go to the **Global Permissions** tab. -7. Create a new *Global Permission*. Add the *User* you created earlier and assign it the Role you created earlier. Click **ok**. +7. Create a new Global Permission. Add the user you created earlier and assign it the role you created earlier. Click **OK**. - - - +  -Now you have a user that is able to successfully create and manager Rancher clusters in vSphere. +  -### Creating vSphere Clusters +## Creating vSphere Clusters -To create the cluster. +### Create a vSphere Node Template -1. From the **Clusters** page, click **Add Cluster**. +To create a cluster, you need to create at least one vSphere [node template]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/#node-templates) that specifies how VMs are created in vSphere. + +>**Note:** +>Once you create a node template, it is saved, and you can re-use it whenever you create additional vSphere clusters. + +1. Log in with an admin account to the Rancher UI. + +2. From the user settings menu, select **Node Templates**. + +3. Click **Add Template** and then click on the **vSphere** icon. + +4. Under [Account Access](#account-access) enter the vCenter FQDN or IP address and the credentials for the vSphere user account (see [Prerequisites](#prerequisites)). + +5. Under [Instance Options](#instance-options), configure the number of vCPUs, memory, and disk size for the VMs created by this template. + +6. **Optional:** Enter the URL pointing to a [RancherOS]({{< baseurl >}}/os/v1.x/en/) cloud-config file in the [Cloud Init](#instance-options) field. + +7. Ensure that the [OS ISO URL](#instance-options) contains the URL of a VMware ISO release for RancherOS (`rancheros-vmware.iso`). + +  + +8. **Optional:** Provide a set of [Configuration Parameters](#instance-options) for the VMs. + +9. Under **Scheduling**, enter the name/path of the **Data Center** to create the VMs in, the name of the **VM Network** to attach to, and the name/path of the **Datastore** to store the disks in. + +  + +10. **Optional:** Assign labels to the VMs that can be used as a base for scheduling rules in the cluster. + +11. **Optional:** Customize the configuration of the Docker daemon on the VMs that will be created. + +10. Assign a descriptive **Name** for this template and click **Create**. + +___ + +### Create a vSphere Cluster + +After you've created a template, you can use it stand up the vSphere cluster itself. + +1. From the **Global** view, click **Add Cluster**. 2. Choose **vSphere**. @@ -52,23 +96,64 @@ To create the cluster. 6. {{< step_create-cluster_node-pools >}} - 1. Click **Add Node Template**. +  - 2. Use the **vSphere Options** to authenticate with vSphere and provision your cluster. +7. Review your configuration, then click **Create**. - - **Account Access** holds the host name for your vCenter host and your credentials for authentication. - - - **Instance Options** are used to provision your cluster's VMs. - - - **Scheduling** is used to choose the hypervisor your virtual machines will be scheduled to. - - 3. {{< step_rancher-template >}} - - 4. Click **Create**. - - 5. **Optional:** Add additional node pools. - -
-7. Review your options to confirm they're correct. Then click **Create**. +> **Note:** +> +> If you have a cluster with DRS enabled, setting up [VM-VM Affinity Rules](https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.resmgmt.doc/GUID-7297C302-378F-4AF2-9BD6-6EDB1E0A850A.html) is recommended. These rules allow VMs assigned the etcd and control-plane roles to operate on separate ESXi hosts when they are assigned to different node pools. This practice ensures that the failure of a single physical machine does not affect the availability of those planes. {{< result_create-cluster >}} + +## Annex - Node Template Configuration Reference + +The tables below describe the configuration options available in the vSphere node template. + +### Account Access + +| Parameter | Required | Description | +|:------------------------:|:--------:|:------------------------------------------------------------:| +| vCenter or ESXi Server | * | IP or FQDN of the vCenter or ESXi server used for managing VMs. | +| Port | * | Port to use when connecting to the server. Defaults to `443`. | +| Username | * | vCenter/ESXi user to authenticate with the server. | +| Password | * | User's password. | + +___ + +### Instance Options + +| Parameter | Required | Description | +|:------------------------:|:--------:|:------------------------------------------------------------:| +| CPUs | * | Number of vCPUS to assign to VMs. | +| Memory | * | Amount of memory to assign to VMs. | +| Disk | * | Size of the disk (in MB) to attach to the VMs. | +| Cloud Init | | URL of a [RancherOS cloud-config]({{< baseurl >}}/os/v1.x/en/installation/configuration/) file to provision VMs with. This file allows further customization of the RancherOS operating system, such as network configuration, DNS servers, or system daemons.| +| OS ISO URL | * | URL of a RancherOS vSphere ISO file to boot the VMs from. You can find URLs for specific versions in the [Rancher OS GitHub Repo](https://github.com/rancher/os). | +| Configuration Parameters | | Additional configuration parameters for the VMs. These correspond to the [Advanced Settings](https://kb.vmware.com/s/article/1016098) in the vSphere console. Example use cases include providing RancherOS [guestinfo]({{< baseurl >}}/os/v1.x/en/installation/running-rancheros/cloud/vmware-esxi/#vmware-guestinfo) parameters or enabling disk UUIDs for the VMs (`disk.EnableUUID=TRUE`). | + +___ + +### Scheduling Options + +| Parameter | Required | Description | +|:------------------------:|:--------:|:------------------------------------------------------------:| +| Data Center | * | Name/path of the datacenter to create VMs in. | +| Pool | | Name/path of the resource pool to schedule the VMs in. If not specified, the default resource pool is used. | +| Host | | Name/path of the host system to schedule VMs in. If specified, the host system's pool will be used and the *Pool* parameter will be ignored. | +| Network | * | Name of the VM network to attach VMs to. | +| Data Store | * | Datastore to store the VM disks. | +| Folder | | Name/path of folder in the datastore to create the VMs in. Must already exist. | + +___ + +## Annex - vSphere Permissions + +The following table lists the permissions required for the vSphere user account configured in the node templates: + +| Privilege Group | Operations | +|:----------------------|:-----------------------------------------------------------------------| +| Datastore | AllocateSpace Browse FileManagement UpdateVirtualMachineFiles UpdateVirtualMachineMetadata | +| Network | Assign | +| Resource | AssignVMToPool | +| Virtual Machine | Config (All) GuestOperations (All) Interact (All) Inventory (All) Provisioning (All) | diff --git a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/_index.md b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/_index.md index 66530d8b917..c332bb59a02 100644 --- a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/_index.md +++ b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/_index.md @@ -20,27 +20,49 @@ From this section you can choose: - Whether Rancher should check if the nodes are running a supported or unsupported version of Docker. If you only allow supported versions, the cluster automatically fails to launch if you have an unsupported version of Docker. Each Kubernetes version is tied to specific Docker versions based on what Kubernetes tests against. -- The [Network Provider](https://kubernetes.io/docs/concepts/cluster-administration/networking/) that the cluster uses. Out of the box, Rancher supports: +- The [Network Provider](https://kubernetes.io/docs/concepts/cluster-administration/networking/) that the cluster uses. - - **[Canal](https://github.com/projectcalico/canal)**: In v2.0.0 - v2.0.4 and v2.0.6, this was the default option for these clusters was Canal with network isolation. With the network isolation automatically enabled, it prevented any pod communication between [projects]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/projects-and-namespaces/). + >**Note:** After you launch the cluster, you cannot change your network provider. Therefore, choose which network provider you want to use carefully, as Kubernetes doesn't allow switching between network providers. Once a cluster is created with a network provider, changing network providers would require you tear down the entire cluster and all its applications. - - **[Flannel](https://github.com/coreos/flannel#flannel)**: In v2.0.5, this was the default option, which did not prevent any network isolation between projects. + Out of the box, Rancher supports the following network providers: - - **[Calico](https://docs.projectcalico.org/v3.1/introduction/)** + - [Canal](https://github.com/projectcalico/canal) + + In v2.0.0 - v2.0.4 and v2.0.6, this was the default option for these clusters was Canal with network isolation. With the network isolation automatically enabled, it prevented any pod communication between [projects]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/). + + As of release v2.0.7, if you use Canal, you also have the option of using **Project Network Isolation**, which will enable or disable communication between pods in different [projects]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/). + + >**Attention Rancher v2.0.0 - v2.0.6 Users** + > + >- In previous Rancher releases, Canal isolates project network communications with no option to disable it. If you are using any of these Rancher releases, be aware that using Canal prevents all communication between pods in different projects. + >- If you are have clusters using Canal and are upgrading to v2.0.7, those clusters enable Project Network Isolation by default. If you want to disable Project Network Isolation, edit the cluster and disable the option. + - > **Note:** Please carefully select which network provider you want to use as Kubernetes doesn't allow switching between network providers. Once a cluster is created with a network provider, you would need to tear down the entire cluster and all applications to be able to switch to a different one. + - [Flannel](https://github.com/coreos/flannel#flannel) + + In v2.0.5, this was the default option, which did not prevent any network isolation between projects. -- Whether or not to use a [cloud provider]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/cloud-providers). If you want to use [volumes and storage]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/volumes-and-storage/) in Kubernetes, typically you must select the specific cloud provider in order to use it. For example, if you want to use Amazon EBS, you would need to select the `aws` cloud provider. + - [Calico](https://docs.projectcalico.org/v3.1/introduction/) - > **Note:** If your cloud provider is not listed as an option, you will need to use the [config file option](#config-file) to use that cloud provider. Please reference the [RKE's cloud provider documentation]({{< baseurl >}}/rke/v0.1.x/en/config-options/cloud-providers/) on how to configure these other cloud providers. + Another network provider option. + +
+ +- Whether or not to use a [cloud provider]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/cloud-providers). If you want to use [volumes and storage]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/) in Kubernetes, typically you must select the specific cloud provider in order to use it. For example, if you want to use Amazon EBS, you would need to select the `aws` cloud provider. + + >**Note:** If your cloud provider is not listed as an option, you will need to use the [config file option](#config-file) to use that cloud provider. Please reference the [RKE's cloud provider documentation]({{< baseurl >}}/rke/v0.1.x/en/config-options/cloud-providers/) on how to configure these other cloud providers. - Whether or not to use a [pod security policy]({{< baseurl >}}/rancher/v2.x/en/admin-settings/pod-security-policies). You must have an existing pod security policy configured before you can use this option. ## Config File +>**Note:** In Rancher v2.0.5 and v2.0.6, the names of services in the Config File (YAML) should contain underscores only: `kube_api` and `kube_controller`. + Instead of using the Rancher UI to choose Kubernetes options for the cluster, advanced users can create an RKE config file. Using a config file allows you to set any of the [options available]({{< baseurl >}}/rke/v0.1.x/en/config-options/) in an RKE installation. - To edit an RKE config file directly from the Rancher UI, click **Edit as YAML**. - To read from an existing RKE file, click **Read from File**. + + For an example of RKE config file syntax, see the [RKE documentation]({{< baseurl >}}/rke/v0.1.x/en/example-yamls/). diff --git a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/cloud-providers/_index.md b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/cloud-providers/_index.md index 78f58542bc9..bb6157d127d 100644 --- a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/cloud-providers/_index.md +++ b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/cloud-providers/_index.md @@ -24,19 +24,14 @@ When using the `Amazon` cloud provider, you can leverage the following capabilit ### Prerequisites -- Create/configure an IAM role +- Create an IAM role and attach to the instances - Configuring the ClusterID -> **Note:** When you create an [Amazon EC2 Cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/ec2/#create-the-amazon-ec2-cluster), the `ClusterID` is automatically configured. +> **Note:** When you create an [Amazon EC2 Cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/ec2/#create-the-amazon-ec2-cluster), the `ClusterID` is automatically configured for the created nodes. Other resources still need to be tagged manually. -#### Create/Configure an IAM Role +#### Create an IAM Role and attach to the instances -All nodes added to the cluster must be able to interact with EC2 so that they can create and remove resources. You can enable this interaction by using an IAM role attached to the instance. - -[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/cluster-provisioning/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/cluster-provisioning/custom-clusters/), you must manually attach the IAM role to the instance(s). +All nodes added to the cluster must be able to interact with EC2 so that they can create and remove resources. You can enable this interaction by using an IAM role attached to the instance. See [Amazon documentation: Creating an IAM Role](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#create-iam-role) how to create an IAM role. The following IAM role can be created: @@ -73,6 +68,9 @@ The following IAM role can be created: } ``` +- While creating an [Amazon EC2 cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/ec2/#create-the-amazon-ec2-cluster), you must fill in the **IAM Instance Profile Name** (not ARN) of the created IAM role when creating the **Node Template**. This requires an additional IAM permission, see [Example IAM Policy with PassRole]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/ec2/#example-iam-policy-with-passrole). +- While creating a [Custom cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/custom-clusters/), you must manually attach the IAM role to the instance(s). + #### Configuring the ClusterID The following resources need to tagged with a `ClusterID`: diff --git a/content/rancher/v2.x/en/faq/telemetry/_index.md b/content/rancher/v2.x/en/faq/telemetry/_index.md new file mode 100644 index 00000000000..60485db2e06 --- /dev/null +++ b/content/rancher/v2.x/en/faq/telemetry/_index.md @@ -0,0 +1,32 @@ +--- +title: Telemetry +weight: 8006 +--- + +### What is Telemetry? + +Telemetry collects aggregate information about the size of Rancher installations, versions of components used, and which features are used. This information is used by Rancher Labs to help make the product better and is not shared with third-parties. + +### What information is collected? + +No specific identifying information like usernames, passwords, or the names or addresses of user resources will ever be collected. + +The primary things collected include: + + - Aggregate counts (smallest, average, largest, total) of nodes per-cluster and their size (e.g. CPU cores & RAM). + - Aggregate counts of logical resources like Clusters, Projects, Namespaces, and Pods. + - Counts of what driver was used to deploy clusters and nodes (e.g. GKE vs EC2 vs Imported vs Custom). + - Versions of Kubernetes components, Operating Systems and Docker that are deployed on nodes. + - Whether some optional components are enabled or not (e.g. which auth providers are used). + - The image name & version of Rancher that is running. + - A unique randomly-generated identifier for this installation. + +### Can I see the information that is being sent? + +If Telemetry is enabled, you can go to `https://
diff --git a/content/rancher/v2.x/en/installation/ha/rke-all-in-one/layer-7-lb/_index.md b/content/rancher/v2.x/en/installation/ha/rke-all-in-one/layer-7-lb/_index.md index ac38f375965..9fb112f4045 100644 --- a/content/rancher/v2.x/en/installation/ha/rke-all-in-one/layer-7-lb/_index.md +++ b/content/rancher/v2.x/en/installation/ha/rke-all-in-one/layer-7-lb/_index.md @@ -31,7 +31,7 @@ Installation of Rancher in a high-availability configuration involves multiple p [RKE](https://github.com/rancher/rke/releases) is a fast, versatile Kubernetes installer that you can use to install Kubernetes on your Linux hosts. -5. [Download RKE Config File Template](#5-download-config-file-template) +5. [Download RKE Config File Template](#5-download-rke-config-file-template) RKE uses a YAML config file to install and configure your Kubernetes cluster. Download one of our RKE config file templates to get started. @@ -147,7 +147,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 RKE Config File Template](#5-download-rke-config-file-template). ``` # MacOS @@ -187,7 +187,7 @@ Once you have the `rancher-cluster.yml` config file template, edit the nodes sec 1. Open `rancher-cluster.yml` in your favorite text editor. -2. Update the `nodes` section with the information of your [Linux hosts](#provision-linux-hosts). +2. Update the `nodes` section with the information of your [Linux hosts](#1-provision-linux-hosts). 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`. @@ -260,7 +260,7 @@ If you are using a Certificate Signed By A Recognized Certificate Authority, you ## 8. Configure FQDN -There is one reference to `
diff --git a/content/rancher/v2.x/en/installation/single-node/advanced-options/proxy-configuration/_index.md b/content/rancher/v2.x/en/installation/single-node/advanced-options/proxy-configuration/_index.md index 79572a0274d..3dd3fa231c2 100644 --- a/content/rancher/v2.x/en/installation/single-node/advanced-options/proxy-configuration/_index.md +++ b/content/rancher/v2.x/en/installation/single-node/advanced-options/proxy-configuration/_index.md @@ -1,32 +1,83 @@ --- -title: Rancher HTTP Proxy Configuration +title: HTTP Proxy Configuration weight: 360 aliases: - /rancher/v2.x/en/installation/proxy-configuration/ --- -If you operate Rancher behind a proxy and you need to reach the Internet to perform tasks (such as using Helm catalogs), you must provide Rancher information about your proxy. +If you operate Rancher behind a proxy and you want to access services through the proxy (such as retrieving catalogs), you must provide Rancher information about your proxy. As Rancher is written in Go, it uses the common proxy environment variables as shown below. -### Setting the `http_proxy` Environment Variable +Make sure `NO_PROXY` contains the network addresses, network address ranges and domains that should be excluded from using the proxy. -#### Ubuntu +Environment variable | Purpose +--------------------------|--------- +HTTP_PROXY | Proxy address to use when initiating HTTP connection(s) +HTTPS_PROXY | Proxy address to use when initiating HTTPS connection(s) +NO_PROXY | Network address(es), network address range(s) and domains to exclude from using the proxy when initiating connection(s) -1. Check if `http_proxy` is still defined: +> **Note** NO_PROXY must be in uppercase to use network range (CIDR) notation. - ``` -echo $http_proxy - ``` +## Single Node Installation - If it is empty, set the variable and store it in your account's environment using the following command: +Passing environment variables to the Rancher container can be done using `-e KEY=VALUE` or `--env KEY=VALUE`. Required values for `NO_PROXY` in a [Single Node Installation]({{< baseurl >}}/rancher/v2.x/en/installation/single-node-install/) are: - ``` -echo "export http_proxy=http://
diff --git a/content/rancher/v2.x/en/k8s-in-rancher/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/_index.md new file mode 100644 index 00000000000..7858a9b4a3b --- /dev/null +++ b/content/rancher/v2.x/en/k8s-in-rancher/_index.md @@ -0,0 +1,143 @@ +--- +title: Kubernetes in Rancher +weight: 3000 +aliases: + - /rancher/v2.x/en/concepts/ + - /rancher/v2.x/en/tasks/ + - /rancher/v2.x/en/concepts/resources/ +--- + +After you provision a cluster in Rancher, you can begin using powerful Kubernetes features to deploy and scale your containerized applications in development, testing, or production environments. + +## Interacting with Clusters + +- **Rancher UI** + + Rancher provides an intuitive user interface for interacting with your clusters. All options available in the UI use the Rancher API. Therefore any action possible in the UI is also possible in the Rancher CLI or Rancher API. + +- **kubectl** + + You can use the Kubernetes command-line tool, [kubectl](https://kubernetes.io/docs/reference/kubectl/overview/), to manage your clusters. You have two options for using kubectl: + + - **Rancher kubectl shell** + + Interact with your clusters by launching a kubectl shell available in the Rancher UI. This option requires no configuration actions on your part. + + For more information, see [Accessing Clusters with kubectl Shell]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/kubectl/#accessing-clusters-with-kubectl-shell). + + - **Terminal remote connection** + + You can also interact with your clusters by installing [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) on your local desktop and then copying the cluster's kubeconfig file to your local `~/.kube/config` directory. + + For more information, see [Accessing Clusters with kubectl and a kubeconfig File]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/kubectl/#accessing-clusters-with-kubectl-and-a-kubeconfig-file). + +- **Rancher CLI** + + You can control your clusters by downloading Rancher's own command-line interface, [Rancher CLI]({{< baseurl >}}/rancher/v2.x/en/cli/). This CLI tool can interact directly with different clusters and projects or pass them `kubectl` commands. + +- **Rancher API** + + Finally, you can interact with your clusters over the Rancher API. Before you use the API, you must obtain an [API key]({{< baseurl >}}/rancher/v2.x/en/user-settings/api-keys/). To view the different resource fields and actions for an API object, open the API UI, which can be accessed by clicking on **View in API** for any Rancher UI object. + +## Editing Clusters + +After you launch a cluster, you can edit many of its settings configured during its initial launch. All clusters allow you to edit the cluster membership, which is a pool of users that can access the cluster, along with their roles within the cluster. For more information, see [members]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#membership-and-role-assignment) and [roles]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles). + +Depending on how you provisioned your clusters, different settings are available for editing their size and options. + +- For clusters provisioned in a [hosted kubernetes provider]({{< baseurl>}}/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/), you can edit the options chosen during cluster provisioning. These options are dependent on your hosted Kubernetes provider. + +- For [Rancher Launched Kubernetes]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/) clusters, you can edit the following options. + + - [Kubernetes options]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/), including: + + - The version of Kubernetes installed. + - Whether the cluster allows unsupported versions of Docker to run. + - Whether the cluster uses a cloud provider. + - Whether the cluster applies a pod security policy. + + >**Note:** You cannot edit the cluster's network provider after its initial launch. + + - **[Node pool]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/#node-pools) or [custom node]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/) clusters only:** the scale and [roles of your nodes]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#kubernetes-cluster-node-components). + + - For node pools, you can add/remove/edit cluster node pools. Node pools are set to a specific scale, so removing nodes individually does not change the size of the cluster unless you change the scale of the pool. + - For custom nodes, you are provided the Docker command to add nodes, but the command can also be used to edit the roles of existing nodes. To remove nodes, browse to the cluster's **Nodes** page and delete the unnecessary nodes. + +To view the settings available for your cluster, see [Editing Clusters]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/editing-clusters). + +## Projects and Namespaces + +To support multi-tenancy on a cluster, create different [projects]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/). Projects allow you to group several [namespaces]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#namespaces) into a single object. You can set user access and pod security policies for each project, which allows groups of users to access different sets of namespaces while using the same cluster. Projects are a feature available in Rancher, but not the base version of Kubernetes. + +For more information on how to manage projects, see: + +- [Projects and Namespaces]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/) +- [Project Members]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/project-members/) + +## Workloads + +Deploy applications to your cluster nodes using [workloads]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/workloads/), which are objects that contain pods that run your apps, along with metadata that set rules for the deployment's behavior. Workloads can be deployed within the scope of the entire clusters or within a namespace. + +When deploying a workload, you can deploy from any image. There are a variety of [workload types]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/workloads/#workload-types) to choose from which determine how your application should run. + +Following a workload deployment, you can continue working with it. You can: + +- [Upgrade]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/workloads/upgrade-workloads) the workload to a newer version of the application it's running. +- [Roll back]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/workloads/rollback-workloads) a workload to a previous version, if an issue occurs during upgrade. +- [Add a sidecar]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/workloads/add-a-sidecar), which is a workload that supports a primary workload. + +## Load Balancing and Ingress + +### Load Balancers + +After you launch an application, it's only available within the cluster. It can't be reached externally. + +If you want your applications to be externally accessible, you must add a load balancer to your cluster. Load balancers create a gateway for external connections to access your cluster, provided that the user knows the load balancer's IP address and the application's port number. + +Rancher supports two types of load balancers: + +- [Layer-4 Load Balancers]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/load-balancers/#layer-4-load-balancer) +- [Layer-7 Load Balancers]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/load-balancers/#layer-7-load-balancer) + +For more information, see [load balancers]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/load-balancers). + +#### Ingress + +Load Balancers can only handle one IP address per service, which means if you run multiple services in your cluster, you must have a load balancer for each service. Running multiples load balancers can be expensive. You can get around this issue by using an ingress. + +Ingress is a set or rules that act as a load balancer. Ingress works in conjunction with one or more ingress controllers to dynamically route service requests. When the ingress receives a request, the ingress controller(s) in your cluster program the load balancer to direct the request to the correct service based on service subdomains or path rules that you've configured. + +For more information, see [Ingress]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/ingress). + +## Service Discovery + +After you expose your cluster to external requests using a load balancer and/or ingress, it's only available by IP address. To create a resolveable hostname, you must create a service record, which is a record that maps an IP address, external hostname, DNS record alias, workload(s), or labled pods to a specific hostname. + +For more information, see [Service Discovery]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/service-discovery). + +## Volumes and Storage + +For workloads that need to retain their state, you must add external storage for the workload. Storage volumes are locations outside of your pods where applications can store their data. Because the storage is external to the workload, if a container fails, the container that replaces it can restore the external data, making recovery appear seamless. + +Within Rancher, you can create persistent storage using one of two methods: + +- [Persistent Volumes]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/#persistent-volumes) + + Persistent volumes are pre-provisioned storage volumes that you can bind to pods later using persistent volume claims. + +- [Storage Classes]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/#storage-classes) + + Storage classes are objects that provision storage volumes upon request. When a pod submits a persistent volume claim to the storage class, the class creates a storage volume for the pod. + +After you deploy a workload, it requests storage using a [persistent volume claim]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/persistent-volume-claims), which is like a voucher used to claim storage space available within the cluster. + +## Kubernetes Resources + +Within the context of a Rancher project or namespace, _resources_ are files and data that support operation of your pods. Within Rancher, certificates, registries, and secrets are all considered resources. However, Kubernetes classifies resources as different types of [secrets](https://kubernetes.io/docs/concepts/configuration/secret/). Therefore, within a single project or namespace, individual resources must have unique names to avoid conflicts. Although resources are primarily used to carry sensitive information, they have other uses as well. + +Resources include: + +- [Certificates]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/certificates/): Files used to encrypt/decrypt data entering or leaving the cluster. +- [ConfigMaps]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/configmaps/): Files that store general configuration information, such as a group of config files. +- [Secrets]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/secrets/): Files that store sensitive data like passwords, tokens, or keys. +- [Registries]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/registries/): Files that carry credentials used to authenticate with private registries. diff --git a/content/rancher/v2.x/en/kubernetes-in-rancher/certificates/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/certificates/_index.md similarity index 96% rename from content/rancher/v2.x/en/kubernetes-in-rancher/certificates/_index.md rename to content/rancher/v2.x/en/k8s-in-rancher/certificates/_index.md index 1ec1dcb22f5..302e22b9d06 100644 --- a/content/rancher/v2.x/en/kubernetes-in-rancher/certificates/_index.md +++ b/content/rancher/v2.x/en/k8s-in-rancher/certificates/_index.md @@ -41,4 +41,4 @@ Add SSL certificates to either projects, namespaces, or both. A project scoped c ## 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/kubernetes-in-rancher/load-balancers-and-ingress/ingress/). +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/k8s-in-rancher/load-balancers-and-ingress/ingress/). diff --git a/content/rancher/v2.x/en/kubernetes-in-rancher/configmaps/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/configmaps/_index.md similarity index 94% rename from content/rancher/v2.x/en/kubernetes-in-rancher/configmaps/_index.md rename to content/rancher/v2.x/en/k8s-in-rancher/configmaps/_index.md index ae28e221bac..82814cc4b52 100644 --- a/content/rancher/v2.x/en/kubernetes-in-rancher/configmaps/_index.md +++ b/content/rancher/v2.x/en/k8s-in-rancher/configmaps/_index.md @@ -30,7 +30,7 @@ ConfigMaps store general configuration information for an application, such as c 1. Click **Save**. - >**Note:** Don't use ConfigMaps to store sensitive data [use a secret]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/secrets/). + >**Note:** Don't use ConfigMaps to store sensitive data [use a secret]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/secrets/). > >**Tip:** You can add multiple key value pairs to the ConfigMap by copying and pasting. > @@ -45,4 +45,4 @@ Now that you have a ConfigMap added to a namespace, you can add it to a workload - 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/kubernetes-in-rancher/workloads/deploy-workloads/). +For more information on adding ConfigMaps to a workload, see [Deploying Workloads]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/workloads/deploy-workloads/). diff --git a/content/rancher/v2.x/en/kubernetes-in-rancher/editing-clusters/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/editing-clusters/_index.md similarity index 88% rename from content/rancher/v2.x/en/kubernetes-in-rancher/editing-clusters/_index.md rename to content/rancher/v2.x/en/k8s-in-rancher/editing-clusters/_index.md index 555cf2c180d..309e665b75c 100644 --- a/content/rancher/v2.x/en/kubernetes-in-rancher/editing-clusters/_index.md +++ b/content/rancher/v2.x/en/k8s-in-rancher/editing-clusters/_index.md @@ -7,6 +7,13 @@ weight: 3015 Following cluster creation, you can add users as cluster members so that they can access its resources. +>**Ping and MS FS Caveats:** +> +>- IdP does not support search or lookup. When adding users to clusters, the exact IDs must be entered correctly. +>- When adding users to a cluster, group IDs are not supported unless the admin who turned on access control is a member of the group. +>- When adding a group that includes an admin to clusters, add it from the drop-down rather than the search bar. If you add the group using the search bar, the group will not get added. + + 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**. diff --git a/content/rancher/v2.x/en/kubernetes-in-rancher/kubeconfig/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/kubeconfig/_index.md similarity index 94% rename from content/rancher/v2.x/en/kubernetes-in-rancher/kubeconfig/_index.md rename to content/rancher/v2.x/en/k8s-in-rancher/kubeconfig/_index.md index d66f8f8b174..98bd87d241e 100644 --- a/content/rancher/v2.x/en/kubernetes-in-rancher/kubeconfig/_index.md +++ b/content/rancher/v2.x/en/k8s-in-rancher/kubeconfig/_index.md @@ -13,7 +13,7 @@ When you create a cluster using the Rancher GUI, Rancher automatically creates a This kubeconfig file and its contents are specific to the cluster you are viewing. You will need a separate kubeconfig file for each cluster that you have access to in Rancher. -For more information, see [Using kubectl to Access a Cluster]({{< baseurl >}}/rancher/v2.x/en//kubernetes-in-rancher/kubectl). +For more information, see [Using kubectl to Access a Cluster]({{< baseurl >}}/rancher/v2.x/en//k8s-in-rancher/kubectl). >**Note:** By default, kubectl checks `~/.kube/config` for kubeconfig files, but you can use any directory you want using the `--kubeconfig` flag. For example: >``` diff --git a/content/rancher/v2.x/en/kubernetes-in-rancher/kubectl/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/kubectl/_index.md similarity index 97% rename from content/rancher/v2.x/en/kubernetes-in-rancher/kubectl/_index.md rename to content/rancher/v2.x/en/k8s-in-rancher/kubectl/_index.md index 63377479f00..edd00120150 100644 --- a/content/rancher/v2.x/en/kubernetes-in-rancher/kubectl/_index.md +++ b/content/rancher/v2.x/en/k8s-in-rancher/kubectl/_index.md @@ -7,7 +7,7 @@ aliases: You can access and manage your Kubernetes clusters using kubectl in two ways: - [Accessing Clusters with kubectl Shell](#accessing-clusters-with-kubectl-shell) -- [Accessing Clusters with kubectl CLI and a kubeconfig File]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/kubeconfig/) +- [Accessing Clusters with kubectl CLI and a kubeconfig File]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/kubeconfig/) ## Accessing Clusters with kubectl Shell diff --git a/content/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/_index.md new file mode 100644 index 00000000000..8b8dffba926 --- /dev/null +++ b/content/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/_index.md @@ -0,0 +1,45 @@ +--- +title: Load Balancing and Ingresses +weight: 3040 +--- + +Within Rancher, you can setup load balancers and ingress controllers to redirect service requests. + +## Load Balancers + +After you launch an application, the app is only available within the cluster. It can't be reached from outside the cluster. + +If you want your applications to be externally accessible, you must add a load balancer to your cluster. Load balancers create a gateway for external connections to access your cluster, provided that the user knows the load balancer's IP address and the application's port number. + +Rancher supports two types of load balancers: + +- [Layer-4 Load Balancers]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/load-balancers/#layer-4-load-balancer) +- [Layer-7 Load Balancers]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/load-balancers/#layer-7-load-balancer) + +For more information, see [load balancers]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/load-balancers). + +### Load Balancer Limitations + +Load Balancers have a couple of limitations you should be aware of: + +- Load Balancers can only handle one IP address per service, which means if you run multiple services in your cluster, you must have a load balancer for each service. Running multiples load balancers can be expensive. + +- If you want to use a load balancer with a Hosted Kubernetes cluster (i.e., clusters hosted in GKE, EKS, or AKS), you must host your load balancer with the same cloud provider. Please review the compatibility tables regarding support for load balancers based on how you've provisioned your clusters: + + + - [Support for Layer-4 Load Balancing]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/load-balancers/#support-for-layer-4-load-balancing) + + - [Support for Layer-7 Load Balancing]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/load-balancers/#support-for-layer-7-load-balancing) + +## Ingress + +As mentioned in the limitations above, using a load balancer per service can be expensive. You can get around this issue using an ingress. + +Ingress is a set or rules that act as a load balancer. Ingress works in conjunction with one or more ingress controllers to dynamically route service requests. When the ingress receives a request, the ingress controller(s) in your cluster program the load balancer to direct the request to the correct service based on service subdomains or path rules that you've configured. + +Your load balancer can either reside within your cluster or externally. Ingress and ingress controllers residing in RKE-launcher clusters are powered by [Nginx](https://www.nginx.com/). + +Ingress can provide other functionality as well, such as SSL termination, name-based virtual hosting, and more. + +- For more information on how to setup ingress in Rancher, see [Ingress]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/ingress). +- For complete information about ingress and ingress controllers, see the [Kubernetes Ingress Documentation](https://kubernetes.io/docs/concepts/services-networking/ingress/) diff --git a/content/rancher/v2.x/en/kubernetes-in-rancher/load-balancers-and-ingress/ingress/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/ingress/_index.md similarity index 99% rename from content/rancher/v2.x/en/kubernetes-in-rancher/load-balancers-and-ingress/ingress/_index.md rename to content/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/ingress/_index.md index 6f288d6bf5b..863a9c84a6e 100644 --- a/content/rancher/v2.x/en/kubernetes-in-rancher/load-balancers-and-ingress/ingress/_index.md +++ b/content/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/ingress/_index.md @@ -64,7 +64,7 @@ Ingress can be added for workloads to provide load balancing, SSL termination an 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]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/certificates/). + >**Note:** You must have an SSL certificate that the ingress can use to encrypt/decrypt communications. For more information see [Adding SSL Certificates]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/certificates/). 1. Click **Add Certificate**. diff --git a/content/rancher/v2.x/en/kubernetes-in-rancher/load-balancers-and-ingress/load-balancers/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/load-balancers/_index.md similarity index 94% rename from content/rancher/v2.x/en/kubernetes-in-rancher/load-balancers-and-ingress/load-balancers/_index.md rename to content/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/load-balancers/_index.md index f75aa11170f..486fa0126f0 100644 --- a/content/rancher/v2.x/en/kubernetes-in-rancher/load-balancers-and-ingress/load-balancers/_index.md +++ b/content/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/load-balancers/_index.md @@ -10,7 +10,7 @@ Kubernetes supports load balancing in two ways: Layer-4 Load Balancing and Layer Layer-4 load balancer (or the external load balancer) forwards traffic to Nodeports. Layer-4 load balancer allows you to forward both HTTP and TCP traffic. Layer-4 load balancer is supported by the underlying cloud provider. As a result, when you deploy RKE clusters on bare metal servers and vSphere clusters, layer-4 load balancer is not supported. -### Cloud Support for Layer-4 Load Balancing +### Support for Layer-4 Load Balancing Support for layer-4 load balancer varies based on the underlying cloud provider. @@ -28,7 +28,7 @@ RKE on Custom Hosts
(e.g. bare-metal servers) | Not Supported Layer-7 load balancer (or the ingress controller) supports host and path-based load balancing and SSL termination. Layer-7 load balancer only forwards HTTP and HTTPS traffic and therefore they listen on ports 80 and 443 only. Cloud providers such as Amazon and Google support layer-7 load balancer. In addition, RKE clusters deploys the Nginx Ingress Controller. -### Cloud Support for Layer-7 Load Balancing +### Support for Layer-7 Load Balancing Support for layer-7 load balancer varies based on the underlying cloud provider. @@ -55,8 +55,6 @@ The benefit of using xip.io is that you obtain a working entrypoint URL immediat ## Related Links -### External Load Balancers - #### External Links - [Create an External Load Balancer](https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/) @@ -67,6 +65,4 @@ The benefit of using xip.io is that you obtain a working entrypoint URL immediat - [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/k8s-in-rancher/nodes/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/nodes/_index.md new file mode 100644 index 00000000000..cf4bc90677e --- /dev/null +++ b/content/rancher/v2.x/en/k8s-in-rancher/nodes/_index.md @@ -0,0 +1,72 @@ +--- +title: Nodes +weight: +aliases: +--- + +After you launch a Kubernetes cluster in Rancher, you can manage individual nodes from the cluster's **Node** tab. Depending on the [option used]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#cluster-creation-in-rancher) to provision the cluster, there are different node options available. + +>**Note:** If you want to manage the _cluster_ and not individual nodes, see [Editing Clusters]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/editing-clusters). + +To manage individual nodes, browse to the cluster that you want to manage and then select **Nodes** from the main menu. The following sections list what node management options are available for each cluster type. + + + +- [Nodes Provisioned by Node Pool](#nodes-provisioned-by-node-pool) +- [Nodes Provisioned with the Custom Nodes Option](#nodes-provisioned-with-the-custom-nodes-option) +- [Nodes Provisioned by Hosted Kubernetes Providers](#nodes-provisioned-by-hosted-kubernetes-providers) +- [Imported Nodes](#imported-nodes) + + + + +## Nodes Provisioned by Node Pool + +Clusters provisioned using [one of the node pool options]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/#node-pools) automatically maintain the node scale that's set during the initial cluster provisioning. This scale determines the number of active nodes that Rancher maintains for the cluster. + +- Mark nodes as unschedulable (i.e., **Cordon**). When a node is cordoned, no new pods are scheduled for the node, but the existing pods continue to run. +- Delete defective nodes from the cloud provider. When you the delete a defective node, Rancher automatically replaces it with an identically provisioned node. + + >**Note:** If you want to scale down the number of nodes, use the scaling controls rather than deleting the node. +- Scale the number of nodes in the cluster up or down. +- Enter a **Custom Name**, **Description**, or **Label** for a node. +- Download the SSH key pair for a node. You can use this key pair to remote into the node using an SSH connection from your workstation. For more instructions on how to remote into the node, see [Remoting into a Node Pool Node](#remoting-into-a-node-pool-node). +- View API Data. + +### Remoting into a Node Pool Node + +1. From the Node Pool cluster, select **Nodes** from the main menu. +1. Find the node that you want to remote into. Select **Ellipsis (...) > Download Keys**. + + **Step Result:** A ZIP file containing files used for SSH is downloaded. + +1. Extract the ZIP file to any location. +1. Open Terminal. Change your location to the extracted ZIP file. +1. Enter the following command: + + ``` + ssh -i id_rsa root@
In addition to customizing each provisioner's options for the storage class, you can also define the volume `reclaimPolicy`. There are two options available: @@ -117,11 +119,10 @@ _Storage Classes_ allow you to dynamically provision persistent volumes on deman 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. - + >**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: + > + > - You must enable the `cloud provider` option for the EC2 cluster. + > - 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. @@ -133,11 +134,9 @@ Mount Persistent Volumes to workloads so that your applications can store their You can mount Persistent Volumes in one of two contexts: -- During deployment of a workload (recommended if possible). For more information, see [Deploying Workloads]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/workloads/deploy-workloads/). -- Following workload creation. For more information, see [Adding Persistent Volume Claims]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/volumes-and-storage/persistent-volume-claims/). +- During deployment of a workload (recommended if possible). For more information, see [Deploying Workloads]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/workloads/deploy-workloads/). +- Following workload creation. For more information, see [Adding Persistent Volume Claims]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/persistent-volume-claims/). ## Related Links -### External Docs - -- [Storage](https://kubernetes.io/docs/concepts/storage/) +- [Kubernetes Documentation: Storage](https://kubernetes.io/docs/concepts/storage/) diff --git a/content/rancher/v2.x/en/kubernetes-in-rancher/volumes-and-storage/examples/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/examples/_index.md similarity index 74% rename from content/rancher/v2.x/en/kubernetes-in-rancher/volumes-and-storage/examples/_index.md rename to content/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/examples/_index.md index 26c4f07257a..2b054ef2223 100644 --- a/content/rancher/v2.x/en/kubernetes-in-rancher/volumes-and-storage/examples/_index.md +++ b/content/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/examples/_index.md @@ -9,4 +9,5 @@ Rancher supports persistent storage with a variety of volume plugins. However, b For your convenience, Rancher offers documentation on how to configure some of the popular storage methods: -- [NFS Share](nfs) +- [NFS]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/examples/nfs/) +- [vSphere]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/examples/vsphere/) diff --git a/content/rancher/v2.x/en/kubernetes-in-rancher/volumes-and-storage/examples/nfs/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/examples/nfs/_index.md similarity index 88% rename from content/rancher/v2.x/en/kubernetes-in-rancher/volumes-and-storage/examples/nfs/_index.md rename to content/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/examples/nfs/_index.md index 4ee35a50945..e56839881f9 100644 --- a/content/rancher/v2.x/en/kubernetes-in-rancher/volumes-and-storage/examples/nfs/_index.md +++ b/content/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/examples/nfs/_index.md @@ -9,7 +9,7 @@ Before you can use the NFS storage volume plug-in with Rancher deployments, you >**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/kubernetes-in-rancher/volumes-and-storage/). +>- 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/k8s-in-rancher/volumes-and-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. @@ -65,4 +65,4 @@ Before you can use the NFS storage volume plug-in with Rancher deployments, you ## What's Next? -Within Rancher, add the NFS server as a [storage volume]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/volumes-and-storage/#adding-a-persistent-volume) and/or [storage class]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/volumes-and-storage/#adding-storage-classes). After adding the server, you can use it for storage for your deployments. +Within Rancher, add the NFS server as a [storage volume]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/#adding-a-persistent-volume) and/or [storage class]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/volumes-and-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/k8s-in-rancher/volumes-and-storage/examples/vsphere/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/examples/vsphere/_index.md new file mode 100644 index 00000000000..dc1e0a2b180 --- /dev/null +++ b/content/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/examples/vsphere/_index.md @@ -0,0 +1,70 @@ +--- +title: vSphere Storage +weight: 3055 +aliases: + - /rancher/v2.x/en/tasks/clusters/adding-storage/provisioning-storage/vsphere/ +--- + +To provide stateful workloads with vSphere storage, we recommend creating a vSphereVolume [storage class]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/#storage-classes). This practice dynamically provisions vSphere storage when workloads request volumes through a [persistent volume claim]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/persistent-volume-claims/). + +### Prerequisites + +In order to provision vSphere volumes in a cluster created with the [Rancher Kubernetes Engine (RKE)]({{< baseurl>}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/), the [vSphere cloud provider]({{< baseurl >}}/rke/v0.1.x/en/config-options/cloud-providers/vsphere) must be explicitly enabled in the [cluster options]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/). + +### Creating A Storage Class + +> **Note:** +> +> The following steps can also be performed using the `kubectl` command line tool. See [Kubernetes documentation on persistent volumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) for details. + +1. From the Global view, open the cluster where you want to provide vSphere storage. +2. From the main menu, select **Storage > Storage Classes**. Then click **Add Class**. +3. Enter a **Name** for the class. +4. Under **Provisioner**, select **VMWare vSphere Volume**. + +  + +5. Optionally, specify additional properties for this storage class under **Parameters**. Refer to the [vSphere storage documentation](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/storageclass.html) for details. +5. Click **Save**. + +### Creating a Workload with a vSphere Volume + +1. From the cluster where you configured vSphere storage, begin creating a workload as you would in [Deploying Workloads]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/workloads/deploy-workloads/). +2. For **Workload Type**, select **Stateful set of 1 pod**. +3. Expand the **Volumes** section and click **Add Volume**. +4. Choose **Add a new persistent volume (claim)**. This option will implicitly create the claim once you deploy the workload. +5. Assign a **Name** for the claim, ie. `test-volume` and select the vSphere storage class created in the previous step. +6. Enter the required **Capacity** for the volume. Then click **Define**. + +  + +7. Assign a path in the **Mount Point** field. This is the full path where the volume will be mounted in the container file system, e.g. `/persistent`. +8. Click **Launch** to create the workload. + +### Verifing Persistence of the Volume + +1. From the context menu of the workload you just created, click **Execute Shell**. +2. Note the directory at root where the volume has been mounted to (in this case `/persistent`). +3. Create a file in the volume by executing the command `touch /
- Replace `
If you use a hostname in the URL, this hostname must be resolvable by DNS on the nodes you want to add to you cluster. - -### Create the Cluster - -Welcome to Rancher! You are now able to create your first Kubernetes cluster. - -In this task, you can use the versatile **Custom** option. This option lets you add _any_ Linux host (cloud-hosted VM, on-premise VM, or bare-metal) to be used in a cluster. - -1. From the **Clusters** page, click **Add Cluster**. - -2. Choose **Custom**. - -3. Enter a **Cluster Name**. - -4. Skip **Member Roles** and **Cluster Options**. We'll tell you about them later. - -5. Click **Next**. - -6. From **Node Role**, select _all_ the roles: **etcd**, **Control**, and **Worker**. - -7. **Optional**: Rancher auto-detects the IP addresses used for Rancher communication and cluster communication. You can override these using `Public Address` and `Internal Address` in the **Node Address** section. - -8. Skip the **Labels** stuff. It's not important for now. - -9. Copy the command displayed on screen to your clipboard. - -10. Log in to your Linux host using your preferred shell, such as PuTTy or a remote Terminal connection. Run the command copied to your clipboard. - -11. When you finish running the command on your Linux host, click **Done**. - -{{< result_create-cluster >}} - -### Deploy a Workload - -You're ready to create your first _workload_. A workload is an object that includes pods along with other files and info needed to deploy your application. - -For this workload, you'll be deploying the application Nginx. - -1. From the **Clusters** page, open the cluster that you just created. - -2. From the main menu of the **Dashboard**, select **Projects**. - -3. Open the **Default** project. - -4. Click **+ Deploy**. - - **Step Result:** The **Deploy Workload** page opens. - -5. Enter a **Name** for your workload. - -6. From the **Docker Image** field, enter `nginx`. This field is case-sensitive. - -7. From **Port Mapping**, click **Add Port**. - -8. From the **As a** drop-down, make sure that **NodePort (On every node)** is selected. - -  - -9. From the **On Listening Port** field, leave the **Random** value in place. - -  - -10. From the **Publish the container port** field, enter port `80`. - -  - -11. Leave the remaining options on their default setting. We'll tell you about them later. - -12. Click **Launch**. - -**Result:** - -* Your workload is deployed. This process might take a few minutes to complete. -* When your workload completes deployment, it's assigned a state of **Active**. You can view this status from the project's **Workloads** page. - -### View Your Application - -When your workload completes deployment, browse to its IP to confirm that your application is working. - -From the **Workloads** page, click the link underneath your workload. If your deployment succeeded, your application opens. - ->**Note** -> When using a cloud-hosted virtual machine, you may not have access to the port running the container. In this event, you can test Nginx in an ssh session on the local machine. Use the port number after the `:` in the link under your workload, which is 31568 in this example. -> ->```sh - -gettingstarted@rancher:~$ curl http://localhost:31568 - - - -
Welcome to Nginx!
-If you see this page, the Nginx web server is successfully installed and -working. Further configuration is required.
- -For online documentation and support please refer to
-Nginx.org.
-Commercial support is available at
-nginx.com.
Thank you for using Nginx.
- - -gettingstarted@rancher:~$ - -``` - -## Finished - -Congratulations! You have: - -- Created your first cluster. -- Deployed Nginx to your cluster using a workload. +- [Deploying Workloads]({{< baseurl >}}/rancher/v2.x/en/quick-start-guide//workload/): Deploy a simple workload and expose it, letting you access it from outside the cluster. diff --git a/content/rancher/v2.x/en/quick-start-guide/deployment/_index.md b/content/rancher/v2.x/en/quick-start-guide/deployment/_index.md new file mode 100644 index 00000000000..cfccadb294d --- /dev/null +++ b/content/rancher/v2.x/en/quick-start-guide/deployment/_index.md @@ -0,0 +1,12 @@ +--- +title: Deploying Rancher Server +weight: 100 +--- + +The following are the current guides for provisioning Rancher Server and a cluster: + +- [DigitalOcean Quick Start](./digital-ocean-qs) - We provide you with a Terraform configuration file that completely automates the set up of the Rancher Server and registers a cluster for you to get started with. + +- [Vagrant Quick Start](./quickstart-vagrant) - We provide you with a Vagrant configuration that again completely automates the set up of the Rancher Server and registers a cluster for you to get started with. + +- [Manual Quick Start](./quickstart-manual-setup) - This will guide you through the process and requirements of manually setting up Rancher in any environment. diff --git a/content/rancher/v2.x/en/quick-start-guide/deployment/digital-ocean-qs/_index.md b/content/rancher/v2.x/en/quick-start-guide/deployment/digital-ocean-qs/_index.md new file mode 100644 index 00000000000..bfc0964705a --- /dev/null +++ b/content/rancher/v2.x/en/quick-start-guide/deployment/digital-ocean-qs/_index.md @@ -0,0 +1,56 @@ +--- +title: DigitalOcean Quick Start +weight: 100 +--- +The following steps will quickly deploy a Rancher Server with a single node cluster attached. + +## Prerequisites + +>**Note** +>Deploying to DigitalOcean will incur charges. + +- [DigitalOcean Account](https://www.digitalocean.com): You will require an account on DigitalOcean as this is where the server and cluster will run. +- [DigitalOcean Access Key](https://www.digitalocean.com/community/tutorials/how-to-create-a-digitalocean-space-and-api-key): Use this link to create a DigitalOcean Access Key if you don't have one. +- [Terraform](https://www.terraform.io/downloads.html): Used to provision the server and cluster to DigitalOcean. + + +## Getting Started + +1. Clone [Rancher Quickstart](https://github.com/rancher/quickstart) to a folder using `git clone https://github.com/rancher/quickstart`. + +2. Go into the DigitalOcean folder containing the terraform file by executing `cd quickstart/do`. + +3. Rename the `terraform.tfvars.example` file to `terraform.tfvars`. + +4. Edit `terraform.tfvars` to include your DigitalOcean Access Key. + +5. **Optional:** Edit `terraform.tfvars` to: + + - Change the number of nodes. (`count_agent_all_nodes`) + - Change the password of the `admin` user for logging into Rancher. (`admin_password`) + +6. Run `terraform init`. + +7. To initiate the creation of the environment, run `terraform apply`. Then wait for the the following output: + + ``` + Apply complete! Resources: 2 added, 0 changed, 0 destroyed. + Outputs: + rancher-url = [ + https://xxx.xxx.xxx.xxx + ] + ``` + +8. Paste the `rancher-url` from the output above into the browser. Log in when prompted (default password is `admin`). + +**Result:** Rancher Server and your Kubernetes cluster is installed on DigitalOcean. + +### What's Next? + +Use Rancher to create a deployment. For more information, see [Creating Deployments]({{< baseurl >}}/rancher/v2.x/en/quick-start-guide/workload). + +## Destroying the Environment + +1. From the `quickstart/do` folder, execute `terraform destroy --force`. + +2. Wait for confirmation that all resources have been destroyed. diff --git a/content/rancher/v2.x/en/quick-start-guide/deployment/quickstart-manual-setup/_index.md b/content/rancher/v2.x/en/quick-start-guide/deployment/quickstart-manual-setup/_index.md new file mode 100644 index 00000000000..d46f7938548 --- /dev/null +++ b/content/rancher/v2.x/en/quick-start-guide/deployment/quickstart-manual-setup/_index.md @@ -0,0 +1,129 @@ +--- +title: Manual Quick Start +weight: 300 +--- +Howdy Partner! This tutorial walks you through: + +- Installation of {{< product >}} {{< version >}} +- Creation of your first cluster +- Deployment of an application, Nginx + +## Quick Start Outline + +This Quick Start Guide is divided into different tasks for easier consumption. + + + + +1. [Provision a Linux Host](#1-provision-a-linux-host) + +1. [Install Rancher](#2-install-rancher) + +1. [Log In](#3-log-in) + +1. [Create the Cluster](#4-create-the-cluster) + + ++### 1. Provision a Linux Host + + Begin creation of a custom cluster by provisioning a Linux host. Your host can be: + +- A cloud-host virtual machine (VM) +- An on-premise VM +- A bare-metal server + + >**Note:** + > When using a cloud-hosted virtual machine you need to allow inbound TCP communication to ports 80 and 443. Please see your cloud-host's documentation for information regarding port configuration. + > + > For a full list of port requirements, refer to [Single Node Installation]({{< baseurl >}}/rancher/v2.x/en/installation/references). + + Provision the host according to the requirements below. + +{{% accordion id="os" label="Operating System" %}} +{{< requirements_os >}} +{{% /accordion %}} +{{% accordion id="hardware" label="Hardware" %}} +Memory: 4GB +{{% /accordion %}} +{{% accordion id="software" label="Software" %}} +Docker + + **Supported Docker versions:** + + - `1.12.6` + - `1.13.1` + - `17.03.2` + + >**Notes:** + > + > - For Docker installation instructions, visit their [documentation](https://docs.docker.com/install/). + > - Docker requirements apply to both your Linux host and your cluster nodes. +{{% /accordion %}} +
+### 2. Install Rancher + +To install Rancher on your host, connect to it and then use a shell to install. + +1. Log in to your Linux host using your preferred shell, such as PuTTy or a remote Terminal connection. + +2. From your shell, enter the following command: + + ``` + $ sudo docker run -d --restart=unless-stopped -p 80:80 -p 443:443 rancher/rancher + ``` + +**Result:** Rancher is installed. + +### 3. Log In + +Log in to Rancher to begin using the application. After you log in, you'll make some one-time configurations. + +1. Open a web browser and enter the IP address of your host: `https://
If you use a hostname in the URL, this hostname must be resolvable by DNS on the nodes you want to add to you cluster. + +
+ +### 4. Create the Cluster + +Welcome to Rancher! You are now able to create your first Kubernetes cluster. + +In this task, you can use the versatile **Custom** option. This option lets you add _any_ Linux host (cloud-hosted VM, on-premise VM, or bare-metal) to be used in a cluster. + +1. From the **Clusters** page, click **Add Cluster**. + +2. Choose **Custom**. + +3. Enter a **Cluster Name**. + +4. Skip **Member Roles** and **Cluster Options**. We'll tell you about them later. + +5. Click **Next**. + +6. From **Node Role**, select _all_ the roles: **etcd**, **Control**, and **Worker**. + +7. **Optional**: Rancher auto-detects the IP addresses used for Rancher communication and cluster communication. You can override these using `Public Address` and `Internal Address` in the **Node Address** section. + +8. Skip the **Labels** stuff. It's not important for now. + +9. Copy the command displayed on screen to your clipboard. + +10. Log in to your Linux host using your preferred shell, such as PuTTy or a remote Terminal connection. Run the command copied to your clipboard. + +11. When you finish running the command on your Linux host, click **Done**. + +{{< result_create-cluster >}} +
+
+#### Finished + +Congratulations! You have created your first cluster. + +#### What's Next? + +Use Rancher to create a deployment. For more information, see [Creating Deployments]({{< baseurl >}}/rancher/v2.x/en/quick-start-guide/workload). diff --git a/content/rancher/v2.x/en/quick-start-guide/deployment/quickstart-vagrant/_index.md b/content/rancher/v2.x/en/quick-start-guide/deployment/quickstart-vagrant/_index.md new file mode 100644 index 00000000000..5903aae2af2 --- /dev/null +++ b/content/rancher/v2.x/en/quick-start-guide/deployment/quickstart-vagrant/_index.md @@ -0,0 +1,38 @@ +--- +title: Vagrant Quick Start +weight: 200 +--- +The following steps quickly deploy a Rancher Server with a single node cluster attached. + +## Prerequisites + +- [Vagrant](https://www.vagrantup.com): Vagrant is required as this is used to provision the machine based on the Vagrantfile. +- [Virtualbox](https://www.virtualbox.org): The virtual machines that Vagrant provisions need to be provisioned to VirtualBox. +- At least 4GB of free RAM. + +## Getting Started + +1. Clone [Rancher Quickstart](https://github.com/rancher/quickstart) to a folder using `git clone https://github.com/rancher/quickstart`. + +2. Go into the folder containing the terraform file by executing `cd quickstart/vagrant`. + +3. **Optional:** Edit `config.yaml` to: + + - Change the number of nodes and the memory allocations, if required. (`node.count`, `node.cpus`, `node.memory`) + - Change the password of the `admin` user for logging into Rancher. (`default_password`) + +4. To initiate the creation of the environment run, `vagrant up`. + +5. Once provisioning finishes, go to `https://172.22.101.101` in the browser. The default user/password is `admin/admin`. + +**Result:** Rancher Server and your Kubernetes cluster is installed on VirtualBox. + +### What's Next? + +Use Rancher to create a deployment. For more information, see [Creating Deployments]({{< baseurl >}}/rancher/v2.x/en/quick-start-guide/workload). + +## Destroying the Environment + +1. From the `quickstart/vagrant` folder execute `vagrant destroy -f`. + +2. Wait for the confirmation that all resources have been destroyed. diff --git a/content/rancher/v2.x/en/quick-start-guide/workload/_index.md b/content/rancher/v2.x/en/quick-start-guide/workload/_index.md new file mode 100644 index 00000000000..201c4dd26a6 --- /dev/null +++ b/content/rancher/v2.x/en/quick-start-guide/workload/_index.md @@ -0,0 +1,10 @@ +--- +title: Deploying Workloads +weight: 200 +--- + +These Quick Start Guides will walk you through deployment of an application. Then they will show you how to expose the application so that you can access it from outside the cluster. + +- [Workload with Ingress Quick Start](./quickstart-deploy-workload-ingress): Create a workload and then expose it using an Ingress. + +- [Workload with NodePort Quick Start](./quickstart-deploy-workload-nodeport): Create a workload and then expose it using a Nodeport. \ No newline at end of file diff --git a/content/rancher/v2.x/en/quick-start-guide/workload/quickstart-deploy-workload-ingress/_index.md b/content/rancher/v2.x/en/quick-start-guide/workload/quickstart-deploy-workload-ingress/_index.md new file mode 100644 index 00000000000..a16a3c41d0d --- /dev/null +++ b/content/rancher/v2.x/en/quick-start-guide/workload/quickstart-deploy-workload-ingress/_index.md @@ -0,0 +1,79 @@ +--- +title: Workload with Ingress Quick Start +weight: 100 +--- + +### Prerequisite + +You have a running cluster with at least 1 node. + +### 1. Deploying a Workload + +You're ready to create your first _workload_. A workload is an object that includes pods along with other files and info needed to deploy your application. + +For this workload, you'll be deploying the application Rancher Hello-World. + +1. From the **Clusters** page, open the cluster that you just created. + +2. From the main menu of the **Dashboard**, select **Projects**. + +3. Open the **Project: Default** project. + +4. Click **Deploy**. + + **Step Result:** The **Deploy Workload** page opens. + +5. Enter a **Name** for your workload. + +6. From the **Docker Image** field, enter `rancher/hello-world`. This field is case-sensitive. + +7. Leave the remaining options on their default setting. We'll tell you about them later. + +8. Click **Launch**. + +**Result:** + +* Your workload is deployed. This process might take a few minutes to complete. +* When your workload completes deployment, it's assigned a state of **Active**. You can view this status from the project's **Workloads** page. + +
+### 2. Expose The Application Via An Ingress + +Now that the application is up and running it needs to be exposed so that other services can connect. + +1. From the **Clusters** page, open the cluster that you just created. + +2. From the main menu of the **Dashboard**, select **Projects**. + +3. Open the **Default** project. + +4. Click on the **Load Balancing** tab. + +5. Click **Add Ingress**. + +6. Enter a name i.e. **hello**. + +7. In the **Target** field, drop down the list and choose the name that you set for your service. + +8. Enter `80` in the **Port** field. + +9. Leave everything else as default and click **Save**. + +**Result:** The application is assigned a `xip.io` address and exposed. It may take a minute or two to populate. + +### View Your Application + +From the **Load Balancing** page, click the target link, which will look something like `hello.default.xxx.xxx.xxx.xxx.xip.io > hello-world`. + +Your application will open in a separate window. + +#### Finished + +Congratulations! You have successfully deployed a workload exposed via an ingress. + +#### What's Next? + +When you're done using your sandbox, destroy the Rancher Server and your cluster. See one of the following: + +- [DigitalOcean: Destroying the Environment]({{< baseurl >}}/rancher/v2.x/en/quick-start-guide/deployment/digital-ocean-qs/#destroying-the-environment) +- [Vagrant: Destroying the Environment]({{< baseurl >}}/rancher/v2.x/en/quick-start-guide/deployment/quickstart-vagrant/#destroying-the-environment) \ No newline at end of file diff --git a/content/rancher/v2.x/en/quick-start-guide/workload/quickstart-deploy-workload-nodeport/_index.md b/content/rancher/v2.x/en/quick-start-guide/workload/quickstart-deploy-workload-nodeport/_index.md new file mode 100644 index 00000000000..d6f9b49bdc7 --- /dev/null +++ b/content/rancher/v2.x/en/quick-start-guide/workload/quickstart-deploy-workload-nodeport/_index.md @@ -0,0 +1,153 @@ +--- +title: Workload with NodePort Quick Start +weight: 200 +--- + +### Prerequisite + +You have a running cluster with at least 1 node. + +### 1. Deploying a Workload + +You're ready to create your first _workload_. A workload is an object that includes pods along with other files and info needed to deploy your application. + +For this workload, you'll be deploying the application Rancher Hello-World. + +1. From the **Clusters** page, open the cluster that you just created. + +2. From the main menu of the **Dashboard**, select **Projects**. + +3. Open the **Project: Default** project. + +4. Click **Deploy**. + + **Step Result:** The **Deploy Workload** page opens. + +5. Enter a **Name** for your workload. + +6. From the **Docker Image** field, enter `rancher/hello-world`. This field is case-sensitive. + +7. From **Port Mapping**, click **Add Port**. + +8. From the **As a** drop-down, make sure that **NodePort (On every node)** is selected. + +  + +9. From the **On Listening Port** field, leave the **Random** value in place. + +  + +10. From the **Publish the container port** field, enter port `80`. + +  + +11. Leave the remaining options on their default setting. We'll tell you about them later. + +12. Click **Launch**. + +**Result:** + +* Your workload is deployed. This process might take a few minutes to complete. +* When your workload completes deployment, it's assigned a state of **Active**. You can view this status from the project's **Workloads** page. + +
+ +### 2. Viewing Your Application + +From the **Workloads** page, click the link underneath your workload. If your deployment succeeded, your application opens. + +### Attention: Cloud-Hosted Sandboxes + +When using a cloud-hosted virtual machine, you may not have access to the port running the container. In this event, you can test Nginx in an ssh session on the local machine. Use the port number after the `:` in the link under your workload, which is `31568` in this example. + +```sh +gettingstarted@rancher:~$ curl http://localhost:31568 + + + +
+ Hello world!
+My hostname is hello-world-66b4b9d88b-78bhx
+
+
+ + KUBERNETES tcp://10.43.0.1:443
+ +
+ k8s services found 2
+ + INGRESS_D1E1A394F61C108633C4BD37AEDDE757 tcp://10.43.203.31:80+ + KUBERNETES tcp://10.43.0.1:443
+ +
+ +
+ 
+ 
+ 
+ 
+ 
+ 
+
+
+
+
+
+
+
+ + + +
+ + + +gettingstarted@rancher:~$ + +``` + +### Finished + +Congratulations! You have successfully deployed a workload exposed via a NodePort. + +#### What's Next? + +When you're done using your sandbox, destroy the Rancher Server and your cluster. See one of the following: + +- [DigitalOcean: Destroying the Environment]({{< baseurl >}}/rancher/v2.x/en/quick-start-guide/deployment/digital-ocean-qs/#destroying-the-environment) +- [Vagrant: Destroying the Environment]({{< baseurl >}}/rancher/v2.x/en/quick-start-guide/deployment/quickstart-vagrant/#destroying-the-environment) \ No newline at end of file diff --git a/content/rancher/v2.x/en/tools/_index.md b/content/rancher/v2.x/en/tools/_index.md index d30b7101f69..1f54dfa41bd 100644 --- a/content/rancher/v2.x/en/tools/_index.md +++ b/content/rancher/v2.x/en/tools/_index.md @@ -2,3 +2,79 @@ title: Rancher Tools weight: 5000 --- + +Rancher contains a variety of tools that aren't included in Kubernetes to assist in your DevOps operations. Rancher can integrate with external services to help your clusters run more efficiently. Tools are divided into four categories: + + + +- [Alerts](#alerts) +- [Notifiers](#notifiers) +- [Logging](#logging) +- [Pipelines](#pipelines) + + + +## Alerts + +To keep your clusters and applications healthy and driving your organizational productivity forward, you need stay informed of events occurring in your clusters, both planned and unplanned. To help you stay informed of these events, Rancher allows you to configure alerts. + +_Alerts_ are sets of rules, chosen by you, to monitor for specific events. The scope for alerts can be set at either the cluster or project level. + +Some examples of alert events are: + +- A Kubernetes [master component]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#kubernetes-cluster-node-components) entering an unhealthy state. +- A node or [workload]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/workloads/) error occurring. +- A scheduled deployment taking place as planned. +- A node's hardware resources becoming overstressed. + +When an event occurs, your alert is triggered, and you are sent a notification. You can then, if necessary, follow up with corrective actions. + +Additionally, you can set an urgency level for each alert. This urgency appears in the notification you receive, helping you to prioritize your response actions. For example, if you have an alert configured to inform you of a routine deployment, no action is required. These alerts can be assigned a low priority level. However, if a deployment fails, it can critically impact your organization, and you need to react quickly. Assign these alerts a high priority level. + +For more information, see [Alerts]({{< baseurl >}}/rancher/v2.x/en/tools/notifiers-and-alerts/#alerts). + +## Notifiers + +Before you can receive alerts, you must configure one or more notifier in Rancher. + +_Notifiers_ are services that inform you of alert events. You can configure notifiers to send alert notifications to staff best suited to take corrective action. Rancher integrates with a variety of popular IT services, including: + +- Slack: Send alert notifications to your Slack channels. +- Email: Choose email recipients for alert notifications. +- PagerDuty: Route notifications to staff by phone, SMS, or personal email. +- Webhooks: Update a webpage with alert notifications. + +For more information, see [Notifiers]({{< baseurl >}}/rancher/v2.x/en/tools/notifiers-and-alerts/#notifiers). + +## Logging + +Rancher can integrate with popular external services used for event streams, telemetry, or search. Rancher can integrate with the following services: + +- Embedded Elasticsearch (experimental) + + >**Note:** This option is available only at the cluster level. + +- Elasticsearch +- splunk +- kafka +- syslog + +These services collect container log events, which are saved to the `/var/log/containers` directory on each of your nodes. The service collects both standard and error events. You can then log into your services to review the events collected, leveraging each service's unique features. + +When configuring Rancher to integrate with these services, you'll have to point Rancher toward the service's endpoint and provide authentication information. Additionally, you'll have the opportunity to enter key value pairs to filter the log events collected. The service will only collect events for containers marked with your configured key value pairs. + +You can configure these services to collect logs at either the cluster or project level. + +## Pipelines + +Using Rancher, you can integrate with a GitHub repository to setup a continuous integration (CI) pipeline. + +To set up a pipeline, you'll first need to authorize Rancher using your GitHub settings. Directions are provided in the Rancher UI. After authorizing Rancher in GitHub, provide Rancher with a client ID and secret to authenticate. + +After configuring Rancher and GitHub, you can deploy containers running Jenkins to automate a pipeline execution: + +- Build your application from code to image. +- Validate your builds. +- Deploy your build images to your cluster. +- Run unit tests. +- Run regression tests. 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 index 1a71e114dde..deec63e0391 100644 --- a/content/rancher/v2.x/en/tools/notifiers-and-alerts/_index.md +++ b/content/rancher/v2.x/en/tools/notifiers-and-alerts/_index.md @@ -1,35 +1,300 @@ --- -title: Notifiers and Alerts +title: Alerts and Notifiers 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 and alerts are two features that work together to inform you of events in the Rancher system. Notifiers are objects that you configure to leverage popular IT services, which send you notification of Rancher events. Alerts are rule sets that trigger when those notifications are sent. + +Notifiers and alerts are built on top of the [Prometheus Alertmanager](https://prometheus.io/docs/alerting/alertmanager/). Leveraging these tools, Rancher can notify [cluster owners]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles) and [project owners]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles) of events they need to address. ## 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. +Before you can receive [alerts](#alerts), you must configure one or more notifier in Rancher. -Available Notifiers: +Notifiers are services that inform you of alert events. You can configure notifiers to send alert notifications to staff best suited to take corrective action. -* Email -* Slack -* PagerDuty -* Webhooks +Notifiers are configured at the cluster level. This model ensures that only cluster owners need to configure notifiers, leaving project owners to simply configure alerts in the scope of their projects. You don't need to dispense privileges like SMTP server access or cloud account access. + +Rancher integrates with a variety of popular IT services, including: + +- **Slack**: Send alert notifications to your Slack channels. +- **Email**: Choose email recipients for alert notifications. +- **PagerDuty**: Route notifications to staff by phone, SMS, or personal email. +- **WebHooks**: Update a webpage with alert notifications. +
+
+ +### Adding Notifiers + +Set up a notifier so that you can begin configuring and sending alerts. + +1. From the **Global View**, open the cluster that you want to add a notifier to. + +1. From the main menu, select **Tools > Notifiers**. Then click **Add Notifier**. + +1. Select the service you want to use as your notifier, and then fill out the form. +{{% accordion id="slack" label="Slack" %}} +1. Enter a **Name** for the notifier. +1. From Slack, create a webhook. For instructions, see the [Slack Documentation](https://get.slack.help/hc/en-us/articles/115005265063-Incoming-WebHooks-for-Slack). +1. From Rancher, enter your Slack webhook **URL**. +1. Enter the name of the channel that you want to send alert notifications in the following format: `#
+
+ +### Managing Notifiers + +After you set up notifiers, you can manage them by selecting **Tools > Notifiers** from the **Global** view. You can: + +- **Edit** their settings that you configured during their initial setup. +- **Clone** them, to quickly setup slightly different notifiers. +- **Delete** them when they're no longer necessary. ## Alerts -Rancher supports alerting on a cluster level or project level. +To keep your clusters and applications healthy and driving your organizational productivity forward, you need to stay informed of events occurring in your clusters and projects, both planned and unplanned. To help you stay informed of these events, you can configure alerts. -On a cluster level, Rancher can monitor and alert on components that manage your Kubernetes cluster including: +Alerts are sets of rules, chosen by you, to monitor for specific events. The scope for alerts can be set at either the cluster or project level. -* System Services -* Resource Events -* Node conditions +### Cluster Alerts vs. Project Alerts -Operators of Kubernetes clusters can get alerts on the health of nodes and other system level components. +At the [cluster level](#adding-cluster-alerts), Rancher monitors components in your Kubernetes cluster, and sends you alerts related to: -On a project level, Rancher can monitor and alert on status on specific deployments including: +- The state of your nodes. +- The system services that manage your Kubernetes cluster. +- The resource events from specific system services. + +At the [project level](#adding-project-alerts), Rancher monitors specific deployments and sends alerts for: * Deployment availability -* Workloads -* Pods +* Workloads status +* Pod status +
+
+ +#### Adding Cluster Alerts + +As a cluster owner, you can configure Rancher to send you alerts for cluster events. + +>**Prerequisite:** Before you can receive cluster alerts, you must [add a notifier](#adding-notifiers). + +1. From the **Global** view, open the cluster that you want to configure alerts for. + +1. From the main menu, select **Tools > Alerts**. Then click **Add Alert**. + +1. Enter a **Name** for the alert that describes its purpose. + +1. Based on the type of alert you want to create, complete one of the instruction subsets below. +{{% accordion id="system-service" label="System Service Alerts" %}} +This alert type monitors for events that affect one of the Kubernetes master components, regardless of the node it occurs on. + +1. Select the **System Services** option, and then select an option from the drop-down. + + - [controller-manager](https://kubernetes.io/docs/concepts/overview/components/#kube-controller-manager) + - [etcd](https://kubernetes.io/docs/concepts/overview/components/#etcd) + - [scheduler](https://kubernetes.io/docs/concepts/overview/components/#kube-scheduler) + +1. Select the urgency level of the of alert. The options are: + + - **Critical**: Most urgent + - **Warning**: Normal urgency + - **Info**: Least urgent +
+
+ Select the urgency level based on the importance of the service and how many nodes fill the role within your cluster. For example, if you're making an alert for the `etcd` service, select **Critical**. If you're making an alert for redundant schedulers, **Warning** is more appropriate. +{{% /accordion %}} +{{% accordion id="resource-event" label="Resource Event Alerts" %}} +This alert type monitors for specific events that are thrown from a resource type. + +1. Choose the type of resource event that triggers an alert. The options are: + + - **Normal**: triggers an alert when any standard resource event occurs. + - **Warning**: triggers an alert when unexpected resource events occur. + +1. Select a resource type from the **Choose a Resource** drop-down that you want to trigger an alert. + + - [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) + - [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) + - [Node](https://kubernetes.io/docs/concepts/architecture/nodes/) + - [Pod](https://kubernetes.io/docs/concepts/workloads/pods/pod/) + - [StatefulSet](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/) + +1. Select the urgency level of the of alert. + + - **Critical**: Most urgent + - **Warning**: Normal urgency + - **Info**: Least urgent +
+
+ Select the urgency level of the alert by considering factors such as how often the event occurs or its importance. For example: + + - If you set a normal alert for pods, you're likely to receive alerts often, and individual pods usually self-heal, so select an urgency of **Info**. + - If you set a warning alert for StatefulSets, its very likely to impact operations, so select an urgency of **Critical**. + + +{{% /accordion %}} +{{% accordion id="node" label="Node Alerts" %}} +This alert type monitors for events that occur on a specific node. + +1. Select the **Node** option, and then make a selection from the **Choose a Node** drop-down. + +1. Choose an event to trigger the alert. + + - **Not Ready**: Sends you an alert when the node is unresponsive. + - **CPU usage over**: Sends you an alert when the node raises above an entered percentage of its processing allocation. + - **Mem usuage over**: Sends you an alert when the node raises above an entered percentage of its memory allocation. + +1. Select the urgency level of the of alert. + + - **Critical**: Most urgent + - **Warning**: Normal urgency + - **Info**: Least urgent +
+
+ Select the urgency level of the alert based on its impact on operations. For example, an alert triggered when a node's CPU raises above 60% deems a urgency of **Info**, but a node that is **Not Ready** deems an urgency of **Critical**. +{{% /accordion %}} +{{% accordion id="node-selector" label="Node Selector Alerts" %}} +This alert type monitors for events that occur on any node on marked with a label. For more information, see the Kubernetes documentation for [Labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/). + +1. Select the **Node Selector** option, and then click **Add Selector** to enter a key value pair for a label. This label should be applied to one or more of your nodes. Add as many selectors as you'd like. + +1. Choose an event to trigger the alert. + + - **Not Ready**: Sends you an alert when selected nodes are unresponsive. + - **CPU usage over**: Sends you an alert when selected nodes raise above an entered percentage of processing allocation. + - **Mem usuage over**: Sends you an alert when selected nodes raise above an entered percentage of memory allocation. + +1. Select the urgency level of the of alert. + + - **Critical**: Most urgent + - **Warning**: Normal urgency + - **Info**: Least urgent +
+
+ Select the urgency level of the alert based on its impact on operations. For example, an alert triggered when a node's CPU raises above 60% deems a urgency of **Info**, but a node that is **Not Ready** deems an urgency of **Critical**. +{{% /accordion %}} +1. Finally, choose the notifiers that send you alerts. + + - You can set up multiple notifiers. + - You can change notifier recipients on the fly. + +**Result:** Your alert is configured. A notification is sent when the alert is triggered. + +#### Managing Cluster Alerts + +After you set up cluster alerts, you can manage each alert object. To manage alerts, browse to the cluster containing the alerts, and then select **Tools > Alerts** that you want to manage. You can: + +- Deactivate/Reactive alerts +- Edit alert settings +- Delete unnecessary alerts + +#### Adding Project Alerts + +>**Prerequisite:** Before you can receive project alerts, you must [add a notifier](#adding-notifiers). + +1. From the **Global** view, open the project that you want to configure alerts for. + +1. From the main menu, select **Resources > Alerts**. Then click **Add Alert**. + +1. Enter a **Name** for the alert that describes its purpose. + +1. Based on the type of alert you want to create, complete one of the instruction subsets below. +{{% accordion id="pod" label="Pod Alerts" %}} +This alert type monitors for the status of a specific pod. + +1. Select the **Pod** option, and then select a pod from the drop-down. +1. Select a pod status that triggers and alert: + + - **Not Running** + - **Not Scheduled** + - **Restarted `
diff --git a/layouts/shortcodes/ports_aws_securitygroup_nodedriver.html b/layouts/shortcodes/ports_aws_securitygroup_nodedriver.html new file mode 100644 index 00000000000..9f45ef205ae --- /dev/null +++ b/layouts/shortcodes/ports_aws_securitygroup_nodedriver.html @@ -0,0 +1,103 @@ +Note:
-The
+rancher/ranchercontainer is hosted on DockerHub. If you don't have access to DockerHub, or you are installing Rancher without an Internet connection, refer to Air Gap Installation.The
rancher/ranchercontainer is hosted on DockerHub. If you don't have access to DockerHub, or you are installing Rancher without an Internet connection, refer to Air Gap Installation.Note:
-For a list of other Rancher Server tags available, refer to Rancher Server Tags.
+For a list of other Rancher Server tags available, refer to Rancher Server Tags.
Amazon EC2 security group when using Node Driver
+If you are Creating an Amazon EC2 Cluster, you can choose to let Rancher create a Security Group called rancher-nodes. The following rules are automatically added to this Security Group.
+
+
+
+
+
+
+
diff --git a/layouts/shortcodes/requirements_os.html b/layouts/shortcodes/requirements_os.html
index 1bdf8e107f2..47f0b8c8339 100644
--- a/layouts/shortcodes/requirements_os.html
+++ b/layouts/shortcodes/requirements_os.html
@@ -2,6 +2,6 @@
Security group: rancher-nodes
+Inbound rules
+| Type | +Protocol | +Port Range | +Source | +
|---|---|---|---|
| SSH | +TCP | +22 | +0.0.0.0/0 | +
| HTTP | +TCP | +80 | +0.0.0.0/0 | +
| Custom TCP Rule | +TCP | +443 | +0.0.0.0/0 | +
| Custom TCP Rule | +TCP | +2376 | +0.0.0.0/0 | +
| Custom TCP Rule | +TCP | +2379-2380 | +sg-xxx (rancher-nodes) | +
| Custom UDP Rule | +UDP | +4789 | +sg-xxx (rancher-nodes) | +
| Custom TCP Rule | +TCP | +6443 | +0.0.0.0/0 | +
| Custom UDP Rule | +UDP | +8472 | +sg-xxx (rancher-nodes) | +
| Custom TCP Rule | +TCP | +10250-10252 | +sg-xxx (rancher-nodes) | +
| Custom TCP Rule | +TCP | +10256 | +sg-xxx (rancher-nodes) | +
| Custom TCP Rule | +TCP | +30000-32767 | +0.0.0.0/0 | +
| Custom UDP Rule | +UDP | +30000-32767 | +0.0.0.0/0 | +
Outbound rules
+| Type | +Protocol | +Port Range | +Destination | +
|---|---|---|---|
| All traffic | +All | +All | +0.0.0.0/0 | +
+
- Ubuntu 16.04 (64-bit)
- Red Hat Enterprise Linux 7.5 (64-bit) -
- RancherOS 1.3.0 (64-bit) +
- RancherOS 1.4 (64-bit)
Add one or more Node Pools to your cluster.
A Node Pool is a collection of nodes based on a Node Template. A Node Template defines the configuration of a Node, like what Operating System image, number of CPUs and amount of RAM. Each Node Pool can have one or more Nodes Roles associated with it.
Add one or more node pools to your cluster.
A node pool is a collection of nodes based on a node template. A node Template defines the configuration of a node, like what Operating System to use, number of CPUs and amount of memory. Each node pool must have one or more nodes roles assigned.
diff --git a/src/img/rancher/cluster-options-yaml.png b/src/img/rancher/cluster-options-yaml.png new file mode 100644 index 00000000000..6259a6f9a34 Binary files /dev/null and b/src/img/rancher/cluster-options-yaml.png differ diff --git a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/globalpermissionfinal.png b/src/img/rancher/globalpermissionfinal.png similarity index 100% rename from content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/globalpermissionfinal.png rename to src/img/rancher/globalpermissionfinal.png diff --git a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/globalpermissionrole.png b/src/img/rancher/globalpermissionrole.png similarity index 100% rename from content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/globalpermissionrole.png rename to src/img/rancher/globalpermissionrole.png diff --git a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/globalpermissionuser.png b/src/img/rancher/globalpermissionuser.png similarity index 100% rename from content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/globalpermissionuser.png rename to src/img/rancher/globalpermissionuser.png diff --git a/src/img/rancher/port-communications.png b/src/img/rancher/port-communications.png index ca1d3356854..f356f6b49b0 100644 Binary files a/src/img/rancher/port-communications.png and b/src/img/rancher/port-communications.png differ diff --git a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/rancherroles1.png b/src/img/rancher/rancherroles1.png similarity index 100% rename from content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/rancherroles1.png rename to src/img/rancher/rancherroles1.png diff --git a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/rancherroles2.png b/src/img/rancher/rancherroles2.png similarity index 100% rename from content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/rancherroles2.png rename to src/img/rancher/rancherroles2.png diff --git a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/rancheruser.png b/src/img/rancher/rancheruser.png similarity index 100% rename from content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/rancheruser.png rename to src/img/rancher/rancheruser.png diff --git a/src/img/rancher/user-settings.png b/src/img/rancher/user-settings.png new file mode 100644 index 00000000000..ca545e752a4 Binary files /dev/null and b/src/img/rancher/user-settings.png differ diff --git a/src/img/rancher/vsphere-cluster-create-1.png b/src/img/rancher/vsphere-cluster-create-1.png new file mode 100644 index 00000000000..35faaf08b30 Binary files /dev/null and b/src/img/rancher/vsphere-cluster-create-1.png differ diff --git a/src/img/rancher/vsphere-node-driver-cloudprovider.png b/src/img/rancher/vsphere-node-driver-cloudprovider.png new file mode 100644 index 00000000000..628d2667c9d Binary files /dev/null and b/src/img/rancher/vsphere-node-driver-cloudprovider.png differ diff --git a/src/img/rancher/vsphere-node-template-1.png b/src/img/rancher/vsphere-node-template-1.png new file mode 100644 index 00000000000..c8e7213a56a Binary files /dev/null and b/src/img/rancher/vsphere-node-template-1.png differ diff --git a/src/img/rancher/vsphere-node-template-2.png b/src/img/rancher/vsphere-node-template-2.png new file mode 100644 index 00000000000..34da41240d2 Binary files /dev/null and b/src/img/rancher/vsphere-node-template-2.png differ diff --git a/src/img/rancher/vsphere-storage-class.png b/src/img/rancher/vsphere-storage-class.png new file mode 100644 index 00000000000..00fa558ea14 Binary files /dev/null and b/src/img/rancher/vsphere-storage-class.png differ diff --git a/src/img/rancher/workload-add-volume.png b/src/img/rancher/workload-add-volume.png new file mode 100644 index 00000000000..d3033b17d14 Binary files /dev/null and b/src/img/rancher/workload-add-volume.png differ diff --git a/src/img/rancher/workload-persistent-data.png b/src/img/rancher/workload-persistent-data.png new file mode 100644 index 00000000000..cb4b6532699 Binary files /dev/null and b/src/img/rancher/workload-persistent-data.png differ diff --git a/src/img/rke/vsphere-advanced-parameters.png b/src/img/rke/vsphere-advanced-parameters.png new file mode 100644 index 00000000000..77c558ffc5d Binary files /dev/null and b/src/img/rke/vsphere-advanced-parameters.png differ diff --git a/src/img/rke/vsphere-nodedriver-enable-uuid.png b/src/img/rke/vsphere-nodedriver-enable-uuid.png new file mode 100644 index 00000000000..58bdbd2e1a3 Binary files /dev/null and b/src/img/rke/vsphere-nodedriver-enable-uuid.png differNotes:
-
- After you create a Node Template, it will be saved and you will be able to re-use it in additional Node Pools.
-- Each Node Role (i.e.
-etcd,Control Plane, andWorker) must be fulfilled. Although it is possible to apply multiple Node Roles to a Node Pool, this is not recommended.- The recommended setup is to have a Node Pool with the
+etcdNode Role and a count of three, a Node Pool with theControl PlaneNode Role and a count of at least two, and a Node Pool with theWorkerNode Role and a count of at least two. Regarding theetcdNode Role, refer to the etcd Admin Guide.- Each node role (i.e.
+etcd,Control Plane, andWorker) should be assigned to a distinct node pool. Although it is possible to assign multiple node roles to a node pool, this should not be done for production clusters.- The recommended setup is to have a node pool with the
etcdnode role and a count of three, a node pool with theControl Planenode role and a count of at least two, and a node pool with theWorkernode role and a count of at least two. Regarding theetcdnode role, refer to the etcd Admin Guide.