1、由google公司开发，google有10年容器化基础架构经验，自身的borg容器在公司内部使用，对外开源的是kubernetes，由go语言开发，基于http协议的c/s架构，是一种资源管理器
2、特点
（1）go语言为静态编译性语言，因此k8s特点之一轻量级：消耗资源小
（2）开源
（3）弹性伸缩
（4）负载均衡：ipvs
1、k8s架构
2、master节点
（1）scheduler：任务发起角色，选择合适的节点进行分配任务，它将任务交给api server，api server将请求写入etcd，它并不会与etcd直接交互
（2）replication controller manager：rc，副本管理器，根据设置的pod数，使整个k8s一直保持这个pod数
（3）api server：一切服务访问的入口，为避免api server过于繁忙，各服务组件在本地生成一定的缓存，同样的访问需求读取缓存
（4）etcd：键值对数据库，存储k8s的参数信息，是一种可信赖的分布式存储服务，有自己的集群化方案，扩容方便，实现了k8s整个框架的持久化方案。v2将数据写入内存，v3会将数据写入磁盘，类似于redis，k8s v1.11已经弃用v2，对于仍在使用v2版的etcd，需要注意备份操作
etcd结构图
<2>etcd基于http协议
<3>raft：存放etcd的读写信息
<4>wal：预写日志，当对数据产生更改，产生日志放入entry进行存储记录，并且利用snapshot对这些日志定时的进行完整备份
<5>store：raft会将数据以及日志，实时的写入本地磁盘store，进行持久化设置
3、node节点
（1）container：容器，现大多数使用docker作为容器平台
（2）kubelet：会与docker进行交互，操作docker创建对应的容器，维持pod生命周期
（3）kube proxy：负责写入规则至iptables或者ipvs，实现服务映射访问
4、其他插件
（1）coredns：为急群众的svc创建一个域名-ip的对应关系解析
（2）dashboard：给k8s集群提供一个b/s结构访问体系
（3）ingress controller：官方只能实现四层代理，ingress可以实现七层代理
（4）fedetation：提供一个可以跨集群中心多k8s统一管理功能
（5）prometheus：提供一个k8s集群的监控能力
（6）elk：提供k8s集群日志统一分析介入平台
5、高可用集群副本数据最好是>=3奇数个
6、有状态服务和无状态服务
（1）有状态服务：需要数据存储功能的服务、或者指多线程类型的服务，队列等，每个实例都需要自己独立的持久化存储，比如说mysql数据库
（2）无状态服务：是指该服务运行的实例不会在本地存储需要持久化的数据，并且多个实例对于同一个请求响应的结果是完全一致的。多个实例可以共享相同的持久化数据，例如nginx、tomcat
1、pod分为两种：
自主式pod：不被控制器管理的pod，pod挂掉后不会被重启
控制器管理的pod
2、同一个pod中，容器之间的端口不能冲突，它们既共用同一个网络栈，又共享同一个存储卷
3、pod控制器类型
（1）replicationcontroller、replicaset、deployment、hpa，前三种控制器具有一定组合性而放在一起，hpa仅适用于replicaset和deployment
<1>replicationcontroller：rc，用来确保容器应用的副本数，始终保持在用户定义的副本数，如果有容器异常退出，会自动创建新的pod来替代，如果异常多出来的容器也会自动回收，在新版本的k8s中建议使用replicaset来取代该项
<2>replicaset：rs，与replicationcontroller没有本质不同，只是名字不一样，并且replicaset支持集合式的selector，新版本中已经抛弃了rc
<3>deployment：一般建议用deployment自动管理replicaset，这样无需担心跟其他机制的不兼容问题，比如rs不支持rolling-update滚动更新，但deployment支持。本项不支持pod创建，但它可以定义rs
滚动更新：假设deployment下有个rs，rs下有3个pod，需要将pod中的内容进行更新
现在开始更新，在deployment下会生成一个新的rs
由于我们设置一共有3个pod，所以升级的过程是rs1去掉一个v1，在rs2处新加一个v2，保持总数不变
以此类推，最后所有pod升级完成
<4>hpa：horizontal pod auto scal，在v1版本中仅支持根据pod的cpu利用率扩缩容，即根据cpu使用率的多少，增加或减少容器，个数不会超过最大最小值。在valpha版本中，支持根据内存和用户自定义的阈值扩缩容。
（2）statefulset：是为了解决有状态服务的问题，是对应deployment和replicasets的无状态服务而设计
<1>稳定的持久化存储，即pod重新调度后还是能访问到相同的持久化数据，基于pvc来实现
<2>稳定的网络标志，即pod重新调度后，podname和hostname都不变，基于headless service来实现
<3>有序部署，有序扩展，即pod是有顺序的，在部署或者扩展的时候要根据定义的顺序依次进行，即从0到最后一个，在下一个pod运行之前的所有pod，都必须是running和ready状态，基于init containers来实现
<4>有序收缩，有序删除，即从倒数第一个到0
（3）daemonset：确保全部或者部分node上运行一个pod的副本。当有node加入集群时，也会为他们新增一个pod；当有node从集群移除时，这些pod也会被回收。删除daemonset将会删除它所创建的所有pod。典型用在每个node上运行日志收集daemon，比如说logstash，或者在每个node上运行监控daemon，比如和prometheus node exporter
（4）job，cronjob
<1>job负责批处理任务，即仅执行一次的任务，它保证批处理任务的一个或多个pod成功结束
<2>cron job管理基于时间的job，即在给定时间点只运行一次、周期性地在给定时间点运行
4、服务发现
（1）当客户端访问一组pod时，即该组pod提供的是同样的服务，即被同一个deployment创建，或者拥有同一组标签，才会被这个service选到。选到以后该service拥有自己的ip和端口，此时客户端便可以通过访问这个service的ip和端口，间接地访问到这些pod，并存在rr轮循调度算法
（2）pod与pod之间的访问，可以通过访问service方式，或者ingress
1、k8s的网络模型假定了所有pod都在一个可以直接连通的扁平网络空间中，也就是说，所有的pod之间都可以依靠ip到达。但如果在私有云里搭建k8s集群，需要实现这个连通的网络空间，将不同节点上的docker容器之间的互相访问先打通，然后再运行k8s
2、通讯方式
（1）同一个pod内的多个容器之间：lo
（2）各pod之间的通讯：flanneloverlay network，覆盖网络
<1>在同一台主机上，由docker0网桥直接转发请求即可，不需要经过
<2>不在同一台主机上，pod的地址是与docker0在同一个网段的，但docker0网段与宿主机网卡是两个完全不同的ip网段，并且不同node之间的统信只能通过宿主机的物理网卡进行，将pod的ip和所在node的ip关联起来，通过这个关联可以互相访问
（3）pod与service之间的通讯：各节点的iptables规则、lvs
（4）pod到外网：pod向外网发送请求，查找路由表，转发数据包到宿主机网卡，宿主机网卡完成路由选择后，iptables执行masquerade，把源ip更改为宿主机网卡的ip，然后向外网发送请求
（5）外网访问pod：service
3、网络解决方案：k8s+flannel，不同主机pod之间的访问过程
（1）flannel：让集群中的不同节点主机创建的docker容器都具有全集群唯一的虚拟ip地址，而且它还能在这些ip地址之间建立一个覆盖网络(overlay network)，通过这个覆盖网络，将数据包原封不懂地传递到目标容器内
（2）不同主机pod之间访问过程说明：
<1>图中若web app2访问web app1，可以直接走docker0网卡即可，即走了pod内的docker之间访问使用lo方式
<2>图中若web app2访问backend，首先自身ip地址10.1.15.2/24经过docker0，进入flannel0，flanneld中有etcd配置的路由表信息，之后对数据包进行封装：
mac
pod源ip，pod目标ip(图中destination有错)
利用udp协议在内部局域网更快的特性
源容器的ip和目标容器的ip
数据包实体
进入目标pod后，flanneld会拆封数据包，将请求转发到flannel0，flannel0再转发到docker0，之后进入backend。
（3）etcd与flannel提供的说明
<1>存储管理flannel可分配的ip地址段资源，避免ip冲突
<2>监控etcd中每个pod的实际地址，并在内存中建立维护pod节点路由表
3、k8s有3层网络，分别是service网络、pod网络和节点网络
真实的物理网络为节点网络，service网络和pod网络为虚拟网络
节点网络：构造k8s需要一张物理网络就可以