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

Merge pull request #50 from MBishop17/config-files

Browse Source 
Config files
This commit is contained in:
Vincent Fiduccia
2018-04-29 17:15:02 -07:00
committed by GitHub
parent 1f2dcb9a65 2618601fff
commit b9c0ebfe36
17 changed files with 1240 additions and 542 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/rancher/concepts/clusters/_index.md
+54 -6
View File
@@ -2,18 +2,15 @@
title: Clusters
weight: 2100
---
# Clusters
Coming Soon
## What's a Cluster?
Coming Soon
A cluster is a group of computing resources that work as a team to accomplish a goal. Each individual computer in a cluster is called a _node_.
## Cluster Creation
Coming Soon
Rancher simplifies creation of Kubernetes clusters by allowing you to create them with the Rancher UI rather than a config file.
### Node Components
@@ -45,6 +42,57 @@ Rancher integrates with cloud APIs so users can provision GKE, EKS, and AKS clus
Users can existing Kubernetes cluster into Rancher. Rancher does not automate the provisioning, scaling, and upgrade of imported Kubernetes clusters. All other cluster management, policy management, and workload management capabilities of Rancher apply to imported clustered.
##### RKE and Amazon AWS EC2: Adding Hosts
When setting up a custom cluster configured to run with an AWS cloud provider, any hosts you add to the cluster:
- Must be an AWS EC2 instance.
- Must have the following IAM policy at minimum:
```
{
"Effect": "Allow",
"Action": "ec2:Describe*",
"Resource": "*"
}
```
In order to use Amazon Elastic Load Balancers (ELBs) and EBS with Kubernetes, the host requires the IAM role with appropriate access.
**Example Policy for IAM Role**
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:Describe*",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "ec2:AttachVolume",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "ec2:DetachVolume",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": ["ec2:*"],
"Resource": ["*"]
},
{
"Effect": "Allow",
"Action": ["elasticloadbalancing:*"],
"Resource": ["*"]
}
]
}
```
### Kubeconfig File
Coming Soon
Coming Soon!
content/rancher/concepts/global-configuration/_index.md
+46 -15
View File
@@ -5,48 +5,79 @@ weight: 2075
# Global Configuration
Coming Soon
After installing Rancher 2.0, you should configure it to support your users and environment. This section describes the global configurations you should make after installation.
## Authentication
# Authentication
Coming Soon
One of the key features that Rancher adds to Kubernetes is centralized user authentication. This feature allows your users to use one set of credentials to authenticate with any of your Kubernetes clusters.
### External vs. Local Authentication
This centralized user authentication is accomplished using the Rancher authentication proxy, which is installed with the rest of Rancher. This proxy authenticates your users and forwards their requests to your Kubernetes clusters using a service account.
Coming Soon
## External vs. Local Authentication
The Rancher authentication proxy integrates with the following external authentication services.
- Microsoft Active Directory
- GitHub
However, Rancher also provides local authentication.
In most cases, you should use an external authentication service over local, as external authentication allows user management from a central location. However, you may want a few local authentication accounts for managing Rancher under rare circumstances, such as if Active Directory is down.
## Users and Roles
Coming Soon
Within Rancher, each user autheticates as a _user_, which is an object that grants you access within the Rancher system. As mentioned in the previous sections, users can either be local or external.
Once the user logs in to Rancher, their _authorization_, or their access rights within the system, are determined by _roles_. Roles are sets of permissions that the user can perform in Rancher
There are two types of roles in Rancher: default roles and custom roles.
### Default Roles
Coming Soon
Out-of-the-box, Rancher comes with two default roles:
- **Administrator:**
These users have full control over the entire Rancher system and all clusters within it.
- **Standard User:**
These users can create new clusters or manage clusters and projects that an administrator has given them access to.
### Custom Roles
Coming Soon
Rancher lets you create _custom roles_ that let you assing individual permissions to a user. These roles are convenient for defining narrow or specialized persmissions to user within Rancher.
### Membership
Coming Soon
The projects and clusters accessible to a standard or custom users is determined by _membership_. Membership is a list of users who have access to a specific project or cluster. Each project and cluster includes a tab that Rancher administrators can use to assign membership.
Non-administrative users do not have access to any existing projects/clusters by default. An administrator must explicitly assign the user membership.
## Rancher Server URL
Coming Soon
This is the URL of your Rancher Server. All nodes in your cluster must resolve to this URL.
- You are prompted for this URL upon the very first Rancher login.
- You can edit this URL later by selecting **Settings**.
## Pod Security Policies
Coming Soon
_Pod Security Policies_ are objects that control security-sensitive aspects of pod specification. Pods only run within Kubernetes if they meet the conditions specified in their assigned Pod Security Policy.
### Best Practice: Set Pod Security as Cluster Level
Read more about Pod Security Policies in the [Kubernetes Documentation](https://kubernetes.io/docs/concepts/policy/pod-security-policy/).
Coming Soon
>**Best Practice:**
>Set Pod Security at the cluster level.
## Node Drivers
Coming Soon
Out-of-the-box, Rancher provides support for creating clusters using many popular cloud providers: Amazon EC2, Azure, DigitalOcean, and so on. However, you may want to create a cluster using another cloud provider. In these scenarios, you can create a custom node driver for the cloud provider and point Rancher toward it.
For more information on creating node drivers, see [https://github.com/rancher/ui-driver-skel](https://github.com/rancher/ui-driver-skel).
## Node Templates
Coming Soon
You can create new clusters within Rancher using _node templates_. A node template is a virtual machine image used to create a Kubernetes cluster. While creating a cluster, Rancher will prompt you for an image to use as a template. Follow the directions on screen to create the template. During cluster creation, Rancher clones the template and installs different Kubernettes components.
After you add a node template to Rancher, its stored by the system so that you can use it when creating another cluster later. Node templates are bound to your login. After you add a template, you can remove them from your user profile.
content/rancher/concepts/projects/_index.md
+6 -3
View File
@@ -7,15 +7,18 @@ weight: 2150
## What's a Project?
Project is a new concept introduced by Rancher. It is not a native Kubernetes construct. A project captures a set of policies for a set of namespaces. A user can be assigned a specific role in a project. A role can be owner, member, read-only, or custom. Policies include Kubernetes Role-Based Access Control (RBAC) policies and pod security policies. Rancher 2.0 also implements a canned network policy that isolated containers in different projects. Future version of Rancher will implement more flexible network policies.
Project is a new concept introduced by Rancher. It is not a native Kubernetes construct. A project captures a set of policies for a set of namespaces. A user can be assigned a specific role in a project. A role can be owner, member, read-only, or custom. Policies include Kubernetes Role-Based Access Control (RBAC) policies and pod security policies. Rancher 2.0 also implements a canned network policy that isolates containers in different projects. Future versions of Rancher will implement more flexible network policies.
### Authorization
Coming Soon
Non-administrative users are only authorized for project access after an administrator explicitly adds them to the project's **Members** tab.
>**Exception:**
> Non-administrative users can access projects that they create themselves.
### Pod Security Policies
Coming Soon
Rancher extends Kubernetes to allow the application of [Pod Sercurity Policies](https://kubernetes.io/docs/concepts/policy/pod-security-policy/) at the project level in additiona to the cluster level. However, as a best practice, we recommend applying Pod Security Policies at the cluster level.
## Namespaces
content/rancher/installation/server-installation/kubernetes-install.md
-217
View File
File diff suppressed because one or more lines are too long
content/rancher/installation/server-installation/rke-install.md
+223
View File
@@ -0,0 +1,223 @@
---
title: Option 2—Install by RKE
weight: 275
---
# Install by RKE
You can deploy Rancher using the Rancher Kubernetes Engine (RKE). RKE is Rancher's own fast and light-weight Kubernetes installer. Rancher installation using RKE is the best install option for two different use cases:
- When installing Rancher on a Kubernettes cluster that is already running.
- When you want to set up a new production Kubernettes cluster running in a high-availablity configuration.
## Objectives
We've broken installation of Rancher by RKE into a series of smaller tasks. Here's what you'll do during your RKE install.
1. [Provision Linux Hosts](#provision-linux-hosts)
Begin by provisioning Linux hosts or an existing Kubernettes cluster. Make sure your hosts meet Rancher requirements.
2. [Get RKE](#get-rke)
Download the RKE installer from GitHub.
3. [Get YAML Template](#get-yaml-template)
During installation, the RKE uploads 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.
- If you want to install Rancher on a Kubernettes cluster that's already running, make sure its nodes meet the requirements below.
- If you want to install Rancher on a new Kubernettes cluster in a high-availabilty configuration, provision 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 uploads a `.yml` config file to install and configure your Kubernetes cluster. Download one of the `.yml` templates that we provide 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:
- Auto-Generated Self-Signed Certifcates (i.e. SSL passthrough):
- [3-node-passthrough.yml]({{< baseurl >}}/rke-yml/3-node-passthrough.yml)
- [5-node-passthrough.yml]({{< baseurl >}}/rke-yml/5-node-passthrough.yml)
- [7-node-passthrough.yml]({{< baseurl >}}/rke-yml/7-node-passthrough.yml)
<br/>
<br/>
- Bring Your Own Certificate (either CA- or Self-Signed):
- [3-node-certificate.yml]({{< baseurl >}}/rke-yml/3-node-certificate.yml)
- [5-node-certificate.yml]({{< baseurl >}}/rke-yml/5-node-certificate.yml)
- [7-node-certificate.yml]({{< baseurl >}}/rke-yml/7-node-certificate.yml)
### 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.
content/rancher/quick-start-guide/_index.md
+54 -270
View File
@@ -17,115 +17,73 @@ This Quick Start Guide is divided into different tasks for easier consumption.
1. [Provision a Linux Host](#provision-a-linux-host)
Begin by provisioning a Linux host.
1. [Review Requirements](#host-and-node-requirements)
2. [Install Rancher](#install-rancher)
Before you do anything, review the requirements.
From your Linux host, run the Docker command for installing Rancher.
2. [Prepare a Linux Host](#prepare-a-linux-host)
3. [Log In](#log-in)
First, you need to provision a Linux host.
Browse to your Linux host to access the Rancher UI.
3. [Install Rancher](#install-rancher)
4. [Create the Cluster](#create-the-cluster)
Run the Docker command for installing Rancher.
Use the versatile **Custom** option to clone your Linux host into a new Kubernetes cluster.
4. [Log In](#log-in)
5. [Deploy a Workload](#deploy-a-workload)
Browse to your Linux host to access the Rancher UI.
Create a workload so that Kubernetes can distribute NGINX among your cluster nodes.
5. [Create a Cluster](#create-a-cluster)
6. [View Your Application](#view-your-application)
Use Rancher to create your first cluster.
When your workload finishes deployment, browse to your node IP to make sure NGINX is running.
6. [Deploy a Workload](#deploy-a-workload)
7. [What's Next?](#whats-next)
Create a workload so that Kubernetes can distribute an application and its dependencies among your nodes.
Now that you've created a cluster and deployed NGINX, find out what else you can do with Rancher v2.0.
7. [View Your Application](#view-your-application)
## Provision a Linux Host
When your workload finishes deployment, browse to your application to make sure it works.
8. [What's Next?](#whats-next)
Now that you've created a cluster and deployed a workload, find out what else you can do with Rancher v2.0.
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
Provision the host according to the requirements below.
#### Hardware Requirements
- Memory: 4GB
- Memory: 4GB
#### Software requirements
- Operating System: Ubuntu 16.04 (64-bit)
- Software: Docker
- Operating System: Ubuntu 16.04 (64-bit)
- Software: Docker
<a name="node-requirements"></a>**Supported Versions:**
<a name="node-requirements"></a>**Supported Versions:**
- `1.12.6`
- `1.13.1`
- `17.03.2`
- `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.
#### Port Requirements
When provisioning your Linux host, open the ports listed below so that your master and worker nodes can communicate.
##### Master Nodes (etcd and controlplane nodes)
Protocol | Direction | Port Range | Purpose
--|---|---|--
TCP | Inbound | 22 | SSH server
TCP | Inbound | 80 | Canal
TCP | Inbound | 443 | Canal
TCP | Inbound | 6443 | Kubernetes API server
TCP | Inbound | 2379-2380 | etcd server client API
TCP | Inbound | 10250 | kubelet API
TCP | Inbound | 10251 | scheduler
TCP | Inbound | 10252 | controller
TCP | Inbound | 10256 | kubeproxy
##### Worker Nodes
Protocol | Direction | Port Range | Purpose
--|---|---|--
TCP | Inbound | 22 | SSH Server
TCP | Inbound | 80 | Canal
TCP | Inbound | 443 | Canal
TCP | Inbound | 10250 | kubelet API
TCP | Inbound | 10256 | kubeproxy
TCP | Inbound | 30000-32767 | NodePort Services
### Prepare a Linux Host
Begin by provisioning a Linux host to be your Rancher server and a template for your cluster nodes. This host can be:
- A virtual machine hosted by a cloud service.
- An on-premise virtual machine.
- An on-premise bare-metal server.
Provision the server according to the [requirements above](#host-and-node-requirements).
>**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.
### 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.
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:
2. From your shell, enter the following command:
```
$ sudo docker run -d --restart=unless-stopped -p 80:80 -p 443:443 rancher/server:preview
```
>**Note:**
> Although Rancher v2.0 is in beta, the `preview` tag is still used for installation.
```
$ sudo docker run -d --restart=unless-stopped -p 80:80 -p 443:443 rancher/server
```
**Result:** Rancher is installed.
@@ -133,106 +91,43 @@ To install Rancher on your host, connect to it and then use a shell to install.
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:
1. Open a web browser and enter the IP address of your host:
`https://<SERVER_IP>`
`https://<SERVER_IP>`
Replace `<SERVER_IP>` with your host IP address.
Replace `<SERVER_IP>` with your host IP address.
> **Note:** Rancher v2.0 beta:
>
> - Supports only the HTTPS protocol.
> - Uses a self-signed certificate. Due to this signature, the browser prompts you to trust the certificate before login. Following GA, you'll be able to use your own certificate.
2. When prompted, create a password for the default `admin` account there cowpoke!
2. When prompted, create a password for the default `admin` account there cowpoke!
3. Set the **Rancher Server URL**. The URL can either be an IP address or a host name. However, each node in your cluster must be able to resolve to the URL.
![login](../../../../img/rancher/server-url.png)
## Create the Cluster
Welcome to {{< product >}}! Use our application to clone your Linux host and configure them as a Kubernetes cluster.
In this task, use the versatile **Custom** option. This option lets you convert _any_ Linux host (cloud-hosted VM, on-premise VM, or bare-metal) into a cluster.
1. Click **+ Add Cluster**.
1. From the **Clusters** page, click **Add Cluster**.
![add cluster](../../../../img/rancher/click-add-cluster.png)
2. Choose **Custom**.
**Step Result:** The **Add Cluster** page opens.
3. Enter a **Cluster Name**.
2. From the **Add Cluster** menu, choose a service or source from which to create your first cluster.
4. Skip **Member Roles** and **Cluster Options**. We'll tell you about them later.
* If you're using a virtual machine hosted on a major cloud service, choose the tile for the service you want to use (e.g. **Digital Ocean**, **Azure Container Service**).
* If you're using bare-metal server, an on-premise virtual machine, or a cloud service that isn't explicitly listed, choose **Custom**.
5. Click **Next**.
> **Note:**
>
> - For Rancher v2.0 beta, Amazon EKS is not supported. This option will be available after GA.
> - For this tutorial, the Import option is out of scope. For now, create a cluster using one of the other options. We'll address Import later.
6. From **Node Role**, select _all_ the roles: **etcd**, **Control**, and **Worker**.
3. Enter a **Cluster Name**. No spaces allowed.
7. Skip the **Labels** stuff. It's not important for now.
> **Tip:** Skip adding **Member Roles** for now. This option isn't essential for your first cluster.
>
> ![skip member roles](../../../../img/rancher/skip-member-roles.png)
8. Copy the command displayed on screen to your clipboard.
4. **For those using Google Container Engine or Azure Container Service:**
9. 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.
Complete the form asking for account information. The form includes links to instructions detailing how to obtain this info.
10. When you finish running the command on your Linux host, click **Done**.
![gce-azure-instructions](../../../../img/rancher/gce-azure-instructions.png)
**Did you choose one of the other tiles (like Digital Ocean)?** This step doesn't apply to you. Skip to the next step.
5. Select **Cluster Options**.
Use these options to choose things like the version of Kubernetes that's installed in your cluster, along with other Kubernetes options such as pod security policies. Some services have more options than others. If you're unsure of what to choose, use the default options.
6. Add at least one **Node Pool**.
A *Node Pool* is a group of nodes that are configured identically. Your cluster can contain as many node pools as you'd like. Each object in the grid represents a single node configuration. You can use the node pool to choose the number (i.e. **Count**) of nodes running a given configuration (i.e. **Template**).
> **Note:** The instructions below don't apply to Google Container Engine, Azure Container Service, or the Custom option.
>
>* For Azure Container Server, no additional steps are needed. Proceed to this task's [final step](#create-cluster).
>* For Google Container Engine, complete the Nodes form. The options are pretty self-explanatory. When you're done, proceed to this task's [final step](#create-cluster).
>* For Custom, see [Appendix A: Add Custom Cluster](#appendix-a-add-custom-cluster).
1. Enter a **Node Prefix**. When the cluster is created, each node in the pool is named after the prefix. An incremented number is appended to each node.
2. Enter the node **Count** for the pool.
3. Click **Add Node Template**. A node template is just the a virtual machine configuration you're using to create your nodes (i.e. other virtual machines).
Depending on the cluster option that you choose, the Rancher UI displays instructions on how to create a template. The process is different for each cloud service. You may need to log in to your cloud service to find the data Rancher needs.
4. Choose the **Template** that you just added.
![choose template](../../../../img/rancher/choose-template.gif)
5. Select roles for the node pool.
<a name="roles"></a>
Kubernetes functions using different [components](https://kubernetes.io/docs/concepts/overview/components/), which are divided into *master components* and *node components*. When setting up your node pool, select a pool to fill each component role. You can install all components one a single pool, or you can spread them around.
The roles are:
- **etcd**: One of the master components. Etcd is a distributed reliable key-value store that stores all Kubernetes states.
- **Control**: The remaining master components as well as the node components. These nodes help manage the Kubernetes cluster and where your applications can be launched.
- **Worker**: On these nodes, only node components are launched. These nodes run only applications.
6. **Optional:** Click **+ Add Node Pool** to add more pools.
![add-second-node-pool](../../../../img/rancher/add-second-node-pool.gif)
7. <a name="create-cluster"></a>Click **Create**.
**Result:**
- Your cluster is created and assigned a state of **Provisioning**. Rancher is standing up your cluster.
- You can access your cluster after its state is updated to **Active**.
- **Active** clusters are assigned a **Project** and **Namespace**, both of which are named `Default`.
{{< result_create-cluster >}}
### Deploy a Workload
@@ -256,11 +151,11 @@ For this workload, you'll be deploying the application NGINX.
7. From **Port Mapping**, click **Add Port**.
![enter-docker-image](../../../../img/rancher/enter-docker-image.png)
8. From the **Publish on** drop-down, make sure that **Every node** is selected.
8. From the **Source Port** field, leave the **Random** value in place.
>**Note:** During Rancher v2.0 beta, only port 80 is supported. Other ports will be supported at GA.
7. From the **Container Port** field, enter port `80`.
8. Leave the remaining options on their default setting. We'll tell you about them later.
@@ -281,116 +176,5 @@ From the **Workloads** page, click the link underneath your workload. If your de
Congratulations! You have:
- Created your first cluster.
- Deployed an application to your cluster using a workload.
Now you can use the rest of Rancher v2.0 to orchestrate and manage your pods.
(Moooooo-re coming soon!)
![cow](../../../../img/rancher/cow.jpg)
### Appendix A: Add Custom Cluster
When creating a custom cluster, follow these instructions to complete its creation. These instructions will create one or more node that will be used to image your cluster.
>**Note:** When creating a custom cluster, make sure each node meets the [Host Requirements](#host-requirements).
1. From **Node Roles**, choose the Kubernetes component roles that you want the node to fill. You must fill each role.
A more detailed description of each [role](#roles) is available earlier in this guide.
>**Note:** If you want to spread the roles among different nodes, provision additional Linux hosts and enter the command on each of your nodes.
3. **Optional:** Add labels to the node template.
4. Copy the command for installing Docker to your clipboard.
>**Remember:** The version of Docker installed on your nodes must be [supported](#node-requirements).
5. Log in to your Linux host using your preferred shell, such as PuTTy or a remote Terminal connection.
6. Enter the command on your Linux host.
7. From you Rancher session, click **Done**.
8. Resume the Quick Start Guide from [Deploy a Workload](#deploy-a-workload).
<!--
### Importing Kubernetes Clusters
In Rancher v2.0, you can import an existing, external installation of Kubernetes v1.8. In this scenario, the cluster provider manages your hosts outside of Rancher.
#### To Import a Kubernetes Cluster:
1. Follow the instructions in the Rancher UI to import an existing Kubernetes cluster. Import the _kubeconfig_ file of your existing cluster.
2. Click **Import**. Once your cluster is ready, you can view its status on the Clusters page. Once the cluster is active, you can start adding pods into your namespace.
### Rancher Concepts
Rancher supports grouping resources into multiples clusters, projects and namespaces.
A **cluster** is a group of physical (or virtual) compute resources. Each project is tied to one cluster and runs its pods on the cluster's nodes. You can share a cluster with more than one project as well as give different users access to manage the various resources of a cluster.
A **project** is a group of namespaces where workloads are defined. The pods in a project can communicate with each other over a shared managed network, and you can give different users access to manage the various resources of a project.
<a id="catalog"></a>
### Deploy an Application
After your cluster is **Active**, you're ready to add applications to its **Default** project.
A *project* is an object that fences in namespaces and workloads. We'll describe projects, namespaces, and workloads in more detail later.
Out of the box, Rancher is bundled with a catalog of applications (i.e. a [Helm chart](https://helm.sh/)) that make their deployment easy. Choose an application from the catalog for deployment.
1. Click the link for the cluster that you just created.
![click-cluster-name](../../../../img/rancher/click-cluster-name.png)
2. From the main menu of your cluster **Dashboard**, click **Projects**.
![select-projects](../../../../img/rancher/select-projects.png)
3. Open the **Default** project. A default project is added to every cluster created.
4. From the main menu, click **Catalog Apps**.
![select-catalog-apps](../../../../img/rancher/select-catalog-apps.png)
5. Click **+ Launch**.
**Step Result:** The **Catalog** displays the application templates that are available.
6. Choose an application to include in your project. Then click **View Details**.
![choose-app](../../../../img/rancher/choose-app.gif)
7. Scroll to **New Application**. Click **Show advanced options**.
8. Click **Use an existing namespace**. Then select **default**.
![select-default-namespace](../../../../img/rancher/select-default-namespace.gif)
9. **Optional:** Choose other settings.
> **Note:** To review the `docker-compose.yml` and `rancher-compose.yml` files used to generate the stacks, click **Preview** before launching the stack.
10. Skip the rest of the options for now. Click **Launch**.
**Result**:
- The application is added to the project and deployed using a *workload*. A workload is an object that includes pods along with other files and info needed to deploy your application.
- When your workload completes deployment, it's assigned a state of **Active**. You can view this status from the project's **Workloads** page.
### Using Kubeconfig File
You can generate a Kubernetes configuration file to use `kubectl` on your desktop. A Kubernetes configuration file, i.e. *kubeconfig*, lets you configure access to one or more clusters from your desktop.
1. On the Rancher UI menu, select the cluster.
2. In the **Dashboard**, click on the **Kubeconfig File** button. A *kubeconfig* file will be generated so you can use `kubectl` on your desktop. Copy and paste the code that displays into your `~/.kube/config` file, and then start using `kubectl`. Click **Close** to return to the Rancher UI.
### Deploying on Ubuntu
It is possible to use Rancher to control Canonical Kubernetes (cdk) clusters running on Ubuntu. A full set of instructions has been provided by Canonical for doing this here: [https://kubernetes.io/docs/getting-started-guides/ubuntu/rancher/](https://kubernetes.io/docs/getting-started-guides/ubuntu/rancher/).-->
- Created your first cluster.
- Deployed NGINX to your cluster using a workload.
layouts/shortcodes/requirements_ha.html
+1 -1
View File
@@ -1,5 +1,5 @@
<div>
<h2>High Availablity Requirements</h2>
<h4>High Availablity Requirements</h4>
<ul>
<li>RKE Cluster</li>
<ul>
layouts/shortcodes/requirements_hardware.html
+1 -1
View File
@@ -1,5 +1,5 @@
<div>
<h2>Hardware Requirements</h2>
<h4>Hardware Requirements</h4>
<ul>
<li>Memory: 4GB</li>
</ul>
layouts/shortcodes/requirements_os.html
+1 -1
View File
@@ -1,5 +1,5 @@
<div>
<h2>Operating System Requirements</h2>
<h4>Operating System Requirements</h4>
<ul>
<li>Ubuntu 16.04 (64-bit)</li>
<li>Red Hat Enterprise Linux 7.5 (64-bit)</li>
layouts/shortcodes/requirements_ports.html
+65 -27
View File
@@ -1,48 +1,59 @@
<div>
<h3>Master Nodes (etcd and controlplane nodes)</h3>
<br/>
<h5>Port Requirements</h5>
<h6>Master Nodes (etcd and controlplane nodes)</h6>
<table>
<tr>
<th>protocol</th>
<th>direction</th>
<th>port range</th>
<th>purpose</th>
</tr>
<tr>
<td rowspan="9">tcp</td>
<td rowspan="10">inbound</td>
<td>tcp</td>
<td>22</td>
<td>ssh server</td>
</tr>
<tr>
<td>80</td>
<td>http</td>
</tr>
<tr>
<td>443</td>
<td>https</td>
</tr>
<tr>
<td>tcp</td>
<td>6443</td>
<td>kubernetes api server</td>
</tr>
<tr>
<td>tcp</td>
<td>2379-2380</td>
<td>etcd server client api</td>
</tr>
<tr>
<tr>
<td>tcp</td>
<td>10250</td>
<td>kubelet api</td>
</tr>
<tr>
<tr>
<td>tcp</td>
<td>10251</td>
<td>scheduler</td>
</tr>
<tr>
<tr>
<td>tcp</td>
<td>10252</td>
<td>controller</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>
@@ -52,38 +63,65 @@
<td>canal</td>
</tr>
</table>
<h3>Worker Nodes</h3>
<br/>
<h6>Worker Nodes</h6>
<table>
<tr>
<td>protocol</td>
<td>direction</td>
<td>port range</td>
<td>purpose</td>
<th>protocol</th>
<th>port range</th>
<th>purpose</th>
</tr>
<tr>
<td rowspan="6">tcp</td>
<td rowspan="7">inbound</td>
<td>tcp</td>
<td>22</td>
<td>ssh server</td>
</tr>
<tr>
<td>tcp</td>
<td>80</td>
<td>http</td>
<td>ingress</td>
</tr>
<tr>
<td>tcp</td>
<td>443</td>
<td>https</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>
layouts/shortcodes/requirements_software.html
+1 -1
View File
@@ -1,5 +1,5 @@
<div>
<h2>Software Requestions</h2>
<h4>Software Requestions</h4>
<ul>
<li>
<p>Docker</p>
src/rke-yml/3-node-certificate.yml
+137
View File
@@ -0,0 +1,137 @@
# default k8s version: v1.8.9-rancher1-1
# default network plugin: flannel
nodes:
- address: <IP> # hostname or 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: [etcd,worker]
ssh_key_path: <PEM_FILE>
addons: |-
---
kind: Namespace
apiVersion: v1
metadata:
name: cattle-system
---
kind: ServiceAccount
apiVersion: v1
metadata:
name: cattle-admin
namespace: cattle-system
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: cattle-crb
namespace: cattle-system
subjects:
- kind: ServiceAccount
name: cattle-admin
namespace: cattle-system
roleRef:
kind: ClusterRole
name: cluster-admin
apiGroup: rbac.authorization.k8s.io
---
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
---
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
---
apiVersion: v1
kind: Service
metadata:
namespace: cattle-system
name: cattle-service
labels:
app: cattle
spec:
ports:
- port: 80
targetPort: 80
protocol: TCP
name: http
- port: 443
targetPort: 443
protocol: TCP
name: https
selector:
app: cattle
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
namespace: cattle-system
name: cattle-ingress-http
annotations:
nginx.ingress.kubernetes.io/proxy-connect-timeout: "30"
nginx.ingress.kubernetes.io/proxy-read-timeout: "1800" # Max time in seconds for ws to remain shell window open
nginx.ingress.kubernetes.io/proxy-send-timeout: "1800" # Max time in seconds for ws to remain shell window open
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
---
kind: Deployment
apiVersion: extensions/v1beta1
metadata:
namespace: cattle-system
name: cattle
spec:
replicas: 1
template:
metadata:
labels:
app: cattle
spec:
serviceAccountName: cattle-admin
containers:
- image: rancher/rancher:master
imagePullPolicy: Always
name: cattle-server
ports:
- containerPort: 80
protocol: TCP
- containerPort: 443
protocol: TCP
volumeMounts:
- mountPath: /etc/rancher/ssl
name: cattle-keys-volume
readOnly: true
volumes:
- name: cattle-keys-volume
secret:
defaultMode: 420
secretName: cattle-keys-server
src/rke-yml/3-node-passthrough.yml
+110
View File
@@ -0,0 +1,110 @@
# default k8s version: v1.8.9-rancher1-1
# default network plugin: flannel
nodes:
- address: <IP> # hostname or 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: [etcd,worker]
ssh_key_path: <PEM_FILE>
ingress:
provider: nginx
extra_args:
enable-ssl-passthrough: ""
addons: |-
---
kind: Namespace
apiVersion: v1
metadata:
name: cattle-system
---
kind: ServiceAccount
apiVersion: v1
metadata:
name: cattle-admin
namespace: cattle-system
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: cattle-crb
namespace: cattle-system
subjects:
- kind: ServiceAccount
name: cattle-admin
namespace: cattle-system
roleRef:
kind: ClusterRole
name: cluster-admin
apiGroup: rbac.authorization.k8s.io
---
apiVersion: v1
kind: Service
metadata:
namespace: cattle-system
name: cattle-service
labels:
app: cattle
spec:
ports:
- port: 80
targetPort: 80
protocol: TCP
name: http
- port: 443
targetPort: 443
protocol: TCP
name: https
selector:
app: cattle
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
namespace: cattle-system
name: cattle-ingress-http
annotations:
nginx.ingress.kubernetes.io/proxy-connect-timeout: "30"
nginx.ingress.kubernetes.io/proxy-read-timeout: "1800" # Max time in seconds for ws to remain shell window open
nginx.ingress.kubernetes.io/proxy-send-timeout: "1800" # Max time in seconds for ws to remain shell window open
nginx.ingress.kubernetes.io/ssl-passthrough: "true" # Enable ssl-passthrough to backend.
spec:
rules:
- host: <FQDN> # FQDN to access cattle server
http:
paths:
- backend:
serviceName: cattle-service
servicePort: 443
---
kind: Deployment
apiVersion: extensions/v1beta1
metadata:
namespace: cattle-system
name: cattle
spec:
replicas: 1
template:
metadata:
labels:
app: cattle
spec:
serviceAccountName: cattle-admin
containers:
- image: rancher/rancher:master
imagePullPolicy: Always
name: cattle-server
ports:
- containerPort: 80
protocol: TCP
- containerPort: 443
protocol: TCP
src/rke-yml/5-node-certificate.yml
+145
View File
@@ -0,0 +1,145 @@
# default k8s version: v1.8.9-rancher1-1
# default network plugin: flannel
nodes:
- address: <IP> # hostname or 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: [etcd,worker]
ssh_key_path: <PEM_FILE>
- address: <IP>
user: <USER>
role: [etcd,worker]
ssh_key_path: <PEM_FILE>
- address: <IP>
user: <USER>
role: [etcd,worker]
ssh_key_path: <PEM_FILE>
addons: |-
---
kind: Namespace
apiVersion: v1
metadata:
name: cattle-system
---
kind: ServiceAccount
apiVersion: v1
metadata:
name: cattle-admin
namespace: cattle-system
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: cattle-crb
namespace: cattle-system
subjects:
- kind: ServiceAccount
name: cattle-admin
namespace: cattle-system
roleRef:
kind: ClusterRole
name: cluster-admin
apiGroup: rbac.authorization.k8s.io
---
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
---
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
---
apiVersion: v1
kind: Service
metadata:
namespace: cattle-system
name: cattle-service
labels:
app: cattle
spec:
ports:
- port: 80
targetPort: 80
protocol: TCP
name: http
- port: 443
targetPort: 443
protocol: TCP
name: https
selector:
app: cattle
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
namespace: cattle-system
name: cattle-ingress-http
annotations:
nginx.ingress.kubernetes.io/proxy-connect-timeout: "30"
nginx.ingress.kubernetes.io/proxy-read-timeout: "1800" # Max time in seconds for ws to remain shell window open
nginx.ingress.kubernetes.io/proxy-send-timeout: "1800" # Max time in seconds for ws to remain shell window open
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
---
kind: Deployment
apiVersion: extensions/v1beta1
metadata:
namespace: cattle-system
name: cattle
spec:
replicas: 1
template:
metadata:
labels:
app: cattle
spec:
serviceAccountName: cattle-admin
containers:
- image: rancher/rancher:master
imagePullPolicy: Always
name: cattle-server
ports:
- containerPort: 80
protocol: TCP
- containerPort: 443
protocol: TCP
volumeMounts:
- mountPath: /etc/rancher/ssl
name: cattle-keys-volume
readOnly: true
volumes:
- name: cattle-keys-volume
secret:
defaultMode: 420
secretName: cattle-keys-server
src/rke-yml/5-node-passthrough.yml
+118
View File
@@ -0,0 +1,118 @@
# default k8s version: v1.8.9-rancher1-1
# default network plugin: flannel
nodes:
- address: <IP> # hostname or 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: [etcd,worker]
ssh_key_path: <PEM_FILE>
- address: <IP>
user: <USER>
role: [etcd,worker]
ssh_key_path: <PEM_FILE>
- address: <IP>
user: <USER>
role: [etcd,worker]
ssh_key_path: <PEM_FILE>
ingress:
provider: nginx
extra_args:
enable-ssl-passthrough: ""
addons: |-
---
kind: Namespace
apiVersion: v1
metadata:
name: cattle-system
---
kind: ServiceAccount
apiVersion: v1
metadata:
name: cattle-admin
namespace: cattle-system
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: cattle-crb
namespace: cattle-system
subjects:
- kind: ServiceAccount
name: cattle-admin
namespace: cattle-system
roleRef:
kind: ClusterRole
name: cluster-admin
apiGroup: rbac.authorization.k8s.io
---
apiVersion: v1
kind: Service
metadata:
namespace: cattle-system
name: cattle-service
labels:
app: cattle
spec:
ports:
- port: 80
targetPort: 80
protocol: TCP
name: http
- port: 443
targetPort: 443
protocol: TCP
name: https
selector:
app: cattle
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
namespace: cattle-system
name: cattle-ingress-http
annotations:
nginx.ingress.kubernetes.io/proxy-connect-timeout: "30"
nginx.ingress.kubernetes.io/proxy-read-timeout: "1800" # Max time in seconds for ws to remain shell window open
nginx.ingress.kubernetes.io/proxy-send-timeout: "1800" # Max time in seconds for ws to remain shell window open
nginx.ingress.kubernetes.io/ssl-passthrough: "true" # Enable ssl-passthrough to backend.
spec:
rules:
- host: <FQDN> # FQDN to access cattle server
http:
paths:
- backend:
serviceName: cattle-service
servicePort: 443
---
kind: Deployment
apiVersion: extensions/v1beta1
metadata:
namespace: cattle-system
name: cattle
spec:
replicas: 1
template:
metadata:
labels:
app: cattle
spec:
serviceAccountName: cattle-admin
containers:
- image: rancher/rancher:master
imagePullPolicy: Always
name: cattle-server
ports:
- containerPort: 80
protocol: TCP
- containerPort: 443
protocol: TCP
src/rke-yml/7-node-certificate.yml
+153
View File
@@ -0,0 +1,153 @@
# default k8s version: v1.8.9-rancher1-1
# default network plugin: flannel
nodes:
- address: <IP> # hostname or 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: [etcd,worker]
ssh_key_path: <PEM_FILE>
- address: <IP>
user: <USER>
role: [etcd,worker]
ssh_key_path: <PEM_FILE>
- address: <IP>
user: <USER>
role: [etcd,worker]
ssh_key_path: <PEM_FILE>
- address: <IP>
user: <USER>
role: [etcd,worker]
ssh_key_path: <PEM_FILE>
- address: <IP>
user: <USER>
role: [etcd,worker]
ssh_key_path: <PEM_FILE>
addons: |-
---
kind: Namespace
apiVersion: v1
metadata:
name: cattle-system
---
kind: ServiceAccount
apiVersion: v1
metadata:
name: cattle-admin
namespace: cattle-system
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: cattle-crb
namespace: cattle-system
subjects:
- kind: ServiceAccount
name: cattle-admin
namespace: cattle-system
roleRef:
kind: ClusterRole
name: cluster-admin
apiGroup: rbac.authorization.k8s.io
---
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
---
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
---
apiVersion: v1
kind: Service
metadata:
namespace: cattle-system
name: cattle-service
labels:
app: cattle
spec:
ports:
- port: 80
targetPort: 80
protocol: TCP
name: http
- port: 443
targetPort: 443
protocol: TCP
name: https
selector:
app: cattle
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
namespace: cattle-system
name: cattle-ingress-http
annotations:
nginx.ingress.kubernetes.io/proxy-connect-timeout: "30"
nginx.ingress.kubernetes.io/proxy-read-timeout: "1800" # Max time in seconds for ws to remain shell window open
nginx.ingress.kubernetes.io/proxy-send-timeout: "1800" # Max time in seconds for ws to remain shell window open
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
---
kind: Deployment
apiVersion: extensions/v1beta1
metadata:
namespace: cattle-system
name: cattle
spec:
replicas: 1
template:
metadata:
labels:
app: cattle
spec:
serviceAccountName: cattle-admin
containers:
- image: rancher/rancher:master
imagePullPolicy: Always
name: cattle-server
ports:
- containerPort: 80
protocol: TCP
- containerPort: 443
protocol: TCP
volumeMounts:
- mountPath: /etc/rancher/ssl
name: cattle-keys-volume
readOnly: true
volumes:
- name: cattle-keys-volume
secret:
defaultMode: 420
secretName: cattle-keys-server
src/rke-yml/7-node-passthrough.yml
+125
View File
@@ -0,0 +1,125 @@
# default k8s version: v1.8.9-rancher1-1
# default network plugin: flannel
nodes:
- address: <IP> # hostname or 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: [etcd,worker]
ssh_key_path: <PEM_FILE>
- address: <IP>
user: <USER>
role: [etcd,worker]
ssh_key_path: <PEM_FILE>
- address: <IP>
user: <USER>
role: [etcd,worker]
ssh_key_path: <PEM_FILE>
- address: <IP>
user: <USER>
role: [etcd,worker]
ssh_key_path: <PEM_FILE>
- address: <IP>
user: <USER>
role: [etcd,worker]
ssh_key_path: <PEM_FILE>
ingress:
provider: nginx
extra_args:
enable-ssl-passthrough: ""
addons: |-
---
kind: Namespace
apiVersion: v1
metadata:
name: cattle-system
---
kind: ServiceAccount
apiVersion: v1
metadata:
name: cattle-admin
namespace: cattle-system
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: cattle-crb
namespace: cattle-system
subjects:
- kind: ServiceAccount
name: cattle-admin
namespace: cattle-system
roleRef:
kind: ClusterRole
name: cluster-admin
apiGroup: rbac.authorization.k8s.io
---
apiVersion: v1
kind: Service
metadata:
namespace: cattle-system
name: cattle-service
labels:
app: cattle
spec:
ports:
- port: 80
targetPort: 80
protocol: TCP
name: http
- port: 443
targetPort: 443
protocol: TCP
name: https
selector:
app: cattle
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
namespace: cattle-system
name: cattle-ingress-http
annotations:
nginx.ingress.kubernetes.io/proxy-connect-timeout: "30"
nginx.ingress.kubernetes.io/proxy-read-timeout: "1800" # Max time in seconds for ws to remain shell window open
nginx.ingress.kubernetes.io/proxy-send-timeout: "1800" # Max time in seconds for ws to remain shell window open
nginx.ingress.kubernetes.io/ssl-passthrough: "true" # Enable ssl-passthrough to backend.
spec:
rules:
- host: <FQDN> # FQDN to access cattle server
http:
paths:
- backend:
serviceName: cattle-service
servicePort: 443
---
kind: Deployment
apiVersion: extensions/v1beta1
metadata:
namespace: cattle-system
name: cattle
spec:
replicas: 1
template:
metadata:
labels:
app: cattle
spec:
serviceAccountName: cattle-admin
containers:
- image: rancher/rancher:master
imagePullPolicy: Always
name: cattle-server
ports:
- containerPort: 80
protocol: TCP
- containerPort: 443
protocol: TCP