kubernetes（k8s）以及涉及组件简单介绍
什么是kubernetes？
Kubernetes是一个全新的基于容器技术的分布式架构领先方案。是Google内部集群管理系统Borg的一个开源版本。直到2015年4月，随着论文发布，才被众人熟知。Kubernetes是一个开放的开发平台。不局限于任何一种语言，没有限定任何编程接口。是一个完备的分布式系统支撑平台。它构建在docker之上，提供应用部署、维护、扩展机制等功能，利用Kubernetes能方便地管理跨机器运行容器化的应用。Kubernetes在大概两三周前，正式发布1.5版本。
主要功能体现在如下：
–使用Docker对应用程序包装、实例化
–以集群的方式运行、管理跨机器的容器
–解决Docker跨机器容器之间的通讯问题
–Kubernetes的自我修复机制使得容器集群总是运行在用户期望的状态
基本概念：
Kubernetes中的大部分概念Node、Pod、Replication Controller、Service等都可以看作一种“资源对象”，几乎所有的资源对象都可以通过kubectl工具（API调用）执行增、删、改、查等操作并将其保存在etcd中持久化存储。从这个角度来看，kubernetes其实是一个高度自动化的资源控制系统，通过跟踪对比etcd库里保存的“资源期望状态”与当前环境中的“实际资源状态”的差异来实现自动控制和自动纠错的高级功能。
Master：集群控制管理节点，所有的命令都经由master处理。
Node：是kubernetes集群的工作负载节点。Master为其分配工作，当某个Node宕机时，Master会将其工作负载自动转移到其他节点。
Node节点可动态增加到kubernetes集群中，前提是这个节点已经正确安装、配置和启动了上述的关键进程，默认情况下，kubelet会向Master注册自己，这也kubernetes推荐的Node管理方式。一旦Node被纳入集群管理范围，kubelet会定时向Master汇报自身的情况，以及之前有哪些Pod在运行等，这样Master可以获知每个Node的资源使用情况，并实现高效均衡的资源调度策略。如果Node没有按时上报信息，则会被Master判断为失联，Node状态会被标记为Not Ready，随后Master会触发工作负载转移流程。
Pod：是kubernetes最重要也是最基本的概念。每个Pod都会包含一个 “根容器”，还会包含一个或者多个紧密相连的业务容器。
Kubernetes为每个Pod都分配了唯一的IP地址，称之为PodIP，一个Pod里的多个容器共享PodIP地址。要求底层网络支持集群内任意两个Pod之间的直接通信，通常采用虚拟二层网络技术来实现（Flannel）。
Label：是一个key=value的键值对，其中key与value由用户自己指定。可以附加到各种资源对象上，一个资源对象可以定义任意数量的Label。可以通过
LabelSelector（标签选择器）查询和筛选资源对象。
RC：Replication Controller声明某个Pod的副本数在任意时刻都符合某个预期值。定义包含如下：
（1）Pod期待的副本数（replicas）
（2）用于筛选目标Pod的Label Selector
（3）当Pod副本数小于期望时，用于新的创建Pod的模板template
（4）通过改变RC里的Pod副本数量，可以实现Pod的扩容或缩容功能
（5）通过改变RC里Pod模板中的镜像版本，可以实现Pod的滚动升级功能
思考：如果Node2上的pod死掉怎么办？
Service：“微服务”，kubernetes中的核心。通过分析、识别并建模系统中的所有服务为微服务，最终系统有多个提供不同业务能力而又彼此独立的微服务单元所组成，服务之间通过TCP/IP进行通信。每个Pod都会被分配一个单独的IP地址，而且每个Pod都提供了一个独立的Endpoint以被客户端访问。
思考：客户端如何访问？
部署负载均衡器，为Pod开启对外服务端口，将Pod的Endpoint列表加入转发列表中，客户端通过负载均衡器的对外IP+Port来访问此服务。每个Service都有一个全局唯一的虚拟ClusterIP，这样每个服务就变成了具备唯一IP地址的“通信节点”，服务调用就变成了最基础的TCP网络通信问题。
Volume：是Pod中能够被多个容器访问的共享目录。定义在Pod之上，被一个Pod里的多个容器挂载到具体的文件目录之下；与Pod生命周期相同。
可以让一个Pod里的多个容器共享文件、让容器的数据写到宿主机的磁盘上或者写文件到 网络存储中，具体如下图所示：
在kubernetes1.2的时候，RC就由Replication Controller升级成Replica Set，“下一代RC”。命令兼容适用，Replica Set主要被Deployment这个更高层的资源对象所使用，从而形成一套Pod创建、删除、更新的编排机制。当我们使用Deployment时，无需关心它是如何创建和维护ReplicaSet的，这一切是自动发生的。
docker
既然k8s是基于容器的，那么就不得不提到docker。2013年初，docker横空出世，孕育着新思想的“容器”，Docker选择容器作为核心和基础，以容器为资源分割和调度的基本单位，封装整个软件运行时环境，为开发者和系统管理员设计，用于构建、发布和运行分布式应用的平台。是一个跨平台、可移植并且简单易用的容器解决方案。通过操作系统内核技术（namespaces、cgroups等）为容器提供资源隔离与安全保障。
上图是一个image的简单使用。我们可以通过一个dockerfile来build自己的image。可以把image上传（push）到自己的私有镜像仓库，也可以从私有仓库pull到本地进行使用。可以单独使用命令行，直接run container，可以对container进行stop、start、restart操作。也可以对image进行save保存操作以及加载load操作，大家具体可以根据自己的使用，选择不同的操作即可。
docker资源隔离技术
2013年初，docker横空出世，孕育着新思想的“容器”，Docker选择容器作为核心和基础，以容器为资源分割和调度的基本单位，封装整个软件运行时环境，为开发者和系统管理员设计，用于构建、发布和运行分布式应用的平台。是一个跨平台、可移植并且简单易用的容器解决方案。通过操作系统内核技术（namespaces、cgroups等）为容器提供资源隔离与安全保障。（关于这两种资源隔离技术，本人只能从功能上说明两者相当于就是分组，隔离，但是具体的内部原理还不甚了解，所以此处只提下概念，如皋想要深入了解，可搜集其他资料）
docker监控
cAdvisor（Container Advisor）是Google开发的用于分析运行中容器的资源占用和性能指标的开源工具。cAdvisor是一个运行时的守护进程，负责收集、聚合、处理和输出运行中容器的信息。对于每个容器，cAdvisor都有资源隔离参数、资源使用历史情况以及完整的历史资源使用和网络统计信息的柱状图。
cAdvisor不但可以为用户提供监控服务，还可以结合其他应用为用户提供良好的服务移植和定制。包括结合InfluxDB对数据进行存储，以及结合Grafana提供web控制台，自定义查询指标，并进行展示。
etcd
etcd是一个键值存储仓库，用于配置共享和服务发现。etcd受Zookeeper与doozer启发而催生的项目。
etcd架构
etcd存储
etcd的存储分为内部存储和持久化（硬盘）存储两部分。内存中的存储除了顺序化地记录所有用户对节点数据变更的记录外，还会对用户数据进行索引、建堆等方便查询的操作。而持久化则使用WAL进行记录存储。在k8s中，所有数据的存储以及操作记录都在etcd中进行存储，所以对于k8s集群来说，etcd是相当重要的，一旦故障，可能导致整个集群的瘫痪或者数据丢失。
在WAL体系中，所有的数据在提交之前都会进行日志记录。持久化存储的目录分为两个：snap和wal。snapshot相当于数据压缩，默认会将10000条wal操作记录merge成snapshot，节省存储，又保证数据不会丢失。
WAL：存储所有事务的变化记录
Snapshot：用于存放某一时刻etcd所有目录的数据
思考：数据损坏或者机器故障怎么办？？？
etcd核心算法
注意：由于etcd是负责存储，所以不建议搭建单点集群，如zookeeper一样，由于存在选举策略，所以一般推荐奇数个集群，如3，5，7。只要集群半数以上的结点存活，那么集群就可以正常运行，否则集群可能无法正常使用。
k8s集群部署方案
如下是我的集群部署策略，1个master + 2个node（minion1.2之前的叫法）。我的存储集群etcd是单点集群，不推荐此做法，你懂得，哈哈。网络使用的是flannel虚拟二次网络。
如何验证？
搭建完成之后，命令行执行：kubectl get no 查看节点状态是否ready。
其他的大家可以通过代码来进行验证，看是否可以成功访问各个服务以及成功运行。
ok，以上是我的初步总结，欢迎留言指导。
顺便吐槽下，个人觉得csdn真的太难用了，么有预览，还有格式排版好难用，看看我的上一篇格式都成啥了，唉，吐槽！！！