一 服务如何通过kubernetes集群的组件来实现其功能
1.1 节点上的所有的服务相关的功能实现都是通过节点上面的kube-proxy来实现的，服务提供了一个或者多个服务IP以及端口对客户端开放，将其中的流量转发到对应的后端的pod上面去，每个service都有其稳定的IP地址以及端口，IP地址是虚拟的，并没有分配给任何实际的设备，所有服务IP本身并不能代表任何东西，这就是你无法ping通它的真正原因
1.2 kube-proxy如何将一个发到请求的service转到相应的后端，以及各个节点如何能够知道service的地址
在API服务器创建了一个service的时候，立马会分配一个IP地址给它，之后API服务器在很短的时间内通知到所有的kube-proxy有一个服务已经创建了，然后kube-proxy会让该IP在其所在的节点上可寻址，原理是建立一系列iptables规则，使得到目的地为服务的IP和端口被修改，如此就能将请求重定向到pod中
下面演示一个到服务的请求如何被重定向到其他的pod中
- 当节点A上的podA向服务发起请求的时候，节点上的内核里面的iptables规则有一条规矩就是如果目的地址为服务的IP则随机替换到服务的endpoint里面一个pod里面去
- 所有实际上，从头到尾，这个服务的IP就是一个极其虚拟的
二 运行高可用的集群
2.1 让应用高可用
将应用运行在集群上的理由是，kubernets天然给你提供负载均衡，高可用以及很多好的特性
如果需要做到这一点，需要你的应用能支持这点，如果不支持也没关系，可以将副本设置为1，并且还可以利用选举机制，就是创建多个你的副本应用，但是在任意的时间内，只有一个是可以对外提供服务，当这个节点挂掉之后，其余节点会感知到并与其他节点互相竞选提供服务的节点
2.2 让kubernetes集群高组件高可用
让kubernets集群高可用的图示如下所示
- etcd高可用，一般将其设置为奇数个，3，5，7等
- api服务器的数量保持和etcd一致就可以了，etcd就不需要搭载负载均衡器，而API服务器则需要一个负载均衡器，这样可以保证客户端总能连接到健康的实例
- 调度器和控制器一样的，都只能有一个是工作的状态，其余的则是等到active节点挂了的时候在去竞争