You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Many users trying out our Kubernetes charts are new to k8s.
One of the first questions asked or issues hit, is being able to access egeria (chassis, UI etc)
Our charts support 'nodeports'. This is where a port is made available on the IP address currently used by the kubernetes workers. This may not be useful in a cloud environment where there are additional restrictions, firewalls, and capabilities - using regular ingress may be easier. However for simple local environments - where ingress is hard (needing additional IPs etc) it works well.
This suggestion is to enable nodeports by default. It doesn't preclude other connectivity. The main risk is that a failure to allocate could cause pods not to run.
The text was updated successfully, but these errors were encountered:
Yes - it might also be helpful (at least for testing purposes) if the default nodeport range was different for each kind of chart - so for instance, one could run base and lab charts in the same cluster?
Though note that to run multiple charts, you will need to deploy strimzi seperately, and disable the setup when installing the egeria charts (this is in the docs)
Many users trying out our Kubernetes charts are new to k8s.
One of the first questions asked or issues hit, is being able to access egeria (chassis, UI etc)
Our charts support 'nodeports'. This is where a port is made available on the IP address currently used by the kubernetes workers. This may not be useful in a cloud environment where there are additional restrictions, firewalls, and capabilities - using regular ingress may be easier. However for simple local environments - where ingress is hard (needing additional IPs etc) it works well.
This suggestion is to enable nodeports by default. It doesn't preclude other connectivity. The main risk is that a failure to allocate could cause pods not to run.
The text was updated successfully, but these errors were encountered: