quarkus: Openshift extension does not create a service for a management interface

Describe the bug

I have an application, deployed on Openshift via Quarkus-openshift extension, which uses separate management interface[1].

After an update to Quarkus 3.2.0, the interface can not be accessed anymore, since this port is not exposed as a part of a service. [1] https://quarkus.io/guides/management-interface-reference

Expected behavior

The port is exposed as a part of a service, same as for 3.1.0.

Generated file target/kubernetes/openshift.yml should contains service description like this:

---
apiVersion: v1
kind: Service
metadata:
  annotations:
<...>
  labels:
    app.kubernetes.io/name: openshift-quickstart
<...>
  name: openshift-quickstart
spec:
  ports:
    - name: http
      port: 80
      protocol: TCP
      targetPort: 8080
    - name: https
      port: 443
      protocol: TCP
      targetPort: 8443
    - name: management
      port: 9000
      protocol: TCP
      targetPort: 9000
  selector:
    app.kubernetes.io/name: openshift-quickstart
    app.kubernetes.io/version: 1.0.0-SNAPSHOT
  type: ClusterIP
---

and oc describe svc/openshift-quickstart should return this:

Name:              openshift-quickstart
Namespace:         fd-test
Labels:            app.kubernetes.io/managed-by=quarkus<...>
Annotations:  <...>
Selector:          app.kubernetes.io/name=openshift-quickstart,app.kubernetes.io/version=1.0.0-SNAPSHOT
Type:              ClusterIP
IP Family Policy:  SingleStack
IP Families:       IPv4
IP:                $EDITED
IPs:               $EDITED
Port:              http  80/TCP
TargetPort:        8080/TCP
Endpoints:         $EDITED1:8080
Port:              https  443/TCP
TargetPort:        8443/TCP
Endpoints:         $EDITED:8443
Port:              management  9000/TCP
TargetPort:        9000/TCP
Endpoints:         $EDITED:9000
Session Affinity:  None
Events:            <none>

Actual behavior

The generated file looks like this:

---
apiVersion: v1
kind: Service
metadata:
  annotations:
<...>
  labels:
    app.kubernetes.io/name: openshift-quickstart
<...>
  name: openshift-quickstart
spec:
  ports:
    - name: http
      port: 80
      protocol: TCP
      targetPort: 8080
  selector:
    app.kubernetes.io/name: openshift-quickstart
    app.kubernetes.io/version: 1.0.0-SNAPSHOT
  type: ClusterIP

and the deployed service like that:

Name:              openshift-quickstart
Namespace:         fd-test
Labels:            app.kubernetes.io/managed-by=quarkus
<...>
Annotations:    <...>
Selector:          app.kubernetes.io/name=openshift-quickstart,app.kubernetes.io/version=1.0.0-SNAPSHOT
Type:              ClusterIP
IP Family Policy:  SingleStack
IP Families:       IPv4
IP:                $EDITED
IPs:               $EDITED
Port:              http  80/TCP
TargetPort:        8080/TCP
Endpoints:         $EDITED:8080
Session Affinity:  None
Events:            <none>

How to Reproduce?

  1. git@github.com:fedinskiy/reproducer.git -b openshift-extension-management
  2. mvn clean install -Dquarkus.kubernetes.deploy=true -Dquarkus.openshift.route.expose=true -Dquarkus.kubernetes-client.trust-certs=true -Dquarkus.platform.version=3.2.0.Final

Run mvn clean install -Dquarkus.kubernetes.deploy=true -Dquarkus.openshift.route.expose=true -Dquarkus.kubernetes-client.trust-certs=true -Dquarkus.platform.version=3.1.0.Final for expected result.

Output of uname -a or ver

6.3.8-200.fc38.x86_64

Output of java -version

17.0.5, vendor: GraalVM Community

GraalVM version (if different from Java)

No response

Quarkus version or git rev

3.2.0.Final

Build tool (ie. output of mvnw --version or gradlew --version)

Apache Maven 3.8.7 (b89d5959fcde851dcb1c8946a785a163f14e1e29)

Additional information

No response

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Comments: 15 (14 by maintainers)

Commits related to this issue

Most upvoted comments

It won’t work when you have multiple replicas, as you will have the round-robin. The management interface is not intended to be used using a round robin

I am fine with management port being exposed through route, as it happens now (although it looks less secure, than in 3.1.0) but in that case we also need an option to expose HTTP(S) alongside it.