-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #281 from stakater/fix-console-docs
fix console docs
- Loading branch information
Showing
20 changed files
with
375 additions
and
390 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Empty file.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,35 @@ | ||
# Capacity Planning | ||
|
||
The Capacity Planning feature in the app provides insights into resource usage and allocation across the cluster to help manage computing resources efficiently. It consists of three main sections: | ||
|
||
## 1. Graphical Representation | ||
|
||
### a. Tenant Requests vs. Cluster Capacity | ||
|
||
This section displays bar charts that compare the current resource requests from tenants (like CPU and memory) with the total available cluster capacity. The charts visually represent how much of the cluster’s resources are currently being utilized versus what is available, helping identify over-utilization or under-utilization scenarios. | ||
|
||
### b. Quota Requests vs. Cluster Capacity | ||
|
||
Similar to the tenant requests, this section compares the quota requests against the total cluster capacity. It allows administrators to see if the quota assigned is in line with the cluster's actual capacity. | ||
|
||
 | ||
|
||
## 2. Worker-pool Details | ||
|
||
A detailed table lists the worker nodes in the cluster, displaying each node’s CPU and memory capacity along with various labels that indicate the node’s configuration and role (e.g., worker, infra). This information helps in identifying resource distribution across nodes and managing workloads accordingly. | ||
|
||
 | ||
|
||
The worker-pool labels dropdown is used to filter the table data and graph based on the selected labels. If the selected label is common amongst the worker nodes, the filtered result is a list of all the worker nodes that contain the selected labels and update graph for filtered worker nodes. | ||
|
||
If the label is specific for any worker node, selecting the label will filter the specific worker nodes containing the label and update the graph based on the filtered results. | ||
|
||
To clear the filter you can remove applied labels and choose **Apply Filter** action. If no label is selected, it will ask you to **PROCEED** or **CANCEL**. If you choose to proceed the filters will be cleared returning the table and graph to default view. | ||
|
||
 | ||
|
||
## 3. Request Details | ||
|
||
This table provides a breakdown of the resource requests from different tenants, displaying both the requested resources (CPU and memory) and the allocated quotas. It helps to monitor if tenant requests align with the quotas set for each tenant, ensuring optimal resource management. | ||
|
||
 |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,135 @@ | ||
# Configuration | ||
|
||
## User Roles and Permissions | ||
|
||
### Administrators | ||
|
||
Administrators have overarching access to the console, including the ability to view all namespaces and tenants. They have exclusive access to the IntegrationConfig, allowing them to view all the settings and integrations. | ||
|
||
 | ||
|
||
### Tenant Users | ||
|
||
Regular tenant users can monitor and manage their allocated resources. However, they do not have access to the IntegrationConfig and cannot view resources across different tenants, ensuring data privacy and operational integrity. | ||
|
||
## Caching and Database | ||
|
||
MTO integrates a dedicated database to streamline resource management. Now, all resources managed by MTO are efficiently stored in a Postgres database, enhancing the MTO Console's ability to efficiently retrieve all the resources for optimal presentation. | ||
|
||
The implementation of this feature is facilitated by the Bootstrap controller, streamlining the deployment process. This controller creates the PostgreSQL Database, establishes a service for inter-pod communication, and generates a secret to ensure secure connectivity to the database. | ||
|
||
Furthermore, the introduction of a dedicated cache layer ensures that there is no added burden on the Kube API server when responding to MTO Console requests. This enhancement not only improves response times but also contributes to a more efficient and responsive resource management system. | ||
|
||
## Authentication and Authorization | ||
|
||
### Keycloak for Authentication | ||
|
||
MTO Console incorporates Keycloak, a leading authentication module, to manage user access securely and efficiently. Keycloak is provisioned automatically by our controllers, setting up a new realm, client, and a default user named `mto`. | ||
|
||
#### Benefits | ||
|
||
- Industry Standard: Offers robust, reliable authentication in line with industry standards. | ||
- Integration with Existing Systems: Enables easy linkage with existing Active Directories or SSO systems, avoiding the need for redundant user management. | ||
- Administrative Control: Grants administrators full authority over user access to the console, enhancing security and operational integrity. | ||
|
||
### PostgreSQL as Persistent Storage for Keycloak | ||
|
||
MTO Console leverages PostgreSQL as the persistent storage solution for Keycloak, enhancing the reliability and flexibility of the authentication system. | ||
|
||
It offers benefits such as enhanced data reliability, easy data export and import. | ||
|
||
#### Benefits | ||
|
||
- Persistent Data Storage: By using PostgreSQL, Keycloak's data, including realms, clients, and user information, is preserved even in the event of a pod restart. This ensures continuous availability and stability of the authentication system. | ||
- Data Exportability: Customers can easily export Keycloak configurations and data from the PostgreSQL database. | ||
- Transferability Across Environments: The exported data can be conveniently imported into another cluster or Keycloak instance, facilitating smooth transitions and backups. | ||
- No Data Loss: Ensures that critical authentication data is not lost during system updates or maintenance. | ||
- Operational Flexibility: Provides customers with greater control over their authentication data, enabling them to manage and migrate their configurations as needed. | ||
|
||
### Built-in module for Authorization | ||
|
||
The MTO Console is equipped with an authorization module, designed to manage access rights intelligently and securely. | ||
|
||
#### Benefits | ||
|
||
- User and Tenant Based: Authorization decisions are made based on the user's membership in specific tenants, ensuring appropriate access control. | ||
- Role-Specific Access: The module considers the roles assigned to users, granting permissions accordingly to maintain operational integrity. | ||
- Elevated Privileges for Admins: Users identified as administrators or members of the clusterAdminGroups are granted comprehensive permissions across the console. | ||
- Database Caching: Authorization decisions are cached in the database, reducing reliance on the Kubernetes API server. | ||
- Faster, Reliable Access: This caching mechanism ensures quicker and more reliable access for users, enhancing the overall responsiveness of the MTO Console. | ||
|
||
## Setting Up User Access in Keycloak for MTO Console | ||
|
||
This guide walks you through the process of adding new users in Keycloak and granting them access to Multi Tenant Operator (MTO) Console. | ||
|
||
### Accessing Keycloak Console | ||
|
||
- Log in to the OpenShift Console. | ||
- Go to the 'Routes' section within the 'multi-tenant-operator' namespace. | ||
|
||
 | ||
|
||
- Click on the Keycloak console link provided in the Routes. | ||
- Login using the admin credentials (default: admin/admin). | ||
|
||
### Adding new Users in Keycloak | ||
|
||
- In the Keycloak console, switch to the `mto` realm. | ||
|
||
 | ||
|
||
- Go to the `Users` section in the `mto` realm. | ||
- Follow the prompts to add a new user. | ||
|
||
 | ||
|
||
- Once you add a new user, here is how the Users section would look like | ||
|
||
 | ||
|
||
### Accessing MTO Console | ||
|
||
- Go back to the OpenShift Console, navigate to the Routes section, and get the URL for the MTO Console. | ||
- Open the MTO Console URL and log in with the newly added user credentials. | ||
|
||
Now, at this point, a user will be authenticated to the MTO Console. But in order to get access to view any Tenant resources, the user will need to be part of a Tenant. | ||
|
||
### Granting Access to Tenant Resources | ||
|
||
- Open Tenant CR: In the OpenShift cluster, locate and open the Tenant Custom Resource (CR) that you wish to give access to. You will see a YAML file similar to the following example: | ||
|
||
```yaml | ||
apiVersion: tenantoperator.stakater.com/v1beta3 | ||
kind: Tenant | ||
metadata: | ||
name: arsenal | ||
spec: | ||
quota: small | ||
accessControl: | ||
owners: | ||
users: | ||
- [email protected] | ||
groups: | ||
- arsenal | ||
editors: | ||
users: | ||
- [email protected] | ||
viewers: | ||
users: | ||
- [email protected] | ||
``` | ||
- Edit Tenant CR: Add the newly created user's email to the appropriate section (owners, editors, viewers) in the Tenant CR. For example, if you have created a user `[email protected]` and wish to add them as an editor, the edited section would look like this: | ||
|
||
```yaml | ||
editors: | ||
users: | ||
- [email protected] | ||
- [email protected] | ||
``` | ||
|
||
- Save Changes: Save and apply the changes to the Tenant CR. | ||
|
||
### Verifying Access | ||
|
||
Once the above steps are completed, you should be able to access the MTO Console now and see alpha Tenant's details along with all the other resources such as namespaces and templates that John has access to. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,35 @@ | ||
# Dashboard | ||
|
||
The dashboard serves as a centralized monitoring hub, offering insights into the current state of tenants, namespaces, and quotas. It is designed to provide a quick summary/snapshot of MTO resources' status. Additionally, it includes a Showback graph that presents a quick glance of the seven-day cost trends associated with the namespaces/tenants based on the logged-in user. | ||
|
||
By default, MTO Console will be disabled and has to be enabled by setting the below configuration in IntegrationConfig. | ||
|
||
```yaml | ||
components: | ||
console: true | ||
ingress: | ||
ingressClassName: <ingress-class-name> | ||
console: | ||
host: tenant-operator-console.<hostname> | ||
tlsSecretName: <tls-secret-name> | ||
gateway: | ||
host: tenant-operator-gateway.<hostname> | ||
tlsSecretName: <tls-secret-name> | ||
keycloak: | ||
host: tenant-operator-keycloak.<hostname> | ||
tlsSecretName: <tls-secret-name> | ||
showback: true | ||
trustedRootCert: <root-ca-secret-name> | ||
``` | ||
`<hostname>` : hostname of the cluster | ||
`<ingress-class-name>` : name of the ingress class | ||
`<tls-secret-name>` : name of the secret that contains the TLS certificate and key | ||
`<root-ca-secret-name>` : name of the secret that contains the root CA certificate | ||
|
||
>Note: `trustedRootCert` and `tls-secret-name` are optional. If not provided, MTO will use the default root CA certificate and secrets respectively. | ||
|
||
Once the above configuration is set on the IntegrationConfig, MTO would start provisioning the required resources for MTO Console to be ready. In a few moments, you should be able to see the Console Ingress in the `multi-tenant-operator` namespace which gives you access to the Console. | ||
|
||
For more details on the configuration, please visit [here](../crds-api-reference/integration-config.md). | ||
 |
19 changes: 18 additions & 1 deletion
19
...ent/how-to-guides/hibernation-workflow.md → content/console/hibernation.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,5 @@ | ||
# Namespaces | ||
|
||
Users can view all the namespaces that belong to their tenant, offering a comprehensive perspective of the accessible namespaces for tenant members. This section also provides options for detailed exploration. | ||
|
||
 |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,13 @@ | ||
# Overview | ||
|
||
This documentation is divided into the following sections to guide you through MTO’s Console capabilities: | ||
|
||
- [Dashboard](./overview.md) – Overview of the UI and how to navigate. | ||
- [Tenants](./tenants.md) – Managing and configuring tenants. | ||
- [Namespaces](./namespaces.md) – Creating and organizing namespaces. | ||
- [Hibernation](./hibernation.md) – Pausing workloads to optimize costs. | ||
- [Cost Analysis](./showback.md) – Monitoring usage and cost breakdowns. | ||
- [Quotas](./quotas.md) – Enforcing resource allocation policies. | ||
- [Templates](./templates.md) – Using templates to streamline namespace creation. | ||
- [Capacity Planning](./capacity-planning.md) – Strategies for managing cluster capacity efficiently. | ||
- [Configuration](./configuration.md) – Configuration of the console. |
Oops, something went wrong.