Openstack LB SG update with Port addtion

gistfile1.txt

1.) First all create a LB svc:


kind: Service
apiVersion: v1
metadata:
  name: ingress-nginx
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
spec:
  type: LoadBalancer
  selector:
    app.kubernetes.io/name: ingress-nginx
  ports:
    - name: https
      port: 443
      targetPort: https
    - name: http
      port: 80
      targetPort: http

 
 2.) Then update the same svc by adding another port

kind: Service
apiVersion: v1
metadata:
  name: ingress-nginx
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
spec:
  type: LoadBalancer
  selector:
    app.kubernetes.io/name: ingress-nginx
  ports:
    - name: https
      port: 443
      targetPort: https
    - name: http
      port: 80
      targetPort: http
    - name: ssh
      port: 22
      targetPort: 22      

 The Openstack SG does not reflect the new port that was added to the svc, so traffic to this port will fail.

the new port has nothing to do with Openstack SG. How do config the security group rules for the worker nodes?

If the new port is not added to the Openstack SG, traffic to that port will fail.

I think the best way for you to get a glimpse of what I am saying is to do the following:

1.) Create a LB service type initially with just one port

2.) Test that you can access that port outside the openstack cluster (e.g. from the internet).

3.) Update the same LB by adding another port to it.

4.) Check if you can access the new port

N.B - Below is the cloud-config template I am using:

cloudConfig: |
[Global]
username="admin"
password="VXdffgvrgvvvHC"
auth-url="https://keystone.redacted:5000/v3"
domain-name="Default"
region="dbl"
tenant-name="redactedk8s"

[LoadBalancer]
lb-version = "v2"
subnet-id = "c1509fca-1872-40b9-a7b5-5cc01d611d6f"
floating-network-id = "8bb661f5-76b9-45f1-9ef9-eeffcd025fe4"
lb-method = "ROUND_ROBIN"
manage-security-groups = true

1.) Create a test svc:

kind: Service
apiVersion: v1
metadata:
  name: test
  labels:
    app: test
spec:
  type: LoadBalancer
  selector:
    app: test
  ports:
    - name: https
      port: 443
      targetPort: https
    - name: http
      port: 80
      targetPort: http

Openstack objects that relates to the LB:

SG that is created by the openstack-provider:

SG rules that was created for the LB:

2.) Now update the LB:

kind: Service
apiVersion: v1
metadata:
  name: test
  labels:
    app: test
spec:
  type: LoadBalancer
  selector:
    app: test
  ports:
    - name: https
      port: 443
      targetPort: https
    - name: http
      port: 80
      targetPort: http
    - name: ssh
      port: 22
      targetPort: 22

Kubernetes service :

Name:                     test
Namespace:                default
Labels:                   app=test
Annotations:              kubectl.kubernetes.io/last-applied-configuration:
                            {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"labels":{"app":"test"},"name":"test","namespace":"default"},"spec":{"por...
Selector:                 app=test
Type:                     LoadBalancer
IP:                       10.107.43.245
LoadBalancer Ingress:     195.192.129.141
Port:                     https  443/TCP
TargetPort:               https/TCP
NodePort:                 https  30786/TCP
Endpoints:                <none>
Port:                     http  80/TCP
TargetPort:               http/TCP
NodePort:                 http  30567/TCP
Endpoints:                <none>
Port:                     ssh  22/TCP
TargetPort:               22/TCP
NodePort:                 ssh  30167/TCP
Endpoints:                <none>
Session Affinity:         None
External Traffic Policy:  Cluster

Openstack SG rules remains the same, port 22 was not added to the rules:

N.B -- I have tested this same scenario on AWS and the SG is always updated when a new port is added or removed

OK, seems like you are still using neutron-lbaas, unfortunately, I don't have experience of using neutron-lbaas since it has been deprecated a while ago and doesn't have some advanced features for us.

The supported LB solution now is only Octavia?

it should work for most of the scenarios but not for this case, I'm not 100% sure because i'm not a neutron-lbaas user. Octavia is using a different deployment model with neutron-lbaas and takes good care of sgs for the lb.

Ok.. Could please kindly try the scenario on Octavia, I currently don't have access to an Octavia based Openstack cluster.