kube-dns getsockopt没有主机路径

Question

我很难理解如何正确地配置kube，在kubernetes 1.10上使用法兰绒，并将容器配置为CRI。

kube运行失败，有以下错误：

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年的这：

就在几周前(我忘记了发布，但它是一个1.2.x，其中x != 0) (#24429)，我们修复了路由，这样到达到服务IP的节点的任何通信都将被处理，就像到达节点端口一样。这意味着您应该能够将服务集群IP范围的yo静态路由设置为一个或多个节点，节点将充当桥梁。这和大多数人用法兰绒搭桥的手法是一样的。 这是不完美的，但它有效。如果您想要最优的行为(即不丢失客户端IP)，那么未来的路由将需要更加精确，或者我们将看到更多的服务的非kube代理实现。

这还相关吗？是否需要为服务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-代理：

[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-代理调试步骤之后，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端口吗？

Answer 1

这个答案有两个组件，一个是关于运行kube-proxy的，另一个是关于这些URL的来源:443个URL。

首先，关于kube-proxy：请不要将kube-proxy作为系统服务运行。它被设计为由集群中的kubelet启动，以便SDN地址行为合理，因为它们实际上是“假”地址。通过在kube-proxy控制之外运行kubelet，所有奇怪的事情都会发生，除非您花费大量的精力来复制kubelet配置其附属码头容器的方式。

现在，关于这个:443 URL：

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分离的，Pod CIDR应该与节点的子网分离，等等。集群的服务CIDR的.1要么被保留(或者传统上被分配)给kubernetes.default.svc.cluster.local Service，它的一个Service.port作为443。

我不太清楚为什么--master标志不取代/etc/kubernetes/kube-proxy.conf中的值，但是由于该文件显然只应该由kube-proxy使用，为什么不直接更新文件中的值以消除所有疑问？