k8s 内部各个部件运转

Master节点部署的都是kubernetes的核心模块
APIServer
提供资源操作的唯一入口，并且提供认证/授权/kubernets的访问控制
可以通过kubectl和自己开发的客户端，通过http的请求通过restapi的形式来访问apiserver，从而实现对整个集群的控制

ControllerManager
负责维护整个集群的状态，如，故障检测/扩缩容/滚动更新等

Scheduler
负责资源的调度，按照预定的调度策略，把pod调度到相应的node节点
K8s有丰富的调度策略

Etcd
主要用于一致性存储，保存pod/service和集群的状态等信息
相当于k8s集群需要持久化的数据都会存储在etcd

Kube-dns
负责整个集群的dns服务，但并不是必须的，若不需要通过名字来访问，可以不安装kube-dns，但通常会安装，因为通过名字访问是一个比较重要的功能

Node节点的服务
Kubelet
维护当前节点的容器的生命周期，维护当前节点的volume/网络等的管理

Kube-proxy
每个node都会运行一个kube-proxy，提供内部的服务发现和负载均衡，为service的概念提供一个落地的方法

Kube-dns
负责整个集群的dns服务，但并不是必须的，若不需要通过名字来访问，可以不安装kube-dns，但通常会安装，因为通过名字访问是一个比较重要的功能

Dashboard
提供一个集群相关数据展示和操作的ui界面

整体访问流程
用户执行kubectl/userClient向apiserver发起一个命令，经过认证授权后，经过scheduler的各种策略，得到一个目标node，然后告诉apiserver，apiserver 会请求相关node的kubelet，通过kubelet把pod运行起来，apiserver还会将pod的信息保存在etcd；pod运行起来后，controllermanager就会负责管理pod的状态，如，若pod挂了，controllermanager就会重新创建一个一样的pod，或者像扩缩容等；pod有一个独立的ip地址，但pod的IP是易变的，如异常重启，或服务升级的时候，IP都会变，这就有了service；完成service工作的具体模块是kube-proxy；在每个node上都会有一个kube-proxy，在任何一个节点上访问一个service的虚拟ip，都可以访问到pod；service的IP可以在集群内部访问到，在集群外呢？service可以把服务端口暴露在当前的node上，外面的请求直接访问到node上的端口就可以访问到service了；

----------------------------------------------------------------------------------------------------------------------
以上部分是来至网络比较官方的介绍。 一下是本人的理解。
开放端口 : 
API Server  6443/8080
Controller 10252
Scheduler 10251
Etcd 2379/2380

api server 作为统一接收指令，并实现调度服务。  接收kubelet, kubectl 和 http api 的指令。 
api server 把资源调度的任务分配给  Controller / Scheduler 进行执行， 其实际具体执行pod任务，应该是 node 上的 kubelet
Controller ， Scheduler， kubelet ， api server 四者把任务和数据统一到 ETCD 进行，保证数据的一致性。

Kube-proxy 作为 node 的网络代理， 执行 svc 的网络映射命令
Kube-dns     负责把 ip  与 name 对应起来， 方便管理