【个人Linux，我作主！】kubernetes基础概念

（1）Kubernetes各个组件
Kubernetes是一个集群，集群的角色不是对等的，有主节点master和工做节点node之分，而主节点之上有三个组件运行守护进程，分别是API Server，Scheduler，Controller-Manager。而在node之上，有kubelet主要是和API Server进行交互的核心组件，而docker做为容器引擎来运行Pod中的容器而建立的。为了可以统一管理同一个集群中大量的资源，因此咱们须要给元数据添加一个Label，它是一个key、value类型的数据，定义完Label标签后咱们就可使用Lable Selector标签选择器来根据条件挑选出符合的Pod资源。
Pod自己是须要由控制器来管理，而不是由人手工来管理的，事实上在K8S上Pod有两类，(1)第一种是自主式Pod，是指自我管理的，由API Server接收之后借助于调度器将其调度至指定的node节点，由node启动此Pod，若是Pod中的容器出现了故障须要重启容器，那是由kubelet来完成，可是节点故障了，这个Pod也就消失了，没法实现全局调度；(2)因此咱们建议使用第二种即控制器管理的Pod，这样会使Pod成为有生命周期的对象，由调度器将其调度至集群中的某节点运行之后，任务一终止它也就停了，可是有一些任务，好比nginx或者tomcat这一类服务若是运行为容器的话它是须要随时处于运行状态，一旦出现故障须要马上反应到或进行重启或进行重建，这样就须要K8S平台提供的Pod控制器。
对于控制器管理的Pod来讲，Pod有不少种，最先的一种名为ReplicationController即副本控制器，当咱们启动一个控制器后，ReplicationController能够控制同一类Pod对象的各类副本，一旦副本的数量少了就会加一个补够，ReplicationController还可以实现其它任务滚动更新，例如更新当前管理的2个Pod控制器，它先建立一个新版本的Pod，并容许在更新过程当中临时超出2个Pod的限制，此时会有3个Pod同时运行，更新完第3个Pod后，此时再删除第1个Pod，这样就实现了保证最终是控制器要求的2个Pod的目标，这就是滚动更新概念，并且它也支持滚动更新的逆转即回滚操做。早期的时候只有ReplicationController一种版本的控制器，到了K8S的新版本后，又有了新的控制器ReplicaSet，可是这个控制器不直接使用，它有一个声明式更新的控制器Deployment来作管理，可是Deployment只能管理无状态的应用，若是是有状态的应用须要使用StatefulSet有状态副本集，若是须要在每个node上运行一个副本而不是随影运行还须要一个DaemonSet，若是已经做业则须要Job，周期性的任务计划做业Cronjob，这些控制器的类型是分别用于确保不一样类型的Pod资源，来用符合用户所指望的方式进行运行。另外Deployment控制器还支持二级控制器HPA（HorizontalPodAutoscaler）水平Pod自动伸缩控制器。

Pod是有生命周期的，随时都会有Pod离去，随时都会有新的Pod加进来，假如他们提供的是同一种服务，咱们客户端是没办法经过固定的手段来访问这些Pod的，由于这些Pod随时都会被替换掉，因此这里就须要用到服务发现机制了。K8S为每一组提供同类服务的Pod和它的客户端之间添加了一个中间层，这个中间层是固定的，这个中间层就叫service，service只要不删除，它的地址就是固定的，这个服务是一个调度器，能提供一个稳定的访问入口，一旦一个Pod宕机了，没有关系新建一个Pod，这个Pod会和service关联起来，做为service后端可用Pod之一，在Pod上有一个固定的元数据Label，只要建立了Pod，它的Label是统一的，都能被service识别，因此客户端的请求到达service，由service代理至后端Pod来实现，因此客户端始终看到的可用服务是service的地址，而这个service组件其实是一个iptables的DNAT规则，装完K8S后还须要安装部署一个DNS的Pod以确保各service名称可以被解析，因此咱们把它称为系统架构级的Pod，它们被称为集群的AddOns附加组件。
iptables已经把负载均衡的功能交给IPVS实现了，所以service背后的Pod使用DNAT来实如今调度效果上可能不太尽如人意，所以在1.11版当中已经把iptables规则进一步改为了IPVS规则，当你建立了一个service规则也就生成了一条IPVS规则，只不过是NAT模型的IPVS，所以支持用户本身指定的调度算法。
咱们把全部应用程序运行在K8S之上，假设咱们以NMT的形式来运行，其中N是T的客户端，可是T不止一个Pod，这些Pod若是须要被N访问，能够在T前加一个Service，把全部请求调度代理至内部的T，因此T不须要开放至互联网访问，一样每个T须要访问M，因此M也应该提供一个固定的访问入口，所以在M前也须要添加一个Service，这个Service是为M提供固定访问入口的，各个T上的应用程序访问的是M的Service， 由这个Service调度至后端的M上来。对于N来讲，它的客户端主要来自集群外部，只有一小部分来自集群内部，因此也须要为N添加Service，Service的地址是一个仅存在于iptables或IPVS规则中的地址，怎么可以被客户端真正访问？为了可以组织出来一个K8S的集群，咱们须要物理节点，因此用户的请求先到达物理服务器的地址，由物理服务器再转发代理至Service，全部外部客户端先去访问节点，由于只有节点才是边界，若是边界也是私网地址，那么能够在外部建立一个外置的调度器，这个调度器能够调度至边界的任何一个节点上的，这个节点的端口只能有一个端口来转发至服务的端口，由服务再转发至Nginx的端口，从外置调度器至Nginx如此造成了三次调度。

咱们发现外置的服务器已经脱离了K8S的控制了，它不能被K8S的命令来进行建立了，不能经过命令建立也就没法作到LBaaS（负载均衡即服务）架构。所以咱们把K8S运行在阿里云或者亚马逊云的云计算环境虚拟机之上，多个虚拟机组成一个K8S集群，咱们知道云计算环境是支持LBaaS的，因此K8S是能够对外调用底层的云计算环境，这样云计算环境给咱们的环境建立一个软件的外置调度器，从而完成将请求接入进来。
而NTM这些服务中，例如Tomcat服务对应的这一组Pod不是由用户手动建立的，而是由控制器建立的，Nginx由Nginx控制器建立，MySQL由MySQL控制器建立，一个控制器一般只管理一部分组件，控制器则是根据标签来识别本身的Pod够不够。
每个Service要想基于名称被客户端访问和发现须要靠DNS服务，DNS服务自身也是一个Pod，这个DNS服务也须要有Service，同时还须要有控制器来经过标签控制建立访问。这就是咱们的K8S集群的集群组成核心组件。

在K8S中，要求的网络模型有3种，第一是每个Pod运行在同一个网络中，第二是Service是另一个网络，它是一个虚拟的地址，第三是各节点的网段也是一个单独的网络。因此接入外部访问时首先到达节点网络，由节点网络代理至Service集群网络，再由Service集群网络代理至Pod的网络。
在K8S上还存在着三类通讯，(1)由于一个Pod内会有多个容器，同一个Pod内的多个容器间使用lo回环地址通讯，(2)各Pod之间的通讯，使用Overlay Network叠加网络，经过隧道的方式来转发二层报文，虽然跨主机但好像工做在同一个二层网络中同样，咱们能够转发对方的二层报文或隧道转发对方的三层报文从而实现叠加网络，(3)咱们客户端和服务端的Pod之间访问时，由于考虑到Pod是有生命周期的，因此中间是经过Service，即Pod与Service之间的通讯，可是Pod与Service不在同一个网络没法直接通讯，Service地址只不过是主机上的iptables规则中的地址，因此只须要有网关指向容器，每个docker宿主机上都得有iptables或者IPVS规则，可是Service怎么能改变全部节点上的相关地址和规则呢？这就须要一个专门的组件来实现，这个组件是运行在node之上的守护进程，它被称为kube-proxy，它负责随时与API Server进行通讯，由于每个Pod发生变化的时候，这个结果是会保存在API Server中的，而API Server通讯内容发生改变后会生成一个通知事件，事件能够被任何关联的组件接收到例如kube-proxy，一旦发现某一Service背后的Pod发生了改变，那么对应的由kube-proxy负责在本地把那个地址反映到iptables或者IPVS规则中，因此Service的管理是靠kube-proxy来实现的。

这么一来咱们发现API Server会存整个集群中各个相关状态的信息，因此各个master之间须要一个共享存储，这个存储咱们称为K8S的DB，这个DB叫作etcd，而etcd是一个键值存储的数据库系统，由于整个集群的数据都在etcd上，因此etcd须要作高可用。etcd通讯一个端口用来实现集群内部通讯。另外一个端口用来实现向客户端提供服务，也就意味着内部通讯须要一个点对点通讯的证书来配置https，然后向客户端提供服务的时候http要想加密靠另一套证书来实现，一样K8S的API Server也是须要将https加密进行通讯，这个是K8S的客户端和副本之间的通讯，并且最好与etcd不要使用同一个CA来签署的。
因此etcd内部通讯须要一套CA来签署证书，etcd为了向客户端API Server提供服务须要一套CA来签署证书，而API Server为了想客户端提供服务须要另一套CA来签署证书，而API Server与各node节点上的kubelet集群代理进行通讯也须要一套CA来签署证书，而API Server与各node节点上的kube-proxy进行通讯也须要一套CA来签署证书。因此想要手动部署K8S足够安全总共须要5套CA认证。

（2）Kubernetes的网络
整个API Server主要是由三类节点组成，第一类是API master，同时须要至少3个节点多高可用，第二类是etcd用来存储集群状态数据，一样也须要至少3个节点多高可用，最后第三类是node节点。它们彼此之间都是http或https进行通讯，然后咱们就能够在node之上运行Pod了，而Pod与Pod之间要通讯，Pod内部的容器之间要通讯，Pod与Service要通讯，Pod与集群外的客户端要通讯，因此咱们要构建出多个网络来。节点有节点的网络，Service有Service的集群网络，Pod有Pod的网络。K8S经过CNI插件体系来接入外部的网络服务解决方案，CNI即为容器网络接口，只要是一个网络服务提供商，能遵循CNI这个开发规范，那么它就能做为K8S的网络解决方案来使用，这些网络解决方案能够以附加组件的方式托管运行在集群之上，网络解决方案能够以Pod运行，而后为其余Pod提供网络解决方案，这个Pod一般是一个特殊Pod。虽然托管运行在集群之上但它们须要共享节点的网络名称空间，这样从而能够实现以容器的方式来运行，实行系统管理之事。
目前能做为CNI插件的很是多，而常见的插件是flannel。其实咱们的网络通常须要两类功能，第一个就是提供网络功能，给Pod、Service提供IP地址，第二个则是提供网络策略，其实Pod和Pod之间是能够直接通讯的，可是咱们通常会经过Service来代理进行通讯，由于Nginx的Pod和Tomcat的Pod之间在进行通讯的时候，T随时会发生变更，一旦发生变更后则N就没法和T再进行通讯了，因此使用Service来代理进行通讯是为了解决Pod有生命周期的问题。若是我在一个K8S之上托管了2万个Pod，这2万个Pod均可以直接通讯，可是若是这些Pod不属于同一家公司，那么别人能够任意访问你的服务甚至劫持你的服务都有可能，因此在多租户的场景中这是很是危险的状况，因此须要用到网络策略中的隔离功能，网络策略须要施加一些条件来隔离不一样的Pod让彼此间不能互相访问。
K8S中另一个重要的组件就是名称空间，整个K8S做为一个统一的集群存在，里面运行2万个Pod程序，此时能够把它切割成多个空间，一类Pod只运行在一个空间中，可是这个空间并非真正意义上的网络边界，只是管理上的边界，例如第一个是开发环境的空间，第二个是生产环境的空间，未来咱们要删除一个环境可使用网络名称空间直接进行移除，因此它为咱们提供了一个管理的边界。可是Pod之间是没有边界的，因此网络策略容许咱们去定义名称空间和名称空间之间甚至是同一个名称空间的Pod之间是否能够互相访问，经过生成iptables规则来隔离它们彼此间的互相访问，这就是网络策略。对于K8S来讲网络策略和网络功能是两个不一样维度的东西，flannel只能实现其中的网络配置，而第二种CNI则是calico，它同时支持网络配置和网络策略，可是calico的使用和实现起来比较难，并且calico能基于BGP协议来实现直接路由的通讯，而flannel是纯粹的叠加网络实现，calico是一个三层隧道网络，也能够直接使用为BGP协议的路由直通模型。flannel和calico是目前最流行的两种网络解决方案，若是咱们想同时实现简单的网络配置而且有网络策略的话就须要使用第三方的项目插件canel，它既能够实现简单的网络配置的功能，也能够实现网络策略的需求，它是flannell和calico结合在一块儿生成的新的项目。

整个K8S有三个网络，第一是节点网路，各节点进行通讯，第二Pod网络，节点之上有Pod，Pod之间经过叠加也罢，直接路由也罢，可以直接进行通讯，第三个是Service集群网络，由kube-proxy负责管控和生成，让Pod和Pod之间能够通讯是借助一个中间层来实现，原本Pod和Pod之间是在同一个网段的，但后来咱们不得不借助于Service，而Service和Pod又不在同一个网段，下降了效率，可是对管理来讲倒是有必要的。

—————— 本文至此结束，感谢阅读 ——————