我正在学习Kubernetes并且目前深入了解高可用性，虽然我知道我可以设置一个高度可用的控制平面（API服务器，控制器，调度程序）与本地（或远程）etcd以及高度可用可用的一组小兵（通过Kubernetes本身），我仍然不确定这个概念服务的位置。
如果他们住在控制平面上：好我可以将它们设置为高可用性。
如果他们住在某个节点上：好的，但是如果节点出现故障或以其他任何方式变得不可用会发生什么？
据我所知，需要服务才能将我的pod暴露给互联网以及负载均衡。因此，没有HA服务，我冒着我的应用程序无法访问的风险（即使它可能超级高可用于系统的任何其他方面）。
答案 0 :(得分：3)
您可以将服务视为内部（在某些情况下是外部）负载均衡器。该定义存储在Kubernetes API服务器中，但如果某些内容没有实现，那么它存在的事实就没有任何意义。与服务一起使用的最常见的组件是kube-proxy，它使用iptables在节点上实现服务（意味着每个节点都有在其中实现的每个服务的本地iptables规则），但也有。 Ingress Controller实现，它使用API中的服务概念来查找端点并将流量定向到它们，从而有效地跳过iptables实现。最后有一些服务网格解决方案，如linkerd或istio，可以自行利用服务定义。
大多数实施中的pod之间的服务负载平衡，这意味着只要你有一个支持pod（并且有足够的容量）你的＆＃34;服务＆＃34;会做出回应（所以你也会得到HA，特别是如果你实施准备/活性探测，除其他事项外，还会从服务中删除不健康的pod）
Kubernetes Service文档提供了很好的洞察力
答案 1 :(得分：2)
Kubernetes Service是k8s群集中的另一个REST对象。有以下类型的服务。它们中的每一个在集群中都有不同的用途。
服务的基本目的
这些对象存储在etcd 中，因为它是群集中的单一事实来源。
Kube-proxy负责创建这些对象。它使用选择器和标签。
例如，每个pod对象都有标签，因此服务对象具有与这些标签匹配的选择器。此外，每个Pod都有端点，因此kube-proxy基本上将这些端点（IP：端口）与服务（IP：端口）分配.Kube-proxy使用IP-Tables规则来实现这一点。
Kube-Proxy在每个群集节点中部署为DaemonSet，因此他们通过使用etcd了解彼此。