general edits

This commit is contained in:
Mark Bishop
2018-05-11 11:26:47 -07:00
committed by Mark Bishop
parent 00574ec0a2
commit a74234befa
4 changed files with 35 additions and 28 deletions
-1
View File
@@ -1,7 +1,6 @@
---
title: About
weight: 5000
draft: true
---
# About
@@ -5,36 +5,39 @@ weight: 2110
# Cloud Providers
A Cloud Provider in Kubernetes is a module which provides an interface for managing load balancers, nodes (i.e. hosts) and networking routes. You can configure a cloud provider to automatically provision load balancers or persistent storage devices when launching Kubernetes definitions if the cloud provider that you configure supports that.
A _cloud provider_ is a module in Kubernetes that provides an interface for managing nodes, load balancers, and networking routes. You can configure a cloud provider to automatically provision load balancers or persistent storage devices when launching Kubernetes definitions, provided that the cloud provider you're using supports such automation.
By default, the Cloud Provider option is set to `None`. Supported cloud providers are:
By default, the **Cloud Provider** option is set to `None`. Supported cloud providers are:
* `Amazon`
* `Azure`
The `Custom` cloud provider is available if you want to configure your own cloud provider name and configuration in your cluster.
> **Warning:** Configuring a Cloud Provider in your cluster without configuring the prerequisites will cause your cluster to not provision correctly. Prerequisites needed for supported cloud providers are listed below.
> **Warning:** Your cluster will not provision correctly if you configure a cloud provider cluster of nodes that do not meet the prerequisites. Prerequisites for supported cloud providers are listed below.
## Amazon
When using the `Amazon` cloud provider, you can leverage the following capabilities:
* **Load Balancers:** Launches an AWS Elastic Load Balancer (ELB) when choosing `Layer-4 Load Balancer` in **Port Mapping** or when launching a `Service` with `type: LoadBalancer`.
* **Persistent Volumes**: Ability to use AWS Elastic Block Stores (EBS) for persistent volumes.
- **Load Balancers:** Launches an AWS Elastic Load Balancer (ELB) when choosing `Layer-4 Load Balancer` in **Port Mapping** or when launching a `Service` with `type: LoadBalancer`.
- **Persistent Volumes**: Allows you to use AWS Elastic Block Stores (EBS) for persistent volumes.
### Prerequisites
* Create/configure an IAM role
* Configuring the ClusterID
- Create/configure an IAM role
- Configuring the ClusterID
> **Note:** When you are creating an [Amazon EC2 Cluster]({{< baseurl >}}/rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-amazon-ec2/#create-the-amazon-ec2-cluster), the `ClusterID` is automatically configured.
> **Note:** When you create an [Amazon EC2 Cluster]({{< baseurl >}}/rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-amazon-ec2/#create-the-amazon-ec2-cluster), the `ClusterID` is automatically configured.
#### Create/configure an IAM role
#### Create/Configure an IAM Role
All nodes added to the cluster need to be able to interact with EC2 to create and remove resources. This is done using an IAM role attached to the instance. Please refer to [EC2 documentation](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#create-iam-role) on how to create an IAM role.
All nodes added to the cluster must be able to interact with EC2 so that they can create and remove resources. You can enable this interaction by using an IAM role attached to the instance.
When you are creating an [Amazon EC2 cluster]({{< baseurl >}}/rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-amazon-ec2/#create-the-amazon-ec2-cluster), you have to insert the name of the IAM role when creating the **Node Template**. When you are creating a [Custom cluster]({{< baseurl >}}/rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-custom/), you have to manually attach the IAM role to the instance(s).
[EC2 documentation: Creating an IAM Role](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#create-iam-role)
- While creating an [Amazon EC2 cluster]({{< baseurl >}}/rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-amazon-ec2/#create-the-amazon-ec2-cluster), you must insert the name of the IAM role when creating the **Node Template**.
- While creating a [Custom cluster]({{< baseurl >}}/rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-custom/), you must manually attach the IAM role to the instance(s).
The following IAM role can be created:
@@ -75,19 +78,19 @@ The following IAM role can be created:
The following resources need to tagged with a `ClusterID`:
* **Nodes**: All hosts added in Rancher.
* **Subnet**: The subnet used for your cluster
* **Security Group**: The security group used for your cluster.
- **Nodes**: All hosts added in Rancher.
- **Subnet**: The subnet used for your cluster.
- **Security Group**: The security group used for your cluster.
>**Note:** Do not tag multiple security groups, as this will generate an error when creating Elastic Load Balancer (ELB).
>**Note:** Do not tag multiple security groups. Tagging multiple groups generates an error when creating an Elastic Load Balancer (ELB).
The tag that should be used is:
Use the following tag:
**Key** = `kubernetes.io/cluster/CLUSTERID` **Value** = `owned`
where `CLUSTERID` can be chosen as you like, as long as it is equal across all tags set.
`CLUSTERID` can be any string you like, as long as it is equal across all tags set.
Setting the value of the tag to owned, tells the cluster that all resources with this tag are owned and managed by this cluster. If you share resources between clusters, you can change the tag to:
Setting the value of the tag to `owned` tells the cluster that all resources with this tag are owned and managed by this cluster. If you share resources between clusters, you can change the tag to:
**Key** = `kubernetes.io/cluster/CLUSTERID` **Value** = `shared`.
@@ -95,14 +98,18 @@ Setting the value of the tag to owned, tells the cluster that all resources with
When using the `Azure` cloud provider, you can leverage the following capabilities:
* **Load Balancers:** Launches an Azure Load Balancer within a specific Network Security Group.
* **Persistent Volumes:** Supports using Azure Blob disks and Azure Managed Disks with standard and premium storage accounts.
* **Network Storage:** Support Azure Files via CIFS mounts.
- **Load Balancers:** Launches an Azure Load Balancer within a specific Network Security Group.
- **Persistent Volumes:** Supports using Azure Blob disks and Azure Managed Disks with standard and premium storage accounts.
- **Network Storage:** Support Azure Files via CIFS mounts.
### Known Limitations Regarding Azure Subscriptions
* Single tenant accounts (e.g. accounts with no subscriptions) are not supported
* Multi-subscription accounts are not supported
The following account types are not supported for Azure Subscriptions:
- Single tenant accounts (i.e. accounts with no subscriptions).
- Multi-subscription accounts.
### Prerequisites
@@ -146,6 +153,7 @@ Last thing you will need to do, is assign the appropriate permissions to your Ap
1. For **Select**, select your created App registration name.
1. Select **Save**.
* **Azure Network Security Group Name (securityGroupName)**
Custom Azure Network Security Group needed to allow Azure Load Balancers to work. If you provision hosts using Rancher Machine Azure driver, you will need to edit them manually to assign them to this Network Security Group. You should already assign custom hosts to this Network Security Group during provisioning.
@@ -9,7 +9,7 @@ There are two ways to create volumes on Kubernetes: Persistent Volumes (PVs) and
## 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.
_Persistent Volumes_ are pre-provisioned storage volumes that you can bind to specific pods later. For example, in Amazon EC2, you might want to create a number of Elastic Block Store (EBS) volumes before you start running your application. Each pre-provisioned EBS volume corresponds to a Kubernetes persistent volume. When the application starts, it creates Persistent Volume Claims (PVCs) that bind to persistent volumes. A PVC corresponds to a Docker volume. Each PVC binds to one PV that includes the minimimum resources that the PVC requires. The following figure illustrates the relationship between pods, PVCs, PVs, and the underlying cloud storage.
![Persistent Volumes]({{< baseurl >}}/img/rancher/persistent-volume.png)
@@ -17,6 +17,6 @@ Rancher allows you to create PVs at cluster level and bind them to PVCs later. V
## 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.
Storage classes allow 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.
![Storage Classes]({{< baseurl >}}/img/rancher/storage-classes.png)
@@ -12,7 +12,7 @@ You can build any complex workload in Kubernetes using two basic constructs: pod
### Pods
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.
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 only one container. Therefore when we discuss _pods_, the term is often synonymous with _containers_. You scale pods the same way you scale containers, by having multiple instances of the same pod that implement a service.
### Controllers
@@ -26,7 +26,7 @@ Kubernetes provide a number of built-in controllers such as:
- [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.
You can also define your own controllers. Controllers have the job of taking a workload that you create and recreatinging on each of your cluster nodes. Controllers query the Kubernetes API for the state of the workload within the Kubernetes database. Then the controllers reproduce that workload state on each cluster node.
<!--## Service Types