mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-23 11:38:05 +00:00
Vincent Fiduccia
@@ -3,3 +3,21 @@ title: Catalogs
|
||||
weight: 2250
|
||||
---
|
||||
# Catalogs
|
||||
|
||||
Rancher catalog builds on an enhanced version of Helm. All upstream Helm charts can work on Rancher, but Rancher adds several enhancements to make the user experience better.
|
||||
|
||||
## Catalog Git Repositories
|
||||
|
||||
Rancher stores Helm charts in git repositories to expedite the fetch and update of charts. In Rancher 2.0, only global catalogs are supported. Support for cluster-level and project-level charts will be added in the future.
|
||||
|
||||
## Enhanced Revision Tracking
|
||||
|
||||
While Helm supports versioned deployments, Rancher added capabilities to track and display what exactly changed between different revisions.
|
||||
|
||||
## Streamlined Application Launch
|
||||
|
||||
Rancher supports simplified README files and questions files to streamline the application launch process. Users need not read through the entire list of Helm variables to understand how to launch an application.
|
||||
|
||||
## Application Resource Management
|
||||
|
||||
Rancher tracks all the resources created by a specific application. Users can easily navigate to and troubleshoot on a page listing all the workload objects used to power an application.
|
||||
|
||||
@@ -4,3 +4,52 @@ weight: 2175
|
||||
---
|
||||
|
||||
# Load Balancing
|
||||
|
||||
Kubernetes supports load balancing in two ways: Layer-4 Load Balancing and Layer-7 Load Balancing.
|
||||
|
||||
## Layer-4 Load Balancer
|
||||
|
||||
Layer-4 load balancer (or the external load balancer) forwards traffic to Nodeports. Layer-4 load balancer allows you to forward both HTTP and TCP traffic. Layer-4 load balancer is supported by the underlying cloud provider. As a result, when you deploy RKE clusters on bare metal servers and vSphere clusters, layer-4 load balancer is not supported.
|
||||
|
||||
### Cloud Support for Layer-4 Load Balancing
|
||||
|
||||
Support for layer-4 load balancer varies based on the underlying cloud provider.
|
||||
|
||||
Cluster Deployment | Layer-4 Load Balancer Support
|
||||
----------------------------------------------|--------------------------------
|
||||
Amazon EKS | Supported by AWS cloud provider
|
||||
Google GKE | Supported by GCE cloud provider
|
||||
Azure AKS | TODO: check with Nathan
|
||||
RKE on EC2 | Supported by AWS cloud provider
|
||||
RKE on DigitalOcean | Not Supported
|
||||
RKE on vSphere | Not Supported
|
||||
RKE on Custom Hosts<br/>(e.g. bare-metal servers) | Not Supported
|
||||
|
||||
## Layer-7 Load Balancer
|
||||
|
||||
Layer-7 load balancer (or the ingress controller) supports host and path-based load balancing and SSL termination. Layer-7 load balancer only forwards HTTP and HTTPS traffic and therefore they listen on ports 80 and 443 only. Cloud providers such as Amazon and Google support layer-7 load balancer. In addition, RKE clusters deploys the Nginx Ingress Controller.
|
||||
|
||||
### Cloud Support for Layer-7 Load Balancing
|
||||
|
||||
Support for layer-7 load balancer varies based on the underlying cloud provider.
|
||||
|
||||
Cluster Deployment | Layer-7 Load Balancer Support
|
||||
----------------------------------------------|--------------------------------
|
||||
Amazon EKS | Supported by AWS cloud provider
|
||||
Google GKE | Supported by GKE cloud provider
|
||||
Azure AKS | TODO: check with Nathan
|
||||
RKE on EC2 | Nginx Ingress Controller
|
||||
RKE on DigitalOcean | Nginx Ingress Controller
|
||||
RKE on vSphere | Nginx Ingress Controller
|
||||
RKE on Custom Hosts<br/>(e.g. bare-metal servers) | Nginx Ingress Controller
|
||||
|
||||
### Host Names in Layer-7 Load Balancer
|
||||
|
||||
Some cloud-managed layer-7 load balancers (such as the ALB ingress controller on AWS) expose DNS addresses for ingress rules. You need to map (via CNAME) your domain name to the DNS address generated by the layer-7 load balancer.
|
||||
|
||||
Other layer-7 load balancers, such as the Google Load Balancer or Nginx Ingress Controller, directly expose one or more IP addresses. Google Load Balancer provides a single routable IP address. Nginx Ingress Controller exposes the external IP of all nodes that run the Nginx Ingress Controller. You can do either of the following:
|
||||
|
||||
1. Configure your own DNS to map (via A records) your domain name to the IP addresses exposes by the Layer-7 load balancer.
|
||||
2. Ask Rancher to generate an xip.io host name for your ingress rule. Rancher will take one of your exposed IPs, say a.b.c.d, and generate a host name <ingressname>.<namespace>.a.b.c.d.xip.io.
|
||||
|
||||
The benefit of using xip.io is that you obtain a working entrypoint URL immediately after you create the ingress rule. Setting up your own domain name, on the other hand, requires you to configure DNS servers and wait for DNS to propagate.
|
||||
|
||||
@@ -2,3 +2,17 @@
|
||||
title: Volumes
|
||||
weight: 2225
|
||||
---
|
||||
|
||||
# Volumes
|
||||
|
||||
There are two ways to create volumes on Kubernetes: Persistent Volumes (PVs) and Storage Classes.
|
||||
|
||||
## Persistent Volumes
|
||||
|
||||
Persistent Volumes are pre-provisioned storage volumes that can be bound to specific pods later. For example, on Amazon EC2, you might want to create a number of EBS volumes before you start running your application. Each pre-provisioned EBS volume corresponds to a Kubernetes persistent volume. When the application starts, its creates Persistent Volume Claims (PVCs) that binds to persistent volumes. A PVC corresponds to a Docker volume. Each PVC binds to one PV that offers at least as much resource as the PVC demands. The following figure illustrates the relationship between pods, PVCs, PVs, and the underlying cloud storage.
|
||||
|
||||
Rancher allows you to create PVs at cluster level and bind them to PVCs later. Volumes are managed on a per-project basis.
|
||||
|
||||
## Storage Classes
|
||||
|
||||
Storage classes enable you to create PVCs dynamically without having to create PVs first. For example, an EBS Storage Class will dynamically create EBS volumes and bind them to PVCs. A storage class is similar to the notion of a “storage driver.” The following figure illustrates how a PVC creation triggers the dynamic provisioning of an underlying EBS volume.
|
||||
|
||||
@@ -6,12 +6,29 @@ draft: true
|
||||
|
||||
# Workloads
|
||||
|
||||
Coming Soon
|
||||
You can build any complex workload in Kubernetes using two basic constructs: pods and controllers.
|
||||
|
||||
## Workload Types
|
||||
|
||||
Coming Soon
|
||||
### Pods
|
||||
|
||||
## Service Types
|
||||
A [_pod_](https://kubernetes.io/docs/concepts/workloads/pods/pod-overview/) is one or more containers that share network namespaces and storage volumes. Most pods have just one container. For all practical purposes, therefore, you can think of a pod as a container. You scale pods the same way you scale containers, by having multiple instances of the same pod that implement a service.
|
||||
|
||||
Coming Soon
|
||||
### Controllers
|
||||
|
||||
_Controllers_ contain the management logic for your application workload. The management logic encapsulated in controllers can include replication, upgrade, and self-healing.
|
||||
|
||||
Kubernetes provide a number of built-in controllers such as:
|
||||
|
||||
- [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)
|
||||
- [ReplicaSets](https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/)
|
||||
- [DaemonSets](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/)
|
||||
- [StatefulSets](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/)
|
||||
- [CronJobs](https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/)
|
||||
|
||||
You can also define your own controllers. Controllers query the Kubernetes API and perform the necessary actions to make the actual state of the workload conform to the desired state of the workload specified in the Kubernetes database.
|
||||
|
||||
|
||||
<!--## Service Types
|
||||
|
||||
Coming Soon-->
|
||||
|
||||
+1
-3
@@ -7,8 +7,6 @@ weight: 3225
|
||||
|
||||
## Objectives
|
||||
|
||||
{{< prereq_cluster >}}
|
||||
|
||||
1. [Create a Linux Host](#create-a-linux-host)
|
||||
|
||||
Begin by provisioning a Linux host.
|
||||
@@ -25,7 +23,7 @@ Begin creation of a custom cluster by provisioning a Linux host. Your host can b
|
||||
- An on-premise VM
|
||||
- A bare-metal server
|
||||
|
||||
Provision the host according to our [requirements](../setup/requirements.md).
|
||||
Provision the host according to the requirements below
|
||||
|
||||
|
||||
|
||||
@@ -11,6 +11,16 @@
|
||||
<td>tcp</td>
|
||||
<td>22</td>
|
||||
<td>ssh server</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>tcp</td>
|
||||
<td>80</td>
|
||||
<td>Rancher Server</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>tcp</td>
|
||||
<td>443</td>
|
||||
<td>Rancher Server</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>tcp</td>
|
||||
|
||||
Reference in New Issue
Block a user