私は同じ問題を抱えています。 また、別の問題で提案されているように、ネットワークARGSを削除してみました。 それでもwaiting for control plane to be readyでハングします。

変更を加えた後、デーモンをリロードし、kubeletサービスを再起動しましたか。 ドライバーとコメントネットワークを変更した後、動作しました。 コントロールプレーンが初めて準備されるまでに10〜11分かかります。初めて、15分間そのままにしておくことをお勧めします。

デーモンをリロードし、毎回kubeletサービスを再起動しました。 セットアップを一晩中邪魔されずに残しましたが、それでもコントロールプレーンを待っていました。

デーモン（ systemctl daemon-reload ）をリロードし、kubeletも再起動しました。 kubeadm resetを実行し、サービス構成を編集し、デーモンをリロードしてから、 kubeadm initを実行します。

ネットワークオプションをコメントアウトした後、Apiserverおよびetcddockerコンテナが実行に失敗します。 また、weave-netを手動でインストールして、cni configディレクトリにデータが入力されるようにしましたが、どちらも機能しませんでした。 これを行うために、weaveをインストールし、 weave setupとweave launch実行しました。 KubeadmがCNI設定を使用するようにDockerを構成する方法はよくわかりませんが、ここで欠落しているステップがある可能性があります。

kubeletがkubeapiサーバーに到達できないようです。

etcdがポート2380でリッスンできないことに気づきました。これらの手順を再度実行すると、クラスターが起動しました。

• kubeadm resetを実行して、サーバーに加えられた変更をすべて削除します。
• マシンを初期状態に戻します。 kubeadmを再インストールする（元の構成ファイルを取得するため）。
• kubernetesに関連するDockerコンテナがある場合は、それを削除します。
• weaveを入手してインストールします。 実行しないでください。
• サーバーを再起動します。
• kubeletが実行されないことを確認してください。
• weave setupとweave launchを実行します。
• kubeadm init実行します。

手織りの管理をやめたいなら...

• weave reset実行します
• kubernetes1.6にweaveアドオンを適用します。
• サーバーを再起動します。

Kubeadmjoinは他のサーバーで機能するはずです。

@Yengas織り方の詳細を教えてください。 それらをすべてのノードで実行しましたか、それともマスターだけで実行しましたか？

@jruelsはマスターノードだけです。 織りはただのバイナリです。 引数なしのsetupコマンドは、weave dockerイメージをダウンロードし、CNI構成を作成します。 引数を指定しないlaunchコマンドは、ホスト上でのみウィーブコンテナを開始します。

@Yengasまだわかりませんが、「weaveを取得してインストールします。実行しないでください」とはどういう意味ですか？kubectl apply -f https://git.io/weave-kube-1.6を実行できないので、weaveをインストールするにはどうすればよいですか？ ？

apiserverログは何と言っていますか？

@ rushabh268
weaveをインストールするには、マスターで次のコマンドを実行します
sudo curl -L git.io/weave -o /usr/local/bin/weave && chmod a+x /usr/local/bin/weave
次に実行します
weave setup
それが完了したら実行
weave launch

あなたはそれをする必要はありません。 kubectl apply- fhttps: //git.io/weave-kube-1.6で十分です。

APIサーバーのログには、バグで述べたのとまったく同じことが記載されています。 また、Kubernetesがインストールされていないため、kubectlを実行できません

@jruels試してみて、このスレッドを更新します！

バグの説明には、kubeadmログとkubeletログがあります。 apiserverログはありません。

@mikedanese apiserverログを取得するにはどうすればよいですか？
@jruels織りを育てることができます
@Yengas手順を実行した後でも、kubeletログに次のエラーが表示されます。
Apr 06 12:55:56 hostname kubelet[5174]: E0406 12:55:56.858931 5174 kubelet.go:2067] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized Apr 06 12:55:57 hostname kubelet[5174]: E0406 12:55:57.556067 5174 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:382: Failed to list *v1.Service: Get https://10.X.X.X:6443/api/v1/services?resourceVersion=0: dial tcp 10.X.X.X:6443: getsockopt: connection refused Apr 06 12:55:57 hostname kubelet[5174]: E0406 12:55:57.557441 5174 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:390: Failed to list *v1.Node: Get https://10.X.X.X:6443/api/v1/nodes?fieldSelector=metadata.name%3Dhostname&resourceVersion=0: dial tcp 10.X.X.X:6443: getsockopt: connection refused Apr 06 12:55:57 hostname kubelet[5174]: E0406 12:55:57.558822 5174 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:46: Failed to list *v1.Pod: Get https://10.X.X.X:6443/api/v1/pods?fieldSelector=spec.nodeName%3Dhostname&resourceVersion=0: dial tcp 10.X.X.X:6443: getsockopt: connection refused Apr 06 12:55:58 hostname kubelet[5174]: I0406 12:55:58.347460 5174 kubelet_node_status.go:230] Setting node annotation to enable volume controller attach/detach Apr 06 12:55:58 hostname kubelet[5174]: I0406 12:55:58.405762 5174 kubelet_node_status.go:77] Attempting to register node hostname1

また、ファイアウォールを停止したので、接続が拒否される理由がわかりません。

ここで同じ問題が報告されています。

念のため、システムメッセージ（マスターノード）がスタックしているときに切り取ってください。 ところで、私はLinodeでこれを実行しています。

4月12日02:10:00localhost監査：SERVICE_START pid = 1 uid = 0 auid = 4294967295 ses = 4294967295 msg ='unit = kubelet comm = "systemd" exe = "/ usr / lib / systemd / systemd" hostname =？ addr =？ ターミナル=？ res = success '
4月12日02:10:00ローカルホスト監査：SERVICE_STOP pid = 1 uid = 0 auid = 4294967295 ses = 4294967295 msg ='unit = kubelet comm = "systemd" exe = "/ usr / lib / systemd / systemd" hostname =？ addr =？ ターミナル=？ res = success '
4月12日02:10:00localhost監査：SERVICE_START pid = 1 uid = 0 auid = 4294967295 ses = 4294967295 msg ='unit = kubelet comm = "systemd" exe = "/ usr / lib / systemd / systemd" hostname =？ addr =？ ターミナル=？ res = success '
4月12日02:10:00localhostsystemd：kubelet.service：サービスの保留時間が終了し、再起動をスケジュールします。
4月12日02:10:00localhostsystemd：停止したkubelet：Kubernetesノードエージェント。
4月12日02:10:00localhostsystemd：kubeletを開始しました：Kubernetesノードエージェント。
4月12日02:10:00localhostsystemd：システムアクティビティアカウンティングツールを開始しています...
4月12日02:10:00ローカルホスト監査：SERVICE_START pid = 1 uid = 0 auid = 4294967295 ses = 4294967295 msg ='unit = sysstat-collect comm = "systemd" exe = "/ usr / lib / systemd / systemd" hostname = ？ addr =？ ターミナル=？ res = success '
4月12日02:10:00ローカルホスト監査：SERVICE_STOP pid = 1 uid = 0 auid = 4294967295 ses = 4294967295 msg ='unit = sysstat-collect comm = "systemd" exe = "/ usr / lib / systemd / systemd" hostname = ？ addr =？ ターミナル=？ res = success '
4月12日02:10:00localhostsystemd：システムアクティビティアカウンティングツールを開始しました。
4月12日02:10:00localhostkubelet：I0412 02：10：00.924529 3445 feature_gate.go：144]機能ゲート：map []
4月12日02:10:00localhostkubelet：I0412 02：10：00.928973 3445 docker.go：364] unix：///var/run/docker.sockのdockerに接続しています
4月12日02:10:00localhostkubelet：I0412 02：10：00.929201 3445 docker.go：384]リクエストtimeout=2m0sでdockerクライアントを起動します
4月12日02:10:00localhostkubelet：W0412 02：10：00.941088 3445 cni.go：157] cni構成を更新できません：/etc/cni/net.dにネットワークが見つかりません
4月12日02:10:00localhostkubelet：I0412 02：10：00.948892 3445 manager.go：143]コンテナで実行されているcAdvisor： "/system.slice"
4月12日02:10:00localhostkubelet：W0412 02：10：00.974540 3445 manager.go：151] Rkt apiサービスに接続できません：rkt：tcpできませんrkt apiサービス：ダイヤルtcp [:: 1]：15441： Getsockopt：接続が拒否されました
4月12日02:10:00localhostkubelet：I0412 02：10：00.997599 3445 fs.go：117]ファイルシステムパーティション：map [/ dev / root：{mountpoint：/ var / lib / docker / devicemapper major：8 minor：0 fsType：ext4 blockSize：0 }]
4月12日02:10:01localhostkubelet：I0412 02：10：01.001662 3445 manager.go：198]マシン：{ NumCores：1 Cpu Frequency：2799998 Memor yCapacity：1037021184 MachineID：5e9a9a0b58984bfb8766dba9afa8a191 S ystemUUID： 5e9a9a0b 437b-9460-981eeefdfe5aファイルシステム：[{Device：/ dev / rootCapacity：15447539712 Type：vfs Inodes ：962880 HasInodes：true }] DiskMap：map [43：0：{ Name：nbd0 Major：43 Minor：0 Size：0スケジューラ：なし} 43:11：{名前：nbd11メジャー：43マイナー：11サイズ：0スケジューラ：なし} 43:12：{名前：nbd12メジャー：43マイナー：12サイズ：0スケジューラ：なし} 43:15： {名前：nbd15メジャー：43マイナー：15サイズ：0スケジューラー：なし} 43：7：{名前：nbd7メジャー：43マイナー：7サイズ：0スケジューラー：なし} 8：0：{名前：sdaメジャー：8マイナー：0サイズ：15728640000スケジューラー：cfq } 252：0：{名前：dm-0メジャー：252マイナー：0サイズ：107374182400スケジューラー：なし} 43：1：{名前：nbd1メジャー：43マイナー：1サイズ：0スケジューラー：none } 43:13：{名前：nbd13メジャー：43マイナー：13サイズ：0スケジューラー：なし} 43：8：{名前：nbd8メジャー：43マイナー：8サイズ：0スケジューラー：なし} 8： 16：{名前：sdbメジャー：8マイナー：16サイズ：536870912スケジューラー：cfq } 9：0：{名前：md0メジャー：9マイナー：0サイズ：0スケジューラー：なし} 43：3：{名前：nbd3メジャー： 43マイナー：3サイズ：0スケジューラー：なし} 43：9：{名前：nbd9メジャー：43マイナー：9サイズ：0スケジューラー：なし} 43:10：{名前：nbd10メジャー：43マイナー：10サイズ：0スケジューラー：none } 43:14：{名前：nbd14メジャー：43マイナー：14サイズ：0スケジューラー：なし} 43：2：{名前：nbd2メジャー：43マイナー：2サイズ：0スケジューラー：なし} 43：4：{名前：nbd4メジャー：43マイナー：4サイズ：0スケジューラー：なし} 43：5：{名前：nbd5メジャー：43マイナー：5サイズ：0スケジューラー：なし} 43：6：{名前：nbd6メジャー：43マイナー： 6サイズ：0スケジューラ：なし}] NetworkDevices：[{ Name：dummy0 M acAddress：5a ：34：bf：e4：23：cc Speed：0 Mtu：1500 } { Name：eth0 M acAddress：f2 ：3c：91： 1f：cd：c3速度：-1 Mtu：1500 } {名前：gre0M acAddress：00 ：00：00：00速度：0 Mtu：1476 } {名前：gretap0M acAddress：00 ：00：00：00：00 ：00 Speed：0 Mtu：1462 } { Name：ip6_vti0 M acAddress：00 ：00：00：00：00：00：00：00：00：00：00：00：00：00：00：00 Speed：0 Mtu：1500 } {名前：ip6gre0M acAddress：00 ：00：00：00：00：00：00：00： 00：00：00：00：00：00：00：00速度：0 Mtu：1448 } {名前：ip6tnl0M acAddress：00 ：00：00：00：00：00：00：00：00：00：00 ：00：00：00：00：00速度：0 Mtu：1452 } {名前：ip_vti0Ma
4月12日02:10:01localhostkubelet： cAddress：00 ：00：00：00 Speed：0 Mtu：1428 } { Name：sit0 M acAddress：00 ：00：00：00 Speed：0 Mtu：1480 } { Name： teql0 MacAddress： Speed：0 Mtu：1500 } { Name：tunl0 M acAddress：00 ：00：00：00 Speed：0 Mtu：1480 }]トポロジ：[{Id ：0Memory：1037021184 Cores：[{Id：0 Threads ：[0]キャッシュ：[{サイズ：32768タイプ：データレベル：1 } {サイズ：32768タイプ：命令レベル：1 } {サイズ：4194304タイプ：統合レベル：2 }]}]キャッシュ：[]}] Clou dProvider：Unknown Ins tanceType：Unknown I nstanceID：None }
4月12日02:10:01localhostkubelet：I0412 02：10：01.013353 3445 manager.go：204]バージョン：{Kern elVersion：4.9.15-x86_64-linode81 Container OsVersion：Fedora 25（Server Edition）Dock erVersion：1.12。 6 CadvisorVersion：CadvisorRevision：}
4月12日02:10:01localhostkubelet：I0412 02：10：01.014086 3445 server.go：509] --cgroups-per-qosが有効になっていますが、-cgroup-rootが指定されていません。 デフォルトは/
4月12日02:10:01localhostkubelet：W0412 02：10：01.016562 3445 container_manager_linux.go：218]スワップをオンにして実行することはサポートされていません。スワップを無効にしてください！ これは、K8s v1.6以降、デフォルトで致命的なエラーになります。 それまでの間、-experimental-fail-swap-onを有効にすることで、これを致命的なエラーにすることを選択できます。
4月12日02:10:01localhostkubelet：I0412 02：10：01.016688 3445 container_manager_linux.go：245]コンテナーマネージャーがユーザー指定のcgroup-rootが存在することを確認しました：/
4月12日02:10:01localhostkubelet：I0412 02：10：01.016717 3445 container_manager_linux.go：250]ノード構成に基づくContainer Managerオブジェクトの作成：{RuntimeCgroupsName：SystemCgroupsName：KubeletCgroupsName：Contain erRuntime ： docker Cgro upsPerQOS：true CgroupRoot：/ Cgr oupDriver：cgroupfs ProtectKerne lDefaults：false EnableCRI：true NodeAllocatableConfig：{KubeReservedCgroupName：SystemReservedCgroupName：EnforceNodeAl locatable ：map [pods：{}] Kub eReserved：map [] Syste mReserved ：map [] HardEvictionThresholds ：[{ ：LessThan Value：{ Quantity：100Mi P ercentage：0 } Gr acePeriod：0s MinReclaim：}]} ExperimentalQO SReserved：map []}
4月12日02:10:01localhostkubelet：I0412 02：10：01.016943 3445 kubelet.go：255]マニフェストファイルの追加：/ etc / kubernetes / manifests
4月12日02:10:01localhostkubelet：I0412 02：10：01.016966 3445 kubelet.go：265]apiserverを監視しています
4月12日02:10:01localhostkubelet：E0412 02：10：01.0250583445reflector.go:190]k8s.io/kubernetes/pkg/kubelet/kubelet.go:390：リストに失敗しました* v1.Node：Get https： //50.116.13.214：6443 / api / v1 / nodes？fieldSelector = metadata.name％3Dli471-214.members.linode.com＆resourceVersion = 0：ダイヤルtcp 50.116.13.214：6443：getsockopt：接続が拒否されました
4月12日02:10:01localhostkubelet：E0412 02：10：01.0253423445reflector.go:190]k8s.io/kubernetes/pkg/kubelet/kubelet.go:382：リストに失敗しました* v1.Service：Get https： //50.116.13.214：6443 / api / v1 / services？resourceVersion = 0：ダイヤルtcp 50.116.13.214：6443：getsockopt：接続が拒否されました
4月12日02:10:01localhostkubelet：E0412 02：10：01.025397 3445reflection.go：190] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:46：リストに失敗しました* v1.Pod：取得https://50.116.13.214：6443 / api / v1 / pods？fieldSelector = spec.nodeName％3Dli471-214.members.linode.com＆resourceVersion = 0：ダイヤルtcp 50.116.13.214：6443：getsockopt：接続が拒否されました
4月12日02:10:01localhostkubelet：W0412 02：10：01.026574 3445 kubelet_network.go：70]ヘアピンモードが「promiscuous-bridge」に設定されていますが、kubenetが有効になっておらず、「h​​airpin-veth」にフォールバックしています
4月12日02:10:01localhostkubelet：I0412 02：10：01.026599 3445kubelet.go：494]ヘアピンモードが「hairpin-veth」に設定されました
4月12日02:10:01localhostkubelet：W0412 02：10：01.026661 3445 cni.go：157] cni構成を更新できません：/etc/cni/net.dにネットワークが見つかりません
4月12日02:10:01localhostkubelet：W0412 02：10：01.034194 3445 cni.go：157] cni構成を更新できません：/etc/cni/net.dにネットワークが見つかりません
4月12日02:10:01localhostkubelet：W0412 02：10：01.043157 3445 cni.go：157] cni構成を更新できません：/etc/cni/net.dにネットワークが見つかりません
4月12日02:10:01localhostkubelet：I0412 02：10：01.043183 3445 docker_service.go：187]cniによって管理されるDockercriネットワーキング
4月12日02:10:01localhostkubelet：エラー：実行に失敗しましたKubelet：kubeletの作成に失敗しました：構成の誤り：kubelet cgroupドライバー："cgroupfs"はdockercgroupドライバーとは異なります： "systemd"
4月12日02:10:01ローカルホスト監査：SERVICE_STOP pid = 1 uid = 0 auid = 4294967295 ses = 4294967295 msg ='unit = kubelet comm = "systemd" exe = "/ usr / lib / systemd / systemd" hostname =？ addr =？ ターミナル=？ res = failed '
4月12日02:10:01localhostsystemd：kubelet.service：メインプロセスが終了しました、code = exited、status = 1 / FAILURE
4月12日02:10:01localhostsystemd：kubelet.service：ユニットが失敗状態になりました。
4月12日02:10:01localhostsystemd：kubelet.service：結果'exit-code'で失敗しました。

@acloudiatorkubeadmconfigでcgroup-driverを設定する必要があると思います。

vi /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
Environment="KUBELET_EXTRA_ARGS=--cgroup-driver=systemd"

そして、kubeletサービスを再起動します

kubeadmが何らかの方法でcgroup構成の問題に対処できれば素晴らしいと思います。
アイデア：

• 設定ミスの場合の初期化の中止
• 事前にDockerの設定を確認し、Dockerが使用しているものを使用してください（ここでの影響についてはわかりません）

ただの更新ですが、私が試した回避策は何でも機能しませんでした。 そこで、マスター用にCentOS 7.3に移行しました。これは、魅力のように機能します。 ただし、CentOS7.2でミニオンを維持しました。

@ rushabh268こんにちは、RedhatLinux7.2でも同じ問題が発生します。 systemdを更新すると、この問題は解決します。 インストールする前にsystemdの更新を試みることができます。
yum update -y systemd
およびkubeletからのエラーログ：
kubelet.go:1752] skipping pod synchronization - [Failed to start ContainerManager systemd version does not support ability to start a slice as transient unit]

CentOS7.3でこの問題が発生しました。 docker-ceをアンインストールしてからdocker-ioをインストールすると、問題は解決しました。
それが根本的な原因かどうかはわかりません。 とにかく、上記の方法が機能しない場合は試してみることができます。

@ZongqiangZhangノードにdocker1.12.6をインストールしています。 @juntaoXie systemdも更新してみましたが、まだスタックしています

だから私は多くのマシンで問題なくCentos7.3w/1.6.4を実行してきました。

selinuxを無効にしたことを確認しましたか？

@timothysc CentOS7.3ではなくCentOS7.2を使用していて、selinuxが無効になっています

CentOS Linuxリリース7.3.1611（コア）を使用していますが、KubeAdm1.6.4が機能しません。

cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=http://yum.kubernetes.io/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=0
repo_gpgcheck=0
EOF

setenforce 0
# edit /etc/selinux/config and set SELINUX=disabled
yum install docker kubelet kubeadm kubectl kubernetes-cni
systemctl enable docker
systemctl start docker
systemctl enable kubelet
systemctl start kubelet
reboot
kubeadm init

出力：

kubeadm init
[kubeadm] WARNING: kubeadm is in beta, please do not use it for production clusters.
[init] Using Kubernetes version: v1.6.4
[init] Using Authorization mode: RBAC
[preflight] Running pre-flight checks
[preflight] WARNING: hostname "kubernet01.localdomain" could not be reached
[preflight] WARNING: hostname "kubernet01.localdomain" lookup kubernet01.localdomain on XXXXXXX:53: read udp XXXXXXX:56624->XXXXXXX:53: i/o timeout
[preflight] Starting the kubelet service
[certificates] Generated CA certificate and key.
[certificates] Generated API server certificate and key.
[certificates] API Server serving cert is signed for DNS names [kubernet01.localdomain kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 10.11.112.51]
[certificates] Generated API server kubelet client certificate and key.
[certificates] Generated service account token signing key and public key.
[certificates] Generated front-proxy CA certificate and key.
[certificates] Generated front-proxy client certificate and key.
[certificates] Valid certificates and keys now exist in "/etc/kubernetes/pki"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/kubelet.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/controller-manager.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/scheduler.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/admin.conf"
[apiclient] Created API client, waiting for the control plane to become ready

Jun 06 17:13:12 kubernet01.localdomain kubelet[11429]: W0606 17:13:12.881451   11429 cni.go:157] Unable to update cni config: No networks found in /etc/cni/net.d
Jun 06 17:13:12 kubernet01.localdomain kubelet[11429]: E0606 17:13:12.882145   11429 kubelet.go:2067] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized
Jun 06 17:13:13 kubernet01.localdomain kubelet[11429]: E0606 17:13:13.519992   11429 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:46: Failed to list *v1.Pod: Get https://10.11.112.51:6443/api/v1/pods?fieldSelector=spec.nodeName%3Dkubernet01.localdomain&resourceVersion=0: dial tcp 10.11.112.51:6443: getsockopt: connection refused
Jun 06 17:13:13 kubernet01.localdomain kubelet[11429]: E0606 17:13:13.520798   11429 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:382: Failed to list *v1.Service: Get https://10.11.112.51:6443/api/v1/services?resourceVersion=0: dial tcp 10.11.112.51:6443: getsockopt: connection refused
Jun 06 17:13:13 kubernet01.localdomain kubelet[11429]: E0606 17:13:13.521493   11429 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:390: Failed to list *v1.Node: Get https://10.11.112.51:6443/api/v1/nodes?fieldSelector=metadata.name%3Dkubernet01.localdomain&resourceVersion=0: dial tcp 10.11.112.51:6443: getsockopt: connection refused
Jun 06 17:13:14 kubernet01.localdomain kubelet[11429]: E0606 17:13:14.337588   11429 event.go:208] Unable to write event: 'dial tcp 10.11.112.51:6443: getsockopt: connection refused' (may retry after sleeping)

@paulobezerr kube-apiserverログをもう少し共有できますか？ （コメントの最後にあるもの）

すでに含めた行の上に同じIPアドレスが記載されていますか？ 最近、2つの新しいKVMでk8sを実行してみました。1つはUbuntu 16.04で、もう1つはCentOS7.3で実行しました。 両方ともこれを与えました：

​[restful] 2017/05/30 19:31:38 log.go:30: [restful/swagger] listing is available at https://x.x.x.x:6443/swaggerapi/
[restful] 2017/05/30 19:31:38 log.go:30: [restful/swagger] https://x.x.x.x:6443/swaggerui/ is mapped to folder /swagger-ui/
​E0530 19:31:38.313090 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: Failed to list *rbac.RoleBinding: Get https://localhost:6443/apis/rbac.authorization.k8s.io/v1beta1/rolebindings?resourceVersion=0: dial tcp y.y.y.y:6443: getsockopt: connection refused

最初に言及されたIPアドレスはx.x.x.xですが、ローカルホストはy.y.y.yに解決されることに注意してください（私の場合、同じ物理サーバー上にある別のKVMのパブリックIPでした）。 最終的にUbuntuでkubeadmを開始できましたが、 https： //github.com/kubernetes/kubeadm/issues/113#issuecomment-273115861と同様の方法でdnsmasqをインストールした後でのみです。 CentOSでの同じ回避策は役に立ちませんでした。

これはkubednsか何かのバグである可能性がありますか？ 興味深いことに、AWSVMでの同じ手順でkubeadmが起動しました。 しかし、EC2インスタンスは私の個人的なプロジェクトには高すぎます。

@paulobezerrと同じ問題があります。

##バージョン：
kubelet-1.6.4-0.x86_64
kubernetes-cni-0.5.1-0.x86_64
kubectl-1.6.4-0.x86_64
kubeadm-1.6.4-0.x86_64
docker-client-1.12.6-28.git1398f24.el7.centos.x86_64
docker-common-1.12.6-28.git1398f24.el7.centos.x86_64
docker-1.12.6-28.git1398f24.el7.centos.x86_64

それで
uname -r> 3.10.0-229.1.2.el7.x86_64
cat / etc / redhat-release> CentOS Linuxリリース7.3.1611（コア）

##次の手順：

    1. sudo yum install -y docker
2. sudo groupadd docker
3. sudo usermod -aG docker $(whoami)
4. curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl
5. chmod +x ./kubectl
6. sudo mv ./kubectl /usr/local/bin/kubectl
7. echo "source <(kubectl completion bash)" >> ~/.bashrc
8. sudo -i
9. cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF
10. setenforce 0
11. yum install -y docker kubelet kubeadm kubectl kubernetes-cni
12. systemctl enable docker && systemctl start docker
13. systemctl enable kubelet && systemctl start kubelet
    14. echo -e "net.bridge.bridge-nf-call-ip6tables = 1\nnet.bridge.bridge-nf-call-iptables = 1" >> /etc/sysctl.d/99-sysctl.conf && sudo service network restart
    15. firewall-cmd --zone=public --add-port=6443/tcp --permanent && sudo firewall-cmd --zone=public --add-port=10250/tcp --permanent  && sudo systemctl restart firewalld
    16. firewall-cmd --permanent --zone=trusted --change-interface=docker0

## api-serverログ：
->37.247.XX.XXXはパブリックIPです

[restful] 2017/06/08 10:45:19 log.go:30：[restful / swagger]リストはhttps://37.247.XX.XXX：6443 /swaggerapi/で入手できます。
[restful] 2017/06/08 10:45:19 log.go:30：[restful / swagger] https://37.247.XX.XXX：6443 /swaggerui/はフォルダー/swagger-ui/にマップされます
E0608 10：45：19.429839 1 Reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70：リストに失敗しました* api.Secret：Get https：// localhost ： 6443 / api / v1 / secrets？resourceVersion = 0：ダイヤルtcp 108.59.253.109：6443：getsockopt：接続が拒否されました
E0608 10：45：19.430419 1 Reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70：* api.ResourceQuotaの一覧表示に失敗しました： https：// localhostを取得します： 6443 / api / v1 / resourcequotas？resourceVersion = 0：ダイヤルtcp 108.59.253.109：6443：getsockopt：接続が拒否されました
E0608 10：45：19.430743 1 Reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70：リストに失敗しました* api.ServiceAccount：Get https：// localhost ： 6443 / api / v1 / serviceaccounts？resourceVersion = 0：ダイヤルtcp 108.59.253.109：6443：getsockopt：接続が拒否されました
E0608 10：45：19.431076 1 Reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70：* storage.StorageClassの一覧表示に失敗しました： https：// localhostを取得します： 6443 / apis / storage.k8s.io / v1beta1 / storageclasses？resourceVersion = 0：ダイヤルtcp 108.59.253.109：6443：getsockopt：接続が拒否されました
E0608 10：45：19.431377 1 Reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70：リストに失敗しました* api.LimitRange：Get https：// localhost ： 6443 / api / v1 / limitranges？resourceVersion = 0：ダイヤルtcp 108.59.253.109：6443：getsockopt：接続が拒否されました
E0608 10：45：19.431678 1 Reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70：リストに失敗しました* rbac.RoleBinding：Get https：// localhost ： 6443 / apis / rbac.authorization.k8s.io / v1beta1 / rolebindings？resourceVersion = 0：ダイヤルtcp 108.59.253.109：6443：getsockopt：接続が拒否されました
E0608 10：45：19.431967 1 Reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70：リストに失敗しました* rbac.ClusterRoleBinding：Get https：// localhost ： 6443 / apis / rbac.authorization.k8s.io / v1beta1 / clusterrolebindings？resourceVersion = 0：ダイヤルtcp 108.59.253.109：6443：getsockopt：接続が拒否されました
E0608 10：45：19.432165 1 Reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70：* api.Namespaceの一覧表示に失敗しました： https：// localhostを取得します： 6443 / api / v1 / namespaces？resourceVersion = 0：ダイヤルtcp 108.59.253.109：6443：getsockopt：接続が拒否されました
E0608 10：45：19.432386 1 Reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70：リストに失敗しました* rbac.ClusterRole： https：// localhostを取得： 6443 / apis / rbac.authorization.k8s.io / v1beta1 / clusterroles？resourceVersion = 0：ダイヤルtcp 108.59.253.109：6443：getsockopt：接続が拒否されました
E0608 10：45：19.432619 1 Reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70：リストに失敗しました* rbac.Role：Get https：// localhost ： 6443 / apis / rbac.authorization.k8s.io / v1beta1 / roles？resourceVersion = 0：ダイヤルtcp 108.59.253.109：6443：getsockopt：接続が拒否されました
I0608 10：45：19.4816121serve.go:79]0.0.0.0:6443で安全にサービスを提供
W0608 10：45：19.596770 1 storage_extensions.go：127]サードパーティのリソース同期に失敗しました：Get https：// localhost ：6443 / apis / extendss / v1beta1 / thirdpartyresources：dial tcp 108.59.253.109：6443：getsockopt：connection refused
E0608 10：45：19.596945 1 client_ca_hook.go：58]投稿https：// localhost ：6443 / api / v1 / namespaces：dial tcp 108.59.253.109：6443：getsockopt：connection refused
F0608 10：45：19.597174 1 controller.go：128]初期IP割り当てチェックを実行できません：サービスIPブロックを更新できません： https：// localhost ：6443 / api / v1 / servicesを取得します：tcp 108.59.253.109をダイヤルします： 6443：getsockopt：接続が拒否されました

@albpal 1週間前にまったく同じ問題が発生しました。 dial tcp X.X.X.Xに奇妙なIPアドレスが表示され、dnsmasqをインストールしてホスティングプロバイダーからDNSではなくgoogle DNSサーバーに切り替えた後でも、CentOSでこれを解決できませんでした。 好奇心のために：表示されている間違ったIPアドレスがVMと同じデータセンターにあるかどうかを確認できますか？ http://ipinfo.ioを使用して、ある程度確実に、または単にtracerouteでそれを推定できます。

私の場合、間違ったIPアドレスが同じ物理サーバー上の別のKVMを参照していました。 物理マシン上のDNSと関係がある可能性があります。これには、kubeapiまたはkubedns内での回避策が必要になる場合があります。そうしないと、クラスターの開始が多くの新規参入者にとって大きな苦痛になります。 ログのIPが間違っているdial tcpに気付く前に、数晩無駄になりました。これは、最初のk8sでの非常に悲しい経験でした。 私のホスティングプロバイダー（ firstvds.ru ）には、CentOSKVM用の優れたすぐに使えるソリューションがまだありません。

IPアドレスのこの非常に奇妙な不一致の原因は何ですか？

@albpal新しい問題を開いてください、あなたが説明したこととこの問題が何であるかは別の問題です（私はその情報に基づいていると思います）

@kachkaevあなたが提案したことを確認しました。

間違ったIPがCPANELで終了していることがわかりました：vps-1054290-4055.manage.myhosting.com。

一方、私のVPSのパブリックIPはイタリアからのものであり、この間違ったIPは米国からのものです...したがって、間違ったIPにはホスティング（CPANEL）に関連するものがあるにもかかわらず、別のKVMを参照しているようには見えません同じ物理サーバー。

k8sをインストールできましたか？

@luxas同じ動作をしますが、Dockerログをコピーしました出力も。

/ var / log/messagesとkubeadminitの出力はどちらも元の問題と同じです。

@albpalなので、VMとその2番目のマシンは両方ともCPANELにありますか？ 私の場合も同じなので、良い兆候です。 それが同じ物理マシンであったという事実は、単なる偶然かもしれません。

実験では2つのKVMを使用しました。1つはUbuntu16.04で、もう1つはCentOS7.3で使用しました。どちらも同じdial tcp IPアドレスの問題がありました。 プロバイダーのDNSサーバーを削除することで、最終的にUbuntuでkubeadmを起動することができました。 解決策はcrilozsのアドバイスに基づいていました：

​apt-get install dnsmasq

rm -rf /etc/resolv.conf
echo "nameserver 127.0.0.1" > /etc/resolv.conf
chmod 444 /etc/resolv.conf
chattr +i /etc/resolv.conf

echo "server=8.8.8.8
server=8.8.4.4" > /etc/dnsmasq.conf

service dnsmasq restart
​# reboot just in case

これにより、Ubuntuのログのdial tcpの後に正しいIPアドレスがもたらされ、数分後にkubeadmが初期化されました。 同じ方法でCentOSにdnsmasqを設定しようとしましたが、問題は解決しませんでした。 しかし、私はこのOSの初心者なので、サービスを再起動したり、キャッシュをクリーンアップしたりするのを忘れた可能性があります。 このアイデアを試してみてください！

いずれにせよ、DNSを再構成するという余分な手順を実行するのは非常に混乱するため、間違っていると感じます（私はサーバー/ DevOpsの人ではなく、調査全体で泣きそうになりました：fearful:)。 kubeadmが、プロバイダーのDNSサーバーが奇妙な方法で機能しているかどうかを検出し、クラスター内で必要なものを自動的に修正できるようになることを願っています。

k8sチームの誰かが何が起こっているのかを喜んで見てくれるなら、いくつかの新しいFirstVDSKVMでルートアクセスを共有できれば幸いです。 ツイッターで私またはDMにメールしてください！

ありがとう@kachkaev ！ 明日やってみます

cc @ kubernetes / sig-network-bugs DNS解決が上記で失敗する理由を知っていますか？

@kachkaevに感謝します。調査します。 それ自体は実際にはkubeadmのせいではないと思いますが、多くのユーザーが同じ設定ミスで立ち往生している場合は、トラブルシューティングドキュメントなどに追加する可能性があります...

私のログは@albpalログになる可能性が非常に高いです。
しかし、私はdnsmasqを試してみます。 皆さん、ありがとうございました！

@kachkaev 、動作しません。 同じ問題😢
完全なログが添付されます。

log.txt

直せました!! ヒントをありがとう@kachkaev ！

問題は次のとおりだと思います。

＃＃＃ シナリオ：
次の構成スキーマを持つVPS：

resolv.conf
[ root @ apalau〜 ]＃cat resolv.conf
ネームサーバー8.8.8.8
ネームサーバー8.8.4.4
nameserver 2001：4860：4860 :: 8888
nameserver 2001：4860：4860 :: 8844

検索ドメインはありません！

ホスト
[ root @ apalau〜 ]＃cat / etc / hosts
127.0.0.1 localhost.localdomain localhost
37.XXX.XX.XXX name.vpshosting.com

ログによると、kubernetesコンテナは以下に接続しようとします。

https：// localhost ：6443 / api / v1 / secrets？resourceVersion=0を取得します

そして私が求めるとき：
$ nslookup "localhost。$（hostname -d）"
私が取得したIPは間違ったもの、つまり108.59.253.109です。

したがって、これらのコンテナはローカルホスト（ドメインなし）を解決しようとしていて、間違ったIPを取得していると思います。 おそらく、「localhost。$（hostname -d）」がそのIPに解決されているためです。これは、ほとんどすべてのVPSサービスで発生すると思います。

## VPS CentOS 7.3で問題を修正するために私がしたこと（https://kubernetes.io/docs/setup/independent/install-kubeadm/#installing-kubelet-and-kubeadmに示されている手順の一部）：

ルートとして：

1. kubeadmリセット
2. yum install dnsmasq
3. cp /etc/resolv.conf〜/resolv.conf_bck
4. rm -rf /etc/resolv.conf
5. echo -e "nameserver 127.0.0.1 \ nnameserver $（hostname -i）" >> /etc/resolv.conf
6. chmod 444 /etc/resolv.conf
7. chattr + i /etc/resolv.conf
8. echo -e "server = 8.8.8.8 \ nserver = 8.8.4.4"> /etc/dnsmasq.conf
9. echo -e "$（hostname -i）\ tlocalhost。$（hostname -d）" >> / etc / hosts
10. サービスdnsmasq再起動
11. Firewall-cmd --zone = public --add-port = 6443 / tcp --permanent && sudo Firewall-cmd --zone = public --add-port = 10250 / tcp --permanent && sudo systemctl restart Firewalld
12. kubeadm init

手順5でホスト名-iを追加しました。追加しない場合、dockerはコンテナのresolv.confに8.8.8.8を追加します。

他の人にも役立つことを願っています。

ありがとう！！

@albpalを聞いてうれしいです！ kubeadm initの前に手順を実行し、CentOS7.3を使用したテストFirstVDSKVM内でクラスターが最終的に初期化されました。 私がしなければならなかった唯一の余分なことは、ポート6443への外部接続をブロックしていたため、firewalldを停止して無効にすることでした。

systemctl disable firewalld
systemctl stop firewalld

_結果を認識していないため、これを行うことはお勧めしません。これは、通常は使用しないOSでテストを完了するのに役立ちました。_

今、私のような初心者のインストールプロセスを簡単にするために何ができるのだろうかと思っています。 Created API client, waiting for the control plane to become readyで立ち往生してから物事を整理するまでの道のりは、特にこの問題を掘り下げてすべてのコメントを読むのに必要な時間を考慮に入れると、まだ巨大です。 __皆さんは何を提案できますか？__

@paulobezerrあなたの添付ファイルにあるものからあなたの問題は少し違うと思います。 私のapiserverログには次のようなものが含まれています。

reflector.go:190] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:46: Failed to list *v1.Pod:
Get https://localhost:6443/api/v1/pods?fieldSelector=spec.nodeName%3Dhostname&resourceVersion=0:
dial tcp RANDOM_IP:6443: getsockopt: connection refused

あなたが言う間：

reflector.go:190] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:46: Failed to list *v1.Pod:
Get https://10.X.X.X:6443/api/v1/pods?fieldSelector=spec.nodeName%3Dhostname&resourceVersion=0:
dial tcp 10.X.X.X:6443: getsockopt: connection refused

（前者の場合はlocalhost / RANDOM_IPですが、後者の場合は常に10.X.X.Xです）

残念ながら、 kubeadm init $のときにさまざまな--apiserver-advertise-address=???を試す以外に、何をアドバイスすればよいかわかりません（ドキュメントを参照）。 私の実際のk8sエクスペリエンスはちょうど10日に達しましたが、そのほとんどはFirstVDSでシングルノードクラスターを開始する無駄な試みでした:-)

これを分類して、ソリューションを他の人と共有してください。

@kachkaev次のファイアウォールルールを適用したことを忘れました。

$ Firewall-cmd --zone = public --add-port = 6443 / tcp --permanent && sudo Firewall-cmd --zone = public --add-port = 10250 / tcp --permanent && sudo systemctl restart Firewalld

ファイアウォールを非アクティブ化せずにこのルールを適用すると、私の環境では正常に機能します。 以前のコメントに追加して、必要なすべての手順を収集します。

@juntaoXieありがとう。 あなたのコメントごとにsystemdバージョンを更新することは私のために働いた。

この問題はまだ2日間発生していますが、プロキシの背後でこれらすべてを実行していますが、問題はないようです。
kubeadm initは、コントロールプレーンの準備が整うのを待っています。 docker psを実行すると、コンテナーがプルされて実行されますが、割り当てられたポートが遅れることはありません（想定されているかどうかはわかりませんが、問題ありません）。 etcdも正常に動作しています。 ただし、kubeletサービスを見ると、cni configを更新できません：/etc/cni/net.dにネットワークが見つかりません。https ：//github.com/kubernetes/kubernetes/issues/43815で問題ありません。 cniネットワークを適用する必要があります。
https://www.weave.works/docs/net/latest/kubernetes/kube-addon/に従って行います。 さて、kubectlは8080が拒否されたと言います-正しいホストまたはポートを指定しましたか？ 鶏が先か卵が先かという問題のようですが、kubeadm initがハングしたときにcniネットワークを適用するにはどうすればよいですか？ これはとても紛らわしいです

これもcgroupの問題ではなく、dockerと私のkubeletサービスの両方がsystemdを使用しています。

FWIW、私はGCPでこれと同じ問題を抱えていました。クリーンなプロジェクトで次のコマンドを使用してUbuntu16.04とCentOSを使用してみました。

$gcloudコンピューティングインスタンスcreatetest-api-01--zone us-west1-a --image-family ubuntu-1604-lts --image-project ubuntu-os-cloud --machine-type f1-micro --description ' APIテスト用のノード1 '

$gcloudコンピューティングインスタンスcreatetest-api-02--zone us-west1-b --image-family ubuntu-1604-lts --image-project ubuntu-os-cloud --machine-type f1-micro --description ' APIテスト用のノード2 '

$gcloudコンピューティングインスタンスcreatetest-api-03--zone us-west1-c --image-family ubuntu-1604-lts --image-project ubuntu-os-cloud --machine-type f1-micro --description ' APIテスト用のノード3」

$ apt-get update

$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-keyadd-

$ apt-get update && apt-get install -qy docker.io && apt-get install -y apt-transport-https

$ echo "deb http://apt.kubernetes.io/ kubernetes-xenial main"> /etc/apt/sources.list.d/kubernetes.list

$ apt-get update && apt-get install -y kubelet kubeadm kubernetes-cni

$ systemctl restart kubelet

$ kubeadm init

それで、数時間頭を打ち負かした後、私は結局次のようになりました：

$gcloudベータコンテナ--project"weather-177507"クラスターは"weather-api-cluster-1"--zone "us-west1-a" --username = "admin"--cluster-version"1.6.7"を作成します--machine-type "f1-micro" --image-type "COS" --disk-size "100" --scopes " https://www.googleapis.com/auth/compute "、 " https：// www.googleapis.com/auth/devstorage.read_only "、" https://www.googleapis.com/auth/logging.write "、" https://www.googleapis.com/auth/monitoring.write "、" https://www.googleapis.com/auth/servicecontrol "、" https://www.googleapis.com/auth/service.management.readonly "、" https://www.googleapis.com/auth/trace。追加"--num-nodes"3 "--network" default "--enable-cloud-logging --no-enable-cloud-monitoring --enable-legacy-authorization

空白のイメージからはできない場所でクラスターを稼働させることができました。

私でさえKubeadmバージョンで同じ問題に直面しています：

その行き詰まり
[apiclient] Created API client, waiting for the control plane to become ready

@paulobezerrと同じ問題-myenv ：CentOS 7.4.1708 kubeadm version：＆version.Info {Major： "1"、Minor： "8"、GitVersion： "v1.8.0"、GitCommit： "6e937839ac04a38cac63e6a7a306c5d035fe7b0a"、GitTreeState： "clean "、BuildDate：" 2017-09-28T22：46：41Z "、GoVersion：" go1.8.3 "、コンパイラ：" gc "、プラットフォーム：" linux / amd64 "}

私にとって、この問題はSELinuxを無効にした状態では実行されていませんでした。 手がかりは彼の歩み、コメントでした：

/ etc / selinux / configを編集し、SELINUX=disabledを設定します

CentOSのインストール手順（https://kubernetes.io/docs/setup/independent/install-kubeadm/）は次のようになります。
「コンテナがホストファイルシステムにアクセスできるようにするには、setenforce0を実行してSELinuxを無効にする必要があります」
ただし、（少なくともCentOS / RHEL / Fedoraタブでは）/ etc / selinux/configを編集してSELINUX=disabledに設定する必要があることについては言及されていません。

私にとっては、setenforce 0を実行したにもかかわらず、同じエラーが発生していました。 / etc / selinux / configを編集し、SELINUX = disableを設定してから、再起動すると修正されました。

ここでは（直交する可能性のある）問題がたくさんあるように思われるので、物事が分岐しないようにしたいと思っています。 これまでのところ、3つの問題を特定したようです。

1. 一部のマシンでは、DNSがローカルホストを正しく解決できません。 @kachkaev @paulobezerrこれを修正できましたか？ 要件でこれをより明確にする方法を知りたいのですが、何かアイデアはありますか？

2. kubeletとDockerのcgroup-driverの一致が正しくありません。 これを要件リストに追加する必要があります。

3. SELinuxは無効になっていません。 これを要件リストに追加する必要があります。

3つすべてがPRで対処されたら、おそらくこれを閉じて、将来問題が発生する人々に独自の問題を作成させる必要があります。 これにより、1つのスレッドで多くのことをやりくりするのではなく、より構造化された情報を受け取り、よりきめ細かいサポートを提供できるようになります。 @luxasはどう思いますか？

私の場合、docker 17.06（17.03が推奨されますが、docker.ioでは利用できません）を使用して、同じ問題で実行しました。 17.09にアップグレードすると、魔法のように問題が修正されました。

このスレッドは非常に長く、おそらくまったく異なる問題がたくさんあるので、 @ jamiehannafordの優れたコメント以外に追加できる最も生産的なことは、何かが起こった場合に備えて、関連するすべてのログ/情報で新しいターゲットを絞った問題を開いてください。 _最新のkubeadmv1.8_で失敗します。これは、以前のバージョンよりもはるかに優れた障害状態を自動的に検出します。 また、要件とエッジケースに関するドキュメントを改善し、人々の時間を節約できることを願っています。

みんなありがとう！

私は1.8のCENTOS7の1.8で同じ問題を抱えていましたか？ 誰もが同じ問題を抱えているか、修正方法を知っています。

@rushins発生している可能性のある問題についてサポートが必要な場合は、ここで十分な詳細を記載した新しい問題を開いてください。

@ rushabh268と同じ問題が発生しました。これはconnection refusedであり、 localhost:6443/apiではありません。
最後に、 search xxx.xx.xxxx.orgを検索しているドメインにコメントを付けて解決しました。

vi /etc/resolv.congf

------ resolv.congf -----
# Generated by NetworkManager
#search xxx.xx.xxxx.org
nameserver 10.x.xxx.xx
nameserver 10.x.xxx.xx
nameserver 10.x.xxx.xx
--------------------------

環境：
-> CentOS-7-x86_64-Minimal-1708
-> K8s v1.9.2
-> Docker v17.12.0.ce
->プライベートネットワークxxx.xx.xxxx.orgの下

神の愛のためにこれをドキュメントに追加してください。 「楽しんでテクノロジーで遊んでいる」という名目で仕事を終えて何晩もクラスターをセットアップしようとしてきましたが、nslookuplocalhostを実行しているときにマスターノードが正しいIPを取得できませんでした。

解決策を提供してくれた@kachkaevに感謝します。