目录
一、kubernetes的今生前世
二、kubernetes的功能
三、kubernetes系统组成、及各组件功能
1. kubernetes集群由三部分组成
2. 各组件介绍
四： kubernetes network
五、总结：
在学习kubernetes技术之前，我们有必要了解下它的出现以及发展历程
一、kubernetes的今生前世
kubernetes项目的前生是Google公司内部使用多年的一套容器编排系统borg。而后为了与docker公司占领器编排系统的地位。Google根据自家的borg编排思想使用go语言进行塑造重生并重新命名为kubernetes，并将kubernetes项目开源并捐献给了CNCF。
CNCF是致力于云原生技术的普及和发展及标准化的组织机构。由Google、红帽、微软、IBM等大型云计算厂商牵头成立了CNCF(Cloud Native Computing Foundation)即云原生计算基金会
由于borg项目在Google内部早于2004年开始使用，多年的经验累积让含着金钥匙出生的kubernetes项目一经问世便迅速击败docker swarm及marathon编排系统，打破了短暂的容器编排领域三足鼎立局面并迅速占领容器编排的市场，现在已然成为容器编排技术的标准。
云原生发展历程：
-> 2004年开始，Google已在内部大规模地使用容器技术。
->2008年，Google将 Cgroups合并进入了Linux内核。
->2013年，Docker项目正式发布。
->2014年，Kubernetes项目正式发布。
->2015年，由Google、Redhat 以及微软等大型云计算厂商以及一些开源公司共同牵头成立了CNCF(Cloud Native Computing Foundation)云原生计算基金会。 2017年，CNCF达到170个成员和14个基金项目；
->2018年，CNCF成立三周年有了195个成员，19个基金会项目和11个孵化项目。
->2022年，全球187国家、820+企业成员、130+项目、16万以上开发者。
二、kubernetes的功能
kubernetes是个跨多主机的容器编排系统，将多个主机构建成一个集群，可将整个集群的计算节点抽象成为一个大的资源池提供计算能力。当客户端提交容器的相关操作请求时，只需提交给容器编排系统，容器编排系统会自动筛选自动实现所需操作，并可实现集群中的容器跨节点自动调度、自动扩缩容，并保证服务可用性。
三、kubernetes系统组成、及各组件功能
1. kubernetes集群由三部分组成
master控制节点：1、整个集群的指挥调度者，负责为用户暴露API
2、作为客户端访问集群的唯一入口
3、编配各组件之间通信，调度工作负载
4、确保各资源对象符合期望状态
node计算节点： 1、接收来自master的工作指令，提供资源、运行容器
2、调整网络规则，完成路由和转发流量
etcd存储节点：是kubernetes默认key-value数据存储系统、存储kubernetes集群的所有数据；但是API server把etcd所提供的数据存储能力做了进一步规范化，使得用户能够存进etcd中的数据只能是API server所支持的资源属性的数据。
2. 各组件介绍
1.1、master组件组成部分
API server
controller manager控制器: API server接收到客户端请求后，controller manager是具体执行者，同时确保资源对象数符合期望值；它是master最核心的组件
scheduler 调度器：随时监测 API server的资源变动情况，当有变动时scheduler就会把新的容器调度到合适的节点创建
1.2、node组件
kubelet : 1.node节点上真正运行任务的组件，kubelet会不断的监测 API server的资源变动情况，如果恰好资源变动了并且是由自己节点执行，那么kubelet就开始执行这个任务，kubelet会调容器运行时下载镜像并启动容器
2.进行节点容器的健康检查
3.向master汇报node节点状态信息
kube-proxy : 负责service的组网是K8S的核心网络组件，负责生成iptables规则或者ipvs规则、负责node、service、POD之间有效通信、并负责维护和实时动态更新规则，下面会详细介绍service与POD关联关系
容器运行时： 负责容器镜像管理、容器生命周期的管理工作、调用runc运行时
四： kubernetes network
K8S有三种网络：
1、pod 网络
2、service 网络
3、node 网络
不过在说k8s的网络前先了解下k8s的服务发现机制，以便于更好的理解k8s网络
首先k8s编排系统的对象不是容器，而是一个叫做POD的资源；POD是K8S节点上的最小调度单元，由一个或多个容器组成类似下图
POD是K8S对于容器的一层封装，同一个POD里容器具有超亲密关系，共享一些资源，比如共享网络、IPC、UTS名称空间 , 因此同一个POD的容器可以通过localhost接口进行通信，并且同一个POD里有个公共的容器pause
POD承载着业务容器，提供服务，为了防止POD奔溃导致服务不可用，因此K8S就必须要有对POD的健康检测功能，一旦发现POD异常就能够对它进行恢复或者重建。而是POD本身是没有这种功能的，K8S是通过POD 控制器来实现此项功能的，最基础常用的控制器Deployment。因此K8S创建POD并不是直接创建的，而是先创建一个POD 控制器，然后通过控制器来创建POD,并且依据客户端对POD数量需求，精确控制，如果POD 控制器要创建3个副本的POD，那么控制器就精确做到整个K8S集群只运行三个POD
作为承载业务的POD必然需要一个地址提供给客户端进行访问，常规来说可以通过IP地址作为访问方式，但是POD并不算是长期稳定的状态，它会因故障而被重启、重建的风险，它的建立与销毁是动态的，因此一旦重建后IP可能就会不一致，那么之前可以通过IP访问的就会失败。
service
service提供固定的访问地址并且反代至POD上，客户端访问service而后service通过反代至对应的POD上完成服务发现，但是service到底是依据什么条件作为判断和标识POD的标准呢？
对于此K8S给出一个极具创造性的方案：给每个资源对象附加一个标签，通过标签的方式来作为唯一标识，而不是依靠IP。这个标签就是键值对，比如app:nginx这个标签，当POD有这个标签时，service可以通过标签选择器（label selector）来找到哪些是拥有app:nginx标签的POD，因此就算POD重建标签也不会变化，只要service ip保持不变客户端就可以访问到POD。如下一个service的描述文件。service的名字为my-service。service指向的pod需要具有app: MyApp标签
这样即使POD被重建也可以通过service ip正常访问到POD了，这个机制得以正常运行的前提是service ip是固定的；但是service ip本身其实是iptables规则或者ipvs规则，并不是配置在某个网卡上的地址，因此规则如果不删除就会一直在，但是规则删除了service ip也会随之变化。
这样的话客户端仍然有无法访问到service ip的风险的，因此在K8S上还需要一个附件DNS，它是动态的，每当用户在K8S上创建一个service，而且service一定是有个名称和ip地址的。DNS会把service的名称和IP的对应关系转换成记录并且动态注册在DNS上，所以客户端只需要在DNS中查询service名称即可解析到对应的IP，即使service删除重建service的 ip也会实时的反应在DNS记录中，因此只要service的名称不变就可以通过DNS解析拿到service ip了，客户端不用关注ip变化与否
但是service ip并不是真正的ip地址，并没有关联到某个具体的网卡，因此无法真正完成通信，需要kube-proxy组件实现将service资源转换为当前节点上的iptable规则或者ipvs规则，这些规则可以把那些发往该service上的流量分发至它后端的POD上。
五、总结：
API service是K8S中唯一的入口，是整个集群的网关，可以通过命令行或者网页与API service进行交互；API service是个HTTP API; K8S中的所有组件都需要且只能通过与API service进行交互
所有组件都是API service的客户端，它们必须通过API service认证才能操作，这也是安全的前提 ，API service是唯一一个etcd的客户端，因此能管理并操纵etcd数据的只有API service，其它所有组件都不能直接操作etcd
