Bug 1783352

Summary: kcm doesn't work on IPv6
Product: OpenShift Container Platform Reporter: Maciej Szulik <maszulik>
Component: kube-controller-managerAssignee: Maciej Szulik <maszulik>
Status: CLOSED ERRATA QA Contact: zhou ying <yinzhou>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 4.3.0CC: aos-bugs, mfojtik
Target Milestone: ---   
Target Release: 4.4.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: No Doc Update
Doc Text:
Story Points: ---
Clone Of:
: 1783353 (view as bug list) Environment:
Last Closed: 2020-05-13 21:55:16 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 1783353    

Description Maciej Szulik 2019-12-13 15:46:20 UTC
Description of problem:
If you say net.Listen("tcp", "0.0.0.0:10357"), golang will actually create a dual-stack IPv4/IPv6 listening socket. But for historical reasons (having to do with bad IPv6 compat in older kube I think), we default to passing "tcp4" (the default value of configv1.ServingInfo.BindNetwork) instead of "tcp", forcing IPv4-only.

There is no reason these days for servers on the pod network to enforce IPv4-only, so this overrides the default for kube-controller-manager.

Comment 1 Maciej Szulik 2019-12-13 15:47:59 UTC
This was fixed in https://github.com/openshift/cluster-kube-controller-manager-operator/pull/320

Comment 3 zhou ying 2019-12-16 07:28:56 UTC
Confirmed with latest payload: 4.4.0-0.nightly-2019-12-15-184910, the issue has fixed:

Login the master node, check the Listen port:

[root@dhcp-140-138 ~]# oc debug node/ip-xxxxx
Starting pod/ip-10-0-130-121us-east-2computeinternal-debug ...
To use host binaries, run `chroot /host`
Pod IP: 10.0.130.121
If you don't see a command prompt, try pressing enter.
sh-4.2# chroot /host
sh-4.4# netstat -pan |grep 10357
tcp6       0      0 :::10357                :::*                    LISTEN      51788/cluster-polic

Comment 5 errata-xmlrpc 2020-05-13 21:55:16 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.

https://access.redhat.com/errata/RHBA-2020:0581