POD 访问层面，采用流表重定向对应service的流量到控制器，控制器采用最少使用原则选择后端，选择好后固定下发SNAT，DNAT流表
cookie=0x1c, duration=526621.511s, table=3, n_packets=6, n_bytes=396, priority=10,tcp,nw_dst=10.254.0.1 actions=CONTROLLER:65535
cookie=0x1f, duration=526621.511s, table=3, n_packets=0, n_bytes=0, priority=10,tcp,nw_dst=10.254.193.232 actions=CONTROLLER:65535

HOST PORT 层面，采用 hostProxy iptables 实现 与 kube-proxy iptables模式相同

service dns 采用上面的nameServer进行注入

一定要：

1. 一定要定义 readiness 保证服务在准备好时，再接收流量

2. 增加一个言简意赅的endpoint，使用 httpGet 检查

3. 检查一定要是最直接的处理业务的endpoint，而非管理等endpoint

4. 服务一定要准备好时，endpoint才返回200，加载数据，预热等阶段可以返回503

一定不要：

1. liveness 不要依赖外部服务，否则外部服务问题，会使容器重建

2. 不要使用相同的 liveness 和 readiness , 如果使用了相同的，那么liveness
   的判定时间一定要比 readiness 长

3. 不要使用 exec probes 探测模式 （k8s对错误的exec command 和 超时都
   认为是无效的执行，忽略对结果的影响，
   而在http，tcp probe 的处理上都认为是failed 的探测，所以 exec 在面对
   command 错误，僵尸进程，死锁进程等超时响应情况时，不能正确反应POD状态）

所以最好定义 liveness 只探测服务是不是死锁，僵尸等，重启解决不可能恢复的局面
定义 readiness 检查服务能提供正常服务所需的依赖，任何一个必须的依赖无法
正常的提供服务，服务就需要下线，等待依赖恢复在上线

whoami-65c4d6d77-2s6xg                 1/1     Running       0          13m     10.190.12.11     10.190.0.44   <none>           <none>
whoami-65c4d6d77-f6xtt                 1/1     Running       0          13m     10.190.11.10     10.190.0.34   <none>           <none>
gaopeiliang@hk5-test-k8s-master-001:~/test_service$ kubectl get node
NAME          STATUS                        ROLES    AGE   VERSION
10.190.0.27   NotReady                      <none>   32d   v1.14.3
10.190.0.33   Ready                         <none>   32d   v1.14.3
10.190.0.34   NotReady                      <none>   32d   v1.14.3
10.190.0.38   Ready                         <none>   32d   v1.14.3
10.190.0.44   Ready                         <none>   32d   v1.14.3
10.190.0.46   NotReady                      <none>   32d   v1.14.3
10.190.0.47   Ready                         <none>   32d   v1.14.3

在 node 变成 not ready 时，POD的状态 一直处于ready状态，这时service是否该摘除这个endpoint那？ 驱逐中间这段时间，应用可能是无法工作的。。。。

1. 流表拦截所有的ARP请求到controller
2. 内部对外的ARP请求，在所有endpoint中寻找目的Mac，进行代答
3. 目的未在endpoints中的转发到uplink
4. 控制器失效后节点所有POD故障
5. uplink 来的arp请求怎么处理？

k8s 的 Services 通过 kube-proxy 组件处理，只能在集群内部访问，如果想在外部访问，只能通过NodePort和load balancer， calico 通过BGP将 Services CIDR广播出去，通过 ECMP 达到负载的效果，同时使用local services 还能防止SNAT丢失原IP

采用流表发送所有的DNS query 到控制器
cookie=0x13, duration=526621.968s, table=0, n_packets=6, n_bytes=528, priority=100,udp,dl_src=02:02:00:00:00:00/ff:ff:00:00:00:00,tp_dst=53 actions=CONTROLLER:65535

控制器在本地维护的nameServer进行查找，直接代答或者再走正常的查询流程
cookie=0x14, duration=526621.968s, table=0, n_packets=6, n_bytes=552, priority=101,udp,dl_vlan=4093,dl_src=02:02:00:00:00:00/ff:ff:00:00:00:00,tp_dst=53 actions=pop_vlan,goto_table:1

多集群，多calico网络，IPIP模式 ==>> 怎么使两个网络能相互通信那？？