Comment 7 for bug 1884995

This doesn't seem like a bug with Kubernetes, Charmed Kubernetes, nor the integrator.

Per the description of the manage-security-groups option in https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/using-openstack-cloud-controller-manager.md#load-balancer Kubernetes expects the Amphora VM to be within the same subnet as the instance and for the security policy to allow connections within the subnet on the NodePort range (30000-32767). Additionally, Juju generally expects that the instances are inside something like a VPC or subnet where traffic between the instances is generally open, with it managing the port SG rules for public access as controlled via open-port and juju expose.

It sounds like these expectations are not met in this environment, and traffic between the Amphora VMs and the instances is blocked by default. It seems reasonable in that case to defer to the OpenStack admin to manually manage the SG rules in such an environment, since they've already expressed a desire to have more control over what access is allowed within the internal network and it would be unclear whether they would be ok with having Juju or the charms override their decisions.

Since Kubernetes typically chooses the NodePort automatically (although it can be explicitly specified in the Service definition, as long as it falls within the NodePort range), you would presumably want to set up the rules to allow that entire range (again, 30000-32767) from the Amphora VMs to the instances.