https://blog.csdn.net/xingwangc2014/article/details/51254265
很多人刚接触到kubernetes时可能并不是清楚kubernetes集群的组成，文章参考官方文档，首先从k8s集群的一些基本组成讲起，确保读者有对集群，集群各个组件之间的关系有一个基本了解。然后再讲解k8s的手动，自动化部署。
本文结合kubernetes架构图，简要的的介绍了kubernetes的组件，以及各个组件之间的关系。
kubernetes是一个为跨主机管理容器化应用而设计的系统，kubernetes提供了多节点资源管理、监控的功能，同时还提供了针对容器的部署，管理、扩容的功能。kubernetes是一个典型的Paas平台。kubernetes主要针对的是容器化应用系统，虽然目前提到的容器主流是Docker，但是kubernetes对容器的支持不仅仅限于docker。kubernetes为了能保证集群中业务的正常运行，提供了针对被管理的容器的强大的自愈能力。如自动重启，重新调度，容器迁移，基于活跃的controller复制容器等机制。
kubernetes设计首先针对的是多容器的应用，如弹性的、分布式的微服务架构应用。同时它被设计用于促进一些非容器化的应用在迁移到kubernetes中来。这样就既能包括对松耦合容器，又能包括对紧耦合容器的抽象，以提供相似的容器发现和通信机制。这个可能有点抽象，后面了解了kubernetes的pod，service等概念后，可能就能慢慢理解其中的一些门道了。
kubernetes还能自动收集、管理集群资源，通过多种资源分配、管理机制提供对容器的资源隔离、限制等。kubernetes调度器能够根据容器的资源设置自动选择、并将容器调度到合适的节点上。当节点上发生资源竞争、资源过多使用时，kubernetes集群也能根据该节点上运行的容器对资源设定的等级优先迁移一些低等级的容器来释放资源优先满足高等级容器的使用。
kubernetes为了保证集群的高可用性，还提供了多master的HA方式，保证在有master节点宕机是，还有standby的节点能够自动顶上来继续承担master的职责，维护集群功能正常。
下图所示就是kubernetes集群的架构图：
如上面架构图所示，master节点上主要有kube-Apiserver，kube-scheduler，kube-controller-manager。另外kubernetes集群后端存储使用高可用的键/值存储系统etcd，etcd也可以是一个分布式集群，可以同master节点一同部署，也可以分别部署，在此同master节点一同介绍。
API Server是Master Server上的一个最重要的服务。API Server是整个集群的主管理节点，通过它用户可以配置Kubernetes的负载和组织单元。它还负责确保etcd存储和服务的细节同部署的容器保持一致。
API Server实现了一套RESTfull的接口。一个kubecfg客户端随Server-side工具集打包，可以在local computer或连接到master server使用。
Controller Manager Service被用于处理Replication Tasks定义的Replication process。那些操作的细节都被写到etcd中，Controller Manager监控etcd中的改动。当发现改动，Controller Manager读取新的信息并实现满足期望的Replication procedure。这可以实现应用程序的扩展和收缩。
Schedule Server负责分配工作负载到集群中某个指定的节点。它读取一个Service的操作需求，分析当前infrastructure环境，然后将work安排到一个合适的节点或多个节点。Scheduler还负责追踪没一个节点中的资源利用情况，并确保工作负载不会在超出可用资源的情况下被分配。Scheduler必须知道每个节点上的可用资源，以及每个节点上已经分配已经分配给已经存在的工作负载的资源。
Kubernetes需要提供的一个基本功能就是全局范围内的配置存储。etcd是由CoreOS开发的一个轻量级的，分布式的键-值存储系统，可以分步在不同的节点上。
Kubernetes使用etcd存储可以被集群每一个节点使用的配置数据。etcd中存储的数据可以被用于服务发现和存储每个component可以应用来进行配置的集群状态表示。Etcd提供了一个简单HTTP/JSON API可以用于设置和检索。
Kubernetes中etcd的实现比CoreOS中更加灵活，你可以选择关闭除了Master上的所有etcd。因为master server必须起来以保证Kubernetes的功能，分布式存储的值则不是必须的。
另外如果需要在集群中运行一些以容器运行的类似于插件的辅助功能的addons，如DNS，监控，日志收集等还需要在master上运行一个kube-addons.sh的daemon创建namespace并定时检查kubernetes目录下addons目录下是否有新的未被创建的addon resource。
如果需要把master节点也当做集群的一个工作节点被调度执行容器，master上也需要安装minion 节点需要安装的组件。
使用不同的网络方案，还需要安装不同的网络组件，如flanneld，openvswitch等
minion节点的主要功能是调度容器，收集节点资源、以及管理容器资源使用情况，并为容器提供代理功能等。节点上集群相关的组件主要有kubelet，kube-proxy，另外要能运行容器，必不可少的还需要安装容器 daemon，如docker。
Docker用于在一个相对隔离的，轻量级的环境中运行一个封装应用的容器。
集群中，每个minion Server之间主要的contact point是kubelet Service。kubelet Service负责从master接收信息，同时也负责向master发送信息。另外还负责与etcd交互读写配置信息(实际为通过Apiserver进行）。
kubelet从master接收命令和工作。Work以’manifest’的形式接收，manifest定义了工作负载和操作参数。然后Kubelet承担了在minion Server上维护工作状态的职责。
架构图中所示，kubelet还与CAdvisor交互，CAdvisor是一个容器监控工具，能够收集容器的CPU，memory等的使用情况，在比较新的k8s中，CAdvisor已经被集成到kubelet中。
为了应付单个主机的子网和可以对外提供服务，每一个minion Server上都运行了一个小的Proxy Server。Proxy负责转发请求到正确的容器，能做基本的负载均衡，且通常负责确保网络环境和可预测的，可访问的，但又是隔离的。
kube-proxy会通过apiserver从etcd中获取集群信息，如果发现有新的service加入，或更新，则会获取最新的信息。并为service到容器建立相应的iptables规则，实现将请求直接转发到相应的容器。kube-proxy提供两种代理模式，一种是userspace模式，一种是iptables模式。1.2之前默认使用userspace模式，1.2之后默认使用iptables模式。iptables模式中，连接请求直接通过iptables规则转发到容器，不在经过proxy代理，具有更高的效率。后续另开一文详细分析k8s的网络。
本文简要介绍了kubernetes集群的各个组件，以及各个组件的作用，让读者对kubernetes有一个简单的概念。下一篇文章将介绍kubernetes集群主要resource的概念，即作用。后续会进一步介绍kubernetes集群的网络方案，并结合网络方案介绍集群各个组件的详细关系等。
kubernetes architecture：https://github.com/kubernetes/kubernetes/blob/master/docs/design/architecture.md
