Bug 1747608 - Worker nodes unable to communicate with cluster after applying updated api certs
Summary: Worker nodes unable to communicate with cluster after applying updated api certs
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Machine Config Operator
Version: 4.2.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: 4.2.0
Assignee: Ryan Phillips
QA Contact: Micah Abbott
Depends On:
TreeView+ depends on / blocked
Reported: 2019-08-31 04:37 UTC by brad.williams
Modified: 2019-10-16 06:39 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2019-10-16 06:39:32 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Github openshift machine-config-operator pull 1095 None closed Bug 1747608: APIServerInternalURL fix for kubelet 2020-06-23 19:56:59 UTC
Red Hat Product Errata RHBA-2019:2922 None None None 2019-10-16 06:39:41 UTC

Description brad.williams 2019-08-31 04:37:33 UTC
Description of problem:
After standing up a new 4.2 integration cluster, for our starter environments, we attempted to apply our new certificates and this led to the cluster falling into a degraded state.  The symptoms we observed were: 
- all the worker nodes were marked as NotReady 
- the kubelet logs showed lots of "unauthorizied" and "invalid certificate" errors
- Multiple cluster operators were flagged as degraded 

Version-Release number of selected component (if applicable):
$ oc get clusterversion
NAME      VERSION                             AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.2.0-0.nightly-2019-08-29-062233   True        False         13h     Cluster version is 4.2.0-0.nightly-2019-08-29-062233

How reproducible:
Unknown.  This happened on the very first 4.2 cluster we stood up.

Steps to Reproduce:
1. Install the latest 4.2 nightly build
2. Apply new certificates to the cluster

Actual results:
The cluster became degraded and unable to proceed with applying the custom certificates and ultimately became unusable.

Expected results:
The cluster operators should be able to apply custom certificates without degrading the system to an unusable state

Additional info:

Comment 4 errata-xmlrpc 2019-10-16 06:39:32 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.