GITA - Overview
Table of contents
- GITA - Overview
- Table of contents
- What is GITA?
- How is it organized?
- What are the main features?
- Interesting features on GITA that you will like
- What are the GITA components in the client cluster?
- How can I use GITA?
- How do roles and permissions work?
- Organization Permissions
- Organization Actions
- Cluster Permissions
- Clusters Actions
What is GITA?
GITA is a Kubernetes manager based on best practices. With it, you can see what improvements can be made to your workloads. It also tracks cluster events, as well as alerts and incidents.
How is it organized?
There are two entities on GITA, which are: Organization and Cluster. An Organization is a set of one or more clusters. And a Cluster is a Kubernetes cluster. It is important to note that the financial entity is the Organization.
This is an example of an Organization view:
This is an example of a dashboard view of a Cluster:
What are the main features?
GITA includes:
- Health: These are checks that indicate the health of the cluster and workloads. They are divided into Events, Alerts and Incidents.
- Events: Events in a Kubernetes cluster are automatic notifications generated by the Kubernetes system to describe something that has happened or is happening in the cluster. They are a way to monitor the behavior of resources and actions within the cluster, helping administrators and operators to diagnose problems and understand what is happening.
- Alerts: These are generated in situations that deserve attention, but that are not impacting the cluster (yet). For example: Disk usage above 90%. There are predefined alert rules on Gita. Access Alerts to see more details.
- Incidents: Indicate unavailability or critical issues in the Kubernetes cluster. For example: An unavailable workload. Examples of incident rules can be seen in the documentation.
- Misconfigurations: These are incorrect, inadequate, or insecure configurations that can lead to operational failures, security vulnerabilities, or performance issues in the cluster. They are usually caused by human error, lack of knowledge, or negligence in the configuration of Kubernetes resources and policies. These failures can impact the security, stability, and reliability of the cluster and the applications running on it.
- Security: These are incorrect configurations that impact the security of the cluster, potentially opening vulnerabilities. Examples are workloads with Excessive or Privileged Resources. Examples of rules can be seen in the official documentation
- Compliance: These are incorrect configurations in the resources Lack of Resource Limits: Pods without CPU and memory limits can consume all available Node resources. Another common example is Deployments Without Readiness or Liveness Probes: Applications that fail are not restarted or removed properly. Examples of compliance rules can be seen in the official documentation.
- Timeline: In our experience, we have noticed that, on average, 87% of incidents in a cluster come from some change - it is very important to find what was changed! The timeline allows you to view everything that was changed in the cluster in a given period of time. A function specially created for you to have visibility of cause and effect.
- Inventory: In the inventory you have access to Kubernetes Workloads, Storage and Services. You can edit (YAML) the objects. In the case of PODS, you can access the console and logs.
Interesting features on GITA that you will like
Here we go, we have some really cool features that will be very useful for you in your day to day. Here are the features:
- Graphical resource tree;
- Management of workload, services, etc…;
- Access to pod console;
- Access to cluster console;
- Access to pod logs in real time;
- Comparison of cluster resources (between clusters and within the same cluster);
- View of computational resources (CPU and RAM);
- Monitoring of Cluster Events;
- YAML import;
- ACK (team monitoring);
- View and edit any Kubernetes resource;
- Generative AI for cluster event insights;
- Events and notifications for health and misconfigurations (security and general).
What are the GITA components in the client cluster?
The following deployments are deployed in the client cluster:
gita-api-manager
(optional) - Allows cluster management, deleting pods, editing, importing yml.gita-probe
- Captures events, workloads, services, ingress and storage (pv, pvc, storage class, configmap, secret, etc.)gita-probe-logs
(optional) - Views pod logs.gita-probe-resources
- Allows cluster resource managementgita-probe-shell-stream
(optional) - Allows instantiating the console in pods
How can I use GITA?
There are two possibilities: You can use it in the SaaS model or in the On Premises model. In the case of the On Premises model, please contact us for a quote. Our email is contato@jackexperts.com.br.
How do roles and permissions work?
For Organizations
Permissions | owner | admin | analyst | viewer | billing |
---|---|---|---|---|---|
Create organization | X | X | X | X | X |
List organizations the user is in | X | X | X | X | X |
Delete organization | X | ||||
List users in the organization | X | X | |||
Change organization name | X | X | |||
Add user to organization | X | X | |||
Add user as billing or owner in organization | X | ||||
Delete user from organization | X | X | |||
Delete user who is billing or owner of organization | X | ||||
Change user permission | X | X | |||
Change user permissions to billing or owner | X | ||||
Create cluster | X | X | |||
List clusters in the organization | X | X | x | ||
View billing dashboard | X | X | X |
For Clusters
Permissions | owner | admin | analyst | viewer |
---|---|---|---|---|
Install cluster | X | X | ||
List cluster users | X | X | ||
Fetch cluster information | X | X | X | X |
Delete cluster | X | |||
Change cluster name | X | X | ||
Add user to cluster as admin or viewer | X | X | ||
Add user to cluster as owner | X | |||
Delete user from cluster if he is (admin or viewer) | X | X | ||
Delete user from cluster if he is (owner) | X | |||
Change user permission if he is (admin or viewer) | X | X | ||
Change user permission if he is (owner) | X | |||
Get cluster status | X | X | X | X |
Disable cluster | X | X | ||
Enable cluster | X | X | ||
Cluster console (terminal) | X | X | X | |
Access pod logs | X | X | X | |
Pod console (terminal) | X | X | X | |
Create, delete, change cluster objects via YAML | X | X | X | |
Create, delete, and change notifications | X | X | X | |
Create, delete, and change rules | X | X | X |
Organization Permissions
- owner: Organization owner with full access.
- admin: Administrator with almost full access, except for some actions reserved for the owner.
- analyst: View-only permission.
- viewer: View-only permission.
- billing: Billing related access.
Organization Actions
Owner:
- Edit and Delete organization;
- Add, remove, edit and list users of the organization;
- Add, remove, edit and list clusters;
- View organization total;
- Access to billing;
- Owner of all clusters of the respective organization;
Admin:
- Edit organization;
- Add, remove, edit (except owner) and list users of the organization;
- Add, remove, edit and list clusters;
- View organization;
Billing:
- Access to billing
- List clusters of the organization
- View organization
Viewer:
- View organization
Cluster Permissions
- owner: Cluster owner with full access.
- admin: Administrator with almost full access, except for some actions reserved for the owner.
- viewer: View-only permission.
Clusters Actions
Owner:
- Install cluster
- Add, remove, edit and list cluster users
- Edit and Delete cluster
- Enable and Disable cluster
- View cluster
- Access to billing
Admin:
- Edit cluster
- Install cluster
- Add, remove, edit (except owner) and list cluster users
- Enable and Disable cluster
- View cluster
Viewer:
- View cluster