K8S 集群结构图
一些名词:
-
etcd
-
etcd保存了整个集群的状态；用于持久化存储集群中所有的资源对象，如Node、Service、Pod、RC、Namespace等；API Server提供了操作etcd的封装接口API，这些API基本上都是集群中资源对象的增删改查及监听资源变化的接口。
-
API Server
提供了资源对象的唯一操作入口，其他所有组件都必须通过它提供的API来操作资源数据，通过对相关的资源数据“全量查询”+“变化监听”，这些组件可以很“实时”地完成相关的业务功能。
提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制； -
Controller Manager
集群内部的管理控制中心，其主要目的是实现Kubernetes集群的故障检测和恢复的自动化工作，比如根据RC的定义完成Pod的复制或移除，以确保Pod实例数符合RC副本的定义；根据Service与Pod的管理关系，完成服务的Endpoints对象的创建和更新；其他诸如Node的发现、管理和状态监控、死亡容器所占磁盘空间及本地缓存的镜像文件的清理等工作也是由Controller Manager完成的。
负责维护集群的状态，比如故障检测、自动扩展、滚动更新等； -
Scheduler
集群中的调度器，负责Pod在集群节点中的调度分配。 -
Kubelet
负责本Node节点上的Pod的创建、修改、监控、删除等全生命周期管理，同时Kubelet定时“上报”本Node的状态信息到API Server里,
同时也负责Volume（CVI）和网络（CNI）的管理； -
Proxy
实现了Service的代理与软件模式的负载均衡器。
负责为Service提供cluster内部的服务发现和负载均衡；
流程:
通过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的生命结束。
Master和Node
Kubernetes将集群中的机器划分为一个Master节点和一群工作节点（Node）。其中，Master节点上运行着集群管理相关的一组进程etcd、API Server、Controller Manager、Scheduler，后三个组件构成了Kubernetes的总控中心，这些进程实现了整个集群的资源管理、Pod调度、弹性伸缩、安全控制、系统监控和纠错等管理功能，并且全都是自动完成。在每个Node上运行Kubelet、Proxy、Docker daemon三个组件，负责对本节点上的Pod的生命周期进行管理，以及实现服务代理的功能
------------
在Kubenetes中，所有的容器均在Pod中运行,一个Pod可以承载一个或者多个相关的容器，在后边的案例中，同一个Pod中的容器会部署在同一个物理机器上并且能够共享资源。一个Pod也可以包含O个或者多个磁盘卷组（volumes）,这些卷组将会以目录的形式提供给一个容器，或者被所有Pod中的容器共享，对于用户创建的每个Pod,系统会自动选择那个健康并且有足够容量的机器，然后创建类似容器的容器,当容器创建失败的时候，容器会被node agent自动的重启,这个node agent叫kubelet,但是，如果是Pod失败或者机器，它不会自动的转移并且启动，除非用户定义了 replication controller。
proxy:
Kube-proxy是K8s集群内部的负载均衡器。它是一个分布式代理服务器，在K8s的每个节点上都有一个；这一设计体现了它的伸缩性优势，需要访问服务的节点越多，提供负载均衡能力的Kube-proxy就越多，高可用节点也随之增多。
service 与 pod的关系
服务主要是用来提供外界访问的接口，服务可以关联一组pod，这些pod的ip地址各不相同，而service相当于一个复杂均衡的vip，用来指向各个pod，当pod的ip地址发生改变之后，也能做到自动进行负载均衡，在关联的时候，service和pod之间主要通过label来关联，也就是标签（-l表示为label）。