k8s在容器云上的负载均衡策略和总体思想是什么？

高可用主要分为如下几个：
-外部镜像仓库高可用
外部镜像仓库独立于OCP平台之外，用于存储平台构建过程中所使用的系统组件镜像。因为外部无法直接访问OCP平台的内部镜像仓库，所以由QA环境CD推送到生产环境的镜像也是先复制到外部镜像仓库，再由平台导入至内部镜像仓库。
为了保证外部镜像仓库的高可用， 使用了2台服务器，前端使用F5进行负载均衡，所有的请求均发至F5的虚拟地址，由F5进行转发。后端镜像仓库通过挂载NFS共享存储。

-master主控节点高可用
Openshift的Master主控节点承担了集群的管理工作，

-计算节点（容器应用）高可用
计算节点高可用指计算节点上运行的容器应用的高可用。一个计算节点异常停机后，其上的容器将会被逐步迁移到其他节点上，从而保证了高可用。
同时可以通过标签的方式来管理计算节点，在不同的计算节点划分为不同的可用区或组。在部署应用时，使用节点选择器将应用部署至带有指定标签的目标计算节点上。为了保证高可用，标签组合的目标计算节点数要大于1。这样可以避免一台目标节点宕机后，调度器还能找到满足条件的计算节点进行容器部署。

-应用高可用
基于软件（HAproxy）负载均衡服务，容器服务弹性伸缩时无需人工对负载均衡设备进行配置干预，即可保证容器化应用的持续、正常访问；可通过图形界面自定义负载均衡会话保持策略。
由于平台内部通过软件定义网络为每个应用容器分配了IP地址，而此地址是内网地址，因此外部客户无法直接访问到该地址，所以平台使用路由器转发外部的流量到集群内部具体的应用容器上，如果应用有多个容器实例，路由器也可实现负载均衡的功能。路由器会动态的检测平台的元数据仓库，当有新的应用部署或者应用实例发生变化时，路由器会自动根据变化更新路由信息，从而实现动态负载均衡的能力。

serveice discovery通过内部dns实现的，service对应后端pod的负载均衡体现在大量iptables规则中，除了iptables外还有ipvs的实现方式
1.对k8s内部，通过默认${服务名}.${名字空间}.cluster.local 域名请求，然后会转发到后端pod
2.对k8s外部，可以通过nodePort(不同服务不同Port)、ingress(基于virtualhost, 支持定制负载均衡的策略)访问对外部提供，然后请求会走到serverice再到后端pod

参考
https://kubernetes.io/docs/concepts/services-networking/service/#type-loadbalancer
https://kubernetes.io/docs/concepts/services-networking/service/
https://kubernetes.io/docs/concepts/services-networking/ingress/

简单一点来说，就是内部服务的动态发现、负载均衡、高可用和外部访问的路由；
通过service，解耦动态变化的IP地址，POD可以随意关停，IP可以任意变，只要DNS正常，服务访问不受影响，但是这里面你的随时保证有个可用的POD,这个时候你就得需要LB了，或者说LB干的就是这个事情。
内部服务之间访问通过service解决了，那么外部访问集群内服务，则通过router即是解决，外网访问要不要负载均衡，大规模高并发情况下是肯定的，当然，外部负载均衡通常需要用户自己搞定了，F5或者开源的HAproxy都行！