clusterIP作为k8s中的服务，
也是其他三个服务的基础
~]$ kubectl create service
clusterip externalname loadbalancer nodeport 
客户端的流量到service
service分发给pod，pod由控制器自动部署，自动维护
那么问题是service的可用性如何保证？
这里以clusterip这个服务举例。
clusterip作为流量的分发者，如果保证自身的高可用？
clusterip是一个虚拟服务
用户访问clusterip的流量
被分配到后端的pod
那么clusterip服务的稳定性如何保证呢？
用kube-proxy保证
kube-proxy调用ipvs内核
实现流量在内核级别的四层负载均衡
clusterip是kube-proxy调用ipvs模块虚拟出来的一个服务器
所以kube-proxy可用性ok
那么clusterip服务的可用性就ok
那么kube-proxy的高可用如何保证呢？
kube-proxy是以pod的形态存在
每个物理节点都有一个kube-proxy的pod
如果某个节点上的kube-proxy休息了
那么控制器就会自动在该节点新建一个kube-proxy的pod
那么在这个新建的过程中，哪怕只有1秒钟
会影响集群的流量分发吗
由于k8s集群的实际负责计算的pod是分布式的在多个节点上的
所以单个节点的kubeproxy的pod掉线
其他节点照常可以负责其他节点的流量分发和计算
不太影响整个集群
但是对于单个节点的流量分发会有少量影响的
但是这个影响对于整体服务来讲
是比较小的。
总之单个节点的kube-proxy的pod掉线小几秒
属于正常波动
而且这种情况发生的概率不大
为什么？
因为kubeproxy的pod不是管理员手工去管理的
kubeproxy的pod，由控制器daemonset来批量部署和维护
当一个节点上的kubeproxy的pod掉线了
daemonset控制器会立马用镜像重建一个新的kubeproxy的pod
仍旧是每个节点上一个kubeproxy的pod
所以，kubeproxy的高可用性由daemonset控制器来保证
那么daemonset控制器的可用性用什么保证呢？
用kube-controller-manager
控制器管理器
控制器管理器会监控着这些控制器
包括daemonset
同时，
prometheus监控着集群的各个组件
包括daemonset控制器
监控界面通过grafana展现
同时prometheus设置alertmanager告警系统
如果集群有组件故障
alertmanager通知管理员
并且可以提前设计预案
alertmanager告警之后
自动执行故障相应系统，以及特定的脚本。
那么prometheus的可用性怎么保证呢？
可以配置冗余
由管理员负责
管理员的管理工作的可用性怎么保证呢？
通过企业对于系统管理的审计
说白了，由部门领导管理
那么部门领导的工作的可用性怎么保证呢？
由公司副总管理
公司副总的工作的可用性怎么保证呢？
由公司老板管理
那么公司老板的监管工作的可用性怎么保证呢？
不用保证。
因为公司技术运营的好，老板多赚
公司技术运营监管的一般，老板少赚点而已
所以
技术到这一层就不用监管了
已经到达权益的主要所有者了
少赚还是多赚，老板自己看着办就行了。
clusterip到光、电、半导体的链路是怎样的？
clusterip把流量分发给pod
pod把任务交给容器
容器里面的进程找操作系统
说，帮我弄个这，帮我干个那
去找cpu干活
cpu拿到各种0和1
一顿操作
通过操作系统和主板上的半导体材料
和本机的各个硬件交互
通过网络和本机之外的资源交互
cpu说，跟硬件打交道的活
就交给cpu吧
应用层等消息就行。
这就实现了从clusterip到光通信、电路板、半导体材料的链路
然后再从物理层响应至应用层
实现服务的可用性。