Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
First Last Prev Next    This bug is not in your last search results.
Bug 1464653 - Nodes becomes NotReady, when status update connection is dropped/severed to master, causing node to wait on 15min default net/http timeout before trying again.
Nodes becomes NotReady, when status update connection is dropped/severed to m...
Status: CLOSED ERRATA
Product: OpenShift Container Platform
Classification: Red Hat
Component: Master (Show other bugs)
3.3.1
Unspecified Unspecified
unspecified Severity urgent
: ---
: 3.7.0
Assigned To: Maciej Szulik
Mike Fiedler
: Reopened
Depends On:
Blocks: 1527389
  Show dependency tree / graph
 
Reported: 2017-06-24 05:24 EDT by Nicolas Nosenzo
Modified: 2018-06-19 02:42 EDT (History)
18 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: Node status information was getting rate limited during heavy traffic. Consequence: It happens that some nodes might be considered not ready. Fix: Use a separate connection for node healthiness. Result: Node status should be reported without any problems.
Story Points: ---
Clone Of:
: 1527389 (view as bug list)
Environment:
Last Closed: 2017-12-19 05:39:51 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Add an attachment (proposed patch, testcase, etc.)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 3363331 None None None 2018-04-27 12:49 EDT
Red Hat Product Errata RHSA-2017:3188 normal SHIPPED_LIVE Moderate: Red Hat OpenShift Container Platform 3.7 security, bug, and enhancement update 2017-11-28 21:34:54 EST

  None (edit)
Description Nicolas Nosenzo 2017-06-24 05:24:54 EDT 
Description of problem:

Nodes unexpectedly entered into a NodeNotReady state, with no information explaining why besides Kubelet stopped posting node status. Customer has confirmed there is a monitoring between hosts and masters via LB. No timeouts or problems were recorded in the last roundabout 16 hours.


Version-Release number of selected component (if applicable):
OCP 3.3.1.20-1

How reproducible:
Partially on Customer environment

Steps to Reproduce:
1.
2.
3.

Actual results:
Nodes suddenly going into a NodeNotReady status

Expected results:
Cluster working propperly

Additional info:

Added within the comments.
Comment 14 Nicolas Nosenzo 2017-06-27 04:44:37 EDT 
@Seth, 

At the same time, in case we still thinking the problem should be on the LB, I'm wondering if we can just skip the LB, by replacing it for a HAproxy native solution, changing the DNS entries to make them point to the new LB, and just replacing the haproxy.cfg in the new LB to point the backend servers to the cluster masters.

Is the above something that might help us on isolating the source of this issue?
Comment 17 Ryan Howe 2017-06-27 13:10:31 EDT 
Description of problem (refocus):

 A node stops posting status updates to the master due to the connection being severed. If the node does not receive a TCP FIN on the request, the node will wait on the 15min timeout default timeout set in net/http. After this time out the node will try to update its status again. 

Version-Release number of selected component (if applicable):
OCP 3.3.1.20-1

Actual results:

 Thu, 22 Jun 2017 15:46:03 +0200         NodeStatusUnknown               Kubelet stopped posting node status.

 Thu, 22 Jun 2017 16:01:05 +0200         KubeletReady                    kubelet is posting ready status

Expected results:

 A timeout to happen on the node that generates an error and retries sending the master an update status. This time out should fall some where between the nodes node-status-update-frequency (default 10s) and master-controllers node-monitor-grace-period duration (default 40s).
Comment 18 Nicolas Nosenzo 2017-06-28 09:35:55 EDT 
Hi Seth, 
Do you think that replacing the current LB for a native haproxy and set  the connection timeouts for server/client to a lower value (default 5m) would cause any side effect on the cluster behaviour?
 
i.e.:
  
    timeout http-request    10s
    timeout queue           1m
    timeout connect         10s
    timeout client          300s #5min  --> set it to 60s
    timeout server          300s #5min   --> set it to 60s
    timeout http-keep-alive 10s
Comment 32 Jordan Liggitt 2017-10-06 10:19:25 EDT 
Not fixed in rebase, fixed in 1.7.8 upstream, still pending cherry pick
Comment 35 zhou ying 2017-10-13 06:12:23 EDT 
Nicolas Nosenzo:
 
  Could you please provider more details about the LB? thanks
Comment 36 zhou ying 2017-10-16 05:36:46 EDT 
Nicolas Nosenzo, Maciej Szulik:

    With the old version:3.7.0-0.127.0, and haproxy HA, when I stop the master's api service, I couldn't reproduce the issue. Could you please help support more details, thanks.
Comment 37 Maciej Szulik 2017-10-17 03:50:13 EDT 
It might be hard to reproduce, you'll need to generate load big enough to hit those limits. I'll defer to Nicolas for the reproducer.
Comment 38 zhou ying 2017-11-03 04:53:56 EDT 
Need to test when 3.8 scalability lab is available.
Comment 40 Mike Fiedler 2017-11-09 07:17:45 EST 
This area was regression tested in a 300 node AWS cluster on 3.7.0-0.190.0.   The originally reported problem was not reproduced.

During the test, a cluster horizontal stress test was run and high stress logging testing was performed at rates over 75 million messages/hour.   During this testing no NotReady nodes were seen.

Additionally SVT has run its suite of network performance tests for 3.7 and no issues were seen.

Marking this bug VERFIED for 3.7 and creating a card (internal board) for SVT to create a test case to explicitly test this area again in 3.8.
Comment 43 errata-xmlrpc 2017-11-28 16:58:46 EST 
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.

https://access.redhat.com/errata/RHSA-2017:3188
Comment 44 Nicolas Nosenzo 2017-12-15 07:41:24 EST 
Hi, re-opening this BZ, affected customer are concerned about whether this will be backported to 3.4-3.6. Is there any plans for doing so ?

Thanks.
Comment 45 Michal Fojtik 2017-12-18 09:53:13 EST 
(In reply to Nicolas Nosenzo from comment #44)
> Hi, re-opening this BZ, affected customer are concerned about whether this
> will be backported to 3.4-3.6. Is there any plans for doing so ?
> 
> Thanks.

Can you please open a separate bug or clone this bug for 3.6?
Comment 46 Nicolas Nosenzo 2017-12-19 05:39:51 EST 
(In reply to Michal Fojtik from comment #45)
> (In reply to Nicolas Nosenzo from comment #44)
> > Hi, re-opening this BZ, affected customer are concerned about whether this
> > will be backported to 3.4-3.6. Is there any plans for doing so ?
> > 
> > Thanks.
> 
> Can you please open a separate bug or clone this bug for 3.6?

Done, https://bugzilla.redhat.com/show_bug.cgi?id=1527389

closing this one.
Note You need to log in before you can comment on or make changes to this bug.
First Last Prev Next    This bug is not in your last search results.