kubernetes简介html
kubernetes是用于管理多个机器上容器化应用的开源系统平台，它拥有一套容器应用部署、规划、更新、维护机制，让应用部署更简单高效。核心的特色就是可以自主的管理容器来保证云平台中的容器按照用户的指望状态运行。node
kubernetes集群基础概念mysql
Clusternginx
Cluster是网络、存储、计算各类资源的集合，k8s利用这些资源运行容器应用。
redisMastersql
Master是集群的管理中心，负责调度，决定将应用放置在哪里运行，能够同时运行多个master以保证高可用。
dockerNode后端
Node是集群的工做节点，负责运行容器应用，node由master管理，node负责监控并汇报容器的状态，同时根据master要求管理容器的生命周期。Node上运行着Kubelet、kube-proxy服务进程，这些服务进程负责Pod的建立、启动、监控、重启、销毁、以及实现软件模式的负载均衡。查看node，kubectl get node， kubectl describe nodeapi
Pod安全
pod是k8s的最小工做单元，每一个pod包含一个或者多个容器，一般状况下运行单一容器，也便是one-container-per-Pod模式；对于多个容器有紧密联系且须要共享资源的则使用多容器模式。
一个pod中的应用容器共享资源：Pod中的不一样应用程序能够看到其余应用程序的进程ID；Pod中的多个容器可以访问同一个IP和端口范围；Pod中的多个容器可以使用SystemV IPC或POSIX消息队列进行通讯；Pod中的多个容器共享一个主机名；Pod中的各个容器能够访问在Pod级别定义的Volumes；
Pod的生命周期经过Replication Controller来管理；经过模板进行定义，而后分配到一个Node上运行，在Pod所包含容器运行结束后，Pod结束。
Controller
k8s一般不会直接建立pod，它是经过controller来管理pod，k8s提供了多种controller，有Deployment、ReplicaSet、DaemonSet、StatefuleSet、job等。Deployment管理pod及其副本，并保证pod按照指望的状态运行；ReplicaSet管理多个副本，使用deployment会自动建立ReplicaSet，因此一般不须要直接用ReplicaSet；DaemonSet用于每一个node最多运行一个pod副本的场景；StatefuleSet保证pod的每个副本在整个生命周期中名称是不变的。Job用于运行结束就删除的应用，其余controller的pod一般是长期运行。
Service
一个Service能够看做一组提供相同服务的Pod的对外访问接口，Service做用于哪些Pod是经过Label Selector来定义的，service有本身的ip和端口，为pod提供负载均衡。
Namecpace
namespace是将物理的cluster逻辑上划分红多个虚拟的cluster，每个cluster就是一个namespace，不一样的namespace里的资源是彻底隔离的，kubectl get namespace命令查看，default是默认的命名空间，kebe-system是k8s本身建立的系统资源的命名空间。
Volume
volume是pod中可以被多个容器访问的共享目录
kubernetes架构
Kubernetes将集群中的机器划分为一个Master节点和一群工做节点（Node）。其中，Master节点上运行着集群管理相关的一组进程etcd、API Server、Controller Manager、Scheduler，后三个组件构成了Kubernetes的总控中心，这些进程实现了整个集群的资源管理、Pod调度、弹性伸缩、安全控制、系统监控和纠错等管理功能，而且全都是自动完成。在每一个Node上运行Kubelet、Proxy、Docker daemon三个组件，负责对本节点上的Pod的生命周期进行管理，以及实现服务代理的功能。
Kubernetes主要由如下几个核心组件组成：
etcd 保存了整个集群的状态； apiserver 提供了资源操做的惟一入口，并提供认证、受权、访问控制、API注册和发现等机制； controller manager 负责维护集群的状态，好比故障检测、自动扩展、滚动更新等； scheduler 负责资源的调度，按照预约的调度策略将Pod调度到相应的机器上； kubelet 负责维护容器的生命周期，同时也负责Volume（CVI）和网络（CNI）的管理； Container runtime 负责镜像管理以及Pod和容器的真正运行（CRI）； kube-proxy 负责为Service提供cluster内部的服务发现和负载均衡； kube-dns 负责为整个集群提供DNS服务 Ingress Controller 为服务提供外网入口 Heapster 提供资源监控 Dashboard 提供GUI Federation 提供跨可用区的集群 Fluentd-elasticsearch 提供集群日志采集、存储与查询
建立pod流程
经过Kubectl提交一个建立RC的请求，该请求经过API Server被写入etcd中， 此时Controller Manager经过API Server的监听资源变化的接口监听到这个RC事件， 分析以后，发现当前集群中尚未它所对应的Pod实例，因而根据RC里的Pod模板定义生成一个Pod对象， 经过API Server写入etcd，接下来，此事件被Scheduler发现，它当即执行一个复杂的调度流程，为这个新Pod选定一个落户的Node， 而后经过API Server将这一结果写入到etcd中， 随后，目标Node上运行的Kubelet进程经过API Server监测到这个“新生的”Pod， 并按照它的定义，启动该Pod并不辞辛苦地负责它的下半生，直到Pod的生命结束。 最后 经过Kubectl提交一个新的映射到该Pod的Service的建立请求， Controller Manager会经过Label标签查询到相关联的Pod实例， 而后生成Service的Endpoints信息，并经过API Server写入到etcd中， 接下来，全部Node上运行的Proxy进程经过API Server查询并监听Service对象与其对应的Endpoints信息， 创建一个软件方式的负载均衡器来实现经过Service访问到后端Pod的流量转发功能
k8s的分层架构
Kubernetes设计理念和功能其实就是一个相似Linux的分层架构
核心层：Kubernetes最核心的功能，对外提供API构建高层的应用，对内提供插件式应用执行环境 应用层：部署（无状态应用、有状态应用、批处理任务、集群应用等）和路由（服务发现、DNS解析等） 管理层：系统度量（如基础设施、容器和网络的度量），自动化（如自动扩展、动态Provision等）以及策略管理（RBAC、Quota、PSP、NetworkPolicy等） 接口层：kubectl命令行工具、客户端SDK以及集群 生态系统：在接口层之上的庞大容器集群管理调度的生态系统，能够划分为两个范畴 Kubernetes外部：日志、监控、配置管理、CI、CD、Workflow、FaaS、OTS应用、ChatOps等 Kubernetes内部：CRI、CNI、CVI、镜像仓库、Cloud Provider、集群自身的配置和管理等
k8s 状态服务
在K8S运行的服务，从简单到复杂能够分红三类：无状态服务、普通有状态服务和有状态集群服务
无状态服务
K8S使用RC（或更新的Replica Set）来保证一个服务的实例数量，若是说某个Pod实例因为某种缘由Crash了，RC会马上用这个Pod的模版新启一个Pod来替代它，因为是无状态的服务，新启的Pod与原来健康状态下的Pod如出一辙。在Pod被重建后它的IP地址可能发生变化，为了对外提供一个稳定的访问接口，K8S引入了Service的概念重点内容。一个Service后面能够挂多个Pod，实现服务的高可用。
普通有状态服务
和无状态服务相比，它多了状态保存的需求。Kubernetes提供了以Volume和Persistent Volume为基础的存储系统，能够实现服务的状态保存。
有状态集群服务
与普通有状态服务相比，它多了集群管理的需求。K8S为此开发了一套以Pet Set为核心的全新特性，方便了有状态集群服务在K8S上的部署和管理。具体来讲是经过Init Container来作集群的初始化工做，用 Headless Service 来维持集群成员的稳定关系，用动态存储供给来方便集群扩容，最后用Pet Set来综合管理整个集群。
要运行有状态集群服务要解决的问题有两个,一个是状态保存，另外一个是集群管理。 咱们先来看如何解决第一个问题：状态保存。Kubernetes 有一套以Volume插件为基础的存储系统，经过这套存储系统能够实现应用和服务的状态保存。
在应用程序中，能够分为有状态应用和无状态应用。 无状态的应用更关注于群体，任何一个成员均可以被取代。 对有状态的应用是关注个体。 像咱们前面用deployment控制器管理的nginx、myapp等都属于无状态应用。 像mysql、redis，zookeeper等都属于有状态应用，他们有的还有主从之分、前后顺序之分。 statefulset控制器能实现有状态应用的管理，但实现起来也是很是麻烦的。须要把咱们运维管理的过程写入脚本并注入到statefulset中才能使用。虽然互联网上有人作好了stateful的脚本，可是仍是建议你们不要轻易的把redis、mysql等这样有状态的应用迁移到k8s上。 在k8s中，statefulset主要管理一下特效的应用： a)、每个Pod稳定且有惟一的网络标识符； b）、稳定且持久的存储设备； c)、要求有序、平滑的部署和扩展； d）、要求有序、平滑的终止和删除； e)、有序的滚动更新，应该先更新从节点，再更新主节点； statefulset由三个组件组成: a) headless service（无头的服务，即没名字）； b）statefulset控制器 c）volumeClaimTemplate（存储卷申请模板，由于每一个pod要有专用存储卷，而不能共用存储卷）
K8S存储系统
K8S的存储系统从基础到高级又大体分为三个层次：普通Volume，Persistent Volume 和动态存储供应(dynamic provisioning)。
普通Volume
单节点Volume是最简单的普通Volume，它和Docker的存储卷相似，使用的是Pod所在K8S节点的本地目录。具体有两种，一种是 emptyDir，是一个匿名的空目录，由Kubernetes在建立Pod时建立，删除Pod时删除。另一种是 hostPath，与emptyDir的区别是，它在Pod以外独立存在，由用户指定路径名。这类和节点绑定的存储卷在Pod迁移到其它节点后数据就会丢失，因此只能用于存储临时数据或用于在同一个Pod里的容器之间共享数据。
跨节点存储卷
这种存储卷不和某个具体的K8S节点绑定，而是独立于K8S节点存在的，整个存储集群和K8S集群是两个集群，相互独立。跨节点的存储卷在Kubernetes上用的比较多，若是已有的存储不能知足要求，还能够开发本身的Volume插件，只须要实现Volume.go 里定义的接口。若是你是一个存储厂商，想要本身的存储支持Kubernetes 上运行的容器，就能够去开发一个本身的Volume插件，目前支持不少种存储方式，nfs，clusterfs，ceph，nas等等。
persistent volume和普通Volume的区别
普通Volume和使用它的Pod之间是一种静态绑定关系，在定义Pod的文件里，同时定义了它使用的Volume。Volume 是Pod的附属品，咱们没法单首创建一个Volume，由于它不是一个独立的K8S资源对象。而Persistent Volume 简称PV是一个K8S资源对象，因此咱们能够单首创建一个PV。它不和Pod直接发生关系，而是经过Persistent Volume Claim，简称PVC来实现动态绑定。Pod定义里指定的是PVC，而后PVC会根据Pod的要求去自动绑定合适的PV给Pod使用。
PersistentVolumeClaim
用户根据所需存储空间大小和访问模式建立（或在动态部署中已建立）一个 PersistentVolumeClaim。Kubernetes的Master节点循环监控新产生的PVC，找到与之匹配的PV（若是有的话），并把他们绑定在一块儿。动态配置时，循环会一直将PV与这个PVC绑定，直到PV彻底匹配PVC。避免PVC请求和获得的PV不一致。绑定一旦造成，PersistentVolumeClaim绑定就是独有的，无论是使用何种模式绑定的。若是找不到匹配的volume，用户请求会一直保持未绑定状态。在匹配的volume可用以后，用户请求将会被绑定。好比，一个配置了许多50Gi PV的集群不会匹配到一个要求100Gi的PVC。 只有在100Gi PV被加到集群以后，这个PVC才能够被绑定。
PV的访问模式
ReadWriteOnce：是最基本的方式，可读可写，但只支持被单个Pod挂载。
ReadOnlyMany：能够以只读的方式被多个Pod挂载。
ReadWriteMany：这种存储能够以读写的方式被多个Pod共享。不是每一种存储都支持这三种方式，像共享方式，目前支持的还比较少，比较经常使用的是NFS。在PVC绑定PV时一般根据两个条件来绑定，一个是存储的大小，另外一个就是访问模式。
静态，是管理员手动建立一堆PV，组成一个PV池，供PVC来绑定。
动态，是指在现有PV不知足PVC的请求时，可使用存储分类(StorageClass)，描述具体过程为：PV先建立分类，PVC请求已建立的某个类（StorageClass）的资源，这样就达到动态配置的效果。即经过一个叫 Storage Class的对象由存储系统根据PVC的要求自动建立。
一个PV建立完后状态会变成Available，等待被PVC绑定。一旦被PVC邦定，PV的状态会变成Bound，就能够被定义了相应PVC的Pod使用。Pod使用完后会释放PV，PV的状态变成Released。变成Released的PV会根据定义的回收策略作相应的回收工做。有三种回收策略，Retain、Delete 和 Recycle。Retain就是保留现场，K8S什么也不作，等待用户手动去处理PV里的数据，处理完后，再手动删除PV。Delete 策略，K8S会自动删除该PV及里面的数据。Recycle方式，K8S会将PV里的数据删除，而后把PV的状态变成Available，又能够被新的PVC绑定使用。在实际使用场景里，PV的建立和使用一般不是同一我的。这里有一个典型的应用场景：管理员建立一个PV池，开发人员建立Pod和PVC，PVC里定义了Pod所需存储的大小和访问模式，而后PVC会到PV池里自动匹配最合适的PV给Pod使用。
动态存储供应（dynamic provisioning）
前面在介绍PV的生命周期时，提到PV的供给有两种方式，静态和动态。动态卷供给是一个 Kubernetes 独有的功能，这一功能容许按需建立存储卷。在没有这种能力以前，集群管理员须要打电话给他们的云或者存储提供者来建立新的存储卷，成功之后再建立 PersistentVolume对象，才可以在 Kubernetes 中使用。动态卷供给能力让管理员没必要进行预先建立存储卷，而是随用户需求进行建立。这一特性在 1.2 版本中处于 α 阶段，在版本 1.4 中提高为 β。提升了动态卷的弹性和可用性。 其中动态方式是经过StorageClass来完成的，这是一种新的存储供应方式。使用StorageClass有什么好处呢？除了由存储系统动态建立，节省了管理员的时间，还有一个好处是能够封装不一样类型的存储供PVC选用。在StorageClass出现之前，PVC绑定一个PV只能根据两个条件，一个是存储的大小，另外一个是访问模式。在StorageClass出现后，等于增长了一个绑定维度。
k8s网络方案
一、直接路由：
节点数量很少的状况下，经过在每一个node上启动docker的时候经过设置—bip并添加对应的路由能够实现各个pod直接的网络互联互通，而且可与其余物理机或者虚拟机进行直接通讯，由于没有数据包的拆包解包工做。
直接路由网络优点：性能较好，容易管理
直接路由网络劣势：网络隔离性差，每次新增节点都须要手动设置路由规则。
二、Flannel容器网络：
Flannel是CoreOS团队针对Kubernetes设计的一个网络规划服务，简单来讲，它的功能是让集群中的不一样节点主机建立的Docker容器都具备全集群惟一的虚拟IP地址,在默认的Docker配置中，每一个节点上的Docker服务会分别负责所在节点容器的IP分配。这样致使的一个问题是，不一样节点上容器可能得到相同的内外IP地址。并使这些容器之间可以经过IP地址相互找到，也就是相互ping通。
Flannel的设计目的就是为集群中的全部节点从新规划IP地址的使用规则，从而使得不一样节点上的容器可以得到“同属一个内网”且”不重复的”IP地址，并让属于不一样节点上的容器可以直接经过内网IP通讯。
Flannel实质上是一种“覆盖网络(overlaynetwork)”，也就是将TCP数据包装在另外一种网络包里面进行路由转发和通讯，目前已经支持udp、vxlan、host-gw、aws-vpc、gce和alloc路由等数据转发方式，默认的节点间数据通讯方式是UDP转发。
Flannel之因此能够搭建kubernets依赖的底层网络，是由于它能够实现如下两点：
· 它给每一个node上的docker容器分配相互不想冲突的IP地址；
· 它能给这些IP地址之间创建一个覆盖网络，同过覆盖网络，将数据包原封不动的传递到目标容器内
Flannel网络优点：部署简单，性能还行
Flannel网络劣势：没法隔离多子网，对上层设计依赖度高，没有IPAM，IP地址浪费，对docker启动方案有绑定。
三、Calico容器网络：
Calico介绍
· Calico是一个纯3层的数据中心网络方案，并且无缝集成像OpenStack这种IaaS云架构，可以提供可控的VM、容器、裸机之间的IP通讯。Calico不使用重叠网络好比flannel和libnetwork重叠网络驱动，它是一个纯三层的方法，使用虚拟路由代替虚拟交换，每一台虚拟路由经过BGP协议传播可达信息（路由）到剩余数据中心。
· Calico在每个计算节点利用Linux Kernel实现了一个高效的vRouter来负责数据转发，而每一个vRouter经过BGP协议负责把本身上运行的workload的路由信息像整个Calico网络内传播——小规模部署能够直接互联，大规模下可经过指定的BGP route reflector来完成。
· Calico节点组网能够直接利用数据中心的网络结构（不管是L2或者L3），不须要额外的NAT，隧道或者Overlay Network。
· Calico基于iptables还提供了丰富而灵活的网络Policy，保证经过各个节点上的ACLs来提供Workload的多租户隔离、安全组以及其余可达性限制等功能。
Calico网络优点：性能较好，可控性高，隔离性好
Calico网络劣势：操做起来比较复杂，维护成本高，对iptables有依赖
calico https://www.kubernetes.org.cn/4960.html
各类应用方案知识点可参考官网
https://kubernetes.io/docs/home/