k8s基础概念

K8S介绍

k8s, 全称Kubernetes，是一个全新的基于容器技术的分布式架构领先方案，是谷歌大规模应用容器技术的经验积累和升华的成果。

Master

	k8s集群由众多的节点构成，Master节点指集群控制节点，通常占据一个独立的服务器或者一个虚拟机，每个集群需要一个Master节点来负责整个集群的管理和控制，基本上kubernetes所有的命令都是发给它的。且Master节点运行着一组关键的进程。

Kubernetes API Server

提供了HTTP Rest接口的关键服务进程，是集群资源的增 删 改 查等操作的唯一入口，也是集群控制的入口进程。

####Kubernetes Controller Manager

Kubernetes里所有资源的自动化控制中心

Kubernetes Scheduler

负责资源调度（Pod调度）的进程，相当于公交公司的调度室

etcd

高可用，分布式键值数据库，基于go语言实现，专门为集群环境而设计，可以很好的实现数据一致性，提供集群节点状态管理和服务自动发现等。

特点：

1. 简单，支持REST风格的HTTP+JSON API
2. 安全，支持HTTPS方式的访问
3. 快速，支持并发每秒1000次的写操作
4. 可靠， 支持分布式结构，基于Raft算法实现一致性

Node

	 除了Master，Kubernetes集群中的其他机器被称为Node节点，该节点可以时一台物理主机或者虚拟机，
 是Kuberbetes集群当中的工作负载节点，每个Node会被Master分配一些工作负载，当某一个Node宕机时，
 其上的工作负载会被Master自动转移到其他节点上。

关键进程

kubelet

负责Pod对应的容器的创建，启动， 停止等任务，同时与Master节点密切协作，实现集群管理的基本功能

kube-proxy

实现Kubernetes Service的通信与负载均衡机制的重要组件，智能的软件负载均衡器。

Docker Engine(docker)

Docker引擎，负责本机的容器创建和管理工作

Node节点在运行期间可以动态的增加到Kubernetes集群中，前提是这个节点已经正确安装，配置和启动了上述关键进程，
默认情况下，kubelet会向Master节点注册自己，（Kubernetes集群推荐的管理方式），一旦Node节点被纳入集群管理范围，
kubelet进程就会定时向Master节点汇报自身的情况，例如操作系统，Dokcer版本，机器的CPU和内存情况，以及之前有哪些Pod在运行，
这样Master可以获知每个Node的资源使用情况，并实现高效均衡的资源调度策略。Node超时不上报信息，则认为该Node失去联系，
被标记为不可用，随后Master触发工作负载转移的自动流程。

Pod（容器组）

每个Pod都有一个特殊的被称为"根容器"的Pause容器，还包含一个或者多个紧密相关的用户业务容器。

为什么Kubernetes会设计一个全新的Pod的概念并且Pod会有这样的特殊的组成结构？

1. 一个容器作为一个单元的情况下，难以对整体简单的继续宁判断及有效的进行行动，比如容器死亡时，无法判断是否整体死亡，引入与业务无关的Pause容器来代表整个容器组（即Pod）的状态
   

2. Pod的多个业务容器共享Pause容器的IP和挂载的Volume，解决业务容器之间的通信问题和文件共享的问题
   

   Kubernetes为每个Pod分配一个唯一的IP地址，称为Pod IP，Pod当中的多个容器共享该IP，Kubernetes要求底层网络支持集群内的任意两个Pod之间的TCP/IP直接通信，通常采用虚拟二层网络技术来实现

   	Pod有两种类型，普通的Pod和静态的Pod，后者不在etcd当中存储，而是存放在某个具体的Node上的一个具体文件中，
   只在该Node上启动运行。
   	普通的Pod创建之后，放入etcd中存储，随后被Master节点调度到某个具体的Node上并进行帮定，随后该Pod被对应的Node上的kubelet进程实例化成一组相关的Docker容器，并启动起来。如果Pod当中的某个容器停止，Kubernetes会检测到这个问题，并重新启动这个Pod，如果Pod所在Node宕机，则会将这个Node上的所有Pod重新调度到其他节点上。
   

Label（标签）

	一个label是一个key=value的键值对，起到分类资源对象的作用，其中key和value用户自己指定，Label可以附加到各种资源上，
如Node，Pod，RC，Service，一个资源独享可以定义任意数量的Label，一个Label也可以添加到任意数量的资源上
	给某个资源对象打上标签，随后可以通过Label Selector查询和筛选资源对象，类似于SQL语句的where条件查询

与之类似的是注解（Annoattion），但不分类资源对象，只是给对象丰富的描述信息
####Label Selector使用场景####

1. kube-controller 进程通过资源对象RC上定义的Label Selector来筛选要监控的Pod副本的数量，从而实现Pod副本的数量，从而实现Pod副本数量始终符合预期设定的全自动控制流程
2. kube-proxy进程通过Service的Label Selector来选择对应的Pod，自动建立起每个Service到对应的Pod的请求转发路由，从而实现Service的智能负载均衡机制
3. 通过定义的Label，在Pod定义文件中使用NodeSelector的标签调度策略，kube-scheduler可以实现Pod的定向调度

Replication Controller（复制控制器）

	定义了一个期望场景，声明某种Pod的副本数量在任一时刻都符合某个预期值，负责启动Pod，并维护其健康的运行状态，
所以RC的定义主要包括：

1. Pod期待的副本数
2. 用于筛选目标Pod的Label Selector
3. 当Pod副本的数量小于预期值的时候用于创建Pod的Pod模板

Deployment（部署）

	在Kubernetes 1.2当中提出的新概念，相当于对RC的升级。
	创建Pod可根据参数自动创建管理Pod的复制控制器， 并且支持升级
	相对与RC，最大的升级就是可以知道当前Pod部署的进度

##Horizontal Pod Autoscaler(HPA 横向Pod扩展器)##

 	Pod横向自动扩容，通过追踪分析RC控制的所有目标Pod的负载变化情况，来确定是否需要针对性的调整目标
 Pod的副本数目，这是HPA的实现原理，HPA衡量Pod负载的方式，

1. CPUUtilizationPercentage， 目标Pod所有副本自身的CPU利用率的平均值，一般采用Heapster组件（未来计划自身实现一个基础性能数据采集模块）
2. 应用程序自定义的指标，如服务每秒的请求数（TPS或者QPS）

Service（服务）

	Lubernetes里的每个service是微服务架构中的一个微服务，通过分析 识别并建模系统中的所有服务为微服务——Kubernetes 
Service，最终系统由多个提供不同业务能力而又彼此独立的微服务单元所组成，服务之间通过TCP/IPi进行通信,可以将服务
理解为若干Pod形成的对外提供某个功能的抽象，不随Pod的改变而改变，带有唯一的固定的访问路径，如ip或者域名。
	服务的提出解决了Pod  IP地址可变的问题，由于Pod随时可能故障，并在其他节点被重启，它的地址不能保持固定。因此用一个服务来
代表提供某一类功能（通过Label Selector来筛选）的Pod，并分配不随Pod位置变化而改变的虚拟访问地址，符合微服务的理念。

####Kubernetes的服务发现机制####

	任何的分布式系统都会涉及到服务发现机制，大部分分布式系统通过提供特定的API接口来实现服务发现的功能，但这样做导
致平台入侵性比较强，也增加了开发测试的困难。
	Kubernetes当中，每个服务都有一个唯一的Cluster IP(虚拟IP)以及唯一的名字，名字是由开发者自己定义的，部署的时候不会
改变，可完全固定在配置当中，接下来就是如何通过Service的名字找到对应的Cluster IP？
	最开始使用环境变量，即在启动每个pod的时候，自动注入一些环境变量不太方便，不够直观。
	后Kubernetes通过Add-On增值包的方式引入了DNS系统，把服务名作为DNS域名，这样程序可直接使用服务名来建立通信连接。

外部系统访问Service的问题

区分三种IP

1. Node IP 集群节点的物理ip，集群外访问集群内使用该IP

2. Pod IP 基于虚拟二层网络，位于不同Node上的Pod彼此直接通信，依赖该地址

3. Cluster IP 仅作用与Service对象，虚拟IP，由kubernetes管理和分配， 无法被ping，只能结合Service Port组成一个具体的通信端口，属于kubernetes集群封闭空间内

   NodePort解决外部无法访问Service的问题，但是无法解决负载均衡问题；
   引入负载均衡器（Load balancer），外部网络访问负载均衡器的IP地址，负载均衡器负责转发流量到后面的某个Node的NodePort上
   

负载均衡器（Load balancer）

	该组件独立于Kubernetes集群之外，通常是一个硬件的负载均衡器或者是以软件方式实现的，例如HAProxy或者Nginx；
对于每个服务，我们通常需要配置一个对应的负载均衡器实例来转发流量到Node节点，Kubernetes提供了自动化的解决方案，
将Service的type=NodePort改为type=LoadBalancer,此时kubernetes会自动创建Service的负载均衡器实例并返回它的IP地址供
外部客户端使用（谷歌GCE公有云上），其他公有云只要提供了此特性的驱动，既可以实现该功能。