A requested feature is to have a CRD that simplifies the publishing of Kode instances.
Each Kode resource should belong to a single user, and only that user. This could be accomplished in many different ways.
Subdomains
Assign a unique subdomain for each user's instance. For example, user1.kode.example.com, user2.kode.example.com.
A sub-path for each Kode instance is required.
Advantages:
Clear isolation at the DNS level.
Easy to implement with Ingress API or Gateway API.
Scales well with a large number of users.
Can use wildcard SSL certificates to secure all subdomains.
Disadvantages:
Requires DNS configuration to support wildcard subdomains.
May have more complex DNS and SSL management.
URL Paths
Use URL paths to differentiate users, such as kode.example.com/user1, kode.example.com/user2.
A sub-path for each Kode instance is required.
Advantages:
Easier to manage a single domain.
Simpler DNS and SSL certificate management.
Also scales well with large number of users.
Disadvantages:
Requires careful configuration to ensure no path conflicts.
May require more complex routing rules in the Ingress API or Gateway API.
Less isolation compared to subdomains.
Unique Ports
Assign a unique port for each user's instance, such as kode.example.com:3001, kode.example.com:3002.
A sub-path for each Kode instance is required.
Advantages:
Simple and straightforward implementation.
No need for complex DNS configuration.
Disadvantages:
Not user-friendly; users have to remember port numbers.
Limited number of ports available, not scalable for a large number of users.
Might require firewall adjustments.
Summary & Reflection
There are more options like utilizing a service-mesh within Kubernetes to route traffic, but that would require this project to integrate with each service-mesh out there and that would take to much time.
The Unique port option is simple but a bit ugly. I foresee some use-cases where this might be wanted. For example in single cluster deployments, and where there are no easy way to configure DNS and access to certificates.
The Subdomain and URL Paths options are both the standard elsewhere in the industry and are relatively easy to implement.
I might also add support for External-DNS as an option to just using wildcard DNS records.
A requested feature is to have a CRD that simplifies the publishing of Kode instances.
Each Kode resource should belong to a single user, and only that user. This could be accomplished in many different ways.
Subdomains
Assign a unique subdomain for each user's instance. For example,
user1.kode.example.com
,user2.kode.example.com
. A sub-path for each Kode instance is required.Advantages:
Disadvantages:
URL Paths
Use URL paths to differentiate users, such as
kode.example.com/user1
,kode.example.com/user2
. A sub-path for each Kode instance is required.Advantages:
Disadvantages:
Unique Ports
Assign a unique port for each user's instance, such as
kode.example.com:3001
,kode.example.com:3002
. A sub-path for each Kode instance is required.Advantages:
Disadvantages:
Summary & Reflection
There are more options like utilizing a service-mesh within Kubernetes to route traffic, but that would require this project to integrate with each service-mesh out there and that would take to much time.
The Unique port option is simple but a bit ugly. I foresee some use-cases where this might be wanted. For example in single cluster deployments, and where there are no easy way to configure DNS and access to certificates.
The Subdomain and URL Paths options are both the standard elsewhere in the industry and are relatively easy to implement. I might also add support for External-DNS as an option to just using wildcard DNS records.