上次通过katacoda体验了Kubernetes界面化工具,大概也了解了一些组件和概念。
首先从整体上看,上边这块就是Master节点,下面有两块都是worker节点,master里面部署的都是k8s的核心模块,虚线框代表的是API Server,提供了资源的核心模块,提供了认证授权和k8s的访问控制,可以通过kubectl或者自己开发的userClient,restApi的形式访问API server。从而完成整个集群的访问。
了解设计理念可以更深入的了解k8s,设计实在太好了,非常值得我们学习和借鉴。
优先规则,对node进行打分,通过优先函数进行预选规则,每个优先函数可以返回0-10的函数,分数越高,这台主机越适合,对应一个权重。
通过pod的Ip来进行访问
满足pod,ip不能冲突
每个服务,所有的pod给虚拟Ip,虚拟Ip只能在内部访问
服务暴露到节点,外部的可以通过NodeIp 访问pod
负责集群内部的dns解析,内部之间可以通过名称访问pod。
玩k8s,玩的就是集群
kubernetes里的Master指的是集群控制节点。每个kubernetes集群里都需要一个Master节点来负责整个集群的管理和控制,基本上kubernetes所有的控制命令都是发给它,它来负责具体的执行过程,我们后面所有的执行的命令基本上都是在Master节点上运行的。Master节点通常会占据一个独立的服务器或虚拟机,就是它的重要性体现,一个集群的大脑,如果它宕机,那么整个集群将无法响应控制命令。
同样的它也是一台物理机或是虚拟机。Node节点才是Kubernetes集群中工作负载节点,每个Node都会被Master分配一些工作负载(Docker容器),当某个Node宕机之后,其上的工作负载会被Master自动转移到其它节点上面去。
Kubernetes 最基本的部署调度单元。每个 Pod 可以由一个或多个业务容器和一个根容器(Pause 容器)组成。一个 Pod 表示某个应用的一个实例。 每个pod由一个根容器的pause容器,其他是业务容器。
k8s为每个pod分配了唯一的IP地址,一个pod里的多个容器共享pod IP。 pod其实有两种类型:普通的pod和静态pod,后者比较特殊,它并不存放在etcd存储中,而是存放在某个具体的Node上的一个具体文件中,并且只在此Node上启动运行。而普通的pod一旦被创建,就会被放入etcd中存储。随后被master调度到某个具体的Node上并进行绑定,随后该pod被对应的Node上的kubelet进程实例化成一组相关的docker容器并启动起来。 每个pod都可以对其使用的服务器上的计算资源设置限额,当前可以设置限额的源有CPU和memory两种。其中CPU的资源单位为CPU的数量。 一般而言,一个CPU的配额已经算是相当大的一个资源配额,所以在k8s中,通常以千分之一的CPU配额为最小单位,以m来表示,通常一个容器的CPU配额为100-300m,即占用0.1-0.3个CPU。这个配额是个绝对值,不是占比。 在k8s中,一个计算资源进行配额限定需要设定两个参数: requests,资源的最小申请量,系统必须满足要求 limits,资源最大允许使用的量。
pod的状态
Pending
挂起,这时pod已经被k8s集群接受,但有一个或多个容器镜像尚未创建,等待时间包括调度pod的时间和通过网络下载容器镜像的时间。
Running
此时pod已经被绑定到某一个节点上,pod中所有的容器都被创建并且至少有一个容器正在运行或者处于启动或重启状态。
Succeed
此时pod中的所有容器都被成功终止并且不会重启。
Failed
pod中的所有容器都已经被终止,并且至少有一个容器因为失败而终止(容器以非0状态退出)。
Pod 副本的抽象,用于解决 Pod 的扩容和伸缩。
Deployment 表示部署,在内部使用ReplicaSet 来实现。可以通过 Deployment 来生成相应的 ReplicaSet 完成 Pod 副本的创建。
Service 是 Kubernetes 最重要的资源对象。Kubernetes 中的 Service 对象可以对应微服务架构中的微服务。Service 定义了服务的访问入口,服务的调用者通过这个地址访问 Service 后端的 Pod 副本实例。Service 通过 Label Selector 同后端的 Pod 副本建立关系,Deployment 保证后端Pod 副本的数量,也就是保证服务的伸缩性。
K8S对外的唯一接口,提供HTTP/HTTPS RESTful API,即kubernetes API。所有的请求都需要经过这个接口进行通信。主要负责接收、校验并响应所有的REST请求,结果状态被持久存储在etcd当中,所有资源增删改查的唯一入口。(大脑中央控制器)
负责保存k8s 集群的配置信息和各种资源的状态信息,当数据发生变化时,etcd会快速地通知k8s相关组件。etcd是一个独立的服务组件,并不隶属于K8S集群。生产环境当中etcd应该以集群方式运行,以确保服务的可用性。(数据库)
etcd不仅仅用于提供键值数据存储,而且还为其提供了监听(watch)机制,用于监听和推送变更。在K8S集群系统中,etcd的键值发生变化会通知到API Server,并由其通过watch API向客户端输出。
负责管理集群各种资源,保证资源处于预期的状态。Controller Manager由多种controller组成,包括replication controller、endpoints controller、namespace controller、serviceaccounts controller等 。由控制器完成的主要功能主要包括生命周期功能和API业务逻辑,具体如下:
资源调度,负责决定将Pod放到哪个Node上运行。Scheduler在调度时会对集群的结构进行分析,当前各个节点的负载,以及应用对高可用、性能等方面的需求。
kubelet是node的agent,当Scheduler确定在某个Node上运行Pod后,会将Pod的具体配置信息(image、volume等)发送给该节点的kubelet,kubelet会根据这些信息创建和运行容器,并向master报告运行状态。
每个Node都需要提供一个容器运行时(Container Runtime)环境,它负责下载镜像并运行容器。目前K8S支持的容器运行环境至少包括Docker、RKT、cri-o、Fraki等。
service在逻辑上代表了后端的多个Pod,外界通过service访问Pod。service接收到请求就需要kube-proxy完成转发到Pod的。每个Node都会运行kube-proxy服务,负责将访问的service的TCP/UDP数据流转发到后端的容器,如果有多个副本,kube-proxy会实现负载均衡,有2种方式:LVS或者Iptables
K8S集群还依赖一组附件组件,通常是由第三方提供的特定应用程序。
在K8S集群中调度并运行提供DNS服务的Pod,同一集群内的其他Pod可以使用该DNS服务来解决主机名。K8S自1.11版本开始默认使用CoreDNS项目来为集群提供服务注册和服务发现的动态名称解析服务。
K8S集群的全部功能都要基于Web的UI,来管理集群中的应用和集群自身。
容器和节点的性能监控与分析系统,它收集并解析多种指标数据,如资源利用率、生命周期时间,在最新的版本当中,其主要功能逐渐由Prometheus结合其他的组件进行代替。
PS:k8s主要明白基本概念有哪些,基本组件有哪些,了解他的概念,下一步咱们一起搭建k8s集群。