已经分析过了deployment controller, replicaset controller的具体实现逻辑,最近抽时间看了看statefulset controller的内部实现机制，目标是将kube-controller-manager的主要资源控制器的实现机制都深入的了解下。
最近抽些时间看了下kube-apiserver的源码,主要先分析了服务的启动流程及API的安装部分，对于apisever与etcd的交互以及编码部分留作后续在分析。
Q1: 为什么需要对容器的资源进行可视化隔离？
A1: 容器技术提供了不同于传统虚拟机技术的环境隔离方式。通常的Linux容器对容器打包和启动进行了加速，但也降低了容器的隔离强度。其中Linux容器最为知名的问题就是资源视图隔离问题。
client-go package包含了许多的机制来方便开发者去开发自定义的controllers。之前基于该包实现过收集日志控制器log-controller，负载均衡控制器lb-controller以及收集k8s事件并写入相应的sink的eventrouter等，但是在使用的过程中对client-go内部的实现机制细节，一直比较模糊，所以抽时间分析下client-go的内部机制，在这里做下记录。
在Kubernetes 1.13版本以后(包含1.13),Kubernetes便指定了CoreDNS作为默认的服务发现机制(之前默认的版本是Kube-DNS)，由于项目中也需要使用CoreDNS对Service进行DNS解析，所以在使用CoreDNS的过程，便深入的看下CoreDNS的源码，已对其内部的实现机制有所了解。
最近在调研CoreDNS如何为Kubernetes集群内的Service提供DNS服务发现。但是在开始CoreDNS之前，需要对DNS的基础知识有所了解，本篇主要对DNS的学习过程做下记录。
kube-proxy当前支持三种方式实现负载均衡，分别是: userspace, Iptables, IPVS. 但前两者随着Service的数量增长，存在性能的瓶颈，在生产环境是不能接受的。所以本篇文章主要对IPVS模式进行源码分析。
代码版本: release-1.15
Kubernetes Serivce是一组具有相同label Pod集合的抽象(可以简单的理解为集群内的LB)，集群内外的各个服务可以通过Service进行互相通信。但是Service的类型有多种，每种类型的Service适合怎样的场景以及kube-proxy是如何实现Service负载均衡的将是本文讨论的重点。