目录
一、概述
二、 Kubernetes 集群的两种管理角色:Master 和 Node
1、Master
1.1、master概念
1.2、master节点上运行的进程
①、Kubernetes API Server(kube-apiserver):(负责对外暴露 Kubernetes API)
②、Kubernetes Controller Manager(kube-controller-manager):(控调整调整集群的状态)
③、Kubernetes Scheduler(kube-scheduler):(进行调度决策,让 Pod 在合适的节点上创建运行)
④、etcd服务:(作为保存 Kubernetes 所有集群数据的后台数据库)
2、Node
2.1、node概念
2.2、node节点上运行的进程
①、kubelet:(负责执行、监控由调度器分配的 Pod)
②、kube-proxy:(网络代理,负责为 Service 提供集群内部的服务发现和负载均衡)
③、Docker Engine(docker)
三、kubernetes实现高效均衡的资源调度策略的方式
四、Pod
1、pod中容器有几种
2、pod的类型
2.1、普通的Pod
2.2、静态的Pod
五、Replication Controller(RC)
1、replication controller 概念
2、replication controller的组成部分
3、replication controller的重要性
六、Label(标签)
1、label 概念
七、StatefulSet和Deployment
八、Endpoint
九、server(服务)
1、概述
2、server 是怎样和后端的Pod副本集群通信的
3、RC(replication controller 副本控制器)对server看来的作用
4、多个pod副本组成一个集群来提供服务,客户端是怎样访问他们的
十、Volume(存储卷)
1、概念
2、k8s中的volume和docker中的volume的区别
十一、Persistent Volume (pv)
1、pv的关键配置参数
2、PV 生命周期的各个阶段(Phase)
十二、PVC 详解
十三、k8s相关概念总结
1、Container
2、Pod
3、Node
4、Namespace
5、Service
6、Label
Kubernetes 中的大部分概念如 Node 、 Pod 、 Replication Controller 、 Service 等都可以看作一
种“资源对象”,几乎所有的资源对象都可以通过 Kubernetes 提供的 kubectl 工具(或者 API 编程调用)执行增、删、改、查等操作并将其保存在 etcd 中持久化存储。
从这个角度来看,Kubernetes 其实是一个高度自动化的资源控制系统,它通过跟踪对比 etcd 库里保存的“资源期望状态”与 当前环境中的“实际资源状态”的差异来实现自动控制和自动纠错的高级功能。
Kubernetes 里的 Master 指的是集群控制节点,每个 Kubernetes 集群里需要有一个 Master节点来负责整个集群的管理和控制,基本上 Kubernetes 的所有控制命令都发给它,它来负责具体的执行过程,我们后面执行的所有命令基本都是在 Master 节点上运行的。 Master 节点通常会占据一个独立的服务器(高可用部署建议用 3 台服务器),其主要原因是它太重要了,是整个集群的“首脑”,如果宕机或者不可用,那么对集群内容器应用的管理都将失效。
作用:提供了 HTTP Rest 接口的关键服务进程,是 Kubernetes 里所有资源的增、删、改、查等操作的唯一入口,也是集群控制的入口进程。
作用:Kubernetes 里所有资源对象的自动化控制中心,可以理解为资源对象的“大总管”。
作用:负责资源调度(Pod 调度)的进程,相当于公 交公司的“调度室”。
作用:Kubernetes 里的所有资源对象的数据存储位置。
除了 Master , Kubernetes 集群中的其他机器被称为 Node 节点,Node 节点才是 Kubernetes 集群中的工作负载节点。 每个 Node 都会被 Master 分配一些工作负载( Docker 容器),当某个 Node 宕机时,其上的工作负载会被 Master 自动转移到其他节点上去。
作用:负责 Pod 对应的容器的创建、启停等任务,同时与 Master 节点密切协作,实现集群管理的基本功能。
作用:实现 Kubernetes Service 的通信与负载均衡机制(L4层的负载均衡)的重要组件
作用:Docker 引擎,负责本机的容器创建和管理工作
node节点可以在运行期间动态的增加到k8s的集群中,前提是这个节点已经完成正确的安装、配置和启动关键进程。在默认情况下,kublet会向master注册自己,这也是k8s推荐的管理方式。node被纳入集群管理范围后,kubelet进程就会定时向master节点汇报自生的状态,例如操作系统、Docker 版本、机器的 CPU 和内存情况,以及当前有哪些 Pod 在运行等。这样Master 可以获知每个 Node 的资源使用情况,并实现高效均衡的资源调度策略。 而某个 Node 超过指定时间不上报信息时,会被 Master 判定为“失联”,Node 的状态被标记为 不可用(Not Ready),随后 Master 会触发“工作负载大转移”的自动流程。
名称 | 作用 |
init容器 | 初始化容器环境 |
pause容器(根容器) |
在pod内提供network namespace和存储卷支持 |
业务/应用容器 | 提供业务运行 |
创建后并不存放在Kubernetes 的 etcd 存储里,而是存放在某个具体的 Node 上的一个具体文件中,并且只在此 Node 上启动运行
①、pod期待的副本数
②、用于筛选目标pod的lable selector
③、当pod的副本数小于预期数量时,用于创建新pod的pod模板
statefulSet:部署的是有状态的应用
deployment:部署的是无状态的应用
①、kubernetes 中的 Volume 定义在 Pod上,然后被一个 Pod 里的多个容器挂载到具体的文件目录下。
②、Kubernetes 中的 Volume 与 Pod 的生命周期相同,Pod终止或者重启、volume数据会丢失,而容器的volume和生命周期不相关,当容器终止或者重启时,Volume 中的数据也不会丢失
③、Kubernetes 支持多种类型的 Volume,例如 GlusterFS、Ceph 等先进的分布式文件系统
PV 可以理解成 Kubernetes 集群中的某个网络存储中对应的一块存储,它与 Volume 很类似。pv作为存储资源,主要包括存储能力、访问模式、回收策略、后端存储类型等关键信息的设置。
①、存储能力:描述存储设备具备的能力,目前仅支持对存储空间的设置(storage=xx)
②、访问模式:对 PV 进行访问模式的设置,用于描述用户应用对存储资源的访问的权限
访问模式:
1、ReadWriteOnce(简写为 RWO):读写权限,并且只能被单个 Node 挂载
2、ReadOnlyMany(简写为 ROX):只读权限,允许被多个 Node 挂载
3、ReadWriteMany(简写为 RWX):读写权限,允许被多个 Node 挂载
③、存储类别
④、回收策略
PV 在生命周期中,可能处于以下 4 个阶段之一
①、Available:可用状态,还未与某个 PVC 绑定
②、Bound:已与某个 PVC 绑定
③、Released:绑定的 PVC 已经删除,资源已释放,但没有被集群回收
④、Failed:自动资源回收失败
即容器。通过镜像包含软件的运行环境,加上namespace的隔离功能,使得容器可以很方便的在任何地方运行
K8s使用pod来管理容器,一个pod可以包含一个或多个容器,他是一组紧密关联的容器集合,共享PID、IPC、Network、UTS namespace(docker的六个名称空间为:PID、IPC、Net、UTS、Mnt、User)是k8s调度的基本单位。
Node 是 Pod 真正运行的主机,可以是物理机,也可以是虚拟机
Namespace 是对一组资源和对象的抽象集合,比如可以用来将系统内部的对象划分为不同的项目组或用户组。常见的 pods, services, replication controllers 和 deployments 等都是属于某一个 namespace 的(默认是 default),而 node, persistentVolumes 等则不属于任何 namespace。
Service 是应用服务的抽象,通过 labels 为应用提供负载均衡和服务发现。匹配 labels 的 Pod IP 和端口列表组成 endpoints,由 kube-proxy 负责将服务 IP 负载均衡到这些 endpoints 上。
每个 Service 都会自动分配一个 cluster IP(仅在集群内部可访问的虚拟地址)和 DNS 名,其他容器可以通过该地址或 DNS 来访问服务,而不需要了解后端容器的运行。
Label 是识别 Kubernetes 对象的标签,以 key/value 的方式附加到对象上。Label 不提供唯一性,并且实际上经常是很多对象(如 Pods)都使用相同的 label 来标志具体的应用。