请问：部署OpenKruise官方提供的 CloneSet 服务，报以下GateWay错误，是什么原因？多谢

[dingsihua]

通过 kubectl apply -f nginx-demo.yaml 部署官方的 CloneSet 服务，报以下错误，请问是什么原因？其中，nginx-demo.yaml是官方指导手册的第一个示例：https://openkruise.io/zh/docs/user-manuals/cloneset

Error from server (InternalError): error when creating "nginx-demo.yaml": Internal error occurred: failed calling webhook "mcloneset.kb.io": Post "https://kruise-webhook-service.kruise-system.svc:443/mutate-apps-kruise-io-v1alpha1-cloneset?timeout=30s": Gateway Time-out

[veophi]

@dingsihua 这种情况一般是 kruise-manager pod 没有被拉起来

[dingsihua]

@veophi pod起来了呀

[root@szvp000316908 openkruise]# kubectl -n kruise-system get pods
NAME READY STATUS RESTARTS AGE
kruise-controller-manager-6cb69cd999-hc7vt 1/1 Running 0 67m
kruise-controller-manager-6cb69cd999-srgsl 1/1 Running 0 67m
kruise-daemon-7v9jh 1/1 Running 0 67m
kruise-daemon-7wk9z 1/1 Running 0 67m

[FillZpp]

@dingshu 如果 kruise-manager 运行正常，那么很大程度上的问题是出在 kube-apiserver 连接到 kruise-manager pod 的网络上不通，可以确认一下（比如说，如果两者的网络是在不同的 vpc 中，要确保打通，能让 kube-apiserver 连接和访问 kruise-manager pod）

[dingsihua]

• @FillZpp
  1、我从主机网络命名空间（kube-apiserver部署在主机网络）能 ping 通 kruise-manager 容器的IP地址，说明网络是通的，但部署还是出现Gateway Time-out错误。
  2、我这个集群是内网环境，为了访问internet，配置了代理（验证了下、删除代理也一样），会影响这个问题麽？

[root@szvp000316908 openkruise]#
[root@szvp000316908 openkruise]# kubectl get nodes -A
NAME STATUS ROLES AGE VERSION
shaphisprk01997 Ready 18h v1.19.3
szvp000316908 Ready master 18h v1.19.3
[root@szvp000316908 openkruise]#
[root@szvp000316908 openkruise]#
[root@szvp000316908 openkruise]# kubectl get nodes -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
shaphisprk01997 Ready 18h v1.19.3 100.107.223.61 EulerOS 2.0 (SP5) 3.10.0-862.14.1.5.h359.eulerosv2r7.x86_64 docker://18.9.0
szvp000316908 Ready master 18h v1.19.3 10.120.51.40 EulerOS 2.0 (SP5) 3.10.0-862.14.1.5.h359.eulerosv2r7.x86_64 docker://18.9.0
[root@szvp000316908 openkruise]#
[root@szvp000316908 openkruise]# kubectl get pods -A -o wide
NAMESPACE NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
kruise-system kruise-controller-manager-6cb69cd999-8t2q4 1/1 Running 0 16h 192.168.1.3 shaphisprk01997
kruise-system kruise-controller-manager-6cb69cd999-m22xp 1/1 Running 0 16h 192.168.1.2 shaphisprk01997
kruise-system kruise-daemon-j8zrq 1/1 Running 0 16h 10.120.51.40 szvp000316908
kruise-system kruise-daemon-wsrmp 1/1 Running 0 16h 100.107.223.61 shaphisprk01997
kube-system coredns-f9fd979d6-srnbp 1/1 Running 0 18h 192.168.0.3 szvp000316908
kube-system coredns-f9fd979d6-vbzv2 1/1 Running 0 18h 192.168.0.2 szvp000316908
kube-system etcd-szvp000316908 1/1 Running 0 18h 10.120.51.40 szvp000316908
kube-system kube-apiserver-szvp000316908 1/1 Running 0 18h 10.120.51.40 szvp000316908
kube-system kube-controller-manager-szvp000316908 1/1 Running 0 18h 10.120.51.40 szvp000316908
kube-system kube-flannel-ds-9vg6x 1/1 Running 0 18h 10.120.51.40 szvp000316908
kube-system kube-flannel-ds-smnxr 1/1 Running 0 18h 100.107.223.61 shaphisprk01997
kube-system kube-proxy-bm92t 1/1 Running 0 18h 10.120.51.40 szvp000316908
kube-system kube-proxy-slpwr 1/1 Running 0 18h 100.107.223.61 shaphisprk01997
kube-system kube-scheduler-szvp000316908 1/1 Running 0 18h 10.120.51.40 szvp000316908
[root@szvp000316908 openkruise]#
[root@szvp000316908 openkruise]# ping 192.168.1.3
PING 192.168.1.3 (192.168.1.3) 56(84) bytes of data.
64 bytes from 192.168.1.3: icmp_seq=1 ttl=63 time=3.23 ms
^C
--- 192.168.1.3 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 3.239/3.239/3.239/0.000 ms
[root@szvp000316908 openkruise]#
[root@szvp000316908 openkruise]#
[root@szvp000316908 openkruise]# ping 192.168.1.2
PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data.
64 bytes from 192.168.1.2: icmp_seq=1 ttl=63 time=3.24 ms
64 bytes from 192.168.1.2: icmp_seq=2 ttl=63 time=2.97 ms
^C
--- 192.168.1.2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 2.971/3.106/3.241/0.135 ms
[root@szvp000316908 openkruise]#
[root@szvp000316908 openkruise]#
[root@szvp000316908 openkruise]# kubectl apply -f nginx-demo.yaml
Error from server (InternalError): error when creating "nginx-demo.yaml": Internal error occurred: failed calling webhook "mcloneset.kb.io": Post "https://kruise-webhook-service.kruise-system.svc:443/mutate-apps-kruise-io-v1alpha1-cloneset?timeout=30s": Gateway Time-out
[root@szvp000316908 openkruise]#

[FillZpp]

ping通说明三层是通的，可以用 telnet 192.168.1.2 9876 看一下能连通 kruise-manager webhook server 吗？

[dingsihua]

@FillZpp telnet没有登录成功，过一段时间显示连接被外部host closed了，有问题麽？
[root@szvp000316908 openkruise]# telnet 192.168.1.2 9876
Trying 192.168.1.2...
Connected to 192.168.1.2.
Escape character is '^]'.

Connection closed by foreign host.

[haozi4go]

遇到了同样的问题，这个问题有解了吗？

我的排查过程如下，但是仍未解决该问题，跪求指教

第一步：先测试了集群内的正常的pod的网络如下
/ # ping nginx-deploy-java-3.ssx-nginx-ns.svc.cluster.local
PING nginx-deploy-java-3.ssx-nginx-ns.svc.cluster.local (10.244.242.244): 56 data bytes
64 bytes from 10.244.242.244: seq=0 ttl=63 time=0.067 ms
64 bytes from 10.244.242.244: seq=1 ttl=63 time=0.070 ms
64 bytes from 10.244.242.244: seq=2 ttl=63 time=0.080 ms
64 bytes from 10.244.242.244: seq=3 ttl=63 time=0.057 ms
^C
--- nginx-deploy-java-3.ssx-nginx-ns.svc.cluster.local ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 0.057/0.068/0.080 ms
/ #

第二步：测试了报错的域名，和上个解析的ip不在一个网段
/ # ping kruise-webhook-service.kruise-system.svc
PING kruise-webhook-service.kruise-system.svc (10.103.97.255): 56 data bytes
^C
--- kruise-webhook-service.kruise-system.svc ping statistics ---
17 packets transmitted, 0 packets received, 100% packet loss
/ #
3. ping 有问题域名解析的ip，发现ping不通
/ # ping 10.103.97.255
PING 10.103.97.255 (10.103.97.255): 56 data bytes

问题：10.103.x.x这个网段的ip是怎么来的呢，如何配置呢（当前k8s集群使用的calico部署集群网络，pod的网段为10.244.0.0/16），这个网段怎么能和集群现有网段通信呢，求指教🙏

[FillZpp]

@haozi4go 首先，kube-apiserver 在调用 webhook 的时候，并不是直接调用 svc 域名的，而是直接从 endpoints 拿到 svc 后端 Pod IP 地址，然后直连这个 IP，因此不涉及域名解析问题。因此，你要在 kube-apiserver 上面尝试连到 kruise-controller-manager Pod 的 IP 以及端口，而不是这个 svc 域名。

其次，即使 ping 域名的 IP 不通，也要看你们集群和网络环境中的 DNS 解析相关的配置了，这个我就不太清楚了。