I want a K8s service account to be created by proper setting in Dgraph’s helm chart values.yaml file.
What I did
I used helm chart to install Dgraph in EKS cluster. The serviceAccount config in values.yamlDgraph Helm Chart Values doesn’t create the K8s service account when it’s been installed though the attribute create is set as true. Both version, v21.12.0 and v23.0.1 failed.
Hey Joaquin, this is the details of the k8s versions and EKS version that I’m using. Let me adjust my config by aligning with yours and get back to you with the result.
Client Version: v1.27.1
Kustomize Version: v5.0.1
Server Version: v1.27.4-eks-2d98532
I have also installed this with K8S (EKS) 1.26, with an IAM Role for S3 bucket access for backups, and have not encountered any issues. Though with this one, I used the default dgraph sa name.
As for dgraph sa name, do you mean super admin name?
I just followed your example, unfortunately no serviceAccountName gets returned.
Here is the my test file service-acct.yaml except for the version difference for labels’ chart, the rest is aligned with yours.
What’s odd is that using kubectl to create the service account with the same yaml file, there’s no any problem.
# create service account
$ kubectl apply -f deploy/dev/dgraph/service-acct.yaml
# check service account
$ kubectl get serviceaccount -n dgraph
# it returns:
# NAME SECRETS AGE
# demo-service-account 0 107m
@joaquin Did you use eksctl to set up your k8s cluster on the cloud? I’m using Terraform code to set up all the infrastructure stuff on the cloud. First I wonder if this difference between your testing and mine is caused by different tools we’re using or not, then it’s proven false because I packed a helm chart for my own app with configuration in its values.yaml file almost the same as what I set in Dgraph’s values.yaml file, when it’s installed using helm, the service account was created immediately and successfully. At least this tells me that there’s nothing wrong with the way I use helm install.
This is what I set for my own app’s chart values.yaml.
serviceAccount:
create: true
# Annotations to add to the service account
annotations:
eks.amazonaws.com/role-arn: arn:aws:iam::xxxxxxxxxxx:role/demo-iam-role
# The name of the service account to use.
# If not set and create is true, a name is generated using the fullname template
name: "myapp-service-account"
When you grep’d for serviceAccountName, you got 2 entries, one for alpha sts and one for zero sts? This would indicate that the service account is indeed created and that STS will use the said service account.
The whole permissions may not work, that would be a different issue, and could be related to how you provisioned it with Terraform. Below is automation I used with eksctl for comparison. The eksctl is doing a lot of hand-holding automation under the hood, so you may need to compare many resources to get equivalency. eksctl uses the reference infra-as-code (AWS cloudformation code) as the guideline, so they will also have tags and such needed by other drivers and resources.
For reference, this is how I provision the resources with eksctl.
I’ve just double checked the infrastructure terraform code, it looks fine, and I destroyed all and re-applied all. Here is the complete dgraph dgraph-values.yaml file I’m using, excuse me that I have to hide some sensitive information.
This looks problematic, as the default driver doesn’t work out of the box after Kubernetes 1.23+. Amazon doesn’t support the in-tree driver anymore, and recommend using the EBS CSI drvier for persistent volume support.
I have EBS CSI drvier added as Add-on to EKS, also give node permission to obtain EBS volume per its need.
Here is the screenshot of the driver added to the cluster from aws cli website page.
As far as I observed, some volumes are dynamically attached to the currently Only 1 node dgraph-node-dev even including a snapshot for Dgraph to use, and I haven’t noticed any exceptions.
I’ll try clean everything tomorrow, I mean uninstall Dgraph and all my services, destroy infrastructure completely. Then begin on a blank slate, try Dgraph v23.0.1 with gp3 as storage class of this dgraph-values.yaml, hope I’m lucky tomorrow to have the service account created successfully.
I have been busy adding features or bug fixes. To get early access, you can download the helm chart, then reference it from the file path. Eventually, the features would be scooped up into a new version.