Skip to content

[Bug]: LoadBalancer managed additional service updates with patch not reconciliated #10132

New issue
New issue
Closed
#10311
#10190
Closed
[Bug]: LoadBalancer managed additional service updates with patch not reconciliated#10132
#10311
#10190
Assignees
gbartoliniarmru
Labels
bug 🐛Something isn't working

Description

@mikarapace
mikarapace
opened on Mar 4, 2026

Is there an existing issue already for this bug?

  • I have searched for an existing issue, and could not find anything. I believe this is a new bug.

I have read the troubleshooting guide

  • I have read the troubleshooting guide and I think this is a new bug.

I am running a supported version of CloudNativePG

  • I have read the troubleshooting guide and I think this is a new bug.

Contact Details

mbertoni at eudonet.com

Version

1.27 (latest patch)

What version of Kubernetes are you using?

1.32

What is your Kubernetes environment?

Cloud: Other

How did you install the operator?

Helm

What happened?

We use a Cluster CR that contains a managed Load balancer service to expose replicas workers to our datalake systems.
Changing the .spec.managed.services.additional[0].loadBalancerSourceRanges field did not result in reconciliation from the CNPG cluster, when using .spec.managed.services.additional[0].updateStrategy: patch.
Using the replace strategy instead worked properly but results in a downtime.

Cluster resource

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: pg-cluster
  labels:
    env: develop
spec:
  resources:
    requests:
      memory: "1Gi"
      cpu: "50m"
    limits:
      memory: "1Gi"
      cpu: "1"
  affinity:
    enablePodAntiAffinity: true
    podAntiAffinityType: preferred
    topologyKey: kubernetes.io/hostname
  monitoring:
    podMonitorMetricRelabelings:
      - action: replace
        replacement: "develop"
        targetLabel: "env"
  postgresql:
    parameters:
      shared_buffers: "256MB"
      max_connections: "200" # Temporarily increased for development, should be optimized for production based on workload analysis
  # Expose a read-only service for datalake access with restricted IPs and TLS enforcement
    pg_hba:
      # Reject any non-TLS connection attempts explicitly
      # - hostnossl all all all reject  # TODO: re-add to reject any non-TLS connection when impact analysis is done
      # Enforce TLS for datalake_ro limited to scaleway private network IP addresses
      - hostssl app datalake_ro 172.16.0.0/16 scram-sha-256
      # ALLOW ALL USERS FROM INSIDE THE K8S CLUSTER
      - hostssl all all 100.64.0.0/10 scram-sha-256
      # BLOCK ALL OTHER USERS FROM OUTSIDE
      - hostssl all all 0.0.0.0/0 reject
  managed:
    roles:
      - name: datalake_ro
        ensure: present
        comment: Read-only role for datalake access (TLS required)
        login: true
        superuser: false
        inherit: true
        # Connection limit can be adjusted as needed. Default to unlimited (-1).
        connectionLimit: -1
        passwordSecret:
          name: datalake-ro-credentials
      - name: internal_dev_user_crud
        ensure: present
        login: true
        inherit: true
        connectionLimit: -1
        passwordSecret:
          name: external-secret-internal-dev-user-credentials
        inRoles:
          - pg_read_all_data
          - pg_write_all_data
    services:
      additional:
        - selectorType: ro
          serviceTemplate:
            metadata:
              name: cluster-ro-external
              annotations:
                service.beta.kubernetes.io/scw-loadbalancer-type: "LB-S"
            spec:
              type: LoadBalancer
              externalTrafficPolicy: Local  # Preserve client IPs
              loadBalancerSourceRanges:
                - 111.111.111.111
                - 222.222.222.222
          updateStrategy: patch

Relevant log output

1772635124004	2026-03-04T14:38:44.004Z	{"level":"debug","ts":"2026-03-04T14:38:44.004168862Z","msg":"Reconciliation loop start","controller":"cluster","controllerGroup":"postgresql.cnpg.io","controllerKind":"Cluster","Cluster":{"name":"one-platform-pg-cluster","namespace":"apps-one-platform"},"namespace":"apps-one-platform","name":"one-platform-pg-cluster","reconcileID":"d788518b-880a-41e4-ab4e-4ac4c04c1574","caller":"internal/controller/cluster_controller.go:155"}
1772635124005	2026-03-04T14:38:44.005Z	{"level":"trace","ts":"2026-03-04T14:38:44.005226364Z","msg":"try getting connection","controller":"cluster","controllerGroup":"postgresql.cnpg.io","controllerKind":"Cluster","Cluster":{"name":"one-platform-pg-cluster","namespace":"apps-one-platform"},"namespace":"apps-one-platform","name":"one-platform-pg-cluster","reconcileID":"d788518b-880a-41e4-ab4e-4ac4c04c1574","pluginName":"barman-cloud.cloudnative-pg.io","caller":"internal/cnpi/plugin/repository/connection.go:71"}
1772635124007	2026-03-04T14:38:44.007Z	{"level":"trace","ts":"2026-03-04T14:38:44.007000204Z","msg":"Acquired logical plugin connection","controller":"cluster","controllerGroup":"postgresql.cnpg.io","controllerKind":"Cluster","Cluster":{"name":"one-platform-pg-cluster","namespace":"apps-one-platform"},"namespace":"apps-one-platform","name":"one-platform-pg-cluster","reconcileID":"d788518b-880a-41e4-ab4e-4ac4c04c1574","pluginName":"barman-cloud.cloudnative-pg.io","caller":"internal/cnpi/plugin/repository/connection.go:92","name":"barman-cloud.cloudnative-pg.io"}
1772635124039	2026-03-04T14:38:44.039Z	{"level":"info","ts":"2026-03-04T14:38:44.038914865Z","msg":"waiting for service to be deleted","controller":"cluster","controllerGroup":"postgresql.cnpg.io","controllerKind":"Cluster","Cluster":{"name":"one-platform-pg-cluster","namespace":"apps-one-platform"},"namespace":"apps-one-platform","name":"one-platform-pg-cluster","reconcileID":"d788518b-880a-41e4-ab4e-4ac4c04c1574","serviceName":"one-platform-pg-cluster-ro-external","updateStrategy":"patch"}
1772635124039	2026-03-04T14:38:44.039Z	{"level":"trace","ts":"2026-03-04T14:38:44.038963066Z","msg":"Released logical plugin connection","controller":"cluster","controllerGroup":"postgresql.cnpg.io","controllerKind":"Cluster","Cluster":{"name":"one-platform-pg-cluster","namespace":"apps-one-platform"},"namespace":"apps-one-platform","name":"one-platform-pg-cluster","reconcileID":"d788518b-880a-41e4-ab4e-4ac4c04c1574","pluginName":"barman-cloud.cloudnative-pg.io","caller":"internal/cnpi/plugin/repository/connection.go:99","name":"barman-cloud.cloudnative-pg.io"}
1772635124039	2026-03-04T14:38:44.039Z	{"level":"debug","ts":"2026-03-04T14:38:44.03899222Z","msg":"Reconciliation loop end","controller":"cluster","controllerGroup":"postgresql.cnpg.io","controllerKind":"Cluster","Cluster":{"name":"one-platform-pg-cluster","namespace":"apps-one-platform"},"namespace":"apps-one-platform","name":"one-platform-pg-cluster","reconcileID":"d788518b-880a-41e4-ab4e-4ac4c04c1574","caller":"internal/controller/cluster_controller.go:157"}

Code of Conduct

  • I agree to follow this project's Code of Conduct

Activity

  1. mikarapace
    assigned
    gbartolini
    on Mar 4, 2026
  2. mikarapace
    added
    triagePending triage
    bug
    on Mar 4, 2026

  3. dosubot commented on Mar 4, 2026

    @dosubot
    dosubotBot
    on Mar 4, 2026 – with DosuBot

    Hi @mikarapace! I'm Dosu and I’m helping the cloudnative-pg team.

    This looks like a confirmed bug/limitation in the managed services reconciliation logic. Looking at the service reconciliation code, the patch strategy only reconciles three fields:

    1. Spec.Selector
    2. Labels
    3. Annotations

    loadBalancerSourceRanges and other ServiceSpec fields are never checked, so changes to them don't trigger an update. The relevant code shows:

    // Only these three fields are compared
if !reflect.DeepEqual(proposed.Spec.Selector, livingService.Spec.Selector) { ... }
if !utils.IsMapSubset(livingService.Labels, proposed.Labels) { ... }
if !utils.IsMapSubset(livingService.Annotations, proposed.Annotations) { ... }

    The "waiting for service to be deleted" log message with updateStrategy: patch is suspicious - this log entry should only appear when a service has a non-zero DeletionTimestamp (i.e., during replace strategy or external deletion).

    Workaround: Unfortunately, replace strategy is currently the only way to apply changes to fields like loadBalancerSourceRanges. This is a genuine gap in the patch strategy implementation - it should be extended to compare additional ServiceSpec fields.

    To reply, just mention @dosu.

    Share context across your team and agents. Try Dosu.

    Leave Feedback Learn about cloudnative-pg with Dosu Add Dosu to your team

  4. armru
    self-assigned this
    on Mar 6, 2026
  5. mnencia
    removed
    triagePending triage
    on Mar 6, 2026

  6. 6 remaining items

  7. cnpg-bot
    added 2 commits that reference this issue on Mar 12, 2026

    fix(services): reconcile managed service spec changes with patch stra…

    66dff15

    fix(services): reconcile managed service spec changes with patch stra…

    ce02d98
  8. leonardoce
    added 2 commits that reference this issue on Mar 20, 2026

    fix(services): use three-way merge for managed service spec reconcili…

    3560501

    fix(services): use JSON merge patch for managed service spec reconcil…

    e20d4d5
  9. cnpg-bot
    added 3 commits that reference this issue on Mar 20, 2026

    fix(services): use JSON merge patch for managed service spec reconcil…

    21531fc

    fix(services): use JSON merge patch for managed service spec reconcil…

    dd6d746

    fix(services): use JSON merge patch for managed service spec reconcil…

    037f556
  10. mnencia
    added
    bug 🐛Something isn't working
    and removed
    bug
    on Jun 21, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

bug 🐛Something isn't working

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions