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