我很难理解如何在kubernetes 1.10和containerd上正确配置带有法兰绒的kube-dns作为CRI。
kube-dns无法运行，出现以下错误：
kubectl -n kube-system logs kube-dns-595fdb6c46-9tvn9 -c kubedns
I0424 14:56:34.944476 1 dns.go:219] Waiting for [endpoints services] to be initialized from apiserver...
I0424 14:56:35.444469 1 dns.go:219] Waiting for [endpoints services] to be initialized from apiserver...
E0424 14:56:35.815863 1 reflector.go:201] k8s.io/dns/pkg/dns/dns.go:192: Failed to list *v1.Service: Get https://10.96.0.1:443/api/v1/services?resourceVersion=0: dial tcp 10.96.0.1:443: getsockopt: no route to host
E0424 14:56:35.815863 1 reflector.go:201] k8s.io/dns/pkg/dns/dns.go:189: Failed to list *v1.Endpoints: Get https://10.96.0.1:443/api/v1/endpoints?resourceVersion=0: dial tcp 10.96.0.1:443: getsockopt: no route to host
I0424 14:56:35.944444 1 dns.go:219] Waiting for [endpoints services] to be initialized from apiserver...
I0424 14:56:36.444462 1 dns.go:219] Waiting for [endpoints services] to be initialized from apiserver...
I0424 14:56:36.944507 1 dns.go:219] Waiting for [endpoints services] to be initialized from apiserver...
F0424 14:56:37.444434 1 dns.go:209] Timeout waiting for initialization
kubectl -n kube-system describe pod kube-dns-595fdb6c46-9tvn9
Type Reason Age From Message
---- ------ ---- ---- -------
Warning Unhealthy 47m (x181 over 3h) kubelet, worker1 Readiness probe failed: Get http://10.244.0.2:8081/readiness: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
Warning BackOff 27m (x519 over 3h) kubelet, worker1 Back-off restarting failed container
Normal Killing 17m (x44 over 3h) kubelet, worker1 Killing container with id containerd://dnsmasq:Container failed liveness probe.. Container will be killed and recreated.
Warning Unhealthy 12m (x178 over 3h) kubelet, worker1 Liveness probe failed: Get http://10.244.0.2:10054/metrics: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
Warning BackOff 2m (x855 over 3h) kubelet, worker1 Back-off restarting failed container
确实没有到10.96.0.1端点的路由：
ip route
default via 10.240.0.254 dev ens160
10.240.0.0/24 dev ens160 proto kernel scope link src 10.240.0.21
10.244.0.0/24 via 10.244.0.0 dev flannel.1 onlink
10.244.0.0/16 dev cni0 proto kernel scope link src 10.244.0.1
10.244.1.0/24 via 10.244.1.0 dev flannel.1 onlink
10.244.2.0/24 via 10.244.2.0 dev flannel.1 onlink
10.244.4.0/24 via 10.244.4.0 dev flannel.1 onlink
10.244.5.0/24 via 10.244.5.0 dev flannel.1 onlink
负责配置群集服务地址范围和关联路由的是什么？它是容器运行时，覆盖网络（在这种情况下是法兰绒）还是其他什么？应该在哪里配置？
10-containerd-net.conflist配置主机和我的pod网络之间的桥接。服务网络也可以配置在这里吗？
cat /etc/cni/net.d/10-containerd-net.conflist
{
"cniVersion": "0.3.1",
"name": "containerd-net",
"plugins": [
{
"type": "bridge",
"bridge": "cni0",
"isGateway": true,
"ipMasq": true,
"promiscMode": true,
"ipam": {
"type": "host-local",
"subnet": "10.244.0.0/16",
"routes": [
{ "dst": "0.0.0.0/0" }
]
}
},
{
"type": "portmap",
"capabilities": {"portMappings": true}
}
]
}
编辑：
从2016年开始this：
截至几个星期前（我忘记了发布，但它是1.2.x，其中x ！= 0）（＃24429）我们修复了路由，以便到达任何流量 在一个以服务IP为目的地的节点将被处理，就好像它来到了一个节点 节点端口。这意味着您应该能够为其设置静态路由 您的服务群集IP范围是一个或多个节点，节点将 充当桥梁。这与大多数人用法兰绒做的一样 桥接叠加层。
它不完美但它有效。未来将需要获得更多 如果你想要最佳行为（即不丢失），请准确地使用路由 客户端IP），或者我们将看到更多的非kube-proxy实现 服务。
这仍然相关吗？我是否需要为服务CIDR设置静态路由？或问题实际上是kube-proxy而不是法兰绒或容器？
我的法兰绒配置：
cat /etc/cni/net.d/10-flannel.conflist
{
"name": "cbr0",
"plugins": [
{
"type": "flannel",
"delegate": {
"hairpinMode": true,
"isDefaultGateway": true
}
},
{
"type": "portmap",
"capabilities": {
"portMappings": true
}
}
]
}
和kube-proxy：
[Unit]
Description=Kubernetes Kube Proxy
Documentation=https://github.com/kubernetes/kubernetes
[Service]
ExecStart=/usr/local/bin/kube-proxy \
--cluster-cidr=10.244.0.0/16 \
--feature-gates=SupportIPVSProxyMode=true \
--ipvs-min-sync-period=5s \
--ipvs-sync-period=5s \
--ipvs-scheduler=rr \
--kubeconfig=/etc/kubernetes/kube-proxy.conf \
--logtostderr=true \
--master=https://192.168.160.1:6443 \
--proxy-mode=ipvs \
--v=2
Restart=on-failure
RestartSec=5
[Install]
WantedBy=multi-user.target
编辑：
查看了kube-proxy debugging steps后，似乎kube-proxy无法与主人联系。我怀疑这是问题的很大一部分。我在HAProxy负载均衡器后面有3个控制器/主节点，它绑定到192.168.160.1:6443并将循环转发给10.240.0.1[1|2|3]:6443上的每个主服务器。这可以在上面的输出/配置中看到。
在kube-proxy.service中，我指定了--master=192.168.160.1:6443。为什么尝试连接端口443？我可以改变这个 - 似乎没有端口标志？是出于某种原因需要端口443吗？
答案 0 :(得分：1)
此答案有两个组成部分，一个是关于运行kube-proxy的，另一个是关于那些：443个网址的来源。
首先，关于kube-proxy：请不要将kube-proxy作为系统服务运行。它被设计为由kubelet 在群集中启动，以便SDN地址的行为合理，因为它们实际上是有效的＆＃34;假的＆＃34;地址。通过在kube-proxy控制范围之外运行kubelet，除非您花费大量精力来复制kubelet配置其下级docker容器的方式，否则将会发生各种奇怪的事情。
现在，关于：443网址：
E0424 14:56:35.815863 1 reflector.go:201] k8s.io/dns/pkg/dns/dns.go:192: Failed to list *v1.Service: Get https://10.96.0.1:443/api/v1/services?resourceVersion=0: dial tcp 10.96.0.1:443: getsockopt: no route to host...
为什么尝试连接端口443？我可以改变这个 - 它似乎不是一个端口标志吗？是出于某种原因需要端口443吗？
10.96.0.1来自您的集群的服务CIDR，它应该（并且应该）与Pod CIDR分开，该CIDR应该与Node的子网等分开。.1的群集的服务CIDR保留（或传统分配）到kubernetes.default.svc.cluster.local Service，其Service.port为443 --master
我不能确定为什么/etc/kubernetes/kube-proxy.conf标志不会取代kube-proxy中的值，但因为该文件非常明显地仅被{{1}使用，为什么不只是更新文件中的值以消除所有疑问？