mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-25 12:38:05 +00:00
Denise
@@ -33,15 +33,15 @@ Rancher lets you assign _custom cluster roles_ to a user instead of the typical
|
|||||||
|
|
||||||
The following table lists each built-in custom cluster role available in Rancher and whether it is also granted by the `Owner` or `Member` role.
|
The following table lists each built-in custom cluster role available in Rancher and whether it is also granted by the `Owner` or `Member` role.
|
||||||
|
|
||||||
| Custom Cluster Role | Owner | Member |
|
| Custom Cluster Role | Owner | Member <a id="clus-roles"></a> |
|
||||||
| ---------------------------------- | ------------- | ------------- |
|
| ---------------------------------- | ------------- | --------------------------------- |
|
||||||
| Manage Cluster Members | ✓ | |
|
| Manage Cluster Members | ✓ | |
|
||||||
| Manage Nodes | ✓ | |
|
| Manage Nodes | ✓ | |
|
||||||
| Manage Storage | ✓ | |
|
| Manage Storage | ✓ | |
|
||||||
| View All Projects | ✓ | |
|
| View All Projects | ✓ | |
|
||||||
| Create Project | ✓ | ✓ |
|
| Create Project | ✓ | ✓ |
|
||||||
| View Cluster Members | ✓ | ✓ |
|
| View Cluster Members | ✓ | ✓ |
|
||||||
| View Nodes | ✓ | ✓ |
|
| View Nodes | ✓ | ✓ |
|
||||||
|
|
||||||
> **Note:** Each cluster role listed above, including `Owner` and `Member`, is comprised of multiple rules granting access to various resources. You can view the roles and their rules on the Global > Security > Roles page.
|
> **Note:** Each cluster role listed above, including `Owner` and `Member`, is comprised of multiple rules granting access to various resources. You can view the roles and their rules on the Global > Security > Roles page.
|
||||||
|
|
||||||
@@ -69,25 +69,25 @@ Rancher lets you assign _custom project roles_ to a user instead of the typical
|
|||||||
|
|
||||||
The following table lists each built-in custom project role available in Rancher and whether it is also granted by the `Owner`, `Member`, or `Read Only` role.
|
The following table lists each built-in custom project role available in Rancher and whether it is also granted by the `Owner`, `Member`, or `Read Only` role.
|
||||||
|
|
||||||
| Custom Cluster Role | Owner | Member | Read Only |
|
| Custom Cluster Role | Owner | Member<a id="proj-roles"><a/> | Read Only |
|
||||||
| ---------------------------------- | ------------- | ------------- | ------------- |
|
| ---------------------------------- | ------------- | ----------------------------- | ------------- |
|
||||||
| Manage Project Members | ✓ | | |
|
| Manage Project Members | ✓ | | |
|
||||||
| Create Namespaces | ✓ | ✓ | |
|
| Create Namespaces | ✓ | ✓ | |
|
||||||
| Manage Config Maps | ✓ | ✓ | |
|
| Manage Config Maps | ✓ | ✓ | |
|
||||||
| Manage Ingress | ✓ | ✓ | |
|
| Manage Ingress | ✓ | ✓ | |
|
||||||
| Manage Secrets | ✓ | ✓ | |
|
| Manage Secrets | ✓ | ✓ | |
|
||||||
| Manage Service Accounts | ✓ | ✓ | |
|
| Manage Service Accounts | ✓ | ✓ | |
|
||||||
| Manage Services | ✓ | ✓ | |
|
| Manage Services | ✓ | ✓ | |
|
||||||
| Manage Volumes | ✓ | ✓ | |
|
| Manage Volumes | ✓ | ✓ | |
|
||||||
| Manage Workloads | ✓ | ✓ | |
|
| Manage Workloads | ✓ | ✓ | |
|
||||||
| View Config Maps | ✓ | ✓ | ✓ |
|
| View Config Maps | ✓ | ✓ | ✓ |
|
||||||
| View Ingress | ✓ | ✓ | ✓ |
|
| View Ingress | ✓ | ✓ | ✓ |
|
||||||
| View Project Members | ✓ | ✓ | ✓ |
|
| View Project Members | ✓ | ✓ | ✓ |
|
||||||
| View Secrets | ✓ | ✓ | ✓ |
|
| View Secrets | ✓ | ✓ | ✓ |
|
||||||
| View Service Accounts | ✓ | ✓ | ✓ |
|
| View Service Accounts | ✓ | ✓ | ✓ |
|
||||||
| View Services | ✓ | ✓ | ✓ |
|
| View Services | ✓ | ✓ | ✓ |
|
||||||
| View Volumes | ✓ | ✓ | ✓ |
|
| View Volumes | ✓ | ✓ | ✓ |
|
||||||
| View Workloads | ✓ | ✓ | ✓ |
|
| View Workloads | ✓ | ✓ | ✓ |
|
||||||
|
|
||||||
> **Note:** Each project role listed above, including Owner, Member, and Read Only, is comprised of multiple rules granting access to various resources. You can view the roles and their rules on the Global > Security > Roles page.
|
> **Note:** Each project role listed above, including Owner, Member, and Read Only, is comprised of multiple rules granting access to various resources. You can view the roles and their rules on the Global > Security > Roles page.
|
||||||
|
|
||||||
@@ -134,3 +134,12 @@ You can change the cluster or project role(s) that are automatically assigned to
|
|||||||
1. If you want to remove a default role, edit the permission and select **No** from the default roles option.
|
1. If you want to remove a default role, edit the permission and select **No** from the default roles option.
|
||||||
|
|
||||||
**Result:** The default roles are configured based on your changes. Roles assigned to cluster/project creators display a check in the **Cluster/Project Creator Default** column.
|
**Result:** The default roles are configured based on your changes. Roles assigned to cluster/project creators display a check in the **Cluster/Project Creator Default** column.
|
||||||
|
|
||||||
|
### Cluster Membership Revocation Behavior
|
||||||
|
|
||||||
|
When you revoke the cluster membership for a user that's explicitly assigned membership to both the cluster _and_ a project within the cluster, that user [loses their cluster roles](#clus-roles) but [retains their project roles](#proj-roles). In other words, although you have revoked the user's permissions to access the cluster and its nodes, the user can still:
|
||||||
|
|
||||||
|
- Access the projects they hold membership in.
|
||||||
|
- Exercise any [individual project roles](#project-role-reference) they are assigned.
|
||||||
|
|
||||||
|
If you want to completely revoke a user's access within a cluster, revoke both their cluster and project memberships.
|
||||||
@@ -22,15 +22,31 @@ While Rancher comes out-of-the-box with a set of default user roles, you can als
|
|||||||
|
|
||||||
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**.
|
1. **v2.0.7 and later only:** Select a tab to determine the scope of the roles you're adding. The tabs are:
|
||||||
|
|
||||||
3. **Name** the role.
|
- **Cluster**
|
||||||
|
|
||||||
4. Choose whether to set the role to a status of [locked]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/locked-roles/).
|
The role is valid for assignment when adding/managing members to _only_ clusters.
|
||||||
|
|
||||||
|
- **Project**
|
||||||
|
|
||||||
|
The role is valid for assignment when adding/managing members to _only_ projects.
|
||||||
|
|
||||||
|
>**Note:** You cannot edit the Global tab.
|
||||||
|
|
||||||
|
1. Click **Add Cluster/Project Role**.
|
||||||
|
|
||||||
|
1. **Name** the role.
|
||||||
|
|
||||||
|
1. Choose whether to set the role to a status of [locked]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/locked-roles/).
|
||||||
|
|
||||||
Locked roles cannot be assigned to users.
|
Locked roles cannot be assigned to users.
|
||||||
|
|
||||||
5. Assign the role a **Context**. Context determines the scope of role assigned to the user. The contexts are:
|
1. **v2.0.7 and later only:** Choose a **Cluster/Project Creator Default** option setting. Use this option to set if the role is assigned to a user when they create a new cluster or project. Using this feature, you can expand or restrict the default roles for cluster/project creators.
|
||||||
|
|
||||||
|
>**Note:** Out of the box, the Cluster Creator Default and the Project Creator Default roles are `Cluster Owner` and `Project Owner` respectively.
|
||||||
|
|
||||||
|
1. **v2.0.6 and earlier only:** Assign the role a **Context**. Context determines the scope of role assigned to the user. The contexts are:
|
||||||
|
|
||||||
- **All**
|
- **All**
|
||||||
|
|
||||||
|
|||||||
@@ -1,51 +1,107 @@
|
|||||||
---
|
---
|
||||||
title: Migrating from Rancher v1.6 to v2.x
|
title: Migrating from Rancher v1.6 to v2.x
|
||||||
weight: 8500
|
weight: 10000
|
||||||
draft: true
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
Rancher 2.0 has been rearchitected and rewritten with the goal of providing a complete management solution for Kubernetes and Docker. Due to these extensive changes, there is no direct upgrade path from 1.6.x to 2.x, but rather a migration of your 1.6 application workloads into the 2.0 Kubernetes equivalent. In 1.6, the most common orchestration used was Rancher's own engine called Cattle. The following blogs (that will be converted in an official guide) explain and educate our Cattle users on running workloads in a Kubernetes environment.
|
||||||
|
|
||||||
### Checklist for migration of a 1.6 setup to 2.0
|
If you are an existing Kubernetes user on Rancher 1.6, you only need to review the [Get Started](#1-get-started) section to prepare you on what to expect on a new 2.0 Rancher cluster.
|
||||||
|
|
||||||
Blog Post: https://rancher.com/blog/2018/2018-08-09-migrate-1dot6-setup-to-2dot0/
|
## Kubernetes Basics
|
||||||
|
|
||||||
### Concepts of Stack, Service
|
Rancher 2.0 is built on the [Kubernetes](https://kubernetes.io/docs/home/?path=users&persona=app-developer&level=foundational) container orchestrator. This shift in underlying technology for 2.0 is a large departure from 1.6, which supported several popular container orchestrators. Since Rancher is now based entirely on Kubernetes, it's helpful to learn the Kubernetes basics.
|
||||||
How to map Cattle's Stack and service design to k8s world and launch a simple service
|
|
||||||
|
|
||||||
Blog Post: https://rancher.com/blog/2018/2018-08-02-journey-from-cattle-to-k8s/
|
The following table introduces and defines some key Kubernetes concepts.
|
||||||
|
|
||||||
|
| **Concept** | **Definition** |
|
||||||
|
| ----------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||||
|
| Cluster | A collection of machines that run containerized applications managed by Kubernetes. |
|
||||||
|
| Namespace | A virtual cluster, multiple of which can be supported by a single physical cluster. |
|
||||||
|
| Node | One of the physical (or virtual) machines that make up a cluster. |
|
||||||
|
| Pod | The smallest and simplest Kubernetes object. A pod represents a set of running [containers](https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/#why-containers) on your cluster. |
|
||||||
|
| Deployment | An API object that manages a replicated application. |
|
||||||
|
| Workload | Units of work that are running on the cluster, these can be pods or deployments. |
|
||||||
|
|
||||||
|
|
||||||
### Exposing your service publicly
|
## Migration Cheatsheet
|
||||||
How to publicly expose your Service using port mapping in 1.6 and its equivalent 2.0 method
|
|
||||||
|
|
||||||
Blog Post: https://rancher.com/blog/2018/expose-and-monitor-workloads/
|
Because Rancher 1.6 defaulted to our Cattle container orchestrator, it primarily used terminology related to Cattle. However, because Rancher 2.0 uses Kubernetes, it aligns with the Kubernetes naming standard. This shift could be confusing for people unfamiliar with Kubernetes, so we've created a table that maps terms commonly used in Rancher 1.6 to their equivalents in Rancher 2.0.
|
||||||
|
|
||||||
### Monitoring a service using healthchecks
|
| **Rancher 1.6** | **Rancher 2.0** |
|
||||||
How to add TCP/HTTP healthchecks in Rancher 2.0
|
| --- | --- |
|
||||||
|
| Container | Pod |
|
||||||
|
| Services | Workload |
|
||||||
|
| Load Balancer | Ingress |
|
||||||
|
| Stack | Namespace |
|
||||||
|
| Environment | Project (Administration)/Cluster (Compute)
|
||||||
|
| Host | Node |
|
||||||
|
| Catalog | Helm |
|
||||||
|
<br/>
|
||||||
|
More detailed information on Kubernetes concepts can be found in the
|
||||||
|
[Kubernetes Concepts Documentation](https://kubernetes.io/docs/concepts/).
|
||||||
|
|
||||||
Blog Post: https://rancher.com/blog/2018/2018-08-22-k8s-monitoring-and-healthchecks/
|
|
||||||
|
|
||||||
### Scheduling rules for placement of service containers & Global Service
|
## Migration Plan
|
||||||
How to find equivalence in 2.0 for scheduling your containers using host affinity/anti-affinity and other 1.6 scheduling labels
|
|
||||||
How to launch a global service in 2.0
|
<!-- TOC -->
|
||||||
|
|
||||||
|
- [1. Get Started](#1-get-started)
|
||||||
|
- [2. Migrate Applications](#2-migrate-applications)
|
||||||
|
- [3. Expose Your Services](#3-expose-your-services)
|
||||||
|
- [4. Monitor Your Applications](#4-monitor-your-applications)
|
||||||
|
- [5. Schedule Deployments](#5-schedule-deployments)
|
||||||
|
- [6. Service Discovery](#6-service-discovery)
|
||||||
|
<!--- [7. Load Balancing](#7-load-balancing)-->
|
||||||
|
|
||||||
|
|
||||||
|
<!-- /TOC -->
|
||||||
|
|
||||||
|
## 1. Get Started
|
||||||
|
|
||||||
|
As a Rancher 1.6 user who's interested in moving to 2.0, how should you get started with migration? The following blog provides a short checklist to help with this transition.
|
||||||
|
|
||||||
|
Blog Post: [Migrating from Rancher 1.6 to Rancher 2.0—A Short Checklist](https://rancher.com/blog/2018/2018-08-09-migrate-1dot6-setup-to-2dot0/)
|
||||||
|
|
||||||
|
## 2. Migrate Applications
|
||||||
|
|
||||||
|
In Rancher 1.6, you launch applications as _services_ and organize them under _stacks_ in an _environment_, which represents a compute and administrative boundary. Rancher 1.6 supports the Docker compose standard and provides import/export for application configurations using the following files: `docker-compose.yml` and `rancher-compose.yml`. In 2.0 the environment concept doesn't exist. Instead it's replaced by:
|
||||||
|
|
||||||
|
- **Cluster:** The compute boundary.
|
||||||
|
- **Project:** An administrative boundary.
|
||||||
|
|
||||||
|
The following article explores how to map Cattle's stack and service design to Kubernetes. It also demonstrates how to migrate a simple application from Rancher 1.6 to 2.0 using either the Rancher UI or Docker Compose.
|
||||||
|
|
||||||
|
Blog Post: [A Journey from Cattle to Kubernetes!](https://rancher.com/blog/2018/2018-08-02-journey-from-cattle-to-k8s/)
|
||||||
|
|
||||||
|
## 3. Expose Your Services
|
||||||
|
|
||||||
|
In Rancher 1.6, you could provide external access to your applications using port mapping. This article explores how to publicly expose your services in Rancher 2.0. It explores both UI and CLI methods to transition the port mapping functionality.
|
||||||
|
|
||||||
|
Blog Post: [From Cattle to Kubernetes—How to Publicly Expose Your Services in Rancher 2.0](https://rancher.com/blog/2018/expose-and-monitor-workloads/)
|
||||||
|
|
||||||
|
## 4. Monitor Your Applications
|
||||||
|
|
||||||
|
Rancher 1.6 provided TCP and HTTP healthchecks using its own healthcheck microservice. Rancher 2.0 uses native Kubernetes healthcheck support instead. This article overviews how to configure it in Rancher 2.0.
|
||||||
|
|
||||||
|
Blog Post: [From Cattle to Kubernetes—Application Healthchecks in Rancher 2.0](https://rancher.com/blog/2018/2018-08-22-k8s-monitoring-and-healthchecks/)
|
||||||
|
|
||||||
|
## 5. Schedule Deployments
|
||||||
|
|
||||||
|
Scheduling application containers on available resources is a key container orchestration technique. The following blog reviews how to schedule containers in Rancher 2.0 for those familiar with 1.6 scheduling labels (such as affinity and anti-affinity). It also explores how to launch a global service in 2.0.
|
||||||
|
|
||||||
|
Blog Post: [From Cattle to Kubernetes—Scheduling Workloads in Rancher 2.0](https://rancher.com/blog/2018/2018-08-29-scheduling-options-in-2-dot-0/)
|
||||||
|
|
||||||
|
## 6. Service Discovery
|
||||||
|
|
||||||
|
Rancher 1.6 provides service discovery within and across stacks using its own internal DNS microservice. It also supports pointing to external services and creating aliases. Moving to Rancher 2.0, you can replicate this same service discovery behavior. The following blog reviews this topic and the solutions needed to achieve service discovery parity in Rancher 2.0.
|
||||||
|
|
||||||
|
Blog Post: [From Cattle to Kubernetes—Service Discovery in Rancher 2.0](https://rancher.com/blog/2018/2018-09-04-service_discovery_2dot0/)
|
||||||
|
|
||||||
|
<!--## 7. Load Balancing
|
||||||
|
|
||||||
|
How to achieve TCP/HTTP load balancing and configure hostname/path-based routing in Rancher 2.0.
|
||||||
|
|
||||||
Blog Post: Coming soon!
|
Blog Post: Coming soon!
|
||||||
|
|
||||||
### Service Discovery: Rancher internal DNS
|
In Rancher 1.6, a Load Balancer was used to expose your applications from within the Rancher environment for access externally. In Rancher 2.0, the concept is the same. There is a Load Balancer option to expose your services. In the language of Kubernetes, this function is more often referred to as an **Ingress**. In short, Load Balancer and Ingress play the same role.-->
|
||||||
How to discover services, use external_name/alias in 2.0
|
|
||||||
|
|
||||||
Blog Post: Coming soon!
|
|
||||||
|
|
||||||
### LoadBalancing
|
|
||||||
How to achieve TCP/HTTP load balancing and configure hostname/path based routing in 2.0
|
|
||||||
|
|
||||||
Blog Post: Coming soon!
|
|
||||||
|
|
||||||
<!--
|
|
||||||
- [ ] Secrets - How to manage and use secrets in 2.0
|
|
||||||
- [ ] Storage - How to configure storage with Rancher 2.0 on Kubernetes
|
|
||||||
- [ ] Rancher metadata - What can be alternative solutions to rancher 1.6 metadata in rancher 2.0
|
|
||||||
- [ ] Environment management - What is the equivalence in 2.0 to creating and managing 1.6 environments
|
|
||||||
- [ ] External DNS integration- Alternative ways in 2.0 to integrate with external DNS providers supported by Rancher 1.6
|
|
||||||
- [ ] Differences in Upgrade procedure for applications deployed on Rancher
|
|
||||||
-->
|
|
||||||
|
|||||||
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
|
Before Width: | Height: | Size: 24 KiB After Width: | Height: | Size: 25 KiB |
File diff suppressed because one or more lines are too long
|
Before Width: | Height: | Size: 29 KiB After Width: | Height: | Size: 30 KiB |
File diff suppressed because one or more lines are too long
|
Before Width: | Height: | Size: 21 KiB After Width: | Height: | Size: 25 KiB |
Reference in New Issue
Block a user