目录
二、 Kubernetes 集群的两种管理角色:Master 和 Node
①、Kubernetes API Server(kube-apiserver):(负责对外暴露 Kubernetes API)
②、Kubernetes Controller Manager(kube-controller-manager):(控调整调整集群的状态)
③、Kubernetes Scheduler(kube-scheduler):(进行调度决策,让 Pod 在合适的节点上创建运行)
④、etcd服务:(作为保存 Kubernetes 所有集群数据的后台数据库)
①、kubelet:(负责执行、监控由调度器分配的 Pod)
②、kube-proxy:(网络代理,负责为 Service 提供集群内部的服务发现和负载均衡)
3、RC(replication controller 副本控制器)对server看来的作用
4、多个pod副本组成一个集群来提供服务,客户端是怎样访问他们的
2、k8s中的volume和docker中的volume的区别
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 来标志具体的应用。