adding headings for docathon

This commit is contained in:
Mark Bishop
2018-06-04 12:35:59 -07:00
committed by Mark Bishop
parent 08fb8d9450
commit 42d4141e1e
11 changed files with 97 additions and 20 deletions
@@ -3,3 +3,5 @@ title: API Keys
weight: 2400
draft: true
---
## What are API Keys?
@@ -27,7 +27,6 @@ The control plane nodes are used to run the Kubernetes API server, scheduler, an
Worker nodes are used to run the kubelet and the workload. It also runs the storage and networking drivers and ingress controllers when required. You create as many worker nodes as needed for your workload needs.
<!--
### Kubeconfig File
<!--### Kubeconfig File
Coming Soon!-->
Craig! Fill me in! -->
@@ -7,6 +7,12 @@ weight: 2105
RKE is Rancher’s own lightweight Kubernetes installer. It works with any cloud providers, virtualization platforms, or bare metal servers. It integrates with node drivers to automatically provision nodes on AWS, Azure, DigitalOcean, vSphere, OpenStack, etc. Users can add custom nodes to the cluster by running the Rancher agent on these nodes.
<!-- ### RKE Clusters and Kubeconfig Files
Craig! Fill me in!
-->
## Cloud-Managed Kubernetes Clusters
Rancher integrates with cloud APIs so users can provision GKE, EKS, and AKS clusters directly from Rancher. New cloud managed Kubernetes clusters will be added as they become available.
@@ -8,11 +8,13 @@ After installing Rancher 2.0, you should configure it to support your users and
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.
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.
### External vs. Local Authentication
The Rancher authentication proxy integrates with the following external authentication services.
- Microsoft Active Directory
- GitHub
- Microsoft Active Directory
- GitHub
However, Rancher also provides local authentication.
@@ -20,33 +22,59 @@ In most cases, you should use an external authentication service over local, as
## Users and Roles
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.
Within Rancher, each user authenticates 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.
<!-- ### Rancher Role Implementation
Fill me in Craig!
-->
### Default Roles
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.
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.
These users can create new clusters or manage clusters and projects that an administrator has given them access to.
<!-- ### Protected Roles
Nathan! Fill me in! If 'default roles' and 'protected roles' are synonymous, just add the info to 'default roles'.
-->
### Custom Roles
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.
Rancher lets you create _custom roles_ that let you assign individual permissions to a user. These roles are convenient for defining narrow or specialized permissions to a user within Rancher.
<!-- ### Projects and Clusters: Automatic Role Assignment
Fill me in Craig!
-->
<!-- ### Role Aggregation
Fill me in Craig!
-->
### Membership
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.
Non-administrative users do not have access to any existing projects/clusters by default. An administrator must explicitly assign membership to the user.
<!-- Craig! Add supplemental information about Role Context here is necessary (Different Roles for Cluster, Project) -->
## Rancher Server URL
@@ -66,12 +94,22 @@ Read more about Pod Security Policies in the [Kubernetes Documentation](https://
## Node Drivers
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.
- 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
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.
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 Kubernetes 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.
<!-- ## Rancher CLI Configuration
Dan! Fill me in!
-How to configure
-Common commands
-Command to view help
-->
@@ -17,3 +17,5 @@ Rancher allows you to create PVs at cluster level and bind them to PVCs later. V
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)
<!-- Storage and Cloud Providers -->
@@ -23,7 +23,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 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.
You can also define your own controllers. Controllers have the job of taking a workload that you create and recreating 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
@@ -87,3 +87,10 @@ You have three options for user authentication in {{< product >}}:
1. From the **Global** view, select **Users** from the main menu.
2. Click **Add User**. Then complete the **Add User** form. Click **Create** when you're done.
<!-- ## Finding User Accounts
Rajashree! Content here.
-->
@@ -4,6 +4,8 @@ weight: 3050
---
## Adding Custom Node Drivers
<!-- >**Prerequisite:** Nathan! Add role prereq here -->
If you create a cluster using a cloud provider that {{< product >}} doesn't support out-of-the-box, you may need to add the provider's drivers (or create them yourself) so that your nodes function properly.
1. From the **Global** view, select **Node Drivers** from the main menu.
@@ -0,0 +1,7 @@
---
title: Password Reset
weight: 3175
draft: true
---
Content here.
@@ -1,9 +1,11 @@
---
title: Adding Pod Security Policies
title: Pod Security Policies
weight: 3150
---
Using {{< product >}}, you can create a Pod Security Policy using our GUI rather than creating a .yaml file.
## Adding Pod Security Policies
Using {{< product >}}, you can create a Pod Security Policy using our GUI rather than creating a YAML file.
1. From the **Global** view, select **Security** > **Pod Security Policies** from the main menu. Then click **Add Policy**.
@@ -33,10 +35,9 @@ Using {{< product >}}, you can create a Pod Security Policy using our GUI rather
Now that you've created a Pod Security Policy, you can apply it to:
- An existing cluster
- An existing cluster.
- A brand new cluster. For more details, see [Creating a Cluster]({{< baseurl >}}/rancher/v2.x/en/tasks/clusters/creating-a-cluster/)
<!-- links -->
[1]: https://kubernetes.io/docs/concepts/policy/pod-security-policy/#volumes-and-file-systems
@@ -6,11 +6,17 @@ While _users_ determine who can log into Rancher, _roles_ determine which Kubern
## Adding A Custom Role
<!-- >**Prerequisites:**
Nathan! List app roles/permissions required to make a custom role here!
-->
While Rancher comes out-of-the-box with a set of default user roles, you can also create custom roles to provide users with very specific permissions within Rancher.
1. From the **Global** view, select **Security** > **Roles** from the main menu.
1. From the **Global** view, select **Security** > **Roles** from the main menu.
2. Click **Add Role**.
2. Click **Add Role**.
3. **Name** the role.
@@ -34,4 +40,11 @@ While Rancher comes out-of-the-box with a set of default user roles, you can als
6. Use the **Inherit from a Role** options to assign individual Rancher roles to your custom roles.
7. Click **Create**.
7. Click **Create**.
<!-- ## Enabling/Disabling Roles
Nathan! Fill me in!
-->