-
Notifications
You must be signed in to change notification settings - Fork 54
Add dynamic ingress hostname and NodePort env vars - v2 #273
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.
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
base: main
Are you sure you want to change the base?
Conversation
Could you please rebase this branch? |
AkashRoleBinding = "akash-binding" | ||
|
||
// Init container script | ||
akashInitScript = ` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This adds a lot of complexity to the code. I believe you could achieve this using the standard library and the Kubernetes API which would result in a more maintainable PR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From what I found, the only way to access the data is AFTER the container is created which my 1st attempt meant calling creation twice since the API decides on the nodeports... so you end up needing an INIT script to query that data.
I also looked at the kube meta yaml stuff and theres no way to inject the node port info in...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is accessing the data after the container is created through kube api not an option? I'm not a fan of the idea of injecting an init container into deployments that run an embedded shell script from the provider... worst case scenario would at least mount the script instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do not know the possibility if you can access the meta api from within the main container. My original PR was a lot more buggy and involved doing 2 creates as I stated because you had to get the info from kube since kube decides the node ports.
The big question I guess is when/how can a container get information about the nodeports the kube daemon assigns to it. This can def be tricky since it goes to a service entity and not the container itself, IIRC?
I found the "kube yaml meta" cant do it, the kube api decides it, and you have to add in RBAC to enable api access. I don't know if you can do so in the main container like how EC2 can access AWS metaservice API's.
Add environment variables to expose: - Generated ingress hostname (AKASH_INGRESS_HOST) - Custom ingress hostnames per port (AKASH_INGRESS_CUSTOM_HOST_<port>_<index>) This allows containers to be aware of their external access points.
This commit adds a configuration system that discovers and exposes NodePorts: - Add init container that detects service NodePorts and writes to config file - Replace static AKASH_EXTERNAL_PORT env var with dynamic config file - Mount config volume in containers to access port information - Add RBAC permissions for pods to query their own service details - Support fallback for different service types (NodePort, LoadBalancer, ClusterIP)
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the ✨ Finishing Touches🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
done. |
This version is a complete redesign in approach and requires sourcing in bash a
config.env
file which is added to aemptydir
mount.The configurations are discovered via an init container added to every deployment, be it a
statefulset
ordeployment
type.The default
serviceaccount
is modified to add a RBAC rule to ensure the init container can read the data needed to write the file.Several experiments were tested to try and make everything be auto injected as ENV's but it was too brittle and required knowledge of the images themselves which the provider does not have at the time of creation of k8 resources.