首页 文章

Kubernetes中的服务是否只是反向允许持续联系的代理？

提问于
浏览 次
1

我正在研究Kubernetes Services（这是k8s组件之一，很像Pods和ReplicaSets） . 它们似乎像反向代理一样运行，但我知道k8s内部使用DNS，所以也许它们是某种负载均衡DNS？此外，它会以某种方式表示，由于Pod可以重新定位或存在于许多节点上，因此它不能简单地成为反向代理，因为它也需要可寻址，但在许多机器上共享一个IP ...（显然在挣扎）想象一下如何在不直接查看源代码的情况下构建它们 - 但是） .

什么构成了K8s服务？ DNS反向代理，还是更多/更少？某种网络技巧？

dns kubernetes reverse-proxy

2 回答

  • 2

    常规ClusterIP服务

    确保 type: ClusterIP 服务的网络连接是kube-proxy的责任 - 通常在群集的每个节点上运行的组件 . kube-proxy通过拦截来自每个节点上的Pod的传出流量并过滤针对服务IP的流量来实现此目的 . 由于它连接到Kubernetes API，因此kube-proxy可以确定哪些Pod IP与每个服务IP相关联，并且可以相应地转发流量 .

    从概念上讲，kube-proxy可能被认为类似于反向代理（因此名称），但通常使用IPtables规则（或者，从Kubernetes 1.9开始，可选IPVS） . 每个创建的服务将在每个节点上产生一组IPtables规则，这些规则拦截并将针对服务IP的流量转发到相应的Pod IP（服务IP纯粹是虚拟的，并且仅存在于这些IPtables规则中;在整个群集中，您将无处可去找到一个持有该IP的实际网络接口 .

    负载 balancer 也通过IPtables规则（或IPVS）实现 . 负载 balancer 始终发生在流量源自的源节点上 .

    以下是文档Debug Services部分的示例：

    u@node$ iptables-save | grep hostnames
-A KUBE-SEP-57KPRZ3JQVENLNBR -s 10.244.3.6/32 -m comment --comment "default/hostnames:" -j MARK --set-xmark 0x00004000/0x00004000
-A KUBE-SEP-57KPRZ3JQVENLNBR -p tcp -m comment --comment "default/hostnames:" -m tcp -j DNAT --to-destination 10.244.3.6:9376
-A KUBE-SEP-WNBA2IHDGP2BOBGZ -s 10.244.1.7/32 -m comment --comment "default/hostnames:" -j MARK --set-xmark 0x00004000/0x00004000
-A KUBE-SEP-WNBA2IHDGP2BOBGZ -p tcp -m comment --comment "default/hostnames:" -m tcp -j DNAT --to-destination 10.244.1.7:9376
-A KUBE-SEP-X3P2623AGDH6CDF3 -s 10.244.2.3/32 -m comment --comment "default/hostnames:" -j MARK --set-xmark 0x00004000/0x00004000
-A KUBE-SEP-X3P2623AGDH6CDF3 -p tcp -m comment --comment "default/hostnames:" -m tcp -j DNAT --to-destination 10.244.2.3:9376
-A KUBE-SERVICES -d 10.0.1.175/32 -p tcp -m comment --comment "default/hostnames: cluster IP" -m tcp --dport 80 -j KUBE-SVC-NWV5X2332I4OT4T3
-A KUBE-SVC-NWV5X2332I4OT4T3 -m comment --comment "default/hostnames:" -m statistic --mode random --probability 0.33332999982 -j KUBE-SEP-WNBA2IHDGP2BOBGZ
-A KUBE-SVC-NWV5X2332I4OT4T3 -m comment --comment "default/hostnames:" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-X3P2623AGDH6CDF3
-A KUBE-SVC-NWV5X2332I4OT4T3 -m comment --comment "default/hostnames:" -j KUBE-SEP-57KPRZ3JQVENLNBR

    有关更多信息，请查看手册中的Virtual IPs and Service Proxies部分 .

    无头服务

    除常规 ClusterIP 服务外，还有Headless Services（通过在创建服务时指定属性 clusterIP: None 来声明） . 这些不会使用kube-proxy;相反，他们的DNS主机名将直接解析为与该服务关联的所有Pod IP . 通过常规DNS循环实现负载 balancer .

    回复于
  • 1

    对于集群内的服务和路由，主要是iptables，除非您明确使用ipvs（部分使用iptables）或类似Cillium（允许您插入BFP） . 每个节点中的kube-proxy管理iptable规则 . 有关代理模式如何here的更多信息 .

    在DNS方面，Kubernetes运行kube-dns（1.10或更早版本）或coredns（1.11或更新版本），并且基本上所有服务和pod都在该DNS服务中注册，以便其他pod /容器找到它们 . 例如，服务将具有如下FQDN： my-service.my-namespace.svc.cluster.local 有关该here的更多信息 .

    回复于

相关问题