Navigate Control Hub

ControlHub is the console for Olares, providing developers and users with precise control over system operations and the underlying environment. This guide helps you understand Control Hub's interface and efficiently monitor your resources.

Navigation

Olares

Monitor the status of applications in three different views:

• Browse (Application-centric view): Navigate through resource usage related to specific applications using a three-column layout for efficient resource location.
• Namespace (User-centric view): Access detailed insights into per-user application resource consumption, with sorting and filtering capabilities.
• Pods: Monitor pod status and resource consumption at the finest granularity.

Resource

View and manage Kubernetes system resources.

• Networks: Monitor network security policies implemented in the system and the network connectivity of each namespace.
• CRDs: Manages various custom resource declarations in the system.

Middleware

View the usage of various middleware services in Olares.

Browse

The Browse section organizes resources into two main namespace categories:

• User projects include each Olares user's independent namespace.
  • user-space-*: Built-in user applications
  • user-system-*: User-related system programs including TAPR components, schedulers, proxies for cross-application interaction
• System projects include core applications of Olares's cluster, along with system-level service programs.

INFO

Olares members can only access their own namespaces, while Olares admin can access all user and system namespaces.

You can view all resource types within the namespace in the second column.

Workloads

In Olares, Workloads represent applications running on your Olares cluster. They correspond to three primary resource types in Kubernetes.

• Deployment

  • The most common workload type in Kubernetes.
  • Automatically generates a ReplicaSet to schedule and generate Pods, creating more Pod replicas for horizontal scaling.

• StatefulSet

  • Used to deploy stateful Pods, such as Pods for databases, distributed file storage, or in-memory caching.
  • Each Pod may hold different data, resulting in Pods with different states. Therefore, StatefulSet often schedules Pods sequentially.

• DaemonSet

  • Schedules and runs only one Pod on each node. The number of Pods generated by a daemon set is usually equal to the number of nodes.
  • Used for node-specific hardware operations.

Workloads details

You can view the following information for a workload resource:

• Details: The general information of the resource.
• Pods: The general information of Pods.
• Ports: All exposed port collections from the workload's Pod containers.
• Environment Variables: Environment variables defined at the workload level in the Pod template.
• Labels: Configured in the workload metadata. Used for controller management coordination in Olares. Can also act as indexes for filtering and selecting resources in Kubernetes.
• Annotations: Similar to labels but more flexible and character range. Serve as a tool for controllers to manage workloads.
• Events: Log of events related to the workload within the latest one hour, often showing Pod scheduling status.

Pod details

You can view the following information for a Pod:

• Details: The general information of the pod.
• Containers: A list of containers within the Pod.
• Volumes: Persistent volumes configured for the Pod.
• Environment Variables: Environment variables defined for the Pod.
• Events: Chronological log of events related to the Pod.

Secrets

The Secrets section stores sensitive data like passwords, credentials, and key configurations. In Kubernetes, this data is Base64 encoded by default.

Expand the Secrets section in the second column to see the all secrets under the application's namespace.

You can view the following information for the secret:

• Details: The basic information of the secret, including the namespace it belongs to and the creation time.
• Data: The Data Key and Data Value of the secret.

TIP

The Data Value shown by default is the Base64 encoded. You can click the preview button at the top right of this section to see the original text.

ConfigMap

The ConfigMap section has a structure similar to Secrets. However, the content stored in the ConfigMap is saved in plaintext.

Expand the ConfigMaps section in the second column to view the details of the ConfigMaps under the application's namespace.

You can view the following information for the configmap:

• Details: The basic information of the ConfigMap, including the namespace and creation time.
• Data: The Data Key and Data Value of the ConfigMap.

Service accounts

Service Accounts is a Kubernetes mechanism to authenticate cluster container applications, enabling their access to cluster resources managed by Kubernetes.

Each Service Account is linked to a Secret. This Secret includes the Service Account's CA certificate, Namespace, and Token.

Expand the second column on the Service Accounts section to view all the Service Accounts under the application's namespace.

You can view the following information for the service account:

• Details: The basic information of the Service Account, including the namespace it belongs to, creation time, etc.
• Data: The Data Key and Data Value of the Secret linked to this Service Account.
• Kubeconfig Settings: The kubeconfig configuration automatically generated by this Service Account. Developers can download this configuration and incorporate it into an application within the container. Alternatively, an application in the container can read the Service Account configuration injected by Kubernetes at /var/run/secrets/kubernetes.io/serviceaccount/.

Services

Services expose network applications running on a single or a group of Pods as network services. They distribute traffic based on defined Selectors.

A Selector uses Labels to filter and select Pods. Essentially, a Service acts as a virtual IP (VIP) that directs traffic to a single Pod or a group of Pods.

Expand the Services section in the second column to view all the Services` under the namespace of the current application.

You can view the following information for the service:

• Details: The basic information of the Service, including its namespace, creation time, selector, virtual IP, type, and DNS address.
• Workloads: All workloads selected by the Service's selector, including name and status.
• Ports: All exposed ports, including port number, protocol, and upstream destination port number.
• Pods: All Pods selected by the Service's selector, including name, node, IP address, and recent CPU and memory charts. An empty list may indicate a Service issue.
• Labels: The Service's labels.
• Annotations: The Service's annotations.
• Events: All events related to the Service.

Namespace

The Namespace section in ControlHub provides a user-centric view of resource consumption and workload conditions on your Olares.

Usage Ranking

Usage Ranking organizes system resource consumption by namespace.

You can view the following information for the namespace:

• Quota: System resource usage percentage of this namespace.
• Pods: All pods within the namespace, sorted by resource consumption, with the option to search by keyword.

Resources

The Resources section displays a chart of current and historical resource utilization.

You can view the total resource usage by all users. Alternatively, select a specific user from the dropdown box to view individual resource consumption.

Pods

The Pods section page provides a comprehensive view of all Pods in your Olares environment, allowing you to manage them at the smallest granularity offered by Kubernetes.

You can view the following information:

• Pod List: All Pods within your Olares.
• Resource: A visual representation of the physical resources consumed by your Pods. This view helps you understand how your cluster's resources are being utilized.

Resource

The Resource section includes resources related to both software and hardware in Olares. For software, it encompasses cluster descriptions, feature definitions, and declarations of cluster states, etc. For hardware, it contains details about networks, storage, devices, etc.

Network

Network Policies is one of the most important network resource in Olares. They define how the network connects. The system utilizes a sandbox mechanism for network policies, which restricts interactions based on the namespace. This provides isolation between the networks of different users and applications.

Ingress Rule

Shows a list of rules that specify which incoming traffic is allowed into a Namespace:

• Only the traffic from the pod in the namespace, which matches the label specified in the rule, is allowed.
  
• The AND logic is applied for each label within a rule.
  
• he OR logic is applied between the rules in the list.

Egress Rule

Similar to the Ingress Rule, it also displays a list of rules that specify which outgoing traffic is allowed out of a Namespace.

CRDs

CRDs list all the Kubernetes-based Custom Resource Definitions (CRDs) in Olares. Many cloud-native features of Olares depend on these CRDs. You can see the following information for the CRDs:

• Details: Shows the name, group, scope level, and creation time of the CRD. There are two types of CRD scopes:

  • Namespace: Indicates that each custom resource belongs to a namespace.

  • Cluster: Indicates that each custom resource must be globally unique and does not belong to any Namespace. For instance, the Namespace itself is a resource at the cluster level.

• Custom Resource: All the custom resources under this CRD, including their names and creation times.

Middleware

The Middleware section allows you to manage middleware in Olares.

TIP

Only administrators can access the Middleware page.

You can see the following information for the middleware:

• Details: Cluster data, including cluster name, deployment namespace, access address, and administrator password.
• Database: An overview of the databases utilized by different applications within Olares, including database name, user, and passwords.