我正在尝试按照Craig Robinson的博客帖子(在https://medium.com/swlh/guide-okd-4-5-single-node-cluster-832693cb752b)构建一个OKD 4.5单节点集群。我首先在引导节点上遇到这个问题，但是在删除并重新创建整个过程之后，它成功地启动了。但在准备控制平面主节点时又出现了同样的问题。初始coreos下载后(证明web服务器工作正常)，我得到这个反复出现的get错误消息一遍又一遍:
ignition[xxx]: GET error: Get "https://api-int.lab.okd.local:22623/config/master": EOF
这是控制平面节点配置:
ip=10.106.31.233::10.106.31.1:255.255.255.0:::none nameserver=10.106.31.231 coreos.inst.install_dev=/dev/sda coreos.inst.image_url=http://10.106.31.231:8080/okd4/ fcos.raw.xz coreos.inst.ignition_url=http://10.106.31.231:8080/okd4/master.ign
"诱导多能性"是:Okd-services: 10.106.31.231;引导:10.106.31.232;控制平面:10.106.31.233
我可以从远程pc到达http://10.106.31.231:8080/okd4地址，并列出包括master在内的内容。ign文件。还有ping api-int.lab.ok .local;也是成功的。okd-services节点上的防火墙开放端口为:
[root@okd4-services ~]# ss -ltu
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
udp UNCONN 0 0 0.0.0.0:hostmon 0.0.0.0:*
udp UNCONN 0 0 10.106.31.231:domain 0.0.0.0:*
udp UNCONN 0 0 127.0.0.1:domain 0.0.0.0:*
udp UNCONN 0 0 127.0.0.53%lo:domain 0.0.0.0:*
udp UNCONN 0 0 [::]:hostmon [::]:*
udp UNCONN 0 0 [::]:domain [::]:*
tcp LISTEN 0 128 0.0.0.0:ssh 0.0.0.0:*
tcp LISTEN 0 4096 127.0.0.1:rndc 0.0.0.0:*
tcp LISTEN 0 4096 0.0.0.0:https 0.0.0.0:*
tcp LISTEN 0 4096 0.0.0.0:22623 0.0.0.0:*
tcp LISTEN 0 4096 0.0.0.0:cslistener 0.0.0.0:*
tcp LISTEN 0 4096 0.0.0.0:sun-sr-https 0.0.0.0:*
tcp LISTEN 0 4096 0.0.0.0:hostmon 0.0.0.0:*
tcp LISTEN 0 4096 0.0.0.0:http 0.0.0.0:*
tcp LISTEN 0 10 10.106.31.231:domain 0.0.0.0:*
tcp LISTEN 0 10 127.0.0.1:domain 0.0.0.0:*
tcp LISTEN 0 4096 127.0.0.53%lo:domain 0.0.0.0:*
tcp LISTEN 0 128 [::]:ssh [::]:*
tcp LISTEN 0 4096 [::1]:rndc [::]:*
tcp LISTEN 0 4096 [::]:hostmon [::]:*
tcp LISTEN 0 511 *:webcache *:*
tcp LISTEN 0 10 [::]:domain [::]:*
okd-services节点上的dig测试输出为:
[root@okd4-services ~]# dig -x 10.106.31.231
; <<>> DiG 9.11.25-RedHat-9.11.25-2.fc33 <<>> -x 10.106.31.231
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60620
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;231.31.106.10.in-addr.arpa. IN PTR
;; ANSWER SECTION:
231.31.106.10.in-addr.arpa. 604800 IN PTR api-int.lab.okd.local.
231.31.106.10.in-addr.arpa. 604800 IN PTR api.lab.okd.local.
231.31.106.10.in-addr.arpa. 604800 IN PTR okd4-services.okd.local.
;; SERVER: 127.0.0.53#53(127.0.0.53)
我删除并重新创建了控制平面，看看它是否解决了问题，但没有成功。知道这个问题意味着什么吗?
我对这篇文章也有同样的问题。问题是引导节点无法完成初始化过程。首先，初始化引导节点，并确保该过程已经完成。查看节点运行情况的最简单方法:
- 用
ssh core@<NODE'S-IP>从生成ssh-certificate的机器连接到一个节点 - ssh将为您提供有用的信息:
这是bootstrap节点;它会在主人死的时候被摧毁完全。
主要业务是release-image。服务紧随其后bootkube.service。要查看它们的状态，运行例如
journalctl -b -f -u release-image。Service -u bootkube。服务这为引导节点;它会在主人完全
。主要业务是release-image。服务紧随其后bootkube.service。要查看它们的状态，运行例如
journalctl -b -f -u release-image。Service -u bootkube。服务FedoraCoreOS 32.20200629.3.0跟踪器https://github.com/coreos/fedora-coreos-tracker讨论:https://discussion.fedoraproject.org/c/server/coreos/
- 首先你必须检查
journalctl -b -f -u release-image.service -u bootkube.service，因为它是主要单位。然而，可能还有其他问题，所以检查失败/未完成systemd的服务单元与systemctl list-units --type=service和journalctl -f -u <UNIT-NAME>遵循过程 - 整个过程将花费一些时间(在我的情况下~20-40分钟)，并且可能在日志的日志中有一些超时，因此只需等待单元的最终状态。
- 只有这样你才能开始初始化控制平面节点
最后，我的问题是在错误的fedora-core-os版本，因为你只能使用32版本。对我来说，使用
就可以安装了- fedora-coreos-32.20201104.3.0-metal.x86_64.raw.xz
- fedora-coreos-32.20201104.3.0-metal.x86_64.raw.xz.sig
- fedora-coreos-32.20201104.3.0-live.x86_64.iso
- openshift -客户- linux - 4.5.0 - 0. - okd - 2020 - 10 - 15 - 235428. - tar.gz
- openshift -安装- linux - 4.5.0 - 0. - okd - 2020 - 10 - 15 - 235428. - tar.gz