Skip to content

Add dynamic ingress hostname and NodePort env vars - v2#273

Draft
pcfreak30 wants to merge 2 commits intoakash-network:mainfrom
LumeWeb:env-v2
Draft

Add dynamic ingress hostname and NodePort env vars - v2#273
pcfreak30 wants to merge 2 commits intoakash-network:mainfrom
LumeWeb:env-v2

Conversation

@pcfreak30
Copy link

This version is a complete redesign in approach and requires sourcing in bash a config.env file which is added to a emptydir mount.

The configurations are discovered via an init container added to every deployment, be it a statefulset or deployment 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.

@cloud-j-luna
Copy link
Member

Could you please rebase this branch?

AkashRoleBinding = "akash-binding"

// Init container script
akashInitScript = `
Copy link
Member

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

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cloud-j-luna

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...

Copy link
Member

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.

Copy link
Author

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.

@coderabbitai
Copy link

coderabbitai bot commented Jul 31, 2025

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

  • 🔍 Trigger a full review
✨ Finishing touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@pcfreak30
Copy link
Author

Could you please rebase this branch?

done.

 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)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants