mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-06-01 09:35:34 +00:00
fixed architecture topic
This commit is contained in:
Mark Bishop
Mark Bishop
@@ -10,7 +10,7 @@ weight: 1
|
||||
|
||||
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.
|
||||
|
||||
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. 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:
|
||||
|
||||
- Built-in CI pipeline
|
||||
- Alerts and log aggregation
|
||||
|
||||
@@ -9,7 +9,7 @@ weight: 1
|
||||
|
||||
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.
|
||||
|
||||
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. 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:
|
||||
|
||||
- Built-in CI pipeline
|
||||
- Alerts and log aggregation
|
||||
|
||||
@@ -2,35 +2,40 @@
|
||||
title: Architecture
|
||||
weight: 1
|
||||
---
|
||||
# Rancher Architecture
|
||||
|
||||
Before explaining Rancher architecture, it is useful to present some background information on two fundamental technologies Rancher build on: Docker and Kubernetes.
|
||||
## Rancher Architecture
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
@@ -40,32 +45,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.
|
||||
|
||||
@@ -17,26 +17,33 @@ Howdy Partner! This tutorial walks you through:
|
||||
|
||||
This Quick Start Guide is divided into different tasks for easier consumption.
|
||||
|
||||
1. [Provision a Linux Host](#provision-a-linux-host) <br/>
|
||||
Begin by provisioning a Linux host.
|
||||
1. [Provision a Linux Host](#provision-a-linux-host)
|
||||
|
||||
2. [Install Rancher](#install-rancher) <br/>
|
||||
From your Linux host, run the Docker command for installing Rancher.
|
||||
Begin by provisioning a Linux host.
|
||||
|
||||
3. [Log In](#log-in) <br/>
|
||||
Browse to your Linux host to access the Rancher UI.
|
||||
2. [Install Rancher](#install-rancher)
|
||||
|
||||
4. [Create the Cluster](#create-the-cluster) <br/>
|
||||
Use the versatile **Custom** option to clone your Linux host into a new Kubernetes cluster.
|
||||
From your Linux host, run the Docker command for installing Rancher.
|
||||
|
||||
5. [Deploy a Workload](#deploy-a-workload) <br/>
|
||||
Create a workload so that Kubernetes can distribute Nginx among your cluster nodes.
|
||||
3. [Log In](#log-in)
|
||||
|
||||
6. [View Your Application](#view-your-application) <br/>
|
||||
When your workload finishes deployment, browse to your node IP to make sure Nginx is running.
|
||||
Browse to your Linux host to access the Rancher UI.
|
||||
|
||||
7. [What's Next?](#whats-next) <br/>
|
||||
Now that you've created a cluster and deployed Nginx, find out what else you can do with Rancher v2.0.
|
||||
4. [Create the Cluster](#create-the-cluster)
|
||||
|
||||
Use the versatile **Custom** option to clone your Linux host into a new Kubernetes cluster.
|
||||
|
||||
5. [Deploy a Workload](#deploy-a-workload)
|
||||
|
||||
Create a workload so that Kubernetes can distribute Nginx among your cluster nodes.
|
||||
|
||||
6. [View Your Application](#view-your-application)
|
||||
|
||||
When your workload finishes deployment, browse to your node IP to make sure Nginx is running.
|
||||
|
||||
7. [What's Next?](#whats-next)
|
||||
|
||||
Now that you've created a cluster and deployed Nginx, find out what else you can do with Rancher v2.0.
|
||||
|
||||
## Provision a Linux Host
|
||||
|
||||
@@ -46,7 +53,7 @@ This Quick Start Guide is divided into different tasks for easier consumption.
|
||||
- An on-premise VM
|
||||
- A bare-metal server
|
||||
|
||||
>**Note**
|
||||
>**Note:**
|
||||
> When using a cloud-host 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.
|
||||
|
||||
### Provision the host according to the requirements below.
|
||||
@@ -69,8 +76,8 @@ This Quick Start Guide is divided into different tasks for easier consumption.
|
||||
|
||||
>**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.
|
||||
> - For Docker installation instructions, visit their [documentation](https://docs.docker.com/install/).
|
||||
> - Docker requirements apply to both your Linux host and your cluster nodes.
|
||||
|
||||
### Install Rancher
|
||||
|
||||
@@ -84,7 +91,7 @@ To install Rancher on your host, connect to it and then use a shell to install.
|
||||
$ sudo docker run -d --restart=unless-stopped -p 80:80 -p 443:443 rancher/rancher
|
||||
```
|
||||
|
||||
**Result: Rancher is installed.**
|
||||
**Result:** Rancher is installed.
|
||||
|
||||
### Log In
|
||||
|
||||
@@ -105,25 +112,25 @@ In this task, you can use the versatile **Custom** option. This option lets you
|
||||
|
||||
1. From the **Clusters** page, click **Add Cluster**.
|
||||
|
||||
1. Choose **Custom**.
|
||||
2. Choose **Custom**.
|
||||
|
||||
1. Enter a **Cluster Name**.
|
||||
3. Enter a **Cluster Name**.
|
||||
|
||||
1. Skip **Member Roles** and **Cluster Options**. We'll tell you about them later.
|
||||
4. Skip **Member Roles** and **Cluster Options**. We'll tell you about them later.
|
||||
|
||||
1. Click **Next**.
|
||||
5. Click **Next**.
|
||||
|
||||
1. From **Node Role**, select _all_ the roles: **etcd**, **Control**, and **Worker**.
|
||||
6. From **Node Role**, select _all_ the roles: **etcd**, **Control**, and **Worker**.
|
||||
|
||||
1. Rancher will auto-detect 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.
|
||||
7. Rancher will auto-detect 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.
|
||||
|
||||
1. Skip the **Labels** stuff. It's not important for now.
|
||||
8. Skip the **Labels** stuff. It's not important for now.
|
||||
|
||||
1. Copy the command displayed on screen to your clipboard.
|
||||
9. Copy the command displayed on screen to your clipboard.
|
||||
|
||||
1. 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.
|
||||
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.
|
||||
|
||||
1. When you finish running the command on your Linux host, click **Done**.
|
||||
11. When you finish running the command on your Linux host, click **Done**.
|
||||
|
||||
{{< result_create-cluster >}}
|
||||
|
||||
@@ -141,7 +148,7 @@ For this workload, you'll be deploying the application Nginx.
|
||||
|
||||
4. Click **+ Deploy**.
|
||||
|
||||
**Step Result:** The **Deploy Workload** page opens.
|
||||
**Step Result:** The **Deploy Workload** page opens.
|
||||
|
||||
5. Enter a **Name** for your workload.
|
||||
|
||||
@@ -150,13 +157,16 @@ For this workload, you'll be deploying the application Nginx.
|
||||
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.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user