Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update README.md #212

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Update README.md #212

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 22 additions & 1 deletion k8s/docs/06-FAQs/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -22,7 +22,7 @@ TigerGraph's exceptional performance comes with certain considerations regarding

For your optimal experience, it is strongly recommended to start a backup operation before starting any upgrade or scaling activities. This precautionary measure ensures the safety of your data and system integrity.

## How to know the status of cluster management? Do I need to confirm stat before modifying TigerGraph cluster CR configuration?
## How can I know the status of cluster management? Do I need to confirm stat before modifying TigerGraph cluster CR configuration?

In essence, TigerGraph does not inherently maintain a record of the cluster status throughout its lifecycle. However, understanding the status of the TigerGraph cluster is pivotal for the TigerGraph Operator. This insight empowers the Operator to determine which operations can be executed at any given moment.

Expand Down Expand Up @@ -83,3 +83,24 @@ listener:
type: LoadBalancer
replicas: 3
```

## What is the purpose and functionality of the custom resource definition in the current setup?
Custom Resource Definition(CRD) is used to define and describe the specifications of creating TG on K8s. When implemented, the end user only needs to care about CRD instead of the native K8s resources such as StatefulSet, and Job.

## Is it feasible to install multiple instances of TigerGraph, such as development, testing, and production environments, on a single EKS cluster?
Yes, the current version supports this feature. The simple way is to install one operator with the cluster scope option enabled `kubectl tg init --cluster-scope true`, or you can install a namespace-scoped operator `kubectl tg init --cluster-scope false` which only watches and manages resources for a specific namespace. When choosing this option, different teams can manage their TG cluster in a certain namespace with their operator.(https://github.com/tigergraph/ecosys/blob/master/k8s/docs/03-deploy/tigergraph-on-eks.md#install-tigergraph-operator)

## Is the cert manager directly involved with the webhooks, and if so, how? What is the cert manager doing?
In Kubernetes, webhooks are typically used for validating admission requests, such as validating that a resource being created or modified adheres to certain policies. These policies can include security, compliance, or custom business rules. Cert Manager can be used to manage TLS certificates for services that expose webhooks.

## Why are there multiple TigerGraph operators in the TigerGraph namespace? We observed three pods labeled as "operator" – are these simply scaled replicas, or do they serve distinct functions?
For a cluster-scoped Operator, there will be only one Operator in a specific namespace. The namespace-scoped operator will be installed for each namespace that you want to manage and deploy TigerGraph on. Operator installation will create a Deployment resource on K8s, and multiple pods that are labeled as “operator” belong to this Deployment, which is used to enable High availability of Operators. You can specify and update the pod numbers of the Operator with `kubectl tg init/upgrade --operator-size 3`, the default value is 3.

## How does Kubernetes handle situations where the GSQL leader or another node fails?
K8s will schedule new pods to another available node if node failures happen. The High Availability of GSQL is the same as we have on-premise; leader switch will be done automatically if your GSQL replication is more than 1.

## Does using `kubectl destroy` change the cluster configuration to 1 by 3, or is it necessary to modify the YAML file for this purpose?
We don't have to necessarily do it only via YAML edit - we can also go from a 1x1 to a 1x3 with the operator by running `kubectl tg update --cluster-name ${YOUR_CLUSTER_NAME} --size 3 --ha 1 --namespace ${YOUR_NAMESPACE}` We support YAML and kubeclt-tg two modes to manage TG clusters on K8s

## Is it possible to restore a 3 node cluster from a 2 node cluster configuration, and if so, how?
A simple rule for restore: partition must be consistent, replication can be different. (https://graphsql.atlassian.net/wiki/spaces/infra/pages/3082879046/Scenarios+that+support+restore)
Loading