Kubernetes:AKS Ingress仅与同一节点和子网上的Pod通信

时间:2019-06-11 15:26:02

标签: kubernetes azure-aks

我部署了一个3节点的AKS kubernetes集群(kubenet是网络覆盖),NGINX Ingress配置为对Pod执行基于名称的路由。

我在群集上以不同的名称部署了许多相同的应用程序。

我可以通过http访问某些应用程序,但不能访问其他应用程序。经过仔细检查,我发现可以到达的应用程序都与入口控制器位于同一节点上,并且位于内部172. *子网中。

所有应用程序都与入口控制器位于同一命名空间中。

无法访问的应用程序全部位于其他2个节点和不同的子网中。看来这是网络配置问题。

但是,我找不到任何相关的配置将允许入口访问所有应用程序,而与它们处于哪个节点和内部子网无关。我认为,这应该是Kubernetes的默认行为。

我该如何配置所需的行为?

一些测试结果:

 kubectl logs https-ingress-controller-6bc79d6c69-7ljkb  --namespace ingress-nginx --follow
-------------------------------------------------------------------------------
NGINX Ingress controller
  Release:    0.23.0
  Build:      git-be1329b22
  Repository: https://github.com/kubernetes/ingress-nginx
-------------------------------------------------------------------------------

W0611 14:37:06.679648       6 flags.go:213] SSL certificate chain completion is disabled (--enable-ssl-chain-completion=false)
nginx version: nginx/1.15.9
W0611 14:37:06.685012       6 client_config.go:549] Neither --kubeconfig nor --master was specified.  Using the inClusterConfig.  This might not work.
I0611 14:37:06.685884       6 main.go:200] Creating API client for https://172.17.0.1:443
I0611 14:37:06.712278       6 main.go:244] Running in Kubernetes cluster version v1.14 (v1.14.0) - git (clean) commit 641856db18352033a0d96dbc99153fa3b27298e5 - platform linux/amd64
I0611 14:37:07.055688       6 nginx.go:261] Starting NGINX Ingress controller
I0611 14:37:07.066491       6 event.go:221] Event(v1.ObjectReference{Kind:"ConfigMap", Namespace:"ingress-nginx", Name:"tcp-services", UID:"56d2e0c2-8c47-11e9-8911-8272a7251f4e", APIVersion:"v1", ResourceVersion:"5775", FieldPath:""}): type: 'Normal' reason: 'CREATE' ConfigMap ingress-nginx/tcp-services
I0611 14:37:07.067855       6 event.go:221] Event(v1.ObjectReference{Kind:"ConfigMap", Namespace:"ingress-nginx", Name:"nginx-configuration", UID:"56cdccf4-8c47-11e9-8911-8272a7251f4e", APIVersion:"v1", ResourceVersion:"5774", FieldPath:""}): type: 'Normal' reason: 'CREATE' ConfigMap ingress-nginx/nginx-configuration
I0611 14:37:07.075165       6 event.go:221] Event(v1.ObjectReference{Kind:"ConfigMap", Namespace:"ingress-nginx", Name:"udp-services", UID:"56d6c9e3-8c47-11e9-8911-8272a7251f4e", APIVersion:"v1", ResourceVersion:"5776", FieldPath:""}): type: 'Normal' reason: 'CREATE' ConfigMap ingress-nginx/udp-services
I0611 14:37:08.159406       6 event.go:221] Event(v1.ObjectReference{Kind:"Ingress", Namespace:"ingress-nginx", Name:"https-ingress", UID:"103260ed-8c4a-11e9-8911-8272a7251f4e", APIVersion:"extensions/v1beta1", ResourceVersion:"17054", FieldPath:""}): type: 'Normal' reason: 'CREATE' Ingress ingress-nginx/https-ingress
I0611 14:37:08.160481       6 backend_ssl.go:68] Adding Secret "ingress-nginx/chachingtls" to the local store
I0611 14:37:08.256541       6 nginx.go:282] Starting NGINX process
I0611 14:37:08.256572       6 leaderelection.go:205] attempting to acquire leader lease  ingress-nginx/ingress-controller-leader-nginx...
I0611 14:37:08.257345       6 controller.go:172] Configuration changes detected, backend reload required.
I0611 14:37:08.261914       6 status.go:148] new leader elected: nginx-ingress-controller-6674b5b5dc-nhjcc
I0611 14:37:08.328794       6 event.go:221] Event(v1.ObjectReference{Kind:"Ingress", Namespace:"ingress-nginx", Name:"https-ingress", UID:"103260ed-8c4a-11e9-8911-8272a7251f4e", APIVersion:"extensions/v1beta1", ResourceVersion:"17059", FieldPath:""}): type: 'Normal' reason: 'UPDATE' Ingress ingress-nginx/https-ingress
I0611 14:37:08.391940       6 controller.go:190] Backend successfully reloaded.
I0611 14:37:08.392044       6 controller.go:200] Initial sync, sleeping for 1 second.
[11/Jun/2019:14:37:09 +0000]TCP200000.000


  • 相同名称空间中的应用程序容器列表:
NAME                                        READY   STATUS    RESTARTS   AGE   IP            NODE                       NOMINATED NODE   READINESS GATES
durian                                      1/1     Running   0          12m   172.18.0.14   aks-agentpool-82039614-0   <none>           <none>
https-ingress-controller-6bc79d6c69-mg7lm   1/1     Running   0          15m   172.18.2.11   aks-agentpool-82039614-2   <none>           <none>
kiwi                                        1/1     Running   0          12m   172.18.2.14   aks-agentpool-82039614-2   <none>           <none>
mango                                       1/1     Running   0          13m   172.18.2.12   aks-agentpool-82039614-2   <none>           <none>
mangosteen                                  1/1     Running   0          12m   172.18.2.13   aks-agentpool-82039614-2   <none>           <none>
orange                                      1/1     Running   0          12m   172.18.2.15   aks-agentpool-82039614-2   <none>           <none>
  • 不同的内部网络和节点:超时:
kubectl exec -ti https-ingress-controller-6bc79d6c69-mg7lm  /bin/bash -n ingress-nginx
www-data@https-ingress-controller-6bc79d6c69-7ljkb:/etc/nginx$
www-data@https-ingress-controller-6bc79d6c69-7ljkb:/etc/nginx$
www-data@https-ingress-controller-6bc79d6c69-7ljkb:/etc/nginx$ curl http://172.18.1.10:5678
^C
  • 相同的内部网络和节点-确定:
www-data@https-ingress-controller-6bc79d6c69-7ljkb:/etc/nginx$
www-data@https-ingress-controller-6bc79d6c69-7ljkb:/etc/nginx$
www-data@https-ingress-controller-6bc79d6c69-7ljkb:/etc/nginx$ curl http://172.18.2.9:5679
mango
  • 相同的内部网络和节点-确定:
www-data@https-ingress-controller-6bc79d6c69-7ljkb:/etc/nginx$ curl http://172.18.2.5:8080
<!-- HTML for static distribution bundle build -->
<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8">
    <title>Swagger UI</title>
    <link rel="stylesheet" type="text/css" href="./swagger-ui.css" >
    <link rel="icon" type="image/png" href="./favicon-32x32.png" sizes="32x32" />
    <link rel="icon" type="image/png" href="./favicon-16x16.png" sizes="16x16" />
    <style>
      html
  • 不同的内部网络/节点-超时:
www-data@https-ingress-controller-6bc79d6c69-7ljkb:/etc/nginx$ curl http://172.18.1.9:5678

^C

我已经多次破坏并重新部署了群集和应用程序,它们具有完全相同的配置,并且行为相同。

2 个答案:

答案 0 :(得分:1)

对于AKS中的kubelet网络,pod可以相互通信。您会看到以下说明:

  

使用kubenet,节点从Azure虚拟网络获取IP地址   子网。 Pod从逻辑上不同的地址接收IP地址   节点的Azure虚拟网络子网的空间。网络   然后配置地址转换(NAT),以便Pod可以   访问Azure虚拟网络上的资源。的源IP地址   流量将被NAT到该节点的主IP地址。

pod可以与其他通过NAT的节点进行通信。而且只有节点可以接收可路由的IP地址。您可以在门户中看到这样的路线:

https://github.com/ionic-team/ionic-cli/blob/develop/packages/ionic/CHANGELOG.md#lollipop-upgrading-from-cli-4

Azure将为您做所有事情。在我这边效果很好。因此,如果它对您不起作用。然后,您可以检查路由是否正确。

以下是屏幕快照,用于测试不同地址空间中Pod的通信:

enter image description here

答案 1 :(得分:1)

在kubenet网络模型的情况下,当使用预先存在的VNET和子网(非专用于AKS)时,带有ADR的AKS节点的路由表未附加到将节点部署到的子网中默认情况下,这意味着Pod无法跨节点相互访问。

Microsoft Azure文档中提到了需要为kubenet配置UDR的事实,但是在路由表和AKS的UDR的实际设置中未提供任何说明。

将路由表附加到AKS子网后,必须创建这些路由,或者将路由添加到该子网的现有路由表(如果存在)。

此处记录了该解决方案,它基本上涉及将AKS安装生成的默认路由表附加到AKS子网:

https://github.com/Azure/aks-engine/blob/master/docs/tutorials/custom-vnet.md

即,自定义并运行此脚本:

#!/bin/bash
rt=$(az network route-table list -g RESOURCE_GROUP_NAME_KUBE -o json | jq -r '.[].id')
az network vnet subnet update \
-g RESOURCE_GROUP_NAME_VNET \
--route-table $rt \
--ids "/subscriptions/SUBSCRIPTION_ID/resourceGroups/RESOURCE_GROUP_NAME_VNET/providers/Microsoft.Network/VirtualNetworks/KUBERNETES_CUSTOM_VNET/subnets/KUBERNETES_SUBNET"

我现在可以通过Ingress到达群集所有节点上的Pod。

注意:或者,可以在部署AKS之前将UDR手动添加到您可以附加到预先创建的AKS子网的任何现有路由表中。