public/rancher-docs
1
0
Fork 0
mirror of https://github.com/rancher/rancher-docs.git synced 2026-09-12 12:07:20 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #74 from MBishop17/edits-5-2

Browse Source 
HA Install Edits
This commit is contained in:
Vincent Fiduccia
2018-05-03 14:38:42 -07:00
committed by GitHub
parent 626136e8ef 61340e17cc
commit ca57fa1a18
6 changed files with 411 additions and 329 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/rancher/v2.x/en/_index.md
+45 -29
View File
@@ -13,7 +13,7 @@ Rancher is a container management platform built for organizations that deploy c
### Run Kubernetes Everywhere
Kubernetes has become the container orchestration standard. Most cloud and virtualization vendors now offer it as standard infrastructure. Rancher users have the choice of creating Kubernetes clusters with Rancher Kubernetes Engine (RKE) or cloud Kubernetes services, such as GKE, AKS, and EKS. Rancher users can also import and manage their existing Kubernetes clusters created using any Kubernetes distribution or installer.
Kubernetes is the container orchestration standard. Most cloud and virtualization vendors now offer it as standard infrastructure. Rancher users have the choice of creating Kubernetes clusters with Rancher Kubernetes Engine (RKE) or cloud Kubernetes services, such as Google Kubernetes Engine (GKE), Azure Container Service (AKS), and Amazon Elastic Container Service for Kubernetes (EKS). Rancher users can also import and manage their existing Kubernetes clusters that were created using any Kubernetes distribution or installer.
### Meet IT requirements
@@ -25,18 +25,18 @@ Rancher supports centralized authentication for all Kubernetes clusters under it
### Empower DevOps Teams
Rancher provides an intuitive user interface for DevOps engineers to manage their application workload. The user does not need to have in-depth knowledge of Kubernetes concepts to start using Rancher. Rancher catalog contains a set of useful DevOps tools. Rancher is certified with a wide selection of cloud native ecosystem products, including, for example, security tools, monitoring systems, container registries, and storage and networking drivers.
Rancher provides an intuitive user interface for DevOps engineers to manage their application workload. The user doesn't need in-depth knowledge of Kubernetes to start using Rancher. Rancher catalog contains a set of useful DevOps tools. Rancher is certified with a wide selection of cloud native ecosystem products, including security tools, monitoring systems, container registries, and storage and networking drivers.
The following figure illustrates the role Rancher plays in IT and DevOps organizations. Each team deploys their applications on the public or private clouds they choose. IT administrators gain visibility and enforce policies across all users, clusters, and clouds.
The following figure illustrates Rancher's role in IT and DevOps organizations. Each team deploys their applications on the public or private clouds they choose. IT administrators gain visibility and enforce policies across all users, clusters, and clouds.
![Platform]({{< baseurl >}}/img/rancher/platform.png)
## What's New?
The previous version of Rancher, version 1.6, was a container management platform built on Docker. Rancher 2.0 builds on the success and experience of Rancher 1.6.
The previous version of Rancher, version 1.6, was a container management platform built on Docker. Rancher 2.0 builds on the success and experience of 1.6.
However, for version 2.0, most of Rancher has been redesigned to work on Kubernetes. Rancher 2.0 retains the user-friendly features of version 1.6, such as the UI and catalog. However, 2.0 now includes many new features such as:
However, for version 2.0, most of Rancher is redesigned to work on Kubernetes. 2.0 retains the user-friendly features of 1.6, such as the UI and catalog. However, 2.0 includes many new features such as:
- Built-in CI pipeline
- Alerts and log aggregation
@@ -46,33 +46,37 @@ However, for version 2.0, most of Rancher has been redesigned to work on Kuberne
# Rancher Architecture
Before explaining Rancher architecture, it is useful to present some background information on two fundamental technologies Rancher build on: Docker and Kubernetes.
This section explains how Rancher interacts with the two fundamental technologies Rancher is built on: Docker and Kubernetes.
## Docker
Docker is the de-facto container packaging and runtime standard. Developers build container images from Dockerfiles and distribute container images from Docker registries. Docker Hub (hub.docker.com) is the most popular public registry. Many organizations also setup private Docker registries.
Docker is the container packaging and runtime standard. Developers build container images from Dockerfiles and distribute container images from Docker registries. [Docker Hub](http://hub.docker.com) is the most popular public registry. Many organizations also setup private Docker registries. Docker is primarily used to manage containers on individual nodes.
Docker is primarily used to manage containers on individual nodes. The Docker Swarm clustering technology are not as widely used as Kubernetes. Rancher 1.6 supported Docker Swarm. Rancher 2.0 no longer does.
>**Note:** Although Rancher 1.6 supported Docker Swarm clustering technology, it is no longer supported in Rancher 2.0 due to the success of Kubernetes.
## Kubernetes
Kubernetes is the de-facto container cluster management standard. YAML files specify containers and other resources that form an application. Kubernetes performs functions such as scheduling, scaling, service discovery, health check, secret and configuration management.
Kubernetes is the container cluster management standard. YAML files specify containers and other resources that form an application. Kubernetes performs functions such as scheduling, scaling, service discovery, health check, secret management, and configuration management.
A Kubernetes cluster consists of multiple nodes.
- The etcd database. Although you can run etcd on just one node, it typically takes 3, 5 or more nodes to create an HA configuration.
- **etcd database**
- Master nodes. Master nodes are stateless and are used to run the API server, scheduler, and controllers.
Although you can run etcd on just one node, it typically takes 3, 5 or more nodes to create an HA configuration.
- Worker nodes. Application workload runs on worker nodes.
- **Master nodes**
Master nodes are stateless and are used to run the API server, scheduler, and controllers.
- **Worker nodes**
The application workload runs on worker nodes.
## Rancher
We now cover high-level Rancher architecture.
The majority of Rancher 2.0 software runs on the Rancher Server. Rancher Server includes all the software components used to manage the entire Rancher deployment.
Majority of Rancher 2.0 software runs on the Rancher server. Rancher server includes all the software components used to manage the entire Rancher deployment.
The figure below illustrates the high-level architecture of Rancher 2.0. The figure depicts a Rancher server installation that manages two Kubernetes clusters: one Kubernetes cluster created by RKE and another Kubernetes cluster created by GKE.
The figure below illustrates the high-level architecture of Rancher 2.0. The figure depicts a Rancher Server installation that manages two Kubernetes clusters: one created by RKE and another created by GKE.
![Architecture]({{< baseurl >}}/img/rancher/rancher-architecture.png)
@@ -82,32 +86,44 @@ In this section we describe the functionalities of each Rancher server component
Rancher API server is built on top of an embedded Kubernetes API server and etcd database. It implements the following functionalities:
1. User management. Rancher API server manages user identities that correspond to external authentication providers like Active Directory or GitHub.
- **User Management**
2. Authorization. Rancher API server manages access control and security policies.
Rancher API server manages user identities that correspond to external authentication providers like Active Directory or GitHub.
3. Projects. A project is a grouping of multiple namespaces and access control policies within a cluster.
- **Authorization**
4. Nodes. Rancher API server tracks identities of all the nodes in all clusters.
Rancher API server manages access control and security policies.
- **Projects**
A _project_ is a group of multiple namespaces and access control policies within a cluster.
- **Nodes**
Rancher API server tracks identities of all the nodes in all clusters.
#### Cluster Controller and Agents
The cluster controller and cluster agents implement the business logic required to manage Kubernetes clusters. All the logic that is global to the entire Rancher install is implemented by the cluster controller. A separate cluster agent instance implements the logic required for the corresponding cluster.
The cluster controller and cluster agents implement the business logic required to manage Kubernetes clusters.
Cluster agents perform the following activities:
- The _cluster controller_ implements the logic required for the global Rancher install. It performs the following actions:
- Manage workload. This includes, for example, creating pods and deployments in each cluster.
- Configuration of access control policies to clusters and projects.
- Applying roles and bindings that are defined in global policies into every cluster.
- Provisioning of clusters by calling:
- Propagate information from cluster to rancher server: events, stats, node info, and health.
- The required Docker machine drivers.
- Kubernetes engines like RKE and GKE.
The cluster controller performs the following activities:
- Configures access control policies to clusters and projects.
- A separate _cluster agent_ instance implements the logic required for the corresponding cluster. It performs the following activities:
- Provisions clusters by invoking the necessary Docker machine drivers and invoking Kubernetes engines like RKE and GKE.
- Workload Management, such as pod creation and deployment within each cluster.
- Application of the roles and bindings defined in each cluster's global policies.
- Communication between clusters and Rancher Server: events, stats, node info, and health.
#### Authentication Proxy
The authentication proxy proxies all Kubernetes API calls. It integrates with authentication services like local authentication, Active Directory, and GitHub. On every Kubernetes API call, the authentication proxy authenticates the caller and sets the proper Kubernetes impersonation headers before forwarding the call to Kubernetes masters. Rancher communicates with Kubernetes clusters using a service account.
The _authentication proxy_ forwards all Kubernetes API calls. It integrates with authentication services like local authentication, Active Directory, and GitHub. On every Kubernetes API call, the authentication proxy authenticates the caller and sets the proper Kubernetes impersonation headers before forwarding the call to Kubernetes masters. Rancher communicates with Kubernetes clusters using a service account.
content/rancher/v2.x/en/installation/server-installation/ha-server-install/_index.md
+7 -194
View File
@@ -4,203 +4,16 @@ weight: 275
---
# High Availability Rancher Server Install
You can deploy Rancher in a high-availability (HA) configuration using the Rancher Kubernetes Engine (RKE). RKE is Rancher's own fast and light-weight Kubernetes installer. Use RKE to set up a new cluster that deploys Rancher as an addon.
You have the option of installing Rancher Server in a High-Availability (HA) configuration. This configuration sets up multiple Rancher Servers, which ensure that you can always access Rancher, even when one of your Rancher Servers is down for maintentance.
## Objectives
Install Rancher in an HA configuration using the Rancher Kubernetes Engine (RKE). RKE is Rancher's own fast and light-weight Kubernetes installer. Use RKE to set up a new cluster that deploys Rancher as an addon.
We've broken installation of Rancher by Kubernetes into a series of smaller tasks. Here's what you'll do during your RKE install.
Complete one of the following procedures to install Rancher in an HA configuration:
1. [Provision Linux Hosts](#provision-linux-hosts)
- [SSL Passthrough]({{< baseurl >}}/rancher/v2.x/en/installation/server-installation/ha-server-install/ssl-passthrough/)
Begin by provisioning Linux hosts or an existing Kubernetes cluster. Make sure your hosts meet Rancher requirements.
In this scenario, your High-Availability Rancher Servers handle SSL decryption rather than a Load Balancer.
2. [Get RKE](#get-rke)
- [SSL Termination]({{< baseurl >}}/rancher/v2.x/en/installation/server-installation/ha-server-install/ssl-termination/)
Download the RKE installer from GitHub.
3. [Get YAML Template](#get-yaml-template)
During installation, the RKE uses a `.yml` config file containing specifications for your cluster. You'll have to configure this file. We have a variety of config file templates available for download.
4. [Edit YAML Template](#edit-yaml-template)
After you download a config file template, edit it according to how you want to configure Rancher and your Kubernetes cluster.
5. [Run RKE](#run-rke)
Finally, run the RKE installer with it pointing toward your config file.
### Provision Linux Hosts
Before you install Rancher, confirm you meet the requirements. Provision a minimum of three new Linux hosts using the requirements below.
#### Requirements
{{< requirements_os >}}
{{< requirements_hardware >}}
{{< requirements_software >}}
{{< requirements_ports >}}
{{< requirements_ha >}}
### Get RKE
Rancher Kubernetes Engine (RKE) is a fast, versatile Kubernetes installer you can use to install Kubernetes on your Linux hosts. You can download RKE from GitHub.
1. From your workstation, open a web browser and navigate to [https://github.com/rancher/rke/releases](https://github.com/rancher/rke/releases). Download the latest RKE installer.
2. Make the RKE binary that you just downloaded executable. Open Terminal, change directory to the location of the RKE binary, and then run the following command:
```
$ chmod +x rke
```
>**Note:** adjust the command for the version of RKE that you downloaded (e.g., `rke_darwin-amd64`)
3. Confirm that RKE is now executable by running the following command:
```
$ ./rke -version
```
**Result:** You receive output similar to what follows:
```
rke version v<N.N.N>
```
### Get YAML Template
During installation, RKE uses a `.yml` config file to install and configure your Kubernetes cluster. Download the `.zip` file of `.yml` templates linked below to get you started. Choose a template based on how many nodes are in your cluster and the type of certificate you plan on using:
- If you want to use Auto-Generated Self-Signed Certifcates (i.e. SSL passthrough), use one of the `passthough` templates.
- If you want to use your own certificate (either CA- or Self-Signed), use one of the `certificate` templates.
[Download YAML Config Templates](https://gist.github.com/MBishop17/ca4691a1b126a93bf8f21bc15d44ce02)
### Edit YAML Template
Once you have a template, customize it to suit your needs.
1. Open the `.yml` file that you just downloaded.
2. Update the `nodes` section with your [Linux hosts](#provision-linux-hosts).
1. For each node in your cluster, update the following placeholders:
- `<IP>`: The IP address or hostname of the node.
- `<USER>`: The node root user (usually `root`).
- `<PEM_FILE>`: The path of the `.pem` file used to authenticate.
2. For each node in your cluster, choose what roles each node should fill. Delete any roles that aren't needed on the node.
**Example YAML**
nodes:
- address: <IP> # IP to access nodes
user: <USER> # root user (usually 'root')
role: [controlplane,etcd,worker] # K8s roles for node
ssh_key_path: <PEM_FILE> # path to PEM file
- address: <IP>
user: <USER>
role: [controlplane,etcd,worker]
ssh_key_path: <PEM_FILE>
- address: <IP>
user: <USER>
role: [controlplane,etcd,worker]
ssh_key_path: <PEM_FILE>
3. Scroll to `kind: Ingress`. Replace the two `<FQDN>` placeholders with the FQDN mapped to each IP address for `controlplane` and/or `worker` nodes on your DNS. On your DNS Server, each node should be added to the DNS entry for the FQDN.
**Example YAML**
spec:
rules:
- host: <FQDN> # FQDN to access cattle server
http:
paths:
- backend:
serviceName: cattle-service
servicePort: 80
tls:
- secretName: cattle-keys-ingress
hosts:
- <FQDN> # FQDN to access cattle server
>**Using Auto-Generated Self-Signed Certificates?**
>
>The next two steps don't apply to you. Save the `.yml` config file and continue to [Run RKE](#run-rke).
4. **Bring Your Own Certificate only:** Scroll to the codeblock that follows.
```
apiVersion: v1
kind: Secret
metadata:
name: cattle-keys-server
namespace: cattle-system
type: Opaque
data:
cert.pem: <BASE64_CRT> # ssl cert for cattle server.
key.pem: <BASE64_KEY> # ssl key for cattle server.
cacerts.pem: <BASE64_CA> # CA cert used to sign cattle server cert and key
```
Replace each placeholder with the applicable `.pem`.
- `<BASE64_CRT>`
- `<BASE64_KEY>`
- `<BASE64_CA>`
>**Important:**
>
> - Each `.pem` must be in base-64: `cat <PEM_FILE> | base64`
> - If you're using a self-signed certificate, the `cattle-keys-server` in this step and `cattle-keys-ingress` in the next step must use certificates and keys signed by the same CA.
5. **Bring Your Own Certificate only:** Scroll to the codeblock that follows.
```
apiVersion: v1
kind: Secret
metadata:
name: cattle-keys-ingress
namespace: cattle-system
type: Opaque
data:
tls.crt: <BASE64_CRT> # ssl cert for ingress. If selfsigned, must be signed by same CA as cattle server
tls.key: <BASE64_KEY> # ssl key for ingress. If selfsigned, must be signed by same CA as cattle server
```
Replace each placeholder with the applicable `.pem`.
- `<BASE64_CRT>`
- `<BASE64_KEY>`
>**Reminder:**
>
> - Each `.pem` must be in base-64: `cat <PEM_FILE> | base64`
> If you're using a self-signed certificate, the `cattle-keys-server` from last step and `cattle-keys-ingress` from this step must use certificates and keys signed by the same CA.
6. Save the `.yml` file and close it.
### Run RKE
Enter the command to run RKE while pointing to your `.yml` file. RKE will install Kubernetes and Rancher using your parameters.
1. From your workstation, make sure your `.yml` config file and RKE are in the same directory.
2. Open a Terminal instance. Change to the directory that contains your config file and RKE.
3. Enter the following command, replacing the placeholder name with the name of the `.yml` config template that you used.
```
rke up --config <YAML_TEMPLATE>
```
### What's Next?
Log in to Rancher to make sure it deployed successfully. Open a web browser and navigate to the FQDN used earlier in this procedure.
In this scenario, your Load Balancer handles all SSL encryption, and then forwards on the communication within your Kubernetes cluster unencrypted.
content/rancher/v2.x/en/installation/server-installation/ha-server-install/ssl-passthrough/_index.md
+143
View File
@@ -0,0 +1,143 @@
---
title: SSL Passthrough
weight: 275
---
# High Availability Install with SSL Passthrough
In this scenario, your High-Availability Rancher Servers handle SSL decryption rather than a Load Balancer.
## Objectives
We've broken installation of Rancher with SSL passthrough into a series of smaller tasks. Here's what you'll do during install.
1. [Provision Linux Hosts](#provision-linux-hosts)
Begin by provisioning Linux hosts. Make sure your hosts meet Rancher requirements.
2. [Get RKE](#get-rke)
Download the Rancher Kubernetes Engine (RKE) installer from GitHub.
3. [Get YAML Config File Template](#get-yaml-template)
During installation, RKE uses a `.yml` config file containing specifications for your cluster. Download our template from GitHub.
4. [Edit YAML Config File Template](#edit-yaml-template)
Edit the `.yml` config file so that it's pointing toward your Linux hosts.
5. [Run RKE](#run-rke)
Finally, run the RKE installer with it pointing toward your `.yml` config file.
### Provision Linux Hosts
Before you install Rancher, confirm you meet the requirements. Provision three new Linux hosts using the requirements below.
#### Requirements
{{< requirements_os >}}
{{< requirements_hardware >}}
{{< requirements_software >}}
{{< requirements_ports >}}
### Get RKE
Rancher Kubernetes Engine (RKE) is a fast, versatile Kubernetes installer that you can use to install Kubernetes on your Linux hosts. You can download RKE from GitHub.
1. From your workstation, open a web browser and navigate to our [RKE Releases](https://github.com/rancher/rke/releases) page. Download the latest RKE installer.
2. Make the RKE binary that you just downloaded executable. Open Terminal, change directory to the location of the RKE binary, and then run the following command:
```
$ chmod +x rke
```
>**Note:** Adjust the command for the version of RKE that you downloaded (e.g., `rke_darwin-amd64`)
3. Confirm that RKE is now executable by running the following command:
```
$ ./rke -version
```
**Result:** You receive output similar to what follows:
```
rke version v<N.N.N>
```
### Get YAML Config File Template
During installation, RKE uses a `.yml` config file to install and configure your Kubernetes cluster. Download the `3-node-passthrough.yml` config file linked below to get you started.
[Download SSL Passthrough YAML Config Template](https://github.com/rancher/rancher/tree/master/rke-templates)
### Edit YAML Template
Once you have `3-node-passthrough.yml`, edit the nodes section to point toward your Linux hosts.
1. Open `3-node-passthrough.yml`, which you just downloaded.
2. Update the `nodes` section with your [Linux hosts](#provision-linux-hosts).
For each node in your cluster, update the following placeholders:
- `<IP>`: The IP address or hostname of the node.
- `<USER>`: The node root user (usually `root`).
- `<PEM_FILE>`: The path of the `.pem` file used to authenticate.
**Example YAML**
nodes:
- address: <IP> # IP to access nodes
user: <USER> # root user (usually 'root')
role: [controlplane,etcd,worker] # K8s roles for node
ssh_key_path: <PEM_FILE> # path to PEM file
- address: <IP>
user: <USER>
role: [controlplane,etcd,worker]
ssh_key_path: <PEM_FILE>
- address: <IP>
user: <USER>
role: [controlplane,etcd,worker]
ssh_key_path: <PEM_FILE>
3. Scroll to `kind: Ingress`. Replace the two `<FQDN>` placeholders with the FQDN mapped to each of your nodes. On your DNS Server, each node should be added to the DNS entry for the FQDN.
**Example YAML**
spec:
rules:
- host: <FQDN> # FQDN to access cattle server
http:
paths:
- backend:
serviceName: cattle-service
servicePort: 80
tls:
- secretName: cattle-keys-ingress
hosts:
- <FQDN> # FQDN to access cattle server
6. Save the `.yml` config file and close it.
### Run RKE
Enter the command to run RKE while pointing to `3-node-passthrough.yml`. RKE installs Kubernetes and Rancher using your parameters.
1. From your workstation, make sure `3-node-passthrough.yml` and RKE are in the same directory.
2. Open a Terminal instance. Change to the directory that contains `3-node-passthrough.yml` and RKE.
3. Enter the following command.
```
rke up --config `3-node-passthrough.yml`
```
### What's Next?
Log in to Rancher to make sure it deployed successfully. Open a web browser and navigate to the FQDN used earlier in this procedure.
content/rancher/v2.x/en/installation/server-installation/ha-server-install/ssl-termination/_index.md
+203
View File
@@ -0,0 +1,203 @@
---
title: SSL Termination
weight: 275
---
# High Availability Install with SSL Temination
In this scenario, your Load Balancer handles all SSL decryption, and then forwards the decrypted communications to your cluster.
## Objectives
We've broken installation of Rancher with SSL termination into a series of smaller tasks. Here's what you'll do during your install.
1. [Provision Linux Hosts](#provision-linux-hosts)
Begin by provisioning Linux hosts. Make sure your hosts meet Rancher requirements.
2. [Get RKE](#get-rke)
Download the Rancher Kubernetes Engine (RKE) installer from GitHub.
3. [Get YAML Template](#get-yaml-template)
During installation, RKE uses a `.yml` config file containing specifications for your cluster. Download our template from GitHub.
4. [Edit YAML Template](#edit-yaml-template)
Edit the `.yml` config file so that it's pointing toward your Linux hosts.
5. [Run RKE](#run-rke)
Finally, run the RKE installer with it pointing toward your `.yml` config file.
### Provision Linux Hosts
Before you install Rancher, confirm you meet the requirements. Provision three new Linux hosts using the requirements below.
#### Requirements
{{< requirements_os >}}
{{< requirements_hardware >}}
{{< requirements_software >}}
{{< requirements_ports >}}
##### Certificate Requirements
Before starting this procedure, you should generate or obtain your own certificate.
The certificate can either be:
- Self-signed
- Signed by a certificate authority (CA)
>**Note:**
>-If you use a self-signed certificate, all certificates and keys must be signed by the same CA.<br/>
>-Each `.pem` must be in base-64: `cat <PEM_FILE> | base64`.
### Get RKE
Rancher Kubernetes Engine (RKE) is a fast, versatile Kubernetes installer that you can use to install Kubernetes on your Linux hosts. You can download RKE from GitHub.
1. From your workstation, open a web browser and navigate to our [RKE Releases](https://github.com/rancher/rke/releases) page. Download the latest RKE installer.
2. Make the RKE binary that you just downloaded executable. Open Terminal, change directory to the location of the RKE binary, and then run the following command:
```
$ chmod +x rke
```
>**Note:** Adjust the command for the version of RKE that you downloaded (e.g., `rke_darwin-amd64`)
3. Confirm that RKE is now executable by running the following command:
```
$ ./rke -version
```
**Result:** You receive output similar to what follows:
```
rke version v<N.N.N>
```
### Get YAML Template
During installation, RKE uses a `.yml` config file to install and configure your Kubernetes cluster. Download the `3-node-certificate.yml` config file linked below to get you started.
[Download 3-node-certificate.yml](https://github.com/rancher/rancher/tree/master/rke-templates)
### Edit YAML Template
Once you have the `.yml` config file template, edit the nodes section to point toward your Linux hosts.
1. Open `3-node-certificate.yml`, which you just downloaded.
2. Update the `nodes` section with your [Linux hosts](#provision-linux-hosts).
For each node in your cluster, update the following placeholders:
- `<IP>`: The IP address or hostname of the node.
- `<USER>`: The node root user (usually `root`).
- `<PEM_FILE>`: The path of the `.pem` file used to authenticate.
**Example YAML**
nodes:
- address: <IP> # IP to access nodes
user: <USER> # root user (usually 'root')
role: [controlplane,etcd,worker] # K8s roles for node
ssh_key_path: <PEM_FILE> # path to PEM file
- address: <IP>
user: <USER>
role: [controlplane,etcd,worker]
ssh_key_path: <PEM_FILE>
- address: <IP>
user: <USER>
role: [controlplane,etcd,worker]
ssh_key_path: <PEM_FILE>
3. Scroll to `kind: Ingress`. Replace the two `<FQDN>` placeholders with the FQDN mapped to each of your nodes. On your DNS Server, each node should be added to the DNS entry for the FQDN.
**Example YAML**
spec:
rules:
- host: <FQDN> # FQDN to access cattle server
http:
paths:
- backend:
serviceName: cattle-service
servicePort: 80
tls:
- secretName: cattle-keys-ingress
hosts:
- <FQDN> # FQDN to access cattle server
4. Scroll to the codeblock that follows.
```
apiVersion: v1
kind: Secret
metadata:
name: cattle-keys-server
namespace: cattle-system
type: Opaque
data:
cert.pem: <BASE64_CRT> # ssl cert for cattle server.
key.pem: <BASE64_KEY> # ssl key for cattle server.
cacerts.pem: <BASE64_CA> # CA cert used to sign cattle server cert and key
```
Replace each placeholder with the applicable certificate `.pem`.
- `<BASE64_CRT>`
- `<BASE64_KEY>`
- `<BASE64_CA>`
>**Reminder:** Each `.pem` must be in base-64: `cat <PEM_FILE> | base64`.
5. Scroll to the codeblock that follows.
```
apiVersion: v1
kind: Secret
metadata:
name: cattle-keys-ingress
namespace: cattle-system
type: Opaque
data:
tls.crt: <BASE64_CRT> # ssl cert for ingress. If self-signed, must be signed by same CA as cattle server
tls.key: <BASE64_KEY> # ssl key for ingress. If self-signed, must be signed by same CA as cattle server
```
Replace each placeholder with the applicable `.pem`.
- `<BASE64_CRT>`
- `<BASE64_KEY>`
>**Reminder:** Each `.pem` must be in base-64: `cat <PEM_FILE> | base64`.
6. Save the `.yml` file and close it.
### Run RKE
Enter the command to run RKE while pointing to `3-node-certificate.yml`. RKE installs Kubernetes and Rancher using your parameters.
1. From your workstation, make sure `3-node-certificate.yml` and RKE are in the same directory.
2. Open a Terminal instance. Change to the directory that contains `3-node-certificate.yml` and RKE.
3. Enter the following command.
```
rke up --config 3-node-certificate.yml
```
### What's Next?
Log in to Rancher to make sure it deployed successfully. Open a web browser and navigate to the FQDN used earlier in this procedure.
layouts/shortcodes/requirements_ports.html
+12 -105
View File
@@ -1,11 +1,11 @@
<div>
<h5>Port Requirements</h5>
<h6>Master Nodes (etcd and controlplane nodes)</h6>
<p>Open the following ports on your Linux hosts.</p>
<table>
<tr>
<th>protocol</th>
<th>port range</th>
<th>purpose</th>
<th>Protocol</th>
<th>Port range</th>
<th>Purpose</th>
</tr>
<tr>
<td>tcp</td>
@@ -15,12 +15,12 @@
<tr>
<td>tcp</td>
<td>80</td>
<td>Rancher Server</td>
<td>Rancher Server/ingress</td>
</tr>
<tr>
<td>tcp</td>
<td>443</td>
<td>Rancher Server</td>
<td>Rancher Server/ingress</td>
</tr>
<tr>
<td>tcp</td>
@@ -34,112 +34,19 @@
</tr>
<tr>
<td>tcp</td>
<td>10250</td>
<td>kubelet api</td>
<td>10250-10256</td>
<td>kubernetes components</td>
</tr>
<tr>
<td>tcp</td>
<td>10251</td>
<td>scheduler</td>
</tr>
<tr>
<td>tcp</td>
<td>10252</td>
<td>kube-controller-manager</td>
</tr>
<tr>
<td>tcp</td>
<td>10253</td>
<td>federation</td>
</tr>
<tr>
<td>tcp</td>
<td>10254</td>
<td>ingress</td>
</tr>
<tr>
<td>tcp</td>
<td>10255</td>
<td>read-only kubelet api</td>
</tr>
<tr>
<td>tcp</td>
<td>10256</td>
<td>kubeproxy</td>
</tr>
<td>tcp</td>
<td>30000-32767</td>
<td>nodeport services</td>
</tr>
<tr>
<td>udp</td>
<td>8472</td>
<td>canal</td>
</tr>
</table>
<h6>Worker Nodes</h6>
<table>
<tr>
<th>protocol</th>
<th>port range</th>
<th>purpose</th>
</tr>
<tr>
<td>tcp</td>
<td>22</td>
<td>ssh server</td>
</tr>
<tr>
<td>tcp</td>
<td>80</td>
<td>ingress</td>
</tr>
<tr>
<td>tcp</td>
<td>443</td>
<td>ingress</td>
</tr>
<tr>
<td>tcp</td>
<td>10250</td>
<td>kubelet api</td>
</tr>
<tr>
<td>tcp</td>
<td>10251</td>
<td>scheduler</td>
</tr>
<tr>
<td>tcp</td>
<td>10252</td>
<td>kube-controller-manager</td>
</tr>
<tr>
<td>tcp</td>
<td>10253</td>
<td>federation</td>
</tr>
<tr>
<td>tcp</td>
<td>10254</td>
<td>ingress</td>
</tr>
<tr>
<td>tcp</td>
<td>10255</td>
<td>read-only kubelet api</td>
</tr>
<tr>
<td>tcp</td>
<td>10256</td>
<td>kubeproxy</td>
</tr>
<tr>
<td>tcp</td>
<td>30000-32767</td>
<td>nodeport services</td>
</tr>
<tr>
<td>udp</td>
<td>8472</td>
<td>canal</td>
</tr>
</table>
<br/>
</div>
layouts/shortcodes/requirements_software.html
+1 -1
View File
@@ -1,5 +1,5 @@
<div>
<h4>Software Requestions</h4>
<h4>Software Requirements</h4>
<ul>
<li>
<p>Docker</p>