Postgres pod starts as secondary node instead of primary after Kubernetes cluster upgrade

• Which version of the Postgres Operator are you using?
  registry.opensource.zalan.do/acid/postgres-operator:v1.9.0.

• Where is the Postgres Operator running? Is it on cloud or bare metal? Are you using Kubernetes or OpenShift?
  The Postgres Operator is running on bare metal.

• Are you currently using the Postgres Operator in production?
  Yes, the Postgres Operator is currently being used in production.

• What type of issue are you facing?
  This is a bug report.

Description:
We upgraded our Kubernetes cluster from version 1.24.8 to 1.26.3 by following the official docs. When we drained the node running the Postgres pod, it would respawn on another node without any issues. However, the Postgres pod started as a secondary node instead of the primary node, even though we had configured it to run in 1-master mode. As a result, the database rejected all connections from the application. Please see the error log below for more information:

2023-04-14 10:26:25,574 INFO: Lock owner: None; I am mattermost-pgsql-0                                                                                                                    │
│ 2023-04-14 10:26:25,574 INFO: starting as a secondary                                                                                                                                      │
│ 2023-04-14 10:26:25,664 INFO: postmaster pid=85678 
│ 2023-04-12 10:26:25 UTC [15597]: [8-1] 6436b473.3ced 0     HINT:  Future log output will appear in directory "../pg_log".                                                                  │
│ /var/run/postgresql:5432 - rejecting connections                                                                                                                                           │
│ /var/run/postgresql:5432 - rejecting connections                                                                                                                                           │
│ /var/run/postgresql:5432 - rejecting connections                                                                                                                                           │
│ /var/run/postgresql:5432 - rejecting connections                                                                                                                                           │
│ /var/run/postgresql:5432 - no response 

No files, tests, or entry points are named. Start by reproducing the node-drain and pod rescheduling after the Kubernetes 1.24.8 to 1.26.3 upgrade, then inspect the operator's primary-election behavior using the reported log; done means the pod starts as primary in 1-master mode and accepts application connections.